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.
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
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
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
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
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
|
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
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
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
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
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)
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
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
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:
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);
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
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
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
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)\._.,--,'``.
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
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
21 matches
Mail list logo
