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

Do we need "MORE"?

[Puls4r]

When existing browsers constantly break standards, do we need "more"?

I mean, seriously - I can do anything I need to do with a web page with the tools we have right now. Adding more options just results in more bloat, more exceptions and errors, and more difficult compatibility. It means new versions of other software to keep up, and new ways to exploit.

When do we need well enough alone?

Re:what happened to xhtml?

[glop]

The whole idea is that most people don't want to bother with XHTML that is XML based.
So the W3C decided that it was worth updating the old SGML based HTML. The revolution of XHTML failed to change the world, so we are back to evolution from the current standard.

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:Do we need "MORE"?

[garett_spencley]

Bloat is entirely in the hands of the webmaster, not the technology. You are free to use or not use any features of HTML. Having more features gives you more choice, not more bloat. What you include in your web pages is entirely up to you.

Improvements in search

[efbee]

Hopefully a positive side effect of sites adopting the new spec is that search engines can index pages more intelligently. For instance, if two of the terms I'm searching for occur in the same <article> block, the page will be presented with a higher relevance than pages where the terms occur in different articles, or in a different section altogether.

I'm tired of searching for something and having pages match just because they had a small blurb or link on the sidebar but the actual page has nothing to do with what I'm looking for...

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.

Re:Excellent!

[Anonymous Coward]

And how is <div class="article"> not machine parsable?

The problem with semantic anything is that it requires an agreement as to what marks what. If you want to be able to mark articles right now, you can do it with HTML 4, and agreeing that anything that is semantically an article is marked with the "article" class. In fact, it's already been done: they're called microformats [wikipedia.org].

Changing <div class="article"> to <article> accomplishes nothing, other than reducing the amount of text that needs to be typed, with the side-effect of requiring people to upgrade their browser.

Re:Excellent!

[telbij]

The difference is that <article> is an element defined by HTML 5 with a documented meaning. <div class="article"> is a generic element with an arbitrary attribute defined by the document author.

I would go so far as to say <div class="article"> is semantically useless. Sure a human or a clever heuristic engine can infer some meaning from that, but it's too imprecise to be of much use on a large scale aggregation or data mining.

Frankly I'm not a huge believer in HTML semantics anyway. Standards snobs will endlessly critique the use of a <ul> vs an <ol> on the merit of "semantics" which in practice makes no appreciable difference. It's like they've never seen tag soup and the real reason for using CSS.

That said, a lot of these new tags are well overdue. If you consider HTML hasn't changed in 10 years and at that time we barely knew how the web would be used. HTML is pretty good for traditional text, but it has virtually nothing for the web as we know it. For instance, structural markup defining navigation has an actual tangible benefit. Browsers (especially screen readers) could make wonderful use of that information.

Re:Do we need "MORE"?

[Doctor Crumb]

Not only that -- these new tags can greatly reduce the bloat in a website by neatly summing up what used to be done in crappy nested tables with a single new 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!

[LighterShadeOfBlack]

Yes it would be as easy for a parser to determine semantics from attributes as it would from elements. But you would still need the attribute to be defined in a specification like HTML 5 in order for it to be any use. As it is now there are millions of sites which use thousands of different names for their classes to specify their article text. Which isn't any use to anyone except the web page owner. Google can't create a parser that accounts for class="article", class="blogpost", class="pink_and_green_article" and every variation on those themes (well they could try, but it wouldn't be very effective). So if it has to be defined in a specification there's no benefit in using an attribute over a new element, whereas there are potential benefits in using a new element over using an attribute. Such as having additional attributes specific to that semantic type (there aren't any for the <article> element but there are for some other semantic tags).

MP3 vs WAV

[sconeu]

Could it have something to do with the fact that MP3 is patent-encumbered?

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:Do we need "MORE"?

[hobo sapiens]

Agreed. Not to be overlooked is the javascript code that can be eliminated.

Want a menu? Gotta write javascript. Want to restrict the length of a textarea? Gotta write a script. Want to make that select box behave like a real select box in a desktop app (where you can type to find a value)? Gotta write javascript.

New tags that accomplish what should be standard behavior would make most websites much leaner and therefore much more maintainable. TFA did not indicate that select or textarea elements are going to be spruced up, though.

Re:Excellent!

[LighterShadeOfBlack]

Well at this point it's important to note one of the things that HTML 5 is not: XML. HTML 5 is plain-old HTML, meaning it's syntactically forgiving (ie. case-insensitive elements and attributes, closing tags optional). That might not be important for you or me or most other Slashdot users but for the vast majority of people that kind of forgiving behaviour is very important. Can you imagine what Myspace would look like if everyone were required to use Strict XHTML or XML+XSL on their pages? Errors as far as the eye can see I'd wager (whether that would actually be better than Comic Sans and animated backgrounds is another matter).

HTML 5 is something you can pick up along the way. It's very much accessible to the common man with just a smidgen of computer knowledge. Raw XML is learnable too, if somewhat inconvenient for beginners in its strictness when hand-editing. Styling it on the other hand is not something for the layman. I don't think anyone who's worked with XSLT and XPath could honestly disagree that they are progammers' tools and shouldn't be considered for the casual web author.

One other benefit of HTML 5 over XML is that it can fail gracefully on old and unsupportive browsers. With HTML 5 the worst thing you're likely to get is HTML 4.01 support with some text that doesn't style appropriately. With XML you're stuck.

Re:Excellent!

[Asmor]

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

Amusing, but actually scary when you think about it... The only way such a tag would actually be implemented by people with advertising is if there were DRM-like restrictions on browsers forcing ads to be shown. I'm sure it wouldn't be hard to get IE to implement such restrictions, and honestly I wouldn't be surprised if they found a way to force Firefox to implement them too. So i say nay to <ad>.

Re:How about

[irc.goatse.cx troll]

Fully agreed, especially about the forms.

I'm not sure what would be better, but the current way (either inputs inside a table, or <label for="asdf">Asdf</label> <input id="asdf" name="asdf" /><br> with a LOT of css to position it) is just a pain in the ass (and only works for simple forms, try duplicating the kind of paper form you fill out at a doctors office for example)

while we're at it, can we like.. require everyone fully support css? I'm tired of putting ID's and Class's on inputs with unique names, when CSS says I should do

input[@name=date]

But of course none of the big three browsers come close to supporting it.

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.

Re:Excellent!

[cmburns69]

Content and presentation have been slowly merging over the course of the web. Adding these semantic tags appears to be an attempt to separate the presentation from the content.

The trouble is that nobody will add the new tags until a majority of browsers support HTML5. And nobody will be interested in upgrading until the major sites require it (or until the format is slowly merged in during users normal upgrade schedules). Add that to the fact that the current generation of browsers don't agree on implementations within HTML4, and I suspect that this will not really help us web developers. /RANT

Re:Do we really need to stop progress?

[telbij]

So you think using Flash for video rather than a single obvious tag is "slathering on additional layers of crap"? Or is it that you don't think we should be displaying video in our web browsers? The new tags are by-and-large very well thought out, and reflect a standardization of common practices over the last decade. The structural tags alone such as header, footer, nav, and article are applicable to the vast majority of websites and provide semantic meaning that could easily be leveraged by browsers (especially screen readers) to improve the user experience. The result is not an additional "layer of crap" but the replacement of a sea of arbitraily classed divs with semantic markup that is more meaningful than before.

Obviously HTML/HTTP is not the ideal platform for rich applications. I fully acknowledge that. However we're not going back to HTML as a platform for purely static content. If that's all you want to use your browser for, please carry on with the rest of the nostalgic internet luddites. I'm sure you can find a few dozen other curmudgeons to reminisce with over on Usenet. However as far as delivering applications, the web has undeniable advantages. Economic realities mean we'll be moving forward with the web for better or for worse, just like with so many other imperfect technologies in the past.

Re:MP3 vs WAV

[fyngyrz]

Could it have something to do with the fact that MP3 is patent-encumbered?

Well, it could be if you accept the premise that the committee is made up of 14-year old fanbois who can't think their way out of a paper bag.

Look: JPEG is patent encumbered; nonetheless, it is the standard. GIF was encumbered; nonetheless, it was the standard. Likewise MP3. It flat out isn't the place of a committee to define things out of public use because there is a commercial tie; the fact is, MP3 is the standard, and if audio is to be a browser feature, then a browser that can't play MP3 is utter crap. A standards body isn't there to be your your mother; it is there to promote interoperability, usability, commonality, is it not? So WTF are these people doing ignoring MP3 in favor of WAV?

Look at it this way: The first question a person is going to ask when they pick up an audio package or hardware audio player (you'll note the usual term is "MP3 player") — editor, player, recorder — is not going to be: "Does it support WAV?" No, it's almost certain, statistically speaking, to be "Does it support MP3?" And that is why WAV is a stupid choice.

I am no fonder of patents than any of the rest of you. But if you're going to rule out every technology that is patent encumbered, your sorry, optimistic, blindered butt will be in a cave before you even know what hit you.

Re:MP3 vs WAV

[sconeu]

I'm not ruling it out. I'm saying that requiring *all* browser developers/vendorss to support a technology for which they may not be able to obtain a license is bad practice in a standard.

Re:MP3 vs WAV

[Bogtha]

Look: JPEG is patent encumbered; nonetheless, it is the standard. GIF was encumbered; nonetheless, it was the standard. Likewise MP3.

Well if we are applying this reasoning equally, then fine. No version of HTML requires browser vendors to implement JPEG. No version of HTML requires browser vendors to implement GIF. And now, the new version of HTML won't require browser vendors to implement MP3. Fair, yes?

It flat out isn't the place of a committee to define things out of public use because there is a commercial tie

And they haven't done any such thing. They haven't banned the use of MP3, they just aren't requiring browser vendors to implement it. In all likelihood, every major browser vendor that implements <audio> will include MP3 support. But "it flat out isn't the place of a committee" to force browser vendors to infringe on patents.

Re:Excellent!

[Bogtha]

Well at this point it's important to note one of the things that HTML 5 is not: XML. HTML 5 is plain-old HTML, meaning it's syntactically forgiving (ie. case-insensitive elements and attributes, closing tags optional).

Actually, it's not plain-old HTML either. It's no longer based on SGML, HTML 5 defines its own parsing rules.

Can you imagine what Myspace would look like if everyone were required to use Strict XHTML or XML+XSL on their pages? Errors as far as the eye can see I'd wager

I wouldn't. Have you noticed that practically everybody using a custom page layout on MySpace uses a tool to do it? Jane Random Teen isn't writing HTML by hand. If any tool like that produced errors, people would simply use one that didn't.

Raw XML is learnable too, if somewhat inconvenient for beginners in its strictness when hand-editing.

Strictness isn't inconvenient for beginners, laxness is. The traditional laxness of HTML lets beginners twist their code further and further out of shape until when their code finally breaks, they've got so much to fix that they don't know where to begin. They just start hacking at it randomly hoping to change something that might have an effect. XML, on the other hand, has regular rules, and lets you know the second you screw up, so you don't get ahead of yourself, so you know which change it was that broke your page, so you have a chance of learning the rules.

Laxness has a reputation for being beginner-friendly because it enables beginners to speed ahead without really learning what it is they are doing. Thinking that's a good idea is short-sighted though, because as soon as they run into difficulty, they are already way out of their depth. Strictness is better in the long run.

Re:Excellent!

[Bogtha]

I haven't gotten into the depths of the HTML 5 spec. but AFAIK it hasn't actually changed from previous versions of HTML at a practical level.

You could characterise the differences between HTML and HTML 5 as nit picking, but if you were totally fair, you'd have to characterise the differences between HTML and XHTML served as text/html as nit picking too, and nobody wants to do that. On a practical level, the differences cause problems in edge cases. But there's a double standard involved because XHTML isn't trendy any more, so people only want to see the bad in XHTML and the good in HTML 5. I mean, HTML 5 and XHTML both have similar subtle syntax differences compared with HTML, but one of the editors of the HTML 5 specification that condones subtle syntax differences is also the author of the XHTML as text/html Considered Harmful essay where he tells everybody that the subtle syntax details are enough to avoid using XHTML as text/html!

All that's really happening I believe is that they're officially specifying the behaviour that every browser already uses. Bascially they're retconning HTML parsing to make every implementation correct instead of trying to get browsers to change.

So basically it's HTML 3.2 all over again and they are just rubber-stamping a mess.

I wouldn't. Have you noticed that practically everybody using a custom page layout on MySpace uses a tool to do it? Jane Random Teen isn't writing HTML by hand. If any tool like that produced errors, people would simply use one that didn't.

Not writing by hand, but from what I've seen (admittedly not a great deal) they do often copy and paste peices of HTML from multiple sources which can very easily lead to nesting issues under XML variants.

You seem to be confusing validity and well-formedness. Copy and pasting code into places where it shouldn't be causes validity errors. XML parsers are only required to throw a fatal error when they encounter a document that is not well-formed. But even so, my point still stands: if somebody is supplying code that breaks their MySpace layouts, they will copy and paste from a source that doesn't supply broken code. I don't know why people are so intent on pretending people won't react to these errors and just blindly use code that gives them errors. It's a common attitude, but seems to bear no resemblance to reality. People are usually rational. If something is obviously broken to the point of complete lack of functionality, they won't use it.

HTML's forgiveness isn't cumulative in most cases though. Generally speaking if you can get away with something once you can get away with it a thousand times and never experience an actual break.

Have you ever actually seen a newbie write code? I've seen professional web designers write tables nested a dozen levels deep before getting to a point where something is broken and they have no idea what or how to fix it. Throwing newbies into that sort of environment is not a good way for them to learn.

You can't really keep twisting more and more because you're not technically doing anything wrong, just being a bit scrappy at worst.

Where does this myth come from that you can do pretty much whatever you like in HTML and it's not technically wrong? HTML isn't that lax, it's got fairly strict syntax rules. It's typical browser error handling that's lax. Once you reach that point, you are definitely "technically doing something wrong".

If you do something truly wrong then odds are it will show in the rendering and can be fixed from there.

No, this is simply not the case. Browsers have well over a decade of kludges built i