Last modified: 2014-11-01 08:15:17 UTC
== Background == Many tables generated by wikitext are bigger than 320px. On a 320px screen, this causes the entire viewport to grow to the size of the table and can break the experience of the entire site. This stretches the search bar and makes the mobile site very unusable. == Current solution (hack) == Currently the mobile site deals with this situation by forcing the table to have width 100% and adding overflow scrolling (which is enabled by making the table a block element). This solution is not perfect as overflow-x is not fully supported across all mobile devices. To see an example of the sort of table this rule targets the table on the presidental election results page [2] provides a good example. Side note: We may also want to make it possible for templates in the short term to opt out of the styling hack e.g. using a nohacks class == Long term solution == Ideally it should be possible for templates to define their own behaviour for tables on mobile devices. There are various responsive tables [1] techniques but there is no one fit for all solution. Note some tables [2] do not even scale well on even desktop devices. It should be possible for template editors to use media queries to style tables differently with the closure of the templating RFC [3] so that we can kill this table hack. Other solutions are welcomed. == Further information/history == See bug 64516 and 36936 [1] http://css-tricks.com/responsive-data-tables/ [2] https://en.m.wikipedia.org/wiki/List_of_United_States_presidential_election_results_by_state#section_1 [3] https://www.mediawiki.org/wiki/Requests_for_comment/Allow_styling_in_templates
Note: The existing hack makes use of !important as this is the only way to override an inline style. See also bug 64578
*** Bug 36936 has been marked as a duplicate of this bug. ***
(In reply to Jon from comment #1) > Note: The existing hack makes use of !important as this is the only way to > override an inline style. See also bug 64578 You start an arms race by making me declare my inline style !important too. And you have no chance of winning.
I can see from your description that the problem is that the flowing text on a page containing a table becomes too wide. Maybe it would be better to limit the text width and to leave the table alone? TEXT TEXT TEXT |A|VERY|WIDE|TABLE| TEXT TEXT
Created attachment 15261 [details] When zoomed out
Created attachment 15262 [details] when zoomed in without the !important hack
Which text would you limit? I've added the above two attachments which demonstrate the effect of dropping these rules. We could maybe considering use max-width instead.. ?
Yes, I thought about max-width, except that I do not want to get stung by folks who insist on supporting ancient browsers. I also understand that the scroll bars are not shown because they appear only while the page is beging scrolled. In your case I would limit the width of the header and of every single table cell (independently).
Luckily I don't care too much for ancient browsers - especially in this case as it doesn't effect readability. Luckily in mobile these are not such an issue - most mobile devices support max-width I'm not quite sure how we'd limit each table cell independently - this would require JavaScript no? Keen to understand if I'm missing anything here...
I would limit the width of every leaf block. That is currently not expressible in CSS unless you classify each such block explicitly, which can be done by the HTML renderer. I was tempted to assume that a table cell width could be limited that way, except that it is theoretically possible to have a table within a table cell. (You cannot use 100% for that since it would refer to the row width, which would be self-contradictory; moreover, the row width should be allowed to be wider than the screen width, in which case the reader could use the scrolling facility provided by the document window to read the content; you should rather use the actual width of the display). The situation with tables in wikitext is alleviated by the fact that wikitext does not allow table cells to contain block elements, so ilimiting the width of a table cell would work for pages that do not use raw HTML to circumvent this limitation. Note that all this stuff is best handled by the accasibility component of the browser, whether built-in or external intermediary; if the browser fails to implement such a rule and allows running text to be wider than the display, it is the browser's fault and not ours. But I understand that it is desirable to provide a workaround for browsers that are not so well-behaved. I am sorry if my writing is unclear; this problem surely requires many aspects to be considered.
*** Bug 65856 has been marked as a duplicate of this bug. ***
Prioritization and scheduling of this bug is tracked on Trello card https://trello.com/c/UDFKccPa
