Re: XBL in CSS

Laurens Holst wrote:
> Matthew Raymond schreef:
>>> That makes no sense. You already ‘pollute’ your XML / HTML with 
>>> reference(s) to style sheet(s), so I do not see the argument here.
>>>     
>>    I'm not sure what you mean. You have the <link> and <style> elements,
>> but those elements aren't in the document body, and you have to have
>> some way to attach styling to begin with. If you mean the |class| and
>> |id| attributes, those have purposes other than styling. You have the
>> |style| attribute, but I personally don't think there should ever have
>> been a |style| attribute, since it serves no semantic purpose.
> 
> Yes, but when talking about referencing XBL from within the XHTML, I 
> also meant that we should just link to it, just like stylesheets, and 
> the XBL contains Selectors to bind it to the elements. So I am not 
> saying there should be any other markup to link the XBL with the XHTML 
> than the <link> element. And the <?xbl-binding?> processing instruction 
> in XML, of course.

   (I assume you mean the <?xbl?> processing instruction, because
"xbl-binding" is a CSS property in the current public XBL 2.0 working
draft, and not a processing instruction.)

   This would result in more markup in the initial document than the CSS
approach because you'd still have to link to the style sheet. In
addition, it would also mean that every document that uses the XBL
binding would have to have a declaration in spite of the fact that they
all separately share style sheets as well.

   Worse, specifying the binding in markup means that you have to
specify every possible selector the XBL might bind too in the actual XBL
file you're importing. So every time you want to bind to a different
element, you have to change the XBL file.

>>> Given that the markup depends on the presence of XBL for its behaviour, 
>>> it seems strange to me to reference it a. indirectly, and b. from a 
>>> within a presentation language.
>>     
>>    But the whole point is that the markup and scripted behavior is
>> presentational rather than semantic. For instance, imagine a <canvas>
>> element that's used for purely presentational animations. Now think of
>> how you'd do a different animation for every alternate style, or have an
>> alternate style that doesn't have the animation. The user wouldn't be
>> able to change the styling through their browser's page style selection,
>> so you'd have to rig up some Internet Explorer-esque hack to allow them
>> an interface to change the style sheet along with the animation type.
> 
> But it is not necessarily (and certainly not purely) presentational.

   As I stated, they can and should use markup-based binding for
non-presentational bindings. Also, recall that you can make multiple
bindings to an element, so you can potentially use this to isolate
unrelated presentation and functionality.

   I suspect that functionality that's absolutely necessary will not be
done via CSS anyways, since the binding can be overridden with a user
style sheet, styling may be turned off, or the style sheet may not be
loaded.

> When considering what I’d use XBL for, I’m thinking of e.g. XForms and 
> XML Schema datatype processing and validation. XForms has parts which 
> specify logic and no presentation, and XML Schema is not presentational 
> at all, but solely behavioural.

   I strongly suspect that this is NOT what many web authors would use
it for, especially if you want style-dependent SMIL markup.

>>    So you see, you claim indirection, but that's because the markup is
>> associated with a specific style, while you're looking at the markup as
>> being associated with the document. You wonder why you'd want to bind
>> from a presentational language, but the whole point is that the markup
>> is presentational. Think of it as if the XBL binding is an
>> implementation of a CSS property.
>>
>>    Now, granted, if there is no presentational purpose to the binding,
>> or there is considerable behavioral functionality, then you should
>> probably bind via markup. XBL 2.0 fully supports binding via markup.
>> There is some potential for misuse, but I don't think it's worth
>> throwing out the baby with the bathwater.
> 
> Given that the functionality to bind through markup is there, I’m not 
> sure whether there is a good reason to have a secondary way to do this.

   Given that there is no simple way to coordinate the markup with a
specific style, I don't see how style-dependent markup could be possible
without CSS-based binding. I personally don't looking to doing CSS
object model queries so I can pull in the right binding using scripting.
I also don't look forward to having annoying presentational markup on
the page, even when I have styling turned off.

Received on Wednesday, 6 September 2006 01:30:38 UTC