- From: Justin James <j_james@mindspring.com>
- Date: Sun, 17 Jan 2010 01:15:56 -0500
- To: "'Shelley Powers'" <shelley.just@gmail.com>
- Cc: "'HTMLWG WG'" <public-html@w3.org>
For better or for worse, major browsers already have implemented a number of HTML 5 features, and (also "for better or for worse") a number of Web sites have already started leveraging that functionality. One thing I've noticed is an outright mockery of this group around the "HTML 5 will be a recommendation in 2022" concept, which is *incredibly* misunderstood. People have an amazing ability to miss the rest of that statement (the part about how "recommendation" means it has two full and correct implementations, which will indeed take quite a while), for whatever reason. The point is, the HTML 5 cat is already out of the bag as it were. Regardless of what people should or should not do (I'm in general agreement that leveraging features from a spec that is still in development is not a good idea unless you don't mind getting burned if it changes underneath your feet), people are already implementing and leveraging these features, and I would not be surprised if some of the HTML 5 features we keep discussing have already surpassed some of the older items that we are loathe to remove or change due to them being used by 0.001% of Web pages. J.Ja -----Original Message----- From: Shelley Powers [mailto:shelley.just@gmail.com] Sent: Sunday, January 17, 2010 12:05 AM To: Justin James Cc: HTMLWG WG Subject: Re: The harm that can come if the W3C supports publication of competing specs On Sat, Jan 16, 2010 at 10:09 PM, Justin James <j_james@mindspring.com> wrote: >> It is irresponsible of us to encourage the use of unreleased and >> unstable specifications. Even ones we like. >> >> Shelley > > That creates a "first mover" problem which will render HTML 5 forever stuck > in limbo. HTML 5 will not become a full "recommendation" without two full > and complete implementations. Therefore, HTML 5 will never because a 100% > "released" and stable specification without encouraging its use before it > has achieved that status. > > In fact, I'd say that most specs written in the modern era are like this. > The days of having a spec develop in a bubble with everyone waiting on its > public, stable release are OVER. Draft-N wireless, anyone? In reality, > plenty specifications attempt to document the "baseline" where existing > implementations overlap to provide a common ground that new implementations > can start from. Implementations. Not recommending that production sites utilize the markup. Yes, before we go to candidate recommendation, we'll need two implementations of the specifications. But that doesn't mean that production sites should incorporate specifications that aren't LC--that aren't even FPWD yet. There is a world of differences between the two. > > J.Ja > > Shelley
Received on Sunday, 17 January 2010 06:18:40 UTC