/irc-logs / w3c / #html-wg / 2008-01-16 / end

Options:

  1. # Session Start: Wed Jan 16 00:00:00 2008
  2. # Session Ident: #html-wg
  3. # [00:05] * Quits: timbl_ (timbl@128.30.5.98) (Quit: timbl_)
  4. # [00:17] * Joins: zcorpan (zcorpan@83.227.33.203)
  5. # [00:18] * Quits: aaronlev (chatzilla@66.30.196.151) (Ping timeout)
  6. # [00:22] <zcorpan> anne: s/xml-stylesheet/access-control/
  7. # [00:26] <zcorpan> anne: the answer to the first question doesn't actually answer the question
  8. # [00:35] * Quits: zcorpan (zcorpan@83.227.33.203) (Ping timeout)
  9. # [00:38] * Quits: tH (Rob@87.102.16.84) (Quit: ChatZilla 0.9.80-rdmsoft [XULRunner 1.8.0.9/2006120508])
  10. # [01:01] * Quits: Sander (svl@86.87.68.167) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
  11. # [01:02] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  12. # [01:15] * Quits: aroben (aroben@76.124.50.18) (Quit: aroben)
  13. # [01:21] * Quits: billmason (billmason@69.30.57.129) (Quit: .)
  14. # [01:24] * Joins: olivier (ot@128.30.52.30)
  15. # [01:29] * Joins: timbl (timbl@96.237.56.114)
  16. # [01:40] * Quits: Lachy (Lachlan@84.215.54.100) (Quit: Leaving)
  17. # [01:41] * Quits: mjs (mjs@17.255.110.3) (Quit: mjs)
  18. # [01:44] * Joins: Lachy (Lachlan@84.215.54.100)
  19. # [01:51] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Less talk, more pimp walk.)
  20. # [02:07] * Quits: adele (adele@17.203.15.207) (Quit: adele)
  21. # [02:27] * Joins: adele (adele@17.203.15.207)
  22. # [02:27] * Joins: mjs (mjs@17.255.110.3)
  23. # [02:30] * Quits: kingryan (kingryan@66.92.219.50) (Ping timeout)
  24. # [03:05] * Quits: adele (adele@17.203.15.207) (Quit: adele)
  25. # [03:11] * Quits: Lachy (Lachlan@84.215.54.100) (Connection reset by peer)
  26. # [03:11] * Joins: Lachy (Lachlan@84.215.54.100)
  27. # [03:36] * Joins: adele (adele@17.203.15.207)
  28. # [03:37] * Quits: adele (adele@17.203.15.207) (Quit: adele)
  29. # [03:51] * Quits: olivier (ot@128.30.52.30) (Quit: Leaving)
  30. # [04:12] * Joins: Dashimon (noone@80.202.220.46)
  31. # [04:12] * Quits: Dashiva (noone@80.202.220.46) (Connection reset by peer)
  32. # [04:12] * Dashimon is now known as Dashiva
  33. # [04:30] * Quits: sbuluf (xchl@200.49.132.117) (Ping timeout)
  34. # [04:35] * Joins: sbuluf (nwsqltc@200.49.132.91)
  35. # [04:36] * Quits: mjs (mjs@17.255.110.3) (Quit: mjs)
  36. # [04:52] * Joins: adele (adele@67.170.232.64)
  37. # [05:15] * Quits: jmb (jmb@152.78.68.189) (Ping timeout)
  38. # [05:16] * Joins: jmb (jmb@152.78.68.189)
  39. # [05:37] * Quits: adele (adele@67.170.232.64) (Client exited)
  40. # [05:38] * Joins: adele (adele@67.170.232.64)
  41. # [06:00] * Quits: inimino (weechat@75.71.88.233) (Ping timeout)
  42. # [06:35] * Quits: Zeros (Zeros-Elip@67.154.87.254) (Quit: Leaving)
  43. # [07:06] * Quits: shepazu (schepers@128.30.52.30) (Quit: Core Breach)
  44. # [07:13] * Joins: shepazu (schepers@128.30.52.30)
  45. # [07:19] * Joins: Zeros (Zeros-Elip@69.140.40.140)
  46. # [07:29] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  47. # [07:38] * Quits: sbuluf (nwsqltc@200.49.132.91) (Ping timeout)
  48. # [07:41] * Quits: heycam (cam@210.84.62.145) (Quit: bye)
  49. # [07:41] * Joins: heycam (cam@210.84.62.145)
  50. # [07:54] * Joins: mjs (mjs@64.81.48.145)
  51. # [08:10] * Joins: kingryan (kingryan@66.92.2.56)
  52. # [08:30] * Quits: Zeros (Zeros-Elip@69.140.40.140) (Quit: Leaving)
  53. # [08:33] * Quits: adele (adele@67.170.232.64) (Quit: adele)
  54. # [08:34] * Joins: adele (adele@67.170.232.64)
  55. # [08:34] * Quits: adele (adele@67.170.232.64) (Quit: adele)
  56. # [08:56] * Quits: kingryan (kingryan@66.92.2.56) (Quit: kingryan)
  57. # [09:22] * Quits: jmb (jmb@152.78.68.189) (Ping timeout)
  58. # [09:25] * Joins: jmb (jmb@152.78.68.189)
  59. # [09:27] * Joins: tH (Rob@87.102.16.84)
  60. # [09:52] * Quits: Lachy (Lachlan@84.215.54.100) (Quit: This computer has gone to sleep)
  61. # [10:07] * Joins: Lachy (Lachlan@213.236.208.22)
  62. # [10:09] * Quits: Lachy (Lachlan@213.236.208.22) (Quit: Leaving)
  63. # [10:09] * Joins: Lachy (Lachlan@213.236.208.22)
  64. # [10:19] * Joins: ROBOd (robod@89.122.216.38)
  65. # [10:41] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Client exited)
  66. # [10:43] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  67. # [10:52] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Less talk, more pimp walk.)
  68. # [11:29] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  69. # [11:42] * Joins: inimino (weechat@75.71.88.233)
  70. # [11:49] <anne> http://www.w3.org/QA/2008/01/html5-is-html-and-xml is nice
  71. # [11:49] * Joins: tH_ (Rob@87.102.83.222)
  72. # [11:50] * Quits: tH (Rob@87.102.16.84) (Ping timeout)
  73. # [11:50] * tH_ is now known as tH
  74. # [11:50] * Quits: laplink (link@193.157.66.108) (Quit: Leaving)
  75. # [11:50] <hsivonen> hmm. putting a <select> inside a <label> for another field causes undesirable default focus behavior in Firefox
  76. # [11:50] <hsivonen> I guess I should get rid of the <label>
  77. # [11:52] <MikeSmith> anne - if you responded to my question on #waf about implementations of the Access Control spec (other than the Mozilla one), I didn't see it
  78. # [11:57] <anne> I didn't reply because you were not there anymore :)
  79. # [11:58] <anne> I'm not aware of any other implementations
  80. # [12:00] * Joins: myakura (myakura@122.29.71.44)
  81. # [12:05] <MikeSmith> anne - OK, thanks
  82. # [12:35] * Quits: jgraham (james@81.86.209.97) (Quit: This computer has gone to sleep)
  83. # [12:44] <anne> 83 votes, 75 yes, 1 no, 5 abstain, and 2 fo
  84. # [12:45] <anne> differences: 73 yes, 5 abstain, 4 no, and 1 fo
  85. # [12:48] * Quits: timbl (timbl@96.237.56.114) (Quit: timbl)
  86. # [12:48] <Lachy> MikeSmith, assuming this vote passes (and we don't get 30 more no votes today), will the spec still be published, as planned, on Jan 22?
  87. # [12:50] <MikeSmith> Lachy - yeah
  88. # [12:51] <MikeSmith> absent of any acts of god that prevent it
  89. # [12:53] <Lachy> well, there is no god, so prevention is not possible. Great! :-)
  90. # [13:03] * Joins: zcorpan (zcorpan@88.131.66.80)
  91. # [14:02] <zcorpan> wow, now we have another diagram that can be included in the spec (and it's not ascii art!) http://www.w3.org/QA/2008/01/html5-is-html-and-xml
  92. # [14:03] <zcorpan> that should be as early as possible in the spec :)
  93. # [14:03] <zcorpan> or probably in the HTML vs XHTML section
  94. # [14:03] <Lachy> the arrows seem to be going the wrong way
  95. # [14:04] <zcorpan> not if you're serializing
  96. # [14:04] <Lachy> yeah, but it says parser in the circles as well
  97. # [14:05] <Lachy> they should be bi directional arrows, or just lines
  98. # [14:05] * zcorpan notes that karl uses "html" rather than "HTML" when referring to the serialization
  99. # [14:06] <anne> he also doesn't use XHTML
  100. # [14:06] <anne> (apart from the MIME type)
  101. # [14:07] <Lachy> I suggested earlier that we could change the name of the serialisation to HTMS for (Hypertext Markup Serialisation/Syntax)
  102. # [14:07] <anne> neh
  103. # [14:07] <Lachy> though it doesn't sound as good as HTML
  104. # [14:07] <zcorpan> looks like a severe typo
  105. # [14:08] <beowulf> HTMS sounds vaguely disease like
  106. # [14:08] <hsivonen> http://validator.nu/ now has file upload and textarea (JS required)
  107. # [14:08] <zcorpan> hsivonen: thanks!
  108. # [14:09] <anne> hsivonen, <html lang=en> ?
  109. # [14:09] <MikeSmith> hsivonen - beautiful
  110. # [14:09] <hsivonen> anne: ?
  111. # [14:10] <anne> add a lang attribute
  112. # [14:10] <hsivonen> anne: OK.
  113. # [14:10] <zcorpan> to the page or the template?
  114. # [14:10] <zcorpan> and why?
  115. # [14:11] <anne> because lang= is still part of HTML
  116. # [14:11] <anne> though arguably not much research has gone into it
  117. # [14:12] <zcorpan> a lot of other attributes are as well
  118. # [14:12] <zcorpan> so?
  119. # [14:12] <anne> it's good practice to use it?
  120. # [14:12] <zcorpan> yes, but not everyone who copy the template will use it for english pages
  121. # [14:12] <zcorpan> and not everyone understands or bothers to change it
  122. # [14:13] <zcorpan> hence, using lang=en for templates intended for a global audience results in pages labeled as 'en' but are not
  123. # [14:13] <hsivonen> anne: I think putting it in the template is pointless
  124. # [14:13] * zcorpan thinks putting it in the template is harmful
  125. # [14:13] * anne was talking about the homepage
  126. # [14:13] <zcorpan> aha
  127. # [14:13] * anne is confused
  128. # [14:14] <zcorpan> the template is in the textarea
  129. # [14:14] <anne> oh, that'd be silly
  130. # [14:14] <hsivonen> it might be cool to populate the textarea from show source if available
  131. # [14:15] <hsivonen> fatal errors suck, though, since they cut show source
  132. # [14:15] <zcorpan> hsivonen: when validating with textarea, the result page shows the url field instead of the textarea
  133. # [14:16] <zcorpan> also when going back in history, but i'm not sure that's fixable
  134. # [14:16] <hsivonen> zcorpan: yeah, that's because it is all on the client side
  135. # [14:17] <hsivonen> anne: lang='en' added
  136. # [14:17] <zcorpan> hsivonen: should be fixable somehow, though :)
  137. # [14:17] <hsivonen> zcorpan: yeah.
  138. # [14:18] <hsivonen> is there a clean way to persist strings in JS across a page load
  139. # [14:18] <hsivonen> that is, holding onto them in a window without putting them in site-wide cookies or anything
  140. # [14:19] <hsivonen> or is round-tripping the data via server still the way to go?
  141. # [14:19] <Lachy> isn't that what HTML5 is adding client side persistent storage for?
  142. # [14:19] <hsivonen> something like window.kungFuDeathGrip = textarea.value
  143. # [14:19] <anne> zcorpan, the answer to the first question simply explains why we have two checks in place
  144. # [14:20] <hsivonen> Lachy: isn't that site-wide instead of being in window scope?
  145. # [14:20] <Lachy> yeah, true
  146. # [14:21] <zcorpan> hsivonen: window.kungFuDeathGrip = textarea.value doesn't work
  147. # [14:21] <hsivonen> :-(
  148. # [14:22] <MikeSmith> hsivonen - btw, the html5check.py script is great to have too
  149. # [14:22] <anne> this is why HTML5 adds sessionStorage
  150. # [14:22] <MikeSmith> I wonder if somebody could get that html5check.py script packaged for Debian and what not
  151. # [14:22] <anne> but you could do it with a cookie hsivonen
  152. # [14:22] <hsivonen> MikeSmith: I'm glad its useful
  153. # [14:22] <anne> there are some simple scripts for that
  154. # [14:23] <hsivonen> anne: wouldn't that risk data leakage when I add cross-site XHR and stuff?
  155. # [14:23] * zcorpan would probably go for roundtripping to the server
  156. # [14:23] <hsivonen> anne: or cross-window leakage
  157. # [14:24] <anne> access control doesn't expose response cookies
  158. # [14:24] <anne> please see http://dev.w3.org/2006/waf/access-control/#security
  159. # [14:24] <anne> "Not to expose any trusted data of the response, such as cookies, and HTTP header data, inappropriately."
  160. # [14:25] <hsivonen> MikeSmith: I think hendry on #whatwg is the person to talk to about Debian packaging
  161. # [14:26] <anne> hsivonen, though the result page could be dependent on how you submit something now?
  162. # [14:26] <anne> s/now/no?
  163. # [14:26] <zcorpan> hsivonen: for textarea, perhaps you could do some XHR fu instead of submitting the form
  164. # [14:26] <anne> so if you submit a <textarea> the result page is based on that
  165. # [14:27] <anne> for <textarea> GET would also be nicer imo
  166. # [14:28] <zcorpan> but GET doesn't work with very large documents... iirc
  167. # [14:28] <hsivonen> anne, zcorpan: those approaches are both possibilities. I was thinking of populating the textarea from Show Source, which would be useful if you first validate a page from the Web and then want to see how a tweak would change the results
  168. # [14:28] <hsivonen> anne: I think I'm not going to do textarea with GET.
  169. # [14:28] <zcorpan> hsivonen: yep, that would also be useful
  170. # [14:29] <hsivonen> (I'm trying to avoid server-side changes that would break my carefully streaming IO.)
  171. # [14:38] <Lachy> I don't get that input type=hash proposal. Alexander keeps saying his proposal prevents the server from knowing the password. But that can't work because the server *needs* to know the password for the whole thing to work.
  172. # [14:40] <anne> sounds like <keygen>
  173. # [14:40] <Lachy> possibly.
  174. # [14:41] <anne> which we need
  175. # [14:41] <anne> though i'm not sure how it works, etc.
  176. # [14:41] <Lachy> but that still lacks any clear documentation on how it works
  177. # [14:41] <Lachy> all I know about it is the client generates a public/private key (I think) and sends it to the server.
  178. # [14:42] <Lachy> But then how exactly the server makes use of that key in the response to the client is a mystery to me.
  179. # [14:43] <Lachy> and I have no idea what the client does with the key after it submitted it, but I assume it would have to store the private key for later use
  180. # [14:43] <anne> it does
  181. # [14:47] <Philip> Lachy: It prevents the server from knowing the clear-text password that the user typed in
  182. # [14:48] <Philip> so the server will see a password like "a4a9b882fd811c31e1836c9f8f00f7d2" rather than a password like "alice07"
  183. # [14:48] <Philip> which sort of keeps the user's password a bit more hidden, particularly since users will use the same clear-text password on other sites
  184. # [14:51] <anne> Philip, are you saying you know the <keygen> processing model? :)
  185. # [14:52] <Lachy> I assume Philip is talking about the type=hash proposal
  186. # [14:52] <Philip> Oh, sorry, I was referring to the "I don't get that input type=hash proposal." thing
  187. # [14:52] <Philip> I know nothing about <keygen> :-)
  188. # [14:53] <Lachy> Philip, but the server would at least need to know the password when the user registers, even if it only stores the hashed version in its DB.
  189. # [14:54] <Philip> Lachy: The client could sent hash(pw) when registering
  190. # [14:55] <Philip> so the server will never be able to know pw
  191. # [14:55] <Lachy> so then you're effectively just changing the password from "alice07" to "a4a9b882fd811c31e1836c9f8f00f7d2"
  192. # [14:55] <Philip> Yes
  193. # [14:55] <Philip> which means the evil server admin can't find out that Alice has the password "alice06" on this other site she joined a year earlier
  194. # [14:55] <Lachy> in order for the server to verify that hash(password + salt + replaysalt) sent by the client is correct, it would need to perform the same operation on the server side
  195. # [14:55] <Philip> which isn't a really compelling advantage
  196. # [14:56] <Philip> Lachy: The initial suggestion was hash(hash(password + salt) + replaysalt)
  197. # [14:57] <Lachy> whatever
  198. # [14:57] <Philip> and the server gets sent hash(password + salt) when registering
  199. # [14:57] <Philip> (so it still doesn't need to know password)
  200. # [14:58] <Lachy> so any attacker can just find out what hash(password+salt) is during registration, and then obtain the replay salt from the login page and their in
  201. # [14:58] <Lachy> s/their/they're/
  202. # [14:59] <Philip> Yes
  203. # [14:59] <Lachy> so, basically, the proposal doesn't really solve anything. It provides the illusion of security
  204. # [14:59] <Philip> They're in to any site which has the same salt, and for which the user uses the same password
  205. # [15:00] <Philip> and if the attacker controls the registration process of one site, they can set the salt to match any other site's salt, so they can find hash(password + that other site's salt)
  206. # [15:00] <Lachy> yep
  207. # [15:01] <Lachy> better security would be obtained by the user using a utility to generate something like "a4a9b882fd811c31e1836c9f8f00f7d2" as their password and use that.
  208. # [15:02] <Philip> It's useful security if you can register via a trusted network, and then have to log in later on an untrusted network
  209. # [15:03] <Philip> except not really since somebody on the untrusted network could just hijack your session after you've logged in
  210. # [15:03] <Lachy> I don't think it's worth it. SSL and TLS are the solution.
  211. # [15:04] <Philip> I guess replaysalt would interact badly with caches
  212. # [15:05] <Lachy> yes, especialy if the login form was on every page
  213. # [15:06] * Joins: timbl (timbl@128.30.5.98)
  214. # [15:08] <Philip> Is it possible to use SSL/etc without signed certificates, so you get no proof of identity but you do get protection from eavesdroppers and you don't get ugly browser security warnings?
  215. # [15:11] * Parts: timbl (timbl@128.30.5.98)
  216. # [15:15] <Lachy> you can use self-signed certificates, but browsers issue warnings about it
  217. # [15:16] <Lachy> I want a self signed certificiate for things like logging into the blog admin on my site
  218. # [15:16] <Philip> The warnings make it unusable
  219. # [15:16] <Lachy> indeed, for most uses
  220. # [15:31] * Joins: aaronlev (chatzilla@66.30.196.151)
  221. # [15:47] <zcorpan> Philip: thanks, you gave me a good laugh with your "Blah blah" sentences in the suggested spec text... :D
  222. # [15:47] * zcorpan waits for Hixie to copy-paste that into the spec
  223. # [15:49] <zcorpan> ( http://www.w3.org/mid/478D5CE5.7060502@cam.ac.uk )
  224. # [16:09] <Philip> Oh, that was just to save some space by not copying-and-pasting uninteresting chunks of spec text
  225. # [16:23] * Quits: drry (drry@222.225.140.32) (Connection reset by peer)
  226. # [16:27] * Joins: aroben (aroben@76.124.50.18)
  227. # [16:28] * Joins: drry (drry@222.225.140.32)
  228. # [16:32] <hsivonen> I wonder if there was a good reason to put textContent as opposed to innerText into the DOM...
  229. # [16:45] * Joins: DanC (connolly@128.30.52.30)
  230. # [16:48] * Joins: billmason (billmason@69.30.57.129)
  231. # [16:56] <anne> I've been told innerText is different
  232. # [16:56] <hsivonen> anne: how?
  233. # [16:56] <gavin> one includes text from child nodes, I think?
  234. # [16:57] <hsivonen> that would be textContent
  235. # [16:58] <hsivonen> from MSDN: @The innerText property is valid for block elements only.@
  236. # [16:58] <hsivonen> sigh
  237. # [16:58] <hsivonen> s/@/"/
  238. # [16:59] <gavin> I think I'm misremembering the childnode difference
  239. # [16:59] <anne> yes
  240. # [16:59] <anne> MSDN is wrong
  241. # [17:03] <hsivonen> well, I can't even test in IE, so I deployed the script with this: // If you want this to work in IE, patches welcome
  242. # [17:04] * Quits: myakura (myakura@122.29.71.44) (Quit: Leaving...)
  243. # [17:08] <zcorpan> innerText works on any element
  244. # [17:08] * zcorpan doesn't know what the difference is, if there is any
  245. # [17:09] <zcorpan> well, at least getting works on any element
  246. # [17:09] <zcorpan> setting raises an exception on some elements (like <html>, <input>)
  247. # [17:09] <hsivonen> I only need the getter
  248. # [17:11] * Quits: Lachy (Lachlan@213.236.208.22) (Quit: This computer has gone to sleep)
  249. # [17:12] <hsivonen> zcorpan: ok. deployed innerText without testing
  250. # [17:12] * Parts: beowulf (beowulf@208.113.221.22)
  251. # [17:14] <zcorpan> hsivonen: seems to work in ie6
  252. # [17:14] <hsivonen> zcorpan: good. thanks
  253. # [17:16] <zcorpan> "XMLNSÂ Filter" hmm, apparently my ie6 thinks that validator.nu is windows-1252
  254. # [17:17] <zcorpan> (encoding is "auto-select" in the menu)
  255. # [17:17] <zcorpan> which is really weird
  256. # [17:18] <hsivonen> zcorpan: web-sniffer.net says the header is text/html; charset=utf-8
  257. # [17:18] <hsivonen> which should be fine...
  258. # [17:18] <zcorpan> yeah. that's why it's weird
  259. # [17:20] <zcorpan> a forced reload makes it utf-8
  260. # [17:20] * zcorpan leaves it at that
  261. # [17:22] * zcorpan tries to validate the html5 spec with show source
  262. # [17:25] <zcorpan> ...
  263. # [17:25] <hsivonen> at least other threads keep serving requests...
  264. # [17:25] * hsivonen is trying to validate the spec concurrently as well
  265. # [17:27] <hsivonen> hmm. looks CPU-bound
  266. # [17:27] * anne tries the W3C version for added joy
  267. # [17:27] <hsivonen> real memory seems to be sufficient
  268. # [17:28] <anne> "Internal Error: Oops. That was not supposed to happen. A bug manifested itself in the application internals. Unable to continue. Sorry. The admin was notified."
  269. # [17:28] <hsivonen> I got the result back but source wasn't shown
  270. # [17:28] * zcorpan is still waiting
  271. # [17:28] * hsivonen checks email
  272. # [17:30] <hsivonen> hah. the Schematron impl ran out of memory
  273. # [17:31] <hsivonen> see! I was right! it does make sense to avoid tree building in a validator.
  274. # [17:31] <hsivonen> now I only need to replace the Schematron schema with something that doesn't build a tree
  275. # [17:32] <hsivonen> fwiw: one thread: java.lang.ArrayIndexOutOfBoundsException: 84968 at org.apache.xml.utils.StringVector.addElement(StringVector.java:108) at org.apache.xml.dtm.ref.sax2dtm.SAX2DTM.setSourceLocation(SAX2DTM.java:974)
  276. # [17:33] <hsivonen> another: java.lang.OutOfMemoryError: Java heap space at java.lang.Object.clone(Native Method) at org.apache.xpath.axes.PredicatedNodeTest.clone(PredicatedNodeTest.java:90)
  277. # [17:33] <anne> can't you replace schematron with custom java code?
  278. # [17:33] <hsivonen> anne: yes, I can
  279. # [17:33] <anne> that does simple traversal
  280. # [17:34] <hsivonen> now I have a better reason to. previously that task seemed more theoretical
  281. # [17:34] <Philip> hsivonen: Alternatively, it makes sense to do tree building because it means the validator will run out memory and abort, rather than running almost forever on a huge document and using up all the CPU time that other people want to share
  282. # [17:35] <hsivonen> Philip: the size of the input doc is limited in terms of # of bytes
  283. # [17:35] <Philip> Oh
  284. # [17:35] * Joins: Lachy (Lachlan@84.215.54.100)
  285. # [17:35] * Quits: Lachy (Lachlan@84.215.54.100) (Client exited)
  286. # [17:35] * Joins: Lachy (Lachlan@84.215.54.100)
  287. # [17:37] <hsivonen> Philip: pretty much everything expect the schematron part is designed to have memory requirements that grow at most linearly relative to input byte size
  288. # [17:37] <hsivonen> (although I don't know the exact perf characteristings of the RELAX NG engine)
  289. # [17:42] <hsivonen> and like I blogged, the Xerces regexp engine has bad perf characteristics compared to what is necessary to implement the XSD regexp spec
  290. # [17:49] * Quits: gavin_ (gavin@99.227.30.12) (Ping timeout)
  291. # [17:51] * Philip sees that the IPv4 TOS byte's definition has been really quite unstable over its history, and concludes that nobody will mind if he totally ignores the RFCs and uses it for something else
  292. # [17:51] * Joins: gavin_ (gavin@99.227.30.12)
  293. # [17:54] * Joins: matt (matt@128.30.52.30)
  294. # [18:01] <zcorpan> aha! innerText replaces linebreaks with <br>s
  295. # [18:01] <zcorpan> on setting
  296. # [18:03] <zcorpan> and <br>s turn into \r\n on getting
  297. # [18:05] <hsivonen> zcorpan: thanks. not a problem in my case
  298. # [18:06] <hsivonen> does alt='' participate in innerText?
  299. # [18:07] * Quits: matt (matt@128.30.52.30) (Ping timeout)
  300. # [18:15] * Joins: matt (matt@128.30.52.30)
  301. # [18:16] * Joins: gsnedders (gsnedders@217.42.133.143)
  302. # [18:17] <zcorpan> hsivonen: no
  303. # [18:18] <zcorpan> also, on getting, linebreaks (in text nodes) are turned into spaces
  304. # [18:18] <zcorpan> except if the element was <pre> (perhaps some others, too)
  305. # [18:19] <Philip> Does CSS white-space:pre affect linebreaks in innerText?
  306. # [18:20] <hsivonen> Safari and Opera supposedly support innerText. I wonder how faithfully to IE.
  307. # [18:23] <zcorpan> Philip: thankfully, no
  308. # [18:23] <zcorpan> opera's implementation is different from ie
  309. # [18:24] * zcorpan finds further funny features when the element contains <style>s or <script>s
  310. # [18:26] <zcorpan> or <comment> :)
  311. # [18:27] <zcorpan> oh wait, <comment>s don't have child nodes
  312. # [18:34] * Joins: Sander (svl@86.87.68.167)
  313. # [19:02] * Quits: mjs (mjs@64.81.48.145) (Quit: mjs)
  314. # [19:03] * matt is now known as matt-nap
  315. # [19:03] * Quits: matt-nap (matt@128.30.52.30) (Quit: matt-nap)
  316. # [19:18] * Joins: adele (adele@17.203.15.207)
  317. # [19:26] <zcorpan> haha... elements' 'display' affects innerText
  318. # [19:26] <zcorpan> X<span style=display:block></span>Y
  319. # [19:26] <zcorpan> X<p style=display:inline></p>Y
  320. # [19:31] <Philip> Not really following the ideas of separation of presentation and content
  321. # [19:36] <zcorpan> or float or position
  322. # [19:44] * MikeSmith is now known as Mike^mail
  323. # [19:53] <zcorpan> it might make sense to make sure that the html4-differences document is properly aligned with the spec before publishing
  324. # [19:53] <zcorpan> ...the html4-differences document
  325. # [19:54] <Philip> s/might/would/
  326. # [19:54] <Philip> Can't be that big a diff to check through, surely
  327. # [19:56] * Philip wonders if hsivonen has an automatically-extracted list of all current elements and attributes, so it can be compared to the list from when html4-differences was last updated
  328. # [20:04] * Parts: zcorpan (zcorpan@88.131.66.80)
  329. # [20:06] * Joins: mjs (mjs@17.255.110.3)
  330. # [20:47] <anne> i'm fine with making some updates
  331. # [20:58] * Joins: dbaron (dbaron@63.245.220.229)
  332. # [21:05] * Mike^mail is now known as MikeSmith
  333. # [21:09] * jgraham_ is somewhat unimpressed by the argument from authority being used on security matters on public-appformats
  334. # [21:10] <jgraham_> (the conclusion may be valid, I don't know, but the reasoning isn't)
  335. # [21:11] <anne> who is doing that?
  336. # [21:13] <mjs> jgraham_: archive link?
  337. # [21:13] <anne> i agree that the situation is pretty bad
  338. # [21:13] <anne> i'm just wondering if you think it's me :)
  339. # [21:27] <shepazu> jgraham_, I'm not using the argument from authority... I just think it's appropriate that experts do review the spec and that their advice be considered
  340. # [21:27] <shepazu> do you disagree with that?
  341. # [21:28] <anne> shepazu, did you even comment about that on public-appformats?!
  342. # [21:29] <shepazu> no, but I've been commenting on #waf
  343. # [21:30] <anne> seems hard for jgraham_ to comment on that
  344. # [21:30] <shepazu> I'm not saying that jgraham_ said it was me that raised the argument
  345. # [21:30] <shepazu> you misunderstood
  346. # [21:32] <jgraham_> Sorry, been away
  347. # [21:33] <jgraham_> The sentence I disliked was "I'm not sure if JSONRequest is perfect [...] but it was designed by Doug Crockford, who gives talks at Ajax conferences on web security, and IMO he has a good handle on security issues"
  348. # [21:33] * Quits: gsnedders (gsnedders@217.42.133.143) (Quit: gsnedders)
  349. # [21:35] <jgraham_> Which didn't seem like an acceptable reason for preferring the security model of JSONRequest (although it might indeed be a good reason to get Doug Crockford to comment on his design rationale and on the access control spec)
  350. # [21:35] <shepazu> jgraham_, fair enough
  351. # [21:36] <anne> Doug Crockford commented and said that JSONRequest was the way to go
  352. # [21:36] <anne> great guy
  353. # [21:36] <mjs> JSNORequest does not in fact have a viable security model
  354. # [21:37] <mjs> I'm not sure Doug Crockford has a good understanding of security issues
  355. # [21:49] * Joins: jgraham (james@81.86.209.97)
  356. # [21:51] * Quits: jgraham (james@81.86.209.97) (Quit: This computer has gone to sleep)
  357. # [21:53] * Joins: jgraham (james@81.86.209.97)
  358. # [21:54] * Quits: shepazu (schepers@128.30.52.30) (Quit: Core Breach)
  359. # [21:55] * Joins: shepazu (schepers@128.30.52.30)
  360. # [22:24] * Joins: Zeros (Zeros-Elip@67.154.87.254)
  361. # [22:30] * Quits: ROBOd (robod@89.122.216.38) (Quit: http://www.robodesign.ro )
  362. # [22:31] * Quits: Hixie (ianh@129.241.93.37) (Ping timeout)
  363. # [22:37] * Joins: Hixie (ianh@129.241.93.37)
  364. # [22:57] * Quits: mjs (mjs@17.255.110.3) (Quit: mjs)
  365. # [22:59] * Joins: adele_ (adele@17.255.96.178)
  366. # [22:59] * Quits: adele_ (adele@17.255.96.178) (Client exited)
  367. # [22:59] * Joins: adele_ (adele@17.255.96.178)
  368. # [23:01] * Quits: adele (adele@17.203.15.207) (Ping timeout)
  369. # [23:02] * Joins: mjs (mjs@17.255.110.3)
  370. # [23:19] * Joins: zcorpan (zcorpan@83.227.33.203)
  371. # [23:30] * Quits: Lachy (Lachlan@84.215.54.100) (Quit: Leaving)
  372. # [23:32] * Joins: sbuluf (talez@200.49.132.72)
  373. # [23:36] * Quits: zcorpan (zcorpan@83.227.33.203) (Ping timeout)
  374. # [23:37] * Quits: aaronlev (chatzilla@66.30.196.151) (Ping timeout)
  375. # [23:44] * Joins: Lachy (Lachlan@84.215.54.100)
  376. # [23:45] <Hixie> shepazu: just saw the acid3 discussion in the svg wg -- just wanted to say that i'm certainly open to good tests, but they have to fit the rules of the competition, like all the other tests for the competition
  377. # [23:45] <Hixie> none of the tests mentioned so far come close
  378. # [23:46] <shepazu> hmmm, okay... naturally, we'd want it to match the criteria... maybe you could explain what's missing?
  379. # [23:46] <shepazu> I know the Renesis one was off-base
  380. # [23:47] <shepazu> maybe we need to study the Acid3 tests better... but it would be helpful if you could provide a frinstance
  381. # [23:48] <Hixie> http://www.hixie.ch/tests/evil/acid/003/competition/
  382. # [23:49] <Hixie> if you can't run the test using that, then it doesn't fit the rules
  383. # [23:51] * Joins: adele (adele@17.203.15.207)
  384. # [23:52] * Quits: adele_ (adele@17.255.96.178) (Ping timeout)
  385. # [23:53] <shepazu> ok, cool, thanks
  386. # [23:54] <shepazu> btw, you might put the closing date instead of "one week"
  387. # [23:54] <shepazu> since the form isn't dated
  388. # [23:54] <Lachy> shepazu, the blog entry about it was dated
  389. # [23:55] <Hixie> yeah, good point
  390. # [23:55] <Hixie> copy and paste snafu :-)
  391. # [23:56] <Philip> shepazu: That gives a mild sense of urgency and encourages people to submit soon, without actually fixing the deadline and thus allowing it to be extended indefinitely if nobody submits any tests
  392. # [23:56] <shepazu> clever :)
  393. # [23:57] <Hixie> i've put in the deadline
  394. # [23:57] <Hixie> (sunday)
  395. # [23:57] <shepazu> thanks
  396. # [23:58] <shepazu> Sunday!!!! Hixie, you can't do that! that's the Lord's Day, a day of rest!
  397. # [23:58] <Hixie> the Lord?
  398. # [23:58] <shepazu> President Bush, of course
  399. # [23:59] <Hixie> i don't recognise bush as my lord.
  400. # [23:59] <shepazu> you're unamerican!
  401. # [23:59] <Lachy> I doubt he'd have the intelligence to be able to write a test, so who cares if he's resting?
  402. # [23:59] <Hixie> (if i don't have enough submissions by sunday, i'll probably just use things that do pass today but used to famously fail)
  403. # Session Close: Thu Jan 17 00:00:00 2008

The end :)