[whatwg] HTML 5 : The Youtube response

[Ian Fette (イアンフェッティ)]

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

http://www.mail-archive.com/whatwg@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-0001.htm>