/irc-logs / w3c / #css / 2012-07-04 / end

Options:

  1. # Session Start: Wed Jul 04 00:00:00 2012
  2. # Session Ident: #css
  3. # [00:10] * Joins: arno (arnog@76.76.241.47)
  4. # [00:33] * Joins: jet (jet@206.15.76.122)
  5. # [01:18] * Joins: miketayl_r (miketaylr@70.112.101.224)
  6. # [01:18] * Quits: miketaylr (miketaylr@70.112.101.224) (Connection reset by peer)
  7. # [01:27] * Quits: drublic (drublic@95.115.7.147) (Client exited)
  8. # [01:27] * Joins: drublic (drublic@95.115.7.147)
  9. # [01:30] * Quits: drublic (drublic@95.115.7.147) (Ping timeout)
  10. # [01:33] * heycam|away is now known as heycam
  11. # [01:38] * Quits: arno (arnog@76.76.241.47) (Quit: Leaving.)
  12. # [02:36] * Quits: dbaron (dbaron@206.15.76.122) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  13. # [02:59] * Quits: tantek (tantek@76.115.51.221) (Quit: tantek)
  14. # [03:07] * Quits: jet (jet@206.15.76.122) (Quit: jet)
  15. # [03:17] * Joins: jdaggett (jdaggett@202.221.217.73)
  16. # [03:17] <jdaggett> fantasai: ping
  17. # [03:30] <fantasai> jdaggett: pong
  18. # [03:30] <jdaggett> so i've finally grokked what's going on with mongolian/phags-pa
  19. # [03:31] <jdaggett> this is really a short-sighted hack that we shouldn't propogate into unicode
  20. # [03:31] <jdaggett> if i was being unkind, i'd say this is standard microsoft behavior
  21. # [03:31] <jdaggett> hack the present, neuter the future
  22. # [03:32] <jdaggett> mongolian/phags-pa, despite being *vertical* scripts, are only defined with horizontal metrics
  23. # [03:32] <jdaggett> (looking at the win8 font examples)
  24. # [03:33] <jdaggett> but this sucks for implementing good vertical layout
  25. # [03:34] <jdaggett> because it will eliminate the chance to kern properly
  26. # [03:34] <jdaggett> 'kern' is the horizontal kerning feature, 'vkrn' the one for vertical
  27. # [03:34] <jdaggett> if text run A and B use different orientation, the ability to kern across those boundaries is lost
  28. # [03:35] <jdaggett> but with correct vertical glyphs and metrics, the correct kerning could be applied
  29. # [03:36] <jdaggett> it's obviously more efficient to store vertical glyphs in horizontal forms and let the layout engine rotate them in
  30. # [03:36] <jdaggett> but that breaks the larger model
  31. # [03:37] <jdaggett> this is something opentype should fix
  32. # [03:37] <jdaggett> by either allowing a transform on a glyph or setting a flag that identified this type of font
  33. # [03:38] <jdaggett> regardless, it's not something that's an intrinsic property of the character
  34. # [03:38] <jdaggett> it's just an expediency used in current implementations
  35. # [03:40] <fantasai> ok
  36. # [03:40] <fantasai> you need more than just vertical kerning, though, you need all the contextual shaping / ligature stuff
  37. # [03:40] <fantasai> that you said was broken atm
  38. # [03:40] <fantasai> anyway, it's not being propagated into Unicode, thanks to the HO property
  39. # [03:40] <fantasai> it's just in our spec right now
  40. # [03:41] <jdaggett> well, it's not broken because they are applying in on horizontal runs
  41. # [03:41] <fantasai> ?
  42. # [03:41] * Liam suspects a different meaning of the word "broken" being used here
  43. # [03:42] <jdaggett> shaping for intra-Mongolian will work
  44. # [03:42] <Liam> expedient-but-not-right vs not-working
  45. # [03:42] <jdaggett> shaping between runs with U vs. R will not
  46. # [03:42] <fantasai> right
  47. # [03:42] <fantasai> but those don't shape anyway
  48. # [03:43] <fantasai> it's the same as end-of-run
  49. # [03:43] <fantasai> We have a general problem with kerning in vertical runs regardless
  50. # [03:43] <jdaggett> no, opentype allows arbitrary substitutions and positionings
  51. # [03:43] <fantasai> due to no cross-run kerning
  52. # [03:43] <fantasai> and there's a lot of U/R boundaries
  53. # [03:44] <fantasai> I don't think it's a problem we can solve atm, it involves the font being able to rotate or not rotate arbitrary punctuation and symbols...
  54. # [03:44] <jdaggett> another way to put this is that the current way that mongolian/phags-pa fonts are implemented is just one way to implement them
  55. # [03:44] <fantasai> yes
  56. # [03:44] <jdaggett> and we should avoid pushing implementation details like this back into a unicode property
  57. # [03:44] <fantasai> the WM spec is written for current fonts
  58. # [03:45] <fantasai> the current Unicode spec is written independent of that
  59. # [03:45] <jdaggett> WM == ?
  60. # [03:45] <fantasai> Writing Modes
  61. # [03:45] <fantasai> Writing Modes combines the HO data with the MVO/SVO data to get at the typeset orientation
  62. # [03:46] <fantasai> but the Unicode spec doesn't do that -- HO is an independent thing
  63. # [03:46] <fantasai> and is tied to the code charts
  64. # [03:46] <jdaggett> um, there's no need for HO data in the current WM spec
  65. # [03:46] <fantasai> there is if we're using existing Mongolian fonts :)
  66. # [03:46] <jdaggett> MVO/SVO = R for Mongolian/Phags-pa
  67. # [03:46] <fantasai> No, it's U
  68. # [03:47] <jdaggett> in tr50-5
  69. # [03:47] <fantasai> It's U
  70. # [03:47] <fantasai> look at 1800 block
  71. # [03:47] <fantasai> SVO=MVO=U
  72. # [03:47] <fantasai> http://www.unicode.org/reports/tr50/tr50-5.Orientation.html
  73. # [03:47] <jdaggett> ah, i was looking at Phags-pa which is U R R
  74. # [03:48] <fantasai> heh
  75. # [03:48] <fantasai> That's an error
  76. # [03:48] <jdaggett> you're right, mongolian is L U U
  77. # [03:48] <fantasai> It was corrected I believe
  78. # [03:48] <fantasai> in one of the telecons
  79. # [03:48] <fantasai> hasn't been propagated out to UTR50 yet
  80. # [03:48] <jdaggett> right
  81. # [03:49] <fantasai> We can't publish WM pointing at such broken data, is the problem.
  82. # [03:49] <fantasai> If we can't publish with fixes, then we can't publish at all
  83. # [03:49] <fantasai> So we have to wait
  84. # [03:50] <jdaggett> well, you know my opinion here: just refer to utr50 and fix utr50
  85. # [03:50] <jdaggett> but i think the underlying layout model that ms is using for mongolian/phags-pa is wrong
  86. # [03:52] <jdaggett> they need to fix the opentype model so that both the model used in existing fonts and one that's more appropriate for good vertical layout
  87. # [03:52] <jdaggett> can be used
  88. # [03:52] * fantasai has no disagreement there
  89. # [03:53] <fantasai> The model for Mongolian that MS has is considerably less broken than previous software, btw.
  90. # [03:53] <fantasai> Apparently some software the glyphs are all mirrored so that you can typeset it and then mirror the result
  91. # [03:53] <fantasai> and fun things like that :)
  92. # [03:54] <jdaggett> yeah
  93. # [03:54] <fantasai> But I guess now that you know Mongolian is U
  94. # [03:54] <fantasai> you can understand why we need to combine the data with HO :)
  95. # [03:54] <fantasai> Putting Mongolian U was to keep the Unicode data independent of font implementations
  96. # [03:55] <jdaggett> but using the HO data is locking in the existing model
  97. # [03:55] <jdaggett> so that's a bad idea
  98. # [03:55] <fantasai> That's a consideration for our spec, not for UTR50
  99. # [03:55] <jdaggett> better to simply describe the situation in a note advising implementations
  100. # [03:56] <jdaggett> sure
  101. # [03:56] <jdaggett> but we shouldn't lock in this model or treat this model as the "only" way
  102. # [03:56] <fantasai> I'm happy to say there are other ways, but not happy to make this behavior non-normative if it's the only one that will work correctly in the current situation
  103. # [03:57] <fantasai> It's a similar issue to brackets. They're fundamentally R by Unicode perspective
  104. # [03:57] <fantasai> but we typeset them upright with vert
  105. # [03:57] <fantasai> Because OpenType fonts are written to that assumption
  106. # [03:58] <fantasai> It seems to me OpenType isn't really set up to handle typesetter-chosen orientations
  107. # [03:58] <fantasai> very well
  108. # [03:58] <fantasai> but it's not something I can fix right now.
  109. # [03:59] <jdaggett> i think we first need to get peter constable on board
  110. # [03:59] <jdaggett> with the notion that this isn't the ideal way to do layout for these scripts
  111. # [04:00] <fantasai> Even so, we still have to handle the present
  112. # [04:00] <jdaggett> then we can talk about the appropriate way to address the problem in opentype
  113. # [04:00] <fantasai> We can't write the spec to only handle the far future
  114. # [04:01] <fantasai> Handling both the future and the present is good
  115. # [04:01] <jdaggett> well, you can still use the hacky heuristic
  116. # [04:01] <fantasai> ?
  117. # [04:01] <jdaggett> if only hmetrics, font contains an internal rotation
  118. # [04:01] <jdaggett> else it's the transform is assumed to be the identity transform
  119. # [04:01] <jdaggett> for the mongolian/phags-pa cases
  120. # [04:02] <jdaggett> this deals with existing behavior but allows for the "right" behavior in the future
  121. # [04:03] <fantasai> ok
  122. # [04:03] <fantasai> um
  123. # [04:03] <fantasai> can you write me a handful of spec sentences? :)
  124. # [04:03] <jdaggett> yeah
  125. # [04:03] * fantasai will try to incorporate them into the spec
  126. # [04:03] <jdaggett> but like i say, we'll need to get buy-in from the ms folks
  127. # [04:03] <fantasai> doesn't have to be perfect, just to give me a better idea of what we're aiming at
  128. # [04:04] <jdaggett> ok
  129. # [04:04] <fantasai> IIRC there was ligatures problem, too, for vertical text and OpenType?
  130. # [04:04] <fantasai> I think all those kinds of problems need to be solved before we can get Mongolian to work as upright
  131. # [04:05] <jdaggett> the question is what are the set of default features for vertical runs (i.e. U runs)
  132. # [04:05] <jdaggett> there's nothing that clearly defines this
  133. # [04:05] <jdaggett> one can infer that kern is not but vkrn is
  134. # [04:05] <jdaggett> but that's not actually documented anywhere
  135. # [04:06] <jdaggett> in the horizontal case 'liga' (common ligatures) is on by default
  136. # [04:06] <jdaggett> the question is what happens in the vertical case
  137. # [04:07] <jdaggett> I think the thinking of Eric/Peter C/Behdad was that features should have flags on them
  138. # [04:07] <jdaggett> to indicate vertical-only, horizontal-only
  139. # [04:07] <jdaggett> which would allow different mappings for the vertical/horizontal cases
  140. # [04:09] <glenn> glad 2 see u guys r fixing OT and Unicode both :)
  141. # [04:09] <jdaggett> my head hurts...
  142. # [04:09] <jdaggett> ;)
  143. # [04:10] <fantasai> is there not a vlig feature?
  144. # [04:10] <fantasai> or something like that?
  145. # [04:10] <fantasai> oh
  146. # [04:10] <fantasai> right
  147. # [04:10] <jdaggett> nope
  148. # [04:10] <fantasai> there's lots of different ligature things...
  149. # [04:10] <jdaggett> that's a different way to approach the problem
  150. # [04:10] <fantasai> you'd have to make up v-names for all of them :P
  151. # [04:10] <jdaggett> yup, that's exactly the problem with that approach
  152. # [04:10] <jdaggett> the flags solution is cleaner in that respect
  153. # [04:11] <glenn> i like the idea of having H and V flags on OT lookup tables, similar to how there is already RightToLeft flag (not that this particular flag has ever been used)
  154. # [04:12] <jdaggett> yes, that was exactly the pattern this idea came from
  155. # [04:12] <glenn> of course, the Ignore{BaseGlyphs,Marks} are certainly used
  156. # [04:13] <jdaggett> there was a discussion of this on the OT list a few months ago
  157. # [04:13] <glenn> maybe we can call them IgnoreHorizontal and IgnoreVertical, meaning don't apply in those contexts
  158. # [04:13] <jdaggett> that sounds right
  159. # [04:13] <glenn> as opposed to a flag that says enable in some context (like RightToLeft flat)
  160. # [04:14] <glenn> s/flat/flag/
  161. # [04:14] <jdaggett> existing apps would take all of them but meh...
  162. # [04:17] <jdaggett> fantasai: so i'll try up a description of what i see as problematic
  163. # [04:17] <jdaggett> fantasai: with pictures
  164. # [04:18] <jdaggett> and post to the opentype group about the problems with the underlying model
  165. # [04:20] <fantasai> jdaggett: I understand that kerning's an issue across runs, if that's what you're worried about :)
  166. # [04:21] <jdaggett> well, kerning is the simplest to explain
  167. # [04:23] * Quits: dstorey (Adium@144.189.101.1) (Quit: Leaving.)
  168. # [04:24] <jdaggett> but other substitution or positioning features wouldn't work either
  169. # [04:25] <jdaggett> e.g. adjusting punctuation when it's preceded by a given punctuation character
  170. # [04:27] <jdaggett> er, adjusting punctuation surrounding specific mongolian characters
  171. # [04:31] <fantasai> jdaggett: it seems to me that half the punctuation is rotated and half of it is upright
  172. # [04:32] <fantasai> jdaggett: so it's not clear that setting mongolian upright vs rotated would be a win
  173. # [04:32] <fantasai> jdaggett: it depends on whether your mixing it more with Chinese or Cyrillic
  174. # [04:32] * fantasai notes that Mongolian is alternately written in Cyrillic
  175. # [04:33] <fantasai> jdaggett: you need a solution to breaking runs, generally, to solve this problem well
  176. # [04:34] * Quits: miketayl_r (miketaylr@70.112.101.224) (Quit: dflk;adfslkj;alsiekfj;laiskdf)
  177. # [04:35] * heycam is now known as heycam|away
  178. # [04:36] * Joins: miketaylr (miketaylr@70.112.101.224)
  179. # [04:40] <jdaggett> i'm not pretending to know much about patterns of mongolian usage
  180. # [04:40] <jdaggett> i just think the model needs to be kept clean and not sullied with hacks that ripple out into all sorts of places
  181. # [04:42] <fantasai> It's probably about as much of a hack as rotating Latin is right now :)
  182. # [04:43] <fantasai> That has the same problems.
  183. # [04:44] <jdaggett> you're thinking of alignment?
  184. # [04:44] <fantasai> and kerning
  185. # [04:44] <fantasai> and everything else
  186. # [04:44] <jdaggett> true
  187. # [04:44] <jdaggett> which is why the vrt2 model is the ideal one
  188. # [04:45] <fantasai> the problem with that is that the font decides which characters to rotate and which not
  189. # [04:45] <fantasai> which might be something you want as an option
  190. # [04:45] <jdaggett> yup
  191. # [04:45] <fantasai> but other people want to decide the rotation explicitly
  192. # [04:45] <fantasai> so you want vrt2 with per-glyph feature tweaking somehow... to say "no, I want this upright " or "no, I want this sideways"
  193. # [04:46] * fantasai doesn't know if that's possible
  194. # [04:46] <fantasai> does changing OpenType features break a run?
  195. # [04:47] <jdaggett> yes but you still have context available (or you should, not saying our implementation is 100% correct)
  196. # [04:47] <fantasai> ok
  197. # [04:48] <jdaggett> fonts have a max context field
  198. # [04:48] <jdaggett> which let's the implementation know how far back a lookup might be needed
  199. # [04:49] <fantasai> nice
  200. # [04:58] * heycam|away is now known as heycam
  201. # [05:32] * Joins: dstorey (Adium@67.180.84.179)
  202. # [05:46] * Joins: tantek (tantek@173.164.85.85)
  203. # [06:10] * Joins: jet (jet@24.5.42.61)
  204. # [06:24] * Quits: jet (jet@24.5.42.61) (Quit: jet)
  205. # [06:59] * Quits: tantek (tantek@173.164.85.85) (Quit: tantek)
  206. # [07:01] * Quits: miketaylr (miketaylr@70.112.101.224) (Quit: dflk;adfslkj;alsiekfj;laiskdf)
  207. # [07:32] * Joins: tantek (tantek@76.115.51.221)
  208. # [09:48] * Joins: florianr (florianr@91.203.97.251)
  209. # [10:08] * Joins: drublic (drublic@95.115.33.68)
  210. # [10:11] * Quits: drublic (drublic@95.115.33.68) (Ping timeout)
  211. # [10:24] * Quits: tantek (tantek@76.115.51.221) (Quit: tantek)
  212. # [10:45] * Joins: drublic (drublic@93.132.252.175)
  213. # [10:58] * Quits: dstorey (Adium@67.180.84.179) (Quit: Leaving.)
  214. # [11:06] * Quits: glenn (gadams@174.29.112.73) (Client exited)
  215. # [11:08] * Joins: glenn (gadams@174.29.112.73)
  216. # [11:08] * Quits: glenn (gadams@174.29.112.73) (Client exited)
  217. # [11:14] * Joins: Ms2ger (Ms2ger@91.181.79.187)
  218. # [11:19] * heycam is now known as heycam|away
  219. # Session Close: Wed Jul 04 14:32:19 2012
  220. #
  221. # Session Start: Wed Jul 04 14:32:19 2012
  222. # Session Ident: #css
  223. # [14:32] * Disconnected
  224. # [14:34] * Attempting to rejoin channel #css
  225. # [14:34] * Rejoined channel #css
  226. # [16:58] * Joins: glenn (gadams@174.29.112.73)
  227. # [17:54] * Joins: jet (jet@67.169.43.128)
  228. # [17:56] * Quits: jet (jet@67.169.43.128) (Quit: jet)
  229. # [17:59] <fantasai> HEY EVERYONE I just updated the DoCs for css3-values and css3-flexbox
  230. # [17:59] <fantasai> http://dev.w3.org/csswg/css3-flexbox/issues-lc-2012
  231. # [17:59] <fantasai> http://dev.w3.org/csswg/css3-values/issues-lc-2012
  232. # [17:59] <fantasai> last issue added to values,
  233. # [17:59] <fantasai> issues 8-12 added to flexbox
  234. # [17:59] * sylvaing_away is now known as sylvaing
  235. # [17:59] * fantasai waves to sylvaing
  236. # [18:00] * fantasai will be back in 12 minutes or so, please find some other minute taker today since I'll be talking?
  237. # [18:00] * sylvaing waves back
  238. # [18:01] * Joins: jet (jet@67.169.43.128)
  239. # [18:03] * Quits: jet (jet@67.169.43.128) (Quit: jet)
  240. # [18:04] * Joins: dstorey (Adium@67.180.84.179)
  241. # [18:05] * Joins: oyvind (oyvinds@91.203.97.251)
  242. # [18:06] * Joins: florian (florianr@91.203.96.240)
  243. # [18:07] * Joins: antonp (50ae8432@109.169.29.95)
  244. # [18:07] * Joins: koji (koji@222.158.227.129)
  245. # [18:08] * Joins: Zakim (rrs-bridgg@128.30.52.169)
  246. # [18:08] * Joins: smfr (smfr@173.228.90.242)
  247. # [18:08] <Ms2ger> fantasai, the legend for the color coding isn't consistent :)
  248. # [18:08] * Joins: RRSAgent (rrs-loggee@128.30.52.169)
  249. # [18:08] <RRSAgent> logging to http://www.w3.org/2012/07/04-css-irc
  250. # [18:08] <plinss> zakim, this is style
  251. # [18:08] <Zakim> ok, plinss; that matches Style_CSS FP()12:00PM
  252. # [18:08] * Joins: CesarAcebal (acebal@85.152.178.157)
  253. # [18:08] <Zakim> +smfr
  254. # [18:09] <Zakim> +??P9
  255. # [18:09] <Zakim> + +47.23.69.aaaa
  256. # [18:09] <florian> Zakim, I am aaaa
  257. # [18:09] <Zakim> +florian; got it
  258. # [18:09] <glenn> zakim, ??p9 is glenn
  259. # [18:09] <Zakim> +glenn; got it
  260. # [18:09] <Zakim> +??P5
  261. # [18:09] * Joins: dbaron (dbaron@70.36.140.99)
  262. # [18:09] <Zakim> + +34.60.940.aabb
  263. # [18:10] <CesarAcebal> zakim, aabb is me
  264. # [18:10] <Zakim> +CesarAcebal; got it
  265. # [18:10] <Zakim> +dbaron
  266. # [18:10] <Zakim> +antonp
  267. # [18:13] * Joins: SteveZ (chatzilla@76.126.187.234)
  268. # [18:13] <Zakim> + +1.415.285.aacc
  269. # [18:13] <hober> Zakim, aacc is me
  270. # [18:13] <Zakim> +hober; got it
  271. # [18:14] <Zakim> +fantasai
  272. # [18:14] <Zakim> +SteveZ
  273. # [18:16] <smfr> scribenick: smfr
  274. # [18:16] <Zakim> +[Microsoft]
  275. # [18:17] <fantasai> http://dev.w3.org/csswg/css3-values/issues-lc-2012
  276. # [18:17] <smfr> TOPIC: values and units issues
  277. # [18:17] <smfr> fantasai: issue 18: defining an always invalid url
  278. # [18:17] <smfr> fantasai: computed value of an attr with no default value is UA specific; need to choose something
  279. # [18:17] <smfr> proposal: about:invalid
  280. # [18:18] <smfr> http://dev.w3.org/csswg/css3-values/issues-lc-2012#issue-18
  281. # [18:18] * Joins: Rossen (Rossen@98.225.38.50)
  282. # [18:18] <smfr> fantasai: comments?
  283. # [18:18] <smfr> florian: no strong opinion, but why not?
  284. # [18:18] <fantasai> http://lists.w3.org/Archives/Public/www-style/2012Jun/0689.html
  285. # [18:19] <smfr> dbaron: does the URL in question have to reparse correctly?
  286. # [18:19] <dbaron> s/does/is it ok that/
  287. # [18:19] <smfr> dbaron: so that it could be specified
  288. # [18:19] <smfr> fantasai: i don't know
  289. # [18:19] <fantasai> http://dev.w3.org/csswg/css3-values/#attr-notation
  290. # [18:19] <smfr> fantasai: (reads from the spec)
  291. # [18:20] <fantasai> attr(foo url)
  292. # [18:20] <fantasai> what's the default if there's no foo attribute?
  293. # [18:20] <fantasai> atm it's UA-defined
  294. # [18:20] <fantasai> comment was to define something
  295. # [18:20] <fantasai> we can either leave UA-defined or return 'about:invalid'
  296. # [18:20] <smfr> dbaron: we return it in computed style for urls that failed the url parser
  297. # [18:20] <smfr> dbaron: but we use a different url string
  298. # [18:20] <smfr> dbaron: we're ok switching to this
  299. # [18:21] <smfr> fantasai: any other comments?
  300. # [18:21] <smfr> RESOLVED: use about:invalid as url as the default url in attr()
  301. # [18:21] <fantasai> http://dev.w3.org/csswg/css3-values/issues-lc-2012#issue-25
  302. # [18:22] <fantasai> http://dev.w3.org/csswg/css3-values/#limits
  303. # [18:22] <smfr> florian: there was mailing list discussion
  304. # [18:23] <smfr> dbaron: my feeling is that most of the prose is defining things that I suspect may not be correct
  305. # [18:23] <smfr> dbaron: we are better of postponing this
  306. # [18:23] <smfr> florian: i agree; the intent is good, but lots of trick edge cases
  307. # [18:23] <smfr> florian: would require changes to engines
  308. # [18:25] <smfr> smfr: we don't like the special "close to integer" behavior
  309. # [18:25] <smfr> florian: i don't want to have to do math differently because of htis
  310. # [18:25] <smfr> s/htis/this
  311. # [18:25] <smfr> florian: i don't like the parsing but am willing to do it
  312. # [18:26] <smfr> fantasai: do we want to defer the min/max, or just the prevision and rounding?
  313. # [18:26] <smfr> sylvaing: rounding is controversial, rounding is less so
  314. # [18:26] <smfr> florian: we're still at 25 bits, the intent was 24 bits
  315. # [18:27] <smfr> fantasai: is the 17 correct?
  316. # [18:27] <smfr> florian: for us it's fine
  317. # [18:27] <sylvaing> correction: rounding is controversial but min/max isn't
  318. # [18:28] <smfr> florian: min/max is the safest bit, fine with deferring the whole thing
  319. # [18:28] <smfr> dbaron: ok with the table, would postpone the prose below
  320. # [18:28] <smfr> sylvaing: postponing the whole thing is easiest
  321. # [18:28] <dbaron> s/ok with the table, would/what I was arguing for earlier was to/
  322. # [18:29] <smfr> smfr: do we still have prose about round-tripping values?
  323. # [18:29] <smfr> florian: would still like responses even if it's postponed
  324. # [18:30] <smfr> RESOLVED: defer Appendix A of Values and Units
  325. # [18:30] <fantasai> http://dev.w3.org/csswg/css3-values/issues-lc-2012#issue-28
  326. # [18:30] <fantasai> Proposed to defer to L4
  327. # [18:30] <smfr> fantasai: are there any other proposals?
  328. # [18:30] <smfr> dbaron: postponing is fine
  329. # [18:31] <smfr> RESOLVED: defer issue 28
  330. # [18:31] <fantasai> http://dev.w3.org/csswg/css3-values/issues-lc-2012#issue-29
  331. # [18:31] <smfr> plinss: this may raise an objection from i18n
  332. # [18:31] <fantasai> http://lists.w3.org/Archives/Public/www-style/2012May/0499.html
  333. # [18:32] <smfr> fantasai: identifiers are case-insensitive, but author-defined counter styles are allowed
  334. # [18:33] <smfr> fantasai: describes 3 options in http://lists.w3.org/Archives/Public/www-style/2012May/0499.html
  335. # [18:34] <smfr> florian: option for 1 is to say that @counter-style name are case insensitive in ASCII range only
  336. # [18:35] <smfr> fantasai: proposal to have two kinds of author-defined identifiers; case sensitive and ASCII-case insensitive
  337. # [18:35] <smfr> plinss: don't like the inconsistency
  338. # [18:35] <smfr> florian: we'll have an inconsistency somewhere
  339. # [18:36] <smfr> fantasai: 4th proposal might be to have in css3 all user-defined idents are case-insensitive in the ASCII range
  340. # [18:36] <smfr> probably web compatible but a change from CSS 2.1
  341. # [18:37] <smfr> florian: how much web breakage?
  342. # [18:37] <smfr> fantasai: not much
  343. # [18:37] <smfr> florian: may break because of typos
  344. # [18:37] <smfr> antonp: erring towards proposal 3
  345. # [18:37] <smfr> fantasai: we will probably do this for some other properties like text-transform
  346. # [18:38] <smfr> plinss: like the idea of making them all ASCII-range case insensitive
  347. # [18:38] <smfr> florian: easier to fix now than later
  348. # [18:38] <smfr> dbaron: could be confusing for authors
  349. # [18:38] <dbaron> case-insensitive in the ascii range could be confusing for authors who use non-ascii characters
  350. # [18:39] <smfr> plinss: option 3 sounds a bit hacky
  351. # [18:40] <smfr> sylvaing: how base is unicode case-folding?
  352. # [18:40] <smfr> fantasai: there's a generic version but it's a source of bugs (if UAs call locale-specific routines by mistake)
  353. # [18:40] <sylvaing> s/base/bad
  354. # [18:41] <plinss> zakim, who is noisy?
  355. # [18:41] <smfr> fantasai: only css keywords will get case permutations
  356. # [18:41] <Zakim> plinss, listening for 11 seconds I heard sound from the following: sylvaing (52%), SteveZ (21%)
  357. # [18:41] <smfr> Zakim: mute SteveZ
  358. # [18:42] <smfr> florian: we already have this code elsewhere
  359. # [18:42] <smfr> fantasai: yes, for text-transform
  360. # [18:42] <smfr> sylvaing: you're breaking up
  361. # [18:42] <fantasai> sylvaing: Are we looking at a situation where it'll take a few releases to get right and it affects lots of people, or it affects only a few people
  362. # [18:42] <smfr> dbaron: there's a performance cost
  363. # [18:43] <smfr> florian: or you convert to lowercase
  364. # [18:43] <smfr> fantasai: you say that the computed value is the case-folded value
  365. # [18:43] <smfr> sylvaing: was asking if the complexity was worth the inconsistency
  366. # [18:44] <smfr> florian: does anyone dislike this?
  367. # [18:44] <smfr> dbaron: would want to go back and look at why we changed this for 2.1
  368. # [18:45] <smfr> dbaron: there were things that were originally case-insensitive and we changed them to case sensitive
  369. # [18:45] <smfr> fantasai: there are some things that would case-fold into the ascii range, and we didn't' want that
  370. # [18:46] <smfr> florian: can we temporarily resolve?
  371. # [18:46] <smfr> fantasai: we could defer author identifier types from level 3?
  372. # [18:46] <smfr> florian: this would go in CR now?
  373. # [18:46] <smfr> fantasai: author ident is not actually used anywhere
  374. # [18:47] <smfr> smfr: aren't animation names author idents?
  375. # [18:47] <smfr> fantasai: yes
  376. # [18:47] <smfr> plinss: i think we should do this in level 3
  377. # [18:47] <smfr> http://lists.w3.org/Archives/Public/www-style/2012May/0499.html
  378. # [18:47] <fantasai> http://lists.w3.org/Archives/Public/www-style/2012May/0499.html
  379. # [18:47] <smfr> dbaron: i would prefer one of the other options
  380. # [18:48] <smfr> florian: we've been proposing 1a for all ...
  381. # [18:48] <smfr> dbaron: i don't think we should reopen the whole case sensitivity discussion
  382. # [18:48] <smfr> plinss: we'll have more places where authors can define things; will be a source of confusion
  383. # [18:49] <smfr> dbaron: want text with references and citations if we go for one of the 1) options
  384. # [18:49] <smfr> and a week to review
  385. # [18:49] <fantasai> http://unicode.org/Public/UNIDATA/CaseFolding.txt
  386. # [18:50] <smfr> fantasai: i can spec it but am concerned about computed values being lowercased
  387. # [18:50] <smfr> fantasai: i will try to spec that
  388. # [18:50] <smfr> dbaron: why didn't we choose this option for 2.1?
  389. # [18:51] <smfr> fantasai: there were no places where author keywords and UA keywords were mixed up
  390. # [18:52] * Parts: antonp (50ae8432@109.169.29.95)
  391. # [18:52] <smfr> smfr: describes issue with animation names
  392. # [18:52] <smfr> authors have to be able to do the same case-folding in JS to compare animation names
  393. # [18:53] * Joins: antonp (50ae8432@109.169.29.95)
  394. # [18:53] <smfr> keyword idents show up in animation events
  395. # [18:53] * Quits: antonp (50ae8432@109.169.29.95) (Quit: http://www.mibbit.com ajax IRC Client)
  396. # [18:53] <smfr> plinss: we'd need a JS function
  397. # [18:53] * Joins: antonp (50ae8432@207.192.75.252)
  398. # [18:53] <smfr> sylvaing: hard to introduce a new function for this
  399. # [18:54] <smfr> dbaron: i don't think parse-time folding is web compatible, because we've never done that before
  400. # [18:54] <smfr> florian: other options are 2 and 3
  401. # [18:55] <smfr> fantasai: 2 is weird, 3 maybe makes more sense
  402. # [18:56] <smfr> plinss: issues with option 1 are the same issues we've run into with unicode normalization
  403. # [18:56] <smfr> plinss: we'll have to deal with that anyway
  404. # [18:56] <SteveZ> does not 3 have all the string matching problems of 1 and 2.
  405. # [18:57] <smfr> plinss: i don't think that case-folding at parse time is the right thing
  406. # [18:57] <smfr> it should happen at comparison time
  407. # [18:57] <smfr> florian: but that's an issue in JS
  408. # [18:57] * fantasai is sad we spent the entire 4th of July telecon on casing :(
  409. # [18:57] * sylvaing my bad...
  410. # [18:57] <smfr> dbaron: authors aren't going to understand
  411. # [18:57] <SteveZ> and not even shell casings!!
  412. # [18:58] <smfr> plinss: would like to see a plan to resolve this
  413. # [18:59] <SteveZ> It seems to me that the issues are (a) string matching, both in CSS and in Javascript and (b) round tripping of Identifiers in serialization
  414. # [18:59] <smfr> plinss: would dbaron be willing to review some new text defining option 1 with new stuff
  415. # [18:59] <smfr> dbaron: i would
  416. # [18:59] <fantasai> http://dev.w3.org/csswg/css3-values/issues-lc-2012#issue-35
  417. # [18:59] <dbaron> s/i would/it's option 1 plus a lot of other things. But I would./
  418. # [19:00] <fantasai> whether calc should make whitespace optional around + -
  419. # [19:00] <smfr> fantasai: because - forms part of an ident
  420. # [19:00] <smfr> rejected because it means you can't put keywords in calc in future
  421. # [19:00] <fantasai> http://lists.w3.org/Archives/Public/www-style/2012May/0463.html
  422. # [19:00] <Zakim> -antonp
  423. # [19:01] <fantasai> proposal: no change, white space is required
  424. # [19:01] <smfr> fantasai: saying no change to calc, whitespace is required around + and -
  425. # [19:01] <smfr> hober: why not require it around / and * for consistency
  426. # [19:01] <smfr> fantasai: they don't need it
  427. # [19:01] <smfr> smfr: hard for authors to remember where to put whitespace
  428. # [19:02] * antonp has a phone connectivity problem right now...
  429. # [19:02] <fantasai> fantasai: just put white space everywhere
  430. # [19:03] <fantasai> fantasai: */ bind tigheter than + and - , so the current requirements make sense
  431. # [19:03] <smfr> dbaron: gecko implements what the spec says
  432. # [19:03] * Quits: SteveZ (chatzilla@76.126.187.234) (Ping timeout)
  433. # [19:04] <smfr> RESOLVED: accept the rejection of this issue
  434. # [19:04] <smfr> plinss: do we want to require whitespace around / and *?
  435. # [19:04] <smfr> dbaron/fantasai/florian: do not want
  436. # [19:04] <oyvind> so the summary of issue 35 seems wrong - "should allow white space" should really say "shouldn't require white space" or something?
  437. # [19:04] <fantasai> yeah, I'll fix it
  438. # [19:05] <smfr> RESOLVED: leave the rest alone
  439. # [19:05] <fantasai> http://dev.w3.org/csswg/css3-flexbox/issues-lc-2012
  440. # [19:05] <smfr> fantasai: issue links are 404s: http://dev.w3.org/csswg/css3-flexbox/issue-11
  441. # [19:05] * fantasai will fix
  442. # [19:06] <dbaron> Issue 11 has a typo in the name of the commenter
  443. # [19:06] <fantasai> http://lists.w3.org/Archives/Public/www-style/2012Jun/0668.html
  444. # [19:06] <smfr> Issue 5: painting atomically: decided to reject
  445. # [19:07] <smfr> dbaron: they should do what inline-block and inline-tables do
  446. # [19:07] <smfr> fantasai: or should they do what table cells do?
  447. # [19:07] <smfr> appendix E doesn't say what table cells do
  448. # [19:08] <smfr> fantasai: how about we resolve to have them do what table cells do?
  449. # [19:08] <smfr> dbaron: not confident that 2.1 Appendix E is correct for table cells
  450. # [19:09] <smfr> ACTION: dbaron to review appendix E and table cells, in relation to flexbox
  451. # [19:09] * trackbot noticed an ACTION. Trying to create it.
  452. # [19:09] * RRSAgent records action 1
  453. # [19:09] <trackbot> Created ACTION-482 - Review appendix E and table cells, in relation to flexbox [on David Baron - due 2012-07-11].
  454. # [19:09] * sylvaing unicode casing and appendix E. is this july 4th or death wish day?
  455. # [19:09] * hober hahahhaha
  456. # [19:09] <smfr> issue 4: 'order' might be too generic a name
  457. # [19:09] <antonp> Agree with dbaron, not at all sure Appendix E handles table stuff well
  458. # [19:10] <antonp> Some bugs are open on that
  459. # [19:10] <smfr> issue 3: does 'order' affect speech and tab order
  460. # [19:10] <smfr> point of order is to change visual order, not order for speech etc.
  461. # [19:10] <dbaron> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0A%23a%20div%20%7B%20background%3A%20aqua%3B%20color%3A%20blue%3B%20margin-right%3A%20-1em%20%7D%0A%23b%20div%20%7B%20background%3A%20yellow%3B%20color%3A%20brown%3B%20margin-left%3A%20-1em%20%7D%0A%3C%2Fstyle%3E%0A%3Ctable%3E%3Ctr%3E%0A%3Ctd%20id%3D%22a%22%3E%3Cdiv%3Ehello%3C%2Fdiv%3E%3C%2Ftd%3E%0A%3Ctd%20id%3D%22b%22%3E%3Cdiv%3Ehello%3C%2Fdiv%3E%3C%2Ftd%3E%0A%3C%2Ftr%3E%
  462. # [19:10] <dbaron> 3C%2Ftable%3E shows 2.1 appendix E is actually correct for table cells
  463. # [19:10] <smfr> fantasai: but if it's just paint order, should it have a more specific name
  464. # [19:11] <dbaron> but I rather prefer the float/inline-block behavior
  465. # [19:11] <smfr> plinss: makes sense to have a more specific name
  466. # [19:11] <smfr> florian: we need to resolve issue 3 first
  467. # [19:11] <fantasai> http://lists.w3.org/Archives/Public/www-style/2012Jul/0046.html
  468. # [19:12] <smfr> florian: was john folio fine with the proposal?
  469. # [19:12] <smfr> fantasai: he didn't have a strong opinion
  470. # [19:13] <fantasai> Foliot's response: http://lists.w3.org/Archives/Public/www-style/2012Jun/0481.html
  471. # [19:13] <smfr> s/folio/foliot
  472. # [19:13] <fantasai> http://dev.w3.org/csswg/css3-flexbox/#overview
  473. # [19:13] <fantasai> http://dev.w3.org/csswg/css3-flexbox/#order-property
  474. # [19:13] <dbaron> also all the "#" links in the DoC are broken
  475. # [19:14] * fantasai knows, will fix
  476. # [19:14] <smfr> fantasai gives order examples
  477. # [19:15] <smfr> RESOLVED: issue 3; order does not affect tab order or speech order
  478. # [19:15] <smfr> plinss: should we change the name to display-order?
  479. # [19:16] <fantasai> smfr: I agree with the name change
  480. # [19:16] <smfr> RESOLVED: rename 'order' to something more specific
  481. # [19:16] <smfr> fantasai: box-order or display-order
  482. # [19:17] <smfr> florian: display-order looks like a longhand for display, don't like
  483. # [19:17] <smfr> plinss: other option is flex-order
  484. # [19:17] <smfr> florian: or visual-order
  485. # [19:18] <smfr> dbaron: it sounds like z-order
  486. # [19:18] <smfr> (which is z-index)
  487. # [19:18] <Zakim> -smfr
  488. # [19:18] <glenn> is visual order same as reading order?
  489. # [19:18] <smfr> gah, call dropped
  490. # [19:18] <fantasai> hober: paint-order?
  491. # [19:18] <dbaron> fantasai: display-order implies affecting paint order too; I understand the longhand issue but I think we should go with that
  492. # [19:18] <smfr> it must be past 10...
  493. # [19:18] <fantasai> ScribeNick: fantasai
  494. # [19:19] * smfr can't call back in
  495. # [19:19] <fantasai> florian proposes straw-polling
  496. # [19:19] * fantasai will minute for you
  497. # [19:19] <fantasai> someone asks to move to next week
  498. # [19:19] <dbaron> Rossen: Alex had an opinion, but not sure what it was
  499. # [19:19] * Joins: SteveZ (chatzilla@76.126.187.234)
  500. # [19:19] <fantasai> Meeting closed.
  501. # [19:20] <dbaron> We might have 'order' committed to the tree by next week
  502. # [19:20] <Zakim> -hober
  503. # [19:20] <Zakim> -glenn
  504. # [19:20] <Zakim> -florian
  505. # [19:20] <Zakim> -plinss
  506. # [19:20] * Quits: SteveZ (chatzilla@76.126.187.234) (Quit: ChatZilla 0.9.88.2 [Firefox 13.0.1/20120614114901])
  507. # [19:20] <Zakim> -dbaron
  508. # [19:20] <Zakim> -CesarAcebal
  509. # [19:20] <Zakim> -[Microsoft]
  510. # [19:20] <Zakim> -sylvaing
  511. # [19:20] * Quits: smfr (smfr@173.228.90.242) (Quit: smfr)
  512. # [19:20] * Parts: CesarAcebal (acebal@85.152.178.157)
  513. # [19:20] <Zakim> -??P5
  514. # [19:20] <Rossen> Zakim, [Microsoft] is me
  515. # [19:20] <Zakim> sorry, Rossen, I do not recognize a party named '[Microsoft]'
  516. # [19:22] <Zakim> -SteveZ
  517. # [19:23] * Quits: koji (koji@222.158.227.129) (Quit: Leaving...)
  518. # [19:27] <Zakim> disconnecting the lone participant, fantasai, in Style_CSS FP()12:00PM
  519. # [19:27] <Zakim> Style_CSS FP()12:00PM has ended
  520. # [19:27] <Zakim> Attendees were sylvaing, plinss, smfr, +47.23.69.aaaa, florian, glenn, +34.60.940.aabb, CesarAcebal, dbaron, antonp, +1.415.285.aacc, hober, fantasai, SteveZ, [Microsoft]
  521. # [19:27] <fantasai> sylvaing: On the plus side, LC closed yesterday, so there will be no more issues
  522. # [19:27] <fantasai> sylvaing: and therefore no more renaming :p
  523. # [19:28] <fantasai> sylvaing: but still, >_____<;;;;;;
  524. # [19:29] * fantasai DoCs are hard, lets make pretty diagrams~
  525. # [19:29] * fantasai works on updating the DoC
  526. # [19:32] * Quits: antonp (50ae8432@207.192.75.252) (Quit: http://www.mibbit.com ajax IRC Client)
  527. # [19:39] * Parts: oyvind (oyvinds@91.203.97.251)
  528. # [19:39] <dbaron> fantasai, mind if I fix some typos in the DoC's, or are you editing?
  529. # [19:40] <fantasai> I'm editing values atm
  530. # [19:41] <fantasai> but not flexbox, so go ahead
  531. # [19:41] <fantasai> pull first, though :)
  532. # [19:42] <dbaron> ok, done
  533. # [19:42] <fantasai> thanks~
  534. # [19:45] * Parts: florian (florianr@91.203.96.240)
  535. # [19:47] <fantasai> ok, pushed out edits and DoC updates
  536. # [19:47] * fantasai will deal with minutes later, kindof want breakfast
  537. # [19:48] * Quits: Rossen (Rossen@98.225.38.50) (Quit: Rossen)
  538. # [19:50] <dbaron> fantasai, ok, I pushed one typo fix to the values DoC now
  539. # [20:12] * Quits: SimonSapin (simon@82.232.219.95) (Ping timeout)
  540. # [20:20] * fantasai pulls
  541. # [20:47] * Quits: drublic (drublic@93.132.252.175) (Client exited)
  542. # [20:47] * Joins: drublic (drublic@93.132.252.175)
  543. # [20:48] * Joins: drublic_ (drublic@93.132.252.175)
  544. # [20:48] * Quits: drublic (drublic@93.132.252.175) (Connection reset by peer)
  545. # [20:51] * Quits: drublic_ (drublic@93.132.252.175) (Ping timeout)
  546. # [21:04] <fantasai> Ms2ger: fixed, if I understood correctly
  547. # [21:05] <Ms2ger> You did
  548. # [21:26] <fantasai> glenn: just caught your IRC question now
  549. # [21:26] <fantasai> glenn: That depends on whether you're using a visual navigation or a logical one
  550. # [21:27] <fantasai> glenn: but the expectation is that a document that is being read from start to finish
  551. # [21:27] <fantasai> glenn: will follow logical order, i.e. the source order
  552. # [21:34] * Zakim excuses himself; his presence no longer seems to be needed
  553. # [21:34] * Parts: Zakim (rrs-bridgg@128.30.52.169)
  554. # [22:05] * Quits: dstorey (Adium@67.180.84.179) (Quit: Leaving.)
  555. # [22:16] * Quits: Ms2ger (Ms2ger@91.181.79.187) (Quit: nn)
  556. # [22:21] * sylvaing is now known as sylvaing_away
  557. # [22:46] * Joins: drublic (drublic@95.115.33.68)
  558. # Session Close: Thu Jul 05 00:00:00 2012

The end :)