Re: css-shapes] Comments on CSS Shapes ED

Alan Stearns wrote:

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

What would the syntax look like?

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

To me, that's a feature: we should not encourage splitting image data
into several locations.

Browsers support alpha channels today, but only when they are part of
the image. I don't see why we should change that now and look for
alpha channels in other places.

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

I'm not sure what you're referring to here -- in my proposal I don't
use any properties to find external resources.

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

But it's easier for authors if they don't have to specify rules at all, no?

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

So, what would your code look like that would produce this example?

  http://dev.w3.org/csswg/css-page-floats/exclusions-dropcap.png


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

But the luminance is in the image, no? If you restrict access to the
luminance you don't have an image.

Also, I don't understand the security implications for alpha data. PNG
images routinly has alpha channels in them and I don't see whey this
is dangerous.

If anything, having a separate property opens another attack
vector -- if a script is able to change the source of the alpha data,
one could percivable hide text by (say) showing black on black.

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

No? Not even for transparent GIFs?

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

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

Received on Friday, 13 September 2013 12:37:38 UTC