[whatwg] [editing] Proposal: Undeletable elements within contentEditable

[Aryeh Gregor]

(Responding to some old feedback on editing from before I started work
on it, which Hixie sent me.)

On Thu, Jun 24, 2010 at 12:08 PM, Nikita Vasilyev <me at elv1s.ru> wrote:
> The current version of spec
> http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#contenteditable
> does not define any way to make an element within contentEditable
> undeletable. I propose "undeletable" attribute:
>
> element.undeletable = "true" | "false"
>
> How should it work:
>
> <div contenteditable>
>  <span undeletable>foo</span>
> </div>
>
> When I focus on the div, select all the text, and delete it, the span
> element MUST be empty, but MUST NOT be deleted.
>
> This behavior would be very useful while building code editors. I'm building
> CSS editor with syntax highlighting and auto-completion based on
> contentEditable. "undeletable" attribute would help me a lot.

I'm very reluctant to add such things, because it adds corner cases
that vastly complicate processing and allow tons more room for bugs.
It means every single algorithm related to editing needs to be aware
of the attribute and check for it before deleting anything.  This is
already a big headache for contenteditable=false, which has tons of
bugs in my algorithms and in browsers that I haven't even tried fixing
systematically yet.

Also, I don't know what use it would be to have the empty wrapper
element hanging around.  I've designed the editing algorithms to avoid
leaving such things: the user can never focus them, typically, so they
don't do much unless you're adding weird styles or such.

If you really wanted this effect, though, I think <span
contenteditable=true> should in theory do what you want.  I've been
designing my spec's algorithms based on the premise that an editing
host should never be deleted or have its attributes modified, but it
can be moved around if it's inside another editing host.  There are
probably loads of bugs in the spec, as I said, and browsers have a
very different view of how things should work in practice, but that's
my goal.

I haven't given a lot of thought to nested editing hosts or nested
non-editable content, though.  I'm not sure what the use-cases are.
It would help a lot if you could explain exactly what you want this
for.

2010/6/24 Joseph Thomas <jthoma12 at calpoly.edu>:
> It seems like the ideal way to handle this would be to handle the
> MutationEvent (and cancel it, but unfortunately they are
> non-cancelable. Perhaps a set of cancelable events, i.e.
> UserMutationEvent.
>
> ( see http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-eventgroupings-mutationevents
> )

Mutation events are a massive headache and we're trying to get rid of
them, so this isn't a feasible long-term suggestion.  See the very
long recent thread on the public-webapps list on this subject.