/irc-logs / w3c / #css / 2008-05-15 / end

Options:

  1. # Session Start: Thu May 15 00:00:00 2008
  2. # Session Ident: #css
  3. # [00:01] <hyatt> people seem to really want them though
  4. # [00:06] <Bert> Some power users, yes. But if they are worth anything they should be capable of finding other solutions, there are dozens of macro languages. I'm concerned that people who want to do the right thing (use style sheets) will not be able to, because we don't provide any alternative language that is simpler than CSS.
  5. # [00:08] <Bert> I don't know about you, but I use more awk than perl or C. It's not as powerful, but that actually helps getting (most) jobs done quicker.
  6. # [00:09] <hyatt> i feel like adding variables is listening to our constituents :)
  7. # [00:09] <hyatt> since it is quite possibly the most-requested feature i've seen for css
  8. # [00:10] <hyatt> ok, spread done.
  9. # [00:10] <hyatt> that wasn't too bad
  10. # [00:10] <hyatt> although i haven't tested it ;)
  11. # [00:10] <fantasai> heh
  12. # [00:10] <fantasai> I still haven't got to updating the spec
  13. # [00:10] * fantasai is working down the issues list
  14. # [00:11] <fantasai> just checked in fallback color syntax changes
  15. # [00:12] <hyatt> well it doesn't work
  16. # [00:12] <hyatt> so i don't win yet ;)
  17. # [00:13] <fantasai> Bert: for no-clip, I think images that repeat should continue to repeat all the way out
  18. # [00:13] <Bert> That's the problem with CSS at the moment: no shortage of demands for features, but no way to ask for no features :-(
  19. # [00:14] <fantasai> Bert: completely useless for repeat in both directions, but may be useful for repeat-x
  20. # [00:14] <Bert> Repeat all the way? That doesn't sound very useful...
  21. # [00:14] <hyatt> no-clip?
  22. # [00:14] <hyatt> what is no-clip?
  23. # [00:14] <Bert> Like 'overflow' for background images
  24. # [00:14] <fantasai> background-clip: no-clip
  25. # [00:14] <fantasai> http://lists.w3.org/Archives/Public/www-style/2008May/0148.html
  26. # [00:15] <fantasai> ISSUE-16
  27. # [00:15] <hyatt> how far out does a tiled background go?
  28. # [00:15] <hyatt> when you do no-clip?
  29. # [00:16] <fantasai> that's what I was asking.. Bert suggested clipping any tile that doesn't at least fit partially within the border box
  30. # [00:16] <fantasai> I'm thinking we should not clip it at all, let it stretch out as far as the canvas goes
  31. # [00:17] <hyatt> what's a use case for that
  32. # [00:17] <hyatt> if it's going to fill the whole canvas anyway, why not just put it on the <body> instead
  33. # [00:18] <fantasai> positioning
  34. # [00:19] <hyatt> i don't think you should extend over the whole canvas necessarily
  35. # [00:19] * hyatt is thinking of opacity for example
  36. # [00:19] <hyatt> where you are in an offscreen bitmap while rendering
  37. # [00:20] <hyatt> would suck to force the transparency layer to have to grow to become as big as the canvas
  38. # [00:20] * hyatt heh
  39. # [00:20] <hyatt> and what about a rotated box with this set
  40. # [00:20] <hyatt> would it really spill all over the canvas in rotated form
  41. # [00:21] <hyatt> i guess it all works
  42. # [00:21] <hyatt> it just seems like it could be abused to make pretty slow web pages
  43. # [00:21] <fantasai> yeah, I know
  44. # [00:21] <fantasai> but the other options seem kind arbitrary
  45. # [00:21] <hyatt> fwiw i do need no-clip for mask-clip
  46. # [00:22] <fantasai> ?
  47. # [00:22] <hyatt> the new mask properties that i added
  48. # [00:22] <hyatt> right now mask-clip defaults to border
  49. # [00:22] <hyatt> which means the mask clips out everything outside the border
  50. # [00:22] <hyatt> a better default for mask-clip would in fact be soemthing like no-clip
  51. # [00:23] <hyatt> so that overflow doesn't get clipped out by the mask by default even when it is visible
  52. # [00:23] <hyatt> (as happens now)
  53. # [00:23] * hyatt (with shadows for example)
  54. # [00:23] * fantasai has no idea what mask-* would do, but ok :)
  55. # [00:23] <hyatt> i haven't written it up yet since i don't want to bombard the list with proposals
  56. # [00:23] <hyatt> one thing at a time
  57. # [00:24] <fantasai> I probably wouldn't have read it even if you had posted it
  58. # [00:24] <fantasai> :)
  59. # [00:24] * fantasai hasn't read the transitions stuff yet either
  60. # [00:28] <hyatt> yeah i think apple wants to start with one module at a time
  61. # [00:28] <hyatt> in terms of working on one
  62. # [00:28] <hyatt> probably transitions
  63. # [00:29] <hyatt> and maybe transforms too
  64. # [00:31] <fantasai> http://dev.w3.org/csswg/css3-background/#the-box-shadow
  65. # [00:31] <fantasai> Do I need to add more explanation?
  66. # [00:37] <fantasai> hyatt: ^
  67. # [00:39] <hyatt> for spread?
  68. # [00:39] <fantasai> yeah
  69. # [00:40] <hyatt> depends on if you're trying to specify down to the pixel how the spread should look
  70. # [00:40] <hyatt> you don't do that with blur
  71. # [00:40] <hyatt> so i see no reason to necessarily do it with spread
  72. # [00:40] <hyatt> although informally we kind of all need to know how it should look :)
  73. # [00:41] <fantasai> I think spread is simple enough that we can specify it, well, not down to pixel-rounding but down to the pixel in terms of ideal size and shape
  74. # [00:42] <hyatt> for box-shadow it is as though you the shadow was cast by a larger box
  75. # [00:42] <fantasai> i.e. it should be clear that pointed corners get more round as the radius increases
  76. # [00:42] <fantasai> not exactly
  77. # [00:43] <hyatt> cast by a larger box, shifted up and to the left by the spread size,and then still clipped out by the original box
  78. # [00:43] <fantasai> that would give you sharp corners
  79. # [00:43] <hyatt> why?
  80. # [00:43] <fantasai> a sharp (non-blurred) box shadow has sharp corners
  81. # [00:43] <hyatt> the corners round even with a non-rounded box?
  82. # [00:44] <fantasai> yes
  83. # [00:44] <hyatt> why?
  84. # [00:44] <fantasai> that's what I was trying to point out with the corners on the A
  85. # [00:45] * hyatt doesn't really understand why spread should cause rounding at corners
  86. # [00:46] <fantasai> both mockups we got on www-style (from 2 different people) rounded the corners
  87. # [00:46] <hyatt> it would probably be worth asking them why
  88. # [00:46] <hyatt> and what this spread algorithm actually is that rounding would start occurring like that
  89. # [00:47] <hyatt> i don't really get how you'd start rounding the joins of glyphs
  90. # [00:47] <fantasai> I explained that already
  91. # [00:47] <hyatt> short of stroking the entire path yourself
  92. # [00:47] <fantasai> you are adding to the shadow any pixel that is within X distance of the edge of the shadow
  93. # [00:47] <fantasai> and at corners, that will cause the outline to become round
  94. # [00:48] <fantasai> as for why it does that in their mockups, probably because that is what Photoshop does
  95. # [00:48] * hyatt doesn't get why that causes rounding though
  96. # [00:49] <fantasai> draw a box and get a piece of string
  97. # [00:49] <fantasai> or a compass
  98. # [00:49] <hyatt> so this is nothing like thickening the glyph or the box then
  99. # [00:49] <hyatt> you can't impl it that way
  100. # [00:49] <fantasai> at a 90deg corner, to get a sharp corner, you'd need the corner to go out sqrt(2)*radius
  101. # [00:50] <hyatt> sure, that's not really anything like what bert was saying though
  102. # [00:50] <hyatt> that is not a thickened glyph
  103. # [00:50] * hyatt or box
  104. # [00:50] <hyatt> and it's unclear what the spread pixels are supposed to be then
  105. # [00:50] <hyatt> i.e., when the blur starts to kick in
  106. # [00:51] <hyatt> is the spread the shadow color if you're within the spread distance from the edge
  107. # [00:51] <fantasai> yes
  108. # [00:51] <hyatt> and the blur only happens once you are outside the spread edge?
  109. # [00:51] * fantasai looks more closely at the diagrams
  110. # [00:53] <fantasai> looks like the blur is centered on the edge of the spread radius
  111. # [00:54] * Quits: ChrisWilson (cwilso@131.107.0.73) (Ping timeout)
  112. # [00:55] * fantasai flicks on her desk lamp and plays with some notebooks
  113. # [00:57] <fantasai> what does WebKit do? (assuming zero spread)
  114. # [00:57] * hyatt is having a baby crisis. i'll bbl
  115. # [00:58] * hyatt is now known as hyattBBL
  116. # [01:02] * fantasai also takes a break
  117. # [01:16] <dbaron> fantasai, er, ignore the first part of the message I just sent to www-style; but the spec should probably say something explicitly either way about the second (whether border-image affects the computed value of border-width)
  118. # [01:16] <dbaron> (I just saw the first part is fixed already in the dev.w3.org version.)
  119. # [01:54] * Quits: Arron (arronei@131.107.0.73) (Quit: Arron)
  120. # [02:21] * hyattBBL is now known as dhyatt
  121. # [02:21] * dhyatt is now known as hyatt
  122. # [02:40] <hyatt> fantasai: ok i understand spread
  123. # [02:40] <hyatt> fantasai: the rounding is basically making an assumption
  124. # [02:40] <hyatt> that the line join style on the stroke is round instead of miter
  125. # [02:41] <hyatt> the stroking support we have in webkit for text does miter join
  126. # [02:41] <hyatt> and doesn't allow you to change it
  127. # [02:41] <hyatt> but that is basically what the spread algorithm is doing in brad's picture
  128. # [02:41] <hyatt> it's as though you took the original object
  129. # [02:42] <hyatt> combined it with a stroke around the object (that uses round joins)
  130. # [02:42] <hyatt> and then took that resultant shape's shadow and drew it
  131. # [02:43] <hyatt> it's not clear to me that round joins are always what you want just because you happened to spread the shadow
  132. # [02:59] <hyatt> fantasai: i replied to brad about this on the list
  133. # [03:24] <fantasai> ok
  134. # [04:12] * Quits: bjoern (bjoern@84.57.250.218) (Quit: Quit)
  135. # [04:47] * Quits: dbaron (dbaron@63.245.220.241) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  136. # [05:17] * Joins: dbaron (dbaron@71.204.153.3)
  137. # [06:43] * Quits: hyatt (hyatt@98.200.231.139) (Connection reset by peer)
  138. # [09:18] * Quits: dbaron (dbaron@71.204.153.3) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  139. # [09:26] * RRSAgent excuses himself; his presence no longer seems to be needed
  140. # [09:26] * Parts: RRSAgent (rrs-loggee@128.30.52.30)
  141. # [09:34] * Joins: bjoern (bjoern@84.56.239.246)
  142. # [11:18] * Joins: Bert_ (bbos@128.30.52.28)
  143. # [11:27] * Quits: Bert_ (bbos@128.30.52.28) (Quit: leaving)
  144. # [13:16] * Joins: myakura (myakura@125.207.238.47)
  145. # [16:03] * Parts: anne (annevk@213.236.208.22)
  146. # [16:03] * Joins: anne (annevk@213.236.208.22)
  147. # [17:57] * Quits: alexmog (alexmog@131.107.0.103) (Ping timeout)
  148. # [18:02] * Joins: alexmog (alexmog@131.107.0.101)
  149. # [18:03] * Joins: ChrisWilson (cwilso@131.107.0.71)
  150. # [18:25] * Quits: myakura (myakura@125.207.238.47) (Quit: Leaving...)
  151. # [18:39] * Joins: sharovatov (vsh@83.239.161.121)
  152. # [18:45] * Joins: dbaron (dbaron@71.204.153.3)
  153. # [21:10] * Quits: ChrisWilson (cwilso@131.107.0.71) (Ping timeout)
  154. # [21:11] * Quits: dbaron (dbaron@71.204.153.3) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  155. # [21:31] * Joins: dbaron (dbaron@63.245.220.241)
  156. # [22:24] * Disconnected
  157. # [22:24] * Attempting to rejoin channel #css
  158. # [22:24] * Rejoined channel #css
  159. # [22:24] * Topic is 'CSS Working Group Discussion -- Logged at http://krijnhoetmer.nl/irc-logs/'
  160. # [22:24] * Set by anne on Mon Apr 21 15:34:48
  161. # [22:25] * Quits: krijnh (krijnhoetm@213.84.148.98) (Connection reset by peer)
  162. # [22:43] * Quits: sharovatov (vsh@83.239.161.121) (Quit: HTTP is like vodka (colorless, tasteless, and flavorless): connectionless, stateless, and one way))
  163. # Session Close: Fri May 16 00:00:00 2008

The end :)