/irc-logs / w3c / #css / 2014-07-18 / end

Options:

  1. # Session Start: Fri Jul 18 00:00:00 2014
  2. # Session Ident: #css
  3. # [00:13] * Joins: dauwhe_ (~dauwhe@public.cloak)
  4. # [00:13] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
  5. # [00:16] <TabAtkins> leaverou_away: Mind either chatting or posting about why you think authors will want to adjust hue on colors, then adjust their rgb values directly?
  6. # [00:46] * Quits: dauwhe_ (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
  7. # [00:50] * Joins: dauwhe (~dauwhe@public.cloak)
  8. # [00:57] * leaverou_away is now known as leaverou
  9. # [01:15] * Quits: plh (plehegar@public.cloak) ("Leaving")
  10. # [01:21] * Quits: glenn (~gadams@public.cloak) ("Leaving...")
  11. # [01:41] * Joins: lmclister (~lmclister@public.cloak)
  12. # [02:03] * nikos_ is now known as nikos
  13. # [02:07] * Quits: lmclister (~lmclister@public.cloak) ("")
  14. # [03:11] <liam> TabAtkins, I'm not Lea (honest!) but adjusting hue without affecting saturation of lightness/value, is pretty useful in colour work generally
  15. # [03:12] <leaverou> same with adjusting lightness (or luminance)
  16. # [03:13] <leaverou> liam: “prefers concat() to overloading + by the way, as it reduces surprises” Prog langs have been overloading + for —literally— decades, I’m sure authors are more than familiar with that.
  17. # [03:13] <TabAtkins> What I mean is, wanting to adjust hue *and*adjust redness, for example.
  18. # [03:14] <leaverou> that’s only because you rarely want to adjust redness in general
  19. # [03:14] <liam> oh, i read that as "rather than" instead of "an then"
  20. # [03:14] <TabAtkins> leaverou: I agree. ^_^
  21. # [03:14] <leaverou> the main case of adjusting red,green,blue is when writing a color picker type thing
  22. # [03:15] <liam> yeah, I happen to adjust redness (actually increasing greenness and blueness) a lot, but as colour correction for scanning, I don't see doing it that much otherwise
  23. # [03:16] <TabAtkins> leaverou: Note that making .h and friends a getter/setter also make author-defined color formats second-class citizens.
  24. # [03:16] <leaverou> authors can define getters/setters
  25. # [03:17] <TabAtkins> Yes, but they can't do so reliably
  26. # [03:17] <TabAtkins> For example, setting and then getting hire may result on ugly decimals.
  27. # [03:17] <leaverou> also, I think .h is really cryptic. People are used to recognize it as part of hsl, but on its own it just looks confusing
  28. # [03:17] <TabAtkins> That's a separate issue.
  29. # [03:17] <TabAtkins> Hire = hue
  30. # [03:18] <leaverou> yep, hence the “also”
  31. # [03:19] <leaverou> TabAtkins: re:decimals, that’s not because you’re using accessors, unless I’m missing something
  32. # [03:19] <TabAtkins> But yeah, side from since special values, storing RGB as the "true" color and sound conversions on the flu in getters/setters means you lose precision, which is confusing.
  33. # [03:19] <liam> every now and then in the gimp project we get bug reports from people using extreme values in "curves" in rgb mode and getting weirded out by the results
  34. # [03:19] <TabAtkins> c.h = 1; print(c.h); // not 1
  35. # [03:20] <leaverou> perhaps the getter should apply some degree of rounding first?
  36. # [03:22] <TabAtkins> Oh gosh no. You have no idea what the person actually wanted.
  37. # [03:23] <leaverou> will those issues be that significant if r,g,b are stored with enough precision?
  38. # [03:24] <TabAtkins> They'll be stored with normal Number precision. It's still weird.
  39. # [03:25] <leaverou> more weird than .1 + .2 != .3 ?
  40. # [03:25] <leaverou> I’d argue that anybody using JS to do any math is accustomed to precision issues of that sort
  41. # [03:28] <leaverou> TabAtkins: ^
  42. # [03:29] <TabAtkins> Not noticeably weird in the produced color, but weird in the "you can't actually test .h/s/l for certain values" way.
  43. # [03:29] <TabAtkins> Possibly.
  44. # [03:30] <TabAtkins> But there's still the .b collision, and the possible future collisions with any future directly-rgb-compatible things, including author-defined ones.
  45. # [03:31] <leaverou> I think .b is cryptic anyway, which is exactly why there is a collision. Even if you have separate classes, having something like myColor.b = 20 means nothing understandable, without looking at the rest of the code
  46. # [03:32] <TabAtkins> Plus the fact that it means invoking the conversion algorithm *at all times* if you're working in anything but literal rgb, as opposed to just when you actually need to convert in the current spec.
  47. # [03:32] <TabAtkins> Also: ugh, my connection is being *terrible* and slow right now, sorry about delayed responses.
  48. # [03:32] <leaverou> that’s an implementation detail. UAs could cache values internally until they change or something, if the author ends up only working in HSL. Implementation details shouldn’t complicate the UI
  49. # [03:33] <leaverou> there is one serious collision though
  50. # [03:33] <TabAtkins> (re: cryptic) Maybe, but expanding on the names means "mycolor.saturation", which is way longer than I want to use.
  51. # [03:33] <leaverou> and it’s saturation
  52. # [03:33] <leaverou> if HSV is ever added
  53. # [03:33] <TabAtkins> Right, those use different saturations.
  54. # [03:34] <TabAtkins> (Note that the spec has an example of adding HSV.)
  55. # [03:35] <leaverou> a 10 letter property though is hardly long, by any standards
  56. # [03:35] * Joins: lmclister (~lmclister@public.cloak)
  57. # [03:35] <TabAtkins> It is when you're doing a lot of color manipulation with it. ^_^
  58. # [03:35] <leaverou> yeah, but it pays off, as your code is more readable
  59. # [03:36] <TabAtkins> (A property that just gets read/set once per expression is fine to have a long name. Ones that get used together in math expressions are less fine with a long name.)
  60. # [03:36] <leaverou> that’s what variables are for
  61. # [03:36] * Quits: lmclister (~lmclister@public.cloak) ("")
  62. # [03:37] <leaverou> if extreme conciseness is a concern, I’d say we should start from querySelectorAll :P
  63. # [03:37] <TabAtkins> We are, with .query(). ^_^
  64. # [03:37] <leaverou> oh, is that going forward? Yay!
  65. # [03:37] <TabAtkins> Using variables as temporary renames is even more complication. :/
  66. # [03:38] <leaverou> single letter variables is a well established bad practice. I’d argue that single letter property names in an API are even worse.
  67. # [03:39] <TabAtkins> But they have a long history in this case. ^_^
  68. # [03:39] <TabAtkins> And they're directly reflected in the API name!
  69. # [03:40] <leaverou> the API name is an acronym. That doesn’t mean the letters stand by themselves. It’s like using S to mean Style in convserations, because CSS exists.
  70. # [03:41] <leaverou> (well, actually an initialism)
  71. # [03:41] <TabAtkins> Possibly, but I think that argument proves too much - it would imply that you can't ever use letters as slang for pieces of an initialism, regardless of context.
  72. # [03:44] <leaverou> there are very few cases where using letters for that purpose is easily understood
  73. # [03:44] <leaverou> and even in those cases, using the whole word is always more understandable
  74. # [03:45] <leaverou> if somebody loves single letter properties that much, there are ways to create aliases. I don’t think we should encourage such a practice by making the native API use single letter properties
  75. # [04:01] <TabAtkins> Anyway, the single-letter topic is a distraction. Even with fully-expanded property names, as you pointed out, .saturation conflicts between HSL and HSV.
  76. # [04:01] <TabAtkins> And it's reasonable to expect authors to use HSV, and potentially for us to add it in the future.
  77. # [04:07] <leaverou> TabAtkins: Yup. Still thinking about how that issue could be solved. :/
  78. # [04:08] <TabAtkins> Don't think it can be, without privileging HSL as "coming first" and forcing HSV to be a different class. (Which produces weird asymmetries that I don't like.)
  79. # [04:09] <liam> c.hsl.s
  80. # [04:10] <TabAtkins> liam: So that's just what I have now, but with a slightly different syntax.
  81. # [04:10] <TabAtkins> c.toHSL().s
  82. # [04:16] <liam> yeah, fair enough, and clearly exensible to HSV or LaB
  83. # [04:17] <liam> or YUV for that matter, for video
  84. # [04:17] <liam> is the conversion done in linear space?
  85. # [04:18] <TabAtkins> So far that's not relevant - I'm only converting between the CSS (directly RGB-compatible) formats, plus CMYK via the naive conversion.
  86. # [04:18] <TabAtkins> I assume that if we add support for formats like Lab it'll do work in linear space.
  87. # [04:19] <liam> ok
  88. # [04:20] <TabAtkins> Actually, though, I'm not sure - there'd be a difference in behavior between executing the HSL conversion depending on whether the RGB was gamma-corrected or not.
  89. # [04:20] <TabAtkins> I guess I'd have to see what it produced.
  90. # [04:20] <liam> yes
  91. # [04:20] <liam> (I don't have strong feelings either way, although with 8 bits per pixel you start getting banding in gradients if you're not careful)
  92. # [04:20] <TabAtkins> I'll do some testing tomorrow. (Or you can, if you feel like having fun.)
  93. # [04:20] * liam is (sadly not literally) tied up this evening
  94. # [04:21] <liam> i've been watching the gimp project go through a lot of this though, in the move to higher bit depth & graph-based editing
  95. # [04:32] * Joins: tommyliu (~technommy@public.cloak)
  96. # [04:34] * Quits: tommyliu (~technommy@public.cloak) (Client closed connection)
  97. # [04:34] * Joins: tommyliu (~technommy@public.cloak)
  98. # [04:41] * Quits: tommyliu (~technommy@public.cloak) (Ping timeout: 180 seconds)
  99. # [05:08] * Joins: tommyliu (~technommy@public.cloak)
  100. # [05:57] * Joins: florian (~Adium@public.cloak)
  101. # [06:01] * Joins: tommyliu_ (~technommy@public.cloak)
  102. # [06:01] * Quits: tommyliu (~technommy@public.cloak) (Client closed connection)
  103. # [06:05] * Quits: florian (~Adium@public.cloak) ("Leaving.")
  104. # [06:59] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
  105. # [07:25] * leaverou is now known as leaverou_away
  106. # [07:31] * leaverou_away is now known as leaverou
  107. # [07:32] * leaverou is now known as leaverou_away
  108. # [07:33] * Joins: dbaron (~dbaron@public.cloak)
  109. # [07:52] * leaverou_away is now known as leaverou
  110. # [07:56] * leaverou is now known as leaverou_away
  111. # [08:21] * leaverou_away is now known as leaverou
  112. # [08:43] * Joins: dwim (~dwim@public.cloak)
  113. # [09:17] * leaverou is now known as leaverou_away
  114. # [09:20] * leaverou_away is now known as leaverou
  115. # [09:33] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
  116. # [10:27] * Joins: Ms2ger (~Ms2ger@public.cloak)
  117. # [11:54] * leaverou is now known as leaverou_away
  118. # [11:56] * leaverou_away is now known as leaverou
  119. # [12:03] * leaverou is now known as leaverou_away
  120. # [12:55] * Joins: tommyliu (~technommy@public.cloak)
  121. # [12:55] * Quits: tommyliu_ (~technommy@public.cloak) (Client closed connection)
  122. # [13:03] * Quits: tommyliu (~technommy@public.cloak) (Client closed connection)
  123. # [13:04] * Joins: tommyliu (~technommy@public.cloak)
  124. # [13:11] * Quits: tommyliu (~technommy@public.cloak) (Ping timeout: 180 seconds)
  125. # [13:37] * Joins: tommyliu (~technommy@public.cloak)
  126. # [15:04] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
  127. # [15:05] * Joins: dauwhe (~dauwhe@public.cloak)
  128. # [15:22] * Joins: dwim_home (~Dongwoo@public.cloak)
  129. # [16:17] * Quits: tommyliu (~technommy@public.cloak) (Ping timeout: 180 seconds)
  130. # [16:20] * Joins: tommyliu (~technommy@public.cloak)
  131. # [16:33] * Quits: tommyliu (~technommy@public.cloak) (Ping timeout: 180 seconds)
  132. # [16:39] * Joins: tommyliu (~technommy@public.cloak)
  133. # [16:57] * Joins: plh (plehegar@public.cloak)
  134. # [17:05] * Quits: tommyliu (~technommy@public.cloak) (Client closed connection)
  135. # [17:12] * Joins: tommyliu (~technommy@public.cloak)
  136. # [18:11] * Joins: tommyliu_ (~technommy@public.cloak)
  137. # [18:14] * Quits: tommyliu (~technommy@public.cloak) (Ping timeout: 180 seconds)
  138. # [18:19] * Joins: adenilson (~anonymous@public.cloak)
  139. # [18:20] * Joins: dbaron (~dbaron@public.cloak)
  140. # [18:45] * Joins: lmclister (~lmclister@public.cloak)
  141. # [19:05] * Quits: darktears (~darktears@public.cloak) (Client closed connection)
  142. # [19:09] * Joins: darktears (~darktears@public.cloak)
  143. # [19:15] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
  144. # [19:55] * Quits: tommyliu_ (~technommy@public.cloak) (Client closed connection)
  145. # [20:03] * Joins: tantek (~tantek@public.cloak)
  146. # [20:11] * Quits: Ms2ger (~Ms2ger@public.cloak) (Ping timeout: 180 seconds)
  147. # [20:15] * Joins: dauwhe (~dauwhe@public.cloak)
  148. # [20:17] * Joins: Ms2ger (~Ms2ger@public.cloak)
  149. # [20:22] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
  150. # [20:52] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
  151. # [21:16] * Joins: dauwhe (~dauwhe@public.cloak)
  152. # [21:23] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
  153. # [21:38] * Quits: Ms2ger (~Ms2ger@public.cloak) ("nn")
  154. # [22:32] * Joins: dbaron (~dbaron@public.cloak)
  155. # [22:43] <SimonSapin> fantasai: Sed Driven Development: https://github.com/mozilla/servo/commit/1807c29
  156. # [23:31] * Quits: lmclister (~lmclister@public.cloak) ("")
  157. # [23:40] * Quits: darktears (~darktears@public.cloak) (Client closed connection)
  158. # [23:43] * Quits: adenilson (~anonymous@public.cloak) (adenilson)
  159. # Session Close: Sat Jul 19 00:00:00 2014

The end :)