Re: ElementTraversal comments

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.

Indeed.


> 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  
strategies.

    * 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