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 em (most appropriate for text-oriented stuff) or px (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) • 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 <TimStarling> 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)

I added implementation details to the RfC, an example web and submitted a patchset. -- Pginer (talk) 14:57, 11 April 2014 (UTC)

In the patchset, Steven Walling notes: "Pau and I talked about this with Juliusz, about how to move this forward. We're going to try and write a WIP test patch which utilizes the grid, as an example." Sharihareswara (WMF) (talk) 23:53, 4 May 2014 (UTC)

We had another meeting and people are now reviewing the patchset. Sharihareswara (WMF) (talk) 15:06, 6 June 2014 (UTC)

Flexbox module

Has anyone considered using the CSS3 Flexbox model? I am already (ab)uisng some aspects of it in my 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)

Flexbox model is great. I love how it solves typical layout issues. Browser support becomes a big issue here. If layout-related aspects (as opposed to round borders or shadow related properties) break it could result on a totally broken UI. The current proposal relies on the more commonly used float approach, but since the high level concepts (.mw-ui-one-third) are separated from the implementation it will be really easy to change the implementation to use the flexbox model instead.--Pginer (talk) 14:48, 11 April 2014 (UTC)

You can actually use both to create a fallback mechanism; flexbox disables floats. So asmuming grids are not overly complex, these two can actually work well together. — Edokter (talk) — 16:29, 15 April 2014 (UTC)

Be sure that you only use the revised (-ms-flexbox) and new (-webkit-flex, flex) flexbox models if you do fallback that way. The older (-webkit-box and perhaps -moz-box) don't play as nicely with floats, sometimes -webkit-box + float causes something to disappear completely. Daniel Friesen (Dantman) (talk) 01:34, 16 April 2014 (UTC)

Agora grid

I really like the agora css grid, the only problem i have with it, is that it's responsive solution, while elegant, is basically pointless to a wikicode editor atm: "It's based on LESS to keep the HTML free from grid classes", so to make use of this in wiki content, would require either templatestyles with less support, or to define a bootstrap like grid class syntax on top of agora. —TheDJ (Not WMF) (talk • contribs) 09:41, 2 March 2017 (UTC)