On Tue, 26 Feb 2008 23:20:59 +0100, Doug Schepers <[EMAIL PROTECTED]> wrote:
Hi, Simon-
Simon Pieters wrote (on 2/26/08 12:39 PM):
On Tue, 26 Feb 2008 17:27:01 +0100, Doug Schepers <[EMAIL PROTECTED]>
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
