This problem has already been solved. Can we fix the misuse of mw-body-content instead introducing a confusingly similar an entirely new and mw-content-body class and thus make skin developers learning curve greater?
I believe that issue is separate and already tracked in T215271
Transforms apply to all pages. We have no concept of page specific transforms at the current time. We have a configuration option MFMobileFormatterOptions so I suppose we could. There are plans to limit transforms on talk pages (T280051) so perhaps that would allow us build on that.
I honestly have no idea what the other current ones actually do and couldn't find any documentation, so I'll just stop here...
Looking close, this was a problem because span.selector-open was being used as the $trigger inside ext.uls.launch instead of the heading... this should fix the problem.
On beta cluster, it seems the mw-interlanguage-selector class has moved from the button to h3
I have opened T280825 to avoid confusion between requirements and discussion here, to preserve this discussion for prosperity.
The patch to review is https://gerrit.wikimedia.org/r/c/mediawiki/core/+/681488 - happy to walk you through it.
Sounds good. Thanks!
Yes I am pretty sure these are due to HTML error pages being treated as JS. I have witnessed this happen on one occasion.
The problem here is that mbox- class is used in other places and last time I checked not very friendly to mobile phones. I don't know how widely used these are on Russian Wikipedia, but wikis should feel free to re-define what content gets stripped via a site configuration change to wgMFRemovableClasses. No changes to MobileFrontend or Minerva are needed here.
I'm revisiting the links inside elements based on the regression in T279693.
Thanks everyone. I can confirm this is finally working and backported.
@Volker_E have broken out the acceptance criteria
 Remove all extra visual properties aside of pure box layout properties  Replace outdated PNG icon with current standard icon and consider SVG
I'll QA this one and resolve.
Basically need to check that https://en.wikipedia.beta.wmflabs.org/wiki/Special:Book unbreaks.
Sorry Edward for the accidentally assignment :)
Make it actually backward compatible per T280723, as a meta package for the split components, so that skins that were happy with it as-was don't immediately break? Because this isn't just affecting deployed Wikimedia skins, this is also breaking almost all other skins as well.
Several styles previously found in 'interface' or 'elements' or 'content' or something (I'm not really sure which, as I've never really used any of these to begin with) are now in legacy. This includes the toc-style catlist box and thumbnail icons that now override any skin-specific icons (T280292).
Sounds good. I'll open new bugs.
...what? Why is that any better? How is this not just breaking things for the sake of breaking things?
we met today to talk about this and we are going to decline it. Assigning Olga to summarize,
Bumping priority then and tagging appropriately. Thanks!
When we add these new components, could I suggest that we take the opportunity to think about how the packaging would work and how we want to make use of asycnrhonous components. In particular I'd like to ensure these are not packaged in the critical path, perhaps in a wvui.forms npm module?
For those who have access the subject is [reading-wmf] Future work idea: skin system and in the e-mail @bd808 describes a skin system and points to us doing T483 (which is now done) with replies from myself and @Tgr .
@Huji I presume this bug is significant enough to require backporting to the 1.36 release since it breaks RTL display of a prominent UI element. Is this a good presumption to make?
@cjming I did a POC a long time ago https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/656518 that may be of some help as you dive into this one.
Stalled on the A/B test task T275807. Assigning to myself while analysis is not possible.
Seems like this would benefit from discussion. Can always backport at later date.
If Jan can review the last patch I think we're good to call this done!