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

On Mon, Mar 30, 2009 at 5: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 could live with that.


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


That works for me. Yes, and its when the image generally follows the
original border shape that letting the corners clip the background can be
very useful too.


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


I think most authors could live with that too. I certainly can, and if was
never implemented differently then no one would have any false expectations
about using it to try to do something else with it.


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

With that, an outline that appeared on :hover would be a nice way for an
author to visually indicating where the clickable areas were, if there was
any question.

A different way to go would be to suppress outlines and let the author draw
them in pixels. That would fit in with my general philosophy of suppressing
visual effects on our outside the border, if they can be represented in the
border images. It gives more flexibility to the author to draw those things
exactly as he wishes. But complicates it a little for effects that commonly
change on mouse-over if the images are not expected to change anyway. I
don't know if that is true or not for a combination of border-image and
outline.