Re: [whatwg] Serving up Theora video in the real world
On Sat, 11 Jul 2009 03:35:22 +0200, Robert O'Callahan rob...@ocallahan.org wrote: On Sat, Jul 11, 2009 at 9:37 AM, Philip Jagenstedt phil...@opera.comwrote: the point is simply that calling canPlayType without out a codecs list or with specific codecs, you can learn exactly what is supported and not out of the container formats and codecs you are interested in, without the need for the strange probably/maybe/ API. I think it would be somewhat counterintuitive for canPlayType(video/ogg) to return true, but canPlayType(video/ogg; codecs=dirac) to return false. Well I disagree of course, because having canPlayType(video/ogg) mean anything else than can I demux Ogg streams is pointless. Quoting myself from http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-November/017212.html (replies from Ian) On Thu, 13 Nov 2008, Philip Jägenstedt wrote: When asking about application/ogg, this could mean 2 things: 1. can I demux Ogg streams? 2. can I demux Ogg streams and decode unknown codecs? It's the second (and thus the answer can only ever be maybe or no). [snip] Unless the codecs parameter is to be made mandatory I think that spec should explicitly make it such that the question asked is 1. In either case we will end up there because 2 is not a meaningful question anduser agents will make untruthful answers in attempts to stay compatiblewith unknown and future content (which might be supported by installingnew codecs in the media framework without upgrading the browser). Currently the spec says we should interpret canPlayType(video/ogg) as can I demux Ogg streams and decode unknown codecs?, which is a pointless question. If we seriously believe that people need the level of control provided by the 3-state answer, just let them make several queries to ask the precise questions they want to ask. -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] Serving up Theora video in the real world
On Sat, 11 Jul 2009 03:31:50 +0200, Robert O'Callahan rob...@ocallahan.org wrote: On Sat, Jul 11, 2009 at 5:23 AM, Aryeh Gregor simetrical+...@gmail.comsimetrical%2b...@gmail.com wrote: Maybe you'd try testing all the video types you support, and if one is maybe while another is probably you'd go with probably? Right. Or you might have plugin-based fallback you can use if you get maybe. Other authors with no plugin-based fallback would go ahead if they get maybe. Programmers expect binary logic, not ternary (look at the complaints about SQL's NULL). I agree. In the past I argued for two boolean functions. Anyway, it's a little late now to change canPlayType more than we just did. There is already deployed content checking for probably/maybe. Not really, the spec isn't stable yet and all deployed content is still experimental. We still have a chance to fix broken APIs (or live with them for 100 years). -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] Serving up Theora video in the real world
On Sat, Jul 11, 2009 at 9:38 PM, Philip Jägenstedt phil...@opera.comwrote: Well I disagree of course, because having canPlayType(video/ogg) mean anything else than can I demux Ogg streams is pointless. So you want canPlayType to mean one thing when provided a type without codecs, and another thing when provided a type with codecs. I don't think that's a good idea. Anyway, it's too late. If you care passionately about this you should have reopened this discussion months ago, not now that two browsers have just shipped support for the API in the spec. 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] Serving up Theora video in the real world
On Sat, 11 Jul 2009 13:15:14 +0200, Robert O'Callahan rob...@ocallahan.org wrote: On Sat, Jul 11, 2009 at 9:38 PM, Philip Jägenstedt phil...@opera.comwrote: Well I disagree of course, because having canPlayType(video/ogg) mean anything else than can I demux Ogg streams is pointless. So you want canPlayType to mean one thing when provided a type without codecs, and another thing when provided a type with codecs. I don't think that's a good idea. Yes, I'm saying that when codecs are provided true means probably and otherwise it means maybe, because the distinction is pointless. Anyway, it's too late. If you care passionately about this you should have reopened this discussion months ago, not now that two browsers have just shipped support for the API in the spec. Ian, if you agree that it's too late to change you needn't reply to any of my other points, I won't push the issue further. -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] Serving up Theora video in the real world
2009/7/11 Robert O'Callahan rob...@ocallahan.org On Sat, Jul 11, 2009 at 9:38 PM, Philip Jägenstedt phil...@opera.comwrote: Well I disagree of course, because having canPlayType(video/ogg) mean anything else than can I demux Ogg streams is pointless. So you want canPlayType to mean one thing when provided a type without codecs, and another thing when provided a type with codecs. I don't think that's a good idea. Anyway, it's too late. If you care passionately about this you should have reopened this discussion months ago, not now that two browsers have just shipped support for the API in the spec. Disagree -- the whole point of candidate rec (which the spec is driving towards) is to find out how implementable the spec is -- not just from the browser side, but from a web author side as well. If a feature turns out to not be implementable / usable in practice, that is certainly valid feedback at this stage. (Not to say it wouldn't be better to have had this conversation earlier, but I definitely don't think that the ship has sailed on this, and in practice some things you only find out once it's implemented and you can actually try using it.) 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] slideml
Hi All, http://slideml.bitflux.ch/specification/slideml_1.0/ ( old ) I am looking for any standard for slideshow !! do anybody have any knowledge of any recent development for this task. It will be difficult to implement the .odp (open standard presentation) for web !! -- ┌─┐ │Narendra Sisodiya ( नरेन्द्र सिसोदिया ) │RD Engineer │Web : http://narendra.techfandu.org │Twitter : http://tinyurl.com/dz7e4a └─┘
Re: [whatwg] Serving up Theora video in the real world
On Sat, 11 Jul 2009 14:38:02 +0200, Robert O'Callahan rob...@ocallahan.org wrote: On Sat, Jul 11, 2009 at 11:51 PM, Philip Jägenstedt phil...@opera.comwrote: Yes, I'm saying that when codecs are provided true means probably and otherwise it means maybe, because the distinction is pointless. IIRC some browsers using system media frameworks don't know what codecs they support, so they still need to be able to answer maybe when codecs are provided; you still need a three-valued result. Opera is one such browser (when using GStreamer), but even if we return maybe for video/ogg; codecs=uncertain-codec, what could be done with the information? The only way of knowing is trying to play it, which is what the resource selection algorithm would do. That's true of both maybe and probably, neither are actual guarantees. Is there any use case for distinguishing them? This is primarily a disagreement about what kind of API is more aesthetically pleasing, either way exposes the same (useful) information. I still think it would confuse authors if you return true for canPlayType(T) and false for canPlayType(U) where U is a subset of T. video/ogg; codecs=vorbis (U) is not a subset of video/ogg (T) as the codecs in T is the empty set, not the set of all codecs. Or did you have some other values of U and T in mind? -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] slideml
On 11/7/09 15:57, narendra sisodiya wrote: http://slideml.bitflux.ch/specification/slideml_1.0/ ( old ) I am looking for any standard for slideshow !! do anybody have any knowledge of any recent development for this task. It will be difficult to implement the .odp (open standard presentation) for web !! What's wrong with SMIL, or, if you want to use HTML, something like http://www.w3.org/Talks/Tools/Slidy/#(1) , perhaps updated with the CSS transitions and animations being discussed by the CSS WG? http://www.w3.org/Style/CSS/current-work -- Benjamin Hawkes-Lewis
Re: [whatwg] slideml
On Sat, Jul 11, 2009 at 9:35 PM, Benjamin Hawkes-Lewis bhawkesle...@googlemail.com wrote: On 11/7/09 15:57, narendra sisodiya wrote: http://slideml.bitflux.ch/specification/slideml_1.0/ ( old ) I am looking for any standard for slideshow !! do anybody have any knowledge of any recent development for this task. It will be difficult to implement the .odp (open standard presentation) for web !! What's wrong with SMIL, or, if you want to use HTML, something like http://www.w3.org/Talks/Tools/Slidy/#(1)http://www.w3.org/Talks/Tools/Slidy/#%281%29, perhaps updated with the CSS transitions and animations being discussed by the CSS WG? http://www.w3.org/Style/CSS/current-work -- Benjamin Hawkes-Lewis Ok, then for the time being, I will go with *Slidy* !! I want to make something similar Slideshare.net (without flash). Have anybody tried for a tool for converting existing .odp (open office impress) or pdf presentation to HTML Slidy. There is a serious need to have standard and tool for presentation over web otherwise in next few years a huge bulk will be created on non-standard formats (flash etc) -- ┌─┐ │Narendra Sisodiya ( नरेन्द्र सिसोदिया ) │RD Engineer │Web : http://narendra.techfandu.org │Twitter : http://tinyurl.com/dz7e4a └─┘
Re: [whatwg] slideml
On Sat, 11 Jul 2009 16:57:23 +0200, narendra sisodiya narendra.sisod...@gmail.com wrote: Hi All, http://slideml.bitflux.ch/specification/slideml_1.0/ ( old ) I am looking for any standard for slideshow !! do anybody have any knowledge of any recent development for this task. It will be difficult to implement the .odp (open standard presentation) for web !! Perhaps you should have a look at http://www.opera.com/browser/tutorials/operashow/ Everything you need is already in HTML/CSS, it's just a question of browser support. -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] Serving up Theora video in the real world
On Jul 10, 2009, at 6:31 PM, Robert O'Callahan wrote: On Sat, Jul 11, 2009 at 5:23 AM, Aryeh Gregor simetrical+...@gmail.com wrote: Maybe you'd try testing all the video types you support, and if one is maybe while another is probably you'd go with probably? Right. Or you might have plugin-based fallback you can use if you get maybe. Other authors with no plugin-based fallback would go ahead if they get maybe. Programmers expect binary logic, not ternary (look at the complaints about SQL's NULL). I agree. In the past I argued for two boolean functions. Anyway, it's a little late now to change canPlayType more than we just did. There is already deployed content checking for probably/maybe. If I were designing the API from scratch, I would have two functions, mightPlayType() and canDefinitelyPlayType(). That would make it easier to write natural boolean expressions. However, I think the current canPlayType() is good enough - the empty string pseudo-false return should make it mostly ok to treat canPlayType as a boolean method. Also, it's a change that we felt we could rush into Firefox and Safari updates without undue risk, before the even more broken version with the no return got locked in. To everyone proposing more wide-ranging changes , this API is probably past the point where we can freely change it any way we want. Regards, Maciej
Re: [whatwg] Serving up Theora video in the real world
On Jul 11, 2009, at 7:56 AM, Ian Fette (イアンフェッティ) wrote: 2009/7/11 Robert O'Callahan rob...@ocallahan.org On Sat, Jul 11, 2009 at 9:38 PM, Philip Jägenstedt phil...@opera.com wrote: Well I disagree of course, because having canPlayType(video/ogg) mean anything else than can I demux Ogg streams is pointless. So you want canPlayType to mean one thing when provided a type without codecs, and another thing when provided a type with codecs. I don't think that's a good idea. Anyway, it's too late. If you care passionately about this you should have reopened this discussion months ago, not now that two browsers have just shipped support for the API in the spec. Disagree -- the whole point of candidate rec (which the spec is driving towards) is to find out how implementable the spec is -- not just from the browser side, but from a web author side as well. If a feature turns out to not be implementable / usable in practice, that is certainly valid feedback at this stage. (Not to say it wouldn't be better to have had this conversation earlier, but I definitely don't think that the ship has sailed on this, and in practice some things you only find out once it's implemented and you can actually try using it.) At this point, I think video should only be changed incompatibly if it is discovered to be literally unimplementable (unlikely now that it's been implemented twice) or unusable for its desired use cases, and an incompatible break is the only fix. But I don't think the issue at hand is that serious - we're just talking about potential refinement. The design we have now for canPlayType is not my favorite, but I can't really say it's broken. Regards, Maciej
Re: [whatwg] HTML 5 video tag questions
On Jul 10, 2009, at 6:11 PM, Jeff Walden wrote: On 10.7.09 17:44, Ian Hickson wrote: The design is based around the assumption that we will eventually find a common codec so that fallback won't ever be needed in supporting UAs. So has anyone ever actually pointed out the elephant in the room here, that we might never do so? I can't remember if so. Maybe HTML5: Galaxy Quest (cf. Captain Taggart's line) just isn't going to happen in the foreseeable future. There is likely an upper bound set by the maximum possible expiration date of any patents applying to any of the viable candidates. It's just that we'd like to reach agreement well before then. (I'm also not convinced that we substantially hurt ourselves by making fallback content the final source.) I also think that would make more sense. Right now if a site wants to publish Ogg-only with Cortado as the fallback, they have to use scripting to make it work in Safari. And if a site wants to publish H. 264-only with Flash or QuickTime as the fallback, they have to use scripting to make it work in Firefox. Sites might want to do this even if there were an agreed-upon common codec that simply didn't meet their needs. So a common codec won't completely eliminate this issue. I can't see any advantage to the current design. Regards, Maciej
Re: [whatwg] HTML 5 video tag questions
On Sat, Jul 11, 2009 at 3:24 PM, Maciej Stachowiakm...@apple.com wrote: On Jul 10, 2009, at 6:11 PM, Jeff Walden wrote: On 10.7.09 17:44, Ian Hickson wrote: The design is based around the assumption that we will eventually find a common codec so that fallback won't ever be needed in supporting UAs. So has anyone ever actually pointed out the elephant in the room here, that we might never do so? I can't remember if so. Maybe HTML5: Galaxy Quest (cf. Captain Taggart's line) just isn't going to happen in the foreseeable future. There is likely an upper bound set by the maximum possible expiration date of any patents applying to any of the viable candidates. It's just that we'd like to reach agreement well before then. Not really, at some point well before then the argument will shift to a newer clearly superior to H.264 encumbered format. I would expect that H.264 would spend a period of time as a non-consideration by almost everyone since it would be inferior to something newer and yet would still require fees. You could counter that H.264 and AAC have reached some magic threshold of adoption or usability that they will not fail to the great hamster-wheel of encumbered codec upgrades, but since I've never seen anyone state what those requirements are I'm doubtful. Regardless— It's far from clear that simply waiting 15ish years would resolve the problem, even if anyone found that to be desirable.
Re: [whatwg] HTML 5 video tag questions
On 11.7.09 12:54, Gregory Maxwell wrote: ...snip... Precisely. Jeff
Re: [whatwg] HTML 5 video tag questions
On Jul 11, 2009, at 12:54 PM, Gregory Maxwell wrote: Not really, at some point well before then the argument will shift to a newer clearly superior to H.264 encumbered format. I would expect that H.264 would spend a period of time as a non-consideration by almost everyone since it would be inferior to something newer and yet would still require fees. You may be right. On the other hand, Theora and it's immediate precursor have been around for about a decade, and Theora is still considered to be contender quality-wise. This was a minor side point to what I think is the main point: video should use the fallback content as a last resort if none of the provided sources are suitable. If you are right that in a decade current codecs may all be obsolete, that is supporting evidence for this position. A final source fallback to a baseline codec may someday not be a suitable solution, if the baseline is considered obsolete by then and no one wants to use it. Regards, Maciej
Re: [whatwg] Serving up Theora video in the real world
On Sat, 11 Jul 2009 21:15:47 +0200, Maciej Stachowiak m...@apple.com wrote: On Jul 11, 2009, at 7:56 AM, Ian Fette (イアンフェッティ) wrote: 2009/7/11 Robert O'Callahan rob...@ocallahan.org On Sat, Jul 11, 2009 at 9:38 PM, Philip Jägenstedt phil...@opera.com wrote: Well I disagree of course, because having canPlayType(video/ogg) mean anything else than can I demux Ogg streams is pointless. So you want canPlayType to mean one thing when provided a type without codecs, and another thing when provided a type with codecs. I don't think that's a good idea. Anyway, it's too late. If you care passionately about this you should have reopened this discussion months ago, not now that two browsers have just shipped support for the API in the spec. Disagree -- the whole point of candidate rec (which the spec is driving towards) is to find out how implementable the spec is -- not just from the browser side, but from a web author side as well. If a feature turns out to not be implementable / usable in practice, that is certainly valid feedback at this stage. (Not to say it wouldn't be better to have had this conversation earlier, but I definitely don't think that the ship has sailed on this, and in practice some things you only find out once it's implemented and you can actually try using it.) At this point, I think video should only be changed incompatibly if it is discovered to be literally unimplementable (unlikely now that it's been implemented twice) or unusable for its desired use cases, and an incompatible break is the only fix. But I don't think the issue at hand is that serious - we're just talking about potential refinement. The design we have now for canPlayType is not my favorite, but I can't really say it's broken. Not that I except this discussion to go anywhere, but out of curiosity I checked how Firefox/Safari/Chrome actually implement canPlayType: http://wiki.whatwg.org/wiki/Video_type_parameters#Browser_Support Firefox is conservative and honest (except maybe for audio/wav; codecs=0, what could you do with the RIFF DATA chunk?) Safari gets maybe/probably backwards compared to what the spec suggests. Chrome seems to ignore the codecs parameter, claiming probably even for bogus codecs. Authors obviously can't trust the distinction between maybe and probably to any extent. -- Philip Jägenstedt Core Developer Opera Software
[whatwg] CanvasRenderingContext2D.lineTo compatibility problem
While investigating a compatibility issue with http://www.blahbleh.com/clock.php I found that the spec behaviour on CanvasRenderingContext2D.lineTo conflicts with what Gecko implements. The current spec language is The lineTo(x, y) method must do nothing if the context has no subpaths. Otherwise, it must connect the last point in the subpath to the given point (x, y) using a straight line, and must then add the given point (x, y) to the subpath. Gecko appears to treat the empty path case as moveTo(x,y). I'm going to do a bit more investigation into the behaviour of this and the other path manipulation functions to see whether lineTo is special or this logic effects every function (of course any Gecko devs may be able to answer more quickly than i can manually verify). On the *assumption* that my initial analysis is correct i propose that the language be updated to something akin to: The lineTo(x, y) method is equivalent to moveTo(x, y) if the context has no subpaths. Otherwise, it must connect the last point in the subpath to the given point (x, y) using a straight line, and must then add the given point (x, y) to the subpath. --Oliver
[whatwg] bezierCurveTo summary is incorrect
Just noticed while looking at the path modification functions that the summary of bezierCurveTo (at the beginning of Section 4.8.11.1.8) gives bezierCurveTo the signature bezierCurveTo(cpx, cpy, x, y) which is the signature for quadraticCurveTo. The signature should be bezierCurveTo(cp1x, cp1y, cp2x, cp2y, x, y) --Oliver
Re: [whatwg] Serving up Theora video in the real world
On Jul 11, 2009, at 3:34 PM, Philip Jägenstedt wrote: Not that I except this discussion to go anywhere, but out of curiosity I checked how Firefox/Safari/Chrome actually implement canPlayType: http://wiki.whatwg.org/wiki/Video_type_parameters#Browser_Support Firefox is conservative and honest (except maybe for audio/wav; codecs=0, what could you do with the RIFF DATA chunk?) Safari gets maybe/probably backwards compared to what the spec suggests. Chrome seems to ignore the codecs parameter, claiming probably even for bogus codecs. Authors obviously can't trust the distinction between maybe and probably to any extent. Thanks for doing the research. We'd appreciate bug reports on any Safari/WebKit behavior that seems incorrect, and I'll certainly ask the Apple folks who work on this to study the matter. Our life is a little harder than Mozilla's since we use a separate media framework and support an open-ended set of codecs. But still, we'd like to get this right. I think you are probably right that the maybe/probably distinction is not currently reliable and likely not relied on in practice. What we do seem to have is some reliance on the answer being one of maybe or probably as indication of a positive result. I don't know the extent of such reliance but I suspect it will be worse before we can design, implement and ship a thorough redesign. One possibility is to consider canPlayType a lost cause as far as having a really great API, and add a cleaner and better defined API in parallel. But I'm not sure the improvement would be worth the cost. Depends on the specifics. - Maciej
Re: [whatwg] CanvasRenderingContext2D.lineTo compatibility problem
Okay the behaviour for lineTo, quadraticCurveTo and bezierCurveTo without an existing subpath (unsure about arcTo any sane response to arcTo with an empty path results in one of those edge cases where webkit, gecko, and presto all disagree) should probably be changed to (worded better of course :D ): * lineTo(x, y) is equivalent to moveTo(x, y) if the context has no subpaths. * The quadraticCurveTo(cpx, cpy, x, y) method is equivalent to moveTo(cpx, cpy); quadraticCurveTo(cpx, cpy, x, y); if the context has no subpaths * The bezierCurveTo(cp1x, cp1y, cp2x, cp2y, x, y) method is equivalent to moveTo(cp1x, cp1y); bezierCurveTo(cp1x, cp1y, cp2x, cp2y, x, y); if the context has no subpaths My rational for this change is that it is a relaxation of existing API -- in the specified API these cases would become no-ops that feed into subsequent calls, eg. lineTo(..);lineTo(..);lineTo(..) will draw nothing as the path never becomes non-empty so none of the calls can ever have an effect, whereas this re-specification would result in subsequent operations drawing something. --Oliver On Jul 11, 2009, at 3:41 PM, Oliver Hunt wrote: While investigating a compatibility issue with http://www.blahbleh.com/clock.php I found that the spec behaviour on CanvasRenderingContext2D.lineTo conflicts with what Gecko implements. The current spec language is The lineTo(x, y) method must do nothing if the context has no subpaths. Otherwise, it must connect the last point in the subpath to the given point (x, y) using a straight line, and must then add the given point (x, y) to the subpath. Gecko appears to treat the empty path case as moveTo(x,y). I'm going to do a bit more investigation into the behaviour of this and the other path manipulation functions to see whether lineTo is special or this logic effects every function (of course any Gecko devs may be able to answer more quickly than i can manually verify). On the *assumption* that my initial analysis is correct i propose that the language be updated to something akin to: The lineTo(x, y) method is equivalent to moveTo(x, y) if the context has no subpaths. Otherwise, it must connect the last point in the subpath to the given point (x, y) using a straight line, and must then add the given point (x, y) to the subpath. --Oliver
Re: [whatwg] html5 state handling: overview and extensions
On Mon, 15 Jun 2009, Mike Wilson wrote: A naive solution for this would be to add something similar to a browser_context-scoped cookie. There have been several requests for things along these lines; I'd recommend taking them up with the working group working on cookies. Invisible Document state for GET requests There currently is no support for associating invisible state with a Document delivered with GET. This is also an area where web frameworks have worked around this problem, and typical workarounds are to use url-based (visible) state or to switch to POST instead. This is by design, as I understand it. It sounds like a feature request for the HTTP working group, though. Going forward I would expect authors to use AJAX-like interaction models so that there is only one page, and the state is all scripted. Document state There currently is no support for associating script state on the Document level. Any state saved in DOM or script global object will be lost on a page reload. You can use pushState() to add an entry if your state changes relative to the original state described in the resource. Use cases would include single-page Ajax applications that want to store data independent of a certain history entry, but at the same time not sharing it with other page loads (Documents) of the same application in the history of the same browsing context (otherwise sessionStorage could be used). That's not a use case, that's a description of what it enables. When would this ever happen? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
