On Tue, Jan 27, 2015 at 4:49 PM, Koji Ishii kojii...@gmail.com wrote:
3 proposals so far:
Proposal A: Leave it undefined. If it's not causing interop issues, we
can leave it.
Proposal B: Clone.
Proposal C: Live.
I can live with any, but prefer B.
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
On Sun, Jan 25, 2015 at 1:31 AM, Mats Palmgren m...@mozilla.com wrote:
Gecko knows if a Range is part of a Selection or not.
Authors don't, I don't think. Of course, we could expose this info to
authors if we wanted, so that's not a big problem.
True, I'm just saying that I don't see any
On Sat, Jan 24, 2015 at 3:28 PM, Koji Ishii kojii...@gmail.com wrote:
Looks like we're in consensus that a) it doesn't really cause issues
today, and b) there are scenarios where live-ness is nice.
I don't agree that it doesn't cause issues now. Unless we want Range
methods to behave
On 01/24/2015 05:50 PM, Aryeh Gregor wrote:
On Wed, Jan 21, 2015 at 5:20 PM, Mats Palmgren m...@mozilla.com wrote:
It seems fine to me. WebKit/Blink already rejects(*) a range with
detached nodes in the addRange call. Imposing the same restriction on
a (live) Selection range is consistent
On Wed, Jan 21, 2015 at 5:20 PM, Mats Palmgren m...@mozilla.com wrote:
It seems fine to me. WebKit/Blink already rejects(*) a range with
detached nodes in the addRange call. Imposing the same restriction on
a (live) Selection range is consistent with that.
I don't think it's consistent at
On 01/24/2015 09:52 AM, Koji Ishii wrote:
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
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
On 01/17/2015 05:11 PM, Aryeh Gregor wrote:
On Wed, Jan 14, 2015 at 6:14 PM, Mats Palmgren m...@mozilla.com
wrote:
It would be easy to change Gecko to ignore addRange() calls if the
range start/end node is detached. We could easily do the same for
range.setStart*/setEnd* for ranges that are in
I just said it in the other thread, but just to clarify in this thread
too: I think non-contiguous selections are a great feature. I think
exposing them to authors as multiple Ranges in a Selection has proven
to be not a good way to do it, because authors basically without
exception just ignore
On 01/09/2015 12:40 PM, Aryeh Gregor wrote:
The advantage of the IE/Gecko behavior is you can alter the selection
using Range methods. The advantage of the WebKit/Blink behavior is
you can restrict the ranges in the selection in some sane fashion,
e.g., not letting them be in detached nodes.
On Jan 13, 2015, at 4:21 AM, Arthur Barstow art.bars...@gmail.com wrote:
On 1/13/15 6:54 AM, cha...@yandex-team.ru wrote:
13.01.2015, 05:31, Boris Zbarsky bzbar...@mit.edu:
On 1/12/15 1:56 PM, Olivier Forget wrote:
Unfortunately
multiple range selections are not a nice to have. All
On 1/13/15 6:54 AM, cha...@yandex-team.ru wrote:
13.01.2015, 05:31, Boris Zbarsky bzbar...@mit.edu:
On 1/12/15 1:56 PM, Olivier Forget wrote:
Unfortunately
multiple range selections are not a nice to have. All real editors
(MS Word, Google Docs, etc..) support selecting multiple ranges
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
13.01.2015, 05:31, Boris Zbarsky bzbar...@mit.edu:
On 1/12/15 1:56 PM, Olivier Forget wrote:
Unfortunately
multiple range selections are not a nice to have. All real editors
(MS Word, Google Docs, etc..) support selecting multiple ranges
Precisely. This is why Gecko ended up supporting
On Jan 13, 2015, at 10:06 AM, Ryosuke Niwa rn...@apple.com wrote:
On Jan 13, 2015, at 4:21 AM, Arthur Barstow art.bars...@gmail.com wrote:
On 1/13/15 6:54 AM, cha...@yandex-team.ru wrote:
13.01.2015, 05:31, Boris Zbarsky bzbar...@mit.edu:
On 1/12/15 1:56 PM, Olivier Forget wrote:
On Mon, Jan 12, 2015 at 3:40 AM, Karl Dubost k...@la-grange.net wrote:
I'm using multiple range selection very often. From every day to a couple of
times a week. My main usage is when I use bookmarking services and I want to
keep part of an article which are distant. Basically a text1 […]
On Sat Jan 10 2015 at 8:30:34 AM Aryeh Gregor a...@aryeh.name wrote:
I don't remember whether it was ever discussed on the mailing list in
depth. The gist is that no one has ever implemented it except Gecko,
and I'm pretty sure no one else is interested in implementing it. The
Selection
On 01/10/2015 06:30 PM, Aryeh Gregor wrote:
On Fri, Jan 9, 2015 at 8:29 PM, Olivier Forget teleclim...@gmail.com wrote:
On Fri Jan 09 2015 at 4:43:49 AM Aryeh Gregor a...@aryeh.name wrote:
- It may never happen, but when multiple ranges are supported, are
they bound to index?
Everyone
On 1/12/15 1:56 PM, Olivier Forget wrote:
Unfortunately
multiple range selections are not a nice to have. All real editors
(MS Word, Google Docs, etc..) support selecting multiple ranges
Precisely. This is why Gecko ended up supporting it: it was needed for
the editor that was part of the
Pulling out my user hat:
Le 11 janv. 2015 à 01:30, Aryeh Gregor a...@aryeh.name a écrit :
The reason for all this is that while it makes wonderful theoretical
sense to support multiple ranges for a selection, and is necessary for
extremely sensible features like allowing a user to select
On Fri, Jan 9, 2015 at 8:29 PM, Olivier Forget teleclim...@gmail.com wrote:
On Fri Jan 09 2015 at 4:43:49 AM Aryeh Gregor a...@aryeh.name wrote:
- It may never happen, but when multiple ranges are supported, are
they bound to index?
Everyone wants to kill this feature, so it's moot.
On 01/07/2015 10:08 AM, Koji Ishii wrote:
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 don't think he said that. He said implementing the live-ness properly
can be somewhat annoying,
Thank you Aryeh for the explanation to this newbie, I understand that
better now. That was a bit different from what I had in mind, but glad
to see you agree to return a value.
So, sounds like we're in consensus to change it to return a value?
/koji
On Fri, Jan 9, 2015 at 9:40 PM, Aryeh Gregor
On Fri Jan 09 2015 at 4:43:49 AM Aryeh Gregor a...@aryeh.name wrote:
- It may never happen, but when multiple ranges are supported, are
they bound to index?
Everyone wants to kill this feature, so it's moot.
Could you please point me to the discussion where this conclusion was
reached? I
On Wed, Jan 7, 2015 at 12:32 AM, Ryosuke Niwa rn...@apple.com wrote:
Trident (since IE10) and Gecko both return a live Range, which can be
modified to update selection. WebKit and Blink both return a clone Range so
that any changes to the Range doesn't update the selection.
It appears that
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:
https://github.com/w3c/selection-api/issues/40
Trident (since IE10) and Gecko both return a live Range, which can be modified
to update selection. WebKit and Blink both return a clone Range so that any
changes to the Range doesn't update the selection.
It appears that there is a moderate
On Tue, Jan 6, 2015 at 5:44 PM, Olli Pettay o...@pettay.fi wrote:
On 01/07/2015 12:32 AM, Ryosuke Niwa wrote:
https://github.com/w3c/selection-api/issues/40
Trident (since IE10) and Gecko both return a live Range, which can be
modified to update selection. WebKit and Blink both return a
For what it's worth as a user of the range and selection APIs, updating a
live range is convenient and preferable, but since this has never worked in
all browsers, I never do it and have never recommended it to anyone else.
Therefore if Gecko changes, nothing really changes for me, so I don't
, 2015 2:32 PM
To: Webapps WG
Subject: [Selection] Should selection.getRangeAt return a clone or a reference?
https://github.com/w3c/selection-api/issues/40
Trident (since IE10) and Gecko both return a live Range, which can be modified
to update selection. WebKit and Blink both return a clone
On 01/07/2015 12:32 AM, Ryosuke Niwa wrote:
https://github.com/w3c/selection-api/issues/40
Trident (since IE10) and Gecko both return a live Range, which can be modified
to update selection. WebKit and Blink both return a clone Range so that any
changes to the Range doesn't update the
33 matches
Mail list logo
