Replies: 4 comments 4 replies
-
|
An initial PoC implementation of converting the existing dialog (without breaking changes) can be found here: |
Beta Was this translation helpful? Give feedback.
-
|
A major problem/concern with static implementations like this is related to how This is basically a deal breaker because we can't reliably position child elements relative to the viewport without developers being aware of the caveats. Our main goal with this static implementation is related to how we want to enable an easier usage of components to avoid dynamically generating DOM on the developers behalf and appending it to the We really need the browsers to implement a |
Beta Was this translation helpful? Give feedback.
-
|
We will eventually get access to adding our own elements to the |
Beta Was this translation helpful? Give feedback.
-
|
The new Chrome status: There is also a popover polyfill available already: |
Beta Was this translation helpful? Give feedback.
-
|
I believe the tracking for Firefox is here: |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
Safari shipped |
Beta Was this translation helpful? Give feedback.
-
|
Proof of concept work on this has begun in the next-overlay branch. Initial assessment is positive in regards to functionality and styles, but accessibility will suffer in the short term until some newer HTML specs are merged and implemented in various browsers. Currently the accessibility aspect only works in Chrome Canary at the of writing thanks to the ARIA reflection API (Safari has it implemented, but isn't hooking the elements up in the AOM yet). More information about status of these APIs can be found here. |
Beta Was this translation helpful? Give feedback.
-
Proposal
Refactor all dynamic components to allow for using a "fixed" positioning strategy by default to allow for using statically inline
without needing to dynamically create the element instance and append to the DOM (defaults to the currently).
This would allow for content to stay inline in the location of the DOM where it was added, but render relative to the .
The biggest benefit for this change is to ensure that the content of these floating elements stays intact in its original location
making this much easier to use with frameworks.
We could technically support both the existing usage as well as the new static usage, with static being the default as it's more intuitive and easier to manage.
Affected components:
When it comes to components like the dialog or bottom-sheet, this is already feasible to support currently, but we should
adjust our default expectation to use these components statically rather than dynamically.
Benefits
DialogServicein Angular, or custom<ForgeDialog>wrapper element in React, but we could still support those for people that want to use it in true dynamic fashion.Caveats
One potential concern is that the static usage enables bindings to potentially run/update even when the dynamic elements are not visible. This depends on how the consumer is using it, but the potential is there and it could have a (negligible) impact on performance and memory. I'm not too concerned about this since it could be fixed with guidance and examples to help promote correct usage, and ensure developers are aware of it in general.
Beta Was this translation helpful? Give feedback.
All reactions