Helper functions for CSS classes (classList)

[dtdesign]

Description

The DOM extension of PHP lacks a couple of helper functions that have eased the life of frontend engineers for many years.

The lack of a proper handling of CSS classes was painful back in the IE6 days and while jQuery solved that to some degree, the addition of the .classList was a massive improvement. I would really love to see PHP adding support for a similar interface to ease the work with CSS classes.

Old additional content:

Another improvement would be the addition of [`append()`](https://developer.mozilla.org/en-US/docs/Web/API/Element/append), [`after()`](https://developer.mozilla.org/en-US/docs/Web/API/Element/after), [`before()`](https://developer.mozilla.org/en-US/docs/Web/API/Element/before) and [`insertAdjacentElement()`](https://developer.mozilla.org/en-US/docs/Web/API/Element/insertAdjacentElement). The first three functions are also special because they implicitly convert strings into text nodes. `after()` and `before()` are simple helper functions that improve readability instead of relying on some `insertBefore()` shenanigans on the parent element. `insertAdjacentElement()` is unique as it accepts a string (in PHP this would possibly be an enum?) for the position which itself can be the result of a simple match statement.

There is also replaceWith() that allows to swap out DOM nodes while preserving the original position in the DOM, but its arguably more niche of a use case.

[dtdesign]

You can disregard some of my suggestions because apparently I’m an idiot and completely missed https://wiki.php.net/rfc/dom_living_standard_api. The current stable version of our software still supports PHP 7.4 (new version with PHP 8.1+ is around the corner though) and I completely missed the progress that has been made here. Feels a bit like the post-IE6 era where out of habit I was still writing garbage JS despite having access to newer JS features …

[nielsdos]

Right. insertAdjacentElement is not implemented right now, but indeed append, after, before, replaceWith, etc are.
classList is not implemented atm and requires implementing DOMTokenList.

Also: please split unrelated feature requests into different issues. People can then give thumbs up on individual issues such that we can prioritise what to implement.

[nielsdos]

I'm going to edit your issue to split the feature request into the token list classList feature, and the insertAdjacent features.
The latter I have implemented here: #11700

[SVGAnimate]

Hi, we must distinguish the DOM of the libxml (ext/dom) and the CoreDOM used in the navigator which implements the events, the ShadowRoot, MutationObserver... Html like Svg uses CoreDom with additional modules.

The DOM of the libxml is a model object of the xml format while the CoreDOM (3.0 currently) is an implementation for web browser.

On the other hand, if you want to use CSS selectors instead of XPath, you must use a css extension compatible with the ext/DOM. maybe libcroco (CSS2.0)

If I had to make a request to improve ext/dom it would be DOMDocument::registerElementClass which will load a specific php class for each element (useful for building a model from an xml file)

How is classList part of ext/dom?

[nielsdos]

It's not specified which version of the DOM ext/dom follows, but the general idea is that it used to follow the W3C DOM spec. For recent features it follows the living WHATWG DOM spec, see https://wiki.php.net/rfc/dom_living_standard_api

The DOM of the libxml is a model object of the xml format while the CoreDOM (3.0 currently) is an implementation for web browser.

The fact that it uses libxml2 under the hood is an implementation detail.

How is classList part of ext/dom?

Because it's defined by the living WHATWG DOM spec.

[SVGAnimate]

I don't have the patience to check but it seems to me that the webkit is using libxml's xmlSAXHandler but not its DOM(equivalent ext/dom).

I think it's a mistake to confuse DOM(libxml dom) and CoreDOM Level 3(W3C - WHATWG now).

(I don't mind that helper functions are implemented)

[nielsdos]

What you're referring to as CoreDOM (Level 3) is the old DOM spec created by W3C that is no longer maintained.
The only surviving DOM spec right now is the living DOM spec. At one point that spec was snapshotted as DOM Core (Level 4). But it is continually updated without intermediate versions. Hence they call it the living spec.
So they're the same thing, just different versions.

[nielsdos]

Ah I get what you're saying now.

Libxml2 doesn't really define a DOM actually. ext/dom therefore doesn't follow libxml2's DOM.
The goal of ext/dom is to implement a DOM similar to that found in browsers. The goal isn't to include events or any feature solely useful for rendering (e.g. scrollIntoView etc), but to provide the features of the DOM necessary to manipulate the document. (see also that RFC I linked previously)
ext/dom already implements many functions from the CoreDOM/living spec. Adding classList would just add another one to the list of useful features.

[SVGAnimate]

Ok, I took the time to read your link. https://wiki.php.net/rfc/dom_living_standard_api

Voting Final Result: 37/37
I can't fight...

But I say : ext/dom is the DOM bindings of the libxml2.so library, carried out with less rigor.
If you want to follow the spec of https://dom.spec.whatwg.org/ there is a lot of work ahead of us

In other words adding this kind of function adds confusion.

that being said. I will adapt to the vision of PHP.
@nielsdos , for my information, do you know the library used to do querySelector() ?
(I mean by library a Css parser and a selector for the ext/dom)

[nielsdos]

there is a lot of work ahead of us

Indeed.

@nielsdos , for my information, do you know the library used to do querySelector() ?
(I mean by library a Css parser and a selector for the ext/dom)

It doesn't implement querySelector at the moment.
As a side note, a CSS parser isn't necessary to implement that functionality.