On Tue, Aug 12, 2014 at 10:27 AM, Christoph Martens <cmarten...@gmail.com> wrote: > I think I have pretty much the same view as Andrea. > > Back then, the w3c discussions about HTML5 were pretty much the same. > > On one side, they introduced an all-new invalid-to-old-browsers doctype > (<!doctype html>)
<!doctype html> was "invalid" per spec, but accepted by all browsers as valid. It was the minimum sigil that was accepted by existing browsers and produced standards-mode. It was not an innovation that took any time to adapt to. > which was SGML based and not valid against any xml-based > schema validator. No major browser has ever been SGML-based or used an XML schema validator in any capacity, so this is irrelevant. > There was a huge discussion about the quirks mode > behaviours, but from my view it was the ideal chance to make a cut to the > old shitty APIs. As this was the single dependency for new html5 modes > inside browsers (that were later on introduced in all browsers), it was also > the ideal place to make a cut. > > If they would've decided to deprecate <marquee> and all that shit, They did deprecate <marquee>. It's still required to be supported, as it's used on the web, but it's not valid for authors to use. A number of other old features are treated the same. > we now > would have a better DOM, Deprecating <marquee> would have no real effect on the DOM. It's just one self-contained interface; it doesn't affect anything else. There are some improvements that would have made the DOM much better, but they're less obvious (like killing document.write, for example). > a better BOM ??? > and a better markup in the first > place. But the reason for not breaking it was "what happens with old IE that > doesn't know HTML5 doctype" question. And all other old browsers. > I mean, seriously? Is a crappy old software a valid reason for preventing an > evolution of a specification or language? Should it be that way? I think > not. Regardless of what's valid for new things in the future, old things still exist, and there are a LOT of old things. That means you have to support the old things *as well as* the new things; all those deprecated things still have to sit in your code if you want to render the old things correctly. The cost of making an incompatible version is that you now have to maintain two code branches, one for the old stuff and one for the new stuff, and keep them synchronized for security fixes and the like. It's rarely worth the benefit. > On the other hand, I think the idea behind IE's different engine modes were > a genius idea to fix the legacy problem. But the implementation and usage > was a hard fail. Decisions like "all websites from a local area network are > served by MS exchange anyways" is like totally idiotic. IE is handicapped by their decision; they have to send 6 or so rendering engines in their browser now, or spend time emulating an older rendering engine in a newer one, reproducing its bugs and quirks as well as they can. > If you need traceur or typescript in order to "really use" ES6 nowadays, I > see it as a design flaw in the language. Of course, it is hard to locate the > problems, but I think with a modular system like in OpenGL extensions, we > may have a valid solution for it. The "nowadays" you mention doesn't mean "now, and forevermore", it's "now, and for a short time as support catches up to the new features". ~TJ _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
