RE: New Working Draft : BECSS

Jelks Cabaniss [mailto:jelks@jelks.nu] wrote:
>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. ...

The appearance of bathroom examples in any discussion is a sure sign the
discussion is not headed in a positive direction.

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

There are quite a few problems with using BECSS as a separate linking
mechanism.  The first, of course, is that there is NO standard provision for
linking them into the document.  We would, in essence, end up having to use
the LINK REL=STYLESHEET and embedded STYLE elements to link these in - or
come up with some new elements, which is a difficult thing to do at this
stage with any hope of interoperability.  Creating a new MIME type is the
least of those worries.

In addition, implementation experience with how designers and authors use
CSS teaches us that web sites are commonly developed with separate content
and presentation - and part of that presentation is interactivity, and
designers would like to design their presentation at one pass, not two.  The
approach we've taken does not exclude those who wish these to be separate
(such as yourself) from making them so.

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

If you choose to use HTCs, that's true - but you'll also note that HTCs are
fairly heavy-weight, and intended for implementing presentational
components, which are really best if they can be componentized and kept in
independent modules.  HTCs are totally document-independent, reusable
modules - the BECSS stuff is not necessarily document-independent at all
(although it can be - just like a CSS stylesheet can be, but often isn't).
The event handling part of BECSS is lighter-weight, and is embedded
directly.

Come on, you really can't use the argument that you want style and
interactivity in separate documents, and then say we're making the wrong
decision by componentizing.

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

Now that's a cry of "Wolf! Wolf!" if I ever heard one.

-Chris Wilson

Received on Thursday, 30 September 1999 13:14:56 UTC