Re: [CSSWG] Minutes and Resolutions 2009-02-04: box-shadow and border-image

On Fri, Feb 6, 2009 at 1:28 PM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Sat, Feb 7, 2009 at 4:55 AM, Brad Kemper <brad.kemper@gmail.com> wrote:
>
>> On Feb 5, 2009, at 9:11 PM, "Robert O'Callahan" <robert@ocallahan.org>
>> wrote:
>>
>> CSS box-shadows will typically look a lot better than image shadows if the
>> user zooms or prints.
>>
>>
>> You really think that matters?
>>
>
> It's not a huge deal, but it's something.
>

Right. Something to argue with me about, but not anything important to
authors.

You can use SVG images in border-image to get nice scaling of those images;
> using SVG filters in the image to produce a nice shadow would be a pain.
>

Maybe you need better tools. I was able to create a shadow-casting shape in
Adobe Illustrator and export it as SVG. It didn't take more than about 2
minutes, the shadow was rasterized inline with the SVG, and it looked fine,
even when I zoomed in several times (because it was blurry to begin with).
No pain at all.

Unfortunately, I can't post it here now, as my Web server seems to have a
problem serving files ending with ".svg" or ".xhtml".


>  Also, CSS box-shadows do not stop events from reaching the elements
>> underneath them, which is very useful when they're translucent; you can't
>> emulate that with border images.
>>
>> Well that's a new argument at least. It didn't seem to figure into the WG
>> discussion though.
>>
>
> So what?
>

So, my original post in this thread was about the rash decision the WG made
after a very short discussion that did not seem to involve many of the pros
and cons mentioned on this list. I mentioned some before their decision, and
now you and Håkon are mentioning others. So it was either not an informed
decision by all participants, or it was based on secret criteria not
mentioned in the meeting. Or maybe logic and reason doesn't matter if some
of the members had their minds made up ahead of time and only come up with
reasons afterward as a way of denying a request. I can't say what was in
people's minds, but the minutes of the discussion were very short and didn't
seem to cover many of the reasons for going one way or the other.


> Of course, the biggest advantage of image-border is to create shape that an
>> ordinary border box can't, so if you use them on links, for instance, the
>> active area won't follow the complex edge anyway.
>>
>
> I don't know if your assumption is true,
>

It is based on being an author and knowing what I want, and seeing a lot of
possibilities that weren't possible before. Out of all the infinite number
of different shapes you can create with images for borders, rectangles and
round-corner rectangles are only two, and are the ONLY two that box-shadow
is any good for. Which is fine, since it keeps that property simple, and it
is simple to create very satisfactory shadows as part of the image.


> and you can't rule out other uses even if it is.
>

Other uses for a cast shadow that doesn't closely match the shape that is
supposed to be casting it? Other uses for image-border that don't involve
irregular shapes (such as simple buttons) are still possible to accomplish
with good-enough shadows as part of the images used. But the reverse, of
creating a nicely shadowed low-bandwidth fallback when image-border isn't
available (perhaps because of bandwidth concerns), is not possible your
way.


> Having border-image disable box-shadow would add a strange wart to the
>> platform that would confuse authors
>>
>>
>> No way. I am an author and the main thing that confused me is why some of
>> the edge decorating effects that image-border can replace are suppressed
>> (border style, weight, and color), and some are not (box-shadow and
>> border-radius).
>>
>
> What has 'box-shadow' got to do with borders, on the face of it? If
> border-image suppressed border-radius that would make a lot more sense,
> since at least they both have 'border' in the name. If it was
> 'border-shadow', sure.
>

The name is just a name. Personally, I would have gone with "corner-radius"
instead of "border-radius", since it works even when there is not border.
But then, according to your logic, it would have to be changed to clip the
border-image. The point is, borders, box-shadows, and border-radius are all
elements to decorate or shape the outer edge of a box. And they all they can
be simulated with image-border (except for the background clipping of
border-radius, as fantasai pointed out).

You may think it makes perfect sense for one property to turn off another
> property whose name is not related, but I don't think you can speak for all
> authors. Having "position" enable "z-index" made sense to someone but it's
> real disaster for authors in practice. I don't want to go there again.
>
> Why were the traditional border properties allowed to coexist in a way that
>> intrinsicly acknowledged their value as fallback, but then fallback is
>> ignored for shadows and corners?
>>
>
> Because "box-shadow" is not a border property.
>

You're just hung up on the name. Box-shadow and Border could both be
simulated with border-image, and could both have fallbacks or not. But the
border is allowed to exist as a fallback and box-shadow is not. Why? Just
saying "box-shadow" is not a border property does not explain why border
properties are allowed to be invisible fallbacks for something that draws
rasters in the same general area and box-shadows are not.


> Dunno about border-radius; the only reason to keep applying it would be to
> get proper hit-testing, and there might be a better way to do that. That's a
> separate issue.
>
>
>> and prevent useful applications of these features. The only benefit would
>> be better fallback when border images are not loaded or in browsers that
>> support box-shadow but not border-image; but the former is extremely unusual
>> in practice
>>
>>
>> Turning off images for bandwidth considerations is not all that unusual.
>>
>
> As a browser developer, I can assure you that the vast majority of all
> users do not disable images.
>

I never said they did. It happens more often for low bandwidth situations.
Also the vast majority of of all users do not disable JavaScript and do not
read Armenian. Yet some of us want to be able to give them a good online
experience anyway. As good as we can with often limited authoring time.


> The few users who do disable images obviously don't care about visual
> effects on the Web and will not be disturbed by pages not falling back to
> box-shadow.
>
>
>> and the latter is not worth worrying about.
>>
>>
>> I can easily imagine UAs used in low bandwidth situations that would have
>> box-shadow but not image-border. Why don't you want me to give them a nice
>> presentation with box-shadow as a substitute?
>>
>
> Because that's a very tiny benefit and the price is adding a confusing wart
> to the platform which removes useful functionality.
>

That's the same argument I have for doing things your way. As an author, I
consider the combination of box-shadow and image-border as they are
currently implemented to be and ugly, confusing wart. I consider the ability
to have a better fallback plan to be vastly more important that having the
image resolution of the fuzzy gray borders be greater than the images used
in the border itself. The alternative I proposed is not at all confusing; it
is what expected from the beginning, when I first tried out using
border-image.


> If you want to serve these users better, I suggest adding a media-query
> value that lets you detect in the stylesheet when image loading is
> disabled.
>

<sarcasm>Oh yeah, like that's simpler and less confusing. </sarcasm>

In either case, falling back to no shadow at all is just fine.
>>
>>
>> If it is so fine to have no shadow in that case, then why insist that it
>> be visible in the other case when it is specified along image-border, when
>> image-border does  a better job of matching it to the shape of the edge.
>>
>
> So that designers can do useful effects and the platform is as uniform and
> predictable as possible.
>

Huh. That is my goal as well, and my proposal is better at achieving that.


> And if fallback for the no image-border situation is so unimportant, then
>> why was such effort put into allowing border and image-border to be author
>> specified at the same time, with the thickness of the image-border based on
>> the border-width of a border it hides? Why didn't we just make the two
>> properties independant with one drawn under the other? It could have allowed
>> for some interesting color changes of the border-with-a-border via DOM
>> during mouseover.
>>
>
> I don't know.


Then I'll tell you. It because fallback to regular borders was an important
consideration, just as fallback to regular shadows on irregularly shaped
image borders should be.


> You have very fixed ideas about how authors should and will use
> border-image and box-shadow.


No, I have my own experience as an author to inform me on how it will be
used. The WG had expressed an interest in knowing what authors wanted,
needed, and thought about the development of the CSS language. That is what
I am providing as an author.

I am not limiting the uses that authors can have for the properties. To the
contrary, I am trying to make them more useful (not just rectangular borders
can use box-shadow to good effect with my proposal, but any use of image
border can).


> In my experience it is difficult to predict how properties will be used and
> in what combinations.


Well, some combinations are easy to see, and I've even provided some sample
cases. Some befits of doing things one way instead of another are fairly
obvious to people who actually use the language to style their pages and
sites. But I suppose you could settle any argument about the usefulness of
one method over another by just refusing to consider the ramifications.


> It has usually been a mistake to compromise orthogonality to try to
> optimize for some particular desired combination.


Then stop trying to optimize for straight edge borders. Orthogonality makes
this particular property easier to understand in more diverse uses than that
does.