From chaals at opera.com  Thu Jul  1 02:19:05 2010
From: chaals at opera.com (Charles McCathieNevile)
Date: Thu, 01 Jul 2010 11:19:05 +0200
Subject: [whatwg] My proposal of a subtitle format via an XML-like
 markup (in progress)
In-Reply-To: <AANLkTikRabgKyrPoFYO6_ieIZctCu7ttkzMev4vEiSqQ@mail.gmail.com>
References: <AANLkTikRabgKyrPoFYO6_ieIZctCu7ttkzMev4vEiSqQ@mail.gmail.com>
Message-ID: <op.ve5qt3dewxe0ny@widsith.local>

On Sun, 30 May 2010 20:56:44 +0200, Carlos Andr?s Sol?s  
<csolisr at gmail.com> wrote:

> I've been thinking on using an XML-like markup as a format to implement
> subtitles. [...]

Hi Carlos,

there is a lot of work in this area happening in the W3C HTML  
accessibility task force, including many people who appear from time to  
time on this list and are responsible for implementing this stuff. I  
recommend you take a look there -  
http://www.w3.org/WAI/PF/HTML/wiki/Media_Accessibility_Requirements#Captioning  
...

cheers

Chaals

-- 
Charles McCathieNevile  Opera Software, Standards Group
     je parle fran?ais -- hablo espa?ol -- jeg l?rer norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com

From silviapfeiffer1 at gmail.com  Thu Jul  1 02:44:26 2010
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Thu, 1 Jul 2010 19:44:26 +1000
Subject: [whatwg] media resources: addressing media fragments through
	URIs spec
In-Reply-To: <AANLkTilSyggGPxuk-I6455ts6KH2EBUWhL7xBrekvIyb@mail.gmail.com>
References: <AANLkTilAqisq4_U-5IMLrenaezWAFft3Ya22uYYf7Wia@mail.gmail.com> 
	<AANLkTilSyggGPxuk-I6455ts6KH2EBUWhL7xBrekvIyb@mail.gmail.com>
Message-ID: <AANLkTiljhBhvMGpWeGPBaPoEDRqj3TeOKr-r-qJO76XM@mail.gmail.com>

Hi Jonas,

On Thu, Jul 1, 2010 at 4:41 AM, Jonas Sicking <jonas at sicking.cc> wrote:
> Hi Silvia,
>
> Back in may last year I brought [1] up the fact that there are two use
> cases for temporal media fragments:
>
> 1. Skipping to a particular point in a longer resource, such as
> wanting to start a video at a particular point while still allowing
> seeking in the entire resource. This is currently supported by for
> example YouTube [2]. It is also the model used for web pages where
> including a fragment identifier only scrolls to a particular point,
> while allowing the user to scroll to any point both before and after
> the identified fragment.
>
> 2. Only displaying part of a video. For example out of a longer video
> from a discussion panel, only displaying the part where a specific
> topic is discussed.
>
> While there seemed to be agreement [3][4] that these are in fact two
> separate use cases, it seems like the media fragments draft is only
> attempting to address one. Additionally, it only addresses the one
> that has the least precedence as far as current technologies on the
> web goes.
>
> Was this an intentional omission? Is it planned to solve use case 1
> above in a future revision?
>
> [1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-May/019596.html
> [2] http://www.youtube.com/watch?v=fyQrKvc7_NU#t=201
> [3] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-May/019718.html
> [4] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-May/019721.html


I think you may have misunderstood the specification. Use case 1 is
indeed the main use case being addressed in the specification. There
is a Firefox plugin implementation[1] of the specification that shows
exactly use case 1 in a video element - a URI with a fragment such as
video.ogv#t=40,50 is being included in a <video> element and the
effect is that the video is displayed from 40s to 50s, but the
transport bar (or controls) are still those of the complete resource,
so you can still seek to any position.

To be sure, this is just a recommendation of how it is supposed to be
implemented (see
http://www.w3.org/TR/media-frags/#media-fragment-display). The group
only defined what URIs look like that point to such a segment - it
cannot prescribe what an application (such as a HTML document) does
with the URI. I would propose that this discussion should be had about
HTML5 and a sentence be added to the HTML5 spec on how UAs are
expected to deal with such segments.

Further, if you are indeed only interested in a subpart of the
original media resource and want to completely blend out all context
(i.e. all other bits of the media resource), you should be using the
URI query addressing method instead of the URI fragment, e.g.
video.ogv?t=40,50. This URI is supposed to create a new resource that
consist only of the segment - it will only do so, of course, if your
server supports this functionality.

All of this is described in more detail in the spec [2]. If that is
unclear or anything is confusing, please do point it out so it can be
fixed.

Best Regards,
Silvia.



[1] http://www.w3.org/2008/WebVideo/Fragments/code/plugin/ (expect some bugs)
[2] http://www.w3.org/TR/media-frags/

From silviapfeiffer1 at gmail.com  Thu Jul  1 02:46:00 2010
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Thu, 1 Jul 2010 19:46:00 +1000
Subject: [whatwg] media resources: addressing media fragments through
	URIs spec
In-Reply-To: <AANLkTiljhBhvMGpWeGPBaPoEDRqj3TeOKr-r-qJO76XM@mail.gmail.com>
References: <AANLkTilAqisq4_U-5IMLrenaezWAFft3Ya22uYYf7Wia@mail.gmail.com> 
	<AANLkTilSyggGPxuk-I6455ts6KH2EBUWhL7xBrekvIyb@mail.gmail.com> 
	<AANLkTiljhBhvMGpWeGPBaPoEDRqj3TeOKr-r-qJO76XM@mail.gmail.com>
Message-ID: <AANLkTin311-SC_Ehmedsc5FW7XYRkib7oz5Tr66mUqAk@mail.gmail.com>

BTW: I will try and make a screencast of that firefox plugin, which
should clarify things further. Stay tuned...
Cheers,
Silvia.


On Thu, Jul 1, 2010 at 7:44 PM, Silvia Pfeiffer
<silviapfeiffer1 at gmail.com> wrote:
> Hi Jonas,
>
> On Thu, Jul 1, 2010 at 4:41 AM, Jonas Sicking <jonas at sicking.cc> wrote:
>> Hi Silvia,
>>
>> Back in may last year I brought [1] up the fact that there are two use
>> cases for temporal media fragments:
>>
>> 1. Skipping to a particular point in a longer resource, such as
>> wanting to start a video at a particular point while still allowing
>> seeking in the entire resource. This is currently supported by for
>> example YouTube [2]. It is also the model used for web pages where
>> including a fragment identifier only scrolls to a particular point,
>> while allowing the user to scroll to any point both before and after
>> the identified fragment.
>>
>> 2. Only displaying part of a video. For example out of a longer video
>> from a discussion panel, only displaying the part where a specific
>> topic is discussed.
>>
>> While there seemed to be agreement [3][4] that these are in fact two
>> separate use cases, it seems like the media fragments draft is only
>> attempting to address one. Additionally, it only addresses the one
>> that has the least precedence as far as current technologies on the
>> web goes.
>>
>> Was this an intentional omission? Is it planned to solve use case 1
>> above in a future revision?
>>
>> [1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-May/019596.html
>> [2] http://www.youtube.com/watch?v=fyQrKvc7_NU#t=201
>> [3] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-May/019718.html
>> [4] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-May/019721.html
>
>
> I think you may have misunderstood the specification. Use case 1 is
> indeed the main use case being addressed in the specification. There
> is a Firefox plugin implementation[1] of the specification that shows
> exactly use case 1 in a video element - a URI with a fragment such as
> video.ogv#t=40,50 is being included in a <video> element and the
> effect is that the video is displayed from 40s to 50s, but the
> transport bar (or controls) are still those of the complete resource,
> so you can still seek to any position.
>
> To be sure, this is just a recommendation of how it is supposed to be
> implemented (see
> http://www.w3.org/TR/media-frags/#media-fragment-display). The group
> only defined what URIs look like that point to such a segment - it
> cannot prescribe what an application (such as a HTML document) does
> with the URI. I would propose that this discussion should be had about
> HTML5 and a sentence be added to the HTML5 spec on how UAs are
> expected to deal with such segments.
>
> Further, if you are indeed only interested in a subpart of the
> original media resource and want to completely blend out all context
> (i.e. all other bits of the media resource), you should be using the
> URI query addressing method instead of the URI fragment, e.g.
> video.ogv?t=40,50. This URI is supposed to create a new resource that
> consist only of the segment - it will only do so, of course, if your
> server supports this functionality.
>
> All of this is described in more detail in the spec [2]. If that is
> unclear or anything is confusing, please do point it out so it can be
> fixed.
>
> Best Regards,
> Silvia.
>
>
>
> [1] http://www.w3.org/2008/WebVideo/Fragments/code/plugin/ (expect some bugs)
> [2] http://www.w3.org/TR/media-frags/
>

From kornel at geekhood.net  Thu Jul  1 06:12:34 2010
From: kornel at geekhood.net (Kornel Lesinski)
Date: Thu, 1 Jul 2010 14:12:34 +0100
Subject: [whatwg] HTML 5 : The Youtube response
In-Reply-To: <5C06BA12-2566-4FE4-A17A-D430B38D263D@apple.com>
References: <20100630093438.M86436@ossreleasefeed.com>
	<AANLkTikc__HfZtauZSS4mM8vs_nQPjzB3BNE3d-Knmvj@mail.gmail.com>
	<AANLkTimNjextTEuYS46NoHMTIdF90PgYZ67_wnYDOqxL@mail.gmail.com>
	<4956CA5A-C4ED-4CE3-BBD2-B2ACF0E23CE4@apple.com>
	<1277948843.29657.23.camel@shane-laptop>
	<5C06BA12-2566-4FE4-A17A-D430B38D263D@apple.com>
Message-ID: <21719D7E-DEE8-4FDE-A7A1-28AD3A4A796E@geekhood.net>

> 
> I believe we can allow arbitrary content to go fullscreen, along the lines of what Robert O'Callahan has proposed on this list, if we impose sufficient restrictions to mitigate the above risks. In my opinion, the following measures would likely be sufficient:
> 
> A) Have a distinctive animated sequence when an element goes into full-screen mode. This helps the user understand what happened.
> B) Limit the ability to go fullscreen to user gestures, much as many browsers limit pop-ups. This prevents shenanigans from happening while the user is away from the keyboard, and greatly limits the potential annoyance factor.
> C) On systems with keyboard/mouse input, limit the keys that may be processed by fullscreen content to a small set, such as the set that Flash limits to in full-screen mode: <http://www.adobe.com/devnet/flashplayer/articles/fplayer10_security_changes_03.html#head5>.
> D) On multitouch devices with an onscreen keyboard as the normal means of input, things are trickier, because it's possible for a dedicated attacker to simulate the keyboard. My best idea is make sure that a visually distinctive status indicator appears at the top of the screen even in full-screen mode, since that is the norm on such platforms.
> E) Reserve one or more obvious key combinations to exiting fullscreen no matter what (Escape, perhaps Cmd+W/Ctrl+W).
> F) Even on keyboard/mouse type systems, have some distinctive visual affordance which is either always present or appears on mouse moves, and which allows the user to exit full-screen mode.
> 
> I think these measures greatly mitigate risks (1) and (2) above, and open up highly valued functionality (full screen video) with a UI that users will enjoy, and customizability that video hosting sites will appreciate.

Another option (for low-res videos on desktop) might be to use lower screen resolution when in full screen ? text and UI elements displayed by attacker will look noticeably different.

-- 
regards, Kornel


From mjs at apple.com  Thu Jul  1 09:16:59 2010
From: mjs at apple.com (Maciej Stachowiak)
Date: Thu, 01 Jul 2010 09:16:59 -0700
Subject: [whatwg] HTML 5 : The Youtube response
In-Reply-To: <21719D7E-DEE8-4FDE-A7A1-28AD3A4A796E@geekhood.net>
References: <20100630093438.M86436@ossreleasefeed.com>
	<AANLkTikc__HfZtauZSS4mM8vs_nQPjzB3BNE3d-Knmvj@mail.gmail.com>
	<AANLkTimNjextTEuYS46NoHMTIdF90PgYZ67_wnYDOqxL@mail.gmail.com>
	<4956CA5A-C4ED-4CE3-BBD2-B2ACF0E23CE4@apple.com>
	<1277948843.29657.23.camel@shane-laptop>
	<5C06BA12-2566-4FE4-A17A-D430B38D263D@apple.com>
	<21719D7E-DEE8-4FDE-A7A1-28AD3A4A796E@geekhood.net>
Message-ID: <8EE51233-8331-4070-A36D-6CDF4AD77947@apple.com>


On Jul 1, 2010, at 6:12 AM, Kornel Lesinski wrote:

>> 
>> I believe we can allow arbitrary content to go fullscreen, along the lines of what Robert O'Callahan has proposed on this list, if we impose sufficient restrictions to mitigate the above risks. In my opinion, the following measures would likely be sufficient:
>> 
>> A) Have a distinctive animated sequence when an element goes into full-screen mode. This helps the user understand what happened.
>> B) Limit the ability to go fullscreen to user gestures, much as many browsers limit pop-ups. This prevents shenanigans from happening while the user is away from the keyboard, and greatly limits the potential annoyance factor.
>> C) On systems with keyboard/mouse input, limit the keys that may be processed by fullscreen content to a small set, such as the set that Flash limits to in full-screen mode: <http://www.adobe.com/devnet/flashplayer/articles/fplayer10_security_changes_03.html#head5>.
>> D) On multitouch devices with an onscreen keyboard as the normal means of input, things are trickier, because it's possible for a dedicated attacker to simulate the keyboard. My best idea is make sure that a visually distinctive status indicator appears at the top of the screen even in full-screen mode, since that is the norm on such platforms.
>> E) Reserve one or more obvious key combinations to exiting fullscreen no matter what (Escape, perhaps Cmd+W/Ctrl+W).
>> F) Even on keyboard/mouse type systems, have some distinctive visual affordance which is either always present or appears on mouse moves, and which allows the user to exit full-screen mode.
>> 
>> I think these measures greatly mitigate risks (1) and (2) above, and open up highly valued functionality (full screen video) with a UI that users will enjoy, and customizability that video hosting sites will appreciate.
> 
> Another option (for low-res videos on desktop) might be to use lower screen resolution when in full screen ? text and UI elements displayed by attacker will look noticeably different.

That would probably make the controls look ugly for video with custom controls, and I suspect neither users nor content authors would appreciate that. Interesting idea, though.

 - Maciej


From christoph.paeper at crissov.de  Thu Jul  1 11:38:51 2010
From: christoph.paeper at crissov.de (=?iso-8859-1?Q?Christoph_P=E4per?=)
Date: Thu, 1 Jul 2010 20:38:51 +0200
Subject: [whatwg] Sortable Tables
Message-ID: <F9859A39-E9E5-43AC-BFBA-0786EDC128BC@crissov.de>

It?s a common task outside HTML to sort tables by one or more of its columns. 

There does seem interest among web content providers in making tables client-side sortable since there are several Javascript solutions to do just that, eg. <http://meta.wikimedia.org/wiki/Help:Sorting>, <http://tablesorter.com/docs/>. From these we can learn what would be needed from markup to help sorting algorithms. None of this must be behaviorial, but descriptionary.

I have not found much on sortable tables on whatwg.org, especially when excluding ?datagrid?.

For starters, only rows inside ?tbody?s shall be reordered. For now columns don?t have to be reordered, ie. only vertical, no horizontal sorting. Nevertheless the design should make it possible to add the other direction later.

Not every table has content that makes sense to be sorted in a different order. So sortable tables should be marked as such. Note that ?col? and ?colgroup? elements are hardly supported.

Not every column has content that makes sense to be sorted in a different order. So non-sortable columns inside sortable tables should be marked as such.

There are different ways to sort, eg. numeric, temporal or alphabetic and ascending or descending. Therefore columns should bear information how they should be sorted, ie. what kind of content their cells have. 

Several columns may be used for sorting by some kind of priority.

The original order must be restorable.

Cell content may not consist of the string that should be used verbatim for sorting purposes, eg. leading articles or similar numbers with different units (?g?, ?kg?, ?t? ?). Cells should have an optional attribute indicating their sort key. The ?time? element already provides the necessary metadata features for temporal sorting ? maybe there should be more of such elements instead.

There may be columns that shall remain stable, eg. rank numbers.

Spanning cells, ie. ?colspan? and ?rowspan?, are a problem or rather two quite different problems. This can be solved if browsers would expand those spans prior to sorting and possibly reapply them afterwards.

Solution 1

A ?sort? attribute is introduced for ?table?, ?col?, ?td? elements at least, but with different meaning and values.

  table @sort: columns | column-groups | rows | row-groups | none
  col   @sort: [numeric | alphabetic | datetime | rank | ?] 
               [ascending | descending] | none
  td    @sort: <string>

Solution 2

Since the ?sort? attribute of solution 1 seems more behavioral than semantic, its name could be different for each element. The possible values may then differ too. For instance:

  table @sortable: (binary)
  col   @content:  numeric | alphabetic | datetime | ? | various
  td    @sortkey:  <string>

PS: I?m not sure whether HTML should have a way to indicate which rows and columns are less important and therefore could be collapsed (?visibility: collapse?) to fit the table into the viewable area.

From pkasting at google.com  Thu Jul  1 12:05:38 2010
From: pkasting at google.com (Peter Kasting)
Date: Thu, 1 Jul 2010 12:05:38 -0700
Subject: [whatwg] Sortable Tables
In-Reply-To: <F9859A39-E9E5-43AC-BFBA-0786EDC128BC@crissov.de>
References: <F9859A39-E9E5-43AC-BFBA-0786EDC128BC@crissov.de>
Message-ID: <AANLkTinL9GL2vMU-SjfDwlBBDPIJK8haf2ZKxXHvKU01@mail.gmail.com>

On Thu, Jul 1, 2010 at 11:38 AM, Christoph P?per <
christoph.paeper at crissov.de> wrote:

> I have not found much on sortable tables on whatwg.org, especially when
> excluding ?datagrid?.


Why are you excluding <datagrid>, when that's the precise element aimed at
addressing your issue?

PK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100701/8f2a595b/attachment.htm>

From kcarle at google.com  Thu Jul  1 13:37:25 2010
From: kcarle at google.com (Kevin Carle)
Date: Thu, 1 Jul 2010 13:37:25 -0700
Subject: [whatwg] HTML 5 : The Youtube response
In-Reply-To: <8EE51233-8331-4070-A36D-6CDF4AD77947@apple.com>
References: <20100630093438.M86436@ossreleasefeed.com>
	<AANLkTikc__HfZtauZSS4mM8vs_nQPjzB3BNE3d-Knmvj@mail.gmail.com> 
	<AANLkTimNjextTEuYS46NoHMTIdF90PgYZ67_wnYDOqxL@mail.gmail.com> 
	<4956CA5A-C4ED-4CE3-BBD2-B2ACF0E23CE4@apple.com>
	<1277948843.29657.23.camel@shane-laptop> 
	<5C06BA12-2566-4FE4-A17A-D430B38D263D@apple.com>
	<21719D7E-DEE8-4FDE-A7A1-28AD3A4A796E@geekhood.net> 
	<8EE51233-8331-4070-A36D-6CDF4AD77947@apple.com>
Message-ID: <AANLkTinwH5H2dL-DYNPCOacVHEexSYW7biIeGM0GPpuo@mail.gmail.com>

One part of (2) [well, debatably part, but related to video streaming] is
the lack of visibility into stream behavior. I can't ask the video element
questions about dropped frames, bitrate, etc. This is incredibly useful in
Flash for getting streaming feedback, and means I really don't know how well
the HTML5 player is working for users. The best I can do is waiting/stalled
events which is nowhere near as granular.

-Kevin

On Thu, Jul 1, 2010 at 9:16 AM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> On Jul 1, 2010, at 6:12 AM, Kornel Lesinski wrote:
>
> >>
> >> I believe we can allow arbitrary content to go fullscreen, along the
> lines of what Robert O'Callahan has proposed on this list, if we impose
> sufficient restrictions to mitigate the above risks. In my opinion, the
> following measures would likely be sufficient:
> >>
> >> A) Have a distinctive animated sequence when an element goes into
> full-screen mode. This helps the user understand what happened.
> >> B) Limit the ability to go fullscreen to user gestures, much as many
> browsers limit pop-ups. This prevents shenanigans from happening while the
> user is away from the keyboard, and greatly limits the potential annoyance
> factor.
> >> C) On systems with keyboard/mouse input, limit the keys that may be
> processed by fullscreen content to a small set, such as the set that Flash
> limits to in full-screen mode: <
> http://www.adobe.com/devnet/flashplayer/articles/fplayer10_security_changes_03.html#head5
> >.
> >> D) On multitouch devices with an onscreen keyboard as the normal means
> of input, things are trickier, because it's possible for a dedicated
> attacker to simulate the keyboard. My best idea is make sure that a visually
> distinctive status indicator appears at the top of the screen even in
> full-screen mode, since that is the norm on such platforms.
> >> E) Reserve one or more obvious key combinations to exiting fullscreen no
> matter what (Escape, perhaps Cmd+W/Ctrl+W).
> >> F) Even on keyboard/mouse type systems, have some distinctive visual
> affordance which is either always present or appears on mouse moves, and
> which allows the user to exit full-screen mode.
> >>
> >> I think these measures greatly mitigate risks (1) and (2) above, and
> open up highly valued functionality (full screen video) with a UI that users
> will enjoy, and customizability that video hosting sites will appreciate.
> >
> > Another option (for low-res videos on desktop) might be to use lower
> screen resolution when in full screen ? text and UI elements displayed by
> attacker will look noticeably different.
>
> That would probably make the controls look ugly for video with custom
> controls, and I suspect neither users nor content authors would appreciate
> that. Interesting idea, though.
>
>  - Maciej
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100701/2f66b95a/attachment.htm>

From mjs at apple.com  Thu Jul  1 14:02:12 2010
From: mjs at apple.com (Maciej Stachowiak)
Date: Thu, 01 Jul 2010 14:02:12 -0700
Subject: [whatwg] HTML 5 : The Youtube response
In-Reply-To: <AANLkTinwH5H2dL-DYNPCOacVHEexSYW7biIeGM0GPpuo@mail.gmail.com>
References: <20100630093438.M86436@ossreleasefeed.com>
	<AANLkTikc__HfZtauZSS4mM8vs_nQPjzB3BNE3d-Knmvj@mail.gmail.com>
	<AANLkTimNjextTEuYS46NoHMTIdF90PgYZ67_wnYDOqxL@mail.gmail.com>
	<4956CA5A-C4ED-4CE3-BBD2-B2ACF0E23CE4@apple.com>
	<1277948843.29657.23.camel@shane-laptop>
	<5C06BA12-2566-4FE4-A17A-D430B38D263D@apple.com>
	<21719D7E-DEE8-4FDE-A7A1-28AD3A4A796E@geekhood.net>
	<8EE51233-8331-4070-A36D-6CDF4AD77947@apple.com>
	<AANLkTinwH5H2dL-DYNPCOacVHEexSYW7biIeGM0GPpuo@mail.gmail.com>
Message-ID: <FECE7E41-95DF-41CF-B65F-64D03DFFE29A@apple.com>


On Jul 1, 2010, at 1:37 PM, Kevin Carle wrote:

> One part of (2) [well, debatably part, but related to video streaming] is the lack of visibility into stream behavior. I can't ask the video element questions about dropped frames, bitrate, etc. This is incredibly useful in Flash for getting streaming feedback, and means I really don't know how well the HTML5 player is working for users. The best I can do is waiting/stalled events which is nowhere near as granular.

I agree that exposing info like that would be useful. What does the Flash API for this look like? What parts of the available data do you find most useful?

Regards,
Maciej

> 
> -Kevin
> 
> On Thu, Jul 1, 2010 at 9:16 AM, Maciej Stachowiak <mjs at apple.com> wrote:
> 
> On Jul 1, 2010, at 6:12 AM, Kornel Lesinski wrote:
> 
> >>
> >> I believe we can allow arbitrary content to go fullscreen, along the lines of what Robert O'Callahan has proposed on this list, if we impose sufficient restrictions to mitigate the above risks. In my opinion, the following measures would likely be sufficient:
> >>
> >> A) Have a distinctive animated sequence when an element goes into full-screen mode. This helps the user understand what happened.
> >> B) Limit the ability to go fullscreen to user gestures, much as many browsers limit pop-ups. This prevents shenanigans from happening while the user is away from the keyboard, and greatly limits the potential annoyance factor.
> >> C) On systems with keyboard/mouse input, limit the keys that may be processed by fullscreen content to a small set, such as the set that Flash limits to in full-screen mode: <http://www.adobe.com/devnet/flashplayer/articles/fplayer10_security_changes_03.html#head5>.
> >> D) On multitouch devices with an onscreen keyboard as the normal means of input, things are trickier, because it's possible for a dedicated attacker to simulate the keyboard. My best idea is make sure that a visually distinctive status indicator appears at the top of the screen even in full-screen mode, since that is the norm on such platforms.
> >> E) Reserve one or more obvious key combinations to exiting fullscreen no matter what (Escape, perhaps Cmd+W/Ctrl+W).
> >> F) Even on keyboard/mouse type systems, have some distinctive visual affordance which is either always present or appears on mouse moves, and which allows the user to exit full-screen mode.
> >>
> >> I think these measures greatly mitigate risks (1) and (2) above, and open up highly valued functionality (full screen video) with a UI that users will enjoy, and customizability that video hosting sites will appreciate.
> >
> > Another option (for low-res videos on desktop) might be to use lower screen resolution when in full screen ? text and UI elements displayed by attacker will look noticeably different.
> 
> That would probably make the controls look ugly for video with custom controls, and I suspect neither users nor content authors would appreciate that. Interesting idea, though.
> 
>  - Maciej
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100701/0fb574f8/attachment.htm>

From jonas at sicking.cc  Thu Jul  1 14:56:38 2010
From: jonas at sicking.cc (Jonas Sicking)
Date: Thu, 1 Jul 2010 14:56:38 -0700
Subject: [whatwg] media resources: addressing media fragments through
	URIs spec
In-Reply-To: <AANLkTin311-SC_Ehmedsc5FW7XYRkib7oz5Tr66mUqAk@mail.gmail.com>
References: <AANLkTilAqisq4_U-5IMLrenaezWAFft3Ya22uYYf7Wia@mail.gmail.com> 
	<AANLkTilSyggGPxuk-I6455ts6KH2EBUWhL7xBrekvIyb@mail.gmail.com> 
	<AANLkTiljhBhvMGpWeGPBaPoEDRqj3TeOKr-r-qJO76XM@mail.gmail.com> 
	<AANLkTin311-SC_Ehmedsc5FW7XYRkib7oz5Tr66mUqAk@mail.gmail.com>
Message-ID: <AANLkTimLk_qsaqWKvFVWpVfCmblH_IxiR9LvlzZM35_G@mail.gmail.com>

That would be great. I guess it's unclear to me how the UIs would differ for

video.ogv#t=40,50
and
video.ogv#t=40

In particular it seems strange to me that video.ogv#t=40 represents
the whole range from the selected point to the end of the video, given
that most commonly when wanting to point out a particular point in a
video you actually just want to represent a point.

/ Jonas

On Thu, Jul 1, 2010 at 2:46 AM, Silvia Pfeiffer
<silviapfeiffer1 at gmail.com> wrote:
> BTW: I will try and make a screencast of that firefox plugin, which
> should clarify things further. Stay tuned...
> Cheers,
> Silvia.
>
>
> On Thu, Jul 1, 2010 at 7:44 PM, Silvia Pfeiffer
> <silviapfeiffer1 at gmail.com> wrote:
>> Hi Jonas,
>>
>> On Thu, Jul 1, 2010 at 4:41 AM, Jonas Sicking <jonas at sicking.cc> wrote:
>>> Hi Silvia,
>>>
>>> Back in may last year I brought [1] up the fact that there are two use
>>> cases for temporal media fragments:
>>>
>>> 1. Skipping to a particular point in a longer resource, such as
>>> wanting to start a video at a particular point while still allowing
>>> seeking in the entire resource. This is currently supported by for
>>> example YouTube [2]. It is also the model used for web pages where
>>> including a fragment identifier only scrolls to a particular point,
>>> while allowing the user to scroll to any point both before and after
>>> the identified fragment.
>>>
>>> 2. Only displaying part of a video. For example out of a longer video
>>> from a discussion panel, only displaying the part where a specific
>>> topic is discussed.
>>>
>>> While there seemed to be agreement [3][4] that these are in fact two
>>> separate use cases, it seems like the media fragments draft is only
>>> attempting to address one. Additionally, it only addresses the one
>>> that has the least precedence as far as current technologies on the
>>> web goes.
>>>
>>> Was this an intentional omission? Is it planned to solve use case 1
>>> above in a future revision?
>>>
>>> [1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-May/019596.html
>>> [2] http://www.youtube.com/watch?v=fyQrKvc7_NU#t=201
>>> [3] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-May/019718.html
>>> [4] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-May/019721.html
>>
>>
>> I think you may have misunderstood the specification. Use case 1 is
>> indeed the main use case being addressed in the specification. There
>> is a Firefox plugin implementation[1] of the specification that shows
>> exactly use case 1 in a video element - a URI with a fragment such as
>> video.ogv#t=40,50 is being included in a <video> element and the
>> effect is that the video is displayed from 40s to 50s, but the
>> transport bar (or controls) are still those of the complete resource,
>> so you can still seek to any position.
>>
>> To be sure, this is just a recommendation of how it is supposed to be
>> implemented (see
>> http://www.w3.org/TR/media-frags/#media-fragment-display). The group
>> only defined what URIs look like that point to such a segment - it
>> cannot prescribe what an application (such as a HTML document) does
>> with the URI. I would propose that this discussion should be had about
>> HTML5 and a sentence be added to the HTML5 spec on how UAs are
>> expected to deal with such segments.
>>
>> Further, if you are indeed only interested in a subpart of the
>> original media resource and want to completely blend out all context
>> (i.e. all other bits of the media resource), you should be using the
>> URI query addressing method instead of the URI fragment, e.g.
>> video.ogv?t=40,50. This URI is supposed to create a new resource that
>> consist only of the segment - it will only do so, of course, if your
>> server supports this functionality.
>>
>> All of this is described in more detail in the spec [2]. If that is
>> unclear or anything is confusing, please do point it out so it can be
>> fixed.
>>
>> Best Regards,
>> Silvia.
>>
>>
>>
>> [1] http://www.w3.org/2008/WebVideo/Fragments/code/plugin/ (expect some bugs)
>> [2] http://www.w3.org/TR/media-frags/
>>
>

From jeremydo at google.com  Thu Jul  1 15:59:14 2010
From: jeremydo at google.com (Jeremy Doig)
Date: Thu, 1 Jul 2010 15:59:14 -0700
Subject: [whatwg] HTML 5 : The Youtube response
In-Reply-To: <FECE7E41-95DF-41CF-B65F-64D03DFFE29A@apple.com>
References: <20100630093438.M86436@ossreleasefeed.com>
	<AANLkTikc__HfZtauZSS4mM8vs_nQPjzB3BNE3d-Knmvj@mail.gmail.com>
	<AANLkTimNjextTEuYS46NoHMTIdF90PgYZ67_wnYDOqxL@mail.gmail.com>
	<4956CA5A-C4ED-4CE3-BBD2-B2ACF0E23CE4@apple.com>
	<1277948843.29657.23.camel@shane-laptop>
	<5C06BA12-2566-4FE4-A17A-D430B38D263D@apple.com>
	<21719D7E-DEE8-4FDE-A7A1-28AD3A4A796E@geekhood.net>
	<8EE51233-8331-4070-A36D-6CDF4AD77947@apple.com>
	<AANLkTinwH5H2dL-DYNPCOacVHEexSYW7biIeGM0GPpuo@mail.gmail.com>
	<FECE7E41-95DF-41CF-B65F-64D03DFFE29A@apple.com>
Message-ID: <AANLkTik3BHl65fI-PZLFB-5EUreojS_z3rse466TymB9@mail.gmail.com>

http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-February/018438.html

On Thu, Jul 1, 2010 at 2:02 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>
> On Jul 1, 2010, at 1:37 PM, Kevin Carle wrote:
>
> One part of (2) [well, debatably part, but related to video streaming] is
> the lack of visibility into stream behavior. I can't ask the video element
> questions about dropped frames, bitrate, etc. This is incredibly useful in
> Flash for getting streaming feedback, and means I really don't know how well
> the HTML5 player is working for users. The best I can do is waiting/stalled
> events which is nowhere near as granular.
>
> I agree that exposing info like that would be useful. What does the Flash
> API for this look like? What parts of the available data do you find most
> useful?
> Regards,
> Maciej
>
> -Kevin
>
> On Thu, Jul 1, 2010 at 9:16 AM, Maciej Stachowiak <mjs at apple.com> wrote:
>>
>> On Jul 1, 2010, at 6:12 AM, Kornel Lesinski wrote:
>>
>> >>
>> >> I believe we can allow arbitrary content to go fullscreen, along the
>> >> lines of what Robert O'Callahan has proposed on this list, if we impose
>> >> sufficient restrictions to mitigate the above risks. In my opinion, the
>> >> following measures would likely be sufficient:
>> >>
>> >> A) Have a distinctive animated sequence when an element goes into
>> >> full-screen mode. This helps the user understand what happened.
>> >> B) Limit the ability to go fullscreen to user gestures, much as many
>> >> browsers limit pop-ups. This prevents shenanigans from happening while the
>> >> user is away from the keyboard, and greatly limits the potential annoyance
>> >> factor.
>> >> C) On systems with keyboard/mouse input, limit the keys that may be
>> >> processed by fullscreen content to a small set, such as the set that Flash
>> >> limits to in full-screen mode:
>> >> <http://www.adobe.com/devnet/flashplayer/articles/fplayer10_security_changes_03.html#head5>.
>> >> D) On multitouch devices with an onscreen keyboard as the normal means
>> >> of input, things are trickier, because it's possible for a dedicated
>> >> attacker to simulate the keyboard. My best idea is make sure that a visually
>> >> distinctive status indicator appears at the top of the screen even in
>> >> full-screen mode, since that is the norm on such platforms.
>> >> E) Reserve one or more obvious key combinations to exiting fullscreen
>> >> no matter what (Escape, perhaps Cmd+W/Ctrl+W).
>> >> F) Even on keyboard/mouse type systems, have some distinctive visual
>> >> affordance which is either always present or appears on mouse moves, and
>> >> which allows the user to exit full-screen mode.
>> >>
>> >> I think these measures greatly mitigate risks (1) and (2) above, and
>> >> open up highly valued functionality (full screen video) with a UI that users
>> >> will enjoy, and customizability that video hosting sites will appreciate.
>> >
>> > Another option (for low-res videos on desktop) might be to use lower
>> > screen resolution when in full screen ? text and UI elements displayed by
>> > attacker will look noticeably different.
>>
>> That would probably make the controls look ugly for video with custom
>> controls, and I suspect neither users nor content authors would appreciate
>> that. Interesting idea, though.
>>
>> ?- Maciej
>>
>
>
>

From jharding at google.com  Thu Jul  1 15:59:37 2010
From: jharding at google.com (John Harding)
Date: Thu, 1 Jul 2010 15:59:37 -0700
Subject: [whatwg] More YouTube response
Message-ID: <AANLkTinbe-p-STmyfGAiGA6NR7cZO-nzqlq405O5gGTd@mail.gmail.com>

Glad to see my post spurred some good discussion - I'll try to address topic
by topic below, but one of the great points made is that some of the
functionality YouTube needs from browsers probably doesn't belong in the
HTML5 spec (e.g. streaming, content protection).  I'm happy to take those
discussions elsewhere if this forum is inappropriate, but it seems like it
would likely be the same group of people, just on a different mailing list.

1. Standard Video Format
Yes, this has been debated a lot, and I generally agree that leaving it out
of the spec was the best way forward for the spec.  Shane Fagan pointed out
that Flash supports multiple different codecs, which is true, but every
version since Flash 7 has supported Sorenson Spark video and MP3 audio.  I
don't think anyone is suggesting that browsers shouldn't support multiple
codecs, but having a consistent baseline is important.  On the current path,
a content provider knows that by offering H.264 and WebM, they can reach all
HTML5-capable browsers.  This honestly is a reasonable state for YouTube
right now - we use H.264 in cases outside the <video> tag as well, but it
would be nice to converge on a single baseline format at some point in the
future.

2. Robust Video Streaming
Andy Berkheimer on our team has been putting some thought into this, so I'll
defer to him for more specific proposals.  For an app like YouTube, it
is *extremely
*useful to have fine-grained control over how the browser fetches media from
the server.  Whether the details belong in the HTML5 spec or not depends on
the preferred design - something similar to Flash 10.1's appendBytes()
mechanism would affect the <video> tag interface, for example, while a
transport protocol could be completely separate.

3. Content Protection
Some of the discussion here seems to have conflated application-controlled
video delivery with content protection, but in an ideal world, the two are
independent.  The basic requirements around content protection that we get
from content owners basically consist of encrypting the content and limiting
the decryption to a "verified" and authorized client - the realm of
traditional DRM.  Rather than ask browsers to get into the DRM business,
what I think would work best is having a means for 3rd party DRM providers
to supply browser plug-ins which implement the <video> tag for protected
content - not all that different than selecting a pluggable codec.

4. Encapsulation and Embedding
As several people pointed out (and which I tried to get at in my post), this
is really an ecosystem issue rather than a change needed in the spec or in
browsers.  I suspect it's going to take some time, but the flexibility of
embedding content via <iframe> will be a big step forward.

5. Fullscreen
Maciej actually covered YouTube's requirements pretty well.  I'd add that
it's not just controls that are important for us to maintain: we have a lot
of additional content that needs to display with and sometimes on top of the
video - our interactive annotations, captions, and ads most notably.
 Maciej's proposal also looks fairly reasonable, though some thoughts on it:
When limiting keyboard input, I'd suggest devices w/ onscreen keyboards
simply disable the keyboard.  Applications that work well with touch
interfaces generally provide gesture alternatives for the limited set of
keys that would be available.  Alternately, devices could limit the keyboard
to the set of allowed keys.
Keyboard restrictions are better than not having fullscreen support, though
they do limit functionality - it would prevent us from supporting search in
fullscreen mode, for example.

6. Camera and Micrphone access
As pointed out, this is not strictly an issue for <video> tag, though
certainly related especially for local preview.  I have not been closely
following the work on the <device> element, though that seems to be where
this is headed.

-John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100701/8153d8e5/attachment.htm>

From christoph.paeper at crissov.de  Thu Jul  1 16:25:43 2010
From: christoph.paeper at crissov.de (=?iso-8859-1?Q?Christoph_P=E4per?=)
Date: Fri, 2 Jul 2010 01:25:43 +0200
Subject: [whatwg] Sortable Tables
In-Reply-To: <AANLkTinL9GL2vMU-SjfDwlBBDPIJK8haf2ZKxXHvKU01@mail.gmail.com>
References: <F9859A39-E9E5-43AC-BFBA-0786EDC128BC@crissov.de>
	<AANLkTinL9GL2vMU-SjfDwlBBDPIJK8haf2ZKxXHvKU01@mail.gmail.com>
Message-ID: <B15935EB-F539-42C0-8307-2FDDBB5C3334@crissov.de>

Peter Kasting:
> 
> Why are you excluding <datagrid>, when that's the precise element aimed at
> addressing your issue?

Because of r3555 <http://lists.whatwg.org/htdig.cgi/commit-watchers-whatwg.org/2009/002723.html> where it was removed and because I don?t think this requires a new element at all.

From eireland at sybase.com  Thu Jul  1 21:06:28 2010
From: eireland at sybase.com (Evan Ireland)
Date: Fri, 2 Jul 2010 16:06:28 +1200
Subject: [whatwg] Web Workers API
Message-ID: <000b01cb199b$f29271a0$d7b754e0$@com>

Hi,

The IDL for Worker in the Web Workers API specification shows:

    void postMessage(in any message, in optional MessagePortArray ports);

I have a question regarding the 'any' type for message.

If a caller of postMessage passes an object to a worker that is not a
string, is it converted to a string or can non-string objects be propagated
through to the onmessage(event) in the worker.

So if I write:

var w = new MyWorker('MyWorker.js');
w.postMessage(new MyObject());

--------------
// MyWorker.js

onmessage = function(event)
{
    var d = event.data;
    // what type is 'd'?
}

If 'd' is not a string, then is it a MyObject, and if so, how is it supposed
to be marshalled by the inter-worker(thread) communication?

I suggest that whatever the answer, that this be covered when the spec
document is next updated.

Thanks.



From Simetrical+w3c at gmail.com  Thu Jul  1 21:16:58 2010
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Fri, 2 Jul 2010 00:16:58 -0400
Subject: [whatwg] More YouTube response
In-Reply-To: <AANLkTinbe-p-STmyfGAiGA6NR7cZO-nzqlq405O5gGTd@mail.gmail.com>
References: <AANLkTinbe-p-STmyfGAiGA6NR7cZO-nzqlq405O5gGTd@mail.gmail.com>
Message-ID: <AANLkTilhe5qKzpIsgTP1NaZd9aYiQJIOa8oBQLqMnJ0p@mail.gmail.com>

On Thu, Jul 1, 2010 at 6:59 PM, John Harding <jharding at google.com> wrote:
> Some of the discussion here seems to have conflated application-controlled
> video delivery with content protection, but in an ideal world, the two are
> independent. ?The basic requirements around content protection that we get
> from content owners basically consist of encrypting the content and limiting
> the decryption to a "verified" and authorized client - the realm of
> traditional DRM. ?Rather than ask browsers to get into the DRM business,
> what I think would work best is having a means for 3rd party DRM providers
> to supply browser plug-ins which implement the <video> tag for protected
> content - not all that different than selecting a pluggable codec.

I suspect that it would be best to just leave this use-case to Flash.
It would be basically impossible to get the kind of obfuscation that
content owners will want via open standards, because people will just
implement clients that skip the obfuscation.  So you're pretty much
stuck with nonstandard plugins anyway.  This decision could be
revisited if there's still a lot of demand for this once the basic
non-DRM use-cases are covered.

> As several people pointed out (and which I tried to get at in my post), this
> is really an ecosystem issue rather than a change needed in the spec or in
> browsers. ?I suspect it's going to take some time, but the flexibility of
> embedding content via <iframe> will be a big step forward.

Wouldn't it be straightforward for YouTube to offer <iframe> support
right now, in addition to <object>?  The backend support should be
simple to do.  If you keep the <object> code as the default embed
recommendation and hide the <iframe> embed code somewhere so people
will only use it if they look for it, you won't risk confusing anyone.
 Sites that currently whitelist <object> from YouTube will eventually
whitelist <iframe> from YouTube too -- I hope there aren't many sites
that permit *arbitrary* <object>s to be inserted by untrusted users.
Allowing <iframe> will have other benefits, like allowing fallback
"install Flash" content (currently omitted from the <object> code, I
assume to keep the size down).

Another thing that occurs to me is that you might show HTML5 video
when Flash isn't installed/enabled, or when the Flash player crashes.
Or at least you could give an option, instead of just failing silently
(for embeds) or saying the user should install Flash (on the site
itself).  My primary machine runs Linux, and Flash usually doesn't
work at all.  If I didn't know about the HTML5 beta, I wouldn't be
able to use YouTube at all.  And as it is, I can't use any YouTube
embeds most of the time.

> When limiting keyboard input, I'd suggest devices w/ onscreen keyboards
> simply disable the keyboard. ?Applications that work well with touch
> interfaces generally provide gesture alternatives for the limited set of
> keys that would be available. ?Alternately, devices could limit the keyboard
> to the set of allowed keys.

The problem is if the program makes a fake keyboard and then directly
intercepts touch events to that location, without invoking the OS's
keyboard at all.  The user won't be able to tell that the keypresses
are going to the website instead of the OS.  But I can't see this as
being a big issue -- screen space is so limited on these devices that
websites are fullscreen anyway, or practically.  On my Nexus One,
unless you're scrolled to the top of the site, websites take up the
whole screen except for the bar at the top, which is present in all
apps.  So they could already trivially spoof any application, if they
know the target platform.  Not if the user presses the menu button, I
guess.

> As pointed out, this is not strictly an issue for <video> tag, though
> certainly related especially for local preview. ?I have not been closely
> following the work on the <device> element, though that seems to be where
> this is headed.

<device> adoption shouldn't interfere with <video> adoption, though.
Even if YouTube switched to <video> by default, it could keep Flash
for recording until <device> was implemented.  It's probably best for
implementers to focus on perfecting <video> (and maybe <canvas>, etc.)
before they put too much work into <device>, since those are much
bigger use-cases.

From oliver at apple.com  Thu Jul  1 23:21:20 2010
From: oliver at apple.com (Oliver Hunt)
Date: Thu, 1 Jul 2010 23:21:20 -0700
Subject: [whatwg] Web Workers API
In-Reply-To: <000b01cb199b$f29271a0$d7b754e0$@com>
References: <000b01cb199b$f29271a0$d7b754e0$@com>
Message-ID: <7DE1F35E-BF35-4482-B322-8FBB827E5A3D@apple.com>

All meesaging through postMessage uses the internal structured cloning algorithm detailed at http://www.w3.org/TR/2010/WD-html5-20100304/Overview.html#internal-structured-cloning-algorithm

It's basically a deep copy, but has a few restrictions on the types cloned, and doesn't copy functions or the prototype property, etc.

--Oliver

On Jul 1, 2010, at 9:06 PM, Evan Ireland wrote:

> Hi,
> 
> The IDL for Worker in the Web Workers API specification shows:
> 
>    void postMessage(in any message, in optional MessagePortArray ports);
> 
> I have a question regarding the 'any' type for message.
> 
> If a caller of postMessage passes an object to a worker that is not a
> string, is it converted to a string or can non-string objects be propagated
> through to the onmessage(event) in the worker.
> 
> So if I write:
> 
> var w = new MyWorker('MyWorker.js');
> w.postMessage(new MyObject());
> 
> --------------
> // MyWorker.js
> 
> onmessage = function(event)
> {
>    var d = event.data;
>    // what type is 'd'?
> }
> 
> If 'd' is not a string, then is it a MyObject, and if so, how is it supposed
> to be marshalled by the inter-worker(thread) communication?
> 
> I suggest that whatever the answer, that this be covered when the spec
> document is next updated.
> 
> Thanks.
> 
> 


From mail at jeroenwijering.com  Fri Jul  2 00:28:17 2010
From: mail at jeroenwijering.com (Jeroen Wijering)
Date: Fri, 2 Jul 2010 09:28:17 +0200
Subject: [whatwg] HTML 5 : The Youtube response
In-Reply-To: <FECE7E41-95DF-41CF-B65F-64D03DFFE29A@apple.com>
References: <20100630093438.M86436@ossreleasefeed.com>
	<AANLkTikc__HfZtauZSS4mM8vs_nQPjzB3BNE3d-Knmvj@mail.gmail.com>
	<AANLkTimNjextTEuYS46NoHMTIdF90PgYZ67_wnYDOqxL@mail.gmail.com>
	<4956CA5A-C4ED-4CE3-BBD2-B2ACF0E23CE4@apple.com>
	<1277948843.29657.23.camel@shane-laptop>
	<5C06BA12-2566-4FE4-A17A-D430B38D263D@apple.com>
	<21719D7E-DEE8-4FDE-A7A1-28AD3A4A796E@geekhood.net>
	<8EE51233-8331-4070-A36D-6CDF4AD77947@apple.com>
	<AANLkTinwH5H2dL-DYNPCOacVHEexSYW7biIeGM0GPpuo@mail.gmail.com>
	<FECE7E41-95DF-41CF-B65F-64D03DFFE29A@apple.com>
Message-ID: <F999B3C9-D2F8-43EC-82A7-CFDA2F285D8B@jeroenwijering.com>

Hello,

The Flash player exposes a string of metrics:

http://help.adobe.com/en_US/AS3LCR/Flash_10.0/flash/net/NetStreamInfo.html

The most useful ones are:

*) droppedFrames: it can be used to determine whether the client can play the video without stuttering.
*) maxBytesPerSecond: it can be used to determine the bandwidth of  the connection. 

In addition to this, the metadata embedded in the video is interesting. For example:

*) width & height: already available
*) duration: already avaliable
*) bitrates: for comparison against maxBytesPerSecond. 
*) seekpoints: for anticipating seek results in the UI
*) content metadata (e.g. ID3 or MP4 Images)

Here's an example with the exposed metadata printed on top of the player:

http://developer.longtailvideo.com/trac/testing/?plugins=metaviewer&file=%2Fplayer%2Ftesting%2Ffiles%2Fbunny.mp4&height=260&width=500&autostart=true&mute=true

Kind regards,

Jeroen





>> One part of (2) [well, debatably part, but related to video streaming] is the lack of visibility into stream behavior. I can't ask the video element questions about dropped frames, bitrate, etc. This is incredibly useful in Flash for getting streaming feedback, and means I really don't know how well the HTML5 player is working for users. The best I can do is waiting/stalled events which is nowhere near as granular.
> 
> I agree that exposing info like that would be useful. What does the Flash API for this look like? What parts of the available data do you find most useful?
> 
> Regards,
> Maciej
> 
>> 
>> -Kevin
>> 
>> On Thu, Jul 1, 2010 at 9:16 AM, Maciej Stachowiak <mjs at apple.com> wrote:
>> 
>> On Jul 1, 2010, at 6:12 AM, Kornel Lesinski wrote:
>> 
>> >>
>> >> I believe we can allow arbitrary content to go fullscreen, along the lines of what Robert O'Callahan has proposed on this list, if we impose sufficient restrictions to mitigate the above risks. In my opinion, the following measures would likely be sufficient:
>> >>
>> >> A) Have a distinctive animated sequence when an element goes into full-screen mode. This helps the user understand what happened.
>> >> B) Limit the ability to go fullscreen to user gestures, much as many browsers limit pop-ups. This prevents shenanigans from happening while the user is away from the keyboard, and greatly limits the potential annoyance factor.
>> >> C) On systems with keyboard/mouse input, limit the keys that may be processed by fullscreen content to a small set, such as the set that Flash limits to in full-screen mode: <http://www.adobe.com/devnet/flashplayer/articles/fplayer10_security_changes_03.html#head5>.
>> >> D) On multitouch devices with an onscreen keyboard as the normal means of input, things are trickier, because it's possible for a dedicated attacker to simulate the keyboard. My best idea is make sure that a visually distinctive status indicator appears at the top of the screen even in full-screen mode, since that is the norm on such platforms.
>> >> E) Reserve one or more obvious key combinations to exiting fullscreen no matter what (Escape, perhaps Cmd+W/Ctrl+W).
>> >> F) Even on keyboard/mouse type systems, have some distinctive visual affordance which is either always present or appears on mouse moves, and which allows the user to exit full-screen mode.
>> >>
>> >> I think these measures greatly mitigate risks (1) and (2) above, and open up highly valued functionality (full screen video) with a UI that users will enjoy, and customizability that video hosting sites will appreciate.
>> >
>> > Another option (for low-res videos on desktop) might be to use lower screen resolution when in full screen ? text and UI elements displayed by attacker will look noticeably different.
>> 
>> That would probably make the controls look ugly for video with custom controls, and I suspect neither users nor content authors would appreciate that. Interesting idea, though.
>> 
>>  - Maciej
>> 
>> 
> 


From silviapfeiffer1 at gmail.com  Fri Jul  2 01:55:19 2010
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Fri, 2 Jul 2010 18:55:19 +1000
Subject: [whatwg] media resources: addressing media fragments through
	URIs spec
In-Reply-To: <AANLkTimLk_qsaqWKvFVWpVfCmblH_IxiR9LvlzZM35_G@mail.gmail.com>
References: <AANLkTilAqisq4_U-5IMLrenaezWAFft3Ya22uYYf7Wia@mail.gmail.com> 
	<AANLkTilSyggGPxuk-I6455ts6KH2EBUWhL7xBrekvIyb@mail.gmail.com> 
	<AANLkTiljhBhvMGpWeGPBaPoEDRqj3TeOKr-r-qJO76XM@mail.gmail.com> 
	<AANLkTin311-SC_Ehmedsc5FW7XYRkib7oz5Tr66mUqAk@mail.gmail.com> 
	<AANLkTimLk_qsaqWKvFVWpVfCmblH_IxiR9LvlzZM35_G@mail.gmail.com>
Message-ID: <AANLkTimGZ-PwKbJOMH8e8fn6nPaLVpK9HuscmqQc6SXj@mail.gmail.com>

Actually, a point in time is nothing - it's an empty set. You never
want to actually point to a point in time, but rather to either the
point in time and an interval after that point in time, or everything
from that point onwards. That's what these URIs represent.

Cheers,
Silvia.

On Fri, Jul 2, 2010 at 7:56 AM, Jonas Sicking <jonas at sicking.cc> wrote:
> That would be great. I guess it's unclear to me how the UIs would differ for
>
> video.ogv#t=40,50
> and
> video.ogv#t=40
>
> In particular it seems strange to me that video.ogv#t=40 represents
> the whole range from the selected point to the end of the video, given
> that most commonly when wanting to point out a particular point in a
> video you actually just want to represent a point.
>
> / Jonas
>
> On Thu, Jul 1, 2010 at 2:46 AM, Silvia Pfeiffer
> <silviapfeiffer1 at gmail.com> wrote:
>> BTW: I will try and make a screencast of that firefox plugin, which
>> should clarify things further. Stay tuned...
>> Cheers,
>> Silvia.
>>
>>
>> On Thu, Jul 1, 2010 at 7:44 PM, Silvia Pfeiffer
>> <silviapfeiffer1 at gmail.com> wrote:
>>> Hi Jonas,
>>>
>>> On Thu, Jul 1, 2010 at 4:41 AM, Jonas Sicking <jonas at sicking.cc> wrote:
>>>> Hi Silvia,
>>>>
>>>> Back in may last year I brought [1] up the fact that there are two use
>>>> cases for temporal media fragments:
>>>>
>>>> 1. Skipping to a particular point in a longer resource, such as
>>>> wanting to start a video at a particular point while still allowing
>>>> seeking in the entire resource. This is currently supported by for
>>>> example YouTube [2]. It is also the model used for web pages where
>>>> including a fragment identifier only scrolls to a particular point,
>>>> while allowing the user to scroll to any point both before and after
>>>> the identified fragment.
>>>>
>>>> 2. Only displaying part of a video. For example out of a longer video
>>>> from a discussion panel, only displaying the part where a specific
>>>> topic is discussed.
>>>>
>>>> While there seemed to be agreement [3][4] that these are in fact two
>>>> separate use cases, it seems like the media fragments draft is only
>>>> attempting to address one. Additionally, it only addresses the one
>>>> that has the least precedence as far as current technologies on the
>>>> web goes.
>>>>
>>>> Was this an intentional omission? Is it planned to solve use case 1
>>>> above in a future revision?
>>>>
>>>> [1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-May/019596.html
>>>> [2] http://www.youtube.com/watch?v=fyQrKvc7_NU#t=201
>>>> [3] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-May/019718.html
>>>> [4] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-May/019721.html
>>>
>>>
>>> I think you may have misunderstood the specification. Use case 1 is
>>> indeed the main use case being addressed in the specification. There
>>> is a Firefox plugin implementation[1] of the specification that shows
>>> exactly use case 1 in a video element - a URI with a fragment such as
>>> video.ogv#t=40,50 is being included in a <video> element and the
>>> effect is that the video is displayed from 40s to 50s, but the
>>> transport bar (or controls) are still those of the complete resource,
>>> so you can still seek to any position.
>>>
>>> To be sure, this is just a recommendation of how it is supposed to be
>>> implemented (see
>>> http://www.w3.org/TR/media-frags/#media-fragment-display). The group
>>> only defined what URIs look like that point to such a segment - it
>>> cannot prescribe what an application (such as a HTML document) does
>>> with the URI. I would propose that this discussion should be had about
>>> HTML5 and a sentence be added to the HTML5 spec on how UAs are
>>> expected to deal with such segments.
>>>
>>> Further, if you are indeed only interested in a subpart of the
>>> original media resource and want to completely blend out all context
>>> (i.e. all other bits of the media resource), you should be using the
>>> URI query addressing method instead of the URI fragment, e.g.
>>> video.ogv?t=40,50. This URI is supposed to create a new resource that
>>> consist only of the segment - it will only do so, of course, if your
>>> server supports this functionality.
>>>
>>> All of this is described in more detail in the spec [2]. If that is
>>> unclear or anything is confusing, please do point it out so it can be
>>> fixed.
>>>
>>> Best Regards,
>>> Silvia.
>>>
>>>
>>>
>>> [1] http://www.w3.org/2008/WebVideo/Fragments/code/plugin/ (expect some bugs)
>>> [2] http://www.w3.org/TR/media-frags/
>>>
>>
>

From jonas at sicking.cc  Fri Jul  2 02:31:24 2010
From: jonas at sicking.cc (Jonas Sicking)
Date: Fri, 2 Jul 2010 02:31:24 -0700
Subject: [whatwg] media resources: addressing media fragments through
	URIs spec
In-Reply-To: <AANLkTimGZ-PwKbJOMH8e8fn6nPaLVpK9HuscmqQc6SXj@mail.gmail.com>
References: <AANLkTilAqisq4_U-5IMLrenaezWAFft3Ya22uYYf7Wia@mail.gmail.com> 
	<AANLkTilSyggGPxuk-I6455ts6KH2EBUWhL7xBrekvIyb@mail.gmail.com> 
	<AANLkTiljhBhvMGpWeGPBaPoEDRqj3TeOKr-r-qJO76XM@mail.gmail.com> 
	<AANLkTin311-SC_Ehmedsc5FW7XYRkib7oz5Tr66mUqAk@mail.gmail.com> 
	<AANLkTimLk_qsaqWKvFVWpVfCmblH_IxiR9LvlzZM35_G@mail.gmail.com> 
	<AANLkTimGZ-PwKbJOMH8e8fn6nPaLVpK9HuscmqQc6SXj@mail.gmail.com>
Message-ID: <AANLkTilRHC0Gg1THJwYUnlVrXHwicZOUxuV-W-hzZRZO@mail.gmail.com>

On Fri, Jul 2, 2010 at 1:55 AM, Silvia Pfeiffer
<silviapfeiffer1 at gmail.com> wrote:
> Actually, a point in time is nothing - it's an empty set. You never
> want to actually point to a point in time, but rather to either the
> point in time and an interval after that point in time, or everything
> from that point onwards. That's what these URIs represent.

I'm not sure I agree, but to avoid meta-discussions I'll just wait to
see the suggested UI.

/ Jonas

From hsivonen at iki.fi  Fri Jul  2 02:37:23 2010
From: hsivonen at iki.fi (Henri Sivonen)
Date: Fri, 2 Jul 2010 02:37:23 -0700 (PDT)
Subject: [whatwg] More YouTube response
In-Reply-To: <948131945.988.1278063352339.JavaMail.root@cm-mail03.mozilla.org>
Message-ID: <1267897846.990.1278063443760.JavaMail.root@cm-mail03.mozilla.org>

"John Harding" <jharding at google.com> wrote:

> Rather than ask browsers to get into the DRM
> business,
> what I think would work best is having a means for 3rd party DRM
> providers
> to supply browser plug-ins which implement the <video> tag for
> protected
> content - not all that different than selecting a pluggable codec.

I think this would defeat a huge chunk of the value of <video>. A big part of the value of <video> is that competition and innovation on the computing platform space will be fostered when the vendor of a computing platform can port (or have ported) one of the Open Source browsers to the platform, pay Opera to port Presto or write their own (like Microsoft) without having to persuade a plug-in proprietor that it's worth the plug-in proprietor's effort to port a certain plug-in to the platform.

Pluggable DRM or codec modules would regress back to the situation where the proprietors of those plug-ins act as gatekeepers for the success of computing platforms.

I observe that Hollywood movies (the most "premium" of content, supposedly) are routinely licensed for DVB broadcast without DRM, and on the Internet every other form of content is distributed without DRM. It may well be that when the potential audience grows enough, at some point the ability to reach that audience weighs more than "protection" and the problem gets solved without DRM (and without the ill effects of DRM to computing platform freedom, competition and innovation).

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/

From marques at displague.com  Fri Jul  2 03:10:43 2010
From: marques at displague.com (Marques Johansson)
Date: Fri, 2 Jul 2010 06:10:43 -0400
Subject: [whatwg] More YouTube response
In-Reply-To: <AANLkTinbe-p-STmyfGAiGA6NR7cZO-nzqlq405O5gGTd@mail.gmail.com>
References: <AANLkTinbe-p-STmyfGAiGA6NR7cZO-nzqlq405O5gGTd@mail.gmail.com>
Message-ID: <AANLkTikmbiM2Vjx2HbhU893BIXOVdb2eG5EJ8LJIB9js@mail.gmail.com>

On Thu, Jul 1, 2010 at 6:59 PM, John Harding <jharding at google.com> wrote:
> 2. Robust Video Streaming
> Andy Berkheimer on our team has been putting some thought into this, so I'll
> defer to him for more specific proposals. ?For an app like YouTube, it is
> extremely useful to have fine-grained control over how the browser fetches
> media from the server. ?Whether the details belong in the HTML5 spec or not
> depends on the preferred design - something similar to Flash 10.1's
> appendBytes() mechanism would affect the <video> tag interface, for example,
> while a transport protocol could be completely separate.
> 3. Content Protection
> Some of the discussion here seems to have conflated application-controlled
> video delivery with content protection, but in an ideal world, the two are
> independent. ?The basic requirements around content protection that we get

I was muddling my recent requests related to "browser fetch" behavior
and "application-controlled video delivery: with the despised topic of
DRM and content protection.  Thanks for clearing that up, John.

If a seek on a HTMLMediaElement's exposed and passed along the XHR
Request to a fetcher method then I could set my constraints for the
impending request.  I would add HTTP Range headers if they are not
present and set a Range upper bound (since the server will return
402,403, or 416 on any "Range: bytes x-" request to retrieve the full
remaining content).

The initiating caller would need to understand that the length of data
requested may have shrunk (which would require the browser to seek
again when the content was all played up or when the buffer was
running low - things that should already be in place).  This, to me,
seems like an alternative to an addBytes method (if that does what I
think it does).

This would provide me with a strictly Javascript solution.  Other
methods I have been asking for would give me a purely HTTP solution
(with new range related 4xxs and, spec endorsed, shorter than
requested 206 responses) to achieve this or an HTML solution (using
new video+source element attributes for buffer (min request size) and
max request size).

From shanepatrickfagan at ubuntu.com  Fri Jul  2 03:13:00 2010
From: shanepatrickfagan at ubuntu.com (Shane Fagan)
Date: Fri, 02 Jul 2010 11:13:00 +0100
Subject: [whatwg] More YouTube response
In-Reply-To: <1267897846.990.1278063443760.JavaMail.root@cm-mail03.mozilla.org>
References: <1267897846.990.1278063443760.JavaMail.root@cm-mail03.mozilla.org>
Message-ID: <1278065580.10898.7.camel@shane-laptop>

On Fri, 2010-07-02 at 02:37 -0700, Henri Sivonen wrote:
> "John Harding" <jharding at google.com> wrote:
> 
> > Rather than ask browsers to get into the DRM
> > business,
> > what I think would work best is having a means for 3rd party DRM
> > providers
> > to supply browser plug-ins which implement the <video> tag for
> > protected
> > content - not all that different than selecting a pluggable codec.
> 
> I think this would defeat a huge chunk of the value of <video>. A big part of the value of <video> is that competition and innovation on the computing platform space will be fostered when the vendor of a computing platform can port (or have ported) one of the Open Source browsers to the platform, pay Opera to port Presto or write their own (like Microsoft) without having to persuade a plug-in proprietor that it's worth the plug-in proprietor's effort to port a certain plug-in to the platform.
> 
> Pluggable DRM or codec modules would regress back to the situation where the proprietors of those plug-ins act as gatekeepers for the success of computing platforms.
> 
> I observe that Hollywood movies (the most "premium" of content, supposedly) are routinely licensed for DVB broadcast without DRM, and on the Internet every other form of content is distributed without DRM. It may well be that when the potential audience grows enough, at some point the ability to reach that audience weighs more than "protection" and the problem gets solved without DRM (and without the ill effects of DRM to computing platform freedom, competition and innovation).
> 
Hey Henri,

Well this isnt really a list where we should talk about the dos and
donts of web content distribution. DRM content can be embedded in the
video tag and decoded using installable plugins so its not really an
issue for this list I dont think. We cant dictate how the specs are used
so try to keep the conversation technology neutral.

--fagan


From marques at displague.com  Fri Jul  2 03:18:17 2010
From: marques at displague.com (Marques Johansson)
Date: Fri, 2 Jul 2010 06:18:17 -0400
Subject: [whatwg] media resources: addressing media fragments through
	URIs spec
In-Reply-To: <AANLkTimGZ-PwKbJOMH8e8fn6nPaLVpK9HuscmqQc6SXj@mail.gmail.com>
References: <AANLkTilAqisq4_U-5IMLrenaezWAFft3Ya22uYYf7Wia@mail.gmail.com> 
	<AANLkTilSyggGPxuk-I6455ts6KH2EBUWhL7xBrekvIyb@mail.gmail.com> 
	<AANLkTiljhBhvMGpWeGPBaPoEDRqj3TeOKr-r-qJO76XM@mail.gmail.com> 
	<AANLkTin311-SC_Ehmedsc5FW7XYRkib7oz5Tr66mUqAk@mail.gmail.com> 
	<AANLkTimLk_qsaqWKvFVWpVfCmblH_IxiR9LvlzZM35_G@mail.gmail.com> 
	<AANLkTimGZ-PwKbJOMH8e8fn6nPaLVpK9HuscmqQc6SXj@mail.gmail.com>
Message-ID: <AANLkTinJ5Iwo-H_bAIb7cIRBni0XLoZnNWH1SKXq-6_g@mail.gmail.com>

A point in time, if it relates to an I-frame, is very small set and it
represents an image.

It would be interesting to have
<img src="file.ogg#t=1:00.5,1:00.5">

or animated images in the sense of:
<img src="file.ogg#t=1:00,1:15">

I think the earlier post was looking to display video thumbnails using
this sort of fragment notation.

If the video wasn't being played I would hope that a browser would
fetch the meta data first and then just seek the byte ranges for that
fragment.

On Fri, Jul 2, 2010 at 4:55 AM, Silvia Pfeiffer
<silviapfeiffer1 at gmail.com> wrote:
> Actually, a point in time is nothing - it's an empty set. You never
> want to actually point to a point in time, but rather to either the
> point in time and an interval after that point in time, or everything
> from that point onwards. That's what these URIs represent.
>
> Cheers,
> Silvia.
>
> On Fri, Jul 2, 2010 at 7:56 AM, Jonas Sicking <jonas at sicking.cc> wrote:
>> That would be great. I guess it's unclear to me how the UIs would differ for
>>
>> video.ogv#t=40,50
>> and
>> video.ogv#t=40
>>
>> In particular it seems strange to me that video.ogv#t=40 represents
>> the whole range from the selected point to the end of the video, given
>> that most commonly when wanting to point out a particular point in a
>> video you actually just want to represent a point.
>>
>> / Jonas
>>
>> On Thu, Jul 1, 2010 at 2:46 AM, Silvia Pfeiffer
>> <silviapfeiffer1 at gmail.com> wrote:
>>> BTW: I will try and make a screencast of that firefox plugin, which
>>> should clarify things further. Stay tuned...
>>> Cheers,
>>> Silvia.
>>>
>>>
>>> On Thu, Jul 1, 2010 at 7:44 PM, Silvia Pfeiffer
>>> <silviapfeiffer1 at gmail.com> wrote:
>>>> Hi Jonas,
>>>>
>>>> On Thu, Jul 1, 2010 at 4:41 AM, Jonas Sicking <jonas at sicking.cc> wrote:
>>>>> Hi Silvia,
>>>>>
>>>>> Back in may last year I brought [1] up the fact that there are two use
>>>>> cases for temporal media fragments:
>>>>>
>>>>> 1. Skipping to a particular point in a longer resource, such as
>>>>> wanting to start a video at a particular point while still allowing
>>>>> seeking in the entire resource. This is currently supported by for
>>>>> example YouTube [2]. It is also the model used for web pages where
>>>>> including a fragment identifier only scrolls to a particular point,
>>>>> while allowing the user to scroll to any point both before and after
>>>>> the identified fragment.
>>>>>
>>>>> 2. Only displaying part of a video. For example out of a longer video
>>>>> from a discussion panel, only displaying the part where a specific
>>>>> topic is discussed.
>>>>>
>>>>> While there seemed to be agreement [3][4] that these are in fact two
>>>>> separate use cases, it seems like the media fragments draft is only
>>>>> attempting to address one. Additionally, it only addresses the one
>>>>> that has the least precedence as far as current technologies on the
>>>>> web goes.
>>>>>
>>>>> Was this an intentional omission? Is it planned to solve use case 1
>>>>> above in a future revision?
>>>>>
>>>>> [1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-May/019596.html
>>>>> [2] http://www.youtube.com/watch?v=fyQrKvc7_NU#t=201
>>>>> [3] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-May/019718.html
>>>>> [4] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-May/019721.html
>>>>
>>>>
>>>> I think you may have misunderstood the specification. Use case 1 is
>>>> indeed the main use case being addressed in the specification. There
>>>> is a Firefox plugin implementation[1] of the specification that shows
>>>> exactly use case 1 in a video element - a URI with a fragment such as
>>>> video.ogv#t=40,50 is being included in a <video> element and the
>>>> effect is that the video is displayed from 40s to 50s, but the
>>>> transport bar (or controls) are still those of the complete resource,
>>>> so you can still seek to any position.
>>>>
>>>> To be sure, this is just a recommendation of how it is supposed to be
>>>> implemented (see
>>>> http://www.w3.org/TR/media-frags/#media-fragment-display). The group
>>>> only defined what URIs look like that point to such a segment - it
>>>> cannot prescribe what an application (such as a HTML document) does
>>>> with the URI. I would propose that this discussion should be had about
>>>> HTML5 and a sentence be added to the HTML5 spec on how UAs are
>>>> expected to deal with such segments.
>>>>
>>>> Further, if you are indeed only interested in a subpart of the
>>>> original media resource and want to completely blend out all context
>>>> (i.e. all other bits of the media resource), you should be using the
>>>> URI query addressing method instead of the URI fragment, e.g.
>>>> video.ogv?t=40,50. This URI is supposed to create a new resource that
>>>> consist only of the segment - it will only do so, of course, if your
>>>> server supports this functionality.
>>>>
>>>> All of this is described in more detail in the spec [2]. If that is
>>>> unclear or anything is confusing, please do point it out so it can be
>>>> fixed.
>>>>
>>>> Best Regards,
>>>> Silvia.
>>>>
>>>>
>>>>
>>>> [1] http://www.w3.org/2008/WebVideo/Fragments/code/plugin/ (expect some bugs)
>>>> [2] http://www.w3.org/TR/media-frags/
>>>>
>>>
>>
>

From marques at displague.com  Fri Jul  2 03:40:09 2010
From: marques at displague.com (Marques Johansson)
Date: Fri, 2 Jul 2010 06:40:09 -0400
Subject: [whatwg] More YouTube response
In-Reply-To: <AANLkTilZAYKX85Q7ZszPxJUEPtxaQi0u5B8ldx6U9JfW@mail.gmail.com>
References: <AANLkTinbe-p-STmyfGAiGA6NR7cZO-nzqlq405O5gGTd@mail.gmail.com>
	<AANLkTikmbiM2Vjx2HbhU893BIXOVdb2eG5EJ8LJIB9js@mail.gmail.com>
	<AANLkTim2hSVrfXscKjGFNEECZWUmrEwyeS7lXXgtMfL4@mail.gmail.com>
	<AANLkTimyE_mORMHCJgfcOLCvJMs6dJV2LHUfj5H_XV8E@mail.gmail.com>
	<AANLkTilZAYKX85Q7ZszPxJUEPtxaQi0u5B8ldx6U9JfW@mail.gmail.com>
Message-ID: <AANLkTikVhV7-zgv5UQwFbbxuaV_Y1wx6mpAaHwiA9-wg@mail.gmail.com>

If the seek method was further hookable it should be possible to add decrypt
or  transcode methods to interpret the fetched content, possibly requesting
more data to the filter stream bucket, before apending the bytes of media.

On Jul 2, 2010 6:10 AM, "Marques Johansson" <marques at displague.com> wrote:

On Thu, Jul 1, 2010 at 6:59 PM, John Harding <jharding at google.com> wrote:
> 2. Robust Video Streamin...
I was muddling my recent requests related to "browser fetch" behavior
and "application-controlled video delivery: with the despised topic of
DRM and content protection.  Thanks for clearing that up, John.

If a seek on a HTMLMediaElement's exposed and passed along the XHR
Request to a fetcher method then I could set my constraints for the
impending request.  I would add HTTP Range headers if they are not
present and set a Range upper bound (since the server will return
402,403, or 416 on any "Range: bytes x-" request to retrieve the full
remaining content).

The initiating caller would need to understand that the length of data
requested may have shrunk (which would require the browser to seek
again when the content was all played up or when the buffer was
running low - things that should already be in place).  This, to me,
seems like an alternative to an addBytes method (if that does what I
think it does).

This would provide me with a strictly Javascript solution.  Other
methods I have been asking for would give me a purely HTTP solution
(with new range related 4xxs and, spec endorsed, shorter than
requested 206 responses) to achieve this or an HTML solution (using
new video+source element attributes for buffer (min request size) and
max request size).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100702/df4ae321/attachment.htm>

From annevk at opera.com  Fri Jul  2 04:38:16 2010
From: annevk at opera.com (Anne van Kesteren)
Date: Fri, 02 Jul 2010 13:38:16 +0200
Subject: [whatwg] More YouTube response
In-Reply-To: <1278065580.10898.7.camel@shane-laptop>
References: <1267897846.990.1278063443760.JavaMail.root@cm-mail03.mozilla.org>
	<1278065580.10898.7.camel@shane-laptop>
Message-ID: <op.ve7rxmh064w2qv@annevk-t60>

On Fri, 02 Jul 2010 12:13:00 +0200, Shane Fagan  
<shanepatrickfagan at ubuntu.com> wrote:
> Well this isnt really a list where we should talk about the dos and
> donts of web content distribution. DRM content can be embedded in the
> video tag and decoded using installable plugins so its not really an
> issue for this list I dont think. We cant dictate how the specs are used
> so try to keep the conversation technology neutral.

Whether playing video requires a plugin is very much an issue for this  
list, I think. What Henri explained -- not having lock-in to a particular  
platform because of proprietary plugins -- is a large part of the reason  
why we have <video> in the first place.


-- 
Anne van Kesteren
http://annevankesteren.nl/

From invitation at mydailyflogmail.com  Fri Jul  2 04:49:24 2010
From: invitation at mydailyflogmail.com (nanda kumar)
Date: Fri, 2 Jul 2010 06:49:24 -0500
Subject: [whatwg] 1 new photo on MyDailyFlog!
Message-ID: <042b78010795a18d3c4a0a995b777804@www.mydailyflog.com>


Hi!
I would like you to come and see my latest photos on MyDailyFlog. 

Check out: http://www.mydailyflog.com/go/invite_register/nandhu_mdf/67426545&stc=71

Thanks!
nanda kumar



~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
To unsubscribe of this type of email from MyDailyFlog in the future,
please click below:
http://www.mydailyflog.com/un/whatwg at lists.whatwg.org&md5=57c70ecf3790c7b9&bl=16

Please do not reply directly to this email. Questions? Contact us - 
http://www.mydailyflog.com/go/contact_us

MyDailyFlog, Refriendz Ltd. PO BOX 1184, Luton, Bedfordshire, LU1 9AT.



From invitation at mydailyflog.com  Fri Jul  2 04:49:23 2010
From: invitation at mydailyflog.com (nanda kumar)
Date: Fri, 2 Jul 2010 06:49:23 -0500
Subject: [whatwg] Check out this photo on MyDailyFlog!
Message-ID: <a20a535f624de87dbbb7ab6fb5015ddb@www.mydailyflog.com>


Hi!
I would like to invite you to visit MyDailyFlog and see my latest photos. 

Check out: http://www.mydailyflog.com/go/invite_register/nandhu_mdf/67426545&stc=16

Cheers!

nanda kumar


========================================
Got a digital camera?

MyDailyFlog is a personal photo-blogging space where you can easily post
your latest and greatest photos, and share them with your friends and family.

Create your own DailyFlog at www.MyDailyFlog.com





~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Unsubscribe: to opt out of further invitations from your friends to see 
their DailyFlogs, please click below:
http://www.mydailyflog.com/un/whatwg at lists.whatwg.org&md5=57c70ecf3790c7b9&bl=16

Please do not reply directly to this email. Questions? Contact us - 
http://www.mydailyflog.com/go/contact_us

MyDailyFlog, Refriendz Ltd. PO BOX 1184, Luton, Bedfordshire, LU1 9AT.



From julian.reschke at gmx.de  Fri Jul  2 04:56:39 2010
From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri, 02 Jul 2010 13:56:39 +0200
Subject: [whatwg] More YouTube response
In-Reply-To: <op.ve7rxmh064w2qv@annevk-t60>
References: <1267897846.990.1278063443760.JavaMail.root@cm-mail03.mozilla.org>	<1278065580.10898.7.camel@shane-laptop>
	<op.ve7rxmh064w2qv@annevk-t60>
Message-ID: <4C2DD3F7.6020201@gmx.de>

On 02.07.2010 13:38, Anne van Kesteren wrote:
> On Fri, 02 Jul 2010 12:13:00 +0200, Shane Fagan
> <shanepatrickfagan at ubuntu.com> wrote:
>> Well this isnt really a list where we should talk about the dos and
>> donts of web content distribution. DRM content can be embedded in the
>> video tag and decoded using installable plugins so its not really an
>> issue for this list I dont think. We cant dictate how the specs are used
>> so try to keep the conversation technology neutral.
>
> Whether playing video requires a plugin is very much an issue for this
> list, I think. What Henri explained -- not having lock-in to a
> particular platform because of proprietary plugins -- is a large part of
> the reason why we have <video> in the first place.

That may be true.

But there's nothing in the spec that actually disallows adding support 
for plugin-based DRM, right? (Just clarifying)

Best regards, Julian


From shanepatrickfagan at ubuntu.com  Fri Jul  2 05:17:52 2010
From: shanepatrickfagan at ubuntu.com (Shane Fagan)
Date: Fri, 02 Jul 2010 13:17:52 +0100
Subject: [whatwg] More YouTube response
In-Reply-To: <op.ve7rxmh064w2qv@annevk-t60>
References: <1267897846.990.1278063443760.JavaMail.root@cm-mail03.mozilla.org>
	<1278065580.10898.7.camel@shane-laptop> <op.ve7rxmh064w2qv@annevk-t60>
Message-ID: <1278073072.11770.10.camel@shane-laptop>

On Fri, 2010-07-02 at 13:38 +0200, Anne van Kesteren wrote:
> On Fri, 02 Jul 2010 12:13:00 +0200, Shane Fagan  
> <shanepatrickfagan at ubuntu.com> wrote:
> > Well this isnt really a list where we should talk about the dos and
> > donts of web content distribution. DRM content can be embedded in the
> > video tag and decoded using installable plugins so its not really an
> > issue for this list I dont think. We cant dictate how the specs are used
> > so try to keep the conversation technology neutral.
> 
> Whether playing video requires a plugin is very much an issue for this  
> list, I think. What Henri explained -- not having lock-in to a particular  
> platform because of proprietary plugins -- is a large part of the reason  
> why we have <video> in the first place.
> 
> 

Well I got that from what Henri was saying. The reason why I said that
was that we cant tell people how to use the spec. The video tag could be
used for any kind of video be it a DRM video or non DRM .webm or .mp4
video, its really vendor preference on what they use. Shipping the DRM
codec as a plugin will be a lot smaller and a lot easier than shipping
the entire flash platform so it would be better than the current
situation. 

I have to clarify that im against DRM anyway because not only does it
not protect the content well in most cases but also most of it doesnt
work on Linux by default. All im saying is that if youtube has a problem
with html5 and want content protection through DRM then thats their
decision. 

--fagan


From marques at displague.com  Fri Jul  2 05:27:42 2010
From: marques at displague.com (Marques Johansson)
Date: Fri, 2 Jul 2010 08:27:42 -0400
Subject: [whatwg] More YouTube response
In-Reply-To: <1278073072.11770.10.camel@shane-laptop>
References: <1267897846.990.1278063443760.JavaMail.root@cm-mail03.mozilla.org>
	<1278065580.10898.7.camel@shane-laptop> <op.ve7rxmh064w2qv@annevk-t60> 
	<1278073072.11770.10.camel@shane-laptop>
Message-ID: <AANLkTinhbIWTogfGj_mQlerSelsUmabndw0sLkUr7x4g@mail.gmail.com>

If there were hooks for handling the bytes being requested and
supplied to the media object, would you agree that DRM modules could
be written with Javascript (if a bit of a straw man - as all DRM is
perceived to varying degrees)? I think this could prevent the need for
some plugins.

On Fri, Jul 2, 2010 at 8:17 AM, Shane Fagan
<shanepatrickfagan at ubuntu.com> wrote:
> On Fri, 2010-07-02 at 13:38 +0200, Anne van Kesteren wrote:
>> On Fri, 02 Jul 2010 12:13:00 +0200, Shane Fagan
>> <shanepatrickfagan at ubuntu.com> wrote:
>> > Well this isnt really a list where we should talk about the dos and
>> > donts of web content distribution. DRM content can be embedded in the
>> > video tag and decoded using installable plugins so its not really an
>> > issue for this list I dont think. We cant dictate how the specs are used
>> > so try to keep the conversation technology neutral.
>>
>> Whether playing video requires a plugin is very much an issue for this
>> list, I think. What Henri explained -- not having lock-in to a particular
>> platform because of proprietary plugins -- is a large part of the reason
>> why we have <video> in the first place.
>>
>>
>
> Well I got that from what Henri was saying. The reason why I said that
> was that we cant tell people how to use the spec. The video tag could be
> used for any kind of video be it a DRM video or non DRM .webm or .mp4
> video, its really vendor preference on what they use. Shipping the DRM
> codec as a plugin will be a lot smaller and a lot easier than shipping
> the entire flash platform so it would be better than the current
> situation.
>
> I have to clarify that im against DRM anyway because not only does it
> not protect the content well in most cases but also most of it doesnt
> work on Linux by default. All im saying is that if youtube has a problem
> with html5 and want content protection through DRM then thats their
> decision.
>
> --fagan
>
>

From aral at aralbalkan.com  Fri Jul  2 05:39:31 2010
From: aral at aralbalkan.com (Aral Balkan)
Date: Fri, 2 Jul 2010 13:39:31 +0100
Subject: [whatwg] Resolutions meta tag proposal
Message-ID: <AANLkTinvknm7dSA_Er_xC1MOZFE6dA5M1X01wEgtpa7T@mail.gmail.com>

I just submitted a proposal for a new meta tag to flag that
high-resolution images are available and should be loaded in place of
low-resolution ones for users with high-PPI displays (like the new
iPhone 4's Retina display).

Please see:

http://wiki.whatwg.org/wiki/MetaExtensions#Proposals

(Currently, although you can use the min-device-pixel-ratio CSS Media
Query to achieve this for background images, no such mechanism exists
for images displayed via the <img> tag short of setting a flag in CSS
and using image substitution via JavaScript. This new meta tag
proposes a JavaScript-free and easy-to-author mechanism to handle the
above use case.)

I look forward to hearing your thoughts :)

All the best,
Aral

From lachlan.hunt at lachy.id.au  Fri Jul  2 05:50:50 2010
From: lachlan.hunt at lachy.id.au (Lachlan Hunt)
Date: Fri, 02 Jul 2010 14:50:50 +0200
Subject: [whatwg] More YouTube response
In-Reply-To: <4C2DD3F7.6020201@gmx.de>
References: <1267897846.990.1278063443760.JavaMail.root@cm-mail03.mozilla.org>	<1278065580.10898.7.camel@shane-laptop>	<op.ve7rxmh064w2qv@annevk-t60>
	<4C2DD3F7.6020201@gmx.de>
Message-ID: <4C2DE0AA.5060009@lachy.id.au>

On 2010-07-02 13:56, Julian Reschke wrote:
> On 02.07.2010 13:38, Anne van Kesteren wrote:
>> On Fri, 02 Jul 2010 12:13:00 +0200, Shane Fagan
>> <shanepatrickfagan at ubuntu.com> wrote:
>>> Well this isnt really a list where we should talk about the dos and
>>> donts of web content distribution. DRM content can be embedded in the
>>> video tag and decoded using installable plugins so its not really an
>>> issue for this list I dont think. We cant dictate how the specs are used
>>> so try to keep the conversation technology neutral.
>>
>> Whether playing video requires a plugin is very much an issue for this
>> list, I think. What Henri explained -- not having lock-in to a
>> particular platform because of proprietary plugins -- is a large part of
>> the reason why we have <video> in the first place.
>
> That may be true.
>
> But there's nothing in the spec that actually disallows adding support
> for plugin-based DRM, right? (Just clarifying)

Correct. Vendors can theoretically implement any codec or container they 
like, with any features or limitations they like.

MP4 already has various DRM schemes in use.  Apple, for example, could 
support FairPlay protected videos, though the use of such content with 
<video> would effectively be limited to within iTunes.

Even Matroska has elements that can be used for general purpose 
encryption and DRM purposes, though these features were not included 
within WebM.  But theoretically, those features could be added and 
implemented with some agreed upon encryption scheme.

I would still, however, argue against anything of the sort being added 
to WebM because DRM doesn't do anything to protect content, but is 
rather used as a way for content providers to control the market by 
blocking unwanted innovation and competition that they don't like, 
including open source software.

-- 
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

From marques at displague.com  Fri Jul  2 06:13:01 2010
From: marques at displague.com (Marques Johansson)
Date: Fri, 2 Jul 2010 09:13:01 -0400
Subject: [whatwg] Resolutions meta tag proposal
In-Reply-To: <AANLkTinvknm7dSA_Er_xC1MOZFE6dA5M1X01wEgtpa7T@mail.gmail.com>
References: <AANLkTinvknm7dSA_Er_xC1MOZFE6dA5M1X01wEgtpa7T@mail.gmail.com>
Message-ID: <AANLkTin-D2I3Qzo0gj_ciuPN4TFuf2uMeq2uxNbjnV0q@mail.gmail.com>

On Fri, Jul 2, 2010 at 8:39 AM, Aral Balkan <aral at aralbalkan.com> wrote:
> ...
> http://wiki.whatwg.org/wiki/MetaExtensions#Proposals

"In this case, the developer would provide 2x, 4x, and 8x versions of all
images. So, in the running example, she would make flower.jpg, flower at 2x.jpg,
flower at 4x.jpg, and"

And what if the image was named "images/flower" (using the accept header to
send a jpg vs png vs gif) instead of "flower.jpg".  The browser would need
to have rules about how to rewrite the name of the file.  I think "@" in the
filename would break the many Dos 6.22 based web servers ;-).

I don't think a single element with a single attribute can handle this
problem.

What about an HTTP header like:

Accept: image/*;ppiratio=2

This would allow the server to send the correct images for that client or
return a 307 to the rewritten filename as the server deems fit.  A new
Accept property doesn't seem to require changing any specs.   I'ld like to
think that image/*;q=x could be used in some way for this.

On Fri, Jul 2, 2010 at 8:39 AM, Aral Balkan <aral at aralbalkan.com> wrote:
> I just submitted a proposal for a new meta tag to flag that
> high-resolution images are available and should be loaded in place of
> low-resolution ones for users with high-PPI displays (like the new
> iPhone 4's Retina display).
>
> Please see:
>
> http://wiki.whatwg.org/wiki/MetaExtensions#Proposals
>
> (Currently, although you can use the min-device-pixel-ratio CSS Media
> Query to achieve this for background images, no such mechanism exists
> for images displayed via the <img> tag short of setting a flag in CSS
> and using image substitution via JavaScript. This new meta tag
> proposes a JavaScript-free and easy-to-author mechanism to handle the
> above use case.)
>
> I look forward to hearing your thoughts :)
>
> All the best,
> Aral
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100702/e8164bcf/attachment.htm>

From silviapfeiffer1 at gmail.com  Fri Jul  2 06:20:05 2010
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Fri, 2 Jul 2010 23:20:05 +1000
Subject: [whatwg] media resources: addressing media fragments through
	URIs spec
In-Reply-To: <AANLkTinJ5Iwo-H_bAIb7cIRBni0XLoZnNWH1SKXq-6_g@mail.gmail.com>
References: <AANLkTilAqisq4_U-5IMLrenaezWAFft3Ya22uYYf7Wia@mail.gmail.com> 
	<AANLkTilSyggGPxuk-I6455ts6KH2EBUWhL7xBrekvIyb@mail.gmail.com> 
	<AANLkTiljhBhvMGpWeGPBaPoEDRqj3TeOKr-r-qJO76XM@mail.gmail.com> 
	<AANLkTin311-SC_Ehmedsc5FW7XYRkib7oz5Tr66mUqAk@mail.gmail.com> 
	<AANLkTimLk_qsaqWKvFVWpVfCmblH_IxiR9LvlzZM35_G@mail.gmail.com> 
	<AANLkTimGZ-PwKbJOMH8e8fn6nPaLVpK9HuscmqQc6SXj@mail.gmail.com> 
	<AANLkTinJ5Iwo-H_bAIb7cIRBni0XLoZnNWH1SKXq-6_g@mail.gmail.com>
Message-ID: <AANLkTinEua8Qr5K1vBZvSkLClKDp4DNcRm2pPTICrI__@mail.gmail.com>

The idea or returning a single image for a URI that points at a video
has indeed been discussed. It is not possible to do with a URI
fragment, since a URI fragment (#) can only return the same mime type
as the main URI. But the suggestion for this is to use a URI query.
Then, it is possible to return an image. A URI scheme such as
video.ogv?image=64 could be used to provide this (or anything else
that your server will make up and provide to clients). Since providing
an image in return for a video URI requires some form of
"transcoding", a URI query is the only way to realise this.

On Fri, Jul 2, 2010 at 8:18 PM, Marques Johansson <marques at displague.com> wrote:
> A point in time, if it relates to an I-frame, is very small set and it
> represents an image.
>
> It would be interesting to have
> <img src="file.ogg#t=1:00.5,1:00.5">
>
> or animated images in the sense of:
> <img src="file.ogg#t=1:00,1:15">

(Note: I'm sure you meant s/ogg/ogv/ so we can talk about video files.)

This latter one is already defined as a 5 sec video extract from the
full file.ogv - it's not possible to overload that with turning the
byte range into an animated gif. You will also need to use transcoding
for this and thus will want to create a new URI query scheme.


> I think the earlier post was looking to display video thumbnails using
> this sort of fragment notation.
>
> If the video wasn't being played I would hope that a browser would
> fetch the meta data first and then just seek the byte ranges for that
> fragment.

The whole media fragment URI spec is based on retrieving byte ranges.
I'd encourage you to read it and see if it matches your expectations.

Cheers,
Silvia.


> On Fri, Jul 2, 2010 at 4:55 AM, Silvia Pfeiffer
> <silviapfeiffer1 at gmail.com> wrote:
>> Actually, a point in time is nothing - it's an empty set. You never
>> want to actually point to a point in time, but rather to either the
>> point in time and an interval after that point in time, or everything
>> from that point onwards. That's what these URIs represent.
>>
>> Cheers,
>> Silvia.
>>
>> On Fri, Jul 2, 2010 at 7:56 AM, Jonas Sicking <jonas at sicking.cc> wrote:
>>> That would be great. I guess it's unclear to me how the UIs would differ for
>>>
>>> video.ogv#t=40,50
>>> and
>>> video.ogv#t=40
>>>
>>> In particular it seems strange to me that video.ogv#t=40 represents
>>> the whole range from the selected point to the end of the video, given
>>> that most commonly when wanting to point out a particular point in a
>>> video you actually just want to represent a point.
>>>
>>> / Jonas
>>>
>>> On Thu, Jul 1, 2010 at 2:46 AM, Silvia Pfeiffer
>>> <silviapfeiffer1 at gmail.com> wrote:
>>>> BTW: I will try and make a screencast of that firefox plugin, which
>>>> should clarify things further. Stay tuned...
>>>> Cheers,
>>>> Silvia.
>>>>
>>>>
>>>> On Thu, Jul 1, 2010 at 7:44 PM, Silvia Pfeiffer
>>>> <silviapfeiffer1 at gmail.com> wrote:
>>>>> Hi Jonas,
>>>>>
>>>>> On Thu, Jul 1, 2010 at 4:41 AM, Jonas Sicking <jonas at sicking.cc> wrote:
>>>>>> Hi Silvia,
>>>>>>
>>>>>> Back in may last year I brought [1] up the fact that there are two use
>>>>>> cases for temporal media fragments:
>>>>>>
>>>>>> 1. Skipping to a particular point in a longer resource, such as
>>>>>> wanting to start a video at a particular point while still allowing
>>>>>> seeking in the entire resource. This is currently supported by for
>>>>>> example YouTube [2]. It is also the model used for web pages where
>>>>>> including a fragment identifier only scrolls to a particular point,
>>>>>> while allowing the user to scroll to any point both before and after
>>>>>> the identified fragment.
>>>>>>
>>>>>> 2. Only displaying part of a video. For example out of a longer video
>>>>>> from a discussion panel, only displaying the part where a specific
>>>>>> topic is discussed.
>>>>>>
>>>>>> While there seemed to be agreement [3][4] that these are in fact two
>>>>>> separate use cases, it seems like the media fragments draft is only
>>>>>> attempting to address one. Additionally, it only addresses the one
>>>>>> that has the least precedence as far as current technologies on the
>>>>>> web goes.
>>>>>>
>>>>>> Was this an intentional omission? Is it planned to solve use case 1
>>>>>> above in a future revision?
>>>>>>
>>>>>> [1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-May/019596.html
>>>>>> [2] http://www.youtube.com/watch?v=fyQrKvc7_NU#t=201
>>>>>> [3] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-May/019718.html
>>>>>> [4] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-May/019721.html
>>>>>
>>>>>
>>>>> I think you may have misunderstood the specification. Use case 1 is
>>>>> indeed the main use case being addressed in the specification. There
>>>>> is a Firefox plugin implementation[1] of the specification that shows
>>>>> exactly use case 1 in a video element - a URI with a fragment such as
>>>>> video.ogv#t=40,50 is being included in a <video> element and the
>>>>> effect is that the video is displayed from 40s to 50s, but the
>>>>> transport bar (or controls) are still those of the complete resource,
>>>>> so you can still seek to any position.
>>>>>
>>>>> To be sure, this is just a recommendation of how it is supposed to be
>>>>> implemented (see
>>>>> http://www.w3.org/TR/media-frags/#media-fragment-display). The group
>>>>> only defined what URIs look like that point to such a segment - it
>>>>> cannot prescribe what an application (such as a HTML document) does
>>>>> with the URI. I would propose that this discussion should be had about
>>>>> HTML5 and a sentence be added to the HTML5 spec on how UAs are
>>>>> expected to deal with such segments.
>>>>>
>>>>> Further, if you are indeed only interested in a subpart of the
>>>>> original media resource and want to completely blend out all context
>>>>> (i.e. all other bits of the media resource), you should be using the
>>>>> URI query addressing method instead of the URI fragment, e.g.
>>>>> video.ogv?t=40,50. This URI is supposed to create a new resource that
>>>>> consist only of the segment - it will only do so, of course, if your
>>>>> server supports this functionality.
>>>>>
>>>>> All of this is described in more detail in the spec [2]. If that is
>>>>> unclear or anything is confusing, please do point it out so it can be
>>>>> fixed.
>>>>>
>>>>> Best Regards,
>>>>> Silvia.
>>>>>
>>>>>
>>>>>
>>>>> [1] http://www.w3.org/2008/WebVideo/Fragments/code/plugin/ (expect some bugs)
>>>>> [2] http://www.w3.org/TR/media-frags/
>>>>>
>>>>
>>>
>>
>

From aral at aralbalkan.com  Fri Jul  2 06:28:14 2010
From: aral at aralbalkan.com (Aral Balkan)
Date: Fri, 2 Jul 2010 14:28:14 +0100
Subject: [whatwg] Resolutions meta tag proposal
In-Reply-To: <AANLkTin-D2I3Qzo0gj_ciuPN4TFuf2uMeq2uxNbjnV0q@mail.gmail.com>
References: <AANLkTinvknm7dSA_Er_xC1MOZFE6dA5M1X01wEgtpa7T@mail.gmail.com>
	<AANLkTin-D2I3Qzo0gj_ciuPN4TFuf2uMeq2uxNbjnV0q@mail.gmail.com>
Message-ID: <AANLkTin-EwYWnluo1I_yZxCGbJdEFZZpWZUTLunx7zrs@mail.gmail.com>

Hi Marques,

I'm an interaction designer/developer, not a rocket scientist. :) A
meta tag, I can easily add. If you start talking about HTTP headers,
you've lost me.

i.e., this is meant to be a pragmatic, easy-to-author solution.

Thanks,
Aral

On Fri, Jul 2, 2010 at 2:13 PM, Marques Johansson <marques at displague.com> wrote:
<snip>
> And what if the image was named "images/flower" (using the accept header to
> send a jpg vs png vs gif) instead of "flower.jpg". ?The browser would need
> to have rules about how to rewrite the name of the file. ?I think "@" in the
> filename would break the many Dos 6.22 based web servers ;-).
> I don't think a single element with a single attribute can handle this
> problem.
> What about an HTTP header like:
> Accept: image/*;ppiratio=2
> This would allow the server to send the correct images for that client or
> return a 307 to the rewritten filename as the server deems fit. ?A new
> Accept property doesn't seem to require changing any specs. ??I'ld like to
> think that image/*;q=x could be used in some way for this.
> On Fri, Jul 2, 2010 at 8:39 AM, Aral Balkan <aral at aralbalkan.com> wrote:
>> I just submitted a proposal for a new meta tag to flag that
>> high-resolution images are available and should be loaded in place of
>> low-resolution ones for users with high-PPI displays (like the new
>> iPhone 4's Retina display).
>>
>> Please see:
>>
>> http://wiki.whatwg.org/wiki/MetaExtensions#Proposals
<snip>

From svartman95 at gmail.com  Fri Jul  2 07:57:45 2010
From: svartman95 at gmail.com (bjartur)
Date: Fri, 02 Jul 2010 14:57:45 +0000
Subject: [whatwg] HTML 5 : The Youtube response
In-Reply-To: <1277948843.29657.23.camel@shane-laptop>
References: <20100630093438.M86436@ossreleasefeed.com>
	<AANLkTikc__HfZtauZSS4mM8vs_nQPjzB3BNE3d-Knmvj@mail.gmail.com>
	<AANLkTimNjextTEuYS46NoHMTIdF90PgYZ67_wnYDOqxL@mail.gmail.com>
	<4956CA5A-C4ED-4CE3-BBD2-B2ACF0E23CE4@apple.com>
	<1277948843.29657.23.camel@shane-laptop>
Message-ID: <4c2dfe6f.093adf0a.66f3.1771@mx.google.com>

> On Wed, 2010-06-30 at 18:11 -0700, David Singer wrote:
> > I think it's interesting to look at these and ask to what extent they are in scope.
> >
> > > 1. Standard video format
> > > 2. Robust video streaming
> > > 3. Content Protection
> > > 4. Encapsulation + embedding
> > > 5. Fullscreen video
> > > 6. Camera and Microphone access
> >

> > #4 is soluble 'on top of' HTML5 and the media formats, if needed.  Web Archives, Web Apps, and so on.  I think.
> >
Yes, <iframe>s, <objec>s and <audio>/<video>s should solve the problem of
embedding, and (if I understand the meaning of "Encapsulation" correctly)
<html> wrappers should solve encapsulation as well.

> > #5 is a problem only if you care about phishing attacks...or indeed apps that have the gall to believe that you should be able to see nothing else when they are running.
> >
> 
> We talked about this a week or two ago and the idea was to have a "allow
> full screen" element in the video tag that makes a control that can be
> used by the user to go full screen. The problem here is abuse but I
> think the browser vendors should make some safeguards if this is the
> route they take.
> 
> > #6 is well, rather different from the problem of delivering a/v to a user.  I'm not enthusiastic about web pages that can listen to me or watch me, myself...
> >
Agreed, such access for web pages should be limited to <input
type=file>. That would require the user to "go out of his way" to grossly
violate his privacy rather than "just clicking OK" or being click-jacked
into approving of recording of himself (such as with interactive
JavaScripts and CSS'd images of hot women labeled "Click here for more").

> Camera and mic access could be done in the spec IMO and it would be
> useful. How its implemented would be interesting. For sites like
> hotmail, gmail, youtube(for their webcam capture)..etc that have
> integrated chat it would be very useful. Obviously in terms of
> implementation they would have to safe guard by asking. Id look for
> something as simple as <webcam /> or <mic /> or something and dont have
> any parameters and allow the browser to work out what to do would be ok
> to put in the spec. Its a little bit out there but I think it would be
> beneficial if its a blocker for some sites.
Will <webcam> and <mic> be <form> elements, interactive content that can
go anywhere in a web page? If the latter, what whould HTML renderers
do with it? But you're probably thinking about <device>, save the no
@attrs suggestion.

I for one don't understand why this would be any better than (in the
case of <form> elements) <input type=file accept="video/*"|"audio/*">
and for more complex and esoteric use cases (i.e. "webapps"), the device
APIs from the DAP WG of W3C.

From ifette at google.com  Fri Jul  2 08:28:41 2010
From: ifette at google.com (=?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?=)
Date: Fri, 2 Jul 2010 08:28:41 -0700
Subject: [whatwg] HTML 5 : The Youtube response
In-Reply-To: <FECE7E41-95DF-41CF-B65F-64D03DFFE29A@apple.com>
References: <20100630093438.M86436@ossreleasefeed.com>
	<AANLkTikc__HfZtauZSS4mM8vs_nQPjzB3BNE3d-Knmvj@mail.gmail.com>
	<AANLkTimNjextTEuYS46NoHMTIdF90PgYZ67_wnYDOqxL@mail.gmail.com>
	<4956CA5A-C4ED-4CE3-BBD2-B2ACF0E23CE4@apple.com>
	<1277948843.29657.23.camel@shane-laptop>
	<5C06BA12-2566-4FE4-A17A-D430B38D263D@apple.com>
	<21719D7E-DEE8-4FDE-A7A1-28AD3A4A796E@geekhood.net>
	<8EE51233-8331-4070-A36D-6CDF4AD77947@apple.com>
	<AANLkTinwH5H2dL-DYNPCOacVHEexSYW7biIeGM0GPpuo@mail.gmail.com>
	<FECE7E41-95DF-41CF-B65F-64D03DFFE29A@apple.com>
Message-ID: <AANLkTilIFY6gRkX9IXZ11w-cUw24NjL34Gh_HZoxXV9N@mail.gmail.com>

Also related discussion, where I proposed something similar on WHATWG:

http://www.mail-archive.com/whatwg at lists.whatwg.org/msg21565.html

On Thu, Jul 1, 2010 at 2:02 PM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> On Jul 1, 2010, at 1:37 PM, Kevin Carle wrote:
>
> One part of (2) [well, debatably part, but related to video streaming] is
> the lack of visibility into stream behavior. I can't ask the video element
> questions about dropped frames, bitrate, etc. This is incredibly useful in
> Flash for getting streaming feedback, and means I really don't know how well
> the HTML5 player is working for users. The best I can do is waiting/stalled
> events which is nowhere near as granular.
>
>
> I agree that exposing info like that would be useful. What does the Flash
> API for this look like? What parts of the available data do you find most
> useful?
>
> Regards,
> Maciej
>
>
> -Kevin
>
> On Thu, Jul 1, 2010 at 9:16 AM, Maciej Stachowiak <mjs at apple.com> wrote:
>
>>
>> On Jul 1, 2010, at 6:12 AM, Kornel Lesinski wrote:
>>
>> >>
>> >> I believe we can allow arbitrary content to go fullscreen, along the
>> lines of what Robert O'Callahan has proposed on this list, if we impose
>> sufficient restrictions to mitigate the above risks. In my opinion, the
>> following measures would likely be sufficient:
>> >>
>> >> A) Have a distinctive animated sequence when an element goes into
>> full-screen mode. This helps the user understand what happened.
>> >> B) Limit the ability to go fullscreen to user gestures, much as many
>> browsers limit pop-ups. This prevents shenanigans from happening while the
>> user is away from the keyboard, and greatly limits the potential annoyance
>> factor.
>> >> C) On systems with keyboard/mouse input, limit the keys that may be
>> processed by fullscreen content to a small set, such as the set that Flash
>> limits to in full-screen mode: <
>> http://www.adobe.com/devnet/flashplayer/articles/fplayer10_security_changes_03.html#head5
>> >.
>> >> D) On multitouch devices with an onscreen keyboard as the normal means
>> of input, things are trickier, because it's possible for a dedicated
>> attacker to simulate the keyboard. My best idea is make sure that a visually
>> distinctive status indicator appears at the top of the screen even in
>> full-screen mode, since that is the norm on such platforms.
>> >> E) Reserve one or more obvious key combinations to exiting fullscreen
>> no matter what (Escape, perhaps Cmd+W/Ctrl+W).
>> >> F) Even on keyboard/mouse type systems, have some distinctive visual
>> affordance which is either always present or appears on mouse moves, and
>> which allows the user to exit full-screen mode.
>> >>
>> >> I think these measures greatly mitigate risks (1) and (2) above, and
>> open up highly valued functionality (full screen video) with a UI that users
>> will enjoy, and customizability that video hosting sites will appreciate.
>> >
>> > Another option (for low-res videos on desktop) might be to use lower
>> screen resolution when in full screen ? text and UI elements displayed by
>> attacker will look noticeably different.
>>
>> That would probably make the controls look ugly for video with custom
>> controls, and I suspect neither users nor content authors would appreciate
>> that. Interesting idea, though.
>>
>>  - Maciej
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100702/07bf1559/attachment.htm>

From Simetrical+w3c at gmail.com  Fri Jul  2 10:22:00 2010
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Fri, 2 Jul 2010 13:22:00 -0400
Subject: [whatwg] Resolutions meta tag proposal
In-Reply-To: <AANLkTinvknm7dSA_Er_xC1MOZFE6dA5M1X01wEgtpa7T@mail.gmail.com>
References: <AANLkTinvknm7dSA_Er_xC1MOZFE6dA5M1X01wEgtpa7T@mail.gmail.com>
Message-ID: <AANLkTil8ktnvX0v1eyQiSINLPhpZZMI1S-MZmxTUwmjx@mail.gmail.com>

On Fri, Jul 2, 2010 at 8:39 AM, Aral Balkan <aral at aralbalkan.com> wrote:
> I just submitted a proposal for a new meta tag to flag that
> high-resolution images are available and should be loaded in place of
> low-resolution ones for users with high-PPI displays (like the new
> iPhone 4's Retina display).
>
> Please see:
>
> http://wiki.whatwg.org/wiki/MetaExtensions#Proposals

I don't know what the right solution is for this problem (other than
"use SVG" :) ), but I don't think your proposal is workable.
Inevitably, some images will be available in different sizes and some
not, but your proposed meta tag will affect all images on the page.
Also, the author needs to be able to control the names of the resized
images to fit their needs -- on a site allowing user-uploaded images,
for instance, you might not be able to guarantee that there isn't
already a file named flower at 2x.jpg in the directory.

The most natural way to do something like this is probably along the
lines of content negotiation, but as we all know, that doesn't work
well in practice because it's hard for authors to set up.  Ideally,
you could have the browser include a Resolution: header or something
like that, saying what resolution it expects to see, and then the web
server should automatically try resizing the image to match (using
appropriate caching).  But this is too hard to deploy and control.

So I don't have any really good ideas.

From jharding at google.com  Fri Jul  2 12:01:31 2010
From: jharding at google.com (John Harding)
Date: Fri, 2 Jul 2010 12:01:31 -0700
Subject: [whatwg] More YouTube response
In-Reply-To: <4C2DE0AA.5060009@lachy.id.au>
References: <1267897846.990.1278063443760.JavaMail.root@cm-mail03.mozilla.org>
	<1278065580.10898.7.camel@shane-laptop> <op.ve7rxmh064w2qv@annevk-t60> 
	<4C2DD3F7.6020201@gmx.de> <4C2DE0AA.5060009@lachy.id.au>
Message-ID: <AANLkTil-ZHzINNZp4nfl7OHsVtHyACu11tFKqtcGoz7q@mail.gmail.com>

On Fri, Jul 2, 2010 at 5:50 AM, Lachlan Hunt <lachlan.hunt at lachy.id.au>wrote:

> On 2010-07-02 13:56, Julian Reschke wrote:
>
>> On 02.07.2010 13:38, Anne van Kesteren wrote:
>>
>>> Whether playing video requires a plugin is very much an issue for this
>>> list, I think. What Henri explained -- not having lock-in to a
>>> particular platform because of proprietary plugins -- is a large part of
>>> the reason why we have <video> in the first place.
>>>
>>
>> That may be true.
>>
>> But there's nothing in the spec that actually disallows adding support
>> for plugin-based DRM, right? (Just clarifying)
>>
>
> Correct. Vendors can theoretically implement any codec or container they
> like, with any features or limitations they like.
>
> MP4 already has various DRM schemes in use.  Apple, for example, could
> support FairPlay protected videos, though the use of such content with
> <video> would effectively be limited to within iTunes.
>
> Even Matroska has elements that can be used for general purpose encryption
> and DRM purposes, though these features were not included within WebM.  But
> theoretically, those features could be added and implemented with some
> agreed upon encryption scheme.
>
> I would still, however, argue against anything of the sort being added to
> WebM because DRM doesn't do anything to protect content, but is rather used
> as a way for content providers to control the market by blocking unwanted
> innovation and competition that they don't like, including open source
> software.
>
>
I think it's unavoidable that the functionality of the <video> tag in some
browsers will be extended by various add-ons to the browser.  IE's
implementation uses whatever codecs are installed and available to
DirectShow; my understanding is that Safari operates this way as well.  My
point here is primarily that it would be good for <video> tag adoption in
general if browsers enabled traditional DRM solutions to integrate in this
way.  It still requires that users will have some non-open software
installed on their machine (that's unavoidable as long as content owners
require it of us), but means that users can continue using their browser of
choice, and content distributors don't need to write a completely new player
for each DRM provider they need to support.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100702/64721c00/attachment.htm>

From jonas at sicking.cc  Fri Jul  2 12:04:52 2010
From: jonas at sicking.cc (Jonas Sicking)
Date: Fri, 2 Jul 2010 12:04:52 -0700
Subject: [whatwg] More YouTube response
In-Reply-To: <4C2DE0AA.5060009@lachy.id.au>
References: <1267897846.990.1278063443760.JavaMail.root@cm-mail03.mozilla.org>
	<1278065580.10898.7.camel@shane-laptop> <op.ve7rxmh064w2qv@annevk-t60> 
	<4C2DD3F7.6020201@gmx.de> <4C2DE0AA.5060009@lachy.id.au>
Message-ID: <AANLkTingBrnyJAWnNBQX8IsJqHlrgAx3B2JY5WsCol4f@mail.gmail.com>

On Fri, Jul 2, 2010 at 5:50 AM, Lachlan Hunt <lachlan.hunt at lachy.id.au> wrote:
> On 2010-07-02 13:56, Julian Reschke wrote:
>>
>> On 02.07.2010 13:38, Anne van Kesteren wrote:
>>>
>>> On Fri, 02 Jul 2010 12:13:00 +0200, Shane Fagan
>>> <shanepatrickfagan at ubuntu.com> wrote:
>>>>
>>>> Well this isnt really a list where we should talk about the dos and
>>>> donts of web content distribution. DRM content can be embedded in the
>>>> video tag and decoded using installable plugins so its not really an
>>>> issue for this list I dont think. We cant dictate how the specs are used
>>>> so try to keep the conversation technology neutral.
>>>
>>> Whether playing video requires a plugin is very much an issue for this
>>> list, I think. What Henri explained -- not having lock-in to a
>>> particular platform because of proprietary plugins -- is a large part of
>>> the reason why we have <video> in the first place.
>>
>> That may be true.
>>
>> But there's nothing in the spec that actually disallows adding support
>> for plugin-based DRM, right? (Just clarifying)
>
> Correct. Vendors can theoretically implement any codec or container they
> like, with any features or limitations they like.
>
> MP4 already has various DRM schemes in use. ?Apple, for example, could
> support FairPlay protected videos, though the use of such content with
> <video> would effectively be limited to within iTunes.
>
> Even Matroska has elements that can be used for general purpose encryption
> and DRM purposes, though these features were not included within WebM. ?But
> theoretically, those features could be added and implemented with some
> agreed upon encryption scheme.
>
> I would still, however, argue against anything of the sort being added to
> WebM because DRM doesn't do anything to protect content, but is rather used
> as a way for content providers to control the market by blocking unwanted
> innovation and competition that they don't like, including open source
> software.

Indeed.

Also compare to the recent battle that was fought over font formats.
Some parties where heavily pushing for DRM formats, however ultimately
we were able to persuade them that this wasn't needed, and we ended up
with a format that everyone is happy with.

/ Jonas

From jharding at google.com  Fri Jul  2 12:09:13 2010
From: jharding at google.com (John Harding)
Date: Fri, 2 Jul 2010 12:09:13 -0700
Subject: [whatwg] More YouTube response
In-Reply-To: <AANLkTilhe5qKzpIsgTP1NaZd9aYiQJIOa8oBQLqMnJ0p@mail.gmail.com>
References: <AANLkTinbe-p-STmyfGAiGA6NR7cZO-nzqlq405O5gGTd@mail.gmail.com> 
	<AANLkTilhe5qKzpIsgTP1NaZd9aYiQJIOa8oBQLqMnJ0p@mail.gmail.com>
Message-ID: <AANLkTilsTSXqbbGVMfUjHCARImFPR4rFsiwgipaEI1Ge@mail.gmail.com>

On Thu, Jul 1, 2010 at 9:16 PM, Aryeh Gregor
<Simetrical+w3c at gmail.com<Simetrical%2Bw3c at gmail.com>
> wrote:

> > As several people pointed out (and which I tried to get at in my post),
> this
> > is really an ecosystem issue rather than a change needed in the spec or
> in
> > browsers.  I suspect it's going to take some time, but the flexibility of
> > embedding content via <iframe> will be a big step forward.
>
> Wouldn't it be straightforward for YouTube to offer <iframe> support
> right now, in addition to <object>?  The backend support should be
> simple to do.  If you keep the <object> code as the default embed
> recommendation and hide the <iframe> embed code somewhere so people
> will only use it if they look for it, you won't risk confusing anyone.
>  Sites that currently whitelist <object> from YouTube will eventually
> whitelist <iframe> from YouTube too -- I hope there aren't many sites
> that permit *arbitrary* <object>s to be inserted by untrusted users.
> Allowing <iframe> will have other benefits, like allowing fallback
> "install Flash" content (currently omitted from the <object> code, I
> assume to keep the size down).
>
Yes, it's pretty straightforward to offer <iframe>-based embed code, but it
needs to be coupled with getting sites to accept them, or we end up with a
lot of confused, unhappy users.  Note that sites don't generally whitelist
specific SWFs - they generally allow all Flash embeds.


>
> Another thing that occurs to me is that you might show HTML5 video
> when Flash isn't installed/enabled, or when the Flash player crashes.
> Or at least you could give an option, instead of just failing silently
> (for embeds) or saying the user should install Flash (on the site
> itself).  My primary machine runs Linux, and Flash usually doesn't
> work at all.  If I didn't know about the HTML5 beta, I wouldn't be
> able to use YouTube at all.  And as it is, I can't use any YouTube
> embeds most of the time.
>
Yes, this is the main point of using an <iframe> to embed code - it allows
the site providing embeddable content to tailor the presentation to the
user/device/context at runtime, rather than requiring the presentation to be
fixed up-front.


>
> > When limiting keyboard input, I'd suggest devices w/ onscreen keyboards
> > simply disable the keyboard.  Applications that work well with touch
> > interfaces generally provide gesture alternatives for the limited set of
> > keys that would be available.  Alternately, devices could limit the
> keyboard
> > to the set of allowed keys.
>
> The problem is if the program makes a fake keyboard and then directly
> intercepts touch events to that location, without invoking the OS's
> keyboard at all.  The user won't be able to tell that the keypresses
> are going to the website instead of the OS.  But I can't see this as
> being a big issue -- screen space is so limited on these devices that
> websites are fullscreen anyway, or practically.  On my Nexus One,
> unless you're scrolled to the top of the site, websites take up the
> whole screen except for the bar at the top, which is present in all
> apps.  So they could already trivially spoof any application, if they
> know the target platform.  Not if the user presses the menu button, I
> guess.
>
Yeah, I realized that loophole after I sent the mail.  The same
vulnerability is there if fullscreen is initiated by a control the browser
chrome, though - at the end of the day, the primary problem to solve is
ensuring that users understand they're still viewing a web page, and the
contents are provided by the web page rather than the OS.



> > As pointed out, this is not strictly an issue for <video> tag, though
> > certainly related especially for local preview.  I have not been closely
> > following the work on the <device> element, though that seems to be where
> > this is headed.
>
> <device> adoption shouldn't interfere with <video> adoption, though.
> Even if YouTube switched to <video> by default, it could keep Flash
> for recording until <device> was implemented.  It's probably best for
> implementers to focus on perfecting <video> (and maybe <canvas>, etc.)
> before they put too much work into <device>, since those are much
> bigger use-cases.
>

You're absolutely right, and I think the order things are going is correct -
<video> is more important than <device>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100702/b5732f62/attachment.htm>

From invitation at mydailyflog.com  Fri Jul  2 13:16:01 2010
From: invitation at mydailyflog.com (nanda kumar)
Date: Fri, 02 Jul 2010 20:16:01 -0000
Subject: [whatwg] Check out this photo on MyDailyFlog!
Message-ID: <f936ec45034d992df4e89692515bad84@www.mydailyflog.com>

Hello!!!

I just uploaded a photo on nandhu_mdf's DailyFlog page that I want you to see.

Check out: http://www.mydailyflog.com/go/invite_register/nandhu_mdf/67426545&stc=82


Cheers!

 


========================================
Got a digital camera?

MyDailyFlog is a personal photo-blogging space where you can easily post
your latest and greatest photos, and share them with your friends and family.

Create your own DailyFlog at www.MyDailyFlog.com





.......................................................................
Unsubscribe: to opt out of further invitations from your friends to see 
their DailyFlogs, please click below:
http://www.mydailyflog.com/un/whatwg at lists.whatwg.org&md5=57c70ecf3790c7b9&bl=82

Please do not reply directly to this email. Questions? Contact us - 
http://www.mydailyflog.com/go/contact_us

MyDailyFlog, Refriendz Ltd. PO BOX 1184, Luton, Bedfordshire, LU1 9AT.
.......................................................................



From lachlan.hunt at lachy.id.au  Fri Jul  2 13:56:47 2010
From: lachlan.hunt at lachy.id.au (Lachlan Hunt)
Date: Fri, 02 Jul 2010 22:56:47 +0200
Subject: [whatwg] More YouTube response
In-Reply-To: <AANLkTil-ZHzINNZp4nfl7OHsVtHyACu11tFKqtcGoz7q@mail.gmail.com>
References: <1267897846.990.1278063443760.JavaMail.root@cm-mail03.mozilla.org>
	<1278065580.10898.7.camel@shane-laptop>
	<op.ve7rxmh064w2qv@annevk-t60> <4C2DD3F7.6020201@gmx.de>
	<4C2DE0AA.5060009@lachy.id.au>
	<AANLkTil-ZHzINNZp4nfl7OHsVtHyACu11tFKqtcGoz7q@mail.gmail.com>
Message-ID: <4C2E528F.2000907@lachy.id.au>

On 2010-07-02 21:01, John Harding wrote:
> On Fri, Jul 2, 2010 at 5:50 AM, Lachlan Hunt<lachlan.hunt at lachy.id.au>wrote:
>> Correct. Vendors can theoretically implement any codec or container they
>> like, with any features or limitations they like.
>>
>> MP4 already has various DRM schemes in use...
>>
>> I would still, however, argue against anything of the sort being added to
>> WebM...
>
> I think it's unavoidable that the functionality of the<video>  tag in some
> browsers will be extended by various add-ons to the browser.

Right, as I said, it's possible.  But that doesn't mean we should 
support it in any way.

YouTube would do better to address this issue by bringing the major 
players in the content industry to the table to discuss methods of 
publishing their content in interoperable ways without DRM.

As Henri pointed out, major content producers already broadcast their TV 
shows and movies over the air without DRM.  Although the BBC iPlayer 
uses DRM for the desktop version, they broadcast the show DRM free over 
the air and they make DRM free content available to the iPhone.  People 
have even found ways to access that from other devices too.  So the DRM 
really isn't there to protect the content.  It's just to force users to 
use the BBC's own iPlayer software, rather than letting users use their 
own choice of software.

The industry even releases content on DVD knowing that the DRM is 
completely ineffective, because they only use it so they can control the 
DVD player market, rather than actually doing anything practical about 
illegal copying.

The music industry have already largely dropped DRM.  Even Spotify, 
which does use DRM, permits the open source application deSpotify that 
bypasses the DRM to continue unimpeded for premium subscribers.  (The 
developers opted not to work around the blocks placed on free accounts 
though).

It's all about the business model.  The industry thinks they need their 
DRM so they can hold onto the same business model they've had for years, 
without adapting. That's why they've gone to court over every new 
innovation in the last 50 years, before slowly catching up.  The truth 
is they don't need DRM, as so many independent content producers are 
demonstrating.

YouTube and other video streaming sites just needs to push them to 
accept a reasonable and fair business model that will work.  Make it 
easy for users to stream the content, and even easier for users who want 
to buy and download the content legally.

Users currently go to torrent sites because it's easier than fighting 
with the industry to get what they want.  Make it easier to do the right 
thing.  Don't punish the legitimate them with DRM, while the "pirates" 
get away with a better user experience.

Give users a real reason to buy, and they will. e.g. Make the purchased 
content have a higher bit-rate and resolution, surround sound, no ads, 
no visible logo watermark, and/or other added features.  Provide some 
incentive, maybe a reward system that benefits the subscribers in some 
tangible way.  Do whatever you do to find a business model that works; 
just say no to DRM.  It's not needed. The big content industry knows 
that, they just won't admit it.

-- 
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

From andreluis.pt at gmail.com  Fri Jul  2 17:10:42 2010
From: andreluis.pt at gmail.com (=?ISO-8859-1?Q?Andr=E9_Lu=EDs?=)
Date: Sat, 3 Jul 2010 01:10:42 +0100
Subject: [whatwg] Resolutions meta tag proposal
In-Reply-To: <AANLkTil8ktnvX0v1eyQiSINLPhpZZMI1S-MZmxTUwmjx@mail.gmail.com>
References: <AANLkTinvknm7dSA_Er_xC1MOZFE6dA5M1X01wEgtpa7T@mail.gmail.com>
	<AANLkTil8ktnvX0v1eyQiSINLPhpZZMI1S-MZmxTUwmjx@mail.gmail.com>
Message-ID: <AANLkTil8aM6Llx0fhQTaEhcOasvGmoSJUbr8xXtkcj2H@mail.gmail.com>

On 2 July 2010 14:28, Aral Balkan <aral at aralbalkan.com> wrote:
> Hi Marques,
>
> I'm an interaction designer/developer, not a rocket scientist. :) A
> meta tag, I can easily add. If you start talking about HTTP headers,
> you've lost me.
>
> i.e., this is meant to be a pragmatic, easy-to-author solution.


I think this point Aral made is very important. This is the kind of
stuff that falls under the sphere of the designer/markup author, who
might not have control on the webserver configuration.

If there is a solution (or solutions), there should exist at least one
in the realm of the markup. That's not to say there can't be more than
one way of doing this.. content negotiation sounds good, too.

I've been musing over this since I read Aral's post... I've been
leaning towards a mixture of media queries and a base tag... to
specify a different folder for each resolution... but, as it's been
pointed out here this would apply to all img tags.

This brings me to another question... shouldn't the same exist for all
kinds of visual media resources? Thinking <img>, <video>, <object> and
possibly <iframe>.


(alt-option 1) Trying to step away from the solution presented, I can
only imagine something along the lines of different src attributes for
different resolutions:

<img src="imgs/standard-def.png" src-2x="imgs/high-def.png">
<video src="movs/sd.ogv" src-2x="movs/hd.ogv">

But this might be pushing the syntax a bit too further... but it
gracefully degrades and can be controlled on a per element basis.

(alt-option 2) Or maybe allow an approach similiar to <video> tag for imgs?

<img> <source src="" media="..insert media query here..">

?

--
Andr? Lu?s
http://id.andr3.net/


On 2 July 2010 18:22, Aryeh Gregor <Simetrical+w3c at gmail.com> wrote:
> On Fri, Jul 2, 2010 at 8:39 AM, Aral Balkan <aral at aralbalkan.com> wrote:
>> I just submitted a proposal for a new meta tag to flag that
>> high-resolution images are available and should be loaded in place of
>> low-resolution ones for users with high-PPI displays (like the new
>> iPhone 4's Retina display).
>>
>> Please see:
>>
>> http://wiki.whatwg.org/wiki/MetaExtensions#Proposals
>
> I don't know what the right solution is for this problem (other than
> "use SVG" :) ), but I don't think your proposal is workable.
> Inevitably, some images will be available in different sizes and some
> not, but your proposed meta tag will affect all images on the page.
> Also, the author needs to be able to control the names of the resized
> images to fit their needs -- on a site allowing user-uploaded images,
> for instance, you might not be able to guarantee that there isn't
> already a file named flower at 2x.jpg in the directory.
>
> The most natural way to do something like this is probably along the
> lines of content negotiation, but as we all know, that doesn't work
> well in practice because it's hard for authors to set up. ?Ideally,
> you could have the browser include a Resolution: header or something
> like that, saying what resolution it expects to see, and then the web
> server should automatically try resizing the image to match (using
> appropriate caching). ?But this is too hard to deploy and control.
>
> So I don't have any really good ideas.
>

From mjs at apple.com  Fri Jul  2 18:04:54 2010
From: mjs at apple.com (Maciej Stachowiak)
Date: Fri, 02 Jul 2010 18:04:54 -0700
Subject: [whatwg] More YouTube response
In-Reply-To: <AANLkTilsTSXqbbGVMfUjHCARImFPR4rFsiwgipaEI1Ge@mail.gmail.com>
References: <AANLkTinbe-p-STmyfGAiGA6NR7cZO-nzqlq405O5gGTd@mail.gmail.com>
	<AANLkTilhe5qKzpIsgTP1NaZd9aYiQJIOa8oBQLqMnJ0p@mail.gmail.com>
	<AANLkTilsTSXqbbGVMfUjHCARImFPR4rFsiwgipaEI1Ge@mail.gmail.com>
Message-ID: <6829CF63-7A27-43AD-A1E6-1D16C42157F1@apple.com>


On Jul 2, 2010, at 12:09 PM, John Harding wrote:

> 
> 
> On Thu, Jul 1, 2010 at 9:16 PM, Aryeh Gregor <Simetrical+w3c at gmail.com> wrote:
> > As several people pointed out (and which I tried to get at in my post), this
> > is really an ecosystem issue rather than a change needed in the spec or in
> > browsers.  I suspect it's going to take some time, but the flexibility of
> > embedding content via <iframe> will be a big step forward.
> 
> Wouldn't it be straightforward for YouTube to offer <iframe> support
> right now, in addition to <object>?  The backend support should be
> simple to do.  If you keep the <object> code as the default embed
> recommendation and hide the <iframe> embed code somewhere so people
> will only use it if they look for it, you won't risk confusing anyone.
>  Sites that currently whitelist <object> from YouTube will eventually
> whitelist <iframe> from YouTube too -- I hope there aren't many sites
> that permit *arbitrary* <object>s to be inserted by untrusted users.
> Allowing <iframe> will have other benefits, like allowing fallback
> "install Flash" content (currently omitted from the <object> code, I
> assume to keep the size down).
> Yes, it's pretty straightforward to offer <iframe>-based embed code, but it needs to be coupled with getting sites to accept them, or we end up with a lot of confused, unhappy users.  Note that sites don't generally whitelist specific SWFs - they generally allow all Flash embeds. 

Any site which does that has a giant security hole, since Flash can be used to arbitrarily script the embedding page. It's about as safe as allowing embedding of arbitrary off-site <script>. If you are aware of sites that allow embedding of arbitrary off-site Flash, you should alert them to the potential security risks. For example a social network site that allowed this would be vulnerable to a self-propagating worm.

What I have heard before is that sites whitelist specific SWFs or Flash from specific domains. I'm don't have any first-hand knowledge of how sites actually do it.

Regards,
Maciej

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100702/c3be2fc8/attachment.htm>

From mjs at apple.com  Fri Jul  2 18:20:04 2010
From: mjs at apple.com (Maciej Stachowiak)
Date: Fri, 02 Jul 2010 18:20:04 -0700
Subject: [whatwg] More YouTube response
In-Reply-To: <6829CF63-7A27-43AD-A1E6-1D16C42157F1@apple.com>
References: <AANLkTinbe-p-STmyfGAiGA6NR7cZO-nzqlq405O5gGTd@mail.gmail.com>
	<AANLkTilhe5qKzpIsgTP1NaZd9aYiQJIOa8oBQLqMnJ0p@mail.gmail.com>
	<AANLkTilsTSXqbbGVMfUjHCARImFPR4rFsiwgipaEI1Ge@mail.gmail.com>
	<6829CF63-7A27-43AD-A1E6-1D16C42157F1@apple.com>
Message-ID: <2137EE0B-8885-4975-BDD6-52415412AE19@apple.com>


On Jul 2, 2010, at 6:04 PM, Maciej Stachowiak wrote:

> 
> Any site which does that has a giant security hole, since Flash can be used to arbitrarily script the embedding page. It's about as safe as allowing embedding of arbitrary off-site <script>. If you are aware of sites that allow embedding of arbitrary off-site Flash, you should alert them to the potential security risks. For example a social network site that allowed this would be vulnerable to a self-propagating worm.
> 
> What I have heard before is that sites whitelist specific SWFs or Flash from specific domains. I'm don't have any first-hand knowledge of how sites actually do it.

With testing I found at least one site where I can apparently embed arbitrary SWFs. However, this site has per-user domains, so it might be relatively safe. This site also allows me to embed arbitrary content in an <iframe>.

Regards,
Maciej



From timeless at gmail.com  Sat Jul  3 19:07:11 2010
From: timeless at gmail.com (timeless)
Date: Sun, 4 Jul 2010 05:07:11 +0300
Subject: [whatwg] media resources: addressing media fragments through
	URIs spec
In-Reply-To: <AANLkTinEua8Qr5K1vBZvSkLClKDp4DNcRm2pPTICrI__@mail.gmail.com>
References: <AANLkTilAqisq4_U-5IMLrenaezWAFft3Ya22uYYf7Wia@mail.gmail.com>
	<AANLkTilSyggGPxuk-I6455ts6KH2EBUWhL7xBrekvIyb@mail.gmail.com>
	<AANLkTiljhBhvMGpWeGPBaPoEDRqj3TeOKr-r-qJO76XM@mail.gmail.com>
	<AANLkTin311-SC_Ehmedsc5FW7XYRkib7oz5Tr66mUqAk@mail.gmail.com>
	<AANLkTimLk_qsaqWKvFVWpVfCmblH_IxiR9LvlzZM35_G@mail.gmail.com>
	<AANLkTimGZ-PwKbJOMH8e8fn6nPaLVpK9HuscmqQc6SXj@mail.gmail.com>
	<AANLkTinJ5Iwo-H_bAIb7cIRBni0XLoZnNWH1SKXq-6_g@mail.gmail.com>
	<AANLkTinEua8Qr5K1vBZvSkLClKDp4DNcRm2pPTICrI__@mail.gmail.com>
Message-ID: <AANLkTikHlSX3IXDqi1mZbId2LLHtVNQK4uxs7V8mxg3N@mail.gmail.com>

On Fri, Jul 2, 2010 at 4:20 PM, Silvia Pfeiffer
<silviapfeiffer1 at gmail.com> wrote:
> This latter one is already defined as a 5 sec video extract from the
> full file.ogv - it's not possible to overload that with turning the
> byte range into an animated gif.

So, <img> isn't restricted to animated GIFs, Mozilla supports animated
PNGs (APNG), and some browsers support MNG.

To some extent, there's nothing wrong with using a video file as an
image, or an animated image.

I'm not absolutely certain i'd want to see it used this way, but I can
understand why someone would ask for it.

> You will also need to use transcoding
> for this and thus will want to create a new URI query scheme.

As <img> doesn't require that animations be GIF based, there's no need
for transcoding. There would be a requirement for browsers to choose
to support the proposed format, but ...

From timeless at gmail.com  Sat Jul  3 19:16:24 2010
From: timeless at gmail.com (timeless)
Date: Sun, 4 Jul 2010 05:16:24 +0300
Subject: [whatwg] Resolutions meta tag proposal
In-Reply-To: <AANLkTil8aM6Llx0fhQTaEhcOasvGmoSJUbr8xXtkcj2H@mail.gmail.com>
References: <AANLkTinvknm7dSA_Er_xC1MOZFE6dA5M1X01wEgtpa7T@mail.gmail.com>
	<AANLkTil8ktnvX0v1eyQiSINLPhpZZMI1S-MZmxTUwmjx@mail.gmail.com>
	<AANLkTil8aM6Llx0fhQTaEhcOasvGmoSJUbr8xXtkcj2H@mail.gmail.com>
Message-ID: <AANLkTikgOvvqJfJI8TehJn6tOQWT8O7n6Fs0723VROcb@mail.gmail.com>

2010/7/3 Andr? Lu?s <andreluis.pt at gmail.com>:
> (alt-option 1) Trying to step away from the solution presented, I can
> only imagine something along the lines of different src attributes for
> different resolutions:
>
> <img src="imgs/standard-def.png" src-2x="imgs/high-def.png">
> <video src="movs/sd.ogv" src-2x="movs/hd.ogv">

<img lowsrc> used to exist:
http://www.htmlcodetutorial.com/images/_IMG_LOWSRC.html

it's mostly gone now.

I think that if someone wants to be fancy they can use the existing
features (min-device-pixel-ratio, alternate stylesheets) and hide the
<img> content and replace it with background images or something.

From silviapfeiffer1 at gmail.com  Sat Jul  3 19:26:29 2010
From: silviapfeiffer1 at gmail.com (silviapfeiffer1)
Date: Sun, 4 Jul 2010 12:26:29 +1000
Subject: [whatwg] media resources: addressing media fragments through
	URIs spec
In-Reply-To: <AANLkTikHlSX3IXDqi1mZbId2LLHtVNQK4uxs7V8mxg3N@mail.gmail.com>
References: <AANLkTilAqisq4_U-5IMLrenaezWAFft3Ya22uYYf7Wia@mail.gmail.com> 
	<AANLkTilSyggGPxuk-I6455ts6KH2EBUWhL7xBrekvIyb@mail.gmail.com> 
	<AANLkTiljhBhvMGpWeGPBaPoEDRqj3TeOKr-r-qJO76XM@mail.gmail.com> 
	<AANLkTin311-SC_Ehmedsc5FW7XYRkib7oz5Tr66mUqAk@mail.gmail.com> 
	<AANLkTimLk_qsaqWKvFVWpVfCmblH_IxiR9LvlzZM35_G@mail.gmail.com> 
	<AANLkTimGZ-PwKbJOMH8e8fn6nPaLVpK9HuscmqQc6SXj@mail.gmail.com> 
	<AANLkTinJ5Iwo-H_bAIb7cIRBni0XLoZnNWH1SKXq-6_g@mail.gmail.com> 
	<AANLkTinEua8Qr5K1vBZvSkLClKDp4DNcRm2pPTICrI__@mail.gmail.com> 
	<AANLkTikHlSX3IXDqi1mZbId2LLHtVNQK4uxs7V8mxg3N@mail.gmail.com>
Message-ID: <AANLkTinzoDNFJ8Tcw4REgaDEfB2a1JXrOmF9slKAAlMs@mail.gmail.com>

On Sun, Jul 4, 2010 at 12:07 PM, timeless <timeless at gmail.com> wrote:
> On Fri, Jul 2, 2010 at 4:20 PM, Silvia Pfeiffer
> <silviapfeiffer1 at gmail.com> wrote:
>> This latter one is already defined as a 5 sec video extract from the
>> full file.ogv - it's not possible to overload that with turning the
>> byte range into an animated gif.
>
> So, <img> isn't restricted to animated GIFs, Mozilla supports animated
> PNGs (APNG), and some browsers support MNG.
>
> To some extent, there's nothing wrong with using a video file as an
> image, or an animated image.
>
> I'm not absolutely certain i'd want to see it used this way, but I can
> understand why someone would ask for it.
>
>> You will also need to use transcoding
>> for this and thus will want to create a new URI query scheme.
>
> As <img> doesn't require that animations be GIF based, there's no need
> for transcoding. There would be a requirement for browsers to choose
> to support the proposed format, but ...


It doesn't actually matter what element the URI appears in - your
element has to deal with the data that it receives and if
"file.ogv#t=1:00,1:15" is an Ogg Theora segment out of a video, then
that is what the <img> element receives.

Of course you can call any file any name, so if "file.ogv" is an
animated gif or an animated png (contrary to what your file extension
indicates), then your <img> element may be able to deal with it. I am
not aware though of any <img> element implementation that can deal
with Ogg Theora video.

If you are, however, asking to turn the Ogg Theora video into a APNG
or a animated GIF or even a MNG, there will need to be a transcoding
step at the server, which means you have to change the mime type of
your resource "file.ogv", which means, it cannot continue to be called
"file.ogv". So, if you really want to do it this way, you can only use
a URI query to transcode your resource into a different mime type and
would need to use a URI such as e.g.
"file.ogv?t=1:00,1:15&target=apng" such that the server knows what
mime type to return instead of the original one.

The gist of the issue is: A fragment ("#") addition to a URI is not
allowed to change the mime type of the resource, since it only points
to a subresource, i.e. basically only to a byte range of the original
resource. But you can do anything to your resource if you use a URI
query ("?").

Cheers,
Silvia.

From silviapfeiffer1 at gmail.com  Sat Jul  3 19:27:39 2010
From: silviapfeiffer1 at gmail.com (silviapfeiffer1)
Date: Sun, 4 Jul 2010 12:27:39 +1000
Subject: [whatwg] media resources: addressing media fragments through
	URIs spec
In-Reply-To: <AANLkTilRHC0Gg1THJwYUnlVrXHwicZOUxuV-W-hzZRZO@mail.gmail.com>
References: <AANLkTilAqisq4_U-5IMLrenaezWAFft3Ya22uYYf7Wia@mail.gmail.com> 
	<AANLkTilSyggGPxuk-I6455ts6KH2EBUWhL7xBrekvIyb@mail.gmail.com> 
	<AANLkTiljhBhvMGpWeGPBaPoEDRqj3TeOKr-r-qJO76XM@mail.gmail.com> 
	<AANLkTin311-SC_Ehmedsc5FW7XYRkib7oz5Tr66mUqAk@mail.gmail.com> 
	<AANLkTimLk_qsaqWKvFVWpVfCmblH_IxiR9LvlzZM35_G@mail.gmail.com> 
	<AANLkTimGZ-PwKbJOMH8e8fn6nPaLVpK9HuscmqQc6SXj@mail.gmail.com> 
	<AANLkTilRHC0Gg1THJwYUnlVrXHwicZOUxuV-W-hzZRZO@mail.gmail.com>
Message-ID: <AANLkTinGE0fiCuKDRM_VI1q5u9krYLAoGZd9VeZ4mUSu@mail.gmail.com>

Hi Jonas,

You  may also be interested to check out the presentation at
http://www.w3.org/2008/WebVideo/Fragments/talks/2010-06-30-Jakub_Sendor-Media_Fragment_Firefox_Plugin.pdf
which has a screenshot in it of the Firefox plugin.

Will do the screencast this week.

Cheers,
Silvia.

On Fri, Jul 2, 2010 at 7:31 PM, Jonas Sicking <jonas at sicking.cc> wrote:
> On Fri, Jul 2, 2010 at 1:55 AM, Silvia Pfeiffer
> <silviapfeiffer1 at gmail.com> wrote:
>> Actually, a point in time is nothing - it's an empty set. You never
>> want to actually point to a point in time, but rather to either the
>> point in time and an interval after that point in time, or everything
>> from that point onwards. That's what these URIs represent.
>
> I'm not sure I agree, but to avoid meta-discussions I'll just wait to
> see the suggested UI.
>
> / Jonas
>

From timeless at gmail.com  Sun Jul  4 04:43:19 2010
From: timeless at gmail.com (timeless)
Date: Sun, 4 Jul 2010 14:43:19 +0300
Subject: [whatwg] media resources: addressing media fragments through
	URIs spec
In-Reply-To: <AANLkTinzoDNFJ8Tcw4REgaDEfB2a1JXrOmF9slKAAlMs@mail.gmail.com>
References: <AANLkTilAqisq4_U-5IMLrenaezWAFft3Ya22uYYf7Wia@mail.gmail.com>
	<AANLkTilSyggGPxuk-I6455ts6KH2EBUWhL7xBrekvIyb@mail.gmail.com>
	<AANLkTiljhBhvMGpWeGPBaPoEDRqj3TeOKr-r-qJO76XM@mail.gmail.com>
	<AANLkTin311-SC_Ehmedsc5FW7XYRkib7oz5Tr66mUqAk@mail.gmail.com>
	<AANLkTimLk_qsaqWKvFVWpVfCmblH_IxiR9LvlzZM35_G@mail.gmail.com>
	<AANLkTimGZ-PwKbJOMH8e8fn6nPaLVpK9HuscmqQc6SXj@mail.gmail.com>
	<AANLkTinJ5Iwo-H_bAIb7cIRBni0XLoZnNWH1SKXq-6_g@mail.gmail.com>
	<AANLkTinEua8Qr5K1vBZvSkLClKDp4DNcRm2pPTICrI__@mail.gmail.com>
	<AANLkTikHlSX3IXDqi1mZbId2LLHtVNQK4uxs7V8mxg3N@mail.gmail.com>
	<AANLkTinzoDNFJ8Tcw4REgaDEfB2a1JXrOmF9slKAAlMs@mail.gmail.com>
Message-ID: <AANLkTinW6TdP8dy3yF_l22X9A5v3HK8QgSmLUSRawu9R@mail.gmail.com>

On Sun, Jul 4, 2010 at 5:26 AM, silviapfeiffer1
<silviapfeiffer1 at gmail.com> wrote:
> It doesn't actually matter what element the URI appears in - your
> element has to deal with the data that it receives and if
> "file.ogv#t=1:00,1:15" is an Ogg Theora segment out of a video, then
> that is what the <img> element receives.

right.

> I am
> not aware though of any <img> element implementation that can deal
> with Ogg Theora video.

That's changeable. And you seem to be totally ignoring that this is
the thrust of someone else's request.

Note that I'm not the one asking for it. Just trying to explain it to
you since you seem to be doing a good job of totally missing the
point.

> If you are, however, asking to turn the Ogg Theora video into a APNG
> or a animated GIF or even a MNG, there will need to be a transcoding
> step at the server,

No no.

If a browser can decode a frame or sequence of frames from an ogg,
then it can display them, and since it can display various image
formats in <img> (jpg, gif, png, apng, potentially mng, and in future
geckos SVG), then someone (not me!) is merely suggesting that ogg be
another one, either as a single frame or an animated sequence.

From marques at displague.com  Sun Jul  4 05:34:29 2010
From: marques at displague.com (Marques Johansson)
Date: Sun, 4 Jul 2010 08:34:29 -0400
Subject: [whatwg] Resolutions meta tag proposal
In-Reply-To: <AANLkTikgOvvqJfJI8TehJn6tOQWT8O7n6Fs0723VROcb@mail.gmail.com>
References: <AANLkTinvknm7dSA_Er_xC1MOZFE6dA5M1X01wEgtpa7T@mail.gmail.com> 
	<AANLkTil8ktnvX0v1eyQiSINLPhpZZMI1S-MZmxTUwmjx@mail.gmail.com> 
	<AANLkTil8aM6Llx0fhQTaEhcOasvGmoSJUbr8xXtkcj2H@mail.gmail.com> 
	<AANLkTikgOvvqJfJI8TehJn6tOQWT8O7n6Fs0723VROcb@mail.gmail.com>
Message-ID: <AANLkTim8ZxFYSbcUF2LiBSSvICPaogRytFGPk-uLiQb1@mail.gmail.com>

Another way about handling this PPI ratio business would be with HTTP 300
multiple choice.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.1

This may not be the best answer for every image on a page, but the first
HTML page in a server controlled session could store the PPI ratio setting
based on the page the UA chooses and then modify the HTML or
content-negotiation setting.  A problem with this is that the browsers
wouldn't be likely to render a page correctly unless they were modified for
this image request yields 300 behavior.

I still like something like this for client content negotiation:

GET /image/dog HTTP/1.1
Accept: image/*; ppiratio=2
...
HTTP/1.1 200 OK
Content-type: image/jpeg
... dog at 2x.jpg

Apache rewrite rules could even handle this by detecting ppiratio in the
Accept header and then looking for a matching images/ratio/2/dog file.  If
it didn't exist the rewrite would fail resulting in the server responding
with images/dog which is suitable if not optimal.

This has me thinking "Accept: image/*; x=400; y=300" could be attached with
any image request based on clients intent for the image.  (The HTML said
'width=400 height=300' so I don't need anything better.)  The server can
ignore this or return something better suited than the 1200x1200 image that
it would otherwise return.

I still don't have a handle on this retinal / ppi stuff so "ppiratio" may be
the wording.

I also like "Accept: video/*; kbps=500" for a similar purpose.


2010/7/3 timeless <timeless at gmail.com>

> 2010/7/3 Andr? Lu?s <andreluis.pt at gmail.com>:
> > (alt-option 1) Trying to step away from the solution presented, I can
> > only imagine something along the lines of different src attributes for
> > different resolutions:
> >
> > <img src="imgs/standard-def.png" src-2x="imgs/high-def.png">
> > <video src="movs/sd.ogv" src-2x="movs/hd.ogv">
>
> <img lowsrc> used to exist:
> http://www.htmlcodetutorial.com/images/_IMG_LOWSRC.html
>
> it's mostly gone now.
>
> I think that if someone wants to be fancy they can use the existing
> features (min-device-pixel-ratio, alternate stylesheets) and hide the
> <img> content and replace it with background images or something.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100704/d7a8c54b/attachment-0001.htm>

From svartman95 at gmail.com  Sun Jul  4 05:57:54 2010
From: svartman95 at gmail.com (bjartur)
Date: Sun, 04 Jul 2010 12:57:54 +0000
Subject: [whatwg] More YouTube response
In-Reply-To: <4C2E528F.2000907@lachy.id.au>
References: <1267897846.990.1278063443760.JavaMail.root@cm-mail03.mozilla.org>
	<1278065580.10898.7.camel@shane-laptop>
	<op.ve7rxmh064w2qv@annevk-t60> <4C2DD3F7.6020201@gmx.de>
	<4C2DE0AA.5060009@lachy.id.au>
	<AANLkTil-ZHzINNZp4nfl7OHsVtHyACu11tFKqtcGoz7q@mail.gmail.com>
	<4C2E528F.2000907@lachy.id.au>
Message-ID: <4c30855c.d908e30a.4784.ffffa84f@mx.google.com>

--------

Lachlan Hunt <lachlan.hunt at lachy.id.au> wrote:
> On 2010-07-02 21:01, John Harding wrote:
> > On Fri, Jul 2, 2010 at 5:50 AM, Lachlan Hunt<lachlan.hunt at lachy.id.au>wrote:
> As Henri pointed out, major content producers already broadcast their TV
> shows and movies over the air without DRM.  Although the BBC iPlayer
> uses DRM for the desktop version, they broadcast the show DRM free over
> the air and they make DRM free content available to the iPhone.  People
> have even found ways to access that from other devices too.  So the DRM
> really isn't there to protect the content.  It's just to force users to
> use the BBC's own iPlayer software, rather than letting users use their
> own choice of software.
> 
I fail to see how BBC would be harmed by the usage of alternative
software. Its business model is about content, not software, right?

> The industry even releases content on DVD knowing that the DRM is
> completely ineffective, because they only use it so they can control the
> DVD player market, rather than actually doing anything practical about
> illegal copying.
> 
How can the industry have control over the DVD player market and not their own
government-designated markets?

From silviapfeiffer1 at gmail.com  Sun Jul  4 06:19:00 2010
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Sun, 4 Jul 2010 23:19:00 +1000
Subject: [whatwg] media resources: addressing media fragments through
	URIs spec
In-Reply-To: <AANLkTinW6TdP8dy3yF_l22X9A5v3HK8QgSmLUSRawu9R@mail.gmail.com>
References: <AANLkTilAqisq4_U-5IMLrenaezWAFft3Ya22uYYf7Wia@mail.gmail.com> 
	<AANLkTilSyggGPxuk-I6455ts6KH2EBUWhL7xBrekvIyb@mail.gmail.com> 
	<AANLkTiljhBhvMGpWeGPBaPoEDRqj3TeOKr-r-qJO76XM@mail.gmail.com> 
	<AANLkTin311-SC_Ehmedsc5FW7XYRkib7oz5Tr66mUqAk@mail.gmail.com> 
	<AANLkTimLk_qsaqWKvFVWpVfCmblH_IxiR9LvlzZM35_G@mail.gmail.com> 
	<AANLkTimGZ-PwKbJOMH8e8fn6nPaLVpK9HuscmqQc6SXj@mail.gmail.com> 
	<AANLkTinJ5Iwo-H_bAIb7cIRBni0XLoZnNWH1SKXq-6_g@mail.gmail.com> 
	<AANLkTinEua8Qr5K1vBZvSkLClKDp4DNcRm2pPTICrI__@mail.gmail.com> 
	<AANLkTikHlSX3IXDqi1mZbId2LLHtVNQK4uxs7V8mxg3N@mail.gmail.com> 
	<AANLkTinzoDNFJ8Tcw4REgaDEfB2a1JXrOmF9slKAAlMs@mail.gmail.com> 
	<AANLkTinW6TdP8dy3yF_l22X9A5v3HK8QgSmLUSRawu9R@mail.gmail.com>
Message-ID: <AANLkTimb7yih4eaoFP50jJ-F8vtH2-FV40izcnzdEbS7@mail.gmail.com>

On Sun, Jul 4, 2010 at 9:43 PM, timeless <timeless at gmail.com> wrote:
> On Sun, Jul 4, 2010 at 5:26 AM, silviapfeiffer1
> <silviapfeiffer1 at gmail.com> wrote:
>> It doesn't actually matter what element the URI appears in - your
>> element has to deal with the data that it receives and if
>> "file.ogv#t=1:00,1:15" is an Ogg Theora segment out of a video, then
>> that is what the <img> element receives.
>
> right.
>
>> I am
>> not aware though of any <img> element implementation that can deal
>> with Ogg Theora video.
>
> That's changeable. And you seem to be totally ignoring that this is
> the thrust of someone else's request.
>
> Note that I'm not the one asking for it. Just trying to explain it to
> you since you seem to be doing a good job of totally missing the
> point.


Same here. ;-)

Note that I do understand the need and am trying to explain how it can
be made to work. Also I am trying to show that what might look as the
simplest approach won't work and why.



>> If you are, however, asking to turn the Ogg Theora video into a APNG
>> or a animated GIF or even a MNG, there will need to be a transcoding
>> step at the server,
>
> No no.
>
> If a browser can decode a frame or sequence of frames from an ogg,
> then it can display them, and since it can display various image
> formats in <img> (jpg, gif, png, apng, potentially mng, and in future
> geckos SVG), then someone (not me!) is merely suggesting that ogg be
> another one, either as a single frame or an animated sequence.

All of the image formats that you are pointing out have an image mime
type. I am merely pointing out that to support ogg theora browsers
would need to support a video mime type in an <img> element. I don't
see that as the intention of the <img> element, in particular since
<img> elements do not have transport controls and the like. Otherwise,
why did we create a <video> element in the first place.

So, I am just pointing out that with current <img> element
implementations and with the existing intentions of <img> elements (as
opposed to <video> elements), using a segment of Ogg Theora video as
defined through a media fragment URI will not work as an image
resource and will also not work as a video resource.


Hope that clarifies it.

Regards,
Silvia.

From Simetrical+w3c at gmail.com  Sun Jul  4 09:36:15 2010
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Sun, 4 Jul 2010 12:36:15 -0400
Subject: [whatwg] More YouTube response
In-Reply-To: <AANLkTilsTSXqbbGVMfUjHCARImFPR4rFsiwgipaEI1Ge@mail.gmail.com>
References: <AANLkTinbe-p-STmyfGAiGA6NR7cZO-nzqlq405O5gGTd@mail.gmail.com>
	<AANLkTilhe5qKzpIsgTP1NaZd9aYiQJIOa8oBQLqMnJ0p@mail.gmail.com>
	<AANLkTilsTSXqbbGVMfUjHCARImFPR4rFsiwgipaEI1Ge@mail.gmail.com>
Message-ID: <AANLkTin1AegDv-qyA2FjVDIHb1xQQ7drD-oZJMkyScAc@mail.gmail.com>

On Fri, Jul 2, 2010 at 3:09 PM, John Harding <jharding at google.com> wrote:
> Yes, it's pretty straightforward to offer <iframe>-based embed code, but it
> needs to be coupled with getting sites to accept them, or we end up with a
> lot of confused, unhappy users.

This will only happen if the <iframe> support is widely advertised,
though.  I assume that practically everyone who embeds YouTube videos
just copies the code given under the video.  If <iframe> support were
only mentioned in out-of-the-way places (like only if you've opted
into the HTML5 beta) and labeled with "only use this if you're sure
you don't want the normal embed code", it would allow people who cared
to use it, and they could push sites to whitelist it if any don't.

This is probably low-priority from your perspective, I can see that.
But it's pretty sad when the IE blog is now consistently using <video>
instead of Flash, while the Chrome blog only uses Flash embeds
(because of the YouTube dependency).

> Note that sites don't generally whitelist
> specific SWFs - they generally allow all Flash embeds.

I'd be very surprised if major sites allowed arbitrary Flash but not
arbitrary <iframe>.  The former is extremely dangerous, the latter is
not (although it could still create annoying popups, etc.).  Do you
have an example of such a site?

On Fri, Jul 2, 2010 at 4:56 PM, Lachlan Hunt <lachlan.hunt at lachy.id.au> wrote:
> YouTube would do better to address this issue by bringing the major players
> in the content industry to the table to discuss methods of publishing their
> content in interoperable ways without DRM.

Given how many lawsuits those major players have filed against Google
*despite* concessions on DRM, I don't think it's practical to suggest
that Google should provoke them even *more*.  However, this isn't
something standards groups have to deal with, since standardized DRM
is more or less a contradiction in terms (in the absence of hardware
support).  Flash can continue to be used for video indefinitely where
DRM is desired, just as Flash is occasionally used for still image
galleries to prevent easy copying.

From Simetrical+w3c at gmail.com  Sun Jul  4 09:46:37 2010
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Sun, 4 Jul 2010 12:46:37 -0400
Subject: [whatwg] media resources: addressing media fragments through
	URIs spec
In-Reply-To: <AANLkTimb7yih4eaoFP50jJ-F8vtH2-FV40izcnzdEbS7@mail.gmail.com>
References: <AANLkTilAqisq4_U-5IMLrenaezWAFft3Ya22uYYf7Wia@mail.gmail.com>
	<AANLkTilSyggGPxuk-I6455ts6KH2EBUWhL7xBrekvIyb@mail.gmail.com>
	<AANLkTiljhBhvMGpWeGPBaPoEDRqj3TeOKr-r-qJO76XM@mail.gmail.com>
	<AANLkTin311-SC_Ehmedsc5FW7XYRkib7oz5Tr66mUqAk@mail.gmail.com>
	<AANLkTimLk_qsaqWKvFVWpVfCmblH_IxiR9LvlzZM35_G@mail.gmail.com>
	<AANLkTimGZ-PwKbJOMH8e8fn6nPaLVpK9HuscmqQc6SXj@mail.gmail.com>
	<AANLkTinJ5Iwo-H_bAIb7cIRBni0XLoZnNWH1SKXq-6_g@mail.gmail.com>
	<AANLkTinEua8Qr5K1vBZvSkLClKDp4DNcRm2pPTICrI__@mail.gmail.com>
	<AANLkTikHlSX3IXDqi1mZbId2LLHtVNQK4uxs7V8mxg3N@mail.gmail.com>
	<AANLkTinzoDNFJ8Tcw4REgaDEfB2a1JXrOmF9slKAAlMs@mail.gmail.com>
	<AANLkTinW6TdP8dy3yF_l22X9A5v3HK8QgSmLUSRawu9R@mail.gmail.com>
	<AANLkTimb7yih4eaoFP50jJ-F8vtH2-FV40izcnzdEbS7@mail.gmail.com>
Message-ID: <AANLkTikmIfzjzPgXxJouj9Pp-mvfAdysbFVV_m16OPLq@mail.gmail.com>

On Sun, Jul 4, 2010 at 9:19 AM, Silvia Pfeiffer
<silviapfeiffer1 at gmail.com> wrote:
> All of the image formats that you are pointing out have an image mime
> type. I am merely pointing out that to support ogg theora browsers
> would need to support a video mime type in an <img> element. I don't
> see that as the intention of the <img> element, in particular since
> <img> elements do not have transport controls and the like. Otherwise,
> why did we create a <video> element in the first place.

I'd expect that a video in <img> would behave like an animated GIF --
no sound, no APIs to control playback, no browser-provided controls.
You might want this sometimes, especially if you're only selecting one
frame.  Animated images are conceptually different from videos, and
there's no reason you couldn't support the same format for both <img>
and <video>, with those different semantics.  It would be particularly
useful to support video frames as images in places where <video> can't
be used, like for the <video poster> attribute, CSS backgrounds, and
so on.  The video MIME type does not conflict at all with allowing
this kind of usage.

So to cover this use-case, it would be good if there were a way of
explicitly selecting one frame, which could be treated as a video that
contains only one frame.  This might, in turn, be accepted by some
browsers in places where they accept images.  You could do this by
explicitly allowing syntax like #t=10,10, where the start point equals
the end point, as selecting only one frame.  (But I guess this could
be emulated by #t=10,10.001 or something, assuming the frame starts at
exactly t=10.)

From timeless at gmail.com  Sun Jul  4 11:23:12 2010
From: timeless at gmail.com (timeless)
Date: Sun, 4 Jul 2010 21:23:12 +0300
Subject: [whatwg] media resources: addressing media fragments through
	URIs spec
In-Reply-To: <AANLkTimb7yih4eaoFP50jJ-F8vtH2-FV40izcnzdEbS7@mail.gmail.com>
References: <AANLkTilAqisq4_U-5IMLrenaezWAFft3Ya22uYYf7Wia@mail.gmail.com>
	<AANLkTilSyggGPxuk-I6455ts6KH2EBUWhL7xBrekvIyb@mail.gmail.com>
	<AANLkTiljhBhvMGpWeGPBaPoEDRqj3TeOKr-r-qJO76XM@mail.gmail.com>
	<AANLkTin311-SC_Ehmedsc5FW7XYRkib7oz5Tr66mUqAk@mail.gmail.com>
	<AANLkTimLk_qsaqWKvFVWpVfCmblH_IxiR9LvlzZM35_G@mail.gmail.com>
	<AANLkTimGZ-PwKbJOMH8e8fn6nPaLVpK9HuscmqQc6SXj@mail.gmail.com>
	<AANLkTinJ5Iwo-H_bAIb7cIRBni0XLoZnNWH1SKXq-6_g@mail.gmail.com>
	<AANLkTinEua8Qr5K1vBZvSkLClKDp4DNcRm2pPTICrI__@mail.gmail.com>
	<AANLkTikHlSX3IXDqi1mZbId2LLHtVNQK4uxs7V8mxg3N@mail.gmail.com>
	<AANLkTinzoDNFJ8Tcw4REgaDEfB2a1JXrOmF9slKAAlMs@mail.gmail.com>
	<AANLkTinW6TdP8dy3yF_l22X9A5v3HK8QgSmLUSRawu9R@mail.gmail.com>
	<AANLkTimb7yih4eaoFP50jJ-F8vtH2-FV40izcnzdEbS7@mail.gmail.com>
Message-ID: <AANLkTimzl1jhJ4Wv81ZIokrsK5HN1SMW-JiA5oShNBLX@mail.gmail.com>

On Sun, Jul 4, 2010 at 4:19 PM, Silvia Pfeiffer
<silviapfeiffer1 at gmail.com> wrote:
> Note that I do understand the need and am trying to explain how it can
> be made to work. Also I am trying to show that what might look as the
> simplest approach won't work and why.

It doesn't have to be made to work that way, which is the point that
the others were trying to make.

http://www.w3.org/TR/REC-html40/struct/objects.html#adef-src-IMG
src = uri [CT]     This attribute specifies the location of the image
resource. Examples of widely recognized image formats include GIF,
JPEG, and PNG.

Nothing in the definition here says "the img tag only allows mime
types of image/*"

http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#attr-img-src

"The src attribute must be present, and must contain a valid non-empty
URL potentially surrounded by spaces referencing a non-interactive,
optionally animated, image resource that is neither paged nor
scripted.

Images can thus be static bitmaps (e.g. PNGs, GIFs, JPEGs),
single-page vector documents (single-page PDFs, XML files with an SVG
root element), animated bitmaps (APNGs, animated GIFs), animated
vector graphics (XML files with an SVG root element that use
declarative SMIL animation), and so forth. However, this also
precludes SVG files with script, multipage PDF files, interactive MNG
files, HTML documents, plain text documents, and so forth."

While there is text in the html5 definition which precludes scripts,
it too doesn't explicitly limit the range to image/*, and in fact I
believe since the PDF mime type is application/pdf, it's safe to say
that browsers do render things which are not image/*.

In testing, although Chrome, Safari, Opera, and Minefield (after bug
276431) support image/svg+xml today none support application/svg+xml.
However, as Safari supports application/pdf, the cat's out of the bag
on non image/ mime types.

http://www.webwizardry.net/~timeless/svg/276431.html

> All of the image formats that you are pointing out have an image mime
> type.

I should have listed PDF which doesn't, mia culpa -- It is in the
HTML5 specification as a suggestion as noted above in this reply.

> I am merely pointing out that to support ogg theora browsers
> would need to support a video mime type in an <img> element.

You didn't point that out, you suggested that instead servers would
have to do content conversions.

> I don't see that as the intention of the <img> element, in particular since
> <img> elements do not have transport controls and the like.

html5: "An img element represents an image.", that's all the proposal
wants, an image, a non interactive image (possibly animated), and it's
possible to decode an ogg video in a way which achieves this.

> Otherwise, why did we create a <video> element in the first place.

http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#video

html5: "A video element is used for playing videos or movies."
"User agents should provide controls to enable or disable the display
of closed captions, audio description tracks, and other additional
data associated with the video stream, though such features should,
again, not interfere with the page's normal rendering.

User agents may allow users to view the video content in manners more
suitable to the user (e.g. full-screen or in an independent resizable
window). As for the other user interface features, controls to enable
this should not interfere with the page's normal rendering unless the
user agent is exposing a user interface. In such an independent
context, however, user agents may make full user interfaces visible,
with, e.g., play, pause, seeking, and volume controls, even if the
controls attribute is absent."

Video offers video controls, the suggestions which you were presented
were clearly instances where people just wanted animated frames
without such controls.

> So, I am just pointing out that with current <img> element
> implementations and with the existing intentions of <img> elements (as
> opposed to <video> elements), using a segment of Ogg Theora video as
> defined through a media fragment URI will not work as an image
> resource and will also not work as a video resource.

In order to support media fragments, media fragment support would have
to be implemented. This is obvious to everyone. Similarly, adding
support for ogg in <img> would require adding support for ogg in
<img>, just as adding support for svg in <img> requires adding support
for svg in <img>. Of note, since SVG is already supported by most
browsers, the incremental cost of adding svg support in <img> is
relatively low (as seen demonstrated by
<https://bugzilla.mozilla.org/show_bug.cgi?id=276431> which adds it to
Gecko).

This is in contrast with the cost of adding media fragment support,
which is essentially entirely new code. But once it's there, the cost
of letting it work in an <img> tag would not be very high.

Again, I'm not saying it should be done, but you've chosen to ignore
how it could work and until your last reply suggested an alternative
which was not the intent of the person who made the proposal while
ignoring what seemed like a perfectly clear proposal. Again, I'm not
endorsing it.

From rescator at emsai.net  Sun Jul  4 13:57:48 2010
From: rescator at emsai.net (=?UTF-8?B?Um9nZXIgSMOlZ2Vuc2Vu?=)
Date: Sun, 04 Jul 2010 22:57:48 +0200
Subject: [whatwg] Resolutions meta tag proposal
In-Reply-To: <AANLkTim8ZxFYSbcUF2LiBSSvICPaogRytFGPk-uLiQb1@mail.gmail.com>
References: <AANLkTinvknm7dSA_Er_xC1MOZFE6dA5M1X01wEgtpa7T@mail.gmail.com>
	<AANLkTil8ktnvX0v1eyQiSINLPhpZZMI1S-MZmxTUwmjx@mail.gmail.com>
	<AANLkTil8aM6Llx0fhQTaEhcOasvGmoSJUbr8xXtkcj2H@mail.gmail.com>
	<AANLkTikgOvvqJfJI8TehJn6tOQWT8O7n6Fs0723VROcb@mail.gmail.com>
	<AANLkTim8ZxFYSbcUF2LiBSSvICPaogRytFGPk-uLiQb1@mail.gmail.com>
Message-ID: <4C30F5CC.6010009@emsai.net>

On 2010-07-04 14:34, Marques Johansson wrote:
> Another way about handling this PPI ratio business would be with HTTP 
> 300 multiple choice. 
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.1
>
> This may not be the best answer for every image on a page, but the 
> first HTML page in a server controlled session could store the PPI 
> ratio setting based on the page the UA chooses and then modify the 
> HTML or content-negotiation setting.  A problem with this is that the 
> browsers wouldn't be likely to render a page correctly unless they 
> were modified for this image request yields 300 behavior.
>
> I still like something like this for client content negotiation:
>
> GET /image/dog HTTP/1.1
> Accept: image/*; ppiratio=2
> ...
> HTTP/1.1 200 OK
> Content-type: image/jpeg
> ... dog at 2x.jpg
>
> Apache rewrite rules could even handle this by detecting ppiratio in 
> the Accept header and then looking for a matching images/ratio/2/dog 
> file.  If it didn't exist the rewrite would fail resulting in the 
> server responding with images/dog which is suitable if not optimal.
>
> This has me thinking "Accept: image/*; x=400; y=300" could be attached 
> with any image request based on clients intent for the image.  (The 
> HTML said 'width=400 height=300' so I don't need anything better.) 
>  The server can ignore this or return something better suited than the 
> 1200x1200 image that it would otherwise return.
>
> I still don't have a handle on this retinal / ppi stuff so "ppiratio" 
> may be the wording.
> I also like "Accept: video/*; kbps=500" for a similar purpose.
>

Again this is negotiation related, and although I'm able to do fancy 
apache stuff on my site I'd rather not have to.

This however takes advantage of CSS 
http://www.alistapart.com/articles/hiresprinting/

Not exactly ideal, but I think it's the better approach, it just need to 
be refined and standardized some way.

But here's an idea I have that would fit into HTML5.

Examples:
1. <img src="img/test.png" width="512" height="256" 
dpi="96;;300;image/test300.png"> work better?
(96 dpi is current thus empty ;; while 300 dpi is alternative hence 
specified.
2. <img src="img/test.png" width="512" height="256" dpi="300"> woould 
also be valid, indicating that the image is 300 dpi and no alternatives.
3. <img src="img/test.png" width="512" height="256" 
dpi="300;image/test300.png"> same as example 1, 96 dpi default assumed.
4. <img src="img/test.png" width="512" height="256" 
dpi="*;image/test.svg"> 96 dpi default assumed, the * indicate any DPI 
and in this case it's a vector format.
If dpi="" or is not specified, then the image should be assumed to be 
96dpi, unless the image format has it's own dpi info (JPG support this, 
but does PNG?) that is.

This would make printouts look better, and allows the author to specify 
displayed size (width and height being logical pixels for non-96 dpi 
images obviously)
High DPI displays would make the browser get the high dpi image instead 
of the default.

The only parts of a site that has issues currently is fixed pixel 
graphics (and fixed pixel based layout as well I guess),
it is only pixel based (bitmapped) images that has issues with scaling,
embed video already tend to offer multiple resolutions.

So a dpi param for img might just be a nice way to fix the issue.
The CSS folks might have to add some support for this too, as well as 
scripting support.

This is just something I came up with right now, but it's at least 
simple in use which is the important thing I guess.

-- 
Roger "Rescator" H?gensen.
Freelancer - http://EmSai.net/


From dgerard at gmail.com  Sun Jul  4 15:56:22 2010
From: dgerard at gmail.com (David Gerard)
Date: Sun, 4 Jul 2010 23:56:22 +0100
Subject: [whatwg] More YouTube response
In-Reply-To: <4c30855c.d908e30a.4784.ffffa84f@mx.google.com>
References: <1267897846.990.1278063443760.JavaMail.root@cm-mail03.mozilla.org>
	<1278065580.10898.7.camel@shane-laptop>
	<op.ve7rxmh064w2qv@annevk-t60> <4C2DD3F7.6020201@gmx.de>
	<4C2DE0AA.5060009@lachy.id.au>
	<AANLkTil-ZHzINNZp4nfl7OHsVtHyACu11tFKqtcGoz7q@mail.gmail.com>
	<4C2E528F.2000907@lachy.id.au>
	<4c30855c.d908e30a.4784.ffffa84f@mx.google.com>
Message-ID: <AANLkTildxSwQdkH3biNWhjEXY2SBGWbPubLCqfazxv4R@mail.gmail.com>

On 4 July 2010 13:57, bjartur <svartman95 at gmail.com> wrote:

> I fail to see how BBC would be harmed by the usage of alternative
> software. Its business model is about content, not software, right?


See, you're using logic and sense ... about half the BBC want to just
*make their stuff available*, the other half are worried about the
thicket of laws and agreements that made sense in the days of analogue
tape broadcast on analogue television that, despite not making sense
on the Internet, still bind them legally. (Broadcast rights, residuals
for actors and writers, etc.) These are serious and real concerns and
they can't just ignore them.

It's all very complicated when real money is at stake.

(c.f. The Innovator's Dilemma.)


That said: DRM is a provably broken concept. Anyone who demands it be
incorporated into a standard is fundamentally, deeply wrong and can
work around it with some sort of proprietary plugin, because that way
they won't be requiring anyone else to pretend mathematics doesn't
work.


- d.

From ash at ashleysheridan.co.uk  Sun Jul  4 16:05:39 2010
From: ash at ashleysheridan.co.uk (Ashley Sheridan)
Date: Mon, 05 Jul 2010 00:05:39 +0100
Subject: [whatwg] More YouTube response
In-Reply-To: <AANLkTildxSwQdkH3biNWhjEXY2SBGWbPubLCqfazxv4R@mail.gmail.com>
References: <1267897846.990.1278063443760.JavaMail.root@cm-mail03.mozilla.org>
	<1278065580.10898.7.camel@shane-laptop> <op.ve7rxmh064w2qv@annevk-t60>
	<4C2DD3F7.6020201@gmx.de> <4C2DE0AA.5060009@lachy.id.au>
	<AANLkTil-ZHzINNZp4nfl7OHsVtHyACu11tFKqtcGoz7q@mail.gmail.com>
	<4C2E528F.2000907@lachy.id.au>
	<4c30855c.d908e30a.4784.ffffa84f@mx.google.com>
	<AANLkTildxSwQdkH3biNWhjEXY2SBGWbPubLCqfazxv4R@mail.gmail.com>
Message-ID: <1278284739.2230.27.camel@localhost>

On Sun, 2010-07-04 at 23:56 +0100, David Gerard wrote:

> On 4 July 2010 13:57, bjartur <svartman95 at gmail.com> wrote:
> 
> > I fail to see how BBC would be harmed by the usage of alternative
> > software. Its business model is about content, not software, right?
> 
> 
> See, you're using logic and sense ... about half the BBC want to just
> *make their stuff available*, the other half are worried about the
> thicket of laws and agreements that made sense in the days of analogue
> tape broadcast on analogue television that, despite not making sense
> on the Internet, still bind them legally. (Broadcast rights, residuals
> for actors and writers, etc.) These are serious and real concerns and
> they can't just ignore them.
> 
> It's all very complicated when real money is at stake.
> 
> (c.f. The Innovator's Dilemma.)
> 
> 
> That said: DRM is a provably broken concept. Anyone who demands it be
> incorporated into a standard is fundamentally, deeply wrong and can
> work around it with some sort of proprietary plugin, because that way
> they won't be requiring anyone else to pretend mathematics doesn't
> work.
> 
> 
> - d.


I agree. I don't condone illegally distributing digital content, but DRM
doesn't have a good track record. At best, it disrupts illegal copyright
infringement, at its worst, it harms the honest consumer. The game Spore
was arguably one of the most copyrighted games ever, despite (or maybe
because of) its almost draconian DRM. DVD's suffered for a long time
with being locked into regions by DRM, making it difficult for people
who travelled a lot but wanted to watch films, and made little or no
impact on those that obtained an illegal DRM-free copy. There are
countless more tales all like this, but until a fiscally viable
alternative is offered to the media companies (as let's face it, it's
not the artists pushing for DRM!) then we will continue to see more
measures brought into place and broken.

Thanks,
Ash
http://www.ashleysheridan.co.uk


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100705/0536c91f/attachment.htm>

From silviapfeiffer1 at gmail.com  Sun Jul  4 16:29:35 2010
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Mon, 5 Jul 2010 09:29:35 +1000
Subject: [whatwg] media resources: addressing media fragments through
	URIs spec
In-Reply-To: <AANLkTikmIfzjzPgXxJouj9Pp-mvfAdysbFVV_m16OPLq@mail.gmail.com>
References: <AANLkTilAqisq4_U-5IMLrenaezWAFft3Ya22uYYf7Wia@mail.gmail.com> 
	<AANLkTilSyggGPxuk-I6455ts6KH2EBUWhL7xBrekvIyb@mail.gmail.com> 
	<AANLkTiljhBhvMGpWeGPBaPoEDRqj3TeOKr-r-qJO76XM@mail.gmail.com> 
	<AANLkTin311-SC_Ehmedsc5FW7XYRkib7oz5Tr66mUqAk@mail.gmail.com> 
	<AANLkTimLk_qsaqWKvFVWpVfCmblH_IxiR9LvlzZM35_G@mail.gmail.com> 
	<AANLkTimGZ-PwKbJOMH8e8fn6nPaLVpK9HuscmqQc6SXj@mail.gmail.com> 
	<AANLkTinJ5Iwo-H_bAIb7cIRBni0XLoZnNWH1SKXq-6_g@mail.gmail.com> 
	<AANLkTinEua8Qr5K1vBZvSkLClKDp4DNcRm2pPTICrI__@mail.gmail.com> 
	<AANLkTikHlSX3IXDqi1mZbId2LLHtVNQK4uxs7V8mxg3N@mail.gmail.com> 
	<AANLkTinzoDNFJ8Tcw4REgaDEfB2a1JXrOmF9slKAAlMs@mail.gmail.com> 
	<AANLkTinW6TdP8dy3yF_l22X9A5v3HK8QgSmLUSRawu9R@mail.gmail.com> 
	<AANLkTimb7yih4eaoFP50jJ-F8vtH2-FV40izcnzdEbS7@mail.gmail.com> 
	<AANLkTikmIfzjzPgXxJouj9Pp-mvfAdysbFVV_m16OPLq@mail.gmail.com>
Message-ID: <AANLkTikyFL2DMoOEKQYHEu-jUcjL8PRhR9fa2LAjQgcc@mail.gmail.com>

On Mon, Jul 5, 2010 at 2:46 AM, Aryeh Gregor <Simetrical+w3c at gmail.com> wrote:
> On Sun, Jul 4, 2010 at 9:19 AM, Silvia Pfeiffer
> <silviapfeiffer1 at gmail.com> wrote:
>> All of the image formats that you are pointing out have an image mime
>> type. I am merely pointing out that to support ogg theora browsers
>> would need to support a video mime type in an <img> element. I don't
>> see that as the intention of the <img> element, in particular since
>> <img> elements do not have transport controls and the like. Otherwise,
>> why did we create a <video> element in the first place.
>
> I'd expect that a video in <img> would behave like an animated GIF --
> no sound, no APIs to control playback, no browser-provided controls.
> You might want this sometimes, especially if you're only selecting one
> frame. ?Animated images are conceptually different from videos, and
> there's no reason you couldn't support the same format for both <img>
> and <video>, with those different semantics. ?It would be particularly
> useful to support video frames as images in places where <video> can't
> be used, like for the <video poster> attribute, CSS backgrounds, and
> so on. ?The video MIME type does not conflict at all with allowing
> this kind of usage.
>
> So to cover this use-case, it would be good if there were a way of
> explicitly selecting one frame, which could be treated as a video that
> contains only one frame. ?This might, in turn, be accepted by some
> browsers in places where they accept images. ?You could do this by
> explicitly allowing syntax like #t=10,10, where the start point equals
> the end point, as selecting only one frame. ?(But I guess this could
> be emulated by #t=10,10.001 or something, assuming the frame starts at
> exactly t=10.)

The issue with #t=10,10 is that the semantics of the interval are that
of a semi-open interval: the start point is in and the end point is
out. This has been the traditional understanding of an interval
related to video (e.g. RTSP defines it that way too). Thus,
"video.ogv#t=10,10" is like asking from byte range 50 to 50 - it's
simply empty.

Further, there are complications with extracting a single frame from a
video since not every point in time will map onto a keyframe, but most
will map onto intra frames, i.e. non-complete frames. Thus, if you ask
for #t=10,10.001, you will most likely receive a region around that
time segment that is a decodable video byte range - maybe a region
that maps to #t=9.02, 12.4 - the UA will know what it asked for and be
able to display only the actually requested part in the middle after
decoding all the bits.

To repeat: I am not convinced it is a good idea to support the video
mime type in an <img> element, even if we change the semantics and
ignore the audio etc. I am not saying it is not possible, I am just
saying that I would not recommend it and would suggest to rather do it
on the server with some transcoding action - it is really not
difficult to install ffmpeg or mplayer on the server, develop a query
format that delivers keyframes from a particular time offset, and do a
keyframe dump on the server upon request. You might want to cache the
result, too.

Cheers,
Silvia.

From silviapfeiffer1 at gmail.com  Sun Jul  4 16:46:02 2010
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Mon, 5 Jul 2010 09:46:02 +1000
Subject: [whatwg] media resources: addressing media fragments through
	URIs spec
In-Reply-To: <AANLkTimzl1jhJ4Wv81ZIokrsK5HN1SMW-JiA5oShNBLX@mail.gmail.com>
References: <AANLkTilAqisq4_U-5IMLrenaezWAFft3Ya22uYYf7Wia@mail.gmail.com> 
	<AANLkTilSyggGPxuk-I6455ts6KH2EBUWhL7xBrekvIyb@mail.gmail.com> 
	<AANLkTiljhBhvMGpWeGPBaPoEDRqj3TeOKr-r-qJO76XM@mail.gmail.com> 
	<AANLkTin311-SC_Ehmedsc5FW7XYRkib7oz5Tr66mUqAk@mail.gmail.com> 
	<AANLkTimLk_qsaqWKvFVWpVfCmblH_IxiR9LvlzZM35_G@mail.gmail.com> 
	<AANLkTimGZ-PwKbJOMH8e8fn6nPaLVpK9HuscmqQc6SXj@mail.gmail.com> 
	<AANLkTinJ5Iwo-H_bAIb7cIRBni0XLoZnNWH1SKXq-6_g@mail.gmail.com> 
	<AANLkTinEua8Qr5K1vBZvSkLClKDp4DNcRm2pPTICrI__@mail.gmail.com> 
	<AANLkTikHlSX3IXDqi1mZbId2LLHtVNQK4uxs7V8mxg3N@mail.gmail.com> 
	<AANLkTinzoDNFJ8Tcw4REgaDEfB2a1JXrOmF9slKAAlMs@mail.gmail.com> 
	<AANLkTinW6TdP8dy3yF_l22X9A5v3HK8QgSmLUSRawu9R@mail.gmail.com> 
	<AANLkTimb7yih4eaoFP50jJ-F8vtH2-FV40izcnzdEbS7@mail.gmail.com> 
	<AANLkTimzl1jhJ4Wv81ZIokrsK5HN1SMW-JiA5oShNBLX@mail.gmail.com>
Message-ID: <AANLkTikxhmG-faFCYacTBeA6ofwM36-6Wf0SmGCmEVWb@mail.gmail.com>

On Mon, Jul 5, 2010 at 4:23 AM, timeless <timeless at gmail.com> wrote:
> On Sun, Jul 4, 2010 at 4:19 PM, Silvia Pfeiffer
> <silviapfeiffer1 at gmail.com> wrote:
>> Note that I do understand the need and am trying to explain how it can
>> be made to work. Also I am trying to show that what might look as the
>> simplest approach won't work and why.
>
> It doesn't have to be made to work that way, which is the point that
> the others were trying to make.
>
> http://www.w3.org/TR/REC-html40/struct/objects.html#adef-src-IMG
> src = uri [CT] ? ? This attribute specifies the location of the image
> resource. Examples of widely recognized image formats include GIF,
> JPEG, and PNG.
>
> Nothing in the definition here says "the img tag only allows mime
> types of image/*"
>
> http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#attr-img-src
>
> "The src attribute must be present, and must contain a valid non-empty
> URL potentially surrounded by spaces referencing a non-interactive,
> optionally animated, image resource that is neither paged nor
> scripted.
>
> Images can thus be static bitmaps (e.g. PNGs, GIFs, JPEGs),
> single-page vector documents (single-page PDFs, XML files with an SVG
> root element), animated bitmaps (APNGs, animated GIFs), animated
> vector graphics (XML files with an SVG root element that use
> declarative SMIL animation), and so forth. However, this also
> precludes SVG files with script, multipage PDF files, interactive MNG
> files, HTML documents, plain text documents, and so forth."
>
> While there is text in the html5 definition which precludes scripts,
> it too doesn't explicitly limit the range to image/*, and in fact I
> believe since the PDF mime type is application/pdf, it's safe to say
> that browsers do render things which are not image/*.
>
> In testing, although Chrome, Safari, Opera, and Minefield (after bug
> 276431) support image/svg+xml today none support application/svg+xml.
> However, as Safari supports application/pdf, the cat's out of the bag
> on non image/ mime types.
>
> http://www.webwizardry.net/~timeless/svg/276431.html
>
>> All of the image formats that you are pointing out have an image mime
>> type.
>
> I should have listed PDF which doesn't, mia culpa -- It is in the
> HTML5 specification as a suggestion as noted above in this reply.
>
>> I am merely pointing out that to support ogg theora browsers
>> would need to support a video mime type in an <img> element.
>
> You didn't point that out, you suggested that instead servers would
> have to do content conversions.
>
>> I don't see that as the intention of the <img> element, in particular since
>> <img> elements do not have transport controls and the like.
>
> html5: "An img element represents an image.", that's all the proposal
> wants, an image, a non interactive image (possibly animated), and it's
> possible to decode an ogg video in a way which achieves this.
>
>> Otherwise, why did we create a <video> element in the first place.
>
> http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#video
>
> html5: "A video element is used for playing videos or movies."
> "User agents should provide controls to enable or disable the display
> of closed captions, audio description tracks, and other additional
> data associated with the video stream, though such features should,
> again, not interfere with the page's normal rendering.
>
> User agents may allow users to view the video content in manners more
> suitable to the user (e.g. full-screen or in an independent resizable
> window). As for the other user interface features, controls to enable
> this should not interfere with the page's normal rendering unless the
> user agent is exposing a user interface. In such an independent
> context, however, user agents may make full user interfaces visible,
> with, e.g., play, pause, seeking, and volume controls, even if the
> controls attribute is absent."
>
> Video offers video controls, the suggestions which you were presented
> were clearly instances where people just wanted animated frames
> without such controls.
>
>> So, I am just pointing out that with current <img> element
>> implementations and with the existing intentions of <img> elements (as
>> opposed to <video> elements), using a segment of Ogg Theora video as
>> defined through a media fragment URI will not work as an image
>> resource and will also not work as a video resource.
>
> In order to support media fragments, media fragment support would have
> to be implemented. This is obvious to everyone. Similarly, adding
> support for ogg in <img> would require adding support for ogg in
> <img>, just as adding support for svg in <img> requires adding support
> for svg in <img>. Of note, since SVG is already supported by most
> browsers, the incremental cost of adding svg support in <img> is
> relatively low (as seen demonstrated by
> <https://bugzilla.mozilla.org/show_bug.cgi?id=276431> which adds it to
> Gecko).
>
> This is in contrast with the cost of adding media fragment support,
> which is essentially entirely new code. But once it's there, the cost
> of letting it work in an <img> tag would not be very high.
>
> Again, I'm not saying it should be done, but you've chosen to ignore
> how it could work and until your last reply suggested an alternative
> which was not the intent of the person who made the proposal while
> ignoring what seemed like a perfectly clear proposal. Again, I'm not
> endorsing it.


I've not ignored anything. I have given my advice to the best of my
knowledge and a recommendation how to solve the use case in a
different technical manner than proposed, since in my opinion the
proposed solution is harder to implement. I am not the one making the
decisions here though - I can only provide input. You are free to
ignore my input and implement video support in the <img> element. I
just had to point out that a media fragment URI that is using "#" will
not return an image mime type, which was what the original question
seemed to imply.

Regards,
Silvia.

From svartman95 at gmail.com  Sun Jul  4 16:57:11 2010
From: svartman95 at gmail.com (Bjartur Thorlacius)
Date: Sun, 04 Jul 2010 23:57:11 +0000
Subject: [whatwg] media resources: addressing media fragments through
	URIs spec
In-Reply-To: <AANLkTikmIfzjzPgXxJouj9Pp-mvfAdysbFVV_m16OPLq@mail.gmail.com>
References: <AANLkTilAqisq4_U-5IMLrenaezWAFft3Ya22uYYf7Wia@mail.gmail.com>
	<AANLkTilSyggGPxuk-I6455ts6KH2EBUWhL7xBrekvIyb@mail.gmail.com>
	<AANLkTiljhBhvMGpWeGPBaPoEDRqj3TeOKr-r-qJO76XM@mail.gmail.com>
	<AANLkTin311-SC_Ehmedsc5FW7XYRkib7oz5Tr66mUqAk@mail.gmail.com>
	<AANLkTimLk_qsaqWKvFVWpVfCmblH_IxiR9LvlzZM35_G@mail.gmail.com>
	<AANLkTimGZ-PwKbJOMH8e8fn6nPaLVpK9HuscmqQc6SXj@mail.gmail.com>
	<AANLkTinJ5Iwo-H_bAIb7cIRBni0XLoZnNWH1SKXq-6_g@mail.gmail.com>
	<AANLkTinEua8Qr5K1vBZvSkLClKDp4DNcRm2pPTICrI__@mail.gmail.com>
	<AANLkTikHlSX3IXDqi1mZbId2LLHtVNQK4uxs7V8mxg3N@mail.gmail.com>
	<AANLkTinzoDNFJ8Tcw4REgaDEfB2a1JXrOmF9slKAAlMs@mail.gmail.com>
	<AANLkTinW6TdP8dy3yF_l22X9A5v3HK8QgSmLUSRawu9R@mail.gmail.com>
	<AANLkTimb7yih4eaoFP50jJ-F8vtH2-FV40izcnzdEbS7@mail.gmail.com>
	<AANLkTikmIfzjzPgXxJouj9Pp-mvfAdysbFVV_m16OPLq@mail.gmail.com>
Message-ID: <4c311fe3.5d1de30a.738b.ffffc8b0@mx.google.com>

Aryeh Gregor <Simetrical+w3c at gmail.com> wrote:
> On Sun, Jul 4, 2010 at 9:19 AM, Silvia Pfeiffer
> <silviapfeiffer1 at gmail.com> wrote:
> > All of the image formats that you are pointing out have an image mime
> > type. I am merely pointing out that to support ogg theora browsers
> > would need to support a video mime type in an <img> element. I don't
> > see that as the intention of the <img> element, in particular since
> > <img> elements do not have transport controls and the like. Otherwise,
> > why did we create a <video> element in the first place.
> 
> I'd expect that a video in <img> would behave like an animated GIF --
> no sound, no APIs to control playback, no browser-provided controls.

Is the no controls part specified by the spec? A MUST in that regard
seems plain wrong. UI shall be implementation defined.

The <video> element is there to allow "webapp" authors to control the
playback of video they link to in ways that may make even less sense
for different media types and to allow linking to multiple related
media streams.


> You might want this sometimes, especially if you're only selecting one
> frame.  Animated images are conceptually different from videos, and
> there's no reason you couldn't support the same format for both <img>
> and <video>, with those different semantics.  It would be particularly
> useful to support video frames as images in places where <video> can't
> be used, like for the <video poster> attribute, CSS backgrounds, and
> so on.  The video MIME type does not conflict at all with allowing
> this kind of usage.
> 
> So to cover this use-case, it would be good if there were a way of
> explicitly selecting one frame, which could be treated as a video that
> contains only one frame.  This might, in turn, be accepted by some
> browsers in places where they accept images.  You could do this by
> explicitly allowing syntax like #t=10,10, where the start point equals
> the end point, as selecting only one frame.  (But I guess this could
> be emulated by #t=10,10.001 or something, assuming the frame starts at
> exactly t=10.)
IMO single frames should be encoded as frames/images rather than full
blown videos consisting of a single frame. The format that the video
codec uses for (golden) frames. In the case of fragments the frame will
of course have to be extracted dynamically on the client side.

From svartman95 at gmail.com  Sun Jul  4 17:21:50 2010
From: svartman95 at gmail.com (Bjartur Thorlacius)
Date: Mon, 05 Jul 2010 00:21:50 +0000
Subject: [whatwg] More YouTube response
In-Reply-To: <AANLkTildxSwQdkH3biNWhjEXY2SBGWbPubLCqfazxv4R@mail.gmail.com>
References: <1267897846.990.1278063443760.JavaMail.root@cm-mail03.mozilla.org>
	<1278065580.10898.7.camel@shane-laptop>
	<op.ve7rxmh064w2qv@annevk-t60> <4C2DD3F7.6020201@gmx.de>
	<4C2DE0AA.5060009@lachy.id.au>
	<AANLkTil-ZHzINNZp4nfl7OHsVtHyACu11tFKqtcGoz7q@mail.gmail.com>
	<4C2E528F.2000907@lachy.id.au>
	<4c30855c.d908e30a.4784.ffffa84f@mx.google.com>
	<AANLkTildxSwQdkH3biNWhjEXY2SBGWbPubLCqfazxv4R@mail.gmail.com>
Message-ID: <4c3125a4.5d1de30a.7930.ffffc86f@mx.google.com>

David Gerard <dgerard at gmail.com> wrote:
> On 4 July 2010 13:57, bjartur <svartman95 at gmail.com> wrote:
> 
> > I fail to see how BBC would be harmed by the usage of alternative
> > software. Its business model is about content, not software, right?
> 
> 
> See, you're using logic and sense ... about half the BBC want to just
> *make their stuff available*, the other half are worried about the
> thicket of laws and agreements that made sense in the days of analogue
> tape broadcast on analogue television that, despite not making sense
> on the Internet, still bind them legally. (Broadcast rights, residuals
> for actors and writers, etc.) These are serious and real concerns and
> they can't just ignore them.
> 
AFAIK BBC hasn't been harmed by the usage of VHS players made and
distributed by 3rd partys nor do I know about any laws that require them
to technically and legally restrict consumer ability to play their media
with their ware of choice.

Limiting who and how their media can be consumed should harm BBC rather than the other way around.

From ben.schwarz at gmail.com  Sun Jul  4 19:41:14 2010
From: ben.schwarz at gmail.com (Ben Schwarz)
Date: Mon, 5 Jul 2010 12:41:14 +1000
Subject: [whatwg] proposal - link relations: rel="prefetch" to be exchanged
	for a boolean attribute
Message-ID: <AANLkTilCIOoYBW84rW2hUUArOYKSbjLEFSb1SDOhQwXP@mail.gmail.com>

Hi All,


I'm sure link relations have already had many debates around how they should
work and the exact use case that they cover.
I'd like to add another card to the deck :-)

When using link relations on an "a" tag, one would find it useful to have
"next" and "previous" link relations, this is especially highlighted for
documentation, online books?publication, in general.

I'd find it useful if I could ask the user agent to prefetch the "next" page
as its more than likely that the user will be lead to this page soon after
the current browsing context. Having a linkrel of "next" is useful for
styling.

However, as far as my understanding goes, linkrels should not contain
multiple values; eg:

<a rel="prefetch next">Next page</a>

I put it forward that prefetch should be moved to become a boolean
attribute, so that it can be used as follows:

<a rel="next" prefetch>Next page</a>

This would allow content producers to improve the user experience for their
users while also maintaining clean, cohesive stylesheets and markup.

(most of) The other link relations describe the content behind a link, and
how one might style or what a browser may do to change the user experience,
this is useful. Prefetch however only aids the browser, not describing the
content whatsoever.

I've floated this idea to the attendees of my HTML5/CSS3 workshop. The
result thus far has been unanimous.

Cheers,

Ben

-
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100705/d38d09b5/attachment.htm>

From dhtmlkitchen at gmail.com  Sun Jul  4 20:27:04 2010
From: dhtmlkitchen at gmail.com (Garrett Smith)
Date: Sun, 4 Jul 2010 20:27:04 -0700
Subject: [whatwg] proposal - link relations: rel="prefetch" to be
	exchanged for a boolean attribute
In-Reply-To: <AANLkTilCIOoYBW84rW2hUUArOYKSbjLEFSb1SDOhQwXP@mail.gmail.com>
References: <AANLkTilCIOoYBW84rW2hUUArOYKSbjLEFSb1SDOhQwXP@mail.gmail.com>
Message-ID: <AANLkTimV0wpL_bbhj8Qho2c7o9GPlJDXQ-cQItIO4FfB@mail.gmail.com>

On 7/4/10, Ben Schwarz <ben.schwarz at gmail.com> wrote:
> Hi All,
>
>
[...]

>
> However, as far as my understanding goes, linkrels should not contain
> multiple values; eg:
>
> <a rel="prefetch next">Next page</a>
>
Why not? They can in HTML4.

http://www.w3.org/TR/html401/struct/links.html#adef-rel

rel = link-types  [CI]
    This attribute describes the relationship from the current
document to the anchor specified by the href attribute. The value of
this attribute is a space-separated list of link types.

Though many, for some odd reason, seem to want to separate those with
comma, not space. Quite often seen: rel="noindex, nofollow", when it
should be just: rel="noindex, nofollow".

Garrett

From pecoraro at apple.com  Sun Jul  4 21:05:49 2010
From: pecoraro at apple.com (Joseph Pecoraro)
Date: Sun, 4 Jul 2010 21:05:49 -0700
Subject: [whatwg] Should window.name be [Replaceable]?
Message-ID: <A9056ACD-3716-4E6A-9E79-76D7CB1D56FB@apple.com>

Should window.name be [Replaceable]?

There are a number of "[Replaceable]" [1] properties on the window
object. However, "window.name" is not marked as such [2]. Not being
marked as replaceable means that if authors use a global variable
named "name" it will be coerced into a string. For many this causes
confusion. It seems some browsers have opted to make it replaceable.

Test case. You can test your browser at [3].

    (function() {
        var arr = [];
        arr.push( typeof window.name );
        window.name = 1;
        arr.push( typeof window.name );
        name = 1;
         // "number" if [Replaceable], "string" otherwise
        arr.push( typeof window.name );
        alert( arr );
    })();

Browser Results:

    - Safari 5 / WebKit Nightly and Chrome 5
      NOT [Replaceable], printing "string,string,string" 
    
    - Firefox 3.6.3 / 3.7a5 and Opera 10.5.3 / 10.6
      [Replaceable], printing  "string,string,number"

    - I didn't have access to IE to test. I'd appreciate
      someone giving it a shot to see how they act.

Has there been discussion on this in the past? I searched and
didn't find any discussion.

- Joe

[1]: http://dev.w3.org/2006/webapi/WebIDL/#Replaceable
[2]: http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#the-window-object
[3]: https://bug-19967-attachments.webkit.org/attachment.cgi?id=60491


From bijumaillist at gmail.com  Sun Jul  4 21:35:54 2010
From: bijumaillist at gmail.com (Biju)
Date: Mon, 5 Jul 2010 00:35:54 -0400
Subject: [whatwg] Should window.name be [Replaceable]?
In-Reply-To: <A9056ACD-3716-4E6A-9E79-76D7CB1D56FB@apple.com>
References: <A9056ACD-3716-4E6A-9E79-76D7CB1D56FB@apple.com>
Message-ID: <AANLkTilpsqxHUZV90CVEJaI1RJ-DZ3wQDEtUo638Jm8c@mail.gmail.com>

On Mon, Jul 5, 2010 at 12:05 AM, Joseph Pecoraro <pecoraro at apple.com> wrote:
> ? ?- I didn't have access to IE to test. I'd appreciate
> ? ? ?someone giving it a shot to see how they act.

On IE8 it is printing "string,string,string"


And it looks like in Firefox
1) name = with_a_number changes type to matched the assigned value
2)  window.name = with_a_number keeps the previous type

See
   (function() {
       var arr = [];
       arr.push( typeof window.name );
       name = 1;
        // "number" if [Replaceable], "string" otherwise
       arr.push( typeof window.name );
       window.name = 1;
       arr.push( typeof window.name );
       alert( arr );
   })();

give ===> string,number,number

From pecoraro at apple.com  Sun Jul  4 21:46:02 2010
From: pecoraro at apple.com (Joseph Pecoraro)
Date: Sun, 4 Jul 2010 21:46:02 -0700
Subject: [whatwg] Should window.name be [Replaceable]?
In-Reply-To: <AANLkTilpsqxHUZV90CVEJaI1RJ-DZ3wQDEtUo638Jm8c@mail.gmail.com>
References: <A9056ACD-3716-4E6A-9E79-76D7CB1D56FB@apple.com>
	<AANLkTilpsqxHUZV90CVEJaI1RJ-DZ3wQDEtUo638Jm8c@mail.gmail.com>
Message-ID: <E341DB02-9CEA-458C-80F4-2EB2DDB88F76@apple.com>


On Jul 4, 2010, at 9:35 PM, Biju wrote:
> On Mon, Jul 5, 2010 at 12:05 AM, Joseph Pecoraro <pecoraro at apple.com> wrote:
>>    - I didn't have access to IE to test. I'd appreciate
>>      someone giving it a shot to see how they act.
> 
> On IE8 it is printing "string,string,string"

Thanks for checking! So its not Replaceable.


> And it looks like in Firefox
> 1) name = with_a_number changes type to matched the assigned value
> 2)  window.name = with_a_number keeps the previous type

Yes. So there is no way to access the real window.name once it
has been "replaced".

- Joe

From dhtmlkitchen at gmail.com  Sun Jul  4 22:58:14 2010
From: dhtmlkitchen at gmail.com (Garrett Smith)
Date: Sun, 4 Jul 2010 22:58:14 -0700
Subject: [whatwg] proposal - link relations: rel="prefetch" to be
	exchanged for a boolean attribute
In-Reply-To: <AANLkTilrWV_6-sjamlUlzVixbZVakzjRLKYodlaYjSSB@mail.gmail.com>
References: <AANLkTilCIOoYBW84rW2hUUArOYKSbjLEFSb1SDOhQwXP@mail.gmail.com>
	<AANLkTimV0wpL_bbhj8Qho2c7o9GPlJDXQ-cQItIO4FfB@mail.gmail.com>
	<AANLkTilrWV_6-sjamlUlzVixbZVakzjRLKYodlaYjSSB@mail.gmail.com>
Message-ID: <AANLkTilmIqpV9KMk_6VYSVOy6a6RvWqlbORcg5QtfJeM@mail.gmail.com>

On 7/4/10, timeless <timeless at gmail.com> wrote:
> On Mon, Jul 5, 2010 at 6:27 AM, Garrett Smith <dhtmlkitchen at gmail.com>
> wrote:
>>    This attribute describes the relationship from the current
>> document to the anchor specified by the href attribute. The value of
>> this attribute is a space-separated list of link types.
>
>> Though many, for some odd reason, seem to want to separate those with
>> comma, not space. Quite often seen: rel="noindex, nofollow", when it
>> should be just: rel="noindex, nofollow".
>
> i think you suffered from a copy+paste error.
>

Yes, I did it *again* (dammit!)

should be just: rel="noindex nofollow".

(and thanks BTW)

-g

From mikko.rantalainen at peda.net  Sun Jul  4 23:51:41 2010
From: mikko.rantalainen at peda.net (Mikko Rantalainen)
Date: Mon, 05 Jul 2010 09:51:41 +0300
Subject: [whatwg] More YouTube response
In-Reply-To: <AANLkTildxSwQdkH3biNWhjEXY2SBGWbPubLCqfazxv4R@mail.gmail.com>
References: <1267897846.990.1278063443760.JavaMail.root@cm-mail03.mozilla.org>	<1278065580.10898.7.camel@shane-laptop>	<op.ve7rxmh064w2qv@annevk-t60>
	<4C2DD3F7.6020201@gmx.de>	<4C2DE0AA.5060009@lachy.id.au>	<AANLkTil-ZHzINNZp4nfl7OHsVtHyACu11tFKqtcGoz7q@mail.gmail.com>	<4C2E528F.2000907@lachy.id.au>	<4c30855c.d908e30a.4784.ffffa84f@mx.google.com>
	<AANLkTildxSwQdkH3biNWhjEXY2SBGWbPubLCqfazxv4R@mail.gmail.com>
Message-ID: <4C3180FD.4010800@peda.net>

2010-07-05 01:56 EEST: David Gerard:
> On 4 July 2010 13:57, bjartur<svartman95 at gmail.com>  wrote:
>
>> I fail to see how BBC would be harmed by the usage of alternative
>> software. Its business model is about content, not software, right?
>
> See, you're using logic and sense ... about half the BBC want to just
> *make their stuff available*, the other half are worried about the
> thicket of laws and agreements that made sense in the days of analogue
> tape broadcast on analogue television that, despite not making sense
> on the Internet, still bind them legally. (Broadcast rights, residuals
> for actors and writers, etc.) These are serious and real concerns and
> they can't just ignore them.

So, you're arguing that DRM is not required, right?

Basically the whole problem is about how current content distributors 
(e.g. BBC) have made stupid contracts in the history and are trying to 
work around those stupid contracts with DRM instead of doing the right 
thing and do one of the following:

(1) renegotiate the contracts to allow redistribution, or
(2) stop trying to redistribute content you don't have proper rights to do.

Especially, the content distributors should immediately stop pretending 
that DRM allows for any kind of protection. It's mathematically 
impossible. It's like trying to send an encrypted message to Bob with a 
requirement that Bob cannot have access to the message. That problem 
cannot be solved. For that problem, a decision needs to be made:

(1) Bob is allowed to get access to the message, or
(2) Bob is not allowed to get access to the message (never send it!)

Notice how this is similar to the DRM case above?

Introducing a DRM system is about *trying to not do the decision* if you 
really *want to distribute the content or not*. Such system should not 
ever be standardized because it really cannot ever work, by definition.

-- 
Mikko

From dgerard at gmail.com  Mon Jul  5 00:39:12 2010
From: dgerard at gmail.com (David Gerard)
Date: Mon, 5 Jul 2010 08:39:12 +0100
Subject: [whatwg] More YouTube response
In-Reply-To: <4C3180FD.4010800@peda.net>
References: <1267897846.990.1278063443760.JavaMail.root@cm-mail03.mozilla.org>
	<1278065580.10898.7.camel@shane-laptop>
	<op.ve7rxmh064w2qv@annevk-t60> <4C2DD3F7.6020201@gmx.de>
	<4C2DE0AA.5060009@lachy.id.au>
	<AANLkTil-ZHzINNZp4nfl7OHsVtHyACu11tFKqtcGoz7q@mail.gmail.com>
	<4C2E528F.2000907@lachy.id.au>
	<4c30855c.d908e30a.4784.ffffa84f@mx.google.com>
	<AANLkTildxSwQdkH3biNWhjEXY2SBGWbPubLCqfazxv4R@mail.gmail.com>
	<4C3180FD.4010800@peda.net>
Message-ID: <AANLkTimHmeZt140TbWX45cQ-vozPPrrRYCNTvW-7-_AW@mail.gmail.com>

On 5 July 2010 07:51, Mikko Rantalainen <mikko.rantalainen at peda.net> wrote:

> So, you're arguing that DRM is not required, right?


I'm arguing that it can't possibly make sense. And that standardising
a DRM is not something anyone sensible should touch.


> Especially, the content distributors should immediately stop pretending that
> DRM allows for any kind of protection. It's mathematically impossible. It's
> like trying to send an encrypted message to Bob with a requirement that Bob
> cannot have access to the message. That problem cannot be solved. For that
> problem, a decision needs to be made:
> (1) Bob is allowed to get access to the message, or
> (2) Bob is not allowed to get access to the message (never send it!)
> Notice how this is similar to the DRM case above?
> Introducing a DRM system is about *trying to not do the decision* if you
> really *want to distribute the content or not*. Such system should not ever
> be standardized because it really cannot ever work, by definition.


Yes, precisely. Law can contain absurdities - in the BBC case above,
"streaming" and "downloading" are legally different things, even
though technically they're identical - but putting such absurdities
into a technical spec is nonsensical.


- d.

From schalk at ossreleasefeed.com  Mon Jul  5 01:28:59 2010
From: schalk at ossreleasefeed.com (Schalk Neethling)
Date: Mon, 5 Jul 2010 10:28:59 +0200
Subject: [whatwg] More YouTube response
In-Reply-To: <AANLkTinbe-p-STmyfGAiGA6NR7cZO-nzqlq405O5gGTd@mail.gmail.com>
References: <AANLkTinbe-p-STmyfGAiGA6NR7cZO-nzqlq405O5gGTd@mail.gmail.com>
Message-ID: <00c801cb1c1c$20514490$60f3cdb0$@com>

Hi John,

 

Many good responses and I agree with most but, "what I think would work best
is having a means for 3rd party DRM providers to supply browser plug-ins
which implement the <video> tag for protected content", I am not so sure. Is
one of the reasons for tags such as <video> not to move away from third
party plugin's and have this baked into the UA instead?

 

The general idea is good, I just believe implementing this via 3rd party
plugin's is not the best way forward.

 

Schalk Neethling

 

From: whatwg-bounces at lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of John Harding
Sent: Friday, July 02, 2010 1:00 AM
To: whatwg at whatwg.org
Cc: Andy Berkheimer
Subject: [whatwg] More YouTube response

 

Glad to see my post spurred some good discussion - I'll try to address topic
by topic below, but one of the great points made is that some of the
functionality YouTube needs from browsers probably doesn't belong in the
HTML5 spec (e.g. streaming, content protection).  I'm happy to take those
discussions elsewhere if this forum is inappropriate, but it seems like it
would likely be the same group of people, just on a different mailing list.

 

1. Standard Video Format

Yes, this has been debated a lot, and I generally agree that leaving it out
of the spec was the best way forward for the spec.  Shane Fagan pointed out
that Flash supports multiple different codecs, which is true, but every
version since Flash 7 has supported Sorenson Spark video and MP3 audio.  I
don't think anyone is suggesting that browsers shouldn't support multiple
codecs, but having a consistent baseline is important.  On the current path,
a content provider knows that by offering H.264 and WebM, they can reach all
HTML5-capable browsers.  This honestly is a reasonable state for YouTube
right now - we use H.264 in cases outside the <video> tag as well, but it
would be nice to converge on a single baseline format at some point in the
future.

 

2. Robust Video Streaming

Andy Berkheimer on our team has been putting some thought into this, so I'll
defer to him for more specific proposals.  For an app like YouTube, it is
extremely useful to have fine-grained control over how the browser fetches
media from the server.  Whether the details belong in the HTML5 spec or not
depends on the preferred design - something similar to Flash 10.1's
appendBytes() mechanism would affect the <video> tag interface, for example,
while a transport protocol could be completely separate.

 

3. Content Protection

Some of the discussion here seems to have conflated application-controlled
video delivery with content protection, but in an ideal world, the two are
independent.  The basic requirements around content protection that we get
from content owners basically consist of encrypting the content and limiting
the decryption to a "verified" and authorized client - the realm of
traditional DRM.  Rather than ask browsers to get into the DRM business,
what I think would work best is having a means for 3rd party DRM providers
to supply browser plug-ins which implement the <video> tag for protected
content - not all that different than selecting a pluggable codec.  

 

4. Encapsulation and Embedding

As several people pointed out (and which I tried to get at in my post), this
is really an ecosystem issue rather than a change needed in the spec or in
browsers.  I suspect it's going to take some time, but the flexibility of
embedding content via <iframe> will be a big step forward.

 

5. Fullscreen

Maciej actually covered YouTube's requirements pretty well.  I'd add that
it's not just controls that are important for us to maintain: we have a lot
of additional content that needs to display with and sometimes on top of the
video - our interactive annotations, captions, and ads most notably.
Maciej's proposal also looks fairly reasonable, though some thoughts on it:

When limiting keyboard input, I'd suggest devices w/ onscreen keyboards
simply disable the keyboard.  Applications that work well with touch
interfaces generally provide gesture alternatives for the limited set of
keys that would be available.  Alternately, devices could limit the keyboard
to the set of allowed keys.

Keyboard restrictions are better than not having fullscreen support, though
they do limit functionality - it would prevent us from supporting search in
fullscreen mode, for example.  

 

6. Camera and Micrphone access

As pointed out, this is not strictly an issue for <video> tag, though
certainly related especially for local preview.  I have not been closely
following the work on the <device> element, though that seems to be where
this is headed.

 

-John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100705/19e73402/attachment.htm>

From nils-dagsson-moskopp at dieweltistgarnichtso.net  Mon Jul  5 08:45:02 2010
From: nils-dagsson-moskopp at dieweltistgarnichtso.net (Nils Dagsson Moskopp)
Date: Mon, 5 Jul 2010 17:45:02 +0200
Subject: [whatwg] More YouTube response
In-Reply-To: <AANLkTinbe-p-STmyfGAiGA6NR7cZO-nzqlq405O5gGTd@mail.gmail.com>
References: <AANLkTinbe-p-STmyfGAiGA6NR7cZO-nzqlq405O5gGTd@mail.gmail.com>
Message-ID: <20100705174502.763d384f@desudesudesu>

John Harding <jharding at google.com> schrieb am Thu, 1 Jul 2010 15:59:37
-0700:

> 1. Standard Video Format
> [?]
> On the current path, a content provider knows
> that by offering H.264 and WebM, they can reach all HTML5-capable
> browsers.  This honestly is a reasonable state for YouTube right now
> - we use H.264 in cases outside the <video> tag as well, but it would
> be nice to converge on a single baseline format at some point in the
> future.

Practically, I think the ball is / was in Apple's court to decide this.
While to this day other browser makers have decided to ship two (!)
royalty-free video formats (Theora and VP8), Apple is the single H.264
holdout, and they have a tight itegration to their hardware as well.

Sadly, I do not have hope for any consolidation regarding video
formats. And while Youtube may be fine with having to provide only two
formats instead of a dozen, for the common smaller webmaster this is a
significant task, as transcoding resources are limited.

Recently, I have been discussing <video> implementation with the
administrator of an imageboard. It was ultimately decided to not add
this feature, precisely because of the multitude of video formats of
which none can be played in every modern browser. It's a shame.

> [?]

> 3. Content Protection
> [?]
> The basic requirements
> around content protection that we get from content owners basically
> consist of encrypting the content and limiting the decryption to a
> "verified" and authorized client - the realm of traditional DRM.

This can not possibly work if you have an open standard, which by
design has to be implementable by everyone who cares, which includes a
wide range of free and proprietary software vendors.

> Rather than ask browsers to get into the DRM business, what I think
> would work best is having a means for 3rd party DRM providers to
> supply browser plug-ins which implement the <video> tag for protected
> content - not all that different than selecting a pluggable codec.

To define a feature like that would hurt an otherwise open standard and
help to balkanize the browser market even more. If you really want to
do this, why not just use flash / java / whatever can deliver using
already available proprietary means ?

> [?]


Greetings,
-- 
Nils Dagsson Moskopp // erlehmann
<http://dieweltistgarnichtso.net>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 230 bytes
Desc: not available
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100705/d165b656/attachment.pgp>

From shanepatrickfagan at ubuntu.com  Mon Jul  5 09:20:12 2010
From: shanepatrickfagan at ubuntu.com (Shane Fagan)
Date: Mon, 05 Jul 2010 17:20:12 +0100
Subject: [whatwg] More YouTube response
In-Reply-To: <20100705174502.763d384f@desudesudesu>
References: <AANLkTinbe-p-STmyfGAiGA6NR7cZO-nzqlq405O5gGTd@mail.gmail.com>
	<20100705174502.763d384f@desudesudesu>
Message-ID: <1278346812.21664.10.camel@shane-laptop>

On Mon, 2010-07-05 at 17:45 +0200, Nils Dagsson Moskopp wrote:
> John Harding <jharding at google.com> schrieb am Thu, 1 Jul 2010 15:59:37
> -0700:
> 
> > 1. Standard Video Format
> > [?]
> > On the current path, a content provider knows
> > that by offering H.264 and WebM, they can reach all HTML5-capable
> > browsers.  This honestly is a reasonable state for YouTube right now
> > - we use H.264 in cases outside the <video> tag as well, but it would
> > be nice to converge on a single baseline format at some point in the
> > future.
> 
> Practically, I think the ball is / was in Apple's court to decide this.
> While to this day other browser makers have decided to ship two (!)
> royalty-free video formats (Theora and VP8), Apple is the single H.264
> holdout, and they have a tight itegration to their hardware as well.
> 
> Sadly, I do not have hope for any consolidation regarding video
> formats. And while Youtube may be fine with having to provide only two
> formats instead of a dozen, for the common smaller webmaster this is a
> significant task, as transcoding resources are limited.
> 
> Recently, I have been discussing <video> implementation with the
> administrator of an imageboard. It was ultimately decided to not add
> this feature, precisely because of the multitude of video formats of
> which none can be played in every modern browser. It's a shame.

If I remember correctly and dont ask me for a link to where I read it
but the problem is still patent suits I believe. MPEG-LA as soon as they
heard about the VP8 codec open sourcing they said they were getting a
patent pool together to challenge its adoption anywhere. Although I
believe that there is nothing to worry about because Google has a huge
patent pool to fight back with. 

I think this issue is still a huge sticking point for everyone and I
dont see a resolution other than to let everyone use whats comfortable
and see what sticks. Its a waiting game im afraid but as for adding webm
to the HTML5 spec I still dont think we can add it at this stage IMHO.

As for Apple not picking it up you would have to ask someone at Apple.
Id say its still the threat from MPEG-LA's patent pool that still hasnt
attacked Theora like it said it would a few years back so it seems like
an empty threat to me. 

--fagan



From derernst at gmx.ch  Mon Jul  5 10:13:22 2010
From: derernst at gmx.ch (Markus Ernst)
Date: Mon, 05 Jul 2010 19:13:22 +0200
Subject: [whatwg] Iframe dimensions
Message-ID: <4C3212B2.6010006@gmx.ch>

Hello

I found that the dimensions of the iframe element are handled along with
those of other embedded content such as img, video and others:
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-map-element.html#attr-dim-width

There is no indication about what a UA should do when dimension 
attributes are not specified. UAs do seem to handle this case 
differently for those elements: To an img element, they apply the actual 
pixel dimensions of the image file, while they seem to apply default 
dimensions to iframe elements.

But there are some special indications in the part about the @seamless 
attribute:
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#attr-iframe-seamless

<quote>
o In visual media, in a CSS-supporting user agent: the user agent should
set the intrinsic width of the iframe to the width that the element
would have if it was a non-replaced block-level element with 'width: auto'.

o In visual media, in a CSS-supporting user agent: the user agent should
set the intrinsic height of the iframe to the height of the bounding box
around the content rendered in the iframe at its current width (as given
in the previous bullet point), as it would be if the scrolling position
was such that the top of the viewport for the content rendered in the
iframe was aligned with the origin of that content's canvas.
</quote>

First, this sounds somehow complicated to me, and second, I don't 
understand why the dimensions of non-seamless iframes should not get the 
  benefits of author-friendly (and user-friendly) dimension handling.

I want to suggest to provide a way to make an iframe behave just like 
any block element regarding width and height, that means: If no 
dimensions are specified, use the full available width, and apply the 
height needed to display the full content.

Use case:
Some content from an external specialized content provider is included 
in an existing web site via an iframe. This cannot be seamless, as the 
links in the iframe must point to the original domain of the included 
document. But in order to avoid double scroll bars, it would be 
desirable to have the height of the iframe adjusted to it's content.

Example:
http://test.rapid.ch/de/haendler-schweiz/iseki.html
(This is under construction.) As a workaround to the height problem, I 
applied a script that adjusts the iframe height to the available height 
in the browser window. But of course the user experience would be more 
consistent if the page could behave like a single page, with only one 
scrollbar at the right of the browser window.

Possible solutions:
- Invent an attribute that makes the iframe element behave like any 
block element (independent from @seamless)
- Respect the CSS display property; display:block would then make an 
iframe rendered like a block element

While I personally would be happy with the second solution, I have no 
idea if this can be specced in HTML5, as it is CSS. And AFAICS the CSS 
specs do not cover individual HTML elements.

I'd be happy about some comments!

From w3c at adambarth.com  Mon Jul  5 10:24:56 2010
From: w3c at adambarth.com (Adam Barth)
Date: Mon, 5 Jul 2010 10:24:56 -0700
Subject: [whatwg] Iframe dimensions
In-Reply-To: <4C3212B2.6010006@gmx.ch>
References: <4C3212B2.6010006@gmx.ch>
Message-ID: <AANLkTikKbLfmimg3CsrcdHvnsU8-DU021AbECJcQsSPy@mail.gmail.com>

On Mon, Jul 5, 2010 at 10:13 AM, Markus Ernst <derernst at gmx.ch> wrote:
> First, this sounds somehow complicated to me, and second, I don't understand
> why the dimensions of non-seamless iframes should not get the ?benefits of
> author-friendly (and user-friendly) dimension handling.

One of the reasons is security: if we automatically sized iframes, an
attacker could learn things about documents in other origins.  Another
reason is compatibility: changing how frames layout would likely break
the layout of a large number of web sites.

Adam

From derernst at gmx.ch  Mon Jul  5 12:37:15 2010
From: derernst at gmx.ch (Markus Ernst)
Date: Mon, 05 Jul 2010 21:37:15 +0200
Subject: [whatwg] Iframe dimensions
In-Reply-To: <AANLkTikKbLfmimg3CsrcdHvnsU8-DU021AbECJcQsSPy@mail.gmail.com>
References: <4C3212B2.6010006@gmx.ch>
	<AANLkTikKbLfmimg3CsrcdHvnsU8-DU021AbECJcQsSPy@mail.gmail.com>
Message-ID: <4C32346B.3090707@gmx.ch>

Am 05.07.2010 19:24 schrieb Adam Barth:
> On Mon, Jul 5, 2010 at 10:13 AM, Markus Ernst <derernst at gmx.ch> wrote:
>> First, this sounds somehow complicated to me, and second, I don't understand
>> why the dimensions of non-seamless iframes should not get the  benefits of
>> author-friendly (and user-friendly) dimension handling.
> 
> One of the reasons is security: if we automatically sized iframes, an
> attacker could learn things about documents in other origins.  

I can't imagine how the information about the computed width and height 
can be abused - would you mind giving an example?

A possible workaround to security issues could be an element to be set 
in the included document, such as a meta tag that contains a comma 
separated list of domains that are allowed to include the document, and 
also get informations about dimensions and such. Some kind of:
<meta name="allow-embedding" content="whatwg.org, mozilla.com">

Also, if this is a potential danger, should the 2 list paragraphs about 
width and height in the part on @seamless be removed at all? As far as I 
understand, the effects of @seamless require the iframe source to be 
from the same origin as the parent document, thus I think that width and 
height of an iframe should be computed independent from @seamless. Else, 
the whole page layout is likely to change if the iframe source is 
navigated from a same-origin document to one from another origin.

> Another reason is compatibility: changing how frames layout would likely 
> break the layout of a large number of web sites.

I don't think the 2 solutions I proposed would do any BC harm:
- Inventing a new attribute does not affect legacy browsers (as they 
will ignore it), nor legacy pages (as they don't have it).
- Interpreting the CSS declaration display:block as the author's wish to 
get the iframe rendered like a block element is nothing but consistent. 
There has been no reason for authors to apply this declaration so far, 
but if anyone did, he/she wanted the rendering I suggest. If not (for 
example if the iframe is floating), he/she also applied dimensions, be 
it in the HTML or the CSS code.

From Simetrical+w3c at gmail.com  Mon Jul  5 13:06:12 2010
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Mon, 5 Jul 2010 16:06:12 -0400
Subject: [whatwg] proposal - link relations: rel="prefetch" to be
	exchanged for a boolean attribute
In-Reply-To: <AANLkTilCIOoYBW84rW2hUUArOYKSbjLEFSb1SDOhQwXP@mail.gmail.com>
References: <AANLkTilCIOoYBW84rW2hUUArOYKSbjLEFSb1SDOhQwXP@mail.gmail.com>
Message-ID: <AANLkTinR6qiO7Wd4DimjHedK7PUvT5kcxr0QUhliuXqY@mail.gmail.com>

On Sun, Jul 4, 2010 at 10:41 PM, Ben Schwarz <ben.schwarz at gmail.com> wrote:
> However, as far as my understanding goes, linkrels should not contain
> multiple values; eg:
> <a rel="prefetch next">Next page</a>

They can.  See the spec:

"The types of link indicated (the relationships) are given by the
value of the rel attribute, which, if present, must have a value that
is a set of space-separated tokens."
http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#attr-link-rel

It's allowed to have multiple types separated by spaces.  This is
common in some cases, like rel="alternate stylesheet".

From marques at displague.com  Mon Jul  5 13:10:25 2010
From: marques at displague.com (Marques Johansson)
Date: Mon, 5 Jul 2010 16:10:25 -0400
Subject: [whatwg] More YouTube response
In-Reply-To: <4C3180FD.4010800@peda.net>
References: <1267897846.990.1278063443760.JavaMail.root@cm-mail03.mozilla.org>
	<1278065580.10898.7.camel@shane-laptop> <op.ve7rxmh064w2qv@annevk-t60> 
	<4C2DD3F7.6020201@gmx.de> <4C2DE0AA.5060009@lachy.id.au>
	<AANLkTil-ZHzINNZp4nfl7OHsVtHyACu11tFKqtcGoz7q@mail.gmail.com> 
	<4C2E528F.2000907@lachy.id.au>
	<4c30855c.d908e30a.4784.ffffa84f@mx.google.com> 
	<AANLkTildxSwQdkH3biNWhjEXY2SBGWbPubLCqfazxv4R@mail.gmail.com> 
	<4C3180FD.4010800@peda.net>
Message-ID: <AANLkTimeOZ9-b25tjpFryQParqvTH9UpGI4DArWx5Qwq@mail.gmail.com>

The company I work for, VOD.com (sfw) (aka Hotmovies .com and clips .com -
nsfw (spaces added)), offer video on demand services to thousands of
studios.  Our sites are central locations for customers who want to watch
something - this is a service in itself.  We handle encoding and content
distribution and streaming sales for these studios without any cost to them.
 They send us video content and we send them a monthly check. Without
services like the ones we provide many of these studios (some are mom and
pop shops) wouldn't otherwise have the ability to sell their content online
in this fashion.

Customers can watch movies by purchasing packages of time or paying for DRM
protected rentals or for some of our sites and videos they can pay for
unprotected video.  The protected content (rentals) comes in the form of WMV
or DivX files using either DivX's service of Windows Media Server.

For the content that is not protected the download or stream is metered so
the client can be charged only for the time they spent watching the content.
 We error on the customer's side for things like buffering and misreported
play segments.

I think the discussion that DRM is irrelevant has its merits, but the
contracts and services at play have a real value regardless of how
distribution is restricted.

For my purposes I am interested in application-controlled video delivery.  I
want to be able to deliver unprotected mp4, webm, or ogv content in a
metered way.  If the user has payed to watch the entire video once and has
managed to work around HTTP no-cache and the other constraints that a normal
browser viewed experience would have, then they will have succeeding in
downloading a copy of the video - a task which they could have accomplished
with a VM session or through other means regardless of DRM.  If we need
additionally protection we can add watermarking to legally go after content
thieves since we know the IP and username of the viewer in most cases.

My requests have focused on things like "<video minbuffer=100k
maxbuffer=200k>" which could also apply to a source element.  I want to make
sure that the browser always uses "Range: bytes x-y" in requests (since I
have no other way to require that a browser use ranges or use ranges with an
upper bound).  I can use this tool to make sure UAs do not download more
content than the user has watched (which costs them money in some way).
 I've also been suggesting HTTP changes that would permit this UA behavior
(a 4xx for Ranges Required, a 4xx for Range too large, or explicitly
defining that a 206 response can include less bytes than requested and the
UA should follow-up with additional ranged requests).

While an HTML5 solution is easy to make possible as their is no legacy to
worry about and the spec is still floating about, an HTTP solution would
allow me to provide metered content flow without leaving HTTP sessions open
(throttling) and without the need for a video element - permitting users to
use their native http streaming players.

These requests can be seen as generally allowing servers to reduce load for
video or large file downloads.  Since a client may be able to download 5
minutes of video in under a minute I would like to see the client disconnect
from the server and reconnect in 5 minutes to get the additional content.  I
would like to see the server have the ability to enforce this (through HTTP
errors) or at least suggest it (through HTML5 attributes or additional HTTP
headers).
On Mon, Jul 5, 2010 at 2:51 AM, Mikko Rantalainen <
mikko.rantalainen at peda.net> wrote:

> 2010-07-05 01:56 EEST: David Gerard:
>
>  On 4 July 2010 13:57, bjartur<svartman95 at gmail.com>  wrote:
>>
>>  I fail to see how BBC would be harmed by the usage of alternative
>>> software. Its business model is about content, not software, right?
>>>
>>
>> See, you're using logic and sense ... about half the BBC want to just
>> *make their stuff available*, the other half are worried about the
>> thicket of laws and agreements that made sense in the days of analogue
>> tape broadcast on analogue television that, despite not making sense
>> on the Internet, still bind them legally. (Broadcast rights, residuals
>> for actors and writers, etc.) These are serious and real concerns and
>> they can't just ignore them.
>>
>
> So, you're arguing that DRM is not required, right?
>
> Basically the whole problem is about how current content distributors (e.g.
> BBC) have made stupid contracts in the history and are trying to work around
> those stupid contracts with DRM instead of doing the right thing and do one
> of the following:
>
> (1) renegotiate the contracts to allow redistribution, or
> (2) stop trying to redistribute content you don't have proper rights to do.
>
> Especially, the content distributors should immediately stop pretending
> that DRM allows for any kind of protection. It's mathematically impossible.
> It's like trying to send an encrypted message to Bob with a requirement that
> Bob cannot have access to the message. That problem cannot be solved. For
> that problem, a decision needs to be made:
>
> (1) Bob is allowed to get access to the message, or
> (2) Bob is not allowed to get access to the message (never send it!)
>
> Notice how this is similar to the DRM case above?
>
> Introducing a DRM system is about *trying to not do the decision* if you
> really *want to distribute the content or not*. Such system should not ever
> be standardized because it really cannot ever work, by definition.
>
> --
> Mikko
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100705/2a929322/attachment.htm>

From Simetrical+w3c at gmail.com  Mon Jul  5 13:26:44 2010
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Mon, 5 Jul 2010 16:26:44 -0400
Subject: [whatwg] More YouTube response
In-Reply-To: <20100705174502.763d384f@desudesudesu>
References: <AANLkTinbe-p-STmyfGAiGA6NR7cZO-nzqlq405O5gGTd@mail.gmail.com>
	<20100705174502.763d384f@desudesudesu>
Message-ID: <AANLkTilOOfaTJetwoSJWSacAPmSfrFuOSx7CNysX6tBW@mail.gmail.com>

On Mon, Jul 5, 2010 at 11:45 AM, Nils Dagsson Moskopp
<nils-dagsson-moskopp at dieweltistgarnichtso.net> wrote:
> Practically, I think the ball is / was in Apple's court to decide this.
> While to this day other browser makers have decided to ship two (!)
> royalty-free video formats (Theora and VP8), Apple is the single H.264
> holdout, and they have a tight itegration to their hardware as well.

Internet Explorer 9 will not support VP8 unless the user manually
installs the codec.  This puts it at the same level of support as
Safari has for Theora, as far as I know.  So even if we assume every
user upgraded to the latest alphas of the browser they used, H.264 is
supported by about 65% of users' browsers, and VP8 by about 40%.  Of
course, in reality, less than half of users' browsers support <video>
at all right now, and given IE uptake rates, that's only going to
change slowly.

On Mon, Jul 5, 2010 at 4:10 PM, Marques Johansson <marques at displague.com> wrote:
> For my purposes I am interested in application-controlled video delivery. ?I
> want to be able to deliver unprotected mp4, webm, or ogv content in a
> metered way. ?If the user has payed to watch the entire video once and has
> managed to work around HTTP no-cache and the other constraints that a normal
> browser viewed experience would have, then they will have succeeding in
> downloading a copy of the video - a task which they could have accomplished
> with a VM session or through other means?regardless of DRM.

There's no way to stop this at the markup level, since the user could
just configure a user-agent to ignore the attributes, or manually
remove them with a tool like Firebug.  More to the point, since this
feature doesn't provide significant benefit to many users or authors,
no user agent would bother implementing it in the first place.

You should instead look into to writing server-side scripts that meet
your needs.  When the user requests a video, have the script check how
much video the user is authorized to view, and just truncate it after
that point.  Or have it insert an extra clip at the end of what
they're allowed to view saying "you have to pay more to keep viewing",
then truncate it.  Or whatever.  This is pretty easy to do, and not
possible for the user to circumvent.

> These requests can be seen as generally allowing servers to reduce load for
> video or large file downloads. ?Since a client may be able to download 5
> minutes of video in under a minute I would like to see the client disconnect
> from the server and reconnect in 5 minutes to get the additional content. ?I
> would like to see the server have the ability to enforce this (through HTTP
> errors) or at least suggest it (through HTML5 attributes or additional HTTP
> headers).

Well-written clients should already buffer only as much as they need
to ensure the video will play smoothly.  The preload="" attribute is
already provided to allow authors to control this behavior.  When the
client has read enough for now, it will just stop reading new content
from the server until it needs more.  If the server thinks that the
client is reading too fast, on the other hand, it can just send fewer
packets.  Again, I don't think anything needs to be changed in HTML
here.

From shanepatrickfagan at ubuntu.com  Mon Jul  5 13:46:37 2010
From: shanepatrickfagan at ubuntu.com (Shane Fagan)
Date: Mon, 05 Jul 2010 21:46:37 +0100
Subject: [whatwg] More YouTube response
In-Reply-To: <AANLkTilOOfaTJetwoSJWSacAPmSfrFuOSx7CNysX6tBW@mail.gmail.com>
References: <AANLkTinbe-p-STmyfGAiGA6NR7cZO-nzqlq405O5gGTd@mail.gmail.com>
	<20100705174502.763d384f@desudesudesu>
	<AANLkTilOOfaTJetwoSJWSacAPmSfrFuOSx7CNysX6tBW@mail.gmail.com>
Message-ID: <1278362798.23537.12.camel@shane-laptop>

> Internet Explorer 9 will not support VP8 unless the user manually
> installs the codec.  This puts it at the same level of support as
> Safari has for Theora, as far as I know.  So even if we assume every
> user upgraded to the latest alphas of the browser they used, H.264 is
> supported by about 65% of users' browsers, and VP8 by about 40%.  Of
> course, in reality, less than half of users' browsers support <video>
> at all right now, and given IE uptake rates, that's only going to
> change slowly.

For windows maybe there should be a .exe/.msi with the entire package of
VP8+Theora+Vorbis or just VP8+Vorbis to make it easier to install but
adoption isnt really our issue thats Microsoft's issue if WebM takes
off. I dont foresee it being any harder than Adobe Flash to install for
the regular user so websites could just direct users to the download if
they dont have it already.

Oh and IE is dropping in use according to the media over the past 3
months ever since the browser selection screen came so its becoming less
of an issue in time. 

--fagan


From Simetrical+w3c at gmail.com  Mon Jul  5 13:50:20 2010
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Mon, 5 Jul 2010 16:50:20 -0400
Subject: [whatwg] Iframe dimensions
In-Reply-To: <4C3212B2.6010006@gmx.ch>
References: <4C3212B2.6010006@gmx.ch>
Message-ID: <AANLkTim38_gSl9lpUVzG1TFUi5wDrLeG1nA-ILYl3lr5@mail.gmail.com>

On Mon, Jul 5, 2010 at 1:13 PM, Markus Ernst <derernst at gmx.ch> wrote:
> Some content from an external specialized content provider is included in
> an existing web site via an iframe. This cannot be seamless, as the links
> in the iframe must point to the original domain of the included document.
> But in order to avoid double scroll bars, it would be desirable to have the
> height of the iframe adjusted to it's content.

This use-case is inherently insecure.  An iframe's height cannot
depend on the contents of a cross-origin page unless that origin
explicitly opts in somehow.

> I found that the dimensions of the iframe element are handled along with
> those of other embedded content such as img, video and others:
> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-map-element.html#attr-dim-width
>
> There is no indication about what a UA should do when dimension attributes
> are not specified.

I can't find it either.  If it's really not specced anywhere, that's a
bug that should be fixed.

On Mon, Jul 5, 2010 at 3:37 PM, Markus Ernst <derernst at gmx.ch> wrote:
> I can't imagine how the information about the computed width and height can
> be abused - would you mind giving an example?

For a basic example, suppose that a page on some site is reliably a
different height depending on whether you're logged in or not (this is
usually true).  Then when you visit my site, I could create a hidden
iframe with the other site inside, and measure the height from
JavaScript.  Then I'd know whether you're logged in on that site.
There are lots of other conditions that would change the height of a
page, and they could leak a large amount of information to arbitrary
third-party sites.  No site should be able to find out anything about
your use of another site, to the extent possible.

> A possible workaround to security issues could be an element to be set in
> the included document, such as a meta tag that contains a comma separated
> list of domains that are allowed to include the document, and also get
> informations about dimensions and such. Some kind of:
> <meta name="allow-embedding" content="whatwg.org, mozilla.com">

This could be handled by seamless using CORS or whatever, sure.

> Also, if this is a potential danger, should the 2 list paragraphs about
> width and height in the part on @seamless be removed at all? As far as I
> understand, the effects of @seamless require the iframe source to be from
> the same origin as the parent document, thus I think that width and height
> of an iframe should be computed independent from @seamless. Else, the whole
> page layout is likely to change if the iframe source is navigated from a
> same-origin document to one from another origin.

You're correct: if you navigate the iframe to a different origin, the
iframe will no longer be seamless, and all the effects of seamless
will cease to apply.  This means it will change height and width, CSS
rules won't apply, etc., etc.  The presence of seamless="" does
definitely change the width and height computations, and many other
things.

> I don't think the 2 solutions I proposed would do any BC harm:
> - Inventing a new attribute does not affect legacy browsers (as they will
> ignore it), nor legacy pages (as they don't have it).

Yes, this is why the seamless attribute works.

> - Interpreting the CSS declaration display:block as the author's wish to get
> the iframe rendered like a block element is nothing but consistent. There
> has been no reason for authors to apply this declaration so far, but if
> anyone did, he/she wanted the rendering I suggest. If not (for example if
> the iframe is floating), he/she also applied dimensions, be it in the HTML
> or the CSS code.

The author might or might not originally have wanted the behavior you
said, but in the end, the site doesn't render that way, and changing
the rendering like that would make the site look very different from
the way it looked before (= the final product that the author was
satisfied with and released).

From ngompa13 at gmail.com  Mon Jul  5 13:51:20 2010
From: ngompa13 at gmail.com (=?ISO-2022-JP?B?Q29uYW4gS3VkbyAoGyRCJUshPCVrISYlNCVzJVEbKEIp?=)
Date: Mon, 5 Jul 2010 15:51:20 -0500
Subject: [whatwg] More YouTube response
In-Reply-To: <1278362798.23537.12.camel@shane-laptop>
References: <AANLkTinbe-p-STmyfGAiGA6NR7cZO-nzqlq405O5gGTd@mail.gmail.com>
	<20100705174502.763d384f@desudesudesu>
	<AANLkTilOOfaTJetwoSJWSacAPmSfrFuOSx7CNysX6tBW@mail.gmail.com>
	<1278362798.23537.12.camel@shane-laptop>
Message-ID: <AANLkTilCln3zdlO0D7FHNfSZNGZYbVD6Hn_6CKymSeKr@mail.gmail.com>

On Mon, Jul 5, 2010 at 3:46 PM, Shane Fagan <shanepatrickfagan at ubuntu.com>wrote:

> > Internet Explorer 9 will not support VP8 unless the user manually
> > installs the codec.  This puts it at the same level of support as
> > Safari has for Theora, as far as I know.  So even if we assume every
> > user upgraded to the latest alphas of the browser they used, H.264 is
> > supported by about 65% of users' browsers, and VP8 by about 40%.  Of
> > course, in reality, less than half of users' browsers support <video>
> > at all right now, and given IE uptake rates, that's only going to
> > change slowly.
>
> For windows maybe there should be a .exe/.msi with the entire package of
> VP8+Theora+Vorbis or just VP8+Vorbis to make it easier to install but
> adoption isnt really our issue thats Microsoft's issue if WebM takes
> off. I dont foresee it being any harder than Adobe Flash to install for
> the regular user so websites could just direct users to the download if
> they dont have it already.
>
> Oh and IE is dropping in use according to the media over the past 3
> months ever since the browser selection screen came so its becoming less
> of an issue in time.
>
> --fagan
>
>
The marketshare drop has been very small, about a percentage point a month.
And Ian and other people in WHATWG made it our issue if Microsoft or Apple
doesn't fully adopt WebM. He made it clear that unless all the browser
vendors adopted a video format, it would never be specified in the spec as
the baseline format to support.

We do need a baseline format in the spec. Supporting video will be difficult
unless content providers can be certain that a single format will be
supported across the board....
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100705/0489fbe8/attachment.htm>

From mike at mikewilcox.net  Mon Jul  5 13:55:23 2010
From: mike at mikewilcox.net (Mike Wilcox)
Date: Mon, 5 Jul 2010 15:55:23 -0500
Subject: [whatwg] More YouTube response
In-Reply-To: <1278362798.23537.12.camel@shane-laptop>
References: <AANLkTinbe-p-STmyfGAiGA6NR7cZO-nzqlq405O5gGTd@mail.gmail.com>
	<20100705174502.763d384f@desudesudesu>
	<AANLkTilOOfaTJetwoSJWSacAPmSfrFuOSx7CNysX6tBW@mail.gmail.com>
	<1278362798.23537.12.camel@shane-laptop>
Message-ID: <AE1F0309-F3A0-4956-A457-7FCCEB22E411@mikewilcox.net>

It's the iPhone and especially the iPad which has really pushed the adoption of HTML5 video. And afaik, you can't install WebM on them. To me (and my company) that's where the issue lies.

Mike Wilcox
http://clubajax.org
mike at mikewilcox.net



On Jul 5, 2010, at 3:46 PM, Shane Fagan wrote:

>> Internet Explorer 9 will not support VP8 unless the user manually
>> installs the codec.  This puts it at the same level of support as
>> Safari has for Theora, as far as I know.  So even if we assume every
>> user upgraded to the latest alphas of the browser they used, H.264 is
>> supported by about 65% of users' browsers, and VP8 by about 40%.  Of
>> course, in reality, less than half of users' browsers support <video>
>> at all right now, and given IE uptake rates, that's only going to
>> change slowly.
> 
> For windows maybe there should be a .exe/.msi with the entire package of
> VP8+Theora+Vorbis or just VP8+Vorbis to make it easier to install but
> adoption isnt really our issue thats Microsoft's issue if WebM takes
> off. I dont foresee it being any harder than Adobe Flash to install for
> the regular user so websites could just direct users to the download if
> they dont have it already.
> 
> Oh and IE is dropping in use according to the media over the past 3
> months ever since the browser selection screen came so its becoming less
> of an issue in time. 
> 
> --fagan
> 


From bmschwar at fas.harvard.edu  Mon Jul  5 14:52:48 2010
From: bmschwar at fas.harvard.edu (Benjamin M. Schwartz)
Date: Mon, 05 Jul 2010 17:52:48 -0400
Subject: [whatwg] More YouTube response
In-Reply-To: <1278362798.23537.12.camel@shane-laptop>
References: <AANLkTinbe-p-STmyfGAiGA6NR7cZO-nzqlq405O5gGTd@mail.gmail.com>	<20100705174502.763d384f@desudesudesu>	<AANLkTilOOfaTJetwoSJWSacAPmSfrFuOSx7CNysX6tBW@mail.gmail.com>
	<1278362798.23537.12.camel@shane-laptop>
Message-ID: <4C325430.8090009@fas.harvard.edu>

On 07/05/2010 04:46 PM, Shane Fagan wrote:
> For windows maybe there should be a .exe/.msi with the entire package of
> VP8+Theora+Vorbis or just VP8+Vorbis to make it easier to install

There is:
http://downloads.xiph.org/releases/oggdsf/opencodecs_0.84.17315.exe
http://lists.xiph.org/pipermail/theora/2010-June/004065.html

In addition to system codecs, the package also includes an ActiveX plugin
that implements a limited form of <video> in IE 8.

--Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100705/db5ba971/attachment.pgp>

From nils-dagsson-moskopp at dieweltistgarnichtso.net  Mon Jul  5 15:42:13 2010
From: nils-dagsson-moskopp at dieweltistgarnichtso.net (Nils Dagsson Moskopp)
Date: Tue, 6 Jul 2010 00:42:13 +0200
Subject: [whatwg] More YouTube response
In-Reply-To: <1278346812.21664.10.camel@shane-laptop>
References: <AANLkTinbe-p-STmyfGAiGA6NR7cZO-nzqlq405O5gGTd@mail.gmail.com>
	<20100705174502.763d384f@desudesudesu>
	<1278346812.21664.10.camel@shane-laptop>
Message-ID: <20100706004213.18378440@desudesudesu>

Shane Fagan <shanepatrickfagan at ubuntu.com> schrieb am Mon, 05 Jul 2010
17:20:12 +0100:

> If I remember correctly and dont ask me for a link to where I read it
> but the problem is still patent suits I believe. MPEG-LA as soon as
> they heard about the VP8 codec open sourcing they said they were
> getting a patent pool together to challenge its adoption anywhere.

MPEG LA cannot allow other video formats to succeed; that would hurt
the fundamental purpose of the organisation. Considering this, it was
entirely expected.

> Although I believe that there is nothing to worry about because
> Google has a huge patent pool to fight back with. 

First, Google "fighting back" is pure speculation. Second, VP8 getting
attacked by MPEG LA (which would be a prerequisite for that scenario)
is pure speculation as well. As far as I am aware of the issue, nothing
has happened yet.

> I think this issue is still a huge sticking point for everyone and I
> dont see a resolution other than to let everyone use whats comfortable
> and see what sticks.

That is, if anything sticks at all.

> Its a waiting game im afraid but as for adding
> webm to the HTML5 spec I still dont think we can add it at this stage
> IMHO.

As Hixie has stated, HTML5 is primarlily a descriptive specification,
not a prescriptive one. If vendors cannot agree for one reason or
another, then something will not be specced.

The only reasonable behaviour for web masters who wish to excert their
influence would be to not support specific clients, same as many pages
prompt you to upgrade Flash.

Speaking for myself, the 3% or whatever Safari users coming to my blog
are advised to install Xiph codecs to be able to check out my Podcast
(please, no etymological arguments about the perceived iPod heritage of
that word). But then I do not run a commercial operation ? porn site
operators will probably use every fallback they can and quickly adapt
to new and relevant clients like the iPad.

> As for Apple not picking it up you would have to ask someone at Apple.
> Id say its still the threat from MPEG-LA's patent pool that still
> hasnt attacked Theora like it said it would a few years back so it
> seems like an empty threat to me. 

May Apple engineers on this list chime in and tell us if patent
uncertainity is still an issue ? AFAIK neither Google, nor Mozilla, nor
Apple have had difficulties. Or should I write to Apple legal
regarding this query ?


Greetings,
-- 
Nils Dagsson Moskopp // erlehmann
<http://dieweltistgarnichtso.net>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 230 bytes
Desc: not available
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100706/e7aff214/attachment.pgp>

From nils-dagsson-moskopp at dieweltistgarnichtso.net  Mon Jul  5 16:09:24 2010
From: nils-dagsson-moskopp at dieweltistgarnichtso.net (Nils Dagsson Moskopp)
Date: Tue, 6 Jul 2010 01:09:24 +0200
Subject: [whatwg] More YouTube response
In-Reply-To: <20100706004213.18378440@desudesudesu>
References: <AANLkTinbe-p-STmyfGAiGA6NR7cZO-nzqlq405O5gGTd@mail.gmail.com>
	<20100705174502.763d384f@desudesudesu>
	<1278346812.21664.10.camel@shane-laptop>
	<20100706004213.18378440@desudesudesu>
Message-ID: <20100706010924.479dc6d4@desudesudesu>

Nils Dagsson Moskopp <nils-dagsson-moskopp at dieweltistgarnichtso.net>
schrieb am Tue, 6 Jul 2010 00:42:13 +0200:

> May Apple engineers on this list chime in and tell us if patent
> uncertainity is still an issue ? AFAIK neither Google, nor Mozilla,
> nor Apple have had difficulties.

s/nor Apple/nor Opera/

Apparently I am of duck today.


Quack.
-- 
Nils Dagsson Moskopp // erlehmann
<http://dieweltistgarnichtso.net>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 230 bytes
Desc: not available
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100706/1fa99361/attachment.pgp>

From svartman95 at gmail.com  Mon Jul  5 16:53:14 2010
From: svartman95 at gmail.com (Bjartur Thorlacius)
Date: Mon, 05 Jul 2010 23:53:14 +0000
Subject: [whatwg] More YouTube response
Message-ID: <4c32707d.487e0e0a.3c3b.ffffcf6a@mx.google.com>

On Mon, 5 Jul 2010, Marques Johansson <marques at displague.com> wrote:
> The company I work for, VOD.com (sfw) (aka Hotmovies .com and clips .com -
> nsfw (spaces added)), offer video on demand services to thousands of
> studios.  Our sites are central locations for customers who want to watch
> something - this is a service in itself.  We handle encoding and content
> distribution and streaming sales for these studios without any cost to them.
> They send us video content and we send them a monthly check. Without
> services like the ones we provide many of these studios (some are mom and
> pop shops) wouldn't otherwise have the ability to sell their content online
> in this fashion.
If I understand correctly, you are content distributors and video encoders.

> Customers can watch movies by purchasing packages of time or paying for DRM
> protected rentals or for some of our sites and videos they can pay for
> unprotected video.  The protected content (rentals) comes in the form of WMV
> or DivX files using either DivX's service of Windows Media Server.
So you sell copies for money and a promise to delete the copy after
it's use. That's like selling a book, printing "Burn after reading"
on it and calling yourself a library. Also the book shall not be used
for "unauthorized uses", e.g. put under a table foot, lent to a friend
or read repeatedly. The latter two cases may be solved by going to the
"library" and buying another copy, other can't.

Many people see DRM as an hybrid between a lock and a automagical fire
lighter.

> For the content that is not protected the download or stream is metered so
> the client can be charged only for the time they spent watching the content.
> We error on the customer's side for things like buffering and misreported
> play segments.
This seems like a saner alternative.
> I think the discussion that DRM is irrelevant has its merits, but the
> contracts and services at play have a real value regardless of how
> distribution is restricted.
> 
> For my purposes I am interested in application-controlled video delivery.  I
> want to be able to deliver unprotected mp4, webm, or ogv content in a
> metered way.  If the user has payed to watch the entire video once and has
> managed to work around HTTP no-cache and the other constraints that a normal
> browser viewed experience would have, then they will have succeeding in
> downloading a copy of the video - a task which they could have accomplished
> with a VM session or through other means regardless of DRM.  If we need
> additionally protection we can add watermarking to legally go after content
> thieves since we know the IP and username of the viewer in most cases.
Once a user has bought a copy, the copy has been bought and how
(often) he uses said copy isn't your probem. You've successfully
distributed and charged for the content. Job's done. A technical user
will probably be able to copy the video to permanent storage whatever
you do. Multi-pricing can also be achieved by other means, such as by
resolution crippling. Watermarking to aid with tracking down grand scale
pirates seems to be an OK thing to do.

> My requests have focused on things like "<video minbuffer=100k
> maxbuffer=200k>" which could also apply to a source element.  I want to make
> sure that the browser always uses "Range: bytes x-y" in requests (since I
> have no other way to require that a browser use ranges or use ranges with an
> upper bound).  I can use this tool to make sure UAs do not download more
> content than the user has watched (which costs them money in some way).
> I've also been suggesting HTTP changes that would permit this UA behavior
> (a 4xx for Ranges Required, a 4xx for Range too large, or explicitly
> defining that a 206 response can include less bytes than requested and the
> UA should follow-up with additional ranged requests).
> 
> While an HTML5 solution is easy to make possible as their is no legacy to
> worry about and the spec is still floating about, an HTTP solution would
> allow me to provide metered content flow without leaving HTTP sessions open
> (throttling) and without the need for a video element - permitting users to
> use their native http streaming players.
> 
> These requests can be seen as generally allowing servers to reduce load for
> video or large file downloads.  Since a client may be able to download 5
> minutes of video in under a minute I would like to see the client disconnect
> from the server and reconnect in 5 minutes to get the additional content.  I
> would like to see the server have the ability to enforce this (through HTTP
> errors) or at least suggest it (through HTML5 attributes or additional HTTP
> headers).
Server load can also be reduced by e.g. P2P, though users may want the
price to drop in proportion to their uploads.

From bzbarsky at MIT.EDU  Mon Jul  5 17:35:27 2010
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Mon, 05 Jul 2010 17:35:27 -0700
Subject: [whatwg] Iframe dimensions
In-Reply-To: <4C32346B.3090707@gmx.ch>
References: <4C3212B2.6010006@gmx.ch>	<AANLkTikKbLfmimg3CsrcdHvnsU8-DU021AbECJcQsSPy@mail.gmail.com>
	<4C32346B.3090707@gmx.ch>
Message-ID: <4C327A4F.2030703@mit.edu>

On 7/5/10 12:37 PM, Markus Ernst wrote:
> I can't imagine how the information about the computed width and height
> can be abused - would you mind giving an example?

Sure.  For example, you can often use this to detect whether the user is 
currently logged into the site in the iframe, which is a privacy leak.

Depending on the target site, other things that might be exposed this 
way are things like the number of credit card transactions the user has 
performed in the last month, the number of phone calls the user has made 
in the last month...  you get the idea.

> A possible workaround to security issues could be an element to be set
> in the included document, such as a meta tag that contains a comma
> separated list of domains that are allowed to include the document, and
> also get informations about dimensions and such. Some kind of:
> <meta name="allow-embedding" content="whatwg.org, mozilla.com">

How is this different from allowing opt-in into seamless iframes across 
origins?

> Also, if this is a potential danger, should the 2 list paragraphs about
> width and height in the part on @seamless be removed at all? As far as I
> understand, the effects of @seamless require the iframe source to be
> from the same origin as the parent document, thus I think that width and
> height of an iframe should be computed independent from @seamless. Else,
> the whole page layout is likely to change if the iframe source is
> navigated from a same-origin document to one from another origin.

Yes, it will.  Why is this a problem?

> There has been no reason for authors to apply this declaration so far,
> but if anyone did, he/she wanted the rendering I suggest.

Experience shows this to not be the case.  People blindly apply CSS 
without thinking through the implications as long as the current 
rendering is "right"; I will bet money there are pages out there that 
use display:block on iframes just to get linebreaks before/after and 
will break if the sizing behavior changes.

-Boris

From hsivonen at iki.fi  Mon Jul  5 19:25:14 2010
From: hsivonen at iki.fi (Henri Sivonen)
Date: Mon, 5 Jul 2010 19:25:14 -0700
Subject: [whatwg] More YouTube response
In-Reply-To: <AANLkTimeOZ9-b25tjpFryQParqvTH9UpGI4DArWx5Qwq@mail.gmail.com>
References: <1267897846.990.1278063443760.JavaMail.root@cm-mail03.mozilla.org>
	<1278065580.10898.7.camel@shane-laptop>
	<op.ve7rxmh064w2qv@annevk-t60> <4C2DD3F7.6020201@gmx.de>
	<4C2DE0AA.5060009@lachy.id.au>
	<AANLkTil-ZHzINNZp4nfl7OHsVtHyACu11tFKqtcGoz7q@mail.gmail.com>
	<4C2E528F.2000907@lachy.id.au>
	<4c30855c.d908e30a.4784.ffffa84f@mx.google.com>
	<AANLkTildxSwQdkH3biNWhjEXY2SBGWbPubLCqfazxv4R@mail.gmail.com>
	<4C3180FD.4010800@peda.net>
	<AANLkTimeOZ9-b25tjpFryQParqvTH9UpGI4DArWx5Qwq@mail.gmail.com>
Message-ID: <DA8E9E8B-814A-44EF-AEDA-83ED75AA8E7B@iki.fi>

On Jul 5, 2010, at 13:10, Marques Johansson wrote:

> For the content that is not protected the download or stream is metered so the client can be charged only for the time they spent watching the content.  We error on the customer's side for things like buffering and misreported play segments.

There'd be no problem if you were selling content by title (plus free trailer for sampling) instead of selling it by minute.

> I think the discussion that DRM is irrelevant has its merits, but the contracts and services at play have a real value regardless of how distribution is restricted.

I think the technology providers shouldn't feel an obligation to cater to particular contract models--especially when it complicates the technology. It makes more sense to draft contracts that are reasonable given the technology. (An example of a contract that I think technology providers shouldn't attempt to cater for is a content licensing contract that tries to distinguish between desktops, mobile devices and TVs. Such a contract makes no sense when devices of any kind can support the same standards.)

> For my purposes I am interested in application-controlled video delivery.  I want to be able to deliver unprotected mp4, webm, or ogv content in a metered way.  If the user has payed to watch the entire video once and has managed to work around HTTP no-cache and the other constraints that a normal browser viewed experience would have, then they will have succeeding in downloading a copy of the video - a task which they could have accomplished with a VM session or through other means regardless of DRM.

If the customers pay for seeing an entire title, why is it a problem if a customer once in a while downloads the bytes twice? Surely it is simpler to bake the average bandwidth cost into the price and not complicate the way the delivery technology behaves.

> These requests can be seen as generally allowing servers to reduce load for video or large file downloads.  Since a client may be able to download 5 minutes of video in under a minute I would like to see the client disconnect from the server and reconnect in 5 minutes to get the additional content.  

Wouldn't this be a non-problem if the customers paid by title? In that case, it would seem pointless to worry about the content getting downloaded faster than it is played.

It seems to me that your problem is picking a pricing model that's unnatural for the technology.

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/



From derernst at gmx.ch  Tue Jul  6 01:40:50 2010
From: derernst at gmx.ch (Markus Ernst)
Date: Tue, 06 Jul 2010 10:40:50 +0200
Subject: [whatwg] Iframe dimensions
In-Reply-To: <AANLkTim38_gSl9lpUVzG1TFUi5wDrLeG1nA-ILYl3lr5@mail.gmail.com>
References: <4C3212B2.6010006@gmx.ch>
	<AANLkTim38_gSl9lpUVzG1TFUi5wDrLeG1nA-ILYl3lr5@mail.gmail.com>
Message-ID: <4C32EC12.4020504@gmx.ch>

Am 05.07.2010 22:50 schrieb Aryeh Gregor:
> On Mon, Jul 5, 2010 at 1:13 PM, Markus Ernst <derernst at gmx.ch> wrote:
>> Some content from an external specialized content provider is included in
>> an existing web site via an iframe. This cannot be seamless, as the links
>> in the iframe must point to the original domain of the included document.
>> But in order to avoid double scroll bars, it would be desirable to have the
>> height of the iframe adjusted to it's content.
> 
> This use-case is inherently insecure.  An iframe's height cannot
> depend on the contents of a cross-origin page unless that origin
> explicitly opts in somehow.

Thank you and Boris for your examples. I see the security issues. Anyway 
It would be very helpful in cases like mine, where security and privacy 
are not affected, to get an easy way to do this opt-in without the need 
of complex scripting, and independent from @seamless. Embedding content 
from external providers looks like a quite common case to me, and an 
easy opt-in mechanism would help both the customers and the providers of 
embedded content.

Am 05.07.2010 22:50 schrieb Aryeh Gregor:
> On Mon, Jul 5, 2010 at 1:13 PM, Markus Ernst <derernst at gmx.ch> wrote:
>> - Interpreting the CSS declaration display:block as the author's wish to get
>> the iframe rendered like a block element is nothing but consistent. There
>> has been no reason for authors to apply this declaration so far, but if
>> anyone did, he/she wanted the rendering I suggest. If not (for example if
>> the iframe is floating), he/she also applied dimensions, be it in the HTML
>> or the CSS code.
> 
> The author might or might not originally have wanted the behavior you
> said, but in the end, the site doesn't render that way, and changing
> the rendering like that would make the site look very different from
> the way it looked before (= the final product that the author was
> satisfied with and released).

Am 06.07.2010 02:35 schrieb Boris Zbarsky:
 > Experience shows this to not be the case.  People blindly apply CSS
 > without thinking through the implications as long as the current
 > rendering is "right"; I will bet money there are pages out there that
 > use display:block on iframes just to get linebreaks before/after and
 > will break if the sizing behavior changes.

A BC problem with display:block would only occur if an author applied 
this declaration _without_ applying dimensions, which looks quite weird 
to me. I admit I have no statistics about this, and no means to get 
statistics. But I can hardly imagine that there are many pages like this 
out there, as the default dimensions that browsers apply to iframes are 
quite special. But anyway, I do not insist in this solution, it was just 
an idea that looked consistent to me as an author with little technical 
backgrownd knowledge.

From Simetrical+w3c at gmail.com  Tue Jul  6 03:31:49 2010
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Tue, 6 Jul 2010 06:31:49 -0400
Subject: [whatwg] Iframe dimensions
In-Reply-To: <4C32EC12.4020504@gmx.ch>
References: <4C3212B2.6010006@gmx.ch>
	<AANLkTim38_gSl9lpUVzG1TFUi5wDrLeG1nA-ILYl3lr5@mail.gmail.com>
	<4C32EC12.4020504@gmx.ch>
Message-ID: <AANLkTilQ3P6hhwrpr14n___yrUD-j0wEHQ4h7yYNElOS@mail.gmail.com>

On Tue, Jul 6, 2010 at 4:40 AM, Markus Ernst <derernst at gmx.ch> wrote:
> Thank you and Boris for your examples. I see the security issues. Anyway It
> would be very helpful in cases like mine, where security and privacy are not
> affected, to get an easy way to do this opt-in without the need of complex
> scripting, and independent from @seamless. Embedding content from external
> providers looks like a quite common case to me, and an easy opt-in mechanism
> would help both the customers and the providers of embedded content.

So what you're saying is that you really do just want seamless="" with
easy cross-origin opt-in, right?  That sounds entirely logical, and
I'm not sure why it's not specced already (or at least I don't see
it).  Could this be easily added to CORS?  CORS isn't so easy to set
up, of course, but I'm not sure it's practical to do better.  An HTML
tag would work, for HTML pages (the common case for iframes), but then
the UA wouldn't know whether it's allowed to be seamless until it
started parsing the response, which might have complications.

I don't know why you keep saying "independent from @seamless" without
giving any reason for it.  Seamless seems like exactly what you want.

From derernst at gmx.ch  Tue Jul  6 03:49:56 2010
From: derernst at gmx.ch (Markus Ernst)
Date: Tue, 06 Jul 2010 12:49:56 +0200
Subject: [whatwg] Iframe dimensions
In-Reply-To: <AANLkTilQ3P6hhwrpr14n___yrUD-j0wEHQ4h7yYNElOS@mail.gmail.com>
References: <4C3212B2.6010006@gmx.ch>	<AANLkTim38_gSl9lpUVzG1TFUi5wDrLeG1nA-ILYl3lr5@mail.gmail.com>	<4C32EC12.4020504@gmx.ch>
	<AANLkTilQ3P6hhwrpr14n___yrUD-j0wEHQ4h7yYNElOS@mail.gmail.com>
Message-ID: <4C330A54.5030906@gmx.ch>

Am 06.07.2010 12:31 schrieb Aryeh Gregor:
> On Tue, Jul 6, 2010 at 4:40 AM, Markus Ernst <derernst at gmx.ch> wrote:
>> Thank you and Boris for your examples. I see the security issues. Anyway It
>> would be very helpful in cases like mine, where security and privacy are not
>> affected, to get an easy way to do this opt-in without the need of complex
>> scripting, and independent from @seamless. Embedding content from external
>> providers looks like a quite common case to me, and an easy opt-in mechanism
>> would help both the customers and the providers of embedded content.
> 
> So what you're saying is that you really do just want seamless="" with
> easy cross-origin opt-in, right?  That sounds entirely logical, and
> I'm not sure why it's not specced already (or at least I don't see
> it).  Could this be easily added to CORS?  CORS isn't so easy to set
> up, of course, but I'm not sure it's practical to do better.  An HTML
> tag would work, for HTML pages (the common case for iframes), but then
> the UA wouldn't know whether it's allowed to be seamless until it
> started parsing the response, which might have complications.
> 
> I don't know why you keep saying "independent from @seamless" without
> giving any reason for it.  Seamless seems like exactly what you want.

My problem is this sentence in the spec for seamless: "This will cause 
links to open in the parent browsing context."

In an application like 
http://test.rapid.ch/de/haendler-schweiz/iseki.html, the external page 
should be able to re-call itself inside the iframe, for example if a 
sort link is clicked or a search form submitted.

From andreluis.pt at gmail.com  Tue Jul  6 04:52:24 2010
From: andreluis.pt at gmail.com (=?ISO-8859-1?Q?Andr=E9_Lu=EDs?=)
Date: Tue, 6 Jul 2010 12:52:24 +0100
Subject: [whatwg] Resolutions meta tag proposal
In-Reply-To: <4C30F5CC.6010009@emsai.net>
References: <AANLkTinvknm7dSA_Er_xC1MOZFE6dA5M1X01wEgtpa7T@mail.gmail.com>
	<AANLkTil8ktnvX0v1eyQiSINLPhpZZMI1S-MZmxTUwmjx@mail.gmail.com>
	<AANLkTil8aM6Llx0fhQTaEhcOasvGmoSJUbr8xXtkcj2H@mail.gmail.com>
	<AANLkTikgOvvqJfJI8TehJn6tOQWT8O7n6Fs0723VROcb@mail.gmail.com>
	<AANLkTim8ZxFYSbcUF2LiBSSvICPaogRytFGPk-uLiQb1@mail.gmail.com>
	<4C30F5CC.6010009@emsai.net>
Message-ID: <AANLkTik-cNubyrSpfJ5R4umPP5RmYiOcp_HdYSWwEJi2@mail.gmail.com>

G'day,

since the discussion is more or less trying to find a solution in the
markup realm (which I thoroughly support), I'm gonna focus on Roger's
proposal of @dpi.

I believe the proposal might work. But assuming you might want to
target 3x resolutions on all <img> the size of the document will
increase.

Like Roger said, it's very important to have this working on a several of ways.

1) content negotiation, at the server level.
2) markup, @dpi or other attribute specifying an alt resource for each
resolution ( <img src resolutions="">?)
3) css, media queries are able to do this.. right?
4) javascript, give access to the document's current resolution in
dpi's, under screen.resolution?

Although, on point 2, i still prefer the way I suggested earlier, to
make <img> work like the other media tags: <video> <audio>, with child
<source> elements that could have either a resolution="96" (per
proposal of Roger) attribute or a media query...

Anyway, is it still time to have this conversation? Will additions to
the spec be considered?

Since this Retina (high res screens) business is very new, there isn't
much real-world usage to harvest proof of... but is there a process or
a set of steps a proposal must go through?

--
Andr? Lu?s
http://id.andr3.net/

On 4 July 2010 21:57, Roger H?gensen <rescator at emsai.net> wrote:
> On 2010-07-04 14:34, Marques Johansson wrote:
>>
>> Another way about handling this PPI ratio business would be with HTTP 300
>> multiple choice.
>> http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.1
>>
>> This may not be the best answer for every image on a page, but the first
>> HTML page in a server controlled session could store the PPI ratio setting
>> based on the page the UA chooses and then modify the HTML or
>> content-negotiation setting. ?A problem with this is that the browsers
>> wouldn't be likely to render a page correctly unless they were modified for
>> this image request yields 300 behavior.
>>
>> I still like something like this for client content negotiation:
>>
>> GET /image/dog HTTP/1.1
>> Accept: image/*; ppiratio=2
>> ...
>> HTTP/1.1 200 OK
>> Content-type: image/jpeg
>> ... dog at 2x.jpg
>>
>> Apache rewrite rules could even handle this by detecting ppiratio in the
>> Accept header and then looking for a matching images/ratio/2/dog file. ?If
>> it didn't exist the rewrite would fail resulting in the server responding
>> with images/dog which is suitable if not optimal.
>>
>> This has me thinking "Accept: image/*; x=400; y=300" could be attached
>> with any image request based on clients intent for the image. ?(The HTML
>> said 'width=400 height=300' so I don't need anything better.) ?The server
>> can ignore this or return something better suited than the 1200x1200 image
>> that it would otherwise return.
>>
>> I still don't have a handle on this retinal / ppi stuff so "ppiratio" may
>> be the wording.
>> I also like "Accept: video/*; kbps=500" for a similar purpose.
>>
>
> Again this is negotiation related, and although I'm able to do fancy apache
> stuff on my site I'd rather not have to.
>
> This however takes advantage of CSS
> http://www.alistapart.com/articles/hiresprinting/
>
> Not exactly ideal, but I think it's the better approach, it just need to be
> refined and standardized some way.
>
> But here's an idea I have that would fit into HTML5.
>
> Examples:
> 1. <img src="img/test.png" width="512" height="256"
> dpi="96;;300;image/test300.png"> work better?
> (96 dpi is current thus empty ;; while 300 dpi is alternative hence
> specified.
> 2. <img src="img/test.png" width="512" height="256" dpi="300"> woould also
> be valid, indicating that the image is 300 dpi and no alternatives.
> 3. <img src="img/test.png" width="512" height="256"
> dpi="300;image/test300.png"> same as example 1, 96 dpi default assumed.
> 4. <img src="img/test.png" width="512" height="256" dpi="*;image/test.svg">
> 96 dpi default assumed, the * indicate any DPI and in this case it's a
> vector format.
> If dpi="" or is not specified, then the image should be assumed to be 96dpi,
> unless the image format has it's own dpi info (JPG support this, but does
> PNG?) that is.
>
> This would make printouts look better, and allows the author to specify
> displayed size (width and height being logical pixels for non-96 dpi images
> obviously)
> High DPI displays would make the browser get the high dpi image instead of
> the default.
>
> The only parts of a site that has issues currently is fixed pixel graphics
> (and fixed pixel based layout as well I guess),
> it is only pixel based (bitmapped) images that has issues with scaling,
> embed video already tend to offer multiple resolutions.
>
> So a dpi param for img might just be a nice way to fix the issue.
> The CSS folks might have to add some support for this too, as well as
> scripting support.
>
> This is just something I came up with right now, but it's at least simple in
> use which is the important thing I guess.
>
> --
> Roger "Rescator" H?gensen.
> Freelancer - http://EmSai.net/
>
>

From annevk at opera.com  Tue Jul  6 05:12:36 2010
From: annevk at opera.com (Anne van Kesteren)
Date: Tue, 06 Jul 2010 14:12:36 +0200
Subject: [whatwg] Resolutions meta tag proposal
In-Reply-To: <AANLkTik-cNubyrSpfJ5R4umPP5RmYiOcp_HdYSWwEJi2@mail.gmail.com>
References: <AANLkTinvknm7dSA_Er_xC1MOZFE6dA5M1X01wEgtpa7T@mail.gmail.com>
	<AANLkTil8ktnvX0v1eyQiSINLPhpZZMI1S-MZmxTUwmjx@mail.gmail.com>
	<AANLkTil8aM6Llx0fhQTaEhcOasvGmoSJUbr8xXtkcj2H@mail.gmail.com>
	<AANLkTikgOvvqJfJI8TehJn6tOQWT8O7n6Fs0723VROcb@mail.gmail.com>
	<AANLkTim8ZxFYSbcUF2LiBSSvICPaogRytFGPk-uLiQb1@mail.gmail.com>
	<4C30F5CC.6010009@emsai.net>
	<AANLkTik-cNubyrSpfJ5R4umPP5RmYiOcp_HdYSWwEJi2@mail.gmail.com>
Message-ID: <op.vfe77ano64w2qv@annevk-t60>

On Tue, 06 Jul 2010 13:52:24 +0200, Andr? Lu?s <andreluis.pt at gmail.com>  
wrote:
> [...] i still prefer the way I suggested earlier, to
> make <img> work like the other media tags: <video> <audio>, with child
> <source> elements that could have either a resolution="96" (per
> proposal of Roger) attribute or a media query...

We cannot have child elements for <img>. Content (legacy and new)  
constraints how <img> is and will be parsed.


> Anyway, is it still time to have this conversation? Will additions to
> the spec be considered?

Yes, though extensions to the <meta> element can be done independently  
 from the specification. As a standalone specification.


> Since this Retina (high res screens) business is very new, there isn't
> much real-world usage to harvest proof of... but is there a process or
> a set of steps a proposal must go through?

There is a somewhat informal process, yes:

http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F


Personally I do not think detailed control is needed at all. It requires  
way too much configuration and hassle for little benefit. What Dave Hyatt  
outlined in http://webkit.org/blog/55/high-dpi-web-sites/ for the img  
element is good enough. I.e. always load the high resolution version and  
scale it down for "lesser" displays using height/width. Sure, some more  
bandwidth is used, but that is not a big deal, especially if you consider  
that the higher resolution version goes to the device with less bandwidth.  
So if bandwidth was a concern we would not be having this discussion.


-- 
Anne van Kesteren
http://annevankesteren.nl/

From marques at displague.com  Tue Jul  6 06:19:35 2010
From: marques at displague.com (Marques Johansson)
Date: Tue, 6 Jul 2010 09:19:35 -0400
Subject: [whatwg] More YouTube response
In-Reply-To: <DA8E9E8B-814A-44EF-AEDA-83ED75AA8E7B@iki.fi>
References: <1267897846.990.1278063443760.JavaMail.root@cm-mail03.mozilla.org>
	<1278065580.10898.7.camel@shane-laptop> <op.ve7rxmh064w2qv@annevk-t60> 
	<4C2DD3F7.6020201@gmx.de> <4C2DE0AA.5060009@lachy.id.au>
	<AANLkTil-ZHzINNZp4nfl7OHsVtHyACu11tFKqtcGoz7q@mail.gmail.com> 
	<4C2E528F.2000907@lachy.id.au>
	<4c30855c.d908e30a.4784.ffffa84f@mx.google.com> 
	<AANLkTildxSwQdkH3biNWhjEXY2SBGWbPubLCqfazxv4R@mail.gmail.com> 
	<4C3180FD.4010800@peda.net>
	<AANLkTimeOZ9-b25tjpFryQParqvTH9UpGI4DArWx5Qwq@mail.gmail.com> 
	<DA8E9E8B-814A-44EF-AEDA-83ED75AA8E7B@iki.fi>
Message-ID: <AANLkTil8nprqDEtayJMdB0q0-847pDtaSKT70f2XJTvu@mail.gmail.com>

On Mon, Jul 5, 2010 at 10:25 PM, Henri Sivonen <hsivonen at iki.fi> wrote:

> On Jul 5, 2010, at 13:10, Marques Johansson wrote:
>
> > For the content that is not protected the download or stream is metered
> so the client can be charged only for the time they spent watching the
> content.  We error on the customer's side for things like buffering and
> misreported play segments.
>
> There'd be no problem if you were selling content by title (plus free
> trailer for sampling) instead of selling it by minute.


If a user is paying for bandwidth why should they need to pay for a download
of the full movie when they are only interested in a few scenes or a few key
seconds of the video.

A friend of mine called this weekend to confirm that a scene in Back to the
Future 3 that has been popping up online was actually in the movie and not
just some Internet hoax.  He called to have me watch a particular segment on
the DVD.  I watched all of 3 minutes of the movie to confirm the original
scene contents.  Doc Brown's young blond haired train companion (who only
appears at the end of the movie) displays a very preverse set of gestures in
his 10 seconds of screen time that should have been edited out (I dodged all
spoilers).  There is a market for this kind of viewing habit that does not
insist on the consumer purchasing a full right/license to the entire video
nor the bandwidth or storage to accommodate it.

When you are selling adult content - many users are much happier to pay for
a few minutes of content that they seek through rather than a full movie
that they will have little interest in watching again.  The difference can
easily be $.16 versus $16.  As for trailers, many of our plans include
additional time and all users that have ever purchased get 3 free 30 second
plays weekly.  That being said, I don't think the business models of one of
the largest online video markets should put be on trial through a by a
standards list.

> I think the discussion that DRM is irrelevant has its merits, but the
> contracts and services at play have a real value regardless of how
> distribution is restricted.
>
> I think the technology providers shouldn't feel an obligation to cater to
> particular contract models--especially when it complicates the technology.
> It makes more sense to draft contracts that are reasonable given the
> technology. (An example of a contract that I think technology providers
> shouldn't attempt to cater for is a content licensing contract that tries to
> distinguish between desktops, mobile devices and TVs. Such a contract makes
> no sense when devices of any kind can support the same standards.)


I think providers cater to the technology that's available.  At the time
these contracts were drawn up Windows Media player and Real were leading the
streaming video market.  The contracts and services in place now were
created pre-Youtube, when most users accessed the site with a 56 modem or
less.  The service was geared toward online streaming and streaming rentals
rather than downloads - which could take some users days to complete - or
longer when coupled with bad re-try behaviors in browsers.  Cell phones
couldn't play let alone download a video over their 14kbps connection.


> > For my purposes I am interested in application-controlled video delivery.
>  I want to be able to deliver unprotected mp4, webm, or ogv content in a
> metered way.  If the user has payed to watch the entire video once and has
> managed to work around HTTP no-cache and the other constraints that a normal
> browser viewed experience would have, then they will have succeeding in
> downloading a copy of the video - a task which they could have accomplished
> with a VM session or through other means regardless of DRM.
>
> If the customers pay for seeing an entire title, why is it a problem if a
> customer once in a while downloads the bytes twice? Surely it is simpler to
> bake the average bandwidth cost into the price and not complicate the way
> the delivery technology behaves.


We have different plans available.  Some allow a user to stream a chosen
video as often as they want.  There are plans that allow users to stream an
entire studios selection of videos on demand.  This likens the service to a
monthly membership site and the company I work for has found that many users
prefer to not have that sort of commitment - preferring instead to pay for
what they watch when they watch it. The choice is determined by the content
provider and the user - we accomodate both parties to the best of our
ability.


> > These requests can be seen as generally allowing servers to reduce load
> for video or large file downloads.  Since a client may be able to download 5
> minutes of video in under a minute I would like to see the client disconnect
> from the server and reconnect in 5 minutes to get the additional content.
>
> Wouldn't this be a non-problem if the customers paid by title? In that
> case, it would seem pointless to worry about the content getting downloaded
> faster than it is played.
>
> It seems to me that your problem is picking a pricing model that's
> unnatural for the technology.


Partial requests are native to HTTP and seeking is natural for a healthy
streamed viewing habit - I'm look for a way to get the browser to take the
servers recommendation that the content be fetched in a particular way - we
have content negotiation of transfer encoding and image quality, why not
allow the server to negotiate the transfer size for the benefit of the user
and the server?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100706/32fe1c19/attachment.htm>

From marques at displague.com  Tue Jul  6 07:01:48 2010
From: marques at displague.com (Marques Johansson)
Date: Tue, 6 Jul 2010 10:01:48 -0400
Subject: [whatwg] More YouTube response
In-Reply-To: <4c32707d.487e0e0a.3c3b.ffffcf6a@mx.google.com>
References: <4c32707d.487e0e0a.3c3b.ffffcf6a@mx.google.com>
Message-ID: <AANLkTin0xDp8_n1lOYhac1srnhF9adLTXfCWLyKWR48y@mail.gmail.com>

On Mon, Jul 5, 2010 at 7:53 PM, Bjartur Thorlacius <svartman95 at gmail.com>wrote:

> On Mon, 5 Jul 2010, Marques Johansson <marques at displague.com> wrote:
> > The company I work for, VOD.com (sfw) (aka Hotmovies .com and clips .com
> -
> > nsfw (spaces added)), offer video on demand services to thousands of
>
If I understand correctly, you are content distributors and video encoders.
>

Yes.


> > Customers can watch movies by purchasing packages of time or paying for
> DRM
> > protected rentals or for some of our sites and videos they can pay for
> > unprotected video.  The protected content (rentals) comes in the form of
> WMV
> > or DivX files using either DivX's service of Windows Media Server.
> So you sell copies for money and a promise to delete the copy after
> it's use. That's like selling a book, printing "Burn after reading"
> on it and calling yourself a library. Also the book shall not be used
> for "unauthorized uses", e.g. put under a table foot, lent to a friend
> or read repeatedly. The latter two cases may be solved by going to the
> "library" and buying another copy, other can't.
>
> Many people see DRM as an hybrid between a lock and a automagical fire
> lighter.
>

Yes, let's get Amazon MP3 and the Itunes store closed down immediately.  I'm
not lobbying for DRM inclusion into HTML5 - I'm looking for server side HTML
or HTTP ways to limit transfer sizes.

Once a user has bought a copy, the copy has been bought and how
> (often) he uses said copy isn't your probem. You've successfully
> distributed and charged for the content. Job's done. A technical user
> will probably be able to copy the video to permanent storage whatever
> you do. Multi-pricing can also be achieved by other means, such as by
> resolution crippling. Watermarking to aid with tracking down grand scale
> pirates seems to be an OK thing to do.
>

I know that a technical user will have the ability to do this.  They will
have at least paid for one copy.


> Server load can also be reduced by e.g. P2P, though users may want the
> price to drop in proportion to their uploads.
>

I am using a standard video format and standard HTTP/HTML to distribute
video.  You don't see many P2P HTTP solutions around these days.

Bandwidth isn't the issue in my case, but I would rather have the user
disconnect from the server and play the video they've got before requesting
more.  The less open / throttled connections the server has to deal with the
better it performs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100706/1851c74d/attachment.htm>

From toni.ruottu at iki.fi  Tue Jul  6 07:11:50 2010
From: toni.ruottu at iki.fi (Toni Ruottu)
Date: Tue, 6 Jul 2010 17:11:50 +0300
Subject: [whatwg] what happened to sendAsBinary?
In-Reply-To: <AANLkTine-F4o69r9mLAB-EraxizzzuH3i3u5cNE-rsmW@mail.gmail.com>
References: <AANLkTimj9jmiDUHy3U6TV3fQQUmyQqV3GdNZgBKofhx1@mail.gmail.com>
	<AANLkTine-F4o69r9mLAB-EraxizzzuH3i3u5cNE-rsmW@mail.gmail.com>
Message-ID: <AANLkTilyW18Kk5MleHNLHzIxK6fqJPjsoM4CHb1zXLUg@mail.gmail.com>

I was looking at jquery, but I am not sure it works. The problem is
that jqeury serializes a web form, where it enters the data in a
field. We need to send the binary data alone.

  --Toni

On Wed, Jun 30, 2010 at 11:14 PM, narendra sisodiya
<narendra at narendrasisodiya.com> wrote:
>
>
> On Wed, Jun 30, 2010 at 3:57 PM, Toni Ruottu <toni.ruottu at iki.fi> wrote:
>>
>> ?hello
>>
>> We are trying to code an application that needs to send some binary
>> data from javascript to a http server. The server is expecting to
>> receive the data in the body of the request, and for the body to not
>> include anything other than the raw data. In the old world you would
>> do this with the sendAsBinary function, available at least in Firefox.
>> How would you do the same thing with XHR2?
>>
>> ?cheers, --Toni
>
> I guess, xhr.sendAsBinary() shoud work
>
> search for string "xhr.sendAsBinary" in following code link
> http://code.google.com/p/jquery-html5-upload/issues/attachmentText?id=9&aid=-4788561921002613366&name=jquery.html5_upload.js&token=279fec81f59a07b7c79ae3ffb7cb9654
> --
> ???????????????????????????
> ? ? ?Narendra Sisodiya
> ? ? ?http://narendrasisodiya.com
> ???????????????????????????
>

From philipj at opera.com  Tue Jul  6 07:12:53 2010
From: philipj at opera.com (=?iso-8859-15?Q?Philip_J=E4genstedt?=)
Date: Tue, 06 Jul 2010 16:12:53 +0200
Subject: [whatwg] More YouTube response
In-Reply-To: <AANLkTil8nprqDEtayJMdB0q0-847pDtaSKT70f2XJTvu@mail.gmail.com>
References: <1267897846.990.1278063443760.JavaMail.root@cm-mail03.mozilla.org>
	<1278065580.10898.7.camel@shane-laptop> <op.ve7rxmh064w2qv@annevk-t60>
	<4C2DD3F7.6020201@gmx.de> <4C2DE0AA.5060009@lachy.id.au>
	<AANLkTil-ZHzINNZp4nfl7OHsVtHyACu11tFKqtcGoz7q@mail.gmail.com>
	<4C2E528F.2000907@lachy.id.au>
	<4c30855c.d908e30a.4784.ffffa84f@mx.google.com>
	<AANLkTildxSwQdkH3biNWhjEXY2SBGWbPubLCqfazxv4R@mail.gmail.com>
	<4C3180FD.4010800@peda.net>
	<AANLkTimeOZ9-b25tjpFryQParqvTH9UpGI4DArWx5Qwq@mail.gmail.com>
	<DA8E9E8B-814A-44EF-AEDA-83ED75AA8E7B@iki.fi>
	<AANLkTil8nprqDEtayJMdB0q0-847pDtaSKT70f2XJTvu@mail.gmail.com>
Message-ID: <op.vffdrrgzatwj1d@philip-pc.gothenburg.osa>

On Tue, 06 Jul 2010 15:19:35 +0200, Marques Johansson  
<marques at displague.com> wrote:

> On Mon, Jul 5, 2010 at 10:25 PM, Henri Sivonen <hsivonen at iki.fi> wrote:
>
>> On Jul 5, 2010, at 13:10, Marques Johansson wrote:
>>
>> > For the content that is not protected the download or stream is  
>> metered
>> so the client can be charged only for the time they spent watching the
>> content.  We error on the customer's side for things like buffering and
>> misreported play segments.
>>
>> There'd be no problem if you were selling content by title (plus free
>> trailer for sampling) instead of selling it by minute.
>
>
> If a user is paying for bandwidth why should they need to pay for a  
> download
> of the full movie when they are only interested in a few scenes or a few  
> key
> seconds of the video.
>
> A friend of mine called this weekend to confirm that a scene in Back to  
> the
> Future 3 that has been popping up online was actually in the movie and  
> not
> just some Internet hoax.  He called to have me watch a particular  
> segment on
> the DVD.  I watched all of 3 minutes of the movie to confirm the original
> scene contents.  Doc Brown's young blond haired train companion (who only
> appears at the end of the movie) displays a very preverse set of  
> gestures in
> his 10 seconds of screen time that should have been edited out (I dodged  
> all
> spoilers).  There is a market for this kind of viewing habit that does  
> not
> insist on the consumer purchasing a full right/license to the entire  
> video
> nor the bandwidth or storage to accommodate it.
>
> When you are selling adult content - many users are much happier to pay  
> for
> a few minutes of content that they seek through rather than a full movie
> that they will have little interest in watching again.  The difference  
> can
> easily be $.16 versus $16.  As for trailers, many of our plans include
> additional time and all users that have ever purchased get 3 free 30  
> second
> plays weekly.  That being said, I don't think the business models of one  
> of
> the largest online video markets should put be on trial through a by a
> standards list.
>
>> I think the discussion that DRM is irrelevant has its merits, but the
>> contracts and services at play have a real value regardless of how
>> distribution is restricted.
>>
>> I think the technology providers shouldn't feel an obligation to cater  
>> to
>> particular contract models--especially when it complicates the  
>> technology.
>> It makes more sense to draft contracts that are reasonable given the
>> technology. (An example of a contract that I think technology providers
>> shouldn't attempt to cater for is a content licensing contract that  
>> tries to
>> distinguish between desktops, mobile devices and TVs. Such a contract  
>> makes
>> no sense when devices of any kind can support the same standards.)
>
>
> I think providers cater to the technology that's available.  At the time
> these contracts were drawn up Windows Media player and Real were leading  
> the
> streaming video market.  The contracts and services in place now were
> created pre-Youtube, when most users accessed the site with a 56 modem or
> less.  The service was geared toward online streaming and streaming  
> rentals
> rather than downloads - which could take some users days to complete - or
> longer when coupled with bad re-try behaviors in browsers.  Cell phones
> couldn't play let alone download a video over their 14kbps connection.
>
>
>> > For my purposes I am interested in application-controlled video  
>> delivery.
>>  I want to be able to deliver unprotected mp4, webm, or ogv content in a
>> metered way.  If the user has payed to watch the entire video once and  
>> has
>> managed to work around HTTP no-cache and the other constraints that a  
>> normal
>> browser viewed experience would have, then they will have succeeding in
>> downloading a copy of the video - a task which they could have  
>> accomplished
>> with a VM session or through other means regardless of DRM.
>>
>> If the customers pay for seeing an entire title, why is it a problem if  
>> a
>> customer once in a while downloads the bytes twice? Surely it is  
>> simpler to
>> bake the average bandwidth cost into the price and not complicate the  
>> way
>> the delivery technology behaves.
>
>
> We have different plans available.  Some allow a user to stream a chosen
> video as often as they want.  There are plans that allow users to stream  
> an
> entire studios selection of videos on demand.  This likens the service  
> to a
> monthly membership site and the company I work for has found that many  
> users
> prefer to not have that sort of commitment - preferring instead to pay  
> for
> what they watch when they watch it. The choice is determined by the  
> content
> provider and the user - we accomodate both parties to the best of our
> ability.
>
>
>> > These requests can be seen as generally allowing servers to reduce  
>> load
>> for video or large file downloads.  Since a client may be able to  
>> download 5
>> minutes of video in under a minute I would like to see the client  
>> disconnect
>> from the server and reconnect in 5 minutes to get the additional  
>> content.
>>
>> Wouldn't this be a non-problem if the customers paid by title? In that
>> case, it would seem pointless to worry about the content getting  
>> downloaded
>> faster than it is played.
>>
>> It seems to me that your problem is picking a pricing model that's
>> unnatural for the technology.
>
>
> Partial requests are native to HTTP and seeking is natural for a healthy
> streamed viewing habit - I'm look for a way to get the browser to take  
> the
> servers recommendation that the content be fetched in a particular way -  
> we
> have content negotiation of transfer encoding and image quality, why not
> allow the server to negotiate the transfer size for the benefit of the  
> user
> and the server?

Is preload="none" not enough? I can't imagine the actual bandwidth savings  
of more fine-grained control to be significant, probably any attempt by  
the browser to stop buffering after some time is good enough.

-- 
Philip J?genstedt
Core Developer
Opera Software

From marques at displague.com  Tue Jul  6 07:24:45 2010
From: marques at displague.com (Marques Johansson)
Date: Tue, 6 Jul 2010 10:24:45 -0400
Subject: [whatwg] More YouTube response
In-Reply-To: <AANLkTilOOfaTJetwoSJWSacAPmSfrFuOSx7CNysX6tBW@mail.gmail.com>
References: <AANLkTinbe-p-STmyfGAiGA6NR7cZO-nzqlq405O5gGTd@mail.gmail.com> 
	<20100705174502.763d384f@desudesudesu>
	<AANLkTilOOfaTJetwoSJWSacAPmSfrFuOSx7CNysX6tBW@mail.gmail.com>
Message-ID: <AANLkTilRA7CT2YvUv6Jz7J1WgNA_k5N1lqPZ2YB82ks3@mail.gmail.com>

On Mon, Jul 5, 2010 at 4:26 PM, Aryeh Gregor
<Simetrical+w3c at gmail.com<Simetrical%2Bw3c at gmail.com>
> wrote:

> On Mon, Jul 5, 2010 at 4:10 PM, Marques Johansson <marques at displague.com>
> wrote:
> > For my purposes I am interested in application-controlled video delivery.
>  I
> > want to be able to deliver unprotected mp4, webm, or ogv content in a
> > metered way.  If the user has payed to watch the entire video once and
> has
> > managed to work around HTTP no-cache and the other constraints that a
> normal
> > browser viewed experience would have, then they will have succeeding in
> > downloading a copy of the video - a task which they could have
> accomplished
> > with a VM session or through other means regardless of DRM.
>
> There's no way to stop this at the markup level, since the user could
> just configure a user-agent to ignore the attributes, or manually
> remove them with a tool like Firebug.  More to the point, since this
> feature doesn't provide significant benefit to many users or authors,
> no user agent would bother implementing it in the first place.
>
> You should instead look into to writing server-side scripts that meet
> your needs.  When the user requests a video, have the script check how
> much video the user is authorized to view, and just truncate it after
> that point.  Or have it insert an extra clip at the end of what
> they're allowed to view saying "you have to pay more to keep viewing",
> then truncate it.  Or whatever.  This is pretty easy to do, and not
> possible for the user to circumvent.


If the UA didn't follow the prescribed size constraints they would get a 403
response (or a better 4xx range too large if it existed).

The benefit to the user is that they could have less open network
connections while streaming video from server controlled sites and those
sites will have the ability to meter their usage more accurately.

Inserting an extra clip at the end is more of a playlist or scripting
answer.  Or perhaps a a live re-encoding answer.   I'm looking for a way to
give the user the raw video file in a metered way.  A 200 response or
partial 206 responses that returns less than the full requested range is not
handled by browsers in a consistent or usable way (for this purpose).  Only
Chrome will continue to fetch where the previous short 206 response left off
(request 1-10, server replies 1-5, request 6-10, server replies 6-10).  The
HTTP spec isn't clear about whether UAs should take this behavior - and so
they don't.

Some UAs request video without sending "Range: bytes 0-".  The server has no
way to negotiate that the UA (a) must use ranges to complete the request or
that (b) the range requested is too large, retry will a smaller range.

> These requests can be seen as generally allowing servers to reduce load
> for
> > video or large file downloads.  Since a client may be able to download 5
> > minutes of video in under a minute I would like to see the client
> disconnect
> > from the server and reconnect in 5 minutes to get the additional content.
>  I
> > would like to see the server have the ability to enforce this (through
> HTTP
> > errors) or at least suggest it (through HTML5 attributes or additional
> HTTP
> > headers).
>
> Well-written clients should already buffer only as much as they need
> to ensure the video will play smoothly.  The preload="" attribute is
> already provided to allow authors to control this behavior.  When the
> client has read enough for now, it will just stop reading new content
> from the server until it needs more.  If the server thinks that the
> client is reading too fast, on the other hand, it can just send fewer
> packets.  Again, I don't think anything needs to be changed in HTML
> here.
>

All of the current video clients make requests like "Range: 0-" or (when you
seek) "Range: 0-end_of_file".  I don't want to give them the whole 2gb file
right now, they may seek to the end of the video at any moment while the
server is paying to send that data and the transfer will have been wasted.
 I don't want to throttle the connection because that is also a waste of
resources.  I want the UA to request X many bytes (which equates to some
fragment of time), disconnect if they will be busy beyond the keep-alive
time, and come back when they need more video data.  A 200 response and an
unbounded 206 response do not permit this.

If the <video> tag included a minbuffer and a maxbuffer (at least the
latter) then the client would always have an upper bound on video ranges
requested.  If the UA failed to include this the server can give them a 403,
416, or some 4xx that does not yet exist.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100706/75e5e419/attachment.htm>

From marques at displague.com  Tue Jul  6 07:33:47 2010
From: marques at displague.com (Marques Johansson)
Date: Tue, 6 Jul 2010 10:33:47 -0400
Subject: [whatwg] More YouTube response
In-Reply-To: <op.vffdrrgzatwj1d@philip-pc.gothenburg.osa>
References: <1267897846.990.1278063443760.JavaMail.root@cm-mail03.mozilla.org>
	<1278065580.10898.7.camel@shane-laptop> <op.ve7rxmh064w2qv@annevk-t60> 
	<4C2DD3F7.6020201@gmx.de> <4C2DE0AA.5060009@lachy.id.au>
	<AANLkTil-ZHzINNZp4nfl7OHsVtHyACu11tFKqtcGoz7q@mail.gmail.com> 
	<4C2E528F.2000907@lachy.id.au>
	<4c30855c.d908e30a.4784.ffffa84f@mx.google.com> 
	<AANLkTildxSwQdkH3biNWhjEXY2SBGWbPubLCqfazxv4R@mail.gmail.com> 
	<4C3180FD.4010800@peda.net>
	<AANLkTimeOZ9-b25tjpFryQParqvTH9UpGI4DArWx5Qwq@mail.gmail.com> 
	<DA8E9E8B-814A-44EF-AEDA-83ED75AA8E7B@iki.fi>
	<AANLkTil8nprqDEtayJMdB0q0-847pDtaSKT70f2XJTvu@mail.gmail.com> 
	<op.vffdrrgzatwj1d@philip-pc.gothenburg.osa>
Message-ID: <AANLkTini3AdVUQm8cV___L6tKEfxe8sPD-ZunyNeV_cK@mail.gmail.com>

On Tue, Jul 6, 2010 at 10:12 AM, Philip J?genstedt <philipj at opera.com>wrote:

> On Tue, 06 Jul 2010 15:19:35 +0200, Marques Johansson <
> marques at displague.com> wrote:
>
> Is preload="none" not enough? I can't imagine the actual bandwidth savings
> of more fine-grained control to be significant, probably any attempt by the
> browser to stop buffering after some time is good enough.


I have been using preload="metadata" in my testing.  If the browser fetches
the metadata then they should be able to seek through the video more easily
and should have all the information they need to make partial requests with
upper bounds.  Again - I have no HTML or HTTP way to suggest the UA only
take X many bytes for now and come back later for more.

Since I see you are with Opera - I noticed that Opera will play ogg files in
a different way than webm files.  The ogg handler will handle short 206
responses by making requests for the next range (client requests 0-10,
server responds with a 206 status, bytes 0-5, client plays then fetches
bytes 6-10).  The webm handler will only play the range that was sent in the
initial 206 (client requests 0-10, server responds with a 206 status, bytes
0-5, client stops playing).

I also noticed that Opera will ignore no-cache headers on video content so a
206 fragment marked as no-cache can be rewinded and replayed without making
additional requests.  Chrome refetches the data.  Looking at this as a pure
HTTP matter I believe Chrome is taking the correct action.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100706/85c87eb6/attachment.htm>

From kornel at geekhood.net  Tue Jul  6 07:41:28 2010
From: kornel at geekhood.net (Kornel Lesinski)
Date: Tue, 6 Jul 2010 15:41:28 +0100
Subject: [whatwg] More YouTube response
In-Reply-To: <AANLkTilRA7CT2YvUv6Jz7J1WgNA_k5N1lqPZ2YB82ks3@mail.gmail.com>
References: <AANLkTinbe-p-STmyfGAiGA6NR7cZO-nzqlq405O5gGTd@mail.gmail.com>
	<20100705174502.763d384f@desudesudesu>
	<AANLkTilOOfaTJetwoSJWSacAPmSfrFuOSx7CNysX6tBW@mail.gmail.com>
	<AANLkTilRA7CT2YvUv6Jz7J1WgNA_k5N1lqPZ2YB82ks3@mail.gmail.com>
Message-ID: <603C7FB4-0C3F-4B8F-8554-4A1A38C10239@geekhood.net>

On 6 Jul 2010, at 15:24, Marques Johansson wrote:

> A 200 response or partial 206 responses that returns less than the full requested range is not handled by browsers in a consistent or usable way (for this purpose).  Only Chrome will continue to fetch where the previous short 206 response left off (request 1-10, server replies 1-5, request 6-10, server replies 6-10).  The HTTP spec isn't clear about whether UAs should take this behavior - and so they don't.

It might be easier to get that fixed in browsers, than to get spec+implementation of a completely new feature.

> Some UAs request video without sending "Range: bytes 0-".  The server has no way to negotiate that the UA (a) must use ranges to complete the request or that (b) the range requested is too large, retry will a smaller range.

You could respond with HTTP/1.0 and close connection. You could split movie into separate video files and hide that fact in the player's UI (sort-of like Apple's HTTP live streaming).

-- 
regards, Kornel


From philipj at opera.com  Tue Jul  6 07:48:00 2010
From: philipj at opera.com (=?iso-8859-15?Q?Philip_J=E4genstedt?=)
Date: Tue, 06 Jul 2010 16:48:00 +0200
Subject: [whatwg] More YouTube response
In-Reply-To: <AANLkTini3AdVUQm8cV___L6tKEfxe8sPD-ZunyNeV_cK@mail.gmail.com>
References: <1267897846.990.1278063443760.JavaMail.root@cm-mail03.mozilla.org>
	<1278065580.10898.7.camel@shane-laptop> <op.ve7rxmh064w2qv@annevk-t60>
	<4C2DD3F7.6020201@gmx.de> <4C2DE0AA.5060009@lachy.id.au>
	<AANLkTil-ZHzINNZp4nfl7OHsVtHyACu11tFKqtcGoz7q@mail.gmail.com>
	<4C2E528F.2000907@lachy.id.au>
	<4c30855c.d908e30a.4784.ffffa84f@mx.google.com>
	<AANLkTildxSwQdkH3biNWhjEXY2SBGWbPubLCqfazxv4R@mail.gmail.com>
	<4C3180FD.4010800@peda.net>
	<AANLkTimeOZ9-b25tjpFryQParqvTH9UpGI4DArWx5Qwq@mail.gmail.com>
	<DA8E9E8B-814A-44EF-AEDA-83ED75AA8E7B@iki.fi>
	<AANLkTil8nprqDEtayJMdB0q0-847pDtaSKT70f2XJTvu@mail.gmail.com>
	<op.vffdrrgzatwj1d@philip-pc.gothenburg.osa>
	<AANLkTini3AdVUQm8cV___L6tKEfxe8sPD-ZunyNeV_cK@mail.gmail.com>
Message-ID: <op.vfffeanzatwj1d@philip-pc.gothenburg.osa>

On Tue, 06 Jul 2010 16:33:47 +0200, Marques Johansson  
<marques at displague.com> wrote:

> On Tue, Jul 6, 2010 at 10:12 AM, Philip J?genstedt  
> <philipj at opera.com>wrote:
>
>> On Tue, 06 Jul 2010 15:19:35 +0200, Marques Johansson <
>> marques at displague.com> wrote:
>>
>> Is preload="none" not enough? I can't imagine the actual bandwidth  
>> savings
>> of more fine-grained control to be significant, probably any attempt by  
>> the
>> browser to stop buffering after some time is good enough.
>
>
> I have been using preload="metadata" in my testing.  If the browser  
> fetches
> the metadata then they should be able to seek through the video more  
> easily
> and should have all the information they need to make partial requests  
> with
> upper bounds.  Again - I have no HTML or HTTP way to suggest the UA only
> take X many bytes for now and come back later for more.

Opera hasn't implemented support for the preload attribute yet, I'm not  
sure what the status of other browsers are. I suspect that once all  
browsers have more conservative bandwidth management, the problem will be  
solved.

> Since I see you are with Opera - I noticed that Opera will play ogg  
> files in
> a different way than webm files.  The ogg handler will handle short 206
> responses by making requests for the next range (client requests 0-10,
> server responds with a 206 status, bytes 0-5, client plays then fetches
> bytes 6-10).  The webm handler will only play the range that was sent in  
> the
> initial 206 (client requests 0-10, server responds with a 206 status,  
> bytes
> 0-5, client stops playing).

The demuxers and decoders are several layers away from the actual HTTP  
requests and responses, so I think the problem could be reproduced with  
either Ogg or WebM depending on chance.

Opera doesn't handle the case where the server returns the wrong amount of  
data very well. Fortunately, I've seen no live servers doing this yet.

> I also noticed that Opera will ignore no-cache headers on video content  
> so a
> 206 fragment marked as no-cache can be rewinded and replayed without  
> making
> additional requests.  Chrome refetches the data.  Looking at this as a  
> pure
> HTTP matter I believe Chrome is taking the correct action.

Thanks, I've noted this in our bug tracking system.

-- 
Philip J?genstedt
Core Developer
Opera Software

From philipj at opera.com  Tue Jul  6 07:59:04 2010
From: philipj at opera.com (=?iso-8859-15?Q?Philip_J=E4genstedt?=)
Date: Tue, 06 Jul 2010 16:59:04 +0200
Subject: [whatwg] More YouTube response
In-Reply-To: <AANLkTilRA7CT2YvUv6Jz7J1WgNA_k5N1lqPZ2YB82ks3@mail.gmail.com>
References: <AANLkTinbe-p-STmyfGAiGA6NR7cZO-nzqlq405O5gGTd@mail.gmail.com>
	<20100705174502.763d384f@desudesudesu>
	<AANLkTilOOfaTJetwoSJWSacAPmSfrFuOSx7CNysX6tBW@mail.gmail.com>
	<AANLkTilRA7CT2YvUv6Jz7J1WgNA_k5N1lqPZ2YB82ks3@mail.gmail.com>
Message-ID: <op.vfffwqjkatwj1d@philip-pc.gothenburg.osa>

On Tue, 06 Jul 2010 16:24:45 +0200, Marques Johansson  
<marques at displague.com> wrote:

> On Mon, Jul 5, 2010 at 4:26 PM, Aryeh Gregor
> <Simetrical+w3c at gmail.com<Simetrical%2Bw3c at gmail.com>
>> wrote:
>
>> On Mon, Jul 5, 2010 at 4:10 PM, Marques Johansson  
>> <marques at displague.com>
>> wrote:
>> > For my purposes I am interested in application-controlled video  
>> delivery.
>>  I
>> > want to be able to deliver unprotected mp4, webm, or ogv content in a
>> > metered way.  If the user has payed to watch the entire video once and
>> has
>> > managed to work around HTTP no-cache and the other constraints that a
>> normal
>> > browser viewed experience would have, then they will have succeeding  
>> in
>> > downloading a copy of the video - a task which they could have
>> accomplished
>> > with a VM session or through other means regardless of DRM.
>>
>> There's no way to stop this at the markup level, since the user could
>> just configure a user-agent to ignore the attributes, or manually
>> remove them with a tool like Firebug.  More to the point, since this
>> feature doesn't provide significant benefit to many users or authors,
>> no user agent would bother implementing it in the first place.
>>
>> You should instead look into to writing server-side scripts that meet
>> your needs.  When the user requests a video, have the script check how
>> much video the user is authorized to view, and just truncate it after
>> that point.  Or have it insert an extra clip at the end of what
>> they're allowed to view saying "you have to pay more to keep viewing",
>> then truncate it.  Or whatever.  This is pretty easy to do, and not
>> possible for the user to circumvent.
>
>
> If the UA didn't follow the prescribed size constraints they would get a  
> 403
> response (or a better 4xx range too large if it existed).
>
> The benefit to the user is that they could have less open network
> connections while streaming video from server controlled sites and those
> sites will have the ability to meter their usage more accurately.
>
> Inserting an extra clip at the end is more of a playlist or scripting
> answer.  Or perhaps a a live re-encoding answer.   I'm looking for a way  
> to
> give the user the raw video file in a metered way.  A 200 response or
> partial 206 responses that returns less than the full requested range is  
> not
> handled by browsers in a consistent or usable way (for this purpose).   
> Only
> Chrome will continue to fetch where the previous short 206 response left  
> off
> (request 1-10, server replies 1-5, request 6-10, server replies 6-10).   
> The
> HTTP spec isn't clear about whether UAs should take this behavior - and  
> so
> they don't.
>
> Some UAs request video without sending "Range: bytes 0-".  The server  
> has no
> way to negotiate that the UA (a) must use ranges to complete the request  
> or
> that (b) the range requested is too large, retry will a smaller range.

The first request is tricky for the browser too. Having no idea of how big  
the resource is or what the bitrate is, there is no bounded request that  
makes sense, in my opinion. The downside is that for a conservative  
approach, the only solution is to abort the connection half way through,  
with the server having no idea when this will happen. I haven't seen any  
negative effects of this in practice yet, but this thread has me thinking  
that it could be better. Handling a short reply gracefully would be a good  
start.

>> These requests can be seen as generally allowing servers to reduce load
>> for
>> > video or large file downloads.  Since a client may be able to  
>> download 5
>> > minutes of video in under a minute I would like to see the client
>> disconnect
>> > from the server and reconnect in 5 minutes to get the additional  
>> content.
>>  I
>> > would like to see the server have the ability to enforce this (through
>> HTTP
>> > errors) or at least suggest it (through HTML5 attributes or additional
>> HTTP
>> > headers).
>>
>> Well-written clients should already buffer only as much as they need
>> to ensure the video will play smoothly.  The preload="" attribute is
>> already provided to allow authors to control this behavior.  When the
>> client has read enough for now, it will just stop reading new content
>> from the server until it needs more.  If the server thinks that the
>> client is reading too fast, on the other hand, it can just send fewer
>> packets.  Again, I don't think anything needs to be changed in HTML
>> here.
>>
>
> All of the current video clients make requests like "Range: 0-" or (when  
> you
> seek) "Range: 0-end_of_file".  I don't want to give them the whole 2gb  
> file
> right now, they may seek to the end of the video at any moment while the
> server is paying to send that data and the transfer will have been  
> wasted.
>  I don't want to throttle the connection because that is also a waste of
> resources.  I want the UA to request X many bytes (which equates to some
> fragment of time), disconnect if they will be busy beyond the keep-alive
> time, and come back when they need more video data.  A 200 response and  
> an
> unbounded 206 response do not permit this.
>
> If the <video> tag included a minbuffer and a maxbuffer (at least the
> latter) then the client would always have an upper bound on video ranges
> requested.  If the UA failed to include this the server can give them a  
> 403,
> 416, or some 4xx that does not yet exist.

Let's wait until preload="" is actually implemented to see if more  
fine-grained control is actually needed.

-- 
Philip J?genstedt
Core Developer
Opera Software

From marques at displague.com  Tue Jul  6 08:42:22 2010
From: marques at displague.com (Marques Johansson)
Date: Tue, 6 Jul 2010 11:42:22 -0400
Subject: [whatwg] More YouTube response
In-Reply-To: <op.vfffwqjkatwj1d@philip-pc.gothenburg.osa>
References: <AANLkTinbe-p-STmyfGAiGA6NR7cZO-nzqlq405O5gGTd@mail.gmail.com> 
	<20100705174502.763d384f@desudesudesu>
	<AANLkTilOOfaTJetwoSJWSacAPmSfrFuOSx7CNysX6tBW@mail.gmail.com> 
	<AANLkTilRA7CT2YvUv6Jz7J1WgNA_k5N1lqPZ2YB82ks3@mail.gmail.com> 
	<op.vfffwqjkatwj1d@philip-pc.gothenburg.osa>
Message-ID: <AANLkTinE3ruLIKVeVaqkufZ1RRnC1Zmzd52H1bu82EqL@mail.gmail.com>

On Tue, Jul 6, 2010 at 10:59 AM, Philip J?genstedt <philipj at opera.com>wrote:

> On Tue, 06 Jul 2010 16:24:45 +0200, Marques Johansson <
> marques at displague.com> wrote:
> Some UAs request video without sending "Range: bytes 0-".  The server has
> no
>
>> way to negotiate that the UA (a) must use ranges to complete the request
>> or
>> that (b) the range requested is too large, retry will a smaller range.
>>
>
> The first request is tricky for the browser too. Having no idea of how big
> the resource is or what the bitrate is, there is no bounded request that
> makes sense, in my opinion. The downside is that for a conservative
> approach, the only solution is to abort the connection half way through,
> with the server having no idea when this will happen. I haven't seen any
> negative effects of this in practice yet, but this thread has me thinking
> that it could be better. Handling a short reply gracefully would be a good
> start.


For webm files, Chrome requests 0-1024 and then some block near the end of
the file.  I assume that the meta data / time ranges are stored at these
locations.

As for bounded requests that make sense - I'm sure the server hosting the
content could suggest something ;-)

I've tried having the server disconnect a HTTP/1.1 200 response by doing a
php exit() before having sent the "Content-Length" specified number of
bytes.  Browsers did not attempt to pick up where the server left off.

I think you are suggesting that the client disconnect but without scripting
I don't really have control over that and if with scripting that doesn't
seem doable unless the video element could be feed with an appendBytes()
type of function.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100706/d1f7eb4e/attachment.htm>

From jsalsman at talknicer.com  Tue Jul  6 09:00:07 2010
From: jsalsman at talknicer.com (James Salsman)
Date: Tue, 6 Jul 2010 09:00:07 -0700
Subject: [whatwg] HTML Device element status
In-Reply-To: <op.vfe8gmr864w2qv@annevk-t60>
References: <AANLkTinneBICtsqtwL3KNPb4hfQbAvmFmkgIt-K7VAoF@mail.gmail.com>
	<op.vfe8gmr864w2qv@annevk-t60>
Message-ID: <AANLkTin6Qzo5R7PiRHyV8T-cN3r4vx4BMac8KIbSLL7m@mail.gmail.com>

On Tue, Jul 6, 2010 at 5:18 AM, Anne van Kesteren <annevk at opera.com> wrote:
>
> There are some advantages with <input>, but overall the design is ugly.

<input type=file> is buffered, which would seem to exclude the
possibility of onchange=form.submit() in any of its forms' elements,
but is otherwise parsimonious, while <device> is its unbuffered
counterpart.  Why is one method of transmission any more or less ugly
than the other?  Buffering can substantially reduce bandwidth.

Is there any reason not to protect both them with the same privacy and
security authorization dialogs, and render them mostly the same,
except for audio/* and video/* <input> you might have
record/pause/play/submit while <device> would have record/pause?  For
image/* the differences are less clear to me: perhaps <input> would
have a viewfinder, (expandable on mobiles) shutter button, a
filesystem browser button, and an (optional?) submit button, but an
image/* <device> might only have a viewfinder and a shutter button.
For the case of a camera, it would seem to me that the buffered
approach is also superior, but the unbuffered <device> approach would
allow audio and video teleconferencing.

Also, someone said it would be a good idea to mute audio input and
output from any hidden tab.  I think this may be a reasonable user
option (people who listen to podcasts might not like it), and wonder
if microphone or other audio input should be muted from any window and
tab without top-most focus and exposure.  Does anyone have thoughts on
that question?

From svartman95 at gmail.com  Tue Jul  6 11:36:32 2010
From: svartman95 at gmail.com (Bjartur Thorlacius)
Date: Tue, 06 Jul 2010 18:36:32 +0000
Subject: [whatwg] HTML Device element status
In-Reply-To: <AANLkTin6Qzo5R7PiRHyV8T-cN3r4vx4BMac8KIbSLL7m@mail.gmail.com>
References: <AANLkTinneBICtsqtwL3KNPb4hfQbAvmFmkgIt-K7VAoF@mail.gmail.com>
	<op.vfe8gmr864w2qv@annevk-t60>
	<AANLkTin6Qzo5R7PiRHyV8T-cN3r4vx4BMac8KIbSLL7m@mail.gmail.com>
Message-ID: <4c3377b7.1207df0a.098e.ffff8f5c@mx.google.com>

--------
James Salsman <jsalsman at talknicer.com> wrote:
> > [...]
> <input type=file> is buffered, which would seem to exclude the
> possibility of onchange=form.submit() in any of its forms' elements,
> but is otherwise parsimonious, while <device> is its unbuffered
> counterpart. [...]
> 
What about <form autosubmit> to request data to be automagically sent as soon as data is input and thus eliminate the buffering problem?
> Is there any reason not to protect both them with the same privacy and
> security authorization dialogs, and render them mostly the same,
> except for audio/* and video/* <input> you might have
> record/pause/play/submit while <device> would have record/pause?  For
> image/* the differences are less clear to me: perhaps <input> would
> have a viewfinder, (expandable on mobiles) shutter button, a
> filesystem browser button, and an (optional?) submit button, but an
> image/* <device> might only have a viewfinder and a shutter button.
> For the case of a camera, it would seem to me that the buffered
> approach is also superior, but the unbuffered <device> approach would
> allow audio and video teleconferencing.
If <device> is basically unbuffered <input> why was sharing email
addresses provided as a use case for <device>? And unbuffered FS access
as an stream-friendly alternative to <input>? WTF? FS access doesn't seem
practically useful sans JavaScript, and JavaScript has it's own interfaces
to things such as filesystems. Putting a placeholder for a JavaScript
interface for a filesystem in a web page doesn't make sense to me.

But for the use case you present, the only info that needs to be
present in the form is what protocol to use (implicit), whether to use
PUT or POST (covered in @method of <form>), the URI (@action of <form>)
accepted MIME types and potentially accepted MIME subtypes (both covered
by @accept). There are two problem with just using <form> and <input>
here: <form> implementations don't support simply uploading a single
unwrapped file and there isn't any way to request "bufferless submits"
that would autosubmit as soon as some minimal amount of data has been
gathered (such as @stream/@autosubmit of <form>).

> Also, someone said it would be a good idea to mute audio input and
> output from any hidden tab.  I think this may be a reasonable user
> option (people who listen to podcasts might not like it), and wonder
> if microphone or other audio input should be muted from any window and
> tab without top-most focus and exposure.  Does anyone have thoughts on
> that question?
I don't think muting other top-level browsing contexts should be made
an requirement. Browsers may of course ask for workstation/terminal wide
mute while recording for user convenience.

From Simetrical+w3c at gmail.com  Tue Jul  6 13:17:05 2010
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Tue, 6 Jul 2010 16:17:05 -0400
Subject: [whatwg] Iframe dimensions
In-Reply-To: <4C330A54.5030906@gmx.ch>
References: <4C3212B2.6010006@gmx.ch>
	<AANLkTim38_gSl9lpUVzG1TFUi5wDrLeG1nA-ILYl3lr5@mail.gmail.com>
	<4C32EC12.4020504@gmx.ch>
	<AANLkTilQ3P6hhwrpr14n___yrUD-j0wEHQ4h7yYNElOS@mail.gmail.com>
	<4C330A54.5030906@gmx.ch>
Message-ID: <AANLkTik1-jW1lLYfpy0fMt-ZH0FMQClx7f4NNnbJ36qG@mail.gmail.com>

On Tue, Jul 6, 2010 at 6:49 AM, Markus Ernst <derernst at gmx.ch> wrote:
> My problem is this sentence in the spec for seamless: "This will cause links
> to open in the parent browsing context."
>
> In an application like http://test.rapid.ch/de/haendler-schweiz/iseki.html,
> the external page should be able to re-call itself inside the iframe, for
> example if a sort link is clicked or a search form submitted.

Oh.  Hmm.  That does seem to pose a problem.  I can't think of any
good solutions off the top of my head.

From Simetrical+w3c at gmail.com  Tue Jul  6 13:37:09 2010
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Tue, 6 Jul 2010 16:37:09 -0400
Subject: [whatwg] More YouTube response
In-Reply-To: <AANLkTilRA7CT2YvUv6Jz7J1WgNA_k5N1lqPZ2YB82ks3@mail.gmail.com>
References: <AANLkTinbe-p-STmyfGAiGA6NR7cZO-nzqlq405O5gGTd@mail.gmail.com>
	<20100705174502.763d384f@desudesudesu>
	<AANLkTilOOfaTJetwoSJWSacAPmSfrFuOSx7CNysX6tBW@mail.gmail.com>
	<AANLkTilRA7CT2YvUv6Jz7J1WgNA_k5N1lqPZ2YB82ks3@mail.gmail.com>
Message-ID: <AANLkTimriXnIcz81mzUSRDQEpdgC_LXVt9fbLLLEnyp7@mail.gmail.com>

On Tue, Jul 6, 2010 at 10:24 AM, Marques Johansson
<marques at displague.com> wrote:
> The benefit to the user is that they could have less open network
> connections while streaming video from server controlled sites and those
> sites will have the ability to meter their usage more accurately.
> Inserting an extra clip at the end is more of a playlist or scripting
> answer. ?Or perhaps a a live re-encoding answer. ? I'm looking for a way to
> give the user the raw video file in a metered way.

It sounds like your use-case is very special, and best handled by
script.  I suggested server-side script -- you could do that today.
Just cut off the HTTP connection when the user has used up their
allotted time.  Alternatively, it might be reasonable to have
client-side scripting for video that's flexible enough to do what you
want.  But a dedicated declarative feature is just not reasonable for
such a specific purpose.

>?A 200 response or
> partial 206 responses that returns less than the full requested range is not
> handled by browsers in a consistent or usable way (for this purpose). ?Only
> Chrome will continue to fetch where the previous short 206 response left off
> (request 1-10, server replies 1-5, request 6-10, server replies 6-10). ?The
> HTTP spec isn't clear about whether UAs should take this behavior - and so
> they don't.
> Some UAs request video without sending "Range: bytes 0-". ?The server has no
> way to negotiate that the UA (a) must use ranges to complete the request or
> that (b) the range requested is too large, retry will a smaller range.

You don't need to return less than the browser requests, until it
actually uses up the bandwidth the user has paid for.  Let the browser
fetch as much of the video as the user wants to view, using
preload=metadata when that's supported by all browsers.  Every time
the server sends a new chunk of video to the user, it should deduct
that much from the user's current balance.  When the user has received
as much video as he's paid for, just have the script exit without
sending more output.

You don't have to return a proper Range header and expect the browser
to issue new requests.  Just pretend you're serving the whole
resource, then cut it off unexpectedly before you've actually returned
all the content.  The browser will handle this fine, it will just
treat it as a network error.  A client-side script can then detect the
error and present nice UI.

> All of the current video clients make requests like "Range: 0-" or (when you
> seek) "Range: 0-end_of_file". ?I don't want to give them the whole 2gb file
> right now, they may seek to the end of the video at any moment while the
> server is paying to send that data and the transfer will have been wasted.
> ?I don't want to throttle the connection because that is also a waste of
> resources. ?I want the UA to request X many bytes (which equates to some
> fragment of time), disconnect if they will be busy beyond the keep-alive
> time, and come back when they need more video data. ?A 200 response and an
> unbounded 206 response do not permit this.

This part is handled by the preload attribute already.  You just have
to wait for browsers to actually support it.

From ash at ashleysheridan.co.uk  Tue Jul  6 13:41:40 2010
From: ash at ashleysheridan.co.uk (Ashley Sheridan)
Date: Tue, 06 Jul 2010 21:41:40 +0100
Subject: [whatwg] Iframe dimensions
In-Reply-To: <AANLkTik1-jW1lLYfpy0fMt-ZH0FMQClx7f4NNnbJ36qG@mail.gmail.com>
References: <4C3212B2.6010006@gmx.ch>
	<AANLkTim38_gSl9lpUVzG1TFUi5wDrLeG1nA-ILYl3lr5@mail.gmail.com>
	<4C32EC12.4020504@gmx.ch>
	<AANLkTilQ3P6hhwrpr14n___yrUD-j0wEHQ4h7yYNElOS@mail.gmail.com>
	<4C330A54.5030906@gmx.ch>
	<AANLkTik1-jW1lLYfpy0fMt-ZH0FMQClx7f4NNnbJ36qG@mail.gmail.com>
Message-ID: <1278448900.2263.1.camel@localhost>

On Tue, 2010-07-06 at 16:17 -0400, Aryeh Gregor wrote:

> On Tue, Jul 6, 2010 at 6:49 AM, Markus Ernst <derernst at gmx.ch> wrote:
> > My problem is this sentence in the spec for seamless: "This will cause links
> > to open in the parent browsing context."
> >
> > In an application like http://test.rapid.ch/de/haendler-schweiz/iseki.html,
> > the external page should be able to re-call itself inside the iframe, for
> > example if a sort link is clicked or a search form submitted.
> 
> Oh.  Hmm.  That does seem to pose a problem.  I can't think of any
> good solutions off the top of my head.


Could you explicitly call the _self target in links in the frame? I
wasn't sure if the target attribute was going or not, but I'd expect
target="_self" to override the default seamless action.

Thanks,
Ash
http://www.ashleysheridan.co.uk


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100706/74d1d280/attachment.htm>

From marques at displague.com  Tue Jul  6 14:19:42 2010
From: marques at displague.com (Marques Johansson)
Date: Tue, 6 Jul 2010 17:19:42 -0400
Subject: [whatwg] More YouTube response
In-Reply-To: <AANLkTimriXnIcz81mzUSRDQEpdgC_LXVt9fbLLLEnyp7@mail.gmail.com>
References: <AANLkTinbe-p-STmyfGAiGA6NR7cZO-nzqlq405O5gGTd@mail.gmail.com> 
	<20100705174502.763d384f@desudesudesu>
	<AANLkTilOOfaTJetwoSJWSacAPmSfrFuOSx7CNysX6tBW@mail.gmail.com> 
	<AANLkTilRA7CT2YvUv6Jz7J1WgNA_k5N1lqPZ2YB82ks3@mail.gmail.com> 
	<AANLkTimriXnIcz81mzUSRDQEpdgC_LXVt9fbLLLEnyp7@mail.gmail.com>
Message-ID: <AANLkTilL36oil_Kw4nuhs8JIU1qG-5LRItCSsLPf9VnS@mail.gmail.com>

On Tue, Jul 6, 2010 at 4:37 PM, Aryeh Gregor
<Simetrical+w3c at gmail.com<Simetrical%2Bw3c at gmail.com>
> wrote:

> On Tue, Jul 6, 2010 at 10:24 AM, Marques Johansson
> <marques at displague.com> wrote:
> > The benefit to the user is that they could have less open network
> > connections while streaming video from server controlled sites and those
> > sites will have the ability to meter their usage more accurately.
> > Inserting an extra clip at the end is more of a playlist or scripting
> > answer.  Or perhaps a a live re-encoding answer.   I'm looking for a way
> to
> > give the user the raw video file in a metered way.
>
> It sounds like your use-case is very special, and best handled by
> script.  I suggested server-side script -- you could do that today.
> Just cut off the HTTP connection when the user has used up their
> allotted time.  Alternatively, it might be reasonable to have
> client-side scripting for video that's flexible enough to do what you
> want.  But a dedicated declarative feature is just not reasonable for
> such a specific purpose.


I tested cutting off the HTTP connection and browsers didn't handle this.  I
realize I may need to test a deeper sever than a php exit() can provide.  I
have essentially tested this (but not this exactly - filehandles, sessions,
additional code, etc):
<?php
header("HTTP/1.1 206 partial");
header("Accept-Ranges: bytes");
header("Content-Range: bytes 0-999999/1000000");
header("Content-Length: 1000000");  // report 1000k
echo str_repeat(" ", 1000); // return 1k
exit();

and found that browsers do not attempt to refetch the data or continue with
a 206 for the next block.

Shouldn't something like this be be worked into the protocol or the language
instead of having to break the stream at a higher level?

Consider the existing 4xx errors.   The server can tell the client that the
request data was too large (1k? - 413/414) or that a "content-length" is
required (411) but not that the range length is required or too large
(1gb?).

> A 200 response or
> > partial 206 responses that returns less than the full requested range is
> not
> > handled by browsers in a consistent or usable way (for this purpose).
>  Only
> > Chrome will continue to fetch where the previous short 206 response left
> off
> > (request 1-10, server replies 1-5, request 6-10, server replies 6-10).
>  The
> > HTTP spec isn't clear about whether UAs should take this behavior - and
> so
> > they don't.
> > Some UAs request video without sending "Range: bytes 0-".  The server has
> no
> > way to negotiate that the UA (a) must use ranges to complete the request
> or
> > that (b) the range requested is too large, retry will a smaller range.
>
> You don't need to return less than the browser requests, until it
> actually uses up the bandwidth the user has paid for.  Let the browser
> fetch as much of the video as the user wants to view, using
> preload=metadata when that's supported by all browsers.  Every time
> the server sends a new chunk of video to the user, it should deduct
> that much from the user's current balance.  When the user has received
> as much video as he's paid for, just have the script exit without
> sending more output.
>

prefetch="metadata" is the plan - but how far forward will the browser
attempt to buffer? When will the browser stop buffering and start playing? I
think the server/service/html/http side of things should have some say.  I
wouldn't want to see browser X seek 10 seconds ahead while browser Y fetches
60 seconds in advance.

I think buffer="" is a reasonable attribute.  buffer="" being akin to
minbuffer="" I feel that a maxbuffer="" is also reasonable.  Again - this
would be easier than getting HTTP spec changes made.

You don't have to return a proper Range header and expect the browser
> to issue new requests.  Just pretend you're serving the whole
> resource, then cut it off unexpectedly before you've actually returned
> all the content.  The browser will handle this fine, it will just
> treat it as a network error.  A client-side script can then detect the
> error and present nice UI.


As I stated before - this didn't pan out for me - I will happily test other
methods.

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100706/0a8b3ff3/attachment.htm>

From marques at displague.com  Tue Jul  6 14:45:51 2010
From: marques at displague.com (Marques Johansson)
Date: Tue, 6 Jul 2010 17:45:51 -0400
Subject: [whatwg] media resources: addressing media fragments through
	URIs spec
In-Reply-To: <AANLkTilAqisq4_U-5IMLrenaezWAFft3Ya22uYYf7Wia@mail.gmail.com>
References: <AANLkTilAqisq4_U-5IMLrenaezWAFft3Ya22uYYf7Wia@mail.gmail.com>
Message-ID: <AANLkTimhqOvnGIutt_qgUIybUqh_3wGCDewlUgcepqsC@mail.gmail.com>

On Wed, Jun 30, 2010 at 8:11 AM, Silvia Pfeiffer
<silviapfeiffer1 at gmail.com>wrote:

> Hi all,
>
> The W3C WG for media fragments has published a Last Call Working Draft
> at http://www.w3.org/TR/media-frags/ .
>
> The idea of the spec is to enable addressing sub-parts of audio-visual
> resources through URIs, such as http://example.com/video.ogv?t=10,40
> to address seconds 10-40 out of video.ogv. This is relevant for use in
> the <audio> and <video> elements and can help focus the playback to a
> specific subpart.
>


When dealing with timed content - shouldn't there be a relative URI meaning
from the current time to the designated time.  I'm thinking of something
like:
http://example.com/video.ogv#t=,40
Which would be used to continue a piece a playing media up to the 40 second
point and then stop.

This could prevent a fetch by the UA to the start of the media fragment
which could be especially useful if the media is marked as no-cache.

I'm thinking an article could outline links on a page each of which would
cause a related video to continue playing up to the point specified in the
link and then stop - giving the reader a chance to catch up.

This also brings up the matter of link targets.  Shouldn't I be able to do
something like this:

<video name="presentation"></video>
<a href="#,50" target="presentation">Next Slide</a>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100706/e511cdf6/attachment-0001.htm>

From nzakas at yahoo-inc.com  Tue Jul  6 16:54:24 2010
From: nzakas at yahoo-inc.com (Nicholas Zakas)
Date: Tue, 6 Jul 2010 16:54:24 -0700
Subject: [whatwg] Clarification request for
	charset/characterSet/defaultCharset
Message-ID: <4E45EC6AD219FD47AD1BC06E4EE3845D052F29F7@SNV-EXVS09.ds.corp.yahoo.com>

Hi all,

 

I was just reading through the spec and am having trouble understanding
the details of document.charset, document.characterSet, and
document.defaultCharset. It seems to me that document.characterSet is
simply a read-only equivalent of document.charset (I'm guessing these
are both here due to already-existing implementations), which is a
little confusing but not terribly so. I'm more interested in
document.defaultCharset and how it relates to the others. Some
questions:

 

1) Should document.charset/document.characterSet always start out
equivalent to document.defaultCharset?

2) What is the canonical source of truth for document.defaultCharset (is
this a system setting, a browser setting, or a document setting)?

3) If document.charset is set to a new value, is there any change
reflected in document.defaultCharset? What about vice-versa?

 

Thanks.

 

-Nicholas

 

______________________________________________

Commander Lock: "Dammit Morpheus, not everyone believes what you
believe!"

Morpheus: "My beliefs do not require them to."

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100706/959cfa2b/attachment.htm>

From silviapfeiffer1 at gmail.com  Tue Jul  6 16:57:42 2010
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Tue, 6 Jul 2010 16:57:42 -0700
Subject: [whatwg] media resources: addressing media fragments through
	URIs spec
In-Reply-To: <AANLkTimhqOvnGIutt_qgUIybUqh_3wGCDewlUgcepqsC@mail.gmail.com>
References: <AANLkTilAqisq4_U-5IMLrenaezWAFft3Ya22uYYf7Wia@mail.gmail.com> 
	<AANLkTimhqOvnGIutt_qgUIybUqh_3wGCDewlUgcepqsC@mail.gmail.com>
Message-ID: <AANLkTin-8ZUToNgHyBQBFWi16U21vjVEUDSkG-B0winz@mail.gmail.com>

On Tue, Jul 6, 2010 at 2:45 PM, Marques Johansson <marques at displague.com> wrote:
> On Wed, Jun 30, 2010 at 8:11 AM, Silvia Pfeiffer <silviapfeiffer1 at gmail.com>
> wrote:
>>
>> Hi all,
>>
>> The W3C WG for media fragments has published a Last Call Working Draft
>> at http://www.w3.org/TR/media-frags/ .
>>
>> The idea of the spec is to enable addressing sub-parts of audio-visual
>> resources through URIs, such as http://example.com/video.ogv?t=10,40
>> to address seconds 10-40 out of video.ogv. This is relevant for use in
>> the <audio> and <video> elements and can help focus the playback to a
>> specific subpart.
>
>
> When dealing with timed content - shouldn't there be a relative URI meaning
> from the current time to the designated time. ?I'm thinking of something
> like:
> http://example.com/video.ogv#t=,40
> Which would be used to continue a piece a playing media up to the 40 second
> point and then stop.
> This could prevent a fetch by the UA to the start of the media fragment
> which could be especially useful if the media is marked as no-cache.
> I'm thinking an article could outline links on a page each of which would
> cause a related video to continue playing up to the point specified in the
> link and then stop - giving the reader a chance to catch up.
> This also brings up the matter of link targets. ?Shouldn't I be able to do
> something like this:
> <video name="presentation"></video>
> <a href="#,50" target="presentation">Next Slide</a>
>

Wouldn't they all have a start time, too? E.g. the start time of a
slide to the end time of the slide?

When you write a Web page, there is no such thing as "now" on the page
- all you can reasonably assume when loading a media resource is to
start at 0, so I cannot see your links work in the way that you're
asking for. You can of course always do what you want with JavaScript
though.

Cheers,
Silvia.

From hsivonen at iki.fi  Tue Jul  6 22:34:42 2010
From: hsivonen at iki.fi (Henri Sivonen)
Date: Tue, 6 Jul 2010 22:34:42 -0700
Subject: [whatwg] More YouTube response
In-Reply-To: <AANLkTil8nprqDEtayJMdB0q0-847pDtaSKT70f2XJTvu@mail.gmail.com>
References: <1267897846.990.1278063443760.JavaMail.root@cm-mail03.mozilla.org>
	<1278065580.10898.7.camel@shane-laptop>
	<op.ve7rxmh064w2qv@annevk-t60> <4C2DD3F7.6020201@gmx.de>
	<4C2DE0AA.5060009@lachy.id.au>
	<AANLkTil-ZHzINNZp4nfl7OHsVtHyACu11tFKqtcGoz7q@mail.gmail.com>
	<4C2E528F.2000907@lachy.id.au>
	<4c30855c.d908e30a.4784.ffffa84f@mx.google.com>
	<AANLkTildxSwQdkH3biNWhjEXY2SBGWbPubLCqfazxv4R@mail.gmail.com>
	<4C3180FD.4010800@peda.net>
	<AANLkTimeOZ9-b25tjpFryQParqvTH9UpGI4DArWx5Qwq@mail.gmail.com>
	<DA8E9E8B-814A-44EF-AEDA-83ED75AA8E7B@iki.fi>
	<AANLkTil8nprqDEtayJMdB0q0-847pDtaSKT70f2XJTvu@mail.gmail.com>
Message-ID: <013D4E19-9A38-471D-93A5-ED5C2BF4EF45@iki.fi>

On Jul 6, 2010, at 06:19, Marques Johansson wrote:
> That being said, I don't think the business models of one of the largest online video markets should put be on trial through a by a standards list.

Well, if you are suggesting that your use case needs to be addressed by introducing browser-side features, putting the use case on trial is a routine part of how specs are developed at the WHATWG.

In particular, it's worthwhile to examine if the use case or a close approximation thereof could be addressed without adding features to the browser side.

One crude approximation would be breaking the video title into chunks similar to the chunks between commercials on TV such that each chunk would be a video file and a JS-based UI would continue from one chunk to the next. This way, billing could be per chunk. (But see below for an even better way.)

>  Partial requests are native to HTTP and seeking is natural for a healthy streamed viewing habit - I'm look for a way to get the browser to take the servers recommendation that the content be fetched in a particular way - we have content negotiation of transfer encoding and image quality, why not allow the server to negotiate the transfer size for the benefit of the user and the server?

I think it's not particularly natural to put bandwidth rate control on the browser side or on/above the HTTP layer. 

I think it's more natural to control bandwidth on the TCP level, and, of the two sides of TCP, the server is the one that you can trust to do it per your parameters. The server could write data into the TCP stream only a little ahead of the playback time. This way, you could assume that the video has been played to the precision of how much data you send ahead of the playback position. To know the playback position, you could have a JS-based video player send the current playback position to the server periodically using XHR or a Web Socket connection. Whenever you receive a playback position heartbeat, you'd flush a bit more data into the video file's TCP stream and account it as viewed.

Downsides: Two TCP connections instead of one, but having two data channels isn't so different from RTSP/RTP.
Upsides: No additional browser features required. No need to trust the browser to do bandwidth rate control according to your parameters, since you decide how often to send the heartbeat and how much data to send per heartbeat. Avoidance of the header overhead of multiple HTTP requests (in the Web Socket case--not in the XHR case).

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/



From philipj at opera.com  Wed Jul  7 01:36:21 2010
From: philipj at opera.com (=?iso-8859-15?Q?Philip_J=E4genstedt?=)
Date: Wed, 07 Jul 2010 10:36:21 +0200
Subject: [whatwg] More YouTube response
In-Reply-To: <AANLkTilL36oil_Kw4nuhs8JIU1qG-5LRItCSsLPf9VnS@mail.gmail.com>
References: <AANLkTinbe-p-STmyfGAiGA6NR7cZO-nzqlq405O5gGTd@mail.gmail.com>
	<20100705174502.763d384f@desudesudesu>
	<AANLkTilOOfaTJetwoSJWSacAPmSfrFuOSx7CNysX6tBW@mail.gmail.com>
	<AANLkTilRA7CT2YvUv6Jz7J1WgNA_k5N1lqPZ2YB82ks3@mail.gmail.com>
	<AANLkTimriXnIcz81mzUSRDQEpdgC_LXVt9fbLLLEnyp7@mail.gmail.com>
	<AANLkTilL36oil_Kw4nuhs8JIU1qG-5LRItCSsLPf9VnS@mail.gmail.com>
Message-ID: <op.vfgsuvc0atwj1d@philip-pc.gothenburg.osa>

On Tue, 06 Jul 2010 23:19:42 +0200, Marques Johansson  
<marques at displague.com> wrote:

> On Tue, Jul 6, 2010 at 4:37 PM, Aryeh Gregor
> <Simetrical+w3c at gmail.com<Simetrical%2Bw3c at gmail.com>
>> wrote:
>
>> On Tue, Jul 6, 2010 at 10:24 AM, Marques Johansson
>> <marques at displague.com> wrote:
>> > The benefit to the user is that they could have less open network
>> > connections while streaming video from server controlled sites and  
>> those
>> > sites will have the ability to meter their usage more accurately.
>> > Inserting an extra clip at the end is more of a playlist or scripting
>> > answer.  Or perhaps a a live re-encoding answer.   I'm looking for a  
>> way
>> to
>> > give the user the raw video file in a metered way.
>>
>> It sounds like your use-case is very special, and best handled by
>> script.  I suggested server-side script -- you could do that today.
>> Just cut off the HTTP connection when the user has used up their
>> allotted time.  Alternatively, it might be reasonable to have
>> client-side scripting for video that's flexible enough to do what you
>> want.  But a dedicated declarative feature is just not reasonable for
>> such a specific purpose.
>
>
> I tested cutting off the HTTP connection and browsers didn't handle  
> this.  I
> realize I may need to test a deeper sever than a php exit() can  
> provide.  I
> have essentially tested this (but not this exactly - filehandles,  
> sessions,
> additional code, etc):
> <?php
> header("HTTP/1.1 206 partial");
> header("Accept-Ranges: bytes");
> header("Content-Range: bytes 0-999999/1000000");
> header("Content-Length: 1000000");  // report 1000k
> echo str_repeat(" ", 1000); // return 1k
> exit();
>
> and found that browsers do not attempt to refetch the data or continue  
> with
> a 206 for the next block.
>
> Shouldn't something like this be be worked into the protocol or the  
> language

One thing that you mustn't lie about is Content-Length, so I assume that  
the real size of this resource if 1000k. If you're trying to return a too  
short range, you should say so in the Content-Range header. In other  
words, in the above you should have used

header("Content-Range: bytes 0-999/1000000");

I'm not sure it will work anyway, though.

-- 
Philip J?genstedt
Core Developer
Opera Software

From philipj at opera.com  Wed Jul  7 01:49:48 2010
From: philipj at opera.com (=?iso-8859-15?Q?Philip_J=E4genstedt?=)
Date: Wed, 07 Jul 2010 10:49:48 +0200
Subject: [whatwg] More YouTube response
In-Reply-To: <AANLkTinE3ruLIKVeVaqkufZ1RRnC1Zmzd52H1bu82EqL@mail.gmail.com>
References: <AANLkTinbe-p-STmyfGAiGA6NR7cZO-nzqlq405O5gGTd@mail.gmail.com>
	<20100705174502.763d384f@desudesudesu>
	<AANLkTilOOfaTJetwoSJWSacAPmSfrFuOSx7CNysX6tBW@mail.gmail.com>
	<AANLkTilRA7CT2YvUv6Jz7J1WgNA_k5N1lqPZ2YB82ks3@mail.gmail.com>
	<op.vfffwqjkatwj1d@philip-pc.gothenburg.osa>
	<AANLkTinE3ruLIKVeVaqkufZ1RRnC1Zmzd52H1bu82EqL@mail.gmail.com>
Message-ID: <op.vfgthagcatwj1d@philip-pc.gothenburg.osa>

On Tue, 06 Jul 2010 17:42:22 +0200, Marques Johansson  
<marques at displague.com> wrote:

> On Tue, Jul 6, 2010 at 10:59 AM, Philip J?genstedt  
> <philipj at opera.com>wrote:
>
>> On Tue, 06 Jul 2010 16:24:45 +0200, Marques Johansson <
>> marques at displague.com> wrote:
>> Some UAs request video without sending "Range: bytes 0-".  The server  
>> has
>> no
>>
>>> way to negotiate that the UA (a) must use ranges to complete the  
>>> request
>>> or
>>> that (b) the range requested is too large, retry will a smaller range.
>>>
>>
>> The first request is tricky for the browser too. Having no idea of how  
>> big
>> the resource is or what the bitrate is, there is no bounded request that
>> makes sense, in my opinion. The downside is that for a conservative
>> approach, the only solution is to abort the connection half way through,
>> with the server having no idea when this will happen. I haven't seen any
>> negative effects of this in practice yet, but this thread has me  
>> thinking
>> that it could be better. Handling a short reply gracefully would be a  
>> good
>> start.
>
>
> For webm files, Chrome requests 0-1024 and then some block near the end  
> of
> the file.  I assume that the meta data / time ranges are stored at these
> locations.
>
> As for bounded requests that make sense - I'm sure the server hosting the
> content could suggest something ;-)

If the index is stored in the beginning of the file, there should be no  
need to seek to the end. What we want is to get at least metadata and the  
first frame in a single request, and I can't guess any number that doesn't  
risk being larger than the file itself. Somehow involving the server just  
amounts to two network roundtrips, which was exactly what we were trying  
to avoid.

> I've tried having the server disconnect a HTTP/1.1 200 response by doing  
> a
> php exit() before having sent the "Content-Length" specified number of
> bytes.  Browsers did not attempt to pick up where the server left off.
>
> I think you are suggesting that the client disconnect but without  
> scripting
>
> I don't really have control over that and if with scripting that doesn't
> seem doable unless the video element could be feed with an appendBytes()
> type of function.

Yes, the browser disconnects, and scripts have no influence over it. With  
preload="metadata" implemented, it should disconnect as soon as possible  
after getting enough data for the first frame. For preload="auto", it will  
disconnect after buffering X seconds of data. If you need more granularity  
than that, I suggest server-side control informed by information collected  
by JavaScript. If browsers handled a short reply to a range request, it  
should work just fine, no?

-- 
Philip J?genstedt
Core Developer
Opera Software

From schalk at ossreleasefeed.com  Wed Jul  7 03:38:31 2010
From: schalk at ossreleasefeed.com (Schalk Neethling)
Date: Wed, 7 Jul 2010 12:38:31 +0200
Subject: [whatwg] Firefox 4 Beta 1
Message-ID: <006501cb1dc0$8cb96e00$a62c4a00$@com>

Hi there everyone,

 

Downloaded and installed the first beta of Firefox 4. To the folks at
Mozilla that is on here, what an awesome job. Love the new look and it IS
very fast. The reason I mention Firefox 4 is because, on the welcome screen
you get after installing the browser, you have the option to view a video
introduction to Firefox 4, nothing strange here but, first the video format
is WebM, which is awesome, the other thing, and this is the main reason for
this mail, if you right click on the video there is a context menu option
for full screen.

 

Upon clicking that, the video goes into full screen mode and it does this, I
must say, very nicely. I also noted that in full screen right clicking is
disabled. With the discussions around full screen HTML5 video as well as
content protection, it seems Mozilla has made some progress. Am I correct in
saying that they keep running HTML5 video 'mode' when going to full screen
or do they somehow switch to Flash?

 

Would be pretty amazing if they do switch to Flash as the video continues
playing from the same frame and does not start from the beginning.

 

Looking forward to your feedback,

Schalk Neethling

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100707/b762d38b/attachment-0001.htm>

From w3c at adambarth.com  Wed Jul  7 04:22:07 2010
From: w3c at adambarth.com (Adam Barth)
Date: Wed, 7 Jul 2010 04:22:07 -0700
Subject: [whatwg] Firefox 4 Beta 1
In-Reply-To: <006501cb1dc0$8cb96e00$a62c4a00$@com>
References: <006501cb1dc0$8cb96e00$a62c4a00$@com>
Message-ID: <AANLkTimkshCtWjZ7_wz8_LUf-RXwG80K5r54z9ip9H8k@mail.gmail.com>

I'm sure they keep using HTML5 video in full screen.  The issues
around full screen relate to letting the page trigger full screen.
It's fine for the user to trigger it directly.

Adam


On Wed, Jul 7, 2010 at 3:38 AM, Schalk Neethling
<schalk at ossreleasefeed.com> wrote:
> Hi there everyone,
>
>
>
> Downloaded and installed the first beta of Firefox 4. To the folks at
> Mozilla that is on here, what an awesome job. Love the new look and it IS
> very fast. The reason I mention Firefox 4 is because, on the welcome screen
> you get after installing the browser, you have the option to view a video
> introduction to Firefox 4, nothing strange here but, first the video format
> is WebM, which is awesome, the other thing, and this is the main reason for
> this mail, if you right click on the video there is a context menu option
> for full screen.
>
>
>
> Upon clicking that, the video goes into full screen mode and it does this, I
> must say, very nicely. I also noted that in full screen right clicking is
> disabled. With the discussions around full screen HTML5 video as well as
> content protection, it seems Mozilla has made some progress. Am I correct in
> saying that they keep running HTML5 video ?mode? when going to full screen
> or do they somehow switch to Flash?
>
>
>
> Would be pretty amazing if they do switch to Flash as the video continues
> playing from the same frame and does not start from the beginning.
>
>
>
> Looking forward to your feedback,
>
> Schalk Neethling
>
>

From schalk at ossreleasefeed.com  Wed Jul  7 04:44:28 2010
From: schalk at ossreleasefeed.com (Schalk Neethling)
Date: Wed, 7 Jul 2010 13:44:28 +0200
Subject: [whatwg] More YouTube response
In-Reply-To: <op.ve7rxmh064w2qv@annevk-t60>
References: <1267897846.990.1278063443760.JavaMail.root@cm-mail03.mozilla.org>	<1278065580.10898.7.camel@shane-laptop>
	<op.ve7rxmh064w2qv@annevk-t60>
Message-ID: <008b01cb1dc9$c4b80f60$4e282e20$@com>

Could not agree more Anne

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Anne van Kesteren
Sent: Friday, July 02, 2010 1:38 PM
To: Henri Sivonen; Shane Fagan
Cc: Andy Berkheimer; John Harding; whatwg at whatwg.org
Subject: Re: [whatwg] More YouTube response

On Fri, 02 Jul 2010 12:13:00 +0200, Shane Fagan <shanepatrickfagan at ubuntu.com> wrote:
> Well this isnt really a list where we should talk about the dos and 
> donts of web content distribution. DRM content can be embedded in the 
> video tag and decoded using installable plugins so its not really an 
> issue for this list I dont think. We cant dictate how the specs are 
> used so try to keep the conversation technology neutral.

Whether playing video requires a plugin is very much an issue for this list, I think. What Henri explained -- not having lock-in to a particular platform because of proprietary plugins -- is a large part of the reason why we have <video> in the first place.


--
Anne van Kesteren
http://annevankesteren.nl/


From schalk at ossreleasefeed.com  Wed Jul  7 04:43:15 2010
From: schalk at ossreleasefeed.com (Schalk Neethling)
Date: Wed, 7 Jul 2010 13:43:15 +0200
Subject: [whatwg] Firefox 4 Beta 1
In-Reply-To: <AANLkTimkshCtWjZ7_wz8_LUf-RXwG80K5r54z9ip9H8k@mail.gmail.com>
References: <006501cb1dc0$8cb96e00$a62c4a00$@com>
	<AANLkTimkshCtWjZ7_wz8_LUf-RXwG80K5r54z9ip9H8k@mail.gmail.com>
Message-ID: <008a01cb1dc9$98c60f60$ca522e20$@com>

Ah, ok. I see but then I wonder what the problem is with regards to Youtube
and full screen as their full screen mode is fully user driven.

-----Original Message-----
From: Adam Barth [mailto:w3c at adambarth.com] 
Sent: Wednesday, July 07, 2010 1:22 PM
To: Schalk Neethling
Cc: whatwg
Subject: Re: [whatwg] Firefox 4 Beta 1

I'm sure they keep using HTML5 video in full screen.  The issues around full
screen relate to letting the page trigger full screen.
It's fine for the user to trigger it directly.

Adam


On Wed, Jul 7, 2010 at 3:38 AM, Schalk Neethling <schalk at ossreleasefeed.com>
wrote:
> Hi there everyone,
>
>
>
> Downloaded and installed the first beta of Firefox 4. To the folks at 
> Mozilla that is on here, what an awesome job. Love the new look and it 
> IS very fast. The reason I mention Firefox 4 is because, on the 
> welcome screen you get after installing the browser, you have the 
> option to view a video introduction to Firefox 4, nothing strange here 
> but, first the video format is WebM, which is awesome, the other 
> thing, and this is the main reason for this mail, if you right click 
> on the video there is a context menu option for full screen.
>
>
>
> Upon clicking that, the video goes into full screen mode and it does 
> this, I must say, very nicely. I also noted that in full screen right 
> clicking is disabled. With the discussions around full screen HTML5 
> video as well as content protection, it seems Mozilla has made some 
> progress. Am I correct in saying that they keep running HTML5 video 
> 'mode' when going to full screen or do they somehow switch to Flash?
>
>
>
> Would be pretty amazing if they do switch to Flash as the video 
> continues playing from the same frame and does not start from the
beginning.
>
>
>
> Looking forward to your feedback,
>
> Schalk Neethling
>
>


From ngompa13 at gmail.com  Wed Jul  7 05:48:21 2010
From: ngompa13 at gmail.com (=?ISO-2022-JP?B?Q29uYW4gS3VkbyAoGyRCJUshPCVrISYlNCVzJVEbKEIp?=)
Date: Wed, 7 Jul 2010 07:48:21 -0500
Subject: [whatwg] Firefox 4 Beta 1
In-Reply-To: <008a01cb1dc9$98c60f60$ca522e20$@com>
References: <006501cb1dc0$8cb96e00$a62c4a00$@com>
	<AANLkTimkshCtWjZ7_wz8_LUf-RXwG80K5r54z9ip9H8k@mail.gmail.com>
	<008a01cb1dc9$98c60f60$ca522e20$@com>
Message-ID: <AANLkTilkwtjb4Rw2rySDYv_6oA1rSfnMVwZ_auYpKJf3@mail.gmail.com>

The problem is that YouTube's fullscreen button doesn't actually make the
video full screen, so it doesn't take advantage of the hardware accelerated
fullscreen video in Firefox 4. There's no generic API for allowing web pages
to create skinned HTML 5 players with a "click to fullscreen" button.

On Wed, Jul 7, 2010 at 6:43 AM, Schalk Neethling
<schalk at ossreleasefeed.com>wrote:

> Ah, ok. I see but then I wonder what the problem is with regards to Youtube
> and full screen as their full screen mode is fully user driven.
>
> -----Original Message-----
> From: Adam Barth [mailto:w3c at adambarth.com]
> Sent: Wednesday, July 07, 2010 1:22 PM
> To: Schalk Neethling
> Cc: whatwg
> Subject: Re: [whatwg] Firefox 4 Beta 1
>
> I'm sure they keep using HTML5 video in full screen.  The issues around
> full
> screen relate to letting the page trigger full screen.
> It's fine for the user to trigger it directly.
>
> Adam
>
>
> On Wed, Jul 7, 2010 at 3:38 AM, Schalk Neethling <
> schalk at ossreleasefeed.com>
> wrote:
> > Hi there everyone,
> >
> >
> >
> > Downloaded and installed the first beta of Firefox 4. To the folks at
> > Mozilla that is on here, what an awesome job. Love the new look and it
> > IS very fast. The reason I mention Firefox 4 is because, on the
> > welcome screen you get after installing the browser, you have the
> > option to view a video introduction to Firefox 4, nothing strange here
> > but, first the video format is WebM, which is awesome, the other
> > thing, and this is the main reason for this mail, if you right click
> > on the video there is a context menu option for full screen.
> >
> >
> >
> > Upon clicking that, the video goes into full screen mode and it does
> > this, I must say, very nicely. I also noted that in full screen right
> > clicking is disabled. With the discussions around full screen HTML5
> > video as well as content protection, it seems Mozilla has made some
> > progress. Am I correct in saying that they keep running HTML5 video
> > 'mode' when going to full screen or do they somehow switch to Flash?
> >
> >
> >
> > Would be pretty amazing if they do switch to Flash as the video
> > continues playing from the same frame and does not start from the
> beginning.
> >
> >
> >
> > Looking forward to your feedback,
> >
> > Schalk Neethling
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100707/1df19795/attachment.htm>

From derernst at gmx.ch  Wed Jul  7 07:15:40 2010
From: derernst at gmx.ch (Markus Ernst)
Date: Wed, 07 Jul 2010 16:15:40 +0200
Subject: [whatwg] Iframe dimensions
In-Reply-To: <1278448900.2263.1.camel@localhost>
References: <4C3212B2.6010006@gmx.ch>	<AANLkTim38_gSl9lpUVzG1TFUi5wDrLeG1nA-ILYl3lr5@mail.gmail.com>	<4C32EC12.4020504@gmx.ch>	<AANLkTilQ3P6hhwrpr14n___yrUD-j0wEHQ4h7yYNElOS@mail.gmail.com>	<4C330A54.5030906@gmx.ch>	<AANLkTik1-jW1lLYfpy0fMt-ZH0FMQClx7f4NNnbJ36qG@mail.gmail.com>
	<1278448900.2263.1.camel@localhost>
Message-ID: <4C348C0C.9010706@gmx.ch>

Am 06.07.2010 22:41 schrieb Ashley Sheridan:
> On Tue, 2010-07-06 at 16:17 -0400, Aryeh Gregor wrote:
>> On Tue, Jul 6, 2010 at 6:49 AM, Markus Ernst <derernst at gmx.ch <mailto:derernst at gmx.ch>> wrote:
>> > My problem is this sentence in the spec for seamless: "This will cause links
>> > to open in the parent browsing context."
>> >
>> > In an application like http://test.rapid.ch/de/haendler-schweiz/iseki.html,
>> > the external page should be able to re-call itself inside the iframe, for
>> > example if a sort link is clicked or a search form submitted.
>>
>> Oh.  Hmm.  That does seem to pose a problem.  I can't think of any
>> good solutions off the top of my head.
> 
> Could you explicitly call the _self target in links in the frame? I 
> wasn't sure if the target attribute was going or not, but I'd expect 
> target="_self" to override the default seamless action.

This looks consistent to me. To clarify it, the first list item in the 
part on @seamless in 4.8.2 could then be extended somehow like:

o The user agent must set the seamless browsing context flag to true for 
that browsing context. This will cause links to open in the parent 
browsing context, unless they contain a target attribute which 
explicitly specifies another link target.

(I assume, "links" also refers to form actions here.)

From derernst at gmx.ch  Wed Jul  7 07:36:30 2010
From: derernst at gmx.ch (Markus Ernst)
Date: Wed, 07 Jul 2010 16:36:30 +0200
Subject: [whatwg] Cross-origin opt-in for seamless iframes [was: Iframe
	dimensions]
In-Reply-To: <AANLkTilQ3P6hhwrpr14n___yrUD-j0wEHQ4h7yYNElOS@mail.gmail.com>
References: <4C3212B2.6010006@gmx.ch>	<AANLkTim38_gSl9lpUVzG1TFUi5wDrLeG1nA-ILYl3lr5@mail.gmail.com>	<4C32EC12.4020504@gmx.ch>
	<AANLkTilQ3P6hhwrpr14n___yrUD-j0wEHQ4h7yYNElOS@mail.gmail.com>
Message-ID: <4C3490EE.7030707@gmx.ch>

Am 06.07.2010 12:31 schrieb Aryeh Gregor:
> On Tue, Jul 6, 2010 at 4:40 AM, Markus Ernst <derernst at gmx.ch> wrote:
>> Thank you and Boris for your examples. I see the security issues. Anyway It
>> would be very helpful in cases like mine, where security and privacy are not
>> affected, to get an easy way to do this opt-in without the need of complex
>> scripting, and independent from @seamless. Embedding content from external
>> providers looks like a quite common case to me, and an easy opt-in mechanism
>> would help both the customers and the providers of embedded content.
> 
> So what you're saying is that you really do just want seamless="" with
> easy cross-origin opt-in, right?  That sounds entirely logical, and
> I'm not sure why it's not specced already (or at least I don't see
> it).  Could this be easily added to CORS?  CORS isn't so easy to set
> up, of course, but I'm not sure it's practical to do better.  An HTML
> tag would work, for HTML pages (the common case for iframes), but then
> the UA wouldn't know whether it's allowed to be seamless until it
> started parsing the response, which might have complications.

You are right, the iframe source could be an image, text, or pdf file or 
whatever, without meta or script elements. But an in-page HTML solution 
would of course make opting-in very easy for authors.

I tried to read about CORS, but did not understand the whole of it. Can 
CORS be set up via server-side scripting, with PHP or whatever? Then it 
will be an acceptable solution, and sooner or later libraries will be 
available for both the server and the client side.

If CORS must be set up by the server administrator, it will be a problem 
in shared hosting environments.

Anyway, for something that looks as easy as allowing an iframe to 
seamlessly integrate a document, the overhead of server-side setup and 
client-side scripting looks huge to me, and it also has the downside of 
being dependent on Javascript.

From annevk at opera.com  Wed Jul  7 07:50:01 2010
From: annevk at opera.com (Anne van Kesteren)
Date: Wed, 07 Jul 2010 16:50:01 +0200
Subject: [whatwg] Cross-origin opt-in for seamless iframes [was: Iframe
 dimensions]
In-Reply-To: <4C3490EE.7030707@gmx.ch>
References: <4C3212B2.6010006@gmx.ch>
	<AANLkTim38_gSl9lpUVzG1TFUi5wDrLeG1nA-ILYl3lr5@mail.gmail.com>
	<4C32EC12.4020504@gmx.ch>
	<AANLkTilQ3P6hhwrpr14n___yrUD-j0wEHQ4h7yYNElOS@mail.gmail.com>
	<4C3490EE.7030707@gmx.ch>
Message-ID: <op.vfg947uj64w2qv@annevk-t60>

On Wed, 07 Jul 2010 16:36:30 +0200, Markus Ernst <derernst at gmx.ch> wrote:
> I tried to read about CORS, but did not understand the whole of it. Can  
> CORS be set up via server-side scripting, with PHP or whatever? Then it  
> will be an acceptable solution, and sooner or later libraries will be  
> available for both the server and the client side.
>
> If CORS must be set up by the server administrator, it will be a problem  
> in shared hosting environments.
>
> Anyway, for something that looks as easy as allowing an iframe to  
> seamlessly integrate a document, the overhead of server-side setup and  
> client-side scripting looks huge to me, and it also has the downside of  
> being dependent on Javascript.

Dependent on JavaScript? Adding a header to a resource is not a huge  
overhead. (As an aside, even in shared hosting environments you can  
usually have complete control over what goes out. It's just more  
complicated. But it does not become less complicated if you have your own  
hosting environment either...)

But this discussion is premature. We should first have a couple of  
implementations of seamless before we make things more complicated.


-- 
Anne van Kesteren
http://annevankesteren.nl/

From bzbarsky at MIT.EDU  Wed Jul  7 07:52:39 2010
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Wed, 07 Jul 2010 07:52:39 -0700
Subject: [whatwg] Firefox 4 Beta 1
In-Reply-To: <008a01cb1dc9$98c60f60$ca522e20$@com>
References: <006501cb1dc0$8cb96e00$a62c4a00$@com>	<AANLkTimkshCtWjZ7_wz8_LUf-RXwG80K5r54z9ip9H8k@mail.gmail.com>
	<008a01cb1dc9$98c60f60$ca522e20$@com>
Message-ID: <4C3494B7.9060901@mit.edu>

On 7/7/10 4:43 AM, Schalk Neethling wrote:
> Ah, ok. I see but then I wonder what the problem is with regards to Youtube
> and full screen as their full screen mode is fully user driven.

The problem is that Youtube disables the browser context menu for the 
video (for various reasons) and that from the _browser_'s point of view 
its full-screen button is just some script.  It can't tell it's 
user-driven (at least not without applying heuristics similar to popup 
blocking or some such).

-Boris

From w3c at adambarth.com  Wed Jul  7 09:39:25 2010
From: w3c at adambarth.com (Adam Barth)
Date: Wed, 7 Jul 2010 09:39:25 -0700
Subject: [whatwg] Firefox 4 Beta 1
In-Reply-To: <4C3494B7.9060901@mit.edu>
References: <006501cb1dc0$8cb96e00$a62c4a00$@com>
	<AANLkTimkshCtWjZ7_wz8_LUf-RXwG80K5r54z9ip9H8k@mail.gmail.com> 
	<008a01cb1dc9$98c60f60$ca522e20$@com> <4C3494B7.9060901@mit.edu>
Message-ID: <AANLkTiku9VrelHAJpomaxX7l5r-hvCI9ZWde9U4x1Q6O@mail.gmail.com>

On Wed, Jul 7, 2010 at 7:52 AM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> On 7/7/10 4:43 AM, Schalk Neethling wrote:
>>
>> Ah, ok. I see but then I wonder what the problem is with regards to
>> Youtube
>> and full screen as their full screen mode is fully user driven.
>
> The problem is that Youtube disables the browser context menu for the video
> (for various reasons) and that from the _browser_'s point of view its
> full-screen button is just some script. ?It can't tell it's user-driven (at
> least not without applying heuristics similar to popup blocking or some
> such).

Yeah, there might be room for looking for a user gesture and providing
some sort of clear animation that you're entering full-screen video
mode.  Part of why Flash can do this securely is that they disable
most of the keyboard while you're in full-screen video, which makes it
hard to phish for passwords.

Adam

From narendra at narendrasisodiya.com  Wed Jul  7 09:44:44 2010
From: narendra at narendrasisodiya.com (narendra sisodiya)
Date: Wed, 7 Jul 2010 22:14:44 +0530
Subject: [whatwg] Firefox 4 Beta 1
In-Reply-To: <006501cb1dc0$8cb96e00$a62c4a00$@com>
References: <006501cb1dc0$8cb96e00$a62c4a00$@com>
Message-ID: <AANLkTikiNen5BCgE1DGXnu47TSNyENDiLf-CpuTB0ovI@mail.gmail.com>

On Wed, Jul 7, 2010 at 4:08 PM, Schalk Neethling
<schalk at ossreleasefeed.com>wrote:

>  Hi there everyone
>
I loved this firefox release (4 beta) very much because it support SVG
animations.

Tons of Thanks..

-- 
???????????????????????????
?    Narendra Sisodiya
?    http://narendrasisodiya.com
???????????????????????????
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100707/362d01b7/attachment.htm>

From marques at displague.com  Wed Jul  7 12:00:24 2010
From: marques at displague.com (Marques Johansson)
Date: Wed, 7 Jul 2010 15:00:24 -0400
Subject: [whatwg] More YouTube response
In-Reply-To: <op.vfgthagcatwj1d@philip-pc.gothenburg.osa>
References: <AANLkTinbe-p-STmyfGAiGA6NR7cZO-nzqlq405O5gGTd@mail.gmail.com> 
	<20100705174502.763d384f@desudesudesu>
	<AANLkTilOOfaTJetwoSJWSacAPmSfrFuOSx7CNysX6tBW@mail.gmail.com> 
	<AANLkTilRA7CT2YvUv6Jz7J1WgNA_k5N1lqPZ2YB82ks3@mail.gmail.com> 
	<op.vfffwqjkatwj1d@philip-pc.gothenburg.osa>
	<AANLkTinE3ruLIKVeVaqkufZ1RRnC1Zmzd52H1bu82EqL@mail.gmail.com> 
	<op.vfgthagcatwj1d@philip-pc.gothenburg.osa>
Message-ID: <AANLkTinhf_HRPM8ixcmz-sZvSX_vL9HyIu__0tnE74Dy@mail.gmail.com>

>
> Yes, the browser disconnects, and scripts have no influence over it. With
> preload="metadata" implemented, it should disconnect as soon as possible
> after getting enough data for the first frame. For preload="auto", it will
> disconnect after buffering X seconds of data. If you need more granularity
> than that, I suggest server-side control informed by information collected
> by JavaScript. If browsers handled a short reply to a range request, it
> should work just fine, no?
>
>
Yes.  I started my quest as a Firefox bug report
https://bugzilla.mozilla.org/show_bug.cgi?id=570755  .. The developers
weren't sure that the HTTP spec actually permits a browser to handle a short
response in this way.  When I went fishing around through the spec I found
some things that seemed to permit this and other things that contradicted
them (noted in the bug report).  I started mailing the HTTP-bis group but
they were not convinced either
http://lists.w3.org/Archives/Public/ietf-http-wg/2010AprJun/0339.html.

Chrome handles short 206s the same way Opera's ogg handler does but nothing
else does.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100707/44fd0a89/attachment.htm>

From Simetrical+w3c at gmail.com  Wed Jul  7 12:53:30 2010
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Wed, 7 Jul 2010 15:53:30 -0400
Subject: [whatwg] Iframe dimensions
In-Reply-To: <1278448900.2263.1.camel@localhost>
References: <4C3212B2.6010006@gmx.ch>
	<AANLkTim38_gSl9lpUVzG1TFUi5wDrLeG1nA-ILYl3lr5@mail.gmail.com>
	<4C32EC12.4020504@gmx.ch>
	<AANLkTilQ3P6hhwrpr14n___yrUD-j0wEHQ4h7yYNElOS@mail.gmail.com>
	<4C330A54.5030906@gmx.ch>
	<AANLkTik1-jW1lLYfpy0fMt-ZH0FMQClx7f4NNnbJ36qG@mail.gmail.com>
	<1278448900.2263.1.camel@localhost>
Message-ID: <AANLkTimfNNcWZRE6y_6nIh776AYyk0hl2I5yT75JYCnH@mail.gmail.com>

On Tue, Jul 6, 2010 at 4:41 PM, Ashley Sheridan
<ash at ashleysheridan.co.uk> wrote:
> Could you explicitly call the _self target in links in the frame? I wasn't sure if the target attribute was going or not, but I'd expect target="_self" to override the default seamless action.

It doesn't.  The iframe is considered part of the parent page for the
purposes of navigation, so _self refers to the parent page.  See the
full algorithm:

http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#navigate

Step 3 there does not take into consideration how the browsing context
to be navigated was chosen.  Anything that tries to navigate the
seamless iframe in any way will navigate the first non-seamless
ancestor instead.  That includes a regular old link, a link with
target="_self" explicit, navigation by JavaScript, and any other
possible way of navigating.  This is intended and correct for the
use-cases that seamless was designed for.

On Wed, Jul 7, 2010 at 10:15 AM, Markus Ernst <derernst at gmx.ch> wrote:
> This looks consistent to me. To clarify it, the first list item in the part
> on @seamless in 4.8.2 could then be extended somehow like:
>
> o The user agent must set the seamless browsing context flag to true for
> that browsing context. This will cause links to open in the parent browsing
> context, unless they contain a target attribute which explicitly specifies
> another link target.
>
> (I assume, "links" also refers to form actions here.)

That doesn't change the conformance requirements that "cause links to
open in the parent browsing context" links to.  The target of that
link is the detailed description of what that requirement means -- the
bullet point in the iframe section is just an informative (and vague,
and inaccurate) summary.  You would have to change the navigation
algorithm to figure out what triggered the navigation and so on.  But
I don't think this is desirable for the primary use-case of seamless.

From Simetrical+w3c at gmail.com  Wed Jul  7 13:16:04 2010
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Wed, 7 Jul 2010 16:16:04 -0400
Subject: [whatwg] More YouTube response
In-Reply-To: <AANLkTilL36oil_Kw4nuhs8JIU1qG-5LRItCSsLPf9VnS@mail.gmail.com>
References: <AANLkTinbe-p-STmyfGAiGA6NR7cZO-nzqlq405O5gGTd@mail.gmail.com>
	<20100705174502.763d384f@desudesudesu>
	<AANLkTilOOfaTJetwoSJWSacAPmSfrFuOSx7CNysX6tBW@mail.gmail.com>
	<AANLkTilRA7CT2YvUv6Jz7J1WgNA_k5N1lqPZ2YB82ks3@mail.gmail.com>
	<AANLkTimriXnIcz81mzUSRDQEpdgC_LXVt9fbLLLEnyp7@mail.gmail.com>
	<AANLkTilL36oil_Kw4nuhs8JIU1qG-5LRItCSsLPf9VnS@mail.gmail.com>
Message-ID: <AANLkTilh-pIsqOXZxl6NhiHmCAdj3wMBA6_Pv8hJW5oV@mail.gmail.com>

On Tue, Jul 6, 2010 at 5:19 PM, Marques Johansson <marques at displague.com> wrote:
> I tested cutting off the HTTP connection and browsers didn't handle this.

You mean they didn't stop playing the video and trigger an error event
that JavaScript can handle?  What did they do?

> and found that browsers do not attempt to refetch the data or continue with
> a 206 for the next block.

Right, they stop playing and raise an error.  This is correct if the
user has used up all their video allotment and is not allowed to view
more.

> Shouldn't something like this be be worked into the protocol or the language
> instead of having to break the stream at a higher level?

No, because it's not a big enough use-case to get its own special
HTML-level features.  Browser implementers have more important things
to implement.

> prefetch="metadata" is the plan - but how far forward will the browser
> attempt to buffer? When will the browser stop buffering and start playing? I
> think the server/service/html/http side of things should have some say. ?I
> wouldn't want to see browser X seek 10 seconds ahead while browser Y fetches
> 60 seconds in advance.

The best way to give authors this level of control might be to expose
more functions or events to script, so the script can decide exactly
when to fetch more bytes and how much.

> As I stated before - this didn't pan out for me - I will happily test other
> methods.

It didn't pan out because you weren't doing what I suggested.  You
were cutting off the connection even when the user still had the right
to view more bytes.  I suggested you only cut the connection when the
user is actually not allowed to view more video, in which case they'd
get an error, as they should.  (This will only work if you can
persuade the browser not to buffer significantly ahead of the current
time.)

From jharding at google.com  Wed Jul  7 13:54:26 2010
From: jharding at google.com (John Harding)
Date: Wed, 7 Jul 2010 13:54:26 -0700
Subject: [whatwg] More YouTube response
In-Reply-To: <2137EE0B-8885-4975-BDD6-52415412AE19@apple.com>
References: <AANLkTinbe-p-STmyfGAiGA6NR7cZO-nzqlq405O5gGTd@mail.gmail.com> 
	<AANLkTilhe5qKzpIsgTP1NaZd9aYiQJIOa8oBQLqMnJ0p@mail.gmail.com> 
	<AANLkTilsTSXqbbGVMfUjHCARImFPR4rFsiwgipaEI1Ge@mail.gmail.com> 
	<6829CF63-7A27-43AD-A1E6-1D16C42157F1@apple.com>
	<2137EE0B-8885-4975-BDD6-52415412AE19@apple.com>
Message-ID: <AANLkTikkyHlzH_ke71UXKtMKjJ27yT3A-mSGSYfAPJIU@mail.gmail.com>

MySpace is my canonical example - they allow arbitrary SWFs to be embedded
in profiles, but not <iframe>s.  Flash added support a while back that
allows containing pages to block SWFs from executing script or accessing the
contents of the page, which MySpace enforces by rewriting the <embed> tag
that users post.  Before that, yes, allowing arbitrary SWFs to be posted by
users was a huge security hole.

Regardless, I think we're all agreed on the path forward (Use <iframe>s to
embed content instead of naked <embed> tags) and just need to start moving
on it, and the ball is largely in YouTube's court on this point.

-John

On Fri, Jul 2, 2010 at 6:20 PM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> On Jul 2, 2010, at 6:04 PM, Maciej Stachowiak wrote:
>
> >
> > Any site which does that has a giant security hole, since Flash can be
> used to arbitrarily script the embedding page. It's about as safe as
> allowing embedding of arbitrary off-site <script>. If you are aware of sites
> that allow embedding of arbitrary off-site Flash, you should alert them to
> the potential security risks. For example a social network site that allowed
> this would be vulnerable to a self-propagating worm.
> >
> > What I have heard before is that sites whitelist specific SWFs or Flash
> from specific domains. I'm don't have any first-hand knowledge of how sites
> actually do it.
>
> With testing I found at least one site where I can apparently embed
> arbitrary SWFs. However, this site has per-user domains, so it might be
> relatively safe. This site also allows me to embed arbitrary content in an
> <iframe>.
>
> Regards,
> Maciej
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100707/4fc8dfb1/attachment.htm>

From jharding at google.com  Wed Jul  7 14:50:44 2010
From: jharding at google.com (John Harding)
Date: Wed, 7 Jul 2010 14:50:44 -0700
Subject: [whatwg] More YouTube response
In-Reply-To: <20100705174502.763d384f@desudesudesu>
References: <AANLkTinbe-p-STmyfGAiGA6NR7cZO-nzqlq405O5gGTd@mail.gmail.com> 
	<20100705174502.763d384f@desudesudesu>
Message-ID: <AANLkTimBAXE3iOQBQ957iI2v0hnBGOFqvyERNJVzLXWb@mail.gmail.com>

Ok - sounds like pretty much unanimous objection to the idea of DRM plugins
being instantiated via <video> tag.  I'll still be pushing on the DRM plugin
providers to implement an interface that mimics the <video> tag - my primary
goal is to be able to have a single player implementation independent of
whether or not DRM is involved.  It's not the end of the world if one uses
<video> and the other uses <embed>.

-John

On Mon, Jul 5, 2010 at 8:45 AM, Nils Dagsson Moskopp <
nils-dagsson-moskopp at dieweltistgarnichtso.net> wrote:

> John Harding <jharding at google.com> schrieb am Thu, 1 Jul 2010 15:59:37
> -0700:
>
> > 1. Standard Video Format
> > [?]
> > On the current path, a content provider knows
> > that by offering H.264 and WebM, they can reach all HTML5-capable
> > browsers.  This honestly is a reasonable state for YouTube right now
> > - we use H.264 in cases outside the <video> tag as well, but it would
> > be nice to converge on a single baseline format at some point in the
> > future.
>
> Practically, I think the ball is / was in Apple's court to decide this.
> While to this day other browser makers have decided to ship two (!)
> royalty-free video formats (Theora and VP8), Apple is the single H.264
> holdout, and they have a tight itegration to their hardware as well.
>
> Sadly, I do not have hope for any consolidation regarding video
> formats. And while Youtube may be fine with having to provide only two
> formats instead of a dozen, for the common smaller webmaster this is a
> significant task, as transcoding resources are limited.
>
> Recently, I have been discussing <video> implementation with the
> administrator of an imageboard. It was ultimately decided to not add
> this feature, precisely because of the multitude of video formats of
> which none can be played in every modern browser. It's a shame.
>
> > [?]
>
> > 3. Content Protection
> > [?]
> > The basic requirements
> > around content protection that we get from content owners basically
> > consist of encrypting the content and limiting the decryption to a
> > "verified" and authorized client - the realm of traditional DRM.
>
> This can not possibly work if you have an open standard, which by
> design has to be implementable by everyone who cares, which includes a
> wide range of free and proprietary software vendors.
>
> > Rather than ask browsers to get into the DRM business, what I think
> > would work best is having a means for 3rd party DRM providers to
> > supply browser plug-ins which implement the <video> tag for protected
> > content - not all that different than selecting a pluggable codec.
>
> To define a feature like that would hurt an otherwise open standard and
> help to balkanize the browser market even more. If you really want to
> do this, why not just use flash / java / whatever can deliver using
> already available proprietary means ?
>
> > [?]
>
>
> Greetings,
> --
> Nils Dagsson Moskopp // erlehmann
> <http://dieweltistgarnichtso.net>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100707/4c37c90f/attachment-0001.htm>

From dhtmlkitchen at gmail.com  Wed Jul  7 17:28:13 2010
From: dhtmlkitchen at gmail.com (Garrett Smith)
Date: Wed, 7 Jul 2010 17:28:13 -0700
Subject: [whatwg] HTML5 (including next generation additions still in
	development) - Mozilla Firefox (Not Responding)
Message-ID: <AANLkTinpaHBTei0tuWGWr6qx-0NKTIPtUQmKudf7TA_P@mail.gmail.com>

This is about the  fourth time I've said it here. Can the person in
charge of writing the slow and buggy ajvascript on the HTML 5 spec
please remove that?


The problem is that that whatwg page causes freezes and crashes in Firefox. i

When it doesn't throw errors, it freezes Firefox.

This is is unfair to the the user, who might not anticipate when
clicking on a link.

Launching Task Manager...

From jackalmage at gmail.com  Wed Jul  7 17:41:12 2010
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Wed, 7 Jul 2010 17:41:12 -0700
Subject: [whatwg] HTML5 (including next generation additions still in
	development) - Mozilla Firefox (Not Responding)
In-Reply-To: <AANLkTinpaHBTei0tuWGWr6qx-0NKTIPtUQmKudf7TA_P@mail.gmail.com>
References: <AANLkTinpaHBTei0tuWGWr6qx-0NKTIPtUQmKudf7TA_P@mail.gmail.com>
Message-ID: <AANLkTin13yg51iymdKPLl0BTOspzidp62hSVTZKJNXz5@mail.gmail.com>

On Wed, Jul 7, 2010 at 5:28 PM, Garrett Smith <dhtmlkitchen at gmail.com> wrote:
> This is about the ?fourth time I've said it here. Can the person in
> charge of writing the slow and buggy ajvascript on the HTML 5 spec
> please remove that?
>
>
> The problem is that that whatwg page causes freezes and crashes in Firefox. i
>
> When it doesn't throw errors, it freezes Firefox.
>
> This is is unfair to the the user, who might not anticipate when
> clicking on a link.
>
> Launching Task Manager...

Use the multipage version of the spec instead.  The one-page version
doubles as a browser stress-test.

People do sometimes send links to the one-page version; you'll just
have to watch out for that and correct it yourself.

~TJ

From aa at google.com  Wed Jul  7 17:43:39 2010
From: aa at google.com (Aaron Boodman)
Date: Wed, 7 Jul 2010 17:43:39 -0700
Subject: [whatwg] HTML5 (including next generation additions still in
	development) - Mozilla Firefox (Not Responding)
In-Reply-To: <AANLkTin13yg51iymdKPLl0BTOspzidp62hSVTZKJNXz5@mail.gmail.com>
References: <AANLkTinpaHBTei0tuWGWr6qx-0NKTIPtUQmKudf7TA_P@mail.gmail.com>
	<AANLkTin13yg51iymdKPLl0BTOspzidp62hSVTZKJNXz5@mail.gmail.com>
Message-ID: <AANLkTikuporIltuZb6NNoJPeV5N9etowLHe6UELn5EW4@mail.gmail.com>

On Wed, Jul 7, 2010 at 5:41 PM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
> On Wed, Jul 7, 2010 at 5:28 PM, Garrett Smith <dhtmlkitchen at gmail.com> wrote:
>> This is about the ?fourth time I've said it here. Can the person in
>> charge of writing the slow and buggy ajvascript on the HTML 5 spec
>> please remove that?
>>
>>
>> The problem is that that whatwg page causes freezes and crashes in Firefox. i
>>
>> When it doesn't throw errors, it freezes Firefox.
>>
>> This is is unfair to the the user, who might not anticipate when
>> clicking on a link.
>>
>> Launching Task Manager...
>
> Use the multipage version of the spec instead. ?The one-page version
> doubles as a browser stress-test.
>
> People do sometimes send links to the one-page version; you'll just
> have to watch out for that and correct it yourself.

I hear this every so often. Do we really need the spec to double as a
browser stress test? I mean, there are actual test suites nowadays. I
just want to read the spec.

- a

From dhtmlkitchen at gmail.com  Wed Jul  7 17:46:53 2010
From: dhtmlkitchen at gmail.com (Garrett Smith)
Date: Wed, 7 Jul 2010 17:46:53 -0700
Subject: [whatwg] HTML5 (including next generation additions still in
	development) - Mozilla Firefox (Not Responding)
In-Reply-To: <AANLkTin13yg51iymdKPLl0BTOspzidp62hSVTZKJNXz5@mail.gmail.com>
References: <AANLkTinpaHBTei0tuWGWr6qx-0NKTIPtUQmKudf7TA_P@mail.gmail.com>
	<AANLkTin13yg51iymdKPLl0BTOspzidp62hSVTZKJNXz5@mail.gmail.com>
Message-ID: <AANLkTiktW65CnJFvbQ3LqG3t11K61frRAPXuW1QmYgiX@mail.gmail.com>

On 7/7/10, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
> On Wed, Jul 7, 2010 at 5:28 PM, Garrett Smith <dhtmlkitchen at gmail.com>
> wrote:
>> This is about the  fourth time I've said it here. Can the person in
>> charge of writing the slow and buggy ajvascript on the HTML 5 spec
>> please remove that?
>>
>>
>> The problem is that that whatwg page causes freezes and crashes in
>> Firefox. i
>>
>> When it doesn't throw errors, it freezes Firefox.
>>
>> This is is unfair to the the user, who might not anticipate when
>> clicking on a link.
>>
>> Launching Task Manager...
>
> Use the multipage version of the spec instead.  The one-page version
> doubles as a browser stress-test.
>

Intentionally, or did somebody switch the reason?

> People do sometimes send links to the one-page version; you'll just
> have to watch out for that and correct it yourself.
>

Blaming the user for clicking the link doesn't seem right, IMO. AISI
the problem is with the site being too slow and heavy and that's what
should be fixed.

From dpranke at chromium.org  Wed Jul  7 17:52:59 2010
From: dpranke at chromium.org (Dirk Pranke)
Date: Wed, 7 Jul 2010 17:52:59 -0700
Subject: [whatwg] HTML5 (including next generation additions still in
	development) - Mozilla Firefox (Not Responding)
In-Reply-To: <AANLkTikuporIltuZb6NNoJPeV5N9etowLHe6UELn5EW4@mail.gmail.com>
References: <AANLkTinpaHBTei0tuWGWr6qx-0NKTIPtUQmKudf7TA_P@mail.gmail.com>
	<AANLkTin13yg51iymdKPLl0BTOspzidp62hSVTZKJNXz5@mail.gmail.com>
	<AANLkTikuporIltuZb6NNoJPeV5N9etowLHe6UELn5EW4@mail.gmail.com>
Message-ID: <AANLkTimQiqS1xPDr7dFITehnEw9y_5JT-193A4loOyhp@mail.gmail.com>

On Wed, Jul 7, 2010 at 5:43 PM, Aaron Boodman <aa at google.com> wrote:
> On Wed, Jul 7, 2010 at 5:41 PM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
>> On Wed, Jul 7, 2010 at 5:28 PM, Garrett Smith <dhtmlkitchen at gmail.com> wrote:
>>> This is about the ?fourth time I've said it here. Can the person in
>>> charge of writing the slow and buggy ajvascript on the HTML 5 spec
>>> please remove that?
>>>
>>>
>>> The problem is that that whatwg page causes freezes and crashes in Firefox. i
>>>
>>> When it doesn't throw errors, it freezes Firefox.
>>>
>>> This is is unfair to the the user, who might not anticipate when
>>> clicking on a link.
>>>
>>> Launching Task Manager...
>>
>> Use the multipage version of the spec instead. ?The one-page version
>> doubles as a browser stress-test.
>>
>> People do sometimes send links to the one-page version; you'll just
>> have to watch out for that and correct it yourself.
>
> I hear this every so often. Do we really need the spec to double as a
> browser stress test? I mean, there are actual test suites nowadays. I
> just want to read the spec.
>

There is also the ?slow-browser option, e.g.:

http://www.whatwg.org/specs/web-apps/current-work/?slow-browser

I sometimes wonder if that shouldn't be the default, and then the
people that wanted the commenting, etc. could bookmark the stress test
version.

-- Dirk

From bzbarsky at MIT.EDU  Wed Jul  7 18:40:10 2010
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Wed, 07 Jul 2010 18:40:10 -0700
Subject: [whatwg] HTML5 (including next generation additions still in
 development) - Mozilla Firefox (Not Responding)
In-Reply-To: <AANLkTinpaHBTei0tuWGWr6qx-0NKTIPtUQmKudf7TA_P@mail.gmail.com>
References: <AANLkTinpaHBTei0tuWGWr6qx-0NKTIPtUQmKudf7TA_P@mail.gmail.com>
Message-ID: <4C352C7A.1010700@mit.edu>

On 7/7/10 5:28 PM, Garrett Smith wrote:
> The problem is that that whatwg page causes freezes and crashes in Firefox.

May I recommend trying out Firefox 4 beta 1?  ;)

-Boris

From bzbarsky at MIT.EDU  Wed Jul  7 18:43:03 2010
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Wed, 07 Jul 2010 18:43:03 -0700
Subject: [whatwg] HTML5 (including next generation additions still in
 development) - Mozilla Firefox (Not Responding)
In-Reply-To: <AANLkTikuporIltuZb6NNoJPeV5N9etowLHe6UELn5EW4@mail.gmail.com>
References: <AANLkTinpaHBTei0tuWGWr6qx-0NKTIPtUQmKudf7TA_P@mail.gmail.com>	<AANLkTin13yg51iymdKPLl0BTOspzidp62hSVTZKJNXz5@mail.gmail.com>
	<AANLkTikuporIltuZb6NNoJPeV5N9etowLHe6UELn5EW4@mail.gmail.com>
Message-ID: <4C352D27.7050307@mit.edu>

On 7/7/10 5:43 PM, Aaron Boodman wrote:
> I hear this every so often. Do we really need the spec to double as a
> browser stress test? I mean, there are actual test suites nowadays. I
> just want to read the spec.

I'll just note that part of the reason it's a "stress test", apart from 
the old Firefox issue, is that it tries to be clever and not hang the 
browser.... which actually causes the browser to do a lot more work.  On 
my machine here, if the spec's script were not trying for the clever 
thing, it would take about 1-2 seconds (with a completely hung browser 
during that time) to do what it currently takes anywhere from 8 to 25 
seconds to do, during which time the browser is largely unresponsive anyway.

-Boris

From diego.perini at gmail.com  Thu Jul  8 00:45:47 2010
From: diego.perini at gmail.com (Diego Perini)
Date: Thu, 8 Jul 2010 09:45:47 +0200
Subject: [whatwg] HTML5 (including next generation additions still in
	development) - Mozilla Firefox (Not Responding)
In-Reply-To: <4C352D27.7050307@mit.edu>
References: <AANLkTinpaHBTei0tuWGWr6qx-0NKTIPtUQmKudf7TA_P@mail.gmail.com>
	<AANLkTin13yg51iymdKPLl0BTOspzidp62hSVTZKJNXz5@mail.gmail.com>
	<AANLkTikuporIltuZb6NNoJPeV5N9etowLHe6UELn5EW4@mail.gmail.com>
	<4C352D27.7050307@mit.edu>
Message-ID: <AANLkTimhCpZ4aoy-jxc9bC-r5tm23357Ju_Gce5HGpN_@mail.gmail.com>

I do not see the reason of having a specification lecture also be a
stress-test.

As Aaron already said I just want to be able to read the specs.

A button at the top maybe to switch to the stress-test ?

Diego


On Thu, Jul 8, 2010 at 3:43 AM, Boris Zbarsky <bzbarsky at mit.edu> wrote:

> On 7/7/10 5:43 PM, Aaron Boodman wrote:
>
>> I hear this every so often. Do we really need the spec to double as a
>> browser stress test? I mean, there are actual test suites nowadays. I
>> just want to read the spec.
>>
>
> I'll just note that part of the reason it's a "stress test", apart from the
> old Firefox issue, is that it tries to be clever and not hang the
> browser.... which actually causes the browser to do a lot more work.  On my
> machine here, if the spec's script were not trying for the clever thing, it
> would take about 1-2 seconds (with a completely hung browser during that
> time) to do what it currently takes anywhere from 8 to 25 seconds to do,
> during which time the browser is largely unresponsive anyway.
>
> -Boris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100708/28134c36/attachment-0001.htm>

From lachlan.hunt at lachy.id.au  Thu Jul  8 07:03:19 2010
From: lachlan.hunt at lachy.id.au (Lachlan Hunt)
Date: Thu, 08 Jul 2010 16:03:19 +0200
Subject: [whatwg] HTML5 (including next generation additions still in
 development) - Mozilla Firefox (Not Responding)
In-Reply-To: <AANLkTinpaHBTei0tuWGWr6qx-0NKTIPtUQmKudf7TA_P@mail.gmail.com>
References: <AANLkTinpaHBTei0tuWGWr6qx-0NKTIPtUQmKudf7TA_P@mail.gmail.com>
Message-ID: <4C35DAA7.4060108@lachy.id.au>

On 2010-07-08 02:28, Garrett Smith wrote:
> This is about the  fourth time I've said it here. Can the person in
> charge of writing the slow and buggy ajvascript on the HTML 5 spec
> please remove that?
>
>
> The problem is that that whatwg page causes freezes and crashes in Firefox. i

As a workaround, you can use AdBlock in Firefox to block the offending 
script.  Just manually add this URL to your block list.

http://www.whatwg.org/specs/web-apps/current-work/status.js

-- 
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

From hsivonen at iki.fi  Thu Jul  8 08:35:44 2010
From: hsivonen at iki.fi (Henri Sivonen)
Date: Thu, 8 Jul 2010 08:35:44 -0700
Subject: [whatwg] HTML5 (including next generation additions still in
	development) - Mozilla Firefox (Not Responding)
In-Reply-To: <AANLkTimhCpZ4aoy-jxc9bC-r5tm23357Ju_Gce5HGpN_@mail.gmail.com>
References: <AANLkTinpaHBTei0tuWGWr6qx-0NKTIPtUQmKudf7TA_P@mail.gmail.com>
	<AANLkTin13yg51iymdKPLl0BTOspzidp62hSVTZKJNXz5@mail.gmail.com>
	<AANLkTikuporIltuZb6NNoJPeV5N9etowLHe6UELn5EW4@mail.gmail.com>
	<4C352D27.7050307@mit.edu>
	<AANLkTimhCpZ4aoy-jxc9bC-r5tm23357Ju_Gce5HGpN_@mail.gmail.com>
Message-ID: <81AD702D-6EE0-4A26-879C-50554B323E25@iki.fi>

On Jul 8, 2010, at 00:45, Diego Perini wrote:

> I do not see the reason of having a specification lecture also be a stress-test.
> 
> As Aaron already said I just want to be able to read the specs.
> 
> A button at the top maybe to switch to the stress-test ? 

It's not primarily a stress test. The script provides a useful function (status annotations).

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/



From diego.perini at gmail.com  Thu Jul  8 09:23:36 2010
From: diego.perini at gmail.com (Diego Perini)
Date: Thu, 8 Jul 2010 18:23:36 +0200
Subject: [whatwg] HTML5 (including next generation additions still in
	development) - Mozilla Firefox (Not Responding)
In-Reply-To: <81AD702D-6EE0-4A26-879C-50554B323E25@iki.fi>
References: <AANLkTinpaHBTei0tuWGWr6qx-0NKTIPtUQmKudf7TA_P@mail.gmail.com>
	<AANLkTin13yg51iymdKPLl0BTOspzidp62hSVTZKJNXz5@mail.gmail.com>
	<AANLkTikuporIltuZb6NNoJPeV5N9etowLHe6UELn5EW4@mail.gmail.com>
	<4C352D27.7050307@mit.edu>
	<AANLkTimhCpZ4aoy-jxc9bC-r5tm23357Ju_Gce5HGpN_@mail.gmail.com>
	<81AD702D-6EE0-4A26-879C-50554B323E25@iki.fi>
Message-ID: <AANLkTikQ2KeT1ybxhTMenKL_6OKXt7EC8nYwDJPulwZ4@mail.gmail.com>

On Thu, Jul 8, 2010 at 5:35 PM, Henri Sivonen <hsivonen at iki.fi> wrote:

> On Jul 8, 2010, at 00:45, Diego Perini wrote:
>
> > I do not see the reason of having a specification lecture also be a
> stress-test.
> >
> > As Aaron already said I just want to be able to read the specs.
> >
> > A button at the top maybe to switch to the stress-test ?
>
> It's not primarily a stress test. The script provides a useful function
> (status annotations).
>
>
Your are correct the "status annotations" could be very useful to some.

Let me reformulate. What about a button on the top to enable "status
annotations" ?

Isn't that more useful and less obtrusive for more people (and more browsers
too) ?

Diego Perini


> --
> Henri Sivonen
> hsivonen at iki.fi
> http://hsivonen.iki.fi/
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100708/c37f1110/attachment.htm>

From diego.perini at gmail.com  Thu Jul  8 10:18:46 2010
From: diego.perini at gmail.com (Diego Perini)
Date: Thu, 8 Jul 2010 19:18:46 +0200
Subject: [whatwg] HTML5 (including next generation additions still in
	development) - Mozilla Firefox (Not Responding)
In-Reply-To: <4C35DAA7.4060108@lachy.id.au>
References: <AANLkTinpaHBTei0tuWGWr6qx-0NKTIPtUQmKudf7TA_P@mail.gmail.com>
	<4C35DAA7.4060108@lachy.id.au>
Message-ID: <AANLkTimzzGlW80gpLTsGo_utaUvq7zzeSFon5FDNv5-l@mail.gmail.com>

On Thu, Jul 8, 2010 at 4:03 PM, Lachlan Hunt <lachlan.hunt at lachy.id.au>wrote:

> On 2010-07-08 02:28, Garrett Smith wrote:
>
>> This is about the  fourth time I've said it here. Can the person in
>> charge of writing the slow and buggy ajvascript on the HTML 5 spec
>> please remove that?
>>
>>
>> The problem is that that whatwg page causes freezes and crashes in
>> Firefox. i
>>
>
> As a workaround, you can use AdBlock in Firefox to block the offending
> script.  Just manually add this URL to your block list.
>
> http://www.whatwg.org/specs/web-apps/current-work/status.js
>
> --
> Lachlan Hunt - Opera Software
> http://lachy.id.au/
> http://www.opera.com/
>

The problem is not only with Firefox and it happens I am not only using
Firefox.

Is there a similar blocking feature of Opera that you can suggest ?

Also in Opera:

   Uncaught exception: Reference Error: Undefined variable: fixBrokenLink
   Error thrown at line 39, column 5 in init() in
http://dev.w3.org/html5/spec/Overview.html: fixBrokenLink();
   called from line 1, column 0 in <anonymous function>(event): init()

I haven't reviewed the complete script itself but I have some thoughts about
this (comparing behaviour on different browsers).

I suspect that when the above is fixed it will take more time in Opera and
other browsers throwing errors and (maybe) suspending execution. As a side
note, should the browser completely suspend script execution when an event
handler fails ?

Isn't the error thrown in a different execution context when handling event
listeners ?

I believe the main execution context should not be suppressed, especially
for an undeclared variable in a different context.

Diego Perini
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100708/c3c83663/attachment.htm>

From ash at ashleysheridan.co.uk  Thu Jul  8 10:23:23 2010
From: ash at ashleysheridan.co.uk (Ashley Sheridan)
Date: Thu, 08 Jul 2010 18:23:23 +0100
Subject: [whatwg] HTML5 (including next generation additions still in
 development) - Mozilla Firefox (Not Responding)
In-Reply-To: <AANLkTimzzGlW80gpLTsGo_utaUvq7zzeSFon5FDNv5-l@mail.gmail.com>
References: <AANLkTinpaHBTei0tuWGWr6qx-0NKTIPtUQmKudf7TA_P@mail.gmail.com>
	<4C35DAA7.4060108@lachy.id.au>
	<AANLkTimzzGlW80gpLTsGo_utaUvq7zzeSFon5FDNv5-l@mail.gmail.com>
Message-ID: <1278609803.2359.32.camel@localhost>

On Thu, 2010-07-08 at 19:18 +0200, Diego Perini wrote:

> 
> 
> 
> On Thu, Jul 8, 2010 at 4:03 PM, Lachlan Hunt
> <lachlan.hunt at lachy.id.au> wrote:
> 
>         On 2010-07-08 02:28, Garrett Smith wrote:
>         
>                 This is about the  fourth time I've said it here. Can
>                 the person in
>                 charge of writing the slow and buggy ajvascript on the
>                 HTML 5 spec
>                 please remove that?
>                 
>                 
>                 The problem is that that whatwg page causes freezes
>                 and crashes in Firefox. i
>         
>         
>         As a workaround, you can use AdBlock in Firefox to block the
>         offending script.  Just manually add this URL to your block
>         list.
>         
>         http://www.whatwg.org/specs/web-apps/current-work/status.js
>         
>         -- 
>         Lachlan Hunt - Opera Software
>         http://lachy.id.au/
>         http://www.opera.com/
> 
> 
> The problem is not only with Firefox and it happens I am not only
> using Firefox.
> 
> Is there a similar blocking feature of Opera that you can suggest ?
> 
> Also in Opera:
> 
>    Uncaught exception: Reference Error: Undefined variable:
> fixBrokenLink
>    Error thrown at line 39, column 5 in init() in
> http://dev.w3.org/html5/spec/Overview.html: fixBrokenLink();
>    called from line 1, column 0 in <anonymous function>(event): init()
> 
> I haven't reviewed the complete script itself but I have some thoughts
> about this (comparing behaviour on different browsers).
> 
> I suspect that when the above is fixed it will take more time in Opera
> and other browsers throwing errors and (maybe) suspending execution.
> As a side note, should the browser completely suspend script execution
> when an event handler fails ?
> 
> Isn't the error thrown in a different execution context when handling
> event listeners ?
> 
> I believe the main execution context should not be suppressed,
> especially for an undeclared variable in a different context.
> 
> Diego Perini
> 


Someone earlier mentioned the
http://www.whatwg.org/specs/web-apps/current-work/?slow-browser URL.
Would it not be sensible to maybe make that the default behaviour, and
then use a special ?crash-test type URL as the -one that crashes the
browsers- stress test? That way, you'd still have the test if people
wanted it, and those that don't won't get unexpected behaviour.

Or maybe I'm misunderstanding the problem?

Thanks,
Ash
http://www.ashleysheridan.co.uk


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100708/03ca30cd/attachment.htm>

From dhtmlkitchen at gmail.com  Thu Jul  8 10:25:21 2010
From: dhtmlkitchen at gmail.com (Garrett Smith)
Date: Thu, 8 Jul 2010 10:25:21 -0700
Subject: [whatwg] HTML5 (including next generation additions still in
	development) - Mozilla Firefox (Not Responding)
In-Reply-To: <4C35DAA7.4060108@lachy.id.au>
References: <AANLkTinpaHBTei0tuWGWr6qx-0NKTIPtUQmKudf7TA_P@mail.gmail.com>
	<4C35DAA7.4060108@lachy.id.au>
Message-ID: <AANLkTilNyOrRb97J3Xc6EVN94Z-Jwv2s76lDHIqv3ZFB@mail.gmail.com>

On 7/8/10, Lachlan Hunt <lachlan.hunt at lachy.id.au> wrote:
> On 2010-07-08 02:28, Garrett Smith wrote:
>> This is about the  fourth time I've said it here. Can the person in
>> charge of writing the slow and buggy ajvascript on the HTML 5 spec
>> please remove that?
>>
>>
>> The problem is that that whatwg page causes freezes and crashes in
>> Firefox. i
>
> As a workaround, you can use AdBlock in Firefox to block the offending
> script.  Just manually add this URL to your block list.
>
> http://www.whatwg.org/specs/web-apps/current-work/status.js

Does every user have permission to do that? On any computer? Running
any browser?

Crashing and freezing and throwing js errors is just no good at all.
The user should not be punished for trying to RTM (and some might even
consider RTM itself punishment).

Adding a disclaimer at the top of the page that the page itself is a
stress test might help stop people from linking to it. It wouldn't
help the user who clicked the link, so it isn't a complete solution.

Adding a link to AdBlock plugin at the top of the spec to tell the
user to download it would help, too, but it would still not be fair to
the user because it is too late. It could also be that the user does
not have permission to install plugins or that the browser doesn't
support the plugin, such as IE6.

Why not have a separated link? The link could go in the spec itself or
could go link to a page of test pages. Two clicks makes it so that the
user won't easily click on it by accident.

<H1>HTML 5<h1>
...
<h3>HTML Tests</h3>
<p>
  <a href="http://example.net/">Latest Test (Updated 2011-12-02)</a>
</p>

From chuck at jumis.com  Thu Jul  8 13:49:41 2010
From: chuck at jumis.com (Charles Pritchard)
Date: Thu, 08 Jul 2010 13:49:41 -0700
Subject: [whatwg] Adding descent to TextMetrics
Message-ID: <4C3639E5.6090600@jumis.com>


We've been doing some work with html line boxes; mainly, mixed font 
styles in a text area,
using the HTML Canvas element. While Canvas fillText does have the 
textBaseline attribute,
in order to set the current alignment, it does not provide enough 
metrics through the measureText
function for us to exploit the textBaseline attribute across fonts 
(sizes and styles).

Adding descent, to the measureText object would allow us to do more.
Currently, TextMetrics only returns "width". I'm proposing adding 
"descent" to that list.

-Charles

From dion at almaer.com  Thu Jul  8 14:19:06 2010
From: dion at almaer.com (Dion Almaer)
Date: Thu, 8 Jul 2010 15:19:06 -0600
Subject: [whatwg] Adding descent to TextMetrics
In-Reply-To: <4C3639E5.6090600@jumis.com>
References: <4C3639E5.6090600@jumis.com>
Message-ID: <DC361243-9FF9-4199-A2FE-5F38B267FF11@almaer.com>

And if we are in there... Can we add the other attributes? For height in bespin we resorted to the width of "m" for the font :/

On Jul 8, 2010, at 2:49 PM, Charles Pritchard <chuck at jumis.com> wrote:

> 
> We've been doing some work with html line boxes; mainly, mixed font styles in a text area,
> using the HTML Canvas element. While Canvas fillText does have the textBaseline attribute,
> in order to set the current alignment, it does not provide enough metrics through the measureText
> function for us to exploit the textBaseline attribute across fonts (sizes and styles).
> 
> Adding descent, to the measureText object would allow us to do more.
> Currently, TextMetrics only returns "width". I'm proposing adding "descent" to that list.
> 
> -Charles

From andreas.kling at nokia.com  Thu Jul  8 14:27:41 2010
From: andreas.kling at nokia.com (Andreas Kling)
Date: Thu, 08 Jul 2010 23:27:41 +0200
Subject: [whatwg] Default value of "complete" attribute on new Image objects
Message-ID: <4C3642CD.5030704@nokia.com>

The current HTML5 specification says:

"The IDL attribute complete must return true if the user agent has 
fetched the image specified in the src attribute, and it is in a 
supported image type (i.e. it was decoded without fatal errors), even if 
the final task queued by the networking task source for the fetching of 
the image resource has not yet been processed. Otherwise, the attribute 
must return false." [1]

This reads to me as if a "new Image()" should have complete=false

No browser currently does this AFAIK. I've posted a patch to implement 
this behavior in WebKit here:

https://bugs.webkit.org/show_bug.cgi?id=41898

Does anyone have thoughts on this?
Anything that might break?
Reasons it's currently defaulting to true?

-Kling

[1] http://www.whatwg.org/specs/web-apps/current-work/#dom-img-complete

From Simetrical+w3c at gmail.com  Thu Jul  8 18:09:02 2010
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Thu, 8 Jul 2010 21:09:02 -0400
Subject: [whatwg] More YouTube response
In-Reply-To: <AANLkTikkyHlzH_ke71UXKtMKjJ27yT3A-mSGSYfAPJIU@mail.gmail.com>
References: <AANLkTinbe-p-STmyfGAiGA6NR7cZO-nzqlq405O5gGTd@mail.gmail.com>
	<AANLkTilhe5qKzpIsgTP1NaZd9aYiQJIOa8oBQLqMnJ0p@mail.gmail.com>
	<AANLkTilsTSXqbbGVMfUjHCARImFPR4rFsiwgipaEI1Ge@mail.gmail.com>
	<6829CF63-7A27-43AD-A1E6-1D16C42157F1@apple.com>
	<2137EE0B-8885-4975-BDD6-52415412AE19@apple.com>
	<AANLkTikkyHlzH_ke71UXKtMKjJ27yT3A-mSGSYfAPJIU@mail.gmail.com>
Message-ID: <AANLkTil_oc9bWxmgMiZMI-2LZJvRGEY2L4jgWncsNsUf@mail.gmail.com>

On Wed, Jul 7, 2010 at 4:54 PM, John Harding <jharding at google.com> wrote:
> MySpace is my canonical example - they allow arbitrary SWFs to be embedded
> in profiles, but not <iframe>s. ?Flash added support a while back that
> allows containing pages to block SWFs from executing script or accessing the
> contents of the page, which MySpace enforces by rewriting the <embed> tag
> that users post. ?Before that, yes, allowing arbitrary SWFs to be posted by
> users was a huge security hole.

Interesting.  I wonder what the rationale was behind banning <iframe>.

> Regardless, I think we're all agreed on the path forward (Use <iframe>s to
> embed content instead of naked <embed> tags) and just need to start moving
> on it, and the ball is largely in YouTube's court on this point.

Great to hear you see it that way.

From diego.perini at gmail.com  Fri Jul  9 03:23:21 2010
From: diego.perini at gmail.com (Diego Perini)
Date: Fri, 9 Jul 2010 12:23:21 +0200
Subject: [whatwg] Default value of "complete" attribute on new Image
	objects
In-Reply-To: <4C3642CD.5030704@nokia.com>
References: <4C3642CD.5030704@nokia.com>
Message-ID: <AANLkTilW9F3MGDLCu8IYxVYEYiITPENYJ60YDtmfnAFd@mail.gmail.com>

Just to add that also by using DOM methods like:

   document.createElement('img').complete; // true

the result is the same: "complete" is always true. Only tested on Firefox
3.5.10 and Opera 10.60.

On FF after setting src="" the "complete" property return true while on
Opera it return false.
On FF after setting src="/nonexisting.gif" the "complete" property remains
true like it does in Opera.

Ugh ! Quite an unreliable behaviour... I would expect false in all the above
cases.

Diego Perini


On Thu, Jul 8, 2010 at 11:27 PM, Andreas Kling <andreas.kling at nokia.com>wrote:

> The current HTML5 specification says:
>
> "The IDL attribute complete must return true if the user agent has fetched
> the image specified in the src attribute, and it is in a supported image
> type (i.e. it was decoded without fatal errors), even if the final task
> queued by the networking task source for the fetching of the image resource
> has not yet been processed. Otherwise, the attribute must return false." [1]
>
> This reads to me as if a "new Image()" should have complete=false
>
> No browser currently does this AFAIK. I've posted a patch to implement this
> behavior in WebKit here:
>
> https://bugs.webkit.org/show_bug.cgi?id=41898
>
> Does anyone have thoughts on this?
> Anything that might break?
> Reasons it's currently defaulting to true?
>
> -Kling
>
> [1] http://www.whatwg.org/specs/web-apps/current-work/#dom-img-complete
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100709/a656963a/attachment.htm>

From lachlan.hunt at lachy.id.au  Fri Jul  9 04:19:02 2010
From: lachlan.hunt at lachy.id.au (Lachlan Hunt)
Date: Fri, 09 Jul 2010 13:19:02 +0200
Subject: [whatwg] HTML5 (including next generation additions still in
 development) - Mozilla Firefox (Not Responding)
In-Reply-To: <AANLkTimzzGlW80gpLTsGo_utaUvq7zzeSFon5FDNv5-l@mail.gmail.com>
References: <AANLkTinpaHBTei0tuWGWr6qx-0NKTIPtUQmKudf7TA_P@mail.gmail.com>	<4C35DAA7.4060108@lachy.id.au>
	<AANLkTimzzGlW80gpLTsGo_utaUvq7zzeSFon5FDNv5-l@mail.gmail.com>
Message-ID: <4C3705A6.3020903@lachy.id.au>

On 2010-07-08 19:18, Diego Perini wrote:
> On Thu, Jul 8, 2010 at 4:03 PM, Lachlan Hunt<lachlan.hunt at lachy.id.au>wrote:
>> As a workaround, you can use AdBlock in Firefox to block the offending
>> script.  Just manually add this URL to your block list.
>>
>> http://www.whatwg.org/specs/web-apps/current-work/status.js
>
> The problem is not only with Firefox and it happens I am not only using
> Firefox.
>
> Is there a similar blocking feature of Opera that you can suggest ?

Opera includes a Content Blocker feature by default.  See "Block 
Content..." in the context menu.

-- 
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

From bzbarsky at MIT.EDU  Fri Jul  9 08:46:57 2010
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Fri, 09 Jul 2010 08:46:57 -0700
Subject: [whatwg] Default value of "complete" attribute on new
	Image	objects
In-Reply-To: <AANLkTilW9F3MGDLCu8IYxVYEYiITPENYJ60YDtmfnAFd@mail.gmail.com>
References: <4C3642CD.5030704@nokia.com>
	<AANLkTilW9F3MGDLCu8IYxVYEYiITPENYJ60YDtmfnAFd@mail.gmail.com>
Message-ID: <4C374471.6050604@mit.edu>

On 7/9/10 3:23 AM, Diego Perini wrote:
> On FF after setting src="" the "complete" property return true while on
> Opera it return false.

We special-case src="" and don't do any loading; iirc the spec calls for 
that at this point.

> On FF after setting src="/nonexisting.gif" the "complete" property
> remains true

Were you testing this from a file:// URI or something?  That shouldn't 
happen over http.

-Boris

From diego.perini at gmail.com  Fri Jul  9 13:26:47 2010
From: diego.perini at gmail.com (Diego Perini)
Date: Fri, 9 Jul 2010 22:26:47 +0200
Subject: [whatwg] Default value of "complete" attribute on new Image
	objects
In-Reply-To: <4C374471.6050604@mit.edu>
References: <4C3642CD.5030704@nokia.com>
	<AANLkTilW9F3MGDLCu8IYxVYEYiITPENYJ60YDtmfnAFd@mail.gmail.com>
	<4C374471.6050604@mit.edu>
Message-ID: <AANLkTimlLaqPA_hSjKOb_gTghRaLHH_rNOuxOqm8JJ0V@mail.gmail.com>

On Fri, Jul 9, 2010 at 5:46 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:

> On 7/9/10 3:23 AM, Diego Perini wrote:
>
>> On FF after setting src="" the "complete" property return true while on
>> Opera it return false.
>>
>
> We special-case src="" and don't do any loading; iirc the spec calls for
> that at this point.
>
>
>  On FF after setting src="/nonexisting.gif" the "complete" property
>> remains true
>>
>
> Were you testing this from a file:// URI or something?  That shouldn't
> happen over http.
>
> -Boris
>

No, I tested that using Firebug (and Opera Dragonfly) typing the commands
directly in the console.

Diego Perini
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100709/e37a5734/attachment.htm>

From schalk at ossreleasefeed.com  Sat Jul 10 10:53:32 2010
From: schalk at ossreleasefeed.com (Schalk Neethling)
Date: Sat, 10 Jul 2010 19:53:32 +0200
Subject: [whatwg] Article: Growing pains afflict HTML5 standardization
Message-ID: <000001cb2058$d436c080$7ca44180$@com>

Hi all,

 

Would love to hear everyone's comments on the following article:
http://goo.gl/VNg0

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100710/78a7d1ad/attachment.htm>

From dresende at thinkdigital.pt  Sat Jul 10 12:31:50 2010
From: dresende at thinkdigital.pt (Diogo Resende)
Date: Sat, 10 Jul 2010 20:31:50 +0100
Subject: [whatwg] Article: Growing pains afflict HTML5 standardization
In-Reply-To: <000001cb2058$d436c080$7ca44180$@com>
References: <000001cb2058$d436c080$7ca44180$@com>
Message-ID: <001301cb2066$8b6f20a0$a24d61e0$@pt>

I hate it.

 

From: whatwg-bounces at lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Schalk Neethling
Sent: s?bado, 10 de Julho de 2010 18:54
To: whatwg at whatwg.org
Subject: [whatwg] Article: Growing pains afflict HTML5 standardization

 

Hi all,

 

Would love to hear everyone?s comments on the following article:
http://goo.gl/VNg0

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100710/ee103494/attachment.htm>

From ash at ashleysheridan.co.uk  Sat Jul 10 13:15:19 2010
From: ash at ashleysheridan.co.uk (Ashley Sheridan)
Date: Sat, 10 Jul 2010 21:15:19 +0100
Subject: [whatwg] Article: Growing pains afflict HTML5 standardization
In-Reply-To: <001301cb2066$8b6f20a0$a24d61e0$@pt>
References: <000001cb2058$d436c080$7ca44180$@com>
	<001301cb2066$8b6f20a0$a24d61e0$@pt>
Message-ID: <1278792919.2295.20.camel@localhost>

On Sat, 2010-07-10 at 20:31 +0100, Diogo Resende wrote:
> I hate it.
> 
>  
> 
> 
> From: whatwg-bounces at lists.whatwg.org
> [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Schalk Neethling
> Sent: s?bado, 10 de Julho de 2010 18:54
> To: whatwg at whatwg.org
> Subject: [whatwg] Article: Growing pains afflict HTML5 standardization
> 
> 
> 
>  
> 
> Hi all,
> 
>  
> 
> Would love to hear everyone?s comments on the following article:
> http://goo.gl/VNg0
> 
> 

While I'm not saying your point is right or wrong, maybe something a
little more constructive would help?...

Thanks,
Ash
http://www.ashleysheridan.co.uk


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100710/becd2a9b/attachment.htm>

From rcrisler1 at unl.edu  Sat Jul 10 13:17:44 2010
From: rcrisler1 at unl.edu (Robert J Crisler)
Date: Sat, 10 Jul 2010 15:17:44 -0500
Subject: [whatwg] M
Message-ID: <49269703-AEB3-45AB-BA4B-30BB93B4591B@unl.edu>



Sent from my iPhone

From dhtmlkitchen at gmail.com  Sat Jul 10 21:14:06 2010
From: dhtmlkitchen at gmail.com (Garrett Smith)
Date: Sat, 10 Jul 2010 21:14:06 -0700
Subject: [whatwg] Article: Growing pains afflict HTML5 standardization
In-Reply-To: <000001cb2058$d436c080$7ca44180$@com>
References: <000001cb2058$d436c080$7ca44180$@com>
Message-ID: <AANLkTinPJo2U1C5TMNa5_2Ze-6PGBCSR33LBuYfPfS7n@mail.gmail.com>

On 7/10/10, Schalk Neethling <schalk at ossreleasefeed.com> wrote:
> Hi all,
>
>
>
> Would love to hear everyone's comments on the following article:
> http://goo.gl/VNg0
>
>

The article goes from one thing to another but doesn't make solid
points. I would rather see sectional headings and sections that make a
point. The few headings that you have are improperly capitalized. One
of the headings seems to use an unintentional homonym.

The article starts out by complaining about language. What is your
point about language?

The article could have mentioned the problems with specification
interdependency and the problems with various related w3c groups and
their failings, the political aspects of the W3C and the technical
capacity of its employees and participants

I read where you cited Shelley Powers as a critic of Ian Hickson. I
don't know why this criticism should be considered at all. I read that
you cited Shelley Powers' accomplishments at publishing a large number
of books. I stopped reading at that point.

Although I would rather see technical criticism, that, coming from
cnet.com, would likely come off as hypocritical. Take the HTML, for
example:
http://validator.w3.org/check?uri=http%3A%2F%2Fnews.cnet.com%2F8301-30685_3-20008935-264.html&charset=%28detect+automatically%29&doctype=Inline&group=0

Garrett

From pkasting at google.com  Sat Jul 10 21:36:04 2010
From: pkasting at google.com (Peter Kasting)
Date: Sat, 10 Jul 2010 21:36:04 -0700
Subject: [whatwg] Article: Growing pains afflict HTML5 standardization
In-Reply-To: <AANLkTinPJo2U1C5TMNa5_2Ze-6PGBCSR33LBuYfPfS7n@mail.gmail.com>
References: <000001cb2058$d436c080$7ca44180$@com>
	<AANLkTinPJo2U1C5TMNa5_2Ze-6PGBCSR33LBuYfPfS7n@mail.gmail.com>
Message-ID: <AANLkTilYrgvWA0vyLbOsTLq0VBNFIHyJzHXyCXUqCPJq@mail.gmail.com>

On Sat, Jul 10, 2010 at 9:14 PM, Garrett Smith <dhtmlkitchen at gmail.com>wrote:

> The few headings that you have are improperly capitalized.
>

I think you are mistakenly assuming that the authors of email and article
are the same person.

PK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100710/18907d85/attachment.htm>

From schalk at ossreleasefeed.com  Sun Jul 11 02:10:52 2010
From: schalk at ossreleasefeed.com (Schalk Neethling)
Date: Sun, 11 Jul 2010 11:10:52 +0200
Subject: [whatwg] Article: Growing pains afflict HTML5 standardization
In-Reply-To: <1278792919.2295.20.camel@localhost>
References: <000001cb2058$d436c080$7ca44180$@com>	
	<001301cb2066$8b6f20a0$a24d61e0$@pt>
	<1278792919.2295.20.camel@localhost>
Message-ID: <009901cb20d8$f87d7f30$e9787d90$@com>

Oops, I believe there was a misunderstanding here. I did not write the article ;-) I just read and thought I would like to know everyone else?s view on the list as I do not agree with the author.

 

Kind Regards,

Schalk Neethling

 

From: Ashley Sheridan [mailto:ash at ashleysheridan.co.uk] 
Sent: Saturday, July 10, 2010 10:15 PM
To: Diogo Resende
Cc: 'Schalk Neethling'; whatwg at whatwg.org
Subject: Re: [whatwg] Article: Growing pains afflict HTML5 standardization

 

On Sat, 2010-07-10 at 20:31 +0100, Diogo Resende wrote: 

I hate it.

 

From: whatwg-bounces at lists.whatwg.org [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Schalk Neethling
Sent: s?bado, 10 de Julho de 2010 18:54
To: whatwg at whatwg.org
Subject: [whatwg] Article: Growing pains afflict HTML5 standardization



 

Hi all,

 

Would love to hear everyone?s comments on the following article: http://goo.gl/VNg0




While I'm not saying your point is right or wrong, maybe something a little more constructive would help?...


Thanks,
Ash
http://www.ashleysheridan.co.uk



 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100711/4ed9d1b7/attachment.htm>

From Simetrical+w3c at gmail.com  Sun Jul 11 13:44:42 2010
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Sun, 11 Jul 2010 16:44:42 -0400
Subject: [whatwg] Article: Growing pains afflict HTML5 standardization
In-Reply-To: <000001cb2058$d436c080$7ca44180$@com>
References: <AcsgWM+uIM1dbbCHQai0Vu1+y51xNA==>
	<000001cb2058$d436c080$7ca44180$@com>
Message-ID: <AANLkTinZWoXZSV3twXOPEuRjLVBZi8ldjE2J2q-bSY7g@mail.gmail.com>

On Sat, Jul 10, 2010 at 1:53 PM, Schalk Neethling
<schalk at ossreleasefeed.com> wrote:
> Would love to hear everyone?s comments on the following article:
> http://goo.gl/VNg0

Seems basically accurate.  I didn't spot anything specific that I'd
say was wrong or misleading.

From dhtmlkitchen at gmail.com  Sun Jul 11 15:13:56 2010
From: dhtmlkitchen at gmail.com (Garrett Smith)
Date: Sun, 11 Jul 2010 15:13:56 -0700
Subject: [whatwg] Article: Growing pains afflict HTML5 standardization
In-Reply-To: <009901cb20d8$f87d7f30$e9787d90$@com>
References: <000001cb2058$d436c080$7ca44180$@com>
	<001301cb2066$8b6f20a0$a24d61e0$@pt>
	<1278792919.2295.20.camel@localhost>
	<009901cb20d8$f87d7f30$e9787d90$@com>
Message-ID: <AANLkTikKBc7aiuwDZeTv6IWzD7HsgO4vi9qesV2E8awt@mail.gmail.com>

On 7/11/10, Schalk Neethling <schalk at ossreleasefeed.com> wrote:
> Oops, I believe there was a misunderstanding here. I did not write the
> article ;-) I just read and thought I would like to know everyone else?s
> view on the list as I do not agree with the author.
>

Got it, I didn't really consider about that in my reply, just
basically responded to the author. I should have made everything as
third person, as:

"The author/article states [thing], instead, [alternative]".

Garrett

From julian.reschke at gmx.de  Mon Jul 12 00:30:33 2010
From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon, 12 Jul 2010 09:30:33 +0200
Subject: [whatwg] Article: Growing pains afflict HTML5 standardization
In-Reply-To: <AANLkTinPJo2U1C5TMNa5_2Ze-6PGBCSR33LBuYfPfS7n@mail.gmail.com>
References: <000001cb2058$d436c080$7ca44180$@com>
	<AANLkTinPJo2U1C5TMNa5_2Ze-6PGBCSR33LBuYfPfS7n@mail.gmail.com>
Message-ID: <4C3AC499.7000806@gmx.de>

On 11.07.2010 06:14, Garrett Smith wrote:
> ...
> I read where you cited Shelley Powers as a critic of Ian Hickson. I
> don't know why this criticism should be considered at all. I read that
> you cited Shelley Powers' accomplishments at publishing a large number
> of books. I stopped reading at that point.
> ...

This in an article that reports on the problems of the WGs involved in 
HTML. I really do believe that talking to Shelley (among others) and 
citing her is the right thing to do. YMMV.

> Although I would rather see technical criticism, that, coming from
> cnet.com, would likely come off as hypocritical. Take the HTML, for
> example:
> http://validator.w3.org/check?uri=http%3A%2F%2Fnews.cnet.com%2F8301-30685_3-20008935-264.html&charset=%28detect+automatically%29&doctype=Inline&group=0

Google: 
<http://validator.w3.org/check?uri=http%3A%2F%2Fwww.google.com&charset=%28detect+automatically%29&doctype=Inline&group=0> 
- 35 errors

Just saying.

Best regards, Julian

From mike at mikewilcox.net  Mon Jul 12 05:44:07 2010
From: mike at mikewilcox.net (Mike Wilcox)
Date: Mon, 12 Jul 2010 07:44:07 -0500
Subject: [whatwg] Article: Growing pains afflict HTML5 standardization
In-Reply-To: <4C3AC499.7000806@gmx.de>
References: <000001cb2058$d436c080$7ca44180$@com>
	<AANLkTinPJo2U1C5TMNa5_2Ze-6PGBCSR33LBuYfPfS7n@mail.gmail.com>
	<4C3AC499.7000806@gmx.de>
Message-ID: <1745C9B4-A201-4CD6-8463-A34E27343B00@mikewilcox.net>

On Jul 12, 2010, at 2:30 AM, Julian Reschke wrote:
> Google: <http://validator.w3.org/check?uri=http%3A%2F%2Fwww.google.com&charset=%28detect+automatically%29&doctype=Inline&group=0> - 35 errors

That's a little different. Google purposely uses unstandardized, incorrect HTML in ways that still render in a browser in order to make it more difficult for screen scrapers. They also "break it" in a different way every week.

Mike Wilcox
http://clubajax.org
mike at mikewilcox.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100712/5512c8b5/attachment.htm>

From julian.reschke at gmx.de  Mon Jul 12 05:58:51 2010
From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon, 12 Jul 2010 14:58:51 +0200
Subject: [whatwg] Article: Growing pains afflict HTML5 standardization
In-Reply-To: <1745C9B4-A201-4CD6-8463-A34E27343B00@mikewilcox.net>
References: <000001cb2058$d436c080$7ca44180$@com>	<AANLkTinPJo2U1C5TMNa5_2Ze-6PGBCSR33LBuYfPfS7n@mail.gmail.com>	<4C3AC499.7000806@gmx.de>
	<1745C9B4-A201-4CD6-8463-A34E27343B00@mikewilcox.net>
Message-ID: <4C3B118B.2030502@gmx.de>

On 12.07.2010 14:44, Mike Wilcox wrote:
> On Jul 12, 2010, at 2:30 AM, Julian Reschke wrote:
>> Google:
>> <http://validator.w3.org/check?uri=http%3A%2F%2Fwww.google.com&charset=%28detect+automatically%29&doctype=Inline&group=0
>> <http://validator.w3.org/check?uri=http%3A%2F%2Fwww.google.com&charset=%28detect+automatically%29&doctype=Inline&group=0>>
>> - 35 errors
>
> That's a little different. Google purposely uses unstandardized,
> incorrect HTML in ways that still render in a browser in order to make
> it more difficult for screen scrapers. They also "break it" in a
> different way every week.

How exactly is it different?

Do you think that what Google does somehow is "better"?

Just asking.

As far as I can tell, it just shows that content providers continue to 
send whatever happens to work, thus are not concerned at all about 
validity (note: there's a permathread about this as well -- why disallow 
things that are known the work reliably...).

Best regards, Julian

From mike at mikewilcox.net  Mon Jul 12 06:16:44 2010
From: mike at mikewilcox.net (Mike Wilcox)
Date: Mon, 12 Jul 2010 08:16:44 -0500
Subject: [whatwg] Article: Growing pains afflict HTML5 standardization
In-Reply-To: <4C3B118B.2030502@gmx.de>
References: <000001cb2058$d436c080$7ca44180$@com>	<AANLkTinPJo2U1C5TMNa5_2Ze-6PGBCSR33LBuYfPfS7n@mail.gmail.com>	<4C3AC499.7000806@gmx.de>
	<1745C9B4-A201-4CD6-8463-A34E27343B00@mikewilcox.net>
	<4C3B118B.2030502@gmx.de>
Message-ID: <42B40833-210E-4FC5-9919-87911277AC00@mikewilcox.net>


On Jul 12, 2010, at 7:58 AM, Julian Reschke wrote:

> On 12.07.2010 14:44, Mike Wilcox wrote:
>> On Jul 12, 2010, at 2:30 AM, Julian Reschke wrote:
>>> Google:
>>> <http://validator.w3.org/check?uri=http%3A%2F%2Fwww.google.com&charset=%28detect+automatically%29&doctype=Inline&group=0
>>> <http://validator.w3.org/check?uri=http%3A%2F%2Fwww.google.com&charset=%28detect+automatically%29&doctype=Inline&group=0>>
>>> - 35 errors
>> 
>> That's a little different. Google purposely uses unstandardized,
>> incorrect HTML in ways that still render in a browser in order to make
>> it more difficult for screen scrapers. They also "break it" in a
>> different way every week.
> 
> How exactly is it different?
> 
> Do you think that what Google does somehow is "better"?
> 
> Just asking.

Not better... on purpose. Proactive sabotage if you will.

> 
> As far as I can tell, it just shows that content providers continue to send whatever happens to work, thus are not concerned at all about validity (note: there's a permathread about this as well -- why disallow things that are known the work reliably...).

I agree, and some pages I've seen and used makes my head want to burst. Clients will tell me "Don't give us code that slows down our page!" and I look at their code and I think "Really?"

In defense of CNET, I looked at the source code and it's not the worst markup I've seen. I looked at the validation errors again, and a vast amount of them are caused by ad services and social network plugins. 

That's still a problem (also one to burst my head), but a different problem.

Mike


From nils-dagsson-moskopp at dieweltistgarnichtso.net  Mon Jul 12 06:39:20 2010
From: nils-dagsson-moskopp at dieweltistgarnichtso.net (Nils Dagsson Moskopp)
Date: Mon, 12 Jul 2010 15:39:20 +0200
Subject: [whatwg] Article: Growing pains afflict HTML5 standardization
In-Reply-To: <1745C9B4-A201-4CD6-8463-A34E27343B00@mikewilcox.net>
References: <000001cb2058$d436c080$7ca44180$@com>
	<AANLkTinPJo2U1C5TMNa5_2Ze-6PGBCSR33LBuYfPfS7n@mail.gmail.com>
	<4C3AC499.7000806@gmx.de>
	<1745C9B4-A201-4CD6-8463-A34E27343B00@mikewilcox.net>
Message-ID: <20100712153920.2ffd3947@desudesudesu>

Mike Wilcox <mike at mikewilcox.net> schrieb am Mon, 12 Jul 2010 07:44:07
-0500:

> That's a little different. Google purposely uses unstandardized,
> incorrect HTML in ways that still render in a browser in order to
> make it more difficult for screen scrapers. They also "break it" in a
> different way every week.

Assuming this is true (which I find difficult to believe), wouldn't a
screen scraper based on the HTML5 parsing algorithm defeat this
purpose ?

Greetings,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 230 bytes
Desc: not available
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100712/21a6c0d0/attachment.pgp>

From mike at mikewilcox.net  Mon Jul 12 07:43:14 2010
From: mike at mikewilcox.net (Mike Wilcox)
Date: Mon, 12 Jul 2010 09:43:14 -0500
Subject: [whatwg] Article: Growing pains afflict HTML5 standardization
In-Reply-To: <20100712153920.2ffd3947@desudesudesu>
References: <000001cb2058$d436c080$7ca44180$@com>
	<AANLkTinPJo2U1C5TMNa5_2Ze-6PGBCSR33LBuYfPfS7n@mail.gmail.com>
	<4C3AC499.7000806@gmx.de>
	<1745C9B4-A201-4CD6-8463-A34E27343B00@mikewilcox.net>
	<20100712153920.2ffd3947@desudesudesu>
Message-ID: <B9B3E67C-C74B-4F06-AA92-B8FA7935EF8F@mikewilcox.net>

On Jul 12, 2010, at 8:39 AM, Nils Dagsson Moskopp wrote:
> 
>> That's a little different. Google purposely uses unstandardized,
>> incorrect HTML in ways that still render in a browser in order to
>> make it more difficult for screen scrapers. They also "break it" in a
>> different way every week.
> 
> Assuming this is true (which I find difficult to believe), wouldn't a
> screen scraper based on the HTML5 parsing algorithm defeat this
> purpose ?

Honestly, I don't know. But W3 defaulted to an HTML5 validator:
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.google.com%2Fsearch%3Fsource%3Dig%26hl%3Den%26rlz%3D%26%3D%26q%3Dhtml5%26aq%3Df%26aqi%3D%26aql%3D%26oq%3D%26gs_rfai%3D&charset=%28detect+automatically%29&doctype=Inline&group=0

On Jul 12, 2010, at 7:55 AM, Julian Reschke wrote:
> 
> Any evidence for this? And how do you know the reason for CNET isn't the same?
> 
> VERY unconvinced.

Such skepticism! I really didn't expect that I said anything controversial. We all know Google is a black box, and I don't, nor have I ever worked for them, so I can't testify that what I say is a fact...

Google does not publish a full API for their search results in spite of the fact that they publish most everything else. That's because their search results / API is their golden egg ? they can't give that away. And they need to protect it. I've tried scraping results with YQL and it failed. I made other attempts that had more success only to find they did not work a week later.

Studying the validation results more closely however does not back up my original statement ? the markup does look as I described, but the things I expected to break the validator are not what I expected. The things I had in mind was for the most part unclosed tags, which I didn't know validated. I knew they were allowed, but thought the validator would complain.


Besides the protecting of their API, Google also will scratch and claw to save every byte. They are the gold standard of a high performance website.  While this may or may not explain the things that don't validate, what it does say is that nothing coming from google.com is accidental.

Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100712/2efb59cb/attachment-0001.htm>

From julian.reschke at gmx.de  Mon Jul 12 08:41:36 2010
From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon, 12 Jul 2010 17:41:36 +0200
Subject: [whatwg] Article: Growing pains afflict HTML5 standardization
In-Reply-To: <B9B3E67C-C74B-4F06-AA92-B8FA7935EF8F@mikewilcox.net>
References: <000001cb2058$d436c080$7ca44180$@com>	<AANLkTinPJo2U1C5TMNa5_2Ze-6PGBCSR33LBuYfPfS7n@mail.gmail.com>	<4C3AC499.7000806@gmx.de>	<1745C9B4-A201-4CD6-8463-A34E27343B00@mikewilcox.net>	<20100712153920.2ffd3947@desudesudesu>
	<B9B3E67C-C74B-4F06-AA92-B8FA7935EF8F@mikewilcox.net>
Message-ID: <4C3B37B0.3040008@gmx.de>

On 12.07.2010 16:43, Mike Wilcox wrote:
> On Jul 12, 2010, at 8:39 AM, Nils Dagsson Moskopp wrote:
>>
>>> That's a little different. Google purposely uses unstandardized,
>>> incorrect HTML in ways that still render in a browser in order to
>>> make it more difficult for screen scrapers. They also "break it" in a
>>> different way every week.
>>
>> Assuming this is true (which I find difficult to believe), wouldn't a
>> screen scraper based on the HTML5 parsing algorithm defeat this
>> purpose ?
>
> Honestly, I don't know. But W3 defaulted to an HTML5 validator:
> http://validator.w3.org/check?uri=http%3A%2F%2Fwww.google.com%2Fsearch%3Fsource%3Dig%26hl%3Den%26rlz%3D%26%3D%26q%3Dhtml5%26aq%3Df%26aqi%3D%26aql%3D%26oq%3D%26gs_rfai%3D&charset=%28detect+automatically%29&doctype=Inline&group=0
> <http://validator.w3.org/check?uri=http%3A%2F%2Fwww.google.com%2Fsearch%3Fsource%3Dig%26hl%3Den%26rlz%3D%26%3D%26q%3Dhtml5%26aq%3Df%26aqi%3D%26aql%3D%26oq%3D%26gs_rfai%3D&charset=%28detect+automatically%29&doctype=Inline&group=0>

True, but a parser conforming to the spec (*) would handle those errors, 
so in this case obfuscation wouldn't work. Essentially, any code using 
that parser would see the same information as an off-the-shelf web browser.

> ...
> Besides the protecting of their API, Google also will scratch and claw
> to save every byte. They are the gold standard of a high performance

Understood. There's an ongoing controversy whether it makes sense to 
make things like these invalid (just stating, not offering an opinion).

> website. While this may or may not explain the things that don't
> validate, what it does say is that nothing coming from google.com
> <http://google.com> is accidental.
> ...

I believe some time ago a certain Google employee actually *did* state 
that some of the conformance problems were unintentional. (yes, I did 
spend a few minutes finding that statement but wasn't successful).

Best regards, Julian

(*) Implementing error recovery, which IMHO isn't required.

From rubys at intertwingly.net  Mon Jul 12 09:03:43 2010
From: rubys at intertwingly.net (Sam Ruby)
Date: Mon, 12 Jul 2010 12:03:43 -0400
Subject: [whatwg] Article: Growing pains afflict HTML5 standardization
In-Reply-To: <4C3B37B0.3040008@gmx.de>
References: <000001cb2058$d436c080$7ca44180$@com>
	<AANLkTinPJo2U1C5TMNa5_2Ze-6PGBCSR33LBuYfPfS7n@mail.gmail.com>
	<4C3AC499.7000806@gmx.de>
	<1745C9B4-A201-4CD6-8463-A34E27343B00@mikewilcox.net>
	<20100712153920.2ffd3947@desudesudesu>
	<B9B3E67C-C74B-4F06-AA92-B8FA7935EF8F@mikewilcox.net>
	<4C3B37B0.3040008@gmx.de>
Message-ID: <AANLkTimP-BSr73lNh8ul9KvaEgpaQ7shRmaA6oXit9ZF@mail.gmail.com>

On Mon, Jul 12, 2010 at 11:41 AM, Julian Reschke <julian.reschke at gmx.de> wrote:
> On 12.07.2010 16:43, Mike Wilcox wrote:
>>
>> On Jul 12, 2010, at 8:39 AM, Nils Dagsson Moskopp wrote:
>>>
>>>> That's a little different. Google purposely uses unstandardized,
>>>> incorrect HTML in ways that still render in a browser in order to
>>>> make it more difficult for screen scrapers. They also "break it" in a
>>>> different way every week.
>>>
>>> Assuming this is true (which I find difficult to believe), wouldn't a
>>> screen scraper based on the HTML5 parsing algorithm defeat this
>>> purpose ?
>>
>> Honestly, I don't know. But W3 defaulted to an HTML5 validator:
>>
>> http://validator.w3.org/check?uri=http%3A%2F%2Fwww.google.com%2Fsearch%3Fsource%3Dig%26hl%3Den%26rlz%3D%26%3D%26q%3Dhtml5%26aq%3Df%26aqi%3D%26aql%3D%26oq%3D%26gs_rfai%3D&charset=%28detect+automatically%29&doctype=Inline&group=0
>>
>> <http://validator.w3.org/check?uri=http%3A%2F%2Fwww.google.com%2Fsearch%3Fsource%3Dig%26hl%3Den%26rlz%3D%26%3D%26q%3Dhtml5%26aq%3Df%26aqi%3D%26aql%3D%26oq%3D%26gs_rfai%3D&charset=%28detect+automatically%29&doctype=Inline&group=0>
>
> True, but a parser conforming to the spec (*) would handle those errors, so
> in this case obfuscation wouldn't work. Essentially, any code using that
> parser would see the same information as an off-the-shelf web browser.
>
>> ...
>> Besides the protecting of their API, Google also will scratch and claw
>> to save every byte. They are the gold standard of a high performance
>
> Understood. There's an ongoing controversy whether it makes sense to make
> things like these invalid (just stating, not offering an opinion).
>
>> website. While this may or may not explain the things that don't
>> validate, what it does say is that nothing coming from google.com
>> <http://google.com> is accidental.
>> ...
>
> I believe some time ago a certain Google employee actually *did* state that
> some of the conformance problems were unintentional. (yes, I did spend a few
> minutes finding that statement but wasn't successful).

http://lists.w3.org/Archives/Public/public-html/2010Mar/0555.html

> Best regards, Julian
>
> (*) Implementing error recovery, which IMHO isn't required.

- Sam Ruby

From liachen at rim.com  Mon Jul 12 13:11:48 2010
From: liachen at rim.com (Lianghui Chen)
Date: Mon, 12 Jul 2010 16:11:48 -0400
Subject: [whatwg] About bypassing caches for URLs listed in Fallback and/or
 Network section in a HTML5 Offline Web Application
Message-ID: <BB31C4AB95A70042A256109D4619912601828EC1@XCH117CNC.rim.net>


Hi,

In spec HTML5 for offline web application (http://www.whatwg.org/specs/web-apps/current-work/#offline) chapter 6.6.6, item 3, 4, 5 state that for resources that is in online whitelist (or has wildcard whitelist), or fallback list, it should be fetched "normally".

I would like to know does it mean the user agent (browser) should bypass its own caches (besides html5 appcache), like the WebKit cache and browser http stack cache?

Best Regards
Lyon Chen

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100712/a0aefca9/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 92 bytes
Desc: image001.gif
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100712/a0aefca9/attachment.gif>

From ian at hixie.ch  Mon Jul 12 16:00:33 2010
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 12 Jul 2010 23:00:33 +0000 (UTC)
Subject: [whatwg] Article: Growing pains afflict HTML5 standardization
In-Reply-To: <000001cb2058$d436c080$7ca44180$@com>
References: <000001cb2058$d436c080$7ca44180$@com>
Message-ID: <Pine.LNX.4.64.1007122252480.15100@ps20323.dreamhostps.com>


I'd like to encourage everyone on this thread to please remember that the 
topic of this mailing list is technical discussion of HTML itself, not 
discussion about discussion, or as in this case, discussion about 
discussion (an article) of discussion (arguments mentioned in the 
article). Let's please focus on specific technical matters that can 
actually improve the Web, rather than process issues.

If you would like to discuss the article in question, it has a comments 
section for this very purpose. There's also an "off topic" section on the 
WHATWG forums:

   http://forums.whatwg.org/

As HTML returns to the media limelight it held in the late 90s, people may 
be interested in discussing the coverage more and more. Similarly, people 
may be interested in discussing the "inside baseball" matters such as the 
various decision policies in place around this work. If there is demand 
for it, I'd be happy to create a mailing list for the purpose of 
discussing these matters on the WHATWG servers. Please let me know if this 
is something you'd be interested in.

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

From jthoma12 at calpoly.edu  Mon Jul 12 19:58:03 2010
From: jthoma12 at calpoly.edu (Joseph Thomas)
Date: Mon, 12 Jul 2010 19:58:03 -0700
Subject: [whatwg] whatwg Digest (and how it is full of political BS)
Message-ID: <AANLkTinFjU7LUrnIlMoSA3HVQpdyp_WfRUSKQUadmVHK@mail.gmail.com>

Occasionally, I notice that a single conversation completely dominates
my digest emails for this group. At the moment, it is "Growing Pains",
in the past it has been called other things, but it all amounts to the
same thing: useless politics.

Can we migrate these discussions to another list? Whatwg-politburro or
some such? Maybe then there will be a place to discuss, you know, spec
writing and features being worked on in peace. Instead, I have to scan
through pages upon pages of WC3'ers whining about Hixie actually
getting shit done.

From levin at chromium.org  Mon Jul 12 20:12:41 2010
From: levin at chromium.org (David Levin)
Date: Mon, 12 Jul 2010 20:12:41 -0700
Subject: [whatwg] whatwg Digest (and how it is full of political BS)
In-Reply-To: <AANLkTinFjU7LUrnIlMoSA3HVQpdyp_WfRUSKQUadmVHK@mail.gmail.com>
References: <AANLkTinFjU7LUrnIlMoSA3HVQpdyp_WfRUSKQUadmVHK@mail.gmail.com>
Message-ID: <AANLkTikow_JtIen9faLO7kaOayWdo6AV8XQqtqqlUp5S@mail.gmail.com>

I believe this has already been addressed in that thread which I guess
you'll get in the next digest.

Now back to getting things done.

On Mon, Jul 12, 2010 at 7:58 PM, Joseph Thomas <jthoma12 at calpoly.edu> wrote:

> Occasionally, I notice that a single conversation completely dominates
> my digest emails for this group. At the moment, it is "Growing Pains",
> in the past it has been called other things, but it all amounts to the
> same thing: useless politics.
>
> Can we migrate these discussions to another list? Whatwg-politburro or
> some such? Maybe then there will be a place to discuss, you know, spec
> writing and features being worked on in peace. Instead, I have to scan
> through pages upon pages of WC3'ers whining about Hixie actually
> getting shit done.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100712/80dac53e/attachment.htm>

From gphemsley at gmail.com  Mon Jul 12 23:31:19 2010
From: gphemsley at gmail.com (Gordon P. Hemsley)
Date: Tue, 13 Jul 2010 02:31:19 -0400
Subject: [whatwg] Proposal: @srctype or @type on <iframe>
Message-ID: <AANLkTik7SGts2vHBz95YdKhEH3wwIRd3OCXXNFAYnIYQ@mail.gmail.com>

Hello all.

There a number of attributes that are designed to give the user agent a
preview of what MIME type to except for referenced resource. (And there are
also attributes like @hreflang that preview other things.) And yet,
<iframe>, which has to load a full document, has no ability to allow the
user agent to determine compatibility.

Thus, I propose doing one of the following:
(1) add @srctype to <iframe>
(2) extend the meaning of @type that applies to <a>, <area>, and <link> to
apply to <iframe>, as well

I'm more inclined to believe that option (2) is the better option.

But now for the reasoning.

It should not be assumed that whatever resource included via <iframe> is
going to be of type 'text/html' or another easily parsable type. Thus, it
could be helpful for the author to give the user agent a hint as to what
type of document it is requesting be displayed inline, and allow the user
agent to choose not to display the contents of the <iframe> if it feels it
cannot support it.

The particular use case that prompted me to think about this is including a
PDF via <iframe>. In Firefox (last I checked), one is required to install a
separate add-on in order to support in-browser display of PDF files on Mac
OS X, since there is no native or integrated Adobe Reader support available.
Without the add-on, the user will be prompted to download the PDF file,
which can be very disconcerting if the user wasn't even expecting a PDF
file. And I'm sure there are plenty of other instances where this same
situation occurs. (TIFF files, perhaps? Like on the U.S. Patent Office's
website?)

Now, I'm not a spec implementor by any means, but I am a web author and a
web user, so I've been on both sides of this issue. And it doesn't appear
that it would be too complicated to extend the existing support of @type.

Thoughts?

Gordon

-- 
Gordon P. Hemsley
me at gphemsley.org
http://gphemsley.org/ ? http://gphemsley.org/blog/
http://sasha.sourceforge.net/ ? http://www.yoursasha.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100713/40743eef/attachment.htm>

From nils-dagsson-moskopp at dieweltistgarnichtso.net  Mon Jul 12 23:48:46 2010
From: nils-dagsson-moskopp at dieweltistgarnichtso.net (Nils Dagsson Moskopp)
Date: Tue, 13 Jul 2010 08:48:46 +0200
Subject: [whatwg] Proposal: @srctype or @type on <iframe>
In-Reply-To: <AANLkTik7SGts2vHBz95YdKhEH3wwIRd3OCXXNFAYnIYQ@mail.gmail.com>
References: <AANLkTik7SGts2vHBz95YdKhEH3wwIRd3OCXXNFAYnIYQ@mail.gmail.com>
Message-ID: <20100713084846.58acc196@desudesudesu>

"Gordon P. Hemsley" <gphemsley at gmail.com> schrieb am Tue, 13 Jul 2010
02:31:19 -0400:

> It should not be assumed that whatever resource included via <iframe>
> is going to be of type 'text/html' or another easily parsable type.
> Thus, it could be helpful for the author to give the user agent a
> hint as to what type of document it is requesting be displayed
> inline, and allow the user agent to choose not to display the
> contents of the <iframe> if it feels it cannot support it.

Have you thought of using HTTP Content-Type headers and classic MIME
type handling to determine compatibility ?

> [?]
> 
> Now, I'm not a spec implementor by any means, but I am a web author
> and a web user, so I've been on both sides of this issue. And it
> doesn't appear that it would be too complicated to extend the
> existing support of @type.

AFAIK, implementors could use HTTP Content-Type headers for the given
purpose.

> Thoughts?

Why do you hate HTTP Content-Type headers ? ;)


Cheers,
Nils
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 230 bytes
Desc: not available
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100713/b9454fe8/attachment-0001.pgp>

From gphemsley at gmail.com  Mon Jul 12 23:53:16 2010
From: gphemsley at gmail.com (Gordon P. Hemsley)
Date: Tue, 13 Jul 2010 02:53:16 -0400
Subject: [whatwg] Proposal: @srctype or @type on <iframe>
In-Reply-To: <20100713084846.58acc196@desudesudesu>
References: <AANLkTik7SGts2vHBz95YdKhEH3wwIRd3OCXXNFAYnIYQ@mail.gmail.com> 
	<20100713084846.58acc196@desudesudesu>
Message-ID: <AANLkTimo3PWyJxP-Z99QrCl61LHYIudjz9btLZndxWfh@mail.gmail.com>

Nils,

I don't hate the HTTP Content-Type header. In fact, I like it very much.

But this proposal was intended to guide the user agent before they
ever receive the HTTP Content-Type header. ;)

Cheers,
Gordon

On Tue, Jul 13, 2010 at 2:48 AM, Nils Dagsson Moskopp
<nils-dagsson-moskopp at dieweltistgarnichtso.net> wrote:
> "Gordon P. Hemsley" <gphemsley at gmail.com> schrieb am Tue, 13 Jul 2010
> 02:31:19 -0400:
>
>> It should not be assumed that whatever resource included via <iframe>
>> is going to be of type 'text/html' or another easily parsable type.
>> Thus, it could be helpful for the author to give the user agent a
>> hint as to what type of document it is requesting be displayed
>> inline, and allow the user agent to choose not to display the
>> contents of the <iframe> if it feels it cannot support it.
>
> Have you thought of using HTTP Content-Type headers and classic MIME
> type handling to determine compatibility ?
>
>> [?]
>>
>> Now, I'm not a spec implementor by any means, but I am a web author
>> and a web user, so I've been on both sides of this issue. And it
>> doesn't appear that it would be too complicated to extend the
>> existing support of @type.
>
> AFAIK, implementors could use HTTP Content-Type headers for the given
> purpose.
>
>> Thoughts?
>
> Why do you hate HTTP Content-Type headers ? ;)
>
>
> Cheers,
> Nils
>



-- 
Gordon P. Hemsley
me at gphemsley.org
http://gphemsley.org/ ? http://gphemsley.org/blog/
http://sasha.sourceforge.net/ ? http://www.yoursasha.com/

From bzbarsky at MIT.EDU  Tue Jul 13 00:26:53 2010
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Tue, 13 Jul 2010 00:26:53 -0700
Subject: [whatwg] Proposal: @srctype or @type on <iframe>
In-Reply-To: <AANLkTik7SGts2vHBz95YdKhEH3wwIRd3OCXXNFAYnIYQ@mail.gmail.com>
References: <AANLkTik7SGts2vHBz95YdKhEH3wwIRd3OCXXNFAYnIYQ@mail.gmail.com>
Message-ID: <4C3C153D.2010406@mit.edu>

On 7/12/10 11:31 PM, Gordon P. Hemsley wrote:
> The particular use case that prompted me to think about this is
> including a PDF via <iframe>. In Firefox (last I checked), one is
> required to install a separate add-on in order to support in-browser
> display of PDF files on Mac OS X, since there is no native or integrated
> Adobe Reader support available.

I'm pretty sure you can install the Adobe Reader plug-in on Mac if you 
want to.

> Without the add-on, the user will be prompted to download the PDF file

Which is exactly what would happen for a type="application/pdf" iframe, 
no?  Silently not showing the content doesn't seem acceptable.

-Boris

From gphemsley at gmail.com  Tue Jul 13 00:45:55 2010
From: gphemsley at gmail.com (Gordon P. Hemsley)
Date: Tue, 13 Jul 2010 03:45:55 -0400
Subject: [whatwg] Proposal: @srctype or @type on <iframe>
In-Reply-To: <4C3C153D.2010406@mit.edu>
References: <AANLkTik7SGts2vHBz95YdKhEH3wwIRd3OCXXNFAYnIYQ@mail.gmail.com> 
	<4C3C153D.2010406@mit.edu>
Message-ID: <AANLkTikMDEQsoEaQIsk15CkGo53398xOk-NMWFdOdP3D@mail.gmail.com>

On Tue, Jul 13, 2010 at 3:26 AM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> On 7/12/10 11:31 PM, Gordon P. Hemsley wrote:
>>
>> The particular use case that prompted me to think about this is
>> including a PDF via <iframe>. In Firefox (last I checked), one is
>> required to install a separate add-on in order to support in-browser
>> display of PDF files on Mac OS X, since there is no native or integrated
>> Adobe Reader support available.
>
> I'm pretty sure you can install the Adobe Reader plug-in on Mac if you want
> to.

Perhaps now, but that wasn't always the case?at least not for Firefox.
I admit that my experience is somewhat outdated. Installing the
third-party PDF viewer add-on is one of the first things I did, in a
"set it and forget it" kind of way. (Plus, I'm still on Tiger.)

But, again, the PDF example was just one possible use case. I'm sure
there are plenty of other file types that cause similar situations,
including the TIFF issue that I mentioned.

>> Without the add-on, the user will be prompted to download the PDF file
>
> Which is exactly what would happen for a type="application/pdf" iframe, no?
> ?Silently not showing the content doesn't seem acceptable.
>
> -Boris
>
Well, the idea is to have the browser operate more intelligently than
that. The page in the iframe is (by definition) not the primary
document that the user is trying to load, so it shouldn't have the
power steal the user's attention immediately upon page load. It would
be very disorienting, and would likely cause the user to lose their
train of thought.

I was thinking more along the lines of Flashblock does or what happens
when the window in an <iframe> can't load: The content would be
replaced somehow by a message and a button/link to allow the user to
manually download the contents of the iframe, if they so choose. It
shouldn't make that decision for the user, as it's not the user's
fault that their browser does not support the format of some ancillary
document.

At least, that's how I see it.

Gordon

-- 
Gordon P. Hemsley
me at gphemsley.org
http://gphemsley.org/ ? http://gphemsley.org/blog/
http://sasha.sourceforge.net/ ? http://www.yoursasha.com/

From bzbarsky at MIT.EDU  Tue Jul 13 01:10:34 2010
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Tue, 13 Jul 2010 01:10:34 -0700
Subject: [whatwg] Proposal: @srctype or @type on <iframe>
In-Reply-To: <AANLkTikMDEQsoEaQIsk15CkGo53398xOk-NMWFdOdP3D@mail.gmail.com>
References: <AANLkTik7SGts2vHBz95YdKhEH3wwIRd3OCXXNFAYnIYQ@mail.gmail.com>
	<4C3C153D.2010406@mit.edu>
	<AANLkTikMDEQsoEaQIsk15CkGo53398xOk-NMWFdOdP3D@mail.gmail.com>
Message-ID: <4C3C1F7A.5040403@mit.edu>

On 7/13/10 12:45 AM, Gordon P. Hemsley wrote:
> Well, the idea is to have the browser operate more intelligently than
> that. The page in the iframe is (by definition) not the primary
> document that the user is trying to load

Unfortunately, on many websites this is false.  That is, the whole 
purpose of the site is to show some non-HTML content to the user, and it 
chooses to do it by sticking it in an iframe....

-Boris

From marques at displague.com  Tue Jul 13 04:37:04 2010
From: marques at displague.com (Marques Johansson)
Date: Tue, 13 Jul 2010 07:37:04 -0400
Subject: [whatwg] Proposal: @srctype or @type on <iframe>
In-Reply-To: <AANLkTikMDEQsoEaQIsk15CkGo53398xOk-NMWFdOdP3D@mail.gmail.com>
References: <AANLkTik7SGts2vHBz95YdKhEH3wwIRd3OCXXNFAYnIYQ@mail.gmail.com> 
	<4C3C153D.2010406@mit.edu>
	<AANLkTikMDEQsoEaQIsk15CkGo53398xOk-NMWFdOdP3D@mail.gmail.com>
Message-ID: <AANLkTik0g9IYZayZLKOTuvoBxPVh8q-sV8yU2tbKYklR@mail.gmail.com>

In one of the video related threads someone from Opera said that browsers
have a rough time trying to figure out how to intelligently handle video
content fetches.  I think that a type suggestion, before the Content-type
could help a browser use a more optimal fetch behavior.

If the type of a resource is predefined then the browser can do a partial
request to fetch the meta data of the alleged file format and in the case of
a PDF perhaps the first few pages of content, leaving the rest to be loaded
on demand as the content is scrolled / paginated.  I don't know if this is
really possible with the structure of PDF documents but there are certainly
some media types for which this could be applied.

I would think 'size' may be a partner attribute for hinting fetch behavior.
 The browser doesn't want to have to make more than one request unless there
is good reason to do so.  If the entire PDF is only one page long then a
meta data prefetch and continued fetch would be wasteful.  However if the
filesize was 26mb then a meta data prefetch could indicate where partial
fetches should be made to acquire the 1mb of content that will actually need
to be displayed to the user immediately.  If "type" is a reasonable
attribute to add to all of these elements I would think "size" should also
be considered.  It wouldn't have to be accurate, Content-length would take
priority, but this attribute would serve for hinting purposes.

Perhaps some alternative could be found with a DOM solution.

On Tue, Jul 13, 2010 at 3:45 AM, Gordon P. Hemsley <gphemsley at gmail.com>wrote:

> On Tue, Jul 13, 2010 at 3:26 AM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> > On 7/12/10 11:31 PM, Gordon P. Hemsley wrote:
> >>
> >> The particular use case that prompted me to think about this is
> >> including a PDF via <iframe>. In Firefox (last I checked), one is
> >> required to install a separate add-on in order to support in-browser
> >> display of PDF files on Mac OS X, since there is no native or integrated
> >> Adobe Reader support available.
> >
> > I'm pretty sure you can install the Adobe Reader plug-in on Mac if you
> want
> > to.
>
> Perhaps now, but that wasn't always the case?at least not for Firefox.
> I admit that my experience is somewhat outdated. Installing the
> third-party PDF viewer add-on is one of the first things I did, in a
> "set it and forget it" kind of way. (Plus, I'm still on Tiger.)
>
> But, again, the PDF example was just one possible use case. I'm sure
> there are plenty of other file types that cause similar situations,
> including the TIFF issue that I mentioned.
>
> >> Without the add-on, the user will be prompted to download the PDF file
> >
> > Which is exactly what would happen for a type="application/pdf" iframe,
> no?
> >  Silently not showing the content doesn't seem acceptable.
> >
> > -Boris
> >
> Well, the idea is to have the browser operate more intelligently than
> that. The page in the iframe is (by definition) not the primary
> document that the user is trying to load, so it shouldn't have the
> power steal the user's attention immediately upon page load. It would
> be very disorienting, and would likely cause the user to lose their
> train of thought.
>
> I was thinking more along the lines of Flashblock does or what happens
> when the window in an <iframe> can't load: The content would be
> replaced somehow by a message and a button/link to allow the user to
> manually download the contents of the iframe, if they so choose. It
> shouldn't make that decision for the user, as it's not the user's
> fault that their browser does not support the format of some ancillary
> document.
>
> At least, that's how I see it.
>
> Gordon
>
> --
> Gordon P. Hemsley
> me at gphemsley.org
> http://gphemsley.org/ ? http://gphemsley.org/blog/
> http://sasha.sourceforge.net/ ? http://www.yoursasha.com/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100713/263d9b00/attachment.htm>

From liachen at rim.com  Tue Jul 13 06:58:55 2010
From: liachen at rim.com (Lianghui Chen)
Date: Tue, 13 Jul 2010 09:58:55 -0400
Subject: [whatwg] About bypassing caches for URLs listed in Fallback
 and/or Network section in a HTML5 Offline Web Application
In-Reply-To: <BB31C4AB95A70042A256109D4619912601828EC1@XCH117CNC.rim.net>
References: <BB31C4AB95A70042A256109D4619912601828EC1@XCH117CNC.rim.net>
Message-ID: <BB31C4AB95A70042A256109D461991260182908A@XCH117CNC.rim.net>


Anyone has any comments?

From: whatwg-bounces at lists.whatwg.org [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Lianghui Chen
Sent: Monday, July 12, 2010 4:12 PM
To: whatwg at lists.whatwg.org
Subject: [whatwg] About bypassing caches for URLs listed in Fallback and/or Network section in a HTML5 Offline Web Application

Hi,

In spec HTML5 for offline web application (http://www.whatwg.org/specs/web-apps/current-work/#offline) chapter 6.6.6, item 3, 4, 5 state that for resources that is in online whitelist (or has wildcard whitelist), or fallback list, it should be fetched "normally".

I would like to know does it mean the user agent (browser) should bypass its own caches (besides html5 appcache), like the WebKit cache and browser http stack cache?

Best Regards
Lyon Chen


---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100713/f1ccc6f9/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.gif
Type: image/gif
Size: 92 bytes
Desc: image002.gif
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100713/f1ccc6f9/attachment-0001.gif>

From shwetankd at opera.com  Tue Jul 13 07:19:16 2010
From: shwetankd at opera.com (Shwetank Dixit)
Date: Tue, 13 Jul 2010 19:49:16 +0530
Subject: [whatwg] About bypassing caches for URLs listed in Fallback
 and/or Network section in a HTML5 Offline Web Application
In-Reply-To: <BB31C4AB95A70042A256109D461991260182908A@XCH117CNC.rim.net>
References: <BB31C4AB95A70042A256109D4619912601828EC1@XCH117CNC.rim.net>
	<BB31C4AB95A70042A256109D461991260182908A@XCH117CNC.rim.net>
Message-ID: <op.vfscp9slim6vpa@shwetank-dixits-macbook.local>

At least in Opera, it will still respect the browser's normal cache  
header. So the network section header will just bypass the application  
cache, and will load normally like any other web page, which means  
respecting (i.e, not bypassing) the normal cache.

On Tue, 13 Jul 2010 19:28:55 +0530, Lianghui Chen <liachen at rim.com> wrote:

>
> Anyone has any comments?
>
> From: whatwg-bounces at lists.whatwg.org  
> [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Lianghui Chen
> Sent: Monday, July 12, 2010 4:12 PM
> To: whatwg at lists.whatwg.org
> Subject: [whatwg] About bypassing caches for URLs listed in Fallback  
> and/or Network section in a HTML5 Offline Web Application
>
> Hi,
>
> In spec HTML5 for offline web application  
> (http://www.whatwg.org/specs/web-apps/current-work/#offline) chapter  
> 6.6.6, item 3, 4, 5 state that for resources that is in online whitelist  
> (or has wildcard whitelist), or fallback list, it should be fetched  
> "normally".
>
> I would like to know does it mean the user agent (browser) should bypass  
> its own caches (besides html5 appcache), like the WebKit cache and  
> browser http stack cache?
>
> Best Regards
> Lyon Chen
>
>
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential  
> information, privileged material (including material protected by the  
> solicitor-client or other applicable privileges), or constitute  
> non-public information. Any use of this information by anyone other than  
> the intended recipient is prohibited. If you have received this  
> transmission in error, please immediately reply to the sender and delete  
> this information from your system. Use, dissemination, distribution, or  
> reproduction of this transmission by unintended recipients is not  
> authorized and may be unlawful.


-- 
Shwetank Dixit
Web Evangelist,
Site Compatibility / Developer Relations / Consumer Products Group
Member - W3C Mobile Web for Social Development (MW4D) Group
Member - Web Standards Project (WaSP) - International Liaison Group
Opera Software - www.opera.com

Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

From liachen at rim.com  Tue Jul 13 07:26:49 2010
From: liachen at rim.com (Lianghui Chen)
Date: Tue, 13 Jul 2010 10:26:49 -0400
Subject: [whatwg] About bypassing caches for URLs listed in Fallback
 and/or Network section in a HTML5 Offline Web Application
In-Reply-To: <op.vfscp9slim6vpa@shwetank-dixits-macbook.local>
References: <BB31C4AB95A70042A256109D4619912601828EC1@XCH117CNC.rim.net>
	<BB31C4AB95A70042A256109D461991260182908A@XCH117CNC.rim.net>
	<op.vfscp9slim6vpa@shwetank-dixits-macbook.local>
Message-ID: <BB31C4AB95A70042A256109D46199126018290C7@XCH117CNC.rim.net>

Thanks, but that means once Opera starts with network connected, it won't detect whether network is offline for offline web applications. Doesn't it somehow defeat the purpose of "fallback" resource?

-----Original Message-----
From: Shwetank Dixit [mailto:shwetankd at opera.com] 
Sent: Tuesday, July 13, 2010 10:19 AM
To: Lianghui Chen; whatwg at lists.whatwg.org
Subject: Re: [whatwg] About bypassing caches for URLs listed in Fallback and/or Network section in a HTML5 Offline Web Application

At least in Opera, it will still respect the browser's normal cache  
header. So the network section header will just bypass the application  
cache, and will load normally like any other web page, which means  
respecting (i.e, not bypassing) the normal cache.

On Tue, 13 Jul 2010 19:28:55 +0530, Lianghui Chen <liachen at rim.com> wrote:

>
> Anyone has any comments?
>
> From: whatwg-bounces at lists.whatwg.org  
> [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Lianghui Chen
> Sent: Monday, July 12, 2010 4:12 PM
> To: whatwg at lists.whatwg.org
> Subject: [whatwg] About bypassing caches for URLs listed in Fallback  
> and/or Network section in a HTML5 Offline Web Application
>
> Hi,
>
> In spec HTML5 for offline web application  
> (http://www.whatwg.org/specs/web-apps/current-work/#offline) chapter  
> 6.6.6, item 3, 4, 5 state that for resources that is in online whitelist  
> (or has wildcard whitelist), or fallback list, it should be fetched  
> "normally".
>
> I would like to know does it mean the user agent (browser) should bypass  
> its own caches (besides html5 appcache), like the WebKit cache and  
> browser http stack cache?
>
> Best Regards
> Lyon Chen
>
>
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential  
> information, privileged material (including material protected by the  
> solicitor-client or other applicable privileges), or constitute  
> non-public information. Any use of this information by anyone other than  
> the intended recipient is prohibited. If you have received this  
> transmission in error, please immediately reply to the sender and delete  
> this information from your system. Use, dissemination, distribution, or  
> reproduction of this transmission by unintended recipients is not  
> authorized and may be unlawful.


-- 
Shwetank Dixit
Web Evangelist,
Site Compatibility / Developer Relations / Consumer Products Group
Member - W3C Mobile Web for Social Development (MW4D) Group
Member - Web Standards Project (WaSP) - International Liaison Group
Opera Software - www.opera.com

Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

From shwetankd at opera.com  Tue Jul 13 07:43:07 2010
From: shwetankd at opera.com (Shwetank Dixit)
Date: Tue, 13 Jul 2010 20:13:07 +0530
Subject: [whatwg] About bypassing caches for URLs listed in Fallback
 and/or Network section in a HTML5 Offline Web Application
In-Reply-To: <BB31C4AB95A70042A256109D46199126018290C7@XCH117CNC.rim.net>
References: <BB31C4AB95A70042A256109D4619912601828EC1@XCH117CNC.rim.net>
	<BB31C4AB95A70042A256109D461991260182908A@XCH117CNC.rim.net>
	<op.vfscp9slim6vpa@shwetank-dixits-macbook.local>
	<BB31C4AB95A70042A256109D46199126018290C7@XCH117CNC.rim.net>
Message-ID: <op.vfsdt5x1im6vpa@shwetank-dixits-macbook.local>

For 'fallback', it will try to load the resource normally, however, if the  
user is offline, that can't happen...so it will try to do it till a short  
while till it gives up (during that short while, if something is cached as  
part of the normal cache then it will use it), after which it will load  
the fallback resource wherever applicable.



On Tue, 13 Jul 2010 19:56:49 +0530, Lianghui Chen <liachen at rim.com> wrote:

> Thanks, but that means once Opera starts with network connected, it  
> won't detect whether network is offline for offline web applications.  
> Doesn't it somehow defeat the purpose of "fallback" resource?
>
> -----Original Message-----
> From: Shwetank Dixit [mailto:shwetankd at opera.com]
> Sent: Tuesday, July 13, 2010 10:19 AM
> To: Lianghui Chen; whatwg at lists.whatwg.org
> Subject: Re: [whatwg] About bypassing caches for URLs listed in Fallback  
> and/or Network section in a HTML5 Offline Web Application
>
> At least in Opera, it will still respect the browser's normal cache
> header. So the network section header will just bypass the application
> cache, and will load normally like any other web page, which means
> respecting (i.e, not bypassing) the normal cache.
>
> On Tue, 13 Jul 2010 19:28:55 +0530, Lianghui Chen <liachen at rim.com>  
> wrote:
>
>>
>> Anyone has any comments?
>>
>> From: whatwg-bounces at lists.whatwg.org
>> [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Lianghui Chen
>> Sent: Monday, July 12, 2010 4:12 PM
>> To: whatwg at lists.whatwg.org
>> Subject: [whatwg] About bypassing caches for URLs listed in Fallback
>> and/or Network section in a HTML5 Offline Web Application
>>
>> Hi,
>>
>> In spec HTML5 for offline web application
>> (http://www.whatwg.org/specs/web-apps/current-work/#offline) chapter
>> 6.6.6, item 3, 4, 5 state that for resources that is in online whitelist
>> (or has wildcard whitelist), or fallback list, it should be fetched
>> "normally".
>>
>> I would like to know does it mean the user agent (browser) should bypass
>> its own caches (besides html5 appcache), like the WebKit cache and
>> browser http stack cache?
>>
>> Best Regards
>> Lyon Chen
>>
>>
>> ---------------------------------------------------------------------
>> This transmission (including any attachments) may contain confidential
>> information, privileged material (including material protected by the
>> solicitor-client or other applicable privileges), or constitute
>> non-public information. Any use of this information by anyone other than
>> the intended recipient is prohibited. If you have received this
>> transmission in error, please immediately reply to the sender and delete
>> this information from your system. Use, dissemination, distribution, or
>> reproduction of this transmission by unintended recipients is not
>> authorized and may be unlawful.
>
>


-- 
Shwetank Dixit
Web Evangelist,
Site Compatibility / Developer Relations / Consumer Products Group
Member - W3C Mobile Web for Social Development (MW4D) Group
Member - Web Standards Project (WaSP) - International Liaison Group
Opera Software - www.opera.com

Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

From liachen at rim.com  Tue Jul 13 08:12:38 2010
From: liachen at rim.com (Lianghui Chen)
Date: Tue, 13 Jul 2010 11:12:38 -0400
Subject: [whatwg] About bypassing caches for URLs listed in Fallback
 and/or Network section in a HTML5 Offline Web Application
In-Reply-To: <op.vfsdt5x1im6vpa@shwetank-dixits-macbook.local>
References: <BB31C4AB95A70042A256109D4619912601828EC1@XCH117CNC.rim.net>
	<BB31C4AB95A70042A256109D461991260182908A@XCH117CNC.rim.net>
	<op.vfscp9slim6vpa@shwetank-dixits-macbook.local>
	<BB31C4AB95A70042A256109D46199126018290C7@XCH117CNC.rim.net>
	<op.vfsdt5x1im6vpa@shwetank-dixits-macbook.local>
Message-ID: <BB31C4AB95A70042A256109D461991260182913D@XCH117CNC.rim.net>

So if the content for a "fallback namespace" is cached, which should be if it starts with network connection and if server not explicitly use "no-cache/no-store" cache control, then it will always be used, from network or cache, and its mapping "fallback entry" will never be used, even if it's offline?

-----Original Message-----
From: Shwetank Dixit [mailto:shwetankd at opera.com] 
Sent: Tuesday, July 13, 2010 10:43 AM
To: whatwg at lists.whatwg.org; Lianghui Chen
Subject: Re: [whatwg] About bypassing caches for URLs listed in Fallback and/or Network section in a HTML5 Offline Web Application

For 'fallback', it will try to load the resource normally, however, if the  
user is offline, that can't happen...so it will try to do it till a short  
while till it gives up (during that short while, if something is cached as  
part of the normal cache then it will use it), after which it will load  
the fallback resource wherever applicable.



On Tue, 13 Jul 2010 19:56:49 +0530, Lianghui Chen <liachen at rim.com> wrote:

> Thanks, but that means once Opera starts with network connected, it  
> won't detect whether network is offline for offline web applications.  
> Doesn't it somehow defeat the purpose of "fallback" resource?
>
> -----Original Message-----
> From: Shwetank Dixit [mailto:shwetankd at opera.com]
> Sent: Tuesday, July 13, 2010 10:19 AM
> To: Lianghui Chen; whatwg at lists.whatwg.org
> Subject: Re: [whatwg] About bypassing caches for URLs listed in Fallback  
> and/or Network section in a HTML5 Offline Web Application
>
> At least in Opera, it will still respect the browser's normal cache
> header. So the network section header will just bypass the application
> cache, and will load normally like any other web page, which means
> respecting (i.e, not bypassing) the normal cache.
>
> On Tue, 13 Jul 2010 19:28:55 +0530, Lianghui Chen <liachen at rim.com>  
> wrote:
>
>>
>> Anyone has any comments?
>>
>> From: whatwg-bounces at lists.whatwg.org
>> [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Lianghui Chen
>> Sent: Monday, July 12, 2010 4:12 PM
>> To: whatwg at lists.whatwg.org
>> Subject: [whatwg] About bypassing caches for URLs listed in Fallback
>> and/or Network section in a HTML5 Offline Web Application
>>
>> Hi,
>>
>> In spec HTML5 for offline web application
>> (http://www.whatwg.org/specs/web-apps/current-work/#offline) chapter
>> 6.6.6, item 3, 4, 5 state that for resources that is in online whitelist
>> (or has wildcard whitelist), or fallback list, it should be fetched
>> "normally".
>>
>> I would like to know does it mean the user agent (browser) should bypass
>> its own caches (besides html5 appcache), like the WebKit cache and
>> browser http stack cache?
>>
>> Best Regards
>> Lyon Chen
>>
>>
>> ---------------------------------------------------------------------
>> This transmission (including any attachments) may contain confidential
>> information, privileged material (including material protected by the
>> solicitor-client or other applicable privileges), or constitute
>> non-public information. Any use of this information by anyone other than
>> the intended recipient is prohibited. If you have received this
>> transmission in error, please immediately reply to the sender and delete
>> this information from your system. Use, dissemination, distribution, or
>> reproduction of this transmission by unintended recipients is not
>> authorized and may be unlawful.
>
>


-- 
Shwetank Dixit
Web Evangelist,
Site Compatibility / Developer Relations / Consumer Products Group
Member - W3C Mobile Web for Social Development (MW4D) Group
Member - Web Standards Project (WaSP) - International Liaison Group
Opera Software - www.opera.com

Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

From zach at longtailvideo.com  Tue Jul 13 11:15:44 2010
From: zach at longtailvideo.com (Zachary Ozer)
Date: Tue, 13 Jul 2010 14:15:44 -0400
Subject: [whatwg] Proposal: @srctype or @type on <iframe>
In-Reply-To: <AANLkTik0g9IYZayZLKOTuvoBxPVh8q-sV8yU2tbKYklR@mail.gmail.com>
References: <AANLkTik7SGts2vHBz95YdKhEH3wwIRd3OCXXNFAYnIYQ@mail.gmail.com> 
	<4C3C153D.2010406@mit.edu>
	<AANLkTikMDEQsoEaQIsk15CkGo53398xOk-NMWFdOdP3D@mail.gmail.com> 
	<AANLkTik0g9IYZayZLKOTuvoBxPVh8q-sV8yU2tbKYklR@mail.gmail.com>
Message-ID: <AANLkTikx8MyBplVAdc-zNmlsSgNWhr6Hnvwcj7jTWhHd@mail.gmail.com>

It think that offering some hinting makes sense.

If the goal is to try and move away from plugins, giving a hint would
allow browsers to display appropriate UI elements before the request
is completed (in the case of PDF, something like the embedded Scribd
controls).

--
Zachary Ozer
Developer, LongTail Video

w: longtailvideo.com ? e: zach at longtailvideo.com ? p: 212.244.0140 ?
f: 212.656.1335
JW Player  |  Bits on the Run  |  AdSolution

On Tue, Jul 13, 2010 at 7:37 AM, Marques Johansson
<marques at displague.com> wrote:
> In one of the video related threads someone from Opera said that browsers
> have a rough time trying to figure out how to intelligently handle video
> content fetches. ?I think that a type suggestion, before the Content-type
> could help a browser use a more optimal fetch behavior.
> If the type of a resource is predefined then the browser can do a partial
> request to fetch the meta data of the?alleged?file format and in the case of
> a PDF perhaps the first few pages of content, leaving the rest to be loaded
> on demand as the content is scrolled / paginated. ?I don't know if this is
> really possible with the structure of PDF documents but there are certainly
> some media types for which this could be applied.
> I would think 'size' may be a partner attribute for hinting fetch behavior.
> ?The browser doesn't want to have to make more than one request unless there
> is good reason to do so. ?If the entire PDF is only one page long then a
> meta data prefetch and continued fetch would be wasteful. ?However if the
> filesize was 26mb then a meta data prefetch could indicate where partial
> fetches should be made to acquire the 1mb of content that will actually need
> to be displayed to the user immediately. ?If "type" is a reasonable
> attribute to add to all of these elements I would think "size" should also
> be considered. ?It wouldn't have to be accurate, Content-length would take
> priority, but this attribute would serve for hinting purposes.
> Perhaps some alternative could be found with a DOM solution.
>
> On Tue, Jul 13, 2010 at 3:45 AM, Gordon P. Hemsley <gphemsley at gmail.com>
> wrote:
>>
>> On Tue, Jul 13, 2010 at 3:26 AM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
>> > On 7/12/10 11:31 PM, Gordon P. Hemsley wrote:
>> >>
>> >> The particular use case that prompted me to think about this is
>> >> including a PDF via <iframe>. In Firefox (last I checked), one is
>> >> required to install a separate add-on in order to support in-browser
>> >> display of PDF files on Mac OS X, since there is no native or
>> >> integrated
>> >> Adobe Reader support available.
>> >
>> > I'm pretty sure you can install the Adobe Reader plug-in on Mac if you
>> > want
>> > to.
>>
>> Perhaps now, but that wasn't always the case?at least not for Firefox.
>> I admit that my experience is somewhat outdated. Installing the
>> third-party PDF viewer add-on is one of the first things I did, in a
>> "set it and forget it" kind of way. (Plus, I'm still on Tiger.)
>>
>> But, again, the PDF example was just one possible use case. I'm sure
>> there are plenty of other file types that cause similar situations,
>> including the TIFF issue that I mentioned.
>>
>> >> Without the add-on, the user will be prompted to download the PDF file
>> >
>> > Which is exactly what would happen for a type="application/pdf" iframe,
>> > no?
>> > ?Silently not showing the content doesn't seem acceptable.
>> >
>> > -Boris
>> >
>> Well, the idea is to have the browser operate more intelligently than
>> that. The page in the iframe is (by definition) not the primary
>> document that the user is trying to load, so it shouldn't have the
>> power steal the user's attention immediately upon page load. It would
>> be very disorienting, and would likely cause the user to lose their
>> train of thought.
>>
>> I was thinking more along the lines of Flashblock does or what happens
>> when the window in an <iframe> can't load: The content would be
>> replaced somehow by a message and a button/link to allow the user to
>> manually download the contents of the iframe, if they so choose. It
>> shouldn't make that decision for the user, as it's not the user's
>> fault that their browser does not support the format of some ancillary
>> document.
>>
>> At least, that's how I see it.
>>
>> Gordon
>>
>> --
>> Gordon P. Hemsley
>> me at gphemsley.org
>> http://gphemsley.org/ ? http://gphemsley.org/blog/
>> http://sasha.sourceforge.net/ ? http://www.yoursasha.com/
>
>

From michaeln at google.com  Tue Jul 13 11:49:43 2010
From: michaeln at google.com (Michael Nordman)
Date: Tue, 13 Jul 2010 11:49:43 -0700
Subject: [whatwg] About bypassing caches for URLs listed in Fallback
	and/or Network section in a HTML5 Offline Web Application
In-Reply-To: <op.vfscp9slim6vpa@shwetank-dixits-macbook.local>
References: <BB31C4AB95A70042A256109D4619912601828EC1@XCH117CNC.rim.net>
	<BB31C4AB95A70042A256109D461991260182908A@XCH117CNC.rim.net>
	<op.vfscp9slim6vpa@shwetank-dixits-macbook.local>
Message-ID: <AANLkTim6sotlKT1lddRE5uk0hI6CaO59KzPFJen97acm@mail.gmail.com>

Like Opera, Chrome respects the http cache when first attempting to "fetch
normally" a resource that falls in a fallback namespace. I'm reasonably
certain WebKit does the same.

"Normal" means just that... first do what the browser would do if there was
no Application Cache... only if that fails to produce a good response, do
something extra.

On Tue, Jul 13, 2010 at 7:19 AM, Shwetank Dixit <shwetankd at opera.com> wrote:

> At least in Opera, it will still respect the browser's normal cache header.
> So the network section header will just bypass the application cache, and
> will load normally like any other web page, which means respecting (i.e, not
> bypassing) the normal cache.
>
> On Tue, 13 Jul 2010 19:28:55 +0530, Lianghui Chen <liachen at rim.com> wrote:
>
>
>> Anyone has any comments?
>>
>> From: whatwg-bounces at lists.whatwg.org [mailto:
>> whatwg-bounces at lists.whatwg.org] On Behalf Of Lianghui Chen
>> Sent: Monday, July 12, 2010 4:12 PM
>> To: whatwg at lists.whatwg.org
>> Subject: [whatwg] About bypassing caches for URLs listed in Fallback
>> and/or Network section in a HTML5 Offline Web Application
>>
>> Hi,
>>
>> In spec HTML5 for offline web application (
>> http://www.whatwg.org/specs/web-apps/current-work/#offline) chapter
>> 6.6.6, item 3, 4, 5 state that for resources that is in online whitelist (or
>> has wildcard whitelist), or fallback list, it should be fetched "normally".
>>
>> I would like to know does it mean the user agent (browser) should bypass
>> its own caches (besides html5 appcache), like the WebKit cache and browser
>> http stack cache?
>>
>> Best Regards
>> Lyon Chen
>>
>>
>> ---------------------------------------------------------------------
>> This transmission (including any attachments) may contain confidential
>> information, privileged material (including material protected by the
>> solicitor-client or other applicable privileges), or constitute non-public
>> information. Any use of this information by anyone other than the intended
>> recipient is prohibited. If you have received this transmission in error,
>> please immediately reply to the sender and delete this information from your
>> system. Use, dissemination, distribution, or reproduction of this
>> transmission by unintended recipients is not authorized and may be unlawful.
>>
>
>
> --
> Shwetank Dixit
> Web Evangelist,
> Site Compatibility / Developer Relations / Consumer Products Group
> Member - W3C Mobile Web for Social Development (MW4D) Group
> Member - Web Standards Project (WaSP) - International Liaison Group
> Opera Software - www.opera.com
>
> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100713/a8b07ff4/attachment.htm>

From liachen at rim.com  Tue Jul 13 11:58:48 2010
From: liachen at rim.com (Lianghui Chen)
Date: Tue, 13 Jul 2010 14:58:48 -0400
Subject: [whatwg] About bypassing caches for URLs listed in Fallback
 and/or Network section in a HTML5 Offline Web Application
In-Reply-To: <AANLkTim6sotlKT1lddRE5uk0hI6CaO59KzPFJen97acm@mail.gmail.com>
References: <BB31C4AB95A70042A256109D4619912601828EC1@XCH117CNC.rim.net>
	<BB31C4AB95A70042A256109D461991260182908A@XCH117CNC.rim.net>
	<op.vfscp9slim6vpa@shwetank-dixits-macbook.local>
	<AANLkTim6sotlKT1lddRE5uk0hI6CaO59KzPFJen97acm@mail.gmail.com>
Message-ID: <BB31C4AB95A70042A256109D46199126018293B2@XCH117CNC.rim.net>

Thanks, so it seems to make sure a fallback entry is used when offline, cache-control has to be used.

From: Michael Nordman [mailto:michaeln at google.com]
Sent: Tuesday, July 13, 2010 2:50 PM
To: Shwetank Dixit
Cc: Lianghui Chen; whatwg at lists.whatwg.org
Subject: Re: [whatwg] About bypassing caches for URLs listed in Fallback and/or Network section in a HTML5 Offline Web Application

Like Opera, Chrome respects the http cache when first attempting to "fetch normally" a resource that falls in a fallback namespace. I'm reasonably certain WebKit does the same.

"Normal" means just that... first do what the browser would do if there was no Application Cache... only if that fails to produce a good response, do something extra.
On Tue, Jul 13, 2010 at 7:19 AM, Shwetank Dixit <shwetankd at opera.com<mailto:shwetankd at opera.com>> wrote:
At least in Opera, it will still respect the browser's normal cache header. So the network section header will just bypass the application cache, and will load normally like any other web page, which means respecting (i.e, not bypassing) the normal cache.

On Tue, 13 Jul 2010 19:28:55 +0530, Lianghui Chen <liachen at rim.com<mailto:liachen at rim.com>> wrote:

Anyone has any comments?

From: whatwg-bounces at lists.whatwg.org<mailto:whatwg-bounces at lists.whatwg.org> [mailto:whatwg-bounces at lists.whatwg.org<mailto:whatwg-bounces at lists.whatwg.org>] On Behalf Of Lianghui Chen
Sent: Monday, July 12, 2010 4:12 PM
To: whatwg at lists.whatwg.org<mailto:whatwg at lists.whatwg.org>
Subject: [whatwg] About bypassing caches for URLs listed in Fallback and/or Network section in a HTML5 Offline Web Application

Hi,

In spec HTML5 for offline web application (http://www.whatwg.org/specs/web-apps/current-work/#offline) chapter 6.6.6, item 3, 4, 5 state that for resources that is in online whitelist (or has wildcard whitelist), or fallback list, it should be fetched "normally".

I would like to know does it mean the user agent (browser) should bypass its own caches (besides html5 appcache), like the WebKit cache and browser http stack cache?

Best Regards
Lyon Chen


---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.


--
Shwetank Dixit
Web Evangelist,
Site Compatibility / Developer Relations / Consumer Products Group
Member - W3C Mobile Web for Social Development (MW4D) Group
Member - Web Standards Project (WaSP) - International Liaison Group
Opera Software - www.opera.com<http://www.opera.com>

Using Opera's revolutionary e-mail client: http://www.opera.com/mail/


---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100713/517555ea/attachment.htm>

From Simetrical+w3c at gmail.com  Tue Jul 13 14:57:51 2010
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Tue, 13 Jul 2010 17:57:51 -0400
Subject: [whatwg] Proposal: @srctype or @type on <iframe>
In-Reply-To: <AANLkTik7SGts2vHBz95YdKhEH3wwIRd3OCXXNFAYnIYQ@mail.gmail.com>
References: <AANLkTik7SGts2vHBz95YdKhEH3wwIRd3OCXXNFAYnIYQ@mail.gmail.com>
Message-ID: <AANLkTimFqm_mDM9Q3Xc1i6qaO60_h925Zskf1n95uTuV@mail.gmail.com>

On Tue, Jul 13, 2010 at 2:31 AM, Gordon P. Hemsley <gphemsley at gmail.com> wrote:
> The particular use case that prompted me to think about this is including a
> PDF via <iframe>. In Firefox (last I checked), one is required to install a
> separate add-on in order to support in-browser display of PDF files on Mac
> OS X, since there is no native or integrated Adobe Reader support available.
> Without the add-on, the user will be prompted to download the PDF file,
> which can be very disconcerting if the user wasn't even expecting a PDF
> file. And I'm sure there are plenty of other instances where this same
> situation occurs. (TIFF files, perhaps? Like on the U.S. Patent Office's
> website?)

If this is your use-case, you don't want or need type="".  You just
want browsers to handle unsupported content in iframes differently
than they do now.  Offering a download sounds like it's probably
better behavior than just ignoring it.  Maybe it would be best to
display a "click to download" thing where the iframe is supposed to
display, instead.  But this is really a UI issue, not an HTML-level
issue.  I suggest you file bugs against browsers that have annoying UI
here.

I don't think there's any reason why a browser would need to know the
type (which might be incorrect) of an <iframe> before it actually
issues the HTTP request.  This is useful on <source>, but only because
the common case there right now is that at least one <source> is
unsupported.  (But when a common baseline codec is settled on, the
useless type="" can be dropped.)  The common case for <iframe> is that
the content is supported, and where it's not, often the page becomes
useless anyway, so it's not worth optimizing for.

From ian at hixie.ch  Tue Jul 13 16:49:52 2010
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 13 Jul 2010 23:49:52 +0000 (UTC)
Subject: [whatwg] The vision behind the <device> element and the
 ConnectionPeer interface
Message-ID: <Pine.LNX.4.64.1007132253160.7242@ps20323.dreamhostps.com>


Several people have asked me to elaborate on the vision I have for the 
<device> element and the ConnectionPeer interface which are currently 
specified in draft form here:

   http://www.whatwg.org/specs/web-apps/current-work/complete/commands.html#devices
   http://www.whatwg.org/specs/web-apps/current-work/complete/commands.html#connectionpeer

There are several use cases that are informing this work:

 - Video conferencing
 - Real-time games
 - Peer-to-peer file transfer

For video conferencing, we need a mechanism through which a local camera 
and microphone setup can be enabled and access to which can be granted to 
scripts in the page, but only with the user's consent and without being 
vulnerable to the user being tricked (e.g. through click-jacking). There 
then needs to be a way to transmit this stream of video to another peer's 
browser, for display. There is also a need to display the stream locally.

For real-time games, we need a mechanism that can send data to a peer or 
server, where the latency is more important than reliability. That is, 
it's not critical that packets arrive in order (or at all); once a packet 
is late, it's useless and there is no reason to resend it. For example, 
transient game state information becomes stale quickly. (Video is similar; 
only data for the latest frame is interesting: data for older frames is 
not useful.)

For peer-to-peer file transfer, we need a mechanism to send data, either 
in the form of text or binary, to another peer.

In all three cases, we need a mechanism to establish a connection to 
another peer. This is a non-trivial problem, because of NAT and firewalls. 
Therefore, we may need help from a third-party server to establish the 
connection.

Ideally, I'd like the solution to involve no special code at the JS level, 
and I'd like the server-side connection helper to be something that can be 
implemented by just setting up a server with no special code and minimal 
configuration. Thus all the complexity would be in the browsers and in 
these reusable servers. The only work the author needs to do in this 
vision is have scripts running in the browsers of both peers decide that 
they want to connect to each other, and have them exchange some opaque 
information and information about the helper server, e.g. by sending a 
message through XMLHttpRequest to the server to bounce to the other user.

To do this, there have to be three configuration strings:

 1. A description of the helper server to give to the browsers, so they 
    know who to contact to get things started.

 2. A description of the first peer that contains all the information the
    second peer needs to connect to the first peer.

 3. A description of the second peer that contains all the information the
    first peer needs to connect to the second peer.

The server can generate the data for 1.

The browser for the first peer can generate the data for 2.

The browser for the second peer can generate the data for 3.

The script then just needs to get the data for 1 and give it to the two 
peers, the data for 2 and give it to the second peer, and the data for 3 
and give it to the first peer.

Once the browsers have the information, they can set up a connection to 
each other using the helper server. For example, in the simplest case, the 
information for 2 is just the IP address and listening port of the first 
peer, the information for 3 is just the IP address and listening port of 
the second peer, and the browsers just have to each open a TCP connection 
to each other to set up a control channel over which everything else can 
be done.

Now of course things aren't that simple -- in practice the information 
will have to include details such as keys to make sure the browsers can 
prove to each other that they are who they expect to be, there will have 
to be information obtained from the helper server (e.g. the IP address of 
the NAT router), and there will likely be information about what protocols 
are supported, and so on.

None of this has to be exposed to the script, though, which is the great 
thing about this mechanism.

So what is missing here?

Well the main thing missing in this vision is the format of the 
configuration strings, and rules for how they are to be interpreted. We 
need a specification that defines how the helper servers and browsers are 
to interact, and how, once they have a control channel set up, how they 
are to set up further channels such as a way to be ready to receive UDP 
packets for a video stream, how to get ready to receive a file, and so on.

I believe this is a self-contained problem, which can be defined as a 
black box that exposes only the following:

   Browser side:
       Methods to:
        - add a configuration string from the other peer
        - add a configuration string from the helper server
        - open a connection
        - close a connection
        - send plain text reliably
        - send plain text unreliably, with low latency
        - send binary data reliably
        - send binary data unreliably, with low latency
        - start sending a stream
        - stop sending a stream
      Callbacks for:
        - getting a configuration string for the other side
        - the connection being established
        - a permanent failure to establish a connection
        - the connection being shut down
        - receiving text
        - receiving binary data
        - being notified of a new stream being received
        - being notified that a stream has been dropped

   Server side:
      Callbacks for:
        - getting a configuration string for the browsers

Everything else (how the connections work, what the configuration strings 
look like, etc) would just be something internal to that specification, 
and separate from HTML.

The black box could also include details like how to negotiate different 
bitrates for video streams; these again don't have to be exposed to the 
script, at least not in the first version. Since the browser is the one 
generating the stream and the one doing the connection work, the black box 
can directly control the stream generation as well.


If this is something that resonates with people, then what we really need 
is for a group of people to get together and design this black box. If 
people would like to do it through the WHATWG I'd be happy to create a 
mailing list and whatever other infrastructure is needed for this purpose; 
alternatively it could be done at the IETF or in some other group.

If there are any questions about this, please feel free to ask them, I'll 
try to explain what I invision here in more detail. If this isn't a 
direction people are interested in, then that's fine too. :-)

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

From bmschwar at fas.harvard.edu  Tue Jul 13 16:56:18 2010
From: bmschwar at fas.harvard.edu (Benjamin M. Schwartz)
Date: Tue, 13 Jul 2010 19:56:18 -0400
Subject: [whatwg] The vision behind the <device> element and the
 ConnectionPeer interface
In-Reply-To: <Pine.LNX.4.64.1007132253160.7242@ps20323.dreamhostps.com>
References: <Pine.LNX.4.64.1007132253160.7242@ps20323.dreamhostps.com>
Message-ID: <4C3CFD22.9090803@fas.harvard.edu>

On 07/13/2010 07:49 PM, Ian Hickson wrote:
> We
> need a specification that defines how the helper servers and browsers are 
> to interact, and how, once they have a control channel set up, how they 
> are to set up further channels such as a way to be ready to receive UDP 
> packets for a video stream, how to get ready to receive a file, and so on.

This sounds like a description of XMPP.  Have you considered XMPP?

Why not use XMPP?

--Ben.

P.S. XMPP

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100713/f5ee760f/attachment.pgp>

From ian at hixie.ch  Tue Jul 13 17:08:23 2010
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 14 Jul 2010 00:08:23 +0000 (UTC)
Subject: [whatwg] The vision behind the <device> element and the
 ConnectionPeer interface
In-Reply-To: <4C3CFD22.9090803@fas.harvard.edu>
References: <Pine.LNX.4.64.1007132253160.7242@ps20323.dreamhostps.com>
	<4C3CFD22.9090803@fas.harvard.edu>
Message-ID: <Pine.LNX.4.64.1007140007180.24444@ps20323.dreamhostps.com>

On Tue, 13 Jul 2010, Benjamin M. Schwartz wrote:
> On 07/13/2010 07:49 PM, Ian Hickson wrote:
> > We need a specification that defines how the helper servers and 
> > browsers are to interact, and how, once they have a control channel 
> > set up, how they are to set up further channels such as a way to be 
> > ready to receive UDP packets for a video stream, how to get ready to 
> > receive a file, and so on.
> 
> This sounds like a description of XMPP.  Have you considered XMPP?
> 
> Why not use XMPP?

XMPP or another existing protocol is indeed an option for how the black 
box I described would function. The point though is that the details would 
be defined outside of this working group, and that the API would thus be 
completely protocol agnostic.

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

From jgraham at opera.com  Wed Jul 14 02:39:42 2010
From: jgraham at opera.com (James Graham)
Date: Wed, 14 Jul 2010 11:39:42 +0200
Subject: [whatwg] Communicating between different-origin frames
Message-ID: <4C3D85DE.10507@opera.com>

Following some discussion of [1], it was pointed out to me that it is 
possible to make two pages on separate subdomains communicate without 
either setting their document.domain by proxing the communication 
through pages that have set their document.domain. There is a demo of 
this at [2].

I'm not sure if this is already well-known nor whether it is harmless or 
not.

[1] 
http://my.opera.com/hallvors/blog/2010/07/13/ebay-versus-security-policy-consistency
[2] http://sloth.whyi.org/~jl/cross-domain.html

From david at davidflanagan.com  Wed Jul 14 12:03:36 2010
From: david at davidflanagan.com (David Flanagan)
Date: Wed, 14 Jul 2010 12:03:36 -0700
Subject: [whatwg] Canvas "coordinate space units"
Message-ID: <4C3E0A08.4030702@davidflanagan.com>

I'm confused by the term "coordinate space units" as applied to the 
canvas spec.  It does not seem to be defined.

It is used in the definition of the translate() method, for example, and 
seems to imply that coordinate space units are affected by scale() 
operations.

It is used in the definition of the lineWidth attribute as well. 
Chrome, Firefox and Opera all scaled lineWidth and Phillip Taylor's test 
suite expects this behavior as well.

But then in the definition of shadowOffsetX and Y, the spec reads:

> Their values are in coordinate space units. They are not affected by the current transformation matrix.

The description of isPointInPath() uses similar language:

>  when treated as coordinates in the canvas coordinate space unaffected by the current transformation,

So which is it?  Are "coordinate space units" affected by scaling or 
not?  Are lineWidths supposed to be scaled? (Implementations do so 
consistently) Are shadow offset supposed to be scaled? (Chrome does, 
Firefox and Opera do not)

I think a clearer definition of coordinate spaces would be helpful. 
Maybe "device space" for the underlying pixmap, "canvas space" for the 
coordinates defined by the width and height attributes of the canvas, 
and "user space" for the space defined by the current transformation matrix?

	David

From w3c at adambarth.com  Wed Jul 14 14:04:12 2010
From: w3c at adambarth.com (Adam Barth)
Date: Wed, 14 Jul 2010 14:04:12 -0700
Subject: [whatwg] Communicating between different-origin frames
In-Reply-To: <4C3D85DE.10507@opera.com>
References: <4C3D85DE.10507@opera.com>
Message-ID: <AANLkTilYHg336y_kzrEvGBU7Eqj-tObDLtQFUGguxxRS@mail.gmail.com>

This is well-known

http://www.collinjackson.com/research/papers/fp801-jackson.pdf

but not a good idea (see Section 4.4):

http://www.adambarth.com/papers/2009/barth-weinberger-song.pdf

Adam


On Wed, Jul 14, 2010 at 2:39 AM, James Graham <jgraham at opera.com> wrote:
> Following some discussion of [1], it was pointed out to me that it is
> possible to make two pages on separate subdomains communicate without either
> setting their document.domain by proxing the communication through pages
> that have set their document.domain. There is a demo of this at [2].
>
> I'm not sure if this is already well-known nor whether it is harmless or
> not.
>
> [1]
> http://my.opera.com/hallvors/blog/2010/07/13/ebay-versus-security-policy-consistency
> [2] http://sloth.whyi.org/~jl/cross-domain.html
>

From Simetrical+w3c at gmail.com  Wed Jul 14 14:33:46 2010
From: Simetrical+w3c at gmail.com (Aryeh Gregor)
Date: Wed, 14 Jul 2010 17:33:46 -0400
Subject: [whatwg] Canvas "coordinate space units"
In-Reply-To: <4C3E0A08.4030702@davidflanagan.com>
References: <4C3E0A08.4030702@davidflanagan.com>
Message-ID: <AANLkTinKDGuiNL-XZHmeo3ggJaPDQiutqbwOk8EfT4QK@mail.gmail.com>

On Wed, Jul 14, 2010 at 3:03 PM, David Flanagan <david at davidflanagan.com> wrote:
> I'm confused by the term "coordinate space units" as applied to the canvas
> spec. ?It does not seem to be defined.

It seems clear to me.  The 2D context represents a Cartesian plane,
and the units for everything are units within that plane.  One
coordinate space unit might correspond to any number of pixels,
depending:

"""
The intrinsic dimensions of the canvas element equal the size of the
coordinate space, with the numbers interpreted in CSS pixels. However,
the element can be sized arbitrarily by a style sheet. During
rendering, the image is scaled to fit this layout size.

The size of the coordinate space does not necessarily represent the
size of the actual bitmap that the user agent will use internally or
during rendering. On high-definition displays, for instance, the user
agent may internally use a bitmap with two device pixels per unit in
the coordinate space, so that the rendering remains at high quality
throughout.
"""

> It is used in the definition of the translate() method, for example, and
> seems to imply that coordinate space units are affected by scale()
> operations.

The transformation matrix is referred to in a particular well-defined
way by some methods.  For instance, the rectangle methods say:

"""
The current transformation matrix must be applied to the following
four coordinates, which form the path that must then be closed to get
the specified rectangle: (x, y), (x+w, y), (x+w, y+h), (x, y+h).
"""

This only affects operations where it says so explicitly.  Nothing
that I see says it affects the coordinate space units themselves (if
that even makes sense).

> It is used in the definition of the lineWidth attribute as well. Chrome,
> Firefox and Opera all scaled lineWidth and Phillip Taylor's test suite
> expects this behavior as well.

I can't find where it says lineWidth should be scaled . . .

> But then in the definition of shadowOffsetX and Y, the spec reads:
>
>> Their values are in coordinate space units. They are not affected by the
>> current transformation matrix.
>
> The description of isPointInPath() uses similar language:
>
>> ?when treated as coordinates in the canvas coordinate space unaffected by
>> the current transformation,
>
> So which is it? ?Are "coordinate space units" affected by scaling or not?

As far as I can tell, no.  When the transformation matrix is used, it
says so explicitly.  The language you point to for shadowOffset and
isPointInPath is just a reminder.  I think.

> ?Are lineWidths supposed to be scaled? (Implementations do so consistently)

I don't think they're supposed to be from reading the spec, although I
don't know why not.  Maybe I'm missing something, or maybe this needs
to be clarified.

> Are shadow offset supposed to be scaled? (Chrome does, Firefox and Opera do
> not)

Doesn't it say explicitly that they shouldn't be?

> I think a clearer definition of coordinate spaces would be helpful. Maybe
> "device space" for the underlying pixmap, "canvas space" for the coordinates
> defined by the width and height attributes of the canvas, and "user space"
> for the space defined by the current transformation matrix?

It might be a good idea to separate out the units for stuff affected
by transformations vs. not, yeah.  I don't know why anything shouldn't
be transformed by the current transformation matrix, though.

From hallvors at gmail.com  Wed Jul 14 15:40:08 2010
From: hallvors at gmail.com (Hallvord R M Steen)
Date: Thu, 15 Jul 2010 00:40:08 +0200
Subject: [whatwg] postMessage's target origin argument can be a full URL in
	some implementations
Message-ID: <AANLkTilVWxoVPEWFHD0wb8778253X8mrn4Ryp3mJT6LS@mail.gmail.com>

Hi,
the way I read the spec, the target origin argument for
window.postMessage should be a protocol, host name and optionally port
number - in other words

window.postMessage( 'foo', 'http://www.example.com' )
or
window.postMessage( 'foo', 'http://www.example.com:81' )

However, it has come to my attention that both WebKit and Gecko's
implementation of postMessage() allows a full URL with path:

window.postMessage( 'foo', 'http://www.example.com/path/goes/here/' )

Isn't this a violation of the spec?

My personal opinion is that protocol+host+port is better, simply
because authors might assume the path is significant (i.e. think that
'http://www.geocities.com/foo' and 'http://www.geocities.com/bar'
would be different origins). Allowing paths that are simply ignored
might muddle the "origin" concept - not a major problem, but a small
potential point of confusion.

Opera follows the spec (as I read it) and throws an exception if a URL
with a path is used, but I've recently come across two different
scripts breaking in Opera because of this issue. I think it's very
important to get this clarified and hopefully fixed in WebKit and
Gecko before usage is too common and we have to modify the spec to
allow it :-(. (We're already discussing fixes with the two broken
sites).

Any comments from Mozilla and WebKit developers on the list?

P.S.: we reported some bugs for you, in case you agree with our
reading and want to fix it :-)
https://bugs.webkit.org/show_bug.cgi?id=42170
https://bugzilla.mozilla.org/show_bug.cgi?id=578380

-- 
Hallvord R. M. Steen

From jonas at sicking.cc  Wed Jul 14 15:45:14 2010
From: jonas at sicking.cc (Jonas Sicking)
Date: Wed, 14 Jul 2010 15:45:14 -0700
Subject: [whatwg] postMessage's target origin argument can be a full URL
	in some implementations
In-Reply-To: <AANLkTilVWxoVPEWFHD0wb8778253X8mrn4Ryp3mJT6LS@mail.gmail.com>
References: <AANLkTilVWxoVPEWFHD0wb8778253X8mrn4Ryp3mJT6LS@mail.gmail.com>
Message-ID: <AANLkTimTnAEtiretvDPxUSPQ5xGxjbv_3mRM3R9SBoBa@mail.gmail.com>

On Wed, Jul 14, 2010 at 3:40 PM, Hallvord R M Steen <hallvors at gmail.com> wrote:
> Hi,
> the way I read the spec, the target origin argument for
> window.postMessage should be a protocol, host name and optionally port
> number - in other words
>
> window.postMessage( 'foo', 'http://www.example.com' )
> or
> window.postMessage( 'foo', 'http://www.example.com:81' )
>
> However, it has come to my attention that both WebKit and Gecko's
> implementation of postMessage() allows a full URL with path:
>
> window.postMessage( 'foo', 'http://www.example.com/path/goes/here/' )
>
> Isn't this a violation of the spec?
>
> My personal opinion is that protocol+host+port is better, simply
> because authors might assume the path is significant (i.e. think that
> 'http://www.geocities.com/foo' and 'http://www.geocities.com/bar'
> would be different origins). Allowing paths that are simply ignored
> might muddle the "origin" concept - not a major problem, but a small
> potential point of confusion.
>
> Opera follows the spec (as I read it) and throws an exception if a URL
> with a path is used, but I've recently come across two different
> scripts breaking in Opera because of this issue. I think it's very
> important to get this clarified and hopefully fixed in WebKit and
> Gecko before usage is too common and we have to modify the spec to
> allow it :-(. (We're already discussing fixes with the two broken
> sites).
>
> Any comments from Mozilla and WebKit developers on the list?
>
> P.S.: we reported some bugs for you, in case you agree with our
> reading and want to fix it :-)
> https://bugs.webkit.org/show_bug.cgi?id=42170
> https://bugzilla.mozilla.org/show_bug.cgi?id=578380

My understanding is that this was a requirement from the spec. An
unfortunate one at that. However when I found out it was too late to
get the spec changed as multiple implementations had already shipped.

/ Jonas

From hallvors at gmail.com  Wed Jul 14 15:48:15 2010
From: hallvors at gmail.com (Hallvord R M Steen)
Date: Thu, 15 Jul 2010 00:48:15 +0200
Subject: [whatwg] postMessage's target origin argument can be a full URL
	in some implementations
In-Reply-To: <AANLkTimTnAEtiretvDPxUSPQ5xGxjbv_3mRM3R9SBoBa@mail.gmail.com>
References: <AANLkTilVWxoVPEWFHD0wb8778253X8mrn4Ryp3mJT6LS@mail.gmail.com>
	<AANLkTimTnAEtiretvDPxUSPQ5xGxjbv_3mRM3R9SBoBa@mail.gmail.com>
Message-ID: <AANLkTikES-UK-oDArsUAa2wNzr8xHBbS_G6YBWtpBBpX@mail.gmail.com>

> My understanding is that this was a requirement from the spec. An
> unfortunate one at that.

Could you elaborate on why you think it is unfortunate?

> However when I found out it was too late to
> get the spec changed as multiple implementations had already shipped.

Does that mean you intend to fix it to align with the spec?
Hallvord

-- 
Hallvord R. M. Steen

From jonas at sicking.cc  Wed Jul 14 16:33:24 2010
From: jonas at sicking.cc (Jonas Sicking)
Date: Wed, 14 Jul 2010 16:33:24 -0700
Subject: [whatwg] postMessage's target origin argument can be a full URL
	in some implementations
In-Reply-To: <AANLkTikES-UK-oDArsUAa2wNzr8xHBbS_G6YBWtpBBpX@mail.gmail.com>
References: <AANLkTilVWxoVPEWFHD0wb8778253X8mrn4Ryp3mJT6LS@mail.gmail.com> 
	<AANLkTimTnAEtiretvDPxUSPQ5xGxjbv_3mRM3R9SBoBa@mail.gmail.com> 
	<AANLkTikES-UK-oDArsUAa2wNzr8xHBbS_G6YBWtpBBpX@mail.gmail.com>
Message-ID: <AANLkTil3savNXtU1HlSQt0OlGl5dtZKLa_PLqUffD-MA@mail.gmail.com>

On Wed, Jul 14, 2010 at 3:48 PM, Hallvord R M Steen <hallvors at gmail.com> wrote:
>> My understanding is that this was a requirement from the spec. An
>> unfortunate one at that.
>
> Could you elaborate on why you think it is unfortunate?

I think it's unfortunate that if someone does:

postMessage(..., "http://foo.com/bar/baz.html");

that message can silently go to

http://foo.com/somethingElse.html

The problem here is the 'silently'. If we instead made the above throw
an exception then it would be more obvious for authors how this
worked.

>> However when I found out it was too late to
>> get the spec changed as multiple implementations had already shipped.
>
> Does that mean you intend to fix it to align with the spec?

I didn't realize that the spec now required that there was no path.
Yes, I think we should update to match the spec. There is of course
the risk that it'll break the web, but I think we should at least try.

Would love it if someone attached a patch. I can promise same-day
review if I'm not in travel.

/ Jonas

From bzbarsky at MIT.EDU  Wed Jul 14 17:18:33 2010
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Wed, 14 Jul 2010 20:18:33 -0400
Subject: [whatwg] postMessage's target origin argument can be a full URL
 in	some implementations
In-Reply-To: <AANLkTilVWxoVPEWFHD0wb8778253X8mrn4Ryp3mJT6LS@mail.gmail.com>
References: <AANLkTilVWxoVPEWFHD0wb8778253X8mrn4Ryp3mJT6LS@mail.gmail.com>
Message-ID: <4C3E53D9.5000708@mit.edu>

On 7/14/10 6:40 PM, Hallvord R M Steen wrote:
> My personal opinion is that protocol+host+port is better, simply
> because authors might assume the path is significant (i.e. think that
> 'http://www.geocities.com/foo' and 'http://www.geocities.com/bar'
> would be different origins). Allowing paths that are simply ignored
> might muddle the "origin" concept - not a major problem, but a small
> potential point of confusion.

I've actually used urls with a path for the origin; specifically when I 
wanted to pass in "the origin of this page".  In particular, I passed in 
location.href.

I'm fine with removing the ability to pass in a path _if_ we create a 
simple way for scripts to get origins from pages which can then be 
passed for this argument.  The alternative is that scripts will be 
parsing location.href themselves to extract the thing to pass as the 
origin string, which is just asking for security fail in my experience.

-Boris

From david at davidflanagan.com  Wed Jul 14 17:29:43 2010
From: david at davidflanagan.com (David Flanagan)
Date: Wed, 14 Jul 2010 17:29:43 -0700
Subject: [whatwg] Canvas "coordinate space units"
In-Reply-To: <AANLkTinKDGuiNL-XZHmeo3ggJaPDQiutqbwOk8EfT4QK@mail.gmail.com>
References: <4C3E0A08.4030702@davidflanagan.com>
	<AANLkTinKDGuiNL-XZHmeo3ggJaPDQiutqbwOk8EfT4QK@mail.gmail.com>
Message-ID: <4C3E5677.6030900@davidflanagan.com>

Aryeh Gregor wrote:
> On Wed, Jul 14, 2010 at 3:03 PM, David Flanagan <david at davidflanagan.com> wrote:
>> I'm confused by the term "coordinate space units" as applied to the canvas
>> spec.  It does not seem to be defined.
> 
> It seems clear to me.  

Even if clear, it is still undefined.  And the words "coordinate space" 
are so generic as to be meaningless here.  "canvas units" or something 
would make more sense.

The 2D context represents a Cartesian plane,
> and the units for everything are units within that plane.  One
> coordinate space unit might correspond to any number of pixels,
> depending:
> 
> """
> The intrinsic dimensions of the canvas element equal the size of the
> coordinate space, with the numbers interpreted in CSS pixels. However,
> the element can be sized arbitrarily by a style sheet. During
> rendering, the image is scaled to fit this layout size.
> 
> The size of the coordinate space does not necessarily represent the
> size of the actual bitmap that the user agent will use internally or
> during rendering. On high-definition displays, for instance, the user
> agent may internally use a bitmap with two device pixels per unit in
> the coordinate space, so that the rendering remains at high quality
> throughout.
> """

As an aside, do you think any implementations actually do that?  It 
seems to me that it would cause real problems with drawImage(): images 
would look bad compared to drawn graphics...


>> It is used in the definition of the translate() method, for example, and
>> seems to imply that coordinate space units are affected by scale()
>> operations.
> 
> The transformation matrix is referred to in a particular well-defined
> way by some methods.  For instance, the rectangle methods say:
> 
> """
> The current transformation matrix must be applied to the following
> four coordinates, which form the path that must then be closed to get
> the specified rectangle: (x, y), (x+w, y), (x+w, y+h), (x, y+h).
> """
> 
> This only affects operations where it says so explicitly.  Nothing
> that I see says it affects the coordinate space units themselves (if
> that even makes sense).

Okay; that makes sense.  Points passed to path definition methods are 
transformed according to the CTM.  I tend to think of transformations as 
affecting the entire coordinate space. But the spec is written with only 
one coordinate space defined, and points are transformed to this space 
as they are added to the path.


>> It is used in the definition of the lineWidth attribute as well. Chrome,
>> Firefox and Opera all scaled lineWidth and Phillip Taylor's test suite
>> expects this behavior as well.
> 
> I can't find where it says lineWidth should be scaled . . .

It doesn't. But all implementations do it, as you pretty much be 
expected (otherwise drawings wouldn't scale right). The spec does not 
actually define what it means to stroke a line.  If it did, it would 
probably have to say something like this:

1) Transform all the points in the path using the inverse of the CTM to 
convert them from the canvas coordinate space to the current user 
coordinate space (or some such language).

2) Define rectangles around each straight line segment of the path, 
where each rectangle is lineWidth pixels wide, and connect these 
rectangles with caps, miters and so on.  (this is the part that would be 
a pain to spec, I think)  So now the path has been transformed into a 
set of polygons.

3) Transform those polygons back to the canvas coordinate space using 
the CTM and fill them.

I'm not trying to suggest that the spec needs to be modified to 
explicitly define how to stroke lines.  But without an explanation of 
the process, the handling of lineWidth is difficult to explain. 
Certainly just saying that lineWidth is measured in coordinate space 
units is not sufficient.  To me, it seems to imply that line width 
should never scale, and I don't think that is intended.

	David

>> But then in the definition of shadowOffsetX and Y, the spec reads:
>>
>>> Their values are in coordinate space units. They are not affected by the
>>> current transformation matrix.
>> The description of isPointInPath() uses similar language:
>>
>>>  when treated as coordinates in the canvas coordinate space unaffected by
>>> the current transformation,
>> So which is it?  Are "coordinate space units" affected by scaling or not?
> 
> As far as I can tell, no.  When the transformation matrix is used, it
> says so explicitly.  The language you point to for shadowOffset and
> isPointInPath is just a reminder.  I think.
> 
>>  Are lineWidths supposed to be scaled? (Implementations do so consistently)
> 
> I don't think they're supposed to be from reading the spec, although I
> don't know why not.  Maybe I'm missing something, or maybe this needs
> to be clarified.
> 
>> Are shadow offset supposed to be scaled? (Chrome does, Firefox and Opera do
>> not)
> 
> Doesn't it say explicitly that they shouldn't be?
> 
>> I think a clearer definition of coordinate spaces would be helpful. Maybe
>> "device space" for the underlying pixmap, "canvas space" for the coordinates
>> defined by the width and height attributes of the canvas, and "user space"
>> for the space defined by the current transformation matrix?
> 
> It might be a good idea to separate out the units for stuff affected
> by transformations vs. not, yeah.  I don't know why anything shouldn't
> be transformed by the current transformation matrix, though.
> 


From oliver at apple.com  Wed Jul 14 17:49:44 2010
From: oliver at apple.com (Oliver Hunt)
Date: Wed, 14 Jul 2010 17:49:44 -0700
Subject: [whatwg] Canvas "coordinate space units"
In-Reply-To: <4C3E5677.6030900@davidflanagan.com>
References: <4C3E0A08.4030702@davidflanagan.com>
	<AANLkTinKDGuiNL-XZHmeo3ggJaPDQiutqbwOk8EfT4QK@mail.gmail.com>
	<4C3E5677.6030900@davidflanagan.com>
Message-ID: <EAEA423C-2E6E-44C7-9B7E-E973D67957A1@apple.com>


On Jul 14, 2010, at 5:29 PM, David Flanagan wrote:

> Aryeh Gregor wrote:
>> On Wed, Jul 14, 2010 at 3:03 PM, David Flanagan <david at davidflanagan.com> wrote:
>>> I'm confused by the term "coordinate space units" as applied to the canvas
>>> spec.  It does not seem to be defined.
>> It seems clear to me.  
> 
> Even if clear, it is still undefined.  And the words "coordinate space" are so generic as to be meaningless here.  "canvas units" or something would make more sense.
> 
> The 2D context represents a Cartesian plane,
>> and the units for everything are units within that plane.  One
>> coordinate space unit might correspond to any number of pixels,
>> depending
<snip>
> As an aside, do you think any implementations actually do that?  It seems to me that it would cause real problems with drawImage(): images would look bad compared to drawn graphics...

WebKit supports device != css coordinates in its canvas implementation -- if you use QuartzDebug on Mac to change the resolution multiplier it causes a higher resolution backing buffer to be used.

--Oliver


From w3c at adambarth.com  Wed Jul 14 18:45:04 2010
From: w3c at adambarth.com (Adam Barth)
Date: Wed, 14 Jul 2010 18:45:04 -0700
Subject: [whatwg] postMessage's target origin argument can be a full URL
	in some implementations
In-Reply-To: <4C3E53D9.5000708@mit.edu>
References: <AANLkTilVWxoVPEWFHD0wb8778253X8mrn4Ryp3mJT6LS@mail.gmail.com> 
	<4C3E53D9.5000708@mit.edu>
Message-ID: <AANLkTim7IwXlYBKOoEBt-6jon7GPPYAEJCEsbqVjGNOB@mail.gmail.com>

On Wed, Jul 14, 2010 at 5:18 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> On 7/14/10 6:40 PM, Hallvord R M Steen wrote:
>>
>> My personal opinion is that protocol+host+port is better, simply
>> because authors might assume the path is significant (i.e. think that
>> 'http://www.geocities.com/foo' and 'http://www.geocities.com/bar'
>> would be different origins). Allowing paths that are simply ignored
>> might muddle the "origin" concept - not a major problem, but a small
>> potential point of confusion.
>
> I've actually used urls with a path for the origin; specifically when I
> wanted to pass in "the origin of this page". ?In particular, I passed in
> location.href.
>
> I'm fine with removing the ability to pass in a path _if_ we create a simple
> way for scripts to get origins from pages which can then be passed for this
> argument. ?The alternative is that scripts will be parsing location.href
> themselves to extract the thing to pass as the origin string, which is just
> asking for security fail in my experience.

Personally, I think we should stop screwing with postMessage and let
it be a stable enough API that folks can rely upon it.

Adam

From bzbarsky at MIT.EDU  Wed Jul 14 19:07:41 2010
From: bzbarsky at MIT