This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Ehsan pointed out that it doesn't make any sense to let the user edit SVG or MathML unless the browser has a special editor for them. We should make only HTML elements editable/editing hosts for now. Embedded SVG/MathML should be treated as opaque, like an <img>. This probably means the root node of the foreign content does need to be editable, so we know we can delete it, but we don't want to touch any of its descendants.
Also, I think we should specify that a bunch of things should work for those subtrees, such as resizing, and copying to the clipboard.
I'll want to define some category of content that includes img, video, audio, svg, math, maybe a few other things (hr?), and specify all of them to be draggable/resizable/etc. Currently I treat some of these specially in some cases but not in others -- I should do some unification.
HTML nested inside SVG should still be editable.
We talked about that. In theory maybe yes, but it might be complicated. At any rate, as far as the spec is concerned, adding the contenteditable attribute to HTML-in-SVG-in-HTML can still be allowed, but I don't think it should inherit the editability of an HTML ancestor automatically. <svg> should be treated similarly to <object> or <img src=foo.svg> by default, which means the whole thing is one big image. Allowing parts to be editable would be a bit of a UI problem.
(In reply to comment #4) > We talked about that. In theory maybe yes, but it might be complicated. At > any rate, as far as the spec is concerned, adding the contenteditable attribute > to HTML-in-SVG-in-HTML can still be allowed, but I don't think it should > inherit the editability of an HTML ancestor automatically. <svg> should be > treated similarly to <object> or <img src=foo.svg> by default, which means the > whole thing is one big image. Allowing parts to be editable would be a bit of > a UI problem. Yes. To elaborate, I think we should treat SVG and MathML content as contentEditable="false" by default. Therefore, any HTML content inside such elements should be treated as non-editable by default. But of course the author might specify the contentEditable attribute on such elements explicitly.
https://dvcs.w3.org/hg/editing/rev/f4f95c3f51d6 I'm not actually testing this requirement anywhere for the time being, since it's a bit niche. There's no way to actually create <svg> or <math> right now using the editing APIs anyway. But the requirement is now there.