Re: [whatwg] Request for feedback: supported elements for formatBlock
On Mon, May 23, 2011 at 2:37 PM, Aryeh Gregor wrote:
>
> * Everyone supports address, div, h*, p, pre
> * Everyone but IE supports blockquote
> * Everyone but Opera supports dd, dt
> * Only IE supports ol, ul
> * Only Firefox and Chrome support dl
> * Only Chrome supports article, aside, footer, header, hgroup, nav, section
> * HTML5 mandates support for address, article, aside, blockquote, div,
> footer, h*, header, hgroup, nav, p, pre, section (which is the same as
> Chrome but minus dl/dt/dd)
>
WebKit's FormatBlock basically supports all HTML5 elements that are display:
block by default.
The issue with all the non-IE browsers is that they support a bunch of
> things that make sense to nest within one another, and formatBlock
> doesn't work for nesting. So for instance, if I do
> execCommand("formatBlock", false, "blockquote") on
> foobar, what's the result? Firefox produces
> foobar, Chrome produces
> foobar, and Opera produces
> foobar.
>
I think Chrome's and Opera's behaviors make most senes here given that
FormatBlock removes the current enclosing block and replace it with the
specified block in other situations.
If you argue that blockquote can be nested, then I'd argue that any block
elements except p can be nested in various situations.
If formatBlock supported them in the way Firefox supports blockquote, you
> could add them using execCommand() but not remove them.
>
For this reason, I don't like Firefox's behavior.
As for Chrome or Opera, their way of doing things might make sense in
> some cases for blockquote, but usually you want the way indent behaves
> instead. If I select two paragraphs and want to put a blockquote
> around them, normally I want a two-paragraph blockquote, not a
> two-line blockquote or two blockquotes. It doesn't make any sense at
> all for things like article -- you want
> foobar, not
> foobar and certainly not
> foobar.
>
I disagree. It depends on context.
So my current spec
> <
> http://aryeh.name/gitweb.cgi?p=editcommands;a=blob_plain;f=editcommands.html;hb=4a898d7#the-formatblock-command
> >
> supports only address, div, h*, p, and pre. I don't think it makes
> sense to support things like blockquote (or article, aside, etc.)
> which are expected to have other block elements nested inside them.
Those should have separate commands (as should dl/dt/dd, probably).
> But if anyone else feels otherwise, please say so.
>
I think we have to support blockquote. The last time I checked, Gmail used
FormatBlock to add blockquote around the quoted context.
- Ryosuke
Re: [whatwg] Proposal for separating script downloads and execution
On 5/26/11 1:10 AM, Ian Hickson wrote:
It's presumably a whole heck of a lot more complex than brack matching:
alert('fail');
function test () {
// ...megabytes of perfectly fine code...
a b;
}
...had better not alert anything.
And in V8 does not, indeed.
What we really need though is perf data, e.g. comparing how browsers
handle code such as:
var times = [];
times.push(new Date());
times.push(new Date());
function test() {
// ...megabytes of complicated code...
};
times.push(new Date());
test();
times.push(new Date());
What are the deltas between all the times in various browsers?
Cute idea. You have to disentangle effects like the second script's
text not being fully downloaded yet when the first script runs, so
loading from file:// or at least from cache is good. You could probably
modify the test to use a script-inserted script instead, but I suspect
that would not change things much.
In any case, I put up that testcase using 4 copies of the non-minified
version of JQuery 1.6.1 as the "complicated code" at
.
The first load will have that downloading issue, but subsequent loads
should be ok. Or save to a local file to avoid the network effects.
I see numbers in ms like so for the deltas (without error bars, but all
are plus or minus 4ms or so based on eyeballing):
Firefox Nightly: 60, 0, 17
Chrome 12 dev: 43, 0, 160 or 19 (the last number is bimodal; this
happens from file:// too, so not
network-related).
WebKit nightly: 30, 0, 30
Opera 11: 22, 0, 10
IE9 (on different hardware): 32, 0, 67
I would expect the deltas to be a high number, 0, and a high number
respectively.
Yep.
I would be happy to redo the test with different "complicated code" if
people think that another test corpus would be better. Just point me to
the code you want tested.
-Boris
Re: [whatwg] Proposal for separating script downloads and execution
On Wed, 25 May 2011, Aryeh Gregor wrote:
>
> # [02:21] the only thing we do on a chunk of script in v8
> currently before starting to execute code is to essentially brace
> match
It's presumably a whole heck of a lot more complex than brack matching:
alert('fail');
function test () {
// ...megabytes of perfectly fine code...
a b;
}
...had better not alert anything.
What we really need though is perf data, e.g. comparing how browsers
handle code such as:
var times = [];
times.push(new Date());
times.push(new Date());
function test() {
// ...megabytes of complicated code...
};
times.push(new Date());
test();
times.push(new Date());
What are the deltas between all the times in various browsers?
I would expect the deltas to be a high number, 0, and a high number
respectively. However, if it is different then the assumptions that
underlie the spec are wrong, and there's probably something we can work on
to make the Web better.
--
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 5/25/11 8:44 PM, Aryeh Gregor wrote:
I just discussed this on IRC with jamesr, of the Chrome team:
http://krijnhoetmer.nl/irc-logs/whatwg/20110526#l-97
According to him, the parsing and compilation time of JavaScript can't
be usefully separated from the execution.
That sounds like a V8 implementation detail. It's certainly not the
case in Spidermonkey; the bytecode compilation in spidermonkey is a
noticeable part of script execution for large scripts (because it
involves various parsing operations, not just paren matching, as well as
constant folding etc) and could in fact be done on a separate thread.
# [02:21] also keep in mind that evaluating the source
"function foo() { }" is _executing_ code
Actually _evaluating_ it is, yes. That has to happen on the main thread.
# [02:21] that's setting a variable called 'foo' on the global object
Not quite; it's defining a property called 'foo' on the global object.
# [02:22] i think that assertion is based on the time spent
executing the code
# [02:22] i.e. assigning the global variable to 'foo' and
dealing with all the side effects of that
If there is only one function in the script, there is exactly one
property definition happening. That doesn't have much in the way of
side effects.
# [02:22] you can brace match on another thread, but that's
not going to buy you much
In V8.
But again, if brace-matching+executing a script of the form:
function foo() {
// megabytes of code here
}
is fast in V8 already, then there is no problem to solve there to start
with, right? Is it the case that this is fast in V8?
# [02:33] incoherent in modern JS engines where there's not
much of a distinction between parse and execution, yes
I think this is generalizing from V8's implementation in a way that
doesn't necessarily make sense for other JS engines.
-Boris
Re: [whatwg] Proposal for separating script downloads and execution
On 5/25/11 8:05 PM, Aryeh Gregor wrote: What do you mean by "execution" here? If the script is already compiled, and you write it so that all it does is define a function, then executing it should not take any measurable amount of time (<1ms). Currently this might not be observable, since if I understand correctly, browsers don't separate compilation from execution. For what it's worth, if someone can point me to a script they actually want such measurements for, I'd be happy to produce at least Gecko numbers for how long the various parts take. While the different parts of the pipeline are not separable from the point of view of a web page right now, Gecko internals and profilers have no such limitations. That's assuming people actually want numbers here. -Boris
Re: [whatwg] ArrayBuffer and the structured clone algorithm
On Mon, Jan 31, 2011 at 10:47 PM, Kenneth Russell wrote: > On Mon, Jan 31, 2011 at 3:10 PM, Ian Hickson wrote: >> On Fri, 7 Jan 2011, David Flanagan wrote: >>> >>> The structured clone algorithm currently allows ImageData and Blob >>> objects to be cloned but doesn't mention ArrayBuffer. Is this >>> intentional? I assume there are no security issues involved, since one >>> could copy the bytes of an ArrayBuffer into either a Blob or an >>> ImageData object in order to clone them. >> >> It's intentional in that I'm waiting for ArrayBuffer to be more stable >> before I add it throughout the spec. (Same with CORS and the various >> places that might support cross-origin communication, e.g. Web Workers, >> Server-Sent Events, +, etc.) > > There's been some preliminary discussion within the WebGL working > group (where ArrayBuffer / Typed Arrays originated) about using > ArrayBuffer with Web Workers in particular. There is a strong desire > to support handoff of an ArrayBuffer from the main thread to a worker > and vice versa; this would allow efficient producer/consumer queues to > be built without violating ECMAScript's shared-nothing semantics. > > All of the parties involved are pretty busy getting WebGL 1.0 out the > door; once that happens, we aim to make one more revision to the Typed > Array spec to support (1) read-only arrays for more efficient XHRs and > (2) handoff of ArrayBuffers. Expect public discussions to start in > about six to eight weeks. Apologies for not following up to this thread. Some strawman proposals for the typed array specification were posted about a month ago and updated just now based on initial feedback. The primary goal is to define interactions between the structured cloning algorithm and ArrayBuffers, so that zero-copy data transfer between Web Workers can be achieved. These proposals, if agreed upon, would involve changes to the structured cloning algorithm and Web Messaging spec. Please see: http://www.khronos.org/registry/typedarray/specs/latest/ Feedback would be greatly appreciated. There is an ongoing thread on the public WebGL mailing list ( see https://www.khronos.org/webgl/public-mailing-list/ ), but I'll take care of coalescing feedback from mailing lists. -Ken
Re: [whatwg] Proposal for separating script downloads and execution
On Wed, May 25, 2011 at 8:44 PM, Aryeh Gregor wrote:
> As far as I understand it now, the actual problem here is that we want
> to be able to separate download and execution, not parsing and
> execution.
I think part of the confusion is that most of us think of "parsing" in C
terms: a compiler taking the whole chunk and processing the whole thing
before executing any of it. From what I understand (from the above, and
other vague recollections), V8 only does a very rough first pass, and then
parses code when it's executed, so the amount of "parsing" time that could
be done asynchronously is tiny anyway.
But you can already do that by putting the whole script in
> a comment, for instance, as Gmail does, so I'm not clear at this point
> on why we need another feature in actual browsers.
>
That's a gross hack, that they're presumably only doing because they have no
better way. Isn't that just a workaround for old JS engines on mobile? I'm
guessing that hack isn't needed on any modern script engine. See the timing
example I gave earlier: executing a large script block that only defines a
couple functions takes no measurable time. It also takes no measurable time
(0ms) on the stock browser on my Android 2.3.4 phone (on a Nexus S).
> James points out this doesn't work if you don't control the script at
> all -- e.g., if you're loading a copy of jQuery from a central
> location that serves many sites, in the interest of increasing cache
> hits or offloading bandwidth.
The same applies to the saner wrap-in-a-function method. I don't think it
makes sense to introduce new browser features for this, though--it's a whole
lot simpler to get the central location to offer a pre-wrapped version, than
to change every browser so they don't have to. ("Dye my eyes to match my
dress", etc...)
--
Glenn Maynard
Re: [whatwg] Proposal for separating script downloads and execution
On Wed, May 25, 2011 at 8:44 PM, Aryeh Gregor wrote: > As far as I understand it now, the actual problem here is that we want > to be able to separate download and execution, not parsing and > execution. But you can already do that by putting the whole script in > a comment, for instance, as Gmail does, so I'm not clear at this point > on why we need another feature in actual browsers. James points out this doesn't work if you don't control the script at all -- e.g., if you're loading a copy of jQuery from a central location that serves many sites, in the interest of increasing cache hits or offloading bandwidth.
Re: [whatwg] Proposal for separating script downloads and execution
On Wed, May 25, 2011 at 8:05 PM, Aryeh Gregor wrote:
> There's a big conceptual difference between parsing the script and
> executing it. We need to be careful not to conflate the two, even if
> browsers don't *currently* separate them.
I just discussed this on IRC with jamesr, of the Chrome team:
http://krijnhoetmer.nl/irc-logs/whatwg/20110526#l-97
According to him, the parsing and compilation time of JavaScript can't
be usefully separated from the execution. If you have a script that
does nothing but define a big function, and it takes some time to run,
it's because actually creating the objects and so on is taking the
time, not anything that can be pushed off to a background thread. So
I stand corrected on that point. It seems the only thing you could
easily separate is the download. Notable lines:
# [02:19] But I assume everyone does something like
compile the whole file to bytecode first thing, at least.
# [02:19] no
# [02:21] the only thing we do on a chunk of script in v8
currently before starting to execute code is to essentially brace
match
# [02:21] also keep in mind that evaluating the source
"function foo() { }" is _executing_ code
# [02:21] The assertion in that thread is that
compilation of large amounts of causes visible lag if it has to be
done synchronously, even if the code doesn't actually do anything
beyond define some functions. Is that the case in V8?
# [02:21] that's setting a variable called 'foo' on the global object
# [02:22] i think that assertion is based on the time spent
executing the code
# [02:22] i.e. assigning the global variable to 'foo' and
dealing with all the side effects of that
# [02:22] which you can't meaningfully pass to another thread
# [02:22] you can brace match on another thread, but that's
not going to buy you much
# [02:23] i haven't jumped in on that thread because everyone
is using slightly different terminology and it's just kind of a mess
:/
# [02:24] i think what authors want is a way to download
script but not execute it
# [02:32] According to you, though, use case A was incoherent.
# [02:33] incoherent in modern JS engines where there's not
much of a distinction between parse and execution, yes
If I understand correctly, that means all of the following key
statements are incorrect (someone please correct me if I
misunderstood):
On Mon, May 23, 2011 at 9:35 PM, Ian Hickson wrote:
> The problem here seems to boil down to "we want our script-heavy page to
> load fast without blocking UI, but browsers block the UI thread while
> parsing after downloading but before executing".
>
> . . .
>
> Why? The parsing doesn't have to block loading; it can all happen in the
> background, while the page is loading.
>
> . . .
>
> Given that script execution (as opposed to the preprocessing that occurs
> before execution, including parsing and compilation) can be trivially
> fast (e.g. by making the script do nothing but expose an object) . . .
>
> . . .
>
> Given that the time the script takes to execute is already under the
> control of the author, and can be trivially short . . .
>
> . . .
>
> Problem A can't be the problem being
> solved here, since the execution takes a trivially short time compared to
> the download and compiling.
As far as I understand it now, the actual problem here is that we want
to be able to separate download and execution, not parsing and
execution. But you can already do that by putting the whole script in
a comment, for instance, as Gmail does, so I'm not clear at this point
on why we need another feature in actual browsers.
Re: [whatwg] Proposal for separating script downloads and execution
On Tue, May 24, 2011 at 12:34 PM, Nicholas Zakas wrote: > Moving parsing and compilation to a background thread solves part of the > problem, the problem where doing so freezes the UI currently. It doesn't > solve what I consider to be the important part of the problem, and that is > the inability to have a JavaScript resource downloaded but not applied to the > page. The best next experience can only be achieved when the resources are > ready and then applied at the right moment. Consider this hypothetical scenario: when you add a
Re: [whatwg] [html5] Question on the structured cloning algorithm
On Tue, 24 May 2011, Stewart Brodie wrote: > > The section on the structured cloning algorithm has a Note that says > > > "Property descriptors, setters, getters, and analogous features are > > not copied in this process." > > Is this note part of the normative definition of the algorithm, or just > a non-normative helpful explanatory note? The typographic convention > description set out in section 1.8.2 doesn't say either way. It has no normative content (no RFC2119 term) so it's not normative. See: http://ln.hixie.ch/?start=1140242962&count=1 > Do getters need to be called to obtain a value which can be stored > (after being cloned itself) in the result? I'm not sure I follow the question. Can you elaborate? -- 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
2011/5/25 Nicholas Zakas :
> I already explained that in my previous email. Parsing and compilation on
a background thread removes some of the problem but not all of it.
Ultimately, even if the script is just a function waiting to be called, the
browser still executes it in a blocking fashion after parsing and
compilation. It's the execution that is troublesome part because it
interferes with the UI. The fact that the script isn't doing much is
helpful, but once again, there will be a non-zero interrupt that can affect
user experience.
The recommendation that your script look something like this:
var yourAPI = function() { throw "API has not been initialized; initAPI must
be called"; };
var initAPI = function() {
initAPI = function() { };
yourAPI = function() {}
yourAPI.prototype.func = function() { }
[...];
return yourAPI;
}
and "..." is lots of code.
There are three steps to loading this API: parsing it, executing the
top-level function and calling initAPI().
The assertion is that it should be possible for top-level execution to take
near-zero time, regardless of the length of "[...]". This seems reasonable
to me. I don't know the internals of various Javascript engines, but
looking at it in Python terms, all the top-level does is create two function
objects from two code objects, where code objects represent the parsed code,
and function objects represent the live function with its global scope and
upvalues (closure variables) attached. All of the actual work happens when
initAPI is called, and you can choose when to do that.
I put a simple test here:
https://zewt.org/~glenn/test-top-level-context-execution. The top-level
function takes no measurable time for me in FF4 and Chrome 11.
(That assumes there's no CPU time tied to execution--work that can't be done
asynchronously--which happens before the first line of code where this code
starts measuring time. Someone familiar with engine internals would need to
comment if that's the case.)
It's been a while since our earlier discussion and I havn't yet entirely
refreshed myself on it, so I'm not sure if this fully covers what we
discussed, but it seems like a reasonable approach.
--
Glenn Maynard
Re: [whatwg] Proposal for separating script downloads and execution
I already explained that in my previous email. Parsing and compilation on a background thread removes some of the problem but not all of it. Ultimately, even if the script is just a function waiting to be called, the browser still executes it in a blocking fashion after parsing and compilation. It's the execution that is troublesome part because it interferes with the UI. The fact that the script isn't doing much is helpful, but once again, there will be a non-zero interrupt that can affect user experience. -N -Original Message- From: Kornel Lesiński [mailto:kor...@geekhood.net] Sent: Tuesday, May 24, 2011 2:33 PM To: whatwg@lists.whatwg.org Cc: Nicholas Zakas Subject: Re: [whatwg] Proposal for separating script downloads and execution On Tue, 24 May 2011 17:34:45 +0100, Nicholas Zakas wrote: > Your assertion that loading a file that simply defines a function will > solve the problem is a bit too simplistic for most web applications. Could you describe the case where wrapping script in a function would not solve the problem in UAs that parse scripts asynchronously? -- regards, Kornel Lesiński
