- From: Ryosuke Niwa <rniwa@apple.com>
- Date: Wed, 10 Dec 2014 10:08:32 -0800
- To: Olivier Forget <teleclimber@gmail.com>
- Cc: Ben Peters <Ben.Peters@microsoft.com>, Johannes Wilm <johannes@fiduswriter.org>, Frederico Knabben <f.knabben@cksource.com>, public-editing-tf <public-editing-tf@w3.org>
- Message-id: <D92CEAC6-9DDB-4EDC-9EDD-E98E0AC77E07@apple.com>
> On Dec 10, 2014, at 9:56 AM, Olivier Forget <teleclimber@gmail.com> wrote: > > 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 Please use the GitHub wiki instead. > 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. This should be done in the actual spec once we reached a rough consensus on what to spec. >> 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 ga|bcdh. Considering that both gah and gbh are editable, with nothing non-editable in-between them, it is a natural user expectation that ARROW-RIGHT will lead to gab|cdh. >> >> >> >> 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, etcc so it sounds reasonable for me that if the outer <span cE=false> has the gdisplayh style set to anything that is not ginlineh, like "inline-blockh, the movement would count as a in-between blocks move, so the caret will be before gbh. 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>​<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 gdisplayh 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 >> >
Received on Wednesday, 10 December 2014 18:09:13 UTC