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

Options:

  1. # Session Start: Thu Oct 11 00:00:01 2007
  2. # Session Ident: #whatwg
  3. # [00:00] * Joins: csarven (n=nevrasc@modemcable130.251-202-24.mc.videotron.ca)
  4. # [00:03] * Quits: kingryan_ (n=kingryan@corp.technorati.com) (Remote closed the connection)
  5. # [00:04] * Joins: kingryan (n=kingryan@corp.technorati.com)
  6. # [00:06] * Parts: kingryan (n=kingryan@corp.technorati.com)
  7. # [00:06] * Joins: kingryan (n=kingryan@corp.technorati.com)
  8. # [00:06] * Parts: kingryan (n=kingryan@corp.technorati.com)
  9. # [00:06] * Joins: kingryan (n=kingryan@corp.technorati.com)
  10. # [00:06] * Joins: hober (n=ted@unaffiliated/hober)
  11. # [00:08] * Quits: KevinMarks (i=KevinMar@nat/google/x-301af9410ed58d9c) (Read error: 110 (Connection timed out))
  12. # [00:09] * epeus is now known as KevinMarks
  13. # [00:17] * Joins: weinig (n=weinig@17.203.15.140)
  14. # [00:19] * Quits: kingryan (n=kingryan@corp.technorati.com)
  15. # [00:19] * Joins: kingryan (n=kingryan@corp.technorati.com)
  16. # [00:29] * Quits: heycam (n=cam@203-214-114-92.dyn.iinet.net.au) ("bye")
  17. # [00:55] * Joins: weinig_ (n=weinig@17.255.108.225)
  18. # [00:59] * Quits: weinig (n=weinig@17.203.15.140) (Read error: 104 (Connection reset by peer))
  19. # [00:59] * Joins: weinig (n=weinig@17.203.15.140)
  20. # [01:01] * Quits: KevinMarks (n=KevinMar@216.239.45.19) ("The computer fell asleep")
  21. # [01:05] <Hixie> ok <video> will default to 300x150 with no content, and to content's size with content
  22. # [01:07] <doublec> sounds good
  23. # [01:15] * Quits: billmason (n=billmaso@ip156.unival.com) (".")
  24. # [01:17] * Quits: weinig_ (n=weinig@17.255.108.225) (Read error: 110 (Connection timed out))
  25. # [01:24] * Quits: tndH_ (i=Rob@87.102.2.12) ("ChatZilla 0.9.78.1-rdmsoft [XULRunner 1.8.0.9/2006120508]")
  26. # [01:24] * Joins: othermaciej_ (i=mjs@nat/apple/x-00947a4c89c1ea4a)
  27. # [01:38] * Joins: KevinMarks (i=KevinMar@nat/google/x-0716755ba8bf4503)
  28. # [01:40] * Quits: othermaciej (n=mjs@17.255.98.11) (Connection timed out)
  29. # [01:43] * Quits: DrChirs (n=IceChat7@204-16-231-250-accuradio.pkh.ord.sparkplugbb.net) ("Relax, its only ONES and ZEROS!")
  30. # [01:50] * Quits: doublec (n=doublec@202.180.114.137)
  31. # [01:57] * Quits: weinig (n=weinig@17.203.15.140)
  32. # [01:59] * othermaciej_ is now known as othermaciej
  33. # [02:11] * Quits: kingryan (n=kingryan@corp.technorati.com)
  34. # [02:26] * Joins: doublec (n=doublec@202.180.114.137)
  35. # [02:27] * Joins: tantek (n=tantek@h460d8af9.area2.spcsdns.net)
  36. # [02:35] * Joins: weinig (n=weinig@17.203.15.140)
  37. # [02:40] * Joins: tantek_ (n=tantek@h460e3f51.area3.spcsdns.net)
  38. # [02:45] * Joins: tantek__ (n=tantek@h460e2714.area3.spcsdns.net)
  39. # [02:57] * Quits: tantek (n=tantek@h460d8af9.area2.spcsdns.net) (Read error: 110 (Connection timed out))
  40. # [03:04] * Quits: tantek_ (n=tantek@h460e3f51.area3.spcsdns.net) (Read error: 110 (Connection timed out))
  41. # [03:16] * Quits: tantek__ (n=tantek@h460e2714.area3.spcsdns.net) (Read error: 110 (Connection timed out))
  42. # [03:19] * Quits: dbaron (n=dbaron@corp-241.mountainview.mozilla.com) ("8403864 bytes have been tenured, next gc will be global.")
  43. # [03:21] * Joins: tantek (n=tantek@000-121-589.area2.spcsdns.net)
  44. # [03:27] <Hixie> it seems people have discovered that you can use my data: URI kitchen to save things like PDFs and such for offline viewing on iPhones
  45. # [03:27] <Hixie> and they are now uploading multi-megabyte PDFs and the like to my server
  46. # [03:29] * Joins: tantek_ (n=tantek@000-118-280.area2.spcsdns.net)
  47. # [03:35] * Quits: h3h (n=w3rd@66-162-32-234.static.twtelecom.net) ("|")
  48. # [03:35] * Quits: tantek (n=tantek@000-121-589.area2.spcsdns.net) (Read error: 104 (Connection reset by peer))
  49. # [03:43] * Quits: tantek_ (n=tantek@000-118-280.area2.spcsdns.net) (Read error: 104 (Connection reset by peer))
  50. # [03:46] * Joins: yod (n=ot@dhcp-247-26.mag.keio.ac.jp)
  51. # [03:47] * Joins: tantek (n=tantek@h460df20f.area2.spcsdns.net)
  52. # [03:49] * Quits: weinig (n=weinig@17.203.15.140)
  53. # [03:59] * Joins: tantek_ (n=tantek@h460dce71.area2.spcsdns.net)
  54. # [04:04] * Quits: tantek (n=tantek@h460df20f.area2.spcsdns.net) (Read error: 104 (Connection reset by peer))
  55. # [04:12] * Joins: tantek (n=tantek@h460d545d.area2.spcsdns.net)
  56. # [04:13] * Quits: tantek_ (n=tantek@h460dce71.area2.spcsdns.net) (Read error: 104 (Connection reset by peer))
  57. # [04:21] * Joins: MikeSmith (n=MikeSmit@eM60-254-226-229.pool.emnet.ne.jp)
  58. # [04:22] * Joins: weinig (n=weinig@adsl-71-138-134-104.dsl.pltn13.pacbell.net)
  59. # [04:22] * Quits: weinig (n=weinig@adsl-71-138-134-104.dsl.pltn13.pacbell.net) (Remote closed the connection)
  60. # [04:23] * Joins: tantek_ (n=tantek@70.14.39.239)
  61. # [04:23] * Joins: weinig (n=weinig@adsl-71-138-134-104.dsl.pltn13.pacbell.net)
  62. # [04:27] * Joins: tantek__ (n=tantek@70.13.236.0)
  63. # [04:31] * Joins: tantek___ (n=tantek@h460d8546.area2.spcsdns.net)
  64. # [04:37] * Quits: tantek (n=tantek@h460d545d.area2.spcsdns.net) (Read error: 110 (Connection timed out))
  65. # [04:37] * Quits: tantek___ (n=tantek@h460d8546.area2.spcsdns.net) (Read error: 104 (Connection reset by peer))
  66. # [04:37] * Joins: tantek (n=tantek@h460d1efe.area2.spcsdns.net)
  67. # [04:47] * Quits: tantek_ (n=tantek@70.14.39.239) (Read error: 110 (Connection timed out))
  68. # [04:50] * Quits: tantek__ (n=tantek@70.13.236.0) (Read error: 110 (Connection timed out))
  69. # [04:53] * Joins: tantek_ (n=tantek@h460db99b.area2.spcsdns.net)
  70. # [04:54] * Quits: tantek (n=tantek@h460d1efe.area2.spcsdns.net) (Read error: 104 (Connection reset by peer))
  71. # [04:54] * Quits: tantek_ (n=tantek@h460db99b.area2.spcsdns.net) (Client Quit)
  72. # [04:56] * Quits: othermaciej (i=mjs@nat/apple/x-00947a4c89c1ea4a)
  73. # [04:59] * Quits: MikeSmith (n=MikeSmit@eM60-254-226-229.pool.emnet.ne.jp) ("Less talk, more pimp walk.")
  74. # [05:03] * Quits: csarven (n=nevrasc@modemcable130.251-202-24.mc.videotron.ca) ("http:/www.csarven.ca")
  75. # [05:21] * Joins: othermaciej (i=mjs@nat/apple/x-3a062fa771e792c2)
  76. # [05:28] * Quits: aaronlev (n=chatzill@209-6-168-245.c3-0.arl-ubr2.sbo-arl.ma.cable.rcn.com) (Remote closed the connection)
  77. # [05:41] * Joins: heycam (n=cam@203-214-114-92.dyn.iinet.net.au)
  78. # [06:07] * Quits: mpt (n=mpt@121-72-139-108.dsl.telstraclear.net) ("Leaving")
  79. # [06:08] * Joins: jruderman (n=jruderma@c-67-180-15-227.hsd1.ca.comcast.net)
  80. # [06:14] <gavin_> heh
  81. # [06:21] * Joins: tantek (n=tantek@h460d4a5c.area2.spcsdns.net)
  82. # [06:22] * Joins: mpt (n=mpt@121-72-139-108.dsl.telstraclear.net)
  83. # [06:25] * Joins: tantek_ (n=tantek@h460d8e02.area2.spcsdns.net)
  84. # [06:33] * Quits: othermaciej (i=mjs@nat/apple/x-3a062fa771e792c2) (Read error: 110 (Connection timed out))
  85. # [06:47] * Quits: tantek (n=tantek@h460d4a5c.area2.spcsdns.net) (Read error: 110 (Connection timed out))
  86. # [06:48] * Quits: tantek_ (n=tantek@h460d8e02.area2.spcsdns.net) (Read error: 110 (Connection timed out))
  87. # [07:04] * Quits: hober (n=ted@unaffiliated/hober) (Read error: 110 (Connection timed out))
  88. # [07:16] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  89. # [07:19] * Joins: MikeSmith (n=MikeSmit@eM60-254-247-95.pool.emnet.ne.jp)
  90. # [07:29] * Quits: Thezilch (i=fuz007@c-68-52-119-203.hsd1.tn.comcast.net) (Read error: 113 (No route to host))
  91. # [08:03] * Quits: MikeSmith (n=MikeSmit@eM60-254-247-95.pool.emnet.ne.jp) ("Less talk, more pimp walk.")
  92. # [08:04] * Quits: doublec (n=doublec@202.180.114.137)
  93. # [08:29] * Joins: Thezilch (i=fuz007@c-68-52-119-203.hsd1.tn.comcast.net)
  94. # [08:33] <hsivonen> "captive portal"?
  95. # [08:33] <Hixie> router that returns 307 for all uris, e.g. used for wireless networks to get payment information
  96. # [08:35] <hsivonen> ah
  97. # [08:35] <hsivonen> those are evil
  98. # [08:36] <Hixie> but it is very common to hit these when in an offline situation
  99. # [08:37] <Hixie> so we have to handle them
  100. # [08:38] <jruderman> as long as we don't require letting them MITM TLS connections
  101. # [08:39] <hsivonen> Hixie: yes, I realize that they are common even if not popular
  102. # [08:40] <hsivonen> I particularly dislike the ones that don't even want my money but that want me the click through a disclaimer an over-eager lawyer wrote
  103. # [08:41] <hsivonen> jruderman: It seems to me that WLAN authorization purchases are finally a use case for CA-approved certs.
  104. # [08:42] <hsivonen> I wonder how many bogus access points there are around Europe pretending to be Orange access points but phishing for credit card numbers
  105. # [08:42] <jruderman> hsivonen: what do you mean?
  106. # [08:42] <jruderman> (about CA-approved certs)
  107. # [08:43] <hsivonen> jruderman: certs signed by CAs that the browser has root certs for in advance
  108. # [08:44] <hsivonen> jruderman: that is, a picking a random access point in a foreign town is much more likely to direct you to a phishing node than the DNS of your wired broadband provider
  109. # [08:45] <hsivonen> though I suppose a proper phishing node could forge IP addresses on its fake network
  110. # [08:45] <hsivonen> and just grab a cert from a real site
  111. # [08:46] <jruderman> oh, you're saying that wireless (not just wireless that charges) is a good reason for using CAs rather than SSH-style authentication
  112. # [08:48] <hsivonen> jruderman: I was saying that certs are useful for authenticating the wireless charging entry points
  113. # [08:49] <hsivonen> (scratch what I said about cert stealing above. of course it doesn't give the stealer the private key)
  114. # [08:50] <jruderman> because if it weren't for wireless networks that charged, you could just wait until you get home to do your credit card purchases?
  115. # [08:52] <hsivonen> jruderman: no that's not what I meant. just that the payment portal seems like lower-hanging fruit to forge than a random site on the net and hoping that someone on the phishing AP makes a purhase on the random site
  116. # [08:52] <jruderman> ok
  117. # [08:55] <hsivonen> on a different note, is it ever uttered out loud which concrete browsers are expected to do the mobile profile stuff
  118. # [08:57] <Hixie> i never understood that either
  119. # [09:01] <othermaciej> I was going to comment on the CSS Mobile Profile on the basis that such a thing is (a) useless and (b) harmful
  120. # [09:01] <othermaciej> but it seems like wasted breath
  121. # [09:08] * Joins: doublec (n=doublec@203-211-83-10.ue.woosh.co.nz)
  122. # [09:17] <hsivonen> Hixie: I think it is a bit weird that the party line is that people are expected to continue to use text/html, but HTML 5 contains many XHTML/DOM-only content model expansions
  123. # [09:22] * Quits: doublec (n=doublec@203-211-83-10.ue.woosh.co.nz)
  124. # [09:24] * Quits: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  125. # [09:27] * Joins: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  126. # [09:31] * Joins: virtuelv (n=virtuelv@pat-tdc.opera.com)
  127. # [09:40] * Joins: Thezilch[FH] (i=fuz007@c-68-52-119-203.hsd1.tn.comcast.net)
  128. # [09:40] * Quits: Thezilch (i=fuz007@c-68-52-119-203.hsd1.tn.comcast.net) (Read error: 104 (Connection reset by peer))
  129. # [09:45] <hsivonen> Hixie: an extra ">": The cite DOM attribute must reflect the element's >cite content attribute.
  130. #
  131. # Session Start: Thu Oct 11 14:37:16 2007
  132. # Session Ident: #whatwg
  133. # [14:37] * Now talking in #whatwg
  134. # [14:37] * Topic is 'WHATWG (HTML5) -- http://www.whatwg.org/ -- Logs: http://krijnhoetmer.nl/irc-logs/ -- Please leave your sense of logic at the door, thanks!'
  135. # [14:37] * Set by Hixie on Tue Apr 03 04:10:22
  136. # [14:37] <krijnh> \o/
  137. # [14:40] <krijn> So, it appears, cables should be connected
  138. # [14:40] <krijn> That's something new
  139. # [14:40] <OmegaJunior> lol
  140. # [14:41] <OmegaJunior> In case of wires: connect. In case of wireless: don't.
  141. # [14:43] * Quits: Lachy (n=Lachy@pat-tdc.opera.com) ("Leaving")
  142. # [14:43] * Joins: Lachy (n=Lachy@pat-tdc.opera.com)
  143. # [14:48] <krijnh> Can't agree more :)
  144. # [14:48] * Disconnected
  145. # Session Close: Thu Oct 11 14:48:39 2007
  146. #
  147. # Session Start: Thu Oct 11 14:49:28 2007
  148. # Session Ident: #whatwg
  149. # [14:49] * Now talking in #whatwg
  150. # [14:49] * Topic is 'WHATWG (HTML5) -- http://www.whatwg.org/ -- Logs: http://krijnhoetmer.nl/irc-logs/ -- Please leave your sense of logic at the door, thanks!'
  151. # [14:49] * Set by Hixie on Tue Apr 03 04:10:22
  152. # [14:55] * gsnedders got 46/52 in the computing test. only two of the lost marks were due to the actual "correct" answers being wrong.
  153. # [14:57] <OmegaJunior> Yes, what is correct according to text books and exams can differ greatly from what is correct according to parsers, compilers and browsers, which in turn differs from what is correct according to the end user.
  154. # [14:57] <krijn> That is correct
  155. # [14:58] <hendry> so <br> tag is a 'void element'. What is a <p> called?
  156. # [14:59] <gsnedders> OmegaJunior: not just according to parsers, compilers, and browsers but also specifications
  157. # [14:59] <OmegaJunior> Phrase element?
  158. # [14:59] <OmegaJunior> For a test, that's a bad situation.
  159. # [15:00] <OmegaJunior> Depends on the transparancy of the spec, I'm sure.
  160. # [15:02] <hsivonen> hendry: <p> is a start tag
  161. # [15:02] <gsnedders> OmegaJunior: US-ASCII (whatever that is — I assume ANSI X3.4-1968) is 8-bit, and Unicode is 16-bit (despite unicode not being an encoding form)
  162. # [15:03] <OmegaJunior> Isn't UTF-8 an 8-bit form of Unicode?
  163. # [15:04] <OmegaJunior> I guess you'd recognise it by it being called 'UTF-8' and not Unicode...
  164. # [15:04] <gsnedders> no, UTF-8 encodes codepoints between one and five 8-bit bytes.
  165. # [15:04] * zcorpan thought it was 1-6 bytes
  166. # [15:04] <gsnedders> s/five/four/
  167. # [15:05] <gsnedders> zcorpan: it was originally six, then changed to limit to 0x10FFFF (which can be done in four bytes)
  168. # [15:05] <gsnedders> UTF-16 is two/four bytes.
  169. # [15:05] <hendry> hsivonen: though <p> are used like 'void element's a lot
  170. # [15:05] <gsnedders> UTF-32 is four bytes.
  171. # [15:05] <hendry> hsivonen: and start tag implies it should be ended? little confused on the terminology
  172. # [15:06] <gsnedders> zcorpan: <http://tools.ietf.org/html/rfc3629#section-12>
  173. # [15:06] <zcorpan> <br> is also a start tag
  174. # [15:06] <hsivonen> hendry: a void element is an element that cannot have content in the text/html serialization and doesn't have an end tag
  175. # [15:06] <gsnedders> zcorpan: as you're limited to 10FFFF at the highest, and non-shortest forms are invalid, you cannot have more than four byte sequences
  176. # [15:06] <zcorpan> gsnedders: ah, ok
  177. # [15:06] <hsivonen> hendry: omitting </p> doesn't make <p> void
  178. # [15:10] <zcorpan> in the parser, br and p are both categorized as "special". on the text/html syntax authoring side, br is categorized as "void element" and p is a "normal element"
  179. # [15:10] <hsivonen> I wonder what the back and forward compat story of the source element is as far as voidness goes...
  180. # [15:10] <hsivonen> oh, right </br> is weird when it comes to parsing
  181. # [15:11] <zcorpan> </p> also :)
  182. # [15:13] <gsnedders> what does </p> do?
  183. # [15:15] <OmegaJunior> It signals the end of a p element
  184. # [15:15] <hendry> hsivonen: so when reading the spec. to distinguish between void element and say a tag, I should be looking at the "content model"
  185. # [15:16] * Joins: aaronlev (n=chatzill@c-66-31-86-217.hsd1.ma.comcast.net)
  186. # [15:16] <hsivonen> hendry: no
  187. # [15:16] <hendry> some things seem to have to be closed, like when I was just playing with <object>, whilst others not so. I guess it's browser thing.
  188. # [15:16] <hsivonen> hendry: "void" is a text/html serialization/parsing concept
  189. # [15:16] <hsivonen> hendry: empty content model is a document tree-level concept
  190. # [15:16] <hsivonen> hendry: it isn't safe to infer a relationship
  191. # [15:17] <hendry> hsivonen: so how do i read the spec for "serialization/parsing concept"?
  192. # [15:17] <hsivonen> hendry: to make things worse, the parsing stuff for new elements that are supposed to be empty hasn't been nailed down
  193. # [15:17] <hsivonen> hendry: the parsing and writing html sections
  194. # [15:19] <hendry> hsivonen: thanks for the clarification(s)
  195. # [15:19] <zcorpan> gsnedders: if there's no p in scope, </p> is the same as <p></p>
  196. # [15:19] <gsnedders> zcorpan: thanks
  197. # [15:20] <hsivonen> hendry: I think it would be useful for the element definition sections to have text/html-specific serialization notes, because people expect to find the advice there (but don't currently)
  198. # [15:21] <zcorpan> Lachy: http://html5.lachy.id.au/ has been Service Unavailable for me for a while now :(
  199. # [15:21] <Lachy> yeah, I know.
  200. # [15:21] <Lachy> I can't fix it till my computer arrives from Australia
  201. # [15:21] <zcorpan> ok
  202. # [15:22] <Lachy> and that's taken longer than expected
  203. # [15:22] <gsnedders> Lachy: stop moving so far :P
  204. # [15:22] <Lachy> it should arrive next week
  205. # [15:22] <hendry> is there a part in html5 that distinguishes between relative URIs? i noticed that HTML4 does
  206. # [15:22] <zcorpan> distinguishes between relative URIs and what?
  207. # [15:23] <zcorpan> relative IRIs? absolute URIs? elephants? :)
  208. # [15:25] * Quits: virtuelv (n=virtuelv@pat-tdc.opera.com) ("Leaving")
  209. # [15:25] <OmegaJunior> They're all URI's... should it matter to the html5-spec whether they're relative or absolute?
  210. # [15:26] <hsivonen> hendry: there's one place in WF2 that requires an absolute URI
  211. # [15:26] <OmegaJunior> Ah. It does matter.
  212. # [15:26] <hsivonen> hendry: value attribute on input type='url'
  213. # [15:27] <hsivonen> hendry: profile is gone at least for now
  214. # [15:29] <hendry> sorry i was called away for a moment zcorpan :)
  215. # [15:29] <OmegaJunior> hsivonen, why does input type='url' require absolute uri's?
  216. # [15:30] <hsivonen> OmegaJunior: I guess entering relative URIs into a form generally does not make sense
  217. # [15:30] <hsivonen> OmegaJunior: since you want the value to work without a base URI
  218. # [15:31] <gsnedders> if you allow relative URIs, is it relative to the page at which the form is on, or relative to the page that receives the form?
  219. # [15:35] <OmegaJunior> Makes sense.
  220. # [15:35] <OmegaJunior> Thanks!
  221. # [15:36] * Quits: yod (n=ot@softbank221018155222.bbtec.net) ("Leaving")
  222. # [15:46] <hendry> i was also thinking of forms today. reset and password
  223. # [15:46] <hendry> is "reset" actually useful? :)
  224. # [15:46] <hendry> and do passwords need to be obfuscated by *****
  225. # [15:47] <hsivonen> hendry: no and yes
  226. # [15:48] <hendry> they need to be obfuscated you say? does it say in the spec? I don't think so
  227. # [15:49] <hendry> i find the obfuscation really painful when typing in wireless keys with my shiny ipod touch
  228. # [15:49] <OmegaJunior> Personally I think such obfuscation silly. The password will still show up in the source if echoed back.
  229. # [15:50] <hsivonen> hendry: reset isn't useful but obfuscation of passwords is when you are not guaranteed to be alone
  230. # [15:51] <hendry> UA should have an option to specific, i'm alone. not in a public place. :)
  231. # [15:51] <hsivonen> hendry: Nokia UIs (both Maemo and S60 briefly give visual feedback for each character before obfuscating it)
  232. # [15:51] <hsivonen> hmm. misplaced )
  233. # [15:51] <OmegaJunior> So does the Motorola Razr
  234. # [15:52] <hendry> OmegaJunior: so you could perhaps write a piece of JS to echo it back without obfuscation/
  235. # [15:52] <OmegaJunior> Yeah, or just use an input type='text'
  236. # [15:52] <hsivonen> OmegaJunior: it isn't about being plain text in the source
  237. # [15:54] <OmegaJunior> Which makes it even more silly.
  238. # [15:54] <hsivonen> OmegaJunior: what's silly about people looking over your shoulder?
  239. # [15:54] <OmegaJunior> It's silly to type in sensitive info when they are. Ever seen someone who can read your typing off of your finger movements? It's quite easy.
  240. # [15:55] <hsivonen> OmegaJunior: use Dvorak :-)
  241. # [15:55] <OmegaJunior> :D
  242. # [15:56] <hendry> also i think some keypads have different frequences depdending on what you type
  243. # [15:57] <hendry> damn, I can't type at all. Getting used to my new Das Keyboard
  244. # [16:12] * Joins: dglazkov (n=dglazkov@adsl-065-081-081-030.sip.bhm.bellsouth.net)
  245. # [16:16] * Parts: BenWard (i=BenWard@nat/yahoo/x-4ae560c04f668100)
  246. # [16:20] <hsivonen> validator.nu now supports dialog and various other relatively recent language changes except data templates
  247. # [16:21] <hsivonen> I guess now is the time to cut the RNG in half and move interactive element exclusions to schematron
  248. # [16:39] <hsivonen> whoa are there really only 3 non-form interactive elements: a, datagrid and details
  249. # [16:39] <hsivonen> or am I misgrepping?
  250. # [16:41] <OmegaJunior> Aren't audio and video elements considered interactive? The spec does require a level of interaction.
  251. # [16:44] <hsivonen> OmegaJunior: they are not
  252. # [16:44] <OmegaJunior> OK.
  253. # [16:44] * zcorpan would expect <area> to also be interactive
  254. # [16:45] <hsivonen> zcorpan: are you going to send email?
  255. # [16:45] <zcorpan> i'm not sure i understand what the "interactive" category is for, exactly
  256. # [16:45] <zcorpan> is it only for the content model?
  257. # [16:46] * Joins: polin8 (n=brian@c-75-71-72-175.hsd1.co.comcast.net)
  258. # [16:46] * Quits: polin8 (n=brian@c-75-71-72-175.hsd1.co.comcast.net) (Remote closed the connection)
  259. # [16:46] * Quits: gsnedders (n=gsnedder@host86-145-188-131.range86-145.btcentralplus.com)
  260. # [16:47] <hsivonen> OmegaJunior: email sent about the interactiveness of video/audio
  261. # [16:47] <hsivonen> zcorpan: the idea is to ban nesting of intrinsically clickable elements
  262. # [16:48] <zcorpan> seems weird that <details> is interactive, then; it should be ok to have links in a <details>, no? (not in the <legend>, perhaps)
  263. # [16:48] <hsivonen> zcorpan: I just sent email about that. :-)
  264. # [16:48] <zcorpan> k
  265. # [16:49] <OmegaJunior> Not received yet
  266. # [16:49] <OmegaJunior> ;)
  267. # [16:49] <hsivonen> OmegaJunior: I sent it to public-html
  268. # [16:49] <zcorpan> perhaps the Big Issue under <datagrid> also applies to <details>
  269. # [16:50] <hsivonen> how do I negate [@foo] in XPath?
  270. # [16:50] <OmegaJunior> hsivonen, I don't think I subscribed to that list
  271. # [16:51] <OmegaJunior> [~@foo]?
  272. # [16:51] <hsivonen> ~ not found in teh XPath spec
  273. # [16:51] <zcorpan> not([@foo]) ?
  274. # [16:52] <OmegaJunior> Hrm.
  275. # [16:52] <OmegaJunior> Let me look.
  276. # [16:53] <hsivonen> I want to select input elements but not input type=hidden
  277. # [16:54] <hsivonen> zcorpan: h:input[not(@type="hidden")] might be it
  278. # [16:55] <OmegaJunior> You should be able to use ~ or !... but I'm not seeing any examples. I'm looking further.
  279. # [17:01] <zcorpan> hsivonen: yeah, that seems to work
  280. # [17:01] <zcorpan> h:input[@type!='hidden'] also
  281. # [17:01] <OmegaJunior> And I learn something new: no ! operator as a shorthand for not().
  282. # [17:02] <zcorpan> at least != works in opera
  283. # [17:03] <hsivonen> zcorpan: thanks
  284. # [17:04] <zcorpan> perhaps <img usemap> should be classified as interactive
  285. # [17:04] <zcorpan> rather than <area>
  286. # [17:04] <hsivonen> zcorpan: are you going to send email or should I?
  287. # [17:05] <zcorpan> i can do it
  288. # [17:05] <hsivonen> thanks
  289. # [17:08] * Joins: gsnedders (n=gsnedder@host86-145-188-131.range86-145.btcentralplus.com)
  290. # [17:11] <zcorpan> wonder if i should drop the "detailed review" thing :)
  291. # [17:23] <Philip`> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0D%0A%3Ca%20href%3D%3FFollowed%3E%3Cmap%20name%3Dmap%3E%3Carea%20shape%3Drect%20coords%3D0%2C0%2C200%2C100%3E%3C%2Fmap%3E%3C%2Fa%3E%0D%0A%3Cimg%20usemap%3D%23map%20src%3Dimage%3E
  292. # [17:23] <Philip`> At least in Opera, click events propagate outwards from the <area>
  293. # [17:24] <Philip`> but I don't know if that's relevant to its interactivity
  294. # [17:26] <hsivonen> Philip`: interactivity is a non-scripted document conformance concept only
  295. # [17:27] <zcorpan> hmm, not sure if click events should be dispatched when interacting with the browser's native UI of <video>
  296. # [17:37] * Parts: krijn (n=krijnhoe@ktk.xs4all.nl)
  297. # [17:46] * Quits: weinig (n=weinig@adsl-71-138-134-104.dsl.pltn13.pacbell.net)
  298. # [17:46] * Quits: Lachy (n=Lachy@pat-tdc.opera.com) ("Leaving")
  299. # [17:48] <hsivonen> I just landed and deployed a big refactoring that moved interactive element nesting issues from RELAX NG to Schematron. Unit tests still pass, but please let me know if I broke something.
  300. # [17:49] <hsivonen> error messages for interactive element nesting violations should be *much* better now
  301. # [17:50] * Joins: Lachy (n=Lachy@pat-tdc.opera.com)
  302. # [17:54] <OmegaJunior> Doesn't seem to raise any errors on one of my testing pages... though that was a relatively easy page. I'll whip up something more elaborate.
  303. # [18:02] * Quits: OmegaJunior (n=ZJr@a82-95-48-162.adsl.xs4all.nl) (Read error: 104 (Connection reset by peer))
  304. # [18:21] * Joins: weinig (n=weinig@17.203.15.140)
  305. # [18:30] <gsnedders> Lachy: didn't anyone tell you? Norway is more expensive than even here.
  306. # [18:31] * Joins: maikmerten_ (n=maikmert@T75bd.t.pppool.de)
  307. # [18:36] * Joins: h3h (n=w3rd@66-162-32-234.static.twtelecom.net)
  308. # [18:44] * maikmerten_ is now known as maikmerten
  309. # [18:51] * Quits: KevinMarks (n=KevinMar@c-98-207-134-151.hsd1.ca.comcast.net) (Read error: 110 (Connection timed out))
  310. # [19:09] * Joins: virtuelv (n=virtuelv@51.80-203-76.nextgentel.com)
  311. # [19:24] * Joins: rubys (n=rubys@cpe-075-182-087-110.nc.res.rr.com)
  312. # [19:29] * Parts: rubys (n=rubys@cpe-075-182-087-110.nc.res.rr.com)
  313. # [19:37] * Quits: mpt (n=mpt@canonical/launchpad/mpt) ("This computer has gone to sleep")
  314. # [19:42] * Joins: kingryan (n=kingryan@corp.technorati.com)
  315. # [19:56] * Joins: billmason (n=billmaso@ip156.unival.com)
  316. # [20:18] <Hixie_> hsivonen: the party line was established after the extensions, in mayn cases
  317. # [20:18] <Hixie_> hsivonen: also note that the attribute stuff in the spec is the way it is (inconsistent) because at one point i decided to give up describing the optional/required constraints in the summaru
  318. # [20:19] * Joins: KevinMarks (n=KevinMar@216.239.45.19)
  319. # [20:24] * Joins: tantek (n=tantek@h460de657.area2.spcsdns.net)
  320. # [20:25] * Joins: hober (n=ted@unaffiliated/hober)
  321. # [20:28] * Joins: epeus (i=KevinMar@nat/google/x-3c48cc411ee3aadc)
  322. # [20:35] * Quits: KevinMarks (n=KevinMar@216.239.45.19) (Read error: 110 (Connection timed out))
  323. # [20:35] * Quits: virtuelv (n=virtuelv@51.80-203-76.nextgentel.com) ("Leaving")
  324. # [20:36] * Quits: tantek (n=tantek@h460de657.area2.spcsdns.net) (Read error: 104 (Connection reset by peer))
  325. # [20:42] * Quits: billmason (n=billmaso@ip156.unival.com) (Read error: 110 (Connection timed out))
  326. # [20:43] <kingryan> Hixie_: the twitter message link to the revision seems to be working great. thanks
  327. # [20:43] <Hixie_> sweet
  328. # [20:44] <Hixie_> i had to adapt your code a bit
  329. # [20:44] <kingryan> of course
  330. # [20:44] <Hixie_> but i'm glad it's working
  331. # [20:44] * epeus is now known as KevinMarks
  332. # [20:45] <kingryan> it was hard for me to test w/out access to the repositories
  333. # [20:46] * Joins: dbaron (n=dbaron@corp-241.mountainview.mozilla.com)
  334. # [20:48] * Joins: tantek (n=tantek@h460d3d7c.area2.spcsdns.net)
  335. # [20:52] * Quits: tantek (n=tantek@h460d3d7c.area2.spcsdns.net) (Client Quit)
  336. # [20:53] * Quits: othermaciej (n=mjs@dsl081-048-145.sfo1.dsl.speakeasy.net)
  337. # [21:14] * Quits: weinig (n=weinig@17.203.15.140) (Read error: 110 (Connection timed out))
  338. # [21:49] * Joins: weinig (n=weinig@17.203.15.140)
  339. # [21:56] * Joins: othermaciej (n=mjs@17.255.111.81)
  340. # [22:09] * Quits: maikmerten (n=maikmert@T75bd.t.pppool.de) (Remote closed the connection)
  341. # [22:18] <hsivonen> Hixie_: do you intend to scale back the content model expansions now that the party line has been established?
  342. # [22:19] <hsivonen> Hixie_: I was hoping I could mine the green-background element summaries for UI messages
  343. # [22:19] <Hixie_> to be honest i really don't know
  344. # [22:19] <Hixie_> that part of the spec is a mess right now
  345. # [22:19] <Hixie_> i haven't focused on semantics for a while
  346. # [22:20] * Quits: zcorpan (n=zcorpan@pat.se.opera.com) (Read error: 110 (Connection timed out))
  347. # [22:21] <hsivonen> ok. I try to continue to put the nonHTMLizable switches in the right places
  348. # [22:21] <Hixie_> i don't understand why this fails: http://cgi.w3.org/member-bin/process.cgi?method=url&url=http%3A%2F%2Fwww.whatwg.org%2Fspecs%2Fweb-apps%2Fcurrent-work%2Fsource-w3c&output=html
  349. # [22:22] <hsivonen> but ATM, I can only infer those places from the parsing algorithm. obviously, authors won't do that but will require more obvious docs.
  350. # [22:22] <Hixie_> for sure
  351. # [22:25] <hsivonen> I wonder how many people would actually care if I combined the xml:id Processor and the XHTML id Processor
  352. # [22:25] <hsivonen> (in some cases, duplicate ID errors would fire for xml:id-wise wrong reasons)
  353. # [22:27] <hsivonen> also, I wonder if I could get away with assigning IDness to all no-namespace attributes called id regardless of the namespace of the element...
  354. # [22:30] * Quits: ROBOd (n=robod@89.122.216.38) ("http://www.robodesign.ro")
  355. # [22:35] <Hixie_> hsivonen: question for you
  356. # [22:35] <Hixie_> hsivonen: regarding the conformance of manifests
  357. # [22:36] <Hixie_> in section "4.6.3.1. Writing cache manifests" i have conformance requirements for manifests
  358. # [22:36] <Hixie_> including: Manifests must specify all the URIs that are to be cached.
  359. # [22:36] <Hixie_> but it was pointed out that in fact, some URIs that are to be cached -- like the application document that refers to the manifest in the first place -- get cached even if not explicitly listed
  360. # [22:37] <Hixie_> and thus the conformance criteria is confusing, if not outright illadvised
  361. # [22:37] <Hixie_> do you have any advice on the matter?
  362. # [22:39] <hsivonen> Hixie_: I think it is at minimum confusing
  363. # [22:41] <hsivonen> I'm trying to come up with a better wording, but I don't know manifests well enough yet
  364. # [22:42] <Hixie_> i'm not really even sure what we should asy
  365. # [22:42] <Hixie_> say
  366. # [22:42] <Hixie_> maybe it's a useless conformance criteria
  367. # [22:42] <Hixie_> it's not like it can be tested
  368. # [22:43] <hsivonen> Hixie_: is there an easy list of things that get cached implicitly?
  369. # [22:43] <Hixie_> 1. html or xhtml files that have a manifest="" attribute on their root element
  370. # [22:43] <hsivonen> Hixie_: Authors must list the URIs they want cached in the manifest, except [short list].
  371. # [22:43] <Hixie_> 2. things that get automatically cached from matching the caching namespaces
  372. # [22:44] <Hixie_> i think i might just drop them
  373. # [22:44] <Hixie_> it seems weird to say that an author must do what he wants to do
  374. # [22:45] <hsivonen> yes
  375. # [22:46] <hsivonen> I guess you could make a non-testable or hard-to-test requirement that authors must list the URIs that don't get cached implicitly and that need to be cached in order for the app to work
  376. # [22:46] <hsivonen> but perhaps it is just better to state the function of the list
  377. # [22:46] <Hixie_> yeah
  378. # [22:46] <hsivonen> instead of making non-testable requirements about what to put on the list
  379. # [22:48] <hsivonen> I'm going to try to combine an xml:id processor, a non-spec-based IDness assigner and ID uniqueness checking in one class
  380. # [22:48] <hsivonen> I guess that's the way to find out if the market will accept such a rigged xml:id processor
  381. # [22:49] <Hixie_> why would it not?
  382. # [22:49] <hsivonen> Hixie_: theoretically, the xml:id processor should live between the XML Processor and the XHTML layer
  383. # [22:50] <hsivonen> Hixie_: so that xml:id Errors don't depend on the XHTML layer
  384. # [22:50] <Hixie_> i see
  385. # [22:50] <hsivonen> Hixie_: if they are fused, the operation will be interleaved and you can't tell whether a duplicate ID error should be flagged an xml:id error or an XHTML id error
  386. # [22:51] <hsivonen> the way around it is not to tell the user which errors are xml:id errors :-)
  387. # [22:52] <othermaciej> it sure would be nice if xml:id was just named id
  388. # [22:52] <hsivonen> othermaciej: I intend to implement IDness assigment to id as see if people yell at me
  389. # [22:52] <hsivonen> I expect to get away with it
  390. # [22:52] <othermaciej> if you advertise that fact in the right circles they might
  391. # [22:54] <othermaciej> probably not in actual use
  392. # [22:54] <Hixie_> in actual use you're unlikely to come across any non-html anything...
  393. # [22:54] <hsivonen> I'd expect people to prefer XPath id() to *work* in actual use :-)
  394. # [22:55] * gsnedders still hasn't got his head around XPath at all
  395. # [22:55] <othermaciej> I guess what I'm saying is, I don't know of a markup language with a non-ID attribute named "id"
  396. # [22:55] <hsivonen> I don't know one, either
  397. # [22:56] * gsnedders could do the assholish thing of creating one, just to prove othermaciej and hsivonen wrong
  398. # [22:56] <othermaciej> gsnedders: I think there is an implicit ground rule for such claims of "no toy examples just to prove it's possible"
  399. # [22:56] <gsnedders> othermaciej: of course, it just means I have to work harder to get it actually used :P
  400. # [23:00] * Parts: dglazkov (n=dglazkov@adsl-065-081-081-030.sip.bhm.bellsouth.net)
  401. # [23:00] * Quits: hober (n=ted@unaffiliated/hober) ("ERC Version 5.3 (devel) (IRC client for Emacs)")
  402. # [23:00] <Hixie_> wow, times have changed
  403. # [23:00] <Hixie_> few years back, i'd have been shot on sight for suggesting that xlink:href should be changed to href
  404. # [23:00] <Hixie_> now, it's actually something that people might consider
  405. # [23:00] <gsnedders> on a totally unrelated note, does anyone have any reasons for wanting me to work on HTTP Parsing over the October holidays instead of various other things on my to-do list?
  406. # [23:00] <gsnedders> (anne is the most likely, but he isn't here right now)
  407. # [23:04] <gsnedders> (regardless of that, I should probably email Eric Woersching tonight about one or two things IIS does)
  408. # [23:05] * Joins: doublec (n=doublec@202.180.114.137)
  409. # [23:14] * Quits: jruderman (n=jruderma@c-67-180-15-227.hsd1.ca.comcast.net)
  410. # [23:16] * Joins: jruderman (n=jruderma@c-67-180-15-227.hsd1.ca.comcast.net)
  411. # [23:18] * Joins: DrChirs (n=IceChat7@204-16-231-250-accuradio.pkh.ord.sparkplugbb.net)
  412. # [23:20] * othermaciej is now known as om_afk
  413. # [23:23] <gsnedders> anyone have any thoughts on me requiring requests to comply with the RFC 2616 specification, otherwise the server MUST return 400 Bad Request?
  414. # [23:24] * Joins: tantek (n=tantek@h460dc3b8.area2.spcsdns.net)
  415. # [23:26] <hsivonen> gsnedders: I guess that depends on how hard it is for the server to validate the request against RFC 2616 requirements and if such validation is needed for interop
  416. # [23:26] <gsnedders> hsivonen: IIS seems to be fairly strict already
  417. # [23:26] <hsivonen> and if interop doesn't require servers *not* to validate
  418. # [23:27] <Hixie_> (which i imagine is the case)
  419. # [23:28] * gsnedders drops email off to IIS technical product manager
  420. # [23:29] <gsnedders> in part asking if there is any reasoning why IIS is in places strict
  421. # [23:30] <hsivonen> I don't like the white space normalization step of xml:id. bad for perf
  422. # [23:34] * Quits: jruderman (n=jruderma@c-67-180-15-227.hsd1.ca.comcast.net) (Read error: 110 (Connection timed out))
  423. # [23:35] * Joins: tantek_ (n=tantek@h460df832.area2.spcsdns.net)
  424. # [23:38] * Joins: jwalden (n=waldo@STRATTON-SIX-SEVENTY-EIGHT.MIT.EDU)
  425. # [23:51] * Quits: tantek (n=tantek@h460dc3b8.area2.spcsdns.net) (Read error: 110 (Connection timed out))
  426. # [23:58] * Joins: tantek (n=tantek@adsl-63-195-114-133.dsl.snfc21.pacbell.net)
  427. # Session Close: Fri Oct 12 00:00:00 2007

The end :)