Re: existing contenteditable spec

On Fri, May 29, 2015 at 4:15 PM, Johannes Wilm <johannes@fiduswriter.org> wrote:
>> Thinking about it a bit more -- the fact is, to implement the user
>> deleting text (for instance), you really have to implement
>> execCommand("bold") and so forth anyway.  Because if you have this:
>>
>>   <p>foobar</p><p style="font-weight: bold">bazquz</p>
>>
>> and the user deletes the text "barbaz", you want to end up with something
>> like
>>
>>   <p>foo<span style="font-weight: bold">quz</span></p>
>> or
>>   <p>foo<b>quz</b></p>
>>
>> and the method of detecting that "quz" was originally bold but no
>> longer is, and then making it bold, is logically equivalent to running
>> queryCommandState("bold") on the text and then execCommand("bold") to
>> change it.  So while deprecating execCommand() is sensible, I think we
>> still effectively need to spec a lot of the command logic if we want
>> to spec UA behavior for things like delete.  At that point we may as
>> well just spec execCommand() itself.
>
>
> I don't see that this is necessary. The logic should be so general so it
> also works for:
>
> <p>foobar</p><p class="somecustomclass">bazquz</p>

I'm don't think extending it to classes is a good idea -- the class
might only be relevant to blocks, like class="note" in W3C specs, and
scripts or styles might behave strangely if you put them on inline
elements.  But supposing you limited it to styles.  Consider if the
block had style="border: 1px" -- I don't think you'd want to copy
that.  You could solve that by whitelisting only certain style
properties.  But then what about

  <p>foobar</p><div style="color: red">ba<p style="color: green">zquz</p></div>

You could fairly argue that these are edge cases and it doesn't really
matter what we do here.  Especially since browsers shouldn't (at least
IMO) put style attributes on block elements at all, and handling HTML
that was not generated by contenteditable is not as essential.  Also,
you might be able to avoid all the editing-specific logic and just
define something simple that works purely with CSS.

I guess if anyone does a contenteditable=true spec, it will have to be
seen if any cases like this come up that pose a serious problem.
Offhand I can't think of more realistic scenarios that are a problem,
although I didn't think very hard -- so with luck maybe there aren't
any.  :)

Received on Sunday, 31 May 2015 11:06:35 UTC