Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Finally We Get New Elements In HTML 5

ScuttleMonkey posted more than 7 years ago | from the not-so-patiently-waiting dept.

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

cancel ×

378 comments

Sorry! There are no comments related to the filter you selected.

Oh noes! (3, Funny)

HitekHobo (1132869) | more than 7 years ago | (#20159461)

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

Re:Oh noes! (-1, Flamebait)

Anonymous Coward | more than 7 years ago | (#20160025)

Same goes for /. that can't even get their CSS to work right.

/flamebait

Excellent! (5, Interesting)

Anonymous Coward | more than 7 years ago | (#20159479)

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! (5, Funny)

Conspiracy_Of_Doves (236787) | more than 7 years ago | (#20159627)

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! (3, Insightful)

Anonymous Coward | more than 7 years ago | (#20159871)

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 [wikipedia.org] .

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! (5, Insightful)

patman600 (669121) | more than 7 years ago | (#20160221)

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! (1)

Richard_at_work (517087) | more than 7 years ago | (#20159881)

In that case why not add a 'semantic' attribute to <div> tags and allow users to add whatever semantics they wish? I personally liked the way HTML has been going - minimalistic.

I agree! (0)

Anonymous Coward | more than 7 years ago | (#20159887)

And all browsers should pipe those to /dev/null.

Re:Excellent! (1)

dbc001 (541033) | more than 7 years ago | (#20159949)

Can't machine parsing like that be done with microformats? While it's neat that search engines can easily figure out where the is with these new elements, they'll get abused into oblivion just like meta keywords and descriptions. I don't see any real value to adding these new elements.

Re:Excellent! (5, Insightful)

rhartness (993048) | more than 7 years ago | (#20160279)

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! (0)

Anonymous Coward | more than 7 years ago | (#20159665)

You missed the point. The new tags do not rely on site specific CSS, and are designed to perform a set function across different devices and accessibility users. Go back and RT full FA!

Re:Excellent! (5, Insightful)

LighterShadeOfBlack (1011407) | more than 7 years ago | (#20159669)

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! (1)

trolltalk.com (1108067) | more than 7 years ago | (#20159859)

Of course there's no reason you can't just serve it as xml tags with an associated stylesheet ... but this is still a "Good Thing".

Re:Excellent! (0, Redundant)

DragonWriter (970822) | more than 7 years ago | (#20159989)

An article, as division of a document, is semantically no different than any other division of a document. So there is no semantic difference between:

<article>...</article> and <div class="article">...</div>

Inasmuch as there is a difference between an "article" and another division of the document, the distinction is purely a matter of the internal heirarchical structure of a specific document. There is no consistent interpretation that can or should be applied to an "article" beyond that of a division of a document.

Re:Excellent! (4, Informative)

LighterShadeOfBlack (1011407) | more than 7 years ago | (#20160343)

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

Just Some Guy (3352) | more than 7 years ago | (#20160095)

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:Excellent! (0)

Anonymous Coward | more than 7 years ago | (#20160323)

because there will always be someone to use

Re:Excellent! (1)

thewiz (24994) | more than 7 years ago | (#20159687)

Just as long as they got rid of the tag.

My retinas will never be the same...

Re:Excellent! (4, Funny)

corsec67 (627446) | more than 7 years ago | (#20159753)

Apparently slashdot got rid of it for you...

Re:Excellent! (1)

Corporate Troll (537873) | more than 7 years ago | (#20159829)

Try using HTML entities next time. Those have been in the spec for a long time ;-) &gt; for > and &lt; for <....

Re:Excellent! (4, Insightful)

peter_gzowski (465076) | more than 7 years ago | (#20159817)

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! (2, Informative)

e4g4 (533831) | more than 7 years ago | (#20159861)

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! (2)

PipianJ (574459) | more than 7 years ago | (#20159933)

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 [microformats.org] ) 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! (3, Insightful)

telbij (465356) | more than 7 years ago | (#20160051)

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! (1)

ajs (35943) | more than 7 years ago | (#20160063)

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:Excellent! (1)

Lumpy (12016) | more than 7 years ago | (#20160119)

Yes there IS a difference. I can set ALL aspects of that div.

If you can do the same with the article tag, then they are adding things for the sake of adding them.

Oh great... (4, Funny)

Bazman (4849) | more than 7 years ago | (#20159493)

More things for IE to not support properly.

Re:Oh great... (1)

Spy der Mann (805235) | more than 7 years ago | (#20159891)

More things for IE to not support properly.

Or in other words...

Let the Browser Wars II... BEGIN!

Re:Oh great... (1)

lonechicken (1046406) | more than 7 years ago | (#20160059)

Or in other words... Let the Browser Wars II... BEGIN!


In A.D. 2007 Browser Wars II was beginning...
What happened???...

Re:Oh great... (4, Funny)

Praedon (707326) | more than 7 years ago | (#20160249)

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

How about a Declarations area? (2, Funny)

WED Fan (911325) | more than 7 years ago | (#20159497)

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? (2, Interesting)

Anonymous Coward | more than 7 years ago | (#20159501)

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? (4, Informative)

_xeno_ (155264) | more than 7 years ago | (#20159599)

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.

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

Anonymous Coward | more than 7 years ago | (#20159837)

The starcraft2.com website takes an approach like that.

The main page is:

(Go and check it out if you don't believe me)

Re:Can't we do all this stuff already? (0, Troll)

trolltalk.com (1108067) | more than 7 years ago | (#20159959)

"Which, assuming you want to support IE users, means no."

You can support IE users ... just inlcude links to the download pages for Opera [opera.com] , Firefox [mozilla.com] , Netscape [netscape.com] , Safari [apple.com] , etc.

Better yet, give them full support - have them download a bootable linux distro to replace Vista Millennium [ubuntu.com] .

Re:Can't we do all this stuff already? (1, Informative)

Anonymous Coward | more than 7 years ago | (#20159979)

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

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

morgan_greywolf (835522) | more than 7 years ago | (#20159611)

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


Shhhhh! Don't tell anyone that! I was trying to keep it a secret!

Seriously, what's wrong with XHTML and CSS?

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

Anonymous Coward | more than 7 years ago | (#20160129)

Yes it is possible to include other tags in XHTML documents, and then use CSS to determine how they are presented. Note the emphasis on presented. More tags mean we can define what parts of the document MEANS.

For example, you could style a definition list using nothing but SPAN or DIV tags. However, HTML has a definition list element to be used. Then, when spiders like Google are indexing your page, it has a better way of knowing what is what and can more accurately summarize your content.

I'll tell you why... (2, Funny)

Orig_Club_Soda (983823) | more than 7 years ago | (#20159519)

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

Re:I'll tell you why... (1)

telbij (465356) | more than 7 years ago | (#20159587)

Huh? How do you use CSS without HTML?

Re:I'll tell you why... (1)

AKAImBatman (238306) | more than 7 years ago | (#20160031)

How do you use CSS without HTML?

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... (3, Informative)

AKAImBatman (238306) | more than 7 years ago | (#20160107)

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

Re:I'll tell you why... (1)

ubernostrum (219442) | more than 7 years ago | (#20160047)

How do you use CSS without HTML?

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

Re:I'll tell you why... (1)

J. Dunlap (915807) | more than 7 years ago | (#20159729)

It's bad to use HTML tags and attributes for styling (colors, fonts, etc) when CSS does as well or better. It's *good* to use HTML to define the *structure* and *content* of the document - and that's what these new tags facilitate.

Re:I'll tell you why... (1)

Orig_Club_Soda (983823) | more than 7 years ago | (#20160097)

...and HTML elements come with styling that you have to suppress and replace with CSS.

Re:I'll tell you why... (1)

Corporate Troll (537873) | more than 7 years ago | (#20159895)

What I think is behind the new tags is that the average Joe that wants to make a webpage can handle HTML fine, but CSS is too hard. Classes, inheritance, boxing, all that stuff requires you to know quite a bit. In comparision HTML 4.1 was easier. I don't agree with the sentiment since I think XHTML+CSS is better for the job.

Re:I'll tell you why... (1)

Orig_Club_Soda (983823) | more than 7 years ago | (#20160187)

The problem with CSS - and I find it a healthy challenge - is that no two browsers render it the same. The more browsers my patron is aware of, the more duplicate work must be done.

However, we are purists. We are not looking at it from the common person's perspective. When joe-consumer browses, all he cares about is that the site works and the page is not all screwed up. How that is accomplished is unimportant.

And what we in America have to worry about is that as the difficulty in achieving this increases; the higher the labor costs; the more likely the web designing and developing jobs will move overseas.

Do we need "MORE"? (3, Insightful)

Puls4r (724907) | more than 7 years ago | (#20159533)

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"? (2, Insightful)

garett_spencley (193892) | more than 7 years ago | (#20159701)

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"? (2, Insightful)

Doctor Crumb (737936) | more than 7 years ago | (#20160069)

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"? (1)

Azarael (896715) | more than 7 years ago | (#20159765)

I expect that browser vendors will implement the new tags by reusing the exact (or vary similar) behavior of old tags. As mentioned in a couple posts above, something like isn't really different than
, aside from their semantic value. Basically, if this ends up being the case, we won't be worse off, just left with the same display incompatibility problems that we already have. And those problems aren't really a problem from the W3C, but the vendors.

Re:Do we need "MORE"? (1)

Azarael (896715) | more than 7 years ago | (#20159869)

Oops /. text replacement

something like isn't really different than ,
should be

something like {article} isn't really different than {div class="article},
Replace braces with gt and lt.

Re:Do we need "MORE"? (0)

Anonymous Coward | more than 7 years ago | (#20159843)

I mean, seriously - I can do anything I need to do with a web page with the tools we have right now.

I remember hearing the same argument a decade ago. I'm assuming you never use anything like gMail or YouTube, and that when you browse Slashdot you force it not to use CSS or anything, right?

Re:Do we need "MORE"? (3, Interesting)

Heian-794 (834234) | more than 7 years ago | (#20160197)

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 [inkedblade.net] to guarantee correct display for any browser, even though word processors have had this essential feature for years.

Re:Do we need "MORE"? (1)

Escogido (884359) | more than 7 years ago | (#20160117)

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?
It's probably just a clever ruse to make Microsoft and other browser developers to finally support HTML 4.

Not unlike during negotiations, when one party proposes something that will obviously be never accepted by the other party, and they consent on something halfway.

Web 1.0 (2, Funny)

Applekid (993327) | more than 7 years ago | (#20159537)

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? (3, Interesting)

fredrated (639554) | more than 7 years ago | (#20159539)

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

Re:what happened to xhtml? (2, Insightful)

glop (181086) | more than 7 years ago | (#20159639)

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? (2, Interesting)

DrSkwid (118965) | more than 7 years ago | (#20159789)

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? (1)

Spy der Mann (805235) | more than 7 years ago | (#20160369)

The revolution of XHTML failed to change the world

Not quite... i think the XHTML revolution was more like a silent one. You can't see it, but it's there. It's in javascript dom handling, in XSLT webpage generation, in less-cluttered webpages... and don't forget that RSS is an XML format, too.

But if we admit that the XHTML revolution did fail, it was not because of the standard itself: XSLT browser support came too late, and incomplete (proprietary extensions, features neglected by the designers). If IE6 and Netscape/Mozilla/whatever had implemented XSLT as they should, all the webpages today would be in an xml format. Another important factor was advertising (without free webpages there wouldn't be blogs or social networking sites today, and free webpages always come with ads). Advertisers didn't put the effort to use XHTML-compliant code in their ads. And last, but not least, IE6 stagnation contributed a lot to it.

Perhaps XHTML came either too late, or too soon. If it had come before Netscape 4, perhaps the web would be VERY, VERY different today.

Re:what happened to xhtml? (1, Interesting)

Anonymous Coward | more than 7 years ago | (#20159677)

Opera decided it wasn't in their best interest to make things easy for their competitors, so they and Apple got together and decided to enshrine IE5 bug-compatibility in a spec, then they started a competitor to W3C called WHAT-WG and announced they would now be running things there, so W3C invited them in to do their thing there.

Re:what happened to xhtml? (1)

jandrese (485) | more than 7 years ago | (#20159749)

XML turned out to be a pain in the butt and people ended up preferring HTML instead.

Re:what happened to xhtml? (0)

Anonymous Coward | more than 7 years ago | (#20160233)

What happened? In a nutshell, nobody could be bothered to get off their ass and recode their web pages, let alone web browsers.

Good and bad at the same time (3, Interesting)

chriss (26574) | more than 7 years ago | (#20159541)

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:Good and bad at the same time (1)

Paulrothrock (685079) | more than 7 years ago | (#20159845)

The only problem I have with XHTML/CSS is browsers that don't support it properly.

Up to now, new HTML elements... (4, Funny)

Anonymous Coward | more than 7 years ago | (#20159563)

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

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

D4C5CE (578304) | more than 7 years ago | (#20159575)

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

OK whats in it for me. (1)

jellomizer (103300) | more than 7 years ago | (#20159591)

It is going to take a long time before web developers can take advantages of these tags. We need the browsers to start using it which may take a while. Firefox may jump on first then maybe Safari and others IE will probably take 2-3 more years until it supports HTML 5. Problem is the faster the Web Grows the harder it will be to put in new versions of html. HTML v1-3 changed quite quickly and easilly 4 took some time (and still isn't 100% supported) and 5 will take much longer. Ill stick with 4.01 until I know that 95% of the people are using it, or can support it.

This just in from Microsoft HQ... (1)

wamerocity (1106155) | more than 7 years ago | (#20159597)

Just as the new HTML 5 standard was finished and announced, Microsoft announced a new "open-source" (wink, wink) version called OO-HTML that they say is just as good* and we should all use.

font size 3> *Microsoft reserves the right to only allow this HTML standard to be running on copies of the latest and most expensive version of Windows, with WGA activated. /font size 3

Re:This just in from Microsoft HQ... (1)

lonechicken (1046406) | more than 7 years ago | (#20159771)

*Microsoft reserves the right to only allow this HTML standard to be running on copies of the latest and most expensive version of Windows, with WGA activated.
You forgot the part about requiring DirectX 11 compliant hardware.

The most greatly wanted tag (5, Funny)

Anonymous Coward | more than 7 years ago | (#20159601)

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 (1)

dunkelfalke (91624) | more than 7 years ago | (#20159941)

actually the most wanted tag is the irony tag.

So do tags ever deprecate? (5, Interesting)

lonechicken (1046406) | more than 7 years ago | (#20159615)

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.

Re:So do tags ever deprecate? (0)

Anonymous Coward | more than 7 years ago | (#20159853)

Yes, tags do deprecate. There are plenty of deprecated tags in HTML4 for instance.

People keep using them because W3C never bothers to explain what they were deprecated by, and people still want the functionality of those tags.

Re:So do tags ever deprecate? (1)

DragonWriter (970822) | more than 7 years ago | (#20160169)

Years from now, are we still going to see IE 10, Firefox 5, and Safari 3.1 support deprecated tags?


A "deprecated" tag is one that implementations should support, but developers should not use for new pages, since it is planned to be removed as "obsolete" in a future version of the standard.

An "obsolete" tag is one that it is no longer expected that implementations will support.

Supporting deprecated tags is what browsers should do.

Finally! The return of the tag! (1)

wiredog (43288) | more than 7 years ago | (#20159631)

Cat got your tongue? (something important seems to be missing from your comment ... like the body or the subject!)

Announcing (5, Funny)

Bluesman (104513) | more than 7 years ago | (#20159643)

The BRAND NEW HTML 5!

Almost as good as TeX!

Re:Announcing (3, Interesting)

annamadrigal (1134821) | more than 7 years ago | (#20160309)

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

Oh crap. (1)

Stumbles (602007) | more than 7 years ago | (#20159721)

Phht, no HTML standard can possibly be complete without *OFFICIAL* sarcasm tags.

Re:Oh crap. (1)

Spy der Mann (805235) | more than 7 years ago | (#20160033)

Phht, no HTML standard can possibly be complete without *OFFICIAL* sarcasm tags.

<sarcasm>You're ABSOLUTELY RIGHT!</sarcasm>

Link to the actual WHATWG Working Draft for HTML 5 (4, Informative)

LighterShadeOfBlack (1011407) | more than 7 years ago | (#20159723)

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

Improvements in search (2, Insightful)

efbee (607166) | more than 7 years ago | (#20159757)

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

Re:Improvements in search (1)

IBBoard (1128019) | more than 7 years ago | (#20159919)

That will, of course, rely on the fact that people actually use it properly. How many people do you see now who use tables for layout? Or spans with titles and styling when they should use abbr or acronym tags?

The idea is good, and if search engines like Google could pay attention to it in a "semantic web" kind of way then it would be a big bonus, but I can't see take up and use being too quick.

Wonderful! (1)

Eberlin (570874) | more than 7 years ago | (#20159787)

I'm glad for all the innovation and improvements -- but how well-received will it be with the browser makers? Just saying that with all these wonderful standards we have, they're only good if everyone follows them. You know, like standards.

I understand it takes a lot of effort to comply and some software makers may not be properly motivated to do so. We can only hope that a renewed(?) browser war may add some pressure.

How are the browsers doing on the current standards anyway (HTML, CSS, etc.)? Right. I thought so.

I'm in the money! (4, Funny)

El_Smack (267329) | more than 7 years ago | (#20159841)

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

permablink? (4, Funny)

jdunlevy (187745) | more than 7 years ago | (#20159875)

I sure hope one of the new elements is finally permablink [kibo.com] !

Cut off back support (1)

pembo13 (770295) | more than 7 years ago | (#20159923)

Would be nice if browsers remove (likely troublesome) code for support of older versions now. It would be nicer if IE did logical things with it's rendering too, but I've kinda given up home on that.

yabbut (1)

AriesGeek (593959) | more than 7 years ago | (#20159947)

Yeah, but we all know the browsers won't implement new tags, or will only half-ass them. Even if they fully implement the new tags, it won't look the same across browsers. The days of the www being about content rather than looks are long-since over. We want our web pages to look good on any browser. This won't happen.

Sorry folks, try again.

Knuth would be proud (0)

Anonymous Coward | more than 7 years ago | (#20160019)

HTML5 looks a hell of a lot like LaTeX.

RISC versus CISC (1)

athloi (1075845) | more than 7 years ago | (#20160029)

More instructions, or fewer instructions with more modes? That's an eternal design question, right there. I guess the pure layout mode of HTML was more popular, especially after the cross-browser mess, and so it's back after CSS.

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 (4, Informative)

mrjb (547783) | more than 7 years ago | (#20160065)

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.

Too Late (1)

N8F8 (4562) | more than 7 years ago | (#20160085)

You can wait till the W3C dorks about with HTML5 for the next decade and browser vendors drag ass in implementing it or you can just start using Silverlight. Some choice.

What if (-1, Offtopic)

Anonymous Coward | more than 7 years ago | (#20160093)

we're invaded by aliens and they don't think as we do, making concepts such as nav and articles completely meaningless to their anal probing ways?

With all non-existing respect, HTML5 tags are not necessary to accomplish the same effect.

XHTML/HTML divergence (5, Insightful)

Animats (122034) | more than 7 years ago | (#20160171)

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.

How about an HTML editor control? (1)

parvenu74 (310712) | more than 7 years ago | (#20160239)

How about an HTML editing control?

whatever happened to... (1)

dgun (1056422) | more than 7 years ago | (#20160251)

My blink tag?

<blink>Hello World!</blink>

Netscape 3 FTW. But seriously, I'm glad to see that HTML is being updated. I guess the W3C has given up hope on everyone dumping HTML for XHTML?

The <BLINK> Tag (2, Funny)

sjaguar (763407) | more than 7 years ago | (#20160303)

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

May me redundant... (2, Interesting)

thatskinnyguy (1129515) | more than 7 years ago | (#20160325)

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

<article><entry>etc...

RSS (2, Informative)

C0y0t3 (807909) | more than 7 years ago | (#20160359)

From TFA:

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


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

Where do I get my "enhanced for HTML 5" banner? (1)

dpbsmith (263124) | more than 7 years ago | (#20160399)

Oh, boy! I can hardly wait to decorate my website with all of these new elements! I haven't been so excited since the day I gave my entire home page the blink attribute!

Now all I want to know is, where can I get a spiffy "Enhanced for HTML 5" GIF to put on my web page so that everyone will know I'm hip and up to date?
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>