Beta

×

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

Thank you!

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

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

W3C Publishes First Public Working Draft of HTML 5

Zonk posted more than 6 years ago | from the new-coat-of-shellack dept.

The Internet 310

Lachlan Hunt writes "Today W3C announced that the HTML Working Group has published the first public working draft of HTML 5 — A vocabulary and associated APIs for HTML and XHTML. It's been over 9 months since the working group began in March 2007 and this long awaited milestone has finally been achieved. '"HTML is of course a very important standard," said Tim Berners-Lee, author of the first version of HTML and W3C Director. "I am glad to see that the community of developers, including browser vendors, is working together to create the best possible path for the Web..." Some of the most interesting new features for authors are APIs for drawing two-dimensional graphics, embedding and controlling audio and video content, maintaining persistent client-side data storage, and for enabling users to edit documents and parts of documents interactively.' An updated draft of HTML 5 differences from HTML 4 has also been published to help guide you through the changes."

cancel ×

310 comments

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

Of course, it won't matter. (1)

morgan_greywolf (835522) | more than 6 years ago | (#22140652)

At least until some major browsers support it. And it really won't matter until IE supports it. Sad, but true, really.

Re:Of course, it won't matter. (3, Interesting)

cromar (1103585) | more than 6 years ago | (#22141374)

Something I found interesting is that they will not consider the spec complete until there are two fully working implementations (FTFA). Sounds good to me... the spec can be trimmed if no one is going to implement the full thing (so at least there will be a smaller spec to refer to instead of a complete spec that no one uses). Another good effect is that if MS drags their feet, they will look even more stupid :)

Re:Of course, it won't matter. (2, Insightful)

ChatHuant (801522) | more than 6 years ago | (#22142132)

Something I found interesting is that they will not consider the spec complete until there are two fully working implementations (FTFA).

Which sounds rather self-defeating to me; why would a group or company put in a lot of effort implementing the most difficult parts of the recommendation, if W3C explicitely reserves the right to change the spec under them any time before you're done?

Re:Of course, it won't matter. (2, Informative)

hixie (116369) | more than 6 years ago | (#22142874)

The browser vendors are part of the working group, so they would be part of any discussions as to what to change. In practice, it's actually the browser vendors who request the changes -- typically, it's because the spec requires things that are contradictory or that don't really work in the real world for one reason or another, and the browser vendors thus would rather implement something else. The requirement for waiting until we have 2 complete implementations is so that we know, when we say the spec is done, that it really can be implemented and that such implementations really can be interoperable.

Re:Of course, it won't matter. (1)

ChatHuant (801522) | more than 6 years ago | (#22143092)

it's because the spec requires things that are contradictory or that don't really work in the real world for one reason or another [...]

The requirement for waiting until we have 2 complete implementations is so that we know, when we say the spec is done, that it really can be implemented and that such implementations really can be interoperable.


Interesting; I had no idea that the W3C design process for the specs is actually trial and error. Thanks for the info! I'd say that explains a lot :).

Re:Of course, it won't matter. (3, Informative)

AKAImBatman (238306) | more than 6 years ago | (#22142020)

Of course, it won't matter. At least until some major browsers support it.

Several of the features (e.g. Canvas) are already supported by all major browsers save for IE.

And it really won't matter until IE supports it.

One of the interesting aims of the HTML 5 standard was to spec the new functionality in such a way as to make it possible to emulate the new APIs in old browser. e.g. Canvas working in IE. [dnsalias.com] (Make sure you click outside the block area to start. I haven't implemented the key passing yet.)

The Storage APIs would be similarly easy to emulate through Cookies, Flash, or Google Gears. (Take your pick.) Server Side Events are more difficult, but I think it might be possible to emulate with XMLHttpRequest. If I'm wrong, there's always a Flash or Java shunt possible. DOM 2 Events is still not supported by IE, but that's easy enough to patch for by wrapping IE's attachEvent scheme.

Basically, we can force Microsoft's hand on this. A simple runtime patch and BAM, we're coding to HTML 5 standards. If enough people do it, Microsoft will realize they've lost that front and move on.

Not again (-1, Flamebait)

L4m3rthanyou (1015323) | more than 6 years ago | (#22140664)

Yes, let's roll out another new standard for no reason at all when most of the web still hasn't caught up to the last one.

I can't be the only one who thinks the W3C is annoying as hell...

Re:Not again (4, Insightful)

nacturation (646836) | more than 6 years ago | (#22140706)

Yes, let's roll out another new standard for no reason at all when most of the web still hasn't caught up to the last one.

I can't be the only one who thinks the W3C is annoying as hell...
So you're advocating holding back progress because a lot of sites authors don't bother to make their HTML compliant? With the new APIs, this hardly qualifies as "no reason at all".
 

Re:Not again (1)

L4m3rthanyou (1015323) | more than 6 years ago | (#22140840)

What progress? With every new standard, I hardly see any improvement. Browsers still render compliant pages differently, web designers still use multiple standards, and all the while the W3C tries to convince everyone that their way is the right way.

The idea of concrete "standards" isn't really compatible with the open, ever-changing, free-for-all we know as the internet. To keep up, the W3C has to keep updating their "standard", which partially defeats the purpose. frankly, I'm sick of hearing about it.

End-users don't give a damn whether a page is compliant or not. As long as it works, it's fine.

Re:Not again (0)

Anonymous Coward | more than 6 years ago | (#22141072)

What do you propse we do instead then? Wait for the browsers to implement new features on their own so we have 4 major browsers going their own way trying to do what they think is best and end up with 4 different sets of features and implementations so that no new features will be implemented cross browser? Yeah that is a great way to get the end user websites that work. God damn, the standards aren't for the people writing the HTML as they are for the people writing the browsers.

Re:Not again (3, Interesting)

MightyYar (622222) | more than 6 years ago | (#22141116)

I don't really keep up with the politics, but I think that HTML 5 is the W3C caving to exactly the sentiment that you are expressing. People weren't happy with the W3C and their pushing of standards that people weren't following (or at least not uniformly). They responded to outside pressure and HTML5 was born. So cut them some slack - they have seen the light and are attempting to be accommodating.

Anyway, the situation that you describe won't really be the case in a few years. Safari, Opera, Mozilla, and IE are all fairly standards-compliant these days. When IE6 decreases to 10% or so, the last of the really non-compliant browsers will be history.

Getting your site pixel-perfect on all of them is not and never will be trivial, because HTML is not supposed to do that. Certain sites do demand that, and for those sites we have things like Flash.

Re:Not again (2, Informative)

timbck2 (233967) | more than 6 years ago | (#22141394)

When IE6 decreases to 10% or so, the last of the really non-compliant browsers will be history.
Which shouldn't be a terribly long time:

http://it.slashdot.org/article.pl?sid=08/01/21/0652248 [slashdot.org]

Re:Not again (1)

cromar (1103585) | more than 6 years ago | (#22141466)

What progress?

If you RTFA you would have seen that there are a lot of interesting changes in HTML5 that integrate with what people are doing NOW and providing a seamless set of markup and APIs. The audio, video, and canvas tags are particularly interesting to me, as well as the host of new meta tags. HTML5 could really take the web to the next level (and I'm just talking about organizing content, here, not even web apps or anything - it has some neat features pertaining to those as well).

Re:Not again (2, Funny)

Just Some Guy (3352) | more than 6 years ago | (#22141658)

Browsers still render compliant pages differently

Oh! I found the problem. You're looking for the article about PDFs. If you'll just follow me...

Re:Not again (1)

framauro13 (1148721) | more than 6 years ago | (#22141022)

Concerning CSS, site authors don't write standard compliant code because most browsers aren't standard compliant. Just to emulate the standards across multiple browsers requires tons of hacks and alternate approaches that normally wouldn't have to be done if the damn browsers were compliant to begin with. It's not the authors' faults that they have to hack around non-compliant rendering engines.

Sorry, I'm just a very frustrated CSS developer :)

Re:Not again (1, Insightful)

Anonymous Coward | more than 6 years ago | (#22140854)

I wonder what the support for HTML 1-4.0 was before 4.1 came out. I bet it was less than total. Standards support for HTML 4.1 is pretty damned good when you look at the big picture. The standard is only not followed (even in IE) for very few features when you look at the entire standard. Full support of HTML 4.1 isn't even a requirement to start on 5. Why would we wait for everybody to finish 4.1 then say "ok, now that you are done with that, lets go do something completely different that will make all of your former work obsolete."

HTML 5 will make it so we don't have to do crazy shit to tease the functionality we want out of a standard that wasn't meant to do what we have come to expect from websites.

Re:Not again (1)

operagost (62405) | more than 6 years ago | (#22141328)

4.1? And here I am, stuck on 4.01.

Re:Not again (1)

NuShrike (561140) | more than 6 years ago | (#22141640)

That's the fault of all the dumb ass wannabe programmers out there who are getting by as corporate-paid web programmers. Most only learned it up to 2.0 spec; maybe 3.0. For further progress, they just shunted into Flash and that's it! It's not like there's compilers, nor pressure, to comply with the standard.

It's all about the lazy man's philosophy that as long as it works, on to the next project. Until browsers start failing bad syntax, the web will stay with the basics, and new HTML revisions are just more leavings of white tower masturbation.

Re:Not again (5, Informative)

hixie (116369) | more than 6 years ago | (#22143108)

Most of HTML5 was actually done outside of the W3C.

However, to address your earlier point, one of the big things we're doing with HTML5 is we're going and specifying the bits that all the other specs avoided, like 'window', like 'setTimeout', like how to parse HTML in the face of errors, and so on, and saying exactly how they should work, based on how browsers do them now, so that we can get the browsers to converge on one interoperable set of behaviours.

I'm also working on the Acid tests, e.g. Acid2 and Acid3, to foster interoperability on the older specs. It's working pretty well so far.

http://ln.hixie.ch/ [hixie.ch]
http://www.webstandards.org/action/acid3 [webstandards.org]

So... HTML5 should actually help bring the browsers closer on the bits that weren't specified before, and the Acid tests are directly intended to do that with the bits that _were_ specified before. If you want to help out, please do -- see the links above for how to help with Acid3, and the links below for how to help with HTML5:

http://blog.whatwg.org/w3c-restarts-html-effort [whatwg.org]

Number 5 ALIVE, Stephanie! (1)

rsborg (111459) | more than 6 years ago | (#22140704)

Looks like this is what Mozilla, Apple, Microsoft, etc will need to begin supporting 5 in the future.
How long that takes, noone really knows. More importantly, how easy will this be to use and how useful will the semantic bindings be?

Finally, anyone know if HTML5 mandates any specific version of EMCA/Java-Script? That part seemed vague to me.

Someone hire this guy! (4, Insightful)

nacturation (646836) | more than 6 years ago | (#22140890)

Looks like this is what Mozilla, Apple, Microsoft, etc will need to begin supporting 5 in the future.
I think they should hire you for your keen insight.

How long that takes, noone really knows.
Another stunning peek into the future.

More importantly, how easy will this be to use and how useful will the semantic bindings be?
It'll be as easy to use as a snowboard and as useful as a hammer.

Finally, anyone know if HTML5 mandates any specific version of EMCA/Java-Script? That part seemed vague to me.
A three second scan of the linked article yields:

"Implementations that use ECMAScript to implement the APIs defined in this specification must implement them in a manner consistent with the ECMAScript Bindings for DOM Specifications specification, as this specification uses that specification's terminology. [EBFD]"

Their language indicates that ECMAScript isn't a requirement. Essentially, "if you use it, you must implement it in a certain way". They don't mention requirements for implementations that don't use ECMAScript.
 

Re:Someone hire this guy! (0)

Anonymous Coward | more than 6 years ago | (#22141234)

It'll be as easy to use as a snowboard and as useful as a hammer.

As useful as a hammer is for snowboarding, you mean...

Re:Number 5 ALIVE, Stephanie! (1)

geminidomino (614729) | more than 6 years ago | (#22141060)

How long that takes, noone really knows.
About a month less than it will take for them to roll out HTML 6, at a guess...

Re:Number 5 ALIVE, Stephanie! (1)

Tacvek (948259) | more than 6 years ago | (#22141092)

Looks like this is what Mozilla, Apple, Microsoft, etc will need to begin supporting 5 in the future.
How long that takes, noone really knows. More importantly, how easy will this be to use and how useful will the semantic bindings be?

Finally, anyone know if HTML5 mandates any specific version of EMCA/Java-Script? That part seemed vague to me.
No, a user agent need not support scripting at all. If it does support an ECMAScript-based scripting language then it would likely be using the third edition or later, as the specification includes an exception system, and try catch blocks were not introduced until the third edition. However, that is no guarantee that that version will be used, as older versions with support for exception added would work as well.

Re:Number 5 ALIVE, Stephanie! (0)

Anonymous Coward | more than 6 years ago | (#22142556)

Looks like this is what Mozilla, Apple, Microsoft, etc will need to begin supporting 5 in the future.
How long that takes, noone really knows. More importantly, how easy will this be to use and how useful will the semantic bindings be?

Finally, anyone know if HTML5 mandates any specific version of EMCA/Java-Script? That part seemed vague to me.
"Noone" is spelled as two separate words, i.e. no one.

The treadmill.... (5, Insightful)

gandhi_2 (1108023) | more than 6 years ago | (#22140786)

I have this theory...some of you might too....

Large for-profit software giants must constantly make product to stay in business, pay programmers, and make profit...even if there's nothing REALLY to fix. Just make upgrades...sell new versions.

Consumers and businesses are constantly put on an upgrade-treadmill as older products are purposely torpedoed...even when they worked fine and did the job they needed to do.

now replace "for-profit software giants" with "design-by-committee standards organization" and "stay in business, pay programmers, and make profit" with "stay in charge and not have to get real jobs".

Re:The treadmill.... (3, Insightful)

keytoe (91531) | more than 6 years ago | (#22140968)

It's not a treadmill if you actually cover ground.

Re:The treadmill.... (1)

Trailer Trash (60756) | more than 6 years ago | (#22141942)

It's not a treadmill if you actually cover ground.

Not necessarily. To extend your analogy, I can still cover 2-3 feet on a treadmill while making it look like I'm running. That's what we're dealing with here.

Re:The treadmill.... (1)

winomonkey (983062) | more than 6 years ago | (#22142822)

I think that what he meant, rather than uphill-treadmill, was giant hamster ball [gameops.com] .

The two are easily confused.

Re:The treadmill.... (1)

cromar (1103585) | more than 6 years ago | (#22141626)

Yeah. It's not like the W3C has contributed anything to the internet at all. Sheesh. Who do they think they are?

Re:The treadmill.... (1)

CharAznable (702598) | more than 6 years ago | (#22142084)

Upgrade treadmill my ass... a lot of the changes in HTML 5 are very welcome, and I wish they were implemented yesterday. This is not Microsoft shoving Vista down your throat.

Re:The treadmill.... (1)

KillerCow (213458) | more than 6 years ago | (#22142124)

I would agree with you... if requirements never changed.

First thoughts (2, Interesting)

apathy maybe (922212) | more than 6 years ago | (#22140828)

Still no client side include (no, object doesn't cut it...).
People are talking about browser support, it seems to be written in such a way as they should already be able to support it if they support either HTML 4 or XHTML.
It removes lots of sylistic tags, CSS way to go.

New section tag is good.

Overall, looks interesting, cleaning up HTML a bit more, forcing it to be more of a structure rather then presentation language.

Anyway, I'll start using it, when and if, it becomes useful for my work. Otherwise, XHTML and HTML 4 are it.

Re:First thoughts (1)

onion2k (203094) | more than 6 years ago | (#22141304)

I can see advantages for most things they're proposing ... except for dropping the target attribute in anchor tags. I don't get that one. That's really useful for making external links open in new windows/tabs. Unless there's an alternative I've missed I think that could be a big mistake.

Re:First thoughts (1)

aftk2 (556992) | more than 6 years ago | (#22141372)

I would imagine they would simply advocate JavaScript for this sort of thing (not that I agree, necessarily). I could also see CSS to some degree controlling this; it's not necessarily presentational, but I could see different stylesheets making use of different target attributes for links.

Re:First thoughts (1)

brunascle (994197) | more than 6 years ago | (#22141418)

it's because the end-user is supposed to decide whether or not to open a link in a new window/tab, not the site.

Re:First thoughts (1)

RDMsoft (758318) | more than 6 years ago | (#22141648)

HTML 5 doesn't drop the target attribute for a elements, in fact it's kind-of adding it, as it was deprecated in HTML 4. It does, however, drop it for link elements.

Re:First thoughts (1)

hixie (116369) | more than 6 years ago | (#22142686)

target="" is mostly useful for targetting iframes.

Re:First thoughts (1)

cromar (1103585) | more than 6 years ago | (#22141680)

What do you want to do with client side include?? With all the security flaws around these days, I'm happy my browser isn't going to be executing external code. Or do you mean something else by that phrase?

Re:First thoughts (1)

RalphSleigh (899929) | more than 6 years ago | (#22143236)

So you can have one html file for your content, then include another html file with your sites header/footer/etc without having to resort to server side scripting. You could secure it by saying you can only include from the same domain as the main page.

Re:First thoughts (0)

Anonymous Coward | more than 6 years ago | (#22141784)

Still no client side include (no, object doesn't cut it...).
Maybe I am missing something here...but why on Earth would you need this? I really can't even see the benefit of using JS to "include" files into a web page anyways. If your web host doesn't have some kind of support for server-side development, then I think it's time to look for a new host.

Re:First thoughts (0)

Anonymous Coward | more than 6 years ago | (#22142502)

Still no client side include (no, object doesn't cut it...).

You can use Ajax for that and fall back to a static frameset. Am I missing a problem... why would you want to do this?

XHTML and HTML 4 are it.

Yeah, but what's the HTML5 namespace?

<html xmlns="http://www.w3.org/1999/xhtml" xmlns:h5="http://namespace.please/">

Then there's all the weird stuff about script... bullshit notes such as the following that completely ignore the fact the end user has the final say...


Web browsers that do not support scripting, or that have scripting disabled, might be unable to fully convey the author's intent.


I wonder, are these the same moron authors who can't do XHTML or provide fallback content for users without script?



Incidentally, best practice for unobtrusive js in XML serialization must now be...

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en">
<head>
<title>js</title>
<script type="text/javascript">
//<![CDATA[
function rewrite_noscript(){
  var e = document.getElementById('noscript');
// Repopulate with innerHTML
}
window.onload = rewrite_noscript;
//]]>
</script>
</head>
<body>
<div id="noscript">
No attempt has been made to ensure this page functions without javascript.
</div>
</body>
</html>

I don't know XHTML5, so I did in plain XHTML but you get the idea

Re:First thoughts (1)

Tangent128 (1112197) | more than 6 years ago | (#22142536)

Still no client side include (no, object doesn't cut it...).
XSLT covers all the usages for client-side includes I can think of; it's actually surprisingly well supported- even IE6 supports much of it.

I'm surprised you don't see much more of it.

Read the diff (2, Insightful)

DeltaSigma (583342) | more than 6 years ago | (#22140832)

And I must say, I like where this is going so far. It feels like a very natural progression from HTML4's ideology, while respecting authors' collective recent interests, such as media embedding, and <canvas>.

Still sloppy (4, Insightful)

nagora (177841) | more than 6 years ago | (#22140882)

"The DOCTYPE declaration is <!DOCTYPE html> and is case-insensitive in the HTML syntax."

So we have

<!DOCTYPE html><html>

At the start of every HTML document served with an text/html mime type? That's real rational. Let's get this tidied up once and for all and start html documents with

<HTML version='xxxx'>

Is that such a difficult concept?

TWW

Re:Still sloppy (1)

RDMsoft (758318) | more than 6 years ago | (#22141112)

The doctype syntax is retained in order to put existing browsers in no-quirks mode. Also, the html element's start tag is optional, like in HTML 4.

Re:Still sloppy (1)

Just Some Guy (3352) | more than 6 years ago | (#22141176)

Is that such a difficult concept?

I'll make you a deal: you talk to the W3C and get them to drop this completely and utterly bass-ackward broken idea of creating new non-XML flavors of HTML, and I'll talk to the XML folks about dropping the DOCTYPE requirement.

Re:Still sloppy (1)

jalefkowit (101585) | more than 6 years ago | (#22141922)

The problem is that most non-IE browsers rely on the presence of a DOCTYPE to signal whether the document should be parsed in a strict standards-compliance mode or a loose "quirks" mode. So if you ditch the DOCTYPE you're taking away authors' ability to "opt in" to stricter parsing.

Re:Still sloppy (1)

LordLucless (582312) | more than 6 years ago | (#22142340)

<html version="5" strict="true">

Still sloppy, but a least it works in all browsers (1)

bunratty (545641) | more than 6 years ago | (#22142622)

That would cause older browsers to use quirks mode, but HTML 5 compliant browsers to use standards mode. <!DOCTYPE html> causes both older and newer browsers to use standards mode, for an easy transition to HTML 5.

Re:Still sloppy (1)

BZ (40346) | more than 6 years ago | (#22143180)

IE also relies on the doctype to switch between standards and quirks (though they're planning ot add some bells and whistles in IE8).

Re:Still sloppy (5, Interesting)

hixie (116369) | more than 6 years ago | (#22142734)

Actually originally we wanted to remove the DOCTYPE altogether, and since the <html> start tag is optional that would have made the boilerplate "" (the empty string), or "<html>" if you want to include the <html> start tag. Unfortunately, in non-HTML5 browsers, if there's no DOCTYPE, you'll get quirks mode, which we wanted to avoid. That's why we went with the shortest string we could find that triggered standards mode, namely "<!DOCTYPE HTML>".

I agree that it's not ideal, but I couldn't really see a way around it.

Includes? (2, Insightful)

pr0nbot (313417) | more than 6 years ago | (#22140906)

Good to see they're binning frames.

But - why has there never been an include mechanism in HTML?

Re:Includes? (1)

MightyYar (622222) | more than 6 years ago | (#22141272)

But - why has there never been an include mechanism in HTML?
I don't know the answer, but I suspect two things:
  • Not that much demand from developers... this is simple to solve server-side.
  • Potential for abuse/mistakes. You'd have to protect browsers against nested includes/circular references which could get tricky.

Re:Includes? (1)

pr0nbot (313417) | more than 6 years ago | (#22142478)

But all that is true of CSS, and yet we have the ability to include external CSS in both HTML and in CSS itself.

Re:Includes? (1)

MightyYar (622222) | more than 6 years ago | (#22142838)

With CSS you are sold on external sheets because they cache and thus shorten load time. You might be able to make the same argument about certain types of html - say a navigation sidebar... but I bet the html that makes up even a complex sidebar is in the 1kb range once zipped. For instance, the whitespace-heavy Slashdot sidebar is 3.4k and compresses to 1.2k. I'm not sure that it is worth caching that. Their CSS, on the other hand is 56k (12k zipped).

The web will finally be useful! (0)

Anonymous Coward | more than 6 years ago | (#22140910)

Audio AND video on the same page? The mind boggles. And with 2-D graphics? I can barely conceive it.

And persistent client-side data storage has been a dream since the mythical cookie.

And editing of documents will just lead to anarchy.

This sounds like HTML Vista.

From the differences page (1)

snl2587 (1177409) | more than 6 years ago | (#22141088)

Absent Elements
font, although it is allowed when inserted by a WYSIWYG editor due to limitations in the state of the art in user interface for these editors.

I know this is for ease of use, but seriously: if the people at W3C really want a "standard", doing stuff like this does nothing but make it ok to ignore the standard. So which is it, CSS or font? Pick one!

Re:From the differences page (1)

Tacvek (948259) | more than 6 years ago | (#22142026)

They are planning on dropping this. What they will recommend dumb WYSIWYG ediotrs to use is unclear, but it may just be simple style attributes containing inline CSS. (That is certainly better than the font tag).

Summary (0)

Anonymous Coward | more than 6 years ago | (#22141108)

Many pages on the internet, are not well formed HTML.
One cannot force everybody to rewrite their pages.
HTML 5 defined the rendering behavior for pages where previously were "Implementation Defined".
In a way it describes the bahevior of the Mozilal program. Not because it is more reasonable. Simply it's what mozilla does.
On top of that, it adds a couple of new tags which help googlebots.
The problem is that a 10000 page standard that describes the bahevior of Mozilla, is not a useful standard.
Monopoly through complexity, etc...

Re:Summary (1)

msuarezalvarez (667058) | more than 6 years ago | (#22143280)

Wow. Great contribution to the debate!

no default ogg, sadly... (1, Insightful)

hitmark (640295) | more than 6 years ago | (#22141164)

title says it all really. basically they are not going for a default of ogg for audio and video by the looks of it...

Re:no default ogg, sadly... (0)

Anonymous Coward | more than 6 years ago | (#22142910)

Some "important players" put a lot of pressure in order to remove ogg/vorbis/theora minimal requirement for and during last HTML5 meeting... this is merely sabotage... maybe the W3C is not to be trusted anymore?
The Net needs real open source and royalty free codec standards NOW!

Re:no default ogg, sadly... (1)

theurge14 (820596) | more than 6 years ago | (#22143076)

Why? Ogg was supposed to be a free version of MP3. We now have AAC/MPEG-4 part 3 for audio and H.264/MPEG-4 part 10 for video. Barely anything out there supports Ogg except for a VLC and maybe one handful of apps and one or two iRiver players.

Re:no default ogg, sadly... (2, Informative)

nickptar (885669) | more than 6 years ago | (#22143342)

"We now have AAC/MPEG-4 part 3 for audio and H.264/MPEG-4 part 10 for video"... both of which are patent-encumbered.

What a Snoozer! (0, Flamebait)

moore.dustin (942289) | more than 6 years ago | (#22141186)

What a lame duck HTML5 will be. These changes serve to only annoy current developers, little more. The only benefit here is for people looking to learn HTML from the source code. It will make a little more sense at a glance, but forgive me for not finding that worthwhile. Who learns HTML via notepad and source code anymore? All the rooks are going to keep using dreamweaver and thinking they understand what is actually happening. They don't.

The only thing that might save me grief is going to be the small changes to form elements. Making something required is only half the battle though. If you are checking the data, you've gotta see if it empty anyways, so I guess this is good for the 'Name' and 'Company' fields :(

Re:What a Snoozer! (1)

bishiraver (707931) | more than 6 years ago | (#22141348)

Seems like it might also help machinereaders.

Standardizing the name of the navigation element, for example, allows a screenreader to find it usefully (on demand instead of in-line with the page). Same with the rest of the elements.

It also helps to standardize the semantic meaning of elements, to allow easier automatic syndication and searching. It's not about making the markup more readable for noobs, it's about making the markup more readable to machines (instead of everyone having a different id or class for their navigation, for example).

Re:What a Snoozer! (1)

cromar (1103585) | more than 6 years ago | (#22141590)

I'm a developer. I don't think I'll be annoyed (it's not like I can't just keep using HTML4 or hell even 1 if I wanted). In fact, I'm pretty excited. It looks like there may be some really powerful changes being made. And yes, I do edit the HTML text directly and very frequently.

Re:What a Snoozer! (1)

moore.dustin (942289) | more than 6 years ago | (#22141748)

Developers would - that was the point :)

I am not so sure about these being powerful changes... They look more like spitballs to me - Where is the powerful change that makes HTML5 worth it?

Re:What a Snoozer! (1)

cromar (1103585) | more than 6 years ago | (#22141870)

The changes in section 3.1. New Elements look really promising. Think of Opera's automatic linking of back and forward on webpages, except we could customize our browsers to say, display blogs and other online reading in a different way than more utilitarian pages, simply because the browser recognizes , , , etc. The changes to input are neat and would at least save developers a little trouble. All in all, it will be up to the browsers to implement this sort of thing, but having the possibility for the extra meta data could change the way certain types of pages are interacted with in a lot of novel ways.

Re:What a Snoozer! (1)

Hatta (162192) | more than 6 years ago | (#22142546)

Who learns HTML via notepad and source code anymore?

Is there another way to learn HTML?

Finally (2, Insightful)

Wiseman1024 (993899) | more than 6 years ago | (#22141254)

XML's syntax sucks. It's annoyingly verbose, and annoyingly lowercase (lowercase tags suck because they are harder to tell from normal text). I'm glad they're supporting HTML syntax.

On top of that, we get decent application controls such as grids, trees, better lists, and meters.

Though audio and video I can live without. I'll be the first to get rid of it in my user CSS.

Oh, and I hope they know what they're doing by removing CENTER. Currently, there's no way to replicate its behaviour from CSS (CSS2). (And no, text-align: center ain't the same.)

Re:Finally (1)

phybere (970508) | more than 6 years ago | (#22141350)

because everyone uses

Re:Finally (1)

Daniel_Staal (609844) | more than 6 years ago | (#22141400)

You want to center a block? Set it's width, and set left and right margins to 'auto'. That's CSS for 'center block relative to enclosing block.' (And yes, that behaviour is in the spec.)

Otherwise, what are you looking to do that you can't?

Re:Finally (1)

LordLucless (582312) | more than 6 years ago | (#22142590)

And if your block isn't fixed-width? Seriously, I've never understood why you need to tinker with an object's margins to changes its alignment. A whole stack of CSS stuff like this seems terribly clunky and unintuitive.

Of course, my mine gripe with the centering methods in CSS is that IE6 doesn't support them, but that's not W3Cs fault.

Re:Finally (1)

mikael_j (106439) | more than 6 years ago | (#22142748)

Setting the left and right margins to auto works just fine in IE6, although I wouldn't have been surprised if it didn't.

Also, as long as your element is set to a width smaller than the parent element then it should work, and if you want everything inside a <div> to be centered then you set "text-align: center;".

/Mikael

Re:Finally (1)

TheSunborn (68004) | more than 6 years ago | (#22142824)

If it's not fixed width, it will be as wide as it's parent and thus centering it would not make sense. What is it you are trying to do but can't do?

Re:Finally (1)

Daniel_Staal (609844) | more than 6 years ago | (#22142954)

Your block will either be fixed-width or have some width relative to it's enclosing block, otherwise you wouldn't be centering it. (The only other option is completely unknown width, and if the width is completely unknown the browser can't center it. It won't know the width either.)

And the margins thing makes sense, if you think about it: to center it, you tell it to distribute all extra space into the margins, equally. So it's logical, if a little unintuitive.

CSS isn't always the most intuitive, I'll admit. There are usually good reasons for it, and it usually allows you to do complex things which more intuitive methods would preclude you from doing, but it does seem to make some simple things hard.

Re:Finally (1)

mikael_j (106439) | more than 6 years ago | (#22141462)

XML's syntax sucks. It's annoyingly verbose, and annoyingly lowercase (lowercase tags suck because they are harder to tell from normal text). I'm glad they're supporting HTML syntax.

I'd say that XHTML (which is what we should be talking about) is actually quite nice and lowercase is a lot nicer than uppercase, or are you one of those people who think COBOL was fun to write?

Oh, and I hope they know what they're doing by removing CENTER. Currently, there's no way to replicate its behaviour from CSS (CSS2). (And no, text-align: center ain't the same.)

Oh really? Ever try actually formatting a page with CSS? set the width of your page element and then use margin-left: auto; margin-right: auto; and watch what happens...

Conclusion: HTML 5 is a new standard meant to be easier to understand since someone apparently thought the reason a lot of pages aren't standards-compliant is because XHTML is too hard, the real reason is that all those people making non-standards-compliant pages are just lazy and they'll continue being lazy with HTML 5. Also, try learning about XHTML and CSS before bashing them.

/Mikael

Re:Finally (0)

Anonymous Coward | more than 6 years ago | (#22143014)

are you one of those people who think COBOL was fun to write?


ADD ONE TO UPCASE GIVING LOVE

Re:Finally (0)

Anonymous Coward | more than 6 years ago | (#22141522)

1) XML is case sensitive, not lowercase. XHTML is lowercase in the main*, but hey, that's what those lil' angle braces are for, decent commenting, and syntax highlighting. uppercasing for "readability" is stupid.
2) HTML5 is not a replacement for XHTML - it is a complementary tech, and XHTML still can do things HTML5 cannot do.
such as embedding SVG, ODT, MathML or other XML into the document as needed.
3) No one uses center anymore. Except you I guess, and rest of your post puts your knowledge kind of in doubt.
http://dorward.me.uk/www/centre/ [dorward.me.uk]
At least you put that CSS2 qualifier in there, btw. But even there you are wrong since what you really mean is IE compatible CSS2 - which is a rather reduced subset (see below "display: table-cell")
http://www.w3.org/Style/Examples/007/center [w3.org]

* not all the time 'cause it is XML and can hook into other definitions. You may end up with a lot of perfectly legit XHTML docs using the attribute schemaLocation for example.

changes for the better (1)

debatem1 (1087307) | more than 6 years ago | (#22141516)

To be honest, after reading TFA, I thought that the response here would be mostly positive. These changes show that the w3c is committed to providing a standard that matches up with how the web is really used anymore, especially the new apis. While obviously writing sites to take advantage of them will have to wait for compliant browsers, it is pretty encouraging to me that they use the presence of implementations, rather than the finishing of the document, as the standard for completion. Personally, I look forward to the new way of handling server-side events, and the ability to ping uri's, which seems to promise a lot of power if sufficiently flexible.

No more "td align" (0)

argent (18001) | more than 6 years ago | (#22141586)

All this means is that instead of using "td align=...", you'll get people using "td style='text-align:...;'". Where's the win, other than making documents larger?

Re:No more "td align" (2, Insightful)

robmv (855035) | more than 6 years ago | (#22141706)

use CSS classes (for example <td class="numberCell">), define the look on a separate CSS file, and let the browser do its work and cache the CSS, you will reduce bandwith this way

Re:No more "td align" (1)

Rhalin (791665) | more than 6 years ago | (#22141904)

Thats really an understatement. Most of the time I see "td align" these days, its to address issues with CSS's lack of object alignment. Yes, text-align works in IE to position boxes, but this behavior has been, and probably will continue to be inconsistent between IE and Firefox, with firefox generally doing the "right" thing and only aligning the text, and IE doing the... well you get the idea. Before they start removing things from HTML because "CSS can do it", they need to make sure that CSS -really- can do it (and do it without complex nested tags or cross-browser trickery), and make sure that the browsers support that version of CSS. Disclaimer: I apologize if IE7 has fixed some of these CSS inconsistencies, but most of my work is specced to work on IE6 and FF, and if I can, Opera.

Re:No more "td align" (1)

hieu-dh (1216248) | more than 6 years ago | (#22142304)

Just so that the authors notice the size bloatness of table layouts. And wake up.

Re:No more "td align" (2, Insightful)

Scubafish (1224972) | more than 6 years ago | (#22142466)

If your using the style attribute for everything, your missing the point of CSS...

<style type="text/css">
    table.align_left td{
        text-align:left;
    }
</style>

<table class="align_left">
    <tr>
        <td>Look a left aligned cell</td>
        <td>Look a left aligned cell</td>
    </tr>
    <tr>
        <td>Look a left aligned cell</td>
        <td>Look a left aligned cell</td>
    </tr>
</table>

Still no value on select tags? (4, Insightful)

dumbo11 (798489) | more than 6 years ago | (#22142072)

If anyone involved in the spec reads this, for the love of god PLEASE include a 'value' on the "select" tag.

'as an alternative to flagging an option tag with selected="selected", a select tag may have a 'value' attribute. A renderer should select the first child option with a matching value attribute.'

Please, my servers are getting fed up with rendering an entire country list just to flag one with selected="selected".

My favorite (1)

AutoTheme (851553) | more than 6 years ago | (#22142420)

The menu element is redefined to be useful for actual menus.

container/video/audio ogg/theora/vorbis sabotage (0)

Anonymous Coward | more than 6 years ago | (#22142540)

One of the requirement of the previous HTML5 was support of *at least* ogg/theora/vorbis.
It was merely shot by "important players" at last conference.
This is sabotage since those codecs are the ONLY ones to fulfill what's required for an open source royalty free W3C standard.
The net is now able to do video and audio, but some collectives do not want it to happen by forcing a crippled standard.

HTML5 is the wrong path (5, Insightful)

Dracos (107777) | more than 6 years ago | (#22142616)

To (hopefully) anyone who understands and advocates XHTML and CSS, HTML5 is a tragic mistake. I can't believe TBL is supporting this garbage. It brings back some (but not all: <i> and <b>, but not <u>) presentational tags and gives them worthless definitions. It's full of concessions to lazy/unskilled developers. It makes XML compliance optional. It's full of niche tags which are so narrowly focused (aside, dialog) that they're almost certainly doomed to lousy browser support. It doesn't address the current inadequacies of forms. It has tons of design flaws and inconsistencies.

Until there are consequences for not following the standards, it doesn't matter what the W3C does: People will continue to make pages and sites that are "just good enough", and browsers will continue to render what they want how they want. In the past, now, and for the foreseeable future, there's no incentive for anyone to do things right other than ego.

I don't get it. The people designing this stuff are supposed to be experts in the field, yet they seem hell bent on force feeding everyone this drivel. If their true goal is the hurl the web into chaos, then they will certainly succeed.

Re:HTML5 is the wrong path (2, Informative)

hixie (116369) | more than 6 years ago | (#22142820)

XHTML failed: hardly anyone uses it. According to studies I did at Google, using a sample of several billion pages, about 0.0044% of pages use XHTML with the XML MIME type, and about 15% of people try to use XHTML, by giving the XHTML namespace, but actually use HTML, by sending it with the text/html MIME type.

I'd rather work on a spec that is considered drivel but that everyone ends up using, than work on a spec that is theoretically perfect but which makes zero impact on the world at large.

Re:HTML5 is the wrong path (1)

Nimey (114278) | more than 6 years ago | (#22143262)

So far as I know, Internet Explorer doesn't support XHTML. Since it's the majority browser, there you go.

Re:HTML5 is the wrong path (1)

Lachlan Hunt (1021263) | more than 6 years ago | (#22143106)

It doesn't address the current inadequacies of forms
Forms were the first feature the WHATWG addressed when they began working on HTML5 back in 2004. The Web Forms 2.0 spec has even been implemented by Opera and there are partial implementations of some features in other browsers. The spec was adopted by the Web Application Formats working groups in 2006 (before the HTMLWG was formed), and pending the outcome of the Forms Task Force (between the W3C's HTML and Forms working groups), the forms features will be integrated into HTML5.

http://www.w3.org/TR/web-forms-2/ [w3.org]

Re:HTML5 is the wrong path (4, Interesting)

Xest (935314) | more than 6 years ago | (#22143316)

Indeed.

HTML 5 is probably the worst thing that can happen to the web right now, slowly but surely XHTML compliance was bringing together browsers and sites, you only have to look at the magnificent jump in compatibility of sites from IE6 and Firefox 1 to IE7 and Firefox 2, whilst far from ideal still, developing Standards compliant code for the latest generation of browsers is much less of a headache than it's ever been.

HTML 5 increases ambiguity, it's a language seemingly designed for the MySpace generation - people who just want to hack together quick and dirty sites without any care or thought for scalability and accessibility. The simplification of XHTML over HTML whereby ambiguity is decreased by fixed rules, and less presentation tags was absolutely fantastic for developing sites that work on a variety of user agents as much more is left for the user agent to figure out so that small handheld devices could finally display compliant sites in a way that best fit the screen. Accessibility software such as screen readers have a much easier time as they could largely ignore CSS and stick to reading out the actual content without worry that some random presentation tags with a non-strict syntax was going to bugger up the parsing.

The most important concept with XHTML was separation of presentation from content coupled with a strict syntax and HTML 5 goes against these two extremely important points for ensuring we have a clean, standardised, accessible web. It's also quite a problem that HTML 5 says "Oh you don't have to use this or that, you can do it was you want", a standard needs to make up it's fucking mind not sit on the fence because otherwise it's not much of a standard as you get people doing things in many different ways, some of which are undoubtedly going to break in some user agent or another.

Essentially what's happened with HTML 5 is we've got a language that caters for those incapable of working with a well structured language, on one hand this is great because more people can publish to the web, on the other it's awful as it basically fucks up the web further. Instead of dumbing down the underlying language and breaking the web as a result, we should be producing better tools for working with the existing language keeping the web clean without leaving it difficult to publish to.

Do we really want to prolong the old situation of sites that only work or look differently with some browsers and that are inaccesible to people with special accessibility requirements? Not to mention that aren't scalable as content and presentation get mangled into one and hence really aren't maintainable either?

No more style attribute?!?!?! (3, Interesting)

TrebleJunkie (208060) | more than 6 years ago | (#22142932)

No more style attributes on any element.

*blink*

Idiocy. Abso-fucking-lute idiocy.

This by itself nearly renders in-browser dhtml applications (ajax or no) non-complaint and broken.

Somebody really needs to wrench the HTML spec out of the hands of the W3C and place it into the hands of somebody who spends a little time on other side of the ivory towers.

Uploading Files (2, Insightful)

Blobule (913778) | more than 6 years ago | (#22142972)

I didn't see anything new for uploading files. It would be great if improved support for uploads could be considered. Currently uploading 10 files requires 10 file widgets and performing the browse/select process for each one. It would be nice if the kind of interface found on sites like facebook for uploading multiple images/files could be achieved without the need for Flash or Java.

Fix : text, sizing, rendering (3, Insightful)

victim (30647) | more than 6 years ago | (#22143136)

Having used <canvas> a bit, I say fix it now!
  1. They have still left text out of the <canvas> tag. This is near insanity. The web is littered with people working around this to get labels onto graphs, current solutions are:
    • overlay a transparent div and absolute position some text elements. Works, but no rotating and is fiddly to get the sizing correct.
    • Take a truetype font, render an image of all the glyphs into a grid and know the coordinates of each ones bounding box then paste them in ransom note style to make your text. Most people are used to subpixel rendering and this won't do it. Looks a little bad for small text, ok for large. Big downloads.
    • Be a plotter. Use the Hershey fonts from NIST back in the good old days of pen plotters. (google://hershey&canvas&element). Small, fast, only one font face, antialiasing looks a little blurrier than modern typography at small sizes.

    Hey working group! Use CSS to pick a font. Give a method to get the various metrics of a layed out string and one to draw it. That will cover most uses.

  2. Lack of dynamic resizing: The width and height is specified in the HTML. It would be nice for this to be dynamic so you could use a canvas for DIV backgrounds, like the gradients behind the slashdot article titles. (Yes, obviously those gradients take fewer bytes as images, but you could do something other than repeat a tiny graphic. Use your imagination.)
  3. Address rendering: The canvas uses coordinate transformations to nicely separate the display coordinates from the drawing coordinates. This is good, but if the browser antialiases then you get radically different results for lines that fall on the pixels and ones that fall in the cracks. There should be language in the spec that leads implementors to all make the same decisions about antialiasing so that authors don't have to try to guess which way a client is going to render.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

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

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

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

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