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
