[Bug 5752] Parsing should be specified for future updates

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





--- Comment #16 from Rob Burns <rob@robburns.com>  2008-06-15 21:31:10 ---
Qualifier for comment #14)
Lachlan, you're just grasping at straws here and I have to wonder why you're
doing this; what's at stake for you in this? You're needlessly complicating
this, and for what? Look the point here is to get to a forward compatible
parsing algorithm. The next question is how can we do that that doesn't: A)
significantly break existing content and B) confuse authors.

For A) Philip is diligently looking for some cases where we might break
existing content to understand how big of a problem we face with that. From the
looks of it so far (again assuming he's drawing a representative sample) it's
not at all a concern.

On the next issue of authoring simplicity, it's really not as complex as you're
making it out to be. 

 * In HTML5 compliant UAs any unknown tag with a solidus is self-closing (the
definition of “unknown” might need to be determined)
 * For HTML5 authors they change nothing; end of story

Having said that here's some things we can do to prepare authors for
forthcoming HTML specifications.
 1) include a solidus in void elements (it helps novice authors understand the
concept of a void element and novice authors copying source from other authors
learn from this approach)
 2) stop telling authors that their doing something wrong if they include a
solidus in their void elements. The confusion you claim you want to avoid is
being created by continually confusing authors, telling them that their code
must is invalid, incorrect, voodoo,  messed up, etc., if it uses a solidus in
void element tags.
 3) continue to tell authors to NOT rely on the solidus in non-void empty
elements but to explicitly close such elements (e.g., <script></script>)

Note that when HTML6 arrives, authors will then be using a solidus to indicate
a void element in every such tag (no complications there) and in HTML5 they're
free to do the same now (again no authoring complications).

It is possible we may never see an HTML6. I cannot predict the future. I can
tell you that it would be incredibly irresponsible for this WG to not take
these simple steps to ease the burden on the HTML6 WG if it comes about. What
I'm calling for here are a few minor changes to the parsing algorithm. However,
they are the types of parsing changes that might actually make UAs want to risk
changing their own already debugged and already tested parsing algorithm. As it
stands now, I can't really imagine why they would bother if its not going to
help with future compatibility (these UAs are already mostly compatible with
existing content or these UAs would have already changed their parsing
algorithms).


-- 
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, 15 June 2008 21:31:45 UTC