Re: [whatwg] Inconsistent behavior for empty-string URLs

[Jonas Sicking]

On Tue, Dec 15, 2009 at 5:51 PM, Aryeh Gregor  wrote:
> On Tue, Dec 15, 2009 at 8:21 PM, Jonas Sicking  wrote:
>> For example not all s are automatically downloaded, such as
>> . However I suspect that we'll want all s to
>> behave the same.
>
> I'd say the rule should be that if the type is text/html or unknown,
> "" should work.

Interesting. I don't think we want to base it on the type attribute,
since that should generally be possible to leave out. But I can
certainly see a use for .

So maybe just apply the don't-download rule rel=stylesheet (and
rel="stylesheet alternate" etc).

/ Jonas

Re: [whatwg] Inconsistent behavior for empty-string URLs

[Mike Taylor]

Shouldn't this proposal take into account the CSS3 content property? (
http://www.w3.org/TR/css3-content/)

 E.g., figure[alt] { content: attr(href, url), attr(alt); }


This was discussed not too long ago, starting in this thread:
Adding a src attribute to all elements (
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-November/023955.html
)

-Mike

On Tue, Dec 15, 2009 at 8:37 PM, Nicholas Zakas wrote:

> Yes, that sounds right.
>
> -Nicholas
>
> __
> Commander Lock: "Damnit Morpheus, not everyone believes what you
> believe!"
> Morpheus: "My beliefs do not require them to."
>
> -Original Message-
> From: Jonas Sicking [mailto:jo...@sicking.cc]
> Sent: Tuesday, December 15, 2009 5:22 PM
> To: Nicholas Zakas
> Cc: Maciej Stachowiak; whatwg@lists.whatwg.org; Aryeh Gregor; Simon
> Pieters
> Subject: Re: [whatwg] Inconsistent behavior for empty-string URLs
>
> On Tue, Dec 15, 2009 at 4:11 PM, Nicholas Zakas 
> wrote:
> > Here's what I would propose:
> >
> > 1. Empty string attributes for HTML elements specifying resources to
> > automatically download are considered invalid and don't cause a
> request
> > to be sent. Examples: , , 

Re: [whatwg] Inconsistent behavior for empty-string URLs

[Aryeh Gregor]

On Tue, Dec 15, 2009 at 8:21 PM, Jonas Sicking  wrote:
> For example not all s are automatically downloaded, such as
> . However I suspect that we'll want all s to
> behave the same.

I'd say the rule should be that if the type is text/html or unknown,
"" should work.  If it's known to be some other type, like text/css,
then it should fail.  Alternatively, it should work for everything
that doesn't actually fetch a resource automatically.  After all, the
rationale for this whole change is that "" as a source for images and
such 1) makes no sense and is almost certainly an authoring mistake,
and 2) causes extra HTTP requests -- but neither is true for all
s.  For instance,  makes perfect sense
and causes no extra requests, so I don't think it should be
prohibited.

Re: [whatwg] Inconsistent behavior for empty-string URLs

[Nicholas Zakas]

Yes, that sounds right.

-Nicholas
 
__
Commander Lock: "Damnit Morpheus, not everyone believes what you
believe!"
Morpheus: "My beliefs do not require them to."

-Original Message-
From: Jonas Sicking [mailto:jo...@sicking.cc] 
Sent: Tuesday, December 15, 2009 5:22 PM
To: Nicholas Zakas
Cc: Maciej Stachowiak; whatwg@lists.whatwg.org; Aryeh Gregor; Simon
Pieters
Subject: Re: [whatwg] Inconsistent behavior for empty-string URLs

On Tue, Dec 15, 2009 at 4:11 PM, Nicholas Zakas 
wrote:
> Here's what I would propose:
>
> 1. Empty string attributes for HTML elements specifying resources to
> automatically download are considered invalid and don't cause a
request
> to be sent. Examples: , , 

Re: [whatwg] Inconsistent behavior for empty-string URLs

[Jonas Sicking]

On Tue, Dec 15, 2009 at 4:11 PM, Nicholas Zakas  wrote:
> Here's what I would propose:
>
> 1. Empty string attributes for HTML elements specifying resources to
> automatically download are considered invalid and don't cause a request
> to be sent. Examples: , , 

Re: [whatwg] Web API for speech recognition and synthesis

[Tran, Dzung D]

Currently the W3C Device API WG is working on a Capture API which will include 
microphone capture and audio streaming capabilities. The current draft is at: 
http://dev.w3.org/2009/dap/camera/

It is pretty rough and still in working progress, so for instance streaming is 
not there.

Thanks
Dzung Tran

On Sun, Dec 13, 2009 at 6:46 PM, Ian McGraw 
mailto:imcg...@mit.edu>> wrote:
> I'm new to this list, but as a speech-scientist and web developer, I wanted
> to add my 2 cents. ?Personally, I believe the future of speech recognition
> is in the cloud.
> Here are two services which provide Javascript APIs for speech recognition
> (and TTS) today:
> http://wami.csail.mit.edu/
> http://www.research.att.com/projects/SpeechMashup/index.html
> Both of these are research systems, and as such they are really just
> proof-of-concepts.
> That said, Wami's JSONP-like implementation allows Quizlet.com to use speech
> recognition today on a relatively large scale, with just a few lines of
> Javascript code:
> http://quizlet.com/voicetest/415/?scatter
> Since there are a lot of Google folks on this list, I recommend you talk to
> Alex Gruenstein (in your speech group) who was one of the lead developers of
> WAMI while at MIT.
> The major limitation we found when building the system was that we had to
> develop a new audio controller for every client (Java for the desktop,
> custom browsers for iPhone and Android). ?It would have been much simpler if
> browsers came with standard microphone capture and audio streaming
> capabilities.
> -Ian
>

Re: [whatwg] Inconsistent behavior for empty-string URLs

[Nicholas Zakas]

Here's what I would propose:

1. Empty string attributes for HTML elements specifying resources to
automatically download are considered invalid and don't cause a request
to be sent. Examples: , , 

Re: [whatwg] Web API for speech recognition and synthesis

[Ian McGraw]

Great!  As I've said, I'm definitely bias towards this approach.  As Bjorn
hinted AJAX APIs could be developed with all sorts of interesting features
that will never make it down into the browser, e.g. pronunciation
assessment, speech therapy, all those lie-detector apps for your phone :-).
Still, I think that we're missing the biggest pro:

- Pro:  Speech recognition technology is data-driven.  Improvements in the
underlying technology are far more likely to occur with a network driven
approach.

To be fair, with that, you have to add a con:

- Con:  Less privacy.

-Ian

On Tue, Dec 15, 2009 at 3:37 PM, Ian Hickson  wrote:

> On Tue, 15 Dec 2009, Bjorn Bringert wrote:
> >
> > - A general microphone API + streaming API + audio tag
> >   - Pro: Useful for non-speech recognition / synthesis applications.
> >E.g. audio chat, sound recording.
> >   - Pro: Allows JavaScript libraries for third-party network speech
> services.
> >E.g. an AJAX API for Google's speech services. Web app
> developers
> >that don't have their own speech servers could use that.
> >   - Pro: Consistent recognition / synthesis user experience across
> > user agents in the same web app.
> >   - Con: No support for on-device recognition / synthesis, only
> > network services.
> >   - Con: Varying recognition / synthesis user experience across
> > different web apps in a single user agent.
> >   - Con: Possibly higher overhead because the audio data needs to
> > pass through JavaScript.
> >   - Con: Requires dealing with audio encodings, endpointing, buffer
> > sizes etc in the microphone API.
>
> FWIW I've started looking at this kind of thing in general (for audio and
> video -- see  in the spec for the first draft ideas), since it'll
> be required for other things as well. However, that shouldn't be taken as
> a sign that the other approach shouldn't also be examined.
>
> --
> Ian Hickson   U+1047E)\._.,--,'``.fL
> http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>

Re: [whatwg] Web API for speech recognition and synthesis

[Ian Hickson]

On Tue, 15 Dec 2009, Bjorn Bringert wrote:
> 
> - A general microphone API + streaming API + audio tag
>   - Pro: Useful for non-speech recognition / synthesis applications.
>E.g. audio chat, sound recording.
>   - Pro: Allows JavaScript libraries for third-party network speech services.
>E.g. an AJAX API for Google's speech services. Web app developers
>that don't have their own speech servers could use that.
>   - Pro: Consistent recognition / synthesis user experience across
> user agents in the same web app.
>   - Con: No support for on-device recognition / synthesis, only
> network services.
>   - Con: Varying recognition / synthesis user experience across
> different web apps in a single user agent.
>   - Con: Possibly higher overhead because the audio data needs to
> pass through JavaScript.
>   - Con: Requires dealing with audio encodings, endpointing, buffer
> sizes etc in the microphone API.

FWIW I've started looking at this kind of thing in general (for audio and 
video -- see  in the spec for the first draft ideas), since it'll 
be required for other things as well. However, that shouldn't be taken as 
a sign that the other approach shouldn't also be examined.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Web API for speech recognition and synthesis

[Bjorn Bringert]

It seems like there is enough interest in speech to start developing
experimental implementations. There appear to be two general
directions that we could take:

- A general microphone API + streaming API + audio tag
  - Pro: Useful for non-speech recognition / synthesis applications.
   E.g. audio chat, sound recording.
  - Pro: Allows JavaScript libraries for third-party network speech services.
   E.g. an AJAX API for Google's speech services. Web app developers
   that don't have their own speech servers could use that.
  - Pro: Consistent recognition / synthesis user experience across
user agents in the same web app.
  - Con: No support for on-device recognition / synthesis, only
network services.
  - Con: Varying recognition / synthesis user experience across
different web apps in a single user agent.
  - Con: Possibly higher overhead because the audio data needs to
pass through JavaScript.
  - Con: Requires dealing with audio encodings, endpointing, buffer
sizes etc in the microphone API.

- A speech-specific back-end neutral API
  - Pro: Simple API, basically just two methods: listen() and speak().
  - Pro: Can use local recognition / synthesis.
  - Pro: Consistent recognition / synthesis user experience across
   different web apps in a single user agent.
  - Con: Varying recognition / synthesis user experience across user
agents in the same web app.
  - Con: Only works for speech, not general audio.

/Bjorn

On Sun, Dec 13, 2009 at 6:46 PM, Ian McGraw  wrote:
> I'm new to this list, but as a speech-scientist and web developer, I wanted
> to add my 2 cents.  Personally, I believe the future of speech recognition
> is in the cloud.
> Here are two services which provide Javascript APIs for speech recognition
> (and TTS) today:
> http://wami.csail.mit.edu/
> http://www.research.att.com/projects/SpeechMashup/index.html
> Both of these are research systems, and as such they are really just
> proof-of-concepts.
> That said, Wami's JSONP-like implementation allows Quizlet.com to use speech
> recognition today on a relatively large scale, with just a few lines of
> Javascript code:
> http://quizlet.com/voicetest/415/?scatter
> Since there are a lot of Google folks on this list, I recommend you talk to
> Alex Gruenstein (in your speech group) who was one of the lead developers of
> WAMI while at MIT.
> The major limitation we found when building the system was that we had to
> develop a new audio controller for every client (Java for the desktop,
> custom browsers for iPhone and Android).  It would have been much simpler if
> browsers came with standard microphone capture and audio streaming
> capabilities.
> -Ian
>
>
> On Sun, Dec 13, 2009 at 12:07 PM, Weston Ruter 
> wrote:
>>
>> I blogged yesterday about this topic (including a text-to-speech demo
>> using HTML5 Audio and Google Translate's TTS service); the more relevant
>> part for this thread:
>>
>>> I am really excited at the prospect of text-to-speech being made
>>> available on
>>> the Web! It's just too bad that fetching MP3s on an remote web service is
>>> the
>>> only standard way of doing so currently; modern operating systems all
>>> have TTS
>>> capabilities, so it's a shame that web apps and can't utilize them via
>>> client-side scripting. I posted to the WHATWG mailing list about such a
>>> Text-To-Speech (TTS) Web API for JavaScript, and I was directed to a
>>> recent
>>> thread about a Web API for speech recognition and synthesis.
>>>
>>> Perhaps there is some momentum building here? Having TTS available in the
>>> browser would boost accessibility for the seeing-impaired and improve
>>> usability
>>> for people on-the-go. TTS is just another technology that has
>>> traditionally been
>>> relegated to desktop applications, but as the open Web advances as the
>>> preferred
>>> platform for application development, it is an essential service to make
>>> available (as with Geolocation API, Device API, etc.). And besides, I
>>> want to
>>> build TTS applications and my motto is: "If it can't be done on the open
>>> web,
>>> it's not worth doing at all"!
>>
>> http://weston.ruter.net/projects/google-tts/
>>
>> Weston
>>
>> On Fri, Dec 11, 2009 at 1:35 PM, Weston Ruter 
>> wrote:
>>>
>>> I was just alerted about this thread from my post "Text-To-Speech (TTS)
>>> Web API for JavaScript" at
>>> .
>>> Amazing how shared ideas like these seem to arise independently at the same
>>> time.
>>>
>>> I have a use-case and an additional requirement, that the time indices be
>>> made available for when each word is spoken in the TTS-generated audio:
>>>
 I've been working on a web app which reads text in a web page,
 highlighting each word as it is read. For this to be possible, a
 Text-To-Speech API is needed which is able to:
 (1) generate the speech audio 

Re: [whatwg] Inconsistent behavior for empty-string URLs

[Jonas Sicking]

On Tue, Dec 15, 2009 at 11:14 AM, Nicholas Zakas  wrote:
> Is it necessary to apply this within XSLT and CSS as well? Or is it
> possible to have this be an HTML-only feature? I'd be happy with the
> latter.

Nothing is required. But we do need a concrete proposal that everyone agrees on.

/ Jonas

Re: [whatwg] Inconsistent behavior for empty-string URLs

[Nicholas Zakas]

Is it necessary to apply this within XSLT and CSS as well? Or is it
possible to have this be an HTML-only feature? I'd be happy with the
latter.

-Nicholas
 
__
Commander Lock: "Damnit Morpheus, not everyone believes what you
believe!"
Morpheus: "My beliefs do not require them to."

-Original Message-
From: Jonas Sicking [mailto:jo...@sicking.cc] 
Sent: Tuesday, December 15, 2009 9:37 AM
To: Maciej Stachowiak
Cc: Nicholas Zakas; whatwg@lists.whatwg.org; Aryeh Gregor; Simon Pieters
Subject: Re: [whatwg] Inconsistent behavior for empty-string URLs

On Tue, Dec 15, 2009 at 1:44 AM, Maciej Stachowiak 
wrote:
> Does anyone have data on what, if any, compatibility impact this has?
I
> can't imagine loading the base URL to be terribly useful in most
cases, but
> perhaps there are wacky sites that do indeed rely on it.

Given that opera has this somewhat deployed, would be interesting to
hear if they have had any compatibility issues.

The one place where I've seen this used is inside XSLT stylesheets,
where i've seen something like:



to read data out of the stylesheet document.

/ Jonas

Re: [whatwg] Inconsistent behavior for empty-string URLs

[Aryeh Gregor]

On Tue, Dec 15, 2009 at 12:33 PM, Jonas Sicking  wrote:
> I think "#" should work as well.

Good point.

Re: [whatwg] Inconsistent behavior for empty-string URLs

[Jonas Sicking]

On Tue, Dec 15, 2009 at 1:44 AM, Maciej Stachowiak  wrote:
> Does anyone have data on what, if any, compatibility impact this has? I
> can't imagine loading the base URL to be terribly useful in most cases, but
> perhaps there are wacky sites that do indeed rely on it.

Given that opera has this somewhat deployed, would be interesting to
hear if they have had any compatibility issues.

The one place where I've seen this used is inside XSLT stylesheets,
where i've seen something like:



to read data out of the stylesheet document.

/ Jonas

Re: [whatwg] Inconsistent behavior for empty-string URLs

[Jonas Sicking]

On Tue, Dec 15, 2009 at 6:55 AM, Aryeh Gregor  wrote:
> On Tue, Dec 15, 2009 at 6:16 AM, James May  wrote:
>> If this change is made, what is the correct (explicit) way to refer to the
>> current URL? "." ?
>
> No, that will return the file in the current directory named ".".
> This might be the current directory itself.  You would have to say
> "foo.html" or such.  This shouldn't be a big deal, given how crazy
> you'd have to be to use the same URL for an HTML file and an image (or
> whatever).

I think "#" should work as well.

/ Jonas

Re: [whatwg] Inconsistent behavior for empty-string URLs

[Aryeh Gregor]

On Tue, Dec 15, 2009 at 6:16 AM, James May  wrote:
> If this change is made, what is the correct (explicit) way to refer to the
> current URL? "." ?

No, that will return the file in the current directory named ".".
This might be the current directory itself.  You would have to say
"foo.html" or such.  This shouldn't be a big deal, given how crazy
you'd have to be to use the same URL for an HTML file and an image (or
whatever).

> In terms of web compat, I do recall a web picture gallery package that
> returned a html information page with a self reference to show the actual
> image.

How did that work?  It used a script that sniffed referers or
something crazy like that?

Re: [whatwg] Quality Values for Media Source Elements

[Aryeh Gregor]

On Tue, Dec 15, 2009 at 3:17 AM, Hugh Guiney  wrote:
> Nor should it. But if you're doing something in JavaScript, there
> *should* be a functional alternative in plain HTML when it's turned
> off.

Functional, sure, except where that's impossible (e.g., a client-side
computer game) or you have good reason not to care (e.g., intranet app
where you can require JS to be on).  It doesn't have to provide all
the same features, though.  In general that's impossible, which is why
we have script to start with.

> I don't know that nobody *wants* to do that; I think most of them
> simply don't know how.

The ones who know how, or could easily find out, still overwhelmingly
don't want to.

> I don't think it's a square wheel. A square wheel wouldn't work. HTTP
> CN works. The fact that people are willing to do something in HTML,
> but are unwilling to do the very same thing in HTTP, seems to suggest
> a lack of understanding of HTTP and/or its capabilities.

A square wheel works, as long as you're willing to do a lot more work.
 HTTP content negotiation has the following problems compared to an
HTML-based solution:

* Authors already know how to edit HTML, since they need to for
everything else.  Changing HTTP headers requires them to also know how
to configure their web server, or use a scripting language (which is
harder to learn and much less performant than static resources).  This
makes it automatically harder to learn, which is bad.
* Every web server is configured differently.  There is no standard
for configuring your server to do content negotiation (that I'm aware
of).
* Many users (e.g., on some shared hosts) don't have the ability to
reconfigure their web server, or at least not easily.
* Some web servers (e.g., lighttpd last I checked) require that the
whole web server be restarted for any config change.
* A solution in HTML will continue to work if you just copy the entire
directory to a new server.  The same is not reliably true of anything
that relies on web server configuration.

People avoid it for excellent reason.

> This is a nice interim solution, but it also forces the user to
> download a resource which may not necessarily be the most appropriate
> version for them.

Only if you use autobuffer, which you don't have to.

Re: [whatwg] Inconsistent behavior for empty-string URLs

[James May]

If this change is made, what is the correct (explicit) way to refer to the
current URL? "." ?

In terms of web compat, I do recall a web picture gallery package that
returned a html information page with a self reference to show the actual
image.

-- James

2009/12/15 Maciej Stachowiak 

>
> On Dec 14, 2009, at 11:08 AM, Nicholas Zakas wrote:
>
>  It seems that thusfar, Jonas from Mozilla is open to this change. Is
>> there anyone from Opera or WebKit that would like to chime in either in
>> favor or opposition?
>>
>
> I'd love to issue fewer useless loads, if sites don't actually rely on it.
>
> Does anyone have data on what, if any, compatibility impact this has? I
> can't imagine loading the base URL to be terribly useful in most cases, but
> perhaps there are wacky sites that do indeed rely on it.
>
> Regards,
> Maciej
>
>
>
>
>
>> Thanks.
>>
>> -Nicholas
>>
>> __
>> Commander Lock: "Damnit Morpheus, not everyone believes what you
>> believe!"
>> Morpheus: "My beliefs do not require them to."
>>
>> -Original Message-
>> From: whatwg-boun...@lists.whatwg.org
>> [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Nicholas Zakas
>> Sent: Friday, December 11, 2009 10:15 AM
>> To: Simon Pieters; Anne van Kesteren; Aryeh Gregor
>> Cc: whatwg@lists.whatwg.org
>> Subject: Re: [whatwg] Inconsistent behavior for empty-string URLs
>>
>> I agree, automatic downloads are the real issue.  is fine
>> because a user must initiate the action (and thus generate a "real"
>> pageview).
>>
>> I'd think that the behavior should be the same in CSS and SVG for
>> resources that are automatically downloaded.
>>
>> -Nicholas
>>
>> __
>> Commander Lock: "Damnit Morpheus, not everyone believes what you
>> believe!"
>> Morpheus: "My beliefs do not require them to."
>>
>> -Original Message-
>> From: Simon Pieters [mailto:sim...@opera.com]
>> Sent: Thursday, December 10, 2009 10:57 AM
>> To: Nicholas Zakas; Anne van Kesteren; Aryeh Gregor
>> Cc: whatwg@lists.whatwg.org
>> Subject: Re: [whatwg] Inconsistent behavior for empty-string URLs
>>
>> On Thu, 10 Dec 2009 19:22:43 +0100, Nicholas Zakas
>> 
>> wrote:
>>
>>  I'd be happy to make the compromise that this applies to markup but
>>>
>> not
>>
>>> to JavaScript APIs.
>>>
>>
>> I think it shouldn't apply to markup that doesn't download things
>> automatically; in particular  should work.
>>
>> What about URLs in CSS and SVG?
>>
>> --
>> Simon Pieters
>> Opera Software
>>
>
>

Re: [whatwg] Inconsistent behavior for empty-string URLs

[Maciej Stachowiak]

On Dec 14, 2009, at 11:08 AM, Nicholas Zakas wrote:


It seems that thusfar, Jonas from Mozilla is open to this change. Is
there anyone from Opera or WebKit that would like to chime in either  
in

favor or opposition?


I'd love to issue fewer useless loads, if sites don't actually rely on  
it.


Does anyone have data on what, if any, compatibility impact this has?  
I can't imagine loading the base URL to be terribly useful in most  
cases, but perhaps there are wacky sites that do indeed rely on it.


Regards,
Maciej





Thanks.

-Nicholas

__
Commander Lock: "Damnit Morpheus, not everyone believes what you
believe!"
Morpheus: "My beliefs do not require them to."

-Original Message-
From: whatwg-boun...@lists.whatwg.org
[mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Nicholas Zakas
Sent: Friday, December 11, 2009 10:15 AM
To: Simon Pieters; Anne van Kesteren; Aryeh Gregor
Cc: whatwg@lists.whatwg.org
Subject: Re: [whatwg] Inconsistent behavior for empty-string URLs

I agree, automatic downloads are the real issue.  is fine
because a user must initiate the action (and thus generate a "real"
pageview).

I'd think that the behavior should be the same in CSS and SVG for
resources that are automatically downloaded.

-Nicholas

__
Commander Lock: "Damnit Morpheus, not everyone believes what you
believe!"
Morpheus: "My beliefs do not require them to."

-Original Message-
From: Simon Pieters [mailto:sim...@opera.com]
Sent: Thursday, December 10, 2009 10:57 AM
To: Nicholas Zakas; Anne van Kesteren; Aryeh Gregor
Cc: whatwg@lists.whatwg.org
Subject: Re: [whatwg] Inconsistent behavior for empty-string URLs

On Thu, 10 Dec 2009 19:22:43 +0100, Nicholas Zakas

wrote:


I'd be happy to make the compromise that this applies to markup but

not

to JavaScript APIs.


I think it shouldn't apply to markup that doesn't download things
automatically; in particular  should work.

What about URLs in CSS and SVG?

--
Simon Pieters
Opera Software

Re: [whatwg] Inconsistent behavior for empty-string URLs

[Simon Pieters]

On Mon, 14 Dec 2009 20:08:40 +0100, Nicholas Zakas   
wrote:



It seems that thusfar, Jonas from Mozilla is open to this change. Is
there anyone from Opera or WebKit that would like to chime in either in
favor or opposition?


It appears that Opera already does this (though I haven't tested SVG or  
CSS). I think it's ok, but I'd like it specced. :-)


--
Simon Pieters
Opera Software

Re: [whatwg] Quality Values for Media Source Elements

[Hugh Guiney]

On Mon, Dec 14, 2009 at 4:08 AM, Silvia Pfeiffer
 wrote:
> I would almost consider simply using "low quality" and "high quality"
> as quality distinguishers (and maybe "medium") and leave the actual
> choice of encoding to the hosting entity. Right now, may sites provide
> only two choices for Desktop: SD and HD, plus one for mobile. The
> device can be separated by the device-width as Eric described.

Except it can't—at least, not entirely. Since the size of a video
image is the result of multiplying the width and height by its pixel
aspect ratio, the pixel count of the video does not necessarily match
that of the device playing it back.

For instance, on a DVD, both "fullscreen" and widescreen movies are
stored at the same resolutions, but with different pixel aspect ratios
(i.e., the shape of the pixels are not necessarily a 1:1 square, as on
computers).

According to the D1 & DV standards, "fullscreen" pixels have a
width-to-height ratio of 4320/4739 (~0.9). So a 720x480 "fullscreen"
image on a square-pixel device would have to be displayed at ~656x480
pixels to retain its proper aspect ratio.

By the same standards, widescreen pixels are 5760/4739 (~1.2), so a
720x480 widescreen image would have to be displayed at ~875x480
pixels.

Therefore, "screen and (min-device-width: 720px)" would not work for
all 480i/p content. Either the PAR would have to be read from the file
itself—the storage of which differs from format to format—or the
author would have to specify it. Which is also problematic since not
everyone knows what PARs are, and even when they do, not everyone uses
the same pixel shape definitions: MPEG-4 says widescreen pixels are
40/33, which is *close* to the D1/DV definition but not quite: this
results in a ~873x480 square-pixel image. And due to rounding, there
is also a conventional habit of specifying a PAR of 6/5 (exactly 1.2),
resulting in 864x480. Apple on the other hand defines it as 32/27,
resulting in ~853x480. So even with the same source content, you may
be looking at as many as 4 different rendered sizes depending on the
device manufacturer. So if you specify the PAR according to one
standard, a device built according to another may not recognize it as
playable material, even though it is fully capable of playing it back.

Though this COULD potentially be solved by taking aspect ratio error
into account when processing the media query. So say for any specified
PAR that doesn't match a PAR the device can support exactly, if the
ratios turned out to be the same rounded to a certain decimal point,
that would count as a match and the device would simply render it
according to its standards. This *somewhat* defeats the point of
specifying PARs exactly, but at least it'd be "good enough" as the
difference would be too insignificant for most people to notice.

> SD and
> HD - while also changing between aspect ratio - are mostly a choice
> between lower bandwidth use and higher bandwidth use, which are taken
> as equivalent to low and high quality by users. Since there will
> likely be a higher bitrate HD version joining in the future, it will
> then turn into SD, HD and HD2 - which equates to low, medium, high.
> Over time, SD will fall aside and leave medium and high. Then, if
> another higher quality comes in, they can be redefined to low and
> medium.
>
> Thus, keeping these "fuzzy" specifiers, we stay future-proof and leave
> the actual choice of what "low" and "high" means to the respective
> hosting site, which will make the format choice according to current
> standards.
>
> I'd prefer giving actual levels ("low", "medium", and "high") rather
> than a number between 0 and 1, because they make it comparable between
> hosting sites. If I choose to have "low" on YouTube, I will likely
> want "low" on Dailymotion and Hulu, even if those sites decided to use
> completely different encoding parameters for their "low" and "high"
> quality versions.

I can agree with this proposal as far as quality = data rate is
concerned. As for any of the other criteria, they'd have to be
addressed differently.

On Mon, Dec 14, 2009 at 10:59 AM, Aryeh Gregor  wrote:
> It depends on the application.  But in any event, HTML can never
> possibly do everything JavaScript does, so at some point the answer
> needs to be "use JavaScript".

Nor should it. But if you're doing something in JavaScript, there
*should* be a functional alternative in plain HTML when it's turned
off. That means if you've got an AJAX application, even with JS turned
off a user should still be able to interact with the server
synchronously. If you had all of your content negotiation in JS,
however, there could be no alternative, as the lack of one would have
been the reason to use JS in the first place.

> I don't follow.  If authors *were* willing to use content negotiation,
> to the contrary, there would be no need for .  You could just
> write  in your markup, and configure your
> server to serve foo.mp4 or foo.ogg depending on the