- From: Matthew Raymond <mattraymond@earthlink.net>
- Date: Tue, 05 Sep 2006 21:30:20 -0400
- To: Laurens Holst <lholst@students.cs.uu.nl>
- CC: www-style@w3.org
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