Finally We Get New Elements In HTML 5

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

Comments

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

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.

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:Can't we do all this stuff already?

[Anonymous Coward]

Actually you can make IE support XHTML fully by following a method I found here: Fix for IE's lack of application/xhtml+xml

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?

Re:I'll tell you why...

[AKAImBatman]

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

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.

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

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!

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

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

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.