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