-
Notifications
You must be signed in to change notification settings - Fork 15
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
Support .ownerMathElement
(or something akin to it)
#241
Comments
[Workaround comment] Side-stepping the main question (which is interesting), would other kinds of workarounds be acceptable? One that avoids namespaces is testing for the MathMLElement interface
|
Indeed, that could be viable too. However, I believe |
[Workaround] Your best bet in that case is probably to make use of the element's Edit: Which I see you've added to OP missed that. |
Personally, I'd say checking Getting the owner element is useful, and consistent in the platform, even if not 100% required here. Was more using that as an example situation in which it could be used. |
Thanks this seems not unreasonable, but we have labeled this to be considered for mathml-core level 2. as we are limited in what we can add to mathml-core at this stage in the process. |
Hopefully this is the correct place for such a request, let me know if not!
I'm looking to add support for rendering MathML elements w/ the correct namespace in Preact, but an issue I'm running up against is that it's quite challenging for us to figure out the namespace an element currently lives in. For a (rough & a bit silly) example:
During the first rendering pass, we're able to keep track of the namespace as we delve into the children of
<math>
, however, whencondition
changes at some point in the future, we need to figure out the namespace before creating whichever element we're swapping to. This poses a bit of a challenge with the existing API.With SVGs, we use
.ownerSVGElement !== undefined
which is pretty effective. Unfortunately, modern MathML doesn't seem to have an equivalent we could use, though it looks like MathML 2 supported this.Is this by chance something worth supporting? Not quite sure yet how we can work around this as we have quite tight perf & size limitations.
Edit: We can use
.namespaceURI
to determine the existing namespace, but this is a bit less than ideal.The text was updated successfully, but these errors were encountered: