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

Oh noes!

[HitekHobo]

And here I was thinking that solved all of my web design problems. Now I might have to learn a second type of tag!

Excellent!

[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]

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!

[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!

[corsec67]

Apparently slashdot got rid of it for you...

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!

[e4g4]

More tags for browsers to neglect to implement! No argument here - but I do take issue with your assessment of the <article> tag. The difference between <div class="article"> and <article> is that "<article>" has some implied meaning that a browser will in fact be able to infer, whereas a browser will not (and should not) infer any real meaning from the CSS class.

While this is not terribly relevant to rendering the page in it's original/intended format - i can see it being very useful for indexing and searching blogs, encyclopedia articles, etc., as well as news aggregators, small format browsers (cell phones, etc.), and screen readers. Allowing the browser to "know" what the contents of the tags "mean" in the context of the web page would allow for much more intelligent default behavior when the site is being accessed out of spec.

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.

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!

[PipianJ]

Actually, I think you're confusing the semantic content of the element (the former says 'This is a division of a page in the article class', the latter says 'This is an article') with the actual intended content of the element. This is really of particular interest to Semantic Web and RSS technologies, as it gives an actual semantic context to the content inside the element, rather than an implied one that is dependent on human-interpretation to understand.

The idea of HTML+CSS was to separate semantic markup from styling markup. HTML5 doesn't change this fact. What it does change is the underlying semantic INTERPRETATION of the content. In particular, one example will prove the usefulness of an article tag (ignoring, just for a moment, the equal validity of RSS to solve it):

It is a given that more and more internet denizens reside in many different countries speaking many different languages. HTML already exists to support all of these languages, and what's to stop a Spanish developer from using

<div class="articulo">

instead of what you mention? The inherent meaning is the same, but to English speakers, and to the browser itself, it's now just a "subdivision of the page of class 'articulo'" which, strictly within the context of English, means absolutely nothing. The <article> tag, in contrast, actually imparts a semantic meaning to the content that is invariant by language, and is the same worldwide. Unless you support setting aside specific classes to impart to them specific semantic content (e.g. Microformats) which will almost certainly NEVER be able to be standardized to the point that it becomes a W3C standard (and thus practically a prerequisite to implementing a standards-compliant browser), the semantic content that HTML5 provides renders it a useful, if not necessary, change.

TLDR: HTML5 isn't about new ways to style, it's about additional semantic markup.

Reductio ad Absurdum: Why keep the <p> tag? It could just as easily be marked up with <div class="paragraph">, by your interpretation of HTML semantics.

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: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]

Well that's not strictly true. The 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!

[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).

Re:Excellent!

[MagicM]

multi-file-select is included in Web Forms 2, which is the "forms" part of HTML 5:

The min and max attributes apply to file upload controls (input elements of type file) and specify (using non-negative integers) how many files must be attached for the control to be valid.

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!

[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: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!

[Touvan]

Page authors could use XHTML 5 (XHTML is allowed under the HTML 5 spec, which they call XHTML 5), and include an xsl style sheet that would convert these new tags to something useful in the older browsers which do not support the new tags (convert to ). That way, there is no need for users to upgrade. There are lots of other strategies for dealing with older browsers too. The answer doesn't always have to be "require users to upgrade".

Re:Excellent!

[Rorzabal]

The intent of making the article tag for accessibility is good. However, you know that people are going to start wrapping their advertisements in article tags, defeating the noble goal.

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:Excellent!

[Bogtha]

Personally I think that's a bad idea, since CLASS carries style information, not semantic information

This is a common misconception. The class attribute is intended for general purpose classification of elements, not merely as a style hook. The idea is that you classify your elements in a meaningful way (i.e. provide semantics), and then your stylesheets, scripts, etc, can use those semantics to manipulate the document in a useful way.

there's probably already a ton of documents out there using, say [...] and their owners are gonna be really surprised when browsers suddenly start parsing those classes in new and unexpected ways.

No, they wouldn't be parsed any differently, but they might be rendered differently.

Re:Excellent!

[Anonymous Coward]

What does a screen reader on Viagra sound like?

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

Re:Excellent!

[nine-times]

I've always wondered whether there was any good reason these days to have the pre-defined elements the way we do. Is the current selection of elements really efficient and meaningful? Is there a good reason to prohibit people from making up their own elements?

Back in the day, of course, web pages were pretty simple, and I guess it made sense that you would come up with a couple generic tags and assign each of them formatting. The "P" tag was a paragraph, and "LI" was a list item. Since pages were mostly plain text, and mostly paragraphs and lists, it made sense.

But now? The type of data contained in a web page is so variable and people want to be more in control of layout and design. So sometimes, when I'm thinking about it, I start to feel like the whole thing is kind of weird. This is a weird debate for me, and I find myself having trouble articulating my thoughts.

The main things I use are "A", "P", "H*", "DIV", "SPAN", "BLOCKQUOTE", "UL", "OL", and "LI"... I guess some others sometimes ("CITE", "DL", "DT", "DD"). But does that selection of default elements really make sense? Were they derived systematically? Even these new elements, were they derived systematically, or were they just pulled from what would go into a weblog or something?

I don't know. The new elements seem good to me. There have been loads of times when I've had so many "DIV" tags with semantic classes that I've just wanted to make up my own elements specific to the data I'm working with. Yeah, I know it shouldn't be any harder to write "div class="article" vs. "article", but it would just make more sense in my own head and be easier to read.

At the same time, I've spent a fair amount of time coming up with CSS that will just reset all the elements to a standard display (P and BLOCKQUOTE display as normal DIVs, no bullets on UL, H1 the same size as normal text, etc). Call me crazy, but sometimes it's just easier for me to start from scratch.

Put these two ideas together, and sometimes I kind of feel like no web browser should have any default elements defined, and you should be able to make up any tag you want. The whole thing should be handled by convention, and there should be an agreed-upon default CSS file that you attach to get the display that would give you the layout browsers give you now without CSS. Hell, even include that CSS with the browser, but allow an easy switch in the HTML spec to disable the whole thing. Drop the "A" tag altogether and make anything a link if you include "href='http://example.com'".

Then again, it seems like that might lead to chaos. I don't know. Sometimes HTML makes a lot of sense to me, and sometimes it seems like the stupidest set of conventions I've ever seen.

Re:Excellent!

[kennygraham]

Barry White + Stephen Hawking

Re:Excellent!

[ptlis]

* However, it can (mostly) deal with it if you (incorrectly, IMO, despite appendix C) send the mime-type as text/html and skip the XML prologue by parsing it as 'tag soup'.

I'd agree with you if you'd been talking about XHTML 1.1. XHTML 1.0 SHOULD be served as application/xhtml+xml, but MAY be served as text/html when the compatibility guidelines are met. XTHML 1.1, however, SHOULD NOT be served as text/html. Even then, it's not a MUST NOT. But since it's a MAY for 1.0, i think calling it "incorrect" is a bit harsh. May, as you probably know, but just incase, is defined by RFC2119 as:

Yes, I was talking about XHTML 1.0 (Appendix C is the location of said compatibility guidelines), it is widely considered to have been a mistake to allow developers to send XHTML documents with the wrong Content-Type because it causes subtle errors and defeats the purpose of using an XML based language (amongst many other reasons). My point is that when you serve XHTML as text/html you negate the point of using XML; You lose the ability to embed other XML languages (such as MathML or SVG) within your document, the page is no longer sent through an XML parser that checks for well-formedness thusly you're likely to introduce subtle errors without realising. When the day comes that all major UAs support application/xhtml+xml correctly and you decide to switch the Content-Type over there is a good chance of your pages not being displayed (works fine in IE but dies in Firefox due to crappy content negotiation) due to subtle errors in your markup that weren't apparent when your document was being parsed as tag soup.

And for all these difficulties you get what? On the web today, with IE still having ~80% market share, XHTML offers no advantage of HTML4 and has a whole pile of potential pitfalls that a developer must take into account of and hack around. For example, <, >, & are all treat as markup irrelevant of where they are in a document when a page is treat as XML, causing problems with inline JavaScript blocks; as a developer you have to explicitly declare the contents of script block as cdata using <![CDATA[ followed by a closing ]]> with all Javascript between those two elements, however because the Javascript interpreter treats anything within a JavaScript block as code (and you're sending it as text/html) you have to comment them out so that when served as text/html to older browsers they don't try to execute the cdata declaration as code.

There are many, many more problems associated with sending XHTML as text/html with various hacks to mitigate some of them to a greater or lesser degree. However I don't feel that sending XHMTL as text/html is ever a good idea and if you insist on generating XHTML markup then I suggest you use a good content negotiation script to send it as application/xhtml+xml where the browser supports it and when it does not using XSLT to transform the document to HTML before sending it to UAs that do not.

Re:Excellent!

[Lord Flipper]

There are many, many more problems associated with sending XHTML as text/html with various hacks to mitigate some of them to a greater or lesser degree. However I don't feel that sending XHMTL as text/html is ever a good idea and if you insist on generating XHTML markup then I suggest you use a good [ptlis.net] content negotiation script to send it as application/xhtml+xml where the browser supports it and when it does not using XSLT to transform the document to HTML before sending it to UAs that do not.

This is very interesting, and even though I dabble in XHTML and CSS and warping PHP templates, and have read a lot, I'd never considered sending different content types before. You know, the conventional 'wisdom' (I use that term loosely in my case) is all about hacks, and alternate stylesheets. But I worked with XML for years, and still hadn't considered the 'xml for these folks, html/text for those folks' idea. Time for me to start digging up my XSLT books and guidelines. Thanks for this.

Oh great...

[Bazman]

More things for IE to not support properly.

Re:Oh great...

[Praedon]

Somebody set us up the HTML 5
What?
We get new tags
Firefox Turn On
It's new!
How are you gentlemen? All your tags are supported by us

Re:Oh great...

[Bazman]

Didn't you guys read the article? This should be in tags...

You have no chance to survive make your <time datetime="2007-04-23T17:35:00-05:00">time</time>

Perhaps HTML5 is designed for the AYB retro nostalgia happening any day now...

Re:Oh great...

[Praedon]

Oh one more thing... another tag that is needed is one for sites that commonly get slashdotted. All we have to do is put several bandwidth hogging images and files inside the antislash tag, which would allow the coding to show or not show the code based on if the site is really crawling. All browser based too, so it cuts out having to ask the server if it's being slashdotted, well, because it obviously is if its going extremely slow. There are other measures to put in place too, like the browser keeping in mind if the referral page was indeed a slashdot article.

I think I am just getting goofy now about this... : )

How about a Declarations area?

[WED Fan]

I'd like to see an ability to use a <Declaration> area, then you can use inline (Declare @xxx) or linked (Imports xxx.x) definitions and such.

Just an idea.

Can't we do all this stuff already?

[Anonymous Coward]

Isn't it already possible to include proprietary tags in (X)HTML documents, then just use CSS to determine how they are presented (i.e. block level vs inline, positioning, color, etc.)?

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

[_xeno_]

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.

I'll tell you why...

[Orig_Club_Soda]

Its because everyone is hyping CSS and its practically terrorism to use HTML.

Re:I'll tell you why...

[AKAImBatman]

Oh, hey, look at that. JsonML. Styled by CSS even. Who would have guessed?

Re:I'll tell you why...

[AKAImBatman]

You know, moderations like this are the great mystery of Slashdot. Why is the above post modded Flamebait? Is it not acceptable to be sarcastic to one's own self? If so, why should being sarcastic to one's self involve starting a flamewar? What would be the responses? Somehow, "JSON can indeed be styled with CSS, but you were being sarcastic so off with 'yer head!" doesn't strike me as a realistic scenario.

Maybe it's grumpy moderator day. Um... happy grumpy moderator day? =D =D =D

(Wait, if it's grumpy moderator day, should I really be wishing them a happy day? My head hurts.)

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

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.

Re:Do we need "MORE"?

[Heian-794]

One thing that should have been covered long ago in HTML but in fact stil requires CSS is vertical writing (such as in Asian languages). It's suprisingly difficult to guarantee correct display for any browser, even though word processors have had this essential feature for years.

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.

Web 1.0

[Applekid]

TFA:

This new version of HTML--usually called HTML 5, although it also goes under the name Web Applications 1.0--would be instantly recognizable to a Web designer frozen in ice in 1999 and thawed today. If you were like me with all the talk about Web 2.0, what happened to Web 1.0, well, here it is. Neat, kind of like Merlyn aging backwards.

I'm looking forward to Web RC1 in the next 5 years.

what happened to xhtml?

[fredrated]

I thought xhtml was the next iteration after html 4, has that been changed?

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:what happened to xhtml?

[DrSkwid]

W3 decided just to bring what-wg HTML5 into the fold, not give up on xhtml.
The browsers relative level of eventual support will declare the winner after buch blood sweat and tears.

Re:what happened to xhtml?

[jalefkowit]

Yes. Kind of.

There are currently to Working Groups in the W3C working on markup -- the XHTML working group, and the HTML working group. 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 independent "HTML5" 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.

Re:what happened to xhtml?

[sootman]

Screw all this. I'm gonna start my own working group... with blackjack and hookers! In fact, forget the working group.
- That, of course, would belong in the much anticipated <bender> tag.

Good and bad at the same time

[chriss]

On the one hand I welcome new tags like datagrid and menu, which will make HTML source easier to handle. Even though the increased complexity will make it harder to start with HTML. Most web developers still have problems with XHTML/CSS, advancing HTML will make that worse.

Most likely this will lead to more automatically generated code, which in the long run (in combination with XML compliance) should lead to less buggy web pages and general browser compatibility. Which is a good thing. But somehow I think that one of the reasons HTMLs use has become so widespread (Microformats etc.) is simply because it was so easy to mess around with. Making it "better" might slow down innovation in these areas, which would be sad.

Up to now, new HTML elements...

[Anonymous Coward]

...had to be created in an expensive particle accelerator and often decayed before you could hit refresh.

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

[D4C5CE]

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

The most greatly wanted tag

[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]

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]

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]

The BRAND NEW HTML 5!

Almost as good as TeX!

Re:Announcing

[annamadrigal]

You beat me to it...
Actually, seriously, one really serious omission from HTML and other "generic" markups which can be read widely is proper support for rendering of mathematical equations. It would be very useful for a lot of us if there was native HTML support for at least some of the more basic mathematical language that's contained in everything which gets written from day to day.
The structure based nature of TeX and its variants seems self-evidently superior to that provided by HTML even with the various enhancements which have been retrofitted in recent incarnations and add-ons. Whilst TeX equally clearly isn't the right answer for generic web based content (and, indeed, it would be preferable not to have a standard which requires multiple parses to render anything useful) it seems that HTML really isn't what is needed and the more variations and versions that get implemented the more confusion there will be -- and the more deviation from these standards.
That HTML is already ubiquitous doesn't seem a sufficiently good reason to insist that every new markup language should be a direct superset with ever more variations and multiple ways of achieving the same end. To start with, there's no future in a structure-based approach which makes it so easy to directly change the appearance of content -- think hold much easier it is to write in bold in HTML than it is to indicate that emphasis is required....
What I think is needed, and surely must emerge sooner or later, is a no markup language based more on TeX and professional typesetting approaches than HTML which actually does things properly....

Re:Announcing

[PipianJ]

Now if W3C gets around to implementing the &tex; entity, I think we'll be all set.

Re:Announcing

[bigdan]

No support for markup of mathematics in HTML? So what's this then http://www.w3.org/Math/? It even works in Mozilla http://www.mozilla.org/projects/mathml/.

Link to the actual WHATWG Working Draft for HTML 5

[LighterShadeOfBlack]

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

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

I'm in the money!

[El_Smack]

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

permablink?

[jdunlevy]

I sure hope one of the new elements is finally permablink!

Seems useful

[mrjb]

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.

Re:Seems useful

[RAMMS EIN]

``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>

.''

Err, no. That will comment out the comment for browsers that do support the tags, too.

``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>

.'' ...which, of course, only helps because, as a special case, browsers process the script even if it is inside an HTML comment.

``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.''

Actually, I just found out today that Internet Explorer, at least in version 7, seems to refuse to apply styles to elements it doesn't recognize. For testing, I added a <leet>This text is leet!</leet> to my homepage and added leet { color: #00ccff; } to my CSS. IE rendered the text in black. Firefox in the color I specified.

``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'.''

Actually, these fancier things can become really troublesome. For example, how does an old browser cope with the (hypothetical) new canvas element, which presents a canvas the user can draw an image on, which is submitted along with the rest of the form?

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:XHTML/HTML divergence

[PipianJ]

HTML5 is being developed hand-in-hand with XHTML5, which is merely the XML serialization of HTML5. Don't worry. You don't have to give up <br /> if you don't want to.

That being said, I do believe that CSS still has fundamental problems that not even CSS3 seems to be solving, such as taking into consideration the growing use of HTML as an application framework rather than a document framework. The most notable issue of this would be the inability to center an object vertically in a viewport without Javascript to determine its size, which is a klutzy hack at best. The float: and clear: primitives, as you mention, are also comparatively weak (since you can't just float an element, have text flow around it, AND position it vertically), though CSS3 is introducing a Multi-column layout module. There are other issues too, but I can't pull them off the top of my head at this time.

Re:XHTML/HTML divergence

[Blobule]

If thay can add a tag wrapper around a tags top change the semantics then I think they should consider also adding a tag wrapper that tells browsers the table used within is for layout purposes only. Then we can be done with the craptastic state of using CSS div kludges to layout data. Old pages wil lbe compatible, future browsers will understand that the table within is just for layout.

Re:XHTML/HTML divergence

[Excors]

A big advantage of XHTML was that the conversion to a parse tree was unambiguous. Why give up that at this late date?

The conversion of HTML5 to a parse tree is unambiguous too – the spec defines exactly what happens to any input document, including ones full of syntax errors. (Or at least it's unambiguous to machines – humans may have a harder time working out how a badly broken document gets parsed). There's currently an parse tree viewer from html5lib (Python and Ruby), and an independently-developed Java one, and some other private or incomplete implementations, and they should all give the same output for whatever input you try.

The <BLINK> Tag

[sjaguar]

As long as the tag is left in, I'm good.

May me redundant...

[thatskinnyguy]

Did anyone notice the TeX style of some of those tags? i.e.

<article><entry>etc...

RSS

[C0y0t3]

From TFA:

...Browser vendors focused on browser features like tabs and Rich Site Summary (RSS) readers. ..

I thought RSS stood for Really Simple Syndication, did I wake up in a parallel universe this morning?

Or is it like PHP where they threw out the original meaning (Personal Home Page) and replaced it with a shiny new recursive one (PHP Hypertext Preprocessor) once it became popular?

I thought I told everyone to keep me apprised of shit like this so I don't sound so dated talking to my co-workers...

"Hey Tim, IBM just changed history again..."

Do we really need to stop progress?

[telbij]

+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: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.

need more tags

[El_Muerte_TDS]

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

I Don't Get It

[RAMMS EIN]

I don't get it. There was much excitement about the new tags in the dupe as well, and now here it is again. Is this really what the world has been waiting for? I thought that with the advent of XML, we could mix and match; include the languages we need, and come up with a nice, meaningful document, which could then be processed by various means to get various interesting results (one of those being a graphical rendering).

So now we get more tags in HTML. What are those good for? Why are we putting them in a single language, rather than keeping things modular?

Also, as far as I know, they still haven't solved some of the problems with XML (the most glaring one, in my opinion, being the lack of abstraction (think: eliminating repetion)).

MP3 vs WAV

[sconeu]

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

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.

How about

[sherriw]

-A height attribute that actually works?
-Looping
-Smarter Form controls
-Eliminate the need for putting a space in empty table cells.
- ???
- Profit!

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:How about

[porneL]

CSS selector input[name=date] works now in all major browsers, including IE (since v.7 though).

HTML doesn't require you to stuff table cells with anything. In CSS you can control their presentation with empty-cells:show. Don't confuse specification with IE's lack of support for it.

HTML 5 includes new form controls for dates, time, urls, emails, with declarative validation. There are repetition templates (you could call it looping). It works already natively in Opera and there are free JS libraries for other browsers.

Re:at least they didn't say ".au" and ".snd" requi

[Excors]

HTML 5 currently says

User agents may support any audio codecs and container formats. User agents must support the WAVE container format with audio encoded using the PCM format.

(Bit-rate, bit-depth and number of channels (and maybe other aspects?) are undefined - I assume the specification may end up adding some restrictions on what support is required, depending on what implementors suggest.)

Re:So...

[HitekHobo]

Yup. Laziness will getcha