W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2014

Re: [Editing] Splitting Selection API Into a Separate Specification

From: Aryeh Gregor <ayg@aryeh.name>
Date: Sun, 13 Apr 2014 15:33:56 +0300
Message-ID: <CAKA+Axmw2FBVuJWVxx-NUVKf46FGs9NA9yy8HZniQVyNUimf-A@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>, Ryosuke Niwa <rniwa@apple.com>
Cc: W3C WebApps WG <public-webapps@w3.org>
On Sat, Apr 12, 2014 at 7:29 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> The outcome of that was basically that the WebKit folks wanted innerText to
> be some sort of complicated prettyprinting thing (which is nothing like the
> spec linked above) while Gecko was not all that interested in implementing a
> complicated prettyprinting thing that wouldn't even be compatible with other
> browsers' complicated prettyprinting things.

Selection.toString already needs to be a complicated prettyprinting
thing anyway, right?  So I don't see any particular downside in
reusing the algorithm for innerText.  IIRC, innerText always did
prettyprinting in all major engines that implemented it (i.e., IE and
WebKit), and some sites depend on some prettyprinting features (at
least converting <br> and block endings to a newline character).  So
if it's specced at all, I don't see any reason to make it different
from Selection.toString, which in turn needs to do pretty-printing to
match user expectations.
Received on Sunday, 13 April 2014 12:34:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:24 UTC