10, 2015, at 9:33 PM, Brian Kardell bkard...@gmail.com wrote:
On Aug 6, 2015 11:05 PM, Glen Huang curvedm...@gmail.com
mailto:curvedm...@gmail.com wrote:
This assumes you'll match
That's a good point. I agree for most APIs it's probably better to simply
use polyfill code for all
at 6:50 PM, Glen Huang curvedm...@gmail.com wrote:
@William @Matthew
Ah, thanks. Now I think prollyfill is prolly a good name. :)
@Brian
Actually, I had this pattern in mind:
When no browsers ship the API:
```
if (HTMLElement.prototype.foo) {
HTMLElement.prototype._foo
@William @Matthew
Ah, thanks. Now I think prollyfill is prolly a good name. :)
@Brian
Actually, I had this pattern in mind:
When no browsers ship the API:
```
if (HTMLElement.prototype.foo) {
HTMLElement.prototype._foo = HTMLElement.prototype.foo;
} else {
HTMLElement.prototype._foo =
Thanks for the detailed explanation.
The only thing I'm not sure I understand is the pattern you described:
```
HTMLElement.prototype.foo = HTMLElement.prototype._foo;
```
I had this pattern in mind when you talked about prollyfills:
```
HTMLElement.prototype._foo = function() {
if
On second thought, what's the difference between prollyfills and libraries
exposed web APIs in a functional style (e.g., node1._replaceWith(node2) vs
replaceWith(node2, node1)? Or in a wrapper style like jquery does? Prefixing
APIs doesn't seem to be that different from using custom APIs? You
. They have
to promise they will never design an API that starts with the prefix we used.
Let's say we write a prollyfills for the node.replace API. So our lib exposes
node._replace
On Aug 3, 2015, at 10:16 AM, Brian Kardell bkard...@gmail.com wrote:
On Sun, Aug 2, 2015 at 9:39 PM, Glen Huang
I'm pretty obsessed with all kinds of web specs, and invest heavily in tools
based on future specs. I was discussing with Tab the other day about whether he
thinks using a css preprocessor that desugars future css is a good idea. His
answer was surprisingly (at least to me) negative, and
Ww, this is pure gold. Thank you so much for such thorough explanation, any
even took the trouble to actually implement optimizations to make sure the
numbers are right. I'm so grateful for the work you put into this just to
answer my question. How do I accept your answer here? ;)
So what
Wow, it's now super clear. Thanks for the detailed explanation.
Just a quick follow up question to quench my curiosity: if I do list[1] and
no one has ever asked the list for any element, Gecko will find the first two
matching elements, and store them in the list, if I then immediately do
querySelector with an id selector does in fact benefit from the id hashtable
Looking at the microbenchmark again, for Gecko, getElementById is around 300x
faster than querySelector('#id'), and even getElementsByClassName is faster
than it. It doesn't look like it benefits much from an eagerly
Live node lists make all dom mutation slower
Haven't thought about this before. Thank you for pointing it out. So if I use,
for example, lots of getElementsByClass() in the code, I'm actually slowing
down all DOM mutating APIs?
, Glen Huang curvedm...@gmail.com
mailto:curvedm...@gmail.com wrote:
On second thought, if the list returned by getElementsByClass() is lazy
populated as Boris says, it shouldn't be a problem. The list is only updated
when you access that list again.
The invalidation is what makes your code
On second thought, if the list returned by getElementsByClass() is lazy
populated as Boris says, it shouldn't be a problem. The list is only updated
when you access that list again.
On Apr 28, 2015, at 2:08 PM, Glen Huang curvedm...@gmail.com wrote:
Live node lists make all dom mutation
Intuitively, querySelector('.class') only needs to find the first matching
node, whereas getElementsByClassName('.class')[0] needs to find all matching
nodes and then return the first. The former should be a lot quicker than the
latter. Why that's not the case?
See
it?
On Apr 27, 2015, at 9:51 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 4/27/15 4:57 AM, Glen Huang wrote:
Intuitively, querySelector('.class') only needs to find the first
matching node, whereas getElementsByClassName('.class')[0] needs to find
all matching nodes
Not true; see below
...@sicking.cc wrote:
On Mon, Apr 27, 2015 at 1:57 AM, Glen Huang curvedm...@gmail.com wrote:
Intuitively, querySelector('.class') only needs to find the first matching
node, whereas getElementsByClassName('.class')[0] needs to find all matching
nodes and then return the first. The former should
with prefetch that we'd keep the data around in the memory cache
waiting for the request.
On Apr 18, 2015 7:07 AM, Glen Huang curvedm...@gmail.com
mailto:curvedm...@gmail.com wrote:
Didn't know about this trick. Thanks.
But I guess you have to make sure the file being prefetched must have a long
18, 2015, at 10:12 AM, Elliott Sprehn espr...@chromium.org wrote:
link rel=prefetch does that for you.
On Apr 17, 2015 7:08 PM, Glen Huang curvedm...@gmail.com
mailto:curvedm...@gmail.com wrote:
One benefit is that browsers can start downloading it asap, instead of
waiting util the fetch
extensible web :)
On Fri, Apr 17, 2015 at 1:32 PM, Matthew Robb matthewwr...@gmail.com
mailto:matthewwr...@gmail.com wrote:
I like the idea of this. It reminds me of polymer's core-ajax component.
On Apr 16, 2015 11:39 PM, Glen Huang curvedm...@gmail.com
mailto:curvedm...@gmail.com wrote
One benefit is that browsers can start downloading it asap, instead of waiting
util the fetch code is executed (which could itself be in a separate file).
On Apr 18, 2015, at 8:41 AM, Elliott Sprehn espr...@chromium.org wrote:
On Fri, Apr 17, 2015 at 6:33 AM, Glen Huang curvedm
Inspired by HTML imports, can we add JSON imports too?
```html
script type=application/json src=foo.json id=foo/script
script type=application/json id=bar
{ foo: bar }
/script
```
```js
document.getElementById(foo).json // or whatever
document.getElementById(bar).json
```
The IDBTransaction interface exposes an onerror event handler. I wonder when
that handler gets called? The algorithm of Steps for aborting a transaction”
dispatches error events at requests of the transaction, but never at the
transaction itself, only an abort event is dispatched, if I
Darn it, I forgot they bubble. Thank you for the detailed explanation.
On Feb 6, 2015, at 1:59 AM, Joshua Bell jsb...@google.com wrote:
On Thu, Feb 5, 2015 at 12:58 PM, Glen Huang curvedm...@gmail.com
mailto:curvedm...@gmail.com wrote:
The IDBTransaction interface exposes an onerror event
before/after/replaceWith behave the same in this case is just a side effect of
DOM trying to be less surprising and more symmetrical for the curious ones. I
doubt most people would even aware they behave the same in this case. Whenever
the user cases come, I believe most people will just use
before the context node
set prevInserted to node
This algorithm shouldn’t slow normal operations down, and I wonder if the spec
could use an algorithm like this and not using document fragment.
On Jan 21, 2015, at 5:50 PM, Glen Huang curvedm...@gmail.com wrote:
@Boris @Simon
, Simon Pieters sim...@opera.com wrote:
On Wed, 21 Jan 2015 00:45:32 +0100, Glen Huang curvedm...@gmail.com wrote:
Ah, thank you for letting me know.
I vaguely remember document fragment is introduced just to reduce reflows.
Looks like this best practice is obsolete now? (I remember myself
be a problem with the native DOM.
On Jan 20, 2015, at 6:39 PM, Anne van Kesteren ann...@annevk.nl wrote:
On Sun, Jan 18, 2015 at 4:40 AM, Glen Huang curvedm...@gmail.com wrote:
To generalize the use case, when you have a bunch of nodes, some of which
need to be inserted before a node
...@annevk.nl wrote:
On Tue, Jan 20, 2015 at 2:22 PM, Glen Huang curvedm...@gmail.com wrote:
jQuery doesn’t support that out of performance and code size reasons:
http://bugs.jquery.com/ticket/14380
https://github.com/jquery/jquery/pull/1276#issuecomment-24526014
Both reasons shouldn’t
as an argument
along with other nodes, just use before() and after() to insert these other
nodes? And even insert them one by one is fine?
On Jan 20, 2015, at 11:57 PM, Simon Pieters sim...@opera.com wrote:
On Tue, 20 Jan 2015 15:00:41 +0100, Glen Huang curvedm...@gmail.com wrote:
I wonder what
Oh crap. Just realized saving index won’t work if context node’s previous
siblings are passed as arguments. Looks like inserting transient node is still
the best way.
On Jan 18, 2015, at 11:40 AM, Glen Huang curvedm...@gmail.com wrote:
To generalize the use case, when you have a bunch
the context
node’s index and its parent, and after running it, pre-insert node into parent
before parent’s index’th child (could be null). No transient node involved and
no recursive finding.
Hope you can reconsider if this edge case should be accepted.
On Jan 16, 2015, at 5:04 PM, Glen Huang curvedm
at 8:47 AM, Glen Huang curvedm...@gmail.com wrote:
Another way to do this is that in mutation method macro, prevent `oldNode`
from being added to the doc frag, and after that, insert the doc frag before
`oldNode`, finally remove `oldNode`. No recursive finding of next sibling is
needed
, 2015 at 8:47 AM, Glen Huang curvedm...@gmail.com wrote:
Another way to do this is that in mutation method macro, prevent `oldNode`
from being added to the doc frag, and after that, insert the doc frag before
`oldNode`, finally remove `oldNode`. No recursive finding of next sibling is
needed
Currently, for `oldNode.replaceWith(…collection)`, if `collection` is array of
multiple nodes, and `oldNode` is in `collection`, after the mutation method
macro, `oldNode` lives in a doc frag. So in the replace algorithm, `parent` is
the doc frag, `node` is also the doc frag, an
Another way to do this is that in mutation method macro, prevent `oldNode` from
being added to the doc frag, and after that, insert the doc frag before
`oldNode`, finally remove `oldNode`. No recursive finding of next sibling is
needed this way.
On Jan 16, 2015, at 1:37 PM, Glen Huang curvedm
35 matches
Mail list logo
