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

On 1/12/12 12:49 PM, "Håkon Wium Lie" <howcome@opera.com> wrote:

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

If the alpha channel is designed for the purpose of wrapping text, then I
agree that it would be ideal. But I believe most alpha channels are designed
for compositing, and the ramp from no transparency to full transparency is
often too steep to find an alpha threshold that results in a good text wrap.
That's why a spacing adjustment is sometimes necessary.

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

I think the correct resolution to that issue is described in css3-exclusions
3.2: http://dev.w3.org/csswg/css3-exclusions/#scope-and-effect-of-exclusions

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

The appropriate margin-top is font-dependent, so this runs into the same
issue you have with matching shapes to content.

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

And depending on the font the descender may change, which can result in the
mismatch you're assuming is limited to shapes. If I'm using a shape I can at
least guarantee that it will match the line-height of the content I'm
attempting to exclude.

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

This is good - it looks to me like we're converging a bit on exclusions. The
remaining differences appear to be:

The css3-exclusions spec uses shapes and alpha channels on images to define
exclusions.

Your Plan B uses rendered content and alpha channels on background images to
define exclusions.

I would prefer using alpha channels on either images or background images. I
think that should be an issue in the css3-exclusions spec to use background
images.

Then it's a question of whether we keep shapes and add rendered content,
remove shapes and add rendered content, or remove both and only rely on
alpha channels. Do you agree?

Thanks,

Alan

Received on Thursday, 12 January 2012 21:30:33 UTC