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

On Tue, Dec 16, 2014 at 5:34 PM, Koji Ishii <kojiishi@gmail.com> wrote:
>
> Are we still on the original topic, or is this a separate topic? It
> looks a separate topic to me, and I'm wondering I'm misunderstanding
> something important.
>

Yes, if you mean by the original subject whether it should be an attribute
or a CSS property, then no, this is a different discussion.
 I changed the subject line because of that.


> By reading your scenarios, what came up in mind is that both
> editability and caret movements should not take display:none into
> account. Browsers can call an external JS function to normalize, and
> that normalizer can do whatever it wants, including the offscreen
> scenarios you mentioned.
>

Well, that's the question. There are arguments for and against it. The
second scenario I wrote about may not actually be valid if we don't allow
pasting anyway.


>
> But then this is probably not about whether the
> editability/selectability should be an attribute or a property.
>

No, that's why I changed the subject line. :)

>
> I couldn't follow what you meant in the last paragraph, sorry for my
> English skill.


I am not a native English speaker myself. It may just as well be a problem
with my explanation.


> Are you saying that you want to utilize the power of
> selectors to change the editability/selectability, and that's why you
> wish it to be a CSS property? You could then use jQuery to enumerate
> such elements, couldn't you? Or maybe I'm totally mistaken.
>

Nono, it has nothing to do with editability controlled by CSS or an
attribute.

I will try to reword it:

[A] For other purposes, web developers (and those creating js frameworks)
know "display:none" as something that will affect all descendants of the
element it is applied to. There is no way to get a descendant element to
show up on the page once an ancestor has been hidden with "display:none".
It therefore never makes sense to attach another "display:none;" style to a
descendant of another element that already has "display:none;" specified.

As I understand the suggestion, to treat a "display:none;" on an element
inside the editing area as if it's not there, whereas a "display:none;" on
an ancestor node of the editing area in a different manner, the logic
mentioned in [A} does not apply.

As a web developer, who has become used to "display:none;" behaving as
mentioned in [A}, I would expect that divergent behavior would be specified
in the relevant specification.  That's all. But I am new at this,  and
maybe it's not normal practice to specify such things at all.


Btw, if you look a few emails back, when I changed the subject line, I
wrote:

"...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."




>
> /koji
>
>
> On Tue, Dec 16, 2014 at 5:12 PM, Johannes Wilm <johannes@fiduswriter.org>
> wrote:
> >
> >
> > On Tue, Dec 16, 2014 at 8:10 AM, Koji Ishii <kojiishi@gmail.com> wrote:
> >>
> >> +1 from me too.
> >>
> >> On Tue, Dec 16, 2014 at 7:11 AM, Johannes Wilm <
> johannes@fiduswriter.org>
> >> wrote:
> >>
> > ...
> >>
> >> >
> >> > <div style="display:none;">
> >> >   <div contenteditable=true>
> >> >     Hello <span style="display:none"><span
> >> > contenteditable=true>Austria</span></span>!
> >> >   </div>
> >> > </div>
> >> >
> >> > Now we would have two (offscreen) contenteditable areas, one within
> the
> >> > other, but the outer one will ignore the inner one when it comes to
> >> > caret
> >> > movement, while the inner one is self-contained. I can see how that
> >> > could
> >> > come in handy for some things.
> >>
> >> Needs Olivier's clarification; I think his proposal handles the two
> >> the same way. Since outer one is display:none, carets cannot move into
> >> there unless it's set by scripts, IIUC.
> >
> >
> > I am imagining two things:
> >
> > 1. An editor that consists of an offscreen contenteditable element which
> has
> > all contents "mirrored" to a visible DOM element (triggered upon any
> change
> > in the contenteditable element) and where some javascript takes care of
> the
> > caret being placed the right place in the offscreen contenteditable
> element
> > when clicking somewhere in the on-screen mirror.
> >
> > 2. The editor detects that pasting is about to happen, but doesn't bother
> > about handling merging with current paragraphs, etc. javascript. So
> instead
> > an offscreen contenteditable element with the current contents is
> created,
> > the paste takes place there, the contenteditable element's contents are
> then
> > cleaned up before beign copied into the onscreen element where most of
> the
> > editing takes place.
> >
> >>
> >> > How about CSS specs? It seems at least the definition of display:none
> >> > would
> >> > need to be amended slightly:
> >> > http://www.w3.org/TR/CSS2/visuren.html#display-prop
> >> >
> >> > "none: This value causes an element to not appear in the formatting
> >> > structure (i.e., in visual media the element generates no boxes and
> has
> >> > no
> >> > effect on layout). Descendant elements do not generate any boxes
> either;
> >> > the
> >> > element and its content are removed from the formatting structure
> >> > entirely.
> >> > This behavior cannot be overridden by setting the 'display' property
> on
> >> > the
> >> > descendants.
> >> >
> >> > Please note that a display of 'none' does not create an invisible box;
> >> > it
> >> > creates no box at all. CSS includes mechanisms that enable an element
> to
> >> > generate boxes in the formatting structure that affect formatting but
> >> > are
> >> > not visible themselves. Please consult the section on visibility for
> >> > details."
> >>
> >> It's only talking about box generations, and editing is done in DOM in
> >> principle, so I don't see any problems with this text. Can you clarify
> >> your concerns a bit more?
> >
> >
> > No, just that display:none now takes on a different quality from being
> > something that is applies to one element and will count for all
> descendants
> > to something that for certain operations can be meaningfully applied at
> > several levels within the DOM tree. jQuery and other js frameworks base
> some
> > of their CSS selection mechanisms on this quality.
> > I am not sure what common practice is for such cases, but if we invent a
> > very new way that display:none is interpreted that only applies to
> editing,
> > then this difference should probably be documented explicitly somewhere,
> > right?
> >
> >
> > --
> > Johannes Wilm
> > Fidus Writer
> > http://www.fiduswriter.org
>
>

-- 
Johannes Wilm
Fidus Writer
http://www.fiduswriter.org