Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-cascade-3] Editorial: Use logical properties in examples #5570

Open
r12a opened this issue Oct 1, 2020 · 4 comments
Open

[css-cascade-3] Editorial: Use logical properties in examples #5570

r12a opened this issue Oct 1, 2020 · 4 comments
Labels

Comments

@r12a
Copy link
Contributor

r12a commented Oct 1, 2020

4.7. Examples
https://www.w3.org/TR/css-cascade-3/#stages-examples

The table shows numerous example properties, but they are all physical. To encourage use of logical properties, why not convert many of them to logical properties? eg. text-align value could be start, border-top-width etc could be border-block-start-width etc, width and height could be block-size and inline-size.

The i18n WG believes that this will help raise the profile and subsequent use of logical properties.

@r12a r12a added the i18n-needs-resolution Issue the Internationalization Group has raised and looks for a response on. label Oct 1, 2020
@fantasai
Copy link
Collaborator

fantasai commented Oct 1, 2020

Hi @r12a,
The cascading and value processing of logical properties is somewhat complicated and not entirely solved, and also this spec is trying to transition to REC whereas logical properties is still WD, so I think using logical properties in this example would not be a good idea. (I think it is a good idea for examples in our various layout specs, though, where the processing model doesn't matter, only the input and end result.)

As for logical values like start, while we have clarity on what the computed value is, it's not entirely clear to me whether the “used value” is left or right, and that question while currently theoretical might end up being non-theoretical in the future, so I'd rather not lock it down one way or another with an example here. :)

So if you don't mind, I'd prefer to reject the suggestion against this particular example in Cascade. Though I'm quite open to using logical properties and values in our examples more generally elsewhere.
Let me know if you find this acceptable~

@r12a
Copy link
Contributor Author

r12a commented Oct 15, 2020

I guess that the issues you are alluding to are those in the css-logical issue [Order of inheritance vs. mapping in logical properties https://github.com//issues/3029) (?)

If so, shouldn't we have an open issue against the Cascade spec indicating that this needs to be resolved for this spec also? (It could just point to the css-logical issue for discussion, but i think there needs to be some indication that there's an open issue of that kind for css-cascade.)

@r12a
Copy link
Contributor Author

r12a commented Apr 15, 2021

@fantasai please change the tag on this to css-cascade-4, so that it doesn't cause you transition problems, and doesn't get forgotten for new work. Thanks.

@tabatkins tabatkins added css-cascade-4 Current Work and removed css-cascade-3 labels Apr 16, 2021
@fantasai fantasai added css-cascade-6 and removed css-cascade-4 Current Work labels Jun 7, 2021
@fantasai
Copy link
Collaborator

fantasai commented Jun 7, 2021

Pushing out to L6 because L4/L5 should be transitioning to CR soon (they're just blocked on some editing details for describing @import using the fetch framework or something). This was deferred pending css-logical-1 details solidifying, and that's still not happened.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants