Re: Decouple XBL2 From CSS

On Thu, 3 Aug 2006, Mark Baker wrote:
> >
> > Providing multiple languages would double the load on implementors, 
> > implementations, testers, documentors, and me [...]
> 
> Only if the languages were required.

It would double the load on testers, documenters, and myself (the spec 
editor) whether or not the languages were required. And to be honest, if 
the two languages aren't both required, implementors will just end up 
being forced to support both anyway, since you'll have some content that 
only works with one, and some that only works with the other.

It would also double the load on the _authors_ if the languages _weren't_ 
required, since they'd have to target two sets of implementations.

Authors hate having to target two sets of implementations. Just look at 
the number of complaints that authors make about CSS and the DOM being 
non-interoperably implemented.


> But I see no reason why other selector syntaxes couldn't be supported. 
> If an author wanted to use XPath, we'd just need a hook to let them, 
> something like;
> 
> <xbl:binding selectorType="xpath" element="/foo/bar[2]" > ...
> 
> Support of XPath would be optional, of course, so the implementation 
> burden on those who just want to support the default, CSS, would be 
> negligible.  The specification, test cases and documentation for 
> selectorType should be trivial too.

If it's optional, and thus not supported, what's the point?

(Also, note that the spec part for XPath is distinctly non-trivial. XPath 
isn't really set up for this sort of thing, you'd have to define the 
profile, the error handling behaviour, etc.)

What you seem to be suggesting is an extension to XBL. Why not specify 
that extension as a separate spec?

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

Received on Friday, 4 August 2006 02:20:50 UTC