Re: [css-ui-4] ACTION-690, interaction of selectability and editability

On 5/29/15 12:25 PM, Florian Rivoal wrote:
> I have this action on me to add a note in the spec of user-select:none[1]
>
>> ACTION-690: Add a note to user-select:none about it's use in template-based editting. (Cascading Style Sheets (CSS) Working Group)
> This note is harder to write than it seemed at first, because this use-case is a combination of selectability and editability. I have a suggestion at the bottom of this mail, and I'd like feedback not only on its content, but also on whether we should have it.
>
> First, let's review the context. As I understand, we're talking about this scenario:
>
> <style>
> .warning {
>    user-select: none;
>    text-transform: uppercase;
>    color:red;
> }
> :read-write { color:grey; }
> </style>
> <div contentEditable=true id=top-secret-memo>
>    <h1>Memo Title Here</h1>
>    <div contentEditable=false class=warning>
>      This memo is top secret.
>      its content may not be revealed to anyone
>      without explicit permission from
>      <span contentEditable=true>agent M</span>.
>    </div>
>    <p>Write the memo here.
> </div>
>
> In this case, user-select:none makes sure that in addition to being impossible to edit (which contentEditable=false takes care of), the warning is impossible to delete. Even if you press control+a / cmd+a / ... it won't get selected, and when you hit delete or backspace it stays there.
>
> contentEditable=false, on its own, should not prevent that, since it can be used for things like this lousy imitation of the "To" field of Apple Mail.
>
> <style>
> .contact { background: lightblue; margin: 0 1px; border-radius: 2px; }
> </style
> <div id=mailto>To:
>    <span contentEditable=true id=receipients>
>      <span class=contact contentEditable=false>www-style &lt;www-style@w3.org&gt;</span>
>      <span class=contact contentEditable=false>Foo &lt;foo@bar.com&gt;</span>
>      not-finished@typing.
>    </span>
> </div>
>
> Here, you cannot edit the contacts that have been already recognized and turned into the non editable class=contact spans by some piece of js, but you can delete them: if the caret is immediately after one of these and you press backspace, the element is selected, and if you press backspace once more, it is deleted.
>
> Back to the first example, placing the caret after the class=warning and hitting backspace would fail to select it, so it would be safe from deletion by the second press of backspace as well.
>
> Or at least, that's what I think should happen. Because as you all know, the behavior of contentEditable is underspecified, and even where it is specified, it is not always interoperable, so what I just described in both examples isn't something you can depend on today.
>
> Maybe it should be dependable (I think that would be good), but this behavior seems out of scope for css-ui, and would belong in the contentEditable spec(s).
>
> Moreover, if the were concerned with contentEditable=typing (See [2] if you're not familiar) rather than contentEditable=true, the browser would do nothing in any of these cases, and this would be up to the js implementation of the editor to decide what to do, so we can spec this even less.
>
> Taking all of this into account, the note I was tasked to write could be:
>
>> Note: user-select:none on a non-editable descendant of an editable element means that in addition to not being editable, that descendant is also not deletable, neither directly nor by attempting to include it in a broader selection and then deleting that selection. This matter for example in template-based editing, where an editable template may contain sections which must be preserved.
> I don't think this can be normative behavior (even with a should) in css-ui-4, since we don't define who editing works in the first place. But it can serve as a reminder for spec editors and implementers of contentEditable or other mechanisms to pay attention to this use case
>
> At the same time, even if it is not normative, maybe it is still out of scope for css-ui-4 (and css in general) do say anything about that behavior, and we should leave this up to other people to figure out whether they want this or not.
>
> Thoughts?

Florian, thanks for including p-webapps on this e-mail.

Wilm, perhaps there is an issue/action that should be created for one of 
the Editing TF's specs (<http://w3c.github.io/editing/>)?

-Thanks, ArtB

>
>   - Florian
>
> [1] http://dev.w3.org/csswg/css-ui-4/#content-selection
> [2] https://w3c.github.io/editing/contentEditableTyping.html

Received on Thursday, 4 June 2015 16:49:39 UTC