browser-compat-data: how many users care about flag data?

[queengooborg]

In the BCD repository, we include data for features that must be enabled using browser flags (that is, settings in chrome://flags/about:config/etc.). Browser flags are a useful way to try out cutting-edge features, however there's a number of issues with flag data:

• It's much harder to maintain since it requires manual testing
• Flags are meant for developers and beta testers, and are accompanied by warnings to "only proceed if you know what you're doing"
• Some browser vendors have also asked for flag data to be omitted from BCD
• Most mobile browsers have removed flags entirely

With all of this in mind, I have been considering simply removing all flag data from BCD. But before I make such a big decision, I would like to know how much readers of MDN Web Docs (and other consumers of BCD) care about flag data.

Please vote in the poll below how much you care for BCD flag data, and if you're down for it, explain in the comments why you chose your answer! I will compile the results and make a decision June 24th (or potentially earlier if responses slow down/there’s a clear winner).

[bershanskiy]

I chose "It just adds more clutter to the tables", however, I believe that flag data (and Origin Trial data) is useful for one rare but important use case. Specifically, this data is crucial for testing upcoming features that are about to launch within a few months. This data is already accessible elsewhere (in some blog posts or on feature trackers, issue trackers, etc.), but having it directly on MDN is always helpful.

[estelle]

I think immediately is likely best. That removes the need to revisit the data. For the developer who wants to use the feature, they will see the 'full support' non-flag.

I am pretty sure there is no needed caveat of providing information to the developer to set or unset the flag on a launched or removed feature because once a feature is supported or removed, I am pretty confident (but not 100% sure) that the browser removes the ability to toggle the flag.

[hamishwillee]

I agree.. Though my immediately might be "the next release". When you're updating BCD during a release cycle it is not unusual to turn that flag on and off a few times and the release to skip forward a bit.

[queengooborg]

I opened mdn/browser-compat-data#16568 to propose moving up the removal period!

[hamishwillee]

Another alternative - trigger display based on something else - e.g. a switch in MDN+

[queengooborg]

The problem is less of how it’s displayed on MDN, and more about the maintenance of said data. If we put a switch on MDN Web Docs, that means we still have to maintain the data in BCD, which isn’t really something we can automate data collection for. I’d love to have a good excuse to just eliminate all flag data and not have to maintain it any longer, hence this poll. 😛

[rik]

GoogleChrome/web.dev#7936 would be "solved" by not having flag data in BCD.

[bershanskiy]

Yes, that is a good point. What I'm asking is would it be better for web.dev to fix this issue now with a simple filter instead of waiting for the completion of this poll and hoping MDN removes the flag data?

[queengooborg]

If it helps, I plan on making a decision based on the poll data on June 24th (about three weeks from now)!

[bershanskiy]

June 24th seems like a long time from now, so I would prefer to have web.dev fixed in the meantime (I never contributed to it before).

[queengooborg]

I chose that date because I wanted to give a long enough period (about a month) for feedback from as many as possible. But you’re right, it might be a bit long — if responses slow down, or there’s a clear winner for the poll, I’ll close it early!

[bershanskiy]

Long poll duration is good since it produces a more well-argumented result. What I meant is web.dev could fix their issue on their side not waiting for the poll to close and not relying on a very specific outcome of the poll. If we end up keeping even some flag data as we are considering, web.dev will have to amend their scripts anyway.

[georapbox]

I can see why browser vendors might prefer flag data not being displayed. On the other hand, from the developer's perspective it's quite convenient to have this kind of information in a central place like the compatibility tables. I think it's important sometimes for decisions making. For example when I see that a feature is behind a flag, it's a sign (although not always the case, I have to admit) that there is intend to ship at some time in the future. But at the very least it shows that the feature is under development.

In a nutshell... "It's nice to have, but not a big deal"

[simevidas]

It's much harder to maintain since it requires manual testing

This could be solved by making browser vendors responsible for keeping the flag data up to date.

[queengooborg]

Mozilla does maintain most of the Firefox flag data! Google and Apple, however, have not -- Google has been mostly -1 on flag data, and we haven't heard anything from Apple on the matter.

[tunetheweb]

It’s only useful to some IMHO. However it’s a great signal to differentiate between a feature that’s likely to come to more browsers soon and so is worth keeping an eye on, and one that’s probably years away.

[atjn]

To expand on my vote "It's nice to have, but not a big deal":

When I build new apps, I often use features that are behind flags. I either use them for progressive enhancement, or I use them in projects where the feature is likely to be implemented by the time the app is released. This is especially the case when the feature has been standardized, and/or enabled by default in a single browser, but isn't available in other browsers. If I can see that it is available behind flags in all/most browsers, I can feel much more safe using it, because features behind flags almost always become fully implemented relatively quickly.
Removing flag info would likely make me use fewer bleeding-edge features in my apps, because I wouldn't have these signals to indicate progress in browsers.

[Ugoku]

I've voted for "It's nice to have, but not a big deal" because:

For example, looking at https://caniuse.com/css-container-queries , it's useful to see that Chromium is actively working on this and Mozilla is not. We can gather this from the tracking bugs, but that takes more time than simply looking at the table.

[hamishwillee]

FWIW I don't think the plan was ever to remove the flags before release but after, once the features are released.

I think the argument is that that the purpose of publishing the flags is to allow early testing. Once the feature is public, then there is no need for the information to be retained, even for older releases.

[Ugoku]

Ah sorry, I missed that part! In that case, my vote goes to "It just adds more clutter to the tables"

[sippan76]

In the BCD repository, we include data for features that must be enabled using browser flags (that is, settings in chrome://flags/about:config/etc.). Browser flags are a useful way to try out cutting-edge features, however there's a number of issues with flag data:

• It's much harder to maintain since it requires manual testing
• Flags are meant for developers and beta testers, and are accompanied by warnings to "only proceed if you know what you're doing"
• Some browser vendors have also asked for flag data to be omitted from BCD
• Most mobile browsers have removed flags entirely

With all of this in mind, I have been considering simply removing all flag data from BCD. But before I make such a big decision, I would like to know how much readers of MDN Web Docs (and other consumers of BCD) care about flag data.

Please vote in the poll below how much you care for BCD flag data, and if you're down for it, explain in the comments why you chose your answer! I will compile the results and make a decision June 24th (or potentially earlier if responses slow down/there’s a clear winner).

• https://developer.mozilla.org/en-US/docs/Web/CSS/Reference

[queengooborg]

Definitely spam, especially when you consider how empty the profile is. I'd remove it, but I don't have write permission for organization discussions. :P

[hamishwillee]

I do!

[queengooborg]

Hey all! Just wanted to let everyone know that the general consensus during this poll and the BCD meeting was that the flag data is useful, but not after the flag is removed or the feature is enabled by default. We have updated the guidelines so that flag data removal can be performed immediately in mdn/browser-compat-data#16637!