Re: "/>" (was Re: several messages about New Vocabularies in text/html

David Carlisle wrote:
>> Experience suggests that making this kind of apparently-simple syntax change the 
>> /shouldn't/ break pages inevitably /does/ break pages and so is
>> unacceptable. 
> 
> It's odd that earlier in the the thread we were told that proper
> handling of html5 would require a real html5 parser (of which several
> ought to be available) but in the same thread there is the repeated
> requirement that html5 "work" with the existing html4 parsers.

The requirement in it's purest form is that we create a spec that people are 
willing to use. That means that implementors have to be willing to ship products 
based on the spec which, in turn, means that implementing the spec cannot some 
at the cost of breaking a significant amount of existing content.

Whether the content is valid HTML 4 or not is irrelevant to whether we can break 
it or not. The only wiggle room in the requirement is the definition of 
"significant" - whether the content that will be broken counts as significant 
depends on how much of it there is, how likely it is to be fixed and how many 
users will encounter it.

> So if html is really a problem make /> generate an empty element for all
> elements unless specified otherwise, and then specify otherwise for all
> (non-empty)  html elements. 

I think it is plausible that we will be able to have the parser treat "/>" as 
indicating a void (HTML 5 term for empty, to distinguish it from an element with 
no content) element if that element is to be placed into a non-html namespace in 
the DOM. That's different from blacklisting the set of HTML elements, as there 
are cases where an unknown element will be placed in the HTML namespace.

-- 
"Eternity's a terrible thought. I mean, where's it all going to end?"
  -- Tom Stoppard, Rosencrantz and Guildenstern are Dead

Received on Wednesday, 2 April 2008 16:55:05 UTC