| 02:09 | <TabAtkins> | Hixie: You tried to send the email to anne's old address. |
| 03:11 | <Hixie> | TabAtkins: d'oh |
| 08:11 | <odinho> | MikeSmith: Yo! :D Sorry to jump on you, but it'd be ace to have everything (PHP) in http://w3c-test.org/webappsec/tests/cors/submitted/opera/staging/resources/ reviewed. |
| 08:11 | <MikeSmith> | odinho: looking now |
| 08:11 | <odinho> | I'm also going to move stuff some more later sadly. To the approved folder hopefully soon, but people in webappsec are worried about all the failures :P (but they don't know the reason) |
| 08:12 | <MikeSmith> | heh |
| 08:13 | <odinho> | MikeSmith: Preemtive thanks :D (afk 1h now) |
| 08:13 | <MikeSmith> | hai |
| 08:56 | <asmodai> | Why do so many website designers suck at making their login forms support auto-fill in? |
| 08:58 | <odinho> | ...? I haven't had that problem. Maybe the implementation of your browser isn't as magical as it could be? :P |
| 09:04 | <asmodai> | odinho: Haha, well, Chrome is generally pretty decent in that regard. :) |
| 09:05 | <asmodai> | But I do encounter quite a few sites that fail, station.sony.com is a good one |
| 09:10 | <odinho> | asmodai: Oh my... Stupid Sony-site says INCOMPATIBLE BROWSER when I go to the log in-page with Opera. |
| 09:11 | <odinho> | They definately suck. |
| 09:11 | <asmodai> | odinho: haha, see?! |
| 09:11 | <asmodai> | :D |
| 09:12 | <odinho> | asmodai: But Opera does save the password for it at least (when I got away the warning). |
| 09:12 | <jgraham> | odinho: File a bug? Well I expect there already is one, but at least check |
| 09:13 | <asmodai> | odinho: I go through planetside2.com to https://auth.station.sony.com/login?theme=ps2&locale=en_US&service=http%3A%2F%2Fwww.planetside2.com%2Fj_acegi_cas_security_check |
| 09:13 | <asmodai> | and that login section on the right hand side never saves the login info for Chrome |
| 09:13 | <asmodai> | Opera did work for that, you say? |
| 09:13 | <odinho> | Funny thing is that they have background: url(some-file.gif) transparent; on that box. And some-file is 404. ... So, result? Gray text against a gray faded background, damn hard to read. |
| 09:14 | <odinho> | asmodai: Yep, it saves it. |
| 09:14 | <odinho> | asmodai: Even from planetside. |
| 09:14 | <asmodai> | Then I wonder just wtf Chrome isn't picking up on it |
| 09:15 | <odinho> | Anywayz, I have a question MikeSmith, I can't for the life of me understand how the PHP-files behave on w3c-test.org. Is there some sort of CORS-apache config thing going on? |
| 09:15 | <odinho> | MikeSmith: curl -i -X OPTIONS -H "Origin: http://test.com"; -H "Access-Control-RequesMethod: GET" "http://w3c-test.org/webappsec/tests/cors/submitted/opera/staging/resources/preflight.php?ident=test"; |
| 09:16 | <odinho> | MikeSmith: It doesn't like getting the OPTIONS header. It just instantly replies with "Allow: OPTIONS,GET,HEAD,POST" -- which is not valid (it should be Access-Control-Allow-Methods), and not something I remember writing :-) |
| 09:17 | <MikeSmith> | no idea man |
| 09:17 | <MikeSmith> | I am PHP-averse |
| 09:18 | <odinho> | Hmm. Looks to be something apache does :-) At least it doesn't happen on Opera Apache (our test server), nor my local nginx. And I'm sure I didn't ever write that line. |
| 09:18 | <MikeSmith> | I had my fill of PHP this year when plh made me work on adding features to the CSS test-framework UI code |
| 09:18 | <odinho> | MikeSmith: Is there shell accounts I can use to muck around? |
| 09:18 | <MikeSmith> | ok if it's an Apache thing I can work on fixing it |
| 09:18 | <MikeSmith> | odinho: no there are not shell accounts |
| 09:18 | <odinho> | MikeSmith: I suspect the server setup though... But you never know with PHP. :P |
| 09:19 | <MikeSmith> | that machine is behind a W3C-internal firewall |
| 09:19 | <MikeSmith> | if it's an Apache-only problem I'm much more enthusiastic about trying to fix it |
| 09:20 | <MikeSmith> | i can check stuff on the server if you point me to what to check |
| 09:20 | <MikeSmith> | other thing is, you can write server-side code in python |
| 09:20 | <odinho> | Will have to do some research first. Looking at it now. |
| 09:20 | <odinho> | That would be nice. |
| 09:21 | <odinho> | But how? |
| 09:22 | <odinho> | MikeSmith: Ah, I'd start with grep -R "OPTIONS" /etc/apache2/ btw. Just to see if it is defining anything. |
| 09:22 | <MikeSmith> | hai |
| 09:22 | <MikeSmith> | will try that right now |
| 09:23 | <MikeSmith> | $ sudo grep -R "OPTIONS" /etc/apache2/ |
| 09:23 | <MikeSmith> | /etc/apache2/mods-available/userdir.conf: <Limit GET POST OPTIONS> |
| 09:23 | <MikeSmith> | /etc/apache2/mods-available/userdir.conf: <LimitExcept GET POST OPTIONS> |
| 09:24 | <MikeSmith> | that's all |
| 09:24 | <odinho> | Hmm. Okay. :-/ So not that then. |
| 09:27 | <odinho> | MikeSmith: Is it mod-php or fcgi or something else? |
| 09:27 | <MikeSmith> | umm |
| 09:27 | <MikeSmith> | not sure |
| 09:27 | <MikeSmith> | lemme check |
| 09:28 | <odinho> | https://issues.apache.org/bugzilla/show_bug.cgi?id=15242 << was a similar issue earlier. But that one should at least be fixed. |
| 09:28 | <odinho> | This patch will add "ScriptTrapOptions (on|off)" directive, which |
| 09:28 | <odinho> | allows user to control whether CGI script will handle OPTIONS request |
| 09:28 | <odinho> | or not. |
| 09:29 | <odinho> | Oh, that's old. They just removed the entire check, so no configuring necessary. |
| 09:29 | <MikeSmith> | I see a mods-enabled/php5_cgi.conf |
| 09:30 | <MikeSmith> | and a mods-enabled/php5filter.conf too |
| 09:30 | <odinho> | oh, filter, that sounds bad :P *googling* |
| 09:31 | <odinho> | Nah, doesnt' seem that related on first look :] |
| 09:32 | <odinho> | Might be some PHP problems anyway then. Because it doesn't reply about any allowance when I use it for other files. |
| 09:33 | <odinho> | But those files won't go through the apache php configuration machinery either, so... |
| 09:35 | <darobin> | mmmmm |
| 09:35 | <darobin> | can you turn on NPH for PHP? |
| 09:35 | <darobin> | I'm having dim memories resurfacing from the Good Old Days of CGI |
| 09:38 | <MikeSmith> | 2012-11-21 02:10:10.745:WARN::/%uff0e%uff0e/%uff0e%uff0e/%uff0e%uff0e/%uff0e%uff0e/%uff0e%uff0e/%uff0e%uff0e/%uff0e%uff0e/%uff0e%uff0e/%uff0e%uff0e/%uff0e%uff0e/%uff0e%uff0e/%uff0e%uff0e/etc/passwd: java.lang.NumberFormatException: uf |
| 09:38 | <annevk> | TabAtkins: Hixie: didn't get an email other than public stuff... |
| 09:42 | <odinho> | darobin: Never knew of this estoric NPH stuff. But seems some people last talked about it in 2004. And I think W3C would have to use a real, old CGI for PHP with Apache. And I guess noone does that (?) |
| 09:43 | <darobin> | odinho: NPH was all the rage back when it was the only way of implementing some neat tricks ;) but yeah, I can't dig up anything useful that's recent |
| 09:44 | <darobin> | modern web dev stuff should normally be able to handle anything without that |
| 09:45 | <odinho> | Yeah, -- but you see that something before my PHP script is handling this request: curl -i -X OPTIONS -H "Origin: http://test.com"; -H "Access-Control-RequesMethod: GET" "http://w3c-test.org/webappsec/tests/cors/submitted/opera/staging/resources/preflight.php?ident=test"; |
| 09:45 | <odinho> | darobin: Testing with Opera's apache and my nginx, it does the expected thing. |
| 09:46 | <darobin> | maybe this could help? http://httpd.apache.org/docs/2.2/mod/mod_actions.html#script |
| 09:46 | <odinho> | Hmm. Since it's CORS, I could just temporarily put the PHP on my own server and update the paths were it asks for stuff. To show webappsec that the tests are working. :P |
| 09:46 | <odinho> | darobin: MikeSmith grepped for OPTIONS, there was nothing suspicious. |
| 09:48 | <darobin> | odinho: indeed, your script is never even called |
| 09:49 | <annevk> | isn't that because the PHP isn't vetted yet? |
| 09:49 | <odinho> | annevk: It is, -- if it wasn't it wouldn't show up on the server at all. :-) |
| 09:50 | <annevk> | odinho: oh :/ |
| 09:51 | <darobin> | nah, the PHP replies correctly to GET, HEAD, POST |
| 09:52 | <darobin> | odinho: if you use a crappy method name like FOO do you get a 501 in your setups that work? |
| 09:52 | <darobin> | because here I get HTTP/1.1 501 Method Not Implemented |
| 09:52 | <darobin> | which may be a lead |
| 09:54 | <MikeSmith> | I have to drop off for a while |
| 09:55 | <MikeSmith> | but if you get it figured out I'll be back on later and can fix it on the server then |
| 09:58 | <odinho> | darobin: That gives me HTTP/1.1 200 OK |
| 09:58 | <odinho> | darobin: the "FOO" |
| 09:59 | <odinho> | darobin: So you're very right. We probably have some extra setup that says "send whatever through" |
| 09:59 | <darobin> | really? weirder and weirder! |
| 09:59 | <darobin> | it would be good to figure out what |
| 09:59 | <darobin> | alternatively, it might be that the W3C setup has a <Limit> directive of some sort |
| 10:01 | <odinho> | Yeah, whatever sending that 501 might very well be it. Some security/restricted setup. |
| 10:01 | <odinho> | Is there a proxy in front of the apache? The firewall tm mentioned? |
| 10:02 | <darobin> | mmmm, no, the firewall is for ssh access |
| 10:02 | <darobin> | I reckon there must be a LimitExcept in there |
| 10:02 | <darobin> | or might be |
| 10:03 | <darobin> | since that will return a 501 for disallowed methods |
| 10:03 | <odinho> | LimitExcept would've shown OPTIONS in the grep probably though. :/ |
| 10:03 | <odinho> | Can PHP have such a stop? |
| 10:04 | <odinho> | ( http://test.s0.no/w3c-tests/webappsec/tests/cors/submitted/opera/staging/preflight-cache.htm ) <- how it should work, green. :] |
| 10:05 | <odinho> | curl -i -X FOO -H "Origin: http://test.com"; -H "Access-Control-Request-Method: GET" "http://test.s0.no/w3c-tests/webappsec/tests/cors/submitted/opera/staging/resources/preflight.php?ident=test"; |
| 10:06 | <darobin> | damn, I can't seem to recall the login I'm supposed to use to access that machine :( |
| 10:06 | <darobin> | we'll have to wait for Mike to return I'm afraid |
| 10:07 | <darobin> | odinho: no, you grepped for OPTIONS. But <LimitExcept GET POST PUT> would exclude OPTIONS |
| 10:07 | <darobin> | and not match in grep |
| 10:07 | <odinho> | darobin: Ah. Yeah, that does make some sense. :-) |
| 10:08 | <odinho> | Hopefully it's that :D *waiting* |
| 10:08 | <darobin> | interesting: PUT returns 405 Method Not Allowed while FOO gives 501 Method Not Implemented |
| 10:19 | <[tm]> | I'll be back on in 15 minutes |
| 10:19 | <[tm]> | or so |
| 10:20 | <[tm]> | darobin: but we should try too get your ssh acceds to that server working also |
| 10:40 | <odinho> | annevk, abarth: Reading http://fetch.spec.whatwg.org/#resource-sharing-check -- it says Note: The above algo also functions when ascii origin == "null". That does in fact mean a browser should allow ACA-Origin: null when it sent Origin: null, right? |
| 10:40 | <abarth> | yes |
| 10:40 | <odinho> | I've been double checking it too much now, and wonder why WebKit doesn't follow that. So either test is wrong, or webkit is. |
| 10:41 | <abarth> | its entirely possible that webkit and the spec disagree |
| 10:41 | <odinho> | Okay, nice. |
| 10:41 | <odinho> | abarth: Origin spec didn't say anything specific about that, but anne's note was at least helpful (though I didn't see it at first :P) |
| 10:42 | <abarth> | its a CORS issue, not an origin issue |
| 10:42 | <odinho> | abarth: Yea, but step 3 defers the origin spec :P --> If the value of Access-Control-Allow-Origin is not a case-sensitive match for the value of the Origin header as defined by its specification, return fail and terminate this algorithm. |
| 10:43 | <abarth> | I'd have to look into the details to give you a definitive answer |
| 10:44 | <odinho> | But okay, that part of the test should be correct then. The failing vendors can (and will) probably do an extra thorough spec check, and report any test errors. |
| 10:44 | <odinho> | Because it LGTM :D |
| 10:48 | <zcorpan> | saying Access-Control-Allow-Origin: null is almost like saying Access-Control-Allow-Origin: * |
| 10:48 | <odinho> | zcorpan: It'll fail much more often ;-) |
| 10:48 | <zcorpan> | but * only works if omit credentials is set |
| 10:49 | <zcorpan> | odinho: but i think any origin can set up something that gets null as origin |
| 10:49 | <odinho> | Hmm. Doing a redirect, and getting "null" would be a possible way to walk around that credentials not allowed for *. |
| 10:50 | <zcorpan> | maybe null should be banned? |
| 10:50 | <odinho> | zcorpan: Why? |
| 10:52 | <zcorpan> | because it seems like a security hole |
| 10:52 | <odinho> | Maybe the credentials stuff. -- But how would it be a security hole if else? |
| 10:53 | <zcorpan> | the person who sets null might not realize that it gives access to anyone |
| 10:54 | <odinho> | I think noone will do that. "Only allow people who have been redirected, or people who are in a privacy sensitive area" |
| 10:54 | <zcorpan> | i don't follow |
| 10:55 | <zcorpan> | noone will use null? |
| 10:55 | <odinho> | It's nice because header("aca-origin: $_SERVER[Origin]") will actually work with redirects too then. |
| 10:56 | <odinho> | zcorpan: Noone will hardcode null. :-) |
| 10:57 | <odinho> | Either they care about who they allow (so they'll have a list), or they don't and use * or just returns whatever the client sent in Origin. |
| 10:57 | <zcorpan> | maybe |
| 10:58 | <annevk> | zcorpan: null is for credentialed search from an untrusted widget |
| 10:59 | <darobin> | [tm]: as far as I can tell it's looking like my public key is no longer on the test machine |
| 10:59 | <darobin> | at least, I can't make any other sense of the trace |
| 10:59 | <MikeSmith> | darobin: OK will check on that |
| 10:59 | <MikeSmith> | btw /etc/apache2/mods-available/userdir.conf: <LimitExcept GET POST OPTIONS> |
| 11:00 | <darobin> | MikeSmith: is that the only match for LimitExcept? |
| 11:00 | <MikeSmith> | yeah that's the only instance of "LimitExcept" in /etc/apache2/ |
| 11:00 | <darobin> | well, that's not it then |
| 11:00 | <darobin> | (unless someone had fun with a .htaccess) |
| 11:00 | <annevk> | but you want to nuke that too |
| 11:01 | <annevk> | because e.g. XHR needs far more than that |
| 11:01 | <annevk> | XHR needs wildcard basically |
| 11:01 | <darobin> | annevk: you mean the LimitExcept? it's in the userdir config, I doubt it affects anything |
| 11:01 | <annevk> | oh |
| 11:01 | <darobin> | in fact, I really hope it only affects ~user stuff — I reckon we could just disable the whole module as we're not using it |
| 11:04 | <annevk> | this is why I dislike Apache for testing (actually for my own site as well) |
| 11:04 | <annevk> | there's too much magic and taking control |
| 11:05 | <darobin> | yeah, I stopped using Apache, it's just too clunky |
| 11:06 | <darobin> | for testing stuff I really like using Node because it practically does nothing for you |
| 11:08 | <annevk> | yeah, in the end you just want raw byte access with maybe a few methods for convenience that output the boilerplate stuff (and even that you want to be able to mess around with, e.g. sending HTTP/2.0 or some such) |
| 11:31 | <jgraham> | FWIW I think we are going to need to write a server specifically for testing so that Mozilla and Google can run tests on their infrastructure |
| 11:31 | <jgraham> | I imagine this would have some way to allow tests to specify handlers that override specific bits of the test |
| 11:31 | <jgraham> | er, the response, on a per-test basis |
| 11:32 | <jgraham> | Or the handling in general |
| 11:39 | <odinho> | Yes yes yes! jgraham for president!!!111 :D |
| 11:42 | <darobin> | jgraham: yeah, that matches other mumbles I've heard |
| 12:04 | <annevk> | I thought jgraham was going to be the new King Arthur? |
| 12:05 | <annevk> | hmm... maybe that is the President |
| 12:05 | <darobin> | it's President For Life Arthur these days |
| 12:05 | darobin | sighs |
| 12:06 | <darobin> | I don't know if paving the cowpaths is the right thing to do for accessibility, but the advice for alt attributes that's in HTML5 is really not paving the cowpaths at all |
| 12:06 | <darobin> | as far as I can tell, using it that way is not even a minority practice |
| 12:07 | <annevk> | can you do time zone conversion in JavaScript easily? |
| 12:07 | <annevk> | volkmar: ^^ |
| 12:08 | <annevk> | volkmar: I think selecting in local time and having it converted to UTC is useful, but if that's trivial both server and client-side... |
| 12:08 | <darobin> | you need a library to do that |
| 12:09 | <darobin> | the core Date is TZ ignorant |
| 12:09 | <annevk> | ew |
| 12:09 | <darobin> | though IIRC TC39 has been adding stuff for that |
| 12:09 | <annevk> | sounds like datetime-utc or datetime-global is kinda useful then |
| 12:09 | <darobin> | not sure what the status of that is though |
| 12:10 | <darobin> | anything that does the right thing with TZs is probably good, people get it wrong all the fucking time |
| 12:11 | <annevk> | so earlier today I wrote an IPv6 serialization algorithm in English |
| 12:11 | <darobin> | if we're changing the datetime names we might as well look at taking the I18N folks' feedback on them as well |
| 12:11 | <annevk> | this was not exactly what I had in mind when starting to work on URLs |
| 12:12 | <darobin> | are you surprised that it's taken you to all sorts of wrong places? |
| 12:13 | <annevk> | I guess I'm most annoyed with IDNA, because it seems I can't actually solve that by myself |
| 12:15 | <annevk> | btw, is it me or is there some productivity dip again? |
| 12:15 | <annevk> | like a few times a year everything gets way quieter |
| 12:16 | <odinho> | annevk: You should make some graphs, man. |
| 12:17 | <darobin> | the most avid users of alt seem to be porn sites |
| 12:17 | <darobin> | but remarkably they use it wrong both according to HTML5 and WCAG |
| 12:17 | <zcorpan> | alt="You don't want to know" |
| 12:18 | <darobin> | in fact given the length of their alts I get the impression that porn site really would rather use longdesc |
| 12:18 | <darobin> | I guess size matters to them |
| 12:18 | <darobin> | annevk: this is Thanksgiving week... |
| 12:18 | <darobin> | no one in the US is doing fuck all |
| 12:18 | <volkmar> | annevk: you can do .toString() and .toUTCString() |
| 12:19 | <volkmar> | annevk: IOW, you can know the user's time in his/her tz and the time in UTC |
| 12:19 | <volkmar> | no real need for any conversion I would say |
| 12:20 | <annevk> | volkmar: math on strings seems annoying |
| 12:20 | <annevk> | darobin: ah yeah, I guess they're doing something over there then after all :-) |
| 12:24 | <annevk> | so if you refine by date on w3.markmail.org for the last year and half or so TabAtkins turns out to be the Big Spammer |
| 12:24 | <annevk> | since inception though it's still Hixie followed by jreschke |
| 12:25 | <volkmar> | annevk: you need to parse the string on the server anyway |
| 12:25 | <annevk> | volkmar: why would there be a server? |
| 12:25 | <annevk> | volkmar: e.g. a timezone app could be pretty much client-side |
| 12:26 | <volkmar> | annevk: if there is no server, the Date object has everything you need |
| 12:26 | <volkmar> | annevk: you can get the date in UTC |
| 12:28 | <annevk> | hmm yeah looks like darobin was wrong |
| 12:29 | <annevk> | well, maybe darobin meant conversion to some other timezone |
| 12:29 | <darobin> | annevk: ? |
| 12:29 | <volkmar> | annevk: never trust French people ;) |
| 12:29 | <annevk> | volkmar: except when they live elsewhere? |
| 12:29 | <darobin> | ah, you asked about TZ conversions — not about dumping out to UTC |
| 12:30 | <darobin> | you can always get the UTC date :) |
| 12:30 | <darobin> | except when they're also Australian! |
| 12:30 | <volkmar> | darobin: as soon as you have the UTC date, it's quite easy to do TZ conversions |
| 12:30 | <darobin> | HAHAHAHAHAHAHA |
| 12:30 | <darobin> | look ma, the funny man over there said date handling is easy! |
| 12:30 | annevk | get some popcorn |
| 12:30 | <annevk> | gets damnit |
| 12:31 | <darobin> | but it's true that if all you care about is getting a UTC datetime, then you're fine |
| 12:31 | <annevk> | volkmar: guess I'm fine with dropping -local then |
| 12:31 | <volkmar> | annevk: you mean, dropping -local and have datetime returning a Date with TZ info? |
| 12:31 | <annevk> | yeah |
| 12:31 | <volkmar> | \o/ |
| 12:32 | annevk | goes back to IPv6 serialization |
| 13:45 | <darobin> | Marcos for TAG! |
| 14:37 | <Stevef> | darobin:having look at the alt text data, is the red/italic the alt text? |
| 14:38 | <darobin> | Stevef: yes, sorry, should've spent a little more time polishing the explanation |
| 14:38 | <Stevef> | np i assumed so |
| 14:41 | <Stevef> | darobin: what is immedaitely obvious form smaller data set is that many many alts are duplicates of text that is contiguous with the <img> |
| 14:42 | <darobin> | Stevef: yes, that happens a lot |
| 14:42 | <darobin> | in fact it's probably relatively easy to autodetect |
| 14:42 | <darobin> | in all of those cases it violates both WCAG and HTML5 |
| 14:43 | <Stevef> | yes |
| 14:43 | <darobin> | I guess that there could be heuristics to usefully manipulate the accessibility tree in such cases |
| 14:44 | <Stevef> | that would be something done on the AT side I think, for example, some AT do not announce duplicate text (via user setting) |
| 14:45 | <darobin> | yup yup |
| 14:46 | <darobin> | but the part that I'm interested in here is that I could only spot very few cases that follow the HTML5 advice, whereas a bunch more do follow WCAG |
| 14:48 | <Stevef> | right |
| 14:50 | <Stevef> | well that could be due to the fact that advice on writing alt text generally and historically comes from accessibility resources and guidelines such as WCAG, so if they do do it 'right' they are going to do it 'right' as per WCAG |
| 14:51 | <darobin> | Stevef: actually I think that's more deeply ingrained than that |
| 14:51 | <darobin> | most web devs haven't read the WCAG details, they're only going on "you should provide some description in alt" |
| 14:51 | <darobin> | and the reflex there seems to be "put a description of the image" not "put something that flows with the surrounding text" |
| 14:52 | <darobin> | it certainly matches my personal experience |
| 14:53 | <Stevef> | darobin: sure, but note the WCAG advice is both "put a description of the image" or "put something that flows with the surrounding text" depending on the context |
| 14:53 | <darobin> | yes, I know, but far less so than in HTML5 |
| 14:54 | <darobin> | I get the impression people only use flowing when it's in a link |
| 14:54 | <darobin> | which seems right |
| 14:58 | <Stevef> | yeah |
| 15:25 | <Lachy> | annevk, I started migrating selectors api 2 into the DOM spec. See branch here for early draft. https://github.com/lachlanhunt/dom/tree/selectorsapi |
| 15:26 | <Lachy> | also, I did what jgraham said re the W3C fork and rebasing. I now have it working, so you shouldn't ever need to accept those changes I submitted yesterday. I just didn't know how to do that before. |
| 15:53 | <annevk> | Lachy: okay |
| 15:57 | <odinho> | darobin, d'ya know the ports the w3c-test.org is listening for HTTPS? (except :443) |
| 15:57 | <darobin> | lemme check |
| 15:58 | <odinho> | (I couldn't find any on http://www.w3.org/wiki/Testing/Requirements ) -- so maybe it doesn't exist. |
| 15:58 | <darobin> | odinho: it takes a little while for ssh to echo my chars back at me, so this could be a little slow... |
| 15:58 | <odinho> | Then I should really remove that test, not like I expect it to break :P |
| 15:58 | <odinho> | darobin: mosh, just sayin' |
| 15:59 | <darobin> | yeah, I been meaning to try that for a while |
| 15:59 | <darobin> | odinho: it looks like we only have 443 |
| 16:00 | <odinho> | I did, when in France ;-) |
| 16:00 | <odinho> | darobin: Okay. Think I'll just remove those tests then. Red isn't a nice colour in tests. |
| 16:00 | <darobin> | odinho: I can open another port |
| 16:00 | <darobin> | which would you like? |
| 16:00 | <darobin> | 442? |
| 16:00 | <darobin> | 4430? |
| 16:01 | <darobin> | odinho: ^^ |
| 16:02 | <odinho> | darobin: At Opera we've done 8443 (and 8080), so basically +8000 for anything. -- Since you have 80 81 82 83, maybe 443 444 would be the correct way? :P |
| 16:03 | <darobin> | 444 it is then |
| 16:03 | <darobin> | I hope I don't cock this up |
| 16:03 | <odinho> | ^_^ |
| 16:04 | <darobin> | I've noticed people make fun of you when you crash the server on the same day you get root access |
| 16:11 | <annevk> | aah Lachy left |
| 16:12 | <darobin> | aaaaaand crash the server I did |
| 16:12 | <darobin> | thankfully not long enough for it to matter |
| 16:15 | <darobin> | odinho: ok, I can't use 8443 because that's taken by Jetty |
| 16:15 | <darobin> | and for other ports I need to poke a hole in iptables |
| 16:16 | <darobin> | I don't want to do that without taking to Mike because I'm unsure of what the security policy is on that box |
| 16:16 | <darobin> | the server currently listens on 444 but the firewall is blocking it |
| 16:51 | <odinho> | darobin: thank you although you're gone. |
| 16:59 | <annevk> | armchairing with bz |
| 16:59 | <annevk> | good times |
| 17:08 | <annevk> | can't wait to get back to http://html5.org/temp/unicorn.svg |
| 17:10 | <miketaylr> | amazing |
| 17:13 | <annevk> | odinho: the different protocol stuff, is that http/https? |
| 17:14 | <annevk> | odinho: and which direction? from http to https or vice versa? |
| 17:16 | <marcosc> | hmmmm... so, for img@srcset, if I have '<img src="foo" srcset="bar x1">' it's not clear (to me) how to pick between them from the algorithm. |
| 17:16 | <marcosc> | argh, make that 1x |
| 17:16 | <odinho> | annevk: Different protocol what? Different protocol and different port, was some tests I removed. |
| 17:17 | <odinho> | (both at the same time) |
| 17:17 | <marcosc> | argh. that effin x1 vs x1 keeps getting me. |
| 17:17 | <annevk> | whoa |
| 17:17 | <annevk> | why do so many browsers fail Disallow origin: http://www1.test.s0.no# ? |
| 17:17 | <annevk> | odinho: oh |
| 17:18 | <odinho> | annevk: The # is probably stripped somewhere in the engines. |
| 17:18 | <annevk> | that's some weird shit |
| 17:19 | <odinho> | It's working for not-remote though. Which I thought a bit weird. |
| 17:19 | <annevk> | afaik HTTP doesn't treat # magically |
| 17:19 | <odinho> | So maybe it's postmessage that's munging it. ... Or it shouldn't do that. |
| 17:19 | <annevk> | that does not-remote mean? |
| 17:19 | <odinho> | There's two tests, origin.htm, and remote-origin.htm |
| 17:19 | <annevk> | miketaylr: my plan is to put that behind about:unicorn |
| 17:20 | <odinho> | they do the same, only remote-origin opens up an iframe on a different origin where it postMessage some stuff for that iframe to XHR. |
| 17:20 | <odinho> | I made it kinda fast, maybe I did something wacky. |
| 17:25 | <annevk> | how are you passing the origin around? |
| 17:26 | <annevk> | odinho: oh, maybe the # doesn't arrive on the server in some browsers because they strip it from the request? |
| 17:27 | <odinho> | annevk: source -> http://test.s0.no/w3c-tests/webappsec/tests/cors/submitted/opera/staging/remote-origin.htm |
| 17:28 | <odinho> | annevk: With less junk -> http://test.s0.no/w3c-tests/webappsec/tests/cors/submitted/opera/staging/anne-panne.htm |
| 17:29 | <odinho> | Hm, it is not sent with in Opera, no. That's strange because it is when I don't do the remote thingy. |
| 17:30 | <annevk> | I suspect encodeURIComponent(real_origin) |
| 17:30 | <marcosc> | Hixie (or hober), when you are around: if I have '<img src="foo" srcset="bar x1">' it's not clear (to me) how to pick between them from the algorithm (I probably missed something). Any guidance would be appreciated. |
| 17:31 | <annevk> | hmm no |
| 17:31 | <annevk> | that's not different from the original |
| 17:32 | <odinho> | decodeURIComponent(e.data.url) then? Lets see |
| 17:32 | <annevk> | yeah |
| 17:32 | <annevk> | I was just there :) |
| 17:32 | <annevk> | the iframe looks like the culprit |
| 17:33 | <annevk> | http://xhr.spec.whatwg.org/#the-open()-method requires the fragment to be dropped |
| 17:33 | <annevk> | maybe Chrome does not do that? would be a bug in Chrome |
| 17:34 | <odinho> | Wat? But ... howcome it works f ... f... Hmmmm.... AHA |
| 17:35 | <annevk> | I doubt howcome knows about this |
| 17:37 | <odinho> | ^_^ I think I can add an extra encodeURIComponent to it, and it'll work better. Or I can remove the decode on the other side. Probably best to remove the decode, it shouldn't be there as far as I can see. |
| 17:38 | <marcosc> | Hixie, hober, never mind. Found it :) |
| 17:39 | <odinho> | annevk: Like totally fixed lots of errors. No more red in Opera for remote-origin. |
| 17:40 | <annevk> | odinho: awesome |
| 17:40 | <odinho> | ( http://test.s0.no/w3c-tests/webappsec/tests/cors/submitted/opera/staging/remote-origin.htm ) |
| 19:27 | <annevk> | hmm, there's also http://wiki.whatwg.org/wiki/FormData |
| 19:27 | <annevk> | kinda sad we use append there instead of add() |
| 19:28 | <annevk> | TabAtkins_: how do you feel about calling it append() instead of add()? |
| 19:29 | <annevk> | hmm, and for URLQuery, how do you get the names? |
| 19:29 | <annevk> | (the difference between FormData and URLQuery is that FormData is like multipart/form-data and URLQuery is like application/x-www-form-urlencoded |
| 19:30 | <annevk> | ; i.e. one supports Blob and the other doesn't) |
| 20:12 | <zewt> | my favorite gmail thing: pasting a URL, editing the URL, and having it be sent with an automagically-generated link to the original link |
| 20:17 | <annevk> | arv: nice work on the exception stuff |
| 20:17 | <jwalden> | exceptionally good work, is what I think annevk meant to say :-) |
| 20:18 | <Ms2ger> | jwalden, you're the worst |
| 20:18 | <annevk> | jwalden: I am reserving that for when WebKit is DOM-compliant :) |
| 20:19 | <jwalden> | Ms2ger: only if you say I'm a brat |
| 20:19 | <arv> | annevk: thanks |
| 20:23 | <annevk> | matjas: seems your spec is up now btw on /specs/ |
| 20:26 | <annevk> | arv: I've talked to sicking btw about adding something like promises to the platform |
| 20:26 | <annevk> | arv: not sure if that's up your alley, but if you have input/suggestions that would be appreciated |
| 20:28 | <arv> | annevk: Talk to Alex Russel, he is also trying to do this |
| 20:28 | <Hixie> | where should a cue that is left-aligned, given an x-position of 50%, and a width of 100%, end up? |
| 20:29 | <arv> | annevk: I want promises but at this point there are too many cooks for me to add anything but +1 to that discussion |
| 20:29 | <Hixie> | at x=50%, widht width=50%? |
| 20:29 | <Hixie> | or at x=0%, with width=100%? |
| 20:29 | <annevk> | arv: fair enough, if people are working on this maybe I should just sit back and relax |
| 20:29 | <annevk> | (and bitch about IDNA) |
| 20:30 | <annevk> | Hixie: is this like background-position or position:absolute? |
| 20:30 | <annevk> | Hixie: or is that what you're asking? :) |
| 20:30 | <arv> | annevk: I think slightlyoff is planning to get it in through some crypto API |
| 20:31 | <annevk> | arv: wut? |
| 20:31 | <arv> | annevk: Promises |
| 20:31 | <annevk> | yeah I understand, not sure I understand the strategy |
| 20:31 | <arv> | annevk: it is a new api that is async |
| 20:31 | <annevk> | my idea was to figure out what we want from the API and then add it to every asynchronous object we have |
| 20:33 | <annevk> | xhr.promise.fail()/succeed()/then() or some such |
| 20:33 | <annevk> | new async stuff could return promise directly |
| 20:39 | <annevk> | "Tell CSS about WG consensus on case folding" |
| 20:39 | <annevk> | hmm |
| 20:40 | <annevk> | -- http://lists.w3.org/Archives/Public/www-international/2012OctDec/0076.html |
| 20:41 | <Hixie> | annevk: it's like neither, but i'm asking |
| 20:42 | <annevk> | Hixie: what do existing formats do? |
| 20:43 | <SimonSapin> | annevk: is that "tell csswg about i18n wg’s consensus"? What is the said consensus? |
| 20:43 | <annevk> | SimonSapin: it sounds like the consensus is not ASCII case-insensitive, which I think is what it should be |
| 20:44 | <Hixie> | annevk: not clear |
| 20:45 | <SimonSapin> | oh I see, "case folding" is i18n’s anwser to the question of "what kind case insensitivity" |
| 20:45 | <Hixie> | align:left position:50% width:100% => seems to me it should be treated the same as align:left position:50% width:50% |
| 20:45 | <Hixie> | but |
| 20:46 | <Hixie> | align:left position:100% width:50% => seems to me it should be treated the same as align:left position:50% width:50% also |
| 20:46 | <Hixie> | and i can't work out how to make both of those happen, so one has to lose |
| 20:46 | <Hixie> | probably the second |
| 20:46 | <Hixie> | but shrinking to width:0% doesn't make sense either... |
| 20:46 | <annevk> | Hixie: why not if pos+width > 100% ignore pos? |
| 20:47 | <zewt> | SimonSapin: case folding is how you do unicode case-insensitivity (as opposed to "convert to lowercase", which is subtly different) |
| 20:47 | <annevk> | case folding is also a way complex operation for where something simple is sufficient |
| 20:48 | <Hixie> | annevk: because default width is 100% so that would mean position doesn't work unless you change the width also, every time |
| 20:48 | <zewt> | annevk: sure, it's nonsense when you're only comparing ascii |
| 20:48 | <zewt> | heh, come to think of it I don't even know what String.toLowerCase actually does |
| 20:49 | <annevk> | Hixie: so ignore width instead then I suppose... |
| 20:49 | <zewt> | there's toLowerCase and toLocaleLowerCase, but "lowercase" basically by definition has to be based on some locale |
| 20:49 | <annevk> | Hixie: which you already concluded |
| 20:49 | <zewt> | maybe just "toLowerCase = lowercase based on en_US, toLocaleLowerCase = based on the user's locale"? dunno |
| 20:49 | <annevk> | zewt: there's a locale-independent algo I think |
| 20:49 | <zewt> | annevk: that's what case folding is |
| 20:49 | <Hixie> | annevk: yeah but then align:left position:100% never does what the author wants. maybe that's ok. |
| 20:50 | <zewt> | is there anywhere it actually matters, aside from stupid turkish dotless I? |
| 20:50 | <annevk> | Hixie: what do you want there? |
| 20:50 | <Hixie> | annevk: hell if i know |
| 20:51 | <annevk> | Hixie: but even though we don't know what X wants, it doesn't do what X wants? |
| 20:51 | <zewt> | or is that just the only one that affects the ASCII set |
| 20:51 | <annevk> | zewt: there's a lot of cases |
| 20:51 | <zewt> | that's probably what it is |
| 20:58 | <Hixie> | annevk: i can argue multiple interpretations as reasonable |
| 20:58 | <Hixie> | another case is align:middle size:25% |
| 20:59 | <Hixie> | should that be in the middle, or on the left? |
| 20:59 | <Hixie> | maybe the default position should depend on the alignment... |
| 21:01 | <Hixie> | please comment on https://www.w3.org/Bugs/Public/show_bug.cgi?id=20037 if you have opinions regarding webvtt positioning |
| 21:01 | <Hixie> | lunch, bbl |
| 21:34 | <annevk> | TabAtkins_: why is it Map.size rather than Map.length? |
| 21:39 | <jwalden> | maps aren't vectors; they don't have a length |
| 21:40 | <jwalden> | does HashMap.length make any sense? |
| 21:40 | <zewt> | "length" in apis usually means "the number of things in the container", it's not restricted to linear things like strings and arrays |
| 21:41 | <jwalden> | I don't think that's universally true, and to the extent it's true in those cases, it's a bad name |
| 21:41 | <zewt> | eg. python uses len() for all kinds of containers, it doesn't make you remember different names (which also makes duck typing work much better) |
| 21:42 | <zewt> | everyone understands it, so i think the name is fine |
| 21:42 | <zewt> | it could be "elephants" as long as it was understood :) |
| 21:42 | <annevk> | yeah, that's certainly how I've come to view length, thus far I haven't seen a different name for it |
| 21:42 | <zewt> | size would be fine too but we've already got "length" |
| 21:43 | <SimonSapin> | btw, what is .length for a sparse JS array? The number of defined items or the greatest index + 1? |
| 21:44 | <heycam> | the latter |
| 21:45 | <zewt> | does javascript even have actual sparse arrays, other than setting up an object-with-array-semantics by hand? |
| 21:45 | <SimonSapin> | zewt: isn’t that an implementation detail? |
| 21:47 | <zewt> | i'm not talking about implementation, i'm asking if there are any interfaces or APIs or syntaxes that actually let you create a sparse array, other than assigning to an object directly |
| 21:47 | <jwalden> | arrays *are* objects |
| 21:47 | <heycam> | you can do [10,20,,,,,,40] |
| 21:47 | <zewt> | yes, we're not JS 101 here :) |
| 21:47 | <jwalden> | there's no such thing as a sparse array at all |
| 21:47 | <jwalden> | just arrays |
| 21:47 | <jwalden> | sometimes which might be missing properties below their length |
| 21:47 | <SimonSapin> | that’s what I meant by sparse |
| 21:48 | <jwalden> | also people don't use "sparse" in the same sense in all cases |
| 21:48 | <jwalden> | it's just not a very precise term |
| 21:48 | <zewt> | jwalden: heycam's syntax definitely gives a sparse array |
| 21:48 | <zewt> | not a terribly useful one (if you want a sparse array, usually you want millions of missing items, not a few), but just the same |
| 21:49 | <jwalden> | zewt: in the engines I'm aware of, I believe that gets optimized to use vector-like storage, which engine implementers don't consider to be a sparse case |
| 21:49 | <heycam> | zewt, you can also start off with [] and then just assign to the index properties you want |
| 21:49 | <jwalden> | zewt: which illustrates the problems of using the term "sparse" |
| 21:49 | <zewt> | jwalden: that much *is* an implementation detail |
| 21:50 | <jwalden> | zewt: there is no definition for the term "sparse", so it's meaningless to ask whether JS exposes them |
| 21:50 | <heycam> | jwalden, do you know if you do `var a = []; a[2**30] = 1` will it not allocate a chunk of memory? |
| 21:50 | <annevk> | and wherein heycam returns and I ask him to add https://www.w3.org/Bugs/Public/show_bug.cgi?id=18547 to his list (unless Ms2ger gets to it first) |
| 21:50 | <zewt> | in JS terms, i'd consider a sparse array to simply be one with array semantics, but where one of the indexes below .length doesn't exist in the object |
| 21:50 | <heycam> | annevk, so added. |
| 21:50 | <jwalden> | well, if that's your definition, new Array(17) |
| 21:51 | <zewt> | whether or how it's actually optimized based on that being the implementation detail part, of course |
| 21:51 | <Ms2ger> | heycam gets to do that :) |
| 21:52 | <jwalden> | heycam: it depends on the engine; most will probably use something similar to non-array, non-typedarray property storage for it, which allocates memory sometimes (but not necessarily always) |
| 21:52 | <zewt> | i guess the other way to view sparse arrays is as the actual physical in-memory data structure (but that isn't very interesting at a level like JS) |
| 21:52 | <jwalden> | questions about what memory gets allocated are inherently un-answerable without qualifying to a specific engine, mostly |
| 21:52 | <zewt> | well, not that exactly (it doesn't define something specific like a binary tree) |
| 23:49 | <Hixie> | so... cross-origin seamless |
| 23:49 | <Hixie> | do we always want the following on any seamless case?: |
| 23:50 | <Hixie> | - links opening in the parent browsing context, not the nested one |
| 23:50 | <Hixie> | - shrink wrapping |
| 23:50 | <Hixie> | - media queries acting as if the bc was the parent, not the iframe |
| 23:51 | <Hixie> | - borders disable by default |
| 23:51 | <Hixie> | - speech media should not announce the iframe as separate |
| 23:52 | <Hixie> | if so, are the only things we _don't_ want to propagate the styles, and the events (not yet specced anyway)? |
