So...we discussed 31 e-mails, time to try to reach a consensus? Please
keep in mind, it's too obvious to everyone but you don't have to agree
to build a consensus. We can build a consensus if all can live with
single conclusion.
3 proposals so far:
Proposal A: Leave it undefined. If it's not
I thought a bit of the same thing as Tab when I saw the visual focus
discussion in CSS WG, but my current conclusion is not to think the
two the same thing. Focus may be possible, but selections is a
different thing.
It's true that you could use multi-range selections to select in
visual order.
On Sat, Jan 24, 2015 at 9:52 PM, Olli Pettay o...@pettay.fi wrote:
Right now the liveness doesn't really cause issues, since only some UAs
support it.
But that doesn't mean getRangeAt should return cloned ranges.
Adding another getRange*At would just pollute the API.
The more I think this,
On Thu, Jan 22, 2015 at 12:20 AM, Mats Palmgren m...@mozilla.com wrote:
If we really want authors to have convenience methods like
setStartBefore() on Selection, we could add them to Selection.
Selection methods wouldn't provide the same functionality though.
Selection.setStart* would
As in the thread Ben split, I think it's just Aryeh omitted in the current
spec focus. Visual Studio supported multiple selections in version 11 or
so. MS Word, I don't remember, but probably version 9 or 10. I agree that
it's a great feature, but also agree with Aryeh and Ben that we have a lot
you want, and they will expect that the range's new start will be
exactly what they set it to.)
On Wed, Jan 7, 2015 at 12:08 PM, Koji Ishii kojii...@gmail.com wrote:
I also guess that we need to ask more work to the spec editor to
support the liveness, such as:
My old spec had no trouble
While I agree that it's nice, I have mild preference to return a
clone. As Olii said, changing from clone to live would involve quite a
bit of code. I feel sorry for already implemented people though.
I also guess that we need to ask more work to the spec editor to
support the liveness, such as: