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>.
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.
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!
Copy & paste the code below to embed this comment.
Anon
(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.
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.
Copy & paste the code below to embed this comment.
J. Snell
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. ;-)
Copy & paste the code below to embed this comment.
Antti Tuppurainen
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.)
This is preposterous… XML means eXtensible Markup language. As in you should extend it and create new vocabularies accroding to it’s syntax rules to fit your business need. To suggest that we should not use XML to do the things XML was created for just doesn’t make sense.
Copy & paste the code below to embed this comment.
HomelessMechanic
Great! let us be thankful for XHTML’s modular design, oh the wisdom, and add a module describing a flag attribute using our own DTD. It’s not-trivial, we are told.
Not-trivial, repeat that. And then hear the truth. “It’s not trivial either because we’ve obfuscated it, or because there isn’t a teacher/writer/actualuser amongst us”.
“But at least its jobs for the boys for a few years yet.”
Practical accessible reading material on the subject appears not to exist. Give up now and save yourself some time. Some messiah will come along with the subject on a stick one day, maybe. You lucky lazy jobless web mechanics.
The use of language belies the w3c as technocratic elitists more inclined to ponder their own cleverness than encapsulating XHTMLs logic for anyone with more than one thing to do.
Of course it’s astonishingly simple when you know how, but don’t worry your pretty little heads about it.
Copy & paste the code below to embed this comment.
Anthony Armendariz
ALA Writers,
I have read this web site religiously since the late 90’s and I am a believer and follower of web standards. As I do understand some of the lingo and jargon in this article, some of it is just alien to me, and thus i open and quickly close the document. How techy does an article really need to be. Content is key, and if you want to really educate people, start talking to them in a manner that a broad range of people can understand, and not just us code geeks.
Sure this site is a great resource, but is it really at its full potential?? I reccomend comparing the time a user spends on a page that is easy to understand vs. pages like this. I am sure there is some drastic results.
Thanks,
Anthony Armendariz
Partner/Creative Director
Design Dialogue
Houston, TX
34 Reader Comments
Back to the ArticleKravvitz
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>.
Sam
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
IMarvinTPA
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
Chris
They are all in there.
Jody Stockley
I’m so happy to see ALA back with a new article. Keep ‘em coming!
Anon
(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.
Anon
Their just in it to lie with the i’s
Sebastian Redl
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.
J. Snell
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. ;-)
Antti Tuppurainen
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.)
kL
If you want to add new tags and attributes, take a look at WAHTWG specs (proposed to W3C):
http://whatwg.org/specs/web-apps/current-work/
http://whatwg.org/specs/web-forms/current-work/
…at least you can have some (non-)standard for your non-standard elements.
Todd
This is preposterous… XML means eXtensible Markup language. As in you should extend it and create new vocabularies accroding to it’s syntax rules to fit your business need. To suggest that we should not use XML to do the things XML was created for just doesn’t make sense.
HomelessMechanic
Great! let us be thankful for XHTML’s modular design, oh the wisdom, and add a module describing a flag attribute using our own DTD. It’s not-trivial, we are told.
Not-trivial, repeat that. And then hear the truth. “It’s not trivial either because we’ve obfuscated it, or because there isn’t a teacher/writer/actualuser amongst us”.
“But at least its jobs for the boys for a few years yet.”
Practical accessible reading material on the subject appears not to exist. Give up now and save yourself some time. Some messiah will come along with the subject on a stick one day, maybe. You lucky lazy jobless web mechanics.
The use of language belies the w3c as technocratic elitists more inclined to ponder their own cleverness than encapsulating XHTMLs logic for anyone with more than one thing to do.
Of course it’s astonishingly simple when you know how, but don’t worry your pretty little heads about it.
Anthony Armendariz
ALA Writers,
I have read this web site religiously since the late 90’s and I am a believer and follower of web standards. As I do understand some of the lingo and jargon in this article, some of it is just alien to me, and thus i open and quickly close the document. How techy does an article really need to be. Content is key, and if you want to really educate people, start talking to them in a manner that a broad range of people can understand, and not just us code geeks.
Sure this site is a great resource, but is it really at its full potential?? I reccomend comparing the time a user spends on a page that is easy to understand vs. pages like this. I am sure there is some drastic results.
Thanks,
Anthony Armendariz
Partner/Creative Director
Design Dialogue
Houston, TX