On Wed, Feb 2, 2011 at 5:30 PM, Boris Zbarsky wrote:
> I should note that it's not clear to me how much we want to standardize
> what browsers actually copy when the user copies. This seems like something
> that users may want to configure and where we want to let browsers
> experiment with heur
On Wed, Feb 2, 2011 at 5:30 PM, Boris Zbarsky wrote:
> This doesn't work for disconnected subtrees. Or rather, it presupposes
> certain things about the browser's architecture that I don't think we want
> to presuppose.
Specifically what? That browsers might not resolve CSS for
disconnected sub
Oh, I think I now understand what Jonas meant.
Proposal A, as I understand it:
1) Don't fire an initial popstate, because this causes stale popstates
when pushState is called before the popstate.
2) Expose the state object to the DOM so pages can find out what the
initial state is when they load
The file input gained the @accept attribute a little while ago, to
indicate what type of file should be accepted. It has three special
values, "image/*", "video/*", and "audio/*".
I believe one intent of these special values is that browsers may
offer the user the ability to capture an image/vide
On 2011-02-02 23:48, Jonas Sicking wrote:
I think my latest proposed change makes this a whole lot better since
the state is immediately available to scripts. The problem with only
sticking the state in an event is that there is really no good point
to fire the event. The later you fire it the lo
On Wed, Feb 2, 2011 at 2:34 PM, Justin Lebar wrote:
>> So during loading, any script that wants to know what the initial (or
>> current) state is does not need to wait for the first popstate, but
>> can simply grab the state and go.
>
> Yeah, I think it's too late to move to this approach.
Even i
> So during loading, any script that wants to know what the initial (or
> current) state is does not need to wait for the first popstate, but
> can simply grab the state and go.
Yeah, I think it's too late to move to this approach.
> My thinking was that if someone calls replaceState, then probab
On 2/2/11 4:51 PM, Aryeh Gregor wrote:
I've based the spec entirely on CSS, with no reference to
specific HTML elements, because this matches what the user sees.
This doesn't work for disconnected subtrees. Or rather, it presupposes
certain things about the browser's architecture that I don't
On Wed, Feb 2, 2011 at 2:05 PM, Justin Lebar wrote:
> I'm a bit uncomfortable with this behavior, since it seems that having
> replaceState cancel the initial popstate is at least somewhat
> surprising.
>
> How is this better than never firing an initial popstate?
My thinking was that if someone
I'm a bit uncomfortable with this behavior, since it seems that having
replaceState cancel the initial popstate is at least somewhat
surprising.
How is this better than never firing an initial popstate?
-Justin
On Mon, Jan 31, 2011 at 6:32 PM, Jonas Sicking wrote:
> On Thu, Dec 23, 2010 at 6:18
Currently I'm writing a specification for converting part of a DOM to
plaintext, with the eventual goal of precisely specifying innerText
and Selection.toString(). (Currently it's written only for innerText,
but adapting it to Selection is a detail.) I'd appreciate feedback on
what I've got so fa
In terms of spec changes:
- Step 5 in
http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#dom-history-replacestate
would be changed to set a flag if the ready state is not "complete"
- Same thing in step 11
http://www.whatwg.org/specs/web-apps/current-work/multipage/history.ht
On Mon, Jan 31, 2011 at 4:20 PM, Ian Hickson wrote:
> On Thu, 11 Nov 2010, Michael Nordman wrote:
>>
>> In section "6.6.6 Changes to the networking model" which applies to sub
>> resource loads, step 3 prevents returning fallback resources for
>> requested urls that fall into a network namespace.
On Wednesday 2011-02-02 20:41 +, Ashley Sheridan wrote:
> For the links to open a new web page that would actually be
> handled by an external app. I remember a few years back when
> Yahoo! Messenger came with such an app that set itself up as your
> default mail program and opened a new window
"Boris Zbarsky" wrote:
>On 2/2/11 3:22 PM, Michael Nordman wrote:
>> That does sound like a bug? I'd be curious to know what the reasoning
>> was for the existing sequence of steps.
>
> From what I can tell, current browser behavior.
>
>> Step 10 looks out of place too...
>>
>> "10. If the new re
On 2/2/11 3:22 PM, Michael Nordman wrote:
That does sound like a bug? I'd be curious to know what the reasoning
was for the existing sequence of steps.
From what I can tell, current browser behavior.
Step 10 looks out of place too...
"10. If the new resource is to be handled using a mechanis
That does sound like a bug? I'd be curious to know what the reasoning
was for the existing sequence of steps.
Step 10 looks out of place too...
"10. If the new resource is to be handled using a mechanism that does
not affect the browsing context, e.g. ignoring the navigation request
altogether be
On Feb 2, 2011, at 03:07, Ian Hickson wrote:
> I suppose we could make it so that scripts get neutered when the document
> that they were first associated with gets unloaded. Would that work?
We did something different.
> Proposal #1:
Proposal #4 (what Gecko now does):
* If at the time when
18 matches
Mail list logo
