[css-logical-1] spec should introduce propdef table notation for logical properties

[dbaron]

The section on Box Model Properties introduces a large number of new properties which are very different from all other CSS properties in that they don't have independent computed values, because their computed values mirror another CSS property. While this is expressed in the prose, it seems like it should be expressed in the propdef table, since other specifications will (hopefully) be introducing similar properties, and it would be good to have a consistent notation for introducing them rather than doing so with prose that may come over time to have normative differences.

I got here from w3ctag/design-reviews#286.

[dbaron]

Also, I think there's a decent case to be made that the relevant propdef table entry should say both:

• which element's writing mode is used for the logical mapping, and
• which physical properties are being mapped to.

[Loirooriol]

other specifications will (hopefully) be introducing similar properties

This is already happening, e.g. https://drafts.csswg.org/css-overflow-3/#logical

[fantasai]

For properties, the mapping is always using the writing mode of the element itself. So that shouldn't need to go into the propdef table.

[fantasai]

If we do this, rather than adding a statement like @Loirooriol proposes in #3033 then I think it would be something like:

Logical Property Group: <identifier>

where the identifier would typically be the most specific common shorthand of all the properties. (margin, padding, border-style, border-color, inset, etc.)

If we go with a statement, I would go with, e.g.:

The longhands of 'border-style' form a logical property group.

so we don't have to list everything out. Easier to read, less likely to forget one.

[Loirooriol]

Logical Property Group: <identifier>

Works for me. But this should also appear in the associated physical properties, not just the logical ones. Because a logical property group has both.

The longhands of 'border-style' form a logical property group.

According to https://drafts.csswg.org/css-backgrounds/#border-style, border-style is only a shorthand for the physical properties.
CSS Logical seems to imply that it's a shorthand for both the physical and logical properties, but that part is considered unstable (#3030).
So I think this kind of statement that doesn't list everything is not completely clear.

[css-meeting-bot]

The CSS Working Group just discussed [css-logical-1] spec should introduce propdef table notation for logical properties, and agreed to the following:

• RESOLVED: Add an optional line in propdef table for logical property groups

The full IRC log of that discussion

<dael> Topic: [css-logical-1] spec should introduce propdef table notation for logical properties
<dael> github: https://github.com//issues/2822
<dael> fantasai: Need to ID properties that belong to logical prop group
<dael> fantasai: ONe way is shorthand in prose but suggested we add a new link to propdef tables for proeprties part of logical property mapping group with same ID
<iank_> An example of only looking at the "set" of properties: https://www.software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22display%3A%20-webkit-box%3B%22%3E%0A%20%20%3Cdiv%20style%3D%22-webkit-box-ordinal-group%3A%202%3B%22%3EA%3C%2Fdiv%3E%0A%20%20%3Cdiv%20style%3D%22order%3A%203%3B%22%3EB%3C%2Fdiv%3E%0A%3C%2Fdiv%3E
<dael> fantasai: If we do this I think it should be optional in propdef so we don't have a bunch of empty fields
<dael> astearns: Do you agree with oriol about in associated phsyical properties?
<dael> fantasai: Of course. They're part of the logical property group
<dael> astearns: How many specs, how many properties?
<dael> fantasai: B&B, positioning, scroll-snap, and box are the only one effected, I think
<dael> fantasai: border, margin, padding, scroll snap margin and padding, inset properties
<dael> fantasai: Most specs not effected which is why I think when making propdef don't include unless needed
<oriol> overflow too
<dael> astearns: Opinions?
<dael> astearns: oriol mentioned overflow
<dael> fantasai: Yeah
<fantasai> s/effected/affected/
<dael> astearns: Prop: Optional line in propdef table for logical property groups
<dael> fantasai: Yeah. May fiddle with name.
<dael> heycam: I also see groups for min size and max size?
<dael> fantasai: Yeah, sizing also affected
<dael> astearns: Objections to adding a line?
<dael> RESOLVED: Add an optional line in propdef table for logical property groups

[cdoublev]

Can you please tell me what would be the group identifier for block-size, inline-size, width, height? size?

And would you accept a PR to add the field in the appropriate property definition tables (do you have some convention/preference for the definition field order, maybe between Applies to and Inherited?), or someone is already planning to do it soon?

[Loirooriol]

I don't think it matters. But Blink, WebKit and Gecko use size for {block-size, inline-size, width, height}. This is the list of their logical property groups names:

• Blink: border, border-color, border-radius, border-style, border-width, contain-intrinsic-size, inset, margin, max-size, min-size, overflow, overscroll-behavior, padding, scroll-margin, scroll-padding, size, visited-border-color
• WebKit: border-color, border-radius, border-style, border-width, contain-intrinsic-size, inset, margin, max-size, min-size, overscroll-behavior, padding, scroll-margin, scroll-padding, size
• Gecko: border-color, border-radius, border-style, border-width, contain-intrinsic-size, inset, margin, max-size, min-size, overflow, overscroll-behavior, padding, scroll-margin, scroll-padding, size

I don't think anybody is planning to do it soon. Better confirm the details with editors of the affected specs.

[cdoublev]

I was hoping to generate a representation of logical property groups/mappings with types similar to the following:

Group   => [Mapping]
Mapping => [PropertyName]

I do not need an explicit Mapping propdef but for example, physical/logical contain-intrinsic-* longhands are defined in the same table, whereas scroll-padding-* longhands are separated in different definition tables for the different mappings.

EDIT: actually, I need an explicit mapping identifier for each property but I think w3c/reffy would be able to extract it (@tidoust) from the section title above the propdef table.

I do not want to make a selfish request but please let me know if you think that some consistency should be applied. I would be happy to help.

[tabatkins]

I'm not sure I understand what you're asking about.

[cdoublev]

The procedures set a CSS declaration and serialize a CSS declaration block require to check whether a longhand 1. belongs to the same logical property group and 2. has a different mapping logic, than another longhand. A Logical property group propdef field allows to check 1 but to check 2, the logical property group, containing a set of longhand names, requires to be splitted in two subsets, corresponding to a mapping logic.

For example:

const logicalPropertyGroups = [
  // ...
  'size': [
    ['block-size', 'inline-size'],
    ['height', 'width'],
  ],
  // ...
]

In specs, some longhands of the same logical property group and with the same mapping logic, are defined in the same definition table, which appears below a section title, eg. Physical Longhands for scroll-padding.

w3c/reffy can take advantage of this grouping in the same table, and of this title, to define a mappingLogic field for the longhands defined in this table.

But for some other longhands, like contain-intrinsic-*, both flow-relative and physical longhands are defined in the same table.

Solutions are:

1. add a Mapping logic propdef field
2. consistently define longhands with same/different mapping logic in same/different propdef table, below a title named after the corresponding mapping logic
3. status quo: manually maintain the list/sublist of logical property groups and mapping logics

[tabatkins]

Ah, I see what you mean. Apologies, I wasn't fully up-to-date on the algorithms.

[cdoublev]

Now fixed in #7950. Now, at least, I can automatically watch for new logical properties and manually add them to the corresponding mapping logic subset.