W3C home > Mailing lists > Public > public-webapi@w3.org > February 2008

Re: ElementTraversal comments

From: Simon Pieters <simonp@opera.com>
Date: Thu, 28 Feb 2008 14:48:40 +0100
To: "Doug Schepers" <schepers@w3.org>, "Web API WG (public)" <public-webapi@w3.org>
Message-ID: <op.t68lzetuidj3kv@hp-a0a83fcd39d2.palace.opera.no>

On Tue, 26 Feb 2008 23:20:59 +0100, Doug Schepers <schepers@w3.org> wrote:

> Hi, Simon-
> Simon Pieters wrote (on 2/26/08 12:39 PM):
>>  On Tue, 26 Feb 2008 17:27:01 +0100, Doug Schepers <schepers@w3.org>  
>> wrote:
>>> I'm not sure how I can make it more clear without imposing undue  
>>> restrictions on UAs.
>>  I'd suggest to take a similar approach as HTML5:
>>     The language in this specification assumes that the user agent  
>> expands
>>    all entity references, and therefore does not include entity  
>> reference
>>    nodes in the DOM. If user agents do include entity reference nodes in
>>    the DOM, then user agents must handle them as if they were fully
>>    expanded when implementing this specification. For example, if a
>>    requirement talks about an element's child text nodes, then any text
>>    nodes that are children of an entity reference that is a child of  
>> that
>>    element would be used as well.
> That is very specific, which is good.


> But I'm not comfortable with imposing such specificity on a UA,  
> especially for what I see as an edge-case.

Why not? Certainly implementors want precise rules?

> It may simply be ignorance on my part, but I don't know how all UAs  
> handle that situation,

Firefox, Safari and Opera all expand entities in the XML processor and  
don't support creating EntityReferences with DOM methods.

> and I don't have a good sense of what the implications of that are for a  
> UA that might behave differently.

If a UA keeps EntityReferences in the DOM, then nextElementSibling() etc.  
need to look inside EntityReference nodes for elements.

> HTML5 may be able to dictate terms like that, since it defines the  
> parsing model as well as the API, but I don't feel that DOM-related  
> specs should make such decisions.

The requirement cited has nothing to do with the parsing part of HTML5,  
since the parsing part doesn't create EntityReference nodes. HTML5 is also  
a DOM spec, and the requirement is, AFAICT, trying to solve the same  
problem as this thread is about.

> I don't feel extremely strongly about this, so if I got corroborating  
> feedback from more UAs (a non-browser UA that implement DOM would be  
> great), I'm willing to change my mind.  Alternately, I'm willing to  
> change the spec if that's the will of the WebAPI WG as a whole.

The current text seems wrong to me. An EntityReference might contain text  
followed by an element, or multiple elements, and so forth, but the spec  
only covers when it contains a single element, and seems to suggest that  
the EntityReference node itself should be used instead of the actual child  
Element node, which I think is intended.

Moreover, the cited requirement in HTML5 doesn't constrain implementation  

    * If the UA expands entities, just implement the spec.
    * If the UA keeps EntityReferences in the DOM, *act as if* they
      were expanded when implementing the spec.

What's the problem?

Simon Pieters
Opera Software
Received on Thursday, 28 February 2008 13:48:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:09:59 UTC