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
[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: 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
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; iscope.__onLoadedListeners.length; i++) {
scope.__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
[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] 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
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=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. 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] 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] Global Script proposal.
On Fri, Aug 21, 2009 at 4:50 AM, Mike Wilsonmike...@hotmail.com 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] Global Script proposal.
On Fri, Aug 21, 2009 at 11:10 AM, Aaron Boodman a...@google.com wrote: On Fri, Aug 21, 2009 at 4:50 AM, Mike Wilsonmike...@hotmail.com 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] 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] Global Script proposal
On Fri, Aug 21, 2009 at 6:37 AM, Patrick Mueller pmue...@muellerware.orgwrote:
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.length; i++) {
scope.__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
On Fri, Aug 21, 2009 at 12:26 PM, Mike Wilson mike...@hotmail.com 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=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. 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
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 pmue...@muellerware.orgwrote:
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.length; i++) {
scope.__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] 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 pmue...@muellerware.orgwrote:
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.length; i++) {
scope.__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
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
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] 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] 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 aside elements, class=copyright can use small, 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 input type=search. 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 input type=search, and made it possible to set role=search on elements like section. * 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. output 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 attn 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 label to associate it with a related error message. e.g. label for=ctrl attn=ctrl-errorFoo/label input id=ctrl span id=ctrl-errorYou filled in an incorrect value/span The attn 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 attn 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: label for=passwordEnter your new password/labelinput id=passwordattn for=passwordYour password is too short/attn In combination with a role attribute, it would solve issues with form controls: label for=passwordEnter your new password/labelinput id=passwordattn for=password role=errorYour password is too short/attn An attn can attach to form and fieldset elements as well. form id=loginattn role=error for=loginLogging in was unsuccessful/attn.../form There might be a use case were attn 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] 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 div aria-role='heading' 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 div role=heading is reported the same way as h1 is, then div role=heading does affect the document outline in the AT the same way as h1 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 h1 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 input type=checkbox role=button 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. `._.-(,_..'--(,_..'`-.;.'
