- From: Koji Ishii <kojiishi@gmail.com>
- Date: Tue, 16 Dec 2014 00:22:48 +0900
- To: Johannes Wilm <johannes@fiduswriter.org>
- Cc: Ben Peters <Ben.Peters@microsoft.com>, "public-editing-tf@w3.org" <public-editing-tf@w3.org>
Thanks for the great summary, Johannes. I started pondering probably a bit wild idea and would like to know what people here thinks. The idea is that, assuming we take what I proposed a bit ago -- browsers do minimal in terms of normalizations but delegates it to an external JavaScript -- could we also take display-none-ishness out of the browsers too? I don't know the history at all, very new in this area, but I suppose it was introduced because cE wanted to be smart, and for sure no end users would want to type into display:none. But now, we're assuming that there will be a layer between browsers and users. Also today's CSS provides more ways to hide elements than 5 years ago, such as opacity or transform:offsetX(100%). Apparently carets are not visible in any of these cases and we might want to define carets visibility in the spec, but if JS would kick in to resolve visual-position-to-dom-position ambiguity, I wonder it's easier to put display-none-ishness into the same bucket. Is this too wild? /koji On Thu, Dec 11, 2014 at 1:03 AM, Johannes Wilm <johannes@fiduswriter.org> wrote: > Hey, > so there seems to be a majority for going with an attribute rather a CSS > property when it comes to assigning editability. > > Another somewhat question seems to have come up a few times over the last > few days without being discussed directly is how CSS should or shouldn't > influence contenteditable=typing. > > AGAINST: Piotr mentioned some reasons not to take CSS into consideration: > "We are often traversing DOM to check whether some element is inside > editable container or not and we do that also on detached DOM (when > processing input/output data). If we would need to check computed styles I > think it would be both - slower and/or more limited/complicated. [...] > Visibility does not affect editability - > https://www.w3.org/Bugs/Public/show_bug.cgi?id=25908". The mentioned link > mentions a case where a contenteditable element was inside of a dom element > that was hidden with display:none and was making the point that the > contenteditable element should still work as normal. > > FOR: Olivier mentioned a display:none node inside of a > contenteditable=typing, which he believes should be treated as if it didn't > exist ( https://github.com/w3c/selection-api/issues/27#issuecomment-65961041 > ) and Federico thinks that carets should behave different for some types of > display:inline-block elements ("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 can see good arguments for both positions, but I think we should try to be > consistent in some way. Think of this example: > > <div style="display:none;"> > <div contenteditable=true> > Hello <span style="display:none">Austria</span>! > </div> > </div> > > > We could of course combine the two proposals above, but it would then seem > to mean that we start to operate with several layers of > display-none-ishness, which I'm not sure was intended. > > -- > Johannes Wilm > Fidus Writer > http://www.fiduswriter.org
Received on Monday, 15 December 2014 15:23:16 UTC