Jonas Sicking wrote:
1.
[...]
it would be better if you could actually navigate between
https://mail.google.com/mail/inbox
https://mail.google.com/mail/label/personal
https://mail.google.com/mail/label/whatwg
https://mail.google.com/mail/label/whatwg/13b4711edac9c1e2
and then
Ian Hickson:
On Tue, 11 Aug 2009, Nils Dagsson Moskopp wrote:
Am Dienstag, den 11.08.2009, 07:27 + schrieb Ian Hickson:
On Tue, 11 Aug 2009, Julian Reschke wrote:
Ian Hickson wrote:
- the literal letters T and Z must be uppercase
It simplifies processing a tiny amount.
So for a tiny
On Wed, Aug 19, 2009 at 5:31 PM, Jeremy Orlowjor...@chromium.org 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
I see. It makes more sense why you mentioned the session storage element
then. Note that there has been some discussion about whether session
storage should survive crashes, but I know Safari and Chrome are currently
planning to _not_ serialize it to disk.
I don't have any good use cases for
I guess this is just a vision about what the developer really
wants to do, or are you thinking of any solutions that would
actually allow changing path (or query string) without loading
a new Document?
The pushState function as currently specified allows you to do
precisely this.
On Thu, Aug 20, 2009 at 11:20 AM, Jeremy Orlowjor...@chromium.org wrote:
I see. It makes more sense why you mentioned the session storage element
then. Note that there has been some discussion about whether session
storage should survive crashes, but I know Safari and Chrome are currently
On Thu, Aug 20, 2009 at 3:13 PM, Justin Lebar justin.le...@gmail.comwrote:
On Thu, Aug 20, 2009 at 11:20 AM, Jeremy Orlowjor...@chromium.org wrote:
I see. It makes more sense why you mentioned the session storage element
then. Note that there has been some discussion about whether session
On Wed, Aug 19, 2009 at 5:31 PM, Jeremy Orlow jor...@chromium.org wrote:
Btw, storing a GUID and using session storage really isn't useful since
session storage itself only stores strings.
Btw, I lied. This part of the spec just changed, so now DOM Storage can
store anything that supports
Hi,
There are already two demos of converting Microdata to other formats which
I found quite useful [1]. I've taken a closer look at the Microdata DOM
API and hacked up a somewhat working JavaScript implementation of it [2].
A few issues came up in the process:
To avoid total confusion
Overall, I think preserving history API information when restoring sessions
is a good thing. My only concern is whether web developers will program in
such a way that this works. Unless ALL state will need to be either saved
in the history API or reconstructible from that information, bad
From 4.2.4:
If one the two files was returned without a Content-Type metadata, or
with a syntactically incorrect type like Content-Type: null, then
the default type for stylesheet links would kick in.
I believe it should read If one _of_ the two files
Chris
--
Chris Cressman
From 4.2.4:
The LinkStyle interface is also be implemented by this element; the
styling processing model defines how.
I believe it should read The LinkStyle interface is also _to_ be
implemented
Chris
--
Chris Cressman
http://chriscressman.com
12 matches
Mail list logo
