Skip to content

[css-color-adjust] [css-color-adjust] Initial value of the color property. #9274

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.

Sign up for GitHub

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

Jump to bottom
Closed
emilio opened this issue Aug 30, 2023 · 8 comments
Closed

[css-color-adjust] [css-color-adjust] Initial value of the color property. #9274

emilio opened this issue Aug 30, 2023 · 8 comments
Labels
css-color-4 Current Work css-color-adjust-1 Current Work

Comments

@emilio
Copy link
Collaborator

emilio commented Aug 30, 2023

Consider this test-case (live):

<!doctype html>
<html style="color-scheme:dark">Root
  <div style="color:red">child div
    <span style="color: initial">what color is this span?</span>
    <span style="color: initial; color-scheme: light">And this?</span>
  </div>
</html>

Browsers disagree on what the behavior is:

  • In Firefox and Safari, the initial color value is still black.
  • In Chrome, the initial color behaves like an explicit CanvasText.

Right now the specs specify neither behavior.

From https://drafts.csswg.org/css-color-4/#the-color-property:

Initial: CanvasText

Initial values are generally computed values, which means that you use the default color scheme, which comes from the <meta name=color-scheme> tag, absent in this test-case.

But then from https://drafts.csswg.org/css-color-adjust/#color-scheme-effect:

On the root element, the used color scheme additionally must affect the surface color of the canvas, the initial value of the color property, and the viewport’s scrollbars.

Which I understand it as "the second span should still have white text".

Test-case with <meta name=color-scheme> here for reference.

I think all browser's behavior make some sense in a way, and are reasonably easy to implement (Chromium's behavior seems to be some sort of special-case where they treat initial much like CanvasText). But the spec behavior is rather weird.

I think Chromium's behavior is the most intuitive and would be ok resolving to do that, but happy to hear other opinions.

@lilles it seems this comes from a647cfd which seems directly from your spec draft. Is the spec behavior being different from Chromium's behavior intentional? I'm guessing not? :)

cc: @smfr @jfkthame @svgeesus @tabatkins
@tabatkins
Copy link
Member

Initial values are generally computed values, which means that you use the default color scheme, which comes from the tag, absent in this test-case.

Wait, can you explain this more? I'm not quite sure I follow your reasoning.

Which I understand it as "the second span should still have white text".

Note that the Color Adjust text is from 2019, predating the commit that changed 'color''s initial value from black to CanvasText which is from 2020. I think you're just getting confused by some dated text, meant to be an override at the time, which should now be removed since the initial value achieves what was intended more directly.

@emilio
Copy link
Collaborator Author

emilio commented Aug 31, 2023

Wait, can you explain this more? I'm not quite sure I follow your reasoning.

This is probably an implementation detail (though I recall WebKit working the same way in the past at least?). The way initial / reset are implemented are by pulling from a shared ComputedStyle object, since it's a computed style, has system colors already resolved.

I think this is the only case where initial needs a specified value. That said this is not unimplementable / hard to do, it's just "weird" compared to all other structs.

I think you're just getting confused by some dated text, meant to be an override at the time, which should now be removed since the initial value achieves what was intended more directly.

Well the dated text is doing something different from CanvasText, that is my point.

@lilles
Copy link
Member

lilles commented Aug 31, 2023

One piece of history here might be that the system keywords were specified to compute to themselves at some point, and that the resolved/used value would take color-scheme into account. In that case it would be obvious to me that the root element and first span should have white color and the second span black color.

I think the "initial value of the color property" statement predates the CanvasText initial value.

This spec text from css-color-adjust also looks like it's assuming system keywords compute to themselves since it's talking about affecting the used value:

For all elements, the user agent must match the following to the [used color scheme](https://drafts.csswg.org/css-?
color-adjust/#used-color-scheme):

In short, I think the Blink behavior makes sense, but we probably need to do some adjustments in the specs.

svgeesus added a commit that referenced this issue Oct 2, 2023
@svgeesus
[css-color-adjust-1] No longer a need to override initial value of co…
7b084cf 
…lor propoerty. #9274
@svgeesus
Copy link
Contributor

svgeesus commented Oct 2, 2023

Note that the Color Adjust text is from 2019, predating the commit that changed 'color''s initial value from black to CanvasText which is from 2020. I think you're just getting confused by some dated text, meant to be an override at the time, which should now be removed since the initial value achieves what was intended more directly.

Done.

@svgeesus
Copy link
Contributor

svgeesus commented Oct 2, 2023

From CSS Color 4, 14.1. Resolving sRGB values

If the sRGB color was explicitly specified by the author as a named color, or as a system color, the specified value is that named or system color, converted to ASCII lowercase. The computed and used value is the corresponding sRGB color, paired with the specified alpha channel (after clamping to [0.0, 1.0]) and defaulting to opaque if unspecified).

So, remove this?

the used value of the system colors

svgeesus added a commit that referenced this issue Oct 26, 2023
@svgeesus
[css-color-adjust-1] No longer a need to override used value of syste…
b74679e 
…m colors. #9274
@svgeesus
Copy link
Contributor

@emilio all good now?

@svgeesus
Copy link
Contributor

@emilio I believe this is all correct now, do you agree? If so the issue can be closed.

@emilio
Copy link
Collaborator Author

emilio commented Nov 28, 2023

Yes

@emilio emilio closed this as completed Nov 28, 2023
@svgeesus svgeesus removed the Agenda+ label Nov 28, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
css-color-4 Current Work css-color-adjust-1 Current Work
Projects
TPAC 2023 agenda
Status: Unslotted
Milestone
No milestone
Development

No branches or pull requests
4 participants
@tabatkins @lilles @emilio @svgeesus