- From: Tantek Çelik <tantek@cs.stanford.edu>
- Date: Thu, 30 Oct 2003 04:05:22 -0800
- To: Daniel Glazman <daniel@glazman.org>, <www-style@w3.org>
On 10/30/03 3:17 AM, "Daniel Glazman" <danielglazman@easyconnect.fr> wrote: > > 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. Nope. 'content' is still just appearance. >> 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. Disagreed. Try turning off javascript. The surprising majority of the web works just fine. Sure there are sites which are more like programs than documents which may not function, but they are typically self-contained applications and services rather than any kind of connected node in the Web. > And only a few people, > we know one very well, completely disable JavaScript browsing the Web. I am very close to disabling javascript for internet sites (while still allowing it for "local content" which i have control over). > I > think the %age of average people - readers of this list are *NOT* average > people - disabling JavaScript is infinitesimal. False. As Dylan provided - 10%. That is not infinitesimal. More people have javascript disabled than use mozilla for example. >> 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. You are fooling yourself. Please read this interview with Tim Berners-Lee in plain English: http://www.guardian.co.uk/online/story/0,3605,1048691,00.html Note the end of the interview: " From the beginning of programming, there have been programs and data. They are distinct. A picture is data while a script is a program. Scripts and programs are dangerous. Pictures are not. " That pretty much sums up what I've been stating in this thread. Continued: " Email software [really, any software that consumes web content] should enable people to clearly distinguish between things that are safe and unsafe. It should not allow them to run programs without jumping through hoops. It should not store them on the machine as runable programs - just fixing that hole will make a huge difference to virus propagation, if not eliminate it. " So I'm not the only that sees a hole. >> 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. The mistake was supporting javascript: urls within the context of CSS. Fortunately there is an easy workaround - turn off javascript. >>> 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? Why bother writing more than one HTML page on a site? Why not put all your HTML into one file? I have also had this same discussion many years ago and at the time I was on the other side. I was worried that authors would simply use "behavior sheets" rather than "style sheets" and thus we would end up in the same situation. I no longer believe that. It is worth it for safety and for user choice to separate the programs from the data. This is what years of experience has taught us. >> 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. Dylan *agreed* with me. 10% is a very significant number. >> 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. Next big thing that requires tons of client side testing unless you are authoring for a single browser which is of course a bad thing to do. >> 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. No, I see it slowly leaking, and you propose adding more holes so that it leaks much more and say well it was leaking anyway what's the difference? > The 'binding' property available *in CSS* adds another level of power, another > level of > control, another layer of extensibility on the Web. No argument there - it can be very useful, especially in vertical/intranet environments. I just think it should be separated from the stylistic and declarative data on the Web and placed on its own. >>> 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. Why? What's wrong with CSS saying no embedded procedural protocols? Just saying you disagree says nothing unless you give a reason. Saying it would be an enormous mistake is only a tautology - you are only repeating yourself with different words. >> 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. I think it is far *more* pragmatic to separate programs from data. People are tired of scripts running amuck in their software. We must address that reality. Tantek
Received on Thursday, 30 October 2003 07:01:14 UTC