W3C home > Mailing lists > Public > www-style@w3.org > February 2009

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

From: Robert O'Callahan <robert@ocallahan.org>
Date: Sat, 7 Feb 2009 18:58:07 +1300
Message-ID: <11e306600902062158q2922d6ecsc68f5fec6c168b4a@mail.gmail.com>
To: Brad Kemper <brad.kemper@gmail.com>
Cc: fantasai <fantasai.lists@inkedblade.net>, "www-style@w3.org" <www-style@w3.org>
On Sat, Feb 7, 2009 at 5:31 PM, Brad Kemper <brad.kemper@gmail.com> wrote:

> 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.
>

FWIW I wasn't involved in the WG meeting, since I'm not in the WG, so I'm
not interested in the aspersions you're casting here.

And they all they can be simulated with image-border (except for the
> background clipping of border-radius, as fantasai pointed out).
>

And except that we want mouse clicks on the shadow to be directed to the
underlying element, not the element the shadow belongs to.

Oh, also, making the border thicker to account for the shadow will affect
layout. You'll need to apply negative margins and hope that doesn't mess up
collapsing. If you wanted to have an em margin and your shadow is in px then
you're just stuffed until calc() arrives.

You're just hung up on the name.
>

Yeah, I am. Names are important.


> 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.
>

We don't break other features to optimize for users with script disabled or
who read Armenian. If we have to choose, we optimize for the common case, in
this case when images can be loaded.


>
>> 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.


>
>> 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.


> 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?


>
>> 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.


> 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.

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.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]
Received on Saturday, 7 February 2009 05:58:44 GMT

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