Re: [whatwg] Section 1.7 "abstract language"
On Thu, 13 Aug 2009, Kevin Benson wrote: > On Thu, Aug 13, 2009 at 10:10 PM, Ian Hickson wrote: > > On Thu, 6 Aug 2009, Elliotte Rusty Harold wrote: > >> > >> "This specification defines an abstract language for describing > >> documents and applications, and some APIs for interacting with > >> in-memory representations of resources that use this language." > >> > >> The phrase "abstract language" concerns me. It's not clear to me that > >> a language can be abstract, nor is it clear to me what this phrase > >> refers to, especially since it seems to be distinguished from the > >> "concrete syntaxes that can be used to transmit resources that use > >> this abstract language, two of which are defined in this > >> specification." > >> > >> Perhaps there's some sort of abstract data model or information model > >> here; but I don't believe that the word "language" is appropriate to > >> describe this. Language as normally understood is a collection of > >> actual words or symbols, written or spoken. It is not a collection of > >> abstract concepts, at least not in any definition of the term I was > >> able to find. > >> > >> http://www.google.com/search?hl=en&safe=off&q=define%3Alanguage&aq=f&oq=&aqi=g10 > > > > What term would you recommend rather than "language" that is more > > understandable than "data model" or "information model"? > > > > Would "vocabulary" be ok? > > Rather than changing the word "language", how about changing the the > word "abstract" instead... ...to an adjective such as "prescriptive" or > "normative"... in order to describe the usage of the word "language" > more purposefully ? On Sat, 15 Aug 2009, Elliotte Rusty Harold wrote: > > "Vocabulary" may be an an improvement over "abstract language"--I'd need > to think further about that--but I think Kevin's suggestion is likely > better. The spec defines a language (not abstract) with two syntaxes (or > dialects, or variants). The word "abstract" is there to lead people away from thinking of HTML as being a concrete language in the sense that, e.g., C++ is a "language" or BibTex is a "language". I agree that "abstract" isn't really the right word, but omitting it I think would cause more confusion here. "Vocabulary" is wrong too, since it implies just a lexicon of words, rather than a grammar, content models, etc. If anyone has any ideas for a better term than "abstract language" that conveys all the richness that language does but without implying a syntax exists, please let me know. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] ARIA
On Thu, 28 Feb 2008, Dave Hodder wrote: > > The current HTML 5 draft doesn't mention ARIA anywhere. Perhaps it > should clarify the relationship (or non-relationship as it is at > present), even if it's only a brief mention in section 1.1. There's a section on it now. On Fri, 29 Feb 2008, James Graham wrote: > > Unfortunately a brief mention is insufficient as aria functionality > overlaps substantially with HTML functionality and so processing > requirements for aria-in-html need to be carefully considered (so we can > answer questions like "how does affect the > outline algorithm"). This has not yet happened. The answer is now "it does not". ARIA doesn't appear to have enough expressive power to be affected by the outline algorithm much, either (it's intended for authors, so there's no way to express the nested implied sections with it). On Fri, 7 Mar 2008, Simon Pieters wrote: > > I would guess that it's the AT that would be the one to implement the > outline algorithm. So if is reported the same way as > is, then does affect the document outline in the > AT the same way as affects the document outline. > > Otherwise, what is the AT supposed to do with the "heading" if not put > it in the list of headings? Surprise the user when he stumbles upon it > and say "Oh snap, that's a heading right there! Didn't see that one > coming."? :-) > > (BTW, I would be fine with solving this particular issue by dropping > "heading" from ARIA -- I don't see what problem it is trying to solve > that doesn't.) I don't really see how to solve this issue from HTML5's side. On Fri, 7 Mar 2008, Aaron Leventhal wrote: > > [...] On the other hand for the "landmark" roles which specify semantics > but not behavior, I would agree that sticking with HTML elements is a > better approach. Even if there is associated behavior for them, such as > a hotkey, they will degrade well to older user agents. Should I just say that you can't use these landmark roles on elements from HTML5 then? On Fri, 7 Mar 2008, James Graham wrote: > > OK, but we still need to specify what happens when they are used. To > take the aria-role="heading" example again, I believe it's a requirement > that a page that uses that has the same outline structure when viewed > using a tool that uses an accessibility API as it does when viewed > through a tool that accesses the DOM directly. I don't know how to achieve this. On Tue, 11 Mar 2008, Aaron Leventhal wrote: > > In general these are great questions. The question as I understand it, > should the spec spell out which role & properties you get naturally with > an HTML element, so an author knows if they even need to override them > with ARIA in the first place? I've done that. > > Therefore > > > > This is non-conforming now, but will result in the element appearing to AT users as a regular button. (And I guess the user gets really confused if they try to activate it.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Predefined classes are gone
On Fri, 18 May 2007, Lachlan Hunt wrote: > Ian Hickson wrote: > > In response to overwhelming feedback on this issue (especially in > > blogs, forums, and mailing lists other than this one, like www-html > > and public-html) I've removed the predefined classes. They're opaque > > again. > > > > The main use cases for predefined classes can mostly be dealt with > > using some of the new elements. class=note and class=example, for > > instance, can instead use elements, class=copyright can use > > , etc. > > The use cases for "error", "warning" and "search" aren't yet covered > well with other elements. > > * class="search" > > The aim of this one was to be able to indicate the form specifically > used for searching. This would then allow UAs, especially assistive > technology, to implement keyboard shortcuts or other mechanisms for > taking the user directly to the search form. role="search" is provided > by the role attribute spec for a similar purpose, and Safari also has > . I would prefer the new input type because it > also has direct benefits for regular users, not just those with > assistive technology. I've added , and made it possible to set role=search on elements like . > * class="error" > > The original idea for this was for indicating error messages, particularly > related form fields. The problem is that screen readers, when in forms mode, > only read the content of form control labels, which has resulted in authors > having to write any error messages within labels, which is kind of a hack. > Labels and error messages should be able to be separated and providing a way > to specifically indicate them would allow screen readers to indicate their > presence to the user and read it on request. > > * class="warning" > > This is similar to "error", but I can't recall the specific use cases. and the various live region features in ARIA now take care of these. > There are various possible solutions to replace error and warning, some > of which include the following. (This is just brainstorming, neither of > these are particularly well thought out ideas.) > > 1. New element (short for 'attention'), which is specifically for > attracting the users attention, which is exactly what errors and > warnings do. > > 2. A new attribute on to associate it with a related error message. > e.g. Foo > > You filled in an incorrect value > > The element is more generic and could probably solve other > similar use cases, whereas the the label attribute would only > specifically solve the form error use case. On Thu, 17 May 2007, Jon Barnett wrote: > > I like the idea of an element more than the other given ideas for > associating a message with a form or form control. It should have a "for" > attribute, like label: > Enter your new password id="password">Your password is too short > > In combination with a "role" attribute, it would solve issues with form > controls: > Enter your new password id="password">Your password is too > short > > An can attach to and elements as well. > Logging in was > unsuccessful... > > There might be a use case were might be able to attach to other > non-form elements. I can't think of a compelling one. > > (The idea of an "attn" attribute above leaves the error message twice > removed from its form control) I haven't added this, I'm not sure the use case is compelling enough. > I like the idea of a "role" attribute for reasons other than that it's new > and doesn't conflict with exiting "class" attributes. Authors assume that > the class attribute is theirs to use for scripting and styling without > outside interference from the UA. Author's don't assume this about the > "rel" attribute. Authors assume that the UA will assign meaning and > function to the "rel" attribute, such as rel=next. HTML4 leaves the > possible values for "rel" open-ended, but authors don't use it willy-nilly. > However, rel=nofollow exists because UAs decided to support it. "role" > should have the same type of existence. > > I don't think XHTML2's example values for "role" are useful (except "note" > and "search"). "error" and "warning" are good useful examples. In the same > vein, I would add "confirmation" or "success". "role" is now owned by ARIA, for all intents and purposes. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Dynamic content accessibility in HTML today
On Thu, 10 Aug 2006, Aaron Leventhal wrote: > > I have a specific question: what about adding the role attribute to > whatwg specs? Done, via reference to ARIA, and with a section describing restrictions on allowed values. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposed changes to the History API
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) I might be introducing horrible races into the HTML5 event model by doing this, though. -Justin
Re: [whatwg] Global Script proposal
Michael Nordman wrote:
I'm confused about the manual loading of the script into the context? The
original proposal called for providing a script url when creating/connecting
to an instance of a global-script... in which case each client page
expresses something more like...
globalScript = new GlobalScript(scriptUrl);
globalScript.onload = myFunctionThatGetsCalledWhenTheScriptIsLoaded;
// some time later onload fires, if the script was already loaded, its
called on the next time thru the message loop
Here's what Dmitry Titov proposed on 2009/08/17:
var context = new GlobalScript();
context.onload = function () {...}
context.onerror = function () {...}
context.load('foo.js');
--
Patrick Mueller - http://muellerware.org
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] Global Script proposal
Hi,
a general comment on the interesting GlobalScript proposal for helping
to structure client-side portions of a web application - have people looked
in detail at existing work & experiences made there? Like .NET's AppDomains.
cheers
--sigbjorn (s...@opera.com)
On 8/21/2009 21:47, Michael Nordman wrote:
I'm confused about the manual loading of the script into the context? The
original proposal called for providing a script url when creating/connecting
to an instance of a global-script... in which case each client page
expresses something more like...
globalScript = new GlobalScript(scriptUrl);
globalScript.onload = myFunctionThatGetsCalledWhenTheScriptIsLoaded;
// some time later onload fires, if the script was already loaded, its
called on the next time thru the message loop
... the system (not the client pages) keep track of how many client pages
are concurrently accessing the same GlobalScript.
On Fri, Aug 21, 2009 at 6:37 AM, Patrick Mueller wrote:
Patrick Mueller wrote:
Time to work on some examples. This would relatively easy to prototype in
something like Rhino (or my nitro_pie python wrapper for JavaScriptCore), at
least API wise, so we could see what the user-land code would look like, and
see it run.
I developed a simulator for this yesterday. My big take away is that the
current shape leaves users in a batteries-not-included state.
Here's the kind of code I had to write to arrange to create a new scope and
load a single script in it from multiple windows. Each window would run
this code in it's own context.
function loadLibrary(scopeName, script, callback) {
var scope = getSharedScope(scopeName);
// script already loaded in the scope
if (scope.__loaded) {
callback(scope, scope.__callback_data);
}
// script not yet done loading
else if (scope.__loading) {
scope.__onLoadedListeners.push(callback);
}
// first one in! much work to do ...
else {
scope.__loading = true;
scope.__onLoadedListeners = [];
function handler(callback_data) {
scope.__loaded= true;
scope.__loading = false;
scope.__callback_data = callback_data;
callback(scope, callback_data);
for (var i=0; ihttp://muellerware.org
Re: [whatwg] Global Script proposal
I'm confused about the manual loading of the script into the context? The
original proposal called for providing a script url when creating/connecting
to an instance of a global-script... in which case each client page
expresses something more like...
globalScript = new GlobalScript(scriptUrl);
globalScript.onload = myFunctionThatGetsCalledWhenTheScriptIsLoaded;
// some time later onload fires, if the script was already loaded, its
called on the next time thru the message loop
... the system (not the client pages) keep track of how many client pages
are concurrently accessing the same GlobalScript.
On Fri, Aug 21, 2009 at 6:37 AM, Patrick Mueller wrote:
> Patrick Mueller wrote:
>
>>
>> Time to work on some examples. This would relatively easy to prototype in
>> something like Rhino (or my nitro_pie python wrapper for JavaScriptCore), at
>> least API wise, so we could see what the user-land code would look like, and
>> see it run.
>>
>
> I developed a simulator for this yesterday. My big take away is that the
> current shape leaves users in a batteries-not-included state.
>
> Here's the kind of code I had to write to arrange to create a new scope and
> load a single script in it from multiple windows. Each window would run
> this code in it's own context.
>
> function loadLibrary(scopeName, script, callback) {
>var scope = getSharedScope(scopeName);
>
>// script already loaded in the scope
>if (scope.__loaded) {
>callback(scope, scope.__callback_data);
>}
>
>// script not yet done loading
>else if (scope.__loading) {
>scope.__onLoadedListeners.push(callback);
>}
>
>// first one in! much work to do ...
>else {
>scope.__loading = true;
>scope.__onLoadedListeners = [];
>
>function handler(callback_data) {
>
>scope.__loaded= true;
>scope.__loading = false;
>scope.__callback_data = callback_data;
>
>callback(scope, callback_data);
>for (var i=0; iscope.__onLoadedListeners[i](scope, callback_data);
>}
>}
>
>scope.runScript(script, {handler: handler});
>}
>
>return scope;
> }
>
> I changed the GlobalScript() constructor to a getSharedScope() function (at
> the top), and the load() function to a runScript() function which takes
> parameters including a callback function.
>
> I'm of two minds here.
>
> One is that the SharedScope proposal is really only appropriate for pages
> with lots of JavaScript that could be shared, or special use cases where you
> want (eventually) easy sharing between windows. As such, s smallish amount
> of JS framework-y-ness like this isn't a show stopper. In fact, as spec'd,
> separating out the scope and script loading, will let folks build
> mini-frameworks for themselves fairly easily, customized to their own needs.
>
> On the other hand, I wonder about the potential benefits of letting more
> people play in the space easier. The securable module work in the serverjs
> projects it a bit easier to use out of the box. I'm not sure they have an
> async story though, and async loading of scripts is where this stuff quickly
> gets complicated.
>
> --
> Patrick Mueller - http://muellerware.org
>
>
Re: [whatwg] Proposed changes to the History API
On Fri, Aug 21, 2009 at 12:26 PM, Mike Wilson wrote: > 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=386244&action=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=386244&action=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. I think whether or not a particular UA persists form field data (or anything other than history API data) is completely orthogonal to this discussion. For the sake of this discussion, lets assume there's some UA out there that ONLY persists history API data for recovery. That way the history API doesn't depend on any of these other features. Agreed? Getting back to your question, with both the original and the newly proposed API this is possible. The difference is that with the newer API, it's much easier to update an entry. For example, if I wanted history to include what was typed into a particular form field, I could just keep updating the history entry whenever the text changes or when I add a new history entry. With the old API, I'd have to create a unique ID that gets pushed via the history API, and then maintain all of that state elsewhere. I then depend on either both or neither of those APIs surviving a recovery. This is one of the reasons I think the proposed changes to the API are much more usable. J
Re: [whatwg] Global Script proposal
On Fri, Aug 21, 2009 at 6:37 AM, Patrick Mueller wrote:
> Patrick Mueller wrote:
>
>>
>> Time to work on some examples. This would relatively easy to prototype in
>> something like Rhino (or my nitro_pie python wrapper for JavaScriptCore), at
>> least API wise, so we could see what the user-land code would look like, and
>> see it run.
>>
>
> I developed a simulator for this yesterday. My big take away is that the
> current shape leaves users in a batteries-not-included state.
>
> Here's the kind of code I had to write to arrange to create a new scope and
> load a single script in it from multiple windows. Each window would run
> this code in it's own context.
>
> function loadLibrary(scopeName, script, callback) {
>var scope = getSharedScope(scopeName);
>
>// script already loaded in the scope
>if (scope.__loaded) {
>callback(scope, scope.__callback_data);
>}
>
>// script not yet done loading
>else if (scope.__loading) {
>scope.__onLoadedListeners.push(callback);
>}
>
>// first one in! much work to do ...
>else {
>scope.__loading = true;
>scope.__onLoadedListeners = [];
>
>function handler(callback_data) {
>
>scope.__loaded= true;
>scope.__loading = false;
>scope.__callback_data = callback_data;
>
>callback(scope, callback_data);
>for (var i=0; iscope.__onLoadedListeners[i](scope, callback_data);
>}
>}
>
>scope.runScript(script, {handler: handler});
>}
>
>return scope;
> }
>
> I changed the GlobalScript() constructor to a getSharedScope() function (at
> the top), and the load() function to a runScript() function which takes
> parameters including a callback function.
>
> I'm of two minds here.
>
> One is that the SharedScope proposal is really only appropriate for pages
> with lots of JavaScript that could be shared, or special use cases where you
> want (eventually) easy sharing between windows. As such, s smallish amount
> of JS framework-y-ness like this isn't a show stopper. In fact, as spec'd,
> separating out the scope and script loading, will let folks build
> mini-frameworks for themselves fairly easily, customized to their own needs.
>
> On the other hand, I wonder about the potential benefits of letting more
> people play in the space easier. The securable module work in the serverjs
> projects it a bit easier to use out of the box. I'm not sure they have an
> async story though, and async loading of scripts is where this stuff quickly
> gets complicated.
For a feature of this scope, I think it's much better to keep the API
surface area as low as is possible for the first version. If, out of the
frameworks, emerges a clear winner, then we should talk about expanding the
API. Until then, I worry we'll just be speculating/bike-shedding.
Thanks for doing this, btw!
J
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=386244&action=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=386244&action=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] Global Script proposal.
On Fri, Aug 21, 2009 at 11:10 AM, Aaron Boodman wrote: > On Fri, Aug 21, 2009 at 4:50 AM, Mike Wilson wrote: > > Another thing: > > > > From the proposal it seems it will be possible for the GlobalScript > context > > to keep references to objects (DOM, JS data, etc) private to pages, and > vice > > versa possible for pages to keep references to GlobalScript objects. This > > also opens up for a new way for independent pages finding and keeping > > references to each other's objects if they are somehow registered in the > > GlobalScript. > > > > When reloading a page there is also the additional dimension of the > > GlobalScript possibly holding references to objects both from the > previous > > and current incarnation of the Document. In a way it seems GlobalScript > > usage will in practice merge the JS worlds of all participating pages, > > potentially including those already navigated away from. > > > > What are your thoughts on this? > > Don't all of these problems already exist with window.open() and > frames? Can the existing solutions not be reused? It does look similar, so same methods could be used. One idea which was mentioned (and seems like nice to have) is to have a couple of events exposed to the GlobalScript global scope, 'connected' and 'disconnected' which would fire when a page connects to a GlobalScript and right after it is closed (so it 'disconnects' from it). This can help with housekeeping, although more thought should go into defining those, their parameters etc. Dmitry
Re: [whatwg] Global Script proposal.
On Fri, Aug 21, 2009 at 4:50 AM, Mike Wilson wrote: > Another thing: > > From the proposal it seems it will be possible for the GlobalScript context > to keep references to objects (DOM, JS data, etc) private to pages, and vice > versa possible for pages to keep references to GlobalScript objects. This > also opens up for a new way for independent pages finding and keeping > references to each other's objects if they are somehow registered in the > GlobalScript. > > When reloading a page there is also the additional dimension of the > GlobalScript possibly holding references to objects both from the previous > and current incarnation of the Document. In a way it seems GlobalScript > usage will in practice merge the JS worlds of all participating pages, > potentially including those already navigated away from. > > What are your thoughts on this? Don't all of these problems already exist with window.open() and frames? Can the existing solutions not be reused? - a
Re: [whatwg] Proposed changes to the History API
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. -Justin
Re: [whatwg] Proposed changes to the History API
> 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=386244&action=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=386244&action=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. Behavior with History API: When you click "edit as comment" and as you type your comments, the page periodically saves the data to pageState. When the page receives a popstate, it restores the state of the textarea. I imagine that one could rework the Bugzilla page to function better on browser restart using existing web technologies. But as the page is designed right now, some kind of pageStorage would be helpful. -Justin
Re: [whatwg] Global Script proposal.
Mike Wilson wrote: Another thing: From the proposal it seems it will be possible for the GlobalScript context to keep references to objects (DOM, JS data, etc) private to pages, and vice versa possible for pages to keep references to GlobalScript objects. This also opens up for a new way for independent pages finding and keeping references to each other's objects if they are somehow registered in the GlobalScript. When reloading a page there is also the additional dimension of the GlobalScript possibly holding references to objects both from the previous and current incarnation of the Document. In a way it seems GlobalScript usage will in practice merge the JS worlds of all participating pages, potentially including those already navigated away from. What are your thoughts on this? You could either force people to clean up after themselves, or they'll just be accumulating (essentially) garbage. Or you could imagine for contexts that have "gone away" (windows closed), the references to objects in those contexts magically become null. The second approach requires something like Smalltalk's become: method, at the JS engine level. And then folks might want to start asking for weak references, etc. Slippery slope to hell. Another issue with the "merge of JS worlds", which by the way is something which is done explicitly, not implicitly, will lead to potential version mis-match issues. Two pages accessing the same space may have different expectations of the versions of code loaded in them. This could be mitigated by using a version number in the space name, but that leads to a nightmare if you have lots of these spaces, having to apply version numbering for every change to your code. Java developers have a similar problem they affectionately call "ClassLoader hell". -- Patrick Mueller - http://muellerware.org
[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:
Re: [whatwg] Global Script proposal
Patrick Mueller wrote:
Time to work on some examples. This would relatively easy to prototype
in something like Rhino (or my nitro_pie python wrapper for
JavaScriptCore), at least API wise, so we could see what the user-land
code would look like, and see it run.
I developed a simulator for this yesterday. My big take away is that
the current shape leaves users in a batteries-not-included state.
Here's the kind of code I had to write to arrange to create a new scope
and load a single script in it from multiple windows. Each window would
run this code in it's own context.
function loadLibrary(scopeName, script, callback) {
var scope = getSharedScope(scopeName);
// script already loaded in the scope
if (scope.__loaded) {
callback(scope, scope.__callback_data);
}
// script not yet done loading
else if (scope.__loading) {
scope.__onLoadedListeners.push(callback);
}
// first one in! much work to do ...
else {
scope.__loading = true;
scope.__onLoadedListeners = [];
function handler(callback_data) {
scope.__loaded= true;
scope.__loading = false;
scope.__callback_data = callback_data;
callback(scope, callback_data);
for (var i=0; iI changed the GlobalScript() constructor to a getSharedScope() function
(at the top), and the load() function to a runScript() function which
takes parameters including a callback function.
I'm of two minds here.
One is that the SharedScope proposal is really only appropriate for
pages with lots of JavaScript that could be shared, or special use cases
where you want (eventually) easy sharing between windows. As such, s
smallish amount of JS framework-y-ness like this isn't a show stopper.
In fact, as spec'd, separating out the scope and script loading, will
let folks build mini-frameworks for themselves fairly easily, customized
to their own needs.
On the other hand, I wonder about the potential benefits of letting more
people play in the space easier. The securable module work in the
serverjs projects it a bit easier to use out of the box. I'm not sure
they have an async story though, and async loading of scripts is where
this stuff quickly gets complicated.
--
Patrick Mueller - http://muellerware.org
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
Re: [whatwg] Global Script proposal.
Another thing: >From the proposal it seems it will be possible for the GlobalScript context to keep references to objects (DOM, JS data, etc) private to pages, and vice versa possible for pages to keep references to GlobalScript objects. This also opens up for a new way for independent pages finding and keeping references to each other's objects if they are somehow registered in the GlobalScript. When reloading a page there is also the additional dimension of the GlobalScript possibly holding references to objects both from the previous and current incarnation of the Document. In a way it seems GlobalScript usage will in practice merge the JS worlds of all participating pages, potentially including those already navigated away from. What are your thoughts on this? Best regards Mike _ 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 'UI windows' simpler and independent. Another case is an application that uses navigation from page to page using menu or some site navigation mechanism. Global Script Context could keep the application state so it doesn't have to be round-tripped via server in a cookie or URL. For example, wizard-like file upload web application could be implemented as a simple sequence of static pages connecting to the local Global Script. It also makes browser's history feature 'just work' so there is no need for complicated history managers like this: http://developer.yahoo.com/yui/history/. Note that Global Script should be able to live through a page-to-page navigation for this to work well. Yet another use case is provided by JS frameworks like SproutCore (http://wiki.sproutcore.com/Basics-Introducing+SproutCore+MVC) which try to bring to the Web the traditional Model-View-Controller model which is based around having a single data model which can be bound to various 'views'. The binding usually happens via Controller that keeps specific mapping between the application's data structure and the structures needed to support UI views. Controller is also the one responding to UI events and figuring out what change should be applied to the model. This means that controller is best shared across 'UI pages' and run on the same thread. The Model part cou
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
[whatwg] [Replaceable] members of window
It looks like the frames and length members of the Window interface need to be [Replaceable] for web content to work correctly. I'd assume that any new attributes will probably also need the same treatment as they might otherwise clash with global variables. -- Andrew Oakley
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 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=386244&action=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
