[csswg-drafts] [css-position-3] Proposal for position: float; Mix sticky and relative positioning (#9200)

vrugtehagel has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-position-3] Proposal for position: float; Mix sticky and relative positioning ==
This is a proposal for `position: float;`. In a nutshell, it is mixing `sticky` and `relative` positioning.

## Some example use-cases

### Navigation menus

Probably one of the most common use-cases would be navigation bars. Often, we choose to use `position: fixed` for these; however, this ends up removing the element from the normal document flow, causing our document content to start _under_ the navigation bar. This means we need something like setting a `padding-top` on a container element around our content. That in turn means we're restricted to choosing absolute heights for our navigation menu (which often is fine, but awkward) and it means we have to manually adjust that `padding-top` in case our navigation menu wants to be sized differently across different screen sizes.

That's not where it ends, though; there are two followup cases that become significantly more painful without `position: float`;
 - Let's say we want a promotional banner above our navigation menu. Of course, we want this too to push content down, so we need to once again adjust our `padding-top`. However this time, we also need to move the navigation menu down, once again with a fixed length for the `top` property.
 - Let's say we have a sub-navigation menu (i.e. another navigation menu just below the main one) with some additional links, or breadcrumbs. This suffers yet again from the same issue; we're forced to give this a fixed height. It _cannot_ wrap the links, or our content will end up sitting under the navigation menus due to the fixed `padding-top`.

### Floating grid items

For the second example, let's say we're building a spreadsheet-like app. We arrange our cells in a grid using `display: grid`. The grid's parent is a scroll container, so the grid can be nice and large and we can scroll to see the overflowing cells.

Now, we want to "pin" the first _two_ columns to that scroll container. Setting `position: sticky;` with `left: 0;` on the cells in the first column would work just fine. However, for the second column, we are once again restricted to fixed sizes; `left` _only_ helps if our first column is not using content-based or flexibly sized. We are essentially forced to either
 - Fix the width of the first column, so we can use `position: sticky;` with `left`
 - Use `position: sticky;`, but use JavaScript to keep the `left` property updated for the second column.

With this proposal, we could give all the cells in the first and second columns `position: float;` and it would be exactly what we want (without even having to specify `left` or `inset`).


## Proposed behavior

If an element with `position: float;` doesn't have any scrolling ancestors, then it behaves like `position: relative;` (and so does the `inset` property and its longhands).

If that element _does_ have a scrolling ancestor, then the element "floats" with respect to the other content in that container. It will not visually move when scrolling the scrollable ancestor (like `sticky`), but it will still take up space in the document flow (like both `relative` and `sticky`). However, unlike `sticky`, which needs at least one of the `inset` longhands to have a non-`auto` value to have any effect, the element _always_ floats relative to its nearest scrolling ancestor. The `inset` properties move the element relative to the elements _original_ (unscrolled) position (like `relative`).


Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9200 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 16 August 2023 12:31:39 UTC