Skip to content

[css-color-4] [css-backgrounds-4] text system color conflicts with background-clip #4465

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
emilio opened this issue Oct 29, 2019 · 4 comments

Comments

@emilio
Copy link
Collaborator

emilio commented Oct 29, 2019

https://drafts.csswg.org/css-backgrounds-3/#propdef-background allows you to specify a background-clip value using one of the <box> bits in the syntax..

backgrounds-4 defines background-clip: text, which multiple browsers implement and ship from a long time ago. It is my intuition that if we allow to set background-clip in the background shorthand, we should also be able to set background-clip: text.

Firefox does this already: background: linear-gradient(red, blue) text parses as background-image: linear-gradient(..); background-clip: text; background-*: initial.

The system colors introduced in css-color-4 (#4091) include a Text value, which conflicts with background-clip: text in the background shorthand.

That means that the previous example will start parsing as background-color: text rather than background-clip: text, which is a significant behavior change.

So we have multiple options I guess:

  • Make this behavior change (as I think Gecko is the only engine that supports background-clip: text on the background shorthand as of now). This would be a bit unfortunate, but probably ok?
  • Rename the text system color to something else, to prevent the naming conflict.
  • Something else I may be missing?

cc @melanierichards @dbaron

@BillGoldstein
Copy link

Bikeshed: rename color:Text to CanvasText (which would be consistent with Canvas)...though I kinda hate the name.

@tabatkins
Copy link
Member

CanvasText sounds fine to me, given the parallel with all other *Text names.

@dbaron
Copy link
Member

dbaron commented Oct 30, 2019

I'd note that it seems likely that one reason implementations differ here is that the level of css-backgrounds (level 4) that defines background-clip: text doesn't define the background shorthand, so different implementers have made different decisions as to what to infer that level 4 will say about the background shorthand once it includes it.

I'd note that another option is to say that not all background-clip values can be specified in the background shorthand. I think this wouldn't be the first case where the shorthand is not serializable from a set of longhands (e.g., lists of mismatched length).

I'd also note that "make this behavior change" isn't super-clear, since you need to define the behavior of:

  • background: text text
  • background: blue text
  • background: padding-box text
  • background: blue padding-box text
  • background: padding-box padding-box text

I think renaming the text system color to something more specific is probably a good idea anyway, though, since there are already a bunch of other *Text system colors, so having one that's just Text is a little odd.

@css-meeting-bot
Copy link
Member

The CSS Working Group just discussed text system color conflicts with background-clip, and agreed to the following:

  • RESOLVED: Rename text keyword to CanvasText
The full IRC log of that discussion <dael> Topic: text system color conflicts with background-clip
<dael> github: https://github.com//issues/4465
<dael> TabAtkins: When we introduced the set of new good system colors we names one text. Means in BG shorthand supplying color text conflicts with clip of text.
<dael> TabAtkins: It's goingt o be a problem when we unprefix
<dael> TabAtkins: Proposal is rename text to canvas-text which matches other pairs. canvas-text is unambig and resolves situation
<dael> TabAtkins: And I dont think text was an old word
<dbaron> s/canvas-text/CanvasText/
<dael> fantasai: Anyone shipped?
<dael> TabAtkins: No. FF wanted to but ran into grammar
<dael> Rossen_: Same for us
<dael> fantasai: In favor. Makes sense and less likely to conflict
<dael> leaverou: Agree
<dael> myles: Worth tryign to come up with system to discover these ambig automatically?
<tantek> that's what CR is for, right? ;)
<dael> TabAtkins: Sounds like it would be valuable, but a bunch of work
<dael> AmeliaBR: TabAtkins write a bikeshed extension for all grammars ^-^
<dael> Rossen_: Objections to rename text to CanvasText?
<dael> smfr: I think WK has shipped text since KHTML days. Someone might be using it in the wild
<dbaron> Such a tool wouldn't have caught this because we haven't actually �written� the grammar for the background shorthand in backgrounds level 4.
<dael> TabAtkins: Really? Never appeared in list from Color 3. I didn't realize it was live
<dael> Rossen_: Sounds like only in WK
<dael> smfr: Don't know if Chrome removed it post-branch
<dael> Rossen_: I don't see in Chrome keywords
<dael> smfr: Other comment is I thought background clip text was being replaced by something in fill and stroke?
<dael> TabAtkins: Replaced but can't remove
<TabAtkins> Looks like Chrome has removed it: <body style="background-color: red; background-color: text;"> is red.
<dael> AmeliaBR: Shipped in FF unprefixed. One thing is issue is allow background clip text, but don't allow in the shorthand. More complicated to impl and spec vs changing the color keyword. If there is compat issue we want to know what the impact is
<dael> chris: Possible to have old text value as an alias so it works in the longhand but not allwoed in shorthand
<tantek> what about WindowText? noticed that's in the MDN docs: https://developer.mozilla.org/en-US/docs/Web/CSS/color_value
<dael> TabAtkins: Possible, but complexity we like to avoid if we can
<leaverou> UIText may work too
<dbaron> this is presumably different from WindowText since WindowText was a CSS 2.1 value
<TabAtkins> tantek, window/windowtext aren't a pair we chose to use
<tantek> cool TabAtkins, I guess we need to update MDN
<dael> fantasai: I think we should rename this. It's better usability and less complex. If we need to support a text keyword that means the same thing if we need it for compat we've got a bunch of mappings we have to do. WE should check and see if need to address. If not maybe WK drops. If so we figure out a way to handle
<dbaron> CSS 2.1 list is at https://www.w3.org/TR/CSS21/ui.html#system-colors
<dael> fantasai: AS far as system colors we're promoting CanvasText makes sense as will have less problems going forward
<dael> smfr: I'm okay trying to rename
<AmeliaBR> s/thing is issue/thing suggested in the issue/
<tantek> FYI Moz also has -moz-default-color User's preference for the text color.
<dael> Rossen_: Objections to renaming?
<dael> RESOLVED: Rename text keyword to CanvasText
<TabAtkins> tantek, windowtext is one of the deprecated colors; just not one of the good ones we're using for forced colors. MDN is fine.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants