Page MenuHomePhabricator

Bootstrap's CSS rule "box-sizing: border-box;" breaks VE toolbar
Closed, ResolvedPublic

Description

In Bootstrap there is rule in line 200:

* {
  -webkit-box-sizing: border-box;
  -moz-box-sizing: border-box;
  box-sizing: border-box;
}

It breaks VE toolbar, first the broken toolbar and below the normal toolbar:

снимок10.png (120×1 px, 16 KB)

Related Objects

StatusSubtypeAssignedTask
Resolved Spage
Resolved Spage
Resolved Spage
Resolvedori
DeclinedNone
ResolvedNone
DeclinedNone
ResolvedAnomie
DeclinedNone
OpenNone
OpenNone
Resolved Spage
DeclinedNone
Resolvedjeropbrenda
OpenNone
DeclinedQgil
Resolved Spage
ResolvedQgil
ResolvedQgil
ResolvedQgil
Resolved Spage
Resolved Spage
Resolved Spage
DeclinedNone
DeclinedNone
Resolved Spage
Resolved Spage
DeclinedNone
DeclinedNone
ResolvedVolker_E

Event Timeline

Pastakhov raised the priority of this task from to Needs Triage.
Pastakhov updated the task description. (Show Details)
Pastakhov added a project: Blueprint.
Pastakhov added a subscriber: Pastakhov.
Volker_E triaged this task as High priority.
Volker_E set Security to None.
Volker_E renamed this task from Bootstraps css rule "box-sizing: border-box;" breaks VE toolbar to Bootstrap's CSS rule "box-sizing: border-box;" breaks VE toolbar.Dec 31 2015, 9:40 PM

Change 261779 had a related patch set uploaded (by VolkerE):
Unbreak Visual Editor Toolbar layout

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

similar "issue" under vector, .vectorTabs and the same .css rule reported in T104767

Easily fixed but still languishes today :(

The concerns raised by @matmarex at T104767 are applying here as well, predominantly "You do not control everything on the page you're applying it to".
When putting myself in the role of a theme developer, I want to work with box-sizing: border-box because it is making my developer life easier. But as I don't have control about user generated content, which highly probable might rely on CSS initial content-box sizing, we should apply border-box to everything except .mw-body-content.

I stand by my points. :) Sorry, I personally will not be supporting anything that sets * { box-sizing: border-box; }, that's just asking for trouble. Overriding it back to content-box in certain places should mostly work, but you will have problems with CSS specificities and UI elements added by extensions in unexpected places in the DOM.

@matmarex I see your point. After Blueprint is first and foremost developed for use at Living Style Guide, I'll stay with universal selector's approach till it's breaking extensions is overwhelming or use cases will change. :)

@matmarex, @Volker_E, I don't understand what is causing all this angst (maybe its just my 'tone') over something I'm in total agreement with you guys in principle as well as in practice.

The point that seems to keep getting 'lost' not only here but in a few other key reports is that I'm dealing with a far smaller project at Wikisource than the norm with a far more narrow mission & scope than something like Wikipedia. I've already addressed the local bits that didn't like the universal selector's effects with re-designs and/or tweaking accordingly (nothing extravagant that would hinder, say, an import by another project or something).

That means I can easily manage such issues by delving into the local stuff as new changes arrive or are applied by other's locally. As a result, the only overrides back to 'content-box' that I had to make were for..

  • (1) Indicator instances (the .top-icon replacement extension); Out of my hands because the local en.WS 'fix' would not be 'seamless' if applied in another project. and;
  • (2) the specific DIV container dealing with wikiEditor's toolbar buttons (not the dialogs; not the booklets or menus; not a single thing else). Same reason; no guarantee a local fix would work seamlessly if applied on other projects.

So I feel like you guys are in an unnecessary 'panic' on this point because you seem to envision that I'm up to creating some apocalyptic universal border-box style guide-less cabal or something. That's the farthest thing from reality. And the change I proposed in T104767 was completely benign to the content-box "world" - it just brought the first and last (and/or unselected) vectorTabs rendering to match the rendering for selected and any filler tabs in between for the left and right "group".

But because I used the exact same argument you guys are making to not make the universal selector in question a site wide addition but instead solely for illustrative purposes to properly support my request, I got this same na-nah na-nah boo boo, ... reaction this time as I did then; tagging me (and the proposal) from then on "suspect" to put it politely.

No big deal at the end of the day; it's just another local .css entry that I'm forced to keep track of because I'm not of Wikipedia, MediaWiki or Commons 'concern'; we're use to it. :)

Honestly, I really don't care what you do at Wikisource, as long as you don't make me debug it :) But I will oppose any widely-applied border-box in code that affects code that I have to maintain. Same with any non-bundled skins, feel free to do anything you want, but if you run into any problems related to my projects, you're on your own.

If you submitted the proposal from T104767 as a patch, I probably would've merged it, but you never did.

Honestly, I really don't care what you do at Wikisource, as long as you don't make me debug it :) But I will oppose any widely-applied border-box in code that affects code that I have to maintain. Same with any non-bundled skins, feel free to do anything you want, but if you run into any problems related to my projects, you're on your own.

Really? you're actually conflating what I originally asked for as some sort of 'widely-applied border-box ... code that affects code that [you] have to maintain'? It was nothing more than setting a descendant span's height attribute to 100% instead letting it continue using the inherent auto default.

div.vectorTabs span {
    height: 100%;
}

Somebody call the kommandos at keyboard kontrol & turn me in. sheesh

If you submitted the proposal from T104767 as a patch, I probably would've merged it, but you never did.

For the umpteenth time - I don't how to work that Git nonsense. In months of on and off attempts to "learn" the ins and outs of it, I only managed to get only a single attempt to take that went nowhere and didn't trigger even an automated response. Believe me - I wouldn't even take a dump here if didn't have to re: en.WS admin duties (no pun intended).

Change 261779 merged by jenkins-bot:
Unbreak Visual Editor Toolbar & possible user styles layout

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

Volker_E moved this task from Needs Review / Feedback to Done on the Blueprint board.
Volker_E removed a project: Patch-For-Review.