Last modified: 2014-02-12 23:55:04 UTC
As reported at <https://www.mediawiki.org/wiki/Thread:Extension_talk:MobileFrontend/Common.css_ignored%3F>, the MobileFrontend extension apparently load MediaWiki:Common.css. MediaWiki:Common.css is the styling that should apply to the entire site. Looking at the page source of <https://en.m.wikipedia.org/> seems to confirm that MediaWiki:Common.css is currently completely ignored.
This is by design. Giving projects the ability to define their own custom CSS specifically for mobile devices would be a better solution as described in bug 22659 Potentially we could imagine the custom css redirecting to Common.css where that is really the desired behaviour. *** This bug has been marked as a duplicate of bug 22659 ***
Un-duping. There should be no need to duplicate stylesheets for mobile. Mobile should just not surpress the default load queue like this. At least it should include in it's in queue crucial things like MediaWiki:Common.css and MediaWiki:<skin>.css because many modern templates will use css classes instead of inline styles and they look broken with out it.
Common.css is mostly >content< styling specific to a particular mediawiki installation, so should be applied to content, be it mobile or not. NEXT to that, we also need mobile specific styling of course, but I see no reason to close this as dupe.
Created attachment 10369 [details] First stab at getting common.css and ResourceLoader into MobileFrontend The currently problem I'm hitting is that the skin is also served up by ResourceLoader which I do not want as skins are not currently mobile aware and introduce a lot of breakage. As I understand it the only way to remove the skin from the outputted css (at the moment) is via doing a horrible str_replace to remove skin.vector - I guess this will not work if another skin is being used? Can someone take a look at my diff and suggest a better way of removing the skin from the output? Even better could ResourceLoader be updated so that skins can be turned off?
Addressed in https://gerrit.wikimedia.org/r/#change,4226 awaiting review
Merged https://gerrit.wikimedia.org/r/4226
Common.css no longer seems to be being applied :(
https://gerrit.wikimedia.org/r/14419
*** Bug 38833 has been marked as a duplicate of this bug. ***
Reopened as this is yet to be merged and seems to be still under discussion
*** Bug 40297 has been marked as a duplicate of this bug. ***
MediaWiki:Mobile.css has been added to provide a way to target css to mobile - this is now merged into the current dev version. Since the original question was "In our installation it seems to completely ignore the content of Mediawiki:Commons.css. Is there a setting for this? An alternative CSS page?" which has now been answered I'm going to mark this as resolved. I think enabling MediaWiki:Common.css in future is a separate discussion that should be discussed outside bugzilla - either on mailing lists or wiki pages till we have more consensus. I've not tested this but I'm assuming MediaWiki:Mobile.css could transclude MediaWiki:Common.css if this behavior was really really wanted.
(In reply to comment #12) > MediaWiki:Mobile.css has been added to provide a way to target css to mobile - > this is now merged into the current dev version. Right, but that's outside the scope of this bug. MediaWiki:Mobile.js and MediaWiki:Mobile.css are related to bug 22659 ("Give projects the opportunity to add mobile specific JS/CSS"). > Since the original question was "In our installation it seems to completely > ignore the content of Mediawiki:Commons.css. Is there a setting for this? An > alternative CSS page?" which has now been answered I'm going to mark this as > resolved. > > I think enabling MediaWiki:Common.css in future is a separate discussion that > should be discussed outside bugzilla - either on mailing lists or wiki pages > till we have more consensus. This bug tracks the "MediaWiki:Common.css loading on mobile" issue ("MobileFrontend extension doesn't load MediaWiki:Common.css"). As far as I can tell, this bug has not been resolved fixed (i.e., the MobileFrontend extension continues to not load MediaWiki:Common.css, as it should; cf. comment 2 and comment 3). If you can safely say that this bug will never, ever be fixed (i.e., MobileFrontend will never, ever load MediaWiki:Common.css [and MediaWiki:Common.js, I suppose]), this bug can be marked resolved wontfix. Otherwise, it should stay open. > I've not tested this but I'm assuming MediaWiki:Mobile.css could transclude > MediaWiki:Common.css if this behavior was really really wanted. Transclusions on CSS and JS pages don't really work as one might expect.
The original problem that was being raised as I read it was "I cannot target styles on to the mobile site". Going deeper I read this to mean 'there is something I styled on desktop that simply must be on mobile'. This is not the same as meaning 'everything style on desktop should be on mobile'. Currently MediaWiki:Common.css is not maintained with mobile in mind - most of the time it is fixing problems on desktop. In fact numerous of the css rules in MediaWiki:Common.css have been targeted in the MobileFrontend core to be optimised for mobile. There are also various rules that exist in MediaWiki:Common.css such as '.treeview ul' that don't appear on every page - so these are not in fact what I'd call 'common'. These add unnecessary bloat to mobile where every byte matters. The fact that MediaWiki:Common.css is how styles get to the desktop site is irrelevant. As far as I can see MediaWiki:Mobile.css allows people that are concerned about these things to target css to mobile users to address mobile specific problems. There is a real opportunity here to include MediaWiki:Mobile.css on desktop and move styles applicable to both desktop and mobile to MediaWiki:Mobile.css - I think this is a much better approach and I think would get closer to what is needed. FWIW a server admin who really really wants MediaWiki:Common.css in mobile can do so by adding the following line to their config: $wgMobileSiteResourceLoaderModule['MediaWiki:Common.css'] = array( 'type' => 'style' ); Personally my opinion is this should be marked as WONTFIX but I'm marking it with the more optimistic LATER. This is not a bug. It's currently by design.
[Closing as "WONTFIX" to get rid of the deprecated "LATER" resolution.]