W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2012

Re: DOMParser Errors Should Be Exceptions

From: João Eiras <joaoe@opera.com>
Date: Wed, 23 May 2012 21:22:49 +0200
To: public-webapps@w3.org
Message-ID: <op.werz4bro2q99of@joaoe>
On Wed, 23 May 2012 21:08:32 +0200, Ms2ger <ms2ger@gmail.com> wrote:

> On 05/23/2012 09:03 PM, Yehuda Katz wrote:
>> In the current DOM parsing spec[1], errors in XML (or SVG) are handled  
>> as
>> follows:
>>
>>> Let root be a new Element, with its local name set to "parsererror" and
>> its
>>> namespace set to  
>>> "http://www.mozilla.org/newlayout/xml/parsererror.xml".
>>> At this point user agents may append nodes to root, for example to
>> describe
>>> the nature of the error.
>>
>> In practice, browsers implement error handling in this way. The output  
>> for
>> the following code is given below.
>>
>> (new XMLSerializer).serializeToString((new
>> DOMParser).parseFromString("<tr>hi", "text/xml"));
>>
>> As a result, jQuery looks for a parserror tag and re-raises an error  
>> when
>> parsing XML[2].
>>
>> In my view, the DOMParser should throw an exception, and not insert a
>> partially unspecified parserror tag.
>>
>> Thoughts?
>
> Opera has reported this is not web-compatible.
>
> Ms2ger
>

Opera thrown an exception long time ago and since version 9.5 it changed  
the behavior to return the bogus parsererror tree because it caused yahoo  
mail to fail back them (among other things).

While the current behavior of returning the parsererror document is  
inappropriate, I afraid it also unchangeable.
Received on Wednesday, 23 May 2012 19:23:20 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:52 GMT