- From: <bugzilla@wiggum.w3.org>
- Date: Sat, 14 Jun 2008 08:48:27 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5752 Summary: Parsing should be specified for future updates Product: HTML WG Version: unspecified Platform: All URL: http://esw.w3.org/topic/HTML/ParsingSpecifiedForFutureUp dates OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Spec proposals AssignedTo: dave.null@w3.org ReportedBy: rob@robburns.com QAContact: public-html-bugzilla@w3.org CC: ian@hixie.ch, mike@w3.org, public-html@w3.org We must specify the parsing algorithm for HTML5 to facilitate the easiest adoption of new elements in the future. • UAs do not generally make use of DTD or other parsing definitions so parsing is coded into the UA • Different UAs handle unknown (or new) elements in different non-interoperable ways • Parsing unknown elements as block elements prevents the introduction to legacy UAs of new inline elements (instead invoking implied P element clost tags) • Parsing unknown elements as void elements prevents the introduction to legacy UAs of new non-void elements • Parsing which moves unknown elements to the body from the head or from the head to the body prevents the introduction of new elements • The lack of a shortcut mechanism to signal void elements requires the cumbersome use of close tags for newly introduced void elements for legacy UA processing Parsing unknown elements as inline elements would be the most forward-compatible approach, but also allowing solidus character for self-closing of unknown elements would create greater flexibility without breaking existing content. See the wiki page for further evolving solution proposals. (http://esw.w3.org/topic/HTML/ParsingSpecifiedForFutureUpdates) Following an approach for interim legacy bridging markup (including the encouragement of <div p> instead of <p> ) would also allow maximal forward compatibility. (see http://esw.w3.org/topic/HTML/InterimLegacyBridgingMarkup) -- 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 Saturday, 14 June 2008 08:49:02 UTC