This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 13145 - Spec Element.innerText
Summary: Spec Element.innerText
Alias: None
Product: WHATWG
Classification: Unclassified
Component: Unwelcome (show other bugs)
Version: unspecified
Hardware: All All
: P2 enhancement
Target Milestone: Unsorted
Assignee: Michael[tm] Smith
QA Contact: sideshowbarker+unwelcome
: 25159 (view as bug list)
Depends on:
Reported: 2011-07-05 15:29 UTC by Aryeh Gregor
Modified: 2015-10-19 07:40 UTC (History)
13 users (show)

See Also:


Description Aryeh Gregor 2011-07-05 15:29:30 UTC
As discussed in this whatwg thread in February:

I don't know what the status is of that thread, and don't see it at a glance on the list of pending e-mail feedback, so I'm filing a bug so I get a clear answer.

As I said in the thread, I recommend something like the following spec text for now:

  1. Let s be the empty string.

  2. For each descendant of the context node in tree order:

     1. If the descendant is a text node, append its data to s.

     2. If the descendant is a <br> element, append "\n" to s.

  3. Return s.

Setting should work the same as textContent.  I would also recommend a note encouraging authors to use textContent instead if available, because innerText is supported inconsistently -- Gecko doesn't support it as of now, and the other three browsers return very different values on getting for the same DOM.

As described in the thread: The behavior I suggest seems to basically match Opera.  Gecko doesn't implement innerText at all, and I found sites that don't work right in Gecko because of it.  I also found a site that sniffs for Firefox and uses textContent for it and innerText for everyone else.  IE9 and WebKit both do pretty-printing of the element contents, in a complicated and inconsistent way.  I didn't find any site that would break if innerText was defined the same as textContent, but Maciej said he was pretty sure some sites would break without the <br>-to-\n conversion, and Opera seems to do that.

Boris said he guessed he could live with my proposed definition.  Maciej seemed skeptical of WebKit changing.  I don't know what Microsoft thinks, but my personal guess would be they won't mind implementing the change in their next standards mode.

Gecko bug:
Comment 1 Anne 2011-07-06 08:32:04 UTC
We hit at least one compatibility issue with not excluding <script>. If we are not going to make this dependent on the render tree I would rather try to remove it.
Comment 2 Aryeh Gregor 2011-07-06 20:40:45 UTC
I've been told in no uncertain terms that it's not practical for non-Gecko browsers to remove.  Depending on the rendering tree to the extent WebKit does, on the other hand, is insanely complicated to spec in terms of standard stuff like DOM and CSS.  Also, it potentially breaks for detached nodes (WebKit behaves totally differently in that case).  I do have an abortive effort here:

But Gecko people seemed pretty unhappy about this kind of complexity and rendering dependence in a DOM property.  And on the other hand, I got the impression WebKit is reluctant to rewrite their innerText implementation at all.  So I'm figuring that the spec that will be implemented by the most browsers possible is one that's as simple as possible, basically just a compat shim.  If multiple implementers actually want to implement something like the innerText spec I started writing, I'd be happy to resume work on it, but that wasn't my impression.

Do you have a link to info about the <script> issue?
Comment 3 Jonas Sicking (Not reading bugmail) 2011-07-07 23:37:09 UTC
If webkit's behavior is implementation dependent enough that it's unlikely to get specced and implemented cross browser, and if webkit further is reluctant to change their implementation at all, there seems to be no hope of consistent behavior cross browser.

In that case I'd rather leave things as is, spec-wise, and hope that implementation converge with time.
Comment 4 Aryeh Gregor 2011-07-08 16:48:28 UTC
"As is, spec-wise" means there's no spec at all.  I don't think that's a good idea.  The response here makes it seem like both Microsoft and Mozilla would be okay with an approach like I outlined in comment #0:

Which is already something like what Opera does.  I'll wait for a response for WebKit and Opera in that thread, but if we can get a spec that three out of four engines are willing to implement, that's surely far better than the status quo.
Comment 5 Jonas Sicking (Not reading bugmail) 2011-07-08 16:54:04 UTC
Well, I'm not sure that Gecko is willing to implement something unless we know that all parties are willing to go that route. For us that would just be additional code that still doesn't produce cross-browser APIs. In fact, more than anything it's likely to break more sites that it fixes since there's likely a lot of pages out there that does:

if (foo.innerText) {
  <code that assumes webkit/IE behavior>
else {
  <code that uses something else>
Comment 6 Aryeh Gregor 2011-07-08 17:11:15 UTC
If anyone is actually doing "if (foo.innerText)" and running code that works in every browser but Gecko, then that just suggests there are more features that Gecko needs to support to match other browsers, no?  Gecko will probably break on other pages too in that case, so you should want to support those features anyway.  Codepaths that only work in one browser are to be expected and we have to work around them, but if a codepath can be written that works in every browser *but* one, that browser's the one that should change.

But we'll see what WebKit says.
Comment 7 Aryeh Gregor 2011-08-01 22:26:57 UTC
Okay, so hober has responded for WebKit:

The conclusion seems to be that WebKit isn't happy with anything as trivial as what I propose in comment #0, and Gecko isn't happy with anything as complicated as IE or WebKit does.  So my recommendation is that for now we go with something like comment #0 and see if browsers wind up converging in practice.  If we find significant problems, we can consider trying something more complicated at that point.  My post to the list on the subject was quoted by Maciej in full here (didn't show up in the archives itself because of From: address problems):
Comment 8 Michael[tm] Smith 2011-08-04 05:17:35 UTC
mass-move component to LC1
Comment 9 Anne 2011-08-14 09:14:26 UTC
FWIW, I think this should end up in DOM if we do not make it rely on layout and probably end up in Editing along with Selection if it does. HTML is not really the right place.
Comment 10 Ian 'Hixie' Hickson 2011-08-15 03:57:37 UTC
Agreed. Who wants it?
Comment 11 Aryeh Gregor 2011-08-15 18:48:58 UTC
The algorithm in comment #0 depends on HTML, specifically <br>.  How can it go in DOM if it depends on HTML?  Also, if it's specced as in comment #0, it will be useless legacy cruft, so we don't want to expose it on anything other than HTMLElement, since browsers don't support it on Element and there's no reason for them to start.  So if it's defined like comment #0, it should be in HTML.

I agree that if we want to do a complicated rendering-dependent definition, this should be in the same place as Selection, which should be the editing spec.  However, currently we're not doing that no matter what, because we have no one to write the spec text.

So if it's going to be specced anywhere right now, it should be in HTML, IMO.
Comment 12 Ian 'Hixie' Hickson 2011-11-24 23:00:12 UTC
But it depends on CSS too, right? Maybe it should be its own thing...

I don't plan to touch this in the coming year or so, for what it's worth. Marking this REMIND so that it doesn't drop off the radar entirely.
Comment 13 Ian 'Hixie' Hickson 2013-03-09 01:06:47 UTC
If someone has the cycles to spec this, please take it. Realistically, I don't see having the cycles to work on this any time soon.
Comment 14 Ian 'Hixie' Hickson 2014-09-17 02:36:05 UTC
*** Bug 25159 has been marked as a duplicate of this bug. ***
Comment 15 Travis Leithead [MSFT] 2014-10-22 22:39:02 UTC
Perhaps I could move this over to DOM Parsing and Serialization and take a stab at it there? IE has recently aligned out behavior more closely with WebKit for this API, so now might be a good time to write down that behavior and see where it goes...
Comment 16 Anne 2014-10-23 06:43:28 UTC
I don't think DOM Parsing & Serialization should cover features that depend on rendering. If we are going with the WebKit/Chrome behavior it needs to be in CSS/editing or some such.
Comment 17 Philip Jägenstedt 2014-10-23 14:33:36 UTC
It would be very nice to attempt to specify this without any rendering-dependence and see if that might be Web compatible, though.
Comment 18 Aryeh Gregor 2014-10-23 17:18:38 UTC
It definitely would be web-compatible in the sense of not outright breaking sites, but my understanding is WebKit (and probably IE too) isn't willing to do it.  In any event, that would just move the problem to the Selection stringifier, so it doesn't really solve anything.
Comment 19 Philip Jägenstedt 2014-10-23 21:12:16 UTC
Oh, I wasn't aware that WebKit developers had considered and rejected that idea, do you have a link to that discussion?
Comment 20 Philip Jägenstedt 2014-10-23 21:13:11 UTC
Have you done any testing, or how are you confident that it would be web-compatible-ish?
Comment 21 Travis Leithead [MSFT] 2014-10-23 22:21:08 UTC
(In reply to Philip Jägenstedt from comment #20)
> Have you done any testing, or how are you confident that it would be
> web-compatible-ish?

I'm pretty skeptical that it would be web-compatible to remove the dependency on layout--IE only came across our interop issue with webkit based on running into a site-compat issue, and our testing sample size is relatively small...
Comment 22 Philip Jägenstedt 2014-10-24 07:21:44 UTC
OK, I have no data at all so I can't argue with that. To be clear, my idea was to consider the element types, so that e.g. <p> and <br> would insert extra line breaks. That would work as long as people don't override the display property *and* depend on it, which seems to me at least worth investigating.
Comment 23 Aryeh Gregor 2014-10-24 11:40:48 UTC
(In reply to Philip Jägenstedt from comment #19)
> Oh, I wasn't aware that WebKit developers had considered and rejected that
> idea, do you have a link to that discussion?

(In reply to Philip Jägenstedt from comment #20)
> Have you done any testing, or how are you confident that it would be
> web-compatible-ish?

I don't remember specifically at this point.  The links to the relevant discussions are in the first comments in this thread.  My basis for saying it would be web-compatible without depending on rendering is the fact that Opera apparently got by okay for a long time using an extremely simple implementation, although apparently that wasn't perfect, as evidenced by comment 1.  Also, Gecko never implemented it at all last I checked, and very few sites break because of this.

(In reply to Travis Leithead [MSFT] from comment #21)
> I'm pretty skeptical that it would be web-compatible to remove the
> dependency on layout--IE only came across our interop issue with webkit
> based on running into a site-compat issue, and our testing sample size is
> relatively small...

Interesting -- what does that site do about Gecko?  Probably it has a separate code path with UA sniffing, or it's meant to be mobile-only and just breaks on non-WebKit.

Anyway, based on my research in 2011, my conclusion was that browsers could avoid breaking practically any sites using a simple non-rendering-dependent implementation.  Things may have changed in the last three years, or it may be you hit one of the few sites that really does depend on exact behavior here.  My recollection is that it didn't look like WebKit's implementation would be sane to replicate exactly in any other UA.  But obviously, if people want to pick up the work here and at least some UAs are willing to converge, great!  :)
Comment 24 Robert O'Callahan (Mozilla) 2015-10-19 02:48:53 UTC
Spec proposal here:
Comment 25 Anne 2015-10-19 07:40:42 UTC
It seems this discussion moved here:

Resolving this bug as such.