[Bug 11909] The principles of Polyglot Markup - validity? well-formed? DOM-equality?

http://www.w3.org/Bugs/Public/show_bug.cgi?id=11909

--- Comment #7 from David Carlisle <davidc@nag.co.uk> 2011-01-30 18:16:28 UTC ---
> I prefer to have further debates about the scope of the document in bug 11909.

moving here as requested (but actually the mailing list is probably better)

> It is also not enough that the document is conforming HTML(5): <noscript> does
not work as intended in XML. 

of course, but the extra constraints needed for a document known to be
conforming html and well formed xml to get compatible DOM parse are
sufficiently coherent that one could contemplate listing them in full in a
spec, hence this spec.

you seem to want to document the set of well formed documents that produce a
compatible DOM if parsed as XML and that is a vastly more complicated set to
describe.


> Isn't it a good start to just list them?

No, it would be at best misleading.

> Just create a header saying "the
following features are autogenerated if you don't insert them, and must
therefore be explicitly added for DOM compatibility". And then list the
features/elements. 

That's nowhere near close to a usable specification. The HTML parser doesn't
just insert elements it moves things around in ways that are fully specified
but that you can not specify here without duplicating much of the html5 parsing
spec.

You'd have to specify all the ways in which p (and other) elements are
auto-closed, all the ways in which form elements get moved around tables, all
the html elements that force-close math and svg. You'd have to specify not to
use image. The list is endless, and unless it was complete the end result would
be that authors would be able to generate documents that complied with all the
constraints in the polyglot spec, but which were not parsed in compatible ways
by xml and html parsers.

If you restrict to conforming documents the complete set of constraints is more
or less listed in the current document (there may be some bugs here and there
but nothing that would make the document ten times bigger). If you do not
restrict to conforming documents the downside is that the spec becomes
unwritable and the only possible upside is that people are informed how to make
non conforming documents using xml tools, but I don't see that making non
conforming documents should be a valid use case.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Sunday, 30 January 2011 18:16:32 UTC