Re: XBL in CSS

I tend to agree with Bert here.

Tying together given versions of CSS and XBL at specific design
points is likely to turn into a  maintainance problem long-term.

Bert Bos writes:
 > 
 > 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

-- 
Best Regards,
--raman

Title:  Research Scientist      
Email:  raman@google.com
WWW:    http://emacspeak.sf.net/raman/
GTalk:  raman@google.com, tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc
Google: tv+raman

Received on Thursday, 17 August 2006 23:41:57 UTC