Re: [css3-ui] what to do if outline-offset is sufficiently negative (issue 38)

> On 24 Nov 2014, at 17:53, Florian Rivoal <florian@rivoal.net> wrote:
> 
> Raised here:
> https://wiki.csswg.org/spec/css3-ui#issue38
> 
> about this:
> http://dev.w3.org/csswg/css-ui/#outline-offset
> 
> The spec does not forbid negative values for outline-offset. In general this is fine, but if the negative value is large enough (in absolute value), the sides of the outline will meet in the middle of the box and pass each other, giving confusing and uninteroperable results.

So, I got an action during the last telecon to define a sensible (for users) and simple (for implementers) limit to negative values of the outline-offset properties.

There are wild differences between implementations of the outline properties (I’ll start another thread about that, to see if this is all “quality of implementation” matter, or if we should try and narrow it down a bit), but I tried to come up with a rule that would work regardless, and remain reasonable even if we work out the underlying interop differences.

First, a couple of examples to illustrate the landscape we’re in. Be sure to view in all browsers (including presto, which is far from the worst behaved here), as there are significant differences between all of them (except blink and webkit which have not diverged about this):

http://jsbin.com/niregineyo/1/watch?output
http://jsbin.com/manuxogute/1/watch?output
http://jsbin.com/lenakukowu/1/watch?output
http://jsbin.com/wivujemaco/1/watch?output
http://jsbin.com/roladubafe/1/watch?output

Here goes my attempt at a sentence to both clarify that negative values are allowed, and to set a limit to their effect:

“Specifying a negative values is allowed, and causes the outline to shrink into the border box. However, in order to make sure that the outline is always visible even with large negative values, neither the height nor the width of the shape drawn by the outline may become smaller than twice the computed value of the outline-width property. User Agents must apply this constraint separately in each dimension. If the outline is drawn as several shapes not connected with each other, this constraint applies to each shape separately.”

Notes:

1) This does not affect the computed value, as you have to do layout before you can find where the limit is.

2) We can have a few variants on this definition my changing the “must” in “User Agents must apply this contraint” into a “may”, or by replacing that sentence by “If this constraint applies in one dimension, the shape must not be further shrunk in the other dimension either”.

The difference is:
- MUST => outlines in their most shrunk form are reduced to a square whose sides are 2 * outline-width
- MUST NOT => outlines in the most shrunk form are reduced to a rectangle, whose short side is 2 * outline-width, and long side depends on the original shape.
- MAY => UAs can pick, and possibly mix and match depending on the shape of what they’re shrinking.

3) Another variant which could make sense if we go with the MUST NOT alternative above is to change the last sentence to “If the outline is […], as soon as one shape reaches its smallest allowed size, all shapes must stop from shrinking”.

4) This definition does not allow for one aspect of Presto’s behaviour: When drawing the outline around an element with overflowing children, presto will draw a shape which is the union of the rectangle following the border box of the element and of the rectangles following the border box of each overflowing child. The offset (if any) is only applied to the rectangle around the element, not to those around the overflowing children. If we want to allow that, we could allow the UA to impose additional constraints on how munch each part of the outline can be shrunk, but I am not convinced this is worth allowing.

Received on Tuesday, 2 December 2014 17:40:37 UTC