- From: Lea Verou via GitHub <sysbot+gh@w3.org>
- Date: Wed, 16 Dec 2020 14:27:45 +0000
- To: public-css-archive@w3.org
> Could hue() accept a parameter instead of needing to be a separate function for HSL vs LCH? Allow folks to get picky wit-it when they want, but otherwise default them to something expected? I'm leaning towards that too, to keep the API surface small-ish. Same for `lightness()`. However, selecting a default has the problem that Chris pointed out: > if we get a better colorspace than Lab/LCH in the future, we are not stuck with "hue means hue in LCH for historical reasons". A few more questions we need to answer (@svgeesus @argyleink @una): - Do we agree to ditch both `color-adjust()` and the relative function syntax, and instead add functions for component extraction? - How many functions do we add for component extraction? It looks like the no brainers are `alpha()`, `hue()`, `lightness()`, `chroma()`, `saturation()`. - Do we also add `red()`, `green()`, `blue()`? They are used in SCSS (about 1% of pages each). If we do add them, can they extract components from RGB color spaces defined via `color()`, e.g. `display-p3`? - Do we need functions for Lab? If so, what to name them? I'd rather avoid single letter functions, but `lab-a` is inconsistent - Can browsers optimize something like `lch(300 chroma(var(--mycolor)) lightness(var(--mycolor)))` to avoid converting `var(--mycolor)` to LCH twice? If my co-editors agree and we reach consensus on these, I could make the edits. -- GitHub Notification of comment by LeaVerou Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5782#issuecomment-746376206 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 16 December 2020 14:27:47 UTC