Re: XBL in CSS

On Thursday 17 August 2006 22:06, Ian Hickson wrote:
> On Thu, 17 Aug 2006, Bert Bos wrote:
> > I don't mind adding some more behavior to CSS. (E.g., I'd like to
> > have collapse/expand for the <nl> element of XHTML2; :hover is not
> > enough for that.) But I do worry that the behavior added via an XBL
> > binding is procedural (through JavaScript) instead of declarative
> > and especially that it makes XBL and JavaScript requirements for
> > implementing CSS.
>
> My proposal would be to put the 'binding' property in the XBL
> specification, rather than in the CSS specifications, thus making it
> only a requirement if you implement XBL.

It doesn't matter what spec you put it in, it's still in CSS. (It's also 
not very user-friendly to put a part of CSS in a spec that is published 
by another WG than the CSS WG, but we can maybe solve that with a good 
catalog of properties.)

Sure, there can be profiles of CSS. Printers don't do :hover and they 
won't do XBL either. But the general principle is that an 
implementation on a platform that could do feature X, *should* do 
feature X. Optional features aren't good.


> There has been a proposal in XBL3 for a fixed set of bindings, the
> problem is that there is such a long tail that this wouldn't
> adequately solve the problem XBL set out to solve.

Is that list (however incomplete) available somewhere? There are a 
handful of hypertext behaviors that CSS really should have supported 
long ago (expand/collapse, tooltip, pop-up) but I have a hard time 
coming up with more. Add the sequential styles from Presentation 
Levels, the tab and directional navigation from UI and the 
link/visited, active and hover that we already have, that makes 
something on the order of ten behaviors. Not a prohibitively long list.

Transition effects between pages have been suggested, but there is SMIL 
if you want those. And if you want strange effects in a page, I think 
it is acceptable when that requires a transclusion (a Java applet, a 
bit of SVG, etc.)


> While I understand that you do not feel XBL is the right solution,
> the real question is that assuming that XBL does continue along the
> REC track, do you, and other members of the CSS community, agree with
> the XBL specification introducing a new property and related
> pseudo-class to the CSS namespace. Currently it appears the majority
> of the community is in favour or at least neutral on the matter.

The problem is that it is not neutral for CSS. If you were to propose a 
new image format called PLONG and wanted to allow 'background: 
url(myimage.plong)' that would be no problem. No change to the CSS 
validator or to any CSS parser. And if PLONG turned out to be a 
disaster, CSS would be unaffected.

Not so with the 'binding' property. It permanently changes CSS. The 
validator has to accept it, CSS parsers have to handle it, if only to 
handle inheritance. And when XBL is replaced by something else, it will 
still continue to be a part of CSS.

Does it really have to be in CSS? Can't you make another language to 
express the binding between XBL files and HTML elements? Why isn't that 
binding in the XBL file itself? (In fact, isn't it already? <binding 
e="div.foo"/>, so why do you need CSS?)

I can't put XBL and CSS in the same model of Web architecture in my 
mind. They may exist in parallel for a while, but I believe XBL is a 
temporary hack (more temporary than CSS at least) and so I'd rather not 
make any permanent dependencies from CSS on XBL.



Bert
-- 
  Bert Bos                                ( W 3 C ) http://www.w3.org/
  http://www.w3.org/people/bos                               W3C/ERCIM
  bert@w3.org                             2004 Rt des Lucioles / BP 93
  +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France

Received on Thursday, 17 August 2006 21:44:44 UTC