How and when do we merge old features

[captainbrosset]

On Nov. 6, 2025, the WebDX CG discussed about the topic of merging old, widely available, features together. Here's a summary (full notes):

• Examples of old features that might be good to merge now include:

  • flex gaps and flex. They are 2 separate features now, and when they came out, definitely deserved to be separate. But now, it might make sense to merge them. I don't think developers consider gap as a separate thing anymore.
  • grid and grid animations might fall in the same category.
    • @jamesnw mentioned that grid animations feel too new to fold into grid right now. This begs the "When" question.
      • Not captured in the notes, but I think there was some high-level agreement about waiting for at least double the Baseline Widely Available time before folding.

• @ddbeck mentioned that answering the "How" question depends on the machinery, and linked to Allow references to useful subsets of large features #2676 where we're investigating how to reference slices of a feature. Being able to have features contain multiple sub-parts would indeed make it easier to merge features together while retaining what these features were originally about.

  • @Elchi3 made a related comment about the fact that merging features would lose Baseline years.
  • Retaining information about the merged features seems important.

• Matching developers' perception of features is important too. Do we want to keep talking about flexbox gaps in 5 years from now when no developers really think of it as something separate?

• @ddbeck and @Elchi3 discussed the case of Array features in JS. Lots of small features were created and then folded into Array.

  • There was a sense that small, atomic, features could continue existing with the notion of larger, merged, features, if we find a way to target sub-features.

I said I'd create an issue to continue discussing (so here it is), and provide a few more examples of features we might want to merge.

Before I do, reading the meeting notes again made me realize that merging is different than grouping. We may very well want to group many features together into a logical group. For example, Grid and Flexbox can be part of a Layout group. And <input> and <table> can be part of a HTML group. But that doesn't mean we'll ever want to merge these features together. @Elchi3 made a comment at the meeting about wanting to keep small, granular features. I agree that we should go as fine grained as necessary for developers, but I don't think we can make a guideline out of this easily. The granularity of our features varies greatly, and that's OK, even if it's uncomfortable for us to work with at times. We need features that map to the mental model of web developers. Features that map 1:1 to tasks that devs need to accomplish by using the web platform. Our goal isn't to create a catalog of the entire platform's sub-parts, that's what BCD is for. Our goal is to make it make sense to devs.

Here are a few features I found which are all Baseline Widely Available and have been since at least 2021, and which we could consider as candidate for merging:

• Consider merging into WebGL:

  • WEBGL_depth_texture WebGL extension
  • EXT_blend_minmax WebGL extension
  • WEBGL_lose_context WebGL extension
  • WEBGL_debug_renderer_info WebGL extension
  • EXT_texture_filter_anisotropic WebGL extension

• Consider merging into String:

  • String padStart() and padEnd()
  • String codePointAt() and fromCodePoint()
  • String includes()
  • String raw()
  • String repeat()
  • String startsWith() and endsWith()

• Consider merging into JavaScript (initial core language support):

  • Let and const
  • Functions
  • Iterators and the for...of loop

Let's ask ourselves:

• Do we want to do this? Do developers consider String.includes() as something separate from String? Has it been available widely and long enough for it to just be part of String by now? Have let and const been part of JS for long enough that developers just consider them like var?
• When? Have these been Baseline WA for long enough that merging would be ok to do? Can we create a guideline around this?
• How? Let's come up with ideas to avoid loosing the history.
  • This begs another question: should the Baseline date of the parent feature (the one which other features are being merged into) advance to whatever is the most recent Baseline date of its sub-features?

[ddbeck]

• Do we want to do this? Do developers consider String.includes() as something separate from String? Has it been available widely and long enough for it to just be part of String by now? Have let and const been part of JS for long enough that developers just consider them like var?

To answer the question in the broadest terms, yes. If I were the only one documenting the web, then I'd make neat, tightly versioned and rarely-changing atoms of feature description, but that's not practical. I think it's the case that developers update their mental models over time¹, but even if they didn't we'd be resisting the other forces in the ecosystem that "forget" newness and difference, such as specifications (e.g., the String.prototype.includes() proposal merged into the language spec), docs (e.g., MDN covers includes(), uses it in unrelated example code, doesn't mark it as experimental, etc.), and tools (e.g., eslint's recommended config requires the use of const). If we're to continue to be descriptive, then we pretty much have to be able to acknowledge these these changes.

• When? Have these been Baseline WA for long enough that merging would be ok to do? Can we create a guideline around this?

I think this depends a little on how we represent these changes structurally, but I suspect the guidelines will be something along the lines of:

• Merging must not regress a headline status.²
• Merging must not change the set of implementers. That is to say, a feature implemented by two engines can't merge with a feature implemented by one, even though the status cannot regress.
• Merging must happen slowly. I'm not committed to a specific timeline (yet), but for Baseline features it's probably at least a full calendar year after reaching widely available. For non-Baseline features, it's probably comparable to the widely available timeline, 2-5 years.
• Merging should avoid surprise. We should avoid being incoherent with the merge target's description or doing other silly things (e.g., you can't merge strings into array even though, if you squint, strings are sequences of values).

• How? Let's come up with ideas to avoid loosing the history.

That's a big question, but I'll lay out some needs and wants. My needs:

• Reference stability, like we have for renames. If I merge id-b into id-a, then I should be able to continue to reference id-b and get some data associated with that ID (such as a name). In other words, it'd be great if I could have a <baseline-status featureId="id-b"> embedded in a blog post and have it continue to work and show a status that makes sense with the respect to the feature at the time that I wrote the blog post.
• Reversibility. That is, if I merge one thing into another, it should be possible to unwind that merge if I made a mistake (e.g., using some mechanism where the merge target gets information about the things that merged into it—information that could be used to point back out to a standalone feature, if we undo the merge).

My wants:

• Record intent to merge. That is to say, if we expect some feature to merge into another, then it would be nice to declare that fact as soon as it is known. We wouldn't catch every case of this and developers (and docs authors) may surprise us with how they come to understand a feature, so this wouldn't be obligatory.
• Preserve the date order of features. That is, if I want to, I ought to be able to sort features by when their earliest iteration was newly available (or widely available), not just the last Baseline date given by our Baseline calculation. Maybe this means we break out the Baseline low date into a separate field (e.g., an explicit date sort field computed under different rules). For example, "Array" should always sort as among the oldest features, no matter the later additions.

My aspects proposal in #1160 was meant to support my "needs" (plus some other things, like improving the authoring of compute_from), but doesn't have answers for my "wants" (yet).

Footnotes

1. I think there are genuine questions about whether or how developers actually revise their mental models about the platform over time. It's possible that developers don't do it over time per se (e.g., they primarily change their minds when they change jobs, moving to a different code base that has different standards). Or it's possible they don't change their minds at all even (i.e., individual developers retain one mental model, but developer understanding overall changes as newer developers outnumber older ones). I think some process definitely changes understanding in aggregate; I remember when I would get 😕 in code review for calling Array.prototype.some() and now that doesn't happen. But I don't think the specific process matters that much because… ↩

2. Setting aside the possibility of feature evolution where it'd be silly not to, such as deprecations. Perhaps something extraordinary could happen, such as overwhelmingly strong evidence that shows developers believe some established feature is "broken" without some later addition. Perhaps we'll see this with Oklab and gamut mapping. I imagine it'd be rare. ↩