CARVIEW |
Select Language
HTTP/2 200
date: Thu, 09 Oct 2025 02:44:51 GMT
content-type: text/html
content-encoding: gzip
last-modified: Sat, 26 Aug 2023 22:11:03 GMT
cache-control: max-age=2592000, public
expires: Fri, 07 Nov 2025 14:47:28 GMT
vary: Accept-Encoding
access-control-allow-origin: *
x-request-id: 98b66eff9e46d22f
strict-transport-security: max-age=15552015; preload
x-frame-options: deny
x-xss-protection: 1; mode=block
cf-cache-status: HIT
set-cookie: __cf_bm=GOWlm1onmL4KWAyPesV65lHCl4Rm8TUonUcJrbrvWzk-1759977891-1.0.1.1-.n8peFbvJzJApKHCrAf.1YDR_B0QkJaaNyWxMci8UsxjbJ9HIOG9OFsNo9HSlMeKyUxLpYC2KmsUlHkX9mSrnfNVTLTX2dTQw6H3PQc_QoU; path=/; expires=Thu, 09-Oct-25 03:14:51 GMT; domain=.w3.org; HttpOnly; Secure; SameSite=None
server: cloudflare
cf-ray: 98ba89d9faf8e9c3-BLR
alt-svc: h3=":443"; ma=86400
[whatwg] Normalization of user selections from Ryosuke Niwa on 2011-06-15 (public-whatwg-archive@w3.org from June 2011)
[whatwg] Normalization of user selections
- From: Ryosuke Niwa <rniwa@webkit.org>
- Date: Wed, 15 Jun 2011 14:46:03 -0700
- Message-ID: <BANLkTik-SuV4yEiA71SkRNWhyRRxNNS8gg@mail.gmail.com>
On Wed, Jun 15, 2011 at 2:39 PM, Aryeh Gregor <AryehGregor at gmail.com> wrote: > > I originally thought the WebKit/Opera behavior was unreasonable, but > I've come around to thinking it makes more sense than IE/Gecko. It's > simpler and more consistent. If selections are always normalized, we > can ignore all sorts of crazy situations like boundary points in > comments, or between a character and a combining diacritic. If we > allowed such selections, we'd have to add extra spec text and code to > handle them reasonably, despite the fact that they're corner cases > that should only arise if the author manually sets the selection to > something weird. > WebKit's current behavior makes impossible to set selection inside an empty span (See https://webkit.org/b/15256) so we're planning to change WebKit's behavior sometime in the future to align with IE/Gecko. So I want to standardize some variant of the WebKit/Opera behavior, > and guarantee that selection boundary points are always > reasonable-looking (for some definition of reasonable TBD). This > would be a change to the existing spec text and the two biggest > implementations, however, so I'd like to hear what everyone has to > think before I start. > If we're taking this route, we must provide some way to work around issues like the one I listed above. - Ryosuke
Received on Wednesday, 15 June 2011 14:46:03 UTC