On Tue, Jan 27, 2015 at 4:49 PM, Koji Ishii 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 caus
On Sun, Jan 25, 2015 at 1:31 AM, Mats Palmgren 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 practical problems
On 01/24/2015 05:50 PM, Aryeh Gregor wrote:
On Wed, Jan 21, 2015 at 5:20 PM, Mats Palmgren 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
On Sat, Jan 24, 2015 at 3:28 PM, Koji Ishii 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 differently based on wheth
On Wed, Jan 21, 2015 at 5:20 PM, Mats Palmgren 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 all. In one cas
On Sat, Jan 24, 2015 at 9:52 PM, Olli Pettay 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, the more
On 01/24/2015 09:52 AM, Koji Ishii wrote:
On Thu, Jan 22, 2015 at 12:20 AM, Mats Palmgren 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.
Select
On Thu, Jan 22, 2015 at 12:20 AM, Mats Palmgren 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 presumably be e
On 01/17/2015 05:11 PM, Aryeh Gregor wrote:
On Wed, Jan 14, 2015 at 6:14 PM, Mats Palmgren
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 the Selection. W
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 an
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.
I
> On Jan 13, 2015, at 10:06 AM, Ryosuke Niwa wrote:
>
>
>> On Jan 13, 2015, at 4:21 AM, Arthur Barstow wrote:
>>
>>
>>> On 1/13/15 6:54 AM, cha...@yandex-team.ru wrote:
>>> 13.01.2015, 05:31, "Boris Zbarsky" :
> On 1/12/15 1:56 PM, Olivier Forget wrote:
> Unfortunately
> multiple
> On Jan 13, 2015, at 4:21 AM, Arthur Barstow wrote:
>
>
>> On 1/13/15 6:54 AM, cha...@yandex-team.ru wrote:
>> 13.01.2015, 05:31, "Boris Zbarsky" :
On 1/12/15 1:56 PM, Olivier Forget wrote:
Unfortunately
multiple range selections are not a "nice to have". All "real" editors
>>
On 1/13/15 6:54 AM, cha...@yandex-team.ru wrote:
13.01.2015, 05:31, "Boris Zbarsky" :
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.
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" :
> 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:
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
On 01/10/2015 06:30 PM, Aryeh Gregor wrote:
On Fri, Jan 9, 2015 at 8:29 PM, Olivier Forget wrote:
On Fri Jan 09 2015 at 4:43:49 AM Aryeh Gregor 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 Sat Jan 10 2015 at 8:30:34 AM Aryeh Gregor 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 interface was
On Mon, Jan 12, 2015 at 3:40 AM, Karl Dubost 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 […] text2 […]
> text3
Pulling out my user hat:
Le 11 janv. 2015 à 01:30, Aryeh Gregor 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 columns of
> a tab
On Fri, Jan 9, 2015 at 8:29 PM, Olivier Forget wrote:
> On Fri Jan 09 2015 at 4:43:49 AM Aryeh Gregor 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 poin
On Fri Jan 09 2015 at 4:43:49 AM Aryeh Gregor 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 searche
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", whi
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 Wed, Jan 7, 2015 at 12:32 AM, Ryosuke Niwa 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 there is a
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:
-
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 care.
On Tue, Jan 6, 2015 at 5:44 PM, Olli Pettay 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 clone R
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 selecti
I'm not sure if any sites depend on the Gecko/Trident behavior, but I imagine
any such sites also work in Webkit/Blink. So I'm fine with changing this unless
anyone knows of an important dependency.
-Original Message-
From: Ryosuke Niwa [mailto:rn...@apple.com]
Sent: Tuesday, January 6,
32 matches
Mail list logo
