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
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 all
On Fri, Dec 12, 2008 at 12:55 AM, Ian Hickson i...@hixie.ch 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
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
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
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 specific
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 life
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 OR you can
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
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.
This could be done
Currently tokenizing the following string (starting at Data state)
!--foo results in a parse error when hitting the 'f'. It seems like
the error is in the Comment start dash state (section 8.2.4.19). It
should switch to 'comment state' when a '-' is consumed, which is not
what it currently does.
On Fri, 12 Dec 2008, Jonas Sicking wrote:
Currently tokenizing the following string (starting at Data state)
!--foo results in a parse error when hitting the 'f'.
As far as I can tell, it does not.
Assuming we're in a normal state of affairs, here are the states we visit
and the parse
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 and
On Thu, Feb 28, 2008 at 10:31 AM, h...@nczonline.net 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
14 matches
Mail list logo
