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

Daniel Glazman wrote:
> 
> 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.

I agree that we need BECSS or something very much like BECSS.  I have no 
intention of trying to kill BECSS.

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

My initial reason for objecting to mixing binding syntax into css 
documents was that it felt to me like it was a hack.  The brevity of the 
syntax is elegant, but I find the placement less so.  Not that I cannot 
be convined that it is ok... many of the statements made in this 
discussion have compelled my to think that the syntax is ok.

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

Ignoring the differences in how removeBinding acts depending on how the 
binding was added, then yes they serve the same purpose.  I disagree 
with the corollary as stated.  Consider the very theoretical case of a 
UA that chose to implement xbl but not css (make it a little less 
abstract and say it is an svg renderer that chooses to support only 
presentational attributes for styling).  Should there not still be a way 
to add binding using the selector mechanism?

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

Agreed, though there are some differences because UA aren't smart enough 
to know that a particular script fragment is for style and another part 
is not.  So disabling script kills one but not the other, disabling css 
kills both, but there is no easy way to only kill changes of css on a 
particular element withour a user style sheet.

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

But I had a great ideas for css schemas :)  I know little about C++ and 
even less about cpp macros, but I'm guessing that the analogy is the same.

-Dylan

Received on Thursday, 30 October 2003 16:18:31 UTC