- 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