On Sat, Feb 17, 2024, at 5:11 PM, Niels Dossche wrote: > Hi internals > > After (and if) my current in-voting RFC about spec-compliance DOM > passes, some features become more easily possible to implement due to > the necessary building blocks becoming in place in the extension code. > > I would like to start implementing those. Therefore, I'd like to gauge > the opinion of the community on the following two features before > making an actual RFC and sitting through the process again. > > 1) Helper functions for CSS classes (i.e. classList). Requested here: > https://github.com/php/php-src/issues/11688 > > This feature would add the DOMTokenList class along with the classList > property to the Element class. > It exists to ease the managing of CSS classes on elements, i.e. it > deals with whitespace, duplicate class names, etc all for you using a > simple set-like API. > > I expect that implementing this into the DOM extension is not too > difficult, as the spec steps are really straight-forward [1] and we > just have to reuse the internal APIs to manage attributes. > > 2) Built-in CSS selector API support > > In particular, Element::querySelector(All), Element::matches, and > Element::closest support. > For "old DOM" there is a trick to at least implement querySelector(All) > in userland, and that is to translate the selector to XPath and use > XPath queries internally. However, that's slower and more cumbersome > than a native implementation. It's also just silly to not have this > natively available since it's so commonly used. > > I have a prototype implementation of this already actually, because I > got bored while fixing spec-compliance issues and wanted some funner > stuff to do. It's based on Lexbor's CSS support. > > > Kind regards > Niels > > [1] https://dom.spec.whatwg.org/#interface-domtokenlist
I feel like the CSS-based querySelector() was discussed not that long ago. Was it by you? Lexbor sounds familiar. Either way, I'm +1 on including a CSS selector natively. --Larry Garfield
