On Thu, Feb 28, 2008 at 10:31 AM, wrote:
We then, as developers, could use that attribute as we see fit and
the document would still validate (for people who care about such
things).
> -
Are people who care about things are the parenthetical afterthoug
Am Freitag, den 12.12.2008, 20:36 +0100 schrieb Calogero Alex
Baldacchino:
> The above (but the 'double check' I was suggesting) is about the way
> Firefox (2.x and 3.0.4) behaves (both href="#foo%20bar" and, in a
> different page, href="./example.html#foo%20bar" match id="foo bar"),
> while IE7
On Fri, 12 Dec 2008, Jonas Sicking wrote:
>
> Currently tokenizing the following string (starting at Data state)
> "
On Sat, Dec 13, 2008 at 1:01 AM, Jonas Sicking wrote:
> On Fri, Dec 12, 2008 at 4:52 PM, Jonas Sicking wrote:
>> Currently tokenizing the following string (starting at Data state)
>> " and .)
--
Philip Taylor
exc...@gmail.com
On Fri, Dec 12, 2008 at 4:52 PM, Jonas Sicking wrote:
> Currently tokenizing the following string (starting at Data state)
> "
Currently tokenizing the following string (starting at Data state)
"
On Fri, 12 Dec 2008, Martin Atkins wrote:
> Ian Hickson wrote:
> > On Fri, 12 Dec 2008, Bil Corry wrote:
> >
> > > Or maybe it'd be better if non-persistent cookies are removed once the
> > > user no longer has an open tab to the site, instead of using a
> > > JavaScript-based solution.
> >
> > T
Ian Hickson wrote:
On Fri, 12 Dec 2008, Bil Corry wrote:
Or maybe it'd be better if non-persistent cookies are removed once the
user no longer has an open tab to the site, instead of using a
JavaScript-based solution.
This could be done now; I recommend bringing this up with browser vendors
Ian Hickson wrote on 12/12/2008 5:11 PM:
> On Fri, 12 Dec 2008, Bil Corry wrote:
>>> Why do session cookies not address this already?
>> They do to some extent. You can choose to make the session life
>> shorter, increasing security but potentially logging the user out before
>> they're ready O
On Fri, 12 Dec 2008, Bil Corry wrote:
> >
> > Why do session cookies not address this already?
>
> They do to some extent. You can choose to make the session life
> shorter, increasing security but potentially logging the user out before
> they're ready OR you can choose to make the session lif
Ian Hickson wrote on 12/12/2008 2:34 PM:
> If the goal is auto-logout, then what you describe wouldn't help, as it
> would have false-positives (leaving the site when another tab still has
> the site open) and false-negatives (a crash wouldn't log out the user).
Well, more thought needs to go i
On Fri, 12 Dec 2008, Bil Corry wrote:
>
> Speaking of 'onbeforeunload' and 'beforeunload' -- it'd be helpful if
> there was a way to distinguish between the user taking an action which
> leaves the site vs. taking an action that returns to the site.
>
> For privacy, it shouldn't reveal which spe
Bil Corry wrote:
Here's a fun one, I made this as a demo to show how a website could trap a user
forever:
http://www.corry.biz/neverleave.lasso
I haven't tried it in any browsers lately, but a quick test with IE7 shows it
still is effective (for it at least).
I think this makes a
Bil Corry ha scritto:
Ojan Vafai wrote on 12/12/2008 12:49 PM:
If we're going for matching what browsers do, there's a number of cases
(different in each browser) where the confirm doesn't popup. In Chrome, for
example, if the beforeunload handler takes too long, we kill it and navigate
away.
Calogero Alex Baldacchino ha scritto:
Maybe the above needs a further clarification. Let me start from URL
parsing (and resolving) rules: after the URL is validated, it's
divided into its components, but nothing is stated about normalization
and/or %-encoded characters. I think that applying a
Ojan Vafai wrote on 12/12/2008 12:49 PM:
> If we're going for matching what browsers do, there's a number of cases
> (different in each browser) where the confirm doesn't popup. In Chrome, for
> example, if the beforeunload handler takes too long, we kill it and navigate
> away. Similarly, in Fire
On Fri, Dec 12, 2008 at 12:55 AM, Ian Hickson wrote:
> On Sun, 16 Nov 2008, ddailey wrote:
> >
> > Here's the sitch: because of an extensive use of CTRL sequences in the
> > interface, the user will sometimes accidentally do something like CTRL R
> > (which the browser thinks is a refresh command
Bil Corry ha scritto:
Speaking of 'onbeforeunload' and 'beforeunload' -- it'd be helpful if there was
a way to distinguish between the user taking an action which leaves the site
vs. taking an action that returns to the site. E.g.:
leaves site:
closes browser
Ian Hickson wrote on 12/12/2008 2:50 AM:
> On Thu, 28 Feb 2008, ddailey wrote:
>> The user opens a web application as one of many tabs in a web browser.
>> They then, either within the application window, accidentally hit CTRL W
>> (or its Mac equivalent), or from the operating system, issue a c
On Sun, 16 Nov 2008, ddailey wrote:
>
> Here's the sitch: because of an extensive use of CTRL sequences in the
> interface, the user will sometimes accidentally do something like CTRL R
> (which the browser thinks is a refresh command). In a regular app, if
> users stand in jeopardy of losing a
On Thu, 28 Feb 2008, ddailey wrote:
>
> The user opens a web application as one of many tabs in a web browser.
> They then, either within the application window, accidentally hit CTRL W
> (or its Mac equivalent), or from the operating system, issue a close
> application command. Most apps (as op
21 matches
Mail list logo
