- From: Sebastian Zartner via GitHub <sysbot+gh@w3.org>
- Date: Wed, 29 Nov 2023 12:13:44 +0000
- To: public-css-archive@w3.org
> > I think it would help to give the data types more expressive names like `<position-one-axis>`, `<position-two-axes>`, `<position-two-axes-with-offsets>`, and `<position-two-axes-with-one-offset>`, or so. > > I think there's a readability balance to be had between splitting things up and abstracting them vs writing them inline, and I think the production structure in Tab's grammar finds a good balance. It's also perfectly suited to hooking together the bg-position and position grammars. Just to make sure we're not talking past each other. I meant to rename `<position-one>` to `<position-one-axis>`, `<position-two>` to `<position-two-axes>`, `<position-four>` to `<position-two-axes-with-offsets>`, and `<position-three>` to `<position-two-axes-with-one-offset>`. I didn't mean to abstract things further. > > Was there a reason not to allow combinations of logical keywords and `<length-percentage>`? > > See the `<position-four>` grammar. I was talking about a logical two-value complement to ```ebnf [ left | center | right | x-start | x-end | <<length-percentage>> ] [ top | center | bottom | y-start | y-end | <<length-percentage>> ] ``` So, e.g. `block-start 10%` or `100px inline-end`. > > So, for example, for a value of 10% y-start, the origin for the percentage is then interpreted as x-start value. > > I think this is a bit too much magic, since if I replace `y-start` with `center`, the interpretation of 10% flips from `x-start` to `left`. That's a great way to introduce errors. > We could potentially loosen that restriction across the board, but this is such an old production that I'd be legitimately afraid of accidentally activating currently-invalid code. It also runs into the ambiguity issue Elika was worried about - `center` doesn't imply an axis at all, so using it with a lenper means we have to impose axises arbitrarily, and if you're relying on the direction disambiguation you'll get a surprising flip of the directions. My point was just that we _could_ define smart interpolation rules in case the start and end value "fit together", as shown in the example I gave, and fall back to the top left coordinate system if they don't. Though as long as authors can interpolate e.g. between `top` and `block-end` and `block-start 10px inline-start 20px` and `block-end 30px inline-end 40px`, it's probably fine. As I said earlier, authors probably won't care much about whether the values are converted to the top left coordinate system when interpolating them. Sebastian -- GitHub Notification of comment by SebastianZ Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/549#issuecomment-1831780897 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 29 November 2023 12:13:46 UTC