[css-typed-om] Spec up ColorValue

[shans]

No description provided.

[nainar]

@tabatkins

[shans]

This should probably be a different class for each of the broad color types, along with converters between the different classes.

[kenchris]

Maybe it should not be prefixed with CSS and it would probably make sense using the same across Web and Node.js and many APIs needs to deal with color. Maybe this could even go into JS proper at some point. @anssiko

[grorg]

I can't imagine that ES-whatever would accept a proposal for a Color type. I can't think of any other language that has that as a primitive (maybe PostScript?).

It's probably better to focus on just the CSS OM use case.

[nainar]

After discussing this with Tab the suggestion is to adopt the strategy here which adds different classes for all the different ways we can represent color, for example hsl, rgba, lab, etc in Typed OM 1.

In Typed OM 2 we can look at adding extensible functions/objects which was also part of this change.

[nainar]

@dbaron and @gregwhitworth WDYT here?

[gregwhitworth]

@nainar in the link you provided, I see a ton of deleted spec text, with some additional JS lines of JS. Am I supposed to read the deleted spec text as your proposal for L1 of TypedOM? Sorry for the confusion.

[tabatkins]

Yeah, the section that was deleted there. (To see it in-spec, check out that commit's parent, then run bikeshed on it.) Proposal is to spec up a CSSColorValue abstract base class (like CSSNumericValue, only to group some related methods), and then individual classes corresponding to each of the color functions, with easy inter-conversion between them.

(Since everything but device-cmyk() has a colorspace associated with it, interconversion is pretty simple.)

[plinss]

...or click the history icon (rewinding clock) on the draft server home page to see the complete list of a draft's pushes and click the date/time link to see any previous version as generated by bikeshed at the time.
e.g.: https://drafts.css-houdini.org/history/css-typed-om/

Or just use a dated url to see a draft at any particular time, e.g.:
https://drafts.css-houdini.org/date/2016-09-13T00:33:42/css-typed-om/
or
https://drafts.css-houdini.org/date/2016-09-13/css-typed-om/

No need to run bikeshed locally on previous versions (the dated/history urls also give you the output that the version of bikeshed and the spec database generated at the time, as opposed to running a current bikeshed on an old spec).

[css-meeting-bot]

The Working Group just discussed Spec up ColorValue, and agreed to the following resolutions:

• RESOLVED: Tab works on Color value proposal he has, and we can look into it later.

The full IRC log of that discussion

<nainar> Topic: Spec up ColorValue
<nainar> Github: https://github.com//issues/159
<nainar> TabAtkins: need a way to represent color values in TypedOM - hide complexity from dev
<nainar> TabAtkins: Had a chunk of code in color module. that gace us a chunk of classes to represent colors and change between them. Transplant that into Typed OM as implementation of Color type.
<nainar> TabAtkins: Any other ideas?
<TabAtkins> https://github.com/w3c/csswg-drafts/commit/85434cb3e0cfa862045ef5178e1720b9ad593d1f#diff-1b39a8c21cc4d6d69673bf20b5226d33
<nainar> TabAtkins: that be diff
<nainar> dbaron: is this about specified or computed colorvalues
<nainar> TabAtkins: Both?
<nainar> TabAtkins: you need an object representation of this. Specified matched author specified. COmput4ed not as much
<nainar> dbaron: computed color values - there are web compat constraints - or dev expectation constraints
<nainar> dbaron: there are althoughcases where color have separate serialization for devtools for those that are web exposed
<TabAtkins> https://drafts.csswg.org/date/2016-05-11T00:33:42/css-color-4/#apis
<nainar> astearns: do we have to meet dev expectations in typed om
<nainar> dbaron: Yes ...
<TabAtkins> ^^^ The Color spec before the API was removed.
<nainar> dbaron: make sure works with wide gamut
<dbaron> s/gamut/gamut etc./
<nainar> TabAtkins: Didnt have wider gamut at the time of that text. Need to do some rejigging - not hard.
<nainar> TabAtkins: does the group feel that deisgn works? It is explicityly allowing dev to specify what mode they are manipulating it in? Or do somethign simpler that is more diff to work in
<nainar> TabAtkins: if you are working in RGB and you get it out in HSLO not equivalent
<TabAtkins> (If underlying value is just an RGB triple, and you set .hue and then read it back out, the value probably isn't equivalent.)
<nainar> surma: I like th old API. Expose to developers what was specified. HSL used -> they should get h, , L values
<nainar> TabAtkins: someone propsed for RGB equivalent atach all syntaxxes and accessors.
<nainar> TabAtkins: problem with that therer is conflict with shorthand in channel
<nainar> TabAtkins: 2diff notions of lightness depending onn whatyou are doing
<nainar> TabAtkins: hence the complete separate interfaces
<nainar> TabAtkins: yay ? nay?
<nainar> TabAtkins: or should we discuss a simpler API
<trackbot> Sorry, but no Tracker is associated with this channel.
<nainar> Rossen: can discuss simpler API as you make changes
<nainar> astearns: its a lot fo spec text but its laid out well
<nainar> surma: any disadvantage?
<nainar> TabAtkins: more to code/test
<RRSAgent> logging to https://www.w3.org/2017/11/09-houdini-irc
<Ralph> rrsagent, please make record public
<RRSAgent> I have made the request, Ralph
<nainar> astearns: disadv I can think of -> converters for each format were in each format. Simpler interface that allows you to convert btw represntations
<Ralph> trackbot, associate this channel with #css
<trackbot> Associated this channel with #css.
<nainar> TabAtkins: designed such -> you can addas many converters as needed. All that is required is to define toRGB version. Tha you can use with some fidelity loss
<trackbot> RRSAgent, make logs public
<RRSAgent> I have made the request, trackbot
<trackbot> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
<trackbot> Date: 09 November 2017
<nainar> TabAtkins: if you wanted to convert from HSL to RGB you may lose hue info....
<nainar> astearns: dont know enough about various information, looking at duping in spec text. partial version that could be a mixin of specific versions
<nainar> TabAtkins: Things are currently relying on internal implementations
<nainar> astearns: then there are details that I dont know much about. Ignore me.
<nainar> Rossen: <tries to solicit other opinion>
<nainar> xidorn: i dont think we need hex color class - useless to RGB and .. colors.
<nainar> TabAtkins: ditinctin that it preserves knowledge of how to serialize. Imp if you want specified color to be close to what you are ..
<nainar> dbaron: syntax could be bool in single class
<dbaron> s/bool/bool or enum/
<nainar> TabAtkins: yes. I did distinguish RGB is 0 to 1 in channel, Hex can represent 0-255 (numbers)
<nainar> dbaron: RGB doesnt allow outside of 0 to 1?? HAVE WE DECIDED
<dbaron> s/HAVE WE DECIDED/Have we decided?/
<TabAtkins> TabAtkins: Putting that to the side, even within the 0-1 range rgb() allows more detail than hex
<nainar> xidorn: if we want to preserver serialization - hex color has 3/4 ways to srialize. How canyou presever that?
<nainar> TabAtkins: We are preserving general syntx
<nainar> TabAtkins: fff -> serializes as ffffff
<nainar> TabAtkins: this was before alpha was declarable in hex syntax
<nainar> TabAtkins: if we want to preseve to that detail - need to track more information.
<nainar> TabAtkins: we have the concept of specifed values - OM can remember the string they were generated from and can serialize to that. But once you manipiulate they serialize to standrd way
<nainar> TabAtkins: so we can jsut rely on that? Authors can get syntax they put in
<nainar> TabAtkins: Does that work for everyone? RGB fucntion too needs to track the diff values
<nainar> dbaron: RGB allows either % or number but not a mix?
<dbaron> s/RGB/rgb()/
<nainar> TabAtkins: More flags that need tracking - to keep author syntax beyond what they put in.
<nainar> dbaron: Hard to keep track of proposal - generally happier with fewer classes. No strong opinion other than dont break the other stuff
<nainar> TabAtkins: Guarantee it wont break other contraints. Defo more classes approach.
<nainar> surma: which is what we have with lengthvalues
<nainar> TabAtkins: Nope that you specify the unit separately.
<nainar> dholbert: Why not that approach for colors?
<nainar> TabAtkins: Doing so because channels are named in conflicting - even if you use full name. HSL and LCH have different lightness notions
<nainar> dholbert: Alterntive - enum saying this color is lCH/HCL.
<nainar> TabAtkins: How you manipulate
<nainar> dholbert: you know what it is internally. If you know somethign is HSL convert as so?
<nainar> TabAtkins: API will ahve attributes for all channels and knows whqt to return depending onw hat channel
<nainar> dholbert: Change represetation under hood depending on channel
<nainar> dbaron: setters like that - you amy want to set multiple in sequence. If you want to set all of H,S,L then you want it to be like you specified all three separately. If underlying representation is somethign else - changing the color so thta if H or S or L is somthing. You dont get the needed HSL color
<TabAtkins> TabAtkins: MOst particularly, if your underlying valu eis rgb, and you set a saturation to 0, the hue information has disappeared and you can't get it back.
<nainar> TabAtkins: More dramatic version of the specified is what you get.
<nainar> TabAtkins: Not comfortable with the large tagged union.
<nainar> fremy: crrentColor needs tobe represented but you cant set HSL on it.
<nainar> TabAtkins: its just a keyword
<nainar> surma: keywords liek red, bue are aliases? Or string?
<nainar> TabAtkins: Turned into rgb/hex color.
<nainar> TabAtkins: if you are setting that - the specified value will remember what it was generated from andsrialize approriately.
<nainar> xidorn: How would you handle currntColor?
<nainar> TabAtkins: return as CSSKeywrodValue. A Typed OM class
<nainar> TabAtkins: you may get a keyword value for Color Vlaue
<nainar> TabAtkins: Have to do that since currentColor is generally calculated at runtime,
<nainar> s/runtime/used value time
<nainar> Rossen: have you played with this in Paint?
<nainar> TabAtkins: can do cause spec text i raw JS
<nainar> RESOLVED: Tab works on Color value proposal he has, and we can look into it later.

[nainar]

Moving this to Level 2 since this needs speccing and feedback and is risky.

[mnpenner]

I hate to be that guy, but it's been two years. Any updates you guys can share with us?

[svgeesus]

Perfectly reasonable to ask what is up!

There was good discussion at the June 2020 virtual face to face meeting which was mostly in the context of color conversion code in Typed OM. Here are the minutes.

[svgeesus]

So ColorValue now appears to be well specced-out.

Close?