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