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  querySelector  
which cannot return a cached result.



From: curvedm...@gmail.com
Date: Mon, 27 Apr 2015 16:57:23 +0800
To: public-webapps@w3.org
Subject: Why is querySelector much slower?

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/queryselectorall-vs-getelementsbytagname/119 for the test
I know querySelectorAll is slow because of the static nature of returned 
NodeList, but this shouldn't be an issue for querySelector. 
 

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
±  stylesheets, not necessarily user and user agent stylesheets) and
±  requiring a special selector, such as , to pierce through the
±  boundary.
± 
±  This is a bit different from the `all` property as that just changes
±  the values of all properties, it does not make a selector such as
±  div no longer match.
± 
±  So to be clear, the idea is that if you have a tree such as
± 
±section class=example
±  h1Example/h1
±  div ... /div
±/section
± 
±  Then a simple div selector would not match the innermost div if we
±  isolated the section. Instead you would have to use section  div or
±  some such. Or perhaps associate a set of selectors and style
±  declarations with that subtree in some manner.
± 
± It's probably feasible, sure.  But I'm not sure that it's necessary, or that
± browsers will go for it.  Using a shadow root as the isolation boundary is
± *really convenient*, because it's a separate tree entirely; the fact that
± outside rules don't apply within it, and inside rules don't apply outside, 
falls
± out for free.
± 
± Let's assume we did it, though.  We'd have to have some mechanism for
± defining an isolation boundary, and denoting whether rules were inside or
± outside the boundary.  This sounds like an at-rule,
± like:
± 
± @isolate .example {
±   h1 { ... }
±   div { ... }
± }
± 
± Now, a problem here is that you have a conflict between nesting isolated
± things and specifying isolation.  Say you have foo and bar elements,
± both of which need to be isolated. You'd think you could just write:
± 
± @isolate foo {
±   ...
± }
± @isolate bar {
±   ...
± }
± 
± But this won't work! If you have markup like foobar.../bar/foo, the
± bar there is inside the foo's isolation boundary, so the @isolate rule
± can't find it.  You'd need to
± *also* nest the @isolate bar rule (and all its styling rules) within the foo
± one, and vice versa.  The effect of this on *three* mutually isolated
± components is, obviously, terrible; let's not even mention trying to use
± multiple modules together that weren't explicitly designed together.
± 
± Alternately, say that it does work - the @isolate selector pierces through
± isolation boundaries.  Then you're still screwed, because if the outer page
± wants to isolate .example blocks, but within your component you use
± .example normally, without any isolation, whoops!
± Suddenly your .example blocks are isolated, too, and getting weird styles
± applied to them, while your own styles break since they can't cross the
± unexpected boundary.
± 
± Basically, trying to smuggle private state into a global declarative language 
is a
± bitch.
± 
± So, CSS is out.  We can't reasonably do this within the confines of CSS
± application.  It needs to be handled at a different layer.  We could do it in
± HTML, potentially - some new global attribute that creates a styling boundary
± that prevents outside styling from targeting anything inside.  Then you can
± just use standard style
± scoped to apply your own styles within the boundary - as long as the
± scoping root is inside the boundary, styling is allowed.
± 
± But that means you have to add an attribute to every element that uses this
± styling boundary, and move your style info into inline scoped blocks.  That's
± annoying. :/
± 
± Let's check out JS. If you can mark some elements as always being styling
± boundaries, then whenever they're constructed, whether manually or via
± the parser, they'll get the right mechanics automatically.  And since this is 
JS,
± it shouldn't be too hard to say always attach this stylesheet to the element
± whenever it gets created, or perhaps introduce some explicit ability to do
± this in the platform.
± 
± This last one, though, is pretty much exactly Custom Elements, just with the
± children staying in the light tree rather than being moved into a shadow tree.
± But keeping them in the light tree has complications; it means that
± everything in the platform needs to be made aware of the isolation
± boundary.  Should qSA respect the isolation boundaries or not?  Depends on
± what you're using it for.
± What about things that aren't CSS at all, like getElementsByTagName()?
±  That's equivalent to a qSA with the same argument, but it's not a selector,
± per se.  Manual tree-walking would also need to be made aware of this, or
± else you might accidentally descend into something that wants isolation.
± Shadow DOM at least gives an answer to all of these, by putting the
± elements in a separate tree.  You don't need to think of every one
± individually, or deal with inconsistent design when someone forgets to spec
± their new tree-searching thing to respect the boundary.
± 
± So, do you still 

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 inacurate; if you conceptualize your Java-to-JavaScript 
conversion to use Async calls where normal calls are done in Java, you 
should not suffer from any issue. As C# did show, every single piece of 
high-level code can be transformed in an asynchronous one by the mean of a 
state machine, which can be auto-generated from the initial code without any 
major syntax change. Sure, this will require a large rewrite of the conveter 
you are currently using, and this is a non-trivial work not a lot of people 
can achieve today, but I think everyone here understands that. We don't 
expect you to make the switch overnight, nor in the coming months.


The reason we don't expect this is that neither the browser implementation 
of the concepts nor the developer tools and experience with the technology 
required for this rewrite are tailored for a broad usage at this time. I 
think everyone also understands the old code relying on sync xhr will take a 
lot of time to go away. But, eventually, browsers will have to break sites. 
The hope is to reduce the amount of sites over time, by the use of scary 
warnings like this.


What you need to understand is that this feature will eventually be removed 
from the web platform, and therefore spec writers already warn now of what 
shall be done in the future, so that the phasing out will work the same way 
accross all browsers. This doesn’t mean this phasing out is planned anytime 
soon, but at least people will have received a fair warning for a long time 
when such phasing out will happen.


If you rely on synchronous xhr calls for your Java-to-Javascript converter, 
you would better schedule in the coming years a rewrite that makes use of 
async/await calls. 





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 are actually in the first 
category.


To be honest, it seems you just need to take a look at modern application 
coding best practices. There's nothing wrong with you giving your opinion --  
thanks for taking the time to do so! -- but there's nothing in the scenario 
you explained that requires a synchronous http request done on the main 
browser thread. Please trust us. 





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 think others are as well. We run
± into the usual time-budget issues, but if we can find someone who is willing
± to champion a particular cause (like form submission) I would be very willing
± to help that champion work through designs and shepherd them through the
± process.
± 
± CC'ing public-nextweb as this is the sort of stuff we love over there.

There's definitely something we should do about that. That being said, things 
have to be prioritized and I'm not sure overloading the FORM tag's behavior is 
absolutely necessary right now. Indeed, inheritage can always be emulated in 
ECMAScript using some Object.setPrototypeOf(...) magic and composition. 

It is very likely that [[ creating some x-form element ]] + [[ adding some 
real form element into its shadow dom ]] + [[ forwarding all events/method 
calls back  forth from the shadow to the main dom tree ]] + [[ hooking 
onsubmit to perform some pre-submit processing, to map non-input elements in 
the main tree into real input elements in the shadow tree ]] would to the trick 
to cover a large majority of the use cases. 

This is somewhat cumbersome but that would work, and doesn't seem to be an 
unsurmountable amount of work. Meanwhile, there are other problems in the 
platform that still lack any proper solution.

That being said, I'm open to review any proposal in that space, it is great to 
see the discussion rolling! My two cents would be that we could add some 
@@InputElement symbol that, when present on a tag, make it participate to the 
form submission process (aka, we use its name and value properties to add 
it to the request body).

Best regards,
François



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
Yes, having the InputStream and OutputStream interfaces would be great, and the 
“Stream” class could inherit from both. The important thing is that an external 
API can return either a readable or a writable stream, depending on what make 
sense for it.



Since JavaScript does not provide a way to check if an object implements an 
interface, there should probably exist a way to check that from the API, like:


   var stream = InputStream(s) // returns “s” if it’s an input stream, convert 
is into a stream if possible, or return null

   if(stream) { … } else { … }


That’s a great way 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.org





Hi François



On Thu, Oct 31, 2013 at 6:16 AM, François REMY francois.remy@outlook.com 
wrote:


- Streams should exist in at least two fashions: InputStream and OutputStream. 
Both of them serve different purposes and, while some stream may actually be 
both, this remains an exceptional behavior worth being noted. Finally, a 
Stream is not equal to a InMemoryStream as the constructor may seem to 
indicate. A stream is a much lower-level concept, which may actually have 
nothing to do with InMemory operations.




Yes. I initially thought it'll be clearer to split in/out interface. E.g. a 
Stream obtained from XHR to receive a response should not be writable. It's 
reasonable to make network-to-Stream transfer happen in background 
asynchronously to JavaScript, and then it doesn't make much sense to keep it 
writable from JavaScript.




It has a unified IDL now but I'm designing write side and read side 
independently. We could decouple it into two separate IDLs? concepts? if it 
make sense. Stream would inherit from both and provides a constructor.

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 exist in at least two fashions: InputStream and 
OutputStream. Both of them serve different purposes and, while some stream 
may actually be both, this remains an exceptional behavior worth being 
noted. Finally, a Stream is not equal to a InMemoryStream as the 
constructor may seem to indicate. A stream is a much lower-level concept, 
which may actually have nothing to do with InMemory operations.


- Secondly, the Stream interface is mixing the Stream and the 
StreamReader/StreamWriter concepts. I do not have a problem, if this is done 
properly, to mix the two concepts (aka most applications will want to use a 
StreamReader/StreamWriter anyway) but the current incarnation is not 
powerfull enough to be really useful, while still managing to be confusing.



As an actionable advice to the authors of the spec, I would recommend to 
have a look to the Stream API of other modern languages and how those API 
evolved over time. Streams exist for a very long time, it would be very 
unfortunate to repeat on the web platform the mistakes already made and 
fixed the hard way in competing platforms.





| Agreement to this proposal: a) indicates support for publishing a new
| WD; and b) does not necessarily indicate support of the contents of the 
WD.


Then, I agree to publish a new Working Draft, but this draft will need much 
futher refinement before being a w3c-recommendable specification. 





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 at all, then they're
 already broken for a lot of users, so making them broken for a few
 more shouldn't be a huge deal. ^_^

I can't name any currently-used mobile browser that doesn't ship with a 
*MatchesSelector function. The drop it proposal is to break code for the sake 
of breaking code. What is the point? We will soon have querySelector and query, 
and that didn't make the world fall into pieces...  
  


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 drop the prefixed version. This is 
possible, according to my definition of possible.

So, the question is: do we want browser to feature matchesSelector, 
blablaMatchesSelector or break stuff? My take would be we should prefer the 
former.

After that, it's just an opinion, now you have it do whatever you think with it 
;-)   


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 for this use case. We could obviously add a 
field to inverse the forward direction so that the roles nextNode and 
previousNode are reversed (in such case, you could use for-of in whatever 
direction, and even change the direction inside the for-of if needed, which is 
really nice).


 I'm fine with something that exposes TreeWalker's abilities to start
 from a given node, but that returns an ES iterator, like Domenic says.

If I'm not mistaken, all it takes for this to work is to add an .iterator() 
function on the TreeWalker/NodeIterator interface that would return an object 
calling nextNode() on the TreeWalker/NodeIterator and format properly the 
return values.


 Given that we can overload the arguments, as you describe, I'm okay
 with reusing the existing method for this.

So, let's sum this up. The proposed changes are:

- a new overload of createTreeWalker/createNodeIterator whose second argument 
can be a string representing a CSS selector, with the other arguments now being 
optional (not forced to pass null).

- a new 'cssFilter' field on TreeWalker/NodeIterator that would return the 
cssFilter used for pre-filter elements (or an empty string if none was given)

- a new 'iterator' function on TreeWalker/NodeIterator that would return an ES 
iterator (i.e. make TreeWalker/NodeIterator iterable with for-of support)

- a new 'iterateBackwards' boolean field on TreeWalker/NodeIterator that would 
make any ES iterator call previousNode() instead of nextNode() when computing 
the next iteration (to make navigation possible in both direction using ES 
iterators)


I would like to hear implementor feedback on this, but I bet the changes are 
not very hard to implement and would give a whole new light to the DOM 
Traversal types by making them actually efficient and natively usable from the 
ES6 world.

Is anyone willing to write the necessary spec changes or should I make a pull 
request on the Overview.src.html file to initiate the proposal discussion?  



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 selectors in replacement to the 
existing whatToShow flags {which are difficult to use and not entirely 
satisfying}, i.e. overloading the createTreeWalker/createNodeIterator functions 
to take a CSS Selector in the form of a string as a second parameter. 

 


var tw = document.createTreeWalker(document.body, “ul.menu  li”);

while(tw.nextNode()) {

   if(...) break;

   ...

}

 

Advantages:

 
It’s much faster than to use a javascript function as a filter that would call 
again the browser stack to find out whether a CSS selector match or not a 
specific element
 
We do not loose the ability to provide a more complex piece of javascript if we 
really need it, but we reduced the cases where we need one.
 
It’s less code to write (CSS is more efficient than any piece of JS)
 
It allows getting rid of the long named constants nobody likes to use

 

In addition, it would open huge optimization opportunities for the browser 
(like skipping siblings that look similar, not entering into descendants if 
it’s known a certain css class is not present among them, reusing cached lists 
of elements matching a selector, or whatever).

 

Thougths?

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 node. In my case, I want to start from a node and find 
the next/previous one (in DOM order) that matches some condition, so your 
solution isn't any useful to me.

Also, the concept of lazy list that doesn't get computed looks slightly weird 
to me, because qSA/getEB* are static list so they would need to be computed as 
soon as you make any DOM change, even if it just happens the list only exists 
in memory because the GC didn't collect it. Honestly, I don't see how that 
could work, except if calling .iterator() destroys the list (ie: make it empty 
if it had been computed, remove it from the compute queue otherwise) but this 
seems fragile to me.   


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 
way to walk the DOM from any starting point. The only stupid thing is that I'm 
forced to reduce my performance by doing this:

  var tw = document.createTreeWalker(region, ELEMENTS, function(e) { return 
e.matchesSelector() }, ...);
  tw.currentNode = myStartNode; if(tw.nextNode()) return tw.currentNode;  

which is suboptimal because the execution context switch back and forth between 
JS and the native engine all the time, and the native engine do not make use of 
the selector to prune the tree walking where it could.

Really, what I need is just plain that:

  var tw = document.createTreeWalker(region, x);
  tw.currentNode = myStartNode; if(tw.nextNode()) return tw.currentNode;

Feature detection, by the way, is not very hard. Try to create any treewalker 
with a string parameter and, if it fails, then polyfill by using previously 
shown method.

I don't get why everybody want to create something new that is a simple 
iterator and doesn't solve my use case while the current design solve my use 
case and just need to be improved dramatically from both the usability and 
performance point of view by adding the power of CSS selectors to it...

Is there any reason everybody hate TreeWalker?