On Mon, Jun 20, 2011 at 7:31 PM, Mark Watson wats...@netflix.com wrote:
The TrackList object has an onchanged event, which I assumed would fire when
any of the information in the TrackList changes (e.g. tracks added or
removed). But actually the spec doesn't state when this event fires (as far
On Jun 20, 2011, at 11:52 AM, Silvia Pfeiffer wrote:
On Mon, Jun 20, 2011 at 7:31 PM, Mark Watson wats...@netflix.com wrote:
The TrackList object has an onchanged event, which I assumed would fire
when
any of the information in the TrackList changes (e.g. tracks added or
removed). But
On Tue, Jun 21, 2011 at 12:07 AM, Mark Watson wats...@netflix.com wrote:
On Jun 20, 2011, at 11:52 AM, Silvia Pfeiffer wrote:
On Mon, Jun 20, 2011 at 7:31 PM, Mark Watson wats...@netflix.com wrote:
The TrackList object has an onchanged event, which I assumed would fire
when
any of the
On Jun 20, 2011, at 5:28 PM, Silvia Pfeiffer wrote:
On Tue, Jun 21, 2011 at 12:07 AM, Mark Watson wats...@netflix.com wrote:
On Jun 20, 2011, at 11:52 AM, Silvia Pfeiffer wrote:
On Mon, Jun 20, 2011 at 7:31 PM, Mark Watson wats...@netflix.com wrote:
The TrackList object has an
On Thu, 09 Jun 2011 03:47:49 +0200, Silvia Pfeiffer
silviapfeiff...@gmail.com wrote:
For commercial video providers, the tracks in a live stream change all
the time; this is not limited to audio and video tracks but would
include text tracks as well.
OK, all this indicates to me that we
On Thu, Jun 9, 2011 at 4:34 PM, Simon Pieters sim...@opera.com wrote:
On Thu, 09 Jun 2011 03:47:49 +0200, Silvia Pfeiffer
silviapfeiff...@gmail.com wrote:
For commercial video providers, the tracks in a live stream change all
the time; this is not limited to audio and video tracks but would
On Jun 9, 2011, at 12:02 AM, Silvia Pfeiffer wrote:
On Thu, Jun 9, 2011 at 4:34 PM, Simon Pieters sim...@opera.com wrote:
On Thu, 09 Jun 2011 03:47:49 +0200, Silvia Pfeiffer
silviapfeiff...@gmail.com wrote:
For commercial video providers, the tracks in a live stream change all
the time;
On Wed, 08 Jun 2011 02:46:15 +0200, Silvia Pfeiffer
silviapfeiff...@gmail.com wrote:
On Tue, Jun 7, 2011 at 7:04 PM, Philip Jägenstedt phil...@opera.com
wrote:
On Sat, 04 Jun 2011 03:39:58 +0200, Silvia Pfeiffer
silviapfeiff...@gmail.com wrote:
On Fri, Jun 3, 2011 at 9:28 AM, Ian Hickson
On Wed, Jun 8, 2011 at 6:14 PM, Philip Jägenstedt phil...@opera.com wrote:
On Wed, 08 Jun 2011 02:46:15 +0200, Silvia Pfeiffer
silviapfeiff...@gmail.com wrote:
On Tue, Jun 7, 2011 at 7:04 PM, Philip Jägenstedt phil...@opera.com
wrote:
On Sat, 04 Jun 2011 03:39:58 +0200, Silvia Pfeiffer
On Wed, 08 Jun 2011 12:35:24 +0200, Silvia Pfeiffer
silviapfeiff...@gmail.com wrote:
On Wed, Jun 8, 2011 at 6:14 PM, Philip Jägenstedt phil...@opera.com
wrote:
On Wed, 08 Jun 2011 02:46:15 +0200, Silvia Pfeiffer
silviapfeiff...@gmail.com wrote:
That is all correct. However, because it is
On Wed, Jun 8, 2011 at 9:18 PM, Philip Jägenstedt phil...@opera.com wrote:
On Wed, 08 Jun 2011 12:35:24 +0200, Silvia Pfeiffer
silviapfeiff...@gmail.com wrote:
On Wed, Jun 8, 2011 at 6:14 PM, Philip Jägenstedt phil...@opera.com
wrote:
On Wed, 08 Jun 2011 02:46:15 +0200, Silvia Pfeiffer
On Wed, 08 Jun 2011 13:38:18 +0200, Silvia Pfeiffer
silviapfeiff...@gmail.com wrote:
On Wed, Jun 8, 2011 at 9:18 PM, Philip Jägenstedt phil...@opera.com
wrote:
On Wed, 08 Jun 2011 12:35:24 +0200, Silvia Pfeiffer
silviapfeiff...@gmail.com wrote:
On Wed, Jun 8, 2011 at 6:14 PM, Philip
On Jun 8, 2011, at 3:35 AM, Silvia Pfeiffer wrote:
Nothing exposed via the current API would change, AFAICT.
Thus, after a change mid-stream to, say, a smaller video width and
height, would the video.videoWidth and video.videoHeight attributes
represent the width and height of the
-Original Message-
From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-
boun...@lists.whatwg.org] On Behalf Of Eric Carlson
Sent: Wednesday, June 08, 2011 9:34 AM
To: Silvia Pfeiffer; Philip Jägenstedt
Cc: whatwg@lists.whatwg.org
Subject: Re: [whatwg] Video feedback
On Jun 8
@lists.whatwg.org
Subject: Re: [whatwg] Video feedback
On Jun 8, 2011, at 3:35 AM, Silvia Pfeiffer wrote:
Nothing exposed via the current API would change, AFAICT.
Thus, after a change mid-stream to, say, a smaller video width and
height, would the video.videoWidth
On Sat, 04 Jun 2011 03:39:58 +0200, Silvia Pfeiffer
silviapfeiff...@gmail.com wrote:
On Fri, Jun 3, 2011 at 9:28 AM, Ian Hickson i...@hixie.ch wrote:
On Thu, 16 Dec 2010, Silvia Pfeiffer wrote:
I do not know how technically the change of stream composition works in
MPEG, but in Ogg we
On Fri, 03 Jun 2011 01:28:45 +0200, Ian Hickson i...@hixie.ch wrote:
On Fri, 22 Oct 2010, Simon Pieters wrote:
Actually it was me, but that's OK :)
There was also some discussion about metadata. Language is sometimes
necessary for the font engine to pick the right glyph.
Could you
I'll be replying to WebVTT related stuff in a separate thread. Here
just feedback on the other stuff.
(Incidentally: why is there details element feedback in here with
video? I don't really understand the connection.)
On Fri, Jun 3, 2011 at 9:28 AM, Ian Hickson i...@hixie.ch wrote:
On Thu, 16
On Thu, Jun 2, 2011 at 7:28 PM, Ian Hickson i...@hixie.ch wrote:
We can add comments pretty easily (e.g. we could say that ! starts a
comment and ends it -- that's already being ignored by the current
parser), if people really need them. But are comments really that useful?
Did SRT have
On Mon, 16 May 2011 17:59:43 +0200, Remy Sharp r...@leftlogic.com wrote:
Hi all,
Since this is *my* code that we're talking specifically about, I'd like
to repeat Glenn's point that this is not sloppy code (the cheeky shit),
and that the /everyman/ developer is going to think that
On 17 May 2011, at 09:04, Philip Jägenstedt wrote:
Or do you mean a spec bug?
I meant a spec bug :)
On Tue, 17 May 2011 10:47:02 +0200, Remy Sharp r...@leftlogic.com wrote:
On 17 May 2011, at 09:04, Philip Jägenstedt wrote:
Or do you mean a spec bug?
I meant a spec bug :)
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12664
Still, I don't think just advocacy is any kind of solution.
On Tue, May 17, 2011 at 5:09 AM, Philip Jägenstedt phil...@opera.comwrote:
To target this specific pattern, one hypothetical solution would be to
special-case the first script that attaches event handlers to a video
element. After it has run, all events that were already fired before the
On Tue, May 17, 2011 at 9:09 PM, Philip Jägenstedt phil...@opera.comwrote:
To target this specific pattern, one hypothetical solution would be to
special-case the first script that attaches event handlers to a video
element. After it has run, all events that were already fired before the
On Wed, May 18, 2011 at 7:09 AM, Robert O'Callahan rob...@ocallahan.orgwrote:
Sure! For certain kinds of events (load, the video events, maybe more),
delay the firing of such events until, say, after DOMContentLoaded has
fired. If you're careful you might be able to make this a strict subset
On Sun, 15 May 2011 19:11:09 +0200, Glenn Maynard gl...@zewt.org wrote:
On Sat, May 14, 2011 at 11:49 AM, Eric Carlson
eric.carl...@apple.comwrote:
It seems to me that the right way to fix the problem is let people
know
it is sloppy code, not to figure out a way to work around it.
The
Hi all,
Since this is *my* code that we're talking specifically about, I'd like to
repeat Glenn's point that this is not sloppy code (the cheeky shit), and that
the /everyman/ developer is going to think that attaching an event is perfectly
legal and will expect it to work.
Now you're right,
On Mon, May 16, 2011 at 3:20 AM, Simon Pieters sim...@opera.com wrote:
The state can have changed before the event has actually fired, since
state changes are sync but the events are queued. So if the script happens
to run in between then func is run twice. See
On Sat, May 14, 2011 at 11:49 AM, Eric Carlson eric.carl...@apple.comwrote:
It seems to me that the right way to fix the problem is let people know
it is sloppy code, not to figure out a way to work around it.
The basic problem is that it isn't sloppy code: it's correct for almost all
On May 13, 2011, at 4:35 AM, Philip Jägenstedt wrote:
I wasn't asking how to work around the problem once you know it exists, I was
wondering if any browser vendors have done anything to make this problem less
likely to happen on pages like http://html5demos.com/video that don't do the
On 05/15/2011 01:24 AM, Ojan Vafai wrote:
It's unfortunate that you need to use an inline event handler instead of one
registered via addEventListener to avoid the race condition. Exposing
something to the platform like jquery's live event handlers (
http://api.jquery.com/live/) could mitigate
On Fri, 13 May 2011 12:25:39 +0200, Henri Sivonen hsivo...@iki.fi wrote:
On Fri, 2011-05-13 at 11:40 +0200, Philip Jägenstedt wrote:
Problem:
video src=video.webm/video
...
script
document.querySelector('video').oncanplay = function() {
/* will it run? */
};
/script
In the above the
On May 13, 2011, at 4:35 , Philip Jägenstedt wrote:
I wasn't asking how to work around the problem once you know it exists, I was
wondering if any browser vendors have done anything to make this problem less
likely to happen on pages like http://html5demos.com/video that don't do the
Hi,
This is regarding the recently added audioTracks and videoTracks APIs
to the HTMLMediaElement.
The design of these APIs seems to be done a little strangely, in that
dealing with each track is done by passing an index to each method on
the TrackList interfaces, rather than treating the
On Fri, 10 Dec 2010 01:43:27 +0100, Kevin Carle kca...@google.com wrote:
The use case under discussion is changing to another video. So the
element
is already inserted and already has src.
Something like:
video controls autoplay
source src=video1.webm type=video/webm
source src=video1.mp4
On Fri, 10 Sep 2010, Biju wrote:
Matthew Gregan wrote in
https://bugzilla.mozilla.org/show_bug.cgi?id=571822 :
Firefox fires the timeupdate event once per frame. Safari 5 and Chrome
6 fire every 250ms. Opera 10.50 fires every 200ms.
Now in firefox bug 571822 they are changing Firefox
On Thu, Dec 9, 2010 at 1:42 AM, Simon Pieters sim...@opera.com wrote:
On Thu, 09 Dec 2010 02:58:12 +0100, Ian Hickson i...@hixie.ch wrote:
On Wed, 1 Sep 2010, Simon Pieters wrote:
I think it might be good to run the media element load algorithm when
setting or changing src on source (that
On Tue, 3 Aug 2010, Boris Zbarsky wrote:
On 8/2/10 5:20 PM, Ian Hickson wrote:
Or does stop the currently running task in #spin-the-event-loop
imply a jump to step 2 of the algorithm under #processing-model2?
Yes.
OK, that might be worth clarifying.
Done.
(Note: I still have
On Mon, 26 Jul 2010, Silvia Pfeiffer wrote:
I now wonder about the intention of play() (and also of pause()). As
I understood it, they are both meant to reload the media resource if
@currentSrc has changed, similar to what load() is supposed to do.
I do not believe that has ever
Long story short: I haven't changed the spec where it talks about video,
source type, Content-Type, and direct file inspection for type
determination. My plan is to just wait and see what browsers do and update
the spec accordingly in due course. This is mostly because we clearly have
a wide
On Wed, 1 Sep 2010, Simon Pieters wrote:
I think it might be good to run the media element load algorithm when
setting or changing src on source (that has a media element as its
parent), but not type and media (what's the use case for type and
media?). However it would fire an 'emptied'
On 12/8/10 8:19 PM, Ian Hickson wrote:
You can't sniff in a toplevel browser window. Not the same way that
people are sniffing invideo. It would break the web.
How so?
People actually rely on the not-sniffing behavior of UAs in actual
browser windows in some cases. For example,
2010-09-13 16:44 EEST: Roger Hågensen:
On 2010-09-13 15:03, Mikko Rantalainen wrote:
And why do we need this? Because web servers are not behaving correctly
and are sending incorrect Content-Type headers? What makes you believe
that BINID will not be incorrectly used?
Because if they add a
On 2010-09-16 15:17, Mikko Rantalainen wrote:
2010-09-13 16:44 EEST: Roger Hågensen:
On 2010-09-13 15:03, Mikko Rantalainen wrote:
And why do we need this? Because web servers are not behaving correctly
and are sending incorrect Content-Type headers? What makes you believe
that BINID will
On 13.09.2010 23:51, Aryeh Gregor wrote:
...
And for heavens sake, do not specify any sniffing as official.
Instead, explicitly specify all sniffing as UA specific and possibly
suggest that UAs should inform the user that content is broken and the
current rendering is best effort if any
On 2010-09-13 15:55, Nils Dagsson Moskopp wrote:
Mikko Rantalainenmikko.rantalai...@peda.net schrieb am Mon, 13 Sep
2010 16:03:27 +0300:
[…]
Basically, this sounds like all the issues of BOM for all binary
files.
And why do we need this? Because web servers are not behaving
correctly and
On 2010-09-14 08:37, Julian Reschke wrote:
On 13.09.2010 23:51, Aryeh Gregor wrote:
...
And for heavens sake, do not specify any sniffing as official.
Instead, explicitly specify all sniffing as UA specific and possibly
suggest that UAs should inform the user that content is broken and the
2010-09-11 01:51 EEST: Roger Hågensen:
On 2010-09-09 09:24, Philip Jägenstedt wrote:
For at least WAVE, Ogg and WebM it's not possible as they begin with
different magic bytes.
Then why not define a new magic that is universal, so that if a proper
content type is not stated then a sniffing
On 2010-09-13 15:03, Mikko Rantalainen wrote:
2010-09-11 01:51 EEST: Roger Hågensen:
On 2010-09-09 09:24, Philip Jägenstedt wrote:
For at least WAVE, Ogg and WebM it's not possible as they begin with
different magic bytes.
Then why not define a new magic that is universal, so that if a
Mikko Rantalainen mikko.rantalai...@peda.net schrieb am Mon, 13 Sep
2010 16:03:27 +0300:
[…]
Basically, this sounds like all the issues of BOM for all binary
files.
And why do we need this? Because web servers are not behaving
correctly and are sending incorrect Content-Type headers? What
On Mon, Sep 13, 2010 at 9:03 AM, Mikko Rantalainen
mikko.rantalai...@peda.net wrote:
For any other value of Content-Type, honor the type specified in HTTP
level. And provide no overrides of any kind on any level above the HTTP.
Levels above HTTP may provide HINTS about the content that can be
On 9/11/10 8:56 AM, Roger Hågensen wrote:
I can't recall any browsers exposing vsync. (does any?)
Gecko is working on it. See
http://weblogs.mozillazine.org/roc/archives/2010/08/mozrequestanima.html
-Boris
On Sat, Sep 11, 2010 at 2:20 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
On Sat, Sep 11, 2010 at 11:03 AM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Fri, Sep 10, 2010 at 4:01 PM, Robert O'Callahan rob...@ocallahan.org
wrote:
I think an ideal API for video frame processing would
On 2010-09-11 03:40, Silvia Pfeiffer wrote:
[snip...]
And yeah, this kinda stretched beyond the scope of HTML5 specs,
but you'd be swatting two flies at once, solving the sniffing
issue with video and audio, but also the sniffing issue that
every OS has had for the last couple
On 2010-09-11 05:23, Eric Carlson wrote:
On Sep 10, 2010, at 8:06 PM, Biju wrote:
On Fri, Sep 10, 2010 at 7:05 AM, Silvia Pfeiffer
silviapfeiff...@gmail.com wrote:
Incidentally: What use case did you have in mind, Biju ?
I was thinking about applications like
https://bugzilla.mozilla.org/show_bug.cgi?id=571822
Firefox fires the timeupdate event once per frame.
Safari 5 and Chrome 6 fire every 250ms. Opera 10.50 fires every 200ms.
Now in firefox bug 571822 they are changing Firefox fires the
timeupdate event at every 250ms
But this takes away
On Fri, Sep 10, 2010 at 7:28 PM, Biju bijumaill...@gmail.com wrote:
https://bugzilla.mozilla.org/show_bug.cgi?id=571822
Firefox fires the timeupdate event once per frame.
Safari 5 and Chrome 6 fire every 250ms. Opera 10.50 fires every 200ms.
Now in firefox bug 571822 they are changing
On Fri, Sep 10, 2010 at 4:05 AM, Silvia Pfeiffer
silviapfeiff...@gmail.com wrote:
On Fri, Sep 10, 2010 at 7:28 PM, Biju bijumaill...@gmail.com wrote:
https://bugzilla.mozilla.org/show_bug.cgi?id=571822
Firefox fires the timeupdate event once per frame.
Safari 5 and Chrome 6 fire every
If I understand correctly... I think we would be using this a lot in
transmedia integration for film/tv.
On Fri, Sep 10, 2010 at 10:53 AM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Fri, Sep 10, 2010 at 4:05 AM, Silvia Pfeiffer
silviapfeiff...@gmail.com wrote:
On Fri, Sep 10, 2010 at 7:28
On 9/10/10 10:53 AM, Tab Atkins Jr. wrote:
I don't know how audio would be returned, though.
Mozilla is using a typed array buffer holding 32-bit floats for its
audio data API stuff, I believe.
-Boris
On Sep 10, 2010, at 7:53 AM, Tab Atkins Jr. wrote:
On Fri, Sep 10, 2010 at 4:05 AM, Silvia Pfeiffer
silviapfeiff...@gmail.com wrote:
On Fri, Sep 10, 2010 at 7:28 PM, Biju bijumaill...@gmail.com wrote:
https://bugzilla.mozilla.org/show_bug.cgi?id=571822
Firefox fires the timeupdate event
On Fri, Sep 10, 2010 at 9:58 AM, Simon Fraser s...@me.com wrote:
The problem with a 'newFrame' callback is what to do if the callback
takes longer than the duration of a single frame. Does the video engine
start dropping frames, or does the video lag?
Dropping frames would be the better
On Sep 10, 2010, at 10:07 AM, Tab Atkins Jr. wrote:
On Fri, Sep 10, 2010 at 9:58 AM, Simon Fraser s...@me.com wrote:
The problem with a 'newFrame' callback is what to do if the callback
takes longer than the duration of a single frame. Does the video engine
start dropping frames, or does the
On 2010-09-09 09:24, Philip Jägenstedt wrote:
On Thu, 09 Sep 2010 02:15:27 +0200, David Singer sin...@apple.com
wrote:
On Wed, Sep 8, 2010 at 3:13 PM, And Clover and...@doxdesk.com wrote:
Perhaps I *meant* to serve a non-video
file with something that looks a fingerprint from a video format
I think an ideal API for video frame processing would involve handing video
frames to a Worker for processing.
Rob
--
Now the Bereans were of more noble character than the Thessalonians, for
they received the message with great eagerness and examined the Scriptures
every day to see if what Paul
On Fri, Sep 10, 2010 at 4:01 PM, Robert O'Callahan rob...@ocallahan.org wrote:
I think an ideal API for video frame processing would involve handing video
frames to a Worker for processing.
Mm, yeah, probably. But then you'd need to be able to do canvas on
workers, and hand the data back...
On Sat, Sep 11, 2010 at 12:53 AM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Fri, Sep 10, 2010 at 4:05 AM, Silvia Pfeiffer
silviapfeiff...@gmail.com wrote:
On Fri, Sep 10, 2010 at 7:28 PM, Biju bijumaill...@gmail.com wrote:
https://bugzilla.mozilla.org/show_bug.cgi?id=571822
Firefox
On Sat, Sep 11, 2010 at 8:51 AM, Roger Hågensen resca...@emsai.net wrote:
On 2010-09-09 09:24, Philip Jägenstedt wrote:
On Thu, 09 Sep 2010 02:15:27 +0200, David Singer sin...@apple.com
wrote:
On Wed, Sep 8, 2010 at 3:13 PM, And Clover and...@doxdesk.com wrote:
Perhaps I *meant* to
On Fri, Sep 10, 2010 at 7:05 AM, Silvia Pfeiffer
silviapfeiff...@gmail.com wrote:
Incidentally: What use case did you have in mind, Biju ?
I was thinking about applications like
https://developer.mozilla.org/samples/video/chroma-key/index.xhtml
(
On Sep 10, 2010, at 8:06 PM, Biju wrote:
On Fri, Sep 10, 2010 at 7:05 AM, Silvia Pfeiffer
silviapfeiff...@gmail.com wrote:
Incidentally: What use case did you have in mind, Biju ?
I was thinking about applications like
https://developer.mozilla.org/samples/video/chroma-key/index.xhtml
(
On Sat, Sep 11, 2010 at 11:03 AM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Fri, Sep 10, 2010 at 4:01 PM, Robert O'Callahan rob...@ocallahan.org
wrote:
I think an ideal API for video frame processing would involve handing
video
frames to a Worker for processing.
Mm, yeah, probably.
I think we should always sniff or never sniff, for simplicity.
Philip
On Wed, 08 Sep 2010 19:14:48 +0200, David Singer sin...@apple.com wrote:
what about don't sniff if the HTML gave you a mime type (i.e. a source
element with a type attribute), or at least don't sniff for the
purposes of
I can't think why always sniffing is simple, or cheap, or desirable. I'd love
to get to never-sniff, but am not sanguine.
On Sep 9, 2010, at 0:07 , Philip Jägenstedt wrote:
I think we should always sniff or never sniff, for simplicity.
Philip
On Wed, 08 Sep 2010 19:14:48 +0200, David
Much of this discussion has focused on the careless server operator. What
about the careful ones?
Given the past history of content sniffing and security warts, it is useful
- or at least comforting - to have a path for the careful server to indicate
I know this file really is intended to be
On Sep 9, 2010, at 16:38 , Andy Berkheimer wrote:
Much of this discussion has focused on the careless server operator. What
about the careful ones?
Given the past history of content sniffing and security warts, it is useful -
or at least comforting - to have a path for the careful
On Tue, 07 Sep 2010 22:00:55 +0200, Boris Zbarsky bzbar...@mit.edu wrote:
On 9/7/10 3:29 PM, Aryeh Gregor wrote:
* Sniff only if Content-Type is typical of what popular browsers serve
for unrecognized filetypes. E.g., only for no Content-Type,
text/plain, or application/octet-stream, and only
On 07.09.2010 22:00, Boris Zbarsky wrote:
...
* If a file in a top-level browsing context is sniffed as video but
then some kind of error is returned before the video plays the first
frame, fall back to allowing the user to download it, or whatever the
usual action would be if no sniffing had
what about don't sniff if the HTML gave you a mime type (i.e. a source
element with a type attribute), or at least don't sniff for the purposes of
determining CanPlay, dispatch, if the HTML source gave you a mime type?
On Sep 8, 2010, at 2:33 , Philip Jägenstedt wrote:
On Tue, 07 Sep 2010
On 9/8/10 11:05 AM, Julian Reschke wrote:
It's not that hard if it's acceptable to restart the network request
(just do it again, with a flag not-to-sniff).
It's common enough to not be ok to restart, though. And even the
restart behavior can be pretty complicated, since it requires not just
On 09/07/2010 09:29 PM, Aryeh Gregor wrote:
I'm not a fan of sniffing, but I'm also not a fan of blindly believing
clearly wrong MIME types
Who decides what is clearly wrong? Perhaps I *meant* to serve a
non-video file with something that looks a fingerprint from a video
format at the top.
On Tue, Sep 7, 2010 at 4:00 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 9/7/10 3:29 PM, Aryeh Gregor wrote:
* Sniff only if Content-Type is typical of what popular browsers serve
for unrecognized filetypes. E.g., only for no Content-Type,
text/plain, or application/octet-stream, and only if
On 9/8/10 3:58 PM, Aryeh Gregor wrote:
And the problem is that you don't want to keep the data handy in case
it fails?
Yes. The problem is that I don't want to have to buffer up
potentially-arbitrary amounts of data.
Yes. Undocumented sniffing behaviour has caused many vulnerabilities, as
On Sep 8, 2010, at 12:58 , Aryeh Gregor wrote:
On Wed, Sep 8, 2010 at 1:14 PM, David Singer sin...@apple.com wrote:
what about don't sniff if the HTML gave you a mime type (i.e. a source
element with a type attribute), or at least don't sniff for the purposes of
determining CanPlay,
On Tue, 07 Sep 2010 02:46:29 +0200, Gregory Maxwell gmaxw...@gmail.com
wrote:
On Mon, Sep 6, 2010 at 3:19 PM, Aryeh Gregor simetrical+...@gmail.com
wrote:
On Mon, Sep 6, 2010 at 4:14 AM, Philip Jägenstedt phil...@opera.com
wrote:
The Ogg page begins with the 4 bytes OggS, which is what
On Tue, 07 Sep 2010 03:56:54 +0200, Boris Zbarsky bzbar...@mit.edu wrote:
On 9/6/10 3:19 PM, Aryeh Gregor wrote:
On Mon, Sep 6, 2010 at 4:14 AM, Philip Jägenstedtphil...@opera.com
wrote:
The Ogg page begins with the 4 bytes OggS, which is what Opera
(GStreamer)
checks for. For additional
On 09/07/2010 03:56 AM, Boris Zbarsky wrote:
P.S. Sniffing is harder that you seem to think. It really is...
Quite. It surprises and saddens me that anyone wants to argue for *more*
sniffing, and even enshrining it in a web standard.
Sniffing is a perpetual disaster that, after several
On 07.09.2010 11:51, And Clover wrote:
On 09/07/2010 03:56 AM, Boris Zbarsky wrote:
P.S. Sniffing is harder that you seem to think. It really is...
Quite. It surprises and saddens me that anyone wants to argue for *more*
sniffing, and even enshrining it in a web standard.
+1
Sniffing is
On Tue, 07 Sep 2010 11:51:55 +0200, And Clover and...@doxdesk.com wrote:
On 09/07/2010 03:56 AM, Boris Zbarsky wrote:
P.S. Sniffing is harder that you seem to think. It really is...
Quite. It surprises and saddens me that anyone wants to argue for *more*
sniffing, and even enshrining it
On 07.09.2010 12:52, Philip Jägenstedt wrote:
...
IE9, Safari and Chrome ignore Content-Type in a video context and rely
on sniffing. If you want Content-Type to be respected, convince the
developers of those 3 browsers to change. If not, it's quite inevitable
that Opera and Firefox will
On 9/7/10 6:52 AM, Philip Jägenstedt wrote:
It hasn't been explicitly stated, but I assume that the only cases where
sniffing for video formats would be employed would be for missing
Content-Type, text/plain and application/octet-stream.
That's not what at least Aryeh is proposing, no. Also
On 9/7/10 6:01 AM, Julian Reschke wrote:
Hmm, that's what Content-Disposition: attachment is for...
This header is currently ignored in non-toplevel browsing contexts in
web browsers, last I checked.
-Boris
On 9/7/10 4:11 AM, Philip Jägenstedt wrote:
It's garbage in at least UTF-8, Big5 and GBK.
Thanks. I assume that applies to the OggS\0 sequence too, right? I
appreciate the data!
I'm not sure what infrastructure is in place, but perhaps one could
*not* sniff if Content-Type also indicates
On Tue, 07 Sep 2010 14:54:15 +0200, Boris Zbarsky bzbar...@mit.edu wrote:
On 9/7/10 6:52 AM, Philip Jägenstedt wrote:
It hasn't been explicitly stated, but I assume that the only cases where
sniffing for video formats would be employed would be for missing
Content-Type, text/plain and
On 9/7/10 9:03 AM, Philip Jägenstedt wrote:
On Tue, 07 Sep 2010 14:54:15 +0200, Boris Zbarsky bzbar...@mit.edu wrote:
On 9/7/10 6:52 AM, Philip Jägenstedt wrote:
It hasn't been explicitly stated, but I assume that the only cases where
sniffing for video formats would be employed would be for
On Tue, 07 Sep 2010 14:56:38 +0200, Boris Zbarsky bzbar...@mit.edu wrote:
On 9/7/10 4:11 AM, Philip Jägenstedt wrote:
It's garbage in at least UTF-8, Big5 and GBK.
Thanks. I assume that applies to the OggS\0 sequence too, right? I
appreciate the data!
UTF-8, Big5 and GBK are all (as
On 9/7/10 9:16 AM, Philip Jägenstedt wrote:
UTF-8, Big5 and GBK are all (as far as I know) ASCII supersets. Do
real-world text documents include \0 bytes?
Yes. Real-world text documents include all sorts of gunk. Just rarely.
As long as indicates an encoding doesn't include UTF-8 or
On Sep 7, 2010, at 3:52 AM, Philip Jägenstedt wrote:
On Tue, 07 Sep 2010 11:51:55 +0200, And Clover and...@doxdesk.com wrote:
On 09/07/2010 03:56 AM, Boris Zbarsky wrote:
P.S. Sniffing is harder that you seem to think. It really is...
Quite. It surprises and saddens me that anyone
On Sep 7, 2010, at 2:51 , And Clover wrote:
On 09/07/2010 03:56 AM, Boris Zbarsky wrote:
P.S. Sniffing is harder that you seem to think. It really is...
Quite. It surprises and saddens me that anyone wants to argue for *more*
sniffing, and even enshrining it in a web standard.
Yes. We
And like I said before, please be careful of assuming our intent and desires
from the way things currently work. We are thinking, listening, and
implementing (and fixing bugs, and re-inspecting older behavior in lower-level
code), so there is some...flexibility...I think.
On Sep 7, 2010, at
On Tue, Sep 7, 2010 at 3:01 AM, Julian Reschke julian.resc...@gmx.de wrote:
On 07.09.2010 11:51, And Clover wrote:
On 09/07/2010 03:56 AM, Boris Zbarsky wrote:
P.S. Sniffing is harder that you seem to think. It really is...
Quite. It surprises and saddens me that anyone wants to argue for
101 - 200 of 894 matches
Mail list logo
