scala-js-dom
scala-js-dom copied to clipboard
scala-js
Proposal for MathML base class
- run
sbt prePR[x] - commit changes to
api-reports[x]
This proposes a base class for MathML elements.
If it gets merged / agreed, I'd propose to follow it up with concrete elements following the style of the SVG elements, and the documentation here;
https://developer.mozilla.org/en-US/docs/Web/MathML
Related;
- https://github.com/raquo/scala-dom-types/pulls
- https://github.com/raquo/Laminar/issues/172
cc @raquo
but in scalajs-dom interfaces, it's only defined for HTML elements. Unless there's a known reason for that, I think it should be defined for SVG (and now MathML) elements as well.
I do not know why it has been done like that, I'm not against this change however.
As for this PR, thank you! TIL about the MathML spec. I am wondering how faithful this implementation is to the MathML spec: https://w3c.github.io/mathml-core/#the-top-level-math-element, shouldn't this at least have the global attributes in the class: https://w3c.github.io/mathml-core/#global-attributes ?
I am wondering how faithful this implementation is to the MathML spec: https://w3c.github.io/mathml-core/#the-top-level-math-element, shouldn't this at least have the global attributes in the class: https://w3c.github.io/mathml-core/#global-attributes ?
I think you are absolutely right. I'll try to add it. I think I got the on* properties through sheer luck parroting the SVG element. Thanks for the pointer, BRB...
@raquo I assume, that I also need to add the concrete mathML instances, before we can take advantage of it downstream? I'm planning to do that in a separate PR to keep this one small...
@Quafadas Well, there are levels to this.
If we just have a single MathMLElement class that is shared by all MathML elements in the DOM, then in Laminar we can still type all MathML elements as instances of that one class, ignoring the subclasses. It will work, but you wouldn't be able to read any subclass-specific properties on such instances using el.ref.<propName>. You would still be able to set those properties via Laminar's usual syntax though, if you define those properties in Scala DOM Types.
FTR, I don't actually know how many of such subclass-specific properties MathML elements have.
@raquo Thanks for the note.
I think what I'm proposing is that once this gets merged, I'll follow it straight up with another PR that puts up a complete list of the concrete elements.
Based on what you've said II think my proposal would be to be quite diligent on the top level math element, but I would prefer to avoid a big bike shedding exercise on the correctness of the sub-elements (that are rather niche). If they turned out to have meaningful properties, it should be easier to add them at a later date...
Does that sounds sensible?
@Quafadas Thanks, sounds good to me, just keep in mind that you want to look at the MathMLElement superclass that is common to all MathML elements. The outer <math> element will likely have its own subclass of MathMLElement (not sure the exact name), so it may have properties on it that are not available on other types of MathML elements.
From what I see on MDN, it seems that the root <math> element only has display as the additional attribute. I assume it also reflects as a property, so should be present in the subclass definition, but I'm not sure.