- From: Alan Stearns <stearns@adobe.com>
- Date: Fri, 16 Oct 2015 19:06:08 +0000
- To: "Eric A. Meyer" <eric@meyerweb.com>, CSS WG <www-style@w3.org>
On 10/15/15, 8:24 PM, "Eric A. Meyer" <eric@meyerweb.com> wrote: >I've been testing shapes recently[1] and I feel like the way shapes are >confined to the margin box of the element is unintuitive, but more to >the point, some of the examples seem to imply different behavior than >what the spec defines. Unless of course I completely misunderstood what >the spec says, though if I did, the Chrome team came to the same >conclusion. > >First off, let me quote from section 2 of ><http://www.w3.org/TR/css-shapes-1/>: > > "When a shape is used to define a float area, the shape is clipped >to the float’s margin box. > In other words, a shape can only ever reduce a float area, not >increase it." > >So that means if I do something like this, the shape will still be 100px >by 100px: > > img {width: 50px; height: 50px; margin: 25px; > shape-outside: polygon(0 0, 200px 0, 200px 200px, 0 200px);} > >First off, I object to this a little bit on general principles: if I >want a shape to stick out of the element's margin box, that seems like >it should be allowed. It seems like this should work (and it did in the original design), but after some discussion we arrived at the margin box clipping for a few reasons. One is that we *have* to clip at the top of the margin box. A shape-outside on a float cannot affect preceding lines. So it’s a simpler story to clip all around the box than have to explain why we’re only clipping at the top. >Suppose I have a raster image of a circle, where >the circle's edge touches the edges of the image. If I set a circle >shape that's larger than the visible circle, like so: > > img {width: 50px; height: 50px; margin: 0; > shape-outside: circle(60px at 50% 50%);} > >…then any text flowing past it will still jam up against the side of >the circle, because the shape is clipped on each side. The only way for >me to make the text flow nicely around the curve is to enlarge either >the image or the image's margins to encompass the shape. This is true whether you have a shape or not. Without shape-outside, you still need a margin to keep things from jamming up against the side of the circle. As you note, this makes the fallback story a bit better, because you have to add that margin even when testing your design in a shape-enabled browser. So that’s another reason we decided to clip. > >But, okay. It's arguable that this is a good thing, in general: it >prevents the fallback in shape-blind browsers from having text jammed up >against floats where an author relied on shapes to push away the text. >We could probably devise scenarios in which that would not be an >advantage as well, but never mind. If there is a scenario where clipping to the margin box makes fallback worse, I’d like to explore it. > >The real problem is that Example 11 is fairly misleading about this >behavior, to my eyes. Looking at the figure in Example 11, I would >expect the image edges of the CSS logo to be pretty close to touching >the outermost points of the dotted line, with maybe a few pixels extra. >But the 'shape-margin: 35px' pushes all the text away 35 pixels. Sure, >we could assume that there's more image or a right margin large enough >to cover the shape-margin, but this is not what I would assume given the >visual and the CSS that accompanies it. Yes, now that you point this out I agree the example is misleading. It should probably show the image bounds and have two renderings - the first showing how the shape is clipped with no margin applied, and a second showing the intended shape with an adequate margin applied. > >I also feel that Example 10, in not showing the edges of the float on >which the polygon shape has been hung, leaves readers without a sense of >the limits of shapes and their margins. (Which, yes, the shape margin >is defined to create a whole new shape, but most people won't think of >it that way, just as almost nobody thinks of an element as being resized >by its margins.) Here I intended the 100x100px sizing in the prose to give an idea of the bounds in which the shape is being drawn. Perhaps there should be width and height declarations in the code? > >In my ideal world, shapes would not be clipped by the margin box of the >float, That would make the examples not misleading, and also be more >intuitive in general, since there's no obvious reason why shapes should >be clipped. This could be partially accomplished by defining the >float's margin box to expand to cover the outermost points of the new >shape defined by the shape-margin, or wholly accomplished by simply >dropping the clipping behavior. One last reason for clipping that I recall is that it *vastly* simplified float stacking when shapes are involved. Floats with shapes still stack using their margin boxes, so keeping the shape within the margin box means that stacking a float always keeps it on the same line or moves it down. If the margin box can be smaller than the shape, then float stacking might need to consider moving a stacked float up. Expanding a float’s margin box to accommodate a shape (with or without shape-margin) could avoid that problem, but it does complicate how margin boxes are constructed. I’d rather keep the margin box simple, and not have to explain how it’s affected by shape-outside and shape-margin. We’d also have cycles to deal with when the shape is *based* on the margin box. > >Failing that, I strongly recommend that Examples 10 and 11 be altered to >make visually clear where the floats' margin edges are placed, likely >with the addition of a declaration in Example 11. This would be my preference. If you’re interested in making these changes, I’m all for it. But I can likely get to it some time in November after TPAC. > >I also (very) strongly recommend adding a new example that explicitly >demonstrates margin-box shape clipping, probably best placed in section >2. > >I'm willing to create the clarified figures and the new example, if >people agree with my reading of the specification and belief that >clarification is needed. > > >[1] See the shape-related links on ><http://meyerweb.com/eric/css/tests/css3/>. > >-- >Eric A. Meyer - http://meyerweb.com/ > >
Received on Friday, 16 October 2015 19:06:39 UTC