Re: XBL in CSS

Bert Bos wrote:
> 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.

   How is this any different from any property that takes a URL for an
image? If the user agent doesn't support the image format, the property
is ignored. Similarly, "binding" does not have to require that the
binding language is XBL. The user agent can ignore the target URL if it
doesn't support the binding language. Internet Explorer could bind to
HTCs, for example.

   Big issue, though, is providing fallback URLs for other binding
languages if the UA doesn't support a specific binding language. I
suggest we use only whitespace to separate fallback URLs, while using
commas to indicate a separate binding in cases where you're performing
multiple bindings:

| binding: url(bind1.xbl) url(bind1.htc), url(bind2.xbl) url(bind2.htc);

> Transition effects between pages have been suggested, but there is SMIL 
> if you want those.

   Heck, SMIL is one of the biggest reasons I want XBL. If I decide to
use alternate style sheets, I want to be able to have specific SMIL
markup for each style sheet. How would you do that without XBL?
Dynamically build the page on the server based on a query string in the URL?

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

   Why would you want to pollute your beautifully semantic (X)HTML with
a bunch of markup that's only there for presentational purposes? If the
effect isn't important to the content, it makes much more sense to
include it via a style sheet binding, especially if this effect is going
to be on every web page on your website and you're not using a server
based application to build your pages dynamically.

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

   It's no different from a situation where the user agents supports
zero image formats. Does a property like "background-image" permanently
require that the user agent support at least one image format?

> The validator has to accept it, CSS parsers have to handle it, if only to 
> handle inheritance.

   The validators have to accept ANY property you add to CSS, so you
seem to be arguing that we can't add any properties at all because the
validators would have to be changed. As for parsers, those that don't
support any binding languages can simply not implement "binding".

> And when XBL is replaced by something else, it will 
> still continue to be a part of CSS.

   In that case, when the XBL Replacement Language (XRL) comes out...

| binding: url(file.xrl);

> Does it really have to be in CSS?

   Yes.

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

   This won't work with traditional (non-XML) HTML documents, so if you
have to serve the same document to all user agents, you can't use XBL.
It also means that pages must be converted from HTML to XHTML in order
to use XBL, whereas with a CSS-based binding you need only change the
style sheet, which can then be referenced by multiple documents. Using
XBL in the actual document forces you to use XML for primary document
markup, while a CSS "binding" property does not.

Received on Friday, 18 August 2006 11:25:44 UTC