Re: [whatwg] api for fullscreen()

On Fri, Jan 29, 2010 at 5:06 PM, Geoff Stearns 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) act

Re: [whatwg] api for fullscreen()

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 H

Re: [whatwg] api for fullscreen()

On Fri, Jan 29, 2010 at 4:06 PM, Kit Grose 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 disagree with it (except in

Re: [whatwg] api for fullscreen()

> > 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 U

Re: [whatwg] api for fullscreen()

> Block-level in what sense? is not block-level in any sense; One > could argue that and 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 saying "any e

Re: [whatwg] api for fullscreen()

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 p

Re: [whatwg] api for fullscreen()

> 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

Re: [whatwg] api for fullscreen()

On Fri, Jan 29, 2010 at 12:51 PM, Simon Fraser 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 > have we res

Re: [whatwg] history.back()

On Wed, 27 Jan 2010, Darin Fisher wrote: > > I think that location.hash = 'a' should synchronously add "#a" to the > session history, or at least it should appear to the web page that it > was added synchronously. > > [...] > > That said, I think it would be good for location.hash = 'a' to inte

Re: [whatwg] api for fullscreen()

On Jan 28, 2010, at 3:38 PM, Robert O'Callahan wrote: > On Thu, Jan 28, 2010 at 8:34 PM, Henri Sivonen 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 screen button

Re: [whatwg] api for fullscreen()

On Thu, Jan 28, 2010 at 8:34 PM, Henri Sivonen 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 > screen button in

Re: [whatwg] history.back()

On 1/28/10 7:15 AM, Darin Fisher wrote: That said, I think it would be good for location.hash = 'a' to interrupt the history.back() request. The net result being that "#a" is appended to session history, and the history.back() request is discarded. Really? What if iframe has been navigated la

Re: [whatwg] HttpOnly cookie for WebSocket?

On Thu, Jan 28, 2010 at 12:12 AM, Fumitoshi Ukai (鵜飼文敏) wrote: > May/Should WebSocket use HttpOnly cookie while Handshaking? WebSocket is a "stateful" protocol, and its cookie support is only applicable in interacting with the HTTP context .. and therefore the spec should simply refer to what's

Re: [whatwg] HttpOnly cookie for WebSocket?

Hi Ian, first I think it would be better have and maintain both whatwg and hybi mailing list in any conversation related to WebSocket at the BoF in Hiroshima there was a clear consensus from all the participants (both the one physically present and the one remotely attending via streaming a

Re: [whatwg] HttpOnly cookie for WebSocket?

On Thu, 28 Jan 2010, Salvatore Loreto wrote: > > a new IETF wg has been formed to take care of WebSocket protocol > HyBi: http://tools.ietf.org/wg/hybi/charters > So, this issue is something it should be discussed there > (btw I am forwdard it to the HyBi ml) > > N.B. to subscribe to the HyBi ml:

Re: [whatwg] HttpOnly cookie for WebSocket?

Hi, a new IETF wg has been formed to take care of WebSocket protocol HyBi: http://tools.ietf.org/wg/hybi/charters So, this issue is something it should be discussed there (btw I am forwdard it to the HyBi ml) N.B. to subscribe to the HyBi ml: https://www.ietf.org/mailman/listinfo/hybi /Sal A

[whatwg] HttpOnly cookie for WebSocket?

May/Should WebSocket use HttpOnly cookie while Handshaking? I think it would be useful to use HttpOnly cookie on WebSocket so that we could authenticate the WebSocket connection by the auth token cookie which might be HttpOnly for security reason. http://www.ietf.org/id/draft-ietf-httpstate-cookie