[cssom] We may not want .setProperty() to change the order if it's setting an identical value to an existing declaration

[upsuper]

So in #1898, we resolved to have .setProperty() behave like appending rather than changing in-place. It causes problem that browsers become unable to optimize out setting identical values. When that happens in inline style, that can consequently trigger mutation event and observer.

From Gecko we have seen bug 1449584 and bug 1460295 related to this issue.

It seems Blink currently appends declaration when it's changing the value, and does nothing otherwise.

If we want to go that way, for the issue raised in #1898, it means although code like

elem.style.marginTop = "1px";
elem.style.marginBlockStart = "2px";
elem.style.marginTop = "0px";

would still work as expected, but something like

elem.style.marginTop = "1px";
elem.style.marginBlockStart = "2px";
elem.style.marginTop = "1px";

would not.

It's not clear to me whether that's something reasonable.

(Avoiding changing the declaration block when updating declaration with identical value wouldn't affect fixing #2515, though, which is good.)

[tabatkins]

I think it's quite a problem if the second example doesn't set the top margin to 1px. The whole point of the order-changing is to make sure you can treat the logical and physicals as aliases of each other, and in this case, the current value "the top margin" is 2px, and you're changing it to 1px. The fact that a previous value was 1px is irrelevant to the author.

[upsuper]

If we don't want to change the resolution in that case, I hope other browsers can follow the change as soon as possible, since that has started causing issue for us... If other browsers don't want to do this, Gecko may probably need to revert the behavior for webcompat reason at some point...

[FremyCompany]

I think a middle ground can be found here. You are allowed not to reorder the properties if there are no properties defined after the one you just set that would override yourself.

elem.style.marginTop = "0px";
elem.style.marginBlockStart = "100px";
...
elem.style.marginTop = "0px"; // fires a style attribute update

but

elem.style.marginTop = "0px";
elem.style.paddingBlockStart = "100px";
...
elem.style.marginTop = "0px"; // doesn't fires a style attribute update

[emilio]

That looks somewhat confusing from the developers' perspective, I think... But could work I guess. It could be confusing specially when setting a shorthand and only some properties get moved away...

[emilio]

It's also a bit messy I think... You'd need to check all the potentially affected logical counter-parts...

[FremyCompany]

Not really related but just to show that we need to change that serialize spec anyway:
https://jsfiddle.net/au00bj23/

I tried to run the steps defined in cssom in my head three times already, I still don't understand how browsers arrive at the result they currently arrive in.
https://www.w3.org/TR/cssom-1/#serialize-a-css-declaration-block

[upsuper]

That is related to #2515, which needs a separate fix to the serialization algorithm. And requiring appending for setting different value is a prerequisite of that fix.

[FremyCompany]

The problem isn't only with variable properties, nor only with the order in which things are defined in the array. An amazing example: https://wptest.center/#/w1gw11

So this is just a mess.

Here is how we currently do things in Edge and how I plan to potentially extend things in the future at the moment:

• Properties are always serialized in the same order, regardless of their order in the array (margin always before padding, etc...)
• All the logical properties we will add will be shadowed under a fully-encompassing shorthand (e.g. "margin"), and serialization of all the longhands associated to this shorthand (e.g. "margin-top" and "margin-block-start") will always happen at the location where that full shorthand would be serialized if it could be. Their relative order will be preserved (is "margin-top" before or after "margin-block-start") but not their order in the full sequence (is "padding-top" before "margin-top").

This way we should limit the style attribute changed notification to a minimum while preserving correctness. Whether our implementation actually stores the full order or not doesn't matter because the serialization step normalizes that order away where it doesn't matter.

[upsuper]

Hmmm... I see what you mean. That's definitely another issue related to shorthand serialization. The algorithm is broken in that case as well :/

So you are proposing a different algorithm which doesn't preserve the order in general, but the order between physical properties and their corresponding logical properties? Hmm...

[upsuper]

I think the right solution to that problem is that, both logical and physical properties should be subproperties of their corresponding shorthands. That is also the only feasible way to implement the logical keyword in the four-direction shorthands.

But then we are going to have problem with margin-{inline,block} etc. again :/

[FremyCompany]

Just realized there was no test case for the actual issue described here, so I created one.
https://wptest.center/#/l6dif3

[FremyCompany]

And, again, based on my experiments, it's totally doable to pass this test yet fire no attribute modification (didn't yet adapt the style serializer to serialize depending on the order of logical-able properties, so the "style" attribute and its internal representation do not round trip, but since this is not the only case I'd be tempted not to care about it until someone actually rewrite the algorithm to consider more cases)

[emilio]

I believe this was fixed in #2924, please reopen otherwise.