Discuss: More About Custom DTDs
by The W3C QA Group
- Editorial Comments
22 :hover isn't CSS-based behaviour
The line between presentation and behaviour can be blurred, if you choose to do so. The whole point about the “is :hover bad?” line of arugment is that they shouldn’t be.
i.e., don’t use javascript to modify the style attribute / styleSheets object. Use javascript to manipulate className instead. Doing this will prevent the line from being blurred.
Regarding hover, however, this isn’t a case of CSS implementing behaviour, so much as the browser coming with some behaviours built in. As such, :hover isn’t
I mean, ultimately you’re going to have li:hover or li.hover, which aren’t substantially different.
Of course, IE6 support is still important :P
posted at 12:36 am on May 19, 2005 by Sam
23 All I want are
I want the “target” attribute back so I don’t have to fuss with javascript to open new windows.
I also want the “wrap” attribute in textarea tags because it defines how to do line-wrapping and there are at least 3 ways the browsers deal with it!
IMarv
posted at 04:14 pm on May 20, 2005 by IMarvinTPA
24 Why don't you use the old DTD then?
They are all in there.
posted at 02:20 am on May 21, 2005 by Chris
25 Great to see ALA active again
I’m so happy to see ALA back with a new article. Keep ‘em coming!
posted at 05:51 am on May 21, 2005 by Jody Stockley
26 Not good enough
(i) respect the work of the w3c, yet wish that we’d gain a little ambition and a greater vision of what together we sellers/users/actual custodians can deliver the world.
Tags and attributes are nothing if not identity attached to various well defined semantics, but clearly it is a schoolboy error to forget that identity exists, and needs to exist, seperate from defined semantics. Arbitrary attribute, prefixed with O_, ie. O_required=“1” would solve they’re philosophical interoperability wobbles. We thousands demand you fix the spec by tomorrow.
Go on then.
I have nails and walls and a hammer. You are the masters of my windows and doors. Tell me I can’t bang these in! Tell me I can’t hang my picture!
Anon stomps off grumbling with a murderous look in his eyes.
posted at 02:59 am on May 22, 2005 by Anon
28 Behaviour and Presentation
Just a few words about the obvious confusion between behaviour and presentation.
It is wrong to say that CSS=presentation and JS=behaviour. Both CSS and JS are tools to make the browser do what you want. Behaviour and presentation are concepts.
It is true that CSS is intended to define presentation, and that JS is most suited for behaviour. Does that mean, though, that everything else is anathema? Am I not allowed to introduce a little style through JS?
The important part is separation, not language binding. If I make a behaviour.js and a presentation.js, I have properly separated the two concepts. I probably have also done a lot of unnecessary work, such as trying to monitor changes to the class attribute so that changes from the behaviour side will reflect in the visible page.
In other words, you should use CSS for presentation because it is better at it than JS. Similarly, you should use JS for behaviour because it is better at it.
There was, for example, a W3C effort called XML Events. (I believe the effort has stopped due to lack of interest.) It allowed binding of events by using XML tags instead of some script language. Was that wrong? Isn’t it said that markup is for structure?
No. The main document is for structure. Putting XML Events tags into the main file would have been wrong, because it would have mingled structure and behaviour. Using, for example, XInclude to separate the XML Events stuff would have been fine.
Another example: SVG. Web sites could look extremely cool if we used SVG for their layout. With the advent of native SVG support in Mozilla and Opera, this even becomes possible. Is it a good idea, though?
Sure, why not? Just because SVG is an XML language doesn’t mean it can’t be used for presentation. The problem is once again in that the naive approach would be to mix SVG elements into the main XHTML document. Mixing of structure and presentation. Bad.
The key in this case would be to use a technology such as XBL to separate the SVG out of the structure. And we’re fine once again.
All this has very little to do with the article in question. The article is about when to and when not to create a custom DTD.
I think the point of the article is that Peter-Paul Koch’s idea of custom attributes is good, but creating a DTD just to make them validate is not. The point is that, due to the document no longer being HTML (not even invalid HTML), the downsides outweigh the questionable benefit of correct validation.
Use your custom attributes. (As long as they don’t go into the behavioural area – in that case, bind from the JS side.) Just make sure that these attributes do not collide with possible future HTML attibutes: give them unique prefixes, or if you’re using XHTML, put them into their own namespace. Let that namespace refer to your own site, so that nobody is tempted to copy it. In recognition of Appendix C, make the namespace prefix reasonably unique as well, so that HTML parsers won’t get confused.
Your document may no longer validate. But it is understood by everything but validating XML parsers. And quite frankly, these are not of much concern in the reality of the web.
posted at 04:32 am on May 22, 2005 by Sebastian Redl
29 Interoperability
What this article tells me is that the W3C are scared that people will not use the ability to create custom DTDs properly, and thus put up big neon “this is bad” signs.
Custom DTDs in the real world are like guns. If they are used carefully and responsibly then they present no threat, but when used without thought they have the potential to do a lot of damage.
If you are going to create custom attributes, then think about what will happen to the user’s experience in user agents where the custom attributes won’t work. A good example of this would be JavaScript validation attributes in browsers that don’t support JavaScript. Will the absence of support prevent use of your site? If it doesn’t then go ahead and use those custom attributes.
If absence of support breaks the site then you’d better rethink what you are doing.
Now, if you’ve used custom attributes then you’d better tell the browser you are doing so and what it can expect to see. This is the purpose of DTDs after all, to tell programs reading our document what it can expect to find there in terms of structure. This includes both validation programs and browsers, even if the popular ones don’t actually bother to look at it.
Of course the document won’t strictly be a 100% W3C standard XHTML document, but if you construct the DTD correctly it will still, for all intents and purposes, still be XHTML. Don’t just use random prefixes for your attributes, put them in a seperate XML namespace title appropriately. Your company name would be a good namespace. This seperates your additions cleanly from XHTML with no threat of conflicting with anything and has more meaning to it than random prefixes.
If a lot of people are using the same attributes which have exactly the same meaning, then it would be wise to use the same namespace (but still seperate from the XHTML namespace) as it would identify to supporting user agents that they can expect the same thing from all these uses of the attribute.
Ultimately the way forward is treat extensions to W3C standards like treading on egg shells. It can be done safely, but only if you are very careful not to break anything. ;-)
posted at 10:01 am on May 22, 2005 by J. Snell
30 About behavior/style
What people seem to keep missing is that behavior means a change of the information immediately available to the user, while style means the presentation of all information. Style should not affect the way the information is perceived, only give an aesthetically pleasing surrounding for it.
As an example, a hover button with a different-colored background is not behavior, but style — no matter whether you do it with CSS or JavaScript. A drop-down menu with options is behavior, as it presents more information than the original view.
Someone is going to ask “Well, smartypants, where’s the line between content and behavior then?”
The line is that behavior controls the displayed content i.e. information. In the most degraded form (as in no css, js, etc for web pages) of the media, all content that can be made available through behavior should be shown.
(Disclaimer: These are all my own thoughts and strictly IMO, but if you feel like giving constructive criticism, feel free.)
posted at 11:06 pm on May 22, 2005 by Antti Tuppurainen
Discussion Closed
New comments are not being accepted, but you are welcome to explore what people said before we closed the door.
Got something to say?
Discuss this article. We reserve the right to delete flames, trolls, and wood nymphs.
Create a new account or sign in below if you’d like to leave a comment.
Subscribe to this article's comments: RSS (what’s this?)
21 It's not clear to me why creating custom attribute
It’s not clear to me why creating custom attributes for scripting is bad. They are just hooks to simplify JavaScript scripts. Web browser rendering engines don’t need to do anything with them since only the scripts will pay any attention to them.
I think :hover is fine. It’s being used to change styles when an event occurs. The lines are blurred between presentation and behavior anyway since JavaScript can make modifications to CSS through the style and styleSheets objects.
P.S. The quote from the HTML 4.01 Specs is here <http://www.w3.org/TR/1998/REC-html40-19980424/appendix/notes.html>.
posted at 11:31 pm on May 18, 2005 by Kravvitz