On Thu, Nov 12, 2009 at 12:33 AM, Boris Zbarsky bzbar...@mit.edu wrote:
I assume you meant mostly as in most of the pages are well-formed, not
pages are mostly well-formed, since the latter is useless, right?
I did a brief survey of obvious sites fitting those descriptions that I had
in my
Aryeh Gregor wrote:
On Thu, Nov 12, 2009 at 12:33 AM, Boris Zbarsky bzbar...@mit.edu wrote:
I assume you meant mostly as in most of the pages are well-formed, not
pages are mostly well-formed, since the latter is useless, right?
I did a brief survey of obvious sites fitting those descriptions
On Nov 11, 2009, at 11:24 PM, Marius Gundersen wrote:
I'm not exactly sure what you mean in the first case. How is the title change
hidden from the DOM? When you call document.title = new title, then the
title does change in the DOM and in the UI.
Sure, that's my point. You're talking
Boris Zbarsky a écrit :
On 11/11/09 10:19 PM, David Bruant wrote:
This attribute have the following properties :
- It's only dependant on the hardware, the operating system and the
WebWorker implementation (thus, it is not dynamically computed by the
user agent at each call and two calls in
The title [argument to pushState] is purely advisory. User agents might use
the title in the user interface.
But unlike the URL which actually changes in the Document object and is
therefore exposed to the DOM, this purely advisory title change is hidden
from the DOM. I'm questioning the
On 11/12/09 12:49 PM, David Bruant wrote:
= You're perfectly right. I reformulate the definition of running
conditions (appearing in condition 2 and 3) as :
same memory available, same number of process running concurrently, no
other worker running working on the same document.
That doesn't
On Nov 12, 2009, at 11:22 AM, Justin Lebar wrote:
The title [argument to pushState] is purely advisory. User agents might use
the title in the user interface.
But unlike the URL which actually changes in the Document object and is
therefore exposed to the DOM, this purely advisory title
As I alluded to in the thread AJAX History Concerns, I'm not
convinced that we need the history.clearState() function.
I haven't been able to come up with a compelling case where a page
would use this. I guess the idea is that I'm on Google Maps, which is
using pushState to make a history entry
Boris Zbarsky a écrit :
On 11/12/09 12:49 PM, David Bruant wrote:
= You're perfectly right. I reformulate the definition of running
conditions (appearing in condition 2 and 3) as :
same memory available, same number of process running concurrently, no
other worker running working on the same
On 11/12/09 10:00 PM, Justin Lebar wrote:
Perhaps a better idea is leaving this whole issue to the UA, which
could collapse all the entries from a single origin in the UI. Then
we wouldn't need either function.
How would UA collapse entries from a single origin?
I agree clearState is a bit
I should've responded to this more directly:
On Nov 12, 2009, at 12:00 PM, Justin Lebar wrote:
I think the use case I proposed is much better served by something
like history.truncate(numBefore, numAfter), which would remove all but
the numBefore entries before the current entry and the
On 11/12/09 3:40 PM, David Bruant wrote:
= If you are comparing no other processes running and one other
process which is also completely cpu-bound running, you are not in what
I've called same running conditions. (because the number of concurrent
processes is different).
Yes, but your
On Thu, Nov 12, 2009 at 1:08 PM, Olli Pettay olli.pet...@helsinki.fi wrote:
On 11/12/09 10:00 PM, Justin Lebar wrote:
Perhaps a better idea is leaving this whole issue to the UA, which
could collapse all the entries from a single origin in the UI. Then
we wouldn't need either function.
How
That said, we didn't implement clearState when we did
push/replaceState because it's hard to get right and we don't
currently have a compelling use case. There are probably lots of
things we'd change if we were going to implement it -- for instance,
why go back to the last entry instead of
On Fri, Nov 13, 2009 at 8:16 AM, Brady Eidson beid...@apple.com wrote:
I should've responded to this more directly:
On Nov 12, 2009, at 12:00 PM, Justin Lebar wrote:
I think the use case I proposed is much better served by something
like history.truncate(numBefore, numAfter), which would
On Nov 12, 2009, at 3:37 PM, Marius Gundersen wrote:
On Fri, Nov 13, 2009 at 8:16 AM, Brady Eidson beid...@apple.com wrote:
I should've responded to this more directly:
On Nov 12, 2009, at 12:00 PM, Justin Lebar wrote:
I think the use case I proposed is much better served by
Boris Zbarsky a écrit :
On 11/12/09 3:40 PM, David Bruant wrote:
I reformulate this way the conditions 2 and 3:
- In blank conditions (no other processes/thread running on the CPU,
enough memory to allocate the workers), running the same algorithm (an
easy delegation algorithm) has
On 11/12/09 7:24 PM, David Bruant wrote:
= I think it happens very often. While I'm writing this e-mail, no
process is running. About fifty processes are runnable, but not
running. They are passively waiting. My CPU is barely used.
Interesting. I have several browser processes using
On Thu, Nov 12, 2009 at 1:08 PM, Brady Eidson beid...@apple.com wrote:
I think clearState() is a good idea but is just spec'ed poorly.
Imagine the use case of the checkout procedure at an online merchant.
There's normally steps like enter your address, choose your shipping
method, enter
On Nov 12, 2009, at 4:39 PM, Jonas Sicking wrote:
On Thu, Nov 12, 2009 at 1:08 PM, Brady Eidson beid...@apple.com wrote:
I think clearState() is a good idea but is just spec'ed poorly.
Imagine the use case of the checkout procedure at an online merchant.
There's normally steps like enter
Sorry to self-reply. I just want to make four targetted points:
-As is, the language specifying clearState() has gapping holes that prevent us
from agreeing on what it is we're implementing.
-I personally think the intention of clearState() is useful and not a bad idea,
and that a more fine
On Wed, 11 Nov 2009, Brady Eidson wrote:
When pushState() or replaceState() are called with a URL argument, the
document's current address is changed. This has a lot of side effects
in that it is exposed to scripts and the DOM and most modern user agents
would update their UI to show
Hi,
I was waiting for Firefox to stop freezing on the HTML5 spec page (it
freezes about one minute each time I visit the one-page version) and I
tried to think of a way to design this page in a way that wouldn't
freeze my browser.
One good way I have found would be to cut the whole page into
On 11/12/09 9:21 PM, David Bruant wrote:
I was waiting for Firefox to stop freezing on the HTML5 spec page (it
freezes about one minute each time I visit the one-page version) and I
tried to think of a way to design this page in a way that wouldn't
freeze my browser.
Two easy ways to do this:
On Fri, Nov 13, 2009 at 1:46 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 11/12/09 9:21 PM, David Bruant wrote:
I was waiting for Firefox to stop freezing on the HTML5 spec page (it
freezes about one minute each time I visit the one-page version) and I
tried to think of a way to design this
25 matches
Mail list logo
