On May 30, 2007, at 15:02, Julian Reschke wrote:
Philip Taylor wrote:
...
Perhaps it would be better to rephrase as: Will there be a
conformance
class for HTML5 consumers that process conforming documents according
the spec, but process non-conforming documents in an undefined way?
...
Yep, that's what I had in mind.
I think it could be useful to allow markup editors to coerce non-
conforming documents into conforming in an implementation-defined way
because then the editor could limit UI representations to conforming
cases.
(I'm not sure whether it's that useful to be able to claim
conformance
for its own sake. Interoperability is useful, but maybe that can be
achieved by imagining a new spec which just says "If a document is
conforming according to the definition in HTML5, then it must be
processed as described in HTML5, otherwise the document should be
rejected but anything may happen" and all the tools can follow that,
so there's no need for HTML5 itself to explicitly allow that.)
> (Keep
> in mind that these consumers may not even have a DOM or a
> Javascript engine).
http://www.whatwg.org/specs/web-apps/current-work#non-scripted
already
defines UA conformance when there's no scripting, which seems to
cover
those cases.
Thinking of which, they may not even want to build a tree of the
document. So how does the HTML5 parsing model help consumers that
just want to consume a stream of tokens similarly to a Sax parser?
The parsing spec allows a Draconian response to parse errors. Hence,
if you want SAX events, you have two conforming options:
1) Build a tree in its entirety first and then emit the events
based on the tree.
2) Emit events as the parse progresses and halt on errors that
require non-streamable recovery.
My plan is to implement both (in Java).
--
Henri Sivonen
[EMAIL PROTECTED]
http://hsivonen.iki.fi/
