Too much left padding on loading buttons

Now that banners have merged, the z-index that's included by default is trolling us in a few places. Do we need it? Should we consider removing it?

See: https://trello.com/c/UNXO7tNJ/153-z-index-issues-on-the-company-page

I've found weird bug when collapsing accordion panes in .s-sidebarwidget component. Chrome just freezes. Confirmed with bunch of folks. It works fine in Safari though.

To Reproduce

1. Go to Sidebar Widget Accordions section.
2. Try to collapse pane.
3. Chrome freezes.

Desktop:

• OS: macOS 10.13.4
• Browser: Chrome 67.0.3396.99

Problem
Our current cards should be updated with an example for clickable cards, where the entire .s-card is linked.

Solution
Codified suggestions on how to design a clickable card.

Describe alternatives you've considered

1. Adding an extra link inside the card:

2. Hyperlinking the card title:

3. Do something more like a sidebar widget:

Also may be worth creating some guidelines for when and how to use cards, like this.

Liquid Warning: Liquid syntax error (line 184): Expected end_of_string but found pipe in "item in site.data.banners.access | sort" in components/banners.html
1:00:39 PM:     Liquid Warning: Liquid syntax error (line 186): Unexpected character " in "{{ item.item | replace: "'", """ }}" in components/banners.html

This bug isn't a showstopper. The site compiles without issue, but this warning shows up and could stand to be fixed. @hellohynes, do you know what this is referring to?

• Move all color stops over from previous website
• List LESS, HEX, RGB, and atomic helper classes for all color stops
• Update colors? There were discussions about updating the colors. Is this a V2?
• Add gradients
• Preferred color combinations?
• Contrast rules?
• Add Pantone and CYMK colors?

We've updated a number of older documentation pages recently (grid, buttons), and the type documentation needs to be updated. Specifically:

• List available classes in data tables

I've built few forms where an input (.s-input) was in the same line as button element (.s-btn). They were usually misaligned because of being different size and required some naughty overwriting.

Additionally, textfields have some extra margin (2px) on top and bottom, whereas buttons do not.

Whether we need all those sizes for both elements is of course questionable, but it would be great to at least have them unified in terms of sizing, especially they are often used combined, next to each other.

I was reading this article from GOV.UK about how they set up their type and spacing. One tidbit in there is that they provide override classes using .govuk-!-, which I didn't know were a thing.

What do people think about providing normal and important atomic classes for Stacks? This would allow developers to use .show() and .hide() for jQuery (using .d-none overrides any local styles jQuery applies). Is that too much overhead? Do we default to adding !important and provided non-important version as needed?

Stacks establishes specific sizes for buttons:

Yet inputs don't establish similar sizing, but instead require you to apply the appropriate .fs-[textname] class name to the label and input.

Shouldn't we use the same approach for both buttons and inputs?

Our toast notifications don't appear centered horizontally at smaller viewports.

While the .fl# classes work fine, they include an auto value for the width, which means items will resize smaller than their normal size. An example of this would be an icon which we don't want to be smaller than 18px. Applying fl0 would still shrink the icon smaller than 18px if the space for it is smaller.

Describe the bug
A typo in the line 27 of said file

To Reproduce
Go https://stackoverflow.design/base/box-sizing, first table, first row, third column, says "browswer" instead of browser

Expected behavior
It saying "browser" instead

Screenshots

Additional context
Tried to PR, but no permission :-)

https://deploy-preview-9--stacks.netlify.com/email/templates#promotional

In Promotional - Not so Good For section

"Repeatative" should be spelled "Repetitive"
@TedGoas

Initially posted by Piper in the Stacks Slack room:

I have some concerns regarding .s-card. The hover state on the cards isn’t very recognizable. I’m not really sure why a card wouldn’t need an obvious hover state, to be honest. It either needs a hover state (and should be obvious) or it doesn’t.

Anywho, I ran into the cards on this page a couple weeks ago and was excited that there seemed to be some sort of alternate option for cards that needed a more obvious hover state:
https://stackoverflow.com/jobs/salary/results?l=Columbus%2c+OH%2c+United+States&ed=0&ex=2&ff=1&dr%5B0%5D=DataScientist&tl%5B0%5D=

I went looking at stacks to find how I could implement the shadow on hover and the way the documentation is written, it seems like I can do such a thing

When applying a .bs-* class with a .s-card component, a :hover style is added to the base .bs-* box shadow.

If the above statement is true, then why would there be a .bs-hover class? Well, I was hoping that it would do what the class says it would do… apply a border-shadow on hover.
But apparently this class is attached to the .bs-* classes, which is silly because the documentation says there already will be a shadow increase on hover.

Basically, I’m asking that you move the .bs-hover be attached to only the .s-card class. I can think of at least 3 situations where this would be useful. Including the example I sent you earlier which is currently using custom CSS to implement the shadow.

We need to add in a basic tooltip style like so:

This would be similar to popups, but would use the title="" attribute for content instead of Javascript.

Right now we have atomic min/max-width classes only for some (seemingly arbitrary, although I assume there's reasoning behind them) fixed widths, with the exception of 100%.

Especially in a responsive world, percentage-based is something I need much more often than fixed values.

What do we think about adding those?

There would be a bit of naming discussions required. Right now .wmx1 through wmx12 refer to ~105px steps, while .wmx100 refers to a percentage. So there's precedent for mixing "units" here.

Since a 10% min/max width is probably rarely helpful, we probably wouldn't have overlap if we go with, for example, .wmx25, .wmx33, .wmx50, .wmx67, .wmx75, or something like that.

Or we could be explicit like under my original suggestion for the naming scheme, e.g .wmx-50pc -- but we haven't done that anywhere else.

Any thoughts?

How can/should we send email at Stack Overflow?
There are a few ways to do it depending on the team, audience, and context. Anita has a Google Doc that no one really reads and would love to include it here so everything email is in one place.

Describe the solution you'd like
Anita to make a Stacks version of her Google Doc so it may be translated into a section under Email.

I was referred here from Meta.SE. The new radio menu for flag comments has two types of text, a larger bold label and a smaller (gray?) description of what that option is for. I find the description hard to read. A description sounds like something that should be a "generally normal" size, not like a footnote or a subscript where we expect things to be smaller. The developer there told me that the description is using the .s-description (element? class? style?) and I should make my request here.

There seem to be two issues here, and it's possible that addressing either one of them would solve the problem (or maybe it needs both):

1. The text is very small.
2. The text is light. I think it's gray not black, and the face is not a "heavy" one.

I don't know enough about Stacks to be able to make better suggestions or explore alternatives, sorry.

Here's the screenshot I posted over on Meta:

There's some inconsistency in color values for @black-500 color in that table.

• Little square on the left returns hex value #6A737C. It's coming from.bg-black-500 class so I assume it's correct.
• HEX value in table is #6A7E7C – it should be 3 instead of E.
• RGB value in table is 108,115,112 – it should be 106,115,124. It's weird because it's different from original value and also from corrupted value in HEX column.

I haven't noticed that in other colors. But I'm not sure if those values were entered manually or generated with some magic in backend/js. But if it's latter then more colors might be corrupted.

https://deploy-preview-9--stacks.netlify.com/email/components

Foreground images section

All email client should be clients

Describe the bug
The modal dialog appears in the top left corner

To Reproduce
Open a modal dialog (i.e. the comment flag box)

Expected behavior
The dialog should appear in the center.

Screenshots

Desktop (please complete the following information):

• OS: Windows 7
• Browser: Waterfox
• Version: 56.2.2

Additional context
It goes to the center if the viewport is resized in any way.

The descenders within our .s-inputs are being cut off at various sizes. This is observed in Safari on High Sierra.

When debugging a print layout, it may be beneficial to include some utilities for printing. Oftentimes, with an atomic layout, we aren't actually giving an overall class to anything:

<div class="p12 bg-black-050 bar-md">
    <a class="s-btn s-btn__primary">Sign up</a>
</div>

In production, this markup is valid. If we want to hide this markup for printing layouts, it doesn't make much sense to target s-btn or its parent and apply display: none;, and it's also tedious to write a new class to target print-only styles.

Perhaps we allow for p:d-none meaning "Don't allow this element to appear in print layouts." Further, we could apply p:d-block if we only want something to show when printed. 🤔

Creating variables in Stacks is a little more complicated because of the dynamic and static LESS file split. A short explanation for how to create variables should be added to Stacks.

As observed on the Teams join workflow, it appears that inputs with s-input applied are inheriting the OS-level fonts, and not ff-sans as intended. I think we need to add our standard fonts to s-inputs, text areas, etc.

Sadly, San Francisco looks soooo good here, but it's not intended in this case.

We've updated a number of older documentation pages recently (grid, buttons), and the inputs documentation could use some cleanup. Specifically:

• List available classes in data tables
• Better examples of error states
• Add accessibility documentation
• Resolve sizing and spacing inconsistencies between inputs, select menus, and buttons

I use min-width: 0; quite a lot (to prevent flex items from overflowing their container), but there's no atomic class for it yet. Any particular reason for that, or is it okay if I add it?

Add in tags into the Stacks system.

We're planning on migrating to github.com. Ok, how?

As reported by Dean, there are contexts where buttons need to appear as links. We can make links look like buttons, and we should support the corollary.

Right now the mobile less has it's own input/form Less files. We should test our current styles to make sure they're mobile friendly as well so we can properly deprecate the mobile skins.

Maybe something @ludwiczakpawel can help within a few weeks?

Goal
This page primarily serves Stack Overflow Designers and Developers. Based on their needs, this page should mention (in order of importance):

1. Templates and where to find them.
2. Components and patterns.
3. Any rules pertaining to a specific use case.

Design
Wireframe in Figma

While working on the documentation site itself, I use a snippet like so:

{% header {element: 'h2', text: 'When should I deviate from these guidelines?'} %}

But it produces this 👇

The i should be uppercase, as it is in the snippet.

Pawel pointed out the current Team icon is padding-based. Since letters are shaped differently, this can make the icon seem "off."

Making it height/width based would be better.

Is your feature request related to a problem? Please describe.
Tabs pile on top of each other when viewport is too small

Describe the solution you'd like
If the tab menu is oriented horizontally, maintain tabs within a row and allow users to scroll through them

Describe alternatives you've considered
I worked on this a bit with @Courtny today. Here's a CodePen of my work: https://codepen.io/hellohynes/pen/MBZKde

If you want to wrap a word with a lot of letters within it, .ww-break-word won't work. Instead you need to use word-break: break-word;

We need to create some word-break atomic classes.

Problem

Our current tables are don't support complex data sets out of the box. Alone, s-table is pretty barebones. Modifiers can be used to push text around, but there aren't codified patterns or recommendations for tables with more complex data. Eg. more than words, data that can be sorted or acted upon. We're currently going at it piecemeal and @UXPiper and I would like to not do that anymore.

Proposal

Codify a few more patterns to support some use cases that we've come up against with more complex data tables.

What to include:

• Improved column headers
• Sortable column headers
• Actions in table cells, and how to display them (eg. in a popover menu or not)
• Graphics in table cells (icons, badges, mini-graphs, etc.)
• Blank state (related to this)

What not to include:

• Title and text around the table.
• Search, sorting, and filtering
• Pagination, show more/less rows

Examples in the wild:

Document all the variable and mixins available within Stacks and for SE Community theming.

Now that we've switched to a responsive layout in our documentation, the presentation on banners is messed up.

Following a conversation with an internal dev, I think we should be bundling our email templates into a package and versioning them properly. This way devs can add Stacks email as a dependency and receive the correct template. I'm happy to set this up, so I've assigned it to myself.

If this doesn't make any sense, let's talk about it.

In the spirit of atomic styling, we should add a class for bg-transparent.

PostCSS seems to be adding too many vendor prefixes. Example we shouldn't need any vendor prefix for box-shadow and transform.

There are a lot of them in the templates. They look like code comments but most times hold the email together in Windows Outlook. We should explain what's going on so folks know what these things are when they see them.

Feels like an FAQ.

We have a few different styles.

This ☝️ looks good, but it and it's children are styled using utility classes. When someone changes the style, it doesn't cascade to the others.

Would be nice to have one or two parent classes that take care of everything inside and "just work." I'd love not to have to think about this.

The preview of .s-tag is pulling in a border-radius defined in Stacks web css, but currently tags don't have a border-radius in email. We should either:

1. Add border radius to email, or
2. Remove the border-radius from the preview.

Problem
Font sizes become unruly when responding to smaller screen size. This especially true at sm sizes where desktop sized headlines are visually too large for the layouts. Different scales work better for different screen sizes, and it's my hope Stacks can intelligently respond to this as a system.

Solution I'd like
It would be very useful to have some baked in responsive font scaling when hitting certain breakpoints. This could manifest itself as a Stacks baked in modular type scaling (I explore this below) and/or the inclusion of some optional utility classes like sm:text-smaller, sm:text-larger. The utility classes would take the base font size for that type style and scale accordingly.

Thoughts on calculating modular scaling
On a small screen, heading sizes should probably be more uniform; a large screen has room for greater variation. We can use a modular typographic technique to fluidly transition between different scales. Maybe we could pick a ratio for small screens and a different ratio for large screens, and then work out the minimum and maximum font sizes for each heading level.

To calculate the modular scale, take the base font size and multiply it by the desired ratio to get larger numbers. For smaller numbers, divide. Repeat this process with subsequent results to get each required step in the scale:

LARGER

• 1em × 1.125em = 1.125em
• 1.125em × 1.125em = 1.266em
• 1.266em × 1.125em = 1.424em
• 1.424em × 1.125em = 1.602em

SMALLER

• 1em ÷ 1.125em = 0.889em
• 0.889em ÷ 1.125em = 0.790em
• 0.790em ÷ 1.125em = 0.702em
• 0.702em ÷ 1.125em = 0.624em

For this example, say we use 1.125 as our minimum scale and do the same calculations for 1.250 as our maximum scale. We’d then apply different steps in the scale to our heading levels.

• Minimum scale: 1.125
• Maximum scale: 1.250

Using these numbers, perhaps there could be some Stacks definitions that deal with the initial scaling.

fs-body1-min
fs-body1-max

I'll try to put together a demonstration soon.

Resources
Type Scale
Modular Scale

[minor] The overflow-x causes a gap between long code blocks and it's example. ⤵