- From: Craig Marsh <Craig.Marsh@Gamesys.co.uk>
- Date: Mon, 14 Jul 2014 09:10:30 +0000
- To: David Carlisle <davidc@nag.co.uk>, "whatwg@lists.whatwg.org" <whatwg@lists.whatwg.org>
- Cc: "dschulze@adobe.com" <dschulze@adobe.com>
Craig Marsh Graduate Dev in Test QA Platform 4th Floor, 10 Piccadilly London, W1J 0DD Email: craig.marsh@gamesys.co.uk www.gamesyscorporate.com <http://www.gamesyscorporate.com/> On 14/07/2014 10:09, "David Carlisle" <davidc@nag.co.uk> wrote: >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 >
Received on Monday, 14 July 2014 09:11:30 UTC