Proposal:

During parsing of a css declaration block, shorthands (like margin and all) expands only to the set of longhand (grouped by mapping logic: so either logical or physical) required to describe their value, and by default resort to use physical properties if both sets are possible. Note that they can only expand if they do not contain var() substitutions.

During serialization, each logical property group is considered, and shorthand values can be emitted instead of the longhands only if the all the longhands of the same mapping logic are present and consecutive (ignoring all properties that are not in the group). Otherwise, the shorthand is not used when serializing the properties in the group.

During serialization, a specific rule should be added in case all longhand properties of one mapping logic are defined, and are followed by all longhand properties of the other mapping logic (this would result in the shorthand being emitted twice, in which case the rule would discard its first appearance)

ex:

margin-top: 0px; margin-left: 0px; margin-bottom: 0px; margin-right: 0px;
margin-inline-start: 10px; margin-block-start: 10px; margin-inline-end: 10px; margin-inline-end: 10px

should serialize as margin: logical 10px (if supported) or just margin-inline-start: 10px; margin-block-start: 10px; margin-inline-end: 10px; margin-inline-end: 10px (otherwise), ignoring the set of longhand properties of physical mapping logic whose all values are to be ignored in the end.

When removing a shorthand property, all the longhand associated with that shorthand should be removed, regardless of their mapping kind.

(all not setting the logical properties only works however if margin-inline-start: inherit has the exact same behavior as margin-left: inherit and does not inherit from margin-inline-start from the parent if that parent has a different writing mode)

proposed text for the statement above would be something like:

logical properties cannot inherit.
when a logical property should inherit, the physical property it maps to must inherit instead

I'm reasonably happy with @FremyCompany's proposal above. One thought about another option is that we could say that appending a shorthand property could set all of its constituent shorthands of one mapping logic and also remove all of the constituent shorthands of the other. We could even go further and do that same removal during serialization.

I'd also note that we need to consider shorthands (e.g., border) where some of the longhands form logical property groups but some do not (the longhands of border-image). (border is also special because its longhands include three logical property groups, for border-color, border-style, and border-width.)

The CSS Working Group just discussed CSS Logical Properties, and agreed to the following:

• RESOLVED: proposal from fremy: During serialization, each logical property group is considered, and shorthand values can be emitted instead of the longhands only if the all the longhands of the same mapping logic are present and consecutive (ignoring all properties that are not in the group). Otherwise, the shorthand is not used when serializing the properties in the group.
• RESOLVED: proposal from fremy:During serialization, each logical property group is considered, and shorthand values can be emitted instead of the longhands only if the all the longhands of the same mapping logic are present and consecutive (ignoring all properties that are not in the group). Otherwise, the shorthand is not used when serializing the properties in the group.

Spec edits have been made, https://bugzilla.mozilla.org/show_bug.cgi?id=1675514 adds tests and fixes Gecko to follow the new spec text.

@emilio Not sure if I get it the spec text right, taking for example this declaration block:

margin-top: 10px;
margin-right: 10px;
margin-left: 10px;
margin-inline-start: 10px;
margin-block-start: 10px;
margin-block-end: 10px;
margin-inline-end: 10px;
margin-bottom: 10px

So we reach the new step with

property = margin-top
already-serialized = []
shorthands = [margin, all]
shorthand = margin
longhands = [margin-top, margin-right, margin-left, margin-inline-start,
             margin-block-start, margin-block-end, margin-inline-end, margin-bottom]
current-longhands = [...longhands]

Then, we have mixed mapping logic, but all declarations in declaration block are in current longhands, so it seems to me we would serialize using margin?

@Loirooriol how so? if shorthand is margin, only margin-top, margin-right, margin-left and margin-bottom should be in current longhands, right? What makes the logical properties end up in there? They're not mapped to margin... and yeah, the "mapping" terminology used in that section of the spec is not great, but basically current longhands is meant to be "the longhands shorthand expands to", which for margin doesn't include the logical properties.

@emilio Didn't we decide this:

During parsing of a css declaration block, shorthands (like margin and all) expands only to the set of longhand (grouped by mapping logic: so either logical or physical) required to describe their value

So margin is a shorthand of both the physical and the logical longhands, and the set of properties it expands to depends on the value. (Of course that's not what implementations do, but I think is how it's supposed to be?)

I don't think we resolved on that, did we? The only shorthand that includes both logical and physical properties is all, and the order of its expansion should be defined in that case, but the algorithm would handle that correctly afaict.

Well that was the "First proposal from fremy" and I think we resolved it, though in the "RESOLVED" the wrong text was copied (so both resolutions are identical)

So even if we resolved on this:

First proposal from fremy: During parsing of a css declaration block, shorthands (like margin and all) expands only to the set of longhand (grouped by mapping logic: so either logical or physical) required to describe their value, and by default resort to use physical properties if both sets are possible. Note that they can only expand if they do not contain var() substitutions.

still it seems the new spec text isn't wrong as long as margin is defined to be a shorthand for only physical properties... If / when that changes we might want to revisit that.

I still think the above proposal is wrong. all should expand to both logical and physical properties IMO.

So even if we resolved on this:

First proposal from fremy: During parsing of a css declaration block, shorthands (like margin and all) expands only to the set of longhand (grouped by mapping logic: so either logical or physical) required to describe their value, and by default resort to use physical properties if both sets are possible. Note that they can only expand if they do not contain var() substitutions.

still it seems the new spec text isn't wrong as long as margin is defined to be a shorthand for only physical properties... If / when that changes we might want to revisit that.

I still think the above proposal is wrong. all should expand to both logical and physical properties IMO.

On second thoughts, I did not consider all very well in my statement. I thought only of hypothetical properties like margin that would cover both logical and physical longhands part of the same group. In the case of all, it is more difficult to figure that out, because that would potentially depend for each group (could be physical for margin, but logical for padding).