Bad Ideas

The purpose of this page is to collect explanations why commonly-proposed bad ideas for the Web are bad, so that they don't need to be explained over and over again.

It should be possible to escape from CSS to a Turing-complete language like JS

This would introduce at least one of these problems:

• Styling couldn't be applied incrementally if the styling program needs to run from start to finish with the entire document has its input. XSLT suffers from this problem.

• Content changes couldn't be efficiently reflected in layout by doing partial updates if the style system had to analyze a Turing-complete program to see if it affects the styling of a particular subtree.

• If the Turing-complete language allowed side effects, the style system couldn't decide when to re-resolve styles. Instead, style re-resolution times would have to be specified in the standard in order to get interoperable side effects.

• Even now, some oft-requested selectors aren't supported due to time-complexity issues. It would be hard to curb bad time-complexity if arbitrary programs were allowed to run as part of styling.

• The environment in which the Turing-complete language program with run would have to be specified and would constrain the implementation of the style system.

Browsers should accept byte code from the network instead of other languages having to be compiled into JS

• It turns out that JavaScript parsers have better time complexity characteristics than e.g. the Java byte code verifier. Checking that a program represented in low-level byte code doesn't do prohibited things is harder than seeing that higher-level representation stays within the constraints posed to it.

• JS is already supported, so compiling to JS enjoys better benefits from network effects that launching a new byte code.

• Using gzip compression on JS produces an already supported binary representation of JS.