Re: [whatwg] api for fullscreen()
On Jan 28, 2010, at 04:38, Robert O'Callahan wrote: > 2009/12/17 Maciej Stachowiak >> 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 element, in a clean way. If content has to make >> layout changes by hand to limit itself to the specific fullscreen target, >> then it's extremely difficult, perhaps impossible, for the browser to do a >> single smooth animated transition without any unwanted flickering or layout >> thrash. >> >> We don't have a specific API proposal to make right now, but I'll try to get >> the people working on this to put forward a concrete proposal soon. >> > Did that happen? 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 a fresh WebKit nigthly) -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] history.back()
On Wed, Jan 27, 2010 at 3:26 PM, Ian Hickson wrote:
>
> > > Another is what should happen if a page goes back() past its fragment
> > > identifier entries, and then modifies the document or alerts the
> > > location? What location should it get? Which document should it
> > > mutate? (test 007)
> > >
> > > How about:
> > >
> > > location.hash = 'a';
> > > /* spin event loop */
> > > history.back();
> > > location.hash = 'b';
> > > history.forward();
> > > alert(location.hash);
> > > /* spin event loop */
> > > alert(location.hash);
> >
> > It would be nice if the navigation and history traversal algorithms did
> > not proceed while the page is blocked on a modal alert.
>
> Sure, but what should alert?
>
> I guess you're saying we should have "b" and "b" here.
>
Yeah, exactly.
>
>
> > > How about:
> > >
> > > location.hash = 'x';
> > > location.hash = 'a';
> > > /* spin event loop */
> > > history.back();
> > > /* spin event loop */
> > > history.forward();
> > > location.hash = 'b';
> > > /* spin event loop */
> > > history.back();
> > > /* spin event loop */
> > > alert(location.hash);
> > >
> > > What does this alert? (test 010)
>
> For this I guess you are saying we should alert "x"?
>
Yes.
>
>
> > I think it would be risky to make navigation to fragment identifiers
> > asynchronously set Location. All browsers do so synchronously today, so
> > I wouldn't be surprised to find that it matters.
>
> Ok, but when should the session history be traversed? Synchronously or
> not?
>
> If you do:
>
> location.hash = 'a';
> location.hash = 'b';
>
> ...and then spin the event loop, then the user hits "back", do you end up
> at "a", or did "a" never get added to the history?
>
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.
In the example you gave above,
location.hash = 'a' // appends "#a" to session history
location.hash = 'b' // appends "#b" to session history
spin the event loop // not significant
user hits "back" // queues a task on the event loop to traverse session
history back one step
spin the event loop // "#a" is the current session history entry
>
> If you do:
>
> history.back();
> location.hash = 'a';
>
> ...do you end up with a no-op (synchronously traverse history to #a while
> the script is running, then go back in a task), or do you end up at a
> different page (go back to the previous page in a task, then do nothing
> with the location.href because the task for traversing its history is
> tossed when you switch to another page)? Or something else?
>
Hmm, good question... I'm not sure how much this matters.
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.
>
> If location changes traverse synchronously, there doesn't seem to be any
> benefit to making history.back() asynchronous -- it's the same algorithm.
>
>
I don't follow this implication. Can you clarify?
I'm trying to treat history,{back,forward,go} as a UI command to the
navigator. Synthesize
the user clicking on the corresponding back/forward buttons. UI actions
typically do not
get dispatched during JS execution (ignoring window.showModalDialog of
course).
>
> > > Should Location be set synchronously but with the session history
> > > actually being updated asynchronously using a task, so that .back()
> > > and .forward() calls get interleaved with the Location setter?
> >
> > I think this would be problematic in other cases. Imagine this
> > scenario:
> >
> > location="#a";
> > pushState("b", "b", "#b");
> > location="#c"; // generates a synchronous popstate event
>
> (I assume you mean a hashchange event, not popstate.)
>
Oops, yes. This is a bad example. Nevermind.
>
> We can have synchronous traversal with asynchronous event dispatch, so I
> don't think that's really a problem.
>
>
> > > Should document.open() synchronously clear the session history, or
> > > should it asynchronously queue a task and do it that way? Should we,
> > > instead of using tasks that could run much later (e.g. if the script
> > > has previously invoked a bunch of setTimeout(0)s), add a step to the
> > > event loop so that after each task, any history traversal that's been
> > > queued up gets processed immediately?
> >
> > non-FIFO queuing makes me nervous ;-)
>
> It's not clear to me exactly what you want specced. Changing the location
> without traversing makes me pretty nervous (more so than non-FIFO
> queueing), but I don't know if that's what you want.
>
I agree that we should not change the location without traversing history.
I'm arguing for making history.{back,forward,go} start out by dispatching a
task
to then run the history traversal algorithm. So, history.back() would never
change
the
Re: [whatwg] api for fullscreen()
2009/12/17 Maciej Stachowiak > 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 element, in a clean way. If content has to make > layout changes by hand to limit itself to the specific fullscreen target, > then it's extremely difficult, perhaps impossible, for the browser to do a > single smooth animated transition without any unwanted flickering or layout > thrash. > > We don't have a specific API proposal to make right now, but I'll try to > get the people working on this to put forward a concrete proposal soon. > Did that happen? The idea of making a particular element (ideally, any HTML element) fullscreen is intriguing, because as you say it's convenient for authors and it lets the browser provide useful UI cues for the transition to fullscreen mode. It's not completely clear to me what the actual behavior is, though. Does it mean you just scale up the bounding-box of the element to cover the screen? What if all or part of the element is scrolled out of view, display:none, etc? Are you drawing the element, or actually the contents of the whole window? (I.e., do effects imposed by container elements like 'opacity' take effect?) As for security, apparently Flash makes alphanumeric key input exit fullscreen mode, which seems adequate to avoid password spoofing, and still leaves a few keys usable for games. Perhaps the method to active fullscreen mode could have a parameter to request arbitrary key input, and that could require more explicit opt-in from the user. Although it just occurred to me that for devices without keyboards, disabling keyboard input isn't necessarily a useful anti-spoofing measure. Rob -- "He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]
Re: [whatwg] History API, pushState(), and related feedback
On Fri, 22 Jan 2010, Mike Wilson wrote:
>
> I'll keep this short as there is more recent discussion:
> 2) The pageStorage object is one incarnation of [a key
>value store] solving the dependency problem that appears
>when different components want to save data to the single
>session history state object
I'm really not convinced this is a problem we need to solve. There are
plenty of places where the Web platform doesn't cater for different parts
of a page being written by different people who aren't coordinating. The
whole DOM, for instance. Event handler attributes. All the storage APIs.
Cookies. URLs. Huge parts of the platform assume that you should
coordinate your code. I think doing so is good practice in general.
> And the later part is more about general properties of
> API design:
> 3) If a key-value store is desired, then using the same API
>as the other key-value stores is a strength and not an over-
>generalisation. The web doesn't need yet another API.
> 4) Thinking about possible future additions when choosing
>names is one part (of many) of a successful design.
I don't understand the above points.
> Let's say that we have two components, A and B, that are not aware of
> each other but both want to save state to the history state.
>
> The author could make an app-global save function that connects to all
> update notifications from all components and does:
>
> function saveItAll() {
> History.replaceState({
> A: A.serializeState(),
> B: B.serializeState()
> });
> }
>
> The above has two drawbacks:
> - the global function has to be maintained when components
> are added or removed
> - even if only one component's data is updated (triggering
> the save function), all component serialization has to
> be executed even if not changed
>
> Trying to fix this, we would want to set each part of the state
> separately so each component can handle its own updates:
>
> A.saveMe: function() {...}
> ...
> B.saveMe: function() {...}
>
> and no global coordination would be needed. But the problem is that when
> A.saveMe wants to store its latest data, it must also have all other
> data, and to be able to have the latest state we need a getter:
>
> A.saveMe: function() {
> var data = History.getState();
> data.A = A.serializeState();
> History.replaceState(data);
> }
>
> With this solution components can have a loose cooperation by just
> agreeing on a general data format (f ex map). Without the getter,
> components can no longer use the History API directly, but instead have
> to call through a wrapper that caches the latest state in a variable:
>
> A.saveMe: function() {
> var data = MyHistoryWrapper.getState();
> data.A = A.serializeState();
> MyHistoryWrapper.replaceState(data);
> };
> MyHistoryWrapper.replaceState = function(data) {
> this.cache = data;
> History.replaceState(data);
> };
>
> Now components not only have to cooperate on a data format, but also on
> a non-standard API.
>
> Of course this use case had been better served by a key- value store
> like pageStorage mentioned above. But having a getter takes us at least
> halfway there.
This is just making the whole problem massively over-complicated.
Just have a global function for pushing state that takes the name of the
module saving state, and have it keep a copy of the "current" state, so
that it can just update the current state without reserialising
everything, and can store the state of each module. Then when there's a
popstate, it can see which of the modules changed states and invoke the
relevant callback. This is a few dozen lines of code tops, and that's
including error handling and so on.
Depending on exactly what you're doing, you can make it even simpler.
All the components have to coordinate _anyway_ to get the URL
representation of the state into some sane form that all the components
can understand. So I really don't think the state object needs special API
functions to make this easier.
> [...] Ie, this data is persisted on demand at a certain point in the
> history entry's life cycle, just as I am suggesting for the pushState
> state.
>
> With the same reasoning as for current pushState, the spec would instead
> suggest that scroll position and form control values were persisted
> immediately when changed, instead of at the "leave history entry" event.
The problem is that you really want the URL to always be up to date, so
that the user can copy it. And thus you really want to be calling
pushState() whenever the state changes.
(The state stored in the state object shouldn't be especially hard to
serialise; back/forward is a UI state navigation, not a data state
navigation. It's not like in a word processor the user'll hit back and
want the page to store the whole state of the user's writings into the
history -- the text should be autosaving anyway. Hitting "back" wo
Re: [whatwg] history.back()
On Fri, 22 Jan 2010, Darin Fisher wrote:
> On Fri, Jan 22, 2010 at 2:08 AM, Ian Hickson wrote:
> > On Thu, 21 Jan 2010, Darin Fisher wrote:
> > >
> > > In WebKit, history.back() is currently implemented asynchronously.
> >
> > It's not clear to me what you mean by "asynchronously".
> >
> > Do you mean that the events fire asynchronously? That the Location
> > object is updated asynchronously? That the decision about whether the
> > call is a noop or not is fired asynchronously? That the navigation, if
> > one is necessary, is done asynchronously? Are we talking about
> > same-frame, or cross-frame? Same-origin, or cross-origin? Traversal
> > from one entry in one document to another entry in the same document,
> > or in another document?
>
> To clarify:
>
> history.{back,forward,go} begin by scheduling a task on the current
> thread to run later. From that task, the history traversal algorithm is
> executed.
Ah, ok.
> > Another is what should happen if a page goes back() past its fragment
> > identifier entries, and then modifies the document or alerts the
> > location? What location should it get? Which document should it
> > mutate? (test 007)
> >
> > How about:
> >
> > location.hash = 'a';
> > /* spin event loop */
> > history.back();
> > location.hash = 'b';
> > history.forward();
> > alert(location.hash);
> > /* spin event loop */
> > alert(location.hash);
>
> It would be nice if the navigation and history traversal algorithms did
> not proceed while the page is blocked on a modal alert.
Sure, but what should alert?
I guess you're saying we should have "b" and "b" here.
> > How about:
> >
> > location.hash = 'x';
> > location.hash = 'a';
> > /* spin event loop */
> > history.back();
> > /* spin event loop */
> > history.forward();
> > location.hash = 'b';
> > /* spin event loop */
> > history.back();
> > /* spin event loop */
> > alert(location.hash);
> >
> > What does this alert? (test 010)
For this I guess you are saying we should alert "x"?
> I think it would be risky to make navigation to fragment identifiers
> asynchronously set Location. All browsers do so synchronously today, so
> I wouldn't be surprised to find that it matters.
Ok, but when should the session history be traversed? Synchronously or
not?
If you do:
location.hash = 'a';
location.hash = 'b';
...and then spin the event loop, then the user hits "back", do you end up
at "a", or did "a" never get added to the history?
If you do:
history.back();
location.hash = 'a';
...do you end up with a no-op (synchronously traverse history to #a while
the script is running, then go back in a task), or do you end up at a
different page (go back to the previous page in a task, then do nothing
with the location.href because the task for traversing its history is
tossed when you switch to another page)? Or something else?
If location changes traverse synchronously, there doesn't seem to be any
benefit to making history.back() asynchronous -- it's the same algorithm.
> > Should Location be set synchronously but with the session history
> > actually being updated asynchronously using a task, so that .back()
> > and .forward() calls get interleaved with the Location setter?
>
> I think this would be problematic in other cases. Imagine this
> scenario:
>
> location="#a";
> pushState("b", "b", "#b");
> location="#c"; // generates a synchronous popstate event
(I assume you mean a hashchange event, not popstate.)
We can have synchronous traversal with asynchronous event dispatch, so I
don't think that's really a problem.
> > Should document.open() synchronously clear the session history, or
> > should it asynchronously queue a task and do it that way? Should we,
> > instead of using tasks that could run much later (e.g. if the script
> > has previously invoked a bunch of setTimeout(0)s), add a step to the
> > event loop so that after each task, any history traversal that's been
> > queued up gets processed immediately?
>
> non-FIFO queuing makes me nervous ;-)
It's not clear to me exactly what you want specced. Changing the location
without traversing makes me pretty nervous (more so than non-FIFO
queueing), but I don't know if that's what you want.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] about:blank synchronicity
On 1/27/10 3:53 AM, Ian Hickson wrote: Would it have other problems? Are there cases other than navigation where about:blank being synchronous is detectable? (I couldn't find any.) I'm not sure what you're asking here... I mean, like, does it matter if about:blank is synchronous in, or in CSS in a url(), or something like that? Oh. I don't think about:blank should be special in any of those contexts, no. -Boris
Re: [whatwg] [html5] r4627 - [e] (0) some editorial improvements to 'the indicated part...'
On Wed, 27 Jan 2010 02:49:15 +0100, wrote: Author: ianh Date: 2010-01-26 17:49:13 -0800 (Tue, 26 Jan 2010) New Revision: 4627 Modified: complete.html index source Log: [e] (0) some editorial improvements to 'the indicated part...' Modified: source === --- source 2010-01-24 11:34:30 UTC (rev 4626) +++ source 2010-01-27 01:49:13 UTC (rev 4627) @@ -64669,7 +64669,8 @@ defined by the specification that defines the MIME type used by the Document (for example, the processing of fragment identifiers for XML MIME - types is the responsibility of RFC3023). + types is the responsibility of RFC3023). [RFC3023] For HTML documents (and HTML MIME types), the following processing model must be followed to @@ -64684,8 +64685,9 @@ URL. - If fragid is the empty string, then the - indicated part of the document is the top of the document. + If fragid is the empty string, then + the indicated part of the document is the top of the + document. Let decoded fragid be the result of expanding any sequences of percent-encoded octets in the indicated part of the document; stop the algorithm here. Here it should say somehting like "if fragid is "top" ascii case insensitively then the indicated part of the document is the top of the document". - Otherwise, there is no indicated part of the - document. + Otherwise, there is no indicated part of the document. ___ Commit-Watchers mailing list commit-watch...@lists.whatwg.org http://lists.whatwg.org/listinfo.cgi/commit-watchers-whatwg.org -- Simon Pieters Opera Software
Re: [whatwg] about:blank synchronicity
On Wed, 13 Jan 2010, Henri Sivonen wrote:
>
> This has turned out to be a test suite compatibility problem with
> about:blank. Mozilla's Mochitest test suite has tests that depend
> about:blank in iframe having a document.body immediately upon iframe
> insertion to document without a trip through the event loop.
>
> At first look, this seems like a clear case: the spec says that
> about:blank is navigated to synchronously. However, this is not what
> Gecko does (with the old parser).
The parser isn't even invoked in this case in the spec actually. Just
creating an and inserting in the document synchronously creates a
Document object with the right elements, without parsing anything.
> Gecko (with the old parser) has these two characteristics:
> 1) If a browsing context that has no document object is asked to return
> its document object, an about:blank-like DOM is generated into the
> browsing context synchronously.
This is compatible with what the spec requires.
> 2) When a browsing context is navigated to about:blank, a task is
> posted to the task queue. When that task is run, about:blank is parsed
> to completion during the single task queue task.
I've changed the spec to make actual navigation to about:blank async.
On Wed, 13 Jan 2010, Maciej Stachowiak wrote:
>
> I am not sure what the exact constraints are, but I believe the
> following are required:
>
> - Accessing the document of a frame with missing, empty or about:blank
> src has to always give you an HTML document with a body, even if there
> hasn't been a chance for the event loop to run.
> - A newly created iframe with missing, empty or about:blank src has to have an
> accessible document right away, without even cycling the event loop.
I believe this is guaranteed in the spec, at least for newly created
browsing contexts.
> There are at least three particular scenarios that are relevant here:
>
> 1) Some sites document.write or otherwise poke at the DOM of their
> about:blank frames or iframes in inline script, without waiting for the
> load event or anything.
>
> 2) Some sites load multiple frames, yet one expects to poke at the
> other's DOM during its load. Since load order is not guaranteed, this
> would be a race condition, if the not-yet-loaded frame had no DOM, but
> synchronous about:blank lets such sites muddle on through. Before we had
> sufficiently synchronous loading of the initial empty frame document, we
> actually encountered sites like this that broke in Safari but not IE or
> Firefox.
>
> 3) Some sites make a new iframe element using DOM calls in an event
> handler, and expect it to have an empty document that's immediately
> ready for DOM manipulation, without any intervening returns to the event
> loop.
Those should all work, since they all can access the initially created
document (the one that doesn't involve a parser).
On Wed, 13 Jan 2010, Boris Zbarsky wrote:
> On 1/13/10 11:52 AM, Maciej Stachowiak wrote:
> > Question: if you generate a document on the fly via early access, does
> > it get replaced when the about:blank task actually completes?
>
> Yes. More precisely, the document is replaced, but the inner window is
> not (the latter required for pages that set variables on the window
> before the load is complete).
This is in fact required by the spec, too:
http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#create-a-document-object
> I believe Gecko treats a document.write the same way it treats a
> location set in terms of network traffic: any loads that are happening
> in that navigation context are canceled. This is not specific to
> pending about:blank loads. For example, if you insert an iframe with
> some http URI as @src into the DOM and then document.write into it
> immediately, then the http load will be canceled. Nothing special about
> about:blank here.
This is currently step 8 of the document.open() algorithm.
>
>
>
>
> function doTheTest() {
> alert(window.frames[0].document.documentElement.textContent);
> }
>
>
>
>
>
> var doc = window.frames[0].document;
> doc.documentElement.appendChild(doc.createTextNode("foopy"));
>
>
>
>
> This alerts empty string in Gecko (and doesn't show the string "foopy"
> in the iframe).
The "" URL resolves to the same as "./", which in IE (though no other
browsers) means loading up an actual page. Currently the spec agrees with
IE on this, though there is an open issue about whether to change this
that I haven't looked at yet.
If we have src="about:blank", though, the spec says that the gets
a Document object with its created synchronously, and the
navigation is never done; the DOM manipulation is thus persistent (and the
test alerts "foopy")
On Thu, 14 Jan 2010, Henri Sivonen wrote:
>
> Which leads to the question: Are there known Web compat constraints on
> navigating a non-framed browsing
