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.