Þann mán 30.maí 2011 03:42, skrifaði Felix Halim:
Hmm.. yes, I think unlimited is a bad word (I just use it because
currently App Cache quota is unlimited).
Let me explain my need for pageStorage in a different way:
Suppose I have a web page and want to store it in an App Cache. This
web page
Harald,
Point taken. Having spent a lot of time with the different versions of
the Postel Mail specifications, I got my citation incorrect.
The appendices to RFC 821, however, well prove my point. As noted
directly in Section 1, Introduction:
SMTP is independent of the particular transmission
[Apologies for being out of the loop on this thread thus far, as I was one
of the main proponents of it earlier this year. I am now going to dive in
and offer some feedback, both to Ian's comments as well as to others that
have replied. I also apologize that this will be an exceedingly long
On Thu, May 12, 2011 at 4:28 PM, Aryeh Gregor simetrical+...@gmail.com wrote:
Behavior for Enter in contenteditable in current browsers seems to be
as follows:
* IE9 wraps all lines in p (including if you start typing in an
empty text box). If you hit Enter multiple times, it inserts empty
On Fri, May 13, 2011 at 5:53 PM, Ian Hickson i...@hixie.ch wrote:
On Fri, 13 May 2011, Robert O'Callahan wrote:
Can you put a note in the spec that we're thinking of changing this
behavior, so developers are less likely to start depending on it, and
we've got some cover in case it breaks
Sorry for repetition, but we can already preload images and CSS and apply
them to the page at an arbitrary point in time. Why wouldn't we want the
same thing for JavaScript?
I think the question is whether you want _more_ than that for JavaScript.
For images, you can preload them and choose
This isn't practical if the contents of the script are not under the
author's direct control. For example, an author that wanted to use jquery
would create a script tag with the src set to one of the popular jquery
mirrors (to maximize the chance of the resource being cached), but then have
no
If browsers processed (parsed compiled) scripts in a background thread
it would mitigate the problem, but not solve it. Suppose I have 100K of
JS I need right now to generate the DOM for the initial page, and I have
another 500K of JS that's only needed if the user clicks on FeatureX.
Assuming
I think there's a valid use case for downloading a script and not
evaluating it immediately.
I think we all agree on that.
Boris-
I wish that were true, at this point, but I'm not sure that it is. The tone
I got from Ian's post (and even subsequent replies) was that he in fact does
not see
On Mon, May 30, 2011 at 10:39 PM, Bjartur Thorlacius
svartma...@gmail.com wrote:
The following is how I understand your requirements; please correct me where
correction is due.
You've got two types of resources:
1. static resources, to be retrieved once and cached indefinitely
2. dynamic
10 matches
Mail list logo
