-
Notifications
You must be signed in to change notification settings - Fork 162
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tidy Mathml element #869
base: main
Are you sure you want to change the base?
Tidy Mathml element #869
Conversation
@zetashift Sorry to bother you again, this would be the follow up PR to the base element. I've had a double check, and I can't see that I would do anything differently? Do you agree with adding the remaining elements? |
@raquo - Does this look more or less the way you would expect? If so I'll continue on filling in the blanks... |
Hm, well, TBH this is indeed what I expected, but upon further research it appears that my expectations were incorrect. For some reason, That means that I'm not sure why it's like this. In contrast, with HTML and SVG, the browsers expose the various elements' interfaces as subclasses. For example, a element is observably a SVGCircleElement. Perhaps the browsers don't care enough about MathML to expose a typed interface to it. Whatever the reason, without JS types there's not much we can do about it in the scalajs-dom, as this repo is only supposed to reflect what exists in JS. On the plus side, if all we want is the ability to build MathML elements using Laminar (or other such libraries), we shouldn't need the help of JS types. We just need to define all the MathML attributes in a new trait in Scala DOM Types – similarly to how SVG attributes are defined there. In practice, Laminar will let you apply any of those MathML attributes to any MathML element anyway, the only benefit of having precise types in scalajs-dom would be to read them via The methods that Laminar does use internally are already defined on the common Element type, so I think now that we have the common MathMLElement type (that does exist in JS), we should be covered as far as scalajs-dom interfaces go. |
Specified interfaces can still be defined in scalajs-dom as |
Ah yes, good point. But... doesn't this mean that the Since we don't actually have user-accessible constructors for any of those types, I guess we could mix-in types like this: But, that brings me to another point that I forgot to mention, that could make all this moot. The spec of That's not unprecedented – those are simply un-reflected attributes. But the browsers also don't seem to implement the methods that the spec promises, e.g. the spec says elements should have a I'm now inclined to believe that the browsers implement only a subset of MathML spec, and the reason they haven't exposed other subtypes of MathMLElement, is that they did not implement any distinguishing features of those subtypes. I haven't exhaustively tested this, but a few attributes and methods that I tried are all absent from the real JS instances. Actually, this brings me to another problem that I've just realized. The
I think the main reason for those mistakes is the confusion between attributes (what you see in the text-based html/markml markup) and properties of element instances available via JS. Those are not the same, and even if some of them are mirrored (reflected), their names don't always match. @Quafadas Can you please adjust the MathMLElement class as per above? ^^^ The way I tested changes in the browser console is just by trying to read properties from an instance of a element. You can select the element from the rendered document in the browser's element tree, and in the browser console, type for example |
No, it doesn't. In Scala, a |
Haha now I have to wonder if I've never used that because I thought that I
couldn't, or the other way around!
…On Sat, Nov 16, 2024, 4:09 AM Sébastien Doeraene ***@***.***> wrote:
Ah yes, good point. But... doesn't this mean that the MathMLElement
sypertype would need to be a trait as well, instead of an abstract class?
No, it doesn't. In Scala, a trait can extend a class. 🙂
—
Reply to this email directly, view it on GitHub
<#869 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAECBMEIWIEGYA4NH6OYLAD2A4YYJAVCNFSM6AAAAABRPDFKNOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOBQGUZTSNRXG4>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
TL:DR I'll set out to modify the base MathML class as suggested. I'm confused though, on whether the remaining elements should be added at all? Are they traits? Should we simply have a I also fired up the browser tools, with this very simple example to try and improve my own understanding, and left more confused. Yey.
I've followed the breadcrumbs on the I guess, that I've been spoiled by scalaJS that I didn't realise, that could be and then that this works as expected. I'm feeling miffed, because before setting out , I did check; Where I understood it was being advertised as widely supported! MathML they said, it'll be fun they said. Just to that I understand, in essence scala-js-dom is the facade to browser API's. So in the end what matters, is what the browsers do, and I agree, that the browsers do not seem to expose these API's on the elements. Am I correct in thinking, that if I wanted to leave the "display" attribute in , it could be implemented in terms of the Would that be unidiomatic / stupid for scala-js-dom? Even if sensible, I'm not sure if I'd do it as I guess it's a lot of work for little gain? |
Yes, you're on the right track. We should just have MathMLElement base class, and forget about the traits, because there's nothing we could put in those traits anyway (since the attributes are not mirrored in the JS API, whether by spec, or by lack of implementation in the browsers). We can implement setting of mathml attributes using I think this arrangement would be perfectly appropriate for both scalajs-dom and Laminar – in line with how we normally do this, and accounting for the limitations of the underlying JS API. |
I think this is it then. A greatly simplified |
var mathbackground: String = js.native | ||
var mathcolor: String = js.native | ||
var mathsize: String = js.native | ||
var className: String = js.native | ||
var nonce: String = js.native | ||
var scriptlevel: Int = js.native |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Quafadas nonce
and scriptlevel
should also be removed. They're undefined
for me in both Chrome and FF
This is a follow up to #858 which added the base class for MathML elements.
The three elements added so far intend to make it "easy" to to check that I'm following the right sort of pattern as I haven't done this before - and then I'd add the remainder.