On Thu, 03 Dec 2009 03:31:27 +0100, Kit Grose k...@iqmultimedia.com.au
wrote:
On 28/10/2009, at 1:10 PM, Aryeh Gregor wrote:
On Tue, Oct 27, 2009 at 7:40 PM, Kit Grose k...@iqmultimedia.com.au
wrote:
Can I get some sort of an understanding on why this behaviour (non-
descript error in
Can someone explain to me how this works, given Aryeh's response
above? Surely if the iPhone can determine its capacity to be able
to play a video file, other UAs could do likewise and fall back on
the content accordingly as UAs with zero video support do?
I know nothing about the iPhone,
It seems counterintuitive to me that having produced fallback content
already, I still need to use Javascript to test for compatibility
(even if I *did* generate two formats, there's obviously no guarantee
IE9 won't come out requiring WMV or a similar issue with a different
UA).
Are there
On Thu, 03 Dec 2009 14:31:41 +0100, Kornel Lesiński kor...@geekhood.net
wrote:
Can someone explain to me how this works, given Aryeh's response
above? Surely if the iPhone can determine its capacity to be able to
play a video file, other UAs could do likewise and fall back on the
content
On Thu, 03 Dec 2009 14:29:19 +0100, Kit Grose k...@iqmultimedia.com.au
wrote:
It seems counterintuitive to me that having produced fallback content
already, I still need to use Javascript to test for compatibility
(even if I *did* generate two formats, there's obviously no guarantee
IE9 won't
On 04/12/2009, at 1:13 AM, Philip Jägenstedt wrote:
I'll freely admit that the most important reason I oppose this is
because
I don't want to implement it
And I'll admit that the main reason I support it is selfish on my part
too :).
Basically I don't want to be producing OGG files (given
On 28/10/2009, at 1:10 PM, Aryeh Gregor wrote:
On Tue, Oct 27, 2009 at 7:40 PM, Kit Grose k...@iqmultimedia.com.au wrote:
Can I get some sort of an understanding on why this behaviour (non-
descript error in supported UAs rather than using the fallback content
that can provide alternate
G'day list,
I've been working on my first HTML5 frontend, which is using the video
element, and I've run into a part of the spec that I disagree with
(and would like to understand its justification):
Content may be provided inside the video element. User agents should
not show this
On Tue, Oct 27, 2009 at 7:40 PM, Kit Grose k...@iqmultimedia.com.au wrote:
[snip]
I expected (incorrectly, in this case) that if I only produced one
source element (an MP4), Firefox would drop down to use the fallback
content, as it does if I include an object element for a format not
G'day Gregory,
Thanks for the explanation. While I understand the issue you present
with precedence of JS and fallback content, I can't off the top of my
head come up with any necessary uses for the canPlayType function
(maybe as a nice-to-have, of course) had the behaviour worked more
On Tue, Oct 27, 2009 at 7:40 PM, Kit Grose k...@iqmultimedia.com.au wrote:
Can I get some sort of an understanding on why this behaviour (non-
descript error in supported UAs rather than using the fallback content
that can provide alternate access methods) would be preferred?
Suppose browsers
Thanks for the really in-depth reply; you make some excellent points
(particularly defining a video source file with the src attribute). I
think it all boils down to the fact that canPlayType() can return
maybe; and in those cases the expected behaviour I mention isn't
easily definable.
12 matches
Mail list logo
