I would guess that new features would go in their own spec, like Web Workers, WebSockets, and so on. If that is the case, you can still say browser X supports things by naming the specs, e.g. Chrome supports WebSockets.
~Jonathan Castello On Sat, Aug 28, 2010 at 8:15 PM, David John Burrowes <bain...@davidjohnburrowes.com> wrote: > Hello all, > > I wanted to chime in on this discussion. Let me say up front that clearly > the w3c and the browser vendors all are on the same page as you, Ian. I'm > not in the position to be challenging your collective wisdom! > > But, I share some of the same concerns (and more) as David Bruant, and would > like to understand why this non-versioned HTML is a good thing. I keep > imagining long, painful support issues. > >>>>> What will this doctype be since it cannot be <!DOCTYPE HTML>? >>>> >>>> It can be that. HTML is backwards-compatible, meaning that an >>>> implementation of the spec in 2020 will handle content written to the >>>> spec in 2010 correctly. >>> >>> Even if I agree on this goal, I think that this is a very ambitious >>> statement. From a formal point of view, how can you prove that a change >>> that you make on a spec is backward-compatible with *any* content >>> written following the 2010 spec? >> >> We can't prove it, but we've never needed versioning for previous versions >> of HTML, and there's massive pressure to ensure we continue to not use >> versioning (the few experiments with versioning -- quirks mode and XHTML >> -- have been found to be rather disappointing, to put it mildly). > >> A number of other languages don't have versioning, for example CSS, C++. > > > I agree that they don't have access to versioning info from within the > languages. > > But, CSS has some sense of versions (CSS, CSS2, and CSS3). This gives me > some ability to say "ah, SurfBrowser 1.0 and 2.0 supported CSS1, but with 3.0 > they supported some of CSS2 etc etc. > > That is, as long as I'm using the current browser, I know I've got support > for whatever is latest. But, when I'm providing support for folks using > non-current browsers, there's some value in being able to estimate what will > and won't work there. Saying "well, I have no idea if our app will work in > the browser you have, because no one knows what form of the HTML spec it > supported" doesn't go over very well with someone paying you money :-). > > Maybe it would make more sense to version the test suite in some fashion? > Then one could say: "SurfBrowser 7.8 passes the HTML test suite of March > 15th, 2012" and so as long as folks know what that test suite is validating, > then this might address support issues just fine. > > david > >
