Re: XBL in CSS

On Thu, 17 Aug 2006, Bert Bos wrote:
> 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.

By that arguement, any browser that supports CSS should also support SVG. 
I'm not sure I agree with your premise.


> > 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?

Not firmly, no. The widgets found in HTML4 and XForms would be the start 
of such a list, but then that immediately shows why such a list would 
probably be inadequate: despite the fact that HTML4 and XForms both have, 
e.g., a submission button, the binding for one and the binding for the 
other would be radically different in implementation.

XBL is (in part) an element-level UA-agnostic plugin architecture for Web 
browsers, much like the Netscape Plugin API but more generic.


> 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.

Ironically, none of those bindings would be on my initial list of 
important bindings. :-) I agree they are things that would be useful, 
though, which demonstrates the "long tail" aspect I mentioned.


> > 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.

Indeed, that is why the Web Application Formats working group is making 
this request.


> 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?)

Implementation experience with Mozilla and IE strongly suggests that a 
CSS-based binding mechanism would be very useful.

There are several use cases for bindings; some are always applicable (e.g. 
an <input> in HTML is always something you submit; if you implemented 
HTML4 Forms using XBL, you wouldn't ever not want the <input> to take part 
in the form submission model), some are presentational (e.g. using XBL to 
rearrange content or to make new interfaces for widgets depends on the 
alternate stylesheet set selected).

For the latter use case, a hook from within CSS seems necessary.


> 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.

On the contrary, if XBL is seen as a way to implement other languages,
like XForms, HTML4, XHTML2, or various Semantic Web things, using Java as 
the implementation language, and CSS as the presentation layer, it seems 
to me that the two languages would cooperate hand-in-hand.

Similarly, if one considers XBL to be useful merely for content reordering 
in conjunction with CSS, then again it would seem that the two languages 
could be expected to have a similar lifespan.

If one considers XBL to be a "macro language" for use with, e.g., SVG, 
where it can be used to define new elements that "expand" into complex 
shapes (in the spirit of the <svg:use> element or XML entities, but with 
significantly more flexibility), then the use of CSS as a hook language 
becomes even more important and again, one would find the two used hand- 
in-hand during their entire lifetime.

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

Received on Thursday, 17 August 2006 22:07:47 UTC