[whatwg] HTML-to-plaintext conversion (innerText and Selection.toString())

On 2/4/11 2:59 PM, Aryeh Gregor wrote:
> On Fri, Feb 4, 2011 at 10:32 AM, Boris Zbarsky<bzbarsky at mit.edu>  wrote:
>> Until they try to use it on a disconnected subtree and it does something
>> weird, right?
>
> Well, it shouldn't do weird stuff on a disconnected subree.  :)  It
> doesn't in IE.

I thought you said Webkit would refuse to implement that sort of behavior?

>> This whole thing seems to me like an exercise in premature standardization.
>>   Browsers are actively experimenting with their dom-to-text conversion APIs.
>>   It'd be nice if it were happening behind vendor prefixes, but they started
>> before such prefixing was popular in the DOM world.
>
> Authors are using these features

Yes, I realize that.

> and they're implemented inconsistently.

Yes, I also realize that.  That's what it means that UAs are experimenting!

> If browsers are experimenting and you think there's
> some chance that we'll eventually get a standardizable algorithm

I have no idea whether they will, because I'm still not sure what 
problems we're trying to solve here...

 > then I don't see why the new algorithm can't use a new prefixed name 
while
> we reserve the legacy names for legacy-compatible behavior.

Compatible with what legacy?  We have at least 4 different legacies 
here, right?

>  From what WebKit and Opera people have told me, innerText is necessary
> for web-compat for non-Gecko browsers.  There are sites out there that
> use textContent if they sniff Firefox, and innerText otherwise.

That's really unfortunate (esp. if they actually sniff for "Firefox").  :(

> innerText apparently can't be exactly the same as textContent --
> Maciej said that "I know that if<br>  doesn't produce newlines, stuff
> will break"

But the "Firefox" path takes the textContent and does its own newline 
processing or something?

> and Opera does add extra newlines for<br>  (but doesn't
> seem to change much else).

I could live with an innerText that was textContent but converted <br> 
to newline, I guess...

> I'm slightly less sure about Selection.toString(), but I'd be inclined
> to take the same general approach.  It's much better for authors to
> have to code around browsers not offering them enough features than to
> code around browsers offering them incompatible features.  At least
> then they only have to do the coding work once.

I still think it'll really confuse authors that Selection.toString() 
won't do the same thing as copying.  But maybe I overestimate the 
problems it would cause....

-Boris

Received on Friday, 4 February 2011 12:15:53 UTC