/irc-logs / w3c / #fx / 2015-02-10 / end

Options:

Previous day, Next day

  1. # Session Start: Tue Feb 10 00:00:00 2015
  2. # Session Ident: #fx
  3. # [00:07] * Quits: nikos (~uid28403@public.cloak) (Client closed connection)
  4. # [00:08] * Quits: TabAtkins (~sid11559@public.cloak) (Ping timeout: 180 seconds)
  5. # [01:05] * Joins: TabAtkins (~sid11559@public.cloak)
  6. # [01:30] * Joins: nikos (~uid28403@public.cloak)
  7. # [02:45] * heycam is now known as heycam|away
  8. # [03:24] * heycam|away is now known as heycam
  9. # [03:45] * Quits: shepazu (schepers@public.cloak) ("My Mac has gone to sleep. ZZZzzz…")
  10. # [04:02] * Joins: shepazu (schepers@public.cloak)
  11. # [04:15] * leaverou is now known as leaverou_away
  12. # [04:16] * leaverou_away is now known as leaverou
  13. # [06:46] * leaverou is now known as leaverou_away
  14. # [08:07] * leaverou_away is now known as leaverou
  15. # [08:18] * Quits: nikos (~uid28403@public.cloak) ("Connection closed for inactivity")
  16. # [08:21] * heycam is now known as heycam|away
  17. # [08:28] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
  18. # [12:35] * Joins: dbaron (~dbaron@public.cloak)
  19. # [12:42] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
  20. # [23:05] * heycam|away is now known as heycam
  21. # [23:08] * Joins: RRSAgent (rrsagent@public.cloak)
  22. # [23:08] <RRSAgent> logging to http://www.w3.org/2015/02/10-fx-irc
  23. # [23:09] <ed> RRSAgent, stay
  24. # [23:09] <RRSAgent> ok, ed; I will stay here even if the channel goes idle
  25. # [23:11] * Joins: dbaron (~dbaron@public.cloak)
  26. # [23:12] <ed> RRSAgent, make logs public
  27. # [23:12] <RRSAgent> I have made the request, ed
  28. # [23:12] <ed> RRSAgent, this meeting spans midnight
  29. # [23:12] <RRSAgent> ok, ed; I will not start a new log at midnight
  30. # [23:13] <ed> Meeting: FXTF F2F, Sydney 2015
  31. # [23:13] <ed> Chair: ed
  32. # [23:14] * Joins: glazou (~glazou@public.cloak)
  33. # [23:14] * Joins: liam (liam@public.cloak)
  34. # [23:14] * Joins: iank (~sid43239@public.cloak)
  35. # [23:14] * Joins: Zakim (zakim@public.cloak)
  36. # [23:15] * Joins: cyril (~cyril@public.cloak)
  37. # [23:15] <glazou> Zakim, this meetings spans over midnight
  38. # [23:15] <Zakim> I don't understand 'this meetings spans over midnight', glazou
  39. # [23:15] <cyril> Zakim, this meeting spans over midnight
  40. # [23:15] <Zakim> I don't understand 'this meeting spans over midnight', cyril
  41. # [23:15] * Joins: nikos (~uid28403@public.cloak)
  42. # [23:15] * Joins: dino (~textual@public.cloak)
  43. # [23:16] <cyril> RRSAgent, this meeting spans over midnight
  44. # [23:16] <RRSAgent> I'm logging. I don't understand 'this meeting spans over midnight', cyril. Try /msg RRSAgent help
  45. # [23:16] <dbaron> RRSAgent, this meeting spans midnight
  46. # [23:16] <RRSAgent> ok, dbaron; I will not start a new log at midnight
  47. # [23:16] <heycam> RRSAgent, this is FXTF
  48. # [23:16] <RRSAgent> I'm logging. I don't understand 'this is FXTF', heycam. Try /msg RRSAgent help
  49. # [23:16] <heycam> ScribeNick: heycam
  50. # [23:16] <heycam> Scribe: Cameron
  51. # [23:17] <plinss> zakim, this is fxtf
  52. # [23:17] <Zakim> sorry, plinss, I do not see a conference named 'fxtf' in progress or scheduled at this time
  53. # [23:17] * liam notes, Achievement Unlocked for dbaron: RRSAgent Mastery
  54. # [23:17] <ed> Agenda: https://wiki.csswg.org/planning/sydney-2015 (Wednesday)
  55. # [23:18] <heycam> Topic: css3-ui
  56. # [23:18] * Joins: kwkbtr (~kwkbtr@public.cloak)
  57. # [23:18] * Joins: gregwhitworth (~gregwhitworth@public.cloak)
  58. # [23:18] * Joins: tantek (~tantek@public.cloak)
  59. # [23:18] * Joins: Florian (~Florian@public.cloak)
  60. # [23:23] <heycam> https://lists.w3.org/Archives/Public/www-style/2015Feb/0243.html
  61. # [23:23] <tantek> hello
  62. # [23:23] <tantek> https://lists.w3.org/Archives/Public/www-style/2015Feb/0243.html
  63. # [23:23] <tantek> [css3-ui] box-sizing and replaced element intrinsic width and/or ratios
  64. # [23:23] <tantek> regarding this issue: https://wiki.csswg.org/spec/css3-ui#issue-69
  65. # [23:24] <heycam> tantek: the first email I posted a couple of test cases
  66. # [23:24] <heycam> ... each has an HTML file and three SVG elements
  67. # [23:24] <heycam> ... the first one we should bring up is the replaced element test case
  68. # [23:24] * Joins: rbyers (~sid31141@public.cloak)
  69. # [23:25] <heycam> ... it shows what happens in three different cases of embedding SVG as an image that has intrinsic width and ratio, or just intrinsic width, or just intrinsic ratio
  70. # [23:25] <heycam> ... and what happens when you apply the max-height property to it
  71. # [23:25] <heycam> ... shows interaction of CSS 2.1 width computations and embedding replaced SVG element
  72. # [23:25] <heycam> ... I want to start with this example because it's all stuff that should "just work" across browsers, btu we found differences that merit questions
  73. # [23:25] <heycam> ... before we decide what box-sizing should do in these cases
  74. # [23:25] * Joins: roc (~chatzilla@public.cloak)
  75. # [23:25] <heycam> [florian projects replaced-element-001.html]
  76. # [23:25] * Joins: Tav (~tbah@public.cloak)
  77. # [23:26] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
  78. # [23:26] * Joins: stakagi (~stakagi@public.cloak)
  79. # [23:27] * Quits: stakagi (~stakagi@public.cloak) ("Leaving...")
  80. # [23:27] * Joins: stakagi (~stakagi@public.cloak)
  81. # [23:27] <heycam> tantek: in doing these tests we didn't find any differences between Blink and Safari
  82. # [23:27] <heycam> ... there are some interesting things going on here
  83. # [23:27] * Joins: dbaron (~dbaron@public.cloak)
  84. # [23:27] <heycam> ... I put the style rules that are taking place at the top
  85. # [23:27] <heycam> ... that apply to each SVG element
  86. # [23:27] <heycam> ... then the SVG markup inline so you can see what the source is
  87. # [23:28] <heycam> ... my understanding is that the top row should all be yellow square
  88. # [23:28] <heycam> ... 150x150 px
  89. # [23:28] <heycam> ... it looks like IE is doing the wrong thing there
  90. # [23:28] * Joins: murakami_ (~murakami@public.cloak)
  91. # [23:28] <heycam> ... by not maintaining the aspect ratio
  92. # [23:28] <heycam> ... that's in the SVG file
  93. # [23:28] <heycam> ... first, I want to verify that that's correct and that it's a bug in IE
  94. # [23:28] <heycam> fantasai: so the specified width is 100px?
  95. # [23:28] <heycam> tantek: no the intrinsic width is
  96. # [23:28] <heycam> fantasai: and the specified width is not specified?
  97. # [23:28] <heycam> tantek: correct
  98. # [23:28] <heycam> dbaron: and it has a viewBox such that it has an intrisic ratio of 1:1
  99. # [23:29] <heycam> Florian: and there is max-height: 100px that shouldn't take effect
  100. # [23:29] <heycam> ... but if you look at IE it seems to be doing something
  101. # [23:29] * dbaron RRSAgent, pointer?
  102. # [23:29] * RRSAgent See http://www.w3.org/2015/02/10-fx-irc#T22-29-10
  103. # [23:29] <heycam> ... both IE and safari are doing strange things on the bottom
  104. # [23:30] <heycam> tantek: I want to check with SVG people that these cases are buggy in the browsers
  105. # [23:30] <tantek> https://lists.w3.org/Archives/Public/www-style/2015Feb/0243.html
  106. # [23:30] * Joins: SimonSapin (~simon@public.cloak)
  107. # [23:31] <heycam> gregwhitworth: in Edge the top yellow one is fixed, the bottom one is the same as Firefox/Presto
  108. # [23:31] * Joins: jun (~jun@public.cloak)
  109. # [23:31] <heycam> Florian: so that confirms the IE cases I'm looking at are bugs
  110. # [23:31] <heycam> ... IE11
  111. # [23:31] * Joins: AndreyR_ (~AndreyR@public.cloak)
  112. # [23:31] <heycam> tantek: so latest IE11 and latest Safari are buggy in handling intrinsic ratio, but not intrinsic width/height
  113. # [23:31] <heycam> ... and Chrome does the same as Safari, so Blink/WebKit must be the same
  114. # [23:31] <heycam> dbaron: Safari is buggy on the third case
  115. # [23:32] * Joins: fantasai (~fantasai@public.cloak)
  116. # [23:32] * Joins: xidorn (~upsuper@public.cloak)
  117. # [23:32] * Joins: smfr (~smfr@public.cloak)
  118. # [23:32] <heycam> heycam: we had a big discussion about SVG sizing last year at a F2F
  119. # [23:33] <heycam> ... I don't remember the details except that we resolved on Firefox's behaviour modulo some corner cases
  120. # [23:33] <heycam> tantek: so Edge has these fixed, and I'm hoping that WebKit/Blink can fix the third sub-test
  121. # [23:34] <heycam> ... so this isn't the actual issue I want to discuss; just want to get a baseline about which behaviour is correct
  122. # [23:34] <heycam> ed: I think the behaviour on the left side is what we want
  123. # [23:35] <heycam> krit: people who are very familiar with this topic are not in this room so I would like to consult them
  124. # [23:36] <heycam> ACTION: Dirk to confirm that the Firefox/Presto behaviour of this SVG sizing test is correct and get back to Tantek
  125. # [23:36] * trackbot is creating a new ACTION.
  126. # [23:36] * RRSAgent records action 1
  127. # [23:36] <trackbot> Created ACTION-87 - Confirm that the firefox/presto behaviour of this svg sizing test is correct and get back to tantek [on Dirk Schulze - due 2015-02-17].
  128. # [23:36] * Joins: shane (~sid61558@public.cloak)
  129. # [23:36] <heycam> tantek: so we'll switch to box-sizing-replaced-element-001.html
  130. # [23:37] <tantek> second test here: https://lists.w3.org/Archives/Public/www-style/2015Feb/0243.html
  131. # [23:37] <tantek> file name box-sizing-replaced-element-001.html
  132. # [23:37] <heycam> tantek: what the box-sizing property allows you to do is change what width/height properties do
  133. # [23:37] <heycam> ... you can make them include the borders and padding of the element
  134. # [23:37] <heycam> ... so if you want to figure out the content width you would subtract the border/padding
  135. # [23:37] <heycam> ... any question about box-sizing:border-box?
  136. # [23:37] <heycam> ... (default behaviour is content-box)
  137. # [23:38] <tantek> http://dev.w3.org/csswg/css-ui-3/#propdef-box-sizing
  138. # [23:38] * Parts: tantek (~tantek@public.cloak) (tantek)
  139. # [23:38] * Joins: tantek (~tantek@public.cloak)
  140. # [23:38] <tantek> hello?
  141. # [23:38] <heycam> tantek: in this one, because box-sizing is set to border-box, now the 40px solid transparent border kicks in, and cuts out from the max-height
  142. # [23:38] <heycam> Florian: we still have an SVG file with an intrinsic width of 100 and a viewBox ratio of 1:1
  143. # [23:39] <heycam> tantek: identical SVG files to the previous test
  144. # [23:39] <heycam> ... the three subtests are in the same order as the previous test
  145. # [23:39] * Joins: jet|aus (~uid49872@public.cloak)
  146. # [23:39] <heycam> dbaron: I think the firefox behaviour on the second subtest is clearly buggy
  147. # [23:39] * jet|aus is now known as jet
  148. # [23:39] <heycam> ... I think we're applying to the box-sizing to the width that is coming from inside the SVG, which we should not be doing
  149. # [23:40] <heycam> fantasai: are these embedded cases?
  150. # [23:40] <heycam> Florian: SVG in <img>
  151. # [23:40] <heycam> ... as far as we can tell Presto is doing the right thing here
  152. # [23:40] <heycam> tantek: we think that is the desired result, so we want to check
  153. # [23:40] <heycam> dbaron: I agree
  154. # [23:40] <heycam> fantasai: should be equivalent to max-height:110px?
  155. # [23:40] <heycam> Florian: max-height:70px
  156. # [23:40] <heycam> tantek: on the first row we have IE and Safari agreeing on the wrong thing
  157. # [23:41] <heycam> ... so we just want to confirm our assumption on which is right/wrong
  158. # [23:41] <heycam> fantasai: one thing making it more confusing is that the content box height is different
  159. # [23:41] <heycam> ... so if you put border:25px max-height:200px you should get the same result as the previous test
  160. # [23:41] <heycam> ... the boundary of the width of the SVG is 100px, in the prev test you were above that, in this test you're below that
  161. # [23:41] <heycam> ... so you're triggering different cases
  162. # [23:41] <heycam> ... I think you should test in all cases above the trigger point, or all below the trigger point
  163. # [23:42] <heycam> ... the behaviour differenes might be due to something other than max-height
  164. # [23:42] <heycam> tantek: so we changed just one property to see what happens
  165. # [23:42] <heycam> fantasai: the numbers you picked made it change more than one thing
  166. # [23:42] <heycam> tantek: that was unintentional
  167. # [23:42] <ed> s/ed: I think the behaviour on the left side is what we want/ed: I think the behaviour on the left side (Firefox and Presto) is what we want/
  168. # [23:43] <heycam> gregwhitworth: Edge is matching Firefox here
  169. # [23:43] <heycam> tantek: change the border to 25px max-height to 200px
  170. # [23:43] <heycam> s/tantek/fantasai/
  171. # [23:44] <heycam> fantasai: we should also test this situation, btw
  172. # [23:44] <heycam> gregwhitworth: chrome is doing the same as firefox on my windows laptop
  173. # [23:44] <heycam> ... v40
  174. # [23:44] <heycam> ... so this may end up being an issue with them talking to our compositor
  175. # [23:45] <heycam> ... right now on windows, firefox / edge ie / chrome have interop
  176. # [23:45] <heycam> ... on the second case
  177. # [23:45] <dbaron> Filed Gecko bug https://bugzilla.mozilla.org/show_bug.cgi?id=1131812
  178. # [23:45] <heycam> dbaron: in the second case I believe we have some code that extracts a width that's specified embedded in an SVG, and applies that to the sizing outer of the img element
  179. # [23:45] <heycam> ... because that's kind of how the sizing algorithm works
  180. # [23:46] <heycam> ... so we're taking the width from the SVG, applying it to the img element, then applying box-sizing
  181. # [23:46] <heycam> Florian: so doing the same thing as if the SVG was embedded inline in the HTML?
  182. # [23:46] <heycam> dbaron: yes
  183. # [23:46] <heycam> Florian: if that were the case the box would be 20px wide wouldn't it?
  184. # [23:46] <heycam> ... and it looks more than that
  185. # [23:46] <heycam> dbaron: yeah...
  186. # [23:47] <tantek> new test with fantasai suggested changes: https://lists.w3.org/Archives/Public/www-style/2015Feb/0245.html
  187. # [23:47] <gregwhitworth> Windows SVG Test: http://imgur.com/xbHMI0r
  188. # [23:47] <heycam> dbaron: OK I'm not sure what's happening then. but I think it's buggy.
  189. # [23:47] <heycam> tantek: I just sent the updated test that fantasai asked for to www-style
  190. # [23:47] <tantek> file name box-sizing-replaced-element-002.html
  191. # [23:48] <heycam> dbaron: this would be a lot easier if you emailed the individual files as attachments of the one email
  192. # [23:49] <heycam> tantek: so now this test has fewer effective changes as -001.htm
  193. # [23:50] <heycam> fantasai: so this test -002 now looks identical to the first thing we looked at
  194. # [23:50] <heycam> gregwhitworth: IE edge matches Firefox/Presto here
  195. # [23:50] <heycam> Florian: which is the same as Safari except for the third case
  196. # [23:50] <heycam> ... so it's just a bug in Safari
  197. # [23:51] <heycam> tantek: which is why we wanted to show you without box-sizing, to show the WebKit's handling of intrinsic ratio is buggy
  198. # [23:52] <heycam> tantek: if we can agree here what behaviour we want florian and I will specify it
  199. # [23:52] <heycam> Florian: once box-sizing gets involved, if we don't apply min/max width/height it's not explicit, but still not ambiguous
  200. # [23:52] <heycam> ... but with min/max-width/height, we need to specify something
  201. # [23:52] <heycam> ... I think Presto has reasonable behaviour
  202. # [23:53] <heycam> krit: this is something we should clarify with SVG the correct behaviour
  203. # [23:53] <heycam> Florian: what is missing on the SVG side?
  204. # [23:53] <heycam> krit: at least consensus on how viewBox etc. should operate on an SVG in <img>
  205. # [23:53] <heycam> Florian: is there anything other than SVG that can give an intrinsic width, ratio, but no height?
  206. # [23:54] <heycam> Florian: the spec says if you have an intrinsic width, do this. if you have width and ratio, do this. ...
  207. # [23:54] <heycam> tantek: CSS has explicit clauses for each of these cases
  208. # [23:54] <heycam> krit: this is with intrisic width and ratio, but not intrinsic height?
  209. # [23:54] <heycam> Florian: yes
  210. # [23:54] <heycam> ... we haven't got to intrinsic height but no width yet
  211. # [23:54] <heycam> krit: ok then the left two browsers are right
  212. # [23:55] <heycam> cyril: in the cases where the square is a rectangle and not a square, do you know if there's a bug in the rendering of the SVG and the aspect ratio is not preserved...
  213. # [23:55] <heycam> ... and the box is filled with the SVG content?
  214. # [23:55] <heycam> dino: for all three we need a circle in the SVG to see whether the bottom one is being clipped or stretched
  215. # [23:56] <heycam> Florian: so can we use something other than SVG for testing here?
  216. # [23:56] <heycam> tantek: no
  217. # [23:56] <heycam> dino: as Dirk is saying, it's not well defined. it also has its own rules for preserving aspect ratio internally inside its viewBox.
  218. # [23:56] <heycam> tantek: we're trying to look at this from the point of view that implementations are converging, so we'd like to follow them
  219. # [23:56] <heycam> dbaron: I think this is well defined now
  220. # [23:56] <heycam> tantek: in SVG?
  221. # [23:57] <heycam> fantasai: I remember the SVG WG saying that it's totally clear, or that they would fix it
  222. # [23:57] <heycam> ... so either that didn't happen or someone's confused
  223. # [23:57] <heycam> krit: in this case we also didn't discuss object-fit
  224. # [23:57] <heycam> Florian: that's not involved yet. but we will discuss that later.
  225. # [23:57] <heycam> krit: that is the case for inline SVG. for <img> we haven't had the discussion yet.
  226. # [23:58] <heycam> ... we likely should have the same rules for inline and in <img>
  227. # [23:58] <heycam> Florian: the way they start interacting with CSS is different
  228. # [23:58] <heycam> tantek: the width attribute in inline is not intrinsic but specified
  229. # [23:58] <heycam> ... so that's very different for these sizing computations
  230. # [23:59] <fantasai> width/height in an inline SVG is both specified and intrinsic size
  231. # [23:59] <fantasai> SVG specifies that it's the intrinsic size, and CSS specifies that it's the specified style
  232. # Session Close: Wed Feb 11 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