On Feb 4, 2010, at 16:53 , Kit Grose wrote:
I also develop kiosk and medical applications where fullscreen is not only
desirable but necessary behaviour. Crippling the API such that the developer
cannot determine whether or not the user permitted their application to run
fullscreen is
On Feb 3, 2010, at 15:03 , Kit Grose wrote:
I feel that the user shouldn't have the ability to enter into some sort of
pseudo-fullscreen. If the content needs to be displayed full-screen,
I don't believe that there is any such 'need' and that the user should own that
decision. I, for
On 05/02/2010, at 8:08 AM, David Singer wrote:
On Feb 3, 2010, at 15:03 , Kit Grose wrote:
I feel that the user shouldn't have the ability to enter into some sort of
pseudo-fullscreen. If the content needs to be displayed full-screen,
I don't believe that there is any such 'need' and that
Brian Campbell writes:
I'm a bit concerned about when the fullscreen events and styles apply,
though. If the page can tell whether or not the user has actually
allowed it to enter fullscreen mode, it can refuse to display content
until the user gives it permission to enter fullscreen mode.
On Feb 3, 2010, at 5:04 AM, Smylers wrote:
Brian Campbell writes:
I'm a bit concerned about when the fullscreen events and styles apply,
though. If the page can tell whether or not the user has actually
allowed it to enter fullscreen mode, it can refuse to display content
until the user
Another scenario applies to most video player sites. Almost all video player
sites using Flash have a full screen button. Many of them do not have a full
window button, however. If a user wishes to view content scaled up to fill
the window, without the distractions of navigational links,
Brian Campbell writes:
As I understand it, the risk with full-screen view is that a
malicous site may spoof browser chrome, such as the URL bar, thereby
tricking a user who isn't aware the site is full-screen.
This is addressing a different scenario; not malicious sites per-se,
but
On Feb 3, 2010, at 7:19 PM, Smylers wrote:
Brian Campbell writes:
As I understand it, the risk with full-screen view is that a
malicous site may spoof browser chrome, such as the URL bar, thereby
tricking a user who isn't aware the site is full-screen.
This is addressing a different
On Mon, Feb 1, 2010 at 4:41 PM, Brian Campbell lam...@continuation.org wrote:
This could lead to the problem that Hixie mentions, of training users to
click through security dialogs, even if this is done through a drop-down
asynchronous notification instead of a modal dialog.
I'd hope that
On Jan 31, 2010, at 05:08, Simon Fraser wrote:
* disallow enterFullscreen() from a frame or iframe
This might be a problem if video sites transition their embedding boilerplate
to an iframe in order to be able to be able to serve HTML5, Flash, ActiveX,
etc. depending on UA without requiring
On Feb 1, 2010, at 1:14 AM, Henri Sivonen wrote:
On Jan 31, 2010, at 05:08, Simon Fraser wrote:
* disallow enterFullscreen() from a frame or iframe
This might be a problem if video sites transition their embedding boilerplate
to an iframe in order to be able to be able to serve HTML5,
The enableKeys parameter to enterFullscreen is a hint to the UA that the
application would like to be able to receive arbitrary keyboard input.
Otherwise the UA is likely to disable alphanumeric keyboard input. If
enableKeys is specified, the UA might require more severe confirmation UI.
On Thu, Jan 28, 2010 at 8:55 PM, Robert O'Callahan rob...@ocallahan.org wrote:
On Fri, Jan 29, 2010 at 5:06 PM, Geoff Stearns tensafefr...@google.com
wrote:
enterFullscreen always returns immediately. If fullscreen mode is
currently supported and permitted, enterFullscreen dispatches a task
On Tue, Feb 2, 2010 at 7:39 AM, Kenneth Russell k...@google.com wrote:
When you say that the DOM viewport of the element is aligned with the
screen when it goes fullscreen, does that mean that the .width and
.height properties are changed? Or does it mean that the element's
size is changed by
On Mon, Feb 1, 2010 at 11:05 AM, Robert O'Callahan rob...@ocallahan.org wrote:
On Tue, Feb 2, 2010 at 7:39 AM, Kenneth Russell k...@google.com wrote:
When you say that the DOM viewport of the element is aligned with the
screen when it goes fullscreen, does that mean that the .width and
On Jan 28, 2010, at 9:42 PM, Robert O'Callahan wrote:
enterFullscreen always returns immediately. If fullscreen mode is currently
supported and permitted, enterFullscreen dispatches a task that a) imposes
the fullscreen style, b) fires the beginfullscreen event on the element and
c)
On Tue, Feb 2, 2010 at 5:00 AM, Simon Fraser s...@me.com wrote:
On Feb 1, 2010, at 1:14 AM, Henri Sivonen wrote:
On Jan 31, 2010, at 05:08, Simon Fraser wrote:
* disallow enterFullscreen() from a frame or iframe
This might be a problem if video sites transition their embedding
On Tue, Feb 2, 2010 at 10:41 AM, Brian Campbell lam...@continuation.orgwrote:
I'm a bit concerned about when the fullscreen events and styles apply,
though. If the page can tell whether or not the user has actually allowed it
to enter fullscreen mode, it can refuse to display content until the
On Feb 1, 2010, at 5:38 PM, Robert O'Callahan wrote:
On Tue, Feb 2, 2010 at 10:41 AM, Brian Campbell lam...@continuation.org
wrote:
I'm a bit concerned about when the fullscreen events and styles apply,
though. If the page can tell whether or not the user has actually allowed it
to enter
On Sun, 31 Jan 2010 03:43:49 +0100, Simon Fraser s...@me.com wrote:
On Jan 30, 2010, at 1:24 PM, Anne van Kesteren wrote:
To stop polluting the Window object, might it make sense to put the new
members (other than event handler attributes) on window.screen?
This would require that the
On 1/31/10 6:38 AM, Tab Atkins Jr. wrote:
This one seems kind of weird. Does the spec currently distinguish
significantly between a user-initiated click and a script-initiated
one?
DOM 3 Events draft does have the concept of trusted events;
UA/user generated events are trusted, script
On Jan 29, 2010, at 9:54 PM, Robert O'Callahan wrote:
So how about a Window API with an optional element component:
void enterFullscreen(optional DOMElement element, optional boolean
enableKeys);
void exitFullscreen();
boolean attribute supportsFullscreen;
boolean attribute
On Sat, 30 Jan 2010 22:12:47 +0100, Simon Fraser s...@me.com wrote:
On Jan 29, 2010, at 9:54 PM, Robert O'Callahan wrote:
So how about a Window API with an optional element component:
void enterFullscreen(optional DOMElement element, optional boolean
enableKeys);
void exitFullscreen();
On Thu, Jan 28, 2010 at 6:42 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
On Fri, Jan 29, 2010 at 12:51 PM, Simon Fraser s...@me.com wrote:
We have been discussing a more general fullscreen API that lets you take
the page fullscreen (perhaps with the ability to focus on a single element),
On Fri, Jan 29, 2010 at 11:54 PM, Robert O'Callahan
rob...@ocallahan.org wrote:
While a window is
fullscreen, the root element and the designated fullscreen element, if any,
are given a pseudoclass fullscreen. Then you can have some default rules
in the UA style sheet:
*:root:fullscreen {
On Jan 30, 2010, at 1:24 PM, Anne van Kesteren wrote:
On Sat, 30 Jan 2010 22:12:47 +0100, Simon Fraser s...@me.com wrote:
On Jan 29, 2010, at 9:54 PM, Robert O'Callahan wrote:
So how about a Window API with an optional element component:
void enterFullscreen(optional DOMElement element,
On Jan 28, 2010, at 6:42 pm, Robert O'Callahan wrote:
On Fri, Jan 29, 2010 at 12:51 PM, Simon Fraser s...@me.com wrote:
We have been discussing a more general fullscreen API that lets you take the
page fullscreen (perhaps with the ability to focus on a single element), as
Maciej mentions.
On Sat, Jan 30, 2010 at 9:08 PM, Simon Fraser s...@me.com wrote:
* require that enterFullscreen() is being called inside a user-event handler
(e.g. click or keypress) to avoid drive-by fullscreen annoyances.
This one seems kind of weird. Does the spec currently distinguish
significantly
On 1/30/10 11:38 PM, Tab Atkins Jr. wrote:
On Sat, Jan 30, 2010 at 9:08 PM, Simon Frasers...@me.com wrote:
* require that enterFullscreen() is being called inside a user-event handler
(e.g. click or keypress) to avoid drive-by fullscreen annoyances.
This one seems kind of weird. Does the
On 1/28/10 10:41 PM, Kit Grose wrote:
True, but surely saying any element opens the door to full-screening inline text
elements (e.gspan elements).
I don't see why this is a problem, offhand.
I suppose the native style being position: fixed would put those elements in
a block formatting
On Jan 28, 2010, at 6:42 PM, Robert O'Callahan wrote:
On Fri, Jan 29, 2010 at 12:51 PM, Simon Fraser s...@me.com wrote:
We have been discussing a more general fullscreen API that lets you take the
page fullscreen (perhaps with the ability to focus on a single element), as
Maciej mentions.
While an element is fullscreen, the UA imposes CSS style
position:fixed; left:0; top:0; right:0; bottom:0 on the element and
aligns the viewport of its DOM window with the screen. Only the
element and its children are rendered, as a single CSS stacking context.
So this makes it a very
On Sat, Jan 30, 2010 at 5:49 AM, Simon Fraser s...@me.com wrote:
On Jan 28, 2010, at 6:42 PM, Robert O'Callahan wrote:
1) Should be convenient for authors to make any element in a page display
fullscreen
2) Should support in-page activation UI for discoverability
I agree with Boris that
On Jan 28, 2010, at 3:38 PM, Robert O'Callahan wrote:
On Thu, Jan 28, 2010 at 8:34 PM, Henri Sivonen hsivo...@iki.fi wrote:
I haven't seen a proposal, but it looks like code has landed:
http://trac.webkit.org/changeset/50893
Demo: http://jilion.com/sublime/video
(option-click the full
On Fri, Jan 29, 2010 at 12:51 PM, Simon Fraser s...@me.com wrote:
We have been discussing a more general fullscreen API that lets you take
the page fullscreen (perhaps with the ability to focus on a single element),
as Maciej mentions. We have not decided on a final form for this API, nor
1) Should be convenient for authors to make any element in a page display
fullscreen
2) Should support in-page activation UI for discoverability
3) Should support changing the layout of the element when you enter/exit
fullscreen mode. For example, authors probably want some controls to be
On 1/28/10 10:06 PM, Kit Grose wrote:
1) Should be convenient for authors to make any element in a page display
fullscreen
2) Should support in-page activation UI for discoverability
3) Should support changing the layout of the element when you enter/exit
fullscreen mode. For example, authors
Block-level in what sense? img is not block-level in any sense; One
could argue that video and object are block-level in HTML terms,
but it's context-dependent (they can contain blocks if their parent
can). None of these are block-level in the CSS sense, by default.
True, but surely
enterFullscreen always returns immediately. If fullscreen mode is currently
supported and permitted, enterFullscreen dispatches a task that a) imposes
the fullscreen style, b) fires the beginfullscreen event on the element and
c) actually initiates fullscreen display of the element. The UA
On Fri, Jan 29, 2010 at 4:06 PM, Kit Grose k...@iqmultimedia.com.au wrote:
Regarding point 1, surely any fullscreen API should only support
block-level elements?
I don't see why. Setting position:fixed does what you want in the cases I
can think of.
If I'm reading point 2 correctly, I
On Thu, 28 Jan 2010, Geoff Stearns wrote:
I think it would suffice to simply show a dialog the first time a user
wants to go fullscreen within a domain with an option to remember this
choice for this domain.
Users click through dialogs without looking, so that wouldn't work.
--
Ian
On Fri, Jan 29, 2010 at 5:06 PM, Geoff Stearns tensafefr...@google.comwrote:
enterFullscreen always returns immediately. If fullscreen mode is currently
supported and permitted, enterFullscreen dispatches a task that a) imposes
the fullscreen style, b) fires the beginfullscreen event on the
2009/12/17 Maciej Stachowiak m...@apple.com
1) It handles some very common use cases (including likely one of the
*most* common, video) in a way that's much simpler for the content author.
2) The browser will have the option to animate the transition to fullscreen
starting from the target
On Dec 17, 2009, at 1:52 AM, Simon Pieters wrote:
On Thu, 17 Dec 2009 10:30:26 +0100, Maciej Stachowiak
m...@apple.com wrote:
Some of us at Apple have discussed fullscreen APIs, and we think a
user gesture requirement plus clear indication of what has happened
is likely sufficient.
2009/12/17 Ian Fette (イアンフェッティ) ife...@google.com
I'm not convinced we actually need opt-in, though if we did have opt-in it
should allow the user to persist that choice (don't ask me for permission
each time i try to fullscreen a youtube video.)
Sure.
I would much rather go for user
On Thu, Dec 17, 2009 at 12:12 AM, Robert O'Callahan
rob...@ocallahan.org wrote:
2009/12/17 Ian Fette (イアンフェッティ) ife...@google.com
I'm not convinced we actually need opt-in, though if we did have opt-in it
should allow the user to persist that choice (don't ask me for permission
each time i
2009/12/17 Jonas Sicking jo...@sicking.cc
Technically speaking this isn't something that needs to be
standardized. All we need is a standardized fullscreen() function
somewhere, and possibly standardized fullscreenon/fullscreenoff
events. Browsers are free to implement whatever UI they want
Some of us at Apple have discussed fullscreen APIs, and we think a
user gesture requirement plus clear indication of what has happened is
likely sufficient.
As to the API itself: we tentatively think a good API would be to make
a specific *element* go full screen, rather than the whole
On Thu, 17 Dec 2009 10:30:26 +0100, Maciej Stachowiak m...@apple.com
wrote:
Some of us at Apple have discussed fullscreen APIs, and we think a user
gesture requirement plus clear indication of what has happened is likely
sufficient.
As to the API itself: we tentatively think a good API
2009/12/17 Jonas Sicking jo...@sicking.cc:
I guess that if you enforced that fullscreen could only happen in
response to a click then you are in better shape.
Browsers already have heuristics just like this for opening popup
windows, don't they? They seem to work pretty well to prevent pages
I love the idea of fullscreen() and on* events for developers and letting
the browsers come up with smart ways to do as much as they can to protect
users (as they have done countless times before with popups, phishing, etc).
We can't say no to every feature because some poor user may click on
2009/12/16 Jonas Sicking jo...@sicking.cc:
2009/12/16 Ian Fette (イアンフェッティ) ife...@google.com:
I think what I've heard from application developers over and over again is
that, while the UA may provide some way to go into full screen from in the
browser chrome, it is much more discoverable when
It would be really nice if the html5 spec supported a javascript call to
set a target window to fullscreen. The browser would then issue a
security warning at the top of the page (similar to pop-ups) and then
the user could grant that domain permission to go full-screen.
This is especially
On Wed, 16 Dec 2009, Michael Dale wrote:
It would be really nice if the html5 spec supported a javascript call to
set a target window to fullscreen. The browser would then issue a
security warning at the top of the page (similar to pop-ups) and then
the user could grant that domain
On Thu, Dec 17, 2009 at 11:42 AM, Ian Hickson i...@hixie.ch wrote:
On Wed, 16 Dec 2009, Michael Dale wrote:
It would be really nice if the html5 spec supported a javascript call to
set a target window to fullscreen. The browser would then issue a
security warning at the top of the page
I think what I've heard from application developers over and over again is
that, while the UA may provide some way to go into full screen from in the
browser chrome, it is much more discoverable when that capability exists
from within the content area (e.g. people are used to clicking on the full
2009/12/16 Ian Fette (イアンフェッティ) ife...@google.com:
I think what I've heard from application developers over and over again is
that, while the UA may provide some way to go into full screen from in the
browser chrome, it is much more discoverable when that capability exists
from within the
2009/12/16 Jonas Sicking jo...@sicking.cc
2009/12/16 Ian Fette (イアンフェッティ) ife...@google.com:
I think what I've heard from application developers over and over again
is
that, while the UA may provide some way to go into full screen from in
the
browser chrome, it is much more discoverable
2009/12/16 Ian Fette (イアンフェッティ) ife...@google.com:
2009/12/16 Jonas Sicking jo...@sicking.cc
2009/12/16 Ian Fette (イアンフェッティ) ife...@google.com:
I think what I've heard from application developers over and over again
is
that, while the UA may provide some way to go into full screen from in
2009/12/16 Jonas Sicking jo...@sicking.cc
2009/12/16 Ian Fette (イアンフェッティ) ife...@google.com:
2009/12/16 Jonas Sicking jo...@sicking.cc
2009/12/16 Ian Fette (イアンフェッティ) ife...@google.com:
I think what I've heard from application developers over and over
again
is
that, while the UA
2009/12/17 Ian Fette (イアンフェッティ) ife...@google.com
I think what I've heard from application developers over and over again is
that, while the UA may provide some way to go into full screen from in the
browser chrome, it is much more discoverable when that capability exists
from within the
2009/12/16 Robert O'Callahan rob...@ocallahan.org
2009/12/17 Ian Fette (イアンフェッティ) ife...@google.com
I think what I've heard from application developers over and over again is
that, while the UA may provide some way to go into full screen from in the
browser chrome, it is much more
62 matches
Mail list logo
