dojo.attr should handle innerText

[Mike Wilcox]

innerText is an important property to handle, as it strips HTML from the contents of a node. It also needs Dojo's assistance to be xbrowser, since FF's version is textContent.

I'm not submitting a patch unless this suggestion is ok'ed. The problem is that this enhancement would add quite a few bites. The _attrProps alone would need the following:

textcontent:dojo.isFF ? "textContent" : "innerText", innertext:dojo.isFF ? "innerText" : "textContent"

and then the setting portion of dojo.attr() would need it's "if" statements restructured a bit.

[dante]

@uhop: does this fall in line with your overall attr() normalization?

[Mike Wilcox]

It should be noted from recent tests I've done that textContent on Firefox is hampered by tab spaces and line breaks, and the results are much different from IE. A lot of string parsing would be required for it to work properly.

[Eugene Lazutkin]

Moving open tickets to the future.

[Mike Wilcox]

Gavin Doughtrie sent this link to dojo.dev, as a reference to how Google handles this: ​http://code.google.com/p/doctype/wiki/ArticleSetTextContent

I did a little research and went to the source, and found how Mozilla suggests doing it: ​https://developer.mozilla.org/En/Whitespace_in_the_DOM

A key to the Mozilla article is finding spaces with "\u0020" instead of \s, as the latter will remove spaces that would appear in between words.

What a pita. Why don't they just have innerText??

[Eugene Lazutkin]

Typo --- it is Gavin Doughtie. The link he gave is to the code licensed under BSD.

[Eugene Lazutkin]

I need more information on this as Microsoft's documentation doesn't define the behavior of innerText (​http://msdn.microsoft.com/en-us/library/ms533899(VS.85).aspx):

1. What is the use case for innerText?
2. Why stripping whitespaces? Does innerText strip whitespaces too? I know that FF creates a bunch of whitespace text nodes between elements. I am asking about other text nodes.
3. Do we need to strip HTML markup from the text on assignment?
4. How to handle IE's read-only innerText properties? With innerHTML it was kind of obvious.

[Mike Wilcox]

The idea would be to leave innerText to function as normal, since all browsers support it except Firefox. I would imagine trying to set read-onlys should fail naturally.

I don't have a use-case for this. The idea stemmed from a blog I wrote on attr() and this seemed like an obvious omission. I've not actually need this functionality except for some very complex stuff where I should just write the code on my own anyway.

I originally thought it was just an even swap between innerText and textContent, but it appears to be more complicated than that. I would recommend changing this ticket to Won't Fix.

[Eugene Lazutkin]

Closing as wontfix for now. Please reopen, if there is a need for such functionality.

[Mike Wilson]

(Reopening because you told me so ;-)

From time to time I need this functionality and I usually put together my own function inline. Would make sense to handle in Dojo IMO. The typical use case is displaying a text string (that may contain HTML-unsafe characters) in an element without having to escape it.

I was actually checking dojo.attr in the Dojo source for this support, but while doing that I came to think that maybe it is not the perfect place for "innerText" handling, as this is not really an attribute and would hide an attribute of the same name? (unlikely, but anyway...)

[Mike Wilson]

Btw, jQuery's text() function is something along these lines. ​http://docs.jquery.com/Attributes/text

[James Burke]

Note that dojo.NodeList?-traverse offers a text() function that should mimic jQuery's equivalent.

[Mike Wilson]

That's interesting, I hadn't seen that. That makes it even more natural to add this functionality somewhere to the Dojo APIs so I can use it directly on an available DOM element without having to create a NodeList? or query first?

[Eugene Lazutkin]

Dup of #10291.