Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121185
Message-ID: <c79ac310-605a-482e-8c6e-a93b5812df3e@gmail.com>
Date: Fri, 29 Sep 2023 22:52:56 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: internals@lists.php.net
References: <c7a7f77b-8187-23f7-7c02-c92f1b538039@gmail.com>
 <48c7bb29-a52c-416e-b855-be2746dc7a84@gmail.com>
 <5ace1060-dd75-4cdc-b5e2-a2ea617df586@app.fastmail.com>
 <59bd7af5-937a-4240-9768-c620e387e8d8@gmail.com>
 <0fe18a09-14a7-41d2-982f-bca60c662249@app.fastmail.com>
Content-Language: en-US
In-Reply-To: <0fe18a09-14a7-41d2-982f-bca60c662249@app.fastmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: [RFC] [Discussion] DOM HTML5 parsing and
 serialization support
From: dossche.niels@gmail.com (Niels Dossche)

On 9/29/23 20:22, Larry Garfield wrote:
> On Fri, Sep 29, 2023, at 6:12 PM, Niels Dossche wrote:
> 
>>> Unclear to me: Would the XML constants also be aliased into the namespace verbatim, or left globally?  
>>>
>>
>> I'll clarify this.
>> The intention is to alias them verbatim.
> 
> :thumbs up emoji:
> 
>>> Did you consider making the new classes throw exceptions rather than forcing people to remember to call another "was there an error" global function like it's still 1996? :-)
>>
>> I did think about it.
>> Using exceptions for the parser is not viable. This is because parse 
>> errors in HTML aren't actually hard errors.
>> The errors are recoverable, i.e. the parser spec tells us how to 
>> proceed when an error occurred. So in a sense, they're closer to 
>> warnings. Using an exception would abort parsing.
>> As a side note, a good amount of the web pages out there violates at 
>> least one parsing rule, but browsers know by-spec how to proceed in 
>> that case (which is probably also why they're often not fixed).
>>
>> I thought about other options as well. E.g. providing a 
>> getParseErrors() method or letting the factory methods return parse 
>> errors optionally as well.
>> However, I think they're not significantly better than what we have 
>> now. Furthermore, I think overhauling how the parse errors are handled 
>> in ext/dom (and maybe by extension ext/simplexml to keep consistency) 
>> is a bit of a feature creep. See also the motivation in the RFC text.
>> Therefore, I would keep the error handling as it is described now in 
>> the RFC.
>>
>> If accepted, this RFC would land early in the 8.4 development cycle.
>> Therefore, we can gather feedback very early on. If we do notice a 
>> major problem in how these things are handled, they can be changed by a 
>> hypothetical future RFC in the same development cycle. That would also 
>> require thinking about the other XML extensions though.
> 
> All valid, thanks.  It would be helpful to include some mention of that in the Errors section to make it clear why exceptions right now are not an option, given the push elsewhere to get rid of the old error handling approaches in favor of exceptions.

Ack, will do! :)

> 
> --Larry Garfield
> 

Cheers
Niels