Re: CSS 4?

On Wed, 29 Oct 2003, Dylan Schiemann wrote:
>
> Say you're a somewhat technically inclined end user and you visit a page
> that has an annoying behavior that is caused by JavaScript added through
> xbl.  A simple view source of the document shows only an html document
> with a style sheet link.  The end user turns off css in their browser
> and the annoying behavior goes away.  Hence they now think that css is
> "at fault" for this, rather than JavaScript or xbl.

I'm only aware of one UA in which CSS can be disabled, and in that UA, you
would simply hit Ctrl-G ("user mode") when you reach the site, which would
disable all the author's styles, whether annoying colours (very common at
the moment) or annoying JavaScript (less common with the advent of popup
blocking, prefs to block raise/lower/status changes, etc).

If you force the relevant JavaScript to be placed _outside_ the CSS, then
you can no longer disable it by disabling author styles.

So I don't really see your point.

Why does it matter that they think CSS (or more likely, "the author's
styles") are the problem, rather than DOM, ECMAScript, or XBL?


>> Selectors, like XPath, can be used for anything.
>> text/css, on the other hand, should only be used for styling.
>
> So presumably other purposes can defined their own text/foo, and DOM 3
> CSS could have a getElementsBySelector interface.

Yup.


> Whether it is true or not, css is generally perceiveded to be "safe".

It's not.

   body { background: url("javascript:alert(\'Hello\ again!\ (background)\')"); }

...is possible right now, and shows a dialog in at least two browsers.

Indeed it's even easier in IE:

   p { width: expression(alert('Hello!\ \(width\)')); }

...and that pops up several dialogs on each paint, almost.

See: http://junkyard.damowmow.com/85

So no, CSS isn't safe. Anybody who thinks it is is unfortunately deluding
themselves (and if they are therefore allowing CSS through un-parsed, this
could be very dangerous in, e.g., webmail environments).

This has, indeed, been the subject of several security bulletins recently.

And of course both Mozilla and IE already support BECSS-like systems, and
have done for years.

In conclusion, I think there is ample evidence that we crossed the
"unsafe" line for CSS many years ago. BECSS is not going to be changing
that. Indeed, by giving authors an official way of marking script as
stylistic, you make it easier for users to disable all annoyances in one
go on a per-page basis.

BECSS has one additional advantage, which is that it allows one to write a
very simple style rule:

   * { binding: none ! important; }

...and instantly disable all of BECSS.


> I'd hate to see css be thought of like JavaScript and disabled in a
> significant percentage of browsers.

JavaScript isn't disabled in a significant percentage of browsers, but
even if it was, that would continue to be the way to disable those kinds
of annoyances. In practice, modern browsers provide controls to disable
specific features of DOM0 that were abused. This would continue to work
with BECSS.


>> Selectors can be used whenever you want a selection language, much like
>> XPath (although they serve subtly different, albeit overlapping, roles).
>
> Are there any known implementations?

You mean apart from the CSS rendering browsers and the STTS
implementations? I don't know of any, but there probably are some.


On Wed, 29 Oct 2003, Tantek [ISO-8859-1] Çelik wrote:
> On 10/29/03 2:34 PM, "Dylan Schiemann" <dylans@yahoo.com> wrote:
>>> text/css, on the other hand, should only be used for styling.
>>
>> So presumably other purposes can defined their own text/foo , and DOM 3
>> CSS could have a getElementsBySelector interface.
>
> Or perhaps something which used CSS for such procedural applications could
> use application/css instead.

Indeed.

Note that BECSS doesn't add procedural applications to CSS. It adds
another mechanism to link to an XML language that may contain scripting,
but that is already possible using the various properties that take url()
values, e.g. 'content'.

And of course there is the point I mentioned above, namely that some
vendors already support embedding javascript straight into the CSS sheet
today, using text/css (actually, in the case of most vendors, the MIME
type isn't checked at all).


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


> 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?". The look and feel of
the document are intrically linked -- 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.

-- 
Ian Hickson                                      )\._.,--....,'``.    fL
U+1047E                                         /,   _.. \   _\  ;`._ ,.
http://index.hixie.ch/                         `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 30 October 2003 04:48:00 UTC