W3C home > Mailing lists > Public > public-html@w3.org > June 2009

RE: <font color="blue"> (was ISSUE-32)

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>
Message-ID: <051d01c9ebaf$be26fc80$3a74f580$@edu>
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

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:04 UTC