- From: Håkon Wium Lie <howcome@opera.com>
- Date: Fri, 13 Sep 2013 14:36:56 +0200
- To: Alan Stearns <stearns@adobe.com>
- Cc: www-style@w3.org
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