Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122067
MIME-Version: 1.0
References: <756bcf2b-f98d-4203-9004-1cbfd402337a@gmail.com>
 <8632ff2a-0169-4cbb-b5d8-3bafb841f1ee@app.fastmail.com> <b3ae143b-537a-41b1-8e5a-13d02d2c16fa@gmail.com>
In-Reply-To: <b3ae143b-537a-41b1-8e5a-13d02d2c16fa@gmail.com>
Date: Sat, 30 Dec 2023 10:25:23 +0100
Message-ID: <CAPzBOBPqZz=QjHUGUoQGjFHwPzJ=zqvsEebyBnY=E_3YPqmYOQ@mail.gmail.com>
To: Niels Dossche <dossche.niels@gmail.com>
Cc: internals@lists.php.net
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] Pre-RFC: Fixing spec bugs in the DOM extension
From: landers.robert@gmail.com (Robert Landers)

Hi Niels,

> They are indeed going to be very similar, but at least having better return types would be good to give one particular example.
> e.g. we currently have a lot of methods that can return an object or false. The current living DOM spec always throws exceptions instead of returning false on error which is a much cleaner API.
> Furthermore, we have the DOMNameSpaceNode that can be returned by some methods and has been a point of confusion for static analysis tools (I did a PR on psalm to fix one of those issues).
> That node type won't be special cased in the new classes API so the (inconsistent use of the) union of DOMAttr|DOMNameSpaceNode will go away.

Actually, I'm not sure it is supposed to be throwing exceptions (if we
look at https://html.spec.whatwg.org/multipage/parsing.html#parse-errors);
in fact, I'd argue there are three different ways to handle errors
(from some experience in writing a parser from scratch):

1. Acting as a user-agent: in this case, errors should be handled as
described in the spec for a user-agent, e.g., switching to Text-Mode
in some cases and gobbling up the rest of the document.

2. Acting as a conformance checker: in this case, a list of errors
should be available to the programmer instead of bailing when parsing
(e.g., not switching to Text-Mode, but trying to continue parsing the
document, as described in the parser spec for conformance checking).

3. Acting as a document builder: Putting the document into an invalid
state should emit at least a warning. However, it's likely better to
let the user-agent handle the invalid DOM (as this is probably more
forward-thinking for new HTML that currently doesn't exist). This is
actually one of the biggest draw-backs to the current implementation
as it requires a number of "hacks" to build valid HTML.