Talk:Requests for comment/Grid system

My experiences
I (and the language engineering team) used the Foundation grid for building TUX (the new translation interface of Translate extension) as well as Universal Language Selector extension before that.

Having a grid simplifies and speeds up development work, at least when designs specifying the columns are available. And it was easy to start using it in existing extension.

We also run into some the problems mentioned in the proposal:
 * white-space sensitivity
 * cases where there was too little space for ui elements on smaller screen sizes.

This just means that using a grid doesn't solve everything automatically, you actually need to spend effort to test that the UI scales up and down properly and make it adapt. If some of these problems are solved in newer grid designs, even better.

Currently it is difficult to share grids. Currently Translate loads the grid from ULS extension, which is not pretty. Having a grid system in core would solve this dependency issue. It would also avoid the situation where many extensions are loading different, maybe even incompatible grid implementations.

--Nikerabbit (talk) 07:31, 3 September 2013 (UTC)


 * "If some of these problems are solved in newer grid designs, even better", in particular I think the proposal should help with the following:


 * Use of a common grid so those extensions that want to use a grid do not have to re-invent the wheel.
 * Responsive by default, making it easier to target multiple devices from the start.
 * Easier to override. One issue we commonly found is that we need to add some extra padding to elements that have the grid classes, leading to CSS rule precedence issues. the use of a system based on Less can also solve this, since you have more control extending classes. Pginer (talk) 14:51, 24 December 2013 (UTC)

Minimum sizes vs proportions?
Hmm, I'm not convinced by a proportional grid system; I generally care more about minimum sizes to fit the contents of some UI element.

I've found that proportional measurements are hugely problematic for responsive design, because a proportion that makes sense on a large desktop screen is complete nonsense on a small phone screen. For instance bug 53944 is caused by the interaction between 'width: 90%' and a horizontal margin conflicting on a small screen. If only the margin were used, it would have "just worked" on mobile.

Minimum sizes in  (most appropriate for text-oriented stuff) or   (most appropriate for stuff bounded by an image or other fixed-size item) can be specified in CSS.

In many cases you can combine proportional 'preference' with minimum/maximum sizes, so this might alleviate some cases though. --brion (talk) 23:36, 10 September 2013 (UTC)


 * "a proportion that makes sense on a large desktop screen is complete nonsense on a small phone screen" -- yes, this is right. Based on Pau's presentation about this at Tech Days though, I don't think he's suggesting defining proportions means you define the same proportions on all devices. What might be 1/3 on a laptop or tablet might need to be hidden entirely or increased/decreased depending on its priority, and for any grid to work you'd still need to define specific rules for a given interface about how it responds to changes in overall screen real estate. Correct? Steven Walling (WMF) &bull; talk   06:36, 12 September 2013 (UTC)


 * As Steven mentioned, the point is to be able to indicate which is the ideal percentage to occupy for each grid column for each screen size. If it makes sense that element X occupies half of the space on mobile and just a quarter on desktop you just need to indicate so: "palm-one-half desk-one-quarter". I found that Bootstrap 3 follows a similar approach but forcing you to use a 12 column system. In Bootstrap, "col-md-6" means 6 columns (out of 12) in a medium-sized device. In the proposal, it would be "lap-one-half" instead, but in both cases that would translate to "width:50%". The use of percentages in the CSS implementation is just used to make the layout flexible *between breakpoints* making the layout changes more gradual. In any case, I would leave implementation decisions to developers. I'm more interested on the concepts (i.e., LESS/CSS classes) that allow to describe how a layout can be adapted to different screen sizes than the specific CSS code inside them.  Pginer (talk) 12:37, 24 December 2013 (UTC)

Discussion at Architecture Summit, & RFC meeting this week
Per the discussion from the January 2014 architecture summit, Pau & Trevor now own this, and we hope to get some working on-wiki demos by about April 2014. Would it be possible for us to discuss this and see your current progress in this week's RFC review? Thanks! Sharihareswara (WMF) (talk) 05:49, 26 February 2014 (UTC)
 * From the 27 February meeting, next steps for Pau:
 * ACTION: pginer to finish writing the RFC so we can mark it accepted
 * ACTION: pginer to add detail on intended use cases / prefixing to RFC & perhaps narrow "implementations" section  if possible, name the actual classes and mixins which you intend to create
 * Sharihareswara (WMF) (talk) 23:26, 10 March 2014 (UTC)
 * Pau is working on this project on Fridays, along with other UX Explore projects. Sumana Harihareswara, Engineering Community Manager (talk) 13:16, 4 April 2014 (UTC)

Flexbox module
Has anyone considered using the CSS3 Flexbox model? I am already (ab)uisng some aspects of it in my [//en.wikipedia.org/wiki/User:Edokter/Main_Page?withCSS=MediaWiki:User:Edokter/Main_Page.css Main page experiment]. Unlike the CSS3 Grid layout module, the flexbox module is already supported by all major browsers. — Edokter  ( talk ) — 11:28, 11 April 2014 (UTC)