Re: css-shapes] Comments on CSS Shapes ED

On 9/13/13 11:56 AM, "Håkon Wium Lie" <howcome@opera.com> wrote:

>I've reviewed 
>
>   http://dev.w3.org/csswg/css-shapes/
>
>as of today.
>
>My previous review:
>
>  http://lists.w3.org/Archives/Public/www-style/2011Dec/0482.html
>
>resulted in a proposal which is now found here:
>
>  http://dev.w3.org/csswg/css-page-floats/#exclusions-based-on-images
>
>I still think that:
>
> - we should base runaround shapes on the actural rendered content,
>   not external resources. That is, UAs would extract the runaround
>   shapes from the luminence channel of the image (which is always
>   available) or rendered text, and not rely on external alpha
>   channels or shapes. E.g, I'd like to do:
>
>     img.float { float: left; exclude-level: 0.5 }
>
>   This is a simplification and avoids the use of the attr() function,
>   which should not be necessary for common use.

I agree that this should eventually be supported, and I believe the
correct way of supporting this is by using the element() function when it
becomes a widely-supported <image> value. That's one of the reasons I've
postponed this functionality to a later level. Another reason is the
security issues involved in accessing image data (which I believe is one
of the reasons element() is not yet ready).

One problem with the exclude-level proposal is that it defines a wrapping
feature that is not extendable to basic shapes or using a separate
resource. The shape-outside property can be used for all of the proposed
shape-generating mechanisms, and I'd prefer a single property than several
one-off properties that accomplish the same thing.

>
> - the exclusions draft is limited to floats. It's good to start
>   simple, but I would probably include backgrounds, too. E.g.:
>
>     body { background: url(foo.jpg); background-exclude-level: 0.5 }

I agree. I think there should be a way to use the background data to
specify a shape for shape-inside (particularly for the position and repeat
features available for backgrounds). But I decided to postpone
shape-inside for a later draft because I believe the correct way to
specify shape-inside is by reference to exclusion areas and wrapping
contexts. The first step for that is to take Exclusions level 1 to CR. The
work on shape-outside in Shapes level 1 can be done in a separate step.
But I am definitely planning on adding shapes from backgrounds in the
future.

>
> - it's important to be able to run text around other text,
>   especially initial caps. Declaring shapes is a cumbersome and
>   unreliable way to do this -- it requires a tool to create the
>   shape, and the specified font may not be available so the shape
>   turns out to be wrong. Rather than using shapes, I think we should
>   use the rendered content. Like this:
>
>     
>http://dev.w3.org/csswg/css-page-floats/#exclusions-based-on-rendered-cont
>ent

Wrapping around an initial cap does not require a tight wrap against the
rendered content (in most cases, that would be something to avoid). The
detail in a glyph will in most cases be much more fine than the size of
the line boxes being wrapped. So using a basic shape to suggest the
general shape of a glyph just works [1]. Describing a circle with a radius
somewhat larger than the drop cap line-height for wrapping around an 'O'
or a 'D' doesn't require a tool. The example you link to was produced with
a simple 4-sided polygon coded by hand, and in this case I think the
straight edge to wrap around is preferable to having the first line
shortened further by the serif on the 'y'.

>
>I also think that:
>
>  - if there is an alpha channel available in the image, it makes
>    sense to use it. Perhaps the switch could be automatic: if alpha
>    is available, use it; otherwise use the luminence.

For the security implications of wrapping around image data, I think it's
better to have a separate property where we can limit access to the alpha
or luminance data. There are lots of ways that images display just fine
that are very risky when used for shape data. So I don't think that any
sort of automatic magical behavior will work for shapes from images.

>
>So, in summary I suggest:
>
>  - let's do backgrounds in addition to floats

I agree, but I think it needs to be in a future level.

>  - let's base runaround shapes on the actural rendered content, not
>external resources

I agree, but I think this needs to wait for element() to be ready.

>  - let's postpone referring to external resources until a later level

I disagree, because using external resources is a good use case (the
external resource might only define the shape, and not actually be
rendered in the document), and can be done now without waiting for
element().

>  - let's use the alpha channel if it's available in the image itself

That's problematic for the reasons I note above.

Thanks,

Alan

[1] 
http://blogs.adobe.com/webplatform/2013/05/06/adobe-explores-the-future-of-
responsive-digital-layout-with-national-geographic-content/

Received on Friday, 13 September 2013 11:14:42 UTC