Refactor buttons borders

[llorca]

Fixes #233, countless of unreported button groups and control groups visual issues

Changes proposed in this pull request:

• Refactor buttons to use box shadows instead of borders
• Add new variable to deal with buttons on top of non-plain content: $button-box-shadow-overlay
• Update shadow values for buttons (done with @piotrk)

Reviewers should focus on:

• Play with button groups and control groups in both themes, including with disabled buttons/inputs, readonly inputs, and all kinds of weird combinations that you can think of.
• Make sure everything is aligned and that there's no blurry edge or pixels.

Screenshot

Example from #233.

Before:

After:

[blueprint-bot]

Fix stacking and alignment of elements in control groups

Preview: docs
Coverage: core | datetime

[adidahiya]

Interesting, you're proposing going back to box shadows? What are the tradeoffs / remind me why we moved away from box shadows in the first place?

[llorca]

Hehe, glad you're asking. Yes, we're basically going back to box-shadow. Borders were a good experiment but in the end, they're too hard to maintain and iterate on for a few reasons:

• borders take up space unlike shadows, therefore changing the box-sizing of elements. This PR gets rid of unwanted maths in a few places (- $button-border-width * 2 for instance)
• borders are defined for every direction, making them verbose and adding constraints in button groups and control groups configurations. With shadows, there's no need to remove a border-right in button groups for instance; the same shadow works in all configurations
• can't stack borders with drop shadows (I discovered that after merging the border approach a while ago, sad times)
• alignment of control group elements was messed up for a while in dark theme
• some <select> configuration (.pt-large in particular) had their text that was not vertically centered
• have to manage the value of box-sizing in addition to border

Shadows solve all of the above problems, + more. Why did I even use borders in the first place? It was because we wanted the default light theme button to have their border outside of the background shape, which we can't achieve with a box-shadow on a single element (we can, but the button would look 2px taller). Now we're back to shadows, the way I solve this problem is by using an alternative set of box shadows ($button-box-shadow-overlay) in required cases: switches and sliders.

[llorca]

The shadow stuff from this PR is actually not that interesting because it's super straightforward and easy to understand. The meaty stuff is the z-index ordering in button groups and control groups

[adidahiya]

@llorca Thanks for explaining. I think it would be really great to include that explanation of tradeoffs in code comments.

[llorca]

@adidahiya I thought about it but didn't so appropriate for code comments. I can do it, however it will be quite a large block of comments to explain all of that

[adidahiya]

@llorca yeah, a large block comment is totally reasonable, and IMO preferable when there are important design decisions that are hard to glean from just reading code

[llorca]

Cool, I'll add a block comment describing the tradeoffs between borders and buttons 👍

[llorca]

Tried to keep the comment as short as possible. How's that?

[blueprint-bot]

Add comment explaining why we’re not using borders

Preview: docs
Coverage: core | datetime

[giladgray]

🔥 this is so hot!

[giladgray]

dbl check that this is correct

[giladgray]

brief code comments outlining the z-index layers here might be helpful

[giladgray]

explain this huge selector

[giladgray]

explain when to use -overlay vs regular shadows? something about shadows blending with elements beneath

[blueprint-bot]

Add a bunch of explanations in comments

Preview: docs | table
Coverage: core | datetime