@Jdlrobson, per T351307#9353379, should you name this project night mode? The generalization of night mode is close and this seems to be unnecessary noise.

Eh, I think I hallucinated it from reading the same tickets over and over again...
T320322 adds the support of CSS variables in TemplateStyles.
T355244 adds the support of Codex tokens in in TemplateStyles.
If I remember correctly, the tokens are already available in MediaWiki:Common.css?
The recommandation is to always use a fallback for skins which do not support Codex (not sure it means everything except both Vector versions).

In T363142#9736276, @Theklan wrote:

Is there any working Main page using those?

Don't know if you know what is Codex, but you can reuse the Codex design tokens in TemplateStyles or CSS page content model (i.e. MediaWiki:Common.css).

Met one yesterday too on frwiki, but I confess I didn't think it could be a bug?

Damn, I had put my piece on the HTML comment, not the categories! I also think I was able before with this same wikicode layout to reply from the main page (the "faulty" version was the version of the page used since 2020), or at least open the reply tool. Except I can't say for sure.

Reproductible on my side.

Tried with "real" title of sections (i.e. == Test ==) and it didn't change anything. getThreadItemsHtml from the API put the HTML-comment in "othercontent" (which is good). So, somehow, this edge case fails within CommentParser.php in computeTranscludedFrom.

@Escargot_rouge, c'est bon.

Since I reported the problem, I've encountered it less than ten times. That's still 10 cases where the anchor is broken...

I'm just discovering that scope are not added with the Visual Editor, nor that it's easily possible to add them without switching to the classic editor. On frwiki, the community relies on a gadget to detect this type of inaccessible table. The impact is quite significant: we continue to generate inaccessible tables that have to be corrected by hand.

In T359644#9728041, @Jdlrobson wrote:

Anyway, thanks again for getting us to where we are now! It's definitely looking a lot more optimistic than it was a month ago so I want to make sure you know I appreciate your efforts in this space! I know consensus is hard to build!

So we haven't agreed on an approach yet but we have two options we are considering:

1. we target .infobox---frwiki. The benefit of this is it targets French only, the downside is all projects would get unused CSS and it wouldn't help other projects e.g. say italian adding infobox--it.
2. We target any class beginning with infobox-. The benefit is we could recommend other projects other than French follow suit, but on the downside code is less readable.
3. We target any class beginning with infobox. The benefit is we can minimize CSS rules. Downside is it would match infobox_v2 and infobox_v3 here (but it sounds like they already have infobox--fr so maybe that's okay?)

Does that make sense?

In T359644#9726811, @Jdlrobson wrote:

French Wikipedia should still work towards adding the infobox class on all its projects. If that's not the goal we need to talk and make sure we're on the same page :-). If all projects standardize to have the infobox class it's better for bots, screen scrapers (and thus SEO), crawlers, APIs, MobileFrontend etc.. as it allows all these things to identify what the infobox in the page is.

My understanding was that the reason French Wikipedia doesn't use the infobox class is because:

1. it dislikes the alteration of appearance that occurs via skins.minerva.content.styles/hacks.less
2. It believes the infobox should be at the top of the page e.g. we should disable MoveLeadParagraph.

In T359644#9724906, @Jdlrobson wrote:

@Lofhi French can also now adopt the infobox class and disable the styles associated with infoboxes if they want to use their own using the approach outlined at https://www.mediawiki.org/wiki/Extension:WikimediaMessages#Disabling_styles - I'm not 100% sure what was the outcome of the discussion @Trizek-WMF was having with Od1n on https://fr.m.wikipedia.org/wiki/Wikip%C3%A9dia:Questions_techniques/semaine_10_2024 but if that's a possibility that would fix this much quicker (days rather than weeks).

Hello, can you check if the file is filled properly on Commons? Thanks.
https://commons.wikimedia.org/wiki/File:OOjs_UI_icon_appearance.svg

Some discussions about removing or not the uses of __NOTOC__ on frwiki articles in the main namespace : https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Sondage/2024/Supprimer_tout_masquage_de_la_table_des_mati%C3%A8res_dans_les_articles

.infobox--frwiki is now used for every infobox (ref).

In T361508#9707623, @CCiufo-WMF wrote:

I like the spirit of this, but there are no specific WCAG compliant colors. Rather, it's the contrast between colors that make them compliant or not. This is why we lean on decision tokens, since they come built-in with guidelines on how they should be used together, to avoid accessibility concerns.

The idea is rather as follows: for a proposed text color, also propose a background color with an acceptable contrast ratio.

No answer and the "image dimming" (not directly related of the initial report) is a official supported and customizable feature of the app, closing.

Request made, https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Demande_d%27intervention_sur_une_page_prot%C3%A9g%C3%A9e#c-Lofhi-20240411080200-Mod%C3%A8le:Classes_d%C3%A9but_infobox_(d_%C2%B7_h_%C2%B7_j_%C2%B7_%E2%86%B5)

@Xover what about just using Codex design tokens? See T355244.

It could improves accessibility by removing arbitrary color uses to be sure to have only WCAG 2.1 AA compliant colors, verified by the WMF, for example.

I like to point out that I communicate quite a bit about Codex on frwiki. This means that certain topics raised by the community can be covered by Codex.

I just discovered that mobileonly is only using CSS to hide elements on the mobile version, so it heavies them down. It is possible to totally remove them elements like the navboxes are removed?

I checked, and it seems that Codex tokens are available on every skin (with mediawiki.skin.defaults.less) ? Or have I misunderstood? I wouldn't mind a hint as to where the ResourceLoader comes in to load the tokens, and for the default autoloaded modules. I really need to dig the ResourceLoader, cause I'm lost about the chaining, don't know where to ask.

Does T356677 made Codex CSS-only components available by default on every request on Vector 2022 (see example)? It seems that skins.vector.search.codex.style is autoloaded. Anyway, if that's the case, it doesn't justify using the Codex components directly on a wiki, right?

In T359644#9683323, @Jdlrobson wrote:

Moving back to tech prioritization until have some clarity if there is some wiggle room here with introducing a new class.

Thanks for the link. I get it. I was asking because some contributors are pushing (again) for them to be re-displayed on small screens (i.e. mobile) on frwiki. I think the only solution I've been able to find is to allow only one pallet per article, which would also have to respect a size limit. A considerable addition of limits that are unlikely to please.

I can only agree with @Izno. There is no simple solution. These types of template are also massively used, so they are also stuck behind edit protections. It's hard to do something without needing days of work for even small changes... without the role. I guess the only solution is for WMF to inform the communities directly that these inline color uses are to be avoided. But this has been common practice for 20 years... I don't know if the existing MediaWiki doc-page will suffice.

I don't know how to put the question: would the use of grid or flexbox be enough to lighten these navboxes? Or is it crucial to also consider the size of the palette content (editorially)? Because while dewiki uses responsive navboxes, they still use tables, which are HTML markup heavy.

One example on frwiki with night mode (first image in the first section): https://fr.m.wikipedia.org/wiki/Portal_(jeu_vid%C3%A9o)

In T360384#9682707, @Jdlrobson wrote:

@Lofhi thank you for setting a fine example of how this can work. If you could share how you went about the MassMessage I think that could be helpful to others!

Thanks for sharing @Gwern, and for you work. It's undeniably a high-quality tool that could be shared with communities. Is it possible to host an instance on Toolforge? It would so appear on Toolhub.

With the types of images you are quoting, the .skin-invert class seems totally fine. But some may still need an adaptative background color (imagining we will have more than two themes in the future) like .media-with-transparency, no? If it's the case, I think the WMF should define this type of class first and not let wikis rely on "in-house" solutions in the first place.

The used concerned is using the version 2.7.50479-r-2024-03-21. ROM is based on Android 11. The user sent me the details in private, so I am not sure they want me to quote the model here, any other channel maybe?

Hello @Jdlrobson, can you tell me if I've assigned the task to the right projects? I think the problem raised needs to be thought through early on before generalizing night mode.

The global changes required on frwiki have been completed. Actives users (since may 2023 ; Vector 2022 generalization) potentially affected (a few hundred and not less than 50 as mentioned in the main task) will be notified this week. We don't have the capacity to manually review each personal user script.

I'd like to point out that frwiki has begun finalizing the transition of its V2 infoboxes, which has been going on for years, to V3 or Lua infoboxes. This will eventually enable the use of the standardized class, but it will take several weeks (months) since these changes are often held up by the need for consensus.

I got the same results than you. Still, the color are different (excluding the background) from the web version, no? It looks duller.
I will ask more details for their even weirder colors.

In T359644#9651178, @DTorsani-WMF wrote:

I meant https://en.wikipedia.org/wiki/Main_Page but am I interested in all templates on every page like you say. It is helpful to know that a broader color palette is wanted.

Does it mean we will have a official night mode color palette coming from Codex (see T357835)? Since the night mode is pushed on wikis and editors are starting to use their own colors... Edit: just found T360343, I think it covers my question.

In T359644#9640524, @DTorsani-WMF wrote:

This might be outside of this task, but I would be very interested in understanding any of the justification for the color and style/layout choices in templates, including the headings on the main page. @Jdlrobson Is there anywhere to see all of the different kinds of templates? Has such an audit been done, or might there be a page with most if not all of them? Though I've noticed even the same type of template doesn't mean it gets the same color or style treatment.

I'm a total stranger to your way of working for application development. It also seems that the teams are quite different for Android and IOS. However, I wanted to bring up a use case from a user (@Baidax). I happened to read their comments about how a 1x1 widget (image) broke with the improved versions of the widgets. Is it possible to support the 1x1 use case?

cough
https://fr.wikipedia.org/w/index.php?title=MediaWiki:Common.css&diff=prev&oldid=213342921

Does WMF have a position on frwiki's infobox header colors? At the very least, they need to be reworked for contrast, but would WMF argue that it would be better to adopt a consistent, global color for all of them?

Alright. I don't really know how do you want to enable the dark mode only for the technical editors but I can only wait.

Let me rephrase: how do you expect us to notice compatibility problems with night mode if we have to constantly add ?vectornightmode=1 to the URL? By not blocking the beta feature rollout, you allow frwiki registered editors to use night mode as they choose, and to report problems as they read through our two million (almost three) articles.

I only see hacks.less getting bigger and this will surely complicate fixes in the long term. How easily should itwiki (and all projects) know that one of its CSS classes is hard-corrected in MediaWiki?

How do you expect projects to correct their issues by making night mode inaccessible?

Blocks deployment to French Wikipedia [...]

In T356344#9601739, @Lofhi wrote:

But the problem is, what do the technical contributors think? I will try to gather their feedback.

There is something I don't understand @Esanders. Why are you uninverting the CSS filter on images? I will ask a very dumb question: why not using the not CSS selector to exclude img? For old browsers support?

I believe the entire community would be willing to participate as pilots for the new night mode, given their constructive contributions when they participated as one of the few major wikis to test the new discussion tools early on.

I wanted to know the proportion of the active editors not using Vector (both versions).

[...] when necessary [...]

Since I've been kicking myself for the past two months with all these new services using a web service based on node, I may write a tutorial if the WMF doesn't mind. My memory is fresh enough to point out the blocking points.

In T353752#9582219, @bd808 wrote:

You were confirmed by the Tool-gitlab-account-approval bot because you were already a member of the Trusted-Contributors Phabricator group.

In my experience, I was confirmed after a brief wait. It appears to be the sole process within the WMF ecosystem that requires approval, but I believe it's acceptable. From what I remember, the only prerequisite for potentially using this type of service is when you are creating an account to create your first Toolforge tool.

We need stability for communication to communities: are we talking about a night mode, or a dark mode? I read MediaWiki-extensions-DarkMode. But the WMF wrote this page: recommendations for night mode compatibility on Wikimedia wikis, initially named recommendations for dark mode compatibility on Wikimedia wikis. Also, the WMF published the "Dark mode is coming" blog post 4 days before the recommendations page rename.

@Jdlrobson, could you please share the percent usage by skin? The SQL results for my user_properties view is heavily redacted for obvious reasons.

What would the WMF think about mass editing instead of using their "temporary" gadget based on individual actions? Currently, I see ~1 900 edits per minute, for all the projects. Adding 300 edits per minute to this average for 10 minutes in the middle of the night in Europe to process all the pages on frwiki would be an acceptable stress on the DBs? We have like ~ 1 000 pages, so *2.

Finally found that DifferenceEngine was modified and then I found this task. T357213 caused some community noises on frwiki too and yes, the problem is only met by editors with "Do not show page content below diffs" enabled. Thanks for the reporting @Yann, and @Jdlrobson for the permanent fix.

In T356465#9522569, @AnneT wrote:

I'm pretty convinced that we should not worry about this. Codex is the design system for Wikimedia, so I think it's okay to limit ourselves, especially given our limited resourcing, to the themes/modes for Wikimedia products.

To recap, a palette already exists and needs to be integrated into the tokens defined with Codex. So I've got the answer to my question. In addition, it's already planned to add "themes" to Codex components (Vue and only-CSS ones?). So it's more than I expected!

No misunderstanding: I was just asking the questions to find out what the WMF thought about it! I am not sure that volunteers patches to update external dependencies would be appreciated by the WMF staff ; it's a bit of an interference for my taste, and it seems even less trivial to touch mediawiki/core. Updating now to 3.4 seems a bad idea, but 3.3.13 should be good. Not sure about my capacity about sending patches, MediaWiki ecosystem is big and scary.

Also, it seems that @egardner sees into the future. He had already planned interventions like mine. https://gerrit.wikimedia.org/r/c/design/codex/+/978712/1/packages/codex/package.json#86

My bad for the last minor, I quoted the one just before the release of 3.4.0-beta.1.