<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.26.3">
</HEAD>
<BODY>
On Tue, 2010-03-09 at 05:05 -0600, Sir Gallantmon (ニール・ゴンパ) wrote:
<BLOCKQUOTE TYPE=CITE>
2010/3/9 Ashley Sheridan <<A HREF="mailto:ash@ashleysheridan.co.uk">ash@ashleysheridan.co.uk</A>>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BLOCKQUOTE>
<BR>
</BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BLOCKQUOTE>
On Tue, 2010-03-09 at 04:47 -0600, Sir Gallantmon (ニール・ゴンパ) wrote: <BR>
<BLOCKQUOTE TYPE=CITE>
On Tue, Mar 9, 2010 at 4:09 AM, Ashley Sheridan <<A HREF="mailto:ash@ashleysheridan.co.uk">ash@ashleysheridan.co.uk</A>> wrote:<BR>
<BLOCKQUOTE>
<BR>
On Tue, 2010-03-09 at 03:00 +0100, Remco wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
On Tue, Mar 9, 2010 at 02:46, David Singer <<A HREF="mailto:singer@apple.com">singer@apple.com</A>> wrote:
> Kiosks and the like fall into the category where the user agent, hardware platform, and so on, are known in advance, so proprietary extensions or other special methods work just fine.
Until you find out that you can't change the infrastructure because
you would need to rewrite the application. You don't want to end up
with another IE6: an ancient application that you can't get rid of
because all intranet applications would break.
</PRE>
</BLOCKQUOTE>
<BR>
<BR>
I would expect the kiosks to have their own display mode which is fullscreen. If you need the video full-screen, just use CSS to style it. I don't think you should be able to display any HTML elements over the top of the browser window, as that would just lead to a whole world of pain. <BR>
<BR>
<BR>
<TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR>
<TD>
Thanks,<BR>
Ash<BR>
<A HREF="http://www.ashleysheridan.co.uk">http://www.ashleysheridan.co.uk</A><BR>
<BR>
<BR>
<BR>
<BR>
</TD>
</TR>
</TABLE>
</BLOCKQUOTE>
<BR>
Using CSS to do it actually sounds painful in itself. Doesn't that also mean that CSS needs to handle the video scaling too? what about the custom button controls? A simple API control that can be used to automatically scale the video to fullscreen size is better because then all that needs to be done in CSS is handle the controls for fullscreen mode.<BR>
<BR>
<BR>
And like I said earlier, Flash and Java have both been able to start in fullscreen mode for a long time now, and nobody has really taken advantage of that. And with HTML 5 implementations in browsers, they can always offer the option of disabling fullscreen API on load of page within browser preferences if you are really that worried.<BR>
<BR>
<BR>
The objective of the <video> and <audio> tags are to replace Flash and Silverlight in most cases. Fullscreen video is pretty damn huge oversight for the <video> tag, and for a reason that I basically invalidated.<BR>
<BR>
<BR>
At this point, I don't think people want to be stupid enough to implement their own proprietary display methods because it means they are trapped with that when the world moves forward. A good example is the IE6 dilemma that web developers face now. So many intranets were designed with IE6 in mind because they felt that way. When IE7 and IE8 broke them, they were screwed.<BR>
<BR>
<BR>
If you have a better reason for not including a standardized API for handling fullscreen mode for videos, say it. The reasons I'm reading so far don't really make sense....<BR>
</BLOCKQUOTE>
<BR>
<BR>
</BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BLOCKQUOTE>
Do you have an example of Flash video being made full-screen automatically, without the user intervening at all? I can't say I ever have, so if the spec must insist on allowing full-screen video through scripting, then safeguards need to be in place to allow it only to be triggered from a user action. This could introduce it's own issues, but that would be up to the user agent to solve I'd imagine.<BR>
<BR>
You do keep mentioning that Flash hasn't been exploited in such a manner before, but you ignore people when they say that just because a situation hasn't been exploited yet, doesn't mean it's gone. Also, you are not asking all the relevant questions about why it hasn't been exploited, which I'm mentioning here again (and I have before)
</BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BLOCKQUOTE>
<BR>
<BR>
<TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR>
<TD>
Thanks,<BR>
Ash<BR>
<A HREF="http://www.ashleysheridan.co.uk">http://www.ashleysheridan.co.uk</A><BR>
<BR>
<BR>
<BR>
</TD>
</TR>
</TABLE>
</BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BR>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
In the first place, I didn't say that the issue doesn't totally exist. I'm saying that because we're not dealing with Flash or Silverlight (which in most cases we can't really control what goes on inside of it), we can put safeguards for an API that makes the video fullscreen.
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BR>
<BR>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
I wouldn't want videos to automatically load in fullscreen either, but I definitely want to be able to click a button on the skinned player control or regular browser control and go into fullscreen mode, with new controls to match.
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BR>
<BR>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
Since you say you know why it hasn't been exploited before and you know that it will be exploited if it is included, tell me. Why?
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BR>
<BR>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
My whole point earlier was that even though Flash has the ability to do fullscreen automatically and be used for such exploits, that it hasn't been done. That doesn't mean that it will hold true for HTML5 video, but it does make the present argument invalid for not including it at all. I definitely understand including safeguards though. Safeguards are important for the entire HTML5 <video> API. With browsers that accept any video format (Chrome and Safari), they have to be careful that malware isn't embedded within the video itself, because some formats permit scripting or other kinds of code within the video container.
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BR>
<BR>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
We don't know the future, but we can prepare for it.
</BLOCKQUOTE>
<BR>
Hi, firstly, please don't just reply to me on this, we need to keep it on the list so that the discussion can benefit everyone.<BR>
<BR>
"Since you say you know why it hasn't been exploited before and you know that it will be exploited if it is included, tell me. Why?"<BR>
<BR>
I didn't say I knew why it hasn't been exploited, I said you weren't asking the question why it wasn't, and that I came up with one question: that I've never seen Flash able to do this automatically, which would reduce the chance of it being used for malicious reasons.<BR>
<BR>
I've just thought of another. As the video won't be rendered with a plugin but natively, wouldn't that mean that we can draw HTML over the top of it, and possibly within the video tags? Could you then not just replicate the page when in full-screen mode in order to trick the user into thinking they're just seeing a genuine dialogue window?<BR>
<BR>
<TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR>
<TD>
Thanks,<BR>
Ash<BR>
<A HREF="http://www.ashleysheridan.co.uk">http://www.ashleysheridan.co.uk</A><BR>
<BR>
<BR>
</TD>
</TR>
</TABLE>
</BODY>
</HTML>