I believe we should design this with multiple Ranges in mind. Otherwise multiple selection requires a lot of work in javascript. Even if we don't actually support multi-selection in V1, we should not block it for a future spec.
-----Original Message----- From: Joanmarie Diggs [mailto:jdi...@igalia.com] Sent: Wednesday, November 12, 2014 12:15 PM To: public-webapps@w3.org Cc: W3C WAI Protocols & Formats Subject: [Selection API] Plans regarding multiple ranges? Hi all. The current draft of the Selection API states: This specification follows non-Gecko engines in restricting selections to at most one range, but the API was still originally designed for selections with arbitrary numbers of ranges. This explains oddities like the coexistence of removeRange() and removeAllRanges(), and a getRangeAt() method that takes an integer argument that must always be zero. If things change and multiple ranges are supported, there may (or may not) be associated accessibility needs to address or techniques to create. If multiple ranges are not supported, then there are clearly not such needs or techniques. So before we (PFWG) give it more thought, do you happen to know what your plans are for multiple ranges? In particular, if some non-Gecko engine added support for multiple ranges, would your API change to reflect that? Or are the corner cases just too unpleasant? Thanks in advance. Take care. --joanie
