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:

• Multilingual websites
• Automatic translation of web pages
• Component libraries that might be used in a variety of written language contexts
• Accommodating reading preferences (horizontal vs vertical writing, which is already offered as a feature in the Japanese eBook market)

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:

<coordinate-mode> = [ logical | physical ] or [ relative | absolute ] or ...

@mode <coordinate-mode>; /* must come after @import and before any style rules */

@mode <coordinate-mode> { <stylesheet> }

selector {
  property: value  !<coordinate-mode>;
}

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.
2. Make sure everything that can have logical/physical variants has both. (Years-long process.)
3. 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.