- From: Florian Rivoal via GitHub <sysbot+gh@w3.org>
- Date: Wed, 20 Dec 2023 03:07:47 +0000
- To: public-css-archive@w3.org
Mostly agree with @MurakamiShinyu. 2 questions, one about the abilities we expose, and one syntactical:
* regardless of what we call them, just like we need both `trim-start trim-adjacent allow-end` and `trim-start trim-adjacent trim-end`, maybe we need `space-first trim-adjacent trim-end` in addition to `space-first trim-adjacent allow-end`? Even if we only pick one, I'm actually not sure which of the two matters most.
* For the choice between `trim-end` and `allow-end` together with `trim-start trim-adjacent` (and maybe with `space-first trim-adjacent`, depending on the answer to the previous question), the spec currently proposes to have an optional `allow-end` additional keyword, whose omission means `trim-end`. In the comment above, @MurakamiShinyu proposes a distinct single keyword for each possibility. I am not sure which is preferable:
* `normal | space-all | trim-all | trim-start | trim-auto | space-first | space-auto‡`
‡ `space-auto` is meant as a stand-in for variant of `space-first` which has the other behavior between `allow-end` and `trim-end`
* `normal | space-all | trim-all | trim-auto | [ space-first || allow-end ]`
I suspect the later makes it easier to progressively open up to additional arbitrary combinations of `?-start ?-adjacent ?-end` later. Not entirely sure whether that's a good or bad thing.
--
GitHub Notification of comment by frivoal
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9511#issuecomment-1863780296 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 20 December 2023 03:07:50 UTC