Re: Re: [RFC] [Discussion] DOM HTML5 parsing and serialization support

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