A user account is required in order to edit this wiki, but we've had to disable public user registrations due to spam.

To request an account, ask an autoconfirmed user on IRC (such as one of these permanent autoconfirmed members).

Difference between revisions of "Bad Ideas"

From WHATWG Wiki
Jump to: navigation, search
(Start a list of bad ideas)
(No difference)

Revision as of 14:30, 4 June 2012

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 style by doing partial updates if the style system have 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.
  • 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.