Re: [css3-exclusions][css3-gcpm] Plan B exclusions

On 12/27/11 6:04 AM, "Håkon Wium Lie" <howcome@opera.com> wrote:

> As expressed earlier in this forum [1][2][3], I believe in regions and
> exclusions, but I have some ideas about how to better express them in
> CSS. Others have expressed similar concerns [4][5][6][7]. Based on
> this, I've written up an alternative proposal and added it to the GCPM
> editor's draft [8]:
> 
>    http://dev.w3.org/csswg/css3-gcpm/#exclusions
>    http://dev.w3.org/csswg/css3-gcpm/#regions
> 
> For comparison purposes, I refer to the GCPM-based proposal as Plan B,
> and the set of proposals [9][10][11] championed by Microsoft and Adobe
> as "Plan A". 

(splitting out the regions section to focus on exclusions)

> I'd also like to propose some changes in the way we create exclusions:
> 
>  (5) in plan A, style sheets may refer to images that establish
>  exclusion zones. This is handy. But I suggest using background images
>  for this; we've spent considerable efforts making background images
>  powerful and flexible and I think they will be a good device for
>  exclusions. For example, background images can be repeating so text
>  may flow around a (say) repeating zig-zag pattern. This is listed as
>  use case for plan A, but left TBD [12].
> 
>  (6) I'm not convinced we should target exclusions based on shapes.
>  While shapes have obvious benefits in being compact representations
>  without the need for external objects, I'd prefer to wait with shaped
>  exclusions until shapes are added to CSS in general. For example one
>  may want to describe borders using shapes in the future. However,
>  I've included shapes in plan B to show how it's possible.
> 
>  (7) A common use case for exclusions is text that runs around big
>  letters/words. In plan A, this is addressed by describing the
>  exclusion zone with a shape. However, the shape may change if a
>  certain font isn't available, or if the user changes the font size.
>  Therefore, I think it's better to base exclusions on the rendered
>  content: the big letters that actually appear in front of the user.
> 
> Plan B is not a fully baked proposal. At this stage it mostly consists
> of use cases from Plan A, recast as columns and page floats from
> css3-multicol and css3-gcpm. I've borrowed liberally from the graphics
> found in the plan A use cases, and most examples are expressible in a
> few lines of CSS code. I happen to like this code, and I'm eager to
> hear what others think.
> 
> [1] http://lists.w3.org/Archives/Public/www-style/2011Aug/0259.html
> [2] http://lists.w3.org/Archives/Public/www-style/2011Oct/0781.html
> [3] http://lists.w3.org/Archives/Public/www-style/2011Dec/0251.html
> [4] http://lists.w3.org/Archives/Public/www-style/2011Dec/0448.html
> [5] http://lists.w3.org/Archives/Public/www-style/2011Dec/0456.html
> [6] http://lists.w3.org/Archives/Public/www-style/2011Dec/0457.html
> [7] http://lists.w3.org/Archives/Public/www-style/2011Dec/0459.html
> [8] http://dev.w3.org/csswg/css3-gcpm/
> [9] http://www.w3.org/TR/css3-regions/
> [10] http://www.w3.org/TR/css3-exclusions/
> [11] http://www.interoperabilitybridges.com/css3-floats/OriginalSubmition.html
> [12] http://wiki.csswg.org/ideas/css3-exclusions-use-cases

I like the idea of using the alpha channel in background images to define
exclusions, particularly being able to use the repeat functionality. I'm
also intrigued by the idea of determining an exclusion shape from rendered
content (and a little fearful of the performance implications). But I do not
think a single threshold property is sufficient in either case.

A. Padding and margins are usually needed to ensure that inline content does
not touch or slightly overlap the shape. Given how the car image in 13.4 is
likely masked, I'd expect the text to end up un-readably close to the edge
of the car unless you allow for some margins on the shape. Similarly, the
drop cap example in 13.5 does not demonstrate how the gap between the large
'y' and the smaller text is achieved. I think we need exclusion margins (and
padding for inclusions).

B. I should be able to use the shape to either include or exclude content,
and also have the options defined in wrap-flow. A single threshold property
is not enough to determine how inline content is going to interact with the
shape.

C. The wrap shape needed sometimes does not match the rendered content or
alpha level of an image. Here are two examples, the first from the drop cap
case you've borrowed:

1. In the drop cap case using the single plan B property, I'd actually
expect the first line of smaller text to start just to the right of the
large 'M', and the smaller text to wrap both to the left and right of the
'y' descender. Depending on the size of the text there might be additional
places the inline content could fill. The intent is not to wrap around only
the rendered content (which has these unfortunate holes), but to define a
diagonal line for the smaller text to follow. Getting that line to match the
rendered content can be tricky, but only using the rendered content is not a
solution for this case.

2. The alpha mask in an image is not always what's needed for a wrap shape.
Depending on the source, images can have complicated masks with holes or
accidental extrusions. In cases like these I'd rather define a shape in CSS
instead of depending on what an image provides. The alpha mask isn't always
intended to be a wrap shape, and I don't think we should require authors to
fiddle with alpha masks in their images in order to get the wrap effect they
want in CSS (though if they want to do this, I'm all for it).

So it's my opinion that shapes are essential to exclusions, and most of the
rest of the current exclusions spec properties are also necessary. I'm
interested in how we might extend the current spec to include background
images and rendered content shapes, but I do not see how plan B makes
anything easier for exclusions.

Thanks,

Alan

Received on Friday, 6 January 2012 21:51:37 UTC