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."
Oh noes! (Score:4, Funny)
Re: (Score:3, Funny)
Excellent! (Score:5, Interesting)
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! (Score:5, Funny)
Actually, they need to put in an <ad> tag.
Re: (Score:3, Insightful)
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
Re:Excellent! (Score:5, Insightful)
Re:Excellent! (Score:5, Insightful)
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: (Score:3, Funny)
Re:Excellent! (Score:5, Funny)
Re: (Score:3, Insightful)
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 implementa
Re: (Score:3, Interesting)
Re:Excellent! (Score:5, Insightful)
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! (Score:5, Informative)
Re: (Score:2)
Re: (Score:2)
Re:Excellent! (Score:5, Insightful)
Web developers want their ads to be seen. They aren't going to make it easy for those ads to be blocked.
Re:Excellent! (Score:4, Insightful)
Re:Excellent! (Score:4, Interesting)
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.
No, they wouldn't be parsed any differently, but they might be rendered differently.
Re:Excellent! (Score:5, Insightful)
Re: (Score:2)
Re:Excellent! (Score:4, Insightful)
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: (Score:3, Insightful)
Actually, it's not plain-old HTML either. It's no longer based on SGML, HTML 5 defines its own parsing rules.
I wouldn't
Re: (Score:3, Insightful)
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 XHT
Re: (Score:2)
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.
Is there a requirement that attributes can't be semantic? Like the GP asked, what's the inherent difference between <article> and <div class="article">? It'd be equally easy to configure a parser to treat each of those as semantic markup.
Re: (Score:3, Insightful)
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.
Re: (Score:2)
My retinas will never be the same...
Re:Excellent! (Score:5, Funny)
Re:Excellent! (Score:5, Insightful)
Re:Excellent! (Score:4, Informative)
Re: (Score:3, Informative)
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, encycl
Re: (Score:3)
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 mar
Re:Excellent! (Score:4, Insightful)
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: (Score:2)
Semantically, what's the difference between:
<div class="article">...</div>
And:
<article>...</article>
Answer: Nothing.
Quite a lot, actually. We can attach strictures of implementation to the article element, write test suites, define tags, and otherwise build a substantial set of semantics for any new element. A div that just has a particular class is like any other div. It doesn't have its own tags, and it might well have very different meanings to different HTML authors and browser vendors.
Re: (Score:2)
If you can do the same with the article tag, then they are adding things for the sake of adding them.
Re: (Score:3, Interesting)
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 mostl
MP3 vs WAV (Score:3, Insightful)
Re: (Score:3, Insightful)
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
Re: (Score:3, Insightful)
Re: (Score:3, Insightful)
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?
Re: (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.)
Oh great... (Score:5, Funny)
Re: (Score:2)
Or in other words...
Let the Browser Wars II... BEGIN!
Re:Oh great... (Score:4, Funny)
What?
We get new tags
Firefox Turn On
It's new!
How are you gentlemen? All your tags are supported by us
Re: (Score:3, Funny)
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...
How about a Declarations area? (Score:3, Funny)
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? (Score:2, Interesting)
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.
I'll tell you why... (Score:2, Funny)
Re: (Score:2)
Re: (Score:2)
With XML [w3schools.com] of course. Actually, you can apply CSS to just about any data format to produce a layout. Whether your browser will support it or not is another matter all together.
I'm just waiting for someone to create a Javascript shunt that will allow CSS to be applied to JSON documents. In fact, I'm sure that someone will produce a link in 3... 2... 1...
Re:I'll tell you why... (Score:4, Informative)
Re: (Score:2)
Same way you use it with HTML. CSS isn't tied to HTML, and can be applied to pretty much any arbitrary XML you like (using Firefox or Thunderbird? The UI is an XML format -- XUL -- styled with CSS, and has behaviors bound to it via XBL, allowing you to add new features to the application with JavaScript if you like).
Do we need "MORE"? (Score:4, Insightful)
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: (Score:3, Insightful)
Re: (Score:3, Insightful)
Re:Do we need "MORE"? (Score:4, Insightful)
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: (Score:2)
Re: (Score:2)
Do we really need to stop progress? (Score:5, Interesting)
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: (Score:3, Insightful)
Re:Do we need "MORE"? (Score:4, Interesting)
Web 1.0 (Score:3, Funny)
I'm looking forward to Web RC1 in the next 5 years.
what happened to xhtml? (Score:4, Interesting)
Re: (Score:2, Insightful)
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: (Score:3, Interesting)
The browsers relative level of eventual support will declare the winner after buch blood sweat and tears.
Re: (Score:2)
Re:what happened to xhtml? (Score:5, Interesting)
Yes. Kind of.
There are currently to Working Groups in the W3C working on markup -- the XHTML working group [w3.org], and the HTML working group [w3.org]. These are separate entities with separate memberships and separate processes.
XHTML was originally intended to be the successor to HTML. But a couple of things that happened after XHTML1 "shipped" caused that to be re-evaluated:
When it became clear that continuing down the XHTML path promised tons of heartburn for publishers and user-agent developers without much reward in return, people started thinking that maybe rebooting the HTML specification process wouldn't be such a bad thing. The W3C picked up the WHATWG's [whatwg.org] independent "HTML5 [whatwg.org]" spec as a starting point, and that's where we are today: XHTML is for people who are comfortable with radical changes between versions of the spec and Draconian error processing; HTML is for people who want backwards compatibility and less strict parsing.
Re:what happened to xhtml? (Score:5, Funny)
- That, of course, would belong in the much anticipated <bender> tag.
Good and bad at the same time (Score:4, Interesting)
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 [wikipedia.org] 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.
Re: (Score:2)
The only problem I have with XHTML/CSS is browsers that don't support it properly.
Up to now, new HTML elements... (Score:4, Funny)
Still no <bgsound tune, repeat> ? ;-) (Score:5, Funny)
repeat:byte; 0 = ad nauseam
With MOD [wikipedia.org] support - of course!
OK whats in it for me. (Score:2)
The most greatly wanted tag (Score:5, Funny)
Re: (Score:2)
Re:The most greatly wanted tag (Score:5, Funny)
So do tags ever deprecate? (Score:5, Interesting)
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.
Finally! The return of the tag! (Score:2)
Announcing (Score:5, Funny)
Almost as good as TeX!
Re: (Score:3, Interesting)
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
Re: (Score:3, Funny)
Link to the actual WHATWG Working Draft for HTML 5 (Score:5, Informative)
Improvements in search (Score:2, Insightful)
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 t
I'm in the money! (Score:5, Funny)
It's 1999 all over again, baby!
permablink? (Score:5, Funny)
Cut off back support (Score:2)
RISC versus CISC (Score:2)
The cross-browser mess was quite frustrating. First Netscape got replaced by IE because IE was simply better, didn't crash as much, supported more stuff. Then IE got almost replaced by FireFox. Now I use Opera
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: (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:
Too Late (Score:2)
XHTML/HTML divergence (Score:5, Insightful)
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 (Score:4, Interesting)
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 [w3.org]. There are other issues too, but I can't pull them off the top of my head at this time.
Re: (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-d [validator.nu]
need more tags (Score:5, Funny)
<//> 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 (Score:3, Interesting)
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)).
How about (Score:3, Funny)
-Looping
-Smarter Form controls
-Eliminate the need for putting a space in empty table cells.
- ???
- Profit!
Re: (Score:3, Insightful)
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"
while we're at it, can we like.. require everyone fully support css? I'm tired of putting ID's and Class's on inp
Re: (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 ot
Re: (Score:2)
<sarcasm>You're ABSOLUTELY RIGHT!</sarcasm>