Skip to content

[css-color-adjust-1] Add 'color-scheme: auto'? #3849

Closed

Description

@tabatkins

Rune's version of color-scheme gives "light" as the initial value, and assumes "light" if the user doesn't express a preference.

This is definitely what's required for web compat in general, but there are still minority user agents that do not render with a "light" style by default (and just accept that they're not always web-compatible).

I propose adding an "auto" value to 'color-scheme' to act as an initial value instead, indicating that the author has no idea what color schemes are, and so the UA should use the legacy "default" color scheme ("light" for maximum web-compatibility). This is currently in the spec, so you can see what it looks like.

Activity

  1. MatsPalmgren commented on Apr 19, 2019

    @MatsPalmgren

    @tabatkins I can't find this "css-color-adjust-1 spec" you are referring to. Link please?

  2. tabatkins commented on Apr 19, 2019

    @tabatkins
    MemberAuthor

    @MatsPalmgren The drafts server was stuck on a draft generation task from last night; the new spec should be up at https://drafts.csswg.org/css-color-adjust-1/ in a little while.

  3. quasicomputational commented on Apr 20, 2019

    @quasicomputational

    I think this is a good idea and it lets UAs DTRT in more cases. My only worry is that color-scheme: auto reads like it means something like 'use whatever colour scheme you want', rather than 'fall back to the default colour scheme, which is probably light for compatibility'. Can it be bikeshedded to color-scheme: legacy or color-scheme: compat or something?

  4. tabatkins commented on Apr 20, 2019

    @tabatkins
    MemberAuthor

    Yeah, on consideration, I think "none" would be the better term here actually. The property expresses which color schemes you're capable of handling, and the default is to assume they can't handle anything besides the default, thus "none".

  5. AmeliaBR commented on Apr 27, 2019

    @AmeliaBR
    Contributor

    My only worry is that color-scheme: auto reads like it means something like 'use whatever colour scheme you want',

    I agree.

    the default is to assume they can't handle anything besides the default, thus "none".

    I'm not sure that's better. It could be confused for appearance: none, suggesting that it would turn off all user agent color settings.

    I like default or legacy as keywords for the generic scheme. That also gives user agents the option to create nicer light color schemes in the future, without worrying about compatibility with the legacy late-90s default color scheme.

  6. css-meeting-bot commented on May 29, 2019

    @css-meeting-bot
    Member

    The CSS Working Group just discussed Add 'color-scheme: auto'?, and agreed to the following:

    • RESOLVED: Add color-scheme: normal
    The full IRC log of that discussion <dael> Topic: Add 'color-scheme: auto'?
    <dael> github: https://github.com//issues/3849
    <florian> call it "default" rather than "auto", and then I'm good with it
    <dael> fantasai: Original version had light as initial value. That's required for web compat. Some UAs don't render with light style and thye don't need to be web compat. Proposal is use auto and say if you're a UA that needs web compat you need to use light. If not you can use dark.
    <AmeliaBR> q+
    <dael> TabAtkins: This is distinct from any. THis is they author saying I don't know what color schemes are and you get default
    <dael> AmeliaBR: Light schemes are allowed to be more diverse then default, esp if sepia is a light scheme. That's not web compat. light default is assumed to be black on white. Worth dinstinguishing.
    <dael> AmeliaBR: Other thing is the keyword should make it clear this is default and not just auto in sense of do it smart
    <dael> TabAtkins: Perhaps none is right
    <dael> florian: I think default is good name
    <dael> TabAtkins: Shouldn't use default. That's a reserved global keyword
    <dael> florian: Okay
    <dael> fantasai: Normal is a possibility
    <dael> florian: sure
    <dael> myles: Reason against legacy?
    <dael> fantasai: Not necessarily legacy
    <dael> florian: Sounds deprecated
    <florian> normal
    <dael> Rossen_: Normal vs any. I hear sympathy to add this. Let's figure out name.
    <AmeliaBR> +1 to normal
    <dael> TabAtkins: no one is going any. Normal or auto
    <tantek> could live with normal
    <dael> smfr: WE don't want auto because WK thinks that means use what meta tag says
    <dael> Rossen_: Sounds like it's normal
    <tantek> metatag--
    <florian> tantek, +1
    <dael> Rossen_: We can try and resolve
    <dael> fantasai: Should we jsut add normal?
    <dael> TabAtkins: Use normal as the word, sure
    <futhark> +1 to normal
    <dael> fantasai: We'll do normal now and figure out weird WK stuff later
    <dael> Rossen_: Prop: Add color-scheme: normal
    <dael> Rossen_: Obj?
    <dael> RESOLVED: Add color-scheme: normal
  7. added a commit that references this issue on Jun 3, 2019
    dc3b172
  8. added a commit that references this issue on Jun 3, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions