-
Notifications
You must be signed in to change notification settings - Fork 715
[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
Comments
Bikeshed: rename color:Text to CanvasText (which would be consistent with Canvas)...though I kinda hate the name. |
CanvasText sounds fine to me, given the parallel with all other *Text names. |
I'd note that it seems likely that one reason implementations differ here is that the level of css-backgrounds (level 4) that defines I'd note that another option is to say that not all I'd also note that "make this behavior change" isn't super-clear, since you need to define the behavior of:
I think renaming the |
The CSS Working Group just discussed
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. |
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 setbackground-clip: text
.Firefox does this already:
background: linear-gradient(red, blue) text
parses asbackground-image: linear-gradient(..); background-clip: text; background-*: initial
.The system colors introduced in css-color-4 (#4091) include a
Text
value, which conflicts withbackground-clip: text
in the background shorthand.That means that the previous example will start parsing as
background-color: text
rather thanbackground-clip: text
, which is a significant behavior change.So we have multiple options I guess:
background-clip: text
on the background shorthand as of now). This would be a bit unfortunate, but probably ok?text
system color to something else, to prevent the naming conflict.cc @melanierichards @dbaron
The text was updated successfully, but these errors were encountered: