<br><br><div class="gmail_quote">On Thu, Jul 1, 2010 at 9:16 PM, Aryeh Gregor <span dir="ltr"><<a href="mailto:Simetrical%2Bw3c@gmail.com">Simetrical+w3c@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im">> As several people pointed out (and which I tried to get at in my post), this</div><div class="im">
> is really an ecosystem issue rather than a change needed in the spec or in<br>
> browsers.  I suspect it's going to take some time, but the flexibility of<br>
> embedding content via <iframe> will be a big step forward.<br>
<br>
</div>Wouldn't it be straightforward for YouTube to offer <iframe> support<br>
right now, in addition to <object>?  The backend support should be<br>
simple to do.  If you keep the <object> code as the default embed<br>
recommendation and hide the <iframe> embed code somewhere so people<br>
will only use it if they look for it, you won't risk confusing anyone.<br>
 Sites that currently whitelist <object> from YouTube will eventually<br>
whitelist <iframe> from YouTube too -- I hope there aren't many sites<br>
that permit *arbitrary* <object>s to be inserted by untrusted users.<br>
Allowing <iframe> will have other benefits, like allowing fallback<br>
"install Flash" content (currently omitted from the <object> code, I<br>
assume to keep the size down).<br></blockquote><div>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. </div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Another thing that occurs to me is that you might show HTML5 video<br>
when Flash isn't installed/enabled, or when the Flash player crashes.<br>
Or at least you could give an option, instead of just failing silently<br>
(for embeds) or saying the user should install Flash (on the site<br>
itself).  My primary machine runs Linux, and Flash usually doesn't<br>
work at all.  If I didn't know about the HTML5 beta, I wouldn't be<br>
able to use YouTube at all.  And as it is, I can't use any YouTube<br>
embeds most of the time.<br></blockquote><div>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.  </div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> When limiting keyboard input, I'd suggest devices w/ onscreen keyboards<br>
> simply disable the keyboard.  Applications that work well with touch<br>
> interfaces generally provide gesture alternatives for the limited set of<br>
> keys that would be available.  Alternately, devices could limit the keyboard<br>
> to the set of allowed keys.<br>
<br>
</div>The problem is if the program makes a fake keyboard and then directly<br>
intercepts touch events to that location, without invoking the OS's<br>
keyboard at all.  The user won't be able to tell that the keypresses<br>
are going to the website instead of the OS.  But I can't see this as<br>
being a big issue -- screen space is so limited on these devices that<br>
websites are fullscreen anyway, or practically.  On my Nexus One,<br>
unless you're scrolled to the top of the site, websites take up the<br>
whole screen except for the bar at the top, which is present in all<br>
apps.  So they could already trivially spoof any application, if they<br>
know the target platform.  Not if the user presses the menu button, I<br>
guess.<br></blockquote><div>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.</div>

<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
> As pointed out, this is not strictly an issue for <video> tag, though<br>
> certainly related especially for local preview.  I have not been closely<br>
> following the work on the <device> element, though that seems to be where<br>
> this is headed.<br>
<br>
</div><device> adoption shouldn't interfere with <video> adoption, though.<br>
Even if YouTube switched to <video> by default, it could keep Flash<br>
for recording until <device> was implemented.  It's probably best for<br>
implementers to focus on perfecting <video> (and maybe <canvas>, etc.)<br>
before they put too much work into <device>, since those are much<br>
bigger use-cases.<br></blockquote><div><br></div><div>You're absolutely right, and I think the order things are going is correct - <video> is more important than <device> </div></div><br>