HTML5 must not become the future of the web
davidarno.org
davidarno.org
For example, the author suggests that separation of content from presentation using HTML and CSS is not possible because the <em> tag is presentational. On the contrary, emphasis is a semantic (in this instance).
The author claims HTML5 will take 12 years to become "fully adopted" when in fact it will be finalized in 2012 and actual production usage is exploding in growth.
HTML5 is apparently no good because it only adds "just a few tags".
HTML, CSS, and JS are best conceptualized as content, presentation, and behaviour, but the author attempts to fit them together as model, view, and controller.
JavaScript is, the author says, a "half-baked toy language that does not scale well" that can never be improved because it is served as source-code to the browser [?] and new versions must be backwards-compatible. Yes, backwards-compatibility slows adoption of updated standards. But, the suggested replacement is a "package-based" system (whatever that is) that can be "text or binary". How does that solve the problem?
[Edit: typo]
That's the point where I said this guy is an idiot. What exactly does emphasis look like? Bold and Italic are presentational, whereas <strong> and <em> are semantic.
There is a kernel of truth in there as I often wish CSS let arrange elements independent of the order they appear in the HTML doc.
...and that type of thing is probably the source of most of the discomfort that the author feels with the way browser separation of duties happens, even if he didn't express it very well: as general-purpose view frameworks go, CSS is an extraordinarily shitty specimen, completely unsuitable for many tasks - every time you've ever had to alter a line of HTML to make your layout work correctly, you've been staring straight at the heart of what is wrong with CSS. Many things that should be handled exclusively within view code (and would be in a sane project) end up leaking into many other parts of the system. And that's even before you start dealing with browser incompatibilities.
I'm not sure that there's any solution, though - yes, we all know it's a terrible setup, but none of us can do anything about it at this point, so we turn to libraries that try to shield us from the complexity. C'est la vie, this is what happens when things evolve naturally under changing needs over a long time...
This final sentence perfectly demonstrates the unfounded, poorly-written, wordy wishful thinking of the entire article. Don’t waste your time.
- - -
He also demonstrates an utter failure to grasp the HTML5 timeline, or why the DOM matters, or that his "alternative" is nothing more or less than requiring all browsers to support a theoretical open-source release of Java applets / Silverlight / Flash / similar.
From one of the author's comments: "I do not see the canvas tag and flash as doing essentially the same thing. Rendering text in a canvas tag would be an odd thing to do for example." Ah! Precisely: one would have to add a shiv to allow <canvas> text to be selected and copied, and it wouldn't quite work the same as it would on the rest of the page; text would be anti-aliased differently than system text; etc. Remind you of anything — Flash, perhaps? He's arguing against himself here.
> "There is an alternative to serving up source code that works well in a growing number of situations, eg the JVM, CLR..."
Really? I'm not sure how much more "big enterprise" we can get... and having been writing a lot of JS as of late, and a lot of past experience with C#... doing the things you do with jQuery et al using C# would be a gigantic pain in the ass and create a morass of completely incomprehensible, unmaintainable code.
I've noticed something in this great big Flash vs. the World debate - the only people defending Flash appear to be Flash developers, and the only real motivation I've seen in the defense of Flash is self-preservation...
Not that I'd start a new project in Flash/Flex, but let's be realistic here.
What JS + CSS + HTML5 are missing is the tools and frameworks that make Flex such a great development platform. The tools will come, and it will not take 12 years. Detractors love to scoff at that number, but we all know that we're never going to let it take even close to that long.
If I were Adobe I'd stop fighting it and start building those tools now.
http://techcrunch.com/2010/05/05/adobe-cto-kevin-lynch-were-...
He forgot that HTML5 now defines, in detail, error handling, and adds new APIs for interaction with javascript. Or maybe he's ignoring them. Doesn't sound like he much cares for javascript.
Wrong. This is what we Web Standards nerds are talking about when we say semantic markup. This is why we stress the use of <em> over <i>.
The <em> tag means emphasis. A word of importance that needs to be stressed. It has a default style that is italicized, in the same way that <ul>s have default list-style definitions. The <em> is easily styled through CSS just like any other tag.
Haha, ok.
Thank God because that was a trainwreck and I found my neck hurting after reading from all the head shaking I was doing...
There is a serious effort by Google http://news.ycombinator.com/item?id=1341340 to alleviate this issue. With NPAPI that allows plenty of access to the browser, instead of current plugin islands, NaCl could be an excellent option. Not to mention, NaCl has the performance of desktop apps, it erases web vs desktop differences.
Hopefully it will also erase browsers, just as browsers largely erased old operating systems.