Re: CSS 4?

On Thu, 30 Oct 2003, Tantek [ISO-8859-1] Çelik wrote:
>>
>> 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.

I'm not sure what you are arguing here, nor do I understand why you
think my statement assumes what you say it does. Could you expand on
this?


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

I don't see how this common belief answers my question.


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

Pure W3C CSS, when implemented in a vacuum, is currently purely
declarative, granted. It isn't "safe", though. At the simplest level,
it lets the author create unreadable pages, which are as much of an
annoyance as popups (this is what I believe Dylan meant by "safe" --
unable to create annoyances). On the other hand, if by "safe" you
meant "not a security or privacy risk", which I do not believe is what
Dylan meant by it, then pure W3C CSS is not safe either, since it
introduces known privacy leaks (e.g. the :link case).

And it is definitely not "safe" by a definiton that considers
scripting to be unsafe if you consider the real world, which includes,
as I have mentioned, expression(), javascript: URIs, and external
resources that contain script.

In any case, introducing "binding" as a way to bind a mixture of
declarative and procedural styles does not introduce scripting
straight into CSS. It is quite possible to use the XBL-like BECSS
proposal without scripting being enabled at all.

A clear statement of what exactly it is about BECSS proposals that you
dislike, and more importantly, why you think they are an issue, would
be very helpful, because I don't fully understand your position, which
makes it hard to tell if I agree or not.


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

What lesson have we learnt? That it is useful and can improve the
separation of presentation from semantics? Why would we want to walk
back over the line in that case?


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

How would this solve anything? Indeed, what is it even trying to
solve?

All I can see that doing is requiring significantly more effort for
authors, requiring longer load times, requiring more code in
implementations, requiring careful management of "look-and-feel"
cascading stylesheets and "look-only" cascading stylesheets so that
they both take part in alternate stylesheet switching, requiring that
authors once again petition their administrators to add more MIME
types to their servers, and so forth.


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

That's a straw man argument. The UA could always provide an option to
"turn off ALL behavior sheets".


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

I think there would be some _serious_ disagreement if the CSS working
group tried to suggest that the 'background' property must not be able
to refer to, e.g., SVG images.


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

As you represent the main vendor in question here, can you tell us
whether or not said vendor intends to follow suit if we do indeed
disallow it?


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

Which working group works on BECSS (or its successor) does not in any
way restrict what the technical solution will be, so that is an
unrelated process issue, IMHO.


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

Apart from the ivory-tower advantage of keeping pure W3C CSS arguably
clean of any sign of scripting, what does this gain us?

It certainly loses us a great deal, for implementors (extra
complexity), authors (the style has to be spread over even more
files), and users (longer load times, plus the increased chance that
either the user or the implementor has made a mistake due to the
greater complexity).


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

The bindings themselves _are_, in all BECSS proposals so far except
ActionSheets, relegated to separate resources. Only the mechanism that
binds the element to the binding is in CSS itself, and that mechanism
is as safe as existing mechanisms such as 'content' that can replace
elements with scripted documents in much the same way.


On Thu, 30 Oct 2003, Dylan Schiemann wrote:
>>
>> 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 don't see why. If the annoying behaviour is popups, you disable
popups. If the annoying behaviour is focus changes, you disable focus
changes. If the annoying behaviour is a combination of things, e.g.
the colours clash, the layout is ugly, or whatever, then you disable
all the author styles.

All that moving the annoyances to a mechanism controlled by CSS does
is make it easier for the user to just cut everything off.

Isn't that a good thing?


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

I was not using it as a criteria for standardisation. I was using it
to demonstrate that people who think BECSS would make CSS "unsafe" are
missing the point, because the equivalent of BECSS has already been
implemented, so CSS is already "unsafe" by that definition, and thus
can't be made any more "unsafe" by introducing BECSS.


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

Are there any annoying scripts that _aren't_ stylistic?

If your point is that annoying scripts won't use BECSS, then, how is
BECSS changing anything?

If your point is that annoying scripts _will_ use BECSS, even if they
aren't presentational (could you give an example?), then wouldn't
BECSS be _helping_ matters by making it easier to disable all the
annoyances at once?


------------------------------------------------------------------------

> Last I checked the total was greater than 10% for browsers without
> JavaScript support...

A surprisingly high number. Interesting.


On Thu, 30 Oct 2003, Tantek [ISO-8859-1] Çelik wrote:
>
> In IE5.x/Mac, go to Preferences, select Web Content, uncheck "Show
> style sheets".

Cool. Two UAs. :-)


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

As Daniel implied, if this is the case, then maybe some aspects of
Avalon need rethinking...

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

Received on Thursday, 30 October 2003 07:35:03 UTC