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

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

From: Ryosuke Niwa <rniwa@apple.com>
Date: Sat, 12 Apr 2014 16:08:12 -0700
Cc: "public-webapps@w3.org" <public-webapps@w3.org>
Message-id: <59F4BF86-7F43-424E-9E63-C8307012E9CA@apple.com>
To: Boris Zbarsky <bzbarsky@MIT.EDU>

> On Apr 11, 2014, at 9:29 PM, Boris Zbarsky <bzbarsky@MIT.EDU> wrote:
>> On 4/11/14 10:09 AM, Domenic Denicola wrote:
>> - https://www.w3.org/Bugs/Public/show_bug.cgi?id=13145
>> - https://web.archive.org/web/20121127212525/http://aryeh.name/spec/innertext/innertext.html
> 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.

Thanks for the pointer. I wasn't aware that there was a disagreement as to what innerText should do.

>From clipboard/selection API perspective, we need to serialize based on CSS box tree (e.g. generated contents should be included) for copy & paste.

If we don't want innerText to do the same, we probably need to spec. something entirely different for innerText and copy & paste.

>> The work already done on this might make including innerText-dependent features more feasible.
> innerText is not particularly interoperable even across UAs that implement it, last I checked....

Definitely not interoperable.  But we can probably come up with some sensible spec. for it since websites don't tend to depend on each non-interoperable implementation of innerText unlike execCommand.

- R. Niwa
Received on Saturday, 12 April 2014 23:08:40 UTC

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