User talk:Jon (WMF)

Bay Area WikiSalon series kickoff, April 27

Please join us in San Francisco!

A Wikipedia panel discussion about journalism — Panel discussion at a recent Wikipedia & Journalism event.

The last Wednesday evening of every month, wiki enthusiasts in the San Francisco Bay Area will gather to collaborate, mingle, and learn about new projects and ideas. We have two brief presentations lined up for our kickoff event in downtown San Francisco:

The Nueva Upper School recently hosted the first ever high school Wikipedia edit-a-thon. We will hear what interests them about Wikipedia, what they have learned so far, and what they hope to achieve.
Photojournalist Kris Schreier Lyseggen, author of The Women of San Quentin: The Soul Murder of Transgender Women in Male Prisons, will tell us about her work and how she researched the topic.

We allow time for informal conversation and working on articles. Newcomers and experienced wiki users are encouraged to attend. We will have beverages and light snacks.

Please note: You must register here, and bring a photo ID that matches your registration name. The building policy is strict on this point.

For further details, see here: Wikipedia:Bay Area WikiSalon, April 2016

We hope to see you -- and until then, happy editing! - Pete, Ben & Wayne

Invitation to the Bay Area WikiSalon series on May 25

Please join us in downtown San Francisco!

The last Wednesday evening of every month, wiki enthusiasts gather at Bay Area WikiSalon to collaborate, mingle, and learn about new projects and ideas.

We allow time for informal conversation and working on articles. Newcomers and experienced wiki users are encouraged to attend. We will have beverages and light snacks.

Please note: You must register here, and bring a photo ID that matches your registration name. The building policy is strict on this point.

For further details, see: Wikipedia:Bay Area WikiSalon, May 2016

See you soon! Pete F, Ben Creasy, and Checkingfax via MediaWiki message delivery (talk) 01:15, 9 May 2016 (UTC) | Subscribe/Unsubscribe to the SF Meetups notice.[reply]

Invitation to the Bay Area WikiSalon series, Wednesday, June 29

Please join us in downtown San Francisco!

The last Wednesday evening of every month, wiki enthusiasts gather at Bay Area WikiSalon to collaborate, mingle, and learn about new projects and ideas.

We make sure to allow time for informal conversation and working on articles. Newcomers and experienced wiki users are encouraged to attend. Free Wi-Fi is available so bring your editing devices. We will have beverages and light snacks. We will also have:

A brief report on Pride edit-a-thon recently held at the San Francisco Publice Library, coordinated by Merrilee:
What topics might we cover in a follow up?

Find out more about resources your public library provides to help with editing (hint, it's more than just books!)

Special announcement (secret for now but come and find out more!)
Join in on an in person Wikidojo!
Are you curious how your peers approach writing a Wikipedia article? This exercise, pioneered by Wikipedians Nikola Kalchev and Vassia Atanassova in 2015 and conducted in many places around the world, will help us all - from first-time wiki users to veteran Wikipedians - share ideas, while building an article together. If you have ideas (relating to Bay Area history, ideally) about a new article we could build (stubs and short existing articles are fine), please submit them ahead of time to coordinator Pete Forsyth. (User talk page or email is fine.)

Announcements and impromptu topics are welcome, too!

Please note: You must register here, and bring a photo ID that matches your registration name. The building policy is strict.

For further details, see: Wikipedia:Bay Area WikiSalon, June 2016

See you soon! Pete F, Ben, Stephen and Checkingfax | (Subscribe or Unsubscribe to this talk page notice here)

MediaWiki message delivery (talk) 10:07, 19 June 2016 (UTC)[reply]

REMINDER/invitation to the Bay Area WikiSalon series, Wednesday, June 29 at 6 p.m.

Please join us in downtown San Francisco tonight!

If you cannot join in person or want to view portions later:

We will have:

Light snacks, and time to mingle
A brief report on the Pride edit-a-thon recently held at the San Francisco Public Library, that was coordinated by Wiki editor Merrilee
A special announcement (secret for now but come and find out more!)
Join in on a brief in person Wikidojo!
Announcements and impromptu topics are welcome, too!

Please register at: https://docs.google.com/forms/d/1cjLRrSTlEkGOPTQ-h6A0WvSFI4ZmIUl6jEHp_RYas-E/viewform and bring a photo ID that matches your registration name. The building policy is strict.

For further details, see: Bay Area WikiSalon, June 2016

See you tonight! Pete F, Ben, Stephen and MediaWiki message delivery (talk) 15:48, 29 June 2016 (UTC) | (Subscribe or Unsubscribe to this talk page notice)[reply]

Late breaking invitation to the Bay Area WikiSalon series, July 27 (Wednesday) - change of venue - tonight

Please join us in the Mission at Noisebridge (one time change of venue)!

We hope you can join us today, Wednesday, from 6 p.m. on, at our July Bay Area WikiSalon. This month only, we are going to be at Noisebridge, a hackerspace/makerspace 1.5 blocks from the 16th & Mission BART station (see the link for directions). Some of us will be working on the Wikipedia article on basic income. All info here. Some good news - we do not have to be as strict about advance RSVP at Noisebridge, so bring spontaneous guests! (Registering ahead of time is still helpful, as always, as it will help us plan ahead.)

Come and hang out, have some light snacks. Wi-Fi is available, so please bring your editing device if you plan to edit.

Also, Pete just published a writeup of the Wikidojo exercise we did last month. Your comments welcome, if he missed anything! http://wikistrategies.net/ghost-town-royals-wikidojo

The last Wednesday evening of every month, wiki enthusiasts gather at Bay Area WikiSalon to collaborate, mingle, and learn about new projects and ideas. Mark you calendars now.

We allow time for informal conversation and working on articles. Newcomers and experienced wiki users are encouraged to attend.

See you soon! Pete F, Ben Creasy, Stephen and Wayne | (Subscribe/Unsubscribe to this talk page notice here)

MediaWiki message delivery (talk) 17:05, 27 July 2016 (UTC)[reply]

Invitation to the Bay Area WikiSalon series, Wednesday, August 31

Please join us in downtown San Francisco!

Hi folks,

We would like to invite you to this month's Bay Area WikiSalon. The last Wednesday evening of every month, wiki enthusiasts gather to collaborate, mingle, and learn about new projects and ideas.

We make sure to allow time for informal conversation and working on articles. Newcomers and experienced wiki users are encouraged to attend. Free Wi-Fi is available so bring your editing devices. We will have beverages and light snacks. We will also have a brief presentation for your education and possible enjoyment:

Former EFF intern Marta Belcher will discuss crowdsourcing her Stanford Law School graduation speech using a wiki. The "WikiSpeech" was the subject of prominent national media attention in 2015, and more than half of her classmates contributed to writing and editing the commencement address via a wiki.

Please note: You should register here, and bring a photo ID that matches your registration name. The building policy is strict on the I.D. part. This also helps us figure out how much food and drink to bring in! Feel free to stop by even if only to say a quick hello, but you might have to give us a last minute call if you forget to RSVP. Also, don't be shy about hitting us up if you have thoughts on speakers or wiki-related activities.

For further details, see: Wikipedia:Bay Area WikiSalon, August 2016

See you soon! Pete F, Ben, Stephen and Checkingfax | (Subscribe or Unsubscribe to this talk page notice here)

MediaWiki message delivery (talk) 21:05, 29 August 2016 (UTC)[reply]

Tonight: Live and archived links for Bay Area WikiSalon

Bay Area WikiSalon, Wednesday, August 31:

If you cannot join us in person tonight, we are streaming (and later archiving) the presentation by former EFF intern Marta Belcher. We expect her to be live starting between 6:30 or 6:45 p.m. PDT and talking and taking questions for about 30 minutes thereafter.

Here is the YouTube stream link: https://www.youtube.com/watch?v=-t8V79s2-og
Here is the link to join the Hangout on Air: https://hangouts.google.com/call/ezrol7dafjfwxfh2ilpkjyxoaue

You can search for it on the Commons and YouTube later too.

Wayne, Pete, Ben, and Stephen

MediaWiki message delivery (talk) 22:50, 31 August 2016 (UTC)[reply]

Invitation to the Bay Area WikiSalon series, Wednesday, September 28

Please join us in downtown San Francisco!

Hi folks,

We would like to invite you to this month's Bay Area WikiSalon. The last Wednesday evening of every month, Wikipedia and Wikimedia enthusiasts gather to collaborate, mingle, and learn about new projects and ideas.

We will have no formal agenda to allow people to freely share ideas and perhaps learn about Wikipedia through hands-on editing. Co-organizer Ben Creasy will be looking at election-related articles to enhance the information available in the upcoming November elections.

Co-organizer Stephen LaPorte has suggested doing an upload-a-thon for Wiki Loves Monuments. Niki, the California coordinator for WLM will be in attendance. WLM is an annual event and the official dealine is Friday the 30th for submissions to count towards awards.

Or, you can grab a couch, a booth, or a stool and do your own thing.

Please note: You should register here, and bring a photo ID that matches your registration name. The building policy is strict on the I.D. part. This also helps us figure out how much food and drink to bring in! Feel free to stop by even if only to say a quick hello, but you might have to give us a last minute call if you forget to RSVP. Also, don't be shy about hitting us up if you have thoughts on future speakers or wiki-related activities.

For further details, please see: Wikipedia:Bay Area WikiSalon, September 2016. Mark your calendars now for the 3rd Wednesday in October, the 26th, when we will have a brief presentation.

See you soon! Pete F, Ben, Stephen and Checkingfax | (Subscribe or Unsubscribe to this talk page notice here)

MediaWiki message delivery (talk) 01:35, 24 September 2016 (UTC)[reply]

You are invited to a Wednesday evening event in SF

Please join us in downtown San Francisco!

Hi folks,

Please copy and share this on other talk pages. We would like to invite you to this month's Bay Area WikiSalon. The last Wednesday evening of every month, Wikipedia and Wikimedia enthusiasts gather at the Wikimedia Foundation lounge to collaborate, mingle, and learn about new projects and ideas.

We will have no meaty agenda this month, but we will allow a brief period for:

Open mic for anybody who attended WikiConference North America 2016 in San Diego last week and wants to share their takeaway
Question & answer
Open mic for announcements
Maybe a focus on some topical election article editing with Ben?

Or, you can grab a couch, a booth, a stool or counter and do your own thing.

Please note: You should register here, and bring a photo ID that matches your registration name. The building policy is strict on the I.D. part. This also helps us figure out how much food and drink to bring in! Feel free to stop by even if only to say a quick hello, but you might have to give us a last minute call if you forget to RSVP. Also, don't be shy about hitting us up if you have thoughts on future speakers or wiki-related activities.

For further details, please see: Wikipedia:Bay Area WikiSalon, October 2016.

PS: Mark your calendars ahead now for the 3rd Wednesday in November, the 30th (the week after Thanksgiving), at 6 p.m. when our WikiSalon will host a super awesome top secret mystery guest mingling in our midst. We will announce specifics at the upcoming WikiSalon.

See you soon! Pete F, Ben, Stephen, Jacob, and Checkingfax | (Subscribe or Unsubscribe to this talk page notice here)

MediaWiki message delivery (talk) 08:51, 22 October 2016 (UTC)[reply]

Everybody is invited to the November 30 Bay Area WikiSalon

Please join us in downtown San Francisco!

Details and RSVP here.

See you soon! Pete F, Ben Creasy, and Checkingfax | (Subscribe/Unsubscribe to this talk page notice here)

MediaWiki message delivery (talk) 00:54, 29 November 2016 (UTC)[reply]

Bay Area WikiSalon series: Everybody is invited this Wednesday evening at 6

Please join us in downtown San Francisco!

The last Wednesday evening of every month, wiki and open-source enthusiasts gather at Bay Area WikiSalon to collaborate, mingle, and learn about new projects and ideas.

Before and after the brief presentation we allow time for informal conversation and working on articles. Newcomers and experienced wiki users are encouraged to attend. Free Wi-Fi is available so bring your editing devices. We will have beverages and light snacks.

In addition, this month we will have:

a brief presentation from User:Cullen328 (Jim Heaphy) about the Wikipedia Teahouse
spontaneous lightning talks from the floor
community announcements from the floor

For details and to RSVP see: Wikipedia:Bay Area WikiSalon, December 2016

See you soon! Ben Creasy and Checkingfax | (Subscribe/Unsubscribe to this talk page notice here)

+++++
P.S. Any help spreading the word through social media or other avenues is most welcome! We plan to announce this on various sites and invite various groups; if you would like to join in, check our meta planning page, and please note any announcements you are sending out: meta:Monthly WikiSalon in San Francisco#Announcements and promotion

Please feel free to add to, refine, reorganize or edit the above linked page: it is a wiki!

We need more helpers and organizers, so if you see a need, please jump in, or talk to us about it! You can add your username to the meta page where appropriate, or create a new role!

MediaWiki message delivery (talk) 21:44, 12 December 2016 (UTC)[reply]

Reminder invitation to the December Bay Area WikiSalon

Please join us in downtown San Francisco!

Hi, everybody.

We are excited to remind you of the ninth in the Bay Area WikiSalon series that is coming up this Wednesday evening at 6 p.m.

Details (RSVP suggested) here (RSVP helps us know how much food and drink to bring in)

What is a WikiSalon? A monthly safe and inclusive meatspace event conducted in organized chaos and we all clean up the mess afterwards. Livestream links for the presentation are available during presentation months, and will be forthcoming for those of you that cannot attend. December is a presentation month.

Hope to see you there! Wayne (and Ben) - co-organizers
Any last minute questions or suggestions? Please ping or email Ben or me. | (Subscribe/Unsubscribe to this talk page notice here)

MediaWiki message delivery (talk) 05:10, 20 December 2016 (UTC)[reply]

Archived link for December Bay Area WikiSalon

Hi, y'all. In case you missed it and want to watch the archive reel; the topic was The Wikipedia Teahouse and the presenter was well respected Wikimedian Jim Heaphy [[User:Cullen328]]

Archive link (also includes intro, announcements, and a lightning talk)

Details about Bay Area WikiSalon for December here

The full title of Jim's presentation was: Welcoming and Helping New Editors: A Month at the Wikipedia Teahouse: an overview of the Teahouse and an analysis of over 300 Teahouse conversations during the month of August, 2016

Jim gave a longer version of this presentation in October at WikiConference North America 2016 in San Diego, California.

Cheers! Co-organizer Checkingfax - and co-organizer Ben Creasy | (Subscribe/Unsubscribe to this talk page notice here)

PS: Mark your calendars now for Sunday, January 15 at 2 p.m. which will be Wikipedia's 16th Birthday party hosted by Bay Area WikiSalon! Details to follow soon. If you want to help plan it, get in touch with us ASAP!

MediaWiki message delivery (talk) 01:43, 23 December 2016 (UTC)[reply]

Discussion at MediaWiki talk:Relatedarticles-read-more-heading#Protected edit request on 28 December 2016

You are invited to join the discussion at MediaWiki talk:Relatedarticles-read-more-heading#Protected edit request on 28 December 2016. A question about an edit you made there. Jo-Jo Eumerus (talk, contributions) 14:34, 28 December 2016 (UTC)[reply]

You are invited to a birthday bash to Celebrate Wikipedia's 16th Birthday!

Please join us in downtown San Francisco!

Wikipedia Day 16 SF is a fun Birthday bash and edit-a-thon on Sunday, January 15, 2017, hosted by Bay Area WikiSalon at the Wikimedia Foundation's Chip Deubner Lounge in the South of Market Street business district.

For details and to RSVP, please see: Wikipedia:Meetup/SF/Wikipedia Day 2017

The San Francisco gathering is one of a number of Wikipedia Day celebrations worldwide.

See you soon! Ben Creasy, Checkingfax and Slaporte | (Subscribe/Unsubscribe to this notice)

PS: We need volunteers to help make this a fun and worthwhile event. Please add your name to the Project page, and what you can offer. It is a wiki, so please make direct edits to the page.

Bay Area WikiSalon usually meets the last Wednesday evening of every month as an inclusive and safe place to collaborate, mingle, munch and learn about new projects and ideas.

MediaWiki message delivery (talk) 07:52, 8 January 2017 (UTC)[reply]

Reminder invitation to the Wikipedia Day 16 birthday bash & edit-a-thon

Please join us in downtown San Francisco!

Wikipedia Day 16 SF is a fun Birthday bash and edit-a-thon on Sunday, January 15, 2017, hosted by Bay Area WikiSalon at the Wikimedia Foundation's Chip Deubner Lounge in the South of Market Street business district and everybody is invited!

Details and RSVP here

See you Sunday! Ben Creasy, Checkingfax and Slaporte

PS: We still need more volunteers to help make this a fun and worthwhile event. Please add what you can offer and your name to the Project page or Talk about it. It is a wiki, so please make direct edits to the Project page. The event is already growing due to volunteers that have stepped up so far.

Bay Area WikiSalon meets one evening of every month as an inclusive and safe place to collaborate, mingle, munch or learn about new projects and ideas.

Note: the previous invitation had a bum wikilink. Sorry! | (Subscribe/Unsubscribe to this notice) | MediaWiki message delivery (talk) 06:43, 13 January 2017 (UTC)[reply]

Bay Area WikiSalon invitation for February 22

Please join us in downtown San Francisco!

The last Wednesday evening of every month, wiki enthusiasts gather at Bay Area WikiSalon to collaborate, mingle, and learn about new projects and ideas.

We allow time for informal conversation and working on articles. Newcomers and experienced wiki users are encouraged to attend. Free Wi-Fi is available so bring your editing devices. We will have beverages (including beer and wine) plus light snacks.

Please note: You should RSVP here, and bring a photo ID that matches your registration name. This also helps us figure out how much food and drink to bring in.

For further details, see: Wikipedia:Bay Area WikiSalon, February 2017

See you soon! Ben Creasy and Wayne | (Subscribe/Unsubscribe to this talk page notice here) | MediaWiki message delivery (talk) 06:47, 15 February 2017 (UTC)[reply]

Bay Area WikiSalon February reminder

Please join us in downtown San Francisco!

Wednesday, February 22, 2017 at 6 p.m.

For details and to RSVP: Wikipedia:Bay Area WikiSalon, February 2017

See you soon! Ben Creasy and Wayne (co-coordinators) | (Subscribe/Unsubscribe to this talk page notice here) | MediaWiki message delivery (talk) 02:58, 21 February 2017 (UTC)[reply]

Your invitation: Bay Area WikiSalon series at Noisebridge

Please join us in San Francisco!

The last Wednesday evening of every month, wiki enthusiasts gather at Bay Area WikiSalon to collaborate, mingle, and learn about new projects and ideas. This month we are meeting at Noisebridge makerspace/hackerspace in the Mission near 16th Street BART (temporary change of venue). The good news is this means that you can bring spontaneous guests if you forget to RSVP!

We allow time for informal conversation and working on articles. Newcomers and experienced wiki users are encouraged to attend. Free Wi-Fi is available so bring your editing devices. We will have beverages (including beer and wine) plus light snacks.

If possible, please RSVP as it helps us figure out how much food and drink to bring in. For further details and to RSVP, please see: Wikipedia:Bay Area WikiSalon, March 2017

See you soon! Co-coordinators Ben Creasy and Wayne
(Subscribe/Unsubscribe to this talk page notice here) | MediaWiki message delivery (talk) 02:06, 23 March 2017 (UTC)[reply]

Reminder: Tonight is Bay Area WikiSalon at Noisebridge

Please join us in San Francisco!

Details and to RSVP: Wikipedia:Bay Area WikiSalon, March 2017 (optional, but helpful for food and special needs accommodations)

We are meeting at Noisebridge makerspace/hackerspace (temporary venue change) near 16th ST BART in SF.

See you soon! Co-coordinators Ben Creasy and Wayne
(Subscribe/Unsubscribe to this talk page notice here) | MediaWiki message delivery (talk) 18:52, 29 March 2017 (UTC)[reply]

Wednesday night you are invited! Bay Area WikiSalon

Please join us in downtown San Francisco!

The last Wednesday evening of every month, wiki enthusiasts gather for the Bay Area WikiSalon series to collaborate, mingle, and learn about new projects and ideas.

We allow time for informal conversation and working on articles. Newcomers and experienced wiki users are encouraged to attend. Free Wi-Fi is available so bring your editing devices. We will have beverages (including beer and wine) plus light snacks. We will have some announcements and lightning talks from the floor, and a breakout session. This is our one year anniversary, so there will be cake!

Please RSVP here, and bring a photo ID that matches your registration name. This also helps us figure out how much food and drink to bring in.

See you soon! Ben Creasy and Wayne
(Subscribe/Unsubscribe to this talk page notice here) | MediaWiki message delivery (talk) 06:19, 26 April 2017 (UTC)[reply]

Template:Editnotice load

Hello Jon (WMF), please see Wikipedia talk:Editnotice regarding the change you enacted.

Common.css .hlist :after

Your recent edit to MediaWiki:Common.css, adding #content to one of the .hlist :after rules, made its specificity higher than the two subsequent .hlist :after, causing those rules to no longer function. Please add #content to the other two .hlist :after rules. Matt Fitzpatrick (talk) 19:49, 10 October 2017 (UTC)[reply]

enwiki infoboxes

Hello Jon, please see w:en:Template_talk:Infobox#editinterfaceprotected regarding a change you have recently been involved with. — xaosflux ^Talk 15:26, 15 December 2018 (UTC)[reply]

Mobile.js

Hello Jon, would you please review the ask at MediaWiki_talk:Common.js#Interface-protected_edit_request_Mobile.js? Thank you, — xaosflux ^Talk 12:59, 15 July 2019 (UTC)[reply]

MediaWiki:Minerva.js

Your edit summary here contradicts what is written on the page as a comment. Which one is correct? SD0001 (talk) 07:27, 9 October 2019 (UTC)[reply]

Are you asking whether Minerva.js runs on Minerva desktop and mobile? That patch was written some time ago so while that was true then, I'm not sure what the current state is. Minerva.js is supposed to load on desktop and mobile, but I'm not sure what the current situation is and whether there still remains a bug (and if not, if such a bug opens). If there is a bug it relates to the longstanding bug in https://phabricator.wikimedia.org/T127268. Jdlrobson (talk) 22:27, 9 October 2019 (UTC)[reply]

Temporary Main Page Banner

Hi Jon (also ping to Jdlrobson in case you are on your personal account), we have temporarily activated Template:Main page banner, but it is not incorporated to the mobile view (e.g. Main Page Mobile View). This is wrapped in an id="mp-banner" div on Main Page. Is there a simple way for us to have this load to the mobile view you would suggest? — xaosflux ^Talk 16:00, 24 January 2020 (UTC)[reply]

@CKoerner (WMF): any hints on where we can get some help on this? We may run out of time for this specific need - I tried on IRC mobile channel but got nowhere. Would still want to get better documentation on this for any future needs. — xaosflux ^Talk 00:15, 25 January 2020 (UTC)[reply]

N.B. attempting to use an mf-banner id (instead of the existing mp-banner) did not appear to work, unless it takes some time to take affect - was worried about a MP change without seeing a change to leave it in place. — xaosflux ^Talk 01:27, 25 January 2020 (UTC)[reply]

Hey @Xaosflux: have you looked at mw:Recommendations_for_mobile_friendly_articles_on_Wikimedia_wikis? I think the issue is with certain classes/elements being hidden on mobile. Mobile might need its own banner to work. CKoerner (WMF) (talk) 13:33, 25 January 2020 (UTC)[reply]

Oh, this page too might be helpful. mw:Mobile_Gateway/Mobile_homepage_formatting CKoerner (WMF) (talk) 13:36, 25 January 2020 (UTC)[reply]

@CKoerner (WMF): yes, not working though - from what I can tell we are on legacy frontend, and also on main page special casing, but I'm a bit lost on the config. This is what I'm hoping a better expert can weigh in on specifically. — xaosflux ^Talk 14:49, 25 January 2020 (UTC)[reply]

We haven't had a lot of community focus on our mobile main page compared to our web one - and we probably should considering the large change in readership lately. phab:T32405 and phab:T138622 may deserve some renewed attention this year, and it certainly won't be easy community-input wise based on past attempts if it isn't done carefully. I agree with the comments in there that step-wise improvements in coding, without also trying to adjust actual content would be a good first start. We do have a lot of dedicated editors that focus on main page content - and that is a good thing, but if discussions stray in to things like 'how often should a "featured list" be presented' discussions are likely to deadlock. I really do think we can get past the "table" layout challenge and use a more responsive design as long as other components don't get "while we're here"'d at once. I was a opponent of one of the designs last year that I thought was mostly better - but it introduced some fixed-width elements that were opposed and the proponents were entrenched with also adding that feature for example. — xaosflux ^Talk 14:49, 25 January 2020 (UTC)[reply]

Hey all. Sorry I was out on vacation so unable to answer. Can't replicate with the current URI. Is there another URI I can test this with? I think getting English Wikipedia off special main page casing should be a top priority. The table layout challenge as you say should be the focus. Is there anything I can do to help with that? I'd be interested in making a template for that without making any changes to the desktop site if that would be widely received. I'd assume such a change would not need to go through a lengthy RFC process provided it kept the status quo in appearance and just altered underlying HTML? Jdlrobson (talk) 08:42, 27 January 2020 (UTC)[reply]

@Jdlrobson: for the immediate issue, should mf- tags work here? What and where is the config of what is included in our mobile front end for main page right now? Where and who can adjust this? — xaosflux ^Talk 21:06, 27 January 2020 (UTC)[reply]

Hard to say whether mf tags would help here without being able to reproduce this issue. There are a variety of things at play in the legacy main page transformer and poor documentation, which is why I've been discouraging its usage. I believe mf- prefixed elements do not get stripped only provided no mp- elements exist but I'd have to refamilarise myself with the code to determine when and where that works. Old revisions from 2013 of mw:Mobile_Gateway/Mobile_homepage_formatting might have some more details. Jdlrobson (talk) 01:36, 28 January 2020 (UTC)[reply]

@Jdlrobson: thank you - please update with what you find. If we need to refer this else where, direction to whom would be useful if you know. — xaosflux ^Talk 02:01, 28 January 2020 (UTC)[reply]

can you point me to a minimum test case? I can't see the issue you are facing and am unable to look into this until that happens.

https://en.m.wikipedia.beta.wmflabs.org/wiki/Main_Page would be ideal. Jdlrobson (talk) 02:11, 28 January 2020 (UTC)[reply]

I suppose the main question here is that Main Page and Mobile Main Page here differ - where is the layout being controlled for the mobile main page on enwiki? Due to legacy config, along with what I suspect is main page special casing, I don't think this is easily repeatable on another project instance unless someone can confirm that those elements are configured the same (goes back to where is this configuration at all?). — xaosflux ^Talk 02:22, 28 January 2020 (UTC)[reply]

User:Jdlrobson/Main_page_notable with Template:Main_Page_responsive/styles.css will give a responsive main page design while making the minimum possible changes to the page. The resulting wikitext+CSS combo consolidates the mobile and desktop designs seamlessly (without making any major changes to look and feel) and avoids all the special paging magic. When the special page casing is turned off the only thing to be aware of is that any element tagged with the class 'nomobile' will be stripped from the mobile site. What are the barriers to updating the Main page to use such a design? Jdlrobson (talk) 12:35, 28 January 2020 (UTC)[reply]

@Jdlrobson: that still appears to be using table markup, and isn't that supposed to be a no-no for getting out of legacy mode? — xaosflux ^Talk 12:40, 28 January 2020 (UTC)[reply]

Still uses table markup yes, but it's a responsive table which makes table elements display block and full width up to tablet-device resolutions. If you want to get out of legacy mode table's are perfectly fine provided they are accompanied by media queries like the ones in Template:Main_Page_responsive/styles.css. Opting out of legacy mode is as easy as dropping any mf- and mp- prefixed id attributes. My hope is this iteration is minimal enough that it can be accepted and then iterated on. By having a stylesheet it will be easy to move all inline styles (style attributes) there and then easily show redesigns with completely different stylesheets. I've checked this mark up with $wgMFSpecialCaseMainPage = true; and $wgMFSpecialCaseMainPage = false; and it works with either. Generally I advocate dropping table markup simply because it's easier to understand, but it's actually a little more nuanced than that :) Jdlrobson (talk) 12:50, 28 January 2020 (UTC)[reply]

@Jdlrobson: could you check out the gutters in the highlighted area of File:Jonwhitespacegutter.PNG. These sections are quite small, where editors carefully prune the words to fit as best as possible, your layout seems to have more whitespace to the left of the bullets then necessary. — xaosflux ^Talk 14:04, 28 January 2020 (UTC)[reply]

How about now? Jdlrobson (talk) 14:24, 28 January 2020 (UTC)[reply]

Better - saw some odd things when the window size is small, at a certain point some of the section header name background boxes (e.g. TFA) change styling, but some on the same page (e.g. DYK) do not. The feature picture section also is a bit odd at small screen sizes (note it is on the current design too) - in that it creates a sectioned horizontal scroll bar control, not sure if there is a better way to deal with that part? — xaosflux ^Talk 14:36, 28 January 2020 (UTC)[reply]

I'd need to do the same to the elements which have nomobile class to make this more complete but I dont want to invest time if the process for upgrading the main page in such a way is not going to be straightforward. Are you saying it is? Jdlrobson (talk) 22:24, 28 January 2020 (UTC)[reply]

I don't think we will have much trouble pushing forth a technical change that doesn't have much impact on the content layout. — xaosflux ^Talk 23:30, 28 January 2020 (UTC)[reply]

Cool! Let's do this then. I'll make another pass at it. Jdlrobson (talk) 23:52, 28 January 2020 (UTC)[reply]

Btw, Xaosflux pointed me here; Yair rand made the conversion some time ago and there was some random issue. See User_talk:Yair_rand#TemplateStyles_for_main_page and related links. --Izno (talk) 03:11, 29 January 2020 (UTC)[reply]

@Xaosflux: and @Izno: - I've made some adjustments. It really is as minimal risk as possible - it copies inline styles to the stylesheet and doesn't change the existing HTML structure. Reading through Yair Rand's attempt modern CSS turned out to be problematic. I'm using identical CSS to the current CSS (just wrapping it in media queries where necessary) and the additional rules I've added for mobile will work in IE6. The only thing I've used that is modern is media queries which will gracefully degrade. It's only a start, but it sounds like baby steps is the way to go with the English Wikipedia Main Page.

I recommend copying User:Jdlrobson/Main_page_notable to Main Page and Template:Main_Page_responsive/styles.css to a more suitable place. Can you help facilitate this? I'm not really sure what the procedure is for making the change. Jdlrobson (talk) 05:54, 29 January 2020 (UTC)[reply]

We already have the consensus to use TemplateStyles; I think the only worry that anyone has is someone being able to make a {{protected edit request}} or similar with a fix should someone report a bug (for reasonable values of Bug--I'm not sure anyone knows what those are these days since Edokter left us to our own devices tending the scripting and skinning and such). If you're reasonably confident you could be responsive to the related issue being posted on Talk:Main Page the day or two after the change, I would be willing to move it over, or I suspect Xaos would be willing to. We'd probably want to leave a talk page note there beforehand. --Izno (talk) 14:20, 29 January 2020 (UTC)[reply]

(And I mostly recommend that path rather than you implementing it directly to avoid the WMF-NIMBY effect. --Izno (talk) 14:22, 29 January 2020 (UTC))[reply]

Talk:Main_Page#Main_Page_January_2020_technical_update opened. — xaosflux ^Talk 14:50, 29 January 2020 (UTC)[reply]
As far what happens next normally - assuming nobody finds a problem that needs to be addressed after at least a week we can move this up, the complete change looks like it will need some phabricator work too (legacy mobile, special case mobile) - I'm still very lost on finding anyone who actually knows anything about this configuration (thus how this thread started!). — xaosflux ^Talk 15:25, 29 January 2020 (UTC)[reply]
@Jdlrobson: please take a look at Talk:Main_Page#PortalLinksBug. — xaosflux ^Talk 20:18, 29 January 2020 (UTC)[reply]

Date script

Hi Jon. I think this edit broke the script. The options no longer load in the tools menu when you edit an article. Please would you be able to fix or self-revert? Thanks. Lugnuts ^{Fire Walk with Me} 20:31, 25 January 2021 (UTC)[reply]

Terribly sorry about that. It should be fixed now. Please ping me again, if not. Jon (WMF) (talk) 20:36, 25 January 2021 (UTC)[reply]

Yep, that's done the trick - thanks for the speedy fix! Lugnuts ^{Fire Walk with Me} 20:39, 25 January 2021 (UTC)[reply]

thanks for maitenance on googletrans and mobile use

Thanks for the code fixup on mobile use.

I've never really coded for it, and I've never actually tried to use it on mobiles. I don't know how it is turned on. There's no SHIFT key on mobiles (that's easy to hit) so I didn't think it could be used there. Endo999 (talk) 17:42, 26 January 2021 (UTC)[reply]

There are no errors on my google console usage graph. Endo999 (talk) 17:43, 26 January 2021 (UTC)[reply]

The error occurs on the Wikimedia side so it won't show up in your google console graph. wgServer corresponds to the desktop domain. I think if you wanted to fix this you could insert the ".m" into wgServer string rather than returning early. Don't know enough about the gadget to advise on how it should work in mobile :) Jdlrobson (talk) 17:46, 26 January 2021 (UTC)[reply]

redwarnConfig.js edits

Hi Jon, FYI re this edit, these errors are caused by an editor erroneously loading the config script in their global/common/skin.js so you should check these instead of fixing a redwarnConfig.js if you see errors of these sort in future - as the file is automatically updated any changes you make will end up cleared when the file is regenerated. ✨ Ed talk! ✨ 19:30, 26 January 2021 (UTC)[reply]

@Ed6767: Got your message. I have removed it from my common.js. I'm not sure how I did that. I guess that explains why Redwarn has been so crazy lately. Words cannot express how sorry I am. I am so sorry for causing so much disruption. I feel horrible. Scorpions13256 (talk) 19:38, 26 January 2021 (UTC)[reply]

@Scorpions13256, no worries, these things happen :) ✨ Ed talk! ✨ 19:42, 26 January 2021 (UTC)[reply]

@User:Ed6767 Did you only just become aware of the problem, or have you been spending days trying to resolve the issue? Scorpions13256 (talk) 19:45, 26 January 2021 (UTC)[reply]

@Scorpions13256, didn't take long at all to diagnose the issue as rw is not defined means RedWarn hasn't loaded which then means the config ran before RedWarn was loaded which doesn't happen in RedWarn's code at all, so that pretty much immediately boiled it down to this issue - we already have automated systems that let us know of any issues/RedWarn script related issues to make sure we find and fix bugs ASAP ✨ Ed talk! ✨ 20:20, 26 January 2021 (UTC)[reply]

Thanks everyone! Please don't feel sorry. Really not a big deal and thanks for the better solution User:Ed6767. Jdlrobson (talk) 20:31, 26 January 2021 (UTC)[reply]

nomobile is my current annoyance today

Aside from the excitement these past few days with Javascript, today I am annoyed with nomobile.

Premise: I am trying to change the class output by Module:Sidebar from vertical-navbox to sidebar. (I don't like that it doesn't match the name of the module and also that it has 7 extra characters it doesn't need which add up when you start looking at the now-TemplateStyles version of the module.)

In trying to achieve said premise, knowing that MobileFrontend strips the content with vertical-navbox class out, I added the nomobile class so that MF could still happily strip the content out.

Little did I know that multiple skins are opinionated on the point even so. Minerva drops a !important on display: none-ing the class while even Timeless also has a display: none on it below 850px (Timeless's mobile number, like 720px in Minerva and elsewhere). I haven't looked into the other responsive versions of skins.

Some options since I clearly think leaving vertical-navbox in the template is a non-starter ;):

Bite the bullet and just use !important for Minerva and not-!important for Timeless and other skins to set display: table, knowing that mobile doesn't see it anyway.
Nix the !important in Minerva, especially given it's not (a) mobile-only skin now.
1. I still bite a small bullet here in TemplateStyles but it's not as big a bullet. :^)
Remove the CSS in the skins entirely and reserve the keyword specifically for MobileFrontend to strip content (see also recently-filed phab:T270849).
Add sidebar to the list of keywords for which MF murders content.
1. I know we're trying to un-murder that content but no-one is solving the related problems anytime soon from what I can see. (C.f. you're trying in one small part of the wikiverse.)

Any thoughts?

Secondarily, I observed that the TemplateStyles for this template still get dumped into the context on mobile. I am pretty sure you can't really do anything about that at all, but I thought it was an interesting observation. --Izno (talk) 23:49, 26 January 2021 (UTC)[reply]

Welcome to tech debt land, where I live most days haha! :) The important thing to note with nomobile is its behaviour is different on desktop and mobile domain. On mobile domain it will get stripped. On desktop domain it might get hidden with CSS, but that's non-standard.

Honestly, I would focus on the mobile domain problem. That's technical debt on the skins part and as the Minerva maintainer I'd love to remove the `nomobile` class in the Minerva skin eventually.

Now all that said I wouldn't rely on `nomobile` at all to be honest. It was a short term fix for a long term problem. If you are using TemplateStyles just add a media query and display: none anything that you don't want to show on mobile and avoid the class entirely. There's no need to rely on it. Sure this will increase the HTML payload of mobile, but leave that to us WMF staff - we can always add rules for DOM-heavy elements at a later date.

As for the name, perhaps consider forking the template and making the current template a transclusion.

Note the logic for stripping HTML is here: https://github.com/wikimedia/operations-mediawiki-config/blob/master/wmf-config/InitialiseSettings.php#L16992

<div class="nomobile">Text</div>

Becomes

<div class="myelement">Text</div>

<style>
.myelement { display: none; }
@media screen and ( min-width: 720px ) {
  .myelement { display: block; }
}

Is any of that helpful? Jon (WMF) (talk) 00:57, 27 January 2021 (UTC)[reply]

Some comments:

Yes, I understood the behavior was different. I wasn't sure about the display: none piece of it on desktop being a supported thing. Should that be removed from deployed skins? (Or at least, could the !important in Minerva be removed?)
Noted regarding nomobile's possible removal at some future date.
Right, the issue is that this meta-template is one of the templates that Someone Somewhere (you? a colleague? a long-departed colleague? :) already decided to hide on the mobile domain (it's .vertical-navbox on line 16997). I am trying to change the class name, not the template name, which is why I was looking at nomobile as a way to keep this off the mobile site. I have 0 issue with just letting this out into the wild on mobile if you have no issue (because I'm just not a fan of display: none-ing stuff), but I think you might have an issue, so that's why I'm on this page first. :)

--Izno (talk) 01:11, 27 January 2021 (UTC)[reply]

That config tends to be added to based on severe issues with display on apps and web. It's best to avoid any classes there. If it makes your life easier, and its feasible, we could add the nomobile class to all templates using vertical-navbox and remove the vertical-navbox entry in the configuration. At least then you'll only have one class to worry about.

My two cents if you have to display: none, the design is flawed to begin with. I've seen a few templates rendering different things for desktop and mobile and I don't recommend doing that, as at some point in the long term future we may want to render identical HTML for mobile and desktop users.

In terms of "letting this out into the wild on mobile" I suggest using your best judgement. If you think the end product is usable/readable on mobile and can commit to testing on mobile going forward, there doesn't seem any reason to hide it. On the other hand, if it's just a garbled mess that can't be read or fixed, then probably best to hide it via a CSS media query.

I think one of the biggest problems with navboxes on mobile is the links are so small they are impossible to touch on a touch screen and given there are so many links in them, it's very common for users to click them accidentally while scrolling with their fingers.

If unsure, you can always ping Alex Hollender (WMF) for some design input. Jon (WMF) (talk) 01:23, 27 January 2021 (UTC)[reply]

we could add the nomobile class to all templates That's basically what I've already done by adding nomobile (and ensuring vertical-navbox doesn't appear in the wild; I'm down to like 5 templates). I honestly don't care whether vertical-navbox continues to be one that WMF tracks. :)

My two cents if you have to display: none Yes, that's my general opinion as well. Generally, I haven't seen display: none in a whole lot of places.

usable/readable Yes, I think it generally is usable (I still have an adjustment to make for mobile because the 'default' whitespace behavior of <a> is nowrap in this context...). Useful/fixable though? Sidebars usually appear (or would in mobile land) above the fold and can be awfully long, so it's a lot of links and a lot of scrolling and maybe after some scrolling finally getting to the content of interest, which I know based on infobox research is not a Good Thing for mobile. (At least infoboxes are about the page topic so it wouldn't kill users to have those first even if they prefer otherwise, not a dozen dozen links to other possibly tangentially-related pages.) Indeed, never mind issues like link density (which can probably be improved for the use case with a media query pretty easily). I can tolerate it (on Timeless), but I'm not the Casual Reader of most-interest.

Let me ping Alex as suggested (AHollender (WMF)) and see what he thinks. --Izno (talk) 02:22, 27 January 2021 (UTC)[reply]

2 weeks and some crickets. Anyway, I've hacked around Minerva for the time being. For desktop at least. (Lots of !importants; Minerva base table styling is rather opinionated; I'll be able to fix some of that innately when I get around to making the boxes divs rather than tables. Some migration effort necessary for that though, along with the other 10,000 pages that need fixing to make TemplateStyles Everywhere a reality. See also MediaWiki talk:Common.css/to do.)

I have in mind to file a phab for the nomobile class in general and/or what skins should assume about what that class means possibly (my preferred interpretation is that the class be unused for anything but marking things to be hidden by MF; YMMV +- future roadmaps, and I know Isarra was opinionated about it [and noprint] the other day on Discord and previously on Phab).

I'm not entirely certain a future of "deliver everything the same as desktop" is the best idea after some more thought, unless you plan to do it with some other things. As an example, the infobox-post-first-para would also have to be folded into core or dropped entirely, the former I suspect you will have some editors up in arms, at least for desktop resolutions, and readers up in unvoiced arms for the latter. Then there's Related Articles at the bottom which currently don't display in some skins (Vector). --Izno (talk) 08:02, 14 February 2021 (UTC)[reply]

Note, the mobile site is a skin - Minerva - and it's perfectly acceptable for Minerva to differ in certain ways to Vector, so things like RelatedArticles are not a problem here. The infobox-post-first-para could be achieved via CSS and that's preferred to the expensive PHP HTML transformations we currently apply.

The thing to remember is that there are people using Vector on mobile phones and people using Minerva on desktop, so this is why I say that `nomobile` should be used as a last resort.

In terms of Timeless, that sounds like a bug in Timeless. The `nomobile` class was introduced (by myself and others) in MobileFrontend as a short term fix to solve the problem of templates that were not mobile-ready while Extension:TemplateStyles was developed. It means "this should not show at mobile resolutions under any circumstance" and any other interpretation is incorrect and a bug should be opened if it is being used to mean something else. I think in the case of the `vertical-navbox` we should remove that from the list of classes that are stripped and use the `nomobile` class where needed. If you tell me that the templates are mobile friendly, I am happy to do that. Jdlrobson (talk) 20:54, 16 February 2021 (UTC) (should have been postedwith my staff hat on: User:Jon (WMF))[reply]

User:Kephir/gadgets/rater

Hi, can you please check User talk:Kephir/gadgets/rater? Thanks. Nehme₁₄₉₉ (talk) 23:17, 1 February 2021 (UTC)[reply]

InstaView

I noticed you made a change here to MediaWiki:Monobook.js regarding InstaView. In case you are not aware, InstaView is a wikitext renderer, integrated into navigation popups, but also by a very old livepreview renderer. People who have errors like that likely haven't touched their scripts files since 2005. —TheDJ (talk • contribs) 21:55, 11 February 2021 (UTC)[reply]

Thanks for the context.. yeh I figured as much. I noticed the pattern

InstaView.conf =

but couldn't find exactly which of the many users (and their scripts) were still active. Given Monobook is logged only users putting it in MediaWiki:Monobook.js seemed like a small price to pay to get the spam out of the error logs. I'm thinking a little about whether it makes sense for user scripts to expire if not touched for several years but haven't thought about that in too much detail but this is definitely a point of interest with respect to that. Any thoughts about whether that would be controversial? Jon (WMF) (talk) 22:08, 11 February 2021 (UTC)[reply]

Trace for twinklefluff edit

Hey Jon, would it be possible to get some info regarding this edit to MediaWiki:Gadget-twinklefluff.js? The specific page or diff or something would be helpful, 'cause I was surprised to see an error. At least in my console and all testing, $('#mw-diff-ntitle2').find('.mw-userlink')[0] works fine and returns the span even for a revdel'd or os'd name. Thanks. ~ Amory (u • t • c) 19:17, 24 February 2021 (UTC)[reply]

Can get this to you tomorrow. I suspect this might relate to username on diff being surpressed or deleted. Jon (WMF) (talk) 19:47, 24 February 2021 (UTC)[reply]

Awesome, thanks! I do too, but I can't seem to trigger an issue on my end. Maybe a specific browser or skin, or interaction with some other tool? Appreciate it. ~ Amory (u • t • c) 19:55, 24 February 2021 (UTC)[reply]

A trace is included below and some test URIs: 1 2 3.

It might relate to an interaction with any of the following gadgets: ext.gadget.HotCat%2CImageAnnotator%2CProsesize%2CProveIt%2CReferenceTooltips%2CShortdesc-helper%2CShowJavascriptErrors%2CStickyTableHeaders%2CTwinkle%2CUTCLiveClock%2CXTools-ArticleInfo%2Ccharinsert%2Ccitations%2Cedittop%2Cextra-toolbar-buttons%2CformWizard%2Cgeonotice%2Cimagelinks%2ClibSettings%2Cmorebits%2Cpurgetab%2CrefToolbar%2Crevisionjumper%2Cscript-installer%2Csearch-new-tab%2Cselect2%2Cswitcher%2Cwatchlist-notice%2CwikEdDiff

hope this helps. Jon (WMF) (talk) 00:27, 26 February 2021 (UTC)[reply]

diff@URL1:589:84
twinklefluff/<@URL1:582:163
fire@URL2:170:209
add@URL2:170:710
twinklefluff@URL1:582:125
Twinkle.load/Twinkle.addInitCallback@URL1:126:166
Twinkle.load/<@URL1:126:231
Twinkle.load@URL1:126:198
mightThrow@URL2:173:149
resolve/</process<@URL2:173:808

URL1: https://en.wikipedia.org/w/load.php?lang=en&modules=ext.gadget.HotCat%2CImageAnnotator%2CProsesize%2CProveIt%2CReferenceTooltips%2CShortdesc-helper%2CShowJavascriptErrors%2CStickyTableHeaders%2CTwinkle%2CUTCLiveClock%2CXTools-ArticleInfo%2Ccharinsert%2Ccitations%2Cedittop%2Cextra-toolbar-buttons%2CformWizard%2Cgeonotice%2Cimagelinks%2ClibSettings%2Cmorebits%2Cpurgetab%2CrefToolbar%2Crevisionjumper%2Cscript-installer%2Csearch-new-tab%2Cselect2%2Cswitcher%2Cwatchlist-notice%2CwikEdDiff&skin=vector&version=tytgb
URL2: https://en.wikipedia.org/w/load.php?lang=en&modules=ext.RevisionSlider.Settings%2ClazyJs%7Cext.centralNotice.geoIP%7Cext.centralauth.ForeignApi%7Cext.centralauth.centralautologin.clearcookie%7Cext.cite.ux-enhancements%7Cext.cx.entrypoints.contributionsmenu%7Cext.cx.eventlogging.campaigns%7Cext.cx.interlanguagelink.init%7Cext.cx.widgets.callout%7Cext.echo.api%2Cinit%7Cext.eventLogging%2CnavigationTiming%2Cpopups%2Cthanks%2CwikimediaEvents%7Cext.thanks.corethank%7Cext.uls.common%2Ccompactlinks%2Cinterface%2Cpreferences%2Cwebfonts%7Cjquery%2Coojs%2Coojs-router%2Coojs-ui-core%2Coojs-ui-windows%2Csite%7Cjquery.client%2Cconfirmable%2Ccookie%2Ctablesorter%2CtextSelection%2Cui%7Cjquery.uls.data%7Cmediawiki.ForeignApi%2CString%2CTitle%2CUri%2Capi%2Cbase%2Ccldr%2Ccookie%2Cexperiments%2CjqueryMsg%2Clanguage%2Cstorage%2Ctoc%2Cuser%2Cutil%7Cmediawiki.ForeignApi.core%7Cmediawiki.editfont.styles%7Cmediawiki.language.months%7Cmediawiki.libs.pluralruleparser%7Cmediawiki.page.ready%7Cmediawiki.page.watch.ajax%7Cmediawiki.ui.button%2Cicon%7Cmmv.bootstrap%2Chead%7Cmmv.bootstrap.autostart%7Coojs-ui-windows.icons%7Coojs-ui.styles.icons-movement%7Cskins.vector.legacy.js%7Cuser.defaults&skin=vector&version=1uw62

Hmm okay, thanks! Been playing around for a while, still can't trigger an issue. Tried a few user scripts too, no dice. Will try to keep looking into it though, 'preciate it. Curious that none of those diffs had a revdel'd username? ~ Amory (u • t • c) 11:18, 26 February 2021 (UTC)[reply]

The plot thickens! I'm now seeing a new variant of this issue "mwUserLink[0]" on sample URIs 1 and 2 with the identical stack trace so apparently my fix didn't help, just made it easier to filter!

diff@URL1:589:120
twinklefluff/<@URL1:582:163
fire@URL2:171:209
add@URL2:171:710
twinklefluff@URL1:582:125
Twinkle.load/Twinkle.addInitCallback@URL1:126:166
Twinkle.load/<@URL1:126:231
Twinkle.load@URL1:126:198
mightThrow@URL2:174:149
resolve/</process<@URL2:174:808

I suspect a user script is tripping this up now. I just don't know what user script and how. Jon (WMF) (talk) 15:44, 26 February 2021 (UTC)[reply]

Okay thanks! I did notice that it wouldn't work — because it's a jQuery object, the $('#mw-diff-ntitle2').find('.mw-userlink'); will return true regardless; what needs to be tested is the length. I've got a PR to plug it up that should be fine, but if it's some userscript issue, I'm more inclined to deal with that and leave the issues for figuring it out; lmk if that's a problem for you and the infrastructure, though, I can push easy. ~ Amory (u • t • c) 18:40, 26 February 2021 (UTC)[reply]

Pushed the change, so hopefully these stop on your end. No earthly idea what the interaction is, I tried a number of scripts from recent editors or likely viewers of those pages, still no dice. ~ Amory (u • t • c) 19:13, 26 February 2021 (UTC)[reply]

Nomination for deletion of Template:Taxonbar/styles.css

Template:Taxonbar/styles.css has been nominated for deletion. You are invited to comment on the discussion at the entry on the Templates for discussion page. Q28 (talk) 01:36, 5 December 2021 (UTC)[reply]

Comments welcome

Hello Jon, any feedback you may have for Wikipedia:Village_pump_(proposals)#RfC:_Showing_Editnotices_to_mobile_editors would be welcome. Thank you, — xaosflux ^Talk 19:13, 6 July 2022 (UTC)[reply]

@Xaosflux: thanks for the ping! With my volunteer hat on it's great to see this RFC! I think RFCs are a really helpful way to tell WMF product where to refocus efforts. I think in the case of this bug, nobody ever said edit notices on mobile were a bad idea - it was just a case of nobody prioritizing adding them. Things like basic editing were deemed more important. I'll let my work colleagues comment on the RFC itself but I've left some concerns on the gadget talk page regarding the gadget code. Hope that's helpful!

I will note that I'd much rather see a non gadget solution to this problem as the problem with gadgets is they become critical parts of the software and maintainers often leave. If the gadget is enabled, I'll note that it is using various CSS selectors that are subject to change, so please follow tech news and be prepared for gadget maintenance over the next 6 months to keep up with technical refactorings that are planned in MobileFrontend in the latter part of this year ( https://phabricator.wikimedia.org/T281930) Jdlrobson (talk) 00:54, 8 July 2022 (UTC)[reply]

MW:Common.css on mobile

I noticed phab:T248416#9678769:

Wikimedia sites which have well maintained Common.css can consider switching Common.css on for mobile devices on their wiki providing they do due diligence to ensure that they are using Common.css responsibly (e.g. are managing it's size in a way that doesn't impact performance). Enabling MediaWiki:Minerva.css as render blocking is pushing us in this direction.

I didn't realize $wgMFCustomSiteModules was the only configuration that needs adjustment to get Common.css render blocking. I think en.wp is at the point it can turn this on (er, off, rather).

After whitespace/comment stripping via ResourceLoader, Common.css is 5.6kb and getting absolutely everything out of Common.css that should be in TemplateStyles only gets us down to 4.1kb, so at most there's only about 1.5kb to shave off there still. I think that means we're at the point we can be considered "responsible" :).

(I'd like to have infoboxes out of there, but I like the technical debt of then-Mobile.css/now-Minerva.css duplicating a bunch of styles a lot less, and missing some others as noted there and elsewhere. Infoboxes is only about 700B (removing would be 4.7kb in Common.css) that we end up needing in some way or another on most articles anyway. And probably the .infobox-? word gets gzipped nicely which is a chunk of that content.)

It probably needs some massaging at least for resolution-supporting work. I still have to do a diff between what then-Mobile.css/now-Minerva.css has been doing (was there some resolution at which Mobile.css was no longer functional?). Maybe color-supporting later, which I see you're futzing with in Minerva.css currently.

What would be the best way to coordinate that adjustment, both the actual bit flipping as well as checking around for how many things I can break both on and off wiki :)? That task doesn't seem like a task that would need the usual "community consensus demonstrated" requirement for most config adjustments, but knowing if there's anything I don't know about potentially breaking elsewhere seems prudent (thinking about stuff like the "CSS size went up warning I think you've got lying around"). Izno (talk) 07:08, 5 April 2024 (UTC)[reply]

I'm on a break starting now for a week, can you ping me again week of 15th? If you want to make progress while I'm out feel free to open up a task tagged web-team-backlog and site requests (maybe ping Jdrewniak for guidance?).

There's nothing technical blocking this, but I think for English at minimum we would likely want to run a few synthetic tests to check that this change doesn't impact first paint too much. We're still trying to work out what is our upper bound for Kb of CSS transferred on mobile should be.

It's also possible when we switchover to use https://en.m.wikipedia.org/w/load.php?modules=ext.wikimediamessages.styles that reducing the dependency on the 2.5kb of CSS in that module could somehow be combined with this change. 🐸 Jdlrobson (talk) 07:15, 5 April 2024 (UTC)[reply]

Yeah, I can bug you in a couple weeks. I'll work on the diff to start and what I think Common.css needs to look like post-loading in MobileFrontend contexts and get a task set up when you're back. Not sure I want to jump on the WM styles piece yet, I think it has some complexities that need to be handled separately and which require a lot more analysis of things that might need to change. Izno (talk) 07:22, 5 April 2024 (UTC)[reply]

Turns out Common.css doesn't need a ton of change to be loaded everywhere. The delta from the working page is something like this. Minerva will keep a line or two, totally ignoring the dark stuff you're been playing with there. I'll not have any time to shepherd this until mid-July though.

I did catch that MediaWiki:Print.css will also be included then, which is also sufficiently short to me (but I can entertain some shuffling of the styles in there to other places behind print media queries - it's probably not much of a win to move those things around).

I've also added the wikimediamessages styles to MediaWiki talk:Common.css/to do in various buckets, though there might be one missing. Izno (talk) 23:19, 20 June 2024 (UTC)[reply]

Regarding MediaWiki:Print.css, I would recommend moving these to gadgets or templates, as Minerva has a pretty opinionated print stylesheet already. Infoboxes and references in particular may conflict.

Is the .printfooter { clear: both; } rule there really needed? Not sure what that's for and if that still applies... might be for an older skin, in which case it could me moved to MediaWiki:Monobook.css or similar. Jon (WMF) (talk) 22:40, 25 June 2024 (UTC)[reply]

The including edit for printfooter. I can check further when I am unAFK.

I will also check to see if this is an issue with what Minerva's print sheet looks like.

Probably the mw collapsible print styles should migrate upstream, or perhaps upstream collapsing styles should be changed to @media screen from applying everywhere. I can also file a task for that. Izno (talk) 14:47, 1 July 2024 (UTC)[reply]

printfooter is included in every skin using skinTemplate and most skins have CSS for it. I'm pretty sure it's the box displayed at the bottom of the last printed page that says "Retrieved from URL"... Clear: both looks valid in that context since sometimes user content floats out of the bottom boxes. Well, there might be a clear fix for that these days in some of the skins since the skin rework pre-V22 work, but I don't think the extra CSS here would be a big deal globally to ensure stuff isn't poking out in print and because I don't think anything upstream guarantees a clear fix.

It kind of looks like some of that CSS could be centralized, and there appear to be some common styles upstream of the skins in core for this specific element. Minerva even has a TODO about them. IDK how many of the skins are using the common style sheets. Izno (talk) 09:04, 3 July 2024 (UTC)[reply]

collapsible

sounds good.

printfooter

.printfooter is included in every skin, yes, but we have a clear:both on `.mw-body-content::after` to clear any floats in the article that may not have been cleared. This is a bit of an edge case, so I'm not sure it warrants a global CSS rule - it would be better for the associated template to be updated to fix that e.g. if .templateClass:last-child::after { clear: both; }.

If we want to keep the rule, it should be added to the software here, not in Print.css and better documented.https://gerrit.wikimedia.org/g/mediawiki/core/+/2dce4d01ccaf57d238612d80c6846608b0c8040c/resources/src/mediawiki.skinning/interface-print.less#11 Jon (WMF) (talk) 17:54, 3 July 2024 (UTC)[reply]

The .mw-body-content rule looks like it applies only to @media screen according to both console and codesearch, which defeats the purpose of the printfooter rule :D. Ignoring a patch to fix that, it's also in each of the individual skins whereas this feels like something that should be centralized? It also looks like interface-print.less is used in no skins according to codesearch. So adding it there is a fix a bit beyond leaving it in local print.css, but I can file a task. Izno (talk) 18:24, 12 July 2024 (UTC)[reply]

The print styles here are part of interface-core which should be loaded on all skins by default - it is loaded by skins using ResourceLoaderSkinModule with interface or interface-core feature. It is marked as "Required interface core styles. Disabling these is not recommended." Jon (WMF) (talk) 16:54, 15 July 2024 (UTC)[reply]

Ah, ok, I see it. Thanks! Izno (talk) 23:53, 15 July 2024 (UTC)[reply]

phab:T370194 for printfooter and phab:T369972 for mw-collapsible. Izno (talk) 18:47, 16 July 2024 (UTC)[reply]

Poking some more at this today, phab:T367463 had some changes that got merged but one of the comments in the block that did was Note this currently doesn't apply ... to responsive images in MobileFrontend. Is there a task for that? I've got some CSS that I'm trying to ditch in Minerva.css that would be able to come out for that reason (flagicons being prevented from shrinking to nothing). Izno (talk) 20:59, 6 September 2024 (UTC)[reply]

That would be phab:T368469. If you want to open a new task, explicitly for removing your Minerva.css rule that would be helpful and likely more easily solved! Thanks for the update! Jon (WMF) (talk) 23:08, 6 September 2024 (UTC)[reply]

Nope, that task is good, I'll go add that to relevant notes. Izno (talk) 23:19, 6 September 2024 (UTC)[reply]

Ok, think I'm down to oneish thing before we can roll ball on changing software config + whatever else you want to do, that maybe if I pray hard enough can be adjusted upstream.

.mw-tag-markers is the container that holds tags that display in change streams next to the revision (Watchlist, Contribs, and etc.). Right now in Minerva we have at least one rule that setting a parent of .mw-tag-markers to 0.85em (and it honestly kind of looked like there were multiple parents setting a font size of 0.85em??). From what I can see of the other skins, nothing else is changing the size of the list items presented in these change streams.

Why I am here: Common.css sets the size of that element to 90% (we think it's less important too). On most skins that ends up with some more or less reasonable absolute size, but doing it on Minerva gets it down to 12.2px, which I think can be agreed is very small. I'm faced with the options of 1) changing Common.css not to target skin-minerva, 2) removing it from Common.css and sprinkling it in the skin pages, or 3) getting Minerva changed (I guess there is [4] which is change all the other skins, or even [5] adding CSS in core). I'd like option 3, but I'd suck it up if that requires some terribly extensive work upstream. (It's probably producing too small text on Monobook today, so option 2 probably isn't The Worst.) Izno (talk) 05:22, 7 September 2024 (UTC)[reply]

Can you open a Phabricator ticket for this? I think I'd need to consult other people about what to do with mw-tag-markers. I'm all for upstreaming to core where we can and it makes sense.

Once it's created ping me and I'll bring the right people to the conversation.

Thanks in advance! Jon (WMF) (talk) 00:29, 10 September 2024 (UTC)[reply]

phab:T374475. Izno (talk) 16:58, 10 September 2024 (UTC)[reply]

I've opted for option 2 above locally pending some action on the task. (I don't think these obviate that task.) This was the series of edits (though I took on the voluntary burden of two of those). Turns out that block isn't great for Minerva for the italics either, which I think look silly with the circle border thing Minerva does, so that's why Minerva gets nothing :).

Which means I'm more or less out of things to do to prep locally. I've filed phab:T375538 for enwiki and actually also phab:T375540 for MediaWiki wiki since there was some discussion about that one too. Meta probably isn't far behind but I haven't done enough work over there to verify things. Izno (talk) 17:08, 24 September 2024 (UTC)[reply]

Barnstar

		The Special Barnstar
		Thank you very much for helping me to fix the problem in US municipality lists!!! I will change the dislaying of other lists very soon. --SickManWP (talk) 15:58, 6 July 2024 (UTC)[reply]

No problem! Glad to help! Jon (WMF) (talk) 20:31, 8 July 2024 (UTC)[reply]

Can you unlink the category in the message box module?

Hi Jon, your recent change (Special:Diff/1235525107) included a category link without the leading colon, so now the page is listed at the category. Could you format it with the leading colon to remove it from appearing on the category page, like:

[[:Category:Pending_AfC_submissions]]

Many thanks, microbiologyMarcus ^{[petri dish·growths]} 19:50, 19 July 2024 (UTC)[reply]

Done Jon (WMF) (talk) 19:51, 19 July 2024 (UTC)[reply]

Appreciate it! Will say, as someone who does not edit modules at all, that would not have been my expected behaviour for the category link to still work in the comment despite still showing inline in the page. All the best, microbiologyMarcus ^{[petri dish·growths]} 20:04, 19 July 2024 (UTC)[reply]

Please close div tags

On August 2, 2024, you or your bot edited about 11 Template Talk pages inserting a section titled "Urgent: Please fix this template for printed content Template:Wikipedia's sister projects/styles.css." The section began with <div lang="en" dir="ltr">, and didn't end with a closing </div> tag. I inserted the closing </div> tags. Please avoid unclosed tags. Cheers! —Anomalocaris (talk) 07:28, 18 August 2024 (UTC)[reply]