Finally We Get New Elements In HTML 5

An anonymous reader writes "Pure HTML enhancements hardly grew at all in the last eight years. Forward motion basically stopped in 1999 with HTML 4. Now the future looks bright. Recently, HTML has come back to life with HTML 5. Tons of new elements will be available for structure (article, nav, section, etc.), block semantic elements (aside, figure, dialog), and several other functions."

Comments

Re:Excellent!

[LighterShadeOfBlack]

The idea is that an "article" is semantically different from other text. It's all well and good styling your text with <span class="header">, <span class="emphasis">, <span class="cite"> etc. to make your text look good on your webpage but that's no good for a computer that's trying to interpret your text in a meaningful way. By using semantic tags it should mean computers can do more in terms of searching and indexing the web to allow all of us to find what we want faster.

Re:Excellent!

[peter_gzowski]

Well, I would have preferred HTML 5 to add things that I could use (perhaps an include or multi-file-select), but I think the answer to your question is: readability. The div's can nest up to the point that you forget what the is paired with. I end up writing XHTML like this:

<div id="foo">
    <div id="bar">
        <div id="baz">
... lots of stuff ...
        </div> <!-- End of "baz" -->
    </div> <!-- End of "bar" -->
</div> <!-- End of "foo" -->

If what I'm using to id my div's is actually a common semantic, then maybe it should have its own tag.

XHTML/HTML divergence

[Animats]

What's wierd about this is that it goes off in a completely different direction than XHTML. Tags don't have to be properly closed, no namespaces, etc.

A big advantage of XHTML was that the conversion to a parse tree was unambiguous. Why give up that at this late date? All this ambiguity breaks visual HTML editors. Dreamweaver 3 was closer to "what you see is what you get" than today's Dreamweaver 8.

Consider, for example, a lone </br> that doesn't terminate anything. Most browsers today treat that as a valid break, not an orphan tag to be ignored. XHTML was supposed to end that kind of nonsense.

The problem with XHTML has been that CSS layout was badly designed. "float" and "clear" just aren't a good set of layout primitives. Cell-based layout (yes, "tables") was a fundamentally more powerful concept. But it's not XHTML that's the problem. It's that the positioning mechanisms for "div" sections are terrible.

Layout is really a 2D constraint problem. Internally, you have constraints like "boxes can't overlap", which turns into constraints like "upper left corner of box B must be below lower left corner of box A", or "right edge of box A and left edge of box B must have same X coordinate". Browsers really ought to do layout that way. Table layout engines come close to doing that. At least with tables you never get text on top of other text. "div" doesn't have comparable power. "float" and "clear" represent a one-dimensional model of layout, and that's just not good enough.

Re:Excellent!

[patman600]

Because there is no standard. You could have

<div class="article"> or <div class="main texty stuff">

. If there is a standard, then things like screen readers will easily be able to divide the article text from a navigation section. Imagine telling your computer to read you the article, and not having to wait for it to work it's way past the navigation bar. Or skipping back to the nav bar if you are tired of the article half way through.

Re:Excellent!

[rhartness]

No, they shouldn't because it would be a waste of time. No web designer in their right mind would mark any thing as an object because, sure enough, as soon as it's implemented in an HTML spec, some one out there will right a plug-in to hide those elements.

Web developers want their ads to be seen. They aren't going to make it easy for those ads to be blocked.

Re:Excellent!

[Bogtha]

Microformats are a good solution where a problem is domain-specific. HTML is extensible with mechanisms like the class attribute so that HTML doesn't have to include lots of element types that aren't useful to most people.

But when something is applicable to a wide variety of situations, the right place for it is in the HTML specification, not as an ad-hoc extension. Otherwise, you could just make the argument for every element type under the sun being replaced with <div class="..."> or <span class="..."> . At that point, you're just using the class attribute as a bodge to avoid new element types, not because it's a good idea.

Yeah, sure, it's nice that browsers don't have to be updated for microformats to work. But that doesn't mean it's good design to try to stuff everything under the sun into the class attribute. Sometimes the right place for something is in the HTML specification.

Re:Excellent!

[Xtravar]

And so how do advertising campaigns fit into this wondrous new paradigm where web developers supposedly have the competence and ethics to only put an article in an article tag?

The fact of the matter is, nobody will use the damn tags correctly and then a screen reader will read a paragraph on Viagra before actually getting to content.

More bastardization of already bastardized HTML... and even more new ways to fuck things up.