Page MenuHomePhabricator

Hat-note FOUC on mobile skin
Closed, DuplicatePublic

Description

For example, on https://en.m.wikipedia.org/wiki/Word . The hatnote is first rendered with a left margin that is flush with the rest of the body text, but then it is indented:

word.gif (452×684 px, 43 KB)

Related Objects

StatusSubtypeAssignedTask
DeclinedNone
DuplicateNone
ResolvedTgr
ResolvedAnomie
Resolvedtstarling
Resolvedcoren
ResolvedAnomie
DeclinedBUG REPORTNone
ResolvedAnomie
ResolvedEsanders
ResolvedEsanders
Resolved ssastry
ResolvedAnomie
ResolvedCKoerner_WMF
Resolvedjhsoby
ResolvedTgr
DeclinedTgr
Resolvedcoren
ResolvedAnomie
ResolvedTgr
DeclinedNone
Resolved ssastry
ResolvedTgr
ResolvedTgr
ResolvedTgr
Resolved Deskana
ResolvedCKoerner_WMF
Resolved Whatamidoing-WMF
ResolvedTgr
ResolvedTgr
ResolvedTgr
ResolvedUrbanecm
ResolvedTgr
ResolvedTacsipacsi
ResolvedTgr
ResolvedCKoerner_WMF

Event Timeline

There's no reason for this to be inside MediaWiki:Mobile.css and MediaWiki:Common.css

I would suggest moving the margin and padding rules to the template module itself - https://en.m.wikipedia.org/wiki/Special:MobileDiff/711777560

I temporarily disabled the css rule for the time being given it is highly noticeable. I will cleanup once we've fixed it in the template.

Yes, lets move all CSS inline to the templates... I think not. Why shouldn't the loading of Mobile.css be fixed instead?

dr0ptp4kt triaged this task as Medium priority.Mar 28 2016, 5:14 PM

Top loading the styles in Mobile.CSS will introduce another HTTP request and lead to a hit on first paint and overall page view performance so we should explore this carefully.

In the current implementation, as used by Vector, the CSS is broken out into a separate HTTP request for caching reasons. We should re-evaluate this as Vector would also benefit from having these CSS shipped in a single request.

Looking through the existing rules in MediaWiki:Mobile.css none of them with the exception of the hatnote rule need to be top loaded.

Hopefully, we'll have some bandwidth soon to investigate this. The RFC will alleviate most of these problems.

It doesn't seem reasonable to block this on T483. T483 may be a blocker an ideal solution, but this problem is sufficiently annoying to merit a nonideal solution, if that is the best we can do.

dr0ptp4kt raised the priority of this task from Medium to High.Aug 10 2016, 2:38 PM

Just checking, are the Community-Relations-Support expected to be actively involved in the resolution of this task?