Finally We Get New Elements In HTML 5 378
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."
Re:Can't we do all this stuff already? (Score:5, Informative)
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 (Score:5, Informative)
Re:Excellent! (Score:3, Informative)
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? (Score:1, Informative)
Seems useful (Score:5, Informative)
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
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:I'll tell you why... (Score:4, Informative)
Re:Excellent! (Score:5, Informative)
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 (Score:2, Informative)
I thought RSS [wikipedia.org] stood for Really Simple Syndication, did I wake up in a parallel universe this morning?
Or is it like PHP [wikipedia.org] 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! (Score:4, Informative)
Re:Seems useful (Score:3, Informative)
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: .''
``With these new tags, browsers may not display a page any differently- instead of and a stylesheet saying
now you get 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:Excellent! (Score:5, Informative)
Re:at least they didn't say ".au" and ".snd" requi (Score:3, Informative)
HTML 5 currently says [whatwg.org]
(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 (Score:3, Informative)
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 [html5.org] from html5lib [google.com] (Python and Ruby), and an independently-developed [validator.nu] Java one, and some other private or incomplete implementations, and they should all give the same output for whatever input you try.
Re:Announcing (Score:2, Informative)
Re:How about (Score:3, Informative)
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.