On Sat, 27 Feb 2010 01:12:21 +0100, Anne van Kesteren ann...@opera.com
wrote:
On Fri, 26 Feb 2010 23:28:12 +0100, Maciej Stachowiak m...@apple.com
wrote:
On Feb 26, 2010, at 11:37 AM, Michael Nordman wrote:
Sure, but a better name could help a bit. For example, this produces
a 'shared'
On Feb 4, 2011, at 03:13, Jonas Sicking wrote:
On Thu, Feb 3, 2011 at 4:45 PM, Kyle Simpson get...@gmail.com wrote:
? One reason I like the noexecute proposal more than relying on
readyState is that noexecute can be used in markup. I.e. you can do
things like:
html
head
script src=a.js
Tab Atkins Jr. wrote:
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
On Tue, 08 Feb 2011 10:28:15 +0100, Henri Sivonen hsivo...@iki.fi wrote:
On Feb 4, 2011, at 03:13, Jonas Sicking wrote:
On Thu, Feb 3, 2011 at 4:45 PM, Kyle Simpson get...@gmail.com wrote:
? One reason I like the noexecute proposal more than relying on
readyState is that noexecute can be
On Tue, Feb 8, 2011 at 1:28 AM, Henri Sivonen hsivo...@iki.fi wrote:
On Feb 4, 2011, at 03:13, Jonas Sicking wrote:
On Thu, Feb 3, 2011 at 4:45 PM, Kyle Simpson get...@gmail.com wrote:
? One reason I like the noexecute proposal more than relying on
readyState is that noexecute can be used in
Jonas Sicking wrote:
On Tue, Feb 8, 2011 at 1:28 AM, Henri Sivonen hsivo...@iki.fi wrote:
On Feb 4, 2011, at 03:13, Jonas Sicking wrote:
On Thu, Feb 3, 2011 at 4:45 PM, Kyle Simpson get...@gmail.com
wrote:
? One reason I like the noexecute proposal more than relying on
readyState is
On Tue, Feb 8, 2011 at 10:44 AM, Henri Sivonen hsivo...@iki.fi wrote:
I thought the case being addressed here is fetching scripts early but not
compiling or evaluating them until the app knows the functionality provided
the script is going to be needed. The degradation story depends on the
On Tue, 08 Feb 2011 17:06:52 +0100, John Tamplin j...@google.com wrote:
I am not on the GMail team, but we did see similar issues on the GWT
team -- simply parsing the downloaded script takes a lot of time and
interferes with user interaction with the UI, so as awkward as it seems,
On Tue, Feb 8, 2011 at 11:10 AM, Anne van Kesteren ann...@opera.com wrote:
Is there a specific problem with letting Web Workers handle this use case?
They should not interfere with the UI thread.
I'm not really the one to answer and I don't know the details of the problem
or solution, I was
On Tue, 08 Feb 2011 17:21:31 +0100, John Tamplin j...@google.com wrote:
I'm not really the one to answer and I don't know the details of the
problem
or solution, I was just trying to give some background to why it was done
the way it was given the comment from Henri.
Also, I thought Web
On Tue, Feb 8, 2011 at 11:35 AM, Anne van Kesteren ann...@opera.com wrote:
They have a way to download and execute scripts. So if the UI thread has a
minimal script that takes care of creation of workers and creates a tunnel
for DOM modifications you could theoretically be all set. (I have not
On Tue, Feb 8, 2011 at 1:41 AM, Rich Tibbett ri...@opera.com wrote:
Tab Atkins Jr. wrote:
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
? I think we should do the readyState thing and put a note in the spec
saying that implementors should be polite to authors and not implement the
readyState property until they also implement the behavior that setting .src
on a not-in-tree node starts the HTTP fetch (in order to make the
On 2/8/11, Tab Atkins Jr. jackalm...@gmail.com wrote:
Right now it's entirely unobvious that UAs should even *think* about
offering the functionality to record a file, so I think it would be
useful.
It's unobvious to me that UAs need to offer the functionality specifically,
rather than rely on
The goal of this proposal is exactly what you're saying: to separate download
from parse/execution.
I don't think it's a common case that people would use these features via
markup; I do think it's a common case for people to use these features via
JavaScript to aid in dynamic script loading.
Web Workers don't adequately solve this problem because:
1) There is no DOM. If the script being loaded and execute requires interaction
with the DOM, it will just error out.
2) Assuming that #1 doesn't get in your way because you're not interacting with
the DOM, you still have the potential
? Is there a specific problem with letting Web Workers handle this use
case?
They should not interfere with the UI thread.
I think the primary reason why Web Workers is not useful is that it's not
widespread enough adoption yet to be useful to the script loader community.
On 2/8/11 3:56 PM, Kyle Simpson wrote:
Yes, it's important to note that it's not even the *execution* of
JavaScript code that's actually the particular issue, but rather just
the parsing of it (even if invoking of the functionality is deferred
until later) that causes the biggest slowdown, in
On 2/8/11 4:13 PM, Boris Zbarsky wrote:
On 2/8/11 3:56 PM, Kyle Simpson wrote:
Yes, it's important to note that it's not even the *execution* of
JavaScript code that's actually the particular issue, but rather just
the parsing of it (even if invoking of the functionality is deferred
until
On Tue, Feb 8, 2011 at 4:13 PM, Boris Zbarsky bzbar...@mit.edu wrote:
Here's the thing. Parsing is a black-box behavior. Nothing says a browser
needs to do it right before execution, that it needs to happen on the main
thread, or that it's happening at all.
For example, for Gecko we have
On 2/8/11 4:21 PM, John Tamplin wrote:
I think it is useful to provide ignorable hints to browser to indicate
that you want this downloaded but you don't need it parsed right away.
Yes, that's fine. As long as we're not adding some sort of new hard
requirements on actual behavior here, all's
Hi again,
Just had an offline discussion about this and I think the answer can
be much simpler than what's been proposed so far. All we have to do
for cross-origin HTTPS resources is respect the cache-control no-store
header.
Let me explain the rationale... first let's back up to the motivation
On Tue, 08 Feb 2011 16:06:52 -, John Tamplin j...@google.com wrote:
I am not on the GMail team, but we did see similar issues on the GWT
team --
simply parsing the downloaded script takes a lot of time and interferes
with user interaction with the UI, so as awkward as it seems,
On Mon, Feb 7, 2011 at 6:15 PM, Adam van den Hoven a...@littlefyr.com wrote:
But that is exactly what has happened, or perhaps some existing pollution is
simply being codified.
atob() and btoa() were first implemented years ago, I guess by
Netscape, and are supported in all major browsers
? Isn't this just a quality of implementation issue?
No, frankly it isn't. No matter how good the implementation of the
JavaScript engine on mobile, the mobile device will always be much more
limited in processing power than a desktop browser environment. There are
those who think that the
On Tue, Feb 8, 2011 at 7:31 PM, Kyle Simpson get...@gmail.com wrote:
It's also tempting to just get mired down in this one use-case of mobile
JavaScript parsing deferral. While this use-case is a great example of why
controlling execution is important, there are plenty of other use-cases for
On 2/8/11 7:31 PM, Kyle Simpson wrote:
No, frankly it isn't. No matter how good the implementation of the
JavaScript engine on mobile, the mobile device will always be much more
limited in processing power than a desktop browser environment.
That's not what the question was about.
It's also
Hi Philip, all,
On Sun, Jan 23, 2011 at 1:23 AM, Philip Jägenstedt phil...@opera.com wrote:
On Fri, 14 Jan 2011 10:01:38 +0100, Silvia Pfeiffer
silviapfeiff...@gmail.com wrote:
There are two sections - the first one concerns the WebVTT format and
the second one the track specification.
Can you list some of them? Most of the ones I can think of are ultimately
different forms of the same optimization.
I would first refer you to the use-cases that Steve Souders has documented
around his ControlJS library. His commentary on this topic is far more
comprehensive than anything I
On 2/8/11 11:04 PM, Kyle Simpson wrote:
No, frankly it isn't. No matter how good the implementation of the
JavaScript engine on mobile, the mobile device will always be much more
limited in processing power than a desktop browser environment.
That's not what the question was about.
The
On 01/24/2011 03:54 PM, Tab Atkins Jr. wrote:
Using existing CSS, it's easy to adapt text-shadow to produce a good outline -
just make four shadows, offset by 1px in each direction, and you're good.
It's been suggested that the spread argument from box-shadow be applied to
text-shadow. If
? If that's what you were responding to, then I think your response is
simply incorrect. There's nothing whatsoever that requires that a web
browser freeze up its UI while parsing a script. If it does so, it's a
quality of implementation issue, pure and simple.
You don't need to be more
Kyle Simpson get...@gmail.com schrieb am Tue, 8 Feb 2011 23:27:35
-0600:
I can't speak definitively as to how the JavaScript engine is
implemented (and if the code is significantly different between
mobile and desktop). But I can say that even if their code is
substantially the same, I could
On Tue, Feb 8, 2011 at 11:26 PM, Boris Zbarsky bzbar...@mit.edu wrote:
You don't need to be more efficient to avoid freezing the UI. You just
have to not do the parsing work in a single shot on the main thread. You can
either break it up (cooperative multitasking, effectively), or put it on a
I'm losing track in the noise of what the fundamental disagreements are--if
there even are any. I think the original proposal is a very good place to
start:
- Add a noexecute attribute to SCRIPT, which instructs the browser to
retrieve the script without executing it. noexecute implies async.
-
35 matches
Mail list logo
