/irc-logs / w3c / #testing / 2013-07-04 / end

Options:

  1. # Session Start: Thu Jul 04 00:00:01 2013
  2. # Session Ident: #testing
  3. # [00:06] * Quits: krisk (~krisk@public.cloak) (Ping timeout: 180 seconds)
  4. # [00:07] * heycam|away is now known as heycam
  5. # [00:49] * Quits: tobie (tobie@public.cloak)
  6. # [04:02] * Joins: gitbot (~gitbot@public.cloak)
  7. # [04:02] -gitbot:#testing- [web-platform-tests] jungkees pushed 1 new commit to master: https://github.com/w3c/web-platform-tests/commit/9dde2fbacd8fad352b8b1837617f9c8e38274aa4
  8. # [04:02] -gitbot:#testing- web-platform-tests/master 9dde2fb Jungkee Song: Merge pull request #128 from w3c/hallvors/XHRtestBugFixes2...
  9. # [04:02] * Parts: gitbot (~gitbot@public.cloak) (gitbot)
  10. # [04:20] * heycam is now known as heycam|away
  11. # [05:12] * heycam|away is now known as heycam
  12. # [06:59] * Quits: jhammel (~jhammel@public.cloak) ("leaving")
  13. # [09:18] * Joins: darobin (rberjon@public.cloak)
  14. # [09:33] * Joins: Ms2ger (~Ms2ger@public.cloak)
  15. # [09:57] * Joins: gitbot (~gitbot@public.cloak)
  16. # [09:57] -gitbot:#testing- [web-platform-tests] yutak opened pull request #237: shadow-dom: Update a test for shadow root's accessors. (master...shadow-dom/shadow-root-accessors) https://github.com/w3c/web-platform-tests/pull/237
  17. # [09:57] * Parts: gitbot (~gitbot@public.cloak) (gitbot)
  18. # [10:06] * heycam is now known as heycam|away
  19. # [10:21] * Joins: tobie (tobie@public.cloak)
  20. # [10:33] * Joins: dom (dom@public.cloak)
  21. # [10:38] * Joins: AutomatedTester (~AutomatedTester@public.cloak)
  22. # [10:38] * Quits: AutomatedTester (~AutomatedTester@public.cloak) (Client closed connection)
  23. # [10:38] * Joins: AutomatedTester (~AutomatedTester@public.cloak)
  24. # [14:17] * Joins: r12a (rishida@public.cloak)
  25. # [14:17] <r12a> which list do i write to if i need some help with a test?
  26. # [14:18] <Ms2ger> What kind of test?
  27. # [14:18] <r12a> scripted
  28. # [14:18] <Ms2ger> What about?
  29. # [14:18] <r12a> ruby in html5 extension
  30. # [14:18] <Ms2ger> public-html-testsuite, probably
  31. # [14:18] <darobin> mmmm, not sure
  32. # [14:19] <r12a> it's how to detect success using javascript that i'm struggling with
  33. # [14:19] <darobin> didn't we say we wanted everything on public-test-infra?
  34. # [14:19] <darobin> yeah, that's definitely public-test-infra, it's not at all HTML WG specific
  35. # [14:19] <Ms2ger> I don't know
  36. # [14:19] <Ms2ger> I thought not yet
  37. # [14:19] <Ms2ger> But yeah, test-infra is good too
  38. # [14:19] <darobin> my understanding is that public-html-testsuite is only for the stuff that's specific to the HTML WG
  39. # [14:19] <darobin> r12a: I'd go with public-test-infra
  40. # [14:19] <r12a> ok, thanks
  41. # [14:19] <Ms2ger> Maybe we should shut them all down for public-test
  42. # [14:20] <darobin> at some point yeah
  43. # [14:20] <Ms2ger> Any objections?
  44. # [14:20] <Ms2ger> Resolved.
  45. # [14:20] <Ms2ger> darobin, go ahead :)
  46. # [14:21] <darobin> rm -Rf w3c/lists/public-test-*
  47. # [14:21] <darobin> there, done
  48. # [14:47] <r12a> mail sent
  49. # [15:07] <jgraham> r12a: My advice-you-don't-want is "let Microsoft fix the bug"
  50. # [15:08] <Ms2ger> Unhelpful yet correct advice?
  51. # [15:08] <Ms2ger> That's my job
  52. # [15:08] <r12a> hmm, interesting idea, except that the bug is in the test mechanism, rather than the thing being tested - i'd like to show that they DO support ruby
  53. # [15:09] <jgraham> It is an unfortunate truth that tests often fail for reasons unrelated to what they nominally test
  54. # [15:09] <jgraham> I can see why you might consider this unacceptable though
  55. # [15:09] <jgraham> *this case
  56. # [15:10] <r12a> between this and trying to do reftests for paragraph handling in textarea for bidi text i'm seriously wondering whether it's realistic to expect all tests to be automated
  57. # [15:11] <r12a> or at least within a reasonable timeframe
  58. # [15:11] <jgraham> Well it is clearly unrealistic to expect all tests to be automated
  59. # [15:11] <jgraham> But it is essential that all tests that *can* be automated are
  60. # [15:12] <r12a> yes, that's fair enough
  61. # [15:12] <jgraham> An automated test will be run hundreds of times a day. A non automated one a handful of times a year
  62. # [15:17] <darobin> r12a: I wonder if there isn't a way to test this that wouldn't fall on the same bugs
  63. # [15:17] <Ms2ger> s/will/can/ ;)
  64. # [15:17] <r12a> so do i ;-)
  65. # [15:18] <darobin> r12a: if you look at the height of the box that contains the ruby without any rt, then measure it again with rt, it ought to increase if the rt is properly on top
  66. # [15:18] <darobin> at least, I'd hope so (the alternative is that CSS does something pretty screwed up, which isn't out of the question but certainly possible)
  67. # [15:19] <jgraham> Heh
  68. # [15:19] <r12a> yes, i thought of that, but i'm going to need to tell whether the box is above or below at some point
  69. # [15:19] <jgraham> But that's an interesting alternative
  70. # [15:19] <Ms2ger> darobin, now, do you have a spec to back that? :)
  71. # [15:19] <r12a> it would be nice if there was one approach that works for all
  72. # [15:20] <r12a> i'd also much rather find a solution that actually tests the right thing, if possible ;-)
  73. # [15:20] <Ms2ger> That seems like a nice thing to have, yes :)
  74. # [15:20] <r12a> i'm curious about what IE is actually doing to produce these odd results though
  75. # [15:21] <darobin> "which isn't out of the question but certainly possible)" well done me
  76. # [15:21] * darobin has to step out
  77. # [15:21] <Ms2ger> (I know why I prefer testing DOM APIs)
  78. # [15:21] <r12a> i wonder why i got into testing i18n stuff (lots of on screen rendering magic) ;-)
  79. # [15:22] <r12a> changing or non-existent fonts
  80. # [15:22] <r12a> etc...
  81. # [15:22] <jgraham> Well if you need to test that it's on top
  82. # [15:22] <Ms2ger> Maybe because your name is r12a and you felt a connection?
  83. # [15:22] <jgraham> and IE is reporting that it's below
  84. # [15:22] <jgraham> Even though it is actually on top
  85. # [15:22] <jgraham> I refer you to my earlier comment
  86. # [15:23] <jgraham> Microsoft should fix their bug
  87. # [15:24] <jgraham> In either case you should certainly make a test that fails in IE]
  88. # [15:24] <jgraham> Since you have found a bug
  89. # [15:24] <r12a> k
  90. # [15:26] <jgraham> (and report it to Microsoft I guess)
  91. # [15:34] <jgraham> r12a: have you tried with getBoundingClientRect?
  92. # [15:34] <r12a> didn't know about that
  93. # [15:35] <jgraham> I assume it will produce the same wrong information
  94. # [15:35] <jgraham> But you never know
  95. # [15:40] <jgraham> I presume that ruby rendering isn't well enough defined that you could write a reftest using ahem?
  96. # [15:43] <r12a> jgraham, getBoundingClientRect produces the same result
  97. # [15:45] <r12a> wrt reftest, the actual distance between ruby text and base and the size of the ruby text are not defined exactly, so i'm leery about going the reftest route
  98. # [15:45] <r12a> for automatic checking, at least
  99. # [15:54] <jgraham> OK, both of those are what I expected, sadly
  100. # [15:55] <jgraham> Then I return to my previous position of leaning on Microsoft until they fix their bug :)
  101. # [15:59] <darobin> r12a: re the font stuff you should really use a single, predictable font that you impose on the page; anything else will indeed be unreliable
  102. # [15:59] <darobin> especially on mobile
  103. # [15:59] <r12a> understood
  104. # [16:00] <r12a> it's the distances between ruby and the size of scaling of the rt that are the key issues
  105. # [16:00] <r12a> those are implementation dependent, and not font related
  106. # [16:00] <r12a> s/between ruby/between ruby text and base/
  107. # [16:01] <darobin> r12a: also, I know I'm going to get heckled for this, but you might want to give one of these a shot to see if they work better with IE: http://api.jquery.com/category/offset/
  108. # [16:01] <darobin> fair enough
  109. # [16:01] <darobin> and if jQuery happens to work, you don't have to make your tests depend on it, we can extract whatever it is they do to paper over IE's bug
  110. # [16:01] <darobin> I would in fact expect it to work
  111. # [16:02] <r12a> ok, i'll give it a try later
  112. # [16:02] <r12a> (i'm deep in css character encoding test rewrites now)
  113. # [16:10] <jgraham> darobin: jQuery.offset seems to use getBoundingClientRect
  114. # [16:11] <darobin> jgraham: I wouldn't be violently shocked if IE had a bug on offset and not gBCR
  115. # [16:12] <jgraham> darobin: 13:40 < r12a> jgraham, getBoundingClientRect produces the same result
  116. # [16:12] <jgraham> (I wouldn't have been shocked either)
  117. # [16:13] <darobin> ah
  118. # [16:14] <darobin> I haven't looked at what jquery does, but I'd be surprised if they exposed something that doesn't work in IE
  119. # [16:14] <darobin> that said, it may be a bug that only affects some ruby elements, in which case jQuery won't do any better
  120. # [16:15] <darobin> at that point, it's worth looking at what horrible default CSS they're applying in order to position the element. Maybe some padding set to the proper line height
  121. # [16:15] <jgraham> Right, it seems likely that someone just got a plus and a minus sign confused when setting the position of ruby elements in the DOM, or something
  122. # [16:15] <darobin> you'd sort of hope such code would not be element-specific...
  123. # [16:15] <jgraham> I wouldn't be entirely surprised if there was a ruby-specific part
  124. # [16:16] <jgraham> Although, yes, it does seem surprising that the position on the screen and the position reported in the DOM don't match
  125. # [16:17] <jgraham> (alterntaively, they are doing something weird like making the ruby text have the same baseline as the normal text but a large bottom margin)
  126. # [16:29] * jgraham looks in the IE developer tools
  127. # [16:29] <jgraham> They aren't, it's just broken
  128. # [16:29] <jgraham> Or, maybe they are internally
  129. # [16:30] <jgraham> But the bottom of the <rt> box lines up with the bottom of the <rb> box
  130. # [16:30] <jgraham> Oh, not quite
  131. # [16:30] <jgraham> The bottom of the <rb> text
  132. # [16:41] <jgraham> (so I retract my previous guess. It looks like some part of the layout engine lays out the text at the baseline of the normal text, and that sets the position in the DOM, and later it is shunted upwards, but the DOM isn't updated to reflect that)
  133. # [17:03] * Quits: dom (dom@public.cloak) ("")
  134. # [17:30] <darobin> jgraham: that's just absolutely lovely
  135. # [17:31] <darobin> but then again, ruby being broken isn't shocking either
  136. # [17:31] <darobin> lots of non-shocking information was uncovered here today
  137. # [17:33] * Quits: darobin (rberjon@public.cloak) (Client closed connection)
  138. # [17:35] * Quits: AutomatedTester (~AutomatedTester@public.cloak) (Client closed connection)
  139. # [18:23] * Quits: Lachy (~Lachy@public.cloak) (Ping timeout: 180 seconds)
  140. # [20:24] * Joins: AutomatedTester (~AutomatedTester@public.cloak)
  141. # [21:56] * Quits: tobie (tobie@public.cloak)
  142. # [22:19] * Joins: tobie (tobie@public.cloak)
  143. # [22:28] * Quits: AutomatedTester (~AutomatedTester@public.cloak) (Client closed connection)
  144. # [23:12] * Quits: tobie (tobie@public.cloak)
  145. # [23:19] * Quits: Ms2ger (~Ms2ger@public.cloak) ("nn")
  146. # [23:32] * Joins: tobie (tobie@public.cloak)
  147. # [23:46] * Quits: tobie (tobie@public.cloak) (Client closed connection)
  148. # [23:47] * Joins: tobie (tobie@public.cloak)
  149. # Session Close: Fri Jul 05 00:00:00 2013

The end :)