In T90687#3064995, @Jhernandez wrote:

I agree with @bd808 about using a well known grid. Bootstrap's is very widely used and would be fine, something like a flexbox grid http://flexboxgrid.com/ would be awesome.

Seems like a good discussion for the Front-end-Standards-Group as @Volker_E said.

At the time the proposal was created, Bootstrap was very different. Now it incorporates many of the principles proposed. The only differences seem to be that Bootstrap assumes a 12-column grid by default, and uses different names (of the breakpoints and the size specifications). So I think it could be a good candidate to support the grid ideas.

In terms of responsiveness it seems that Bootstrap supports adjusting grid columns and visibility of elements, but it would be useful to have ways to adjust any CSS aspect (such as font size) as illustrated in the experimental implementation of the proposal. This can be considered related to the grid discussion, or considered separately.

In T90687#3065816, @Volker_E wrote:

As first step, we should gather and clearly define needs, on the RFC discussion page there hasn't been a lot of inputs, if so, the last one dates back to June 2014. I don't know if there were any other findings or documentation… @Pginer-WMF?

In the proposal I capture the main needs I identified:

• Optional because we cannot change the whole UI at once.
• Nestable because we want to use the grid in components that will appear inside pages or other components based on the same grid system.
• Responsive because we want to make the best use of the available space in a world with a big diversity of devices.
• Semantic because we don't want to clutter the HTML and be heavily affected by changes in the grid system internals in the future.
• I also included proportional because I found that "one-half" the available space was easier to understand that col-6 (which requires you to know it means 6/12), But I'm ok to live without this one since I'm not the one going to implement software using this, I just want the designs to be easy to transfer accurately into the final solutions.

@Volker_E The backing CSS of the abstraction we choose to expose should be an implementation detail, in my opinion.

@Pginer-WMF The proposal is great, and I very much agree with those points.

From what I see, the implementation is not mobile-first, which is something I think is very important (some reasons in How To Write Mobile-first CSS).

Would it be worth modifying that behavior so that the targets apply upwards? (using only min-width on the media queries) That is how mobile-first grids work, like bootstrap or skeleton for example.

@Tgr Does TemplateStyles allow developers to use LESS in the templates or only CSS? Asking because if it is only CSS we would need to expose classes instead of using the semantic approach and only exposing mixins.

TemplateStyles does not allow use of LESS right now (just like we have on MediaWiki.css not MediaWiki.less) and I don't think we should go down that route as part of this... that would increase the scope quite dramatically. I also worry about adoption as many wiki editors are not necessarily programmers and learning LESS might be a little bit of a stretch for some (remember many of these editors don't know Git and don't want to learn Git hence why the develop gadgets).

I'd suggest we focus on a class based approach.
+1 to using a well known grid.

In relation to T158149: Find an owner for top 10 Developer Wishlist 2017 proposals, I dare to ask: what is the current status? :)

@Qgil There's no clear consensus on

• where such grid (helpers) should live (MW core probably, but then again where and as what),
• what technology to build on top as there has been massive standard support improvement additions in providing more powerful (Flexible Box Layout) or simpler (CSS Grid Layout) solutions in this area
• and last but not least, who's to implement & maintain it given the multitude of necessities to care about and test against

On this behalf I'm removing OOUI as it's not the place for grid support to live in from current project scope.

I played a bit with bootstrap's grid layout and templatestyles: https://www.mediawiki.org/wiki/User:TheDJ/bootstrap

The UI system of ContentTranslation Vue dashboard implemented a grid based on flexbox. It has been very helpful for layout. See Storybook .

That looks promising, @santhosh. One thing that seems important here, were examples given how it behaves in Internet Explorer 9 (and 8 if T248061 doesn't get accepted). I assume that you're building on autoprefixer for IE 10 support?!

Spacing units are multiples of 4 units. So pa-2 means padding: 8px. The values can be between 1 to 12. pt-12 means padding-top: 48px

It think by providing too many numerical options, you may end up with restricted version of inline styles.

Where possible a framework should be limited to identified use cases to promote consistent design.

In T90687#6170217, @Esanders wrote:

Spacing units are multiples of 4 units. So pa-2 means padding: 8px. The values can be between 1 to 12. pt-12 means padding-top: 48px

It think by providing too many numerical options, you may end up with restricted version of inline styles.

Sorry, I did not understand this comment. What do you mean by 'restricted version of inline styles"?

@Pginer-WMF @Volker_E - I cannot find a baseline grid (4px or otherwise) formally documented anywhere (on the Design Style Guide, OOUI, etc). I was going to create a new task for this, but does it make sense instead for this task to be updated to incorporate the need to define and document a baseline grid as well?

In T90687#7246210, @RHo wrote:

@Pginer-WMF @Volker_E - I cannot find a baseline grid (4px or otherwise) formally documented anywhere (on the Design Style Guide, OOUI, etc). I was going to create a new task for this, but does it make sense instead for this task to be updated to incorporate the need to define and document a baseline grid as well?

Sounds good to me. These spacing aspects seem quite relevant to the topic of the ticket.

Thanks for the update @RHo – that was the reason to have linked this task to the epic questions task, I've had both, the grid and spacing as indivisible parts in mind.
The 4px multiplier spacing was visible in Sketch WikimediaUI Components Overview.

Formal question: Are we doing ourselves more of a favor with 4px, 8px or even 16px equivalent as base spacing? Even in the components collection there are sometimes 2px overrides, but the majority is 8 and 16.

In T90687#7246854, @Volker_E wrote:

Thanks for the update @RHo – that was the reason to have linked this task to the epic questions task, I've had both, the grid and spacing as indivisible parts in mind.
The 4px multiplier spacing was visible in Sketch WikimediaUI Components Overview.

Right I see. It seems warranted to make it much more 'official' and better documented on the Design Style Guide, something like the following:

• https://material.io/design/layout/spacing-methods.html#baseline-grid
• https://www.lightningdesignsystem.com/utilities/grid/
• https://ant.design/components/grid/

Formal question: Are we doing ourselves more of a favor with 4px, 8px or even 16px equivalent as base spacing? Even in the components collection there are sometimes 2px overrides, but the majority is 8 and 16.

IMO as 4px as the smallest unit gives wiggle room, and then moving forward we should ensure components and space adheres to the smallest unit, and no longer have overrides moving forward.

In T90687#7247152, @RHo wrote:

Formal question: Are we doing ourselves more of a favor with 4px, 8px or even 16px equivalent as base spacing? Even in the components collection there are sometimes 2px overrides, but the majority is 8 and 16.

IMO as 4px as the smallest unit gives wiggle room, and then moving forward we should ensure components and space adheres to the smallest unit, and no longer have overrides moving forward.

Not sure I follow the take “follow the smallest unit” here. We have had overrides of 2px, even 3px and 1px in certain interface challenges like in Desktop Improvements in past months. And I think 4px or 2px are also fine contextually to be used and will continuosly needed to be used. The formal question is:

• “8px equivalent is our base spacing unit, there are cases where you could half (4px) or even a quarter (2px) contextually.“ My recommendation looking through our interface components. Or
• “16px equivalent is our base spacing unit, there are cases where you could half (8px) or even a quarter (4px) or an eighth (2px) contextually.“ This would have the advantage that we're also aligning to a technical pre-conception, having 1em equivalent to 1 spacing unit. Keep in mind, that ems might loose importance in the mid-future due to approaches like T262928 Or
• “4px equivalent is our base spacing unit, there are cases where you could multipliers (8px) or a half (2px) contextually.“ Least recommended, simple sentence, but not used widely enough in components, 8px and 16px are much more often used.

In T90687#7253220, @Volker_E wrote:

In T90687#7247152, @RHo wrote:

Formal question: Are we doing ourselves more of a favor with 4px, 8px or even 16px equivalent as base spacing? Even in the components collection there are sometimes 2px overrides, but the majority is 8 and 16.

IMO as 4px as the smallest unit gives wiggle room, and then moving forward we should ensure components and space adheres to the smallest unit, and no longer have overrides moving forward.

Not sure I follow the take “follow the smallest unit” here. We have had overrides of 2px, even 3px and 1px in certain interface challenges like in Desktop Improvements in past months. And I think 4px or 2px are also fine contextually to be used and will continuosly needed to be used. The formal question is:

• “8px equivalent is our base spacing unit, there are cases where you could half (4px) or even a quarter (2px) contextually.“ My recommendation looking through our interface components. Or
• “16px equivalent is our base spacing unit, there are cases where you could half (8px) or even a quarter (4px) or an eighth (2px) contextually.“ This would have the advantage that we're also aligning to a technical pre-conception, having 1em equivalent to 1 spacing unit. Keep in mind, that ems might loose importance in the mid-future due to approaches like T262928 Or
• “4px equivalent is our base spacing unit, there are cases where you could multipliers (8px) or a half (2px) contextually.“ Least recommended, simple sentence, but not used widely enough in components, 8px and 16px are much more often used.

Right. What I mean is that we should have 4px as the smallest base spacing that is allowed, which would convert to 0.25em equivalent if ems continue to be used.
I am interested in understanding what the cases are for overrides of 1px, 2px, or 3px to be allowed and in what context. I am talking about not having smaller than 4px in the Design Styleguide for spacing and layout.

In T90687#7253301, @RHo wrote:

In T90687#7253220, @Volker_E wrote:

In T90687#7247152, @RHo wrote:

Formal question: Are we doing ourselves more of a favor with 4px, 8px or even 16px equivalent as base spacing? Even in the components collection there are sometimes 2px overrides, but the majority is 8 and 16.

IMO as 4px as the smallest unit gives wiggle room, and then moving forward we should ensure components and space adheres to the smallest unit, and no longer have overrides moving forward.

Not sure I follow the take “follow the smallest unit” here. We have had overrides of 2px, even 3px and 1px in certain interface challenges like in Desktop Improvements in past months. And I think 4px or 2px are also fine contextually to be used and will continuosly needed to be used. The formal question is:

• “8px equivalent is our base spacing unit, there are cases where you could half (4px) or even a quarter (2px) contextually.“ My recommendation looking through our interface components. Or
• “16px equivalent is our base spacing unit, there are cases where you could half (8px) or even a quarter (4px) or an eighth (2px) contextually.“ This would have the advantage that we're also aligning to a technical pre-conception, having 1em equivalent to 1 spacing unit. Keep in mind, that ems might loose importance in the mid-future due to approaches like T262928 Or
• “4px equivalent is our base spacing unit, there are cases where you could multipliers (8px) or a half (2px) contextually.“ Least recommended, simple sentence, but not used widely enough in components, 8px and 16px are much more often used.

Right. What I mean is that we should have 4px as the smallest base spacing that is allowed, which would convert to 0.25em equivalent if ems continue to be used.
I am interested in understanding what the cases are for overrides of 1px, 2px, or 3px to be allowed and in what context. I am talking about not having smaller than 4px in the Design Styleguide for spacing and layout.

4px sounds good to me.

Examples:

• Desktop Improvements was the last project where I encounter a few of them. Would 6px be an acceptable value? From a strict formal point I lean towards no. 5px definitely not. Logo margin features one.
• WVUI TypeaheadSearch Suggestion title features margin-bottom: 2px

In T90687#5592907, @TheDJ wrote:

I played a bit with bootstrap's grid layout and templatestyles: https://www.mediawiki.org/wiki/User:TheDJ/bootstrap

Whoa. That's cute! Just for fun I've adapted your work here for itwiki:

https://it.wikipedia.org/wiki/Template:Bootstrap

Since this does not seem to create conflicts, maybe the itwiki local community can try it and start killing some layouts made with tables and see if we have further feedback to share here.

BTW the ability to create columns with just a generic class like ".col-md" without saying "col-md-6" etc. is a killer feature and it's definitely one of the things I would recommend having in the MediaWiki core. The .col-md feature is more simple to discuss, before agreeing on the number of columns.