Re: [css-shapes] Re: Agenda conf call 02-oct-2013

On 10/2/13 4:16 AM, "Håkon Wium Lie" <howcome@opera.com> wrote:

>Daniel Glazman wrote:
>
> > 3. Shapes LC
> > ------------
> > publish ?
>
>As a WD, fine. As Last Call, no. I've expressed my views in comments
>here:
>
>  http://lists.w3.org/Archives/Public/www-style/2013Sep/0321.html

>  http://lists.w3.org/Archives/Public/www-style/2013Sep/0335.html

>  http://lists.w3.org/Archives/Public/www-style/2013Sep/0342.html

>  http://lists.w3.org/Archives/Public/www-style/2011Dec/0482.html

>
>The comments have had zero impact, it seems.

I'm not sure how you're arriving at this conclusion. I've responded to all
of your comments in detail, and your input has resulted in several changes
to Shapes level 2. As far as I can tell, we're mainly disagreeing on which
shape generation mechanisms to work on first. I've described my reasons
for what is in level 1 and level 2 of shapes several times. Here's another
attempt.

>
>I believe the curently drafted solution breaks several fundamental
>CSS principles. Here's a short summary:
>
>  - the syntax is author-unfriendly -- at least if the author is a
>    human being and not an authoring tool

As Fantasai pointed out yesterday, the circle() function is essentially
equivalent to what we have human beings author for a radial gradient. I'd
argue the shape function is simpler, but I am sympathetic to her argument
that we should have one syntax for similar things. I disagree that the
basic shapes functions are author-unfriendly.

>
>  - the shape describes something which may or may not appear: the
>    downloadable font may or may not be available, bandwidth
>    constraints may have turned font downloading off, and the user may
>    have set preferences that result in altered font sizes. Describing
>    the outline of a certain glyph and using this outline to run text
>    around may therefore result in meaningless designs

If you are constructing a polygon that follows the contours of a
particular glyph, then this could be a problem. But that's not what we've
seen authors do. If you have a drop cap with a capital 'O', it's
sufficient to describe a circle to wrap around it. And the circle is *not*
following the contours of the intended glyph - there's a significant
offset to allow content wrapping around the 'O'. That offset makes the
shape appropriate for fallback glyphs as well. Drop cap wrapping is best
served with a generic curve or line, not hugging to actual glyph contours.

>
>  - style sheets will be content- and glyph-specific with little
>    chance for reuse

I'd argue that a generic shape is more re-usable than what you have to do
to make rendered contours a usable wrap solution. In your coding of the
lowercase drop cap example you're adding content-specific margins which
may not be reusable in another situation.

>
>  - there may be security problems with having glyph-specific style
>    Sheets

If you can demonstrate what those security problems might be, I'd be glad
to work on addressing them. What has been demonstrated and discussed in
the working group is the security problem in using rendered content.
That's one reason your version of shapes is in level 2.

>
>  - referring to the alpha channel of another image rather than the
>    image itself seems unnecessarily complex

The main use case for using a separate image is where the image itself is
not actually being displayed in the element. And while most cases of shape
from image will use the same image as the one that's displayed, there are
cases where the original image cannot be modified and the image data it
contains is not usable as a shape. Allowing a separate image file that
contains only the shape information lets you work around that limitation.

>
>I believe there are much simpler and author-friedly ways to achieve the
>same results, as discussed here:
>
>  http://dev.w3.org/csswg/css-page-floats/#exclusions-based-on-images

>
>I suggest that the CSS WG issue a call for comments to the web
>authoring community about how to best achieve such effects in the best
>possible way.
>
>Cheers,
>
>-h&kon
>              Håkon Wium Lie                          CTO °þe®ª
>howcome@opera.com                  http://people.opera.com/howcome

>
>

Received on Wednesday, 2 October 2013 15:01:16 UTC