I don't see the necessity for two separate statements. In fact, merging them would bring the evolution of the initial value closer together:

"Before Chrome 127, the initial value is implicitinstead ofnormal(see [bug 340878604](https://crbug.com/340878604)). Since Chrome 127, the initial value isautoinstead ofnormal (see [bug 460415950](https://crbug.com/460415950)).

I don't think we'd be serving developers by suggesting that Chrome 125 to 144 represented a single implementation. The behavior of implicit is much closer to normal than auto is to normal. How the successive releases are broken is not just inconsistent with today's spec, but also inconsistent with Chrome's own implementations.

To put this another way, if Chrome had unshipped the implicit implementation in 128, then shipped the new auto implementation in 129, we would have no choice but to have multiple compat statements. This to me is closer in meaning to what is going on here than to collapse the two statements.

I don't think we'd be serving developers by suggesting that Chrome 125 to 144 represented a single implementation.

I disagree that combining the partial implementation period in a single statement suggests this is a "single" implementation (whatever that means). In my opinion, what is most relevant for developers is the version range of partial support, and the start version of full support. To understand the evolution of the partial support, they can then look at the partial statement's notes.

But I won't insist here.

Note: According to https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Properties/position-anchor#none, none is the initial value, but the spec defines normal as the initial value. So the MDN page should also be updated.

Given that each browser has notes here, would this not warrant a subfeature initial_value_is_normal that none of the browsers support, with notes what the initial value is instead in different version ranges?

I did contemplate a one or more subfeatures, however I don't think there is a good case to be made for one here. There are a few issues with using subfeatures:

• The spec evolution wasn't additive (e.g., like the contextual subfeature example in the guidelines). In a sense, you'd have to look to the initial_value_is_normal feature to know whether position-anchor itself is consistent between browsers.
• This implied to me that we'd end up bubbling up the partial implementation to the parent feature. That would go against the spirit, if not the letter, of the behavioral subfeature guideline's recommendation to avoid subfeatures for data that "would be the same, across all browsers, as the parent feature."
• Once all browsers ship normal, the initial_value_is_normal data would effectively duplicate the normal subfeature data, if you ignored the historic details. This also struck me as contrary to the spirit of the behavioral subfeature guideline.
• If we used one subfeature, it's hard not to make the argument for multiple subfeatures (e.g., show each change in initial value, deprecating the old ones). This struck me as needlessly noisy.

That said, I will acknowledge that this PR does imply that we ought to make an implicit (deprecated) subfeature. I didn't do it because only one browser shipped it for a few months and it'll get deleted in a year anyway.

As for the docs, I expect that'll get resolved shortly. https://bugzilla.mozilla.org/show_bug.cgi?id=2030351 has dev-doc-needed; it should hit beta next week, so I figured the usual process would take that up.

I did contemplate a one or more subfeatures, however I don't think there is a good case to be made for one here. There are a few issues with using subfeatures:

• The spec evolution wasn't additive (e.g., like the contextual subfeature example in the guidelines). In a sense, you'd have to look to the initial_value_is_normal feature to know whether position-anchor itself is consistent between browsers.
• This implied to me that we'd end up bubbling up the partial implementation to the parent feature. That would go against the spirit, if not the letter, of the behavioral subfeature guideline's recommendation to avoid subfeatures for data that "would be the same, across all browsers, as the parent feature."
• Once all browsers ship normal, the initial_value_is_normal data would effectively duplicate the normal subfeature data, if you ignored the historic details. This also struck me as contrary to the spirit of the behavioral subfeature guideline.
• If we used one subfeature, it's hard not to make the argument for multiple subfeatures (e.g., show each change in initial value, deprecating the old ones). This struck me as needlessly noisy.

That said, I will acknowledge that this PR does imply that we ought to make an implicit (deprecated) subfeature. I didn't do it because only one browser shipped it for a few months and it'll get deleted in a year anyway.

I don't think we'd be serving developers by suggesting that Chrome 125 to 144 represented a single implementation. The behavior of implicit is much closer to normal than auto is to normal. How the successive releases are broken is not just inconsistent with today's spec, but also inconsistent with Chrome's own implementations.

To put this another way, if Chrome had unshipped the implicit implementation in 128, then shipped the new auto implementation in 129, we would have no choice but to have multiple compat statements. This to me is closer in meaning to what is going on here than to collapse the two statements.

As for the docs, I expect that'll get resolved shortly. https://bugzilla.mozilla.org/show_bug.cgi?id=2030351 has dev-doc-needed; it should hit beta next week, so I figured the usual process would take that up.

I don't think we'd be serving developers by suggesting that Chrome 125 to 144 represented a single implementation.

I disagree that combining the partial implementation period in a single statement suggests this is a "single" implementation (whatever that means). In my opinion, what is most relevant for developers is the version range of partial support, and the start version of full support. To understand the evolution of the partial support, they can then look at the partial statement's notes.

But I won't insist here.