Page MenuHomePhabricator

Limit content width, and refine alignment & styling of relevant elements
Closed, ResolvedPublic8 Estimated Story Points

Description

Background

As a part of our sidebar work, we would like to restrict the content width of the content in order to create a better reading experience by improving readability. This change requires several additional pieces of work: creating a width-container for the entire page, positioning the various containers appropriately, styling the sidebar background, adding a sidebar animation, styling of the footer, and handling certain special pages (which won't be getting the fixed-width).

More details on motivation and rationale are available in this section of our project documentation.

Design details

Latest prototype: https://di-collapsible-sidebar-5.firebaseapp.com/Hathor
Proposed patch: 589774 | demo (login: "Guest" pass: "guestguest") | history

Wide screen (1780px)

sidebar closedsidebar opensidebar open on special page

Narrow screen (1280px)

sidebar closedsidebar opensidebar open on special page
Sidebar animation

In order to avoid weird content reflow issues:
If there is enough room for the sidebar to open without the article content having to move, the sidebar will have an animation. This should be at or above 1420px (the magic number at which the sidebar can open without the content having to move).
If there is not enough room, the sidebar will not have an animation.

Sidebar background

The sidebar background changes based on the width of the page.
Below 1500px: background: linear-gradient(to bottom, #fff 0%, #f8f9fa 3%, #f8f9fa 97%, #fff 100%);
At or above 1500px: white background w/ left border that mimics the gradient above
(I wasn't able to figure out how to get the gradient border to work the way I wanted so for the prototype I ended up putting a gradient background on the parent element, and then making the parent element 1px wider than the sidebar container.)

Container width & breakpoints

There are three containers. All three containers usually remain horizontally centered within the browser window. The case where they don't is when the browser is less than 1500px wide and the sidebar is open, in which case the content container gets offset to the right.

  • Page container
    • this is the outer-most container, ensuring that on extra wide screens the header contents don't drift too far from the content. The only thing that lives at this level is the site header.
    • max-width: 1650px, padding: 0 30px
  • Workspace container
    • this is in place to ensure that the sidebar doesn't drift too far from the content on wide screens. It also acts as a container for Special page contents that are not limited to the content container
    • max-width: 1440px, padding: 0
  • Content container
    • this is the inner-most container, which contains the article toolbar and article contents
    • max-width: 960px, padding 0

We've discussed whether or not below a certain screen width the sidebar should slide over the content (like how the mobile menu does). At this point I think we can hold off on that functionality. The website will be usable, with the sidebar open, until the screen width gets below ~700px, at which point a horizontal scrollbar will appear.

Page footer

Page footer should be within the workspace container (red dotted line in screenshot below)

Some pages will not get a max-width

The contents container of certain pages will not have a max-width. Context: the purpose of the max-width is to make articles easier to read. Some of the non-article page types benefit from this constraint, e.g. Talk pages and User pages. While others, functioning more as dashboards/logs/tables, do not benefit from this constraint. In particular we've identified that pages using the "ChangeList" component are negatively affected by this constraint. Therefore to begin with the following pages will not have a max-width:

  • All special pages
  • History pages

The resulting variability in the contents container size is both an inconsistency, and a capability of sorts. In the future we should think more about whether we want to try and converge on one page size that works for all page types, or further formalize the different options.

Here is an extreme example of how this will look:

Sidebar closed

normal pagespecial pagegif

Sidebar open

normal pagespecial pagegif

Acceptance criteria

  • Limit width as per spec above
  • Special pages will NOT have fixed width
  • This should be feature flagged if possible
  • We will not be responsible for any issues with templates or content as a part of this task - we will collect a list of issues (if any) and work with communities to get them fixed on wiki

Open questions

  • How do we approach this? How do we set widths and breaking points
  • Do we want to have separate behavior for tablets/small screens?

QA Steps

Browser list: Chrome 83, 81, Firefox 77, 76, Safari 13, IE 11, Opera 68, Edge 83

For article pages:

  1. Visit https://en.wikipedia.beta.wmflabs.org/wiki/Main_Page when anon.
  2. Make sure your screen is > 1750px and ensure there is grey surrounding the white part of the page. Click the sidebar button to make it appear.
  3. Click the sidebar button and ensure the sidebar disappears and the content does not move. Click the sidebar button again to make it reappear. Again, ensure the content does not move.
  4. Resize your browser's window width to 1499px and ensure the sidebar turns grey
  5. Resize your browser's window to 1050px and click the sidebar button to make it disappear. Ensure the content's width expands to fill most of the screen (there should still be 30px of padding on each side of the content though). Click the sidebar button again to make it reappear.

For history pages:

  1. Visit https://en.wikipedia.beta.wmflabs.org/w/index.php?title=Main_Page&action=history when anon.
  2. Make sure your screen is > 1750px and ensure there is grey surrounding the white part of the page. Also ensure that the content of the page is wider than it was for the article page. Click the sidebar button to make it appear.
  3. Click the sidebar button and ensure the sidebar disappears. The content should expand to fill more of the page, but the tabs shouldn't move at all. Click the sidebar button again to make it reappear. Ensure the content shrinks to make room for the sidebar.
  4. Resize your browser's window width to 1499px and ensure the sidebar turns grey
  5. Resize your browser's window to 1050px and click the sidebar button to make it disappear. Ensure the content's width expands to fill most of the screen (there should still be 30px of padding on each side of the content though). Click the sidebar button again to make it reappear.

For special pages: (should behave very similarly to history page)

  1. Visit https://en.wikipedia.beta.wmflabs.org/wiki/Special:BrokenRedirects when anon.
  2. Make sure your screen is > 1750px and ensure there is grey surrounding the white part of the page. Also ensure that the content of the page is wider than it was for the article page. Click the sidebar button to make it appear.
  3. Click the sidebar button and ensure the sidebar disappears. The content should expand to fill more of the page, but the tabs shouldn't move at all. Click the sidebar button again to make it reappear. Ensure the content shrinks to make room for the sidebar.
  4. Resize your browser's window width to 1499px and ensure the sidebar turns grey
  5. Resize your browser's window to 1050px and click the sidebar button to make it disappear. Ensure the content's width expands to fill most of the screen (there should still be 30px of padding on each side of the content though). Click the sidebar button again to make it reappear.

QA Results - Beta (Chrome 83.0.4103.116 (Official Build) (64-bit))

QA Results - Beta (Safari Version 13.1.1 (15609.2.9.1.2))

QA Results - Beta (Firefox Version 78.0.2 (64-bit))

QA Results - Beta (IE11)

QA Results - Beta (Opera 68)

QA Results - Beta (Edge 83)

ACStatusDetails
9T246420#6311097
10T246420#6311097
11T246420#6311097
12T246420#6311097

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

Change 606538 had a related patch set uploaded (by Aron Manning; owner: Aron Manning):
[mediawiki/core@master] checkboxHack: Capture SPACE key on button (label) to change checkbox state

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

Change 606541 had a related patch set uploaded (by Aron Manning; owner: Aron Manning):
[mediawiki/skins/Vector@master] [WIP] [modern] Sidebar button (label) is focusable instead of the checkbox

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

Change 605427 merged by jenkins-bot:
[mediawiki/skins/Vector@master] [modern] Move sidebar checkbox above content, sidebar button into header

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

Change 607311 had a related patch set uploaded (by Nray; owner: Nray):
[mediawiki/skins/Vector@master] Move sidebar into header and improve tab order

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

Demian added a comment.EditedJun 23 2020, 6:33 PM

What's the expected behavior on "very narrow" screens, ca. ~500px? An iPhone 8 renders 320pt (426px AFAICT) width. See chart.

@alexhollender Can we call that range "Narrow screen (<=700px765px)" and rename the "Narrow screen (1280px)" in the description to something along the lines of "Midsized screen (<=1280px)"?

Test parameters:

  • sidebar: on/off
  • action: view/history (article vs. workspace layout)
  • width: small/middle/wide

@nray @alexhollender Most of the transitions between these states work very well. There's one however which I find to be a very unexpected UX:

Toggling the sidebar on wide-screen history (workspace) page: while the workspace widens, the tabs move inside to match the article width.

This allows the tabs to remain in place while switching between view and history (article and workspace) when the sidebar is hidden:

There is a trade-off to be made regarding how the tabs line up.

I think the first use-case of toggling the sidebar is a more often and immediately experienced transition than switching to history.
Accordingly the trade-off should favor the sidebar toggling use-case.
Either

  1. the tabs should stay fixed (as if the sidebar was always open) or
  2. the tabs on the left should expand with the workspace to the left edge and the tabs on the right should remain in place.

I think option 2. is easier to implement (just use the same container as the workspace) and more natural as the tabs move together with the workspace.

I think option 2. is easier to implement (just use the same container as the workspace) and more natural as the tabs move together with the workspace.

To me this makes the most sense because (in my mental model) the tabs are highly connected with the content, and therefore where the content goes, the tabs should follow.

Based on this task, all pages are getting max-width (page container) and everything but special pages and page histories are getting a second max-width (content container).

All non-article pages shouldn't have a max-width (page or content containers). The project documentation focuses on articles and doesn't provide justification for doing so. I'd say implement max-width for ns:0 only and leave everything else with no max-width containers.

@JJMC89 thanks for making this clarification and apologies for not being precise in the task description. There are indeed three containers, all of which have max-widths. The discussions above about max-width or no max-width pertain to the innermost container, as you noted. And yes, everything below the header is additionally subject to the max-width of the middle container no matter what. Currently the middle container (referred to above as the workspace container) has a max-width of 1440px. My understanding is that you think 1440px is not enough width for special pages, is that correct? If so could you please help me understand why a max-width of 1440px is problematic? Thanks again for your help

It should be fine for many special pages like Special:Block. Log types (e.g., Special:Log, Special:AbuseLog, and page histories) it is problematic. You lose the ability to "unwrap" entries by making the browser window wider. I do this to improve readability by displaying one entry per line without any wrapping.

nray reassigned this task from nray to Volker_E.Jun 24 2020, 5:15 PM
nray added a subscriber: nray.

I think option 2. is easier to implement (just use the same container as the workspace) and more natural as the tabs move together with the workspace.

To me this makes the most sense because (in my mental model) the tabs are highly connected with the content, and therefore where the content goes, the tabs should follow.

Thanks for the explanation! I feel the same.

@JJMC89 thanks for making this clarification and apologies for not being precise in the task description. There are indeed three containers, all of which have max-widths. The discussions above about max-width or no max-width pertain to the innermost container, as you noted. And yes, everything below the header is additionally subject to the max-width of the middle container no matter what. Currently the middle container (referred to above as the workspace container) has a max-width of 1440px. My understanding is that you think 1440px is not enough width for special pages, is that correct? If so could you please help me understand why a max-width of 1440px is problematic? Thanks again for your help

It should be fine for many special pages like Special:Block. Log types (e.g., Special:Log, Special:AbuseLog, and page histories) it is problematic. You lose the ability to "unwrap" entries by making the browser window wider. I do this to improve readability by displaying one entry per line without any wrapping.

JJMC89 makes a very good point. The more width is available for log-type pages, the better. I think those shouldn't be constrained at all.
On the other hand form-type special pages might be considered to be limited: forms usually don't need more width than articles, but the results need to be taken into account as well: those might need more space.

@nray @alexhollender Most of the transitions between these states work very well. There's one however which I find to be a very unexpected UX:

Toggling the sidebar on wide-screen history (workspace) page: while the workspace widens, the tabs move inside to match the article width.

Hands-on experience: DEMO

Adding some notes: The sectioning element header now features label and sidebar navigation mw-sidebar before the sectioning header, which should be the logo. This is currently necessary to achieve a logical tab order. But we should keep this on the radar if there is a solution around this having logo first and then tabbable sidebar button connected to sidebar contents.

Change 607311 merged by jenkins-bot:
[mediawiki/skins/Vector@master] Move sidebar into header to improve tab order

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

@Demian thanks for your detailed review and comments in T246420#6249759. I was also looking into this same issue.

@nray I think the most straightforward way to state the goal is: the tabs should never move as a result of switching from Article to History (or similar). The tabs may move at times when opening/closing the sidebar. I've updated my prototype to show this desired behavior: https://di-collapsible-sidebar-5.web.app/Hathor. Apologies for not doing this earlier, for some reason I originally thought it wasn't possible. I have also made some GIFs (using screenshots from the prototype) to demonstrate the cases I've tested with (I believe these are all the relevant cases).

narrow screenwide screen
sidebar closed
sidebar open
nray added a comment.Jun 26 2020, 8:03 PM

@alexhollender Thank you, I've made another patchdemo based on your feedback. You can visit it at http://patchdemo.wmflabs.org/wikis/18130ec154d60d0d3aa17e433174f010/w/index.php/Test . Login with:

username: patchdemo
password: patchdemo123

From there you should be able to switch from the article to the history page. Can you please confirm that is what you had in mind?

Demian added a comment.EditedJun 27 2020, 12:03 AM

I've made another patchdemo

Direct link to modern layout: http://patchdemo.wmflabs.org/wikis/18130ec154d60d0d3aa17e433174f010/w/index.php?title=Test&action=history&useskinversion=2
@nray To get the modern layout as default just add to your demo the patch 607404: [DNM][Patchdemo] Default to modern layout

Looks good to me!

@Demian thanks for your detailed review and comments in T246420#6249759. I was also looking into this same issue.
I think the most straightforward way to state the goal is: the tabs should never move as a result of switching from Article to History (or similar).

I've had a big concern about the tab positioning, but this solution is very agreeable. I'd like to keep for the record that I still prefer the tabs sticking to the edges of the workspace/content, as @Jdrewniak wrote in T246420#6250350:

(in my mental model) the tabs are highly connected with the content, and therefore where the content goes, the tabs should follow.

However, both solutions are very reasonable and good on its own and the rest is subjective.

To move forward, please revisit the question raised about the tab border being cut in 2 parts:

@nray @alexhollender I think the vertical border line of the first tab on the right is missing in the prototype and the POC. I assumed this was done for simplicity, but it's not an issue to show that border and only hide it on the left side. In this form, however, it looks incomplete: the shapes are open in the middle and lose continuity.

From a design perspective I find this an unclear pattern that might even be confusing. I think the vertical border gradient should only be removed on the very left tab, only on articles, where the border-bottom does not extend further to the left (-> discussion on patch).

Change 608161 had a related patch set uploaded (by Aron Manning; owner: Aron Manning):
[mediawiki/skins/Vector@master] [modern] Normalize the sidebar button focus ring

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

To move forward, please revisit the question raised about the tab border being cut in 2 parts:

@nray @alexhollender I think the vertical border line of the first tab on the right is missing in the prototype and the POC. I assumed this was done for simplicity, but it's not an issue to show that border and only hide it on the left side. In this form, however, it looks incomplete: the shapes are open in the middle and lose continuity.

From a design perspective I find this an unclear pattern that might even be confusing. I think the vertical border gradient should only be removed on the very left tab, only on articles, where the border-bottom does not extend further to the left (-> discussion on patch).

I agree that all tabs aside from the left-most tab ("Article" in the screenshots above & below) should have borders on both sides.

Regarding tab positioning:

@alexhollender Thank you, I've made another patchdemo based on your feedback. You can visit it at http://patchdemo.wmflabs.org/wikis/18130ec154d60d0d3aa17e433174f010/w/index.php/Test . Login with:

username: patchdemo
password: patchdemo123

From there you should be able to switch from the article to the history page. Can you please confirm that is what you had in mind?

@nray incredible! You got it. 😍

I've had a big concern about the tab positioning, but this solution is very agreeable. I'd like to keep for the record that I still prefer the tabs sticking to the edges of the workspace/content, as @Jdrewniak wrote in T246420#6250350:

(in my mental model) the tabs are highly connected with the content, and therefore where the content goes, the tabs should follow.

However, both solutions are very reasonable and good on its own and the rest is subjective.

@Demian I agree that it's an awkward situation either way. If we keep the tabs in a fixed position then we get a visually awkward layout where the toolbar is more narrow than the content below. If we allow the tabs to move so that they always remain at the edges of the content area then we have an awkward user experience where switching between tabs (e.g. Article/History) becomes more difficult. In this case I believe that the visual awkwardness is preferable to an awkward user experience.

@alexhollender thanks for explaining the thinking behind positioning the tabs in the same spot regardless of the content width.
You make a good point about prioritizing the editor-workflow over the more abstract association between tabs and content.

If we keep the tabs in a fixed position then we get a visually awkward layout where the toolbar is more narrow than the content below.
If we allow the tabs to move so that they always remain at the edges of the content area then we have an awkward user experience where switching between tabs (e.g. Article/History) becomes more difficult.

I've asked around on discord how users feel about it. Though only two people engaged, they had no concerns, therefore I put my personal preference aside and I'm happy with the outcome. It's a trade-off, both options good for some reason. Thinking forward, if there was no page reload when changing views then the static tab positioning would be clearly the better solution.

I agree that all tabs aside from the left-most tab ("Article" in the screenshots above & below) should have borders on both sides.

One question: what about the wide workspace when the border-bottom extends to the left from the "Article" tab?

nray added a comment.Jul 1 2020, 12:12 AM

@alexhollender During the course of code review, Aron had a question about the padding of the sidebar:

At small viewport widths, the sidebar turns a gradient grey, but the edges of the gradient (white parts) can get pretty close to the links. Should there be a top and bottom padding applied to the sidebar to ease this?

We'll also need to update VE ('s toolbar) to make up for the toolbar not leaning against a border any more…

Jdrewniak claimed this task.Jul 1 2020, 5:25 PM

@nray Being done with the CheckboxHack I'm just starting to get into the DOM structure here. The first thing I've noticed how easier it would be to focus on the page structure if we would have moved the content block into its own template, as discussed in T249073#6034873, T249073#6038717 and split into T253669.

It would also have the benefit of:

  • cleaner diffs in your patch and the git history
  • a big chunk of template code DRYed
  • semantic separation of concerns

Do you think this is a good time to pick up that work where we left off? I have redone my old patch on the current master: 585625.

As Nray's patch is almost done, we could revisit a minor detail that was descoped from the previous patch. The sidebar button's focus outline in Firefox is different from the regular focus outline. Fix, using the already established solution: patch 607311

nray added a comment.Tue, Jul 7, 5:55 PM

@Volker_E @alexhollender From code review, I think Volker had one pending question about the border on the page-container that I am hoping we can sort out:

Not a big fan of this. Need to check-in with Alex again. [1]

I'm not sure if this is due to my usage of the Less fade function or a more design centric reason.

[1] https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/603606/38/resources/skins.vector.styles/layout-max-width.less#176

nray added a comment.Tue, Jul 7, 6:34 PM

Do you think this is a good time to pick up that work where we left off? I have redone my old patch on the current master: 585625.

@Demian It's a valid pain point to keep in mind and write about in T253669, but I don't suspect will be tackled in this ticket.

As Nray's patch is almost done, we could revisit a minor detail that was descoped from the previous patch. The sidebar button's focus outline in Firefox is different from the regular focus outline. Fix, using the already established solution: patch 607311

Left a comment on the patch (https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/608161 )

nray added a comment.EditedTue, Jul 7, 7:08 PM

@ovasileva I wanted to loop you in on a conversation @alexhollender and I have been having offline regarding a potential issue we might encounter when we deploy the max-width design. The issue surfaces anytime the height of the sidebar is larger than the height of the content and causes the sidebar to overflow into the footer:

You can see this by visiting my patchdemo:

http://patchdemo.wmflabs.org/wikis/87ed3f27d19b458a49cae1f325619ee2/w/index.php/Main_Page

and by logging in with:

username: patchdemo
password: patchdemo123

In production, I'm not sure how often the sidebar height is larger than the content, and therefore I'm not sure what its impact would be. There are several potential fixes for this that we've been discussing, but I don't think any are trivial enough to incorporate in this ticket (should be split off in its own ticket).

Change 603606 merged by jenkins-bot:
[mediawiki/skins/Vector@master] Implement Page, Workspace, Content, and Article Toolbar Containers

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

@ovasileva I wanted to loop you in on a conversation @alexhollender and I have been having offline regarding a potential issue we might encounter when we deploy the max-width design. The issue surfaces anytime the height of the sidebar is larger than the height of the content and causes the sidebar to overflow into the footer:

You can see this by visiting my patchdemo:

http://patchdemo.wmflabs.org/wikis/87ed3f27d19b458a49cae1f325619ee2/w/index.php/Main_Page

and by logging in with:

username: patchdemo
password: patchdemo123

In production, I'm not sure how often the sidebar height is larger than the content, and therefore I'm not sure what its impact would be. There are several potential fixes for this that we've been discussing, but I don't think any are trivial enough to incorporate in this ticket (should be split off in its own ticket).

@nray - were you able to fix this? This is what I'm seeing:

Either way, I agree we should split it off and mark that task as high. I don't think it's a blocker for the deployment though.

nray added a comment.Wed, Jul 8, 3:52 PM

@ovasileva No, the issue has not been fixed. I will make a task for it today

nray added a comment.Wed, Jul 8, 4:43 PM

@ovasileva I think you may have wanted me to ping you when I was about to write the QA steps for this ticket to get a list of the browsers to test. Please consider this the ping :)

nray reassigned this task from Jdrewniak to Edtadros.Wed, Jul 8, 6:43 PM
nray claimed this task.
nray added a subscriber: Edtadros.

Change 610424 had a related patch set uploaded (by Nray; owner: Nray):
[operations/mediawiki-config@master] Enable limited-width layout for "Latest Vector" on Beta

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

Change 610424 merged by jenkins-bot:
[operations/mediawiki-config@master] Enable limited-width layout for "Latest Vector" on Beta

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

Change 610912 had a related patch set uploaded (by Jdrewniak; owner: Aron Manning):
[mediawiki/core@master] checkboxHack: Capture SPACE and ENTER key on button (label) to change checkbox state

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

Change 610912 merged by jenkins-bot:
[mediawiki/core@master] checkboxHack: Capture SPACE and ENTER key on button (label) to change checkbox state

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

nray reassigned this task from nray to Edtadros.Fri, Jul 10, 12:16 AM
nray updated the task description. (Show Details)

@ovasileva I think you may have wanted me to ping you when I was about to write the QA steps for this ticket to get a list of the browsers to test. Please consider this the ping :)

Thank you!

ovasileva updated the task description. (Show Details)Mon, Jul 13, 5:00 PM
Edtadros added a comment.EditedWed, Jul 15, 3:02 AM

Test Result - Beta (Chrome 83.0.4103.116 (Official Build) (64-bit))

Status: ✅ PASS
Environment: beta
OS: macOS Catalina
Browser: Chrome
Device: MBP
Emulated Device: NA

Test Artifact(s):

QA Steps

For article pages:

  1. Visit https://en.wikipedia.beta.wmflabs.org/wiki/Main_Page when anon.
  2. ✅ AC1: Make sure your screen is > 1750px and ensure there is grey surrounding the white part of the page. Click the sidebar button to make it appear.

  1. ✅ AC2: Click the sidebar button and ensure the sidebar disappears and the content does not move. Click the sidebar button again to make it reappear. Again, ensure the content does not move.

  1. ✅ AC3: Resize your browser's window width to 1499px and ensure the sidebar turns grey

  1. ✅ AC4: Resize your browser's window to 1050px and click the sidebar button to make it disappear. Ensure the content's width expands to fill most of the screen (there should still be 30px of padding on each side of the content though). Click the sidebar button again to make it reappear.

For history pages:

  1. Visit https://en.wikipedia.beta.wmflabs.org/w/index.php?title=Main_Page&action=history when anon.
  2. ✅ AC5: Make sure your screen is > 1750px and ensure there is grey surrounding the white part of the page. Also ensure that the content of the page is wider than it was for the article page. Click the sidebar button to make it appear.
  3. ✅ AC6: Click the sidebar button and ensure the sidebar disappears. The content should expand to fill more of the page, but the tabs shouldn't move at all. Click the sidebar button again to make it reappear. Ensure the content shrinks to make room for the sidebar.

  1. ✅ AC7: Resize your browser's window width to 1499px and ensure the sidebar turns grey

  1. ✅ AC8: Resize your browser's window to 1050px and click the sidebar button to make it disappear. Ensure the content's width expands to fill most of the screen (there should still be 30px of padding on each side of the content though). Click the sidebar button again to make it reappear.

For special pages: (should behave very similarly to history page)

  1. Visit https://en.wikipedia.beta.wmflabs.org/wiki/Special:BrokenRedirects when anon.
  2. ✅ AC9: Make sure your screen is > 1750px and ensure there is grey surrounding the white part of the page. Also ensure that the content of the page is wider than it was for the article page. Click the sidebar button to make it appear.
  3. ✅ AC10: Click the sidebar button and ensure the sidebar disappears. The content should expand to fill more of the page, but the tabs shouldn't move at all. Click the sidebar button again to make it reappear. Ensure the content shrinks to make room for the sidebar.

  1. ✅ AC11: Resize your browser's window width to 1499px and ensure the sidebar turns grey

  1. ✅ AC12: Resize your browser's window to 1050px and click the sidebar button to make it disappear. Ensure the content's width expands to fill most of the screen (there should still be 30px of padding on each side of the content though). Click the sidebar button again to make it reappear.

Test Result - Beta (Safari Version 13.1.1 (15609.2.9.1.2))

Status: ✅ PASS
Environment: beta
OS: macOS Catalina
Browser: Safari 13.1.1
Device: MBP
Emulated Device: NA

Test Artifact(s):

QA Steps

For article pages:

  1. Visit https://en.wikipedia.beta.wmflabs.org/wiki/Main_Page when anon.
  2. ✅ AC1: Make sure your screen is > 1750px and ensure there is grey surrounding the white part of the page. Click the sidebar button to make it appear.
  3. ✅ AC2: Click the sidebar button and ensure the sidebar disappears and the content does not move. Click the sidebar button again to make it reappear. Again, ensure the content does not move.

  1. ✅ AC3: Resize your browser's window width to 1499px and ensure the sidebar turns grey

  1. ✅ AC4: Resize your browser's window to 1050px and click the sidebar button to make it disappear. Ensure the content's width expands to fill most of the screen (there should still be 30px of padding on each side of the content though). Click the sidebar button again to make it reappear.

For history pages:

  1. Visit https://en.wikipedia.beta.wmflabs.org/w/index.php?title=Main_Page&action=history when anon.
  2. ✅ AC5: Make sure your screen is > 1750px and ensure there is grey surrounding the white part of the page. Also ensure that the content of the page is wider than it was for the article page. Click the sidebar button to make it appear.
  3. ✅ AC6: Click the sidebar button and ensure the sidebar disappears. The content should expand to fill more of the page, but the tabs shouldn't move at all. Click the sidebar button again to make it reappear. Ensure the content shrinks to make room for the sidebar.

  1. ✅ AC7: Resize your browser's window width to 1499px and ensure the sidebar turns grey

  1. ✅ AC8: Resize your browser's window to 1050px and click the sidebar button to make it disappear. Ensure the content's width expands to fill most of the screen (there should still be 30px of padding on each side of the content though). Click the sidebar button again to make it reappear.

For special pages: (should behave very similarly to history page)

  1. Visit https://en.wikipedia.beta.wmflabs.org/wiki/Special:BrokenRedirects when anon.
  2. ✅ AC9: Make sure your screen is > 1750px and ensure there is grey surrounding the white part of the page. Also ensure that the content of the page is wider than it was for the article page. Click the sidebar button to make it appear.
  3. ✅ AC10: Click the sidebar button and ensure the sidebar disappears. The content should expand to fill more of the page, but the tabs shouldn't move at all. Click the sidebar button again to make it reappear. Ensure the content shrinks to make room for the sidebar.

  1. ✅ AC11: Resize your browser's window width to 1499px and ensure the sidebar turns grey

  1. ✅ AC12: Resize your browser's window to 1050px and click the sidebar button to make it disappear. Ensure the content's width expands to fill most of the screen (there should still be 30px of padding on each side of the content though). Click the sidebar button again to make it reappear.

Test Result - Beta (Firefox Version 78.0.2 (64-bit))

Status: ✅ PASS
Environment: beta
OS: macOS Catalina
Browser: Firefox 78.0.2
Device: MBP
Emulated Device: NA

Test Artifact(s):

QA Steps

For article pages:

  1. Visit https://en.wikipedia.beta.wmflabs.org/wiki/Main_Page when anon.
  2. ✅ AC1: Make sure your screen is > 1750px and ensure there is grey surrounding the white part of the page. Click the sidebar button to make it appear.
  3. ✅ AC2: Click the sidebar button and ensure the sidebar disappears and the content does not move. Click the sidebar button again to make it reappear. Again, ensure the content does not move.

  1. ✅ AC3: Resize your browser's window width to 1499px and ensure the sidebar turns grey

  1. ✅ AC4: Resize your browser's window to 1050px and click the sidebar button to make it disappear. Ensure the content's width expands to fill most of the screen (there should still be 30px of

For history pages:

  1. Visit https://en.wikipedia.beta.wmflabs.org/w/index.php?title=Main_Page&action=history when anon.
  2. ✅ AC5: Make sure your screen is > 1750px and ensure there is grey surrounding the white part of the page. Also ensure that the content of the page is wider than it was for the article page. Click the sidebar button to make it appear.
  3. ✅ AC6: Click the sidebar button and ensure the sidebar disappears. The content should expand to fill more of the page, but the tabs shouldn't move at all. Click the sidebar button again to make it reappear. Ensure the content shrinks to make room for the sidebar.

  1. ✅ AC7: Resize your browser's window width to 1499px and ensure the sidebar turns grey

  1. ✅ AC8: Resize your browser's window to 1050px and click the sidebar button to make it disappear. Ensure the content's width expands to fill most of the screen (there should still be 30px of padding on each side of the content though). Click the sidebar button again to make it reappear.

For special pages: (should behave very similarly to history page)

  1. Visit https://en.wikipedia.beta.wmflabs.org/wiki/Special:BrokenRedirects when anon.
  2. ✅ AC9: Make sure your screen is > 1750px and ensure there is grey surrounding the white part of the page. Also ensure that the content of the page is wider than it was for the article page. Click the sidebar button to make it appear.
  3. ✅ AC10: Click the sidebar button and ensure the sidebar disappears. The content should expand to fill more of the page, but the tabs shouldn't move at all. Click the sidebar button again to make it reappear. Ensure the content shrinks to make room for the sidebar.

  1. ✅ AC11: Resize your browser's window width to 1499px and ensure the sidebar turns grey

  1. ✅ AC12: Resize your browser's window to 1050px and click the sidebar button to make it disappear. Ensure the content's width expands to fill most of the screen (there should still be 30px of padding on each side of the content though). Click the sidebar button again to make it reappear.
Edtadros added a comment.EditedThu, Jul 16, 5:56 AM

Test Result - Beta (IE11, Opera 68, Edge 83)

Status: ✅ PASS
Environment: beta
OS: macOS Catalina
Browser: IE 11, Opera 68, Edge 83
Device: MBP
Emulated Device: NA

Test Artifact(s):

QA Steps

For article pages:
IE 11

  1. Visit https://en.wikipedia.beta.wmflabs.org/wiki/Main_Page when anon.
  2. ✅ AC1: Make sure your screen is > 1750px and ensure there is grey surrounding the white part of the page. Click the sidebar button to make it appear.
  3. ✅ AC2: Click the sidebar button and ensure the sidebar disappears and the content does not move. Click the sidebar button again to make it reappear. Again, ensure the content does not move.

  1. ✅ AC3: Resize your browser's window width to 1499px and ensure the sidebar turns grey

This is likely minor, but on IE11 it changes to grey at 1482px.


This is okay per T246420#6312999

  1. ✅ AC4: Resize your browser's window to 1050px and click the sidebar button to make it disappear. Ensure the content's width expands to fill most of the screen (there should still be 30px of

For history pages:
Opera 68

  1. Visit https://en.wikipedia.beta.wmflabs.org/w/index.php?title=Main_Page&action=history when anon.
  2. ✅ AC5: Make sure your screen is > 1750px and ensure there is grey surrounding the white part of the page. Also ensure that the content of the page is wider than it was for the article page. Click the sidebar button to make it appear.
  3. ✅ AC6: Click the sidebar button and ensure the sidebar disappears. The content should expand to fill more of the page, but the tabs shouldn't move at all. Click the sidebar button again to make it reappear. Ensure the content shrinks to make room for the sidebar.

  1. ✅ AC7: Resize your browser's window width to 1499px and ensure the sidebar turns grey

This is likely minor, but on IE11 it changes to grey at 1482px.


This is okay per T246420#6312999

  1. ✅ AC8: Resize your browser's window to 1050px and click the sidebar button to make it disappear. Ensure the content's width expands to fill most of the screen (there should still be 30px of padding on each side of the content though). Click the sidebar button again to make it reappear.

For special pages: (should behave very similarly to history page)
Edge 83

  1. Visit https://en.wikipedia.beta.wmflabs.org/wiki/Special:BrokenRedirects when anon.
  2. ✅ AC9: Make sure your screen is > 1750px and ensure there is grey surrounding the white part of the page. Also ensure that the content of the page is wider than it was for the article page. Click the sidebar button to make it appear.
  3. ✅ AC10: Click the sidebar button and ensure the sidebar disappears. The content should expand to fill more of the page, but the tabs shouldn't move at all. Click the sidebar button again to make it reappear. Ensure the content shrinks to make room for the sidebar.

  1. ✅ AC11: Resize your browser's window width to 1499px and ensure the sidebar turns grey

This is likely minor, but on IE11 it changes to grey at 1482px.


This is okay per T246420#6312999

  1. ✅ AC12: Resize your browser's window to 1050px and click the sidebar button to make it disappear. Ensure the content's width expands to fill most of the screen (there should still be 30px of padding on each side of the content though). Click the sidebar button again to make it reappear.

@nray, Please a look at the ACs with a ❓ in T246420#6311097. The side bar doesn't turn grey right at 1499, I'm pretty sure this isn't an issue, but you never know.

Change 613192 had a related patch set uploaded (by Nray; owner: Nray):
[operations/mediawiki-config@master] Enable limited-width layout for Vector on officewiki

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

nray added a comment.Thu, Jul 16, 4:34 PM

@Edtadros That's kind of weird that IE11 does that (although it is IE), but I don't think it's very concerning.

Volker_E added a comment.EditedThu, Jul 16, 5:14 PM

@nray @Edtadros A wild guess is, that IE makes the calculation differently with scrollbar involved… Seems fine any way.

Change 613192 merged by jenkins-bot:
[operations/mediawiki-config@master] Enable limited-width layout for Modern Vector

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

Mentioned in SAL (#wikimedia-operations) [2020-07-16T18:12:05Z] <addshore@deploy1001> Synchronized wmf-config/InitialiseSettings.php: [[gerrit:613192]] T246420 Enable limited-width layout for Modern Vector (duration: 00m 56s)

Quick production QA - Chrome 84

For article pages:

Visit https://en.wikipedia.beta.wmflabs.org/wiki/Main_Page when anon.
Make sure your screen is > 1750px and ensure there is grey surrounding the white part of the page. Click the sidebar button to make it appear. ✅
Click the sidebar button and ensure the sidebar disappears and the content does not move. Click the sidebar button again to make it reappear. Again, ensure the content does not move. ✅
Resize your browser's window width to 1499px and ensure the sidebar turns grey ✅
Resize your browser's window to 1050px and click the sidebar button to make it disappear. Ensure the content's width expands to fill most of the screen (there should still be 30px of padding on each side of the content though). Click the sidebar button again to make it reappear. ✅
For history pages:

Visit https://en.wikipedia.beta.wmflabs.org/w/index.php?title=Main_Page&action=history when anon.
Make sure your screen is > 1750px and ensure there is grey surrounding the white part of the page. Also ensure that the content of the page is wider than it was for the article page. Click the sidebar button to make it appear. ✅
Click the sidebar button and ensure the sidebar disappears. The content should expand to fill more of the page, but the tabs shouldn't move at all. Click the sidebar button again to make it reappear. Ensure the content shrinks to make room for the sidebar. ✅
Resize your browser's window width to 1499px and ensure the sidebar turns grey ✅
Resize your browser's window to 1050px and click the sidebar button to make it disappear. Ensure the content's width expands to fill most of the screen (there should still be 30px of padding on each side of the content though). Click the sidebar button again to make it reappear. ✅
For special pages: (should behave very similarly to history page)

Visit https://en.wikipedia.beta.wmflabs.org/wiki/Special:BrokenRedirects when anon.
Make sure your screen is > 1750px and ensure there is grey surrounding the white part of the page. Also ensure that the content of the page is wider than it was for the article page. Click the sidebar button to make it appear. ✅
Click the sidebar button and ensure the sidebar disappears. The content should expand to fill more of the page, but the tabs shouldn't move at all. Click the sidebar button again to make it reappear. Ensure the content shrinks to make room for the sidebar. ✅
Resize your browser's window width to 1499px and ensure the sidebar turns grey ✅
Resize your browser's window to 1050px and click the sidebar button to make it disappear. Ensure the content's width expands to fill most of the screen (there should still be 30px of padding on each side of the content though). Click the sidebar button again to make it reappear. ✅

Spot-checked Firefox & Opera - all looks good. Note that Opera has a left sidebar which causes a the text width to go under 960 and a small reflow

ovasileva closed this task as Resolved.Mon, Jul 20, 8:22 AM

Resolving based on above. Will test again in production after the deployment.