- From: Brad Kemper <brad.kemper@gmail.com>
- Date: Thu, 26 Mar 2009 09:36:56 -0700
- To: David Hyatt <hyatt@apple.com>
- Cc: "www-style@w3.org list" <www-style@w3.org>
On Mar 25, 2009, at 10:08 AM, David Hyatt wrote: > If border-image does not clip to the border radius, then as far as > hit testing is concerned, the box has to be treated as rectangular. > By default, hit testing does not look at transparent pixels of an > image. I still don't understand why border-image has to ignore the > curve specified by border radius, Because border-radius clipping (and current version of box-shadow, for that matter) makes assumptions about the width and transparency of the border that are not valid assumptions (because border-image, in more possible cases than not, changes the transparency and width of the perceived border). Background and foreground-clipping do not have that same problem (at least, not to the same degree... see below). I think it is appropriate, therefore, to either use the rectangular shape for hit testing (since you don't know the true shape of the image-based border), or else look at the transparent pixels of the image (alpha > .5 = hit target). I'd prefer the latter (as a SHOULD), unless it is a significant performance hit. The reasons an author might want to specify a border-radius that does not clip the border-image is the same as why an author would want to specify a border at all in addition to the border-image: so that the fallback version can still look as close as possible to the intended look when images or image-border is not available. If fallback is not an important consideration, then image-border should not include a way to specify a different border width than 'border-width'. In which case I would rescind my previous arguments about this and about box-shadow in the presence of image-border. But I do think it is important, especially during the transition time in which the various UAs will have various levels of support for this new property. > when both the background images and foreground content (when > overflow:hidden) are going to honor the curve. The background-image alignment does suffer a bit from possibly being based on a possibly changed border-box width, but only when background- origin is 'border-box', which is not the default, and when 'background- clip' is not 'padding-box'. Personally, I am unlikely to use anything but 'background-clip:padding-box' when using image-border (I almost wish it was automatic). In that case, background images and foreground content are clipped to everyones expectations, because then this no longer has anything to do with the border or the border-box. > This change makes no sense to me. Nevertheless I have made it in > the latest WebKit. We'll follow the spec off a cliff if we have > to. :( Thank you! I appreciate your dedication. > > > dave > (hyatt@apple.com) > >
Received on Thursday, 26 March 2009 16:37:34 UTC