Nested contenteditable

[Dinu]

I think this is a collection of browser bugs, don't know if they have any workaround or can be forwarded. Test case: <span contenteditable="false">abcd<span contenteditable="true">efgh</span>ijkl</span> The idea is to have a fixed structure with contenteditable=false (basically some fake post-processing tags), that has an editable window inside.

Outcome: IE: surprisingly, everything works as expected FF: all keyboard interaction except typing is dead in the inner block Chrome: completely crashes browser Opera: entire block is non-editable Safari: "sort of" works, browser crashes when you delete everything in the inner block

I was a bit surprised to see webkit appcrash like this, I guess fame comes with a price :)

[Dinu]

More on the same matter:
IE: cursor cannot be moved in the nested editable span with the mouse (always goes to start of block) All others: links in the nested editable span are not disabled

[Garry Yao]

First it should be understood that "nested contenteditble" is allowed by the specification, even not been well explained:

An editing host can contain non-editable sections that contain further editing hosts.

Then we'd claim that nested "contenteditable" is not yet supported in CKEditor, there are two parts contributing to this:

1. we'd like to receive stronger feedback on how such structure is actually useful for people;
2. As you noted, browsers have only right now partial and premature support for it, we'd like to expect a more consistent behavior across the browsers before we land it on our feature list.

So we'd treat this a new feature and will propose it at the proper time in future releases.

[Dinu]

For usefullness, we envision using this to add fixed-format widgets to the html code, that would still have editable portions inside. A couple exemples:

1) Smart links: We'd like to replace the <a> tag with a more comprehensive structure that would provide for post-processing custom resource ids, related subjects, etc; but still work like a regular <a> tag in the sense that the link text would be editable. So the structure would look like this:

<span contenteditable="false">
    <custom:processing internal_resource_id="..." related_targets="..." more_data="..." />
    <a href="regular_url">
        <span contenteditable="true">
        </span>
    </a>
</span>
}}}[[BR]]
2) '''Picture with caption''': we'd like <img> tags to have a caption attached in a fixed format (say, below the picture, and the caption be html-editable):[[BR]]
{{{
<span contenteditable="false">
    <div class="some-css-class-for styling-the-box">
        <img src="image" />
        <div class="caption-class">
            <span contenteditable="true">
                Picture caption here
            </span>
        </div>
    </div>
</span>
}}}[[BR]]
So in short, it has 2 uses: for creating presentation blocks that can be embedded in an editable document, and for embedding post-processing tags that are not html-specific.[[BR]]
[[BR]]
For implementation, 2 things would be required:
- Browser support
- Editor support: 2 points: editor should not refactor html in non-editable blocks (as it happens now), and it should treat every editable block as a separate container

}}}

[Dinu]

I can never get this trac formatting work for me...

[Alfonso Martínez de Lizarrondo]

The "right way" (that's it: the way that you can do it without waiting lots of years and become crazy fighting all the issues) is to use the same approach than the Placeholder plugin: the whole block isn't editable, and you can edit its contents with a custom dialog.

Don't try to do nested contentEditable or you'll never stop having issues.

[Dinu]

Yes, I made some mental gymnastics to figure what would take to see this come to life, and it doesn't look very soon. However, I have everything ready to support this on the host app. It 90% works on IE, so now it's just a question of pushing for compliance and tracking progress. If you don't mind, I'll note here all issues I find and synthesize them for each browser, for when time comes to support this.

[Dinu]

My immediate must for now is to have non-nested contenteditable="false" elements working properly (like the Placeholder plugin, still a few issues there, too, see #6735), then see what can be done about nesting. Thanks for your patience, though.

[Frederico Caldeira Knabben]

Feel free to log your findings in this ticket dinu. Thanks for the findings.

Of course, the very first thing to have is a good set of reports on the browsers vendors side.

(Tip: Always hit the "Preview" button first ;))

[Hallvord R. M. Steen (Opera Software)]

Opera just improved its support for nested contentEditable false/true scenarios, should work better in Opera 11 (internal bug: CORE-32646).

[Piotrek Koszuliński]

Support for nested editables was introduced in CKEditor 4.3 (#9764). The missing feature from those mentioned in this ticket is support for inline nested editables: #10974.