Why in heaven's name should we have different widths per project ? That makes NO sense whatsoever and is a maintenance nightmare.
This should be resolutely rejected.

Support community design standards

Where to find these?

In T332505#8725725, @Aklapper wrote:

Support community design standards

Where to find these?

Relabeled 'standards' to 'requests' - for example the parent ticket.

In T332505#8724789, @TheDJ wrote:

Why in heaven's name should we have different widths per project ? That makes NO sense whatsoever and is a maintenance nightmare.
This should be resolutely rejected.

Wikidata, of particular note, would benefit from additional width by default as currently designed to support a two-column content view with (floating? flex?) fallback to one-column. It currently uses Vector 2010, but I assume in the name of brand unity it will use Vector 2022 at some point. I suspect WikiFunctions will have flexibility similar to Wikidata.

Commons, Wikispecies, and Wiktionary could likewise use the extra width in subject spaces, for much the same reason that they are light on prose (rather than absent of prose).

I expect there are 3rd parties which have light-to-negligible prose content (the other semantic wikis directly, of note) for which the default as narrow does not make sense and would still prefer to use Vector 2022.

Now, whether it's fair to put that burden on the skin maintainers rather than having those wikis do the work in their Vector-2022.css is a reasonable question, as you imply by your comment about maintainability. I do not know what using Vector-2022.css would imply about what the toggle can do.

Now, I might be missing something obvious here, but there's already a configuration variable (vector-limited-width, set to 1 by default via DefaultUserOptions in the skin.json) — $wgDefaultUserOptions allows for "overrid[ing] the default user preferences for anonymous visitors and users who have not customized their preferences."[0]

I suppose this (and by extension, T332426) could be implemented by:

diff --git a/wmf-config/CommonSettings.php b/wmf-config/CommonSettings.php
index 5fe846412..4220d8940 100644
--- a/wmf-config/CommonSettings.php
+++ b/wmf-config/CommonSettings.php
@@ -4342,6 +4342,7 @@ if (
 }

 $wgLogRestrictions = array_merge( $wgLogRestrictions, $wmgLogRestrictions );
+$wgDefaultUserOptions = array_merge( $wgDefaultUserOptions, $wmgDefaultUserOptions );

 # THIS MUST BE AFTER ALL EXTENSIONS ARE INCLUDED
 #
diff --git a/wmf-config/InitialiseSettings.php b/wmf-config/InitialiseSettings.php
index 5b741a651..6b2ae6b40 100644
--- a/wmf-config/InitialiseSettings.php
+++ b/wmf-config/InitialiseSettings.php
@@ -13380,4 +13380,11 @@ return [
        'default' => SCHEMA_COMPAT_OLD,
 ],

+'wmgDefaultUserOptions' => [
+       'default' => [],
+       '+enwiki' => [
+               'vector-limited-width' => 0
+       ],
+],
+
 ];

[0] https://www.mediawiki.org/wiki/Manual:$wgDefaultUserOptions

Change 904375 had a related patch set uploaded (by Samtar; author: Samtar):

[operations/mediawiki-config@master] [WIP/DNM] InitialiseSettings: Add `wmgDefaultUserOptions` override

https://gerrit.wikimedia.org/r/904375

Change 904376 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/skins/Vector@master] [POC] allow default value for limited width to be default

https://gerrit.wikimedia.org/r/904376

Change 904375 abandoned by Samtar:

[operations/mediawiki-config@master] [WIP/DNM] InitialiseSettings: Add `wmgDefaultUserOptions` override

Reason:

Flawed implementation — https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/904375/comments/af2be3ca_3660e46e

https://gerrit.wikimedia.org/r/904375

In T332505#8740342, @TheresNoTime wrote:

Now, I might be missing something obvious here [...]

Indeed I was — explanation on the patch for anyone interested, but the tl;dr is $wgDefaultUserOptions would override logged out users who selected the limited width option :-(

I might be missing something else obvious here, but I believe that issue could be fixed with the following changes:

In the vector skin, in features.js, in the save function, change:

if ( enabled ) {
	// @ts-ignore
	mw.cookie.set( 'mwclientprefs', null );
} else {
	// @ts-ignore
	mw.cookie.set( 'mwclientprefs', 'vector-feature-limited-width' );
}

to:

if ( enabled ) {
	// @ts-ignore
	mw.cookie.set( 'mwclientprefs', 'vector-feature-limited-width-enabled' );
} else {
	// @ts-ignore
	mw.cookie.set( 'mwclientprefs', 'vector-feature-limited-width-disabled' );
}

In mediawiki, in ClientHtml.php, from line 268, change:

var cookie = document.cookie.match( /(?:^|; ){$cookiePrefix}mwclientprefs=([^;]+)/ );
// For now, only support disabling a feature
// Only supports a single feature (modifying a single class) at this stage.
// In future this may be expanded to multiple once this has been proven as viable.
if ( cookie ) {
	var featureName = cookie[1];
	document.documentElement.className = document.documentElement.className.replace(
		featureName + '-enabled',
		featureName + '-disabled'
	);
}

To:

var cookie = document.cookie.match( /(?:^|; ){$cookiePrefix}mwclientprefs=([^;]+)-([^;-]+)/ );
// For now, only supports boolean choices for a feature
// Only supports a single feature (modifying a single class) at this stage.
// In future this may be expanded to multiple once this has been proven as viable.
if ( cookie ) {
	var featureName = cookie[1];
	var prefStatus = cookie[2];
	var prefStatusInverse = 'disabled'
	if ( prefStatus == 'disabled' ) {
		prefStatusInverse = 'enabled'
	}
	document.documentElement.className = document.documentElement.className.replace(
		featureName + '-' + prefStatusInverse,
		featureName + '-' + prefStatus
	);
}

This should then allow TNT's patch to work; I haven't found any problems on my local instance. I don't have a functioning dev account, so can't push this directly.

In T332505#8740836, @BilledMammal wrote:

I might be missing something else obvious here, but I believe that issue could be fixed with the following changes:
[...]

I'll defer to @Jdlrobson on that suggestion, but thank you for the investigation! 🙂

It's also perhaps worth noting @ovasileva's comment at T332426#8740528.

Regarding part of ovasileva's comment at VPT, one solution to allow logged out users who had set full width as their preference on Wiki's where limited width remains the default would be:

var cookie = document.cookie.match( /(?:^|; ){$cookiePrefix}mwclientprefs=([^;]+)-([^;-]+)/ );
// For now, only supports boolean choices for a feature
// Only supports a single feature (modifying a single class) at this stage.
// In future this may be expanded to multiple once this has been proven as viable.
if ( cookie ) {
	var featureName = cookie[1];
	var prefStatus = cookie[2];
	var prefStatusInverse = 'disabled'
	// The following four lines allows preferences from prior to the change, where the existence of 
	// "vector-feature-limited-width" meant that limited width was disabled, to persist. 
	// It should be removed after sufficient time has passed for most of those cookies to have been replaced
	if (prefStatus == 'width') {
		featureName = featureName + '-' + prefStatus
		prefStatus = 'disabled'
	}
	// End of temporary code
	if ( prefStatus == 'disabled' ) {
		prefStatusInverse = 'enabled'
	}
	document.documentElement.className = document.documentElement.className.replace(
		featureName + '-' + prefStatusInverse,
		featureName + '-' + prefStatus
	);
}

I want to flag that this would change the default for everyone and currently the RFC on English Wikipedia does not have the scope to change it for other projects who want limited width as default e.g. French Wikipedia.

This code is also in a critical and sensitive part of MediaWiki's infrastructure and is outputted in HTML that is heavily cached. I don't think you should be complicating this logic with project-specific code. Please see T321498 and T327979 for the amount of rigor and performance testing which went into building this particular piece of code. Similar rigor would be necessary for any changes.

If changing it, you will also need consider our caching infrastructure. We cache pages for days/weeks so this code would need to work for people who have already stored cookies so any change here would require a migration strategy. The change you are proposing as written would suddenly give limited width to everyone who has already set it disrupting various people's workflow and be lead to an inconsistency across all page views depending on their cached status. The only other way around this is clearing the cache for the entirety of English Wikipedia which the SRE team at WMF would not approve given it could cause huge problems for the operations team.

Finally, this code is part of a wider set of changes to enable important accessibility settings such as font-size and dark mode which is already in motion (T331681). Changing this code in the way you describe would set this work back by at least a month, maybe up to 3 months, by forcing repetition of the same testing done already, and a revisiting of a lot of the thought that went into the existing architecture and assumptions that have been made around default states.

The request here on T332505 was only to enable a project based configuration option to be available, such that a project could request said configuration option. If creating such an option is declined, the site request in T332426 to set it on for enwiki that is dependent on this will die (and likely lead to some fighting about using local js/css hacks). The description above may be missing something - if this gets created and a project configuration is enabled to use it, the request is indeed to set that view for logged out users (potentially with the large caching update mentioned above) - but not to change the value to existing users (in regard to the 'disrupting workflow' comment above) - only to have that be the default value going forward for newly created users (that is they would have the same experience as they do when logged out).

Jdlrobson, the code I provided would allow a different default to be set on each project; if only enwiki wanted full width as a default then no other wikiproject would need to be affected.

When I wrote the code I was careful to minimize changes to existing code, to prevent any performance issues beyond any the existing code causes, but you are welcome to test it if you believe it may introduce such issues.

Regarding people who have already stored cookies, the second version addresses that.

Regarding T331681, my understanding is that the code there would not support project specific defaults and as such needs revision regardless. It also appears that the only thing that has been tested is whether storing multiple preferences affects performance; I see no reason why the change I proposed would affect this in such a manner that the tests would need to be repeated.

Change 904376 abandoned by Jdlrobson:

[mediawiki/skins/Vector@master] [POC] allow default value for limited width to be default

Reason:

https://gerrit.wikimedia.org/r/904376