4 ms·

Here's an animated version with some transparency https://codepen.io/anon/pen/PaMVYX?editors=0100 https://codepen.io/anon/pen/PaMVYX?editors=0100 The root is

Here's an animated version with some transparency https://codepen.io/anon/pen/PaMVYX?editors=0100 https://codepen.io/anon/pen/PaMVYX?editors=0100 The root issue is that the browsers are being asked to draw a line that's 100px in from the edge of a 100px box -- it's an impossible task, so there's no perfect solution. This CSS test suite http://test.csswg.org/suites/css-ui-3_dev/nightly-unstable/xhtml1print/outline-013.xht http://test.csswg.org/suites/css-ui-3_dev/nightly-unstable/x... suggests that browsers should treat it as though it were the largest offset that made sense at the current outline width, giving you https://codepen.io/pjwdev/pen/vrovPR?editors=0100 https://codepen.io/pjwdev/pen/vrovPR?editors=0100 Safari achieves this if the border is the same colour the whole way around, but doesn't get the individual sides in a sensible arrangement. Edge doesn't match the test, but it does another reasonable thing -- it takes the offset as a given, and uses the biggest outline width that makes sense. Chrome and firefox...

gsnedders 8y ago
The negative value case is: > Negative values must cause the outline to shrink into the border box. Both the height and the width of outside of the shape drawn by the outline should not become smaller than twice the computed value of the outline-width property, to make sure that an outline can be rendered even with large negative values. User Agents should apply this constraint independently in each dimension. If the outline is drawn as multiple disconnected shapes, this constraint applies to each shape separately. There's a lot of RFC 2119 SHOULD there, unfortunately.