/irc-logs / w3c / #css / 2008-10-19 / end

Options:

  1. # Session Start: Sun Oct 19 00:00:00 2008
  2. # Session Ident: #css
  3. # [00:07] * Quits: anne (annevk@81.253.28.193) (Connection reset by peer)
  4. # [09:12] * Joins: glazou (daniel@81.253.60.166)
  5. # [09:15] * Joins: plinss_ (plinss@81.253.60.106)
  6. # [09:17] * Joins: dbaron (dbaron@81.253.60.210)
  7. # [09:20] <glazou> http://wiki.csswg.org/planning/mandelieu-2008
  8. # [09:21] * Joins: Zakim (rrs-bridgg@128.30.52.30)
  9. # [09:21] * Joins: RRSAgent (rrs-loggee@128.30.52.30)
  10. # [09:21] <RRSAgent> logging to http://www.w3.org/2008/10/19-css-irc
  11. # [09:27] * Joins: anne (annevk@81.253.61.222)
  12. # [09:36] * Joins: sylvaing (sylvaing@81.253.60.202)
  13. # [09:39] * dbaron couldn't hear the observer's name
  14. # [09:40] * anne same here, and i was sitting next to him :/
  15. # [09:40] * Joins: jdaggett (jdaggett@81.253.60.209)
  16. # [09:41] <dbaron> ScribeNick: dbaron
  17. # [09:41] <dbaron> Scribe: David Baron
  18. # [09:41] <glazou> http://wiki.csswg.org/planning/mandelieu-2008
  19. # [09:41] <dbaron> Meeting: CSS Working Group Face-to-Face meeting
  20. # [09:41] <dbaron> Topic: Agenda
  21. # [09:42] <dbaron> Daniel: I just posted wiki URL. Request to discuss CSS2 system colors with another WG, probably tomorrow morning.
  22. # [09:42] <dbaron> Daniel: Who is attending conflicting meetings?
  23. # [09:42] <dbaron> Steve: I'm chairing another meeting on Tuesday.
  24. # [09:42] <dbaron> Anne: I have Web Apps Monday and Tuesday; I'll try to alternate, but both don't have an agenda yet.
  25. # [09:43] <dbaron> Daniel: To those who won't be here Monday/Tuesday, anything you want discussed today?
  26. # [09:43] <dbaron> Anne: I want to attend the cross-WG one listed at the bottom of the page ("User control over UI").
  27. # [09:43] <dbaron> Anne: "Special behavior of BODY" we could do, but it should be trivial.
  28. # [09:44] <dbaron> Steve: My preference is that things like syntax and selectors occur on Tuesday.
  29. # [09:44] <dbaron> Elika: Melinda wants paged media on Tuesday.
  30. # [09:45] <dbaron> Steve: Although I'd prefer paged media not on Tuesday.
  31. # [09:46] <dbaron> Anne: Dean Jackson wanted to discuss Apple proposals... he's not here now.
  32. # [09:46] <dbaron> Daniel: maybe Monday
  33. # [09:47] <dbaron> Anne: We'd like it as well, and Mozilla has implemented parts of it.
  34. # [09:48] <dbaron> Daniel: <goes rapidly over list of topics>
  35. # [09:48] <dbaron> Daniel: While everybody is here, we should probably discuss 2 things: (1) next f2f meetings
  36. # [09:48] <fantasai> Topic: F2Fs next year
  37. # [09:49] <dbaron> Peter: I'd like 4 2-day meetings.
  38. # [09:49] <dbaron> Elika: ...
  39. # [09:49] <dbaron> Steve: I think 3 3-day is more practical... especially given travel budgets.
  40. # [09:49] <fantasai> Elika: That's tough for people travelling from far away
  41. # [09:49] <dbaron> Daniel: What time of year?
  42. # [09:49] * Joins: alexmog (alexmog@81.253.60.150)
  43. # [09:50] <fantasai> Elika: It takes a couple days just to adjust to the new time zone
  44. # [09:50] <fantasai> David: One issue we've had the past few years is that we've put the summer meeting late in the summer and thus very close to the fall meeting
  45. # [09:50] <dbaron> Daniel: We could do February, June, November...
  46. # [09:51] <dbaron> John: Can't confirm for sure, but could do one in Tokyo.
  47. # [09:54] <dbaron> (February)
  48. # [09:54] <dbaron> ?: Sophia-Antipolis in June?
  49. # [09:54] <dbaron> Bert: My holidays are first half of June.
  50. # [09:55] <dbaron> RRSAgent, make logs public
  51. # [09:55] <RRSAgent> I have made the request, dbaron
  52. # [09:55] <dbaron> Daniel: And TPAC in October/November.
  53. # [09:56] * Quits: sylvaing (sylvaing@81.253.60.202) (Quit: sylvaing)
  54. # [09:56] * Joins: sylvaing (sylvaing@81.253.60.202)
  55. # [09:56] <dbaron> Daniel: Either Boston or Santa Clara.
  56. # [09:57] <dbaron> Daniel: Let us know about days that are bad in Feb/Mar and late June.
  57. # [09:57] <dbaron> Elika: I can't do second half of March.
  58. # [09:58] <dbaron> Steve: Week of President's Day (US) can be a good week.
  59. # [09:58] * Quits: sylvaing (sylvaing@81.253.60.202) (Quit: sylvaing)
  60. # [09:59] <dbaron> Daniel: I think Haakon may have offered to host in Oslo...
  61. # [10:00] <dbaron> Daniel: Tentative plan is Tokyo in Feb/Mar, Sophia-Antipolis in June, TPAC in US in Oct/Nov.
  62. # [10:00] * Joins: sylvaing (sylvaing@81.253.60.202)
  63. # [10:01] <fantasai> Daniel needs to check school vacation calendar, prefers to be home 25th of Feb
  64. # [10:01] <dbaron> Daniel: I'd like to be home 25 Feb.
  65. # [10:01] <fantasai> Anne: No constraints
  66. # [10:01] <fantasai> Bert: First 2 weeks of June
  67. # [10:01] <fantasai> Bert: can't do
  68. # [10:02] <fantasai> Steve: June is difficult, but I can probably work around it
  69. # [10:02] <fantasai> Daniel: I prefer after March 2nd
  70. # [10:03] <fantasai> Alex: MSFT March 18-20 not a good time
  71. # [10:03] <fantasai> David: I have a weak preference for avoiding US Government holidays
  72. # [10:04] <fantasai> Peter: no constraints
  73. # [10:04] <fantasai> John: no constraints
  74. # [10:04] <fantasai> Elika: Not second half of March
  75. # [10:04] <fantasai> Alex: Also SxSW is March 13-22
  76. # [10:06] <fantasai> Discussing dates in June
  77. # [10:07] <fantasai> Steve prefers week of 22n-26
  78. # [10:08] <fantasai> Bert is returning on the 23rd
  79. # [10:10] <fantasai> Elika: I can't do May 29-June1
  80. # [10:11] <fantasai> Daniel: So, target 24-25-26 June 2009
  81. # [10:12] <fantasai> Daniel: Target for 1st meeting, 2 first weeks of March
  82. # [10:12] <fantasai> ACTION: glazou email w3c-css-wg with proposed dates and ask for comments/constraints
  83. # [10:12] * trackbot noticed an ACTION. Trying to create it.
  84. # [10:12] * RRSAgent records action 1
  85. # [10:12] <trackbot> Created ACTION-113 - Email w3c-css-wg with proposed dates and ask for comments/constraints [on Daniel Glazman - due 2008-10-26].
  86. # [10:13] <dbaron> Topic: Keeping web designers involved as invited experts
  87. # [10:13] <fantasai> Topic: Web Designers as Invited Experts
  88. # [10:13] <fantasai> Daniel: Jason Cranford Teague has left the WG
  89. # [10:13] <fantasai> Daniel: Since his perpsective is exteremely valuable, we wanted to propose to keep him as an Invited Expert to the WG
  90. # [10:14] <fantasai> Daniel: This raises an issue because AOL is the kind of company that could join the WG, but they are leaving the WG
  91. # [10:14] <fantasai> Daniel: Jason was never really representing AOL as much as himself and the web designers, so I think it makes sense
  92. # [10:14] <fantasai> Daniel: I understand from a W3C Process point of view it's difficult, but we really need web designers
  93. # [10:15] <fantasai> Steve: I would support that. I agree that Jason's contributions are from the perspective of a designer, but I think the precedent it establishes in W3C is potentially dangerous
  94. # [10:15] <fantasai> John: People who are very hard are people who are technically oriented, but ...
  95. # [10:16] <fantasai> John: A lot of issues break down to implementation issues, there has to be a balance between making an implementation consistent etc. and what will make it useful and easy for designers
  96. # [10:16] <fantasai> Daniel: That's a difficulty in this WG. A trivial proposal, a one-liner, can be extremely difficult to implement and most web designers don't understand that
  97. # [10:16] <fantasai> Daniel: Jason says he has time
  98. # [10:17] <fantasai> Bert: Has to pass Morrow and W3CM. He's clearly an AOL employee
  99. # [10:17] <fantasai> Bert and Steve want him here, but are concerned about process stuff
  100. # [10:17] <glazou> Mauro
  101. # [10:17] <dbaron> s/Morrow/Mauro/
  102. # [10:18] <dbaron> Elika: Other people?
  103. # [10:18] <dbaron> Daniel: We already had this discussion... remember failure of CSS 11?
  104. # [10:19] * Joins: MoZ (chatzilla@80.125.173.55)
  105. # [10:21] <fantasai> Daniel: ... strictly speaking, it is difficult to make Jason an official Invited Expert
  106. # [10:21] <fantasai> Daniel: but almost everything we do here is public, so he can still contribute
  107. # [10:21] <fantasai> Steve: We have to be careful about IPR
  108. # [10:24] <dbaron> (various discussion)
  109. # [10:26] <fantasai> Topic: Margin Collapsing
  110. # [10:26] <fantasai> Bert: Was wondering about margin collapsing in vertical
  111. # [10:26] <fantasai> Bert: If you have a vertical block inside a horizontal one
  112. # [10:27] <fantasai> Alex: That's a yes-or-no question. In our implementation they do collapse
  113. # [10:27] <fantasai> David: You'd be making a new block formatting context
  114. # [10:27] <dbaron> (break)
  115. # [10:29] <fantasai> RESOLVED: make a new block formatting context when block direction switches, margins outside the bfc do collapse
  116. # [10:35] * Quits: MoZ (chatzilla@80.125.173.55) (Ping timeout)
  117. # [10:43] * Joins: MoZ (chatzilla@81.253.3.138)
  118. # [10:45] * Quits: sylvaing (sylvaing@81.253.60.202) (Quit: sylvaing)
  119. # [11:03] <dbaron> Topic: Special behavior of BODY
  120. # [11:04] <dbaron> Daniel: Proposal by Simon Pieters is to make the body element in XHTML magic just like in HTML.
  121. # [11:06] * Joins: mib_apftg8 (c0960ac8@67.207.141.120)
  122. # [11:07] <dbaron> Anne: Was partly implemented per spec, marked at risk, implementations shifted back.
  123. # [11:07] * Quits: mib_apftg8 (c0960ac8@67.207.141.120) (Quit: http://www.mibbit.com ajax IRC Client)
  124. # [11:07] <fantasai> David: Originally everyone did what simon is proposing
  125. # [11:07] <fantasai> David: Then the XHTML WG asked us to make this change, and some browsers followed
  126. # [11:07] <fantasai> David: There are two different quirks. One for background, one for overflow
  127. # [11:07] <fantasai> David: I think Mozilla followed both briefly
  128. # [11:07] <fantasai> David: Webkit followed one but not the other
  129. # [11:07] * Joins: sylvaing (sylvaing@81.253.6.77)
  130. # [11:08] <fantasai> David: So we didn't have two implementations of both
  131. # [11:08] * Joins: SteveZ (c0960ac8@67.207.141.120)
  132. # [11:08] <fantasai> David: so we marked it at risk
  133. # [11:08] <fantasai> David: Mozilla, Opera, and Webkit currently treat HTML body and XHTML body the same way
  134. # [11:08] <fantasai> David: And simon has a test suite for this quirk stuff
  135. # [11:09] <dbaron> Elika: Can we get these tests in the 2.1 test suite?
  136. # [11:09] <fantasai> Elika: Anne, make sure they're in the right format and check them into svn?
  137. # [11:10] <dbaron> David: HTML5 spec wants HTML and XHTML to be treated the same; don't know that it's been discussed in WG.
  138. # [11:11] <dbaron> Alex: We don't do XHTML yet; would be easiest to not do anything special for XHTML.
  139. # [11:11] <dbaron> Daniel: That sounds like a consensus?
  140. # [11:11] <dbaron> Bert: I'd rather do the other way around, but...
  141. # [11:11] <dbaron> Bert: I think it's ugly but it doesn't break anything.
  142. # [11:11] <dbaron> Daniel: And it helps people who want to convert a Web page from HTML4 to XHTML.
  143. # [11:12] <dbaron> Bert: But harder to convert to Docbook or other things.
  144. # [11:12] <dbaron> Bert: I don't like it, but I don't think it's dangerous, just ugly.
  145. # [11:12] <dbaron> Peter: I'd almost like to see a way of declaring in CSS that element N should have this behavior.
  146. # [11:12] <dbaron> Anne: Seems too obscure to complicate the language.
  147. # [11:13] <dbaron> Elika: Seems like a quirk that we just have to deal with for HTML.
  148. # [11:13] <dbaron> Elika: It's there because of backwards-compatibility, not because it's useful.
  149. # [11:14] <dbaron> Bert: But what happens if people create new formats that reuse parts of HTML?
  150. # [11:14] <dbaron> Anne: If it's in the HTML namespace, then it will have the same special behavior.
  151. # [11:14] <dbaron> Anne: ... if it meets all the requirements of being a body (second child of HTML element, or something...).
  152. # [11:15] <dbaron> Daniel: The BODY is mandatory; you can't remove it.
  153. # [11:15] <dbaron> David: You can remove it through the DOM.
  154. # [11:17] <dbaron> (discussion)
  155. # [11:17] <dbaron> David: We don't want to get into the discussion of what an HTML document is for the DOM.
  156. # [11:18] <dbaron> Steve: If it's invalid, then interoperability is irrelevant.
  157. # [11:18] <dbaron> Anne: You're confusing authoring requirements and user-agent requiremnets.
  158. # [11:20] <dbaron> (discussion of HTML and DOM issues)
  159. # [11:21] <dbaron> s/requiremnets/requirements/
  160. # [11:26] <dbaron> Alex: Any concern about describing behavior of invalid documents?
  161. # [11:26] <dbaron> Anne: Not at all unusual... e.g., style sheets missing closing }
  162. # [11:27] <dbaron> Daniel: I abstain (no objection).
  163. # [11:27] <dbaron> Anne, Elika, David, Alex: in favor
  164. # [11:28] <dbaron> Anne: We should separate user-agent requirements and authoring requirements.
  165. # [11:28] <dbaron> (in response to comment by Alex)
  166. # [11:28] <dbaron> Daniel: ok, resolved.
  167. # [11:29] <anne> http://www.w3.org/Style/css2-updates/issues-4-20061106.html#issue-31
  168. # [11:29] <dbaron> RESOLVED: accept proposal in http://www.w3.org/Style/css2-updates/issues-4-20061106.html#issue-31
  169. # [11:32] <dbaron> http://lists.w3.org/Archives/Public/www-style/2007Mar/0035.html
  170. # [11:33] * Zakim excuses himself; his presence no longer seems to be needed
  171. # [11:33] * Parts: Zakim (rrs-bridgg@128.30.52.30)
  172. # [11:34] <fantasai> http://wiki.csswg.org/spec/css2.1#issue-80
  173. # [11:34] <dbaron> (Were we accepting the 17.5 changes as well?)
  174. # [11:36] <fantasai> http://wiki.csswg.org/spec/css2.1#issue-79
  175. # [11:37] <dbaron> RESOLVED: accept proposal in http://www.w3.org/Style/css2-updates/issues-4-20061106.html#issue-31 (chapters 11 and 14 parts)
  176. # [11:37] <dbaron> Topic: Margin collapsing (issue 79)
  177. # [11:38] <dbaron> Alex: When min-height has an effect, it prevents the bottom margin of the element from collapsing with the bottom margin of its last child.
  178. # [11:38] <dbaron> Alex: What exactly does this mean?
  179. # [11:39] <dbaron> Alex: Does it mean that the element's height is exactly the min-height, or bigger?
  180. # [11:39] <fantasai> ScribeNick: fantasai
  181. # [11:39] <fantasai> Alex draws a blue rectangle.
  182. # [11:39] <fantasai> Alex: Here we have a parent with some margin, and it has a child with some other margin
  183. # [11:39] <fantasai> Alex draws a short margin below the blue box
  184. # [11:40] <fantasai> Alex draws a red box inside the blue box, with a large margin that extends outside the box
  185. # [11:41] <fantasai> Alex: If the height was not specified, the parent would be as big as its child, and their margins would collapse, and the box after it (Alex draws a green box below the margin)
  186. # [11:41] <fantasai> would be after the collapsed margin.
  187. # [11:41] <fantasai> Alex: What's going to happen if we add a min-height that is bigger than the natural height?
  188. # [11:41] <fantasai> Alex: The parent box would grow
  189. # [11:41] <fantasai> Alex: but the margins no longer collapse
  190. # [11:41] <fantasai> s/margins/bottom margins/
  191. # [11:42] <fantasai> Alex: What happens to the margins?
  192. # [11:42] <fantasai> Alex: We have two options
  193. # [11:42] <fantasai> Alex: We treat the min-height as height,
  194. # [11:42] <fantasai> Alex: which causes us to ignore the bottom margin of the child
  195. # [11:42] <fantasai> Alex: which means the effective margin is much smaller than before, and the green box moves higher
  196. # [11:43] <fantasai> Alex: the other option is for the child's margin to be included in the parent's content box
  197. # [11:43] <fantasai> Alex: so the parent box grows bigger than the min-height in order to contain the margin
  198. # [11:44] <fantasai> Alex: and this is another interpretation of not collapsing the margins
  199. # [11:44] <fantasai> Alex: I have two options here. I could go with Firefox's behavior (the former) which is the easiest to implement
  200. # [11:44] <fantasai> Alex: Other option is to do the second option, which requires redoing size computation
  201. # [11:45] <fantasai> David: You'd have a discontinuity
  202. # [11:45] <fantasai> Elika: You have one in both cases
  203. # [11:45] <dbaron> http://dbaron.org/css/test/2008/min-height-margin-collapse
  204. # [11:45] <fantasai> Elika: In FF's case the green box jumps up once min-height takes effect
  205. # [11:46] <fantasai> We look at dbaron's testcase
  206. # [11:46] <fantasai> Alex: In this case it can become 200px or 400px
  207. # [11:47] <fantasai> Alex: That would be the difference between the different options
  208. # [11:47] <fantasai> Alex: Once the bottom margin doesn't collapse anymore, then you lose the distance between the bottom of this box and the next box
  209. # [11:47] <glazou> (observer is Hartmut Glaser from NIC.br)
  210. # [11:48] <fantasai> David: It seems to me that it should be 200px high but you should have a 200px margin as well
  211. # [11:49] <fantasai> Elika: That wouldn't make sense if the parent's min-height would contain its child including its margin
  212. # [11:50] <fantasai> Peter: What I don't want to see is the margin collapsing of the child change behavior based on whether the min-height is applying in this scenario...
  213. # [11:50] <fantasai> Peter actually said something about large margins appearing and disappearing mysteriously
  214. # [11:50] <fantasai> when you hit a discontinuity point
  215. # [11:51] <fantasai> ...
  216. # [11:52] <fantasai> David: In Oslo in 2003 we rewrote margin collapsing, and I didn't like that we introduced a discontinuity. We had a big discusison on how clearance, margin collapsing, and height computation
  217. # [11:52] <fantasai> interact
  218. # [11:53] <fantasai> Peter: If the height of an elemetn depends on the viewport width and resizing the window causes a giant margin to appear and disappear, nobody is going to be happy with that result
  219. # [11:54] <fantasai> Alex: So I think we should include the margin in the parent's height
  220. # [11:54] <fantasai> Steve: I realize the agreements reached in Oslo are very fragile, would doing what Alex says break those agreements?
  221. # [11:54] <fantasai> David: No
  222. # [11:55] <fantasai> Anne: So it seems all browsers are doing different things
  223. # [11:58] <fantasai> ....
  224. # [12:00] <fantasai> Alex: we could do Opera's solution (collapse the bottom borders even in the presence of min-height)
  225. # [12:00] <fantasai> Elika: That would not make sense if the min-height is big enough to contain the margin
  226. # [12:01] <fantasai> Alex: but its behavior is continuous
  227. # [12:01] <fantasai> Discussion about what is intuitive
  228. # [12:01] <fantasai> Steve: It really bothers me that we don't have any designers here
  229. # [12:02] <fantasai> Steve: At least Alex's proposal is consistent with what happens when margin collapsing is turned off elsewhere
  230. # [12:03] <fantasai> David: I think from a designer's pov parent-child margin collapsign was a mistake
  231. # [12:03] <fantasai> Peter: There are cases where it makes esnes from a designer's pov
  232. # [12:04] <fantasai> Peter: what doesn't make sense is the margin collapsing turning on and off for inexplicable reasons
  233. # [12:05] <fantasai> ...
  234. # [12:05] <fantasai> Peter: The margin of a box should not begin somewhere far below the box, it should always be attached
  235. # [12:05] <fantasai> Elika: You're asking for partial collapsing
  236. # [12:06] <fantasai> David: THat's what we decided never to do in Oslo
  237. # [12:06] <fantasai> ...
  238. # [12:06] <fantasai> Alex: Let's suppose the next element has a top margin of 300px, what will that margin collapse with?
  239. # [12:07] <fantasai> Steve: It shouldn't make any difference, it will collapse with the collapsed result of what we get here
  240. # [12:08] <fantasai> Steve tries to explain the margin collapsing model
  241. # [12:10] <fantasai> Bert: What about when we introduce vertical-alignment?
  242. # [12:10] <fantasai> Elika: We decided that that would create a new block formatting context, then you wouldn't collapse the parent and child margins
  243. # [12:11] <fantasai> Alex: ... partial collapsing
  244. # [12:11] <glazou> (sorry for the phone call, it's was my plumber, and no his name is NOT Joe :-)
  245. # [12:12] <fantasai> Bert: That was the original intention, that you take the lowest of the bottom of the relevant margins
  246. # [12:12] <fantasai> Anne: Is it really worth making margin collapsing that much more complicated?
  247. # [12:14] <fantasai> discussion of usage of margins
  248. # [12:15] <fantasai> Margin collapsing is designed not for layout, but for when you have a continuous flow of content: headings, paragraphs, etc
  249. # [12:15] <fantasai> Elika; We have several options here, let's list them
  250. # [12:15] <fantasai> A. Firefox's behavior, which to truncate to min-height
  251. # [12:15] <fantasai> and ignore the child margin
  252. # [12:16] <fantasai> B. Alex' 1st proposal, which is to growt include the child and min-height
  253. # [12:16] <fantasai> C. Opera behavior: collapse margins, then apply min-height
  254. # [12:16] <fantasai> D. Define partial collapsing
  255. # [12:18] <fantasai> David: I don't think it's really partial collapsing that you want to define, it's putting the edge of an element in the middle of a margin collapse
  256. # [12:18] <fantasai> David: But that's really a huge change at this point
  257. # [12:18] <fantasai> Steve: Are there other cases where this happens?
  258. # [12:18] <fantasai> David, Bert: THere are other cases with clear where something like this happens.
  259. # [12:18] <fantasai> David: THe concept of clearance was created in the discussion I'm talking about
  260. # [12:19] <fantasai> David: Before 2003 clearance didn't exist, clear just added a margin which then collapsed
  261. # [12:19] <dbaron> It's not really partial collapsing -- it's making the top/bottom edge of an element be in the middle of its margin
  262. # [12:19] <dbaron> but that's what we decided to avoid in 2003.
  263. # [12:20] <fantasai> Alex: but floats...
  264. # [12:20] <fantasai> David: We ended up saying that the position of a float can be in one of these places
  265. # [12:20] <dbaron> To be clear, I really don't want to change the big stuff (i.e., go with (D)) at this point.
  266. # [12:21] <fantasai> Elika: Do we have consensus on eliminating D?
  267. # [12:21] <fantasai> Steve: No, because that's what would make the most sense from a designer's perspective
  268. # [12:22] <fantasai> Alex: Min-height is as currently specified has a side-effect on margin collapsing that is not intuitive to the designer
  269. # [12:22] <fantasai> Steve: I'm trying to think of reasons why a designer would set min-height
  270. # [12:22] <fantasai> Alex: Let's try to come up with examples
  271. # [12:23] <fantasai> Alex: maybe I have business cards, and I set min-width min-height to 2/3
  272. # [12:23] <fantasai> Alex: so if someone's card has more info at least it shows
  273. # [12:23] <fantasai> Steve: in that case I wouldn't want the child margins to spill outside the box
  274. # [12:24] <fantasai> Alex: Say I have a series of paragraphs and a div around some of them
  275. # [12:25] <fantasai> Alex: Don't want setting min-height to make the margins between the apragraphs to disappear
  276. # [12:25] <dbaron> E. Say min-height != 0 always prevents collapsing.
  277. # [12:26] <fantasai> Daniel: I use min-height all the time.
  278. # [12:27] <fantasai> Daniel: I have a <pre>, and I want a minimum height for my code box
  279. # [12:27] <dbaron> Designers aren't really using min-height in the wild because of IE support, I think.
  280. # [12:29] <fantasai> everybody has a different idea of what designers would want for min-height and margin collapsing
  281. # [12:29] <fantasai> fantasai posts to twitter and gives up trying to minute
  282. # [12:31] <fantasai> Discuss dbaron's option E
  283. # [12:31] <fantasai> Alex: That's what IE8 impelements, and I'm not convinced it's more intuitive
  284. # [12:31] <fantasai> Alex: Min-height normally doesn't have any effect when the min-height is very small
  285. # [12:33] * Quits: SteveZ (c0960ac8@67.207.141.120) (Quit: http://www.mibbit.com ajax IRC Client)
  286. # [12:33] <fantasai> David: Using min-height along with an auto height has two uses
  287. # [12:34] <fantasai> David: You're sayin to use the maximum of the content height and the given min-height
  288. # [12:34] <fantasai> David: We dont' know which is going to be the normal case, it's different fro different uses
  289. # [12:34] <anne> (in the case where you really want to use the margin of the parent you just use parent > :last-child { margin-bottom:0 } )
  290. # [12:34] <fantasai> in some cases your base case using the content height, and the min-height is an exception
  291. # [12:35] <fantasai> and in other cases your base case is the min-height, and the content height is the exception (for when there's too much content)
  292. # [12:35] <fantasai> fantasai thinks that david baron's point here is really important!!!
  293. # [12:40] <dbaron> So one other question is whether we want there to be differences between "height: auto; min-height: 200px" and "min-height: min-content; height: 200px"
  294. # [12:45] <fantasai> Steve: We remove the line that says min-height turns margin collapsing off.
  295. # [12:45] <fantasai> Steve: Then we still have the question of how margin collapsing behaves when it's on and min-height has an effect
  296. # [12:46] <fantasai> RESOLVED: min-height does not turn off margin collapsing
  297. # [12:47] <fantasai> fantasai is skeptical and reserves judgement
  298. # [12:48] * Quits: plinss_ (plinss@81.253.60.106) (Quit: plinss_)
  299. # [12:48] * Quits: jdaggett (jdaggett@81.253.60.209) (Quit: jdaggett)
  300. # [12:48] <fantasai> LUNCH
  301. # [12:48] * Quits: sylvaing (sylvaing@81.253.6.77) (Quit: sylvaing)
  302. # [12:49] * Quits: dbaron (dbaron@81.253.60.210) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  303. # [12:50] * Quits: glazou (daniel@81.253.60.166) (Ping timeout)
  304. # [12:51] * Quits: MoZ (chatzilla@81.253.3.138) (Ping timeout)
  305. # [13:52] * Joins: jdaggett (jdaggett@81.253.18.52)
  306. # [13:59] * Joins: MoZ (chatzilla@81.253.18.31)
  307. # [14:04] * Joins: shepazu (schepers@128.30.52.30)
  308. # [14:06] <jdaggett> shepazu: http://wiki.csswg.org/planning/mandelieu-2008
  309. # [14:08] <shepazu> thanks, jdaggett
  310. # [14:09] * Joins: plinss_ (plinss@81.253.19.37)
  311. # [14:11] * Joins: glazou (daniel@81.253.19.75)
  312. # [14:13] * Joins: sylvaing (sylvaing@81.253.19.77)
  313. # [14:15] * Joins: SteveZ (51fd1277@67.207.141.120)
  314. # [14:17] <SteveZ> This is a test
  315. # [14:17] <fantasai> ScribeNick: SteveZ
  316. # [14:17] * Joins: dbaron (dbaron@81.253.18.37)
  317. # [14:18] <SteveZ> Issue: CSS2.1 issue 60 - Z index
  318. # [14:18] * trackbot noticed an ISSUE. Trying to create it.
  319. # [14:18] <trackbot> Created ISSUE-68 - CSS2.1 issue 60 - Z index ; please complete additional details at http://www.w3.org/Style/CSS/Tracker/issues/68/edit .
  320. # [14:18] <fantasai> Elika: Issue #60 is that Appendix E conflicts with chapter 9 in the CSS2.1 text
  321. # [14:20] <fantasai> http://dev.moonhenge.net/css21/spec/z-index/
  322. # [14:21] <SteveZ> Start with 2.1. Stacking context–like behaviour
  323. # [14:21] <dbaron> s/Issue:/Topic:/
  324. # [14:26] <SteveZ> This topic is postponed until tomorrow
  325. # [14:26] <SteveZ> so that Hixie can participate
  326. # [14:27] <SteveZ> Topic: Value pseudo attribute
  327. # [14:29] <SteveZ> DB: this came out of discussion on WhatWG list
  328. # [14:29] <SteveZ> DB: there was a proposal to have text (specially identified) that can be typed over
  329. # [14:30] <SteveZ> DB: Styling should specify how that text is specially identified
  330. # [14:30] <SteveZ> DB: this is attribute like, but not actually an attribute
  331. # [14:30] <SteveZ> AvK: This is sort of like a DOM attribute
  332. # [14:31] <SteveZ> AvK: it seems to apply to placeholders
  333. # [14:31] <SteveZ> DB: you could combine it with the focus selector
  334. # [14:31] <fantasai> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-October/016544.html
  335. # [14:31] <anne> WebKit has implemented :-webkit-placeholder for this case. That works for focusing the input control as well and such.
  336. # [14:32] <dbaron> http://lists.w3.org/Archives/Public/www-style/2008Oct/0144.html
  337. # [14:32] <dbaron> but it would actually need input[:value=""]:not(:focus)
  338. # [14:32] <SteveZ> DG: I was wrong to complain that it would be difficult to internationalize because this applies only to the content of an attribute
  339. # [14:33] <SteveZ> AvK: When this facility (sample text) is added to HTML, then having a placeholder pseudo element would make sense
  340. # [14:36] <SteveZ> BB: I find that having the placeholder disappear when a partial selection is done disturbing; I want to be able to select the text and cut it and paste it
  341. # [14:36] <SteveZ> BB: the above point is really an HTML not a CSS point
  342. # [14:37] <fantasai> Topic: Selectors
  343. # [14:37] <SteveZ> Does the current Hover element apply to the parent if the child is outside of the display space of the parent
  344. # [14:38] <fantasai> http://www.w3.org/Style/CSS/Tracker/issues/65
  345. # [14:39] <anne> test
  346. # [14:39] <SteveZ> DG: e.g. a child element is relatively positioned outside its structural parent
  347. # [14:39] <anne> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0D%0A%3Cstyle%3E%20div%3Ahover%20%7B%20background%3Ayellow%20!important%20%7D%20%3C%2Fstyle%3E%0D%0A...%3Cdiv%20style%3Dheight%3A50px%3Bwidth%3A50px%3Bbackground%3Alime%3E%0D%0A%3Cdiv%20style%3Dheight%3A50px%3Bwidth%3A50px%3Bbackground%3Ared%3Bposition%3Aabsolute%3Btop%3A40px%3Bleft%3A100px%3E%3C%2Fdiv%3E%0D%0A%3C%2Fdiv%3E
  348. # [14:39] <anne> (that test tests the behavior)
  349. # [14:39] <anne> (being discussed)
  350. # [14:39] * Bert (About previous topic: If there is really no room to put the label next to the text box, then a compromise might be to put it inside, but in gray rather than black text. Safari's search box does that. Gray text looks less "selectable" than black text.)
  351. # [14:40] <SteveZ> DG: all browsers do selection of the parent
  352. # [14:41] <SteveZ> AM: I have an example where I show help text outside the button to which it applies and I want the hover to stay on if the cursor moves over the help text
  353. # [14:41] <SteveZ> AvK: There are other examples which depend on this behavior
  354. # [14:42] <SteveZ> DG: I want to be sure that the specification will make clear what a user should expect; in particular, that it is not just the physical position of the cursor that triggers hover behavior.
  355. # [14:43] <SteveZ> DG and EE: this probably needs a note in the spec
  356. # [14:43] <SteveZ> DB: you figure out which element would receive the event and that element and all its ancestors are in the hover state
  357. # [14:44] <SteveZ> DB: you have to keep compatibility with hovering over a link or any of its descendents will keep the link in the hover state
  358. # [14:46] <SteveZ> PL: we should define the hover processing in terms of event processing and accept that the specs that define event processing will say what elements are affected
  359. # [14:47] <SteveZ> DB: the behavior of events on hidden elements is not consistent across browsers
  360. # [14:47] <SteveZ> DB: SVG has a property called "pointer events" that may make sense to adopt at some point
  361. # [14:48] <SteveZ> DB: right now this is massively undefined in the selector spec; I would favor more specification as would PL
  362. # [14:49] <SteveZ> AvK: Say when the element is in "the hover state" (as defined by some spec) then the behavior is ....
  363. # [14:49] <SteveZ> DB and EE: but is there a spec that defines "the hover state"
  364. # [14:50] <SteveZ> DB: We can define things in terms of DOM level 2 events (a REC)
  365. # [14:51] <SteveZ> DB: we are leaving the hit testing definition to some other spec, but we can define the rest now
  366. # [14:52] <SteveZ> DB: why are we changing only hover and not "active"
  367. # [14:52] <SteveZ> EE: "active" is not well defined
  368. # [14:53] <SteveZ> EE: in IE an element remains active even after a click is released
  369. # [14:53] <SteveZ> AM: this works on the iPhone
  370. # [14:53] * Quits: jdaggett (jdaggett@81.253.18.52) (Quit: jdaggett)
  371. # [14:53] <SteveZ> PL: thie activity persists during a load, but not forever.
  372. # [14:54] <SteveZ> DB: does it matter that browsers have different behaviors for "active"
  373. # [14:54] <SteveZ> EE: the differences are so subtle that it is OK
  374. # [14:55] <SteveZ> DB: I am OK with differing when something begins being active and ends being active, but not with not saying whether the ancestors are active or not
  375. # [14:56] <SteveZ> EE: I would say that "active" does not propogate up; e.g. clicking on something (a span) inside an anchor makes only the span active
  376. # [14:56] <anne> data:text/xml,<html xmlns="http://www.w3.org/1999/xhtml"><style> a:active { background:lime }</style><a href="test">a<a href="test">b<a href="test">c</a></a></a></html>
  377. # [14:57] <SteveZ> AvK: active only applies to the element being activated is active, but in Mozilla and Webkit the ancestors are active as well
  378. # [14:58] <SteveZ> AvK: I thnk that in Firefox, nested links have some anomolies in behavior
  379. # [14:59] <SteveZ> EE: CSS does not define what elements get activated or for how long
  380. # [15:00] <fantasai> or what triggers the activation
  381. # [15:00] <SteveZ> DB: current spec says "while it is being activated" not "while it is active".
  382. # [15:00] <fantasai> EE: e.g. clicking on something (a span) inside an anchor makes only the *anchor* active (not the span)
  383. # [15:01] <fantasai> EE: and clicking on a triple-nested link should only apply :active to the link that's been activated
  384. # [15:01] <SteveZ> DB: not sure that this is something that should be defined differently in different specs
  385. # [15:02] <shepazu> SCXML and the SMIL State module define state (but I don't know if they are compatible with each other, much less what CSS would mean by "state")
  386. # [15:02] <SteveZ> DS: (Doug Schepers): there are two specs that define states: SMIL and an SVG spec
  387. # [15:02] <shepazu> s/SVG spec/MMI spec/
  388. # [15:02] <dbaron> ScribeNick: dbaron
  389. # [15:03] <dbaron> EE: So we want text for the :hover issue.
  390. # [15:03] <glazou> s/we/I
  391. # [15:03] <dbaron> EE: I'm ok with saying that the parent of an element that's :active is not necessarily :active, but that :hover is propagated to ancestors.
  392. # [15:04] <anne> data:text/xml testcase as link http://annevankesteren.nl/test/css/temp/003.xml
  393. # [15:05] <dbaron> BB: Leave it undefined for :active because we don't know what elements can be activated.
  394. # [15:06] <anne> So I said that Opera activates the innermost link, where Firefox activates the outermost
  395. # [15:06] <dbaron> DB: ?
  396. # [15:06] <dbaron> DG: The original issue was just this one clarification.
  397. # [15:06] <dbaron> DB: But it was a clarification about something that's explicitly undefined.
  398. # [15:06] <dbaron> ScribeNick: SteveZ
  399. # [15:06] <anne> And that what Opera does is currently specified in HTML5 and probably matches what IE does (you can test using submit buttons and links)
  400. # [15:06] <SteveZ> BB: if an ancestor has a hover selector does that block propogation?
  401. # [15:07] <SteveZ> PL: no, the existance of selectors is indpendent of event propogation
  402. # [15:08] <SteveZ> BB: if you have two ancestors with pop-ups on hover, you will get both unless the first one blocks propogation
  403. # [15:09] <fantasai> proposal: t
  404. # [15:09] <fantasai> If an element that is ':hover' causes its parent to
  405. # [15:09] <fantasai> be in ':hover', then it is possible for an element that is not underneath
  406. # [15:09] <fantasai> the pointing device is in ':hover'.
  407. # [15:10] <fantasai> If an element that is ':hover' causes its parent to
  408. # [15:10] <fantasai> be ':hover', then it is possible for an element that is not underneath
  409. # [15:10] <fantasai> the pointing device to be ':hover'.
  410. # [15:11] <glazou> if :hover applies to an element causes :hover apply to the parent element, then it's possible :hover applies to an element that is not underneath the pointing device
  411. # [15:14] <SteveZ> BB: the typical use case for "hover" is to indicate what can be activated so only the things that can be activated should be in hover; not all ancestors
  412. # [15:14] <fantasai> If it's possible for ':hover' to apply to an element because its
  413. # [15:14] <fantasai> child is designated by a pointing device, then it's possible for
  414. # [15:14] <fantasai> ':hover' to apply to an element that is not underneat the pointing
  415. # [15:14] <fantasai> device.
  416. # [15:14] <fantasai> If it's possible for ':hover' to apply to an element because its
  417. # [15:14] <fantasai> child is designated by a pointing device, then it's possible for
  418. # [15:14] <fantasai> ':hover' to apply to an element that is not underneat the pointing
  419. # [15:14] <fantasai> device.
  420. # [15:15] <SteveZ> DB: the WG did not resolve that hover was heirarchical but with IE8 all implementations seem to make it hierarchical
  421. # [15:16] <SteveZ> N.B. the above text by fantasai is intended as a NOTE
  422. # [15:16] * Quits: alexmog (alexmog@81.253.60.150) (Ping timeout)
  423. # [15:16] <fantasai> checked in
  424. # [15:16] <fantasai> RESOLVED: proposal above accepted
  425. # [15:17] <dbaron> http://dbaron.org/css/test/sec051103b is a testcase for hierarchical :hover
  426. # [15:17] <dbaron> (and :active)
  427. # [15:17] <SteveZ> Topic: Grammer for an+b for nth child
  428. # [15:21] <SteveZ> DG: although whether hover applies to ancestors is officially undefined; millions of websites would break if it were otherwise defined
  429. # [15:21] <shepazu> I'd just like to note that you could define "hovered" as being defined by the host language
  430. # [15:22] <glazou> http://www.w3.org/Style/CSS/Tracker/issues/66
  431. # [15:22] <shepazu> then it's out of the CSS's problem
  432. # [15:22] <shepazu> s/out of /not /
  433. # [15:24] <dbaron> You want the n, the even, and the odd to be written using the {n}, {o}, etc. productions from the grammar
  434. # [15:24] <SteveZ> EE: we had already resolved where white space is allowed: not between a unary operator and the integer to which it applies nor between the integer and the "n"
  435. # [15:25] <dbaron> and it would be nice to indent so the [] and () don't line up with the | because they look a lot like |
  436. # [15:25] <SteveZ> DB: the odd and even need to be case insensitive
  437. # [15:26] <SteveZ> DG: the 'n' is escapable, but not the "+" or "-"
  438. # [15:26] <dbaron> (since units are escapable, but sign is not... right?)
  439. # [15:27] <SteveZ> Resoved: the proposed grammer is accepted, with the modification to allow the 'n' is escapable.
  440. # [15:27] <fantasai> s/Resolved/RESOLVED/
  441. # [15:27] <SteveZ> Topic: ::selectors
  442. # [15:27] <dbaron> Ah, so we haven't had the pseudo-element argument for a few years, so we need to do it again...
  443. # [15:28] * Quits: anne (annevk@81.253.61.222) (Ping timeout)
  444. # [15:28] <fantasai> http://www.w3.org/Style/CSS/Tracker/issues/67
  445. # [15:30] <fantasai> ScribeNick: fantasai
  446. # [15:30] <fantasai> David: Pseudo-elements have this thing where their boundaries don't line up with the tree
  447. # [15:31] <fantasai> David: The question is do you split the <span> into 2 pieces, or do you split the pseudo-element into 2 pieces?
  448. # [15:31] <fantasai> David: The current spec says you split the pseudo-element
  449. # [15:31] <SteveZ> DB: pseudo elements have boundaries that do not necessarily match the boundaries of the mark-up; which is split: the pseudo element or the real element?
  450. # [15:31] <fantasai> Daniel: Can the pseudo-element contain more than pcdata and replaced elements?
  451. # [15:32] <fantasai> Peter: you could have a selection, for example in the example in 67
  452. # [15:32] <fantasai> Peter: you can't contain the children and still be well-formed
  453. # [15:32] * Joins: alexmog (alexmog@81.253.60.150)
  454. # [15:32] <dbaron> The question is: Does <span>A<pseudo>B</span>C</pseudo> give the tree <span>A<pseudo>B</pseudo></span><pseudo>C</pseudo> or <span>A</span><pseudo><span>B</span>C</pseudo>?
  455. # [15:33] <fantasai> Peter: the HTML5 spec might say something about this, wrt malformed markup
  456. # [15:33] <fantasai> Peter: In this scenario, what you get with the pseudo-element should always be describable as valid tree markup
  457. # [15:33] <fantasai> Daniel: It's describable as a DOM range
  458. # [15:33] <anne> ls
  459. # [15:34] <anne> sorry about that
  460. # [15:34] <fantasai> David: The problem is that many CSS properties, including inheritance, are defined in terms of a tree
  461. # [15:34] <fantasai> Daniel: Question remains, do I have multiple outlines for richtext::selection?
  462. # [15:35] <fantasai> ...
  463. # [15:35] <fantasai> David: What Mozilla actually implements now, I think, is something that sounds even more complicated than these two
  464. # [15:35] <fantasai> David: We do both
  465. # [15:35] <fantasai> David: We do one for the inherited properties and one for the non-inherited properties
  466. # [15:36] <SteveZ> DB: Mozilla implements that 3rd option: it treats the inherited and non-inherited properties
  467. # [15:36] <fantasai> Daniel: I wonder if we should just remove outline from the list of properties allowed?
  468. # [15:36] <SteveZ> differently
  469. # [15:37] <fantasai> David: I'm not even sure if that's quite what we do
  470. # [15:37] <anne> http://annevankesteren.nl/test/css/temp/004.xml
  471. # [15:37] <fantasai> Anne: Opera doesn't apply outline at all
  472. # [15:37] <SteveZ> BB: in David's solution "outline" is an outer thing so goes around the whole thing and "color" is an inner thing so it would be inside the markup elements
  473. # [15:42] <fantasai> Anne: It seems nobody implements outline
  474. # [15:45] <dbaron> Peter: What about p::selection { color: inherit } ?
  475. # [15:47] * Joins: mollydotcom (mollyholzs@70.176.234.187)
  476. # [15:48] <SteveZ> DB: Warning: at some point I may want to propose styling of multiple ranges
  477. # [15:48] <SteveZ> DB: "background" is non-inherited so its behavior would be the same as that for "outline"
  478. # [15:48] <dbaron> I think for ::selection it's important that the ::selection is innermost for the 'color'.
  479. # [15:50] <SteveZ> AvK: if there is a span::selecction it should apply; it does in Opera but not in Firefox
  480. # [15:51] <dbaron> With ::selection, do you ever get <p::selection><span::selection>sel</span::selection></p::selection>, or something else?
  481. # [15:51] <glazou> hey mollydotcom!!!!
  482. # [15:51] <mollydotcom> greetings all
  483. # [15:51] <dbaron> and how do global ::selection styles interact with that?
  484. # [15:52] <mollydotcom> catching up on the topic, having tea to wake up, be with you all in a bit
  485. # [15:52] <fantasai> David: Suppose you have a selection that includes an element that is 20 levels nested
  486. # [15:52] <dbaron> If you have a ::selection{} rule and your selection is in an element 20 levels nested within the tree, and your background color is rgba(255, 0, 0, 0.2), what happens?
  487. # [15:52] <dbaron> Do you have 20 pseudos?
  488. # [15:53] <fantasai> If you have p::selection and you set a color on it
  489. # [15:53] <fantasai> And you have a span inside the p, you want the selection inside the span to have the color you set on p::selection
  490. # [15:54] <fantasai> (that was dbaron, btw, not me)
  491. # [15:55] <fantasai> David: So this is not a tree-based approach. How do you deal with inheritance?
  492. # [15:55] <dbaron> p::selection { color: blue } span { color: purple; }
  493. # [15:55] * Quits: shepazu (schepers@128.30.52.30) (Ping timeout)
  494. # [15:55] <dbaron> <p>Text << text <span>span</span> text >> text.</p>
  495. # [15:55] <dbaron> we want the "span" to be blue rather than purple
  496. # [15:57] <dbaron> We definitely don't want to distinguish "in the selection" from "contains the selection" because it can be half and half.
  497. # [15:57] <dbaron> What about 'color: inherit' ?
  498. # [15:59] <fantasai> Peter points out that Daniel's concept of a global selection is incompatible with the idea of styling p::selection and span::selection differently
  499. # [16:00] <fantasai> Steve: A selection is a set of DOM ranges.
  500. # [16:00] <fantasai> Steve: That's the One Selection
  501. # [16:01] <fantasai> Steve: Then there's the issue of how to style it
  502. # [16:01] <fantasai> Steve: THe proposal is to style it as if the selection is not there
  503. # [16:01] <fantasai> Steve: Then go back and for the pieces that fall into the range, you restyle them
  504. # [16:01] <fantasai> Anne: That's not desired for the span case because then p::selection would not apply to the span nested inside the p
  505. # [16:04] <fantasai> David: I think it would help to have concrete examples
  506. # [16:04] <SteveZ> DG: I will come up with a list of requirements for what ::selection should and should not do
  507. # [16:05] <SteveZ> DG: one requirement is that we do not want nested outlines
  508. # [16:05] <SteveZ> DG: we want color to nest locally
  509. # [16:06] <SteveZ> ACTION: (DG) develop requirements for ::selection behavior
  510. # [16:06] * trackbot noticed an ACTION. Trying to create it.
  511. # [16:06] <trackbot> Sorry, couldn't find user - (DG)
  512. # [16:06] * RRSAgent records action 2
  513. # [16:07] <Bert> How about: insert <::selection> at the start, </::selection> before every tag, <::selection> after every tag, and </::selection> at the end: <p>...........<<<<::>.......</::></p><::> </::><p><::>......</::><span><::>......</::>>>>.......</span></p>
  514. # [16:07] <dbaron> http://dbaron.org/css/test/sec051103b is a testcase for hierarchical :hover
  515. # [16:07] <Bert> (and then think about 'outline' separately)
  516. # [16:07] <SteveZ> ACTION:glazou, develop requirements for ::selection behavior
  517. # [16:07] * RRSAgent records action 3
  518. # [16:15] <mollydotcom> I look at this and try to imagine designers having a clue. It isn't working.
  519. # [16:18] <mollydotcom> just bear in mind designers want very explicit control of every piece within a given selection
  520. # [16:20] * Quits: sylvaing (sylvaing@81.253.19.77) (Quit: sylvaing)
  521. # [16:33] <SteveZ> This is a test
  522. # [16:33] * Quits: SteveZ (51fd1277@67.207.141.120) (Quit: http://www.mibbit.com ajax IRC Client)
  523. # [16:34] * Joins: SteveZ (51fd1277@67.207.141.120)
  524. # [16:35] <SteveZ> WG resumes at 4:30PM
  525. # [16:36] <SteveZ> Topic: First line, First letter pseudoelements
  526. # [16:36] <glazou> http://lists.w3.org/Archives/Public/www-style/2006Jan/0209.html
  527. # [16:38] * Joins: sylvaing (sylvaing@81.253.29.40)
  528. # [16:38] * anne test!
  529. # [16:39] * Bert test received
  530. # [16:39] * Joins: anne (annevk@81.253.61.222)
  531. # [16:39] <glazou> http://lists.w3.org/Archives/Public/www-style/2006Jan/0091.html
  532. # [16:40] <fantasai> David: I think this is what we solved by doing the inherited/non-inherited properties split
  533. # [16:40] <fantasai> David: He put a display property on the :first-line and then display:inhert on a span in the first line
  534. # [16:40] <glazou> http://lists.w3.org/Archives/Public/www-style/2005Oct/0163.html
  535. # [16:40] <dbaron> http://lists.w3.org/Archives/Public/www-style/2005Oct/0163.html
  536. # [16:41] <fantasai> David: What we used to do on this test case was crash
  537. # [16:44] <fantasai> David looks up what exactly Mozilla does here
  538. # [16:47] <fantasai> David: If you have property: inherit; on an element that is inside the :first-line, then we don't inherit from the :first-line
  539. # [16:48] <fantasai> David: for non-inherited properties
  540. # [16:48] <fantasai> David: The effective change for this is only when the 'inherit' keyword is used on a non-inherited property
  541. # [16:49] <fantasai> David: That's a very uncommon case
  542. # [16:49] <fantasai> David: It's possible we want to change the behavior on more common cases
  543. # [16:49] <fantasai> David: like a tiled background image on ::first-line
  544. # [16:50] <fantasai> David reviews the spec
  545. # [16:50] <fantasai> David: no, that's should probably work...
  546. # [16:53] <fantasai> David: So how should we be changing the spec to try to address this?
  547. # [16:53] <SteveZ> DG: The current spec says that the span is split into two separate boxes
  548. # [16:53] <glazou> s/DG/DB ?
  549. # [16:54] <SteveZ> DG: How should the spec be changed to allow/require what Mozilla does?
  550. # [16:54] <fantasai> David: Do we want to say what Mozilla does with inheritance is allowed, or required, or it's undefined, or make another change
  551. # [16:54] <fantasai> Alex: IE does exactly what Mozilla does at this point.
  552. # [16:54] <SteveZ> AM: it appears that IE does what Mozilla does at this point
  553. # [16:54] <fantasai> Alex: inheritance comes not from the pseudo-class but from the actual parent
  554. # [16:54] <fantasai> David: but for an inherited property like color?
  555. # [16:55] <fantasai> Alex: doesn't inherit
  556. # [16:55] <SteveZ> s/DG/DB/
  557. # [16:56] <fantasai> David inspects Alex's testcase
  558. # [16:57] <Bert> (Is it the case that proeprties that don't apply to :first-line are also not inherited from :first-line? Or are only non-inherited properties not inherited?)
  559. # [16:57] <fantasai> only non-inherited properties are not inherited
  560. # [16:58] <SteveZ> DB: explicit inheritance of non-inherted properties ignores the firstline and firstchar properties in computed the inherited value
  561. # [17:00] <SteveZ> DB: inheritence of inherited properties do use the properties of firstline where relevant
  562. # [17:03] <SteveZ> EE: the split between non-inheritable properties do not inherit from the pseudo element properties and inheritable properties do inhert makes sense
  563. # [17:04] <SteveZ> AM: background and text decoration are safe to inherit
  564. # [17:04] <SteveZ> BB and DB: position and float are not safe to inherit
  565. # [17:05] <SteveZ> DB: if you set "whitespace: nowrap" this may change the firstline behavior (beyond just the inheritance question).
  566. # [17:06] <SteveZ> BB: The keyworld inherits from either the parent of the first line or the firstline; which should be used?
  567. # [17:07] <SteveZ> BB: one rule might be to inherit from the firstline if the property is applicable to the firstline and the parent otherwise.
  568. # [17:13] <SteveZ> suggested text: The portion of a child element that occurs on the first line inherits properties applicable to the firstline pseudo element; for properties not applicable to the firstline pseudo element, the inheritence is from the parent of the first line pseudo element
  569. # [17:15] <fantasai> s/parent/non-pseuo-element parent/
  570. # [17:16] <SteveZ> add: The portion of a child element that does not occur on the first line always inherits from the parent of that child.
  571. # [17:16] <fantasai> RESOLVED: proposal above accepted
  572. # [17:20] <SteveZ> DB: Firefox does not have the same rules for firstletter because firstletter is not layout based; it is only storage order based
  573. # [17:22] <SteveZ> Many: but, note that a quote followed by a character whose bidi order is opposite from the context in which the quote occurs may separate the quote and the following letter by the rest of the embedded bidi string
  574. # [17:25] * Joins: jdaggett (jdaggett@81.253.27.176)
  575. # [17:26] * Parts: sylvaing (sylvaing@81.253.29.40)
  576. # [17:26] <glazou> ======== ADJOURN FOR TODAY ===========
  577. # [17:28] * fantasai wants ideas for http://lists.w3.org/Archives/Public/www-style/2008Sep/0142.html yo
  578. # [17:28] <mollydotcom> Have some fun tonight for me . . . any good restaurants on the plan?
  579. # [17:28] <Bert> We were just discussing l'Ermitage du Riou...
  580. # [17:29] <mollydotcom> Bert: Yes, yes, didn't Peter say he had a little room on that HP credit card? ;)
  581. # [17:29] <mollydotcom> It's a wonderful restaurant
  582. # [17:30] * plinss_ conducted the credit card stress test last night :-)
  583. # [17:30] <mollydotcom> plinss_ and it's not even officially day one of TP/AC
  584. # [17:30] * plinss_ will have to wait for peer review before concluding it was a success
  585. # [17:30] <mollydotcom> you gotta be ready for the long haul
  586. # [17:30] <mollydotcom> hehe
  587. # [17:30] <mollydotcom> enjoy, enjoy. I will be vicariously enjoying through you
  588. # [17:31] <mollydotcom> and back as time zones permit
  589. # [17:31] * mollydotcom waves to all
  590. # [17:31] * fantasai waves
  591. # [17:31] * mollydotcom is now known as mollydotcom_afk
  592. # [17:31] * glazou waves back
  593. # [17:34] * Quits: glazou (daniel@81.253.19.75) (Ping timeout)
  594. # [17:35] * Quits: MoZ (chatzilla@81.253.18.31) (Ping timeout)
  595. # [17:41] * Quits: plinss_ (plinss@81.253.19.37) (Quit: plinss_)
  596. # [17:41] * Quits: alexmog (alexmog@81.253.60.150) (Quit: alexmog)
  597. # [17:43] * Quits: jdaggett (jdaggett@81.253.27.176) (Quit: jdaggett)
  598. # [18:01] * Quits: dbaron (dbaron@81.253.18.37) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  599. # [18:04] * Quits: SteveZ (51fd1277@67.207.141.120) (Quit: http://www.mibbit.com ajax IRC Client)
  600. # [18:06] * Quits: anne (annevk@81.253.61.222) (Ping timeout)
  601. # [18:42] * Quits: mollydotcom_afk (mollyholzs@70.176.234.187) (Quit: Quitting!)
  602. # [19:24] * Joins: myakura (myakura@122.29.60.226)
  603. # [19:36] * Quits: myakura (myakura@122.29.60.226) (Quit: Leaving...)
  604. # [22:37] * Quits: arronei (arronei@131.107.0.74) (Ping timeout)
  605. # [22:43] * Joins: arronei (arronei@131.107.0.73)
  606. # Session Close: Mon Oct 20 00:00:00 2008

The end :)