Logical (Flow-relative Syntax)

See Flow-relative syntax for margin-like shorthands and related issues.

[!IMPORTANT] This wiki page is a recording of ideas under the presumption that CSS should, in the future, be easy and pleasant to author when working primarily in flow-relative coordinates.

The CSSWG has yet to adopt this principle. We hope it will.

Use Cases

Logical-first authoring is important for the following use cases:

Goal

To make logical-first stylesheets easy and pleasant to author, we will ultimately need some kind of lexical switch. Relying solely on a per-property syntax, such as those proposed so far, would make logical mappings a second-class citizen to physical mappings.

Overall the proposal that seems to make the most sense is to provide an at-rule that switches the entire stylesheet file—or a designated block of it—to logical mode for every property that has both, and to also provide per-declaration syntaxes for targetted exceptions.

Note: A mode switch that is not lexically scoped would cause declarations written without knowledge of this style sheet to be re-interpreted in an unexpected coordinate mode. This is bad.

For example:

= [ logical | physical ] or [ relative | absolute ] or ... @mode ; /* must come after @import and before any style rules */ @mode { } selector { property: value !; } For example, if a box has a margin to avoid drawing over part of a background image, this needs to be a physical margin even if the stylesheet is written in logical coordinates overall in order to accommodate translations. ## Plan Realistically speaking, moving to this new world is a 7-10-year project: 1. Adopt per-declaration syntax switch, to be defined as valid on a property-by-property basis. 1. Make sure everything that can have logical/physical variants has both. (Years-long process.) 1. Adopt @rule for switching syntax at a higher level. For compatibility reasons, we can't adopt an @rule until we've defined the impact of switching every declaration to logical mode. ## Phase One: Per-property Switch If we're to adopt the plan of having a lexical switch, this presents several constraints on our choice of syntax: - It has to be possible to apply to any property grammar, so that all properties have a consistent syntax for this switch. - It has to be possible to be valid or invalid per property, so that properties that don't have their logical behavior defined yet cannot accept the notation. - It might be nice if this syntax can also fit within a functional syntax, e.g. for gradients. Using the `!keyword` proposal fits these requirements. Using a bare keyword does not.