Re: CSS 4?

*Tantek Çelik*:
> On 10/30/03 1:47 AM, "Ian Hickson" <ian@hixie.ch> wrote:
>
> In IE5.x/Mac, go to Preferences, select Web Content, uncheck "Show
> style sheets".

Is it really called that way? I would expect "Use style sheets", "Use CSS",
"[ ] Style sheets" or the like.

> E.g. in IE5.x/Mac, same place as above, uncheck "Enable scripting"

  [ ] Enable Foo

is bad UI practice either, not only because of the different naming scheme.
But that only as an off-topic side note.

> CSS itself is safe.

I tend to agree, although there are valid privacy concerns.

>>  body { background: url("javascript:alert(\'Hello\ again!\
(background)\')");}
>> ...is possible right now, and shows a dialog in at least two browsers.

A URI protocol "javascript" isn't defined anywhere official, though.

> If you take something which is safe, mix it with something that is
> unsafe, you end up with a result that is unsafe.

Agreed.

> Javascript by itself is unsafe.

Rather not, it's more the implementations that are unsafe, assuming the common
denominator of JavaScript and JScript: ECMAScript. However, that makes it
"unsafe in practice".

> I for one would very much like to see procedural protocols like
> javascript: excluded from the URI type in CSS.

As "javascript:" is not a valid protocol at all, it is thereby automatically
excluded. IMVHO.
What about "url(http://example.com/evilscript.js)"?

> No Ian, your proof is false as demonstrated above.  CSS without
> javascript is safe.

It's of course not only JavaScript that could be executed after being
referenced with url() and thus make the file unsafe.

> IE/Mac does not support [...] (and never will).

Easy claim. ;)

>> BECSS is not going to be changing that. Indeed, by giving authors
>> an official way of marking script as stylistic,

Which they undoubtfully will abuse.

> All of these advantages (and more) could also be achieved by isolating
> procedural/DOM/BECSS type functionality into a "behavior sheet" that
> was sent as "application/css" to indicate it's procedural/behavioral nature.

OTOH that would remove some of the possibilities the cascade offers and
increase the number of files and data to download.

>> JavaScript isn't disabled in a significant percentage of browsers,

That depends on your definition of "significiant". For some people 1% is, for
others 10% is not significiant--also differing from subject to subject.

> clientside scripting is a bad idea to reach the broadest set of clients.

It's fine for anything optional, only wastes bandwidth.

>>> I think a major component of this perceived safety is the
>>> purely declarative nature (e.g. nothing procedural) of CSS.
>>
>> While this is true on paper, it isn't true in reality. CSS today,
>> as implemented, can host emdedded procedural scripts.
>
> It is effectively true in reality because such embedded procedural
> scripts are absent from real-world CSS except for the rarest test pages

I'm constantly surprised that e.g. expression() isn't used more for bug
work-arounds, instead there's selector and comment hackery. I've neither seen
url() abused for user tracking etc. -- yet.

>>> While behavior may be presentational (Ian's litmus test is a good
>>> one), it is not clear to me that CSS by itself should attempt to solve
>>> all presentational problems.
>>
>> That begs the question, "where else would it be?".
>
> Optimally - in a different working group.

SVG-CSS shows what bad side-effects that may have.

>> most HTC behaviours or XBL bindings I have seen in the wild basically
>> consist of toggling some CSS properties based on DOM events, with
>> the script just being glue code to do something that can't be expressed
>> in CSS, and is not common enough to warrant its own CSS extensions.

Or to rebuild something that the HTC/XBL enabled browser doesn't support out
of the box.

Received on Monday, 3 November 2003 10:03:40 UTC