XPath Dependency

[ScottFreeCode]

Most browsers these days have XPath built in, and apparently at one time Internet Explorer had XPath builtin using a different interface than the now standard one (it probably predated the standard as usual). However, since then the API shim for IE's non-standard XPath interface no longer works. These links suggest XPath was removed from IE at some point (or at least that this way of getting to it no longer works -- or maybe what this library was using to get it never worked? I can never tell with non-standard extensions):
http://stackoverflow.com/questions/13521554/dom-level-3-xpath-in-internet-explorer
http://stackoverflow.com/questions/15743049/xpath-incompatible-with-internet-explorer

As far as I can tell, what this comes down to is that to use Tranjsform and have it be compatible with some versions of IE a third-party XPath library that supplies document.evaluate is needed (that or there's a hidden dependency on acquiring your DOM pieces the "right" way so that they'll include the IE-specific XPath functions, but there's nothing more brittle than hidden dependencies like that, so I'm going to assume the library solution is a better option). Frankly, I don't mind that. But -- and this is the part I'm opening this issue for -- it would be helpful to document it at least (maybe suggest good JS XPath libraries; I used the WGX suggested in the links above and did fine). (It also may require some code tweaks to work with a library solution without breaking other browsers' builtin solutions; I have these as part of a set of IE fixes submitted by pull request #3.)

[TRPB]

I think a bettter way of doing this will be using document.querySelector and then manually implementing the pseudo selectors. This would remove any dependency on XPath and querySelector is now widely supported.

[ScottFreeCode]

Getting the selectors to use builtin CSS support would be great; that should really expand the supported CSS selectors. Are you thinking of stripping the Transphporm/Tranjsform-specific logic out of the TSS selector and then passing what's left to querySelector[All], or of refactoring the TSS selector design so that the selector part is pure CSS and the rest is actually written somewhere else (except maybe selecting attributes; although, since attributes can't have all the same template commands applied to them maybe they should be targeted at the command level anyway)? I have a couple ideas about how that could be done, I've been mulling over some thoughts about separation of concerns and selecting elements vs. all the other logic involved in this out-of-line type of templating. Anyway, either one would make it possible to leverage existing CSS implementations, but the latter, if you also had an interface for supplying/choosing the selection function (or something more object-oriented to that effect?), would make it easier to port to other languages because existing selector libraries could be used, and would make it possible to use other selectors directly as well. For instance, I could use an XPath to find the element in the template based on tests about its children (not possible in CSS), or on some qualities of its text content (e.g. contains "Account List"; also not possible in CSS), or to find two different types of elements without repeating the parts of the selector that are the same (CSS only has "," for chaining multiple selectors and it only applies at the top level). Or if next decade some as-of-yet unheard-of selector becomes popular in XML/HTML, it would be easy to add support for it because the selector is decoupled -- just implement (or shim in an existing implementation for) the new selector type, and presto, they're another choice available.

(Not directly on topic here, but any other thoughts on #3?)

[TRPB]

What I was planning on is letting transphporm manually implement pseudo selectors (split on :) and attributes (split on [ and ]) this would allow transphorm to handle data() and iteration() pseudo elements and attributes but let querySelector handle everything else. This also allows us to implement [foo!=bar] and other comparisons that native CSS cannot do.