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