- From: Aryeh Gregor <ayg@aryeh.name>
- Date: Sun, 25 Jan 2015 13:57:51 +0200
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: Olivier Forget <teleclimber@gmail.com>, Ben Peters <Ben.Peters@microsoft.com>, Ryosuke Niwa <rniwa@apple.com>, Koji Ishii <kojiishi@gmail.com>, Webapps WG <public-webapps@w3.org>, Ehsan Akhgari <ehsan.akhgari@gmail.com>
On Sat, Jan 24, 2015 at 9:18 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote: > Though I believe browsers will soon have much more pressure to support > multiple ranges as a matter of course, as increased design with > Flexbox and Grid will mean that highlighting from one point to > another, in the world of "a range is defined by two DOM endpoints and > contains everything between them in DOM order", can mean highlighting > random additional parts of the page that are completely unexpected. > Switching to a model of "visual" highlighting for selections will > require multi-range support. > > In other words, it'll switch from being a rare thing to much more common. Most sites will probably not use flexbox or grid for a long time to come, and on sites that do non-contiguous selections will probably be rare, so I wouldn't rely on this as a mitigating factor. I once went through some common selection use-cases with the new selection API that I suggested before (returning a list of selected nodes or such), and for at least some common cases (like "wrap the selection in a <span>") it handled non-contiguous selections automatically, and was easier to use as well. For typical selection use-cases, the author wants to deal with the selected nodes anyway, not the endpoints.
Received on Sunday, 25 January 2015 11:58:41 UTC