; On Aug 10, 2015, at 9:33 PM, Brian Kardell wrote:
>
> On Aug 6, 2015 11:05 PM, "Glen Huang" <mailto:curvedm...@gmail.com>> wrote:>
>
> > > This assumes you'll match
> >
> > That's a good point. I agree for most APIs it's proba
at 7:07 AM, Brian Kardell wrote:
>
> On Thu, Aug 6, 2015 at 6:50 PM, Glen Huang wrote:
>> @William @Matthew
>>
>> Ah, thanks. Now I think prollyfill is prolly a good name. :)
>>
>> @Brian
>>
>> Actually, I had this pattern in mind
@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 = poly
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 (HTMLEleme
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 mi
he WG. 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 wrote:
>
> On Sun, Aug 2, 2015 at 9:39 PM, Glen H
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 recomme
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
> 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
But If I do getElementsByClass()[0], and LiveNodeList is immediately garbage
collectable, then if I change the DOM, Blink won't traverse ancestors, thus no
penalty for DOM mutation?
> On Apr 28, 2015, at 2:28 PM, Elliott Sprehn wrote:
>
>
>
> On Mon, Apr 27, 2015 at
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 wrote:
>
>> Live node lists make all do
> 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?
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
"li
, 2015, at 7:04 PM, Jonas Sicking wrote:
>>
>> On Mon, Apr 27, 2015 at 1:57 AM, Glen Huang wrote:
>>> Intuitively, querySelector('.class') only needs to find the first matching
>>> node, whereas getElementsByClassName('.class')[0] needs to find all
because authors don't use querySelector often enough that UAs aren't
interested in optimizing it?
> On Apr 27, 2015, at 9:51 PM, Boris Zbarsky wrote:
>
> On 4/27/15 4:57 AM, Glen Huang wrote:
>> Intuitively, querySelector('.class') only needs to find th
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 http://jsperf.com/queryselect
in the memory cache
> waiting for the request.
>
> On Apr 18, 2015 7:07 AM, "Glen Huang" <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
>
s http header?
> On Apr 18, 2015, at 10:12 AM, Elliott Sprehn wrote:
>
> does that for you.
>
> On Apr 17, 2015 7:08 PM, "Glen Huang" <mailto:curvedm...@gmail.com>> wrote:
> One benefit is that browsers can start downloading it asap, instead of
> waiting
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 wrote:
>
>
>
> On Fri, Apr 17, 2015 at 6:33 AM, Glen Huang <mailto:cu
y
> extensible web :)
>
> On Fri, Apr 17, 2015 at 1:32 PM, Matthew Robb <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" <mailto:curvedm...@gmail.
Inspired by HTML imports, can we add JSON imports too?
```html
{ "foo": "bar" }
```
```js
document.getElementById("foo").json // or whatever
document.getElementById("bar").json
```
Darn it, I forgot they bubble. Thank you for the detailed explanation.
> On Feb 6, 2015, at 1:59 AM, Joshua Bell wrote:
>
> On Thu, Feb 5, 2015 at 12:58 PM, Glen Huang <mailto:curvedm...@gmail.com>> wrote:
> The IDBTransaction interface exposes an onerror event handler.
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 understa
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 rep
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 wrote:
>
> @Boris @Simon
>
4:52 PM, Simon Pieters wrote:
>
> On Wed, 21 Jan 2015 00:45:32 +0100, Glen Huang 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
ntext node 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 wrote:
>
> On Tue, 20 Jan 2015 15:00:41 +0100, Glen Huang wrote:
>
>> I wonder
ote:
>
> On Tue, Jan 20, 2015 at 2:22 PM, Glen Huang 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 r
Both reasons shouldn’t be a problem with the native DOM.
> On Jan 20, 2015, at 6:39 PM, Anne van Kesteren wrote:
>
> On Sun, Jan 18, 2015 at 4:40 AM, Glen Huang wrote:
>> To generalize the use case, when you have a bunch of nodes, some of which
>> need to be inserted before a
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 wrote:
>
> To generalize the use case, when you have a bunch of nodes
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 wr
6, 2015 at 8:47 AM, Glen Huang 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
>
entioned in the first mail.
> On Jan 16, 2015, at 4:22 PM, Anne van Kesteren wrote:
>
> On Fri, Jan 16, 2015 at 8:47 AM, Glen Huang wrote:
>> Another way to do this is that in mutation method macro, prevent `oldNode`
>> from being added to the doc frag, and after
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 wr
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 `HierarchyReque
35 matches
Mail list logo
