#Needs product manager review

This is different in Site Studio where there's no way of setting defaults/fallbacks for empty values AFAIK? In Experience Builder, both SDC and in-browser code components provide a way to use fallback values in code.

UI Suite themes are using this approach too. See https://git.drupalcode.org/project/ui_suite_dsfr/-/blob/1.1.x/components... for an example. This is also what their docs are recommending: https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... → .

To me this seems largely a docs concern to explain how we'd recommend components to be built. There are potential UX implications because many page builders have special handling for empty behavior where they don't even show the field when the fallback value is used.

Crucially, #8's when you see prefilled text, you expect it to be submitted unless you overwrite it. ignores that it cannot work like that for SDC's default images — otherwise they'd end up being saved into Drupal's Media Library.

This seems just the incorrect behavior of the widget itself? We should make it possible for the widget to display the default value, regardless of it not being in Media Library. The widget is just means to displaying the value of the field, which in Drupal has historically been tied to a specific field type. In this case it's interesting because the example value cannot use media library and therefore we must implement a field widget which is able to handle display of multiple field types.

This has significant data storage implications, so tentatively tagging .

Found 🐛 Fix Drupal\Core\Database\Fetch* types as they are wrong Active while reviewing this one.

One question inline related to copyright

#1. I've updated the statcounter link to go directly to https://gs.statcounter.com/browser-market-share, which includes regional filters by continent and country along with a short mention. I think it's good to link to the resources we know about, but don't think we want to be comprehensive/prescriptive here in case something better shows up.

#2. I had a look at the most recent webaim survey to see if there was an example.

https://webaim.org/projects/screenreadersurvey10/#browsers

This shows Firefox at 16% and Edge at 19%, whereas if we look at the last month's global data on statcounter:

https://gs.statcounter.com/browser-market-share/desktop-mobile/worldwide...

Firefox is at 2.5% and Edge is at 5%

So I've added "(e.g. more than 10-15% stable usage when global usage is under 1%)".

The 'stable' in there is so that the 'downward trend' above can take precedence, this was part of the considerations for dropping IE11 support iirc because it was clearly on its way out in successive webaim surveys, if still disproportionately used.

Stable 10-15% usage isn't a hard number (and we could change it to a different number), it just means we would need to put some effort into understanding why a browser is disproportionately and consistently used over the years before dropping support for it.

#3. I started writing a comment saying I think versions is already covered in https://www.drupal.org/docs/getting-started/system-requirements/browser-... → , but then I realised that doesn't cover how we decide which browsers get two major vs. only latest major version covered. So yes, we probably do need something.

I've added:

In general, desktop browsers are supported for their two most recent major releases, and mobile browsers are supported only for their most recent release. See https://www.drupal.org/docs/getting-started/system-requirements/browser-... → for details of current support.

I think we'd need a good reason to deviate from that for a specific browser, firefox ESR and safari mobile are the only two deviations we have, not sure we can get around discussing special cases like that.

I think that hopefully addresses the feedback, going to be bold and self-RTBC the changes since they are pretty minimal in the scheme of things.

I think this looks great. Few comments that would be great to address to make sure that it's clear how this guidance should be applied:

1. Can we add a reference for geographical browser usage? If we don't have one, I don't think we should include it in the heuristics.
2. Can we define specific thresholds for when we would we consider a browser is disproportionally used by screenreaders per webaim screen reader survey?
3. Should we add guidance on how browser versions are handled? If they follow the existing policy, we could drop support for previous major of Safari for example.

The blocker went in but I don't think we should try combining the screens, there's a push to decouple block_content from block at the moment so we don't want to tie them together any more (see 📌 Why block_content depends on block? Active )

There is also ✨ Link block to content_block Active for adding a link so maybe we close this one in favour of that?

FYI: Thanks to this effort, I've been able to close about a century's worth of old issues out of the update.module component. 🎉

https://www.drupal.org/project/issues/search/drupal?status%5B%5D=5&statu... →

Or see the growing list of issues in the "Referenced by" list in here, since I've been marking things related...

Huzzah!
-Derek

Here's what XB did in the meantime: 🐛 Disable Block UI for regions managed by Experience Builder Active

Still needs @lauriii per #11.