/irc-logs / freenode / #whatwg / 2010-07-07 / end

Options:

  1. # Session Start: Wed Jul 07 00:00:00 2010
  2. # Session Ident: #whatwg
  3. # [00:06] * Joins: nessy (~Adium@209.52.84.51)
  4. # [00:07] * Quits: Martijnc (~Martijnc@91.176.155.244)
  5. # [00:16] * Joins: shepazu (~schepers@adsl-242-235-39.rmo.bellsouth.net)
  6. # [00:24] * Quits: gratz|home (~gratz@cpc3-brig15-2-0-cust237.3-3.cable.virginmedia.com) (Quit: Leaving)
  7. # [00:27] * Joins: titacgs (~titacgs@190.2.33.49)
  8. # [00:34] * Joins: othermaciej (~mjs@17.246.17.147)
  9. # [00:39] * Joins: gabriel9 (~gabriel9@93.157.192.28)
  10. # [00:39] * Quits: eighty4 (~eighty4@c-76c8e455.012-403-6c6b701.cust.bredbandsbolaget.se) (Remote host closed the connection)
  11. # [00:40] * Quits: BlurstOfTimes (~blurstoft@168.203.117.112) (Remote host closed the connection)
  12. # [00:50] <zcorpan_> hmm, if the opening handshake has content-length, do the 8 bytes still fulfill their intended purpose?
  13. # [00:50] <zcorpan_> or should we just drop key3 altogether
  14. # [00:56] * Quits: zcorpan_ (~zcorpan@pat.se.opera.com) (Quit: zcorpan_)
  15. # [00:57] * Quits: nessy (~Adium@209.52.84.51) (Quit: Leaving.)
  16. # [01:01] * Quits: nielsle (~nielsle@1503032406.dhcp.dbnet.dk) (Quit: Ex-Chat)
  17. # [01:05] * Quits: titacgs (~titacgs@190.2.33.49) (Ping timeout: 276 seconds)
  18. # [01:11] * Joins: nessy (~Adium@209.52.84.50)
  19. # [01:24] * Joins: boblet (~boblet@p1201-ipbf709osakakita.osaka.ocn.ne.jp)
  20. # [01:37] * Joins: mdelaney (~mdelaney@2620:0:1b00:1191:d69a:20ff:febf:89a0)
  21. # [01:37] * Quits: aroben (~aroben@unaffiliated/aroben) (Quit: aroben)
  22. # [01:43] * Joins: jlebar (~jlebar@209.52.84.51)
  23. # [01:45] * Joins: homata (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp)
  24. # [01:47] * Joins: Nameless (~Nameless@cm218-252-156-82.hkcable.com.hk)
  25. # [01:49] * Quits: abarth (~abarth@c-98-210-108-185.hsd1.ca.comcast.net) (Ping timeout: 240 seconds)
  26. # [01:50] * Joins: wakaba_ (~wakaba_@122x221x184x68.ap122.ftth.ucom.ne.jp)
  27. # [01:51] * Quits: MikeSmith (~MikeSmith@EM111-188-3-101.pool.e-mobile.ne.jp) (Quit: Till kicked and torn and beaten out he lies, and leaves his hold and crackles, groans, and dies.)
  28. # [01:51] * Quits: mdelaney (~mdelaney@2620:0:1b00:1191:d69a:20ff:febf:89a0) (Quit: mdelaney)
  29. # [01:52] * Quits: Nameless (~Nameless@cm218-252-156-82.hkcable.com.hk) (Client Quit)
  30. # [01:52] * Joins: MikeSmith (~MikeSmith@EM114-48-147-169.pool.e-mobile.ne.jp)
  31. # [02:03] * Joins: jrgarrison (~garrison@wikiotics/jrgarrison)
  32. # [02:07] * Quits: JonathanNeal (~JonathanN@rrcs-76-79-114-210.west.biz.rr.com) (Read error: Connection reset by peer)
  33. # [02:14] * Quits: FireFly (~firefly@unaffiliated/firefly) (Quit: swatted to death)
  34. # [02:18] * Joins: yutak_home (~kee@U017209.ppp.dion.ne.jp)
  35. # [02:28] * Joins: miketaylr (~miketaylr@24.42.95.108)
  36. # [02:28] * Joins: smaug_ (~chatzilla@209.52.84.50)
  37. # [02:28] * Quits: ap (~ap@2620:0:1b00:1191:226:4aff:fe14:aad6) (Quit: ap)
  38. # [02:32] * Quits: karlcow (~karl@nerval.la-grange.net) (Quit: This computer has gone to sleep)
  39. # [02:34] * Joins: nicktick (~na@unaffiliated/nicktick)
  40. # [02:47] * Quits: jlebar (~jlebar@209.52.84.51) (Ping timeout: 260 seconds)
  41. # [02:56] * Joins: FireFly (~firefly@unaffiliated/firefly)
  42. # [02:57] * Quits: boblet (~boblet@p1201-ipbf709osakakita.osaka.ocn.ne.jp) (Quit: boblet)
  43. # [02:58] * Parts: everton (~everton@KD118153063184.ppp-bb.dion.ne.jp)
  44. # [02:59] * Quits: yutak_home (~kee@U017209.ppp.dion.ne.jp) (Quit: Ex-Chat)
  45. # [03:05] * Quits: nessy (~Adium@209.52.84.50) (Quit: Leaving.)
  46. # [03:08] * Quits: WePanicForYou (~ziggy@unaffiliated/panicsys) (Quit: there is no bald lad manipulating a non-existent sp00n)
  47. # [03:11] <AryehGregor> "The best demos that we’ve seen for D2D support are actually the IE Flying Images and the IE Flickr Explorer demo. Firefox actually performs wonderfully on these demos, better than the IE9 builds in most cases." Yay.
  48. # [03:11] <AryehGregor> And probably Firefox 4 will release before IE9.
  49. # [03:11] <AryehGregor> Now if only it has OpenGL support by then too. Otherwise the IE people will say "We're glad to say what great use other browsers can make of our awesome proprietary Windows(R) technology."
  50. # [03:11] <MikeSmith> heh
  51. # [03:14] <MikeSmith> I'm sure the Web graphics performance race will continue for quite a while
  52. # [03:14] <MikeSmith> with browser projects taking turns leapfrogging past each other
  53. # [03:14] <MikeSmith> hopefully
  54. # [03:14] * Quits: miketaylr (~miketaylr@24.42.95.108) (Ping timeout: 276 seconds)
  55. # [03:15] <AryehGregor> Unfortunately, I darkly suspect that Linux will do poorly even once hardware acceleration is enabled, unless maybe you use a proprietary driver.
  56. # [03:15] <AryehGregor> I guess we'll see.
  57. # [03:18] <MikeSmith> fortunately, many desktop Linux users are accustomed to poor user experience and so have low expectations :)
  58. # [03:18] <Slaanesh> Implement OpenGL in canvas
  59. # [03:18] <AryehGregor> "The -moz-background-size property has been renamed to its final background-size name. -moz-background-size is no longer supported." Doesn't this encourage authors to specify foo alongside -moz-foo, thereby defeating the point of vendor prefixes?
  60. # [03:18] <AryehGregor> Slaanesh, you mean WebGL?
  61. # [03:18] <Slaanesh> No, OpenGL 1.5
  62. # [03:18] <AryehGregor> A bunch of browsers have experimental implementations of that.
  63. # [03:18] * AryehGregor looks up info about WebGL
  64. # [03:18] <Slaanesh> WebGL is basically OpenGL ES 2.0
  65. # [03:19] <AryehGregor> . . . so what's the difference?
  66. # [03:20] * Joins: wakaba_0 (~wakaba_@203-140-90-184.eonet.ne.jp)
  67. # [03:20] * Quits: wakaba_ (~wakaba_@122x221x184x68.ap122.ftth.ucom.ne.jp) (Ping timeout: 240 seconds)
  68. # [03:21] * Quits: gabriel9 (~gabriel9@93.157.192.28) (Write error: Broken pipe)
  69. # [03:23] * Quits: roc (~roc@209.52.84.51) (Quit: roc)
  70. # [03:23] * Joins: gabriel9 (~gabriel9@93.157.192.28)
  71. # [03:24] * Joins: roc (~roc@209.52.84.51)
  72. # [03:26] * Joins: miketaylr (~miketaylr@24.42.95.108)
  73. # [03:28] * Quits: roc (~roc@209.52.84.51) (Ping timeout: 248 seconds)
  74. # [03:31] * Joins: fwaokda (~fwaokda@adsl-222-72-253.jan.bellsouth.net)
  75. # [03:40] * Joins: rolandsteiner (~rolandste@220.109.219.244)
  76. # [03:42] * Joins: boblet (~boblet@p1201-ipbf709osakakita.osaka.ocn.ne.jp)
  77. # [03:46] * Quits: boblet (~boblet@p1201-ipbf709osakakita.osaka.ocn.ne.jp) (Client Quit)
  78. # [03:53] <MikeSmith> we are still looking for an editor to pick up work on the WebIDL spec
  79. # [03:53] <MikeSmith> http://dev.w3.org/2006/webapi/WebIDL/
  80. # [03:54] <MikeSmith> everlasting fame awaits the right person
  81. # [03:57] <micheil> Hixie: ping. (re that thread on hybi, just wanted to discuss something with you before repling)
  82. # [03:57] <micheil> *replying
  83. # [03:57] <Hixie> micheil: that is hardly the only spec awaiting an editor :-)
  84. # [03:57] <Hixie> micheil: hey
  85. # [03:57] <micheil> howdy'
  86. # [03:59] <micheil> Hixie: about the thing with the challenge being sent without a content-length, that was actually an issue when I was implemented the node.js server, this resulted in us changing the node.js http server to do a different thing if a request is an upgrade request, rather then a regular request
  87. # [03:59] <Hixie> indeed, that's the idea
  88. # [03:59] <micheil> and even now, without a content-length, I'm having to use a guess method to get the header, as if it isn't the right length sent, then I'm having to buffer to ensure it is.
  89. # [04:00] <micheil> and when I was implementing, I did check the http spec to find out that node was handling the request fine, according to http spec (which is what the node http parser was design to do), and that websockets weren't actually meeting spec
  90. # [04:01] <Hixie> web sockets is meeting the web sockets spec
  91. # [04:01] <Hixie> it's not http
  92. # [04:01] <Hixie> it just looks like http just enough to make it possible to share the port
  93. # [04:01] <micheil> but the initial handshake is over http protocol.
  94. # [04:01] <Hixie> no
  95. # [04:01] * Quits: nicktick (~na@unaffiliated/nicktick) (Read error: Connection reset by peer)
  96. # [04:01] <Hixie> it's web sockets
  97. # [04:01] <micheil> well, okay then
  98. # [04:01] * Joins: nicktick (~na@unaffiliated/nicktick)
  99. # [04:01] <micheil> but it does mean that you can't use the same server side parser as you would for compliant http
  100. # [04:02] <micheil> which adds a barrier to implementation
  101. # [04:02] <Hixie> you can't anyway, that would be non-conformming to web sockets
  102. # [04:03] <Hixie> for example, web sockets requires that you ignore continuation lines
  103. # [04:03] <micheil> then how could you have a server that does websockets respond to normal GET requests for pages?
  104. # [04:03] * Quits: kennyluck (~kennyluck@133.27.228.176) (Quit: kennyluck)
  105. # [04:03] <micheil> if you don't use http spec in the handshake
  106. # [04:04] <Hixie> the only "correct" way to implement it if you really need to share a port with an http server is for the server to decide when it looks at the incoming data whether it thinks it's http or not (e.g. by looking for Upgrade: WebSockets) and if it thinks it is Web Sockets, to hand off the whole buffer and socket to another piece of code
  107. # [04:04] <Hixie> the whole "share the port with http" thing was a mistake though, imho
  108. # [04:04] <micheil> yeah, which is something that is almost impossible to do within node, without major code changes to the http server
  109. # [04:04] <micheil> I'd agree on it being a mistake, but I can see where it'd be useful.
  110. # [04:05] <Hixie> well, personally i would recommend not bothering supporting both protocols on one connection
  111. # [04:05] <Hixie> on one port i mean
  112. # [04:05] <Hixie> (you can never do it on one connection currently)
  113. # [04:05] <micheil> and now it's there, it sort of forces websockets to use the http parser, until the http parser know's that the data it's receiving is actually an upgraded http request
  114. # [04:05] <Hixie> it doesn't force it unless you decide to share the port
  115. # [04:05] <Hixie> which nobody is forcing anyone to do
  116. # [04:06] <micheil> although, because it looks like http, that's where people will start serving http off the same server
  117. # [04:07] <micheil> it then makes no sense for the websocket protocol to even initialize a connection with a http type header
  118. # [04:07] <Hixie> (btw, you can also just hack it by parsing the handshake per http, then handing the socket to the websockets code before sending back the 101)
  119. # [04:08] <micheil> that's what I do.
  120. # [04:08] <Hixie> i agree that it makes no sense for the websocket protocol to initialize a connection with a http type header, but it's probably to olate now
  121. # [04:08] <Hixie> given the implementations
  122. # [04:08] <micheil> node's http parser is evented, so, I get an "upgrade" event from it, instead of a "request" event, when it parsers the headers.
  123. # [04:08] <Hixie> makes sense
  124. # [04:09] <Hixie> the mail to hybi was about a reverse proxy, btw, not an http server
  125. # [04:09] <Hixie> which is a different kettle of fish and is even less valid imho as a complaint
  126. # [04:09] <micheil> however, because no content-length on the request body is set, we just have to rely on whatever the rest of the buffer after the headers is as the upgrade header
  127. # [04:09] <Hixie> (if you have reverse proxies, you really have no reason to be sharing the port, you surely have enough IP addresses to have a dedicated server)
  128. # [04:09] <Hixie> micheil: why?
  129. # [04:10] <Hixie> micheil: why can't you handle it the same way as the frames afterwards?
  130. # [04:10] <micheil> as far as I can see, if the websocket protocol is going to us a http handshake, and allow you to serve http off a websocket server, then the initial handshake should comply to http spec.
  131. # [04:10] <micheil> because, it's sent as one frame..
  132. # [04:11] <Hixie> "sent as one frame"?
  133. # [04:11] <Hixie> what in the http spec does the web socket handshake violate?
  134. # [04:12] <micheil> in the sense that my server has always received the data in buffer, in that first data packet it receives from a connection as GET .... \r\n....\r\n\r\nChallenge\r\n
  135. # [04:12] <micheil> (maybe not the last \r\n)
  136. # [04:12] <micheil> well, from what I'm reading, websockets doesn't send a content-length when it sends a body, which is in violation of http spec.
  137. # [04:13] <Hixie> can you cite the actual statement that the handshake is violating?
  138. # [04:13] <micheil> more then likely not.
  139. # [04:13] <Hixie> i don't understand what you mean about the packets. There's nothing that guarantees the handshake will be in one TCP/IP packet.
  140. # [04:14] <Hixie> or that the frames won't be broken across packets.
  141. # [04:14] <Hixie> or that the end of the handshake and the start of the first frame won't be in the same packet, if the client didn't check the handshake (which it might not if it's a dedicated command-line client)
  142. # [04:14] <micheil> yeah, which is why I'm letting node's http parser handle the parsing of the incoming stream of data until it know's it's an upgrade
  143. # [04:15] <Hixie> i don't understand why you can't treat the first 8 bytes as just a spec kind of frame, like the rest of the frames
  144. # [04:15] <micheil> because it's often caught by the http parser
  145. # [04:16] <micheil> and as it's not stated as a body in the headers, the http parser that complies to spec doesn't know what to do with this extra data
  146. # [04:18] <Hixie> what would you do if we put the 8 bytes in the header somehow, and then the client sent a frame along with the handshake so that it appeared in the same packet?
  147. # [04:18] <micheil> it's the same issue as what was being seen by the reverse proxy
  148. # [04:19] <micheil> if the 8 bytes were as a header, I'd have no problems with that.
  149. # [04:19] <micheil> but there's still that backwards compat issue. now that chrome 6 supports draft76, it's going to be a major issue (as chrome auto-updates itself)
  150. # [04:20] <Hixie> i don't understand why the 8 bytes are an issue but the terabytes of potential data after the 8 bytes are not
  151. # [04:20] * Quits: gabriel9 (~gabriel9@93.157.192.28) (Read error: Connection reset by peer)
  152. # [04:20] <micheil> if you have a "draft77" of the spec, which moves that 8 bytes into a header, then you're going to have then 3 protocols to try and support by the server
  153. # [04:21] <micheil> because, the way we're doing it is by hijacking the connection after we've parsed the GET request
  154. # [04:22] <micheil> this is all that I actually do outside of the http server in order to determine a websocket request: http://github.com/miksago/node-websocket-server/blob/master/lib/ws.js#L55-66
  155. # [04:22] <Hixie> if the first packet from the client is "GET /foo bla bla bla handshake bla bla \r\n\r\n12345678[frame][frame][frame]", why is byte "8" going to be a disastrous problem, but the 0x00 byte immediately after it in the first [frame] in the _same TCP/IP packet_ not going to be a problem?
  156. # [04:23] <micheil> because, I've not yet seen any client that sends something like: GET /foo bla bla bla handshake bla bla \r\n\r\n123456780x00
  157. # [04:23] * Quits: weinig (~weinig@17.246.18.173) (Quit: weinig)
  158. # [04:23] <Hixie> there's no reason one couldn't exist
  159. # [04:23] <micheil> basically long of the short of what I'm saying is that I agree in adding the content-length
  160. # [04:24] <micheil> true, and the content-length would then ensure that the http parser know's to pause reading the buffer after it has received the defined number of bytes
  161. # [04:24] <Hixie> so the problem would also be solved by content-length: 0 ?
  162. # [04:25] <micheil> yes
  163. # [04:25] <micheil> but as the challenge body is part of the initial http request, it'd make more sense to do content-length: 8
  164. # [04:25] <micheil> which would fix it for the reverse proxies as well
  165. # [04:26] <Hixie> then your server is buggy, because the http spec, as i understand it, says that GET implies content-length:0 if it's missing
  166. # [04:27] <Hixie> (content-length:8 would defeat the whole point, which is to make man-in-the-middle proxies fail to send the bytes because they look like the next request)
  167. # [04:28] <micheil> I don't actually know the internals of the http parser we're using.
  168. # [04:29] <micheil> and I would get the developer of it to explain it more clearly then I could, but he's not around at the moment
  169. # [04:31] <Hixie> (i can't actually find where in the http 1.1 spec it says how to determine the length of a GET request without an explicit content-length, but i'm pretty sure it has to assume it's zero, since otherwise you'd never know when the request was finished)
  170. # [04:31] <micheil> on the EOF?
  171. # [04:31] <micheil> or when you choose to close the request?
  172. # [04:32] <Hixie> if you just closed the request you wouldn't be able to get a reply :-)
  173. # [04:32] <Hixie> let alone pipeline multiple requests
  174. # [04:32] <Hixie> anyway, i'd be fine with adding a content-length:0 header, i just think it's pointless
  175. # [04:33] <Hixie> i'd be strongly against adding a content-length:8 header, for multiple reasons:
  176. # [04:33] <Hixie> 1. it would break the whole point of the 8 bytes
  177. # [04:33] <Hixie> 2. it would just bury the problem you described, so people would be less likely to test for it, even though the bug would still be there (e.g. with dedicated clients sending frames along with the handshake)
  178. # [04:35] * Joins: karlcow (~karl@nerval.la-grange.net)
  179. # [04:35] <micheil> well, I mean, the way I've designed my websocket server to work, is to work either way, so I'm fine if the spec goes to either way
  180. # [04:36] <Hixie> yeah, 3. i'm not convinced it's actually a problem anyway
  181. # [04:36] <Hixie> it's probably a little more work for people reusing http servers, but my answer would be to not do that
  182. # [04:36] <Hixie> just write dedicated websocket servers, it's trivial to do
  183. # [04:37] * Quits: TelFiRE (~TelFiRE@c-24-10-155-57.hsd1.ut.comcast.net) (Quit: TelFiRE)
  184. # [04:37] <micheil> yeah, but parsing the headers of http, like the protocol says you should be doing, is often extremely difficult, and hence the reason people would be inclined to use a http server.
  185. # [04:39] <micheil> by extension, because the websocket protocol is sending an upgrade header, and not being a totally different protocol, it is in effect extending the HTTP protocol, so it is valid for it to be handled by a http server, until that server knows otherwise in which case it can handle it correctly
  186. # [04:40] <micheil> for instance, you could fire a websocket request at a non-websocket enabled server, and you'd just get back either a bad request response or a connection: closed
  187. # [04:41] <micheil> example: https://gist.github.com/7e4459073a89b4ed4ea9
  188. # [04:41] <micheil> localhost:80 is just a standard nginx install
  189. # [04:42] <micheil> example with a valid url: https://gist.github.com/f25dc66f20f0d372a649
  190. # [04:43] <Hixie> micheil: parsing the headers is _not_ hard, it's really easy. it's only hard if you have to share a port with an http server.
  191. # [04:43] <Hixie> micheil: don't forget web sockets has far simpler field parsing rules than http's header parsing rules
  192. # [04:43] <micheil> which is how the protocol is designed, and it's the most common thing I have requested for my server to do.
  193. # [04:44] <Hixie> what's the most common thing you have requested?
  194. # [04:44] <Hixie> i don't follow
  195. # [04:49] <micheil> the most common thing I have requested that my websocket-server support is to being able to handle standard http requests
  196. # [04:49] <micheil> as people want their websocket server to share the port with their http server
  197. # [04:50] <Hixie> do they say why?
  198. # [04:50] <micheil> because that's what their been told websockets does, and that's how they understand the protocol.
  199. # [04:51] <micheil> because it looks like http, people want to treat it as http, and I'm not going to disallow that, because I think it's the right method of going about it.
  200. # [04:53] <Hixie> so the reason people want the feature is that it's possible?
  201. # [04:53] <Hixie> that's pretty silly
  202. # [04:53] * Quits: karlcow (~karl@nerval.la-grange.net) (Quit: This computer has gone to sleep)
  203. # [04:55] <micheil> and it's also how the spec reads. It currently reads in a way that says: "Websocket servers, may optionally also act as HTTP servers"
  204. # [04:56] <micheil> to quote: "The opening handshake is intended to be compatible with HTTP-based server-side software, so that a single port can be used by both HTTP clients talking to that server and WebSocket clients talking to that server"
  205. # [04:56] <micheil> section 1.3 of the protocol document.
  206. # [04:58] <micheil> the way that most people probably read that is that a websocket server should be able to handle http. it may be the wrong way of thinking about it, but it'd take a lot of effort to re-educate that that isn't how the protocol works
  207. # [04:58] <micheil> as it is, I have a hard enough time trying to explain to people that there's more to websockets now then what there was in draft75.
  208. # [04:59] <micheil> also, by not having a websocket-server act as a http server, you remove the possibility of allow degrades like Sockets.io uses, where by it'll try and use websockets, if that fails, then it'll use comted
  209. # [04:59] <micheil> *cometd protocol / bayeux
  210. # [05:02] <Hixie> i think it's fine that we make it possible, because there are use cases where it does make sense
  211. # [05:02] <Hixie> i'm a little concerned that people are thinking this is the main way to use the protocol
  212. # [05:02] <Hixie> because that rather misses the point, which is that writing a custom websocket server is a weekend's work at most
  213. # [05:04] <micheil> it's taken me more then a weekend to implement my websocket server, for sure.
  214. # [05:04] <Hixie> sure, but you're also doing it with http
  215. # [05:04] <micheil> the only case where it's a weekend's work, is if you're highly familiar with IETF specs.
  216. # [05:05] <Hixie> if you just do a straight websocket server, with no http at all, it's trivial
  217. # [05:05] <Hixie> you just follow the spec
  218. # [05:05] <Hixie> it's like 150 lines of perl
  219. # [05:05] <micheil> actually, I was able to implement it much easier using the http as a basis.
  220. # [05:05] <micheil> because of the different clients I tested, each sent the headers in a slightly different way
  221. # [05:05] * Quits: tyoshino (~tyoshino@220.109.219.244) (Quit: Leaving...)
  222. # [05:06] <Hixie> well, right now it's more difficult than it should be because of the various versions, for sure
  223. # [05:06] <Hixie> i just mean once the spec is interoperably implemented
  224. # [05:07] <micheil> you'll always have older clients.
  225. # [05:08] <micheil> are you going to refuse an IE visitor access to your site because they don't support border-radius? I doubt it.
  226. # [05:08] <Hixie> i'm just talking about websockets
  227. # [05:09] <micheil> yeah, and in which case, are you going to refuse people using chrome 5 or safari 5 access to your site because they don't support draft76?
  228. # [05:09] <micheil> it'd be the same issue as what we get with the CSS spec.
  229. # [05:09] <Hixie> both chrome and safari update very very quickly, such that that won't be an issue for long
  230. # [05:10] <micheil> umm.. safari hasn't yet updated to draft76, and safari 5 was released when 76 was available, so, go figure.
  231. # [05:13] * Quits: fwaokda (~fwaokda@adsl-222-72-253.jan.bellsouth.net) (Ping timeout: 240 seconds)
  232. # [05:13] <Hixie> sure, but the spec isn't done yet
  233. # [05:13] <Hixie> there might well be further breaking changes
  234. # [05:13] <Hixie> my point is that once we're stable, someone implementing a server that just works with compliant clients will be very easy.
  235. # [05:18] * Joins: fwaokda (~fwaokda@adsl-157-18-210.jan.bellsouth.net)
  236. # [05:18] <micheil> yeah, but we know they clients are generally never compliant
  237. # [05:19] <micheil> because even when the spec is stable, you may still have Joe connecting using chrome 5, or safari 5, because their organisation hasn't / can't upgrade to a newer version of the browser
  238. # [05:19] <micheil> which while that scenario is unlikely, it's something to plan for, because it will happen.
  239. # [05:20] <Hixie> i'm more optimistic :-)
  240. # [05:20] <micheil> I've already seen it, and consequentially I've implemented an auto mode in the server to automatically choose which handshake to use be it draft76 or draft75
  241. # [05:20] <Hixie> yes, but again, right now is not a normal situation
  242. # [05:21] <micheil> and if you tell the server to only support version X, then clients connecting using version Y will be rejected
  243. # [05:21] <micheil> but the thing you have is that people want to support the most client's possible.
  244. # [05:21] <micheil> there's no point in using websockets now, if you can only use them in chromium 6.
  245. # [05:21] <micheil> (and possibly chrome 6 by extension)
  246. # [05:22] <Hixie> yes i understand; in due course, however, all the deployed clients will be compliant
  247. # [05:22] <Hixie> so it'll be a non-issue
  248. # [05:22] <micheil> how many years? 1? 2? 5? 10? 20?
  249. # [05:22] <micheil> it'll be the same issue as what has been seen in the css spec and implementation
  250. # [05:23] <Hixie> i predicted it would be so by 2022
  251. # [05:23] <Hixie> for the stuff that was in web apps 1.0 in 2006, which includes what is now known as web sockets
  252. # [05:24] <Hixie> so <12 years?
  253. # [05:24] <micheil> right.. so.. basically you're saying that no one should use websockets yet at the moment, when the demand for them is now.
  254. # [05:25] <Hixie> demand ain't gonna go down :-)
  255. # [05:26] <micheil> are we even going to be using http in 12 years time?
  256. # [05:26] <micheil> are we going to be using a web browser as it is today in 12 years time?
  257. # [05:26] <Hixie> we were 20 years ago, so, sure
  258. # [05:26] <Hixie> what else would we use?
  259. # [05:26] <micheil> to put in perspective, I didn't know the web really existed 12 years ago.
  260. # [05:27] <micheil> I would've actually only been 5 years old. 12 years is a bloody long time.
  261. # [05:27] <Hixie> sure
  262. # [05:27] <Hixie> but it takes a bloody long time for things to change, too
  263. # [05:30] <Hixie> i don't see why a technology that hasn't been invented yet would be able to take over and be more widely implemented and usable than a technology that already exists
  264. # [05:31] <micheil> well, as far as I've seen it's been almost instant with the adoption of changes to the websocket protocl.
  265. # [05:31] <micheil> chrome 5 -> chrome 6.
  266. # [05:31] <micheil> that's maybe 1 year at most.
  267. # [05:32] <micheil> which is very quick adoption.
  268. # [05:32] * Joins: roc (~roc@209.52.84.51)
  269. # [05:32] <micheil> but then, only 2 months before chrome 6 was released, we had safari 5 released that was supporting the older spec, not the newest spec.
  270. # [05:33] <micheil> as for firefox, opera, and IE, I have no idea where they currently stand on implementing websockets.
  271. # [05:33] <micheil> (and I haven't had time to test each version.)
  272. # [05:33] <Hixie> i hope that it'll be a lot less than 12 years in practice
  273. # [05:33] <Hixie> 2022 was just the date for everything in the spec; it's quite possible some things will be ready sooner
  274. # [05:34] <micheil> but my point still stands that you'll have some people become dependent on draft75, hence can't upgrade to draft76, hence locking them out of using websites that use draft76
  275. # [05:35] * Joins: karlcow (~karl@nerval.la-grange.net)
  276. # [05:35] * Quits: miketaylr (~miketaylr@24.42.95.108) (Quit: Leaving...)
  277. # [05:42] <Hixie> micheil: i am seriously completely unconcerned by people getting "dependent" on a draft that is only currently implemented by one browser
  278. # [05:42] <Hixie> especially since it was a highly unstable draft
  279. # [05:43] <Hixie> and anyone implementing it is basically asking for trouble
  280. # [05:43] <Hixie> since it has known security flaws
  281. # [05:43] <micheil> I know people who already have. and by you being unconcerned by it, it totally breaks everything that's been said about progressive enhancement being good practice
  282. # [05:43] <micheil> like I said, the demand for websockets is now. not sometime in the next 12 years.
  283. # [05:44] <Hixie> i hate to be blunt, but there's a difference between being backwards compatible with established technologies, and being backwards compatible with insecure unstable working drafts
  284. # [05:44] <Hixie> we can't be held hostage to people playing with experiments
  285. # [05:44] <micheil> okay then.
  286. # [05:44] <Hixie> the demaind for websockets isn't going away any time soon
  287. # [05:44] <Hixie> demand, even
  288. # [05:44] <micheil> yeah, but the fact is, it's now. people want to use it now.
  289. # [05:45] <Hixie> sure
  290. # [05:45] <Hixie> and tomorrow
  291. # [05:45] <Hixie> and the day after
  292. # [05:45] <Hixie> and also yesterday
  293. # [05:45] <Hixie> and the day before that
  294. # [05:45] <Hixie> that's why we are working on it
  295. # [05:45] <Hixie> not much point working on technologies that don't have demand :-)
  296. # [05:45] <micheil> I've already had clients come to me wanting to use websockets, because their interfaces demand for it. Should I just tell them: "Sorry, but websockets aren't ready for public comsuption yet"?
  297. # [05:46] <Hixie> yes
  298. # [05:46] <micheil> I'm not going to do that, because I'm a freelancer. I need the money. I'm not going to deny myself the option to earn it.
  299. # [05:46] <micheil> If I don't do it, then there'll be someone else that does.
  300. # [05:47] <micheil> I can recommend that websockets are an unstable protocol, but I'm not going to decline to work on it.
  301. # [05:48] <Hixie> that's fine, as long as they (and you) understand that you might get screwed again if we change the protocol :-)
  302. # [05:48] <micheil> to give context, the big demand for rounded corners was in the "web 2.0 era", it's not so much now. now it's just a nice design decision, and we've learnt that some browsers just won't get the rounded corners (progressive enhancement)
  303. # [05:49] <Hixie> well i'm glad to say that i think web sockets will be ready before rounded corners, but that says more about the csswg than anything else
  304. # [05:50] * Quits: cfq (~cfq@94-194-98-91.zone8.bethere.co.uk) (Quit: cfq)
  305. # [05:53] * Quits: nimbupani (~nimbupani@c-24-22-131-46.hsd1.wa.comcast.net) (Quit: nimbupani)
  306. # [06:02] * Joins: homata_ (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp)
  307. # [06:05] * Quits: homata (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp) (Ping timeout: 240 seconds)
  308. # [06:11] * Joins: bzed_ (~bzed@devel.recluse.de)
  309. # [06:11] * bzed_ is now known as Guest65862
  310. # [06:11] * Quits: ttepasse (~ttepasse@ip-109-90-160-217.unitymediagroup.de) (Quit: ⌘Q)
  311. # [06:11] * Quits: bzed (~bzed@devel.recluse.de) (Read error: Operation timed out)
  312. # [06:17] * Joins: mdelaney (~mdelaney@c-24-6-60-29.hsd1.ca.comcast.net)
  313. # [06:17] * Joins: boblet (~boblet@p1201-ipbf709osakakita.osaka.ocn.ne.jp)
  314. # [06:18] * Joins: weinig (~weinig@c-69-181-125-223.hsd1.ca.comcast.net)
  315. # [06:19] * Quits: mdelaney (~mdelaney@c-24-6-60-29.hsd1.ca.comcast.net) (Client Quit)
  316. # [06:22] * Joins: mdelaney (~mdelaney@c-24-6-60-29.hsd1.ca.comcast.net)
  317. # [06:36] * Quits: bobchao (~cctw@209.52.84.50) (Ping timeout: 240 seconds)
  318. # [06:37] * Quits: jrgarrison (~garrison@wikiotics/jrgarrison) (Quit: Ex-Chat)
  319. # [06:43] * Joins: bobchao (~cctw@209.52.84.50)
  320. # [06:46] * Quits: homata_ (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp) (Ping timeout: 240 seconds)
  321. # [06:47] * Joins: homata (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp)
  322. # [06:51] * Joins: homata_ (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp)
  323. # [06:53] * Quits: homata (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp) (Ping timeout: 260 seconds)
  324. # [07:12] * Joins: nessy (~Adium@209.52.84.50)
  325. # [07:18] * Quits: roc (~roc@209.52.84.51) (Quit: roc)
  326. # [07:19] * Joins: mhausenblas (~mhausenbl@wg1-nat.fwgal01.deri.ie)
  327. # [07:23] * Joins: henrikbjorn (~hb@109.56.191.237)
  328. # [07:31] * Quits: mdelaney (~mdelaney@c-24-6-60-29.hsd1.ca.comcast.net) (Read error: No route to host)
  329. # [07:31] * Joins: mdelaney (~mdelaney@c-24-6-60-29.hsd1.ca.comcast.net)
  330. # [07:33] * Quits: othermaciej (~mjs@17.246.17.147) (Quit: othermaciej)
  331. # [07:41] * Quits: mdelaney (~mdelaney@c-24-6-60-29.hsd1.ca.comcast.net) (Read error: Connection reset by peer)
  332. # [07:41] * Quits: nicktick (~na@unaffiliated/nicktick) (Ping timeout: 252 seconds)
  333. # [07:41] * Quits: nessy (~Adium@209.52.84.50) (Read error: Connection reset by peer)
  334. # [07:42] * Joins: mdelaney (~mdelaney@c-24-6-60-29.hsd1.ca.comcast.net)
  335. # [07:43] * Joins: maikmerten (~merten@ls5dhcp196.cs.uni-dortmund.de)
  336. # [07:47] * Quits: Anonameless (~Nameless@cm218-252-156-82.hkcable.com.hk) (Read error: Connection reset by peer)
  337. # [07:48] * Quits: mdelaney (~mdelaney@c-24-6-60-29.hsd1.ca.comcast.net) (Remote host closed the connection)
  338. # [07:48] * Joins: mdelaney (~mdelaney@c-24-6-60-29.hsd1.ca.comcast.net)
  339. # [07:49] * Quits: henrikbjorn (~hb@109.56.191.237) (Ping timeout: 240 seconds)
  340. # [07:50] * Joins: nessy (~Adium@209.52.84.50)
  341. # [07:52] * Joins: MikeSmithX (~MikeSmith@EM114-48-25-161.pool.e-mobile.ne.jp)
  342. # [07:53] * Joins: deepthawtz (~deepthawt@c-67-180-92-66.hsd1.ca.comcast.net)
  343. # [07:53] * Quits: deepthawtz (~deepthawt@c-67-180-92-66.hsd1.ca.comcast.net) (Remote host closed the connection)
  344. # [07:56] * Quits: MikeSmith (~MikeSmith@EM114-48-147-169.pool.e-mobile.ne.jp) (Ping timeout: 245 seconds)
  345. # [07:57] * Joins: henrikbjorn (~hb@109.57.159.74)
  346. # [07:58] * Quits: maikmerten (~merten@ls5dhcp196.cs.uni-dortmund.de) (Read error: Operation timed out)
  347. # [08:01] * Quits: henrikbjorn (~hb@109.57.159.74) (Remote host closed the connection)
  348. # [08:07] * Joins: Heimidal (~heimidal@unaffiliated/heimidal)
  349. # [08:10] * Joins: mdelaney_ (~mdelaney@c-24-6-60-29.hsd1.ca.comcast.net)
  350. # [08:11] * Joins: WePanicForYou (~ziggy@unaffiliated/panicsys)
  351. # [08:12] <jwm> now we just need websocket server support in browsers
  352. # [08:12] <jwm> *cough*
  353. # [08:12] <jwm> hehe
  354. # [08:12] * Quits: mdelaney_ (~mdelaney@c-24-6-60-29.hsd1.ca.comcast.net) (Remote host closed the connection)
  355. # [08:12] * Quits: mdelaney (~mdelaney@c-24-6-60-29.hsd1.ca.comcast.net) (Ping timeout: 248 seconds)
  356. # [08:13] * Quits: nessy (~Adium@209.52.84.50) (Quit: Leaving.)
  357. # [08:13] * Joins: eighty4 (~eighty4@h-112-7.A163.corp.bahnhof.se)
  358. # [08:15] * Joins: nicktick (~na@unaffiliated/nicktick)
  359. # [08:17] * Quits: Heimidal (~heimidal@unaffiliated/heimidal) (Remote host closed the connection)
  360. # [08:19] * Quits: Amorphous (jan@unaffiliated/amorphous) (Ping timeout: 248 seconds)
  361. # [08:22] * Quits: justicefries (~gerred@c-98-245-71-126.hsd1.co.comcast.net) (Quit: justicefries)
  362. # [08:25] * Joins: estellevw (~estellevw@adsl-99-170-149-16.dsl.pltn13.sbcglobal.net)
  363. # [08:32] * Joins: othermaciej (~mjs@c-69-181-42-237.hsd1.ca.comcast.net)
  364. # [08:34] * Joins: Amorphous (jan@unaffiliated/amorphous)
  365. # [08:45] * Joins: Maurice (~ano@a80-101-46-164.adsl.xs4all.nl)
  366. # [08:45] * Joins: pesla (~pesla@188.202.125.121)
  367. # [08:52] * Quits: smaug_ (~chatzilla@209.52.84.50) (Ping timeout: 240 seconds)
  368. # [08:57] * Joins: zalan (~zalan@catv-89-135-140-7.catv.broadband.hu)
  369. # [09:30] * Joins: roc (~roc@209.52.84.50)
  370. # [09:33] * Joins: homata (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp)
  371. # [09:36] * Quits: homata_ (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp) (Ping timeout: 240 seconds)
  372. # [09:41] * Quits: estellevw (~estellevw@adsl-99-170-149-16.dsl.pltn13.sbcglobal.net) (Quit: estellevw)
  373. # [09:50] * Joins: kennyluck (~kennyluck@133.27.228.175)
  374. # [09:52] * Joins: pesla_ (~pesla@188.202.125.121)
  375. # [09:55] * Quits: pesla (~pesla@188.202.125.121) (Ping timeout: 248 seconds)
  376. # [09:55] * pesla_ is now known as pesla
  377. # [10:18] * Joins: svl (~me@ip565744a7.direct-adsl.nl)
  378. # [10:21] <annevk> Hixie, should just pick a non-HTTP port again and push back on IANA maybe
  379. # [10:24] * Joins: harig (~harig@180.215.58.20)
  380. # [10:29] * Quits: harig (~harig@180.215.58.20) (Ping timeout: 264 seconds)
  381. # [10:33] * Quits: homata (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp) (Ping timeout: 260 seconds)
  382. # [10:33] * Joins: homata (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp)
  383. # [10:33] * Quits: Lachy (~Lachlan@cm-84.215.59.50.getinternet.no) (Quit: This computer has gone to sleep)
  384. # [10:34] * Joins: zcorpan_ (~zcorpan@pat.se.opera.com)
  385. # [10:40] * Joins: cfq (~cfq@94-194-98-91.zone8.bethere.co.uk)
  386. # [10:45] * Joins: Lachy (~Lachlan@pat-tdc.opera.com)
  387. # [10:46] * Joins: Phae (~Phae@gatekeeper.macmillan.co.uk)
  388. # [10:47] * Joins: akamike (~akamike@94-193-106-14.zone7.bethere.co.uk)
  389. # [10:48] * Joins: lhnz (~lhnz@188-223-83-48.zone14.bethere.co.uk)
  390. # [10:49] * Joins: slartsa (~Lari@adsl-215-234-204.kymp.net)
  391. # [10:50] * Quits: Lachy (~Lachlan@pat-tdc.opera.com) (Client Quit)
  392. # [10:50] * Joins: Lachy (~Lachlan@pat-tdc.opera.com)
  393. # [10:51] <zcorpan_> so does adding connection: close solve the reverse proxy problem?
  394. # [10:56] * Quits: Smylers (~smylers@host86-162-120-121.range86-162.btcentralplus.com) (Ping timeout: 245 seconds)
  395. # [10:56] * Quits: slartsa (~Lari@adsl-215-234-204.kymp.net) (Ping timeout: 276 seconds)
  396. # [10:57] * Joins: Smylers (~smylers@host86-162-120-121.range86-162.btcentralplus.com)
  397. # [11:03] * MikeSmithX is now known as MikeSmith
  398. # [11:09] * Joins: ROBOd (~robod@109.96.213.23)
  399. # [11:13] * Joins: homata_ (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp)
  400. # [11:14] * Quits: homata (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp) (Ping timeout: 240 seconds)
  401. # [11:20] * Quits: cfq (~cfq@94-194-98-91.zone8.bethere.co.uk) (Quit: cfq)
  402. # [11:25] * Joins: adactio (~adactio@host213-123-197-180.in-addr.btopenworld.com)
  403. # [11:34] * Quits: pesla (~pesla@188.202.125.121) (Remote host closed the connection)
  404. # [11:34] * Joins: pesla (~pesla@188.202.125.121)
  405. # [11:42] * Joins: pauld (~chatzilla@194.102.13.2)
  406. # [11:47] * Quits: Smylers (~smylers@host86-162-120-121.range86-162.btcentralplus.com) (Ping timeout: 265 seconds)
  407. # [11:47] <MikeSmith> fwiw, I just made a change to the "Edition for Web Authors" subset of the spec (static copy of the "Hide UA text") view
  408. # [11:48] <MikeSmith> the change is to some of the link behavior
  409. # [11:49] <MikeSmith> there are some links in the author view with fragment IDs that are not actually in the author view
  410. # [11:49] <MikeSmith> only in the full spec
  411. # [11:49] * Joins: Smylers (~smylers@host86-162-120-121.range86-162.btcentralplus.com)
  412. # [11:51] <MikeSmith> so what I did was to cause those to be rewritten (in the generated static copy) so that they are absolute URLs to the full spec
  413. # [11:51] <MikeSmith> instead of (broken) fragment references
  414. # [11:51] <MikeSmith> and I added some :hover styling for them
  415. # [11:52] <MikeSmith> see for example, http://dev.w3.org/html5/spec-author-view/timers.html#timers
  416. # [11:52] <MikeSmith> hover over the "setTimeout()" link
  417. # [11:53] <MikeSmith> if anybody has suggestions for how to better style those, lemme now
  418. # [11:54] <MikeSmith> the way I have it now, there's no visual indicator that it's an external link to the full spec
  419. # [11:54] <MikeSmith> you don't know until you hover over it whether it is or not
  420. # [11:55] <MikeSmith> but maybe there should be some visual indication that shows up even if you don't hover
  421. # [11:55] <MikeSmith> I just didn't want to add anything additional that would be obtrusive/annoying
  422. # [11:56] <MikeSmith> e.g., it's going to show up in pretty much all the IDLs
  423. # [11:56] <zcorpan_> MikeSmith: changing the layout on hover is annoying. could you use outline instead of border or something?
  424. # [11:56] <MikeSmith> because the links in the IDLs are mostly definitions in the full spec
  425. # [11:56] <MikeSmith> zcorpan_: sure
  426. # [11:56] <MikeSmith> if I know the CSS
  427. # [11:57] <MikeSmith> um, is outline a CSS property?
  428. # [11:57] <zcorpan_> yeah
  429. # [11:57] <zcorpan_> and no horizontal padding
  430. # [11:57] <MikeSmith> hai
  431. # [11:57] <MikeSmith> will make an attempt right now
  432. # [11:57] * Quits: homata_ (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp) (Ping timeout: 240 seconds)
  433. # [11:58] * Joins: homata (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp)
  434. # [11:58] * zcorpan_ would be ok with no vertical padding too
  435. # [11:58] <MikeSmith> zcorpan_: yeah, agreed it's annoying
  436. # [12:00] <zcorpan_> MikeSmith: the "This box is non-normative. Implementation requirements are given below this box." text is not really accurate
  437. # [12:00] <MikeSmith> hmm, yeah
  438. # [12:00] <zcorpan_> maybe just remove them
  439. # [12:00] <MikeSmith> I think that's something that Hixie will need to change in teh upstream source
  440. # [12:01] <MikeSmith> zcorpan_: they show up in the dynamic "Hide UA text" view also
  441. # [12:02] <MikeSmith> I guess the text "Implementation requirements are given below this box." should probably be marked up with span/@class=impl
  442. # [12:02] <zcorpan_> i thought it was css-generated
  443. # [12:02] <MikeSmith> oh
  444. # [12:03] <MikeSmith> if it is, then that's easy enough to tweak
  445. # [12:03] * MikeSmith checks the stylesheet
  446. # [12:03] <MikeSmith> doesn't appear to be CSS-generated
  447. # [12:04] <MikeSmith> is there a way that I can have an outline that bleeds over the surrounding text?
  448. # [12:04] <annevk> are you sure it's not CSS-generated?
  449. # [12:04] <annevk> pretty sure it is
  450. # [12:04] <annevk> if this is about domintro boxes
  451. # [12:04] <MikeSmith> that is, with padding that doesn't cause surrounding text to be pushed aside or up or down
  452. # [12:05] * Quits: nicktick (~na@unaffiliated/nicktick) (Ping timeout: 245 seconds)
  453. # [12:06] <MikeSmith> maybe I'm not looking at the right stylesheet
  454. # [12:06] * Quits: kennyluck (~kennyluck@133.27.228.175) (Quit: kennyluck)
  455. # [12:08] <MikeSmith> hmm, yeah, it's definitely generated
  456. # [12:16] <MikeSmith> "The outline created with the outline properties is drawn "over" a box, i.e., the outline is always on top, and does not influence the position or size of the box, or of any other boxes. Therefore, displaying or suppressing outlines does not cause reflow or overflow."
  457. # [12:16] <MikeSmith> http://www.w3.org/TR/CSS21/ui.html#dynamic-outlines
  458. # [12:17] <MikeSmith> so again I wonder how I can specify an outline with a padding such that it doesn't cause any reflow
  459. # [12:19] <MikeSmith> oh, offset
  460. # [12:19] * Joins: harig (~harig@180.215.33.57)
  461. # [12:20] * Quits: harig (~harig@180.215.33.57) (Client Quit)
  462. # [12:38] * Quits: wakaba_0 (~wakaba_@203-140-90-184.eonet.ne.jp) (Ping timeout: 252 seconds)
  463. # [12:39] * Joins: wakaba_ (~wakaba_@122x221x184x68.ap122.ftth.ucom.ne.jp)
  464. # [12:44] * Quits: bobchao (~cctw@209.52.84.50) (Ping timeout: 240 seconds)
  465. # [12:47] <MikeSmith> zcorpan_: updated with attempted improvements
  466. # [12:47] <MikeSmith> I removed the domintro:before generated text
  467. # [12:47] <MikeSmith> and changed the link styling to outline with and offset
  468. # [12:48] <MikeSmith> *an offset
  469. # [12:53] * Joins: workmad3 (~workmad3@84.88.33.150)
  470. # [12:54] <Lachy> reading through the change proposal for doctype versioning (ISSUE-4), since the poll apparently starts next week, there are so many technical problems with it, even ignoring the fact that it's a bad idea
  471. # [12:57] <MikeSmith> zcorpan_: hang on for a minute.. seems my commit failed for some reason
  472. # [12:58] <Lachy> ... like the fact that it doesn't actually provide any justification for needing a completely useless versioning syntax, especailly when it says that UAs must not implement any other DOCTYPE specific behaviour
  473. # [12:59] * Quits: adactio (~adactio@host213-123-197-180.in-addr.btopenworld.com) (Quit: adactio)
  474. # [13:01] * Joins: adactio (~adactio@host213-123-197-180.in-addr.btopenworld.com)
  475. # [13:01] * Quits: homata (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp) (Ping timeout: 240 seconds)
  476. # [13:01] * Joins: davidhund (~davidhund@78-27-27-74.dsl.alice.nl)
  477. # [13:02] * Joins: homata (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp)
  478. # [13:02] <MikeSmith> http://techcrunch.com/2010/07/06/freelancer-geolocation-html5-jobs/
  479. # [13:02] * Joins: bobchao (~cctw@209.52.84.50)
  480. # [13:04] <MikeSmith> ". As a result of what the company dubs the ‘Apple effect’, Freelancer.com also saw a significant 721% boost in HTML5 jobs."
  481. # [13:06] * Joins: nielsle (~nielsle@1503032406.dhcp.dbnet.dk)
  482. # [13:07] <Philip`> That's a lot of significant figures
  483. # [13:07] <MikeSmith> dunno what constitutes an "HTML job"
  484. # [13:08] <MikeSmith> I suppose any job ad that mentions "HTML5"
  485. # [13:08] * Quits: Peter` (~peter@170-116.citynet.ftth.internl.net) (*.net *.split)
  486. # [13:08] * Quits: jmb (~jmb@login.ecs.soton.ac.uk) (*.net *.split)
  487. # [13:09] <MikeSmith> I wonder if they count jobs adds that say "we think HTML5 is hype and we're not looking for 'HTML5' developers so if you are an 'HTML5' developer please apply somewhere else for 'HTML5' work instead of here, where we're not looking got any kind of HTML5 stuff"
  488. # [13:10] <MikeSmith> zcorpan_: checked in and synced up now on http://dev.w3.org/html5/spec-author-view/
  489. # [13:10] <MikeSmith> fwiw
  490. # [13:11] * MikeSmith prepares to hook up the trailer to his riding lawn mower for the drive back home
  491. # [13:11] * Joins: Peter` (~peter@170-116.citynet.ftth.internl.net)
  492. # [13:11] * Joins: jmb (~jmb@login.ecs.soton.ac.uk)
  493. # [13:17] * Quits: othermaciej (~mjs@c-69-181-42-237.hsd1.ca.comcast.net) (Quit: othermaciej)
  494. # [13:22] <annevk> MikeSmith, outline-offset
  495. # [13:22] <annevk> iirc
  496. # [13:22] * Quits: workmad3 (~workmad3@84.88.33.150) (Remote host closed the connection)
  497. # [13:25] <karlcow> for what is worth, more and more RFPs, we receive at the Web agency for the last 3 months contain sentences such as "We want the website compatible html5" or "requirements: html 5 ready (iphone and ipad)"
  498. # [13:25] <karlcow> people associate html5 with iphone and ipad.
  499. # [13:25] <karlcow> They often mean, "no flash on ipad and iphone".
  500. # [13:26] <annevk> RFP?
  501. # [13:26] <karlcow> Request For Proposal - usually the document the client sends to a few agencies for getting the best (underpriced) proposals
  502. # [13:27] * Quits: wakaba_ (~wakaba_@122x221x184x68.ap122.ftth.ucom.ne.jp) (Quit: Leaving...)
  503. # [13:29] <MikeSmith> karlcow: interesting.. seems in line with comment in that article about the "Apple effect"
  504. # [13:30] <MikeSmith> annevk: thanks, yeah, outline-offset is what I used
  505. # [13:31] <MikeSmith> file:///opt/workspace/html5/spec-author-view/style.css
  506. # [13:31] <MikeSmith> oops
  507. # [13:31] <MikeSmith> make that http://dev.w3.org/html5/spec-author-view/style.css
  508. # [13:34] * Joins: Martijnc (~Martijnc@91.176.155.244)
  509. # [13:39] * Quits: homata (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp) (Ping timeout: 260 seconds)
  510. # [13:40] * Joins: homata (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp)
  511. # [13:40] * Quits: rolandsteiner (~rolandste@220.109.219.244) (Quit: Leaving.)
  512. # [13:47] * Joins: homata_ (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp)
  513. # [13:50] * Joins: maikmerten_ (~merten@ls5dhcp196.cs.uni-dortmund.de)
  514. # [13:50] * Quits: homata (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp) (Ping timeout: 276 seconds)
  515. # [13:51] * Quits: Martijnc (~Martijnc@91.176.155.244) (Ping timeout: 260 seconds)
  516. # [13:53] * Joins: rolandsteiner (~rolandste@220.109.219.244)
  517. # [13:54] * Quits: MikeSmith (~MikeSmith@EM114-48-25-161.pool.e-mobile.ne.jp) (Ping timeout: 260 seconds)
  518. # [13:56] * Joins: nessy (~Adium@209.52.84.50)
  519. # [13:57] * Joins: Martijnc (~Martijnc@91.176.94.58)
  520. # [13:59] <zcorpan_> seems like MikeSmith found a bug in opera
  521. # [14:01] * Joins: MikeSmith (~MikeSmith@EM114-49-135-19.pool.e-mobile.ne.jp)
  522. # [14:02] * Quits: Martijnc (~Martijnc@91.176.94.58) (Client Quit)
  523. # [14:02] * Joins: Martijnc (~Martijnc@91.176.94.58)
  524. # [14:08] * Quits: homata_ (~homata@58x158x182x50.ap58.ftth.ucom.ne.jp) (Quit: Leaving...)
  525. # [14:09] * Quits: MikeSmith (~MikeSmith@EM114-49-135-19.pool.e-mobile.ne.jp) (Ping timeout: 248 seconds)
  526. # [14:13] * Joins: nicktick (~na@unaffiliated/nicktick)
  527. # [14:23] * Quits: rolandsteiner (~rolandste@220.109.219.244) (Quit: Leaving.)
  528. # [14:23] * Joins: MikeSmith (~MikeSmith@EM114-49-130-169.pool.e-mobile.ne.jp)
  529. # [14:24] * Quits: MikeSmith (~MikeSmith@EM114-49-130-169.pool.e-mobile.ne.jp) (Client Quit)
  530. # [14:25] <karlcow> http://news.bbc.co.uk/2/hi/technology/10525509.stm
  531. # [14:25] <karlcow> "The Taiwanese smartphone maker HTC has reported a 41% sales increase for the first six months of 2010."
  532. # [14:50] * Joins: yutak_home (~kee@U017209.ppp.dion.ne.jp)
  533. # [14:51] * Joins: smaug_ (~chatzilla@209.52.84.50)
  534. # [14:56] * Joins: BlurstOfTimes (~blurstoft@168.203.117.112)
  535. # [14:58] <boblet> hsivonen: did anything come of the lint checker option idea adactio and others were desiring for the validator?
  536. # [14:59] <adactio> There's this: http://lint.brihten.com/html/
  537. # [14:59] <annevk> nobody came with a sensible list of requirements iirc
  538. # [14:59] <annevk> Sam Ruby tried to gather some, but it never really want anywhere
  539. # [14:59] <annevk> went, even
  540. # [14:59] <adactio> That URL has a sensible list of requirements.
  541. # [15:00] * Joins: aroben (~aroben@c-71-58-77-15.hsd1.pa.comcast.net)
  542. # [15:00] * Quits: aroben (~aroben@c-71-58-77-15.hsd1.pa.comcast.net) (Changing host)
  543. # [15:00] * Joins: aroben (~aroben@unaffiliated/aroben)
  544. # [15:00] <annevk> it has a few radio buttons :)
  545. # [15:01] <adactio> Those are the things that authors want.
  546. # [15:01] <annevk> but sure, you can derive something from that, but is that what everyone wants?
  547. # [15:01] <adactio> It's what 99% of authors want.
  548. # [15:01] <annevk> for instance the TAG and these polyglot people want XML-compatibility, that's not really important?
  549. # [15:01] <adactio> Nope, not for a lint tool. Completely different use case.
  550. # [15:01] <adactio> A lint tool is purely about writing style.
  551. # [15:02] <adactio> It has nothing to do with parsing.
  552. # [15:02] <annevk> sure it does, you can enforce a writing style that ensures that parsing later does not result in surprises
  553. # [15:02] <adactio> That's what I kept trying to get across (to Henri, to Sam, etc.) but the talk would always keep coming back to polyglot documents ...which is something completely different.
  554. # [15:03] <adactio> you *can* enforce a writing style for polyglot documents but that's not why 99% of authors have a writing style.
  555. # [15:03] <annevk> agreed
  556. # [15:04] <annevk> I wonder if we created a wiki page for this
  557. # [15:04] <adactio> You're focusing on the 1% use case: attempting to derive a "safe" writing style for polyglot documents when 99% of the time, all people want is as simple as "tell me if I forget to quote an attribute."
  558. # [15:05] <annevk> I'm not, I'm just the messenger
  559. # [15:06] <annevk> I'm trying to explain where it stopped last time
  560. # [15:08] <annevk> http://intertwingly.net/blog/2009/09/08/First-Polyglot-Validator-Check-Deployed
  561. # [15:08] <annevk> I guess "Polyglot" should just be dropped and "Pedagogical" be turned into a bunch of lint checking options
  562. # [15:09] <annevk> I'd like a validator that tell me whether I'm using tabs rather than spaces :)
  563. # [15:09] <adactio> Right. I think the term "polyglot" is guaranteed to derail any discussion of lint tools. "Pedagogical" works for me.
  564. # [15:11] * Joins: miketaylr (~miketaylr@38.117.156.163)
  565. # [15:12] * Joins: jcranmer (~jcranmer@asimov.csl.tjhsst.edu)
  566. # [15:13] * Quits: nielsle (~nielsle@1503032406.dhcp.dbnet.dk) (Ping timeout: 260 seconds)
  567. # [15:15] * Joins: jcranmer_ (~jcranmer@asimov.csl.tjhsst.edu)
  568. # [15:15] * Philip` thinks "lint" is much easier to spell and pronounce than "pedagogical", and doesn't look like it could be a rude word
  569. # [15:15] * Joins: nielsle (~nielsle@1503032406.dhcp.dbnet.dk)
  570. # [15:15] <annevk> http://wiki.whatwg.org/wiki/HTML_Lint_Checking
  571. # [15:16] * Joins: KaOSoFt (~maxzagato@unaffiliated/kaosoft)
  572. # [15:16] * Joins: jwm_ (jwm@dev.dist.us)
  573. # [15:17] * Quits: jcranmer (~jcranmer@asimov.csl.tjhsst.edu) (Quit: leaving)
  574. # [15:17] * Quits: zcorpan_ (~zcorpan@pat.se.opera.com) (Quit: zcorpan_)
  575. # [15:17] * Quits: drunknbass (~drunknbas@76.91.255.83) (*.net *.split)
  576. # [15:17] * Quits: jwm (jwm@dev.dist.us) (*.net *.split)
  577. # [15:18] * jcranmer_ is now known as jcranmer
  578. # [15:19] * Joins: MikeSmith (~MikeSmith@EM114-48-210-223.pool.e-mobile.ne.jp)
  579. # [15:38] * Joins: workmad3 (~workmad3@84.88.33.150)
  580. # [15:40] * Joins: kennyluck (~kennyluck@EM111-188-129-158.pool.e-mobile.ne.jp)
  581. # [15:44] * Quits: davidhund (~davidhund@78-27-27-74.dsl.alice.nl) (Quit: davidhund)
  582. # [15:50] * Joins: smaug__ (~chatzilla@209.52.84.50)
  583. # [15:50] * Quits: smaug_ (~chatzilla@209.52.84.50) (Read error: Connection reset by peer)
  584. # [15:59] * Quits: MikeSmith (~MikeSmith@EM114-48-210-223.pool.e-mobile.ne.jp) (Ping timeout: 240 seconds)
  585. # [16:04] * Quits: eighty4 (~eighty4@h-112-7.A163.corp.bahnhof.se) (Remote host closed the connection)
  586. # [16:05] <hsivonen> boblet: no, and I'm not sure who dropped the ball
  587. # [16:06] * Joins: MikeSmith (~MikeSmith@EM111-188-17-52.pool.e-mobile.ne.jp)
  588. # [16:07] * Quits: smaug__ (~chatzilla@209.52.84.50) (Ping timeout: 248 seconds)
  589. # [16:07] <boblet> hsivonen: I’m imagining the ppl who would like that function are hoping the legions of crack programmers maintaining validator.nu are on it ;-)
  590. # [16:07] <boblet> …blame MikeSmith ?
  591. # [16:08] * Joins: davidb (~davidb@209.52.84.50)
  592. # [16:08] <MikeSmith> boblet: what function?
  593. # [16:08] <hsivonen> boblet: I thinkI said I wouldn't do it right away but Sam's patches would be welcome
  594. # [16:08] <boblet> [9:56pm] boblet: hsivonen: did anything come of the lint checker option idea adactio and others were desiring for the validator?
  595. # [16:09] <boblet> adactio: woah completely missed your reply, orz
  596. # [16:09] <hsivonen> boblet: and Sam made it clear that he'd only work on it if zeldman and tantek were precise about what they wanted
  597. # [16:10] <boblet> hsivonen: so “just like validator.nu, but more anal” isn’t accurate enough? hrm
  598. # [16:11] <adactio> hsivonen: I don't think it necessarily needs to be incorporated into the validator. I'm quite happy having my lint tool at http://lint.brihten.com/html/ as long as it also pipes documents through the validator.
  599. # [16:11] <hsivonen> I'm at the same conference as tantek, so maybe I can ask him wha happened if I find him
  600. # [16:11] <boblet> I could have a crack but I’m sure I wouldn’t do as precise a job as t would
  601. # [16:11] * Quits: workmad3 (~workmad3@84.88.33.150) (Remote host closed the connection)
  602. # [16:11] <boblet> hsivonen: please do. I might email him too (something else I wanted to ask about and he hasn’t been in IRC much recently)
  603. # [16:12] <adactio> I propose a version of Godwin's law whereby, in a discussion of what should be in a lint tool, any mention of "polyglot" invalidates the discussion.
  604. # [16:13] * Joins: MikeSmithX (~MikeSmith@EM114-48-123-185.pool.e-mobile.ne.jp)
  605. # [16:14] <boblet> adactio: if validator.nu offered that feature it’d be a good thing tho, esp. if it then gets rolled into validator.w3.org
  606. # [16:14] <Philip`> hsivonen: Would you be reluctant to add link-checking features that were incompatible with high-performance parsing (e.g. having the tokenizer store extra data about tokens), and that would either cause performance regressions or add significant complexity or require code forks?
  607. # [16:15] * Philip` is wondering whether validator.nu could do everything by itself, or if it needs a completely separate lint-checking layer
  608. # [16:15] <Philip`> s/link-checking/lint-checking/
  609. # [16:15] <boblet> adactio: actually would you have the time to whip up a precise list of stuff you’d like?
  610. # [16:15] <adactio> boblet: I agree. But every effort to get a discussion about lint tools into validator.nu inevitably gets hijacked by polyglot fans. So, at this stage, I think things will move faster somewhere else.
  611. # [16:15] <adactio> bobet: The radio buttons here are my list: http://lint.brihten.com/html/
  612. # [16:16] * Quits: MikeSmith (~MikeSmith@EM111-188-17-52.pool.e-mobile.ne.jp) (Ping timeout: 240 seconds)
  613. # [16:16] <adactio> boblet: in fact, I'd leave off the "misc" category myself. The other 6 things are it, really.
  614. # [16:16] <annevk> I put them here: http://wiki.whatwg.org/wiki/HTML_Lint_Checking
  615. # [16:16] * Quits: bobchao (~cctw@209.52.84.50) (Quit: Leaving.)
  616. # [16:16] <annevk> so other people can add/subtract
  617. # [16:17] <adactio> annevk: Thanks.
  618. # [16:17] * Quits: nessy (~Adium@209.52.84.50) (Quit: Leaving.)
  619. # [16:17] <adactio> It might be good to have a *separate* place to discuss the creation of polyglot conformance checker (to make it clear that they are separate use cases).
  620. # [16:17] <Philip`> adactio: That hijacking seems inevitable if you ask people to justify their demands, since the justification given for most syntax requirements is "I want to be able to parse pages as XML", so I guess we need to stop asking people why they want to check the things they say they want to check
  621. # [16:18] <boblet> just read the earlier conversation (polyglot vs pedagogical/lint) and now know what everyone’s talking about (was in skype mtng)
  622. # [16:18] * Quits: weinig (~weinig@c-69-181-125-223.hsd1.ca.comcast.net) (Quit: weinig)
  623. # [16:18] <adactio> Philip: I don't think there needs to be any justification required for a lint tool. Isn't the whole point of, for example, a coding style in a programming language, that it's basically personal preference?
  624. # [16:19] <adactio> Philip: so yes, I agree: no need to ask "why?"
  625. # [16:20] <boblet> Philip`: also it’s intended more for the silent majority
  626. # [16:20] * Quits: davidb (~davidb@209.52.84.50) (Quit: davidb)
  627. # [16:22] <Philip`> adactio: Yeah, I don't think we do need to have justification - it won't be a coherent set of rules derived logically from a precise high-level goal, but it'll satisfy people and it'll lead them towards less ugly markup
  628. # [16:22] <adactio> Yup.
  629. # [16:23] <boblet> hsivonen: so if we have a list of desired features, would it be possible to get them incorporated into validator.nu? or still the same low priority status issue?
  630. # [16:23] <hsivonen> Philip`: I'm planning on adding an API for listening to tokenizer state transitions for source highlighting use. Time will tell if it becomes useful for linting, too.
  631. # [16:23] <Philip`> Perhaps the best way to justify the set of rules is to implement everything that's suggested, measure how many people use them, then remove the ones that aren't worth the code/UI complexity they add
  632. # [16:24] <hsivonen> Philip`: I have plans to strip the code out for other use cases
  633. # [16:24] <hsivonen> the readability of the tokenizer source is going to suffer a bit
  634. # [16:26] <hsivonen> I consider it a step forward that the lint discussion is being detached from the polyglot discussion
  635. # [16:27] <hsivonen> but I don't know if all the people who want a 'lint' want at all the same thing
  636. # [16:29] <boblet> hsivonen: if asking what ppl want invokes the specter of polygot and lint.brihten.com is a working example of what ppl want, implementing those 6 things as adactio suggests then asking questions second would be great
  637. # [16:32] <Philip`> hsivonen: Would the API be sufficient for e.g. allowing <input ... disabled> but not allowing <img ... alt> (and probably not <embed ... disabled>) (i.e. context-dependent valueless attributes)?
  638. # [16:34] * Joins: gonemad3 (~workmad3@84.88.33.150)
  639. # [16:34] <Philip`> (I would guess the normal relatively-clean tokenizer/tree constructor separation might make it hard when you want to do checks that cross both layers)
  640. # [16:34] * Quits: gonemad3 (~workmad3@84.88.33.150) (Remote host closed the connection)
  641. # [16:36] <Philip`> (...but I don't know enough about the implementations to do more than guess)
  642. # [16:36] <boblet> nn
  643. # [16:38] * Joins: gonemad3 (~workmad3@84.88.33.150)
  644. # [16:40] * Quits: boblet (~boblet@p1201-ipbf709osakakita.osaka.ocn.ne.jp) (Quit: boblet)
  645. # [16:41] * Joins: justicefries (~gerred@c-98-245-71-126.hsd1.co.comcast.net)
  646. # [16:41] * Quits: justicefries (~gerred@c-98-245-71-126.hsd1.co.comcast.net) (Client Quit)
  647. # [16:43] * Joins: nessy (~Adium@209.52.84.50)
  648. # [16:44] * Quits: gonemad3 (~workmad3@84.88.33.150) (Read error: Connection reset by peer)
  649. # [16:44] * Joins: gonemad3 (~workmad3@84.88.33.150)
  650. # [16:49] * Quits: maikmerten_ (~merten@ls5dhcp196.cs.uni-dortmund.de) (Quit: Verlassend)
  651. # [16:53] * Joins: Caius_ (~workmad3@84.88.33.150)
  652. # [16:53] * Joins: weinig (~weinig@17.246.18.173)
  653. # [16:54] * Quits: gonemad3 (~workmad3@84.88.33.150) (Read error: Connection reset by peer)
  654. # [16:54] * Quits: nessy (~Adium@209.52.84.50) (Quit: Leaving.)
  655. # [16:55] * Joins: bobchao (~cctw@209.52.84.51)
  656. # [16:57] * Joins: smaug_ (~chatzilla@209.52.84.51)
  657. # [16:59] * Quits: nicktick (~na@unaffiliated/nicktick) (Ping timeout: 276 seconds)
  658. # [17:01] <adactio> So here's something that been bothering me: should a user agent prevent a form being submitted if one field is suffering a type mismatch *even if that field is not required*?
  659. # [17:01] <adactio> Test cases here:
  660. # [17:01] <adactio> http://andyhume.net/testing/forms.html
  661. # [17:02] <annevk> yes
  662. # [17:02] <adactio> In the 2nd and 3rd examples, the form can be submitted if the url or email field is empty but not if the url or email field has an invalid value.
  663. # [17:02] <adactio> That's awful!
  664. # [17:02] <annevk> that's the whole point of form validation
  665. # [17:02] * Quits: Maurice (~ano@a80-101-46-164.adsl.xs4all.nl) (Quit: Disconnected...)
  666. # [17:03] <adactio> No, the whole point of form validation is to allow you (the author) to decide what to do in the case of type mismatch.
  667. # [17:04] <adactio> For the user-agent to automatically cancel the submission of a form when a non-required field suffers from a type mismatch is the browser equivalent of the "nanny state".
  668. # [17:04] <annevk> in the simple case you want submission to be prevented because otherwise the server will have to complain and it costs the user (and you) a roundtrip
  669. # [17:05] * Quits: Caius_ (~workmad3@84.88.33.150) (Remote host closed the connection)
  670. # [17:05] <annevk> there may be more complex cases, but those are not (yet) addressed
  671. # [17:05] <adactio> The server will have to complain if it's a required field. Otherwise, no.
  672. # [17:05] * Quits: bobchao (~cctw@209.52.84.51) (Ping timeout: 248 seconds)
  673. # [17:05] <annevk> though you can do something via scripting for sure
  674. # [17:05] <annevk> adactio, there's more use cases than the one you are interested in :)
  675. # [17:05] <annevk> there're grmbl
  676. # [17:06] <hober> If a field is optional, but has validation constraints, then those validation constraints should be enforced if the element has a non-"" value
  677. # [17:06] <adactio> annevk: the use cases I'm talking about came from other people ...who are now changing everything back to input type="text" to avoid webkit's over-zealous behaviour with type mismatches.
  678. # [17:07] <hober> essentially, putting validation constraints on an optional field means "we accept empty xor *like this*"
  679. # [17:07] <annevk> adactio, well yes, WebKit has a stupid non-UI implementation
  680. # [17:07] <annevk> adactio, that's not the fault of the specification, but of WebKit for shipping something broken
  681. # [17:08] <adactio> It's not about the UI.
  682. # [17:09] <annevk> in Opera it is clear why the form is not submitted
  683. # [17:09] <Philip`> Why would you put validation constraints on a non-required field if you don't want the value to be validated against those constraints?
  684. # [17:09] <adactio> I find Opera's behaviour equally wrong *as long as the field is not required*.
  685. # [17:09] <adactio> semantics
  686. # [17:09] <annevk> I don't see how required is more important than valid
  687. # [17:10] <annevk> should it be submitted if it's required and invalid?
  688. # [17:10] <annevk> i guess not per your reasoning, but that would make even less sense then
  689. # [17:10] <hober> required means "this element must have a non-'' value"
  690. # [17:10] <hober> which is orthogonal to value constraints
  691. # [17:11] * Joins: nessy (~Adium@209.52.84.51)
  692. # [17:16] * Joins: Heimidal (~heimidal@unaffiliated/heimidal)
  693. # [17:16] * weinig is now known as weinig|away
  694. # [17:21] * Quits: nessy (~Adium@209.52.84.51) (Quit: Leaving.)
  695. # [17:24] * Quits: Heimidal (~heimidal@unaffiliated/heimidal) (Remote host closed the connection)
  696. # [17:25] * Joins: ZombieLoffe (~e@unaffiliated/zombieloffe)
  697. # [17:26] * Joins: bobchao (~cctw@209.52.84.51)
  698. # [17:28] * Joins: nessy (~Adium@209.52.84.51)
  699. # [17:35] * Quits: bobchao (~cctw@209.52.84.51) (Read error: Connection reset by peer)
  700. # [17:37] * Quits: Lachy (~Lachlan@pat-tdc.opera.com) (Quit: This computer has gone to sleep)
  701. # [17:38] * Joins: bobchao (~cctw@209.52.84.51)
  702. # [17:43] * Quits: KaOSoFt (~maxzagato@unaffiliated/kaosoft)
  703. # [17:46] * Quits: pauld (~chatzilla@194.102.13.2) (Ping timeout: 265 seconds)
  704. # [17:52] * Joins: davidb (~davidb@209.52.84.51)
  705. # [17:52] * weinig|away is now known as weinig
  706. # [17:53] * Quits: davidb (~davidb@209.52.84.51) (Client Quit)
  707. # [17:57] * Quits: svl (~me@ip565744a7.direct-adsl.nl) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
  708. # [18:02] * Joins: fishd (~fishd@nat/google/x-ltqdfxkqdauqgzru)
  709. # [18:04] * Joins: TabAtkins_ (~tabatkins@nat/google/x-yrwselsfefeyropp)
  710. # [18:12] * Joins: Maurice (copyman@5ED573FA.cable.ziggo.nl)
  711. # [18:15] * Joins: pauld (~chatzilla@194.102.13.2)
  712. # [18:18] * Joins: estellevw (~estellevw@adsl-99-170-149-16.dsl.pltn13.sbcglobal.net)
  713. # [18:26] * Joins: nimbupani (~nimbupani@c-24-22-131-46.hsd1.wa.comcast.net)
  714. # [18:31] * Quits: Phae (~Phae@gatekeeper.macmillan.co.uk) (Quit: Leaving.)
  715. # [18:31] * Quits: pesla (~pesla@188.202.125.121) (Quit: kthxbye!)
  716. # [18:38] * Quits: nessy (~Adium@209.52.84.51) (Quit: Leaving.)
  717. # [18:38] * Joins: nessy (~Adium@209.52.84.51)
  718. # [18:38] * Joins: othermaciej (~mjs@c-69-181-42-237.hsd1.ca.comcast.net)
  719. # [18:39] * Quits: smaug_ (~chatzilla@209.52.84.51) (Ping timeout: 252 seconds)
  720. # [18:49] * Quits: bobchao (~cctw@209.52.84.51) (Quit: Leaving.)
  721. # [18:53] * Quits: estellevw (~estellevw@adsl-99-170-149-16.dsl.pltn13.sbcglobal.net) (Quit: estellevw)
  722. # [18:55] * Joins: JonathanNeal (~JonathanN@rrcs-76-79-114-210.west.biz.rr.com)
  723. # [18:56] * Quits: othermaciej (~mjs@c-69-181-42-237.hsd1.ca.comcast.net) (Quit: othermaciej)
  724. # [18:59] * Quits: roc (~roc@209.52.84.50) (Quit: roc)
  725. # [19:04] * Quits: akamike (~akamike@94-193-106-14.zone7.bethere.co.uk) (Quit: akamike)
  726. # [19:08] * Joins: estellevw (~estellevw@adsl-99-170-149-16.dsl.pltn13.sbcglobal.net)
  727. # [19:12] * Quits: Necrathex (~bleptop@212-123-163-12.ip.telfort.nl) (Quit: Necrathex)
  728. # [19:13] * Joins: justicefries (~gerred@c-98-245-71-126.hsd1.co.comcast.net)
  729. # [19:15] <karlushi> I wonder if anyone has evaluated when Chrome will start flirting with firefox http://en.wikipedia.org/wiki/File:Usage_share_of_alternative_web_browsers.svg
  730. # [19:16] <karlushi> 2012?
  731. # [19:18] * Quits: nessy (~Adium@209.52.84.51) (Quit: Leaving.)
  732. # [19:21] * Joins: deepthawtz (~deepthawt@c-24-130-129-16.hsd1.ca.comcast.net)
  733. # [19:24] * Quits: justicefries (~gerred@c-98-245-71-126.hsd1.co.comcast.net) (Quit: justicefries)
  734. # [19:24] <TabAtkins> adactio: Webkit's behavior (assuming they hook up actual UI to it, dammit) is precisely what I would expect, for precisely the reason hober outlined - if I say something is non-required but has a pattern, I expect it to mean "empty, or matching this pattern".
  735. # [19:25] <TabAtkins> adactio: If I'm reading what you want right, it would make the various pattern attributes entirely useless on a non-required field.
  736. # [19:25] <TabAtkins> AryehGregor: I'
  737. # [19:25] <TabAtkins> AryehGregor: I'm not the most useful twitterer. I'm curious as to what in specific that I post if making you glad you're avoiding twitter, though?
  738. # [19:26] * jwm_ is now known as jwm
  739. # [19:27] * TabAtkins forgot that his tweets turn into buzzes anyway - he only uses the google-internal buzz.
  740. # [19:28] * Joins: dglazkov (~dglazkov@nat/google/x-ztlpbevqejeyoszn)
  741. # [19:28] * Joins: nessy (~Adium@209.52.84.51)
  742. # [19:31] * Joins: jlebar (~jlebar@209.52.84.51)
  743. # [19:31] * Quits: nessy (~Adium@209.52.84.51) (Client Quit)
  744. # [19:32] * Joins: Lachy (~Lachlan@cm-84.215.59.50.getinternet.no)
  745. # [19:36] * Quits: mhausenblas (~mhausenbl@wg1-nat.fwgal01.deri.ie) (Read error: Connection reset by peer)
  746. # [19:37] * Joins: mhausenblas (~mhausenbl@wg1-nat.fwgal01.deri.ie)
  747. # [19:38] * Joins: davidb (~davidb@209.52.84.51)
  748. # [19:41] * Quits: davidb (~davidb@209.52.84.51) (Client Quit)
  749. # [19:43] * Quits: zalan (~zalan@catv-89-135-140-7.catv.broadband.hu)
  750. # [19:44] <JonathanNeal> Is it acceptable to make a label on an input be hidden accessible?
  751. # [19:45] * Joins: hamcore (rhythm@unaffiliated/msmosso)
  752. # [19:47] * Quits: jlebar (~jlebar@209.52.84.51) (Ping timeout: 276 seconds)
  753. # [19:48] * Joins: eighty4 (~eighty4@c-76c8e455.012-403-6c6b701.cust.bredbandsbolaget.se)
  754. # [19:49] * Joins: jlebar (~jlebar@209.52.84.51)
  755. # [19:50] <TabAtkins> JonathanNeal: I don't understand the question - the last part of the sentence doesn't parse.
  756. # [19:52] <JonathanNeal> Sure, let me see if I can describe it.
  757. # [19:53] <JonathanNeal> <span class="field-content"><label class="hidden-accessible" for="someInput">Some Input</label><input id="someInput" type="text" /></span>
  758. # [19:53] <JonathanNeal> Where .hidden-accessible is visually implied, but there is a textual fallback.
  759. # [19:53] <JonathanNeal> it's hidden, but there's a text label for screen readers.
  760. # [19:54] <TabAtkins> Oh, okay.
  761. # [19:54] <TabAtkins> Then, yes? That's just standard accessibility stuff.
  762. # [19:54] <JonathanNeal> Okay, I wasn't sure if there were different rules for <label>s.
  763. # [19:55] * Quits: jlebar (~jlebar@209.52.84.51) (Ping timeout: 276 seconds)
  764. # [19:56] <TabAtkins> Only insofar as radio buttons by themselves are sorta hard to click or whatever, so having a label is good to make it more clickable. But if you're doing other stuff to make it clickable and the label isn't otherwise necessary, then sure, yeah, hide it visually but make it accessible.
  765. # [19:58] * Quits: mhausenblas (~mhausenbl@wg1-nat.fwgal01.deri.ie) (Quit: mhausenblas)
  766. # [19:58] <JonathanNeal> Would you know if "aria-hidden" should be read by screen readers?
  767. # [19:59] <TabAtkins> No clue. It sounds like maybe not, though. If you want it accessible, then it shouldn't be denoted as "hidden".
  768. # [19:59] <TabAtkins> (Presumably hidden things shouldn't be looked at.)
  769. # [19:59] <TabAtkins> I don't think you have to do anything with aria at all here. Just do the standard abspos hack.
  770. # [20:01] * Quits: weinig (~weinig@17.246.18.173) (Quit: weinig)
  771. # [20:01] <JonathanNeal> Fair enough, I wasn't sure if there was a hidden accessible type-of-role for it.
  772. # [20:01] <JonathanNeal> Thanks.
  773. # [20:09] * Quits: pauld (~chatzilla@194.102.13.2) (Remote host closed the connection)
  774. # [20:12] <JonathanNeal> So what was confusing about my question, the phrase "hidden accesible"?
  775. # [20:13] <TabAtkins> Yeah - I wasn't able to parse that as a single word.
  776. # [20:13] <TabAtkins> s/word/phrase/
  777. # [20:13] <TabAtkins> or whatever
  778. # [20:19] * Quits: dimich (~dimich@nat/google/x-jiusjbsoxmwgymyh) (Quit: dimich)
  779. # [20:20] <JonathanNeal> Is there a better word / phrase I could have used?
  780. # [20:21] <TabAtkins> "Is it acceptable to make a label on an input be visually hidden but still accessible?"
  781. # [20:21] <TabAtkins> "hidden accessible" sounded to me like it was accessible to hidden things. ^_^
  782. # [20:21] * Quits: nimbupani (~nimbupani@c-24-22-131-46.hsd1.wa.comcast.net) (Quit: nimbupani)
  783. # [20:23] <Hixie> how can something be accessible if it's hidden?
  784. # [20:23] <TabAtkins> "hidden" = "absposed off the left screen edge"
  785. # [20:23] <TabAtkins> So visually hidden, but not hidden from screenreaders and such.
  786. # [20:24] <Hixie> well if it's off the screen edge, i ain't gonna be able to access it
  787. # [20:24] * Quits: fwaokda (~fwaokda@adsl-157-18-210.jan.bellsouth.net) (Ping timeout: 240 seconds)
  788. # [20:24] <Hixie> so it doesn't seem accessible
  789. # [20:24] * Quits: onar (~onar@2620:0:1b00:16f2:21f:5bff:fe3e:944) (Quit: onar)
  790. # [20:24] <TabAtkins> ?_?
  791. # [20:24] <Hixie> something that's only accessible to screen readers isn't accessible
  792. # [20:24] <Hixie> it's just limited to screen reader users
  793. # [20:24] <TabAtkins> Yes, you won't be able to access it if you're using a normal browser. That's the point.
  794. # [20:24] <TabAtkins> It's like that on purpose.
  795. # [20:25] <Hixie> seems weird to call that "accessible"
  796. # [20:25] <Hixie> since it's the opposite of accessible
  797. # [20:25] <Hixie> it's like something that's only visible to screen users
  798. # [20:25] <TabAtkins> Eh, that's common usage. "accessible" means "still usable by someone using something other than a normal browser".
  799. # [20:25] <TabAtkins> In the common webdev-hack parlance.
  800. # [20:25] <Hixie> "accessible" means "usable by everyone"
  801. # [20:25] <TabAtkins> If it's usable by a normal browser you dont' have to use a word for it at all. ^_^
  802. # [20:25] <Workshiva> We have always been at work with alt text
  803. # [20:26] <Hixie> alt text is an example of this... the alt text isn't accessible, nor is the png file, it's the <img> that becomes accessible when you provide both the image file and the alt text
  804. # [20:27] <TabAtkins> Correct. And? This is a different issue entirely.
  805. # [20:27] <TabAtkins> (Are you just arguing about the use of the term?)
  806. # [20:27] <Hixie> yes
  807. # [20:27] <JonathanNeal> The idea is that implicit visual functionality is lost to non visual users.
  808. # [20:27] <TabAtkins> Ah, then shrug. Like I said, that usage is common in webdev-hack parlance.
  809. # [20:28] <JonathanNeal> Like certain calendar input fields, or a "skip to main content" link.
  810. # [20:28] <Hixie> i think a big part of the problem with making context universally accessible is the view point that the visual presentation is somehow privileged
  811. # [20:28] <JonathanNeal> So, I was using the phrase "hidden accessible" to describe how it is hidden to the visual user who would not need the additional accessibility.
  812. # [20:28] * Joins: fwaokda (~fwaokda@adsl-19-160-111.jan.bellsouth.net)
  813. # [20:29] <Hixie> referring to things that aren't visible as "accessible" is a symptom of that viewpoint imho
  814. # [20:29] <TabAtkins> If it's just a symptom, then changing it won't affect anything. ^_^
  815. # [20:29] <JonathanNeal> Hixie, the visual presentation is privileged, communication happens in more ways than just text.
  816. # [20:30] <Hixie> "the audio presentation is privileged, communication happens in more ways than just text" is equally true
  817. # [20:30] <TabAtkins> But yeah, since most people (and especially most devs) have working vision and motor skills, there is indeed a privileged presentation in practice.
  818. # [20:30] <JonathanNeal> That's why alt exists, because the visual presentation is privileged to show you a picture of a kitten without necessarily having to textually describe it for you.
  819. # [20:31] <JonathanNeal> Hixie, yes, this is true, the audio presentation is privileged.
  820. # [20:32] <Hixie> my point is that the right way to think about this is to view the markup as media-independant, so that no medium is privileged.
  821. # [20:32] <Hixie> crap, i gotta go, meeting
  822. # [20:32] * Hixie hastily climbs off his soapbox and packs it away
  823. # [20:32] <Hixie> later
  824. # [20:32] <JonathanNeal> Later.
  825. # [20:32] <TabAtkins> Hixie: So you're missing the point of the hack itself anyway, which is to make a media-independent markup and then visually hide the bits that the visual presentation doesn't need.
  826. # [20:32] <JonathanNeal> So, hidden accessible maybe isn't the best term.
  827. # [20:33] <JonathanNeal> non-presentational
  828. # [20:34] <TabAtkins> Just say "visually hidden, but still otherwise accessible", like I said. That captures the intent exactly, and Hixie's just overreacting.
  829. # [20:34] <TabAtkins> Or rather, he's reacting to something else that he mistakenly thinks you're saying.
  830. # [20:34] * Joins: justicefries (~gerred@c-98-245-71-126.hsd1.co.comcast.net)
  831. # [20:36] * Joins: mdelaney (~mdelaney@2620:0:1b00:1191:d69a:20ff:febf:89a0)
  832. # [20:36] * Joins: smaug_ (~chatzilla@209.52.84.50)
  833. # [20:36] * Joins: seanoshea (~seanoshea@nat217.eye.fi)
  834. # [20:40] <JonathanNeal> okay, so when I say hidden accessible what I mean to say is "visually HIDDEN but still otherwise ACCESSIBLE"
  835. # [20:41] * Joins: jlebar (~jlebar@209.52.84.51)
  836. # [20:43] * Joins: othermaciej (~mjs@17.246.19.79)
  837. # [20:45] * Joins: weinig (~weinig@17.246.18.173)
  838. # [20:45] * Joins: nessy (~Adium@209.52.84.51)
  839. # [20:46] * Parts: adactio (~adactio@host213-123-197-180.in-addr.btopenworld.com)
  840. # [20:47] * Quits: justicefries (~gerred@c-98-245-71-126.hsd1.co.comcast.net) (Ping timeout: 245 seconds)
  841. # [20:49] * Quits: estellevw (~estellevw@adsl-99-170-149-16.dsl.pltn13.sbcglobal.net) (Quit: estellevw)
  842. # [20:50] * Joins: estellevw (~estellevw@adsl-99-170-149-16.dsl.pltn13.sbcglobal.net)
  843. # [20:51] * Joins: justicefries (~gerred@c-98-245-71-126.hsd1.co.comcast.net)
  844. # [20:51] * Quits: seanoshea (~seanoshea@nat217.eye.fi) (Ping timeout: 276 seconds)
  845. # [20:54] * Joins: ttepasse (~ttepasse@ip-109-90-160-217.unitymediagroup.de)
  846. # [20:58] * Quits: smaug_ (~chatzilla@209.52.84.50) (Ping timeout: 260 seconds)
  847. # [20:58] * Quits: nessy (~Adium@209.52.84.51) (Quit: Leaving.)
  848. # [21:00] * Joins: seanoshea (~seanoshea@nat217.eye.fi)
  849. # [21:05] * Quits: JonathanNeal (~JonathanN@rrcs-76-79-114-210.west.biz.rr.com) (Read error: Connection reset by peer)
  850. # [21:06] * Quits: weinig (~weinig@17.246.18.173) (Quit: weinig)
  851. # [21:06] * Joins: JonathanNeal (~JonathanN@rrcs-76-79-114-210.west.biz.rr.com)
  852. # [21:09] * Quits: jlebar (~jlebar@209.52.84.51) (Ping timeout: 240 seconds)
  853. # [21:10] * Quits: mdelaney (~mdelaney@2620:0:1b00:1191:d69a:20ff:febf:89a0) (Quit: mdelaney)
  854. # [21:10] * Quits: kennyluck (~kennyluck@EM111-188-129-158.pool.e-mobile.ne.jp) (Ping timeout: 240 seconds)
  855. # [21:13] <AryehGregor> TabAtkins, I'm sure they're fine, as far as tweets go. But nearly all of them are just random unconnected thoughts that at *best* are only very mildly interesting to me.
  856. # [21:13] * Joins: mdelaney (~mdelaney@2620:0:1b00:1191:d69a:20ff:febf:89a0)
  857. # [21:13] <AryehGregor> I think my remark was triggered by "OMIGOD FRESH BREAD OMNOMNOMNOMNOM".
  858. # [21:13] <AryehGregor> I guess maybe it's good if you want to know what the tweeter is thinking about, or somesuch.
  859. # [21:15] <TabAtkins> AryehGregor: That is, indeed, largely what tweeting is about.
  860. # [21:16] <TabAtkins> Also, that sort of thing would normally just go to my facebook, but I posted it from my phone, which by default pushes stuff to both fb and twitter.
  861. # [21:17] * Quits: justicefries (~gerred@c-98-245-71-126.hsd1.co.comcast.net) (Ping timeout: 260 seconds)
  862. # [21:17] * AryehGregor is reminded of why he isn't on Facebook too, then.
  863. # [21:17] <TabAtkins> I like the random unconnected thoughts. ^_^
  864. # [21:17] <TabAtkins> And if someone is uninteresting enough, I just unfollow or hide them.
  865. # [21:18] * TabAtkins just uses twitter for technical stuff and webcomic authors.
  866. # [21:18] * Quits: seanoshea (~seanoshea@nat217.eye.fi) (Quit: seanoshea)
  867. # [21:20] * Quits: gavin_ (~gavin@firefox/developer/gavin) (Ping timeout: 276 seconds)
  868. # [21:21] <TabAtkins> AryehGregor: It also lets you know that, were you at my house, you'd be enjoying some damned fine fresh bread.
  869. # [21:22] * Joins: justicefries (~gerred@c-98-245-71-126.hsd1.co.comcast.net)
  870. # [21:25] * Joins: gavin_ (~gavin@firefox/developer/gavin)
  871. # [21:26] <gsnedders> TabAtkins: Then why on earth do you follow me? :P
  872. # [21:27] <TabAtkins> gsnedders: Good question. ^_^
  873. # [21:27] * Joins: TelFiRE (~TelFiRE@c-24-10-155-57.hsd1.ut.comcast.net)
  874. # [21:27] <TabAtkins> Nah, I *read* twitter for more than technical stuff, and you're high enough on my list of "internet friends" to be followable.
  875. # [21:28] * gsnedders still doesn't get why so many people read his shit
  876. # [21:28] <TabAtkins> You don't post enough to be annoying, is why.
  877. # [21:28] * Joins: davidb (~davidb@209.52.84.51)
  878. # [21:30] * Joins: smaug_ (~chatzilla@209.52.84.51)
  879. # [21:31] * Joins: jgornick (~joe@199.199.212.242)
  880. # [21:32] * Joins: bobchao (~cctw@209.52.84.50)
  881. # [21:38] * Joins: Anonameless (Nameless@cm218-252-156-82.hkcable.com.hk)
  882. # [21:38] * Quits: bobchao (~cctw@209.52.84.50) (Quit: Leaving.)
  883. # [21:40] * Quits: davidb (~davidb@209.52.84.51) (Quit: davidb)
  884. # [21:41] * Joins: davidb (~davidb@209.52.84.51)
  885. # [21:43] * Joins: dandaman (~Daniel.Sa@216.52.240.243)
  886. # [21:43] <dandaman> this is a # for html5?
  887. # [21:43] <TabAtkins> Yes.
  888. # [21:43] <dandaman> is there an IDE someone can recommend?
  889. # [21:44] <dandaman> im just starting out html5 for this internship
  890. # [21:44] <dandaman> and i'd like to make the learning process as quick as possible
  891. # [21:44] <TabAtkins> I suggest a text editor. ^_^
  892. # [21:44] <AryehGregor> HTML5 is just HTML+JavaScript+CSS.
  893. # [21:44] <AryehGregor> So use whatever HTML/JS/CSS IDE you want.
  894. # [21:44] <AryehGregor> (personally I just use a text editor)
  895. # [21:45] <AryehGregor> We probably are not the best people to ask questions like this, because we're all very familiar with HTML5 and don't really need IDEs or things like that.
  896. # [21:47] * Quits: davidb (~davidb@209.52.84.51) (Quit: davidb)
  897. # [21:47] * Joins: bobchao (~cctw@209.52.84.51)
  898. # [21:48] <TabAtkins> Yeah, syntax highlighting is about all the luxury I'm used to.
  899. # [21:48] * Joins: davidb (~davidb@209.52.84.51)
  900. # [21:48] <karlushi> dandaman, what do you use usually?
  901. # [21:50] * Joins: jwalden (~waldo@209.52.84.51)
  902. # [21:52] <dandaman> i havent touched html for like 8 years, not since i was 8
  903. # [21:52] <dandaman> 13*
  904. # [21:54] <Martijnc> dandaman: I use Notepad++, not really an IDE but is has syntax highlighting
  905. # [21:55] * Quits: davidb (~davidb@209.52.84.51) (Quit: davidb)
  906. # [21:57] <AryehGregor> "This site is attempting to download multiple files. Do you want to allow this? Allow/Deny/X"
  907. # [21:57] <AryehGregor> 1) What does that actually mean? 2) Why would I want to not allow it?
  908. # [21:58] <TabAtkins> Yay for useless "security" prompts.
  909. # [21:58] <AryehGregor> (this URL in Chrome: http://www.mozilla.com/en-US/products/download.html?product=firefox-4.0b1&os=linux&lang=en-US)
  910. # [21:58] <AryehGregor> Downloads the same tar.bz2 for me twice . . .
  911. # [21:58] <TabAtkins> Doesn't for me.
  912. # [21:59] <TabAtkins> You're on dev channel, right?
  913. # [21:59] * Parts: dandaman (~Daniel.Sa@216.52.240.243)
  914. # [21:59] <AryehGregor> Yeah, on Linux.
  915. # [21:59] * AryehGregor tries reloading
  916. # [21:59] <TabAtkins> I'm on normal linux, so that sounds like a bug.
  917. # [21:59] <AryehGregor> Doesn't reproduce when I reload. Although it downloads instantly, maybe If-Modified-Since or something.
  918. # [22:00] * Quits: fishd (~fishd@nat/google/x-ltqdfxkqdauqgzru) (Quit: Leaving)
  919. # [22:01] <Martijnc> It happens when you click 'click here' and the automatic download starts
  920. # [22:01] <AryehGregor> Ah, that explains it.
  921. # [22:01] <AryehGregor> No idea what the prompt is for, though . . .
  922. # [22:03] <AryehGregor> maxlength="140" for feedback is criminal. Is this being tweeted or something?
  923. # [22:05] <AryehGregor> Wow, Firefox 4 is really much snappier.
  924. # [22:06] * Joins: weinig (~weinig@17.246.18.173)
  925. # [22:06] <AryehGregor> Also, the feedback thing misdetected some slashes as the presence of URLs and rejected the input.
  926. # [22:16] * Quits: MikeSmithX (~MikeSmith@EM114-48-123-185.pool.e-mobile.ne.jp) (Ping timeout: 265 seconds)
  927. # [22:17] * Quits: smaug_ (~chatzilla@209.52.84.51) (Ping timeout: 264 seconds)
  928. # [22:21] * Joins: MikeSmithX (~MikeSmith@EM114-48-6-78.pool.e-mobile.ne.jp)
  929. # [22:23] * Joins: ap (~ap@2620:0:1b00:1191:226:4aff:fe14:aad6)
  930. # [22:27] * Joins: smaug_ (~chatzilla@209.52.84.50)
  931. # [22:33] <hober> is <noscript> currently conforming in the draft?
  932. # [22:33] <TabAtkins> Pretty sure yes.
  933. # [22:33] * TabAtkins would have to check to be sure.
  934. # [22:33] <AryehGregor> Yes.
  935. # [22:34] <TabAtkins> Only in HTML, of course.
  936. # [22:34] <AryehGregor> There's a bug complaining about it.
  937. # [22:34] <AryehGregor> Lots of arguing, including at least one person who actually develops web pages for a living and seems to be encountering standards-purity advocates for the first time.
  938. # [22:34] <crash\> yeah <noscript> is obsolete, but we need it I think since it's widly used
  939. # [22:35] <AryehGregor> It's not really obsolete.
  940. # [22:35] <crash\> so it's good to have it standardized
  941. # [22:35] <crash\> AryehGregor: is there any use case for <noscript>?
  942. # [22:35] <crash\> I say it's easy, but scripting is better in all cases
  943. # [22:35] <AryehGregor> A page that consists of a JavaScript game, where all you want to do without script is say "You have to have JavaScript"?
  944. # [22:36] <AryehGregor> You can emulate the effect easily with script, but why bother?
  945. # [22:36] <crash\> since <noscript> has it's problems
  946. # [22:36] <AryehGregor> Like what?
  947. # [22:36] <AryehGregor> http://www.w3.org/Bugs/Public/show_bug.cgi?id=10068
  948. # [22:37] <AryehGregor> See, someone who actually writes web pages for a living: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10068#c20
  949. # [22:37] * Quits: jwalden (~waldo@209.52.84.51) (Quit: ChatZilla 0.9.86-rdmsoft [XULRunner 1.9.2.4/20100622203044])
  950. # [22:38] <crash\> it's right what he says
  951. # [22:38] <crash\> but I say it's better to do alternate content via scripting
  952. # [22:39] <crash\> AryehGregor: like <noscript> doesn't have type
  953. # [22:39] <AryehGregor> Type?
  954. # [22:39] <TabAtkins> crash\: That's not a problem in practice. If the web ever actually develops a second scripting language that people care about, then maybe.
  955. # [22:39] <AryehGregor> Oh, yeah, that kind of type. Well, it just means "execute unless there's JavaScript support".
  956. # [22:39] <AryehGregor> If you have some other language you want to test for, go ahead and use script.
  957. # [22:40] <AryehGregor> It's not a realistic issue.
  958. # [22:40] <crash\> so you can't use it when you want it only be visible if a certain scripting langauge is availble
  959. # [22:40] <AryehGregor> Sure you can, as long as that scripting language is JavaScript.
  960. # [22:40] <AryehGregor> Which is the only one anyone uses or cares about in practice, so that's fine.
  961. # [22:41] <crash\> ok, good but <noscript> doesn't cover those cases
  962. # [22:41] <TabAtkins> ...which is fine, because no one cares about those cases.
  963. # [22:41] <AryehGregor> Which nobody cares about.
  964. # [22:41] <AryehGregor> And if they did, fine, so don't use it in those cases.
  965. # [22:41] <AryehGregor> That doesn't hurt its utility in the other 99.984% of cases.
  966. # [22:41] <AryehGregor> (I'm being generous)
  967. # [22:41] <TabAtkins> And/or we'd fix it at that point.
  968. # [22:41] <AryehGregor> Unlikely, since it can be trivially emulated.
  969. # [22:42] <TabAtkins> True, but it's possible.
  970. # [22:42] <crash\> sure, it wont be a problem for most of the cases
  971. # [22:42] <crash\> but you should know that <noscript> isn't perfect
  972. # [22:43] <crash\> replacing content via scripting is
  973. # [22:43] <AryehGregor> It's also true that <noscript> will not cook pizza for me.
  974. # [22:43] <AryehGregor> Nor will replacing content by scripting.
  975. # [22:43] <AryehGregor> Ergo, neither is perfect.
  976. # [22:43] <TabAtkins> Damn those HTML designers and their lack of foresight.
  977. # [22:43] <AryehGregor> Objecting to an element on the basis that it works perfectly fine for the uses it was intended to cover but doesn't cover some other things you'd like it to cover makes no sense.
  978. # [22:44] <crash\> but it's a great advantage that HTML5 cover many of cases oldes standard didn't
  979. # [22:45] * Joins: jlebar (~jlebar@209.52.84.51)
  980. # [22:45] <crash\> and is on the other side is a standardwhich covers a lot of real-life problems
  981. # [22:46] * Philip` misreads that as standardwich, which sounds like an interesting variant on the common sandwich
  982. # [22:46] <crash\> and JavaScript has it's versions and implementations, so it might become a problem some day
  983. # [22:47] <crash\> so some day somebody may complain about <noscript>, who knows? ;)
  984. # [22:47] <TabAtkins> Philip`: You don't want a sandwich designed by a standard.
  985. # [22:47] <TabAtkins> crash\: And on that day we'll commence caring. ^_^
  986. # [22:47] <AryehGregor> crash\, so you think that people should avoid <noscript> because someday someone might complain about it?
  987. # [22:47] <AryehGregor> That's a remarkably low standard.
  988. # [22:47] <crash\> I think it should be marked deprecated, yes
  989. # [22:48] <AryehGregor> Because someone might someday complain about it, or for some other reason?
  990. # [22:48] <AryehGregor> Because I haven't seen any practical reason yet that authors shouldn't use it.
  991. # [22:48] * Joins: onar (~onar@2620:0:1b00:16f2:21f:5bff:fe3e:944)
  992. # [22:49] * Quits: ZombieLoffe (~e@unaffiliated/zombieloffe)
  993. # [22:49] * Joins: svl (~me@ip565744a7.direct-adsl.nl)
  994. # [22:51] <crash\> and one thing I forget it's not XHTML compatible ;)
  995. # [22:51] <AryehGregor> Yet another thing no one cares about in real life.
  996. # [22:51] <crash\> I think there are many people who would like to send XML
  997. # [22:52] <AryehGregor> Not relative to the number of web authors.
  998. # [22:53] * TabAtkins is, for some reason, gradually writing a library for quoting and indenting emails while respecting max-width constraints on lines.
  999. # [22:54] <AryehGregor> . . .
  1000. # [22:54] <AryehGregor> Like a plugin for a mail program, or it just works on plain text?
  1001. # [22:54] <TabAtkins> Just a few python functions for my own use on plain text.
  1002. # [22:55] <TabAtkins> When I'm quoting from a spec and indenting with |, and then later adjusting the wording and thus changing line lengths, I want an easy way to automagically readjust all the lines to respect 70-char lines while keeping the |s in proper place.
  1003. # [22:56] * Quits: ROBOd (~robod@109.96.213.23) (Quit: .)
  1004. # [22:58] <AryehGregor> E-mail indentation is annoying. Too bad no one has invented a way of doing auto-wrapping in e-mail. Maybe you could even add other features at the same time. Actually, it would make the most sense to reuse an existing format. Come to think of it, does the WHATWG work on anything that might be useful here?
  1005. # [22:58] * TabAtkins wonders if this would be easier to just write by importing the text as Markdown and then writing some html-to-plaintext functions.
  1006. # [23:01] <hober> TabAtkins: Emacs' M-q can do that, if you tell it about the |
  1007. # [23:01] <TabAtkins> Ah, yes, Markdown'll do what I need if I mod it to accept | and # as blockquoting markers as well (it's sorta a CSSWG convention to use that for spec suggestions and spec quoting, respectively).
  1008. # [23:01] <TabAtkins> hober: That'd mean I have to use emacs.
  1009. # [23:01] * Quits: miketaylr (~miketaylr@38.117.156.163) (Remote host closed the connection)
  1010. # [23:01] <hober> :)
  1011. # [23:03] * Quits: mdelaney (~mdelaney@2620:0:1b00:1191:d69a:20ff:febf:89a0) (Ping timeout: 260 seconds)
  1012. # [23:04] * Joins: davidb (~davidb@209.52.84.51)
  1013. # [23:06] * Quits: jlebar (~jlebar@209.52.84.51) (Ping timeout: 264 seconds)
  1014. # [23:07] <Hixie> JonathanNeal: different styles for different media should be done with different style sheets (or @media in a style sheet), i don't get why the AT vendors haven't gotten around to supporting that yet.
  1015. # [23:07] <gsnedders> Hmm, did ES5 really change parseInt to disallow leading "0" to mean octal when no browser will change? Great!
  1016. # [23:08] <JonathanNeal> Hi Hixie
  1017. # [23:08] <JonathanNeal> Are you referring to my hidden accessible issue?
  1018. # [23:09] <Hixie> JonathanNeal: i was just continuing our earlier conversation :-)
  1019. # [23:09] * Quits: davidb (~davidb@209.52.84.51) (Client Quit)
  1020. # [23:09] <AryehGregor> Hixie, maybe because people then are forced to write different styles for different media, and they won't test the styles they write for uncommon media, so the site breaks if you try to use the styles in practice?
  1021. # [23:10] <annevk> Hixie, what is your fifth priority? *curious*
  1022. # [23:10] <Hixie> AryehGregor: well in practice they wouldn't need to write style sheets for anything but the one they do now, but they could do display:none on the stuff they want to leave for ATs
  1023. # [23:10] <Hixie> ideally we wouldn't need to hide anything from non-ATs, too
  1024. # [23:11] <Hixie> annevk: deal with feedback
  1025. # [23:11] * Quits: ap (~ap@2620:0:1b00:1191:226:4aff:fe14:aad6) (Remote host closed the connection)
  1026. # [23:12] <annevk> nothing grand like <device>? :)
  1027. # [23:13] <Hixie> <device> is 7th
  1028. # [23:13] <Hixie> though i may work on it out-of-order on tuesday
  1029. # [23:13] <annevk> heh
  1030. # [23:13] <Hixie> since there's a lot of interest
  1031. # [23:14] <annevk> I think most people outside are way past the process bullshit and are looking at what is next
  1032. # [23:14] <Hixie> yes
  1033. # [23:14] <annevk> and to be honest, me too, for the most of it
  1034. # [23:14] <Hixie> me too :-)
  1035. # [23:22] <JonathanNeal> Hixie, but even when I use @media to style the obscured elements (the hidden accessibles) I think I'll need the same tricks.
  1036. # [23:23] <AryehGregor> In theory no. Just put display: none in the visual stylesheets, and not in the media-specific stylesheets.
  1037. # [23:23] <AryehGregor> No tricks required.
  1038. # [23:23] <AryehGregor> That doesn't work, but only because ATs use the visual stylesheets.
  1039. # [23:23] * Joins: ap (~ap@2620:0:1b00:1191:226:4aff:fe14:aad6)
  1040. # [23:24] * Joins: nessy (~Adium@209.52.84.51)
  1041. # [23:24] * Quits: Maurice (copyman@5ED573FA.cable.ziggo.nl)
  1042. # [23:24] * Joins: nimbupani (~nimbupani@c-24-22-131-46.hsd1.wa.comcast.net)
  1043. # [23:25] <JonathanNeal> AryehGregor, oh ... yea I hate when practice beats theory, but that kinda binds me, yea.
  1044. # [23:26] * Joins: davidb (~davidb@209.52.84.51)
  1045. # [23:30] * Joins: jlebar (~jlebar@209.52.84.51)
  1046. # [23:31] * Quits: bobchao (~cctw@209.52.84.51) (Ping timeout: 260 seconds)
  1047. # [23:36] * Quits: eighty4 (~eighty4@c-76c8e455.012-403-6c6b701.cust.bredbandsbolaget.se) (Remote host closed the connection)
  1048. # [23:38] * Quits: TelFiRE (~TelFiRE@c-24-10-155-57.hsd1.ut.comcast.net) (Ping timeout: 260 seconds)
  1049. # [23:42] * Joins: mmn (~mmn@209.52.84.51)
  1050. # [23:48] * Quits: ttepasse (~ttepasse@ip-109-90-160-217.unitymediagroup.de) (*.net *.split)
  1051. # [23:48] * Quits: svl (~me@ip565744a7.direct-adsl.nl) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
  1052. # [23:50] * Joins: TelFiRE (~TelFiRE@c-24-10-155-57.hsd1.ut.comcast.net)
  1053. # [23:51] * Joins: ttepasse (~ttepasse@ip-109-90-160-217.unitymediagroup.de)
  1054. # [23:52] * Quits: TelFiRE (~TelFiRE@c-24-10-155-57.hsd1.ut.comcast.net) (Client Quit)
  1055. # [23:53] * Quits: davidb (~davidb@209.52.84.51) (Quit: davidb)
  1056. # [23:55] * Joins: ap_ (~ap@17.246.17.28)
  1057. # [23:55] * Quits: ttepasse (~ttepasse@ip-109-90-160-217.unitymediagroup.de) (*.net *.split)
  1058. # [23:56] * Joins: TelFiRE (~TelFiRE@c-24-10-155-57.hsd1.ut.comcast.net)
  1059. # [23:58] * Quits: ap (~ap@2620:0:1b00:1191:226:4aff:fe14:aad6) (Ping timeout: 276 seconds)
  1060. # [23:58] * ap_ is now known as ap
  1061. # Session Close: Thu Jul 08 00:00:00 2010

The end :)