Box-shadow used as border should be inset. Otherwise they may be cropped

[BertrandPodevin]

IF a component use a box-shadow: 0 0 0 1px #color; as a border, this shadow should also be defined as inset. Otherwise the shadow overflow it's box and could be cropped by it's parents.

Example with a callout : the laterals shadows are cropped.

That would'nt be the case with an inset shadow :

[jeremie-lucca]

@BertrandPodevin It's a requirement from design specs to keep the space inside components not affected by borders. It works the same way on every components, like buttons, textfields, etc.

We already discussed it with Clément but it's not going to change for now, so the best approach for now is to avoid to hide overflow when possible.

[BertrandPodevin]

@jeremie-lucca Avoiding using overflow is not always possibility :/

Which leaves 4 options :

• Not using this element at all when in an overflow context :(
• Keep a super ugly cropped element :(
• Adding artifical margin around the element to keep it uncropped but break alignments with other elements
• Overriding the box shadow, but because there is not box-shadow-inset property in css we need to override the whole box-shadows, and for every states (:hover, :focus...)

An element designed to take 100% of it's parent width should not casualy take 100% + 2px without offering a fallback There should be at least a mod or a css vars to allow a clean override when needed.

Ex box-shadow: var(--component-box-shadow-inset, ) 0px 0px 0px 1px #000000; which can be overrided easily if needed .myComponent {--component-box-shadow-inset: inset;}

[BertrandPodevin]

Here's a comparative between LF16 & 17 https://codepen.io/bertrandpodevin/pen/PogNxPN

[jeremie-lucca]

@BertrandPodevin Could you share some examples/mockups where you cannot bypass hidden overflow ? May concrete examples could convince Clément to use inside borders. If not, we'll consider fallbacks 🙂

[BertrandPodevin]

I don't think that there are designs or mockups that required to combine outset shadow component + overflow.

On the other hand this change (border -> shadow) is breaking for existing screens build without this technical constraint in mind. Some TA screens and our pwa are now exposed to this.

A simple fallback will do the trick.

[vvalentin-lucca]

The same problem can arise when it comes to displaying the outline for keyboard navigation.

You can get away with a negative margin combined with padding of the same value, if necessary.