Page MenuHomePhabricator

Don't expand Vector's vertical padding on mw-body on HD/non-HD
Closed, DeclinedPublic

Description

Non-HD @content-padding value is 1em; for HD, we are over-ridding this to 1.5em in all directions except for left, which meant that on screen width re-size the content within the .mw-body <div> would get shifted vertically for no reason. Instead, we should retain from the non-HD styling the existing padding, and only over-ride it for padding-left and -right. It's not entirely clear to me why we bother to do this bit at all, but, at least, can't
we maintain some level of sanity for our users?

Event Timeline

Restricted Application added subscribers: Zppix, Aklapper. · View Herald Transcript

Change 264910 had a related patch set uploaded (by Jforrester):
Don't expand the vertical padding on mw-body on HD/non-HD

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

Jdlrobson changed the task status from Open to Stalled.Aug 31 2016, 9:37 PM
Jdlrobson subscribed.

@Jdforrester-WMF and @Krinkle should work this out :)

@Jdforrester-WMF The issue I pointed out in code review (https://gerrit.wikimedia.org/r/264910) was about horizontal padding. The changing of left/right padding changes the effective width of the content element, and as such requires a complete reflow of all text and floating elements. However, I realise now that that doesn't matter. Since it is triggered by a resize, the width is changing anyway. And as you point out, this task is about vertical padding. Sorry for the confusion.

As for the vertical padding, I'm not sure why it matters that the content will be slightly lower or higher. From what I can tell, this makes perfect sense. The purpose of HD mode, very similar to the "variable spacing" modes that Google products use, is to compact or "add breathing room" based on the available space. Where Google has three modes, we have two. The slight increase in padding within the content container is the result of that change.

I'm curious in what way you consider this disruptive to the reader experience. My first guess would be scrolling position, but as mentioned, when resizing the window, the text and float flow will change inevitably - as such causing a much more significant offset change compared to the <1em offset change from the top padding. Also, in recent versions of Chrome and Firefox, there is now intelligent logic that usually is able to maintain the intended offset when resizing the browser window, based on sticking to viewport-relative offsets of headings, paragraph text, text nodes, and various floating elements currently in view.

From a design perspective, that's not an issue. It's a common pattern to extend horizontal padding on wider screens and in order to keep white space harmonious, it also makes sense to extend vertical padding. The few times where resizing a window could _maybe_ lead to a minor confusion when vertical padding changes versus the main use case of loading the page at one specific size and having a more harmonious appearance are not worth the change. This task should be declined.

Per T139066#5542753 I will decline this in a week if I hear no objections.

Change 264910 abandoned by Jdlrobson:
Don't expand the vertical padding on mw-body on desktop (HD)

Reason:
It sounds like we want to decline this (https://phabricator.wikimedia.org/T139066)

I'm possible lacking context so apologies if I've misunderstood anything but it sounds like we need to discuss this further on the task regardless before being able to review this.

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

The principal motivation is that the content shouldn't move up/down when the window width is changing left/right. The gets particularly acute for wide content with when resizing near the threshold.

Aklapper changed the task status from Stalled to Open.Nov 2 2020, 5:42 PM

The previous comments don't explain who or what (task?) exactly this task is stalled on ("If a report is waiting for further input (e.g. from its reporter or a third party) and can currently not be acted on"). Hence resetting task status, as tasks should not be stalled (and then potentially forgotten) for years for unclear reasons.

Per T139066#5542753 I will decline this in a week if I hear no objections.

Not sure if James' last comment is an objection or not...

Vector legacy is frozen at this point in light of the new Vector being built so I don't think it makes sense to work on this.