Buddha443556 wrote:Yep it's not valid HTML ... till you
fix the DTD.
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:Injecting the attrubutes to me is just avoiding the problem with the DTD.
I agree. No matter when the attributes are added, custom attributes are simply invalid code.
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.
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: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.
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.
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.
Buddha443556 wrote:Roja wrote:Pray that you never end up having to use assistive browsing technologies that can't handle it then.
Roja wrote:Seems selfish, short-cited, and blissfully unaware of the realities of web standards.
Wow! Did I deserve these personal attacks for trying to start a debate?
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.
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!
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.
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:Web Content Accessibility Guidelines 1.0 wrote:When inaccessible technologies (proprietary or not) must be used, equivalent accessible pages must be provided.
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.

Three issues:
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.
