RE: New Working Draft : BECSS

Daniel wrote:

> As a document provider, I see absolutely no reason to keep :
>
> 	DIV.foo > P#bar + TABLE { text-align : center }
>
> and :
>
> 	DIV.foo > P#bar + TABLE { onclick : "func(event)" }
>
> in two single files/objects/whatever when it can be easily agregated
> in :
>
> 	DIV.foo > P#bar + TABLE { text-align : center ;
> 				  onclick : "func(event)" }

One can go to the bathroom, and one can go for a drive.  Aggregating the two
because they both involve "going" would over time make for a rather unpleasant
car. ...

> > Could we not please keep style in CSS and move behavior to another
> > mechanism? Behaviors-expressed-in-CSS-like-notation is fine, but I
> > feel strongly that behavior declarations do not belong in a CSS
> > stylesheet.
>
> I'll keep in mind that last sentence. Let me now give you my opinion :
> my company got involved in the BECSS discussion because we strongly
> believe that such a way of declaring behaviors is the easiest and
> cheapest way to help us building a real intranet in the energy
> industrial field, distributing our web components all over the country
> in all our sites. All the mechanisms now appearing in some other parts
> of the W3C are still highly unstable and it'll take tiiiiiiime until
> we get (a) browsers' support (b) deployment of these browsers over our
> 130,000 computers (guess how long it takes to update 130,000
> computers!). The CSS linking mechanism is already here and perfectly
> functional.  BECSS provide a way of declaring behaviors that can be
> agregated to styles ***without modifying CSS itself***.

What's wrong with using a CAS (or whatever you want to call it) as a *separate*
linking mechanism?  Is it because bringing in a new MIME type would be too much
trouble?  Sneaking behaviors into the back door (via CSS) seems to be a quick
hack to avoid some kind of problem like this.  But what are the long-term
ramifications of doing this?  And most importantly, what does behavior have to
with style -- other than that you *could* share the same declarative syntax?

> It's enough
> for the "very-big-document-and-apps-provider" part of Electricité de
> France and we see no real serious reason but "religious" not
> agregating BECSS rules and CSS rules in a single object.
> XML, and sub-technologies, is agregating the document instance, the
> styles, the transformations and so on in the single object. So what ?

Yes, right now we LINK in a stylesheet into (for example) an HTML document.
BECSS would be an even *further* level of indirection: HTCs would be linked into
the CSS that's linked into the HTML doc... The recent focus is on packaging,
where each of these stand alone and unlinked, but "wrapped" in another resource,
yet BECSS seems to be going in the opposite direction.

> Last but not least, the 2 major browser vendors agree on that
> mechanism and sat quickly at the same discussion table. Hey, isn't it
> a real miracle ?-)))

Weren't they both behind "namespaces" as well?

I know the W3C is a consortium, but I do hope that long-term considerations of
the web itself would hold at least equal weight as the interests of Microsoft
and Netscape.  If *more* weight, that would be the real miracle. :)

It sure seems that the CSS part of BECSS is a short term hack that sounds OK on
the surface, but will prove as bad an idea as FONT was to markup.

/Jelks

Received on Thursday, 30 September 1999 04:01:50 UTC