/irc-logs / w3c / #css / 2011-02-16 / end

Options:

  1. # Session Start: Wed Feb 16 00:00:00 2011
  2. # Session Ident: #css
  3. # [00:02] * Joins: homata (homata@58.158.182.50)
  4. # [00:18] * Quits: homata (homata@58.158.182.50) (Quit: Leaving...)
  5. # [00:33] * Joins: myakura (myakura@122.18.175.221)
  6. # [00:33] * Joins: myakura_ (myakura@122.18.175.221)
  7. # [00:33] * Quits: myakura (myakura@122.18.175.221) (Connection reset by peer)
  8. # [00:34] * Quits: Ms2ger` (Ms2ger@91.181.219.32) (Quit: nn)
  9. # [00:39] * Quits: myakura_ (myakura@122.18.175.221) (Client exited)
  10. # [01:29] * Joins: homata (homata@58.158.182.50)
  11. # [01:38] * Joins: smfr (smfr@17.203.14.12)
  12. # [01:45] * Quits: smfr (smfr@17.203.14.12) (Ping timeout)
  13. # [02:02] * Joins: kojiishi (kojiishi@222.158.227.129)
  14. # [02:08] * Joins: murakami (murakami@118.154.209.3)
  15. # [02:11] <fantasai> TabAtkins: talk bout
  16. # [02:12] <fantasai> Topic: Tokyo/SF CSS/i18n discussions
  17. # [02:13] <fantasai> Topic: Inline-level Alignment
  18. # [02:13] <fantasai> SteveZ: One is, when we revised CSS2.1 spec last fall, I did some homework. We were figuring how to align inlines in the linebox and where to place the half-leading
  19. # [02:14] <fantasai> SteveZ: The conclusion that we drew from that, and is in the CSS2.1 spec now, is to use the stypo ascender and stypo descender and the wind ascender and wind descender (sp) if not present.
  20. # [02:14] <fantasai> SteveZ: Defining central baseline as halfway between the two seems to make sense.
  21. # [02:14] <fantasai> SteveZ: but there is a caveat
  22. # [02:14] <fantasai> SteveZ: There is no good source for what the embox is.
  23. # [02:14] <fantasai> SteveZ: Adobe has an ideographic baseline in their fonts, which they use for alignment.
  24. # [02:15] <fantasai> SteveZ: They said to use the ideographic baseline as the bottom of the embox
  25. # [02:15] <fantasai> SteveZ: In Adobe fonts this is usually -120, since 0 is alphabetic baseline
  26. # [02:15] <fantasai> SteveZ: That was the input I got from Adobe
  27. # [02:16] <fantasai> SteveZ: Suggestion to put a note, similar to the note that's in the CSS2.1 spec for inline positioning to determine what ascender and descender to look at,
  28. # [02:16] <fantasai> SteveZ: And put suggestion for using 12% down from alphabetic
  29. # [02:17] <fantasai> fantasai: Don't all fonts have ascender/descender info?
  30. # [02:17] <fantasai> SteveZ: Pretty much all fonts have alphabetic baseline
  31. # [02:18] <fantasai> SteveZ: ... this is suggestion on what to do if baseline tables are missing
  32. # [02:18] <fantasai> Koji talks about some really weird fonts with zero descender
  33. # [02:18] <fantasai> SteveZ: Adobe and MS have fixed fonts as some of these issues have come to light. Wouldn't trust Windows 3.1 heuristics today.
  34. # [02:19] * Joins: jdaggett (jdaggett@202.221.217.73)
  35. # [02:20] <fantasai> fantasai: If ideographic baseline is better than descender, then we can suggest using that if it exists
  36. # [02:20] <fantasai> fantasai: and fallback to descender
  37. # [02:20] <fantasai> fantasai: I don't think we should use -120 instead of descender
  38. # [02:21] <fantasai> fantasai: is ideographic baseline the same as the bottom always?
  39. # [02:21] <fantasai> SteveZ: I think it's defined as the bottom, but I'll take an action to check.
  40. # [02:21] * fantasai notes to jdaggett that koji can pull him into the call if he wants
  41. # [02:21] <kojiishi> http://www.microsoft.com/typography/otspec/baselinetags.htm
  42. # [02:22] <fantasai> SteveZ: Nat McCully on the Adobe InDesign team sent me the name of the ideographic baseline that should be accurate if it exists.
  43. # [02:22] <fantasai> SteveZ is looking this up, should report back exact name soon.
  44. # [02:22] <fantasai> http://dev.w3.org/csswg/css3-writing-modes/#inline-alignment
  45. # [02:22] <fantasai> Discussing ^
  46. # [02:22] <fantasai> Koji describes his microsoft.com link to baseline table keywords
  47. # [02:23] * Quits: plinss_ (plinss@192.6.114.30) (Quit: plinss_)
  48. # [02:24] <fantasai> fantasai: Ken Lunde talked about the ICF lines.
  49. # [02:24] <fantasai> fantasai: Basically, the embox is the design space for the glyph
  50. # [02:24] <fantasai> fantasai: but the glyph ink rarely extends to the full area of that space
  51. # [02:24] <fantasai> fantasai: the ICF box is the area inside which the glyph is drawn
  52. # [02:24] <fantasai> fantasai: It is slightly smaller than the embox.
  53. # [02:25] <fantasai> fantasai: Depending on what you're doing, it is sometimes better to do baseline alignment to the ICF box edges
  54. # [02:25] <kojiishi> The link above says "The ideographic character face (ICF), also known as the average character face (ACF), specifies the approximate bounding box of the full-width ideographic and kana glyphs in a CJK font."
  55. # [02:26] <fantasai> SteveZ reads from an email
  56. # [02:27] <fantasai> SteveZ: The ideo is the embox bottom; idtp is embox top
  57. # [02:27] <fantasai> (these are baseline names)
  58. # [02:27] <fantasai> Koji: Question then is how much do these values differ from ascender and descender, or are they identical.
  59. # [02:28] <fantasai> fantasai: I can definitely update the spec to reference these baselines, and then use ascender/descender if they are missing.
  60. # [02:28] <fantasai> SteveZ: Also copy note about ascender/descender in OT fonts from CSS2.1
  61. # [02:30] <fantasai> ...
  62. # [02:30] <fantasai> SteveZ: So for central baseline you want to add half of design space to ideo baseline
  63. # [02:31] <fantasai> fantasai: idtp doesn't seem to be very common, because it's not used for baseline alignment
  64. # [02:32] <fantasai> fantasai: ideo seems to be in the baseline table, even though it's supposed to be the same as descender, because it's used for baseline alignment
  65. # [02:32] <fantasai> fantasai: but since idtp is usually missing and would have to be replaced with ascender, wouldn't it make more sense to use ascender + descender?
  66. # [02:32] <fantasai> fantasai: after all, we are synthesizing a baseline (the central baseline); using any metrics should make sense.
  67. # [02:33] <fantasai> SteveZ, reading from some document: The bottom of the ideographic embox and the value of stypo descender are supposed to be the same.
  68. # [02:33] <fantasai> SteveZ reads an example from the document
  69. # [02:35] <fantasai> fantasai: So why not use ascender+descender? We have to use it for alignment anyway
  70. # [02:35] <fantasai> SteveZ: Should use romn baseline, first
  71. # [02:36] <fantasai> SteveZ: Then use ascender+descender
  72. # [02:36] <fantasai> fantasai: but you need ascender+descender to do leading anyway
  73. # [02:36] <fantasai> SteveZ: ...
  74. # [02:37] <fantasai> SteveZ: The win ascender and win descender are designed for clipping, so a reasonable fallback from stypo values, but not really the same thing.
  75. # [02:37] <fantasai> fantasai: So, if you have romn baseline, but no ascender/descender info, what do you do about leading?
  76. # [02:38] <fantasai> SteveZ: Well, let's write up the best we have, and then have jdaggett look at it because he as to deal with it, and he'll tell us if we're wrong.
  77. # [02:38] <fantasai> fantasai: Well this looks like fun.
  78. # [02:38] <fantasai> SteveZ: Remember, font is a four-letter word beginning with f.
  79. # [02:39] <fantasai> Koji describes fonts with ascenders and descenders that cross out of the embox.
  80. # [02:40] <fantasai> SteveZ: I think what we want to say is that the ascender and descender that's related to the embox of the font, not necessarily of any individual character, is what we want.
  81. # [02:40] <fantasai> fantasai: Zapfino is a commonly-given example of that kind of font
  82. # [02:40] <fantasai> fantasai: Actually, I often write like that when I'm writing letters.
  83. # [02:41] <fantasai> Koji: Your current text says "ascender/descender edges of the embox", so it probably describes well enough.
  84. # [02:41] <fantasai> SteveZ: The catch is that people won't realize the other metrics won't do that.
  85. # [02:42] <fantasai> fantasai: We can copy over the note, and add a little more info on what the various things represent.
  86. # [02:42] <fantasai> Koji: What about the issue on missing alphabetic baseline?
  87. # [02:43] <fantasai> SteveZ: Let me ask about that one.
  88. # [02:44] <fantasai> fantasai: So, first you'd want to use ascender+descender to find romn, then...?
  89. # [02:44] <fantasai> SteveZ: Use 120.
  90. # [02:44] <fantasai> fantasai: 12%, in case design space is different
  91. # [02:44] <fantasai> fantasai: Ok, so my actions here are to copy over the note from CSS2.1 and add detail about what stypo and win difference are
  92. # [02:45] * Joins: szilles (chatzilla@71.83.118.221)
  93. # [02:45] <fantasai> fantasai: Write in romn fallback to ascender+descender calculations
  94. # [02:45] <fantasai> fantasai: if zero is not at the bottom, use zero
  95. # [02:45] <fantasai> fantasai: and if zero is at the bottom, use 12%
  96. # [02:46] <fantasai> fantasai: And find out from font mystics whether this divination technique is valid :p
  97. # [02:47] <fantasai> koji has a concern about what 12% is referencing
  98. # [02:47] <fantasai> stevez says it references the design space, which scales with the size of the font
  99. # [02:47] <fantasai> Koji: So about vertical text
  100. # [02:48] <fantasai> SteveZ: In rotated text, the roman baseline is the same as in horizontal text
  101. # [02:48] <fantasai> fantasai note to self -- need to write aobut mixed orientation text
  102. # [02:49] * Quits: szilles (chatzilla@71.83.118.221) (Ping timeout)
  103. # [02:49] * Joins: szilles (chatzilla@71.83.118.221)
  104. # [02:49] <fantasai> fantasai: If you're not rotating, then why is there an alphabetic basline?
  105. # [02:49] <fantasai> SteveZ: I assume the Latin character is centered left-to-right
  106. # [02:50] <fantasai> fantasai: top-to-bottom alignment is an advance width issue, not a baseline alignment issue
  107. # [02:50] <fantasai> fantasai: The alphabetic baseline is irrelevant if you're setting text upright
  108. # [02:51] <fantasai> fantasai: In the case where the text is upright, you always want to use the central baseline.
  109. # [02:51] <fantasai> SteveZ: Some fonts have tables for vertical
  110. # [02:51] <murakami> I think characters in text-orientation:upright should be aligned same as text-combine:horizontal with one character.
  111. # [02:51] <fantasai> SteveZ: so that's where you ought to start
  112. # [02:51] <fantasai> murakami, yes, that would be central alignment
  113. # [02:52] <fantasai> murakami, but we have to figure out what exactly that means :)
  114. # [02:54] <fantasai> fantasai: So, let me guess here at what the best we can do
  115. # [02:55] <fantasai> fantasai: ...
  116. # [02:55] <fantasai> fantasai: the ascender/descender values are not axis-dependent, are they
  117. # [02:55] <fantasai> :/
  118. # [02:56] <fantasai> fantasai: So, if we have a proper font, and all the text is in that font, we're just creating a stack of emboxes
  119. # [02:56] <fantasai> fantasai: that all line up
  120. # [02:56] <fantasai> fantasai: And the font is responsible for positioning the glyph within that embox
  121. # [02:56] <fantasai> fantasai: and adjusting the advance height to be correct
  122. # [02:57] <fantasai> fantasai: Is there such a thing as advance height?
  123. # [02:57] <kojiishi> http://www.microsoft.com/typography/otspec/vmtx.htm
  124. # [02:57] <fantasai> Koji: It's a vmtx (vertical metrics) table
  125. # [02:58] <fantasai> fantasai: So we just make a stack of emboxes using the advance height and aligning the left and right edges of all the emboxes
  126. # [02:58] <fantasai> fantasai: And the font is responsible for positining the glyph in that embox using its gsub feature?
  127. # [02:58] <fantasai> er
  128. # [02:58] <fantasai> gpos
  129. # [02:58] <fantasai> s/gsub/gpos/
  130. # [02:58] <fantasai> fantasai: That's if it has all the data
  131. # [02:59] <fantasai> fantasai: So if it's missing information, then we have to figure out what it's missing and substitute in?
  132. # [03:00] <fantasai> Koji: so we probably want to follow Murakami-san's suggestion to match text-combine
  133. # [03:00] <fantasai> fantasai: How do you know if gpos information is missing for vertical?
  134. # [03:00] <fantasai> SteveZ: gpos table is missing? but it's used for other things
  135. # [03:01] <fantasai> fantasai: We could check for vert feature
  136. # [03:01] * Joins: homata_ (homata@58.158.182.50)
  137. # [03:01] <fantasai> SteveZ looking at gpos table info
  138. # [03:01] <fantasai> SteveZ: "Positioning glyphs with TrueType 1.0" and it shows horizontal and vertical metrics example
  139. # [03:02] <szilles> http://www.microsoft.com/typography/otspec/gpos.htm
  140. # [03:02] <kojiishi> http://www.microsoft.com/typography/SpecificationsOverview.mspx
  141. # [03:03] * Quits: homata (homata@58.158.182.50) (Ping timeout)
  142. # [03:04] <fantasai> SteveZ: But I don't think we want to get into stuff like gpos
  143. # [03:04] <fantasai> SteveZ: The diagram is nice though
  144. # [03:04] <fantasai> fantasai: We can link to it
  145. # [03:04] <fantasai> fantasai: "The UA should synthesize whatever metrics are missing to the best of its ability." ?
  146. # [03:05] <fantasai> SteveZ: Should be good for now.
  147. # [03:05] <fantasai> SteveZ: If we could give better advice we should, to get more consistency.
  148. # [03:05] <fantasai> SteveZ: because fonts are so bad, esp. with vertical
  149. # [03:07] <fantasai> Koji: text-combine is atomic inline?
  150. # [03:08] <fantasai> fantasai: .. I think it's just inline. But behaves like a single glyph
  151. # [03:08] <fantasai> fantasai: If it was atomic inline, it would align to margin edge, and width/height would apply to it and stuff.
  152. # [03:09] <fantasai> Koji: So the behavior of baseline of text-combine is defined in property itself.
  153. # [03:10] <fantasai> Koji: Ok, I think we are good for now. Anything else we want to discuss?
  154. # [03:10] <fantasai> SteveZ: Yeah, I think we're good.
  155. # [03:11] <fantasai> Koji: Tokyo Workshop, will send email.
  156. # [03:11] <fantasai> Koji: For MV F2F, we have agenda for telecon tomorrow
  157. # [03:14] <TabAtkins> fantasai: talk bout? Is the conversation above something I should be paying attention to?
  158. # [03:14] <fantasai> Skipping next week's call. Steve and fantasai will be on east coast
  159. # [03:15] <fantasai> Meeting closed.
  160. # [03:15] <fantasai> TabAtkins: Not particularly, unless you care about font metrics in vertical text :)
  161. # [03:16] <TabAtkins> Okay. Why did you mention me an hour ago, then?
  162. # [03:16] * fantasai scrolls up
  163. # [03:16] <fantasai> huh
  164. # [03:16] <fantasai> That was not what I meant to type
  165. # [03:16] <fantasai> I was going to say, talk to Bert :)
  166. # [03:16] <TabAtkins> Ah, kk.
  167. # [03:17] <fantasai> on the topic of Bert,
  168. # [03:17] <fantasai> Bert: http://www.w3.org/Style/CSS/Test/Fonts/ is still returning 502 Bad Gateway
  169. # [03:17] <TabAtkins> Also, Brad finally responded. I'm going to slightly tweak the issues in gradients in response. No change to the rest of the spec.
  170. # [03:17] <fantasai> kk
  171. # [03:17] <fantasai> let me know when you're done
  172. # [03:17] <TabAtkins> k, one sec.
  173. # [03:22] * Quits: murakami (murakami@118.154.209.3) (Quit: Leaving...)
  174. # [03:24] <TabAtkins> fantasai: Done and committed.
  175. # [03:24] <fantasai> k
  176. # [03:25] <TabAtkins> fantasai: Thanks for preparing the draft for WD and making the revisions you did, btw.
  177. # [03:25] <fantasai> you're welcome :)
  178. # [03:26] <fantasai> thanks for drafting up most of the text ^_^
  179. # [03:49] * Joins: miketaylr (miketaylr@76.15.238.5)
  180. # [03:51] * Quits: miketaylr (miketaylr@76.15.238.5) (Quit: Linkinus is updating...)
  181. # [03:51] * Joins: miketaylr (miketaylr@76.15.238.5)
  182. # [04:00] <plinss> Bert: I fixed the link, added DirectoryIndex Overview.html to the .htaccess file
  183. # [04:40] * Quits: kennyluck (kennyluck@128.30.52.169) (Ping timeout)
  184. # [04:41] * Quits: dbaron (dbaron@63.245.220.240) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  185. # [05:07] * Joins: dbaron (dbaron@98.234.51.190)
  186. # [05:10] * Joins: kennyluck (kennyluck@128.30.52.169)
  187. # [06:59] * Quits: miketaylr (miketaylr@76.15.238.5) (Quit: miketaylr)
  188. # [07:33] * Quits: szilles (chatzilla@71.83.118.221) (Ping timeout)
  189. # [07:33] * Joins: szilles (chatzilla@71.83.118.221)
  190. # [08:01] * Joins: davve (davve@83.218.67.122)
  191. # [08:13] * Quits: szilles (chatzilla@71.83.118.221) (Ping timeout)
  192. # [08:15] * Joins: szilles (chatzilla@71.83.118.221)
  193. # [09:00] * Quits: dbaron (dbaron@98.234.51.190) (Ping timeout)
  194. # [09:24] * Joins: anne (annevk@83.85.115.123)
  195. # [10:03] * Quits: jdaggett (jdaggett@202.221.217.73) (Quit: jdaggett)
  196. # [10:10] * Joins: homata (homata@58.158.182.50)
  197. # [10:11] * Quits: homata_ (homata@58.158.182.50) (Ping timeout)
  198. # [11:52] * Joins: myakura (myakura@122.18.175.221)
  199. # [12:36] * Joins: homata_ (homata@58.158.182.50)
  200. # [12:36] * Quits: homata (homata@58.158.182.50) (Ping timeout)
  201. # [12:44] * Quits: homata_ (homata@58.158.182.50) (Quit: Leaving...)
  202. # [12:49] * Quits: lhnz (lhnz@188.223.83.48) (Ping timeout)
  203. # [12:49] * Joins: lhnz (lhnz@188.223.83.48)
  204. # [14:50] * Joins: miketaylr (miketaylr@206.217.92.186)
  205. # [17:02] * Joins: Ms2ger (Ms2ger@91.181.219.32)
  206. # [17:25] * Quits: szilles (chatzilla@71.83.118.221) (Quit: ChatZilla 0.9.86 [Firefox 3.6.13/20101203075014])
  207. # [17:28] * Joins: Martijnc (Martijnc@91.176.50.133)
  208. # [17:45] * Joins: glazou (glazou@85.168.18.110)
  209. # [17:45] * Joins: Zakim (rrs-bridgg@128.30.52.169)
  210. # [17:45] * Joins: RRSAgent (rrs-loggee@128.30.52.169)
  211. # [17:45] <RRSAgent> logging to http://www.w3.org/2011/02/16-css-irc
  212. # [17:46] <glazou> Zakim, this will be Style
  213. # [17:46] <Zakim> ok, glazou; I see Style_CSS FP()12:00PM scheduled to start in 18 minutes
  214. # [17:46] <glazou> RRSAgent, make logs public
  215. # [17:46] <RRSAgent> I have made the request, glazou
  216. # [17:46] <glazou> Zakim, code ?
  217. # [17:46] <Zakim> the conference code is 78953 (tel:+1.617.761.6200 tel:+33.4.26.46.79.03 tel:+44.203.318.0479), glazou
  218. # [17:47] * Joins: dbaron (dbaron@98.234.51.190)
  219. # [18:01] * Joins: oyvind (oyvinds@213.236.208.22)
  220. # [18:01] <Zakim> Style_CSS FP()12:00PM has now started
  221. # [18:01] <Zakim> +[Microsoft]
  222. # [18:01] <Zakim> +??P0
  223. # [18:01] <glazou> Zakim, ??P0 is me
  224. # [18:01] <Zakim> +glazou; got it
  225. # [18:01] <arronei> zakim, Microsoft is me
  226. # [18:01] <Zakim> +arronei; got it
  227. # [18:03] * Joins: TabAtkins_ (tabatkins@216.239.45.19)
  228. # [18:03] <Zakim> + +1.858.216.aaaa
  229. # [18:03] <plinss> zakim, aaaa is me
  230. # [18:03] <Zakim> +plinss; got it
  231. # [18:03] * Joins: smfr (smfr@68.183.195.83)
  232. # [18:04] <Zakim> +smfr
  233. # [18:04] <Zakim> +[Microsoft]
  234. # [18:04] * Joins: alexmog (alexmog@24.16.133.35)
  235. # [18:04] <Zakim> +TabAtkins_
  236. # [18:04] * Joins: johnjan (qw3birc@128.30.52.28)
  237. # [18:04] * Joins: cesar (acebal@85.152.178.140)
  238. # [18:04] <johnjan> zakim, microsoft is johnjan
  239. # [18:04] <Zakim> +johnjan; got it
  240. # [18:05] * Joins: sylvaing (sylvaing@98.232.9.174)
  241. # [18:05] <Zakim> + +1.206.324.aabb
  242. # [18:06] <Zakim> +fantasai
  243. # [18:06] * sylvaing may have to step away for 10-15 minutes during the call. apologies for that.
  244. # [18:06] <Zakim> +Bert
  245. # [18:07] <Zakim> + +46.0.94.0.aacc
  246. # [18:07] <Zakim> +??P24
  247. # [18:07] <Zakim> +??P25
  248. # [18:07] <kojiishi> zakim, ??p24 is me
  249. # [18:07] <Zakim> +kojiishi; got it
  250. # [18:07] <cesar> Zakim, aacc is me.
  251. # [18:07] <Zakim> +cesar; got it
  252. # [18:07] <Zakim> -kojiishi
  253. # [18:08] <TabAtkins_> ScribeNick: TabAtkins_
  254. # [18:08] <Zakim> +??P24
  255. # [18:08] <kojiishi> zakim, ??p24 is me
  256. # [18:08] <Zakim> +kojiishi; got it
  257. # [18:08] * Joins: ChrisL (ChrisL@128.30.52.169)
  258. # [18:09] <TabAtkins_> glazou: Extra agenda item sent to the list from Koji.
  259. # [18:09] <TabAtkins_> glazou: Asking to resurrect CSS Line Grid, with him assuming editorship.
  260. # [18:09] <Zakim> +ChrisL
  261. # [18:09] <TabAtkins_> glazou: Any objection to this?
  262. # [18:10] <TabAtkins_> [no objections]
  263. # [18:10] <TabAtkins_> glazou: Welcome, Koji.
  264. # [18:10] <glazou> http://idpf.org/epub/30/spec/epub30-contentdocs.html#sec-css-profile
  265. # [18:10] <TabAtkins_> glazou: Next topic. Epub wants us to review the CSS-related section of their doc and send comments.
  266. # [18:10] <Zakim> +SteveZ
  267. # [18:10] <TabAtkins_> fantasai: I'm pretty sure we'll have some reasonably amount of time to discuss it.
  268. # [18:11] * Joins: szilles (chatzilla@71.83.118.221)
  269. # [18:11] <TabAtkins_> glazou: The CSS section is mostly a profile, right?
  270. # [18:11] <TabAtkins_> fantasai: Yes, so we want to make sure they're profiling correctly.
  271. # [18:11] <ChrisL> its also a profile of CSS 2.1, while EPUB2 was CSS2 iirc
  272. # [18:11] <TabAtkins_> fantasai: jdaggett had some concerns, but I think they were addressed before publishing.
  273. # [18:11] <Zakim> + +1.650.275.aadd
  274. # [18:12] <TabAtkins_> fantasai: There are several features not in CR yet, so we need to make sure we're okay with dealing with that.
  275. # [18:12] * Joins: bradk (bradk@99.7.175.117)
  276. # [18:12] <TabAtkins_> ACTION on everyone: Review the CSS-related section of the epub document.
  277. # [18:12] * trackbot noticed an ACTION. Trying to create it.
  278. # [18:12] <trackbot> Sorry, couldn't find user - on
  279. # [18:12] <fantasai> I don't see any mention of a deadline for comments.
  280. # [18:13] <TabAtkins_> Topic: CSS 2.1 issues
  281. # [18:13] <Zakim> +David_Baron
  282. # [18:13] <TabAtkins_> glazou: Peter, you got a message from web2pdf.
  283. # [18:13] <TabAtkins_> plinss: They're fixing a bunch of bugs in our blocked tests.
  284. # [18:13] <glazou> WebToPDF.NET
  285. # [18:13] <fantasai> Probably one month is good, so that they have time to address them and can make it in before their next draft (which I'm guessing will be more than one month out).
  286. # [18:13] <TabAtkins_> plinss: They'll have a public beta release that fixes several of our blockers.
  287. # [18:13] <glazou> http://test.csswg.org/harness/results?s=CSS21_HTML&t=0&f[]=1&f[]=1
  288. # [18:14] <TabAtkins_> plinss: We're on 15 blocked tests now.
  289. # [18:14] <TabAtkins_> plinss: I know they have fixes on two of them, and regressions on two more that they'll go back and fix.
  290. # [18:14] <TabAtkins_> glazou: Any other 2.1 comments?
  291. # [18:15] <TabAtkins_> johnjan: Looks like Elika's done a bunch of updates to the current issues list.
  292. # [18:15] <TabAtkins_> fantasai: I just copied over the LC comments from the page I was stashing them on.
  293. # [18:16] <Zakim> -glazou
  294. # [18:16] * ChrisL glazou sip timeout
  295. # [18:16] <TabAtkins_> fantasai: There's a bunch of issues over clearance and margins that need a closer look at.
  296. # [18:16] <glazou> one sec please
  297. # [18:17] <fantasai> http://wiki.csswg.org/spec/css2.1#issue-209
  298. # [18:17] <TabAtkins_> fantasai: Issue 209 should be easy to resolve.
  299. # [18:17] <Zakim> +??P0
  300. # [18:17] <glazou> Zakim, ??P0 is me
  301. # [18:17] <Zakim> +glazou; got it
  302. # [18:17] <fantasai> http://wiki.csswg.org/spec/css2.1#issue-207 probably requres some investigation by WG members; it involves clearance
  303. # [18:17] <glazou> ChrisL: free.fr still cutting at 15mn despite of reregister settings...
  304. # [18:17] <fantasai> also http://wiki.csswg.org/spec/css2.1#issue-211 is margin collapsing
  305. # [18:19] <TabAtkins_> dbaron: The issue with the root element is that we never say what precisely establishes the root BFC, whether it's the root element or osmething above it.
  306. # [18:19] <TabAtkins_> dbaron: The only place I've found that matters is if the root contains floats that extend below its normal content, or if the root has a background image vertically positioned anywhere other than "top".
  307. # [18:20] <fantasai> s/or/and/
  308. # [18:20] <TabAtkins_> dbaron: Gecko treats it as the root establishes a new BFC. Opera and Webkit don't.
  309. # [18:20] <TabAtkins_> fantasai: My inclination is to treat it as a BFC, since its margins don't collapse. It would make things more consistent.
  310. # [18:21] <TabAtkins_> alexmog: In IE we have a pagination problem, since if the root is a BFC then it won't break across pages.
  311. # [18:21] <TabAtkins_> fantasai: Why would the root take the size of the page?
  312. # [18:22] <TabAtkins_> alexmog: The root's layout box (whatever gets the scrollbar) gets set to the size of the first page.
  313. # [18:22] <TabAtkins_> alexmog: I may not be able to describe the problems properly, and they may be impl-specific.
  314. # [18:23] <glazou> https://bug590491.bugzilla.mozilla.org/attachment.cgi?id=469029
  315. # [18:23] <dbaron> https://bug590491.bugzilla.mozilla.org/attachment.cgi?id=469029
  316. # [18:23] <fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0A%20%20html%20{%20border%3A%20solid%20blue%3B%20}%0A%20%20.float%20{%20float%3A%20left%3B%20height%3A%2016in%3B%20border%3A%20solid%20orange%3B%20}%0A%3C%2Fstyle%3E%0A%0A%3Cdiv%20class%3D%22float%22%3E%3C%2Fdiv%3E
  317. # [18:23] <TabAtkins_> dbaron: What matters in the test is the position of the orange stripe
  318. # [18:23] <dbaron> in first test, what matters is position of orange stripe
  319. # [18:24] <TabAtkins_> fantasai: In my test, if the blue box is large enough to hold the yellow, it's a BFC.
  320. # [18:24] <TabAtkins_> alexmog: It's not a BFC in IE9 or IE8. It was in IE7.
  321. # [18:24] <TabAtkins_> fantasai: I suspect this isn't a web compat issue, since we have differeing implementations.
  322. # [18:25] <TabAtkins_> fantasai: So I suggest to make it a BFC, because authors would get confused otherwise when root backgrounds don't contain their floats.
  323. # [18:25] <TabAtkins_> alexmog: Can I check with Paged Media issues and get back to you on that?
  324. # [18:25] <TabAtkins_> fantasai: Yup.
  325. # [18:26] <TabAtkins_> alexmog: Another issue. When pages change width, usually you take the width of the page where the BFC starts, and it stays that width. This is how we treat tables and such.
  326. # [18:26] <TabAtkins_> alexmog: But if the root is a BFC it has to act differently, so it can get larger if the page gets larger.
  327. # [18:26] <TabAtkins_> Bert: Related, we have 'overflow' which can't apply to <body>.
  328. # [18:28] <TabAtkins_> glazou: So do we need more time to decide on exactly how to handle this?
  329. # [18:28] <TabAtkins_> dbaron: I'm okay with changing Moz, though we do need to define where the root BFC comes from.
  330. # [18:29] * Joins: shan (soonbo.han@111.118.53.146)
  331. # [18:29] <TabAtkins_> glazou: Is that okay with everyone?
  332. # [18:29] <dbaron> I don't really understand alexmog's paged media issue, though.
  333. # [18:30] <TabAtkins_> alexmog: Is it okay to say that the root is not a BFC in paged media?
  334. # [18:30] <dbaron> I don't see any reference to block formatting contexts in the CSS 2.1 paged media chapter or in css3-page.
  335. # [18:31] <TabAtkins_> alexmog: It's not written anywhere, but it's something that people will have to solve as they implement Paged Media.
  336. # [18:32] <TabAtkins_> dbaron: is it related to BFCs specifically, or just to certian types of things that establish BFCs?
  337. # [18:32] <TabAtkins_> alexmog: It's certainly easier to say that everything that establishes a BFC has that behavior.
  338. # [18:32] <Zakim> -glazou
  339. # [18:32] <TabAtkins_> fantasai: You say IE has special behavior for tables and such across pages to make their widths stay the same across pages?
  340. # [18:33] <TabAtkins_> fantasai: You also do that for overflow:hidden?
  341. # [18:33] <Zakim> +??P0
  342. # [18:33] <glazou> Zakim, ??P0 is me
  343. # [18:33] <Zakim> +glazou; got it
  344. # [18:33] <TabAtkins_> alexmog: Yes, overflow:hidden elements also have this behavior.
  345. # [18:34] <TabAtkins_> fantasai: I'd prefer that overflow:hidden elements act like normal elements.
  346. # [18:34] <TabAtkins_> alexmog: So I don't strongly object to the root being a BFC, it would just make its pagination rules somewhat special.
  347. # [18:34] <TabAtkins_> fantasai: Yeah, the pagination rules aren't clear in the first place. We wrote something aobut chaning page widths into paged media, though it's not quite the same that you have.
  348. # [18:34] <Zakim> +??P9
  349. # [18:35] <TabAtkins_> alexmog: It's unlikely we'll make changes to IE9 in this regard, btw.
  350. # [18:35] <TabAtkins_> glazou: So what do we do?
  351. # [18:35] <shan> Zakim, ??P9 is me
  352. # [18:35] <Zakim> +shan; got it
  353. # [18:37] <TabAtkins_> TabAtkins_: It sounds like nobody has great disagreements, we just need to have some careful consideration of the issues and decide what to specify.
  354. # [18:37] <TabAtkins_> johnjan: Is this really something we want to change right now?
  355. # [18:38] <TabAtkins_> glazou: FF4 and IE9 are shipping with different behavior, so no matter what's decided there will be differeing impls.
  356. # [18:38] <ChrisL> erratum for CSS 2.1 then?
  357. # [18:38] <TabAtkins_> dbaron: I'm okay with waiting siz months and putting this into the next revision of 2.1, but I'm not okay with waiting for CSS3.
  358. # [18:39] <TabAtkins_> RESOLVED: Discuss issue, resolve in CSS 2.1 errata.
  359. # [18:39] <TabAtkins_> Topic: Gamma section in CSS 2.1 spec
  360. # [18:39] <TabAtkins_> ChrisL: There was a discussion a few years ago from Chris Murphy, as a result of which we removed the section on gamma from CSS3 Color.
  361. # [18:39] <TabAtkins_> ChrisL: It was confusing and outdated.
  362. # [18:40] <TabAtkins_> ChrisL: It was recently pointed out to me that the same section is still there in CSS 2.1 as an informative note.
  363. # [18:40] <TabAtkins_> ChrisL: It has no conformance weight, but it's still confusing and outdated and has negative value. So we should delete it from CSS 2.1 as well.
  364. # [18:40] <TabAtkins_> RESOLVED: Remove the gamma note from 2.1.
  365. # [18:42] <arronei> http://wiki.csswg.org/spec/css2.1#issue-215
  366. # [18:42] <arronei> http://wiki.csswg.org/spec/css2.1#issue-216
  367. # [18:42] <TabAtkins_> arronei: There are two issues on the issues list that are super simple, 215 or 216. We discussed at the testing f2f, and I think we all agreed to kill them.
  368. # [18:43] <TabAtkins_> arronei: I'm not hearing any objections to leaving 215 undefined.
  369. # [18:43] <TabAtkins_> arronei: dbaron, you said FF is the only one that passes 216, and everyone else goes the other way. Do you object to dropping it?
  370. # [18:43] <TabAtkins_> dbaron: I'm fine with that. It can fall into a MAY.
  371. # [18:44] <TabAtkins_> RESOLVED: Resolve issue 215 as undefined, and drop issue 216.
  372. # [18:44] <TabAtkins_> Topic: Multicol algorithm.
  373. # [18:44] <ChrisL> the comment from Chris Murphy about being ignored at W3C
  374. # [18:44] <ChrisL> http://lists.freedesktop.org/archives/openicc/2011q1/002969.html
  375. # [18:44] <TabAtkins_> glazou: howcome's not on the call, but he quoted two of his messages.
  376. # [18:44] * glazou loves when philosophy come to CSS :-D
  377. # [18:44] <TabAtkins_> alexmog: There are a few ways to treat a situation when there's no usable layout that satisfies the constraints.
  378. # [18:45] * fantasai votes for adding more comments to the pseudo-algorithm =)
  379. # [18:45] <TabAtkins_> alexmog: One way is to honor everything that is exactly defined, and just overflow if necessary.
  380. # [18:45] <plinss> s/drop issue 216/accept proposal for issue 216/
  381. # [18:45] <TabAtkins_> alexmog: Another is to keep content visible, so users on a phone dn't get a pretty layout, but it's usable.
  382. # [18:46] * Quits: myakura (myakura@122.18.175.221) (Client exited)
  383. # [18:46] <TabAtkins_> alexmog: I think that nowhere in CSS do we alter the way we interpret properties based on whether an overflow is about to happen.
  384. # [18:47] <TabAtkins_> alexmog: If we really care about the end-user and want to show them content, when the design intent totally fails, the best thing for the user is to just drop to a single column as soon as possible when the multicol properties can't be satisfied.
  385. # [18:47] <TabAtkins_> alexmog: So once we shrink down to 0 col width, the next step should be to drop straight to 1 column.
  386. # [18:48] <TabAtkins_> alexmog: I think these are the only two situations (honor exactly, or drop to 1col quickly), and not to try and gradually relax properties, hovering around unusable states.
  387. # [18:48] <Zakim> -glazou
  388. # [18:48] <TabAtkins_> Bert: I like the principle, but what's the practical effect of 0-width columns?
  389. # [18:48] <Zakim> +??P0
  390. # [18:48] <glazou> Zakim, ??P0 is me
  391. # [18:48] <Zakim> +glazou; got it
  392. # [18:48] <TabAtkins_> alexmog: I think the page becomes unusable before 0px-wide columns.
  393. # [18:49] <TabAtkins_> alexmog: If the column is too small, the overflow just intrudes into the column-gap.
  394. # [18:49] <Zakim> -ChrisL
  395. # [18:50] <TabAtkins_> alexmog: If there's a single 0-width column, you'll see the overflow content. With multiple columns you won't.
  396. # [18:50] <TabAtkins_> szilles: I thought we discussed overflow columns just going to the right. Does that help in this case?
  397. # [18:50] <Zakim> +ChrisL
  398. # [18:50] <TabAtkins_> alexmog: Different situation - that's where column width is specified, but not count. This case is where column-count is specified, but not width.
  399. # [18:51] <TabAtkins_> szilles: So really, if you want to service multiple screens, setting a fixed number of columns is a bad idea.
  400. # [18:51] <TabAtkins_> alexmog: Without using media queries, yeah. Setting column-width is a better approach in general.
  401. # [18:53] <TabAtkins_> TabAtkins_: I think we should just honor things exactly. It can produce an unusable situation, but that's easy to fix right with media queries.
  402. # [18:53] <TabAtkins_> szilles: And what happens if I set both -width and -count?
  403. # [18:53] <TabAtkins_> alexmog: Current spec ignores -count in that case.
  404. # [18:54] <TabAtkins_> alexmog: I don't think that this extreme case is a good enough reason to add column-min-width.
  405. # [18:54] <fantasai> I thought the -count became the maximum column count?
  406. # [18:54] <TabAtkins_> alexmog: So we have two in favor of treating things exactly as specified.
  407. # [18:54] <TabAtkins_> bradk: Me to.
  408. # [18:54] <TabAtkins_> s/to/too/
  409. # [18:54] <TabAtkins_> szilles: i could live with it.
  410. # [18:54] <TabAtkins_> glazou: What's the option preferred by howcome?
  411. # [18:54] <TabAtkins_> alexmog: I'd prefer to ask him directly, but I think he was okay with either option, and just wanted consensus.
  412. # [18:55] <TabAtkins_> szilles: "Treating things exactly" is how the spec is now, right?
  413. # [18:55] <TabAtkins_> alexmog: No, the current spec somewhat relaxes count in some situations. It would remove 3 lines from the pseudo-algorithm.
  414. # [18:55] <Zakim> -cesar
  415. # [18:56] <TabAtkins_> fantasai: -count sets a minimum number of columns when used with -width, so if you set both values you effectively get a minimum width anyway.
  416. # [18:56] <fantasai> s/minimum number/maximum number/
  417. # [18:57] <TabAtkins_> alexmog: So I think we should ask howcome if he agrees with the consensus here.
  418. # [18:57] <fantasai> You get your column count combined with a minimum width for the columns
  419. # [18:57] <TabAtkins_> ACTION howcome to read the minutes from today and confirm if he agrees or not with the Multicol algo consensus.
  420. # [18:57] * trackbot noticed an ACTION. Trying to create it.
  421. # [18:57] <trackbot> Created ACTION-297 - Read the minutes from today and confirm if he agrees or not with the Multicol algo consensus. [on Håkon Wium Lie - due 2011-02-23].
  422. # [18:57] <fantasai> So if is not room for all the columns given your -width, the algorithm drops columns until -width is honored
  423. # [18:57] <TabAtkins_> Topic: :active disagreement between CSS and HTML
  424. # [18:58] * dbaron url to message?
  425. # [18:58] <fantasai> Could even recommend that authors set -width when setting -count, so that the columns don't get too narrow.
  426. # [18:58] <TabAtkins_> Bert: I think the trouble is the definition of the word "activate".
  427. # [18:58] <fantasai> http://lists.w3.org/Archives/Public/www-style/2011Feb/0426.html
  428. # [18:58] <TabAtkins_> Bert: We thought we needed some indirection at the time of speccing, so we just used the word "activate" and let the source language define that.
  429. # [18:58] <TabAtkins_> Bert: But HTML already uses the word "activate" for something else.
  430. # [18:59] * dbaron url to Bert's message?
  431. # [18:59] <TabAtkins_> Bert: So this is just a wording problem. They have to invent a new word for this or something, as the word "activate" is already taken in that spec.
  432. # [18:59] <fantasai> http://lists.w3.org/Archives/Member/w3c-css-wg/2011JanMar/0176.html
  433. # [18:59] <TabAtkins_> ChrisL: So it seems that HTML can just say "For CSS purpose, 'activate' means XXX"
  434. # [19:00] <TabAtkins_> Bert: Right. Another option is for HTML to use a different word for what they currently call "activate", and then use "activate" in the CSS sense.
  435. # [19:00] * fantasai has the opinion that Bert should forward his message to www-style
  436. # [19:00] * Ms2ger or the other way around
  437. # [19:00] <TabAtkins_> TabAtkins_: I pinged Hixie this morning to ask him to change the wording.
  438. # [19:01] <TabAtkins_> ACTION TabAtkins to report back to the group on the progress of this issue.
  439. # [19:01] * trackbot noticed an ACTION. Trying to create it.
  440. # [19:01] <trackbot> Sorry, couldn't find user - TabAtkins
  441. # [19:01] <TabAtkins_> ACTION tab to report back to the group on the progress of this issue.
  442. # [19:01] * trackbot noticed an ACTION. Trying to create it.
  443. # [19:01] <trackbot> Created ACTION-298 - Report back to the group on the progress of this issue. [on Tab Atkins Jr. - due 2011-02-23].
  444. # [19:03] <Zakim> -glazou
  445. # [19:04] <glazou> shit
  446. # [19:04] <glazou> cannotrejoin
  447. # [19:04] <TabAtkins_> [discussion about communication between WGs]
  448. # [19:04] <glazou> guys, end of call, will summarize by email
  449. # [19:04] <glazou> sorry for that, blame my SIP client:(
  450. # [19:04] <Zakim> -David_Baron
  451. # [19:05] <Zakim> -ChrisL
  452. # [19:05] <Zakim> -johnjan
  453. # [19:05] <Zakim> -smfr
  454. # [19:05] * Quits: bradk (bradk@99.7.175.117) (Quit: Get MacIrssi - http://www.sysctl.co.uk/projects/macirssi/ )
  455. # [19:05] <Zakim> -plinss
  456. # [19:05] <Zakim> -SteveZ
  457. # [19:05] <Zakim> -kojiishi
  458. # [19:05] <Zakim> -??P25
  459. # [19:05] <Zakim> -Bert
  460. # [19:05] <Zakim> -fantasai
  461. # [19:05] <Zakim> - +1.650.275.aadd
  462. # [19:05] <Zakim> -TabAtkins_
  463. # [19:05] <Zakim> -shan
  464. # [19:05] <Zakim> -arronei
  465. # [19:06] <fantasai> Bert: can you forward your message to www-style?
  466. # [19:06] <cesar> I'm sorry too: it seems I finished my Skype credit. :( (I have to try a SIP client). Bye!
  467. # [19:07] * Quits: kojiishi (kojiishi@222.158.227.129) (Quit: Leaving...)
  468. # [19:09] * Quits: TabAtkins_ (tabatkins@216.239.45.19) (Ping timeout)
  469. # [19:10] * Quits: oyvind (oyvinds@213.236.208.22) (Quit: oyvind)
  470. # [19:11] <Zakim> disconnecting the lone participant, +1.206.324.aabb, in Style_CSS FP()12:00PM
  471. # [19:11] <Zakim> Style_CSS FP()12:00PM has ended
  472. # [19:11] <Zakim> Attendees were glazou, arronei, +1.858.216.aaaa, plinss, smfr, TabAtkins_, johnjan, +1.206.324.aabb, fantasai, Bert, +46.0.94.0.aacc, kojiishi, cesar, ChrisL, SteveZ,
  473. # [19:11] <Zakim> ... +1.650.275.aadd, David_Baron, shan
  474. # [19:11] <TabAtkins> Bert: Image Values should be all ready for WD publishing now, btw.
  475. # [19:11] * Quits: glazou (glazou@85.168.18.110) (Quit: glazou)
  476. # [19:11] <TabAtkins> Bert: Anything else I need to do?
  477. # [19:12] * Quits: cesar (acebal@85.152.178.140) (Quit: cesar)
  478. # [19:12] <fantasai> Bert: (Tab made a couple extra editorial edits yesterday)
  479. # [19:14] <Bert> I'll try to have it published tomorrow.
  480. # [19:14] * Quits: johnjan (qw3birc@128.30.52.28) (Quit: Page closed)
  481. # [19:15] * Quits: ChrisL (ChrisL@128.30.52.169) (Quit: Fire on main board error, client combusted)
  482. # [19:15] <TabAtkins> Bert: Cool, thanks.
  483. # [19:16] <Bert> Do you remember at what telcon we decided to publish it? Was it in January?
  484. # [19:17] <Bert> Found it, Jan 26
  485. # [19:17] * Quits: smfr (smfr@68.183.195.83) (Quit: smfr)
  486. # [19:19] * Joins: smfr (smfr@68.183.195.83)
  487. # [19:26] * Quits: smfr (smfr@68.183.195.83) (Quit: smfr)
  488. # [19:26] * Quits: arronei (arronei@131.107.0.85) (Ping timeout)
  489. # [19:32] * Joins: arronei (arronei@131.107.0.91)
  490. # [19:39] * Quits: dbaron (dbaron@98.234.51.190) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  491. # [20:00] * Quits: plinss (plinss@68.107.116.23) (Quit: plinss)
  492. # [20:06] * Joins: dbaron (dbaron@63.245.220.240)
  493. # [20:11] * Joins: hey (4f92ac88@207.192.75.252)
  494. # [20:12] * Joins: plinss (plinss@68.107.116.23)
  495. # [20:15] * Joins: oickoame (oickoame@79.146.172.136)
  496. # [20:16] <hey> hola
  497. # [20:16] <hey> esto es una prueba
  498. # [20:16] <hey> chao
  499. # [20:16] * Parts: hey (4f92ac88@207.192.75.252)
  500. # [20:19] * Quits: oickoame (oickoame@79.146.172.136) (Quit: oickoame)
  501. # [20:20] * Quits: shan (soonbo.han@111.118.53.146) (Quit: shan)
  502. # [20:21] * Joins: smfr (smfr@17.203.14.227)
  503. # [20:21] * Parts: smfr (smfr@17.203.14.227)
  504. # [20:27] * Joins: hober (ted@174.143.153.77)
  505. # [20:41] * Joins: ChrisL (ChrisL@128.30.52.169)
  506. # [20:52] * Quits: alexmog (alexmog@24.16.133.35) (Ping timeout)
  507. # [21:12] * Quits: karl (karlcow@128.30.54.58) (Quit: Freedom - to walk free and own no superior.)
  508. # [21:16] * Zakim excuses himself; his presence no longer seems to be needed
  509. # [21:16] * Parts: Zakim (rrs-bridgg@128.30.52.169)
  510. # [21:29] * Quits: Martijnc (Martijnc@91.176.50.133) (Quit: Martijnc)
  511. # [22:06] * Joins: jdaggett (jdaggett@118.243.227.145)
  512. # [22:14] * Parts: sylvaing (sylvaing@98.232.9.174)
  513. # [22:29] * Joins: smfr_ (smfr@17.246.16.151)
  514. # [22:33] * Quits: smfr_ (smfr@17.246.16.151) (Quit: smfr_)
  515. # [22:38] * Joins: myakura (myakura@122.18.175.221)
  516. # [22:39] * Joins: myakura_ (myakura@122.18.175.221)
  517. # [22:39] * Quits: myakura (myakura@122.18.175.221) (Connection reset by peer)
  518. # [23:06] * Quits: miketaylr (miketaylr@206.217.92.186) (Quit: miketaylr)
  519. # [23:34] * Quits: Ms2ger (Ms2ger@91.181.219.32) (Quit: nn)
  520. # [23:35] * Quits: ChrisL (ChrisL@128.30.52.169) (Quit: Fire on main board error, client combusted)
  521. # Session Close: Thu Feb 17 00:00:00 2011

The end :)