w3c / csswg-drafts

CSS Working Group Editor Drafts
https://drafts.csswg.org/
Other
4.5k stars 664 forks source link

[css-backgrounds-4] Can you chain `border-area` and `text` in `background-clip`? #10696

Open nt1m opened 3 months ago

nt1m commented 3 months ago

9456 added background-clip: border-area.

I think it would be useful to support background-clip: border-area text in case you want your background to bleed through both the text and the border-area of an element.

The new syntax would then be:

<bg-clip> = <visual-box> | [ border-area || text ]
smfr commented 3 months ago

I think this is just two border-images:

            background-image: linear-gradient(to bottom right, green, blue), linear-gradient(to bottom right, green, blue), none;
            background-color: yellow;
            background-origin: border-box;
            background-clip: border-area, text, border-box;
yisibl commented 3 months ago

Considering that the border gradient uses the same gradient as the text, and to avoid writing multiple background-image, I think it's necessary to support the background-clip: border-area text syntax.

cc @LeaVerou

image

LeaVerou commented 3 months ago

Agreed. Though my preference would be to not special case the combination of border-area and text, but to define a more general way to create unions of these. Possibly just by space-separating the identifiers. Sure, that could allow nonsensical combinations like border-box content-box but UAs can easily short-circuit those. E.g. border-box text is not meaningless, since text can actually overflow its container (though currently text is clipped by border-box, which is very unfortunate).

nt1m commented 3 months ago

Feel free to reopen if you feel like this is a path exploring

SebastianZ commented 3 months ago

I guess that's a straight-forward change and all seem positive about it. So let's put it on the agenda.

The two points to resolve on:

  1. Support for multiple values in background-clip
  2. Support any keyword combination or only sensible ones?

Regarding combinations, I don't see value in allowing all combinations. So I propose the syntax to be

<bg-clip> = [ <visual-box> | border-area ] || text

Or, if we believe there are use cases to combine styling the box areas with the border area, then

<bg-clip> = <visual-box> || border-area || text

Sebastian

Loirooriol commented 3 months ago

border-area content-box and border-area text seem reasonable. border-area padding-box and border-area border-box should just behave like border-box I think. text content-box and text padding-box would have their own behavior if there is text overflowing the content/padding box, but I can't image why someone would want this combination. text border-box behaves like border-box, unless we change the definition of text.

fantasai commented 1 month ago

I have a preference for only supporting the reasonable values. The QA cost to checking invalid values are invalid is wayyy less than ensuring nonsensical values work correctly.

css-meeting-bot commented 6 days ago

The CSS Working Group just discussed [css-backgrounds-4] Can you chain `border-area` and `text` in `background-clip`?, and agreed to the following:

The full IRC log of that discussion <TabAtkins> fantasai: suggestion to combine some of the background-clip areas, particularly 'text' and 'border-area'
<fantasai> https://github.com/w3c/csswg-drafts/issues/10696#issuecomment-2284375965
<TabAtkins> fantasai: this seems fine to me
<TabAtkins> fantasai: also a suggestion to allow arbitrary combos, don't think we shoudl do that. not worth it for almost all of the combos.
<TabAtkins> fantasai: we can enable particular combos as needed; currently i think text and border-area is the only reasonable one
<TabAtkins> TabAtkins: okay, it's a combination of the two areas, i thought it was gonna be an intersection
<dbaron> does this preclude doing intersections later?
<TabAtkins> smfr: yeah it saves you from ahving to do two backgrounds if they'd be the same
<TabAtkins> fantasai: i think if you want an intersection we should have a specific syntax for it
<fantasai> TabAtkins: once you get there, ordering dependency matters
<fantasai> TabAtkins: interesting feature, but requires justification and development
<dbaron> (clipping background to the text that is inside the <*-box> seems like not too unusual a request
<TabAtkins> astearns: so proposal is to add `border-area || text` as a valid value
<TabAtkins> astearns: no prejudice against more changes in the future
<TabAtkins> astearns: objections?
<TabAtkins> RESOLVED: Add `border-area || text` to the background-clip syntax