Currently we trigger search on any element that matches #searchInput, #searchIcon

What if we generalised this?
https://github.com/wikimedia/mediawiki-skins-MinervaNeue/blob/master/resources/skins.minerva.scripts/search.js

Change 418007 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/skins/MinervaNeue@master] Generalise search trigger mechanism

https://gerrit.wikimedia.org/r/418007

^ I've put that on the beta cluster. any element with class skin-minerva-search-trigger when clicked will trigger the search now. Does that solve your problem?

The corresponding CSS is at reading-web-staging.wmflabs.org/wiki/User:Nzr123/common.css

Just a word of warning.. any css in mobile provided by editors is loaded via JS. Does Hindi have template styles? If not that problem goes away, otherways you'll need to inline them :/

Just a word of warning.. any css in mobile provided by editors is loaded via JS. Does Hindi have template styles? If not that problem goes away, otherways you'll need to inline them :/

inline all of it? what about the wrapper classes that are not actually part of the main_page code?

^ I've put that on the beta cluster. any element with class skin-minerva-search-trigger when clicked will trigger the search now. Does that solve your problem?

that will work nicely!

Hi! Quick timing update - seems like this is the most visible. Our analysts have requested that these change go live at least a few days before or after the video campaign launches so that we can isolate the impact of the change. Do you have a sense for when your piece will be done?

I spent 30 mins with JR. we have figured out 80% of the things. the only thing remains now is the flash of unstyled content.
we are trying to target

hindi subdomain, only main page, only mobile, only minerva, NOT desktop

This requires some hacky methods of applying styles that result in flash of content being styled. there isn't a really good way to get rid of it (apart from templatestyles, that are not deployed on hindi)

so it's kinda up to us now. we need to discuss the trade offs of FOUC vs the value we get out of this project.

FOUC whenever a user opens the page: https://www.youtube.com/watch?v=G6kRtkA9BOk

next step:

• Nirzar, Anne, Olga: discuss the trade offs of FOUC
• Nirzar: create steps that admin on hindi wikipedia can follow to make these changes
• Olga test cases, assign a QA card? some minor QA would do
• Satdeep: send the steps to the admin on hindi
• Anne, Olga, nirzar: test it

@ovasileva @Nirzar I'll be OOO Wed-Fri. I don't see a time that we could discuss tradeoffs in a call before I'm out. I imagine we want to make a decision on this ASAP.

My thoughts, quickly...

Will it be a slower flash on slower connections? While India has had a huge increase in speed and availability of data, we should still assume that many people will be on slower connections with cheaper devices.

This is a pretty big flash IMO. I'm concerned that the goodwill we're building with community might take a hit with a rough solution and, since we're having a community member implement it, the risk here is higher that it'll cause problems and be reverted.

That said, the content doesn't seem to move at all with the change (which has been an issue with fundraising banners' FOUC), so the disturbance to readers should be relatively small. For an MVP it's probably OK, and I know this is interrupt work, so I understand if the decision is to go forward with this as-is.

If it helps with the decision at all, we are planning to try other similar things in the coming fiscal year (that we can plan/resource more deliberately). We could revisit this one at that time, assuming that it's of high enough quality that we can definitely understand if it works at helping people navigate.

btw - will clicks to that search be logged at all?

Change 418007 merged by jenkins-bot:
[mediawiki/skins/MinervaNeue@master] Generalise search trigger mechanism

https://gerrit.wikimedia.org/r/418007

In T189316#4044909, @atgo wrote:

@ovasileva @Nirzar I'll be OOO Wed-Fri. I don't see a time that we could discuss tradeoffs in a call before I'm out. I imagine we want to make a decision on this ASAP.

My thoughts, quickly...

Will it be a slower flash on slower connections? While India has had a huge increase in speed and availability of data, we should still assume that many people will be on slower connections with cheaper devices.

Yes. It will be speed dependent. It could kick in up to 2+ seconds later. Chrome has support for tethering so I'm happy to show you this on a simulated 2G connection if that helps (not sure if we can do that via the WiFi in the office any more..)

This is a pretty big flash IMO. I'm concerned that the goodwill we're building with community might take a hit with a rough solution and, since we're having a community member implement it, the risk here is higher that it'll cause problems and be reverted.

I think that's a fair assessment.
As I've explained to Nirzar the one definite way we can avoid this issue is by deploying TemplateStyles to Hindi Wikipedia. We'd have to check with @Deskana if that is feasible.

That said, the content doesn't seem to move at all with the change (which has been an issue with fundraising banners' FOUC), so the disturbance to readers should be relatively small. For an MVP it's probably OK, and I know this is interrupt work, so I understand if the decision is to go forward with this as-is.

That's likely a side effect of caching/fast connections
The content does move but on faster connections it's barely noticeable - we're talking about 100ms-ish.

btw - will clicks to that search be logged at all?

Searches will be logged via Schema:MobileWebSearch, but right now it won't be clear they came from this particular search box. You could however look at searches from the Main page and get a sense of increase/decrease if that's what you are interested in (but obviously wouldn't be able to say for sure this was because of this particular change)

Thanks for this, @Jdlrobson

After checking with @satdeep_gill and @ovasileva, we can't deploy this as-is. Satdeep is available to help support community consultation, and he and Olga are coordinating to figure out what the plan is to move this forward.

@atgo just to clarify the video shows 3 flashes. they are triggered by reloads which are not captured in the screen there.

Thanks @Nirzar, that's what I'd guessed.

Hey again - in a meeting discovered this blocker to deploying TemplateStyles elsewhere: T189528

Are there other options?

The real blocker is that TemplateStyles does not currently work with Tidy and hiwiki has not been converted to Remex yet.

It mostly works with Tidy. You just need to avoid putting the <templatestyles> tag in the middle of a paragraph (including in templates designed to be used inline).

@Jdlrobson and @Nirzar, do you have an updated link for the styles, and what are the potential options for embedding styles inline or in render blocking stylesheets on a per wiki basis as a shorter term measure between now and the more seamless TemplateStyles option?

If I'm guessing correctly, it seems that there's an implicit preference to avoid potential maintenance burden with, for example, introduction of a per-wiki config variable to allow style embedding in the MobileFrontend /Minerva Neue ResourceLoader implementation akin to Common.css (e.g., make it possible for Mobile.css to be part of the <link rel="stylesheet">) or a literal additional stylesheet file in mediawiki-config for just hiwiki.

It would make a lot of sense IMO to load MediaWiki:Mobile.css as a render-blocking style everywhere, because MediaWiki:Common.css is already loaded this way.

The only thing blocking that right now is that Mobile.js and Mobile.css are combined into one module (mobile.site) , and render-blocking CSS is only allowed for style-only modules. In core, we split site into two modules for that reason (site for the JS and site.styles for the CSS). IMO we should do the same thing here.

@Krinkle: thoughts?

@Krinkle said yes, so I'm writing a patch for this now.

I created T190083: Make MediaWiki:Mobile.css render-blocking as a subtask of this task (strangely there's no Catrope added a subtask entry here), wrote a patch to make MediaWiki:Mobile.css render-blocking, and attached it to that task. If it gets merged in the next ~20 hours, it'll be on hiwiki on Thursday (and if not, we can expedite it if needed).

@Catrope the problem with this is this will load significant styles on all wiki pages - and we only want to load them on the main page. As far as I know there is not a MediaWiki:Mainpage.css ?

If you are not too concerned about performance impact you can just scope the mainpage styles to .page-मुखपृष्ठ.

If you are not too concerned about performance impact

The performance impact is what I'm concerned about :)

In that case, you could just use Mainpage.css and declare it as a new RL module from CommonSettings.php. (Assuming this is a one-off that's only needed for the dureation of the campaign. Otherwise, that functionality would probably make sense as an extension.)

In T189316#4047948, @Tgr wrote:

The real blocker is that TemplateStyles does not currently work with Tidy and hiwiki has not been converted to Remex yet.

@ssastry has been working through the blocking issues to convert hiwiki to Remex, so this may be a possible option.

In T189316#4062865, @atgo wrote:

In T189316#4047948, @Tgr wrote:

The real blocker is that TemplateStyles does not currently work with Tidy and hiwiki has not been converted to Remex yet.

@ssastry has been working through the blocking issues to convert hiwiki to Remex, so this may be a possible option.

I've been fixing some templates. I paused for now unless this is a path you guys want to take. Otherwise, hiwiki will get Remex within the next 2-4 weeks once I edit a few more templates and push hiwiki over the hump to get ns0 linter counts to be < 100 for all the high-priority linter categories.

I sat down with @Nirzar today. We've landed on the simplest possible solution which doesn't require any ResourceLoader or TemplateStyles changes. I've still got a few more bits to work out but this is the task (T190101).

Long term we definitely want to lean on TemplateStyles for this sort of thing.

Thanks all for the helpful advice and updates! I think this has gone a long way to show the power that TemplateStyles will give us!

Thanks @Jdlrobson!