Re: [csswg-drafts] [css-cascade] Additive CSS (#1594)

Looking into this more with @fantasai and @jensimmons, we think it's important to start this conversation with the long-term future in mind:

**Goal: make primarily flow-relative stylesheets as easy and pleasant to author as stylesheets using primarily physical coordinates.** 

The first important question to consider is whether or not the CSSWG can adopt this goal. This is harder than just making it *possible* to author in flow-relative coordinates (but we think it's worth it). Long term, we hope that flow-aware styles and layouts can become the default that all authors reach for when starting a new project. With tools & browsers now automating the translation of entire web pages, authors should be encouraged to create flow-relative layouts, even when the site itself does not contain bidirectional content.

**Use cases** for logical-first authoring:

* Multilingual websites.
* Graceful adaptation to automatic translation of web pages.
* Component libraries that can be used in a variety of written language contexts.
* More easily accommodating user reading preferences (horizontal vs. vertical writing, which is already offered as a feature in the Japanese eBook market).

## End State

While adding `*-logical` variants of each property seems reasonable as a short-term solution for `margin` and a few other properties (authors can use auto-complete to write long names), that becomes significantly more burden when extended to entire logical-first stylesheets including all the potentially affected properties and function syntaxes (box properties, `<position>` syntaxes, transform functions, etc.). Stylesheets written logically would be peppered with `logical` annotations, making them noisy to read and more work to type out—relegating logical styles to second-class status.

Therefore, to make logical-first stylesheets equally authorable, @fantasai and I believe we would ultimately need some kind of higher-level lexical switch.

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.
* Per-declaration syntaxes for targetted exceptions. 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. Another example is shadows, which need to reflect a consistent lighting source.

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>;
}
```

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.

Note: A mode switch (like `box-sizing`) that is attached to an element is also bad. In addition to the issues with global scope (previous note), it would require cascading the mode switch property before any shorthand declarations can even be parsed, nevermind cascaded.

## Roadmap

It's not possible to instantly implement logical shorthands for all affected properties and functional notations across the entire language, so realistically speaking moving to this new world is a multi-year project, consisting of several steps: 
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.

Note: For compatibility reasons, we can't adopt an @rule until we've defined the impact of switching every declaration to logical mode. 

## First steps

Property by property, function by function, we would need to adopt a convention that takes notations with bare coordinates (that are not explicitly associated with an axis or side) and gives them an explicit coordinate space (physical or logical).

Whatever syntactic convention we adopt for this, it needs to:
* be consistent across all properties and functional notations so affected
* not interfere with complex grammars, so that it can be used consistently everywhere without causing parsing or interpretation problems with the rest of the property/function grammar

Using `!keyword` fits these requirements. Appending `-logical` or `-physical` to property or function names fits these requirements. Using a bare keyword embedded in the value space does not.

-- 
GitHub Notification of comment by mirisuzanne
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1594#issuecomment-952424710 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 27 October 2021 00:07:25 UTC