Re: [whatwg] ArrayBuffer and ByteArray questions
On Wed, 08 Sep 2010 01:09:13 +0200, Jian Li jia...@chromium.org wrote: Several specs, like File API and WebGL, use ArrayBuffer, while other spec, like XMLHttpRequest Level 2, use ByteArray. Should we change to use the same name all across our specs? Since we define ArrayBuffer in the Typed Arrays spec ( https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html), should we favor ArrayBuffer? In addition, can we consider adding ArrayBuffer support to BlobBuilder, FormData, and XMLHttpRequest.send()? So TC39 is going to leave this thing alone? I.e. are we sure ArrayBuffer is the way of the future? -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] The choice of script global object to use when the script element is moved
On Tue, 07 Sep 2010 22:57:27 +0200, Adam Barth w...@adambarth.com wrote: It sounds like CSP is creating sub-origin privileges. Sub-origin privileges don't really work, so it's unclear to what a sensible result would be. This is a problem with your alternative CSP proposal as well, no? https://wiki.mozilla.org/Security/CSP/AllowedScripts It prevents a bunch of things, but when loaded in an iframe someone else on the same-origin can still inject a script of some sorts. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] The choice of script global object to use when the script element is moved
On Wed, Sep 8, 2010 at 2:10 AM, Anne van Kesteren ann...@opera.com wrote: On Tue, 07 Sep 2010 22:57:27 +0200, Adam Barth w...@adambarth.com wrote: It sounds like CSP is creating sub-origin privileges. Sub-origin privileges don't really work, so it's unclear to what a sensible result would be. This is a problem with your alternative CSP proposal as well, no? https://wiki.mozilla.org/Security/CSP/AllowedScripts It prevents a bunch of things, but when loaded in an iframe someone else on the same-origin can still inject a script of some sorts. The goal of AllowedScripts is not to limit a privilege to a subset of an origin. Rather, the goal is to prevent an attacker who can inject markup into a document from executing script. Put another way, if you're already executing script, then it's not trying to withhold any privileges. Adam
Re: [whatwg] The choice of script global object to use when the script element is moved
On Wed, 08 Sep 2010 11:20:30 +0200, Adam Barth w...@adambarth.com wrote: The goal of AllowedScripts is not to limit a privilege to a subset of an origin. Rather, the goal is to prevent an attacker who can inject markup into a document from executing script. Put another way, if you're already executing script, then it's not trying to withhold any privileges. Fair enough. I guess if one page gets compromised all else that is same origin is lost anyway. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Timed tracks: feedback compendium
On Wed, 08 Sep 2010 01:19:17 +0200, Ian Hickson i...@hixie.ch wrote:
On Fri, 23 Jul 2010, Philip Jägenstedt wrote:
http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#attr-track-kind
The distinction between subtitles and captions isn't terribly clear.
It says that subtitles are translations, but plain transcriptions
without cues for the hard of hearing would also be subtitles.
How does one categorize translations that are for the HoH?
I've tried to clarify this.
Thanks, the new definitions look good to me.
Alternatively, might it not be better to simply use the voice sound
for this and let the default stylesheet hide those cues? When writing
subtitles I don't want the maintenance overhead of 2 different versions
that differ only by the inclusion of [doorbell rings] and similar.
Honestly, it's more likely that I just wouldn't bother with
accessibility for the HoH at all. If I could add it with sounddoorbell
rings, it's far more likely I would do that, as long as it isn't
rendered by default. This is my preferred solution, then keeping only
one of kind=subtitles and kind=captions. Enabling the HoH-cues could
then be a global preference in the browser, or done from the context
menu of individual videos.
I don't disagree with this, but I fear it might be too radical a step for
the caption-authoring community to take at this point.
Well, I guess the infrastructure in place is enough to do this by changing
stylesheets.
If we must have both kind=subtitles and kind=captions, then I'd suggest
making the default subtitles, as that is without a doubt the most common
kind of timed text. Making captions the default only means that most
timed text will be mislabeled as being appropriate for the HoH when it
is not.
Ok, I've changed the default. However, I'm not fighting this battle if it
comes up again, and will just change it back if people don't defend
having
this as the default. (And then change it back again if the browsers pick
subtitles in their implementations after all, of course.)
Note that captions aren't just for users that are hard-of-hearing. Most
of
the time when I use timed tracks, I want captions, because the reason I
have them enabled is that I have the sound muted.
OK, thanks!
On Fri, 23 Jul 2010, Sam Dutton wrote:
Is trackgroup out of the spec?
What is trackgroup?
In the discussion on public-html-a11y trackgroup was suggested to group
together mutually exclusive tracks, so that enabling one automatically
disables the others in the same trackgroup.
I guess it's up to the UA how to enable and disable tracks now, but the
only option is making them all mutually exclusive (as existing players do)
or a weird kind of context menu where it's possible to enable and disable
tracks completely independently. Neither options is great, but as a user I
would almost certainly prefer all tracks being mutually exclusive and
requiring scripts to enable several at once.
On Fri, 6 Aug 2010, Philip Jägenstedt wrote:
I'm not particularly fond of the current voice markup, mainly for 2
reasons:
First, a cue can only have 1 voice, which makes it impossible to style
cues spoken/sung simultaneously by 2 or more voices. There's a karaoke
example of this in
http://wiki.whatwg.org/wiki/Use_cases_for_timed_tracks_rendered_over_video_by_the_UA#Multiple_voices
That's just two cues.
I'm not sure what you're saying. The male singer's cues are in blue, the
female singer's are in red and the part sung together is in green. Are you
saying that the last cue should be made into two cues, or something else?
I would prefer if voices could be mixed, as such:
00:01.000 -- 00:02.000
1 Speaker 1
00:03.000 -- 00:04.000
2 Speaker 2
00:05.000 -- 00:06.000
12 Speaker 1+2
What's the use case?
To use a different style for the cues that are sung together, so that you
know when it's your turn to sing. I hope we can throw away the numerical
voices, continued below...
Second, it makes it impossible to target a smaller part of the cue for
styling. We have i and b, but there are also cases where part of the
cue should be in a different color, see
http://wiki.whatwg.org/wiki/Use_cases_for_timed_tracks_rendered_over_video_by_the_UA#Multiple_colors
Well you can always restyle i or b.
That would be quite an abuse of i and b and would give bogus
italics/bold text in standalone players.
If one allows multiple voices, it's not hard to predict that people will
start using magic numbers just to work around this, which would both be
wrong semantically and ugly to look at:
00:01.000 -- 00:02.000
1 I like 1234blue/1234 words.
They'd then target 1234 with CSS to color it blue.
I'm not sure of the best solution. I'd quite like the ability to use
arbitrary voices, e.g. to use the names/initials of the speaker rather
than a number, or to use e.g. shouting in combination with CSS :before
{ content 'Shouting: ' } or similar to adapt the display for different
Re: [whatwg] Video with MIME type application/octet-stream
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 if the encoding is either not present or is UTF-8 or ISO-8859-1. Or whatever web servers do here. * Sniff the same both for video tags and top-level browsing contexts, so open video in new tab doesn't mysteriously fail on some setups. I could probably live with those, actually. * 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 occurred. This might be pretty difficult to implement, since the video decoder might consume arbitrary amounts of data before saying that there was an error. I agree with Boris, the first two points are OK but the third I'd rather not implement, it's too much work for something that ought to happen very, very rarely. -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] Timed tracks: feedback compendium
On Wed, Sep 8, 2010 at 2:27 AM, Philip Jägenstedt phil...@opera.com wrote: On Wed, 08 Sep 2010 01:19:17 +0200, Ian Hickson i...@hixie.ch wrote: We could say that a custom voice has to start with some punctuation or other, say :philip? Yes, that would be better than numerical voices IMO. Unless there's a very good reason for making voices always apply to the whole cue, could we not use the same parsing for voices and other tags (i, b, ruby, rt)? Ideally, the CSS extensions (http://wiki.whatwg.org/wiki/Timed_tracks#CSS_extensions) should also work the same for voices and tags, using the normal child selectors would work. Something like video::cue(narrator i) to style the following cue: 00:01.000 -- 00:02.000 narratoriThe story begins I'm not sure what constraints CSS syntax puts on the prefix for custom voices, is : safe? Other options might be @philip (Twitter style) or -philip (vendor prefix style). A token preceded by a : is just treated as a pseudoclass by the grammar. That's not necessarily a bad thing, though. I believe - should be just fine. @ would be too. ~TJ
Re: [whatwg] Video with MIME type application/octet-stream
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 occurred. This might be pretty difficult to implement, since the video decoder might consume arbitrary amounts of data before saying that there was an error. ... It's not that hard if it's acceptable to restart the network request (just do it again, with a flag not-to-sniff). Best regards, Julian
Re: [whatwg] ArrayBuffer and ByteArray questions
On Sep 8, 2010, at 12:13 AM, Anne van Kesteren wrote: On Wed, 08 Sep 2010 01:09:13 +0200, Jian Li jia...@chromium.org wrote: Several specs, like File API and WebGL, use ArrayBuffer, while other spec, like XMLHttpRequest Level 2, use ByteArray. Should we change to use the same name all across our specs? Since we define ArrayBuffer in the Typed Arrays spec ( https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html), should we favor ArrayBuffer? In addition, can we consider adding ArrayBuffer support to BlobBuilder, FormData, and XMLHttpRequest.send()? So TC39 is going to leave this thing alone? I.e. are we sure ArrayBuffer is the way of the future? ArrayBuffer certainly has momentum behind it. It started as a part of the WebGL spec as a way of passing buffers of data of various types (sometimes heterogeneous types) to the WebGL engine. Since then, it has found uses in the Web Audio proposal, the File API and there has been talk in using it as a way to pass data to Web Workers. We have discussed using it in XHR as well, and I think that would be a great idea. From a WebGL standpoint, it is the one missing piece to make it possible to easily get data of any type from a URL into the WebGL engine. But it would have uses in many other places as well. For reference, here is the latest proposal: https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html - ~Chris cmar...@apple.com
Re: [whatwg] ArrayBuffer and ByteArray questions
On Wed, 08 Sep 2010 17:22:44 +0200, Chris Marrin cmar...@apple.com wrote: On Sep 8, 2010, at 12:13 AM, Anne van Kesteren wrote: On Wed, 08 Sep 2010 01:09:13 +0200, Jian Li jia...@chromium.org wrote: Several specs, like File API and WebGL, use ArrayBuffer, while other spec, like XMLHttpRequest Level 2, use ByteArray. Should we change to use the same name all across our specs? Since we define ArrayBuffer in the Typed Arrays spec ( https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html), should we favor ArrayBuffer? In addition, can we consider adding ArrayBuffer support to BlobBuilder, FormData, and XMLHttpRequest.send()? So TC39 is going to leave this thing alone? I.e. are we sure ArrayBuffer is the way of the future? ArrayBuffer certainly has momentum behind it. It started as a part of the WebGL spec as a way of passing buffers of data of various types (sometimes heterogeneous types) to the WebGL engine. Since then, it has found uses in the Web Audio proposal, the File API and there has been talk in using it as a way to pass data to Web Workers. Do you mean WebSockets? We have discussed using it in XHR as well, and I think that would be a great idea. From a WebGL standpoint, it is the one missing piece to make it possible to easily get data of any type from a URL into the WebGL engine. But it would have uses in many other places as well. For reference, here is the latest proposal: https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html - ~Chris cmar...@apple.com -- Simon Pieters Opera Software
Re: [whatwg] Canvas API: What should happen if non-finite floats are used
The problem with throwing an exception is that it's fairly common for code to
end up accidentally producing a NaN or Infinite value, and throwing an
exception would prevent all subsequent drawing from occurring.
I suggested this behaviour a long time ago after running into yet another piece
of code that hit this case in webkit (back when the spec said to throw an
exception) yet firefox and opera did not throw. In some cases firefox does
throw, and in others it doesn't (or maybe didn't? has ffx behaviour changed?)
and we came to the conclusion that as much as possible the canvas should
silently ignore NaN/Infinite values.
--Oliver
On Sep 7, 2010, at 10:36 PM, Jonas Sicking wrote:
This seems like a strange choice of behavior. Given that this is very
likely a bug in the program, wouldn't it make more sense to throw an
exception as to make it easier to debug? Similar to for example
Node.appendChild when called with a null argument.
/ Jonas
On Tue, Sep 7, 2010 at 10:32 PM, Sam Weinig wei...@apple.com wrote:
In 4.8.11.1 the spec does state:
Except where otherwise specified, for the 2D context interface, any method
call with a numeric argument whose value is infinite or a NaN value must be
ignored.
-Sam
On Sep 7, 2010, at 9:41 PM, Boris Zbarsky wrote:
Consider this testcase:
!doctype html
html
body
canvas id=c width=200 height=200/canvas
script
try {
var c = document.getElementById(c),
t = c.getContext(2d);
t.moveTo(100, 100);
t.lineTo(NaN, NaN);
t.lineTo(50, 25);
t.stroke();
} catch (e) {alert(e); }
/script
/body
/html
Behavior in the spec seems to be undefined (in particular, no mention is
made as to what the canvas API functions are supposed to do if non-finite
values are passed in). Behavior in browsers is:
Presto: Throws NOT_SUPPORTED_ERR on that lineTo(NaN, NaN) call.
Gecko: Throws DOM_SYNTAX_ERR on that lineTo(NaN, NaN) call.
Webkit: Silently ignores the lineTo(NaN, NaN) call, and then
draws a line from (100,100) to (50, 25).
Seems like the spec needs to define this.
-Boris
P.S. This isn't a hypothetical issue; this came up in a page that was
trying to graph things using canvas and ending up with divide-by-0 all over
the place. It worked in webkit (though not drawing the right thing, so
much). It failed to draw anything in Presto or Gecko.
Re: [whatwg] The choice of script global object to use when the script element is moved
On Wed, Sep 8, 2010 at 2:24 AM, Anne van Kesteren ann...@opera.com wrote: On Wed, 08 Sep 2010 11:20:30 +0200, Adam Barth w...@adambarth.com wrote: The goal of AllowedScripts is not to limit a privilege to a subset of an origin. Rather, the goal is to prevent an attacker who can inject markup into a document from executing script. Put another way, if you're already executing script, then it's not trying to withhold any privileges. Fair enough. I guess if one page gets compromised all else that is same origin is lost anyway. As I understand it, this is the general design thinking for CSP too. Additionally, the recommended best practices is to use the same CSP policies for all urls in a domain, which also avoids the discussed attack. / Jonas
[whatwg] Differences between HTML5 Drafts
I want to know the differences between these HTML5 drafts( I don't want to know more details about the differences, and just want to know the major changes), Could someone know where to find such Information? Thanks
Re: [whatwg] Video with MIME type application/octet-stream
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 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 if the encoding is either not present or is UTF-8 or ISO-8859-1. Or whatever web servers do here. * Sniff the same both for video tags and top-level browsing contexts, so open video in new tab doesn't mysteriously fail on some setups. I could probably live with those, actually. * 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 occurred. This might be pretty difficult to implement, since the video decoder might consume arbitrary amounts of data before saying that there was an error. I agree with Boris, the first two points are OK but the third I'd rather not implement, it's too much work for something that ought to happen very, very rarely. -- Philip Jägenstedt Core Developer Opera Software David Singer Multimedia and Software Standards, Apple Inc.
Re: [whatwg] Differences between HTML5 Drafts
On Wed, Sep 8, 2010 at 10:11 AM, zhao Matt mattzhao...@gmail.com wrote: I want to know the differences between these HTML5 drafts( I don't want to know more details about the differences, and just want to know the major changes), Could someone know where to find such Information? Which drafts do you mean? The WHATWG and W3C versions? Or something else? ~TJ
Re: [whatwg] Canvas API: What should happen if non-finite floats are used
On Wed, Sep 8, 2010 at 9:45 AM, Oliver Hunt oli...@apple.com wrote:
The problem with throwing an exception is that it's fairly common for code to
end up accidentally producing a NaN or Infinite value, and throwing an
exception would prevent all subsequent drawing from occurring.
I believe that was the point: you throw an exception, the bug becomes
obvious, and you fix it. Without the exception, you draw the wrong
thing, and it's much harder to find the problem.
I suggested this behaviour a long time ago after running into yet another
piece of code that hit this case in webkit (back when the spec said to throw
an exception) yet firefox and opera did not throw. In some cases firefox
does throw, and in others it doesn't (or maybe didn't? has ffx behaviour
changed?) and we came to the conclusion that as much as possible the canvas
should silently ignore NaN/Infinite values.
--Oliver
On Sep 7, 2010, at 10:36 PM, Jonas Sicking wrote:
This seems like a strange choice of behavior. Given that this is very
likely a bug in the program, wouldn't it make more sense to throw an
exception as to make it easier to debug? Similar to for example
Node.appendChild when called with a null argument.
/ Jonas
On Tue, Sep 7, 2010 at 10:32 PM, Sam Weinig wei...@apple.com wrote:
In 4.8.11.1 the spec does state:
Except where otherwise specified, for the 2D context interface, any method
call with a numeric argument whose value is infinite or a NaN value must be
ignored.
-Sam
On Sep 7, 2010, at 9:41 PM, Boris Zbarsky wrote:
Consider this testcase:
!doctype html
html
body
canvas id=c width=200 height=200/canvas
script
try {
var c = document.getElementById(c),
t = c.getContext(2d);
t.moveTo(100, 100);
t.lineTo(NaN, NaN);
t.lineTo(50, 25);
t.stroke();
} catch (e) {alert(e); }
/script
/body
/html
Behavior in the spec seems to be undefined (in particular, no mention is
made as to what the canvas API functions are supposed to do if non-finite
values are passed in). Behavior in browsers is:
Presto: Throws NOT_SUPPORTED_ERR on that lineTo(NaN, NaN) call.
Gecko: Throws DOM_SYNTAX_ERR on that lineTo(NaN, NaN) call.
Webkit: Silently ignores the lineTo(NaN, NaN) call, and then
draws a line from (100,100) to (50, 25).
Seems like the spec needs to define this.
-Boris
P.S. This isn't a hypothetical issue; this came up in a page that was
trying to graph things using canvas and ending up with divide-by-0 all
over the place. It worked in webkit (though not drawing the right
thing, so much). It failed to draw anything in Presto or Gecko.
Re: [whatwg] Differences between HTML5 Drafts
WHATWG version. thanks On Thu, Sep 9, 2010 at 1:19 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Sep 8, 2010 at 10:11 AM, zhao Matt mattzhao...@gmail.com wrote: I want to know the differences between these HTML5 drafts( I don't want to know more details about the differences, and just want to know the major changes), Could someone know where to find such Information? Which drafts do you mean? The WHATWG and W3C versions? Or something else? ~TJ
Re: [whatwg] Canvas API: What should happen if non-finite floats are used
On Sep 8, 2010, at 10:20 AM, Eric Uhrhane wrote: On Wed, Sep 8, 2010 at 9:45 AM, Oliver Hunt oli...@apple.com wrote: The problem with throwing an exception is that it's fairly common for code to end up accidentally producing a NaN or Infinite value, and throwing an exception would prevent all subsequent drawing from occurring. I believe that was the point: you throw an exception, the bug becomes obvious, and you fix it. Without the exception, you draw the wrong thing, and it's much harder to find the problem. In a lot of cases all you want to do is ignore NaN and Infinite values, otherwise you basically have to prepend every call to canvas with NaN and Infinity checks if you're computing values unless you can absolutely guarantee your values won't have gone nuts at any point in the computation -- otherwise you're going to get reports that occasionally your content breaks but with no repro case (typical users will not be seeing error messages, it just doesn't work). Additionally there is content that depends on the non-throwing behaviour, in webkit we had to drop the exceptions that we threw due to content that worked in firefox because of the absence of exceptions. In the ended we spec'd these values as being ignored so that there was some degree of consistency through the API (and because the various UAs that support canvas would through on non-finite values in differing functions). --Oliver
Re: [whatwg] Differences between HTML5 Drafts
http://html5.org/tools/web-apps-tracker shows recent changes (with diffs). Mihai On Wed, Sep 8, 2010 at 10:31 AM, zhao Matt mattzhao...@gmail.com wrote: WHATWG version. thanks On Thu, Sep 9, 2010 at 1:19 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Sep 8, 2010 at 10:11 AM, zhao Matt mattzhao...@gmail.com wrote: I want to know the differences between these HTML5 drafts( I don't want to know more details about the differences, and just want to know the major changes), Could someone know where to find such Information? Which drafts do you mean? The WHATWG and W3C versions? Or something else? ~TJ
Re: [whatwg] Differences between HTML5 Drafts
Also, I found a W3C draft's publication notes at http://www.w3.org/TR/2008/NOTE-html5-pubnotes-20080610/. However, I can't find other draft's publication notes. On Thu, Sep 9, 2010 at 1:31 AM, zhao Matt mattzhao...@gmail.com wrote: WHATWG version. thanks On Thu, Sep 9, 2010 at 1:19 AM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Wed, Sep 8, 2010 at 10:11 AM, zhao Matt mattzhao...@gmail.com wrote: I want to know the differences between these HTML5 drafts( I don't want to know more details about the differences, and just want to know the major changes), Could someone know where to find such Information? Which drafts do you mean? The WHATWG and W3C versions? Or something else? ~TJ
Re: [whatwg] Differences between HTML5 Drafts
On Wed, 08 Sep 2010 19:39:18 +0200, zhao Matt mattzhao...@gmail.com wrote: Also, I found a W3C draft's publication notes at http://www.w3.org/TR/2008/NOTE-html5-pubnotes-20080610/. However, I can't find other draft's publication notes. I think pubnotes haven't been written for other drafts since it was too much work. However, there's http://www.w3.org/TR/html5-diff/#changelog -- Simon Pieters Opera Software
Re: [whatwg] ArrayBuffer and ByteArray questions
On Tue, Sep 7, 2010 at 4:09 PM, Jian Li jia...@chromium.org wrote: Hi, Several specs, like File API and WebGL, use ArrayBuffer, while other spec, like XMLHttpRequest Level 2, use ByteArray. Should we change to use the same name all across our specs? Since we define ArrayBuffer in the Typed Arrays spec (https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html), should we favor ArrayBuffer? In addition, can we consider adding ArrayBuffer support to BlobBuilder, FormData, and XMLHttpRequest.send()? It seems like an obvious addition for BlobBuilder or XHR.send, but do we need it in both, or is one sufficient? Thanks, Jian
Re: [whatwg] Canvas API: What should happen if non-finite floats are used
On 9/8/10 12:45 PM, Oliver Hunt wrote: I suggested this behaviour a long time ago after running into yet another piece of code that hit this case in webkit (back when the spec said to throw an exception) yet firefox and opera did not throw. In some cases firefox does throw, and in others it doesn't (or maybe didn't? has ffx behaviour changed?) Gecko behavior for lineTo and most other canvas methods I see has been to throw since late 2006, and shipped with the initial release of Firefox 3.0. At the time, the change was also backported to the Firefox 1.5 and Firefox 2 branches. and we came to the conclusion that as much as possible the canvas should silently ignore NaN/Infinite values. Well, except that leads to incorrect rendering, as I said. Was this discussion public, perchance? -Boris
Re: [whatwg] Differences between HTML5 Drafts
Thanks. I am a newbie ;) BTW, some revisions(e.g. 5443, 5439) are displayed in red background. What does it mean? When I click a revision's URL, e.g. http://html5.org/tools/web-apps-tracker?from=5442to=5443 The web page is strangely displayed. My browser is Firefox 3.6, need I use other browsers? On Thu, Sep 9, 2010 at 1:34 AM, Mihai Parparita mih...@chromium.org wrote: http://html5.org/tools/web-apps-tracker shows recent changes (with diffs). Mihai On Wed, Sep 8, 2010 at 10:31 AM, zhao Matt mattzhao...@gmail.com wrote: WHATWG version. thanks On Thu, Sep 9, 2010 at 1:19 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Sep 8, 2010 at 10:11 AM, zhao Matt mattzhao...@gmail.com wrote: I want to know the differences between these HTML5 drafts( I don't want to know more details about the differences, and just want to know the major changes), Could someone know where to find such Information? Which drafts do you mean? The WHATWG and W3C versions? Or something else? ~TJ
Re: [whatwg] Canvas API: What should happen if non-finite floats are used
On Wed, Sep 8, 2010 at 10:33 AM, Oliver Hunt oli...@apple.com wrote: In a lot of cases all you want to do is ignore NaN and Infinite values, otherwise you basically have to prepend every call to canvas with NaN and Infinity checks if you're computing values unless you can absolutely guarantee your values won't have gone nuts at any point in the computation -- otherwise you're going to get reports that occasionally your content breaks but with no repro case (typical users will not be seeing error messages, it just doesn't work). Does this mean that you're expecting that the ignored calls didn't matter? Surely having parts of the drawing be missing will often be noticed by users as well! Mike
Re: [whatwg] Differences between HTML5 Drafts
thanks On Thu, Sep 9, 2010 at 1:43 AM, Simon Pieters sim...@opera.com wrote: On Wed, 08 Sep 2010 19:39:18 +0200, zhao Matt mattzhao...@gmail.com wrote: Also, I found a W3C draft's publication notes at http://www.w3.org/TR/2008/NOTE-html5-pubnotes-20080610/. However, I can't find other draft's publication notes. I think pubnotes haven't been written for other drafts since it was too much work. However, there's http://www.w3.org/TR/html5-diff/#changelog -- Simon Pieters Opera Software
Re: [whatwg] Canvas API: What should happen if non-finite floats are used
On 9/8/10 1:33 PM, Oliver Hunt wrote: Additionally there is content that depends on the non-throwing behaviour, in webkit we had to drop the exceptions that we threw due to content that worked in firefox because of the absence of exceptions. I'm really curious about this claim. Looking at the code, we seem to throw on all the functions I see that take floats if the float is non-finite, and those checks all go back to November 2006. Were you running into compat issues _before_ that or something? Note that before we added the checks we just passed the non-finite values to the drawing library, which typically crashed rather than silently working. -Boris
Re: [whatwg] Video with MIME type application/octet-stream
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 redoing the network request but has interactions with session history, etc, etc. It's a huge can of worms. -Boris
Re: [whatwg] ArrayBuffer and ByteArray questions
On Sep 8, 2010, at 9:44 AM, Simon Pieters wrote: On Wed, 08 Sep 2010 17:22:44 +0200, Chris Marrin cmar...@apple.com wrote: On Sep 8, 2010, at 12:13 AM, Anne van Kesteren wrote: On Wed, 08 Sep 2010 01:09:13 +0200, Jian Li jia...@chromium.org wrote: Several specs, like File API and WebGL, use ArrayBuffer, while other spec, like XMLHttpRequest Level 2, use ByteArray. Should we change to use the same name all across our specs? Since we define ArrayBuffer in the Typed Arrays spec ( https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html), should we favor ArrayBuffer? In addition, can we consider adding ArrayBuffer support to BlobBuilder, FormData, and XMLHttpRequest.send()? So TC39 is going to leave this thing alone? I.e. are we sure ArrayBuffer is the way of the future? ArrayBuffer certainly has momentum behind it. It started as a part of the WebGL spec as a way of passing buffers of data of various types (sometimes heterogeneous types) to the WebGL engine. Since then, it has found uses in the Web Audio proposal, the File API and there has been talk in using it as a way to pass data to Web Workers. Do you mean WebSockets? Web Sockets is certainly another candidate, but I meant Web Workers. There have been informal discussions on using ArrayBuffers as a way to safely share binary data between threads. I don't believe anything has been formalized here. - ~Chris cmar...@apple.com
Re: [whatwg] ArrayBuffer and ByteArray questions
On Wed, 08 Sep 2010 20:13:19 +0200, Chris Marrin cmar...@apple.com wrote: ArrayBuffer certainly has momentum behind it. It started as a part of the WebGL spec as a way of passing buffers of data of various types (sometimes heterogeneous types) to the WebGL engine. Since then, it has found uses in the Web Audio proposal, the File API and there has been talk in using it as a way to pass data to Web Workers. Do you mean WebSockets? Web Sockets is certainly another candidate, but I meant Web Workers. There have been informal discussions on using ArrayBuffers as a way to safely share binary data between threads. I don't believe anything has been formalized here. Oh, as in posting to a worker with postMessage? Yeah that could be useful. A side-effect of speccing this would be that other stuff that use the structured clone algorithm would also support ArrayBuffer, e.g. localStorage. -- Simon Pieters Opera Software
Re: [whatwg] ArrayBuffer and ByteArray questions
On Sep 8, 2010, at 11:13 AM, Chris Marrin wrote: Web Sockets is certainly another candidate, but I meant Web Workers. There have been informal discussions on using ArrayBuffers as a way to safely share binary data between threads. I don't believe anything has been formalized here. You can't share data between workers. There is no (and there cannot be) any shared state between multiple threads of JS execution.
Re: [whatwg] Canvas API: What should happen if non-finite floats are used
On Sep 8, 2010, at 11:00 AM, Boris Zbarsky wrote: On 9/8/10 12:45 PM, Oliver Hunt wrote: I suggested this behaviour a long time ago after running into yet another piece of code that hit this case in webkit (back when the spec said to throw an exception) yet firefox and opera did not throw. In some cases firefox does throw, and in others it doesn't (or maybe didn't? has ffx behaviour changed?) Gecko behavior for lineTo and most other canvas methods I see has been to throw since late 2006, and shipped with the initial release of Firefox 3.0. At the time, the change was also backported to the Firefox 1.5 and Firefox 2 branches. and we came to the conclusion that as much as possible the canvas should silently ignore NaN/Infinite values. Well, except that leads to incorrect rendering, as I said. Was this discussion public, perchance? I can see a number of canvas discussions in late 2007/early 2008 on the whatwg list, so i presume that covers some of it. It also only leads to incorrect rendering if the behaviour if it's unexpected. One old case that failed in the presence of exceptions was the old canvex demo at http://canvex.lazyilluminati.com/83/play.xhtml - this was one of the first cases i saw after trying to make webkit's implementation conform to the (older) spec by throwing exceptions on non-finite values we had many canvas using sites break so had to stop throwing. It seems to work these days but a quick scan of the minified source seemed to indicate that they now put try/catch around every use of canvas is now wrapped in try/catch --Oliver
Re: [whatwg] ArrayBuffer and ByteArray questions
On Wed, Sep 8, 2010 at 11:21 AM, Oliver Hunt oli...@apple.com wrote: On Sep 8, 2010, at 11:13 AM, Chris Marrin wrote: Web Sockets is certainly another candidate, but I meant Web Workers. There have been informal discussions on using ArrayBuffers as a way to safely share binary data between threads. I don't believe anything has been formalized here. You can't share data between workers. There is no (and there cannot be) any shared state between multiple threads of JS execution. Let's say efficiently send rather than share. The current thinking has been around a way to post one ArrayBuffer to a worker which would close that ArrayBuffer and all views on the main thread. The way to get the same backing store from the worker back to the main thread would be to post the ArrayBuffer from the worker to the main thread, at which point the ArrayBuffer and all views on the worker would be closed. This ping-ponging would allow efficient implementation of producer/consumer queues without allocating new backing store each time the worker wants to produce something for the main thread. This would require some small API additions to the typed array spec, and a prototype so we can convince ourselves of its effectiveness. -Ken
Re: [whatwg] ArrayBuffer and ByteArray questions
On Sep 8, 2010, at 11:21 AM, Oliver Hunt wrote: On Sep 8, 2010, at 11:13 AM, Chris Marrin wrote: Web Sockets is certainly another candidate, but I meant Web Workers. There have been informal discussions on using ArrayBuffers as a way to safely share binary data between threads. I don't believe anything has been formalized here. You can't share data between workers. There is no (and there cannot be) any shared state between multiple threads of JS execution. Right. I didn't mean literal sharing. But you can imagine some copy-on-write semantics which would make it more efficient to pass data this way. - ~Chris cmar...@apple.com
Re: [whatwg] Differences between HTML5 Drafts
On Wed, Sep 8, 2010 at 11:00 AM, zhao Matt mattzhao...@gmail.com wrote: Thanks. I am a newbie ;) BTW, some revisions(e.g. 5443, 5439) are displayed in red background. What does it mean? The color is an indication of the type of edit. If you hover the link in the revision message, you'll see that the red ones display a tooltip saying Implemented, while grey ones display something else, usually containing Draft Content. When I click a revision's URL, e.g. http://html5.org/tools/web-apps-tracker?from=5442to=5443 The web page is strangely displayed. My browser is Firefox 3.6, need I use other browsers? What strangeness do you see? I'm looking at it in FF 3.6 and don't see anything particularly strange. ~TJ
Re: [whatwg] Video with MIME type application/octet-stream
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. In fact, given that HTML5 does not endorse or limit implementation to a particular video format, there could be any number of video formats whose header-words I have to avoid using in the first N bytes of my file. If I were serving an image/png with no PNG header, you could say it was clearly wrong. But there's no way you can say any sequence of bytes is clearly not application/octet-stream or some other anything-goes type. I'm not yet sure what the correct tradeoff is here, but I'm pretty sure it's not no sniffing at all under any conditions. I suggest: 1. Resources with no Content-Type continue to be fair game. 2. By far the most prevalent maybe wrong Content-Type that is widely deployed is text/plain, due to inappropriate web server defaults (both IIS and Apache2.3). Allow sniffing of text/plain resources, but provide an override for server operators to say I mean it, this is really text/plain. ie. standardise X-Content-Type-Options or something like it. 3. Sniffing should otherwise not occur in any context. It is unfortunate that sniffing will continue to be needed for the text/plain case for a very long time yet. But we should be aiming to mitigate and deprecate this historical error, rather than make the problem an order of magnitude worse by requiring potentially-limitless new sniffing cases. it's unreliable in the same way across all browsers. It's already different in different browsers, even with the small number of filetypes we currently have. As previously commented, undistinctive fingerprints, starting mid-stream and other oddities like ID3 tags makes sniffing for media filetypes even more troublesome than it is for other types. In any case, any sniffing solution will always be inconsistent as different browsers, OSes, installed codecs and options expose different media filetypes to the net. Never mind just browsers, or even browsers that simply pass the resource to their underlying media frameworks for sniffing: there are far more already-deployed media players with HTTP capability than there are browsers with video/audio support. There is no chance we will ever be able to standardise the implementation of sniffing amongst this wide range of agents! So there will always be non-compliant UAs. In the face of this, we might as well standardise the 'good' solution - minimal sniffing - and hope to drag a few modern browsers along with that, instead of mandating an unreliable sniffing approach that *still* isn't implemented universally. This is particularly essential for security -- undocumented sniffing behavior has caused more than one vulnerability in the past. Yes. Undocumented sniffing behaviour has caused many vulnerabilities, as even well-known sniffing behaviour continues to do (see the current publicised difficulties with CSS-inclusion attacks). Lack of sniffing behaviour, however, has never caused a vulnerability. It fails safe. -- And Clover mailto:a...@doxdesk.com http://www.doxdesk.com/
Re: [whatwg] Video with MIME type application/octet-stream
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 the encoding is either not present or is UTF-8 or ISO-8859-1. Or whatever web servers do here. * Sniff the same both for video tags and top-level browsing contexts, so open video in new tab doesn't mysteriously fail on some setups. I could probably live with those, actually. On Wed, Sep 8, 2010 at 5:33 AM, Philip Jägenstedt phil...@opera.com wrote: I agree with Boris, the first two points are OK but the third I'd rather not implement, it's too much work for something that ought to happen very, very rarely. That sounds promising. What do other implementers think? * 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 occurred. This might be pretty difficult to implement, since the video decoder might consume arbitrary amounts of data before saying that there was an error. And the problem is that you don't want to keep the data handy in case it fails? Hopefully it makes no big difference, then. 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, dispatch, if the HTML source gave you a mime type? What advantage does this serve? 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 at the top. Anything's possible, but it's vastly more likely that you just made a mistake. I suggest: 1. Resources with no Content-Type continue to be fair game. 2. By far the most prevalent maybe wrong Content-Type that is widely deployed is text/plain, due to inappropriate web server defaults (both IIS and Apache2.3). Allow sniffing of text/plain resources, but provide an override for server operators to say I mean it, this is really text/plain. ie. standardise X-Content-Type-Options or something like it. 3. Sniffing should otherwise not occur in any context. This is basically the same as what I suggested in my last post, right? Except for the allow opting out of sniffing, which would be great but is orthogonal. It's already different in different browsers, even with the small number of filetypes we currently have. Because it's not standardized. In any case, any sniffing solution will always be inconsistent as different browsers, OSes, installed codecs and options expose different media filetypes to the net. I don't follow. A standardized sniffing solution can be implemented across the board. Never mind just browsers, or even browsers that simply pass the resource to their underlying media frameworks for sniffing: there are far more already-deployed media players with HTTP capability than there are browsers with video/audio support. There is no chance we will ever be able to standardise the implementation of sniffing amongst this wide range of agents! So there will always be non-compliant UAs. In the face of this, we might as well standardise the 'good' solution - minimal sniffing - and hope to drag a few modern browsers along with that, instead of mandating an unreliable sniffing approach that *still* isn't implemented universally. I don't follow this logic. If these media players want to work the same as browsers, they'll implement the spec. If they don't implement the spec, it makes no difference what the spec says, so why even consider them? Yes. Undocumented sniffing behaviour has caused many vulnerabilities, as even well-known sniffing behaviour continues to do (see the current publicised difficulties with CSS-inclusion attacks). Lack of sniffing behaviour, however, has never caused a vulnerability. It fails safe. The CSS-inclusion attacks that I'm aware of involve @import-ing an HTML document and observing what syntax errors occur. There is no sniffing that occurs there. What attacks were you thinking of?
Re: [whatwg] Canvas API: What should happen if non-finite floats are used
On 9/8/10 2:22 PM, Oliver Hunt wrote: I can see a number of canvas discussions in late 2007/early 2008 on the whatwg list, so i presume that covers some of it. OK. All versions of Firefox threw at that point. It also only leads to incorrect rendering if the behaviour if it's unexpected. Well... I guess that depends on how you define correct rendering. The case where I ran into was graphing a function; due to Webkit ignoring the calls that use NaN the graph is completely wrong (the actual function has a singularity at 0 which entirely disappears, with a smooth interpolation between two points pretty far away from zero shown instead). One old case that failed in the presence of exceptions was the old canvex demo at http://canvex.lazyilluminati.com/83/play.xhtml - this was one of the first cases i saw after trying to make webkit's implementation conform to the (older) spec by throwing exceptions on non-finite values we had many canvas using sites break so had to stop throwing. OK. I can believe that this was the case at the time, but it certainly wasn't due to Firefox not throwing. I can see how given people's penchant to create browser-specific content changing the webkit behavior could cause issues with sites that were targeting only webkit and didn't bother testing in anything else. It seems to work these days but a quick scan of the minified source seemed to indicate that they now put try/catch around every use of canvas is now wrapped in try/catch Right. Which raises the question of whether this would be an issue nowadays. With the exception of that one graphing demo (which was on a Chrome demos site, iirc so again is targeting webkit), we have had no reports of this being an issue in Gecko. -Boris
Re: [whatwg] Video with MIME type application/octet-stream
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 even well-known sniffing behaviour continues to do (see the current publicised difficulties with CSS-inclusion attacks). Lack of sniffing behaviour, however, has never caused a vulnerability. It fails safe. The CSS-inclusion attacks that I'm aware of involve @import-ing an HTML document and observing what syntax errors occur. There is no sniffing that occurs there. There sort of is. There's the fact that for quirks documents the Content-Type for style sheet resources was ignored. (Note that the syntax errors are not what the issue was about, btw.) -Boris
Re: [whatwg] The choice of script global object to use when the script element is moved
On Fri, 3 Sep 2010, Henri Sivonen wrote: When evaluating a parser-inserted script, there are three potential script global objects to use: 1) The script global object of the document whose active parser the parser that inserted the script is. 2) The script global object of the document that owned the script element at the time of invoking the run algorithm. 3) The script global object of the document that owns the script element at the time of script evaluation. #1 and #2 are dodgy because the documents in question might have been GC'ed by that point. The spec says the answer is #3. WebKit (with HTML5 parser or without) says the answer is #1. Firefox 3.6 says the answer is #2. I doubt that there are Web compat considerations forcing this choice, because IE8 doesn't get as far as running the script in this case. IE9 tries to do either #2 or #3 (not sure which) succeeding for inline scripts and failing for external ones. (IIRC, the text in the spec that explains the distinction between 1 and the other (without explaining the distinction between 2 and 3) was added specifically for the benefit of the IE team.) I'm not sure exactly which sentence you mean here, but I'm happy to clarify text if anything is ambiguous. The spec asserts that these options are equally safe, because if something is able to move the scripts so that 1, 2 and 3 would result in different script global objects, the script gets moved within one Origin. There's some weirdness, e.g. if one of the browsing contexts has script disabled or if document.domain gets changed after the script node is moved to another document, but yeah, as far as I can tell either option is safe. However, if there's something other than Same Origin restricting what scripts are eligible for evaluation (e.g. Content Security Policies that I don't know well enough to reason about), 1, 2 and 3 might not be equally safe. Essentially, there are two browsing contexts, the one with the parser and the other one. - If the one with the parser moves the script to the other context: for an attack to be relevant here, the script would have to run in the other context, but any attack possible this way could also be done by just creating a script in that document and appending it, or setting onload or onclick or some such content attribute in that document. If script is disabled in that other browsing context then nothing happens. - If the one without the parser grabs the script and inserts it into itself, then for any attack to be interesting, scripting in the parser doc has to be disabled (since otherwise the other doc could just inject script into the parser doc and do whatever it wanted as if it was itself the parser doc). If we make scripts run in the parser doc context, then you can use this to grab a script src= that is Referer-checked and execute it in the other doc's context, grabbing any information from that script. However, you could also do this by just pushState()ing to the other doc's URL, and then obtaining the script directly. The other possibility is scripts running in the non-parser doc context, but as far as I can tell you can always just grab the script from the other DOM and copy it to run in the non-parser doc, so again no new security problem seems to be introduced. So in conclusion, I really don't see a new attack vector regardless of what we do here. * Why does the spec say #3 when none of the browsers did #3 at the time of spec writing? I don't know the original reason. I would guess it was simply a matter of doing the simplest thing in the spec -- I try wherever possible to not refer back to the active parser if I can avoid it, letting things work identically with DOM manipulation from script as from the parser. Also, it avoids any weirdness like how to handle the case of the original doc(s) being GCed. * Are there use cases that favor any one of these in particular? (I doubt it.) They seem identical. FWIW, my gut says we should do #1, since it is obviously secure, except it would be unfortunate if the spec changed to #1 but too late for IE9 to match. They all seem obviously secure. If you can manipulate a document's DOM, you can essentially do anything including running arbitrary script in that document or run script from that document in your document. One advantage of doing #3 is that, as Adam pointed out, the implementation is required to get the security context at the last minute, where it's most likely to be up to date (e.g. with document.domain changes, etc) even in the case of the script element not being moved around. On Fri, 3 Sep 2010, Boris Zbarsky wrote: Could it cause script to run from a script element that someone sticks in a same-origin but sandboxed iframe if the non-sandboxed parent moves some part of the DOM out before the parse is done? The only relevant case would be a sandboxed frame that is marked
Re: [whatwg] Canvas API: What should happen if non-finite floats are used
On Wed, Sep 8, 2010 at 9:02 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 9/8/10 2:22 PM, Oliver Hunt wrote: One old case that failed in the presence of exceptions was the old canvex demo at http://canvex.lazyilluminati.com/83/play.xhtml - this was one of the first cases i saw after trying to make webkit's implementation conform to the (older) spec by throwing exceptions on non-finite values we had many canvas using sites break so had to stop throwing. OK. I can believe that this was the case at the time, but it certainly wasn't due to Firefox not throwing. I can see how given people's penchant to create browser-specific content changing the webkit behavior could cause issues with sites that were targeting only webkit and didn't bother testing in anything else. Canvex was originally written for and tested in Firefox 1.5/2.0 and Opera 9. It wasn't tested in Safari (due to lack of Mac). I think the relevant bug is https://bugs.webkit.org/show_bug.cgi?id=13537 which was actually caused by passing 0 sizes to drawImage, not by non-finite values. -- Philip Taylor exc...@gmail.com
Re: [whatwg] ArrayBuffer and ByteArray questions
On Thu, Sep 9, 2010 at 4:37 AM, Chris Marrin cmar...@apple.com wrote: On Sep 8, 2010, at 11:21 AM, Oliver Hunt wrote: On Sep 8, 2010, at 11:13 AM, Chris Marrin wrote: Web Sockets is certainly another candidate, but I meant Web Workers. There have been informal discussions on using ArrayBuffers as a way to safely share binary data between threads. I don't believe anything has been formalized here. You can't share data between workers. There is no (and there cannot be) any shared state between multiple threads of JS execution. Right. I didn't mean literal sharing. But you can imagine some copy-on-write semantics which would make it more efficient to pass data this way. Is this then similar to posting ImageData with Web Workers? ( http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#imagedata) . I know that these can already be put into a postMessage and they are effectively arrays. Cheers, Silvia.
Re: [whatwg] Video with MIME type application/octet-stream
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, dispatch, if the HTML source gave you a mime type? What advantage does this serve? It both significantly reduces the footprint of sniffing (knocks out a whole load of cases), and clarifies that 'canplay' decisions don't need to sniff (so you don't sniff a whole bunch of different files). 'Non-configured servers' is a valid excuse for HTTP content-type being wrong (for a few cases), but I can't think of any reason to disbelieve the page author, can you? 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 at the top. Anything's possible, but it's vastly more likely that you just made a mistake. It may be possible to make one file that is valid under two formats. Kinda like those old competitions write a single file that when compiled and run through as many languages as possible prints hello, world! :-). David Singer Multimedia and Software Standards, Apple Inc.
Re: [whatwg] Canvas API: What should happen if non-finite floats are used
On 9/8/10 7:04 PM, Philip Taylor wrote: I think the relevant bug is https://bugs.webkit.org/show_bug.cgi?id=13537 which was actually caused by passing 0 sizes to drawImage, not by non-finite values. Ah, yes. The drawImage size check for 0 in Gecko is still nonthrowing, and has never thrown to my knowledge. But that has nothing to do with the issue I initially raised. Nor does the fix for that Webkit bug have anything to do with the issue I raised. -Boris
