Re: [whatwg] events when navigating away before page load?
Thanks Ian, Ian Hickson wrote on 14 december 2012 19:22: On Fri, 14 Dec 2012, Mike Wilson wrote: What events are supposed to be fired when the browsing context gets navigated away before the current page has finished loading, ie before the load event has been fired? It's pretty complicated, but the short answer is beforeunload and unload. DOMContentLoaded and load don't fire per spec, though this is controversial (it's been suggested that the abort that happens during navigation should be equivalent to the abort that happens when the user hits Stop; whether it is or not changes whether or not we pretend that the page finished parsing or not). I added the beforeunload event in an updated fiddle: http://jsfiddle.net/khwtB/ which resulted in: FF17 Chr23 IE9 spec - - - - domload y y n n load n n n n beforeunload y n y y unload y y n y So yes, it seems there is a lack of agreement here :-) Anyway, the finding that originally got me started on looking at this was that I received an unload event without a preceeding load event. Naively this seems logically wrong, but I appreciate these are complicated matters so I'm content with the answer that this probably shouldn't be expected in these kinds of cases. Best regards Mike
Re: [whatwg] events when navigating away before page load?
Ian Hickson wrote on 14 december 2012 21:11: As a general rule, the intent of the spec is that you get a load when all your scripts (and other resources) have loaded, and you get an unload when the page is going away. Thus if the page goes away before the page has finished loading, you just get an unload. Yes, when I think about this a bit more it makes a lot of sense. Initially I did expect a behaviour more like abort/stop - skipping all outstanding i/o and fast- forwarding to the firing of the load event(s). But as you say, as we are leaving the page anyway, there shouldn't be a big need to do page load initializations. And a smart page can actually detect it's being rushed through by looking for unload without load. Note to self and to other page authors: make sure unload handlers don't break if related code in load handlers weren't executed. We additionally also suggest firing a load and so forth when the user aborts the page, on the assumption that you probably have all the scripts you need and are only missing minor things like ads or analytics Makes sense too - the user probably stopped the page when it seemed complete enough to him, so he should get event handlers and all other UI stuff set up that's normally in load handlers. I did a few more tests and found even more differences. Chrome has different behaviour depending on if the navigation is initiated while parsing head or body, and for the latter it fires the same events as Firefox although in a different order: FF17 Chr23 Chr23 IE9spec nav head nav head nav body nav head nav head or body or bodyor body -- -- -- -- -- beforeunld domloaddomloadbeforeunld beforeunld domloadunload beforeunldunload unloadunload Interesting stuff indeed :-) Best regards Mike
Re: [whatwg] script element onerror event
Hi John, This event is actually already speced, see #14 fire a simple event named error at the element in: http://www.whatwg.org/specs/web-apps/current-work/#prepare-a-script (and the onerror attribute is valid for all elements) Best regards Mike Wilson John J. Barton wrote: To allow optional JavaScript download, some widely used JavaScript libraries, such as jQuery and requireJS, use script elements added to the document dynamically by JavaScript. (Of course this feature is also used by applications directly as well). For normal deployment this approach works well in practice. At development time however, or in the presence of network or server problems, the approach gives poor error recovery information. Fundamentally the problem is that the insertion mechanism has no error return path. The script element does support one event, 'onload' which fires after the script has finished loading. I suggest the addition of one new event, 'onerror', which fires in every other case. For examples, a network error (4XX, 5XX) or JavaScript parse error would trigger onerror but not onload. On the other hand, a runtime error for the outer-function of the script element would trigger onload (I guess), but the developer can handle this with try/catch. Very long load times would still have poor error recovery information, but developers could implement UI to signal loading... once they know they will get some update event eventually. jjb
Re: [whatwg] script element onerror event
John J. Barton wrote: Step 14 is unclear or incomplete however: If the src http://www.whatwg.org/specs/web-apps/current-work/#attr-script-src attribute's value is the empty string or if it could not be resolved,... Does this mean the error handler will be called in the case of 4XX, 5XX, and syntax errors? If you follow the algorithm a bit further down you have this in step 15.2: If the load resulted in an error (for example a DNS error, or an HTTP 404 error) Executing the script block must just consist of firing a simple event named error at the element. Best regards Mike
Re: [whatwg] script element onerror event
Mike Wilson wrote: John J. Barton wrote: Step 14 is unclear or incomplete however: If the src http://www.whatwg.org/specs/web-apps/current-work/#attr-script-src attribute's value is the empty string or if it could not be resolved,... Does this mean the error handler will be called in the case of 4XX, 5XX, and syntax errors? If you follow the algorithm a bit further down you have this in step 15.2: If the load resulted in an error (for example a DNS error, or an HTTP 404 error) Executing the script block must just consist of firing a simple event named error at the element. Oops, this section isn't step 15.2, it's below it. Here's the link: http://www.whatwg.org/specs/web-apps/current-work/#execute-the-script-block Best regards Mike
Re: [whatwg] navigation shouldn't abort if canceled
Boris Zbarsky wrote: On 2/2/11 3:22 PM, Michael Nordman wrote: That does sound like a bug? I'd be curious to know what the reasoning was for the existing sequence of steps. From what I can tell, current browser behavior. As I wrote in my initial post, my observation was actually that this is contrary to current browser behaviour. But I may be misinterpreting the consequences of the algorithm as stated. Here's my test scenario in pseudo code: 1) load a page that has a beforeunload handler 2) the page has an img/link css/external script that is slow to load 3) navigate away from the page before the resource in (2) has completed loading 4) answer stay on page on the beforeunload prompt According to http://www.whatwg.org/specs/web-apps/current-work/#navigating-across-documen ts I would expect the resource in (2) to stop loading at (3), as a result of aborting the document in the navigation algorithm's step 9. But this is not what I am seeing in Firefox 3.6 or even IE6 (I tested a number of other browsers too but don't have the exact versions handy). The external resources all complete loading, with load events and all. Did I miss something? Best regards Mike Wilson
Re: [whatwg] navigation shouldn't abort if canceled
Boris Zbarsky wrote: As I wrote in my initial post, my observation was actually that this is contrary to current browser behaviour. Ah, I see. So in Gecko, at least, beforeunload fires before the document is aborted. Right, that matches my findings in other browsers as well. So can we then say that http://www.whatwg.org/specs/web-apps/current-work/#navigating-across-documen ts probably needs updating? Is the fix as simple as moving step 9 to the position between current step 11 and 12? (directly after beforeunload) Best regards Mike
Re: [whatwg] navigation shouldn't abort if canceled
No comments so far on this issue so I'll describe it a bit more. Consequences of the current text are that resource fetches are canceled for a document when navigating away from it, even if the user then chooses to cancel the navigation at a beforeunload prompt and returns to the document. Best regards Mike Wilson Mike Wilson wrote on December 26, 2010: http://www.whatwg.org/specs/web-apps/current-work/#navigating- across-documents (as of December 26, 2010) | When a browsing context is navigated to a new resource, the | user agent must run the following steps: ... | 9. Abort the active document of the browsing context. ... | 11. Prompt to unload the Document object. If the user refused | to allow the document to be unloaded, then these steps | must be aborted. Might this be a bug? (It seems more consistent with other parts of the html5 spec, and with browsers, to do the abort after the user has allowed the document to unload.) Best regards Mike Wilson
Re: [whatwg] WebWorkers and images
Boris Zbarsky wrote: It would be interesting to have an API that allows passing an imagedata object (not a copy) to a worker. Such an API would have to make the data disappear on the caller's side. That could be implemented reasonably efficiently using shared memory (either directly with threads or using shared memory segments with processes). FWIW, there's some interesting discussion on handing over data in message passing in this Google TechTalk: http://www.youtube.com/watch?v=37NaHRE0Sqw although this is about a Java framework. (some data structure pictures at 27:57 and forward) Best regards Mike Wilson
Re: [whatwg] link onLoad event
Diogo Resende wrote: I see already information on the latest draft about a load and error event, I think this is it. I was hoping some browser vendors would implement it sooner :) Yes, ironically link.onload works in IE6, but not in current stable versions of Firefox, Safari or Chrome :-P Best regards Mike Wilson
[whatwg] navigation shouldn't abort if canceled
http://www.whatwg.org/specs/web-apps/current-work/#navigating-across-documen ts (as of December 26, 2010) | When a browsing context is navigated to a new resource, the | user agent must run the following steps: ... | 9. Abort the active document of the browsing context. ... | 11. Prompt to unload the Document object. If the user refused | to allow the document to be unloaded, then these steps | must be aborted. Might this be a bug? (It seems more consistent with other parts of the html5 spec, and with browsers, to do the abort after the user has allowed the document to unload.) Best regards Mike Wilson
Re: [whatwg] History API, pushState(), and related feedback
It seems the big questions here are whether to regard pushState
as a storage API, and whether to invent new API patterns instead
of reusing existing ones.
Is pushState about storage?
---
Ian Hickson wrote:
Mike Wilson wrote:
the semantic contract is coming closer and closer to that
of the other storage APIs, so I think it would be an
advantage to use the same interface as well.
I don't see the relevance of storage APIs here. This isn't a
storage model. It's more a callback model.
I disagree. Once an API persists state between page loads it
deserves to be regarded as a storage API and not just a callback
API.
The data objects supplied in pushState calls may be persisted for
the lifetime of their browsing context (unless history entry is
removed), just like data in session storage.
Invent new API pattern instead of reusing?
--
There should be good reasons why not to reuse existing API
patterns.
Why is pushState inventing a new API pattern where a copy of
the state is forwarded through new methods and events, instead
of accessing it through a storage facade (see sessionStorage and
localStorage) as in WebStorage?
Why is pushState defining a more restrictive model to state
access (read once / write anytime) compared to WebStorage
(read anytime / write anytime) ?
What use-cases are solvable in the current pushState model
but not in a WebStorage-style model? (see below for
WebStorage-style example)
Ian Hickson wrote:
Mike Wilson wrote:
Why not use the same API as in Web Storage:
interface Storage {
readonly attribute unsigned long length;
getter DOMString key(in unsigned long index);
getter any getItem(in DOMString key);
setter creator void setItem(in DOMString key, in any data);
deleter void removeItem(in DOMString key);
void clear();
};
and make the current entry's Storage instance always available
as f ex:
interface History {
readonly attribute Storage state;
}
Then pushState's state parameter may be removed and there is
no longer a need for the replaceState method.
I don't understand how this would work. When does the history
get updated in this model?
The pushState method (without state parameter and possibly
renamed) remains to create a new session history entry:
function() {
history.state.setItem(a, 1); // set on current history entry
history.pushState(title, url); // create new history entry
history.state.getItem(a); // get from new history entry (null)
history.state.setItem(a, 2); // set on new history entry
}
How do you know you've gone back in history?
The popstate event (without state attribute) remains to inform
us that history entry has been switched and that the corresponding
data is now available through history.state.
Best regards
Mike Wilson
Re: [whatwg] Window id - a proposal to leverage session usage in webapplication
[cross-posting as a similar amount of discussion has taken place on the two groups] Sebastian Hennebrueder wrote: The browser should generate an id unique per browser window and sent it as request header with every browser request. Request Header -- X-Window-Id: 279078917624897 Right, I have also used this technique successfully since several years and it is quite a nice solution for managing multiple windows. Though, currently this is only usable for Ajax apps (XHR.setRequestHeader) due to the missing pieces you point out. Using the Window id Having a window id, we can save the list of opened menus/ widgets per window in the user session. We split up the user session in slices. In pseudocode it looks like this: id = request['x-window-id'] context = session[id] menus = context['menus'] For other readers on the group it may be good to clarify that this is the server side session you are talking about. The whole point of adding this feature is to support server- centric applications better. It is quite interesting that HTML 5 solves the problem for the client side of JavaScript applications. The sessionStorage allows fine grained controll if data is seen by all windows or just by the current. The problem only persists for client - server applications. Exactly. Recent additions in this area of HTML5 mainly enhance the programming experience for applications that use script. I made an overview of this last year [1], suggesting to enhance the state handling model for server-centric apps. Below is a table with a related subset of the state management features mentioned, and your suggestion would fill the gap at *: NON-URL-BASED STATE MANAGEMENT (FOR GET PAGES W/A) Scope Script-centric Server-centric - -- -- user agent WS localStorage http-only cookies cookies cookies browsing context WS sessionStorage - * window.name document - - history entry push/replaceState N/A within document (#hash urls etc) The response from Ian Hickson was in short to direct these kinds of things to the HTTP WG, and that he expected applications to use Ajax-like interaction models instead. It has since struck me that HTML5 is quite client-focused, so I haven't invested time in bringing up any more server- centric discussions. I do think there is a need though, to cater for the classical server-side applications' state management. But I am not sure what WG wants to do this. Best regards Mike Wilson [1] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-June/020423.html
Re: [whatwg] History API, pushState(), and related feedback
Ian Hickson wrote:
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.
I think the storage APIs (localStorage and sessionStorage) are
the better comparison of these as they are also state handling
mechanisms. These do allow selected parts of the state to
be accessed individually as they are key/value stores. Thus
they allow different parties to have uncoordinated access to
their own data.
Fwiw, with some good will you can say that cookies are also
handled as key/value stores as their values are scoped on both
domain and key (cookie name). This allows different parts of
the code to deal with their own values as long as there isn't
a key (cookie name) collision.
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.
The main point is: Why not use the same API as in Web Storage:
interface Storage {
readonly attribute unsigned long length;
getter DOMString key(in unsigned long index);
getter any getItem(in DOMString key);
setter creator void setItem(in DOMString key, in any data);
deleter void removeItem(in DOMString key);
void clear();
};
and make the current entry's Storage instance always available
as f ex:
interface History {
readonly attribute Storage state;
}
Then pushState's state parameter may be removed and there is
no longer a need for the replaceState method.
Apart from API harmonization this also fixes the differences
in semantic contract. With this I mean that when Justin Lebar
and I started this discussion last summer the pushState API
was still very restrictive and only allowed retrieval of data
during the popstate event and only allowed storage of data
when pushState:ing a new history entry.
Making an analogy with sessionStorage would mean that it would
only be allowed to read data from sessionStorage during the
load event and only be allowed to write data at the same time
as assigning window.location.
Since then we have seen some changes to the spec and now the
state object may be written to at any time, and may also be
written to without creating a new history entry. Reading from
it at any time is still missing, for what reason I don't know?
Nevertheless, the semantic contract is coming closer and
closer to that of the other storage APIs, so I think it
would be an advantage to use the same interface as well.
[...] 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.
Indeed a fair bit of cases should reflect their state in
the URL, but, referring to my earlier examples, state like
scroll position and form control values usually should not.
I'm talking about this latter kind of data.
back/forward is a UI state navigation, not a data state
navigation.
We are in agreement that back/forward is not a generic undo/
redo mechanism. Still, UI state may have a broad definition.
Hitting back would take the user into a previous state in
the application, it wouldn't affect the user's work.
Yes and no. According to the current spec
http://dev.w3.org/html5/spec/Overview.html#history-traversal
user agents are free to persist scroll position and form
control values on history traversal. Naively I'd consider
scroll position to be UI state and form control values to be
user data state, and both seem to be eligible for persisting
on history entries.
So, I think there may be cases where it is desired to
(temporarily) store the contents of a rich-text form field
on a history state, or maybe store complex UI state such as
the open/close status of a large number of tree nodes, both
of which would be overkill to replaceState
Re: [whatwg] History API, pushState(), and related feedback
Ian Hickson wrote: On Wed, 19 Aug 2009, Mike Wilson wrote: Currently, the design with an immutable state object and the PopEvent and HashChange events triggering at somewhat insufficient timings, makes it hard to build the things I'm thinking about. IMO you need: - an event each time you're *leaving* a history entry (in addition to HashChange triggered when entering one) - allow updating existing state entries - shift the whole state entry model so that state entries belong to history entries, and are not logically inserted between them (this is actually a very important distinction) I'm hoping Ian will come back with the use cases he has in mind, as I am as of yet not clear on what he wants, or does not want, to support with the pushState model. Does replaceState() make it possible to do the things you're thinking about? If not, could you elaborate on what is not possible, or is awkward, in the current design? Yes, replaceState solves bullets two and three above. On Sat, 22 Aug 2009, Mike Wilson wrote: Great, this seems to be exactly what I want too. In particular I note the following differences from the current spec: - events both when entering and leaving a history entry (I called them hashload and hashunload but I agree it is better to avoid hash as we also have state-only history entries) - the same processing for fresh (newly navigated to) history entries as for historical (navigated back/forward to) history entries - removal of the popstate event and exposing a read/writable state object during the whole history entry session About stateactivated naming: Activated/deactivated is a bit longish. Could - stateload/stateunload - stateenter/stateleave or others be good alternatives? Is state the desired keyword? Or should history or others be considered? Or something playing on the pageshow/pagehide naming? About pageStorage lifetime: Adding on to your description, assuming we are navigating from one page (/a) to another (/b) in history without bfcache, the following would be a suitable chain of events: - /a statedeactivated event - /a unload event - /a browser saves form fields, scrollpos, and history state obj - browser swaps out /a and loads /b - /b browser restores history state obj before any script runs - /b scripts are executed and form fields and scrollpos are restored while document content is built - /b load event - /b stateactivated event About pageStorage naming: I think page makes you think more of Document than of history entries. Looking at an overview of storage areas, ordered from large scopes down to fine-grained scopes may spawn some ideas: CURRENTLY DISCUSSED: Scope Storage area / identifier - - user agent window.localStorage browsing contextwindow.sessionStorage document- history entry window.pageStorage If anticipating there could be a future storage area per Document, naming could be something like this: ALTERNATIVE: Scope Storage area / identifier - - user agent window.localStorage browsing contextwindow.sessionStorage documentdocument.documentStorage history entry window.history.entryStorage I'm a little concerned about overgeneralisation and overabstraction to the point of making APIs that on paper seem logical but in practice don't really work. I'm not really clear on what the above is proposing to solve, though. Could you describe the problem with the current API that the above solves, ideally with reference to use cases? I'll keep this short as there is more recent discussion: 1) The additional event is discussed later in this mail. 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 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. On Wed, 2 Dec 2009, Mike Wilson wrote: 6.11.9, step 3.1.2: The browsing context's browsing context name must be unset. It might be good with a note that the browsing context name is only switched by the user agent for history traversal to another origin, and not for navigation to a new origin. Navigation involves a history traversal step. Right, missed that. Good, it seems correct that browser context name is cleared
Re: [whatwg] history state object api issues
Justin Lebar wrote: - allow for self-contained components to handle own state [not supported by spec, *2] I'm generally in favor of a minimalistic approach to this kind of thing. Ideally, we'd be able to compose independent components using the API, but I'm not convinced that it's worth the complexity that would add. If pages really needed this kind of composition, someone could write a thin library around the existing push/replaceState API. It seems we agree that this is an issue with the current API that forces all components to cooperate, or be coordinated, through a central point. The rub with those thin wrapper libraries is that all components need to be using the same library and thus also requiring cooperation, albeit in a different way. Examples that could be using this feature are drop-in components that implement things like trees and rich-text editors that automatically cooperate with session history to restore their values or layout, without manual coding to collect all data inside an app-specific data structure. Of course, these components can continue to use DOM tricks that hook into the browser's form field storage, but I thought one of the point with the state object feature was not having to do that. - have a notification event when entering a history entry [almost full support in spec (popstate), *3] I guess this might be useful if you have independent components hooking into the API. Again, I'm not sure that this is worth the complexity it would add. (Should a pushState trigger a popState? That would be a little weird. And certainly we wouldn't want to add a new event just to tell you that you called pushState.) I agree this is the most questionable part of my observations, as programmatic activation of a feature doesn't normally trigger the associated event. Though, here it would simplify code as a logical page can get its state in the same way independent of it was navigated (pushState) or traversed (history) to. Also, it seems like the other programmatic way to switch state objects, History.go/back/forward, does trigger the popstate event, but maybe that should go away instead? - have a notification event when leaving current history entry [not supported by spec, *4] Is the use case here to allow pages to save their state right before the browser navigates away? This doesn't seem essential -- the page could just call replaceState whenever the state changes -- but I suppose it might be useful. Certainly the page code can update the state on every change of user-editable state, setting up a swarm of event handlers not to miss anything important. My point is that this is not always practical, imagine f ex serializing a large tree or rich-text editor on every update event. (Btw, did you have any insight on issue #1?) A merry Christmas to all you web-standard-oholics out there! :-) Best regards Mike On Wed, Dec 23, 2009 at 10:52 AM, Mike Wilson mike...@hotmail.com wrote: There are still some issues with the pushState feature of session history, as I wrote in August [1]. As there was a lack of discussion at that time I am raising these issues again. Below is a list of naive requirements on the state- handling parts of the new client-side session history mechanism, mapped against the current support in the 21 December 2009 version of editor's draft. It should be possible to: - specify associated state when programatically creating a new session history entry [supported by spec (pushState)] - update state for the current session history entry [supported by spec (replaceState)] - get state for current session history entry [partial support by spec (popstate), *1] - allow for self-contained components to handle own state [not supported by spec, *2] - have a notification event when entering a history entry [almost full support in spec (popstate), *3] - have a notification event when leaving current history entry [not supported by spec, *4] Notes: *1: only available in popstate event, not during rest of history entry lifetime (getter needed) *2: all page parts saving state must coordinate with a shared data structure (key/value-store or similar needed) *3: popstate event not fired for navigation with pushState (fire for navigation too needed) *4: there is no event that fires before upcoming history entry is activated (new event needed) If there is interest, I can put together a pseudo code example to illustrate these needs, to aid the discussion of solutions. Best regards Mike Wilson [1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-Augus t/022211.html
[whatwg] history state object api issues
There are still some issues with the pushState feature of session history, as I wrote in August [1]. As there was a lack of discussion at that time I am raising these issues again. Below is a list of naive requirements on the state- handling parts of the new client-side session history mechanism, mapped against the current support in the 21 December 2009 version of editor's draft. It should be possible to: - specify associated state when programatically creating a new session history entry [supported by spec (pushState)] - update state for the current session history entry [supported by spec (replaceState)] - get state for current session history entry [partial support by spec (popstate), *1] - allow for self-contained components to handle own state [not supported by spec, *2] - have a notification event when entering a history entry [almost full support in spec (popstate), *3] - have a notification event when leaving current history entry [not supported by spec, *4] Notes: *1: only available in popstate event, not during rest of history entry lifetime (getter needed) *2: all page parts saving state must coordinate with a shared data structure (key/value-store or similar needed) *3: popstate event not fired for navigation with pushState (fire for navigation too needed) *4: there is no event that fires before upcoming history entry is activated (new event needed) If there is interest, I can put together a pseudo code example to illustrate these needs, to aid the discussion of solutions. Best regards Mike Wilson [1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022211.html
[whatwg] two minor things in history traversal
6.11.9, step 3.1: To me, this text: If the browsing context is a top-level browsing context (and not an auxiliary browsing context) seems to imply that an auxiliary b-c is not a top-level b-c. This is subjective of course, but it might be a good thing to rephrase the sentence into something like: If the browsing context is a top-level browsing context which is not an auxiliary browsing context or: If the browsing context is a top-level browsing context (but not an auxiliary browsing context) Or, I guess it would also be possible to invent a new term for independent top-level browsing contexts or something in the same spirit. 6.11.9, step 3.1.2: The browsing context's browsing context name must be unset. It might be good with a note that the browsing context name is only switched by the user agent for history traversal to another origin, and not for navigation to a new origin. Best regards Mike Wilson
Re: [whatwg] AJAX History Concerns
Ian Hickson wrote: The idea is that the string you would put into the back button or history menu is not the same as the string you would put into the title bar or bookmarks (i.e. not the same as title). It might be good to spell out the fact that sessionHistoryEntry.title has nothing to do with document.title a bit more explicitly in the text, as this seems to be easily misinterpreted (maybe because of the use of the title identifer?). Maybe adding a note to 6.10.1, and/or expanding the note about title in 6.10.2 would be good? Best regards Mike Wilson
Re: [whatwg] HTML5 at Last Call (at the WHATWG)
Ian Hickson wrote: If you sent an e-mail or filed a bug that I haven't replied to, then please send it again. In case I didn't miss it, it seems you haven't followed up on the thread titled Proposed changes to the History API: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-August/022138.html (22 messages) Best regards Mike Wilson
Re: [whatwg] first script and impersonating other pages - pushState(url)
Justin Lebar wrote: Mike Wilson wrote: The result is that the address bar URL can't be trusted, as any page on the site can impersonate any other without consent from that page or part of the site? Someone will correct me if I'm wrong, but I think this is already pretty much the case with today's same-origin policy, albeit with a bit more work. My understanding is that if A and B have the same origin, they can do whatever they want to each others' documents, including modifying content. So if you can control script at http://google.com/~mwilson , and a user has both your site and http://google.com/securesite , then your malicious page can do whatever it wants to the secure page. That's why it's important that you trust all the javascript which runs on your origin. Ian Hickson wrote: The Web has a same-origin security model. If you're sharing one origin between two untrusted authors, you've already lost. For example, today you could already do what you describe -- just use window.open() to open the topclientsonly/login page, and then inject script to grab the password. Yes of course, should have thought about that :-P. As you say, it is trivial to add a frame that displays the victim page and then patch it to my needs. Well, if there will ever be a path-based security mechanism (as suggested in my other thread) I guess it could apply to pushState as well. Thanks Mike
Re: [whatwg] RFC: Alternatives to storage mutex for cookies andlocalStorage
Interesting. I've been following this discussion as my experience is that it is *extremely* hard to make an invisible locking mechanism that is to provide both consistency and performance (no lockouts). So far it seems a silver bullet hasn't been found. Your suggestion is in line with what I would expect from a solution that makes a best effort compromise between the multi-tab browsing experience and the burden put on application authors. What if cookies are accessed between beginTransaction() and commitTransaction(), would it make sense to throw for updates with side-effects here as well? (Even though this would not be the case if done outside the transaction.) In some cases it may be helpful to get this side-effect notification for cookies as well... Best regards Mike Wilson Chris Jones wrote: I'd like to propose that HTML5 specify different schemes than a conceptual global storage mutex to provide consistency guarantees for localStorage and cookies. Cookies would be protected according to Benjamin Smedberg's post in the [whatwg] Storage mutex and cookies can lead to browser deadlock thread. Roughly, this proposal would give scripts a consistent view of document.cookie until they completed. AIUI this is stronger consistency than Google Chrome provides today, and anecdotal evidence suggests even their weaker consistency hasn't broken the web. localStorage would be changed in a non-backwards-compatible way. I believe that web apps can be partitioned into two classes: those that have planned for running concurrently (single-event-loop or not) in multiple browsing contexts, and those that haven't. I further posit that the second class would break when run concurrently in multiple contexts regardless of multiple event loops, and thus regardless of the storage mutex. Even in the single-event-loop world, sites not prepared to be loaded in multiple tabs can stomp each other's data even though script execution is atomic. (I wouldn't dare use my bank's website in two tabs at the same time in a single-event-loop browser.) In other words, storage mutex can't help the second class of sites. (I also believe that there's a very large, third class of pages that work accidentally when run concurrently in multiple contexts, even though they don't plan for that. This is likely because they don't keep quasi-persistent data on the client side.) Based on that, I believe localStorage should be designed with the first class of web apps (those that have considered data consistency across multiple concurrent contexts) in mind, rather than the second class. Is a conceptual global storage mutex the best way for, say, gmail to guarantee consistency of its e-mail/contacts database? I don't believe so: I think that a transactional localStorage is preferable. Transactional localStorage is easier for browser vendors to implement and should result in better performance for web apps in multi-process UAs. It's more of a burden on web app authors than the hidden storage mutex, but I think the benefits outweigh the cost. I propose adding the functions window.localStorage.beginTransaction() window.localStorage.commitTransaction() or window.beginTransaction() window.commitTransaction() (The latter might be preferable if we later decide to add more resources with transactional semantics.) localStorage.getItem(),. setItem(), .removeItem(), and .clear() would remain specified as they are today. beginTransaction() would do just that, open a transaction. Calling localStorage.*() outside of an open transaction would cause a script exception to be thrown; this would unfortunately break all current clients of localStorage. There might be cleverer ways to mitigate this breakage by a UA pretending not to support localStorage until a script called beginTransaction(). yieldForStorageUpdates() would no longer be meaningful and should be removed. A transaction would successfully commit, atomically applying its modifications to localStorage, if localStorage was not modified between beginTransaction() and commitTransaction(). Note that a transaction consisting entirely of getItem() could fail just as those actually modifying localStorage. If a transaction failed, the UA would throw a TransactionFailed exception to script. The UA would be allowed to throw this exception at any time between beginTransaction() and commitTransaction(). There are numerous ways to implement transactional semantics. Single-event-loop UAs could implement beginTransaction() and commitTransaction() as no-ops. Multi-event-loop UAs could reuse the global storage mutex if they had already implemented that (beginTransaction() == lock, commitTransaction() == unlock). Some edge cases: * calling commitTransaction() without beginTransaction() would throw an exception
Re: [whatwg] origin+path namespacing and security
Ian Hickson wrote: On Fri, 28 Aug 2009, Mike Wilson wrote: My chain of thoughts is something like below (this is just a general picture so don't take it too literally): - invent a more restrictive mechanism for script access between documents from the same origin (host) so it can be limited based on a base path - this mechanism needs a way to specify the blessed path, maybe something along the lines of document.domain or a response header - the default blessed path should probably be as permissive as today to not break existing content on the Web (though maybe some smart algorithm may be developed that adds some restrictions) - if new browsers implement this mechanism, it means it will be possible to secure all new HTML5 features implemented at the same time or later, as authors can depend on that, if a browser has feature X, then it also has path-based security - old browsers will still ignore the new path-based restrictions, but they will not have the new HTML5 features so these can not be exploited - cookies will still be exploitable in old browsers and for legacy content, but as old browsers are phased out application authors can more and more depend on cookies also being safe based on configured path security It's definitely too late to take on anything this radical in the HTML5 time frame. I would recommend building experiments on these lines, publishing papers and getting peer review, and so on, to see what could be done on the long term. Ok, that sort of defeats the point as it will not be possible to depend on this security function for HTML5 features released before its appearance in the standard - my idea was that f ex WebStorage would refer to (and require) the new enhanced security model. I'd say it is extremely difficult to add a stricter security model on to a released standard (with deployed browsers) in a way so authors can depend on it. On the other hand, there hasn't been an overwhelmingly positive response (understatement ;-) on this suggestion, so unfortunately I guess it might better be dropped. Best regards Mike
Re: [whatwg] first script and impersonating other pages - pushState(url)
Ian Hickson wrote:
On Mon, 31 Aug 2009, Mike Wilson wrote:
Ian Hickson wrote:
On Fri, 21 Aug 2009, Mike Wilson wrote:
[...]
Imagine that I want my loaded page:
/pages/section1/thing1
be able to impersonate:
/pages/section2/thing2
how do you envision this to be structured?
Something like this? :
/pages/section1/thing1:
script src=/pages/script.js
button onclick=impersonate();
/pages/script.js:
function impersonate() {
...pushState(..., /pages/section2/thing2);
}
That would do it, yes.
[...] wouldn't the first script
(corresponding to the button click) be the implicitly
generated event handler in:
/pages/section1/thing1
with a basedir of
/pages/section1
thereby making the call to:
...pushState(..., /pages/section2/thing2);
throw SECURITY_ERR in step 2.2 of the pushState
algorithm?
No, why?
Because I was interpreting the following from the spec
and your previous mail:
- clicking the button will trigger the anonymous
event handler in /pages/section1/thing1 and will
result in activating a first script with
basedir=/pages/section1
- when the anonymous event handler calls into the
impersonate() function defined in /pages/script.js
the initial script (and basedir) remains as first
script and does not activate basedir=/pages
- calling pushState(..., /pages/section1/thing2) when
first script's basedir=/pages/section1 will be ok
- calling pushState(..., /pages/section2/thing2) when
first script's basedir=/pages/section1 will not be
allowed (and throw).
Is any of these wrong?
Best regards
Mike
Re: [whatwg] origin+path namespacing and security
Adam Barth wrote: On Thu, Sep 3, 2009 at 2:44 AM, Mike Wilson wrote: Ok, that sort of defeats the point as it will not be possible to depend on this security function for HTML5 features released before its appearance in the standard - my idea was that f ex WebStorage would refer to (and require) the new enhanced security model. WebStorage has already shipped in several implementations that do not implement this enhanced security model. I'm aware of that, but invention in standards can't stop as soon as one vendor publishes their first release based on an unfinished draft. But yes, you'll have to decide how to deal with browsers based on drafts when you depend on something only available in the finished version, and you expect beta-versions to have impact. This is an expected part of the early implementation to give feedback to standardization process and there are different ways to address it. Best regards Mike
Re: [whatwg] first script and impersonating other pages - pushState(url)
Ian Hickson wrote: On Thu, 3 Sep 2009, Mike Wilson wrote: - calling pushState(..., /pages/section1/thing2) when first script's basedir=/pages/section1 will be ok - calling pushState(..., /pages/section2/thing2) when first script's basedir=/pages/section1 will not be allowed (and throw). Is any of these wrong? The path part of the URL is ignored when deciding whether or not to allow the call. Rereading the spec again I see that. Sorry, my bad :-S I see now that the first script's url is only used to keep pushState on the same origin, while I was expecting it to keep pushState urls on the same sub branch path. But doesn't this open up a fairly bad security exploit? Let's say that I have rights to post to a blog on: www.corporatesite.com/fan/blog Assuming I can get some JavaScript inside one of my blog posts, I can then pretend I am redirecting the user to: www.corporatesite.com/topclientsonly/login while I am really impersonating that page through pushState and harvesting their passwords. The result is that the address bar URL can't be trusted, as any page on the site can impersonate any other without consent from that page or part of the site? Best regards Mike
Re: [whatwg] HTML extension for system idle detection.
David Bennett wrote: On Mon, Aug 31, 2009 at 5:30 PM, Drew Wilson atwil...@google.com wrote: This would be my inclination as well. I'm not entirely convinced that every web app should define their own idle timeout is such desirable behavior that we should build our API around it by forcing every caller to specify their idle timeout - having a standard event that's fired with an exposed state for apps that need it seems like a cleaner approach. The trouble with this is it doesn't allow any experimentation on the part of the app/entity to figure out what is the best idle time for it's purposes. In terms of chat it might be that a 3 minute or 5 minute idle time works best in terms of people's attention. For something like watching a video perhaps a 15 minute idle would be a better length of time, or for an online game a longer idle time is probably useful before being signed out. Different purposes have different requirements for the idle time so it makes sense to allow them to specify the different timeouts. This requirement could be solved in several other ways, f ex making sure that the standard timeout period is short enough to not be longer than what any app wants. Then (as was previously suggested) an app that wants a longer timeout can do setTimeout and trigger its own idle stuff if status has not come back to active during that time. Another alternative is to have no event, and just a property: window.lastUserActionTime which is kept updated with the msec since epoch for the latest user input on the desktop. Then an app can implement its own idle functionality with totally own rules. This API has the drawback of maybe exposing too much information (the rate of input events to other apps), but may spawn some ideas. Best regards Mike
Re: [whatwg] first script and impersonating other pages - pushState(url)
Ian Hickson wrote:
On Fri, 21 Aug 2009, Mike Wilson wrote:
I'm currently wrapping my head around the notion of
first script in the spec [1]. It's description is
a bit terse and the subject seems non-trivial, so
maybe the text could be fleshed out some?
Section 6.1.5 Groupings of browsing contexts
says:
| Each unit of related similar-origin browsing
| contexts can have a first script which is used to
| obtain, amongst other things, the script's base
| URL to resolve relative URLs used in scripts
| running in that unit of related similar-origin
| browsing contexts. Initially, there is no first
| script.
Does this implicitly say that this set of browsing
contexts should never execute script in parallel?
No, that is implied by the event loop mechanism.
http://www.whatwg.org/specs/web-apps/current-work/#event-loops
Ah thanks, that made it clear. 6.1.5 might get a little
easier to understand if some text mentioned the shared
event loop for this set of browsing contexts, or linked
to 6.5.4.
/pages/page1.html:
script src=/scripts/script1.js
*1 button onclick=func1();
/scripts/script1.js:
function func1() { ... }
*2 func1();
What is regarded as *first script* in these two
calls to func1() ?
*1: the implicitly generated event handler wrapper
in /pages/page1.html ?
*2: /scripts/script1.js
Yes.
[...]
Imagine that I want my loaded page:
/pages/section1/thing1
be able to impersonate:
/pages/section2/thing2
how do you envision this to be structured?
Something like this? :
/pages/section1/thing1:
script src=/pages/script.js
button onclick=impersonate();
/pages/script.js:
function impersonate() {
...pushState(..., /pages/section2/thing2);
}
That would do it, yes.
Per *1 in the first example, wouldn't the first script
(corresponding to the button click) be the implicitly
generated event handler in:
/pages/section1/thing1
with a basedir of
/pages/section1
thereby making the call to:
...pushState(..., /pages/section2/thing2);
throw SECURITY_ERR in step 2.2 of the pushState
algorithm?
Best regards
Mike
Re: [whatwg] Global Script proposal.
Ian Hickson wrote: Given that all frames in a browsing context have to be on the same thread, regardless of domain, then unless we put all the browsing contexts on the same thread, we can't guarantee that all frames from the same domain across all browsing contexts will be on the same thread. Right, the GlobalScript proposal would cause an additional vector that enlarges the sets of related similar-origin browsing contexts, ie making more browsing contexts share event loop. But there are already a number of relationships that cause this, so can we really say that having one more is not possible? As an application developer I wouldn't have any problem with knowing up-front that my application would share thread with the other instances (pages) of my application if I use the GlobalScipt feature. (And has been mentioned, it wouldn't be a forced requirement.) @Dmitry: as an implementor, do you find problems with having a loaded page change event loop and thread, or is that just about swapping around data structures? What I'm thinking about is that if swapping is possible, then every page can start on its own thread, and then only swap over to the shared thread for that unit of related similar-origin browsing contexts if referencing a GlobalScript. (If swapping is not possible, then every page would have to try to join the thread for its origin at load time, to be prepared for GlobalScript sharing, and that would probably pull together more browsing contexts than desired into shared threds...) [...] Granted, programmers today don't want to use threads -- but, well, tough. All indications are that that's what the programming model of the next few decades is going to be; now is the time to move that way. We shouldn't be adding features that actually move us back to the single-threaded world. FWIW, I don't see the GlobalScript proposal as something that wants to avoid multi-threading. Though, with JavaScript's shared nothing approach between threads, single-threading is a side-effect of having live access (no intermediate serializing/cloning) to shared data. If there was multi-threaded access to data (you could say there already is with cookies and the storage mutex) I'm sure the GlobalScript proposal could be tailored to take advantage of that. Best regards Mike
Re: [whatwg] Storage mutex feedback
Jonas Sicking wrote: On Sat, Aug 29, 2009 at 10:06 PM, Ian Hicksoni...@hixie.ch wrote: Upon further consideration I've renamed getStorageUpdates() to yieldForStorageUpdates(). I really liked Darin's (?) suggestion of allowStorageUpdates as that seems to exactly describe the intended use of the function. We no longer prevent other page from updating the storage. Quite nice. One little nit is that it could be interpreted as allowing oneself's updates, while it is really about allowing other's updates. allowOtherStorageUpdates? (not so nice, but... ;-) Is there a preference for having the name indicate that we are finishing our own transaction, ie myStorageUpdatesAreNowComplete endStorageUpdates finishStorageUpdates commitStorageUpdates flushStorageUpdates saveStorageUpdates or should it indicate that others are now welcome to do their stuff, such as in: otherPagesStorageUpdatesAreNowWelcome allow(Other)StorageUpdates enable(Other)StorageUpdates ? Best regards Mike
Re: [whatwg] origin+path namespacing and security
Adam Barth wrote: Mike Wilsonmike...@hotmail.com wrote: I see what you mean. The ideal thing would be if we could implement path-based security with the same construct that adds path-based namespacing. I realize the problem of backwards-compat, but have there been any efforts or definitive conclusions made in this area? I suspect the scheme+host+port model is too entrenched at this point to add +path to the origin tuple. Just to be clear, I wasn't suggesting that we'd redefine origin to contain path, but rather saying there are cases where we could benefit from namespacing on origin (=scheme/host/port) + path. The namespacing bit is probably not so hard, but making it secure also is non-trivial, due to the by-default unrestricted access between documents from the same origin that Anne mentions: Anne van Kesteren wrote: Note also that someone on /evilpath/ can simply inject an iframe loading /targetpath/ and extract cookies from there via ECMAScript or initiate requests from there, etc. Paths cannot be trusted to provide security. Yes, I guess this is what Ian had in mind in his initial response, and it means cookies are already lost for this cause. But maybe we can still save new HTML5 features from this exploit. My chain of thoughts is something like below (this is just a general picture so don't take it too literally): - invent a more restrictive mechanism for script access between documents from the same origin (host) so it can be limited based on a base path - this mechanism needs a way to specify the blessed path, maybe something along the lines of document.domain or a response header - the default blessed path should probably be as permissive as today to not break existing content on the Web (though maybe some smart algorithm may be developed that adds some restrictions) - if new browsers implement this mechanism, it means it will be possible to secure all new HTML5 features implemented at the same time or later, as authors can depend on that, if a browser has feature X, then it also has path-based security - old browsers will still ignore the new path-based restrictions, but they will not have the new HTML5 features so these can not be exploited - cookies will still be exploitable in old browsers and for legacy content, but as old browsers are phased out application authors can more and more depend on cookies also being safe based on configured path security But maybe there has been previous efforts done on this topic? Best regards Mike
Re: [whatwg] origin+path namespacing and security
Adam Barth wrote: Mike Wilsonmike...@hotmail.com wrote: - this mechanism needs a way to specify the blessed path, maybe something along the lines of document.domain or a response header 1) Document.domain is an abomination. We certainly don't want more features like that. 2) There's a race condition in such a default insecure approach: the excluded paths can just XSS the page before it opts in to tighter security. I also wrote: My chain of thoughts is something like below (this is just a general picture so don't take it too literally): so please feel welcome to provide alternatives instead of just killing the provided analogies. But more interesting is, are you saying that it is not possible, under any circumstance, to design a secure opt-in mechanism in this case? My belief was that security information delivered before the actual document contents (like a response header) could activate the desired security level before creation of the related JS context. Best regards Mike
Re: [whatwg] Proposal for local-storage file management
Maciej Stachowiak wrote: Broader note: loading and then modifying existing documents in the browser might be cool. But in general, I don't see the win of making the file manager the tool to manage data created by web apps. File managers are not really that great an interface for managing information, and much of the time, something specific to the type of content is a better interface. That's what I think too, and my guess for the future is that applications will be focusing on the actual information, letting users project it in different useful ways, and not force them to map it to physical folders or files. So I say first priority is to design a first-class browser storage, to make it possible to build really good apps in the browser. Done right, this browser storage may eventually become users' first choice and ordinary files may become uninteresting. (There could very well be device-specific ways to exchange files between browser storage and the device's own storage representation.) Best regards Mike Wilson
Re: [whatwg] Proposal for local-storage file management
Right, trying to answer on-topic ;-) I guess if the spec doesn't mention anything about where localStorage is persisted, it leaves it up to every browser to decide whether to ask the user or use a default location. Earlier I didn't think of the possibility of localStorage data being stored in different locations for different apps, but that might be a good idea. I can see both good and bad sides of this; it's good with more control for expert users that want to put data in very specific locations. On the other hand I would also want to build apps that don't force users to make decisions about files and folders at all, they should just work. Maybe the storage decision could be high level, offering simplified alternatives like - browser's default storage location - user account's documents location - that SD card you just inserted There still is the problem that Michael Nordman mentioned; there is no way to identify specific applications's data so f ex all apps under www.google.com would be routed into the same file. Will I be able to make collective decisions about data for collections of apps like that? Maybe. Or it will be worked around by even more vanity host names. (importantdocs.google.com, privatedocs.google.com, ... ;-) Best regards Mike Jens Alfke wrote: There's some feature-creep going on in this thread. I think a filesystem API is a good feature for the future, but the immediate issue is with the pending local-storage API: how to balance applications' legitimate needs for permanent local storage with users' legitimate needs to manage disk usage and backups. I don't think that's an issue we can put off until HTML6 or whenever. Yes, my suggestion does involve the filesystem, but not in a way that's visible to the web-app. The app simply sees a persistent key- value store as currently spec'ed; it has no idea where in the filesystem the user has chosen to put it. Whereas the user just decides on a parent folder (and maybe a quota), without having access to the individual records inside. The purpose is just for the user to have some control of whether to give the app storage at all, and if so where to put it, and the ability to manage that storage via the regular file manager UI. (Or for platforms that don't have such a UI, like the iPhone, some kind of flat list of web-apps.) -Jens
Re: [whatwg] Web Storage: apparent contradiction in spec
Speaking up as an application developer ;-) here, I think the evict data at browser's choice route is fatal for new inventions in app development. I've been hoping that WebStorage and Offline together with other new APIs could provide a platform that allows us to build applications free from dependencies to specific platforms/OSs (a no-brainer for the web) and also freeing us from the tyranny of the 50-year old file concept (information doesn't necessarily want to be contained in files, and most of the time users don't want to do the additional task of administering file names and folder structures on a local disk). These new apps might not have a server at all, maybe using peer-to-peer technologies to exchange parts of its data with the outside world. If, like many say here, a user file is considered more precious than data in localStorage, and the latter may have an automatic eviction scheme, then these new apps cannot use WebStorage. Instead I would look forward to new File APIs, allowing me to store data in local files. And then we are back to having our users handling and managing files and folders on their local disk... To back up a bit, offline data can be used to improve applications in different ways, and here's a quick list of scenarios I come to think of: * the browser makes an automatic decision to cache certain server data * the application decides to cache certain server data without asking the user * the application caches certain server data in response to user command (I need to have all my mail for offline access while I'm on the plane) * the application allows creation of new data and modification of existing cached server data while offline * the application allows creation and modification of data without relying on that there is a server or a copy of the data on that server If localStorage data is not considered precious I can only see the first two types of caching possible in professional applications. Even the third point would not be acceptable if the user has specifically asked to have a certain subset of his data available while travelling the Amazonas, just to discover that it was evicted because the browser decided to. As someone said, I think it is important that the spec clarifies which of these scenarios WebStorage is aiming to fulfill. Best regards Mike Wilson Drew Wilson wrote: This is one of those times when I *really* wish that the application developer community was more active on this list. I absolutely understand Linus' point of view, but I also feel like we are really hamstringing applications when we make choices like this and I wish that those developers were more vocally represented in these types of discussions. Going down this path would basically kill the ability to have offline web applications, because there would be no guarantees that the data would persist until the user comes back online. But since that point's already been made several times, I guess it's not a compelling argument. -atw On Wed, Aug 26, 2009 at 8:23 PM, Linus Upson li...@google.com wrote: I simply want clicking on links to be safe. In a previous thread I wrote safe and stateless but I'm coming to the opinion that stateless is a corollary of safe. Clicking on links shouldn't, either by filling my disk or hitting my global quota, someday lead to a dialog which reads, Please choose what to delete so that web sites will continue to work. The candidate delete list will be thousands long and hidden in that haystack will be a few precious needles. I also want to avoid any [Yes] [No] dialogs. Can I do something scary [Yes] [No]? Can I do something innocuous [Yes] [No]? Users shouldn't be forced to make those kinds of safety judgements. I'm guilty of instigating at least one of those dialogs. As shamed politicians do I'll retreat to the passive voice: Mistakes were made. I'm not opposed to web apps manipulating files on the user's computer, but the user should be in explicit control. I'd support input type=open and input type=save that worked similarly to input type=file. User agents are already registering for file types so that double clicking a file with a certain extension can be automatically sent to an URL, perhaps residing in an AppCache. In addition, I'd like to see the pop-up dialogs for the location API removed. I find the Can I know where you are? dialogs on the iPhone very annoying. Mistakes were made. Perhaps we can find a way to make input type=location work well instead. Linus On Wed, Aug 26, 2009 at 5:14 PM, Brady Eidson beid...@apple.com wrote: I started writing a detailed rebuttal to Linus's reply, but by the time I was finished, many others had already delivered more targetted replies. So I'll cut the rebuttal format and make a few specific points. - Many apps act as a shoebox for managing specific types of data, and users are used to using these apps
Re: [whatwg] HTML5 History Management
Ian Hickson wrote: On Sun, 16 Aug 2009, Mike Wilson wrote: Ian Hickson wrote: I don't think we should encourage cases where the same URL can correspond to multiple states, which this would encourage. This statement confuses me as the whole point of pushState seems to be to store unique state in addition to the URL. If the URL can be used to infer the state anyway, then what's the point of storing it in the history entry? It's mostly about being able to track extra state that isn't important to the user. For example, if you have an application with many boxes, and two states, one with one box open, and another with another box open, and the boxes are randomly dotted around but move when a box is opened or closed, and you then hit back-forward-back-forward, you would want the same two boxes to move in the same way each time. However, if you just jump straight to the URI representing those two states, the exact position of the boxes doesn't matter, and might differ each time. The state object is for keeping track of that kind of thing (the position of the boxes). It seems we do indeed agree that the state object is for storing state that could differ for multiple history entries for the same URL, and what you are actually saying is that you think this feature should not be used for important state. I'm fine as long the former is true, and you are free to have an opinion about the latter. Though, when taking a more thorough look at what is spec:ed, it seems these use cases are indeed not supported, due to state update limitations and how events are ordered. I've tried to fix this by making popstate more synchronous. I still don't think this fixes my issues. I've described most of these in the thread Proposed changes to the History API so I'll wait until you reply to that before commenting further here. Best regards Mike
Re: [whatwg] Proposed changes to the History API
Justin Lebar wrote: Mike Wilson wrote: It would be interesting to see a concrete example on how you intend the dynamics of your solution to work. It would be great if you could outline the different events and method calls used (in order) to save and restore the history state object in the following situations: - doing a fresh navigation from page#1 to page#2 - going back in history from page#2 to page#1 Here's one way it could go: User was at http://google.com, types http://mozilla.com/index.html#1 into address bar. * onload * stateactivated User clicks on link with href #2 * statedeactivated (until this event is complete, document.location.hash == #1 and the pageStorage object is for the #1 state) * stateactivated (at the beginning of this event, document.location.hash == #2 and the pageStorage object is for the #2 state) User clicks back * statedeactivated (for #2) * stateactivated (for #1) Great, this seems to be exactly what I want too. In particular I note the following differences from the current spec: - events both when entering and leaving a history entry (I called them hashload and hashunload but I agree it is better to avoid hash as we also have state-only history entries) - the same processing for fresh (newly navigated to) history entries as for historical (navigated back/forward to) history entries - removal of the popstate event and exposing a read/writable state object during the whole history entry session About stateactivated naming: Activated/deactivated is a bit longish. Could - stateload/stateunload - stateenter/stateleave or others be good alternatives? Is state the desired keyword? Or should history or others be considered? Or something playing on the pageshow/pagehide naming? About pageStorage lifetime: Adding on to your description, assuming we are navigating from one page (/a) to another (/b) in history without bfcache, the following would be a suitable chain of events: - /a statedeactivated event - /a unload event - /a browser saves form fields, scrollpos, and history state obj - browser swaps out /a and loads /b - /b browser restores history state obj before any script runs - /b scripts are executed and form fields and scrollpos are restored while document content is built - /b load event - /b stateactivated event About pageStorage naming: I think page makes you think more of Document than of history entries. Looking at an overview of storage areas, ordered from large scopes down to fine-grained scopes may spawn some ideas: CURRENTLY DISCUSSED: Scope Storage area / identifier - - user agent window.localStorage browsing contextwindow.sessionStorage document- history entry window.pageStorage If anticipating there could be a future storage area per Document, naming could be something like this: ALTERNATIVE: Scope Storage area / identifier - - user agent window.localStorage browsing contextwindow.sessionStorage documentdocument.documentStorage history entry window.history.entryStorage Best regards Mike
Re: [whatwg] Proposed changes to the History API
Justin Lebar wrote: The pushState function as currently specified allows you to do precisely this. History.pushState(obj, title, url) creates a new history entry with the given URL, but doesn't load a new document. Ah thanks, I had missed the part saying that path and query were ok to change. I think this part of the spec is very controversial though, but I'll spawn that discussion to another thread. It would further be nice if your comments weren't lost even if you navigate away from the page. This is the way it works in most browsers, as the browser persists form field values when you navigate back and forth in history. Right. But the difficulty with this page in particular is that it's structured such that it's difficult/impossible for the browser to properly restore its form state after a crash. Onload, the page creates a textarea and populates it with the text of the patch. So if we crash then restore, the page won't have created the textarea by the time the browser looks to restore the text. Sorry, it seems we are not talking about the same application. Jonas referred to attachment pages in your bug database, which I assumed would f ex be a page like this one: https://bugzilla.mozilla.org/attachment.cgi?id=386244action=edit (The textarea in this app is not created onload, it is delivered in the server-generated HTML and thus is subject to form field value persistence.) What app are you talking about? what we really want is a way to programmatically do the restore. Certainly, that's why we are all here I guess :-) Being able to do similar things as form field value persistence and scroll position persistence, but for your own data, is the purpose of history states, IMO. Best regards Mike
Re: [whatwg] Proposed changes to the History API
Justin Lebar wrote: On Wed, Aug 19, 2009 at 5:31 PM, Jeremy Orlow wrote: but here it seems like everything can just stay in memory...right? My thought was that if you had a tab open and restarted the browser, that the state objects would be there after the restart, so we'd have to serialize to disk. I also thought that we'd persist this state data even after we take a Document out of memory. This part begs a couple more questions :-) What you're essentially saying here is that when restarting the browser, you will also restore history data, correct? For tabs that were open when the browser was closed, this will mean that these will reappear after restart with full history, being able to go Back and restore state on previous pages? But for pages that were explicitly closed, and then navigated to in a new tab, will you restore the full history in these as well? And is that really desired from a user pov? (It seems you will be haunted by the same page history forever, even if the corresponding server state expired a long time ago.) And if there has been several sessions in parallel on that URL space, which one do you respawn for a navigation to a related page in a new tab? Best regards Mike
Re: [whatwg] Proposed changes to the History API
Justin Lebar wrote: Maybe the right solution is to have a pageStorage object, which works just like sessionStorage but is local to a session history entry and perhaps carries some weak promise of persistence. Yes, I was also thinking that being able to store key/value pairs, instead of a single state object, would be good. It would be nice to see the same kind of API be reused throughout the different state/storage mechanisms. Best regards Mike
[whatwg] first script and impersonating other pages - pushState(url)
I'm currently wrapping my head around the notion of
first script in the spec [1]. It's description is
a bit terse and the subject seems non-trivial, so
maybe the text could be fleshed out some?
Section 6.1.5 Groupings of browsing contexts says:
| Each unit of related similar-origin browsing
| contexts can have a first script which is used to
| obtain, amongst other things, the script's base
| URL to resolve relative URLs used in scripts
| running in that unit of related similar-origin
| browsing contexts. Initially, there is no first
| script.
Ok, so a *unit of related similar-origin browsing
contexts* has one shared first script.
Does this implicitly say that this set of browsing
contexts should never execute script in parallel?
(= mutually exclusive code execution, so one
hang will hang them all)
Section 6.5.3.2 Calling scripts says:
| When a user agent is to jump to a code entry-point
| for a script, for example to invoke an event
| listener defined in that script, the user agent
| must run the following steps:
| [...]
| 2. Set the first script to be the script being
|invoked.
Example:
/pages/page1.html:
script src=/scripts/script1.js
*1 button onclick=func1();
/scripts/script1.js:
function func1() { ... }
*2 func1();
What is regarded as *first script* in these two
calls to func1() ?
*1: the implicitly generated event handler wrapper
in /pages/page1.html ?
*2: /scripts/script1.js
Section 6.10.2 The History interface says:
| [...]
| pushState(data, title, url)
| [...]
| 2.1 Resolve the value of the third argument,
| relative to the first script's base URL.
| [...]
| 5 If the third argument is present, set the
| document's current address to the absolute URL
| that was found earlier in this algorithm.
Ok, by calling pushState() with an URL I can make
the address bar show another URL than my document is
loaded from.
Imagine that I want my loaded page:
/pages/section1/thing1
be able to impersonate:
/pages/section2/thing2
how do you envision this to be structured?
Something like this? :
/pages/section1/thing1:
script src=/pages/script.js
button onclick=impersonate();
/pages/script.js:
function impersonate() {
...pushState(..., /pages/section2/thing2);
}
Best regards
Mike Wilson
[1] http://dev.w3.org/html5/spec/Overview.html
(btw, the latest WD link gives a 404:
http://www.w3.org/TR/2009/WD-html5-20090825/)
Re: [whatwg] Proposed changes to the History API
Justin Lebar wrote: Mike Wilson wrote: Sorry, it seems we are not talking about the same application. Jonas referred to attachment pages in your bug database, which I assumed would f ex be a page like this one: https://bugzilla.mozilla.org/attachment.cgi?id=386244action=edit (The textarea in this app is not created onload, it is delivered in the server-generated HTML and thus is subject to form field value persistence.) STR: * Open https://bugzilla.mozilla.org/attachment.cgi?id=386244action=edit * Click Edit as comment * Change the text in the textarea * Close and re-open your browser Actual behavior: The textarea is back to its original state, read-only and without your edits. Even after you press edit as comment, the state still doesn't reflect the changes you made before you closed the browser. Hm, it seems you didn't get my point. I was referring to your statement saying that it wasn't possible for the form field value persistence to do its job because the textarea was created and populated onload. I was pointing out that this is not the case, as the textarea and its content are indeed delivered in the static HTML right from the server and not created onload. Thus, this textarea is fully functional with the browser's form field value persistence mechanism, as can be seen if you revisit the textarea within the same browser session. I understand that persistence between browser restarts is one of your goals, but I have never said that the current incarnation of form field value persistence persists between browser restarts. Or are you saying that? Indeed, if Mozilla's implementation did that, I would expect it to work straight off with the discussed bugzilla page, due to its simple and form-friendly design. Best regards Mike
Re: [whatwg] Proposed changes to the History API
Ah good, something made me think you were trying to populate fresh history entries as well, which would have been awkward. We've been discussing general properties of the solution for a while now. It would be interesting to see a concrete example on how you intend the dynamics of your solution to work. It would be great if you could outline the different events and method calls used (in order) to save and restore the history state object in the following situations: - doing a fresh navigation from page#1 to page#2 - going back in history from page#2 to page#1 If we start with this simple example (simple hash nav and no URL impersonation) then maybe we can move on to more advanced stuff later on. I'm assuming page#1 and page#2 are perceived by the user as different parts of the application and that he wants state saved for each of them when navigating back and forth in history. Best regards Mike Justin Lebar wrote: Mike Wilson wrote: What you're essentially saying here is that when restarting the browser, you will also restore history data, correct? For tabs that were open when the browser was closed, this will mean that these will reappear after restart with full history, being able to go Back and restore state on previous pages? Right. We already do this, sans popping a state object. But for pages that were explicitly closed, and then navigated to in a new tab, will you restore the full history in these as well? No. The state object is attached to the session history entry, not to the page's URI. If you close a tab, all its session history entries go away. If you navigate to a page which was open in the tab you just closed, that new instance of the page won't be aware of the old page's state object(s). And if there has been several sessions in parallel on that URL space, which one do you respawn for a navigation to a related page in a new tab? A navigation on a new tab would get an entirely new environment. Otherwise, like you suggested, this would be very confusing.
Re: [whatwg] Proposed changes to the History API
Jonas Sicking wrote: 1. [...] it would be better if you could actually navigate between https://mail.google.com/mail/inbox https://mail.google.com/mail/label/personal https://mail.google.com/mail/label/whatwg https://mail.google.com/mail/label/whatwg/13b4711edac9c1e2 and then use the fragment identifier for what it was intended. I guess this is just a vision about what the developer really wants to do, or are you thinking of any solutions that would actually allow changing path (or query string) without loading a new Document? I guess half of the problem (keeping loaded script and state between page loads, but not the Document) is addressed by the GlobalScript/SharedScope discussion in a different thread. Also, keeping state between page loads is also the subject of some of my previous mailings to the list. 2. The ability to create several session history entries for the same page which the user can navigate between, and use some type of state object to disambiguate between these states. For example in our bug database we allow users to look at attachments, as well as comment on attachments. When starting to comment on an attachment the page changes from displaying the attachment, to displaying a textarea pre-populated with the contents of the attachment such that you can add comments to it. It would be nice if switching modes acted like navigation so that you could go back Yes, I think this is one of the purposes of the history state entries, in particular the URL-less ones (if you don't want your mode change reflected in the URL hash). It would further be nice if your comments weren't lost even if you navigate away from the page. This is the way it works in most browsers, as the browser persists form field values when you navigate back and forth in history. Try (in Firefox) to input some comments and navigate to a new page. When returning to the comment page in FF3.5, the edit mode is gone (because this was a scripted state) but if you go into edit again, you'll see your input text, as the textarea contents was persisted by the browser. From my incomplete tests it looks like several browsers persist form field values per document, but scroll position per history entry. Thus, you will not get different persisted comment text when navigating between two hash urls. Though, it would be possible to build that function yourself, if desired, using the history state mechanism for hash urls. When thinking about it this way it became pretty clear that pushState was not the right API for two reasons. First of all it combines the two aspects into a single function call. The same function is used to navigate the user to a different API, as is used to associate data with a history entry. Instead having createNewEntry which deals with the first use case, and setState which (partially) deals with the second makes more sense. Though there is actually two features in the second use case: 2a. Create new session history entries for the current page. 2b. Associate data with the current session history entry. setState only does 2b. However createNewEntry could cover 2a if we make both the uri and title arguments optional. I think this pretty much agrees with my view. I'd like to draw an analogy with how state currently is/can be persisted in normal page loading: click link to navigate from page1.html to page2.html: ... go back to page1.html in history: leaving page2: - trigger unload event so user code can save custom state - browser saves form field values for page2 document entering page1: - browser restores form field values for page1 document - trigger load event to allow user code to restore custom state Note that there currently is no standard mechanism for saving custom state per document above, and the form field value area is not accessible to to user code. Though, in the session history proposal there is a mechanism for saving custom state (the state object), so below I sketch on a model that uses this and also is symmetric with the page-load model above: click link to navigate from page1.html#a to page1.html#b: leaving #a: - trigger HashUnload event so user code can save custom state - state may be saved using History.setState(), f ex History.setState(hello); entering #b: - trigger HashLoad event so user code can restore custom state - state may be queried with History.getState() but this is null as this is a fresh history entry go back to page1.html#a in history: leaving #b: - trigger HashUnload event so user code can save custom state - state may be saved using History.setState() entering #a: - trigger HashLoad event so user code can restore custom state - state may be queried with History.getState() and hello will now be returned Note: 1) HashLoad event is similar to the current HashChange 2) HashUnload event is new, and is
Re: [whatwg] Global Script proposal.
Jeremy Orlow wrote: Btw, I thought I'd just point out that the proposal mentions this case: From the proposal text: All pages connected to the same Global Script should run on the same thread, in the same process. Since this is not always technically possible, it should be legal (and not break the applications) for there to be duplicate global script contexts within a UA. I'm glad this came up, however, since now it's more clear why such language is necessary. Ah, right I misread that part. I interpreted the second half of it (after technically possible) as other threading models were possible. Now, as I understand it, two pages sharing a GlobalScript MUST share a single thread, or otherwise MUST use a different/duplicate GlobalScript instance. On Tue, Aug 18, 2009 at 12:20 PM, Mike Wilson mike...@hotmail.com wrote: With this stated, I'd like to throw out a question on what do you want the most - max performance in 100% of cases, but redundant GlobalScript contexts, or max performance in most cases and singular GlobalScript contexts? I don't think any UA is realistically going to do this for v1. But sure, the door should be left open for in the future. (The initial proposal allows for both, btw.) That's exactly my point, the door should be open for these kind of improvements. But to allow both, I think the proposal text has to be adjusted somewhat, as interpretations (like mine) will otherwise risk assuming that different threads/processes MUST imply having different GlobalScript context instances. Best regards Mike
Re: [whatwg] Proposed changes to the History API
Justin Lebar wrote: [...] Notably unsupported by this API is support for pages altering their saved state. For instance, a page might want to save a text box's edit history to implement a fancy undo. [...] We'd probably want to fire PopState on all loads and history navigations, since any document might have a state to pop Right, this is exactly my thoughts on the API as well, as we started discussing recently, see: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022087.html | Though, when taking a more thorough look at what is | spec:ed, it seems these use cases are indeed not supported, | due to state update limitations and how events are ordered. Currently, the design with an immutable state object and the PopEvent and HashChange events triggering at somewhat insufficient timings, makes it hard to build the things I'm thinking about. IMO you need: - an event each time you're *leaving* a history entry (in addition to HashChange triggered when entering one) - allow updating existing state entries - shift the whole state entry model so that state entries belong to history entries, and are not logically inserted between them (this is actually a very important distinction) I'm hoping Ian will come back with the use cases he has in mind, as I am as of yet not clear on what he wants, or does not want, to support with the pushState model. Best regards Mike Wilson
Re: [whatwg] Global Script proposal.
Patrick Mueller wrote: Or perhaps these GlobalScripts - should really be called GlobalObjects or GlobalContexts maybe; SharedScope? I like Shared as this is the term used in SharedWorkers to identify something that can be shared between multiple pages. SharedContext? Best regards Mike
Re: [whatwg] Proposal to drag virtual file out of browser
Sounds interesting!
You only mention a singular file, what do you think about multiple files?
Also, would it be possible to hook browser-produced data into this model, so
client-generated data (f ex text, html, pdf) could be dragged out as a
virtual file to the desktop?
Best regards
Mike Wilson
_
From: whatwg-boun...@lists.whatwg.org
[mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Jian Li
Sent: den 18 augusti 2009 03:03
To: whatwg@lists.whatwg.org
Subject: [whatwg] Proposal to drag virtual file out of browser
SUMMARY
The HTML 5 spec defines the event-based drag-and-drop mechanism that could
cross the browser boundary. If a draggable element contains a URL, dragging
it out of the browser will only copy the URL value. However, in some
scenarios, we really want to download the data file from the specified URL,
instead of copying the value. Here we propose a way to allow dragging a
virtual file denoted by an URL out of the browser boundary.
USE CASES
In order to download the attachment from an Internet mail application, the
user will have to click the attachment link and a save dialog will pop up
to let the user select the destination folder. This will normally involves
multiple clicks. Native application, like Outlook, can let the user drag
attachments directly into the destination place, i.e. desktop, which is
really convenient.
WORKAROUNDS
Currently there is no direct support in HTML 5 to support such dragging of
the virtual file. To work around this, a plugin with such capability has to
be installed and used.
PROPOSAL
We propose adding a specific format string to the DataTransfer object:
DownloadURL. The data associated with the DownloadURL format should be
parsed similar to the URL format. When the drag ends in another
application, the remote file described in the associated data URL should be
downloaded and provided to the target application.
For example, here's how one can create a draggable image that results in a
file when dragged:
var dragTarget = document.createElement(img);
dragTarget.src = http://example.com/example-attachment.gif;;
document.body.insertBefore(dragTarget, document.body.firstChild);
dragTarget.addEventListener(dragstart, function(event) {
event.dataTransfer.setData(DownloadURL,
http://example.com/example-download-attachment;);
}, false);
Traditionally allowing the non-image file to be dragged out of the browser
is considered bad. The main danger here is that the user might unknowingly
drag a file that will auto-execute. To address this issue, the browser needs
to mark the dragged file to indicate that it is coming from the Internet.
With this zone marker, the user will be prompted with a security warning
dialog when the dropped file is launched. If a specific platform does not
support zone identifier marker, this feature should be turned off by
default.
We should consider allowing only http and https typed URL in the associated
data for the DownloadURL format. Should we further restrict the download
URL to the same origin?
If the filename is provided in the Content-Disposition header, it should
always be used. Otherwise, it is up to the browser to decide how the
filename is generated from the URL. But once it is chosen, it cannot be
changed.
The drag-and-drop feedback might be decorated with the filename and the
domain from which the file is downloaded. However, the real filename might
be only available when we initiate the download and get back the response
header. To address this, we can download the response header after the drag
is initiated and then update the feedback image based on the filename
retrieved from the Content-Disposition header. This might not be possible
for certain platform because changing the drag meta-data might not be
allowed.
Re: [whatwg] Global Script proposal.
This is an interesting suggestion as it isolates the stateful parts from the rest of the previous suggestions. I like state. Here's how I see how it fits inside the big picture: Scope Serialized state Live state - -- user agent WS_localStorage, GlobalScript [2] SharedWorker [1] cookie browsing context WS_sessionStorage- [3] window.name document -plain JS objs [4] history entry History.pushStateplain JS objs [4] [1] Global state can be coordinated by a SharedWorker but it would need to be serialized in postMessage on transfer so that's why I've put it in the serialized column. [2] As I understand it, the new GlobalScript construct is a context that can be shared by all browsing contexts in the user agent. [3] You also mention that the feature could be usable for page-to-page navigation within the same browsing context. It hasn't been suggested yet, but it would be possible to have a variation of GlobalScript that binds to a specific browsing context, analogous to sessionStorage. [4] These plain JavaScript objects indeed live throughout their Document's life, but this lifetime is usually shorter than what the user's perception tells him. Ie, when the user returns to a previous page through the Back button he regards that as the same document, while technically it's usually a new Document, with a freshly created document tree and JavaScript context. Questions - Threading: This is the unavoidable question ;-) How do you envision multiple threads accessing this shared context to be coordinated? Process boundaries: In this past discussion there have been several mentions about having to cluster pages inside the same process if they are to share data. Why is this so, and why can't shared memory or proxied objects be an option for browsers doing process separation? Best regards Mike Wilson From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Dmitry Titov Sent: den 17 augusti 2009 23:38 To: wha...@whatwg.org Subject: [whatwg] Global Script proposal. Dear whatwg, The previous discussion about shared page and persistence has sent us back 'to the drawing board', to think again what is the essence of the feature and what's not important. Talking with web apps developers indicates the most of benefits can be achieved without dangerous background persistence or the difficulty to specify visual aspects of the invisible page. Here is the new proposal. Your feedback is very appreciated. We are thinking about feasibility of doing experimental implementation in WebKit/Chrome. Thanks! - SUMMARY Currently there is no mechanism to directly share DOM, code and data on the same ui thread across several pages of the web application. Multi-page applications and the sites that navigate from page to page would benefit from having access to a shared global script context (naming?) with direct synchronous script access and ability to manipulate DOM. This would compliment Shared Workers (http://www.whatwg.org/specs/web-workers/current-work/) by providing a shared script-based context which does not run on a separate thread and can be used directly from the application's pages. USE CASES Chat application opens separate window for each conversation. Any opened window may be closed and user expectation is that remaining windows continue to work fine. Loading essentially whole chat application and maintaining data structures (roster) in each window takes a lot of resources and cpu. Finance site could open multiple windows to show information about particular stocks. At the same time, each page often includes data-bound UI components reflecting real-time market data, breaking news etc. It is very natural to have a shared context which can be directly accessed by UI on those pages, so only one set of info is maintained. A game may open multiple windows sharing the same model to provide different views at the game objects (as in flight simulator). In an email application, a user may want to open a separate compose window for a new email, often after she started to answer in place but realized she'd like to look up something else in the mailbox for the answer. This could be an instantaneous operation if the whole html tree and the compose editor script were shared. Such multiple-window use cases could be simpler and use much less resources if they had access to a shared Global Script Context so there is no need to re-initialize and maintain the same state in all the pages. Having direct, same-thread DOM/JS access to this context makes it possible to avoid loading and initialization of repetitive code and data, makes separate
Re: [whatwg] Global Script proposal.
Michael Nordman wrote: On Tue, Aug 18, 2009 at 6:07 AM, Mike Wilson mike...@hotmail.com wrote: Threading: This is the unavoidable question ;-) How do you envision multiple threads accessing this shared context to be coordinated? Nominally, they don't. In our design for chrome's multi-process architecture, the global-script would only be shared within a single 'renderer' process (in which all page's, and global-scripts, execute in a single thread). This might not be the same in other browsers. I think you need to define how concurrent access should be handled so it can be applied to f ex a browser using a single process but a thread per top-level window. If I understand correctly it would be something like letting only one thread call inside the GlobalScript context at a time? Process boundaries: In this past discussion there have been several mentions about having to cluster pages inside the same process if they are to share data. Why is this so, and why can't shared memory or proxied objects be an option for browsers doing process separation? A multi-process browser vendor probably *could* proxy all script calls to a truely global context across all 'renderers'... but that is not required in the proposal... and is probably even discouraged. One of the motivations for doing this is webapp performance. Proxying all script interactions across the page/context boundary works against that. Also synchronization issues get much more complicated. Implicit in the proposal is that a global-script is very inexpensive to interact with. Certainly, the ideal case is that they are in the same process. Using proxies is coming back to serialization all over again, although transparent. What I was commenting was the (seemingly widespread) notion that it is impossible to share data between process, which is not true. There is nothing stopping an implementation from using direct calls whenever process sharing is possible, and falling back to proxies in cases when processes need to be different. With this stated, I'd like to throw out a question on what do you want the most - max performance in 100% of cases, but redundant GlobalScript contexts, or max performance in most cases and singular GlobalScript contexts? Also, what about shared memory (I'm assuming everybody knows what this is) - apart from being non-trivial stuff, are there any specific drawbacks that renders it not useful for this case? Best regards Mike
Re: [whatwg] SharedWorkers and the name parameter
Drew Wilson wrote: Per section 4.8.3 of the SharedWorkers spec, if a page loads a shared worker with a url and name, it is illegal for any other page under the same origin to load a worker with the same name but a different URL -- the SharedWorker name becomes essentially a shared global namespace across all pages in a single origin. This causes problems when you have multiple pages under the same domain (ala geocities.com) - the pages all need to coordinate in their use of name. I agree with you that this is a problem, and the same problem exists in WebStorage (storage areas are set up per origin). F ex, the sites http://www.google.com/calendar and http://www.google.com/reader, and every other site based off www.google.com will compete for the same keys in one big shared storage area. It seems lately everything is being based on having unique host names, and path is not being considered anymore, which I think it should. An alternative model would be to follow what cookies do with cookie.path, to allow the application itself decide on what URL should be used as the namespace root. Allowed values would be in the range from the bare host name (~origin) up to the file URL (per your suggestion). (Then if even Document.domain could be enhanced with something to allow subsetting on path it'd be great. But that has probably been discussed to death a long time ago ;-) Best regards Mike Wilson
Re: [whatwg] HTML5 History Management
Ian Hickson wrote: On Wed, 5 Aug 2009, Nathan Hammond wrote: I should have stated this one with a goal: the ability to ensure that the popstate event always fires with a full understanding of the (app/page) state when navigating through history. This would be lost when a user manually changes the hash. With that as my goal, history.replace does not achieve what I am trying to accomplish. Neither does pushState without a URL as that still registers a new history point. All the information about the state really should be in the URL, such that the state of the app after the user manually changes the hash, and the state of the app after the user returns to a point in the history where he had manually changed the hash, really should be the same. This has never been true for server-side web applications so why should it be this way for client-side apps? My understanding of the purpose of pushState has been that it is there to aid client-side apps in behaving like server- side apps wrt history traversal. Not to make them more different and break user expectations. I don't think we should encourage cases where the same URL can correspond to multiple states, which this would encourage. This statement confuses me as the whole point of pushState seems to be to store unique state in addition to the URL. If the URL can be used to infer the state anyway, then what's the point of storing it in the history entry? But you may have a different purpose for these state objects. I'm expecting to store things like step-for-step state from wizard-like flows, or user interface state similar to (but in addition to) the browser's own handling of saving/restoring form field values and scroll position. Though, when taking a more thorough look at what is spec:ed, it seems these use cases are indeed not supported, due to state update limitations and how events are ordered. It would be very interesting to hear about the scenarios you have in mind, to be able to comment correctly. It would be great if you could flesh out (or point to) a concrete example of correct and intended usage of this history state object mechanism. [suggesting .hashvalue on hashchange event] I really don't follow. Imagine you're updating what's visible based on the hash, and the user changes the hash twice in a row quickly such that by the time you get the first event, the location's already changed again. Why wouldn't you be happy to ignore the first location? F ex, because your client-side app may update some state based on what (or how many times) individual fragments have been visited. Maybe something in the spirit of read count or so. Two other notes about the history state mechanism: 1) The popstate event is sort of a misnomer as it doesn't pop the state. Popping would imply removing it from its stack, but this is not the case as it remains in place in the history to be retrieved any number of times. A better name could be something like restorestate. 2) This text at the end of 6.10.1: | When state object entries are added, a URL can be | provided. This URL is used to replace the state object | entry if the Document is evicted. I'm not sure how to interpret this. Does it (implicitly) say that all state objects are evicted when the owning Document is evicted? And does the popstate event really supply the URL string in its .state member, instead of the real object, in these cases? One super-minor nit: In 6.10.3 we have: | (which happens during [[session history traversal]], as | described above) The link points to 6.11.9 which is below, not above. Best regards Mike Wilson
Re: [whatwg] Installed Apps
Ian Hickson wrote: On Tue, 4 Aug 2009, Drew Wilson wrote: Sure, although I'd say that persistent storage is addressed by the Web Storage and Web Database features. Shared state is also addressed, but that's not the primary goal. If I have a tree of objects that I'd like to share between two pages, telling me to serialize it into name/value string pairs, write it into Web Storage, and then have the remote side read it out is not a satisfying (or performant) solution. Web Storage supports structured data now. I'm assuming that you refer to the concept of structured clone now added to http://dev.w3.org/html5/webstorage/. This certainly makes life easier for certain scenarios, but I don't think it fully addresses Drew's use case. The problem is that to change the tiniest thing in the object graph, you will have to get a complete copy of the data out from the storage provider, apply the change, and then let it be copied (cloned) back into storage again. With Drew's large mailbox + categories example I think this will be too inefficient. Also, it cannot be divided into chunks stored under individual keys as that breaks object pointers. Maybe I'm mistaken, but I think Drew wanted handling of live objects, where each window gets access to the same concrete objects (possibly protected by private proxy objects) so the graph can be walked without cloning. Drew: are you thinking that the same object graph also makes up the data cache between sessions? If not, then persistence is not a must-have for this use case so the area of ideas could well expand outside webstorage. (Minor note: the Introduction still says that structured data needs to be handled manually: To store structured data in a storage area, you must first convert it to a string.) Best regards Mike Wilson
Re: [whatwg] HTML5 History Management
Nathan Hammond wrote: I should have stated this one with a goal: the ability to ensure that the popstate event always fires with a full understanding of the (app/page) state when navigating through history. This would be lost when a user manually changes the hash. [...] Any other techniques for remembering data other than this would still be a hack because, in and of itself, the data stored are not uniquely tied to a particular history state. [...] Using sessionStorage I have the additional task of mapping the stored series of states to a particular visit of the (app/page) if the user visits the site again after navigating away: example.com - whatwg.com - example.com Hi Nathan, I think I touched on the same need in my thread html5 state handling: overview and extensions, see http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-June/020423.html or http://www.nabble.com/html5-state-handling:-overview-and-extensions-td240347 73.html See the table on SCRIPT-CONTROLLED STATE at the end of that mail. As you can see I am suggesting to add a state construct for the missing Document state level. I'm just back from vacation but I'm doing some more research and hope to provide more information on that thread later this month. Best regards Mike Wilson
Re: [whatwg] Installed Apps
Michael Nordman wrote: On Mon, Aug 3, 2009 at 2:37 PM, Mike Wilson wrote: Btw, another reflection is that this mail thread is about introducing a client/server model in the browser. Some mentions of complex code in the background page, f ex building the HTML for the visible window, make me think of traditional server-centric webapps, but inside the browser. I've made the below table to illustrate this, and I mean to point out similarities between traditional server-centric and the new background_page-centric webapps, and between client-centric and visible-centric webapps. Maybe this can inspire some new thoughts. Yes... client/server model in the browser... good observation... and a good way to think about the direction I would like to see things go. Incidentally, that line of thinking is my motivation for the introduction of script-generated responses in this (HTML5) system design. Ah, I seem to have missed that. Makes total sense for offline as it probably makes it a lot easier to port server-centric apps to the cache, and well, there is already a concept of serving files (although only static). It's not a small thing to add, but if this is taken further I think coordination should be done with current inititatives using JS in server-side web platform designs, such as: ServerJS WSGI https://wiki.mozilla.org/ServerJS/WSGI (several products pointed to by comparison table) Joyent Smart http://becoming.smart.joyent.com/index.html + other stuff using EnvJS, etc... This would make it easier to move code between server and client, simplifying creation of distributed and offline apps. Remote Background Visible server page page -- -- --- Current webapp designs: server- state centric logic (bugzilla) gen HTML - render client- state - state centric logic (gmail) gen/render HTML New background page client-centric designs: background- state - state centric logic gen HTML - render visible- state - state - state centric (logic) logic gen/render HTML Best regards Mike
Re: [whatwg] Installed Apps
Drew Wilson wrote: SharedWorkers are overloaded to provide a way for pages under the same domain to share state, but this seems like an orthogonal goal to parallel execution and I suspect that we may have ended up with a cleaner solution had we decided to address the shared state issue via a separate mechanism. [...] 3) Sharing between pages requires going through the database or shared worker - you can't just party on a big shared datastructure. Assuming this shared state doesn't require a full JavaScript global context, and could do with some root object or collection, would it be possible to extend Web Storage to support this task? Best regards Mike Wilson
Re: [whatwg] Installed Apps
Michael Nordman wrote: On Mon, Aug 3, 2009 at 3:05 AM, Mike Wilsonmike...@hotmail.com wrote: Assuming this shared state doesn't require a full JavaScript global context, and could do with some root object or collection, would it be possible to extend Web Storage to support this task? A big part of what the Gmail team is interested in sharing is quite a lot of javascript (loaded, parsed, jit'd... ready to call functions). Along with that, the app can maintian shared state as well, but a big part of this feature request is sharing the code itself. In the absence of JS languange changes (analogous to DLLs or SOs for JS), I think this does call for a full JS context. Right, with your scenario, that makes use of all these new features in the same app, that could make sense. Still, it would be interesting to look at how each feature could be implemented on its own, to potentially lessen the overhead for apps that only use a single feature. These are the individual features discussed so far, I think (did I miss any?): - preload JavaScript code - share live data between multiple pages - background process with direct access to UI - background process that outlives browser process - background process that auto-starts with operating system - access to notification area I can easily imagine separate use of the first two items, and I think it would be great to address the data handling in a coherent way with other state handling. It would be nice to have finer-grained control over data handling than having to pop a new window to use its global context. Btw, another reflection is that this mail thread is about introducing a client/server model in the browser. Some mentions of complex code in the background page, f ex building the HTML for the visible window, make me think of traditional server-centric webapps, but inside the browser. I've made the below table to illustrate this, and I mean to point out similarities between traditional server-centric and the new background_page-centric webapps, and between client-centric and visible-centric webapps. Maybe this can inspire some new thoughts. Remote Background Visible server page page -- -- --- Current webapp designs: server- state centric logic (bugzilla) gen HTML - render client- state - state centric logic (gmail) gen/render HTML New background page client-centric designs: background- state -state centric logic gen HTML - render visible-state -state - state centric (logic) logic gen/render HTML mvh Mike
Re: [whatwg] html5 state handling: overview and extensions
Michael Nordman wrote: This breakdown is a useful way to think about application state in the browser. Thanks, it has been very useful to myself as a working model for making vague thoughts of something missing into something that is possible to measure and compare. Ideally, some similar kind of overview could be maintained in the HTML5 spec to keep both spec authors and readers sane. Another axis that could be incorporated into the model is lifetime. You really hit the nail on the head there. Actually, my initial attempt on a comparison table included a few additional columns: General: - state inherited by cloned browsing context - persistent storage supported - state protected/scoped by origin - state protected/scoped by origin+path - lifetime control Server-control: - state travels to browser in response headers - state travels to browser in response body but I decided to start out with a cut-down version, as otherwise definitely no-one would read my post (it was bad enough with the length of it even being cut down ;-). There is some overlap between Server- Controlled and Script-Controlled realms in cookies, applications definitely have a dependency on that overlap being there. Right, I missed including that in the post. Actually, in my initial table (mentioned above) I didn't split between client- and server-control, but had that as columns instead, so one feature (cookies) could cover both script- and server-needs. I should note that in this initial table of mine, normal cookies serve both purposes but http-only cookies only do server-controlled state. Here's an updated table with cookies added: SCRIPT-CONTROLLED STATE Scope Visibility : State construct - -- - user agent, invisible : cookies, WS localStorage browsing context, invisible : window.name, WS sessionStorage document, invisible : - history entry,invisible : history state history entry,url, : url hash There are two constructs not represented in your writeup, Database and ApplicationCache. Yes, they felt like somewhat different animals so I didn't include them, maybe that was wrong. All the other ones are some kind of simple data or name/value-paired data so I focused on them. My goal was also to make a matrix that would help us find the missing pieces, by identifying the empty cells. When adding too many different animals to the same matrix there will be many empty cells, and it gets harder to see patterns. Do you have ideas on how to incorporate Database and ApplicationCache in the comparisons? Possible solutions would be to add a new documentStorage to WebStorage, or to offer a History.setDocumentState method. I see other possibilities with WebStorage too. documentStorage has persistent lifetime + document scope others... transient lifetime + document scope (transient does not survive a browser restart) transient lifetime + user agent scopetemporaryStorage transient lifetime + history entry scope privateStorage Interesting ideas! My initial thought was that lifetime could be controlled in a way similar to cookies, ie no lifetime indicates transient lifetime, and for persistent lifetime you set an expiration date/time. Maybe the legacy of cookie expiration doesn't have to be the model here, but it would seem good if some of the suggested extensions are indeed implemented as something cookie-like. mvh Mike
Re: [whatwg] page refresh and resubmitting POST state
Ian Hickson wrote: On Fri, 22 May 2009, Mike Wilson wrote: I can see some usefulness for adding a couple of subjects to the HTML5 spec: - how browsers should handle page refresh, in particular for pages received through POST (= do you want to resubmit?) Done. Nice, thanks. - potentially add constructs to help users avoid the above resubmit question (this could f ex be through providing some support for PRG = Post-Redirect-Get, or other) On Fri, 22 May 2009, Jonas Sicking wrote: This is already supported. If you use a 302 or 303 redirect in response to a POST this will redirect to a uri that the UA then GETs. Refresing that page will simply result in a new GET to the second uri. snip On Sat, 23 May 2009, Mike Wilson wrote: I was thinking about the resubmit problem in a general context, specifically how browsers could make it possible for web authors to create POSTing pages that avoids giving the dreaded do you want to resubmit question at all, independent of operation. Just do a redirect like Jonas describes, instead of returning the page contents directly. You can even redirect to the same URL. As I pointed out in a followup to Jonas's mail: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-May/019937.html doing PRG with current technology has the drawback of losing the page state. This can be patched back again by adding query params to the URL but this isn't good for all scenarios (see below). [...] Defining some support in the browser could replace or simplify parts of these solutions. I'm sure people are open to suggestions. I wouldn't worry about whether they're in scope for HTML5 or not; if they're not, we can always redirect you to the right group. The information I've compiled goes outside the subject of this thread, so I'll explore further parts of the state handling problem in a separate mail thread titled html5 state handling: overview and extensions. On Sun, 24 May 2009, Aryeh Gregor wrote: One workaround is to just stick the info in the query string of the GET. One problem with this is that it makes it easy to trick users into thinking they've just done something alarming: you can link to confirmmove.php?page1=Main_Pagepage2=Main_Page_ON_WHEELS, and the user will think they actually just moved the page (the software told them so!). Another problem is that sometimes there's way too much data to fit into a query string. For instance, in MediaWiki you can move a page with all its subpages. There might be hundreds or even thousands of these, and a success/failure message is printed for each, with the reason for failure if appropriate. This might be too long to fit in a GET. Just stick the data into the query parameters, including the user's ID, then sign the query parameters, and when serving the page, check the signature and check the user's ID matches the cookie. Adding data to the URL makes sense in some scenarios, but not in others. Often the application needs to hold on to state shared by a sequence of pages in the same browsing context, but at the same time not wanting this state to be shared with the same set of pages in another browsing context. This rules out cookie-based state as this is shared by all browsing contexts in the user agent. With current technology a common solution is to add a unique id to the URL that points to a storage area on the server where the full state is stored. The same id is then used on all pages throughout the navigation sequence, and the id could be said to represent the browsing context (ie window or tab) as each browsing context will get a different id, mapping to state for that browsing context. For this scenario it would be better if the id parameter was not part of the URL, because: - the id parameter adds no meaning to the URL - the id parameter maps to an internal and transient data structure on the server and not to an entity - the above two bullets mean we don't want it in bookmarks - coming back with an old URL (with an old id) requires handling cases like recreating an expired data structure, or handling conflicts if our id is now allocated to another user A similar workaround would be to use cookies. This is nicer than the previous method, but has the potential to break confusingly if the user takes several similar actions at once (e.g., moving a number of pages at once in multiple tabs). Using sessionStorage can be used to work around this somewhat, at least in AJAX apps. For server-oriented webapps a solution that doesn't rely on script is preferred. This means the server should be able to transmit browsing_context-scoped state to the client and have it automatically sent back on any following request. Something like browsing_context-oriented cookies. I'll include this in my state handling overview in the new thread. Best regards Mike Wilson
[whatwg] html5 state handling: overview and extensions
hash urls http://host/page#state take care of url- visible state asociated with history entries. Document state There currently is no support for associating script state on the Document level. Any state saved in DOM or script global object will be lost on a page reload. Use cases would include single-page Ajax applications that want to store data independent of a certain history entry, but at the same time not sharing it with other page loads (Documents) of the same application in the history of the same browsing context (otherwise sessionStorage could be used). Possible solutions would be to add a new documentStorage to WebStorage, or to offer a History.setDocumentState method. I welcome any discussion about the missing pieces, and possible solutions, in these state construct listings. Best regards Mike Wilson
Re: [whatwg] page refresh and resubmitting POST state
Kristof Zelechovski wrote: I certainly want refresh to redo, for example, when validating a local document that I am editing. Chris What do you mean with editing a local document - is the document contents being edited inside an input field (f ex textarea) on a POSTing page? Mike
Re: [whatwg] page refresh and resubmitting POST state
Kristof Zelechovski wrote: If the local document is being edited in Notepad and bound to the validator via a file input control, refreshing the page should resubmit the file. Chris Ah, ok. I see no problem with the page author coupling the file input control to the redisplay state, or whatever construct could be used to hint to the browser that this data can be resubmitted without harm. You would then avoid getting the resubmission question on refresh. The hinting system could be useful whether we say that the Refresh button's semantics is Redisplay or Redo. Both would avoid popping the resubmission question when all fields are hinted harmless, but they would have different behaviour for when there is a mix of harmless and harmful fields. Of course, the same goal could be achieved with a completely different solution. This was just an example to get going. On a side note, your example makes me think of whether what to post at a page refresh is covered by any spec. The normal behaviour is that the browser posts the same data as sent in the original POST request, so if you have done any edits in the form between original POST and Refresh, they will be lost (this could even be subject for a discard edits? question ;-). Though as you mention, and I guess for practical reasons, the file contents of an uploaded file doesn't reflect the original request but instead the current file contents. Nothing wrong with that, but maybe this also deserves spec space. So, going back to my main point. All this is about de-facto, or potential future, browser behaviour and thus would be interesting in a spec about just that. The HTML5 effort is the closest match I've found for this subject. Best regards Mike Wilson
Re: [whatwg] page refresh and resubmitting POST state
Aryeh Gregor wrote: You should spell out the existing problem carefully and in great detail, including existing solutions or workarounds, to get the best response. I certainly intend to do this once I get feedback on whether this subject is relevant for HTML5, or any other whatwg spec (preferrably from people involved in authoring these). Time is limited and I would like to only spend this effort if applicable to spec work. Looking at the current spec I haven't found any section that directly relates to this subject, that's why I'm asking if it is in the spec's scope to add a section about it. An observation though, is that the Web Storage text (that was previously in the HTML5 spec) discusses a client-side session to alleviate the problem of using cookies together with multiple windows/tabs: http://www.w3.org/TR/webstorage/#introduction The multi window vs cookie scenario is something I consider part of the page state problem space, but other parts of this problem space don't map well to web storage... I don't think refresh is a big deal. I've been using refresh/resubmit as an easy example so that everybody knows what I am talking about. The subject of page state handling has far greater implications than refresh, just like you show in your examples below. I've tried outlining it later in this post, but you might be able to contribute further info. .. The problem is that since HTTP is stateless, you don't have the data available to show a confirmation page. For instance, suppose a user .. Another workaround is to have a database table or memcached key or something that stores a move ID with the info, and put the move ID .. A similar workaround would be to use cookies. This is nicer than the previous method, but has the potential to break confusingly if the .. Yet another workaround would be just to dispense with the confirmation page. For instance, when making a new post in a forum, the user could .. Yes, these are some of the workarounds I also had in mind which exemplify how web authors sometimes have to battle the page state handling in the browser. When/if this subject seems to relate to the HTML5 effort, I would like to contribute to a larger discussion on these kinds of topics. Best regards Mike
Re: [whatwg] page refresh and resubmitting POST state
Kornel Lesinski wrote: Is it possible for HTML 5 spec to say that browsers may re-send PUT without asking? It sounds like you are starting to agree with me that topics like these could deserve a place in the HTML5 spec :-) Aryeh Gregor wrote: On Sun, May 24, 2009 at 11:41 AM, Kornel Lesinski kor...@geekhood.net wrote: You store the data on server side, and redirect to URL that contains unique ID for this data. It's just a few lines in PHP (and similar solutions shuold be possible in all web frameworks): $id = uniqid(); $_SESSION[$id] = $_POST; header(Location: [.]/result.php?id=$id,false,303); and later: $_POST = $_SESSION[$_GET['id']]; This works even for multiple submissions done in parallel and it's pretty secure and tamper-proof. That does seem like a pretty good solution. Perhaps Mike Wilson can point out the problems with it. In an earlier mail I was referring to this solution as conversation id in URL, and yes, there are drawbacks with this as well. Best regards Mike
Re: [whatwg] page refresh and resubmitting POST state
Jonas Sicking wrote: On Sat, May 23, 2009 at 4:29 AM, Mike Wilson mike...@hotmail.com wrote: I was thinking about the resubmit problem in a general context, specifically how browsers could make it possible for web authors to create POSTing pages that avoids giving the dreaded do you want to resubmit question at all, independent of operation. Can you explain more in detail why PRG doesn't solve this problem? My understanding is that the do you want to resubmit UI comes up when sites *doesn't* use PRG, and the UI would disappear if they had used it. PRG solves the immediate problem of getting rid of the resubmission dialog, but creates another problem: loss of page state. Sometimes this is not a problem, but often when you work with web applications, it is. So, an author will have to choose between two evils; either go with plain POST, which will keep the page state but cause resubmission questions, or go PRG which will eliminate the questions but lose page state. At first, the loss of page state in PRG may seem solvable by tucking a handle to that data inside the URL, but this scheme gets complex and breaks down when you want to separate multi-window operations (and are facing New Window in IE or Duplicate Tab in Chrome), or when you want bookmarkable URLs. There is a whole spectrum of possible improvements that could help out in these cases, but they all involve defining something about state. F ex, plain POST pages have to ask their question because they don't know if the page state they carry is harmless data needed only for telling the server what to display, or if it is something that will trigger an undoable action. Usually the page state is a mix of both these. So, one improvement could be making it possible to specify (per input element) if the state is for redisplay or for action. Then pressing Refresh could safely send the redisplay state without asking the resubmission question, and leave out the action state. (Assuming we want the semantics of the Refresh button to be Redisplay and not Redo.) At the other end of the spectrum we could help authors using PRG, to associate state with their GET pages without adding to the URL. This could f ex be solved by giving the server the possibility to associate some state with each page load (delivered in headers or body), which is then sent back to the server (in header) on any request that leaves that page, including page refresh. Web storage is touching on the same problem, mentioning the limitations of cookies, but AFAICT depends on script and has no transparent UA/server transfer. These are just examples of constructs that could be possible. I hope I have provided enough information to determine if this is indeed a subject that is relevant for HTML5. Best regards Mike
Re: [whatwg] page refresh and resubmitting POST state
I was thinking about the resubmit problem in a general context, specifically how browsers could make it possible for web authors to create POSTing pages that avoids giving the dreaded do you want to resubmit question at all, independent of operation. Authors of Web Applications (the original name of the HTML5 spec ;-) are continuosly inventing new workarounds for this problem, all with different advantages and drawbacks, to achieve intuitive page handling when using a lot of POSTs. Examples of workarounds include PRG, flash scopes, conversation ids in URL, temporary cookie assignments, etc. Defining some support in the browser could replace or simplify parts of these solutions. But first I'd like to know if this subject is within scope of the spec. If it is, I could for starters imagine some prose about the UA asking the resubmit question on refresh of a page received through POST, as this is what current browsers do. Unless this is already covered by a referred spec, of course. Best regards Mike Kornel Lesinski wrote: As far as I understand the resubmit problem is just sign of poor implementation that violates SHOULD NOT in the HTTP RFC: http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.13 This problem can be elegantly solved within existing standards: Opera simply goes back in history without resubmitting forms, and resubmits only when user clicks standard Reload button (or F5, etc.) -- regards, Kornel Lesinski
Re: [whatwg] page refresh and resubmitting POST state
Kornel Lesinski wrote: Do you think that solution suggested by RFC 2616 13.13 is not appropriate? It does not define what to do at page refresh, only history traversal, as far as I can see. Is Opera's solution of this problem not good enough? I think you are missing the point I am describing. I don't know if you develop Web Applications and are acquainted with the workarounds I've mentioned (conversation ids etc), but if you don't then it is probably hard to see my point ;-). Anyway, I respect your opinion that page refresh is enough well-defined by RFC 2616 and the Opera implementation, and doesn't need coverage in the HTML5 spec. Thanks Mike
[whatwg] page refresh and resubmitting POST state
I can see some usefulness for adding a couple of subjects to the HTML5 spec: - how browsers should handle page refresh, in particular for pages received through POST (= do you want to resubmit?) - potentially add constructs to help users avoid the above resubmit question (this could f ex be through providing some support for PRG = Post-Redirect-Get, or other) Does this seem interesting? Best regards Mike Wilson
Re: [whatwg] page refresh and resubmitting POST state
Thanks for expanding on my previous mail, Jonas, but I was assuming that everyone on this list was aware of the PRG pattern and its existing support in browsers. With current technology there are limitations to the usefulness of PRG (f ex in multi-window/tab scenarios), so I am asking if it is within HTML5's scope to explore improved or alternative solutions to the resubmit problem. Best regards Mike Jonas Sicking wrote: On Fri, May 22, 2009 at 7:06 AM, Mike Wilson mike...@hotmail.com wrote: - potentially add constructs to help users avoid the above resubmit question (this could f ex be through providing some support for PRG = Post-Redirect-Get, or other) This is already supported. If you use a 302 or 303 redirect in response to a POST this will redirect to a uri that the UA then GETs. Refresing that page will simply result in a new GET to the second uri. Example: product.html contains a form method=POST action=addToCart.cgi. addToCart.cgi processes the parameters received from the POST request and replies with a 302 response with Location: displayCart.cgi. displayCart.cgi lists what is in the shopping cart. The result of this is that once the user submits the form on product.html, the UA will make a POST request to addToCart.cgi, then make a GET request to displayCart.cgi and display the result of that page. If the user refreshes the UA will again make a GET request to displayCart.cgi and display the result. / Jonas
Re: [whatwg] Exposing EventTarget to JavaScript
On Fri, Apr 24, 2009 at 2:42 PM, Boris Zbarsky bzbar...@mit.edu wrote: Alex Russell wrote: Something missing from this (and from Erik's original mail) is the ability to enumerate listeners. This has been brought up before. Incidentally I just posted a message over at public-webapps about exactly this feature (I discovered this thread afterwards): http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0345.html I'd be happy to continue this discussion here or there, whichever is suitable for everybody else. Best regards Mike Wilson
Re: [whatwg] Link.onload
Jonas Sicking wrote on 15 mars 2009 02:55: On Sat, Mar 14, 2009 at 1:48 PM, Greg Houston gregory.hous...@gmail.com wrote: This is a request for the link element to be given an onload attribute. This sounds like a good idea to me. Seems useful for dynamically added stylesheets too, and possibly for stylesheets where the href attribute is dynamically changed. I also think this is a good thing that should make it into the spec independently of the depends ideas. It is already specified that script elements fire (on)load or (on)error events (see end of 4.3.1[0]) to signal whether loading the external file was successful. Wouldn't it be nice and symmetric if analogous behaviour was specified for all loading of external resources? HTML5 already specifies onload/onerror event handlers for all elements so the actual handlers are already in place on link elements (and others). What remains is to define that link should actually fire these events. Best regards Mike Wilson
Re: [whatwg] HTML 5 : Misconceptions Documented
Ian Hickson wrote: On Sat, 17 Jan 2009, Mike Wilson wrote: So I wonder what is your process for determining if a quirk should be included in HTML5 or not? It basically boils down to did Web browser vendors find that if they didn't implement it, enough people complained to justify spending the resources to implement it after all?. Ah, so your process is really to look at if browser vendors historically have added special handling for individual quirks and then mimic popular solutions in the spec? Now I am just being curious ;-) but how on earth do you find all quirks (and if they have been specially dealt with) - is it up to reports on the mailing list or are you reading source code? :-) And do you generally find concensus among the non-MS vendors or are there many quirks that are only worked around in a single browser, and how do you handle that? The idea is to make it so that browsers don't feel forced to add _any_ non-standard behavior (other than experimental innovations using vendor-prefixed names and stuff). Do you think this will happen with the current popular browsers, ie will they actually remove existing code that implements workarounds that don't make it into HTML5? Or will they employ some legacy vs HTML5 mode switching where their custom workarounds are only in legacy mode? I guess what I am really thinking about is whether there will ever be a strict to standard HTML5 implementation, or a reference implementation, that stays exactly on what is written in (or easily interpolated from) the HTML5 spec...? Feel free to add questions to the FAQ, even without answers; someone will fill them in! :-) Magic! :-) Best regards Mike
Re: [whatwg] HTML 5 : Misconceptions Documented
Lachlan Hunt wrote: a lot of interesting stuff Thanks for all the information, it sounds good and reasonable. Well done! The idea is to make it so that browsers don't feel forced to add _any_ non-standard behavior (other than experimental innovations using vendor-prefixed names and stuff). Do you think this will happen with the current popular browsers, ie will they actually remove existing code that implements workarounds that don't make it into HTML5? Or will they employ some legacy vs HTML5 mode switching where their custom workarounds are only in legacy mode? snip There will not be, at least in Opera, Firefox or Safari, new modes added beyond the existing no quirks, limited quirks and quirks modes. Do you reckon all, or only some of, these modes will implement the HTML5 spec? (and differ only in css/rendering) Best regards Mike
Re: [whatwg] HTML 5 : Misconceptions Documented
Ian Hickson wrote: On Thu, 15 Jan 2009, Garrett Smith wrote: If I understand this correctly, given a FORM with an INPUT named 'b', if I change the name of that INPUT to 'a', then form.b should return the element with name=a. snip What is the reason for introducing the past names map behavior to the form? Compatibility with a legacy IE bug required (acording to Safari and Firefox devs) by legacy content. I'm impressed with the level of detail that you strive for in documenting real-world HTML :-) The idea of HTML5 is to make sure that a browser that implements all of HTML5 is compatible with legacy content. This is one of the things that legacy content requires, so the spec has to require it too. The idea is to make it so that browsers don't feel forced to add _any_ non-standard behavior (other than experimental innovations using vendor-prefixed names and stuff). That's a good thing. Still, seeing this quite non-trivial feature-bug being standardized, I see the potential for making the standard unnecessary complicated if including a lot of these legacy quirks. So I wonder what is your process for determining if a quirk should be included in HTML5 or not? Is there any listing of other quirks together with a yes/no decision whether to include them in HTML5? Also, what is the general ambition for compatibility with legacy content? Until reading this thread I personally thought HTML5's legacy compatibility revolved mainly around rendering and document validity, but now I realize it has a lot to do with script compatibility as well? And please do not take this message as criticism, these are just interesting (to me) questions that I couldn't find the answer to on the whatwg FAQ. Best regards Mike Wilson
Re: [whatwg] DOM-related and API-related feedback
Ian Hickson wrote on 28 december 2008 12:38: On Thu, 12 Jun 2008, Mike Wilson wrote: Ian Hickson wrote: window.focus() isn't in HTML5 as there doesn't appear to be a valid use case for it and it is too abusable, and thus shouldn't be supported. If pages depend on it being supported we could make it a no-op, I guess. I would think the opposite. Being able to pop a browser window to front is quite useful, and I have used it f ex in notifier windows that sit in some kind of loop checking for a condition (possibly minimized) and pop up to front when there is new data. And I wouldn't want to use alert() in these cases. As a user, I would find such behavior incredibly annoying. I think you need to think about not only alien pages that want to do you harm, but also about web applications f ex on intranets that solve a complex task through the use of multiple windows. I've had users of the latter demand that we (the developers) raise windows automatically based on different events. Personally I'm not a fan of auto-raising windows (f ex MS Windows does it too often for my taste) but I think these users' use cases have been valid. I've now specced window.focus() and window.blur(), but mostly as no-ops. I've noted that window.focus() could trigger a notification. I read your updated text, and while it is great that you have added the notification stuff, I think removing focus's current behaviour is a hard legacy to break. Even good scripts would need to workaround it at times. I think UAs could be encouraged to handle focus like many popup blockers do; have a global setting to determine the default behaviour (system focus|notification|ignore) and then being able to override this setting for f ex selected sites or the current session. Focusing an element inside a window should raise the window or hidden tab at the UA's discretion. I think the opposite about this one too, I guess it shows how different web users may think about their visual experience ;-) Popping a window to front on every programmatic element focusing would make windows pop to front more often than needed. Windows should be forced to front as little as possible as this is messing with the user's desktop experience. Also regard users that don't use the standard Windows focus model (click to focus = focused window on top) but rather the X-mouse-model (focus follows mouse = focused window may be partially obscured). If they are typing data into a partially obscured browser window that then calls elem.focus() to move keyboard focus, they will get an undesired window raise. So, I think it is desired to distinguish between element keyboard focus and window raising, and only let the latter be done explicitly and not as a side-effect of doing the former. I don't see any reason to let the latter be done at all really. I'm confused. I responded to this sentence in your previous mail: Focusing an element inside a window should raise the window or hidden tab at the UA's discretion. but now you say that this should never be done (which I think is fine btw). What did I misinterpret? Best regards Mike Wilson
Re: [whatwg] window.onerror -ancient feature needs upgrade
[didn't notice this discussion at the time] Garrett Smith wrote on 20 August 2008 04:08 On Tue, Aug 19, 2008 at 6:16 PM, Ian Hickson [EMAIL PROTECTED] wrote: Is window.onerror not enough? window.onerror would be sufficient if it: * accepted an Error parameter. * fired when an EventListener callback had an Error * fired when a callback in setTimeout had an Error But unfortunately, none of the above is true. At least some of it is true in some browsers. A very nice improvement list! These are exactly the flaws I've been hitting when trying to use window.onerror for something useful in Ajax apps. Instead we have had to resort to decorating all event handlers with try/catch logic. I'm not sure I follow what the problem is here. Is this to aid debugging? Yes. window.onerror seems useful for testing and debugging but leaves some to be desired. The way we would have liked to use it is actually for fallback error handling/presentation in Ajax apps. Ie, if you need custom error handling for some site function then implement it as try/catch in the respective event handler, but if you just want error presentation with standard recovery then let it bubble out to the global error handling in window.onerror. Naturally, for this scenario it is also important with the Error parameter for onerror. Best regards Mike Wilson
Re: [whatwg] About input type=hidden
Ian Hickson wrote: On Fri, 17 Oct 2008, Mike Wilson wrote: but for more decoupled systems you may want to specify a HTML snippet per object type or similar - and then apply recursive view rendering on an object graph. I agree, but it seems that having the hidden inputs be inside the next li of a list, or the next td, or whatever is appropriate, isn't much to ask for. It's good that you see what problems I am describing. There are two problems here, and I think you are mainly referring to the one which is about the templating system having to parse the HTML it is producing to find the next insertion spot. This is solvable but would be nice to not having to do. The other problem is that you sometimes would have to produce new markup, and probably hide it, in case there is no next li or tr f ex. (I notice that the requirement for at least one td has not been loosened up as it has been for tr.) Anyway, I understand that you do not see a good way of letting postable state become position independent, so we can close this discussion. Best regards Mike Wilson
Re: [whatwg] input type=hidden and validation
I suggested the same thing a week ago: http://www.nabble.com/input-type%3Dhidden-outside-phrasing-content-td275 4.html#a2754 with replies here: http://www.nabble.com/Re:-input-type%3Dhidden-outside-phrasing-content-td200 00847.html#a20023298 The short answer is that for some elements (eg FORM) this is already solved in HTML5, but for other elements (eg TABLE) it is not, and the responses were not too positive about changing that. Best regards Mike Wilson -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Oldrich Vetešník Sent: den 22 oktober 2008 17:42 To: [EMAIL PROTECTED] Subject: [whatwg] input type=hidden and validation Hello, I'd like to throw a question out here, please don't shoot me if it's been already answered, I'm a full-time coder and don't have an internet at home so I can't make any deep researches in your archives. Q: Is it possible that hidden inputs don't have to be in a semantic tag? That is it passes the validation test without showing this error up: line 20 column 32 - Error: document type does not allow element input here; missing one of p, h1, h2, h3, h4, h5, h6, div, pre, address, fieldset, ins, del start-tag It's because hidden inputs aren't meant to be shown to the front-end user so it doesn't mean if it's not covered in a semantic tag. Sometimes it's O.K., you have a form with a few fieldsets so you can put it in one, but sometimes it's rather stupid having to do divinput type=hidden name=somename value=somevalue //div just to silence the validator. Thank you, Ollie
Re: [whatwg] input type=hidden and validation
Ian Hickson wrote: I believe in HTML5 that we've allowed input in most places, which should satisfy your needs. Let us know if it does not. :-) We discussed this last week http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-October/016655.html and HTML5 is certainly a step forward in this respect. Still, HTML5 doesn't allow input everywhere in the document. For visible input fields this is of course a good thing, but for hidden input it would be good to have more flexibility. My use-case is a server-side solution that is to automatically add hidden postable state to just about any HTML fragment (the form is taken care of on an outer level). To make this in a valid way today presents quite a few challenges like traversing table models or adding extra td:s just for state. I don't have any universal solution, but possibilities include: - allowing hidden input:s to actually live anywhere (this is probably hard to do dtd/validation-wise) - inventing some hidden postable state that is orthogonal to the element structure and thus can be added to any element (maybe an extended version of the data attributes?) - keeping the whole thing invalid but still define in HTML5 how the migration of ill-placed input:s should work (I did a little research on the last point here: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-October/016718.html ) Do you have comments or any other ideas? Best regards Mike Wilson
Re: [whatwg] input type=hidden and validation
Ian Hickson wrote: On Wed, 22 Oct 2008, Mike Wilson wrote: - allowing hidden input:s to actually live anywhere (this is probably hard to do dtd/validation-wise) It's easy to specify, the problem is that it makes it easy for authors to get in trouble if they change the type attribute on the fly (e.g. in an editor or from script). Certainly. None of this is easy. It's also not clear why this is necessary -- putting it in the first cell of a row, or the next li in an ol, seems trivial. Assuming you are in control of the whole page's markup at once then I agree. But when you are not and, it may be far from trivial. (I mentioned an example of this in the link I included earlier http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-October/016718.html ) - keeping the whole thing invalid but still define in HTML5 how the migration of ill-placed input:s should work That is theoretically already defined. Interesting. Is it the foster-parenting of tables you are referring to, or is there anything more specific for input:s? Best regards Mike Wilson
Re: [whatwg] input type=hidden outside phrasing content
Anne van Kesteren wrote: I'd suggest playing with validator.nu. Out the top of my head: Ah, thanks for the link. I tried the different examples and your hunch was correct for all of them (tables and lists having problems). For the table and lists cases, is there a good use case for complicating their content model This being a good or important use case is hard to say - I guess it is one of these real-world annoyances that both webdevs and browsers have learnt to cope with. As part of the HTML5 initiative is based on real-world browser behaviour I was thinking this may be a candidate for some spec adjustment in some form (maybe just defining graceful migration). or could you just as well put the input either before or after the table or list? For hand-coding I certainly could, I see no real reason to do what I suggest here when you are in control of the complete markup. But it gets harder for the scenario I was mentioning in my initial mail: [some incarnations of] server-side templating. Many templating systems work with the whole page at once to specify what markup to generate for specific data, but for more decoupled systems you may want to specify a HTML snippet per object type or similar - and then apply recursive view rendering on an object graph. Along the way the system may want to insert hidden state that it wants posted back later, and the easiest way to accomplish this is something like inserting a hidden input just after the respective snippet's top element. (If there are snippets designed for actually editing the data these will have been hand-coded to include inputs in valid places so this is not an issue.) So, for an example hierarchical object structure: obj1 obj2 obj3 we may have the following associated HTML snippets: obj1 - TABLE... obj2 - TR... obj3 - TD... If we want the system to insert hidden state along the way the naive solution would look like this: TABLE INPUT obj1 state TR INPUT obj2 state TD INPUT obj3 state which is not valid. We could make this smarter by moving TABLE's state before the element instead of as first child, but the TR is harder to fix. We could have the system add an extra TD to hold the state for the row object but this is starting to affect the rest of the page a bit much. Andy Lyttle wrote: This is something I wanted to do recently. I was building HTML in a Perl script, adding table rows in a loop, and I wanted some rows to contain text field with user-editable value, while for other rows I wanted the value to be displayed but not editable Yes, this is sort of similar to my scenario above, and you were able to workaround it being in control of the whole markup in one place (and not completely decoupled as I describe above). I think this is one of those things that webdevs keep hitting every now and then, and it is caused by a kind of inter- mingling of document structure and POSTable state in HTML/DOM. Kristof Zelechovski wrote: So, where a paragraph is not allowed, neither is the INPUT control; inserted where it does not belong, it migrates; the document is invalid but it can be rescued. I had a look at migration in a TABLE structure for a few different browsers (by inspecting the DOM) and the results are sort of interesting: Firefox 3: Hidden INPUTs are kept in their exact place where they were specified but visible INPUTs in invalid locations are moved up and in front of their parent element(s) until they have a valid position. Safari 2: Visible INPUTs in invalid locations are moved up and in front of their parent(s) and hidden INPUTs are moved up and behind their parent(s). Though, POST parameter order is preserved and not affected by the INPUT reorganization in the DOM. Safari 3 and Chrome: All INPUTs in invalid locations are moved up and in front of their parent(s). Opera 9.60: All INPUTs in invalid locations are kept in the exact place they were specified in and no migration is done. (And visible fields are still displaying correctly.) IE6 and IE7: All INPUTs in invalid locations are (sort of) kept in place but are wrapped with an extra unnamed element, f ex: TABLE INPUT TR ... Summing this up I think FF3 has an interesting behaviour as they sort of already do what I am suggesting. Visible INPUTs should be placed where their element is allowed to be rendered, but hidden INPUTs could really be placed anywhere. Best regards Mike Wilson
Re: [whatwg] input type=hidden outside phrasing content
Kristof Zelechovski wrote: Why is FORM INPUT[type=hidden] not enough? Hi Chris, I'm sorry I don't follow your comment. My suggestion is about input type=hidden currently not being allowed in all locations in a document. Could you elaborate? (Maybe the followups below will make things clearer anyway.) Anne van Kesteren wrote: Where is it currently not allowed that you would like to allow it? It's pretty much allowed anywhere already as far as I can tell. Yes, maybe it is? Reading the spec again, I realize I had missed the sentence All phrasing content is also flow content. (I was mainly on the lookout for DTD-like info.) I have included a couple of the cases I'm thinking of below (that are invalid in HTML4). But some of them may already be ok in HTML5? form ... input type=hidden ... /form blockquote input type=hidden ... /blockquote table input type=hidden ... /table table tr input type=hidden ... td/td /tr /table ul/ol/dl input type=hidden ... /ul/ol/dl Tab Atkins Jr. wrote: For arbitrary state accessible to in-page scripting (like javascript), html5 defines the data-* family of attributes on all elements. These can have any name (as long as it starts with data-) and can hold arbitrary data. Yes, I'm aware of them and they actually have an interesting property in that they introduce page state in a way orthogonal to the element structure, as they allow data binding without introducing a new element or enforcing a certain element structure. (My focus this time is on POSTable state so the data- props won't do, but it would be interesting if hidden POSTable data could be added orthogonally to the element structure in a fashion similar to data-.) For POSTable state, the state needs to be within the form that's being submitted in any case, so being able to place the hidden state outside of the form wouldn't get you much. Can you elaborate on what you're proposing? Certainly, and no it is not outside the form I'm seeking but rather the odd cases above (imagine an outer form on all examples but the first). Best regards Mike Wilson -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Wilson Sent: Wednesday, October 15, 2008 9:40 PM To: whatwg@lists.whatwg.org Subject: [whatwg] input type=hidden outside phrasing content Would it be possible to have HTML5 allow the insertion of input type=hidden ... (or something with the same effect) anywhere in the document? This would f ex relieve cases like server-side templating wanting to attach hidden state to its generated markup, and not having to use complex algorithms to find a suitable spot. As this type of element is non-visual this suggestion shouldn't cause any layout problems, but I guess having different placement rules for different settings on the same element type is, so maybe using input is not possible. Could HTML5 support adding hidden POSTable state in another way, that wouldn't be subject to placement rules for visual content? Best regards Mike Wilson
[whatwg] input type=hidden outside phrasing content
Would it be possible to have HTML5 allow the insertion of input type=hidden ... (or something with the same effect) anywhere in the document? This would f ex relieve cases like server-side templating wanting to attach hidden state to its generated markup, and not having to use complex algorithms to find a suitable spot. As this type of element is non-visual this suggestion shouldn't cause any layout problems, but I guess having different placement rules for different settings on the same element type is, so maybe using input is not possible. Could HTML5 support adding hidden POSTable state in another way, that wouldn't be subject to placement rules for visual content? Best regards Mike Wilson
Re: [whatwg] Web Sockets
Blocking I/O on the main thread is ok if it's possible to specify a timeout for the I/O operation, see: http://www.openajax.org/runtime/wiki/Synchronous_XHR_Enhancements and if the UA'a user interface is kept responsive (running animated GIFs, repainting UI etc) and allows the user to abort the blocking operation (f ex as a new use of the Stop button), see: http://www.openajax.org/runtime/wiki/Browser_Unresponsive_Mode_Enhancements Best regards Mike Wilson -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brady Eidson Sent: den 7 juli 2008 22:50 To: Mike Ter Louw Cc: whatwg; Ian Hickson Subject: Re: [whatwg] Web Sockets On Jul 7, 2008, at 12:57 PM, Mike Ter Louw wrote: Joking aside, should a blocking read/recv call be made available? In some cases additional lag may be an acceptable compromise for maintaining the JavaScript call stack until a response arrives. My personal take (and the take of most of the people I work with) is that blocking i/o on the main thread should be out of the question. No matter what assumptions, guarantees, or compromises are understood in a rationalization for allowing it, we've seen time and time again that they backfire and lead to poor user experiences and bad performance problems. Notice I'm explicitly mentioning the main thread - if we get a clear, clean spec for worker threads and we restrict blocking i/o to such worker threads, then sure - go for it! ~Brady
Re: [whatwg] Focus management
Ian Hickson wrote: window.focus() isn't in HTML5 as there doesn't appear to be a valid use case for it and it is too abusable, and thus shouldn't be supported. If pages depend on it being supported we could make it a no-op, I guess. I would think the opposite. Being able to pop a browser window to front is quite useful, and I have used it f ex in notifier windows that sit in some kind of loop checking for a condition (possibly minimized) and pop up to front when there is new data. And I wouldn't want to use alert() in these cases. Then maybe this functionality really should have another function name, popToFront() or something, but I don't think there is enough reason to change it. Focusing an element inside a window should raise the window or hidden tab at the UA's discretion. I think the opposite about this one too, I guess it shows how different web users may think about their visual experience ;-) Popping a window to front on every programmatic element focusing would make windows pop to front more often than needed. Windows should be forced to front as little as possible as this is messing with the user's desktop experience. Also regard users that don't use the standard Windows focus model (click to focus = focused window on top) but rather the X-mouse-model (focus follows mouse = focused window may be partially obscured). If they are typing data into a partially obscured browser window that then calls elem.focus() to move keyboard focus, they will get an undesired window raise. So, I think it is desired to distinguish between element keyboard focus and window raising, and only let the latter be done explicitly and not as a side-effect of doing the former. Lastly, I guess if deprecating window.focus() devs would start using myDummyElem.focus() instead, to achieve the same result? Best regards Mike Wilson
Re: [whatwg] Thoughts on HTML 5 - dialog
Tab Atkins Jr. wrote: My personal favorite alternate suggestion so far has been cl. Yes, I also quite like the analogy with dl/ul/ol. But it may be confusing when using dt and dd as child elements (as in the current spec for dialog): cl dt dd ... /cl That could be resolved by introducing elements ct and cd: cl ct cd ... /cl and that I guess can be regarded as making things better OR worse depending on your focus... Best regards Mike Wilson
Re: [whatwg] Thoughts on HTML 5 - dialog
Zachary Carter wrote: FWIW, in my first encounter with HTML5 dialog I assumed it meant a dialog box. Yes, I assumed the same thing. I think it would be better to not use such an overloaded term for the stated purpose. The spec itself uses dialog in both meanings: 3.4.6 ... tabbed dialogs ... (= dialog box) 3.9.5 dialog element (= conversations) 4.2 ... showModalDialog (= dialog box) 4.5.1 Simple dialogs (= dialog boxes) I think it would be better to choose any other word from the suggested ones, as I think most of them do not already have another meaning within the HTML5 spec. The first paragraph of 3.9.5 gives a hint: The dialog element represents a conversation. so my first recommendation would be to go for conversation and live with its length. Many other element names are abbreviated so could also opt for that: convers spkdlg (spoken dialog) etc etc. Ian Hickson wrote: I agree that the initial name, if that's all you see, has the opportunity to confuse, but once you read what the element was really for, did the confusion continue to be a problem? Personally, I guess I can learn the intended meaning of the element. But, each time I see the element there is a feeling that this is wrong and I have to focus to remember the element's real purpose. I guess this is what more people are feeling and that this is why you are getting so much feedback on this fairly simple issue. Best regards Mike Wilson
Re: [whatwg] Scripts not in the active document
Ian Hickson wrote: Jonas Sicking wrote: Scripts can actually still run fine even if you navigate away from a page. But there are definitely weird things happening (such as global scope being different from 'window'). Could you elaborate on this? I'm not clear on how to define this. This may be nothing new, but in DWR we have had to handle a few cases related to this, and browsers differ. The scenario is that the user is navigating away from a page that still is doing some kind of script-related request to the server: Case 1: The page is doing a request to the server through a hidden IFRAME that receives a page containing script. It differs whether the request will be allowed to complete and the script be run. (and window environment may go away) Case 2: The page is doing a request to the server through XHR. It differs whether onreadystatechange callback is triggered. [XHR may be out of scope here, I'm just mentioning it for completeness.] Best regards Mike Wilson
Re: [whatwg] Modal dialogs in HTML5
If I understand it correctly, the suggested sections and irrelevant
attribute would make dialogs work quite like current modal HTML
dialogs from various js libs (the latter making use of backdrops to
hinder access to original page content) as new content from the same
page is swapped into view in front of the original content.
The modality comes natural when the original content is swapped out
from view and only the dialog content is accessible.
Though, I wonder if these two cases are addressed by sections/
irrelevant:
1. See-through-view modality
Is it possible to pop a dialog on top of (while still showing) the
original content, but hindering interaction with it? (much like what
current js libs offer with their dialog classes)
2. Unload modality
Most modality discussed so far has been about the view modality, ie
disallowing the user from accessing the original page content until
the dialog has been dismissed. Browser modality may also be about
not letting the browser unload/reload the page until a dialog has
been dismissed (eg do you want to save before closing the window?).
Is there any way to force a user to respond to a modal dialog
section before unloading the page?
If not, ideally a generic modality feature could be added to assist
both sections and current style HTML dialogs in achieving this
unload modality.
Best regards
Mike Wilson
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson
Sent: den 27 april 2008 10:59
To: [EMAIL PROTECTED]
Cc: Web APIs WG (public)
Subject: Modal dialogs in HTML5
On Fri, 27 Apr 2007, Jon Barnett wrote:
On 4/26/07, Ian Hickson [EMAIL PROTECTED] wrote:
On Sun, 26 Jun 2005, Karl Pongratz wrote:
I had a short look at the webforms and web applications
specification at whatwg.org, I didn't find anything
about modal and
modeless windows. If there is anything to improve for
html, xhtml,
xforms and compound documents, then, in my opinion, the first
missing feature that comes into my mind is the lack of
modal and
modeless windows.
I've now added window.open(), irrelevant=, and target= to the
specification, which should provide various ways of obtaining the
effect you're looking for. For example, with
irrelevant= you can
hide the content you want to disable, and force the
modal aspect of
the application to be responded to before reshowing the
other parts.
Can I ask how that would work with a dialog? Would it be like this?
myframeddocument.designMode = on;
mytoolbar.hyperlinkButton.onclick = function() {
myframeddocument.body.irrelevant = true;
var dialog = window.open(hyperlinkDialog.html);
// a dialog where the user may either enter a URL or choose
from a preset
list of pages on his site
dialog.onunload = function() {
processHyperlinkSelections();
myframeddocument.body.irrelevant = false;
}
}
Is that really the best way?
No, I meant everything within the one document, with
sections for each
part of the app, and all but the current section having
irrelevant=
set.
Would that keep dialog on top of the main browser window
until it's
dismissed?
You should only use one browser window ever, as a Web app author.
I used the WYSIWYG example because I think it's a good case where
authors really want some sort of modal dialog that's
synchronous in the
opener document's javascript. Is there a better way to handle that?
I'm also curious why the features argument of window.open
is supposed
to have no effect. That's something I can search the
archives for on
my own if it's been asked and answered.
Because none of the features that browsers support are things that
actually should be supported, as they are not things that
help the user.
On Fri, 27 Apr 2007, Thomas Broyer wrote:
If I correctly understood Ian's proposal, the best way
would be to not
use another window.
1. put the content of hyperlinkDialog.html within the current page
(or eventually load it within an iframe) and make it irrelevant=true
(let's call this the hyperlink editing section)
2. when you click the hyperlink toolbar button, make the
hyperlink
editing section irrelevant=false
3. when the OK or Cancel button inside the hyperlink
editing section
is clicked, do what's needed and switch the section back to
irrelevant=true
Pretty much.
On Sun, 27 Jan 2008, Karl Pongratz wrote:
You say:
Notwithstanding the features that make this possible, I
have to say that in
general Web applications on the Web should not be written
as if they are
desktop applications.
1.) We actually miss web application models. Do you know of
any where
they are defined, though some which don't have any quirks?
Application
models where the web browser back/next and reload button
doesn't harm
anything? Maybe its time to fix
