Re: Write-up about semantics in HTML5 from A List Apart

On Thu, Jan 8, 2009 at 11:25 PM, Robert J Burns wrote:
> Hi Thomas,
>
> On Jan 7, 2009, at 7:08 PM, Thomas Broyer wrote:
>>
>> On Wed, Jan 7, 2009 at 7:17 PM, Martin Atkins wrote:
>>>
>>> A solution to this has been offered in the form of having the <element/>
>>> form be treated as void for all unknown elements.
>>
>> It wouldn't solve anything short-term, as current browsers parse
>> unknown elements as non-void, whatever the "/>" syntax; only
>> <element></element> would (and could lead to different DOMs being
>> produced if an author uses <element>foo</element>: "foo" as a child of
>> <element> in HTML5 but "foo" as a sibling and </element> ignored in
>> HTMLx).
>
> That is not true. IE parses unknown elements as void. <element></element>
> becomes:
>
> element
> /element
>
> where two void elements are created as siblings of one another, one with the
> name prefixed with a solidus.

It actually depends whether you've used some script before or not:
http://blog.whatwg.org/supporting-new-elements-in-ie

>> There cannot be a single rule that would allow compatibility all over
>> the place (HTML6 docs in HTML5 UA, HTML5 in HTML6 UA; with the same
>> DOM being produced); except not introducing any new void element
>> and/or non-phrasing element; which is probably worse than having
>> authors use middle-term workarounds.
>
> The use of the slash would solve the problem (along with the other proposed
> solutions). In other words in both HTML5 and HTML6 parsers, the UAs would
> know that any unknown (unknown as of right now) element with a slash is to
> be parsed as a void element and any unknown element without the slash is to
> be parsed as a non-void element.
>
> The difference between phrasing and structure elements is simply that the
> latter implicitly closes a P element. I see no reason to make any more
> elements that need to implicitly close a p element

You are proposing introducing a discrepency in the language ("legacy"
void elements do not require a trailing slash and "legacy" "block
elements" imply a </P>; while "new" void elements require a trailing
slash and "new" "block elements" require you to explicitly close your
paragraphs if you don't want the element to become a child of it!),
which will last for years; while there are workarounds (include "new"
void elements at the end of an element –eventually inserting it within
a <span>– as Ian proposed, or use an end tag for the void element; and
explicitly close your elements before opening a "new" "block element")
to have elements parsed appropriately by "legacy" parsers (HTML5
parsers when you author an HTML6 document; HTML4 parsers when you
author an HTML5 document, though it's a bit different in this case as
HTML4 parsers have no "standard" behavior), which are only needed
short-term to mid-term (depending on how fast new browser versions are
adopted, and your audience).

I'd expect those workarounds to be part of test suites.

> (the implied close of a p was probably a bad idea in retrospect to avoid a
> very short tag).

HTML was supposed to be SGML-based, where an UA would use the
appropriate DTD (from its catalog), as given in the DOCTYPE, to
determine how to parse a document.


-- 
Thomas Broyer

Received on Friday, 9 January 2009 09:46:40 UTC