Bug 31949 - -webkit-border-image/-webkit-gradient should be altered by -webkit-border-radius
Summary: -webkit-border-image/-webkit-gradient should be altered by -webkit-border-radius
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: CSS (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-11-27 20:42 PST by David Gatwood
Modified: 2011-09-23 16:15 PDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Gatwood 2009-11-27 20:42:54 PST
The -webkit-border-radius should modify borders generated by the -webkit-border-image tag.  At a minimum, it should do so when the image is dynamically created (e.g. with -webkit-gradient).  Without that, gradients can only be used for very simplistic square borders.

While I'm suggesting improvements in this area, it would be really nice to have a clean CSS way of specifying that these borders be beveled (equivalent to inset/outset on standard borders).
Comment 1 mitz 2009-11-29 11:03:48 PST
The Editor’s Draft of CSS Backgrounds and Borders Module Level 3 disagrees:
“ Backgrounds, but not the border-image, are clipped to the appropriate curve (as determined by ‘background-clip’).” <http://dev.w3.org/csswg/css3-background/#the-border-radius>.
Comment 2 David Gatwood 2009-11-30 10:47:09 PST
The problem is that there's a fundamental difference in the way a manually constructed border image and a programmatically generated border image (e.g. -webkit-gradient) should be treated.  The former should definitely not be cropped because the creator can easily crop it if desired by adding an alpha channel.  The latter definitely should be cropped because otherwise there's no way to crop it.

Perhaps the specification could be amended to say that the border-image should be cropped only if there is no alpha channel present in the border image?  That would cover both of the two likely use cases, and I can't think of any good argument for having a hand-built border-image with no alpha channel.
Comment 3 Dave Hyatt 2011-09-14 12:25:14 PDT
Spec is pretty much final and still disagrees.
Comment 4 David Gatwood 2011-09-14 15:33:18 PDT
Please take this up with the standards committee and strongly encourage them to *fix* the *spec*.  As written, it's just plain broken in a rather serious way.  As designed, it is not possible to do non-square borders with CSS3 unless you manually generate all the images in a graphics program.  That can't *possibly* be the intended behavior....
Comment 5 Dave Hyatt 2011-09-23 16:15:22 PDT
(In reply to comment #4)
> Please take this up with the standards committee and strongly encourage them to *fix* the *spec*.  As written, it's just plain broken in a rather serious way.  As designed, it is not possible to do non-square borders with CSS3 unless you manually generate all the images in a graphics program.  That can't *possibly* be the intended behavior....

You're never going to get the images to perfectly match the border-radius curve across all browsers/implementations of border-radius. I think the expectation is that designers would build the rounding into the border-image itself in order to guarantee pixel-perfect rendering everywhere.

There have already been discussion threads on this issue on www-style, and I think it has been satisfactorily resolved. If the spec changes, we can re-open the bug, but I don't think it will.