Slashdot Mirror

← Back to Stories (view on slashdot.org)

Stop Standardizing HTML

Posted by Unknown on from the remember-xhtml-2.0 dept.

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.

8 of 302 comments (clear)

  1. HTML isn't anymore by Anonymous Coward · · 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.

    1. Re:HTML isn't anymore by Lord+Lode · · Score: 4, Interesting

      You ask for a companion programming language and at the same time propose eliminating Javascript. I see a contradiction in there.

    2. Re:HTML isn't anymore by SuricouRaven · · Score: 2, Interesting

      So is lambda calculus. There's more than a passing simularity there, too.

  2. Extending the DOM; WAI-ARIA in search engines by tepples · · Score: 3, 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. 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?

    1. Re:Extending the DOM; WAI-ARIA in search engines by fuzzyfuzzyfungus · · Score: 4, 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 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!

  3. HTML5 is a design by committee failure by exabrial · · Score: 4, Interesting

    HTML5 is the response by a bunch of whiners that normal xhtml is "too hard." Yes it's too hard to remember to close your tags. It's too hard to remember to put quotes around attributes. Why are humans checking your syntax? Have the danged computer check your syntax.

    "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.

  4. Re:Nope by cjjjer · · Score: 3, Interesting

    Since Google is forking Webkit I suspect that they will be doing the same thing in the near future or have not already to make their services work better in the browser.

  5. Stop Standardizing HTML Badly by Dracos · · Score: 3, 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:

    • The b and i elements are presentational, no matter how the authors try to claim otherwise. Let them stay dead.
    • Sectioning is a mess, and whether related elements are sections is dependent on context. "Strongly Suggesting" that developers use h1 for every headline within sectioned content dilutes its semantic value. Just create a level-less h element, like XHTML2 did, that inherits its level based on depth and context.
    • There is still no way to clearly associate dd elements with their dt. Wrapping these sets with li would fix this.

    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.