[Javascript] CSS vs. JS: The content property

[mdougherty at pbp.com (Mike Dougherty)]

1.  I can understand why having CSS generated content would offend some css purists.  I can also 
see how your example (as a general class of solution) is a strong arguement against those purists. 
 This tool can be very valueable when used properly.  The purists will probably argue that the 
majority of developers will abuse the technology more often than use it correctly.  This is the 
same arguement against the .innerHTML property in javascript.  It's very useful, but I won't use 
it anymore because it's undoubtedly on the chopping block of future support.
2.  you already made the point about misuse - same as my point #1
3.  I think your point here is an extension of #1.  It seems to me that the mantra "CSS for 
display" would suggest this is EXACTLY what "content" is to be used for.  The suggestion that a 
program language (js) be used to dynamically redesign the document is valid for interactive 
updates (based on user input, the page is redesigned)  In the case of media-specific css, the user 
isn't even involved yet - or possibly without the 'content' enhancement, they CAN'T be involved 
because the information isn't communicated.  Using pseduo-elements and a series of rules to keep 
popups open is better implemented using an object method that changes the popup's className. 
 Using CSS to render a document given it's initial state and some rules for display is what CSS 
already does - the support for "content" is an extension of that.

That's my two cents, but I'm no Eric Meyer <g>

On Thu, 28 Apr 2005 11:13:02 -0400
  Ryan Cannon <ryan@xxxxxxxxxxxxxx> wrote:
>For as much as I respect him, after reading some of PPK's Tough Quizzes at the QuirksBlog[1] I've 
>really begun to disagree with the his stance on the content property[2], for a number of reasons, 
>and I'm wondering what others think.
>
>    [1] http://www.quirksmode.org/blog/
>    [2] http://www.quirksmode.org/index.html?/css/clearing.html
>
>I see a few reasons why:
>
>1) Media-specific style sheets. Aural stylesheets would be impossible without :before, :after and 
>the content property. This is mostly a theoretical argument, as only Opera 8 supports aural 
>stylesheets, and I haven't been able to test how well. But the code:
>
>@media aural {
>    a[href]:before { content: "link: " }
>    acronym[title]:before,
>    abbr[title]:before { content: attr(title) " or "; speak:normal }
>    acronym, abbr { speak: spell-out }
>}
>
>Is essential for a meaningful use of the aural medium.
>
>2) Graphical replacement of text.
>
>CSS-on, Images-off, Javascript-off is a nightmare for accessibility-minded designers. The 
>emerging CSS 3 method looks like a promising solution:
>
>@media screen { h1 { content: url("h1.png") } }
>
>or, better, with XHTML 2:
>
>@media screen { h[src] { content: attr(src) } }
>
>Both of these options assume that a designer is using text images to replace content. It does 
>have the potential to be misused, but so does a lot of design technologies.
>
>And finally,
>
>3) Non-structural, non-behavioral graphical enhancements
>
>A common argument against the content property stems from its altering the document structure. 
>PPK says Javascript should do this instead, but I wonder about this. If we are truly separating 
>presentation, structure and behavior into three-legged stool, is CSS really a hammer for screws 
>when it comes to visual cues?
>
>Think of it this way: on my website, I want viewers to know that a link in the text of my blog is 
>to an external site--a small icon, nothing that needs to show up in the document structure, 
>because it is inappropriate in some media (print, for example).
>
>I could write a DOM javascript to insert an image after every link with http in its href 
>attribute, or I could use CSS. I contend that this is presentation, not behavior, and therefore 
>use:
>
>a[href^="http://";] { content:url("external.png") }
>
>Of course some browsers miss out on this, but it's a minor detail and I'm not too concerned.
>
>Of course I'm not against using Javascript for behavioral elements, such as dynamic tables etc, 
>I'm just trying to sort out which issues are nails and which are screws. What do you think?
>
>--
>
>Ryan Cannon
>Instructional Technology
>Web Design
>http://RyanCannon.com
>
>_______________________________________________
>Javascript mailing list
>Javascript@xxxxxxxxxx
>https://lists.LaTech.edu/mailman/listinfo/javascript
>
>
>
>__________________________________________________________
>This message was scanned by ATX
>11:13:26 AM ET - 4/28/2005