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
