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

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