Some interesting ideas, thanks for opening this PR: I'm going to convert to a draft for now though, because these changes need more discussion, most of it on the https://github.com/web-platform-dx/web-features level:

Include the Baseline year of the feature in the unexpanded view.
Make "Widely available" or "Newly available" chip formatting consistent and more prominent.

We experimented with design variations a little bit like this, but if memory serves we decided that for most users, once a feature becomes Widely Available, the year matters much less - and so demoted the year into the expanded view.

I appreciate the visual consistency here, but as a developer targeting Widely Available - and the aim of the definition is that most developers will - I'm not sure the inclusion of the date in the main banner tells me much I don't already know.

But, we've also found that developer understanding of the Baseline "brand" has evolved enormously since its launch, so perhaps even developers targeting Widely Available still find meaning in the year, and it is valuable to include it. @atopal perhaps we should do some user research here?

Adds a sentence providing the future Widely available date for Newly available features.

There's no guarantee that a feature will become Widely Available 30 months after it's Newly Available: it's merely a prediction, and there's a good chance that breaking bugs will be found in that time (as more developers start using it) which set the feature back, so we can't do this. @ddbeck am I remembering that right?

Thanks for putting this together @tonypconway!

Just for some additional context on this request, I recently switched Angular to use Baseline widely available (pinned to a specific date for a major release) as our browser support for that release. This revealed some challenges in the UX for working with these APIs and making sure our implementation is limited to widely available APIs. I wrote a doc where I tried to explain how to read this component to determine whether an API is usable, but it is IMHO more complicated than it needs to be.

I think my main feedback comes down to:

1. It's confusing that the "widely available" view shows the "newly available" date.
   • Might be somewhat separate from this PR, but honestly, it just feels like a UX bug. At minimum, could we says something like "newly available since ${date}" just to put the words "newly available" in there?
2. There is no indicator of when a "newly available" API is expected to become "widely available", requiring the manual +2.5 years addition.
   • This is important because most meaningful feature development happens on versions which haven't released yet, so we usually don't care about the current Baseline status of the feature, so much as the Baseline status on the expected release date of the current in-development Angular version.

We experimented with design variations a little bit like this, but if memory serves we decided that for most users, once a feature becomes Widely Available, the year matters much less - and so demoted the year into the expanded view.

IMHO the date is important to note somewhere, but I think it's fine to limit it to the expanded view. I agree in the mainline case, most developers are interested in the current Baseline status, rather than its historical status. Historical status does come up, for example, when modifying an Angular LTS release, we would care whether the feature was Baseline during that original release up to 2 years back. But I don't think it's a big deal to have to expand the view for that use case, so I don't have any objection to hiding the year in the simplified view.

There's no guarantee that a feature will become Widely Available 30 months after it's Newly Available: it's merely a prediction, and there's a good chance that breaking bugs will be found in that time (as more developers start using it)

Isn't that all the more important to call out the widely available date then?

I'm thinking we can mark it as an "estimate" since we ultimately can't predict the future. But also if it is delayed due to a browser bug in the newly available period, then it would be helpful to say that even the current estimate is actually further out than "newly available date + 2.5 years". I'm not sure if we have the data to effectively include that kind of information, but it feels useful if we can.