- From: Ryosuke Niwa <rniwa@apple.com>
- Date: Sat, 12 Apr 2014 16:08:12 -0700
- To: Boris Zbarsky <bzbarsky@MIT.EDU>
- Cc: "public-webapps@w3.org" <public-webapps@w3.org>
> 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