W3C home > Mailing lists > Public > www-style@w3.org > October 2003

bindings, behaviours, CSS and aspirin (the one I need after this message)

From: Daniel Glazman <danielglazman@easyconnect.fr>
Date: Thu, 30 Oct 2003 16:01:18 +0100
Message-ID: <3FA127BE.8000901@easyconnect.fr>
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

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.

Received on Thursday, 30 October 2003 10:01:23 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:09 UTC