search

w3c / csswg-drafts

CSS Working Group Editor Drafts
https://drafts.csswg.org/
Other
4.43k stars 652 forks source link

[CSS-POSITION-4] Define a way to have a dialog anchored to an element #5304

Open gregwhitworth opened 4 years ago

gregwhitworth commented 4 years ago

<dael> TabAtkins: If we ever do want to attach to an element some mech is the thing being used to position non-anchor dialogs. If we switch non-anchor to fixedpos we have to figure out how to do it for non-anchored.

<dael> iank_: I think a different solution for anchoring down the road

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

una commented 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.

melanierichards commented 4 years ago

^ 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.

ShanonJackson commented 2 years ago

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.