/irc-logs / freenode / #whatwg / 2009-07-29 / end

Options:

  1. # Session Start: Wed Jul 29 00:00:00 2009
  2. # Session Ident: #whatwg
  3. # [00:06] * Parts: palimpsest (n=palimpse@ip67-152-23-98.z23-152-67.customer.algx.net)
  4. # [00:07] <annevk2> not quite, we can have both static and a live NodeList
  5. # [00:07] * Quits: dbaron (n=dbaron@nat/mozilla/x-aa8a1717a6028fe9) ("8403864 bytes have been tenured, next gc will be global.")
  6. # [00:08] * Joins: sicking (n=chatzill@nat/mozilla/x-eb3bcaf9cc16d84d)
  7. # [00:09] <othermaciej> Hixie: I don't think it makes sense to have the same interface object for interfaces with different methods
  8. # [00:09] <annevk2> and if you change namedItem to always return an Object...
  9. # [00:09] <Hixie> othermaciej: no disagreement from me there
  10. # [00:10] <othermaciej> (I assume this is about having tags() appear on the "all" HTMLCollection but not other HTMLCollections)
  11. # [00:10] <Hixie> annevk2: yeah but the .item() method on the static one is the same as the .item() method on the live one, which isn't the case with these collections
  12. # [00:10] <Hixie> othermaciej: yes
  13. # [00:11] * Quits: ttepasse (n=ttepas--@p5B01495F.dip.t-dialin.net) (Read error: 110 (Connection timed out))
  14. # [00:11] <othermaciej> I think the only sensible way to do it is to make HTMLAllCollection a derived interface, is there a reason that would be a compatibility issue?
  15. # [00:12] <othermaciej> (of course the other alternative is to just leave tags() on all HTMLCollections)
  16. # [00:13] <Hixie> right now i've done both. We have two interfaces, and .tags() is on both.
  17. # [00:14] <Hixie> (there are other differences)
  18. # [00:14] * Joins: Rik` (n=Rik`@pha75-2-81-57-187-57.fbx.proxad.net)
  19. # [00:15] <sicking> Hixie, why have .tags() on all HTMLCollections?
  20. # [00:15] <Hixie> because most browsers have it on all HTMLCollection objects
  21. # [00:15] <Hixie> see the mail i just sent to the list
  22. # [00:17] * Joins: dbaron (n=dbaron@nat/mozilla/x-f24af2b08b525baf)
  23. # [00:19] <othermaciej> Hixie: is the return of namedItem the other difference?
  24. # [00:19] <othermaciej> Hixie: I can imagine it might be a problem for HTMLCollection and HTMLAllCollection to have no inheritence relationship at all
  25. # [00:19] <Hixie> and the implementation of .namedItem, yeah
  26. # [00:19] <Hixie> why?
  27. # [00:19] <Hixie> the other collection interfaces have no relationship either
  28. # [00:19] <Hixie> there's five of them at this point
  29. # [00:19] <Hixie> they're all basically the same with weird minor differences
  30. # [00:20] <othermaciej> I don't know that it is a problem for sure, but if someone wants to prototype-hack HTMLCollection to add or modify a method, it won't work on the unrelated types of collection
  31. # [00:20] <Hixie> correct
  32. # [00:20] * Joins: weinig (n=weinig@nat/apple/x-db2343e4d9ab5b02)
  33. # [00:20] <Hixie> i don't see any way around that given that the prototypes would have different .namedItem()s anyway
  34. # [00:20] <othermaciej> so if that works in browsers currently, it could be a compat issue
  35. # [00:20] <Hixie> i guess we'll find out
  36. # [00:21] <othermaciej> you could just make namedItem() return Object and not worry about the fact that for some collections it's a more specific type
  37. # [00:21] <Hixie> the implementation is still different
  38. # [00:21] <Hixie> so the prototype needs to be different
  39. # [00:21] <othermaciej> that's irrelevant to the interface
  40. # [00:22] <Hixie> not in JS?
  41. # [00:22] <othermaciej> the prototype doesn't need to be different
  42. # [00:22] <othermaciej> we can have a single JS wrapper that can wrap multiple underlying C++ classes with different behavior
  43. # [00:22] <Hixie> so there's only one namedItem() implementation, and it just happens to act very differently in different contexts?
  44. # [00:22] <othermaciej> the JS method just needs to call a C++ virtual method
  45. # [00:22] <Hixie> freaky
  46. # [00:24] * Quits: othermaciej (n=mjs@17.246.18.65)
  47. # [00:29] <Hixie> i'm thinking of adding an event to WebSocket that fires when the buffers are filling too fast
  48. # [00:29] * Joins: tndH_ (n=Rob@cpc2-leed18-0-0-cust427.leed.cable.ntl.com)
  49. # [00:29] <Hixie> what should i call it?
  50. # [00:29] <Hixie> websocket.onoverflow ?
  51. # [00:30] <Hixie> websocket.onthrottle ?
  52. # [00:33] <Hixie> websocket.on... ?
  53. # [00:34] <franksalim> Hixie, the send buffer? or both buffers? the recv buffer must be taken care of by the underlying network layer, right?
  54. # [00:34] <Hixie> send
  55. # [00:36] <ap> Hixie: what's the semantics of this proposed event? does it fire from within send() that will fail?
  56. # [00:36] <Hixie> it fires asynchronously whenever the user agent feels like it (when the UA is in danger of hitting some internal limit)
  57. # [00:37] <Hixie> unless you have a better idea :-)
  58. # [00:38] * Quits: tndH (n=Rob@cpc2-leed18-0-0-cust427.leed.cable.ntl.com) (Read error: 110 (Connection timed out))
  59. # [00:38] <ap> Hixie: I still think that there needs to be an indication when send() fails
  60. # [00:38] <Hixie> you don't know when send fails
  61. # [00:39] <ap> Hixie: fails to take the data in its queue. sure you know that
  62. # [00:39] <Hixie> "take the data in its queue
  63. # [00:39] <Hixie> "?
  64. # [00:39] <ap> Hixie: here's what TCP guarantees:
  65. # [00:39] <Hixie> if you hit a hardware limitation, then you can do whatever you like
  66. # [00:39] <ap> Hixie: once you call send(), and it returns success
  67. # [00:40] <ap> Hixie: it means that either the data will be delivered to the other side
  68. # [00:40] <ap> Hixie: or no more data will be delivered to the other side over this connection
  69. # [00:40] * Quits: ttepass- (n=ttepas--@p5B016FBE.dip.t-dialin.net) (Read error: 104 (Connection reset by peer))
  70. # [00:40] <Hixie> no, it doesn't, except for some definition of "other side" that is not really practically useful to the author.
  71. # [00:41] <ap> Hixie: huh?
  72. # [00:41] <Hixie> what matters is whether the application level on the other side dealt with the data, and the only way you can know that is an acknowledgement.
  73. # [00:41] <ap> Hixie: I thought I explained it in detail in e-mail :(
  74. # [00:41] <Hixie> you can't know from TCP whether the server on the other side is still alive or has had some sort of crash or is spilling all its data on the floor or whatever.
  75. # [00:42] <ap> Hixie: repeating it again, it means that "either the data will be delivered to the other side, or no more data will be delivered to the other side over this connection"
  76. # [00:42] <Hixie> but that's not interesting information
  77. # [00:42] <ap> Hixie: that may sounds subtle, but it makes all the difference between TCP and UDP
  78. # [00:43] <Hixie> i understand the difference between TCP and UDP :-)
  79. # [00:43] <ap> Hixie: with this guarantee, you can do simple app-level acks
  80. # [00:43] <Hixie> sure
  81. # [00:43] <ap> Hixie: without it, you need much more complicated mechanisms for acks
  82. # [00:43] <Hixie> we already expose "the connection closed"
  83. # [00:44] <Hixie> i don't really see what you are proposing
  84. # [00:44] <ap> Hixie: what I'm saying is that there is absolutely no reason to provide UDP-level reliability when the underlying protocol is TCP
  85. # [00:44] * Joins: arun__ (n=arun@nat/mozilla/x-053b4831cbcc41ae)
  86. # [00:44] <Hixie> ok... we're not doing that
  87. # [00:44] <Hixie> so where's the problem?
  88. # [00:45] <ap> Hixie: that's actually exactly what the spec provides now (well, except that it still guarantees ordering)
  89. # [00:45] <Hixie> how so?
  90. # [00:45] * Quits: svl (n=me@ip565744a7.direct-adsl.nl) ("And back he spurred like a madman, shrieking a curse to the sky.")
  91. # [00:45] <ap> Hixie: if you call send() several times, and you get an ACK for the last, you cannot be sure that all the data arrived to the other side
  92. # [00:45] <Hixie> you can't drop packets in the middle and keep sending them
  93. # [00:46] <Hixie> how not?
  94. # [00:46] * Joins: bradee-oh (n=bradeeoh@66.98.208.42)
  95. # [00:46] <Hixie> if that's so, there's an error in the spec
  96. # [00:46] <Hixie> what text did i screw up?
  97. # [00:46] <ap> Hixie: where does the spec say that once packets are dropped, the connection is closed?
  98. # [00:46] <Hixie> you're not allowed to drop packets at all.
  99. # [00:47] <ap> Hixie: oh, do you mean that the current text suggests filling up RAM until it ends?
  100. # [00:47] <Hixie> the current spec says that when you call send(), you have to send the bytes.
  101. # [00:47] <Hixie> it doesn't say how exactly
  102. # [00:47] <Hixie> they just have to be sent
  103. # [00:47] <Hixie> there's no permission to not send
  104. # [00:48] <Hixie> i can add a line saying "if you can't send, you have to close" if you like
  105. # [00:48] <ap> Hixie: neither sounds like useful behavior
  106. # [00:48] <franksalim> so there is no notion of a send failing
  107. # [00:48] <Hixie> ap: neither what?
  108. # [00:48] <Hixie> franksalim: not currently
  109. # [00:48] <franksalim> if you add a throttling event, there would have to still be a way to indicate that subsequent calls to send failed
  110. # [00:48] <ap> Hixie: neither filling up the RAM or closing at UA's discretion
  111. # [00:49] <Hixie> ap: what would you like the spec to say?
  112. # [00:49] <ap> Hixie: as indicated in the mailing list, I like Jeremy Orlow's proposal
  113. # [00:50] * Quits: taf2_ (n=taf2@38.99.201.242)
  114. # [00:50] <ap> Hixie: an overflow event that is sent at UA's discretions sounds helpful, too
  115. # [00:50] <Hixie> you want send() to throw an exception when the TCP layer failed to successfully send the packet to the other side?
  116. # [00:50] <ap> Hixie: it's just no substitute
  117. # [00:51] <Hixie> that's what he suggested, but as far as i can tell it's impossible to implement, since send() has to be async.
  118. # [00:51] <ap> Hixie: actually not, that's not what he suggested
  119. # [00:51] <Hixie> ok, so what are you and he proposing, since i misunderstood what he suggested?
  120. # [00:52] <ap> Hixie: the suggestion is to raise an event when UA no longer wants to buffer the data in its queue (in practice, the buffer will be quite small, to allow for quick adaptation to network conditions)
  121. # [00:52] <Hixie> (that's definitely not what he suggested, but ok)
  122. # [00:52] <ap> Hixie: raqise an exception, sorry
  123. # [00:53] <Hixie> so you want send() to throw an exception (but leave the connection open) if the buffer is full?
  124. # [00:53] <ap> btw, quoting the suggestion, "Maybe the right behavior is to buffer in user-space (like Maciej explained) up until a limit (left up to the UA) and then anything beyond that results in an exception."
  125. # [00:53] <ap> Hixie: yes
  126. # [00:53] <Hixie> wouldn't that mean send() could arbitrarily and randomly fire exceptions? that seems like a _really_ bad idea
  127. # [00:53] <Hixie> and would effectively give you UDP-like behaviour
  128. # [00:54] <ap> Hixie: I don't agree with either statement (neither that it's bad, nor that it's somehow related to UDP-like behavior)
  129. # [00:54] * Quits: Maurice (i=copyman@5ED548D4.cable.ziggo.nl) ("Disconnected...")
  130. # [00:54] <ap> Hixie: returning a boolean result would be as good as firing an exception in my eyes, btw
  131. # [00:55] * annevk2 doesn't like getAsBinary and getAsBase64
  132. # [00:55] <Hixie> it's bad for the same reason that we are avoiding firing an exception if you call send() on a closed WebSocket
  133. # [00:55] <ap> ok, let it be a boolean return value. there just needs to be a clear indication that the data passed to send() is dropped on the floor
  134. # [00:55] <Hixie> and it's UDP-like because it means that if you are calling send() on a timer at roughly the rate that you can send, then a random subset of the data will be sent, and the rest will be dropped on the floor.
  135. # [00:56] <Hixie> which, as you said earlier, is really bad
  136. # [00:56] <ap> Hixie: to determine the rate that you can send, one needs guidance
  137. # [00:57] <Hixie> sure, so we have the overflow event, which you can use to back off
  138. # [00:57] <ap> Hixie: back off by how much?
  139. # [00:57] <Hixie> (should probably be "willsoonoverflow" or something)
  140. # [00:57] <Hixie> who knows
  141. # [00:57] <Hixie> a boolean won't tell you either
  142. # [00:57] <franksalim> what happens when it actually overflows?
  143. # [00:57] <ap> Hixie: there are well established flow control protocols that work with "the boolean"
  144. # [00:57] <franksalim> exception? binary value?
  145. # [00:57] <Hixie> franksalim: i propose to make the connection close
  146. # [00:58] <ap> Hixie: like, every streaming protocol that works over TCP can adapt when send() fails
  147. # [00:58] <Hixie> ap: yeah, but they're all designed for experts
  148. # [00:58] <Hixie> ap: nobody except the experts are going to be checking for a return value from send(), realistically speaking
  149. # [00:58] <Hixie> ap: (they're also not going to be checking for an event)
  150. # [00:59] <ap> Hixie: with 128K or so buffered in the UA, non-experts will still be able to ignore the complexities, and control their toy trains
  151. # [00:59] <Hixie> i'm happy to make the event provide more information
  152. # [00:59] <ap> Hixie: you're now basically asking experts to come up with new flow control protocols, and non-experts will still not get decent streaming behavior
  153. # [01:00] <annevk2> what's the problem with the UA buffering all calls to send() somehow?
  154. # [01:00] <franksalim> annevk2, i think all of these proposed behaviors involve doing some amount of buffering
  155. # [01:00] <ap> annevk2: the data will never get to the other side if it's sent faster than the network can transmit it
  156. # [01:00] <Hixie> ap: i would be ok with returning a number from send() which is how much more data can be buffered, and then failing the connection when you go over the limit
  157. # [01:00] <franksalim> but they differ in what to do when a buffer fills
  158. # [01:01] * Quits: MikeSmith (n=MikeSmit@71-218-60-163.hlrn.qwest.net) ("Tomorrow to fresh woods, and pastures new.")
  159. # [01:01] <ap> Hixie: that sounds good to me, but it is not implementable
  160. # [01:01] <franksalim> why fail the connection when you could indicate failure of that particular call to send?
  161. # [01:01] <annevk2> ap, the UA can control how fast it is being sent
  162. # [01:01] <Hixie> ap: which is similar to what you're suggesting, except that going over (returning false) is fatal
  163. # [01:01] <Hixie> ap: why not?
  164. # [01:01] * Joins: othermaciej (n=mjs@nat/mozilla/x-d081c3bd43bc2020)
  165. # [01:01] <ap> annevk2: by blocking send() until the queue is free? we agreed to never block
  166. # [01:01] <Hixie> franksalim: because people are going to ignore this data, and we don't want to make this UDP-like
  167. # [01:02] <annevk2> ap, it can queue up in the local RAM
  168. # [01:02] <ap> Hixie: hmm, maybe it can be implemented, let me think
  169. # [01:02] * ap is now known as ap|brb
  170. # [01:02] <Hixie> annevk2: if you're calling send() faster than the network can handle, you'll eventually run out of RAM
  171. # [01:02] <annevk2> ap, and when there's OOM it's just like any other platform implementation
  172. # [01:02] <franksalim> there are many ways for a javascript application to eat arbitrarily large amounts of RAM if the author is careless or malicious
  173. # [01:03] <Hixie> i'm rather with anne on this to be honest
  174. # [01:03] <annevk2> with implementation I meant limitation, sorry
  175. # [01:03] * Quits: tndH_ (n=Rob@cpc2-leed18-0-0-cust427.leed.cable.ntl.com) (Read error: 110 (Connection timed out))
  176. # [01:05] * ap|brb is now known as ap
  177. # [01:05] * Quits: yshin (n=yshin@72.14.227.1)
  178. # [01:05] <ap> annevk2: e.g. if you're sending a video stream from a capture device, there is no good in filling up RAM until OOM
  179. # [01:05] <ap> annevk2: you want to be notified quickly, and to downscale your video
  180. # [01:05] <Hixie> we don't support sending a video stream
  181. # [01:06] <Hixie> if that's the use case, we can fix this in v2
  182. # [01:06] <ap> Hixie: why don't we?
  183. # [01:06] <annevk2> I was just about to say that for specific types of data (e.g. files from the local disk) we should let send() accept dedicated types (e.g. FileData) and let the UA handle the specifics
  184. # [01:06] <ap> Hixie: what about an audio stream?
  185. # [01:06] <annevk2> it just handles text
  186. # [01:06] <Hixie> ap: because we don't have any of the building blocks for that yet
  187. # [01:07] <ap> Hixie: what about data for/from SETI@home?
  188. # [01:07] <Hixie> ap: we don't have binary data, we don't have stream interfaces, we don't have audio or video hardware access
  189. # [01:07] * Joins: weinig_ (n=weinig@17.246.17.74)
  190. # [01:07] <ap> Hixie: or any other programmatically generated data stream?
  191. # [01:07] <Hixie> ap: SETI@home is rate-limited by the server
  192. # [01:08] <Hixie> annevk2: for file upload i'm waiting for arun's draft
  193. # [01:09] <ap> Hixie: the spec says that WebSocket is to app-level protocols what TCP is to internet protocols
  194. # [01:09] <ap> Hixie: if you're targeting TTY instead of TCP, please say so :)
  195. # [01:10] <ap> Hixie: so yes, send() can of course return how much space there's in UA queue at the moment (I was thinking about kernel queue, and this data is usually unavailable)
  196. # [01:10] <ap> Hixie: it feels quite weird to report implementation details in this way though
  197. # [01:11] <annevk2> it should probably be a percentage or something as otherwise you need to figure out UTF-16 vs UTF-8 etc.
  198. # [01:11] <annevk2> if anything at all, that is
  199. # [01:13] <ap> the important thing is to be able to estimate the available bandwidth, and keep the UA queue close to empty after that
  200. # [01:13] <ap> or take 50% of available bandwidth, for example
  201. # [01:14] <Hixie> ok so i got run of onoverflow, and instead just made send() return a number, which is either 0 (connection closed), 1 (buffering not supported), a number indicating the number of bytes that can be buffered, or 4294967295 if the buffering is essentially unlimited.
  202. # [01:14] <Hixie> and overflowing the buffer closes the connection.
  203. # [01:15] <Hixie> got rid of, rather
  204. # [01:16] <franksalim> i'm catching up on the mailing list thread. has the alternative been discussed in which notification occurs when writes are successful? this would allow application code to make use of an arbitrarily large buffer but be aware of the rate at which the buffer is being drained
  205. # [01:16] <ap> Hixie: what is the client to do when 1 is returned?
  206. # [01:16] <Hixie> ap: pray it doesn't hit the network rate limit
  207. # [01:17] <Hixie> ap: i just needed a number that wasn't 0, since 0 means "failed"
  208. # [01:17] <ap> Hixie: ok
  209. # [01:17] <ap> Hixie: I think that's workable, let's see what people have to say about elegance
  210. # [01:18] <Hixie> it's the web, i gave up trying to win any awards for legance long ago :-)
  211. # [01:18] <Hixie> but yeah
  212. # [01:18] <Hixie> for elegance, even
  213. # [01:18] <ap> franksalim: could you explain this in more detail? what's a successful write?
  214. # [01:18] <franksalim> ap, successfully dequeued by the UA
  215. # [01:18] <franksalim> ap, not necessarily acked
  216. # [01:19] * Quits: dbaron (n=dbaron@nat/mozilla/x-f24af2b08b525baf) ("8403864 bytes have been tenured, next gc will be global.")
  217. # [01:19] <ap> franksalim: I see. I don't think it's been suggested
  218. # [01:19] <franksalim> this would make the information available to keep buffers close to empty for "smart" developers, but not close connections forcefully at arbitrary limits
  219. # [01:20] <roc> what was wrong with my idea of allowing apps to query the amount of buffered data?
  220. # [01:20] <Hixie> roc: that's basically what we have now, though in reverse
  221. # [01:20] <franksalim> most (all?) other js APIs can use arbitrarily large amounts of memory
  222. # [01:21] <Hixie> maybe we should also have an attribute for the actual amount pending?
  223. # [01:21] <franksalim> Hixie, roc: except what we have now implies that there has to be a max, right?
  224. # [01:21] <ap> franksalim: I think that a highwater mark notification would still be needed to rate limit
  225. # [01:21] <Hixie> franksalim: no, the UA is allowed to return 4294967295 if the buffering is essentially unlimited
  226. # [01:21] <franksalim> Hixie, but then you don't know how much of the buffer you have used
  227. # [01:21] <Hixie> franksalim: correct
  228. # [01:22] <roc> I think it's a lot more useful to know how much data is queued than how much space is left in the buffer
  229. # [01:22] <franksalim> i think it is desirable to have an unlimited buffer size with the ability to know how large a buffer you are using
  230. # [01:22] <franksalim> roc, i agree
  231. # [01:22] <Hixie> hmm... maybe i should have it return the amount queued, then? or make it return a boolean and have a separate amount-queued attribute?
  232. # [01:22] <ap> franksalim: "other js APIs can use arbitrarily large amounts of memory" - the issue here is not with OOM, but with letting the app achieve its mission. other JS APIs don't usually cause infinite memory growth when doing something useful
  233. # [01:23] <Hixie> roc: what should i call such an attribute?
  234. # [01:23] <franksalim> ap, yes. but setting a max buffer size is not necessary. the important data is how far backed up you are, not how much space you have left
  235. # [01:23] <Hixie> websocket.queueLength?
  236. # [01:23] <roc> bufferedAmount?
  237. # [01:23] <ap> franksalim: agreed
  238. # [01:26] <ap> Hixie: with the boolean returned, will it be for success/failure?
  239. # [01:26] <Hixie> it'll return false if the connection is closed (e.g. because of buffer overflow) and true otherwise
  240. # [01:27] <Hixie> roc: once the connection is closed, should bufferedAmount be reset to zero, or should it continue counting the number of bytes that aren't getting sent?
  241. # [01:27] * Quits: nessy (n=nessy@124-170-2-64.dyn.iinet.net.au) ("This computer has gone to sleep")
  242. # [01:30] * Joins: MikeSmith (n=MikeSmit@71-218-60-163.hlrn.qwest.net)
  243. # [01:32] <Hixie> this attributes makes a lot of sense, it lets you just check to see if it's non-zero, and just not send data while that is true
  244. # [01:33] <ap> Hixie: it will still take a good amount of "isSafari" and "isFirefox" checks for someone to send a 128K blob of data
  245. # [01:33] <Hixie> why?
  246. # [01:34] <ap> Hixie: maybe I'm just not seeing how it can be done. what would you suggest?
  247. # [01:34] * Quits: jacobolus (n=jacobolu@c-98-248-43-68.hsd1.ca.comcast.net) (Remote closed the connection)
  248. # [01:35] <ap> for a browser that can buffer such amount, the best way is to send in one chunk
  249. # [01:35] <roc> Hixie: I'd say bufferedAmount should keep increasing, if you keep allowing send()s
  250. # [01:35] * Joins: jacobolus (n=jacobolu@c-98-248-43-68.hsd1.ca.comcast.net)
  251. # [01:35] <ap> for one that cannot - how large can bufferedAmount become before the app should freak out?
  252. # [01:36] <Hixie> roc: k, done that
  253. # [01:36] <Hixie> ap: if you're sending a 128KB frame, then it's one send() call.
  254. # [01:36] <roc> ap: I think this is just like any other memory issue
  255. # [01:37] <Hixie> ap: so there's nothing to check
  256. # [01:37] <ap> roc: if I understand what you're saying right, the model is that buffer will be unlimited (or huge) for this API to work
  257. # [01:37] <roc> right
  258. # [01:37] <roc> which is like all the other buffers Web apps deal with today
  259. # [01:37] <ap> roc: makes sense
  260. # [01:38] <roc> I think in practice if you carve your data into 1MB chunks you should be in good shape for any scenario
  261. # [01:38] <ap> other than dial-up :)
  262. # [01:38] <roc> then you're just doomed :-)
  263. # [01:41] * Quits: dglazkov (n=dglazkov@nat/google/x-07f258b93dff667f)
  264. # [01:48] * Quits: Rik` (n=Rik`@pha75-2-81-57-187-57.fbx.proxad.net) (Read error: 113 (No route to host))
  265. # [01:50] * Joins: sbublava (n=stephan@77.119.89.221.wireless.dyn.drei.com)
  266. # [01:52] * Quits: heycam (n=cam@124-168-112-102.dyn.iinet.net.au) ("bye")
  267. # [01:55] * Quits: othermaciej (n=mjs@nat/mozilla/x-d081c3bd43bc2020)
  268. # [01:57] * Quits: ray (i=ray@drong.notacat.org) ("Reconnecting")
  269. # [01:57] * Joins: ray_ (i=ray@drong.notacat.org)
  270. # [01:58] * Quits: ap (n=ap@nat/apple/x-276f0fb92824779e)
  271. # [01:58] * ray_ is now known as ray
  272. # [02:07] * Quits: weinig (n=weinig@nat/apple/x-db2343e4d9ab5b02)
  273. # [02:08] * Quits: weinig_ (n=weinig@17.246.17.74)
  274. # [02:09] * Quits: arun__ (n=arun@nat/mozilla/x-053b4831cbcc41ae)
  275. # [02:11] * Joins: rogan_ (n=chatzill@c-75-65-199-138.hsd1.tn.comcast.net)
  276. # [02:12] * rogan_ is now known as Tripler
  277. # [02:13] <Tripler> Can anyone point me in the direction of a tutorial for the <video> tag and how to style etc
  278. # [02:20] * Joins: arun__ (n=arun@nat/mozilla/x-d587b6e5c6892b8d)
  279. # [02:21] * Joins: sbublava_ (n=stephan@77.116.33.92.wireless.dyn.drei.com)
  280. # [02:24] * Joins: auk (n=scott@cpe-75-83-19-98.socal.res.rr.com)
  281. # [02:25] * Quits: sicking (n=chatzill@nat/mozilla/x-eb3bcaf9cc16d84d) (Remote closed the connection)
  282. # [02:30] * Quits: hallvors (n=hallvord@pat-tdc.opera.com) (Read error: 110 (Connection timed out))
  283. # [02:32] * Quits: Tripler (n=chatzill@c-75-65-199-138.hsd1.tn.comcast.net) ("ChatZilla 0.9.84 [Firefox-3.5 3.5.1pre/20090704164426]")
  284. # [02:35] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  285. # [02:37] * Joins: taf2_ (n=taf2@98.218.77.43)
  286. # [02:42] * Quits: sbublava (n=stephan@77.119.89.221.wireless.dyn.drei.com) (Read error: 110 (Connection timed out))
  287. # [02:43] * Joins: heycam (n=cam@clm-laptop.infotech.monash.edu.au)
  288. # [02:44] * Joins: slightlyoff_ (n=slightly@72.14.229.81)
  289. # [02:46] * Quits: virtuelv (n=virtuelv@201.169.34.95.customer.cdi.no) ("Ex-Chat")
  290. # [02:48] * Quits: Amorphous (i=jan@unaffiliated/amorphous) (Read error: 110 (Connection timed out))
  291. # [02:50] * Quits: slightlyoff (n=slightly@72.14.229.81) (Read error: 110 (Connection timed out))
  292. # [02:51] * Quits: sbublava_ (n=stephan@77.116.33.92.wireless.dyn.drei.com)
  293. # [02:54] * Quits: aroben (n=aroben@unaffiliated/aroben) (Read error: 104 (Connection reset by peer))
  294. # [02:55] * Joins: Amorphous (i=jan@unaffiliated/amorphous)
  295. # [03:17] * Quits: jwalden (n=waldo@nat/mozilla/x-e03a267d35541a61) ("dinner")
  296. # [03:19] * Quits: ZombieLoffe (n=e@unaffiliated/zombieloffe)
  297. # [03:27] * Quits: slightlyoff_ (n=slightly@72.14.229.81)
  298. # [03:28] * Joins: slightlyoff (n=slightly@72.14.229.81)
  299. # [03:29] * Quits: arun__ (n=arun@nat/mozilla/x-d587b6e5c6892b8d)
  300. # [03:31] * Quits: cying (n=cying@70.90.171.153)
  301. # [03:45] * Joins: shepazu (n=schepers@adsl-221-113-51.rmo.bellsouth.net)
  302. # [03:46] * Joins: tantek (n=tantek@32.159.4.72)
  303. # [03:48] * Quits: jennb (n=jennb@72.14.227.1)
  304. # [04:05] * Joins: othermaciej (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net)
  305. # [04:08] * Joins: nessy (n=nessy@124-170-2-64.dyn.iinet.net.au)
  306. # [04:12] * Joins: onar_ (n=onar@c-67-180-87-66.hsd1.ca.comcast.net)
  307. # [04:12] * Joins: tantekc (n=tantek@32.159.145.252)
  308. # [04:13] * Quits: othermaciej (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net)
  309. # [04:24] * Quits: jacobolus (n=jacobolu@c-98-248-43-68.hsd1.ca.comcast.net) (Remote closed the connection)
  310. # [04:25] * Quits: taf2_ (n=taf2@98.218.77.43)
  311. # [04:28] * Joins: tantekc_ (n=tantek@32.158.117.205)
  312. # [04:29] * Joins: cying (n=cying@adsl-75-41-114-136.dsl.pltn13.sbcglobal.net)
  313. # [04:30] * Joins: gavin___ (n=gavin@CPE001346f5db49-CM0018c0db9a8a.cpe.net.cable.rogers.com)
  314. # [04:33] * Quits: dave_levin (n=dave_lev@72.14.227.1)
  315. # [04:36] * Quits: tantek (n=tantek@32.159.4.72) (Read error: 110 (Connection timed out))
  316. # [04:38] * Joins: erikvvold (n=erikvvol@96.49.192.204)
  317. # [04:39] * Quits: erikvvold (n=erikvvol@96.49.192.204) (Client Quit)
  318. # [04:39] * Joins: erikvvold (n=erikvvol@96.49.192.204)
  319. # [04:40] * Quits: onar_ (n=onar@c-67-180-87-66.hsd1.ca.comcast.net)
  320. # [04:42] * gavin___ is now known as gavin
  321. # [04:45] * Quits: tantekc (n=tantek@32.159.145.252) (Read error: 110 (Connection timed out))
  322. # [04:46] * Quits: jorlow (n=jorlow@nat/google/x-c532996def1d9173) (Read error: 60 (Operation timed out))
  323. # [04:47] * Joins: weinig (n=weinig@c-67-180-35-124.hsd1.ca.comcast.net)
  324. # [05:06] * Joins: roc_ (n=roc@203-97-204-82.dsl.clear.net.nz)
  325. # [05:07] * Quits: tantekc_ (n=tantek@32.158.117.205) (Read error: 110 (Connection timed out))
  326. # [05:09] * Joins: dave_levin (n=dave_lev@c-98-203-247-78.hsd1.wa.comcast.net)
  327. # [05:20] * Quits: dolske (n=dolske@nat/mozilla/x-1d69742812ed7ba6)
  328. # [05:21] * Quits: MikeSmith (n=MikeSmit@71-218-60-163.hlrn.qwest.net) (clarke.freenode.net irc.freenode.net)
  329. # [05:21] * Quits: othree (n=othree@admin39.ct.ntust.edu.tw) (clarke.freenode.net irc.freenode.net)
  330. # [05:21] * Joins: roc__ (n=roc@203-97-204-82.dsl.clear.net.nz)
  331. # [05:25] * Quits: roc_ (n=roc@203-97-204-82.dsl.clear.net.nz) (Read error: 110 (Connection timed out))
  332. # [05:25] * Joins: dglazkov (n=dglazkov@c-67-188-0-62.hsd1.ca.comcast.net)
  333. # [05:25] * Joins: onar_ (n=onar@c-67-180-87-66.hsd1.ca.comcast.net)
  334. # [05:27] * Joins: othree (n=othree@admin39.ct.ntust.edu.tw)
  335. # [05:28] * Quits: roc (n=roc@203-97-204-82.dsl.clear.net.nz) (Read error: 110 (Connection timed out))
  336. # [05:34] * Joins: roc (n=roc@203-97-204-82.dsl.clear.net.nz)
  337. # [05:34] * Joins: othermaciej (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net)
  338. # [05:35] * Joins: weinig_ (n=weinig@c-67-180-35-124.hsd1.ca.comcast.net)
  339. # [05:43] * Quits: gsnedders (n=gsnedder@c83-252-204-130.bredband.comhem.se) (Read error: 113 (No route to host))
  340. # [05:43] * Joins: archtech (n=stanv@83.228.56.37)
  341. # [05:50] * Quits: weinig (n=weinig@c-67-180-35-124.hsd1.ca.comcast.net) (Read error: 113 (No route to host))
  342. # [05:53] * Quits: roc__ (n=roc@203-97-204-82.dsl.clear.net.nz) (Read error: 110 (Connection timed out))
  343. # [06:16] * Joins: dolske (n=dolske@c-76-103-40-203.hsd1.ca.comcast.net)
  344. # [06:19] * Joins: dave_levin_ (n=dave_lev@72.14.224.1)
  345. # [06:21] * Quits: dglazkov (n=dglazkov@c-67-188-0-62.hsd1.ca.comcast.net)
  346. # [06:37] * Quits: dave_levin (n=dave_lev@c-98-203-247-78.hsd1.wa.comcast.net) (Read error: 110 (Connection timed out))
  347. # [06:37] * dave_levin_ is now known as dave_levin
  348. # [06:45] * Joins: jwalden (n=waldo@c-98-248-40-206.hsd1.ca.comcast.net)
  349. # [06:49] * Quits: shepazu (n=schepers@adsl-221-113-51.rmo.bellsouth.net) ("Core Breach")
  350. # [06:50] * Quits: othermaciej (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net)
  351. # [06:51] * Joins: othermaciej (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net)
  352. # [06:55] * Joins: shepazu (n=schepers@adsl-221-113-51.rmo.bellsouth.net)
  353. # [07:04] * Quits: slightlyoff (n=slightly@72.14.229.81) (Read error: 110 (Connection timed out))
  354. # [07:33] * Joins: gsnedders (n=gsnedder@c83-252-204-130.bredband.comhem.se)
  355. # [07:33] * Joins: erikvold (n=erikvvol@GANDALF.VKISTUDIOS.NET)
  356. # [07:42] * Quits: roc (n=roc@203-97-204-82.dsl.clear.net.nz)
  357. # [07:48] * Quits: heycam (n=cam@clm-laptop.infotech.monash.edu.au) (Read error: 104 (Connection reset by peer))
  358. # [07:50] * Quits: erikvvold (n=erikvvol@96.49.192.204) (Read error: 110 (Connection timed out))
  359. # [07:50] * Joins: erikvvold (n=erikvvol@96.49.192.204)
  360. # [07:50] * Joins: shikiesos (n=shiki@220.109.219.244)
  361. # [07:51] * Joins: maikmerten (n=merten@ls5dhcp196.cs.uni-dortmund.de)
  362. # [07:54] * Quits: erikvold (n=erikvvol@GANDALF.VKISTUDIOS.NET) (Read error: 110 (Connection timed out))
  363. # [08:00] * Joins: pesla (n=retep@procurios.xs4all.nl)
  364. # [08:08] * Quits: auk (n=scott@cpe-75-83-19-98.socal.res.rr.com) (Read error: 110 (Connection timed out))
  365. # [08:10] * Joins: abii (n=macbook@cm27.delta30.maxonline.com.sg)
  366. # [08:53] * Quits: dave_levin (n=dave_lev@72.14.224.1)
  367. # [09:01] * Parts: Mrmil (n=ut_ollie@host-77-236-204-8.blue4.cz)
  368. # [09:06] * Joins: Mrmil (n=ut_ollie@host-77-236-204-8.blue4.cz)
  369. # [09:11] * Joins: dave_levin (n=dave_lev@72.14.227.1)
  370. # [09:18] * Quits: weinig_ (n=weinig@c-67-180-35-124.hsd1.ca.comcast.net)
  371. # [09:25] * Joins: KevinMarks (n=Snak@c-67-164-14-96.hsd1.ca.comcast.net)
  372. # [09:28] * Quits: onar_ (n=onar@c-67-180-87-66.hsd1.ca.comcast.net)
  373. # [09:30] * Joins: tndH (n=Rob@cpc2-leed18-0-0-cust427.leed.cable.ntl.com)
  374. # [09:32] * Joins: Rik` (n=Rik`@pha75-2-81-57-187-57.fbx.proxad.net)
  375. # [09:33] * Quits: gsnedders (n=gsnedder@c83-252-204-130.bredband.comhem.se)
  376. # [09:50] * Joins: MikeSmith (n=MikeSmit@71-218-60-163.hlrn.qwest.net)
  377. # [09:56] * Joins: zcorpan (n=zcorpan@c83-252-201-53.bredband.comhem.se)
  378. # [10:08] * Quits: Rik` (n=Rik`@pha75-2-81-57-187-57.fbx.proxad.net) (Read error: 113 (No route to host))
  379. # [10:08] * Joins: Rik`_ (n=Rik`@pha75-2-81-57-187-57.fbx.proxad.net)
  380. # [10:09] * Rik`_ is now known as Rik`
  381. # [10:15] <Philip`> "return the result of subtracting value from zero" - hmm, sounds like COBOL
  382. # [10:17] <annevk4> "the Hixie fork of the HTML5 specification" classic
  383. # [10:19] <othermaciej> annevk4: Hixie was just tired of Hixie's unsound, dictatorial decisions
  384. # [10:19] <othermaciej> annevk4: so he had to fork Hixie's original spec and make his own
  385. # [10:25] <annevk4> zcorpan, really? you want a section on SGML differences?
  386. # [10:25] <annevk4> zcorpan, nobody cares
  387. # [10:25] * Joins: Maurice (i=copyman@5ED548D4.cable.ziggo.nl)
  388. # [10:26] <annevk4> fortunately both objections placed so far are against process and I don't think they carry any weight
  389. # [10:26] <annevk4> well, "fortunately" I personally don't really care that much about publishing either way I think
  390. # [10:31] <othermaciej> I don't think Working Drafts are all that important, but I do get annoyed at every little thing being turned into a political fight
  391. # [10:31] <othermaciej> in particular, the Editor's Draft being mch changed from the Working Draft was used for political point scoring
  392. # [10:31] <othermaciej> and now the process of updating it is being turned into a political fight
  393. # [10:32] <zcorpan> annevk2: i was more thinking of extending the paragraph with more examples
  394. # [10:32] <zcorpan> "... such as NET syntax, marked sections and processing instructions"
  395. # [10:33] <annevk4> marked sections?
  396. # [10:33] <annevk4> I suppose I could add something like that
  397. # [10:33] <zcorpan> <![INCLUDE[ ]]>, <![CDATA[ ]]>
  398. # [10:34] <annevk4> well, <![CDATA[ ]]> is still there somewhat
  399. # [10:34] <zcorpan> true
  400. # [10:34] <zcorpan> maybe don't mention marked sections
  401. # [10:36] * Joins: jacobolus (n=jacobolu@adsl-75-36-158-29.dsl.pltn13.sbcglobal.net)
  402. # [10:40] * Joins: roc (n=roc@121-72-217-254.dsl.telstraclear.net)
  403. # [10:51] * Joins: Phae (n=phaeness@gateb.mh.bbc.co.uk)
  404. # [10:52] * Joins: mat_t (n=mattomas@nat/canonical/session)
  405. # [10:57] <annevk4> joy, co-author of URI and IRI specs wonders whether www.%77%33.org vs www.w3.org is a problem
  406. # [11:00] * Quits: pesla (n=retep@procurios.xs4all.nl) ("( www.nnscript.com :: NoNameScript 4.21 :: www.esnation.com )")
  407. # [11:02] * Quits: Rik` (n=Rik`@pha75-2-81-57-187-57.fbx.proxad.net)
  408. # [11:06] * Joins: pesla (n=retep@procurios.xs4all.nl)
  409. # [11:13] * Quits: MikeSmith (n=MikeSmit@71-218-60-163.hlrn.qwest.net) (Read error: 60 (Operation timed out))
  410. # [11:19] * Joins: MikeSmith (n=MikeSmit@71-218-60-163.hlrn.qwest.net)
  411. # [11:20] * Quits: KevinMarks (n=Snak@c-67-164-14-96.hsd1.ca.comcast.net) ("bye")
  412. # [11:31] * Parts: annevk2 (n=annevk@5355732C.cable.casema.nl)
  413. # [11:41] * Parts: zcorpan (n=zcorpan@c83-252-201-53.bredband.comhem.se)
  414. # [11:43] * Joins: Chris_Wilson (n=cwilso@nat/microsoft/session)
  415. # [11:46] * Joins: ROBOd (n=robod@89.122.216.38)
  416. # [11:52] * Quits: ChrisWilson (n=cwilso@nat/microsoft/x-207d1d3c4bb7f05d) (Read error: 110 (Connection timed out))
  417. # [11:57] * Joins: ZombieLoffe (n=e@unaffiliated/zombieloffe)
  418. # [12:13] * Quits: tkent (n=tkent@220.109.219.244) ("Leaving...")
  419. # [12:15] * Joins: adactio (n=adactio@host86-132-125-223.range86-132.btcentralplus.com)
  420. # [12:16] * Quits: dave_levin (n=dave_lev@72.14.227.1)
  421. # [12:17] * Quits: Lachy (n=Lachlan@85.196.122.246) ("This computer has gone to sleep")
  422. # [12:18] * Joins: gsnedders (n=gsnedder@pat.se.opera.com)
  423. # [12:18] * annevk4 is now known as annevk
  424. # [12:19] * Quits: gavin (n=gavin@firefox/developer/gavin) (Read error: 113 (No route to host))
  425. # [12:19] * annevk is now known as anne
  426. # [12:20] <gsnedders> Hixie: yt?
  427. # [12:21] * anne is now known as annevk
  428. # [12:21] * Joins: myakura (n=myakura@p1215-ipbf412marunouchi.tokyo.ocn.ne.jp)
  429. # [12:29] * Joins: Lachy (n=Lachlan@pat-tdc.opera.com)
  430. # [12:32] * Joins: svl (n=me@ip565744a7.direct-adsl.nl)
  431. # [12:32] * Joins: tkent (n=tkent@220.109.219.244)
  432. # [12:38] * Joins: Creap (n=Creap@vemod.brg.sgsnet.se)
  433. # [12:39] * Joins: olliej (n=oliver@c-67-164-125-23.hsd1.ca.comcast.net)
  434. # [12:40] <gsnedders> Hixie: Ignore that
  435. # [13:23] <gsnedders> Why would html5lib.HTMLParser().parseFragment(StringIO("<p>foo")) return None
  436. # [13:25] * Joins: virtuelv (n=virtuelv@201.169.34.95.customer.cdi.no)
  437. # [13:36] * Joins: heycam (n=cam@124-168-112-102.dyn.iinet.net.au)
  438. # [13:53] * Quits: virtuelv (n=virtuelv@201.169.34.95.customer.cdi.no) ("Ex-Chat")
  439. # [13:53] * Joins: gunderwonder (n=gunderwo@garage.upstruct.com)
  440. # [13:59] * Joins: ttepasse (n=ttepas--@p5B01334B.dip.t-dialin.net)
  441. # [14:04] * Joins: ttepass- (n=ttepas--@p5B014F9A.dip.t-dialin.net)
  442. # [14:18] <Lachy> Philip`, do you have, or could you obtain, any data comparing how common it is for authors to include = within unquoted attribute values, compared with those that write attributes like alt= with no value?
  443. # [14:18] <Lachy> I'm trying to show why Hixie choice is wrong here http://lists.w3.org/Archives/Public/public-html/2009Jul/0817.html
  444. # [14:25] * Quits: ttepasse (n=ttepas--@p5B01334B.dip.t-dialin.net) (Read error: 110 (Connection timed out))
  445. # [14:25] * Joins: ttepasse (n=ttepas--@p5B0142B4.dip.t-dialin.net)
  446. # [14:31] <Dashiva> What's the reason a= and a=b=c can't both be valid? I can't remember. Is it stuff like a=b c?
  447. # [14:33] <Lachy> Dashiva, Hixie claims it's because of situations like <img alt= class=photo> where "class=photo" would be interpreted as the value of the alt attribute
  448. # [14:35] <Dashiva> If the space between them was left out, you mean?
  449. # [14:35] <Lachy> no, with the space
  450. # [14:35] * Quits: ttepass- (n=ttepas--@p5B014F9A.dip.t-dialin.net) (Read error: 110 (Connection timed out))
  451. # [14:35] <Lachy> perhaps the better solution is to make whitespace before unqutoed attribute values invalid
  452. # [14:36] <Dashiva> Oh. So there's probably content that depends on a= b being parsed as a="b" then
  453. # [14:36] <Lachy> so <img class= photo> would be invalid, but <img class= "photo" could still be valid
  454. # [14:36] <Lachy> yes
  455. # [14:41] * Quits: olliej (n=oliver@c-67-164-125-23.hsd1.ca.comcast.net)
  456. # [14:46] <Philip`> Lachy: How would those two cases be distinguished? <img alt = class=photo> seems like it could be either, and would require human interpretation
  457. # [14:47] <Philip`> Lachy: But anyway I don't have data like that, and don't think I can easily obtain it, since it probably involves hacking the tokeniser
  458. # [14:50] <Lachy> Philip`, you could use a rough technique by looking for obvious cases like the href attribute where = in values is common <a href= ?foo-bar>, and also look for [^=]+=\s+([A-Za-z]+)= where $1 matches known attribute names
  459. # [14:50] <Lachy> s/foo-bar/foo=bar/
  460. # [14:51] <Lachy> actually, just the regex would be more like [A-Za-z]+=\s+([A-Za-z]+)=
  461. # [14:52] <Lachy> or [A-Za-z]+\s?=\s+([A-Za-z]+)=
  462. # [14:56] <gsnedders> Philip`: Can you fix html5lib so test cases can run with more recent SimpleJSON which throws on "output":["ParseError", ["Character", "\uD869"], "ParseError", ["Character", "\uDED6"]]}?
  463. # [14:58] * Joins: remysharp (n=remyshar@212.42.4.242)
  464. # [14:58] * Quits: remysharp (n=remyshar@212.42.4.242) (Client Quit)
  465. # [14:58] * Joins: remysharp (n=remyshar@212.42.4.242)
  466. # [15:00] * Quits: remysharp (n=remyshar@212.42.4.242) (Client Quit)
  467. # [15:05] * Joins: rubys (n=rubys@78.sub-70-214-83.myvzw.com)
  468. # [15:06] * Joins: pmuellr (n=pmuellr@nat/ibm/x-pkszdmkobzzwpgzv)
  469. # [15:10] * Joins: taf2_ (n=taf2@38.99.201.242)
  470. # [15:16] * Parts: rubys (n=rubys@78.sub-70-214-83.myvzw.com)
  471. # [15:21] * Joins: aroben (n=aroben@unaffiliated/aroben)
  472. # [15:21] * Quits: nessy (n=nessy@124-170-2-64.dyn.iinet.net.au) ("This computer has gone to sleep")
  473. # [15:21] * Joins: webben (n=benh@nat/yahoo/x-unamrlvqzuwwtqbm)
  474. # [15:23] <Philip`> Lachy: Hmm, that sounds kind of vague :-p
  475. # [15:24] <Philip`> If you have a single specific Java-compatible regexp, I can run it and give a list of the matching lines or of matching substrings
  476. # [15:24] <Philip`> and then I wouldn't have to actively think about it, which would be good
  477. # [15:24] <Philip`> gsnedders: Why me? :-(
  478. # [15:24] <Philip`> gsnedders: Also: How could it be fixed?
  479. # [15:24] <Lachy> ok, I'll have to find out what a java compatible regex is, and how it differs from the one I gave you
  480. # [15:25] <gsnedders> Philip`: Because your around, and might have an idea of how to fix it.
  481. # [15:25] <Philip`> Lachy: It's basically a Perl-compatible regexp
  482. # [15:25] <Lachy> is the one I gave you perl compatible?
  483. # [15:25] <Philip`> so the one you said should be fine
  484. # [15:25] <Lachy> except for the mistake in it
  485. # [15:25] <Philip`> but you'd need to include the list of common attribute values if that's what you want
  486. # [15:25] <Philip`> Uh, names
  487. # [15:25] * Quits: webben (n=benh@nat/yahoo/x-unamrlvqzuwwtqbm) (Client Quit)
  488. # [15:26] * Joins: webben (n=benh@nat/yahoo/x-ewubnocjnzrbjwsg)
  489. # [15:26] <Lachy> corrected version: [A-Za-z]+\s*=\s+([A-Za-z]+)=
  490. # [15:27] <Philip`> gsnedders: Hmm, what test case can cause the expected output to have unpaired surrogate codepoints?
  491. # [15:27] <Lachy> do you mean like: [A-Za-z]+\s*=\s+(class|href|src|...)=
  492. # [15:27] <Philip`> Lachy: Yes
  493. # [15:27] <Lachy> ok
  494. # [15:27] <Philip`> Lachy: if you want to restrict it to that
  495. # [15:27] <gsnedders> Philip`: A tokenizer one with input like that
  496. # [15:27] <Philip`> Lachy: (Also you might want to prefix with (?i) to make it case-insensitive)
  497. # [15:27] <gsnedders> Philip`: From your script, I think
  498. # [15:27] <Philip`> gsnedders: Yes, but I'm too lazy to look it up myself :-p
  499. # [15:28] * Quits: karlcow (n=karl@nerval.la-grange.net) ("O public road, I say back I am not afraid to leave you, yet I love you, you express me better than I can express myself.")
  500. # [15:28] * Joins: karlcow (n=karl@nerval.la-grange.net)
  501. # [15:29] <Lachy> ok, I'll think about it more and get back to you
  502. # [15:32] * Philip` ought to set up a web service so people can run their own regexps over the page data
  503. # [15:32] <Philip`> (but that sounds like too much effort now)
  504. # [15:35] <Lachy> how much processing time does it take to run a typical regex over the data?
  505. # [15:37] <Philip`> Um... A while
  506. # [15:38] <Lachy> like a few hours?
  507. # [15:38] <Philip`> (so a web service would have to be restricted to a subset of the data most of the time)
  508. # [15:38] <Philip`> More like a few minutes
  509. # [15:38] <Philip`> (for the 425K pages)
  510. # [15:38] <Philip`> where "few" might be "ten" or something but I can't really remember now
  511. # [15:38] <gsnedders> yay! An IndexError from html5lib. What I always wanted.
  512. # [15:38] <Philip`> and also it depends on the complexity of the regexp
  513. # [15:38] <Lachy> ok. Still, it would be a DOS risk
  514. # [15:39] * Lachy would abuse the system by trying to run hundreds of simultaneous queries for the same thing :-)
  515. # [15:39] <Philip`> It's fast enough that I haven't bothered writing the code to parallelise it, in any case
  516. # [15:40] <Philip`> There's also the issue that the university wouldn't be particularly happy about running web servers on their machines, for security
  517. # [15:41] <gsnedders> fragment parsing isn't well tested in html5lib seemingly
  518. # [15:44] * Quits: jacobolus (n=jacobolu@adsl-75-36-158-29.dsl.pltn13.sbcglobal.net) (Remote closed the connection)
  519. # [15:45] <annevk> gsnedders, yeah, it wasn't well implemented either iirc
  520. # [15:45] <annevk> at least not initially
  521. # [15:46] * gsnedders has so far hit one exception and one infinite loop
  522. # [15:52] <gsnedders> Oh, wait.
  523. # [15:52] <gsnedders> This infinite loop isn't an html5lib bug. We follow the spec. The spec has an infinite loop.
  524. # [15:53] <gsnedders> I guess this is where we're allowed implementation specific limitations, due to hardware constraints.
  525. # [15:53] <annevk> the spec has an infinite loop?
  526. # [15:53] <annevk> and validator.nu does not?
  527. # [15:55] <gsnedders> annevk: validator.nu doesn't implement innerHTML, does it?
  528. # [15:59] <annevk> I thought it did
  529. # [16:07] <annevk> yeah, that's loop indeed
  530. # [16:07] <Philip`> gsnedders: Any self-respecting Turing-complete machine should be happy to run infinite loops without exceeding hardware constraints
  531. # [16:08] <gsnedders> True, but they never complete executing, which annoys me.
  532. # [16:08] <Philip`> The desire to not wait infinitely long for a web page to render is a user constraint, not a hardware constraint
  533. # [16:08] <Philip`> and we should consider other solutions to that problem, such as making users immortal
  534. # [16:08] * Joins: jacobolus (n=jacobolu@c-76-102-55-224.hsd1.ca.comcast.net)
  535. # [16:11] <gsnedders> Philip`: Do you know of anyone who will implement that?
  536. # [16:11] * Parts: Mrmil (n=ut_ollie@host-77-236-204-8.blue4.cz)
  537. # [16:12] <Philip`> gsnedders: No, but I can think of a number of ways to test it
  538. # [16:15] * Joins: dglazkov (n=dglazkov@c-67-188-0-62.hsd1.ca.comcast.net)
  539. # [16:16] * Joins: Mrmil (n=ut_ollie@host-77-236-204-8.blue4.cz)
  540. # [16:16] <gsnedders> Can anyone see a better fix for the middle change in http://code.google.com/p/html5lib/source/detail?r=21ce65db1e551ef8e7c4e91db0295caab08a4f62#
  541. # [16:23] <Philip`> gsnedders: for e in reversed(self.tree.openElements): if e.name == 'table': return e; (newline) return self.tree.openElements[0]
  542. # [16:23] <Philip`> perhaps?
  543. # [16:24] <Philip`> (except not using reversed if we want Python 2.3 compatibility)
  544. # [16:25] <Philip`> The code you checked in looks disgusting :-p
  545. # [16:28] * Joins: weinig (n=weinig@c-67-180-35-124.hsd1.ca.comcast.net)
  546. # [16:40] * Joins: dave_levin (n=dave_lev@72.14.227.1)
  547. # [16:42] <gsnedders> Philip`: Agreed, but I was going it off the top of my head :P
  548. # [16:42] <Philip`> "This is such an extreme edge case that I'm surprised this discussion has received 34 (now 35) replies." - someone should teach him about bikesheds until it no longer surprises him
  549. # [16:43] <Philip`> gsnedders: I think it's best if you use the insides of your head instead :-p
  550. # [16:43] <gsnedders> Philip`: Where is this?
  551. # [16:45] <Philip`> gsnedders: Between your shoulders and your hair
  552. # [16:46] <gsnedders> Philip`: No, the quote
  553. # [16:47] <Philip`> gsnedders: Oh, on the PHP/SGML discussion
  554. # [16:48] <ezyang> Does HTML5 do anything special to &image inside URLs?
  555. # [16:49] <gsnedders> ezyang: no
  556. # [16:49] <ezyang> hmm, ok
  557. # [16:49] * Quits: dglazkov (n=dglazkov@c-67-188-0-62.hsd1.ca.comcast.net)
  558. # [16:51] <Philip`> &image; is special, though
  559. # [16:54] <ezyang> oh, wow, so browsers will interpret &image= as the actual character entity. News to me.
  560. # [16:54] <Philip`> No, only &image;=
  561. # [16:55] <Philip`> (Well, or &image;foo or whatever)
  562. # [16:55] <ezyang> Wait, really?
  563. # [16:56] <ezyang> If the character reference is being consumed as part of an attribute, and the last character matched is not a U+003B SEMICOLON (;), and the next character is in the range U+0030 DIGIT ZERO to U+0039 DIGIT NINE, U+0041 LATIN CAPITAL LETTER A to U+005A LATIN CAPITAL LETTER Z, or U+0061 LATIN SMALL LETTER A to U+007A LATIN SMALL LETTER Z, then, for historical reasons, all the characters that were matched after the U+0026 AMPERSAND (&) must be unconsumed,
  564. # [16:56] <Philip`> Only the ones explicitly listed (in the giant table in HTML5) without a semicolon will be parsed if they don't have a semicolon
  565. # [16:56] <ezyang> aha!
  566. # [16:56] <Philip`> and then only in cases where they're not followed by 0-9a-z
  567. # [16:57] <Philip`> so &amp=foo is an entity, &ampx=foo isn't, &image=foo isn't, &image;=foo is
  568. # [16:57] <Philip`> (if I remember correctly)
  569. # [16:57] <Philip`> (in attribute values)
  570. # [16:59] * Quits: maikmerten (n=merten@ls5dhcp196.cs.uni-dortmund.de) (Remote closed the connection)
  571. # [17:00] * Quits: Lachy (n=Lachlan@pat-tdc.opera.com) ("This computer has gone to sleep")
  572. # [17:10] * Joins: Lachy (n=Lachlan@85.196.122.246)
  573. # [17:11] * Joins: dbaron (n=dbaron@nat/mozilla/x-beiwukujkzzywuts)
  574. # [17:18] * Joins: riven` (n=colin@53525B67.cable.casema.nl)
  575. # [17:25] * Quits: weinig (n=weinig@c-67-180-35-124.hsd1.ca.comcast.net)
  576. # [17:25] <dbaron> othermaciej, We've had conference room names for less than 24 hours and you already know that they're good?
  577. # [17:26] * Joins: dglazkov (n=dglazkov@nat/google/session)
  578. # [17:27] * Quits: dave_levin (n=dave_lev@72.14.227.1)
  579. # [17:30] * Joins: mengelhardt (n=chatzill@pD9E070C4.dip.t-dialin.net)
  580. # [17:31] <mengelhardt> Hello
  581. # [17:35] * Quits: riven (n=colin@pdpc/supporter/professional/riven) (Read error: 110 (Connection timed out))
  582. # [17:41] * Quits: pesla (n=retep@procurios.xs4all.nl) ("( www.nnscript.com :: NoNameScript 4.21 :: www.esnation.com )")
  583. # [17:42] * Joins: dave_levin (n=dave_lev@72.14.227.1)
  584. # [17:59] * Quits: webben (n=benh@nat/yahoo/x-ewubnocjnzrbjwsg) ("Lost terminal")
  585. # [18:04] * Joins: sgalineau (n=sylvaing@nat/microsoft/x-mslmszuoqcncrqtt)
  586. # [18:07] * Joins: weinig (n=weinig@c-67-180-35-124.hsd1.ca.comcast.net)
  587. # [18:10] * Joins: annevk2 (n=annevk@5355732C.cable.casema.nl)
  588. # [18:16] * Quits: weinig (n=weinig@c-67-180-35-124.hsd1.ca.comcast.net) (Read error: 60 (Operation timed out))
  589. # [18:18] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  590. # [18:24] * Parts: Mrmil (n=ut_ollie@host-77-236-204-8.blue4.cz)
  591. # [18:33] * Joins: Mrmil (n=ut_ollie@host-77-236-204-8.blue4.cz)
  592. # [18:33] <jacobolus> Hixie: I remember you data-mined a big corpus of pages to figure out common class/id names. Has anyone done similar for frequency of font names used in css?
  593. # [18:33] * Parts: Mrmil (n=ut_ollie@host-77-236-204-8.blue4.cz)
  594. # [18:34] * Quits: gunderwonder (n=gunderwo@garage.upstruct.com)
  595. # [18:34] <jacobolus> or are there big page sets already gathered (and freely available somewhere?) to do such an analysis on?
  596. # [18:36] <Philip`> jacobolus: There's http://dev.opera.com/articles/view/mama/ but I'm not sure that's got font names
  597. # [18:37] <Philip`> That uses pages downloaded from the freely available list from dmoz.org
  598. # [18:37] <Philip`> http://www.dotnetdotcom.org/ has a big pile of HTML pages (no CSS) freely available
  599. # [18:37] <jacobolus> Philip`: thanks, that's a cool resource. no listed fonts though
  600. # [18:38] <jacobolus> (the opera one)
  601. # [18:38] <tantek> are there actually authors that try to validate (unprocessed source) PHP files as HTML?
  602. # [18:39] <Philip`> jacobolus: I can easily run regexps over dotnetdotcom's ~425K HTML pages, so if there's a regexp that would (approximately) extract font names (from inline CSS) then I could do that
  603. # [18:40] <jacobolus> Philip`: okay, just a minute
  604. # [18:41] <takkaria> "font\s*:" and "font-family\s?:" would probably catch a lot them
  605. # [18:42] <Philip`> (?i)font(?:-family)?\s*:([^;"}]+) gives some stuff you could extract individual names from
  606. # [18:46] <jacobolus> Philip`: will your regexps just return all captures?
  607. # [18:47] * Quits: Phae (n=phaeness@gateb.mh.bbc.co.uk)
  608. # [18:47] <Philip`> jacobolus: For each line that matches the regexp, it can either print the line or print the first matching substring or print any captured group
  609. # [18:48] * Joins: weinig (n=weinig@nat/apple/x-tpdbmjjlfkrfcfnh)
  610. # [18:48] <jacobolus> just one of the captured groups?
  611. # [18:48] <jacobolus> oh, I guess if it can print the lines out, it would be possible to grab that and run further regexps on it
  612. # [18:48] <Philip`> Yes
  613. # [18:49] <Philip`> Most of the lines have lots of HTML junk in them
  614. # [18:49] * Quits: Creap (n=Creap@vemod.brg.sgsnet.se) ("nu fäkt")
  615. # [18:49] * Quits: mengelhardt (n=chatzill@pD9E070C4.dip.t-dialin.net) (Read error: 113 (No route to host))
  616. # [18:54] <jacobolus> yeah
  617. # [18:54] <Philip`> jacobolus: http://philip.html5.org/data/fonts-in-inline-css-raw.txt.gz (~7MB) has the strings that match the regexp I gave earlier
  618. # [18:55] <jacobolus> font(?:\-family)?\s*\:.*\s*((?:(?:'[a-zA-Z ]*')|(?:"[a-zA-Z ]*")|[a-zA-Z]*)(?=\s*[,}])[^}]*)}
  619. # [18:55] <Philip`> (I can do it differently if you're willing to wait ten minutes for it to regenerate)
  620. # [18:55] <jacobolus> I think that should be right
  621. # [18:55] <jacobolus> I should do some testing
  622. # [18:55] <Philip`> (Use a command like 'gzip -cd fonts-in-inline-css-raw.txt.gz|sort -u|cut -f2|sort|uniq -c|sort -n' to count number of pages each string occurs on, etc)
  623. # [18:57] <jacobolus> actually
  624. # [18:57] <jacobolus> font(?:\-family)?\s*\:.*\s*((?:(?:'[a-zA-Z ]*')|(?:"[a-zA-Z ]*")|[a-zA-Z]*)(?=\s*[,;}])[^;}]*)[};]
  625. # [18:57] <Philip`> jacobolus: That seems like it's probably close to a subset of what my regexp was matching, so hopefully you could just run that on my existing output :-)
  626. # [18:58] * Quits: myakura (n=myakura@p1215-ipbf412marunouchi.tokyo.ocn.ne.jp) ("Leaving...")
  627. # [18:58] <jacobolus> Philip`: probably a subset, yes :)
  628. # [18:58] <jacobolus> this just grabs all the fonts in a "stack"
  629. # [18:58] <jacobolus> as one capture
  630. # [18:58] <Philip`> jacobolus: That one wouldn't match style="font-family: wingdings"
  631. # [18:58] <Philip`> I think
  632. # [18:58] <jacobolus> oh, true
  633. # [18:58] <jacobolus> because it doesn't end in ,, ;, or }
  634. # [18:59] <jacobolus> :/
  635. # [19:00] * Quits: mat_t (n=mattomas@nat/canonical/x-wiynltesdbqjcdgv) (Remote closed the connection)
  636. # [19:01] <Darxus> I suppose I should complain about the inability to set an li style to "+" or "-" to the css folks, not the html folks?
  637. # [19:03] <Darxus> Sorry, nevermind: 12:56PM < mamont> Darxus: li:before { content: "+"; }
  638. # [19:03] <jacobolus> Darxus: you can just use a custom image or so, no?
  639. # [19:04] <gsnedders> Darxus: "To obtain other glyphs, authors should use the 'content' property of the ::marker pseudo-element." — CSS3 Lists
  640. # [19:04] <jacobolus> if you do li:before won't that change the alignment
  641. # [19:04] <Darxus> jacobolus: I can, but I don't consider the inability... to do the above acceptable.
  642. # [19:04] <Darxus> jacobolus: Haven't tried it yet. My guess is the "before" part isn't necessary.
  643. # [19:04] <jacobolus> gsnedders: do browsers implement that?
  644. # [19:04] <gsnedders> jacobolus: No.
  645. # [19:04] <jacobolus> :)
  646. # [19:05] <gsnedders> jacobolus: But the fact that CSS3 says something about it means there's little point in writing to www-style :)
  647. # [19:05] <jacobolus> heh
  648. # [19:05] <Darxus> It's actually in CSS3.
  649. # [19:05] <jacobolus> IOW go complain in #webkit, on irc.mozilla.org, etc...
  650. # [19:05] * Quits: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net) (Read error: 104 (Connection reset by peer))
  651. # [19:06] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  652. # [19:06] <jacobolus> not that they'll have any sympathy
  653. # [19:09] * gsnedders comes across Dashiva in BTS
  654. # [19:10] * Joins: onar_ (n=onar@17.244.68.70)
  655. # [19:12] * Joins: cying_ (n=cying@70.90.171.153)
  656. # [19:12] <Philip`> jacobolus: You can get a seemingly reasonably not-too-inaccurate list by doing something like
  657. # [19:12] <Philip`> gzip -cd fonts-in-inline-css-raw.txt.gz|sort -u|cut -f2|sort|perl -lne's/.*?://;print $1 while /('\''[^'\'']+'\''|"[^"]+"|[^\s,]+)/g'|sort|uniq -c|sort -n
  658. # [19:12] * Quits: sgalineau (n=sylvaing@nat/microsoft/x-mslmszuoqcncrqtt) (Read error: 104 (Connection reset by peer))
  659. # [19:13] <Darxus> So that content trick seems to be not what I want. It's not changing the bullet, and so it's not doing the alignment I care about.
  660. # [19:13] <Philip`> and then ignoring the ones like "11px" which obviously aren't fonts
  661. # [19:13] <Darxus> Can't imagine how CSS has gone so long without allowing you to specify an arbitrary character as the bullet style.
  662. # [19:13] <Philip`> Might need to tweak the results so they're more meaningful e.g. counting number of pages each value appears on
  663. # [19:13] <gsnedders> Darxus: Images.
  664. # [19:13] <Darxus> gsnedders: Not acceptable.
  665. # [19:14] <jacobolus> Philip`: I was writing a python script to spit out all the font stacks :)
  666. # [19:14] <Philip`> Darxus: "<p>+ Line one.<br>+ Line two.</p>"
  667. # [19:14] <Darxus> I'll do a table. I think it actually sort of qualifies as tabular data.
  668. # [19:14] <gsnedders> Darxus: Well, obviously, seeming is has gone for so long it is acceptable
  669. # [19:14] <Philip`> jacobolus: I prefer bash+perl :-)
  670. # [19:14] <Darxus> Philip`: I want to alternate between + and -, the characters are different widths, so what I'm looking for is proper alignment.
  671. # [19:15] <Darxus> (Positive and negative attributes of the thing in the list heading.)
  672. # [19:15] <jacobolus> Philip`: I dunno whether you've done much python ever, but this is fun stuff: http://www.dabeaz.com/generators
  673. # [19:15] <Philip`> Darxus: "<p><span style=position:absolute>+</span>&nbsp; Line one.<br><span style=position:absolute>-</span>&nbsp; Line two.</p>"
  674. # [19:15] <gsnedders> jacobolus: But Python is slow!
  675. # [19:16] <Darxus> Nice, it looks like since yesterday whatwg overthrew w3 as the first google hit for html5.
  676. # [19:16] <gsnedders> We're back at number one!
  677. # [19:17] * ZombieLoffe is now known as ZombieL
  678. # [19:17] * ZombieL is now known as ZambiaL
  679. # [19:18] * ZambiaL is now known as ZombieL
  680. # [19:22] * cying_ is now known as cyingWork
  681. # [19:22] * Joins: sgalineau (n=sylvaing@nat/microsoft/x-bzzycmtakzlcnwmm)
  682. # [19:28] * Quits: onar_ (n=onar@17.244.68.70)
  683. # [19:28] <gsnedders> Are scripts running upon being added to the DOM?
  684. # [19:29] * Joins: onar_ (n=onar@17.244.68.70)
  685. # [19:31] * Quits: onar_ (n=onar@17.244.68.70) (Client Quit)
  686. # [19:46] <gsnedders> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/188 should run per HTML 5, but doesn't in IE, Fx, Chromium, and only does in Opera
  687. # [19:49] * Joins: cying_ (n=cying@70.90.171.153)
  688. # [19:49] * Quits: cying_ (n=cying@70.90.171.153) (Remote closed the connection)
  689. # [19:49] * Joins: jennb (n=jennb@72.14.227.1)
  690. # [19:49] * Joins: sbublava (n=stephan@77.118.186.19.wireless.dyn.drei.com)
  691. # [19:54] <Dashiva> gsnedders: Snooping in canvas bugs, are you?
  692. # [19:54] <gsnedders> Dashiva: no
  693. # [19:54] * gsnedders needs a break having been working for almost eight hours
  694. # [19:54] <gsnedders> Time to go home, I think
  695. # [19:59] * Quits: abii (n=macbook@cm27.delta30.maxonline.com.sg)
  696. # [19:59] * Parts: adactio (n=adactio@host86-132-125-223.range86-132.btcentralplus.com)
  697. # [20:01] * eighty4 is now known as trying
  698. # [20:02] * trying is now known as eighty4
  699. # [20:03] * Quits: sgalineau (n=sylvaing@nat/microsoft/x-bzzycmtakzlcnwmm) (Read error: 110 (Connection timed out))
  700. # [20:05] * Quits: cyingWork (n=cying@70.90.171.153) (Read error: 110 (Connection timed out))
  701. # [20:05] * Quits: jwalden (n=waldo@c-98-248-40-206.hsd1.ca.comcast.net) ("inbound")
  702. # [20:07] * Joins: arun__ (n=arun@nat/mozilla/x-tiqdcpwxpfpijrwt)
  703. # [20:07] * Joins: sgalineau (n=sylvaing@nat/microsoft/x-trtmxliaphmtwbaq)
  704. # [20:10] * Joins: weinig_ (n=weinig@17.246.17.209)
  705. # [20:10] <annevk> http://www.smashingmagazine.com/2009/07/29/misunderstanding-markup-xhtml-2-comic-strip/ is nice
  706. # [20:11] <annevk> except of course that XHTML as text/html is fiction :p
  707. # [20:19] * Joins: jwalden (n=waldo@nat/mozilla/x-hleuuntzoovogice)
  708. # [20:23] * Joins: aboodman2 (n=aboodman@72.14.229.81)
  709. # [20:23] * Quits: sgalineau (n=sylvaing@nat/microsoft/x-trtmxliaphmtwbaq) (Read error: 104 (Connection reset by peer))
  710. # [20:25] * Quits: cying (n=cying@adsl-75-41-114-136.dsl.pltn13.sbcglobal.net)
  711. # [20:27] * Quits: weinig (n=weinig@nat/apple/x-tpdbmjjlfkrfcfnh) (Read error: 110 (Connection timed out))
  712. # [20:27] <tantek> annevk - XHTML as text/html is not fiction - validates just fine with the W3C validator :)
  713. # [20:28] <annevk> that validator is also a piece of fiction :p
  714. # [20:29] <annevk> having said that, I don't really care that much what people do with their markup
  715. # [20:30] <tantek> annekv - you have a curious usage of the word "fiction" ;) http://validator.w3.org
  716. # [20:31] * Joins: ttepass- (n=ttepas--@p5B017D51.dip.t-dialin.net)
  717. # [20:33] <Hixie> XHTML as text/html isn't fiction, it happens all the time
  718. # [20:33] * Joins: gsnedders_ (n=gsnedder@c83-252-197-10.bredband.comhem.se)
  719. # [20:33] <Hixie> the rules for how to process XHTML go out of the window when you use text/html though
  720. # [20:33] <Hixie> and with XHTML5, you can't have XHTML5 as text/html
  721. # [20:34] * Quits: gsnedders (n=gsnedder@pat.se.opera.com) (Nick collision from services.)
  722. # [20:34] * gsnedders_ is now known as gsnedders
  723. # [20:35] * Joins: gsnedders_ (n=gsnedder@pat.se.opera.com)
  724. # [20:38] * Quits: weinig_ (n=weinig@17.246.17.209) (Remote closed the connection)
  725. # [20:39] * Joins: weinig (n=weinig@nat/apple/x-bftuaibbppzyaero)
  726. # [20:39] <Hixie> this Installed Apps thread had better be good
  727. # [20:40] <weinig> Hixie: :\
  728. # [20:42] * Joins: onar_ (n=onar@17.226.23.106)
  729. # [20:42] * Quits: onar_ (n=onar@17.226.23.106) (Remote closed the connection)
  730. # [20:46] * Quits: ttepasse (n=ttepas--@p5B0142B4.dip.t-dialin.net) (Read error: 110 (Connection timed out))
  731. # [20:46] * Joins: ttepasse (n=ttepas--@p5B013BBB.dip.t-dialin.net)
  732. # [20:46] * Joins: weinig_ (n=weinig@17.246.17.209)
  733. # [20:49] <annevk> tantek, I'll give you that :)
  734. # [20:51] * Joins: tkent_ (n=tkent@220.109.219.244)
  735. # [20:59] * Joins: maikmerten (n=maikmert@Z817b.z.pppool.de)
  736. # [21:00] * Quits: ttepass- (n=ttepas--@p5B017D51.dip.t-dialin.net) (Read error: 110 (Connection timed out))
  737. # [21:01] * Joins: kristallpirat (n=kristall@c-base/crew/kristall)
  738. # [21:02] * Joins: ttepass- (n=ttepas--@p5B016B91.dip.t-dialin.net)
  739. # [21:03] * Quits: weinig (n=weinig@nat/apple/x-bftuaibbppzyaero) (Read error: 110 (Connection timed out))
  740. # [21:05] <Hixie> gsnedders_: why is it desireable for the parser to go out of its way to avoid multiple <body>s?
  741. # [21:06] <Hixie> gsnedders_: i'm not going to change the spec on that, at least not unless a good reason to do so is presented.
  742. # [21:07] <Darxus> What is the correct way to display a triple line break between paragraphs, to show greater separation?
  743. # [21:07] <Darxus> Er, correct markup.
  744. # [21:08] <annevk> <style> p { margin:2em 0 } </style>
  745. # [21:08] * Quits: tkent (n=tkent@220.109.219.244) (Read error: 110 (Connection timed out))
  746. # [21:08] <Hixie> Darxus: <p>...</p><hr><p>...</p>
  747. # [21:08] <Darxus> Hixie: I like that one better, thanks.
  748. # [21:08] <Hixie> HTML5 then styles <hr> as hr { border: none; margin: 2em; } or something
  749. # [21:10] <Darxus> It took me a long time to give in to p's with end tags (used br's instead), but now I'm fond of them.
  750. # [21:10] * Joins: zcorpan (n=zcorpan@c83-252-201-53.bredband.comhem.se)
  751. # [21:12] <Darxus> You guys may enjoy reading up on Lojban, a synthetic human language designed to reduce language related limits on thought. No ambiguity.
  752. # [21:13] <Darxus> (And it's entirely HTML5's fault I ended up finding it - wondering how best to apply the HTML refinement process to human language.)
  753. # [21:14] * Joins: sgalineau (n=sylvaing@nat/microsoft/x-ftoznjugquyhqvpx)
  754. # [21:20] <Dashiva> Darxus: There's always ambiguity, you just move it one step up in the hierarchy
  755. # [21:25] * Joins: ap (n=ap@nat/apple/x-zlgozqxllvtwxgqr)
  756. # [21:25] * Quits: ttepasse (n=ttepas--@p5B013BBB.dip.t-dialin.net) (Read error: 110 (Connection timed out))
  757. # [21:25] <tfh> ds++
  758. # [21:28] * Quits: zcorpan (n=zcorpan@c83-252-201-53.bredband.comhem.se) (Read error: 110 (Connection timed out))
  759. # [21:36] * Quits: weinig_ (n=weinig@17.246.17.209)
  760. # [21:39] * Quits: taf2_ (n=taf2@38.99.201.242) (Read error: 60 (Operation timed out))
  761. # [21:41] <Darxus> Dashiva: Where is there ambiguity in Lojban?
  762. # [21:42] * Joins: taf2 (n=taf2@38.99.201.242)
  763. # [21:43] * Quits: othermaciej (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net)
  764. # [21:45] * Joins: billmason (n=billmaso@ip124.unival.com)
  765. # [21:45] * Parts: billmason (n=billmaso@ip124.unival.com)
  766. # [21:46] * Parts: annevk2 (n=annevk@5355732C.cable.casema.nl)
  767. # [21:48] * Joins: zcorpan (n=zcorpan@c83-252-201-53.bredband.comhem.se)
  768. # [21:52] * Quits: dbaron (n=dbaron@nat/mozilla/x-beiwukujkzzywuts) (Read error: 110 (Connection timed out))
  769. # [21:53] * Joins: annevk2 (n=annevk@5355732C.cable.casema.nl)
  770. # [21:53] <Darxus> CSS3 for lists is awfully extensive for not being able to specify a freaking character to use as the bullet: http://www.w3.org/TR/css3-lists/
  771. # [21:54] * Parts: gsnedders (n=gsnedder@c83-252-197-10.bredband.comhem.se)
  772. # [21:54] <tantek> Darxus, you may be looking for generated content.
  773. # [21:54] <Darxus> tantek: Somebody pointed me at that earlier, the problem is that it doesn't handle the alignment as a bullet.
  774. # [21:54] * Joins: dbaron (n=dbaron@nat/mozilla/x-rpkghcadnciaaani)
  775. # [21:55] * Quits: dolske (n=dolske@c-76-103-40-203.hsd1.ca.comcast.net)
  776. # [21:55] * Quits: zcorpan (n=zcorpan@c83-252-201-53.bredband.comhem.se) (Read error: 104 (Connection reset by peer))
  777. # [21:55] <Darxus> Oh, hah, I didn't realize that CSS3 (at least for lists) is also Hixies fault.
  778. # [21:55] <Darxus> Hixie: Fix it.
  779. # [21:55] <Hixie> i took a break from css to work on html5
  780. # [21:55] <Darxus> Ah.
  781. # [21:55] <tantek> I think I took the same break to work on microformats.
  782. # [21:55] <Darxus> Hixie: I would like to be able to specify any character to use as a bullet in a list.
  783. # [21:56] <Hixie> ::marker { content: '' }
  784. # [21:56] <Hixie> iirc
  785. # [21:56] <Darxus> Particulary + / -, to list positive and negative aspects of something.
  786. # [21:56] <tantek> Darxus, I believe you may need to use generated content, and float:left, and text-align:right
  787. # [21:56] <tantek> oh and perhaps some negative margin-left
  788. # [21:56] <tantek> but you may find better luck to such questions in #css
  789. # [21:56] <Darxus> tantek: Tables work easy :P
  790. # [21:57] <Darxus> tantek: Talked to #css about it first.
  791. # [21:58] <tantek> Darxus, Hixie is right - see ::marker http://www.w3.org/TR/css3-lists/#markers
  792. # [22:00] * Joins: othermaciej (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net)
  793. # [22:03] <Darxus> tantek: Working on it, thanks. Any idea if any browsers have implimented it?
  794. # [22:06] * Joins: weinig (n=weinig@17.246.17.209)
  795. # [22:08] * Joins: cying (n=cying@70.90.171.153)
  796. # [22:09] <Darxus> Yeah I copied the example in the spec and it doesn't work in chrome or firefox 3.
  797. # [22:09] <Darxus> Hixie: But thanks for including it.
  798. # [22:09] <tantek> you may want to check their open source repositories for evidence of ::marker support
  799. # [22:10] <tantek> perhaps ask in the #webkit channel
  800. # [22:10] * Joins: erikvold (n=erikvvol@96.49.192.204)
  801. # [22:11] <tantek> and in #firefox
  802. # [22:11] * Joins: gsnedders (n=gsnedder@c83-252-197-10.bredband.comhem.se)
  803. # [22:15] * Quits: maikmerten (n=maikmert@Z817b.z.pppool.de) (Remote closed the connection)
  804. # [22:16] * Quits: taf2 (n=taf2@38.99.201.242) (Read error: 60 (Operation timed out))
  805. # [22:16] * Quits: sgalineau (n=sylvaing@nat/microsoft/x-ftoznjugquyhqvpx) (Read error: 104 (Connection reset by peer))
  806. # [22:22] * Joins: taf2 (n=taf2@38.99.201.242)
  807. # [22:23] * Joins: ttepasse (n=ttepas--@p5B0158D5.dip.t-dialin.net)
  808. # [22:23] * Joins: ap_ (n=ap@17.246.19.211)
  809. # [22:27] * Joins: dglazkov_ (n=dglazkov@nat/google/x-rfiminxyinfpcmbb)
  810. # [22:28] * annevk2 finds http://www.pemberton.nl/vandf/2009/07/xhtml2-not-dead.html
  811. # [22:28] * Quits: erikvvold (n=erikvvol@96.49.192.204) (Read error: 110 (Connection timed out))
  812. # [22:29] * Joins: dolske (n=dolske@nat/mozilla/x-czbkmdsrkzbjzeyc)
  813. # [22:32] <Hixie> i wouldn't expect anyone to support the lists stuff yet
  814. # [22:35] <annevk2> iirc nobody went further than a bunch of the new keywords
  815. # [22:36] * Quits: othermaciej (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net)
  816. # [22:37] * Quits: ttepass- (n=ttepas--@p5B016B91.dip.t-dialin.net) (Read error: 110 (Connection timed out))
  817. # [22:38] * Joins: ttepass- (n=ttepas--@p5B017306.dip.t-dialin.net)
  818. # [22:38] * Quits: ap (n=ap@nat/apple/x-zlgozqxllvtwxgqr) (Read error: 110 (Connection timed out))
  819. # [22:41] * Quits: weinig (n=weinig@17.246.17.209)
  820. # [22:43] * Quits: dglazkov (n=dglazkov@nat/google/x-01e433c5e1588227) (Read error: 110 (Connection timed out))
  821. # [22:51] * Quits: ROBOd (n=robod@89.122.216.38) ("http://www.robodesign.ro")
  822. # [22:51] * Quits: ttepasse (n=ttepas--@p5B0158D5.dip.t-dialin.net) (Read error: 110 (Connection timed out))
  823. # [22:51] * Joins: ttepasse (n=ttepas--@p5B015586.dip.t-dialin.net)
  824. # [22:55] * Quits: sbublava (n=stephan@77.118.186.19.wireless.dyn.drei.com)
  825. # [22:56] * Joins: weinig (n=weinig@17.246.17.209)
  826. # [22:59] * Quits: pmuellr (n=pmuellr@nat/ibm/x-pkszdmkobzzwpgzv)
  827. # [23:05] * Joins: tndH_ (n=Rob@cpc2-leed18-0-0-cust427.leed.cable.ntl.com)
  828. # [23:06] * Joins: sgalineau (n=sylvaing@nat/microsoft/x-smvfgdsfbwniyzyu)
  829. # [23:06] * Quits: dglazkov_ (n=dglazkov@nat/google/x-rfiminxyinfpcmbb) (Remote closed the connection)
  830. # [23:06] * Joins: dglazkov (n=dglazkov@nat/google/x-ckdwfzqxhtqrwctg)
  831. # [23:07] * Joins: dbaron_ (n=dbaron@nat/mozilla/x-hsiuptwcfnzhrmof)
  832. # [23:11] * Quits: tndH (n=Rob@cpc2-leed18-0-0-cust427.leed.cable.ntl.com) (Read error: 110 (Connection timed out))
  833. # [23:11] * tndH_ is now known as tndH
  834. # [23:12] * Quits: weinig (n=weinig@17.246.17.209)
  835. # [23:14] * Quits: ttepass- (n=ttepas--@p5B017306.dip.t-dialin.net) (Read error: 110 (Connection timed out))
  836. # [23:16] * Joins: weinig (n=weinig@17.246.17.209)
  837. # [23:18] * Joins: Hish (n=chatzill@mail2.n-e-s.de)
  838. # [23:20] * Quits: weinig (n=weinig@17.246.17.209) (Client Quit)
  839. # [23:22] * Joins: StationsPatient (n=kristall@c-base/crew/kristall)
  840. # [23:22] * Joins: jennb_ (n=jennb@72.14.227.1)
  841. # [23:26] * Quits: gsnedders (n=gsnedder@c83-252-197-10.bredband.comhem.se)
  842. # [23:27] * Joins: slightlyoff (n=slightly@72.14.229.81)
  843. # [23:30] * Joins: tndH_ (n=Rob@cpc2-leed18-0-0-cust427.leed.cable.ntl.com)
  844. # [23:31] * Joins: othermaciej (n=mjs@17.246.19.253)
  845. # [23:31] * Quits: kristallpirat (n=kristall@c-base/crew/kristall) (Read error: 104 (Connection reset by peer))
  846. # [23:32] * Quits: dbaron (n=dbaron@nat/mozilla/x-rpkghcadnciaaani) (Read error: 110 (Connection timed out))
  847. # [23:32] * Joins: kristallpirat (n=kristall@c-base/crew/kristall)
  848. # [23:33] * Quits: othermaciej (n=mjs@17.246.19.253) (Client Quit)
  849. # [23:36] * Quits: jennb (n=jennb@72.14.227.1) (Read error: 110 (Connection timed out))
  850. # [23:41] * Joins: Sidnicious (n=Sidney@unaffiliated/sidnicious)
  851. # [23:42] * Quits: tndH (n=Rob@cpc2-leed18-0-0-cust427.leed.cable.ntl.com) (Read error: 110 (Connection timed out))
  852. # [23:46] * annevk2 wonders if Thomas meant getting the name wrong with bad quoting or the top posting :p
  853. # [23:46] * Quits: arun__ (n=arun@nat/mozilla/x-tiqdcpwxpfpijrwt) (Read error: 110 (Connection timed out))
  854. # [23:47] * Quits: StationsPatient (n=kristall@c-base/crew/kristall) (Read error: 110 (Connection timed out))
  855. # [23:47] * Philip` wonders who Philip is
  856. # [23:48] <Philip`> Maybe some weird mixup between Patrick and PHP?
  857. # [23:51] * Joins: othermaciej (n=mjs@17.246.19.253)
  858. # [23:51] * Quits: Chris_Wilson (n=cwilso@nat/microsoft/x-lwpytjyzpytwmepo) (Read error: 110 (Connection timed out))
  859. # [23:54] * riven` is now known as riven
  860. # [23:54] * Joins: Phae (n=phaeness@cpc2-acto9-0-0-cust364.brnt.cable.ntl.com)
  861. # [23:55] * Quits: othermaciej (n=mjs@17.246.19.253) (Client Quit)
  862. # [23:55] * Joins: weinig (n=weinig@17.246.17.209)
  863. # [23:56] * Quits: archtech (n=stanv@83.228.56.37) (Read error: 113 (No route to host))
  864. # [23:56] * Quits: weinig (n=weinig@17.246.17.209) (Client Quit)
  865. # [23:58] * Joins: jennb (n=jennb@72.14.227.1)
  866. # [23:58] * Joins: othermaciej (n=mjs@nat/apple/x-wglucrrqsqqdbxiq)
  867. # Session Close: Thu Jul 30 00:00:00 2009

The end :)