[whatwg] Please unsubscribe me, thanks

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