W3C home > Mailing lists > Public > www-style@w3.org > March 2014

Re: [css-shapes] new Last Call Working Draft published

From: Håkon Wium Lie <howcome@opera.com>
Date: Wed, 5 Mar 2014 21:20:29 +0100
Message-ID: <21271.34573.891222.673933@gargle.gargle.HOWL>
To: Alan Stearns <stearns@adobe.com>
Cc: "www-style\@w3.org" <www-style@w3.org>
Alan Stearns wrote:

 > > > The CSS WG has published a Last Call Working Draft of the CSS Shapes
 > > > Module Level 1:
 > > > 
 > > >     http://www.w3.org/TR/2014/WD-css-shapes-1-20140211/
 > >
 > >The draft, as it stands, has issues.
 > >
 > >First, by describing the shape of an element in the style sheet,
 > >content and presentation is mixed. If images had been referred to in
 > >the style sheet (like background images are), this would probably have
 > >been ok, but when the elements are HTML elements, CSS should not
 > >describe their shapes.
 > 
 > I don’t quite understand this. CSS describes the displayed shape of
 > elements using tools like border-radius. 

Border-radius can be applied to many types of images. For
example, photos often came with rounded corners in the old days, and
one can easily achieve that retro feeling with a line in the style sheet.

  img { border-radius: 1em }

But shapes are different, by a magnitude. Take, for example, the blue
triangle example you use in the draft -- you couldn't take the CSS
code:

   shape-outside: polygon(50px 0px, 100px 100px, 0px 100px);

an apply it to other images -- that code is tied to that specific
image. Used for drop-cap effects, you would have to write different
style snippets for (almost) all letters in the alphabet. There's very
little code reuse.

 > One use case of shape-outside is
 > to use that same shape from CSS to affect wrapping behavior. The basic
 > shape functions give CSS more expressivity on how an element is rendered
 > (with clip-path) and how wrapping occurs. These capabilities seem to me to
 > be properly placed in CSS.
 > 
 > >Second, the draft uses dummy DIV elements to achive presentational
 > >effects. This problem is discussed at some length here:
 > >
 > >  http://alistapart.com/blog/post/css-regions-considered-harmful
 > 
 > There is a single example that uses divs

Yes, the first example.

 > and for the purposes of the example I don’t see a problem with the
 > markup.

You never had a problem with dummy DIVs, I believe :)

 > But I could change the content to use <p> and the floats to use
 > ::before and ::after, if you like.

Changing the example without changing the underlying functionality
doesn't help much.

 > >Third, there is a way to refer to a shape in the image itself, as
 > >opposed to writing poloygons in CSS. That's good. However, only the
 > >alpha channel of the image can be used. I believe it is much more
 > >natural for authors to use the visible luminance of the image, and
 > >this option should be added. The current model favors authoring tools.
 > 
 > We’ve discussed this before, and luminance could be added in a future
 > level, along with additional shape mechanisms currently described in the
 > shapes level 2 skeleton draft. I would prefer to keep level 1 as small as
 > possible so that we can implement and iterate.

If simplicity is a goal, we should remove reliance on alpha
channels and only consider luminance. All picture formats have
luminance, our cameras record luminance and not alpha channels, it's
easiser for humans to see luminance (alpha channels require tools),
and the size of images without the alpha channel is smaller.

To further simplify the spec, we could drop expressing shapes in CSS
and only rely on the shapes found in the content itself. 

Then we would have a really simple specification, one that all could
support.

-h&kon
              Håkon Wium Lie                          CTO °þe®ª
howcome@opera.com                  http://people.opera.com/howcome
Received on Wednesday, 5 March 2014 20:21:01 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 March 2014 20:21:01 UTC