- From: Daniel Glazman <danielglazman@easyconnect.fr>
- Date: Thu, 30 Oct 2003 16:01:18 +0100
- To: www-style@w3.org
This mail is not directly related to the threads about BECSS but I felt the need to write down my feelings about BECSS and post them here. Maybe a few people share them with me, or maybe it can make you all think about it. Anyway, here it is: 1) I firmly believe we need BECSS. I think I stood up at least three or four times during the Future of HTML Workshop many years ago asking for behavioural extensions. Not exactly a leitmotiv, but I'd like to see it happen before my old age. I think BECSS is almost the only reasonably feasible real mechanism of extension on the web. Microsoft, Netscape and Electricité de France started discussing BECSS ***years*** ago. We have no more time to spend. 2) I think that we have so many times discussed the fact the CSS general syntax can be used for other tasks but CSS that this is deeply integrated into my brain now. When I see foo bar { color: red; binding: url(a.xbl); } I don't think this *is* CSS. This is one instance, conformant to the CSS general syntax, made of one rule applying one stylistic/presentational declaration and one binding. The author chose to aggregate the two into one single rule, because the selector is shared. It makes sense from an author's POV. 3) because of point 2, I think that we should have a new mimetype for instance the one proposed by Tantek, application/css. Read well: such a mimetype could be used for all document instances conformant to the basic modules of CSS 3 (selectors, grammar, units, inheritance and cascade) ***WITH THE PROFILE OF CSS3***. In other terms, using application/css would be ok for an instance of purely stylistic rules an instance of CSS and BECSS rules (grouping of declarations per selector allowed) an instance of BECSS rules and if some day we have the XYWWZZ language fully conformant to the basic modules of CSS3, well, an instance of XYWWZZ rules then you could keep text/css for pure CSS. But I am not far from finding this counter-productive. 4) from my perspective, the 'binding' property and the addBinding() method serve exactly the same purpose w/o any difference. For me, saying that 'binding' should not apply 'semantic' bindings because disabling CSS would disable them is a false argument : this is only the case if the CSS and BECSS share not only the parser but also the resolution engine. In other words, that's not a spec problem, that's from my point of view entirely an implementation problem. Corollary: If you're an implementor and if your browser disables the application of bindings when CSS is disabled, I claim that's YOUR fault because you don't separate the application of styles and behaviours in your resolution engines. 5) in relation to point 4, there is no way we can restrict the usage of the binding property to one kind of XBL or another. The binding property should know NOTHING intrinsicly about the target URI. Imho, it implies that any restriction on the type of binding applied by 'binding' can be ONLY informative, certainly not normative. To tell the truth, I would find such a restriction, even informative, almost completely useless. It's like inline style attribute and the style DOM property in ElementCSSInlineStyle interface. Serve same purpose, achieve same effect. I urge the recipients of this message to read and read it again many times before making an opinion. It's like having cpp macros into a C++ code. Different purposes, one instance only. That's viable. More important, that's SIMPLE. Let's not fall into the trap the XML-everywhere community has fallen into, please. </Daniel>
Received on Thursday, 30 October 2003 10:01:23 UTC