Re: RFC from implementers on Element.innerText

On Aug 1, 2011, at 9:14 PM, Boris Zbarsky wrote:

> On 8/1/11 9:35 PM, Maciej Stachowiak wrote:
>> 
>> On Aug 1, 2011, at 3:01 PM, Boris Zbarsky wrote:
>>> So far the only proposal I've seen for Selection.toString is "do what the copy operation does", which is neither well-defined nor acceptable for innerText.  In my opinion.
>> 
>> If innerText fundamentally has to behave differently from Selection.toString
> 
> Oh, they could behave the same.
> 
> innerText just can't behave the way "copy" does and be specified at the same time, again in my opinion.  And that's because I strongly feel that browsers should be able to experiment with what "copy" does, especially as new HTML features are added.  On the other hand, messing too much with innerText as time passes is likely to cause web compat issues, I would think.

I agree that browsers should be able to experiment with and change what "copy" does. In principle this could even have platform-specific behaviors for the same browser. I think speccing Selection.toString() to say "do what copy does" would also be unacceptable because (a) it's underspecified and (b) it's likely to result in non-interoperable behavior for Selection.toString().

I guess my preference order would be:

1) If Selection.toString() and Element.innerText can be the same (or very nearly the same with perhaps a simple flag controlling a few necessary differences), that would be the best solution to spec.

2) If #1 is impractical, and a relatively simple solution is compatible with innerText-using content (including content that uses innerText conditionally, or avoids using it in Gecko-based browsers), then that seems like potentially the next-best choice.

3) If #1 and #2 are both impractical, then specifying fairly complex behavior for innerText that does not match anything else seems acceptable.

Regards,
Maciej

Received on Tuesday, 2 August 2011 06:50:47 UTC