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 <[email protected]> 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 < > [email protected]>: > >> 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 > [email protected] > https://lists.wikimedia.org/mailman/listinfo/translators-l > >
_______________________________________________ Translators-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/translators-l
