In T361299#9730812, @JScherer-WMF wrote:

Thanks for this. Just so I understand, is there potential tech debt or complications that we would incur if we kept the smaller margin? Ideally, the block quote would be inset from both sides of the main paragraph, including the vertical stroke that demarcates it from the other sections.

There is no potential tech debt, but I would argue that mobile format should use as much space as is allowed. Tablet+ can obviously have margins. I just don’t think it necessarily makes sense for a mobile layout (especially since not everyone has big smartphones).

In T362747#9727635, @matmarex wrote:

@stjn I am not sure if the problem you're describing is the same. It's less obvious what could have happened there, but in your case it could actually be outdated CSS, either cached by your browser or somewhere server-side.

I think in that case it was also what you described: new module not propagating to the HTML. It wasn’t browser-side cache because I also checked it without any cache in Firefox Focus etc. But, to be frank, I don’t think it is the same in the desktop version: I use Wikipedia anonymously extensively and I’ve both added and removed gadgets before and the change propagation on desktop is not the same as it is on mobile. I don’t exactly know the reason for it, but it doesn’t take week or two to add a new gadget module to desktop views, for instance.

While this bug is the most apparent, it would be also good to explore in general what causes this problem in Minerva / mobile version in particular. I don't think the expectation of a style change should be any different on Minerva than it is on other skins. If an update is done, it should be properly propagated no matter the skin. Currently that is only the case with async CSS loaded by Minerva’s JS.

I experienced this while trying to do the work on making a common site styles module in Russian Wikipedia.

@Volker_E please comment on the patch if you can. I need to drop https://ru.wikipedia.org/wiki/MediaWiki:Gadget-wikibugs.css#L-21 already :-)

In T361299#9723798, @JScherer-WMF wrote:

Would you mind letting me know the device / viewport width with which that screenshot was taken so I can replicate it on our end?

This is also related to T356532. Even without the block quote styling, the new large text setting can create less optimal character per line numbers, especially in languages with longer words.

This was just my Android device. Obviously the most glaring problems would be seen on 360px, this is somewhere like 480px width and 720px height.

In T316670#9179471, @matmarex wrote:

I think that this could be resolved with min-width on the headings, rather than clear: both. We did that for headings modified by DiscussionTools, which also adds a bunch of extra items to the heading: T335823.

Since this is not getting fixed for such a long time and continues to cause issues, I added min-width: 10em locally (= 240px) in https://ru.wikipedia.org/wiki/MediaWiki:Minerva.css#L-6

What you are describing are deficiencies in Translate extension, not in VE. Same would probably happen if I use https://en.wikipedia.org/wiki/User:BrandonXLF/QuickEdit if the handling of !!FUZZY!! is really so fragile. That should be fixed instead of trying to break VE support for no reason.

@matmarex replying here instead of onwiki: this is this code in jquery.makeCollapsible styles —
https://gerrit.wikimedia.org/g/mediawiki/core/+/67f80e68bf5534d5de317c4ee892707d18760ade/resources/src/jquery/jquery.makeCollapsible.styles.less#46

Interesting. Updated https://ru.wikipedia.org/wiki/Шаблон:Оригинальный_текст to use it, seems to function as intended. I guess this covers all the cases then.

Another option for ruWP might be to turn on the ‘basic’ experience by default since we don't seem to show the ‘advanced’ version to IP users and I would argue ‘advanced’ option is pretty, for the lack of the technical term, shit for everyone else as well. That whole interface really needs a redesign, but in the case of Russian Wikipedia, I think switching it off might be a proper solution as well.

From my own lookup of what causes this, this seems to be caused by the following code in OOUI itself:
https://gerrit.wikimedia.org/g/oojs/ui/+/8e4947086a62a6516df6f2eb125a02d440ebb94b/php/mixins/ButtonElement.php#44

‘At least as visibly as in the wikitext editor’, or... not so much :-) I don’t see why the deficiencies of Translate extension in that department should preclude from fixing this task.

Another argument in favour of putting everything above the input (with an example that is valid for Wikipedia, ‘Stjn’ is not required to be here, it can also just be ‘Manage passwords’ on its own):

Regarding !!FUZZY!!, I think this is a more general issue with Translate extension. See for example this edit: https://translatewiki.net/?diff=12345686 — I think !!FUZZY!! was there at some point and I only ended up seeing it because I went into source code mode afterwards to edit yet again, but nothing was shown upon saving. There might be some other cases where that’s true.

Is there any way to differentiate page-wide translations like MediaWiki translations from these translation units translations? Because making Translate extension compatible can be limited to page-wide translations then so there’s less confusing code.

This continuously causes issues with user scripts after any rename, I am asking someone from Security-Team to take time to review the patch provided.

Why do I have visual editor buttons on translatewiki.net in those namespaces then? (And what would be the problem with keeping it?)

This task should really be declined. Most languages do not have machine translations that are well-translated in comparison to original, especially with technical terms, especially in such a narrow field like Wiki(p/m)edia. Trying to engineer a solution that would at any point involve machine translation in interface messages is just plain wrong. In Russian we are frequently having to remove the results of low-effort machine translations from people who simply press some buttons to translate without knowing both languages full well. WMF should not contribute to this. If you want your tools to be translated to different languages, pay Wikimedians to translate them.

In T361940#9695592, @Ladsgroup wrote:

Doing this will address the problem for everyone regarding that issue: T359529#9684005

This is a massive change in how autoreview was handled though, if intended. Having one or multiple unreviewed templates on a page shouldn’t lead to requiring to review every single edit on a page.

@Zache please comment the same on the other task since this one was closed as a duplicate of T361940: Imports, moves and protections are not autoreviewed

In T361934#9692567, @cscott wrote:

EDIT: actually I think I misunderstood the meaning of "guaranteed invalid" in the spec (https://www.w3.org/TR/css-variables-1/#invalid-variables) and the inheritance won't actually work the way I expected it would. Can someone else double-check my logic and figure out whether this can be done in another way without requiring more custom-property syntax?

Copying the comment: unless you hard-code something to switch it to var( --skin-specific, #fff ), this example would lead to override of #fff to an empty value in all the browsers supporting var() in case --skin-specific is undefined.

@Mabualruz unless you hard-code something to switch it to var( --skin-specific, #fff ), this example would lead to override of #fff to an empty value in all the browsers supporting var().

I had to fix margins yesterday on the main page of Russian Wikipedia because I opened it in new Vector and it had a bunch of spacing problems because of the paddings. I think having only margins to space elements is a reasonable expectation in newer skins (Monobook also has paddings, but, hey) that was broken by the changes described in the task.

By going to https://en.m.wikipedia.org/wiki/Martin_Luther_King_Jr.#/languages I get this:

Fixing this would also fix T309489: Main Page history is not full width

Somewhat of an opinion that <pre lang=""> and <code lang=""> should just function as synonyms to <syntaxhighlight> if the extension is installed. Or something similar to them (language or hlang to differ from HTML lang?). Yes, it is not ‘correct HTML’, but so what? As long as wikitext doesn’t insert the attribute into HTML, we’re fine, I’d say. And <syntaxhighlight> without any lang should be considered an error. (<source> to me is bad since it doesn’t say anything about what the tag does, even if it is less verbose.)

The last note is the result of T282999: Enable Reference Previews on all wikis using the Popups extension, on Nov 21 to which you are privy. We never asked to have ext.cite.referencePreviews enabled, it was done without the community opt-in on an explicit promise that it should not add JS when the project doesn’t want to use it.

In T345960#9680099, @Jdlrobson wrote:

It's already a thing for WMF developers: https://phabricator.wikimedia.org/T360590

Are there any metrics showing what contributes the most to the JS payload? I tried to look into that issue in Russian Wikipedia as a result of the T340705: [performance budgeting] Improve JS payload for projects with gadgets that lead to a 30%+ increase after gzip task, but we ended up with an impression that default gadgets contribute far less into the JS size than the default modules did.

Small comment: if this becomes a thing, this should also become a thing for WMF developers, since (from the looks of it for me) most of the JS payload on Wikimedia websites comes not from gadgets, but from various default JS modules loaded without any possibility to opt-out. Focusing on gadgets then becomes trying to push the blame onto the gadget developers even though they are not the main contributors to JS payload.

In T358071#9679085, @Jdlrobson wrote:

I can't see ambox in https://en.m.wikipedia.org/wiki/Crocus_City_Hall_attack ?

See for example in https://en.m.wikipedia.org/?oldid=1215029134

Keep in mind btw that since T280531: Enable partial action blocks on all Wikimedia production wikis and in MediaWiki by default local sysops already can block users from (re)uploading files and that doesn’t require having a user group (via https://www.mediawiki.org/wiki/Anti-Harassment_Tools/Action_Blocks). I see that the proposal removes autopromotion entirely, but just want to make sure that the decision-makers in the community are aware of this opportunity.

See https://www.mediawiki.org/wiki/Figure_migration / T314318: Disable wgParserEnableLegacyMediaDOM on all wikis

Changed by MusikAnimal after my request.

(I would like to amend the previous comment: I too consider the patch and the merge good for the project, I just think that given the constraints of the current system there should’ve been some amendment that would make possible to use category names with commas in them.)

In T359894#9663983, @Izno wrote:

This is how it was until T280766. That was enough writing on the wall to ditch the name.

Oof. Maybe if Jdlrobson pinky-promises to not touch that class again, you can use error with cs1-specific class?

There is no specific template adding a category, it is added via heuristics. So no, it still requires a gadget while Lua support for categories is not there.

Another alternative is for .cs1-visible-error to implement itself via standard error class while resetting some of its properties.

Encountered another instance where setting a variable on the class level would be beneficial to simpler CSS writing:
https://ru.wikipedia.org/?diff=136900868

Other options would rarely contain categories, but this option is very likely to do so in many languages. I think making this change without considering this was bad.

@Sophivorus @Krinkle can you clarify how this new |categories= syntax can be used with languages that can have comma in category names?.. Currently from looking at the code I see no way to do so, but category names like https://ru.wikipedia.org/wiki/Категория:Персоналии,_умершие_менее_года_назад are entirely correctly named in Russian.

In T248416#9655908, @Tacsipacsi wrote:

…and if I do so, I expect it to work the same way as Minerva on mobile.

That’s not how it currently functions though. You get Minerva without MobileFrontend hacks, not the mobile website.

Would be great to develop https://ru.wikipedia.org/wiki/Template:Ambox styling that doesn’t look bad and works with the current MobileFrontend hacks in some manner. https://en.wikipedia.org/wiki/Module:Message_box/ambox.css looks very ugly and hacky, especially with ‘Page issues’ menu added in. (This is the last blocker to TemplateStyles conversion of these templates I am currently doing in Russian Wikipedia.) See the current style in https://en.m.wikipedia.org/wiki/Crocus_City_Hall_attack

In T360387#9655670, @Izno wrote:

Col-begin still appears to use multicol for columns? (It's another on the list of things to change, but I haven't jumped at this one because there's a lot of articles that could be affected by any div-i-fication.)

Could be easily rewritten into TemplateStyles like https://ru.wikipedia.org/wiki/Шаблон:Столбцы/styles.css

Btw, keep in mind that CSS variables can have a fallback like var( --color-base, #000 ), maybe that is a good thing to advise in the variable use so that dropping a certain token doesn’t cause too many problems.

@CCiufo-WMF this task’s scope is different from that task’s scope.

One other thing I thought of: this would make it so the main pages can no longer expect that the templates included on them would be from stable version. Which might complicate some things in the community side. I agree, I guess, that the impact on the stabilised pages (I am not sure why you keep calling them protect mode?) is less pronounced since it’s not like the big templates on those pages are unprotected. It might be an interesting alternative to limit this feature to pages not protected to a certain level (to help the issue with the main pages), but that might be a bit complicated.

To be more precise, if you have var( --wikipedia-color-infobox-bg ) and it gets overridden on template level to some other value, that could affect things outside the template scope, yes. But so can just putting .infobox { background: #dcc } in TemplateStyles, no? That’s not really fundamentally different things. And the nesting behaviour you describe is already possible via .template .infobox { background: #dcc } without CSS variable use. So TS already has those kinds of scoping complications.

In T322482#8577814, @TheDJ wrote:

This requires updating upstream component css-sanitiser with the new logical property values. This should be relatively simple.

The whole of css-sanitzer could really do with an update, but its quite a bit of manual labor to go through all the specs and make sure everything is up to date (I started once, but calculated that going through all the specs and checking everything is up to date would take me some 20+ hours. And that is just for updating property names and values, not introducing new units or other more invasive spec changes.

As I’ve described previously in T162379#4173054, using Autoprefixer can maybe speed it up the list generation if one would leverage it correctly.

As long as defining CSS variables is scoped to .mw-parser-output children as everything else, is there a problem with it if we would allow to use them? (other than sanitisation, but that one seems potentially solvable by code reuse)

(Per the list in Russian Wikipedia, in more than a thousand pages. A code-based solution would be better at protecting privacy at such a number of pages at large, and would make it easier to revert this action when the political situation in Russia/Belarus changes.)

Respectfully, @Volker_E, I don’t think you’ve read the task correctly. I know a mixin is a thing, I am saying that the end-users of Wikimedia projects should have access to the same mixin via an agreed class name since that would improve accessibility and re-usability of code across projects. Currently this sort of thing gets copied across wikis on an ad-hoc basis, whereas it would be better to create a centrally managed utility class.

Seems like something of an interest for Codex efforts as well, since it could provide an increased use of accessibility text in the projects, which is a net benefit for UI standardisation.

In T334940#9611092, @Bugreporter wrote:

Saying T211881#9425243 here again: The last (before archival) version of graphoid is prone to RCE due to CVE-2020-26296. For a POC, see https://github.com/vega/vega/issues/3018#issuecomment-748929438

I wasn’t strictly talking about making Graphoid available again, I was talking about providing a sandboxed generator of Graphoid-like images. Maybe I am missing something, but I can’t see this being impossible in the same way that container version of Lilypond is able to be used.

Shouldn’t have there been a follow-up that made these signatures illegal in the current signature parser? Because right now <math display="block"> is saveable into the prefs, and I’m sure <score> is too.

In T359765#9621233, @Tacsipacsi wrote:

That’s quite long ago. 🙁 I wish it would be fixed (by using URL escapes), but who knows how many templates were built around this buggy behaviour in the past thirteen years…

Ehh. Not sure this should be a justification for keeping the bug in, though. If someone used this buggy behaviour in their templates, let them fix those templates. Should be simple (with wikitext or Lua).

In T359529#9614890, @Ladsgroup wrote:

What you're referring is called "protect mode" (i.e. you protect some pages to be reviewed) and that's actually can't be enabled with flaggedtemplates feature at the same time. Protect mode disables a lot of FR features. At least that's my understanding of the code.

If I understand correctly, we are talking about the feature that makes the top-page notice ‘This page has unreviewed templates or files: …’, right? Then the above I am not describing the protect mode, I am describing stabilisation. Protect mode is enWP-only (mostly) thing, other wikis usually do not use FR in the same way. If I am correct about this being related to that top-page notice, it works with any transclusions, but non-FR-ed namespaces (not modules) do not work correctly with it.

It is strange to me to close the older task as a duplcate of the newer one, but alright.

In T13555#9615648, @matmarex wrote:

I'm sorry that this caused work for you. It seems that nothing else was affected and no one else seems to have noticed, so I'm going to leave it like that, until we're ready to change the entire markup.

That’s not true: I had to make a comment here after this being a problem for different people for three times. Autogenerated summaries got affected even if you don’t use CD, and some user scripts and gadgets also were broken by this (see https://ru.wikipedia.org/wiki/Обсуждение_Википедии:Гаджеты/Гаджет_проекта_«Добротные_статьи»#Гаджет_добавляет_слово_"подписаться"_в_список_ДС.).

So. The benefit of this feature being present is that the template editors are not necessarily tied too much by ‘template stability requirements’ since MediaWiki would show the previous version of the same template if really needed. The bot run can happen replacing one code with another for whatever reason, and in stabilised articles, it wouldn’t be a problem if the page was unreviewed for a while. The removal of this feature would affect the projects where FlaggedRevs is in ‘stable by default’ mode the most, but at the same time, those projects might have less of a backlog. In the case of ‘stable by default in some articles but not all’ setup, it would definitely affect the stabilised pages, potentially leading to some wrong results from a template change that wasn’t reflected in the stable version of the wikitext of the page. I would say that making the behaviour more performant or maybe affecting the articles where the template versioning is a problem is preferable to removing it outright (although I might be not thinking of the right thing in my comment, clarify if needed, I think this is how it is supposed to work?).

@matmarex can you maybe comment on the cause of the above?

In T334940#9605163, @TheDJ wrote:

I personally still think that running something on toolforge and exporting to SVG which can then be uploaded, is the most flexible, easiest to realize and most usable short term way to enable rich creation tools. It creates a hard separation between security contexts and avoids any sort of fragile dependency on MediaWiki and Wikimedia. The uploading can even be automated, OAuth login and commons uploading are commonly implemented things in tools already. You loose interactivity, but interactivity was already pretty rare in graphs.

At that point, you might as well resurrect Graphoid in a more secure way. Which is, by the way, a solution: sandbox Vega JS part on the server, allow users to generate graph SVG or PNG images, and that’s it. No interactivity, of course, but also no security threat to the end-users. Which is what the original removal of Graph extension was about. Tbf I don’t get why the perfect is such an enemy of the good here, yes, maybe Graph extension should be phased out in the long-term, but currently we are serving readers a big pile of nothing for the last year. Surely the WMF, with all of its resources, can develop a short-term solution that would not compromise security and then work on a long-term solution. @MMiller_WMF’s email seems weirdly avoidant of that.

In T334940#9602916, @Bawolff wrote:

T336595 feels like a band-aid solution and a bad one at that. It does nothing to adress the underlying security problem or maintenance problem. I personally don't think we should do that except as a last resort.

But, to be clear, having graphs unavailable for a year already feels like there needs to be some last resort solution. I don’t see why Graphs cannot be brought back with tight security requirements about editing them, and then a more comprehensible solution can be worked out by the engineers (maybe even dropping the current library etc., but, eh, not waiting for two years for a new solution). Many wikis have used graphs extensively and therefore require them to be back, even though that might not apply to English-speaking audiences.

Hey, just want to say that this work is great. Having buttons at the bottom brings another usability improvement: they are simply closer to the user in terms of finger movement etc. Material design guidelines, I think, are not really representative of actual usability trends: take, for example, their inputs, that have been weird for years now. At the same time, I have a related question: was the right-aligned placement of the buttons in desktop contexts in any way tested for accessibility? Because as far as I know, it is generally preferred to keep the buttons next to the input fields at least for one reason: in magnifier-related context user will be less likely to miss the buttons that are located close to what they are doing/reading (see https://axesslab.com/make-site-accessible-screen-magnifiers/ as an example post to that point). Thanks in advance for the answer.

I see the same issue with

HTML spec and WCAG spec are two separate things. We were discussing the case of the duplicated accesskeys with @sgrabarczuk in Russian Discord server (in English) and the thing is, many of those duplicated ones are just duplicated items in various menus (Edit button also present in Actions menu, etc.). If this is to try to get the elements resized correctly, then yes, probably some JS to move accesskeys around to the element that is not display: none is needed. But the HTML on the page also should not be giving duplicated edit accesskeys etc. by default, because having them duplicated is like having IDs duplicated: wrong for accessibility (and understandability for those who use the accesskeys).

The solution is to not get two accesskeys onto the page in the first place. It is a WCAG violation: https://www.w3.org/TR/2014/NOTE-WCAG20-TECHS-20140311/F17

I can’t, that’s why I said ‘possibly’. Things to check can be stuff like redirect/page creations, but I can’t know for sure.

I think button wrapping is valid to handle separately from general truncation. Since in the buttons, there can be some instances where you cannot put entire button text on the available screen space (e. g. the button in the example screenshot above). Though I would argue that in the ideal world even such cases should be handled by adapting design in the languages where the button gets truncated, or fixing the word usage, etc., and not cutting off text that can be valuable to understanding what the button in question does.