-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Add MathMLElement
interface and mixins ElementCSSInlineStyle
, HTMLOrForeignElement
#4143
Conversation
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.
I noticed it used mixins that were not there yet, which are also used for the interfaces
SVGElement
andHTMLElement
, I've added them as well and removed the redundant attributes from interfaces that inherit from these.
This is unfortunately a breaking change, so we can't do this yet.
We prefer getting the bindings from the specification instead of from browser implementations. See https://www.w3.org/TR/MathML2/appendixe.html#dom-bindings.IDLBinding.
A changelog entry is missing as well.
What's the policy here? Accumulate more breaking changes at once? Though I think it's a "minor breaking change" if at all, everything should be working as expected, as the methods just shift towards the parent interfaces, and coercion should do the rest, I'm not sure if that's even considered a breaking change? We could also leave the methods on the child interfaces there, and accept the duplicated methods, so that it's not a breaking change.
Thanks for the link, I missed that (although I studied the specs as well). AFAIK this browser implementation is a subset of the specs. The motivation for this change, is to have a I think I'll just add the sub-interfaces as well, so that we have a complete and more accurate representation of MathML then? |
Well I guess it is, when it's used explicitly: So that leaves this suggestion:
|
I think at this point we have more then enough changes lined up for a breaking change. See #4090.
Indeed, this sounds reasonable. |
1c00324
to
3c1e334
Compare
I've updated this to not be a breaking change anymore. Well yet another time it turns out how messy the specification and its implementation in browsers is, e.g. https://www.w3.org/TR/MathML3/chapter2.html#fund.globatt specifies |
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.
Thank you for cleaning up the mixin interfaces!
…MLOrForeignElement`
…HtmlSelectElement`, `HtmlTextAreaElement`, and use deprecated notice instead.
…LOrSVGElement` and `TouchEventHandlers`
Co-authored-by: daxpedda <[email protected]>
0d64159
to
c240696
Compare
(force push, because CI didn't run successfully, but I don't think that failed test is related to the PR) |
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.
Thank you for the patience!
c56157c
to
6659911
Compare
…t`s (#765) As noted in #621 (comment), rustwasm/wasm-bindgen#4143 is now added in wasm_bindgen 0.2.96. This PR updates all the dependencies of xilem_web and finally correctly supports `style` for `MathMlElement`.
This aims to add the
MathMLElement
interface, from https://searchfox.org/mozilla-central/source/dom/webidl/MathMLElement.webidlI noticed it used mixins that were not there yet, which are also used for the interfaces
SVGElement
andHTMLElement
, I've added them as well and removed the redundant attributes from interfaces that inherit from these. I can keep it more focused on only theMathMLElement
addition if that is desired. Was the omittance ofElementCSSInlineStyle
intentional?