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

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.

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.

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

I couldn't follow what you meant in the last paragraph, sorry for my
English skill. 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.

/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

Received on Tuesday, 16 December 2014 16:34:32 UTC