Re: [whatwg] Move contentEditable/isContentEditable from HTMLElement to Element?

On Tue, May 13, 2014 at 11:21 AM, Ian Hickson <ian@hixie.ch> wrote:

> On Tue, 13 May 2014, Dirk Schulze wrote:
> >
> > contentEditable can be fairly useful in SVG as well. It partly works for
> > inline SVG content in web browsers today.
> >
> > The question is, should SVGElement add support for
> > contentEditable/isContentEditable and add it to its interface? Or should
> > both attributes move to the Element interface instead?
>
> I would be very careful about moving global attributes to Element. Doing
> so implies that we are adding them to _all_ XML namespaces. That's a huge
> change to propose. Even with "class" it's IMHO going a bit far (we're
> saying that the semantics of <myvocab:teacher class="..."/> are that it's
> a space-separate list of CSS class names, even if the vocab designer
> intended it to be a room name or whatever).
>

@class is a strange thing to make applicable to all random elements in all
namespaces. Even so, in WebKit and Blink we do actually support it on
Element which means that's already the case.


>
> I would feel more comfortable putting things on SVG, MathML, and HTML
> explicitly.
>
>
>
I don't think we want contenteditable in SVG or MathML. Almost all of the
operations don't make sense. What does intending in SVG do? What does
making something italic? What happens when you hit enter? We can't just
insert a new line in SVG, does it add some space between all the shapes?
Where does your caret actually appear?

We might want some new kind of Web Editing API, but
contenteditable/execCommand are both pretty specific to HTML.

- E

Received on Thursday, 15 May 2014 17:02:45 UTC