Re: [whatwg] Chipset support is a good argument
On Sun, 5 Jul 2009, Eric Flores wrote: I agree with 80% of your reponses to the Codecs for audio and video conversation. However, I think that you are underestimating the influencing power of the spec with regarding to available hardware support. Hardcoding a spec in hardware is a very expensive and time consuming proposition. Chipmakers do not see an incentive to add a spec to their chips if they do not have guidance that provides them a roadmap. Even if some of the browsers choose not to follow the spec, it is good for everybody to have clarity on what is the recommended roadmap (whatever roadmap is decided). The point is that there is no decided roadmap. On the other side, I'm firmly convinced that some vested interest could lobby and even pay the chipmakers for having them not adding support to Ogg. This is a free market, isn't it? As you say, it's a free market. If people want Theora chips, then it's likely that they will become available. For that to happen there has to be some demand for Theora support, though, which the spec's can't generate. Definitively not as important as the above, I also have some reservations whenever you talk about alignment of 'all the players'. Are you really expecting agreements from ALL the players? Or just the big ones? I assume that you are disregarding the smallish browsers, aren't you? I'm talking primarily about the browser vendors who take part in this mailing list's discussions and have stated an opinion, regardless of size. Finally, it looks like Dirac looks worth discussing. I hope that their proponents do not drop the ball. Agreed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Chipset support is a good argument
2009/7/5 Ian Hickson i...@hixie.ch On Sun, 5 Jul 2009, Eric Flores wrote: [...] On the other side, I'm firmly convinced that some vested interest could lobby and even pay the chipmakers for having them not adding support to Ogg. This is a free market, isn't it? As you say, it's a free market. If people want Theora chips, then it's likely that they will become available. For that to happen there has to be some demand for Theora support, though, which the spec's can't generate. I think that if Theora support is recommended in HTML5, this *will* generate demand, since content producers and (most) browser vendors alike will take advantage of it. Chips may well, in that scenario, become available. Sam
Re: [whatwg] Chipset support is a good argument
On Sun, 5 Jul 2009, Sam Kuper wrote: 2009/7/5 Ian Hickson i...@hixie.ch On Sun, 5 Jul 2009, Eric Flores wrote: [...] On the other side, I'm firmly convinced that some vested interest could lobby and even pay the chipmakers for having them not adding support to Ogg. This is a free market, isn't it? As you say, it's a free market. If people want Theora chips, then it's likely that they will become available. For that to happen there has to be some demand for Theora support, though, which the spec's can't generate. I think that if Theora support is recommended in HTML5, this *will* generate demand, since content producers and (most) browser vendors alike will take advantage of it. Chips may well, in that scenario, become available. Most browser vendors are already implementing Theora, and content producers will use whatever the browser vendors support, regardless of whether it's in the spec or not. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Chipset support is a good argument
On Mon, Jul 6, 2009 at 8:51 AM, Ian Hickson i...@hixie.ch wrote: For that to happen there has to be some demand for Theora support, though, which the spec's can't generate. Specs do generate demand --- by creating author expectation that a feature will be supported, by adding a well-known brand, and because test suites get created which vendors then compete on. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] Chipset support is a good argument
On Jul 5, 2009, at 3:41 PM, Robert O'Callahan wrote: On Mon, Jul 6, 2009 at 8:51 AM, Ian Hickson i...@hixie.ch wrote: For that to happen there has to be some demand for Theora support, though, which the spec's can't generate. Specs do generate demand --- by creating author expectation that a feature will be supported, by adding a well-known brand, and because test suites get created which vendors then compete on. For H.264, a lot of the demand was created by the initial ISO/ITU standard and the follow-on standards for hardware products such as HD video disc players, set-to boxes and mobile phones. This was actually considerably earlier than H.264 deployment on the Web. For Microsoft's WMV to participate in some of the same markets, it had to go through a formal standards process, becoming SMPTE VC-1. SMPTE has also standardized Dirac Pro (a subset with no interframe compression) as VC-2. A spec for Theora through a formal standards process might more effectively focus latent demand than a mention in the HTML spec. It would also greatly clarify the patent situation, since many holders of wide-ranging patents on video compression participate in these groups. I've asked the Xiph folks if they'd be willing to take Theora to an organization such as SMPTE.[1] Regards, Maciej [1] http://lists.xiph.org/pipermail/theora/2009-July/002418.html
Re: [whatwg] Chipset support is a good argument
On Mon, Jul 6, 2009 at 11:00 AM, Maciej Stachowiak m...@apple.com wrote: A spec for Theora through a formal standards process might more effectively focus latent demand than a mention in the HTML spec. You may be right, but that is an orthogonal issue. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
[whatwg] autobuffer on new Audio objects
When script creates an audio element using the new Audio constructor, the 'autobuffer' attribute should be automatically set on that element. Presumably scripts will only create audio elements that they actually intend to play. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
[whatwg] DOMTokenList feedback
Hi, I'm looking at the Gecko implementation of element.classList. I had a few comments about the spec. 1) http://html5.org/tools/web-apps-tracker?from=3253to=3254 missed something. There is still a mention of alphabetical sort order in the beginning of section 2.8.3: element = tokenlist . item(index) tokenlist[index] Returns the token with index index. The tokens are sorted alphabetically. 2) contains/add/remove/toggle should mention what happens if an empty string token is passed in the token argument. Looking at the DOM Core exceptions, throwing a SYNTAX_ERROR seems to be the best match in this case (if we consider an empty string as invalid): SYNTAX_ERR, introduced in DOM Level 2. If an invalid or illegal string is specified. 3) case sensitivity. Would be nice to address [1]. Note that the definition of uniqueness for .length and .item() will also need to be revisited if we want to handle classes in a case-insensitive way in quirks mode. Sylvain [1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-June/020425.html
Re: [whatwg] autobuffer on new Audio objects
What about slower, public, or WIFI connections that can't support 5 people going to yahoo.com and having audio of interviews load? Yahoo would think that everyone would want to listen to at least the first ~15-30 seconds. On Sun, Jul 5, 2009 at 7:27 PM, Robert O'Callahan rob...@ocallahan.orgwrote: When script creates an audio element using the new Audio constructor, the 'autobuffer' attribute should be automatically set on that element. Presumably scripts will only create audio elements that they actually intend to play. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6] -- - Adam Shannon ( http://ashannon.us )
Re: [whatwg] autobuffer on new Audio objects
On Mon, Jul 6, 2009 at 12:36 PM, Adam Shannon ashannon1...@gmail.comwrote: What about slower, public, or WIFI connections that can't support 5 people going to yahoo.com and having audio of interviews load? Yahoo would think that everyone would want to listen to at least the first ~15-30 seconds. What about them? I'm not sure what your point is. I think we expect new Audio to be used for scripted playing of sounds, not to create in-page audio elements. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] autobuffer on new Audio objects
On Sun, Jul 5, 2009 at 7:58 PM, Robert O'Callahan rob...@ocallahan.orgwrote: On Mon, Jul 6, 2009 at 12:36 PM, Adam Shannon ashannon1...@gmail.comwrote: What about slower, public, or WIFI connections that can't support 5 people going to yahoo.com and having audio of interviews load? Yahoo would think that everyone would want to listen to at least the first ~15-30 seconds. What about them? I'm not sure what your point is. There already low bandwidth would be crippled more than it already is. (By loading audio files. I think we expect new Audio to be used for scripted playing of sounds, not to create in-page audio elements. If that is the purpose for the audio element then it may be missing out, I would love support for in-page audio, it could be used for podcasts, radio, interviews, ect... Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6] -- - Adam Shannon ( http://ashannon.us )
[whatwg] Codecs for audio and video -- informative note?
Ian Hickson wrote: | video does support fallback, so in practice you can just use Theora and | H.264 and cover all bases. Could you replace the codec section with at least an informative note to this effect? Something like, As of 2009, there is no single efficient codec which works on all modern browsers. Content producers are encouraged to supply the video in both Theora and H.264 formats, as per the following example (If there is an older royalty-free format that is universally supported, then please mention that as well, as it will still be sufficient for some types of videos, such as crude animations.) -jJ
Re: [whatwg] Codecs for audio and video -- informative note?
On Sun, Jul 5, 2009 at 8:02 PM, Jim Jewett jimjjew...@gmail.com wrote: Ian Hickson wrote: | video does support fallback, so in practice you can just use Theora and | H.264 and cover all bases. Could you replace the codec section with at least an informative note to this effect? Something like, As of 2009, there is no single efficient codec which works on all modern browsers. Content producers are encouraged to supply the video in both Theora and H.264 formats, as per the following example (If there is an older royalty-free format that is universally supported, then please mention that as well, as it will still be sufficient for some types of videos, such as crude animations.) The browser vendors were not able to implement the same codec (because of patent's and copyrights), so no codec was able to be chosen. ( http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-July/ ) -jJ -- - Adam Shannon ( http://ashannon.us )
Re: [whatwg] Chipset support is a good argument
On Mon, Jul 6, 2009 at 8:41 AM, Robert O'Callahanrob...@ocallahan.org wrote: On Mon, Jul 6, 2009 at 8:51 AM, Ian Hickson i...@hixie.ch wrote: For that to happen there has to be some demand for Theora support, though, which the spec's can't generate. Specs do generate demand --- by creating author expectation that a feature will be supported, by adding a well-known brand, and because test suites get created which vendors then compete on. I agree: standards generate demand. It is how h.264 hardware support originated - by making it a ISO standard, the vendors knew there would be sufficient market demand for it and created the chips. Silvia.
Re: [whatwg] Chipset support is a good argument
On Mon, 6 Jul 2009, Robert O'Callahan wrote: Specs do generate demand --- by creating author expectation that a feature will be supported, by adding a well-known brand, and because test suites get created which vendors then compete on. On Mon, 6 Jul 2009, Silvia Pfeiffer wrote: I agree: standards generate demand. It is how h.264 hardware support originated - by making it a ISO standard, the vendors knew there would be sufficient market demand for it and created the chips. I disagree with both these statements, I don't think they are in fact accurate. Demand can be focused around a specification if one exists, but a specification cannot create demand, and the lack of a specification is not an impediment to deployment. We have seen both facets of this repeatedly demonstrated through the lifetime of the Web, not least of which by HTML itself. Indeed, cutting features that didn't have demand despite being in HTML4 for a decade is one of HTML5's achievements. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Codecs for audio and video -- informative note?
On Sun, 5 Jul 2009, Jim Jewett wrote: Ian Hickson wrote: | video does support fallback, so in practice you can just use Theora and | H.264 and cover all bases. Could you replace the codec section with at least an informative note to this effect? Something like, As of 2009, there is no single efficient codec which works on all modern browsers. Content producers are encouraged to supply the video in both Theora and H.264 formats, as per the following example I might add some text along these lines once it's clearer what the implementations have actually deployed. Right now, video implementations are still quite young. (If there is an older royalty-free format that is universally supported, then please mention that as well, as it will still be sufficient for some types of videos, such as crude animations.) There isn't, as far as I know. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Chipset support is a good argument
On Mon, Jul 6, 2009 at 9:00 AM, Maciej Stachowiakm...@apple.com wrote: On Jul 5, 2009, at 3:41 PM, Robert O'Callahan wrote: On Mon, Jul 6, 2009 at 8:51 AM, Ian Hickson i...@hixie.ch wrote: For that to happen there has to be some demand for Theora support, though, which the spec's can't generate. Specs do generate demand --- by creating author expectation that a feature will be supported, by adding a well-known brand, and because test suites get created which vendors then compete on. For H.264, a lot of the demand was created by the initial ISO/ITU standard and the follow-on standards for hardware products such as HD video disc players, set-to boxes and mobile phones. This was actually considerably earlier than H.264 deployment on the Web. For Microsoft's WMV to participate in some of the same markets, it had to go through a formal standards process, becoming SMPTE VC-1. SMPTE has also standardized Dirac Pro (a subset with no interframe compression) as VC-2. A spec for Theora through a formal standards process might more effectively focus latent demand than a mention in the HTML spec. It would also greatly clarify the patent situation, since many holders of wide-ranging patents on video compression participate in these groups. I've asked the Xiph folks if they'd be willing to take Theora to an organization such as SMPTE.[1] I don't think putting it through SMPTE will magically create hardware support. VC-1 and VC-2 didn't magically get hardware support through being standardised by SMPTE. It is a combination of standardisation and uptake that will get the confidence for the market. I think the W3C is in a much better position to achieve this right now than the SMPTE. Which standards body adopts it doesn't make much of a difference to the market. Don't get me wrong though: I don't have anything against putting Theora through SMPTE - if SMPTE would indeed accept such a submission. I could imagine SMPTE be interested in it for digital TV type transmissions, e.g. for picture-in-picture in combination with VC-1 or VC-2. But the SMPTE process will take a minimum of 2 years and a dedicated person to travel to meetings, prepare the extensive paperwork required, and lobby the SMPTE members - an expense that Xiph is simply not in a position to fund. Also, the documentation required for a standard is already available: a open specification, an open reference implementation, test data, and a validation approach. So, it would be a rather expensive experiment just to get political support from the TV folks. The only thing that SMPTE would probably add is a call for patent holders to come forward now. This is something that the W3C can do, too. If widely enough publicized, it should bring the risk down. Please note that this is my personal opinion and not Xiph's official stance. Regards, Silvia.
Re: [whatwg] Chipset support is a good argument
On Mon, Jul 6, 2009 at 11:44 AM, Ian Hicksoni...@hixie.ch wrote: On Mon, 6 Jul 2009, Robert O'Callahan wrote: Specs do generate demand --- by creating author expectation that a feature will be supported, by adding a well-known brand, and because test suites get created which vendors then compete on. On Mon, 6 Jul 2009, Silvia Pfeiffer wrote: I agree: standards generate demand. It is how h.264 hardware support originated - by making it a ISO standard, the vendors knew there would be sufficient market demand for it and created the chips. I disagree with both these statements, I don't think they are in fact accurate. Demand can be focused around a specification if one exists, but a specification cannot create demand, and the lack of a specification is not an impediment to deployment. We have seen both facets of this repeatedly demonstrated through the lifetime of the Web, not least of which by HTML itself. Indeed, cutting features that didn't have demand despite being in HTML4 for a decade is one of HTML5's achievements. It's not the standard alone that makes it happen. The standard is for the general market neither a necessary nor a sufficient requirement for uptake. However, for the individual vendor, a standard and the perception that the market is adopting it will be a sufficient requirement to make a decision to create a product. Lacking the standard, just the perception that the market is adopting makes taking that decision just that much harder. Regards, Silvia.
Re: [whatwg] autobuffer on new Audio objects
On Mon, Jul 6, 2009 at 1:01 PM, Adam Shannon ashannon1...@gmail.com wrote: On Sun, Jul 5, 2009 at 7:58 PM, Robert O'Callahan rob...@ocallahan.orgwrote: I think we expect new Audio to be used for scripted playing of sounds, not to create in-page audio elements. If that is the purpose for the audio element then it may be missing out, I would love support for in-page audio, it could be used for podcasts, radio, interviews, ect... For in-page audio, put an audio element in the page. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] Chipset support is a good argument
On Mon, Jul 6, 2009 at 1:44 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 6 Jul 2009, Robert O'Callahan wrote: Specs do generate demand --- by creating author expectation that a feature will be supported, by adding a well-known brand, and because test suites get created which vendors then compete on. On Mon, 6 Jul 2009, Silvia Pfeiffer wrote: I agree: standards generate demand. It is how h.264 hardware support originated - by making it a ISO standard, the vendors knew there would be sufficient market demand for it and created the chips. I disagree with both these statements, I don't think they are in fact accurate. Demand can be focused around a specification if one exists Specs can't create author demand for features that authors don't actually want, but if authors want a general feature (say, simple CSS animations) then having an implementation of that feature creates demand for that particular incarnation of the feature, and giving it the CSS WG imprimatur increases demand further. Some authors want a royalty-free video codec. We have an implementation, Theora. I believe linking HTML5 to it would increase author demand for it to be supported in all browsers, and help those authors make a stronger case. If I didn't think so, I wouldn't be wasting my time here. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] Chipset support is a good argument
On Mon, 6 Jul 2009, Silvia Pfeiffer wrote: It's not the standard alone that makes it happen. The standard is for the general market neither a necessary nor a sufficient requirement for uptake. However, for the individual vendor, a standard and the perception that the market is adopting it will be a sufficient requirement to make a decision to create a product. Lacking the standard, just the perception that the market is adopting makes taking that decision just that much harder. I don't buy it. Nobody bases their business decisions on what specs say, they base them on what their customers and potential customers say they are going to spend money on. (Or the equivalent in the relevant market.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Chipset support is a good argument
On Mon, 6 Jul 2009, Robert O'Callahan wrote: Some authors want a royalty-free video codec. We have an implementation, Theora. I believe linking HTML5 to it would increase author demand for it to be supported in all browsers, and help those authors make a stronger case. Given the volume of support Theora has gotten without it being in the spec, I don't see why putting it in HTML5 would have any effect on author demand. The demand already exists, and the customer pressure on Apple will rise as more and more sites make use of Theora. I don't see that the spec saying must...Theora would have any effect. If anything, I think it would be a negative effect, since it would mean that at least one thing in the spec was there despite it being known that one vendor is actively refusing to implement it (as opposed to just not having gotten to it yet). If I didn't think so, I wouldn't be wasting my time here. I have no doubt that you are arguing in good faith. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Chipset support is a good argument
On Sun, 5 Jul 2009, Eric Flores wrote: The point is that there is no decided roadmap. There was one, and has been recently dropped. Actually there has never been a roadmap on this issue. My point is that thinking that the free market will solve the issue by any of the two routes that you stated is even more unrealistic than assuming that Apple will implement Theora just because it is part of the spec. Apple has said they won't implement Theora regardless of whether it's in the spec or not. I agree though that it might be that the two outcomes I describe are also unlikely. Apple will not change their format even if the rest of the world uses any other thing. On the other side, the silent giant will not support anything other than their WMV and WMA format. Even if Apple and Mozilla reach an agreement, what will we do once Microsoft decides to speak up? Yes, I know the response. I don't. I wish Microsoft would speak up, as that might help tilt the balance one way or the other. Having a preferred format tips the balance for the chipmakers to make a decision, and in the case of Theora, helps to stir discussion about the supposed hidden patents. I agree entirely. It is sad that we can't find one. Theora might not be the best. But is the best that we have. We don't even have Theora right now. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Chipset support is a good argument
On Mon, 6 Jul 2009, Kartikaya Gupta wrote: 1) Do you agree with my view that specifying Theora for the video element would result in a self-fulfilling prophecy? No. I don't think it would make any difference to what browsers implement, and as far as I can tell, what browsers implement is the only thing that affects what authors adopt. 2) Do you think that it is better to sit on the fence and not specify anything, thereby forcing authors to either (a) be incompatible with some browsers or (b) re-encode their content in multiple formats? I don't think it makes any difference whether we specify something or not; if the browsers aren't all going to implement the same thing, then that is what is going to force authors to either (a) be incompatible with some browsers or (b) re-encode their content in multiple formats. Or do you think it is better to pick a side that has a good shot at winning, even if it means that some vendors may be non-compliant with the spec? I think it would be harmful to spec something that is actively different than what a browser vendor will implement. This is why HTML5 started -- because the W3C wrote specs that were idealistic and did not match reality. My view with regards to question (2) above is that one way or another, the web will settle on a single encoding format. This can be done the easy way or the hard way. The hard way is to not specify anything, and let authors and vendors battle it out for years at everybody's expense, leaving a trail of carnage and cruft behind that will then need to supported for decades. The easy way is to specify something and cross your fingers. Even if it doesn't work, at worst it will just prolong an already long and bloody battle. The benefits from the best-case scenario make the risk more than worth it. We already know what Apple will do if we put Theora in the spec. They'll ignore it. So it will not make any difference one way or the other as far as video is concerned. It will, however, mean that HTML5 is less in line with what authors can actually rely on. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Chipset support is a good argument
On Mon, 6 Jul 2009, Ian Hickson wrote: On Mon, 6 Jul 2009, Robert O'Callahan wrote: Specs do generate demand --- by creating author expectation that a feature will be supported, by adding a well-known brand, and because test suites get created which vendors then compete on. On Mon, 6 Jul 2009, Silvia Pfeiffer wrote: I agree: standards generate demand. It is how h.264 hardware support originated - by making it a ISO standard, the vendors knew there would be sufficient market demand for it and created the chips. I disagree with both these statements, I don't think they are in fact accurate. Demand can be focused around a specification if one exists, but a specification cannot create demand, and the lack of a specification is not an impediment to deployment. We have seen both facets of this repeatedly demonstrated through the lifetime of the Web, not least of which by HTML itself. Indeed, cutting features that didn't have demand despite being in HTML4 for a decade is one of HTML5's achievements. I'm not sure whether specs can create demand, and frankly, I find it somewhat irrelevant to the point at hand. The fact is there is already demand for a single encoding format that will be compatible with as many browsers as possible. The only question is what that format will be. In this case, the spec doesn't need to create demand for anything, it just needs to tell people what that format is. I believe that if HTML5 specified Theora, that would become a self-fulfilling prophecy, and Theora would become the standard (both specified and actual) of the web. There's already been a huge amount of press (on Slashdot, OSNews, Ars Technica, etc.) about the debate on this list. If a decision were to be made in favor of Theora, that would immediately be broadcast by the same channels and a lot of people (including actual and potential web authors) would be aware of it. A lot of those authors (not major publishers like YouTube, but the long tail that includes everybody else) will not bother to read the details of the decision; they will simply assume that since it is in the standard it will soon be supported by all the major browsers, and they will make their choices and start publishing content with that in mind. Since there is already some browser support for it, those efforts won't just fizzle and die. As there is an increase of Theora-encoded content, support for it will increase (including in terms of hardware) and it will drive a virtuous cycle pushing Theora to be even more widespread. In a nutshell, what I'm thinking is that putting Theora in the HTML5 spec would not be enough to magically get authors to start generating Theora-encoded content. It is, however, enough to make authors in the process of deciding between H.264 and Theora for their video content to pick Theora. It's just a little push, but that little push is enough to make all the difference. Now, I suppose all of the above may hold for H.264 instead of Theora, but I think it is far less likely given the distribution of vendors and their reasons for being in favor of a particular codec. If you disagree, that's fine. Just replace all instances of Theora with H.264 and read on. I'm also ignoring the Dirac possibility which has been mentioned a few times but doesn't seem to be being actively pursued. If that satifies everybody, so much the better. So, my questions to you are: 1) Do you agree with my view that specifying Theora for the video element would result in a self-fulfilling prophecy? 2) Do you think that it is better to sit on the fence and not specify anything, thereby forcing authors to either (a) be incompatible with some browsers or (b) re-encode their content in multiple formats? Or do you think it is better to pick a side that has a good shot at winning, even if it means that some vendors may be non-compliant with the spec? My view with regards to question (2) above is that one way or another, the web will settle on a single encoding format. This can be done the easy way or the hard way. The hard way is to not specify anything, and let authors and vendors battle it out for years at everybody's expense, leaving a trail of carnage and cruft behind that will then need to supported for decades. The easy way is to specify something and cross your fingers. Even if it doesn't work, at worst it will just prolong an already long and bloody battle. The benefits from the best-case scenario make the risk more than worth it. kats
Re: [whatwg] Chipset support is a good argument
On Mon, 6 Jul 2009 04:06:25 + (UTC), Ian Hickson i...@hixie.ch wrote: On Mon, 6 Jul 2009, Kartikaya Gupta wrote: Or do you think it is better to pick a side that has a good shot at winning, even if it means that some vendors may be non-compliant with the spec? I think it would be harmful to spec something that is actively different than what a browser vendor will implement. This is why HTML5 started -- because the W3C wrote specs that were idealistic and did not match reality. You've expressed something similar in a couple of the other threads as well, and I find it puzzling. It's true that if you spec things that will never be implemented, it harms the integrity of the spec. But on the other hand, if you allow any one vendor to determine what does or does not go into the spec [1], you're are exposing the spec to a much greater risk. In at least one other thread [2] you've implied that you treat all browser vendors as equal. If you put this together with the veto power it means that any browser vendor, regardless of size can get things axed from the spec. Am I missing something? What is stopping me from becoming a browser vendor and stating flat-out that I will not support any of the new additions in HTML5 just to kill off a good chunk of the spec? (Since I am working on a browser currently playing catch-up, this would certainly make my life easier). It seems to me that you need to either take away this veto power you've given browser vendors, or you need to draw a line between the vendors that do have veto power and the ones that don't. If you have already drawn such a line, I would like to know exactly where it is and what criteria were used to determine which vendors to allow and which ones to disallow. One of the failings of HTML5, IMHO, is that it is trying to both document existing behavior and spec new features. These two activities should use different processes with regard to vendor consensus, but they are instead getting lumped together, and the new features are getting stifled as a result. kats [1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-July/020722.html, your replies to Anne [2] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-July/020747.html
