Re: ISSUE-41/ACTION-97 decentralized-extensibility

Philip Taylor On 09-10-19 15.28:

> Shelley Powers wrote:
>> On Mon, Oct 19, 2009 at 7:18 AM, Anne van Kesteren <annevk@opera.com> wrote:
>>> Designing for the unknown future sounds like a waste of time and effort to
>>> me. I forward compatibility is important, but adding a ton of complexity for
>>> a need that may emerge in the future seems unsound.
>>>
>> I read Tony's proposal. I didn't see a ton of complexity, especially
>> considering that namespaces are already supported in the XHTML
>> serialization of HTML5.
> 
> A lot of hidden complexity is in the parser processing rules, which 
> Microsoft's high-level proposal doesn't go into.
> 
> For example, the spec would need to define the conformance requirements 
> and expected namespaceURI/localName values in the following examples:
> 
>      <html xmlns:foo="test"> <foo:bar>


[ many examples ]

>      <html> <xmlns:foo>
> 
> Implementors (of HTML5 parsers, and of other tools like RDFa processors 
> that try to extract namespace prefix information) would have to deal 
> with all these cases and match the spec's requirements, and authors 
> would be exposed to some of the complexities when they write slightly 
> unusual markup like this.
> 
> They're not insurmountable problems, but they are problems that wouldn't 
> exist if a simpler syntax with fewer special cases and/or without prefix 
> indirection was used.

So wouldn't default namespaces be simpler than prefixed 
namespaces? Many fewer possible errors then, it seems.

> Authors would also be faced with the complexity that "Namespaces" in 
> text/html will have easily-encountered differences to how they work in 
> XML - e.g. in Microsoft's proposal, default namespace declarations are 
> either not supported or are not supported on <html> elements. Anyone who 
> reads documentation or tutorials on Namespaces in XML will be misled as 
> to how they work in HTML; they will instead have to learn the new 
> HTML-compatible subset.


Isn't Tony's proposal to do namespaces properly? Isn't it and 
advantage - today, from a "don't break the web" perspective - that 
IE doesn't support default namespaces and doesn't support them on 
HTML elements?

 
> (Experience with XHTML suggests people aren't good at sticking to 
> compatible subsets - e.g. they write <script src="..." /> in text/html 
> and expect it to be parsed as an empty element, because that's how they 
> were taught XML works, and they don't recognise the problems it causes 
> in HTML.)
> 
> Developers of script libraries will also have to deal with three very 
> different ways that element names with colons are parsed (the new 
> behaviour, legacy Firefox/Safari/Opera/etc behaviour, legacy IE 
> behaviour (presumably preserved indefinitely in compatibility modes)).
> 
> I think any proposal that encourages the use of colons in names 
> introduces a significant amount of complexity along these lines.

Sounds like default namespaces are the better option?

> (Complexity might be worthwhile if the benefits are sufficient, and if 
> the benefits can't be achieved with less complexity through other 
> solutions; but I don't believe that is the case here.)
-- 

leif halvard silli

Received on Monday, 19 October 2009 13:51:58 UTC