Re: [RFC] Decoding HTML and the Ambiguous Ampersand
| From: | Christoph M. Becker | Date: | Sat, 24 Aug 2024 12:47:43 +0000 |
| Subject: | Re: [RFC] Decoding HTML and the Ambiguous Ampersand | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-125181@lists.php.net to get a copy of this message | ||
On 23.08.2024 at 01:02, Dennis Snell wrote:
>> If we could have a single implementation, that would be great. I do understand of course
>> your concern that DOM is not a required extension, and therefore basing the internals on Lexbor
>> makes it tied to the DOM extension which may not be available. I however suspect that a large chunk
>> of people needing a function like this have DOM available (as DOM is required by many
>> HTML-processing-related packages). I can also look into it sometime soon if you want; anyway feel
>> free to ping me.
>
> I’m also very open to lexbor-based approaches but I’ve so-far found it more complicated
> than I expected. In some part this is because it involves setting up the parser and state machine
> for the HTML specification and much of the actual decoding can be safely done without this.
>
> The other part is the extension aspect. I hear you, that you would expect calling code to have
> the DOM extensions available, but that’s simply not the case when developing a platform like
> WordPress, which I do. We don’t have control over the servers or environments where people are
> deploying this, and the availability of the DOM extensions is low enough that WordPress code simply
> cannot use
DOMDocument (even though it shouldn’t because of the
> wild problems that has for attempting to parse HTML).
>
> People resort to html_entity_decode() because that’s the only
> option. In WordPress we now have a spec-compliant decoder, but as it’s in user-space PHP its
> performance is far below what’s possible.
>
> I’d love your help in setting up lexbor’s state machine to decode text nodes. I’d love it
> even more if this could be part of the PHP language. It constantly surprises me that _the language
> of the web_ (PHP) doesn’t have the tools to speak _the language of the web_ (HTML). This RFC is
> all about taking a step towards ensuring that PHP developers can rely on PHP to be a reliable
> middle-man between the HTML domain and the PHP domain.
>
> In other words, requiring the DOM extension or DOM\HtmlDocument
> would be such a non-starter for WordPress (accounting for 43% of the web today) that it would
> completely unavailable.
Well, I don't think it would be a big deal to move the bundled lexbor to
somewhere where it is always available. I mean, so far it's only used
by ext/dom so it's bundled there, but if other parts of the php-src code
base would use it, we could put it elsewhere.
Christoph