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

On Feb 6, 2009, at 9:58 PM, Robert O'Callahan wrote:

> FWIW I wasn't involved in the WG meeting, since I'm not in the WG

I didn't say you were. You asked why I mentioned nobody giving any of  
your reason in their meeting (or at least, that is what I understood  
"so?" to mean in the context), and I told you that they didn't seem to  
consider many of the reasons on either side. So they voted without  
everyone there considering all the pros and cons of what they were  
voting on, either in ignorance or knowingly. One reason I can imagine  
a member not adequately discussing it is because he or she had already  
made up his or her mind.

> Oh, also, making the border thicker to account for the shadow will  
> affect layout. You'll need to apply negative margins

So does specifying a width for image-border that is different from the  
original border. Plus, it is no worse than what authors are doing  
today with background images to create button shapes with shadows. If  
they want to tweak the position with a few pixels of negative margin,  
it is not burdensome to do so, and there are usually enough other  
wrappers to be found in the HTML that a different one could be used  
with some padding or margin if you need some extra space outside of  
that measured in ems.

> 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.
>
> We don't break other features to optimize for users with script  
> disabled or who read Armenian.

But you are willing to break a very reasonable fallback feature in a  
situation where other fallback is allowed for the same thing (no image- 
border available to the UA). And why? So that normally indistinct  
shadows can be in higher resolution than the borders they straddle.  
That is not a good reason to break a reasonable and orthogonal  
fallback. Especially when on the vast majority of possible image- 
borders, your shadow won't line up with anything anyway.

> If we have to choose, we optimize for the common case,

No, you are optimizing for images that are straight-edged, with either  
square or round corners. With all the possible shapes, that cannot  
possibly be considered the common case.

> in this case when images can be loaded.

When images are loaded, having the shadow as part of the image is  
still the best bet, except in those minority times when the images  
happen to have the exact same outer shape as the border box. And even  
then, in that limited situation, the only advantages you get are:

1. to have shadow color that can be easily changed via a single value  
in CSS, even though most designs these days don't need to, and even  
though the effect can be created in via an additional image (which  
would be tiny in the most common use case of this uncommon  
occurrence), and

2. to have shadows that are higher resolution than the image-based  
border, even though–in virtually every case–the resolution of the  
shadow will be much less important to any author than the resolution  
of images making up the border, because shadows are typically blurry  
anyway. And guess what? You can have high resolution image-borders if  
it is important to the author, and by building the shadows into the  
images they become just as high-res.

Those limited benefits in those limited circumstances are not work  
discarding the same sort of fallback to box-shadow as with the  
fallback to borders.

> 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 don't forget this point. Your mission here is to provide a  
> fallback shadow to users who have already indicated they don't care.

Turning off images (or image-borders) or not having them available in  
the UA does not mean that design doesn't matter. It might just mean  
that loading images takes too much time, or that they are unlikely to  
look good due to a tiny screen, or that they were not a implementation  
priority.

> 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.
>
> You are proposing adding code so that border-radius disables box- 
> shadow. I am proposing simply not doing that. Your behaviour is more  
> complex than mine.

No, it certainly isn't.

> As an author, I consider the combination of box-shadow and image- 
> border as they are currently implemented to be and ugly, confusing  
> wart.
>
> You're seriously arguing that authors will be confused if border- 
> image and box-shadow both work when applied to the same element?

They may be confused (as I was) of the logic and reasoning behind the  
fact that borders can be specified as a fallback but shadows cannot,  
even though the image is a very likely place to contain both (when,  
when using image-borders for the irregular-shaped edges that it was  
designed to handle.

> 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>
>
> Sure, it's a direct solution that's easily implemented and cleanly  
> allows authors to fall back any way they want when images are not  
> being loaded.

Not nearly as simple for authors as what I have suggested, where an  
author simply inserts a property/value pair that is not needed by  
image-border.

And last time I checked, media queries cannot detect whether or not  
certain values were assigned to certain properties in a UA or author  
style sheet. device-width could tell you it was a small screen, but  
not if the connection was slow because of a dial-up modem, or if the  
small screen had a fast connection through wi-fi or 3g, or if a person  
just doesn't load images as a matter of principal, or if the UA is  
behind the times and doesn't support image-border (which is newer than  
box-shadow, and probably lower on some implementers list of features  
to implement).

On the other hand, if high resolution shadows are important to you,  
you could use media queries on resolution to specify a higher  
resolution border image for printing or zooming. You could lazy load  
it when it was needed, and let the screen resolution version load with  
the initial page load.

> 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.
>
> As one author, yes, thanks. A sample of one out of millions, but you  
> seem to claim to know what all authors will want.

You've heard from two, actually, and they generally agree on the main  
points.

So far, no author has spoken out against having box-shadow available  
as a fallback to image-border, or said, "man, I would really like to  
have a rectangular drop shadow surrounding my non-rectangular border"  
or "gee, I'd like to add a drop shadow to the images in my border, but  
the ones that PhotoShop and Illustrator produce are just too blurry  
because they have the same image resolution as the images in the  
border" or "golly, please don't give me a way to do simple drop  
shadows for the people who can't see the ones in my image-border". It  
has only been a couple implementors that have been coming up with  
excuses not to allow the fallback.

> 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.
>
> Orthogonality in the platform means that when features A and B work  
> when applied independently in some situation, they continue to work  
> as expected when applied together. B doesn't just stop working in  
> the presence of A because someone thought that would be a good idea  
> for the cases they cared about.

Call it philosophical consistency then. Consistency makes things  
easier to understand.

Feature A: image-border (which can do the same things as feature B)
Feature B: border-style & border-width

Feature A: image-border (which can do the same things as feature B)
Feature B: box-shadow & border-radius

If these were consistent it would make them easier to understand.