Hi,
Just a reminder that this is the translators-l mailing list, which is probably not the ideal place to talk about this.
I would look at https://phabricator.wikimedia.org/T33597 for context, and Sherry will likely know where your comments can be better placed.
thanks! Joe
-- *Joe Sutherland* Community Advocate Wikimedia Foundation joesutherland.rocks
On 12 July 2017 at 17:04, Philippe Verdy verdy_p@wanadoo.fr wrote:
This is absolutely not CSS "hack", but standard CSS feature.
Only broken by some bad CSS inserted by default in MediaWiki (notably for all bulleted/numbered/definition lists, both in the wiki or HTML syntax, with their top/bottom margins that can't work nicely in multicolumn containers where these margins should be moved)... but that could be solved when we'll have the possibility to attach stylesheets to wiki pages instead of in each element to fix what default MediaWiki stylesheets forces everywhere.
Another thing that Mediawiki still does not accept (even though they are completely harmless) are columns groups in tables (OK: there's no wikisyntax for them in wikitables, but I don't see why colgroup elements, or even thead/tbody's/tfoot elements are forbidden, even if they are also needed for accessibility of tables: this requires hacking tables with lot of CSS)
And this is not a minority of wikis that use such technic (even if they don't have necessarily a very simple template to do that easily for references): there are lot of pages using that.
Multicolumnn rendering is often far better than using tables with a static number of columns (that won't fit very well, on narrow smartphone screens or on large screens where lot of horizontal space is left unused). Multicolumn output could also be used for galleries, without necessarily using the REAL CSS+Javascript hack defined with mode="hover*".
More generally we lack some basic features in Mediawiki to handle dynamic/flexible layout patterns that will work across all display sizes. There are now great layout frameworks used on modern websites (so these sites are usable on all screens, and will still remain "accessible" with various text sizes, zoom levels, or display resolutions between low-dpi displays like TVs and high-dpi displays like smartphones).
So this proposal is in fact very minor: this was not really needed, the needs are clearly elsewhere. This is a solution for a problem that actually does not exist: when there's no problem, it's better not to fix it. This proposal is then a non-solution...
I'll better welcome the addition of stylesheets per page, possibly also per templates (not generated multiple times at each inclusion, but just referenced only once on pages that will use transclude them): this was recently announced and will solve lot of problems and will help simplifying lot of templates, and avoiding many errors and simplifying the edition of articles or tables.
2017-07-13 0:07 GMT+02:00 Whatamidoing (WMF)/Sherry Snyder < ssnyder@wikimedia.org>:
The fact that a minority of wikis have implemented CSS hacks to do this is exactly why this message needs to reach everyone. Communities can either remove the old CSS (recommended), or ask to be taken off the list for default-on (acceptable).
Translators-l mailing list Translators-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/translators-l