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

Options:

  1. # Session Start: Sat Jan 12 00:00:00 2008
  2. # Session Ident: #html-wg
  3. # [00:02] <anne> am now
  4. # [00:07] <jgraham> public-tss-testsuite?
  5. # [00:07] <anne> ah, I found http://www.w3.org/2007/11/09-html-wg-minutes.html
  6. # [00:09] <jgraham> Oh I see.
  7. # [00:11] * Quits: timbl (timbl@96.237.56.114) (Ping timeout)
  8. # [00:11] * Joins: timbl (timbl@96.237.56.114)
  9. # [00:11] <Hixie> er
  10. # [00:11] <Lachy> would have been nice if that MIT licence issue was mentioned on one of the HTMLWG mailing lists at the time. The first I heard about it was in the public-css-testsuite thread.
  11. # [00:11] <Hixie> jgraham: public-css-testsuite is what i meant
  12. # [00:12] * anne was looking for the HTML WG reference regarding MIT
  13. # [00:13] <jgraham> yeah, I worked it out (it was pretty obvious really)
  14. # [00:13] * anne doesn't think it's a great reference but can't find anything better
  15. # [00:13] <Lachy> I didn't even notice the typo, and what wondering why you questioned it.
  16. # [00:15] <Hixie> heh
  17. # [00:18] * Quits: aroben (aroben@71.58.127.126) (Quit: aroben)
  18. # [00:19] <anne> we're over fifty now
  19. # [00:19] <anne> (votes)
  20. # [00:19] <gsnedders> and members?
  21. # [00:19] <gsnedders> sorry anne, I'll go revise soon :P
  22. # [00:20] * anne is confused
  23. # [00:20] * Quits: jgraham (james@81.86.210.78) (Quit: This computer has gone to sleep)
  24. # [00:20] <gsnedders> anne: you advised me to revise for exams not work on specs
  25. # [00:20] * Quits: timbl (timbl@96.237.56.114) (Ping timeout)
  26. # [00:20] <gsnedders> and here I am not revising
  27. # [00:20] <anne> i see
  28. # [00:20] <anne> seven members
  29. # [00:20] <anne> well, seven orgs
  30. # [00:21] <gsnedders> and we need 14.
  31. # [00:21] <gsnedders> ow.
  32. # [00:21] <anne> yeah...
  33. # [00:21] <gsnedders> MS/Chris Wilson have removed their vote for some reason
  34. # [00:21] <anne> there's a reminder, lets wait another day
  35. # [00:22] <anne> oh, they already voted?
  36. # [00:22] <gsnedders> yeah, I saw one earlier.
  37. # [00:22] <gsnedders> No and Yes was the vote
  38. # [00:23] <Hixie> i didn't know you could remove your vote
  39. # [00:23] <gsnedders> Hixie: "You may completely remove your response from our records. As this operation is not reversible, please confirm your desire to delete your answers by first checking this box:"
  40. # [00:23] <gsnedders> Hixie: bottom of the form.
  41. # [00:25] <Hixie> ah
  42. # [00:25] <Hixie> weird
  43. # [00:25] <Hixie> why would they vote then unvote
  44. # [00:25] <anne> "SVG <script> Should Have @charset" euh
  45. # [00:26] <shepazu> you disagree?
  46. # [00:27] <mjs> for inline scripts?
  47. # [00:27] <mjs> or external scripts?
  48. # [00:27] <anne> external i guess
  49. # [00:27] <shepazu> external
  50. # [00:27] * Hixie sighs again at the quagmire that the waf wg has ended up in
  51. # [00:27] <mjs> seems like in the former case it would be insane (no reason not to use the document encoding) and in the latter case it would be useless (MIME types can have a charset parameter)
  52. # [00:28] <anne> Hixie, http://www.hollywoodstandups.com/images/quagmire.jpg ? :D
  53. # [00:28] <mjs> it would be actively harmful if charset interpretation of a script was based on which document embeds it
  54. # [00:28] * anne loves family guy
  55. # [00:28] * Joins: timbl (timbl@96.237.56.114)
  56. # [00:28] <mjs> Hixie: accept-charset getting bogged down?
  57. # [00:28] * Quits: Lachy (Lachlan@84.215.54.100) (Ping timeout)
  58. # [00:29] <Hixie> anne: more like http://someonesaygrace.blogspot.com/2007/09/quagmire.html
  59. # [00:29] <Hixie> mjs: access-control
  60. # [00:29] <mjs> er
  61. # [00:29] <mjs> yeah, that's what I was thinking of, I think my aphasia is getting worse
  62. # [00:30] <shepazu> mjs, that's a good point... how is HTML dealing with the script @charset?
  63. # [00:30] * anne wonders how many browsers support it
  64. # [00:31] <anne> if you want to solve the problem you should not solve it in SVG
  65. # [00:31] * shepazu suspects that mjs' argument was the reason it was left out in the first place
  66. # [00:31] <anne> but rather inventing some kind of @charset for JS
  67. # [00:32] <shepazu> anne, that doesn't make sense
  68. # [00:32] <mjs> text/javascript; charset=utf8
  69. # [00:32] <anne> shepazu, that doesn't help
  70. # [00:32] <mjs> I'm not sure how you would sensibly do in-content charset declaration
  71. # [00:33] <anne> @charset in CSS works reasonable
  72. # [00:33] * Joins: Lachy (Lachlan@84.215.54.100)
  73. # [00:33] <anne> the HTML way is pretty crappy
  74. # [00:34] <gsnedders> the XML way sorta works
  75. # [00:34] <shepazu> ah, anne, you mean an import declaration, not an attribute... ok, that makes more sense
  76. # [00:34] <anne> XML allows an inifite amount of whitespace
  77. # [00:34] <anne> infinite, even
  78. # [00:35] <shepazu> I thought you were saying that JS should define the attributes of the svg:script element
  79. # [00:35] * gsnedders thinks someone should create an infinite loop that serves an XML document with nothing but whitespace
  80. # [00:35] <anne> -_-
  81. # [00:36] <gsnedders> just to see what breaks.
  82. # [00:36] <gsnedders> I mean, we already have infinite HTML documents out there.
  83. # [00:37] <shepazu> ok, I'll comment on the mozilla bug and close my own SVG bug
  84. # [00:37] <shepazu> thanks, mjs
  85. # [00:37] <anne> your own bug has the wrong references btw
  86. # [00:38] <anne> 4106 is a bit too old for any SVG related work on Gecko
  87. # [00:38] * Joins: jgraham (james@81.86.210.78)
  88. # [00:39] <shepazu> ah, cp error, thanks
  89. # [00:42] <anne> http://it.slashdot.org/comments.pl?sid=414942&cid=22002054
  90. # [00:43] * Quits: adele (adele@17.203.15.207) (Quit: adele)
  91. # [00:44] <Philip> I was wondering a while ago what the average size of HTML pages was, but then I realised there was probably at least one endless page on the internet and so the average would simply be infinite
  92. # [00:47] <jgraham> The median would be finite though
  93. # [00:48] <Philip> The median doesn't seem an especially useful thing to know
  94. # [00:49] <jgraham> In many situations it's a better measure of the underlying population average than the mean
  95. # [00:49] <jgraham> But I can't remember exactly what those situations are :)
  96. # [00:49] <Philip> The mean is interesting because you know that downloading n pages will use n*k bytes of bandwidth / disk space, as long as you limit the maximum
  97. # [00:50] <Philip> (*maximum per page)
  98. # [00:51] <jgraham> I think the median will be a good estimator there too, but I'd have to check some stats notes I didn't really understand in the first place
  99. # [00:51] <Philip> http://triin.net/archive/kool/webstat/figure-8.png is apparently the distribution
  100. # [00:53] * jgraham goes to look at the notes
  101. # [00:54] <anne> Hixie, now you're online, what's the use case for testing NULL in Acid3?
  102. # [00:55] <anne> actually, what use cases are currently prohibited by Opera not supporting NULL in the DOM
  103. # [00:55] <Philip> (Presumably the mean will be higher than the median, because the big pages will have a much stronger effect than the small pages)
  104. # [00:56] <Hixie> anne: ?
  105. # [00:56] <Philip> NULL == "\0"?
  106. # [00:56] * Quits: smedero (smedero@192.223.6.251) (Quit: smedero)
  107. # [00:56] <Hixie> anne: oh you mean zero bytes? zero bytes are often used as ways to smuggle data in in security attacks
  108. # [00:57] <mjs> silently stripping 0 bytes is bad for security
  109. # [00:57] <Hixie> anne: it's important that a browser react the same way to \0 as to any other element, otherwise some code expecting, e.g., "bad\0good" to be different from "bad" will have an attack vector
  110. # [00:57] <mjs> because it defeats attempts at content filtering
  111. # [00:58] <anne> we're not stripping
  112. # [00:58] <Hixie> they're terminating, which is even worse
  113. # [00:58] <mjs> terminating at 0 bytes is also bad
  114. # [00:59] <mjs> not sure if it is worse (depends on the specific circumstance)
  115. # [00:59] <Hixie> i guess
  116. # [00:59] <mjs> many content filtering scripts search for magic strings so \0 in the middle of its search term getting silently stripped is the really bad case
  117. # [00:59] * Joins: adele (adele@17.203.15.207)
  118. # [01:04] <Hixie> yeah
  119. # [01:07] <anne> so re: access control madness, i guess i could write up a simple design decision faq
  120. # [01:08] <anne> do you think that would help Hixie?
  121. # [01:08] * anne isn't too convinced
  122. # [01:08] <Hixie> can't hurt i guess
  123. # [01:08] <anne> yeah
  124. # [01:08] <Hixie> the problem is that the people asking for the requirements are people who disagree with the requirements
  125. # [01:08] <Hixie> they just want the requirements so that they can explain that they disagree with them
  126. # [01:09] <anne> i know
  127. # [01:09] <anne> it sucks
  128. # [01:18] <anne> i don't really understand the "server-side model"
  129. # [01:18] <anne> hmm
  130. # [01:18] <Hixie> yeah i don't understand how the UA can't be the PEP here
  131. # [01:18] <Hixie> i mean the server can help, obviously
  132. # [01:18] <Hixie> but ultimately if the server returns data, it's the client that decides what to do with it
  133. # [01:19] <Hixie> and all servers today return data...
  134. # [01:25] * jgraham wonders if the thing he was half remembering about medians is just the part about reconstructing noisy data, where removing outliers is the problem
  135. # [01:25] <jgraham> I thought there was something about more general use of the median but I either imagined it or can't find it now
  136. # [01:27] <mjs> a pure server-side model could not be secure since today's servers don't know about it
  137. # [01:27] <mjs> if the client opens up cross-site access, it needs to fail on existing servers
  138. # [01:27] <mjs> given that, the client has to do at least part of the logic to deny access
  139. # [01:28] <mjs> so it may as well do as much as possible, so security policy is in one place
  140. # [01:28] <anne> I need some input: http://annevankesteren.nl/temp/access-control-faq
  141. # [01:28] <mjs> (but it would also be ok to design the protocol so the server could deny access too, for defense in depth)
  142. # [01:29] <anne> maybe I should mention ScriptTrapOptions
  143. # [01:29] <Philip> Statistics is almost as much fun as designing security protocols, since there are lots of subtle but significant ways to get it wrong and no way to tell when you've got it right
  144. # [01:31] <jgraham> Fortunately I managed to avoid the part of astrophysics that requires serious statistics
  145. # [01:31] * Quits: Sander (svl@86.87.68.167) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
  146. # [01:32] <jgraham> anne: If there are technical difficulties with using OPTIONS on apache you should specify what they are
  147. # [01:32] * Joins: Sander (svl@86.87.68.167)
  148. # [01:32] * Quits: Zeros (Zeros-Elip@67.154.87.254) (Quit: Leaving)
  149. # [01:32] <anne> well, you never "catch" the options request with the script
  150. # [01:33] <jgraham> where by "technical" I mean "not related to access to the apache config"
  151. # [01:34] <anne> hmm, Hixie had the exact details
  152. # [01:34] <anne> I simply never got it to work
  153. # [01:34] <anne> Hixie figured out it works on some servers by using ScriptTrapOptions and not having installed some other module
  154. # [01:36] <anne> ah, mod_dav
  155. # [01:36] <jgraham> (I'm not disputing that issues exist btw; I have no idea either way)
  156. # [01:37] <anne> added the technical info
  157. # [01:37] * Philip sees e.g. http://issues.apache.org/bugzilla/show_bug.cgi?id=15242
  158. # [01:38] * Quits: Sander (svl@86.87.68.167) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
  159. # [01:43] <anne> I guess it's just mod_dav that's left then
  160. # [01:45] <anne> then again, what does mod_php do etc.
  161. # [01:47] <anne> Hixie, look what I just found: http://www.mnot.net/blog/2005/04/03/options
  162. # [01:47] <anne> -_-
  163. # [01:48] <Philip> If I send an OPTIONS request to a CGI script on a fairly plain Apache 2.2.6 then it works fine
  164. # [01:50] <anne> is mod_dav enabled?
  165. # [01:53] <shepazu> mjs, it's my understanding that W3C doesn't and shouldn't vote on things like this... if they should, it should be a single vote from the organization as a whole, representing the director's decision, not as 3 separate hosts (IMO)... this may affect the number of Member votes required (dunno if DanC took that into account)
  166. # [01:54] <Philip> On a different installation of the same version of Apache, the CGI script works with and without mod_dav enabled
  167. # [01:55] <shepazu> mjs, maybe we could contact the Member reps directly to ask them to vote... would you like me to do that?
  168. # [01:55] <anne> Hixie, ^^
  169. # [01:57] <anne> thanks Philip
  170. # [01:57] <Philip> (mod_dav is sufficiently enabled that it shows me an SVN repository)
  171. # [01:57] <Philip> (and a Perl CGI script runs and has $ENV{REQUEST_METHOD} = 'OPTIONS')
  172. # [01:58] <mjs> shepazu: the W3C has voted on previous surveys
  173. # [01:58] <mjs> shepazu: sure, I'd appreciate you contacting member reps
  174. # [01:58] <shepazu> ok, I'll leave that bit up to MikeSmith
  175. # [01:58] <anne> what's the equivalent in Python Philip?
  176. # [01:59] <shepazu> ok, thanks for doing the legwork on sorting them out, and calling attention to it
  177. # [01:59] <Philip> OPTIONS also works the same on a simple lighttpd 1.4.18
  178. # [01:59] <mjs> shepazu: Mozilla has voted now btw
  179. # [01:59] <mjs> shepazu: yeah, I didn't want us to end up in an indeterminate state on account of quorum
  180. # [01:59] <Philip> anne: import os; os.environ
  181. # [02:01] <shepazu> cool... wonder if your email will get enough notice... I would wait a few days to see, but it's Friday... I'll prepare an email and ask MikeSmith to send it (he is the TC)
  182. # [02:15] <Philip> (OPTIONS also works with mod_php on the non-mod_dav Apache)
  183. # [02:16] <anne> you're implying it does not work on the other?
  184. # [02:16] * Quits: adele (adele@17.203.15.207) (Quit: adele)
  185. # [02:16] <Philip> I haven't got PHP installed on the other
  186. # [02:18] <Hixie> anne: the fact that there are so many issues with it IMHO is reason enough to stay the hell away
  187. # [02:18] <Hixie> frankly i don't understand why we need to use options
  188. # [02:18] <Hixie> i am starting to think we should drop options from http altogether
  189. # [02:19] <Hixie> (and move it to webdav)
  190. # [02:19] <Philip> Ah, now I've got PHP installed on the other, and it still works there
  191. # [02:20] * Joins: adele (adele@17.203.15.207)
  192. # [02:20] <anne> Hixie, it does work for me
  193. # [02:21] <anne> using like five lines of Python
  194. # [02:21] <Hixie> yeah i think i eventually got it to work after dreamhost upgraded me recently
  195. # [02:21] <Hixie> i posted about this a few weeks ago
  196. # [02:21] <anne> maybe I missed it
  197. # [02:21] <anne> pointer?
  198. # [02:22] <anne> in general though dealing with os.environ or the equivalent for PHP (whatever that is) is something I typically don't do...
  199. # [02:22] <Hixie> i don't know off hand
  200. # [02:23] <anne> in PHP I used $_GET and $_POST and that was about it as far as HTTP was concerned
  201. # [02:23] <anne> use, rather
  202. # [02:23] <Philip> $_SERVER["REQUEST_METHOD"]
  203. # [02:23] <Hixie> what's wrong with using GET?
  204. # [02:23] <Hixie> that's what i don't understand
  205. # [02:23] <Hixie> the only arguments i've heard are theoretical and potential
  206. # [02:25] <anne> GET could be cached
  207. # [02:25] <anne> I'm not particularly convinced by the size argument
  208. # [02:26] <anne> Jonas also seems to favor OPTIONS
  209. # [02:26] <mjs> GET could be cached if marked cacheable
  210. # [02:26] <mjs> is there actually a rule that you can never cache OPTIONS?
  211. # [02:27] <mjs> and if so, is that a plus or minus?
  212. # [02:27] <Hixie> isn't the caching a GET a good thing?
  213. # [02:27] <anne> no
  214. # [02:27] <anne> not for the authorization request
  215. # [02:27] <Hixie> why not? we're explicitly caching that anyway! hwe're making up our own cache for it!
  216. # [02:27] <mjs> the client can mark it uncacheable if you shouldn't cache the authorization reply
  217. # [02:28] <mjs> er, the server I mean
  218. # [02:28] <anne> mjs, HTTP section 9.2 says "Responses to this method are not cacheable."
  219. # [02:28] <anne> Hixie, yes, but our own cache uses the referer-root as key
  220. # [02:28] <mjs> the reply should probably include a Vary header listing the access-control-relevant headers
  221. # [02:29] <jgraham> The argument about not wanting to GET a large resource before DELETEing it made some sense to me, but I haven't followed this closely so it may not be significant
  222. # [02:30] <jgraham> Does Vary work in practice?
  223. # [02:30] <Hixie> well i don't care as much about the OPTIONS vs GET issue relative to the rest of the issues, but i am sure that if we use OPTIONS we will have all kinds of authoring problems in the future
  224. # [02:30] <anne> Hixie, say example.org shares a resource with foo.org and bar.org but only lists the domain in access-control if the referer-root is ok; if in that case the GET is cached for an initial interchange with foo.org bar.org is not usable
  225. # [02:30] <Hixie> anne: in that kind of case, why can't the server just set no-cache?
  226. # [02:30] <mjs> anne: then example.org should set either Cache-control: no-cache or Vary: Referer-root
  227. # [02:31] <mjs> in the reply
  228. # [02:31] <anne> fair enough
  229. # [02:32] <anne> i agree with authoring problems but it's hard to demonstrate :(
  230. # [02:33] * Quits: Navarr (navarr@76.247.244.98) (Quit: Yeah.. I'll see ya around...)
  231. # [02:35] <anne> Hixie, do you remember where you posted?
  232. # [02:36] <Hixie> appformats i think
  233. # [02:37] <jgraham> Re: Vary, I think the reason I was not sure how well it worked in practice was http://www.mnot.net/blog/2007/06/20/proxy_caching#comment-2989
  234. # [02:37] <anne> nothing there about that, though there is the server research there
  235. # [02:43] <mjs> jgraham: I think it will prevent over-caching but might result in too little caching, which that comment seems to line up with
  236. # [02:49] <jgraham> mjs: Is the bit about getting the wrong response with varying on multiple headers not a potential problem?
  237. # [02:49] <mjs> oh
  238. # [02:49] <mjs> yes, that's a problem
  239. # [02:50] <mjs> it specifically mentions multiple Vary headers; I'm not sure if that applies also to multiple headers listed in a single Vary
  240. # [02:50] <mjs> or what implementations he has in mind for that matter
  241. # [02:54] * Quits: mjs (mjs@17.203.15.209) (Quit: mjs)
  242. # [02:56] <Hixie> vary is another feature i would drop if we were making http5
  243. # [02:59] * Quits: adele (adele@17.203.15.207) (Quit: adele)
  244. # [03:05] * Quits: tH (Rob@87.102.4.60) (Quit: ChatZilla 0.9.79-rdmsoft [XULRunner 1.8.0.9/2006120508])
  245. # [03:07] * Joins: mjs (mjs@17.203.15.209)
  246. # [03:22] * Quits: mjs (mjs@17.203.15.209) (Quit: mjs)
  247. # [03:25] * Quits: dbaron (dbaron@71.204.145.103) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  248. # [03:33] * Joins: aaronlev (chatzilla@209.6.168.245)
  249. # [04:08] * Quits: Lachy (Lachlan@84.215.54.100) (Quit: This computer has gone to sleep)
  250. # [04:08] * Joins: Lachy (Lachlan@84.215.54.100)
  251. # [04:23] * Joins: Navarr (navarr@76.247.244.98)
  252. # [04:30] * Joins: mjs (mjs@64.81.48.145)
  253. # [05:00] <Navarr> I assume this would be the place to discuss it.. the <u> tag. Its being replaced using CSS, but doesn't it have its inline properties too? For example, the title of a book would be underlined, no? Wouldn't that be better to use a tag for, instead of CSS since it could be considered semantic data?
  254. # [05:01] <Navarr> i'll cross post to the mailing-list
  255. # [05:02] <shepazu> Navarr, rather, you should somehow indicate that the title is a title (perhaps with a class or microformats tag or special attribute), and use that as a signal on how to style it.. underline doesn't have exclusive semantics with titels, it can be use for emphasis and lots of other things
  256. # [05:03] <Navarr> once i make sure i look at it some more
  257. # [05:03] <Navarr> thats true, shepazu.
  258. # [05:03] <Navarr> let me double check something.
  259. # [05:03] <shepazu> sure
  260. # [05:04] <Navarr> see, considering what you just wrote, does that not apply to the <b> tag as well?
  261. # [05:04] <shepazu> by my logic, yes
  262. # [05:05] <Navarr> heh
  263. # [05:05] <shepazu> is that not how it's presented?
  264. # [05:05] * shepazu doesn't know
  265. # [05:05] <Navarr> we're apparetly keeping <b> as per http://www.w3.org/html/wg/html5/diff/#changed-elements
  266. # [05:05] <Navarr> quoth: "The b element now represents a span of text to be stylistically offset from the normal prose without conveying any extra importance, such as key words in a document abstract, product names in a review, or other spans of text whose typical typographic presentation is emboldened."
  267. # [05:06] <shepazu> and dropping <u>?
  268. # [05:06] <Navarr> yes
  269. # [05:06] <shepazu> seems inconsistent
  270. # [05:06] <Navarr> thats what I thought
  271. # [05:06] <sbuluf> a gem of coherence
  272. # [05:06] <shepazu> sbuluf, hmmm?
  273. # [05:07] <sbuluf> ( </irony> )
  274. # [05:07] <MikeSmith> data from indexes show that <u> is not used as widely as <b> and <i>
  275. # [05:07] * shepazu wonders if sbuluf thinks shepazu is normally incoherent :)
  276. # [05:07] <Navarr> so then the standard is reflecting usage?
  277. # [05:08] <MikeSmith> yes
  278. # [05:09] <Navarr> but when considering semantics, such as these reasons, would it really be okay to just drop <u> for styling, even when it has semantic purposes, even if its not as widely used as <b> and <i>?
  279. # [05:09] <shepazu> Navarr, I suspect that <u> still has a processing model, and instructions on how to treat it, but is deprecated... is that not the case?
  280. # [05:09] <Navarr> I do believe that is the case, shepazu, however, being "deprecated" means that it shouldn't be used with newer sites, doesn't it?
  281. # [05:09] <shepazu> yeah
  282. # [05:10] <Navarr> what I don't understand is why the same isn't being done to the <b> tag (at the least)
  283. # [05:10] <Navarr> it seems (as you said) inconsistent
  284. # [05:10] <shepazu> I think we should get rid of <u>, <b>, and <i>, but keep <blink>
  285. # [05:11] <Navarr> I don't see any semantic value to <blink> :-p
  286. # [05:11] <Navarr> nor have I ever seen a web page with blinking text that didn't slightly annoy me nor strain my eyes. I don't think blinking text is too good of an idea in the first place, mind you.
  287. # [05:12] <MikeSmith> Navarr - have you read the recent "underline element" discussion threads on public-html?
  288. # [05:12] <shepazu> its semantic value can be expressed as "LOOK AT ME!!!! MOMMY, DADDY, LOOK, I MADE A WEB PAGE! LOOK!"
  289. # [05:12] <MikeSmith> http://lists.w3.org/Archives/Public/public-html/2007Dec/thread.html#msg268
  290. # [05:12] <Navarr> No, I was just about to search and see if there is one.
  291. # [05:12] <Navarr> thank you
  292. # [05:12] <MikeSmith> here too:
  293. # [05:12] <MikeSmith> http://lists.w3.org/Archives/Public/public-html/2008Jan/thread.html#msg0
  294. # [05:13] * Navarr gets to the reading.
  295. # [05:14] <MikeSmith> It's not clear how much less commonly used <u> is at this point
  296. # [05:14] <MikeSmith> see this message;
  297. # [05:14] <MikeSmith> http://lists.w3.org/Archives/Public/public-html/2007Dec/0314.html
  298. # [05:15] <Navarr> hmm.
  299. # [05:19] <MikeSmith> I personally think these current discussions about authoring-conformance requirements are totally unproductive at this point and wish the spec didn't attempt to say anything at all about authoring conformance until we have solved the real problems we need to solve
  300. # [05:20] <Navarr> true.
  301. # [05:20] <MikeSmith> whether or not <u> or <b> or <i> are considered conformant for authoring makes not one iota of difference as far as browser behavior is concerned
  302. # [05:22] <MikeSmith> browsers will continue to forever render them as they do now, regardless of what this spec or any other says about whether they're valid
  303. # [05:24] <Navarr> thats a very valid point. This conversation is best saved till closer to the publishing
  304. # [06:00] * Quits: timbl (timbl@96.237.56.114) (Quit: timbl)
  305. # [06:10] * Quits: aaronlev (chatzilla@209.6.168.245) (Ping timeout)
  306. # [07:37] <inimino> jgraham: http://www.edge.org/q2008/q08_print.html#kosko
  307. # [07:37] <inimino> (regarding median and mode)
  308. # [08:09] * Joins: myakura (myakura@122.17.57.162)
  309. # [10:05] * Quits: anne (annevk@82.156.27.18) (Ping timeout)
  310. # [10:11] * Joins: anne (annevk@82.156.27.18)
  311. # [10:43] * Joins: ROBOd (robod@89.122.216.38)
  312. # [10:44] * Quits: sbuluf (zhsteur@200.49.132.78) (Ping timeout)
  313. # [10:45] <hsivonen> anne: as far as I can tell, the XML BNF doesn't allow S before XMLDecl
  314. # [10:46] <anne> is the encoding determined based on the encoding of <?xml ?
  315. # [10:47] * anne though the actual pseudo-attribute value mattered as well
  316. # [10:49] <hsivonen> Hixie: when a program *can* intercept OPTIONS, using it would make code clearer as you don't need to avoid the normal code path in GET
  317. # [10:50] <hsivonen> Hixie: when I tried implementing the GET-based approach in Validator.nu, the spec didn't make it clear enough when I'd be better off not returning the entity body. With OPTIONS it would be simpler for server-side implementors (when OPTIONS is interceptable).
  318. # [10:52] <hsivonen> Hixie: POST invalidates the HTTP-level GET cache. regardless of GET vs. OPTIONS, there needs to be an app-level authorization cache for efficiency
  319. # [10:53] <hsivonen> why would simply unconditionally responding to OPTIONS be harder for authors than carefully iffing out the special GET and remembering to set Vary accordingly?
  320. # [10:55] <hsivonen> anne: good point about the inter-pseudo attribute S
  321. # [11:01] <mjs> hsivonen: it sounds like the problems with OPTIONS in Apache are: (a) you have to set an undocumented config option to reply to it at all and (b) you have to make sure mod_dav is not installed
  322. # [11:01] <mjs> dunno about other popular web servers
  323. # [11:01] <anne> actually, both of those concerns are no longer true
  324. # [11:02] <anne> I didn't have to do either to get it to work on DreamHost
  325. # [11:02] <anne> I did before, but apparently there was a recent update
  326. # [11:03] <hsivonen> mjs: when I tested that Validator.nu (Apache2 as of feisty, mod_jk and Jetty 6.1) was able to handle OPTIONS, I didn't need to tweak anything on the Apache side.
  327. # [11:03] <hsivonen> mjs: I just overrode doOptions in the servlet
  328. # [11:03] <mjs> then there's probably no problem with it
  329. # [11:03] <mjs> and using OPTIONS may be more clear
  330. # [11:04] <anne> the only problem is that common authors are less familiar with it
  331. # [11:04] <anne> they hardly know the difference between GET and POST
  332. # [11:05] <anne> when I started I thought the difference was that GET had the values encoded in ?... and POST did not
  333. # [11:06] <hsivonen> anne: if common authors don't understand the subleties of HTTP, I'd guess they are less likely to get the Vary stuff right
  334. # [11:07] <anne> the current design doesn't require Vary as the UA always requests a new uncached copy, but I guess if OPTIONS is less pain we should use that instead
  335. # [11:08] * anne goes to check what kind of changes have to be made
  336. # [11:12] <hsivonen> anne: if the same URI also serves cacheable GET content, Vary is necessary
  337. # [11:13] <anne> that content will be invalidated by the actual request that follows on the authorization request
  338. # [11:13] <anne> afaict
  339. # [11:13] <hsivonen> yes, the POST will invalidate cache (in compliant impls.)
  340. # [11:14] <anne> so I'm not sure what your point is
  341. # [11:14] <hsivonen> anne: if you don't have Vary: Method-Check, a proxy may satisfy the access-control request from the proxy cache
  342. # [11:14] <hsivonen> or is there something else to prevent that?
  343. # [11:21] <hsivonen> see also http://www.al3x.net/2008/01/shared-hosting-is-ghetto.html
  344. # [11:22] <hsivonen> stuff in Rails, TurboGears, Django(?) and Java needs a dedicated host or a virtual machine
  345. # [11:23] <anne> I guess it depends on what you need
  346. # [11:23] <hsivonen> Dreamhost-style Apache sharing is for PHP
  347. # [11:23] <anne> the simple stuff I run on DreamHost works good enough
  348. # [11:24] <hsivonen> the reason why Validator.nu is not at Dreamhost is that they couldn't sell me memory resident processess without having to reserve an actual box in the server colo
  349. # [11:25] <hsivonen> they don't even allow mod_jk on the shared apache and the Java back end somewhere else
  350. # [11:49] * Quits: myakura (myakura@122.17.57.162) (Ping timeout)
  351. # [11:52] <anne> they have that now i think
  352. # [11:52] <anne> not cheap though, then again, it's US dollars
  353. # [12:01] <hsivonen> anne: do you mean they now have virtual machines?
  354. # [12:04] <anne> http://dreamhostps.com/
  355. # [12:11] * Quits: Lachy (Lachlan@84.215.54.100) (Quit: This computer has gone to sleep)
  356. # [12:11] * Joins: Lachy (Lachlan@84.215.54.100)
  357. # [12:11] * Quits: Lachy (Lachlan@84.215.54.100) (Client exited)
  358. # [12:11] * Joins: Lachy (Lachlan@84.215.54.100)
  359. # [12:12] <hsivonen> anne: thanks for the pointer. Their offering (even if it weren't invite-only) is not particularly attractive compared to what I have now
  360. # [12:12] <hsivonen> (a virtual x86_64 machine with 256 MB of RAM running feisty with root access)
  361. # [12:13] <hsivonen> anne: there are only two things in favor of the dreamhost thing: weak dollar and RAM adjustability in small increments
  362. # [12:15] <hsivonen> aside: hosting Validator.nu on a 32-bit machine might be smarter than hosting it on a 64-bit machine, because RAM is where the cost is and 64-bit HotSpot needs more RAM
  363. # [12:16] * Lachy is considering moving my site to dreamhost, but not really looking forward to the effort needed to migrate my site
  364. # [12:16] <anne> what effort?
  365. # [12:17] <anne> it was quite easy for me
  366. # [12:17] <Lachy> I have to transfer all the files from my current site, databases, etc. and then make sure everything works
  367. # [12:18] <hsivonen> fwiw, I decided against moving hsivonen.iki.fi, because I have some weird Python and Jython stuff in cron. everything takes more effort than it looks on the surface
  368. # [12:18] <Lachy> I really want the extra storage space. I'm limited to 1GB on my current host
  369. # [12:19] <anne> you're using more than 1GB?
  370. # [12:19] * anne doesn't come anywhere near that
  371. # [12:21] <Lachy> no, not for my website, but I also want to use it for the IMAP mail, and I have about 1.3GB of archived mail to store
  372. # [12:23] <Lachy> plus, I'm also limited to just 30GB bandwidth per month, which I occasionally go over. I probably should just sign up
  373. # [12:25] <anne> use someone elses sign up thingie so they get money from it
  374. # [12:32] <Lachy> anne, do you mean for the email of friend who referred me field?
  375. # [12:33] <anne> yeah
  376. # [12:33] <anne> or click a link somewhere on the web
  377. # [12:34] <Lachy> I'll just put your email in, which one should I use?
  378. # [12:35] <anne> annevankesteren@gmail.com it seems
  379. # [12:35] * anne wonders if this actually works
  380. # [12:35] * anne will use the money to keep html5.org alive
  381. # [12:36] <Lachy> how much do they give you?
  382. # [12:36] <Lachy> I wonder if I should take up their free domain registration offer. I wonder what I should get?
  383. # [12:37] <anne> "10% of all payments forever"
  384. # [12:37] <Lachy> woah! I thought it would just be a 1-time payment
  385. # [12:38] <anne> i could get that too
  386. # [12:38] <anne> maybe using "dirtcheap" from Arve is better
  387. # [12:38] <anne> he claims you get a 78$ discount
  388. # [12:39] <anne> though I think they limited that
  389. # [12:44] <Lachy> I'll have to sign up later, after I get paid this month
  390. # [12:45] <Lachy> then I can pay for 10 years, get the cheapest rate and not have to worry about it
  391. # [12:46] <hsivonen> hmm. I wonder how people paying for 10 years in advance affects their support incentives
  392. # [12:47] <hsivonen> if you've already paid, they don't feel the thread of losing money if a customer leaves
  393. # [12:49] <hsivonen> s/thread/threat/
  394. # [12:49] <anne> does it make that much difference?
  395. # [12:49] <hsivonen> I don't know
  396. # [12:50] <hsivonen> they do seem a bit pyramid-schemish
  397. # [12:50] <hsivonen> and they used to have a bad BBB rating
  398. # [12:50] <anne> 45% off
  399. # [12:50] <hsivonen> but then, they've actually stayed in business for a long time
  400. # [12:52] <hsivonen> to get back on topic: I think I'm going to publish broken <style scoped> support and just document the brokenness citing spec ambiguity
  401. # [12:56] <hsivonen> do we have an open issue about iframe width/height conformance?
  402. # [12:57] * hsivonen looks
  403. # [12:58] <hsivonen> http://canvex.lazyilluminati.com/misc/cgi/issues.cgi/message/%3C961321BE-2A9B-471B-9531-1711606E9DB0%40iki.fi%3E
  404. # [12:58] <hsivonen> from me even
  405. # [13:04] <anne> seems like a simple mistake
  406. # [13:26] * Joins: Sander (svl@86.87.68.167)
  407. # [13:57] * Joins: tH_ (Rob@87.102.4.60)
  408. # [13:57] * tH_ is now known as tH
  409. # [14:16] * Quits: Sander (svl@86.87.68.167) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
  410. # [14:17] * Quits: gsnedders (gsnedders@86.137.236.187) (Quit: Partying in teh intarwebs)
  411. # [14:56] * Joins: zcorpan (zcorpan@83.227.33.203)
  412. # [15:03] <zcorpan> shepazu: fwiw, charset='' has been dropped from <script> and <link> in html5, and i've dropped it in my <?xml-stylesheet?> spec, too
  413. # [15:03] <shepazu> zcorpan, okay, thanks, good to know
  414. # [15:07] * Joins: myakura (myakura@122.17.57.162)
  415. # [15:17] * Quits: zcorpan (zcorpan@83.227.33.203) (Ping timeout)
  416. # [15:18] * Quits: jgraham (james@81.86.210.78) (Ping timeout)
  417. # [15:18] * Quits: jgraham__ (jgraham@81.86.210.78) (Ping timeout)
  418. # [15:18] * Joins: jgraham__ (jgraham@81.86.208.116)
  419. # [15:18] * Joins: jgraham (james@81.86.208.116)
  420. # [15:29] * Joins: zcorpan (zcorpan@83.227.33.203)
  421. # [15:51] <zcorpan> <oedipus> i just found out that in the google search box, a dropdown list appears when one begins to type -- same thing at ask.com -- which i discovered through sheer clumsiness (blind luck)
  422. # [15:51] <zcorpan> <oedipus> now that's a case where ARIA would help -- it would at least tell me that a dropdown was there
  423. # [15:51] <zcorpan> (from the minutes)
  424. # [15:51] <zcorpan> ...or <datalist>
  425. # [16:06] <Lachy> it always amazes me why some people always think aria is the answer to accessibility issues, instead of looking at what's already covered in HTML5
  426. # [16:10] <hsivonen> Lachy: how does Opera 9.5 fare with real AT in the datalist case vs. the ARIA case?
  427. # [16:16] * Quits: zcorpan (zcorpan@83.227.33.203) (Ping timeout)
  428. # [16:22] * Joins: gsnedders (gsnedders@86.137.236.187)
  429. # [16:28] <Lachy> hsivonen, don't know
  430. # [16:47] * Joins: zcorpan (zcorpan@83.227.33.203)
  431. # [17:00] * Joins: Sander (svl@86.87.68.167)
  432. # [17:16] * Quits: zcorpan (zcorpan@83.227.33.203) (Ping timeout)
  433. # [17:35] * Quits: myakura (myakura@122.17.57.162) (Quit: Leaving...)
  434. # [17:36] * Joins: zcorpan (zcorpan@83.227.33.203)
  435. # [17:47] * Joins: anne-mac (annevk@77.163.243.203)
  436. # [17:50] <anne-mac> oops
  437. # [17:50] <anne-mac> I e-mailed the wrong list with my OPTIONS announcement
  438. # [17:50] <anne-mac> crap
  439. # [18:16] * Quits: zcorpan (zcorpan@83.227.33.203) (Ping timeout)
  440. # [18:17] * Quits: anne-mac (annevk@77.163.243.203) (Ping timeout)
  441. # [19:25] * Quits: Shunsuke (Shunsuke@123.176.107.50) (Connection reset by peer)
  442. # [19:26] * Joins: Shunsuke (Shunsuke@123.176.107.50)
  443. # [19:29] * Joins: sbuluf (mfluhhb@200.49.132.77)
  444. # [19:39] <Philip> Hmm, two formal objections
  445. # [20:00] <anne> this one follows the rules even less it seems
  446. # [20:01] <Dashiva> It wouldn't be any fun if we got a valid FO, after all :)
  447. # [20:02] <anne> then we could at least focus on fixing something
  448. # [20:03] <Dashiva> On the upside, the number of Member respondents is growing
  449. # [20:04] <Dashiva> Looks like 9 now
  450. # [20:09] <anne> yeah
  451. # [20:10] <anne> from that list I would expect Library of Congress, Google, W3C, IBM, and AOL to reply as well, which would make 14
  452. # [20:22] * Joins: kingryan (kingryan@72.47.127.186)
  453. # [20:55] * anne e-mails html4all about the wiki spam
  454. # [20:56] * gsnedders wonders what complaints Robert Burns is referencing in his response to the survey
  455. # [20:57] <gsnedders> Only thing vaguely like it is me talking about unanimous agreement, not consensus
  456. # [20:58] * gsnedders also notes that his issue seems to be a process one and a technical one
  457. # [20:58] <gsnedders> *and not
  458. # [20:58] <anne> it's not a technical vote either
  459. # [21:01] <gsnedders> "An individual who registers a Formal Objection should cite technical arguments and propose changes that would remove the Formal Objection"
  460. # [21:02] <gsnedders> only a should, seemingly
  461. # [21:02] * gsnedders wonders how that works out under the RFC 2119 meaning
  462. # [21:02] <Philip> (Does that come from a document written in RFC 2119 language rather than in English?)
  463. # [21:02] <gsnedders> yeah
  464. # [21:03] <gsnedders> the W3C Process Document is RFC 2119'd
  465. # [21:38] <anne> what is the equivalent of the GET commandline tool that allows arbitrary HTTP methods to be used?
  466. # [21:39] <Philip> GET -m FOO
  467. # [21:40] <anne> so that actually does not work
  468. # [21:40] <anne> "GET: FOO is not an allowed method"
  469. # [21:40] <anne> which is why I asked :)
  470. # [21:41] <Philip> Oh
  471. # [21:41] <Philip> It works if FOO == OPTIONS :-)
  472. # [21:41] <anne> i know
  473. # [21:42] <Philip> You could edit GET and remove the obvious place where it dies for unallowed methods
  474. # [21:42] <anne> where is get located?
  475. # [21:42] <Philip> Run "which GET"
  476. # [21:42] <anne> cool
  477. # [21:48] <anne> reading the source code I found a better way :)
  478. # [21:48] <anne> GET -efm FOO http://annevankesteren.nl/temp/test-access-control-method.py
  479. # [21:48] <anne> and it works :)
  480. # [21:49] <Philip> Ah
  481. # [21:49] <Philip> Reading GET --help would show that way too :-)
  482. # [21:49] <anne> --help is for the weak :p
  483. # [21:49] <Philip> although I did that and read it and didn't notice that -f did exactly what you wanted
  484. # [21:50] <anne> this opens up a whole new range of debugging nonsense
  485. # [21:51] <anne> Apache handles no method at all itself but lets ' go through
  486. # [21:52] <anne> () results in weird results
  487. # [21:53] <anne> same for @
  488. # [21:53] <anne> though 1 and ! work fine
  489. # [21:57] <anne> @ is arguably a bug as it is within the token range afaict
  490. # [21:58] <anne> oops, it's a separator, my bad
  491. # [21:58] <anne> hmm, the HTTP method #
  492. # [22:01] <anne> this library simply uppercases the input method
  493. # [22:02] <anne> and people complain XMLHttpRequest is "subsetting" HTTP!
  494. # [22:02] * anne goes back to GET2
  495. # [22:06] <anne> depending on the server you either get a 501 or 400 for "get"
  496. # [22:07] <anne> it seems that Apache with PHP is fine with "get" or "gET" requests
  497. # [22:07] <anne> hmm
  498. # [22:12] * Quits: ROBOd (robod@89.122.216.38) (Quit: http://www.robodesign.ro )
  499. # [22:33] * Philip sees one more Member response
  500. # [23:03] * Quits: anne (annevk@82.156.27.18) (Ping timeout)
  501. # Session Close: Sun Jan 13 00:00:00 2008

The end :)