Re: CSS 4?

Ian Hickson 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, 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?

The point is that it makes it more difficult for the end user to figure 
out how to prevent the annoying behavior, not whether or not you can 
disable it by disabling css.

I know people who still think of Java as slow or bad because Netscape 4 
used to display the infamous loading Java message whenever it would load 
the VM... not that people will ever know what css is unless is annoys them.

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

Yet another reason to not use IE :)

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

Is that the criteria for whether something should become a standard? :)

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

Except that xbl allows non stylistic script to be bound through a 
binding.  Most annoying authors aren't going to follow the official way 
of doing things.

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

Which is perhaps how some user agents might implement the mechanism for 
disabling behaviors.

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

Last I checked the total was greater than 10% for browsers without 
JavaScript support... I'm not sure what percentage of this was browsers 
without JavaScript, and what percentage was browsers with JavaScript 
disabled, but 0-2% of total users seems within the limits of a 
reasonable guess.

Browsers usually provide controls only after the annoyance bothers 
enough people.  I'm sure that in a year or two most sites that insist on 
continuing to use popup ads will switch to using positioned elements, 
and then we will see a way to disable positioned "popups", and then 
they'll switch to using a div with content and then we'll see a way to 
block that, etc.

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

Right.  Besides being curious, I was looking to see how else selectors 
were being used as possible inspiration for a better binding mechanism.

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

I think we've seen very little "in the wild" use so far because neither 
implementation is a standard.  Just look at the rapid pace of creative 
css innovations in the past year or two now that there are a number of 
implementations where css works fairly well.  One misuse of xbl and htc 
is using them in place of browser sniffing or object detection [1] for 
different implementations of XMLHttpRequest in IE and mozilla.

[1] http://www.pbwizard.com/Articles/DownloadDoc.htm

Received on Thursday, 30 October 2003 05:50:33 UTC