I chatted to @alexhollender on Monday about supporting different official viewports. Right now we only officially support in Minerva are 320p and, 720px The more we support the more complicated/complex it is to keep that support level high and I'm not sure we can scale to this kind of work without switching to a true fluid layout.

When discusssing this we felt it might be helpful to collect some data around what browser resolutions people are viewing Minerva in before doing any work in this area.

I've started talking with @Tbayer about what it would take to collect screen size data for readers. Until we have more specific data I thought it might make sense to look at general statistics. These two sites report on "screen resolution" — I'm not sure if that's quite the same thing as the size of your browser window?

https://www.rapidtables.com/web/dev/screen-resolution-statistics.html
http://gs.statcounter.com/screen-resolution-stats

If we think it's a decent proxy, it seems like we should probably consider introducing a third breakpoint around 1200px. There could even be an argument that we stop caring about 720px.

@alexhollender tbh those general stats may be enough. The statistics only become useful when thinking about who is using the mobile site, how they make use of their screen (maybe on a 1000px they are not full screening their windows and should we be caring more about 720px upwards. If so though we've got bigger problems - such as the editor overlay appearing full screen.

I should note this particular bug is about 1000px. The design looks like nice on 1024px which features in the table with 3.9% usage.

@Jdlrobson right, good point. Given that I don't think this is high priority.

I guess another way we could think about this is having a 2-3 main breakpoints, but still doing things that help the display of the page in between those breakpoints. E.g. in this case it seems like if we set a percentage-based width for the main container (90%), and introduced a pixel based max-width we'd avoid this problem.

@Jdlrobson @Niedzielski what if we changed the max-width here to 90% instead of 993.3px? As far as I can tell that would ensure there is always some margin.

@alexhollender, I don't think we want to do that since 10% gives too wide a page on large screens. Why not define the margins wanted instead per breakpoint?

Why not define the margins wanted instead per breakpoint?

The content needs to be centered so a margin: auto will be needed somewhere, if not here on a parent container.

The fundamental issue here is that the breakpoint is 1000px, and the content area does not have a width of 993.3px available. The easiest solutions here would be dropping that value of that max-width or increasing the breakpoint at which it comes into play (a little trickier as impacts other things.

we could also define a width + a max-width, let's say

max-width: 993.3px;
width: 90%;
margin-left: auto;
margin-right: auto;

That way the content will be never be bigger than 993.3px, and on smaller screens it'll be 90% width.

Nice @Jdrewniak — just tried that out on a large screen and it seems like it does exactly what we want.

Can I move this out of design land?

@ovasileva for clarification this is ready to be worked on, no more design needed

make it so.

https://codein.withgoogle.com/tasks/5849034129408000/

Change 469836 had a related patch set uploaded (by Goomel; owner: Goomel):
[mediawiki/skins/MinervaNeue@master] Bug: T193061

https://gerrit.wikimedia.org/r/469836

Change 469836 had a related patch set uploaded (by Jdlrobson; owner: Goomel):
[mediawiki/skins/MinervaNeue@master] Ensure there are page margins for 1000px viewports

https://gerrit.wikimedia.org/r/469836

Change 469836 merged by jenkins-bot:
[mediawiki/skins/MinervaNeue@master] Ensure there are page margins for 1000px viewports

https://gerrit.wikimedia.org/r/469836

@nray points out there is a problem with the implementation - it's taking up the full screen on desktop.

Change 470886 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/skins/MinervaNeue@master] Article width should not be full screen

https://gerrit.wikimedia.org/r/470886

Change 470887 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/skins/MinervaNeue@wmf/1.33.0-wmf.2] Article width should not be full screen

https://gerrit.wikimedia.org/r/470887

@alexhollender am requesting an urgent sign off by 2pm PST (2.5hrs from now) on http://reading-web-staging.wmflabs.org so I can SWAT this at 4pm PST.

LGTM. Checked at various browser widths.

Change 470886 merged by jenkins-bot:
[mediawiki/skins/MinervaNeue@master] Article width should not be full screen

https://gerrit.wikimedia.org/r/470886

Change 470887 merged by jenkins-bot:
[mediawiki/skins/MinervaNeue@wmf/1.33.0-wmf.2] Article width should not be full screen

https://gerrit.wikimedia.org/r/470887

Mentioned in SAL (#wikimedia-operations) [2018-10-31T23:34:26Z] <tgr@deploy1001> Synchronized php-1.33.0-wmf.2/skins/MinervaNeue/resources/skins.minerva.tablet.styles/common.less: SWAT: [[gerrit:470887|MinervaNeue: Article width should not be full screen (T193061)]] (duration: 00m 53s)

Mentioned in SAL (#wikimedia-operations) [2018-10-31T23:36:30Z] <tgr@deploy1001> Synchronized php-1.33.0-wmf.2/skins/MinervaNeue/skin.json: SWAT: [[gerrit:470887|MinervaNeue: Article width should not be full screen (T193061)]] (invalidate RL cache) (duration: 00m 53s)

Looks good to me on staging and production{F27086759}