Page MenuHomePhabricator

Revisit box-sizing: border-box for everything in MobileFrontend
Closed, ResolvedPublic40 Estimated Story Points


So yeh the subject of ownership is confusing. Technically MobileFrontend does own the skin, but it doesn't own certain areas which happen to be inside it and I guessbecause of this thus MobileFrontend doesn't own the skin.

I suspect we may want to move the box-sizing rules so that it applies to anything in mobile that is a View (erg I wish there was a url I could point to for our documentation) - this could then be turned off by the VisualEditorOverlay.

I'd still need to look closely at what it does to things like our hacks to get images and tables to render properly.

So next actionable steps I can suggest

  • Let's make the rule only apply in .beta and .stable modes of site to everything and anything that is a View (I'm doing this now) [DONE]
  • Get deployed to cluster.
  • Give me/us time to review in alpha the damage on live wikis if any to the content area.
  • Make a decision based on the above.

Related Objects

Event Timeline

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

Change 202760 had a related patch set uploaded (by Jdlrobson):
Border box no longer default

Change 202760 merged by jenkins-bot:
Border box no longer default

So while the latest patch fixes VE, I'd still like to switch all views over to not use the border-box * selector. Any components of MF that may get shared between read mode & VE (for example, the toolbar) could render differently. Also future components that might be embedded in the regular view, but which aren't owned by MF may have the same problem as VE.

This appears to not be working correctly. The view-border-box class is getting applied to the body before VE loads, and never removed.

Change 218608 had a related patch set uploaded (by Esanders):
Never apply border-box to 'body' (i.e. for a 'Skin')

Change 218608 merged by jenkins-bot:
Never apply border-box to 'body' (i.e. for a 'Skin')

Note: The latest fix has introduced some visual regressions which have made it out on to 1.26wmf10. See T102868: Big logout icon we need to decide whether to revert this or work on top of it some fixes (please don't rush changes to the box-sizing defaults in future without vigorous testing across the whole of the mobile site)

Once the patch is reverted, I'll restore it and we'll review/test it a bit more vigorously second time round to fix up the remaining issues with content inside the skin.

Change 223176 had a related patch set uploaded (by Jdlrobson):
Skin itself should not be border box

I'm a bit lost here -- and totally admit that could just be my lack of understanding re: how LESS "works" or something so I apologize in advance if this is rather 'obvious' to you coder types -- but what exactly is changed by r223176 of July 6th if the .view-border-box class is still present in the BODY element and still defined to cascade down to any & all of it's decendants &/or children elements (.view-border-box *, .view-border-box)?

Sure - I can grasp the fact the class name was added to certain elements - I'm just not sure what difference that makes if the BODY element's cascade is still in place (or is that stopped by the added bits to Skin.js?).

I have to ask because when halting that "body cascade" was the aim two or three weeks ago, it had to be reverted in r219877 to recover from all the "deviations" applying it had exposed in process.

Thanks for your time at any rate.

@GOIII: 219877 was reverted because it caused a handful of regressions.

As of 223176, the view-border-box class won't be present on the body element, which is the result of [the change to the Skin class]( as you pointed out. So the major difference between the initial and current patches is that the latter also addresses the regressions caused by the change.

The file that I was trying to share on 223176 was

stable.gif (423×1 px, 1 MB)
/cc @Florian

Thanks for the clarification, phuedx.

Still think this is a bad idea; fixed skin design and format should use one setting (imho: border-box) and the branch/container dealing with user initiated content, templates and the like should also have one setting (in this case; content-box).

Eliminating the attribute & allowing the default (content-box) to reign simply by attribute omission doesn't seem to be the optimal way forward.

Change 223176 merged by jenkins-bot:
Skin itself should not be border box

This is merged. @Esanders any follow ups required. Does VE look good to you? (All looks well to me)

Jhernandez added a subscriber: Jhernandez.

Thanks @Jdlrobson for all the work on this.

sounds pretty accurate, but hindsight is 20/20 ;)

It's certainly fixed for VE, which was the high-priority task.

However there is still a * selector left over, which is going to cause problems in the future if any other code is integrated with MF. This will need to be resolved before we migrate to OOUI.

Title of description is a little confusing as we're not planning on revisiting it in MobileFrontend. I think this is superseded by T147692.
If this needs to be reopened, please flesh out the task description.