?
I don't think readyState as Kyle describes is an appropriate candidate
mechanism because it's not an actual indicator that the functionality
exists. The only thing you can really be sure of if readyState is
"uninitialized" is that the script element supports readyState. The fact
the only bro
>> Doesn't mostly address the use-case of
>> load-but-don't-execute in markup? The reason script-inserted script elements
>> need this capability is more advanced than any use-case for why you'd do so
>> in markup. In other words, I can't imagine that a script loader would rely
>> on adding script
?
I'm not sure why you are narrowing the scope to "script loaders"? (I
imagine you're referring to js-libraries which help with loading
scripts faster?)
Yes, script loaders like LABjs are the primary use-case that I'm concerned
about in terms of giving the load-but-defer-execution behavior to.
At 2011-01-24T14:38:28+1300, Robert O'Callahan wrote:
> On Thu, Jan 20, 2011 at 4:20 PM, Matthew Gregan wrote:
>
> > This doesn't seem to be required by the current wording of the spec (in
> > fact, it seems to be incorrect behaviour), but I think this behaviour is
> > more intuitive, as it seems
On Thu, Feb 3, 2011 at 4:41 PM, Boris Zbarsky wrote:
> And all I'm saying is that there are at least three pieces of data here:
>
> 1) innerText return value
> 2) Selection.toString() return value
> 3) What the browser actually copies
>
> My point is that browsers must be free to modify #3 as d
On Thu, Feb 3, 2011 at 4:53 PM, Nicholas Zakas wrote:
> I don't think readyState as Kyle describes is an appropriate candidate
> mechanism because it's not an actual indicator that the functionality exists.
> The only thing you can really be sure of if readyState is "uninitialized" is
> that th
On Thu, Feb 3, 2011 at 4:45 PM, Kyle Simpson 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:
>>
>>
>>
>>
I don't think readyState as Kyle describes is an appropriate candidate
mechanism because it's not an actual indicator that the functionality exists.
The only thing you can really be sure of if readyState is "uninitialized" is
that the script element supports readyState. The fact the only browser
?> 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: