Re: Behavior, scripts, CSS

Delurking...

I concur with Simon on this. XSLT will not be an adequate client side
solution for many years to come yet, and I see most of the vendors reaching
that same conclusions ... hence the adoption of server side orientations
(whether called .NET or anything else, this is more a capitulation about the
fragmentation of the client than anything).

To me the most ideal solution would be one in which a CSS behavior
implementation defined an interface mechanism, and only an interface
mechanism. It could be consistent with ECMAScript, it could be XML based, it
could be Java centric, hell, it could be COM based, for that  matter
(shudder), but the  important thing is that such a mechanism place a clear
boundary between the interfaces and some XML substructure that contains
implementation details (a <script> block, for instance, that includes
language, an id, and deployment information). By clearly defining the
interface structures so that they are language neutral, you could
conceivably have multiple implementations of the same behavior script.

I worked fairly extensively with IE5 behaviors (and prior to that IE4
scriptlets) while they were being developed, and to me they suffered from a
number of limitations, not least of which being that they were reloaded for
every instance of that scriptlet and that they were XML-like, but not
strictly conformant. I think that the link between CSS and XML should be
strengthened at the borders that behaviors represent. They ARE a powerful
mechanism for encapsulating functionality, encourage the creation of code
libraries and code reuse, and they solve a problem that I see emergent with
server side development -- the tendency to encapsulate scripting code within
XSLT bodies, as part of templates, making modularization just that much
harder to achieve.

-- Kurt Cagle

----- Original Message -----
From: "Simon St.Laurent" <simonstl@simonstl.com>
To: <www-style@w3.org>
Sent: Thursday, August 03, 2000 3:38 PM
Subject: Behavior, scripts, CSS


> At 02:36 PM 8/3/00 -0400, Jelks Cabaniss wrote:
> >This is another good reason why the 'E' of BECSS should be dropped.  Do
> >"behaviors" in CSS syntax if you will, but as a *separate* entity.
Script
> does
> >not belong inside CSS, no matter how convenient in might be to script
> kiddies or
> >mass-market UA vendors wishing to avoid MIME issues.
>
> I seem to be the only here who feels this way, but I think this is putting
> our heads in the sand.  There's an enormous amount of work to be done,
> especially with XML vocabularies (and XHTML modules containing those) that
> requires more than formatting but less than custom application
development.
>
> ActiveX controls let you format your hard drive from any script - this
> isn't a hazard peculiar to including scripts in CSS.  If the script's not
> in a sandbox, of course there are potential disasters lurking.  That's the
> nature of programming, period.
>
> I'm not very happy with the current BECSS draft - section 3 should be
> gutted, since too many upcoming CSS application have nothing to do with
HTML.
>
> Styles already define behavior, and already provide a set of tools for
> attaching that behavior to document structures.  I don't think adding
> scripting to the behavioral mix is so awful.  In fact, I think it'll be
> necessary if CSS has any interested in supporting upcoming XML work,
> notably XLink.  I really _don't_ want to have to turn to XSLT for that
work.
>
> Script kiddies?  Maybe.  More realistically, XML developers trying to get
> real work done.
>
> Simon St.Laurent
> XML Elements of Style / XML: A Primer, 2nd Ed.
> http://www.simonstl.com - XML essays and books
>

Received on Thursday, 3 August 2000 19:26:14 UTC