W3C home > Mailing lists > Public > public-html@w3.org > March 2010

Re: TWO Change proposals for ISSUE-41 : Distributed Extensibility

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Wed, 17 Mar 2010 07:34:26 +0100
To: Maciej Stachowiak <mjs@apple.com>
Cc: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>, Jonas Sicking <jonas@sicking.cc>, "Ennals, Robert" <robert.ennals@intel.com>, Ian Hickson <ian@hixie.ch>, HTMLwg <public-html@w3.org>
Message-ID: <20100317073426706435.e4fd93a9@xn--mlform-iua.no>
Maciej Stachowiak, Tue, 16 Mar 2010 22:15:16 -0700:
> On Mar 16, 2010, at 8:48 PM, Leif Halvard Silli wrote:
>> Maciej Stachowiak, Tue, 16 Mar 2010 18:18:24 -0700:
>>> I think Microdata and RDFa are good examples of standardized
>>> extensions. However, as a browser engine developer, I would like the
>>> ability to do vendor extensions (either experimental or not intended
>>> for public Web content) without stepping on valuable shared
>>> namespace. We have a decent way to do that with CSS properties using
>>> the vendor prefix convention(*). It would be nice to have something
>>> similar at the HTML level. It seems like Rob's proposals (either X or
>>> Y) would provide ways to do that.
>> Rob states in proposal X that
>> ]]Any document that parses correctly in both XML and HTML is guaranteed
>> to parse to the same DOM tree.[[
> I think this statement is true, even with Robert's proposal.

> All browsers seeing the same DOM is different from XML and HTML 
> parsing producing the same DOM.

This is not what I had in mind. I only had text/html in mind.

> The former is essential, and separate 
> from any differences in processing that DOM. The latter will not be 
> achieved by Robert's proposal and is probably not practical for 
> various edge case reasons.

Vendor prefixes would then be an edge case?

What I meant was that if an attribute prefix lives in a namespaces 
according to one user agent, but not according to another (which could 
be a possibility in text/html, even if it may not be possible in 
XHTML), then a prefixed attribute "leave" on the DOM tree could be 
targeted, via CSS, like this,


in the UA that sees it as a namespace. And like this,


in an UA which doesn't see the namespace.  May be this difference is 
what you refer to as the "produced DOM"? And I argue that one cannot 
avoid this difference, when it comes to vendor prefixes.

Effectively, in text/html, then a vendor specific namespace could be 
implemented without the use of a prefix - one could simply do this:

	<div -wexbkit="value">

Those that support the -webkit namespace could then see it (in CSS) as 


Or as


whereas the others could target it as 


(Unlike for CSS prefixes [but also not in CSS, if the extension is a 
specific selector syntax!], then in HTML, we cannot avoid that user 
agents/authors potentially make use of the vendor prefix in a 
non-vendor specific fashion.)
leif halvard silli
Received on Wednesday, 17 March 2010 06:35:02 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:13 UTC