[whatwg] More YouTube response

[John Harding]

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-0002.htm>