Are custom attributes, such as those used by Dojo and others, acceptable?
I've seen a lot of comments about Dojo and other javascript libraries screwing up HTML validation with their custom attributes. As far as I'm concerned, custom attributes aren't a problem and are perfectly acceptable.
What's your two cents?
Custom Attributes
Moderator: General Moderators
Re: Custom Attributes
No.Buddha443556 wrote:Are custom attributes, such as those used by Dojo and others, acceptable?
Exactly. Its not valid code, it can cause problems for any browser that doesn't expect them and have a method for dealing with them.Buddha443556 wrote:I've seen a lot of comments about Dojo and other javascript libraries screwing up HTML validation with their custom attributes.
Pray that you never end up having to use assistive browsing technologies that can't handle it then.Buddha443556 wrote:As far as I'm concerned, custom attributes aren't a problem and are perfectly acceptable.
Seems selfish, short-cited, and blissfully unaware of the realities of web standards.Buddha443556 wrote:What's your two cents?
Roja is so right. Isn't it enough that different browsers render the same code (vaild code) in different ways? Now you want to use attributes which the browser doesn't even know?
Think about it
Think about it
Last edited by Oren on Mon Jun 19, 2006 8:18 am, edited 1 time in total.
- Buddha443556
- Forum Regular
- Posts: 873
- Joined: Fri Mar 19, 2004 1:51 pm
Re: Custom Attributes
Roja wrote:Exactly. Its not valid code, it can cause problems for any browser that doesn't expect them and have a method for dealing with them.
Yep it's not valid HTML ... till you fix the DTD. Injecting the attrubutes to me is just avoiding the problem with the DTD. I would prefer to know if I mistyped a custom attribute or used it in an element I did not want it used. Also makes automated validation/testing easier.Feyd wrote:If they are needed, you can use Javascript to inject them into the DOM, but I'd never use them explicitly.
In the browser, the DOCTYPE is only used to determining the the mode it will use to render the page: quirks, standard or almost standard. If the browser doesn't recognize the DOCTYPE it reverts to quirks mode. Browsers will attempt to muddle through whatever you throw at them and have a method of dealing with attributes they don't recognize - the browser ignores them.
Roja wrote:Pray that you never end up having to use assistive browsing technologies that can't handle it then.
Wow! Did I deserve these personal attacks for trying to start a debate? However, I'll ignore them and sticking to the issues of assistive browsing technologies which is much more important. The only way I've found to make sure my pages work with assistive browsing technologies is to have them tested in those technologies. Valid HTML (W3C standard or not) is no guarantee that a page will work with anything including a normal browser. However, the Web Content Accessibility Guidelines provide guidance for those of us who wish to play on the bleeding edge of technology.Roja wrote:Seems selfish, short-cited, and blissfully unaware of the realities of web standards.
Sometime even my clients get to dictate the technology, I have no problem with providing equivalent pages to comply with WCA Guidelines especially since the clients will be paying for them.Web Content Accessibility Guidelines 1.0 wrote:Many non-W3C formats (e.g., PDF, Shockwave, etc.) require viewing with either plug-ins or stand-alone applications. Often, these formats cannot be viewed or navigated with standard user agents (including assistive technologies). Avoiding non-W3C and non-standard features (proprietary elements, attributes, properties, and extensions) will tend to make pages more accessible to more people using a wider variety of hardware and software. When inaccessible technologies (proprietary or not) must be used, equivalent accessible pages must be provided.
Re: Custom Attributes
Only in XML, only on browsers that will support alternative DTD's (I know of several that do not), and - most importantly - Dojo does not do so.Buddha443556 wrote:Yep it's not valid HTML ... till you fix the DTD.
I agree. No matter when the attributes are added, custom attributes are simply invalid code.Buddha443556 wrote:Injecting the attrubutes to me is just avoiding the problem with the DTD.
Actually, custom attributes make it challenging to develop - they don't get the context warnings that a WYSIWYG editor would produce for non-custom attributes. It also makes automated validation harder, as some embedded automated validators (tidy) do not like custom attributes.Buddha443556 wrote:I would prefer to know if I mistyped a custom attribute or used it in an element I did not want it used. Also makes automated validation/testing easier.
All kinds of inaccuracies in those statements. First, the DOCTYPE is used for multiple things - not just determining the mode used to render the page. It also has an impact on the javascript processing, on the css rendering, on the security model, and more. There is little the doctype doesn't have an impact on.Buddha443556 wrote:In the browser, the DOCTYPE is only used to determining the the mode it will use to render the page: quirks, standard or almost standard. If the browser doesn't recognize the DOCTYPE it reverts to quirks mode. Browsers will attempt to muddle through whatever you throw at them and have a method of dealing with attributes they don't recognize - the browser ignores them.
Worse, not all browsers immediately throw into quirks mode if it doesn't recognize the DOCTYPE. Jaws, for example, does not do so. (Of course, there is an argument to be made that Jaws doesn't have a strict mode, but thats another discussion). Worse, if you hand it a valid custom DTD (as you recommended at the beginning), most browsers actually go into strict mode - and without an understanding of how to handle those custom attributes, the behavior is undefined - not ignored.
Neither were personal attacks. I use assistive browsing technologies, and non-standard code is far more likely to cause problems. I can count on both hands the number of html-compliant pages that have had issues on those technologies, where on the opposite side, its a rare case to find a non-compliant page that doesn't have at least a minor issue.Buddha443556 wrote:Roja wrote:Pray that you never end up having to use assistive browsing technologies that can't handle it then.Wow! Did I deserve these personal attacks for trying to start a debate?Roja wrote:Seems selfish, short-cited, and blissfully unaware of the realities of web standards.
Choosing to ignore those realities is selfish. Your comment allowed that response, when you said "As far as I am concerned, custom attributes aren't a problem and are perfectly acceptable". The reality disagrees with you, and does so for a non-trivial number of users.
Its also short-cited, as this discussion is based on the CURRENT state. What happens when IE8 or 9 requires valid code, and ends quirks mode entirely? I suspect custom attributes wouldn't be nearly as attractive if the entire page would fail to render. Worse, what of browser vendors trying to move to only supporting strict mode, but unable to because so many sites use non-standard code, and now, people try to encourage the use of custom attributes as "not a problem". Its a problem for rendering engines!
I don't disagree. However, I would repeat the previous statement I've made - the vast majority of HTML valid code does work well in assistive technologies. I'd consider HTML compliance the 80% mark to being accessible.Buddha443556 wrote:However, I'll ignore them and sticking to the issues of assistive browsing technologies which is much more important. The only way I've found to make sure my pages work with assistive browsing technologies is to have them tested in those technologies. Valid HTML (W3C standard or not) is no guarantee that a page will work with anything including a normal browser.
Three issues:Buddha443556 wrote:Sometime even my clients get to dictate the technology, I have no problem with providing equivalent pages to comply with WCA Guidelines especially since the clients will be paying for them.Web Content Accessibility Guidelines 1.0 wrote:When inaccessible technologies (proprietary or not) must be used, equivalent accessible pages must be provided.
1. "Must be used" is the key - custom attributes aren't *required*, they are something you can choose to use or not. The vast majority of the web manages to exist without them, and the use of them is simply poor programming practice.
2. To choose to provide an alternative page (as you just did), you have to agree that they are inaccessible technologies - as I've stated, but you've argued against. If its accessible, you don't need an alternative.
3. Seperate but equal is bad - even on the web. It means more maintenance, less relevant search results, poorly maintained "accessible" sections of sites, and double the work for the same amount of output for users.
In such a scenario, I hardly see how you can argue that they "aren't a problem".
Quoting your sig:
"I conclude that there are two ways to constructing software design: One way is to make it so simple that there obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies."
It sounds like you are aiming for the latter.
I apologize to Buddha443556.
In re-reading my comments, it definitely comes across as a personal attack, and that was not at all my intention. He is defending a rather perilous position, in a good-natured attempt to encourage debate. While I focused my responses to his position, after a reread, my comments targetted him without me intending to do so.
Sorry for the confusion.
With that out of the way, I am interested in the debate on the topic! I feel that the logic for not using custom attributes is strong, but I'm not so closed-minded as to be uninterested in the possibility of other ideas.
So please, discuss!
In re-reading my comments, it definitely comes across as a personal attack, and that was not at all my intention. He is defending a rather perilous position, in a good-natured attempt to encourage debate. While I focused my responses to his position, after a reread, my comments targetted him without me intending to do so.
Sorry for the confusion.
With that out of the way, I am interested in the debate on the topic! I feel that the logic for not using custom attributes is strong, but I'm not so closed-minded as to be uninterested in the possibility of other ideas.
So please, discuss!
Personally, I think browsers (user agents in general) must ignore those attributes they do not understand and handle only those they know about (and only those which are allowed according to the current DTD).
Following this logic we will achieve the separation between attributes intended for browsers and attributes used by, say, AJAX apps.
Sometimes I need to bind some JS object to some part of a document tree. Moreover, to simplify the coding I would like to mantain two-way binding. How would I do this without custom attributes? Mantaining global binding registry looks like a dirty coding to me.
Following this logic we will achieve the separation between attributes intended for browsers and attributes used by, say, AJAX apps.
Sometimes I need to bind some JS object to some part of a document tree. Moreover, to simplify the coding I would like to mantain two-way binding. How would I do this without custom attributes? Mantaining global binding registry looks like a dirty coding to me.