Open glen-84 opened 3 years ago
@glen-84 Thanks for the request and for using the template.
I'm a fan of logical properties. I like the consistency of using flow-relative language for everything, whether that's for grid and flex or for the box model and text alignment. I've been transpiling box model and text alignment logical properties and values using postcss-logical
, and enforcing their use with the use-logical
stylelint plugin and the property-disallowed-list
& declaration-property-value-disallowed-list
built-in rules.
We'll need to discuss whether this should remain a plugin or be built into core.
We generally favour using the disallowed/allowed-list
rules to enforce best practice rather than a specific rule. However, this case has a couple of things that may warrant a dedicated rule:
.foo:dir(ltr) { text-align: left; }
.foo { margin: logical 1rem 2rem 0.5rem 1rem; }
The introduction in the spec says:
Some aspects of a layout are actually relative to the writing directions, and thus will vary when the page is translated to a different system; others are inherently relative to the page’s physical orientation. [emphasis mine]
And goes on to give this example:
Documents might need both logical and physical properties. For instance the drop shadows on buttons on a page must remain consistent throughout, so their offset will be chosen based on visual considerations and physical directions, and not vary by writing system.
Can anyone think of a use case where an author would want to use physical box model properties alongside logical ones? The example above is for drop shadows which don't have an equivalent logical property in the spec. If there are use cases where physical and logical properties and values are used side-by-side then this differs from something like the color-function-notation
rule, where authors would want to use either modern or legacy color functions but not both in their codebase.
There's also the instability of the Four-Directional Shorthand Properties.
My gut says we leave this as a plugin for now until:
Hopefully, by then logical properties will be more widely used and the use cases better known, especially around how physical and logical might be used side-by-side. Until then, a plugin is a great place to experiment and iterate, e.g. implementing something for the unstable logical
keyword.
I'll label as discussion, so that people can share their thoughts on this.
This suggestion is interesting to me, too. But for now, I agree with:
My gut says we leave this as a plugin for now until:
stylelint-use-logical appears to be unmaintained. stylelint-use-logical-spec is an alternative.
Enforce the use of logical properties over physical properties, as a best practice.
A new rule that requires you to use logical properties like
margin-inline-end
instead of physical properties likemargin-right
.Browser support is quite high (https://caniuse.com/css-logical-props), but if this rule was implemented in the near future, some properties (f.e.
border-top-left-radius
) may need to be allowed until the equivalent logical property is better supported (esp. in Safari).Autofix would likely also be very useful.