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
± On Fri, Jan 9, 2015 at 5:40 AM, Anne van Kesteren ann...@annevk.nl
± 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
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
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
± 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
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
| 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
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
Read the thread more closely - as always, we only suggest dropping
prefixed variants *if 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
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
`.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?
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
The proposal here would be to accept CSS
An alternate proposal:
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
Both of these seem very like the ES6
iterator interface. Can you just use
that instead of minting a new iterable/
Again, that doesn't solve my TreeWalker use case :-/
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
Mail list logo