W3C home > Mailing lists > Public > www-dom@w3.org > January to March 2008

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

From: Michael A. Puls II <shadow2531@gmail.com>
Date: Fri, 11 Jan 2008 10:23:10 -0500
Message-ID: <6b9c91b20801110723j75412c51oef1c121545c5a9c6@mail.gmail.com>
To: "Brad Pettit" <Brad.Pettit@microsoft.com>
Cc: www-dom@w3.org

On 1/10/08, Brad Pettit <Brad.Pettit@microsoft.com> wrote:
> According to the DOM 1 Core spec, the value of an Attr Node in string form (with entities expanded) is Attr.value. The childNodes collection is a list of Text and EntityReference nodes, so it could have a length > 1. As you said, setting the value should create a TextNode child with the unparsed string.
> If you want to access the expanded text value of an attribute, you should use Attr.value.

(note that I'm guessing below)

Well, I was able to do this, but it only works in Safari, but Safari
treats it like "magic" isn't a known entity and therefore "zam" is
missing from the result. I also had to append to an element instead of
an attribute node because appending to attribute nodes is not allowed.


<!DOCTYPE html [<!ENTITY magic "zam">]>
<html xmlns="http://www.w3.org/1999/xhtml">
            window.addEventListener("load", function() {
                var x =
document.createElementNS("http://www.w3.org/1999/xhtml", "div");
            }, false);
        <p>With Javascript on, you should see zip&magic;bam below.</p>

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.

None of them allow appending a text node (or an entityReference node)
to an Attr node either and throw no_modification errors.

>From what I gather, I should be able to do this:

<!DOCTYPE x [<!ENTITY magic "zam">]>

var a = document.createAttribute("test");

so that a.value = "zipzambam", and I would do it that way because *just* doing:

a.value = "zip&magic;bam" (In a cdata script block so the &magic;
isn't resolved on me during parsing)

would cause a.value to return "zip&magic;bam" instead of "zipzambam".

Which means, that if I wanted an entity to be resolved/expanded, I
can't add it in the string (because it will just be treated literally)
and I must create an entity reference instead.

If so, that makes sense, but it doesn't seem to work in browsers, not
even with plain XML and especially not with Attr nodes.

Is my understanding correct here?

Is there an XML engine I can test with to see this stuff actually working?

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?


Received on Friday, 11 January 2008 15:23:16 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:13 UTC