Re: Default Caret and Selection Positioning Spec?

I agree with everybody that it seems things get forgotten too easily and
that there are too many discussions going on at once.

Github Issues alone aren't really enough because without an existing
document to create an issue against, they're basically just email threads
in a different place.

Ben, would you consider creating a crude "caret handling" text file on
gitHub? This would:
- list all the things that we need to address
- central go-to reference for what the latest thinking of the group for
each, along with links to emails or issues where discussed.
- things not yet addressed are clearly marked as such

My hope is that this will help keep everybody on the same page, and on
track to discuss what needs to be addressed.

I think a simple text file would suffice, possibly in markdown, so we can
issue pull requests. The idea is that this is a living document, it should
be updated every time the conversation moves forward a notch.

Thoughts? If you want I can take a first stab at it.


On Wed, Dec 10, 2014 at 9:23 AM, Ben Peters <Ben.Peters@microsoft.com>
wrote:

>  Can we please use GitHub issues? If an issue contains multiple topics,
> we should split it into multiple issues. That will keep the conversation
> cleaner. Email tends to lose context.
>
>
>
> *From:* johanneswilm@gmail.com [mailto:johanneswilm@gmail.com] *On Behalf
> Of *Johannes Wilm
> *Sent:* Wednesday, December 10, 2014 3:53 AM
> *To:* Frederico Knabben
> *Cc:* Ben Peters; Ryosuke Niwa; public-editing-tf
> *Subject:* Re: Default Caret and Selection Positioning Spec?
>
>
>
>
>
>
>
> On Wed, Dec 10, 2014 at 10:48 AM, Frederico Knabben <
> f.knabben@cksource.com> wrote:
>
> ...
>
>
>
>  a|<span cE=false><span cE=true>b</span>c</span>d
>
> a<span cE=false><span cE=true>b|</span>c</span>d (nothing to skip)
>
>  This one seems more questionably to me.  What would the use case be to
> not have the caret be able to go in front of the "b"? It seems like users
> would need "hack" this by adding a zero-width space to the outer span to
> get around this limitation. That doesn't seem right.
>
>  Visually speaking, the user sees the above as “a|bcd”. Considering that
> both “a” and “b” are editable, with nothing non-editable in-between them,
> it is a natural user expectation that ARROW-RIGHT will lead to “ab|cd”.
>
>
>
>    I understand that there may be situations where you want to style non
> editable blocks in a more evident way to the user, with borders, padding,
> etc… so it sounds reasonable for me that if the outer <span cE=false> has
> the “display” style set to anything that is not “inline”, like
> "inline-block”, the movement would count as a in-between blocks move, so
> the caret will be before “b”. This would be a good way to bring developers
> control over this behavior.
>
>
>
> I think that sounds like a good compromise and a lot better than having to
> add zero space characters as would otherwise be the only way around this:
>
>
>
> a<span class="outer" cE=false>&#8203;<span cE=true>b</span>c</span>d
>
>
>
> I can't think of any circumstances in which one may need to use the inline
> css style yet still want this behavior.
>
>
>
>
>
> Btw, I feel that the computed style of “display” is critical on the
> algorithms, because some block elements may be styled as inline and
> vice-versa.
>
>
>
> We discussed some related cases in the  above URL.
>
>  @Ben, It is pretty hard to follow the discussion there, because there
> are several different topics under discussion on separate comments. Just
> like this thread. I really think that a shared document would do a better
> job.
>
>
>
>
>
> Agreed. I sometimes feel that certain points have been forgotten, but I
> don't want to constantly repost here as that would just spam the list.
>
>
>
> --
>
> Johannes Wilm
>
> Fidus Writer
>
> http://www.fiduswriter.org
>