W3C home > Mailing lists > Public > www-style@w3.org > June 2010

Re: [css3-background] box-shadow spread Multiple Choice Question

From: Brad Kemper <brad.kemper@gmail.com>
Date: Sun, 6 Jun 2010 10:22:07 -0700
Cc: www-style list <www-style@w3.org>
Message-Id: <6D8C13DC-E8F0-4E47-A52A-DE05ADF2153B@gmail.com>
To: fantasai <fantasai.lists@inkedblade.net>
Oops, I left out number 4 (and 4a), which was "prefer #2 (or 2a), but allow #3 (or 3a)." So, I'd insert those options as follows (in descending order of preference).

3a
4a
2a
3
4
2
1 Clearly it is not preferable to distort the shape in order to simulate an offset via a scale, even if you thought box-shadow should have a scaling feature, which this isn't. It's one thing to do it for performance reasons, another thing to do it because you really wanted something completely different. It is supposed to satisfy the needs of those who use spread in image editors today, not those wishing for another feature and attempting to sabotage this one.
5



On Jun 3, 2010, at 5:05 PM, Brad Kemper wrote:

> Thank you, fantasai. This looks like an accurate list if the options, well explained. My order of preference is:
> 
> 3a. In my tests, it actually looked better than 2a's truer offset, and if it is better for performance, so much the better.
> 
> 2a. What I originally proposed.
> 
> 3. I could live without the square corner requirement, even though I think it is pretty nice to have.
> 
> 2. This one could actually be a raster effect, which may (?) make it mote acceleratable using a graphics card. It is also more likely what we'd have to do to bring spread to text-shadow (which I really hope we do, as it really proves it's worth even moreso for defining shadows for small finicky shapes).
> 
> 1. Better than nothing, but it is not just distortion of elipses that suffers. It is scaling of elipses, too, because the scaling is not nearly enough. Consider the difference between the inside and outside radii of a border whose 'border-radius' measurement is close to its 'border-width'. It is a big difference, with the inside at or near zero radius. Now consider how little you have to scale a typical element to get offsets of a few (or even several) pixels. Hardly any at all, so that the corners look very odd, not much at all like a real offset.
> 
> 5.
> 
> By the way, one other issue I have is that I don't think we need the word 'radius' in 'spread-radius' or even 'blur-radius'. It is kind of confusing, like saying 'offset-radius'. For blur, it is actually more like a diameter (of the blur brush being swept around the perimeter).
> 
> On Jun 3, 2010, at 3:56 PM, fantasai <fantasai.lists@inkedblade.net> wrote:
> 
>> Given that
>> a) We made some very significant changes to CSS3 Backgrounds and Borders
>>    at the last F2F in March
>> b) We have not yet published a new official draft of the changes
>> c) The spec is already in CR, and therefore under Call for Implementations
>> I think it is imperative that we publish a new official Last Call Working
>> Draft asap.
>> 
>> However! We still have an open issue, which is the behavior of box-shadow's
>> spread radius. There are a fixed number of options that have been proposed.
>> I will attempt to list them all:
>> 
>> 1. Change spread to scale. The border-box shape is scaled up or down
>>    in each dimension independently as necessary to increase its width
>>    and height by the spread radius.
>> 
>>    Note: If the width and height are not equal, this will distort the
>>          shape.
>> 
>> 2. Define spread as an outward outset normal to the original shadow
>>    perimeter. (This is equivalent to a blur operation with a threshold
>>    operation that makes all non-transparent areas solid, and to stroking
>>    the perimeter of the border-box with a spread-radius-sized brush,
>>    and is the strictest interpretation of a "spread" concept.)
>> 
>>    Note: If the corner curves are not circular, the curves will no
>>          longer be elliptical.
>> 
>>    Note: If the shadow shape is contracted by more than the border-radius,
>>          round corners will become sharp.
>> 
>> 2a. As for 2, but special-case border-radius: 0; to be a sharp-cornered
>>     rectangle.
>> 
>> 3. Define spread as an outward outset of the box sides and a corresponding
>>    increase in the border-radii.
>> 
>>    Note: If the corner curves are not circular, the distance between the
>>          original edge and the altered edge will not be constant.
>> 
>>    Note: If the shadow shape is contracted by more than the border-radius,
>>          round corners will become sharp.
>> 
>> 3a. As for 3, but special-case border-radius: 0; to be a sharp-cornered
>>     rectangle.
>> 
>> 4. Define spread radius as outward normal outset, but allow implementations
>>    to approximate as per 3.
>> 
>> 4a. As for 4, but special-case border-radius: 0; to be a sharp-cornered
>>     rectangle.
>> 
>> 5. Drop spread radius from box-shadow.
>> 
>> If I am missing your preferred option, please respond to this email with an
>> explanation of your preferred option.
>> 
>> For details on concepts 2, 2a, 3, 3a, 4, and 4a, see the editor's draft,
>> which defines 4a, and thus has definitions for all the rest.
>> http://dev.w3.org/csswg/css3-background/#the-box-shadow
>> If you think the above definitions are missing details... They are missing
>> details! Check the spec before complaining that they are missing. I've added
>> Brad's diagram and rearranged the text. If there are any outstanding editorial
>> or clarificational comments, let me know, preferably *before* we discuss the
>> topic on a telecon.
>> 
>> Finally, I respectfully request that the chairs schedule ten minutes of an
>> upcoming telecon to conduct a straw poll, hopefully resolve the issue, and
>> approve publication of a css3-background LCWD. I also request that if the
>> discussion takes more than 8 minutes that we take option 5 and publish. I
>> understand that CSS2.1 is the top priority, but it is also urgent that we
>> officially publish the major changes we made to background-clip.
>> 
>> Thanks~
>> 
>> ~fantasai
>> 
>> 
>> 
Received on Sunday, 6 June 2010 17:22:47 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:28 GMT