>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
>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
http://ch
> 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
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 I'
On Wed, Aug 19, 2009 at 5:31 PM, Jeremy Orlow 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 structured clonin
On Thu, Aug 20, 2009 at 3:13 PM, Justin Lebar wrote:
> On Thu, Aug 20, 2009 at 11:20 AM, Jeremy Orlow 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, b
On Thu, Aug 20, 2009 at 11:20 AM, Jeremy Orlow 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
> planning to _not_
> 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. History.
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 allo
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
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 w
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
>
> a
12 matches
Mail list logo
