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

[Popup] Compatibility issue with existing <popup> use #341

Closed
tomayac opened this issue Apr 22, 2021 · 6 comments
Closed

[Popup] Compatibility issue with existing <popup> use #341

tomayac opened this issue Apr 22, 2021 · 6 comments
Labels

Comments

@tomayac
Copy link

tomayac commented Apr 22, 2021

The UA stylesheet changes introduced in crbug.com/1168738#c6 seem to cause compatibility issues with prior use of <popup>. While this is self-inflicted and was predicted (see @annevk's comment [I know this was written in the context of CE and the present issue is not about a CE]), it may seem nevertheless worthwhile to explore how much of a compatibility issue this is, especially since the Intent to Prototype message mentioned there were no compatibility issues.

@pepelsbey
Copy link

pepelsbey commented Apr 22, 2021

Some real life examples:

photo_2021-04-22 12 30 53

Reported by developers who (despite of Angular’s recommendations to prefix components) used <popup> element as is.

@gregwhitworth
Copy link
Member

Interesting - @mfreed7 @melanierichards either of you want to do some compat analysis?

@melanierichards
Copy link
Collaborator

Saw this on Twitter while out of office (thanks again folks for filing)...maybe we should hold on a compat analysis until we have a better idea on names for this element are reasonably in scope. Un-prefixed components might pose a problem with any name that is natural to reach for; it'll likely come up again with other new elements; and I don't think we should hold back the platform for improperly named custom elements. This issue is precisely why the author requirement for a hyphen exists. :) But if there's 2-3 names that seem reasonable and one of these minimizes conflicts with un-prefixed custom elements, maybe that's our winner.

Also, for awareness: https://bugs.chromium.org/p/chromium/issues/detail?id=1168738#c28

@mfreed7
Copy link
Collaborator

mfreed7 commented Apr 28, 2021

This is an interesting issue. I agree that I completely missed this potential issue in my intent to prototype. It seems that the compat concerns aren't awful, as there have only been a handful of bugs reported, and most were quickly resolved on the site-side by renaming the element. But it would definitely be good to do this analysis in advance of actually shipping either <popup> or <selectmenu> to the web platform.

@melanierichards thanks for linking that commit. That was in response to this bug: https://crbug.com/1199964. When I added <popup> to the codebase behind a flag, I didn't prevent the UA stylesheet from doing a display:none !important for closed popups, which hid any non-standard <popup> elements a site used. This has been fixed now in Chromium M91, but not in (already stable) M90.

@github-actions
Copy link

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.

@github-actions github-actions bot added the stale label Mar 19, 2022
@mfreed7
Copy link
Collaborator

mfreed7 commented Mar 19, 2022

Since we're not doing a new element for popup, I think we can just close this.

@mfreed7 mfreed7 closed this as completed Mar 19, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants