/irc-logs / freenode / #whatwg / 2010-02-22 / end

Options:

  1. # Session Start: Mon Feb 22 00:00:00 2010
  2. # Session Ident: #whatwg
  3. # [00:04] * Quits: gavin_ (~gavin@firefox/developer/gavin) (Ping timeout: 268 seconds)
  4. # [00:05] * Joins: gavin_ (~gavin@firefox/developer/gavin)
  5. # [00:05] * Joins: tantek (~tantek@70-36-139-7.dsl.dynamic.sonic.net)
  6. # [00:11] * Quits: JonathanNeal (~JonathanN@99-59-124-67.lightspeed.irvnca.sbcglobal.net) (Read error: Connection reset by peer)
  7. # [00:11] <Hixie> TabAtkins: you didn't mail hte list
  8. # [00:11] * Joins: JonathanNeal_oww (~JonathanN@99-59-124-67.lightspeed.irvnca.sbcglobal.net)
  9. # [00:11] <TabAtkins> Craps.
  10. # [00:12] <Hixie> :-)
  11. # [00:12] <TabAtkins> Danke, sent.
  12. # [00:13] * Hixie learnt last week that the IETF submission process actually has a human in the loop
  13. # [00:13] <Hixie> and apparently submitting websocket so much is tiring them out
  14. # [00:13] <Hixie> :-/
  15. # [00:13] <Hixie> it's like the IETF stopped evolving in the 70s or something
  16. # [00:14] * Quits: tametick (~chatzilla@chello084114134061.3.15.vie.surfer.at) (Quit: ChatZilla 0.9.86 [Firefox 3.6/20100115132715])
  17. # [00:14] * Joins: bfrantz (~bfrantz@pdpc/supporter/professional/bfrantz)
  18. # [00:22] * Joins: paul_irish (~paul_iris@c-71-192-163-128.hsd1.nh.comcast.net)
  19. # [00:23] * Quits: m_W (~mwj@c-69-141-106-205.hsd1.nj.comcast.net) (Read error: Connection reset by peer)
  20. # [00:24] * Joins: m_W (~mwj@c-69-141-106-205.hsd1.nj.comcast.net)
  21. # [00:24] * Quits: Rik` (~Rik`@pha75-2-81-57-187-57.fbx.proxad.net) (Ping timeout: 245 seconds)
  22. # [00:25] * Joins: karlcow (~karl@nerval.la-grange.net)
  23. # [00:29] <tantek> Hixie every standards organizations' processes tends to be a time capsule of the culture/technologies in common use at their inception. Hence the need for new standards organizations every few years.
  24. # [00:29] <Hixie> seems that way
  25. # [00:30] * Quits: Amorphous (jan@unaffiliated/amorphous) (Ping timeout: 260 seconds)
  26. # [00:31] * Joins: Rik` (~Rik`@pha75-2-81-57-187-57.fbx.proxad.net)
  27. # [00:33] * Quits: FireFly (~firefly@unaffiliated/firefly) (Quit: Leaving)
  28. # [00:45] * Joins: Amorphous (jan@unaffiliated/amorphous)
  29. # [00:49] <AryehGregor> Blargh, why does type="search" not support width in WebKit?
  30. # [00:50] <Hixie> width?
  31. # [00:50] <AryehGregor> Hmm, maybe I'm wrong?
  32. # [00:51] <Hixie> what do you mean by width?
  33. # [00:51] <Hixie> CSS property, IDL attribute, content attribute, something else?
  34. # [00:51] <AryehGregor> The width CSS property. But my accusation was scurrilous.
  35. # [00:51] <Hixie> ah ok
  36. # [00:54] <AryehGregor> Hmm, I guess scurrilous doesn't mean what I think it means.
  37. # [00:55] <AryehGregor> My accusation was groundless.
  38. # [00:56] <Hixie> is there a spec for how HTTP CONNECT works anywhere?
  39. # [00:58] <Lachy> Hixie, maybe this http://www.ietf.org/rfc/rfc2817.txt
  40. # [00:58] <Lachy> I haven't read it to see how well it defines it. just found it
  41. # [00:58] * Quits: tndH (~Rob@cpc2-leed18-0-0-cust427.leed.cable.ntl.com) (Ping timeout: 256 seconds)
  42. # [00:58] * Hixie looks
  43. # [01:00] * Quits: grimboy (~grimboy@bcm-131-111-216-247.girton.cam.ac.uk) (Remote host closed the connection)
  44. # [01:00] * Joins: wakaba_ (~wakaba_@ntkyto167068.kyto.nt.ftth4.ppp.infoweb.ne.jp)
  45. # [01:03] <Hixie> weird
  46. # [01:03] <Hixie> if i connect to hixie.ch port 80 and send:
  47. # [01:03] <Hixie> CONNECT hixie.ch:80 HTTP/1.1 [CRLF][CRLF]
  48. # [01:04] <Hixie> i get back a 400 Bad Request
  49. # [01:04] <Hixie> but if i connect to hixie.ch port 80 and send:
  50. # [01:04] <Hixie> CONNECT hixie.ch:80 garbage [CRLF][CRLF]
  51. # [01:04] <Hixie> i get back a 405 Method not Allowed
  52. # [01:06] * Joins: yutak_home (~kee@N038037.ppp.dion.ne.jp)
  53. # [01:10] * Joins: othermaciej (~mjs@c-69-181-42-237.hsd1.ca.comcast.net)
  54. # [01:14] <Hixie> i really can't see how to make CONNECT work as a handshake
  55. # [01:15] <Hixie> (not if we simultaneously try to not violate HTTP)
  56. # [01:15] * Quits: karlcow (~karl@nerval.la-grange.net) (Quit: This computer has gone to sleep)
  57. # [01:17] <othermaciej> how would a CONNECT handshake violate HTTP?
  58. # [01:18] * Joins: tndH (~Rob@cpc2-leed18-0-0-cust427.leed.cable.ntl.com)
  59. # [01:18] <othermaciej> is it forbidden to send a CONNECT request to an origin server?
  60. # [01:19] <Hixie> no
  61. # [01:20] <Hixie> the problem is the response
  62. # [01:20] <Hixie> it consists of an entire 2xx response before the pip is established
  63. # [01:20] <Hixie> pipe
  64. # [01:20] <Hixie> so basically we're opening a massive hole right at the head of the connection
  65. # [01:21] <othermaciej> you could do the Adam-style handshake after the connection is established
  66. # [01:21] <Hixie> yeah i guess we'd have to
  67. # [01:21] <othermaciej> unless there is some chance that the CONNECT request itself will completely own the server
  68. # [01:21] <Hixie> oh i missed your response to that question i asked the other day, btw, i was meeting with one of the hybi chairs
  69. # [01:22] <othermaciej> I do think the Adam-style handshake is more complicated than necessary for its own security
  70. # [01:22] <othermaciej> or at least, his original version
  71. # [01:22] <Hixie> yeah i don't see why we need to encrypt any useful data
  72. # [01:22] <othermaciej> there's no need for the server to generate its own entropy
  73. # [01:22] * Quits: Lerc (~Lerc@121-74-1-66.telstraclear.net) (Quit: Lerc)
  74. # [01:22] <Hixie> can't we just include a challenge of the form "here's 16 bytes, return them x'ored with each other"?
  75. # [01:23] <Hixie> s/'//
  76. # [01:23] <othermaciej> there's a couple of issues with that
  77. # [01:23] <othermaciej> 1) doesn't increase the likelihood that the server will pay attention to the client's Origin
  78. # [01:24] <othermaciej> 2) no way to differentiate from future protocols using the same approach
  79. # [01:24] <Hixie> if the server doesn't pay attention to the origin, he'll include a hard-coded value, which is fine, no?
  80. # [01:25] <othermaciej> 3) required useful data ("this is WebSocket", "here's the Origin") would have to go in a separate response, increasing the number of round trips
  81. # [01:25] <Hixie> i don't see how we can do anything that reduces the chances of a server just echoing the origin when they should check it
  82. # [01:25] <othermaciej> well let me put it this way
  83. # [01:25] <Hixie> i don't follow #3
  84. # [01:25] <othermaciej> what do you expect to be in the handshake besides those 16 bytes, if anything?
  85. # [01:26] <othermaciej> Adam's goal was that the whole handshake looks like random bytes if you don't understand it, and thus is highly unlikely to have a specific bad effect on servers
  86. # [01:26] * Quits: jgornick (~joe@199.199.212.242) (Quit: jgornick)
  87. # [01:26] <Hixie> yeah well given that the start of the handshake is a CONNECT, there's zero chance of that
  88. # [01:26] <Hixie> so i kinda gave up with that goal
  89. # [01:26] <Hixie> i guess if we want to do it we still can though
  90. # [01:28] <othermaciej> yeah I don't know how meaningful it is to do the Adam handshake after a CONNECT
  91. # [01:28] <othermaciej> I mean, probably somewhat meaningful just less so
  92. # [01:29] <othermaciej> there are a few ways I can think of to simplify server-side implementation of Adam's design without reducing the security:
  93. # [01:29] <othermaciej> 1) Have the client use a one-time pad as its crypto (i.e. XOR with an equally long key)
  94. # [01:30] <othermaciej> 2) have the server respond with a hash of the client's key and the client's plaintext (perhaps reodering the parts)
  95. # [01:30] <othermaciej> it doesn't even have to be a cryptographically secure hash, could even be CRC, you just want a hash value that's too long to get the right value by chance
  96. # [01:31] <othermaciej> though I suspect MD5 is more widely available in library form than most simpler hashes with a decent output size
  97. # [01:31] * Joins: Waldo_ (~waldo@c-98-248-40-206.hsd1.ca.comcast.net)
  98. # [01:31] <othermaciej> that removes the server's needs to use a fancy algorithm to decrypt, to produce random bits, and to use a fancy algorithm to encrypt again
  99. # [01:33] <Hixie> we can get rid of the need for a library altogether just by having the server xor parts of the key together
  100. # [01:33] <Hixie> e.g. xor bytes 1,2,3,4 with bytes 5,6,7,8
  101. # [01:33] <Hixie> also making the key the right length is easy if you just interleave each byte of the key with the byte of data it's been xored with
  102. # [01:34] <Hixie> e.g. ABC becomes [k1][k1 xor A][k2][k2 xor B][k3][k3 xor C]
  103. # [01:34] <Hixie> and the server's nonce can then just be [k1 xor k2][k3 xor k4]...[k8 xor k16] or something
  104. # [01:41] * Joins: roc (~roc@c-67-188-229-36.hsd1.ca.comcast.net)
  105. # [01:42] <NickYoung> I hope this isn't supposed to be cryptographically secure..
  106. # [01:42] <NickYoung> the security guy in me is seeing the next WEP being created...
  107. # [01:43] <othermaciej> I think making the server xor random bytes is probably more of a burden on the server than telling the server to use MD5
  108. # [01:43] <othermaciej> NickYoung: it's not supposed to be cryptographically secure
  109. # [01:43] <NickYoung> Oh good ;)
  110. # [01:43] <NickYoung> also, I disagree with your assertion.. XOR is a single cycle operation
  111. # [01:44] <NickYoung> even if you have 20 of them, it will be many thousands times faster than MD5
  112. # [01:44] <othermaciej> NickYoung: by "burden" I mean difficulty of implementation, not CPU cost of doing the computation
  113. # [01:44] <NickYoung> seriously, bitwise -or is difficult to implement? =P
  114. # [01:45] <othermaciej> if you invent a funky custom algorithm then the server can't use a pre-existing library
  115. # [01:45] * Quits: Utkarsh (~admin@117.201.80.151) (Ping timeout: 252 seconds)
  116. # [01:45] <NickYoung> from what I read, you're just XORing a few bytes...
  117. # [01:46] * Parts: jtbandes (~jtbandes@unaffiliated/jtbandes) ("Bye.")
  118. # [01:46] <othermaciej> yeah, the tricky part is which bytes
  119. # [01:46] <othermaciej> you have to hand-code a loop to do it and have it step in the right increments
  120. # [01:46] <othermaciej> and the reason Hixie wants to do that is because calling a library function to do MD5 or CRC or whatever might be too hard
  121. # [01:47] <NickYoung> what's the point of this anyway, to verify you're speaking the correct protocol..?
  122. # [01:48] * Joins: paradisaeidae (~chatzilla@r125-63-186-202.cpe.unwired.net.au)
  123. # [01:48] <othermaciej> to verify that you are speaking the correct protocol and that the connection is allowed without opening too much opportunity for cross-protocol attacks
  124. # [01:49] <NickYoung> and these 16bits are a nonce?
  125. # [01:49] <othermaciej> Hixie: I think if your key is variable-length then you need to length-prefix or terminator-delimit the client handshake, so the server knows when it got all of it
  126. # [01:49] <Hixie> othermaciej: sure, the last four bytes would decode to CRLFCRLF or some such
  127. # [01:50] <othermaciej> I think it's meant to be 16 bytes, a 16-bit nonce would be pretty weak
  128. # [01:50] <NickYoung> ah, misread
  129. # [01:50] <NickYoung> wait
  130. # [01:50] <NickYoung> 16 bytes?
  131. # [01:50] <othermaciej> Hixie: that would force a requirement to do the "decrypt" operation in streaming mode
  132. # [01:51] <othermaciej> NickYoung: it's really a variable-length number of bytes, since the plaintext client handshake message is not fixed-length
  133. # [01:51] * Joins: Utkarsh (~admin@117.201.80.84)
  134. # [01:51] <NickYoung> ah.
  135. # [01:51] <Hixie> othermaciej: yes? the whole protocol is a "streaming-mode" protocol
  136. # [01:51] <othermaciej> Hixie: as opposed to "read known length or up to delimiter and then process"
  137. # [01:52] <othermaciej> which is how HTTP headers and WebSocket messages are both handled
  138. # [01:52] <othermaciej> there is no need to process every single byte to even find the message boundaries
  139. # [01:53] <othermaciej> the point is, what you're proposing is not easier to implement than even Adam's original version, given a reasonable set of available libraries
  140. # [01:53] <othermaciej> it is in fact harder
  141. # [01:53] <othermaciej> and people could easily get it wrong in subtle ways, e.g. not expect the client handshake to be split in the middle, or to be split on an odd byte
  142. # [01:54] <Hixie> i don't mind have a non-encrypted delimiter if you like
  143. # [01:54] <othermaciej> I would say it's far better to use well-known algorithms than some weird ad-hoc thing if your goal is to make it easy on custom server implementations
  144. # [01:54] <othermaciej> I don't think the delimiter is the biggest problem with your proposal
  145. # [01:55] <Hixie> we could even just define the key characters for the last four bytes so that you can do the delimiter check in either mode
  146. # [01:55] <othermaciej> "run around XORing random bytes together" is not a trivial operation
  147. # [01:55] <Hixie> i can't think of a single language i've ever used where it's been anything _but_ trivial
  148. # [01:55] <othermaciej> most people who interview with the Safari team would probably fail if presented that problem as an interview question (not that we hire them, but lots of these people think they know how to code)
  149. # [01:57] * Joins: boblet (~boblet@p1072-ipbf36osakakita.osaka.ocn.ne.jp)
  150. # [01:58] <Hixie> i don't understand the problem here. read byte; if (needkey) key = byte else append(byte xor key); needkey = !needkey;
  151. # [01:58] <Hixie> it seems truly trivial
  152. # [01:59] <Hixie> am i missing something?
  153. # [01:59] <othermaciej> you're missing the loop, the code to detect the terminators, and the code to output the response
  154. # [02:00] <Hixie> right, you need those regardless of what we do here
  155. # [02:00] <othermaciej> also you're not accounting for the fact that the read is asynchronous
  156. # [02:00] <othermaciej> s/output/compute/
  157. # [02:00] <Hixie> i'm assuming the above is the code you stick in the select() loop for the socket
  158. # [02:01] <othermaciej> the hypothetical naiive server-side programmer is using select with raw sockets instead of something like Twisted?
  159. # [02:01] <othermaciej> this hypothetical person must really hate using libraries
  160. # [02:02] <TabAtkins> Hypothetical people do, as a rule.
  161. # [02:02] <Hixie> i'm baffled as to why you would use a library for something this simple personally
  162. # [02:03] * Quits: yutak_home (~kee@N038037.ppp.dion.ne.jp) (Quit: Ex-Chat)
  163. # [02:04] <othermaciej> Adam
  164. # [02:04] <othermaciej> er
  165. # [02:04] <othermaciej> Adam
  166. # [02:05] <othermaciej> dammit, why must enter be so close to the quote key
  167. # [02:05] <othermaciej> Adam's original version also has the problem that it's variable-length but neither length-prefixed nor delimited
  168. # [02:06] <boblet> Hixie: did you see the HTML5 & APIs book that is just coming out in Japan?
  169. # [02:06] <othermaciej> in his case the key is fixed-length, so you could just keep decrypting til it works, but that is lame
  170. # [02:06] <Hixie> boblet: didn't see it, but mike told me about it
  171. # [02:06] <Hixie> othermaciej: i'm happy to delimit it
  172. # [02:06] <boblet> http://www.amazon.co.jp/dp/4822284220/
  173. # [02:07] <boblet> Mike was encouraging Shiraishi-san to send you a copy, so you might be able to see it in the flesh :)
  174. # [02:07] <othermaciej> Hixie: I can't tell up front what a good delimiter would be
  175. # [02:08] <othermaciej> Hixie: btw your code, despite doing only a small fraction of the work, has an obvious bug
  176. # [02:08] <othermaciej> Hixie: it doesn't save the key bytes, which per your definition are used to compute the server response
  177. # [02:08] * Quits: roc (~roc@c-67-188-229-36.hsd1.ca.comcast.net) (Quit: roc)
  178. # [02:08] <othermaciej> (I'm also not clear on why the server response depends only on the key and not the plaintext in your proposal)
  179. # [02:09] <Hixie> yeah, i wasn't sure what to do about that sicne you didn't like the proposal of using hte key
  180. # [02:09] <Hixie> i would use this as the delimiter, so you could detect it in either implementation style (before or after decrypting): 0x00 0x0D 0x00 0x0A 0x00 0x0D 0x00 0x0A
  181. # [02:09] <boblet> Futomi-san (of http://html5.jp/ fame) also has a book in the pipeline: http://www.amazon.co.jp/dp/4798025291/ It’s a hot topic over here
  182. # [02:10] <Hixie> (maybe we should just use LF line endings in this, since we don't have to be HTTP-compatible)
  183. # [02:11] <othermaciej> boblet: people are probably more excited in Japan because they can't follow the mailing list flamewars
  184. # [02:11] <Hixie> hah
  185. # [02:11] <boblet> othermaciej: zing!
  186. # [02:12] <boblet> yeah, info about it comes prefiltered so ppl here miss out on that and the FUD too
  187. # [02:12] <othermaciej> Hixie: I dunno if you come up with a complete proposal I can analyze it (and I'm sure Adam would be willing to as well)
  188. # [02:13] <othermaciej> too hard to review an emerging design over IRC
  189. # [02:13] <Hixie> yeah, i'm poking at one
  190. # [02:14] <othermaciej> I do think that even though this doesn't have to be cryptographically secure, it would be wiser to use off-the-shelf algorithms, because the first rule of crypto club is "don't invent your own algorithms"
  191. # [02:14] <Hixie> the idea of the nonce coming back from the server is to have the server include something in the response that's verifiable (showing the server knows the protocol) and yet not predictable without controlling the client's handshake, right?
  192. # [02:14] <othermaciej> yes
  193. # [02:14] <Hixie> a one time pad isn't a new invention
  194. # [02:14] <othermaciej> I think a one-time pad for the client request is fine
  195. # [02:14] <Hixie> oh for the response, yeah
  196. # [02:15] <othermaciej> (given a suitable way to mark the boundary)
  197. # [02:16] <othermaciej> ideally I think the response would use an algorithm that doesn't require the server to generate a random number, which is why I thought of hashing instead of encryption
  198. # [02:16] * Quits: gavin_ (~gavin@firefox/developer/gavin) (Ping timeout: 260 seconds)
  199. # [02:16] <Hixie> yeah
  200. # [02:16] <Hixie> totally agreed on that
  201. # [02:17] <othermaciej> one more thing I thought of, you can't use a fixed set of bytes as a delimiter without forcing some kind of escapting
  202. # [02:18] <othermaciej> oh, I guess the idea of 0x0 0xD is supposed to be that the plaintext request can't contain byte 0xD, but that's pretty subtle
  203. # [02:19] <othermaciej> I can't think of a good simple way to encode the length without violating the "it looks like random bytes" property
  204. # [02:22] * Joins: gavin_ (~gavin@firefox/developer/gavin)
  205. # [02:25] <othermaciej> Hixie: btw have you had a chance to look at the Change Proposal that the i18n people came up with for ISSUE-88? would it be helpful if someone extracted out the requests there that still differ from the spec?
  206. # [02:37] * Joins: tkent (~tkent@220.109.219.244)
  207. # [02:38] <Hixie> link?
  208. # [02:39] <Hixie> the answer is probably no
  209. # [02:39] <Hixie> because in the last week i've only done bugs and websocket feedback
  210. # [02:40] <Hixie> oh this one? http://www.w3.org/International/wiki/Htmlissue88
  211. # [02:41] * Joins: annodomini (~lambda@2002:97cb:cadc:2:21c:b3ff:febc:c615)
  212. # [02:41] * Quits: annodomini (~lambda@2002:97cb:cadc:2:21c:b3ff:febc:c615) (Changing host)
  213. # [02:41] * Joins: annodomini (~lambda@wikipedia/lambda)
  214. # [02:43] <Waldo_> othermaciej:erm, do you happen to know why the jwalden nick I usually use is banned in #webkit? was my connection flaky recently or something?
  215. # [02:44] <othermaciej> Waldo_: banned?
  216. # [02:44] <othermaciej> as in, you can't enter the channel, or you can't speak?
  217. # [02:44] <Waldo_> "=== jwalden #webkit Cannot change nickname while banned on channel"
  218. # [02:44] <Waldo_> that's as much as I know, when I try /nick jwalden
  219. # [02:44] <othermaciej> no idea
  220. # [02:44] <gavin> your nick isn't registered?
  221. # [02:44] <gavin> or you aren't identified
  222. # [02:45] <othermaciej> there's only one other person who has channel ownership
  223. # [02:45] <Waldo_> no, this is when I try to change nick right now
  224. # [02:45] <gavin> oh
  225. # [02:45] <gavin> Waldo_ isn't identified
  226. # [02:45] <othermaciej> I can probably unban you but my IRC mojo is weak
  227. # [02:45] <gavin> so you can't change his nick
  228. # [02:45] <Waldo_> well, sure
  229. # [02:45] <gavin> because webkit is +R
  230. # [02:45] <Waldo_> you identify after you change nick
  231. # [02:45] <gavin> part webkit, change nick, identify, rejoin
  232. # [02:45] * Waldo_ is now known as jwalden
  233. # [02:46] <jwalden> hum, that worked
  234. # [02:46] <jwalden> sorry for the trouble...
  235. # [02:46] <Hixie> the bans in #webkit are:
  236. # [02:46] <Hixie> 02:43 -!- 1 - #webkit: ban *!*jibot@67.207.137.* [by zelazny.freenode.net, 1910310 secs ago]
  237. # [02:46] <Hixie> 02:43 -!- 2 - #webkit: ban *!*onar@*.hsd1.ca.comcast.net [by zelazny.freenode.net, 1910310 secs ago]
  238. # [02:46] <Hixie> looks like someone using comcast was banned
  239. # [02:46] <Hixie> and the server won't let you change nicks while that's going on
  240. # [02:46] <gavin> no no, this is just a quiet ban
  241. # [02:46] <gavin> +q $~a
  242. # [02:46] <gavin> applies to all unregistered nicks
  243. # [02:47] <gavin> (/mode +q #webkit)
  244. # [02:47] <jwalden> chatzilla could use a better error message here, if the protocol permits one to be used
  245. # [02:47] <jwalden> or rather, allows the situation to be identified
  246. # [02:47] <othermaciej> that would stop people from talking but not from entering the channel, right?
  247. # [02:47] <gavin> right
  248. # [02:47] <gavin> unregistered users can currently join but not speak in #webkit
  249. # [02:48] <gavin> |/mode -q $~a #webkit| if you want to remove that restriction
  250. # [02:48] <gavin> er, or maybe |/mode #webkit -q $~a|
  251. # [02:50] * Quits: Utkarsh (~admin@117.201.80.84) (Ping timeout: 256 seconds)
  252. # [02:56] * Quits: othree (~othree@admin39.ct.ntust.edu.tw) (Remote host closed the connection)
  253. # [02:56] * Joins: paul_irish_ (~paul_iris@c-71-192-163-128.hsd1.nh.comcast.net)
  254. # [02:58] * Quits: paul_irish (~paul_iris@c-71-192-163-128.hsd1.nh.comcast.net) (Ping timeout: 256 seconds)
  255. # [03:01] <JonathanNeal_oww> Hey guys!
  256. # [03:01] * JonathanNeal_oww is now known as JonathanNeal
  257. # [03:02] <JonathanNeal> I heard some great questions about HTML5 today and I thought I would share them with the group and get your reactions.
  258. # [03:03] <JonathanNeal> Accessibility: What is the benefit to accessibility with HTML5? Do existing and popular screen-readers have an easier or harder time understanding HTML5 tags? How do they parse the content in IE when they run into an unknown tag?
  259. # [03:04] * Quits: JonathanNeal (~JonathanN@99-59-124-67.lightspeed.irvnca.sbcglobal.net) (Read error: Connection reset by peer)
  260. # [03:04] * Joins: JonathanNeal (~JonathanN@99-59-124-67.lightspeed.irvnca.sbcglobal.net)
  261. # [03:05] <Hixie> HTML5 improves matters for accessibility, though the various and sundry ways it does that are numerous and difficult to summarise
  262. # [03:06] <JonathanNeal> Hixie, can any of them be mentions or written?
  263. # [03:06] <JonathanNeal> Are they listed on the web?
  264. # [03:06] <JonathanNeal> Or is it theory.
  265. # [03:06] * Quits: murr4y (~murray@89.84-49-66.nextgentel.com) (Ping timeout: 260 seconds)
  266. # [03:07] <boblet> JonathanNeal: one of the big accessibility improvements is moving a11y stuff from hidden locations (like attributes) to visible locations (like content), so they’re available to everyone, and also to give authors a reason to add them
  267. # [03:09] * Quits: paradisaeidae (~chatzilla@r125-63-186-202.cpe.unwired.net.au) (Read error: Connection reset by peer)
  268. # [03:09] <boblet> an example of this is the great table summary vs caption wars
  269. # [03:09] <boblet> http://www.whatwg.org/specs/web-apps/current-work/multipage/tabular-data.html#attr-table-summary
  270. # [03:09] <boblet> another is the ongoing longdesc battle
  271. # [03:11] <JonathanNeal> HTML5 Accessibility can be measured in battles.
  272. # [03:11] * Joins: paradisaeidae (~chatzilla@r125-63-186-202.cpe.unwired.net.au)
  273. # [03:12] <Hixie> JonathanNeal: hidden="", the new <input type>s, removing features that were harming accessibility due to widespread misuse, removing all media-specific presentational features in favour of CSS, making many of the features more explicitly media-independent, etc
  274. # [03:13] <Hixie> othermaciej: i replied to the issue-88 stuff
  275. # [03:14] <JonathanNeal> making many of the features more explicitly media-independent, you mean like the presentational to css stuff?
  276. # [03:15] <othermaciej> Hixie: thanks
  277. # [03:16] <Hixie> JonathanNeal: i mean like <hr> being redefined to have nothing to do with horizontal rules specifically
  278. # [03:16] <Hixie> or <b> and <i> being redefined to make sense in all media, not just visual media
  279. # [03:16] <boblet> JonathanNeal: eg em = emphasis to stress emphasis, kbd = keyboard to keyboard and other eg voice input (ie has explicit aural ref plus less UA-specific)
  280. # [03:18] <boblet> JonathanNeal: re accessibility battles, it’s a topic on which many people have strongly held and conflicting beliefs :|
  281. # [03:19] <othermaciej> I think the best features for accessibility are the new controls (both form controls and things that don't participate in form submission but resemble standard application widgets)
  282. # [03:19] <othermaciej> because now people won't need to use <div> soup to build those controls
  283. # [03:19] <JonathanNeal> This is a fun discussion.
  284. # [03:22] * Quits: sebmarkbage (~miranda@213.80.108.29) (Ping timeout: 248 seconds)
  285. # [03:23] <boblet> also once UAs (and authors) start using semantic structural elements (nav especially) it’ll make things way more accessible
  286. # [03:24] <JonathanNeal> Should I continue the dialog?
  287. # [03:24] <JonathanNeal> Google and the world of search:
  288. # [03:25] <JonathanNeal> Is there an SEO benefit to HTML5? Is there one now, or will there be one? Does Google favor HTML5 markup, over HTML4 markup, or XHTML markup? Does any search engine (such as Bing, Yahoo, etc)?
  289. # [03:26] <Hixie> no SEO benefit
  290. # [03:26] <Hixie> just make your content useful
  291. # [03:26] <Hixie> you'll have much more luck with making your content have high rank in google if you make it something people want, than if you spend the same time trying to do markup tricks
  292. # [03:28] <JonathanNeal> Fair enough, boblet or othermaciej feel free to jump in on that one if you think differently, otherwise I'll move on.
  293. # [03:28] <JonathanNeal> Final section, The Browser Effect:
  294. # [03:29] <boblet> although I think it’s fair to say that using good markup will help make the content accessible to people. i suspect there is some search engine benefit to using good markup over tag soup
  295. # [03:29] <JonathanNeal> How will HTML5 impact browser performance? CSS3 selectors have a quantifiable impact on performance, but do HTML5 tags have any impact on rendering performance? What about in IE; what is the performance impact (in ms and possibly in MB) on having to create the elements via JS on every page load?
  296. # [03:30] <boblet> eg Google Lists(?) probably won’t include a list marked up using <p> with <br> in it’s list of related entries suggestions
  297. # [03:30] * Joins: miketaylr (~miketaylr@24.42.95.234)
  298. # [03:31] <boblet> I think POSH (plain old semantic HTML) is probably good SEO for free
  299. # [03:32] <othermaciej> I don't know anything about what search engine algorithms do
  300. # [03:32] <othermaciej> you would have to ask them
  301. # [03:33] <boblet> JonathanNeal: i don’t know of any performance impact, and typically something like 90% of the time is spent getting the file (vs processing), so any change on processing will probably be small
  302. # [03:33] <othermaciej> HTML5 will probably improve performance in the case where you can use a native HTML5 feature instead of rolling your own with DIV+CSS+JS
  303. # [03:34] <boblet> re: IE HTML5 shiv, the JS itself is tiny, and the performance overhead of creating new elements before being able to use them should be tiny compared to something like using jQuery. in current browsers I wouldn’t expect HTML5 (over HTML4 etc) to make a noticeable difference
  304. # [03:35] <othermaciej> also using the <video> element may be higher performance than plugin-based video solutions
  305. # [03:35] <othermaciej> it really shouldn't make much difference either way in most cases
  306. # [03:36] <boblet> JonathanNeal: if you’re worried about performance use YSlow and Smushit—your HTML
  307. # [03:37] <boblet> —HTML differences are tiny compared to image minification and reducing requests
  308. # [03:37] <othermaciej> appcache is an HTML5 feature that can significantly improve load performance (past the first time)
  309. # [03:38] * Quits: MikeSmith (~MikeSmith@EM114-48-158-107.pool.e-mobile.ne.jp) (Ping timeout: 252 seconds)
  310. # [03:39] <boblet> Hixie: the “submit review comment” help message should probably mention that you can receive a reply if you use the same email as bugzilla
  311. # [03:39] <boblet> also it munges non-ascii characters
  312. # [03:41] <JonathanNeal> All of what you guys have said is great, but is there any measurable, documented proof?
  313. # [03:41] <JonathanNeal> Or is there a way you would recommend I make one, such as with yslow, etc?
  314. # [03:42] <othermaciej> what are you looking for proof of?
  315. # [03:42] <othermaciej> "how will HTML5 impact browser performace?" is a very open-ended question
  316. # [03:42] <othermaciej> if you formulate a specific hypothesis we can tell you ways to test
  317. # [03:43] <JonathanNeal> "Do HTML5 tags have any impact on rendering performance?"
  318. # [03:43] <othermaciej> if the question is about using HTML5 at all, without using any new features, you could try the same page with HTML4.01 and HTML5 doctypes to see if there is any difference in load speed (there won't be)
  319. # [03:43] * Joins: MikeSmith (~MikeSmith@EM114-48-229-121.pool.e-mobile.ne.jp)
  320. # [03:44] <othermaciej> if you want to see if enabling IE to use the new tags compatibly impacts load time in IE, you can test load times in IE of a page with and without
  321. # [03:44] <JonathanNeal> How would you test those load times in IE?
  322. # [03:44] <othermaciej> if you want to see if appcache improves cached-case load speed, then that would be a more challenging experiment (to set up the app cache manifest properly etc) but still doable
  323. # [03:45] <othermaciej> you could use a stopwatch
  324. # [03:45] <othermaciej> or if you want to ignore network load time, instrument the page with a <script> to save the current time at the very top of the page (right inside <head> I guess) and then check in the "load" listener how much time elapsed
  325. # [03:45] <othermaciej> benchmarking is hard
  326. # [03:45] <othermaciej> if you want data and not just educated guesses, it will take some work
  327. # [03:46] <boblet> JonathanNeal: there’s a hardcore performance tool for IE that I saw mentioned on John Resig’s blog
  328. # [03:46] <boblet> http://ejohn.org/blog/deep-tracing-of-internet-explorer/
  329. # [03:46] <boblet> dynaTrace Ajax
  330. # [03:47] <boblet> there’s a similar extension for Google Chrome called Speed Tracer:
  331. # [03:47] <boblet> http://code.google.com/webtoolkit/speedtracer/
  332. # [03:48] <boblet> please publish any testing you do btw
  333. # [03:52] <JonathanNeal> Freaking Ajax tool requires registration and doesn't immediately send out the registration email.
  334. # [03:52] <JonathanNeal> If you want to collect info about who is using your product, don't make it so damn hard to get.
  335. # [03:53] <JonathanNeal> I'm referring to dynaTrace AJAX
  336. # [04:03] <JonathanNeal> I'm tweeting how much these guys suck for that.
  337. # [04:03] <JonathanNeal> That's bull when companys do this.
  338. # [04:03] <JonathanNeal> *ies
  339. # [04:07] * Joins: karlcow (~karl@nerval.la-grange.net)
  340. # [04:07] <boblet> JonathanNeal: so you’re thinking to test it?
  341. # [04:15] <JonathanNeal> I'm trying to.
  342. # [04:15] <JonathanNeal> boblet
  343. # [04:16] <boblet> JonathanNeal: if you have any success (and remember to) please ping me @boblet on twitter. I’d love to hear about it
  344. # [04:18] <JonathanNeal> boblet: http://twitter.com/jon_neal
  345. # [04:19] <JonathanNeal> I'll let you know on here or tweet it once I've gotten the software and had a successful test (which proves either case)
  346. # [04:20] <boblet> that’d be great!
  347. # [04:34] * Quits: othermaciej (~mjs@c-69-181-42-237.hsd1.ca.comcast.net) (Quit: othermaciej)
  348. # [04:43] * Joins: othermaciej (~mjs@c-69-181-42-237.hsd1.ca.comcast.net)
  349. # [04:47] * Quits: erikvold (~erikvold@S01060024012860e9.gv.shawcable.net) (Quit: Bye bye)
  350. # [04:57] * Joins: JonathanNeal_oww (~JonathanN@99-59-124-67.lightspeed.irvnca.sbcglobal.net)
  351. # [04:58] * Quits: JonathanNeal (~JonathanN@99-59-124-67.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 252 seconds)
  352. # [04:59] * Quits: annodomini (~lambda@wikipedia/lambda) (Quit: annodomini)
  353. # [04:59] * Joins: annodomini (~lambda@wikipedia/lambda)
  354. # [05:02] * Quits: annodomini (~lambda@wikipedia/lambda) (Client Quit)
  355. # [05:43] * Quits: othermaciej (~mjs@c-69-181-42-237.hsd1.ca.comcast.net) (Quit: othermaciej)
  356. # [05:45] * Quits: paradisaeidae (~chatzilla@r125-63-186-202.cpe.unwired.net.au) (Read error: Connection reset by peer)
  357. # [05:46] * Joins: paradisaeidae (~chatzilla@r125-63-186-202.cpe.unwired.net.au)
  358. # [05:51] * Joins: Utkarsh (~admin@117.201.87.50)
  359. # [05:55] * Quits: paradisaeidae (~chatzilla@r125-63-186-202.cpe.unwired.net.au) (Read error: Connection reset by peer)
  360. # [06:00] * Joins: surkov (~surkov@99-57-136-50.lightspeed.sntcca.sbcglobal.net)
  361. # [06:07] * Joins: paradisaeidae_ (~chatzilla@r125-63-186-202.cpe.unwired.net.au)
  362. # [06:12] * Quits: miketaylr (~miketaylr@24.42.95.234) (Remote host closed the connection)
  363. # [06:17] * Quits: paradisaeidae_ (~chatzilla@r125-63-186-202.cpe.unwired.net.au) (Read error: Connection reset by peer)
  364. # [06:18] * Joins: paradisaeidae (~chatzilla@r125-63-186-202.cpe.unwired.net.au)
  365. # [06:20] * JonathanNeal_oww is now known as JonathanNeal
  366. # [06:37] <JonathanNeal> Well, I made a test.
  367. # [06:38] <JonathanNeal> Afte running several tests, each test running itself 100,000 times...
  368. # [06:39] <JonathanNeal> The average time it takes for JS to add support for styled HTML5 elements in IE6 browsers is from 0.01ms in native IE6 to 0.05ms in emulated IE6, with a 0.000497ms descrepency caused by the test itself.
  369. # [06:43] * Quits: TabAtkins_ (~chatzilla@70-139-15-246.lightspeed.rsbgtx.sbcglobal.net) (Ping timeout: 265 seconds)
  370. # [06:44] * Quits: TabAtkins (~chatzilla@70-139-15-246.lightspeed.rsbgtx.sbcglobal.net) (Ping timeout: 248 seconds)
  371. # [06:50] * Quits: shepazu (~schepers@adsl-221-126-121.rmo.bellsouth.net) (Quit: shepazu)
  372. # [06:51] * Joins: shepazu (~schepers@adsl-221-126-121.rmo.bellsouth.net)
  373. # [06:56] * Quits: shepazu (~schepers@adsl-221-126-121.rmo.bellsouth.net) (Quit: Core Breach)
  374. # [07:15] * Joins: _Utkarsh (~admin@117.201.87.84)
  375. # [07:16] * Joins: othermaciej (~mjs@c-69-181-42-237.hsd1.ca.comcast.net)
  376. # [07:17] * Quits: Utkarsh (~admin@117.201.87.50) (Ping timeout: 260 seconds)
  377. # [07:22] * Quits: gavin_ (~gavin@firefox/developer/gavin) (Ping timeout: 265 seconds)
  378. # [07:29] <MikeSmith> I see some mentions of an open letter from the FSF to Google about free-licensing On2 video codecs
  379. # [07:30] <MikeSmith> wondering where the actual FSF communiqué is
  380. # [07:31] <MikeSmith> .me finds http://www.fsf.org/blogs/community/google-free-on2-vp8-for-youtube
  381. # [07:32] <MikeSmith> hmm, this looks more like just the case of one dude who has blogging perms at http://www.fsf.org/blogs/community/ deciding to post about it
  382. # [07:32] <gavin> Google was going to release On2, but are reconsidering the decision now that the FSF thinks it's a good idea
  383. # [07:32] <gavin> er, s/On2/VP8/
  384. # [07:33] <MikeSmith> heh
  385. # [07:33] <MikeSmith> <snort>
  386. # [07:34] <MikeSmith> yeah, that would seem to be a good idea in general for reconsidering any decision that would otherwise be obviously beneficial
  387. # [07:35] <MikeSmith> btw, about #webkit not allowing nick changes, I started to have that problem, fairly recently
  388. # [07:35] <MikeSmith> like, within the last 3 or 4 weeks or so
  389. # [07:35] <MikeSmith> and I also get the same message about being "banned"
  390. # [07:35] * Joins: shepazu (~schepers@adsl-221-126-121.rmo.bellsouth.net)
  391. # [07:35] <gavin> that's when the freenode spamming started
  392. # [07:35] <MikeSmith> ah
  393. # [07:36] <gavin> and channels started all going +R (registered users only)
  394. # [07:36] <gavin> then the ircd switchover happened, and some channels are still +q $~a (the new +R)
  395. # [07:36] <gavin> they should probably remove it now that the spamming has mostly stopped, but othermaciej doesn't seem keen on the idea
  396. # [07:37] <MikeSmith> so if I register my other nicks, maybe that will let me change them when I need to
  397. # [07:37] * MikeSmith is now known as MikeSmithX
  398. # [07:40] <MikeSmithX> "You are already logged in as MikeSmith." "Use GROUP to register MikeSmithX to your account." .. "group :Unknown command"
  399. # [07:41] * Joins: Necrathex (~bleptop@212-123-163-12.ip.telfort.nl)
  400. # [07:41] <MikeSmithX> d'oh, "/nickserv group"..
  401. # [07:42] * MikeSmithX is now known as MikeSmithXX
  402. # [07:43] * MikeSmithXX is now known as MikeSmith
  403. # [07:46] * Joins: zalan (~zalan@540071FA.dsl.pool.telekom.hu)
  404. # [07:54] * Joins: zcorpan (~zcorpan@c-2e99e355.410-6-64736c14.cust.bredbandsbolaget.se)
  405. # [07:57] * Quits: paradisaeidae (~chatzilla@r125-63-186-202.cpe.unwired.net.au) (Read error: Connection reset by peer)
  406. # [08:00] * Joins: paradisaeidae (~chatzilla@r125-63-186-202.cpe.unwired.net.au)
  407. # [08:08] * Joins: FireFly (~firefly@unaffiliated/firefly)
  408. # [08:08] <fantasai_> n/lastlog fantasai
  409. # [08:09] * fantasai_ is now known as fantasai
  410. # [08:10] * Parts: fantasai (fantasai@connectionreset.info)
  411. # [08:14] * Joins: sandeep (~d1g1t@unaffiliated/sandeep)
  412. # [08:17] * Joins: annevk (~annevk@5355737B.cable.casema.nl)
  413. # [08:20] * Joins: roc (~roc@ip67-152-86-163.z86-152-67.customer.algx.net)
  414. # [08:26] <JonathanNeal> Any editors in the house?
  415. # [08:26] <JonathanNeal> I mean ... like to review an email I'm sending to the co in support of HTML5.
  416. # [08:28] <annevk> boblet, would be nice if someone translated that filtered info back again so I could miss out on the bs too :)
  417. # [08:28] <annevk> (re: some hours ago)
  418. # [08:29] <MikeSmith> http://cristianadam.blogspot.com/2010/02/ie-tag-take-two.html .. 'To enable <video> tag for Internet Explorer you need to add xmlns="http://www.w3.org/1999/xhtml/video" attribute'
  419. # [08:30] * Quits: paradisaeidae (~chatzilla@r125-63-186-202.cpe.unwired.net.au) (Read error: Connection reset by peer)
  420. # [08:31] * Joins: paradisaeidae (~chatzilla@r125-63-186-202.cpe.unwired.net.au)
  421. # [08:35] * Joins: eighty4 (~eighty4@h-112-7.A163.corp.bahnhof.se)
  422. # [08:36] * Quits: salavas (salavas@h4n1fls31o279.telia.com) (Ping timeout: 264 seconds)
  423. # [08:38] * Quits: paradisaeidae (~chatzilla@r125-63-186-202.cpe.unwired.net.au) (Read error: Connection reset by peer)
  424. # [08:39] * Joins: paradisaeidae (~chatzilla@r125-63-186-202.cpe.unwired.net.au)
  425. # [08:47] * Quits: paradisaeidae (~chatzilla@r125-63-186-202.cpe.unwired.net.au) (Read error: Connection reset by peer)
  426. # [08:47] * Joins: Maurice (~ano@a80-101-46-164.adsl.xs4all.nl)
  427. # [08:48] * Joins: paradisaeidae (~chatzilla@r125-63-186-202.cpe.unwired.net.au)
  428. # [08:49] * Joins: pesla (~retep@procurios.xs4all.nl)
  429. # [08:58] * Joins: mhausenblas (~mhausenbl@wg1-nat.fwgal01.deri.ie)
  430. # [09:01] * Quits: FireFly (~firefly@unaffiliated/firefly) (Quit: Leaving)
  431. # [09:03] * Quits: tyoshino_ (~tyoshino@220.109.219.244) (Quit: Leaving...)
  432. # [09:10] * Quits: zalan (~zalan@540071FA.dsl.pool.telekom.hu)
  433. # [09:15] * hsivonen cann't get to work due to a lock malfunction
  434. # [09:15] <hsivonen> it's interesting to see how little documentation one needs to convince a locksmith to come over
  435. # [09:17] <hsivonen> anyway, nice to see that Adam wrote a counter-proposal to Larry's
  436. # [09:17] <hsivonen> now I don't have to
  437. # [09:18] * Joins: mpt (~mpt@canonical/mpt)
  438. # [09:18] <MikeSmith> hsivonen: you should send a +1 at least
  439. # [09:18] <boblet> annevk: well, just ignore everything but the spec, and you’ll be about there ;-)
  440. # [09:20] <boblet> JonathanNeal: so the shiv to addHTML5 support adds 0.04ms to IE6’s page load? that’s … acceptable, hehe
  441. # [09:20] <hsivonen> MikeSmith: ok. I'll express my support to zero edits
  442. # [09:21] <hsivonen> I note that the TAG as a whole has been unwilling to support the doctype versioning change proposal
  443. # [09:23] * Joins: workmad3 (~workmad3@cpc3-bagu10-0-0-cust651.1-3.cable.virginmedia.com)
  444. # [09:25] * Joins: virtuelv (~virtuelv_@162.179.251.212.customer.cdi.no)
  445. # [09:30] * Quits: workmad3 (~workmad3@cpc3-bagu10-0-0-cust651.1-3.cable.virginmedia.com) (Remote host closed the connection)
  446. # [09:30] * Quits: mpt (~mpt@canonical/mpt) (Ping timeout: 264 seconds)
  447. # [09:33] * Joins: zalan (~zalan@54007081.dsl.pool.telekom.hu)
  448. # [09:34] * Quits: surkov (~surkov@99-57-136-50.lightspeed.sntcca.sbcglobal.net) (Quit: surkov)
  449. # [09:38] * Quits: _Utkarsh (~admin@117.201.87.84) (Ping timeout: 272 seconds)
  450. # [09:39] * Quits: MikeSmith (~MikeSmith@EM114-48-229-121.pool.e-mobile.ne.jp) (Ping timeout: 265 seconds)
  451. # [09:44] * Joins: MikeSmith (~MikeSmith@EM114-48-49-63.pool.e-mobile.ne.jp)
  452. # [09:53] <Hixie> othermaciej: you know, it strikes me that if we just include some data in the encrypted part, then just repeating that information (unencrypted) is actually proof enough that the server is reading the handshake
  453. # [09:53] * Parts: sandeep (~d1g1t@unaffiliated/sandeep)
  454. # [09:54] <annevk> Hixie, wasn't the concern with that simple echo thingies?
  455. # [09:57] <Hixie> well they'd have to decrypt it
  456. # [09:57] <Hixie> which is easy enough, but won't happen unless you really are a websocket server
  457. # [09:58] * Quits: paradisaeidae (~chatzilla@r125-63-186-202.cpe.unwired.net.au) (Ping timeout: 252 seconds)
  458. # [10:02] <othermaciej> Hixie: you would need to make sure that part of what they echo back is unpredictable
  459. # [10:02] <Hixie> right
  460. # [10:02] * Joins: svl (~chatzilla@a194-109-2-65.dmn.xs4all.nl)
  461. # [10:02] <othermaciej> ideally you want at least one thing to be both unpredictable *and* not verbatim
  462. # [10:03] <Hixie> well it wouldn't be verbatim, since it'd be encrypted
  463. # [10:03] <othermaciej> but the data XOR'd with the one-time pad key is all predictable
  464. # [10:03] <annevk> what counts as unpredictable? timestamps?
  465. # [10:04] <othermaciej> the key itself is the only unpredictable part
  466. # [10:04] <Hixie> annevk: random data
  467. # [10:04] <Hixie> othermaciej: i mean, client sends something like Unique-ID: 312524232362435234521, but in the encrypted part, and the server just has to say that back
  468. # [10:04] <othermaciej> annevk: random data generated by the browser after JS code transfers control
  469. # [10:04] <Hixie> othermaciej: but the server's returned data is unencrypted
  470. # [10:04] <othermaciej> Hixie: you could do that - then the client is generating two different random numbers
  471. # [10:04] <Hixie> right
  472. # [10:05] <othermaciej> one to be the encryption key and one to be the nonce
  473. # [10:05] <Hixie> yup
  474. # [10:05] <Hixie> they can be generated from the same single truely random number, it's not like they have to be independent
  475. # [10:05] <Hixie> so it's not an entropy drain
  476. # [10:06] <othermaciej> the other property Adam was trying to guarantee is that both request and response look like random bytes without WebSocket processing but I don't know offhand why it's important
  477. # [10:06] <Hixie> yeah
  478. # [10:06] <othermaciej> Hixie: they do have to be independent, XORing a value with itself won't be very random
  479. # [10:06] <annevk> btw http://lists.w3.org/Archives/Member/process-issues/2010Feb/0006.html (W3C Member-only)
  480. # [10:06] <Hixie> othermaciej: fair enough
  481. # [10:08] <Hixie> annevk: well, i have to say, i can't disagree with anything in that e-mail, but i imagine i'd read between the lines rather differently!
  482. # [10:09] <annevk> uhuh :)
  483. # [10:09] * othermaciej facepalms at that message
  484. # [10:09] <othermaciej> also, at the other content of that archive
  485. # [10:10] <Hixie> http://lists.w3.org/Archives/Member/process-issues/2010Feb/0003.html is even more amusing, given the link in that e-mail
  486. # [10:10] <Hixie> especially as the accusation immediately after that link is one i would level at the person writing that e-mail!
  487. # [10:10] <Hixie> anyway
  488. # [10:12] * Quits: Rik` (~Rik`@pha75-2-81-57-187-57.fbx.proxad.net) (Quit: Rik`)
  489. # [10:20] * Joins: workmad3 (~workmad3@cpc3-bagu10-0-0-cust651.1-3.cable.virginmedia.com)
  490. # [10:27] * Joins: tametick (~chatzilla@chello084114134061.3.15.vie.surfer.at)
  491. # [10:28] <annevk> http://twitter.com/patrick_h_lauke/status/9436007749 lol
  492. # [10:34] * Joins: mpt (~mpt@canonical/mpt)
  493. # [10:44] * Joins: ROBOd (~robod@89.122.216.38)
  494. # [10:46] * Quits: Lachy (~Lachlan@138.199.66.243) (Quit: This computer has gone to sleep)
  495. # [10:59] * Joins: Phae (~phaeness@gateb.mh.bbc.co.uk)
  496. # [10:59] * Joins: othree (~othree@admin39.ct.ntust.edu.tw)
  497. # [11:00] * Quits: ROBOd (~robod@89.122.216.38) (Read error: Connection reset by peer)
  498. # [11:04] * Joins: ROBOd (~robod@89.122.216.38)
  499. # [11:06] <hsivonen> annevk: thanks for the process-issues URL
  500. # [11:06] * Joins: Lachy (~Lachlan@pat.se.opera.com)
  501. # [11:07] <Hixie> right, bed time
  502. # [11:07] <Hixie> nn
  503. # [11:16] * Quits: virtuelv (~virtuelv_@162.179.251.212.customer.cdi.no) (Quit: Ex-Chat)
  504. # [11:17] * Quits: tantek (~tantek@70-36-139-7.dsl.dynamic.sonic.net) (Quit: tantek)
  505. # [11:21] <MikeSmith> fwiw, I turned the webkit_commits twitter bot back on
  506. # [11:25] * Quits: jwalden (~waldo@c-98-248-40-206.hsd1.ca.comcast.net) (Quit: ChatZilla 0.9.86-rdmsoft [XULRunner 1.9.2/20100122095031])
  507. # [11:28] * Quits: rauchg (~rauchg@75.16.26.133) (Quit: rauchg)
  508. # [11:30] * Quits: mhausenblas (~mhausenbl@wg1-nat.fwgal01.deri.ie) (Quit: brb)
  509. # [11:40] * Joins: mhausenblas (~mhausenbl@wg1-nat.fwgal01.deri.ie)
  510. # [11:53] * Quits: Heimidal (~heimidal@unaffiliated/heimidal) (Remote host closed the connection)
  511. # [11:55] * Quits: tametick (~chatzilla@chello084114134061.3.15.vie.surfer.at) (Quit: ChatZilla 0.9.86 [Firefox 3.6/20100115132715])
  512. # [12:03] * Quits: zalan (~zalan@54007081.dsl.pool.telekom.hu) (Read error: Connection reset by peer)
  513. # [12:24] * Quits: jorlow (~jorlow@2620:0:1042:2:225:ff:fef2:bfa4) (Quit: jorlow)
  514. # [12:28] * Joins: zalan (~zalan@54007081.dsl.pool.telekom.hu)
  515. # [12:39] * Quits: Rik|work (~Rik|work@fw01d.skyrock.net) (Quit: Rik|work)
  516. # [12:45] * Joins: Rik|work (~Rik|work@fw01d.skyrock.net)
  517. # [12:48] * Joins: dbaron (~dbaron@m445f36d0.tmodns.net)
  518. # [12:49] * Joins: Utkarsh (~admin@117.201.89.52)
  519. # [12:53] <gsnedders> JonathanNeal: I'm around now
  520. # [12:53] <gsnedders> JonathanNeal: But seeming you said good morning when you pinged me over the weekend at a time four hours later, I guess that's quite uselss
  521. # [13:01] * Joins: murr4y (~murray@89.84-49-66.nextgentel.com)
  522. # [13:04] * Quits: dbaron (~dbaron@m445f36d0.tmodns.net) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  523. # [13:12] * Philip` wonders if updating his canvas tests would be useful
  524. # [13:15] <annevk> yes
  525. # [13:15] <annevk> a) gives some insight how far impls are along b) prolly generates more <canvas> feedback / improvements
  526. # [13:16] <Philip`> I hope there weren't too many features snuck into the spec while I wasn't looking
  527. # [13:16] * Philip` completely missed drawFocusRing
  528. # [13:22] * Quits: Lachy (~Lachlan@pat.se.opera.com) (Quit: This computer has gone to sleep)
  529. # [13:25] * Joins: Lachy (~Lachlan@pat.se.opera.com)
  530. # [13:34] <othermaciej> Philip`: yes, and you should submit them for the html5 test suite
  531. # [13:36] <Philip`> (I probably should have said "worthwhile" rather than "useful")
  532. # [13:40] * Quits: nessy (~Adium@124-168-170-167.dyn.iinet.net.au) (Quit: Leaving.)
  533. # [13:49] <othermaciej> well, I can't say how it would rate for you against other uses of your time
  534. # [13:49] <othermaciej> it would definitely be of great benefit to others
  535. # [13:49] <othermaciej> I would actually like to put your whole test suite into the WebKit regression tests
  536. # [13:53] * Quits: mpt (~mpt@canonical/mpt) (Ping timeout: 265 seconds)
  537. # [13:58] * Joins: yutak_home (~kee@N038037.ppp.dion.ne.jp)
  538. # [14:01] <MikeSmith> othermaciej: about 'should longdesc be considered "obsolete but conforming" or just conforming to a warning'
  539. # [14:02] <othermaciej> MikeSmith: yes?
  540. # [14:02] <MikeSmith> what does "just conforming to a warning" mean?
  541. # [14:02] <othermaciej> MikeSmith: it means that it would not be listed in the "obsolete but conforming" section or have that label applied to it, but the practical effect would be the same
  542. # [14:03] <MikeSmith> meaning that conformance checkers would still need to warn about it?
  543. # [14:03] <MikeSmith> it seems like it is effectively creating yet another conformance level
  544. # [14:04] <othermaciej> well, summary is in a gray zone right now where it's not totally clear which of those buckets it falls into
  545. # [14:04] <othermaciej> Cynthia's change proposal for summary would in fact label it as "obsolete but conforming"
  546. # [14:04] <othermaciej> my thinking is we should do the same for longdesc
  547. # [14:05] <othermaciej> I think the effect on validators is pretty much nil, it's just a matter of presentation and spec organization
  548. # [14:07] <MikeSmith> perhaps one possible remedy for this is to not use the word "obsolete" in the name of that section, but categorize them as "Conforming features that have specific caveats"
  549. # [14:07] <MikeSmith> or something else that is more in the sense of "caveat" rather than "obsoleted"
  550. # [14:08] * Joins: FireFly (~firefly@unaffiliated/firefly)
  551. # [14:08] <MikeSmith> the spec could mandate the specific warning messages that conformance checkers should emit for those cases
  552. # [14:09] <MikeSmith> or at least what specific sense the messages should convey
  553. # [14:10] * Joins: mpt (~mpt@canonical/mpt)
  554. # [14:10] <MikeSmith> e.g., in general, the sense would be "There is evidence to suggest this element is widely misused, therefore, make sure to use it with care."
  555. # [14:11] <MikeSmith> or if not "widely", at least "sometimes"
  556. # [14:11] <Philip`> Every feature of the language is sometimes misused
  557. # [14:11] <Dashiva> I don't think removing the word obsolete will do anything, it will just shift the battle to removing the new language
  558. # [14:11] <Philip`> and everything should be used with care
  559. # [14:12] <Dashiva> "Why does this fully conforming and not obsolete feature need a warning?"
  560. # [14:12] <Philip`> Maybe some need slightly more care than others, so perhaps we could have a care-o-meter that says longdesc rates 80% on the need-to-care index while summary is 70% and <a href> is only 20%
  561. # [14:13] <Philip`> Then we wouldn't have to keep drawing and shifting arbitrary lines between features that are good and features that are bad and features that are sort of in the middle so we'll allow them but complain a bit
  562. # [14:14] <Dashiva> And instead we get bikeshedding over what number to use for each feature
  563. # [14:15] <Dashiva> "Now only 19.95 care"
  564. # [14:15] <Philip`> We could vote and use the mean rating
  565. # [14:15] <Dashiva> Median, surely
  566. # [14:16] <MikeSmith> Dashiva: I think he meant "mean" in the sense of "meanest"
  567. # [14:16] <Dashiva> Or maybe a mix, like removing the top and bottom 10% and doing the mean of the rest
  568. # [14:16] <Philip`> Dashiva: Good point - we should have a vote on what voting mechanisms to use
  569. # [14:17] <Dashiva> How about we just stick to the current categories
  570. # [14:17] <Philip`> Everyone can rate each voting mechanism out of 10, and then we use a weighted sum of all voting mechanisms
  571. # [14:18] <MikeSmith> all smartassery aside, we do really need to get agreement about what the spec should say about these attributes
  572. # [14:18] <Dashiva> There is wide agreement, and a few dissenting voices
  573. # [14:18] <Philip`> Dashiva: If we make enough new categories, then people will be confused into supporting choices that are equivalent to ones they've rejected
  574. # [14:18] <Philip`> (I assume that's the purpose of tweaking the wording of category labels)
  575. # [14:19] <MikeSmith> Dashiva: no, that's not an accurate assessment of the state of things, actually
  576. # [14:19] <MikeSmith> and that's not the basis for making decisions, regardless
  577. # [14:19] <MikeSmith> by anybody's measure
  578. # [14:20] <Dashiva> It's the basis of quite a few systems
  579. # [14:20] <MikeSmith> true, like mob rule
  580. # [14:20] * Joins: pmuellr (~pmuellr@nat/ibm/x-znreoenncetxcdao)
  581. # [14:21] <Dashiva> And, you know, democracy
  582. # [14:21] <MikeSmith> right, what I said
  583. # [14:21] <othermaciej> MikeSmith: the closest equivalent to "Obsolete but conforming" in HTML4 would have been "Deprecated
  584. # [14:21] <othermaciej> MikeSmith: in non-HTML contexts, things that are "deprecated" tend to generate a warning, though I don't think any HTML4 validator ever did that
  585. # [14:22] <MikeSmith> well, HTML4 validator(s) have a lot of deficiencies
  586. # [14:22] <MikeSmith> that was then, this is now
  587. # [14:22] <Dashiva> MikeSmith: We support philosopher kings too, but apparently you don't like that either
  588. # [14:22] <MikeSmith> othermaciej: in my opinion "deprecated" is a fine, accurate way to describe this case
  589. # [14:23] <othermaciej> I think "obsolete but conforming" is also an ok way to describe it
  590. # [14:23] <MikeSmith> yeah, it's just more words
  591. # [14:23] <othermaciej> "You shouldn't be using this any more, but we will grudgingly allow it, for now"
  592. # [14:23] <MikeSmith> yeah, I will conceded it's probably more precise
  593. # [14:23] <othermaciej> I don't really want to open up the can of worms of what that section should be named
  594. # [14:24] <othermaciej> to me that's much less important than the actual real effects
  595. # [14:24] <Dashiva> But none of those wordings actually satisfy the people who want to encourage use of that feature
  596. # [14:24] <MikeSmith> Dashiva: I like philosopher kings pretty well, actually
  597. # [14:24] <othermaciej> I think "Obsolete but conforming" is an improvement over "Downplayed error"
  598. # [14:24] <othermaciej> I would have just said "mandatory warning" or something
  599. # [14:25] <MikeSmith> "downplayed error" is just goofy
  600. # [14:25] <othermaciej> "deprecated" also seems sort of ok, though I think some people don't like that specific word because the way HTML4 handled it seemed to be ineffective in discouraging those features
  601. # [14:25] <Dashiva> deprecated is just wrong
  602. # [14:25] <Dashiva> It implies removing support in a later revision
  603. # [14:26] <othermaciej> I guess that is wrong in two subtle ways:
  604. # [14:26] * Joins: mat_t (~mattomasz@91.189.88.12)
  605. # [14:26] <othermaciej> 1) we'll likely never remove support, just any semblance of conforming status
  606. # [14:26] <othermaciej> 2) we don't necessarily promise to remove even that
  607. # [14:30] <Dashiva> Most of the cases seem entirely uncontroversial, with summary being quite the exception
  608. # [14:31] <Dashiva> But is there anyone who objects to summary being marked as <whatever> who doesn't also want summary to be fully unconditionally conforming?
  609. # [14:31] <othermaciej> for summary it might cease to be controversial if the Change Proposal currently in development by the a11y tf goes through
  610. # [14:37] * Joins: TabAtkins (~chatzilla@70-139-15-246.lightspeed.rsbgtx.sbcglobal.net)
  611. # [14:37] * Joins: TabAtkins_ (~chatzilla@70-139-15-246.lightspeed.rsbgtx.sbcglobal.net)
  612. # [14:41] * Joins: ChrisLTD|Work (~blahness@152.2.194.196)
  613. # [14:43] * Quits: mpt (~mpt@canonical/mpt) (Ping timeout: 268 seconds)
  614. # [15:06] * Joins: BlurstOfTimes (~blurstoft@168.203.117.66)
  615. # [15:12] * Joins: annodomini (~lambda@c-75-69-96-104.hsd1.nh.comcast.net)
  616. # [15:12] * Quits: annodomini (~lambda@c-75-69-96-104.hsd1.nh.comcast.net) (Changing host)
  617. # [15:12] * Joins: annodomini (~lambda@wikipedia/lambda)
  618. # [15:14] * Joins: taf2 (~taf2@173-13-232-33-WashingtonDC.hfc.comcastbusiness.net)
  619. # [15:16] * Quits: yutak_home (~kee@N038037.ppp.dion.ne.jp) (Quit: Ex-Chat)
  620. # [15:20] * Joins: paul_irish (~paul_iris@12.33.239.250)
  621. # [15:23] * Joins: miketaylr (~miketaylr@38.117.156.163)
  622. # [15:23] * Joins: lazni1 (~lazni@118.71.1.136)
  623. # [15:26] * Joins: jgornick (~joe@199.199.212.242)
  624. # [15:35] <TabAtkins> JonathanNeal: So, effectively zero time to get IE to support the new elements? Fractions of a millisecond are basically free.
  625. # [15:35] * Joins: maikmerten (~merten@ls5dhcp196.cs.uni-dortmund.de)
  626. # [15:35] * Joins: MikeSmithX (~MikeSmith@EM114-48-233-200.pool.e-mobile.ne.jp)
  627. # [15:38] <Philip`> http://www.austriantrade.nl/awo-marktplatz/awoCompanySearch.do?selectedId=4006&editable=false&action=Details&language=en&country=tz - <a name="top"></a>...<img longdesc="#top">
  628. # [15:39] <Philip`> http://www.konyhatizezercikk.hu/product_info.php?products_id=716&osCsid=e6ce5f51d4fcec7641964b009e2e4bfe - <img longdesc="#oldalteto"> (undefined id)
  629. # [15:39] * Quits: MikeSmith (~MikeSmith@EM114-48-49-63.pool.e-mobile.ne.jp) (Ping timeout: 276 seconds)
  630. # [15:39] <Philip`> plus a few with longdesc="#"
  631. # [15:40] <Philip`> according to http://philip.html5.org/data/longdesc-raw.txt
  632. # [15:40] <Philip`> othermaciej: "Is it actually used that way in content?" - apparently not frequently
  633. # [15:40] <othermaciej> Philip`: thanks
  634. # [15:40] <othermaciej> Philip`: so that's one plausibly correct fragment reference
  635. # [15:41] <othermaciej> Philip`: out of how many pages total?
  636. # [15:41] <Philip`> About 425K
  637. # [15:42] <Philip`> http://philip.html5.org/data/dotbot-20090424.txt
  638. # [15:42] <Philip`> Which one is plausibly correct?
  639. # [15:42] * MikeSmithX is now known as MikeSmith
  640. # [15:42] <othermaciej> and those are the only idrefs?
  641. # [15:42] <Philip`> The one that points to an empty element, or the one that points to a non-existent element?
  642. # [15:42] <othermaciej> the #top one, out of those you mentioned
  643. # [15:43] <othermaciej> is there relevant content after the <a>?
  644. # [15:43] <Philip`> No
  645. # [15:43] <Philip`> See the page itself :-)
  646. # [15:44] <Philip`> (It hasn't changed since the crawler saw it)
  647. # [15:44] <Philip`> I just looked for the string "# in the longdesc-raw.txt file
  648. # [15:45] <Philip`> so it's all the pages that have <img longdesc="#...">
  649. # [15:45] <othermaciej> I see, that anchor is just before the image, so not clear how much it's supposed to help
  650. # [15:46] <othermaciej> I would say post your findings on public-html
  651. # [15:46] <othermaciej> I am more curious if it works in any reasonable way in browser+AT combos
  652. # [15:47] <othermaciej> if not, then energy is probably better directed into more fully implementing ARIA than into making longdesc="#..." work reasonably
  653. # [15:51] <Philip`> Whoops
  654. # [15:51] <Philip`> Opera's incremental find doesn't work perfectly if you use it before the page has finished loading
  655. # [15:51] <Philip`> so there's a few more longdesc="#..."s
  656. # [15:53] * Joins: tametick (~chatzilla@chello084114134061.3.15.vie.surfer.at)
  657. # [15:54] <othermaciej> I count 28 values with # signs
  658. # [15:54] <othermaciej> 11 of which are not just "#"
  659. # [15:55] <othermaciej> most look like similar $top situations
  660. # [15:59] * Quits: eighty4 (~eighty4@h-112-7.A163.corp.bahnhof.se) (Read error: No route to host)
  661. # [16:02] * Joins: eighty4 (~eighty4@h-112-7.A163.corp.bahnhof.se)
  662. # [16:15] * Joins: mpt (~mpt@canonical/mpt)
  663. # [16:19] <Philip`> Is it possible to have a 0x0 pixel JPEG?
  664. # [16:20] <Necrathex> no, but 0x1 is
  665. # [16:20] <Necrathex> ^_^
  666. # [16:20] <othermaciej> most image formats seem to have that as a possibility but I don't know about JPEG
  667. # [16:20] * Quits: ttepasse (~ttepasse@ip-95-222-120-117.unitymediagroup.de) (Quit: Verlassend)
  668. # [16:21] <Philip`> PNG doesn't ("Zero is an invalid value")
  669. # [16:24] <Philip`> Necrathex: Peculiar
  670. # [16:25] <Philip`> JPEG is all weird and talks about samples and lines instead of width and height :-(
  671. # [16:25] <Necrathex> i'm pretty sure you can make a 0x0 svg image
  672. # [16:26] <Dashiva> You can make SVG without size at all, can't you?
  673. # [16:27] <Philip`> Hmm, can't JPEG do 0x0 if you use this special DNL thing to set it to 0?
  674. # [16:27] <Necrathex> why do you need an empty image?
  675. # [16:27] <Dashiva> Division by zero!
  676. # [16:27] <Philip`> or maybe you can only do the DNL thing after the first line
  677. # [16:28] <Philip`> if a "scan" is related to a line in some way
  678. # [16:28] <Philip`> This seems too complex to bother understanding :-)
  679. # [16:28] <Philip`> (or at least too different to terminology I understand)
  680. # [16:29] * Joins: aroben (~aroben@unaffiliated/aroben)
  681. # [16:29] <Philip`> Necrathex: Just wondering what could/should happen if you do toDataURL("image/jpeg") on a 0xN or Nx0 canvas
  682. # [16:30] <Philip`> and/or if you use drawImage with a 0x0 image
  683. # [16:31] <annevk> Philip`, worthwhile depends on you, it would be useful to a lot of people I think
  684. # [16:31] * Joins: wakaba_0 (~wakaba_@ntkyto167068.kyto.nt.ftth4.ppp.infoweb.ne.jp)
  685. # [16:35] * Quits: wakaba_ (~wakaba_@ntkyto167068.kyto.nt.ftth4.ppp.infoweb.ne.jp) (Ping timeout: 252 seconds)
  686. # [16:35] * annevk likes that HTML5 makes LF out of &13; but has no good arguments
  687. # [16:35] * annevk sighs
  688. # [16:39] * Joins: lazni (~lazni@118.71.97.228)
  689. # [16:41] * Quits: lazni1 (~lazni@118.71.1.136) (Ping timeout: 248 seconds)
  690. # [16:42] <AryehGregor> <othermaciej> also using the <video> element may be higher performance than plugin-based video solutions <-- Are there benchmarks that show this is consistently true? I've heard conflicting reports.
  691. # [16:44] <Dashiva> I've heard reports <video> is worse than plugins for fullscreen
  692. # [16:45] <Philip`> "may be" != "is"
  693. # [16:46] <Philip`> It's certainly possible that it can be higher performance than a plugin, because in the worst case it can be implemented exactly like a plugin and in the best case it can be more tightly integrated with the browser's rendering code
  694. # [16:47] <fupp> according to adobe, <video> doesn't solve the performance problem, but does the exact same thing that makes flash slow, to convert YUV data to the RGB colorspace and combine the image with other elements
  695. # [16:47] <fupp> http://blogs.adobe.com/penguin.swf/2010/01/solving_different_problems.html
  696. # [16:48] <hsivonen> fupp: if you profile Firefox running a pageload test, you'll find that one of the top things taking time is the color domain conversion for JPEGs
  697. # [16:49] <hsivonen> so yeah, YUV to RGB is a big deal
  698. # [16:49] <hsivonen> it's not the only deal, though
  699. # [16:49] <Dashiva> Couldn't a browser do what a dedicated media player does?
  700. # [16:50] <zcorpan> depends on whether you're doing fancy things like rotating the video or having transparency
  701. # [16:51] <hsivonen> Dashiva: in the absence of hard SVG filters, yes
  702. # [16:51] <hsivonen> https://bugzilla.mozilla.org/show_bug.cgi?id=538323
  703. # [16:51] <asmodai> Mmm, could the html in the HTML 4.01 doctype be lowercase as well, or should it always be uppercase? (Can't remember >_< )
  704. # [16:51] <hsivonen> asmodai: yes
  705. # [16:51] <gsnedders> It's case-insensitive
  706. # [16:51] <gsnedders> HtMl is fine too
  707. # [16:51] <workmad3> htmL
  708. # [16:51] <asmodai> Heh, I'll just stick to the lowercase then. ^^
  709. # [16:51] * Joins: lazni1 (~lazni@118.71.60.217)
  710. # [16:52] * asmodai seriously wants to nail this developer to the wall. Not sure which HTML standard he was following, but it was not HTML 4.01 or XHTML 1.0
  711. # [16:52] <hsivonen> zcorpan: I'd expect rotation and transparency to work if the video is an OpenGL texture converted from YUV to RGB using an OpenGL pixel shader
  712. # [16:52] <hsivonen> and the 2D compositing is done on the GPU
  713. # [16:53] * Quits: lazni (~lazni@118.71.97.228) (Ping timeout: 252 seconds)
  714. # [16:53] <hsivonen> although that's not what movie players on Linux do
  715. # [16:53] <hsivonen> they tend to use xv instead of OpenGL
  716. # [16:55] * Quits: maikmerten (~merten@ls5dhcp196.cs.uni-dortmund.de) (Remote host closed the connection)
  717. # [16:57] * Quits: cpearce (~cpearce@ip67-152-86-163.z86-152-67.customer.algx.net) (Quit: ChatZilla 0.9.86-rdmsoft [XULRunner 1.9.0.15/2009101909])
  718. # [16:57] <AryehGregor> Why can't you solve color format conversions by just using a different color format in the videos?
  719. # [16:57] * Quits: Lachy (~Lachlan@pat.se.opera.com) (Quit: Leaving)
  720. # [16:58] <Philip`> Because YUV compresses much better than RGB
  721. # [16:59] * Joins: Lachy (~Lachlan@pat.se.opera.com)
  722. # [16:59] <AryehGregor> Hmph.
  723. # [16:59] <AryehGregor> I see.
  724. # [16:59] * Quits: Lachy (~Lachlan@pat.se.opera.com) (Client Quit)
  725. # [17:00] * Quits: mpt (~mpt@canonical/mpt) (Ping timeout: 252 seconds)
  726. # [17:00] * Quits: aroben (~aroben@unaffiliated/aroben) (Ping timeout: 248 seconds)
  727. # [17:04] <AryehGregor> Is this the sort of thing that parallelizes nicely, so we can all rest assured that in five years we'll do fine because eight cores are standard?
  728. # [17:05] <AryehGregor> I imagine you could hand one frame to one CPU and the next to another.
  729. # [17:05] <AryehGregor> Or something.
  730. # [17:05] * Joins: Lachy (~Lachlan@pat.se.opera.com)
  731. # [17:05] <AryehGregor> (maybe not, if there's delta encoding or whatnot . . . oh well, not my field)
  732. # [17:05] * Quits: Maurice (~ano@a80-101-46-164.adsl.xs4all.nl) (Quit: Disconnected...)
  733. # [17:05] <MikeSmith> so it seems the first f2f meeting of the hybi wg will be March 24 in Anaheim, California.. would be good if we could get some people to attend
  734. # [17:06] <MikeSmith> I think it will cost you 200 USD for registration, though
  735. # [17:07] <hsivonen> MikeSmith: what's the goal of the meeting? (I'm not planning on attending. just curious.)
  736. # [17:09] <MikeSmith> hsivonen: not sure what the agenda is.. I've not been following the hybi discussions closely for last couple months
  737. # [17:10] <Philip`> AryehGregor: Each pixel is entirely independent, so you can do colour conversions with loads of parallelism
  738. # [17:10] <Philip`> which is why it's good to do it on the GPU rather than CPU, because then you can process hundreds of pixels in parallel
  739. # [17:11] <Philip`> as far as I'm aware
  740. # [17:11] <AryehGregor> Well, I trust that people who know more than I do will figure out some way to do it efficiently. :)
  741. # [17:11] <Philip`> In five years we'll all have higher-resolution monitors so there'll be more pixels to decode :-)
  742. # [17:12] <Philip`> so simply relying on hardware improvements won't fully solve the problem
  743. # [17:12] <hsivonen> Philip`: U and V are not truly independent for each pixel, though
  744. # [17:12] <AryehGregor> Rats.
  745. # [17:13] <hsivonen> Philip`: assuming a sampling where the resolution of U and V is lower than the resolution of Y
  746. # [17:13] <AryehGregor> I guess video is pretty close to unlimited resolution, for the foreseeable future. You can always get better quality until the pixels become invisible. That's a long way off . . .
  747. # [17:13] * Quits: lazni1 (~lazni@118.71.60.217) (Quit: Leaving.)
  748. # [17:14] * hsivonen can't tell the difference between 720p and 1080p movie trailers on a 1080p display from a normal movie watching distance
  749. # [17:14] <hsivonen> (as in: downloading the same trailer and 720p and 1080p from Apple and comparing)
  750. # [17:15] <annevk> you need at least 42inch or so
  751. # [17:15] <Philip`> hsivonen: Oh, true
  752. # [17:15] * Joins: lazni (~lazni@118.71.60.217)
  753. # [17:16] <Philip`> but 4x2 blocks (?) should be independent
  754. # [17:16] <Philip`> and there's still zillions of those to process in parallel
  755. # [17:17] <hsivonen> annevk: I used a 37" display
  756. # [17:18] * Quits: roc (~roc@ip67-152-86-163.z86-152-67.customer.algx.net) (Quit: roc)
  757. # [17:19] <annevk> hsivonen, I'm not a 100% sure of course, but I heard you start seeing the difference from 42"... So presumably you need 50 or so to really see it
  758. # [17:19] * Joins: surkov (~surkov@99-57-136-50.lightspeed.sntcca.sbcglobal.net)
  759. # [17:19] <annevk> of course, this doesn't stop them from working on 4000+
  760. # [17:20] * hsivonen notes that the live action in the newer star wars movies was shot at mere 1080p
  761. # [17:21] * Joins: gavin_ (~gavin@firefox/developer/gavin)
  762. # [17:21] * Joins: roc (~roc@ip67-152-86-163.z86-152-67.customer.algx.net)
  763. # [17:22] * Quits: roc (~roc@ip67-152-86-163.z86-152-67.customer.algx.net) (Read error: Connection reset by peer)
  764. # [17:25] * Joins: erikvold (~erikvold@S01060024012860e9.gv.shawcable.net)
  765. # [17:27] * Joins: rauchg (~rauchg@75.16.26.133)
  766. # [17:28] * Joins: aroben (~aroben@unaffiliated/aroben)
  767. # [17:34] * Joins: roc (~roc@ip67-152-86-163.z86-152-67.customer.algx.net)
  768. # [17:35] * Quits: roc (~roc@ip67-152-86-163.z86-152-67.customer.algx.net) (Read error: Connection reset by peer)
  769. # [17:35] * Joins: roc_ (~roc@ip67-152-86-163.z86-152-67.customer.algx.net)
  770. # [17:36] * Quits: surkov (~surkov@99-57-136-50.lightspeed.sntcca.sbcglobal.net) (Quit: surkov)
  771. # [17:43] * Quits: mhausenblas (~mhausenbl@wg1-nat.fwgal01.deri.ie) (Quit: mhausenblas)
  772. # [17:46] * roc_ notes that we have GPU-based YUV-to-RGB conversion working for <video> "in the lab"
  773. # [17:46] <AryehGregor> Hurrah.
  774. # [17:47] * Quits: svl (~chatzilla@a194-109-2-65.dmn.xs4all.nl) (Quit: And back he spurred like a madman, shrieking a curse to the sky!)
  775. # [17:49] * Quits: wycats (~yehudakat@c-69-181-216-213.hsd1.ca.comcast.net) (Quit: wycats)
  776. # [17:53] * Joins: eric_carlson (~ericc@2620:0:1b00:1191:223:32ff:feb1:5d30)
  777. # [17:55] * Quits: roc_ (~roc@ip67-152-86-163.z86-152-67.customer.algx.net) (Quit: roc_)
  778. # [17:57] * Quits: JonathanNeal (~JonathanN@99-59-124-67.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 264 seconds)
  779. # [18:00] * Quits: TabAtkins_ (~chatzilla@70-139-15-246.lightspeed.rsbgtx.sbcglobal.net) (Quit: ChatZilla 0.9.86 [Firefox 3.6/20100115144158])
  780. # [18:02] * Quits: Lachy (~Lachlan@pat.se.opera.com) (Quit: Leaving)
  781. # [18:06] * Joins: Lachy (~Lachlan@static-88.131.66.114.addr.tdcsong.se)
  782. # [18:07] * Joins: Maurice (copyman@5ED548D4.cable.ziggo.nl)
  783. # [18:10] * Quits: ment (thement@ibawizard.net) (Quit: eof)
  784. # [18:11] * Joins: surkov (~surkov@nat/mozilla/x-mtijovdfkkjhviht)
  785. # [18:17] * Joins: JonathanNeal (~JonathanN@rrcs-76-79-114-213.west.biz.rr.com)
  786. # [18:18] * Joins: dave_levin (~dave_levi@2620:0:1008:1101:225:ff:fef0:9a9e)
  787. # [18:19] * Joins: cpearce (~cpearce@nat/mozilla/x-qwuefuoxvvzkeoam)
  788. # [18:20] <JonathanNeal> Goodmorning.
  789. # [18:20] * Joins: sbublava (~stephan@77.118.175.222.wireless.dyn.drei.com)
  790. # [18:22] * Quits: cpearce (~cpearce@nat/mozilla/x-qwuefuoxvvzkeoam) (Client Quit)
  791. # [18:25] * Quits: othermaciej (~mjs@c-69-181-42-237.hsd1.ca.comcast.net) (Quit: othermaciej)
  792. # [18:26] * Joins: cpearce (~cpearce@nat/mozilla/x-xdrcrixlxafewjzp)
  793. # [18:29] * Joins: ap_ (~ap@17.246.19.5)
  794. # [18:30] * Quits: MikeSmith (~MikeSmith@EM114-48-233-200.pool.e-mobile.ne.jp) (Ping timeout: 248 seconds)
  795. # [18:32] * Joins: MikeSmith (~MikeSmith@EM114-48-135-73.pool.e-mobile.ne.jp)
  796. # [18:33] * Quits: Lachy (~Lachlan@static-88.131.66.114.addr.tdcsong.se) (Quit: This computer has gone to sleep)
  797. # [18:33] * Joins: Heimidal (~heimidal@c-71-237-116-77.hsd1.co.comcast.net)
  798. # [18:33] * Quits: Heimidal (~heimidal@c-71-237-116-77.hsd1.co.comcast.net) (Changing host)
  799. # [18:33] * Joins: Heimidal (~heimidal@unaffiliated/heimidal)
  800. # [18:34] * Quits: pesla (~retep@procurios.xs4all.nl) (Quit: ( www.nnscript.com :: NoNameScript 4.21 :: www.esnation.com ))
  801. # [18:36] * Joins: mpt (~mpt@canonical/mpt)
  802. # [18:37] * Joins: roc (~roc@nat/mozilla/x-qxifqgltnevlczlb)
  803. # [18:43] * Joins: ttepasse (~ttepasse@dslb-084-060-026-177.pools.arcor-ip.net)
  804. # [18:44] * Quits: roc (~roc@nat/mozilla/x-qxifqgltnevlczlb) (Quit: roc)
  805. # [18:45] <boblet> hey Mike…
  806. # [18:47] <MikeSmith> yeah
  807. # [18:47] <boblet> was just chatting to Yakura-san, and he mentioned that a lot of Japanese sites (esp. mobile) use <hr> as a content division. The new “*paragraph-level* thematic break” doesn’t mesh with that usage
  808. # [18:48] <boblet> makes sense on eg yahoo.co.jp’s HP when you turn off CSS atm. No <hr> would make it a wall of unstyled content
  809. # [18:48] <boblet> (admittedly as opposed to a slightly chunked wall of unstyled content :)
  810. # [18:50] <boblet> are UAs eventually expected to differentiate between sectioning content blocks visually when CSS is disabled?
  811. # [18:51] <boblet> and with that rousing question I bid you adieu. sleep well…
  812. # [18:51] <boblet> nn
  813. # [18:52] * Quits: erikvold (~erikvold@S01060024012860e9.gv.shawcable.net) (Quit: me so sleepy)
  814. # [18:53] * Joins: erikvold (~erikvold@S01060024012860e9.gv.shawcable.net)
  815. # [18:53] * Joins: dglazkov (~dglazkov@2620:0:1000:1b01:21f:f3ff:fed0:dd49)
  816. # [18:54] * Joins: tantek (~tantek@70-36-139-7.dsl.dynamic.sonic.net)
  817. # [18:59] * Quits: taf2 (~taf2@173-13-232-33-WashingtonDC.hfc.comcastbusiness.net) (Ping timeout: 252 seconds)
  818. # [19:03] * Quits: zcorpan (~zcorpan@c-2e99e355.410-6-64736c14.cust.bredbandsbolaget.se) (Quit: zcorpan)
  819. # [19:05] * Joins: KevinMarks (~KevinMark@157.22.22.46)
  820. # [19:10] <MikeSmith> boblet: some Japanese sites have a pattern of doing a number of strange/bizzare things as far as markup goes
  821. # [19:11] <boblet> don’t we know it. ok, nn fo reals this time
  822. # [19:11] * Quits: boblet (~boblet@p1072-ipbf36osakakita.osaka.ocn.ne.jp) (Quit: boblet)
  823. # [19:12] <JonathanNeal> I've started ending my emails with "VIVA LA CINCO!"
  824. # [19:12] <JonathanNeal> In support of HTML5.
  825. # [19:12] * Quits: tametick (~chatzilla@chello084114134061.3.15.vie.surfer.at) (Remote host closed the connection)
  826. # [19:13] <gsnedders> hsivonen: http://www.p01.org/releases/128b_mandelbrot/115b.htm is b0rked with html5 parser
  827. # [19:13] * Quits: ChrisLTD|Work (~blahness@152.2.194.196) (Quit: ChrisLTD|Work)
  828. # [19:14] <gsnedders> hsivonen: nvm, wfm in 3.7, just not 3.6
  829. # [19:18] * Quits: mpt (~mpt@canonical/mpt) (Ping timeout: 265 seconds)
  830. # [19:22] * Joins: salavas (salavas@h4n1fls31o279.telia.com)
  831. # [19:22] * Joins: jwalden (~waldo@nat/mozilla/x-ehoatvxmbrtdxaee)
  832. # [19:26] * Joins: othermaciej (~mjs@nat/apple/x-vmqinjneernkugfx)
  833. # [19:29] * Quits: mat_t (~mattomasz@91.189.88.12) (Quit: This computer has gone to sleep)
  834. # [19:30] * Joins: mat_t (~mattomasz@91.189.88.12)
  835. # [19:30] * Joins: maikmerten (~maikmerte@port-92-201-168-18.dynamic.qsc.de)
  836. # [19:31] * Joins: svl (~me@ip565744a7.direct-adsl.nl)
  837. # [19:34] * Joins: gratz|home (~gratz@cpc3-brig15-2-0-cust237.3-3.cable.virginmedia.com)
  838. # [19:36] * Quits: gavin_ (~gavin@firefox/developer/gavin) (Ping timeout: 240 seconds)
  839. # [19:38] <JonathanNeal> Today is battle of the HTML5 day, woohoo.
  840. # [19:40] <othermaciej> eh?
  841. # [19:40] * Quits: mat_t (~mattomasz@91.189.88.12) (Quit: This computer has gone to sleep)
  842. # [19:41] * Joins: gavin_ (~gavin@firefox/developer/gavin)
  843. # [19:41] <JonathanNeal> We've been running out HTML5 website through a gauntlet of tests.
  844. # [19:42] <JonathanNeal> Screenreaders, performance checkers.
  845. # [19:42] <JonathanNeal> Testing to see how much positive or negative the HTML5 impact has been.
  846. # [19:43] <JonathanNeal> HTMl5 killed 0 accessibility tests on MAC and PC, including using the EYES and JAWS readers.
  847. # [19:44] <JonathanNeal> In fact, HTML5 in combination with properly layed-out markup improved accessibility, and use of <nav> tag offered improved accessibility in the JAWS reader.
  848. # [19:44] * aroben is now known as aroben|lunch
  849. # [19:45] <TabAtkins> Ooh, JonathanNeal, could you write up your findings?
  850. # [19:45] <JonathanNeal> For IE6,7,8 we tested the shiv used to add in support for HTML5 elements in the DOM and CSS.
  851. # [19:45] <TabAtkins> Especially regarding the results with actual screenreadeers.
  852. # [19:45] <JonathanNeal> TabAtkins, yea and we've been youtub'ing the results.
  853. # [19:45] <TabAtkins> Awesome.
  854. # [19:46] <JonathanNeal> You may wanna wait til we've written up our assessments of the results, right now it's scattered.
  855. # [19:46] <TabAtkins> kk
  856. # [19:46] <JonathanNeal> We found the HTML5 shiv for IE had an impact of 0.025ms in IE6.
  857. # [19:46] * Joins: Lachy (~Lachlan@london.perfect-privacy.com)
  858. # [19:46] <miketaylr> so awesome
  859. # [19:47] <JonathanNeal> 0.015ms in IE8. We contrast these results with other tests, like document.getElementById, ElementsByTagName.
  860. # [19:47] <JonathanNeal> We're measuring our existing site search results on Google, Bing, Yahoo, etc to see how the content was picked up.
  861. # [19:48] <othermaciej> JonathanNeal: that's interesting data
  862. # [19:49] <Necrathex> what site are we talking about btw?
  863. # [19:50] <JonathanNeal> Well, some tests don't require the site, but otherwise we're looking at our site, liferay.com
  864. # [19:50] <Necrathex> ah
  865. # [19:51] <Necrathex> you actually have ie6-visitors? :)
  866. # [19:51] <JonathanNeal> Which I built exclusively in HTML5 thanks to the help of TabAtkins and many others in here, taking advantage of the new markup as well as the new <video> feature.
  867. # [19:51] <JonathanNeal> We have plenty of IE6 visitors, you'll see Cisco is a client, and they're pretty much all IE6.
  868. # [19:51] <Necrathex> that's really nice :)
  869. # [19:51] <Necrathex> :x
  870. # [19:52] <JonathanNeal> Guess how many complaints we've received about HTML5, from anyone, even on the forums, or support tickets; 0.
  871. # [19:55] * Quits: erikvold (~erikvold@S01060024012860e9.gv.shawcable.net) (Quit: Bye bye)
  872. # [19:57] * Quits: jwalden (~waldo@nat/mozilla/x-ehoatvxmbrtdxaee) (Quit: ChatZilla 0.9.86-rdmsoft [XULRunner 1.9.2/20100122095031])
  873. # [19:58] * Joins: wycats (~yehudakat@enginey-9.border1.sfo002.pnap.net)
  874. # [20:01] * Joins: jwalden (~waldo@nat/mozilla/x-uqqamjfdiaufuhyi)
  875. # [20:01] <AryehGregor> JonathanNeal, I wish I could say that about my attempt to get HTML5 into Wikipedia. Then again, we don't have all this "testing" stuff you've been talking about.
  876. # [20:08] <JonathanNeal> Wikipedia doesn't have "testing" stuff?
  877. # [20:14] <Philip`> Depends if you consider ordinary users to be testers
  878. # [20:17] <AryehGregor> JonathanNeal, we don't have any formal testing procedure. The procedure is largely 1) people commit stuff to trunk, 2) users of trunk (mostly developers) hopefully complain when things break, then eventually: 3) test.wikipedia.org is synced to trunk and sysadmins wait a little while to see if there are reports from voluntary testers, 4) all Wikimedia projects are synced to trunk, 5) sysadmins hang around in #wikimedia-tech for a while fieldi
  879. # [20:17] <AryehGregor> ng critical bug reports that weren't caught at an earlier stage.
  880. # [20:22] * Quits: jwalden (~waldo@nat/mozilla/x-uqqamjfdiaufuhyi) (Quit: ChatZilla 0.9.86-rdmsoft [XULRunner 1.9.2/20100122095031])
  881. # [20:27] * Joins: jwalden (~waldo@nat/mozilla/x-gbrqwfvtwcdyhnqz)
  882. # [20:34] * Quits: jwalden (~waldo@nat/mozilla/x-gbrqwfvtwcdyhnqz) (Ping timeout: 256 seconds)
  883. # [20:36] * Joins: grimboy (~grimboy@bcm-131-111-216-247.girton.cam.ac.uk)
  884. # [20:36] * Joins: nessy (~Adium@124-168-170-167.dyn.iinet.net.au)
  885. # [20:38] * Joins: jwalden (~waldo@nat/mozilla/x-nkawkcksqtanzkce)
  886. # [20:38] <JonathanNeal> Well, AryehGregor, I will be sure to show my results to you and capture any other questions you have.
  887. # [20:38] <JonathanNeal> I hope we can help each other, in the spirit of opensource.
  888. # [20:39] <gsnedders> JonathanNeal: I am here again
  889. # [20:39] * aroben|lunch is now known as aroben
  890. # [20:40] <JonathanNeal> Hey gsnedders, cool, did you have a question for me? I can't recall, it's a been a wild night and morning.
  891. # [20:40] * Quits: othermaciej (~mjs@nat/apple/x-vmqinjneernkugfx) (Quit: othermaciej)
  892. # [20:40] <gsnedders> JonathanNeal: You tried to get me :P
  893. # [20:40] <Hixie> well, the first evidence of the domintro boxes having a negative effect just surfaced... it looks like microsoft read those instead of the normative text.
  894. # [20:40] <JonathanNeal> gsnedders, cool, do you also know what I was asking you for? :D
  895. # [20:41] <JonathanNeal> I bet it had SOMETHING to do with html5.
  896. # [20:41] <gsnedders> JonathanNeal: No
  897. # [20:41] <JonathanNeal> heheh.
  898. # [20:41] <JonathanNeal> Well, hello friend!
  899. # [20:42] <JonathanNeal> We're doing lots of accessibility tests with HTML5.
  900. # [20:43] * Joins: othermaciej (~mjs@2620:0:1b00:1191:21f:f3ff:fe4e:bf33)
  901. # [20:43] <JonathanNeal> Like, for instance, in Chrome you can not tab to a <video> element, but in Firefox you can, and then use spacebar to play and pause the video.
  902. # [20:43] <AryehGregor> Hixie, did they disagree with the normative text?
  903. # [20:43] <jwalden> JonathanNeal: that's a quality-of-implementation thing, right?
  904. # [20:43] <AryehGregor> JonathanNeal, neat. Gecko seems to have better <video> support overall than WebKit right now.
  905. # [20:44] <Hixie> AryehGregor: no they just said they were confused and quoted the domintro text
  906. # [20:44] <Hixie> AryehGregor: see public-canvas-api
  907. # [20:44] <Hixie> (there's a bug in the spec)
  908. # [20:46] <Hixie> hsivonen: i believe the &#13; thing was done in response to your feedback...
  909. # [20:48] <hsivonen> Hixie: oops...
  910. # [20:51] <JonathanNeal> I've filed a ticket about the <video> keyboard accessibility issue @ http://code.google.com/p/chromium/issues/detail?id=36472
  911. # [20:52] <JonathanNeal> Might as well push them all to improve. :D
  912. # [20:53] <AryehGregor> Does Safari have the same issue? If so, you should probably file with WebKit instead.
  913. # [20:53] <JonathanNeal> Well, their implementation of <video> differs so greatly.
  914. # [20:53] <JonathanNeal> I think Safari swallows <video> and turns it into a quicktime control.
  915. # [20:54] <othermaciej> "quicktime control"?
  916. # [20:54] <othermaciej> we do use QuickTime as the media engine but not stock high-level APIs like NSMovie
  917. # [20:55] <AryehGregor> How much of the <video> implementation is shared by Safari and Chrome?
  918. # [20:57] <Philip`> The spec has annoyingly many conformance requirements
  919. # [20:57] <AryehGregor> We should remove all the conformance requirements, then.
  920. # [20:57] <AryehGregor> Would that solve the problem?
  921. # [20:57] <JonathanNeal> othermaciej, yes, the video seems to share the same controls as a quicktime video, though they do not add height to the video as quicktime controls usually do.
  922. # [20:58] * Philip` has now reached 306 testable statements for <canvas>
  923. # [20:58] <JonathanNeal> But that means they're overlapping the bottom portion of the video, since they do not hide themselves.
  924. # [20:58] <AryehGregor> That seems low.
  925. # [20:59] * AryehGregor wonders what all the 105-year-old Internet users do when they get age forms that only go back to 1910 or so
  926. # [20:59] <Philip`> It looks like it's probably more than the combined total of http://www.w3.org/MarkUp/Test/HTML401/current/assertions/assertions_toc.html
  927. # [21:00] <AryehGregor> That says more about HTML 4 than it does about HTML5, though.
  928. # [21:00] <Philip`> AryehGregor: Maybe they do what all the 15-year-old Internet users do, and lie about their age
  929. # [21:01] <AryehGregor> I assume so.
  930. # [21:03] <AryehGregor> Anyway, as for video, it seems to me like the spec is sort of painted into a corner. Authors have to know how much space the video will take up regardless of whether it has built-in controls, but the size of controls would be implementation-dependent. So it's basically forced to leave no space for UA-provided controls.
  931. # [21:03] <AryehGregor> UAs handle this pretty elegantly, I guess.
  932. # [21:06] * Quits: gratz|home (~gratz@cpc3-brig15-2-0-cust237.3-3.cable.virginmedia.com) (Quit: Leaving)
  933. # [21:17] <JonathanNeal> othermaciej, I looked into this Safari issue deeper, let me post a test.
  934. # [21:23] <JonathanNeal> http://sandbox.thewikies.com/html5-video-framing/ <-- note the result in Safari.
  935. # [21:25] <JonathanNeal> We lose the bottom 16 pixels of the video while the controls are visible, which do not hide.
  936. # [21:25] * Quits: rauchg (~rauchg@75.16.26.133) (Quit: rauchg)
  937. # [21:26] <Hixie> anyone (othermaciej) have any comments on these updates to the change proposal for longdesc=""? http://wiki.whatwg.org/wiki/Change_Proposal_for_not_including_longdesc%3D""
  938. # [21:26] <eric_carlson> JonathanNeal: the controls are only visible when the video is paused, or when the cursor moves over the element
  939. # [21:27] <Hixie> this shows the diffs: http://wiki.whatwg.org/index.php?title=Change_Proposal_for_not_including_longdesc%3D%22%22&action=historysubmit&diff=4448&oldid=4436
  940. # [21:27] <JonathanNeal> eric_carlson, noted, so it's only for preview.
  941. # [21:27] <JonathanNeal> That's fair, the poster attr doesn't work yet either, so I hope to see it all pushed through eventually.
  942. # [21:27] <eric_carlson> JonathanNeal: the poster attribute should work in WebKit
  943. # [21:28] <AryehGregor> JonathanNeal, same in Chrome, looks like.
  944. # [21:28] <AryehGregor> Ah, no.
  945. # [21:28] <AryehGregor> They fade out if you mouse away.
  946. # [21:28] <AryehGregor> But not if it's paused.
  947. # [21:29] <JonathanNeal> These are notes on framing, hpoe I'm not pissing you guys off -- I note the similarity in Chrome too!
  948. # [21:30] * Quits: eighty4 (~eighty4@h-112-7.A163.corp.bahnhof.se) (Remote host closed the connection)
  949. # [21:34] * Joins: starjive (beos@81-233-16-19-no30.tbcn.telia.com)
  950. # [21:34] <JonathanNeal> It seems unique to the paused state of <video> in Chrome and Safari.
  951. # [21:35] * Quits: maikmerten (~maikmerte@port-92-201-168-18.dynamic.qsc.de) (Remote host closed the connection)
  952. # [21:36] <TabAtkins> Hixie: Sounds good overall.
  953. # [21:37] <Hixie> have i missed any arguments?
  954. # [21:39] <JonathanNeal> Kill that longdesc, Hixie :D
  955. # [21:39] <annevk> Hixie, we recently had the same with <canvas> domintro text
  956. # [21:39] <annevk> Hixie, with us it was about drawImage() exceptions
  957. # [21:40] <Hixie> annevk: the same bug, or the same problem with implementors reading the domintro text?
  958. # [21:40] <Philip`> Maybe it should say "This box is not normative" in every domintro box
  959. # [21:40] <annevk> same problem, have not looked at the bug
  960. # [21:40] <Hixie> Philip`: ooh, that's a good idea.
  961. # [21:41] <Philip`> Seems like people aren't used to the idea that anything that doesn't say "must" is not normative
  962. # [21:43] <othermaciej> Hixie: I'll try to look over lunch
  963. # [21:45] <JonathanNeal> From an accessibility standpoint, Firefox's implementation is the best. The visible controls are unique to the paused state of <video> in Chrome and Safari, whereas Firefox will hide the controls once a mouse has passed into and out of a <video>. If a mouse has not passed into a <video> but keyboard interaction does, the controls remain visible - it's a visible feature triggered by a visible interaction.
  964. # [21:45] <TabAtkins> Hixie: One example of a page with useful @longdesc is cssquirrel.com.
  965. # [21:46] <TabAtkins> Though the last 4 comics' longdescs 404.
  966. # [21:46] <Dashiva> You know, I can understand that FSF wants open codecs, but saying Google owes them a free codec seems taking a bit far...
  967. # [21:47] <AryehGregor> Does the FSF ever *not* take things a bit far?
  968. # [21:47] <AryehGregor> Well, yes. When they take them more than a bit far.
  969. # [21:48] <othermaciej> Hixie: your updates certainly increase the persuasive force of your argumemt
  970. # [21:48] <JonathanNeal> Dashiva, which codec do they want now?
  971. # [21:48] <othermaciej> Hixie: I guess Chaals or I or someone advising us needs to find at least one example of a page with a good use of longdesc
  972. # [21:49] <Dashiva> JonathanNeal: VP8
  973. # [21:49] <Hixie> othermaciej: one in one trillion is not good odds. :-P
  974. # [21:49] <othermaciej> Hixie: I agree - though it is infinitely better than zero in a trillion
  975. # [21:50] <othermaciej> I'm just saying that I don't know if I can stand behind a rationale of "there are some good uses of longdesc" without having at least one to point to
  976. # [21:54] * Quits: gavin_ (~gavin@firefox/developer/gavin) (Ping timeout: 252 seconds)
  977. # [21:56] <TabAtkins> othermaciej: CSSquirrel. Weems uses @longdesc to link to the transcripts for his comics.
  978. # [21:57] <Hixie> he also already uses ARIA, and his latest links are 404
  979. # [21:57] <Hixie> so it's not like (a) he uses it correctly and (b) he needs a transition story
  980. # [21:58] <annevk> this reminds me of a site from Philip TAYLOR with an incorrect alternate text and a longdesc pointing to a 404
  981. # [21:58] <annevk> was a homepage of something
  982. # [21:58] * Joins: gavin_ (~gavin@firefox/developer/gavin)
  983. # [21:59] <tantek> longdesc arguments are looooooooooooooooooooooooooooooooooooooooooooooong
  984. # [21:59] <othermaciej> I wonder why he does not use aria-describedby for the transcripts, seems pretty harsh to force a page load to get it
  985. # [22:00] <Hixie> yeah longdesc="" isn't even a good solution in that case, compared to just putting the text inline
  986. # [22:01] <tantek> or an inline visible link to an external transcript
  987. # [22:01] <tantek> when or why would you want curbcuts to ever be invisible?
  988. # [22:01] <Hixie> yeah
  989. # [22:01] <othermaciej> inline visible test or visible link associated with aria-describedby seems to be the best of all possible worlds afaict
  990. # [22:02] <othermaciej> or if you must, you can hide the description in visual media
  991. # [22:02] <tantek> better to err on the side of visibility (somebody else might find use for the information) than err on the side of invisibility (some developer might be annoyed at having to make it visible)
  992. # [22:02] <tantek> also - note that in that case user need should win over author/developer need - per the design principles
  993. # [22:02] <othermaciej> aria-describedby defaults to visibility, which is nice
  994. # [22:04] <Hixie> i added something to the Risks and Negative Effect sections
  995. # [22:04] <tantek> are there any conforming and recommended invisible content features in HTML5 currently?
  996. # [22:05] <othermaciej> does alt count?
  997. # [22:05] <tantek> no - because alt is visible when you load a browser with images turned off (a common preference in browsers)
  998. # [22:05] <othermaciej> do the various <meta name> and <link rel> types without default visible effect count?
  999. # [22:05] <tantek> and some browsers show alt while images are loading (e.g. over slow connections)
  1000. # [22:06] <Hixie> ok i'll post this to the list later if nobody has any more suggestions in the meantime
  1001. # [22:06] <tantek> which just demonstrates another curbcut scenario - what was intended for accessibility helps those with slow networks
  1002. # [22:06] <Hixie> http://wiki.whatwg.org/wiki/Change_Proposal_for_not_including_longdesc%3D""
  1003. # [22:06] <tantek> othermaciej - yes, meta name needs to be dropped nearly universally
  1004. # [22:07] <Hixie> diffs at http://wiki.whatwg.org/index.php?title=Change_Proposal_for_not_including_longdesc%3D%22%22&action=historysubmit&diff=&oldid=4436
  1005. # [22:07] <tantek> link rel is typically programmatic rather than content oriented - like script
  1006. # [22:07] <Dashiva> "Not including" is probably going to be misunderstood to "not supporting"
  1007. # [22:08] <tantek> you might argue that the "title" attribute on link is invisible content, but it is only advisory, and in the context of alternate style sheets - for user agents that support them (e.g. Mozilla back in the day), those titles are visible when choosing an alternative
  1008. # [22:09] <Hixie> Dashiva added comment to hte summary for you
  1009. # [22:10] * tantek fixes the link to the wiki placed in IRC to be more regex-auto-linking proof.
  1010. # [22:11] <tantek> so, once again, any conforming invisible content in HTML5 other than meta name (which IMHO should be dropped) ?
  1011. # [22:12] <annevk> <link>?
  1012. # [22:13] <annevk> <rp>, <input type=hidden>
  1013. # [22:14] <Hixie> hidden=""
  1014. # [22:14] <tantek> annevk - see above about <link>
  1015. # [22:15] <tantek> (in short - it's more programmatic like script than any kind of content)
  1016. # [22:15] <Hixie> fallback in <object>, <canvas>, <video>, <iframe>, <audio>, etc
  1017. # [22:15] <annevk> hmm, <link rel=prev> and all are not
  1018. # [22:15] <tantek> fallbacks are not invisible because they show up when the primary content fails
  1019. # [22:16] <annevk> only a few in http://annevankesteren.nl/2010/01/optimizing-html are programmatic
  1020. # [22:16] * tantek would like something akin to <rp> for general use
  1021. # [22:16] <annevk> but I'm not sure they're very useful either, to be honest
  1022. # [22:16] <annevk> I included them because at the time using <link> like that made sense
  1023. # [22:16] <annevk> it was the HTML4-way
  1024. # [22:17] <annevk> markup gods would give you a compliment and you'd feel good about yourself; nowadays it feels more like bloat :)
  1025. # [22:17] * Quits: danbri (~danbri@unaffiliated/danbri) (Remote host closed the connection)
  1026. # [22:18] <Hixie> the markup gods are dead? :-)
  1027. # [22:18] * Quits: ROBOd (~robod@89.122.216.38) (Quit: http://www.robodesign.ro)
  1028. # [22:20] <tantek> annevk - there's good markup for practical reasons, and there's good markup for dogmatic reasons. some disagree about which category any particular technique falls into.
  1029. # [22:21] <tantek> e.g. I've found plenty of practical use in making biglot documents, especially recently.
  1030. # [22:21] <tantek> there's plenty of XML based tools that are useful (e.g. in PHP, DOMDocument etc.)
  1031. # [22:22] <tantek> so until all these backend languages have built-in support for html5lib - biglot documents are useful (and thus the space slash for empty elements like <img /> etc.)
  1032. # [22:22] <Hixie> oh bi-glot, i was reading big-lot
  1033. # [22:23] * Philip` finishes updating his canvas test assertion list, and ends up with 311 (excluding the focus management section)
  1034. # [22:24] <tantek> e.g. the software running on my current site to post to Twitter etc. uses an hAtom biglot store.
  1035. # [22:24] * Joins: danbri (~danbri@unaffiliated/danbri)
  1036. # [22:25] * Philip` doesn't think he's ever seen any tool in which space-slash is needed
  1037. # [22:25] <Philip`> (instead of no-space slash)
  1038. # [22:26] <annevk> Philip`, you should create a patch for the source code of html5 so you don't have to do it again everytime
  1039. # [22:26] <annevk> but I guess hixie would have to maintain it then
  1040. # [22:26] <tantek> Philip' - I believe the "lore" is that some browsers need the space before the slash in order to treat those elements properly
  1041. # [22:27] * tantek does not have specific tests for this though - it may just be out of date lore.
  1042. # [22:30] * tantek prefers to use biglot HTML5+hAtom for storage of small numbers of things rather than pay the DBA-tax (e.g. MySQL).
  1043. # [22:30] * Quits: sbublava (~stephan@77.118.175.222.wireless.dyn.drei.com) (Quit: sbublava)
  1044. # [22:30] <Philip`> annevk: I don't have to redo the whole thing, I just have to add/remove/update whatever's changed since the last version of the spec
  1045. # [22:31] <Philip`> so it's no harder than if the markers were inline in the spec
  1046. # [22:31] <Philip`> The main problem is the last version of the spec was 1.5 years old, and it's changed a bit since then
  1047. # [22:31] <tantek> Hixie, re: http://wiki.whatwg.org/wiki/Change_Proposal_for_not_including_longdesc - where is the section on how longdesc harms accessibility?
  1048. # [22:31] <annevk> mostly because of you :p
  1049. # [22:31] <tantek> I think that needs to be made explicit
  1050. # [22:32] <Philip`> tantek: By "lore", you mean dogma? :-)
  1051. # [22:33] <tantek> Philip` usually it's a transition from experience to lore to dogma.
  1052. # [22:33] <Philip`> No modern browser could require the space because it'd break on web content
  1053. # [22:33] <tantek> by the time it makes it to dogma, because the lore became detached from experience, it is no longer possible to retest the original hypotheses.
  1054. # [22:33] <tantek> Philip` - which web content would it break on?
  1055. # [22:33] <Philip`> and (if I remember correctly) even Netscape 1 worked fine with no space
  1056. # [22:34] <tantek> Philip` - do you have test cases of all HTML empty elements with no-space slash? Including tests to ensure than any attributes before the no-space slash are handled correctly?
  1057. # [22:36] <Philip`> tantek: http://google.com/codesearch?q=%3Cimg%5C+src%3D%22%5B%5E%22%5D%2B%22%2F%3E
  1058. # [22:38] * Quits: pmuellr (~pmuellr@nat/ibm/x-znreoenncetxcdao) (Quit: pmuellr)
  1059. # [22:40] * Joins: Asaph (rob@unaffiliated/robdgreat)
  1060. # [22:42] <tantek> http://google.com/codesearch?hl=en&lr=&q=%3Clink%5C+rel%3D%22%5B%5E%22%5D+href%3D%22%5B%5E%22%5D%2B%22%2F%3E&sbtn=Search
  1061. # [22:42] * Quits: Rik|work (~Rik|work@fw01d.skyrock.net) (Ping timeout: 252 seconds)
  1062. # [22:43] <tantek> http://google.com/codesearch?hl=en&lr=&q=%3Cmeta%5C+name%3D%22%5B%5E%22%5D+contents%3D%22%5B%5E%22%5D%2B%22%2F%3E&sbtn=Search
  1063. # [22:45] <tantek> and of course: http://google.com/codesearch?q=%3Cbr%2F%3E
  1064. # [22:45] * Quits: annodomini (~lambda@wikipedia/lambda) (Quit: annodomini)
  1065. # [22:46] <Hixie> tantek: second bullet of rationale and third of the positive effects
  1066. # [22:46] <tantek> I think it could be more strongly worded
  1067. # [22:46] <tantek> evidence demonstrates that longdesc has harmed accessibility
  1068. # [22:47] <tantek> net-harmed
  1069. # [22:47] <Hixie> tantek: uri?
  1070. # [22:47] <tantek> those same studies
  1071. # [22:47] <Hixie> ok why does .domintro:before { display: block; margin: -1em -0.5em 0 auto; width: auto; content: '...'; border: solid thin; background: white; padding: 0 0.25em; } result in a box that fills the width of the ocntaining block???
  1072. # [22:47] <tantek> that show all the garbage values
  1073. # [22:47] <Hixie> tantek: they don't demonstrate harm to users
  1074. # [22:47] <Hixie> tantek: just that the data is bogus
  1075. # [22:47] <Hixie> tantek: it is argued that UAs are ignoring longdesc="" values that are bogus
  1076. # [22:47] <Hixie> or that they could
  1077. # [22:47] <Hixie> or some such
  1078. # [22:48] <tantek> how can they tell that the values are bogus?
  1079. # [22:48] <Hixie> beats me
  1080. # [22:48] <Hixie> but i'd rather not explicitly say there is harm caused unless i can prove it
  1081. # [22:48] <Hixie> since otherwise i'm just providing a straw man to attack
  1082. # [22:53] * Quits: tantek (~tantek@70-36-139-7.dsl.dynamic.sonic.net) (Ping timeout: 276 seconds)
  1083. # [22:53] * Quits: svl (~me@ip565744a7.direct-adsl.nl) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
  1084. # [22:54] * Quits: franksalim (~frank@adsl-75-61-86-190.dsl.pltn13.sbcglobal.net) (Remote host closed the connection)
  1085. # [22:55] <Hixie> oh duh
  1086. # [22:55] <Hixie> width:auto overrides auto margins
  1087. # [22:55] <Hixie> !#$%%
  1088. # [22:56] <Hixie> do we have width:intrinsic yet?
  1089. # [22:56] * Hixie switches to display:table instead
  1090. # [22:56] * Quits: paul_irish (~paul_iris@12.33.239.250) (Ping timeout: 264 seconds)
  1091. # [22:56] <TabAtkins> I think the intrinsic width values are vendor-prefixed right now?
  1092. # [22:57] <Hixie> slowest. moving. wg. ever.
  1093. # [22:57] <TabAtkins> Just use display:table, yeah. That's the current hacky form of width:min-intrinsic.
  1094. # [22:57] <TabAtkins> For real.
  1095. # [22:58] <Hixie> ok good, that works
  1096. # [22:58] <Hixie> .domintro:before { display: block; margin: -1em -0.5em 0 auto; width: auto; content: 'This box is non-normative. Implementation requirements are given below this box.'; col\
  1097. # [22:58] <Hixie> or: red; border: solid thin; background: white; padding: 0 0.25em; }
  1098. # [22:58] <TabAtkins> We *just* got our first css3 module to PR. >_<
  1099. # [22:58] <Hixie> er
  1100. # [22:58] <Hixie> mispaste
  1101. # [22:58] <Hixie> http://www.whatwg.org/specs/web-apps/current-work/#error-codes
  1102. # [22:58] <Hixie> selectors?
  1103. # [22:58] <TabAtkins> Yeah.
  1104. # [22:58] <Hixie> that's not css3 :-P
  1105. # [22:58] <Hixie> but woohoo!
  1106. # [22:58] <Hixie> selectors in pr!
  1107. # [22:58] <TabAtkins> Close enough!
  1108. # [22:58] <Hixie> man i remember writing parts of the test suite for that 8 years ago!
  1109. # [22:59] <Hixie> maybe more!
  1110. # [22:59] * TabAtkins has so much shit planned for this new gig.
  1111. # [22:59] <Hixie> ok do these new domintro boxes look ok?
  1112. # [23:00] <TabAtkins> I'd give it a 2px border.
  1113. # [23:00] <Hixie> are the colours ok?
  1114. # [23:01] <TabAtkins> Yah.
  1115. # [23:01] * Joins: roc (~roc@nat/mozilla/x-iutiqedpfyuuzbxj)
  1116. # [23:02] <TabAtkins> Oh, hmm. Now I see the box. The box background is far too light. I have to tilt my monitor and get it to start distorting colors before I can tell the extent of the box.
  1117. # [23:02] <TabAtkins> For .domintro, not .domintro::before
  1118. # [23:04] <Hixie> reload in a few minutes, let me know what you think. back in a bit, cycling to work.
  1119. # [23:11] * Quits: Maurice (copyman@5ED548D4.cable.ziggo.nl)
  1120. # [23:11] * Joins: sicking (~chatzilla@nat/mozilla/x-vkrsamrygafqibqe)
  1121. # [23:11] * Quits: miketaylr (~miketaylr@38.117.156.163) (Remote host closed the connection)
  1122. # [23:12] * Joins: dbaron (~dbaron@nat/mozilla/x-eoznaplxkhenoudv)
  1123. # [23:12] <TabAtkins> Hixie: Yes, much better.
  1124. # [23:16] * Joins: beilabs (~beilabs@ppp121-44-78-10.lns20.syd6.internode.on.net)
  1125. # [23:21] * Quits: BlurstOfTimes (~blurstoft@168.203.117.66) (Quit: Leaving...)
  1126. # [23:30] * Joins: Rik` (~Rik`@pha75-2-81-57-187-57.fbx.proxad.net)
  1127. # [23:31] * Quits: Rik` (~Rik`@pha75-2-81-57-187-57.fbx.proxad.net) (Remote host closed the connection)
  1128. # [23:32] * Joins: Rik` (~Rik`@pha75-2-81-57-187-57.fbx.proxad.net)
  1129. # [23:33] * Joins: tantek (~tantek@70-36-139-7.dsl.dynamic.sonic.net)
  1130. # [23:40] * Quits: annevk (~annevk@5355737B.cable.casema.nl) (Ping timeout: 252 seconds)
  1131. # [23:47] * Quits: eric_carlson (~ericc@2620:0:1b00:1191:223:32ff:feb1:5d30) (Quit: eric_carlson)
  1132. # [23:50] * Joins: xtothey (~ryanblair@ool-457b0e1a.dyn.optonline.net)
  1133. # [23:50] * Parts: xtothey (~ryanblair@ool-457b0e1a.dyn.optonline.net)
  1134. # [23:52] <Dashiva> "You could interest users with HD videos in free formats [...] this would eventually lead to users not bothering to install Flash on their computers"
  1135. # [23:52] <Dashiva> Apparently FSF never heard of flash games
  1136. # [23:58] * Quits: tantek (~tantek@70-36-139-7.dsl.dynamic.sonic.net) (Quit: tantek)
  1137. # Session Close: Tue Feb 23 00:00:00 2010

The end :)