- From: Koji Ishii <kojiishi@gmail.com>
- Date: Sat, 13 Dec 2014 14:06:12 +0900
- To: Ben Peters <Ben.Peters@microsoft.com>
- Cc: Johannes Wilm <johannes@fiduswriter.org>, "public-editing-tf@w3.org" <public-editing-tf@w3.org>
I think the point of this discussion, by reading what Johannes and Piotr said, is that the ideal copy-paste behavior could vary by the editor developer preferences; i.e., some may prefer to keep editability while some may want not to. I think that's good, there should be editors that does it, that does not, or that allows users to choose. I just do not want standardize to define such controversial behavior. But *if* we want to change it, it's easier to change attributes than CSS property? Changing the computed value of CSS property computed for just one element isn't quite easy, and I hope you agree on this point. For the selectability, thank you for agreeing to discuss on this together. I'm wondering, do we really need a separate attribute/property? My gut feeling is that it can be replaced by contenteditable=noselect (or content-editable: no-select if we were going to CSS route,) but either way, is there cases where we'd need to split the two? I believe making these two into different values of single variable would make both spec and implementation simpler. Thoughts? /koji On Wed, Dec 10, 2014 at 2:11 AM, Ben Peters <Ben.Peters@microsoft.com> wrote: > > > On Tue, Dec 9, 2014 at 1:29 AM, Johannes Wilm <johannes@fiduswriter.org> wrote: >>> 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? > > This seems like a rabbit hole to me. Editor B is not made to edit citations. You can fix this situation by simply deleting the non-editable citation and typing your own. Or if Editor A is more robust, it could change from its specialized citation class to something editable when you copy out of it. I don't think we need to be in the business of solving this in the browser. > > It's important to have these conversations! At this point I still think a DOM attribute is the way to go.
Received on Saturday, 13 December 2014 05:06:39 UTC