Craig Marsh Graduate Dev in Test QA Platform 4th Floor, 10 Piccadilly London, W1J 0DD Email: craig.ma...@gamesys.co.uk www.gamesyscorporate.com <http://www.gamesyscorporate.com/>
On 14/07/2014 10:09, "David Carlisle" <dav...@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 >