whatwg
Make the dictionary <-> ordered map correspondence clearer about order
Dictionary members have an order:
The order of the dictionary members on a given dictionary is such that inherited dictionary members are ordered before non-inherited members, and the dictionary members on the one dictionary definition (including any partial dictionary definitions) are ordered lexicographically by the Unicode codepoints that comprise their identifiers.
But the places that talk about the dictionary <-> Infra ordered map correspondence, namely 1:
A dictionary is a definition (matching Dictionary) used to define an ordered map data type with a fixed, ordered set of entries, termed dictionary members, where keys are strings and values are of a particular type specified in the definition.
and 2:
An ordered map with string keys can be implicitly treated as a dictionary value of a specific dictionary D if all of its entries correspond to dictionary members, as long as those entries have the correct types, and there are entries present for any required or defaulted dictionary members.
do not mention this specific order. In particular it might be confusing what happens if someone writes a spec using ordered map literal syntax where the keys are not listed in the canonical order.
I read “dictionary” and “dictionary members” there as referring to the definitional Web IDL constructs rather than the concrete dictionary instances and their entries. This seems to be how “dictionary” and “members” are commonly used throughout the spec. Is this also how you read it?
The ES binding conversion steps seem to support this interpretation. For example when converting Web IDL dictionary values to ES values, it’s the order of the members of the dictionary D, not of the dictionary value V (whose type is D), which determines the order of property definition.
I don’t think the quoted passages are in conflict for that reason, but it looks to me like the spec doesn’t answer the question of whether concrete dictionary instances have ordered members at all. That order can’t be observed from ES in any Web IDL algorithms, but it could end up exposed indirectly by spec-specific algorithm steps, so regardless it ought to be defined.
Possibly notable: concrete Web IDL record values do have ordered entries.
I guess you're right that technically the spec only talks about the order defined by the type. I think it would be most natural to identify the two, though.