Re: [whatwg] Javascript: URLs as element attributes
Apologies for not reading the whole thread before replying, but the design Darin describes below has worked well in WebKit thus far. I'd be hesitant to make JavaScript URLs work in more contexts due to the risk of introducing security vulnerabilities into the engine. Adam On Tue, Nov 30, 2010 at 11:37 AM, Darin Adler wrote: > In WebKit, we have treated the javascript URL scheme as a special case, with > explicit code in the loader, and not handled by general purpose resource > protocol machinery. Maciej Stachowiak suggested this approach, back in 2002, > and one of the reasons he gave me at the time is that thought WebKit would be > more likely to get the security policy right if code paths opted in to > JavaScript execution rather than opting out of javascript URL scheme handling. > > -- Darin > >
Re: [whatwg] Should script run if it comes from a HTML fragment?
> * innerHTML doesn't run scripts and they are inserted disabled. FWIW, here's a counter-example: http://www.oele.net/innerhtmljs2.html The above runs the script in all browsers except Firefox 4 (which follows the spec). The pattern is reportedly from the http://crossbrowserajax.com/ library. However, http://www.oele.net/innerhtmljs.html doesn't run in IE9 PP7. I'm not thrilled about adding code to support this quirky pattern at this point of the release cycle (evang is being attempted), but I thought I'd mention this finding even though I'm not asking for a spec change (at least not yet). -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] Javascript: URLs as element attributes
On 2/10/11 4:36 AM, Adam Barth wrote: Apologies for not reading the whole thread before replying, but the design Darin describes below has worked well in WebKit thus far. I'd be hesitant to make JavaScript URLs work in more contexts due to the risk of introducing security vulnerabilities into the engine. For what it's worth, Gecko treats javascript: URLs as a general protocol, but with tracking of where the URL came from required for the script to actually execute and explicit opt-in on the caller's part required to execute outside a sandbox. This too has worked well in terms of security, for what it's worth, while offering a lot more flexibility in terms of how and where javascript: URIs can work. I don't think we should gate the spec here on Webkit's implementation details if we think a certain behavior is correct but hard to support in Webkit -Boris
Re: [whatwg] Proposal for separating script downloads and execution
The reason for using readyState/onreadystatechange was to build on
kind-of-existing functionality rather that introducing something new. When
thinking through the problems, I was easily able to map this onto my main goals:
1) Determine if a script is downloaded successfully or not.
2) Determine if a script has already been executed.
I'm not suggesting this is the only possible implementation, just that it was
something familiar to developers already, and building on top of it may make
understanding the new functionality a bit easier.
And from earlier in the thread: I'd also be fine if this were a scripting-only
feature and wasn't used in markup. That was always a secondary use case in my
mind.
Glenn - thanks for steering the conversation back towards interfaces.
-N
-Original Message-
From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org]
On Behalf Of Glenn Maynard
Sent: Wednesday, February 09, 2011 7:43 PM
To: Kyle Simpson
Cc: whatwg@lists.whatwg.org
Subject: Re: [whatwg] Proposal for separating script downloads and execution
On Wed, Feb 9, 2011 at 10:06 AM, Kyle Simpson wrote:
> The original proposal is in fact more focused on the markup-driven use-case
> than on the script-driven use-case. The original proposer, Nicholas, agreed
> in an earlier message that he's really more concerned with script-driven
> functionality than markup driven functionality. And I completely agree with
> that assertion.
>
> In fact, I'd go so far as to say that the use-case for separating script
> loading from its parsing/execution phase (and thus being able to
> control/trigger when that phase occurs, later) is 99% driven by the
> script-loaders use-case. Script loaders by and large do not use markup
> semantics to accomplish their tasks (because most of them do not use
> document.write("
> So, if we consider the spirit of the original proposal, we should examine
> it in the proper context (the vast majority use-case), which is script
> elements being created from script logic rather than markup.
>
> Given that proper context, the proposal becomes something like:
>
> 1. Give a dynamic script element a "noExecute" property (a boolean
> property, defaults to false, can be set to true)
> 2. Give a dynamic script element an "execute()" function which executes a
> script that has been "deferred" by the "noExecute" property.
>
This is precisely what I described. (Obviously, the "noexecute" flag would
be exposed both as a DOM attribute and a script property.)
The problem with *that* phrasing of the proposal (compared to the
> "readyState" preoloading I'm advocating) is:
>
> 1. It asks for two new unprecedented additions to the script element
> specification. The other proposal asks to take the existing spec wording and
> change it from a "may" to a "must" (from suggestion to requirement).
>
It would take more than that. It wouldn't make sense to put a "must"
requirement for "must begin loading data when the src attribute is set, even
if the script element has not been added to the document" inside a list of
steps that only happens when the script has been added to the document.
It would also require adding readyState to the script element spec; it's
currently only defined for document and media. It would require specifying
onreadystatechange, which is only currently defined for document (and not
media, I believe). The "error" event would need to be updated to reflect
the fact that it can fire when the script element isn't in the DOM tree if
the fetch fails; I think IE's behavior of firing that event in this case is
currently off-spec.
I'm not against this approach fundamentally; I'm just pointing out that it's
not a one-word "s/may/must/" change. I do believe noexecute is cleaner and
more powerful: it allows executing a fetched script synchronously, which
would make using this transparently behind a black-box script API easier.
With readyState, if you call a function and it needs an interface that isn't
yet loaded, it needs to trigger execution (by adding the script to the
document) and return with "try again later", which is restrictive. I'd also
expect most of the engine work needed to support noexecute is already
implemented for defer (a question for implementors, of course).
In any case, I'm not too worried about either approach; my main goal was
getting back to discussing interfaces, since it seemed like most of the
debate was tangental--the main relevant point seems to be guaranteeing
browsers retain the freedom to parse scripts at whatever point they want
(during load, after load, during idle time, or upon execution), which I
think everyone is strongly agreed on.
--
Glenn Maynard
Re: [whatwg] Javascript: URLs as element attributes
On Thu, Feb 10, 2011 at 6:29 AM, Boris Zbarsky wrote: > On 2/10/11 4:36 AM, Adam Barth wrote: >> Apologies for not reading the whole thread before replying, but the >> design Darin describes below has worked well in WebKit thus far. I'd >> be hesitant to make JavaScript URLs work in more contexts due to the >> risk of introducing security vulnerabilities into the engine. > > For what it's worth, Gecko treats javascript: URLs as a general protocol, > but with tracking of where the URL came from required for the script to > actually execute and explicit opt-in on the caller's part required to > execute outside a sandbox. > > This too has worked well in terms of security, for what it's worth, while > offering a lot more flexibility in terms of how and where javascript: URIs > can work. > > I don't think we should gate the spec here on Webkit's implementation > details if we think a certain behavior is correct but hard to support in > Webkit The connection is that these features are unlikely to get implemented in WebKit anytime soon. To the extent that we want the spec to reflect interoperable behavior across browsers, speccing things that aren't (and aren't likely to become) interoperable is a net loss. Adam
Re: [whatwg] Javascript: URLs as element attributes
On 2/10/11 1:38 PM, Adam Barth wrote: The connection is that these features are unlikely to get implemented in WebKit anytime soon. To the extent that we want the spec to reflect interoperable behavior across browsers, speccing things that aren't (and aren't likely to become) interoperable is a net loss. That's fine; I just think that if you mean "Don't specify this because we don't want to implement it and will refuse to do so" you should just say that instead of making it sound like there are unspecified security issues with the proposal. -Boris
Re: [whatwg] Javascript: URLs as element attributes
On Thu, Feb 10, 2011 at 10:43 AM, Boris Zbarsky wrote: > On 2/10/11 1:38 PM, Adam Barth wrote: >> The connection is that these features are unlikely to get implemented >> in WebKit anytime soon. To the extent that we want the spec to >> reflect interoperable behavior across browsers, speccing things that >> aren't (and aren't likely to become) interoperable is a net loss. > > That's fine; I just think that if you mean "Don't specify this because we > don't want to implement it and will refuse to do so" you should just say > that instead of making it sound like there are unspecified security issues > with the proposal. To be clear, this is just my opinion. Rather than flatly refuse to implement the feature, I'm just sharing my perspective on why WebKit behaves the way it does today and how it's likely to behave in the future. If someone turned up tomorrow with a patch that re-architected how WebKit processes JavaScript URLs to make it possible, e.g., to use JavaScript URLs in the src attribute of an embed tag, I suspect there would be a lot of consternation within the project about whether the benefits of the patch outweighed the security risks. If you look back in the bug tracker, you'll see that I tried doing something along those lines (albeit on a more moderate scale) a while back. The result was roughly as I've described: we decided not to accept the patches because of their security risk. IMHO, data URLs cover these use cases much better than JavaScript URLs. The benefits of implementing JavaScript URLs are mostly to be compatible with web sites that rely upon them. Adam
Re: [whatwg] Proposal for separating script downloads and execution
* Kyle Simpson wrote:
>For the purposes of this discussion, we are combining (but safely so, I
>believe) "execution" and "parsing", and saying that we want to be able to
>defer the "parse/execution" phase of script loading. The reason it's
>necessary to draw the distinction (and point out that parsing is the costly
>bit) is to defuse the argument that the script author can simply change the
>script to not execute itself until manually invoked at a later time.
There are multiple phases between receiving bytes on the wire and having
executed the code they represent. Parsing would seem unlikely to be the
main problem here (parsing is mainly checking for syntax errors while or
after removing the character encoding from the bytes received), while it
is quite likely that browsers don't have very fast parsers, without very
good benchmarks I would rather suspect the problem is more in finding
out about the side effects of the code and eagerly pre-processing code
like turning it into machine code and the things that entails like gc
runs. There would seem to be no reason why a lazier evaluation strategy
would be an appreciable performance hit. You would couple those mainly
because decoupling them in implementations so you actually gain much is
hard.
Anyway, I don't really see the problem with rewriting your code so you
have more control over when execution takes place, for instance, you can
just do `function load() { eval("...") }` and similar mechanisms. That
would in fact seem wiser as browsers would have a better chance to spe-
culatively pre-parse the constant you want evaluated than doing that for
some code that has been commented out. That would of course require you
to change code, and related mechanisms would have other downsides, like
they would not degrade as gracefully or not work across origins in all
browsers, and so on. You might even make the argument that the proposal
here seems like a cheap enough hack that might get traction quickly.
On the other hand, dynamically loading code by fiddling script elements
into documents is rather ... inelegant. A more viable long term solution
would be a proper native script loading programming interface. But it's
only been 15 years since people pointed out that's necessary, let's not
be hasty when it comes to essential low-level features.
--
Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: [whatwg] Proposal for separating script downloads and execution
On 2/10/11 3:23 PM, Bjoern Hoehrmann wrote:
There are multiple phases between receiving bytes on the wire and having
executed the code they represent. Parsing would seem unlikely to be the
main problem here (parsing is mainly checking for syntax errors while or
after removing the character encoding from the bytes received)
And constructing whatever output model (AST, bytecode, whatever) your
parser produces.
while it is quite likely that browsers don't have very fast parsers, without
very
good benchmarks I would rather suspect the problem is more in finding
out about the side effects of the code and eagerly pre-processing code
like turning it into machine code
Browsers don't do much stuff eagerly in this space.
Based on my profiles of script loading and execution in Spidermonkey,
parsing _is_ in fact pretty expensive (very commonly much more expensive
than the initial execution for large scripts, since most of the script
is cold).
That said, Spidermonkey's parser does in fact do some optimization
(constant-folding and the like). But it also ends up having to create
large data structures, read a bunch of data, sometimes ends up running
O(N^2) algorithms, etc, etc.
If you have actual data, not just conjecture, as to the amount of time
the parser takes in other ECMAScript implementations, which I have not
profiled, I would love to see that data.
Anyway, I don't really see the problem with rewriting your code so you
have more control over when execution takes place, for instance, you can
just do `function load() { eval("...") }` and similar mechanisms.
Because that makes your code much slower in some cases?
-Boris
Re: [whatwg] Proposal for separating script downloads and execution
For the purposes of this discussion, we are combining (but safely so, I believe) "execution" and "parsing", and saying that we want to be able to defer the "parse/execution" phase of script loading. The reason it's necessary to draw the distinction (and point out that parsing is the costly bit) is to defuse the argument that the script author can simply change the script to not execute itself until manually invoked at a later time. There are multiple phases between receiving bytes on the wire and having executed the code they represent. Parsing would seem unlikely to be the main problem here (parsing is mainly checking for syntax errors while or after removing the character encoding from the bytes received), The Gmail mobile team did extensive research into this area and concluded that it was in fact the parsing that was the big slow-down in their case. From what I recall, they have a big file with nothing but function declarations in it (NO EXECUTIONS), and that file took a few seconds to "execute" (not actually execute any functions, but parse and declare those functions into the global space). On the other hand, if they wrapped all the code in /* .. */ comments, and had that single big comment "parsed/executed" by the engine, it went orders of magnitude faster (unsurprisingly). So, it strongly suggests that the parsing/interpretation of the code was in fact the culprit. There's nothing they could have really done to prevent less execution, since they weren't executing anything. It was merely the sheer number of function declarations being parsed and added to the environment that slowed everything down. There's already in thread sufficient confusion over what "execute" means. In the literal sense as far as the JavaScript engine is concerned, we probably ARE talking about wanting to defer when the code itself (the function declarations) is "executed". But we need to differentiate *that* "execution" (which is the problem) from later "execution" (which isn't the problem) with actual function call invocations. For the sake of this discussion here, I've been referring to the first "execution" as "parsing" and the second "execution" as "execution". I don't want us to derail this thread AGAIN with semantics arguments about what is and is not "parsing" or "execution", and whether the problem is "parsing" or "interpretation", or whatever you want to call that first pass where JavaScript code is run through the engine, even if no function calls were happening. The real point is, THAT part (whatever it's called) is clearly what is so slow, and THAT part is what we're seeking to have control to defer. And THAT part won't benefit at all from telling a developer "just redesign your code". Anyway, I don't really see the problem with rewriting your code so you have more control over when execution takes place, Again, this is exactly the line of degenerative conversation that I was trying to preempt from happening. You're assuming (wrongly) that the code is unnecessarily "executing" function calls at the time of inclusion, when in reality it's not, and so that's not the problem. It's not a question of if I can change code from automatically invoking a function to controlling that function call myself. It's a question of if I have any way to defer when the browser interprets a huge chunk of function declarations present in my source code. And the answer is, currently, I can't defer that step, whatever we call that step. --Kyle
Re: [whatwg] Proposal for separating script downloads and execution
On Thu, Feb 10, 2011 at 12:53 PM, Kyle Simpson wrote:
>>> For the purposes of this discussion, we are combining (but safely so, I
>>> believe) "execution" and "parsing", and saying that we want to be able to
>>> defer the "parse/execution" phase of script loading. The reason it's
>>> necessary to draw the distinction (and point out that parsing is the
>>> costly
>>> bit) is to defuse the argument that the script author can simply change
>>> the
>>> script to not execute itself until manually invoked at a later time.
>>
>> There are multiple phases between receiving bytes on the wire and having
>> executed the code they represent. Parsing would seem unlikely to be the
>> main problem here (parsing is mainly checking for syntax errors while or
>> after removing the character encoding from the bytes received),
>
> The Gmail mobile team did extensive research into this area and concluded
> that it was in fact the parsing that was the big slow-down in their case.
> From what I recall, they have a big file with nothing but function
> declarations in it (NO EXECUTIONS), and that file took a few seconds to
> "execute" (not actually execute any functions, but parse and declare those
> functions into the global space). On the other hand, if they wrapped all the
> code in /* .. */ comments, and had that single big comment "parsed/executed"
> by the engine, it went orders of magnitude faster (unsurprisingly).
>
> So, it strongly suggests that the parsing/interpretation of the code was in
> fact the culprit. There's nothing they could have really done to prevent
> less execution, since they weren't executing anything. It was merely the
> sheer number of function declarations being parsed and added to the
> environment that slowed everything down.
Nope, execution is the culprit here, as function declarations are
actually executed code. Saying "function foo() { bar(); }" is the
same as saying "window.foo = function(){ bar(); };" (module a few
irrelevant details). The act of defining functions requires executing
functions (hidden behind the syntax of an operator, but still).
Solving this does require deferring execution entirely, like the GMail
Mobile team was able to do with the comment hack.
~TJ
Re: [whatwg] Removal of blocking script
On Thu, 10 Feb 2011, Juriy Zaytsev wrote: > On Wed, Feb 9, 2011 at 7:49 PM, Ian Hickson wrote: > > On Mon, 15 Nov 2010, Juriy Zaytsev wrote: > > > > > > When removing [1] a long-loading script element from a document, > > > browsers seem to disagree on whether such removal should affect page > > > rendering. A simple test � > > > http://kangax.github.com/jstests/blocking_script_removal_test/� > > > shows that Opera (9.x - 11) and IE (5.5 - 9) immediately continue > > > parsing the document upon element removal. However, in Firefox (3-4) > > > and Chrome (9) the document parsing is blocked until script is > > > loaded or times out (even when the actual element no longer exists > > > in the document, has its "src" reference an empty string, and there > > > exist no references to it). > > > > > > Does current draft explain what should happen in such case, and if > > > it does � what is it (I can't seem to find it)? The existing > > > discrepancy suggests that it's something worth codifying. > > > > > > [1] Where "removing" is done through scripting (say, via Node's > > > `removeChild` or analogous method). > > > > The spec currently implies that the page should block for the full > > second, > > Full second as in 1 second? Strange requirement. I mean it should block for however long the script takes to be downloaded. > Could you please point me to where exactly it's in the spec? Look up "pending parsing-blocking script" and follow the references from there (click on the term in the single-page copy of the spec to get the various places it is referenced). HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal for separating script downloads and execution
On Thu, 10 Feb 2011 21:02:43 -, Tab Atkins Jr.
wrote:
Nope, execution is the culprit here, as function declarations are
actually executed code. Saying "function foo() { bar(); }" is the
same as saying "window.foo = function(){ bar(); };" (module a few
irrelevant details). The act of defining functions requires executing
functions (hidden behind the syntax of an operator, but still).
Solving this does require deferring execution entirely, like the GMail
Mobile team was able to do with the comment hack.
Are you sure about this? As far as I understand it, execution of:
window.foo = function(){ /* nothing */ }
and
window.foo = function(){ crazy(); amount(); of(); code(); }
is basically the same — just linking of function expression to global
scope (so that referenced globals can be found *later* when function body
is executed) and assignment of Function object to window.foo.
So once script is parsed, I assume that definition of a huge function
should not be any slower than definition of an empty function.
--
regards, Kornel
Re: [whatwg] Proposal for separating script downloads and execution
* Boris Zbarsky wrote: >On 2/10/11 3:23 PM, Bjoern Hoehrmann wrote: >> There are multiple phases between receiving bytes on the wire and having >> executed the code they represent. Parsing would seem unlikely to be the >> main problem here (parsing is mainly checking for syntax errors while or >> after removing the character encoding from the bytes received) > >And constructing whatever output model (AST, bytecode, whatever) your >parser produces. I can grant you persisting information about the structure to some point but generating byte code is not the job of the parser, that's what code generators are for. It's not uncommon however to persist only minimal information and extract structure only as needed. Perl's URI parser for instance does that which is a sound optimization there. >Based on my profiles of script loading and execution in Spidermonkey, >parsing _is_ in fact pretty expensive (very commonly much more expensive >than the initial execution for large scripts, since most of the script >is cold). Yes, but it's a long way from there to saying that "parsing" must be a- voided because parsing is inherently slow. As it becomes more common to load very large libraries where you don't actually use most things, or use them only much later, it may also be that your "parser" simply does too much work up-front. I have no idea, I just don't think saying we should not look at individual factors in finding a proper optimization is the best approach. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: [whatwg] Proposal for separating script downloads and execution
On Thu, Feb 10, 2011 at 5:09 PM, Bjoern Hoehrmann wrote: > Yes, but it's a long way from there to saying that "parsing" must be a- > voided because parsing is inherently slow. As it becomes more common to > load very large libraries where you don't actually use most things, or > use them only much later, it may also be that your "parser" simply does > too much work up-front. I have no idea, I just don't think saying we > should not look at individual factors in finding a proper optimization > is the best approach. This is all arguing about semantics. The point is the current mechanisms for handling scripts are insufficient, and on mobile phones in particular the process of reading the contents of a script tag (whether you call that parsing, executing definitions, or whatever), is way too slow and interrupts the UI. This problem has driven crude hacks like the comment hack, which in fact precludes the browsers every getting smarter about doing the parsing/etc in the background or during idle time. This proposal is about a way to hint to the browser that only the download part should happen now, and the parsing/execution of the downloaded script will happen later, which in fact enables smarter browsers to make smarter decisions. -- John A. Tamplin Software Engineer (GWT), Google
Re: [whatwg] Proposal for separating script downloads and execution
On Wed, Feb 9, 2011 at 10:06 AM, Kyle Simpson wrote: > readyState There's one other fundamental limitation of the readyState approach which I forgot about: it's impossible to defer execution of inline scripts. It inherently only works for external scripts.
Re: [whatwg] Proposal for separating script downloads and execution
Testing this shows that IE9 doesn't fire a progress event for the transition that is of interest for the use case. That is, when the script transitions to "loaded", there's no event. Once the script has been evaluated, there is a (rather useless) progress event for the transition to "complete". The interesting transition to "loaded" can only be observed by polling. Sigh. :-( Demo: http://hsivonen.iki.fi/test/moz/script-readystate.html You're correct about this not working in IE9b. But it would seem that it's a regression, as I just checked in IE6-8, and it does indeed fire the `onreadystatechange` event on the "loaded" state. I'm going to file a bug in the IE9 feedback system to ask them to address that regression. Here's my test: http://test.getify.com/ie-script-readystate/ UPDATE: IE9 RC1 came out today, and this regression is fixed. `readyState=loaded` does fire the `onreadystatechange` handler as expected. Good news for the support of `readyState` proposal, I think. *HOWEVER*, in IE6-8 (and I would assume IE9 once they address that regression), there's still a wrinkle with being able to rely on the "loaded" readyState event. If the script is already in the cache, it appears that IE does *not* fire the "loaded" readyState event. Obviously, this is quite unfortunate, since it means that polling would still be a necessary piece of the puzzle for IE. Turns out I was completely wrong on this. `readyState=loaded` fires fine with cached items. My test code has a race-condition in it that was masking the correct behavior. So, at this point, I can verify (at least in my tests), that `readyState` works fine (without polling) in at least IE6-IE9. This means polling is not necessary to support that functionality in IE. Good news on both fronts. --Kyle
Re: [whatwg] Proposal for separating script downloads and execution
* John Tamplin wrote: >This is all arguing about semantics. The point is the current mechanisms >for handling scripts are insufficient, and on mobile phones in particular >the process of reading the contents of a script tag (whether you call that >parsing, executing definitions, or whatever), is way too slow and interrupts >the UI. This problem has driven crude hacks like the comment hack, which in >fact precludes the browsers every getting smarter about doing the >parsing/etc in the background or during idle time. This proposal is about a >way to hint to the browser that only the download part should happen now, >and the parsing/execution of the downloaded script will happen later, which >in fact enables smarter browsers to make smarter decisions. The proposal is an optimization of these crude hacks. Authors using such hacks are unlikely to stop using them because the optimization does not work on deployed clients. New clients supporting it are likely to have better JavaScript parsers as people make new benchmarks taking parsing more into account than they have so far and because improvements there help with all web sites, so as we apparently don't know very well where the performance issues here lie and how the various hacks compare, we do not know much about how much of a difference the proposal would make. What will happen is that people using the proposed feature will intro- duce subtle bugs in their code (like calling .execute() in some place but not in another which works 99% of the time on the test systems but fails on other systems due to, say, differences in how they schedule re- source loads), and for others using "noexecute" may be beneficial now, but may not be beneficial with the next browser generation, which may result in browser vendors changing their optimization logic, which then causes more breakage and might be more complex. And there is a toll on everyone since in trying to optimize they would have to try yet another thing that might help. The terminology is not all that important, but some analyis beyond the simple "
Re: [whatwg] Proposal for separating script downloads and execution
On Thu, Feb 10, 2011 at 7:39 PM, Bjoern Hoehrmann wrote: > While I am sure that people here have done far more extensive research > than what we've heard so far, this is Ian Hickson's mailing list and as > I recall, he puts great emphasis on research and the proceedings being > available to the general public, and so far I've not seen much beyond > some blog posting with one test on hard- and software that will be four > years old when the proposed feature becomes anything resembling main- > stream, plus some individual findings, and that's not very impressive. I await your experimental findings. Forgive me for bringing up actual deployed procedures to combat actual user-visible problems on real devices. -- John A. Tamplin Software Engineer (GWT), Google
Re: [whatwg] Canvas feedback (various threads)
On Thu, 3 Feb 2011, Boris Zbarsky wrote: > > It looks like CSS rgba colors with an alpha value of 0 are serialized as > rgba() with "0" as the alpha value. in at least Gecko, Webkit, and > Presto. > > It also looks like canvas style color with an alpha value of 0 are > serialized as rgba() with "0.0" as the alpha value in Gecko 3.6, Webkit, > and Presto. > > In Gecko 2.0 we made a change to the canvas code to fix some bugs in the > serialization by the simple expedient of reusing the well-tested code > that CSS colors use. This has the incidental benefit of more behavior > consistency for authors. Unfortunately, this makes us not do what these > other UAs do, nor do what the current spec draft says. > > While we can clearly special-case 0 in this code, it seems like an > authoring pitfall to have the two different serialization styles, so I > would prefer to have consistent behavior between the two. What do other > UA vendors think of standardizing on "0" as the serialization for canvas > color alpha channels when they're transparent? Alternately, what about > using "0.0" for CSS colors? On Fri, 4 Feb 2011, Anne van Kesteren wrote: > > Either way is fine. Note however that when there is no alpha-channel > involved the differences are much greater between CSS and . At > least in Gecko/WebKit. I.e. rgb() vs #rrggbb. That probably cannot be > changed though. Given Anne's point (that this is already different in other contexts), and given the current deployed interop on this issue, I'm reluctant to change this. I agree that it's unfortunate that we needlessly differ from CSS here. It's another example of why it's important for us to define everything, and that we never leave anything up to UAs to decide. :-) On Mon, 17 Jan 2011, carol.sz...@nokia.com wrote: > > I propose changing the drawing model steps 2 to 5 the following way: > > Step 2: Multiply the alpha channel of every pixel in A by globalAlpha. > (Prior Step 5) > > Step 3: When shadows are drawn, render the shadow from image A, using > the current shadow styles, creating image B. > > Step 4: When shadows are drawn, composite image B onto image A using > destination-over compositing operation. > > This algorithm is less expensive then the prior one (it saves one > multiplication of the AlphaChannel over the entire B bitmap), and treats > the image/object drawn and its shadow as one entity. Which results in > the shadow being preserved for composite operations such as copy and > source-in and produces less strange results in operations such as xor > and destination-out when shadows are drawn. > > The this algorithm yields the same result as the current version of the > spec for source-over, but for completeness supports shadows in all > modes. Indeed the way the current spec exists, many non-source-over > modes including xor yield very strange results if shadows are used. I do > not care that much if the spec has my proposal in it or whether it specs > that shadows are not rendered in modes other then source over, but it > would be nice to hear an agreement from browser implementors on this. On Tue, 18 Jan 2011, Robert O'Callahan wrote: > > [...] if we don't have good use cases for using shadows with > non-"source-over" operators (I don't), let's just say that shadows don't > draw for non-"source-over" operators. That would reduce spec and > implementation complexity. I'm happy to do either of these, but I'm very relunctant to change the spec away from what browsers do. Currently, browsers pretty much agree on how shadows work in composition, they just disagree over what gets composited (and even then it's only really WebKit that disagrees). If there is interest in changing this, I think the best thing would be for browser vendors to indicate a commitment to change it, so that I can make sure I'm not changing the spec away from what browsers want to implement. On Tue, 23 Nov 2010, Tab Atkins Jr. wrote: > > Right now, canvas gradients interpolate their colors in > non-premultiplied space; that is, the raw values of r, g, b, and a are > interpolated independently. This has the unfortunate effect that colors > darken as they transition to transparent, as "transparent" is defined as > "rgba(0,0,0,0)", a transparent black. Under this scheme, the color > halfway between "yellow" and "transparent" is "rgba(127,127,0,.5)", a > partially-transparent dark yellow, rather than "rgba(255,255,0,.5)".* > > The rest of the platform has switched to using premultiplied colors for > interpolation, because they react better in cases like this**. CSS > transitions and CSS gradients now explicitly use premultiplied colors, > and SVG ends up interpolating similarly (they don't quite have the same > problem - they track opacity separate from color, so transitioning from > "color:yellow;opacity:1" to "color:yellow;opacity:0" gives you > "color:yellow;opacity:.5" in the middle, which is the moral equiv
Re: [whatwg] Canvas feedback (various threads)
On Thu, Feb 10, 2011 at 4:56 PM, Ian Hickson wrote: > Looking at that demo, it seems that premultiplied removes possible options > from the author. How do you go from red to actually transparent black, > getting darker as you transition? Do you have to give a nearly-transparent > black (alpha=0.01) to get around it or some such? That seems weird. If you want to mimic the appearance of red->transparent black in non-premultiplied space, then yes, you need to put in several additional color-stops. In premultiplied space, that transition is a curved path. >> It's not only the 'transparent' keyword; it affects all cases of >> gradients between colors with different alpha values and different color >> values. And in cases where one of the endpoint alphas is not 0, it's >> not possible to get the correct (premultiplied) result with a gradient >> computed in nonpremultiplied space. > > Can you elaborate on that? I'm interested in seeing the cases that you > can't do in one or the other of the colour spaces we're discussing. If one > is a strict superset of the other, then it would make sense to specify > that we use that one. If you can do the same gradients in both, then > interoperability seems more important. The two color-spaces are equivalent in terms of colors and gradients than can be expressed, though the ease of expressing certain gradients are different between them. CSS does transitions in premultiplied space, and both FF and Webkit are planning to do CSS gradients in premultiplied space as well (the spec already requires it). It would be unfortunate to have work differently than CSS here. > The canvas gradient spec is pretty uniformly and interoperably implemented > on this front: > > > http://software.hixie.ch/utilities/js/canvas/?c.clearRect(0%2C%200%2C%20640%2C%20480)%3B%0Ac.save()%3B%0Avar%20gradient%20%3D%20c.createLinearGradient(0%2C0%2C640%2C480)%3B%0Agradient.addColorStop(0%2C%20'rgba(255%2C255%2C255%2C1)')%3B%0Agradient.addColorStop(1%2C%20'rgba(0%2C0%2C0%2C0)')%3B%0Ac.fillStyle%20%3D%20gradient%3B%0Ac.fillRect(0%2C0%2C640%2C480)%3B%0Ac.restore()%3B%0A > > It's easy to work around this issue: > > > http://software.hixie.ch/utilities/js/canvas/?c.clearRect(0%2C%200%2C%20640%2C%20480)%3B%0Ac.save()%3B%0Avar%20gradient%20%3D%20c.createLinearGradient(0%2C0%2C640%2C480)%3B%0Agradient.addColorStop(0%2C%20'rgba(255%2C255%2C255%2C1)')%3B%0Agradient.addColorStop(1%2C%20'rgba(255%2C255%2C255%2C0)')%3B%0Ac.fillStyle%20%3D%20gradient%3B%0Ac.fillRect(0%2C0%2C640%2C480)%3B%0Ac.restore()%3B%0A > > I'm happy to change the spec on this, but I'm not going to change it ahead > of the implementations. If you want this changed, I recommend getting the > browser vendors to change this. Ok. ~TJ
Re: [whatwg] Proposal for separating script downloads and execution
The proposal is an optimization of these crude hacks. Authors using such hacks are unlikely to stop using them because the optimization does not work on deployed clients. What will happen is that people using the proposed feature will intro- duce subtle bugs in their code (like calling .execute() in some place but not in another which works 99% of the time on the test systems but First of all, you're making quite a few assumptions which YOU have no proof of. The people who are vocal on here asking for this feature are responsible, seasoned developers, who've been in the trenches of JavaScript and web development for many years. We're also authors and maintainers of publicly consumed and widely used tools (script loaders, etc), and we know exactly how to responsibly use the feature we are asking for. I can't speak to if other devs will possibly do it wrong, but there's PLENTY in both HTML and in JavaScript specs which can (and is, regularly) abused by ignorant developers. That something *can* be abused is not proof it will be, nor is it a reason to deny it from the people who clearly know how to use it correctly. Secondly, and more importantly, as I've said several times already in this thread... **THIS IS NOT JUST ABOUT THE MOBILE PERFORMANCE** I'm not sure why some people in this thread insist on focusing on arguing that point (ad nauseum) to the exclusion of the other parts of the conversation. Combine that with the others who want to play semantics games over what we call something, and the bikeshedding is getting out of hand. Talking about how deferring a script's "execution" can help mobile performance seemed like a simple way to illustrate a usage of the feature being requested, especially since there was hard evidence and established research done by a pretty well known/respected/intelligent group -- the Gmail Mobile team. If we were to completely throw out the mobile performance use-case, and ONLY consider the others (of which I've documented several), could we get this conversation back on track instead of these side paths of argument over issues which don't really matter to the overall validity of the request/proposal? Even if the mobile performance use-case were thrown out, I'd still be advocating for the other use-cases and requesting this functionality as a result. I think I can safely speak for Nicholas and Steve in my assertions that there are other valid reasons this functionality is important besides just deferring execution to avoid CPU-bottlenecking on mobile. --Kyle
Re: [whatwg] Proposal for separating script downloads and execution
On 2/10/11 5:09 PM, Bjoern Hoehrmann wrote: And constructing whatever output model (AST, bytecode, whatever) your parser produces. I can grant you persisting information about the structure to some point but generating byte code is not the job of the parser Well, the parser has to output _some_ representation. In the case of Spidermonkey, the parser outputs bytecode directly. In the case of V8 it outputs an AST. Constructing those takes time. Yes, but it's a long way from there to saying that "parsing" must be a- voided because parsing is inherently slow. As it becomes more common to load very large libraries where you don't actually use most things, or use them only much later, it may also be that your "parser" simply does too much work up-front. I have no idea, I just don't think saying we should not look at individual factors in finding a proper optimization is the best approach. Oh, I agree that we shouldn't take current browser JS parser behavior as set in stone. -Boris
Re: [whatwg] Proposal for separating script downloads and execution
On 2/10/11 10:32 PM, timeless wrote:
i believe the only requirements for:
function x(){}
function y(){}
are:
1. if x fails to compile, y is not evaluated
2. y can fail to compile too
3. if something fails to compile, window.onerror is triggered
4. if x could compile, then window.x is defined to be a Function object
I don't think so. If there is any parse or compilation or whatever you
want to call it error, the script is never executed, so window.x is
never defined.
Also, I would fully expect it to be a web compat requirement that
window.onerror not be triggered until the script would be evaluated. If
you parse/compile/whatever before that and hit an error, you'd need to
save that and report it at the "right" time.
Which means the that parse/compile/whatever process is currently not
observable directly. And that's a good thing!
in theory, i believe a js engine could choose to discard all work it
has done to validate syntax for x+y beyond saving those coordinates,
and then either do the proper ast / bytecode / machine code generation
lazily (or schedule to do it on a thread).
Sure; a js engine could also not do any syntax validation at all, until
it needs to run the script...
-Boris
Re: [whatwg] Canvas feedback (various threads)
On 2/10/11 7:56 PM, Ian Hickson wrote: On Thu, 3 Feb 2011, Boris Zbarsky wrote: It looks like CSS rgba colors with an alpha value of 0 are serialized as rgba() with "0" as the alpha value. in at least Gecko, Webkit, and Presto. It also looks like canvas style color with an alpha value of 0 are serialized as rgba() with "0.0" as the alpha value in Gecko 3.6, Webkit, and Presto. I have to correct myself. The above is the behavior in _Chrome_, not in all Webkit-based browsers. In Safari, canvas style colors are serialized as the original string they were set to, apparently (so if you set it to 0.0 you get 0.0 back; if you set it to 0 you get 0 back, and if you set "interoperability" you get "interoperability" back...). An additional data point is that in the IE9 RC you get 0, just like in Firefox 4. Given Anne's point (that this is already different in other contexts), and given the current deployed interop on this issue Which is less interop than it seems (due to Safari's behavior), and about to disappear completely, since both IE9 and Firefox 4 will ship with the 0 instead of 0.0 :( It's another example of why it's important for us to define everything, and that we never leave anything up to UAs to decide. :-) Preaching to the choir, eh. ;) -Boris
Re: [whatwg] Canvas feedback (various threads)
On Thu, 10 Feb 2011, Boris Zbarsky wrote: > On 2/10/11 7:56 PM, Ian Hickson wrote: > > On Thu, 3 Feb 2011, Boris Zbarsky wrote: > > > > > > It looks like CSS rgba colors with an alpha value of 0 are serialized as > > > rgba() with "0" as the alpha value. in at least Gecko, Webkit, and > > > Presto. > > > > > > It also looks like canvas style color with an alpha value of 0 are > > > serialized as rgba() with "0.0" as the alpha value in Gecko 3.6, Webkit, > > > and Presto. > > I have to correct myself. The above is the behavior in _Chrome_, not in > all Webkit-based browsers. In Safari, canvas style colors are > serialized as the original string they were set to, apparently (so if > you set it to 0.0 you get 0.0 back; if you set it to 0 you get 0 back, > and if you set "interoperability" you get "interoperability" back...). I think you had a typo in your test. As far as I can tell, all WebKit-based browsers act the same as Opera and Firefox 3 on this: http://software.hixie.ch/utilities/js/canvas/?c.clearRect(0%2C%200%2C%20640%2C%20480)%3B%0Ac.save()%3B%0Atry%20%7B%0A%20%20c.strokeStyle%20%3D%20'red'%3B%0A%20%20c.fillText(c.strokeStyle%2C%2020%2C%2080)%3B%0A%20%20c.strokeStyle%20%3D%20'transparent'%3B%0A%20%20c.fillText(c.strokeStyle%2C%2020%2C%20120)%3B%0A%7D%20finally%20%7B%0A%20%20c.restore()%3B%0A%7D%0A > An additional data point is that in the IE9 RC you get 0, just like in > Firefox 4. Good to know. > Which is less interop than it seems (due to Safari's behavior), and > about to disappear completely, since both IE9 and Firefox 4 will ship > with the 0 instead of 0.0 :( Is there no chance to fix this in Firefox 4? It _is_ a regression. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal for separating script downloads and execution
On Fri, Feb 11, 2011 at 5:51 AM, Boris Zbarsky wrote: > I don't think so. If there is any parse or compilation or whatever you want > to call it error, the script is never executed, so window.x is never > defined. oops, right, but i don't know that that complicates things much. you just store a list of variables to pollute window with when should be applied or the error to send to window.onerror at time. > Also, I would fully expect it to be a web compat requirement that > window.onerror not be triggered until the script would be evaluated. If you > parse/compile/whatever before that and hit an error, you'd need to save that > and report it at the "right" time. sure, but that's one error to store with a pending
Re: [whatwg] Canvas feedback (various threads)
On 2/10/11 11:31 PM, Ian Hickson wrote: I think you had a typo in your test. As far as I can tell, all WebKit-based browsers act the same as Opera and Firefox 3 on this: http://software.hixie.ch/utilities/js/canvas/?c.clearRect(0%2C%200%2C%20640%2C%20480)%3B%0Ac.save()%3B%0Atry%20%7B%0A%20%20c.strokeStyle%20%3D%20'red'%3B%0A%20%20c.fillText(c.strokeStyle%2C%2020%2C%2080)%3B%0A%20%20c.strokeStyle%20%3D%20'transparent'%3B%0A%20%20c.fillText(c.strokeStyle%2C%2020%2C%20120)%3B%0A%7D%20finally%20%7B%0A%20%20c.restore()%3B%0A%7D%0A On that test, Safari 5.0.3 on Mac outputs "red" and "transparent" for the two strings. And this test: http://software.hixie.ch/utilities/js/canvas/?c.clearRect(0%2C%200%2C%20640%2C%20480)%3B%0Ac.save()%3B%0Atry%20%7B%0A%20%20c.strokeStyle%20%3D%20'red'%3B%0A%20%20c.fillText(c.strokeStyle%2C%2020%2C%2080)%3B%0A%20%20c.strokeStyle%20%3D%20'orly%2C%20do%20you%20think%20so'%3B%0A%20%20c.fillText(c.strokeStyle%2C%2020%2C%20120)%3B%0A%7D%20finally%20%7B%0A%20%20c.restore()%3B%0A%7D%0A outputs "red" and "orly, do you think so" in the same browser. Does Safari on Mac behave differently from Safari on Windows here? Which is less interop than it seems (due to Safari's behavior), and about to disappear completely, since both IE9 and Firefox 4 will ship with the 0 instead of 0.0 :( Is there no chance to fix this in Firefox 4? It _is_ a regression. :-) At this point, probably not. If it's not actively breaking websites it's not being changed before final release. If it is, we'd at least think about it... -Boris
Re: [whatwg] Canvas feedback (various threads)
On Thu, Feb 10, 2011 at 8:39 PM, Boris Zbarsky wrote: > On 2/10/11 11:31 PM, Ian Hickson wrote: > >> I think you had a typo in your test. As far as I can tell, all >> WebKit-based browsers act the same as Opera and Firefox 3 on this: >> >> >> http://software.hixie.ch/utilities/js/canvas/?c.clearRect(0%2C%200%2C%20640%2C%20480)%3B%0Ac.save()%3B%0Atry%20%7B%0A%20%20c.strokeStyle%20%3D%20'red'%3B%0A%20%20c.fillText(c.strokeStyle%2C%2020%2C%2080)%3B%0A%20%20c.strokeStyle%20%3D%20'transparent'%3B%0A%20%20c.fillText(c.strokeStyle%2C%2020%2C%20120)%3B%0A%7D%20finally%20%7B%0A%20%20c.restore()%3B%0A%7D%0A >> > > On that test, Safari 5.0.3 on Mac outputs "red" and "transparent" for the > two strings. > > And this test: > http://software.hixie.ch/utilities/js/canvas/?c.clearRect(0%2C%200%2C%20640%2C%20480)%3B%0Ac.save()%3B%0Atry%20%7B%0A%20%20c.strokeStyle%20%3D%20'red'%3B%0A%20%20c.fillText(c.strokeStyle%2C%2020%2C%2080)%3B%0A%20%20c.strokeStyle%20%3D%20'orly%2C%20do%20you%20think%20so'%3B%0A%20%20c.fillText(c.strokeStyle%2C%2020%2C%20120)%3B%0A%7D%20finally%20%7B%0A%20%20c.restore()%3B%0A%7D%0A > > outputs "red" and "orly, do you think so" in the same browser. > > Does Safari on Mac behave differently from Safari on Windows here? The version of WebKit used by Safari 5.0.3 is rather antiquated at this point. Using the latest WebKit nightly build, or Chrome 10.0.648.45 dev (which has a significantly newer version of WebKit), I get #ff and rgba(0, 0, 0, 0.0) on the first test and #ff / #ff on the second. Presumably at some point Apple will release a new version of Safari that matches the behavior nightlies currently have. - James > > > Which is less interop than it seems (due to Safari's behavior), and >>> about to disappear completely, since both IE9 and Firefox 4 will ship >>> with the 0 instead of 0.0 :( >>> >> >> Is there no chance to fix this in Firefox 4? It _is_ a regression. :-) >> > > At this point, probably not. If it's not actively breaking websites it's > not being changed before final release. If it is, we'd at least think about > it... > > -Boris >
Re: [whatwg] Canvas feedback (various threads)
On 2/10/11 11:54 PM, James Robinson wrote: The version of WebKit used by Safari 5.0.3 is rather antiquated at this point. Using the latest WebKit nightly build, or Chrome 10.0.648.45 dev (which has a significantly newer version of WebKit), I get #ff and rgba(0, 0, 0, 0.0) on the first test and #ff / #ff on the second. Presumably at some point Apple will release a new version of Safari that matches the behavior nightlies currently have. Ah, I see. My point stands: interoperability among UAs that users are using right now (which doesn't include webkit nightlies, but does include Chrome 9 which seems to have the new behavior) is just not there. -Boris
