Re: Should we take CSS into consideration? (was: Re: attribute or CSS property?)

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