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

Oh noes!

[HitekHobo]

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

Excellent!

[Anonymous Coward]

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!

[Conspiracy_Of_Doves]

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!

[Anonymous Coward]

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!

[LighterShadeOfBlack]

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!

[thewiz]

Just as long as they got rid of the tag.

My retinas will never be the same...

Re:Excellent!

[corsec67]

Apparently slashdot got rid of it for you...

Re:Excellent!

[peter_gzowski]

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!

[Corporate Troll]

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

Re:Excellent!

[trolltalk.com]

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!

[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:Excellent!

[Anonymous Coward]

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.

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!

[Richard_at_work]

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

Re:Excellent!

[PipianJ]

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

[dbc001]

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!

[DragonWriter]

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!

[telbij]

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!

[ajs]

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!

[Just Some Guy]

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!

[Lumpy]

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.

Re:Excellent!

[patman600]

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!

[rhartness]

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!

[Anonymous Coward]

because there will always be someone to use

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.

Re:Excellent!

[rtaylor]

The difference between <div class="article"> and <article> is that "<article>" has some implied meaning that a search engine will in fact be able to infer. This has little to do with display in a browser. It has quite a bit to do with giving search engines the intelligence to focus on important components of the page.

Re:Excellent!

[hobo sapiens]

Right. And not only that, according to tfa "Apple, Opera, and the Mozilla Foundation" got together to do this. We all like these companies, but until they get buy-in from Macrosuck, we'll be coding IE hacks for our entire careers. That pisses me off. Microsoft once propelled the web forward, now they are holding it back with their ~90% marketshare coupled with pigheaded unwillingness to let the web evolve.

Re:Excellent!

[LighterShadeOfBlack]

Yes it would be as easy for a parser to determine semantics from attributes as it would from elements. But you would still need the attribute to be defined in a specification like HTML 5 in order for it to be any use. As it is now there are millions of sites which use thousands of different names for their classes to specify their article text. Which isn't any use to anyone except the web page owner. Google can't create a parser that accounts for class="article", class="blogpost", class="pink_and_green_article" and every variation on those themes (well they could try, but it wouldn't be very effective). So if it has to be defined in a specification there's no benefit in using an attribute over a new element, whereas there are potential benefits in using a new element over using an attribute. Such as having additional attributes specific to that semantic type (there aren't any for the <article> element but there are for some other semantic tags).

Re:Excellent!

[poot_rootbeer]

I would have preferred HTML 5 to add things that I could use (perhaps an include or multi-file-select)

Or how about a combobox form widget! Faking such a control in the existing HTML language requires a ridiculous amount of Javascript and cleverness...

Re:Excellent!

[fyngyrz]

designed to perform a set function across different devices

Not very well, though. For instance, with regard to the audio tag, "Browsers must support the WAV format. Browsers can also support other formats such as MP3 if they like."

Talk about getting something backwards. MP3 is the defacto standard. WAV? OMG WTF. Way to waste bandwidth.

Re:Excellent!

[Anonymous Coward]

I don't quite get why don't we just use XML. No need to wait for a predefined set of tags. If is missing, just write proper definitions and transformations. At this pace we're never gonna get fully semantical net.

Re:Excellent!

[Anonymous Coward]

And how is <div class="article"> not machine parsable? OK, so what does "article" actually mean here?

How about <div class="artigo">? What does that mean?

Or <div class="Artikel"> or <div class="articolo">? Is that the same thing? If so, how does the machine know that? If not, why not? It's the same damn word, just different languages.

Re:Excellent!

[Anonymous Coward]

And how is <div class="article"> not machine parsable? Easy, who and what is telling anyone to use the class name "article" instead of "story" or even spelling that class name in a different language.

I'll tell you who, nobody except for English speaking geeks.

It's not a standard, never will be. Thus new HTML tags.

Re:Excellent!

[jalefkowit]

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.

But you don't need new tags for that. You could just come up with a standardized list of attributes for common uses. XHTML2 uses a new attribute, "role", to accomplish this, for example. So the standard defined a list of common ROLEs (like, say, "role=navigation" or "role=advertisement"), you could have, say:

<div role="advertisement">Buy Crelm Toothpaste!</div>

... and get the same effect as an ADVERTISEMENT tag, and at the same time make it easier to extend the list of defined elements in the future (since you could just extend the list of ROLEs, and not have to re-do the whole spec).

The HTML WG is considering a similar mechanism, only using the CLASS attribute instead of ROLE. Personally I think that's a bad idea, since CLASS carries style information, not semantic information, and there's probably already a ton of documents out there using, say,

<div class="navigation">

... and their owners are gonna be really surprised when browsers suddenly start parsing those classes in new and unexpected ways.

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!

[nuzak]

> MP3 is the defacto standard. WAV? OMG WTF. Way to waste bandwidth.

WAV by itself isn't even all that meaningful, since a .wav extension on windows can be ANY audio format it can recognize. Try it, rename a .mp3 with .wav, and it'll play back. They probably mean 44.1 stereo PCM, which is the red book standard on CDs. If you're aiming for a minimum, PCM .wav or Mu-law .au is a good one to shoot for.

MP3 is yesterday's lossy format that's absolutely obsolete in today's MPEG standards (do recall what MP3 was part of) and it's got patent issues up the wazoo (not that AAC is free of those either).

Re:Excellent!

[MagicM]

A combobox can be achieved per the Web Forms 2 specification using a datalist element:

For the text, email, url, date-related, time-related, and numeric types of the input element, a new attribute list is introduced to point to a list of values that the UA should offer to the user in addition to allowing the user to pick an arbitrary value.

Re:Excellent!

[Just Some Guy]

Yes it would be as easy for a parser to determine semantics from attributes as it would from elements. But you would still need the attribute to be defined in a specification like HTML 5 in order for it to be any use.

Someone already mentioned microformats, which I believe would be a better solution in that:

1. They don't involve modifying the underlying schema. A document with add microformats is just as valid as that document without them.
2. They're more ad-hoc and don't require waiting for a central committee to approve each and every one. The guys working on the "geo" microformat don't have to wait for the hResume team to finish their spec before releasing updates.

I think Google would be in a prime position to push adoption of selected microformats (as they already have with 'rel="nofollow"'): "wrap your articles in the <div class="article"> tag and watch your Pagerank climb!" If there were a real need for this, I think they could have done it by now.

Re:Excellent!

[Bogtha]

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!

[icepick72]

Then I suggest adding an "intention" attribute to div/span and standardize on a few commonly-used names like: etc. The developer can also create other non-standard names for proprietary use.

Re:Excellent!

[LighterShadeOfBlack]

Well at this point it's important to note one of the things that HTML 5 is not: XML. HTML 5 is plain-old HTML, meaning it's syntactically forgiving (ie. case-insensitive elements and attributes, closing tags optional). That might not be important for you or me or most other Slashdot users but for the vast majority of people that kind of forgiving behaviour is very important. Can you imagine what Myspace would look like if everyone were required to use Strict XHTML or XML+XSL on their pages? Errors as far as the eye can see I'd wager (whether that would actually be better than Comic Sans and animated backgrounds is another matter).

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:Excellent!

[edwdig]

Is there a requirement that attributes can't be semantic? Like the GP asked, what's the inherent difference between and ? It'd be equally easy to configure a parser to treat each of those as semantic markup.

The difference is the div class approach is already defined to not have any meaning other than that defined by the page. Changing that now would have side effects for a lot of existing documents.

Re:Excellent!

[Asmor]

Actually, they need to put in an <ad> tag. Amusing, but actually scary when you think about it... The only way such a tag would actually be implemented by people with advertising is if there were DRM-like restrictions on browsers forcing ads to be shown. I'm sure it wouldn't be hard to get IE to implement such restrictions, and honestly I wouldn't be surprised if they found a way to force Firefox to implement them too. So i say nay to <ad>.

Re:Excellent!

[lgw]

Actually, they need to put in an tag. Wasn't there an RFC about this?

<div evil_bit="1"></div>

Re:Excellent!

[Conspiracy_Of_Doves]

Ok, ok. is a bad idea. I'm an honest person, so my first instinct before I have a chance to think about things is that other people will be honest too.

They should put in some kind of tag to indicate that search engines and other parsing scripts shouldn't pick up on the tag's contents.

Re:Excellent!

[fm6]

More tags for browsers to neglect to implement!

Since this spec is written by a consortium of browser vendors, it actually has a good chance of getting implemented. That's different from all those W3C specs that browser vendors view as containing "optional features". Then again, a certain browser vendor that has 90% of the market is notably absent from this venture.

Re:Excellent!

[Anonymous Coward]

Great question! And semantically, what is the difference between:

<apple>...</apple>

and

<orange class="apple">...</orange>

Answer: Nothing, as long as you invent your own definition of semantics.

Re:Excellent!

[Ahnteis]

It's easier to find a single

</article>

tag than it is to locate one of the many nested

</div>

tags?

Just one thought.

Re:Excellent!

[smartr]

indeed! Not only will it be easier to read, but it also will be more writable. Throw in the fact that it will add in the ability to have much more intelligent behavior of tables (datagrid) and menus. I don't think everyone should have to dive into various javascript wheels (prototype, dojo, and various others) for simple common GUI elements.

Re:Excellent!

[LighterShadeOfBlack]

Microformats certainly serve a purpose, but if given the choice between writing my web pages to a full specification like HTML 5 versus writing it to HTML 4 with a microformat extension I think it goes without saying that the former is preferable for most people. As you say, microformats allow for faster changes to make up for the inherent slowness of the major formats like HTML, but I don't see any reason why that should mean that when HTML does make changes it should shy away from improvements in lieu of letting a microformat deal with it.

If anything the additional elements just provide more ways in which microformats can improve the specification by filling in the details that HTML is unable to due to its scope. For example a search engine could now choose to support a microformat extension to article elements that told them exactly what kind of article it was. Get a few major blogging frameworks to support an extension like <article class="blog"> and suddenly Google Blog Search no longer needs you to have an RSS feed to get your blog's content. Get a few major newspaper websites supporting <article class="news"> and you've got Google NewsHound. Of course all of that was possible with microformats without the article element, but like it or not the big formats still pull a lot more weight which makes people much more likely to take notice when it goes at least some of the way towards making these things happen.

Re:Excellent!

[prockcore]

Seriously. Using the GP's logic, all of html can be replaced with

Re:Excellent!

[prockcore]

arg, I meant everything can be replaced with

<div class="table"> <div class="h1"> <div class="href">

Re:Excellent!

[Xtravar]

And so how do advertising campaigns fit into this wondrous new paradigm where web developers supposedly have the competence and ethics to only put an article in an article tag?

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:Excellent!

[ShieldW0lf]

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.

The difference is that the first example supports creating powerful css designs that take advantage of inheritance, because the "article" is still a "div", while the second example doesn't take advantage of inheritance, and is thus a step backwards.

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:Excellent!

[Rorzabal]

The intent of making the article tag for accessibility is good. However, you know that people are going to start wrapping their advertisements in article tags, defeating the noble goal.

Re:Excellent!

[cmburns69]

Content and presentation have been slowly merging over the course of the web. Adding these semantic tags appears to be an attempt to separate the presentation from the content.

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 implementations within HTML4, and I suspect that this will not really help us web developers. /RANT

Re:Excellent!

[Excors]

a certain browser vendor that has 90% of the market is notably absent from this venture.

That's not really true, since Microsoft is present in the HTML WG which is now working on HTML 5, and Chris Wilson is a co-chair of the group. They have been extremely quiet in the group so far, though.

Re:Excellent!

[Ross D Anderson]

Shhhhhh! Don't give them ideas!

Re:Excellent!

[jilles]

I agree though semantically the difference is that the article tag is going to be standardized, and the div of class article is not. You should of course use the hatom microformat instead and then you would end up using a div with class "hentry". Unlike the article tag, you can use that right now and tools already exist that do smart things with it (e.g. firefox operator extension).

Here lies the real problem. Much of the stuff that html 5 adds is sort of redundant (and in some cases inconsistent with) these microformats; and common use of existing tags. HTML 5 is backwards compatible in the sense that existing browsers will ignore its new tags, not in the sense that stuff works as expected. For example, if you don't want people to see the video on your website then use the new video tag (i.e. don't expect this to show up on youtube any time soon). The old stuff on the other hand is forward compatible and will continue to work. So there is no point at all in using these tags unless you want old browsers to break on your site.

Most content is generated rather than handcrafted so an article tag provides just unneeded syntactic sugar rather than improved semantics. As microformats demonstrate today the use of div and abbr tags combined with use of class names as semantic tags provides plenty of syntax to add all sorts of complicated semantics and ontologies. Compared to that the HTML 5 additions are redundant, rather arbitrary and not really that useful.

So basically, I would encourage the HTML 5 editors to remove all the misguided semantic cruft and focus on consistency and real improvements instead of compatibility breaking syntactic sugar. What is needed is less tags (i.e. deprecate stuff instead of adding stuff). Instead of redoing XHTML, they should endorse and formalize many of the microformats that already cover a wide range of common semantics in a way that really backwards compatible. In so far semantics are missing, new microformats should be suggested rather than compatibility breaking new html constructs.

Re:Excellent!

[Bogtha]

Personally I think that's a bad idea, since CLASS carries style information, not semantic information

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.

there's probably already a ton of documents out there using, say [...] and their owners are gonna be really surprised when browsers suddenly start parsing those classes in new and unexpected ways.

No, they wouldn't be parsed any differently, but they might be rendered differently.

Re:Excellent!

[Jugalator]

More bastardization of already bastardized HTML... and even more new ways to fuck things up.

Actually they've been throwing out a lot of bastardized HTML, like FONT tags and other tags that mix up formatting and disposition.

Re:Excellent!

[Anonymous Coward]

What does a screen reader on Viagra sound like?

Re:Excellent!

[Bogtha]

Well at this point it's important to note one of the things that HTML 5 is not: XML. HTML 5 is plain-old HTML, meaning it's syntactically forgiving (ie. case-insensitive elements and attributes, closing tags optional).

Actually, it's not plain-old HTML either. It's no longer based on SGML, HTML 5 defines its own parsing rules.

Can you imagine what Myspace would look like if everyone were required to use Strict XHTML or XML+XSL on their pages? Errors as far as the eye can see I'd wager

I wouldn't. Have you noticed that practically everybody using a custom page layout on MySpace uses a tool to do it? Jane Random Teen isn't writing HTML by hand. If any tool like that produced errors, people would simply use one that didn't.

Raw XML is learnable too, if somewhat inconvenient for beginners in its strictness when hand-editing.

Strictness isn't inconvenient for beginners, laxness is. The traditional laxness of HTML lets beginners twist their code further and further out of shape until when their code finally breaks, they've got so much to fix that they don't know where to begin. They just start hacking at it randomly hoping to change something that might have an effect. XML, on the other hand, has regular rules, and lets you know the second you screw up, so you don't get ahead of yourself, so you know which change it was that broke your page, so you have a chance of learning the rules.

Laxness has a reputation for being beginner-friendly because it enables beginners to speed ahead without really learning what it is they are doing. Thinking that's a good idea is short-sighted though, because as soon as they run into difficulty, they are already way out of their depth. Strictness is better in the long run.

Re:Excellent!

[fm6]

I stand corrected. I was misled by TFA, which indicated that this revision of HTML is being done by a group external to W3C, one that does not include Microsoft. Rusty is a good (I would even say "great") technical writer, but he's sometimes sloppy with non-technical facts.

On the other hand, Microsoft has a nasty history of not following standards, even ones they helped develop. Hopefully, they're outgrowing that sort of thing. I'd like to think that they're showing signs of losing their "my way or the highway" attitude since Mr. Bill has given up his "software architect" role.

Re:Excellent!

[porneL]

Well at this point it's important to note one of the things that HTML 5 is not: XML.

This would be correct if you used <blink> instead of <b> ;)

HTML 5 gives you choice of serialisations and you can either use HTML or XML. It doesn't affect semantics. As a perk, HTML 5 as HTML allows some stray slashes and xmlns attributes, so with little fiddling you can have one document that's compatible with both at the same time (so you can work around Firefox's inability to parse block elements in new tags and IE's inability to do anything with XHTML 5).

Re:Excellent!

[LighterShadeOfBlack]

Actually, it's not plain-old HTML either. It's no longer based on SGML, HTML 5 defines its own parsing rules. I haven't gotten into the depths of the HTML 5 spec. but AFAIK it hasn't actually changed from previous versions of HTML at a practical level. All that's really happening I believe is that they're officially specifying the behaviour that every browser already uses. Bascially they're retconning HTML parsing to make every implementation correct instead of trying to get browsers to change.

I wouldn't. Have you noticed that practically everybody using a custom page layout on MySpace uses a tool to do it? Jane Random Teen isn't writing HTML by hand. If any tool like that produced errors, people would simply use one that didn't. Not writing by hand, but from what I've seen (admittedly not a great deal) they do often copy and paste peices of HTML from multiple sources which can very easily lead to nesting issues under XML variants.

Strictness isn't inconvenient for beginners, laxness is. The traditional laxness of HTML lets beginners twist their code further and further out of shape until when their code finally breaks, they've got so much to fix that they don't know where to begin. They just start hacking at it randomly hoping to change something that might have an effect. XML, on the other hand, has regular rules, and lets you know the second you screw up, so you don't get ahead of yourself, so you know which change it was that broke your page, so you have a chance of learning the rules.

Laxness has a reputation for being beginner-friendly because it enables beginners to speed ahead without really learning what it is they are doing. Thinking that's a good idea is short-sighted though, because as soon as they run into difficulty, they are already way out of their depth. Strictness is better in the long run. HTML's forgiveness isn't cumulative in most cases though. Generally speaking if you can get away with something once you can get away with it a thousand times and never experience an actual break. You can't really keep twisting more and more because you're not technically doing anything wrong, just being a bit scrappy at worst. If you do something truly wrong then odds are it will show in the rendering and can be fixed from there. XML can be inconvenient due to its strictness but is still very much useable as I said. But using XSL is simply not a practical option for Joe Averageuser which makes the useability of XML a bit of a moot point really. OK so there's XHTML 2.0 which is both XML and presentational, but that seems to be continually diverging from the common-man perspective with each passing day and each new "module", which is presumably one of the main reasons HTML 5 has come about at all.

Re:Excellent!

[Anonymous Coward]

At which point you may just as well write XHTML 1.0 or do semantic XML and serve all documents via XSLT. We can standardize XML schema for anything and everything.

Another thing; the XML serialization of WTFWG HTML doesn't support the noscript element and half their proposal consists of scriptable DOM extensions. It's a complete joke.

Re:Excellent!

[XavidX]

Thats exactly the point. Isnt this partly why xml is invented and thus we are able to use one format and use xsl style sheets to translate the xml into whatever you want.

So why not just use xml.

And this includes xml with tags. I dunno perhaps I will think of something useful for these tags one day when I see them, but right now it seems like people are just trying to invent something new just because.

Ok Perhaps audio and video are in the right direction and maybe time, but any page that is dynamically displayed either by code or whatever (which is almost every page I visit) will not need to use alot of these tags.

And even if they are static, you can produce probably all the same results using css classes.

Re:Excellent!

[ptlis]

Content and presentation have been slowly merging over the course of the web. Adding these semantic tags appears to be an attempt to separate the presentation from the content.

Do you have any evidence to back up this sweeping statement? In my opinion this was the case from the early days of the web, through the original browser wars and for a period afterwards (until maybe '01-02) at which point people started realising that contaminating the markup with presentational cruft was a good way to create maintainability nightmares, and made major redesigns of medium to large sites a frustrating and time-consuming (thus costly) process.

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

This is, of course, very true (and I forsee Internet Explorer lagging behind the other 'major' browser vendors), however this can be said about any new web specifications (the XHTML 1.0 spec was released as a recommendation in January 2000, and IE doesn't support it in any way, shape or form*).

Add that to the fact that the current generation of browsers don't agree on implementations within HTML4, and I suspect that this will not really help us web developers.

Nowadays, the commonly used browsers (>IE6, Gecko based browsers, Konq, Safari, Opera) all implement a large subset of the HTML 4 spec, although you are right that there are some presentational issues (mostly due to the fact that the spec is vague in places) these can be eliminated with a judicious application of CSS rules.

Personally i'm glad that the w3 have taken the helm wrt the HTML5 spec - I had major problems with the direction that WHATWG were going with it. A specific example is their introduction of the presentational font element; their note that it should only be used by WYSIWIG tools and to be syntactically valid said tool must add a special meta element is laughably nieve. As the font element has no semantic meaning and no benefit over the equally semantically meaningless span element with a suitable styling via CSS - sure you could argue it offers backwards compatibility with legacy documents, however I would assume that a document that is not syntactically valid HTML4 would need major work to be cleaned up to be valid HTML5 anyway (plus, that would be disobeying the spirit of the spec, being as such content would not be generated by a WYSIWIG editor).

Another worry is that they're integrating DOM stuff into the same spec, although it does make sense in some ways it seems like there is the distinct potential of losing focus by covering too diverse a set of problems. However, it is still early days yet and I will withhold judgement until we start seeing near-finalised drafts and browsers start implementing some of the new features.

* However, it can (mostly) deal with it if you (incorrectly, IMO, despite appendix C) send the mime-type as text/html and skip the XML prologue by parsing it as 'tag soup'.

Re:Excellent!

[cheater512]

Think about Google. They would love the layout to be machine readable.
Its the next logical step.

I assume you think things like

and

are equally pointless?

Re:Excellent!

[Anonymous Coward]

What does a screen reader on Viagra sound like? Berry White and Isaac Hayes mixed

Re:Excellent!

[Bogtha]

I haven't gotten into the depths of the HTML 5 spec. but AFAIK it hasn't actually changed from previous versions of HTML at a practical level.

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 XHTML isn't trendy any more, so people only want to see the bad in XHTML and the good in HTML 5. I mean, HTML 5 and XHTML both have similar subtle syntax differences compared with HTML, but one of the editors of the HTML 5 specification that condones subtle syntax differences is also the author of the XHTML as text/html Considered Harmful essay where he tells everybody that the subtle syntax details are enough to avoid using XHTML as text/html!

All that's really happening I believe is that they're officially specifying the behaviour that every browser already uses. Bascially they're retconning HTML parsing to make every implementation correct instead of trying to get browsers to change.

So basically it's HTML 3.2 all over again and they are just rubber-stamping a mess.

I wouldn't. Have you noticed that practically everybody using a custom page layout on MySpace uses a tool to do it? Jane Random Teen isn't writing HTML by hand. If any tool like that produced errors, people would simply use one that didn't.

Not writing by hand, but from what I've seen (admittedly not a great deal) they do often copy and paste peices of HTML from multiple sources which can very easily lead to nesting issues under XML variants.

You seem to be confusing validity and well-formedness. Copy and pasting code into places where it shouldn't be causes validity errors. XML parsers are only required to throw a fatal error when they encounter a document that is not well-formed. But even so, my point still stands: if somebody is supplying code that breaks their MySpace layouts, they will copy and paste from a source that doesn't supply broken code. I don't know why people are so intent on pretending people won't react to these errors and just blindly use code that gives them errors. It's a common attitude, but seems to bear no resemblance to reality. People are usually rational. If something is obviously broken to the point of complete lack of functionality, they won't use it.

HTML's forgiveness isn't cumulative in most cases though. Generally speaking if you can get away with something once you can get away with it a thousand times and never experience an actual break.

Have you ever actually seen a newbie write code? I've seen professional web designers write tables nested a dozen levels deep before getting to a point where something is broken and they have no idea what or how to fix it. Throwing newbies into that sort of environment is not a good way for them to learn.

You can't really keep twisting more and more because you're not technically doing anything wrong, just being a bit scrappy at worst.

Where does this myth come from that you can do pretty much whatever you like in HTML and it's not technically wrong? HTML isn't that lax, it's got fairly strict syntax rules. It's typical browser error handling that's lax. Once you reach that point, you are definitely "technically doing something wrong".

If you do something truly wrong then odds are it will show in the rendering and can be fixed from there.

No, this is simply not the case. Browsers have well over a decade of kludges built i

Re:Excellent!

[nine-times]

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 mostly plain text, and mostly paragraphs and lists, it made sense.

But now? The type of data contained in a web page is so variable and people want to be more in control of layout and design. So sometimes, when I'm thinking about it, I start to feel like the whole thing is kind of weird. This is a weird debate for me, and I find myself having trouble articulating my thoughts.

The main things I use are "A", "P", "H*", "DIV", "SPAN", "BLOCKQUOTE", "UL", "OL", and "LI"... I guess some others sometimes ("CITE", "DL", "DT", "DD"). But does that selection of default elements really make sense? Were they derived systematically? Even these new elements, were they derived systematically, or were they just pulled from what would go into a weblog or something?

I don't know. The new elements seem good to me. There have been loads of times when I've had so many "DIV" tags with semantic classes that I've just wanted to make up my own elements specific to the data I'm working with. Yeah, I know it shouldn't be any harder to write "div class="article" vs. "article", but it would just make more sense in my own head and be easier to read.

At the same time, I've spent a fair amount of time coming up with CSS that will just reset all the elements to a standard display (P and BLOCKQUOTE display as normal DIVs, no bullets on UL, H1 the same size as normal text, etc). Call me crazy, but sometimes it's just easier for me to start from scratch.

Put these two ideas together, and sometimes I kind of feel like no web browser should have any default elements defined, and you should be able to make up any tag you want. The whole thing should be handled by convention, and there should be an agreed-upon default CSS file that you attach to get the display that would give you the layout browsers give you now without CSS. Hell, even include that CSS with the browser, but allow an easy switch in the HTML spec to disable the whole thing. Drop the "A" tag altogether and make anything a link if you include "href='http://example.com'".

Then again, it seems like that might lead to chaos. I don't know. Sometimes HTML makes a lot of sense to me, and sometimes it seems like the stupidest set of conventions I've ever seen.

Re:Excellent!

[Lorkki]

-- XHTML is allowed under the HTML 5 spec, which they call XHTML 5 --

Is this some kind of SGML lobby ploy to induce confusion between HTML and future versions of the actual XHTML standard?

Re:Excellent!

[615]

Wait, I have an idea. Let's continue the transition from HTML to XML, and give the standards bodies their own namespace (e.g., "std"). Want to mark up an article in a way that's meaningful to search engines? Use std:article. Couldn't be simpler!

Re:Excellent!

[VGPowerlord]

You are aware that <div class="main texty stuff">...</div> belong to the classes main, texty, and stuff, right?

Re:Excellent!

[Anonymous Coward]

'cept the second one is actually three things at once: "main", "texty", and "stuff".

Re:Excellent!

[Lachlan Hunt]

Actually, the article element and the other new sectioning elements are also important for the heading level algorithm. When used, the heading level is determined by the number of nested sections, not just the numbered heading element. So you're no longer restricted to the 6 levels provided by the h1 to h6 elements and you no longer have to worry about changing the heading number when moving content around. e.g. An article on one page may begin with a 2nd level heading, but on another page, it may need to be a 3rd or 4th level.

The other advantage is for authors, since it's possible to replace dozens of div elements with other appropriate elements, it makes it easier to maintain the code because, for example, it's easier to match up a <article> with </article>, than it is to match up <div class="article"> with the correct </div>, especially when there are many divs used.

Re:Excellent!

[Almahtar]

Oh if there was an tag I would be thrilled!!! User.css, here I come!

Re:Excellent!

[Randle_Revar]

XHTML 5 will be the actual XHTML standard, once it is complete.

Re:Excellent!

[kennygraham]

Barry White + Stephen Hawking

Re:Excellent!

[kennygraham]

* However, it can (mostly) deal with it if you (incorrectly, IMO, despite appendix C) send the mime-type as text/html and skip the XML prologue by parsing it as 'tag soup'.

I'd agree with you if you'd been talking about XHTML 1.1. XHTML 1.0 SHOULD be served as application/xhtml+xml, but MAY be served as text/html when the compatibility guidelines are met. XTHML 1.1, however, SHOULD NOT be served as text/html. Even then, it's not a MUST NOT. But since it's a MAY for 1.0, i think calling it "incorrect" is a bit harsh.

May, as you probably know, but just incase, is defined by RFC2119 as:

MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.)

And, unfortunately, I feel the marketplace requires it.

Re:Excellent!

[bigt_littleodd]

Correction:

Barry White + Stephen Hawking, with a sore throat and stiff neck.

Re:Excellent!

[Eivind]

The difference is that the first is an arbitrary choice by you, the second is a part of the HTML standard.

The first would work exactly as well as the second, *IF* everybody made precisely the same choice of class-name that you made. Which is unlikely.

span class="H1" could replace h1 too, only people wouldn't be consistent so we'd have H1, h1, Header1, MainHeader, Header_1, and half a gazillion others.

Re:Excellent!

[Yvanhoe]

The goal of HTML is to be a rich text format, not a semantically meaningful language. Various markup languages are implemented on top of xml to do just that. But they still need a way to translate from semantics to display and layout instructions. That was the use of HTML.

Re:Excellent!

[mykdavies]

You've just identified why it will never catch on: use it properly, and your pages will show up lower in Google searches. I don't think the SEO crowd will care for it much!

Re:Excellent!

[oliderid]

It does.

Instead of having billions of different ways to write the article class (but also IDs): Article, articles, article, Article, art., (and foreign languages) etc. You've got simple one.

Extremely easy to parse. And if it is extemely easy to parse: new concepts (that we don't know yet) may take advantage of it.

The biggest advantage of all may be search engines. They may get a better perception of the content type.

I'm all in favor of such kind of upgrades. It is a pragmatic, down to earth approach. HTML is more and more used in blogs, CMS, and the like. And they all work with a block based concepts. If HTML upgrades stick to the reality of the Internet, then I'm all for it.

But please no more theorical/ideologic major upgrades, wasting their efforts reinventing the wheel that nobody will ever implement.

Re:Excellent!

[delinear]

That's true - but then people are already producing nasty tag soup so it likely won't worsen the situation in places where it's already bad, while at the same time giving those who do care about accessibility, usability and semantics more tools to do things right.

Re:Excellent!

[LighterShadeOfBlack]

True, but it would also make sense to then give slightly higher relevance to pages which contained multiple elements and contained both search terms within a single one.

So basically you get a tradeoff. Terms spread across articles come lower than normal, terms focused on a single article (on a page that contains many) would come higher than normal. No doubt it'd need a great deal of tweaking and rejigging to balance everything right but the long-term affect should be searchers get more results which contain all their search terms in a relevant manner. Hopefully.

Re:Excellent!

[ptlis]

* However, it can (mostly) deal with it if you (incorrectly, IMO, despite appendix C) send the mime-type as text/html and skip the XML prologue by parsing it as 'tag soup'.

I'd agree with you if you'd been talking about XHTML 1.1. XHTML 1.0 SHOULD be served as application/xhtml+xml, but MAY be served as text/html when the compatibility guidelines are met. XTHML 1.1, however, SHOULD NOT be served as text/html. Even then, it's not a MUST NOT. But since it's a MAY for 1.0, i think calling it "incorrect" is a bit harsh. May, as you probably know, but just incase, is defined by RFC2119 as:

Yes, I was talking about XHTML 1.0 (Appendix C is the location of said compatibility guidelines), it is widely considered to have been a mistake to allow developers to send XHTML documents with the wrong Content-Type because it causes subtle errors and defeats the purpose of using an XML based language (amongst many other reasons). My point is that when you serve XHTML as text/html you negate the point of using XML; You lose the ability to embed other XML languages (such as MathML or SVG) within your document, the page is no longer sent through an XML parser that checks for well-formedness thusly you're likely to introduce subtle errors without realising. When the day comes that all major UAs support application/xhtml+xml correctly and you decide to switch the Content-Type over there is a good chance of your pages not being displayed (works fine in IE but dies in Firefox due to crappy content negotiation) due to subtle errors in your markup that weren't apparent when your document was being parsed as tag soup.

And for all these difficulties you get what? On the web today, with IE still having ~80% market share, XHTML offers no advantage of HTML4 and has a whole pile of potential pitfalls that a developer must take into account of and hack around. For example, <, >, & are all treat as markup irrelevant of where they are in a document when a page is treat as XML, causing problems with inline JavaScript blocks; as a developer you have to explicitly declare the contents of script block as cdata using <![CDATA[ followed by a closing ]]> with all Javascript between those two elements, however because the Javascript interpreter treats anything within a JavaScript block as code (and you're sending it as text/html) you have to comment them out so that when served as text/html to older browsers they don't try to execute the cdata declaration as code.

There are many, many more problems associated with sending XHTML as text/html with various hacks to mitigate some of them to a greater or lesser degree. However I don't feel that sending XHMTL as text/html is ever a good idea and if you insist on generating XHTML markup then I suggest you use a good content negotiation script to send it as application/xhtml+xml where the browser supports it and when it does not using XSLT to transform the document to HTML before sending it to UAs that do not.

Re:Excellent!

[tinkerghost]

The only way such a tag would actually be implemented by people with advertising is if there were DRM-like restrictions on browsers forcing ads to be shown.

They'll still have a problem getting around my 127.0.0.1 .tld lines in my hosts file :)

I honestly think my web browsing experiance is 2-3 times faster now that I added doubleclick & 2mdn to the list.

Re:Excellent!

[Touvan]

I think it's just convenient to have version parody. It'd be nice if they could come up with a better name though. Maybe HTML 5 XML or something. It's just HTML 5 with a well formed XML syntax, instead of an HTML syntax. Interestingly, they now say HTML is it's own thing. It doesn't necessarily have to follow SGML rules anymore (well HTML hasn't been valid SGML for a while now I guess).

Re:Excellent!

[Random832]

an 8khz 8bit mono WAV takes no more space/bandwidth than a 64kbps MP3.

Re:Excellent!

[Lord Flipper]

There are many, many more problems associated with sending XHTML as text/html with various hacks to mitigate some of them to a greater or lesser degree. However I don't feel that sending XHMTL as text/html is ever a good idea and if you insist on generating XHTML markup then I suggest you use a good [ptlis.net] content negotiation script to send it as application/xhtml+xml where the browser supports it and when it does not using XSLT to transform the document to HTML before sending it to UAs that do not.

This is very interesting, and even though I dabble in XHTML and CSS and warping PHP templates, and have read a lot, I'd never considered sending different content types before. You know, the conventional 'wisdom' (I use that term loosely in my case) is all about hacks, and alternate stylesheets. But I worked with XML for years, and still hadn't considered the 'xml for these folks, html/text for those folks' idea. Time for me to start digging up my XSLT books and guidelines. Thanks for this.

Re:Excellent!

[Ngarrang]

with the side-effect of requiring people to upgrade their browser. Um...which people should ALREADY be doing to avoid the security flaws that exist in any current version of your preferred browser. As Microsoft and Mozilla roll out their updates and new versions, HTML 5 will simply be there with no more effort than what would have already been made to begin with.

Re:Excellent!

[baeksu]

Exactly. While we are at it, why don't we make tags for emails. That way senders can mark their emails by category or importance.

I'm sure spammers will remember to inclue the <spam> tag.

This will work at least as well as the .xxx would for filtering p0rn.

Yessirree, can't go wrong. These guys really know the intarweb.

Re:Excellent!

[Anonymous Coward]

parody = something that makes fun of something

parity = equality

I think you meant the latter.

Re:Excellent!

[kennygraham]

shhhh i have Pfizer stock.

Oh great...

[Bazman]

More things for IE to not support properly.

Re:Oh great...

[Spy der Mann]

More things for IE to not support properly.

Or in other words...

Let the Browser Wars II... BEGIN!

Re:Oh great...

[lonechicken]

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

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

Re:Oh great...

[Praedon]

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

Re:Oh great...

[Bazman]

Didn't you guys read the article? This should be in tags...

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

Re:Oh great...

[Praedon]

<geekhumor> This all makes sense now! HTML 5 will handle all of our needs by providing common tags such as <sarcasm>, <yelling>, <geekish>, and other common things that we usually type in brackets just cause it's fun! </geekhumor>

Re:Oh great...

[Praedon]

Oh one more thing... another tag that is needed is one for sites that commonly get slashdotted. All we have to do is put several bandwidth hogging images and files inside the antislash tag, which would allow the coding to show or not show the code based on if the site is really crawling. All browser based too, so it cuts out having to ask the server if it's being slashdotted, well, because it obviously is if its going extremely slow. There are other measures to put in place too, like the browser keeping in mind if the referral page was indeed a slashdot article.

I think I am just getting goofy now about this... : )

How about a Declarations area?

[WED Fan]

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?

[Anonymous Coward]

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?

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

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

[morgan_greywolf]

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?

[Anonymous Coward]

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?

[trolltalk.com]

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

You can support IE users ... just inlcude links to the download pages for Opera, Firefox, Netscape, Safari, etc.

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

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

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

[Anonymous Coward]

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.

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

[hobo sapiens]

"Isn't it already possible to include proprietary tags in (X)HTML documents"
Sure, but if you want your code to actually validate, you have to write your own DTD. Have fun with that.

If you include proprietary elements/attributes while using a standard DTD your code won't validate. XHTML code that doesn't validate against its DTD isn't truly XHTML code, since adherence to the DTD is what defines XHTML code.

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

[Bogtha]

That doesn't make Internet Explorer support XHTML. It makes it automatically convert XHTML to HTML, which it does support. This is not the same thing. For example, try document.getElementsByTagName("HTML") in JavaScript. When applied to an XHTML document, that should return no elements. When applied to an HTML document, it should return the root element. Or try styling <tbody> elements. Unless you put them in explicitly, there won't be any in an XHTML document. In an HTML document, they are automatically implied for every <table> element.

What you are doing with the XSLT approach is covering up Internet Explorer's inadequacy by automatically transcoding to HTML on the client. Internet Explorer isn't seeing XHTML though, so if you attempt to use anything XHTML-specific, then it won't work. And if you aren't attempting to use anything XHTML-specific, then it's not worth bothering with XHTML in the first place, you might as well just use HTML.

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

[bigstrat2003]

That's not supporting IE users, troll. That's having them switch.

I don't understand where you get this idea that we shouldn't support IE, or Vista, just because you don't like them.

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

[Jugalator]

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

IE 7, Firefox, Opera, all support XSLT 1.0 properly.
I don't know about XHTML+CSS though -- but that was always labeled unrecommended by W3C anyway.

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

[Jugalator]

Hm, upon further checking, even IE 6 supports XSLT with the proper namespace as it comes with MSXML 3+.

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

[_xeno_]

I assume you mean XML+CSS is unrecommended. XHTML+CSS is the recommended way - that's what the XSLT translates to. :)

But, yes, after screwing around with XML+CSS, I have to agree that it's a bad idea. It's neat in that it demonstrates the power of XML and CSS, but ultimately it involves either turning CSS into XSLT (gratuitous use of the CSS "content" attribute) or re-ordering your XML to match the desired output structure and not the semantic structure.

But that's not what the original poster was asking, at least as I understood it. They were asking why you can't create new semantic tags and use them in an existing XHTML document. The answer is that you can, but it won't work in IE. Or, at least, I don't think it'll work in IE - the "run it through XSLT" trick someone mentioned might work, but I haven't tried it.

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

[Dhalka226]

Ignore him. The first article on his website is "Is it time for an ABM (Anyone But Microsoft) license?"

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

[trolltalk.com]

Getting people to switch is probably the best support you can ever give them. You know the saying - "Once you go Mac, you never go back."

The ultimate goal is supporting IE users, which is not the same as supporting IE. The best support you can give an IE user is links to competing, and better, browsers.

What's best for Microsoft isn't what's best for their users - otherwise, they wouldn't be trying so hard to lock people in with restrictive file formats, etc.

In a lot of cases, what's best for EVERYONE is "Anybody But Microsoft". A good example of that is Vista - how much extra greenhouse gases will be released because of the extra power consumption needed to run all the eye candy? Vista is literally harmful for the environment.

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

[Phroggy]

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. IE is no longer dead. There's IE7 now, and there will be IE8 in a couple years. Within a decade, IE8 will have substantial market share. HTML 5 isn't pointless, it's just forward-thinking. A decade from now, thing will suck less.

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

[trolltalk.com]

Don't be such a dickhead.

Why not come up with an argument against what I proposed in my original post (that in may cases users would best be supported by switching to other browsers)? Because you can't - even the market (via market share figures of IE vs other browsers) is saying as much.

As for the "ABM" (Anybody But Microsoft) license, it makes sense for some projects; how many times has a project gotten flack because it runs poorly under Windows, but fine under the *nixes? This way, a dev can say "Sorry, we don't support Windows. Please read the license." rather than listen to foolish arguments about the "need" to support Windows, and the "need" to make things Microsoft-compatible. Microsoft needs to stop making itself incompatible with the "embrace - extend - extinguish" crap.

I'll tell you why...

[Orig_Club_Soda]

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

Re:I'll tell you why...

[telbij]

Huh? How do you use CSS without HTML?

Re:I'll tell you why...

[J. Dunlap]

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

[Corporate Troll]

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

[AKAImBatman]

How do you use CSS without HTML?

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

[ubernostrum]

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

[Orig_Club_Soda]

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

Re:I'll tell you why...

[AKAImBatman]

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

Re:I'll tell you why...

[Orig_Club_Soda]

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.

Re:I'll tell you why...

[AKAImBatman]

You know, moderations like this are the great mystery of Slashdot. Why is the above post modded Flamebait? Is it not acceptable to be sarcastic to one's own self? If so, why should being sarcastic to one's self involve starting a flamewar? What would be the responses? Somehow, "JSON can indeed be styled with CSS, but you were being sarcastic so off with 'yer head!" doesn't strike me as a realistic scenario.

Maybe it's grumpy moderator day. Um... happy grumpy moderator day? =D =D =D

(Wait, if it's grumpy moderator day, should I really be wishing them a happy day? My head hurts.)

Re:I'll tell you why...

[realthing02]

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.

So you consider doubling the amount of certain effort to be a healthy challenge? No offense but that's my definition of "tedious and pointless". Would you miss the challenge if all browsers rendered things the same?

Also, i highly doubt web developer jobs will be going overseas in the software programming sense. Especially if it is something like html/css front end stuff. Creativity is a huge part of front end design, and that isn't emphasized in most countries like it is here. I'm not saying this is bad or good, i'm just saying that American education emphasizes literacy and 'how do you feel about x' curriculum as opposed to a good healthy dose of science and math.

Re:I'll tell you why...

[ClosedSource]

Well, the powers that be decided that they wanted you to use CSS so they didn't bother to enhance the "goodness" of HTML tags and attributes. Still, not everybody believes that making every page on a site uniform in appearence is a good thing.

Do we need "MORE"?

[Puls4r]

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

[garett_spencley]

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

[Azarael]

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

[Anonymous Coward]

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

[Azarael]

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

[Doctor Crumb]

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

[Escogido]

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.

Re:Do we need "MORE"?

[Heian-794]

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

Re:Do we need "MORE"?

[nicklott]

640K ought to be enough for anybody!

Re:Do we need "MORE"?

[hobo sapiens]

Agreed. Not to be overlooked is the javascript code that can be eliminated.

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:Do we need "MORE"?

[Crazy Taco]

Worse, this "standard" takes us back to the 90's when nothing was strict, well-formed, or enforced properly in any way whatsoever. The 90's were nothing than a big free for all in which you couldn't get anything to display consistently across browsers.

XHTML and CSS saved us from a lot of this by making things well formed, stricter, and less messy (by seperating content from presentation). Going back to what the article aptly calls the "cave-man" approach is a disaster and a disgrace. I had previously liked Mozilla up to now for their work on standards conforming firefox, but after seeing this all I can say is that they are a bunch of idiots. THe same goes for Apple and Opera. This will be a BIG setback to regular, structured, standards based web development.

Ironically, the only hope now is that Microsoft, with its huge installation base, will continue to march along its current path of better complying with XHTML (which will hopefully be fully complete by IE 8), thus making the efforts of the other three worthless. Heck, I'd even be content for Microsoft to follow the more traditional course of not applying with anyone's standards. At least that would also keep this "standard" from being widely supported, hopefully killing it or at least delaying it enough to give the W3C time to get off their butts and get XHTML 2 out the door.

Side Note: Why do we have to go back to HTML? Why can't we just add these new elements to XHTML and call it XHTML 1.2? Why do we have to go back to unclosed tags and crappy code that can't be parsed with the ubiquitous XML parser?

Re:Do we need "MORE"?

[Excors]

HTML5 is much more strict than HTML4, from the perspective of browsers – e.g. it defines precisely how any sequence of bytes is parsed and the DOM tree that is produced, and HTML5-compliant browsers must follow those rules. HTML4 left most of the parser undefined, so browser developers had to make it up themselves, which caused the "you couldn't get anything to display consistently across browsers". A fundamental goal of HTML5 is that HTML documents (including the significant majority that are invalid and full of syntax errors) must work consistently across browsers, by being strict in how browsers handle any content.

It's much less strict than XHTML from an author's perspective, but that is orthogonal to the issue of browser inconsistency – any garbage can get parsed by an HTML5 parser without raising fatal errors, but it will be parsed the same by all HTML5 parsers.

Re:Do we need "MORE"?

[BenoitRen]

I wonder when the XHTML hippies will realise that XHTML is dead, and never was a good idea. Did you actually take the time to read the XHTML2 specification? It's a mess.

http://www.spartanicus.utvinternet.ie/no-xhtml.htm
http://www.autisticcuckoo.net/archive.php?id=2005/ 03/14/xhtml-is-dead
http://www.xml.com/pub/a/2003/03/19/dive-into-xml. html

Re:Do we need "MORE"?

[BenoitRen]

Which "browsers"? There's only one, and it's called IE.

Re:Do we need "MORE"?

[Anonymous Coward]

I don't claim to know everything about HTML, the W3C, etc, but why can't we have modularized HTML,CSS,etc parsing engine(s), maintained and developed by some working group, that can be integrated into browsers, applications, whatever, allow it to be upgraded easily, extended with proprietary tags, just prevent certain tags from being overridden (in functionality)?

All we have now is a specification that browsers are encouraged to support and implement. The specification means as much as j-walking laws. Not only would every application needing to parse HTML & CSS do it consistently, it would allow browsers to develop faster. Granted I know MS would probably stick their nose up at this, but if they didn't do it, they would have to reinvent the wheel, while other browsers could concentrate on other features instead of how to implement margins and padding.

just a thought...go ahead flame my ass now.

Re:Do we need "MORE"?

[Eskarel]

Actually, to be honest, the current standards problems(aside of course from the fact that Microsoft got slack and ignored IE for the real time equivilant of about a millenium(the web has changed a lot since IE6 first came out)) are more to do with trying to implement standards after the fact than any other reason.

Yes IE is terribly non standards compliant in some ways(particularly relating to DOM), but when IE first introduced the code the functionality didn't exist in the standards. Some of the functionality still doesn't exist in the standards(though relatively little, and most of it is of questionable security). This doesn't excuse the fact that the DOM model in some later versions of IE differs wildly from both the standard and from previous versions, but it does explain why things like document.all exist in the first place.

I'm a web developer these days, and from what I can see the W3C is in some ways just as guilty as Microsoft is for screwing things up. I don't really care about what's standard and what's not. I don't really care whether Microsof is to blame for not supporting standards, or whether the W3C is to blame for not putting the defacto Microsoft standards into the canonical standard. All I care about is being able to build JavaScript and DOM code which actually works in any browser I try to run it in.

Re:Do we need "MORE"?

[Richy_T]

I would have thought that was exactly the kind of thing that should be covered by CSS. Or perhaps in the HTTP headers (perhaps by the encoding). The content of the HTML document is just a stream of information. I'd be interested to hear your rationale though.

Rich

Web 1.0

[Applekid]

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?

[fredrated]

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

Re:what happened to xhtml?

[glop]

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?

[Anonymous Coward]

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?

[jandrese]

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

Re:what happened to xhtml?

[DrSkwid]

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?

[Anonymous Coward]

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

Re:what happened to xhtml?

[Spy der Mann]

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?

[jalefkowit]

Yes. Kind of.

There are currently to Working Groups in the W3C working on markup -- the XHTML working group, and the HTML working group. 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:

• The whole point of XHTML was that moving to XML syntax would open up new possibilities for user-agents: not just browsers (whose lives would be simplified by not having to deal with "tag soup" anymore"), but applications that would take advantage of already knowing XML to do cool stuff with the web. Only that never really happened; and because Microsoft wasn't on board, browser vendors still had to parse the "tag soup" anyway.
• The XHTML Working Group went off the deep end and announced that XHTML2 would handle errors the way XML parsers are supposed to: by shutting down and throwing up an "Non-conforming document" error. Needless to say, this is not how the Web works today, and it threw a scare into millions of Web publishers who incorporate third-party content that they have no control over (like, say, ads) in their sites. They also proposed major changes to the syntax of XHTML2 versus XHTML1 to clean it up and make it more logical; which sounds great until you realize that now you have to teach those millions of web publishers a whole new syntax or their sites break.

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 independent "HTML5" 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?

[unreal32]

XHTML 1.0 was just HTML 4.0 reformatted for XML compatibility.

Re:what happened to xhtml?

[Anonymous Coward]

yeah because writing this

My text

is so much harder than <p>My text</P>

anyone thinking that tag soup is / was a good idea is far lower on the evolutionary chain than Raging Monkies on acid.

Re:what happened to xhtml?

[RAMMS EIN]

``The whole point of XHTML was that moving to XML syntax would open up new possibilities for user-agents: not just browsers (whose lives would be simplified by not having to deal with "tag soup" anymore"), but applications that would take advantage of already knowing XML to do cool stuff with the web. Only that never really happened; and because Microsoft wasn't on board, browser vendors still had to parse the "tag soup" anyway.''

That one isn't really Microsoft's fault. It's more like there is a whole lot of legacy code that browsers need to support. The sad thing is that more "legacy code" keeps being written every day by webmasters that aren't worth their salt (or acting on bad orders). As for cool stuff not happening, to the extent that this is true (cool stuff does happen in places), I think that is more a matter of not figuring out how to do it at all than a problem with parsing HTML.

``The XHTML Working Group went off the deep end and announced that XHTML2 would handle errors the way XML parsers are supposed to: by shutting down and throwing up an "Non-conforming document" error. Needless to say, this is not how the Web works today, and it threw a scare into millions of Web publishers who incorporate third-party content that they have no control over (like, say, ads) in their sites. They also proposed major changes to the syntax of XHTML2 versus XHTML1 to clean it up and make it more logical; which sounds great until you realize that now you have to teach those millions of web publishers a whole new syntax or their sites break.''

All FUD, if you ask me. Sites won't break as long as browsers keep supporting older formats, which they will. If you have no control over what goes in your page, and thus can't guarantee that it will be valid XHTML2, there's a simple solution: don't claim that it is. And if you're too <word> to learn a better language than your current one, well, shame on you.

Re:what happened to xhtml?

[sootman]

Screw all this. I'm gonna start my own working group... with blackjack and hookers! In fact, forget the working group.
- That, of course, would belong in the much anticipated <bender> tag.

Re:what happened to xhtml?

[Anonymous Coward]

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

That means their competitors just need to read the spec in order to see how to implement the IE5 bug-compatibility that most of the web relies on and that all the major browsers have already figured out, instead of spending years reverse-engineering every other browser and finding the bugs the hard way. How is that harmful to competition in the browser space?

Re:what happened to xhtml?

[zzen]

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 independent "HTML5" 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. You did get most of the points right, but I could maybe add:

• It wasn't people that started thinking about extending HTML, it was the browser vendors (w/o Microsoft) -- the WHATWG.
• They didn't do it because they didn't like strict parsing without the tag-soup headache, but because the the ludicrous speed of the XHTML WG indicated XHTML2 could be finalized in 10 years - or more. The progress was actually slowing down in recent years.
• With the whole web 2.0 thing floating around, browsers were held back in their potential by an old standard with many sore spots (think better forms with better client-side in-browser validation for starters) and no vision of changing it anytime near.
• The W3C re-established the HTML WG and adopted the WHATWG spec on the brink of becoming irrelevant when the browser-vendors consortium would be shipping browsers to their own standards

Some people criticize the WHATWG draft as being too browser-centric, however I for one as a developer am thrilled by the proposed changes.

Re:what happened to xhtml?

[zzen]

That - and Apple (Dave Hyatt) fueled the fire a bit as well when it chose to base it's Dashboard widgets on extended HTML4 with new radical elements like - and promptly built support for all these right into Safari.

Re:what happened to xhtml?

[maxume]

Not enough people liked the processing model enough to put xhtml into practice. A big feature of html5 is that it specifies how to recover from poorly formed markup, so the end user always sees something, which many people prefer to an error page.

Re:what happened to xhtml?

[Anonymous Coward]

> XHTML2 would handle errors the way XML parsers are supposed to:
> by shutting down and throwing up an "Non-conforming document" error.

At least it would do this for documents that declared themselves to be XHTML 2. The problem with HTML 5 is it requires no unique document declaration (simply ) and this spec and DOM are meant to apply to any web document ever made, or that ever will be made.

If all the browsers implement HTML5 rules as it appears they will be, we'll be stuck with these rules for a long time. The emphasis on backwards compatibility keeps us from changing anything that ever was, no matter how screwy it is.

Unless they change their minds, break their own rules and redefine tags like they have done with the tag. Then whatever the future brings will change the meaning of your old code. There is no way to say "this is HTML4 and this other document is HTML5". You think you'd like to use a doctype for this, but the working group has decided that they are useless. http://www.w3.org/html/wg/html5/#the-doctype.

Good and bad at the same time

[chriss]

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.

Re:Good and bad at the same time

[Paulrothrock]

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

Up to now, new HTML elements...

[Anonymous Coward]

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

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

[D4C5CE]

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

OK whats in it for me.

[jellomizer]

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.

Re:OK whats in it for me.

[Randle_Revar]

Webkit, Gecko, and Opera will probably all get html5 support around the same time.

For example, there are experimental Opera, Firefox and webkit builds with <video> support.

IE will probably lag, but Chris Wilson of Microsoft is the w3c working group chairman so there is hope...

Re:OK whats in it for me.

[Carewolf]

The tag is the most useless of them all. Apple has already decided only to support QT movies in it, and Opera and Firefox have decided not to support QT (patent issues). So even among the first movers it will be completely incompatible.

Re:OK whats in it for me.

[julesh]

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.

Firefox and Safari have already implemented a lot of this stuff, and some of it is supported in IE already too (even if only by hacks). A good example is the 'canvas' tag. It was implemented in safari before the working group even started, and was implemented by firefox quite soon after it was added to the working draft of the standard. Scripts are available that implement it for IE as well. Other things are standardisations of what were previously IE-proprietary extensions (e.g. the 'contenteditable' system), so are already fully supported by IE, and will likely be available in firefox & safari soon.

This just in from Microsoft HQ...

[wamerocity]

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

[lonechicken]

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

Re:This just in from Microsoft HQ...

[Jugalator]

And I think I forgot to laugh at worn Microsoft jokes. :-p

Sorry.

I mean Micro$oft jokes.

Re:This just in from Microsoft HQ...

[Anonymous Coward]

Bet you wish you had a tag now, don't you?

Or maybe <botched-microsoft-joke>.

The most greatly wanted tag

[Anonymous Coward]

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

[dunkelfalke]

actually the most wanted tag is the irony tag.

Re:The most greatly wanted tag

[Anonymous Coward]

Actually, wouldn't that be written like this, most likely? ;)

Re:The most greatly wanted tag

[the_womble]

actually the most wanted tag is the irony tag.

The problem is that most people on /. will not understand how to use it.

Re:The most greatly wanted tag

[Bogtha]

We already have the irony mark.

Re:The most greatly wanted tag

[mabinogi]

Especially since using it defeats the purpose of irony in the first place ;)

Re:The most greatly wanted tag

[Anonymous Coward]

I'm still waiting for a tag.

Re:The most greatly wanted tag

[ivan256]

It's like a new tag that crashes your existing browser......

Isn't it ironic? ;)

Re:The most greatly wanted tag

[skeeto]

/. users will also have trouble distinguishing between the and tags too.

So do tags ever deprecate?

[lonechicken]

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?

[Anonymous Coward]

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?

[DragonWriter]

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.

Re:So do tags ever deprecate?

[Bogtha]

You can remove support for things like <font> in your browser today.

Re:So do tags ever deprecate?

[Bogtha]

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

This is not true. The HTML 4.01 specification includes numerous explanations of what should be used instead of deprecated element types and attributes. I quote from the specification:

However, since style sheets offer more powerful presentation mechanisms, the World Wide Web Consortium will eventually phase out many of HTML's presentation elements and attributes. Throughout the specification elements and attributes at risk are marked as "deprecated". They are accompanied by examples of how to achieve the same effects with other elements or style sheets.

This specification includes examples that illustrate how to avoid using deprecated elements. In most cases these depend on user agent support for style sheets. In general, authors should use style sheets to achieve stylistic and formatting effects rather than HTML presentational attributes.

For example, in the part of the specification that describes font styles, examples are given to show you how to style text with CSS instead. If you haven't seen the explanations, then you just aren't looking.

Re:So do tags ever deprecate?

[TheoMurpse]

No, it's more like having tires that can go over both highways and old dirt roads. Unless you want old web pages that are no longer maintained (but still have useful information) to be completely inaccessible (think: nearly 100% of everything on the Wayback Machine), you want to support the deprecated stuff, too.

Re:So do tags ever deprecate?

[fzammett]

Hey, get the hell away from my car!!

Re:So do tags ever deprecate?

[Anonymous Coward]

If only the wayback machine parsed the resulting DOM and spat out conforming pages...

Finally! The return of the tag!

[wiredog]

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

Announcing

[Bluesman]

The BRAND NEW HTML 5!

Almost as good as TeX!

Re:Announcing

[annamadrigal]

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

Re:Announcing

[PipianJ]

Now if W3C gets around to implementing the &tex; entity, I think we'll be all set.

Re:Announcing

[Neil Watson]

When I learned TeX last year I wondered why HTML did not borrow more from TeX. While not perfect for a browser, TeX has a lot of good tags that could have been used from the outset of HTML.

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:Announcing

[poot_rootbeer]

one really serious omission from HTML and other "generic" markups which can be read widely is proper support for rendering of mathematical equations

I'm sure to scientists, this is a serious omission. But as a former liberal arts major, my web browsing rarely takes me to pages that contain equations so complex that they cannot be represented in plain UTF-8, even if that means substituting '/' for fraction lines and so forth.

Should HTML be required to support rendering of sheet music as well? It's a similar niche requirement, and in both cases I think the answer is "required? no."

Besides which, the W3C already has a MathML spec for presenting mathematical equations. Firefox renders it natively, and plugins exist for IE. How much more does the W3C need to do?

Re:Announcing

[Richy_T]

Indeed, for liberal arts students, HTML was complete upon the introduction of the tag.

Rich

Oh crap.

[Stumbles]

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

Re:Oh crap.

[Spy der Mann]

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

[LighterShadeOfBlack]

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

Improvements in search

[efbee]

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

[IBBoard]

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!

[Eberlin]

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.

Re:Wonderful!

[Randle_Revar]

html5 has been adopted by the w3c, but it started life in the WHAT-WG, which is a group created by Mozilla, Apple and Opera. So I think it will be well received. Also, Chris Wilson of Microsoft is the chairman of the w3c working group, so there is a good chance of even IE supporting this.

IE is the only browser that is not doing so well in supporting the standards, and that's only in the realms of CSS and XHTML. IE has done a pretty good job of supporting HTML for quite a while.

Re:Wonderful!

[IL-CSIXTY4]

The WHAT-WG, the group behind the HTML 5 proposal, was founded by folks from Apple, Mozilla, and Opera. IE may not support it right away, but I think it's a safe bet the other browsers will.

I'm in the money!

[El_Smack]

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

permablink?

[jdunlevy]

I sure hope one of the new elements is finally permablink!

Re:permablink?

[Anonymous Coward]

because all HappyWeb connections are sent through tubes filled with deadly radiation

What can I say? Kibo is a great visionary, once again.

I agree!

[Anonymous Coward]

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

Cut off back support

[pembo13]

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.

Re:Cut off back support

[Phroggy]

If you use a DOCTYPE declaration to indicate what version of HTML you're writing in, browsers won't do backwards-compatibility crap. It's only when you leave that out that they try to emulate Netscape 4 and other legacy cruft.

yabbut

[AriesGeek]

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.

Re:yabbut

[808140]

Of course you mean that IE will not implement these new tags. If they're a W3C standard, Gecko, Konqueror, Safari, Opera and friends will all implement them ASAP.

Re:yabbut

[AriesGeek]

Ya know, I made an innocent, non-biased post. I tried to do it in such a way that I wouldn't draw an MS bash or a Firefox bash. But no. You couldn't let it go.

Care to make a friendly wager? If they ALL (you said all) implement them ASAP (i'll give them 6 months) and mean ol' MS doesn't implement them in the same timeframe, I will give into the /. groupthink and spend 6 months of my life posting nothing on slashdot except MS bashing.

However, if they don't ALL implement them ASAP and/or MS does implement them within 6 months, you have to find every post you've made bashing MS and apologize saying you had given into /. groupthink and are guilty of being close-minded.

No, this is not a troll, it's a legitimate challenge.

Re:yabbut

[808140]

In that case, you won't get much apologizing, as I'm not much of an MS-basher. IE is made by MS, but that's where the association with MS ends. Criticizing IE is not the same as bashing MS, you know. Ignoring for a moment who makes IE, anyone who has done web development has been bitten badly by that browser's inability to deal with 10 year old standards that every other browser in the world has long since implemented in a standards compliant way. IE 6, which up until very recently was the newest version of IE, went for nearly a decade without an update. It remains in wide circulation. IE 7, apparently the answer to IE 6's limitations, still fails to properly implement decades old standards, introduces new bugs which have not been fixed, and mainly seems to be about adding tabbed browsing and popup-blocking to IE 6.

I know your wager was meant in jest, but consider that if you win, I won't have much to apologize for, but if I were to win, you'd waste six months of your life being an idiot like most of Slashdot. Not much of a bargain.

Re:yabbut

[BenoitRen]

Just a heads-up: IE6 for XP SP2 already had pop-up blocking.

Re:yabbut

[808140]

Thanks for the correction.

Knuth would be proud

[Anonymous Coward]

HTML5 looks a hell of a lot like LaTeX.

Re:Knuth would be proud

[Troy Baer]

HTML5 looks a hell of a lot like LaTeX.

You say that like it's a bad thing.

RISC versus CISC

[athloi]

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

[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:Seems useful

[MikeBabcock]

Except that the article text version will work in all the recent browsers, not just unnamed versions of the future, whereas text will cause problems in older browsers.

Re:Seems useful

[julesh]

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

As a rule, the standards developers are careful not to introduce new features that would cause breakage like that.

For example, there are new input types proposed. But all of them are specified using '<input type="blah">' tags, which (per the HTML 4 spec) degrade to being a text input if they aren't understood. In each case, the standard specifies the textual format that is used to transfer the data, and instructions could be given to a user to use this format. In the case of date entry fields, it probably won't be particularly helpful (few people want to work with ISO-formatted dates), but for the new '<input type="number">', complete backwards compatibility is assured.

Too Late

[N8F8]

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.

XHTML/HTML divergence

[Animats]

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

[PipianJ]

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. There are other issues too, but I can't pull them off the top of my head at this time.

Re:XHTML/HTML divergence

[Dracos]

HTML5 should be dropped, and just develop XHTML5. Imroper/lazy nesting and optionally closed tags are the crutch of "designers" who rely on overly helpful browsers and sloppy WYSIWYGS to do their jobs for them.

Do you trust a mechanic who, after working on your car, gives you your keys and a pile of "extra" parts that he found on your car that "weren't necessary"? Get back in there and put the rest of the head bolts back on, bub.

The fact that the HTML5 tagset is getting silly is a separate issue.

Re:XHTML/HTML divergence

[Bogtha]

A big advantage of XHTML was that the conversion to a parse tree was unambiguous.

It was unambiguous in SGML as well. The advantage XML had was that the tree was explicit in the document rather than being implied by a bunch of complex rules in the SGML standard and the external DTD subset.

I've seen a lot of people wrongly claim that forbidding things like <b><i>...</b></i> is an advantage of XHTML — are you making the same mistake? Such things are forbidden in HTML too, it's just people tend to get away with things like that with HTML because of its undefined error handling.

Re:XHTML/HTML divergence

[poot_rootbeer]

Layout is really a 2D constraint problem.

For rendering to a sheet of paper, maybe.

To a text-to-speech converter, layout is one-dimensional. To a web browser, layout is three-dimensional (yes, three: z-index indicates how far "in front of" or "behind" one element is to another, though flattening this layout space to a 2-D display reduces the perception of a Z-axis somewhat).

Re:XHTML/HTML divergence

[Blobule]

If thay can add a tag wrapper around a tags top change the semantics then I think they should consider also adding a tag wrapper that tells browsers the table used within is for layout purposes only. Then we can be done with the craptastic state of using CSS div kludges to layout data. Old pages wil lbe compatible, future browsers will understand that the table within is just for layout.

Re:XHTML/HTML divergence

[Animats]

I've seen a lot of people wrongly claim that forbidding things like <b><i>...</b></i> is an advantage of XHTML -- are you making the same mistake? Such things are forbidden in HTML too, it's just people tend to get away with things like that with HTML because of its undefined error handling.

I'm looking at it from the side of someone working on a site rating engine that has to parse real-world web pages. There are many constructs that are flatly wrong, yet common enough that they have to be handled. Incorrectly terminated comments show up very frequently, and have to be handled properly. "&" outside an entity is wrong, but almost normal. A </br> without a <br> is treated as a line break by most browsers, rather than being ignored. We see hostile pages that exploit the differences between the standards and what browsers actually understand, using tricks like escaped newlines in URLs. These things are all at the level where the document is turned into a tree, not at the higher levels where we see things like <li> without an enclosing <ul>.

It would be helpful if we could at least insist that pages parse correctly into a tree. Browsers enforce that for XML, which is a good first step towards consistency.

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:XHTML/HTML divergence

[Anonymous Coward]

That still doesn't help screen readers unless you add an "order" attribute or something. For example, give each TD element an attribute like order="1", order="2", order="3" etc. so that screen readers know what the logical flow of the layout is (if there is one.)

This is a somewhat worthwhile hack, the real way it should be done is define the layout elements in an ordered list embedded inside datagrid, and inside the grid items the list item id to define what element goes in that grid position. I think that developers and designers who think that CSS is great and that table (at least in structure) can't be semantically modified for layout suffer from a lack of imagination.

Re:XHTML/HTML divergence

[Bogtha]

"&" outside an entity is wrong, but almost normal.

This is not true. Ampersands are not parsed as entity references in HTML unless they are followed by a letter or '#' and a number.

It would be helpful if we could at least insist that pages parse correctly into a tree.

You're missing the point I was making. HTML does insist that pages parse into a tree. If they don't parse into a tree, then they aren't HTML and it is an error condition.

You're saying that it would be useful to force mandatory error handling rather than letting user-agents attempt to work around errors, and I agree, but that doesn't change the fact that HTML's parsing rules are as unambiguous as XHTML's.

Re:XHTML/HTML divergence

[BenoitRen]

No way, that's going back to the old table mess. HTML is semantic, lay-out has no place in it. Your new tag is not semantic.

Re:XHTML/HTML divergence

[Blobule]

No way, that's going back to the old table mess. HTML is semantic, lay-out has no place in it. Your new tag is not semantic. Sure it's semantic. It's telling the browser it's plain old layout. That IS semantic. I'm not saying get rid of CSS, CSS is great, but the way CSS and divs currently complicate what used to be simplistic with tables IMHO is a strong argument for the return to simplicity of using a table for layout. Also if layout has no place in HTML please explain the purpose of the tag and the tag if not for layout.

Re:XHTML/HTML divergence

[Blobule]

That should have said: Also if layout has no place in HTML please explain the purpose of the tag and the tag if not for layout.

Re:XHTML/HTML divergence

[DragonWriter]

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.

Doesn't XSL:FO handle that? I remember back when there were XSL:FO browsers in the works (and early versions released even), but it looks like that, sadly, all fell apart, and XSL:FO mostly got relegate to generating output aimed at print, where it is used at all.

Re:XHTML/HTML divergence

[oliderid]

"br" is still extremely useful for those of us who have to deal with marketing people on a daily basis.

Most of the corrections you receive from such kind of department is commas, text color, justification, bold and break line.

Instead of having tons of different class or style="margin-bottom:XXpx" for each paragraph, more verbose and more time consuming. all you have to do is to put a simple breakline or two and it does the trick.

This probably the most boring part of a web development job. The fastet way to get rid of it, the better.

XHTML, HTML 4.1 transitionnal, HTML 4 , or whatever I really don't care. If it works with Firefox, Safari, Internet Explorer, Konqueror, Opera and pass a WAI test, then I did my job.

Re:XHTML/HTML divergence

[Anonymous Coward]

HTML5 should be dropped, and just develop XHTML5. Imroper/lazy nesting and optionally closed tags are the crutch of "designers" who rely on overly helpful browsers and sloppy WYSIWYGS to do their jobs for them.

Do you trust a mechanic who, after working on your car, gives you your keys and a pile of "extra" parts that he found on your car that "weren't necessary"? Get back in there and put the rest of the head bolts back on, bub.

You can't expect your mechanic to ensure that every single part he places into the car was engineered to spec. This is the reason that XHTML doesn't work for large sites in the style of yahoo or ibm. Way too much third party HTML gets included into the page from content management systems, all written to different variations of HTML, and even though it's technically possible to verify, validate, correct and transform all the 3rd party HTML, in reality it's just not worth the cost. Couple this with the braindead decision of enforced catastrophic failure parsing invalid XML (imagine if an entire book became unreadable because in a sentence halfway someone forgot a comma), and it remains very important to support tag soup.

Re:XHTML/HTML divergence

[julesh]

A big advantage of XHTML was that the conversion to a parse tree was unambiguous. Why give up that at this late date?

Nobody's giving up on that. One of the goals of HTML5 is to ease adoption of XHTML, for instance by removing details from the HTML specification that are incompatible with XHTML: e.g., in the description of parsing element opening tags:

"if the element is one of the void elements, [after the attributes] there may be a single U+002F SOLIDUS (/) character. This character has no effect except to appease the markup gods. As this character is therefore just a symbol of faith, atheists should omit it."

e.g., HTML 5 ignores a slash in (e.g.) <br />, whereas according to the HTML 4 spec it should be processed as SGML would process it: SGML would render it as if it had occurred just after the tag.

Consider, for example, a lone 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.

A conforming HTML implementation should ignore such a tag, which is illegal in an HTML document. That they don't has nothing to do with the specification, and just shows that browser implementors do not support XHTML (in which such a tag is _legal_ and should not be rendered) as well as many claim they do.

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.

It sounds like you, like me, feel that the real solution to all of these problems is a clean break from HTML and its legacy.

Re:XHTML/HTML divergence

[BenoitRen]

They both define a section.

Your new tag is not semantic because it doesn't say anything about the content itself.

Re:XHTML/HTML divergence

[Blobule]

Yes it does, it says it's not tabular data, it's layout data :)

Re:XHTML/HTML divergence

[BenoitRen]

And lay-out is not content. You also forgot that inside most of those tables would be content, and your tag wouldn't say anything about that.

Re:XHTML/HTML divergence

[Blobule]

That's right, because the content within the layout would use the appropriate semantic tags to describe that very content. Layout is just layout, semantically the table is described as layout, but the content within if you need amphasis or a title can still use the appropriate semantic tag.

Re:XHTML/HTML divergence

[Random832]

HTML5 explicitly defines how formatting tags are handled, in such a way as to allow not only ... but also ..........

Re:XHTML/HTML divergence

[PGaries]

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.

Actually, you can do this with CSS:

display: table-cell; vertical-align: middle

In that regard, the problem is Internet Explorer's lack of support for CSS2/2.1 rather than CSS itself. If you know the dimensions of the object to be centered, you can also use absolute/fixed positioning (except in IE6) or absolute/fixed positioning combined with negative margins.

How about an HTML editor control?

[parvenu74]

How about an HTML editing control?

Re:How about an HTML editor control?

[porneL]

It's there, based on contentEditable/designMode (so it's IE-compatible).

whatever happened to...

[dgun]

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?

Re:whatever happened to...

[Jugalator]

Yeah. Now they expect people to use a whole new tag set instead of a mostly backwards compatible implementation of HTML in XML.

That's a much smaller leap. ;-)

The <BLINK> Tag

[sjaguar]

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

May me redundant...

[thatskinnyguy]

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

<article><entry>etc...

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:RSS

[cerelib]

Did you even read that Wikipedia article you linked to? It lists three different names that RSS has had; Really Simple Syndication, RDF Site Summary, and Rich Site Summary. It all has to do with the wacky and incompatibility filled version history of RSS.

Re:RSS

[Anonymous Coward]

I thought RSS stood for Really Simple Syndication, did I wake up in a parallel universe this morning?

Yes, this is the /. dimension, where folk cite articles before reading them.

Re:RSS

[C0y0t3]

Sorry, I guess I always jump to the evil plot conclusion...

Re:RSS

[Anonymous Coward]

RDF Site Summary -> Rich Site Summary -> Really Simple Syndication

Re:RSS

[syrinx]

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?

Did you even read the Wikipedia article you linked to? "Really Simple Syndication" is the shiny new marketing-speak meaning. RSS is really "RDF Site Summary". When it stopped using RDF, the R changed to "Rich" instead of "RDF".

Re:RSS

[C0y0t3]

Ok, I admit it - I didn't read the whole article, not very far down it says the other acronym derivatives, and the 'versions' they refer to. But what threw me most was that this article uses a more obscure definition as the standard/latest reference. So I'm not dated; the original author is. And that makes me feel better about me.

Re:RSS

[rossz]

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

You didn't get the memo? Damn. Sorry, dude.

Re:RSS

[TheAwfulTruth]

Heh it's more like how "DVD" used to mean "Digital Video Disk" but got changed to "Digital Versitile Disk" buy the sloaganeering teams...

Re:RSS

[steveoc]

Or C the programming language - an infinitely recursive definition if ever I saw one.

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

[dpbsmith]

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?

Re:Where do I get my "enhanced for HTML 5" banner?

[r3dx0r]

there you go http://idisk.mac.com/r3d/Public/html5.gif

Wanted: <slashdot /> tag

[Namlak]

<slashdot class="FirstPost"> (deprecated)
<slashdot class="Dupe">
<slashdot class="LibrariesOfCongress">
<slashdot class="BeowulfCluster">

Do we really need to stop progress?

[telbij]

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

Re:Do we really need to stop progress?

[Onan]

You seem to be equating change with progress.

All of the additional fluff to which you refer just allows site designers to slather on additional layers of crap on the same content. More often than not, this actually impedes access to whatever content was there, worsening to utility of the site.

So if your argument is that bolting these things onto the elegant simplicity of html will make it easier to add cruft like javascript and css, you have only convinced me to be even more opposed to it. I have yet to see anything done in javascript that I actually want to have happen in my browser.

Re:Do we really need to stop progress?

[bigmammoth]

we can use javascript libraries to support html5 video elements today

Re:Do we really need to stop progress?

[telbij]

So you think using Flash for video rather than a single obvious tag is "slathering on additional layers of crap"? Or is it that you don't think we should be displaying video in our web browsers? The new tags are by-and-large very well thought out, and reflect a standardization of common practices over the last decade. The structural tags alone such as header, footer, nav, and article are applicable to the vast majority of websites and provide semantic meaning that could easily be leveraged by browsers (especially screen readers) to improve the user experience. The result is not an additional "layer of crap" but the replacement of a sea of arbitraily classed divs with semantic markup that is more meaningful than before.

Obviously HTML/HTTP is not the ideal platform for rich applications. I fully acknowledge that. However we're not going back to HTML as a platform for purely static content. If that's all you want to use your browser for, please carry on with the rest of the nostalgic internet luddites. I'm sure you can find a few dozen other curmudgeons to reminisce with over on Usenet. However as far as delivering applications, the web has undeniable advantages. Economic realities mean we'll be moving forward with the web for better or for worse, just like with so many other imperfect technologies in the past.

Re:Do we really need to stop progress?

[Mazin07]

There, I stopped progress for you.

Re:Do we really need to stop progress?

[Mazin07]

There, I stopped progress for you.

All these changes . . .

[UnknowingFool]

and still no blink tag. :P

ummm .... MENU is not a new tag ...

[trolltalk.com]

"I welcome new tags like datagrid and menu"

The MENU tag has been part of the spec since the earlest html drafts.

Several tags are being "repurposed" or "overloaded". MENU is one of them. Read the discussion in TFA on the DIALOG tag for how definition lists are being re-worked.

need more tags

[El_Muerte_TDS]

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

Re:need more tags

[Bogtha]

</> close previous open tag

This has always been part of HTML, but is being dropped from HTML 5 because no major browser ever implemented it.

Re:need more tags

[skeeto]

I thought something like <:q!> would close all open tags. Of course, you may need a couple tags first.

Re:need more tags

[Alomex]

We also need a tag, but with Free as in freedom not Free as in free Beer.

Probably Irrelevant to me

[the eric conspiracy]

I'm 55 years old. By the time there are browsers that supports this properly AND most people are using them I'll be retired.

Re:Probably Irrelevant to me

[IdahoEv]

By the time there are browsers that supports this properly AND most people are using them I'll be retired.

Me too. And I'm 33.

/ not impressed with the state of browser standards support, even today.

Re:Probably Irrelevant to me

[porneL]

By the time there are browsers that supports this properly AND most people are using them I'll be retired.

One of the goals of HTML 5 is to make spec compatible with the web, not the other way round. Parsing model is reverse-engineered IE's behavior and so are some of the "new" features like WYSIWYG editor. Where possible, useful de-facto standards were documented and standarized as HTML 5. Most other features (like new form elements) degrade gracefully and can be fully implemented in current browsers using JavaScript.

Granted, IE and Firefox in text/html mode will choke on <article> tag, so don't quit your day job yet :)

The semantic web...

[WoollyMittens]

... in about 12 years time, after the W3C is done bickering and all legacy browsers are phased out.

I Don't Get It

[RAMMS EIN]

I don't get it. There was much excitement about the new tags in the dupe as well, and now here it is again. Is this really what the world has been waiting for? I thought that with the advent of XML, we could mix and match; include the languages we need, and come up with a nice, meaningful document, which could then be processed by various means to get various interesting results (one of those being a graphical rendering).

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

Re:I Don't Get It

[nicklott]

Also, as far as I know, they still haven't solved some of the problems with XML Maybe that's why... I mean why wait for the solution to a possibly insoluble problem in order to progress? XML is great for programmers but your average myspace/hello world user has enough problems with html. Why not just accept that html isn't xml?

So now we get more tags in HTML. What are those good for? Why not update? The various HTML incarnations were developed in the 90s based on what we *thought* the web might be used for in the future, why not update to reflect what it's actually used for now, after 10 years of experience?

Re:I Don't Get It

[RAMMS EIN]

Why not update to HTML 5? Because I don't see its value. It adds more tags? So we get a more bloated spec, which still doesn't give us every tag we need. We already have XML. With that, we can define and use any schema we need. It's more modular, and at the same time less bloated and more flexible. Where HTML 5 tries to increase the coverage of HTML by throwing in more tags, creating a single, monolithic monstrosity (anyone remember SGML?), XML allows infinite coverage, where every individual part can be small and simple.

So, the reason I don't feel like updating to HTML 5 is that, to me, it feels like a step back.

Re:I Don't Get It

[poot_rootbeer]

We already have XML. With that, we can define and use any schema we need.

The great thing about standards is that there's so many of them. If that's true, then it must be even greater to allow anybody to create their own standard. That's the situation that XML has given us.

Re:I Don't Get It

[neutrino38]

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

Because this is the point of view of a language specialist. Most of the web sites are made by people with only practical knowledge of Web technologies and HTML (classic) serves this purpose very well.

Unless you build graphical tools that handle XHTML in all its aspects, coding by hand XML and namespace and co can become pretty difficult and I am not aware that such tool exists.

With XHTML, W3C made the exact same mistake than with VXML and CCXML. In my view, we have to have a single language for signalling and voice rendering. They preferred to have two distinct languages with namespace. The result is poor and difficult to read. XML syntax is not fit for describing telecommonication services simply.

Re:I Don't Get It

[LionMage]

Unless you build graphical tools that handle XHTML in all its aspects, coding by hand XML and namespace and co can become pretty difficult and I am not aware that such tool exists.

You mean like Dreamweaver? Or any number of other "smart" editors that have come out? I grant you that they might not all be perfect, but they do a lot of the heavy lifting for you -- enough to make them worthwhile for users who don't want to code everything by hand.

Re:I Don't Get It

[l0b0]

Well, at least companies can say they support the standard, while anyone trying to make a mashup or parser will be tearing their hair out. Except for the "attributes should really be elements" argument, what's wrong with XML? Making web sites harder to parse (and consequently, making layouts harder to specify unambiguously) will come back to bite us in the ass.

So...

[Anonymous Coward]

Let me guess, the first (and only) tag you knew before this was blink?

Re:So...

[HitekHobo]

pre...

Re:So...

[absoluteflatness]

I assume you meant to write

 in your post three levels above, but it got filtered out.

Preview is your friend.

Re:So...

[HitekHobo]

Yup. Laziness will getcha

MP3 vs WAV

[sconeu]

Could it have something to do with the fact that MP3 is patent-encumbered?

Re:MP3 vs WAV

[Anonymous Coward]

Your sig has no depth. Define "needs".

Re:MP3 vs WAV

[fyngyrz]

Could it have something to do with the fact that MP3 is patent-encumbered?

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 audio is to be a browser feature, then a browser that can't play MP3 is utter crap. A standards body isn't there to be your your mother; it is there to promote interoperability, usability, commonality, is it not? So WTF are these people doing ignoring MP3 in favor of WAV?

Look at it this way: The first question a person is going to ask when they pick up an audio package or hardware audio player (you'll note the usual term is "MP3 player") — editor, player, recorder — is not going to be: "Does it support WAV?" No, it's almost certain, statistically speaking, to be "Does it support MP3?" And that is why WAV is a stupid choice.

I am no fonder of patents than any of the rest of you. But if you're going to rule out every technology that is patent encumbered, your sorry, optimistic, blindered butt will be in a cave before you even know what hit you.

Re:MP3 vs WAV

[sconeu]

I'm not ruling it out. I'm saying that requiring *all* browser developers/vendorss to support a technology for which they may not be able to obtain a license is bad practice in a standard.

Re:MP3 vs WAV

[Bogtha]

Look: JPEG is patent encumbered; nonetheless, it is the standard. GIF was encumbered; nonetheless, it was the standard. Likewise MP3.

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?

It flat out isn't the place of a committee to define things out of public use because there is a commercial tie

And they haven't done any such thing. They haven't banned the use of MP3, they just aren't requiring browser vendors to implement it. In all likelihood, every major browser vendor that implements <audio> will include MP3 support. But "it flat out isn't the place of a committee" to force browser vendors to infringe on patents.

Re:MP3 vs WAV

[Planesdragon]

So WTF are these people doing ignoring MP3 in favor of WAV? They're not.

An MP3 is a compressed WAV. You can't support the former without doing almost all of the work to support the latter.

And if you think that HTML needs "music", well, you don't know what you're talking about. A few small-size, simple WAVs will do more for a website than a running background song ever could.

Re:MP3 vs WAV

[Anonymous Coward]

An MP3 is a compressed WAV.

Where on earth did you get THAT idea???

Re:MP3 vs WAV

[Anonymous Coward]

Most people don't know that audio/x-wav is actually a container format that can represent many codecs (including MPEG-1). He means you have to implement playing PCM samples if you want to play MPEG-1 layer III audio, which is generally true. Maybe it's possible to go directly from the frequency domain to pulse-density modulation, but if you're writing a browser you're probably targeting computer-oriented hardware that takes PCM.

at least they didn't say ".au" and ".snd" required

[poot_rootbeer]

Talk about getting something backwards. MP3 is the defacto standard. WAV? OMG WTF. Way to waste bandwidth.

MPEG Layer 3, while the defacto standard, is also a patent-encumbered format. It makes sense not to saddle browser authors with a compulsory licensing fee.

Not sure how WAV is any better, though, as it's a Microsoft proprietary file container. I also didn't see any detail about which codec(s) must be supported; would support for just uncompressed PCM be sufficient? What about ADPCM and its variants? uLaw? What about an MP3 audio stream stored in a WAV container?

How about

[sherriw]

-A height attribute that actually works?
-Looping
-Smarter Form controls
-Eliminate the need for putting a space in empty table cells.
- ???
- Profit!

Re:How about

[ed.mps]

-A height attribute that actually works? isn't it browsers' fault (instead of HTML itself) ?

Re:How about

[irc.goatse.cx troll]

Fully agreed, especially about the forms.

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" /><br> with a LOT of css to position it) is just a pain in the ass (and only works for simple forms, try duplicating the kind of paper form you fill out at a doctors office for example)

while we're at it, can we like.. require everyone fully support css? I'm tired of putting ID's and Class's on inputs with unique names, when CSS says I should do

input[@name=date]

But of course none of the big three browsers come close to supporting it.

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.

Re:How about

[julesh]

-A height attribute that actually works?

Could you elucidate what's wrong with the current one? OK, so it isn't supported on enough elements, but...

Smarter Form controls

The proposal includes form controls for dates, times and numbers, plus pattern-matching on text fields.

Eliminate the need for putting a space in empty table cells.

Try adding 'empty-cells:show' to your CSS for the table declaration.

Re:How about

[TALlama]

-A height attribute that actually works?

I concur.

-Looping

Repititon allows you to repeat elements

-Smarter Form controls

There don't seem to be any; a <date> and <time> would be nice, at least.

-Eliminate the need for putting a space in empty table cells.

<td/>'s content model: Zero or more block-level elements, or inline-level content (but not both).

- ???

I like this bit.

- Profit!

That's up to you.

namespaces, extensibility

[harlanji]

I'm surprised at the lack of namespaces. I'd sooner extend xhtml with namepsaces (like XMPP, RSS) than create a bunch of new elements and drop xml semantics. It seems contrary to the mashability that "web2.0" seems to love so much. I guess when used in unison with xmlrpc services and the like it could make the job easier for designers, but in my humble, yet 411-limited, opinion, it seems like the wrong direction to go.

Re:namespaces, extensibility

[Randle_Revar]

Just use XHTML5

http://www.whatwg.org/specs/web-apps/current-work/ #html-vs
http://blog.whatwg.org/faq/#html-namespaces

what about the v-chip rating?

[duranaki]

Why couldn't they think of the children?!

<vchip sex="yes" violence="no">
<img src="parishiltonxxx.jpg">
</vchip>

Re:what about the v-chip rating?

[pho3nixtar]

And what makes you think they weren't?

<vchip sex="yes" violence="maybe">
<img src="hilton_spears_lohan_jail.jpg">
</vchip>

Re:what about the v-chip rating?

[Phroggy]

We have ICRA (formerly RSACi) for that. Nobody really uses it. What makes you think they'd use your idea?

Correct title

[Dracos]

"HTML 5 Tagspace Gets More Bloat"

Most of these new tags are ridiculous and doomed to obscurity because they pander to niches narrower than the average paper cut.

Why not do something constructive like design rich form widgets or fix the <dl> element (instead of cloning it as <dialog>)?

Re:Correct title

[The Master Control P]

How exactly are most of them pandering to narrow nitches? I run my own little website, and here's what I see in these tags:

Section-Article-Nav: Much better for my index.html than forcing a navigation table to the left with CSS.
Figure: The ability to associate text with an image without using a table (and all it's constraints).
Meter: This would be a very nice way to add richness without data bloat. I could make a graph without an image.
Media: At last an embedded .flv wouldn't be a thousand characters of HTML.
Details: Like onMouseover="" bringing over a hidden info box, but without exposing the rest of javascript to (ab)use.
Datagrid: Imagine e-commerce websites being able to resort information *without* reloading everything from the server.
Menu: I'm thinking of a browser-based office suite that would write your document natively as HTML.

It's certainly possible to emulate all this at the present; We have section-article websites, embedded media, and dynamic menus. But this would make them easy to use, and that's the point of HTML.

Because: The Web's not done

[blueZ3]

'til FireFox won't run.

But, wait... it's IE that usually fails to implement standards in a standard way, isn't it <head explodes> :-)

Re:Link to the actual WHATWG Working Draft for HTM

[PsychosisC]

I assumed the new standard would be very limited in scope to making it easier to solve fundamental web markup problems. Sadly at first blush, some of the new elements seem awfully bad.

http://www.whatwg.org/specs/web-apps/current-work/ multipage/section-prose.html#dialog

3.9.4. The dialog element

Block-level element.

Contexts in which this element may be used:
        Where block-level elements are expected.
Content model:
        Zero or more pairs of dt and dd elements.
Element-specific attributes:
        None.
DOM interface:
        No difference from HTMLElement.

The dialog element represents a conversation.

Each part of the conversation must have an explicit talker (or speaker) given by a dt element, and a discourse (or quote) given by a dd element.

This example demonstrates this using an extract from Abbot and Costello's famous sketch, Who's on first:

<dialog>
  <dt> Costello
  <dd> Look, you gotta first baseman?
  <dt> Abbott
  <dd> Certainly.
  <dt> Costello
  <dd> Who's playing first?
  <dt> Abbott
  <dd> That's right.
  <dt> Costello
  <dd> When you pay off the first baseman every month, who gets the money?
  <dt> Abbott
  <dd> Every dollar of it.
</dialog>

Text in a dt element in a dialog element is implicitly the source of the text given in the following dd element, and the contents of the dd element are implicitly a quote from that speaker. There is thus no need to include cite, q, or blockquote elements in this markup. Indeed, a q element inside a dd element in a conversation would actually imply the person talking were themselves quoting someone else. See the cite, q, and blockquote elements for other ways to cite or quote.

Ewwwww

They left out the leet tag

[Anonymous Coward]

Too bad they forgot the 1337 tag. It takes standard text and translates it to 1337. Great for script kiddies, posers and trools. For example: I am just too leet. This site is customized for HTML 5. BTW check out my free porn. Renders: 1 4m 700 1337. 7h15 5173 15 cu570m1z3d f0r H7M| 5. BTW ch3ck 0u7 my fr33 pr0n.

From the article

[oSand]

Finally, when the caveman fired up the 300MHz laptop running Windows 98 that was also frozen in 1999...

Frozen in ice, or frozen because it was running win98

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

Comment removed

[account_deleted]

Comment removed based on user account deletion

How about grid layout and flow in CSS?

[argent]

There are three main layout models in text formatters: cartesian coordinates, packed boxes, and grids. CSS floats (both absolute and relative) are cartesian, the traditional non-floated divisions are packed boxes (albeit a fairly primitive packer), but there's no grid layout other than tables.

The other missing thing is what you need to create automatic columnar layout, the ability to define divisions as being part of the same flow, so that text can fill across division boundaries.

All the special tags they've come up with, though, can be handled by standardising names for spans and divisions. In fact that's pretty much all they are, new aliases for and .

Re:How about grid layout and flow in CSS?

[porneL]

Are you aware that HTML and CSS are different specs? Although CSS isn't perfect for layout, there is baisc automatic columnar layout (with text reflow) in CSS3 and table-like display in CSS2 (spec writers have written their part, now you should complain to Microsoft).

You could say that all tags are just standarized names for divs and spans, but you have to put name somewhere and there's no benefit in prepending everything with '<div class="'. There actually were some predefined class names in an earlier draft, but that didn't fly (for various, IMHO disputable, reasons - see public-html group archives).

Re:How about grid layout and flow in CSS?

[argent]

HTML and CSS are different specs like Ford and Lincoln are different companies. HTML and CSS have to work together and build off each other.

There is NO grid layout support in CSS2. There is crippled packing support that, when combined with painstakingly cumbersome absolute-sized and positioned divisions, can be used to simulate very very simple grid layouts. This is so far from a real grid layout engine that it's not funny.

The flow support in CSS3 is similarly limited to a specific canned solution to a specific problem.

The result of these half-assed solutions is web pages that are actually *less* capable of adapting to different window sizes, let alone different display devices than if they were written using tables for layout... which is what makes this an HTML problem.

Re:How about grid layout and flow in CSS?

[porneL]

HTML and CSS have to work together and build off each other.

No, CSS is almost completly independent from HTML (you can take any DOM tree, any element names and style them using CSS). Theoretically HTML is styling-language-agnostic as well (<style type=text/javascript> used to work in Netscape).

painstakingly cumbersome absolute-sized and positioned divisions

Again, don't confuse what IE can't do with what CSS can't do. As far as CSS is concerned, you don't have to use positioning for grid layout - there is display:table-cell which makes any element behave like <td> . Tables for layout and hacks are neccessity because IE doesn't support CSS2, not because CSS2 doesn't support table-like layout.

Whether CSS sucks or not, it's not HTML's role to fix it. HTML defines structure and semantics of a document, and it's up to styling language to present them in a useful way.

Re:How about grid layout and flow in CSS?

[argent]

Will you quit babbling about what IE does or does not support... because I could care less. I *banned* IE at our office from 1997 until we got borged in 2002, for security reasons (and what happened after we were forced to use it again really made me look like a hero). Nobody should be using IE for anything but a last resort for broken sites.

If CSS supports grid layout then you should be able to show me a page that I can view in Safari, Camino, Firefox, Opera, or any other decent browser, and is still readable in IE.

Just being able to display a div as a table cell is just part of it.

Re:How about grid layout and flow in CSS?

[julesh]

A serious question here: what features do you need that aren't covered by simply using 'display: table-cell' and 'display: table-row'?

I can think of a few that might be useful:

* Ability to define column/row orders independently of element order (i.e. something like 'table-cell-column-index:0' to force a cell to appear in the leftmost column, etc.)
* Ability to make an element span multiple rows or columns
* Regarding text flow in columns, etc., something like 'overflow-target: #nextelement' (need to think about how box sizing works in the presence of text overflowing into the next box)

Re:How about grid layout and flow in CSS?

[argent]

A serious question here: what features do you need that aren't covered by simply using 'display: table-cell' and 'display: table-row'?

You've already mentioned row and column spanning.

I have yet to see a web page that uses smart packing behavior... columns packed based on their contents, and then expanded intelligently when the window is resized. It's pretty rare to get a page that even handles window resizing at all. This should be able to be statically defined in CSS, without having to specify any absolute widths.

There is pretty limited anchor support in CSS.

Have a look at what the three layout managers in Tk can do. Ousterhout held off on a grid layout manager for a long time, trying to make do with packing and floats, but he finally adopted one.

In some text formatting languages you define the layout with no content, with named boxes, and then the content is placed in a separate container... eg "" ... "...". I don't know the algorithms text formatters use for sizing non-contiguous regions, but there's gotta be code in open-source programs like TeX and Lout.

This would also solve your first problem, and more generally.

OT: Radioactive Horses?

[Spaceman40]

You know, the top Google result for this is: "Radioactive Horse Manure Seen as New Terror Threat"

Re:OT: Radioactive Horses?

[nightrain_tg]

Radioactive Horse Manure

Just the new band name I've been looking for! It's even got a built in "fun, insider/MySpace name": Atomic Pony Poo

I don't think Google works like this at all.

[Estanislao Mart�nez]

IIRC, Google has a policy of not using metadata to rank search results, because (a) it's easy to abuse, (b) it's easy to use incorrectly or inconsistently in ways that are unhelpful, and more importantly, (c) it's not information that's visible to the users of the page, and therefore, it tends to be irrelevant to whether the users will find the page useful.

Your ad-hoc rule sounds useful in a "gee, wiz" kind of way, but you don't know if it actually helps at all, or whether it actually harms in some situations.

Re:I don't think Google works like this at all.

[LighterShadeOfBlack]

IIRC, Google has a policy of not using metadata to rank search results, because (a) it's easy to abuse, (b) it's easy to use incorrectly or inconsistently in ways that are unhelpful, and more importantly, (c) it's not information that's visible to the users of the page, and therefore, it tends to be irrelevant to whether the users will find the page useful. I don't know what Google's practices are. I've never been that interested in improving search indexes. One company's policies aren't all that relevant to the point though to be honest. Whether Google do or don't, there's no stand-out reason nobody else should use them as one way of measuring relevance. The reasons you've given aren't prohibitive:

a) Quite frankly everything is easy to abuse. There is no metric that Google or any other search engine can use which cannot be abused by those who really want to. There's an entire quasi-legitimate IT sub-industry built around trying to abuse search engine results (SEO). Intelligently using semantic markup as an additional factor is unlikely to throw the world off-balance, but just might make things better for searchers. Taking the <article> element again, there would be a trade-off in its use:
– Words only appearing in sibling/unrelated article elements would be considered less relevant
– Words within the same article element (assuming more than one per-page) would be considered marginally more relevant

Obviously there would be more to it than that, but as an additional means of measurement I don't see this being any more abusable than existing methods.

b) I'm not sure I see that. These aren't structural tags so it's not like somebody's going to destroy their relevance by using 500 nested article tags in an attempt to create the perfect layout. Well I guess they could, but it doesn't seem very likely.

c) That one definitely doesn't make sense to me. The point of my example was that if someone searches for two terms it's typically because they want information relating to both of those terms. If they wanted two peices of information, one about Term 1, and another about Term 2, then logically they wouldn't be searching for them in a single search right? By using the article element you're explicitly stating that it's an independent peice of text, so having something in two peices of text independent of each other means that the chances are lower that the page has information that will be relevant to the searcher.

Your ad-hoc rule sounds useful in a "gee, wiz" kind of way, but you don't know if it actually helps at all, or whether it actually harms in some situations. Well no. Nobody does right now. And nobody will until HTML 5 is in general use a few years down the line and someone decides to test it in their search engine algorithms. Until then we're all just guessing one way or the other. And like I said before it was only one example off the top of my head. The point is that new semantic tags can open up possibilities that simply aren't feasible right now.

Re:I don't think Google works like this at all.

[DragonWriter]

IIRC, Google has a policy of not using metadata to rank search results, because (a) it's easy to abuse, (b) it's easy to use incorrectly or inconsistently in ways that are unhelpful, and more importantly, (c) it's not information that's visible to the users of the page, and therefore, it tends to be irrelevant to whether the users will find the page useful.

What he was referring to (and challenging me in the process) was document structure, not metadata. There is a substantial difference. Its much harder to abuse, its fairly easy to use consistently in a way that is helpful, and its information that while it can be obscured through clever styling, will generally be visible to page viewers.

YES!

[tubapro12]

Now I've finally got three more ways to do the same old thing and confuse all the people I try to teach HTML to!

Re:Link to the actual WHATWG Working Draft for HTM

[BenoitRen]

What else do you propose? Currently you have to use a div element to wrap a dialog/conversation in, which semantically doesn't mean anything.

Re:Link to the actual WHATWG Working Draft for HTM

[ccvqc]

From that document:
1.2.1. How to read this specification

This specification should be read like all other specifications. First, it should be read cover-to-cover, multiple times. Then, it should be read backwards at least once. Then it should be read by picking random sections from the contents list and following all the cross-references.

Layout paradigm

[Anonymous Coward]

Good point, that's what I always think trying to do some easy stuff in terms of windows UI layout and finding it nearly impossible in HTML - without tables. HTML was designed for plain text flowing in simple ways, all the layout problems stem from that fact. What is lacking is containers that keep dimensions as proportions of their parent (withouy any stupid tricks), containers that can stick to other containers, and all the stuff the windows forms programmers/designers are acustomed with. For layouts HTML sucks... The only thing one can do is use some javascript lib for doing window layout. It is funny that nearly nobody mentions those HTML layout problems, there are some hacks, some tricks, but the stanradization bodies just come up with some semantics stuff completly forgetting about desing part, sure CSS can do some of it, but it is shitty. Try to do anything more advanced and ambitional and you hit the browser incompetency (pretty normal in diverse environment) and lack of features of the language (this is abnormal and should be changed)

float and clear? fuck that, I want 'glue:[top] [right] [bottom] [left]' and so much more...

If CSS 3 is an example, don't hold your breath....

[HeavyDevelopment]

How long has the WC3 been working CSS 3!?! CSS 2.1 took from May '98 to '04 to be released--and that was a stop gap. Of course IE 7 won't support some parts of it. HTML 5 is going to be the same situation. The thing that gets me the most is that the the big push for implementing it is because of lazy a$$ designers and developers can't get standard compliant!!! I mean how long to you have to deprecate things? 10 years? 50years?

HTML was a crappy idea in the first place. It sucks as a markup language in that it lacks hardly any description of data at all. It doesn't work very well for layout--hence the cell based table design hacks that used images (IMAGES!!!) to set table heights an widths. I mean what is that? Seriously when I was first learn web design layout, it seemed asinine. But now that I've been around the block several times, it REALLY seems lame. HTML's built in form objects have not been improved upon since its inception! The input of form data is one of the cornerstones of user interaction on the web. Could we not get at least some validation of data that is built in!?! Opposed to using a myriad of Javascript code?

Now we're headed back to dark ages because of designers and programmers that are either too stupid or too lazy to get with the program.

Thanks a lot, jerks!

Don't you mean Leslie Lamport would be proud?

[LionMage]

Since Knuth was the guy behind TeX, and Lamport was the woman behind LaTeX...

And one way in which I can see HTML5 not looking like LaTeX (or Scribe, or any other number of markup languages) is that HTML5 expressly allows for un-closed tags. To me, that seems kind of a throwback to pre-XML days... but then again, even the savviest HTML jockeys I've met haven't totally wrapped their heads around XHTML and the requirements of writing good, XML-compliant markup.

So basically, HTML5 codifies all the problems with prior versions of HTML and the bad practices of web developers, and expressly says they are OK, and the browser will just have to deal with bad logical structure using all the kludgy logic that browsers currently use. This is also a great way to insure that the current crop of parsing engines out there will maintain a strategic advantage over newer parsers, since you can't expect properly closed tags or the other rigorous features of XML. This also makes the prospect for slimmer/leaner parsers that are less forgiving of deviation from standards kind of, well, slim. (The advantage of such lean parsers is that they'd be great for deployment in memory-constrained environments like cell phones. As a developer, I'd happily deal with more stringent adherence to strict structural requirements in exchange for being able to shoehorn my application onto a device that otherwise couldn't run/display my application.)

I'm also not happy about the proposed overloading of the dt and dd tags. That seems like a bad idea to me.

Re:Don't you mean Leslie Lamport would be proud?

[Anonymous Coward]

Dude, Lamport is a guy: http://en.wikipedia.org/wiki/Leslie_Lamport

Re:Don't you mean Leslie Lamport would be proud?

[Anonymous Coward]

Lamport is male:
http://en.wikipedia.org/wiki/Leslie_Lamport

Well, no

[DragonWriter]

You still need as well as , and, of course, you still need hyperlinks and images and other things which don't define structure.

Canvas Tag?

[LifesABeach]

Having this tag operational will cause some major enhancements to web surfing.

Re:Canvas Tag?

[julesh]

Yes, the canvas tag is in there. It is, of course, already supported by Safari and Mozilla (and Opera, IIRC), and there's a free script that can be used to make IE support it as well, so there's little reason not to start using it already.

Re:Canvas Tag?

[LifesABeach]

I just about ready to setup a web site that uses it. But there is a major draw back to one of the methods, "drawImage", when it comes to processing the 9 argument method, it is a Time-Sink. I hope the Uber-Gods can find a way to speed it up.

Bad Priorities and CSS3

[duerra]

I'm sorry, but IMHO, most of what was in that article is fairly useless to end developers and everyday browser users. There's very little there which allows you to do things that you can't already otherwise do. Adding an tag, which does absolutely nothing different than a ? Come on - it's not going to help anybody do anything that they can't otherwise already do - not to mention that it will be abused by spammers just the same as everything else already is.

That said, I'm DYING for CSS3. Being able to easily render features such as columned flowing text and generate borders with rounded corners, which CAN'T be easily (if at all) done with the current limitations is HUGE for me. There's countless features in CSS3 which devs are biting at the bit to get ahold of, but right now our hands are tied.

Re:Bad Priorities and CSS3

[duerra]

Sorry, the parent is supposed to read "Adding an tag, which does absolutely nothing different than a ?"

overseas

[Orig_Club_Soda]

I have already lost HTML/CSS production to overseas. Some clients are paying me just to design it in photoshop and then their team in China does the rest. Its already happening.

I also think you should be careful with your assumption that there are no creative people in billions of chinese and indians out there.

Very Bad Very Bad indeed!

[kentsin]

Why comments, footnotes and endnotes are not there !!!!

Why something already got defined in microformat is defined?

time, meter is notthing related to html, w3c should think about its reason for existance.

Bye W3C, you forgot what you should do. We should drop you.

Re:Very Bad Very Bad indeed!

[Randle_Revar]

The w3c didn't come up with this. Most or all of the current HTML5 spec in the w3c was pulled directly from the WHAT-WG, which is a group primarily made up of representatives from Mozilla, Apple and Opera.

Micro formats are good but they don't carry the weight that the official HTML spec does.

Things like time and meter could be very useful for rich web apps.

If you dislike the spec, you should join the w3c or WHAT working group (both are open membership).

Re:If CSS 3 is an example, don't hold your breath.

[Randle_Revar]

It sucks as a markup language in that it lacks hardly any description of data at all.

What?
 

It doesn't work very well for layout--hence the cell based table design hacks that used images (IMAGES!!!) to set table heights an widths.

That's why you are supposed to use CSS and not HTML for layout.
 

HTML's built in form objects have not been improved upon since its inception!

HTML5 includes web forms 2.0
 

Could we not get at least some validation of data that is built in!?! Opposed to using a myriad of Javascript code?

Validation is included in Web Forms 2.0

Good!

[wytcld]

The reason HTML enabled the Web to take off was it could be done by anybody. Then Advertising Age ran it's "We Must Conquer New Media" cover story, and all the creative directors got involved, and we ended up with this mishmash of html/css/javascript/java/flash on top of php/perl/.net on top of SQL &c. - which made everything bizarrely complex, while not really improving the look or accessibility-to-nondesigners of the Web. So then you get your wikis and blogs and so on which work because once again the "normal" people (who are often specialists in the sciences, politics, the arts and so on) can put up stuff again where the tools get out of the way and let them get on with the content.

If HTML evolves to the point it's done right again (as right as it was done in its very good and successful first year, but with what we've learned since) then we won't need wiki syntax, for instance. HTML should do that itself: let creative people who are not designers easily post stuff in most-accessible form. The whole move over the intervening years to make the Web the best medium for advertising hasn't worked well even for that. The most successful advertising venue is Google, whose success is based on stripping all that design nonsense out of its pages.

html or xml

[falconwolf]

HTML 5 is plain-old HTML, meaning it's syntactically forgiving (ie. case-insensitive elements and attributes, closing tags optional). That might not be important for you or me or most other Slashdot users but for the vast majority of people that kind of forgiving behaviour is very important.

xml's very strictness means those learning it won't get into bad behaviors. Bad behaviors are hard to get rid of, so it's better to have strict enforcement to begin with.

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.

xml can be written to degrade gracefully too. It was a few years ago but in an xml class I took we had to write xml files that could be rendered in older as well as newer versions of IE and Netscape with style sheets and xslt.

Falcon

/. feeds the troll (or Why HTML 5 is a Good Thing)

[Tokerat]

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. <div class="article">...</div> means absolutely nothing, context-wise. The "article" class is a style, designed by the developer. It tells nothing of context, only pretty colors and fonts. Now, the <article> TAG has a defined meaning to a browser, and in case you'd like to step outside that box which you seem to prefer thinking in, let me refresh you by reminding you that FireFox, IE, Opera, and Safari are NOT the only way one is meant to access HTML documents.

The whole fucking point of HTML is to CATEGORIZE DATA in a way that can be meaningfully interpreted regardless of context.

CSS and JavaScript are ways to build on this content for richer environments, sure, and I'm very grateful to have them. HOWEVER, they are tools to accent the underlying information, not to define the interpretation of that information.

How much better do you think these changes (HTML 5's new tags) can make search engines? Accessibility (think Braille readers for example)? The countless possibilities I haven't even thought about?

It seems we've got such a heavy case of A.D.D. these days, we've forgotten the entire point of HTML.

If you want to be able to develop web-based applications with fancy GUIs, etc. Then I'm all for it. But let's introduce a whole new schema for that designed from the ground up. Hell, design a new protocol to go with it; secure connections, stateful and persistent sessions built in, server-pushed updates, and all without kludges. Simplified Internet Transport Engine (site://catchy.name.even).

It just gets me up in arms that HTML was designed for a very specific purpose (that all content could be a cross-referenced and easily indexable and presentable in any way), and we're trashing that notion because it's all about flashy colors and thin-client capability.

My Wish List

[kadnan]

following tags which would be very helpful.

1)</beer>
2)<troll></troll>
3)<Miria mAbacha></MiriamAbacha> [She will not have not to send us so many mails,making her life easier]
4)<ASL></ASL>[ For lonly souls in Chat World]
5)<HotOrNot></HotOrnOt>-easily find your soul partner

add your choice please?

Image comments

[dargaud]

One thing I'd really like to see, and wether it's a problem for the browser implementation or the HTML specs is unclear, is a way to display the ALT text of an image together with the image. Currently you have to duplicate it as such:
<DIV>
<IMG SRC=... ALT="This image represents...">
<P>This image represents...</P>
</DIV>
It would be nice to have a way to have an option to control where and how the ALT tag is displayed.

Re:Image comments

[Richy_T]

If you use the ALT tag correctly, most of the time its text should be different from any captioning text anyway.

Rich

Re:Image comments

[dargaud]

Except for a possible 'Above:', 'Right:' or 'Left:' I don't see why there should be any difference. Care to elaborate on that ?

tag

[wdebruij]

From the article: "A complementary audio element is also proposed. For example, you might attach background music to a Web page"

Great idea! I choose <audio src="1000_wailing_women.ogg"/> to accompany this post.

Wrong......

[tinkerghost]

The whole fucking point of HTML is to CATEGORIZE DATA in a way that can be meaningfully interpreted regardless of context.

Actually, the purpose of HTML is to create Hyper Text documents Marked up in a common Language. A markup language is for formatting in terms of a print pre-process. The original goals of HTML were based around graphical appearance of the documents & a common means of linking specific aspects of a document to other documents which expounded on the current topic.

The concept that the content should be isolated & structured is more of a function of XML than HTML. XML takes the traditional print oriented concept of a markup language & applies it to data structuring instead of output formatting.

It just gets me up in arms that HTML was designed for a very specific purpose (that all content could be a cross-referenced and easily indexable and presentable in any way)

Again, the cross referencing wasn't designed to be done in an automated fasion, hyper text links were designed to be manually embedded into a document - footnotes on steroids. The [b,i,u,strike] tags were just about your only formatting options, because they were understood by the NCurses libraries. Beyond that, presentation wasn't really even a consideration with the orginal formats for HTML, because LYNX was your friend - pretty much your only friend.

Mosaic from the NSCA changed things dramatically by adding graphics to the mix, but web design was still based around presentation not encapsulation of data. Data encapsulation on a web page is a slow starter, lagging far behind the transition to OOP. Javascript wasn't introduced until 1995, and DOM in 1998. Until IE5 was released in '99, CSS was pretty much worthless as neither IE nor NS4 supported a significant subset of the CSS spec. As late as 2002 it was still considered good practice to code the page for specific resolutions in order to ensure that anyone viewing the page got the same experience.

Overall, I would say that data encapsulation and the seperation of data & presentation really begins right around 2000. Once data begins being seperated in order to take the biggest advantages of CSS , you begin hearing about the symantic web. This is where you begin to really see data being classed & potentially fully indexable.

Why not just add a new attribute to existing tags?

[Pragmatix]

Why not just add an attribute to the existing tags?

<div class='someclass' metavalue='article'>text</div>

If there were a finite set of what could go in metavalue, then search engines and screen readers could use the information to better understand what is in a particular tag.

The whole concept of HTML as it stands is wrong.

[master_p]

As it stands, the whole concept of HTML is wrong. HTML should have been a Turing-complete programming language where tags represented functions or classes (if it was object oriented). The code behind the function/class should be responsible for processing the content and making the output, using primitives provided by the web browser.

This would solve two problems:

1) the need for scripting languages.
2) the need to wait for the W3C committee to make a decision. HTML libraries would exist to allow these kinds of extensions.

DRM to prevent hiding of "ad" content

[Geoff-with-a-G]

It wouldn't be nearly so difficult as mandating elaborate DRM on the browser side.

Simply put some vital page content within an "ad" tag, so that automated "ad" tag blocking would also block the important content. Then the automated blocking becomes unusable.

Yes we do

[TheLink]

Actually we do need more tags. But a lot of these new ones aren't very useful.

Here are the sort of tags that I think will be useful:

http://it.slashdot.org/comments.pl?sid=224182&cid= 18153186

Basically I proposed HTML tags to turn OFF stuff, so that say a webmail site displaying webmail from uncontrolled sources (spam email) to users using unknown browsers (with different sorts of HTML parsing bugs/behaviours), can give hints to those browsers such as "between these two tags: java, javascript and other naughty stuff should be DISABLED", and if the browsers support those tags, and the browser programmers aren't totally braindead, it should be easy for the programmers to ensure that the naughty stuff is disabled (just set few flags/attribs).

Sure the website should still try to filter out and disable such stuff for browsers that don't support those tags, but these tags WILL definitely help make things safer.

I proposed such tags years ago to both the browser people and the W3C people, but they weren't interested at all.

The W3C has requirements and specs that say "Here's the spec for XYZ. BTW, you MUST do XYZ safely". But as far as I see, they don't actually help make things safer.

It's like they are distributing a design for a car without any brakes, and requiring that the builders make a safe car, and hoping that car drivers will drive safely.

But nobody other than me seems to be asking for an HTML with "brakes", so what are the odds that we'll get one? We'll just get more versions of HTML with "turbo, nitro" tags (and people wonder why things keep crashing). If you see another XSS worm, don't just blame the worm maker and the site.

Save some blame for the browser makers and the W3C.

Finally...

[StikyPad]

the return of HTML design. Now all we need are 6 figure salaries for anyone who can make black text appear on a gray background.