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.
- 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.
- 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
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.
- Helper functions for CSS classes (i.e. classList). Requested here:
https://github.com/php/php-src/issues/11688This 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.
- 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
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
Hi Larry
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.
- Helper functions for CSS classes (i.e. classList). Requested here:
https://github.com/php/php-src/issues/11688This 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.
- 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
NielsI feel like the CSS-based querySelector() was discussed not that long ago. Was it by you? Lexbor sounds familiar.
I have mentioned it in the past, I couldn't find another discussion specifically about it on externals.io.
So it was probably me :-)
As for Lexbor, I did mention it both in my current RFC and previous RFC.
In short: it's the library allowing us to have HTML5 support.
Cheers
Niels
Either way, I'm +1 on including a CSS selector natively.