[css-borders][css-images] Properly address border image use cases, and kill border-image with fire #9714
Description
Background
Overall border-image is a mess, and most authors won't touch it with a bargepole unless they really have to (per the 2022 Almanac it is used on < 7% of pages, which seems way lower than the frequency of actual border image use cases).
It doesn't cover enough related use cases, and even when it does, its syntax is confusing.
Several issues exist to patch some of its holes, either by tweaking border-image itself, or by adding syntax to other parts of CSS to address them, e.g.:
- [css-backgrounds] background-clip: border-area #9456
- [css-borders-4] Allow to define separate border images for different border regions #9183
- [css-borders] allow negative values for
border-image-outset#9263 - [css-borders] Multi-layer support for
border-image#8802 - [css-images][css-backgrounds] make
border-imageandborder-radiuswork together #7550 - [css-borders] manipulating
border-image-sourcebefore slice #7777 - [css-backgrounds] a
no-repeatoption forborder-image-repeat#7457
Its syntax also has issues:
Fixing border-image
It seems to me that there are three 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 becauseborder-imagewas designed before@supports, so we probably thoughtborder-radiusandbordercan be used to provide a decent fallback? - It doesn’t cover all relevant use cases
It’s probably not worth trying to reuse border-image for this, since border-image: <image> is valid syntax, it will impose severe restrictions in terms of what we can do. Perhaps border-layer could work (since we recently added background-layer) and naturally affords multiple images. We could even move the <image-1D> syntax to that, which currently awkwardly sits in border-color.
For 1, I think a good way forwards would be to offload the scaling logic to @image and have border-layer only deal with assigning one or more <image> values to border parts and doing reasonable things by default.
For 2, it seems obvious that whatever replaces it should naturally follow border-width, border-radius, border-style etc. it could also have corresponding side longhands for specifying separate images per border.
For 3, I think the main categories of use cases are, in order of less to more control:
- Entire image used in the border area (see use cases for [css-backgrounds] background-clip: border-area #9456)
- 9-slice scaling
- Separate images for sides/corners with auto-flip/rotate
- Separate images for sides/corners with no modification
One potential design, just to get the conversation started:
border-layer-source: <image>#
border-layer-align: [ auto | normal ]#;
border-layer: [<border-layer-source> && <border-layer-align>?]#
With potential border-<side>-layer / border-<corner>-layer shorthands for separate images per side/corner.