Re: existing contenteditable spec

On Sun, May 31, 2015 at 7:05 AM, Aryeh Gregor <ayg@aryeh.name> wrote:

> 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.  :)
>

The question is if it makes sense to exactly specify contenteditable=true
if browser makers won't change view that they will not standardize the
behavior due to pre-existing conditions.

What could be spec'ed would a new attribute that does more or less the same
as contenteditable=true. Something like "editing=full". I personally would
prefer that it should do paragraph splitting, etc. in consistent ways no
matter what styling/classes types of elements one is dealing with, but
also, I do not care too much. I think the ce=typing is the most important
of the specs because everything else will be built on top of it and can
probably be entirely implemented in JavaScript, at least initially.

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