Re: CSS 4?

Tantek Çelik wrote:

> 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

I disagree with that. The way we extend the 'content' property goes FAR beyond
the appearance of the document. Please note that I don't disagree with it. I
originally proposed that change long before you joined the CSS WG.

> CSS itself is safe.

You said 'relatively safe' above :-)

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

Does not cancel the fact that the Web without JavaScript (please note the
capital S everyone always forgets) won't be the Web. And only a few people,
we know one very well, completely disable JavaScript browsing the Web. I
think the %age of average people - readers of this list are *NOT* average
people - disabling JavaScript is infinitesimal.

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

This is a false argument, comprehensible by geeks like us. Tell that to your
marketing department just to see how they react.
The addition of an unsafe element does not reduce the intrinsic interest of
the global thing, Tantek. The intrinsic interest of the total can be, even
with a slightly increased safety risk, so much increased it's worth doing it.
We live in a pragmatical world.

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

The spec is. But implementations are done by human beings. Human beings make
mistakes.

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

Chris Wilson, Vidur Apparao and I, sometimes with Chris Lilley, had this
exact discussion a dozen of times. The most important argument I can easily
remember was the following one : same general syntax, same grammar, why the
hell do you want to force authors to edit two different objects?
There is no reasonable answer to this question. Listen to your common sense,
and you'll see there is no reason why an authour should have to write the
same selector twice for two different properties.

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

I am totally with Dylan here and think you are totally wrong.

> 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

Client side scripting is a so bad idea that client side web services based on
scripting are going to be the next big thing in our world.

> Yes, it adds yet another hole.

This is like having a 1 liter bottle with .5 liter of water. Half empty
or half full? I see it half full, you see it half empty.

The 'binding' property available *in CSS* adds another level of power, another level of
control, another layer of extensibility on the Web.

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

No, CSS should not deal with the contents of URIs, sorry. I strongly
disagree with you here and think it would be an enormous mistake.

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

Even with the best good will of the world backing this opinion, it's still
a mistake from a pragmatical point of view.

</Daniel>

Received on Thursday, 30 October 2003 06:17:47 UTC