Page MenuHomePhabricator

Final update: Support for styling message boxes using old markup is being removed
Closed, ResolvedPublic

Description

The following wiki pages use markup for message boxes that has not been supported for some time now (see 2022 update in T300314 for previous recommendation to move away from these styles):
https://global-search.toolforge.org/?q=%5B%5E%3E%3D%5Dmw-message-box&regex=1&namespaces=&title=%5B%5E%5C%2F%5C.%5D*

Vector 2022 has been detecting and styling these but will cease to do so within the next 30 days (T360668).

To avoid losing CSS styling of message Please see https://doc.wikimedia.org/codex/latest/components/demos/message.html#css-only-version for the updated HTML markup you should be using.

Event Timeline

To avoid losing CSS styling of message Please see https://doc.wikimedia.org/codex/latest/components/demos/message.html#css-only-version for the updated HTML markup you should be using.

This is a great way to ensure that styling is lost on any skin other than Vector 2022 and Minerva, immediately rather than within 30 days. Compare the original version with the “fixed”, i.e. broken one on Vector 2010. Could you please, please not break wikis without a suitable replacement being provided?

To avoid losing CSS styling of message Please see https://doc.wikimedia.org/codex/latest/components/demos/message.html#css-only-version for the updated HTML markup you should be using.

This is a great way to ensure that styling is lost on any skin other than Vector 2022 and Minerva, immediately rather than within 30 days. Compare the original version with the “fixed”, i.e. broken one on Vector 2010. Could you please, please not break wikis without a suitable replacement being provided?

You shouldn't be using system message boxes for non-system messages as it is important these are distinguishable from messages in content - we don't want vandals using them for phishing attacks for example. These are not currently marked as a stable interface. As noted in T300314 a lot of usages relate to the historic confusion of messagebox's introduction (context: T300306#7699797) the correct fix here is to move away from that markup to a local template - in this case https://meta.wikimedia.org/wiki/Template:Message looks appropriate.

This was already "broken" in Minerva skin and for Vector 2022 with JS disabled, and there have been messages in the JS console about this for some time:
https://meta.wikimedia.org/w/index.php?title=Tech/Header&oldid=26342327&useskin=minerva

Screenshot 2024-09-16 at 9.12.12 AM.png (1×2 px, 361 KB)

Screenshot 2024-09-16 at 9.12.53 AM.png (1×2 px, 373 KB)

These are not currently marked as a stable interface.

Which doesn’t mean you have to break them. And definitely doesn’t mean you should propose a replacement that silently fails on some skins.

the correct fix here is to move away from that markup to a local template - in this case https://meta.wikimedia.org/wiki/Template:Message looks appropriate.

Local templates are a huge tech debt. They have to be kept up to date on each wiki one by one (wastes a lot of human time) yet are bound to be different across wikis and out of date. Your proposed template

  • doesn’t have any interwikis, i.e. it’s so different across wikis that it doesn’t exist on any other wikis at all (or at least it’s not discoverable);
  • doesn’t work as expected on narrow screens (the horizontal margins and the icon on the left remain no matter how narrow the screen is, leaving too little space for the text);
  • doesn’t work as expected in night mode (remains dark-on-light).

Yes, it’s probably possible to fix these on Meta. And on mediawiki.org if a similar template is created there. And on Commons. And on English Wikipedia. And on French Wikipedia. One by one. I won’t, I have no time for that.

This comment was removed by Izno.

You shouldn't be using system message boxes for non-system messages as it is important these are distinguishable from messages in content - we don't want vandals using them for phishing attacks for example.

After deleting the styles, the only thing that will happen is that almost every project's Common.css will have its own (with varying degrees of obsolescence) copy of these styles. It will not appear in some, and the messages will look bad.

These styles have been used for many years, and it is strange to expect that communities will suddenly decide to come up with their own set of styles for notifications.

And the argument about vandals is quite strange. You can make the same design simply using inline styles. And this does not limit vandals in any way, so only honest editors suffer in this situation.

The phishing attacks are not made more possible by the existence of .mw-message-box class. That argument is just false. By that point you might as well prohibit using TemplateStyles or inline styles as well, since they can replicate even Codex-looking boxes without much work (and currently anyone, including IP editors, can create TS pages on most projects, phishing galore). This change only makes it harder for legitimate users to have warnings/errors/etc. without reimplementing the same markup for the 1000th time. To this end, it should be reversed and completely abandoned as a plan, as the previously planned deprecation of .error class was.

There is also an additional problem where Codex styles do not always get loaded reliably for every user group, see task and comment in T373602: FlaggedRevs: Codex styles display unstyled in some conditions.

While updating Twinkle, putting the following in a sandbox resulted in the second and third divs being unstyled.

<div class="mw-message-box mw-message-box-success">Test</div>

<div class="cdx-message cdx-message--success">Test</div>

<div class="cdx-message cdx-message--block cdx-message--notice">Test</div>

image.png (261×1 px, 5 KB)

https://en.wikipedia.org/w/index.php?title=User%3ANovem_Linguae%2Fsandbox&diff=1246470886&oldid=1246240800

I guess I'll import and hard code the old CSS.

https://github.com/wikimedia-gadgets/twinkle/pull/2014

Thank you for the feedback here. I talked with the Design-System-Team about this and we agreed to continue loading support for the legacy markup on pages which use it as an interim step until there is a better way to generate interface messages in article content. This will be similar to how mw-ui-button styles are currently handled and will not require updating any pages while also resolving the current situation of broken styles in Minerva. More information in T375127.

Generally, we still recommend using Codex markup where you can. For example, messages in the MediaWiki namespace would typically be better served as Codex messages since they are used in a way that’s more similar to system interface messages. https://meta.m.wikimedia.org/wiki/User:Jdlrobson/T374499 provides guidance on how.

In the future we hope to offer better tools for using Codex components in wikitext so that community members don’t have to rely on markup which is not guaranteed to be stable. That work is currently tracked in T363607 and we welcome discussion there or on related subtasks.

I hope this addresses the concerns raised on this ticket.

If things are not working as described, please consider it a bug and file a ticket and I'll make sure it gets looked into.

we agreed to continue loading support for the legacy markup on pages

Thanks. Just to clarify, does this mean that we no longer need to migrate our mw-message-box code by the mentioned deadline of next week? This will continue to work for the foreseeable future?

Also, I feel like the tickets T374499: Final update: Support for styling message boxes using old markup is being removed T300314: [breaking, April 2022] Plan for eventual removal of styles for messagebox, successbox, errorbox and warningbox classes in mediawiki core T360668: Drop support for non-Codex message boxes (mw-message-box) are all related and should probably be linked together as parent/child, but I wasn't sure which one to pick as the parent. Are messagebox and mw-message-box the same thing? If so maybe T300314 should be the parent ticket of the other two.

Thanks. Just to clarify, does this mean that we no longer need to migrate our mw-message-box code by the mentioned deadline of next week? This will continue to work for the foreseeable future?

For markup inside content that's correct but for the 21 impacted. gadgets you'll need to either load mediawiki.legacy.messageBox or mediawiki.htmlform.codex.styles to make sure these get reliably styled per https://meta.wikimedia.org/wiki/User:Jdlrobson/T374499#Migration%20notes

Fixed the Russian Wikipedia gadget but someone really needs to look into why Codex styling does not get fully loaded for IP users at https://ru.wikipedia.org/w/index.php?title=Амстердам&action=edit&section=4 for example (with default skin). @Jdlrobson would appreciate if you could take a look at it if possible.

Fixed the Russian Wikipedia gadget but someone really needs to look into why Codex styling does not get fully loaded for IP users at https://ru.wikipedia.org/w/index.php?title=Амстердам&action=edit&section=4 for example (with default skin). @Jdlrobson would appreciate if you could take a look at it if possible.

Unable to reproduce so far. Is the problem in desktop or mobile? Wikitext editor or visual editor? What should I look for?

Fixed the Russian Wikipedia gadget but someone really needs to look into why Codex styling does not get fully loaded for IP users at https://ru.wikipedia.org/w/index.php?title=Амстердам&action=edit&section=4 for example (with default skin). @Jdlrobson would appreciate if you could take a look at it if possible.

Assuming this is the non-JS editor. This is fixed on current master - so patches will ride the train this week. A long term fix is being tracked in T375246 (basically the edit page and various other pages are using Codex but not adding Codex styles! Doh!).

I haven’t got around replying here. Thanks @Jdlrobson for reversing the decision on the style removal (at least for now)!

No problem. Thanks for the feedback. Sorry for creating any unnecessary stress, I think we all share the same end-goal here of easier to maintain code!

I think we all share the same end-goal here of easier to maintain code!

Yes, absolutely. And the current situation is not really easy to maintain (nor easy to reason about nor error-free – for example, a live preview may miss the necessary styles), so I hope we can reach a solution that’s easier to maintain for MediaWiki developers and on-wiki template maintainers, and doesn’t have its edge cases.

Jdlrobson claimed this task.