/irc-logs / w3c / #css / 2015-05-19 / end

Options:

Previous day, Next day

  1. # Session Start: Tue May 19 00:00:01 2015
  2. # Session Ident: #css
  3. # [00:00] * Quits: smfr (~smfr@public.cloak) (smfr)
  4. # [00:00] <gregwhitworth> RESOLUTION: Bring back elements for snap points. Once it is specificed, it will be the box that traps all snap points
  5. # [00:01] * Joins: smfr (~smfr@public.cloak)
  6. # [00:01] <fantasai> Meeting adjourned.
  7. # [00:01] * Quits: glazou (~glazou@public.cloak) (glazou)
  8. # [00:01] <Bert_> s/if I set them on the outer element with repeat,/if I set them on the outer element with repeat, and use 'break-before: <something>' on a child,/
  9. # [00:01] * Quits: gregwhitworth (~gregwhitworth@public.cloak) ("Page closed")
  10. # [00:01] * fantasai kicks leaverou for not speaking up her points
  11. # [00:02] * Quits: smfr (~smfr@public.cloak) (smfr)
  12. # [00:02] * leaverou fantasai sorry! I had a sudden surge of self-consciousness :P
  13. # [00:09] * Quits: SteveZ (~SteveZ@public.cloak) (Ping timeout: 180 seconds)
  14. # [00:09] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
  15. # [00:09] * liam_ has been there often, leaverou :)
  16. # [00:09] * Joins: Florian (~Florian@public.cloak)
  17. # [00:10] * Quits: ChrisL (clilley@public.cloak) (Ping timeout: 180 seconds)
  18. # [00:11] * Quits: dael (~dael@public.cloak) ("Page closed")
  19. # [00:14] * Quits: antonp1 (~Thunderbird@public.cloak) (antonp1)
  20. # [00:14] * Joins: adenilson (~anonymous@public.cloak)
  21. # [00:16] * Quits: johanneswilm (~johannes@public.cloak) (Ping timeout: 180 seconds)
  22. # [00:16] * Quits: bcampbell (~chatzilla@public.cloak) (Ping timeout: 180 seconds)
  23. # [00:16] * Quits: Florian (~Florian@public.cloak) (Ping timeout: 180 seconds)
  24. # [00:18] * Rossen is now known as Rossen_away
  25. # [00:19] * Quits: andreyr (~andreyr@public.cloak) (Ping timeout: 180 seconds)
  26. # [00:21] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
  27. # [00:21] * leaverou is now known as leaverou_away
  28. # [00:29] * heycam|away is now known as heycam
  29. # [00:54] * Quits: adenilson (~anonymous@public.cloak) (Client closed connection)
  30. # [00:55] * Joins: adenilson (~anonymous@public.cloak)
  31. # [01:19] * heycam is now known as heycam|away
  32. # [01:21] * heycam|away is now known as heycam
  33. # [01:33] * Joins: adenilson_ (~anonymous@public.cloak)
  34. # [01:35] * Quits: adenilson (~anonymous@public.cloak) (Ping timeout: 180 seconds)
  35. # [01:35] * adenilson_ is now known as adenilson
  36. # [01:38] * Quits: adenilson (~anonymous@public.cloak) (Client closed connection)
  37. # [01:38] * Joins: adenilson (~anonymous@public.cloak)
  38. # [01:50] * Quits: Nik (~c7aca957@public.cloak) ("http://www.mibbit.com ajax IRC Client")
  39. # [01:54] * Quits: adenilson (~anonymous@public.cloak) (Client closed connection)
  40. # [01:55] * Joins: adenilson (~anonymous@public.cloak)
  41. # [01:55] * heycam is now known as heycam|away
  42. # [02:08] * Quits: adenilson (~anonymous@public.cloak) (Client closed connection)
  43. # [02:08] * Joins: adenilson (~anonymous@public.cloak)
  44. # [02:15] * Quits: adenilson (~anonymous@public.cloak) (Client closed connection)
  45. # [02:15] * Joins: adenilson (~anonymous@public.cloak)
  46. # [02:22] * Parts: quadcore (~user@public.cloak)
  47. # [02:27] * Joins: jdaggett (~jdaggett@public.cloak)
  48. # [02:30] * Quits: bl4de (~45bff13b@public.cloak) ("http://www.mibbit.com ajax IRC Client")
  49. # [02:40] * heycam|away is now known as heycam
  50. # [02:46] * Quits: Hixie (~ianh@public.cloak) (Ping timeout: 180 seconds)
  51. # [03:03] * Quits: adenilson (~anonymous@public.cloak) (adenilson)
  52. # [03:05] * Joins: Hixie (~ianh@public.cloak)
  53. # [03:18] * Joins: adenilson (~anonymous@public.cloak)
  54. # [03:21] * Quits: adenilson (~anonymous@public.cloak) (adenilson)
  55. # [03:27] * Joins: adenilson (~anonymous@public.cloak)
  56. # [03:29] * Joins: kwkbtr (~kwkbtr@public.cloak)
  57. # [03:53] * Joins: smfr (~smfr@public.cloak)
  58. # [03:53] * Quits: adenilson (~anonymous@public.cloak) (adenilson)
  59. # [03:54] * Joins: adenilson (~anonymous@public.cloak)
  60. # [04:04] * Joins: johanneswilm (~johannes@public.cloak)
  61. # [04:05] * Joins: shepazu (schepers@public.cloak)
  62. # [04:08] * Quits: adenilson (~anonymous@public.cloak) (adenilson)
  63. # [04:17] * Joins: adenilson (~anonymous@public.cloak)
  64. # [04:24] * Joins: adenilson_ (~anonymous@public.cloak)
  65. # [04:24] * Quits: adenilson (~anonymous@public.cloak) (Ping timeout: 180 seconds)
  66. # [04:24] * adenilson_ is now known as adenilson
  67. # [04:25] * Joins: Florian (~Florian@public.cloak)
  68. # [04:28] * leaverou_away is now known as leaverou
  69. # [04:34] * Joins: ChrisL (clilley@public.cloak)
  70. # [04:49] * Quits: ChrisL (clilley@public.cloak) (Client closed connection)
  71. # [04:51] * Quits: smfr (~smfr@public.cloak) (smfr)
  72. # [04:52] * Quits: johanneswilm (~johannes@public.cloak) (Ping timeout: 180 seconds)
  73. # [04:57] * leaverou is now known as leaverou_away
  74. # [05:05] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
  75. # [05:06] * Joins: Florian (~Florian@public.cloak)
  76. # [05:22] * Quits: adenilson (~anonymous@public.cloak) (adenilson)
  77. # [05:25] * leaverou_away is now known as leaverou
  78. # [05:29] * heycam is now known as heycam|away
  79. # [05:55] * SimonSapin_ is now known as SimonSapin
  80. # [05:57] * heycam|away is now known as heycam
  81. # [06:10] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
  82. # [06:16] * Joins: Florian_ (~Florian@public.cloak)
  83. # [06:24] * Quits: Florian_ (~Florian@public.cloak) (Client closed connection)
  84. # [06:33] * Joins: adenilson (~anonymous@public.cloak)
  85. # [07:31] * Quits: adenilson (~anonymous@public.cloak) (adenilson)
  86. # [07:33] * leaverou is now known as leaverou_away
  87. # [08:39] * Joins: Ms2ger (~Ms2ger@public.cloak)
  88. # [09:28] * Joins: johanneswilm (~johannes@public.cloak)
  89. # [09:43] * Joins: anssik (~uid10742@public.cloak)
  90. # [09:43] * Joins: antonp (~Thunderbird@public.cloak)
  91. # [09:47] * heycam is now known as heycam|away
  92. # [10:12] * Quits: jdaggett (~jdaggett@public.cloak) (Ping timeout: 180 seconds)
  93. # [10:39] * Joins: lajava (~javi@public.cloak)
  94. # [11:34] * Joins: adenilson (~anonymous@public.cloak)
  95. # [11:37] * Quits: johanneswilm (~johannes@public.cloak) (Ping timeout: 180 seconds)
  96. # [12:25] * Quits: kwkbtr (~kwkbtr@public.cloak) (Client closed connection)
  97. # [12:46] * Quits: adenilson (~anonymous@public.cloak) (adenilson)
  98. # [13:04] * Joins: Florian (~Florian@public.cloak)
  99. # [13:05] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
  100. # [13:05] * Joins: Florian (~Florian@public.cloak)
  101. # [13:12] * Quits: Florian (~Florian@public.cloak) (Ping timeout: 180 seconds)
  102. # [13:14] * Joins: johanneswilm (~johannes@public.cloak)
  103. # [13:29] * Joins: plh (plehegar@public.cloak)
  104. # [13:40] * Quits: lajava (~javi@public.cloak) (Ping timeout: 180 seconds)
  105. # [13:42] * Joins: Florian (~Florian@public.cloak)
  106. # [14:00] * leaverou_away is now known as leaverou
  107. # [14:05] * Quits: johanneswilm (~johannes@public.cloak) (Ping timeout: 180 seconds)
  108. # [14:12] * leaverou is now known as leaverou_away
  109. # [14:20] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
  110. # [14:20] * Joins: Florian (~Florian@public.cloak)
  111. # [14:27] * Quits: Florian (~Florian@public.cloak) (Ping timeout: 180 seconds)
  112. # [14:34] * Joins: SteveZ (~SteveZ@public.cloak)
  113. # [15:03] * Quits: shepazu (schepers@public.cloak) ("My Mac has gone to sleep. ZZZzzz…")
  114. # [15:04] * Joins: bcampbell (~chatzilla@public.cloak)
  115. # [15:07] * Joins: dauwhe (~dauwhe@public.cloak)
  116. # [15:12] * Joins: presentation-pc (~presentation-pc@public.cloak)
  117. # [15:15] * Joins: andrey-bloomberg (~andrey-bloomberg@public.cloak)
  118. # [15:16] <andrey-bloomberg> **** Dial in info: ****
  119. # [15:16] <andrey-bloomberg> please dial +1-212-617-1960 for New York, +44-20-7330-7700 for London, +81-3-3201-7040 for Tokyo. * Participants should enter PIN 295109.
  120. # [15:18] * Joins: renoirb (renoirb@public.cloak)
  121. # [15:18] * Joins: johanneswilm (~johannes@public.cloak)
  122. # [15:24] * Joins: glazou (~glazou@public.cloak)
  123. # [15:26] * Joins: Florian (~Florian@public.cloak)
  124. # [15:31] <glazou> koji: yt?
  125. # [15:31] * leaverou_away is now known as leaverou
  126. # [15:31] * koji yeah, trying to call in
  127. # [15:31] <glazou> we’re not ready yet
  128. # [15:31] * Joins: antenna (~antenna@public.cloak)
  129. # [15:31] <glazou> last people just arrived
  130. # [15:34] * Joins: Zakim (zakim@public.cloak)
  131. # [15:36] <SimonSapin> ScribeNick: SimonSapin
  132. # [15:36] <SimonSapin> Topic: Writing Modes
  133. # [15:36] * Quits: antenna (~antenna@public.cloak) ("Leaving")
  134. # [15:38] * Quits: plh (plehegar@public.cloak) ("Leaving")
  135. # [15:38] * presentation-pc is now known as presenter
  136. # [15:38] <presenter> https://lists.w3.org/Archives/Public/www-style/2015Apr/0387.html
  137. # [15:38] <SimonSapin> koji: First issue is proposal to defer orthogonal table cells
  138. # [15:39] * Joins: gregwhitworth (~gregwhitworth@public.cloak)
  139. # [15:39] <SimonSapin> fantasai: idea is we don’t have interop impls for writing modes applied to a table cell (you can apply to contents of a table cell)
  140. # [15:39] <SimonSapin> fantasai: proposal to defer to level 3
  141. # [15:39] <SimonSapin> fantasai: don’t think this makes sense, but problem is that we don’t have impls eg for vertical table headers
  142. # [15:40] <SimonSapin> Rossen_away: did you test IE?
  143. # [15:40] <SimonSapin> fantasai: yes, found bugs
  144. # [15:40] <SimonSapin> fantasai: I don,t think it makes sense to defer to next level
  145. # [15:40] <SimonSapin> jet: single cells?
  146. # [15:40] <SimonSapin> fantasai: yes
  147. # [15:40] <SimonSapin> fantasai: my position is we should keep it
  148. # [15:40] <SimonSapin> Rossen_away: I agree
  149. # [15:41] <SimonSapin> fantasai: defer means if you apply a WM to a table cell, some impls will apply some will ignore
  150. # [15:41] <SimonSapin> glazou: what does it mean in terms of spec? Behavior undefined?
  151. # [15:42] <SimonSapin> fantasai: we can do 3 things: 1 leave the spec alone, 2 say it’s undefined, 3 is say that WM to a table cell: either you do X or pretend it doesn’t apply
  152. # [15:42] <SimonSapin> dbaron: WM inherits, right?
  153. # [15:42] <SimonSapin> fantasai: yes
  154. # [15:43] <SimonSapin> fantasai: we need to look at why it’s not implemented
  155. # [15:43] <SimonSapin> SteveZ: ignore the property?
  156. # [15:43] <SimonSapin> fantasai: that’s 3
  157. # [15:43] <SimonSapin> fantasai: undefined means weird things can happen
  158. # [15:43] <SimonSapin> dbaron: it’s kinda weird to ignore an inherited prop on just some elements
  159. # [15:43] <gregwhitworth> This works in IE/MS Edge: http://jsbin.com/videdumeme/2/edit
  160. # [15:43] <SimonSapin> dbaron: on inner table elements like rows is use the WM of the table
  161. # [15:44] <SimonSapin> koji: you already apply WM to the table’s contents
  162. # [15:44] <SimonSapin> dbaron: ignoring it means you do the same for a cell, which acts like it has the WM of the table
  163. # [15:44] <koji> Spec currently says "All elements except table row groups, table column groups, table rows, and table columns"
  164. # [15:44] <SimonSapin> dbaron: but the anonymous block inside the cell uses the WM of the cell
  165. # [15:45] <SimonSapin> fantasai: if correctly, that’s same results
  166. # [15:45] <SimonSapin> dbaron: execpt for logical properties
  167. # [15:46] <SimonSapin> fantasai: we don’t have those yet, so from the POV of the spec it doesn’t make a difference
  168. # [15:46] * Joins: kwkbtr (~kwkbtr@public.cloak)
  169. # [15:46] <SimonSapin> dbaron: I don’t see how it would be extra work to make it apply at least on the anonymous block inside the table cell
  170. # [15:48] <glazou> Present: plinss, Rossen, TabAtkins, gregwhitworth, Bert, bcampbell, SimonSapin, glazou, fantasai, jet, iank, shane, dbaron, leaverou, SteveZ, johanneswilm, ChrisL, smfr, andrey-bloomberg
  171. # [15:48] * Joins: dbaron (~dbaron@public.cloak)
  172. # [15:49] * Joins: smfr (~smfr@public.cloak)
  173. # [15:51] <SimonSapin> koji: some differences in table cells when applying borders
  174. # [15:51] * fantasai koji, I think you have to type
  175. # [15:51] * fantasai we cannot understad you
  176. # [15:51] <koji> I think table cell has some differences in borders, colspan, etc.
  177. # [15:52] <koji> IE fails most of these tests as of today
  178. # [15:52] <fantasai> colspan!?
  179. # [15:52] <koji> Since WebKit and Blink does not apply to td/th
  180. # [15:52] <koji> authors already work around by putting a div/span inside table cells
  181. # [15:52] <SimonSapin> dbaron: colsan and rowspan are still relative to the table’s WM I hope?
  182. # [15:52] <SimonSapin> TabAtkins: Yes
  183. # [15:53] <SimonSapin> TabAtkins: a colspan spans columns
  184. # [15:53] <SimonSapin> dbaron: who is pushing to change the spec?
  185. # [15:53] <SimonSapin> TabAtkins: Koji is
  186. # [15:53] <koji> me
  187. # [15:53] <SimonSapin> fantasai: my preferred solution would be file bugs against impls
  188. # [15:53] <SimonSapin> gregwhitworth: Rossen_away: agree
  189. # [15:54] <SimonSapin> fantasai: anyone have a different opinion?
  190. # [15:54] <SimonSapin> Chris: so your opinion is that the spec is clear?
  191. # [15:54] <SimonSapin> fantasai: on that topic yes
  192. # [15:54] <SimonSapin> glazou: what does this mean to go to REC?
  193. # [15:54] * Rossen_away is now known as Rossen
  194. # [15:54] <SimonSapin> fantasai: bugs need to be fixed before
  195. # [15:54] <SimonSapin> glazou: are browsers interested in fixing this?
  196. # [15:55] <SimonSapin> jet: We’re implementing now
  197. # [15:55] <SimonSapin> glazou: sshould it be at-risk?
  198. # [15:55] <SimonSapin> Chris: there is no downside to mark at-risk
  199. # [15:55] <SimonSapin> Florian: also can mark at-risk + say "we can drop from must to should"
  200. # [15:56] <SimonSapin> SteveZ: In that case fantasai wants a fallback which in my mind means to ignore the property
  201. # [15:57] <SimonSapin> fantasai: so `td, th { writing-mode: inherit !important}` in the UA stylesheet?
  202. # [15:57] <SimonSapin> fantasai: effectively
  203. # [15:57] <SimonSapin> Chirs: with a comment: do it properly or not at all
  204. # [15:57] <koji> If not supported, it should be the same as when applied to <tr>, no?
  205. # [15:58] <SimonSapin> jet: sounds like implementers want to leave it in
  206. # [15:58] <SimonSapin> fantasai: you (IE) want the spec to stay and you’ll fix your bugs
  207. # [15:58] <SimonSapin> Rossen: can you be more specific?
  208. # [15:58] <SimonSapin> fantasai: so if we write test cases where you fail, you’ll fix it
  209. # [15:58] <SimonSapin> Rossen: that’s how it works
  210. # [15:58] <SimonSapin> fantasai: I think it should stay, but it’s up to the WG
  211. # [15:59] <SimonSapin> glazou: straw poll
  212. # [15:59] <SimonSapin> glazou: Two options: should stay in the spec, or not
  213. # [15:59] <SimonSapin> Florian: or marked at risk
  214. # [15:59] <Florian> s/or/and/
  215. # [16:00] <fantasai> 1. No change to spec
  216. # [16:00] <fantasai> 2. Say it is undefined
  217. # [16:00] <Florian> Stay in the spec, mark at risk, with clarification that at risk means may drop from must to shoud
  218. # [16:00] <fantasai> it = what happens whe writing-mode is applied to a table cell
  219. # [16:01] <glazou> Present+ shepazu
  220. # [16:01] <fantasai> 3. Mark as at-risk and specify what happens if it's not implemented
  221. # [16:01] <SimonSapin> 1: 8 hands raised
  222. # [16:01] <SimonSapin> 2: none
  223. # [16:02] <SimonSapin> 3: 5 hands
  224. # [16:02] * Zakim sees 3:, 5 on the speaker queue
  225. # [16:02] * koji raising for 3
  226. # [16:02] <koji> 3
  227. # [16:02] <SimonSapin> 3: 6 hands
  228. # [16:02] * Zakim sees 3:, 5, 6 on the speaker queue
  229. # [16:03] <SimonSapin> Florian: what’s the downside of 3? Same as 1 plus insurance
  230. # [16:03] <SimonSapin> dbaron: plus extra work
  231. # [16:03] <SimonSapin> fantasai: you need to specify both "should" and the alternative
  232. # [16:03] <koji> I can try to define the alternative
  233. # [16:04] <SimonSapin> glazou: 1 wins. Anyone objects?
  234. # [16:04] <koji> ok
  235. # [16:04] * fantasai notes that Microsoft, Blink, and Mozilla reps were all for 1
  236. # [16:04] <SimonSapin> RESOVED: No spec change for WM on table cells
  237. # [16:04] <SimonSapin> RESOVED: No spec change for writing-mode on table cells
  238. # [16:05] <SimonSapin> Topic: propagation of the direction property from <body>
  239. # [16:05] <SimonSapin> fantasai: not really getting information on why would anybody would do that
  240. # [16:05] <SimonSapin> gregwhitworth: faster to make the switch and see how much stuff breaks
  241. # [16:06] <SimonSapin> fantasai: proposal: propagate the dir attr value from body to html
  242. # [16:06] <SimonSapin> fantasai: rather than the direction property
  243. # [16:06] <koji> does the proposal include writing-mode?
  244. # [16:07] <SimonSapin> fantasai: advantage is that the direction property has lots of side effects on the root: scrolling direction, scrolling origin, alignment of things in the root, cascading…
  245. # [16:07] <SimonSapin> fantasai: lots easier and less buggy if none of these things had to be special-cased for body
  246. # [16:07] <SimonSapin> fantasai: only pay attention to direction on the root
  247. # [16:07] <SimonSapin> fantasai: less buggy impls, main question is can we pull that off in web content
  248. # [16:08] <SimonSapin> fantasai: some data, but hard to tell what’s going on
  249. # [16:08] <SimonSapin> fantasai: one survey says the direction property is used in like 88% of web pages, which is ridiculous
  250. # [16:08] <SimonSapin> fantasai: maybe it’s in some library
  251. # [16:08] <SimonSapin> fantasai: one fo the browsers should release a nightly build and see if that works
  252. # [16:08] <SimonSapin> fantasai: lots of simplification in layout engines, consistency, less bugs
  253. # [16:09] <SimonSapin> fantasai: worried about logical properties
  254. # [16:09] * Joins: ChrisL (clilley@public.cloak)
  255. # [16:09] <SimonSapin> dbaron: proposal is that dir attr on body sets the direction property on html?
  256. # [16:09] <SimonSapin> fantasai: yes
  257. # [16:09] * ChrisL less future bugs? Invest today in bug futures!
  258. # [16:09] <SimonSapin> fantasai: it’s only line with a child selector
  259. # [16:10] <SimonSapin> SimonSapin: you mean :has()
  260. # [16:10] <SimonSapin> fantasai: yeah
  261. # [16:10] <SimonSapin> dbaron: you also have to handle dir=auto
  262. # [16:10] <SimonSapin> dbaron: difference on dir=auto on html and body?
  263. # [16:10] <SimonSapin> fantasai: yes, look at the title
  264. # [16:10] <SimonSapin> dbaron: and maybe style and script elements?
  265. # [16:11] <SimonSapin> fantasai: yeah, probably you don’t want to set it on the html elements
  266. # [16:11] <SimonSapin> dbaron: don’t know interop. Gecko’s behavior is a bit random, 5 things that should be propagated but only some do. No good sense of compat risk or how reliable other impls are
  267. # [16:11] <SimonSapin> fantasai: testing showed lots of bugs
  268. # [16:12] <SimonSapin> fantasai: do we want someone implementing this, or more data, or not do this?
  269. # [16:12] <SimonSapin> SimonSapin: in favor of the proposal
  270. # [16:13] <SimonSapin> Bert_: would like to get rid of propagation from body as much as possible, e.g. background
  271. # [16:13] <SimonSapin> fantasai: probably this is the best we can do
  272. # [16:14] * ChrisL html6 to deprecate html, require head inside body
  273. # [16:14] <SimonSapin> fantasai: 2 variations up to HTML WG: 1. propagate the resolved direction (accounts for auto on body, not particularly necessary)
  274. # [16:14] <SimonSapin> 2. just propagate dir=rtl
  275. # [16:14] * Bert_ :-) at ChrisL
  276. # [16:14] <SimonSapin> dbaron: Don’t think the current HTML WG is suited to make this decision
  277. # [16:14] <SimonSapin> fantasai: I mean the people who work on things
  278. # [16:14] <SimonSapin> dbaron: that’s us
  279. # [16:14] <fantasai> html:has(>body[dir=rtl]) { direction: rtl }
  280. # [16:15] <fantasai> html:has(>body:dir(rtl)) { direction: rtl; }
  281. # [16:15] <fantasai> (insert a :not([dir]) after the html there)
  282. # [16:15] <fantasai> I don't think it matters which one we take, both are fine for web-compat, and using dir=auto on <body> is stupid
  283. # [16:16] <SimonSapin> dbaron: probably more sensible to handle dir=auto on body
  284. # [16:16] <SimonSapin> dbaron: makes more sense than on html
  285. # [16:16] <SimonSapin> fantasai: other opinions?
  286. # [16:16] <Bert_> s/e.g. background/background was an anomaly/
  287. # [16:16] <koji> writing-mode?
  288. # [16:16] <SimonSapin> fantasai: works for me
  289. # [16:16] <SimonSapin> glazou: we need to resolve or move on. Good to go?
  290. # [16:17] <SimonSapin> TabAtkins: yeah
  291. # [16:17] <fantasai> koji, I think we have to handle that as a separate issue
  292. # [16:17] <koji> ok, good then
  293. # [16:17] <SimonSapin> gregwhitworth: good to go but we need other impls to follow
  294. # [16:17] <SimonSapin> dbaron: someone just wrote patch, waiting for review. Don’t know if it does what this says
  295. # [16:18] <SimonSapin> gregwhitworth: can we resolve on doing this unless web compat is terrible?
  296. # [16:18] <SimonSapin> fantasai: yes
  297. # [16:18] * Joins: plh (plehegar@public.cloak)
  298. # [16:18] * Joins: quadcore (~user@public.cloak)
  299. # [16:18] <SimonSapin> fantasai: proposed resolution: no propagation of 'direction' from body to html, propagate dir attr with that rule above, back out if web compat problems
  300. # [16:18] <SimonSapin> fantasai: sounds good?
  301. # [16:18] <SimonSapin> glazou: no objection?
  302. # [16:19] <koji> yes, good
  303. # [16:19] <koji> can we also resolve for writing-mode?
  304. # [16:19] <koji> ...or at least discus?
  305. # [16:19] <SimonSapin> RESOLVED: no propagation of 'direction' from body to html, propagate dir attr with `html:not([dir]):has(>body:dir(rtl)) { direction: rtl; }, back out if web compat problems
  306. # [16:20] <SimonSapin> dbaron: if this works, it makes sense not to propagate writing-mode
  307. # [16:20] <SimonSapin> dbaron: if not, keep them together
  308. # [16:20] <SimonSapin> fantasai: seems ok
  309. # [16:20] <koji> but propagating dir attribute implies propagating direciton property, no?
  310. # [16:20] <fantasai> no, it's different
  311. # [16:20] <koji> I prefer propagating writing-mode
  312. # [16:21] <koji> as that's what IE/WebKit/Blink does today AFAIU
  313. # [16:21] <SimonSapin> dbaron: if we want WM to propagate at the CSS level we should undo that resolution and propagate direction at the CSS level as well
  314. # [16:22] <koji> If those two are linked, I'm not ok with the proposal for dir
  315. # [16:22] <SimonSapin> dbaron: though maybe in terms of effect, not necessarily in terms of computed values
  316. # [16:22] <dbaron> dbaron: ... on the root
  317. # [16:23] <SimonSapin> fantasai: we have to figure out what to do for writing-mode. If it has to propagate, direction does too
  318. # [16:23] <SimonSapin> fantasai: IE WebKit Blink all propagate
  319. # [16:23] <SimonSapin> fantasai: issue would be, can we turn it off?
  320. # [16:23] <koji> Quite possible to break lots of EPUB
  321. # [16:24] <SimonSapin> Rossen: In our case, vertical/rtl doesn’t make a difference
  322. # [16:24] <SimonSapin> Rossen: I’m gonna be opposed to different handling
  323. # [16:24] <SimonSapin> fantasai: agreed
  324. # [16:24] <SimonSapin> fantasai: you currently propagate w-m from body to html, wolud you be able to turn that off?
  325. # [16:24] <SimonSapin> Rossen: we can, if everybody else does it at the same time
  326. # [16:25] <SimonSapin> fantasai: other impls are WebKit and Blink
  327. # [16:25] <SimonSapin> TabAtkins: I have no idea
  328. # [16:25] <SimonSapin> gregwhitworth: maybe a good starting point is understand the compat issue
  329. # [16:25] <SimonSapin> fantasai: is is more […], we have more options with direction with the dir attr, but this is only CSS
  330. # [16:26] <SimonSapin> fantasai: sounds like Microsoft is willing is Blink and WebKit also ship without propagation. What is the state of the content you need to deal with?
  331. # [16:27] <SimonSapin> fantasai: concern that there are pages out there that set w-m on body and expect the whole thing to be vertical text
  332. # [16:27] <koji> I don't have data, but estimates it breaks several EPUB content
  333. # [16:27] <SimonSapin> gregwhitworth: do we wanna unresolve?
  334. # [16:27] <SimonSapin> fantasai: we can resolve that direction and w-m need to have the same propagation behavior
  335. # [16:27] <SimonSapin> gregwhitworth: I can give sites that are using w-m on body, be would be good if webkit/blink can also investigate
  336. # [16:28] <SimonSapin> RESOLVED: writing-mode and direction need to have the same propagation behavior, so writing-mode compat affects the previous resolution
  337. # [16:28] <koji> and do we unresolve the previous until we investigate?
  338. # [16:29] <koji> great, thank you
  339. # [16:30] <SimonSapin> fantasai: action item for that?
  340. # [16:30] <SimonSapin> gregwhitworth: I’ll take it, but good if everybody else looks into it
  341. # [16:31] <SimonSapin> gregwhitworth: ebooks and stuff
  342. # [16:31] <SimonSapin> ACTION gregwhitworth Investigate web compat of not propagating writing-mode from body to html
  343. # [16:31] * trackbot is creating a new ACTION.
  344. # [16:31] <trackbot> Created ACTION-687 - Investigate web compat of not propagating writing-mode from body to html [on Greg Whitworth - due 2015-05-26].
  345. # [16:31] <koji> I'll try to look into too
  346. # [16:31] * fantasai notes that result of ebooks layout might not be affected if 7.3.2 is implemented fully ^_^
  347. # [16:32] <SimonSapin> ACTION smfr Investigate web compat of not propagating writing-mode from body to html
  348. # [16:32] * trackbot is creating a new ACTION.
  349. # [16:32] <trackbot> Created ACTION-688 - Investigate web compat of not propagating writing-mode from body to html [on Simon Fraser - due 2015-05-26].
  350. # [16:32] * glazou notes that fantasai types emoji on IRC faster than I can read them
  351. # [16:33] <SimonSapin> fantasai: 7.3.2 is automatic use of multicol. Since ebooks don’t scroll, the default column size is the full size of the viewport. Long horizontal document with vertical columns … ends up with the same result
  352. # [16:33] <SimonSapin> fantasai: only problem with scrollable web page, scrolling origin is in the wrong place
  353. # [16:33] <SimonSapin> fantasai: if you set w-m on body and it doesn’t propagate, you only notice it in scrolling
  354. # [16:34] <SimonSapin> fantasai: you don’t implement auto multicol, it does make a difference
  355. # [16:34] <SimonSapin> fantasai: if you have one long thing and only print the first chunk of it
  356. # [16:35] <SimonSapin> fantasai: might be that we can not popagate if we handle auto multicol in orthogonal flows
  357. # [16:35] <SimonSapin> Topic: SVG
  358. # [16:36] <SimonSapin> fantasai: issue is that writing-mode property will inherit into embedded SVG
  359. # [16:36] <SimonSapin> fantasai: in some cases you want that, if decorating text
  360. # [16:36] <SimonSapin> fantasai: in most cases, that’ll break your coordinate space
  361. # [16:36] <SimonSapin> fantasai: do we block inferitance of writing-mode in SVG?
  362. # [16:36] <SimonSapin> ChrisL: there are lots of cases when inheritance is unwanted
  363. # [16:37] <SimonSapin> ChrisL: MathML doesn’t do vertical text, SVG tries
  364. # [16:37] <SimonSapin> fantasai: you render MathML sideways, it ignores writing-mode
  365. # [16:37] <koji> yeah, but the problem of writing-mode is coordinate system is always physical
  366. # [16:38] <SimonSapin> Rossen: if you have foreign objects with HTML inside, you might want to popagate
  367. # [16:38] <SimonSapin> dbaron: seems like if pasting SVG into HTML, there’s a ton of things that inherit. Fonts, … If you want your SVG to be isolated, not be part of the contxt, you should be using object or img or iframe
  368. # [16:39] <SimonSapin> fantasai: we can block with `all: initial`
  369. # [16:39] <SimonSapin> TabAtkins: except direction, because it shouldn’t have been a CSS property
  370. # [16:39] <SimonSapin> TabAtkins: and unicode-bidi
  371. # [16:39] <SimonSapin> fantasai: we want that to happen at the HTML layer
  372. # [16:40] <SimonSapin> fantasai: direction is not the problem here. If you’re pasting graphics with text, chances are it’s in the same language
  373. # [16:41] <SimonSapin> Doug: confusing either way. Some people will expect either behavior. As long as there is a way to achieve both. Have a way to block all these things at the SVG layer
  374. # [16:41] <SimonSapin> Doug: it’s gonna be confusing for somebody no matter which way we go
  375. # [16:41] <SimonSapin> ChrisL: mention it in the SVG integration spec?
  376. # [16:41] <SimonSapin> fantasai: way to do is set `all: initial` and maybe `direction: intial`. Is that the default? Or does the defalut inherit through?
  377. # [16:42] <SimonSapin> fantasai: 2 things is that `all: initial` would block inheritance, `all: unset` would get it back
  378. # [16:42] <SimonSapin> Doug: Once you see a graphics you don’t expect it to change based on context. So want the default to not propagate.
  379. # [16:43] <SimonSapin> TabAtkins: you’re dropping literal markup
  380. # [16:43] <SimonSapin> Doug: still think it’s more intuitive to opt into propagation
  381. # [16:43] <SimonSapin> fantasai: also run into bugs when the author didn’t look at that particular graphics when translated… or change some font property
  382. # [16:44] <SimonSapin> fantasai: more obvious if the text is off
  383. # [16:44] <SimonSapin> Doug: we don’t know how they’re bringing that markup. Are they using D3?
  384. # [16:45] <SimonSapin> Doug: they could do it in a blog. Blocking is more intuitive, and make it clear how to unblock
  385. # [16:46] <SimonSapin> fantasai: proposed resolution: CSSWG recommends to SVGWG to block inheritance of CSS properties using `all: initial` at the SVG/HTML boundary
  386. # [16:46] <SimonSapin> dbaron: compat risk, this is used.
  387. # [16:46] <SimonSapin> glazou: yes
  388. # [16:46] <SimonSapin> Florian: fine 10 years ago, but SVG is used now with inheritance, we’re changing behavior
  389. # [16:47] <SimonSapin> glazou: SVG editor in Bluegriffon. You can select the whole document and make it bold. It just works.
  390. # [16:47] * Quits: gregwhitworth (~gregwhitworth@public.cloak) (Ping timeout: 180 seconds)
  391. # [16:47] <SimonSapin> glazou: change behavior in a way that may not be understandable
  392. # [16:47] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
  393. # [16:47] * Joins: Florian (~Florian@public.cloak)
  394. # [16:47] <SimonSapin> ChrisL: problem is two situations where people expect opposite things. Not clear which should be the default.
  395. # [16:48] <SimonSapin> Doug: we’re mostly talking about text.
  396. # [16:48] <SimonSapin> TabAtkins: color matters. `fill: currentColor`
  397. # [16:48] <SimonSapin> TabAtkins: it can be done now, we’d be breaking graphics if we change it to black
  398. # [16:48] <SimonSapin> jet: should SVG WG be doing this?
  399. # [16:49] <SimonSapin> fantasai: spec should explain how to do the other behavior
  400. # [16:49] <SimonSapin> Rossen: I’m with dbaron. Web compat is gonna be a chanllenge. If you want to do this, it should be opt-in
  401. # [16:49] <SimonSapin> Florian: should be on the svg element
  402. # [16:49] <SimonSapin> Rossen: too big of a knob
  403. # [16:50] <SimonSapin> ChrisL: the all property is already a big knob
  404. # [16:50] <SimonSapin> Florian: SVG is just an image, or it’s part of the document. Having that switch, that can still be overridden
  405. # [16:51] <SimonSapin> plinss: other problem when people want isolation of style. Why special mechanism just for SVG?
  406. # [16:51] <SimonSapin> ChrisL: SVG seamless
  407. # [16:51] <SimonSapin> leaverou: I though that was a joke
  408. # [16:51] <SimonSapin> ChrisL: when you want to inherit into <object>
  409. # [16:51] <SimonSapin> fantasai: so inherit, and use `all: initial` if your image is screwed up
  410. # [16:52] <SimonSapin> fantasai: need notes on both specs, especially for `writing-mode: unset`
  411. # [16:52] <leaverou> s/ChrisL: SVG seamless/ChrisL: Lea suggested the seamless attribute to do the opposite/
  412. # [16:52] <SimonSapin> fantasai: SVG spec in embedding should talk about this
  413. # [16:52] <SimonSapin> Doug: somebody’s gonna be surprised either way
  414. # [16:52] <SimonSapin> fantasai: if we have exsting content…
  415. # [16:52] * Joins: Florian_ (~Florian@public.cloak)
  416. # [16:53] <leaverou> s/leaverou: I though that was a joke/leaverou: that was more of a joke/
  417. # [16:53] <SimonSapin> RESOLVED: Writing Modes spec adds an example of blocking inheritance into SVG
  418. # [16:53] <SimonSapin> <break duration=15m>
  419. # [16:54] * Quits: Florian (~Florian@public.cloak) (Ping timeout: 180 seconds)
  420. # [16:59] * Joins: shepazu (schepers@public.cloak)
  421. # [17:01] * Quits: Florian_ (~Florian@public.cloak) (Client closed connection)
  422. # [17:02] * Joins: Florian (~Florian@public.cloak)
  423. # [17:08] * Joins: Florian_ (~Florian@public.cloak)
  424. # [17:09] * Quits: Florian (~Florian@public.cloak) (Ping timeout: 180 seconds)
  425. # [17:12] * leaverou is now known as leaverou_away
  426. # [17:15] * Rossen is now known as Rossen_away
  427. # [17:18] * Joins: myakura (~myakura@public.cloak)
  428. # [17:18] * Joins: gregwhitworth (~gregwhitworth@public.cloak)
  429. # [17:19] <gregwhitworth> koji: you there?
  430. # [17:19] <koji> greg: yes
  431. # [17:20] <gregwhitworth> ok, awesome
  432. # [17:20] <gregwhitworth> we're going to get moving again
  433. # [17:20] <koji> thanks
  434. # [17:20] <gregwhitworth> scribenick: gregwhitworth
  435. # [17:21] <gregwhitworth> koji: let us know when you're dialed in
  436. # [17:23] * leaverou_away is now known as leaverou
  437. # [17:23] <koji> I'm already in ;)
  438. # [17:23] <gregwhitworth> thanks
  439. # [17:26] <SimonSapin> Topic: sideways-left
  440. # [17:26] <gregwhitworth> fantasai: we have three keywords
  441. # [17:27] <gregwhitworth> fantasai: depending on the block direction sideways will get you the direction of the non-cjk language
  442. # [17:27] <gregwhitworth> fantasai: as though the block was rotated
  443. # [17:27] <gregwhitworth> fantasai: [shows diagram of sideways props]
  444. # [17:28] <dbaron> fantasai: sideways-right is the same as sideways in vertical-rl (Chinese, Japanese, etc.), but backwards for vertical-lr (Mongolian)
  445. # [17:28] <dbaron> fantasai: reverse for sideways-left
  446. # [17:28] <gregwhitworth> fantasai: you just want to set writing-mode on the root element and have it work
  447. # [17:29] <gregwhitworth> fantasia: this issue we have is implementors have not implemented sideways-left
  448. # [17:29] <leaverou> s/fantasia/fantasai/
  449. # [17:30] * Rossen_away is now known as Rossen
  450. # [17:30] <gregwhitworth> fantasai: because of this if you set vertical-lr together with sideways webkit will give you the sideways-right behavior
  451. # [17:31] <gregwhitworth> florian: isn't the bottom right to embed arabic in english?
  452. # [17:31] <gregwhitworth> fantasai: yes, you're right, there are use cases for this
  453. # [17:31] <gregwhitworth> fantasai: also there is an obscure script for this as well
  454. # [17:32] <ChrisL> https://en.wikipedia.org/wiki/Ogham
  455. # [17:32] <gregwhitworth> fantasai: we have implementors saying sideways-right is good, and sideways, but not sideways-left
  456. # [17:32] <gregwhitworth> fantasai: this is not right, this is a conflict, you can't implement sideways and not implement sideways-left
  457. # [17:33] <gregwhitworth> florian: given what you want for mongolian, do we need sideways?
  458. # [17:33] <gregwhitworth> fantasai: it's trivial, it helps with table captions and doing it automatically
  459. # [17:33] <gregwhitworth> florian: fare enough
  460. # [17:33] * Joins: tantek (~tantek@public.cloak)
  461. # [17:33] <plinss> s/fare/fair/
  462. # [17:34] <gregwhitworth> fantasai: either implement both sideways-left, or drop vertical-lr support, or update the spec
  463. # [17:34] <gregwhitworth> fantasai: we could mark vertical-lr at risk
  464. # [17:34] <gregwhitworth> fantasai: change the meaning of sideways
  465. # [17:35] <gregwhitworth> fantasai: those are the things that we can do for the spec
  466. # [17:35] <gregwhitworth> florian: the naming we have now favors english
  467. # [17:35] <gregwhitworth> florian: maybe we should focus the short keyword on doing the right thing for Asain languages since writing-modes is for fixing these issues
  468. # [17:36] <gregwhitworth> simon: what is the difficulty with sideways-left? And don't you have the same issues with sideways-right and RTL?
  469. # [17:37] <gregwhitworth> fantasai: no the issue is with the coordinate system being different
  470. # [17:37] <gregwhitworth> fantasai: in sideways-left and you may have both of them in a line, you will have a coordinate system for your linebox and then inside of this you may have to flip this for a range of text
  471. # [17:38] <gregwhitworth> dbaron: Gecko implements sideways-right, but not sideways or sideways-left
  472. # [17:38] <gregwhitworth> dbaron: another complication that sideways-left introduces is how floats will work, technically float: left and float: right can be swapped
  473. # [17:39] <gregwhitworth> dbaron: the spec needs to be switched to floats that are on the right/left of the bfc, etc
  474. # [17:39] <gregwhitworth> dbaron: once you introduce sideways-left you may have a bfc where they swap
  475. # [17:39] <dbaron> (that's issue 5 in the spec)
  476. # [17:40] <gregwhitworth> Bert_: why is this different than Japanese?
  477. # [17:40] <gregwhitworth> fantasai: because it works differently and the float will go where it should go like normal, just in vertical
  478. # [17:41] <gregwhitworth> florian: that way float: left would be float: top
  479. # [17:41] <Florian_> ?
  480. # [17:42] <gregwhitworth> ratan: that is how our implementation currently works, it's generic to the bfc
  481. # [17:42] <gregwhitworth> fantasai: we have this issue where webkit is not per spec
  482. # [17:42] <gregwhitworth> fantasai: three options
  483. # [17:42] <gregwhitworth> fantasai: 1) Change meaning of sideways to sideways-right
  484. # [17:42] <dbaron> http://dev.w3.org/csswg/css-writing-modes/#logical-to-physical is a useful table
  485. # [17:43] <gregwhitworth> fantasai: 2) Webkit drops support for sideways keyword
  486. # [17:43] <gregwhitworth> fantasai: 3) webkit drops support for vertical-lr
  487. # [17:43] <gregwhitworth> fantasai: 4)Webkit implements sideways correctly
  488. # [17:43] <gregwhitworth> fantasai: I believe this is the same for Blink as well
  489. # [17:44] <gregwhitworth> florian: Do we actually have a choice or are there compat concerns
  490. # [17:44] <gregwhitworth> fantasai: Not really, there won't be a lot of compat risk
  491. # [17:45] <gregwhitworth> fantasai: The issue when you would hit this, is foregin text in a Mongolian document where this would break compat
  492. # [17:45] <ChrisL> Mongolia: Population, total = 2.84 million (2013)
  493. # [17:45] <gregwhitworth> fantasai: I want to know what WK/Blink think about the options
  494. # [17:45] <gregwhitworth> tabatkins: ¯\_(ツ)_/¯
  495. # [17:46] <koji> As a personal I prefer 1
  496. # [17:47] <gregwhitworth> florian: Number 1 makes the most sense to me
  497. # [17:47] <gregwhitworth> Bert_: Are these values to be used in CJK texts
  498. # [17:47] <gregwhitworth> fantasai: yes
  499. # [17:49] <gregwhitworth> fantasai: if you're embedding a word "O'connor", in CJK languages you would put it in mixed mode and it would look wrong
  500. # [17:49] * Joins: lajava (~javi@public.cloak)
  501. # [17:49] <gregwhitworth> fantasai: you would set [lang-en] {sidways-x} so that they display correctly
  502. # [17:49] <Rossen> http://www.memes.com/m/rEyc
  503. # [17:50] <gregwhitworth> florian: for CJK sideways left and sideways right are actually the same
  504. # [17:50] <gregwhitworth> smfr: I'm looking at some webkit test cases and sideways and sideways-right differ in glyphs used
  505. # [17:50] <gregwhitworth> fantasai: well then that's wrong, the spec is clear that sideways equates to sideways-right
  506. # [17:51] <gregwhitworth> florian: so your sideways, is a kind of mixed not a kind of sideways, so drop it
  507. # [17:51] <gregwhitworth> smfr: but we did this for Japanese books
  508. # [17:53] <gregwhitworth> fantasai: from the testing it looks like we landed on two
  509. # [17:53] * koji ?
  510. # [17:54] <fantasai> koji, do you have a testcase for webkit 'sideways'?
  511. # [17:54] <gregwhitworth> tantek: has webkit ever dropped the support for a keyword
  512. # [17:54] <koji> it used to work as an alias to sideways-right AFAIK
  513. # [17:54] <fantasai> It doesn't seem to atm
  514. # [17:54] <gregwhitworth> tantek: I don't think that we should resolve on it if it's never happened
  515. # [17:54] <fantasai> smfr's testcase works same as mixed
  516. # [17:55] <fantasai> smfr: webkit also says they can change names when dropping prefix
  517. # [17:55] <fantasai> smfr: So, is there still an issue?
  518. # [17:55] <fantasai> s/smfr/koji/
  519. # [17:55] <fantasai> s/smfr/koji/
  520. # [17:55] <fantasai> s/:/,/
  521. # [17:55] <fantasai> s/:/,/
  522. # [17:56] <koji> I'm not really following...so which option WG prefers?
  523. # [17:56] <fantasai> koji, WG testing shows 'text-orientation: sideways' is not supported by WebKit
  524. # [17:56] <fantasai> So, it seems option 2 is ok
  525. # [17:56] <koji> It used to, at least for a few years, and Bllnk does today
  526. # [17:57] <gregwhitworth> fantasai: I need a testcase
  527. # [17:58] <Bert_> Neither writing-mode nor text-orientation is in Safari's documentation.
  528. # [17:58] <fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22-webkit-writing-mode%3A%20vertical-lr%3B%20text-orientation%3A%20sideways%22%3ETEXT
  529. # [17:58] * Bert_ is now known as Bert
  530. # [17:59] <fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22-webkit-writing-mode%3A%20vertical-lr%3B%20text-orientation%3A%20sideways%22%3ETEXT%E3%81%AE%E3%83%9A%E3%83%BC%E3%82%B8%E3%80%81%E3%82%B9%E3%82%AF%E3%83%AD%E3%83%BC%E3%83%AB%E3%81%8C
  531. # [17:59] <fantasai> Koji< looks like no support
  532. # [17:59] <fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22-webkit-writing-mode%3A%20vertical-lr%3B%20-webkit-text-orientation%3A%20sideways%22%3ETEXT%E3%81%AE%E3%83%9A%E3%83%BC%E3%82%B8%E3%80%81%E3%82%B9%E3%82%AF%E3%83%AD%E3%83%BC%E3%83%AB%E3%81%8C
  533. # [17:59] <fantasai> OK, last one is the real thing :)
  534. # [18:00] * Quits: kwkbtr (~kwkbtr@public.cloak) ("")
  535. # [18:00] <fantasai> Note that all properties are prefixed
  536. # [18:00] <fantasai> -webkit-
  537. # [18:00] <koji> I see, because you use vertical-lr
  538. # [18:00] <koji> WebKit supports sideways correctly if vertical-rl
  539. # [18:00] <koji> looks like
  540. # [18:01] <koji> vertical-rl + sideways = mixed in WebKit, but
  541. # [18:01] <koji> s/rl/lr/
  542. # [18:01] <koji> vertical-lr + sideways = sideways-right
  543. # [18:01] <koji> so WebKit does have problems for CJK, not a problem for Mongolian
  544. # [18:02] <gregwhitworth> fantasai: we have two different behaviors for the sideways keyword
  545. # [18:02] <gregwhitworth> fantasai: Blink implements it as sideways-right
  546. # [18:02] <gregwhitworth> fantasai: Webkit implements it as mixed
  547. # [18:03] <gregwhitworth> fantasai: both in vertical-lr mode
  548. # [18:03] <gregwhitworth> florian: since they're prefixed the same there should be no compat hit
  549. # [18:03] <gregwhitworth> fantasai: yeah
  550. # [18:03] * Zakim excuses himself; his presence no longer seems to be needed
  551. # [18:03] * Parts: Zakim (zakim@public.cloak)
  552. # [18:04] <gregwhitworth> dbaron: we're not currently shipping our pref for text-orientation
  553. # [18:04] <koji> Mongolian needs sideways-right anyway, so I guess option 1 works better than option 1?
  554. # [18:04] <gregwhitworth> smfr: we did this for Japanese, so that's probably just a bug
  555. # [18:04] <gregwhitworth> fantasai: I feel like we're leaning towards option 1 or 4
  556. # [18:05] <gregwhitworth> fantasai: there seems like a decent likelyhood that we won't have sideways-left for a while, so I think it's at risk of being dropped, what happens to sideways in that case as we may have web compat
  557. # [18:05] <fantasai> koji, does content depend on unprefixed 'text-orientation: sideways'?
  558. # [18:05] <gregwhitworth> florian: again, it's only in prefixed props for compat
  559. # [18:06] <gregwhitworth> florian: also, it's mainly in books, etc so less likely hood of pre-parsers
  560. # [18:06] <koji> fantasai: don't have data
  561. # [18:06] <gregwhitworth> florian: maybe we should drop them now
  562. # [18:06] <gregwhitworth> dbaron: another option is to keep sideways-left/right and put vertical-lr at risk
  563. # [18:06] <gregwhitworth> fantasai: seems less likely to drop vertical-lr
  564. # [18:07] <gregwhitworth> smfr: I don't think I'd prefer that
  565. # [18:07] <gregwhitworth> tantek: what is the usecase for 2 vs 3 keywords
  566. # [18:07] <gregwhitworth> fantasai: shows the different examples again
  567. # [18:08] <gregwhitworth> fantasia: it's captions on tables or image, and you want to put the block ordering in english
  568. # [18:08] <gregwhitworth> fantasai: the other options are for CJK languages, it doesn't make sense for english
  569. # [18:09] <gregwhitworth> tantek: So for horizontal text written vertically that's the main use case for sideways
  570. # [18:09] <gregwhitworth> florian: yes
  571. # [18:09] <gregwhitworth> SteveZ: It's not easy as you say, what if you want it different on the left than on the right of the document
  572. # [18:09] <gregwhitworth> fantasai: you would change the writing-mode only
  573. # [18:09] <koji> tantek: sideways-left is for English, but sideways-right is used in CJK and Mongolian too
  574. # [18:10] <gregwhitworth> fantasai: the use cases for sideways-left are not that strong
  575. # [18:10] <gregwhitworth> fantasai: but to have sideways, you have to have both sideways-right and sideways-left
  576. # [18:10] <gregwhitworth> tantek: they're not strong, but there are use cases
  577. # [18:10] <koji> and most of the use cases can be achieved by transform:rotate(180deg)
  578. # [18:11] <gregwhitworth> fantasai: yes in books, with tabs in the corner that are rotated, etc
  579. # [18:11] <koji> So I'm not positive to bring in the complexity sideways-left has
  580. # [18:11] <gregwhitworth> tantek: are there any use cases for non-90 degree angles?
  581. # [18:12] <gregwhitworth> fantasai: not currently
  582. # [18:12] * Quits: bcampbell (~chatzilla@public.cloak) (Ping timeout: 180 seconds)
  583. # [18:12] <gregwhitworth> fantasai: we may want to change the keywords to sideways-rl and sideways-lr
  584. # [18:12] <gregwhitworth> florian: I don't think that is better
  585. # [18:13] <gregwhitworth> florian: Typically when embedding a foreign language in Japanese you normally do sideways-right
  586. # [18:13] <gregwhitworth> fantasai: but there are examples of both
  587. # [18:13] <gregwhitworth> tantek: what is the easiest one for authors to remember, if it doesn't actually map to vertical-lr then we probably should change it
  588. # [18:14] <gregwhitworth> dbaron: let's pick an option before moving onto the naming
  589. # [18:14] <gregwhitworth> fantasai: [crosses off number 3]
  590. # [18:15] <gregwhitworth> smfr: when we unprefix, we could change the behavior
  591. # [18:15] <gregwhitworth> fantasai: I think you could change it now, because people aren't really depending on sideways-right in vertical-lr mode
  592. # [18:16] <gregwhitworth> fantasai: [explains options again]
  593. # [18:16] <gregwhitworth> smfr: just spec what people want and we'll change our implementation
  594. # [18:17] <gregwhitworth> WG says to keep 4: Implement sideways correctly (DON'T HAVE BUGS)
  595. # [18:17] <gregwhitworth> smfr: file those bugs and we'll go fix them
  596. # [18:18] <gregwhitworth> RESOLUTION: Clarify the spec to correctly explain how to implement sideways
  597. # [18:19] <gregwhitworth> RESOLUTION: and how to not implement sideways
  598. # [18:19] * Quits: Florian_ (~Florian@public.cloak) (Client closed connection)
  599. # [18:19] * liam_ is now known as liam
  600. # [18:19] * Joins: Florian (~Florian@public.cloak)
  601. # [18:19] <gregwhitworth> RESOLUTION: Don't mark vertical-lr at risk
  602. # [18:20] <gregwhitworth> koji: anymore issues?
  603. # [18:20] <koji> Are there time for issue 10?
  604. # [18:21] <gregwhitworth> fantasai: issue 10
  605. # [18:21] <gregwhitworth> fantasai: let's say you have a vertical block and start writing, and the block gets longer and longer, then you print it chops off the overflow
  606. # [18:22] <gregwhitworth> fantasai: when printing, if you support multicol, when you print the overflow gets put into a multicol that is the size of the viewport height
  607. # [18:22] <gregwhitworth> fantasai: this is good because you have no data loss and this will allow ebooks to still work as well
  608. # [18:22] <gregwhitworth> ChrisL: You said this as though it was magic, but does the stylesheet have this, or does the UA do this
  609. # [18:23] <gregwhitworth> fantasai: the spec currently says that this needs to happen if you overflow, so you would need to put it into multicolumn
  610. # [18:23] <gregwhitworth> ratan: we had this behavior in IE6/7 when you have vertical inside of horizontal, our printing would do what you are saying
  611. # [18:24] <gregwhitworth> ratan: We didn't emulate this in later versions, it wasn't technically too dificult to do but in my opinion if we need to have this it would be easier to do the magic behavior that ChrisL stated
  612. # [18:25] <gregwhitworth> ratan: where when we're paginating that would allow us to keep the layout
  613. # [18:25] <gregwhitworth> fantasai: I'm not recommending this for just printing
  614. # [18:25] <gregwhitworth> SteveZ: isn't this where you would want to do overflow: fragment
  615. # [18:26] <gregwhitworth> tabatkins: sure, multicol was just the way to get the behavior
  616. # [18:26] * Rossen is now known as Rossen_away
  617. # [18:26] <gregwhitworth> fantasai: you don't want copies of the container with it's decorations
  618. # [18:27] <gregwhitworth> fantasai: this is just for autosizing
  619. # [18:27] <gregwhitworth> SteveZ: I would still need to set a height
  620. # [18:27] * Rossen_away is now known as Rossen
  621. # [18:27] <Rossen> s/ratan/Rossen/
  622. # [18:27] <gregwhitworth> dbaron: this seems way too magical
  623. # [18:28] <gregwhitworth> dbaron: I would prefer to do it in simple ways that they can know how to set it up
  624. # [18:28] <gregwhitworth> florian: on the other hand if you're testing on your screen and don't hit this, that causes problems
  625. # [18:29] <gregwhitworth> smfr: there are other ways to cause these issues
  626. # [18:29] <gregwhitworth> plinss: I would like to see a general solution to clipping content to overflow
  627. # [18:29] <gregwhitworth> Bert_: It's not overflowing, the height is auto - you have infinite space in the block direction
  628. # [18:30] <gregwhitworth> fantasai: you don't want to set the height to vh, because you'll cause overflow in the block direction as well
  629. # [18:30] <gregwhitworth> SteveZ: then I agree this is way too magical
  630. # [18:30] <gregwhitworth> Rossen: Also this is really rare
  631. # [18:30] <gregwhitworth> fantasai: The author doesn't print their website ever, it's the user
  632. # [18:31] <gregwhitworth> fantasai: that's why we set to shrink wrap to the viewport height
  633. # [18:31] <gregwhitworth> fantasai: and that causes things to wrap and end up overflowing
  634. # [18:31] <gregwhitworth> SteveZ: I agree that multicol is good solution, but I would prefer to use overflow: fragment
  635. # [18:33] <gregwhitworth> plinss: I like the effect, and what you're trying to do with it, but I don't like the magic and trying to explain pagination using multicol
  636. # [18:33] <gregwhitworth> fantasai: we normally just tile it, but here you don't want to tile it as you'll cut stuff in half
  637. # [18:34] <gregwhitworth> plinss: I just wish we had a better way of explaining pagination
  638. # [18:34] <gregwhitworth> plinss: it feels like overflow: fragmentation is the right way to take this, but we need to mature that space
  639. # [18:36] <gregwhitworth> fantasai: Multicol and fragment are very similiar, but multicol will provide you with the backgrounds and borders you want
  640. # [18:36] * dauwhe +1 to plinss
  641. # [18:36] <gregwhitworth> plinss: I want a better general explanation of this
  642. # [18:36] <gregwhitworth> florian: we've been using multicol as a type of exotic layout, but in this case it is very fundamental in common layouts
  643. # [18:37] <gregwhitworth> florian: the type of behavior it gets you is quite fundamental
  644. # [18:38] <gregwhitworth> plinss: againt the behavior is the correct one, but I don't want it just using multicol under the hood. I want a general set of primitives that explains pagination that people can trigger
  645. # [18:38] <gregwhitworth> fantasai: This is only triggered in an orthogonal flow
  646. # [18:39] <gregwhitworth> Rossen: The spec encourages to set height
  647. # [18:39] <gregwhitworth> SteveZ: I would like to have it work on all heights
  648. # [18:39] <gregwhitworth> fantasai: [draws diagrams showing calculations of heights of cols in an orthogonal flow]
  649. # [18:40] <gregwhitworth> SteveZ: If I print that and I've set the orthogonal flow to 1vh
  650. # [18:40] <gregwhitworth> fantasai: you can't because you can't split the line box
  651. # [18:41] <gregwhitworth> fantasai: we don't have the capability of having variable width columns
  652. # [18:42] <gregwhitworth> ChrisL: This is the type of thing that authors can't control
  653. # [18:43] <gregwhitworth> fantasai: they can set the props themselves and control this, this is only for situations where everything is auto
  654. # [18:44] <gregwhitworth> dbaron: this is making me think things are getting more and more complex, for example I'm considering not investing on grid as it keeps evolving
  655. # [18:44] <gregwhitworth> dbaron: I'm starting to regret working on writing-modes, as I want to be able to ship stuff that are valuable
  656. # [18:45] <gregwhitworth> tabatkins: this is not getting more complex, we're just starting to actually document everything instead of just saying "magic"
  657. # [18:45] <gregwhitworth> tabatkins: this is a common thing that people hit
  658. # [18:45] <gregwhitworth> florian: yes mixed modes are very common in Japenes
  659. # [18:46] <gregwhitworth> tabatkins: I understand your frustration
  660. # [18:46] <gregwhitworth> fantasai: The spec even says what to do if you don't have support for multicol
  661. # [18:47] <gregwhitworth> rossen: in the current Japanese printed world, where you're saying most of them have mixed writing modes, I've never seen them in a magazine
  662. # [18:48] <gregwhitworth> SteveZ: the most likely place you'll see this is in english text quoting Japanese text
  663. # [18:48] * Quits: johanneswilm (~johannes@public.cloak) (Ping timeout: 180 seconds)
  664. # [18:48] <gregwhitworth> SteveZ: The real problem I think is between the switch of captions
  665. # [18:48] <gregwhitworth> Rossen: again these are small chunks, not long long flows of text
  666. # [18:49] * Joins: johanneswilm (~johannes@public.cloak)
  667. # [18:49] <gregwhitworth> smfr: I we trying to do this in L3, or can we defer this until later
  668. # [18:49] <gregwhitworth> fantasai: I think that's ok, but we may run into a few edge cases with this
  669. # [18:49] <gregwhitworth> rossen: I've discussed this case so many times and yet I've never seen it, it's always something small
  670. # [18:50] <gregwhitworth> fantasai: [shows magazine example]
  671. # [18:50] <Bert> (Image from a ftf in 2012: http://www.w3.org/Talks/2012/0509-CSS-ftf/all.htm#challenge5 )
  672. # [18:50] <gregwhitworth> fantasai: talks about how the publishers adjust the layout to make it work just right
  673. # [18:51] <gregwhitworth> fantasai: we don't see what happens when you mess with the layout or change the screen size
  674. # [18:51] <gregwhitworth> fantasai: we should decide on what to do
  675. # [18:52] <tantek> fantasai: we should make it so that it doesn't clip the content
  676. # [18:52] <gregwhitworth> rossen: is anyone asking for this? if this was a very big painful point the entire Japanese publishing would let us know.
  677. # [18:52] <gregwhitworth> fantasai: sure we can defer this, but we should solvet his problem
  678. # [18:53] <gregwhitworth> rossen: I'm not saying that, we're about to add a bunch of magic, that won't be trivial to implement and cause interop issues on something that we aren't commonly told is an actual issue
  679. # [18:53] <gregwhitworth> fantasai: [shows another use case]
  680. # [18:54] <gregwhitworth> SteveZ: I think vh is the wrong thing to use for the line length, I think it would be better to use Xchars in the default font
  681. # [18:55] <gregwhitworth> rossen: I'll add to this, when I implemented orthogonal flows in IE8, when you have a mixed flow and let's say the body has a margin of 100vh you will automatically have a scrollbar even if you don't overflow
  682. # [18:56] <gregwhitworth> rossen: again, I've never heard from people about this problem though
  683. # [18:57] <gregwhitworth> fantasai: I think that ultimately the author would select the correct column height
  684. # [18:57] <gregwhitworth> SteveZ: No one can read that though
  685. # [18:58] <gregwhitworth> SteveZ: My memory, and I can't remember where from, is between 14-16 ems for Japanese
  686. # [18:58] <gregwhitworth> fantasai: As a spec author I'm not going to pick an arbituary set of numbers for font sizes
  687. # [18:58] * Bert 150px if vertical, 300px if horizontal? :-)
  688. # [18:59] <gregwhitworth> tabatkins: She's trying to just provide the same capability for vertical text as horizontal text
  689. # [19:00] <gregwhitworth> plinss: the more I think about this, the more I think this is the right solution for orthogonal flows especailly when you have n levels deep. All my other reservations stand on their own, but on this one I think this is the best solution for this
  690. # [19:00] <gregwhitworth> rossen: what happens if its a scroller, would you still do multicol
  691. # [19:01] * Quits: smfr (~smfr@public.cloak) (smfr)
  692. # [19:01] <gregwhitworth> rossen: I have a a div from overflow: visible to overflow: scroll
  693. # [19:01] <gregwhitworth> florian: it would make sense to remove the multicol
  694. # [19:01] <gregwhitworth> rossen: well that's more fairy dust and magic
  695. # [19:03] <gregwhitworth> fantasai: this will only trigger if you have auto and thus can grow in the infinite direction, a scroller will have a set height
  696. # [19:03] <gregwhitworth> plinss: what is stopping the line from being one long line, something has to be causing it to wrap
  697. # [19:03] <gregwhitworth> fantasai: you don't want to have any line of text that is longer than your viewport
  698. # [19:04] <gregwhitworth> tabatkins: that's the behavior if you don't support multicol or you have line breaks (pointing at css3 multicol example)
  699. # [19:04] <gregwhitworth> SteveZ: I still think there are enough unanswered questions that it should be defered
  700. # [19:05] <gregwhitworth> florian: There is value in shipping this, if not shipping anything at all
  701. # [19:05] <gregwhitworth> SteveZ: But you're not providing anything valuable
  702. # [19:06] <gregwhitworth> fantasai: in the case of fixed height, we're trying to avoid overflowing, which is the whole point of this
  703. # [19:06] <gregwhitworth> SteveZ: All you're doing is coming up with a height for the first block if no height is set
  704. # [19:07] <gregwhitworth> Bert_: You can turn it into a fixed height and multicol
  705. # [19:07] <gregwhitworth> Daniel: This discussion is going no where, let's wrap up
  706. # [19:07] <gregwhitworth> fantasai: I think everyone can agree to add this to the at risk list in the spec, we can agree with that
  707. # [19:07] <gregwhitworth> rossen: yep
  708. # [19:08] <gregwhitworth> fantasai: we'll see where we are
  709. # [19:08] <gregwhitworth> fantasai: if stuff ships and we don't have this, then we'll defer it
  710. # [19:09] <koji> Thank you all and sorry for making lunch late
  711. # [19:14] * Rossen is now known as Rossen_away
  712. # [19:15] * Quits: gregwhitworth (~gregwhitworth@public.cloak) (Ping timeout: 180 seconds)
  713. # [19:20] * Quits: johanneswilm (~johannes@public.cloak) (Ping timeout: 180 seconds)
  714. # [19:25] * Quits: lajava (~javi@public.cloak) (Ping timeout: 180 seconds)
  715. # [19:28] * Quits: renoirb (renoirb@public.cloak) ("Textual IRC Client: www.textualapp.com")
  716. # [19:28] * leaverou is now known as leaverou_away
  717. # [19:32] * Joins: renoirb (renoirb@public.cloak)
  718. # [19:35] * Joins: smfr (~smfr@public.cloak)
  719. # [19:36] * Joins: gregwhitworth (~gregwhitworth@public.cloak)
  720. # [19:36] <gregwhitworth> koji: no problem, thank you for staying up late!!!
  721. # [19:37] * Joins: myles (~Adium@public.cloak)
  722. # [19:38] * Joins: lajava (~javi@public.cloak)
  723. # [19:40] * Joins: johanneswilm (~johannes@public.cloak)
  724. # [19:41] * Quits: gregwhitworth (~gregwhitworth@public.cloak) ("Page closed")
  725. # [19:50] * Quits: smfr (~smfr@public.cloak) (smfr)
  726. # [20:00] * Joins: smfr (~smfr@public.cloak)
  727. # [20:06] * Quits: smfr (~smfr@public.cloak) (smfr)
  728. # [20:06] * Quits: quadcore (~user@public.cloak) ("")
  729. # [20:07] * Joins: c0rt3x (~cortex@public.cloak)
  730. # [20:10] * Joins: smfr (~smfr@public.cloak)
  731. # [20:23] * Joins: gregwhitworth (~gregwhitworth@public.cloak)
  732. # [20:24] * Quits: glazou (~glazou@public.cloak) (glazou)
  733. # [20:26] * Quits: anssik (~uid10742@public.cloak) ("Connection closed for inactivity")
  734. # [20:27] * Quits: andrey-bloomberg (~andrey-bloomberg@public.cloak) (Ping timeout: 180 seconds)
  735. # [20:30] <fantasai> ScribeNick: fantasai
  736. # [20:30] <fantasai> Topic: text-decoration-skip
  737. # [20:30] <fantasai> Florian: A while ago we resolved to add trailing-space value to text-decoration-skip in L4
  738. # [20:31] <fantasai> Florian: When using in combination with pre-wrap, you might have preserved spaces at the end of the line. Do these get underlined or not?
  739. # [20:31] <fantasai> Florian: In MS Word they do not
  740. # [20:31] <fantasai> Florian: We added a new value to be able to control this
  741. # [20:31] <fantasai> Florian: Default currently is underlining everything
  742. # [20:32] <fantasai> tantek: Why add a value for the common case? Why not just make that the default
  743. # [20:32] * Joins: bcampbell (~chatzilla@public.cloak)
  744. # [20:32] <fantasai> tantek: Barring compat problems, the default should be the desired
  745. # [20:32] <fantasai> Florian: One option is underline by default, switch off
  746. # [20:32] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
  747. # [20:32] <fantasai> Florian: Another option is don't underline by default, switch on
  748. # [20:33] <fantasai> Florian: Third option is auto value by default, which can depend on the type of pre-wrapping
  749. # [20:33] * Joins: dauwhe (~dauwhe@public.cloak)
  750. # [20:33] <fantasai> Florian: Wanted to bring up what the default should be, so that L3 has whatever we think the default shoudl be
  751. # [20:33] <fantasai> Florian: So summary is initial value
  752. # [20:33] <fantasai> 1. objects
  753. # [20:33] <fantasai> 2. objects trailing-spaces
  754. # [20:34] <fantasai> 3. auto (depends on white-space value)
  755. # [20:34] <fantasai> Florian: Related issue is whether to skip leading spaces
  756. # [20:34] * Rossen_away is now known as Rossen
  757. # [20:34] <fantasai> Florian: Judging by word processors, they don't switch behavior based on text-alignment
  758. # [20:34] * Quits: antonp (~Thunderbird@public.cloak) (antonp)
  759. # [20:34] <fantasai> Florian: MS word underlines leading spaces but not trailing spaces
  760. # [20:35] <fantasai> Florian: Not entirely sure if intentional to be assymmetric
  761. # [20:35] * Quits: c0rt3x (~cortex@public.cloak) ("")
  762. # [20:35] <fantasai> tantek: Leading spaces are visible, so kindof make sense. Trailing spaces are invisible
  763. # [20:35] <fantasai> Florian: That's true for left-alignment. Not true for right-alignment
  764. # [20:35] <fantasai> tantek: Would be good to know if there's even a single web page with right-aligned pre-wrap text
  765. # [20:35] <fantasai> fantasai: Probably not
  766. # [20:36] <fantasai> fantasai: I would prefer to keep the behavior symmetric
  767. # [20:36] <fantasai> fantasai: Another consideration is that underlining indicates links, and those spaces are clickable
  768. # [20:37] * Quits: myakura (~myakura@public.cloak) (Client closed connection)
  769. # [20:37] <fantasai> gregwhitworth: What is % use cases for links vs decoration?
  770. # [20:37] <fantasai> Florian: pre/pre-wrap used a lot for code
  771. # [20:37] * Joins: myakura (~myakura@public.cloak)
  772. # [20:37] <fantasai> Florian: trailing spaces affect layout in pre-wrap
  773. # [20:38] <fantasai> fantasai: If we're doing for pre-wrap, should do it for pre
  774. # [20:38] <fantasai> fantasai: I think if we didn't use underlining for links, then I would say don't underline leading or trailing spaces. Looks better.
  775. # [20:39] * Joins: ctcptest (~ctcptest@public.cloak)
  776. # [20:39] <fantasai> fantasai: But since we do, I think we should default to underlining
  777. # [20:39] <fantasai> fantasai: Since that indicates the clickable area
  778. # [20:39] <fantasai> Bo: We looked into use of underlining, and it's almost always used for links.
  779. # [20:39] <fantasai> Bo: were considering, for a11y, to restrict underlining to just links, and it didn't seem like it would be a problem.
  780. # [20:41] <fantasai> Florian describes case of link breaking across lines, with leading/trailing spaces
  781. # [20:42] <fantasai> tantek: I don't buy the argument that we should underline the spaces because they're clickable.
  782. # [20:42] <fantasai> tantek: Blocks have plenty of space that are clickable, not underlined
  783. # [20:43] <fantasai> ...
  784. # [20:43] <fantasai> Florian: ...
  785. # [20:44] <fantasai> fantasai: I don't have a strong preference on underlining vs not-underlining
  786. # [20:44] <fantasai> fantasai: But want leading/trailing to be symmetric
  787. # [20:44] <fantasai> tantek: Don't buy that argument
  788. # [20:44] <fantasai> Florian: People use spaces for indentation, want them underlined
  789. # [20:44] * Quits: myakura (~myakura@public.cloak) (Ping timeout: 180 seconds)
  790. # [20:44] <fantasai> fantasai: Really? That looks terrible. Why is that wanted?
  791. # [20:44] <fantasai> [discussion of what is ugly]
  792. # [20:45] <fantasai> gregwhitworth: I think we should put all three options on the board, point at the ugly one, and say, don't do that.
  793. # [20:45] <fantasai> plinss: For diff tracking, want to show underlining on spaces as well, to show what exactly is added/removed
  794. # [20:46] <fantasai> tantek: Can't imagine you want to see underlines, unless you're trying to show where the spaces are for some reason.
  795. # [20:47] * Joins: glazou (~glazou@public.cloak)
  796. # [20:47] <fantasai> plinss: Might make sense to have the default be one way, but have the UA default style sheet for <ins>, <del>, <u>, <s> not skip anything
  797. # [20:48] <fantasai> fantasai: I don't think we can change default behavior for <u> and images.
  798. # [20:48] * leaverou_away is now known as leaverou
  799. # [20:48] <fantasai> Florian: So, proposal is to skip leading/trailing by default.
  800. # [20:49] <fantasai> Florian: And UA stylesheet for <ins>/<del> underlines spaces
  801. # [20:49] <fantasai> Unsure on <u>/<s>
  802. # [20:49] <fantasai> Florian: Implies we add leading-spaces
  803. # [20:49] <fantasai> fantasai: Or edge-spaces
  804. # [20:50] <fantasai> Florian: Good point. Do we need them separately-controllable?
  805. # [20:51] <fantasai> tantek: MS Word does that. Probably not an accident
  806. # [20:51] <fantasai> fantasai: I'm not so sure about that....
  807. # [20:51] <fantasai> Florian: So anyway, proposal is that initial value skips objects, leading and trailing spaces
  808. # [20:52] * Yves sets mode: +b *!*ctcptest@*
  809. # [20:52] <fantasai> Florian: Suggest that UA stylesheet skips nothing for <ins> and <del>, skips objects (as currently) for <u> and <s>
  810. # [20:52] * Quits: ctcptest (~ctcptest@public.cloak) (KILLed by Yves: (requested))
  811. # [20:53] <fantasai> ...
  812. # [20:53] <fantasai> dbaron: Seems weird to change default behavior and change that in the UA sheet for a couple elements.
  813. # [20:53] <fantasai> plinss: ...
  814. # [20:54] <fantasai> dbaron: I suspect most of the text decoration on the web is not <u> and <s>; treating those as especially legacy seems odd
  815. # [20:54] <fantasai> Florian: Proposal makes sense to me, but breaks compat
  816. # [20:56] <fantasai> dbaron: I think I'm fine to change the default for the property. Can see use case for having different behavior on <ins>/<del>. Think it's weird to treat <u> and <s> differently from the default.
  817. # [20:56] <fantasai> dbaron: One more quirk I'd rather not add, unless there's a good argument for it.
  818. # [20:57] <fantasai> Revised proposal: skip leading/trailing spaces, <ins>/<del> don't skip anything
  819. # [20:57] <fantasai> proposal: add leading-spaces / trailing-spaces values to text-decoration-skip
  820. # [20:57] <fantasai> fantasai: I'm OK with the new defaults, a little unsure about the two keywords
  821. # [20:58] <fantasai> tantek: Worth putting in draft, then see if anyone screams
  822. # [20:59] <fantasai> Florian: L3 or L4?
  823. # [20:59] <fantasai> fantasai: I think we should put into L4 draft, get some feedback, add a note in L3 that we might switch default behavior as in [this draft over here]
  824. # [20:59] <fantasai> fantasai: in a future CR update
  825. # [21:02] <fantasai> tantek: Make a stronger statement -- it's resolved, not might happen
  826. # [21:02] <fantasai> tantek: Capture the fact that there's a consensus on the changing
  827. # [21:02] <fantasai> Bert asserts that WDs can change
  828. # [21:02] <fantasai> plinss suggests we move on
  829. # [21:02] <fantasai> fantasai^: We can change the default easily in L3, but wouldn't be able to add UA stylesheet rules without the new values from L4.
  830. # [21:03] <fantasai> RESOLVED: Add leading-spaces/trailing-spaces to text-decoration-skip in L4. Change default behavior to skip leading/trailing spaces. Add UA rule that <ins>/<del> don't skip anything. Add note from L3 to L4 indicating impending changes.
  831. # [21:04] <fantasai> Florian: Can't change behavior without new keywords
  832. # [21:04] <fantasai> fantasai: sure we can
  833. # [21:05] <fantasai> fantasai: another issue is, this is getting unweildy. To skip one new thing, need to re-specify the whole initial value, which is now three long values
  834. # [21:06] * Joins: andrey-bloomberg (~andrey-bloomberg@public.cloak)
  835. # [21:06] <fantasai> plinss: Let's refine it in L4. L3 is in CR, stable for 2 years
  836. # [21:06] <fantasai> plinss: Moving on.
  837. # [21:06] <fantasai> Topic: Box % sizing
  838. # [21:08] <Bert> (So that implies the initial value in L4 will change to 'objects trailing leading'? Seems fine, but just verifying...)
  839. # [21:08] <Florian> Bert: yes
  840. # [21:09] <Bert> s/Bert:/Bert,/
  841. # [21:09] <fantasai> Rossen: This was a discussion brought up a couple months ago. Brought up by blink team, wrt implementing flex
  842. # [21:10] <fantasai> Rossen: They came back and said that resolving top and bottom pecentages for padding and margin out of height instead of width kindof doesn't make sense to us and harder to implement for us
  843. # [21:10] <fantasai> Rossen: Bunch of discussion of what is expected behavior, why does it make sense to have top/bottom % to resolve against width rather than height
  844. # [21:11] <fantasai> Rossen: In summary there was some exchange back and forth
  845. # [21:11] <fantasai> Rossen: Having symmetric layout makes a lot of sense for app-centric layout
  846. # [21:11] <fantasai> Rossen: Other behavior makes more sense for auto-height document flows
  847. # [21:12] <Rossen> http://jsbin.com/pekiyuqalu/1/edit?output
  848. # [21:12] * fantasai kindof leans towards Ojan's POV on this issue
  849. # [21:12] <fantasai> Rossen: There's a fixed-size div with items with % padding and % width/height
  850. # [21:12] <fantasai> Rossen: One thing we identified early on in flex development
  851. # [21:12] <fantasai> Rossen: is that being able to stretch inside flex items is really useful
  852. # [21:13] <fantasai> Rossen: Here when I have 100% to the inner item, in the case of documen tflow that will compute to auto because its parent has height auto
  853. # [21:13] <fantasai> Rossen: That means that the height will be shrink-to-fit
  854. # [21:13] <fantasai> Rossen: If this were a flex item, the height of the inner item would actually resolve to 100% of the available height
  855. # [21:13] <fantasai> Rossen: That happens because the flex item is stretched by default
  856. # [21:14] <fantasai> Rossen: The one pattern that we can start noticing here is that in traditional flow layout, usually people think of the document in some kind of continuous media.
  857. # [21:14] <fantasai> Rossen: Things wrap, maybe have some tables, but the only thing you can take a hard dependency on is the available width
  858. # [21:14] <fantasai> Rossen: This is what we resolve most percentages out of
  859. # [21:14] <fantasai> Rossen: All horizontal % resolve against width, as well as padding and margin in the vertical dimension
  860. # [21:14] <fantasai> Rossen: All of these values resolve from this available width
  861. # [21:15] <fantasai> Rossen: If you have % height, that's a hard problem, we'll just default to autl
  862. # [21:15] <fantasai> Rossen: And we have this kind of assymmetric behavior
  863. # [21:15] <fantasai> Rossen: Flexbox, as well as Grid, started taking a different direction
  864. # [21:16] <fantasai> Rossen: How about we figure out a way to fix both the widht and the height, so that when resolving percent ...
  865. # [21:16] <fantasai> Rossen: If I have an item which has % width, resolves against width.
  866. # [21:16] <fantasai> Rossen: If I have an item with % height, should resolve against height
  867. # [21:16] <fantasai> Rossen: This is how we specced flexbox
  868. # [21:16] <fantasai> Rossen: And grid
  869. # [21:17] <fantasai> Rossen: In this example, we have percentage height, width, padding
  870. # [21:17] <fantasai> Rossen: Both horizontal and vertical ...
  871. # [21:18] <fantasai> Rossen: If I specify margin or padding with just one number, want the same size all around -- resolve it from just one of these dimensions
  872. # [21:18] <fantasai> Rossen: That is a valid use case
  873. # [21:18] <fantasai> Rossen: You can use grid or flexbox to have layout that simulates flow layout
  874. # [21:18] <fantasai> Rossen: I think the one use case that was brough up was an image gallery, e.g. 4 columns, want to have equal margins around photo in both dimensions
  875. # [21:19] <fantasai> Rossen: This is Chrome's implementation. Here's it's a block. If I switch and make it a flex item...
  876. # [21:20] <Rossen> http://jsbin.com/rivisiyifa/1/edit?output
  877. # [21:20] <fantasai> Rossen: Point I'm trying to make is that the flex implementation in Chrome will look basically like so...
  878. # [21:21] <fantasai> Rossen: This is our current implementation in Edge
  879. # [21:21] <fantasai> Rossen: We resolve padding and margins against the available width
  880. # [21:21] <fantasai> Rossen: The height is still 100%
  881. # [21:21] * fantasai is getting very confused
  882. # [21:21] <fantasai> Rossen: All heights are hard, now we're like theyr'e kinda sort of hard. Saying paddings and margins are hard.
  883. # [21:21] <fantasai> Rossen: This isn't really quirky behavior
  884. # [21:22] <fantasai> Rossen: One proposed solution that we came up with was to have a switch basically that allows both of these
  885. # [21:22] <fantasai> Rossen: If you want to have block-layout % resolution, should be able to express that
  886. # [21:22] <fantasai> Rossen: And if you want it symmetric, should be able to express that
  887. # [21:22] <fantasai> Rossen: And this example does exactly that.
  888. # [21:22] <fantasai> Rossen: On :hover, I'm triggering box-percent-sizing: symmetric
  889. # [21:22] * ChrisL 50 shades of quirkiness
  890. # [21:23] <fantasai> Rossen: (This is just a demo on my box, not going anywhere besides this room.)
  891. # [21:23] <fantasai> Rossen: To me, it still seems strange that we are going to the extent of resolving the heights, but not resolving top and bottom paddings
  892. # [21:24] <fantasai> TabAtkins: If flexbox is auto-sized, but flex item is % height, it will resolve
  893. # [21:24] <fantasai> Rossen shows through example
  894. # [21:25] <fantasai> Rossen: We're going to a greater effort to define available width and available height that you can depend on.
  895. # [21:25] <fantasai> Rossen: We measure the content, then go back to define the available height
  896. # [21:25] <fantasai> Rossen: Allows % to resolve
  897. # [21:25] <fantasai> Rossen: So we're doing a lot of work to keep this symmetric between available widths and heights.
  898. # [21:26] <fantasai> TabAtkins: I agreed with you at first. That's why we specified the way it is today.
  899. # [21:26] <fantasai> TabAtkins: Our implementers view is that, yes, while it is slightly more difficult for us to implement, that's besides the point.
  900. # [21:27] <fantasai> TabAtkins: However, our reason for not wanting to implement this is largely
  901. # [21:27] <fantasai> TabAtkins: nobody cares. They're not used much for anything, except one thing: hack to do aspect ratios
  902. # [21:27] <fantasai> TabAtkins: A lot of people using this hack to do aspect ratios
  903. # [21:27] <fantasai> TabAtkins: This padding hack no longer works in flexbox
  904. # [21:27] <fantasai> TabAtkins: And Mozilla gets bug reports about this
  905. # [21:28] <fantasai> TabAtkins: We're not opposed to having a switch, but want block behavior to be the default
  906. # [21:28] <fantasai> tantek: You're seriously using aspect ratio hack for this?
  907. # [21:28] <fantasai> TabAtkins: Yeah
  908. # [21:28] <fantasai> dbaron: What is this hack?
  909. # [21:29] <fantasai> TabAtkins: Say you want a variable-size element to always maintain a 2:1 aspect ratio
  910. # [21:29] <leaverou> Sorry for pointing out the obvious but if we all know that aspect ratio is needed a lot, why aren't we discussing how to add an aspect-ratio property instead?
  911. # [21:29] <fantasai> TabAtkins: You give the parent padding: 50%, relpos, and make the child abspos to fill that
  912. # [21:29] <tantek> leaverou++
  913. # [21:30] <fantasai> TabAtkins: No opposition to that. I put up a bad proposal for it.
  914. # [21:30] <fantasai> TabAtkins: My proposal was bad. It has problems. Should feel bad.
  915. # [21:30] <fantasai> TabAtkins: At some point, will do it properly. But in the meantime, this hack is where we're at.
  916. # [21:31] <fantasai> TabAtkins: Anyway, that's our argument for wanting to revert the change.
  917. # [21:32] <fantasai> fantasai: I disagree with having a switch. Mode switches for interpreting existing rules are problematic, when they combine with declarations that weren't expecting it.
  918. # [21:32] <fantasai> gregwhitworth: Like box-sizing
  919. # [21:32] <fantasai> fantasai: Right
  920. # [21:32] <fantasai> gregwhitworth: Would have been better to be symmetric from get-go
  921. # [21:32] <fantasai> tantek: yes
  922. # [21:32] <TabAtkins> <wrapper style="position: relative; padding-top:50%"><real-stuff style="position: absolute; t/r/b/l: 0">...</real-stuff></wrapper>
  923. # [21:33] <fantasai> Rossen shows example of using eprcentages
  924. # [21:33] <tantek> except with box-sizing, we made it a switch because that was the default behavior that web authors/designers actually *wanted* instead of the CSS1 spec'd default
  925. # [21:33] <fantasai> TabAtkins: In this example you could have used 3px
  926. # [21:33] <tantek> also - units wouldn't have solved box-sizing :P
  927. # [21:33] <fantasai> gregwhitworth: On a bigger screen, e.g. 75in TV, want it to be bigger.
  928. # [21:33] <fantasai> gregwhitworth: percentages are much more responsive than just using pixels
  929. # [21:34] <fantasai> TabAtkins: Case like this, the difference is pretty minimal
  930. # [21:34] <fantasai> TabAtkins: You could continue using the same thing, and it would work fine resolving against the width
  931. # [21:35] <fantasai> gregwhitworth: It makes more sense to resolve in your own dimension
  932. # [21:35] <fantasai> TabAtkins: We agree it makes more sense. But nobody cares.
  933. # [21:35] <fantasai> TabAtkins: Percentage margins/paddings are extremely rare. Main use is just the aspect-ratio hack
  934. # [21:35] * Quits: SteveZ (~SteveZ@public.cloak) (Ping timeout: 180 seconds)
  935. # [21:36] <fantasai> gregwhitworth: You went into this idealistically, changed your mind when implementability came up.
  936. # [21:36] * Quits: smfr (~smfr@public.cloak) (smfr)
  937. # [21:36] <fantasai> TabAtkins: They presented me with convincing data that nobody cared.
  938. # [21:37] <fantasai> fantasai: To be fair, Tab and I were pretty ambivalent about which way to go.
  939. # [21:37] <fantasai> Issue was Grid spec and Flexbox disagreed, and we wanted them to match. Ended up picking Grid since it seemed reasonable at the time.
  940. # [21:37] * trackbot doesn't understand that ISSUE command.
  941. # [21:37] <shane> an example of the bugs filed on firefox that Tab was talking about: https://bugzilla.mozilla.org/show_bug.cgi?id=958714
  942. # [21:38] * ChrisL trackbot, go home you are drunk
  943. # [21:38] <trackbot> Sorry, ChrisL, I don't understand 'trackbot, go home you are drunk'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.
  944. # [21:40] <fantasai> fantasai: My opinion is that, having read Ojan's argument, I agree with keeping things consistent across our layout systems
  945. # [21:40] <fantasai> fantasai: However, concerend wrt compat in changing Grid to match that. [Flexbox is incompatibility]
  946. # [21:40] <fantasai> fantasai: But not super strong opinion.
  947. # [21:40] <fantasai> dbaron: Also don't have a super strong opinion...
  948. # [21:41] <fantasai> dbaron: But block layout has a much stronger widths as input, height as output
  949. # [21:41] <fantasai> dbaron: Grid/Flexbox take input in both dimensions, differnet model, percentages this way makes more sense.
  950. # [21:41] * fantasai unsure if that was correct
  951. # [21:41] <fantasai> dbaron: Don't think aspect-ratio hack is a reason to keep this.
  952. # [21:41] <fantasai> tantek: Agree with that. If they want hacks, we can give them hacks.
  953. # [21:42] <fantasai> gregwhitworth: Resolving percent margins/padding against width doesn't make sense. App developers would be happier with percentages resolved against height.
  954. # [21:43] * Joins: smfr (~smfr@public.cloak)
  955. # [21:43] <fantasai> tantek: App developers don't speak up to browsers. We don't speak up for them, nobody does
  956. # [21:43] * Quits: gregwhitworth (~gregwhitworth@public.cloak) (Ping timeout: 180 seconds)
  957. # [21:43] <fantasai> Rossen: we do speak for them. Have a lot of app developers for Windows apps
  958. # [21:43] <fantasai> Rossen: People who come from Java or C based application backgroundsis very different than conversations with ppl who started on the web
  959. # [21:43] <tantek> which is why I'm agreeing with you Rossen
  960. # [21:43] <fantasai> Rossen: Most of these papers are used to driving their layout apps much closer than with HTML/CSS
  961. # [21:44] <fantasai> Rossen: Our struggle has been, for the first year or two, was "how do we get them out of abspos?"
  962. # [21:44] <fantasai> Rossen: Once started learing how grid & flex work, how easy it is, much more performant, was a big Aha moment.
  963. # [21:44] <fantasai> Rossen: And now converted.
  964. # [21:44] <fantasai> Rossen: To the point that XAML team is getting requests to be more like HTML/CSS
  965. # [21:45] <fantasai> TabAtkins: We're down with a switch, as long as default behavior is the old behavior
  966. # [21:45] <fantasai> fantasai: And I'm not ok with a switch
  967. # [21:45] <fantasai> dbaron: I don't think I'm ok with a switch either, for two reasons
  968. # [21:45] <fantasai> dbaron: One is that I don't like switches.
  969. # [21:45] <fantasai> dbaron: Two is that I'm not sure how easy it is to do the new behavior for blocks.
  970. # [21:45] <fantasai> TabAtkins: would just go down to zero in most cases
  971. # [21:45] <fantasai> dbaron: The current behavior is % margins on flex items.
  972. # [21:46] <fantasai> TabAtkins: And grid items
  973. # [21:46] <fantasai> shane: In the case of Android, you just can't specify percentage margins or padding
  974. # [21:46] <fantasai> ?: Or iOS
  975. # [21:46] <fantasai> shane: App dev platforms don't have percentages
  976. # [21:46] <fantasai> tantek: What? Interface Builder totally had that in the 90s....
  977. # [21:47] <fantasai> shane: Goes back to what Tab was saying. ppl don't use this, except in the case of this hack
  978. # [21:47] <fantasai> TabAtkins: It's extremely rare
  979. # [21:47] * Quits: smfr (~smfr@public.cloak) (smfr)
  980. # [21:47] <fantasai> greg: I've used that a lot...
  981. # [21:47] <fantasai> TabAtkins: Couldn't have, wouldn't work.
  982. # [21:48] <fantasai> greg: I can guarantee % are not all aspect-ratio hack.
  983. # [21:48] <fantasai> TabAtkins: Most cases where I've used them in the past, I would just use flexbox or grid for it, and it would work automatically.
  984. # [21:48] <fantasai> TabAtkins: My only web-dev cases for using margins/paddings are more-or-less gone
  985. # [21:48] <fantasai> Florian: Also box-sizing
  986. # [21:49] <fantasai> fantasai: Yeah, a lot of cases are probably "I need to use percentages, because I have to do math that adds up to 100%"
  987. # [21:49] <fantasai> TabAtkins: Almost always want borders to be consistent all the way around
  988. # [21:50] <fantasai> Florian: Want things in percent so that horizontally things add up to 100%. Vertical is auto-sized, sizes are consistent
  989. # [21:50] <fantasai> greg: What do you think, dbaron? Right now we're in a bad place. IE and Mozilla agree on this.
  990. # [21:51] <fantasai> greg: But we don't have interop
  991. # [21:51] <fantasai> dbaron: I wasn't convinced that anything needed to change.
  992. # [21:51] <fantasai> dbaron: I guess Ojan is not happy about changing chrome
  993. # [21:51] <fantasai> TabAtkins: worst case, we would change. Would highly prefer not to, not so much for implementation reasons, but because we don't believe this is the right thing to do
  994. # [21:52] <fantasai> SteveZ: It seems to me whether or not there is usage today in percentage padding, people would have liekd to use it, you couldn't do it with unresolved height
  995. # [21:52] <fantasai> SteveZ: Coming up with a definition that only really works for a hack, which we should do a better way eventually, seems like the wrong way to design a system.
  996. # [21:52] <fantasai> TabAtkins: From a theoretical POV I agree.
  997. # [21:53] <fantasai> fantasai: I don't think aspect-ratio hack would be a reason to keep this.
  998. # [21:53] <fantasai> SteveZ: I came away with wanting to switch
  999. # [21:53] <fantasai> SteveZ: Want a uniform size all the way around.
  1000. # [21:53] <fantasai> SteveZ: So I want that ability
  1001. # [21:54] <fantasai> SteveZ: but also want the ability to resolve margins/padding against the available height
  1002. # [21:54] <fantasai> TabAtkins: We don't see this being used
  1003. # [21:54] <fantasai> greg: You can't
  1004. # [21:54] <fantasai> TabAtkins: We don't see it in the width dimension either
  1005. # [21:54] <fantasai> dbaron: It does seem there is a use case for people who want something evenly around the entire size
  1006. # [21:55] <fantasai> ...
  1007. # [21:55] <fantasai> Florian: There' sno right way for box-sizing
  1008. # [21:55] <fantasai> Several: No, border-box is the right way
  1009. # [21:55] <fantasai> dbaron: The other thing we could have instead of switch is different set of units
  1010. # [21:56] <fantasai> dbaron: percents in either dimension
  1011. # [21:56] <fantasai> fantasai: pi and pb
  1012. # [21:56] <dbaron> or i% and b%
  1013. # [21:56] <fantasai> s/dimension/ inline percents and block percents/
  1014. # [21:56] * shane thinks they should be 'fizz' and 'buzz'
  1015. # [21:56] <fantasai> TabAtkins: We can't parse i%
  1016. # [21:57] <Bert> (ip and vp would parse)
  1017. # [21:57] <fantasai> Florian: Could also have the switch be a keyword rather than the property
  1018. # [21:57] <fantasai> Rossen: ...
  1019. # [21:57] <fantasai> Rossen: One model is you have content that dictates how it's going to behavio in a particular container
  1020. # [21:57] <fantasai> Rossen: Other one is container dictating how things are distributed on that level
  1021. # [21:58] * fantasai is ok with units, proposed that last time we discussed in fact
  1022. # [21:58] * fantasai doesn't want switch property
  1023. # [21:58] <Bert> ('padding-top: 5% independent')
  1024. # [21:58] <fantasai> Someone mentions calc(5ip + 7bp)
  1025. # [21:59] <fantasai> plinss: Lets you get into some really circular situations
  1026. # [21:59] <fantasai> plinss: You'd have to be really careful about where you can use them
  1027. # [21:59] <fantasai> dbaron: Percentages on some of these propertis are function of a size of the parent
  1028. # [21:59] <fantasai> dbaron: And if cyclic, treated as auto
  1029. # [21:59] <fantasai> dbaron: fall back to zero
  1030. # [21:59] <fantasai> dbaron: those rules would continue to hold
  1031. # [22:00] <fantasai> TabAtkins: Define it as part of <percentage>
  1032. # [22:00] <fantasai> fantasai: Don't think you want to do that. E.g. line-height, font-size, not really useful
  1033. # [22:00] <fantasai> dbaron: Only want them in certain functions that take <length> and <percentage> and percentage is relative to size of the parent
  1034. # [22:01] <fantasai> Florian: This is why I think a special keyword would make more sense...
  1035. # [22:01] <fantasai> ...
  1036. # [22:01] <fantasai> TabAtkins: SVG has some things that use length of diagonal, could finally calc() that
  1037. # [22:02] <fantasai> plinss: So, are we getting to a resolution?
  1038. # [22:03] <fantasai> Proposals
  1039. # [22:03] <fantasai> 1. global switch
  1040. # [22:03] <fantasai> box-percent-sizing
  1041. # [22:04] <fantasai> 2. switch as keyword
  1042. # [22:04] <fantasai> on some properties
  1043. # [22:04] * Joins: smfr (~smfr@public.cloak)
  1044. # [22:05] <fantasai> 3. ip + bp, usable in some places
  1045. # [22:05] <leaverou> fantasai: it could be useful for line-height, to fit a specific number of lines in a container with a fixed height.
  1046. # [22:06] <fantasai> 4. Nothing, settle on block
  1047. # [22:06] <fantasai> 5. Nothing, settle on symmetry
  1048. # [22:06] <fantasai> fantasai: I think 4-5 need to be combined
  1049. # [22:07] <fantasai> Florian: I just specced box-sizing, and having done that work, #1 looks like a terrible idea
  1050. # [22:07] <fantasai> Rossen: ...
  1051. # [22:07] <fantasai> tantek: No, I agree with Florian, this is much worse
  1052. # [22:08] <fantasai> greg: This is just margin/padding
  1053. # [22:08] <fantasai> fantasai: How do we know? It's called box-percent-sizing. Could also affect width/height
  1054. # [22:08] <fantasai> Rossen: Only discussing effect on margin/padding.
  1055. # [22:08] <fantasai> fantasai: 2 & 3 are strictly more powerful
  1056. # [22:09] <fantasai> fantasai: could have margins/padding be different
  1057. # [22:09] <fantasai> fantasai: Also doesn't have cascading problems
  1058. # [22:10] <fantasai> fantasai: The cascading problem is like this
  1059. # [22:10] <astearns> would ip and bp have too many restrictions on use (bp on height of floats, for example)?
  1060. # [22:11] <fantasai> fantasai: Somebody writes a declaration in percentages, expecting it to work a certain way
  1061. # [22:11] <fantasai> fantasai: Somebody else writes a box-percentage-sizing rule together with his percentage declration, expecting it to work together in that way
  1062. # [22:11] <fantasai> fantasai: The box-percentage-sizing rule ends up affecting the first declaration, changing the way it's interpreted in a way that's not expected
  1063. # [22:12] * Quits: lajava (~javi@public.cloak) (Ping timeout: 180 seconds)
  1064. # [22:13] <fantasai> Rossen: My choice is 1, but prefer 5.
  1065. # [22:14] <fantasai> Florian explains difference between 1 and 2
  1066. # [22:15] <fantasai> Florian: 2 puts keywords in margin/padding declarations, so you can have margins and paddings have different values.
  1067. # [22:15] <fantasai> Florian: Also doesn't have the cascading problem fantasai pointed out
  1068. # [22:15] <fantasai> shane: 3 is better for object model
  1069. # [22:15] <fantasai> TabAtkins: not sure about that, think it's fine
  1070. # [22:16] <fantasai> dbaron: 2 questions
  1071. # [22:16] <fantasai> dbaron: 1. Should we have a switch? 2. If so, which one? 3. What is the flexbox/grid default?
  1072. # [22:16] <leaverou> A benefit of using units is that we can in the future extend the cases they can be used in, whereas we can't change how a switch behaves.
  1073. # [22:17] <tantek> 1. no, 2. ø, 3. flexbox/grid % based on height, not block
  1074. # [22:17] <fantasai> we can't change how a global switch behaves, but can change 2 or 3
  1075. # [22:17] <fantasai> plinss: 4 vs 5
  1076. # [22:18] <dbaron> #4 - 5 votes (tab, bert, fantasai, shane, ian)
  1077. # [22:18] <dbaron> #5 - 5 votes (steve, greg, peter, rossen, tantek)
  1078. # [22:18] <dbaron> (others abstaining)
  1079. # [22:21] <fantasai> Rossen asks for feedback from lea and tantek
  1080. # [22:22] * astearns must be confused as to what 'block' and 'symmetry' mean in these choices
  1081. # [22:22] <fantasai> leaverou: I think #3 is my preference. We can't extend a global switch, but we can extend where units can be used.
  1082. # [22:22] <fantasai> leaverou: #2 is awkward, espeically if you use the keyword in places where you have multi-valued / complex values
  1083. # [22:22] <fantasai> leaverou: I think authors are already use dto percentages resolving against widths, even for vertical margins/paddings
  1084. # [22:22] <SimonSapin> astearns, "like display:block", and "percentages refer to the same direction"
  1085. # [22:22] <fantasai> leaverou: So I think there's a learnability benefit there
  1086. # [22:22] <fantasai> leaverou: Even though, if we were designing from scratch, would be better to resolve from height
  1087. # [22:22] * Rossen is now known as Rossen_away
  1088. # [22:22] * Quits: plh (plehegar@public.cloak) ("Leaving")
  1089. # [22:22] <fantasai> leaverou: but many years from against height
  1090. # [22:22] <fantasai> tantek: I actually disagree with that. This is a constant source of confusion. Would like it to stop being a source of confusion
  1091. # [22:22] <fantasai> tantek: This confuses *everybody* using CSS
  1092. # [22:22] <fantasai> tantek: We have this change to get Flex and Grid right, as layout modes
  1093. # [22:22] <fantasai> tantek: Customers that use that kind of layout on native platforms
  1094. # [22:23] <fantasai> tantek: Better to say "hey, use this new layout mode that does it right"
  1095. # [22:23] <fantasai> tantek: Lower barrier to entry, reduce number of things that make you go "huh?"
  1096. # [22:23] <astearns> agrees with tantek
  1097. # [22:23] <fantasai> leaverou: but old models still work the old way
  1098. # [22:24] <fantasai> tantek: What models? Goal of flex and grid is to not need to learn that stuff.
  1099. # [22:24] <fantasai> Florian: Nice speech. Add my vote to #5
  1100. # [22:24] * fantasai might switch too :)
  1101. # [22:25] <fantasai> greg and Tab argue over compat loads of Blink flexbox and Microsoft grid
  1102. # [22:25] * fantasai block means block-layout rules symmetry means resolve against your own axis
  1103. # [22:26] * Joins: myakura (~myakura@public.cloak)
  1104. # [22:26] <fantasai> SteveZ: You can get 3 on 2 by having 2 keywords, keywords being 'inline ' or 'block, and still use percentage value
  1105. # [22:26] <fantasai> TabAtkins: We only got two responses when we asked authors for feedback
  1106. # [22:27] <fantasai> TabAtkins: two non-sequiturs
  1107. # [22:27] * astearns was reading 'symmetry' as the margins are all symmetrical :)
  1108. # [22:27] <fantasai> fantasai: No, one was a valid answer
  1109. # [22:27] * fantasai sorry :)
  1110. # [22:27] <fantasai> smfr: Dave Hyatt is willing to change WebKit to #5
  1111. # [22:27] <fantasai> plinss: In light of discussion, let's redo the vote
  1112. # [22:28] <fantasai> #4 - 3 votes ( shane, TabAtkins , Bert)
  1113. # [22:28] <dbaron> + Ian
  1114. # [22:28] <fantasai> #5 - 12 (smfr, Florian, dbaron, steveZ, Andrey, Jet, Chris, Lea, Greg, rossen, plinss, tantek)
  1115. # [22:28] * Bert thinks a CSS-T without flexbox and a CSS-U with *only* flexbox would make sense, but attempts in the past failed and they seem stuck together forever.
  1116. # [22:29] <fantasai> #5 - 13 (smfr, Florian, dbaron, steveZ, Andrey, Jet, Chris, Lea, Greg, rossen, plinss, tantek, asteans)
  1117. # [22:29] <fantasai> #4 - 4 votes ( shane, TabAtkins , Bert, Ian)
  1118. # [22:29] <fantasai> RESOLVED: Flexbox top/bottom margins and padding resolve against height.
  1119. # [22:31] * Rossen_away is now known as Rossen
  1120. # [22:31] <fantasai> plinss: All in favor of having a switch for behavior
  1121. # [22:31] <fantasai> [half a vote]
  1122. # [22:31] <fantasai> plinss: All those opposed to a switch
  1123. # [22:31] <dbaron> (I'm abstaining)
  1124. # [22:31] <fantasai> 4 - TabAtkins, greg, fantasai, tantek
  1125. # [22:32] <fantasai> RESOLVED: No switch for now
  1126. # [22:32] * ChrisL CSS WG goes to an abstainance-only model
  1127. # [22:33] * Quits: myakura (~myakura@public.cloak) (Ping timeout: 180 seconds)
  1128. # [22:33] <astearns> late vote against switch - unit would be better
  1129. # [22:34] <fantasai> astearns, vote was for/against any of 1,2, or 2
  1130. # [22:35] <fantasai> if no way to switch behaviors is 0
  1131. # [22:35] <fantasai> vote was 0 vs. 1+2+#
  1132. # [22:35] <fantasai> vote was 0 vs. 1+2+3
  1133. # [22:35] <astearns> ah, ok
  1134. # [22:42] * glazou positive 0 or negative 0 ?-)
  1135. # [22:43] * Quits: johanneswilm (~johannes@public.cloak) (Ping timeout: 180 seconds)
  1136. # [22:46] * Joins: jdaggett (~jdaggett@public.cloak)
  1137. # [22:47] * Quits: Ms2ger (~Ms2ger@public.cloak) (Ping timeout: 180 seconds)
  1138. # [22:55] * Joins: johanneswilm (~johannes@public.cloak)
  1139. # [22:57] * Joins: gregwhitworth (~gregwhitworth@public.cloak)
  1140. # [22:57] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
  1141. # [22:57] * Joins: jdaggett (~jdaggett@public.cloak)
  1142. # [22:57] * Joins: lajava (~javi@public.cloak)
  1143. # [22:58] <plinss> jdaggett are you calling in?
  1144. # [22:58] <jdaggett> plinss: yes, when is good?
  1145. # [22:58] <plinss> now
  1146. # [22:59] <jdaggett> hang on just a sec, want to get heycam too
  1147. # [22:59] <dbaron> heycam|away, ^
  1148. # [22:59] <dbaron> (might be early for heycam)
  1149. # [23:00] <tantek> jdaggett do you have a Firefox Hello URL?
  1150. # [23:00] * heycam|away is now known as heycam
  1151. # [23:00] <plinss> jdaggett, heycam - +1-212-617-1960 for New York, +44-20-7330-7700 for London, +81-3-3201-7040 for Tokyo. PIN 295109
  1152. # [23:00] * heycam is here
  1153. # [23:00] * heycam thanks
  1154. # [23:00] <jdaggett> ok, thanks
  1155. # [23:02] <dbaron> We're the only participant
  1156. # [23:02] <dbaron> waiting for others to join
  1157. # [23:02] <dbaron> heycam's on the call
  1158. # [23:03] * leaverou is now known as leaverou_away
  1159. # [23:03] <fantasai> Topic: ????
  1160. # [23:03] <plinss> s/????/font-display-loading property/
  1161. # [23:03] <jdaggett> original proposal: http://tabatkins.github.io/specs/css-font-rendering/
  1162. # [23:03] <jdaggett> telcon discussion: https://lists.w3.org/Archives/Public/www-style/2015Apr/0143.html
  1163. # [23:03] <jdaggett> font-loading-display proposal: https://lists.w3.org/Archives/Public/www-style/2015Apr/0216.html
  1164. # [23:04] <fantasai> jdaggett: Back in march Tab had a proposal for what was called a 'font-rendering' control
  1165. # [23:04] <fantasai> jdaggett: Was to control appearance of text while font resources were loading
  1166. # [23:04] <fantasai> jdaggett: Discussed in April
  1167. # [23:04] <fantasai> jdaggett: General consensus, we want the functionality, but notion of timeouts we should drop
  1168. # [23:04] <fantasai> jdaggett: I went back and thought what we should do with it
  1169. # [23:04] <fantasai> jdaggett: Which I think is maybe a better way of going about this
  1170. # [23:05] <fantasai> jdaggett: Can we project the actual proposal?
  1171. # [23:05] <Bert> -> https://lists.w3.org/Archives/Public/www-style/2015Apr/0216.html proposal
  1172. # [23:05] * Florian Greg's doing it
  1173. # [23:05] * Florian not yet
  1174. # [23:05] * Florian ready
  1175. # [23:06] <fantasai> jdaggett: I'm proposing a new property, font-loading-display
  1176. # [23:06] <fantasai> jdaggett: 4 keywords
  1177. # [23:06] <fantasai> font-loading-display: auto | fallback | blank-fallback | blank
  1178. # [23:06] <fantasai> jdaggett: Essentially these are saying what should be displayed while font resource is downloaded
  1179. # [23:06] <fantasai> jdaggett: auto just means browser decides
  1180. # [23:06] <fantasai> jdaggett: fallback means fallback font is immediately displayed
  1181. # [23:06] <fantasai> jdaggett: blank-fallback is what FF and ? do
  1182. # [23:06] <Bert> q+ to ask if it is a property or a descriptor for @font-face.
  1183. # [23:06] <fantasai> jdaggett: Show invisible text, then show fallback font if timed out
  1184. # [23:07] <fantasai> jdaggett: blank is what safari does, show nothing until font loads
  1185. # [23:07] <fantasai> jdaggett: blank is currently not exactly Safari's behavior... Safari takes forever
  1186. # [23:07] <fantasai> jdaggett: At some point, you really need to show the user text. Can't just show a blank page
  1187. # [23:07] <fantasai> TabAtkins: As an alternate proposal, we had a discussion in blink
  1188. # [23:07] <fantasai> TabAtkins: We're fine with dropping timeouts
  1189. # [23:07] <fantasai> TabAtkins: and using the keywords from original proposal
  1190. # [23:07] * fantasai asks for link to Tab's proposal
  1191. # [23:08] <fantasai> jdaggett: blank isn't Safari's wait-forever, it's wait a long time
  1192. # [23:08] <fantasai> Florian: I agree that his blank is less bad than Safari's
  1193. # [23:08] <Bert> -> http://tabatkins.github.io/specs/css-font-rendering/ Tab's proposal
  1194. # [23:08] <fantasai> Florian: But agree with Tab that it's still pretty bad
  1195. # [23:09] * leaverou_away is now known as leaverou
  1196. # [23:09] <fantasai> Florian: There was a behavior that you display with the fallback font, start the load, and keep with the fallback font until page is reloaded, then use real font
  1197. # [23:10] <fantasai> (behavior above is optional keyword from Google's proposal)
  1198. # [23:10] <fantasai> jdaggett: The notion that during layout decide whether to display or not based on whether a font is available or not
  1199. # [23:10] <fantasai> jdaggett: If font is in the cache, finite amount of time to figure out if you have the font available
  1200. # [23:10] <fantasai> jdaggett: could be as much as 20ms
  1201. # [23:11] <fantasai> jdaggett: You're putting a big load into this keyword
  1202. # [23:11] * fantasai is confused
  1203. # [23:11] <fantasai> TabAtkins: No, we're not.
  1204. # [23:11] <fantasai> TabAtkins: It's about a very small UA-defined timeout. If you've loaded within that time, great. If not, cache is cold, then keep with the fallback font.
  1205. # [23:11] <fantasai> jdaggett: My point is, there will always be a flash.
  1206. # [23:12] <fantasai> Florian: The problem isn't with flash
  1207. # [23:12] <fantasai> Florian: The problem is with partway into reading the page
  1208. # [23:12] <fantasai> Florian: And then stuff shifts under you
  1209. # [23:12] <fantasai> TabAtkins: Our timeout for optional is, are we at the point where we're putting the text on the page?
  1210. # [23:12] <fantasai> TabAtkins: If not there yet and loaded font, then go use font
  1211. # [23:12] <fantasai> TabAtkins: Otherwise render with falback font
  1212. # [23:13] <fantasai> dbaron: I think definition that you gave means some implementations will never use the optional font, and that's what we don't want
  1213. # [23:13] <fantasai> fantasai: I don't understand what that means
  1214. # [23:14] <fantasai> dbaron: Some implementations would have never loaded the font by the time they do the paint
  1215. # [23:14] <fantasai> TabAtkins: They never see that font. From first paint onward, no change in font
  1216. # [23:14] <fantasai> heycam: I think expectation is that first time, very good chance it won't show, but next time load a page from that site, will see the font.
  1217. # [23:14] <fantasai> jdaggett: In a lot of situations, where you really want this is mobile devices
  1218. # [23:14] <fantasai> jdaggett: where the connection is slowery
  1219. # [23:14] * Rossen is now known as Rossen_away
  1220. # [23:15] <fantasai> jdaggett: But those mobile devices are severely resource-constrained
  1221. # [23:15] <fantasai> jdaggett: Whether something shows up in cache is a crapshoot
  1222. # [23:15] <fantasai> TabAtkins: That's one of the main cases
  1223. # [23:15] <fantasai> TabAtkins: They are the ones that are most likely to not render the optional font
  1224. # [23:15] <fantasai> plinss: Better for mobile perf
  1225. # [23:15] <fantasai> jdaggett: font loading API gives authors the most control
  1226. # [23:16] <plinss> s/perf/perf</sarcasm>/
  1227. # [23:16] <fantasai> jdaggett: I think it makes more sense for authors to script this, rather than having non-interop
  1228. # [23:16] * hober that joke is so 2014, plinss :)
  1229. # [23:16] <fantasai> TabAtkins: I'm ok with delaying on the optional keyword until we have something we agree on
  1230. # [23:16] <fantasai> fantasai: I think 'optional' makes sense. I would probably want that behavior.
  1231. # [23:17] * plinss hober, the old jokes will continue until mobile perf improves
  1232. # [23:17] <fantasai> dbaron: I would be OK with some definitions of optional, like Florian's definition
  1233. # [23:17] <fantasai> dbaron: Florian's definition was about some small amount of time. Not predicated on drawing text.
  1234. # [23:17] <fantasai> Florian: Things might flash very briefly, but won't shift under you once you've started reading.
  1235. # [23:17] <fantasai> jdaggett: I think in practice, you'll find that for a certain set of devices that happen to be at some level of cache storage
  1236. # [23:18] <fantasai> jdaggett: going to end up seeing on one view,not see the font, then next view see the font, then load a bunch of stuff, not see hte font, later then see the font
  1237. # [23:18] <fantasai> jdaggett: Don't think usability would be great on this
  1238. # [23:18] <fantasai> TabAtkins: I disagree. This is better for optional uses.
  1239. # [23:18] <fantasai> TabAtkins: Better to be stable on a given page than swap sometime while you're reading.
  1240. # [23:19] <fantasai> jdaggett: I think the criteria for optional, there are more parameters that you'll want to use
  1241. # [23:19] <fantasai> jdaggett: Think it's better to leave optional behavior to script.
  1242. # [23:20] <fantasai> fantasai: I don't want to require script for this. This is a reasonable behavior that I'd want, and I don't want to script it.
  1243. # [23:20] <fantasai> fantasai: Wouldn't want someone reading my article to have the text shift around 30 seconds after starting to read
  1244. # [23:21] <fantasai> fantasai: just to have a nicer font
  1245. # [23:21] <Bert> (What does "optional" mean? Aren't all fonts optional? As long as there is at least one.)
  1246. # [23:21] <fantasai> jdaggett: My concern is that flipping back and forth between pages, the font loads, and then the current layout isn't the same as the previous layout
  1247. # [23:21] <fantasai> jdaggett: We should leave it to authors to script this, and then if there's a pattern that evovlves, then we can put it into a CSS keyword
  1248. # [23:22] * Rossen_away is now known as Rossen
  1249. # [23:22] <fantasai> jdaggett: I'm unconvinced that this is something we should specify with just a timeout on the font resource. Also want to consider what's the state of the page? Are we rendering? etc. Will be parameters not captured by the proposal.
  1250. # [23:22] <fantasai> TabAtkins: Our argument is that there's a common enough case that we can handle now. Script can handle more complicated cases.
  1251. # [23:23] <fantasai> tantek: Page changing the second time you load it -- when you go back to it. Or the case where you navigate back to it from another page
  1252. # [23:23] <fantasai> tantek: That's a red herring.
  1253. # [23:23] <fantasai> tantek: Web pages change all the time over time
  1254. # [23:23] <fantasai> tantek: Images, ads load over time, new buttons, whatever
  1255. # [23:23] <fantasai> tantek: I don't think it's that disturbing t
  1256. # [23:24] <fantasai> jdaggett: But if I read halfway through an article, flip to my mail app, flip back and it rerenders
  1257. # [23:24] <fantasai> jdaggett: that's bad
  1258. # [23:24] <fantasai> fantasai: That's exactly the point we're making! [except it changes while you're reading and not even you flipped anything]
  1259. # [23:24] <tantek> that's not bad, that's how the web works today
  1260. # [23:25] <jdaggett> the problem is the rerender now renders with a different font which no longer lays out the same way
  1261. # [23:25] <jdaggett> and the position where i was reading has now been lost!!
  1262. # [23:25] <fantasai> dbaron: The google proposal for optional was basically was aiming for a zero-second timeout, or something very close to it
  1263. # [23:25] <fantasai> dbaron: What Tantek and Elika are saying is that they'd be happy with the 3 second time out
  1264. # [23:25] <fantasai> tantek: Yeah, I'm ok with both
  1265. # [23:25] <fantasai> dbaron: But then you fall back
  1266. # [23:26] <fantasai> dbaron: In some ways, that's very similar to what's there with the blank-fallback
  1267. # [23:26] <fantasai> dbaron: It's already wait for 3 seconds, if it's not loaded fall back
  1268. # [23:26] <fantasai> TabAtkins: No. It's don't show anything for 3 seconds, then show the fallback font, then load the real font and render with it onces it's loaded
  1269. # [23:26] <tantek> 3 seconds is too long
  1270. # [23:27] <Florian> tantek: +1
  1271. # [23:27] <fantasai> discussion of case where links were invisible for 3 seconds while res tof page was visible, 'cuz using different font for links. Was very confusing.
  1272. # [23:27] <fantasai> dbaron: I think there are 3 quesitons
  1273. # [23:27] <fantasai> dbaron: 1. What is the timeout after which your behavior changes
  1274. # [23:27] <fantasai> dbaron: 2. What do you do before you hit that time?
  1275. # [23:28] <fantasai> dbaron: 3. What do you if the font loads after that timeout?
  1276. # [23:28] <fantasai> Florian: There might be two timeouts.
  1277. # [23:28] <jdaggett> can't hear!!!
  1278. # [23:28] * heycam ok :)
  1279. # [23:28] <fantasai> Florian: There's potentially 2 thresholds
  1280. # [23:28] <fantasai> Florian: 1 where initially you might be blank or show fallback
  1281. # [23:29] <tantek> what's the timeout threshold for showing alt-text while waiting to load an image?
  1282. # [23:29] <fantasai> Florian: Then the font comes in
  1283. # [23:29] <ChrisL> similar issue with "You must NEVER do this" where NEVER uses a downloaded font and has not loaded.
  1284. # [23:29] * heycam cannot hear Tab at all
  1285. # [23:29] <fantasai> TabAtkins: My spec is exactly that model
  1286. # [23:29] <jdaggett> can't hear you now!!
  1287. # [23:29] <jdaggett> someone sitting on the mike?!?
  1288. # [23:29] <tantek> jdaggett: we're working on it
  1289. # [23:29] <jdaggett> kk
  1290. # [23:29] <tantek> how about now?
  1291. # [23:29] <dbaron> the mics all ran out of attery
  1292. # [23:29] <dbaron> battery
  1293. # [23:29] <jdaggett> good!
  1294. # [23:30] <jdaggett> ah
  1295. # [23:30] <dbaron> so we had to switch to hand mics
  1296. # [23:30] <dbaron> and pass them around
  1297. # [23:30] <jdaggett> charger?
  1298. # [23:30] <fantasai> TabAtkins: There are 3 periods: blank period, swap-if-it-comes-in-otherwise-show-fallback period, screw-it-just-stick-with-fallback
  1299. # [23:30] <fantasai> TabAtkins: Called the blank, swap, and fallback periods
  1300. # [23:30] <fantasai> TabAtkins: Keywords just set the boundaries between those three periods to different values
  1301. # [23:31] <fantasai> Florian: I would like to stick with that model.
  1302. # [23:31] <fantasai> Florian: I would like to make the periods user-defined.
  1303. # [23:31] <fantasai> s/I/Having removed timeouts, I/
  1304. # [23:32] <jdaggett> s/user-defined/user-agent defined/
  1305. # [23:32] <fantasai> Florian: There are two times that you'd need user-agent defined -- one is "almost instantaneously", and the other is "after a little while (e.g. 3sec, but not exactly that necessarily)"
  1306. # [23:32] <fantasai> Florian: I don't know how it's defined right now, ...
  1307. # [23:33] <fantasai> TabAtkins: Right now it says "Xs or whatever UA heuristics you want"
  1308. # [23:33] <fantasai> jdaggett: I think the keywords from that proposal are really awful
  1309. # [23:33] <fantasai> jdaggett: Would prefer to go along the lines of what we've got in font-loading-display property
  1310. # [23:33] <smfr> q+
  1311. # [23:33] * heycam can't hear smfr
  1312. # [23:33] * Quits: andrey-bloomberg (~andrey-bloomberg@public.cloak) (Ping timeout: 180 seconds)
  1313. # [23:34] <fantasai> plinss: Another difference is that one has a property only, and the other is descripter and property
  1314. # [23:34] <dbaron> we had good table microphones, and it seems their batteries all last until 5:15pm and then give out
  1315. # [23:34] <fantasai> smfr: In webkit, we don't want different font loading behavior per element.
  1316. # [23:34] <fantasai> smfr: We're happy with a rule in the font descriptor, but not in elements.
  1317. # [23:35] <fantasai> smfr: Don't want to have situation where font is loaded but can only be used in some elements.
  1318. # [23:35] <TabAtkins> q+ ChrisL
  1319. # [23:35] <plinss> ack smfr
  1320. # [23:35] <fantasai> Rossen: I have a more general question related to the topic
  1321. # [23:35] <fantasai> Rossen: Strikes me a little bit surprising , dealing with resource handling in CSS
  1322. # [23:35] <fantasai> Rossen: I get it that fonts are intrinsically very important for everything else that we do
  1323. # [23:35] <dbaron> also, we have a hard stop in about 15 minutes for dinner, if my memory serves
  1324. # [23:35] <fantasai> Rossen: But we're not doing anything like this for images or other media loading
  1325. # [23:35] <fantasai> Rossen: whyare we doing this for fonts?
  1326. # [23:35] <fantasai> fantasai: Because for fonts you can have a fallback
  1327. # [23:36] <fantasai> TabAtkins: And text is more improtant than images
  1328. # [23:36] <fantasai> smfr: We've had requests for pseudo-class for loading state of images (not-yet-loaded)
  1329. # [23:36] * Joins: routed (~user@public.cloak)
  1330. # [23:36] <fantasai> ChrisL: I agree that this make smore sense as a descriptor than a property.
  1331. # [23:36] <fantasai> ChrisL: Not per-element basis
  1332. # [23:37] <fantasai> Florian: Generally yes, but in some cases, you may have the same font and headlines and body, and you're OK with the headlines flickering, but not the body flickering.
  1333. # [23:37] <fantasai> Florian: So both are useful. If we only have one, descriptor is better.
  1334. # [23:37] <ChrisL> ok, I can go with that
  1335. # [23:37] <fantasai> heycam: Could get same behavior by using descriptors
  1336. # [23:37] <fantasai> heycam: define different @font-face rules
  1337. # [23:37] <fantasai> smfr: Concerned about overhad for implementations, using a property
  1338. # [23:38] <fantasai> Florian: If only one, descriptors only
  1339. # [23:38] <fantasai> smfr: font descriptor can have more than one font, so need to define behavior there
  1340. # [23:38] <fantasai> TabAtkins: The timeout is for initialy using a font name
  1341. # [23:38] <fantasai> TabAtkins: So if the first one fails at 1s, other one came in within 1.5s later, then still made it within the 3s timeout
  1342. # [23:39] <tantek> :partial pseudo-element for proposed in 1998 for partially loaded elements including images. https://www.w3.org/Style/Group/1998/09/progrend-19980930
  1343. # [23:39] <fantasai> TabAtkins: If we consider that we already agree that we can leave discussion of explicit timeouts to later
  1344. # [23:39] <tantek> (apologies for the member-only link - that was before I knew better ;) )
  1345. # [23:39] <dbaron> (restaurant said they could only do a large group dinner if we came at 6pm)
  1346. # [23:39] <fantasai> TabAtkins: I'm fine with leaving optional out for now, while we discuss something that makes everybody happy
  1347. # [23:39] <fantasai> TabAtkins: Have two other behaviors that everyone agrees on:
  1348. # [23:40] * tantek dbaron how far is the restaurant?
  1349. # [23:40] <fantasai> TabAtkins: a) swap - start with fallback, if font loads in reasonable amount of time, show it otherwise stay with fallback
  1350. # [23:40] * heycam finds in Tab's accent that "blank" and "blink" sound pretty similar :)
  1351. # [23:41] <fantasai> TabAtkins: b) blank - start with blank until it loads, if hasn't loaded by the blank timeout, use fallback
  1352. # [23:41] * tantek heycam good point
  1353. # [23:41] * fantasai is confused about stability after 30s
  1354. # [23:41] <fantasai> leaverou: Why would you want blank?
  1355. # [23:41] <fantasai> TabAtkins: Things like brand identity, better to wait to display than to display in fallback font
  1356. # [23:41] <tantek> what about font-loading to render the alt text on an image that's taking too long to load?
  1357. # [23:41] <fantasai> plinss: Not really ideal for body text
  1358. # [23:42] * glazou that’s 30 seconds or thirty years?-)
  1359. # [23:42] <fantasai> fantasai: What happens if font loads after 30 seconds?
  1360. # [23:42] <fantasai> TabAtkins: under my proposal you have an infinite swappable period
  1361. # [23:42] <fantasai> TabAtkins: will always load the real font once it loads
  1362. # [23:43] <fantasai> heycam: Unless we make 30 seconds author-controllable, not sure about new hardcoded timeout
  1363. # [23:44] <fantasai> dbaron: Nobody suggesting 30s as a timeout for anything. Just as an example
  1364. # [23:44] * tantek glazou yeah seriously. ^.^
  1365. # [23:44] <fantasai> dbaron: of a time after every timeout discussed
  1366. # [23:44] <fantasai> dbaron: anyway
  1367. # [23:44] <fantasai> dbaron: These two behaviors you're discussing
  1368. # [23:44] * glazou tantek, we are all confused about stability after 30, right?-)
  1369. # [23:44] * tantek is still wondering about alt text
  1370. # [23:44] <fantasai> dbaron: They vary on two characteristics: what you do before, and also what you do after
  1371. # [23:45] * tantek glazou learning rock climbing helped with stability.
  1372. # [23:45] <fantasai> TabAtkins: If you have a font that you really-really want to use, want blank
  1373. # [23:45] <fantasai> TabAtkins: Not great for body text
  1374. # [23:45] <fantasai> TabAtkins: For cases where blocking behavior is intended
  1375. # [23:45] * glazou tantek I chose another path, divorce :-D
  1376. # [23:45] <fantasai> TabAtkins: Having it load after an arbitrary amount of time [...]
  1377. # [23:45] <jdaggett> um, *lots* of sites use fonts for body text
  1378. # [23:45] * tantek glazou didn't that choice, and don't envy you for having it and doing it.
  1379. # [23:46] <fantasai> TabAtkins: For swapping behavior want to prioritize user something or other .....
  1380. # [23:46] * tantek didn't *have
  1381. # [23:46] <fantasai> TabAtkins: Can we agree that these two behaviors are good
  1382. # [23:46] <fantasai> fantasai: No
  1383. # [23:46] * fantasai takes a break
  1384. # [23:46] * Florian john you're not minuted
  1385. # [23:46] * Joins: gregwhitworth_ (~gregwhitworth@public.cloak)
  1386. # [23:46] <gregwhitworth_> scribenick: gregwhitworth
  1387. # [23:47] <gregwhitworth_> dbaron: John doesn't have one that never swaps
  1388. # [23:48] * Joins: gregwhitworth__ (~gregwhitworth@public.cloak)
  1389. # [23:48] * Quits: shepazu (schepers@public.cloak) ("My Mac has gone to sleep. ZZZzzz…")
  1390. # [23:48] * Quits: gregwhitworth (~gregwhitworth@public.cloak) (Ping timeout: 180 seconds)
  1391. # [23:49] <gregwhitworth__> adjourned
  1392. # [23:49] * Quits: ChrisL (clilley@public.cloak) ("Client combusted")
  1393. # [23:49] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
  1394. # [23:50] * Quits: glazou (~glazou@public.cloak) (glazou)
  1395. # [23:51] * Quits: lajava (~javi@public.cloak) (Ping timeout: 180 seconds)
  1396. # [23:51] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
  1397. # [23:51] * Quits: smfr (~smfr@public.cloak) (smfr)
  1398. # [23:51] * Joins: Florian (~Florian@public.cloak)
  1399. # [23:53] * Quits: tantek (~tantek@public.cloak) (tantek)
  1400. # [23:54] * Quits: gregwhitworth_ (~gregwhitworth@public.cloak) (Ping timeout: 180 seconds)
  1401. # [23:55] * Rossen is now known as Rossen_away
  1402. # [23:56] * Quits: gregwhitworth__ (~gregwhitworth@public.cloak) (Ping timeout: 180 seconds)
  1403. # [23:57] * Quits: johanneswilm (~johannes@public.cloak) (Ping timeout: 180 seconds)
  1404. # [23:58] * Quits: Florian (~Florian@public.cloak) (Ping timeout: 180 seconds)
  1405. # [23:59] * leaverou is now known as leaverou_away
  1406. # Session Close: Wed May 20 00:00:00 2015

Previous day, Next day

Think these logs are useful? Then please donate to show your gratitude (and keep them up, of course). Thanks! — Krijn