Skip to content
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

Should we push for equivalent/interoperable support for popover in MathML and SVG? #194

Open
bkardell opened this issue Apr 28, 2023 · 4 comments

Comments

@bkardell
Copy link
Collaborator

bkardell commented Apr 28, 2023

Recently, HTML has added 'popovers' - which allow some of the machinery related to various kinds of popup ui to be natively supported. It is getting widely implemented now, but is still of a bit limited use without its corresponding partner CSS Anchor Positioning. Once we have that too, I expect use to really take off as it makes it easy to do lots of useful popover/popup stuff.

However, while he originally had intended it for everywhere, @mfreed7 was encouraged to focus on HTML first at least. The result is that that stuff is landed without similar support in MathML or SVG. At least for MathML-Core this seems like it would be very useful and worth moving up to HTMLOrForeignElement or something?

@AmeliaBR @nikolaszimmermann

@mfreed7
Copy link

mfreed7 commented Apr 28, 2023

Thanks for raising the issue. I am (and was) supportive of supporting popover on Element rather than HTMLElement. @domenic was, I believe, the one that requested it be restricted, but I've since forgotten (and can't find) the rationale. Perhaps he can comment here, in case there's still a good reason not to support it.

@domenic
Copy link

domenic commented May 2, 2023

I think we discussed this in whatwg/html#8221 (comment) a bit. The precedent of hidden="" only applying to HTML is what tipped us over the edge to starting with only HTML.

Some thoughts:

  • Much functionality is HTML-specific today, e.g. most of https://html.spec.whatwg.org/#global-attributes . This problem might be better tackled holistically. (Also, as noted below, there's some tech debt to clean up before proceeding, I think.)
  • There's a general choice between "all namespaces" (Element) and "HTML + MathML + SVG" (HTMLForeignElement). Different features have made different choices here.
  • UA stylesheets are currently namespace-specific. [css-cascade-4] An "all-namespaces" user agent stylesheet csswg-drafts#8573 would need to be resolved before we had a proper place to put things that applied in all namespaces.
  • You might also want to distinguish between "works with other-namespace elements" vs. "works in other-namespace documents". Is it a good idea to give pure SVG documents (which some might think of as images) the ability to create popovers? Or MathML documents?
  • It's unclear whether you want to port over popovertarget="" and popovertargetaction="" as well.

@mfreed7
Copy link

mfreed7 commented May 5, 2023

Yep, those are indeed some good reasons. It sounds like nothing is really "fundamental" but more that there is a lot of clarification and cleanup needed before we could do this. Sounds reasonable to me.

  • You might also want to distinguish between "works with other-namespace elements" vs. "works in other-namespace documents". Is it a good idea to give pure SVG documents (which some might think of as images) the ability to create popovers? Or MathML documents?

This is a great question. My gut reaction is that we want the former (works with other namespace elements) and not the latter. It seems weird to have part of an SVG be a popover. Same for mathml. Though I suppose I could imagine some cool effects where part of an image/equation animates up and over to emphasize it?

  • It's unclear whether you want to port over popovertarget="" and popovertargetaction="" as well.

Since AFAIK there aren't button-like things in SVG or math-ml, I think I'd say no?

@bkardell
Copy link
Collaborator Author

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants