I think this is a really good step in the right direction, the specification process is now matching up with the way the standard are actually implemented.
I think in the last few days the w3c + whatwg have taken really positive steps, both for the understanding of the technologies and the marketing of them.
Think of it as "English as Documented in OED2" versus "English as used on the street"
Both definitions are actually useful in different contexts. The second one certainly allows for more flexibility in growth and development. whatwg is recognizing that HTML, like chrome, isn't as important in a particular ordinal identifier, as they are in the features they offer and the development model behind them.
I'm guessing 95% of the people using chrome don't what version they are currently using - but it has never impacted web developers, or users, from making use of the browser.
It also aligns with agile development practices, and, if I can stretch a bit, dvcsystems - people are free to complete new stories in the HTML definition or browser, without worrying too much about other teams work, or particular releases.
I think the more people understand these technologies and their terminologies, the more people will feel comfortable using them, the more people using them the faster their development will progress.
I think these last 2 announcements have drastically helped clarify things. So as a web enthusiast I do find it great
Is this a snipe at the W3C from the WHATWG? Is it a coincidence that the W3C announced the HTML5 logo yesterday, and today the WHATWG is dropping the 5? Why would that not have been coordinated? I feel like the W3C logo would make more sense as being HTML instead of HTML5
I am a Member of the WHATWG and one of the persons that pushed for this change. We try not to snipe at the W3C. What happened was that HTML5 was used to mean a lot more than HTML5-the-spec in practice. The W3C embraced this and designed a logo around this concept. Now that the W3C was on board with calling e.g. CSS HTML5 we thought we could safely carry out a move we had wanted to make at the end of 2009. Namely dropping the 5 from HTML5 since HTML has no versions. It is a continuously evolving language.
I'll have to reserve judgment on this. The idea makes me nervous.
I guess my main fear is that the "living document" may cease to be a target that is continuously progressing forward, and instead may become merely a description of current practices. Who, then, is minding the store?
HTML5 was a decided move away from the stagnation that had become xhtml, with a lot of new ideas. It created a cohesive goal, and moved toward that goal. Each major rev of the standard gives you an opportunity to re-assess and, if necessary, change your vector.
Also, this begs the question: whither validation? What are we validating against now?
The basic idea is that the software (browsers, validators, editors), the specification, and common practice, all evolve together. This is how the web has evolved so far. We are simply acknowledging it.
In particular, it’s nice to remove the confusion around whether an HTML4 document was any different from an HTML5 document. Now it should be easier to explain that the interpretation of every web page anywhere can be described in one standard called “HTML”.
Well we could have stopped progressing without renaming the spec. You have to make sure we keep improving the Web, and if we don't, take over! That's what we did to the W3C when they stopped, after all.
(You can also join us. See http://whatwg.org/ for details. It's basically an open community.)
There's a ton of specs lacking editors. If you have anyone who can take over, let me know. We've been looking.
...and by "open" I mean anyone can join, contribute, and have a significant impact on the spec. The spec's development has been based on rational debate and research. If someone has a different vision, though, they are welcome to create a new spec, just like we did with the WHATWG when we disagreed with the W3C's vision.
reset.css + 960.gs
Build site entirely in Chrome (dev channel)
Make sure it works in IE8, turn on compatibility view ensure it works there (usually a few fixed needed for IE7).
Open it up on iPad / iPhone and ensure that works (usually no issues, somtimes need to set min-width on body)
Then pop open FF 3.0 and Safari just to make sure there are no issues
(Sorry Opera folks, you don't factor into my process)
I could care less what the standards say, no customer cares, they just want to open it in the browser of their choice and see a working site.
This new process makes a lot of sense as what you can use depends primarily on the browser demographics of the site and what people are willing to forgo to support IE6. It also meshes well with the release process browsers except for IE / Safari are moving to which is continuous release. You're always going to be limited in what part of the spec is 'valid' based on the browser demographics of your site, because every browser implements 80-90% of the spec.
Being valid according to spec and having support in a particular browser are different and unrelated things.
I am validating against doctype I use, and make sure things work as intended in browsers I'd like to support.
HTML - 5 throws out the DTD. What you validate against becomes arbitrary: could be the same tomorrow, but maybe not.
A versioned standard does not have this problem.
I realize that the response is: "validation doesn't matter". I disagree.
This is not merely about developing to the existing browser ecology. We all do that of necessity. But there has always been a somewhat-pliable boundary with versioned specs that lets you know the state of the ecology that you developed against.
That goes out the window with a living document. Many sites, such as HN and Google abandoned the DTD long ago. I do not object to this. However, I would argue that the fact that sites can choose to abandon the DTD is only enabled by the existence of a set of standards to which they choose not to bind themselves.
Abandoning a clear target is obviously not a problem today. But I am more concerned with the future: What standard are we choosing NOT to follow? I do not want to return to the chaos of the early web where we developed against browsers instead of standards. Again, I know the objections: We develop against browsers today. No, not really. You develop against browsers that have agreed to a contract of sorts to follow a coherent standard. Thus if you develop to said standard, the work required to make your site work with the current ecology is minimized. Will a "living document" lead us back to the wild west? I am not a prophet, but I am uneasy nevertheless.
This is a signal to the nitpickers to cut it out already. Now that the actual HTML5 spec is just called HTML, we're free to use the term HTML5 to describe the suite of new web standards.
I agree with fleitz. The users do not care about standards and the developers should focus on the users and consequently just make it work in all browsers without caring about the theoretical specification.
I just hope IE9 is released soon and finally implements round border...
You comment is wrong on many levels. Let's just start by saying that HTML spec (formerly known as HTML5) is a very practical work, more than any of the preceding specs. This was driven by the desire and the goal to "make it work in all browsers". I guess you don't remember the "if (document.layers)" days…
While true that users don't care, spec is not for the users. It is for developers and browser vendors, and they care a lot.
You may not care what's under the hood of your car as long as it drives you from the point A to the point B, but believe me, countless specs are involved.
For some reason the first thing that comes into my head is, "we have always been at war with Eastasia."
Bizarre Orwellian statements aside, this is a terrible move unless you're sitting in a development bubble. I can totally get behind HTML being constantly developed. Of course it is. But you need to take snapshots to act as reference points for the rest of us. Some of us kind of want to support users who might not be on the latest and greatest platform.
Do browsers have version numbers? Yes. HTML should too.
(Ideally, browsers should also report what version of HTML they support on their About page. That'd be rad. But I don't think we're going to see it any time soon.)
That was exactly the first thing that came into my head too.
The trouble with declaring a particular revision of HTML as 'supported' is that a standard as complex as HTML (or ECMAScript, or CSS) has many parts, and it's quite possible to correctly and completely support some parts and not others.
For example, HTML 4 defines that tables can have a <col> element with an "align" attribute that declares the visual alignment of cells in that column. HTML 4 became a recommendation in December 1999, and yet I know of no browser that supports the "align" attribute on <col> elements. Does that mean that every browser has to mark HTML 4 as 'not supported'?
You are assuming browsers implement a particular version of HTML. They do not. I work for a browser vendor (Opera) and what actually happens is that we keep getting closer to interoperability with each release. I.e. add support for EventSource, fix several bugs in the HTML parser, etc.
Software (and in particular the browser market) is not the same as a screwdriver. You do not bring it to market once and it is ready. It incrementally evolves over time and keeps getting better and better (when done right).
27 comments
[ 3.2 ms ] story [ 87.0 ms ] threadI think in the last few days the w3c + whatwg have taken really positive steps, both for the understanding of the technologies and the marketing of them.
w3c releasing an HTML 5 logo and the whatwg renaming HTML 5 to HTML doesn't sound that great.
Both definitions are actually useful in different contexts. The second one certainly allows for more flexibility in growth and development. whatwg is recognizing that HTML, like chrome, isn't as important in a particular ordinal identifier, as they are in the features they offer and the development model behind them.
I'm guessing 95% of the people using chrome don't what version they are currently using - but it has never impacted web developers, or users, from making use of the browser.
It also aligns with agile development practices, and, if I can stretch a bit, dvcsystems - people are free to complete new stories in the HTML definition or browser, without worrying too much about other teams work, or particular releases.
I think these last 2 announcements have drastically helped clarify things. So as a web enthusiast I do find it great
I guess my main fear is that the "living document" may cease to be a target that is continuously progressing forward, and instead may become merely a description of current practices. Who, then, is minding the store?
HTML5 was a decided move away from the stagnation that had become xhtml, with a lot of new ideas. It created a cohesive goal, and moved toward that goal. Each major rev of the standard gives you an opportunity to re-assess and, if necessary, change your vector.
Also, this begs the question: whither validation? What are we validating against now?
(You can also join us. See http://whatwg.org/ for details. It's basically an open community.)
I wish Hixie would retire and get some new blood in there. He's done good work, but it's time to move on.
...and by "open" I mean anyone can join, contribute, and have a significant impact on the spec. The spec's development has been based on rational debate and research. If someone has a different vision, though, they are welcome to create a new spec, just like we did with the WHATWG when we disagreed with the W3C's vision.
My process is basically this:
I could care less what the standards say, no customer cares, they just want to open it in the browser of their choice and see a working site.This new process makes a lot of sense as what you can use depends primarily on the browser demographics of the site and what people are willing to forgo to support IE6. It also meshes well with the release process browsers except for IE / Safari are moving to which is continuous release. You're always going to be limited in what part of the spec is 'valid' based on the browser demographics of your site, because every browser implements 80-90% of the spec.
You can validate using the HTML5 validator (http://html5.validator.nu/) - which presumably will be renamed to the HTML validator.
A versioned standard does not have this problem.
I realize that the response is: "validation doesn't matter". I disagree.
This is not merely about developing to the existing browser ecology. We all do that of necessity. But there has always been a somewhat-pliable boundary with versioned specs that lets you know the state of the ecology that you developed against.
That goes out the window with a living document. Many sites, such as HN and Google abandoned the DTD long ago. I do not object to this. However, I would argue that the fact that sites can choose to abandon the DTD is only enabled by the existence of a set of standards to which they choose not to bind themselves.
Abandoning a clear target is obviously not a problem today. But I am more concerned with the future: What standard are we choosing NOT to follow? I do not want to return to the chaos of the early web where we developed against browsers instead of standards. Again, I know the objections: We develop against browsers today. No, not really. You develop against browsers that have agreed to a contract of sorts to follow a coherent standard. Thus if you develop to said standard, the work required to make your site work with the current ecology is minimized. Will a "living document" lead us back to the wild west? I am not a prophet, but I am uneasy nevertheless.
Sarcasm aside, if HTML = HTML5, how is one to describe this? "HTML5" wasn't perfect, but its a helluva lot better than "<canvas> and friends".
[1] http://en.wikipedia.org/wiki/Taboo_%28game%29
I'm not sure what you mean by "<canvas> and friends" or what you meant by "HTML5" before.
I just hope IE9 is released soon and finally implements round border...
While true that users don't care, spec is not for the users. It is for developers and browser vendors, and they care a lot. You may not care what's under the hood of your car as long as it drives you from the point A to the point B, but believe me, countless specs are involved.
Bizarre Orwellian statements aside, this is a terrible move unless you're sitting in a development bubble. I can totally get behind HTML being constantly developed. Of course it is. But you need to take snapshots to act as reference points for the rest of us. Some of us kind of want to support users who might not be on the latest and greatest platform.
Do browsers have version numbers? Yes. HTML should too.
(Ideally, browsers should also report what version of HTML they support on their About page. That'd be rad. But I don't think we're going to see it any time soon.)
The trouble with declaring a particular revision of HTML as 'supported' is that a standard as complex as HTML (or ECMAScript, or CSS) has many parts, and it's quite possible to correctly and completely support some parts and not others.
For example, HTML 4 defines that tables can have a <col> element with an "align" attribute that declares the visual alignment of cells in that column. HTML 4 became a recommendation in December 1999, and yet I know of no browser that supports the "align" attribute on <col> elements. Does that mean that every browser has to mark HTML 4 as 'not supported'?
Software (and in particular the browser market) is not the same as a screwdriver. You do not bring it to market once and it is ready. It incrementally evolves over time and keeps getting better and better (when done right).
To counter Orwellian developments we have version control: http://html5.org/tools/web-apps-tracker