date:20100520


On Thu, 06 May 2010 17:20:41 +0200, Simon Pieters sim...@opera.com wrote:

On Tue, 20 Apr 2010 16:00:36 +0200, Simon Pieters sim...@opera.com  
wrote:



[[
WebSocket object with an open connection must not be garbage collected  
if there are any event listeners registered for message events.

]]

Shouldn't it also not be garbage collected if there are listeners for  
open, error and close? What about when the connection is not yet  
established?


I think the policy should be:

if readyState is CONNECTING:
   has 'open' event listener: don't collect
   has 'message' event listener: don't collect
   has 'error' event listener: don't collect
   has 'close' event listener: don't collect

if readyState is OPEN:
   has 'open' event listener: OK to collect
   has 'message' event listener: don't collect
   has 'error' event listener: don't collect
   has 'close' event listener: don't collect

if readyState is CLOSING:
   has 'open' event listener: OK to collect
   has 'message' event listener: OK to collect
   has 'error' event listener: OK to collect
   has 'close' event listener: don't collect

if readyState is CLOSED:
   has 'open' event listener: OK to collect
   has 'message' event listener: OK to collect
   has 'error' event listener: OK to collect
   has 'close' event listener: OK to collect


Make that:

 if readyState is CONNECTING:
has 'open' event listener: don't collect
has 'message' event listener: don't collect
has 'error' event listener: don't collect
has 'close' event listener: don't collect

 if readyState is OPEN or CLOSING:
has 'open' event listener: OK to collect
has 'message' event listener: don't collect
has 'error' event listener: don't collect
has 'close' event listener: don't collect

 if readyState is CLOSED:
has 'open' event listener: OK to collect
has 'message' event listener: OK to collect
has 'error' event listener: OK to collect
has 'close' event listener: OK to collect


(I didn't realize that you could get message and error events in CLOSING  
state.)


--
Simon Pieters
Opera Software

Re: [whatwg] forwarded: Google opens VP8 video codec

2010-05-20 Thread David Gerard

On 20 May 2010 00:38, David Gerard dger...@gmail.com wrote:

 x264 don't think much of VP8, they think it's just not ready:
 http://x264dev.multimedia.cx/?p=377
 OTOH, that may not end up mattering.


Greg Maxwell thinks it's only about as much of a car crash as VP3 was
when it was released:

http://lists.wikimedia.org/pipermail/wikitech-l/2010-May/047795.html

You should have seen what VP3 was like when it was handed over to
Xiph.Org.  The software was horribly buggy, slow, and the quality was
fairly poor (at least compared to the current status).

What it needs, of course, is a plugin for *current* browsers, more
than the Chrome/Chromium dev channel.

In any case - interesting times :-D


- d.

Re: [whatwg] forwarded: Google opens VP8 video codec

2010-05-20 Thread ニール・ゴンパ

On Thu, May 20, 2010 at 4:27 AM, David Gerard dger...@gmail.com wrote:

 On 20 May 2010 00:38, David Gerard dger...@gmail.com wrote:

  x264 don't think much of VP8, they think it's just not ready:
  http://x264dev.multimedia.cx/?p=377
  OTOH, that may not end up mattering.


 Greg Maxwell thinks it's only about as much of a car crash as VP3 was
 when it was released:

 http://lists.wikimedia.org/pipermail/wikitech-l/2010-May/047795.html

 You should have seen what VP3 was like when it was handed over to
 Xiph.Org.  The software was horribly buggy, slow, and the quality was
 fairly poor (at least compared to the current status).

 What it needs, of course, is a plugin for *current* browsers, more
 than the Chrome/Chromium dev channel.

 In any case - interesting times :-D


 - d.


Opera has already made a GStreamer plugin for VP8 and released it in their
gstreamer git repository, and Firefox already has support integrated into
the trunk.

The real problem is getting libvpx included into distros. The buildsystem
doesn't currently build shared libraries, only static ones. Yay for custom
buildsystems... In any case, it looks like Fedora has hacked around that
issue and will hopefully soon include it in the distro package lists.

[whatwg] Video with MIME type application/octet-stream

I just became aware that application/octet-stream is excluded from being a
type the user agent knows it cannot render.
http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#a-type-that-the-user-agent-knows-it-cannot-render
Apparently this was done in response to a bug report:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=7977
Neither the bug report nor the editor's response give any indication why
this change was made.

This change means files served with application/octet-stream will make it
all the way to the step If the media
datahttp://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#media-datacan
be fetched but is found by inspection to be in an unsupported format
..., so implementations have to add support for binary sniffing for all the
types they support. We didn't need this before in Gecko. What was the
motivation for adding this implementation requirement?

Thanks,
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] forwarded: Google opens VP8 video codec

2010-05-20 Thread David Gerard

2010/5/20 Peter Beverloo pe...@lvp-media.com:

 Microsoft has announced playback support for VP8 in Internet Explorer 9[1]
 under the condition that one has to install a VP8 codec manually, albeit via
 inclusion in another program: In its HTML5 support, IE9 will support
 playback of H.264 video as well as VP8 video when the user has installed a
 VP8 codec on Windows.
 I think that's fairly significant.


I don't. They're trying to make if you install it yourself, it'll
work look like they're actually doing anything at all. But they're
not, because the same applies already to Vorbis and Theora. If
anything, they're just offering not to deliberately stop it from
working.


- d.

Re: [whatwg] Video with MIME type application/octet-stream

On Thu, May 20, 2010 at 9:55 PM, Robert O'Callahan rob...@ocallahan.orgwrote:

I just became aware that application/octet-stream is excluded from being a
type the user agent knows it cannot render.

http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#a-type-that-the-user-agent-knows-it-cannot-render
Apparently this was done in response to a bug report:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=7977
Neither the bug report nor the editor's response give any indication why
this change was made.

This change means files served with application/octet-stream will make it
all the way to the step If the media
datahttp://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#media-datacan
be fetched but is found by inspection to be in an unsupported format
..., so implementations have to add support for binary sniffing for all the
types they support. We didn't need this before in Gecko. What was the
motivation for adding this implementation requirement?

Hmm. I guess it doesn't add any implementation requirements beyond what you
need to handle the complete absence of a Content-Type (which we currently
don't handle, but I suppose we should). So this isn't really a problem.

I'd still like to know why application/octet-stream has been added here,
though.

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] forwarded: Google opens VP8 video codec

2010-05-20 Thread Philip Jägenstedt


On Thu, 20 May 2010 17:55:42 +0800, David Gerard dger...@gmail.com wrote:


2010/5/20 Peter Beverloo pe...@lvp-media.com:

Microsoft has announced playback support for VP8 in Internet Explorer  
9[1]
under the condition that one has to install a VP8 codec manually,  
albeit via

inclusion in another program: In its HTML5 support, IE9 will support
playback of H.264 video as well as VP8 video when the user has  
installed a

VP8 codec on Windows.
I think that's fairly significant.



I don't. They're trying to make if you install it yourself, it'll
work look like they're actually doing anything at all. But they're
not, because the same applies already to Vorbis and Theora. If
anything, they're just offering not to deliberately stop it from
working.


That is unfair. While I don't know precisely what the IE team is doing,  
hooking up things like canPlayType to give the correct reply depending on  
what is installed doesn't happen automatically.


--
Philip Jägenstedt
Core Developer
Opera Software

Re: [whatwg] forwarded: Google opens VP8 video codec

2010-05-20 Thread David Gerard

On 20 May 2010 11:03, Philip Jägenstedt phil...@opera.com wrote:
 On Thu, 20 May 2010 17:55:42 +0800, David Gerard dger...@gmail.com wrote:

 I don't. They're trying to make if you install it yourself, it'll
 work look like they're actually doing anything at all. But they're
 not, because the same applies already to Vorbis and Theora. If
 anything, they're just offering not to deliberately stop it from
 working.

 That is unfair. While I don't know precisely what the IE team is doing,
 hooking up things like canPlayType to give the correct reply depending on
 what is installed doesn't happen automatically.


hmm, OK. I suppose they have to actually check it won't break anything.


- d.

Re: [whatwg] forwarded: Google opens VP8 video codec

2010-05-20 Thread Philip Jägenstedt

On Thu, 20 May 2010 17:34:49 +0800, Conan Kudo (ニール・ゴンパ)  
ngomp...@gmail.com wrote:



On Thu, May 20, 2010 at 4:27 AM, David Gerard dger...@gmail.com wrote:


On 20 May 2010 00:38, David Gerard dger...@gmail.com wrote:

 x264 don't think much of VP8, they think it's just not ready:
 http://x264dev.multimedia.cx/?p=377
 OTOH, that may not end up mattering.


Greg Maxwell thinks it's only about as much of a car crash as VP3 was
when it was released:

http://lists.wikimedia.org/pipermail/wikitech-l/2010-May/047795.html

You should have seen what VP3 was like when it was handed over to
Xiph.Org.  The software was horribly buggy, slow, and the quality was
fairly poor (at least compared to the current status).

What it needs, of course, is a plugin for *current* browsers, more
than the Chrome/Chromium dev channel.

In any case - interesting times :-D


- d.



Opera has already made a GStreamer plugin for VP8 and released it in  
their

gstreamer git repository, and Firefox already has support integrated into
the trunk.


As it turns out Collabora also made plugins (unknown to us) and this is  
what is now in gst-plugins-bad. Still, Opera's matroskademux WebM changes  
and parts of our encoder/decoder will come to use.


--
Philip Jägenstedt
Core Developer
Opera Software

Re: [whatwg] Video with MIME type application/octet-stream

2010-05-20 Thread Philip Jägenstedt

On Thu, 20 May 2010 17:59:42 +0800, Robert O'Callahan
rob...@ocallahan.org wrote:

On Thu, May 20, 2010 at 9:55 PM, Robert O'Callahan
rob...@ocallahan.orgwrote:

I just became aware that application/octet-stream is excluded from
being a

type the user agent knows it cannot render.

This change means files served with application/octet-stream will make
it
all the way to the step If the media
datahttp://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#media-datacan
be fetched but is found by inspection to be in an unsupported format
..., so implementations have to add support for binary sniffing for
all the

types they support. We didn't need this before in Gecko. What was the
motivation for adding this implementation requirement?

Hmm. I guess it doesn't add any implementation requirements beyond what
you

need to handle the complete absence of a Content-Type (which we currently
don't handle, but I suppose we should). So this isn't really a problem.

I'd still like to know why application/octet-stream has been added here,
though.

For the record, Opera implements canPlayType(application/octet-stream)
and canPlayType(application/octet-stream; codecs=foo) as per spec
(maybe and respectively), but I don't have any strong opinions about
it.

--
Philip Jägenstedt
Core Developer
Opera Software

Re: [whatwg] forwarded: Google opens VP8 video codec

2010-05-20 Thread Peter Beverloo

On Thu, May 20, 2010 at 11:55, David Gerard dger...@gmail.com wrote:

 2010/5/20 Peter Beverloo pe...@lvp-media.com:

  Microsoft has announced playback support for VP8 in Internet Explorer
 9[1]
  under the condition that one has to install a VP8 codec manually, albeit
 via
  inclusion in another program: In its HTML5 support, IE9 will support
  playback of H.264 video as well as VP8 video when the user has installed
 a
  VP8 codec on Windows.
  I think that's fairly significant.


 I don't. They're trying to make if you install it yourself, it'll
 work look like they're actually doing anything at all. But they're
 not, because the same applies already to Vorbis and Theora. If
 anything, they're just offering not to deliberately stop it from
 working.


 - d.


Microsoft showing interest in a codec they're not specifically participating
in, different from their involvement in H264, is a good start. In their
revised comments about HTML 5 video[1] they already stated that they would
consider implementing other codecs if the industry reaches a consensus and
is confident that the uncertainties are resolved. Their wording in the
recent blog-post refers to an industry announcement rather than a Google
announcement, which is why I think it's plausible to assume including the
codec by default will be, partially, dependent on Apple's stance on it.

As Philip already said, right now there simply are a number
of uncertainties limiting the discussion to mere speculation. Let's hope
more clearity will be available soon.

Peter

[1]
http://blogs.msdn.com/ie/archive/2010/05/03/follow-up-on-html5-video-in-ie9.aspx

Re: [whatwg] forwarded: Google opens VP8 video codec

2010-05-20 Thread Adam Harvey

On 20 May 2010 17:55, David Gerard dger...@gmail.com wrote:
 2010/5/20 Peter Beverloo pe...@lvp-media.com:
 Microsoft has announced playback support for VP8 in Internet Explorer 9[1]
 under the condition that one has to install a VP8 codec manually, albeit via
 inclusion in another program: In its HTML5 support, IE9 will support
 playback of H.264 video as well as VP8 video when the user has installed a
 VP8 codec on Windows.
 I think that's fairly significant.

 I don't. They're trying to make if you install it yourself, it'll
 work look like they're actually doing anything at all. But they're
 not, because the same applies already to Vorbis and Theora. If
 anything, they're just offering not to deliberately stop it from
 working.

It is quite significant: before that announcement, H.264 was to be the
only codec supported in video tags in IE9.⁰ Microsoft aren't
intending to allow video to use system codecs generally for a bunch
of reasons¹ (probably most notably around security), which has ruled
native Theora in IE9 out for now.

Adam

⁰ http://blogs.msdn.com/ie/archive/2010/04/29/html5-video.aspx
¹ 
http://blogs.msdn.com/ie/archive/2010/05/03/follow-up-on-html5-video-in-ie9.aspx

Re: [whatwg] Video with MIME type application/octet-stream

On Thu, 20 May 2010 11:55:01 +0200, Robert O'Callahan  
rob...@ocallahan.org wrote:


I just became aware that application/octet-stream is excluded from being  
a

type the user agent knows it cannot render.
http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#a-type-that-the-user-agent-knows-it-cannot-render
Apparently this was done in response to a bug report:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=7977
Neither the bug report nor the editor's response give any indication why
this change was made.


This bug report was about application/octet-stream *with parameters*, e.g.  
application/octet-stream; codecs=theora, vorbis. The spec had the  
requirement about application/octet-stream before that bug report.




This change means files served with application/octet-stream will make it
all the way to the step If the media
datahttp://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#media-datacan
be fetched but is found by inspection to be in an unsupported format
..., so implementations have to add support for binary sniffing for all  
the

types they support. We didn't need this before in Gecko. What was the
motivation for adding this implementation requirement?

Thanks,
Rob



--
Simon Pieters
Opera Software

Re: [whatwg] Video with MIME type application/octet-stream

On Thu, 20 May 2010 12:36:36 +0200, Simon Pieters sim...@opera.com wrote:

On Thu, 20 May 2010 11:55:01 +0200, Robert O'Callahan
rob...@ocallahan.org wrote:

I just became aware that application/octet-stream is excluded from
being a

type the user agent knows it cannot render.
http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#a-type-that-the-user-agent-knows-it-cannot-render
Apparently this was done in response to a bug report:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=7977
Neither the bug report nor the editor's response give any indication why
this change was made.

This bug report was about application/octet-stream *with parameters*,
e.g. application/octet-stream; codecs=theora, vorbis. The spec had the
requirement about application/octet-stream before that bug report.

This change means files served with application/octet-stream will make
it

all the way to the step If the media
datahttp://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#media-datacan
be fetched but is found by inspection to be in an unsupported format
..., so implementations have to add support for binary sniffing for
all the

types they support. We didn't need this before in Gecko. What was the
motivation for adding this implementation requirement?

The spec requires binary sniffing for all the types you support even
without the application/octet-stream requirement, since a WebM file
labelled as video/ogg should play if both video/webm and video/ogg are
supported.

--
Simon Pieters
Opera Software

Re: [whatwg] forwarded: Google opens VP8 video codec

2010-05-20 Thread Silvia Pfeiffer

On Thu, May 20, 2010 at 8:16 PM, Adam Harvey a...@adamharvey.name wrote:
 On 20 May 2010 17:55, David Gerard dger...@gmail.com wrote:
 2010/5/20 Peter Beverloo pe...@lvp-media.com:
 Microsoft has announced playback support for VP8 in Internet Explorer 9[1]
 under the condition that one has to install a VP8 codec manually, albeit via
 inclusion in another program: In its HTML5 support, IE9 will support
 playback of H.264 video as well as VP8 video when the user has installed a
 VP8 codec on Windows.
 I think that's fairly significant.

 I don't. They're trying to make if you install it yourself, it'll
 work look like they're actually doing anything at all. But they're
 not, because the same applies already to Vorbis and Theora. If
 anything, they're just offering not to deliberately stop it from
 working.

 It is quite significant: before that announcement, H.264 was to be the
 only codec supported in video tags in IE9.⁰ Microsoft aren't
 intending to allow video to use system codecs generally for a bunch
 of reasons¹ (probably most notably around security), which has ruled
 native Theora in IE9 out for now.

 Adam

 ⁰ http://blogs.msdn.com/ie/archive/2010/04/29/html5-video.aspx
 ¹ 
 http://blogs.msdn.com/ie/archive/2010/05/03/follow-up-on-html5-video-in-ie9.aspx


Add to that the announcement that Adobe will ship VP8 in Flash and you
can get a huge installed base of the codec in no time flat - hopefully
it will somehow be possible to access the installed codec library from
IE9  - bingo!

Silvia.

Re: [whatwg] Speech input element

2010-05-20 Thread Bjorn Bringert

On Thu, May 20, 2010 at 1:32 PM, Anne van Kesteren ann...@opera.com wrote:
 On Thu, 20 May 2010 14:29:16 +0200, Bjorn Bringert bring...@google.com
 wrote:

 It should be possible to drive input type=speech with keyboard
 input, if the user agent chooses to implement that. Nothing in the API
 should require the user to actually speak. I think this is a strong
 argument for why input type=speech should not be replaced by a
 microphone API and a separate speech recognizer, since the latter
 would be very hard to make accessible. (I still think that there
 should be a microphone API for applications like audio chat, but
 that's a separate discussion).

 So why not implement speech support on top of the existing input types?

Speech-driven keyboards certainly get you some of the benefits of
input type=speech, but they give the application developer less
control and less information than a speech-specific API. Some
advantages of a dedicated speech input type:

- Application-defined grammars. This is important for getting high
recognition accuracy in with limited domains.

- Allows continuous speech recognition where the app gets events on
speech endpoints.

- Multiple recognition hypotheses. This lets applications implement
intelligent input disambiguation.

- Doesn't require the input element to have keyboard focus while speaking.

- Doesn't require a visible text input field.

-- 
Bjorn Bringert
Google UK Limited, Registered Office: Belgrave House, 76 Buckingham
Palace Road, London, SW1W 9TQ
Registered in England Number: 3977902

Re: [whatwg] Video with MIME type application/octet-stream


On Thu, 20 May 2010 12:46:16 +0200, Simon Pieters sim...@opera.com wrote:

On Thu, 20 May 2010 12:36:36 +0200, Simon Pieters sim...@opera.com  
wrote:


On Thu, 20 May 2010 11:55:01 +0200, Robert O'Callahan  
rob...@ocallahan.org wrote:


I just became aware that application/octet-stream is excluded from  
being a

type the user agent knows it cannot render.
http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#a-type-that-the-user-agent-knows-it-cannot-render


Apparently this was done in response to:

http://lists.w3.org/Archives/Public/public-html/2009Jul/0888.html
http://html5.org/tools/web-apps-tracker?from=3497to=3498

--
Simon Pieters
Opera Software

Re: [whatwg] Video with MIME type application/octet-stream

2010-05-20 Thread Boris Zbarsky


On 5/20/10 5:59 AM, Robert O'Callahan wrote:

Hmm. I guess it doesn't add any implementation requirements beyond what
you need to handle the complete absence of a Content-Type (which we
currently don't handle, but I suppose we should).


For what it's worth, the above-necko layer in Gecko never sees absence 
of a Content-Type.  If there isn't one, necko will sniff, period.  Of 
course that sniffing knows nothing about video at the moment, and will 
likely just detect it as application/octet-stream (modulo the 
extension-sniffing bits).


-Boris

Re: [whatwg] Speech input element

2010-05-20 Thread bjartur

 
On Thu, 20 May 2010 14:18:56 +0100, Bjorn Bringert bring...@google.com wrote:
 On Thu, May 20, 2010 at 1:32 PM, Anne van Kesteren ann...@opera.com wrote:
  On Thu, 20 May 2010 14:29:16 +0200, Bjorn Bringert bring...@google.com
 
  It should be possible to drive input type=speech with keyboard
  input, if the user agent chooses to implement that. Nothing in the API
  should require the user to actually speak. I think this is a strong
  argument for why input type=speech should not be replaced by a
  microphone API and a separate speech recognizer, since the latter
  would be very hard to make accessible. (I still think that there
  should be a microphone API for applications like audio chat, but
  that's a separate discussion).
 
  So why not implement speech support on top of the existing input types?

  Speech-driven keyboards certainly get you some of the benefits of
 input type=speech, but they give the application developer less
 control and less information than a speech-specific API. Some
 advantages of a dedicated speech input type:
It's more important that users have control (e.g. on whether they want
to input text by voice or typing) than devs. Devs don't know the needs
of every single user of their forms.

Also, I don't see any new speech-specific 
 - Application-defined grammars. This is important for getting high
 recognition accuracy in with limited domains.
This may be true, but does this require a new type? I really don't know.
 - Allows continuous speech recognition where the app gets events on
 speech endpoints.
Please describe how exactly this is different from continuous text input.
 - Doesn't require the input element to have keyboard focus while speaking.
Neither does input type=text if the user chooses to input text into 
it
with voice. It requires microphone focus (termed activated in draft).
Anything else is a usibility issue in the app, not in the form spec.
 - Doesn't require a visible text input field.
HTML does not (or at least shouldn't) define how elements will be 
presented.
In especial; it does not mandate a visual interface if the user doesn't want
one. See also: CSS.

Also the spec clearly states that The user can click the element to 
move
back to the not activated state. So the draft suggests a visible input element,
assuming that this was an informal note and not a requirement.

From the draft on 
http://docs.google.com/Doc?docid=0AaYxrITemjbxZGNmZzc5cHpfM2Ryajc5Zmhxhl=en:
 Web search by voice
 Speech translation
input type=text for client-side recognition, input type=audio for 
server-side.
 Speech-enabled webmail client
Commandline interface with pronounceable commands (as is recommended for 
commandline
interfaces in generl anyway.
 VoiceXML interpreter
I don't see how XML interpreters relate to speech-based HTML forms.
Or my definition of interpreter doesn't match yours (I don't write English 
natively).

--- code sample from draft ---
html
script type=text/javascript
function startSearch(event) {
Â  var query = event.target.value;
Â Â document.getElementById(q).value = query;
Â Â // use AJAX search API to get results forÂ 
Â Â // q.value and put in #search_results.
}
/scriptbody

form name=search_form
input type=text name=q id=q
input type=speech grammar=builtin:search onchange=startSearch
/form

div id=search_results/div

/body/html
--- end of code sample ---
How is listening for changes on one element and moving them to another element
and then submitting the form better than e.g.
--- code sample ---
html
!-- tell browser that form is a search box --
link rel=search href=#search 
body
form id=search !-- or name=search --
input type=search name=q id=q
/form
/body
/html
--- end of code sample ---
Works sans scripting, scripted submit can be used if scripting is supported.
I'd understand it if it linked to some SRGS stuff, but it doesn't.
Also it brakes the @type attribute of input so you had to add /another/
attribute to tell browsers what type of information is expected to input
into the input. Speech isn't a type of information. It's a way to input
information.

Really, you should be using CSS and JavaScript if your want
fine-grained control over the user-interaction (for human users that'll
use the form). Feel free to add speech recognition capabilites to
JavaScript and improve CSS styling of voice media.

If you wanted to integrate HTML forms and SRGS, that shouldn't brake input
type.

Re: [whatwg] Video with MIME type application/octet-stream

2010-05-20 Thread David Singer

Did anyone revise the registration of application/octet-stream to add 
parameters?

On May 20, 2010, at 3:36 , Simon Pieters wrote:

 On Thu, 20 May 2010 11:55:01 +0200, Robert O'Callahan rob...@ocallahan.org 
 wrote:
 
 I just became aware that application/octet-stream is excluded from being a
 type the user agent knows it cannot render.
 http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#a-type-that-the-user-agent-knows-it-cannot-render
 Apparently this was done in response to a bug report:
 http://www.w3.org/Bugs/Public/show_bug.cgi?id=7977
 Neither the bug report nor the editor's response give any indication why
 this change was made.
 
 This bug report was about application/octet-stream *with parameters*, e.g. 
 application/octet-stream; codecs=theora, vorbis. The spec had the 
 requirement about application/octet-stream before that bug report.
 
 
 This change means files served with application/octet-stream will make it
 all the way to the step If the media
 datahttp://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#media-datacan
 be fetched but is found by inspection to be in an unsupported format
 ..., so implementations have to add support for binary sniffing for all the
 types they support. We didn't need this before in Gecko. What was the
 motivation for adding this implementation requirement?
 
 Thanks,
 Rob
 
 
 -- 
 Simon Pieters
 Opera Software

David Singer
Multimedia and Software Standards, Apple Inc.

Re: [whatwg] forwarded: Google opens VP8 video codec

2010-05-20 Thread David Singer


On May 19, 2010, at 21:48 , Sir Gallantmon (ニール・ゴンパ) wrote:
 
 Google's patent license states that anyone that attempts to sue over VP8 will 
 automatically lose their patent license. That's a huge deterrent.

only to potential practitioners...not trolls :-( (i.e. non-practicing patent 
owners)

 AFAIR, the VC-1 codec didn't have that kind of clause, which caused the 
 debacle that led to the VC-1 patent pool...

I don't recall, but I would be surprised.  This is a pretty common defensive 
clause.

David Singer
Multimedia and Software Standards, Apple Inc.

Re: [whatwg] Video with MIME type application/octet-stream


On Thu, 20 May 2010 18:44:12 +0200, David Singer sin...@apple.com wrote:

Did anyone revise the registration of application/octet-stream to add  
parameters?


No. It's just error handling.

--
Simon Pieters
Opera Software

Re: [whatwg] Video with MIME type application/octet-stream

2010-05-20 Thread David Singer

It's an error to have a parameter that isn't valid for the mime type, so are 
you suggesting (a) that you throw away the parameter as it's invalid or (b) 
since it's an error to supply application/octet-stream as the mime type in the 
first place, we may as well process its invalid parameter in an attempt to 
recover?

On May 20, 2010, at 10:27 , Simon Pieters wrote:

 On Thu, 20 May 2010 18:44:12 +0200, David Singer sin...@apple.com wrote:
 
 Did anyone revise the registration of application/octet-stream to add 
 parameters?
 
 No. It's just error handling.
 
 -- 
 Simon Pieters
 Opera Software

David Singer
Multimedia and Software Standards, Apple Inc.

Re: [whatwg] Video with MIME type application/octet-stream


On Thu, 20 May 2010 20:18:43 +0200, David Singer sin...@apple.com wrote:

It's an error to have a parameter that isn't valid for the mime type, so  
are you suggesting (a) that you throw away the parameter as it's invalid  
or (b) since it's an error to supply application/octet-stream as the  
mime type in the first place, we may as well process its invalid  
parameter in an attempt to recover?


I'm just suggesting that it should be defined what to do when you get  
application/octet-stream with parameters. I don't care which handling that  
is, or whether it's valid or why the specific handling was chosen.


--
Simon Pieters
Opera Software

Re: [whatwg] Image resize API proposal


On May 11, 2010, at 11:58 AM, Sterling Swigart wrote:

 I'm working with David Levin, and based on the feedback received regarding 
 offscreen canvas, the proposal has been changed to address more specific 
 scenarios. The main use case was resizing images, so we are proposing an 
 asynchronous image resizing API. If you are curious about how we arrived at 
 our API below, take a look at the appendix to view the alternatives we 
 considered.

I'm not clear on why this API is needed. Mozilla's feedback on the offscreen 
canvas proposal was that image resizing is plenty fast enough with no new API, 
if you use something like Direct2D to accelerate it, using only current Canvas 
APIs. This API seems much less general than offscreen canvas, so it's subject 
to the same criticism and you can't even make the argument that it also serves 
other use cases.

Regards,
Maciej

 
 Let us know what you think. Thanks!
 Sterling
 
 Use Cases:
 
 
 Begin with a user giving a local image file to a webpage. Then:
 
 
 1. In real-time chat, quickly give other users a thumbnail view of the image 
 file.
 
 2. Or, limit the size of an image file before uploading it to a web server.
 
 
 Proposed Solution:
 
 
 We propose adding image.getBlob. getBlob will be an instance function of the 
 javascript Image object which asynchronously gets a blob of the image, 
 resized to the given width and height, encoded into jpeg or png. The function 
 declaration will be:
 
 
 getBlob(mimeType /* req */, width /* req */, height /* req */, successEvent 
 /* req */, errorEvent /* op */, qualityLevel /* op */, preserveAspectRatio /* 
 op */, rotateExif /* op */);
 
 
 The blob will be passed as an argument to the success callback function, or 
 upon error, error data will be passed into the error callback function as an 
 argument. Quality level should be between 0.0 and 1.0, and any value outside 
 of that range will be reverted to the default, 0.85. If MIME type does not 
 equal image/jpeg, then quality level is ignored. If null (or a negative 
 value) is passed in for the width or height, then the function will use the 
 source's measurement for that dimension. Default values for 
 preserveAspectRatio and rotateExif are true.
 
 All EXIF metadata will be retained except for any saved thumbnails, and the 
 EXIF rotation property will be appropriately modified.
 
 Security:
 
 
 If the image source is of a different origin than the script context, then 
 getBlob raises a SECURITY_ERR exception.
 
 
 Sample Code:
 
 
 // url contains location of an image file
 
 Image i = new Image();
 
 i.src = url;
 
 
 var successEvt = function (newBlob) { myDiv.innerHTML += img src=' + 
 newBlob.url + ' /; };
 
 var errEvt = function (err) { alert(err); };
 
 i.getBlob(image/jpeg, 300, 350, successEvt, errEvt, .55);
 
 // Image will retain aspect ratio and correct for EXIF rotation. If the 
 source image was 700x700,
 
 //   the blob will represent a new image that is 300x300.
 
 
 
 That's all!
 
 Appendix: Alternatives considered 
 
 For reference, we've also included a list of other designs that we thought of 
 along with the reasons why they were dropped
 
 
 Creating a new object for resizing
 
 Summary of approach: 
 
 [NamedConstructor=ImageResizer(),
 
  NamedConstructor=ImageResizer(blob, onsuccess),
 
  NamedConstructor=ImageResizer(blob, onsuccess, onerror),
 
  NamedConstructor=ImageResizer(blob, onsuccess, onerror, type),
 
  NamedConstructor=ImageResizer(blob, onsuccess, onerror, type, width, height)]
 
 
 interface ImageResizer {
 
 void start(); // starts resize operation
 
 void abort(); // aborts operation
 
 
 
 attribute Blob blob;
 
 attribute DOMString type; // default image/png
 
 attribute unsigned long width; 
 
 
 attribute unsigned long height; 
 
 attribute float qualityLevel; // default 1.0, must be 0.0 to 1.0, else 
 reverts to default
 
 
 
 readonly attribute unsigned short started; // default 0
 
 
 attribute Function onsuccess;
 
 attribute Function onerror;
 
 };
 
 
 Why it wasn't chosen:
 
 Creating an entirely new object for this task made the task seem more 
 complicated and involved than necessary, and this problem could be solved via 
 modifications to the Image object.
 
 
 
 Returning a SizelessBlob immediately from a method on image
 
 Summary of approach: 
 
 var streamingBlob = image.toStreamingBlob(mimeType /* req */, width /* req 
 */, height /* req */, qualityLevel /* op */, preserveAspectRatio /* op */, 
 rotateExif /* op */);
 
 
 
 New Blob Interfaces:
 
 interface SizelessBlob {
 
// moved from Blob
 
   readonly attribute DOMString type;
 
   readonly attribute DOMString url; // whatever name -- URL, urn, URN, 
 etc.
 
 }
 
 
 interface StreamingBlob : SizelessBlob {
 
  // at most one of the following functions will be called 
 for a single FutureBlob
 
  attribute Function onblobready;

Re: [whatwg] Image resize API proposal

2010-05-20 Thread David Levin

On Thu, May 20, 2010 at 11:30 AM, Maciej Stachowiak m...@apple.com wrote:

 I'm not clear on why this API is needed. ... This API seems much less
general than offscreen canvas, so it's subject to the same criticism and you
can't even make the argument that it also serves other use cases.

The criticism for the OffscreenCanvas was
1. it made the core use case of image resizing rather complicated and
2. depending on the browser's implementation, there may be faster ways to do
the image resizing than doing it on a worker.

The net suggestion that This supports the idea of specialized API... --
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-March/025590.html

This is exactly what we are doing (and it addresses those criticisms).

Thanks,
dave

Re: [whatwg] Video with MIME type application/octet-stream

On Fri, May 21, 2010 at 2:00 AM, Boris Zbarsky bzbar...@mit.edu wrote:

 On 5/20/10 5:59 AM, Robert O'Callahan wrote:

 Hmm. I guess it doesn't add any implementation requirements beyond what
 you need to handle the complete absence of a Content-Type (which we
 currently don't handle, but I suppose we should).


 For what it's worth, the above-necko layer in Gecko never sees absence of
 a Content-Type.  If there isn't one, necko will sniff, period.  Of course
 that sniffing knows nothing about video at the moment, and will likely just
 detect it as application/octet-stream (modulo the extension-sniffing bits).


Ah, right. Thanks.

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] Image resize API proposal


On May 20, 2010, at 1:00 PM, David Levin wrote:

 
 
 On Thu, May 20, 2010 at 11:30 AM, Maciej Stachowiak m...@apple.com wrote:
 
  I'm not clear on why this API is needed. ... This API seems much less 
  general than offscreen canvas, so it's subject to the same criticism and 
  you can't even make the argument that it also serves other use cases.
 
 The criticism for the OffscreenCanvas was 
 1. it made the core use case of image resizing rather complicated and
 2. depending on the browser's implementation, there may be faster ways to do 
 the image resizing than doing it on a worker.
 
 The net suggestion that This supports the idea of specialized API... -- 
 http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-March/025590.html
 
 This is exactly what we are doing (and it addresses those criticisms).


Is the purpose of this API performance or convenience?

It seems like the proposed API is so specialized that it's only really useful 
to resize an image immediately before transferring it over the network in some 
way. Is that really so much more common than any other resizing that it needs a 
specialized convenience API?

Regards,
Maciej

Re: [whatwg] Image resize API proposal


On May 20, 2010, at 5:48 PM, Maciej Stachowiak wrote:

 
 On May 20, 2010, at 1:00 PM, David Levin wrote:
 
 
 
 On Thu, May 20, 2010 at 11:30 AM, Maciej Stachowiak m...@apple.com wrote:
 
  I'm not clear on why this API is needed. ... This API seems much less 
  general than offscreen canvas, so it's subject to the same criticism and 
  you can't even make the argument that it also serves other use cases.
 
 The criticism for the OffscreenCanvas was 
 1. it made the core use case of image resizing rather complicated and
 2. depending on the browser's implementation, there may be faster ways to do 
 the image resizing than doing it on a worker.
 
 The net suggestion that This supports the idea of specialized API... -- 
 http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-March/025590.html
 
 This is exactly what we are doing (and it addresses those criticisms).
 
 
 Is the purpose of this API performance or convenience?
 
 It seems like the proposed API is so specialized that it's only really useful 
 to resize an image immediately before transferring it over the network in 
 some way. Is that really so much more common than any other resizing that it 
 needs a specialized convenience API?

Another thought - should the return type here be an ArrayBuffer instead of a 
Blob? There doesn't seem to be a reason to hide the actual binary data behind 
an asynchronous interface.

I'd also love to hear from Mike Shaver and others from the original thread what 
they think of this API proposal.

Regars,
Maciej

Re: [whatwg] Image resize API proposal

On Fri, May 21, 2010 at 12:50 PM, Maciej Stachowiak m...@apple.com wrote:

 I'd also love to hear from Mike Shaver and others from the original thread
 what they think of this API proposal.


I think Shaver's feedback still applies: on any device with a GPU, we can
optimize canvas and/or rendering enough that scaling images is no problem on
the main thread. So this API would have a short useful lifetime ... possibly
negative.

Coming thread full circle, I now think there are good use cases for
off-main-thread canvas, in particular with WebGL, but I guess that deserves
its own thread again :-).

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] Image resize API proposal


On May 20, 2010, at 6:24 PM, Robert O'Callahan wrote:

 On Fri, May 21, 2010 at 12:50 PM, Maciej Stachowiak m...@apple.com wrote:
 I'd also love to hear from Mike Shaver and others from the original thread 
 what they think of this API proposal.
  
 I think Shaver's feedback still applies: on any device with a GPU, we can 
 optimize canvas and/or rendering enough that scaling images is no problem on 
 the main thread. So this API would have a short useful lifetime ... possibly 
 negative.
 
 Coming thread full circle, I now think there are good use cases for 
 off-main-thread canvas, in particular with WebGL, but I guess that deserves 
 its own thread again :-).

As far as I can tell, the proposed API doesn't enable resizing off the main 
thread. It is an API on HTMLImageElement so you can't call it from a worker. 
And it returns synchronously so the main thread has to block until the resize 
is done regardless. It returns a Blob, so I suppose it may be possible that the 
intent is to make a magical blob that's actually backed by a background thread 
asynchronous computation instead of data. That wasn't clear to me from the 
proposal. It would be a little weird.

Regards,
Maciej

Re: [whatwg] Image resize API proposal

2010-05-20 Thread David Levin

On Thu, May 20, 2010 at 7:55 PM, Maciej Stachowiak m...@apple.com wrote:


 On May 20, 2010, at 6:24 PM, Robert O'Callahan wrote:

 On Fri, May 21, 2010 at 12:50 PM, Maciej Stachowiak m...@apple.com wrote:

 I'd also love to hear from Mike Shaver and others from the original thread
 what they think of this API proposal.


 I think Shaver's feedback still applies: on any device with a GPU, we can
 optimize canvas and/or rendering enough that scaling images is no problem on
 the main thread. So this API would have a short useful lifetime ... possibly
 negative.

 Coming thread full circle, I now think there are good use cases for
 off-main-thread canvas, in particular with WebGL, but I guess that deserves
 its own thread again :-).


 As far as I can tell, the proposed API doesn't enable resizing off the main
 thread. It is an API on HTMLImageElement so you can't call it from a worker.
 And it returns synchronously so the main thread has to block until the
 resize is done regardless. It returns a Blob, so I suppose it may be
 possible that the intent is to make a magical blob that's actually backed by
 a background thread asynchronous computation instead of data. That wasn't
 clear to me from the proposal. It would be a little weird.


The proposed api has a callback for the blob, so it is totally async. We
attempted to return the blob sync (and do everything hidden in the
background), but blob.size wouldn't be known (so it would need to throw or
block, etc.)

Sample code from the proposal:

var successEvt = function (newBlob) { myDiv.innerHTML += img src=' +
newBlob.url + ' /; };

i.getBlob(image/jpeg, 300, 350, successEvt);


dave



 Regards,
 Maciej

Re: [whatwg] Image resize API proposal