/irc-logs / w3c / #css / 2011-10-30 / end

Options:

  1. # Session Start: Sun Oct 30 00:00:00 2011
  2. # Session Ident: #css
  3. # [01:00] <dbaron> hmmm, so there aren't any arrival times on the wiki, so I have no idea who might be around for dinner
  4. # [01:04] * Joins: huddler (5e080aef@78.129.202.38)
  5. # [01:06] * Parts: huddler (5e080aef@78.129.202.38)
  6. # [01:22] * Joins: arno (arno@208.87.61.130)
  7. # [01:26] * Quits: arno (arno@208.87.61.130) (Quit: Leaving.)
  8. # [01:26] * Joins: cornelius (616816ae@109.169.29.95)
  9. # [01:27] * Quits: cornelius (616816ae@109.169.29.95) (Quit: http://www.mibbit.com ajax IRC Client)
  10. # [01:29] * Joins: bletch (616816ae@64.62.228.82)
  11. # [01:29] * Joins: mr_sticky (616816ae@109.169.29.95)
  12. # [01:32] * Joins: likinit (616816ae@109.169.29.95)
  13. # [01:39] <likinit> ?
  14. # [01:44] * Quits: likinit (616816ae@109.169.29.95) (Quit: http://www.mibbit.com ajax IRC Client)
  15. # [01:47] * Quits: bletch (616816ae@64.62.228.82) (Quit: http://www.mibbit.com ajax IRC Client)
  16. # [01:47] * Quits: mr_sticky (616816ae@109.169.29.95) (Quit: http://www.mibbit.com ajax IRC Client)
  17. # [02:02] * fantasai is around
  18. # [02:25] * Joins: arronei (arronei@131.107.0.110)
  19. # [02:25] * Quits: arronei_ (arronei@131.107.0.85) (Ping timeout)
  20. # [02:29] <dbaron> fantasai, anyway, I think I'm just going to eat here rather than try to chase people down
  21. # [02:29] <fantasai> ok
  22. # [02:30] <fantasai> if you like I can go try to chase people down for you at the Mariott :)
  23. # [02:30] <fantasai> They're probably all there.
  24. # [02:30] * fantasai is getting grumpy and probably should eat something too
  25. # [02:33] <dbaron> fantasai, anyway, I think I should just stay here and get some work done
  26. # [02:33] <dbaron> dinner first, though
  27. # [02:33] * Quits: dbaron (dbaron@173.228.28.129) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  28. # [02:42] * fantasai found ppl randomly having foos at the bar, not really an organized dinner
  29. # [04:19] * Joins: dbaron (dbaron@173.228.28.129)
  30. # [05:40] * Joins: plinss (plinss@63.145.238.4)
  31. # [05:47] * Quits: dbaron (dbaron@173.228.28.129) (Ping timeout)
  32. # [05:56] * Joins: arno (arno@208.87.61.130)
  33. # [06:10] * Joins: arronei_ (arronei@63.145.238.4)
  34. # [06:11] * Quits: arronei_ (arronei@63.145.238.4) (Quit: arronei_)
  35. # [06:11] * Joins: arronei_ (arronei@63.145.238.4)
  36. # [06:12] * Joins: dbaron (dbaron@173.228.28.129)
  37. # [06:12] * Quits: dbaron (dbaron@173.228.28.129) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  38. # [06:14] * Quits: arronei_ (arronei@63.145.238.4) (Ping timeout)
  39. # [06:28] * Quits: arno (arno@208.87.61.130) (Quit: Leaving.)
  40. # [06:47] <fantasai> hm, clearly typing on the phone sucks
  41. # [06:47] <fantasai> s/foos/food/
  42. # [07:06] * Joins: dodo (5646d95c@207.192.75.252)
  43. # [07:07] * Quits: dodo (5646d95c@207.192.75.252) (Quit: http://www.mibbit.com ajax IRC Client)
  44. # [07:10] * Quits: stearns (anonymous@209.119.68.98) (Quit: stearns)
  45. # [07:50] * Quits: anne (annevk@83.85.115.123) (Client exited)
  46. # [07:58] * Joins: anne (annevk@83.85.115.123)
  47. # [08:00] * Quits: anne (annevk@83.85.115.123) (Quit: anne)
  48. # [08:24] * Joins: Ms2ger (Ms2ger@91.181.84.233)
  49. # [09:21] * Quits: plinss (plinss@63.145.238.4) (Quit: plinss)
  50. # [12:12] * Quits: jdaggett (jdaggett@180.235.5.178) (Ping timeout)
  51. # [12:20] * Joins: jdaggett (jdaggett@180.235.9.33)
  52. # [14:17] * Joins: casper (579819b2@207.192.75.252)
  53. # [14:18] * Parts: casper (579819b2@207.192.75.252)
  54. # [16:03] * Joins: arronei_ (arronei@63.145.238.4)
  55. # [16:39] * Quits: arronei_ (arronei@63.145.238.4) (Ping timeout)
  56. # [16:54] * Joins: TabAtkins_ (tabatkins@208.54.5.223)
  57. # [16:56] * Joins: arno (arno@192.150.10.200)
  58. # [17:13] * Joins: plinss (plinss@64.129.229.106)
  59. # [17:13] * Joins: dbaron (dbaron@64.129.229.106)
  60. # [17:15] <arno> ping
  61. # [17:15] <Ms2ger> Pong?
  62. # [17:15] <arno> Whoo-hoo
  63. # [17:15] * Joins: sylvaing (sylvaing@64.129.229.106)
  64. # [17:16] * Joins: JohnJansen (qw3birc@128.30.52.28)
  65. # [17:16] <arno> ScribeNick arno
  66. # [17:16] * Joins: stearns (anonymous@192.150.10.200)
  67. # [17:16] * Joins: RRSAgent (rrs-loggee@128.30.52.169)
  68. # [17:16] <RRSAgent> logging to http://www.w3.org/2011/10/30-css-irc
  69. # [17:16] * Joins: szilles (chatzilla@192.150.10.201)
  70. # [17:16] * Joins: Zakim (rrs-bridgg@128.30.52.169)
  71. # [17:16] <Ms2ger> ScribeNick arno
  72. # [17:16] * Quits: TabAtkins_ (tabatkins@208.54.5.223) (Quit: leaving)
  73. # [17:17] * Joins: TabAtkins_ (tabatkins@208.54.5.223)
  74. # [17:17] * Joins: glazou (glazou@64.129.229.106)
  75. # [17:17] <Ms2ger> RRSAgent, make logs public
  76. # [17:17] <RRSAgent> I have made the request, Ms2ger
  77. # [17:18] <arno> vincent: 3d interest group requested to meet w/ us
  78. # [17:18] <arno> not on the agenda?
  79. # [17:18] <Bert> The snow in the NE has made one victim: Florian not sure he can make today (see e-mail I just forwarded)
  80. # [17:18] <arno> :(
  81. # [17:18] * Joins: mollydotcom (mollyh@64.129.229.106)
  82. # [17:18] <arno> Daniel: will add to agenda for Tuesday morning
  83. # [17:19] * Joins: vhardy (vhardy@192.150.10.201)
  84. # [17:19] <arno> Tab: variables and hierarchy
  85. # [17:19] <arno> (nesting selectors)
  86. # [17:19] * Joins: arronei_ (arronei@64.129.229.106)
  87. # [17:19] <arno> Tab: I have a proposed spec and would like sign off on "yes, we're going to do these"
  88. # [17:20] <arno> Tab: asking on behalf of shane and luke.
  89. # [17:20] <arno> Daniel: adding to agenda, but gut feeling: "you are going too fast"
  90. # [17:20] * Joins: shepazu (shepazu@128.30.52.169)
  91. # [17:20] * Joins: kojiishi (kojiishi@64.129.229.106)
  92. # [17:20] * Joins: jarek (jarek@83.27.246.228)
  93. # [17:21] <arno> Peter: I have a joint meeting w/ web apps at 11am
  94. # [17:22] <arno> ??: discussion on CSS OM on tuesday morning would require david and tab, will they be there?
  95. # [17:22] <arno> tab: yes, there's a conflict w/ a fx meeting
  96. # [17:22] <arno> peter: no, fx meeting is on thursday
  97. # [17:22] <arno> daniel: please update wiki accordingly
  98. # [17:23] <arno> daniel: I did the schedule based on interest and joint meetings, it wasn't an easy task.
  99. # [17:23] <arno> daniel: any other extra items?
  100. # [17:23] <arno> everyone: no.
  101. # [17:23] * Joins: jdaggett_ (jdaggett@64.129.229.106)
  102. # [17:23] <dbaron> Should we do a brief round of introductions?
  103. # [17:23] <arno> daniel: first, a request from sylvain: "how should wg handle issues?"
  104. # [17:24] * Joins: Rossen (Rossen@64.129.229.106)
  105. # [17:24] <arno> daniel: yes, let's start with intros
  106. # [17:25] <dbaron> Luke McPherson (Google), Shane Stevens (Google), Steve Zilles (Adobe), Molly Holzschlag (Invited Expert), Mark Silverman (Adobe), Deepa Subramanian (Adobe), Bert Bos (W3C), Alan Stearns (Adobe), Arno Gourdol (Adobe), Brad Kemper (Invited Expert), Tab Atkins (Google), Elika Etemad (Mozilla), Daniel Glazman (Disruptive Innovations), Koji Ishii (Invited Expert), John Daggett (Mozilla)
  107. # [17:27] <dbaron> David Baron (Mozilla), Arron Eicholz (Microsoft), Sylvain Galineau (Microsoft), John Jansen (Microsoft), Håkon Lie (Opera), Peter Linss (HP), Chris Lilley (W3C), Vincent Hardy (Adobe), Rossen Atanassov (Microsoft)
  108. # [17:27] <dbaron> (hopefully I kept to under 10 spelling mistakes)
  109. # [17:27] <arno> daniel: back to first issue
  110. # [17:27] * Joins: ChrisL (ChrisL@128.30.52.169)
  111. # [17:27] <arno> sylvain: we implement a spectrum of specs at different levels
  112. # [17:27] * Joins: shans (qw3birc@128.30.52.28)
  113. # [17:27] <arno> sylvain: when something is not Last Call, questions get asked
  114. # [17:27] <sylvaing> http://lists.w3.org/Archives/Public/www-style/2011Apr/0359.html
  115. # [17:28] <arno> the question above was asked, but not answered
  116. # [17:28] <arno> "how much normative info is laying around in the mailing list that's not incorporated"
  117. # [17:28] <sylvaing> https://docs.google.com/spreadsheet/ccc?key=0Akz3Ts2PEQF2dEdQMEtSMXFFMWJyYkVpdUtrWDB4Z3c&hl=en_US#gid=1
  118. # [17:28] <arno> sylvain: I replied "I don't know" and people freaked out.. :)
  119. # [17:29] <arno> sylvain: did an analysis of discussion threads, and it turns out that many did not got concluded and getting it back into the spec
  120. # [17:29] <arno> sylvain: we did that with css 2.1 where fantasai went through 10 years of archives to make sure that everything was taken into account
  121. # [17:30] <arno> sylvain: we shouldn't have to do this. we should have a better organized way of tracking issues.
  122. # [17:30] <arno> dagett: we already have a tracker, no?
  123. # [17:30] * Quits: TabAtkins_ (tabatkins@208.54.5.223) (Ping timeout)
  124. # [17:30] <arno> fantasai: but the editor does not keep up with the feedback
  125. # [17:30] * Joins: TabAtkins_ (tabatkins@216.239.45.130)
  126. # [17:31] <arno> sylvain: difficult to resolve differences between implementations...
  127. # [17:31] * ChrisL saw dino yesterday, wonders whether he will be here later
  128. # [17:31] <arno> sylvain: when we get to module, we should have a link of issues
  129. # [17:31] <fantasai> dbaron: Of all the specs I've implemented, CSS Animations has been in the worst state
  130. # [17:31] <arno> vincent: would be nice to have one common way. i liked the suggestion to have an annotation in the spec that incorporates a link to the wiki
  131. # [17:32] <arno> vincent: not a big fan of the wiki because it's a bit too fragile, would like better method
  132. # [17:32] <arno> daniel: it's a human process, the editor still has to do the right thing
  133. # [17:32] <arno> fantasai: we have multiple ways
  134. # [17:32] <dbaron> (I think there are also a bunch of animations issue that I didn't even bother to bring up on the mailing list.)
  135. # [17:33] * Joins: bradk (bradk@64.129.229.106)
  136. # [17:33] <arno> fantasai: different editors like different systems
  137. # [17:33] <arno> fantasai: i use to track issues in a plain text file, and that worked great for me
  138. # [17:33] <arno> vincent: i like steve's suggestion to incorporate it in the spec, because as you read the spec you can see where there are issues
  139. # [17:34] <arno> howcome: i think email works pretty well
  140. # [17:34] <fantasai> fantasai: The problem is that if the editor is not tracking issues, the issues aren't being tracked. Period.
  141. # [17:34] <arno> sylvain: when it come to disposition of comments, you shouldn't have to go through email archives
  142. # [17:34] * Quits: szilles (chatzilla@192.150.10.201) (Ping timeout)
  143. # [17:35] <arno> howcome: it's not a lack of mechanical solution, the problem is the editor needs to do the tracking
  144. # [17:35] <arno> dbaron: i like the idea of having it in the spec
  145. # [17:35] <fantasai> dbaron: Not nessarily as the only place to track it but as a place to track it
  146. # [17:35] <arno> dbaron: but that doesn't mean there shouldn't be some other way of tracking it
  147. # [17:36] <arno> steve: we may need a mechanism to collect in a list all the issues and what their status is, and we need a way to track what the issue actually is (email, etc.. anything with a URL)
  148. # [17:36] <fantasai> Steve: First issue I see is showing in the spec, at that place, that there is an issue there. Second we need some place that collects all the issues and tells you the status of the issues. Third is we need a way to document what the issue actually is
  149. # [17:37] <arno> steve: putting open issues in the document is pretty important, as it allows people to do something about it. but we probably to have somewhere else also to keep track of all issues
  150. # [17:38] <arno> chris: it's useful to be able to track issues over a long period of time, with a tracker or something else
  151. # [17:38] <arno> jdaggett: we don't need to track all issues, especially at the very beginning of a spec, but bug tracking does make sense when you get to the end
  152. # [17:38] <fantasai> jdaggett++
  153. # [17:38] <arno> fantasai: i agree with this, that's what i've done
  154. # [17:39] <arno> fantasai: but the editor still needs to response to feedback. if it doesn't happen, it doesn't matter what tracking system we have
  155. # [17:40] <arno> fantasai: specs currently don't link to issues
  156. # [17:40] <arno> (in general, a few do)
  157. # [17:41] <arno> fantasai: it's unfair to expect that others will do the work of identifying issues that need to be tracked
  158. # [17:41] * Quits: jarek (jarek@83.27.246.228) (Quit: jarek)
  159. # [17:41] <JohnJansen> note: this is not just a problem with one spec, but is a more general issue
  160. # [17:41] <arno> daggett: how to we deal w/ feature request which the editor think should be dealt with later?
  161. # [17:41] <arno> fantasai: i dump it into tracker
  162. # [17:41] <arno> alan: there's also some wiki pages that include level 4 ideas
  163. # [17:42] <arno> tantek: i like wiki pages better, because it's easier to aggregate requests together, "since the future is fuzzier, a fuzzier mechanism helps"
  164. # [17:42] * Joins: tantek (tantek@64.129.229.106)
  165. # [17:42] <arno> daniel: any concrete proposal?
  166. # [17:42] <tantek> is this on? 1 10 11 check
  167. # [17:43] <arno> sylvain: when dino is around we should discuss w/ him
  168. # [17:43] <Ms2ger> tantek, it is :)
  169. # [17:43] <arno> tab: should we introduce an issue tracker so that if you file an issue via email you also have to file it into the tracker?
  170. # [17:44] <arno> tantek: it depends on where you constraint is. If it's editor's time, that's going to be the bottleneck
  171. # [17:44] <Ms2ger> Might as well go to filing directly in bugzilla, then
  172. # [17:44] <arno> dbaron: if there are multiple requirements to track issues (tracker, email, bugzilla, etc…) some people might use the wrong mechanism and issues may end up dropped on the floor
  173. # [17:45] <arno> tantek: it's already in the spec: send a message to wwwstyle
  174. # [17:45] <JohnJansen> ms2ger, the argument against that is that when a spec is young, bugzilla is too much overhead
  175. # [17:45] <arno> tantek: i think it's up to the editor to track the messages to wwwstyle and track it
  176. # [17:46] * Ms2ger doesn't care much about young specs
  177. # [17:46] <arno> tantek: however the editor track the issue, it should be public and others should be able to add issues
  178. # [17:46] <arno> moly: what about using some tools like stackoverflow, etc… to track?
  179. # [17:47] <arno> tantek: there's only a handful of mechanism other than bugzilla, tracker, wiki
  180. # [17:47] <arno> fantasai: i've used CVS/plaintext
  181. # [17:47] <arno> tantek: someone could add to it?
  182. # [17:47] <arno> fantasai: yes, a bit more cumbersome, though
  183. # [17:47] <arno> chris: as long as it's publicly available
  184. # [17:48] <arno> fantasai: yes, a local text file, spreadsheet, etc… would not work
  185. # [17:48] <glazou> s/moly/molly
  186. # [17:48] <arno> molly: each editor has process, but we need to communicate where the info is. the disparate methodology is creating a disparate problem in which we're not able to have this coalesced
  187. # [17:49] <tantek> molly is talking about a discovery problem ("where are the issues?") rather than a diversity of mechanisms problem.
  188. # [17:49] <tantek> what Steve Zilles said
  189. # [17:49] <arno> steve: as part of the status section of a spec, we should include where the issues are being tracked, so that you can know where the editor tracks issues
  190. # [17:49] <tantek> one single place to track where the issues are, not one single issue tracker
  191. # [17:49] <arno> steve: i.e. that's a per spec issue, not an issue for all specs, right?
  192. # [17:50] <arno> steve: i propose we have, for each spec, a clear indication of where the issues are tracked
  193. # [17:50] <tantek> fantasai - you said there are some specs that have links from their header to their issues?
  194. # [17:50] <tantek> examples?
  195. # [17:50] <Ms2ger> HTML has that
  196. # [17:50] <tantek> i.e.. which spec(s)
  197. # [17:50] <fantasai> tantek, http://www.w3.org/TR/css3-background/
  198. # [17:51] <dbaron> For http://dev.w3.org/csswg/css3-conditional/ I've just been tracking all the issues in <p class=issue>s in the editor's draft.
  199. # [17:51] <arno> steve: if there's a clear list of issues, people could find out what the status is and have the group (or the chair) do the policing if necessary
  200. # [17:51] <tantek> so none of those have links from the header
  201. # [17:52] <tantek> proposal: just as each spec must have a link to the editor's draft, right underneath that, it should link to where it tracks issues
  202. # [17:52] <arno> fantasai: so, each spec must have a clear, publicly accessible way of tracking issues
  203. # [17:52] <arno> fantasai: each module
  204. # [17:52] <Ms2ger> And note that nobody reads the SotD :)
  205. # [17:52] <fantasai> RESOLVED: Each module must have one publicly-accessible, CSSWG-editable way of tracking issues.
  206. # [17:53] <sylvaing> http://dev.w3.org/csswg/css3-positioning/
  207. # [17:53] <arno> tantek: the examples above are burried in the spec
  208. # [17:54] <fantasai> RESOLVED: Add link to issues list from spec header
  209. # [17:54] <arno> daniel: who's in favor of the RESOLVED issue above
  210. # [17:54] <arno> ?
  211. # [17:54] <arno> daniel: (from show of hands): OK, resolved
  212. # [17:55] <arno> daniel: i'm not satisfied with a different system for each spec
  213. # [17:55] <arno> daniel: you have to adapt yourself for each one, and it's difficult when you're tracking 30 specs
  214. # [17:55] <arno> steve: building o the idea that there are 4 systems in use right now, could we restrict the list of acceptable issue tracking system
  215. # [17:55] <arno> daniel: that's a good compromise
  216. # [17:56] <arno> steve: we have 3: wiki, tracker and bugzill
  217. # [17:56] <Ms2ger> And plaintext in CVS
  218. # [17:56] <arno> dbaron: and there's another one: track everything in the draft
  219. # [17:57] <arno> alan/tantek: do you keep a log of the resolved issues
  220. # [17:57] <arno> dbaron: no, the CVS log is the log...
  221. # [17:57] <arno> daniel: <squirms>
  222. # [17:57] <arno> tantek: so you're saying that twitter is the log, then...
  223. # [17:58] <tantek> here's an example of a spec which has links in the header to both editor's draft and issues list: http://dev.w3.org/csswg/css3-ui/
  224. # [17:58] <arno> tab: i use the same system as david, and it works for me
  225. # [17:58] <arno> alexm: with multiple editors it can get complicated
  226. # [17:58] <arno> fantasai: i use different systems, depending on the lifecycle of the spec.
  227. # [17:59] <arno> fantasai: when we need to resolve a bunch of issues as a group, i make a list and use it in tracker for easier resolution
  228. # [17:59] * Quits: plinss (plinss@64.129.229.106) (Client exited)
  229. # [17:59] * Joins: plinss (plinss@68.107.116.103)
  230. # [17:59] <arno> fantasai: at the end, i use a plaintext file
  231. # [17:59] <arno> daniel: let's close on steve's proposal
  232. # [18:00] <tantek> I use the wiki to track issues, and have been putting links from the document like: "Related open issue: 1. " (where "1." is hyperlinked to the issue)
  233. # [18:00] <arno> daniel: when using inline issue tracking, still indicate that in the header
  234. # [18:00] * Joins: plinss__ (plinss@64.129.229.106)
  235. # [18:01] <arno> fantasai: we have the WD and the Editor's draft.
  236. # [18:01] <arno> fantasai: they may have separate issues list
  237. # [18:01] <arno> vincent: the current list of issues is related to the ED, not the WD
  238. # [18:02] <arno> fantasai: it's snapshotted if you track it inline, but otherwise the link to a separate issue tracker may get out of sync
  239. # [18:02] <arno> fantasai: maybe only have the link on the ED
  240. # [18:03] <arno> steve: no, too many people get to the WD than the ED, and then you will end up in the wrong issue list
  241. # [18:03] <arno> molly: agree, we need to coalesce, rather than fragment
  242. # [18:03] * Quits: plinss (plinss@68.107.116.103) (Ping timeout)
  243. # [18:03] * plinss__ is now known as plinss
  244. # [18:03] <arno> vincent: if you do inline issue tracking, that resolves it
  245. # [18:04] <arno> fantasai: could be resolved if the link to issues in the WD point to the ED issues list
  246. # [18:04] * Joins: alexmog (alexmog@64.129.229.106)
  247. # [18:05] <arno> molly: the ED is the up to date version of issues are tracked. so we could just have a link that points to the ED to find out what the current issues are
  248. # [18:06] <arno> tantek: maybe we need a warning in the WD that makes it clear it's out of date...
  249. # [18:06] <arno> chris: when it's published as a TR it should not include the list of issues anymore
  250. # [18:06] <Ms2ger> Why not?
  251. # [18:07] * Parts: alexmog (alexmog@64.129.229.106)
  252. # [18:07] <arno> daniel: a TR has a date, so having issues there would be appropriate to reflect what the issues were for *that* version of the document
  253. # [18:07] <arno> daniel: i don't know how to tweet this
  254. # [18:08] <ChrisL> @ms2ger I was arguing against a static,out of date copy of the state of issues in a /TR published draft, if the editors draft has a more up to date list
  255. # [18:08] <arno> daniel: issue trackers used: bugzilla, wiki, tracker, inline
  256. # [18:09] <arno> RESOLVED: use one of bugzilla, wiki, tracker or inline to track issues.
  257. # [18:09] <arno> fantasai: it was really hard with CSS 2.1
  258. # [18:09] <arno> tantek: let's not have big specs like that anymore
  259. # [18:09] <tantek> :)
  260. # [18:10] * Joins: alexmog- (alexmog@64.129.229.106)
  261. # [18:10] <arno> fantasai: how do we track 300 issues on one wiki page? doesn't seem to scale
  262. # [18:10] <tantek> we can cross that bridge when we reach it
  263. # [18:11] <arno> johnjansen: that's why i like bugzilla better to do the tracking
  264. # [18:11] <arno> vincent: maybe it depends on the lifecycle, later on in the spec's life, using bugzilla may be better
  265. # [18:12] <arno> fantasai: not asking for a WG resolution, but sharing my experience
  266. # [18:13] <arno> steve: we have these discussions where we agree on a particular strategy, recorded in the minute, and then it slowly gets out of memory as time goes on
  267. # [18:13] <arno> steve: could we have this recorded in the wiki or somewhere
  268. # [18:13] <arno> daniel: i agree that best practices are needed
  269. # [18:13] <tantek> here: http://wiki.csswg.org/spec#specification-editing
  270. # [18:13] <arno> daniel: what should happen if an editor doesn't track issues?
  271. # [18:13] <arno> daniel: spanking the editor?
  272. # [18:14] <arno> steve: the chair has multiple paths: talk to the editor, talk to the AC rep, raise it to the group and replace the editor
  273. # [18:14] <arno> tantek: after step 1 (talking to the editor), you could also suggest adding a co-editor
  274. # [18:15] <arno> tantek: or even assign a co-editor
  275. # [18:15] <arno> tantek: that's worked in the past
  276. # [18:15] <arno> daniel: you need to know there's an issue with the issue tracking
  277. # [18:15] <arno> tantek: if the ED gets more than 1 year out of date...
  278. # [18:16] <arno> tantek: there are past signals and procedure that seem to have fixed it
  279. # [18:16] <arno> tab: re: issue tracking and bugzilla, there's only 5 components in it right now. could we add all components?
  280. # [18:16] <arno> johnjansen: yeah, how do we do that
  281. # [18:17] <arno> solution: mail mike smith (or bert) to ask the components to be added in bugzilla
  282. # [18:17] <arno> sylvain: we have 1 hour tomorrow for animation
  283. # [18:18] <arno> sylvain: i have some technical discussion that needs to hapen
  284. # [18:18] <arno> bert: maybe that's a topic for the plenary
  285. # [18:18] <arno> tantek: there are several issue re: specs
  286. # [18:18] <arno> tantek: sounds like you want to lead a discussion
  287. # [18:18] <arno> bert: no, not really...
  288. # [18:19] <arno> daniel: anything else about spec editing/tracking?
  289. # [18:19] <arno> plinns: that makes me want to build a tool. would people use it?
  290. # [18:19] <arno> tantek: might be worth looking at hixie's tool'
  291. # [18:20] <arno> tab: it's easy to deal with
  292. # [18:20] <arno> daniel: yes, select all and resolve as invalid :)
  293. # [18:20] * Bert Tracker itself came out of Dean Jackson feeling like Peter feels now. :-)
  294. # [18:20] <arno> fantasai: you could improve tracker, most of its problems are UI issues
  295. # [18:21] <arno> fantasai: we have so many systems because all of them kinda suck
  296. # [18:21] <arno> tantek: who does the IT for bugzilla/tracker?
  297. # [18:21] <arno> chris: it's the systems team
  298. # [18:21] <tantek> URL?
  299. # [18:22] * tantek wouldn't mind seeing tracker's source/deployment moving to github.
  300. # [18:22] <arno> daniel: let's close this agenda item and move on the next one
  301. # [18:22] <arno> daniel: let's move to css regions
  302. # [18:23] <arno> vincent: <showing slides>
  303. # [18:23] <arno> my.adobe.acrobat.com/silverman
  304. # [18:24] <arno> vincent: css regions (alex and vincent)
  305. # [18:24] <arno> css exlcusions (rossen and vincent)
  306. # [18:24] <arno> css fragmentations (eliak and rossen)
  307. # [18:24] <arno> vincent: ED after the tokyo meeting
  308. # [18:24] * Joins: howcome (howcome@64.129.229.106)
  309. # [18:24] <dbaron> Is positioned floats part of one of those three parts?
  310. # [18:25] <arno> vincent: most issues have been worked out, except the ones to review today
  311. # [18:25] <arno> vincent: 2 implementations in progress (IE and WebKit)
  312. # [18:25] <arno> vincent: would like to resolve some issues today and publish a new WD
  313. # [18:26] <arno> vincent: positioned floats is another module (not the three parts above)
  314. # [18:26] <dbaron> vincent: positioned floats is a 4th part
  315. # [18:26] * Joins: szilles (chatzilla@192.150.10.201)
  316. # [18:26] * sylvaing Skype access to the meeting available at w3c-csswg
  317. # [18:27] <arno> vincent: issue tracked in the spec, and the wiki has a list of resolved issues and no longer in the spec
  318. # [18:27] <vhardy> http://wiki.csswg.org/spec/css3-regions?&#issue-19special-behavior-of-iframe-flow
  319. # [18:28] <dbaron> http://wiki.csswg.org/spec/css3-regions#issue-19special-behavior-of-iframe-flow
  320. # [18:28] <arno> howcome: i have concerns with the current regions approach
  321. # [18:29] <arno> howcome: we need them, but it doesn't discuss two issues that seem important: pagination and auto-generation of boxes
  322. # [18:29] <arno> max: currently done by script, using OM
  323. # [18:29] <arno> alan: to have the entire content displayed, you need a page template mechanism
  324. # [18:30] <arno> howcome: multicol is already doing auto-generation
  325. # [18:30] <arno> alex: we use at multiple use cases, and there are so many cases that you need script anyway
  326. # [18:30] <arno> howcome: i'd love to see the use cases.
  327. # [18:31] <arno> alex: for some use cases you need script, but maybe we can have a subset that does auto-generation
  328. # [18:31] <stearns> you can display the entire content (by having the last region overflow)
  329. # [18:32] <arno> steve: you are correct that some of the problem have do with pages. you can't know ahead of time how many pages you need. rather than picking up on region, it seems like this is something that should be handled by pages instead
  330. # [18:32] <fantasai> didn't Bert have a proposal in css3-template that solved this kind of problem?
  331. # [18:32] <arno> steve: some way of having master pages that can be combined through an auto-generation mechanism to do this
  332. # [18:32] <Bert> q+
  333. # [18:32] * Zakim sees Bert on the speaker queue
  334. # [18:33] <arno> steve: multicol seems too weak to deal with this
  335. # [18:34] <arno> howcome: i'd like to approach this by looking at use cases
  336. # [18:35] <arno> vincent: we looked at what's needed for magazine, but regions are one the building blocks that's needed. pagination is useful as well.
  337. # [18:35] <arno> vincent: there's a lot that can be done with regions, and we'd like to work on pagination as well
  338. # [18:36] <arno> vincent: regions was a common denominator across all the use cases we looked at
  339. # [18:36] <arno> howcome: i think two things regions must address are pagination and auto-generation
  340. # [18:36] <arno> steve: i'm confused: neither of these things have to do with pages, pages is a separate module
  341. # [18:37] <arno> howcome: i think we're using the terms differently
  342. # [18:37] * alexmog- proposes action for Hakon and Alex to propose a mechanizm for autogeneration
  343. # [18:38] <fantasai> howcome: If I take a stylesheet from one document and apply it to another that has more content, I should be able to *see the content*
  344. # [18:38] <arno> howcome: when you apply a style sheet to another document, you should still be able to see the content
  345. # [18:38] <arno> steve: regions doesn't resolve all problems. it's one building block, that can be chained with others.
  346. # [18:39] <arno> steve: the intent was that the auto-generation would be done over a collection of regions, called a page, that would get auto-generated. you're correct this is not correctly specified, but it makes more sense to deal with it in the context of pages, rather than regions
  347. # [18:40] <arno> howcome: i dont think we fundamentally disagree. we both want to do regions. i think it's possible to latch onto the multicol model with does auto-generation and paginations
  348. # [18:41] <arno> howcome: if you can have selectors for each column, and column on each page, maybe layout-wise it's as powerful, it solves the use cases but gives you pagination and auto-generation
  349. # [18:42] <dbaron> ack Bert
  350. # [18:42] * Zakim sees no one on the speaker queue
  351. # [18:42] <arno> bert: I did some work past few days to integrate regions spec in template layout
  352. # [18:42] <arno> bert: for repeating, not completely worked out, but should possible to put a template in a column.
  353. # [18:43] <Bert> -> https://www.w3.org/Style/Group/css3-src/css3-layout/Overview.html#repeating-templates note about combining columns and regions (i.e., templates)
  354. # [18:43] <arno> bert: all w/ same mechanism, you only need a selector to select a column and a column in a page
  355. # [18:44] <arno> howcome: can we see the use cases?
  356. # [18:44] <arno> daniel: have them in the spec
  357. # [18:44] <Bert> action bert: move template layout to dev.w3.org
  358. # [18:44] * trackbot noticed an ACTION. Trying to create it.
  359. # [18:44] * RRSAgent records action 1
  360. # [18:44] <trackbot> Created ACTION-374 - Move template layout to dev.w3.org [on Bert Bos - due 2011-11-06].
  361. # [18:45] <arno> vincent: we don't have use cases in specs in general
  362. # [18:45] <arno> daniel: maybe in an appendix
  363. # [18:45] <fantasai> fantasai: Can we have this draft on dev.w3.org? Bert: It's convenient to have it internal. fantasai: It's more convenient for us to have it public. Bert: I'd rather publish a WD. fantasai: Yes, let's do both. :)
  364. # [18:45] <Ms2ger> fantasai++
  365. # [18:45] <arno> molly: there's a convention in publishing, if it's a screenshot it's not considered proprietary
  366. # [18:46] * Bert thanks fantasai for recording that.
  367. # [18:46] * fantasai welcome
  368. # [18:46] * tantek agrees with daniel
  369. # [18:46] <arno> howcome: we need to see the use cases
  370. # [18:46] <arno> howcome: we need to support auto-generation
  371. # [18:46] <tantek> would be useful to capture/see the use-cases in the spec that drove the design. in an Appendix is fine.
  372. # [18:47] <arno> howcome: we need pagination
  373. # [18:47] <fantasai> hwocome^: Shouldn't have to resort to scripting.
  374. # [18:47] * sylvaing dreams of specs with uses-cases appendices
  375. # [18:47] <arno> vincent: agree with it, but our take was that pagination and auto-generation were not going to be covered in regions spec
  376. # [18:47] <arno> steve: shouldn't it be in the paginated media module?
  377. # [18:48] <arno> howcome: that would be fine, but the specs should evolve at the same time
  378. # [18:49] <arno> alex: i think you're trying to do a simple page flipper, it would be great to support that
  379. # [18:50] <fantasai> howcome: My use case is to have a fancy first page of an article, and then second and subsequent pages flow as multi-col
  380. # [18:50] <arno> vincent: multicol serves multiple purpose, it's both a template and a way to paginate
  381. # [18:50] <fantasai> vincent: That's issue 12, whether to have multicol as regions
  382. # [18:50] <arno> alex: i think we need to talk about it and decide which spec it belongs to
  383. # [18:51] <fantasai> vincent: auto-generation goes much further than just that
  384. # [18:51] <arno> steve: i think we should record the issue that howcome is raising
  385. # [18:52] <arno> alex: i think pagination/fragmentation is a fundamental feature of layout. the region spec is about how to provide this boundary
  386. # [18:52] <arno> howcome: i just want to know how to print documents with regions on them
  387. # [18:52] <arno> daniel: we have 15min remaining. let's move one.
  388. # [18:53] <arno> s/one/on/
  389. # [18:53] <glazou> http://wiki.csswg.org/spec/css3-regions?&#issue-19special-behavior-of-iframe-flow
  390. # [18:53] <arno> vincent: do we want multicol elements to be regions or not
  391. # [18:53] <dbaron> http://wiki.csswg.org/spec/css3-regions#issue-12should-we-allow-multi-column-elements-to-be-regions
  392. # [18:54] <arno> fantasai: i'm in favor
  393. # [18:54] <arno> alex: i like that idea too, add very little complexity to implementation
  394. # [18:55] <arno> alex: if there's a region and you set column = 2, you get a region with two columns
  395. # [18:55] <ChrisL> rrsagent, here
  396. # [18:55] <RRSAgent> See http://www.w3.org/2011/10/30-css-irc#T17-50-04
  397. # [18:56] <tantek> <aside> just stubbed http://wiki.csswg.org/spec/issue-tracking - please review and feel free to improve </aside>
  398. # [18:56] <arno> rossen: overflow would be interesting in that case
  399. # [18:56] <arno> rossen: this would lead to introducing fragmentation
  400. # [18:56] <arno> steve: seems like the AI is "how should it be done or why it shouldn't be done"
  401. # [18:57] * Quits: szilles (chatzilla@192.150.10.201) (Ping timeout)
  402. # [18:58] <arno> jdaggett: is the question something with both multi-column and region, what happens?
  403. # [18:58] <arno> jdaggett: where does the spec forbid it?
  404. # [18:58] <arno> section 4.2
  405. # [18:58] <tantek> <aside> also lurking in #tpac as a general back-channel for this week </aside.
  406. # [18:58] <vhardy> http://dev.w3.org/csswg/css3-regions/#the-flow-from-property
  407. # [18:59] <arno> howcome: multicol only changes how things are laid out inside the element
  408. # [18:59] <arno> howcome: i don't understand how multicol would be any harder...
  409. # [19:00] <arno> alex: some work needs to happen, because overflow behavior is different
  410. # [19:00] <arno> howcome: i don't understand why we need a proposal
  411. # [19:01] <arno> daniel: we need a proposal, alex/vincent come back to the group when you have one
  412. # [19:01] <arno> action vincent: bring a proposal for interaction between multicol and region
  413. # [19:01] * trackbot noticed an ACTION. Trying to create it.
  414. # [19:01] * RRSAgent records action 2
  415. # [19:01] <trackbot> Created ACTION-375 - Bring a proposal for interaction between multicol and region [on Vincent Hardy - due 2011-11-06].
  416. # [19:01] <dbaron> http://wiki.csswg.org/spec/css3-regions#issue-19special-behavior-of-iframe-flow
  417. # [19:01] <arno> alex: issue 19: special behavior of iframe.
  418. # [19:02] <arno> alex: two implementations (IE and webkit) have different behavior. need to reconcile.
  419. # [19:02] * Quits: shepazu (shepazu@128.30.52.169) (Quit: shepazu)
  420. # [19:02] <arno> alex: need some sort of indirection mechanism
  421. # [19:02] <arno> fantasai: how does it related to the seamless attributes in HTML5
  422. # [19:03] <arno> ??: seems like allowing flowing of content is not specific to regions
  423. # [19:03] <fantasai> s/??/hober/
  424. # [19:03] <fantasai> alex: seamless also allows transparency wrt scripting and style rules
  425. # [19:03] <arno> alex: once the flow is picked up from iframe, not relevant to iframe either. maybe have a link element referring to a url with the external flow
  426. # [19:04] <arno> alex: i would like advice
  427. # [19:04] <arno> tab: i am scared of this, esp. re: security
  428. # [19:04] <arno> tab: this would allow arbitrary interaction with layout
  429. # [19:04] <arno> alex: currently restricted to same origin
  430. # [19:04] <arno> fantasai: seems like the switch should be at the HTML level
  431. # [19:05] <dbaron> hober: certainly not at the regions level
  432. # [19:05] <arno> tab: i don't think we should tie a "transclusion" property with regions
  433. # [19:05] <arno> molly: i think it should be in html5
  434. # [19:05] <dbaron> http://dev.w3.org/html5/spec/the-iframe-element.html#attr-iframe-seamless
  435. # [19:06] <Bert> (Sounds like this already exists: XInclude)
  436. # [19:06] <arno> tab: we should make a separate spec for it
  437. # [19:06] <fantasai> s/it/transclusions/
  438. # [19:07] <arno> steve: you can put the iframe in the flow, but not the content of the iframe
  439. # [19:07] <arno> tab: the content of iframes are a black box to css
  440. # [19:07] <arno> johnjansen: you get the security protection by using iframe
  441. # [19:07] <fantasai> tab: the security concern is in the other direction
  442. # [19:08] <arno> rossen: the core of the problem is do we allow external content to flow through regions? if we do, we need a way
  443. # [19:08] <arno> daniel: what's the use case
  444. # [19:08] <arno> rossen: digital publishing that pick up articles from various sources, and aggregates them
  445. # [19:08] <arno> daniel: seems like it could be a feature we add later
  446. # [19:09] <arno> dbarron: doesn't seem specific to Regions
  447. # [19:09] <fantasai> s/dbarron/dbaron/
  448. # [19:09] <arno> molly: or CSS at all. seems like HTML
  449. # [19:09] <arno> alex: looks like we don't have a proposal, and that's what IE is going to ship
  450. # [19:09] <arno> hober: it could be anywhere it's appropriate
  451. # [19:10] <Bert> (B.t.w., https://www.w3.org/Style/Group/css3-src/css3-box/Overview.html#the-width-and-height-properties defines 'height: complex' to deal with SEAMLESS (although it predates the invention of that attribute.)
  452. # [19:11] <arno> daniel: it reminds of the time when features where implemented before discussions
  453. # [19:11] <arno> daniel: and it gives me a bad feeling
  454. # [19:11] <arno> daniel: i have the gut feeling you're going too fast. there's no agreement between parties it should be the spec and you say: "it's in IE"
  455. # [19:12] <arno> alex: i disagree w/ the statement that we don't care about it
  456. # [19:12] * tantek agrees with daniel. this feels like we (the working group) are racing towards shipping incompatibility and legacy compat issues.
  457. # [19:12] <fantasai> +!
  458. # [19:12] * Zakim wonders where ! is
  459. # [19:12] <fantasai> +1
  460. # [19:13] <arno> action alex: remove text about special iframe behavior and alex to write proposal about the behavior of iframe
  461. # [19:13] * trackbot noticed an ACTION. Trying to create it.
  462. # [19:13] * RRSAgent records action 3
  463. # [19:13] <trackbot> Created ACTION-376 - Remove text about special iframe behavior and alex to write proposal about the behavior of iframe [on Alex Mogilevsky - due 2011-11-06].
  464. # [19:17] * Quits: tantek (tantek@64.129.229.106) (Quit: tantek)
  465. # [19:17] * Quits: TabAtkins_ (tabatkins@216.239.45.130) (Ping timeout)
  466. # [19:18] * Quits: plinss (plinss@64.129.229.106) (Quit: plinss)
  467. # [19:30] * Joins: tantek (tantek@64.129.229.106)
  468. # [19:31] <vhardy> http://wiki.csswg.org/spec/css3-regions?&#issue-10should-the-regionlayoutupdate-event-by-sync-or-async
  469. # [19:31] <dbaron> http://wiki.csswg.org/spec/css3-regions#issue-10should-the-regionlayoutupdate-event-by-sync-or-async
  470. # [19:31] <fantasai> ScribeNick: fantasai
  471. # [19:31] <fantasai> vhardy: Should this event be synchronous or asynchronous
  472. # [19:32] <fantasai> vhardy: IE implemented as async, seemed to work with demos they built
  473. # [19:32] <fantasai> alex: Not sure how to make it synchronous
  474. # [19:32] * Bert to Daniel: can we find 2 minutes somewhere on the agenda to decide to publish a new Template Layout WD (probably conditionally, with a week's delay, so people can raise objections if needed)?
  475. # [19:32] <fantasai> vhardy: If no convincing argument for sync, then making it async
  476. # [19:32] <fantasai> dbaron: Are you defining exactly how it's async?
  477. # [19:32] * glazou Bert yes, right after lunch?
  478. # [19:32] <fantasai> alex: Sync would be defining exactly in what order it happens
  479. # [19:33] * Bert OK
  480. # [19:33] <fantasai> alex: async means that some layout process has happened in this region, and you're notified of that
  481. # [19:33] * Joins: plinss (plinss@64.129.229.106)
  482. # [19:33] <fantasai> dbaron: i agree with making it async. Might need more detail at some point
  483. # [19:33] <fantasai> RESOLVED: regionLayoutUpdate is an asynchronous event
  484. # [19:33] <vhardy> http://wiki.csswg.org/spec/css3-regions?&#issue-18interplay-of-flow-from-and-content
  485. # [19:33] <fantasai> vhardy: interplay of flow-from and content
  486. # [19:34] <fantasai> vhardy: which one has precedence?
  487. # [19:34] <fantasai> vhardy: We had resolved to say that flow from property gets used in place of ocntent for associating an element with a flow
  488. # [19:34] <fantasai> vhardy: We moved from using 'content' to 'flow-from', there was issue raised during meeting that not sure this was quite the right decision
  489. # [19:34] <fantasai> vhardy: My request is to close the issue unless we have a problem to discuss?
  490. # [19:35] <fantasai> vhardy: I'd rather close it, and reopen if you have a specific objection
  491. # [19:35] <fantasai> fantasai: I'm ok with that.
  492. # [19:35] <fantasai> Bert: flow-from is on regions, content is on elements. So they don't interact.
  493. # [19:36] <fantasai> vhardy: flow-from makes something a region
  494. # [19:36] <fantasai> Bert: There are various ways to make regions, but content is on an element.
  495. # [19:37] <fantasai> vhardy: Right now if you wnat to flow content into an area, then you'll pick a flow and then put it in an element, which makes it into a region
  496. # [19:37] <fantasai> howcome: Bert's point is that you're using an element to create a region. You could create a region without an element
  497. # [19:38] <fantasai> RESOLVED: close issue 18, reopen if needed later
  498. # [19:38] <dbaron> http://wiki.csswg.org/spec/css3-regions#issue-23should-regions-be-non-breakable
  499. # [19:38] <dbaron> http://wiki.csswg.org/spec/css3-regions#issue-22content-vs-flow-from-precedence
  500. # [19:38] <fantasai> vhardy: content vs. flow-from precedence
  501. # [19:38] <fantasai> vhardy: On mailing list there was overwhelming preference for 'content' to take precedence
  502. # [19:40] <fantasai> fantasai: The 'normal' value of 'content' would compute to using flow-from when available
  503. # [19:40] <fantasai> discussion of using 'content' to override content
  504. # [19:41] <fantasai> alex: flow-from blows away whatever content is there. Why shouldn't it be more important than 'content'.
  505. # [19:42] * Joins: TabAtkins_ (tabatkins@208.54.5.223)
  506. # [19:42] <fantasai> vhardy: So we have a proposal from several to have 'content' != 'normal' override, and other is to have 'flow-from' always override.
  507. # [19:43] <fantasai> alex: If we had display-inside: region, then 'content' would be irrelevant
  508. # [19:43] <fantasai> alex: flow-from is two properties in one
  509. # [19:44] <fantasai> fantasai: 'content' property is supposed to be the master switch for what the contents of this element ar.
  510. # [19:44] * Joins: tcelik (tantek_@64.129.229.106)
  511. # [19:45] * Joins: szilles (chatzilla@192.150.10.201)
  512. # [19:46] <dbaron> fantasai: I don't like having properties that unilaterally override other properties.
  513. # [19:46] <dbaron> fantasai: That always leads to problems.
  514. # [19:47] <fantasai> fantasai: we have this problem with 'border-image', where if someone sets 'border-image' further up in the cascade, my 'border-style: dashed' inexplicably has no effect
  515. # [19:48] <fantasai> Bert: A different solution, apart from needing two properties, the model doesn't have to be one overriding the other.
  516. # [19:48] <fantasai> Bert: In Template module, if two pieces of content go into the same slot, they add up
  517. # [19:48] <fantasai> alex: So if there's content in the region, then it's appended to the flow?
  518. # [19:48] <fantasai> vincent: You would include the element's content, and the append the flow
  519. # [19:49] * Quits: szilles (chatzilla@192.150.10.201) (Ping timeout)
  520. # [19:49] <fantasai> molly: from a developer perspective, 'content' should be about the content.
  521. # [19:50] <fantasai> discussion of applying 'content' to an image
  522. # [19:50] <fantasai> fantasai: if you write img { content: "foo" } the <img> element will cease to be a replaced element and will become an inline element containing the string "foo"
  523. # [19:52] <fantasai> RESOLVED: If 'content' computes to 'normal', then the element takes the flow
  524. # [19:54] * Quits: TabAtkins_ (tabatkins@208.54.5.223) (Quit: leaving)
  525. # [19:54] * Joins: szilles (chatzilla@192.150.10.201)
  526. # [19:54] * Joins: TabAtkins_ (tabatkins@208.54.5.223)
  527. # [19:55] <fantasai> fantasai explains the 'content' property and its various values and effects on elements, pseudo-elements, replaced elements, etc.
  528. # [19:56] <vhardy> http://wiki.csswg.org/spec/css3-regions?&#issue-20list-of-region-style-properties
  529. # [19:56] <vhardy> http://dev.w3.org/csswg/css3-regions/#the-at-region-style-rule
  530. # [19:56] <fantasai> vhardy: The @region doesn't have the pseudo-selector ppl didn't like
  531. # [19:56] <fantasai> vhardy: The number of properties that apply listed in that link, font proeprties, background properties, simple rendering properties
  532. # [19:56] <fantasai> vhardy: Also includs borders/marginsp/adding,
  533. # [19:57] <fantasai> vhardy: We explain why some things that apply to layout might make sense here
  534. # [19:58] <fantasai> vhardy: there's a simplified list of properties that can apply to regions, but it's now more than ::first-line
  535. # [19:58] <fantasai> vhardy: In our impl experience, this has been ok
  536. # [19:58] <fantasai> alex: multi-col properties?
  537. # [19:58] <fantasai> vhardy: The multi-col isn't on the flow content, it's on the region itself
  538. # [19:58] <fantasai> alex: We should have an element there, say <article> as 3 columns... flows into a 1 column region
  539. # [19:59] <fantasai> alex: Could choose to have 1 col in one region and 3 col in another region
  540. # [19:59] * fantasai doesn't understand this issue at all and need to read the spec before making any comment
  541. # [19:59] <fantasai> vhardy: You can't change the layout nature, e.g. display/position
  542. # [19:59] <fantasai> vhardy: multicol... I guess it's halfway
  543. # [19:59] <fantasai> vhardy: I guess we could add it
  544. # [20:00] <fantasai> dbaron: Does this specify somewhere how the cascading and inheritance works?
  545. # [20:00] <fantasai> vhardy: yes, somewhere there
  546. # [20:00] <fantasai> dbaron: .... specificity isn't the issue
  547. # [20:00] <fantasai> howcome: It's multiple inheritance, isn't it.
  548. # [20:01] <fantasai> Bert: It's the ::first-line problem.
  549. # [20:01] <fantasai> fantasai: Can we put ::first-line into the regions spec so you can solve all the problems at the same time? :)
  550. # [20:01] <fantasai> vhardy: If there's an issue with cascading/inheritance then I'm happy to take that as a separate issue. This one is about the list of properties.
  551. # [20:02] <fantasai> ...
  552. # [20:02] <fantasai> howcome: if you set 1.2em on something inside a region, what does it refer to?
  553. # [20:02] <fantasai> vhardy: If you set the font size on the region itself, it has no effect on the content just on the layout of the region
  554. # [20:02] <fantasai> howcome: I have a region, and I set font-size on that. And it's applied
  555. # [20:03] <fantasai> howcome: And I have a span inside it that sets 1.2em. What is it relative to?
  556. # [20:03] <fantasai> vhardy: If you set it on the region then it doesn't inherit
  557. # [20:03] <fantasai> Steve: You can't have it both ways.
  558. # [20:04] <fantasai> Steve: If you set it on the region and it affects the text, it inherits into that element
  559. # [20:04] <fantasai> howcome: What if you set 'inhert'?
  560. # [20:04] <fantasai> Steve: I wouldn't answer that question hastily...
  561. # [20:04] <fantasai> Steve: ::first-line has the same problem
  562. # [20:04] <fantasai> dbaron: This is very different from ::first-line actualy
  563. # [20:05] <fantasai> dbaron: I'd like the example in the spec to not use pseudo-syntax, use real syntax
  564. # [20:05] <fantasai> jdaggett agrees
  565. # [20:05] <fantasai> jdaggett: I'd like the examples to show what an author might use, not just region1 region2
  566. # [20:05] <fantasai> Steve: dbaron, I thought you said ::first-line effectively introduced an element around that thing, so inheritance would go to the first line
  567. # [20:06] <fantasai> dbaron: ::first-line introduces an additional pseudo-element around it, and I forget the wording around inheritnace 'cuz we changed it so many times
  568. # [20:06] <fantasai> dbaron: But this also has selectors inside the region rules, so you can have an element that picks up different selectors based on where it breaks.
  569. # [20:06] * glazou we're breaking for lunch in 10mins from now
  570. # [20:06] <fantasai> howcome: It says font size in percentages refers to inherited font-size
  571. # [20:07] <fantasai> dbaron: I think the model here is actually relatively simple. I think it's simpler than ::first-letter. However it doesn't agree at all with the spec's existing terminology. So it's sort of hard to write about.
  572. # [20:07] <fantasai> dbaron: This model gives elements multiple styles essentially.
  573. # [20:07] * tcelik is a bit confused about the distinction between the "current" font-size and the "inherited" font-size.
  574. # [20:07] <fantasai> dbaron: And 2.1 is writen assuming that an element has *a* computed value for a property
  575. # [20:07] <fantasai> Tab: All the specs are written with that assumption
  576. # [20:07] <fantasai> dbaron: This is more box tree stuff
  577. # [20:08] <fantasai> fantasai: We're introducing the term "fragment" to talk about pieces of the box in the box tree when it's broken
  578. # [20:09] <fantasai> fantasai: might help with discussing this
  579. # [20:09] <fantasai> Bert: I also have 'vertical-align', works like in table cells
  580. # [20:09] <fantasai> Bert: I also have 'overflow': if contents put in the region are too wide for the region, where does it go? Is it visible at all?
  581. # [20:10] <fantasai> (talking about properties that are set on the region)
  582. # [20:10] <fantasai> Rossen: This is about the properties that are propagated to the contents of the region
  583. # [20:10] <fantasai> Rossen: Back to howcome's example, when you compute fonts you always have a resolved font-size no matter where you are in the tree
  584. # [20:10] <fantasai> Rossen: If we allow regions to specify font-size, this would be equivalent to changing initial font size on the fly
  585. # [20:10] * Joins: umbridge (ae64bcb7@78.129.202.38)
  586. # [20:11] <fantasai> Rossen: Once you're inside, you start again from the root
  587. # [20:11] <fantasai> Rossen: Like howcome pointed out, this is multiple inheritance, no kidding
  588. # [20:11] <fantasai> Rossen: you won't know your font size until you lay out the part of the element that you're computing
  589. # [20:11] <fantasai> Rossen: Simplest example is body with 100em width
  590. # [20:12] <fantasai> Rossen: It appears in 2 regions, one with 10px font size and one with 100px fontsize
  591. # [20:12] <fantasai> Rossen: In this model you will have to recompute the body size
  592. # [20:12] * Parts: umbridge (ae64bcb7@78.129.202.38)
  593. # [20:12] <fantasai> vhardy: No, right now all inheritance happens through the element tree
  594. # [20:12] <fantasai> vhardy: you're adding selectors that apply to fragments
  595. # [20:12] <fantasai> ...
  596. # [20:13] <fantasai> vhardy: In our model, you'll set a selector: if my H1 is in this region, here's the font size that applies
  597. # [20:13] <fantasai> howcome: in that sense you don't have multiple inheritance
  598. # [20:13] <fantasai> Steve: the multiple inheritance is when you have different pieces of the block that get different styling
  599. # [20:13] <fantasai> CHrisL: Similar to ::first-letter multiple inheritance
  600. # [20:13] <fantasai> dbaron: no, I don't think it is
  601. # [20:13] <fantasai> dbaron: Wanted to bring up 2 other things
  602. # [20:14] <fantasai> dbaron: Thing you said about percentages relative to the original, that sounded wrong to me.
  603. # [20:14] <fantasai> dbaron: I'd think if you have separate styles for stuff in the region, you'd compute styles in a consistent model within that tree
  604. # [20:14] <fantasai> dbaron: Percentages etc. would compute relative to those styles until you're back outside of that region
  605. # [20:14] <fantasai> dbaron: I don't think multiple inheritance is the right way to think about that.
  606. # [20:14] <fantasai> dbaron: Other thing I wanted to mention is, if we think about it that way
  607. # [20:15] <fantasai> dbaron: Then any property that takes lengths can change as a result of font-size changes.
  608. # [20:15] <fantasai> dbaron: It seems silly to restrict that then, i.e. only allow changes as a result of font-size but not arbitrarily otherwise.
  609. # [20:15] <fantasai> dbaron: Basically if you have @region head { body {font-size: 2em; }}
  610. # [20:16] <fantasai> s/}}/}/
  611. # [20:16] <fantasai> }
  612. # [20:16] <fantasai> h1 { height: 2em; }
  613. # [20:16] <fantasai> dbaron: Your body font size is going to be double your HTML font size as it flows into this region.
  614. # [20:16] <fantasai> dbaron: your h1 initial font size is specifid in ems
  615. # [20:17] <fantasai> dbaron: If you accept what steve and I say, then the h1 is going to be proportionally larger
  616. # [20:17] <fantasai> dbaron: but what you said earlier is that it wouldn't be
  617. # [20:17] <fantasai> Steve: So I thought what yoy said is that you're overlaying styles on these elements using selectors
  618. # [20:17] <fantasai> Steve: so you'd walk up the tree and see the overlaid styles
  619. # [20:17] <fantasai> vhardy: ... this is why the properties only make sense ..
  620. # [20:18] <fantasai> vhardy: height doesn't make sense to apply to different fragments of the div
  621. # [20:18] <fantasai> steve: height has to look somewhere for its value
  622. # [20:18] <fantasai> vhardy: So that's something you'd have to compute relative to the parent element
  623. # [20:18] <fantasai> vhardy: If my h1 is in the head region, will it be base don that value or the other one
  624. # [20:18] <fantasai> vhardy: I'll take an action item on that.
  625. # [20:19] <fantasai> howcome: We all wanted to have a use case appendix, wasn't recorded as an action item.
  626. # [20:19] <fantasai> ACTION vhardy: Make a use case appendix
  627. # [20:19] * RRSAgent records action 4
  628. # [20:19] * trackbot noticed an ACTION. Trying to create it.
  629. # [20:19] <trackbot> Created ACTION-377 - Make a use case appendix [on Vincent Hardy - due 2011-11-06].
  630. # [20:19] <fantasai> <br type=lunch>
  631. # [20:19] <glazou> br is empty :-)
  632. # [20:19] * Quits: bradk (bradk@64.129.229.106) (Quit: Computer has gone to sleep)
  633. # [20:20] <mollydotcom> but lunch is presentational :P
  634. # [20:21] <ChrisL> <br type="lunch" dur="60min" />
  635. # [20:22] * Quits: arronei_ (arronei@64.129.229.106) (Ping timeout)
  636. # [20:24] * Quits: sylvaing (sylvaing@64.129.229.106) (Ping timeout)
  637. # [20:33] * Quits: tcelik (tantek_@64.129.229.106) (Quit: tcelik)
  638. # [20:34] * Quits: szilles (chatzilla@192.150.10.201) (Ping timeout)
  639. # [20:38] * Joins: szilles (chatzilla@192.150.10.201)
  640. # [20:42] * Joins: arronei_ (arronei@64.129.229.106)
  641. # [20:49] * Joins: sylvaing (sylvaing@64.129.229.106)
  642. # [20:49] * Quits: tantek (tantek@64.129.229.106) (Quit: tantek)
  643. # [20:57] * Quits: szilles (chatzilla@192.150.10.201) (Ping timeout)
  644. # [21:00] * Joins: bradk (bradk@64.129.229.106)
  645. # [21:03] * Joins: guacamole (5ad7ffd3@207.192.75.252)
  646. # [21:04] * Parts: guacamole (5ad7ffd3@207.192.75.252)
  647. # [21:09] <dbaron> ScribeNick: dbaron
  648. # [21:10] <dbaron> Topic: Orientation and unicode properties for vertical text layout
  649. # [21:10] * Joins: szilles (chatzilla@192.150.10.201)
  650. # [21:10] <jdaggett_> http://www.unicode.org/reports/tr50/
  651. # [21:10] <glazou> "Orientation and Unicode properties for vertical text layout"
  652. # [21:10] * Joins: tantek (tantek@64.129.229.106)
  653. # [21:10] <dbaron> jdaggett: I put this on the wiki. Based on discussions from the summer. Current writing modes spec doesn't have an entirely normative defintion of orientation.
  654. # [21:11] <dbaron> jdaggett: So it wasn't clear what exactly the default orientation should be. This means that in vertical text layout, some characters, e.g. ideographic, stay upright, whereas roman characters are rotated on their side. The question is which characters go which way.
  655. # [21:11] <dbaron> jdaggett: The current spec has an appendix which gives an algorithm; I don't know whether it's currently marked as normative.
  656. # [21:12] <dbaron> jdaggett: But the question is what the right way to do this is. In talking with Eric Muller (sitting in the back), it would make sense to make a Unicode property for this specifically.
  657. # [21:12] <dbaron> jdaggett: This proposal is to make an additional property for Unicode that would specify the default orientation that the writing-modes spec could normatively reference.
  658. # [21:12] <dbaron> jdaggett: There's a comment period now, and there will be another review period.
  659. # [21:13] <jdaggett_> http://wiki.csswg.org/spec/utr50
  660. # [21:13] <dbaron> Eric: Process-wise, UTC meets next week. Then produce a draft version of the TR and have another round of review.
  661. # [21:13] <dbaron> jdaggett: These http://wiki.csswg.org/spec/utr50 are Elika's and Koji's comments as to different issues.
  662. # [21:13] <dbaron> jdaggett: Very clear for ideographic and alphabetic characters, but there are a number of character ranges where it's more difficult to decide.
  663. # [21:13] <jdaggett_> http://www.unicode.org/reports/tr50/bycp.html
  664. # [21:14] <dbaron> jdaggett: http://www.unicode.org/reports/tr50/bycp.html is the proposed list of codepoints and how they change
  665. # [21:14] <jdaggett_> http://lists.w3.org/Archives/Public/www-archive/2011Sep/att-0010/defaultorientation.pdf
  666. # [21:14] <dbaron> jdaggett: http://lists.w3.org/Archives/Public/www-archive/2011Sep/att-0010/defaultorientation.pdf is a PDF that shows ... scroll down to U+2000 ...
  667. # [21:14] * Bert daniel, don't forget the 2 minutes on the agenda for publishing css3-layout (and css3-regions, because I think Vincent had that on his agenda as well)
  668. # [21:15] <dbaron> jdaggett: These are some general punctuation characters. Green column shows the vertical alternate that exists in the font (Hiragino Mincho, Kozuka Mincho, Meiryo).
  669. # [21:15] <dbaron> jdaggett: Where the character in the green column is different it means there's a vertical alternate for that codepoint.
  670. # [21:15] <dbaron> jdaggett: U+2014, em-dash, no fonts have vertical alternates for it
  671. # [21:16] <dbaron> ?: Using the VERT feature for this?
  672. # [21:16] <dbaron> ?: In Kozuka font, U+2014 is proportional -- covered by VRT2 but not by VERT.
  673. # [21:16] <dbaron> ?: In vertical, you do want U+2014 rotated to go along with other Latin characters that get rotated as well.
  674. # [21:17] <dbaron> jdaggett: On the Mac it's natural to use U+2014, on Windows it's natural to use U+2015.
  675. # [21:17] <dbaron> ?: In our fonts it's also a distinction between proportional and full-width.
  676. # [21:17] <dbaron> jdaggett: When you say proportional, the expectation is that it will be set sideways.
  677. # [21:17] <dbaron> ?: do that with VRT2
  678. # [21:18] <dbaron> jdaggett: scroll down to the arrows... high U+2190s
  679. # [21:18] <dbaron> jdaggett: See that the arrows are ... U+2190 pointing to the text that's coming before it
  680. # [21:18] <dbaron> jdaggett: I also have how the current IE and WebKit implementations handle this.
  681. # [21:19] <dbaron> jdaggett: These may not be totally accurate because it's a little tricky to figure out.
  682. # [21:19] <ChrisL> http://www.microsoft.com/typography/otspec/features_uz.htm#vert http://www.microsoft.com/typography/otspec/features_uz.htm#vrt2
  683. # [21:19] <dbaron> jdaggett: The problem we want to solve is that we don't want different implementations handling this differently.
  684. # [21:19] <dbaron> jdaggett: Once Unicode has a property that establishes this we have firmer ground to make text-orientation consistent across implementations.
  685. # [21:20] <dbaron> jdaggett: We won't get a solution that works 100% of the time, but we'll get a good default that authors can still change when they need to.
  686. # [21:21] * Joins: tcelik (tantek_@64.129.229.106)
  687. # [21:21] * Joins: Liam (liam@128.30.52.169)
  688. # [21:21] <dbaron> Bert: Looks like an issue for Unicode, not us.
  689. # [21:21] <dbaron> jdaggett: Right now our spec is defining an equivalent of this.
  690. # [21:21] <dbaron> fantasai: Yes, once Unicode defines this we will reference it.
  691. # [21:22] <dbaron> jdaggett: When you go into the details there are still questions as to what the OpenType layout model is for vertical text, and questions for which way specific code ranges should go.
  692. # [21:22] <dbaron> fantasai: Details of code ranges don't need the whole room.
  693. # [21:23] <dbaron> SteveZ: In other words, if you think you care, look at these documents (wiki, tr50) and comment.
  694. # [21:23] <dbaron> jdaggett: We have two browser implementations of vertical text, and it would be nice if the implementors ...
  695. # [21:23] <dbaron> fantasai: ... looked at this and made comments as appropriate.
  696. # [21:23] <dbaron> jdaggett: There's wide variation between existing implementations.
  697. # [21:24] <dbaron> SteveZ: One thing that's important as a principle: we're trying to do it so the choice of whether something is rotated or upright can be made without looking at the font data. One reason for that is that it's expensive or impossible given how the font data are encoded in OpenType (and may be impossible through some OS interfaces). But it must work in the context where the fonts do things in certain circumstances, so it's a slightly messy problem.
  698. # [21:25] <dbaron> Topic: Gradients
  699. # [21:26] <bradk> http://wiki.csswg.org/ideas/radial-gradients
  700. # [21:26] <dbaron> ACTION hober to review Unicode TR50 and compare to existing implementation
  701. # [21:26] * trackbot noticed an ACTION. Trying to create it.
  702. # [21:26] <trackbot> Created ACTION-378 - Review Unicode TR50 and compare to existing implementation [on Edward O'Connor - due 2011-11-06].
  703. # [21:26] <dbaron> ACTION sylvain to review Unicode TR50 and compare to existing implementation
  704. # [21:26] * trackbot noticed an ACTION. Trying to create it.
  705. # [21:26] <trackbot> Created ACTION-379 - Review Unicode TR50 and compare to existing implementation [on Sylvain Galineau - due 2011-11-06].
  706. # [21:26] <dbaron> Topic: ?
  707. # [21:26] <dbaron> Bert: You said you wanted to publish regions as well?
  708. # [21:26] <jdaggett_> s/TR/UTR/
  709. # [21:27] <dbaron> Bert: I also wanted to ask if we could publish a new template layout module.
  710. # [21:27] <dbaron> glazou: A little more than a week -- let's say two weeks to look at this, and then make a decision in 2 weeks?
  711. # [21:27] <dbaron> Håkon: Can we do the action points first before we publish? I think it would be helpful for the specs to have code examples.
  712. # [21:28] <dbaron> jdaggett: replacing the pseudo-code with real code
  713. # [21:28] <dbaron> Håkon: maybe put in a couple of use cases
  714. # [21:28] <dbaron> s/Topic: ?/Topic: publishing template and regions/
  715. # [21:28] <dbaron> SteveZ (?): There are use cases on the wiki.
  716. # [21:29] <dbaron> RESOLVED: publish regions and template if there are no objections in 2 weeks
  717. # [21:29] <dbaron> Topic: Gradients
  718. # [21:29] <dbaron> Tab: I assume everybody has read all the mailing list discussion on the subject. :-)
  719. # [21:29] <dbaron> http://wiki.csswg.org/ideas/radial-gradients
  720. # [21:29] <dbaron> Tab: We have 2 proposed syntaxes for radial gradients. The one in the draft and brad's simplification of it.
  721. # [21:29] <dbaron> Tab: The differences between them at this point are that:
  722. # [21:30] <dbaron> - draft allows arbitrary position; brad allows center/side/corners only
  723. # [21:30] <dbaron> - draft allows more options sizing the gradient; Brad has just circle or ellipse that fills the box
  724. # [21:30] <dbaron> Tab: The question is which one we're going to keep.
  725. # [21:30] <dbaron> Tab: This is the only remaining issue with css3-images; want to move to LC.
  726. # [21:31] <dbaron> fantasai: Do a pre-LC TR draft first.
  727. # [21:31] <dbaron> Brad: When we did linear gradients, we simplified it and made it easy to understand and learn.
  728. # [21:31] <dbaron> Brad: I think all the options in the draft are confusing and overcomplicated, and I think the way people use those options is really confusing.
  729. # [21:31] <dbaron> Brad: I think the layering of different properties that affect the length of the gradient line in different ways.
  730. # [21:31] <dbaron> Brad: In some cases position makes the gradient line larger or smaller.
  731. # [21:32] <dbaron> Brad: To understand what's going on you have to understand what wins when background-position and background-size change it
  732. # [21:32] <dbaron> Brad: The arguments for all this extra control seem to be centered around non-background use of radial gradients, which are, imo, edge cases.
  733. # [21:33] <dbaron> Brad: If you want to use a radial gradient as a list-style-image, and you can't get the clipping/styling/positioning you want, I think that's a minor issue that shouldn't drive the syntax.
  734. # [21:34] <dbaron> Tab: I disagree with that. Making all the other image-bearing properties have properties analogous to background-position and background-size (list-style-image, border-image, masks) ...
  735. # [21:34] <dbaron> Tab: While you can do without it for the most part in backgrounds.
  736. # [21:34] <dbaron> Tab: I think what's there isn't that hard and is sufficiently useful to justify itself.
  737. # [21:35] <dbaron> Tab: There are 3 bits that require thinking about with a radial gradient: if you're using a position other than center then all the implicit sizing keywords and ? and ? are relatively simple to think about if you're only using 1 or 2 of them together.
  738. # [21:36] <dbaron> Tab: The one in Lea Verou's gallery that used all 3 and was very confusing was done that way because existing browsers don't have explicit sizing.
  739. # [21:36] <dbaron> Tab: This is the Hearts Grid example.
  740. # [21:36] <dbaron> Tab: You can do the "Syntax A" version
  741. # [21:37] <dbaron> Elika: Which is the position and which is the size?
  742. # [21:37] <dbaron> Tab: position, then size
  743. # [21:37] <dbaron> Brad: That's my whole point: we're saying that if you want explicit sizing you have to put in a value for the position, since you need that comma in there to distinguish.
  744. # [21:37] <dbaron> Tab: The problem of positions and sizes looking similar is also in the background shorthand.
  745. # [21:37] <dbaron> Brad: slash there, comma here?
  746. # [21:38] <dbaron> Elika: I'd prefer something that didn't involve comma-separating everything so we could tell what's what.
  747. # [21:38] <dbaron> Tab: Unless we did a slash I'm not sure what we'd do.
  748. # [21:38] <dbaron> Daniel: no slash
  749. # [21:38] <dbaron> Brad: ...
  750. # [21:38] <dbaron> Brad: If it's a problem that we can't size images for list-style-image then it's a problem for all images, not just gradients.
  751. # [21:39] <dbaron> Arron: It's the intrinsic size of the image.
  752. # [21:39] <dbaron> Tab: With a gradient you can't control the intrinsic size.
  753. # [21:39] <dbaron> Chris: I don't agree that non-background cases are minority: I think we're going to see more of that. I'm reluctant to see a solution that doesn't give full functionality to non-background images.
  754. # [21:39] * Zakim excuses himself; his presence no longer seems to be needed
  755. # [21:39] * Parts: Zakim (rrs-bridgg@128.30.52.169)
  756. # [21:40] <dbaron> Brad: Won't those types of images need that functionality anyway?
  757. # [21:40] <dbaron> Chris: There are things that know how to size themselves that are not background images.
  758. # [21:40] <dbaron> Elika: With a PNG image, you have the same problem.
  759. # [21:40] <dbaron> Elika: Wouldn't it be better to have a mechanism general enough to handle non-gradient images?
  760. # [21:40] <dbaron> Brad: Better not to have to use the gradient functions to solve that problem.
  761. # [21:41] <dbaron> Chris: Things I'm thinking of don't have that problem -- they know how big they are.
  762. # [21:41] <dbaron> Chris: The syntax that requires background-size and background-position, then we'd be very limited using CSS gradients for 'fill' and 'stroke'.
  763. # [21:41] <fantasai> radial-gradient(<size> <shape> from <position> as <color-stop>, <color-stop>, ...)
  764. # [21:42] <fantasai> <size> would be one of the keywords
  765. # [21:42] <dbaron> Chris: existing syntax has % and absolute, corresponding to SVG's userSpaceOnUse and boundingBoxRelative
  766. # [21:42] <dbaron> (minute taker has trouble keeping up)
  767. # [21:43] <dbaron> Brad: simplicity is a feature, makes CSS easier to learn
  768. # [21:43] <dbaron> Elika: I'd prefer a halfway point between the two.
  769. # [21:44] <dbaron> Brad: I already went a little towards Tab's with putting center on edge/corner.
  770. # [21:44] <dbaron> Elika: farthest-corner, etc., make it easier for me to think about
  771. # [21:44] * Quits: JohnJansen (qw3birc@128.30.52.28) (Quit: Page closed)
  772. # [21:44] <dbaron> Brad: ... other colors going on past ...
  773. # [21:45] <dbaron> Elika: put a color stop at the nearest corner?
  774. # [21:45] <dbaron> Brad: That seems more complicated than just saying 142%
  775. # [21:46] <dbaron> Brad: When I'm desiging things I'm doing it visually.
  776. # [21:46] <dbaron> 1.4142135623730951
  777. # [21:46] <tcelik> would this qualify as an irrational discussion?
  778. # [21:46] <stearns> (that will be the tattoo for Tab's other arm)
  779. # [21:47] <dbaron> Brad: It's can be important to hit the edges exactly when getting a circle, but matters less to be exact at the corners.
  780. # [21:47] <dbaron> Molly: None of this makes any sense to designers/developers -- I don't think this belongs in CSS.
  781. # [21:47] <dbaron> Molly: ok, let's leave the second point for dinner conversation
  782. # [21:48] <dbaron> Daniel: I implemented a visual editor for the gradient proposal -- it's very complicated because of the syntax.
  783. # [21:48] <dbaron> Daniel: I did the original WebKit proposal and the WG one afterwards.
  784. # [21:48] <dbaron> Tab: It should be a lot easier now with explicit sizing.
  785. # [21:48] <dbaron> Brad: I made a list of all the details I had to learn about how these parameters interact with each other.
  786. # [21:49] <dbaron> Brad: linear gradients are simple, one side to the other
  787. # [21:49] <dbaron> Brad: With this simplification, you're either going from one side to the other or center to the side
  788. # [21:50] <dbaron> Brad: keeping it simple makes it much more understandable
  789. # [21:51] <dbaron> Tab: Linear gradients are easier because it's one-dimensional.
  790. # [21:51] <dbaron> Tab: Any linear gradient can be represented using the current syntax. Can't do that with radial gradient -- many can't be expressed in simpler form.
  791. # [21:52] * Joins: JohnJansen (qw3birc@128.30.52.28)
  792. # [21:52] <dbaron> Brad: I'd want things more towards the simple side.
  793. # [21:52] <dbaron> Molly: Agree. This is really SVG. We're putting it in CSS because designers want it right now. I think we need to keep it simple and respect what's in SVG.
  794. # [21:53] <Bert> +1 to Molly
  795. # [21:53] * Bert doesn't feel so alone anymore :-)
  796. # [21:53] <dbaron> Molly: Designers would love the perfect WYSIWYG. As implementors you may be able to understand something, but putting it in language that people with less experience can explain... Trying to stopgap a need from designers. Concerned about simplicity and relation to SVG.
  797. # [21:54] <dbaron> Tab: Remember, the majority of gradient usage won't use the functionality we're talking about.
  798. # [21:54] <dbaron> Sylvain: We have 4 implementations.
  799. # [21:55] <dbaron> Daniel: Opinions of those who make tools that design gradients?
  800. # [21:55] * Quits: Liam (liam@128.30.52.169) (Ping timeout)
  801. # [21:55] <dbaron> Daniel: we have to reach a consensus
  802. # [21:55] <dbaron> Arno: I'd lean towards the simpler syntax.
  803. # [21:55] <dbaron> John: I would too
  804. # [21:56] <dbaron> Alan: There is an SVG fallback.
  805. # [21:57] <dbaron> Sylvain: Authors I've talked to have been more bothered by the change to bearing angles than by the complexity. What seems complex now may not in the future.
  806. # [21:57] <dbaron> Brad: I don't think complexity goes away.
  807. # [21:57] <dbaron> Elika: I'm confused by both syntaxes. I'd want something more readable.
  808. # [21:58] <dbaron> Elika: How can we make it obvious which part means what?
  809. # [21:58] <dbaron> Elika: Get away from commas, use keywords.
  810. # [21:58] <dbaron> Elika: linear-gradient(from left as red, blue, green)
  811. # [21:58] <dbaron> Elika: radial-gradient(circle from top left as red, blue, green)
  812. # [21:59] <dbaron> Elika: radial-gradient(<shape>? from <position> as <color-stop-list>)
  813. # [22:00] <dbaron> Brad: I do have the 'from' keyword, optional if not starting from the center.
  814. # [22:01] <dbaron> Bert: Why 'circle' at all?
  815. # [22:01] <dbaron> Elika: Otherwise it's an ellipse.
  816. # [22:02] <dbaron> Elika: gradients have no intrinsic ratio
  817. # [22:02] <dbaron> Elika: You can do Tab's set of functionality or Brad's with this syntax, but I think it'll be understandable
  818. # [22:03] <dbaron> Brad: I have the idea that if you specify 'circle' it does have an intrinsic ratio.
  819. # [22:03] <dbaron> Brad: That solves the what if you want a non-distorted circle that fills to the corners.
  820. # [22:04] <fantasai> dbaron: I don't think giving it an intrinsic ration solves what you think it solves
  821. # [22:05] <fantasai> dbaron: I think what you were saying is that if you want a circle that fills out to the corners of a non-square box
  822. # [22:05] <fantasai> dbaron: so you want somehting where the extent of the graident is that *draws rectangle inscribed in an ellipse*
  823. # [22:05] <fantasai> Brad: sorry, should have said "background-size: cover"
  824. # [22:06] <fantasai> dbaron: that'll be smaller than what you want
  825. # [22:06] <fantasai> Brad: I have a circle, used the circle keyword, and draw gradient to 142%
  826. # [22:07] <fantasai> Brad: and then ..
  827. # [22:07] <fantasai> dbaron: I don't know if we need to dig into this too much, though.
  828. # [22:07] <fantasai> Steve: You would get what you want if the diameter of the circle covers the box.
  829. # [22:07] <fantasai> Steve: Which is another way of saying...
  830. # [22:07] <fantasai> dbaron: Tab's syntax has keywords for those four possibilities.
  831. # [22:08] <fantasai> daniel: we've been working on gradient syntax for months withouth conclusion
  832. # [22:08] <fantasai> steve: one reason we might not have a conclusions is that neither are acceptable yet
  833. # [22:08] <fantasai> steve: there are good ideas in both, but still haven't gotten one that people understand and can communicate
  834. # [22:08] <fantasai> daniel: Both solutions are okay. That's the problem.
  835. # [22:09] <fantasai> daniel: But we need a resolution, and designers need this to ship
  836. # [22:09] <fantasai> sylvain: People are using this today.
  837. # [22:09] <fantasai> dbaron: And they're using it enough that this might wind up being the first -moz-prefixed thing we are unable to drop, given the number of changes.
  838. # [22:10] <fantasai> fantasai: I really want to go in this direction. I can't read this stuff.
  839. # [22:11] <fantasai> (this == using keywords)
  840. # [22:11] <fantasai> Tab: I want to resolve on this asap.
  841. # [22:11] <fantasai> Tantek: You're saying taking longer hurts more than complexity
  842. # [22:11] <Ms2ger> Don't we all?
  843. # [22:11] <fantasai> Molly: And then educators are stuck with this for eternity
  844. # [22:12] <fantasai> daniel: What's the plan?
  845. # [22:12] <fantasai> fantasai: I would like 24 hours with Brad and Tab and come back here tomorrow.
  846. # [22:12] <fantasai> Tab: What I want more than anything else for my birthday is to close this issue.
  847. # [22:13] <tantek> Dante's Inferno would have used radial gradients.
  848. # [22:13] * hober the 9 color stops of Hell
  849. # [22:13] <arno> :)
  850. # [22:13] <dbaron> the closest-side, etc. could be following a 'to'
  851. # [22:14] <dbaron> Tab: Brad's concern about complication is about position of the gradient line.
  852. # [22:15] <dbaron> Bert: What's the difference if it's not the syntax?
  853. # [22:15] <dbaron> fantasai: The ability to do arbitrary center, and the {farthest,closest}-{corner,side}, and explicit sizing of the ellipse.
  854. # [22:15] * Joins: drublic (drublic@95.115.25.171)
  855. # [22:16] * hober an example of brad's gradient: http://media-cdn.tripadvisor.com/media/photo-s/01/c4/e1/5f/guinness-storehouse.jpg
  856. # [22:16] <dbaron> Brad: And the fact that I'm starting from edge or center means I can go from corner to the full width of the element maintaining a circle.
  857. # [22:17] <dbaron> dbaron: Isn't that farthest-side?
  858. # [22:17] <dbaron> Tab: My syntax gives you the option.
  859. # [22:17] <dbaron> Daniel: We are running in circles.
  860. # [22:17] <dbaron> (Aren't we running in ellipses?)
  861. # [22:18] <dbaron> Daniel: Straw poll, syntax A (Atkins) vs. syntax B (Brad)
  862. # [22:18] <dbaron> Luke MacPherson: A
  863. # [22:18] <dbaron> Shane: A
  864. # [22:18] <dbaron> Steve: no comment
  865. # [22:18] <dbaron> Molly: abstain
  866. # [22:18] <dbaron> Bert: B (set of features, not syntax)
  867. # [22:18] <dbaron> Stearns: abstain
  868. # [22:19] <dbaron> Alex: to Sylvain
  869. # [22:19] <dbaron> Arno: A
  870. # [22:19] <dbaron> Brad: B
  871. # [22:19] <dbaron> Tab: A
  872. # [22:19] <dbaron> Elika: abstain
  873. # [22:19] <dbaron> Daniel: B
  874. # [22:19] <dbaron> Koji: A
  875. # [22:19] <dbaron> John Daggett: don't like either, so abstain
  876. # [22:19] <dbaron> David: I guess A.
  877. # [22:20] <dbaron> Arron: A
  878. # [22:20] <dbaron> Sylvain: A
  879. # [22:20] <dbaron> John: I'll have to learn A.
  880. # [22:20] <dbaron> Håkon: abstain
  881. # [22:20] <dbaron> Peter: abstain
  882. # [22:20] <dbaron> Chris: A
  883. # [22:20] <dbaron> Vincent: A
  884. # [22:20] <dbaron> Rossen: A
  885. # [22:20] <dbaron> Tantek: A
  886. # [22:20] <dbaron> Hober: A
  887. # [22:20] <dbaron> Resolved: Stick with Tab's set of features.
  888. # [22:21] <dbaron> ACTION Tab and Elika: discuss improvements to syntax within this set of features
  889. # [22:21] * trackbot noticed an ACTION. Trying to create it.
  890. # [22:21] <trackbot> Created ACTION-380 - And Elika: discuss improvements to syntax within this set of features [on Tab Atkins Jr. - due 2011-11-06].
  891. # [22:22] <dbaron> Can we teach tracker to give actions to 2 people?
  892. # [22:22] <fantasai> ACTION plinss: teach Tracker to give actions to multiple people
  893. # [22:22] * trackbot noticed an ACTION. Trying to create it.
  894. # [22:22] * RRSAgent records action 5
  895. # [22:22] <trackbot> Created ACTION-381 - Teach Tracker to give actions to multiple people [on Peter Linss - due 2011-11-06].
  896. # [22:22] <fantasai> :P
  897. # [22:22] <Ms2ger> ACTION Elika and Tab: discuss improvements to syntax within this set of features
  898. # [22:22] * trackbot noticed an ACTION. Trying to create it.
  899. # [22:22] <trackbot> Created ACTION-382 - And Tab: discuss improvements to syntax within this set of features [on Elika Etemad - due 2011-11-06].
  900. # [22:22] <Ms2ger> :)
  901. # [22:23] * Quits: bradk (bradk@64.129.229.106) (Quit: Computer has gone to sleep)
  902. # [22:27] * Quits: tcelik (tantek_@64.129.229.106) (Quit: tcelik)
  903. # [22:28] * Quits: JohnJansen (qw3birc@128.30.52.28) (Quit: Page closed)
  904. # [22:32] * Quits: tantek (tantek@64.129.229.106) (Quit: tantek)
  905. # [22:32] * Quits: plinss (plinss@64.129.229.106) (Quit: plinss)
  906. # [22:51] * Joins: bradk (bradk@64.129.229.106)
  907. # [22:51] <dbaron> Topic: CSS Object Model
  908. # [22:52] * Joins: BradK_ (bradk@64.129.229.106)
  909. # [22:52] <fantasai> [side-note wrt writing-modes] fantasai: we might want to discuss property to tailor UTR50 to handle e.g. greek/cyrillic being upright, but we can discuss that offline
  910. # [22:52] * Quits: bradk (bradk@64.129.229.106) (Quit: Computer has gone to sleep)
  911. # [22:52] * BradK_ is now known as BradK
  912. # [22:52] <dbaron> Håkon: Anne will be at TPAC Monday and Tuesday.
  913. # [22:52] <fantasai> jdaggett: Shouldn't Anne be here?
  914. # [22:53] <dbaron> Daniel: Originally Scheduled for Tuesday at 9am.
  915. # [22:53] <fantasai> howcome: I can inform him that we'll discuss this Tuesday at 9am
  916. # [22:53] <fantasai> glazou: if he's not going to show up to discussions...
  917. # [22:53] <fantasai> glazou: Ok, next topic
  918. # [22:53] <fantasai> Topic: CSS Exclusions and Shapes
  919. # [22:54] <Rossen> http://dev.w3.org/csswg/css3-exclusions
  920. # [22:54] <dbaron> http://dev.w3.org/csswg/css3-exclusions/
  921. # [22:55] <fantasai> Rossen: there were two independent spec works being done by MS and Adobe before we even brought any of this to the WG, and at some point Adobe brought in original Regions and Exclusions spec, and that was halfway when almost done with our part and getting ready to propose working on Floats
  922. # [22:55] <fantasai> Rossen: At that time we decided to see what the differences and similarities are and come up with one single spec
  923. # [22:55] <fantasai> Rossen: CSS Exclusions was split from CSS Regions
  924. # [22:56] <fantasai> Rossen: And since last F2F in Seattle our one major action was to redo the spec combine, css exclusions and positioned floats and present that
  925. # [22:56] <fantasai> Rossen: And get that towards WD
  926. # [22:56] <fantasai> Rossen: So CSS Exclusiosn and Shapes we are talking about today
  927. # [22:56] <fantasai> Rossen: We're going to see what CSS Exclusions are and how to use them, and what the CSS Shapes are and how to use them
  928. # [22:57] <fantasai> Rossen: The two concepts are currently separate concepts, but they actually work really well together. So keeping them in same spec for now
  929. # [22:57] * Joins: JohnJansen (qw3birc@128.30.52.28)
  930. # [22:57] <fantasai> Rossen: CSS Exclusions
  931. # [22:57] <fantasai> Rossen: Baic definition, it's an area that you want to preserv clear from any inline-flow layout
  932. # [22:57] * Joins: tantek (tantek@64.129.229.106)
  933. # [22:57] <fantasai> Rossen: Many example sof this in magazine layouts: pull-quotes, figures with type wrapped around them, etc.
  934. # [22:57] <vhardy> s/Baic/Basic
  935. # [22:57] <fantasai> Rossen: In CSS we already have floats, which are like exlcusions, but we lack the ability to position them precisely
  936. # [22:58] <fantasai> Rossen: Currently we allow exclusions to be applied to any block-level element
  937. # [22:58] <fantasai> Rossen: so an exclusion can be any block-level element
  938. # [22:58] * ChrisL such as ins and del
  939. # [22:58] <fantasai> Rossen: Combined with abpso you can create some really magazine-like layouts.
  940. # [22:58] <fantasai> Rossen: I will show slides and spec side-by-side
  941. # [22:59] <fantasai> Rossen: So, declaring exclusions is done with the 'wrap-flow' property
  942. # [22:59] <fantasai> Rossen: Setting it to anything other than 'auto' creates an exclusion
  943. # [23:00] <fantasai> Rossen: 'auto' in this case is special because for regular flow elements the 'auto' value doesn't change the behavior of floats
  944. # [23:00] <fantasai> Rossen: Exclusions can be applied on the left, right, or both sides
  945. # [23:00] <BradK> Exclusions apply to block only, but floats turn inclines into blocks. Shouldn't they behave similarly?
  946. # [23:01] <fantasai> Rossen: maximum picks the left or right, whichever has the most space left
  947. # [23:01] <fantasai> Rossen: Last one is clear, which clears wrapping on both left and right
  948. # [23:02] <TabAtkins_> scribenick: TabAtkins_
  949. # [23:02] <TabAtkins_> jdaggett_: Is there a typo with the maximum example showing up twice?
  950. # [23:02] <TabAtkins_> Rossen: No, the example shows what 'maximum' does when there's more room on one space or the other.
  951. # [23:03] <TabAtkins_> szilles: 'left' and 'right' don't work vertically.
  952. # [23:03] <TabAtkins_> fantasai: It would probably map to line-left and line-right, but it should probably just be 'start' and 'end'.
  953. # [23:04] <TabAtkins_> fantasai: Or have them both, since they do slightly different things.
  954. # [23:04] <TabAtkins_> jdaggett_: Why not just start and end?
  955. # [23:04] <TabAtkins_> fantasai: If you have a design that doesn't depend on the writing direction, frex.
  956. # [23:05] <TabAtkins_> howcome: Are there any restrictions on what elements can affect other things?
  957. # [23:05] <TabAtkins_> Rossen: Next slide, containing model.
  958. # [23:05] <TabAtkins_> Rossen: We're not changing things beyond what 2.1 already specifies.
  959. # [23:05] <TabAtkins_> Rossen: We find the containing block, and that's the exclusion container too.
  960. # [23:06] <TabAtkins_> scribenick: fantasai
  961. # [23:06] <fantasai> Rossen: The definition we have for wrapping context is simply a collection of exclusion elements.
  962. # [23:06] <fantasai> s/elements/areas/
  963. # [23:06] <fantasai> Rossen: An exclusion area is the area defined by the element. Initially this is the border-box of the element
  964. # [23:06] <fantasai> Rossen: As we'll see later on, this can be changed into a shape
  965. # [23:06] <fantasai> howcome: I can't really parse this text here
  966. # [23:07] <fantasai> howcome: If an abspos comse from outside, will it affect layout of a deeply-nested <p> element?
  967. # [23:07] <fantasai> Rossen: Does everyone understand the containing model?
  968. # [23:07] <fantasai> Rossen: You have somewhere in a subtree of an element an abpsos element, and it positions to a containing block.
  969. # [23:08] <fantasai> Rossen: The scope of the exclusion is the entire subtree of the containing block.
  970. # [23:08] <fantasai> howcome: Then you have 'wrap-through' property.
  971. # [23:08] <fantasai> Rossen: You can use that property to stop the propagation of wrap context at any level of the subtree. But in the subree only
  972. # [23:08] * Joins: tcelik (tantek_@64.129.229.106)
  973. # [23:09] <fantasai> Rossen shows the example of 'wrap-through' right above the 'wrap' shorthand definition
  974. # [23:09] <fantasai> jdaggett: ...
  975. # [23:09] <fantasai> Rossen: It's positioned and sized following CSS2.1 rules.
  976. # [23:09] <fantasai> Rossen: Once it is positioned, it is registered as an exclusion, and the flow layout will continue from that point on, respecting that exclusion
  977. # [23:09] <fantasai> jdaggett: The content of the exclusionary is what?
  978. # [23:10] <fantasai> jdaggett: What goes in that div that you're absolutely positioning?
  979. # [23:10] <TabAtkins_> Shane suggests a 'rap' property to complement 'flow'.
  980. # [23:10] <fantasai> howcome: So 'wrap-through', it's similar to 'float-through'
  981. # [23:10] <fantasai> Bert: No, that's different
  982. # [23:10] * Joins: mouse (5e080aef@207.192.75.252)
  983. # [23:10] <fantasai> dbaron: That's propagation to ancestors, not descendants
  984. # [23:10] <fantasai> howcome: If you have a <p> and you have a float on the side, you end the element, the float continues
  985. # [23:11] <fantasai> dbaron: Wrap through is about going through to descendants
  986. # [23:11] <fantasai> dbaron: This model can't describe float, basically
  987. # [23:11] <fantasai> howcome: But you're introducing a different concept.
  988. # [23:11] <fantasai> howcome: Could we not latch onto one of the other contexts that we have?
  989. # [23:11] <fantasai> howcome: I'm wary of introducing yet another reference model
  990. # [23:12] * Quits: szilles (chatzilla@192.150.10.201) (Ping timeout)
  991. # [23:12] <fantasai> vhardy: We've been bounching around on this for several months, this is what we ended up with
  992. # [23:12] <fantasai> Rossen: We started with floats, but it had a lot of issues that we were not able to solve.
  993. # [23:12] <fantasai> Bert: I think you're talking about something else, howcome.
  994. # [23:13] <fantasai> Bert: The second paragraph that you (howcome) didn't draw. The wrap-through property isn't about whether the float goes through, but whether the line boxes in the second <p> wrap around it
  995. # [23:13] <fantasai> howcome: It's so similar to floats, we should extend floats
  996. # [23:13] <fantasai> Rossen: .. they do create exclusions, and in this respect they're the same
  997. # [23:13] <fantasai> Rossen: In this respect they're not completley normal. But it is the positioning that we want to address.
  998. # [23:14] <fantasai> Rossen: Do people understand 'wrap-through'?
  999. # [23:14] <fantasai> Rossen draws a diagram:
  1000. # [23:14] <fantasai> circle marked CB at the top
  1001. # [23:14] <fantasai> triangle extending down from it
  1002. # [23:14] <fantasai> a squiggly line extending from the circl down to a small circle inside the diagram
  1003. # [23:14] <fantasai> which then connects to the left corner of the big triangle and the middle of its base
  1004. # [23:14] <fantasai> this part is shaded
  1005. # [23:15] <fantasai> a thing on the base line on the non-shaded part points back up to the CB circl
  1006. # [23:15] * Parts: mouse (5e080aef@207.192.75.252)
  1007. # [23:15] <fantasai> Rossen: wrap-through opts out of the wrapping. It's an opt-out model rather than an opt-in model.
  1008. # [23:15] <fantasai> howcome: How common is this?
  1009. # [23:15] <fantasai> howcome: If you have an exclusion, can't it just be an exclusion?
  1010. # [23:16] <fantasai> Rossen: We did have use cases for this
  1011. # [23:16] <fantasai> Bert: Say you have in that tree you draw there, the small black thing that's abspos, it pushes everything else aside.
  1012. # [23:16] <fantasai> Bert: It has wrap-flow something.
  1013. # [23:16] <fantasai> Bert: When you say wrap-trhough on the other circle, then you set wrap-flow on it.
  1014. # [23:17] <fantasai> Rossen: Then you have multiple exclusions
  1015. # [23:17] * Joins: dino (dino@63.145.238.4)
  1016. # [23:17] <fantasai> Alan: There was a bunch of discussion about overlapping and combining exlcusion shapes and having portions be affected by this exclusion shape and not that one, to build up more complicated layouts that have that feature that was requested.
  1017. # [23:17] <fantasai> dbaron: wrap-trhough is an attempt to do that?
  1018. # [23:17] <fantasai> Alan: You don't do it by itself, you use it with other exclusion shapes, to chose which ones you'd be affected by
  1019. # [23:18] <fantasai> Alex: ... my content doesn't wrap to anything, so the exlusions overlap but hte content flows around
  1020. # [23:18] <fantasai> Bert: THe problem I see with wrap-through, if you have a floating element there, you still want to wrap around that floating element
  1021. # [23:18] <fantasai> vhardy: Your question is if I have a float before here *draws a circle before the small circle*
  1022. # [23:19] <fantasai> vhardy: Is that float still affecting wrpaping
  1023. # [23:19] <fantasai> vhardy: In our model, we have just one wrapping context, and if you exclude them [...]
  1024. # [23:19] <fantasai> Rossen: We can scope the opt-out wrapping so that floats are not affected by it
  1025. # [23:19] <fantasai> Rossen: In otherwords, floats would still contribute as they do today
  1026. # [23:19] <fantasai> Bert: I'm still brainstorming here.
  1027. # [23:20] <fantasai> Bert: You might also on this subtree set a z-index at a high value. And then you'd be in front of the exclusion. That seems easier.
  1028. # [23:20] <fantasai> Alex: I think wrap-trhough needs a better name. I was confused for the longest time what it does.
  1029. # [23:20] <fantasai> Alex: The meaning of the property is "make this container avoid wrapping anything"
  1030. # [23:21] <fantasai> 'wrap-off'?
  1031. # [23:21] * fantasai thinks the name is fine
  1032. # [23:21] <fantasai> Rossen: wrap-through means stop the propagation of wrapping context
  1033. # [23:21] <fantasai> howcome: So it's the same as this thing I'm describing here. I'd like to have it for floats.
  1034. # [23:21] <fantasai> dbaron: What's the use case for floats?
  1035. # [23:22] <fantasai> dbaron: Why do you want this, and why do you want this here?
  1036. # [23:22] <vhardy> http://wiki.csswg.org/ideas/css3-exclusions-use-cases
  1037. # [23:23] <fantasai> Rossen shows UC2
  1038. # [23:23] <fantasai> Rossen: In this case we have 2 exclusions affecting each other as well as the context around them
  1039. # [23:24] <fantasai> *shows example of two columns of black text, wrapped around: a red circle of text in the center, which has a blue square text intersecting with it; none of the text overlaps*
  1040. # [23:24] * fantasai wants to know what happens when you increase the font size of that red circle
  1041. # [23:25] <fantasai> Rossen: One use case not in the wiki was to have for example tables, where data is really supposed to be prsented in some manner, if you want to pop out of exclusion so that the table's contents aren't affected by it
  1042. # [23:25] <fantasai> Rossen: There are layouts for which you don't want to have exclusions.
  1043. # [23:26] <fantasai> jdaggett: How does z-index affect this?
  1044. # [23:26] <fantasai> Rossen: thanks for moving us ahead
  1045. # [23:26] <fantasai> Rossen: So, once you have a wrapping context computed for an element, you have ca collection of many elements that want to be exclusions
  1046. # [23:26] <fantasai> Rossen: we need to compute their order
  1047. # [23:27] <fantasai> Rossen: By default the last item in the document will be on top of everything else
  1048. # [23:27] <fantasai> Rossen: Naturally we'd want everything else would be affected
  1049. # [23:27] <fantasai> Rossen: Ordering of exlcusions is done in painting order. And you can use z-index to reorder them
  1050. # [23:28] <fantasai> Rossen: Doing this work, at first it seemed kind of hard to wrap our heads around would z-index just work
  1051. # [23:28] <fantasai> Rossen: Interesting thing is that all of the sorting is doable just locally on that element
  1052. # [23:28] <fantasai> Rossen: You don't have to sort the entire document and figure out all of the stacking contexts in order to apply this, simply because the scope of exclusions is basically limited to the containing block
  1053. # [23:28] <fantasai> dbaron: But it covers all descendants too
  1054. # [23:28] <fantasai> dbaron: So it's not a local process. You still have to perform layout between each one.
  1055. # [23:29] <fantasai> Rossen: Not a local process. It is a two-pass layout
  1056. # [23:29] <fantasai> Rossen: in which you first lay out all of the descendants
  1057. # [23:29] <fantasai> Rossen: Not abpsos though
  1058. # [23:29] <fantasai> dbaron: Yes you do, because [...]
  1059. # [23:32] <fantasai> dbaron: because there might be an abpsos descendant that creates an exclusion, but that that abspos descendant's containing block is still a descendant of your current context, and your current context has another descendant after that also establishing an exclusion
  1060. # [23:32] <fantasai> Rossen: This second exclusion that you just discovered, its scope will be [...]
  1061. # [23:32] <fantasai> Rossen: So this exclusion cannot affect any of the sibling exclusions
  1062. # [23:32] <fantasai> dbaron: We have two abpsos containing blocks, one inside the other.
  1063. # [23:32] <fantasai> dbaron: You have an exclusion inside the first, that affects the size of it
  1064. # [23:32] <fantasai> Rossen: assume they're all abspos for simplicity
  1065. # [23:32] <fantasai> dbaron: That's one of the problems, the spec assumes that but allows for things that aren't
  1066. # [23:33] <fantasai> Rossen: Let's say that you ahve an abspos element that propagates up to this CB in the hierarchy
  1067. # [23:33] <fantasai> Rossen: These are both position absolute *dras siblings*
  1068. # [23:33] <fantasai> Rossen: And this one is also an exclusion (second one)
  1069. # [23:33] <fantasai> Rossen: When the two are to be laid out on the elvel of this containing block
  1070. # [23:33] <fantasai> Rossen: Your statement was that I also need to lay out everything inside the first abspos in rder to figure out the stacking context
  1071. # [23:34] <fantasai> dbaron: If you're doing this 2-pass thing, you just do 2 passes and get the wrong result.
  1072. # [23:34] <fantasai> Arron: The first pass finds the static position of everything.
  1073. # [23:34] <fantasai> dbaron: The static position will be wrong once you've done the second pass
  1074. # [23:34] <fantasai> dbaron: It's not just static position, it's anything that creates an exclusion that's not absoluely positioned
  1075. # [23:35] <fantasai> fantasai: Also if you position to the bottom, and your height depends on the contents.
  1076. # [23:35] <fantasai> Rossen: Oh yeah, this is a known issue.
  1077. # [23:35] <fantasai> dbaron: Fundamentally I think the absolute positioning model is the wrong thing to tie exclusions to. I'd rather connect them to the floats model.
  1078. # [23:35] <fantasai> Steve: But that gives the wrong answer
  1079. # [23:35] <fantasai> howcome: I think I support you (dbaron)
  1080. # [23:36] <fantasai> howcome: You've introduced a bunch of wrap propertis, but it doesn't affect floats, and I think it should do.
  1081. # [23:36] <fantasai> Steve: That's a separate question. Let's look at this and then see how it affects floats.
  1082. # [23:36] <fantasai> dbaron: One of the other problems with this, it sort of assumes you can apply it to things that aren't absolutely positioned.
  1083. # [23:37] <fantasai> dbaron: But if you do, that won't work well because it only affects things inside the parent
  1084. # [23:37] * fantasai didn't quite catch that
  1085. # [23:37] <fantasai> Rossen: If you want to have an exclusion which is part of the flow, say a centered float
  1086. # [23:37] <fantasai> Rossen: Today you have left float and right float, say you want a centered float.
  1087. # [23:37] <fantasai> howcome: You add float: center;
  1088. # [23:38] <fantasai> Rossen: That brings other problems. How do you interact with left and right floats?
  1089. # [23:38] <fantasai> Rossen: Right now we have left and right areas of the float which compete for space with text in the center. Now you have a region in between?
  1090. # [23:38] <fantasai> howcome: Don't you have that problem anyway?
  1091. # [23:38] <fantasai> howcome draws.
  1092. # [23:39] <fantasai> howcome: You have an exclusion here. Then you have a left float that doesn't fit. What happens?
  1093. # [23:39] <fantasai> howcome: Do you have a clear ?
  1094. # [23:39] <fantasai> howcome: By having a model that kindof interacts with floats and kindof interacts with abspos, you create all these problems in the wake
  1095. # [23:39] <fantasai> Steve: The current definition of float moves the float down until it will fit
  1096. # [23:40] <fantasai> Steve: The barrier just doesn't allow any text to appear there. So lines dont' break, but flow across it, and don't render inside it
  1097. # [23:40] <fantasai> howcome: Still sems like a viable option to me, don't see why it's not
  1098. # [23:41] <fantasai> Steve: don't have enough control over positioning
  1099. # [23:41] <fantasai> Steve: If you break it down, bunch of considerations about where things are
  1100. # [23:41] <fantasai> Steve: Takes abspos items and make them behave like floats
  1101. # [23:41] <fantasai> howcome: Why not extend floats?
  1102. # [23:41] <fantasai> Steve: Because I don't want them to move
  1103. # [23:41] <fantasai> Steve: Makes more sense to make abspos elements exclude
  1104. # [23:42] <fantasai> vhardy: A positioned float is kindof an oxymoron.
  1105. # [23:42] <fantasai> howcome: Want to explore doing it the float way
  1106. # [23:42] <fantasai> jj: that's what we've done
  1107. # [23:42] <fantasai> dbaron: Something Steve said I disagreed with
  1108. # [23:42] <fantasai> Tantek: The whole expand float vs new feature. THere are a couple methodologies to apply to think about.
  1109. # [23:43] * Quits: dino (dino@63.145.238.4) (Ping timeout)
  1110. # [23:43] <fantasai> Tantek: From author's perpsective, there's a transition period. How will this behave during the transition period?
  1111. # [23:43] * Joins: bradk_ (bradk@64.129.229.106)
  1112. # [23:43] <fantasai> Tantek: What's the fallback behavior?
  1113. # [23:43] <fantasai> Tantek: One way to explore this problem space is to consider that.
  1114. # [23:43] <fantasai> Tantek: Want to do this new exclusion thing, but not suck on these old browsers.
  1115. # [23:44] <fantasai> Tantek: Without using css-conditional, if you had two float values you can have a fallback value
  1116. # [23:44] <fantasai> Tantek: If you don't ahve a fallback, it will slow adoption.
  1117. # [23:44] <fantasai> Tantek: Other quesiton is, if new feature B is similar to old feature A. How complex is old feature A?
  1118. # [23:45] <fantasai> Tantek: If it took only a few years to do old feature A, then building on it for B make ssense.
  1119. # [23:45] <dbaron> q+ to respond to Steve's assertion that authors want it where they position it
  1120. # [23:45] <fantasai> Tantek: But if old feature A took years and years and years to get it right, then it's naive ot think new feature B can be completed quickly.
  1121. # [23:46] <fantasai> Steve: I'm wondering which of abpos and floats you think is simpler. :)
  1122. # [23:46] <fantasai> Rossen: We don't want to mess with positioning complexity of floats today. Don't want to produce yet another layer of complexity
  1123. # [23:46] <fantasai> Alex: I wanted this to CSS3 Floats module, and we should have one that includes new floats and page floats.
  1124. # [23:47] <fantasai> Alex: This spec is scoped in a way that when this new floats spec appears, it doesn't need to say anything new about exclusions.
  1125. # [23:47] <fantasai> Alex: This describes how objects with exclusions itneract with content and each other.
  1126. # [23:47] <fantasai> Alex: When we find smarter way to position floats, this should all apply.
  1127. # [23:47] <fantasai> Alex: Should be able to implement just this, and then get smarter floats.
  1128. # [23:47] <fantasai> Alex: Might be things here, like 2-pass algorithm, which is really about [...]
  1129. # [23:48] <fantasai> vhardy: One big difference with floats is that floats assume rectangular shapes, so margin collapsing [..]
  1130. # [23:48] <fantasai> fantasai: floats don't collapse margins with anything.
  1131. # [23:48] <fantasai> Steve: Point you made earlier with overlays. These are positioned. If they overlap, one takes chunk out of the other.
  1132. # [23:48] <fantasai> Steve: Simpler model, but gives you something you can't get with floats
  1133. # [23:49] <fantasai> Bert: I wonder how that example works.
  1134. # [23:49] <fantasai> Bert: The blue one is not in the flow of the containing block of the red one. The blue one has its own flow
  1135. # [23:49] <fantasai> Rossen: Wrapping context is that of the *containing block* of the exclusion.
  1136. # [23:49] <fantasai> Rossen: In this case they both hvae same containing block, so they're in the same wrapping context.
  1137. # [23:50] <fantasai> ...
  1138. # [23:50] <fantasai> howcome: So in this example, if the blue comes on top
  1139. # [23:51] <fantasai> Rossen: Then the red will wrap around it
  1140. # [23:52] <fantasai> ...
  1141. # [23:52] <fantasai> Tantek: Is the circle a fixed size? What happens to overflow?
  1142. # [23:52] * Joins: Liam (liam@128.30.52.169)
  1143. # [23:52] <fantasai> Rossen: haven't talked about shapes yet.
  1144. # [23:52] <fantasai> Rossen: All three elements here are exclusions, all in same containing block *shows example of three overlapping squares*
  1145. # [23:53] <fantasai> Tantek: How adaptive is this to different amounts of content?
  1146. # [23:53] <fantasai> Rossen: This one is done with overflow: hidden
  1147. # [23:53] <fantasai> howcome: If you have a newspaper article, and you want to highlight the quote, you want to make sure the full quote appears.
  1148. # [23:53] <fantasai> howcome: Your examples look good, but they cut off the text.
  1149. # [23:54] <fantasai> Tantek: So the request is to us econtent and grows it
  1150. # [23:54] <fantasai> Rossen: If the element is width or height auto, and you start excluding it, its size will change to accommodate the content.
  1151. # [23:55] <fantasai> Rossen: If the size is fixed, then it will overflow.
  1152. # [23:55] <fantasai> Tantek: I think the examples should show what designers will want, i.e. not clipping the content.
  1153. # [23:55] <fantasai> dbaron: I'd like to go back to the point Steve made about 11 minutes ago
  1154. # [23:55] * tantek wants to avoid more unintended cases of http://dev.w3.org/csswg/css3-ui/cssisawesome.png
  1155. # [23:55] <fantasai> dbaron: So, when we were talkinga bout differences btw floats and positioning, Steve made the assertion that authors want things where they've positioned it.
  1156. # [23:55] <fantasai> dbaron: but thinking back to the examples Adobe showed when we met at Mozilla in the spring
  1157. # [23:56] <fantasai> dbaron: I think in a bunch of those examples, you don't want that.
  1158. # [23:56] <fantasai> dbaron: You will wind up in many cases where you're overlapping where you don't want overlap
  1159. # [23:56] <fantasai> dbaron: For example, pull quotes in the middle of a page.
  1160. # [23:57] <fantasai> dbaron: You're fine if the author can look at the resulting page on all the devices on which it will appear, and make sure there aren't two pull-quotes on the same page
  1161. # [23:57] <fantasai> dbaron: But if you have different font sizes or different page sizes and you're doing a layout like that, you don't want two pull quotes that wind up on the same page to overlap each other.
  1162. # [23:57] <fantasai> dbaron++
  1163. # [23:57] <fantasai> Steve: I agree with your example. I don't think floats do a better job, though.
  1164. # [23:58] <fantasai> Steve: If I wind up with two pull-quotes, I might want to only show one of them
  1165. # [23:59] <fantasai> Rossen and howcome discuss how to position the pull-quote
  1166. # [23:59] <fantasai> howcome: I want to put a pull-quote between 1st and 2nd column, 30% down from the top
  1167. # [23:59] <fantasai> Rossen: How many columns?
  1168. # [23:59] <fantasai> howcome: Depends on width of the screen
  1169. # [23:59] <fantasai> Steve: that gets us more into grid-addressing issue
  1170. # [23:59] * Joins: dino (dino@63.145.238.4)
  1171. # Session Close: Mon Oct 31 00:00:00 2011

The end :)