the page?
If not, ideally a generic modality feature could be added to assist
both sections and current style HTML dialogs in achieving this
unload modality.
Best regards
Mike Wilson
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson
Sent: den 27
the element there is a feeling that
this is wrong and I have to focus to remember the element's real
purpose.
I guess this is what more people are feeling and that this is
why you are getting so much feedback on this fairly simple issue.
Best regards
Mike Wilson
onreadystatechange callback is triggered.
[XHR may be out of scope here, I'm just mentioning it for
completeness.]
Best regards
Mike Wilson
by introducing elements ct and cd:
cl
ct
cd
...
/cl
and that I guess can be regarded as making things better OR
worse depending on your focus...
Best regards
Mike Wilson
myDummyElem.focus() instead, to achieve the same result?
Best regards
Mike Wilson
the blocking
operation (f ex as a new use of the Stop button), see:
http://www.openajax.org/runtime/wiki/Browser_Unresponsive_Mode_Enhancements
Best regards
Mike Wilson
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Brady Eidson
Sent: den 7 juli 2008 22
state in another
way, that wouldn't be subject to placement rules for visual
content?
Best regards
Mike Wilson
).
Best regards
Mike Wilson
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mike Wilson
Sent: Wednesday, October 15, 2008 9:40 PM
To: whatwg@lists.whatwg.org
Subject: [whatwg] input type=hidden outside phrasing content
Would it be possible to have
Mike Wilson
(eg FORM) this is already solved
in HTML5, but for other elements (eg TABLE) it is not, and the responses
were not too positive about changing that.
Best regards
Mike Wilson
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Oldrich Vetešník
Sent: den 22
how
the migration of ill-placed input:s should work
(I did a little research on the last point here:
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-October/016718.html
)
Do you have comments or any other ideas?
Best regards
Mike Wilson
Ian Hickson wrote:
On Wed, 22 Oct 2008, Mike Wilson wrote:
- allowing hidden input:s to actually live anywhere (this is
probably hard to do dtd/validation-wise)
It's easy to specify, the problem is that it makes it easy
for authors to
get in trouble if they change the type
Ian Hickson wrote:
On Fri, 17 Oct 2008, Mike Wilson wrote:
but for more decoupled systems you may want to specify a
HTML snippet per object type or similar - and then apply
recursive view rendering on an object graph.
I agree, but it seems that having the hidden inputs be inside
to the global error
handling in window.onerror.
Naturally, for this scenario it is also important with the Error
parameter for onerror.
Best regards
Mike Wilson
Ian Hickson wrote on 28 december 2008 12:38:
On Thu, 12 Jun 2008, Mike Wilson wrote:
Ian Hickson wrote:
window.focus() isn't in HTML5 as there doesn't appear to
be a valid use case for it and it is too abusable, and
thus shouldn't be supported. If pages depend on it being
rendering
and document validity, but now I realize it has a lot to do with
script compatibility as well?
And please do not take this message as criticism, these are
just interesting (to me) questions that I couldn't find the
answer to on the whatwg FAQ.
Best regards
Mike Wilson
Ian Hickson wrote:
On Sat, 17 Jan 2009, Mike Wilson wrote:
So I wonder what is your process
for determining if a quirk should be included in HTML5 or not?
It basically boils down to did Web browser vendors find that if they
didn't implement it, enough people complained to justify
Lachlan Hunt wrote:
a lot of interesting stuff
Thanks for all the information, it sounds good and reasonable.
Well done!
The idea is to make it so that browsers don't feel forced to
add _any_ non-standard behavior (other than experimental
innovations using vendor-prefixed names and
).
What remains is to define that link should actually fire these events.
Best regards
Mike Wilson
exactly this feature (I discovered this thread afterwards):
http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0345.html
I'd be happy to continue this discussion here or there, whichever
is suitable for everybody else.
Best regards
Mike Wilson
be through providing
some support for PRG = Post-Redirect-Get, or other)
Does this seem interesting?
Best regards
Mike Wilson
if it is
within HTML5's scope to explore improved or alternative solutions
to the resubmit problem.
Best regards
Mike
Jonas Sicking wrote:
On Fri, May 22, 2009 at 7:06 AM, Mike Wilson
mike...@hotmail.com wrote:
- potentially add constructs to help users avoid the above
resubmit question
I was thinking about the resubmit problem in a general
context, specifically how browsers could make it possible
for web authors to create POSTing pages that avoids giving
the dreaded do you want to resubmit question at all,
independent of operation.
Authors of Web Applications (the original
Kornel Lesinski wrote:
Do you think that solution suggested by RFC 2616 13.13 is not
appropriate?
It does not define what to do at page refresh, only history
traversal, as far as I can see.
Is Opera's solution of this problem not good enough?
I think you are missing the point I am
Aryeh Gregor wrote:
You should spell out the existing problem carefully and in
great detail, including existing solutions or workarounds, to
get the best response.
I certainly intend to do this once I get feedback on whether
this subject is relevant for HTML5, or any other whatwg spec
: [.]/result.php?id=$id,false,303);
and later:
$_POST = $_SESSION[$_GET['id']];
This works even for multiple submissions done in parallel
and it's pretty
secure and tamper-proof.
That does seem like a pretty good solution. Perhaps Mike Wilson can
point out the problems
Jonas Sicking wrote:
On Sat, May 23, 2009 at 4:29 AM, Mike Wilson
mike...@hotmail.com wrote:
I was thinking about the resubmit problem in a general
context, specifically how browsers could make it possible
for web authors to create POSTing pages that avoids giving
the dreaded do you
Kristof Zelechovski wrote:
I certainly want refresh to redo, for example, when validating a local
document that I am editing.
Chris
What do you mean with editing a local document - is the document
contents being edited inside an input field (f ex textarea) on a
POSTing page?
Mike
, going back to my main point. All this is about de-facto, or
potential future, browser behaviour and thus would be
interesting in a spec about just that. The HTML5 effort is the
closest match I've found for this subject.
Best regards
Mike Wilson
Ian Hickson wrote:
On Fri, 22 May 2009, Mike Wilson wrote:
I can see some usefulness for adding a couple of subjects
to the HTML5 spec:
- how browsers should handle page refresh, in particular
for pages received through POST (= do you want to
resubmit?)
Done.
Nice, thanks
, in these state construct listings.
Best regards
Mike Wilson
Michael Nordman wrote:
This breakdown is a useful way to think about application state
in the browser.
Thanks, it has been very useful to myself as a working model for
making vague thoughts of something missing into something that
is possible to measure and compare. Ideally, some similar kind
or collection, would it be possible to
extend Web Storage to support this task?
Best regards
Mike Wilson
Michael Nordman wrote:
On Mon, Aug 3, 2009 at 3:05 AM, Mike
Wilsonmike...@hotmail.com wrote:
Assuming this shared state doesn't require a full
JavaScript global context, and could do with some
root object or collection, would it be possible to
extend Web Storage to support this task?
Michael Nordman wrote:
On Mon, Aug 3, 2009 at 2:37 PM, Mike Wilson wrote:
Btw, another reflection is that this mail thread is about
introducing a client/server model in the browser. Some
mentions of complex code in the background page, f ex building
the HTML for the visible window, make
and
hope to provide more information on that thread later
this month.
Best regards
Mike Wilson
it to a
string.)
Best regards
Mike Wilson
above)
The link points to 6.11.9 which is below, not above.
Best regards
Mike Wilson
)
up to the file URL (per your suggestion).
(Then if even Document.domain could be enhanced
with something to allow subsetting on path it'd be
great. But that has probably been discussed to death
a long time ago ;-)
Best regards
Mike Wilson
Sounds interesting!
You only mention a singular file, what do you think about multiple files?
Also, would it be possible to hook browser-produced data into this model, so
client-generated data (f ex text, html, pdf) could be dragged out as a
virtual file to the desktop?
Best regards
Mike
mentions
about having to cluster pages inside the same process
if they are to share data.
Why is this so, and why can't shared memory or proxied
objects be an option for browsers doing process
separation?
Best regards
Mike Wilson
From: whatwg-boun...@lists.whatwg.org
Michael Nordman wrote:
On Tue, Aug 18, 2009 at 6:07 AM, Mike Wilson mike...@hotmail.com wrote:
Threading:
This is the unavoidable question ;-) How do you envision
multiple threads accessing this shared context to be
coordinated?
Nominally, they don't. In our design for chrome's multi-process
possible. Now, as I
understand it, two pages sharing a GlobalScript MUST share a single thread,
or otherwise MUST use a different/duplicate GlobalScript instance.
On Tue, Aug 18, 2009 at 12:20 PM, Mike Wilson mike...@hotmail.com wrote:
With this stated, I'd like to throw out a question on what do
(this is actually a very important
distinction)
I'm hoping Ian will come back with the use cases he has in
mind, as I am as of yet not clear on what he wants, or does
not want, to support with the pushState model.
Best regards
Mike Wilson
Patrick Mueller wrote:
Or perhaps these GlobalScripts - should really be called
GlobalObjects or GlobalContexts maybe; SharedScope?
I like Shared as this is the term used in SharedWorkers
to identify something that can be shared between multiple
pages. SharedContext?
Best regards
Mike
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
and then
Justin Lebar wrote:
The pushState function as currently specified allows you to do
precisely this. History.pushState(obj, title, url) creates a new
history entry with the given URL, but doesn't load a new document.
Ah thanks, I had missed the part saying that path and query
were ok to change.
Justin Lebar wrote:
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
Justin Lebar wrote:
Maybe the right solution is to have a pageStorage object, which works
just like sessionStorage but is local to a session history entry and
perhaps carries some weak promise of persistence.
Yes, I was also thinking that being able to store key/value
pairs, instead of a
this? :
/pages/section1/thing1:
script src=/pages/script.js
button onclick=impersonate();
/pages/script.js:
function impersonate() {
...pushState(..., /pages/section2/thing2);
}
Best regards
Mike Wilson
[1] http://dev.w3.org/html5/spec/Overview.html
(btw, the latest WD link gives
Justin Lebar wrote:
Mike Wilson wrote:
Sorry, it seems we are not talking about the same application.
Jonas referred to attachment pages in your bug database, which
I assumed would f ex be a page like this one:
https://bugzilla.mozilla.org/attachment.cgi?id=386244action=edit
.
Best regards
Mike
Justin Lebar wrote:
Mike Wilson wrote:
What you're essentially saying here is that when restarting
the browser, you will also restore history data, correct?
For tabs that were open when the browser was closed, this
will mean that these will reappear after restart
Justin Lebar wrote:
Mike Wilson wrote:
It would be interesting to see a concrete
example on how you intend the dynamics of your solution to
work. It would be great if you could outline the different
events and method calls used (in order) to save and restore
the history state object
Ian Hickson wrote:
On Sun, 16 Aug 2009, Mike Wilson wrote:
Ian Hickson wrote:
I don't think we should encourage cases where the same
URL can correspond to multiple states, which this would
encourage.
This statement confuses me as the whole point of pushState
seems
to fulfill.
Best regards
Mike Wilson
Drew Wilson wrote:
This is one of those times when I *really* wish that the application
developer community was more active on this list. I absolutely understand
Linus' point of view, but I also feel like we are really hamstringing
applications when we make
Adam Barth wrote:
Mike Wilsonmike...@hotmail.com wrote:
I see what you mean. The ideal thing would be if we
could implement path-based security with the same
construct that adds path-based namespacing.
I realize the problem of backwards-compat, but have
there been any efforts or
Adam Barth wrote:
Mike Wilsonmike...@hotmail.com wrote:
- this mechanism needs a way to specify the blessed path,
maybe something along the lines of document.domain or a
response header
1) Document.domain is an abomination. We certainly don't want more
features like that.
2)
.
(There could very well be device-specific ways to
exchange files between browser storage and the
device's own storage representation.)
Best regards
Mike Wilson
Right, trying to answer on-topic ;-)
I guess if the spec doesn't mention anything about where
localStorage is persisted, it leaves it up to every browser
to decide whether to ask the user or use a default
location. Earlier I didn't think of the possibility of
localStorage data being stored in
Ian Hickson wrote:
On Fri, 21 Aug 2009, Mike Wilson wrote:
I'm currently wrapping my head around the notion of
first script in the spec [1]. It's description is
a bit terse and the subject seems non-trivial, so
maybe the text could be fleshed out some?
Section 6.1.5 Groupings
Ian Hickson wrote:
Given that all frames in a
browsing context have to be on the same thread,
regardless of domain, then unless we put all the
browsing contexts on the same thread, we can't
guarantee that all frames from the same domain
across all browsing contexts will be on the same
Jonas Sicking wrote:
On Sat, Aug 29, 2009 at 10:06 PM, Ian Hicksoni...@hixie.ch wrote:
Upon further consideration I've renamed getStorageUpdates() to
yieldForStorageUpdates().
I really liked Darin's (?) suggestion of allowStorageUpdates as that
seems to exactly describe the intended use
David Bennett wrote:
On Mon, Aug 31, 2009 at 5:30 PM, Drew Wilson atwil...@google.com wrote:
This would be my inclination as well. I'm not entirely convinced that every
web app should define their own idle timeout is such desirable behavior
that we should build our API around it by forcing
Ian Hickson wrote:
On Fri, 28 Aug 2009, Mike Wilson wrote:
My chain of thoughts is something like below (this is just
a general
picture so don't take it too literally):
- invent a more restrictive mechanism for script access
between documents from the same origin (host) so
Ian Hickson wrote:
On Mon, 31 Aug 2009, Mike Wilson wrote:
Ian Hickson wrote:
On Fri, 21 Aug 2009, Mike Wilson wrote:
[...]
Imagine that I want my loaded page:
/pages/section1/thing1
be able to impersonate:
/pages/section2/thing2
how do you envision
Adam Barth wrote:
On Thu, Sep 3, 2009 at 2:44 AM, Mike Wilson wrote:
Ok, that sort of defeats the point as it will not be possible
to depend on this security function for HTML5 features released
before its appearance in the standard - my idea was that f ex
WebStorage would refer
Ian Hickson wrote:
On Thu, 3 Sep 2009, Mike Wilson wrote:
- calling pushState(..., /pages/section1/thing2) when
first script's basedir=/pages/section1 will be ok
- calling pushState(..., /pages/section2/thing2) when
first script's basedir=/pages/section1 will not be
allowed
Justin Lebar wrote:
Mike Wilson wrote:
The result is that the address bar URL can't be trusted, as
any page on the site can impersonate any other without
consent from that page or part of the site?
Someone will correct me if I'm wrong, but I think this is already
pretty much the case
as well? (Even though this
would not be the case if done outside the transaction.)
In some cases it may be helpful to get this side-effect
notification for cookies as well...
Best regards
Mike Wilson
Chris Jones wrote:
I'd like to propose that HTML5 specify different schemes than a
conceptual
/022138.html
(22 messages)
Best regards
Mike Wilson
to do with
document.title
a bit more explicitly in the text, as this seems to be
easily misinterpreted (maybe because of the use of the
title identifer?).
Maybe adding a note to 6.10.1, and/or expanding the note
about title in 6.10.2 would be good?
Best regards
Mike Wilson
to
another origin, and not for navigation to a new origin.
Best regards
Mike Wilson
example to illustrate these needs, to aid the discussion
of solutions.
Best regards
Mike Wilson
[1]
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022211.html
is that this is not always practical, imagine f
ex serializing a large tree or rich-text editor on every update event.
(Btw, did you have any insight on issue #1?)
A merry Christmas to all you web-standard-oholics out there! :-)
Best regards
Mike
On Wed, Dec 23, 2009 at 10:52 AM, Mike Wilson
mike
Ian Hickson wrote:
On Wed, 19 Aug 2009, Mike Wilson wrote:
Currently, the design with an immutable state object and
the PopEvent
and HashChange events triggering at somewhat insufficient
timings, makes
it hard to build the things I'm thinking about.
IMO you need:
- an event
in bringing up any more server-
centric discussions. I do think there is a need though, to
cater for the classical server-side applications' state
management. But I am not sure what WG wants to do this.
Best regards
Mike Wilson
[1]
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-June
Ian Hickson wrote:
On Fri, 22 Jan 2010, Mike Wilson wrote:
I'll keep this short as there is more recent discussion:
2) The pageStorage object is one incarnation of [a key
value store] solving the dependency problem that appears
when different components want to save data
It seems the big questions here are whether to regard pushState
as a storage API, and whether to invent new API patterns instead
of reusing existing ones.
Is pushState about storage?
---
Ian Hickson wrote:
Mike Wilson wrote:
the semantic contract is coming closer
.)
Best regards
Mike Wilson
and forward)
Best regards
Mike Wilson
Best regards
Mike Wilson
regards
Mike Wilson
Mike Wilson wrote on December 26, 2010:
http://www.whatwg.org/specs/web-apps/current-work/#navigating-
across-documents
(as of December 26, 2010)
| When a browsing context is navigated to a new resource, the
| user agent must run the following steps:
...
| 9. Abort
the document in the navigation
algorithm's step 9.
But this is not what I am seeing in Firefox 3.6 or even IE6
(I tested a number of other browsers too but don't have the
exact versions handy).
The external resources all complete loading, with load events
and all.
Did I miss something?
Best regards
Mike
Boris Zbarsky wrote:
As I wrote in my initial post, my observation was actually
that this is contrary to current browser behaviour.
Ah, I see.
So in Gecko, at least, beforeunload fires before the document
is aborted.
Right, that matches my findings in other browsers as well.
So can
Hi John,
This event is actually already speced, see #14 fire a simple event
named error at the element in:
http://www.whatwg.org/specs/web-apps/current-work/#prepare-a-script
(and the onerror attribute is valid for all elements)
Best regards
Mike Wilson
John J. Barton wrote:
To allow
John J. Barton wrote:
Step 14 is unclear or incomplete however:
If the src
http://www.whatwg.org/specs/web-apps/current-work/#attr-script-src
attribute's value is the empty string or if it could not be resolved,...
Does this mean the error handler will be called in the case of 4XX, 5XX, and
Mike Wilson wrote:
John J. Barton wrote:
Step 14 is unclear or incomplete however:
If the src
http://www.whatwg.org/specs/web-apps/current-work/#attr-script-src
attribute's value is the empty string or if it could not be resolved,...
Does this mean the error handler will be called in the case
Thanks Ian,
Ian Hickson wrote on 14 december 2012 19:22:
On Fri, 14 Dec 2012, Mike Wilson wrote:
What events are supposed to be fired when the browsing context
gets navigated away before the current page has finished
loading, ie before the load event has been fired?
It's pretty
Ian Hickson wrote on 14 december 2012 21:11:
As a general rule, the intent of the spec is that you
get a load when all your scripts (and other resources)
have loaded, and you get an unload when the page is
going away. Thus if the page goes away before the page
has finished loading, you
89 matches
Mail list logo
