[Source Distributed Extensibility Submission from Microsoft - 30 September 2009]
It is a common practice for authors, tool vendors, and library authors to want to extend languages to represent additional information that can't be adequately described by the standard grammar. ... Here are a few examples that apply to HTML:
- A JavaScript library processes custom tags in a browser and turns them into custom controls dynamically on the page.
We would very much like our proprietary Custom Tags to validate.
- A browser wants to allow custom behaviors to be defined in one module and attached automatically to custom elements.
We would very much like our proprietary HTML Components to validate.
- An author includes processing instructions in the document that will be processed by a server before delivering the document to a user agent.
We would very much like SharePoint's proprietary InfoPath processing instructions to validate.
- A HTML document editor adds information about tool settings so that a subsequent editing session can continue with the same settings.
We would very much like Word's "export as HTML" output -- which is so proprietary that it has spawned an entire cottage industry dedicated to "cleaning" it -- to validate.
In many cases, the language customizations are used for small niche applications and don't require the burden of centralized standardization. Instead these extensions are defined in a distributed fashion among groups of interested developers or authors.
We like making up our own shit.
A Distributed Extensibility model for standard HTML is desirable because it means that user agents from different vendors that adhere to the standard can be assured of correctly processing mark-up that contains extensions without destroying the integrity of the document.
Other people keep fucking up our shit.
The proposal as stated closely matches behavior that Internet Explorer has had for a number of releases, reducing compatibility concerns.
Supporting distributed extensibility means providing a standard repeatable mechanism for creating these extensions without the need for centralized agreement.
We're going to keep making up our own shit, whether it validates or not.
(with apologies to John Gruber,
who did it first and did it best)
Postscript: I am not "against" extensibility, or distributed extensibility, or decentralized extensibility, or whatever we're calling namespaces this week. I just think it's funny that some people read this proposal and immediately jumped to The Glorious And Infinitely Extensible Semantic Web With Unicorns And Ponies, when it's really just an attempt to get the HTML Working Group to bless a collection of Microsoft-proprietary technologies that they've jammed into Internet Explorer over the years.
§
Most of my recent writing has happened elsewhere.
- Dive Into Python 3
- Dive Into HTML5 (in progress)
- Various articles about HTML5 on the WHATWG blog, including
That last article came about during the creation of mimesniff, my open source Python 3 library that implements the HTML5 Content-Type detection and character encoding detection algorithms.
If none of that is your cup of tea, here is a picture of my dog Beauregard, enjoying the beautiful North Carolina summer weather.
§
The following consensus was reached by Protocols and Formats Working Group during its teleconference of Wednesday, 3 June 2009 ...
We note that summary is often used as a technique for accessibility support where governmental regulations require governmental web sites to be accessible. ... [link to Guide to the Section 508 Standards for Electronic and Information Technology, Subpart B - Technical Standards, Web-based Intranet and Internet Information and Applications (1194.22), Section (g) "Data Table"]
If summary is removed [from HTML 5], U.S. Government web sites, might find it more difficult to conform to HTML 5. We further note that Section 508 regulations apply to U.S. state and local governments, and that similar accessibility requirements are emerging in Canada, the U.K., the E.U., Australia, and elsewhere.
Web developers who are interested in summarizing their tables should consider placing their descriptions either adjacent to their tables or in the body of the table, using such tags as the CAPTION tag.
On June 4, 2009, Ian Hickson, editor of the HTML 5 specification, replied:
As far as I can tell this concern is unfounded; the <caption> attribute is in fact encouraged by the very same government (as quoted above) to be used exactly as HTML5 recommends in a manner consistent with the goals of the summary="" attribute.
HTML 5, Editor's Draft as of this writing:
For tables that consist of more than just a grid of cells with headers in the first row and headers in the first column, and for any table in general where the reader might have difficulty understanding the content, authors should include explanatory information introducing the table. This information is useful for all users, but is especially useful for users who cannot see the table, e.g. users of screen readers.
Such explanatory information should introduce the purpose of the table, outline its basic cell structure, highlight any trends or patterns, and generally teach the user how to use the table.
There are a variety of ways to include this information, such as:
- In prose, surrounding the table
- In the table's caption
- In the table's caption, in a details element
- Next to the table, in the same figure
- Next to the table, in a figure's legend
Authors may also use other techniques, or combinations of the above techniques, as appropriate.
If a table element has a summary attribute, the user agent may report the contents of that attribute to the user.
PF responded on these questions formally. We would appreciate the basic human courtessy of acknowledgment. If you don't like what we said, please speak to that. But kindly don't simply ignore us. [link to the June 3, 2009 message announcing the consensus of the Protocols and Formats Working Group]
On July 7, 2009, Ian Hickson, editor of the HTML 5 specification, replied:
That e-mail received a reply some weeks ago: [link to Ian Hickson's message of June 4, 2009]
Is there a formal reply to that e-mail?
No, we don't make formal replies to individuals.
On August 2, 2009, John Foliot wrote:
I maintain that it is not the role of the HTML WG, and the editor in particular, to be offering this guidance, especially when it contradicts the consensus position of the W3C Group chartered to speak on web accessibility issues. Simply put, you are messing in somebody else's yard, and it is against W3C process to be doing so. If HTML WG feel that they have compelling evidence and data that suggests that the WCAG guidance needs to be reviewed and revised, there is a process for that.
On August 3, 2009, Ian Hickson responded to John Foliot:
I didn't want to be the one to have to explain this to you, but nobody else is doing so, so here goes: The W3C process doesn't actually require that working groups agree, or not contradict each other. The WAI's mission is not binding on other working groups.
On August 3, 2009, at approximately 7:51 pm, Roy Fielding wrote:
I have no opinion on the value of @summary other than noting the likelihood that its support will be required for some FIPS or government statute for accessibility, and therefore deprecating it within HTML5 will just make HTML5 look stupid.
Web developers who are interested in summarizing their tables should consider placing their descriptions either adjacent to their tables or in the body of the table, using such tags as the CAPTION tag.
On August 3, 2009, at approximately 7:59 pm, Roy Fielding wrote:
[A]uthors are clearly not served by a specification that tells them caption and summary are the same and all such information must be relegated to caption. As an implementor of content management systems used by government agencies in several different countries, I will not conform to any HTML specification that deprecates or fails to define @summary.
Web developers who are interested in summarizing their tables should consider placing their descriptions either adjacent to their tables or in the body of the table, using such tags as the CAPTION tag.
On May 23, 2006, Joe Clark wrote:
The Web Content Accessibility Guidelines Working Group [part of the W3C Web Accessibility Initiative (WAI)] is the worst committee, group, company, or organization I've ever worked with. Several of my friends and I were variously ignored; threatened with ejection from the group or actually ejected; and actively harassed.
In response to Joe Clark's article, John Foliot wrote:
I can attest to knowing a regular participant to the [Web Content Accessibility Guidelines] WG discussion list who has been shut down and ignored on more than one occasion, and I personally have been dismissed by other working groups within the W3C. ... So the behavior and treatment described by Joe is not unknown any time you strongly voice an opinion counter to the internal W3C herd.
On August 2, 2009, John Foliot wrote:
I have submitted an alternative [HTML 5] Draft document for consideration; one which I believe rightly returns the role of author guidance for creating accessible content to the W3C WAI - the group officially chartered by the W3C to speak to these matters. It is a question of respect.
On August 4, 2009, Ian Hickson asked:
Are you saying that for you, it is more important that HTML5 not contradict other W3C specifications, than it be that HTML5 address accessibility problems with the HTML language?
On August 4, 2009, John Foliot responded to Ian Hickson:
You needs to stop contradicting WAI, even if you have proof that WAI might need to update their guidance. ...
Contradictory information *harms* the overall outreach aspect of teaching people how to create accessible web content, and I speak from the position of one who actually does that for a living, and have been doing so for close to a decade. THE MESSAGE WE SEND TO THE WORLD'S WEB DEVELOPERS MUST BE CONSISTENT!
Web developers who are interested in summarizing their tables should consider placing their descriptions either adjacent to their tables or in the body of the table, using such tags as the CAPTION tag.
On August 3, 2009, Roy Fielding wrote:
John [Foliot]'s point is that the W3C has a group specifically tasked to make accessibility recommendations.
On August 3, 2009, David Baron responded to Roy Fielding:
Has that group weighed in in this debate, in response to the evidence presented? Or is it just that an out-of-date (i.e., not updated in response to newer evidence) recommendation of that group is being cited?
On August 3, 2009, Roy Fielding responded to David Baron:
I don't know -- it isn't a relevant question. The group exists [link to W3C Web Accessibility Initiative (WAI)] and seems to be open for your input.
§
On the topic of <canvas> accessibility, John Foliot writes:
Finally, I propose that any instance of
<canvas>that lacks at a minimum the 2 proposed mandatory values be non-conformant and not render on screen.
When pressed for an explanation, John continues:
Actually, yes, I have proposed this form of draconian response before.
It's about consequences: until such time as there are real consequences for slack developers/tools that allows content to exist that is incomplete, then there will be content that is incomplete - it's a simple as that. Why would
<img src="path..." />be any more complete than<img alt="Photo of a leprechaun" />? I mean, clearly, anyone processing that info in their user-agent will 'get' the intent of the author, right? Yet today, the first example will render in the browser, the second delivers a 'fail'. Ergo (to me) there is a problem of inequity here that must be addressed - if it fails for some, it should fail for all.
If it fails for some, it should fail for all.
John also believes that Flickr is (or at least should be) illegal because it allows people to publish inaccessible content. I'll pause for a moment and let that sink in.
.
.
.
It's important to understand just how extreme these views are, even within the accessibility community. I was a professional accessibility architect for several years; before that, I took an intense interest in web accessibility; long before that, I was a relay operator for AT&T. A few years ago, I had the pleasure of attending the annual CSUN accessibility conference, where I helped staff the Mozilla booth and talked about Firefox's accessibility features to anyone who would listen. So I have had the opportunity to speak to a great many people who cared about accessibility, authored accessible content, wrote accessible software, designed accessible hardware, and provided accessibility services.
In all that time, in all those conversations, with all those people, I have never heard anyone say, "Seriously, you know what we should do to make the world more accessible? Fuck over all the sighted people."
I know that most of the people who care about accessibility do not have the time or resources to follow the daily machinations of the HTML 5 working groups. That's fine; standards take a long time and require a lot of attention, and most people have day jobs somewhere else. But I have observed a kind of "conventional wisdom" taking hold in this wider community -- that the HTML working group doesn't care about accessibility, that any and all proposals are rejected, that the views of "experts" are simply dismissed out of hand.
I think it would be wise for people who truly care about accessibility to take a closer look at the so-called "experts" who are participating on their behalf, and to understand exactly what these people are proposing. It's true that some of their proposals have not been adopted, but it's not because some cartoonishly monocled villain enjoys being mean to them. It's because the proposals are insane.
§
In case you missed it, I've started a new column at the WHATWG blog called This Week in HTML 5. The story thus far:
- Episode 1: Web Workers, and how to specify alternate text for images you know nothing about.
- Episode 2: the window.navigator object, meta http-equiv="Content-Language", the
Workerobject,outerHTML,insertAdjacentHTML(), and the continuing saga of thealtattribute. - Episode 3: the event loop, the
onhashchangeevent, and content sniffing for SVG images. - Episode 4: the W3C's HTML 5 validator, SVG-in-HTML, and the proper way to provide alternate text for Rorschach inkblots.
- Episode 5: XSLT, MathML, Web Forms 2, and some light reading on character encoding.
- Episode 6: multimedia accessibility, Ogg Theora, and the year 2022.
- Episode 7: clickjacking.
There is a feed available for people who like that sort of thing.
§