13893 2011-08-24 19:55:36 +0000 Only HTML elements should be editable 2011-11-08 19:24:21 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - HTML Editing APIs unspecified All All RESOLVED FIXED P2 normal --- 1 ayg ayg annevk ehsan mike public-webapps sideshowbarker+html-editing-api oldest_to_newest 55771 0 ayg 2011-08-24 19:55:36 +0000 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. 55787 1 ehsan 2011-08-25 02:50:51 +0000 Also, I think we should specify that a bunch of things should work for those subtrees, such as resizing, and copying to the clipboard. 55934 2 ayg 2011-08-28 16:00:17 +0000 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. 56029 3 annevk 2011-08-30 07:22:49 +0000 HTML nested inside SVG should still be editable. 56047 4 ayg 2011-08-30 16:54:39 +0000 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. 56057 5 ehsan 2011-08-30 19:09:56 +0000 (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. 59756 6 ayg 2011-11-08 19:24:21 +0000 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.