/irc-logs / freenode / #whatwg / 2011-10-11 / end

Options:

  1. # Session Start: Tue Oct 11 00:00:00 2011
  2. # Session Ident: #whatwg
  3. # [00:00] * Quits: danbri (~danbri@ip176-48-210-87.adsl2.static.versatel.nl) (Read error: Connection timed out)
  4. # [00:00] * Quits: ap_ (~ap@17.212.155.203) (Ping timeout: 255 seconds)
  5. # [00:01] * Joins: danbri (~danbri@ip176-48-210-87.adsl2.static.versatel.nl)
  6. # [00:03] * Joins: heycam (~cam@wok.mcc.id.au)
  7. # [00:03] * Joins: KillerX_ (~anant@206-15-76-122.static.twtelecom.net)
  8. # [00:04] <heycam> morning
  9. # [00:06] * Quits: KillerX (~anant@206-15-76-122.static.twtelecom.net) (Read error: Operation timed out)
  10. # [00:06] * KillerX_ is now known as KillerX
  11. # [00:16] * Joins: smaug____ (~chatzilla@ZYYMKDCCXXVII.gprs.sl-laajakaista.fi)
  12. # [00:16] <sicking> heycam!
  13. # [00:17] <Hixie> heycam! you have returned!
  14. # [00:17] <Hixie> heycam: let me know when you're caught up with mail and so on, i have some questions for you :-)
  15. # [00:19] <heycam> Hixie, ok, gimme a day :)
  16. # [00:19] <Hixie> np!
  17. # [00:20] * Quits: mishunov (~spliter@212.17.143.210) (Quit: mishunov)
  18. # [00:21] * heycam starts remote working today, hopes it works out for him :)
  19. # [00:23] * Quits: hasather_ (~hasather_@84.38.144.96) (Remote host closed the connection)
  20. # [00:27] <Hixie> wait, tpac costs money again this year? wtf
  21. # [00:28] <Hixie> i don't even want to attend any meetings
  22. # [00:32] * Joins: ako (~nya@fuld-590c7bda.pool.mediaWays.net)
  23. # [00:33] * Joins: necolas (~necolas@5e0c0fc8.bb.sky.com)
  24. # [00:34] * Joins: homata (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp)
  25. # [00:36] * Quits: aho (~nya@fuld-590c78af.pool.mediaWays.net) (Ping timeout: 248 seconds)
  26. # [00:37] * ako is now known as aho
  27. # [00:38] * bga_ is now known as bga_|away
  28. # [00:46] <Hixie> sicking: do you know if anyone at mozilla is looking at <iframe sandbox>?
  29. # [00:47] <sicking> Hixie: yes, Ian Melven expressed interest in working on it
  30. # [00:47] <sicking> Hixie: no ETA though, he's just starting
  31. # [00:47] <sicking> Hixie: on that topic though, the fallback story for sandboxes seem to be terrible
  32. # [00:48] <Hixie> yeah that's what i wanted to ask about
  33. # [00:48] <Hixie> the spec uses text/html-sandboxed currently
  34. # [00:48] <Hixie> apparently this fails in some old IEs that sniff like crazy
  35. # [00:48] <Hixie> i was wondering if anyone at mozilla had any better ideas
  36. # [00:49] <Hixie> (by "fails" i mean "gets interpreted as text/html so you can XSS someone by getting them to visit the framed content directly")
  37. # [00:52] * Quits: Amorphous (jan@unaffiliated/amorphous) (Ping timeout: 248 seconds)
  38. # [00:53] <jwalden> \o/
  39. # [00:54] * Joins: MikeSmith_ (~MikeSmith@EM1-113-12-168.pool.e-mobile.ne.jp)
  40. # [00:54] * bga_|away is now known as bga_
  41. # [00:56] * Quits: danbri (~danbri@ip176-48-210-87.adsl2.static.versatel.nl) (Read error: Connection timed out)
  42. # [00:57] * Quits: MikeSmith (~MikeSmith@EM114-48-134-68.pool.e-mobile.ne.jp) (Ping timeout: 244 seconds)
  43. # [00:57] * MikeSmith_ is now known as MikeSmith
  44. # [00:57] * Joins: danbri (~danbri@ip176-48-210-87.adsl2.static.versatel.nl)
  45. # [00:58] <sicking> Hixie: does the @sandbox attribute only work with text/html-sandboxed?
  46. # [00:58] <sicking> Hixie: i thought it was intended to work with plain "text/html" too?
  47. # [00:58] <Hixie> it works for both; there's use cases for sandboxing stuff that is safe to access directly
  48. # [00:58] <Hixie> (e.g. anything cross-domain)
  49. # [00:59] <sicking> Hixie: but then what's the purpose of the sandbox attribute in that use case?
  50. # [00:59] <Hixie> to e.g. prevent popups
  51. # [00:59] <Hixie> it's pretty flexible, you can do quite a lot with it
  52. # [01:00] <sicking> my concern is that it's *really* easy to write markup that looks fine, until you start thinking about browsers that don't implement @sandbox
  53. # [01:00] * Quits: ap (~ap@17.245.91.215) (Remote host closed the connection)
  54. # [01:01] * Joins: ap (~ap@17.212.155.203)
  55. # [01:01] <Hixie> yeah, but there's so many use cases where sandbox="" is just extra defense in depth that it doesn't really make sense to make it not work at all in legacy UAs
  56. # [01:01] <sicking> not sure I agree, i'd prefer if websites in those cases detected that sandbox wasn't implemented and did the fallback themselves
  57. # [01:02] <sicking> i'm fine with having fallback for the less sensitive cases
  58. # [01:02] <sicking> but for the more sensitive ones, like disable scripting, it seems pretty bad with the current design
  59. # [01:02] <sicking> one alternative i was thinking about is something like this:
  60. # [01:03] <sicking> <iframe src="strictly_filtered_comments.cgi?blogpostid=123" sandbox_src="comments.cgi?blogpostid=123">
  61. # [01:03] <sicking> or
  62. # [01:03] <sicking> or rather "and:"
  63. # [01:04] * bga_ is now known as bga_|away
  64. # [01:05] <sicking> <iframe src="strictly_filtered_comments.cgi?blogpostid=123" sandbox_src="comments.cgi?blogpostid=123" sandbox="allow-top-navigation">
  65. # [01:05] * Quits: temp01 (~temp01@unaffiliated/temp01) (Ping timeout: 248 seconds)
  66. # [01:05] * bga_|away is now known as bga_
  67. # [01:06] <sicking> where the former cgi could do more agressive filtering of any HTML contents for example
  68. # [01:06] <erlehmann> sicking, can you explain why „strictly_filtered_comments“ would not be in both?
  69. # [01:06] <erlehmann> i seem to be missing something here.
  70. # [01:06] * Joins: ezoe (~ezoe@203-140-89-83f1.kyt1.eonet.ne.jp)
  71. # [01:07] * jernoble is now known as jernoble|afk
  72. # [01:07] * Joins: temp01 (~temp01@unaffiliated/temp01)
  73. # [01:07] <sicking> erlehmann: say that you want to allow comments to use some basic HTML markup, like changing colors and fonts
  74. # [01:07] <sicking> erlehmann: but you don't trust that you'll get all the HTML filtering correctly
  75. # [01:07] * Joins: Amorphous (jan@unaffiliated/amorphous)
  76. # [01:08] <sicking> erlehmann: so you do what you think is correct in comments.cgi, but remove *all* markup in strictly_filtered_comments.cgi
  77. # [01:08] <erlehmann> intredasting.
  78. # [01:08] <sicking> erlehmann: or say that you're hosting widgets on your site
  79. # [01:09] <sicking> erlehmann: you want the widgets to be able to run script
  80. # [01:09] <erlehmann> i'll still just use html5lib and think i am filtering absolutely, entirely correctly in that case.
  81. # [01:09] <sicking> erlehmann: but not if you can't sandbox them
  82. # [01:09] <erlehmann> that i understand.
  83. # [01:09] <sicking> erlehmann: then you'd let the first src filter out all scripts, but the second would be allowed to run scripts
  84. # [01:10] <sicking> erlehmann: if you're trusting your filtering, then would you ever need sandbox at all?
  85. # [01:10] <sicking> erlehmann: i.e. isn't HTML4 working fine for you?
  86. # [01:10] <erlehmann> still, that's not the graceful degradation i know. it is … something else. i hope i'll never need it.
  87. # [01:10] * Quits: tndH (~Rob@cpc16-seac19-2-0-cust234.7-2.cable.virginmedia.com) (Ping timeout: 248 seconds)
  88. # [01:10] <erlehmann> last i checked, there was no html4lib ;)
  89. # [01:10] <erlehmann> but yes.
  90. # [01:11] <sicking> erlehmann: well then, if what exists already is good enough for you, then i think we're done here :)
  91. # [01:11] <erlehmann> we are. but now i understand why you did not just filter damn everything.
  92. # [01:12] <erlehmann> (which i, for the record, would do, if i were that unsure of my filtering capabilities.)
  93. # [01:12] <erlehmann> a friend made a wiki and is so paranoid, even internal functions check their assertions about the arguments.
  94. # [01:12] * jernoble|afk is now known as jernoble
  95. # [01:12] <erlehmann> that is properly paranoid.
  96. # [01:14] <Hixie> sicking: sure, in that use case you'd want to use something different in both cases. But most use cases will be <iframe sandbox src="something-i-think-is-safe-regardless"></iframe>
  97. # [01:14] <Hixie> (s/most/many/, certainly)
  98. # [01:16] <sicking> Hixie: then put the same url in both attributes
  99. # [01:16] <Hixie> sicking: as soon as we do that you're back to your original problem
  100. # [01:17] <abarth> the default-closed behavior is really hard to get for on-domain resources
  101. # [01:17] <Hixie> sicking: i.e. that it is easy to write markup that looks fine, until you start thinking about browsers that don't implement @sandbox
  102. # [01:17] <Hixie> how do you mean?
  103. # [01:17] <abarth> its really hard to host things on-domain and not have them be used against you
  104. # [01:17] <abarth> e.g., by Java or Flash
  105. # [01:18] <abarth> one thing you can do is to set a Content-Disposition: attachment
  106. # [01:18] <abarth> Flash will respect that
  107. # [01:18] <abarth> i haven't tested Flash recently
  108. # [01:18] <abarth> it turns out that sandbox is pretty useful even without text/html-sandbox
  109. # [01:19] <Hixie> well if we are assuming that anything same-domain is guaranteed to be unsandboxable when viewed directly, we might as well require that src="" be cross-origin if sandbox="" is specified
  110. # [01:19] <Hixie> but then that makes a lot of sandbox="" rather pointless
  111. # [01:19] <abarth> a very common way to use it is with an about:blank iframe
  112. # [01:19] * bga_ is now known as bga_|away
  113. # [01:19] <abarth> which you sandbox
  114. # [01:20] <abarth> and then fill up with stuff
  115. # [01:20] * Quits: gabe_ (~chatzilla@81-174-24-100.dynamic.ngi.it) (Quit: ChatZilla 0.9.87 [Firefox 7.0.1/20110928224103])
  116. # [01:20] <Hixie> ok. so on the short-term, what i'm hearing is that we shoudl drop text/html-sandboxed like microsoft suggests
  117. # [01:21] <Hixie> and on the medium term there might be additional changes that would be useful?
  118. # [01:23] <abarth> in the medium term, i want to convince someone to implement seamless
  119. # [01:23] <abarth> ;)
  120. # [01:25] * Joins: nunnun (~nunnun@2001:268:355:1:20c:29ff:fed5:973a)
  121. # [01:25] * nunnun is now known as nunnun_away
  122. # [01:27] * Joins: myakura (~myakura@FL1-203-136-164-250.tky.mesh.ad.jp)
  123. # [01:28] <sicking> Hixie: and disable the ability to have same-origin sandboxes?
  124. # [01:28] <Hixie> that's the medium term question
  125. # [01:29] <Hixie> i recommend posting on the whatwg list about it
  126. # [01:29] <sicking> so what are the use cases when sandbox is useful? Assuming the aweful fallback in older browsers?
  127. # [01:29] <Hixie> (we'd have to drop allow-same-origin if we did that)
  128. # [01:30] <Hixie> well like i said, defense-in-depth is a huge use case
  129. # [01:30] <sicking> wouldn't that make it cover the same usecases as CSP then?
  130. # [01:31] <Hixie> CSP is far too complex for most authors who have just one domain to use, imho
  131. # [01:31] <sicking> CSP lets you completely disable scripting
  132. # [01:31] <sicking> which would seem like the main usecase for sandbox
  133. # [01:32] * bga_|away is now known as bga_
  134. # [01:32] <sicking> if we're only talking about defence in depth
  135. # [01:32] <Hixie> i dunno that i'd say it's the main use case
  136. # [01:32] <Hixie> might be an important use case in the defence in depth subset of the use cases
  137. # [01:32] <Hixie> but then so's preventing form submission
  138. # [01:32] <Hixie> and disallowing frame navigation
  139. # [01:32] <Hixie> and blocking plugins...
  140. # [01:33] <Hixie> CSP is so complex that i see abarth asking about it :-P
  141. # [01:33] <sicking> ok, so assume a world where browsers implement CSP, convince me as a browser author what additional use cases would be covered by @sandbox
  142. # [01:34] <abarth> Hixie: CSP is crazy complex
  143. # [01:34] <abarth> its very hard for authors to use
  144. # [01:34] <abarth> i've been spending a bunch of time with early adopters to understand the snags they run into
  145. # [01:34] <abarth> sicking: oh, the use cases are really different
  146. # [01:34] <Hixie> sicking: if CSP was implemented and easy to use, it might obviate many use cases for same-origin sandbox=""
  147. # [01:34] <Hixie> sicking: though not any of the cross-origin ones
  148. # [01:35] <abarth> sicking: CSP is for restricting your own content. sandbox is for restricting other people's content
  149. # [01:35] <sicking> abarth: i'm listening...
  150. # [01:35] <Hixie> sicking: but so far it does not seem that CSP is going to be easy to use, so...
  151. # [01:35] * Quits: KillerX (~anant@206-15-76-122.static.twtelecom.net) (Remote host closed the connection)
  152. # [01:35] * Quits: danbri (~danbri@ip176-48-210-87.adsl2.static.versatel.nl) (Read error: Connection timed out)
  153. # [01:35] * Quits: necolas (~necolas@5e0c0fc8.bb.sky.com) (Remote host closed the connection)
  154. # [01:35] <abarth> sicking: here's a real example
  155. # [01:35] <sicking> yay
  156. # [01:35] * Joins: KillerX (~anant@206-15-76-122.static.twtelecom.net)
  157. # [01:35] <abarth> you've got a RSS feed that you've fetched via CORS
  158. # [01:36] <abarth> and you want to show it to the user in a nice pretty form
  159. # [01:36] * Joins: danbri (~danbri@ip176-48-210-87.adsl2.static.versatel.nl)
  160. # [01:36] <abarth> you send it into a sandboxed iframe
  161. # [01:36] <abarth> and make a nice presentation of it
  162. # [01:36] <Hixie> i love that microsoft's suggestion regarding what to do with the warning is just 'In section 4.8.2 "The iframe element," remove the text "Warning! It is important that the server serve the user-provided HTML using the text/html-sandboxed MIME type so that if the attacker convinces the user to visit that page directly, the page doesn't run in the context of the site's origin, which would make the user vulnerable to any attack found in the page."'
  163. # [01:36] <abarth> that works really well with @sandbox and isn't really doable with CSP
  164. # [01:36] <Hixie> they don't suggest changing it or anything, just removing it
  165. # [01:36] <sicking> abarth: what's the fallback story for old browsers?
  166. # [01:37] <abarth> in the actual case, it didn't matter because it's a browser extension that does this
  167. # [01:37] <abarth> in the case of a web site, you can probably have a lower fidelity rendering of the RSS feed
  168. # [01:37] * Quits: divya (~divyam@219.64.117.145) (Quit: Leaving.)
  169. # [01:37] <abarth> or take some security risks
  170. # [01:38] <Hixie> or wait a few years and then tell the 1% of legacy UAs that they're screwed
  171. # [01:38] <sicking> abarth: i'm much more interested in building features for websites than extensions
  172. # [01:38] <abarth> sure, i just mentioned that case
  173. # [01:38] <abarth> because its a place where this got used this past week
  174. # [01:39] <sicking> abarth: so the concern is that the RSS markup would contain onclick attributes or <script> elements
  175. # [01:40] <sicking> abarth: ?
  176. # [01:40] <abarth> the RSS feed contains HTML
  177. # [01:40] <abarth> e.g., the contents of the posts
  178. # [01:40] <sicking> right
  179. # [01:40] <abarth> and you don't want the content to call alert()
  180. # [01:41] <abarth> for example
  181. # [01:41] <abarth> because that's annoying
  182. # [01:41] <sicking> so it seems you're screwed if you inject that into a about:blank iframe
  183. # [01:41] <abarth> so you don't want script to run
  184. # [01:41] <sicking> since that can run any script
  185. # [01:41] <abarth> what this guy was actually doing
  186. # [01:41] <abarth> was using a data URL
  187. # [01:42] <abarth> and i advised him to just add the sandbox attribute
  188. # [01:42] <abarth> to his iframe
  189. # [01:42] <abarth> and everything worked great
  190. # [01:42] <abarth> he was a very happy customer :)
  191. # [01:42] <sicking> i don't understand how it would work great in the fallback situation
  192. # [01:42] <sicking> i.e. when the browser doesn't support sandbox
  193. # [01:43] <sicking> let me phrase it this way: it seems to me that @sandbox has such a terrible fallback story for browsers that don't support @sandbox, that I'm not sure that we'll want to implement it in firefox and thus encourage it's usage on the web
  194. # [01:43] <abarth> well, for example, we could just how the text of the posts
  195. # [01:43] <abarth> instead of the HTML formating
  196. # [01:44] <sicking> i think there's a word missing there?
  197. # [01:44] <abarth> s/how/show
  198. # [01:44] <sicking> ah
  199. # [01:45] <abarth> its seems like you could make the same argument about CSP
  200. # [01:45] <sicking> abarth: so the idea is that webdevelopers are responsible for checking that @sandbox is supported, and use a completely different codepath if it's not
  201. # [01:45] * Joins: nessy (~Adium@74.125.56.18)
  202. # [01:45] <sicking> abarth: certainly
  203. # [01:45] <sicking> abarth: CSP is explicitly a defence-in-depth mechanism
  204. # [01:45] <abarth> there are two choices
  205. # [01:45] <abarth> 1) proceed as before and live with any additional risk
  206. # [01:45] <sicking> abarth: i was under the impression that @sandbox wasn't intended to be just defence-in-depth
  207. # [01:45] <abarth> 2) check if its supported and do something else if its not
  208. # [01:46] <sicking> this discussion has made me more confused about whether it is or not :)
  209. # [01:46] <abarth> that's option (2), but option (1) exists too
  210. # [01:46] * Quits: erlehmann (~erlehmann@89.204.153.10) (Ping timeout: 248 seconds)
  211. # [01:46] <abarth> well, consider the Secure attribute on cookies
  212. # [01:46] <abarth> is that defense in depth or is that a security measure?
  213. # [01:46] <abarth> what about browsers that don't support the Secure attribute?
  214. # [01:47] * Quits: astearns (~anonymous@192.150.22.5) (Ping timeout: 276 seconds)
  215. # [01:47] <sicking> are there any such browsers?
  216. # [01:47] <abarth> there were at one point in time
  217. # [01:47] <abarth> we'll be asking the same question about @sandbox in a few years
  218. # [01:47] <sicking> i'm not sure we made good decisions at that point in time :)
  219. # [01:47] <abarth> put another way,
  220. # [01:48] <abarth> what's a site supposed to do with browsers that don't support WebGL ?
  221. # [01:48] <abarth> use a different code path?
  222. # [01:48] <Hixie> sicking: sandbox="" is intended exclusively for defence in depth for now. It will eventually be usable for other things as well.
  223. # [01:48] <abarth> just because this is a security feature doesn't mean all the hard things about introducing new features go away
  224. # [01:48] <sicking> but yes, in a sense the Secure attribute is defense-in-depth. Though we know that MITM is easier than what was thought
  225. # [01:49] <abarth> ok, then you probably believe that every security feature is defense-in-depth
  226. # [01:49] <Hixie> except maybe TLS :-)
  227. # [01:50] <Hixie> what's teh fallback for https:// ? :-)
  228. # [01:50] * bga_ is now known as bga_|away
  229. # [01:50] <sicking> possibly. I'm a not huge fan of "security features" since most of them are patching mistakes of the past
  230. # [01:50] <sicking> but they are obviously needed
  231. # [01:51] <Hixie> "firefox developer not fan of security features" :-P
  232. # [01:51] <sicking> abarth: i'd just much rather that we fell back to a closed situation than an open situation
  233. # [01:51] <Hixie> sicking: falling back to a closed situation would be great, but falling back to nothing is not fallback, it's just the feature not being supported and the site being broken in old UAs
  234. # [01:52] <sicking> abarth: it seems very likely to me that people will do <iframe src="completely_untrusted_contents.cgi" sandbox>
  235. # [01:52] <abarth> i don't think there's any way to do that securely
  236. # [01:52] <abarth> regardless of the design
  237. # [01:52] <Hixie> if a site does <iframe src="completely_untrusted_contents.cgi" sandbox> they have far better problems than fallback
  238. # [01:52] <Hixie> even in completely compliant UAs they'll still get owned
  239. # [01:53] <Hixie> since you can just point a user to a page on another domain with that same iframe without sandbox=""
  240. # [01:53] <Hixie> and boom, you run script on the victim origin
  241. # [01:53] <Hixie> that was the idea behind text/html-sandboxed, which i've just removed from the spec and replaced with warnings saying to use a different origin for untrusted content
  242. # [01:57] <sicking> Hixie: so it seems to make sense to me to make <iframe src="same-origin/comments.cgi" sandbox="..."> refuse to load the iframe?
  243. # [01:57] <Hixie> would you block src="about:blank" too?
  244. # [01:58] <sicking> good question
  245. # [02:00] <sicking> i'd say no
  246. # [02:00] * Quits: danbri (~danbri@ip176-48-210-87.adsl2.static.versatel.nl) (Read error: Connection timed out)
  247. # [02:00] <sicking> since you can't do the thing of "use another site to navigate the user directly to the url thus avoiding the sandbox"
  248. # [02:01] * Joins: danbri (~danbri@ip176-48-210-87.adsl2.static.versatel.nl)
  249. # [02:02] * bga_|away is now known as bga_
  250. # [02:03] <Hixie> sicking: if you block that then you completely prevent the use case adam brought up earlier
  251. # [02:03] <Hixie> sicking: of being able to generate a file on the fly that has scripting disabled
  252. # [02:03] <sicking> Hixie: yup
  253. # [02:04] <Hixie> ok so... that's bad
  254. # [02:04] <sicking> Hixie: you'll note that I said "no" above
  255. # [02:04] <Hixie> oh, sorry, i misunderstood
  256. # [02:04] <Hixie> i thought you meant no, it wouldn't work :-)
  257. # [02:04] <TabAtkins> Hixie: Random sidenote - we found a better term than "superior parent": "originating element"
  258. # [02:05] <Hixie> sicking: if you don't block it, then what stops someone from just redirecting the page to a same-origin url?
  259. # [02:05] <sicking> Hixie: redirecting about:blank?
  260. # [02:05] <Hixie> TabAtkins: i have no idea what either of those terms mean :-) are they xbl-related things?
  261. # [02:05] * Joins: davidb (~davidb@bas1-toronto06-2925210074.dsl.bell.ca)
  262. # [02:05] <Hixie> TabAtkins: "originating element" sounds like something to do with the origin policy?
  263. # [02:06] <Hixie> sicking: as in, you insert an <iframe sandbox> then you document.write() into it a "<meta http-equiv=refresh content=0;URL=local.html">
  264. # [02:06] <Hixie> but with my quotes not screwed up
  265. # [02:06] <sicking> Hixie: then it's a new load, so you'd block that
  266. # [02:07] <Hixie> ew
  267. # [02:07] <TabAtkins> Hixie: Dude, "superior parent" comes from css3-content, to refer to a pseudo-elements "parent".
  268. # [02:07] <Hixie> brb need to find power
  269. # [02:07] <sicking> you want different policies depending on if it's the first document or the second document to be loaded in an iframe?
  270. # [02:11] * Quits: KillerX (~anant@206-15-76-122.static.twtelecom.net) (Quit: KillerX)
  271. # [02:13] <Hixie> sicking: the current mechanism (not sandbox-specific) handles src="" differently than normal in-frame page loads
  272. # [02:14] * Quits: ojan (ojan@nat/google/x-ydarmhswzvigubge) (Quit: ojan)
  273. # [02:14] <sicking> Hixie: huh??
  274. # [02:14] <sicking> Hixie: in what way?
  275. # [02:14] * bga_ is now known as bga_|away
  276. # [02:15] <Hixie> sicking: the src="" attribute loads go through the "process the iframe attributes" algorithm first
  277. # [02:15] <Hixie> sicking: the normal loads don't do anything iframe-specific
  278. # [02:16] <sicking> Hixie: so you can have an <iframe sandbox src="...> which contains a document that isn't sandboxed?
  279. # [02:16] * Quits: smaug____ (~chatzilla@ZYYMKDCCXXVII.gprs.sl-laajakaista.fi) (Ping timeout: 255 seconds)
  280. # [02:16] <sicking> with proper quotes :)
  281. # [02:16] <Hixie> sicking: maybe i didn't understand you proposal though; are you saying that we should block any page loads that have the same origin if the browsing context's sandboxed origin browsing context flag is set?
  282. # [02:16] <Hixie> sicking: no
  283. # [02:16] <Hixie> sicking: the sandboxing is a feature of the browsing context
  284. # [02:17] <Hixie> TabAtkins: aaah
  285. # [02:17] <Hixie> TabAtkins: not sure "originating element" works since it's not necessarily an element, is it?
  286. # [02:17] <Hixie> TabAtkins: as someone who had forgotten what either term meant, i have to say, both terms seemed equally opaque to me just now
  287. # [02:18] <sicking> Hixie: the way it seems to me, we should block any same-origin loads if the browsing context is sandboxed
  288. # [02:18] <sicking> Hixie: or let me rephrase
  289. # [02:18] <sicking> Hixie: the way it seems to me, we should block any loads where the loaded document is same-origin with the parent document, if the browsing context is sandboxed
  290. # [02:20] * Quits: dbaron (~dbaron@206-15-76-122.static.twtelecom.net) (Read error: Operation timed out)
  291. # [02:20] * Joins: astearns (~anonymous@c-50-132-63-33.hsd1.wa.comcast.net)
  292. # [02:22] <Hixie> sicking: that would block about:blank.
  293. # [02:23] <Hixie> (i assume by "is sandboxed" you mean specifically the case of it having the sandboxed origin browsing context flag, not all sandboxing)
  294. # [02:25] * Quits: davidb (~davidb@bas1-toronto06-2925210074.dsl.bell.ca) (Quit: davidb)
  295. # [02:26] * bga_|away is now known as bga_
  296. # [02:33] * bga_ is now known as bga_|away
  297. # [02:35] * Quits: ap (~ap@17.212.155.203) (Quit: ap)
  298. # [02:36] * Quits: danbri (~danbri@ip176-48-210-87.adsl2.static.versatel.nl) (Read error: Connection timed out)
  299. # [02:37] * Joins: danbri (~danbri@ip176-48-210-87.adsl2.static.versatel.nl)
  300. # [02:38] * Quits: jernoble (~jernoble@2620:149:4:1b01:71a3:e63b:c42a:c0f2) (Read error: Connection reset by peer)
  301. # [02:39] * Joins: jernoble (~jernoble@17.212.152.13)
  302. # [02:40] <sicking> Hixie: no, i meant all sandboxing, per the discussion we just had it seems that sandboxing is useless for same-origin loads
  303. # [02:41] <sicking> Hixie: i guess i don't consider about:blank as a "load". But if it is considered a load then add an exception for that
  304. # [02:43] <Hixie> well like i said, there's a difference in handling for initial loads and subsequent loads
  305. # [02:43] * Quits: ZombieLoffe (ZombieL@unaffiliated/zombieloffe)
  306. # [02:43] <Hixie> the initial load of src="" (empty) and src="about:blank" (normalised) is handled specially in the "process the iframe attributes" algorithm
  307. # [02:43] <Hixie> subsequent loads of about:blank are handled in the navigation algorithm
  308. # [02:44] <Hixie> but it would seem crazy to not allow about:blank to navigate to about:blank, say
  309. # [02:45] <sicking> sure, so exclude all about:blank loads
  310. # [02:48] <Hixie> i just said that would be crazy :-P
  311. # [02:48] <Hixie> oh by exlude you mean allow?
  312. # [02:48] <Hixie> man i'm confused
  313. # [02:48] * bga_|away is now known as bga_
  314. # [02:49] <Hixie> this really seems like adding really obscure complexity to the platform to me
  315. # [02:49] <Hixie> are we going to do the same for CSP?
  316. # [02:49] <Hixie> i don't see the difference
  317. # [02:53] * Joins: yuuki (~kobayashi@58x158x182x50.ap58.ftth.ucom.ne.jp)
  318. # [02:56] <sicking> CSP is totally different
  319. # [02:56] <sicking> it applies to all loads, no matter how they happen
  320. # [02:56] <Hixie> how is that different?
  321. # [02:56] <sicking> via sandboxed iframes, non-sandboxed iframes or page navigation
  322. # [02:56] <Hixie> only in new UAs
  323. # [02:57] <Hixie> just like text/html-sandboxed
  324. # [02:58] * Joins: agektmr (~Adium@220.109.219.244)
  325. # [02:59] <sicking> yes, CSP is strictly defense-in-depth
  326. # [02:59] <sicking> that's different from the same-origin issue with sandboxes though
  327. # [02:59] <Hixie> sanbdox is strictly defense-in-depth too.
  328. # [03:00] <Hixie> but i have to go now. ttyl :-)
  329. # [03:00] <sicking> ok, ttyl
  330. # [03:00] <Hixie> i recommend e-mailing the whatwg list to get others in the loop
  331. # [03:01] * Joins: asmodai (asmodai@178-85-121-247.dynamic.upc.nl)
  332. # [03:09] * jernoble is now known as jernoble|afk
  333. # [03:09] <TabAtkins> Hixie or abarth: What should we reference for the definition of URL in CSS? We're currently referring to RFC 3986.
  334. # [03:12] <TabAtkins> Hixie or abarth: Our current definition is at http://dev.w3.org/csswg/css3-values/#urls
  335. # [03:20] * bga_ is now known as bga_|away
  336. # [03:20] * Quits: bga_|away (~bga@95-55-63-29.dynamic.avangarddsl.ru) (Read error: Connection reset by peer)
  337. # [03:20] <rniwa> Hixie, sicking: yt?
  338. # [03:38] * Joins: dbaron (~dbaron@173-228-28-227.dsl.dynamic.sonic.net)
  339. # [03:50] * Quits: dbaron (~dbaron@173-228-28-227.dsl.dynamic.sonic.net) (Ping timeout: 252 seconds)
  340. # [03:54] * Quits: danbri (~danbri@ip176-48-210-87.adsl2.static.versatel.nl) (Read error: Operation timed out)
  341. # [03:54] * Joins: danbri (~danbri@ip176-48-210-87.adsl2.static.versatel.nl)
  342. # [03:58] * Quits: jacobolus (~jacobolus@c-71-198-169-213.hsd1.ca.comcast.net) (Remote host closed the connection)
  343. # [04:01] * Quits: nonge_ (~nonge@p5082B423.dip.t-dialin.net) (Ping timeout: 240 seconds)
  344. # [04:02] * Joins: nonge_ (~nonge@p5082B423.dip.t-dialin.net)
  345. # [04:07] * Joins: hij1nx (~hij1nx@cpe-98-14-168-178.nyc.res.rr.com)
  346. # [04:07] * Quits: dave_levin (dave_levin@nat/google/x-xznwzburyehprmdn) (Quit: dave_levin)
  347. # [04:08] * Quits: rniwa (rniwa@nat/google/x-puzqxyvljwfgufot) (Quit: rniwa)
  348. # [04:10] * Quits: agektmr (~Adium@220.109.219.244) (Read error: Connection reset by peer)
  349. # [04:10] * Joins: agektmr1 (~Adium@220.109.219.244)
  350. # [04:10] * heycam is now known as heycam|away
  351. # [04:12] * Quits: hij1nx (~hij1nx@cpe-98-14-168-178.nyc.res.rr.com) (Client Quit)
  352. # [04:26] * Quits: agektmr1 (~Adium@220.109.219.244) (Quit: Leaving.)
  353. # [04:37] * Joins: agektmr (~Adium@220.109.219.244)
  354. # [04:40] * Quits: danbri (~danbri@ip176-48-210-87.adsl2.static.versatel.nl) (Read error: Connection timed out)
  355. # [04:41] * Joins: danbri (~danbri@ip176-48-210-87.adsl2.static.versatel.nl)
  356. # [04:42] * Quits: jamesr (jamesr@nat/google/x-hcvbpiikrmzskigr) (Quit: jamesr)
  357. # [04:47] * Joins: dbaron (~dbaron@173-228-28-227.dsl.dynamic.sonic.net)
  358. # [04:56] * Quits: agektmr (~Adium@220.109.219.244) (Quit: Leaving.)
  359. # [05:00] * Joins: J_Voracek (~J_Voracek@71.21.195.70)
  360. # [05:00] * Quits: J_Voracek (~J_Voracek@71.21.195.70) (Client Quit)
  361. # [05:01] * Quits: jwalden (~waldo@2620:101:8003:200:224:d7ff:fef0:8d90) (Quit: ChatZilla 0.9.87-2.1450hg.fc15 [XULRunner 7.0.1/20110930134335])
  362. # [05:02] * Joins: agektmr (~Adium@220.109.219.244)
  363. # [05:06] * Quits: benjoffe (~benjoffe_@CPE-121-218-225-100.lnse4.cht.bigpond.net.au) (Remote host closed the connection)
  364. # [05:09] * Quits: agektmr (~Adium@220.109.219.244) (Quit: Leaving.)
  365. # [05:12] * Joins: jacobolus (~jacobolus@67.164.92.84)
  366. # [05:13] * Joins: benjoffe_ (~benjoffe_@CPE-121-218-225-100.lnse4.cht.bigpond.net.au)
  367. # [05:15] * Quits: fishd (darin@nat/google/x-dbcwqstphpixmesp) (Read error: Connection reset by peer)
  368. # [05:15] * Joins: fishd (darin@nat/google/x-hqgatulheztkgllz)
  369. # [05:19] * heycam|away is now known as heycam
  370. # [05:21] * Joins: annevk (~annevk@EM1-113-12-168.pool.e-mobile.ne.jp)
  371. # [05:21] <annevk> TabAtkins, CSS URL values are parsed the same as in HTML
  372. # [05:22] <annevk> TabAtkins, though UTF-8 is enforced, just like in XMLHttpRequest
  373. # [05:22] <annevk> TabAtkins, 3986 is wrong, but there's not really a good replacement at the moment
  374. # [05:22] <annevk> I think we should just put everything into the URL specification
  375. # [05:22] <annevk> API, syntax, etc.
  376. # [05:24] * Joins: jamesr (~jamesr@173-164-251-190-SFBA.hfc.comcastbusiness.net)
  377. # [05:25] * Quits: ezoe (~ezoe@203-140-89-83f1.kyt1.eonet.ne.jp) (Read error: Connection reset by peer)
  378. # [05:31] * Quits: cpearce (~chatzilla@60.234.54.74) (Ping timeout: 258 seconds)
  379. # [05:31] * Quits: nonge_ (~nonge@p5082B423.dip.t-dialin.net) (Ping timeout: 252 seconds)
  380. # [05:33] * Quits: danbri (~danbri@ip176-48-210-87.adsl2.static.versatel.nl) (Read error: Connection timed out)
  381. # [05:34] * Joins: danbri (~danbri@ip176-48-210-87.adsl2.static.versatel.nl)
  382. # [05:40] * Parts: annevk (~annevk@EM1-113-12-168.pool.e-mobile.ne.jp)
  383. # [05:41] * Joins: annevk (~annevk@EM1-113-12-168.pool.e-mobile.ne.jp)
  384. # [05:43] * Joins: nonge_ (~nonge@p50829383.dip.t-dialin.net)
  385. # [05:49] * Quits: danbri (~danbri@ip176-48-210-87.adsl2.static.versatel.nl) (Ping timeout: 252 seconds)
  386. # [06:02] * Joins: hij1nx (~hij1nx@cpe-98-14-168-178.nyc.res.rr.com)
  387. # [06:04] * Joins: rabbi1 (~manjunath@49.249.143.34)
  388. # [06:05] * Joins: cpearce (~chatzilla@ip-118-90-78-13.xdsl.xnet.co.nz)
  389. # [06:06] <sicking> annevk: ping
  390. # [06:06] * Quits: rabbi1 (~manjunath@49.249.143.34) (Client Quit)
  391. # [06:07] <annevk> hey sicking
  392. # [06:07] <sicking> annevk: i don't understand your email regarding the CORS change
  393. # [06:07] <sicking> annevk: can you give an example scenario which you're proposing should change
  394. # [06:08] <annevk> you xhr to from a to b
  395. # [06:08] <annevk> b doe set-cookie
  396. # [06:08] <annevk> withCredentials is true
  397. # [06:08] <annevk> does*
  398. # [06:08] <annevk> b also fails the sharing check
  399. # [06:08] <annevk> Gecko/WebKit set the cookie
  400. # [06:09] <sicking> "fails the sharing check" === "doesn't set access-control-allow-origin to the 'correct' value"?
  401. # [06:09] <annevk> a similar situation with <img crossorigin> is not supposed to set a cookie
  402. # [06:09] <annevk> sicking, for instance, or does not include the header
  403. # [06:09] <annevk> sicking, does not include the credentials header
  404. # [06:09] <sicking> ok
  405. # [06:10] <sicking> hmm.. why doesn't HTML5 simply defer to CORS on this?
  406. # [06:10] <sicking> i'm not sure how to implement this in Gecko...
  407. # [06:10] <sicking> by the time the response gets to the CORS code, the networking library has already set the cookie
  408. # [06:10] <sicking> so i guess we don't follow the HTML5 spec on this, if it indeed demands that behavior
  409. # [06:11] <annevk> HTML says
  410. # [06:11] <annevk> "For the purposes of the calling algorithm, the user agent must act as if there was a fatal network error and no resource was obtained."
  411. # [06:11] <annevk> no resource obtained means no cookie
  412. # [06:11] * Joins: agektmr (~Adium@220.109.219.244)
  413. # [06:11] <sicking> depends on what "the calling algorithm" refers to
  414. # [06:12] <sicking> does it refer to the <img> algorithm which downloads and parses an image?
  415. # [06:12] <annevk> fetch
  416. # [06:13] <annevk> we could also change HTML I suppose
  417. # [06:13] <sicking> which layers of the ISO layer model does "fetch" include?
  418. # [06:13] <annevk> it just seems slightly saner to not alter cookies
  419. # [06:13] <annevk> ISO?
  420. # [06:13] * Quits: dbaron (~dbaron@173-228-28-227.dsl.dynamic.sonic.net) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  421. # [06:14] <sicking> OSI
  422. # [06:15] <annevk> still no clue :)
  423. # [06:15] <sicking> annevk: so the algorithm defined in the HTML spec also never sets the UAs cookies. So aborting the algorithm wouldn't seem to affect whether cookies are set
  424. # [06:15] <sicking> http://en.wikipedia.org/wiki/OSI_model
  425. # [06:15] <annevk> fetch sets cookies
  426. # [06:16] <annevk> we should define CORS and fetch in one spec really
  427. # [06:16] <annevk> but you know, lots of work refactoring those two
  428. # [06:17] <sicking> ah, yes
  429. # [06:17] <sicking> it'll still be hard to implement this, since it means violating the HTTP layer model
  430. # [06:18] <sicking> i.e. you can't use a plain HTTP library to do the load
  431. # [06:18] <sicking> i do sort of understand/like the idea. It'll just be very hacky to implement
  432. # [06:18] <annevk> a plain HTTP library does not do cookies
  433. # [06:19] <sicking> annevk: well.. i guess that's a matter of definition
  434. # [06:19] <sicking> ours does
  435. # [06:19] <annevk> if cookies are part of HTTP, so is CORS
  436. # [06:19] <annevk> aaah, so whatever Gecko's HTTP library does is plain :)
  437. # [06:20] <sicking> i don't expect we're the only ones to put cookies into the http library
  438. # [06:20] <annevk> for Opera it's no problem either way
  439. # [06:20] <sicking> for any browser it makes a lot of sense to have a layer that you can call into which does http including cookies and cache
  440. # [06:21] <annevk> that same library should prolly do CORS though
  441. # [06:21] <annevk> given the potentially CORS-enabled fetching stuff
  442. # [06:21] <sicking> annevk: arguably, but that'll require more refactoring than spec changes ;-)
  443. # [06:21] <sicking> annevk: i guess I'm fine with it if other browsers agree. Would be nice to have a more understandable email to the group though.
  444. # [06:26] <annevk> sicking, I emailed a reply to myself explaining it more clearly (hopefully)
  445. # [06:31] * Quits: agektmr (~Adium@220.109.219.244) (Quit: Leaving.)
  446. # [06:34] <heycam> hmm, 1323 unread public-html mails. wonder if there's anything worth reading in there...
  447. # [06:35] * Quits: cpearce (~chatzilla@ip-118-90-78-13.xdsl.xnet.co.nz) (Ping timeout: 248 seconds)
  448. # [06:35] <annevk> hey
  449. # [06:35] <annevk> look who's back
  450. # [06:37] <Hixie> here now
  451. # [06:37] <Hixie> what's up
  452. # [06:38] <heycam> hi annevk
  453. # [06:38] <heycam> (and sicking, from before!)
  454. # [06:39] <sicking> annevk: thanks! I sent a reply. I generally think I agree with the change, though I have no idea when we'd be able to implement :(
  455. # [06:39] <sicking> annevk: our network library has this very silly policy of not having any security code in it.
  456. # [06:40] <sicking> annevk: We've abandoned the policy, but it's a slow process to change
  457. # [06:40] <annevk> Hixie, HTML applies a slightly stricter set of rules to CORS with respect to cookies
  458. # [06:40] <Hixie> that is unintentional if so
  459. # [06:41] <Hixie> let me check
  460. # [06:41] <annevk> Hixie, but we like it
  461. # [06:41] * sicking wonders if darin actually made a bad decision!?!
  462. # [06:41] <annevk> Hixie, it's the bit about completely ignoring the response resource if the resource sharing check fails
  463. # [06:41] <Hixie> cookies get set in step 6.3 of the fetch algorithm
  464. # [06:42] <annevk> "For the purposes of the calling algorithm, the user agent must act as if there was a fatal network error and no resource was obtained."
  465. # [06:42] <annevk> if there's no resource, there's no cookies
  466. # [06:42] <Hixie> that happnes long after the cookies are set
  467. # [06:43] <annevk> oh really?
  468. # [06:43] <Hixie> i'm assuming you're talking about a potentially CORS-enabled fetch right?
  469. # [06:43] <annevk> no
  470. # [06:43] <Hixie> oh
  471. # [06:43] <Hixie> which case do you mean then
  472. # [06:43] <annevk> oh yes
  473. # [06:43] <Hixie> ok
  474. # [06:43] <annevk> <img crossorigin> for instance
  475. # [06:43] <Hixie> so assume mode = Use Credentials
  476. # [06:43] <Hixie> we start the algorithm
  477. # [06:44] * Quits: jacobolus (~jacobolus@67.164.92.84) (Ping timeout: 260 seconds)
  478. # [06:44] <Hixie> step 1 calls CORS "cross-origin request", section 7.1 of CORS
  479. # [06:44] <Hixie> step 2 of that calls the "simple cross-origin request"
  480. # [06:44] <Hixie> section 7.1.4 of CORS
  481. # [06:44] <Hixie> step 1 of that calls "make a request steps"
  482. # [06:44] <Hixie> in section 7.1.7 of CORS
  483. # [06:45] <Hixie> that calls "fetch" in HTML
  484. # [06:45] <Hixie> oh but it has the block cookies flag set
  485. # [06:45] <Hixie> interesting
  486. # [06:45] <Hixie> ok then <img crossorigin> never sets cookies one way or the other currently
  487. # [06:45] <Hixie> oops
  488. # [06:47] * Quits: Stikki (~lordstich@dsl-pribrasgw1-ff17c300-80.dhcp.inet.fi) (Ping timeout: 260 seconds)
  489. # [06:47] <Hixie> annevk: when does XHR set cookies?
  490. # [06:50] <annevk> block cookies is only set if credentials is false
  491. # [06:50] <annevk> but credentials is true here
  492. # [06:50] <annevk> you said assume mode = Use Credentials
  493. # [06:50] <annevk> XHR sets cookies whenever "fetch" does
  494. # [06:51] <annevk> really need to merge CORS and fetch and I really do not want to
  495. # [06:51] <annevk> can't we have some Google code projects on specs next time that is up?
  496. # [06:51] <annevk> Google Summer of Code I meant
  497. # [06:53] <heycam> or a NaNo(WebSpec)Mo
  498. # [06:53] <Hixie> oh well
  499. # [06:53] <Hixie> ok
  500. # [06:53] <Hixie> so if credentials is true
  501. # [06:53] <Hixie> then let me continue:
  502. # [06:53] <Hixie> that calls "fetch" in HTML
  503. # [06:53] <Hixie> "fetch" then does the stuff, gets to step 6
  504. # [06:54] <Hixie> step 6.3 sets cookies
  505. # [06:54] <Hixie> then fetch starts firing tasks
  506. # [06:54] * Joins: MikeSmith_ (~MikeSmith@EM114-48-115-238.pool.e-mobile.ne.jp)
  507. # [06:55] <Hixie> looks like you should be calling "fetch" with the synchronous flag set btw
  508. # [06:55] <Hixie> either that or talk about getting the data from the tasks it fires
  509. # [06:55] <Hixie> but anyway
  510. # [06:55] <Hixie> ignoring that
  511. # [06:55] <Hixie> back to "simple cross-origin request"
  512. # [06:55] <Hixie> it goes into the "otherwise" branch, which calls "resource sharing check"
  513. # [06:56] <Hixie> section 7.2 of CORS
  514. # [06:56] * Quits: annevk (~annevk@EM1-113-12-168.pool.e-mobile.ne.jp) (Ping timeout: 255 seconds)
  515. # [06:56] <Hixie> step 1 sees no Access-Control-Allow-Origin header values so it returns fail
  516. # [06:56] <Hixie> so back to "simple cross-origin request"; it calls the "network error steps"
  517. # [06:56] <Hixie> in 7.1.7
  518. # [06:56] <Hixie> that sets cross-origin request status to /network error/
  519. # [06:57] <Hixie> and aborts "simple cross-origin request"
  520. # [06:57] * Quits: MikeSmith (~MikeSmith@EM1-113-12-168.pool.e-mobile.ne.jp) (Ping timeout: 245 seconds)
  521. # [06:57] * MikeSmith_ is now known as MikeSmith
  522. # [06:57] <Hixie> so we're back to "cross-origin request", which just returns since it's finished too
  523. # [06:58] <Hixie> so, we're back to the HTML spec's "potentially CORS-enabled fetch"
  524. # [06:58] * Joins: erlehmann (~erlehmann@89.204.137.88)
  525. # [06:58] <Hixie> second branch, step 2. That waits for the CORS cross-origin request status to have a value, which it does
  526. # [06:58] <Hixie> so then step 3
  527. # [06:58] <Hixie> goes through the first branch, since it's not "success"
  528. # [06:58] <Hixie> all the tasks are discarded, and it returns a fatal network error
  529. # [06:58] <Hixie> but the cookies are already set
  530. # [06:59] <Hixie> since they were set way back when before CORS was checked
  531. # [06:59] <Hixie> here ends my story
  532. # [07:00] * Joins: agektmr (~Adium@220.109.219.244)
  533. # [07:03] * Joins: annevk (~annevk@114.48.115.238)
  534. # [07:04] <annevk> o_O
  535. # [07:05] <Hixie> why o_O?
  536. # [07:05] * Quits: erlehmann (~erlehmann@89.204.137.88) (Quit: Ex-Chat)
  537. # [07:07] * Joins: Stikki (~lordstich@dsl-pribrasgw1-ff17c300-80.dhcp.inet.fi)
  538. # [07:08] <annevk> complicated :)
  539. # [07:08] * Quits: agektmr (~Adium@220.109.219.244) (Quit: Leaving.)
  540. # [07:08] <Hixie> you wrote most of it! :-P
  541. # [07:11] * Joins: agektmr (~Adium@220.109.219.244)
  542. # [07:17] * Joins: fishd_ (darin@nat/google/x-tolgyhgjqhhifgrm)
  543. # [07:17] * Quits: roc (~chatzilla@60.234.54.74) (Ping timeout: 248 seconds)
  544. # [07:18] * Quits: fishd (darin@nat/google/x-hqgatulheztkgllz) (*.net *.split)
  545. # [07:18] * Quits: dydx (~dydz@adsl-75-37-25-16.dsl.pltn13.sbcglobal.net) (*.net *.split)
  546. # [07:18] * Quits: lhnz (~lhnz@188-223-83-48.zone14.bethere.co.uk) (*.net *.split)
  547. # [07:18] * Quits: ukai (ukai@nat/google/x-xqrtxikemoruymqv) (*.net *.split)
  548. # [07:18] * Quits: hamaji (~hamaji@220.109.219.244) (*.net *.split)
  549. # [07:18] * Quits: Hixie (~ianh@trivini.no) (*.net *.split)
  550. # [07:18] * Quits: romainhuet (u2533@gateway/web/irccloud.com/x-kgagqzjfsstfntxa) (*.net *.split)
  551. # [07:18] * Quits: slightlyoff (u1768@gateway/web/irccloud.com/x-leutuazhgomfkzqq) (*.net *.split)
  552. # [07:18] * Quits: tmzt_ (~tmzt@adsl-69-208-11-149.dsl.akrnoh.ameritech.net) (*.net *.split)
  553. # [07:18] * Quits: benschwarz (u2121@gateway/web/irccloud.com/x-arvwvlkaudklrkjq) (*.net *.split)
  554. # [07:18] * Quits: silky (~silky@pool-74-108-142-22.nycmny.fios.verizon.net) (*.net *.split)
  555. # [07:18] * Quits: reggna (~reggna@godis.olf.sgsnet.se) (*.net *.split)
  556. # [07:19] * Joins: fishd (darin@nat/google/x-hqgatulheztkgllz)
  557. # [07:19] * Joins: dydz (~dydz@adsl-75-37-25-16.dsl.pltn13.sbcglobal.net)
  558. # [07:19] * Joins: lhnz (~lhnz@188-223-83-48.zone14.bethere.co.uk)
  559. # [07:19] * Joins: ukai (ukai@nat/google/x-xqrtxikemoruymqv)
  560. # [07:19] * Joins: hamaji (~hamaji@220.109.219.244)
  561. # [07:19] * Joins: Hixie (~ianh@trivini.no)
  562. # [07:19] * Joins: silky (~silky@pool-74-108-142-22.nycmny.fios.verizon.net)
  563. # [07:19] * Joins: romainhuet (u2533@gateway/web/irccloud.com/x-kgagqzjfsstfntxa)
  564. # [07:19] * Joins: slightlyoff (u1768@gateway/web/irccloud.com/x-leutuazhgomfkzqq)
  565. # [07:19] * Joins: tmzt_ (~tmzt@adsl-69-208-11-149.dsl.akrnoh.ameritech.net)
  566. # [07:19] * Joins: benschwarz (u2121@gateway/web/irccloud.com/x-arvwvlkaudklrkjq)
  567. # [07:19] * Joins: reggna (~reggna@godis.olf.sgsnet.se)
  568. # [07:20] * Joins: riven` (~riven@53518387.cm-6-2c.dynamic.ziggo.nl)
  569. # [07:20] * Quits: fishd (darin@nat/google/x-hqgatulheztkgllz) (Ping timeout: 244 seconds)
  570. # [07:21] * Joins: rimantas (~rimliu@93.93.57.193)
  571. # [07:22] * Joins: rniwa (~rniwa@70-89-66-218-ca.sfba.hfc.comcastbusiness.net)
  572. # [07:24] * Quits: riven (~riven@pdpc/supporter/professional/riven) (Ping timeout: 244 seconds)
  573. # [07:26] * Joins: robman (~robman@eth4584.nsw.adsl.internode.on.net)
  574. # [07:31] * Joins: FlorianX (~Florian_S@p4FE2D2FC.dip.t-dialin.net)
  575. # [07:34] * Quits: jamesr (~jamesr@173-164-251-190-SFBA.hfc.comcastbusiness.net) (Quit: jamesr)
  576. # [07:35] * Joins: Rik`_ (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net)
  577. # [07:35] * Quits: Rik` (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net) (Read error: Connection reset by peer)
  578. # [07:39] * Joins: jacobolus (~jacobolus@c-71-198-174-224.hsd1.ca.comcast.net)
  579. # [07:42] * Rik`_ is now known as Rik`
  580. # [07:43] * Joins: jacobolu_ (~jacobolus@c-71-198-169-213.hsd1.ca.comcast.net)
  581. # [07:43] * nunnun_away is now known as nunnun
  582. # [07:45] <annevk> yeah I guess we should do new Text()
  583. # [07:46] <annevk> prolly should revert the overloading change and start with that
  584. # [07:46] <annevk> still not really sure of the new EVERYTHING() plan
  585. # [07:46] <annevk> new HTMLDivElement() is so ugly
  586. # [07:46] <annevk> new Div() would be kind of neat
  587. # [07:46] * Quits: jacobolus (~jacobolus@c-71-198-174-224.hsd1.ca.comcast.net) (Ping timeout: 240 seconds)
  588. # [07:46] <Hixie> new HTMLUnknownElement()
  589. # [07:46] <Hixie> new HTML*Element() in general just doesn't work
  590. # [07:47] <annevk> so alex thinks it should work and should just result in a useless object
  591. # [07:48] <annevk> but I'm not sure what the point of that is
  592. # [07:48] <Hixie> yeah i pretty strongly disagree with alex on this issue
  593. # [07:51] <heycam> new HTMLDivElement() is indeed ugly
  594. # [07:51] <heycam> I would like new Element("div")
  595. # [07:52] <annevk> that returns a non-Element object?
  596. # [07:52] <heycam> don't think it matters too much that the return type is something more specific than Element -- it at least is a kind of Element
  597. # [07:52] * Quits: rniwa (~rniwa@70-89-66-218-ca.sfba.hfc.comcastbusiness.net) (Quit: rniwa)
  598. # [07:52] <annevk> hmm
  599. # [07:52] <heycam> I think "Element" is nice and short enough
  600. # [07:52] <annevk> Element.create is pretty short too
  601. # [07:52] <heycam> but not as :)
  602. # [07:53] <annevk> node.append(["div"]) would be even shorter
  603. # [07:53] <annevk> see some emails on www-dom
  604. # [07:53] <heycam> so I agree with Alex that we should encourage constructors where possible, it's just that I don't know that forcing spec writers to specify constructor behaviour on everything is the best (or most polite) way to do that
  605. # [07:54] <annevk> we can just add [NoConstructor] everywhere until the concrete proposals arrive
  606. # [07:54] <heycam> guess so
  607. # [07:54] <annevk> or we can skip the make work and wait for the latter
  608. # [07:54] <heycam> still seems kinda rude for webidl to force that
  609. # [07:54] * Joins: nimbupani (~divyam@219.64.117.145)
  610. # [07:54] * nimbupani is now known as divya
  611. # [07:54] <annevk> I was being sarcastic
  612. # [07:55] <annevk> I think what we have now is good and people should make concrete proposals for constructors where they are needed
  613. # [07:55] <heycam> sarcasm with no indicating punctuation!
  614. # [07:55] <annevk> if we end up with constructors everywhere, we can make them optional
  615. # [07:56] <annevk> heycam, the horror!
  616. # [07:56] <annevk> next you claim it's inaccessible
  617. # [07:56] <Hixie> i think the json-like description of elements is kinda crazy, personally
  618. # [07:56] <annevk> crazy-neat?
  619. # [07:57] <heycam> many people write helper functions to do that json-like thing
  620. # [07:58] <Hixie> crazy ugly and incomprehensible
  621. # [07:58] <heycam> i'm a bit wary of potential confusion over whether it sets js properties, dom attributes, magic with onfoo handlers, etc.
  622. # [07:58] <Hixie> if we're going that route, please for the love of kittens just use E4X or something similar
  623. # [07:58] <heycam> ha
  624. # [08:00] * Joins: ezoe (~ezoe@112-68-244-76f1.kyt1.eonet.ne.jp)
  625. # [08:01] <annevk> E4X yeah right
  626. # [08:01] * Quits: nessy (~Adium@74.125.56.18) (Quit: Leaving.)
  627. # [08:01] <annevk> heycam, ah yeah, guess we'll end up with attributes and on* as event handlers
  628. # [08:01] <annevk> if we do it
  629. # [08:01] <heycam> :/
  630. # [08:02] <heycam> hopefully as separate arguments?
  631. # [08:02] <heycam> i.e. not intermingled on the one object passed in?
  632. # [08:02] <annevk> that was the idea initially, but is that really worth it?
  633. # [08:03] <heycam> dunno, it just rubs me the wrong way somehow, treating /^on/ attributes differently
  634. # [08:03] <heycam> (do we have any non event listener attributes that begin with "on"?)
  635. # [08:04] * Joins: zcorpan (~zcorpan@c-df9be355.410-6-64736c14.cust.bredbandsbolaget.se)
  636. # [08:04] <annevk> don't think so
  637. # [08:04] * Joins: dirkpennings (~Vuurbal@90-145-26-140.bbserv.nl)
  638. # [08:05] <heycam> even if we don't, I wouldn't like to rule out such attributes because Element.create or whatever would treat them as event names after the "on"
  639. # [08:06] <heycam> "1emu = 1pt/12700"
  640. # [08:06] <heycam> I would've expected an emu to be a kind of large unit
  641. # [08:06] * Joins: mishunov (~spliter@212.17.143.210)
  642. # [08:06] * Quits: mishunov (~spliter@212.17.143.210) (Client Quit)
  643. # [08:07] * dglazkov is now known as dglazkov|away
  644. # [08:08] * Joins: GlitchMr (~glitchmr@178-36-32-130.adsl.inetia.pl)
  645. # [08:10] <annevk> heycam, given that X is going to be optimized for web platform elements I do not think that's a problem
  646. # [08:12] <annevk> but then I'm still not sure whether we should do X (e.g. Element.create) at all, plus all the other various DOM methods ojan is proposing
  647. # [08:13] * heycam probably skimmed past that email
  648. # [08:13] <annevk> "modifying the DOM WAS: Node append"
  649. # [08:14] * Quits: aho (~nya@fuld-590c7bda.pool.mediaWays.net) (Quit: EXEC_over.METHOD_SUBLIMATION)
  650. # [08:22] * Joins: Rich_Clark (~chatzilla@94-193-82-82.zone7.bethere.co.uk)
  651. # [08:23] <annevk> heycam, so the one thing we need for that is unbounded dictionaries
  652. # [08:24] <heycam> yeah
  653. # [08:24] <annevk> heycam, so there's still a defined processing order and everything
  654. # [08:24] <heycam> I just avoided adding that until there were concrete needs for it
  655. # [08:24] <annevk> okay
  656. # [08:26] <annevk> it would be great if we could discuss these proposals with various implementors
  657. # [08:26] <annevk> it seems pretty clear authors want some simplified way of doing things
  658. # [08:26] <heycam> (is that not what the www-dom discussion is achieving?)
  659. # [08:26] <annevk> everyone has their own convenience method / templating system
  660. # [08:26] <annevk> yeah, though I'm missing sicking / othermaciej
  661. # [08:26] <heycam> yeah, it is tough to standardise a templating system -- it's almost entirely a syntax debate
  662. # [08:27] <annevk> actually, not sicking
  663. # [08:27] <annevk> I do think that if we want to simplify the DOM having element templates would be huge step
  664. # [08:28] <annevk> and keeps people from using innerHTML which has all the badness of string concatenation
  665. # [08:28] <annevk> well hopefully keeps them away from it, no guarantees
  666. # [08:28] <heycam> sprintf
  667. # [08:28] <Hixie> the biggest problem with innerHTML is the lack of compile-time syntax checking
  668. # [08:31] <annevk> the array stuff gives you that to some extent
  669. # [08:31] * Quits: dydz (~dydz@adsl-75-37-25-16.dsl.pltn13.sbcglobal.net) (Quit: dydz)
  670. # [08:31] <annevk> prolly about as far as E4X
  671. # [08:31] <Hixie> yes but it's 10x as verbose
  672. # [08:31] <Hixie> and uglier than Element.create()
  673. # [08:31] <annevk> hmm
  674. # [08:32] <annevk> <div class="test"/>
  675. # [08:32] <annevk> ["div", {class:"test"}]
  676. # [08:32] <annevk> not too bad
  677. # [08:32] <Hixie> uh huh
  678. # [08:33] <heycam> I just some more sarcasm without punctuation :)
  679. # [08:33] <heycam> *detected some
  680. # [08:33] <Hixie> :-)
  681. # [08:33] <annevk> if you write </div> instead you even save a character
  682. # [08:34] <Hixie> what's <div><p><span>TEST</span></p></div> in your syntax?
  683. # [08:34] <heycam> I find the purely arrays/strings/object literals too hard to read
  684. # [08:34] <Hixie> yes
  685. # [08:34] <heycam> even though I'm guilty of writing functions like that for my own purposes
  686. # [08:34] <heycam> because I hate to use so many method calls :)
  687. # [08:35] <Hixie> i use duct tape for private use, too. i wouldn't try to sell a product made with duct tape.
  688. # [08:35] <heycam> so I wonder, without having written out an example, if a small amount of verbosity like requiring new Element("div", { class: "test" }) rather than just using an array with a string in first position to mean the tag name, would help make it more readable
  689. # [08:35] <annevk> ["div", ["p", ["span", "TEST"]]]
  690. # [08:36] <annevk> it wins again
  691. # [08:36] <Hixie> wow
  692. # [08:36] <Hixie> wins is so not the word i was going to use
  693. # [08:36] <heycam> lol
  694. # [08:44] <jacobolu_> burn
  695. # [08:44] * jacobolu_ is now known as jacobolus
  696. # [08:45] <annevk> I'm not sure
  697. # [08:45] <jacobolus> Hixie: you don't think having some kind of structured way to write these that's not a string would be helpful?
  698. # [08:45] <annevk> I'm not the one who claimed "10x as verbose"
  699. # [08:45] <Hixie> jacobolus: i absolutely think it would be helpful
  700. # [08:45] <Hixie> jacobolus: i think E4X would be the way to go
  701. # [08:45] <Hixie> jacobolus: or, within JS itself, nested Element.create() calls
  702. # [08:45] <jacobolus> oh. I'm not very familiar w/ e4x
  703. # [08:46] <jacobolus> wait, you just write xml inline w/ the javascript?
  704. # [08:46] <Hixie> annevk: not 10x longer, just 10x more verbose
  705. # [08:46] <jacobolus> ick
  706. # [08:46] <heycam> I think a structured way to write these things is good, it's just that using only [] and {} as the delimiters makes it far from readable
  707. # [08:46] <heycam> I would happily sacrifice some conciseness for readability
  708. # [08:46] <Hixie> annevk: there's way more punctuation going on in ways that really make it very hard to work out what's going on
  709. # [08:47] <Hixie> annevk: e.g. "foo", "foo" should never be able to represent an element containing a text node
  710. # [08:47] <Hixie> annevk: that's just batty
  711. # [08:47] * heycam easily envisages calls to this Element.create ending with ]]]}]]]}]});
  712. # [08:48] <annevk> Hixie, hmm, at the end of the array you have either other elements or text nodes; I don't think it's too bad
  713. # [08:48] <heycam> would be nice if the whatwg mailing list software included an Archived-At header (probably someone has requested this before)
  714. # [08:48] <annevk> Hixie, you do have to know the model of course, otherwise it is indeed kind of hard
  715. # [08:48] <annevk> heycam, lots of people have
  716. # [08:49] <annevk> heycam, I was planning on writing some intermediary script at one point, but never did
  717. # [08:50] <annevk> my idea was passing he Message-ID after some URL that would have some kind of lookup and do redirects
  718. # [08:50] <annevk> the*
  719. # [08:51] <Hixie> heycam: tell dreamhost :-(
  720. # [08:51] <heycam> annevk, oh yeah, like w3.org/mid/...
  721. # [08:51] <Hixie> annevk: good APIs are intuitive
  722. # [08:52] <annevk> it's not exactly less or more intuitive than the Element.create proposal
  723. # [08:52] <annevk> or new Event()
  724. # [08:54] <jacobolus> Hixie: what's an intuitive DOM creation/query/manipulation API in your view?
  725. # [08:54] <Hixie> annevk: as an extreme example, I would say Element.create("div", {title: "bar"}, ["Hello"]); is more intuitive than Element.create(["div", {title: "bar"}, ["Hello"]]);, because in the latter one there's one argument, and it's not clear that one array's values mean different things, whereas in the former it's clear that the arguments mean different things, and it seems obvious that an element creation method would start with an element name, and you can work out the
  726. # [08:54] <Hixie> jacobolus: well, an intuitive creation one would be: var mydiv = <div/>;
  727. # [08:55] <jacobolus> but just making that a string in a simple function is just as good at that point, ISTM
  728. # [08:55] <Hixie> (i wouldn't take anything from E4X other than the element literals, fwiw)
  729. # [08:55] <Hixie> jacobolus: strings aren't syntax-checked
  730. # [08:55] * Quits: hij1nx (~hij1nx@cpe-98-14-168-178.nyc.res.rr.com) (Quit: hij1nx)
  731. # [08:55] <jacobolus> syntax-checked by whom?
  732. # [08:55] <Hixie> the compiler
  733. # [08:55] * Joins: tomasf (~tomasf@77.72.97.5.c.fiberdirekt.net)
  734. # [08:56] <Hixie> jacobolus: consider the difference between var mytree = <p><i>hello</b> world</p>; and var mytree = "<p><i>hello</b> world</p>";
  735. # [08:56] <Hixie> jacobolus: how long do you think it would take to catch those two errors?
  736. # [08:56] <jacobolus> so then a question... how do you make it dynamic?
  737. # [08:56] <jacobolus> i.e. if I want to stick some custom stuff in halfway through
  738. # [08:56] <Hixie> for the first one, i'd say about 1 second to catch it, and about 3 seconds to fix it. for the second, it might never get caught, but it's probably measured in weeks or months.
  739. # [08:57] <Hixie> E4X had a mechanism for that
  740. # [08:57] <Hixie> something like var name = 'jacobolus'; var mydiv = <div>Hello {name}</div>;
  741. # [08:57] <jacobolus> hm
  742. # [08:58] <jacobolus> so why couldn't you just make it a function w/ some name
  743. # [08:58] <Hixie> (you can test it in mozilla, it ships with e4x)
  744. # [08:58] <Hixie> a function?
  745. # [08:58] <jacobolus> and pass in a string
  746. # [08:58] <jacobolus> and then have tooling
  747. # [08:58] <Hixie> strings aren't syntax checked
  748. # [08:58] <jacobolus> that would do the syntax checing
  749. # [08:58] <jacobolus> *checking
  750. # [08:58] <jacobolus> that could easily be done in e.g. a text editor, linter, etc.
  751. # [08:59] <Hixie> not as easily as "the compiler won't run the code while it's broken"
  752. # [08:59] <Hixie> and the difference is enough that nobody does what you're suggesting
  753. # [08:59] <jacobolus> they do for regexps in python, as one example
  754. # [09:00] <Hixie> maybe python developers are better than js developers?
  755. # [09:00] <jacobolus> heh
  756. # [09:01] <jacobolus> are there any people who have written descriptive praises of E4X?
  757. # [09:01] <Hixie> descriptive praises?
  758. # [09:01] * Joins: virtuelv (~virtuelv_@pat-tdc.opera.com)
  759. # [09:01] <jacobolus> i.e. is there some testimonial I can read about how nice it was to deal with?
  760. # [09:01] <jacobolus> with like, specific problems it solved and so forth?
  761. # [09:01] <Hixie> i dunno, probably
  762. # [09:02] <Hixie> most commentary was about how it sucks
  763. # [09:02] <jacobolus> because just at first glance my guess is that I sort of wouldn't like it
  764. # [09:02] <Hixie> the suckitude being mostly related to the bits i haven't talked about :-)
  765. # [09:02] <Hixie> (it tried to solve too much imho)
  766. # [09:02] <Hixie> anyway, i gotta go
  767. # [09:02] <Hixie> bed time
  768. # [09:02] * heycam is now known as heycam|away
  769. # [09:02] <jacobolus> cheers
  770. # [09:03] <jacobolus> I wonder if there are any DSLs embedded in other languages for XML manipulation that are particularly elegant
  771. # [09:03] * Joins: maikmerten (~merten@ls5dhcp200.cs.uni-dortmund.de)
  772. # [09:03] <jacobolus> some lisp macros or some such
  773. # [09:04] <jacobolus> or I guess just for creating complex structured data with attributes and descendants at each level
  774. # [09:04] <jacobolus> wouldn't necessarily have to be based around xml
  775. # [09:05] <jacobolus> annevk: FWIW, I like your thing :)
  776. # [09:12] * Quits: abarth (~abarth@173-164-128-209-SFBA.hfc.comcastbusiness.net) (Quit: abarth)
  777. # [09:24] * Quits: GlitchMr (~glitchmr@178-36-32-130.adsl.inetia.pl) (Read error: Connection reset by peer)
  778. # [09:29] * Joins: toyoshiAw (~toyoshim@yuri.twintail.org)
  779. # [09:30] * Joins: rtuin (~rtuin@213.125.175.250)
  780. # [09:30] * Quits: divya (~divyam@219.64.117.145) (Ping timeout: 245 seconds)
  781. # [09:31] * Quits: sicking (~chatzilla@206-15-76-122.static.twtelecom.net) (Ping timeout: 248 seconds)
  782. # [09:34] * Joins: cpearce (~chatzilla@ip-118-90-78-13.xdsl.xnet.co.nz)
  783. # [09:39] * Quits: cpearce (~chatzilla@ip-118-90-78-13.xdsl.xnet.co.nz) (Ping timeout: 244 seconds)
  784. # [09:40] * Joins: Velmont (odinho@knuth.ping.uio.no)
  785. # [09:41] * Quits: virtuelv (~virtuelv_@pat-tdc.opera.com) (Remote host closed the connection)
  786. # [09:47] * Joins: virtuelv (~virtuelv_@pat-tdc.opera.com)
  787. # [09:50] * Joins: roc (~chatzilla@121.98.230.221)
  788. # [09:53] <hsivonen> Is webcam support in Opera 12 going to be WebRTC or something else?
  789. # [09:56] * Quits: cygri (~cygri@109.255.150.223) (Quit: cygri)
  790. # [10:10] * Joins: nessy (~Adium@124-168-52-143.dyn.iinet.net.au)
  791. # [10:13] * Joins: Timz (~Adium@86.89.174.199)
  792. # [10:18] * Joins: cpearce (~chatzilla@ip-118-90-78-13.xdsl.xnet.co.nz)
  793. # [10:20] * Joins: david_carlisle (~chatzilla@86.188.197.189)
  794. # [10:29] <hsivonen> hmm. Opera 12 doesn't have license legal stuff for Google's WebRTC code on the about page at least
  795. # [10:30] <hsivonen> is there some documentation about what kind of webcam integration Opera 12 has?
  796. # [10:32] * Quits: david_carlisle (~chatzilla@86.188.197.189) (Read error: Connection reset by peer)
  797. # [10:33] <hsivonen> considering how portable Opera is, I'm a bit surprised Opera isn't using clang already on Mac: http://my.opera.com/desktopteam/blog/2011/09/28/mac-compiler-js-performance
  798. # [10:37] * Quits: cpearce (~chatzilla@ip-118-90-78-13.xdsl.xnet.co.nz) (Remote host closed the connection)
  799. # [10:37] * Quits: nessy (~Adium@124-168-52-143.dyn.iinet.net.au) (Quit: Leaving.)
  800. # [10:42] <foolip> hsivonen, it's not Google code
  801. # [10:49] <doublec> opera 12 has webrtc support?
  802. # [10:50] <hsivonen> foolip: what's the feature?
  803. # [10:50] <hsivonen> foolip: that is, what's the webcam integration feature? still upload via <input type=file>? WebRTC? something else?
  804. # [10:52] <foolip> hsivonen, I really don't know, but I assume it's in anticipation of future features that need it (WebRTC)
  805. # [10:53] <hsivonen> foolip: ok. I was wondering about https://twitter.com/#!/ComputerActive/status/123663408133451776 which was retweeted by @opera
  806. # [10:54] <foolip> hmm, yeah, I'm not sure what the sales pitch is, AFAICT you can do things like "augmented reality" now, for what it's worth
  807. # [10:54] <foolip> on mobile at least, on desktop I don't think we have device orientation events :)
  808. # [10:55] <hsivonen> I haven't verified, but IIRC, Firefox has device orientation events on laptops
  809. # [10:56] <hsivonen> though having to tilt the whole laptop might not be as good UI as tilting a phone
  810. # [10:56] <foolip> I'm just guessing though
  811. # [10:56] <zcorpan> orientation events worked for me in firefox on my macbook
  812. # [10:57] <hsivonen> http://news.ycombinator.com/item?id=3096398 is interesting. especially Brendan's follow-up at the bottom of the page
  813. # [10:59] * riven` is now known as riven
  814. # [10:59] * Quits: riven (~riven@53518387.cm-6-2c.dynamic.ziggo.nl) (Changing host)
  815. # [10:59] * Joins: riven (~riven@pdpc/supporter/professional/riven)
  816. # [11:05] * Quits: KevinMarks (~KevinMark@c-71-204-145-244.hsd1.ca.comcast.net) (Quit: The computer fell asleep)
  817. # [11:05] * Joins: KevinMarks (~KevinMark@c-71-204-145-244.hsd1.ca.comcast.net)
  818. # [11:07] <MikeSmith> hsivonen: indeed
  819. # [11:09] * Quits: KevinMarks (~KevinMark@c-71-204-145-244.hsd1.ca.comcast.net) (Ping timeout: 244 seconds)
  820. # [11:09] <annevk> what blog post of alex does Brendan mean?
  821. # [11:10] <hsivonen> annevk: I don't know. I'm guessing http://infrequently.org/2011/09/google-the-future-of-javascript/
  822. # [11:11] * Quits: zcorpan (~zcorpan@c-df9be355.410-6-64736c14.cust.bredbandsbolaget.se) (Remote host closed the connection)
  823. # [11:12] * Joins: zcorpan (~zcorpan@85.227.155.223)
  824. # [11:18] <annevk> hsivonen, afaik Opera 12 allows displaying the feed of a device camera via <video> (which you can then manipulate using <canvas>)
  825. # [11:19] <hsivonen> annevk: ok.
  826. # [11:19] <hsivonen> annevk: are there docs on how to do that from Web content?
  827. # [11:20] <annevk> I think we implemented getUserMedia()
  828. # [11:20] <annevk> there was a labs build with that a while ago
  829. # [11:20] * Quits: homata (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp) (Quit: Leaving...)
  830. # [11:20] <annevk> http://my.opera.com/core/blog/2011/03/23/webcam-orientation-preview
  831. # [11:21] <annevk> instead of URL.createObjectURL() we currently allow directly assigning a Stream object to <video>.src instead; I think that's the only deviation
  832. # [11:21] <annevk> it's just to let people play around a little bit
  833. # [11:27] <hsivonen> annevk: thanks
  834. # [11:29] * Joins: cygri (~cygri@wlan-nat.fwgal01.deri.ie)
  835. # [11:29] * Joins: danbri (~danbri@ip176-48-210-87.adsl2.static.versatel.nl)
  836. # [11:30] * Quits: cygri (~cygri@wlan-nat.fwgal01.deri.ie) (Remote host closed the connection)
  837. # [11:30] * Joins: cygri (~cygri@wg1-nat.fwgal01.deri.ie)
  838. # [11:32] <hsivonen> the new features in http://www.w3.org/2011/09/games/ look rather reasonable except for the hardware performance score
  839. # [11:33] <hsivonen> surely each per-sensitive app needs to run its own benchmark to find out the perf that's relevant to the app
  840. # [11:34] <jgraham> Yeah, that sounds like a bad idea
  841. # [11:35] * Joins: nessy (~Adium@124-168-43-223.dyn.iinet.net.au)
  842. # [11:37] <hsivonen> if the app uses requestAnimationFrame, it should be able to detect if the fps is bad and try throttle down whatever slow stuff it does
  843. # [11:38] <hsivonen> though that might not help. I tried the WebGL aquarium in Firefox on Galaxy S II and the level of detail had no bearing on the frame rate
  844. # [11:38] * Quits: Lachy (~Lachy@cm-84.215.59.50.getinternet.no) (Quit: Computer has gone to sleep.)
  845. # [11:38] <hsivonen> I'm guessing the frame rate was terrible due to something like readbacks from the GPU
  846. # [11:40] * Joins: smaug____ (~chatzilla@GZYYYMKCCLXXX.gprs.sl-laajakaista.fi)
  847. # [11:42] * Joins: ZombieLoffe (ZombieL@unaffiliated/zombieloffe)
  848. # [11:45] * Joins: adactio (~adactio@host213-123-197-180.in-addr.btopenworld.com)
  849. # [11:46] * Quits: nessy (~Adium@124-168-43-223.dyn.iinet.net.au) (Quit: Leaving.)
  850. # [11:46] * Joins: Rik`_ (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net)
  851. # [11:46] * Quits: Rik` (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net) (Read error: Connection reset by peer)
  852. # [11:48] * Joins: Rik` (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net)
  853. # [11:48] * Quits: Rik`_ (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net) (Read error: Connection reset by peer)
  854. # [11:49] * Quits: toyoshiAw (~toyoshim@yuri.twintail.org) (Remote host closed the connection)
  855. # [11:49] * Joins: toyoshiAw (~toyoshim@yuri.twintail.org)
  856. # [11:51] * Joins: Rik`_ (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net)
  857. # [11:51] * Quits: Rik` (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net) (Read error: Connection reset by peer)
  858. # [11:53] * Joins: Rik` (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net)
  859. # [11:53] * Quits: Rik`_ (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net) (Read error: Connection reset by peer)
  860. # [11:56] * Joins: Lachy (~Lachy@pat-tdc.opera.com)
  861. # [12:01] * Quits: Rik` (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net) (Remote host closed the connection)
  862. # [12:06] * Joins: bga_ (~bga@95-55-63-29.dynamic.avangarddsl.ru)
  863. # [12:12] * Quits: virtuelv (~virtuelv_@pat-tdc.opera.com) (Ping timeout: 252 seconds)
  864. # [12:13] * Quits: jdong_ (~quassel@222.126.155.250) (Ping timeout: 245 seconds)
  865. # [12:20] * Joins: mpt (~mpt@nat/canonical/x-bbxzwibcdhepsmll)
  866. # [12:20] * Quits: mpt (~mpt@nat/canonical/x-bbxzwibcdhepsmll) (Changing host)
  867. # [12:20] * Joins: mpt (~mpt@canonical/mpt)
  868. # [12:22] * Joins: jdong_ (~quassel@222.126.155.250)
  869. # [12:25] * Joins: Rik` (~Rik`@mozilla-paris-253-98.cnt.nerim.net)
  870. # [12:25] * Quits: jdong__ (~jdong@222.126.155.250) (Remote host closed the connection)
  871. # [12:28] * Quits: yuuki (~kobayashi@58x158x182x50.ap58.ftth.ucom.ne.jp) (Quit: Leaving...)
  872. # [12:36] * Joins: cygri_ (~cygri@wlan-nat.fwgal01.deri.ie)
  873. # [12:40] * Quits: cygri (~cygri@wg1-nat.fwgal01.deri.ie) (Ping timeout: 248 seconds)
  874. # [12:40] * cygri_ is now known as cygri
  875. # [12:45] * Quits: zcorpan (~zcorpan@85.227.155.223) (Quit: zcorpan)
  876. # [12:50] * Joins: Telling (~unknown@192.38.109.188)
  877. # [12:54] * Quits: Telling (~unknown@192.38.109.188) (Client Quit)
  878. # [12:57] * Quits: annevk (~annevk@114.48.115.238) (Ping timeout: 260 seconds)
  879. # [12:57] * Quits: agektmr (~Adium@220.109.219.244) (Quit: Leaving.)
  880. # [12:57] * Quits: MikeSmith (~MikeSmith@EM114-48-115-238.pool.e-mobile.ne.jp) (Ping timeout: 252 seconds)
  881. # [13:02] * Joins: MikeSmith (~MikeSmith@EM1-112-8-149.pool.e-mobile.ne.jp)
  882. # [13:03] * Joins: mokush (~quassel@188.24.32.36)
  883. # [13:04] * Joins: zcorpan (~zcorpan@c-5eeaaa20-74736162.cust.telenor.se)
  884. # [13:05] * Quits: ZombieLoffe (ZombieL@unaffiliated/zombieloffe)
  885. # [13:08] * Joins: FlorianX1 (~Florian_S@p4FE2DC21.dip.t-dialin.net)
  886. # [13:10] * Quits: FlorianX (~Florian_S@p4FE2D2FC.dip.t-dialin.net) (Ping timeout: 240 seconds)
  887. # [13:23] * Joins: necolas (~necolas@5e0c0fc8.bb.sky.com)
  888. # [13:33] * Quits: cygri (~cygri@wlan-nat.fwgal01.deri.ie) (Quit: cygri)
  889. # [13:44] * Quits: jarib (~jarib@unaffiliated/jarib) (Ping timeout: 258 seconds)
  890. # [13:50] * Joins: cygri (~cygri@wlan-nat.fwgal01.deri.ie)
  891. # [13:51] * Quits: cygri (~cygri@wlan-nat.fwgal01.deri.ie) (Remote host closed the connection)
  892. # [13:51] * Joins: cygri (~cygri@wg1-nat.fwgal01.deri.ie)
  893. # [13:52] <smaug____> where is Ms2ger
  894. # [13:53] <smaug____> annevk5: is the plan to move onfoo idl properties to DOM[4/web/Core/Math.random()] ?
  895. # [13:53] * Quits: zcorpan (~zcorpan@c-5eeaaa20-74736162.cust.telenor.se) (Quit: zcorpan)
  896. # [14:03] * Joins: annevk (~annevk@EM1-112-8-149.pool.e-mobile.ne.jp)
  897. # [14:07] * Joins: zcorpan (~zcorpan@c-df9be355.410-6-64736c14.cust.bredbandsbolaget.se)
  898. # [14:13] * Joins: Ms3ger (9dc13031@gateway/web/freenode/ip.157.193.48.49)
  899. # [14:14] <Ms3ger> smaug____: you called?
  900. # [14:15] <annevk> Ms3ger--
  901. # [14:15] <Ms3ger> Postfix, so it would still return Ms3ger
  902. # [14:16] * Joins: connrs (~connrs@212.159.122.160)
  903. # [14:16] <Ms3ger> (I should note that I stole that joke from someone in #jsapi)
  904. # [14:17] <smaug____> Ms3ger: just about the thing I asked from annevk5
  905. # [14:17] <smaug____> onfoo properties
  906. # [14:17] <smaug____> whether those are going to DOM[4/web/Core/Math.random()]
  907. # [14:18] <annevk> it's been argued they should be
  908. # [14:18] <Ms3ger> Hmm, DOMWeb
  909. # [14:18] <annevk> makes a lot of sense in Dutch
  910. # [14:18] * Joins: tantek (~tantek@cpe-74-73-189-229.nyc.res.rr.com)
  911. # [14:18] <annevk> so probably not a good name
  912. # [14:18] <Ms3ger> annevk++
  913. # [14:19] <Ms3ger> Anyway, not sure about the specific attributes
  914. # [14:19] <Ms3ger> It might be good to move the infrastructure to DOM4, though
  915. # [14:23] <smaug____> annevk: Ms3ger: I was just wondering the right component for http://www.w3.org/Bugs/Public/show_bug.cgi?id=14428 It could be DOM or HTML or WebIDL, I guess. I picked up the last one
  916. # [14:24] * Ms3ger is happy to let heycam figure out what to do
  917. # [14:24] <Ms3ger> Also, welcome back, heycam!
  918. # [14:25] * Ms3ger goes off again
  919. # [14:25] <Ms3ger> ttyl
  920. # [14:25] <annevk> yeah, I'm pretty happy for other people to figure out how event handlers should work before we include them
  921. # [14:26] * Quits: Ms3ger (9dc13031@gateway/web/freenode/ip.157.193.48.49)
  922. # [14:30] * Quits: mokush (~quassel@188.24.32.36) (Remote host closed the connection)
  923. # [14:38] * Joins: bezoar (~Adium@c-24-143-67-135.customer.broadstripe.net)
  924. # [14:41] * Quits: toyoshiAw (~toyoshim@yuri.twintail.org) (Remote host closed the connection)
  925. # [14:42] * Quits: smaug____ (~chatzilla@GZYYYMKCCLXXX.gprs.sl-laajakaista.fi) (Ping timeout: 256 seconds)
  926. # [14:42] * Joins: toyoshiAw (~toyoshim@yuri.twintail.org)
  927. # [14:44] * Quits: mpt (~mpt@canonical/mpt) (Excess Flood)
  928. # [14:44] * Joins: mpt (~mpt@nat/canonical/x-xiwrgazvptgkxklw)
  929. # [14:44] * Quits: mpt (~mpt@nat/canonical/x-xiwrgazvptgkxklw) (Changing host)
  930. # [14:44] * Joins: mpt (~mpt@canonical/mpt)
  931. # [14:56] * Quits: tantek (~tantek@cpe-74-73-189-229.nyc.res.rr.com) (Quit: tantek)
  932. # [14:59] * Joins: jdong_bot_ (~jdong_bot@117.79.233.191)
  933. # [15:03] * Joins: davidb_ (~davidb@66.207.208.98)
  934. # [15:04] * Quits: tomasf (~tomasf@77.72.97.5.c.fiberdirekt.net) (Quit: tomasf)
  935. # [15:12] * Joins: Telling (~unknown@shop3.diku.dk)
  936. # [15:15] * Joins: jarib (~jarib@109.74.192.179)
  937. # [15:15] * Quits: jarib (~jarib@109.74.192.179) (Changing host)
  938. # [15:15] * Joins: jarib (~jarib@unaffiliated/jarib)
  939. # [15:16] * Joins: MacTed (~Thud@63.119.36.36)
  940. # [15:21] * Joins: scor (~scor@drupal.org/user/52142/view)
  941. # [15:21] * Joins: GlitchMr (~glitchmr@178-36-32-130.adsl.inetia.pl)
  942. # [15:24] * Joins: nimbupani (~divyam@219.64.117.145)
  943. # [15:24] * nimbupani is now known as divya
  944. # [15:25] * bga_ is now known as bga_|away
  945. # [15:34] * bga_|away is now known as bga_
  946. # [15:59] <jgraham> So, why can't I find the spec for innerHTML anymore?
  947. # [16:00] * Joins: erlehmann (~erlehmann@89.204.153.90)
  948. # [16:01] * Joins: agektmr (~Adium@p2156-ipbf5107marunouchi.tokyo.ocn.ne.jp)
  949. # [16:01] <annevk> you're not looking carefully? http://html5.org/specs/dom-parsing.html
  950. # [16:02] <jgraham> Oh you made a whole new spec for it. You know that will confuse the hell out of people, right?
  951. # [16:03] * Joins: tantek (~tantek@64.20.183.131)
  952. # [16:03] <annevk> you always predict doom
  953. # [16:03] <annevk> ;)
  954. # [16:19] * Quits: mpt (~mpt@canonical/mpt) (Ping timeout: 256 seconds)
  955. # [16:23] * Joins: rimantas_ (~rimliu@93.93.57.193)
  956. # [16:24] * Quits: zcorpan (~zcorpan@c-df9be355.410-6-64736c14.cust.bredbandsbolaget.se) (*.net *.split)
  957. # [16:24] * Quits: jacobolus (~jacobolus@c-71-198-169-213.hsd1.ca.comcast.net) (*.net *.split)
  958. # [16:24] * Quits: rimantas (~rimliu@93.93.57.193) (*.net *.split)
  959. # [16:24] * Quits: lhnz (~lhnz@188-223-83-48.zone14.bethere.co.uk) (*.net *.split)
  960. # [16:24] * Quits: ukai (ukai@nat/google/x-xqrtxikemoruymqv) (*.net *.split)
  961. # [16:24] * Quits: hamaji (~hamaji@220.109.219.244) (*.net *.split)
  962. # [16:24] * Quits: Hixie (~ianh@trivini.no) (*.net *.split)
  963. # [16:24] * Quits: romainhuet (u2533@gateway/web/irccloud.com/x-kgagqzjfsstfntxa) (*.net *.split)
  964. # [16:24] * Quits: slightlyoff (u1768@gateway/web/irccloud.com/x-leutuazhgomfkzqq) (*.net *.split)
  965. # [16:24] * Quits: tmzt_ (~tmzt@adsl-69-208-11-149.dsl.akrnoh.ameritech.net) (*.net *.split)
  966. # [16:24] * Quits: benschwarz (u2121@gateway/web/irccloud.com/x-arvwvlkaudklrkjq) (*.net *.split)
  967. # [16:24] * Quits: silky (~silky@pool-74-108-142-22.nycmny.fios.verizon.net) (*.net *.split)
  968. # [16:24] * Quits: reggna (~reggna@godis.olf.sgsnet.se) (*.net *.split)
  969. # [16:24] * Joins: lhnz (~lhnz@188-223-83-48.zone14.bethere.co.uk)
  970. # [16:25] * Quits: gnarf (~gnarf@unaffiliated/gnarf) (Read error: Operation timed out)
  971. # [16:25] * Joins: smaug____ (~chatzilla@GZKMMCCXVI.gprs.sl-laajakaista.fi)
  972. # [16:27] * Joins: gnarf (~gnarf@unaffiliated/gnarf)
  973. # [16:27] * Joins: eric_carlson_ (~eric@2620:149:4:1b01:7900:9d3e:456a:930f)
  974. # [16:29] * Joins: romainhuet (u2533@gateway/web/irccloud.com/x-xaawzyktmislogqk)
  975. # [16:29] * Joins: slightlyoff (u1768@gateway/web/irccloud.com/x-rznqzxjmhdzvjphq)
  976. # [16:29] * Joins: zcorpan (~zcorpan@c-df9be355.410-6-64736c14.cust.bredbandsbolaget.se)
  977. # [16:29] * Joins: jacobolus (~jacobolus@c-71-198-169-213.hsd1.ca.comcast.net)
  978. # [16:29] * Joins: ukai (ukai@nat/google/x-xqrtxikemoruymqv)
  979. # [16:29] * Joins: hamaji (~hamaji@220.109.219.244)
  980. # [16:29] * Joins: Hixie (~ianh@trivini.no)
  981. # [16:29] * Joins: silky (~silky@pool-74-108-142-22.nycmny.fios.verizon.net)
  982. # [16:29] * Joins: tmzt_ (~tmzt@adsl-69-208-11-149.dsl.akrnoh.ameritech.net)
  983. # [16:29] * Joins: reggna (~reggna@godis.olf.sgsnet.se)
  984. # [16:29] * Quits: smaug____ (~chatzilla@GZKMMCCXVI.gprs.sl-laajakaista.fi) (Read error: Connection reset by peer)
  985. # [16:31] * Joins: mpt (~mpt@nat/canonical/x-wewljrpndbkgtsvx)
  986. # [16:31] * Quits: mpt (~mpt@nat/canonical/x-wewljrpndbkgtsvx) (Changing host)
  987. # [16:31] * Joins: mpt (~mpt@canonical/mpt)
  988. # [16:31] * Quits: jdong_bot_ (~jdong_bot@117.79.233.191) (Remote host closed the connection)
  989. # [16:32] * Quits: Rik` (~Rik`@mozilla-paris-253-98.cnt.nerim.net) (Remote host closed the connection)
  990. # [16:32] * Joins: benschwarz (u2121@gateway/web/irccloud.com/x-teclrtecvsnkkrni)
  991. # [16:36] * Joins: timeless (u4015@gateway/web/irccloud.com/x-mgufbkeratirtixq)
  992. # [16:36] * Quits: timeless (u4015@gateway/web/irccloud.com/x-mgufbkeratirtixq) (Changing host)
  993. # [16:36] * Joins: timeless (u4015@firefox/developer/timeless)
  994. # [16:37] * Quits: bga_ (~bga@95-55-63-29.dynamic.avangarddsl.ru) (Ping timeout: 252 seconds)
  995. # [16:39] * Joins: bga_ (~bga@ppp78-37-248-65.pppoe.avangarddsl.ru)
  996. # [16:56] * Joins: hij1nx (~hij1nx@cpe-98-14-168-178.nyc.res.rr.com)
  997. # [17:06] * Quits: maikmerten (~merten@ls5dhcp200.cs.uni-dortmund.de) (Quit: Verlassend)
  998. # [17:07] * Quits: rtuin (~rtuin@213.125.175.250) (Quit: Leaving)
  999. # [17:08] * Joins: tmzt (~tmzt@adsl-69-208-11-149.dsl.akrnoh.ameritech.net)
  1000. # [17:10] * Quits: tmzt_ (~tmzt@adsl-69-208-11-149.dsl.akrnoh.ameritech.net) (Ping timeout: 256 seconds)
  1001. # [17:10] * Quits: jacobolus (~jacobolus@c-71-198-169-213.hsd1.ca.comcast.net) (Ping timeout: 256 seconds)
  1002. # [17:11] * Joins: jacobolus (~jacobolus@c-71-198-169-213.hsd1.ca.comcast.net)
  1003. # [17:18] * Joins: smaug____ (~chatzilla@cs181151161.pp.htv.fi)
  1004. # [17:21] * Joins: Rik` (~Rik`@mozilla-paris-253-98.cnt.nerim.net)
  1005. # [17:22] * Quits: ezoe (~ezoe@112-68-244-76f1.kyt1.eonet.ne.jp) (Ping timeout: 255 seconds)
  1006. # [17:26] * Quits: tantek (~tantek@64.20.183.131) (Quit: tantek)
  1007. # [17:27] * Joins: ZombieLoffe (ZombieLoff@unaffiliated/zombieloffe)
  1008. # [17:27] * Quits: annevk (~annevk@EM1-112-8-149.pool.e-mobile.ne.jp) (Quit: annevk)
  1009. # [17:29] * Joins: mhausenblas (~mhausenbl@wlan-nat.fwgal01.deri.ie)
  1010. # [17:29] * Joins: alohci (~chatzilla@cpc2-lutn10-2-0-cust550.9-3.cable.virginmedia.com)
  1011. # [17:29] * Quits: alohci (~chatzilla@cpc2-lutn10-2-0-cust550.9-3.cable.virginmedia.com) (Client Quit)
  1012. # [17:36] <hsivonen> I wonder where this person gets his ideas about Mozilla http://news.ycombinator.com/item?id=3094880
  1013. # [17:36] * Joins: tantek (~tantek@64.20.183.131)
  1014. # [17:37] <bga_> open bytecode stantard is ok
  1015. # [17:38] * Quits: Lachy (~Lachy@pat-tdc.opera.com) (Quit: Computer has gone to sleep.)
  1016. # [17:39] <bga_> i remeber http://code.google.com/p/chromium/issues/detail?id=64290
  1017. # [17:41] <jgraham> hsivonen: Cynicism untempered by reality?
  1018. # [17:42] * dglazkov|away is now known as dglazkov
  1019. # [17:42] * Joins: mdelaney (~mdelaney@c-71-202-44-225.hsd1.ca.comcast.net)
  1020. # [17:42] <dglazkov> good morning, Whatwg!
  1021. # [17:45] <divya> GOOD MORNING DGLAZKOV
  1022. # [17:46] <dglazkov> all caps. Excellent choice.
  1023. # [17:46] * Quits: dirkpennings (~Vuurbal@90-145-26-140.bbserv.nl) (Ping timeout: 260 seconds)
  1024. # [17:46] <divya> i really put in the effort for the cause of html5
  1025. # [17:47] <hsivonen> I wonder if I'm reading too much into Opera's PR language when I observe that they don't say "Flash" when they've added Flash support
  1026. # [17:47] <hsivonen> it looks like an attempt to downplay Flash as something that users are aware of
  1027. # [17:47] <timeless> hsivonen: are they bundling flash now?
  1028. # [17:48] <hsivonen> timeless: no, but on desktop, they are automating installation at least on Windows, IIRC
  1029. # [17:48] <hsivonen> timeless: this is about the latest Opera Mobile release, though, which added Flash support on Honeycomb
  1030. # [17:49] <hsivonen> apparently the way Flash presents itself to NPAPI is different in Android 2.x and 3.x
  1031. # [17:50] <timeless> sandboxing related perhaps?
  1032. # [17:51] <hsivonen> dunno
  1033. # [17:51] <hasather> hsivonen: the guy writing that blog post is not an Opera employee btw (but I think the blog is official)
  1034. # [17:52] * Joins: rillian_ (~rillian@184.71.182.138)
  1035. # [17:52] * Joins: eric_carlson__ (~eric@17.212.152.104)
  1036. # [17:53] <jgraham> We get random strangers to write our PR stuff? :)
  1037. # [17:53] <hasather> jgraham: neither random nor stranger I think, but yea... :D
  1038. # [17:54] <beverloo> I agree that it's hard to see which posts are and which posts aren't official at Opera's
  1039. # [17:54] <timeless> jgraham: nokia did
  1040. # [17:54] <timeless> we had contractors responsible for the official nokia connections or whatever it was blog
  1041. # [17:55] * Quits: eric_carlson_ (~eric@2620:149:4:1b01:7900:9d3e:456a:930f) (Ping timeout: 244 seconds)
  1042. # [17:59] * Joins: Lachy (~Lachy@cm-84.215.59.50.getinternet.no)
  1043. # [18:05] * Quits: hij1nx (~hij1nx@cpe-98-14-168-178.nyc.res.rr.com) (Quit: hij1nx)
  1044. # [18:06] * Joins: KevinMarks (~KevinMark@c-71-204-145-244.hsd1.ca.comcast.net)
  1045. # [18:09] * Joins: svl (~me@ip565744a7.direct-adsl.nl)
  1046. # [18:13] * Joins: ezoe (~ezoe@112-68-244-91f1.kyt1.eonet.ne.jp)
  1047. # [18:17] <hsivonen> is the XHR error flag exposed to scripts?
  1048. # [18:20] <hsivonen> looks like Gecko returns xhr.status == 0 for non-HTTP requests :-(
  1049. # [18:23] * Joins: tomasf (~tom@c-5ed9e555.024-204-6c6b7012.cust.bredbandsbolaget.se)
  1050. # [18:23] * Quits: astearns (~anonymous@c-50-132-63-33.hsd1.wa.comcast.net) (Quit: astearns)
  1051. # [18:25] * bga_ is now known as bga_|away
  1052. # [18:27] * Joins: astearns (~anonymous@50.132.63.33)
  1053. # [18:29] <smaug____> Should http://www.whatwg.org/specs/web-apps/current-work/multipage/fetching-resources.html#fetch say something about caching
  1054. # [18:30] * Joins: hasather_ (~hasather_@84.38.144.96)
  1055. # [18:31] <smaug____> especially, in which case is loading from browser cache ok, and in which case it isn't
  1056. # [18:31] * Joins: Maurice (copyman@5ED573FA.cm-7-6b.dynamic.ziggo.nl)
  1057. # [18:34] <AryehGregor> What's the story with &apos;? What's the newest browser that doesn't support it?
  1058. # [18:35] <AryehGregor> IE6, at least?
  1059. # [18:35] <AryehGregor> Apparently IE7 also?
  1060. # [18:36] * AryehGregor uses &#39; instead
  1061. # [18:36] * Quits: tantek (~tantek@64.20.183.131) (Quit: tantek)
  1062. # [18:37] <AryehGregor> jgraham, I pushed the innerHTML change, with a single escaping function defined as you requested.
  1063. # [18:37] * Quits: tomasf (~tom@c-5ed9e555.024-204-6c6b7012.cust.bredbandsbolaget.se) (Read error: Connection reset by peer)
  1064. # [18:38] <AryehGregor> (am also looking at pushing other changes)
  1065. # [18:38] * Joins: tomasf (~tom@c-5ed9e555.024-204-6c6b7012.cust.bredbandsbolaget.se)
  1066. # [18:40] * Joins: tndH (~Rob@cpc16-seac19-2-0-cust234.7-2.cable.virginmedia.com)
  1067. # [18:41] * Quits: rimantas_ (~rimliu@93.93.57.193) (Quit: Leaving)
  1068. # [18:41] <gsnedders> hasather: What blog post?
  1069. # [18:45] <gsnedders> Oh, that one.~
  1070. # [18:45] * AryehGregor finds that 50% of total time in Chrome is in format_value now
  1071. # [18:49] * Quits: Necrathex (~nectop@82-170-160-25.ip.telfort.nl) (Quit: Necrathex)
  1072. # [18:49] * Quits: cygri (~cygri@wg1-nat.fwgal01.deri.ie) (Ping timeout: 248 seconds)
  1073. # [18:50] * Quits: GlitchMr (~glitchmr@178-36-32-130.adsl.inetia.pl) (Read error: Connection reset by peer)
  1074. # [18:51] * gsnedders is increasingly doubting the open-web nature of even the Dart to JS compiler.
  1075. # [18:51] * Quits: mdelaney (~mdelaney@c-71-202-44-225.hsd1.ca.comcast.net) (Quit: mdelaney)
  1076. # [18:52] <AryehGregor> Is it any worse than GWT?
  1077. # [18:53] <gsnedders> At a high-level it appears better, but looking into it it seems worse.
  1078. # [18:53] * Quits: astearns (~anonymous@50.132.63.33) (Quit: astearns)
  1079. # [18:53] * AryehGregor hasn't looked into it
  1080. # [18:53] * AryehGregor doubts the utility of "let's introduce yet another language", though
  1081. # [18:54] <gsnedders> Oh, yeah. Sure. But it's really a bit too late for me to start bitching about that now…
  1082. # [18:54] * bga_|away is now known as bga_
  1083. # [18:55] * Joins: MikeSmith_ (~MikeSmith@EM114-48-154-96.pool.e-mobile.ne.jp)
  1084. # [18:55] <gsnedders> AryehGregor: It avoids the browser sniffing, but is supported on fewer browsers, and without any given reason (or bug reports)…
  1085. # [18:55] * Joins: tantek (~tantek@64.20.183.131)
  1086. # [18:55] <AryehGregor> "supported on" meaning "actually works on" or "is tested on"?
  1087. # [18:56] <gsnedders> I believe the latter. Though it makes me the doubt the former.
  1088. # [18:56] <gsnedders> Testing is hardly that expensive.
  1089. # [18:56] <AryehGregor> Testing is very expensive if you do enough of it.
  1090. # [18:56] <AryehGregor> If there's no browser-sniffing of any kind, all browsers should be able to work just by making sure they follow what other browsers do, right?
  1091. # [18:56] <gsnedders> For a company like Google, with the amount of resources already thrown at Dart, it's cheap.
  1092. # [18:57] <AryehGregor> Even compared to the benefit, taking market shares into account?
  1093. # [18:57] <gsnedders> AryehGregor: Except that at least the Dart website (haven't looked to see if that uses Dart though, FWIW) breaks if we fix DOM 3 Events compliance bug to move inline with Fx/WebKit.
  1094. # [18:58] <gsnedders> AryehGregor: IE has a non-negilable marketshare. We have enough marketshare that they care about us enough in GWT.
  1095. # [18:58] <gsnedders> And our JS impl really should be good enough that it should work fine.
  1096. # [18:58] * Quits: MikeSmith (~MikeSmith@EM1-112-8-149.pool.e-mobile.ne.jp) (Ping timeout: 260 seconds)
  1097. # [18:58] * MikeSmith_ is now known as MikeSmith
  1098. # [18:58] <gsnedders> So the cost of supporting Carakan should be ~0.
  1099. # [18:59] <gsnedders> Provided they actually follow ES5 in their impl and don't rely upon things where V8/SM intend on changing behaviour for it.
  1100. # [19:00] * Quits: mhausenblas (~mhausenbl@wlan-nat.fwgal01.deri.ie) (Quit: brb)
  1101. # [19:00] <gsnedders> Same with Chakra, really.
  1102. # [19:00] <gsnedders> Omitting the two JS engines that nowadays probably have the best support for ES5 is… odd.
  1103. # [19:00] <gsnedders> To say the least.
  1104. # [19:01] <AryehGregor> Well, supporting an extra browser is cheap if all your tests are automated.
  1105. # [19:01] <gsnedders> And I'd hope they are.
  1106. # [19:01] * Joins: jwalden (~waldo@2620:101:8003:200:224:d7ff:fef0:8d90)
  1107. # [19:01] * Joins: GlitchMr (~glitchmr@178-36-32-130.adsl.inetia.pl)
  1108. # [19:02] <AryehGregor> For a language converter, yeah.
  1109. # [19:08] * Joins: KillerX (~anant@nat/mozilla/x-dshtyxsxthexkmou)
  1110. # [19:12] <hsivonen> what's the deal with WebM support in Opera Mobile for Android? Earlier, I was told Opera Mobile supported WebM from 2.3 onwards
  1111. # [19:13] <hsivonen> I just tested the latest release on Android 3.1 and it supported H.264 but not WebM
  1112. # [19:15] * Joins: hij1nx (~hij1nx@207.239.107.3)
  1113. # [19:17] * Quits: adactio (~adactio@host213-123-197-180.in-addr.btopenworld.com) (Quit: adactio)
  1114. # [19:19] * Quits: tantek (~tantek@64.20.183.131) (Quit: tantek)
  1115. # [19:20] <AryehGregor> Is it possible for window.parent to change?
  1116. # [19:20] <gsnedders> hsivonen: I believe we just use the system video decoder, so whatever that supports.
  1117. # [19:20] <AryehGregor> I mean, for the same script to see different values at different times?
  1118. # [19:20] <AryehGregor> For the same window object?
  1119. # [19:20] <timeless> AryehGregor: hrm
  1120. # [19:21] <AryehGregor> I'd think it should be impossible, but I wanted to check.
  1121. # [19:21] <timeless> if a browser implements a user friendly version of <pop-frame-out-as-window-out
  1122. # [19:21] <timeless> but i don't think that exists anywhere
  1123. # [19:21] * Joins: sicking (~chatzilla@206-15-76-122.static.twtelecom.net)
  1124. # [19:22] <hsivonen> gsnedders: maybe I should remove the advice that Opera Mobile supports WebM on Android, then
  1125. # [19:23] <hsivonen> gsnedders: because it sucks to tell people it does if it doesn't
  1126. # [19:23] * Joins: dbaron (~dbaron@nat/mozilla/x-txplyaevgevcuoua)
  1127. # [19:23] <gsnedders> hsivonen: We should support it.
  1128. # [19:23] <hsivonen> at least Firefox supports it consistently even if performance is unusable
  1129. # [19:23] * gsnedders has no Android 2.3.3+ device to test on
  1130. # [19:24] * Quits: jacobolus (~jacobolus@c-71-198-169-213.hsd1.ca.comcast.net) (Remote host closed the connection)
  1131. # [19:24] <AryehGregor> Is it worthwhile to support it if performance is unusable?
  1132. # [19:25] <hsivonen> well, at least I should edit the page not to suggest Opera 11+ users to install Opera as a remedy to WebM non-support
  1133. # [19:25] <AryehGregor> Isn't it better in that case to fall back to the next source, if any?
  1134. # [19:25] <hsivonen> AryehGregor: unclear
  1135. # [19:25] <hsivonen> hmm. which reminds me that I haven't tested it with layers acceleration
  1136. # [19:25] * jernoble|afk is now known as jernoble
  1137. # [19:26] <gsnedders> hsivonen: I saw someone saying Mobile 11.5 at least had better WebM perf than Firefox on some Android device.
  1138. # [19:26] <timeless> gsnedders: do you have an n900?
  1139. # [19:27] * timeless wonders which version Android is used for Nitdroid
  1140. # [19:27] <gsnedders> timeless: No. HTC Legend.
  1141. # [19:28] <hsivonen> the perf sucks even with layers acceleration enabled :-(
  1142. # [19:29] <gsnedders> hsivonen: What device are you testing on, and on what Android version?
  1143. # [19:29] <gsnedders> And what version of Mobile?
  1144. # [19:30] <hsivonen> gsnedders: Samsung Galaxy Tab 10.1, Android 3.1 (latest build available), Opera Mobile 11.50 (the one released today)
  1145. # [19:30] <dglazkov> AryehGregor: re window.parent, you should talk with dimich on #webkit about this. There's a thing called "magic iframe" in WebKit, which _may_ make window.parent change
  1146. # [19:31] <AryehGregor> dglazkov, I suspect that for my use-case it's not the end of the world if it changes in crazy circumstances.
  1147. # [19:31] <gsnedders> hsivonen: What page were you using for testing?
  1148. # [19:31] <dglazkov> AryehGregor: k
  1149. # [19:31] <hsivonen> gsnedders: http://webm.html5.org/
  1150. # [19:31] * bga_ is now known as bga_|away
  1151. # [19:31] <gsnedders> hsivonen: eh, we appear to have https://bugs.opera.com/wizard/mobile now, so can you just file a bug?
  1152. # [19:31] <hsivonen> a friend on another channel reports that WebM doesn't work in GSII in Opera Mobile 11.x
  1153. # [19:32] <hsivonen> gsnedders: ok
  1154. # [19:32] * Quits: eric_carlson (~ericc@adsl-67-112-12-110.dsl.anhm01.pacbell.net) (Disconnected by services)
  1155. # [19:32] * eric_carlson__ is now known as eric_carlson
  1156. # [19:32] <gsnedders> I'll make sure it gets attention, because that is /bad/ it doesn't work.
  1157. # [19:34] <hsivonen> gsnedders: oh, the playback support is there. canPlayType is wrong
  1158. # [19:34] <hsivonen> FAIL
  1159. # [19:34] <gsnedders> hsivonen: That may be down to YouTube breaking if canPlayType is right, AIUI
  1160. # [19:35] <gsnedders> (I wish I was joking)
  1161. # [19:36] <hsivonen> even worse
  1162. # [19:37] <hsivonen> gsnedders: ANDMEX-3236
  1163. # [19:37] <gsnedders> "Enabling only webM audio for Android 2.3.3+ Video doesn't work well and causes Android media server to crash."
  1164. # [19:38] <AryehGregor> Does anyone have any tips on how to speed up layout of a 40,000-row table?
  1165. # [19:38] <gsnedders> So, uh, we seem to have it disabled because Android's WebM impl is unstable
  1166. # [19:40] * Quits: KillerX (~anant@nat/mozilla/x-dshtyxsxthexkmou) (Read error: Connection reset by peer)
  1167. # [19:40] * Joins: KillerX (~anant@2620:101:8003:200:81a9:37bc:99bf:f1a5)
  1168. # [19:41] * Joins: cygri (~cygri@89.19.72.90)
  1169. # [19:42] * Quits: Lachy (~Lachy@cm-84.215.59.50.getinternet.no) (Quit: Computer has gone to sleep.)
  1170. # [19:45] * Joins: tantek (~tantek@64.20.183.131)
  1171. # [19:48] * Joins: Areks (~kvirc@176.14.214.163)
  1172. # [19:49] * Joins: ap_ (~ap@2620:149:4:1b01:7029:4eb8:c852:8e66)
  1173. # [19:49] <gsnedders> Heheh, I like how in response to Dart people are again saying there should be a generic bytecode, "to avoid the cost of parsing", totally ignoring a large part of the cost is validating it, which will remain true for any bytecode.
  1174. # [19:49] <gsnedders> The only real gain is a few fewer bytes to process, but the same number of tokens, pretty much…
  1175. # [19:51] <gsnedders> AryehGregor: Also, Dart->JS compiler's output does UA sniff and blocks everything that isn't Chrome, Safari, or Firefox.
  1176. # [19:51] <gsnedders> AryehGregor: They only talk about removing the UA block on IE9.
  1177. # [19:51] <AryehGregor> Seriously? That's massively lame.
  1178. # [19:51] <gsnedders> AryehGregor: So Opera is totally fucked.
  1179. # [19:52] <AryehGregor> Along with every other minor browser that uses WebKit or whatever but happens not to look like one of the major browsers.
  1180. # [19:52] * Joins: astearns (~anonymous@192.150.22.5)
  1181. # [19:52] <AryehGregor> (although probably all of those pretend to be a major browser)
  1182. # [19:53] <gsnedders> So Google care enough about us to give us however-many-million-dollars per year, but not enough to actually support us.
  1183. # [19:53] <AryehGregor> It's independent people making different decisions.
  1184. # [19:53] * Quits: Telling (~unknown@shop3.diku.dk) (Quit: ...)
  1185. # [19:58] * Quits: cygri (~cygri@89.19.72.90) (Quit: cygri)
  1186. # [19:59] * Quits: agektmr (~Adium@p2156-ipbf5107marunouchi.tokyo.ocn.ne.jp) (Quit: Leaving.)
  1187. # [20:00] * Joins: rniwa (rniwa@nat/google/x-culdzresdxuullmz)
  1188. # [20:00] * Quits: ezoe (~ezoe@112-68-244-91f1.kyt1.eonet.ne.jp) (Ping timeout: 255 seconds)
  1189. # [20:01] <timeless> AryehGregor: um
  1190. # [20:02] <AryehGregor> ?
  1191. # [20:02] <timeless> i don't think we pretend to be a major browser
  1192. # [20:02] * timeless seems to recall getting crappy content
  1193. # [20:02] <AryehGregor> You probably just get broken content in sites that whitelist browsers, then.
  1194. # [20:03] * bga_|away is now known as bga_
  1195. # [20:04] <timeless> oh cute
  1196. # [20:04] <timeless> we claim to be Safari :)
  1197. # [20:04] <AryehGregor> So does Chrome, kind of.
  1198. # [20:04] <AryehGregor> And Safari claims to be Mozilla, as does everyone else.
  1199. # [20:04] <AryehGregor> UA strings are fun.
  1200. # [20:04] <timeless> i thought Opera or IE stopped claiming to be Gecko
  1201. # [20:05] <TabAtkins> annevk5 heycam|away: If HTMLDivElement is really ugly, but "new Div()" is probably too short, what about semi-namespacing? "new HTML.Div()"?
  1202. # [20:05] <timeless> HTMLDivElement is really ugly
  1203. # [20:05] <AryehGregor> It still claims to be Mozilla, right?
  1204. # [20:05] * Joins: othermaciej (~mjs@c-24-6-209-189.hsd1.ca.comcast.net)
  1205. # [20:05] <TabAtkins> I think that might be a good way to expose CSS value constructors in a short manner as well.
  1206. # [20:06] * Quits: dbaron (~dbaron@nat/mozilla/x-txplyaevgevcuoua) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  1207. # [20:08] <dglazkov> HTML.Div() sounds nice.
  1208. # [20:08] <dglazkov> maybe html.Div()?
  1209. # [20:08] * dglazkov breaks out his shed painting overalls
  1210. # [20:08] <timeless> darn, ie9 still claims to be mozilla/5
  1211. # [20:08] * timeless sobs
  1212. # [20:09] * Quits: divya (~divyam@219.64.117.145) (Ping timeout: 252 seconds)
  1213. # [20:10] * Joins: miketaylr (~miketaylr@24.42.93.245)
  1214. # [20:11] * Joins: cygri (~cygri@89.19.72.90)
  1215. # [20:12] * Quits: erlehmann (~erlehmann@89.204.153.90) (Quit: Ex-Chat)
  1216. # [20:14] * Quits: miketaylr (~miketaylr@24.42.93.245) (Client Quit)
  1217. # [20:15] * Joins: dave_levin (dave_levin@nat/google/x-zbburlhcwmxyomfv)
  1218. # [20:17] <rniwa> who knows about microdata well?
  1219. # [20:18] <AryehGregor> rniwa, well, Hixie designed it . . . but a bunch of other people here know about it too.
  1220. # [20:18] <AryehGregor> If you ask your question, it will probably be answered.
  1221. # [20:18] <rniwa> okay
  1222. # [20:19] <rniwa> would an element with itemscope and itemtype considered to be an top-level item even if there are some item-scope element that refers to that element via itemref?
  1223. # [20:22] * Quits: Stikki (~lordstich@dsl-pribrasgw1-ff17c300-80.dhcp.inet.fi) (Ping timeout: 248 seconds)
  1224. # [20:24] * Quits: rillian_ (~rillian@184.71.182.138) (Read error: Connection reset by peer)
  1225. # [20:25] * Quits: myakura (~myakura@FL1-203-136-164-250.tky.mesh.ad.jp) (Remote host closed the connection)
  1226. # [20:27] <cygri> rniwa: the spec says "An item is a top-level microdata item if its element does not have an itemprop attribute."
  1227. # [20:28] <rniwa> cygri: on the other hand, it also says "Items that are not part of others are called top-level microdata items."
  1228. # [20:28] <AryehGregor> The latter sounds non-normative.
  1229. # [20:28] <cygri> note that itemref doesn't actually refer to items, despite its name. it just imports any property-value pairs on the target or its descendants
  1230. # [20:28] <AryehGregor> Is it in a normative section?
  1231. # [20:28] <rniwa> cygri: ah, that's good point.
  1232. # [20:29] * Joins: Lachy (~Lachy@cm-84.215.59.50.getinternet.no)
  1233. # [20:29] <rniwa> cygri: but what if we had an ancestor with itemscope?
  1234. # [20:29] <cygri> yeah. it also sounds slighly wrong
  1235. # [20:29] <rniwa> cygri: e.g. <div itemscope>hello<span itemscope itemtype="~~">
  1236. # [20:29] <rniwa> I don't think span should be considered as the top-level microdata items in this case
  1237. # [20:30] <rniwa> or maybe top-level isn't really top-level
  1238. # [20:30] <cygri> according to the spec it is top-level
  1239. # [20:30] <rniwa> huh...
  1240. # [20:30] <rniwa> even if we had <div itemscope itemtype="~~">hello<span itemscope itemtype="~~"><b itemprop="~~"> ?
  1241. # [20:30] <cygri> as AryehGregor said, the section you quoted is non-normative
  1242. # [20:31] <rniwa> cygri: but in this case, div's item will contain b's content, right?
  1243. # [20:31] <rniwa> cygri: so we'll have two top-level items in this case?
  1244. # [20:32] * Joins: Stikki (~lordstich@dsl-pribrasgw1-ff17c300-80.dhcp.inet.fi)
  1245. # [20:34] * Joins: cygri_ (~cygri@109.79.250.164)
  1246. # [20:34] <rniwa> cygri_: ?
  1247. # [20:34] <cygri_> what?
  1248. # [20:34] * Quits: GlitchMr (~glitchmr@178-36-32-130.adsl.inetia.pl) (Read error: Connection reset by peer)
  1249. # [20:35] <rniwa> cygri: did you get my last question?
  1250. # [20:35] <rniwa> cygri: if we had <div itemscope itemtype="~~">hello<span itemscope itemtype="~~"><b itemprop="~~">
  1251. # [20:35] <rniwa> cygri: would we have two top-level items?
  1252. # [20:35] * Quits: cygri (~cygri@89.19.72.90) (Ping timeout: 255 seconds)
  1253. # [20:35] * cygri_ is now known as cygri
  1254. # [20:35] * cygri is on a bus. internet not good
  1255. # [20:36] <cygri> that looks like two top-level items to me
  1256. # [20:36] <rniwa> cygri: ok, thanks
  1257. # [20:36] <cygri> yw!
  1258. # [20:45] * Quits: Stikki (~lordstich@dsl-pribrasgw1-ff17c300-80.dhcp.inet.fi) (Ping timeout: 258 seconds)
  1259. # [20:56] * Quits: tantek (~tantek@64.20.183.131) (Quit: tantek)
  1260. # [20:57] * Joins: tantek (~tantek@64.20.183.131)
  1261. # [20:58] * Quits: cygri (~cygri@109.79.250.164) (Quit: cygri)
  1262. # [21:00] * Joins: mkanat (mkanat@nat/google/x-lrpljvozsmvdrden)
  1263. # [21:07] * Joins: Stikki (~lordstich@dsl-pribrasgw1-ff17c300-80.dhcp.inet.fi)
  1264. # [21:09] * Joins: dbaron (~dbaron@nat/mozilla/x-xywnhhmgajjnwoxi)
  1265. # [21:10] * Joins: cygri (~cygri@109.79.250.164)
  1266. # [21:11] * Quits: othermaciej (~mjs@c-24-6-209-189.hsd1.ca.comcast.net) (Quit: othermaciej)
  1267. # [21:12] * Quits: tantek (~tantek@64.20.183.131) (Quit: tantek)
  1268. # [21:15] * Joins: ojan (ojan@nat/google/x-cvaiowvzcqmcysjw)
  1269. # [21:21] * Joins: jarek (~jarek@unaffiliated/jarek)
  1270. # [21:22] * jernoble is now known as jernoble|afk
  1271. # [21:23] * Joins: cygri_ (~cygri@89.19.73.208)
  1272. # [21:25] * Quits: cygri (~cygri@109.79.250.164) (Ping timeout: 260 seconds)
  1273. # [21:25] * cygri_ is now known as cygri
  1274. # [21:29] * Joins: zdobersek (~zan@BSN-176-193-184.dial-up.dsl.siol.net)
  1275. # [21:30] * Quits: jarek (~jarek@unaffiliated/jarek) (Ping timeout: 260 seconds)
  1276. # [21:32] * Quits: sicking (~chatzilla@206-15-76-122.static.twtelecom.net) (Ping timeout: 252 seconds)
  1277. # [21:35] * Joins: rillian_ (~rillian@184.71.182.138)
  1278. # [21:37] * Joins: tomasf_ (~tomasf@c-5ed9e555.024-204-6c6b7012.cust.bredbandsbolaget.se)
  1279. # [21:39] * Joins: jamesr (jamesr@nat/google/x-lrwiujrawvzcvkom)
  1280. # [21:39] <rniwa> AryehGregor: regarding the -webkit-user-modify, the most important users are AIR and Inspector
  1281. # [21:40] <AryehGregor> What's AIR?
  1282. # [21:40] <rniwa> AryehGregor: but I've seen some users in the public Web
  1283. # [21:40] <rniwa> AryehGregor: Adobe's new Web authoring tool
  1284. # [21:40] <rniwa> AryehGregor: http://www.adobe.com/products/air.html
  1285. # [21:40] <AryehGregor> Hmm.
  1286. # [21:40] <rniwa> AryehGregor: we can probably ask them to use contenteditable instead
  1287. # [21:40] <AryehGregor> Well, I don't like all these features being exposed permanently with vendor prefixes, but I guess there are more important things to worry about.
  1288. # [21:41] <rniwa> AryehGregor: well, at least we don't expose user-modify :)
  1289. # [21:41] <rniwa> in fact, that's the whole point of vendor-prefixing it, right?
  1290. # [21:41] <rniwa> so that we can kill the feature from the standard
  1291. # [21:41] * Quits: tomasf_ (~tomasf@c-5ed9e555.024-204-6c6b7012.cust.bredbandsbolaget.se) (Client Quit)
  1292. # [21:41] <AryehGregor> Well, it's much better than non-vendor-prefixed, yes.
  1293. # [21:41] <rniwa> without breaking the whole web
  1294. # [21:44] * Quits: roc (~chatzilla@121.98.230.221) (Ping timeout: 244 seconds)
  1295. # [21:46] * Quits: Timz (~Adium@86.89.174.199) (Quit: Leaving.)
  1296. # [21:47] * Joins: Timz (~Adium@86.89.174.199)
  1297. # [21:49] * Quits: ralphholzmann (~ralph@li76-151.members.linode.com) (Quit: WeeChat 0.3.5)
  1298. # [21:51] * Quits: smaug____ (~chatzilla@cs181151161.pp.htv.fi) (Ping timeout: 258 seconds)
  1299. # [21:51] <jgraham> Hixie: tables in email++
  1300. # [21:51] * Quits: Timz (~Adium@86.89.174.199) (Ping timeout: 248 seconds)
  1301. # [21:55] <Hixie> heh
  1302. # [21:55] <Hixie> i'm sure i'll get told it's inaccessible
  1303. # [21:55] <Hixie> or i would if it was in public-html
  1304. # [21:56] <Hixie> you'd be surprised how often i got told that my ascii art sig was a travesty and an insult to accessibility tool users everywhere
  1305. # [21:57] * Quits: zcorpan (~zcorpan@c-df9be355.410-6-64736c14.cust.bredbandsbolaget.se) (Quit: zcorpan)
  1306. # [21:57] <TabAtkins> Hixie: It would be less confusing to me if you didn't try to conflate the term "binding" and "component". We've been trying to distinguish the terms for ease of discussion such that "component" implies permanence and "binding" implies decoration.
  1307. # [21:57] <Hixie> the terms mean the same thing, and have since 1997 or so
  1308. # [21:57] <jgraham> I'm not surprised. It wouldn't be so funny if accessibility advocates hadn't been responsible for the most confusing, inaccessible email I have ever received on a standards mailing list
  1309. # [21:57] <Hixie> jgraham: yeah, tell me about it
  1310. # [21:58] <TabAtkins> Hixie: Which is why we've been trying to distinguish them. ^_^
  1311. # [21:58] <Hixie> TabAtkins: trying to take terms that mean the same thing and distinguish them after more than 15 years of them meaning the same thing is pointless. use new terms. :-)
  1312. # [21:58] <jgraham> TabAtkins: Those implications aren't at all clear from the names, so I wouldn't try that
  1313. # [21:59] * Joins: tantek (~tantek@64.20.183.131)
  1314. # [21:59] <Hixie> TabAtkins: "presentation transient binding" and "semantic API-defining binding", for instance
  1315. # [21:59] <TabAtkins> Hixie: Those are horrible!
  1316. # [21:59] <AryehGregor> They're long, is all.
  1317. # [22:00] * Quits: tantek (~tantek@64.20.183.131) (Client Quit)
  1318. # [22:00] <TabAtkins> That's what I said.
  1319. # [22:00] <AryehGregor> You can kill either of the two modifiers on both.
  1320. # [22:00] <Hixie> TabAtkins: (i wasn't even aware that there were two concepts until i suggested there were a few e-mails ago, btw, and i'd no idea that there was any attempt to redefine the terms until today)
  1321. # [22:00] <TabAtkins> Hixie: No wonder you've been so confused, then. We've been talking solely about permanent bindings forever.
  1322. # [22:01] * Joins: tantek (~tantek@64.20.183.131)
  1323. # [22:01] <Hixie> TabAtkins: yeah stop that.
  1324. # [22:01] <TabAtkins> What? Why?
  1325. # [22:01] <Hixie> because the two problems have almost identical solution spaces and it is pointless to ignore one of the two problems when designing the solution
  1326. # [22:01] <TabAtkins> But they dont'! They're so different!
  1327. # [22:01] <Hixie> they're almost identical
  1328. # [22:02] <Hixie> there's two differences
  1329. # [22:02] <Hixie> see my most recent e-mail with the table
  1330. # [22:02] <TabAtkins> One changes the prototype chain, exposes public API. One can be swapped on-and-off because it makes no lasting changes.
  1331. # [22:02] <Hixie> that's it
  1332. # [22:02] <Hixie> that's the changes
  1333. # [22:02] <TabAtkins> "Two" differences underscores the magnitude of the differences.
  1334. # [22:02] * Quits: bezoar (~Adium@c-24-143-67-135.customer.broadstripe.net) (Quit: Leaving.)
  1335. # [22:02] <Hixie> i don't think you mean "underscores" but i agree with what you actually said, even if it's not what you meant :-)
  1336. # [22:03] <TabAtkins> s/underscores/understates/
  1337. # [22:03] <Hixie> the differences are nearly trivial. XBL2 could be adopted to separating them with barely a dozen edits.
  1338. # [22:03] <TabAtkins> I... don't know how to respond to that, except by saying "No".
  1339. # [22:04] <Hixie> let me know when you have a more coherent answer :-)
  1340. # [22:04] <TabAtkins> "You're wrong"?
  1341. # [22:04] <Hixie> maybe you can explain how?
  1342. # [22:05] <TabAtkins> The ideal API for permanently changing something is a decent bit different from the ideal API for adding a swappable decorator.
  1343. # [22:05] <Hixie> sure. One is is="foo" and the other is binding: foo;
  1344. # [22:06] <Hixie> you're not suggesting that shadow trees would need to be defined differently, or that event handlers for one would look different than for the other, right?
  1345. # [22:07] <TabAtkins> Shadow trees should use the same definition mechanism, obviously. Binding event listeners may look different. Exposing further API beyond that would definitely look different, since you can't do it at all in the decorator case.
  1346. # [22:08] * Joins: smaug____ (~chatzilla@GYGKLI.gprs.sl-laajakaista.fi)
  1347. # [22:08] * Quits: gavin__ (~gavin@people.mozilla.com) (Read error: Connection reset by peer)
  1348. # [22:09] * Joins: gavin__ (~gavin@people.mozilla.com)
  1349. # [22:11] * Joins: othermaciej (~mjs@17.245.89.211)
  1350. # [22:12] * jernoble|afk is now known as jernoble
  1351. # [22:13] * Joins: weinig (~weinig@17.212.155.112)
  1352. # [22:15] * Joins: roc (~chatzilla@60.234.54.74)
  1353. # [22:15] * Quits: cygri (~cygri@89.19.73.208) (Quit: cygri)
  1354. # [22:16] <Hixie> TabAtkins: just excluding certain features in one case doesn't make it look different, just excludes certain features
  1355. # [22:16] <Hixie> bbiab lunch
  1356. # [22:19] * Joins: Telling (~unknown@109.57.161.96)
  1357. # [22:24] * Quits: Telling (~unknown@109.57.161.96) (Quit: ...)
  1358. # [22:30] * Quits: necolas (~necolas@5e0c0fc8.bb.sky.com) (Remote host closed the connection)
  1359. # [22:30] * Quits: davidb_ (~davidb@66.207.208.98) (Quit: davidb_)
  1360. # [22:30] * Joins: necolas (~necolas@5e0c0fc8.bb.sky.com)
  1361. # [22:31] * Quits: necolas (~necolas@5e0c0fc8.bb.sky.com) (Read error: Connection reset by peer)
  1362. # [22:31] * Joins: jacobolus (~jacobolus@c-71-198-169-213.hsd1.ca.comcast.net)
  1363. # [22:32] * Joins: necolas (~necolas@5e0c0fc8.bb.sky.com)
  1364. # [22:34] * Joins: espadrine (~thaddee_t@acces2299.res.insa-lyon.fr)
  1365. # [22:35] * Quits: othermaciej (~mjs@17.245.89.211) (Quit: othermaciej)
  1366. # [22:41] * Joins: rillian__ (~rillian@184.71.166.126)
  1367. # [22:42] * Joins: othermaciej (~mjs@17.245.89.211)
  1368. # [22:45] * Quits: rillian_ (~rillian@184.71.182.138) (Ping timeout: 276 seconds)
  1369. # [22:46] * Joins: sicking (~chatzilla@206-15-76-122.static.twtelecom.net)
  1370. # [22:51] * Quits: FlorianX1 (~Florian_S@p4FE2DC21.dip.t-dialin.net) (Quit: Leaving.)
  1371. # [22:51] * Quits: jamesr (jamesr@nat/google/x-lrwiujrawvzcvkom) (Ping timeout: 240 seconds)
  1372. # [22:51] * Quits: Stikki (~lordstich@dsl-pribrasgw1-ff17c300-80.dhcp.inet.fi) (Ping timeout: 245 seconds)
  1373. # [22:51] * Quits: mpt (~mpt@canonical/mpt) (Ping timeout: 240 seconds)
  1374. # [22:52] * Joins: jamesr (jamesr@nat/google/x-awxbpzvxagbpbudg)
  1375. # [22:54] * Joins: Stikki (~lordstich@dsl-pribrasgw1-ff17c300-80.dhcp.inet.fi)
  1376. # [23:00] * Quits: MacTed (~Thud@63.119.36.36)
  1377. # [23:02] * heycam|away is now known as heycam
  1378. # [23:04] * Quits: dbaron (~dbaron@nat/mozilla/x-xywnhhmgajjnwoxi) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  1379. # [23:08] * Joins: dbaron (~dbaron@nat/mozilla/x-gmbbdsccjzdtbycp)
  1380. # [23:12] * AryehGregor ponders the philosophy of testing features that depend on one another
  1381. # [23:12] <AryehGregor> If you can't test one feature because an unrelated feature is buggy or unsupported, should the test pass or fail?
  1382. # [23:12] <AryehGregor> If it fails, you're putting a lot of weight on possibly minor bugs in features that other features happen to depend on.
  1383. # [23:13] <AryehGregor> If it passes, that takes more effort to handle, and also you penalize browsers for fixing bugs in features that other features depend on (because their score can only go down).
  1384. # [23:13] <AryehGregor> (for the dependent tests, that is)
  1385. # [23:14] <gsnedders> It's a failure, because you've failed to run the test.
  1386. # [23:14] <AryehGregor> I guess it should generally fail, unless there's some way to avoid the bug in the underlying feature.
  1387. # [23:14] <gsnedders> Unless the test is simply not applicable.
  1388. # [23:15] <AryehGregor> Well, if you can easily work around the underlying bug, I think you should.
  1389. # [23:15] <AryehGregor> Like WebKit throws WrongDocumentError if you try to set a range's endpoint to a node that's in another document from the one you created the range in.
  1390. # [23:15] * Quits: zdobersek (~zan@BSN-176-193-184.dial-up.dsl.siol.net) (Quit: Leaving.)
  1391. # [23:16] <AryehGregor> So when creating ranges for tests, other than in setStart/setEnd tests, I make sure that I call createRange() on the ownerDocument of the intended endpoints.
  1392. # [23:16] <AryehGregor> Otherwise that one minor bug would create zillions of spurious failures in unrelated features.
  1393. # [23:17] <gsnedders> You can always have it as a separate prereq function, and group results into pass, fail, prereq failed
  1394. # [23:17] * Quits: Maurice (copyman@5ED573FA.cm-7-6b.dynamic.ziggo.nl)
  1395. # [23:18] <AryehGregor> That doesn't really solve the problem. It just obscures it.
  1396. # [23:18] * AryehGregor discovers that the Range tests all seem to be broken, since no one adjusted the relative URLs to testharness.js
  1397. # [23:18] * AryehGregor goes to fix
  1398. # [23:22] * Quits: tomasf (~tom@c-5ed9e555.024-204-6c6b7012.cust.bredbandsbolaget.se) (Quit: tomasf)
  1399. # [23:23] * Quits: KevinMarks (~KevinMark@c-71-204-145-244.hsd1.ca.comcast.net)
  1400. # [23:24] * Quits: scor (~scor@drupal.org/user/52142/view) (Quit: scor)
  1401. # [23:24] <jgraham> AryehGregor: You should avoid unnecessarily depending on features that you aren't explicitly trying to test
  1402. # [23:24] <AryehGregor> On the other hand, IE seemingly doesn't let you create Ranges whose boundary points don't descend from a Document.
  1403. # [23:25] <jgraham> But you should always be conservative about handing out "pass"
  1404. # [23:25] <AryehGregor> So if I have a test that starts by creating such a range, what am I supposed to do?
  1405. # [23:25] <AryehGregor> In that case, I have to fail it.
  1406. # [23:25] * Quits: dbaron (~dbaron@nat/mozilla/x-gmbbdsccjzdtbycp) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  1407. # [23:25] <jgraham> AryehGregor: Yes. They have a bug. They will fix the bug and the test will pass
  1408. # [23:26] <jgraham> there isn't a problem unless you are creating unnecessary dependencies
  1409. # [23:26] * Quits: rillian__ (~rillian@184.71.166.126) (Ping timeout: 245 seconds)
  1410. # [23:26] * Quits: Rik` (~Rik`@mozilla-paris-253-98.cnt.nerim.net) (Remote host closed the connection)
  1411. # [23:27] <AryehGregor> Now, WebKit/Opera mangle ranges when you do addRange(), so the range that winds up in the actual selection might not have the same boundary points as the one you gave to addRange(). In that case, when testing collapseToStart(), do I just test that whatever range ends up there gets collapsed to the start? Or do I decide that's not really what I'm testing, if the range is substantially different from the one I put in, so I fail them?
  1412. # [23:27] <jgraham> Judgement call
  1413. # [23:27] <AryehGregor> What if they don't put any range in at all, so they wind up with a Selection that has no ranges? Do I just test that they throw an exception, or do I fail them because that has no relationship to what I'm supposed to be testing?
  1414. # [23:27] * AryehGregor is ambivalent about this one
  1415. # [23:28] * Quits: jamesr (jamesr@nat/google/x-awxbpzvxagbpbudg) (Ping timeout: 244 seconds)
  1416. # [23:28] <jgraham> I think I would prefer to be a bit conservative and always check that you have the right range
  1417. # [23:28] * AryehGregor thinks he'll let it slide if there winds up being some Range present, but not if there's no Range, because then you could pass all the tests if addRange() and collapseToStart() were both no-ops
  1418. # [23:28] * Joins: jamesr (jamesr@nat/google/x-pnysjkratmxstbss)
  1419. # [23:28] <AryehGregor> jgraham, that means WebKit fails almost every single test, even though its collapseToStart() implementation seems to be almost completely correct.
  1420. # [23:29] <jgraham> AryehGregor: Well that doesn't seem ideal
  1421. # [23:29] * Joins: dbaron (~dbaron@nat/mozilla/x-vdnqiggajyzrezav)
  1422. # [23:29] <AryehGregor> (Opera fails every test anyway, because its Selection implementation is broken beyond comprehension)
  1423. # [23:29] <jgraham> But maybe it will motivate them to fix the bug :)
  1424. # [23:29] <gsnedders> AryehGregor: But if you can't construct an environment to test that in, then how do you know it's almost completely correct?
  1425. # [23:30] <AryehGregor> gsnedders, because it does add a range, just not the one I specified. And then it collapses the range it did add correctly.
  1426. # [23:31] * Quits: eighty4 (~eighty4@unaffiliated/eighty4) (Quit: ZNC - http://znc.sourceforge.net)
  1427. # [23:31] <gsnedders> AryehGregor: Then should you not assert that it adds the range it does add correctly, regardless of what that is?
  1428. # [23:31] <AryehGregor> gsnedders, yeah, that's what I'm doing.
  1429. # [23:31] <gsnedders> Which means WebKit should pass?
  1430. # [23:31] <AryehGregor> Yes.
  1431. # [23:32] <gsnedders> Then I'm confused.
  1432. # [23:34] * Joins: rillian_ (~rillian@184.71.166.126)
  1433. # [23:34] <AryehGregor> Okay, so now Gecko passes everything because it's actually correct, Opera fails everything because it's actually completely broken, WebKit fails about half the tests because it doesn't add any range at all in some cases, and IE fails almost all the tests because it genuinely has a bug in collapseToStart/End.
  1434. # [23:34] <AryehGregor> Seems good to me.
  1435. # [23:35] * Quits: svl (~me@ip565744a7.direct-adsl.nl) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
  1436. # [23:36] * Quits: Areks (~kvirc@176.14.214.163) (Quit: KVIrc 4.0.2 Insomnia http://www.kvirc.net/)
  1437. # [23:40] <gsnedders> Are we actually that broken? The fact we manage to work with most sites tends to suggest we're not /that/ broken.
  1438. # [23:41] <AryehGregor> gsnedders, it could be some artifact of my test setup. I tend to find that addRange() routinely does nothing in Opera.
  1439. # [23:41] <AryehGregor> So the selection remains empty.
  1440. # [23:41] <AryehGregor> I suspect it has something to do with Opera deciding the range I give it isn't visible or something.
  1441. # [23:42] <AryehGregor> Also, authors in real life commonly deal with user-created selections and don't use addRange at all.
  1442. # [23:42] <AryehGregor> But obviously tests can't do that.
  1443. # [23:42] <rniwa> AryehGregor: what is this range bug you're describing?
  1444. # [23:42] <AryehGregor> rniwa, WebKit fails lots of Selection tests because addRange() doesn't add the same range it's given, it normalizes it. As we've discussed.
  1445. # [23:43] <rniwa> AryehGregor: ah I see.
  1446. # [23:43] <AryehGregor> gsnedders, http://dvcs.w3.org/hg/editing/raw-file/tip/selecttest/collapseToStartEnd.html
  1447. # [23:44] <AryehGregor> rniwa, but there are two other tests here that fail for a different reason (not "Sanity check"), didn't look into it closely: http://dvcs.w3.org/hg/editing/raw-file/tip/selecttest/collapseToStartEnd.html
  1448. # [23:44] * Joins: jdaggett (~jdaggett@y230056.dynamic.ppp.asahi-net.or.jp)
  1449. # [23:51] <gsnedders> AryehGregor: Where's the spec, again?
  1450. # [23:51] <AryehGregor> gsnedders, it's wandered around a bit, but is now part of the editing spec. http://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#selections
  1451. # [23:53] <gsnedders> AryehGregor: Okay, so addRange only does something if the range is not detached (in the DOM) and is collapsed.
  1452. # [23:54] <AryehGregor> It only works if the range is collapsed?
  1453. # [23:54] <AryehGregor> Wha?
  1454. # [23:54] <AryehGregor> Not detached I understand, although it's not per spec.
  1455. # [23:54] <AryehGregor> But collapsed?
  1456. # [23:54] <AryehGregor> How are you supposed to create non-collapsed selections, then?
  1457. # [23:54] <gsnedders> Don't ask me. I'm just reading the code. :)
  1458. # [23:55] * Joins: AlvarL (~laigna@87-119-176-221.tll.elisa.ee)
  1459. # [23:56] * Quits: AlvarL (~laigna@87-119-176-221.tll.elisa.ee) (Client Quit)
  1460. # [23:56] <gsnedders> Do you have tests for isCollapsed? That may help…
  1461. # [23:56] <AryehGregor> Well, if you can suggest a sane way to create non-collapsed selections, I'm willing to add the workaround to my selection tests.
  1462. # [23:56] * heycam is now known as heycam|away
  1463. # [23:56] * Quits: hasather_ (~hasather_@84.38.144.96) (Remote host closed the connection)
  1464. # [23:57] <AryehGregor> I haven't tested isCollapsed yet, but if I did, it would consist of making a bunch of selections with addRange() and then checking isCollapsed, so it would still break in Opera.
  1465. # [23:57] <AryehGregor> Also, Opera seems to not be adding even collapsed non-detached selections when I do addRange(), in my collapseToStart/End tests.
  1466. # [23:58] <AryehGregor> All the nodes that are detached are named detached* in the test names, or foreign* for a foreign document, or xml* for a foreign XML document.
  1467. # [23:59] * Joins: Rik` (~Rik`@lag75-1-78-192-241-87.fbxo.proxad.net)
  1468. # [23:59] * Joins: eighty4 (~eighty4@unaffiliated/eighty4)
  1469. # Session Close: Wed Oct 12 00:00:00 2011

The end :)