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

Sam Ruby On 09-10-06 18.41:
   [...]

> We've not even established that D.E. is a requirement. 

   [...]

> I see two parts to this question.

   [...]

So if I understood the implications of these two parts...

> The first part is how to deal with markup extensions,

   [...]

> For many uses, something as simple as saying names with a dash (or a dot 
> or another character) will never be standardized and to encourage the 
> use of prefixes may suffice.  A similar approach has worked, and worked 
> reasonably well, for CSS; though there are enough differences between 
> the two languages that it is not at all clear that such an approach 
> would work in the context of HTML (example: CSS has a more comprehensive 
> approach to fallbacks).


... then we need some variant of <prefix[punctuation]name>

> The second part is the (unfortunate?) fact that users and tools have 
> made use of entity and attribute names containing colons.  You have, and 
> will continue to see, such syntax used in RDFa and in SVG fragments that 
> users will copy and paste into HTML documents.  As near as I can tell, 
> nobody is contesting the current position that none of these elements or 
> attributes will affect the rendering of the page one bit.


.... the colon format is a much used prefix format. Hence, it 
would be convenient to say that entities/attributes with a colon 
in the name will never be defined as part of text/html. And thus 
select that format as the extension format. Exception: some 
prefixes, e.g. "xmlns:", would be reserved.

 

> Three subparts to the second part.
> 
> a) The current spec goes beyond the statement above, and makes all such 
> uses non-conforming.  My personal belief is that such is entirely 
> unnecessary and counter-productive.  And ultimately, self-defeating.

CSS vendor prefixes do not cause parse errors. But do not validate 
either.

> b) HTML parsing can result in localNames containing colons in the DOM. 
> Serializing such DOMs as XML /can/ result in parse errors, depending on 
> whether or not a corresponding xmlns: declaration is present.  The 
> current serialization algorithm doesn't take this into account, and 
> instead serializes things like dc:title as dcU00003Atitle.  Such will 
> not round trip.  My belief: this is suboptimal.


<foo:bar> causes a local name "bar" in IE, regardless of whether 
there is a namespace declaration or not. How serious is that?

My view:

* Colon prefixes possible one attributes
* Default namespaces may be simpler to support than prefixed elements.

 
> c) MS's DistributedExtensibility Submission[3] goes beyond this, and 
> attempts to make it easier to access this information via ECMAScript 
> APIs, and in the process narrow the gap between the DOM produced by an 
> XML parser and the DOM produced by an HTML parser when given the same 
> polyglot[4] document.


Polyglot documents are for "situations where a document is 
intended to be served as either HTML or XHTML, depending on the 
support in particular browsers".

Which sounds as a pretty strong justification for allowing XHTML 
extensibility syntax in text/html documents. It works fine if some 
UAs can read it as text/html and others as XHTML.

But I think that what we are discussing here, are text/html 
documents where some UAs see namespaces and others do not. Thus 
the breaking the web problem.

>  My opinion: I'm not sure that this is possible 
> without breaking the web.  Adding new APIs may be possible.  Phillip 
> Taylor has pointed out that simply adopting MS's existing tagURN may 
> cause pages that employ capability based browser sniffing to break.[5]


W.r.t. new APIs: I suggested a new, generic "namespaced context 
container" - e.g. <root> [1]. What other new API ideas are there?

> [4] http://dev.w3.org/html5/html-author/#polyglot-documents
> [5] http://lists.w3.org/Archives/Public/public-html/2009Oct/0076.html 


[1] http://lists.w3.org/Archives/Public/public-html/2009Oct/0179
-- 
leif halvard silli

Received on Thursday, 8 October 2009 02:09:27 UTC