This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
As discussed in this whatwg thread in February: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-February/030179.html 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: https://bugzilla.mozilla.org/show_bug.cgi?id=264412
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.
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: http://aryeh.name/spec/innertext/innertext.html 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?
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.
"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: http://lists.w3.org/Archives/Public/public-html/2011Jul/0133.html 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.
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> }
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.
Okay, so hober has responded for WebKit: http://lists.w3.org/Archives/Public/public-html/2011Jul/0430.html 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): http://lists.w3.org/Archives/Public/public-html/2011Aug/0014.html
mass-move component to LC1
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.
Agreed. Who wants it?
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.
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.
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.
*** Bug 25159 has been marked as a duplicate of this bug. ***
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...
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.
It would be very nice to attempt to specify this without any rendering-dependence and see if that might be Web compatible, though.
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.
Oh, I wasn't aware that WebKit developers had considered and rejected that idea, do you have a link to that discussion?
Have you done any testing, or how are you confident that it would be web-compatible-ish?
(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...
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.
(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! :)
Spec proposal here: https://github.com/rocallahan/innerText-spec
It seems this discussion moved here: https://github.com/whatwg/compat/issues/5 Resolving this bug as such.