Re: [whatwg] Move contentEditable/isContentEditable from HTMLElement to Element?
On Jul 2, 2014, at 4:01 AM, Ryosuke Niwa rn...@apple.com wrote: On May 15, 2014, at 10:01 AM, Elliott Sprehn espr...@chromium.org wrote: On Tue, May 13, 2014 at 11:21 AM, Ian Hickson i...@hixie.ch wrote: 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? The question about “hitting enter” is valid. However, these kind of questions don’t seem to be clarified for HTML either. Every UA is doing something different. To the other questions: just text in text, textPath and tspan are affected. In all other cases the general processing rules of SVG apply. We might want some new kind of Web Editing API, but contenteditable/execCommand are both pretty specific to HTML. contenteditable isn't just for execCommand. We could simply enable plaintext editing inside SVG text element for example. However, I would like to know what use cases and problems Dirk is trying to solve by moving these attributes from HTMLElement to Element. Dirk, could you elaborate on that? If you add contentEditable to an HMTL element and an SVG element is an descendant of this element, SVG text is editable as well. If you add contentEditable to an SVGElement itself, it doesn’t work. That is an observation that can be see in all browsers IIRC. SVG folks actually get asked to support contentEditable. People want to use text along a path, have it selectable and editable. Just SVG can do that — but with the hack of above. Should we add contentEditable to SVGElement or Element seems to be the remaining question. This depends if there are similar scenarios in MathML (and other markup languages) as well. Greetings, Dirk - R. Niwa
Re: [whatwg] Move contentEditable/isContentEditable from HTMLElement to Element?
On 14/07/2014 09:43, Dirk Schulze wrote: However, I would like to know what use cases and problems Dirk is trying to solve by moving these attributes from HTMLElement to Element. Dirk, could you elaborate on that? If you add contentEditable to an HMTL element and an SVG element is an descendant of this element, SVG text is editable as well. If you add contentEditable to an SVGElement itself, it doesn’t work. That is an observation that can be see in all browsers IIRC. SVG folks actually get asked to support contentEditable. People want to use text along a path, have it selectable and editable. Just SVG can do that — but with the hack of above. Should we add contentEditable to SVGElement or Element seems to be the remaining question. This depends if there are similar scenarios in MathML (and other markup languages) as well. The MathML element case is similar to SVG the token elements such as mtext are basically just like span as far as text is concerned and editing the text in such an element is a perfectly natural requirement. change the variable x to y in e^x... editing the more structural elements such as mfrac requires more editing support (or can be disallowed, whichever fits in best with the rest of the platform) same is true of SVG (or HTML tables for that matter). Dirk's observation above about having to put contentEditable on an ancestor HTML element reminds me of the arguments for adding .innerHTML and friends to MathML (by way of adding them to Element). As originally defined you couldn't use .innerHTML on MathML elements but if you wrapped them in a span the browser had to be able to generate the innerHTML serialisation of all the descendents of that span including the MathML, so innerMathML could be faked on MathML by wrapping it in a spurious span and then removing the span from the result. Allowing the innerHTML directly on the mathml elements just made the system more logical and more convenient. It seems contentEditable is similar. David
Re: [whatwg] Move contentEditable/isContentEditable from HTMLElement to Element?
Le 13/05/2014 18:21, Ian Hickson a écrit : 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). I would feel more comfortable putting things on SVG, MathML, and HTML explicitly. It might make sense to split the current HTMLElement interface and create a partial interface so it can be more easily reused in SVG and MathML. Filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=26329 for that purpose. David
Re: [whatwg] Move contentEditable/isContentEditable from HTMLElement to Element?
On May 15, 2014, at 10:01 AM, Elliott Sprehn espr...@chromium.org wrote: On Tue, May 13, 2014 at 11:21 AM, Ian Hickson i...@hixie.ch wrote: 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. contenteditable isn't just for execCommand. We could simply enable plaintext editing inside SVG text element for example. However, I would like to know what use cases and problems Dirk is trying to solve by moving these attributes from HTMLElement to Element. Dirk, could you elaborate on that? - R. Niwa
Re: [whatwg] Move contentEditable/isContentEditable from HTMLElement to Element?
On Tue, May 13, 2014 at 11:21 AM, Ian Hickson i...@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
Re: [whatwg] Move contentEditable/isContentEditable from HTMLElement to Element?
On Tue, May 13, 2014 at 11:26 AM, Dirk Schulze dschu...@adobe.com 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 suggest we wait with deciding upon this until browsers have moved id/class support to Element as per the DOM Standard. Seems best to make some incremental steps here to see what problems we run into. -- http://annevankesteren.nl/
Re: [whatwg] Move contentEditable/isContentEditable from HTMLElement to Element?
On 13/05/2014 10:26, Dirk Schulze wrote: Hi, 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? Greetings, Dirk Same for MathML, in general I favour moving as much as possible to Element to remove differences that really have more to do with history than anything else. No argument with Anne's reply that you can only move as fast as you can move though:-) David
Re: [whatwg] Move contentEditable/isContentEditable from HTMLElement to Element?
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). I would feel more comfortable putting things on SVG, MathML, and HTML explicitly. BTW, if anyone wants to move contenteditable= to another spec, my suggestion would be that the place to move it to is the HTML Editing APIs spec, which could be renamed Web Editing APIs. There's precedent for having hooks for attributes like that, e.g. ARIA. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
