Overriding .textContent of BR elements

[Csaba Gabor]

In my Firefox 1.5 (on Win XP Pro) a <BR>
element's .textContent returns the empty string.
I have no idea why they (W3C) construed this to
be reasonable, but it was contested, and denied
here:
https://bugzilla.mozilla.org/show_bug.cgi?id=316063

Boris suggests doing something else to get what
I believe most users are really after, but doesn't
say what. Here's a possible approach, with initial
tests working in my FF1.5:

HTMLBRElement.prototype.__defineGetter__("innerText",
function() {return "\n";});

Node.prototype.__defineGetter__("innerText",
function() {
if (!this.firstChild) return this.textContent;
s=this.firstChild;
var res=s.innerText;
while (s=s.nextSibling) res+=s.innerText;
return res; });


However, it would be FFFFAAAAAAARRRR nicer
to simply redefine .textContent on the
HTMLBRElement.prototype and not muck about
with innerText, all on account of the <BR> element
adhering to a standard (whose reasonableness
on this point escapes me). However, the following
line is ignored as far as I can tell - any ideas?:

HTMLBRElement.prototype.__defineGetter__("textContent",
function() {return "\n";});


Thanks,
Csaba Gabor from Vienna

 

[David Mark]

In my Firefox 1.5 (on Win XP Pro) a <BR>
element's .textContent returns the empty string.

And what more did you expect it to return?

 

[Thomas 'PointedEars' Lahn]

In my Firefox 1.5 (on Win XP Pro) a <BR> element's .textContent returns
the empty string.

JFYI: Firefox 3.0.3 is the currently stable version. The 1.5 branch reached
its end of life on 2007-05-30 CE with the release of Firefox 1.5.0.12, and
2.0 will in mid of 2008-12 CE.

I have no idea why they (W3C) construed this to be reasonable,

,-<http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html#Node3-textContent>
|
| This attribute returns the text content of this node and its descendants.
| [...]
| Node type Content
| --------------------------------------------------------------------------
| ELEMENT_NODE, concatenation of the textContent attribute
^^^^^^^^^^^^
| ATTRIBUTE_NODE, value of every child node, excluding COMMENT_NODE
| ENTITY_NODE, and PROCESSING_INSTRUCTION_NODE nodes.
| ENTITY_REFERENCE_NODE, This is the empty string if the node
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| DOCUMENT_FRAGMENT_NODE has no children.
^^^^^^^^^^^^^^^^

but it was contested, and denied here:
https://bugzilla.mozilla.org/show_bug.cgi?id=316063

Boris suggests doing something else to get what I believe most users are
really after, but doesn't say what. Here's a possible approach, with
initial tests working in my FF1.5: [...]

..oO(*yawn* Why, is it April 1 again, already?)

The content model of BR/br elements is EMPTY. (To make that more clear
to you: That means it is like a born eunuch; it has no and can not have
[natural] children. [Well, you asked for it.])

If you want to insert an element node or text node *before* or *after* a
BR/br element, just do so:

br.parentNode.insertBefore(foo, br);

or

br.parentNode.insertBefore(foo, br.nextSibling);


HTH

PointedEars