W3C Publishes First Public Working Draft of HTML 5 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."
Number 5 ALIVE, Stephanie! (Score:2)
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! (Score:5, Insightful)
"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: (Score:2)
Re: (Score:2)
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.
The treadmill.... (Score:5, Insightful)
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.... (Score:4, Insightful)
Re: (Score:2)
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: (Score:3, Funny)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
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".
Right. Because the current standards are so flawless and slopping over with intuitiveness that they can't be improved upon, and the needs of developers, content providers, and end users never ever change. If there's anything to love about the web game, it's how it's reliable and rock solid and fantastically
Re:The treadmill.... (Score:5, Informative)
Also, spec writers aren't in charge of anything. This is actually a common fallacy, which leads to people writing specs without paying attention to their users and implementers -- just look at most specs coming out of the W3C. No, spec writers are in fact at the very bottom of the food chain. We can only specify things which the implementers want to implement, otherwise they'll ignore us, and we are only able to control what users do in so far as we tell them to do things that they want to do, otherwise they'll ignore us too. Just look at browser vendors ignoring specs they disagree with. Just look at how many pages have some sort of syntax error (over 93% according to a study of several billion documents I did last year).
With HTML5 we're specifically trying to avoid torpedoing what implementers and users are doing today. A huge part of the effort is to make the spec relevant, specify what users are doing, specify things that other specs left vague, add features where users are working around holes in the spec, etc.
As to whether my job is a "real job" or not... I can't speak to that. It's a lot of work, at least.
Re: (Score:2)
First thoughts (Score:3, Interesting)
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: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Read the diff (Score:2, Insightful)
Still sloppy (Score:5, Insightful)
So we have
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
Is that such a difficult concept?
TWW
Re: (Score:2)
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: (Score:2)
Re: (Score:2)
Re: (Score:2)
Still sloppy, but a least it works in all browsers (Score:2)
Re: (Score:2)
Re:Still sloppy (Score:5, Interesting)
I agree that it's not ideal, but I couldn't really see a way around it.
Re:Still sloppy (Score:4, Interesting)
If every version of HTML is going to be identical from the browser's point of view, why bother including any versioning information in there at all?
As far as validators go: the point of validators is to report errors. When HTML6 comes out, if there are things in HTML6 that are errors that aren't errors in HTML5, that presumably means we found bugs in the HTML5 spec, and so it is more helpful to authors if we report them than if we don't. Therefore validators should always validate against the latest spec (unless manually configured otherwise, of course), and the validators don't need a version number in the format.
Having version numbers in formats makes people do stupid things, like make behaviour depend on the version flag. Not having a version number in the format makes people notice that kind of mistake more (since then explicit flags have to be invented to make the mistake, instead of just using the version number in the format).
Includes? (Score:3, Insightful)
But - why has there never been an include mechanism in HTML?
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
From the differences page (Score:2)
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: (Score:2)
Re: (Score:2)
If W3C demanded CSS, then it would get ignored or at best implemented as <span style="color:red">, which is just as bad as <font color="red">.
no default ogg, sadly... (Score:2, Insightful)
Re: (Score:2)
Re: (Score:2, Informative)
Re: (Score:2)
Finally (Score:2, Insightful)
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
Re: (Score:2)
Otherwise, what are you looking to do that you can't?
Re: (Score:2)
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: (Score:2)
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: (Score:2)
Re: (Score:2)
Re: (Score:2)
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 ad
Re: (Score:2)
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).
Re: (Score:3, Insightful)
There's also work to make validators for HTML5 that are far more detailed and friendly than
Two words: syntax highlighting (Score:2)
...and delightfully extensible and powerful...
...which is why I used one of the many open source and/or freeware text editors out there that support syntax highlighting. I can honestly say that I've never had a problem telling my tags and attributes from my content, and even when I'm not using case-sensitive markup, I never use asinine CAPITAL LETTERS to denote su
Still no value on select tags? (Score:4, Insightful)
'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".
Re: (Score:2)
Re: (Score:2)
HTML5 is the wrong path (Score:5, Insightful)
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: (Score:3, Informative)
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: (Score:2)
Re: (Score:3, Informative)
There are also a growing number of HTML5 parsers out there, including some for Python, Ruby, and Java, with more being written. The spec makes it actually really brain-dead easy to implement an HTML5 parser that is compatible with Web conten
Re: (Score:2)
XHTML is kind of nice, but Microsoft has rendered it irrelevant by ignoring it. So we use HTML 5, which maybe has a better chance of supplanting HTML 4.01.
Re: (Score:3, Informative)
No version of IE supports XHTML's correct mime type. XHTML "failed" not because people didn't want to use it, or didn't understand it, but because the majority browser didn't support it. So XHTML is served with the mime type IE does understand, and this is a practical, if far from ideal, compromise. The problem lies with the browser(s), not the users or developers.
I'd rather have a spec that is perfect and correctly implemented than a perverted one that still won't be correctly implemented.
Re: (Score:2, Informative)
Re:HTML5 is the wrong path (Score:5, Interesting)
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?
Re:HTML5 is the wrong path (Score:5, Insightful)
As far as I understand, HTML 5 specifies exactly how a user agent should deal with formally incorrect code. I have never understood some people's obsession with XHTML, where a compliant browser is supposed to display an error message. With Opera, I encounter "XHTML" pages every now and then that do not display at all because they were dynamically generated from a database and there is a single illegal character in there or a forgotten close tag in a string coming from a database. How is that supposed to help anyone that every scripted page needs to be tested against every possible input condition? It could have been made optional in the user-agent to display a warning for web developers, but no, the spec requires that the browser justs bails out.
And xhtml also sucks for hand-coded pages since it is full of redundant closing tags, for things like <br>, <tr>, <td>, <li, and so on. It's only more typing and more obfuscating syntactic sugar. There are millions of people who create web content, and only a handful browsers. To me it is obvious that it is a waste of manpower to require of millions of people to learn the exact strict xhtml rules rather than make the browsers more flexible with non-conformant input, in a well-defined cross-browser portable manner. HTML 5 will add new useful features. XHTML adds nothing that wasn't already possible in HTML 4.01-strict (the version without font/frameset/bgcolor/etc. stuff).
I think you are talking about spacer GIFs and table markup. As far as I know, you can still abuse tables for page layout in XHTML. Moreover, to make a page that is really portable between 1024 pixel monitors and devices with a 150 pixel-wide screen requires much more than just xhtml/css; both the CSS and the page structure need to be carefully designed to be portable, in a way that is not enforced by the xhtml spec.
Re: (Score:3, Informative)
Naturally, semantic tables should never be used for layout purposes, and that has never been allowed by any of the HTML specs.
Re: (Score:2)
No more style attribute?!?!?! (Score:4, Interesting)
*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 (Score:2, Insightful)
Fix : text, sizing, rendering (Score:4, Insightful)
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.
The standards are just not very good (Score:3, Interesting)
All of that is true. But I have come to believe that perhaps the blame lies primarily with the standards themselves. They are just not very good.
I know this is not a popular opinion. Let me qualify it and try to explain briefly what I mean. There is of course a lot of theoretical and historical background to consider, but frankly it is a waste of time to drag all that into a Slashdot comment.
The first problem is with HTML. HTML abstracts at the wrong level. It should be a presentation language, not a structural markup language. There is no need for HTML as a structural markup language and frankly I am baffled by the religious zeal with which some people defend this notion. As a structural markup language, HTML is very poor. Structural markup is most useful for well-defined, domain-specific applications. That is not what HTML is used for and this causes numerous problems: ill-defined rendering behavior, poor querying and indexing abilities, poor feature set, relatively slow performance, not to mention poor reusability.
The second problem is with CSS. Although at its core a good idea, it is poorly implemented, with a pointlessly weird, C-inspired syntax. It is too feeble to express presentational structure and lacks a method to express generalized context-dependent relationships. The selector language is so baroque that it is poorly understood by authors and implementors alike. Most importantly, CSS simply does not solve many common layout and styling problems, except at the most trivial level. Efforts to address this have mostly just made CSS more complicated rather than more powerful.
The third problem is with Javascript. The language itself is not bad, but it exists in an environment that is so primitive and crude, that often the easiest way to accomplish anything is still to just stuff precalculated strings into a node's innerHTML. The web is littered with the corpses of Javascript libraries to provide simple services like data binding, templating, input validation and widget sets. None of which build on eachother, because there are no tools to enable this kind of workflow, and most of which fail on either correctness, performance or standards-compliance.
Why are there so many problems with these standards? Is it normal for standards to be so problematic? It is certainly true that numerous standards failed. But on the other hand, many other standards succeeded. PostScript and PDF are very successful standards that have been implemented dozens of times with minimal interoperability issues. The same goes for countless file format standards, such as GIF, PNG, JPG and ZIP, or standards such as ASCII or Unicode.
Of course the comparison between HTML (and all related tech) and, say, GIF, is not valid. In the case of HTML there are many reasons, some socio-economic, which have brought us to the point where we are today. But despite that, I believe it is possible to identify 2 key issues with the W3C family of tech:
Re:Not again (Score:5, Insightful)
I can't be the only one who thinks the W3C is annoying as hell...
Re:Not again (Score:4, Interesting)
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: (Score:3, Informative)
http://it.slashdot.org/article.pl?sid=08/01/21/0652248 [slashdot.org]
Re: (Score:2)
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: (Score:3, Funny)
Oh! I found the problem. You're looking for the article about PDFs. If you'll just follow me...
Re: (Score:2)
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
Re: (Score:2)
Re:Not again (Score:5, Informative)
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]
Re: (Score:2)
There are lots of hacks out there that do this, but it seems like it c
Re: (Score:2, Informative)
What you describe seems more like a stylistic thing than a semantic thing (e.g. it wouldn't really make much sense in a speech browser, as far as I can tell). I recommend suggesting it to the CSS working group.
Re:Not again (Score:5, Informative)
(BTW, all of the above should work even when Javascript is disabled, so you NoScript users get security _AND_ functionality)
Re: (Score:2)
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
Re: (Score:2)
Re: (Score:2)
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: (Score:2)
Re: (Score:2)
Just a little heads up: Slashdot ate the gast you entered; you have to use < and > instead of the brackets.
Some kind of <verbatim> tag would be nice for Slashdot. Something that just makes sure that the enclosed text is bracket-transformed
Re: (Score:2)
Re: (Score:2)
Is there another way to learn HTML?
Re:Of course, it won't matter. (Score:4, Interesting)
Re: (Score:3, Insightful)
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: (Score:3, Informative)
Re: (Score:2)
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: (Score:2, Insightful)
But yeah, like with software development, you have to fix bugs when you find them, and you rarely find the bugs before actually trying to use the software (or in this case, the spec).
Re:Of course, it won't matter. (Score:4, Insightful)
Re:Of course, it won't matter. (Score:4, Informative)
Several of the features (e.g. Canvas) are already supported by all major browsers save for IE.
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.
Re: (Score:2, Insightful)
Re: (Score:2)
Re: (Score:2, Insightful)
<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
Re: (Score:3, Informative)
Re: (Score:2)