Re: XBL in CSS

Matthew Raymond schreef:
>>>> 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.
>>>       
>> 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.

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

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.

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

>> In the contrary, I think it makes more sense to refer to the XBL 
>> stylesheet directly from the XML (or HTML) file, and let the binding to 
>> specific elements be done in the XBL itself (through the ‘element’ 
>> attribute).
>>
>> This would also keep prevention of the cycle that fantasai mentioned 
>> within the XBL domain, and not pull it into the CSS implementations.
>>     
>
>    How does Mozilla solve this problem with XBL 1.0?
>   

Probably if there is a re-flow for an element, by flagging that the 
reflow was caused by XBL and in that case not applying any new bindings 
that it may get. It is of course possible to do this within CSS, I’m 
just saying that this way CSS will retain its nice properties such as 
‘no-cycles’, and the XBL only has consider itself when reflowing. I can 
imagine this would simplify the implementation.


~Grauw

-- 
Ushiko-san! Kimi wa doushite, Ushiko-san nan da!!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Laurens Holst, student, university of Utrecht, the Netherlands.
Website: www.grauw.nl. Backbase employee; www.backbase.com.