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

Excellent!

[by Anonymous Coward]

More tags for browsers to neglect to implement!

On a slightly more serious note, it sounds like they're giving up on having most browsers support CSS styling of XML, and just adding new tags that serve no point other than being CSS targets. Semantically, what's the difference between:

<div class="article">...</div>

And:

<article>...</article>

Answer: Nothing. One is easier to type and less verbose, and the CSS selector rule saves a single character.

Re:Excellent!

[Conspiracy_Of_Doves (236787)]

The whole point of a semantic tag is that it is machine parsable. A script that is interpreting the page will know what parts of the page is the article, which parts are the navigation, which parts are the advertisements, and so on.

Actually, they need to put in an <ad> tag.

Re:Excellent!

[rhartness (993048)]

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!

[patman600 (669121)]

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!

[Xtravar (725372)]

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.

Re:Excellent!

[Bogtha (906264)]

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!

[LighterShadeOfBlack (1011407)]

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!

[LighterShadeOfBlack (1011407)]

Well that's not strictly true. The <article> element is for "a section of a page that consists of a composition that forms an independent part of a document, page, or site". An example where having that information available to a computer might be useful is in search results:

Imagine someone searches for radioactive horses, and Google has crawled two web pages which contain those two words, one in which both words occur within ordinary prose, the other in which each word occurs in separate sibling <article> elements. It could very well make sense to give the page with the <article> elements a lower precedence because from the semantic information we know that there's a good chance the two peices of text are independent of each other (ie. that there is no text about radioactive horses, just two different peices of text: one involving something radioactive and the other involving horses).

Of course this isn't the only way it might be helpful, that's just something off the top of my head. The point is that giving text some additional meaning does have benefits, even if they aren't always immediately clear.

Re:Excellent!

[peter_gzowski (465076)]

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.

Re:Excellent!

[corsec67 (627446)]

Apparently slashdot got rid of it for you...

Oh great...

[Bazman (4849)]

More things for IE to not support properly.

Still no <bgsound tune, repeat> ? ;-)

[D4C5CE (578304)]

The tag the world's been waiting for since 1994...
repeat:byte; 0 = ad nauseam
With MOD [wikipedia.org] support - of course!

The most greatly wanted tag

[by Anonymous Coward]

And, of course, the addition of the long overdue

<dupe>http://developers.slashdot.org/article.pl?si d=07/07/20/1226235</dupe>

tag.

Re:The most greatly wanted tag

[the_womble (580291)]

actually the most wanted tag is the irony tag.

The problem is that most people on /. will not understand how to use it.

So do tags ever deprecate?

[lonechicken (1046406)]

Years from now, are we still going to see IE 10, Firefox 5, and Safari 3.1 support deprecated tags? (Or is it depreciated? Defecated?)

It's like slapping on a shiny new paint job on your car, but the back seat is still full of old McDonald's bags.

Announcing

[Bluesman (104513)]

The BRAND NEW HTML 5!

Almost as good as TeX!

Link to the actual WHATWG Working Draft for HTML 5

[LighterShadeOfBlack (1011407)]

Here's a link to the latest HTML 5 working draft (published today) [whatwg.org] for those who like their information first-hand.

I'm in the money!

[El_Smack (267329)]

Sweet! Can I get my $80K a year job back doing HTML for a dotcom?
It's 1999 all over again, baby!

permablink?

[jdunlevy (187745)]

I sure hope one of the new elements is finally permablink [kibo.com]!

Seems useful

[mrjb (547783)]

This will work wonderfully because the HTML standard was designed from the ground up with graceful degradation in mind.

Even if browsers do not support these tags, the content of the tags will be displayed- if you don't want this, simply comment them out like so:

<newtag><!-- some stuff --></newtag>.

For tags that do not want their content displayed, there usually is an accompanying 'no' tag:

<script><!-- script goes here --></script>
<noscript>Your browser does not support scripts.</noscript>

With these new tags, browsers may not display a page any differently- instead of

<div class="article">articletext</div>
and a stylesheet saying .article { font-family: serif; }

now you get

<article>articletext</article>
and a stylesheet saying
article { font-family: serif; }

This will *already* be rendered equally in both old and new browsers. Some of these may end up having a fancier display in new browsers; I imagine dates could have a date picker style pop-up to better visualize the 'when'.

Even if some extensions seem to have limited use from a front-end rendering perspective, this can have a huge impact on search engines, for example, which is great. Although I must admit that I have second thoughts on some of the tags that seem to require JavaScript.

XHTML/HTML divergence

[Animats (122034)]

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.

need more tags

[El_Muerte_TDS (592157)]

</> close previous open tag
<//> close all open tags
</fix> instantly fix everything that is wrong with the site
<beer> because I need one, preferably a one of class="cold"

Re:Can't we do all this stuff already?

[_xeno_ (155264)]

Yes, in browsers that fully implement XHTML.

Which, assuming you want to support IE users, means no.

Of course, it's not like we can expect IE to rush out to support these new tags either. Making the whole effort, honestly, pointless.

It's already possible to take a plain XML document and style it completely using only CSS. It turns out to be impractical (some tags sort of require special support that can't be duplicated just by CSS rules, like <img>, <a>, and <script>), but it's possible.

Do we really need to stop progress?

[telbij (465356)]

+5 insightful? WTF? This is the same kind of specious reasoning that leads to such gems as "everything that can possibly be invented has been invented."

With the one exception of Microsoft letting IE rot for 7 years, the advancement of the web has been steady and rapid. Even while IE was a thorn in our side, we were able to drop support for NS4, then IE5, then IE5.5. Firefox and Safari continually pushed the envelope of standards support. Javascript toolkits proliferated, bridging the gap between implementations. Even 5 years ago, using CSS for site layout was a much more difficult proposition than it is today.

Now, if you had actually read the article, you would see that some of these tags provide very common functionality that currently require a mess of tag soup, CSS, and/or javascript. <video> and <audio> tags for instance, or <progress>. Sure you can't use them now, but in 10 years everyone will use them, and they'll be horrified with what we used to have to do. There's no reason to stop progress just because a handful of browser makers and lethargic standards bodies haven't yet perfected the first de-facto cross-platform, cross-media information platform in human history.

Re:what happened to xhtml?

[jalefkowit (101585)]

Yes. Kind of.

There are currently to Working Groups in the W3C working on markup -- the XHTML working group [w3.org], and the HTML working group [w3.org]. These are separate entities with separate memberships and separate processes.

XHTML was originally intended to be the successor to HTML. But a couple of things that happened after XHTML1 "shipped" caused that to be re-evaluated:

• The whole point of XHTML was that moving to XML syntax would open up new possibilities for user-agents: not just browsers (whose lives would be simplified by not having to deal with "tag soup" anymore"), but applications that would take advantage of already knowing XML to do cool stuff with the web. Only that never really happened; and because Microsoft wasn't on board, browser vendors still had to parse the "tag soup" anyway.
• The XHTML Working Group went off the deep end and announced that XHTML2 would handle errors the way XML parsers are supposed to: by shutting down and throwing up an "Non-conforming document" error. Needless to say, this is not how the Web works today, and it threw a scare into millions of Web publishers who incorporate third-party content that they have no control over (like, say, ads) in their sites. They also proposed major changes to the syntax of XHTML2 versus XHTML1 to clean it up and make it more logical; which sounds great until you realize that now you have to teach those millions of web publishers a whole new syntax or their sites break.

When it became clear that continuing down the XHTML path promised tons of heartburn for publishers and user-agent developers without much reward in return, people started thinking that maybe rebooting the HTML specification process wouldn't be such a bad thing. The W3C picked up the WHATWG's [whatwg.org] independent "HTML5 [whatwg.org]" spec as a starting point, and that's where we are today: XHTML is for people who are comfortable with radical changes between versions of the spec and Draconian error processing; HTML is for people who want backwards compatibility and less strict parsing.