Talk:Forward compatibility

All sources are published W3C specifications, RFCs, or archived W3C mailing lists. Happy to share draft wikitext for the actual article edits. [[User:Disentropic|Disentropic]] ([[User talk:Disentropic|talk]]) 23:50, 11 April 2026 (UTC)

All sources are published W3C specifications, RFCs, or archived W3C mailing lists. Happy to share draft wikitext for the actual article edits. [[User:Disentropic|Disentropic]] ([[User talk:Disentropic|talk]]) 23:50, 11 April 2026 (UTC)

== Broader framing in the lead — forward compatibility as a design stance ==

Now that the W3C TAG and Postel material is in the article (per the previous proposal, which I've implemented), I think it surfaces a mismatch for us to discuss. The lead currently frames forward compatibility as a property a system ''has'' as in "a design characteristic that allows a system to accept input intended for a later version of itself." But the sources the article now cites describe it differently: as a design stance that a language, protocol, or format takes toward inputs it doesn't recognize. These are not quite the same claim, and the narrower framing is what the lead commits to.

The TAG's definition is "consumers of the original language can correctly process text written for the evolved version of the language". This applies to any consumer/producer pair, many systems and their own later versions. That broadening matters for two reasons: first, forward compatibility becomes framed as something one can deliberately design into a new system, not merely an accidental property an old system turns out to have. Second, several of the article's own examples only make sense under the broader framing: HTML, the HTTP header-handling rule (now in the Design principles section), and the Postel reference all describe a stance toward ''unrecognized'' input rather than a relationship between successive versions of the same product.

The narrower framing also affects who finds this article useful. The current lead reads as primarily about hardware and consumer electronics, which suits the Telecommunication standards and Video gaming sections fine but doesn't match what the new Design principles section describes. Editors working on API design, schema versioning, or protocol specs are a natural audience for the cited TAG material and aren't likely to land here from the current lead.

A broader framing would also take some heat out of the recurring "upward vs forward" question that's come up on this page; the current lead treats "forward" as a temporal direction, which is the part that keeps generating the disagreement. KevinBTheobald's point in the 2020 television-signals thread (that forward compatibility doesn't require the original designers to have anticipated specific future uses) fits naturally under a design-stance framing but sits awkwardly against the current lead. Wanted to float this before drafting wording. [[User:Disentropic|Disentropic]] ([[User talk:Disentropic|talk]]) 04:15, 19 April 2026 (UTC)