WIP: Math ml tag defs

[Quafadas]

I will not pretend to have written any of this myself - thank you Mr AI.

In the light of the above statement, I'm not clear whether I have a better or worse chance of this actually working.

So let's poke the CI and see what happens.

[davidon-top]

as far as i know org.scalajs.dom doesn't have support for mathml so your scalaJsElementTypeAlias assignments wont work after codegen, i can be mistaken tho i'm not certain

[Quafadas]

You beat the CI to it!

https://github.com/Quafadas/scala-dom-types/actions/runs/10959385719/job/30431627724

I'm actually not sure whether it needs to be supported by org.scalajs.dom explicitly though.

The browser seems to render it quite happily, so I'm wondering if I just go for some base class and pray?

[Quafadas]

I guess this is probably going to impact the attributes it can have though? Does that mean I need to make PR to scala-js-dom?

[davidon-top]

by default sdt generates definitions like these lazy val htmlRootTag: HtmlTag[dom.HTMLHtmlElement] = htmlTag("html") and u can see inside the HtmlTag generic the dom.whatever that is what scalaJsElementTypeAlias describes AFAIK, its probably possible to add it without scala-js-dom having mathml tags but it will need to use a different system/design to make the mathml elements

[davidon-top]

I guess this is probably going to impact the attributes it can have though? Does that mean I need to make PR to scala-js-dom?

i don't think it would impact the attributes since they are basically just a name and codec it would impact tags tho since they accept the generic type from org.scalajs.dom

[Quafadas]

So I've pattern matched my way through the CI, which is green on my fork. Hopefully it's a starting point for a discussion.

[Quafadas]

I assume, that in its curren t form, it will exhibit the same set of problems as the original bootlegged HTML. I'm not clear how to work around that though.

[raquo]

Thanks, that's a good start!

After looking into this a bit, I think overall, we need to treat MathML tags and attributes similarly to how we treat SVG – so they will get their own namespace in Laminar.

Indeed, as you said, for this to be meaningful, someone needs to contribute the MathMLElement interface to scalajs-dom. I think we can do without that if we just use the dom.Element supertype for MathML elements, but that's only suitable for a PoC, it would make the types too loose in Laminar.

I think if we're adding MathML, we should add all of the MathML tags and attributes right away, especially if AI is helping with the chore. Also:

• The tags and attributes should be sorted alphabetically by their JS / DOM name in the listings
• The <math> tag itself should be moved to MathMlTags – it's actually a MathMlElement, not an HTMLElement (similar to the root tag)

I made an issue in Laminar to track all the related tasks: raquo/Laminar#172

[Quafadas]

@raquo This passes on my fork, I'm not in a position to judge, if the tests are meaningful or not, however :-(

[raquo]

Thanks, good start! 🚀 Please see comments.

[raquo]

Sure, we can merge this into a new mathml branch (pending a couple new comments).

We can merge this into master once the feature is complete and scala-js-dom makes a release.

[Quafadas]

Is there any chance I'm hitting this?

actions/runner-images#10767

[Quafadas]

I can't reproduce this failure locally :-(.

[raquo]

I've merged this into the new mathml branch – as we've discussed, we'll keep MathML work in that branch until it's ready to release.