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

Alan Stearns wrote:

 > >    http://dev.w3.org/csswg/css3-gcpm/#exclusions

 > 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. 

When the alpha-channel is used to determine the exclusion zone, it can
express -- with greater detail than any property -- where the content
is allowed and not allowed. In these cases, no new properties are needed.

 > 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).

I agree that spacing behavor must be described somehow, and in this
case we don't have an alpha channel to use. This is noted in issue 13:
"Some kind of spacing behavior must be defined." We could,
perceivably, use some kinde of kerning parameter from the font in
question. But this may be unavailable or hard to extract. So a
property may be easier. We would only need one property, no? 

 > 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', 

Yes. In order to prevent this, a negative margin-top on the float
would be necessary.

 > and the smaller text to wrap both to the left and right of the
 > 'y' descender.

That's less clear; the #dropcaps element is floated to the left so
other content would normally appear on the right side. The descender
of the 'y' glyph may, as such, be a barrier to entry.

 > 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.

I can see issues with using the rendered content; we may ned to have
a way to say that islands inside the image cannot be used etc. But
defining a shape isn't a solution either. There's an inherent
disconnect between shapes (which are expressed textually in a style
sheet) and an image/font (which probably reside in a URL somewhere).
Combining the shape with the image/font may not succeed. The image may
be unavailable or may have been changed. The user may have increased
the size of the text, in which case the shape and the text do not
match any longer.

So, I think it's better to use the rendered content & alpha channels
as the basis for exclusions.

-h&kon
              Håkon Wium Lie                          CTO °þe®ª
howcome@opera.com                  http://people.opera.com/howcome

Received on Thursday, 12 January 2012 20:51:05 UTC