Stop Standardizing HTML 302
pfignaux writes with an interesting view on the place of centralized standardization in modern browsers. From the article: "When HTML first appeared, it offered a coherent if limited vocabulary for sharing content on the newly created World Wide Web. Today, after HTML has handed off most of its actual work to other specifications, it's time to stop worrying about this central core and let developers choose their own markup vocabularies and processing."
Instead, the author proposes that CSS, Javascript+DOM, the W3C's accessibility framework, and Web Components are sufficient to implement the rendering of smaller, domain-specific markups.
HTML isn't anymore (Score:2, Interesting)
What was once a standard for rendering text and images together in a single document has suffered from severe scope creep over the years. With the addition of multimedia, HTML crossed the line from static to active content markup, which in my opinion defeated its original purpose. HTML needs an active companion language, an actual programming language, one that will replace the disparate third-party technologies in use today. Just eliminating Flash and Javascript for example would eliminate a vast majority of the world's browsing headaches.
We are so close to a Web-based operating system I can taste it.
Extending the DOM; WAI-ARIA in search engines (Score:4, Interesting)
"Instead, the author proposes that CSS, Javascript+DOM, the W3C's accessibility framework, and Web Components are sufficient to implement the rendering of smaller, domain-specific markups."
In other words, implement everything new as polyfills [wikipedia.org]. But how would one have implemented new HTML5 features, such as the 2D Canvas, WebGL, and the video tag as polyfills? Even if one doesn't standardize new extensions to HTML markup, one still needs to standardize new extensions to the DOM. In addition, no new elements means that user agents that do not process script or WAI-ARIA, such as robots used by search engines, won't be able to make sense of pages. Do any current web search engines process WAI-ARIA?
Re:HTML isn't anymore (Score:5, Interesting)
You ask for a companion programming language and at the same time propose eliminating Javascript. I see a contradiction in there.
Re:Extending the DOM; WAI-ARIA in search engines (Score:5, Interesting)
The author's proposal sounds suspiciously like he has fallen for the seductive path of elegant generalizations(that are too theoretical for the ugly details to yet be visible) instead of confronting the ugly details that our current attempt at standardization has made visible...
To be sure, the sausage-by-comittee that tends to result when you try to standardize something is quite ugly and takes ages to settle down; but if the proposal is "Just let people use whatever shims they want for everything" you haven't really solved the problem, just comitted yourself to standardizing a suitably powerful interface for the shims to sit on, along with giant piles of shim-dependent code that crawlers and any other applications that break the shims' assumptions won't be able to make the slightest sense of.
Heck, for maximum elegance in the core standards, we could just replace virtually everything with the "Object" tag, and let people embed whatever they want, or abandon this 'HTML' nonsense entirely and just make Native Client [google.com] the standard, freeing developers to implement pretty much any conceivable structure, from a legacy browser engine, to a Flash client, to a TECO interpreter built entirely out of Minecraft redstone logic, as the shim for their 'site'. A glorious age of unfettered freedom!
Re:HTML isn't anymore (Score:3, Interesting)
So is lambda calculus. There's more than a passing simularity there, too.
HTML5 is a design by committee failure (Score:5, Interesting)
"Pave the cowpaths" is an excuse to appease a bunch of zealots that are hellbent on pushing their personal preferences and egos into a standard rather than designing something that is quick/easy to parse and universally render across platforms. It's only going to get worse as the standard is never completed over the next decade.
XML serialization of HTML sucks. It's verbose, and it's ugly. But it's effective because it's well defined and it leaves very little room for interpretation.
Honestly, I'd like to see two standards. One, is XHTML5 Strict that follows the XML serialization. This will be left to the big boys who have real work to do. The other standard would be an extension to MarkDown to allow CSS customization with classes and ids. This would allow the path the cowpaths crowd to get things down as fast as possible and keep the verbosity of XML out of their way.
Comment removed (Score:4, Interesting)
Stop Standardizing HTML Badly (Score:4, Interesting)
HTML5 is riddled with faulty logic, flawed reasoning, and bad semantics. Even reading the spec gives the impression that the writing is of lesser quality than pervious versions. Why this is the case after 9 years completely baffles me.
Selected points:
Last but not least: enough with the XML hatred. XHTML5, with proper XML syntax, should be the focus instead of an afterthought. XML syntax compliance isn't that hard or time consuming. Markup languages are for machine consumption, not human readability. Not requiring tags to be closed, bare unary attributes (ie, checked instead of checked="checked") and all the other shortcuts are asinine and only foster laziness and sloppiness... which would not be tolerated in any compiled or interpreted language.