/irc-logs / freenode / #whatwg / 2010-06-30 / end

Options:

  1. # Session Start: Wed Jun 30 00:00:00 2010
  2. # Session Ident: #whatwg
  3. # [00:03] * Quits: mdelaney (~mdelaney@171.66.53.164) (Quit: mdelaney)
  4. # [00:04] * Quits: gratz|home (~gratz@cpc3-brig15-2-0-cust237.3-3.cable.virginmedia.com) (Quit: Leaving)
  5. # [00:07] <jgraham> I suggested JSON
  6. # [00:07] * Joins: mmn (~mmn@129-97-225-230.uwaterloo.ca)
  7. # [00:08] <jgraham> Since XML is massive amounts of overkill and json is only small amounts of overkill
  8. # [00:09] <jgraham> Oh I just thought of another issue that wasn't discussed
  9. # [00:09] * Joins: nimbupani (~nimbupani@c-24-22-131-46.hsd1.wa.comcast.net)
  10. # [00:09] <jgraham> We need a way to deal with multiple tests per file
  11. # [00:09] <jgraham> Hmm
  12. # [00:10] <jgraham> Oh well, bedtime
  13. # [00:11] * Quits: boaz (~boaz@64.119.159.231) (Read error: Connection reset by peer)
  14. # [00:11] * Quits: f1lt3r (~f1lt3r@64.119.159.231) (Read error: Connection reset by peer)
  15. # [00:15] * Joins: roc (~roc@203-97-204-82.dsl.clear.net.nz)
  16. # [00:19] * Joins: justicefries (~gerred@c-98-245-71-126.hsd1.co.comcast.net)
  17. # [00:19] * Quits: svl (~me@ip565744a7.direct-adsl.nl) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
  18. # [00:20] * Joins: MikeSmith (~MikeSmith@EM114-48-47-240.pool.e-mobile.ne.jp)
  19. # [00:21] <Hixie> zcorpan_: sweet
  20. # [00:21] <Hixie> i haven't even half finished the spec yet and we're already got implementations
  21. # [00:22] <TabAtkins> Haha, I just made several people look through multiple rulebooks before they realized I was making a rule-34 joke.
  22. # [00:23] * Joins: m_W (~mwilcox56@130.156.111.2)
  23. # [00:23] <TabAtkins> http://forums.xkcd.com/viewtopic.php?p=2215558#p2215558
  24. # [00:24] * TabAtkins is a dork.
  25. # [00:27] <Philip`> zcorpan_: http://urd.let.rug.nl/tiedeman/OPUS/OpenSubtitles.php ?
  26. # [00:28] <zcorpan_> Philip`: thanks
  27. # [00:29] <Philip`> zcorpan_: It's not clear how many are SRT but it sounds like some are
  28. # [00:29] * Quits: nattokirai (~nattokira@ac242062.dynamic.ppp.asahi-net.or.jp) (Quit: nattokirai)
  29. # [00:30] <MikeSmith> TabAtkins: nice
  30. # [00:30] <MikeSmith> "I don't see it. What edition?"
  31. # [00:30] <TabAtkins> I love being a D&D nerd. The thought of D&D defining that is actually plausible.
  32. # [00:31] <MikeSmith> D&D defining anything is plausible
  33. # [00:31] <Philip`> zcorpan_: ...unless they've only got converted-to-XML versions in there
  34. # [00:31] <gsnedders> TabAtkins: Rule 34?
  35. # [00:31] <Philip`> zcorpan_: but I don't fancy downloading 1.6GB just to check
  36. # [00:32] <TabAtkins> gsnedders: http://lmgtfy.com/?q=rule+34
  37. # [00:32] <gsnedders> Oh.
  38. # [00:32] <AryehGregor> TabAtkins, they would only define that in the BoVD or something.
  39. # [00:32] <AryehGregor> No way would that be in the DMG.
  40. # [00:32] <TabAtkins> BoEF, more than likely, but that's not an actual wotc book.
  41. # [00:33] <AryehGregor> I know of BoVD and BoED, what's BoEF?
  42. # [00:33] <AryehGregor> I probably don't want to know about it.
  43. # [00:33] <TabAtkins> Erotic Fantasy.
  44. # [00:33] <AryehGregor> Yeah.
  45. # [00:34] <MikeSmith> reminds me of the way to give annoying people driving directions: Give them such that they'll head off in a completely wrong direction, in the boondocks, and when you are done explaining most of it, say, "...once you get around there, you might feel like you've gone too far in that direction, but don't worry, just keep going a little further and you'll find it"
  46. # [00:34] * Quits: taf2 (~taf2@173-13-232-33-WashingtonDC.hfc.comcastbusiness.net) (Quit: taf2)
  47. # [00:35] <TabAtkins> I actually had to always append that to directions to my old house, because otherwise I'd get calls from people driving to my place wondering where they missed their turn.
  48. # [00:36] <AryehGregor> Why?
  49. # [00:36] <AryehGregor> Also, I guess this was in the pre-Google Maps/GPS era.
  50. # [00:36] <TabAtkins> No, it was just a few months ago.
  51. # [00:36] <AryehGregor> A Luddite, then?
  52. # [00:36] <AryehGregor> Or do people not use those things as much as I'd think?
  53. # [00:37] <AryehGregor> (I don't drive, of course, since I live in Manhattan.)
  54. # [00:37] <TabAtkins> Houston highways are almost completely developed, so you never go any distance without seeing stores or strip malls or whatnot. My house was just far enough out from the city that there was a stretch of forest and a creek before the strip malls started again.
  55. # [00:37] * Quits: m_W (~mwilcox56@130.156.111.2) (Ping timeout: 265 seconds)
  56. # [00:37] <TabAtkins> It confused people, because usually seeing that means you're on your way to Dallas or Austin.
  57. # [00:39] <AryehGregor> I see.
  58. # [00:42] <MikeSmith> http://www.w3.org/TR/1998/NOTE-xml-names-0119 "error on line 2 at column 30: Encoding error"
  59. # [00:42] * MikeSmith resorts to lynx
  60. # [00:43] <MikeSmith> let's hope the lynx developers add an XML parser
  61. # [00:43] <MikeSmith> that'd be fun
  62. # [00:45] <TabAtkins> lynx developers just need to add <video> support via one of the video-to-ascii converters.
  63. # [00:46] <TabAtkins> Then I will finally be able to fulfill my dream: browsing youtube in lynx.
  64. # [00:49] <TabAtkins> re: xml error, hoisted by their own doctype, it appears.
  65. # [00:51] * Quits: deepthawtz (~deepthawt@c-24-130-129-16.hsd1.ca.comcast.net) (Ping timeout: 240 seconds)
  66. # [00:53] <MikeSmith> Murata-san is 1998 - http://lists.xml.org/archives/xml-dev/199808/msg00164.html
  67. # [00:54] <MikeSmith> [[
  68. # [00:54] <MikeSmith> As a member of the WG, I have been involved. I have agreed on colonization,
  69. # [00:54] <MikeSmith> and have always believed that colonization provides a good basis for
  70. # [00:54] <MikeSmith> the namespace extension. Now that we have local scoping and declaration by
  71. # [00:54] <MikeSmith> attributes, I start to wonder.
  72. # [00:54] <MikeSmith> Since the same prefix can be bound to
  73. # [00:54] <MikeSmith> different namespaces, it is no longer possible to construct an equivalent
  74. # [00:54] <MikeSmith> XML 1.0 DTD from a collection of namespace-schema pairs. Then, what is
  75. # [00:54] <MikeSmith> the point of using prefixes?
  76. # [00:54] <MikeSmith> It would have
  77. # [00:54] <MikeSmith> been a lot simpler if we had introduced a reserved attribute for specifying
  78. # [00:54] <MikeSmith> the namespace of the element.
  79. # [00:54] <MikeSmith> ]]
  80. # [00:54] <Hixie> man that would have been hella verbose
  81. # [00:55] <TabAtkins> <svg namespace="foobar">?
  82. # [00:55] <MikeSmith> yeah, sure
  83. # [00:55] <MikeSmith> more <svg xmlns="foobar> I guess
  84. # [00:56] <MikeSmith> oops
  85. # [00:56] <Hixie> if it was scoping that might work for svg, html, mathml, etc; wouldn't be very pretty for rdf
  86. # [00:56] * Quits: oal (~oal@5.79-160-122.customer.lyse.net) (Remote host closed the connection)
  87. # [00:57] <zcorpan_> Philip`: seems it was xml with sentence-for-sentence translations
  88. # [00:57] * Joins: deepthawtz (~deepthawt@c-24-130-129-16.hsd1.ca.comcast.net)
  89. # [00:57] <TabAtkins> No, rdf would have sucked with that.
  90. # [00:57] <TabAtkins> But it feels like it would have been saner for normal elements.
  91. # [00:58] <MikeSmith> I just point it out as a reminder that there was nothing close to real consensus in the WG at that time
  92. # [00:58] <MikeSmith> no consensus that prefix mechanism was the right way
  93. # [00:59] <MikeSmith> just as there was also no consensus then about draconian error handling being the right way
  94. # [00:59] <Hixie> just as there's no consensus in the htmlwg that html5 is the right way :-)
  95. # [00:59] <Hixie> consensus isn't a good language design mechanism
  96. # [01:01] <MikeSmith> well it's especially not a good design mechanism when claims are made that it exists for a particular issue when it really does not
  97. # [01:01] <MikeSmith> decision about draconian error handling was made by simple majority vote
  98. # [01:01] <MikeSmith> which is not consensus anyway
  99. # [01:04] * Quits: BlurstOfTimes (~blurstoft@168.203.117.112) (Remote host closed the connection)
  100. # [01:08] * Joins: titacgs (~titacgs@190.2.33.49)
  101. # [01:08] <Philip`> zcorpan_: Maybe those people or the people they got the original data from would be willing to share the original data if asked
  102. # [01:08] * Philip` was unable to easily find easily-downloadable subtitle collections
  103. # [01:09] <Philip`> (which I guess is because the people who collect the subtitles want to show loads of adverts to visitors, and don't want other sites copying all the data they've collected from volunteers)
  104. # [01:11] <zcorpan_> it says source: http://www.opensubtitles.org
  105. # [01:18] <zcorpan_> Hixie: the first random srt i download has <i> wrapping multiple lines
  106. # [01:18] <zcorpan_> (well, the second random. the first didn't have any markup)
  107. # [01:19] <zcorpan_> http://www.opensubtitles.org/en/download/sub/3695049
  108. # [01:19] <zcorpan_> i have no idea which encoding that one is using
  109. # [01:21] <Hixie> zcorpan_: ah, excellent, good to know, thanks
  110. # [01:26] <zcorpan_> it seems existing srts use different legacy encodings and don't declare it :(
  111. # [01:27] <variable> Has there been any discussion on client side includes for HTML files?
  112. # [01:27] <roc> yes
  113. # [01:27] <roc> see if <iframe seamless> is what you want
  114. # [01:30] * Quits: jlebar (~jlebar@63.245.220.220) (Read error: Operation timed out)
  115. # [01:30] <variable> the spec is the only document that has more links to itself than wikipedia ;)
  116. # [01:32] <zcorpan_> i wonder what to do about the encoding issue
  117. # [01:33] <variable> roc, as I read the spec "seamless" means that <html>___stuff___</html> is the same as <html><iframe srcdoc="____stuff____" seamless></html> - am I correct ?
  118. # [01:33] <zcorpan_> hopefully people will reencode their legacy subtitles to utf-8 for web use
  119. # [01:33] <variable> (or src="document" where document has ___stuff___ in it)
  120. # [01:33] <AryehGregor> variable, no, it's radically different in lots of ways.
  121. # [01:33] <AryehGregor> However, it should be similar enough for most purposes.
  122. # [01:34] <roc> what Aryeh said
  123. # [01:34] <variable> AryehGregor, can you explain? I'm not /that/ knolegeable.
  124. # [01:34] <AryehGregor> Well, it's an iframe.
  125. # [01:34] <variable> *not that familier with how it works
  126. # [01:34] <AryehGregor> It integrates better than a regular iframe, but still an iframe.
  127. # [01:34] <AryehGregor> So there's a whole separate document inside.
  128. # [01:35] <AryehGregor> But you can make it blend in to the bigger document visually, etc.
  129. # [01:35] <roc> it's a separate document, it's in a rectangle
  130. # [01:35] <variable> AryehGregor, in a seamless iframe is top.location == location ?
  131. # [01:35] <roc> for example you can't expect to put inline content in it and wrap that content at line breaks
  132. # [01:35] <roc> it has its own DOM
  133. # [01:35] <roc> its top.location != location in general
  134. # [01:36] <variable> so what does "When specified, it indicates that the iframe element's browsing context is to be rendered in a manner that makes it appear to be part of the containing document (seamlessly included in the parent document). "
  135. # [01:36] <variable> mean? or can you point me to some "newbie" docs the issue?
  136. # [01:37] <TabAtkins> It means that it should look like the <iframe> tag wasn't there at all.
  137. # [01:38] <TabAtkins> (Replaced by the contents of the contained document.)
  138. # [01:38] <variable> so to the enclosing page there is no iframe but to the iframe content it is on its own
  139. # [01:38] * Quits: jwalden (~waldo@nat/mozilla/x-vcrbqfklzwufieyz) (Quit: ChatZilla 0.9.86-rdmsoft [XULRunner 1.9.2.4/20100622203044])
  140. # [01:39] * variable has to learn how to read the spec better
  141. # [01:39] <TabAtkins> Visually, yes. In all other respects, the <iframe> is still there and acts normally.
  142. # [01:39] * Quits: dglazkov (~dglazkov@nat/google/x-ricdxnltvnshzyhc) (Quit: dglazkov)
  143. # [01:39] <variable> Ah. I see.
  144. # [01:39] <variable> There is no "client side include" but you can get the visual effect. OK
  145. # [01:40] <TabAtkins> Yeah.
  146. # [01:40] <TabAtkins> Actualy client-side includes have to be faked with javascript and xhr.
  147. # [01:40] <TabAtkins> s/Actualy/Actual/
  148. # [01:40] <variable> ok. good to know
  149. # [01:43] * Joins: wakaba_ (~wakaba_@122x221x184x68.ap122.ftth.ucom.ne.jp)
  150. # [01:43] * zcorpan_ finds an srt with Traducerea ∫i adaptarea: <font color=#ff99cc>Kprice</font>
  151. # [01:43] * zcorpan_ <font color=#ffffff>Subtitr„ri-Noi Team</font>
  152. # [01:44] <TabAtkins> Is that an integral sign?
  153. # [01:44] <variable> TabAtkins, yes
  154. # [01:44] <zcorpan_> wrong encoding
  155. # [01:47] * Joins: hamcore (rhythm@unaffiliated/msmosso)
  156. # [01:48] * Joins: jlebar (~jlebar@nat/mozilla/x-vmssyylvmhxxjyej)
  157. # [01:53] * Quits: zcorpan_ (~zcorpan@c-1799e355.410-6-64736c14.cust.bredbandsbolaget.se) (Quit: zcorpan_)
  158. # [01:56] * Joins: nessy (~Adium@124-170-165-184.dyn.iinet.net.au)
  159. # [02:00] * Parts: hamcore (rhythm@unaffiliated/msmosso)
  160. # [02:11] * Quits: Lachy (~Lachlan@cm-84.215.59.50.getinternet.no) (Quit: Leaving)
  161. # [02:11] * Joins: Lachy (~Lachlan@cm-84.215.59.50.getinternet.no)
  162. # [02:20] * Joins: taf2 (~taf2@pool-98-117-216-229.bltmmd.fios.verizon.net)
  163. # [02:23] * Quits: erlehmann (~erlehmann@dslb-188-102-050-058.pools.arcor-ip.net) (Quit: Ex-Chat)
  164. # [02:24] * Joins: erlehmann (~erlehmann@dslb-188-102-050-058.pools.arcor-ip.net)
  165. # [02:25] * Joins: erlehmann_ (~erlehmann@dslb-188-102-050-058.pools.arcor-ip.net)
  166. # [02:25] * Joins: mdelaney (~mdelaney@2620:0:1b00:1191:d69a:20ff:febf:89a0)
  167. # [02:27] * Quits: erlehmann (~erlehmann@dslb-188-102-050-058.pools.arcor-ip.net) (Client Quit)
  168. # [02:27] * Quits: erlehmann_ (~erlehmann@dslb-188-102-050-058.pools.arcor-ip.net) (Client Quit)
  169. # [02:27] * Quits: deepthawtz (~deepthawt@c-24-130-129-16.hsd1.ca.comcast.net) (Remote host closed the connection)
  170. # [02:28] * Quits: nimbupani (~nimbupani@c-24-22-131-46.hsd1.wa.comcast.net) (Quit: nimbupani)
  171. # [02:28] * Joins: nattokirai (~nattokira@rtr.mozilla.or.jp)
  172. # [02:30] * Joins: boblet (~boblet@p1201-ipbf709osakakita.osaka.ocn.ne.jp)
  173. # [02:31] * Quits: ZombieLoffe (~e@unaffiliated/zombieloffe)
  174. # [02:31] * Joins: abarth (~abarth@c-98-210-108-185.hsd1.ca.comcast.net)
  175. # [02:32] * Joins: yutak_home (~kee@U017209.ppp.dion.ne.jp)
  176. # [02:33] * Quits: mahound_ (~pferreir@unaffiliated/mahound) (Ping timeout: 252 seconds)
  177. # [02:34] * Quits: onar (~onar@2620:0:1b00:16f2:21f:5bff:fe3e:944) (Quit: onar)
  178. # [02:35] * Quits: gavin_ (~gavin@firefox/developer/gavin) (Ping timeout: 248 seconds)
  179. # [02:36] * Quits: Anonameless (~Nameless@cm218-252-156-82.hkcable.com.hk) (Read error: Connection reset by peer)
  180. # [02:37] * Joins: onar (~onar@2620:0:1b00:16f2:21f:5bff:fe3e:944)
  181. # [02:40] * Joins: gavin_ (~gavin@firefox/developer/gavin)
  182. # [02:42] * Quits: mdelaney (~mdelaney@2620:0:1b00:1191:d69a:20ff:febf:89a0) (Read error: Operation timed out)
  183. # [02:46] * Quits: yutak_home (~kee@U017209.ppp.dion.ne.jp) (Quit: Ex-Chat)
  184. # [02:55] * Joins: davidb (~davidb@bas1-toronto06-2925211560.dsl.bell.ca)
  185. # [02:57] * Joins: erlehmann (~erlehmann@dslb-188-102-050-058.pools.arcor-ip.net)
  186. # [02:57] * Quits: ap (~ap@2620:0:1b00:1191:226:4aff:fe14:aad6) (Quit: ap)
  187. # [02:58] * Joins: KaOSoFt (~maxzagato@190.24.156.162)
  188. # [02:58] * Quits: KaOSoFt (~maxzagato@190.24.156.162) (Changing host)
  189. # [02:58] * Joins: KaOSoFt (~maxzagato@unaffiliated/kaosoft)
  190. # [02:58] <MikeSmith> um
  191. # [02:59] * Quits: KaOSoFt (~maxzagato@unaffiliated/kaosoft) (Client Quit)
  192. # [02:59] <MikeSmith> how is the word "activateable" spelled?
  193. # [02:59] <MikeSmith> is that not a word?
  194. # [03:02] <MikeSmith> activatable
  195. # [03:02] <MikeSmith> only ~100,000 ocurrances
  196. # [03:03] * MikeSmith wonders what other ways people use to express the "activatable"
  197. # [03:05] <Philip`> "can be activated"
  198. # [03:05] * Quits: sicking (~chatzilla@nat/mozilla/x-cuconuyydhcgsmgq) (Ping timeout: 240 seconds)
  199. # [03:06] <MikeSmith> Philip`: my context is, "Make drag-and-drop events keyboard-activatable"
  200. # [03:07] <MikeSmith> is "Make drag-and-drop events fireable by keyboard" any better?
  201. # [03:07] * Joins: m_W (~mwilcox56@c-69-141-106-205.hsd1.nj.comcast.net)
  202. # [03:07] <MikeSmith> you don't really "activate" an event, anyway
  203. # [03:08] <Philip`> "Allow keyboard activation of drag-and-drop events"
  204. # [03:10] <MikeSmith> thanks
  205. # [03:15] <MikeSmith> Hixie: when you have a chance, please flip the spec back to ED
  206. # [03:16] <Hixie> k
  207. # [03:16] <MikeSmith> thanks
  208. # [03:18] * Quits: weinig (~weinig@17.246.16.164) (Quit: weinig)
  209. # [03:25] <Hixie> remind me if i forget to do it in the next few hours
  210. # [03:27] * Quits: variable (~variable@unaffiliated/variable) (Remote host closed the connection)
  211. # [03:31] * Quits: erlehmann (~erlehmann@dslb-188-102-050-058.pools.arcor-ip.net) (Quit: Ex-Chat)
  212. # [03:32] * Quits: davidb (~davidb@bas1-toronto06-2925211560.dsl.bell.ca) (Quit: davidb)
  213. # [03:35] * Joins: wakaba_0 (~wakaba_@203-140-90-184.eonet.ne.jp)
  214. # [03:36] * Parts: kennyluck (~kennyluck@tea04.w3.mag.keio.ac.jp)
  215. # [03:36] * Quits: wakaba_ (~wakaba_@122x221x184x68.ap122.ftth.ucom.ne.jp) (Ping timeout: 252 seconds)
  216. # [03:36] * Quits: justicefries (~gerred@c-98-245-71-126.hsd1.co.comcast.net) (Quit: justicefries)
  217. # [03:37] * Quits: cying (~cying@75-25-137-159.lightspeed.plalca.sbcglobal.net) (Quit: cying)
  218. # [03:38] <MikeSmith> man, David Carlisle is a model of how inter-WG problem-resolving should be conducted
  219. # [03:38] <MikeSmith> despite me talking trash about my frustrations with MathML stuff, he always remains gracious
  220. # [03:39] <MikeSmith> and focuses on trying to figure out where the problems are and how we can try to fix them
  221. # [03:40] <nessy> it can be hard - keeping feelings under control is always hard - but it's definitely more productive ;)
  222. # [03:40] <MikeSmith> yep
  223. # [03:44] * Quits: jlebar (~jlebar@nat/mozilla/x-vmssyylvmhxxjyej) (Ping timeout: 240 seconds)
  224. # [03:45] <MikeSmith> Hixie: if/when you might find some real-time discussion with David to be useful, he says feel free to e-mail or skype him and he can join the channel for the discussion
  225. # [03:47] <MikeSmith> hmm, I find a David Carlisle whose Skype handle is "abadassmother"
  226. # [03:47] <MikeSmith> somehow I think that's not likely him
  227. # [03:48] <AryehGregor> See, that's the nice thing about having a distinctive name. No confusion necessary.
  228. # [03:48] <AryehGregor> (I assume you could tell us the opposite end of that story.)
  229. # [03:49] <MikeSmith> heh
  230. # [03:49] <AryehGregor> No other Mike Smith had the foresight to trademark their name, though. That's how I was able to find you on Twitter or something one time.
  231. # [03:50] <MikeSmith> I'm trademarking the fact that I have a trademark in my name
  232. # [03:50] * MikeSmith looks for Aryeh on twitter
  233. # [03:50] <AryehGregor> Good luck.
  234. # [03:51] * AryehGregor uses no social networking site or anything vaguely similar.
  235. # [03:51] <AryehGregor> Well, I guess I technically use Google Buzz, but only because I wasn't given a choice.
  236. # [03:51] <MikeSmith> heh
  237. # [03:51] <AryehGregor> (I don't post to it, in my defense)
  238. # [03:51] <MikeSmith> that's the next step in their plan
  239. # [03:51] <AryehGregor> (Nor does anyone else in the universe, though, except TabAtkins)
  240. # [03:52] <AryehGregor> (and possibly a single-digit number of other Google employees)
  241. # [03:52] <MikeSmith> I hear Buzz2 will actually generate posts without your consent, and send them out to all your contacts automatically, with them all Cc'ed so that they know who each other are (of course)
  242. # [03:53] <MikeSmith> so that'll be a nice feature to have
  243. # [03:53] <AryehGregor> Even better than what I've heard about Facebook!
  244. # [03:53] <MikeSmith> they will call it a feature for "lazy bloggers who have anxiety about not having posted for 3 months"
  245. # [03:54] <MikeSmith> Facebook is the market leader in privacy-infringing special features
  246. # [03:54] * Joins: Thezilch (~fuz007@cpe-76-90-63-19.socal.res.rr.com)
  247. # [03:54] <MikeSmith> they are setting the de facto standards
  248. # [03:54] <AryehGregor> Yes, but Google is in a strong position to overtake them if they put their mind to it.
  249. # [03:54] <MikeSmith> yes
  250. # [03:54] <AryehGregor> I mean, where was Facebook when Google was out collecting people's unsecured Wi-Fi data without telling them?
  251. # [03:55] <MikeSmith> they just need to try harder, find more novel ways to expose people's private info
  252. # [03:55] <MikeSmith> AryehGregor: good point
  253. # [03:55] <MikeSmith> Google should blog about that
  254. # [03:55] <MikeSmith> "Nobody can infringe on privacy at the scale we can!"
  255. # [03:56] <AryehGregor> They do have an effective opt-out program, to be fair. http://www.theonion.com/video/google-opt-out-feature-lets-users-protect-privacy,14358/
  256. # [03:57] <AryehGregor> The video doesn't work for me. :(
  257. # [03:58] * Joins: jlebar (~jlebar@63.245.220.220)
  258. # [04:09] <MikeSmith> "The Opt-Out Village"
  259. # [04:10] <MikeSmith> beautiful
  260. # [04:10] <MikeSmith> "Christian Groups: Biblical Armageddon Must Be Taught Alongside Global Warming" is nice too
  261. # [04:12] * Joins: rolandsteiner (~rolandste@220.109.219.244)
  262. # [04:14] <othermaciej> MikeSmith: that's good to hear, about David Carlisle
  263. # [04:29] * Joins: Anonameless (~Nameless@cm218-252-156-82.hkcable.com.hk)
  264. # [04:33] * Quits: Martijnc (~Martijnc@91.176.119.63)
  265. # [04:35] <MikeSmith> othermaciej: yeah, kind of leading by example
  266. # [04:35] * Quits: dave_levin (~dave_levi@74.125.59.65) (Quit: dave_levin)
  267. # [04:43] * Joins: justicefries (~gerred@c-98-245-71-126.hsd1.co.comcast.net)
  268. # [04:45] * Quits: justicefries (~gerred@c-98-245-71-126.hsd1.co.comcast.net) (Client Quit)
  269. # [05:08] * Joins: dave_levin (~dave_levi@c-98-203-247-78.hsd1.wa.comcast.net)
  270. # [05:11] * Joins: dave_levin_ (~dave_levi@216.239.45.130)
  271. # [05:14] * Quits: dave_levin (~dave_levi@c-98-203-247-78.hsd1.wa.comcast.net) (Ping timeout: 265 seconds)
  272. # [05:14] * dave_levin_ is now known as dave_levin
  273. # [05:18] * Quits: ttepasse- (~ttepasse@ip-109-90-160-217.unitymediagroup.de) (Quit: ⌘Q)
  274. # [05:22] * Quits: broquaint (a68dd54535@spc2-brig11-0-0-cust40.asfd.cable.virginmedia.com) (Ping timeout: 265 seconds)
  275. # [05:23] * Joins: broquaint (81911bca88@spc2-brig11-0-0-cust40.asfd.cable.virginmedia.com)
  276. # [05:28] * Quits: taf2 (~taf2@pool-98-117-216-229.bltmmd.fios.verizon.net) (Quit: taf2)
  277. # [05:29] * Quits: gavin_ (~gavin@firefox/developer/gavin) (Ping timeout: 252 seconds)
  278. # [05:30] * Joins: gavin_ (~gavin@firefox/developer/gavin)
  279. # [06:04] * Joins: weinig (~weinig@c-69-181-125-223.hsd1.ca.comcast.net)
  280. # [06:14] * Quits: MikeSmith (~MikeSmith@EM114-48-47-240.pool.e-mobile.ne.jp) (Ping timeout: 240 seconds)
  281. # [06:20] * Joins: MikeSmith (~MikeSmith@EM111-188-67-224.pool.e-mobile.ne.jp)
  282. # [06:25] * Joins: cying (~cying@c-24-4-120-70.hsd1.ca.comcast.net)
  283. # [06:25] * Quits: cying (~cying@c-24-4-120-70.hsd1.ca.comcast.net) (Client Quit)
  284. # [06:41] * Quits: Dashiva (Dashiva@wikia/Dashiva) (Ping timeout: 245 seconds)
  285. # [06:42] * Joins: Dashiva (Dashiva@wikia/Dashiva)
  286. # [06:50] * Quits: titacgs (~titacgs@190.2.33.49) (Ping timeout: 265 seconds)
  287. # [06:51] * Joins: Dashimon (Dashiva@wikia/Dashiva)
  288. # [06:54] * Quits: Dashiva (Dashiva@wikia/Dashiva) (Ping timeout: 265 seconds)
  289. # [06:54] * Dashimon is now known as Dashiva
  290. # [06:56] * Parts: mmn (~mmn@129-97-225-230.uwaterloo.ca)
  291. # [06:58] * Joins: Dashimon (Dashiva@ti0169a380-0309.bb.online.no)
  292. # [06:58] * Quits: Dashimon (Dashiva@ti0169a380-0309.bb.online.no) (Changing host)
  293. # [06:58] * Joins: Dashimon (Dashiva@wikia/Dashiva)
  294. # [07:00] * Joins: nimbupani (~nimbupani@c-24-22-131-46.hsd1.wa.comcast.net)
  295. # [07:01] * Quits: Dashiva (Dashiva@wikia/Dashiva) (Ping timeout: 265 seconds)
  296. # [07:01] * Joins: Dashiva (Dashiva@ti0169a380-0346.bb.online.no)
  297. # [07:01] * Quits: Dashiva (Dashiva@ti0169a380-0346.bb.online.no) (Changing host)
  298. # [07:01] * Joins: Dashiva (Dashiva@wikia/Dashiva)
  299. # [07:02] * Quits: Dashimon (Dashiva@wikia/Dashiva) (Ping timeout: 240 seconds)
  300. # [07:06] * Joins: justicefries (~gerred@c-98-245-71-126.hsd1.co.comcast.net)
  301. # [07:07] * Joins: mhausenblas (~mhausenbl@wg1-nat.fwgal01.deri.ie)
  302. # [07:08] * Joins: Dashimon (Dashiva@ti0169a380-0425.bb.online.no)
  303. # [07:08] * Quits: mhausenblas (~mhausenbl@wg1-nat.fwgal01.deri.ie) (Client Quit)
  304. # [07:08] * Quits: Dashimon (Dashiva@ti0169a380-0425.bb.online.no) (Changing host)
  305. # [07:08] * Joins: Dashimon (Dashiva@wikia/Dashiva)
  306. # [07:08] * Joins: mhausenblas (~mhausenbl@wg1-nat.fwgal01.deri.ie)
  307. # [07:08] * Quits: mhausenblas (~mhausenbl@wg1-nat.fwgal01.deri.ie) (Client Quit)
  308. # [07:09] * Joins: mhausenblas (~mhausenbl@wg1-nat.fwgal01.deri.ie)
  309. # [07:09] * Quits: Dashiva (Dashiva@wikia/Dashiva) (Ping timeout: 276 seconds)
  310. # [07:09] * Dashimon is now known as Dashiva
  311. # [07:15] * Joins: Dashimon (Dashiva@wikia/Dashiva)
  312. # [07:17] * Quits: Dashiva (Dashiva@wikia/Dashiva) (Ping timeout: 276 seconds)
  313. # [07:17] * Joins: Dashiva (Dashiva@wikia/Dashiva)
  314. # [07:17] * Joins: dglazkov (~dglazkov@75-37-194-175.lightspeed.lsatca.sbcglobal.net)
  315. # [07:18] * Quits: othermaciej (~mjs@17.246.17.69) (Quit: othermaciej)
  316. # [07:20] * Quits: Dashimon (Dashiva@wikia/Dashiva) (Ping timeout: 240 seconds)
  317. # [07:25] * Joins: Dashimon (Dashiva@ti0169a380-0642.bb.online.no)
  318. # [07:26] * Quits: Dashimon (Dashiva@ti0169a380-0642.bb.online.no) (Changing host)
  319. # [07:26] * Joins: Dashimon (Dashiva@wikia/Dashiva)
  320. # [07:26] * Quits: Dashiva (Dashiva@wikia/Dashiva) (Ping timeout: 260 seconds)
  321. # [07:26] * Dashimon is now known as Dashiva
  322. # [07:32] * Joins: Dashimon (Dashiva@ti0169a380-0732.bb.online.no)
  323. # [07:32] * Quits: Dashimon (Dashiva@ti0169a380-0732.bb.online.no) (Changing host)
  324. # [07:32] * Joins: Dashimon (Dashiva@wikia/Dashiva)
  325. # [07:33] * Joins: zalan (~zalan@192.100.124.156)
  326. # [07:33] * Quits: Dashiva (Dashiva@wikia/Dashiva) (Ping timeout: 260 seconds)
  327. # [07:33] * Dashimon is now known as Dashiva
  328. # [07:35] * Joins: everton (~everton@KD118153063184.ppp-bb.dion.ne.jp)
  329. # [07:40] * Joins: Dashimon (Dashiva@ti0169a380-0912.bb.online.no)
  330. # [07:40] * Quits: Dashimon (Dashiva@ti0169a380-0912.bb.online.no) (Changing host)
  331. # [07:40] * Joins: Dashimon (Dashiva@wikia/Dashiva)
  332. # [07:41] * Quits: Dashiva (Dashiva@wikia/Dashiva) (Ping timeout: 265 seconds)
  333. # [07:41] * Dashimon is now known as Dashiva
  334. # [07:41] * Quits: dglazkov (~dglazkov@75-37-194-175.lightspeed.lsatca.sbcglobal.net) (Quit: dglazkov)
  335. # [07:41] * Quits: nimbupani (~nimbupani@c-24-22-131-46.hsd1.wa.comcast.net) (Quit: nimbupani)
  336. # [07:47] * Joins: Dashimon (Dashiva@ti0169a380-0064.bb.online.no)
  337. # [07:47] * Quits: Dashimon (Dashiva@ti0169a380-0064.bb.online.no) (Changing host)
  338. # [07:47] * Joins: Dashimon (Dashiva@wikia/Dashiva)
  339. # [07:48] * Quits: Dashiva (Dashiva@wikia/Dashiva) (Ping timeout: 260 seconds)
  340. # [07:48] * Dashimon is now known as Dashiva
  341. # [07:50] * Quits: gavin_ (~gavin@firefox/developer/gavin) (Ping timeout: 240 seconds)
  342. # [07:51] * Joins: gavin_ (~gavin@firefox/developer/gavin)
  343. # [07:54] * Joins: Dashimon (Dashiva@ti0169a380-0180.bb.online.no)
  344. # [07:54] * Quits: Dashimon (Dashiva@ti0169a380-0180.bb.online.no) (Changing host)
  345. # [07:54] * Joins: Dashimon (Dashiva@wikia/Dashiva)
  346. # [07:56] * Quits: Dashiva (Dashiva@wikia/Dashiva) (Ping timeout: 264 seconds)
  347. # [07:56] * Dashimon is now known as Dashiva
  348. # [08:00] * Joins: Dashimon (Dashiva@ti0169a380-0212.bb.online.no)
  349. # [08:01] * Quits: Dashimon (Dashiva@ti0169a380-0212.bb.online.no) (Changing host)
  350. # [08:01] * Joins: Dashimon (Dashiva@wikia/Dashiva)
  351. # [08:02] * Joins: drunknbass (~drunknbas@76.91.255.83)
  352. # [08:04] * Quits: Dashiva (Dashiva@wikia/Dashiva) (Ping timeout: 276 seconds)
  353. # [08:04] * Dashimon is now known as Dashiva
  354. # [08:07] * Quits: roc (~roc@203-97-204-82.dsl.clear.net.nz) (Quit: roc)
  355. # [08:10] * weinig is now known as weinig|away
  356. # [08:15] * Quits: Amorphous (jan@unaffiliated/amorphous) (Ping timeout: 248 seconds)
  357. # [08:16] * Joins: maikmerten (~merten@ls5dhcp196.cs.uni-dortmund.de)
  358. # [08:16] * Joins: othermaciej (~mjs@c-69-181-42-237.hsd1.ca.comcast.net)
  359. # [08:20] * Joins: payman_ (~payman@pat.se.opera.com)
  360. # [08:21] * Joins: eighty4 (~eighty4@h-112-7.A163.corp.bahnhof.se)
  361. # [08:21] * Quits: payman (~payman@pat.se.opera.com) (Ping timeout: 240 seconds)
  362. # [08:22] * Joins: Smylers1 (~smylers@host81-151-154-162.range81-151.btcentralplus.com)
  363. # [08:24] * Quits: Smylers (~smylers@host81-159-173-66.range81-159.btcentralplus.com) (Ping timeout: 240 seconds)
  364. # [08:25] * Joins: Dashimon (Dashiva@ti0169a380-0522.bb.online.no)
  365. # [08:25] * Quits: Dashimon (Dashiva@ti0169a380-0522.bb.online.no) (Changing host)
  366. # [08:25] * Joins: Dashimon (Dashiva@wikia/Dashiva)
  367. # [08:25] * Quits: Dashiva (Dashiva@wikia/Dashiva) (Ping timeout: 265 seconds)
  368. # [08:25] * Dashimon is now known as Dashiva
  369. # [08:30] * Joins: Amorphous (jan@unaffiliated/amorphous)
  370. # [08:32] * Joins: Dashimon (Dashiva@ti0169a380-0811.bb.online.no)
  371. # [08:32] * Quits: Dashimon (Dashiva@ti0169a380-0811.bb.online.no) (Changing host)
  372. # [08:32] * Joins: Dashimon (Dashiva@wikia/Dashiva)
  373. # [08:35] * Quits: Dashiva (Dashiva@wikia/Dashiva) (Ping timeout: 265 seconds)
  374. # [08:35] * Dashimon is now known as Dashiva
  375. # [08:37] * Quits: drunknbass (~drunknbas@76.91.255.83) (Remote host closed the connection)
  376. # [08:42] * Joins: Dashimon (Dashiva@wikia/Dashiva)
  377. # [08:42] * Quits: Dashiva (Dashiva@wikia/Dashiva) (Ping timeout: 248 seconds)
  378. # [08:42] * Dashimon is now known as Dashiva
  379. # [08:45] * Joins: Maurice (~ano@a80-101-46-164.adsl.xs4all.nl)
  380. # [08:52] * Quits: dave_levin (~dave_levi@216.239.45.130) (Quit: dave_levin)
  381. # [08:55] * Quits: Smylers1 (~smylers@host81-151-154-162.range81-151.btcentralplus.com) (Ping timeout: 245 seconds)
  382. # [08:56] * Quits: Dashiva (Dashiva@wikia/Dashiva) (Ping timeout: 265 seconds)
  383. # [08:57] * Joins: Dashiva (Dashiva@ti0169a380-0351.bb.online.no)
  384. # [08:57] * Quits: Dashiva (Dashiva@ti0169a380-0351.bb.online.no) (Changing host)
  385. # [08:57] * Joins: Dashiva (Dashiva@wikia/Dashiva)
  386. # [09:02] * Joins: Dashimon (Dashiva@ti0169a380-0513.bb.online.no)
  387. # [09:02] * Quits: Dashimon (Dashiva@ti0169a380-0513.bb.online.no) (Changing host)
  388. # [09:02] * Joins: Dashimon (Dashiva@wikia/Dashiva)
  389. # [09:05] * Quits: Dashiva (Dashiva@wikia/Dashiva) (Ping timeout: 276 seconds)
  390. # [09:05] * Dashimon is now known as Dashiva
  391. # [09:08] <MikeSmith> I wonder if Chris Grigg in the Audio XG is the same as the one who was a member of Negativland
  392. # [09:09] <MikeSmith> ...and who also maybe the same who wrote the music for Maniac Mansion
  393. # [09:12] * Joins: Dashimon (Dashiva@ti0169a380-0742.bb.online.no)
  394. # [09:12] * Quits: Dashimon (Dashiva@ti0169a380-0742.bb.online.no) (Changing host)
  395. # [09:12] * Joins: Dashimon (Dashiva@wikia/Dashiva)
  396. # [09:15] * Quits: Dashiva (Dashiva@wikia/Dashiva) (Ping timeout: 265 seconds)
  397. # [09:15] * Dashimon is now known as Dashiva
  398. # [09:18] * Quits: fecalpatties (~t@pool-96-248-211-27.nrflva.fios.verizon.net)
  399. # [09:20] * Joins: Dashimon (Dashiva@ti0169a380-0149.bb.online.no)
  400. # [09:20] * Quits: Dashimon (Dashiva@ti0169a380-0149.bb.online.no) (Changing host)
  401. # [09:20] * Joins: Dashimon (Dashiva@wikia/Dashiva)
  402. # [09:20] <MikeSmith> is there any way in MediaWiki to add an ID to a paragraph or term/span of text or whatever?
  403. # [09:22] * Quits: Dashiva (Dashiva@wikia/Dashiva) (Ping timeout: 264 seconds)
  404. # [09:22] <annevk> http://www.w3.org/QA/2010/06/an_update_on_css_21.html
  405. # [09:22] * Joins: Dashiva (Dashiva@ti0169a380-0190.bb.online.no)
  406. # [09:22] * Quits: Dashiva (Dashiva@ti0169a380-0190.bb.online.no) (Changing host)
  407. # [09:22] * Joins: Dashiva (Dashiva@wikia/Dashiva)
  408. # [09:25] * Quits: Dashimon (Dashiva@wikia/Dashiva) (Ping timeout: 276 seconds)
  409. # [09:26] <MikeSmith> somebody posted a comment to that blog entry but it has not appeared yet for some reason
  410. # [09:26] <MikeSmith> though I got an feed notification about it
  411. # [09:27] * Joins: Dashimon (Dashiva@ti0169a380-0355.bb.online.no)
  412. # [09:27] * Quits: Dashimon (Dashiva@ti0169a380-0355.bb.online.no) (Changing host)
  413. # [09:27] * Joins: Dashimon (Dashiva@wikia/Dashiva)
  414. # [09:30] * Quits: Dashiva (Dashiva@wikia/Dashiva) (Ping timeout: 264 seconds)
  415. # [09:31] * Joins: Dashiva (Dashiva@ti0169a380-0522.bb.online.no)
  416. # [09:31] * Quits: Dashiva (Dashiva@ti0169a380-0522.bb.online.no) (Changing host)
  417. # [09:31] * Joins: Dashiva (Dashiva@wikia/Dashiva)
  418. # [09:32] * Quits: Dashimon (Dashiva@wikia/Dashiva) (Ping timeout: 240 seconds)
  419. # [09:37] * Joins: henrikbjorn (~hb@80.199.116.190.static.peytz.dk)
  420. # [09:39] * Joins: Dashimon (Dashiva@wikia/Dashiva)
  421. # [09:40] * Quits: Dashiva (Dashiva@wikia/Dashiva) (Ping timeout: 240 seconds)
  422. # [09:42] * panicsys is now known as WePanicForYou
  423. # [09:42] * Joins: Dashiva (Dashiva@ti0169a380-0742.bb.online.no)
  424. # [09:42] * Quits: Dashiva (Dashiva@ti0169a380-0742.bb.online.no) (Changing host)
  425. # [09:42] * Joins: Dashiva (Dashiva@wikia/Dashiva)
  426. # [09:45] * Quits: Dashimon (Dashiva@wikia/Dashiva) (Ping timeout: 264 seconds)
  427. # [09:46] * Joins: Dashimon (Dashiva@wikia/Dashiva)
  428. # [09:47] * Quits: Dashiva (Dashiva@wikia/Dashiva) (Ping timeout: 260 seconds)
  429. # [09:48] * Joins: Dashiva (Dashiva@ti0169a380-0921.bb.online.no)
  430. # [09:48] * Quits: Dashiva (Dashiva@ti0169a380-0921.bb.online.no) (Changing host)
  431. # [09:48] * Joins: Dashiva (Dashiva@wikia/Dashiva)
  432. # [09:51] * Quits: Dashimon (Dashiva@wikia/Dashiva) (Ping timeout: 260 seconds)
  433. # [09:51] * Joins: wakaba_ (~wakaba_@122x221x184x68.ap122.ftth.ucom.ne.jp)
  434. # [09:51] * Quits: everton (~everton@KD118153063184.ppp-bb.dion.ne.jp) (Remote host closed the connection)
  435. # [09:51] * Joins: everton (~everton@98.158.118.151)
  436. # [09:52] <MikeSmith> https://bugs.webkit.org/show_bug.cgi?id=41363 is interesting
  437. # [09:52] <MikeSmith> what to do if author puts "body { text-rendering: optimizeLegibility; }"
  438. # [09:52] * Quits: wakaba_0 (~wakaba_@203-140-90-184.eonet.ne.jp) (Ping timeout: 276 seconds)
  439. # [09:53] <MikeSmith> paul_irish: btw, I don't think putting fragment IDs onto shortened URLs works the way you might have intended :)
  440. # [09:54] <MikeSmith> e.g., http://webk.it/6136#c3
  441. # [09:54] * Hixie mumbles something about it being bad to give authors control over how UAs optimise
  442. # [09:54] <MikeSmith> what to do if author puts "body { text-rendering: optimizeEntireBrowsingExperience; }"
  443. # [09:55] <Peter`> MikeSmith: Chrome forwards me to https://bugs.webkit.org/show_bug.cgi?id=6136#c3, also scrolls the page to the intended position
  444. # [09:55] <MikeSmith> Peter`: well lah dee dah
  445. # [09:55] <MikeSmith> good for you
  446. # [09:55] <MikeSmith> seriously?
  447. # [09:55] <Peter`> Uh..?
  448. # [09:55] <MikeSmith> does Chrome cook breakfast for people now too?
  449. # [09:56] <MikeSmith> it seems like chrome should not do that
  450. # [09:56] <hsivonen> I'm concerned of a situation where a perf test suite turns on all these typographic nice things but doesn't test that they are taking effect and then Brand X browser scores better than Gecko simply by not implementing any of that stuff
  451. # [09:56] * Joins: Dashimon (Dashiva@wikia/Dashiva)
  452. # [09:57] <Peter`> Whatever. I'm just saying it works on Chrome, I'm unaware of what the spec says on it, or of what other browsers do.
  453. # [09:57] <Lachy> MikeSmith, I just tried to update my answer on the issue 88 objetion poll, but it doesn't seem to be accepting my changes. It's still showing my original answers.
  454. # [09:57] <MikeSmith> Lachy: I'll check now
  455. # [09:58] <hsivonen> Lachy: do you see the new answer in another browser?
  456. # [09:58] * Quits: Dashiva (Dashiva@wikia/Dashiva) (Ping timeout: 265 seconds)
  457. # [09:58] * Dashimon is now known as Dashiva
  458. # [09:58] <MikeSmith> Peter`: sorry, I was just trying to be funny, but I guess it sounded like I was trying to be a dick instead..
  459. # [09:59] <Lachy> ah, yeah, it works now. Must have been just a cache issue.
  460. # [09:59] <Peter`> Ok, I misinterpreted your message in that case, thank you for clearing it up
  461. # [10:00] <MikeSmith> Peter`: hmm, Minefield and Opera also do as Chrome does for http://webk.it/6136#c3 .. so egg on my face
  462. # [10:00] <MikeSmith> Safari does not, though
  463. # [10:00] <MikeSmith> or at least Webkit does not
  464. # [10:00] <MikeSmith> nightly
  465. # [10:00] <Peter`> IE doesn't do it either
  466. # [10:00] <MikeSmith> interesting
  467. # [10:01] * Joins: zcorpan_ (~zcorpan@c-1799e355.410-6-64736c14.cust.bredbandsbolaget.se)
  468. # [10:01] <MikeSmith> I wonder what the specs say
  469. # [10:01] <Hixie> 20 hours left on the polls, Philip`, zcorpan, MikeSmith, and anyone else i missed :-)
  470. # [10:02] <Hixie> foolip: ^
  471. # [10:02] <MikeSmith> I payed at the office.
  472. # [10:03] * Joins: Dashimon (Dashiva@ti0169a380-0172.bb.online.no)
  473. # [10:03] * Quits: Dashimon (Dashiva@ti0169a380-0172.bb.online.no) (Changing host)
  474. # [10:03] * Joins: Dashimon (Dashiva@wikia/Dashiva)
  475. # [10:03] <MikeSmith> Lachy: OK. I have noticed some other unusualities lately that seem to indicate borked caching somewhere
  476. # [10:03] <Peter`> MikeSmith: http://trac.tools.ietf.org/wg/httpbis/trac/ticket/43 seems to be related
  477. # [10:03] <annevk> MikeSmith, fragids ought to be forwarded
  478. # [10:03] <MikeSmith> Peter`: thanks
  479. # [10:03] * MikeSmith reads
  480. # [10:03] <annevk> MikeSmith, though client-side
  481. # [10:03] <Peter`> while it more specifically relates to overriding fragment ids
  482. # [10:04] <MikeSmith> annevk: sez who?
  483. # [10:04] * Quits: Dashimon (Dashiva@wikia/Dashiva) (Client Quit)
  484. # [10:04] <annevk> MikeSmith, it's like <image> needs to be parsed as <img>; it wasn't always defined, but it's certainly true :p
  485. # [10:04] * Joins: Smylers (~smylers@static-93.158.79.103.got.public.icomera.com)
  486. # [10:04] <annevk> MikeSmith, I believe the HTTP WG might catch up though
  487. # [10:05] <annevk> MikeSmith, actually, I think it has always been defined for the simple case
  488. # [10:05] * Quits: Dashiva (Dashiva@wikia/Dashiva) (Ping timeout: 265 seconds)
  489. # [10:06] * Quits: ukai (~ukai@220.109.219.244) (Ping timeout: 240 seconds)
  490. # [10:07] <annevk> MikeSmith, maybe not, "fragment" is mentioned only once in 2616 (haven't looked at errata though)
  491. # [10:08] <Peter`> http://www.w3.org/Protocols/HTTP/Fragment/draft-bos-http-redirect-00.txt
  492. # [10:08] <Peter`> That seems to be spot-on
  493. # [10:09] <annevk> no official standing whatsoever though
  494. # [10:09] * Joins: mpt (~mpt@canonical/mpt)
  495. # [10:09] <annevk> so I guess it's like <image> after all
  496. # [10:10] <MikeSmith> good times
  497. # [10:11] * Joins: svl (~chatzilla@a194-109-2-65.dmn.xs4all.nl)
  498. # [10:13] * Joins: ukai (~ukai@220.109.219.244)
  499. # [10:13] <hsivonen> Hixie: I'm debugging an interesting crash with document.documentElement.innerHTML = "<math></html>"
  500. # [10:14] * Joins: smaug (~chatzilla@cs181150024.pp.htv.fi)
  501. # [10:14] <hsivonen> Hixie: I think the spec doesn't take this into account, and my ad hoc fixes to the spec don't take it into account, either
  502. # [10:14] * Quits: Yudai (~Yudai@p6eac83.kngwnt01.ap.so-net.ne.jp) (Quit: SIGTERM received; exit)
  503. # [10:14] * Joins: Yudai (~Yudai@p6eac83.kngwnt01.ap.so-net.ne.jp)
  504. # [10:16] <foolip> ddfdf
  505. # [10:16] <annevk> one more and you have a color
  506. # [10:16] <foolip> hehe
  507. # [10:18] <foolip> just trying to shut things down, this computer i moving to Gothenburg
  508. # [10:19] * Quits: foolip (~philip@c-0e8ee555.017-40-6c6b7013.cust.bredbandsbolaget.se) (Quit: leaving)
  509. # [10:19] <hsivonen> Hixie: I assume we wouldn't want to switch out of 'in foreign' and into 'after body' with <math> on the top of the stack
  510. # [10:20] <annevk> the spec doesn't crash though, does it?
  511. # [10:21] <zcorpan_> https://connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=559531 - IE9 fails html5lib html parser tests - Closed
  512. # [10:21] <zcorpan_> as Fixed
  513. # [10:22] <hsivonen> Hixie: OTOH, if we don't (or only change the secondary mode to 'after body'), the end tag handling in 'in foreign content' ends up popping <html> off the stack
  514. # [10:22] * Quits: ukai (~ukai@220.109.219.244) (Ping timeout: 260 seconds)
  515. # [10:23] <hsivonen> which should never happen and, therefore, crashes in EOF handler
  516. # [10:25] <jgraham> hsivonen: Would it be possible for you to document your ad-hoc fixes to the spec in the relevant bug reports?
  517. # [10:25] <hsivonen> jgraham: I suppose it would be possible
  518. # [10:26] <jgraham> hsivonen: Prose is easier to read than java :)
  519. # [10:26] <zcorpan_> seems they still fail many html5lib tests
  520. # [10:26] <annevk> hsivonen, so it doesn't crash for <math></head> or <math></body> or <math></td> ?
  521. # [10:27] <hsivonen> annevk: let's check
  522. # [10:27] <hsivonen> annevk: no crash
  523. # [10:28] <hsivonen> annevk: (with html as the context node)
  524. # [10:28] <hsivonen> so it seems wrong to change the primary mode to 'after body' without popping the foreign stuff off the stack
  525. # [10:29] <hsivonen> I think this leaves three options:
  526. # [10:29] <hsivonen> 1) Ignoring </html> (and maybe </body>) in 'in foreign content'
  527. # [10:29] * Quits: Heimidal (~heimidal@unaffiliated/heimidal) (Remote host closed the connection)
  528. # [10:29] <hsivonen> 2) popping all foreign stuff off the stack when transitioning to 'after body'
  529. # [10:30] <hsivonen> 3) making an exception in the end tag handling in 'in foreign' so that the first item on the stack never gets popped no matter what
  530. # [10:30] <jgraham> hsivonen: It feels like </html> in innderHTML should be ignored
  531. # [10:30] <annevk> is this specific to in foreign content or would a document <math></html> do it too?
  532. # [10:30] <jgraham> Although I don't know what happens in other cases
  533. # [10:30] * Joins: ROBOd (~robod@92.86.245.3)
  534. # [10:30] <MikeSmith> zcorpan_: are there bugs open for the other tests they fail?
  535. # [10:31] <MikeSmith> zcorpan_: or is their any distinguishable pattern to the bugs they fail?
  536. # [10:31] <zcorpan_> ie breaks out of <mtext>
  537. # [10:31] <hsivonen> annevk: <math></html> crashes even without fragment mode
  538. # [10:31] <MikeSmith> zcorpan_: hmm, that especially ain't good
  539. # [10:31] <zcorpan_> MikeSmith: no (afaik) and no (they just fail lots of tests)
  540. # [10:31] <MikeSmith> k
  541. # [10:32] <hsivonen> jgraham: so ignoring </html> in the fragment case is not the right fix
  542. # [10:32] <zcorpan_> oh they don't support mathml parsing at all
  543. # [10:32] <zcorpan_> and i was using <svg>, heh
  544. # [10:33] <zcorpan_> hmm they don't do case fixup for <foreigncontent>
  545. # [10:33] <jgraham> hsivonen: Well, it might be part of the right fix :)
  546. # [10:34] <zcorpan_> but they break out of <foreignContent>
  547. # [10:34] <annevk> hsivonen, and it's due to the spec? still not quite clear to me where it goes wrong; but I guess I should do something else
  548. # [10:34] <jgraham> annevk: The spec for end tag handling in foreign content mode is broken on its own
  549. # [10:34] <hsivonen> annevk: it is possible that my ad hoc fixes to spec crashes introduced this crash
  550. # [10:35] <jgraham> annevk: hsivonen has added some fixes
  551. # [10:35] * Joins: akamike (~akamike@94-193-106-14.zone7.bethere.co.uk)
  552. # [10:35] <hsivonen> annevk: Hixie's fixes to SVG </a> and </font> handling caused the spec to crash
  553. # [10:36] <jgraham> hsivonen: This case crashes my local copy of html5lib which I think implements the spec as written
  554. # [10:36] <zcorpan_> at least they parse <foobar/> outside foreign content correctly now :)
  555. # [10:36] <abarth> are they trying to implement the HTML5 parsing algorithm?
  556. # [10:37] <jgraham> abarth: They seem to be trying to implement foreign content in HTML
  557. # [10:37] <annevk> I think the rest of it too
  558. # [10:37] <zcorpan_> abarth: half-assed, yes. they have a proper tree now (they said they implemented AAA) and svg in html
  559. # [10:37] <jgraham> it's not clear whether they are implementing the rest of the algorithm or trying to cherry pick
  560. # [10:38] <hsivonen> jgraham: I'm thinking of either ignoring </html> in 'in foreign content' or modifying step 3 under "An end tag, if the current node is not an element in the HTML namespace." stop right before it pops the last node off the stack
  561. # [10:38] <zcorpan_> they don't implement foster parenting
  562. # [10:38] <abarth> cherry picking seems silly
  563. # [10:38] * Joins: Phae (~Phae@chimera.macmillan.com)
  564. # [10:38] <jgraham> abarth: Indeed
  565. # [10:38] <abarth> the main benefit is from going "all in" (to borrow a phrase from my favorite blog)
  566. # [10:39] <hsivonen> zcorpan_: interesting. I have thought that implementing parts of the parsing algorithm in an existing parser would be more painful than implementing the whole thing from scratch
  567. # [10:39] <jgraham> hsivonen: Have you made other changes to that algorithm?
  568. # [10:40] <hsivonen> jgraham: I fixed http://www.w3.org/Bugs/Public/show_bug.cgi?id=9582 , http://www.w3.org/Bugs/Public/show_bug.cgi?id=9581 and http://www.w3.org/Bugs/Public/show_bug.cgi?id=9580
  569. # [10:40] <zcorpan_> hsivonen: maybe their goal for ie9 was just proper tree and svg support
  570. # [10:41] <hsivonen> jgraham: I'll look up my code changes and try to figure out how to map those back to English
  571. # [10:41] <hsivonen> jgraham: the diff is http://hg.mozilla.org/projects/htmlparser/rev/b08b9993cd5d
  572. # [10:42] <hsivonen> jgraham: don't pay attention to the "changes" inside switch (mode)
  573. # [10:42] * Quits: nattokirai (~nattokira@rtr.mozilla.or.jp) (Quit: nattokirai)
  574. # [10:43] <jgraham> hsivonen: thanks
  575. # [10:45] * Joins: kennyluck (~kennyluck@tea04.w3.mag.keio.ac.jp)
  576. # [10:46] * Quits: Lachy (~Lachlan@cm-84.215.59.50.getinternet.no) (Quit: This computer has gone to sleep)
  577. # [10:48] <hsivonen> jgraham: eltPosForeign represents /node/ from the spec (by index)
  578. # [10:48] <hsivonen> jgraham: the three lines at http://hg.mozilla.org/projects/htmlparser/rev/b08b9993cd5d#l1.66 are one addition
  579. # [10:49] <hsivonen> fixing http://www.w3.org/Bugs/Public/show_bug.cgi?id=9580
  580. # [10:49] * Quits: kennyluck (~kennyluck@tea04.w3.mag.keio.ac.jp) (Client Quit)
  581. # [10:50] <hsivonen> jgraham: http://hg.mozilla.org/projects/htmlparser/rev/b08b9993cd5d#l1.64 fixes http://www.w3.org/Bugs/Public/show_bug.cgi?id=9582
  582. # [10:50] * Joins: kennyluck (~kennyluck@tea04.w3.mag.keio.ac.jp)
  583. # [10:50] <hsivonen> jgraham: currentPtr is the index of the top aka. bottom of the stack
  584. # [10:52] <hsivonen> jgraham: it it is smaller than the just-decremented eltPosForeign, the secondary insertion mode has popped so much stuff that it would be bad to continue per spec before /node/ is in range for the current stack again
  585. # [10:53] * Joins: ukai (~ukai@220.109.219.244)
  586. # [10:53] <hsivonen> jgraham: the left-hand part of the |if| condition on line http://hg.mozilla.org/projects/htmlparser/rev/b08b9993cd5d#l1.57 fixes http://www.w3.org/Bugs/Public/show_bug.cgi?id=9581
  587. # [10:53] <hsivonen> jgraham: that's all, I think
  588. # [10:54] <jgraham> hsivonen: OK
  589. # [10:58] <hsivonen> krijnh: logs are broken
  590. # [11:03] <hsivonen> zcorpan_: they aren't supposed to case-correct <foreigncontent> but <foreignobject>
  591. # [11:05] <MikeSmith> zcorpan_: what's AAA?
  592. # [11:06] <annevk> adoption-agency-algorithm
  593. # [11:06] <zcorpan_> hsivonen: oops
  594. # [11:06] <MikeSmith> ah
  595. # [11:06] <hsivonen> jgraham: currently, </body> in 'in foreign' pops more stuff than </body> with <div> but no foreign content on the stack
  596. # [11:07] * Joins: everton_ (~everton@KD118153063184.ppp-bb.dion.ne.jp)
  597. # [11:07] <hsivonen> jgraham: I'd expect this to be a bug, too
  598. # [11:07] <zcorpan_> hsivonen: still, they didn't turn <fooBarBaz> to lowercase
  599. # [11:07] * Quits: everton_ (~everton@KD118153063184.ppp-bb.dion.ne.jp) (Client Quit)
  600. # [11:07] <hsivonen> what if we ignored </body> and </html> in 'in foreign content'?
  601. # [11:07] <hsivonen> would that be too blunt a solution?
  602. # [11:09] * zcorpan_ wouldn't mind always ignoring </body> and </html>
  603. # [11:10] * Quits: everton (~everton@98.158.118.151) (Ping timeout: 265 seconds)
  604. # [11:10] <jgraham> wfm I think
  605. # [11:12] <hsivonen> hmm. I think the new end tag handling is probably more aggressive that Hixie intended
  606. # [11:12] <hsivonen> consider <dl><svg><foreignContent><div><math></dl><foo>
  607. # [11:12] <hsivonen> </dl> pops stuff until <dl> has been popped
  608. # [11:12] * Joins: mahound_ (~pferreir@unaffiliated/mahound)
  609. # [11:12] <hsivonen> in particular, it doesn't stop at the <div>
  610. # [11:13] <hsivonen> aaagh.
  611. # [11:13] <hsivonen> zcorpan_'s foreignContent is messing with my head
  612. # [11:13] <zcorpan_> heh
  613. # [11:14] <hsivonen> anyway, <foo> becomes the next sibling of <dl>
  614. # [11:15] <zcorpan_> why would it stop at the div? that doesn't make any sense
  615. # [11:16] <hsivonen> in the <dl><svg><foreignObject><div><math></dl><foo> case, both <foreignObject> and <div> are scoping
  616. # [11:16] * Joins: pauld (~chatzilla@194.102.13.2)
  617. # [11:16] <hsivonen> normally, </dl> doesn't match a <dl> if there's a scoping element in between
  618. # [11:16] * Joins: roc (~roc@121.98.230.221)
  619. # [11:16] <jgraham> I agree that it should stop at scopiung elements
  620. # [11:17] <jgraham> *scoping
  621. # [11:17] * Joins: Lachy (~Lachlan@pat-tdc.opera.com)
  622. # [11:17] <zcorpan_> if there's a scoping element in between, shouldn't the end tag just be treated as if the <dl> start tag wasn't there?
  623. # [11:17] * Joins: oal (~oal@5.79-160-122.customer.lyse.net)
  624. # [11:18] <hsivonen> zcorpan_: possibly, but that's not what the spec does
  625. # [11:18] <hsivonen> zcorpan_: which looks like a spec bug to me
  626. # [11:18] <hsivonen> it's a bug of such magnitude that I'm not fully comfortable with improvising as solution
  627. # [11:19] <hsivonen> but I should land something to get rid of the crasher :-(
  628. # [11:19] <zcorpan_> <dl><div></dl>x
  629. # [11:19] <zcorpan_> closes the dl
  630. # [11:20] <hsivonen> zcorpan_: good point
  631. # [11:20] <hsivonen> <dl><div></body>x
  632. # [11:21] <hsivonen> doesn't close dl
  633. # [11:21] <hsivonen> but if </body> happens in 'in foreign' it pops stuff all the way to <body>
  634. # [11:22] <hsivonen> well, I guess ignoring </body> and </html> would good enough to address the worst cases
  635. # [11:23] * Joins: aho (~nya@g228015007.adsl.alicedsl.de)
  636. # [11:23] * Quits: Rik` (~Rik`@pha75-2-81-57-187-57.fbx.proxad.net) (Ping timeout: 265 seconds)
  637. # [11:23] * Quits: Lachy (~Lachlan@pat-tdc.opera.com) (Quit: Leaving)
  638. # [11:23] * Joins: Lachy (~Lachlan@pat-tdc.opera.com)
  639. # [11:24] <MikeSmith> .
  640. # [11:24] <MikeSmith> (sorry, fat-finger)
  641. # [11:25] <hsivonen> whoa. <dl><svg><foreignObject><div><math></body><foo> is worse than I thought
  642. # [11:25] <hsivonen> <foo> becomes the next sibling on <body>!
  643. # [11:25] * Joins: ZombieLoffe (~e@unaffiliated/zombieloffe)
  644. # [11:27] <MikeSmith> sweet
  645. # [11:28] <MikeSmith> huh?
  646. # [11:28] <MikeSmith> isn't already the next sibling of body in your example?
  647. # [11:29] <MikeSmith> oh
  648. # [11:29] * MikeSmith puts down his meth pipe
  649. # [11:29] <MikeSmith> (ignore me)
  650. # [11:31] * Joins: adactio (~adactio@host213-123-197-180.in-addr.btopenworld.com)
  651. # [11:34] <zcorpan_> awesome that websrt has <comment> and ie also has <comment> in html
  652. # [11:36] <jgraham> hsivonen: I think the end tag handling in In Foreign Content needs to be totally rewritten...
  653. # [11:37] <hsivonen> jgraham: :-(
  654. # [11:37] <hsivonen> jgraham: how?
  655. # [11:38] <hsivonen> is the whatwg wiki broken or my browser? some operations that are supposed to redirect me don't
  656. # [11:38] <hsivonen> and I'm left with a blank page
  657. # [11:38] <jgraham> hsivonen: I don't know
  658. # [11:38] <jgraham> hsivonen: That's the problem
  659. # [11:39] <jgraham> But it feels like we're trying to patch around the wrong approach
  660. # [11:39] <jgraham> I could be wrong of course
  661. # [11:41] <hsivonen> jgraham: it's also possible that my fix for http://www.w3.org/Bugs/Public/show_bug.cgi?id=9582 is wrong
  662. # [11:41] <annevk> http://html5.org/tools/web-apps-tracker now remembers the show editorial flag
  663. # [11:42] <hsivonen> jgraham: and the right fix would be setting the insertion mode to the secondary mode and returning instead of continuing the loop
  664. # [11:43] <annevk> only browser it goes wrong in is Firefox
  665. # [11:43] <annevk> it does not seem to reflow the page after a class name change to the body element
  666. # [11:44] <zcorpan_> annevk: nice
  667. # [11:49] <roc> looks to me like the body class is not being set in firefox
  668. # [11:50] * Joins: Rik` (~Rik`@213.41.141.234)
  669. # [11:50] <zcorpan_> http://forums.whatwg.org/viewtopic.php?t=4334 - how to produce HTML5 printable pdf
  670. # [11:51] <annevk> roc, weird, everyone gets the same code
  671. # [11:51] <annevk> roc, and invoking updateEditorial() after page load does work...
  672. # [11:52] * abarth is now known as abarth|zZz
  673. # [11:52] <annevk> roc, maybe a bug due to parser changes?
  674. # [11:52] <roc> checking
  675. # [11:53] <roc> so I think it's to do with form history restoration
  676. # [11:54] <hsivonen> does it involve innerHTML?
  677. # [11:54] <roc> no
  678. # [11:54] <hsivonen> good
  679. # [11:54] <roc> if you load the page the first time, the checkbox is checked. You uncheck the checkbox and reload. We remember that the checkbox was unchecked, so in the reloaded page, we uncheck it
  680. # [11:54] <roc> then "if(showEdits() && readCookie("editorial") == "editorial") {" is false because showEdits returned false because the editorial checkbox is not checked
  681. # [11:55] <roc> so you don't call updateEditorial
  682. # [11:56] <jgraham> hsivonen: So am I reading your fixes right? If I am they boil down to:
  683. # [11:56] <jgraham> In step 4 abort if node is the root node
  684. # [11:57] <jgraham> After step 5, if node is no longer on the stack of open elements, set node to the bottommost element on the stack of open elements
  685. # [11:57] <annevk> roc, ah, you remember the value of the checkbox, but not the class name on the body
  686. # [11:57] <roc> yeah
  687. # [11:57] * Quits: tndH (~Rob@cpc2-leed18-0-0-cust427.leed.cable.ntl.com) (Quit: ChatZilla 0.9.86-rdmsoft [XULRunner 1.9.0.1/2008072406])
  688. # [11:57] <annevk> hmm
  689. # [11:57] <roc> why would we remember the class name on the body?
  690. # [11:59] <annevk> mkay, removed the showEdits() check there
  691. # [11:59] <annevk> went wrong in Chrome too with history navigation
  692. # [11:59] <annevk> Opera works fine
  693. # [12:00] <roc> I'm not really sure what the status of form history restoration is
  694. # [12:00] <roc> spec-wise
  695. # [12:06] <annevk> I think Hixie might have specced it out, but I'm not familiar with the details
  696. # [12:07] <roc> annevk: I'm confused about one thing in your page
  697. # [12:07] <roc> function updateEditorial() {
  698. # [12:07] <roc> var editorial = showEdits() ? "" : "editorial"
  699. # [12:07] <roc> shouldn't that be the other way around?
  700. # [12:08] <annevk> the naming is all confusing :/
  701. # [12:08] <annevk> but editorial means that stuff will be hidden
  702. # [12:08] <annevk> well "editorial"
  703. # [12:09] <hsivonen> yeah, the YouTube blog *so* makes me want to support Content Protection to enable them to serve "This rental is currently unavailable in your country."
  704. # [12:09] <annevk> this code needs a few more passes before it's logical again
  705. # [12:09] <annevk> it also has createCookie and readCookie for non-cookie code
  706. # [12:10] <roc> hsivonen: heh, we got that too
  707. # [12:10] <roc> annevk, OK, I'm going to stop trying to make it work then :-)
  708. # [12:10] <annevk> sorry, the code is logical, it's just not logically named
  709. # [12:12] <hsivonen> umm. how do sites that embed the YouTube swf player ensure that the swf doesn't get at private information on the embedding page?
  710. # [12:12] <annevk> hsivonen, yeah, blargh
  711. # [12:12] <annevk> content protection is teh evil
  712. # [12:15] * Quits: MikeSmith (~MikeSmith@EM111-188-67-224.pool.e-mobile.ne.jp) (Ping timeout: 276 seconds)
  713. # [12:16] * Quits: annevk (~annevk@5355737B.cable.casema.nl) (Remote host closed the connection)
  714. # [12:17] * Joins: MikeSmith (~MikeSmith@EM114-48-143-238.pool.e-mobile.ne.jp)
  715. # [12:17] * Joins: annevk (~annevk@5355737B.cable.casema.nl)
  716. # [12:19] <zcorpan_> hsivonen: they trust youtube?
  717. # [12:20] <annevk> most of the other issues they mention will be addressed in due course though
  718. # [12:21] * Joins: corey__ (~jackie@209.237.79.138)
  719. # [12:21] <corey__> is this the proper channel for html5 discussions?
  720. # [12:22] <zcorpan_> yes
  721. # [12:22] * roc hacks on fullscreen to make that one go away
  722. # [12:23] <hsivonen> zcorpan_: as far as I can tell, the embedding model is already "they trust YouTube", yes
  723. # [12:23] <zcorpan_> roc: api? for video only or anything?
  724. # [12:23] <annevk> roc, someone hacking on a spec too?
  725. # [12:23] <roc> yep
  726. # [12:23] <roc> I already proposed it in the whatwg list a while ago
  727. # [12:23] <roc> zcorpan_: everything
  728. # [12:24] <hsivonen> zcorpan_: so doing <script src="http://www.youtube.com/do/whatever/you/do.js"></script> should work fine
  729. # [12:24] <roc> zcorpan_, annevk: https://wiki.mozilla.org/Gecko:FullScreenAPI#Gecko_Implementation
  730. # [12:24] <roc> erp
  731. # [12:24] <roc> ignore the implementation bit
  732. # [12:25] <roc> that's just a slight refinement of what was discussed here: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-January/024872.html
  733. # [12:27] <corey__> are websockets a dependable technology?
  734. # [12:28] <annevk> corey__, what does that mean?
  735. # [12:28] <annevk> roc, looks pretty good, though it would be nice if we could avoid putting more stuff on Window
  736. # [12:28] <corey__> I'm asking if it's doing to be adopted by major browsers in the near future. seems to be only on chrome at the moment.
  737. # [12:28] <roc> yeah
  738. # [12:28] <zcorpan_> maybe fullscreen stuff should be on window.screen :)
  739. # [12:29] <roc> no it shouldn't
  740. # [12:29] <roc> you don't make the screen fullscreen
  741. # [12:29] <roc> I could go with "navigator is the new window"
  742. # [12:29] <annevk> corey__, other browsers are implementing it, yes
  743. # [12:29] <roc> corey__: it's on Firefox trunk
  744. # [12:29] <roc> so the next Firefox will have it
  745. # [12:30] <corey__> I was lead to believe Firefox 4 would have it?
  746. # [12:30] <roc> yeah
  747. # [12:30] * Quits: Smylers (~smylers@static-93.158.79.103.got.public.icomera.com) (Ping timeout: 248 seconds)
  748. # [12:30] <roc> annevk: thing is, Gecko already has a "fullscreen" attribute on Window
  749. # [12:30] <roc> er, fullScreen
  750. # [12:30] * Joins: titacgs (~titacgs@190.2.33.49)
  751. # [12:31] <hsivonen> roc: why is there already fullScreen on window?
  752. # [12:31] <hsivonen> roc: XUL stuff leaking to the Web?
  753. # [12:31] <roc> maybe, I don't know without doing the archaeology
  754. # [12:32] <annevk> seems to be unique to Gecko
  755. # [12:32] <annevk> well, at least Opera/Chrome don't have it
  756. # [12:33] <roc> I could add the new APIs elsewhere, and even a new 'fullScreen' attribute
  757. # [12:34] <roc> it's just that Window is the most logical place for it, apart from the global namespace pollution problem
  758. # [12:45] <othermaciej> roc: it seems odd that requestFullScreen is on Window but operates on an Element, instead of just being an Element method
  759. # [12:45] <roc> you might not have an element
  760. # [12:45] <roc> we could have two no-arg methods, one on Element and one on Window
  761. # [12:46] <othermaciej> would the one on Window do anything different than applying full-screen to the root element?
  762. # [12:46] <hsivonen> roc: what about non-arg methods on Element and Document?
  763. # [12:46] <hsivonen> roc: to avoid window pollution
  764. # [12:46] <roc> although there's the variation for disabling keys, so that's two methods on Element and two on Window
  765. # [12:46] <annevk> is it likely we would have other options than keys in the future?
  766. # [12:47] <othermaciej> adding to Window pollutes the global namespace, which is bad
  767. # [12:47] <roc> annevk: I don't know
  768. # [12:47] <roc> yes, I know
  769. # [12:47] <hsivonen> roc: has Document been considered?
  770. # [12:47] <roc> othermaciej: yes, making the root element fullscreen has side effects ... the default :full-screen style rule would kick in
  771. # [12:47] <annevk> othermaciej, root can be positioned within the initial containing block
  772. # [12:48] <roc> hsivonen: I'm considering it right now :-)
  773. # [12:48] <othermaciej> I think WebKit's enterFullscreen() and exitFullscreen() extensions on HTMLVideoElement could just be applied to all elements
  774. # [12:48] <MikeSmith> corey__: https://bugzilla.mozilla.org/show_bug.cgi?id=472529
  775. # [12:49] * zcorpan_ wonders what happens if you fullsceen an element that's display:none
  776. # [12:49] <roc> othermaciej: I think they behave differently from what I'm working on
  777. # [12:49] <MikeSmith> corey__: I think most of the code has already landed in gecko trunk
  778. # [12:49] <othermaciej> also it doesn't make sense to me for the shorter simpler name to be the one with keyboard disabled
  779. # [12:49] <roc> it's not
  780. # [12:49] <othermaciej> er
  781. # [12:49] <othermaciej> with keyboard enabled I mean
  782. # [12:49] <corey__> I'm using a recent minefield build and not seeing websockets enabled =/
  783. # [12:49] <hsivonen> hmm. I guess the whatwg wiki isn't broken but instead my snapshot of Gecko doesn't support HTTP redirects
  784. # [12:49] <othermaciej> having keyboard enabled is a big security risk, so I am not sure why it should be allowed at all
  785. # [12:50] <zcorpan_> corey__: works for me
  786. # [12:50] <roc> WriteRoom, stuff like that
  787. # [12:50] <roc> lots of games need the keybaord
  788. # [12:50] <othermaciej> have you thought of a sufficient way to mitigate the security risk of a full-screen OS simulacrum?
  789. # [12:50] <corey__> zcorpan_, your version?
  790. # [12:50] <hsivonen> othermaciej: shouldn't full-screen first-person WebGL shooters support movement by letter keys?
  791. # [12:50] <annevk> it does make sense to reverse the logic I think
  792. # [12:50] <zcorpan_> corey__: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:2.0b2pre) Gecko/20100629 Minefield/4.0b2pre
  793. # [12:50] * Quits: justicefries (~gerred@c-98-245-71-126.hsd1.co.comcast.net) (Quit: justicefries)
  794. # [12:50] <annevk> requestFullScreenEnableKeyboard or some such
  795. # [12:50] <roc> hsivonen: well, one thing I'm thinking of is suppressing keypress, not keydown or keyup
  796. # [12:50] <othermaciej> Flash deals with this by (a) having an ugly text warning when you first enter full-screen and (b) only allowing a very limited set of keys in fullscreen mode
  797. # [12:51] <roc> annevk: ok
  798. # [12:51] <MikeSmith> kennyluck: http://blog.jclark.com/2010/01/xml-namespaces.html
  799. # [12:51] <othermaciej> hsivonen: that's a valid use case, but how do you allow it without creating the security risk of an OS simulacrum that steals your password?
  800. # [12:52] <roc> passive opt-in UI
  801. # [12:52] <MikeSmith> kennyluck: http://www.xml.com/pub/a/2005/04/13/namespace-uris.html is worth reading too (from 2005 and that article was not the first to point out the problems but it's a good summary)
  802. # [12:52] <roc> othermaciej: so if I understand correctly, webkitEnterFullScreen creates a new window showing just the video, right?
  803. # [12:52] <zcorpan_> speaking of FPS games, i wonder how to solve the problem of the mouse reaching the edge of the window
  804. # [12:53] <kennyluck> thanks, reading.
  805. # [12:53] <othermaciej> roc: are you asking about the implementation, or logically what it does?
  806. # [12:53] <MikeSmith> kennyluck: "XML Namespaces Don't Need URIs"
  807. # [12:53] <roc> the latter
  808. # [12:53] * hsivonen notes that e.g. OS X "Application foo requires you to type your password" dialog could be faked without fullscreen
  809. # [12:53] <othermaciej> roc: there is no second <video> element
  810. # [12:53] <hsivonen> but Ubuntu's can't
  811. # [12:53] <othermaciej> roc: it displays the existing <video> element fullscreen
  812. # [12:53] <othermaciej> it happens to do this by creating another fullscreen window to render to, but that's an implementation detail
  813. # [12:54] <corey__> MikeSmith, every xml namespace has a uri
  814. # [12:54] <othermaciej> if keyboard access has to be granted special permission, and regular fullscreen doesn't, then it seems like poor form to have the simpler method name be the one that enables the keyboard
  815. # [12:54] <MikeSmith> corey__: yeah, too bad
  816. # [12:54] <roc> is there documentation for webkitEnterFullScreen? http://developer.apple.com/safari/library/documentation/appleapplications/reference/WebKitDOMRef/HTMLVideoElement_idl/Classes/HTMLVideoElement/index.html is a bit sparse
  817. # [12:55] <othermaciej> anyway, we would like to generalize enterFullscreen / exitFullscreen to all elements, and we were thinking of writing a proposal, but we may just comment on yours, since it is close to what we want
  818. # [12:55] <hsivonen> I agree that the way for requesting the keyboard should look more special than the way of going fullscreen without keyboard
  819. # [12:55] <roc> othermaciej: you already did comment on mine
  820. # [12:55] <roc> well, Simon did
  821. # [12:55] <othermaciej> my only concern would be that you seem to have features that are not obviously necessary for the common use case
  822. # [12:55] <roc> we had a thread about almost this exact proposal on the whatwg list in January
  823. # [12:55] <MikeSmith> corey__: sorry I meant yeah, that's the beauty of it
  824. # [12:56] <othermaciej> well, one comment I'd give is that I think enter / exit are fine verbs, and while I have no huge problem with changing them, request/cancel don't seem obviously better
  825. # [12:56] <Philip`> zcorpan_: If it's fullscreen, that doesn't seem much of a problem - there's no browser chrome for the user to click on so there's probably no security risk in disabling their cursor, so you just disable their cursor and send mouse events with dx/dy instead of x/y
  826. # [12:56] <roc> the thing is that in my model, fullscreen transitions are asynchronous
  827. # [12:56] <othermaciej> having methods on Window instead of on elements seems pretty clearly worse (to me)
  828. # [12:56] <roc> when you call requestFullScreen, you don't necessarily get it immediately, or at all
  829. # [12:56] <MikeSmith> corey__: or, I meant No, not actually
  830. # [12:57] <roc> yes, I agree moving the methods to Element and Document make sense
  831. # [12:57] <MikeSmith> corey__: take your pick
  832. # [12:57] <othermaciej> "might not get it at all" seems weird
  833. # [12:57] <roc> it might be denied
  834. # [12:57] <corey__> MikeSmith, you are very indecisive
  835. # [12:57] <othermaciej> so the user gets prompted whether to allow fullscreen?
  836. # [12:57] <othermaciej> or are you imagining a blacklist?
  837. # [12:58] <roc> I'm imagining a passive prompt
  838. # [12:58] <roc> like we do for popups
  839. # [12:58] <othermaciej> I would say that for the common limited-keyboard case, no prompting is required
  840. # [12:58] <roc> I at least want to *allow* the UA to use a passive prompt
  841. # [12:58] <kennyluck> MikeSmith, I read the latter one before. And I think it's about the centralized vs decentralized debate.
  842. # [12:58] <annevk> if it's like popups, openFullScreen() / closeFullScreen() ?
  843. # [12:58] <othermaciej> for the full-keyboard case, I don't think a prompt would be an adequate security measure
  844. # [12:58] * annevk is just brainstorming a bit; don't pay too much attention
  845. # [12:59] <roc> it's not like popups other than that
  846. # [12:59] <roc> othermaciej: I don't think it's a good idea to design an API that's incompatible with any kind of prompting
  847. # [12:59] <othermaciej> I am dubious about implementing a version with full keyboard support (as opposed to, say, limited to space, enter, arrow keys)
  848. # [12:59] <jgraham> Is this supposed to be bound to explicit user actions?
  849. # [12:59] <roc> it can be
  850. # [12:59] <annevk> maybe full keyboard should only be for this new "installed apps" concept, if that is going to happen
  851. # [13:00] <roc> othermaciej: what about devices that don't have a keyboard? I mean, if you only have a touch screen, disabling the keyboard isn't a big security win
  852. # [13:00] <othermaciej> that makes more sense to me, if there is such a concept
  853. # [13:00] <othermaciej> yes, I was just thinking today about how to defend against OS simulacrum on touchscreen-only devices
  854. # [13:00] <jgraham> If it's not then the ability to have a prompt is essential. If it is then it still seems like a useful feature
  855. # [13:01] <Philip`> othermaciej: If FPS-style games are a use case, then you need to support at least the WASD keys
  856. # [13:01] <othermaciej> I think one of the most common use cases for this will be video that wants to go full-screen with custom controls
  857. # [13:01] <roc> I don't want to constrain the security design space here by making the API assume synchronous transitions
  858. # [13:01] <othermaciej> for that case, prompting of any form would be obnoxious
  859. # [13:01] <roc> is that so crazy?
  860. # [13:02] <roc> especially given that I want fullscreen features that work when the user explicitly commands fullscreen (F11 in Firefox), so asynchronous transitions happen anyway
  861. # [13:02] <othermaciej> I'm not saying it should assume synchronous transitions, because in any case it would be nice for the transition to animate and for the content to remain live during that
  862. # [13:02] <hsivonen> Philip`: and the WASD-equivalent Dvorak, French, etc. locations
  863. # [13:02] <roc> othermaciej: I agree about the common use case
  864. # [13:03] <othermaciej> Philip`: it might be interesting to investigate what subset of keys Flash allows
  865. # [13:03] <roc> othermaciej: is webkitEnterFullScreen documented anywhere?
  866. # [13:03] <Philip`> http://www.adobe.com/devnet/flashplayer/articles/fplayer10_security_changes_03.html#head5
  867. # [13:03] <Philip`> Not sure if that's a comprehensive list
  868. # [13:04] <othermaciej> roc: I don't really know, but I can get people to write a rough description of it (and related events) or write it myself
  869. # [13:05] <othermaciej> our HTMLVideoElement.idl documents the entry points pretty clearly, if not the details of behavior
  870. # [13:05] <othermaciej> there are also some events
  871. # [13:05] <roc> what my proposal does is just make the window fullscreen and apply a default style to the fullscreen element, if any
  872. # [13:05] <othermaciej> http://trac.webkit.org/browser/trunk/WebCore/html/HTMLVideoElement.idl
  873. # [13:06] <roc> that means that cases like fullscreening a display:none element are perfectly well defined
  874. # [13:06] <annevk> what is the default style?
  875. # [13:06] <roc> it can also integrate nicely with the fullscreen features Firefox already has
  876. # [13:06] <othermaciej> do you do anything to make the full-screened element grow to the size of the Window?
  877. # [13:07] <roc> *:full-screen { position:fixed; top:0; left:0; right:0; bottom:0; z-index:2147483647; background:black; }
  878. # [13:07] <annevk> interesting
  879. # [13:08] <zcorpan_> so by default you get black text on black background?
  880. # [13:08] <othermaciej> doing it that way is clever
  881. # [13:08] <roc> zcorpan_: only if you decide to fullscreen a DIV full of default-style text ... I don't think that's the common case
  882. # [13:09] <othermaciej> what I would imagine is that the element's bounds become the viewport, so you can't use CSS to make stuff surrounding the element appear in view through weird CSS rules
  883. # [13:09] <roc> the common case is <video>, which generally wants black
  884. # [13:09] <othermaciej> that makes it more obvious how to do a nice transition
  885. # [13:09] <hsivonen> can CSS animations provide nice transitions from an in-flow box into a position:fixed box?
  886. # [13:09] <roc> no
  887. # [13:09] <annevk> you could add color:white
  888. # [13:10] <roc> sure, but I honestly don't think it would matter :-)
  889. # [13:10] <roc> most of the transitions you might want to do require OS integration to make a window zoom out in some manner
  890. # [13:10] <Philip`> annevk: If somebody wants to fullscreen a page of text, they probably want it to stay black-on-white, so you should minimise the number of CSS properties they need to override
  891. # [13:11] <zcorpan_> i agree that full screen video should be black, but for anything else it's less clear it should be black
  892. # [13:11] <roc> with my approach you can make the style change happen immediately, snap the window to the old bounds of the element, and zoom it out to the full screen
  893. # [13:13] <roc> that transition would look good in most cases
  894. # [13:13] <roc> almost all cases, I suspect
  895. # [13:13] <Philip`> *:full-screen { position: ...; } video:full-screen { background: black; } ?
  896. # [13:13] <roc> yes
  897. # [13:13] <roc> that would work
  898. # [13:13] <othermaciej> if you are using this with custom controls, you are likely to be using an ancestor of the <video>
  899. # [13:13] <roc> although we don't want UA style sheets to get *too* clever
  900. # [13:13] <roc> othermaciej: yep
  901. # [13:14] <annevk> the flexibility it provides for is pretty great
  902. # [13:14] * Quits: wakaba_ (~wakaba_@122x221x184x68.ap122.ftth.ucom.ne.jp) (Quit: Leaving...)
  903. # [13:15] <roc> I'll make some changes, thanks for the feedback
  904. # [13:15] <othermaciej> it's not clear to me that adding a black background in fullscreen is helpful on net
  905. # [13:15] <roc> I dunno
  906. # [13:15] <roc> that's a minor detail anyway
  907. # [13:15] <annevk> yeah, me neither, but we can fiddle with those details later I suppose
  908. # [13:15] <annevk> once there's some developer feedback
  909. # [13:16] <othermaciej> I will say that our main point of feedback for enterFullscreen on <video> has been a desire for custom controls
  910. # [13:17] <roc> yes, that's essential
  911. # [13:17] <othermaciej> we have not had much direct interest in taking non-video content full-screen, but it makes sense to be fully general if you are general enough to allow custom JS-driven video controls
  912. # [13:18] <othermaciej> also one can imagine games and perhaps distraction-free apps as future use cases
  913. # [13:18] <othermaciej> or slideshows
  914. # [13:18] <roc> once you allow custom controls you have to deal with most of the security issues anyway
  915. # [13:19] <othermaciej> well, for keyboard&mouse devices at least, keyboard access is the main security risk
  916. # [13:20] <othermaciej> for touch devices, most of them have a status display at the top, so perhaps an always-on distinctive status display would be good enough
  917. # [13:20] <roc> so what would you do for touch devices?
  918. # [13:20] <roc> heh
  919. # [13:20] <othermaciej> that's the best I was able to think of
  920. # [13:20] <roc> ok
  921. # [13:20] <roc> thanks
  922. # [13:22] <jgraham> hsivonen: I am clearly still missing something. How do you cope with <table><caption><svg></caption>?
  923. # [13:24] * Joins: weinig (~weinig@c-69-181-125-223.hsd1.ca.comcast.net)
  924. # [13:24] * Quits: weinig|away (~weinig@c-69-181-125-223.hsd1.ca.comcast.net) (Read error: Connection reset by peer)
  925. # [13:25] <jgraham> It feels like it should break after the caption element is popped, but afaict it does not
  926. # [13:26] <roc> I don't really like going to requestFullScreen and requestFullScreenEnableKeys
  927. # [13:26] <roc> in the modern world it feels a bit wrong for the simple API to disable one particular input device that isn't even ubiquitous anymore
  928. # [13:27] <othermaciej> the simple API should be the one that likely does not require permission grants or pre-approval by the user
  929. # [13:27] <roc> in that case we should disable all input except the ESC key :-)
  930. # [13:27] <othermaciej> if I were designing it I'd just leave out the EnableKeys variant for v1, since Flash gets along fine without it
  931. # [13:28] <othermaciej> I think the Flash set of keys, and ESC hardcoded to always exit, is likely a pretty safe mode, at least for devices with a keyboard
  932. # [13:28] <roc> that's a big caveat
  933. # [13:29] <roc> but I'll go with this and see what people think
  934. # [13:30] <roc> oh, now I remember why I decided to have methods that take an element parameter
  935. # [13:31] <roc> it's because then I can have requestFullScreen(Element); cancelFullScreen() where cancelFullScreen takes no parameter
  936. # [13:31] <roc> so there's no confusion about what should happen if you do elem1.requestFullScreen(); elem2.cancelFullScreen();
  937. # [13:31] <roc> I suppose I can have cancelFullScreen on the Document only
  938. # [13:32] * zcorpan_ was just going to suggest that
  939. # [13:32] <othermaciej> elem1.requestFullScreen(); elem2.cancelFullScreen(); is something that is likely to arise only by mistake or in artificial test cases
  940. # [13:33] <othermaciej> or maybe I am too optimistic
  941. # [13:33] <othermaciej> anyway
  942. # [13:33] <othermaciej> I'm way overdue for some sleep, so good night folks
  943. # [13:33] * Quits: othermaciej (~mjs@c-69-181-42-237.hsd1.ca.comcast.net) (Quit: othermaciej)
  944. # [13:34] <roc> heh, it must be 5:30am there
  945. # [13:34] <jgraham> hsivonen: It seems to work OK with the html5lib test cases if you break when node is no longer in the stack of open elements after step 5
  946. # [13:34] <jgraham> hsivonen: And for the <math></html> case
  947. # [13:35] <jgraham> hsivonen: I havne't really thought about the implications of that fix though
  948. # [13:41] * Quits: MikeSmith (~MikeSmith@EM114-48-143-238.pool.e-mobile.ne.jp) (Quit: This computer has gone to sleep)
  949. # [13:43] * Joins: aroben (~aroben@unaffiliated/aroben)
  950. # [13:54] <karlcow> "<video> tag does not currently meet all the needs of a site like YouTube:" - http://apiblog.youtube.com/2010/06/flash-and-html5-tag.html implementer feedback
  951. # [13:58] * Joins: Smylers (~smylers@hns01-fw.internal.gxn.net)
  952. # [13:59] * Quits: titacgs (~titacgs@190.2.33.49) (Ping timeout: 276 seconds)
  953. # [14:03] * Quits: Rik` (~Rik`@213.41.141.234) (Quit: Rik`)
  954. # [14:09] <annevk> karlcow, you might be interested in the logs
  955. # [14:12] * Quits: asmodai (asmodai@dhammapada.xs4all.nl) (Ping timeout: 260 seconds)
  956. # [14:16] <hsivonen> karlcow: I believe that's "author feedback" from the usual point of view
  957. # [14:16] * Quits: zalan (~zalan@192.100.124.156)
  958. # [14:16] <hsivonen> usual on #whatwg that is
  959. # [14:16] * Joins: Amadiro (~whoppix@ti0021a380-dhcp1747.bb.online.no)
  960. # [14:17] * Joins: Martijnc (~Martijnc@91.176.75.59)
  961. # [14:19] * Joins: asmodai (asmodai@dhammapada.xs4all.nl)
  962. # [14:20] * Joins: taf2 (~taf2@173-13-232-33-WashingtonDC.hfc.comcastbusiness.net)
  963. # [14:23] * Joins: KaOSoFt (~maxzagato@unaffiliated/kaosoft)
  964. # [14:24] <Amadiro> Good evening. Can someone recommend a small, handy webserver or proxy that supports websockets, both the new standard (with all the fancy encryption and hanshake stuff) as well as the older formats (as older versions of chrome implement them, for instance)? I'm currently using misultin (a tiny erlang webserver w/ websocket support) as reverse proxy, but it does not support the newer revisions of the websocket protocol.
  965. # [14:24] <Amadiro> Basically, what I want to do is connect my websocket application to my server, which uses a plain TCP connection. So the gateway has to accept the websocket, and relay the connection.
  966. # [14:33] <karlcow> hsivonen: thanks
  967. # [14:34] * Quits: syp (~syp@lasigpc9.epfl.ch) (Remote host closed the connection)
  968. # [14:36] * Joins: davidb_ (~davidb@mozca02.ca.mozilla.com)
  969. # [14:37] * Quits: KaOSoFt (~maxzagato@unaffiliated/kaosoft)
  970. # [14:39] * Quits: rolandsteiner (~rolandste@220.109.219.244) (Quit: Leaving.)
  971. # [14:39] * Joins: rolandsteiner (~rolandste@220.109.219.244)
  972. # [14:41] * Quits: nessy (~Adium@124-170-165-184.dyn.iinet.net.au) (Quit: Leaving.)
  973. # [14:43] * Quits: rolandsteiner (~rolandste@220.109.219.244) (Ping timeout: 260 seconds)
  974. # [14:51] * Joins: f1lt3r (~f1lt3r@64.119.159.231)
  975. # [14:53] * Joins: BlurstOfTimes (~blurstoft@168.203.117.112)
  976. # [14:55] * Joins: erlehmann (~erlehmann@dslb-092-078-143-210.pools.arcor-ip.net)
  977. # [15:09] <annevk> why does https://wiki.mozilla.org/index.php?title=Gecko:FullScreenAPI&limit=500&action=history only show changes from today?
  978. # [15:11] <jgraham> annevk: Because it was created today?
  979. # [15:13] <annevk> ooh
  980. # [15:13] <annevk> I thought this was going on for some time
  981. # [15:14] * Joins: plainhao (~plainhao@mail.xbiotica.com)
  982. # [15:20] * Quits: mike][inq (~mike@2001:858:5:303:224:81ff:fe12:b5c4) (Remote host closed the connection)
  983. # [15:21] * Joins: mike][inq (~mike@2001:858:5:303:224:81ff:fe12:b5c4)
  984. # [15:22] * Quits: kennyluck (~kennyluck@tea04.w3.mag.keio.ac.jp) (Quit: kennyluck)
  985. # [15:24] * Joins: miketaylr (~miketaylr@38.117.156.163)
  986. # [15:33] * Joins: kamathln (~kamathln@122.167.2.77)
  987. # [15:41] <kamathln> <a href="http://appspot.com" href="http://appengine.google.com"> Appspot</a>
  988. # [15:41] * Joins: nessy (~Adium@124-170-82-66.dyn.iinet.net.au)
  989. # [15:42] <kamathln> <a href="svn://svn.something.com/something" href="http://something.com/svn"> Appspot</a>
  990. # [15:44] <kamathln> <a href="htt://mylinux.dyndns.org" href="http://myblog.com/LapppyNotReachable"> Me :-)</a>
  991. # [15:44] <kamathln> what say
  992. # [15:44] <kamathln> ?
  993. # [15:44] <kamathln> alternate hrefs when the orig hrefs go bad
  994. # [15:46] <annevk> unlikely I'd say
  995. # [15:46] <kamathln> annevk: in what way
  996. # [15:46] <annevk> on a basic level it's incompatible with the HTML parser and the DOM
  997. # [15:47] <annevk> and it's not really clear there's a real need for it
  998. # [15:47] <annevk> I suggest reading through http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F
  999. # [15:48] <kamathln> I am only discussing here .. more than just for when things become unreachable, I want the browsers to be able to handle when they dont know how to handle a rotocol
  1000. # [15:48] <kamathln> protocol*
  1001. # [15:48] <kamathln> eg: svn protocol there
  1002. # [15:48] <kamathln> <a href="htt://mylinux.dyndns.org" href="http://myblog.com/LapppyNotReachable"> Me :-)</a>
  1003. # [15:49] <kamathln> whups not that
  1004. # [15:49] <kamathln> <a href="svn://svn.something.com/something" href="http://something.com/svn"> Appspot</a>
  1005. # [15:49] <kamathln> that one
  1006. # [15:49] <Amadiro> kamathln, so if the browser doesn't understand the svn:// protocol, it can use the alternative link?
  1007. # [15:49] <kamathln> Amadiro: yes, thats the idea
  1008. # [15:49] <Amadiro> (Does any browser understand the svn protocol?)
  1009. # [15:49] <Peter`> wondering; there's registerProtocolHandler now, is there some kind of isProtocolKnown method?
  1010. # [15:50] <Amadiro> kamathln, I kinda like the idea, I have to say
  1011. # [15:50] <kamathln> Peter`: that would require Javascript right?
  1012. # [15:50] <Peter`> Yes
  1013. # [15:50] <kamathln> or at least some dynamic scripting
  1014. # [15:50] <annevk> Peter`, there's no infrastructure around it, no
  1015. # [15:50] <annevk> Peter`, not really clear that's needed
  1016. # [15:50] <kamathln> with alternate linking, it need not even be dynamic
  1017. # [15:51] <Peter`> annevk: I haven't thought of any use-cases or whatsoever, was mostly wondering
  1018. # [15:53] <Amadiro> kamathln, I'd imagine the browser would display a message ala "This location is not available because $reason, the website suggests to visit $alternative_link instead"
  1019. # [15:55] <kamathln> Amadiro: hmm, that would be possible as well. I Think I should have used the wordings "it *need not* be dynamic"
  1020. # [15:56] <kamathln> non-dynamic fallback usefull when you are using resources from alternative sites
  1021. # [15:57] <kamathln> from mysite1 : <img src="http://mysite2.com/kamathln/1.jpg" alt_src="http://mysite3..com/kamathln/1.jpg">
  1022. # [16:00] <kamathln> programmers can think of this as a minimalistic try(){}catch(){}
  1023. # [16:00] <kamathln> :)
  1024. # [16:03] * Joins: yutak_home (~kee@U017209.ppp.dion.ne.jp)
  1025. # [16:05] <TabAtkins> That only gives you two sources, though - even better would be to leverage CSS and the image() function (when it's supported), like <img src=foo style="content: contents, image(bar, baz, qux);">. That'll try each of the four images in turn.
  1026. # [16:06] <kamathln> TabAtkins: I have been thinking about the problem.. There must be a way to specify any number of URLs
  1027. # [16:06] <TabAtkins> There is. I just gave one.
  1028. # [16:07] <TabAtkins> It just so happens that nobody implements that part of CSS yet.
  1029. # [16:07] <kamathln> TabAtkins: that would work only for the IMG problem .. what about a href , js and css srcs ?
  1030. # [16:07] <TabAtkins> Then it indeed would not work.
  1031. # [16:07] <kamathln> and now, audio and video ..
  1032. # [16:07] <kamathln> exactly ..
  1033. # [16:08] <zcorpan_> kamathln: audio and video support multiple fallbacks already
  1034. # [16:09] <kamathln> zcorpan_: Oh yeah! then it would be (sort of) shamefull to not have them for anywhere we need to specify hrefs and srcs
  1035. # [16:09] * kamathln starts groping for audio and video documentation to find how its implemented
  1036. # [16:10] <zcorpan_> i don't see why we'd want to support fallbacks everywhere
  1037. # [16:13] <kamathln> zcorpan_: did you login after I started to chat ? I already gave 3 usecases .. 1)general unaivalability of the page, 2)unaivalability of a domain providing a resource, and 3) inability of a browser to handle a special protocol (like svn, I guess)
  1038. # [16:13] <annevk> they're very minor
  1039. # [16:14] <annevk> and most can be checked beforehand by the page provider providing an even better user experience
  1040. # [16:14] <zcorpan_> what would a browser do with an svn: link?
  1041. # [16:14] <annevk> TabAtkins, not really convinced that image() proposal is a good idea to be honest
  1042. # [16:14] <kamathln> launch tortoissvn?
  1043. # [16:14] <kamathln> tortoisesvn?
  1044. # [16:15] <zcorpan_> what's the use case for that?
  1045. # [16:16] <zcorpan_> i'd rather have svn: urls written in plain text so i can copy it and paste it into my terminal or a script
  1046. # [16:18] <zcorpan_> for 1), if there's reason to believe a page will become unavailable, and you have a backup page that is not unavailable, why not just link to the backup page directly?
  1047. # [16:19] <kamathln> irc:// xmpp:// lastfm:// webcal:// .. etc..
  1048. # [16:19] <kamathln> svn was just one example
  1049. # [16:19] <zcorpan_> what would you fall back to for those?
  1050. # [16:19] <kamathln> webclients
  1051. # [16:20] <annevk> (besides, only 0.0000000001% or so of all links fall in that category)
  1052. # [16:20] * Joins: ttepasse (~ttepasse@ip-109-90-160-217.unitymediagroup.de)
  1053. # [16:20] <Philip`> zcorpan_: You may believe the backup page will become unavailable too, and more frequently than the original page, but rarely at the same time
  1054. # [16:20] <zcorpan_> why not provide two links? some users might prefer the web client over the native app
  1055. # [16:20] * Quits: annevk (~annevk@5355737B.cable.casema.nl) (Read error: Connection reset by peer)
  1056. # [16:20] * Joins: annevk (~annevk@5355737B.cable.casema.nl)
  1057. # [16:21] * kamathln wears a second thinking cap
  1058. # [16:22] <zcorpan_> Philip`: fair enough. however i haven't seen anyone work around this limitation so i'm not convinced it's a problem that needs solving
  1059. # [16:22] <doublec> zcorpan_, video and audio don't have fallback in the case of the resource being unavailable - which is what I think kamathln was wanting
  1060. # [16:23] <zcorpan_> doublec: sure it does
  1061. # [16:23] <zcorpan_> doublec: if a video is not available, the next <source> is tried
  1062. # [16:24] <kamathln> why would you provide it for video, and not img ? I still dont get.
  1063. # [16:24] <zcorpan_> that's not the problem <source> was intended to solve, but it does as a side effect
  1064. # [16:24] <kamathln> zcorpan_: oh okies
  1065. # [16:24] <Philip`> zcorpan_: I guess the common case is that you own both the linker and linkee and run them on the same server, so if it's down then it doesn't matter what links you write; or the linker and linkee are different people, and the linker doesn't know enough about the linkee's backup/mirroring/update strategy to sensibly link to multiple URLs
  1066. # [16:25] <doublec> zcorpan_, erm, I don't think it does
  1067. # [16:25] <doublec> zcorpan_, if the resource fails to load then an error is raised
  1068. # [16:26] <TabAtkins> annevk: image() in general, or just for this use-case? image() is just wrapping up the behavior of the "content" property in a more general fashion for images themselves.
  1069. # [16:26] <zcorpan_> doublec: could you point to the relevant part of the spec that says so?
  1070. # [16:26] <doublec> zcorpan_, 4.8.10.5
  1071. # [16:27] <doublec> although it appears to have changed a lot since I last read it
  1072. # [16:27] * doublec double checks
  1073. # [16:27] <zcorpan_> "⌛ If absolute URL was not obtained successfully, then end the synchronous section, and jump down to the failed step below."
  1074. # [16:28] <zcorpan_> "⌛ If the node after pointer is a source element, let candidate be that element."
  1075. # [16:29] <zcorpan_> "⌛ If candidate is null, jump back to the search loop step. Otherwise, jump back to the process candidate step."
  1076. # [16:30] * Quits: pauld (~chatzilla@194.102.13.2) (Ping timeout: 265 seconds)
  1077. # [16:30] <paul_irish> miketaylr: really? shorturl+fragment was working fine for me. it broke something? :(
  1078. # [16:31] <doublec> what does "If absolute URL was not obtained successfully" mean?
  1079. # [16:31] <miketaylr> paul_irish: ?
  1080. # [16:32] <doublec> It's really this bit we're talking about, right? "Run the resource fetch algorithm with absolute URL. If that algorithm returns without aborting this one, then the load failed. "
  1081. # [16:34] <doublec> yeah it looks like you're right zcorpan_
  1082. # [16:34] <zcorpan_> doublec: what you quoted is about <video src="">, not <source>
  1083. # [16:35] <doublec> zcorpan_, no what I quoted is also in the "Otherwise, the source elements will be used; run these substeps:" section
  1084. # [16:35] <zcorpan_> oh sorry
  1085. # [16:35] <doublec> it seems hard to refer to parts of the spec in this area
  1086. # [16:36] <doublec> lots of numbered steps and parts without subheadings
  1087. # [16:36] * Quits: kamathln (~kamathln@122.167.2.77) (Quit: whups .. distracted by me finished kernel compile.. c ya later)
  1088. # [16:37] <doublec> the resource fetch algorithm lumps 4XX errors in the same class as unsupported media which is where it confirms what you are saying I think
  1089. # [16:37] <doublec> http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#concept-media-load-resource
  1090. # [16:37] <zcorpan_> doublec: so if it isn't aborted (because the load failed), then the next step is run which will process the next <source>
  1091. # [16:37] <doublec> yep
  1092. # [16:38] <doublec> lucky I didn't work on the resource selection/loading part of our implementation
  1093. # [16:38] <doublec> :)
  1094. # [16:40] * Joins: pauld (~chatzilla@194.102.13.2)
  1095. # [16:40] <paul_irish> miketaylr: wrong mike. :)
  1096. # [16:41] <miketaylr> so many mikes!
  1097. # [16:41] <zcorpan_> firefox fails 28 out of my 35 resource selection tests
  1098. # [16:43] <zcorpan_> opera fails 4, chrome fails 28
  1099. # [16:45] * Joins: no_mind (~orion@122.161.34.125)
  1100. # [16:45] <no_mind> is there any attempt or demo or displaying streaming video under html5 <video> tag ?
  1101. # [16:45] * Quits: yutak_home (~kee@U017209.ppp.dion.ne.jp) (Quit: Ex-Chat)
  1102. # [16:48] <doublec> zcorpan_, where are your tests?
  1103. # [16:49] * Joins: justicefries (~gerred@c-98-245-71-126.hsd1.co.comcast.net)
  1104. # [16:49] * Quits: justicefries (~gerred@c-98-245-71-126.hsd1.co.comcast.net) (Client Quit)
  1105. # [16:49] <doublec> zcorpan_, no doubt bug 485288 https://bugzilla.mozilla.org/show_bug.cgi?id=485288
  1106. # [16:50] <zcorpan_> doublec: not public yet :(
  1107. # [16:51] * Quits: henrikbjorn (~hb@80.199.116.190.static.peytz.dk) (Remote host closed the connection)
  1108. # [16:52] * Quits: karlcow (~karl@nerval.la-grange.net) (Quit: Freedom - to walk free and own no superior.)
  1109. # [16:52] * Joins: karlcow (~karl@nerval.la-grange.net)
  1110. # [16:53] <annevk> TabAtkins, image() in general I think; I don't really believe in fallback too much
  1111. # [16:53] <TabAtkins> Ah, ok.
  1112. # [16:53] <annevk> that it works and is used in practice, that is
  1113. # [16:54] * Quits: nessy (~Adium@124-170-82-66.dyn.iinet.net.au) (Quit: Leaving.)
  1114. # [16:54] <annevk> it's definitely way too small a thing to hit 80/20 in general
  1115. # [16:55] <annevk> (media might be slightly different, but even there it is mostly because the format situation is fucked up, not because fallback is needed in general)
  1116. # [16:58] <TabAtkins> Hm, maybe.
  1117. # [16:58] * Joins: everton (~everton@KD118153063184.ppp-bb.dion.ne.jp)
  1118. # [16:59] <TabAtkins> I do like the ability to fallback to a color, though.
  1119. # [17:00] <annevk> how often do you see images not load?
  1120. # [17:00] <TabAtkins> When I specifically know that my text won't be legible on the underlying background and am relying on an image to provide the proper color contrast, but the image is partially transparent so I can't just pair it with a background-color.
  1121. # [17:00] <annevk> when we get SPDY it's even less likely you'll notice delay by images
  1122. # [17:01] <annevk> it's just way too much into theoretical space
  1123. # [17:01] <annevk> there's a lot of other things we could tackle instead
  1124. # [17:01] <TabAtkins> Certainly.
  1125. # [17:01] * Quits: ROBOd (~robod@92.86.245.3) (Ping timeout: 265 seconds)
  1126. # [17:01] <zcorpan_> TabAtkins: text-shadow? :)
  1127. # [17:02] <TabAtkins> zcorpan_: That only works if you *want* a shadow.
  1128. # [17:02] <annevk> that images are not loading is not something that happens nowadays though
  1129. # [17:02] <annevk> maybe in the nineties
  1130. # [17:03] <TabAtkins> I've had broken images sit around on my sites before. ^_^
  1131. # [17:03] <TabAtkins> Though, to be fair, that stopped happening as soon as I hooked up an email script to my 404 page.
  1132. # [17:03] <TabAtkins> And if an author is smart enough to know that they need fallback, they're smart enough to make their 404 page email them too.
  1133. # [17:03] <annevk> cnn.com would be a fair example (especially if their developers want to tackle the issue)
  1134. # [17:04] <annevk> your own site not so much
  1135. # [17:04] * Quits: maikmerten (~merten@ls5dhcp196.cs.uni-dortmund.de) (Quit: Verlassend)
  1136. # [17:04] <annevk> lets be at least a little pragmatic here :)
  1137. # [17:04] <TabAtkins> I meant "a company site that I managed as the webmaster".
  1138. # [17:04] * Quits: Maurice (~ano@a80-101-46-164.adsl.xs4all.nl) (Quit: Disconnected...)
  1139. # [17:06] * Parts: zcorpan_ (~zcorpan@c-1799e355.410-6-64736c14.cust.bredbandsbolaget.se)
  1140. # [17:08] * Joins: zcorpan_ (~zcorpan@c-1799e355.410-6-64736c14.cust.bredbandsbolaget.se)
  1141. # [17:09] * Quits: mpt (~mpt@canonical/mpt) (Ping timeout: 245 seconds)
  1142. # [17:09] <annevk> things that seem more relevant for the CSS WG to tackle: <meta name=viewport>, fullscreen API, gradients, form control styling, ...
  1143. # [17:09] <annevk> also a lot more important
  1144. # [17:10] <hsivonen> hmm. Nokia announces an XForms client for J2ME
  1145. # [17:10] <annevk> we're now implementing this border-image thing which has become quite the complexity while form controls are still not figured out, while the table model is still undefined...
  1146. # [17:10] * Quits: eighty4 (~eighty4@h-112-7.A163.corp.bahnhof.se) (Remote host closed the connection)
  1147. # [17:10] <annevk> the priorities are way wrong imo
  1148. # [17:11] * Joins: boazsender (~boazsende@77.sub-75-238-117.myvzw.com)
  1149. # [17:11] <hsivonen> https://projects.forum.nokia.com/XFormsJ2ME
  1150. # [17:13] <annevk> Symbian, J2ME, Maemo, ... where are they going?
  1151. # [17:15] <hsivonen> annevk: looks like they are trying to keep all three for different market segments
  1152. # [17:15] <hsivonen> but why XForms for any of the market segments? and why now?
  1153. # [17:15] <TabAtkins> annevk: Dude, start kicking some asses then. You never talk about any of this stuff on the list or in meetings. I get easily distracted by shiny new things.
  1154. # [17:18] <annevk> TabAtkins, heh, I certainly try, but it's not really working
  1155. # [17:18] <annevk> TabAtkins, also, I haven't found much time to work on CSS stuff other than CSSOM
  1156. # [17:18] <TabAtkins> I haven't seen much trying. ^_^
  1157. # [17:19] <TabAtkins> Yeah, granted.
  1158. # [17:21] * Quits: mhausenblas (~mhausenbl@wg1-nat.fwgal01.deri.ie) (Quit: mhausenblas)
  1159. # [17:22] * Joins: johnst (~johnst@x1-6-00-07-95-57-08-bb.k479.webspeed.dk)
  1160. # [17:24] <TabAtkins> Um, does anyone implement a box-shadow-style property?
  1161. # [17:24] * TabAtkins doesn't think so.
  1162. # [17:24] * Quits: f1lt3r (~f1lt3r@64.119.159.231) (Read error: Operation timed out)
  1163. # [17:25] * Quits: riven (~riven@53518387.cable.casema.nl) (Read error: Connection reset by peer)
  1164. # [17:25] * Joins: riven (~riven@53518387.cable.casema.nl)
  1165. # [17:25] * Joins: f1lt3r (~f1lt3r@64.119.159.231)
  1166. # [17:26] * Joins: dglazkov (~dglazkov@nat/google/x-pkybgguylhczhewx)
  1167. # [17:30] * Joins: dbaron (~dbaron@c-98-234-51-190.hsd1.ca.comcast.net)
  1168. # [17:30] * Quits: svl (~chatzilla@a194-109-2-65.dmn.xs4all.nl) (Quit: And back he spurred like a madman, shrieking a curse to the sky!)
  1169. # [17:30] <annevk> TabAtkins, I haven't done it much recently, but it's also quite hard
  1170. # [17:31] * Quits: f1lt3r (~f1lt3r@64.119.159.231) (Ping timeout: 260 seconds)
  1171. # [17:31] <Peter`> TabAtkins: sorry, meant box-shadow by itself
  1172. # [17:33] <TabAtkins> Ah, that Peter is you?
  1173. # [17:33] <Peter`> Yes
  1174. # [17:33] <Peter`> I overlooked the fact that border-radius is in fact a shorthand method
  1175. # [17:34] <TabAtkins> Heh, I actually forgot about that too. I only ever use the shorthand.
  1176. # [17:34] <TabAtkins> (Though that's partially because of the mismatch between subproperty names between webkit and gecko.)
  1177. # [17:34] * TabAtkins doesn't know if that's been fixed yet.
  1178. # [17:35] <Peter`> Same here, indeed :-)
  1179. # [17:35] <TabAtkins> Also, remember that you can do multiple shadows right now by just specifying multiple shadows comma-separated.
  1180. # [17:36] <Peter`> I didn't know that, thanks! I'll do some experimenting with it. I do remember seeing some fancy coloured shadow-examples which didn't immediately make sense -they do now-.
  1181. # [17:42] * Joins: eighty4 (~eighty4@c-76c8e455.012-403-6c6b701.cust.bredbandsbolaget.se)
  1182. # [17:46] * Joins: jgornick (~joe@199.199.212.242)
  1183. # [17:57] * Joins: mpt (~mpt@canonical/mpt)
  1184. # [17:58] * Joins: nimbupani (~nimbupani@c-24-22-131-46.hsd1.wa.comcast.net)
  1185. # [18:09] * Quits: akamike (~akamike@94-193-106-14.zone7.bethere.co.uk) (Quit: akamike)
  1186. # [18:09] * Joins: ROBOd (~robod@92.86.245.3)
  1187. # [18:10] * Quits: jlebar (~jlebar@63.245.220.220) (Ping timeout: 264 seconds)
  1188. # [18:10] * Joins: yoshiaki (~yoshiaki@p17160-ipngn2001marunouchi.tokyo.ocn.ne.jp)
  1189. # [18:11] * Joins: mmn (~mmn@129-97-225-230.uwaterloo.ca)
  1190. # [18:13] <TabAtkins> Hixie: Webkit is implementing dataset right now, and uncovered a spec bug. I've emailed whatwg about it, and would appreciate a quick response.
  1191. # [18:14] * Quits: weinig (~weinig@c-69-181-125-223.hsd1.ca.comcast.net) (Quit: weinig)
  1192. # [18:15] <Philip`> TabAtkins: Why do you think there's a problem?
  1193. # [18:16] <Philip`> The part you cut out of the quote says the attribute name needs to be XML-compatible too
  1194. # [18:16] <Philip`> and the processing algorithm ignores that too
  1195. # [18:17] <Philip`> (i.e. empty and/or XML-incompatible names aren't allowed but will be extracted by the algorithm)
  1196. # [18:17] * Quits: Smylers (~smylers@hns01-fw.internal.gxn.net) (Ping timeout: 265 seconds)
  1197. # [18:18] <TabAtkins> Well, it doesn't gain us anything to process <div data-=foo>, since there isn't anything on the web that depends on it. Might as well align author and impl requirements here.
  1198. # [18:18] * Quits: Lachy (~Lachlan@pat-tdc.opera.com) (Quit: This computer has gone to sleep)
  1199. # [18:19] <Philip`> Do you want to align to the XML-compatible requirement too?
  1200. # [18:22] <TabAtkins> Maybe, though I'd be equally happy to drop that requirement.
  1201. # [18:23] * Joins: jlebar (~jlebar@nat/mozilla/x-gzwziojwenespnul)
  1202. # [18:23] * Quits: ZombieLoffe (~e@unaffiliated/zombieloffe)
  1203. # [18:27] <jgraham> The empty string case is confusing
  1204. # [18:27] <jgraham> So that shouldn't work, I think
  1205. # [18:29] <TabAtkins> We're already verifying that the name doesn't include any capital letters, so I suspect it's not overly a burden to verify that it only contains characters in the xml-compatible range.
  1206. # [18:29] <TabAtkins> (http://www.w3.org/TR/REC-xml/#NT-NameStartChar and NameChar)
  1207. # [18:29] <annevk> that seems like overkill
  1208. # [18:30] <TabAtkins> Possibly, yeah, so I'm not against ignoring that.
  1209. # [18:30] * Joins: dave_levin (~dave_levi@nat/google/x-ilctcarytinxgdnv)
  1210. # [18:31] * Quits: taf2 (~taf2@173-13-232-33-WashingtonDC.hfc.comcastbusiness.net) (Quit: taf2)
  1211. # [18:31] <annevk> I don't really see why author and user agent requirements need to be aligned here
  1212. # [18:32] <Philip`> TabAtkins: Do you want http://www.w3.org/TR/REC-xml/#NT-NameChar or http://www.w3.org/TR/2006/REC-xml-20060816/#NT-Name ?
  1213. # [18:32] * Quits: Phae (~Phae@chimera.macmillan.com) (Quit: Leaving.)
  1214. # [18:32] <Philip`> TabAtkins: by which I mean, I'd personally be happy to not have to care and instead to allow anything
  1215. # [18:32] <TabAtkins> I linked to the one that HTML5 does, which is the extent of my caring.
  1216. # [18:32] <jgraham> I think it only makes sense to allow anything, not to only process XML-compatible names
  1217. # [18:33] <jgraham> Down that path lies madness
  1218. # [18:34] <Philip`> Down that path lies a lot of work writing test cases and filing bugs, for no benefit to anybody
  1219. # [18:34] <TabAtkins> That's cool with me.
  1220. # [18:34] <jgraham> But dropping the processing of empty names seems fine
  1221. # [18:34] <TabAtkins> I'm also cool with changing the author conformance to say that "data-" is valid.
  1222. # [18:34] <jgraham> I see no benefit to processing them
  1223. # [18:34] <jgraham> and allowing them would be weird
  1224. # [18:36] <Philip`> If you don't process "data-", then should the name-setting algorithm throw an exception on dataset[""] = "foo"?
  1225. # [18:36] <Philip`> to avoid losing the (I think) guaranteed roundtripping
  1226. # [18:36] <TabAtkins> If we did restrict it, then yes.
  1227. # [18:37] <jgraham> It could just silently ignore it
  1228. # [18:37] <jgraham> That would be The ECMAScript Way (TM)
  1229. # [18:37] * Joins: Maurice (copyman@5ED573FA.cable.ziggo.nl)
  1230. # [18:38] <jgraham> (but sure, throwing INVALID_ARGUMENTS_ERROR or whatever it's called seems fine)
  1231. # [18:38] <Philip`> It should silently ignore dataset["-A"] too, instead of throwing like that?
  1232. # [18:38] <Philip`> (in your proposed Way (TM))
  1233. # [18:39] <Philip`> s/like that/like it does now/
  1234. # [18:39] <TabAtkins> Obviously we should match everything one way or another. ^_^
  1235. # [18:39] <jgraham> Philip`: I have no idea what it does now, and would mildly prefer throwing to ignoring
  1236. # [18:40] * TabAtkins sighs.
  1237. # [18:41] <TabAtkins> I wish XML weren't so stupid.
  1238. # [18:41] <annevk> http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0334.html -- I guess with some people "URIs" is some kind of gut reaction to problems :/
  1239. # [18:41] <jgraham> TabAtkins: Blame Tim Bray
  1240. # [18:41] <TabAtkins> I will!
  1241. # [18:41] <jgraham> Since everyone has the (somewhat inaccurate) idea he is the Father of XML
  1242. # [18:42] <TabAtkins> Argh, he's work-at-home. So I can't bug him on campus.
  1243. # [18:42] <annevk> implement XML5 in Chrome
  1244. # [18:42] <annevk> it's much saner
  1245. # [18:44] * Quits: aroben (~aroben@unaffiliated/aroben) (Quit: Leaving)
  1246. # [18:44] <jgraham> TabAtkins: You could wait 'till he next visits and follow him home
  1247. # [18:44] * Joins: aroben (~aroben@c-71-58-77-15.hsd1.pa.comcast.net)
  1248. # [18:44] * Quits: aroben (~aroben@c-71-58-77-15.hsd1.pa.comcast.net) (Changing host)
  1249. # [18:44] * Joins: aroben (~aroben@unaffiliated/aroben)
  1250. # [18:44] <jgraham> and then ring on his doorbeel at three in the morning
  1251. # [18:44] <jgraham> and hide out in his bins
  1252. # [18:44] <TabAtkins> jgraham: Brilliant!
  1253. # [18:45] * Joins: maikmerten (~maikmerte@port-92-201-89-70.dynamic.qsc.de)
  1254. # [18:45] <TabAtkins> annevk: XML5 being backwards compatible means that a substantial bit of craziness is still present, right?
  1255. # [18:45] <TabAtkins> Like the namechar restrictions?
  1256. # [18:46] <annevk> those are gone, for instance
  1257. # [18:46] <TabAtkins> So it's somewhat backwards compatible?
  1258. # [18:46] <annevk> there's no need for arbitrary restrictions to stay compatible with well-formed content
  1259. # [18:46] <TabAtkins> kk
  1260. # [18:47] <TabAtkins> Ah, so XML5 processors read XML1 content, but not the other way round. Got it.
  1261. # [18:47] <jgraham> The doctype madness is still there iirc
  1262. # [18:47] <jgraham> (I mean it has to be)
  1263. # [18:47] <annevk> TabAtkins, depends on how you craft your XML5 content, yup
  1264. # [18:47] <TabAtkins> Yeah, of course.
  1265. # [18:47] * TabAtkins wants something even simpler. Screw backwards compatibility.
  1266. # [18:47] <annevk> jgraham, yes, it's about half the complexity of the tokenizer (or the whole parser, really)
  1267. # [18:48] * Joins: tndH (~Rob@cpc5-seac20-2-0-cust394.7-2.cable.virginmedia.com)
  1268. # [18:48] <annevk> TabAtkins, I don't think you can get much simpler (apart from taking out all the DOCTYPE states) while still having the expressiveness of the DOM
  1269. # [18:49] <TabAtkins> I should actually look at XML5 before declaring it not-simple-enough.
  1270. # [18:50] <Philip`> It seems quite common to implement XML parsers that don't support internal subsets
  1271. # [18:51] <Philip`> so there'd probably be demand for a spec that isn't entirely backward-compatible in that way
  1272. # [18:52] * Quits: boblet (~boblet@p1201-ipbf709osakakita.osaka.ocn.ne.jp) (Quit: boblet)
  1273. # [18:52] * Joins: svl (~me@ip565744a7.direct-adsl.nl)
  1274. # [18:53] * Quits: yoshiaki (~yoshiaki@p17160-ipngn2001marunouchi.tokyo.ocn.ne.jp) (Remote host closed the connection)
  1275. # [18:58] <TabAtkins> Oof, the PI and DOCTYPE stuff really is the majority of the parser.
  1276. # [18:59] <TabAtkins> Ignoring those two groups, there are only 22 states.
  1277. # [18:59] <TabAtkins> (And about half of *those* are just dealing with comments and CDATA.)
  1278. # [19:00] <TabAtkins> Well, a third. Looks like 7 or 8 states devoted to those two.
  1279. # [19:01] <zcorpan_> TabAtkins: you want XML5 but without PI, doctype, comment and CDATA?
  1280. # [19:02] <TabAtkins> That'd be nice, yeah.
  1281. # [19:02] <TabAtkins> Though comments are useful enough that I can accept those in there.
  1282. # [19:03] <jgraham> CDATA seems pretty useful
  1283. # [19:03] <jgraham> PI not so much
  1284. # [19:03] <jgraham> (pity about the CDATA syntax, really)
  1285. # [19:04] * Quits: pauld (~chatzilla@194.102.13.2) (Ping timeout: 265 seconds)
  1286. # [19:06] <TabAtkins> annevk: If I'm reading the comment states correctly, the intention is that <!-- and --> are actual comment start/end, and -- inside of them is just treated as characters?
  1287. # [19:06] <annevk> yeah
  1288. # [19:06] <TabAtkins> Cool.
  1289. # [19:10] <TabAtkins> And all the doctype and pi states are solely to consume doctypes, not do anything with them?
  1290. # [19:11] <TabAtkins> jgraham: is CDATA very useful? I really don't know - I just use <style> and <script> without worrying about the fact that they might contain things that look disturbingly like markup.
  1291. # [19:11] <annevk> DOCTYPEs are processed actually
  1292. # [19:11] <TabAtkins> I just assume the rest is magic.
  1293. # [19:11] <annevk> to support entity references
  1294. # [19:11] <annevk> and such nonsense
  1295. # [19:11] <annevk> PIs are put in the DOM
  1296. # [19:11] <TabAtkins> Ah, yeah, I see the PI part.
  1297. # [19:11] * Quits: adactio (~adactio@host213-123-197-180.in-addr.btopenworld.com) (Quit: adactio)
  1298. # [19:11] <TabAtkins> I just skimmed the doctype states, so must have missed where they were actually parsed.
  1299. # [19:12] <annevk> large parts of it are ignored
  1300. # [19:12] <annevk> and are just about correctly processing them
  1301. # [19:12] <annevk> but some parts are taken into consideration
  1302. # [19:12] <jgraham> TabAtkins: In XML is guess it is useful
  1303. # [19:12] * Joins: KaOSoFt (~maxzagato@190.24.156.162)
  1304. # [19:12] * Quits: KaOSoFt (~maxzagato@190.24.156.162) (Changing host)
  1305. # [19:12] * Joins: KaOSoFt (~maxzagato@unaffiliated/kaosoft)
  1306. # [19:12] <jgraham> I mean it is confusing if you can't do if (1<b) in your script
  1307. # [19:12] <TabAtkins> jgraham: Presumably so you can do the script/style magic without having to know that the elements are magic beforehand?
  1308. # [19:13] <jgraham> Yeah
  1309. # [19:13] <TabAtkins> Makes sense.
  1310. # [19:14] <TabAtkins> Though it should be even more explicit - it's too easy to get a nested array-reference in a numeric comparison and fake out the cdata-end state. ^_^
  1311. # [19:16] * Quits: mpt (~mpt@canonical/mpt) (Ping timeout: 240 seconds)
  1312. # [19:17] <annevk> you can just do &lt;
  1313. # [19:17] <annevk> works fine
  1314. # [19:18] <TabAtkins> There is no way I'm writing |if(a[b[c]]&lt;42) {...}|
  1315. # [19:18] <annevk> you rather write <![CDATA[ crap?
  1316. # [19:19] <annevk> to each his own I suppose
  1317. # [19:19] <annevk> but my way requires less states :p
  1318. # [19:19] <TabAtkins> If I'm handwriting? Yeah.
  1319. # [19:19] * TabAtkins supposes he could just avoid directly embedding non-XML languages in an xml document.
  1320. # [19:21] * Joins: gratz|home (~gratz@cpc3-brig15-2-0-cust237.3-3.cable.virginmedia.com)
  1321. # [19:22] * TabAtkins would enjoy a language with only &lt; and &quot; as entities.
  1322. # [19:22] * Joins: mlpug (~mlpug@a88-115-164-40.elisa-laajakaista.fi)
  1323. # [19:23] <zcorpan_> and &amp;?
  1324. # [19:24] * Joins: maikmerten_ (~maikmerte@port-92-201-177-35.dynamic.qsc.de)
  1325. # [19:24] <TabAtkins> Right, yes.
  1326. # [19:25] * TabAtkins would like to find a way to avoid that, too.
  1327. # [19:26] * Quits: maikmerten (~maikmerte@port-92-201-89-70.dynamic.qsc.de) (Ping timeout: 245 seconds)
  1328. # [19:26] * Quits: KaOSoFt (~maxzagato@unaffiliated/kaosoft)
  1329. # [19:27] * zcorpan_ finds an srt with <b><font color="#00afad">Join us on Facebook !
  1330. # [19:27] * zcorpan_ Squadra Dell'Ombra</font></b>
  1331. # [19:27] * Quits: tc_ (~travis@rrcs-67-78-243-170.se.biz.rr.com) (Ping timeout: 252 seconds)
  1332. # [19:27] <zcorpan_> Hixie: ^
  1333. # [19:27] * Joins: KaOSoFt (~maxzagato@190.24.156.162)
  1334. # [19:27] * Quits: KaOSoFt (~maxzagato@190.24.156.162) (Changing host)
  1335. # [19:27] * Joins: KaOSoFt (~maxzagato@unaffiliated/kaosoft)
  1336. # [19:28] * Joins: deepthawtz (~deepthawt@c-24-130-129-16.hsd1.ca.comcast.net)
  1337. # [19:30] * Joins: mpt (~mpt@canonical/mpt)
  1338. # [19:33] <zcorpan_> Hixie: http://www.tvsubtitles.net/subtitle-132566.html has <i>Et maintenant "Les transcroyables
  1339. # [19:33] <zcorpan_> exploits de Zapp Brannigan"
  1340. # [19:33] <zcorpan_> (i.e. unclosed <i>
  1341. # [19:33] <zcorpan_> )
  1342. # [19:33] * Joins: weinig (~weinig@17.246.19.126)
  1343. # [19:34] <Hixie> zcorpan_: i'm intentionally not going to be supporting attributes at this point
  1344. # [19:34] <Hixie> zcorpan_: and will support unclosed <i>s
  1345. # [19:36] <zcorpan_> Hixie: it was just the first srt i found with <b>
  1346. # [19:36] <Hixie> ah
  1347. # [19:36] <zcorpan_> {\pos(192,240)}On a des photos.
  1348. # [19:36] <zcorpan_> http://www.tvsubtitles.net/subtitle-132551.html
  1349. # [19:37] <zcorpan_> <i>{\a6}TY,
  1350. # [19:37] <zcorpan_> L'ASSISTANT DU CORONER</i>
  1351. # [19:39] <Hixie> wow, i wonder what UA supports that
  1352. # [19:46] * Joins: kennyluck (~kennyluck@EM111-188-56-222.pool.e-mobile.ne.jp)
  1353. # [19:46] <zcorpan_> VLC doesn't support it
  1354. # [19:46] * Quits: KaOSoFt (~maxzagato@unaffiliated/kaosoft)
  1355. # [19:50] <annevk> hmm, VLC is pretty good usually
  1356. # [19:50] <Hixie> TabAtkins: you're e-mail confuses authoring criteria with implementation requirements, there's no ambiguity
  1357. # [19:51] * Quits: weinig (~weinig@17.246.19.126) (Quit: weinig)
  1358. # [19:51] * Joins: tc_ (~travis@rrcs-67-78-243-170.se.biz.rr.com)
  1359. # [20:00] * Joins: weinig (~weinig@17.246.19.126)
  1360. # [20:00] <zcorpan_> MPlayer seems to support {\pos(192,240)}
  1361. # [20:01] <zcorpan_> and ignores {\a6}, or replaces it with a space or something
  1362. # [20:04] <Hixie> (um, s/you're/your/)
  1363. # [20:05] * Quits: smaug (~chatzilla@cs181150024.pp.htv.fi) (Ping timeout: 252 seconds)
  1364. # [20:09] * Joins: jwalden (~waldo@nat/mozilla/x-zyoausmtlykpiyqe)
  1365. # [20:10] <zcorpan_> Hixie: all subtitles from tvsubtitles.net seem to have 9999
  1366. # [20:10] <zcorpan_> 00:00:0,500 --> 00:00:2,00
  1367. # [20:10] <zcorpan_> <font color="#ffff00" size=14>www.tvsubtitles.net</font>
  1368. # [20:10] <zcorpan_> at the *end* of the file
  1369. # [20:11] * Joins: sicking (~chatzilla@nat/mozilla/x-couretwkhrytzecb)
  1370. # [20:16] <Hixie> yeah, i think the parser will likely support out-of-order cues
  1371. # [20:17] * Quits: dbaron (~dbaron@c-98-234-51-190.hsd1.ca.comcast.net) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  1372. # [20:17] <Hixie> (in fact it already does)
  1373. # [20:18] <Hixie> it doesn't support times with only one digit for the seconds or two digits for the thousandths, though
  1374. # [20:18] <Hixie> do UAs support that?
  1375. # [20:18] <Hixie> it's trivial for me to add support if necessary
  1376. # [20:20] * Quits: mpt (~mpt@canonical/mpt) (Ping timeout: 240 seconds)
  1377. # [20:20] <Hixie> zcorpan_: btw so i don't miss them it'd really useful if you could note your observations of what you found in the wild on the iki
  1378. # [20:20] <Hixie> wiki
  1379. # [20:20] <zcorpan_> VLC supports single-digit seconds
  1380. # [20:20] <zcorpan_> ok
  1381. # [20:20] <Hixie> thanks for doing this btw, it's really helpful
  1382. # [20:21] <zcorpan_> MPlayer too
  1383. # [20:22] * Quits: Necrathex (~bleptop@212-123-163-12.ip.telfort.nl) (Ping timeout: 260 seconds)
  1384. # [20:22] * Joins: Necrathex (~bleptop@212-123-163-12.ip.telfort.nl)
  1385. # [20:22] * Quits: tndH (~Rob@cpc5-seac20-2-0-cust394.7-2.cable.virginmedia.com) (Quit: ChatZilla 0.9.86-rdmsoft [XULRunner 1.9.0.1/2008072406])
  1386. # [20:23] * Quits: mlpug (~mlpug@a88-115-164-40.elisa-laajakaista.fi) (Ping timeout: 260 seconds)
  1387. # [20:24] <zcorpan_> vlc seems to drop the thousands if they're 2 digits
  1388. # [20:25] <zcorpan_> heh, vlc interprets 00:00:00,5000 as if it were 00:00:05,000
  1389. # [20:26] <zcorpan_> it's possible that it takes the two digits but it's too close to 0 for me to tell
  1390. # [20:28] <Hixie> 100ms should distinguishable from 0ms, try having multiple overlapping titles
  1391. # [20:28] <Hixie> oh wait doesn't vlc do automatic overlay protection?
  1392. # [20:29] <Hixie> if so you can just have some that would overlap and some that would not based on how it interprets two digit times
  1393. # [20:29] <Hixie> and see how it positions them
  1394. # [20:29] <Hixie> bbiab, going to the office
  1395. # [20:29] <zcorpan_> mplayer also interprets 00:00:00,5000 as if it were 00:00:05,000
  1396. # [20:33] <zcorpan_> ok vlc interprets 00:00:01,99 as 00:00:01,099
  1397. # [20:36] <zcorpan_> vlc seems to just overlap without changing position
  1398. # [20:37] * Joins: mlpug (~mlpug@a88-115-164-40.elisa-laajakaista.fi)
  1399. # [20:40] <zcorpan_> for the pay-per-minute or per-byte use case, can't the server just throttle the download as it sees fit?
  1400. # [20:41] <zcorpan_> if it's on the client side it seems easy to bypass anyway
  1401. # [20:41] * Quits: maikmerten_ (~maikmerte@port-92-201-177-35.dynamic.qsc.de) (Remote host closed the connection)
  1402. # [20:43] * Quits: plainhao (~plainhao@mail.xbiotica.com) (Quit: plainhao)
  1403. # [20:44] * Joins: f1lt3r (~f1lt3r@64.119.159.231)
  1404. # [20:44] * Joins: dbaron (~dbaron@nat/mozilla/x-krqtjigvhjvowrxt)
  1405. # [20:45] * Quits: mlpug (~mlpug@a88-115-164-40.elisa-laajakaista.fi) (Ping timeout: 264 seconds)
  1406. # [20:48] * Quits: abarth|zZz (~abarth@c-98-210-108-185.hsd1.ca.comcast.net) (Quit: abarth|zZz)
  1407. # [20:59] * Joins: mlpug (~mlpug@a88-115-164-40.elisa-laajakaista.fi)
  1408. # [21:07] * Joins: othermaciej (~mjs@17.246.18.89)
  1409. # [21:11] <Hixie> zcorpan_: thanks for the notes on the wiki
  1410. # [21:11] <zcorpan_> np
  1411. # [21:15] * Quits: aroben (~aroben@unaffiliated/aroben) (Quit: aroben)
  1412. # [21:21] * Joins: Lachy (~Lachlan@cm-84.215.59.50.getinternet.no)
  1413. # [21:22] * Quits: erlehmann (~erlehmann@dslb-092-078-143-210.pools.arcor-ip.net) (Quit: Ex-Chat)
  1414. # [21:23] * Quits: Lachy (~Lachlan@cm-84.215.59.50.getinternet.no) (Client Quit)
  1415. # [21:23] * Joins: Lachy (~Lachlan@cm-84.215.59.50.getinternet.no)
  1416. # [21:29] * Joins: justicefries (~gerred@c-98-245-71-126.hsd1.co.comcast.net)
  1417. # [21:31] * Quits: nimbupani (~nimbupani@c-24-22-131-46.hsd1.wa.comcast.net) (Quit: nimbupani)
  1418. # [21:33] <Hixie> zcorpan_: we can go several ways on the timestamp parsing thing
  1419. # [21:33] <Hixie> zcorpan_: we could just support arbitrary values in each field, and then add them together without checking ranges
  1420. # [21:34] <Hixie> zcorpan_: so e.g. 1:60:60,60000 would turn into 1 hour + 60 minutes + 60 seconds + 60000 thousandths, i.e. 2h2m, same as 02:02:00.000
  1421. # [21:35] <Hixie> zcorpan_: we could check ranges, but support missing zero padding, so e.g. 1:1:1,1 => 01:01:01.001
  1422. # [21:36] <Hixie> zcorpan_: or we could be strict, and not support this contentz
  1423. # [21:36] <Hixie> zcorpan_: any opinions?
  1424. # [21:42] <Hixie> i went with the first option
  1425. # [21:43] <zcorpan_> that's what i was going to suggest (for compat with vlc and mplayer; i have no idea if there's any content that relies on this)
  1426. # [21:45] <TabAtkins> Adding them all together is the best. Makes so many things simpler when you don't have to futz around with doing base-60 arithmetic yourself.
  1427. # [21:45] <Hixie> well there's the content you pasted which relies on us doing either the first two and not the third
  1428. # [21:46] <Hixie> TabAtkins: well they're still not valid at the moment
  1429. # [21:46] <Hixie> this is just error handling behaviour
  1430. # [21:46] <TabAtkins> d'oh.
  1431. # [21:46] <TabAtkins> I like it when that sort of thing is expicitly allowed.
  1432. # [21:46] <Hixie> we can talk about what should be valid too, but that's a discussion for another time
  1433. # [21:46] <Hixie> i'm starting the format as strict as possible in terms of what's allowed, e.g. it even wants the cues in order
  1434. # [21:46] <Hixie> which i imagine we'll later relax
  1435. # [21:46] <Hixie> but we'll see
  1436. # [21:47] * TabAtkins thinks specifically of date libraries that are perfectly happy being asked to create a datetime for March -3 or whatever.
  1437. # [21:48] <zcorpan_> Hixie: ah, i didn't even notice the lack of zeros in 00:00:0,500 --> 00:00:2,00 when i pasted it
  1438. # [21:49] <Hixie> heh
  1439. # [21:49] <Hixie> TabAtkins: there are arguments both ways on this -- in this particular case, given how easy it is to write a script that normalises the files, the benefit might not outweigh the cost
  1440. # [21:50] <Hixie> (the cost is that it makes understanding what's going on kinda confusing)
  1441. # [21:50] <Hixie> (e.g. you can't tell at a glance which cue is higher than which cue)
  1442. # [21:50] * Quits: sicking (~chatzilla@nat/mozilla/x-couretwkhrytzecb) (Ping timeout: 260 seconds)
  1443. # [21:51] <TabAtkins> I blame human-based timestamps.
  1444. # [21:54] <annevk> http://html5.org/tools/web-apps-tracker?from=5123&to=5124 -- I hope we don't get these
  1445. # [21:54] * Joins: mitnavn (~mitnavn@unaffiliated/mitnavn)
  1446. # [21:54] <hsivonen> annevk: congrats on the chairship
  1447. # [21:56] <annevk> thanks, though the charter still needs to get approved by the AC
  1448. # [21:56] <Hixie> chairship?
  1449. # [21:57] <annevk> http://www.w3.org/2010/06/notification-charter.html
  1450. # [21:58] <Hixie> oh, i've been ignoring that thread
  1451. # [21:59] <Hixie> glad you're chairing that
  1452. # [21:59] <Hixie> grats
  1453. # [21:59] <Hixie> keep 'em sane!
  1454. # [22:01] * Hixie wonders how to structure the output of the cue text parser
  1455. # [22:01] <Hixie> i could just output DOM nodes
  1456. # [22:01] <Hixie> but that seems a bit heavy-weight if implementations decide to actually take me to my word
  1457. # [22:05] * Joins: pauld (~chatzilla@188.28.182.250.threembb.co.uk)
  1458. # [22:05] * Quits: davidb_ (~davidb@mozca02.ca.mozilla.com) (Quit: davidb_)
  1459. # [22:05] <zcorpan_> Hixie: i think you can assume that implementors are going to cut corners
  1460. # [22:14] * Quits: pauld (~chatzilla@188.28.182.250.threembb.co.uk) (Remote host closed the connection)
  1461. # [22:19] * Quits: roc (~roc@121.98.230.221) (Quit: roc)
  1462. # [22:25] * Quits: justicefries (~gerred@c-98-245-71-126.hsd1.co.comcast.net) (Ping timeout: 264 seconds)
  1463. # [22:26] <hsivonen> Hixie: if the cue text parser outputs DOM nodes, why not use the HTML fragment parsing algorithm?
  1464. # [22:29] <karlushi> trying to imagine the concrete use cases from the report http://www.w3.org/2010/02/mbui/report.html and have difficulties to see them. I guess I should read the papers
  1465. # [22:29] <othermaciej> annevk: I offer you a virtual beer of sympathy
  1466. # [22:31] * Joins: justicefries (~gerred@c-98-245-71-126.hsd1.co.comcast.net)
  1467. # [22:32] <zcorpan_> hsivonen: it's interleaved with karaoke timestamps and voices
  1468. # [22:32] * Quits: mlpug (~mlpug@a88-115-164-40.elisa-laajakaista.fi) (Remote host closed the connection)
  1469. # [22:33] <hsivonen> zcorpan_: I didn't notice voices inside the cue text
  1470. # [22:33] * hsivonen looks
  1471. # [22:33] * Quits: kennyluck (~kennyluck@EM111-188-56-222.pool.e-mobile.ne.jp) (Ping timeout: 276 seconds)
  1472. # [22:33] <zcorpan_> hsivonen: and maybe VLC doesn't want to bundle a whole HTML parser just for websrt
  1473. # [22:34] <zcorpan_> hsivonen: oh maybe not voices
  1474. # [22:34] * Quits: Amadiro (~whoppix@ti0021a380-dhcp1747.bb.online.no) (Quit: A subtle thought that is in error may yet give rise to fruitful inquiry that can establish truths of great value.)
  1475. # [22:35] <hsivonen> zcorpan_: VLC already bundles the kitchen sink
  1476. # [22:35] <hsivonen> zcorpan_: I thought we'd have learned that avoiding HTML parsing is the wrong optimization
  1477. # [22:36] <hsivonen> we could mint an element for karaoke timing within cue text
  1478. # [22:36] <karlushi> http://www.google.com/search?q=websrt+site%3Avideolan.org
  1479. # [22:37] <karlushi> [nil]
  1480. # [22:38] * Joins: roc (~roc@121.98.230.221)
  1481. # [22:39] * hsivonen still thinks karaoke stuff is a distraction as far as solving an accessibility problem goes
  1482. # [22:40] <karlushi> http://trac.videolan.org/vlc/search?q=Subtitles nothing related to websrt
  1483. # [22:41] <zcorpan_> hsivonen: if browsers support any elements in captions then soon enough all media players need to bundle a browser engine for compat with content
  1484. # [22:42] <hsivonen> zcorpan_: maybe. one could argue that if browsers support any elements in prose, word processors need to bundle browser engines
  1485. # [22:42] <hsivonen> when designing a format for the Web, needing a browser engine isn't a bug, IMO
  1486. # [22:45] <karlushi> hsivonen, maybe, but it doesn't necessary help with the format having success in other environments. (thinking). If the format has no strong ties with the browser engine, I guess it doesn't matter that much.
  1487. # [22:47] <hsivonen> karlushi: SRT already has success in other environments. WebSRT is leveraging that. Not the other way round.
  1488. # [22:47] * Quits: Anonameless (~Nameless@cm218-252-156-82.hkcable.com.hk) (Quit: Leaving)
  1489. # [22:47] * Quits: miketaylr (~miketaylr@38.117.156.163) (Remote host closed the connection)
  1490. # [22:51] * Quits: roc (~roc@121.98.230.221) (Quit: roc)
  1491. # [22:56] * Joins: sicking (~chatzilla@nat/mozilla/x-iknlgfppuhbvkddp)
  1492. # [23:01] * Quits: ROBOd (~robod@92.86.245.3) (Quit: http://www.robodesign.ro)
  1493. # [23:02] <annevk> both sides make sense
  1494. # [23:03] <annevk> though I suspect browsers will at some point be a low-level piece of software, like unix, so having them as a requirement is probably not too bad
  1495. # [23:04] <TabAtkins> "at some point"?
  1496. # [23:05] <annevk> it's not quite there yet
  1497. # [23:07] * Joins: nimbupani (~nimbupani@c-24-22-131-46.hsd1.wa.comcast.net)
  1498. # [23:08] <TabAtkins> AryehGregor: Plus, the only pay-per-minute video I've ever seen on the web is porn.
  1499. # [23:09] * Quits: sicking (~chatzilla@nat/mozilla/x-iknlgfppuhbvkddp) (Ping timeout: 240 seconds)
  1500. # [23:11] * karlushi suddenly think that TabAtkins has spent money for nothing, there is so much free stuff out there.
  1501. # [23:12] <TabAtkins> Oh, I've never paid for it. You kidding? Giving your credit card to a porn company is just *asking* for identity theft.
  1502. # [23:12] <TabAtkins> I'm just saying, that's the only place I've ever seen pay-per-minute used.
  1503. # [23:13] * Joins: sicking (~chatzilla@nat/mozilla/x-kycnnddqwgjlanpc)
  1504. # [23:13] * Quits: Maurice (copyman@5ED573FA.cable.ziggo.nl)
  1505. # [23:13] <Hixie> hsivonen: because i don't want to require that VLC embed an HTML parser when it's not necessary
  1506. # [23:13] * karlushi was just quoting TabAtkins ;) "I've ever seen" and being playful.
  1507. # [23:16] <annevk> Hixie, the counter argument is that VLC will be eaten by the browser Godzilla in the end and that therefore complicating the browser more for the sake of VLC is not worth it long term
  1508. # [23:18] * Philip` kind of likes having several small independent applications, rather than one giant monolithic one
  1509. # [23:18] <annevk> (and maybe/hopefully, long term HTML parsing will be like number parsing in programming languages)
  1510. # [23:19] * karlushi agrees with Philip`
  1511. # [23:19] * karlushi fears we are geeks though
  1512. # [23:20] <annevk> I don't know
  1513. # [23:20] <annevk> applications are on top of the platform
  1514. # [23:20] <annevk> we're discussing the platform here
  1515. # [23:23] <annevk> I don't mind yet another parser so much though
  1516. # [23:24] <annevk> compared to layout, dynamic updates, etc., parsers are cheap
  1517. # [23:25] <annevk> (though admittedly the HTML parser with script injection and all can get pretty darn complex)
  1518. # [23:25] <hsivonen> Hixie: I think WebSRT is repeating the mistake that Pingback made (speccing a regexp instead of requiring real parsing)
  1519. # [23:26] <hsivonen> (this time it's not a regexp but still the "can't require HTML parsing" mentality)
  1520. # [23:26] * Quits: nimbupani (~nimbupani@c-24-22-131-46.hsd1.wa.comcast.net) (Quit: nimbupani)
  1521. # [23:26] <hsivonen> and we are the group that has finally solved HTML parsing so that it could now be required!
  1522. # [23:27] <Hixie> hsivonen: who's speccing a regexp?
  1523. # [23:27] <hsivonen> Hixie: you did in Pingback
  1524. # [23:27] <Hixie> i was ten years younger then :-)
  1525. # [23:28] <Hixie> i can't use the html fragment parser because it doesn't support things like timestamps, and i don't want to use the html parser because that's about 1000 times the needed complexity
  1526. # [23:28] <annevk> Pingback was about finding something inside a text/html resource. That seems quite different from finding something in a text/srt resource.
  1527. # [23:28] <Hixie> but i have no intention of speccing a fake parser, it'll be a real one
  1528. # [23:28] <hsivonen> my point is that HTML parsing shouldn't be considered to be the bogeyman it was 10 years ago
  1529. # [23:29] <hsivonen> Hixie: I'm suggesting that the HTML parser be used only for cue text
  1530. # [23:29] <Hixie> sure, but the cue text has timestamps (for karaoke)
  1531. # [23:30] <hsivonen> Hixie: I'm ok with a dedicated parser for the WebSRT encapsulation
  1532. # [23:30] <hsivonen> Hixie: an element could be minted
  1533. # [23:30] <Hixie> i don't consider the html parser a bogeyman, i consider it a massive piece of engineering and a pretty big part of my spec editing career... but it's still orders of magnitude more than we need here
  1534. # [23:30] <hsivonen> Hixie: (and karaoke is on the wrong side of 80/20 anyway, IMO)
  1535. # [23:31] <Hixie> i beg to differ on that last one, karaoke occurs in many (most?) anime videos, e.g.
  1536. # [23:32] <annevk> most Ghibli movies I've seen so far need it
  1537. # [23:32] <TabAtkins> Agreed. It's either part of most movies, or at the least part of the opening/closing credits.
  1538. # [23:33] <annevk> yeah, usually at the start/ending
  1539. # [23:33] <Hixie> anyway, i really don't see why we'd reuse the html parser other than just because we already have one, which is a pretty poor reason given that media players aren't going to be the same as html browsers in many cases
  1540. # [23:33] <annevk> I should say Totoro again; it's pretty great
  1541. # [23:33] <hsivonen> would the creators of those movies be satisfied with text tracks anyway, or would they burn their art to the pixel data?
  1542. # [23:33] <annevk> s/say/see/ doh
  1543. # [23:34] * Joins: ap (~ap@2620:0:1b00:1191:226:4aff:fe14:aad6)
  1544. # [23:34] <boazsender> There any mention in any spec of file writing with data uri's?
  1545. # [23:34] <boazsender> like if I wanted to be able to do window.location='data:dataType,' + URIEncodedData;
  1546. # [23:34] <hsivonen> Hixie: I think the WHATWG would be designing a captioning format for use on the Web. if it gets picked up by standalone media players, that would be a bonus, but IMO shouldn't be a design goal
  1547. # [23:35] <boazsender> ... and have that cause a file download.
  1548. # [23:35] <boazsender> the above works in firefox 3.6
  1549. # [23:35] <annevk> hsivonen, you don't want to create captions twice
  1550. # [23:36] <hsivonen> annevk: for the vast majority of cases, the WebSRT captions would be just like today's SRT
  1551. # [23:36] <hsivonen> without fancy stuff
  1552. # [23:36] * Joins: roc (~roc@203-97-204-82.dsl.clear.net.nz)
  1553. # [23:36] <annevk> I wonder more how long the standalone player with no browser argument holds true...
  1554. # [23:37] <annevk> hsivonen, presumably they would like to have conforming implementations too
  1555. # [23:38] <hsivonen> annevk: we could use the "CSS is optional" pixie dust :-)
  1556. # [23:39] <zcorpan_> annevk: legacy encodings is a bigger problem with existing srt
  1557. # [23:41] <annevk> zcorpan_, I don't think it's about how much existing content works with WebSRT, it's more how easy WebSRT can be adopted by various vendors
  1558. # [23:41] <annevk> hsivonen, as in HTML parsing is optional?
  1559. # [23:41] <hsivonen> annevk: no, as in complex rendering of the data structure you get out of the HTML parser would be optional
  1560. # [23:42] * Quits: eighty4 (~eighty4@c-76c8e455.012-403-6c6b701.cust.bredbandsbolaget.se) (Remote host closed the connection)
  1561. # [23:42] <hsivonen> HTML parsing is / will be off-the-shelf stuff
  1562. # [23:42] <annevk> I think Hixie's point was that implementing an HTML parser was too much already
  1563. # [23:43] <annevk> yeah, I think that will be true in due course too
  1564. # [23:43] <hsivonen> annevk: my point is that you'll be able to use an HTML parser that's already been written
  1565. # [23:43] <annevk> on the other hand, by that argument we should have used HTML for EventSource or manifest=""
  1566. # [23:44] <annevk> if the part of WebSRT that is markup is significantly simpler than a full HTML parser it might be worth to have it actually be simpler
  1567. # [23:44] * Joins: eric_carlson (~ericc@17.246.18.251)
  1568. # [23:44] <hsivonen> (I realize that what I say would be more credible if I was able to point to a C++ version of the V.nu/Gecko parser that didn't need Gecko stuuf around it)
  1569. # [23:45] <annevk> your argument also kind of sounds like "lets use XML; it's great"
  1570. # [23:45] * Quits: boazsender (~boazsende@77.sub-75-238-117.myvzw.com) (Ping timeout: 240 seconds)
  1571. # [23:47] <annevk> and we have rejected that too because of the sheer complexity
  1572. # [23:47] <annevk> even though standard libraries are all over the place
  1573. # [23:50] <annevk> anyway, I'm about 45min late for an appointment with a novel; nn :)
  1574. # [23:51] <roc> WebSRT is renderable markup, EventSource and manifest are not
  1575. # [23:51] * Joins: boazsender (~boazsende@217.sub-75-238-235.myvzw.com)
  1576. # [23:51] <roc> the argument that "right now we only need a simple subset, so let's spec our own" is why SVG started encroaching on HTML and CSS
  1577. # [23:52] <roc> it's troublesome because of course the requirements grow over time, and at each step the easiest thing to do for implementers, spec authors and Web authors is to add one more feature to the stand-alone subset
  1578. # [23:53] <roc> however, argument by analogy is weak so that doesn't settle the issue
  1579. # [23:54] <AryehGregor> I don't suppose there's any way to have, say, <input type="number"> that doesn't get validated, without adding attributes to the form itself or submit buttons?
  1580. # [23:56] * AryehGregor doesn't see one
  1581. # [23:56] <zcorpan_> AryehGregor: i think you can override the validation of specific elements with setCustomValidity or something
  1582. # [23:56] <AryehGregor> I was thinking without JS. I could always add oninvalid="return false", yeah.
  1583. # [23:57] * Joins: ZombieLoffe (~e@unaffiliated/zombieloffe)
  1584. # [23:57] <zcorpan_> then no, afaik
  1585. # [23:58] * Quits: eric_carlson (~ericc@17.246.18.251) (Quit: eric_carlson)
  1586. # [23:59] * Joins: eric_carlson (~ericc@17.246.18.251)
  1587. # Session Close: Thu Jul 01 00:00:00 2010

The end :)