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

[Boris Zbarsky]

On 2/3/11 8:25 PM, Aryeh Gregor wrote:
> innerText seems like a reasonable place to put such an API, if only
> because WebKit already does it.  It's not ideal a priori, but by the
> consistency standards of the web platform it's not noticeably bad.  I
> should particularly point out that your typical author is not going to
> have the foggiest notion of separation of DOM and CSS and so on -- it
> will make intuitive sense to authors to have it at innerText as much
> as anywhere.

Until they try to use it on a disconnected subtree and it does something 
weird, right?

> Actually, if browsers are willing to converge on making innerText work
> like textContent and Selection.toString() work like Range.toString(),
> I'd be okay with that.

Why is that useful, though?  You can already do that with textContent 
and toString.

> Gecko (at least that portion that
> I'm talking to :) ) seems to be skeptical of implementing anything
> very complicated here either.

What I'm skeptical of is standardizing this behavior today, because I 
feel like the result will be very confusing for authors...

> But Maciej has told me that WebKit
> doesn't want to scrap its elaborate plaintext-conversion APIs (which
> have by far the best fidelity of any browser's from what I see).

I assume Maciej has particular use cases for them in mind?

> (Possibly with minimal differences for web-compat -- Opera's behave
> slightly differently, and IIRC I was told it's for web-compat
> reasons.)

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.  It's not clear to me why we want to suddenly standardize 
whatever half-baked stuff they have implemented "for web-compat" right 
now.  I do think having an informative note about the web-compat 
constraints is a good idea, to aid those who may wish to implement this 
API after all.

> On the other hand, if WebKit is unwilling to accept anything other
> than a complicated plaintext conversion algorithm here, I don't think
> we're going to have interop in the foreseeable future no matter what.

Indeed.

> Even if it gets specced, no one will want to implement it.

That's not obvious to me.

> we can at least have everyone but WebKit converge on
> innerText/Selection.toString() behaving as similarly to
> textContent/Range.toString() as possible.

Why?  What's the point?

Or put another way, why is converting on innerText behaving like 
textContent better than converging on not having innerText at all?

-Boris