Re: CSS 4?

On 10/30/03 1:47 AM, "Ian Hickson" <ian@hixie.ch> wrote:

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

In IE5.x/Mac, go to Preferences, select Web Content, uncheck "Show style
sheets".


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

Your statement assumes that Javascript placed outside of CSS *MUST* be
disabled by disabling author styles.  This is a false assumption as a simple
solution which is already widely implemented is a separate preference for
scripting.

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


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

Because CSS is known as something declarative, relatively safe, and having
to do for the most part with just the appearance of the document.  This is
common sense experience -- no need to pretend to be ignorant about it in
order to attempt to demonstrate an artificially extreme point of view.


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

CSS itself is safe.

This is very simply demonstrated.

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

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

Javascript by itself is unsafe.  This has been demonstrated through
javascript only exploits on the Web.

CSS by itself (e.g. without any embedded javascript) is safe.  If you mix it
with javascript which is unsafe, you end up with a result that is unsafe
which is all that your example demonstrates.

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


> Indeed it's even easier in IE:
> 
>  p { width: expression(alert('Hello!\ \(width\)')); }

IE/Mac does not support the "expression" proposed property (and never will).

Expression is merely another hook for javascript.  Thus again, the addition
of something unsafe (javascript) of course makes something that was safe,
then unsafe.


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

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


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

IE/Mac does not support any BECSS-like system (and never will).


> In conclusion, I think there is ample evidence that we crossed the
> "unsafe" line for CSS many years ago.

And now having learned that lesson, perhaps it is time that we retreat back
over that line.


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

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.

Then a user could simply choose to turn off ALL behavior sheets in their
preferences rather than have to fiddle with some number of properties (which
could increase in the future) in their user behavior sheet.


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

That is contrary to what I have seen.  More and more people are turning off
javascript by default in their browsers due to all the security problems and
annoying behaviors (e.g. pop-ups etc.).

In fact, enough folks are turning off javascript that if you are doing web
development, clientside scripting is a bad idea to reach the broadest set of
clients.  Better to keep all the procedural/scripting elements on the server
(where you also don't have to test numerous versions of different browsers
to make sure your script works in all of them.)



> On Wed, 29 Oct 2003, Tantek [ISO-8859-1] ?lik 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,

Yes, it adds yet another hole.

> but that is already possible using the various properties that take url()
> values, e.g. 'content'.

It is good to point this out so we can fix it.

See above proposal for restricting url() within CSS to declarative
(non-procedural) protocols.


> And of course there is the point I mentioned above, namely that some
> vendors already support embedding javascript straight into the CSS sheet
> today,

We should explicitly disallow it and ask that vendors follow suit.

> using text/css (actually, in the case of most vendors, the MIME
> type isn't checked at all).

Newer user agents treat the MIME type more strictly.


>> 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 which
typical users never visit.


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

My straw proposal was a "procedure sheet" or "behavior sheet" sent as
'application/css' where the "css" simply indicates the syntax.  Of course
one could follow the +xml convention pattern and use something like
'application/bs+css'.


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

And such behaviors or bindings should be relegated to a separate file with
its own MIME type that makes it clear that it is procedural (and thus
significantly less safe) in nature.

Tantek

Received on Thursday, 30 October 2003 05:49:09 UTC