Re: attribute or CSS property?

Hey Koji Ishii,


On Mon, Dec 8, 2014 at 6:19 PM, Koji Ishii <kojiishi@gmail.com> wrote:

> Thank you Johannes to start this discussion. There was a related
> discussion at www-style just a few days ago[1], whether to put
> user-select in CSS UI Level 3 or not. It looks like CSS WG will defer
> that for now, and would like our inputs for CSS UI Level 4.
>

Thanks for the link!



> I'd like to discuss these two together, because editability and
> selectablity are deeply related, and doing these two differently makes
> our life harder. Also, some combinations are weird, such as "typing &
> not-selectable".
>

I agree, it would seem so.

I'm a bit back and forth on the original topic; whether these should
> be attribute or CSS property. Right now, I'm a bit leaning towards to
> attributes for both, since these look content-layer thing to me, and
> in your copy-paste scenario, editability/selectability being copied
> looks more natural to me.
>

>From the perspective of an editor it seems somewhat less so for me.

Lets imagine a webbased editor A (for example TinyMCE on a Wordpress blog
with some plugins) and webbased editor B (for example CKeditor on a Drupal
site with some other plugins) and for the sake of the argument we take the
cleanup of the HTML away that editor B currently will have.

We copy some text in editor A of which some pats are marked as non-editable
such as a citation, as we have a special citation plugin in editor A:

<p>"Hello there, stranger!", the king said <span class="citation"
contenteditable=false>(Adam 1991: 23)</span></p>

We copy this and paste it into editor B, which does not have a citation
plugin. The citation is still handled as one single character. Now the user
wants to change the page number in the citation in editor B. After looking
through all buttons  in the editor UI, the user will figure out that there
is nothing he can do. What are his possible ways out of this?

   - Open the browser's developer mode and remove the contenteditable
   attribute by hand. This is something one of us may do, but normal users
   likely not.
   - Copy the entire text again, paste it into Notepad.exe, copy it again
   and paste it in the webbased editor. This way all the HTML will be gone and
   he will no longer be restricted from changing the page number

 On the other hand, if content-editable were a CSS variable then the
transition from editor A to editor B would be friction-less.

Or the other way: Imagine that in editor A the caption of a figure is
directly editable, whereas editor B has a special way of editing the
caption (through some type of popup): From editor A the user copies;

<figure contenteditable=false>
<img>
<figcaption contenteditable=typing>Some image</figcaption>
</figure>

Although all other figure-elements directly created in editor B will have
the contenteditable-attributes set correctly so that the special plugin
will deal with the figcaption, the figure pasted from editor A will instead
allow direct editing of the caption.



> I had an informal conversations with my colleagues, who pointed out
> that making them to attribute will allow browsers to determine
> editability without computing styles, but we'll probably need to take
> display:none into account, so I guess it won't make much differences.
>

agreed, so that shouldn't be a concern.

>
> [1]
> http://lists.w3.org/Archives/Public/www-style/2014Dec/thread.html#msg42
> [2] http://lists.w3.org/Archives/Public/www-style/2014Dec/0081.html
> [3] http://lists.w3.org/Archives/Public/www-style/2014Dec/0081.html
>
> /koji
>
> On Sun, Dec 7, 2014 at 9:51 PM, Johannes Wilm <johannes@fiduswriter.org>
> wrote:
> > Hey,
> > one issue that hasn't been talked about is the question of whether
> > contenteditable is best handled as an attribute or a css property (or
> both).
> > -webkit-user-modify: read-write-plaintext-only; seems to do some of what
> we
> > want contenteditable=typing to do already in terms of not handling
> things.
> >
> >
> > However, the main reason I am thinking about this is editable and
> > noneditable parts potentially being mixed. If we take a random editor, it
> > will usually have one DOM node in which all the editors content is
> stored,
> > such as:
> >
> > <div contenteditable=typing>....Blablabla....</div>
> >
> > For saving it then simply takes the contents of that node and sends it to
> > the server which will save it to the database from where it then can be
> > served as part of another webpage. That's easy enough.
> >
> > But what if one works with an editor that is dealing with more complex
> > elements which may be partially editable?
> >
> > For example citations one does not want to be editable:
> >
> > <div contenteditable=typing>
> > The sun is larger than the moon.<span class="citation"
> > contenteditable=false>(Galileo 1635:35)</span>
> > </div>
> >
> > One can still save the contents of the editor Dom node and display it
> > directly, although someone may come across the contenteditable=false
> > attribute if trying to copy the text and pasting it into his own editor.
> >
> > But what if one wants to have an image with an editable caption?
> >
> > <div contenteditable=typing>
> > <p>Text...</p>
> > <figure contenteditable=false>
> > <img src="...">
> > <figcaption contenteditable=typing>An important picture</figcaption>
> > </figure>
> > <p>Text...</p>
> > </div>
> >
> >
> > If one simply saves the contents of the DOM-node and displays it in a
> > webpage, the captions of the pictures will suddenly appear as if they are
> > editable. If course it's not *that* difficult to go through all the nodes
> > before and add contenteditable=false on those that need it and do the
> same
> > again removing the attributes before saving. But it would seem cleaner if
> > one simply could use CSS instead:
> >
> > <style>
> > #editor, figcaption {
> >   content-editable: typing;
> > }
> > figure, .citation {
> >   content-editable: false;
> > }
> > </style>
> > <div id="editor">
> >   <p>Text...</p>
> >   <figure>
> >     <img src="...">
> >     <figcaption>An important picture</figcaption>
> >   </figure>
> >   <p>Text...</p>
> > </div>
> >
> >
> >
> > --
> > Johannes Wilm
> > Fidus Writer
> > http://www.fiduswriter.org
>
>


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