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

Re: [Backgrounds/Borders] What to do when a border-image fails to load

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 30 Mar 2009 19:56:27 -0500
Message-ID: <dd0fbad0903301756i7ad2c784o576ac1e6b515b3ce@mail.gmail.com>
To: David Hyatt <hyatt@apple.com>
Cc: Brad Kemper <brad.kemper@gmail.com>, Andrew Fedoniouk <news@terrainformatica.com>, Anne van Kesteren <annevk@opera.com>, Bert Bos <bert@w3.org>, "www-style@w3.org list" <www-style@w3.org>
On Mon, Mar 30, 2009 at 7:21 PM, David Hyatt <hyatt@apple.com> wrote:
> On Mar 30, 2009, at 7:04 PM, Brad Kemper wrote:
>
>> How about if for the pixels falling outside the regular border-box, only
>> totally opaque pixels would be hit/hover targets, and all others would be
>> considered a purely decorative effect? That would be the ideal, IMHO, as it
>> would allow images of shadows, glows, clouds, puffs of smoke, etc. to be
>> ignored as hit targets. Otherwise, if it is all or nothing for pixels
>> outside the box, I would lean towards nothing, treating them as a purely
>> decorative effect, like box-shadow.
>
> My preference is that the border-image's box is just a decorative effect and
> that hit testing should use the normal border box.  I would expect even the
> border-radius to be included in such hit testing, and simply assume that the
> border-image is conceptually going to follow that curve closely (even if it
> isn't clipped when rendering so that it can produce visual frills outside
> the curve).

I would also prefer this.  It's very simple, and once you are aware of
it, intuitive.

> I really get why you didn't want border-image to clip to the border-radius
> now with this new proposal of yours.  I agree with that now, with the
> understanding that hit testing should honor the border-radius curve.  The
> idea behind border-image is that it *should* match the original border
> shape, and that any pixels drawn outside that shape should be purely for
> decorative effect.

Yup, that's exactly why I supported Brad's ideas in the earlier threads.  ^_^

> I'm actually inclined to disallow negative offsets for the border-image box
> now that I've thought about it some more, since there is no way an inset box
> can actually respect the original border shape.  By disallowing negative
> offsets, we'd help make that clear, i.e., that the intent of expansion is
> for visual frills outside the original border shape, and not to just draw
> some arbitrarily different shape.

Eh, I disagree.  A negative offset is effectively identical to just
adding extra transparent space around the edge of the image, and
increasing the slice depths appropriately.  I don't know if the
'lesson' here is important enough to drive home that we need to
disable an ability and force authors to hack around it when required.

>> There's also the question of where outlines should render.
>>
>> Yes, these are interesting questions... automatically follow the contours
>> of non-transparent pixels? Honestly, I think it would be perfectly
>> reasonable if the outline just followed the original border-box, and was
>> rendered somewhere above the border-image.
>
> Yeah I agree.  I think the outline should just follow the original border
> shape (including the border-radius if specified).

Agreed.  Follow the border-box (including border-radius), render above
the border-image (so it is always visible).

~TJ
Received on Tuesday, 31 March 2009 00:57:13 GMT

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