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__("innerTex t",
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 <BRelement
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__("textCont ent",
function() {return "\n";});


Thanks,
Csaba Gabor from Vienna

On Oct 11, 11:46*am, Csaba Gabor <dans...@gmail.comwrote:

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?

Csaba Gabor wrote:

In my Firefox 1.5 (on Win XP Pro) a <BRelement'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.

<http://en.wikipedia.org/wiki/Mozilla_Firefox#Release_history>

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
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16

On 2008-10-11 17:46, Csaba Gabor wrote:

In my Firefox 1.5 (on Win XP Pro) a <BR>

FF 1.5 really shouldn't be used anymore, except for compatibility
testing. I would understand version 2.x (some people can't run 3.x
because of missing libraries), but 1.5 is ancient.

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

After reading that bug report, and the specs, it looks like that's the
correct and expected behavior. Inconvenient, maybe, but at least it's
consistent.

Boris suggests doing something else to get what
I believe most users are really after, but doesn't
say what.

(for reference)
| Comment #5 From Boris Zbarsky:
| [..] If you want an actual serialization, instead of just the
| textContent, you need to use something else.

I suppose he was talking about something similar to what you've done
with "innerText".

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

Using "innerText" as a getter name is a dubious choice for Firefox.
AFAIK, they still haven't implemented innerText in their DOM
implementation (in contrast to innerHTML), but they might do so in the
future, and then you'll get errors. You should also be aware that the
getter/setter behavior has changed in more recent versions of Firefox:

| Prior to Firefox 3.0, getter and setter are not supported for DOM
| Elements. Older versions of Firefox silently fail. If exceptions are
| needed for those, changing the prototype of HTMLElement
| (HTMLElement.prototype.__define[SG]etter__) and throwing an
| exception is a workaround.
| With Firefox 3.0, defining getter or setter on an already-defined
| property will throw an exception. The property has to be deleted
| beforehand, what is not the case for older versions of Firefox.

<http://preview.tinyurl.com/4wk75y>

Thanks,
Csaba Gabor from Vienna

Greetings to Vienna,


- Conrad