RE: Decouple XBL2 From CSS

On Fri, 4 Aug 2006, Doug Schepers wrote:
> |
> | XBL2 is based on discussion and listening to a broad range of 
> | inputs. It's one of the most openly discussed specs 
> | that is currently being driven by the W3C -- all discussion 
> | since late last year has been on public lists, both 
> | before and after being in the W3C
> 
> I understand that this spec has been discussed extensively elsewhere, 
> but not very much so on this list.  You have stated your conclusions, 
> but not any evidence leading up to them; I'm sure this evidence exists, 
> so I would appreciate a pointer to any substantive technical discussions 
> that indicate why XPath should not be a selector option for XBL2.

Quoting from:

   http://lists.w3.org/Archives/Public/public-appformats/2006Aug/0014.html

"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)."

I have also asked various experts in the field, including implementors of 
major Web browser vendors and representatives of the Web Standards 
Project. Their advice was almost unanimously to use Selectors rather than 
XPath. (In several cases, their actual reply was "what's XPath?".)

There are, in addition to all the reasons given above, significant 
technical reasons to use Selectors rather than XPath. The binding 
mechanism is performance-critical; selectors has a very limited worse-case 
evaluation time. XPath, on the other hand, potentially requires the entire 
tree to be crawled to evaluate each expression, leading to much slower 
worse-case performance characteristics.

Furthermore, XPath is not a language that performs the mapping:

   expression * element -> boolean

It is a generic expression language capable of mathematics, string 
manipulation, and more, and must be profiled to limit it to the above 
mapping. Selectors, on the other hand, is designed exclusively for 
use in contexts that need that mapping (such as XBL).

This means that even if the browser already supports XPath, the 
implementation cannot simply be re-used for XBL. For example, Mozilla's 
XPath implementation would apparently need significant work to function in 
an XBL context, whereas its selectors implementation could just be dropped 
in unchanged.

And finally, Selectors is simply much more mature and well-understood than 
XPath. Selectors first became a REC in 1996, XPath only became a first 
working draft in 1998.


To recap:

 1. Selectors is used more than XPath.
 2. The majority of experts I have consulted recommend using Selectors.
 3. Selectors has better performance characteristics than XPath.
 4. XPath doesn't fit exactly the mapping we need.
 5. Existing XPath implementations can't always simply be re-used.
 6. Selectors is the more mature specification.

Any _one_ of these reasons would tip the balance in favour of using 
Selectors over XPath.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Friday, 4 August 2006 21:08:37 UTC