Options:
- # Session Start: Sat Jan 12 00:00:00 2008
- # Session Ident: #html-wg
- # [00:02] <anne> am now
- # [00:07] <jgraham> public-tss-testsuite?
- # [00:07] <anne> ah, I found http://www.w3.org/2007/11/09-html-wg-minutes.html
- # [00:09] <jgraham> Oh I see.
- # [00:11] * Quits: timbl (timbl@96.237.56.114) (Ping timeout)
- # [00:11] * Joins: timbl (timbl@96.237.56.114)
- # [00:11] <Hixie> er
- # [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.
- # [00:11] <Hixie> jgraham: public-css-testsuite is what i meant
- # [00:12] * anne was looking for the HTML WG reference regarding MIT
- # [00:13] <jgraham> yeah, I worked it out (it was pretty obvious really)
- # [00:13] * anne doesn't think it's a great reference but can't find anything better
- # [00:13] <Lachy> I didn't even notice the typo, and what wondering why you questioned it.
- # [00:15] <Hixie> heh
- # [00:18] * Quits: aroben (aroben@71.58.127.126) (Quit: aroben)
- # [00:19] <anne> we're over fifty now
- # [00:19] <anne> (votes)
- # [00:19] <gsnedders> and members?
- # [00:19] <gsnedders> sorry anne, I'll go revise soon :P
- # [00:20] * anne is confused
- # [00:20] * Quits: jgraham (james@81.86.210.78) (Quit: This computer has gone to sleep)
- # [00:20] <gsnedders> anne: you advised me to revise for exams not work on specs
- # [00:20] * Quits: timbl (timbl@96.237.56.114) (Ping timeout)
- # [00:20] <gsnedders> and here I am not revising
- # [00:20] <anne> i see
- # [00:20] <anne> seven members
- # [00:20] <anne> well, seven orgs
- # [00:21] <gsnedders> and we need 14.
- # [00:21] <gsnedders> ow.
- # [00:21] <anne> yeah...
- # [00:21] <gsnedders> MS/Chris Wilson have removed their vote for some reason
- # [00:21] <anne> there's a reminder, lets wait another day
- # [00:22] <anne> oh, they already voted?
- # [00:22] <gsnedders> yeah, I saw one earlier.
- # [00:22] <gsnedders> No and Yes was the vote
- # [00:23] <Hixie> i didn't know you could remove your vote
- # [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:"
- # [00:23] <gsnedders> Hixie: bottom of the form.
- # [00:25] <Hixie> ah
- # [00:25] <Hixie> weird
- # [00:25] <Hixie> why would they vote then unvote
- # [00:25] <anne> "SVG <script> Should Have @charset" euh
- # [00:26] <shepazu> you disagree?
- # [00:27] <mjs> for inline scripts?
- # [00:27] <mjs> or external scripts?
- # [00:27] <anne> external i guess
- # [00:27] <shepazu> external
- # [00:27] * Hixie sighs again at the quagmire that the waf wg has ended up in
- # [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)
- # [00:28] <anne> Hixie, http://www.hollywoodstandups.com/images/quagmire.jpg ? :D
- # [00:28] <mjs> it would be actively harmful if charset interpretation of a script was based on which document embeds it
- # [00:28] * anne loves family guy
- # [00:28] * Joins: timbl (timbl@96.237.56.114)
- # [00:28] <mjs> Hixie: accept-charset getting bogged down?
- # [00:28] * Quits: Lachy (Lachlan@84.215.54.100) (Ping timeout)
- # [00:29] <Hixie> anne: more like http://someonesaygrace.blogspot.com/2007/09/quagmire.html
- # [00:29] <Hixie> mjs: access-control
- # [00:29] <mjs> er
- # [00:29] <mjs> yeah, that's what I was thinking of, I think my aphasia is getting worse
- # [00:30] <shepazu> mjs, that's a good point... how is HTML dealing with the script @charset?
- # [00:30] * anne wonders how many browsers support it
- # [00:31] <anne> if you want to solve the problem you should not solve it in SVG
- # [00:31] * shepazu suspects that mjs' argument was the reason it was left out in the first place
- # [00:31] <anne> but rather inventing some kind of @charset for JS
- # [00:32] <shepazu> anne, that doesn't make sense
- # [00:32] <mjs> text/javascript; charset=utf8
- # [00:32] <anne> shepazu, that doesn't help
- # [00:32] <mjs> I'm not sure how you would sensibly do in-content charset declaration
- # [00:33] <anne> @charset in CSS works reasonable
- # [00:33] * Joins: Lachy (Lachlan@84.215.54.100)
- # [00:33] <anne> the HTML way is pretty crappy
- # [00:34] <gsnedders> the XML way sorta works
- # [00:34] <shepazu> ah, anne, you mean an import declaration, not an attribute... ok, that makes more sense
- # [00:34] <anne> XML allows an inifite amount of whitespace
- # [00:34] <anne> infinite, even
- # [00:35] <shepazu> I thought you were saying that JS should define the attributes of the svg:script element
- # [00:35] * gsnedders thinks someone should create an infinite loop that serves an XML document with nothing but whitespace
- # [00:35] <anne> -_-
- # [00:36] <gsnedders> just to see what breaks.
- # [00:36] <gsnedders> I mean, we already have infinite HTML documents out there.
- # [00:37] <shepazu> ok, I'll comment on the mozilla bug and close my own SVG bug
- # [00:37] <shepazu> thanks, mjs
- # [00:37] <anne> your own bug has the wrong references btw
- # [00:38] <anne> 4106 is a bit too old for any SVG related work on Gecko
- # [00:38] * Joins: jgraham (james@81.86.210.78)
- # [00:39] <shepazu> ah, cp error, thanks
- # [00:42] <anne> http://it.slashdot.org/comments.pl?sid=414942&cid=22002054
- # [00:43] * Quits: adele (adele@17.203.15.207) (Quit: adele)
- # [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
- # [00:47] <jgraham> The median would be finite though
- # [00:48] <Philip> The median doesn't seem an especially useful thing to know
- # [00:49] <jgraham> In many situations it's a better measure of the underlying population average than the mean
- # [00:49] <jgraham> But I can't remember exactly what those situations are :)
- # [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
- # [00:50] <Philip> (*maximum per page)
- # [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
- # [00:51] <Philip> http://triin.net/archive/kool/webstat/figure-8.png is apparently the distribution
- # [00:53] * jgraham goes to look at the notes
- # [00:54] <anne> Hixie, now you're online, what's the use case for testing NULL in Acid3?
- # [00:55] <anne> actually, what use cases are currently prohibited by Opera not supporting NULL in the DOM
- # [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)
- # [00:56] <Hixie> anne: ?
- # [00:56] <Philip> NULL == "\0"?
- # [00:56] * Quits: smedero (smedero@192.223.6.251) (Quit: smedero)
- # [00:56] <Hixie> anne: oh you mean zero bytes? zero bytes are often used as ways to smuggle data in in security attacks
- # [00:57] <mjs> silently stripping 0 bytes is bad for security
- # [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
- # [00:57] <mjs> because it defeats attempts at content filtering
- # [00:58] <anne> we're not stripping
- # [00:58] <Hixie> they're terminating, which is even worse
- # [00:58] <mjs> terminating at 0 bytes is also bad
- # [00:59] <mjs> not sure if it is worse (depends on the specific circumstance)
- # [00:59] <Hixie> i guess
- # [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
- # [00:59] * Joins: adele (adele@17.203.15.207)
- # [01:04] <Hixie> yeah
- # [01:07] <anne> so re: access control madness, i guess i could write up a simple design decision faq
- # [01:08] <anne> do you think that would help Hixie?
- # [01:08] * anne isn't too convinced
- # [01:08] <Hixie> can't hurt i guess
- # [01:08] <anne> yeah
- # [01:08] <Hixie> the problem is that the people asking for the requirements are people who disagree with the requirements
- # [01:08] <Hixie> they just want the requirements so that they can explain that they disagree with them
- # [01:09] <anne> i know
- # [01:09] <anne> it sucks
- # [01:18] <anne> i don't really understand the "server-side model"
- # [01:18] <anne> hmm
- # [01:18] <Hixie> yeah i don't understand how the UA can't be the PEP here
- # [01:18] <Hixie> i mean the server can help, obviously
- # [01:18] <Hixie> but ultimately if the server returns data, it's the client that decides what to do with it
- # [01:19] <Hixie> and all servers today return data...
- # [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
- # [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
- # [01:27] <mjs> a pure server-side model could not be secure since today's servers don't know about it
- # [01:27] <mjs> if the client opens up cross-site access, it needs to fail on existing servers
- # [01:27] <mjs> given that, the client has to do at least part of the logic to deny access
- # [01:28] <mjs> so it may as well do as much as possible, so security policy is in one place
- # [01:28] <anne> I need some input: http://annevankesteren.nl/temp/access-control-faq
- # [01:28] <mjs> (but it would also be ok to design the protocol so the server could deny access too, for defense in depth)
- # [01:29] <anne> maybe I should mention ScriptTrapOptions
- # [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
- # [01:31] <jgraham> Fortunately I managed to avoid the part of astrophysics that requires serious statistics
- # [01:31] * Quits: Sander (svl@86.87.68.167) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
- # [01:32] <jgraham> anne: If there are technical difficulties with using OPTIONS on apache you should specify what they are
- # [01:32] * Joins: Sander (svl@86.87.68.167)
- # [01:32] * Quits: Zeros (Zeros-Elip@67.154.87.254) (Quit: Leaving)
- # [01:32] <anne> well, you never "catch" the options request with the script
- # [01:33] <jgraham> where by "technical" I mean "not related to access to the apache config"
- # [01:34] <anne> hmm, Hixie had the exact details
- # [01:34] <anne> I simply never got it to work
- # [01:34] <anne> Hixie figured out it works on some servers by using ScriptTrapOptions and not having installed some other module
- # [01:36] <anne> ah, mod_dav
- # [01:36] <jgraham> (I'm not disputing that issues exist btw; I have no idea either way)
- # [01:37] <anne> added the technical info
- # [01:37] * Philip sees e.g. http://issues.apache.org/bugzilla/show_bug.cgi?id=15242
- # [01:38] * Quits: Sander (svl@86.87.68.167) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
- # [01:43] <anne> I guess it's just mod_dav that's left then
- # [01:45] <anne> then again, what does mod_php do etc.
- # [01:47] <anne> Hixie, look what I just found: http://www.mnot.net/blog/2005/04/03/options
- # [01:47] <anne> -_-
- # [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
- # [01:50] <anne> is mod_dav enabled?
- # [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)
- # [01:54] <Philip> On a different installation of the same version of Apache, the CGI script works with and without mod_dav enabled
- # [01:55] <shepazu> mjs, maybe we could contact the Member reps directly to ask them to vote... would you like me to do that?
- # [01:55] <anne> Hixie, ^^
- # [01:57] <anne> thanks Philip
- # [01:57] <Philip> (mod_dav is sufficiently enabled that it shows me an SVN repository)
- # [01:57] <Philip> (and a Perl CGI script runs and has $ENV{REQUEST_METHOD} = 'OPTIONS')
- # [01:58] <mjs> shepazu: the W3C has voted on previous surveys
- # [01:58] <mjs> shepazu: sure, I'd appreciate you contacting member reps
- # [01:58] <shepazu> ok, I'll leave that bit up to MikeSmith
- # [01:58] <anne> what's the equivalent in Python Philip?
- # [01:59] <shepazu> ok, thanks for doing the legwork on sorting them out, and calling attention to it
- # [01:59] <Philip> OPTIONS also works the same on a simple lighttpd 1.4.18
- # [01:59] <mjs> shepazu: Mozilla has voted now btw
- # [01:59] <mjs> shepazu: yeah, I didn't want us to end up in an indeterminate state on account of quorum
- # [01:59] <Philip> anne: import os; os.environ
- # [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)
- # [02:15] <Philip> (OPTIONS also works with mod_php on the non-mod_dav Apache)
- # [02:16] <anne> you're implying it does not work on the other?
- # [02:16] * Quits: adele (adele@17.203.15.207) (Quit: adele)
- # [02:16] <Philip> I haven't got PHP installed on the other
- # [02:18] <Hixie> anne: the fact that there are so many issues with it IMHO is reason enough to stay the hell away
- # [02:18] <Hixie> frankly i don't understand why we need to use options
- # [02:18] <Hixie> i am starting to think we should drop options from http altogether
- # [02:19] <Hixie> (and move it to webdav)
- # [02:19] <Philip> Ah, now I've got PHP installed on the other, and it still works there
- # [02:20] * Joins: adele (adele@17.203.15.207)
- # [02:20] <anne> Hixie, it does work for me
- # [02:21] <anne> using like five lines of Python
- # [02:21] <Hixie> yeah i think i eventually got it to work after dreamhost upgraded me recently
- # [02:21] <Hixie> i posted about this a few weeks ago
- # [02:21] <anne> maybe I missed it
- # [02:21] <anne> pointer?
- # [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...
- # [02:22] <Hixie> i don't know off hand
- # [02:23] <anne> in PHP I used $_GET and $_POST and that was about it as far as HTTP was concerned
- # [02:23] <anne> use, rather
- # [02:23] <Philip> $_SERVER["REQUEST_METHOD"]
- # [02:23] <Hixie> what's wrong with using GET?
- # [02:23] <Hixie> that's what i don't understand
- # [02:23] <Hixie> the only arguments i've heard are theoretical and potential
- # [02:25] <anne> GET could be cached
- # [02:25] <anne> I'm not particularly convinced by the size argument
- # [02:26] <anne> Jonas also seems to favor OPTIONS
- # [02:26] <mjs> GET could be cached if marked cacheable
- # [02:26] <mjs> is there actually a rule that you can never cache OPTIONS?
- # [02:27] <mjs> and if so, is that a plus or minus?
- # [02:27] <Hixie> isn't the caching a GET a good thing?
- # [02:27] <anne> no
- # [02:27] <anne> not for the authorization request
- # [02:27] <Hixie> why not? we're explicitly caching that anyway! hwe're making up our own cache for it!
- # [02:27] <mjs> the client can mark it uncacheable if you shouldn't cache the authorization reply
- # [02:28] <mjs> er, the server I mean
- # [02:28] <anne> mjs, HTTP section 9.2 says "Responses to this method are not cacheable."
- # [02:28] <anne> Hixie, yes, but our own cache uses the referer-root as key
- # [02:28] <mjs> the reply should probably include a Vary header listing the access-control-relevant headers
- # [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
- # [02:30] <jgraham> Does Vary work in practice?
- # [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
- # [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
- # [02:30] <Hixie> anne: in that kind of case, why can't the server just set no-cache?
- # [02:30] <mjs> anne: then example.org should set either Cache-control: no-cache or Vary: Referer-root
- # [02:31] <mjs> in the reply
- # [02:31] <anne> fair enough
- # [02:32] <anne> i agree with authoring problems but it's hard to demonstrate :(
- # [02:33] * Quits: Navarr (navarr@76.247.244.98) (Quit: Yeah.. I'll see ya around...)
- # [02:35] <anne> Hixie, do you remember where you posted?
- # [02:36] <Hixie> appformats i think
- # [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
- # [02:37] <anne> nothing there about that, though there is the server research there
- # [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
- # [02:49] <jgraham> mjs: Is the bit about getting the wrong response with varying on multiple headers not a potential problem?
- # [02:49] <mjs> oh
- # [02:49] <mjs> yes, that's a problem
- # [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
- # [02:50] <mjs> or what implementations he has in mind for that matter
- # [02:54] * Quits: mjs (mjs@17.203.15.209) (Quit: mjs)
- # [02:56] <Hixie> vary is another feature i would drop if we were making http5
- # [02:59] * Quits: adele (adele@17.203.15.207) (Quit: adele)
- # [03:05] * Quits: tH (Rob@87.102.4.60) (Quit: ChatZilla 0.9.79-rdmsoft [XULRunner 1.8.0.9/2006120508])
- # [03:07] * Joins: mjs (mjs@17.203.15.209)
- # [03:22] * Quits: mjs (mjs@17.203.15.209) (Quit: mjs)
- # [03:25] * Quits: dbaron (dbaron@71.204.145.103) (Quit: 8403864 bytes have been tenured, next gc will be global.)
- # [03:33] * Joins: aaronlev (chatzilla@209.6.168.245)
- # [04:08] * Quits: Lachy (Lachlan@84.215.54.100) (Quit: This computer has gone to sleep)
- # [04:08] * Joins: Lachy (Lachlan@84.215.54.100)
- # [04:23] * Joins: Navarr (navarr@76.247.244.98)
- # [04:30] * Joins: mjs (mjs@64.81.48.145)
- # [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?
- # [05:01] <Navarr> i'll cross post to the mailing-list
- # [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
- # [05:03] <Navarr> once i make sure i look at it some more
- # [05:03] <Navarr> thats true, shepazu.
- # [05:03] <Navarr> let me double check something.
- # [05:03] <shepazu> sure
- # [05:04] <Navarr> see, considering what you just wrote, does that not apply to the <b> tag as well?
- # [05:04] <shepazu> by my logic, yes
- # [05:05] <Navarr> heh
- # [05:05] <shepazu> is that not how it's presented?
- # [05:05] * shepazu doesn't know
- # [05:05] <Navarr> we're apparetly keeping <b> as per http://www.w3.org/html/wg/html5/diff/#changed-elements
- # [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."
- # [05:06] <shepazu> and dropping <u>?
- # [05:06] <Navarr> yes
- # [05:06] <shepazu> seems inconsistent
- # [05:06] <Navarr> thats what I thought
- # [05:06] <sbuluf> a gem of coherence
- # [05:06] <shepazu> sbuluf, hmmm?
- # [05:07] <sbuluf> ( </irony> )
- # [05:07] <MikeSmith> data from indexes show that <u> is not used as widely as <b> and <i>
- # [05:07] * shepazu wonders if sbuluf thinks shepazu is normally incoherent :)
- # [05:07] <Navarr> so then the standard is reflecting usage?
- # [05:08] <MikeSmith> yes
- # [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>?
- # [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?
- # [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?
- # [05:09] <shepazu> yeah
- # [05:10] <Navarr> what I don't understand is why the same isn't being done to the <b> tag (at the least)
- # [05:10] <Navarr> it seems (as you said) inconsistent
- # [05:10] <shepazu> I think we should get rid of <u>, <b>, and <i>, but keep <blink>
- # [05:11] <Navarr> I don't see any semantic value to <blink> :-p
- # [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.
- # [05:12] <MikeSmith> Navarr - have you read the recent "underline element" discussion threads on public-html?
- # [05:12] <shepazu> its semantic value can be expressed as "LOOK AT ME!!!! MOMMY, DADDY, LOOK, I MADE A WEB PAGE! LOOK!"
- # [05:12] <MikeSmith> http://lists.w3.org/Archives/Public/public-html/2007Dec/thread.html#msg268
- # [05:12] <Navarr> No, I was just about to search and see if there is one.
- # [05:12] <Navarr> thank you
- # [05:12] <MikeSmith> here too:
- # [05:12] <MikeSmith> http://lists.w3.org/Archives/Public/public-html/2008Jan/thread.html#msg0
- # [05:13] * Navarr gets to the reading.
- # [05:14] <MikeSmith> It's not clear how much less commonly used <u> is at this point
- # [05:14] <MikeSmith> see this message;
- # [05:14] <MikeSmith> http://lists.w3.org/Archives/Public/public-html/2007Dec/0314.html
- # [05:15] <Navarr> hmm.
- # [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
- # [05:20] <Navarr> true.
- # [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
- # [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
- # [05:24] <Navarr> thats a very valid point. This conversation is best saved till closer to the publishing
- # [06:00] * Quits: timbl (timbl@96.237.56.114) (Quit: timbl)
- # [06:10] * Quits: aaronlev (chatzilla@209.6.168.245) (Ping timeout)
- # [07:37] <inimino> jgraham: http://www.edge.org/q2008/q08_print.html#kosko
- # [07:37] <inimino> (regarding median and mode)
- # [08:09] * Joins: myakura (myakura@122.17.57.162)
- # [10:05] * Quits: anne (annevk@82.156.27.18) (Ping timeout)
- # [10:11] * Joins: anne (annevk@82.156.27.18)
- # [10:43] * Joins: ROBOd (robod@89.122.216.38)
- # [10:44] * Quits: sbuluf (zhsteur@200.49.132.78) (Ping timeout)
- # [10:45] <hsivonen> anne: as far as I can tell, the XML BNF doesn't allow S before XMLDecl
- # [10:46] <anne> is the encoding determined based on the encoding of <?xml ?
- # [10:47] * anne though the actual pseudo-attribute value mattered as well
- # [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
- # [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).
- # [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
- # [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?
- # [10:55] <hsivonen> anne: good point about the inter-pseudo attribute S
- # [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
- # [11:01] <mjs> dunno about other popular web servers
- # [11:01] <anne> actually, both of those concerns are no longer true
- # [11:02] <anne> I didn't have to do either to get it to work on DreamHost
- # [11:02] <anne> I did before, but apparently there was a recent update
- # [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.
- # [11:03] <hsivonen> mjs: I just overrode doOptions in the servlet
- # [11:03] <mjs> then there's probably no problem with it
- # [11:03] <mjs> and using OPTIONS may be more clear
- # [11:04] <anne> the only problem is that common authors are less familiar with it
- # [11:04] <anne> they hardly know the difference between GET and POST
- # [11:05] <anne> when I started I thought the difference was that GET had the values encoded in ?... and POST did not
- # [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
- # [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
- # [11:08] * anne goes to check what kind of changes have to be made
- # [11:12] <hsivonen> anne: if the same URI also serves cacheable GET content, Vary is necessary
- # [11:13] <anne> that content will be invalidated by the actual request that follows on the authorization request
- # [11:13] <anne> afaict
- # [11:13] <hsivonen> yes, the POST will invalidate cache (in compliant impls.)
- # [11:14] <anne> so I'm not sure what your point is
- # [11:14] <hsivonen> anne: if you don't have Vary: Method-Check, a proxy may satisfy the access-control request from the proxy cache
- # [11:14] <hsivonen> or is there something else to prevent that?
- # [11:21] <hsivonen> see also http://www.al3x.net/2008/01/shared-hosting-is-ghetto.html
- # [11:22] <hsivonen> stuff in Rails, TurboGears, Django(?) and Java needs a dedicated host or a virtual machine
- # [11:23] <anne> I guess it depends on what you need
- # [11:23] <hsivonen> Dreamhost-style Apache sharing is for PHP
- # [11:23] <anne> the simple stuff I run on DreamHost works good enough
- # [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
- # [11:25] <hsivonen> they don't even allow mod_jk on the shared apache and the Java back end somewhere else
- # [11:49] * Quits: myakura (myakura@122.17.57.162) (Ping timeout)
- # [11:52] <anne> they have that now i think
- # [11:52] <anne> not cheap though, then again, it's US dollars
- # [12:01] <hsivonen> anne: do you mean they now have virtual machines?
- # [12:04] <anne> http://dreamhostps.com/
- # [12:11] * Quits: Lachy (Lachlan@84.215.54.100) (Quit: This computer has gone to sleep)
- # [12:11] * Joins: Lachy (Lachlan@84.215.54.100)
- # [12:11] * Quits: Lachy (Lachlan@84.215.54.100) (Client exited)
- # [12:11] * Joins: Lachy (Lachlan@84.215.54.100)
- # [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
- # [12:12] <hsivonen> (a virtual x86_64 machine with 256 MB of RAM running feisty with root access)
- # [12:13] <hsivonen> anne: there are only two things in favor of the dreamhost thing: weak dollar and RAM adjustability in small increments
- # [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
- # [12:16] * Lachy is considering moving my site to dreamhost, but not really looking forward to the effort needed to migrate my site
- # [12:16] <anne> what effort?
- # [12:17] <anne> it was quite easy for me
- # [12:17] <Lachy> I have to transfer all the files from my current site, databases, etc. and then make sure everything works
- # [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
- # [12:18] <Lachy> I really want the extra storage space. I'm limited to 1GB on my current host
- # [12:19] <anne> you're using more than 1GB?
- # [12:19] * anne doesn't come anywhere near that
- # [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
- # [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
- # [12:25] <anne> use someone elses sign up thingie so they get money from it
- # [12:32] <Lachy> anne, do you mean for the email of friend who referred me field?
- # [12:33] <anne> yeah
- # [12:33] <anne> or click a link somewhere on the web
- # [12:34] <Lachy> I'll just put your email in, which one should I use?
- # [12:35] <anne> annevankesteren@gmail.com it seems
- # [12:35] * anne wonders if this actually works
- # [12:35] * anne will use the money to keep html5.org alive
- # [12:36] <Lachy> how much do they give you?
- # [12:36] <Lachy> I wonder if I should take up their free domain registration offer. I wonder what I should get?
- # [12:37] <anne> "10% of all payments forever"
- # [12:37] <Lachy> woah! I thought it would just be a 1-time payment
- # [12:38] <anne> i could get that too
- # [12:38] <anne> maybe using "dirtcheap" from Arve is better
- # [12:38] <anne> he claims you get a 78$ discount
- # [12:39] <anne> though I think they limited that
- # [12:44] <Lachy> I'll have to sign up later, after I get paid this month
- # [12:45] <Lachy> then I can pay for 10 years, get the cheapest rate and not have to worry about it
- # [12:46] <hsivonen> hmm. I wonder how people paying for 10 years in advance affects their support incentives
- # [12:47] <hsivonen> if you've already paid, they don't feel the thread of losing money if a customer leaves
- # [12:49] <hsivonen> s/thread/threat/
- # [12:49] <anne> does it make that much difference?
- # [12:49] <hsivonen> I don't know
- # [12:50] <hsivonen> they do seem a bit pyramid-schemish
- # [12:50] <hsivonen> and they used to have a bad BBB rating
- # [12:50] <anne> 45% off
- # [12:50] <hsivonen> but then, they've actually stayed in business for a long time
- # [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
- # [12:56] <hsivonen> do we have an open issue about iframe width/height conformance?
- # [12:57] * hsivonen looks
- # [12:58] <hsivonen> http://canvex.lazyilluminati.com/misc/cgi/issues.cgi/message/%3C961321BE-2A9B-471B-9531-1711606E9DB0%40iki.fi%3E
- # [12:58] <hsivonen> from me even
- # [13:04] <anne> seems like a simple mistake
- # [13:26] * Joins: Sander (svl@86.87.68.167)
- # [13:57] * Joins: tH_ (Rob@87.102.4.60)
- # [13:57] * tH_ is now known as tH
- # [14:16] * Quits: Sander (svl@86.87.68.167) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
- # [14:17] * Quits: gsnedders (gsnedders@86.137.236.187) (Quit: Partying in teh intarwebs)
- # [14:56] * Joins: zcorpan (zcorpan@83.227.33.203)
- # [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
- # [15:03] <shepazu> zcorpan, okay, thanks, good to know
- # [15:07] * Joins: myakura (myakura@122.17.57.162)
- # [15:17] * Quits: zcorpan (zcorpan@83.227.33.203) (Ping timeout)
- # [15:18] * Quits: jgraham (james@81.86.210.78) (Ping timeout)
- # [15:18] * Quits: jgraham__ (jgraham@81.86.210.78) (Ping timeout)
- # [15:18] * Joins: jgraham__ (jgraham@81.86.208.116)
- # [15:18] * Joins: jgraham (james@81.86.208.116)
- # [15:29] * Joins: zcorpan (zcorpan@83.227.33.203)
- # [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)
- # [15:51] <zcorpan> <oedipus> now that's a case where ARIA would help -- it would at least tell me that a dropdown was there
- # [15:51] <zcorpan> (from the minutes)
- # [15:51] <zcorpan> ...or <datalist>
- # [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
- # [16:10] <hsivonen> Lachy: how does Opera 9.5 fare with real AT in the datalist case vs. the ARIA case?
- # [16:16] * Quits: zcorpan (zcorpan@83.227.33.203) (Ping timeout)
- # [16:22] * Joins: gsnedders (gsnedders@86.137.236.187)
- # [16:28] <Lachy> hsivonen, don't know
- # [16:47] * Joins: zcorpan (zcorpan@83.227.33.203)
- # [17:00] * Joins: Sander (svl@86.87.68.167)
- # [17:16] * Quits: zcorpan (zcorpan@83.227.33.203) (Ping timeout)
- # [17:35] * Quits: myakura (myakura@122.17.57.162) (Quit: Leaving...)
- # [17:36] * Joins: zcorpan (zcorpan@83.227.33.203)
- # [17:47] * Joins: anne-mac (annevk@77.163.243.203)
- # [17:50] <anne-mac> oops
- # [17:50] <anne-mac> I e-mailed the wrong list with my OPTIONS announcement
- # [17:50] <anne-mac> crap
- # [18:16] * Quits: zcorpan (zcorpan@83.227.33.203) (Ping timeout)
- # [18:17] * Quits: anne-mac (annevk@77.163.243.203) (Ping timeout)
- # [19:25] * Quits: Shunsuke (Shunsuke@123.176.107.50) (Connection reset by peer)
- # [19:26] * Joins: Shunsuke (Shunsuke@123.176.107.50)
- # [19:29] * Joins: sbuluf (mfluhhb@200.49.132.77)
- # [19:39] <Philip> Hmm, two formal objections
- # [20:00] <anne> this one follows the rules even less it seems
- # [20:01] <Dashiva> It wouldn't be any fun if we got a valid FO, after all :)
- # [20:02] <anne> then we could at least focus on fixing something
- # [20:03] <Dashiva> On the upside, the number of Member respondents is growing
- # [20:04] <Dashiva> Looks like 9 now
- # [20:09] <anne> yeah
- # [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
- # [20:22] * Joins: kingryan (kingryan@72.47.127.186)
- # [20:55] * anne e-mails html4all about the wiki spam
- # [20:56] * gsnedders wonders what complaints Robert Burns is referencing in his response to the survey
- # [20:57] <gsnedders> Only thing vaguely like it is me talking about unanimous agreement, not consensus
- # [20:58] * gsnedders also notes that his issue seems to be a process one and a technical one
- # [20:58] <gsnedders> *and not
- # [20:58] <anne> it's not a technical vote either
- # [21:01] <gsnedders> "An individual who registers a Formal Objection should cite technical arguments and propose changes that would remove the Formal Objection"
- # [21:02] <gsnedders> only a should, seemingly
- # [21:02] * gsnedders wonders how that works out under the RFC 2119 meaning
- # [21:02] <Philip> (Does that come from a document written in RFC 2119 language rather than in English?)
- # [21:02] <gsnedders> yeah
- # [21:03] <gsnedders> the W3C Process Document is RFC 2119'd
- # [21:38] <anne> what is the equivalent of the GET commandline tool that allows arbitrary HTTP methods to be used?
- # [21:39] <Philip> GET -m FOO
- # [21:40] <anne> so that actually does not work
- # [21:40] <anne> "GET: FOO is not an allowed method"
- # [21:40] <anne> which is why I asked :)
- # [21:41] <Philip> Oh
- # [21:41] <Philip> It works if FOO == OPTIONS :-)
- # [21:41] <anne> i know
- # [21:42] <Philip> You could edit GET and remove the obvious place where it dies for unallowed methods
- # [21:42] <anne> where is get located?
- # [21:42] <Philip> Run "which GET"
- # [21:42] <anne> cool
- # [21:48] <anne> reading the source code I found a better way :)
- # [21:48] <anne> GET -efm FOO http://annevankesteren.nl/temp/test-access-control-method.py
- # [21:48] <anne> and it works :)
- # [21:49] <Philip> Ah
- # [21:49] <Philip> Reading GET --help would show that way too :-)
- # [21:49] <anne> --help is for the weak :p
- # [21:49] <Philip> although I did that and read it and didn't notice that -f did exactly what you wanted
- # [21:50] <anne> this opens up a whole new range of debugging nonsense
- # [21:51] <anne> Apache handles no method at all itself but lets ' go through
- # [21:52] <anne> () results in weird results
- # [21:53] <anne> same for @
- # [21:53] <anne> though 1 and ! work fine
- # [21:57] <anne> @ is arguably a bug as it is within the token range afaict
- # [21:58] <anne> oops, it's a separator, my bad
- # [21:58] <anne> hmm, the HTTP method #
- # [22:01] <anne> this library simply uppercases the input method
- # [22:02] <anne> and people complain XMLHttpRequest is "subsetting" HTTP!
- # [22:02] * anne goes back to GET2
- # [22:06] <anne> depending on the server you either get a 501 or 400 for "get"
- # [22:07] <anne> it seems that Apache with PHP is fine with "get" or "gET" requests
- # [22:07] <anne> hmm
- # [22:12] * Quits: ROBOd (robod@89.122.216.38) (Quit: http://www.robodesign.ro )
- # [22:33] * Philip sees one more Member response
- # [23:03] * Quits: anne (annevk@82.156.27.18) (Ping timeout)
- # Session Close: Sun Jan 13 00:00:00 2008
The end :)