Re: Fulscreen Tag Proposal

On Wed, Jul 21, 2010 at 1:20 AM, Paul Ellis <paul@ellisfoundation.com>wrote:

> Any solution that requires creating another window and opening a new
> document would create a lot of issues that would not compare favorably with
> any current popular web video plugin (Flash, Silverlight, etc). It would not
> be a very seemless transition. The <video> resource from the parent page may
> have downloaded hundreds of MB of data and then the new window would make a
> new separate request for the same resource. Certainly the browsers could try
> to aggressively cache video content for these situations but even that
> wouldn't work in all cases (any HTTP connection that doesn't allow byte
> range requests, e.g. HTTP 1.0), and it probably would not work very well for
> resource constrained devices such as smartphones and tablets. This type of
> hand-off would have to happen every time the user switched between
> fullscreen and embedded mode as well.
>

Just add an attribute called "source" to the <video> tag, which accepts the
ID of another <video> tag to display. This is just one of many possible
solutions to the reloading problem. There is no need to reload a video
twice.


> I think the goal should be to enable a way for the current browsing/viewing
> session to change context into a "fullscreen" mode. This fullscreen context
> still needs to support all of the typical HTML elements for things like
> custom video player controls.
>

But why would you need to reorganize a whole page just to display a simple
video? Unless you would have attributes regarding what happens in fullscreen
mode and what doesn't, like Daniel's idea.


> My thinking is that there should be some DOM attribute that would toggle a
> chromeless/fullscreen browsing state similar to Firefox's read-only
> window.fullscreen. The display of the page content including the video would
> be controlled/determined using CSS/JavaScript. The "SublimeVideo HTML5 Video
> Player" (http://jilion.com/sublime/video) is a great example of this type
> of player. This fullscreen viewing is experience is very comparable to
> current video plug-ins. All that is missing is that it can not remove the
> browser chrome. Some work would have to happen to keep this from being
> abused but that type of problem has already been solved in Flash and
> Silverlight and similar rules (e.g. users must initiate the fullscreen mode)
> would apply.
>
> Letting a page take over a screen is very problematic in terms of security.
You would probably need explicit permission for that using some kind of
alert. I completely agree that an attribute such as "window.fullscreen"
should be made writable to allow the current page to expand to the whole
screen, but for purposes of opening a new window with new content based on
the parent window, there are better solutions.


> Thoughts?
>
> Paul Ellis
>
> <http://www.linkedin.com/in/jpaulellis>
>
> On Tue, Jul 20, 2010 at 1:20 PM, Ron Reiter <ron.reiter@gmail.com> wrote:
>
>> I haven't noticed such a tag already exists for window.open.
>> True fullscreen support needs to be added, for better hardware level
>> support, such as other windowless plugins including Flash and Silverlight.
>> The current fullscreen tag only maximizes the window.
>>
>> Maybe a tag called maximize can be added, to better define fullscreen
>> mode. For example, maximize="borderless" will enable fullscreen with no
>> borders, and maximize="hardware" will switch to hardware fullscreen mode.
>> This mode could even turn the width and height attributes to specify and
>> control hardware level resolution of the screen, instead of window
>> dimensions.
>>
>> On Tue, Jul 20, 2010 at 11:01 PM, Ron Reiter <ron.reiter@gmail.com>wrote:
>>
>>> The correct design would be to use a window-less application for desktop
>>> applications, which then spawn windows using standard javascript and DOM
>>> (window.open function).
>>>
>>> http://www.pageresource.com/jscript/jwinopen.htm
>>>
>>> <http://www.pageresource.com/jscript/jwinopen.htm>Attributes such as
>>> width, height, scrollbars, toolbars, status bar, menubar, etc can be set.
>>>
>>> Adding an attribute "fullscreen=yes" could enable you to open a
>>> fullscreen window easily, using the currently implemented javascript
>>> support. That way, you won't need to reconsider the implicatoins such a tag
>>> has.
>>>
>>> Adding to your proposition, I suggest doing the opposite (which will
>>> eventually lead to the correct design of your idea) and adding a seperate
>>> DOCTYPE tag attribute called a "windowless application".
>>>
>>> Examples:
>>> <!DOCTYPE WLHTML>
>>> <!DOCTYPE HTML windowless="true">
>>>
>>> Since the DOCTYPE tag must be the first tag in an HTML document, browsers
>>> could open window-less applications without a window, and allow such web
>>> applications to use the standard javascript API to spawn windows.
>>>
>>> With the addition of a fullscreen tag, one could configure a desktop
>>> application to open a web application directly in fullscreen mode.
>>>
>>> This capability enables HTML5 to be more flexible than any browser based
>>> plugin in the world.
>>>
>>>
>>>
>>>
>>> On Wed, Jul 21, 2010 at 11:28 AM, Daniel Hendrycks <kondo8@hotmail.com>wrote:
>>>
>>>> On Tue, 20 Jul 2010 12:58:29 -0600, Ron Reiter <ron.reiter@gmail.com>
>>>> wrote:
>>>>
>>>> I do think there is room for proposing tags for desktop applications
>>>>
>>>> I am proposing this for HTML5, which is rendered by desktop
>>>> applications. I cannot really understand what you are saying, if you don't
>>>> want HTML5 to interact with the device, then that is quite contrary to
>>>> things that are in drafts for HTML5. Today, HTML Media Capture went in a
>>>> draft phase, that interacts with the device; that could be a security
>>>> concern, too (you mentioned security as an issue for the tag, earlier).
>>>> http://www.w3.org/TR/2010/WD-html-media-capture-20100720/
>>>>
>>>> "This puts HTML in direct competition with other technologies intended
>>>> for applications deployed over the Web, in particular Flash and
>>>> Silverlight." -Ian Hickson
>>>> http://lists.w3.org/Archives/Public/public-html/2009Jan/0215.html
>>>>
>>>> As you can see, HTML5 is in competition with plug-ins, plug-ins can go
>>>> in fullscreen. YouTube said HTML is not ready for YouTube, one of the
>>>> reasons stated was: "HD video begs to be watched in full screen, but that
>>>> has not historically been possible with pure HTML."
>>>>
>>>> There is a need for Fullscreen, I believe the syntax I gave is simple
>>>> enough to make it possible.
>>>>
>>>> --
>>>> Daniel Hendrycks <http://my.opera.com/DanielHendrycks/>
>>>>
>>>
>>>
>>>
>>> --
>>> -- Ron
>>>
>>
>>
>>
>> --
>> -- Ron
>>
>
>


-- 
-- Ron