- From: John Foliot <jfoliot@stanford.edu>
- Date: Fri, 12 Jun 2009 15:46:25 -0700 (PDT)
- To: "'Jonas Sicking'" <jonas@sicking.cc>, "'Shelley Powers'" <shelley.just@gmail.com>
- Cc: "'Rob Sayre'" <rsayre@mozilla.com>, "'Sam Ruby'" <rubys@intertwingly.net>, <public-html@w3.org>
Jonas Sicking [mailto:jonas@sicking.cc] > > I'll repeat a reply I sent to John Foliot in a private email recently: > > "As I understand it it's up to any and all HTML consumer to decide what > they want to do when a parse error is reached. > > I can only speak for one consumer of HTML 5, the firefox web browser. > We do not plan to take any action on parse errors, or DOM errors. Thanks for making public something that you said to me in private. So there we have it: it simply does not matter, as Firefox for one will not care. And if Firefox doesn't care, I don't see lesser browsers (lesser in terms of market share, not capability) doing anything differently, at the risk of losing the market share they hang on to now. The house of cards is exposed. > As I also work with Henri Sivonen, I happen to know that the validator > that he is writing (and I believe have been contracted by W3C to > maintain), will report all parse errors by reporting them back to the > user, but it will also continue parsing in order to find more errors. > However it won't report the page as conforming unless there are no > parse errors." And so no gold star for me. I think I can live with that, especially if I know that I am creating a more accessible document using poorly understood but currently supported attributes like @summary. Fact: using ARIA attributes today creates non-conformant (non-validating) documents, yet most forward looking JavaScript libraries are implementing ARIA into the fold as quickly as they can, and all of the major browsers are supporting most aspects of ARIA today. So my choice is better accessibility or non-conformance: that's a tough call? > For what it's worth, I can't think of a way that the spec *could* > mandate a specific behavior for non-conforming vs. conforming markup > in a productive manner. Even the XML spec is very vague on what to do > with non-conforming documents. Do you display as much as you've loaded > to that point. Do you only retain what you've displayed so far (which > could be slightly less than you've parsed. Do you replace what's > currently being displayed with an error message? Are you not allowed > to display anything until you know the document is conforming? Jonas, do you remember what happened, way back when, if you opened a <table> but forgot to close your </table> in, say, Netscape 3? At that time I was teaching civil servants how to write HTML in Notepad, and trust me, they only made that mistake once... they learned quickly what a critical failure looked like (which of course was a blank page). But today the browsers are smarter, which allows for dumber HTML I guess... JF
Received on Friday, 12 June 2009 22:47:04 UTC