RE: Why is querySelector much slower?

2015-04-27 Thread François REMY
Not sure this is a public-webapps issue but I'm pretty sure however that the reason is the return values of getElement*By*(...) are cached by the browser which means that you end up not doing the work at all at some point in the loop, while you probably do it every single time for

RE: Shadow tree style isolation primitive

2015-01-12 Thread François REMY
± On Fri, Jan 9, 2015 at 5:40 AM, Anne van Kesteren ann...@annevk.nl ± wrote: ± I'm wondering if it's feasible to provide developers with the ± primitive that the combination of Shadow DOM and CSS Scoping provides. ± Namely a way to isolate a subtree from selector matching (of document ±

Re: =[xhr]

2014-09-03 Thread François REMY
Yes, sure, a lot of it can be done asynchronously. And I do that as much as possible. But I suggest there are times where synchronous transfer is both appropriate and necessary. The case in point is 50 levels deep in the stack of function calls when a new Java class is needed. This statement is

Re: =[xhr]

2014-08-01 Thread François REMY
From: nmork_consult...@cusa.canon.com Thank you for letting me know my input is not desired. No, not at all. I think many engineers reading this list are truly delighted to have seen your message. Some of us are also very sad, but I would argue that all of us who have a good sense of humor

RE: [webcomponents] Inheritance in Custom Elements (Was Proposal for Cross Origin Use Case and Declarative Syntax)

2013-12-08 Thread François REMY
± If someone were to make proposals about adding more hooks to the web ± platform to enable more subtyping use cases (for example, a protocol for ± participating in form submission) I would look forward to working with them ± on those proposals. ± ± I am very interested in such proposals and I

Re: Splitting Stream into InputStream and OutputStream (was Re: CfC: publish WD of Streams API; deadline Nov 3)

2013-10-31 Thread François REMY
to convert a string into a stream, for example, in the case of an API that requires an InputStream and must integrate with older code that returns a String or a Blob. De : Takeshi Yoshino Envoyé : ‎jeudi‎ ‎31‎ ‎octobre‎ ‎2013 ‎04‎:‎45 À : François REMY Cc : Arthur Barstow, public-webapps@w3

Re: CfC: publish WD of Streams API; deadline Nov 3

2013-10-30 Thread François REMY
| If you have any comments or concerns about this proposal, please reply | to this e-mail by November 3 at the latest. While adding streams to the platform seems a good idea to me, I've a few concern with this proposal. My biggest concerns are articulated over two issues: - Streams should

RE: Making selectors first-class citizens

2013-09-16 Thread François REMY
Regardless of what they assumed, there's presumably a case to handle older browsers that don't support it at all. If the scripts guessed wrongly about what the unprefixed name would be, then they'll fall into this case anyway, which should be okay. If they didn't support down-level browsers

RE: Making selectors first-class citizens

2013-09-16 Thread François REMY
Read the thread more closely - as always, we only suggest dropping prefixed variants *if possible*. Define possible. If we add matchesSelector as an official alias to matches the same way querySelector and querySelectorAll will be aliases to query and queryAll soon, it should be possible to

RE: [DOM4] Short and Efficent DOM Traversal

2013-07-28 Thread François REMY
I hate TreeWalker because it's an iterator but not an ES Iterator. DOM is broken, legacy cruft, etc. As far as I know, an iterator can only go forward, not backward (while a tree walker can). But I agree 90% of the use cases map to a forward navigation and it would be nice to support for-of

RE: [DOM4] Short and Efficent DOM Traversal

2013-07-28 Thread François REMY
`.iterator()` is a nonstandard Mozilla-ism; the spec calls for a field named by the well-known unique symbol `@@iterator`. How do you write that using WebIDL? It there an attribute for that?

[DOM4] Short and Efficent DOM Traversal

2013-07-27 Thread François REMY
TL/DR: CSS Selectors represent the most commonly used way to perform search in the DOM. But, until now, you’ve to choose between using CSS (querySelectorAll) or doing incremental search (createTreeWalker). I think we should try to fix that. The proposal here would be to accept CSS

RE: [DOM4] Short and Efficent DOM Traversal

2013-07-27 Thread François REMY
From: o...@chromium.org An alternate proposal: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-July/040264.html. var iterator = document.querySelectorAll(abc).asIterator(); You make the assumption I want to walk in the forward direction and do not want to start from a specific

RE: [DOM4] Short and Efficent DOM Traversal

2013-07-27 Thread François REMY
Both of these seem very like the ES6 iterator interface. Can you just use that instead of minting a new iterable/ iterator interface? Again, that doesn't solve my TreeWalker use case :-/

RE: [DOM4] Short and Efficent DOM Traversal

2013-07-27 Thread François REMY
I like the idea of being able to get lazy iterators and treewalkers. And that are driven by selectors. But I think creating a new feature rather than trying to retrofit existing ones will be more successful. Why? I need *exactly* the behavior the TreeWalker is offering me now: ie a lazy