11 CSS is behaviour

Sanchez said: «The original Koch article was about separating behavior from structure and style — a desirable W3C objective if I ever heard one.»

Koch’s point sounds desirable – and may be is. But what’s the diff between behaviour and style? Much done through JavaScript manipulations can be done with CSS. So why call it ‘behaviour’ when it uses JavaScript instead of CSS?

posted at 09:41 am on May 18, 2005 by Leif Halvard Silli

12 Good points

Personally I don’t know if custom DTDs and namespaces make sense when you could just use an XML document with a proper schema or relaxNG and go nuts on your attributes elements. This would also allow you to create proper sections of the document rather than relying on H1-H6 to introduce but not encompass your sections.
An XSL transformation can spit out the proper xHTML, a JavaScript with the right validation and instruct the backend how to work out the fallback validation should JavaScript not be available.
Putting our own inventions on the backend will also make it safer – if I can see all required information in the markup I have a chance to spoof them a lot easier.

By the way – Interesting spot for a typo:
“It does, however, remind us of a very important point: validation only one step in checking the correctness of”

Correctness is achieved by adding andother “is” after validation :-)

posted at 09:48 am on May 18, 2005 by Chris

13 I hate this keyboard

another of course, not andother

posted at 09:48 am on May 18, 2005 by Chris

14 CSS is not behaviour

CSS cannot create and remove elements from the document. That is what the DOM is for.
Visual changes are not the same as changes in the structure. JavaScript also allows you to test a lot more than CSS even with the CSS3 selectors allows you to. How would you validate a form entry in CSS? This is what behaviour is about.

posted at 09:51 am on May 18, 2005 by Chris

15 Behaviour and CSS

There are some examples around, I gather, of elements created through pseudo-elements and generated content. And for CSS3 selectors you yourself note similarity. More advanced, but still much of the same.

View it like that should have implications for how to continue. New content [new CDATA] for e.g. the style attribute would then be quite logical: new css attributes instead of new (X)HTML attributes. E.g. style=”-jsrequired:‘true’;”. Valid XHTML but invalid CSS, until the new CSS attributes are accepted. Is that so bad? Eventually you could create a /* behaviour */ section in your stylesheet.

posted at 10:24 am on May 18, 2005 by Leif Halvard Silli

16 style/behavior

This is a bit off topic, but given any apparent confusion of CSS with behavior, perhaps ALA should look into publishing an article on why :hover is a bad idea (or not) in CSS. A lot of people complain that IE doesn’t support :hover for anything but a link but shouldn’t we be looking at javascript for that anyway? What does the W3C have to say about this? (I’ll admit, I haven’t looked)

posted at 10:30 am on May 18, 2005 by jim

17 Re: CSS is not behaviour

While I agree with most of your post, the use of ::before and ::after, as well as the (poorly supported) content attribute do allow for the creation and modification of simple elements (anything complicated will likely break cross-browser compatibility). Opera’s content attribute is faily powerful and I believe Opera is closest to achieving CSS counters (if not alrady achieved) thanks to it.

That said, yes, DOM manipulation is much more reliable, as all browsers have their respective problems with CSS generated content (for example, I stayed up until 2:30 last night trying — and failing — to figure out problems with ::before and ::after in Opera. I used them to generate content in my default Style Sheet, and in another Style Sheet that is only loaded when JavaScript is available they were set to display: none;, but Opera would not remove these elements).

Or am I missing something here?

posted at 10:37 am on May 18, 2005 by Brian LePore

18 Caution is still a good practice

One person solving a real world problem and then exposing it to the world is good. 15 people solving the real world problem exposing it to the world is confusing. The W3C is only cautioning you that Custom DTD’s might make your page validate but won’t necessarily make you page readable by your targeted audience. If a useable implementation already exists then use it. If one doesn’t then yes build one. Custom DTD’s are not a panacea though. That’s why standards are important. It increases the chances that your document will be readable by the widest range of client platforms.

posted at 10:45 am on May 18, 2005 by Zaphar

19 Confusing CSS with behaviour?

«Behaviour» seems to be simply another word for «script» — or is it a particular way of using the scripts?

Anyway, Koch got his inspiration from the way CSS stylesheets work. And to use «script selectors», seems very much in line with the thinking behind CSS stylesheets.

To introduce new markup attributes —even introducing more than one such markup «behaviour» attribute instead of having just one «behaviour» attribute with many content (CDATA) options— in my mind is not in line with the thinking behind CSS stylesheets.

That is how I evaluate Koch’s article against the background fo W3’s article.

posted at 11:19 am on May 18, 2005 by Leif Halvard Silli

20 Standards coming up short

The fact of the matter is that support for arbitrary attributes is totally supported by (X)HTML – in the sense that all browsers have supported it since the DOM was introduced.

The fact that the standards have NO clear way of recognising this is a huge shortcoming. My own solution is simply to ignore those validation errors; this is hardly ideal, particularly when we are trying to promote our CMS as standards compliant.

posted at 09:30 pm on May 18, 2005 by Sam