Re: Should Attr nodes store their values in a child text node?

On 1/14/08, Kartikaya Gupta <kagupta@rim.com> wrote:
> Your last couple of messages seem to agree with (at least my
> interpretation of) the spec.
>
> > In Firefox, createEntityReference is present, but it returns null,
> which
> > causes a pointer error when you try to append it to anything.
> >
> > Opera doesn't support createEntityReference.
>
> From http://www.w3.org/TR/DOM-Level-2-Core/core.html, under the
> description for "createEntityReference", it says that the implementation
> should throw a NOT_SUPPORTED_ERR if the document is an HTML document. So
> I guess I was wrong in my original statement; HTML documents aren't
> allowed to have entity references. However, full XML documents should be
> allowed to have entity references, and so attribute nodes there should
> allow child nodes that are entity references.
>
> > Anyway, what I'm getting at is that if browsers don't support entity
> > references in Attr nodes, then there's not much use for browsers
> having a
> > child text node. Just using .value or .nodeValue to get the attribute
> > value as a string should be fine.
> >
> > Or, do you think that regardless, a child text node should still be
> > created and made available for acess like Safari and FF do?
>
> It does appear that current browser implementations do not fully support
> this DOM functionality, and that just using .value and .nodeValue is
> probably fine.
>
>
> > But, if there's no doubt that a text node should be created and
> > revealed with Attr.firstChild and Attr.childNodes[0] in all cases,
> > then I guess it's just a bug in Opera. (Looking for more comments
> > still though just to be sure.)
>
> Agreed, that makes sense.

Thanks for the input.

-- 
Michael

Received on Tuesday, 15 January 2008 00:13:44 UTC