Re: [whatwg] Removing versioning from HTML
On Fri, 14 Aug 2009, João Eiras wrote: On Fri, 14 Aug 2009 12:01:31 +0100, Ian Hickson i...@hixie.ch wrote: On Sun, 9 Aug 2009, Aaron Boodman wrote: I frequently see the comment on this list and in other forums that something is too late for HTML5, and therefore discussion should be deferred. I would like to propose that we get rid of the concepts of versions altogether from HTML. In reality, nobody supports all of HTML5. Each vendor supports a slightly different subset of the spec, along with some features that are outside the spec. This seems OK to me. Instead of insisting that a particular version of HTML is a monolithic unit that must be implemented in its entirety, we could have each feature (or logical group of features) spun off into its own small spec. We're already doing this a bit with things like Web Workers, but I don't see why we don't just do it for everything. Just as they do now, vendors would decide at the end of the day which features they would implement and which they would not. But we should never have to say that the spec is too big. If somebody is interested in exploring an idea, they should be able to just start doing that. I agree in principle. I wholeheartedly agree with all the reasoning, but there are issues. From an implementor's point of view it is much harder to implement and keep up with a mutating specification. During implementation a stable spec is preferred. The parts of the spec you would be implementing would still be stable, it's just that other parts of it would evolve. Currently, because specs are being edited and might take a while to get to CR, we have different implementors implement different parts of the specifications, and then meanwhile the specification mutates and implementors have to waste time updating their implementation which could have been right from the start. I understand that implementation feedback is necessary, but this is not very optimal. We have to keep the spec from running away from implementations anyway, whether we have a stable snapshot model or a continually evolving model. After a spec gets to CR it can't just mutate out of thin air, hence forking it into a new version is the way to go. Example: Gecko, Webkit and IE have localStorage, but the spec changed a few days ago to allow structured storage. If we do snapshots, it just means the implementors are working on an obsolete version of the spec, which is worse. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Removing versioning from HTML
On Sun, 9 Aug 2009, Aaron Boodman wrote: I frequently see the comment on this list and in other forums that something is too late for HTML5, and therefore discussion should be deferred. I would like to propose that we get rid of the concepts of versions altogether from HTML. In reality, nobody supports all of HTML5. Each vendor supports a slightly different subset of the spec, along with some features that are outside the spec. This seems OK to me. Instead of insisting that a particular version of HTML is a monolithic unit that must be implemented in its entirety, we could have each feature (or logical group of features) spun off into its own small spec. We're already doing this a bit with things like Web Workers, but I don't see why we don't just do it for everything. Just as they do now, vendors would decide at the end of the day which features they would implement and which they would not. But we should never have to say that the spec is too big. If somebody is interested in exploring an idea, they should be able to just start doing that. I agree in principle. With HTML5, we had an anomalous event in that the HTML4 spec was unusable as a base, due to its woeful inadequacies in terms of precision in implementation requirements, and the large holes in terms of what the platform involves relative to what it specified. Moving forward, I would like to move to a model that is less tied to versions. I expect to start looking at this kind of thing next year. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Removing versioning from HTML
On Fri, 14 Aug 2009 12:01:31 +0100, Ian Hickson i...@hixie.ch wrote: On Sun, 9 Aug 2009, Aaron Boodman wrote: I frequently see the comment on this list and in other forums that something is too late for HTML5, and therefore discussion should be deferred. I would like to propose that we get rid of the concepts of versions altogether from HTML. In reality, nobody supports all of HTML5. Each vendor supports a slightly different subset of the spec, along with some features that are outside the spec. This seems OK to me. Instead of insisting that a particular version of HTML is a monolithic unit that must be implemented in its entirety, we could have each feature (or logical group of features) spun off into its own small spec. We're already doing this a bit with things like Web Workers, but I don't see why we don't just do it for everything. Just as they do now, vendors would decide at the end of the day which features they would implement and which they would not. But we should never have to say that the spec is too big. If somebody is interested in exploring an idea, they should be able to just start doing that. I agree in principle. I wholeheartedly agree with all the reasoning, but there are issues. From an implementor's point of view it is much harder to implement and keep up with a mutating specification. During implementation a stable spec is preferred. So versioning will allow an implementor to decide to implement the latest stable version of some spec, while work proceeds on a newer one. And when I refer mutating specification I'm not referring to the whole html5 spec, but each separate component, like web storage, web workers, video, etc... Currently, because specs are being edited and might take a while to get to CR, we have different implementors implement different parts of the specifications, and then meanwhile the specification mutates and implementors have to waste time updating their implementation which could have been right from the start. I understand that implementation feedback is necessary, but this is not very optimal. After a spec gets to CR it can't just mutate out of thin air, hence forking it into a new version is the way to go. Example: Gecko, Webkit and IE have localStorage, but the spec changed a few days ago to allow structured storage.
Re: [whatwg] Removing versioning from HTML
Hi, Versioning is a larger topic recently: http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0655.html http://lists.w3.org/Archives/Public/www-tag/2009Aug/0027.html http://lists.w3.org/Archives/Public/www-tag/2009Aug/0029.html I wonder whether there could be a consistent pattern through all the specs from WHATWG and W3C to handle versions. The issues and use cases are very similar if not the same everywhere. Thanks. Kind regards, Marcin From: whatwg-boun...@lists.whatwg.org [whatwg-boun...@lists.whatwg.org] On Behalf Of João Eiras [jo...@opera.com] Sent: Friday, August 14, 2009 9:35 PM To: WHATWG Subject: Re: [whatwg] Removing versioning from HTML On Fri, 14 Aug 2009 12:01:31 +0100, Ian Hickson i...@hixie.ch wrote: On Sun, 9 Aug 2009, Aaron Boodman wrote: I frequently see the comment on this list and in other forums that something is too late for HTML5, and therefore discussion should be deferred. I would like to propose that we get rid of the concepts of versions altogether from HTML. In reality, nobody supports all of HTML5. Each vendor supports a slightly different subset of the spec, along with some features that are outside the spec. This seems OK to me. Instead of insisting that a particular version of HTML is a monolithic unit that must be implemented in its entirety, we could have each feature (or logical group of features) spun off into its own small spec. We're already doing this a bit with things like Web Workers, but I don't see why we don't just do it for everything. Just as they do now, vendors would decide at the end of the day which features they would implement and which they would not. But we should never have to say that the spec is too big. If somebody is interested in exploring an idea, they should be able to just start doing that. I agree in principle. I wholeheartedly agree with all the reasoning, but there are issues. From an implementor's point of view it is much harder to implement and keep up with a mutating specification. During implementation a stable spec is preferred. So versioning will allow an implementor to decide to implement the latest stable version of some spec, while work proceeds on a newer one. And when I refer mutating specification I'm not referring to the whole html5 spec, but each separate component, like web storage, web workers, video, etc... Currently, because specs are being edited and might take a while to get to CR, we have different implementors implement different parts of the specifications, and then meanwhile the specification mutates and implementors have to waste time updating their implementation which could have been right from the start. I understand that implementation feedback is necessary, but this is not very optimal. After a spec gets to CR it can't just mutate out of thin air, hence forking it into a new version is the way to go. Example: Gecko, Webkit and IE have localStorage, but the spec changed a few days ago to allow structured storage. Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
Re: [whatwg] Removing versioning from HTML
On Fri, Aug 14, 2009 at 12:35 PM, João Eiras jo...@opera.com wrote: From an implementor's point of view it is much harder to implement and keep up with a mutating specification. During implementation a stable spec is preferred. As a browser implementer, I have certainly not found the dynamic nature of the spec to be a problem. In fact the opposite is true: problems in the spec can be fixed quickly when they're raised. Currently, because specs are being edited and might take a while to get to CR, we have different implementors implement different parts of the specifications, and then meanwhile the specification mutates and implementors have to waste time updating their implementation which could have been right from the start. I understand that implementation feedback is necessary, but this is not very optimal. As opposed to if we froze versions, which would mean implementers would implement part of the old specification, and meanwhile the new spec has changed it. In other words, I don't see how versioning reduces this problem at all in practice. Furthermore, you seem to be proposing versioning well in advance of CR status, since you say it will take time to reach CR. What is the metric by which we'd decide to freeze a spec, then? PK
[whatwg] Removing versioning from HTML
[If this has been discussed before, feel free to just point me there] I frequently see the comment on this list and in other forums that something is too late for HTML5, and therefore discussion should be deferred. I would like to propose that we get rid of the concepts of versions altogether from HTML. In reality, nobody supports all of HTML5. Each vendor supports a slightly different subset of the spec, along with some features that are outside the spec. This seems OK to me. Instead of insisting that a particular version of HTML is a monolithic unit that must be implemented in its entirety, we could have each feature (or logical group of features) spun off into its own small spec. We're already doing this a bit with things like Web Workers, but I don't see why we don't just do it for everything. Just as they do now, vendors would decide at the end of the day which features they would implement and which they would not. But we should never have to say that the spec is too big. If somebody is interested in exploring an idea, they should be able to just start doing that. - a
Re: [whatwg] Removing versioning from HTML
On Sun, Aug 9, 2009 at 11:10 AM, Aaron Boodmana...@google.com wrote: [If this has been discussed before, feel free to just point me there] I frequently see the comment on this list and in other forums that something is too late for HTML5, and therefore discussion should be deferred. I would like to propose that we get rid of the concepts of versions altogether from HTML. In reality, nobody supports all of HTML5. Each vendor supports a slightly different subset of the spec, along with some features that are outside the spec. This seems OK to me. Instead of insisting that a particular version of HTML is a monolithic unit that must be implemented in its entirety, we could have each feature (or logical group of features) spun off into its own small spec. We're already doing this a bit with things like Web Workers, but I don't see why we don't just do it for everything. Just as they do now, vendors would decide at the end of the day which features they would implement and which they would not. But we should never have to say that the spec is too big. If somebody is interested in exploring an idea, they should be able to just start doing that. A feature that is not widely supported is a feature we authors can't depend on. If we're lucky, we can put in some extra effort to work around the lack and still deliver a decent experience. If we're not, we simply don't do what we wanted, or deliver something inferior that relies on technologies we *can* rely on. The idea behind pushing something to the next version is that it gives implementors time to catch up to the spec and converge on what they support. This is good for people like me. ^_^ In the meantime, there's certainly nothing preventing someone from exploring an idea. The fact that it won't make it into a spec *yet* doesn't mean you can't still discuss and refine it, or implement test versions of it in js, or anything else. ~TJ
Re: [whatwg] Removing versioning from HTML
On Sun, Aug 9, 2009 at 11:10 AM, Aaron Boodman a...@google.com wrote: [If this has been discussed before, feel free to just point me there] I frequently see the comment on this list and in other forums that something is too late for HTML5, and therefore discussion should be deferred. I would like to propose that we get rid of the concepts of versions altogether from HTML. In reality, nobody supports all of HTML5. Each vendor supports a slightly different subset of the spec, along with some features that are outside the spec. This seems OK to me. Instead of insisting that a particular version of HTML is a monolithic unit that must be implemented in its entirety, we could have each feature (or logical group of features) spun off into its own small spec. We're already doing this a bit with things like Web Workers, but I don't see why we don't just do it for everything. Just as they do now, vendors would decide at the end of the day which features they would implement and which they would not. But we should never have to say that the spec is too big. If somebody is interested in exploring an idea, they should be able to just start doing that. - a If we never cut things off then the spec will really never be finished before 2020. I agree that somethings can be reopened but there are also some which have been resolved and any new discussions are coming a year++ later. -- - Adam Shannon ( http://ashannon.us )
Re: [whatwg] Removing versioning from HTML
On Sun, Aug 9, 2009 at 9:21 AM, Tab Atkins Jr.jackalm...@gmail.com wrote: A feature that is not widely supported is a feature we authors can't depend on. If we're lucky, we can put in some extra effort to work around the lack and still deliver a decent experience. If we're not, we simply don't do what we wanted, or deliver something inferior that relies on technologies we *can* rely on. Clearly, but how does limiting the things that vendors can work on affect this one way or the other? I think there is an assumption that vendors will implement something solely because it is in the spec. This is not true, and can be verified by looking at history. Just yesterday, Jonas mentioned that Mozilla was less than enthused about implementing the bb tag from HTML5. Microsoft recently suggested they weren't happy with some of the new tags introduced in HTML5. And Ian has repeatedly said that he is not interested in writing fiction: he will only spec something that vendors will implement. The idea behind pushing something to the next version is that it gives implementors time to catch up to the spec and converge on what they support. This is good for people like me. ^_^ I don't think implementations will ever catch up. Partial mixed support is the natural state of a system where there are several completing implementations, and it is healthy. Some ideas aren't good. We shouldn't halt work on other things waiting for everyone to implement every idea. That is a recipe for stagnation. Instead, let some ideas die on the vine, and let growth occur in other places. If authors want a vendor to implement something, they will still be able to put pressure on the vendor to do that. In fact, that is exactly what happens today. Ian frequently says if you want that, please go talk to the vendors. In the meantime, there's certainly nothing preventing someone from exploring an idea. The fact that it won't make it into a spec *yet* doesn't mean you can't still discuss and refine it, or implement test versions of it in js, or anything else. In theory this is true. In practice, there is a lot of nice infrastructure setup at WhatWG that would be nice to reuse. Plus the WhatWG mailing list has become a very nice place for vendors to come together and discuss browser futures. What I am suggesting is that there should be no limit to the number of micro specs in a draft state concurrently at WhatWG. On Sun, Aug 9, 2009 at 9:29 AM, Adam Shannonashannon1...@gmail.com wrote: If we never cut things off then the spec will really never be finished before 2020. Why does this matter? At the end of the day isn't the goal to have the largest number of interoperable features? Consider one reality where we try to limit what HTML5 is, and it has n features, and we get an average of n*.9 features interoperably implemented on browsers by 2020. Consider an alternate reality where we let things be a bit more open-ended and we get n*1.5*.9 features interoperably implemented by 2020. Isn't the second reality better? - a
Re: [whatwg] Removing versioning from HTML
On Sun, Aug 9, 2009 at 9:29 AM, Adam Shannonashannon1...@gmail.com wrote: If we never cut things off then the spec will really never be finished before 2020. Why does this matter? At the end of the day isn't the goal to have the largest number of interoperable features? Consider one reality where we try to limit what HTML5 is, and it has n features, and we get an average of n*.9 features interoperably implemented on browsers by 2020. Consider an alternate reality where we let things be a bit more open-ended and we get n*1.5*.9 features interoperably implemented by 2020. Isn't the second reality better? - a If you are looking for quantity of features then yes it is better, but if you are looking for quality of implementations then the latter is not as good. I would highly prefer IE to have video, audio, canvas, geoLocation implemented in IE9 than wasting that update trying to decide if we should reopen the codec issue (example of possible debate). Sure, if we can wait 10 years for HTML5 then neither matters, but I don't think that we have that option. A 20 year spec will not stand the test of time nor provide the needed qualifications for the pace of development. -- - Adam Shannon ( http://ashannon.us )
Re: [whatwg] Removing versioning from HTML
On 8/9/09 7:10 PM, Aaron Boodman wrote: [If this has been discussed before, feel free to just point me there] I frequently see the comment on this list and in other forums that something is too late for HTML5, and therefore discussion should be deferred. I would like to propose that we get rid of the concepts of versions altogether from HTML. In reality, nobody supports all of HTML5. Each vendor supports a slightly different subset of the spec, along with some features that are outside the spec. This seems OK to me. Instead of insisting that a particular version of HTML is a monolithic unit that must be implemented in its entirety, we could have each feature (or logical group of features) spun off into its own small spec. We're already doing this a bit with things like Web Workers, but I don't see why we don't just do it for everything. If you say the HTML5 draft should be split to many smaller parts, I agree. We need to be able to say that some feature is stable i.e. recommendation. Without stability it is pretty awkward to implement anything, IMO Currently there is the draft where one can just guess the stability of the features. HTML5 should contain just the core features of the web platform. Everything else should go to some other specifications. Also, I believe splitting the spec would make it more readable. -Olli
Re: [whatwg] Removing versioning from HTML
On Sun, Aug 9, 2009 at 11:50 AM, Aaron Boodmana...@google.com wrote: On Sun, Aug 9, 2009 at 9:21 AM, Tab Atkins Jr.jackalm...@gmail.com wrote: A feature that is not widely supported is a feature we authors can't depend on. If we're lucky, we can put in some extra effort to work around the lack and still deliver a decent experience. If we're not, we simply don't do what we wanted, or deliver something inferior that relies on technologies we *can* rely on. Clearly, but how does limiting the things that vendors can work on affect this one way or the other? I think there is an assumption that vendors will implement something solely because it is in the spec. This is not true, and can be verified by looking at history. Just yesterday, Jonas mentioned that Mozilla was less than enthused about implementing the bb tag from HTML5. Microsoft recently suggested they weren't happy with some of the new tags introduced in HTML5. And Ian has repeatedly said that he is not interested in writing fiction: he will only spec something that vendors will implement. Certainly, but the spec gives some nice direction. Nobody implemented the new input types, frex, until someone wrote it up; now Opera has some decent support for it, while Webkit is starting support. Aiming at a target, especially one that you know other people will probably also be aiming at, is a lot easier than coding up a new feature that you just dreamed up. The idea behind pushing something to the next version is that it gives implementors time to catch up to the spec and converge on what they support. This is good for people like me. ^_^ I don't think implementations will ever catch up. Partial mixed support is the natural state of a system where there are several completing implementations, and it is healthy. Some ideas aren't good. We shouldn't halt work on other things waiting for everyone to implement every idea. That is a recipe for stagnation. Instead, let some ideas die on the vine, and let growth occur in other places. Not completely, sure. But they'll get closer. And we certainly won't wait for everyone to implement everything - the 2022 date that keeps getting bandied about was Ian's estimation of when complete conformance from 2 browsers would first happen. HTML6 will start *long* before that. Giving people a bit of breathing room, though, and a static target to code towards, helps out. If authors want a vendor to implement something, they will still be able to put pressure on the vendor to do that. In fact, that is exactly what happens today. Ian frequently says if you want that, please go talk to the vendors. Agreed. However, using *only* author feedback to direct browser implementors seems insufficient when we can also direct it in a useful manner by the spec. In the meantime, there's certainly nothing preventing someone from exploring an idea. The fact that it won't make it into a spec *yet* doesn't mean you can't still discuss and refine it, or implement test versions of it in js, or anything else. In theory this is true. In practice, there is a lot of nice infrastructure setup at WhatWG that would be nice to reuse. Plus the WhatWG mailing list has become a very nice place for vendors to come together and discuss browser futures. What I am suggesting is that there should be no limit to the number of micro specs in a draft state concurrently at WhatWG. Nobody's preventing that sort of discussion, even if Ian says Not for HTML5. On Sun, Aug 9, 2009 at 9:29 AM, Adam Shannonashannon1...@gmail.com wrote: If we never cut things off then the spec will really never be finished before 2020. Why does this matter? At the end of the day isn't the goal to have the largest number of interoperable features? Consider one reality where we try to limit what HTML5 is, and it has n features, and we get an average of n*.9 features interoperably implemented on browsers by 2020. Consider an alternate reality where we let things be a bit more open-ended and we get n*1.5*.9 features interoperably implemented by 2020. Isn't the second reality better? That reality is fantasy, though. ^_^ The rate at which an implementor can code is independent of the number of features that are in the spec. Increase the number of features (and assume some reasonable distribution of interest among the features) and the % of them that are interoperably implemented, especially within a given time frame, will drop. There's clearly some optimizing to be done - it's silly to spec only one thing at a time and wait for everyone to implement it, but an unbounded spec size is also bad. Ian's charting a course that already leans heavily into the lots of features side of the debate, and I disagree that pushing it further in that direction will necessarily help interop. ~TJ (Imo, we are getting *way* too meta about the whole thing lately. Meta is rarely a good thing...)
