Slashdot Mirror
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."
And here I was thinking that solved all of my web design problems. Now I might have to learn a second type of tag!
A couple of 30-somethings embark on the ultimate roadtrip
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.
More things for IE to not support properly.
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?
I thought xhtml was the next iteration after html 4, has that been changed?
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.
memomo: free web based language trainer DE-EN-ES-FR-IT
...had to be created in an expensive particle accelerator and often decayed before you could hit refresh.
The tag the world's been waiting for since 1994...
repeat:byte; 0 = ad nauseam
With MOD support - of course!
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.
You are in a maze of twisty little relative jumps, all alike.
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.
The BRAND NEW HTML 5!
Almost as good as TeX!
If moderation could change anything, it would be illegal.
Here's a link to the latest HTML 5 working draft (published today) for those who like their information first-hand.
Spelling mistakes, grammatical errors, and stupid comments are intentional.
Sweet! Can I get my $80K a year job back doing HTML for a dotcom?
It's 1999 all over again, baby!
There are 01 kinds of cars in the world. The General Lee, and everything else.
I sure hope one of the new elements is finally permablink!
This will work wonderfully because the HTML standard was designed from the ground up with graceful degradation in mind.
.article { font-family: serif; }
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.
Visit http://ringbreak.dnd.utwente.nl/~mrjb/growingbettersoftware to download your free copy of the book
Oh, hey, look at that. JsonML. Styled by CSS even. Who would have guessed?
Javascript + Nintendo DSi = DSiCade
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.
+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.
</> 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"