Re: [csswg-drafts] [css-overflow] Proposing `scroll-start`: allowing overflow scroll to not always start at 0 on 1st layout pass (#6986)

I agree with Sebastian that [`<position>`](https://drafts.csswg.org/https://w3c.github.io/csswg-drafts/css-values-4/#position) can replace the current value definition:

  > `[ auto | start | end | center | left | right | top | bottom | <length-percentage [0,∞]> ]{1,2}`
  
`<position>` is more powerfull. But it would need to accept flow-relative keywords `start` and `end` (like [<bg-position> in CSS Backgrounds 4](https://w3c.github.io/csswg-drafts/css-backgrounds-4/#typedef-bg-position), cf. #549).

---

I am a bit confused by `start` as the second value when it is omitted in the shorthand, and `auto` (not defined) as the initial value of the longhands.

CSS is not very consistent with default values in shorthands. Sometimes they resolve to a previous value (`margin`, `border-color`, etc), or the initial longhand value (`animation`, `font`, etc), or an arbitrary value (`background-position`, there does not seem to be many examples in this category).

The behavior of the first category feels more natural to me when specifying a logical shorthand value, ie. `end` would expand to `end end` instead of `end start`. This could also apply to `scroll-start-target` (the second value defaults to `none`).

---

I am not sure `scroll-start` and `scroll-start-target` can map to both their physical and flow-relative longhands. Which of the physical longhand should the first/second value map to?

All logical shorthands currently map to their physical longhands.

Related: #1282

-- 
GitHub Notification of comment by cdoublev
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6986#issuecomment-1541736241 using your GitHub account


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

Received on Wednesday, 10 May 2023 09:25:12 UTC