Last modified: 2014-05-01 00:38:05 UTC
The Mobile Frontend declares tables to span the whole width of the page. I suppose you have a good reason for this; however, this effect is divvicult to revert because you set display to block and make the width !important; Please do not do that; a simple { width: 100% } should be enough if you really insist.
Prioritization and scheduling of this bug is tracked on Mingle card https://wikimedia.mingle.thoughtworks.com/projects/mobile/cards/1974
The reason is many wikimedia wiki's set inline styles with maximum table widths. This allows horizontal scrolling. There is a tracking bug for issues with table on Wikimedia wiki's in general. Are you wanting to remove this for a 3rd party?
See table bug 36936 for all the history with this. It could be disabled on certain wikis but most wikis need it.
(In reply to Jon from comment #2) > Are you wanting to remove this for a 3rd party? No, I specifically want to remove !important for Wikipedia. Please visit the referenced talk page; another editor provided a much better explanation of how awful this is.
Yes. Tables are a mess in general, this has been a longstanding known issue. What is needed is the ability to style using stylesheets and media queries. Sadly 100% !important is the only workaround that can be used currently. There is an open RFC https://www.mediawiki.org/wiki/Requests_for_comment/Allow_styling_in_templates Until this gets closed and it is possible for CSS rules to be written in templates this rule will need to remain. I would suggest in the meantime it might be useful to get an admin to add a helper css class that helps tables override this on mobile devices in MediaWiki:Mobile.css. You can also achieve the same result by wrapping it in a fixed width div - but bear in mind anything with width over 320px will look terrible on the majority of mobile devices, so fixed widths are generally not a good idea unless you are doing something with media queries. *** This bug has been marked as a duplicate of bug 36936 ***
The only workaround for what? I reverted your duplication assignment because the other bug is not a bug. I do not know what it is.
(In reply to Jon from comment #5) > I would suggest in the meantime it might be useful to get an admin to add a > helper css class that helps tables override this on mobile devices in > MediaWiki:Mobile.css. You can also achieve the same result by wrapping it in > a fixed width div - but bear in mind anything with width over 320px will > look terrible on the majority of mobile devices, so fixed widths are > generally not a good idea unless you are doing something with media queries. I cannot achieve the same result by wrapping the table in a DIV of fixed width because I do not know the width of the table in advance.
(In reply to Jon from comment #5) > I would suggest in the meantime it might be useful to get an admin to add a > helper css class that helps tables override this on mobile devices in > MediaWiki:Mobile.css. Request filed following your advice at <URL: https://meta.m.wikimedia.org/wiki/General_requests >.
See also https://meta.wikimedia.org/wiki/Help_talk:Table#Table_width_in_Mobile_View
In general the "!important" specifier in **all** global CSS stylesheets (notably non specific ones like here that just target very generic elements outside any context) is an extremely bad idea: Everything it is supposed to solve for a few users will break many others or on some other browser platform or device. It also fails all accessibility rules, when users need to setup their own overrides for their specific needs independantly of what other users will see on pages. So even if things may seem broken without them in some configurations, the best is to avoid them completely. Instead, use better mechanisms for detecting specific devices and sending them tweaked styles (but even in this case, avoid "!important" styles, this is clearly not necessary and a better way is to manage correctly how styles are inherited in the cascading stylesheets (by appropriately hiding those that may take the priority). In summary, delete all these "!important" style specifiers completely. And solve the problems by looking at other solutions. This remark also applies to all gadgets and MediaWiki extensions that should not override the default styles this way (instead they should better manage the order of loading for their stylesheets and also better manage the selectivity of the specified CSS selectors). "!important" on sitewide stylesheets is only for lazy programmers that don't want to invest time to do this research work. (And notably here where it targets ALL mobile platforms used now by a very significant part of our users worldwide, with a fast growing rate which could overwhelm all other users on traditional PCs; note that many tablet users are already targeted by the mobile version, even if they could use the standard web version on their screens with a diagonal larger than about 5 inches ; now, many "desktop" PCs are in fact tablets or convertible to mobile tablets, and use mobile OSes like Android or iOS; even desktop OSes are implementing now a mobile view by default on their interface and reserve the desktop view for specific tasks). Ideally, though, MediaWiki should offer a way for the various parsers, extensions and gadget to get a full view of the stylesheets that will be injected in the page, using some hooks that allow them to inspect the cascades of styles, before modifying them and returning a modified tree that MediaWiki will then send to the user when serving the final HTML pages. Or there should be a Javascript framework allowing an extension or gadget to send additional javascript that will modify the loaded stylesheets using the DOM, if they need it. But in all cases these solutions will also not inject any "!important" modifier to styles. Leave these specifiers only to final users in their own personal customizations (in their own Wikimedia skins stored in their user pages, or using external tools and addins to their browsers, for example accessibility tools) : the simplicity of "important" specifiers for building their own stylesheets will be left to these users (even if they can also avoid them, provided MediaWiki does not leave any "!important" more specific overrides that break what their CSS selectors will match).
Hi Philippe, with no disrespect, I don't think you truly understand the scale of the problem here and you make many assumptions. Let me try to elaborate. Inline styles cannot be easily overridden without resorting to !important. The !important style specifier is the only way to override them. This is why the rule is specified in a file called hacks.less: http://git.wikimedia.org/blob/mediawiki%2Fextensions%2FMobileFrontend/8d9184c2d4af6e460ccea44be32b88db6565afc7/less%2Fcommon%2Fhacks.less (it's in a file called hacks.less as it _is_ a hack and we know this. Your comment about "lazy programmers" doesn't endear me to you :-) - especially given research has been ongoing in the form of an RFC to research this that I added above. As stated above the real problem here is you cannot target different styles at both mobile and desktop browsers. https://www.mediawiki.org/wiki/Requests_for_comment/Allow_styling_in_templates Please help me get the above RFC resolved so we can remove these hacks - which trust me we want to. Without these hacks various other templates look terrible on mobile. I am going to create a new bug which tries to detail all of these issues. I agree the old bug was messy but by the same evaluation this is equally messy and does not show the full story. I will comment on this bug with the new bug number. In terms of tablets - the hack rule doesn't apply to them. We've been working on tablet styling which should be pushed to all users very soon. This restricts this hack to mobile browsers with a screen less than 320px.
Bug 64577
A bug should be declared INVALID when it is irrelevant, bogus, unintelligible, if it gets the facts wrong. What is your reason for invalidating this one? I disagree with your statement «by the same evaluation this is equally messy». A bug does not need to «show the full story» to be valid.
Having more than one bug around tables that can't be fixed mutually exclusively won't get this bug fixed any quicker, if anything it will add to confusion. I think it's important to collect all the issues in one ticket so the solution thinks about all of the sides of the problem.
