- From: Brad Kemper via GitHub <sysbot+gh@w3.org>
- Date: Sat, 16 Dec 2023 03:46:53 +0000
- To: public-css-archive@w3.org
> It seems to me that there are two fundamental problems with border-image: > > It conflates two orthogonal concepts: 9-slice scaling is useful for images in general, and using images for borders is useful with or without 9-slice scaling. > It doesn’t play well with other properties, like border-radius. Presumably this was done because border-image was designed before @supports, so we probably thought border-radius and border can be used to provide a decent fallback? > It doesn’t cover all relevant use cases I see these more as border-image limitations than border-image problems. It was never intended for border-image to be more than a 9-slicer, similar in capabilities to what Android provided natively (I don't remember which came first). Naturally, IMO, there should be other ways to put images into borders that doesn't involve doing a 9 slice, and that should be with a separate property. I suspect the appetite to do so earlier was reduced due to border-image's lack of popularity. WRT border-radius, fallback was part of the reasoning, but also there is the fact that the images would not be clipped by the border box. Even with overflow: hidden, clipping the border image would not be desirable, as the image is able to extend beyond those edges, and have any manner of shadows, glows, filigree, or whatever that was just ink. Most of the time, if you wanted round corners you'd just build them into the image. Border-radius is something that shapes a border, but only clips the background (or contents, with a non-visible overflow). I don't think there is any good way for border-radius to shape or clip border-image, and it isn't necessary if the image already describes the corners, but border-radius is good as a fallback. -- GitHub Notification of comment by bradkemper Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9714#issuecomment-1858703280 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Saturday, 16 December 2023 03:46:55 UTC