W3C home > Mailing lists > Public > public-appformats@w3.org > August 2006

Re: Decouple XBL2 From CSS

From: Ian Hickson <ian@hixie.ch>
Date: Thu, 3 Aug 2006 21:36:35 +0000 (UTC)
To: Mark Birbeck <mark.birbeck@x-port.net>, Antoine Quint <aq@fuchsia-design.com>
Cc: public-appformats@w3.org, doug.schepers@vectoreal.com
Message-ID: <Pine.LNX.4.62.0608032050150.5340@dhalsim.dreamhost.com>

On Thu, 3 Aug 2006, Mark Birbeck wrote:
> 
> I'm getting deja vu here. I can't keep track of all the discussions I'm 
> in with you, in which you dismiss someone else's view as providing 
> 'little or no benefit to the author', or assert that XML technologies 
> are unused on the web. Are you really serious when you say that XPath is 
> an untested technology? I had to look twice at the date...I'm sure you 
> must be having a little jest.

Relative to Selectors? Yes, XPath is hardly used at all. In a recent study 
of 667416 files, containing 862606 <link> elements with a type attribute, 
681381 had type="text/css", and 6847 had text="text/xml" or 
"application/xml", which covers RSS, Atom, and XSLT. (The same sample had 
736036 <link> elements with rel="stylesheet". The de facto default type="" 
value for rel="stylesheet" in browsers today is text/css.) I found exactly 
one file that claimed to use the XForms namespace in this sample. (I 
didn't check to see if this file actually used XForms; it should be noted 
that there are a surprisingly large number of pages on the Web that claim 
to use a whole host of namespaces but actually don't use any. Thus, this 
hit could have been a false positive.)

I haven't yet checked script-based use of Selectors or XPath, but 
preliminary results suggest that neither is used to any significant 
degree.

So based on this research, I conclude that most authors have used 
Selectors (typically as part of CSS), and nearly no authors have used 
XPath (whether as part of XSLT, XForms, or scripting).


> Anyway, the request for XPath selector support *is* actually being made 
> by authors and application builders

It's being requested by a very small (though very vocal) minority. If you 
allow a spec's design to be led by the vocal minority you end up with a 
spec that is not useful for the silent majority. The W3C process is very 
well tuned towards creating such specifications, and the TR page is full 
of them. I have no intention of letting XBL2 fall into that trap.


> and I think it would be wise to design XBL in such a way that the 
> binding *selection* process is distinct from what the bindings actually 
> do. If an implementer chooses to only support CSS selectors then that's 
> fine, and doesn't bother me at all.

If you are ok with having two non-interoperable versions of XBL2, one with 
implementations that use Selectors, and the other with implementations 
that use XPath, then I encourage you to take the XBL2 specification, 
change its name to something else, change the "Selectors" parts to using 
XPath (this will require quite substantial changes, including specifying 
error handling behaviour for XPath, and profiling the allowed expressions 
for XPath to exclude things that don't act like pattern matches), and 
finally publish it. The XBL2 specification is available under a Creative 
Commons Attribution Share-alike license for precisely this purpose.


On Thu, 3 Aug 2006, Antoine Quint wrote:
> 
> What can I say? This kind of statement really shows that you're not as 
> informed as you could be on the topic of XPath usage and maturity. And 
> considering that CSS3 selectors are not a W3C recommendation, but just a 
> WD, how can it be considered more mature? I'm sure there are lots of 
> people using selectors as specified by CSS 2 or 2.1, but certainly not 
> by a spec in WD.

Selectors have been in a W3C recommendation since 1996, two years before 
XML was published, two years before even the first draft of XPath was 
published. The latest revision of Selectors is in WD, LC, CR, or whatever 
stage we're at today, sure, but that's just the latest version -- the 
original version (which was published as part of CSS1) has been around for 
nearly a decade, is *very* widely used (far more so than XPath), and is 
very widely understood by authors.


> > (Using both isn't an option because it would require twice as much 
> > work for everyone involved with little or no practical benefit to 
> > authors.)
> 
> Web technologies such as XHTML, CSS, the DOM, SVG and soon XBL are not 
> confined to usage for displays of Web pages, but are also heavily used 
> for creating rich user interfaces in desktop and mobile applications. On 
> my machine, my several IM/IRC clients are all using a Web languages 
> rendering toolkit (WebKit), so do my RSS newsreader, code editor, etc., 
> and these are just a few examples of how a lot of modern applications 
> are developed.

Yes, XBL1 was designed for this exact purpose. I was there. :-)


> The people behind these end user applications are not Web authors, but 
> rather developers. And XBL itself is today most heavily used by Gecko 
> developers. I wish all the success in the world to XBL on the Web, but 
> we shouldn't forget that XBL is also very much geared advanced 
> development techniques and I like to think that desktop/mobile/Web 
> application developers, like me, are looking for XPath support in XBL.

While it's great that technologies like HTML, CSS, and XBL are capable 
enough to be used in contexts that aren't the Web, that doesn't mean that 
those contexts should drive the specification.

It doesn't matter if the XBL in your RSS reader's UI renderer 
interoperates with the XBL implementation in your spreadsheet package's UI 
renderer, because those are implementation-specific. It is perfectly fine 
for XBL (or any other technology) to be tweaked for those contexts, which 
might well imply using XPath or whatever. For example, Mozilla fully 
intends to make internal tweaks to XBL2 to support native code 
implementations, add fixed interface support for COM, add secure-binding 
flags, etc.

That has absolutely no effect on the spec which *does* have to be 
interoperable, simple, and easy to use, namely, the version of XBL which 
is to be used and deployed on the multi-UA Web.


IMHO this discussion is moot. We've already had this argument many times. 
I'm not going to dance around here being politically correct, I'm just 
going to be blunt about this: I'm not happy to move forwards with an XBL2 
that uses XPath instead of Selectors, and I'm not happy to move forwards 
with an XBL2 that uses more than one binding pattern language. This design 
was reached by careful consideration based on researching what real 
authors were familiar with on the Web. Naturally not all authors will 
agree with this design, but that will always be the case.

If you wish to raise a formal objection, I will go out of my way to make 
sure the director is aware of your position when we move to CR.

I was asked, by the Web Application Formats working group, to bring the 
specification that I edited for Mozilla to the W3C, on the understanding 
that no major changes would be involved. I am happy to do that, and I'm 
happy to fix any real technical problems that are found in the spec.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 3 August 2006 21:36:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:10:19 GMT