Open gregwhitworth opened 4 years ago
I love this! I feel this would be a huge help for tooltips, menus, animations, and other relationship-based interactive items without using translation and hacking around positioning. This enables dynamically sized tooltips to be positioned more easily and improve linked submenu element positioning as well.
When I think of syntax for this, I am reminded of what gradients use for radial/conic positioning. I'd love to have the ability to anchor using the keywords "at top center", "at bottom center", "at left center", "at right center", "at center", "at top left", "at top right", etc. That being said, it doesn't account for logical positioning. On the same thread as radial/conic gradient placement as well, this could be percentage-based in addition to the keywords (i.e. 20% 20%)
It sounds like this might work best as a function that accepts position values.
^ A few of us were talking about anchored positioning in the context of various classes of popups. It could be interesting to have some platform-enabled automatic anchoring that could take into account both writing mode and available space to render said anchored element, in order to mimic how some rendering engines position popup parts of native elements like <select>
.
If there's interest in creating a new keyword set around positioning, component libraries indicate that level of control would likely be desirable to authors. Some components provide mechanisms to customize the direction in which the popup is displayed in relation to the activating element. Literal positioning (top-center
) and logical positioning (block-start-center
) both seem relevant.
I don't think the solution needs to introduce new syntax.
position absolute, top 100% puts you below your relative parent position absolute top -100% puts you above your relative parent position absolute left 100% puts you on the right of your relative parent position absolute left -100% puts on the left of your relative parent
You can then use a combination of these with transform and calc to reach all desired positions without knowing the height/width of the relative parent ahead of time.
We just need to allow the dialog element itself to be positioned with css and then this should be enough to be able to achieve the desired outcome?
The true power of dialog is that it allows you to break overflow:hidden ancestors.
I think we should open a separate issue for this because authors do want this capability outside of the specific
<dialog>
need (eg: tooltips, dropdown menus, etc). So this should be thought about sooner rather than later. In the research that @annevk shared there are many examples that are not centered and are anchored to an element. While I get the implementation concerns I'm also curious of making the dialog itself the scroller via overflow behavior is the right way. Most of the scenarios that come to mind however normally don't fit in what seems to be the primary definition (based on what is shipping) as a<dialogue>
.cc: @melanierichards
Originally posted by @gregwhitworth in https://github.com/w3c/csswg-drafts/issues/4645#issuecomment-655847121