/irc-logs / w3c / #html-wg / 2010-02-17 / end

Options:

  1. # Session Start: Wed Feb 17 00:00:00 2010
  2. # Session Ident: #html-wg
  3. # [00:28] * Joins: rubys1 (rubys@98.27.53.108)
  4. # [00:29] * Quits: rubys (rubys@98.27.53.108) (Quit: Leaving.)
  5. # [00:29] * rubys1 is now known as rubys
  6. # [00:53] * Quits: mjs (mjs@69.181.42.237) (Quit: mjs)
  7. # [00:59] * Quits: gavin_ (gavin@99.226.207.11) (Ping timeout)
  8. # [01:03] * Quits: aroben (aroben@71.58.77.15) (Connection reset by peer)
  9. # [01:03] * Joins: gavin_ (gavin@99.226.207.11)
  10. # [01:58] * Joins: mjs (mjs@17.246.19.253)
  11. # [02:01] * Joins: miketaylr (miketaylr@24.42.95.234)
  12. # [02:04] * Joins: MikeSmithXX (MikeSmith@114.48.218.100)
  13. # [02:07] * Quits: MikeSmithX (MikeSmith@114.48.136.110) (Ping timeout)
  14. # [02:58] * Joins: plh (plh@128.30.52.28)
  15. # [03:01] * MikeSmithXX is now known as MikeSmith
  16. # [03:08] * Quits: gavin_ (gavin@99.226.207.11) (Ping timeout)
  17. # [03:13] * Joins: gavin_ (gavin@99.226.207.11)
  18. # [03:19] * Joins: dsinger (dsinger@67.218.106.55)
  19. # [03:23] * Joins: paul_irish (paul_irish@206.193.201.155)
  20. # [03:28] * Joins: annodomini (lambda@75.69.96.104)
  21. # [04:02] * Quits: dsinger (dsinger@67.218.106.55) (Quit: dsinger)
  22. # [04:06] * Quits: plh (plh@128.30.52.28) (Quit: always accept cookies)
  23. # [04:10] * Parts: rubys (rubys@98.27.53.108)
  24. # [04:19] * Quits: drunknbass_work (aaron@71.106.110.90) (Ping timeout)
  25. # [05:27] * Quits: gavin_ (gavin@99.226.207.11) (Ping timeout)
  26. # [05:32] * Joins: gavin_ (gavin@99.226.207.11)
  27. # [06:06] * Quits: miketaylr (miketaylr@24.42.95.234) (Client exited)
  28. # [06:09] * Joins: dsinger (dsinger@68.126.176.203)
  29. # [06:18] * Quits: krove (krove@174.51.56.48) (Quit: krove)
  30. # [06:31] * Quits: mjs (mjs@17.246.19.253) (Quit: mjs)
  31. # [06:52] * Quits: Lachy (Lachlan@83.170.95.133) (Ping timeout)
  32. # [07:23] * Joins: mjs (mjs@69.181.42.237)
  33. # [07:40] * Quits: gavin_ (gavin@99.226.207.11) (Ping timeout)
  34. # [07:45] * Joins: gavin_ (gavin@99.226.207.11)
  35. # [08:04] * Joins: MikeSmithX (MikeSmith@114.48.73.227)
  36. # [08:06] * Quits: MikeSmith (MikeSmith@114.48.218.100) (Ping timeout)
  37. # [08:23] * Joins: Lachy (Lachlan@83.170.95.133)
  38. # [08:48] * Joins: Thezilch[FH] (fuz007@98.151.147.120)
  39. # [08:49] * Quits: Thezilch (fuz007@98.151.147.120) (Ping timeout)
  40. # [09:26] * Joins: tlr (tlr@128.30.52.169)
  41. # [09:42] * Quits: annodomini (lambda@75.69.96.104) (Quit: annodomini)
  42. # [09:49] * Quits: gavin_ (gavin@99.226.207.11) (Ping timeout)
  43. # [09:55] * Joins: gavin_ (gavin@99.226.207.11)
  44. # [10:07] * Quits: Lachy (Lachlan@83.170.95.133) (Quit: Leaving)
  45. # [10:10] * Joins: Lachy (Lachlan@83.170.95.133)
  46. # [10:17] * Quits: Lachy (Lachlan@83.170.95.133) (Quit: This computer has gone to sleep)
  47. # [10:18] * Quits: MikeSmithX (MikeSmith@114.48.73.227) (Quit: Till kicked and torn and beaten out he lies, and leaves his hold and crackles, groans, and dies.)
  48. # [10:29] * Joins: Lachy (Lachlan@88.131.66.80)
  49. # [10:29] * Quits: Lachy (Lachlan@88.131.66.80) (Client exited)
  50. # [10:29] * Joins: Lachy (Lachlan@88.131.66.80)
  51. # [10:49] * Joins: ROBOd (robod@89.122.216.38)
  52. # [11:13] <Hixie> Julian: the IANA part of the registration process isn't hte part that I want to test. I already know the IANA part sucks. The question is whether Mark's process ends up being as convenient as a wiki would be, or whether it's a multiple-week process of doom like IANA, or if it's something in between.
  53. # [11:33] <jgraham> What is Mark's process?
  54. # [11:34] * jgraham thinks there should be something more structured tahn a wiki but with similarly low barriers to entry
  55. # [11:34] <Hixie> it's described in his draft proposal; i don't recall offhand exactly how it works
  56. # [11:34] <Hixie> it's basically a layer in front of IANA, iirc
  57. # [11:35] <anne> i thought it still involved email and IANA
  58. # [11:35] <anne> just faster approval time and less requirements
  59. # [11:35] <anne> but maybe I missed something
  60. # [11:37] <Hixie> why do i get the crash-recovery dialog every time i open opera?
  61. # [11:37] <Hixie> oops, wc
  62. # [11:39] <Julian> Hixie, it's still IANA
  63. # [11:39] <Julian> the only thing that is added is the mailing-list based distribution of updates
  64. # [11:40] * tlr is now known as tlr-bbl
  65. # [11:40] <Julian> and, at least for the link relation registry, there doesn't seem to be a problem with IANA
  66. # [11:40] <Julian> anne, "less requirements" than?
  67. # [11:41] <anne> before?
  68. # [11:42] <Julian> "before" as in "earlier drafts" or in "Atom link relation"?
  69. # [11:42] <anne> former
  70. # [11:44] <Julian> the IANA requirements haven't changed in a long time, it's "Designated Expert" + "Specification Required"
  71. # [11:45] <anne> oh lol
  72. # [11:45] <anne> so it's not better at all
  73. # [11:46] <Julian> that is not constructive
  74. # [11:46] <anne> agreed
  75. # [11:46] <anne> the constructive bits have been provided in the past
  76. # [11:47] <Julian> if you're unhappy with the current state of ISSUE-27, please follow up on the mailing list thread
  77. # [11:48] <Julian> if you're unhappy with what the draft says, then send comments
  78. # [11:48] <Julian> the LC ended yesterday, but I'm sure comments are welcome anyway
  79. # [11:50] <anne> it's been known for a while i'm unhappy with the status, but i've plenty of other things to do
  80. # [11:51] <Julian> jgraham, see http://greenbytes.de/tech/webdav/draft-nottingham-http-link-header-07.html#rfc.section.6.2.1
  81. # [11:51] * Quits: tH (Rob@82.4.89.172) (Ping timeout)
  82. # [11:51] * Joins: tH (Rob@82.4.89.172)
  83. # [11:58] * Quits: gavin_ (gavin@99.226.207.11) (Ping timeout)
  84. # [12:02] * Joins: gavin_ (gavin@99.226.207.11)
  85. # [12:06] <mjs> anne: "Specification Required" seems to match the old wiki-based systems requirements
  86. # [12:07] <mjs> at least, for being fully accepted
  87. # [12:07] <mjs> does the new registry have a mechanism for provisional registration?
  88. # [12:07] <anne> sure, but the advantage was that everything that's in draft was there too
  89. # [12:08] <Julian> " Specification Required - Values and their meanings must be documented in a permanent and readily available public specification, in sufficient detail so that interoperability between independent implementations is possible. When used, Specification Required also implies use of a Designated Expert, who will review the public...
  90. # [12:08] <Julian> ...specification and evaluate whether it is sufficiently clear to allow interoperable implementations. The intention behind "permanent and readily available" is that a document can reasonably be expected to be findable and retrievable long after IANA assignment of the requested value. Publication of an RFC is an ideal...
  91. # [12:08] <Julian> ...means of achieving this requirement, but Specification Required is intended to also cover the case of a document published outside of the RFC path. For RFC publication, the normal RFC review process is expected to provide the necessary review for interoperability, though the Designated Expert may be a particularly well-qualified...
  92. # [12:08] <anne> and everything else people came across
  93. # [12:08] <Julian> ... person to perform such a review. Examples: Diffserv-aware TE Bandwidth Constraints Model Identifiers [RFC4124], TLS ClientCertificateType Identifiers [RFC4346], ROHC Profile Identifiers [RFC4995]."
  94. # [12:08] <Julian> http://tools.ietf.org/html/rfc5226#section-4.1
  95. # [12:08] * mjs does not see the word "provisional" in the internet-draft
  96. # [12:08] <Julian> no, there is no provisional registry
  97. # [12:08] <mjs> why not?
  98. # [12:09] <mjs> I guess I should send that belated comment
  99. # [12:09] <Julian> did anybody ask for it?
  100. # [12:09] <mjs> http header fields have a provisional registry
  101. # [12:09] <Julian> I don't recall that.
  102. # [12:09] <anne> they do
  103. # [12:09] <mjs> I don't think anyone asked
  104. # [12:09] <Julian> well, there are registries that have it, and registries that do not
  105. # [12:09] <mjs> I don't care enough about this issue either way, so I didn't review Mark's draft in detail
  106. # [12:10] <mjs> I only checked that everyone else felt their concerns were addressed
  107. # [12:10] <mjs> http://www.ietf.org/rfc/rfc3864.txt
  108. # [12:10] <Julian> what problem do you want to solve by a provisional registry?
  109. # [12:10] <mjs> there is definitely a provisional registration status
  110. # [12:10] <mjs> Julian: collision avoidance in cases where no one has written a full specification yet
  111. # [12:10] <mjs> same as for provisionally registered http headers
  112. # [12:30] <mjs> Julian: I guess I just assumed there would be provisional registration, consistent with provisional registration of http headers, provisional registration of URI schemes, and registration of vendor, personal and experimental MIME types
  113. # [12:30] <mjs> maybe I should comment
  114. # [12:36] * Joins: MikeSmith (MikeSmith@114.48.237.22)
  115. # [12:54] * Joins: J_Voracek (irchon@166.205.10.88)
  116. # [12:54] * Quits: J_Voracek (irchon@166.205.10.88) (Client exited)
  117. # [12:59] <Julian> my experience is that adding even more registration options doesn't help when people ignore registries anyway
  118. # [12:59] <Julian> so, for instance, there is a provisional URI scheme registry
  119. # [13:00] <Julian> it doesn't list "itms" or "ical"
  120. # [13:00] <Julian> nor the permanent one
  121. # [13:00] <Hixie> why don't you register them?
  122. # [13:01] * Joins: Michelangelo (Michelange@193.205.162.69)
  123. # [13:03] <Julian> should I make up the documentation?
  124. # [13:03] <Hixie> i dunno, you're the one who cares about registration
  125. # [13:03] <Julian> Believe me, I was tempted to do so multiple times :-)
  126. # [13:03] <Hixie> then do it
  127. # [13:04] <anne> with a wiki we'd just put them in and say "Documentation missing"
  128. # [13:05] <anne> and at least it would be clear they're floating around versus the current situation where you have to go from blog posts, wikipedia, etc.
  129. # [13:05] <mjs> Are itms links still used? this page provides you with http: links http://ax.phobos.apple.com.edgesuite.net/WebObjects/MZStoreServices.woa/wa/itmsLinkMaker
  130. # [13:07] * Parts: mjs (mjs@69.181.42.237)
  131. # [13:08] * Joins: mjs (mjs@69.181.42.237)
  132. # [13:08] <hsivonen> mjs: doesn't "View In iTunes" there use itms: for dispatch?
  133. # [13:09] <mjs> iTunes does still respect them, and I presume Web pages use something like that to open a view in iTunes (I think it used to use a plugin at some point)
  134. # [13:25] * Quits: Julian (chatzilla@217.91.35.233) (Ping timeout)
  135. # [13:25] <Philip> http://www.ilike.com/artist/Aled+Jones/track/Morning+Has+Broken
  136. # [13:25] <Philip> They still use itms://...
  137. # [13:26] * Joins: Julian (chatzilla@217.91.35.233)
  138. # [13:26] <mjs> this is not a topic on which I am an expert, sadly
  139. # [13:27] <mjs> because it is easy to register to open URIs of a particular URI scheme with the OS, and because dispatch is done without any networking, they are commonly used as a way to view a resource in a particular application
  140. # [13:27] <mjs> as opposed to solely to identify the resource
  141. # [13:28] <mjs> in theory it's more correct to use MIME types for application dispatch
  142. # [13:28] <anne> it's apparently the result of many popular exploits
  143. # [13:28] <mjs> but it would suck to have to do a download of something just to open iTunes or iCal
  144. # [13:28] <anne> sorry, what lead to many exploits
  145. # [13:28] <anne> or led, bah
  146. # [13:28] <mjs> I assume this is why the teams in question do it
  147. # [13:29] <Philip> It seems pretty common for games to use URLs like unreal://12.34.56.78:1234 so you can click a link in a web browser and launch the game which will connect to the given server
  148. # [13:30] <mjs> in the case of Unreal it does define a specific kind of resource (an Unreal server)
  149. # [13:30] <mjs> the "feed:" URL scheme (used by Safari among others, I am sad to say) is solely for the purpose of application dispatch and actually names an http resource
  150. # [13:30] <mjs> based on these things I have often wondered if there should be a way to do dispatch to some chosen external processor without forcing a download *and* without resorting to questionable use of URI schemes
  151. # [13:30] <anne> sometimes used as feed:http:// even!
  152. # [13:41] <Julian> feed, itms, and ical are all aliases for http, aren't they?
  153. # [13:46] <Julian> mjs, maybe using a link relation?
  154. # [13:46] <mjs> feed is not a synonym for http necessarily
  155. # [13:47] <mjs> feed: can be applied to any other URI scheme (though http: is the default)
  156. # [13:47] <mjs> I don't actually know what itms: or ical: do besides launching those particular applications
  157. # [13:47] <mjs> the problem with link relations is that they don't get preserved via the usual mechanisms of copying links, which is to just copy the URL
  158. # [13:50] <Julian> so why is fetching the content, checking the MIME type, and dispatching to an application at that point a problem?
  159. # [13:51] <mjs> it's more complicated and slower, to the point that app authors don't want to do it
  160. # [13:51] * tlr-bbl is now known as tlr
  161. # [13:51] <mjs> (I should add that the custom URL scheme phenomenon occurs on pretty much any OS that lets apps register to handle requests for URIs with a particular scheme)
  162. # [13:51] * Quits: Michelangelo (Michelange@193.205.162.69) (Ping timeout)
  163. # [13:52] <mjs> For example, mailto: is instant if your Mail client is already running, it would suck if it had to contact some Web server first and download something
  164. # [13:52] <mjs> not saying it's impossible, this is just my best understanding of why content authors do it
  165. # [13:53] <mjs> er, app authors I mean
  166. # [13:53] <Julian> but in this case it's an HTTP resource anyway; what changes is just the point when the dispatching happens
  167. # [13:54] <Julian> what you need is a format that preserves the information where the entity body came from (in Atom it's the "self" link relation)
  168. # [13:57] <mjs> for the case of a feed: link to launch an external feed reader, if you replace it with an http: link, that will generally lead to either a double load of the resource, or the feed reader not launching at all until the resource is fully retrieved
  169. # [13:57] <mjs> in theory it would be possible to come up with a way to hand off a live http stream from one app to another (including what has been received so far)
  170. # [13:57] <mjs> I don't think any OS vendor has chosen to implement such a thing
  171. # [13:57] <Julian> mjs, but as far as I can tell that happens exactly once; upon feed subscription.
  172. # [13:58] <Julian> Where's the problem with that?
  173. # [13:58] <Julian> mjs, what "kind of thing"?
  174. # [13:58] <mjs> don't ask me, I didn't invent feed:
  175. # [13:58] <mjs> being able to transfer a live http connection (that would allow app dispatch based on content types without significant delay and without double download)
  176. # [13:58] <mjs> users are sensitive to a little delay though
  177. # [13:59] <mjs> at one point I implemented a feature in Safari where, when you command-clicked a link, instead of opening a new tab/window right away, it would wait to see if it was going to display the resource directly or download it
  178. # [13:59] <mjs> so it could avoid opening a useless tab/window at all if it was just going to do a download
  179. # [13:59] <Julian> you don't need to transfer live HTTP connection
  180. # [13:59] <mjs> everyone hated it because it made it seem like their cmd-click didn't work
  181. # [14:00] <mjs> I'm saying transferring live http connections is a plausible way to do things that wouldn't cause a slowdown
  182. # [14:00] <mjs> downloading and then dispatching based on MIME type is something you can do today, that no one seems to want to do
  183. # [14:00] <Julian> ok
  184. # [14:00] <mjs> (Mac OS X even preserves the URL that the resource was loaded from, in filesystem metadata)
  185. # [14:00] <Julian> I just don't see how that's relevant for the act of subscribing to a feed or a remote calendar.
  186. # [14:01] <Julian> mjs, cool!
  187. # [14:01] <mjs> I'm giving you my best understanding, I am not the one who designed these things
  188. # [14:01] <Julian> MacOS, or Safari?
  189. # [14:01] <mjs> but I do understand that users are extremely sensitive to latency
  190. # [14:02] <Julian> well, users are also sensitive to links that work only on certain platforms :-)
  191. # [14:02] <mjs> well, Mac OS X has the facility, WebKit-based browsers will use it by default, I can't speak for whether other browsers properly set the appropriate metadata field
  192. # [14:02] <mjs> I think app developers don't care about the experience for users who don't have their app
  193. # [14:03] <Julian> what should be relevant are not the app developers, but the content providers
  194. # [14:04] * Joins: plh (plh@128.30.52.28)
  195. # [14:04] <Julian> it sucks to provide different hyperlinks depending on the platform the request came from
  196. # [14:05] * Quits: gavin_ (gavin@99.226.207.11) (Ping timeout)
  197. # [14:06] <anne> well, feed: "works" regardless of the platform
  198. # [14:07] <anne> and the other URIs in theory too, apps can register for them
  199. # [14:07] <anne> and the UA will dispatch per system mappings
  200. # [14:07] <mjs> this is a problem I sometimes think about but it's not high on my personal list of problems with the Web to solve
  201. # [14:07] <mjs> there are only so many hours in the day
  202. # [14:11] * Joins: gavin_ (gavin@99.226.207.11)
  203. # [14:14] * Julian wonders why Thunderbird Lightning then doesn't register for "ical"
  204. # [14:23] <anne> i guess my point is that ivory tower registries are far from useful
  205. # [14:27] * Quits: arronei (arronei@131.107.0.104) (Ping timeout)
  206. # [14:30] * Quits: tH (Rob@82.4.89.172) (Ping timeout)
  207. # [14:30] <mjs> I can understand the requirement to have a spec for anything to be fully accepted, it just seems like too high a bar to be listed at all
  208. # [14:31] <mjs> maybe HTML5 should just allow anything as a rel value
  209. # [14:31] <anne> well, some warnings would at least be appropriate
  210. # [14:32] * Joins: J_Voracek (irchon@166.205.10.251)
  211. # [14:32] * Quits: J_Voracek (irchon@166.205.10.251) (Client exited)
  212. # [14:33] * Joins: arronei (arronei@131.107.0.72)
  213. # [14:33] * Quits: MikeSmith (MikeSmith@114.48.237.22) (Quit: Till kicked and torn and beaten out he lies, and leaves his hold and crackles, groans, and dies.)
  214. # [14:42] <Julian> mjs, I agree that coupling conformance to a registry may not be a good idea
  215. # [14:50] * Joins: Alex_Ivaylov (alex@85.187.214.246)
  216. # [14:58] * Joins: sbublava (sbublava@77.119.90.189)
  217. # [15:01] * Quits: paul_irish (paul_irish@206.193.201.155) (Client exited)
  218. # [15:06] * Quits: Lachy (Lachlan@88.131.66.80) (Quit: Leaving)
  219. # [15:07] * Joins: Lachy (Lachlan@208.100.23.169)
  220. # [15:09] * Quits: Lachy (Lachlan@208.100.23.169) (Quit: Leaving)
  221. # [15:09] * Joins: Lachy (Lachlan@88.131.66.80)
  222. # [15:16] * Joins: aroben (aroben@71.58.77.15)
  223. # [15:40] * Joins: myakura (myakura@123.224.228.213)
  224. # [16:07] * Joins: miketaylr (miketaylr@38.117.156.163)
  225. # [16:14] * Quits: gavin_ (gavin@99.226.207.11) (Ping timeout)
  226. # [16:15] * Joins: annodomini (lambda@75.69.96.104)
  227. # [16:19] * Joins: gavin_ (gavin@99.226.207.11)
  228. # [16:44] * Joins: alexf (alejandro@85.152.42.1)
  229. # [16:44] * Parts: alexf (alejandro@85.152.42.1)
  230. # [16:50] * Quits: dsinger (dsinger@68.126.176.203) (Quit: dsinger)
  231. # [16:51] * Quits: myakura (myakura@123.224.228.213) (Quit: Leaving...)
  232. # [16:51] <Julian> Henri, yt?
  233. # [16:52] <anne> the difference between <embed> and <object> is that <object> does handle images and <embed> solely handles images
  234. # [16:52] <anne> some browsers handle images for <embed> too, which makes them "plugins" as far as <embed> is concerned
  235. # [16:53] <Julian> ?
  236. # [16:53] <Julian> I thought <embed> used to invoke plugins in the past...?
  237. # [16:53] <Julian> and why does it matter how a content handler is invoked?
  238. # [16:54] <Julian> right now, the plugin definition doesn't mention that
  239. # [16:54] <anne> sorry, <embed> solely handles plugins, doh
  240. # [16:55] <Julian> ok
  241. # [16:55] * Quits: Alex_Ivaylov (alex@85.187.214.246) (Client exited)
  242. # [16:55] <Julian> so if I <embedded> a JPG, and didn't have a *plugin* registered for that mime type, it wouldn't display, while it would with <object>?
  243. # [16:56] <anne> it might still display, but then the UA is considered the plugin handler
  244. # [16:57] <anne> if you explicitly override that (if the UA allows it) it might not display
  245. # [16:57] <anne> but would with <object>
  246. # [16:57] <Julian> ok, so let's leave <embed> aside for now
  247. # [16:57] <Julian> ...
  248. # [16:58] <Julian> the new definition still makes the builtin code that handles JPGs a "plugin", right?
  249. # [16:59] <anne> seems so
  250. # [16:59] <anne> not sure if that's good
  251. # [16:59] <anne> but plugins are sort of magic so i guess it doesn't matter much
  252. # [17:00] <Julian> it's amazingly hard to define, I think, but without a definition it's tricky to discuss the impact of sandboxed iframes
  253. # [17:00] <Julian> it didn't matter back when there were no normative requirements on plugin handling
  254. # [17:01] <anne> seems pretty clear what should happen there
  255. # [17:02] * Joins: Alex_Ivaylov (alex@85.187.214.246)
  256. # [17:02] <Julian> if it is, please follow up on the mailing list; it would be good to make progress with this
  257. # [17:02] <anne> well, no idea how to define it
  258. # [17:02] <Julian> for instance
  259. # [17:03] <anne> just that it's clear that Flash / Java / etc. ought not to work
  260. # [17:03] <Julian> - will JPG embedded with <object> display? will SVG?
  261. # [17:03] <anne> of course
  262. # [17:04] <Julian> - how about quicktime in <video> (not sure about that)
  263. # [17:04] <Julian> - what about FLV in <video>
  264. # [17:04] <Julian> it's not what the spec currently says, as far as I can tell
  265. # [17:04] <Julian> it's probably what people do expect, sure
  266. # [17:05] <anne> is FLV a video format?
  267. # [17:05] <plh> regarding flv in video, I would think that's a codec issue. whehther it's ogv, mp4, or flv is the same
  268. # [17:05] <plh> anne, I believe so
  269. # [17:05] <Julian> I believe so: http://en.wikipedia.org/wiki/Flash_Video
  270. # [17:06] <anne> those would prolly be ok then, if the UA decides to support them
  271. # [17:06] <plh> yep
  272. # [17:06] <Julian> so what I'm really looking for is a precise definition of what a "content handler" inside a sandboxed iframe is supposed to allow and forbid
  273. # [17:07] <Julian> we then can define a plugin API expressing that
  274. # [17:07] <plh> for quicktime, it's a player so it doesn't make sense to associate with <video>. quicktime uses mp4 (and a few others).
  275. # [17:07] <anne> well, safari uses quicktime for <video>
  276. # [17:09] <Julian> I'm looking for a precise definition of what content handlers may or may not do in sandboxed iframes. Absent that, that feature is underspecified and probably needs to be removed.
  277. # [17:20] * Quits: gavin_ (gavin@99.226.207.11) (Ping timeout)
  278. # [17:21] * Joins: gavin_ (gavin@99.226.207.11)
  279. # [17:21] <anne> I thought your favorite was to leave it undefined?
  280. # [17:23] <Julian> I like "undefined" for broken content.
  281. # [17:23] <Julian> This is not about broken content.
  282. # [17:23] <anne> plugins are broken :)
  283. # [17:36] <plh> it depends on your definition of broken I guess :)
  284. # [17:37] <anne> not being cross-platform would be one particle of my definition
  285. # [17:38] <anne> but sure
  286. # [17:38] <Julian> browsers aren't inherently cross-platform, either
  287. # [17:39] <anne> nope, but that doesn't matter
  288. # [17:39] <Julian> what's broken are closed formats
  289. # [17:51] * Joins: dsinger (dsinger@67.218.109.152)
  290. # [17:58] * Quits: Alex_Ivaylov (alex@85.187.214.246) (Quit: Alex_Ivaylov)
  291. # [18:02] * Joins: Lachy_PC (Lachy@213.236.208.22)
  292. # [18:03] * Lachy_PC is now known as anne42
  293. # [18:09] * Quits: gavin_ (gavin@99.226.207.11) (Ping timeout)
  294. # [18:12] * Joins: gavin_ (gavin@99.226.207.11)
  295. # [18:16] * Quits: dsinger (dsinger@67.218.109.152) (Quit: dsinger)
  296. # [18:23] * Joins: dsinger (dsinger@17.197.20.4)
  297. # [18:25] * Quits: mjs (mjs@69.181.42.237) (Quit: mjs)
  298. # [18:50] * Quits: anne42 (Lachy@213.236.208.22) (Quit: Leaving)
  299. # [18:51] * Joins: drunknbass_work (aaron@71.106.110.90)
  300. # [19:01] * Joins: tH (Rob@82.4.89.172)
  301. # [19:17] * Quits: dsinger (dsinger@17.197.20.4) (Quit: dsinger)
  302. # [19:24] * Joins: Stevef (chatzilla@82.44.68.200)
  303. # [19:24] <Stevef> mikesmith: about?
  304. # [19:53] * tlr is now known as tlr-bbl
  305. # [19:58] * Joins: paul_irish (paul_irish@66.167.112.217)
  306. # [20:01] * Quits: sbublava (sbublava@77.119.90.189) (Quit: sbublava)
  307. # [20:33] * Joins: sbublava (sbublava@77.119.90.189)
  308. # [20:44] * Quits: Stevef (chatzilla@82.44.68.200) (Quit: ChatZilla 0.9.85 [Firefox 3.5.3/20090824101458])
  309. # [20:47] * Quits: paul_irish (paul_irish@66.167.112.217) (Ping timeout)
  310. # [20:49] * Joins: paul_irish (paul_irish@66.167.112.217)
  311. # [21:12] * Quits: Lachy (Lachlan@88.131.66.80) (Quit: This computer has gone to sleep)
  312. # [21:13] * Joins: Lachy (Lachlan@88.131.66.80)
  313. # [21:13] * Quits: Lachy (Lachlan@88.131.66.80) (Quit: This computer has gone to sleep)
  314. # [21:19] * Quits: tlr-bbl (tlr@128.30.52.169) (Client exited)
  315. # [21:36] * Quits: sbublava (sbublava@77.119.90.189) (Quit: sbublava)
  316. # [21:41] * Joins: Lachy (Lachlan@81.170.212.11)
  317. # [21:42] * Quits: Lachy (Lachlan@81.170.212.11) (Quit: Leaving)
  318. # [21:42] * Joins: Lachy (Lachlan@83.170.95.133)
  319. # [21:49] * Quits: miketaylr (miketaylr@38.117.156.163) (Client exited)
  320. # [21:52] * Joins: mjs (mjs@69.181.42.237)
  321. # [21:57] * Joins: tlr (tlr@128.30.52.169)
  322. # [21:58] * Parts: tlr (tlr@128.30.52.169)
  323. # [22:10] * Quits: drunknbass_work (aaron@71.106.110.90) (Ping timeout)
  324. # [22:29] * Quits: mjs (mjs@69.181.42.237) (Quit: mjs)
  325. # [22:43] * Quits: ROBOd (robod@89.122.216.38) (Quit: http://www.robodesign.ro )
  326. # [22:53] * Joins: sbublava (sbublava@77.116.43.39)
  327. # [22:55] * Quits: paul_irish (paul_irish@66.167.112.217) (Ping timeout)
  328. # [23:20] * Joins: mjs (mjs@17.246.18.145)
  329. # [23:26] * Joins: drunknbass_work (aaron@71.106.110.90)
  330. # Session Close: Thu Feb 18 00:00:00 2010

The end :)