- From: Bert Bos <bert@w3.org>
- Date: Thu, 17 Aug 2006 23:44:15 +0200
- To: www-style@w3.org, public-appformats@w3.org
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:39 UTC