https://drafts.csswg.org/css-values/#funcdef-toggle

To determine the computed value of toggle(), first evaluate each argument as if it were the sole value of the property in which toggle() is placed to determine the computed value that each represents, called Cn for the n-th argument to toggle(). Then, compare the property’s inherited value with each Cn.

But for example, consider https://drafts.csswg.org/css-grid/#grid-auto-flow-property

Value: [ row | column ] || dense
Computed value: specified keyword(s)

I guess "specified keyword(s)" means that column dense and dense column have different computed values.

However, Chromium normalizes them into GridAutoFlow::kAutoFlowColumnDense.

This was fine before toggle() since https://drafts.csswg.org/cssom/#serializing-css-values says

If certain component values can appear in any order without changing the meaning of the value (a pattern typically represented by a double bar || in the value syntax), reorder the component values to use the canonical order of component values as given in the property definition table.

But adding toggle() breaks this, e.g.

grid-auto-flow: toggle(column dense, row, dense column, row dense);

should produce row for column dense and row dense for dense column. But for UAs that compute dense column to column dense, it will always be row.

From an implementation point of view it would be annoying to have column dense and dense column as different computed values, so I think that toggle() should somehow normalize the computed values before comparing them. For example, by comparing serializations instead of raw computed values.

Another approach would be analyzing all property tables and ensuring that the "Computed value" field makes equivalent things have the same computed value, but this seems more fragile and annoying for spec editors.