Open devseppala opened 9 months ago
It looks like a useful addition to HTMX. The easier it is for people to use what they already know, the better. Especially with this amount of change to the source code.
Here's an interesting thread on the WHATWG DOM repo about the recent state of affair about XPath integration in web browsers: https://github.com/whatwg/dom/issues/903
I just recently learned about htmx as it has gained much attention over the web. I immediately liked the concept as it feels like a move to a more sane direction in web development. However, as I quickly learned that htmx does not support XPath, I was a little dissapointed. XPath support was originally included in browsers with ajax based content swaps in mind, just what htmx does and it is a pity that htmx supports only CSS selectors.
After a little thinking, I thought that it would be a nice way to try to learn htmx by trying to implement support for XPath selectors. So I forked htmx to my own repository https://github.com/devseppala/htmxpath , started hacking and after a while got XPath selectors working. The following is a description of my XPath implementation, so it could be considered for a possible inclusion to htmx.
By using "!xpath:" prefix in front of the selector, the implementation allows XPath to be used in hx-select , hx-target and hx-swap-oob attributes. For example, hx-select="!xpath:/html/body/h1[2]" , selects the second h1 heading under the body element. I ran the test suite locally (npm run test) and 674 test passed (1 pending?). Passed tests include some new XPath specific cases.
Implementation details:
Some issues for consideration:
I would like to add that, that I am not really a web developer, nor have I built anything using htmx, My background is more in developing a Java, XML and XSLT based documentation system, where I have come to accustomed in using XPath. So, feel free to question my coding choices and to suggest improvements.
Below is a diff that highlights the changes that I have made to htmx.js 1.9.9 . As you see, this implementation does not add all that much new code to the library. I guess I could even trim away a few lines if needed.