Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122437
Message-ID: <1b619316-9c28-4a58-beeb-3102ce214b1d@gmail.com>
Date: Mon, 19 Feb 2024 19:28:28 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] New ext-dom features
To: internals@lists.php.net
References: <1b2384c8-bb93-435f-975f-5904297c46be@gmail.com>
 <a76d6ec7-bd32-4061-bf09-c2bd4c410bcc@app.fastmail.com>
Content-Language: en-US
In-Reply-To: <a76d6ec7-bd32-4061-bf09-c2bd4c410bcc@app.fastmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
From: dossche.niels@gmail.com (Niels Dossche)

Hi Larry

On 18/02/2024 18:25, Larry Garfield wrote:
> 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.

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.
>