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
* 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.
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
On Thu, Feb 10, 2011 at 6:29 AM, Boris Zbarsky bzbar...@mit.edu 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
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
On Thu, Feb 10, 2011 at 10:43 AM, Boris Zbarsky bzbar...@mit.edu 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,
* 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
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
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
On Thu, Feb 10, 2011 at 12:53 PM, Kyle Simpson get...@gmail.com 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
On Thu, 10 Feb 2011, Juriy Zaytsev wrote:
On Wed, Feb 9, 2011 at 7:49 PM, Ian Hickson i...@hixie.ch 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
On Thu, 10 Feb 2011 21:02:43 -, Tab Atkins Jr. jackalm...@gmail.com
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
* 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
On Thu, Feb 10, 2011 at 5:09 PM, Bjoern Hoehrmann derhoe...@gmx.net 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
On Wed, Feb 9, 2011 at 10:06 AM, Kyle Simpson get...@gmail.com 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. script noexecute can
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
* 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
On Thu, Feb 10, 2011 at 7:39 PM, Bjoern Hoehrmann derhoe...@gmx.net 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
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
On Thu, Feb 10, 2011 at 4:56 PM, Ian Hickson i...@hixie.ch 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
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
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
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
On Fri, Feb 11, 2011 at 5:51 AM, Boris Zbarsky bzbar...@mit.edu 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
On Thu, Feb 10, 2011 at 8:39 PM, Boris Zbarsky bzbar...@mit.edu 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:
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
26 matches
Mail list logo
