[whatwg] Fullscreen for HTML5 Video element
ash at ashleysheridan.co.uk
Tue Mar 9 03:07:53 PST 2010
On Tue, 2010-03-09 at 05:05 -0600, Sir Gallantmon (ニール・ゴンパ)
> 2010/3/9 Ashley Sheridan <ash at ashleysheridan.co.uk>
> On Tue, 2010-03-09 at 04:47 -0600, Sir Gallantmon (ニール・ゴ
> ンパ) wrote:
> > On Tue, Mar 9, 2010 at 4:09 AM, Ashley Sheridan
> > <ash at ashleysheridan.co.uk> wrote:
> > On Tue, 2010-03-09 at 03:00 +0100, Remco wrote:
> > > On Tue, Mar 9, 2010 at 02:46, David Singer <singer at apple.com> 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.
> > >
> > 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.
> > Thanks,
> > Ash
> > http://www.ashleysheridan.co.uk
> > 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.
> > 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.
> > 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.
> > 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.
> > 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....
> 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.
> 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)
> 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.
> 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.
> 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?
> 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.
> We don't know the future, but we can prepare for it.
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.
"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?"
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.
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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the whatwg