| 07:12 | <yanni> | Hi |
| 17:11 | <Hixie> | zcorpan: ping |
| 18:04 | <zcorpan> | Hixie: pong |
| 18:32 | <Krinkle> | The accessKeyLabel specification does not explicitly state that the node needs to be attached in the document root for the property to resolve. |
| 18:32 | <Krinkle> | It seems in Firefox it remains an empty string until attached. |
| 18:32 | <Krinkle> | http://jsfiddle.net/R3fNY/ |
| 18:32 | <Krinkle> | Does that seem sensible? I'd like to have it changed. |
| 18:32 | <Krinkle> | So that e.g. a library using this doesn't have to special-case anything that uses this to after insertion of the widget. |
| 18:32 | <Krinkle> | Wikipedia software embeds this (when available) in the title attribute like "caption [ctrl-e]" |
| 18:33 | <Krinkle> | We're hoping to phase out the ugly logic that currently infers the keyboard shortcut for accesskeys on all browsers using essentially UA sniffing. |
| 18:36 | <Krinkle> | Down stream : https://bugzilla.wikimedia.org/show_bug.cgi?id=67946 ; Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=583533 |
| 18:36 | <Krinkle> | I can file a proper bug but would be nice to know whether It'll be backed up by whatwg. |
| 18:40 | <Ms2ger> | CC me on the Mozilla bug, please. Ms2ger⊙gc |
| 18:41 | <Hixie> | Krinkle: looking... |
| 18:42 | <Hixie> | Krinkle: yeah, it does indeed appear that accesskey="" is defined to be assigned regardless of the element being in the doc |
| 18:43 | <Hixie> | Krinkle: i could go either way on this, fwiw, if the browsers disagree |
| 18:43 | <Krinkle> | Firefox is the first one to have implemented it |
| 18:43 | <Krinkle> | I've been waiting for WebKit for years |
| 18:43 | <Krinkle> | I filed a Chromium ticket today |
| 18:43 | <Krinkle> | I'm checking Aurora just in case, and will file a mozilla bug after with you two on CC? |
| 18:48 | <Krinkle> | Hixie: https://bugzilla.mozilla.org/show_bug.cgi?id=1037990 |
| 18:51 | <Hixie> | Krinkle: k |
| 18:51 | <Hixie> | Krinkle: keep me posted, especially if the browser vendors have a reason for not wanting to pre-assign the access keys before the element is in the document |
| 18:51 | <Krinkle> | Yeah |
| 18:51 | <Krinkle> | Seems to be going really slow though. |
| 18:52 | <Krinkle> | I mean, Wikipedia editors use accesskeys so much and while you tend to know them once you're used to them, I really want to get rid of this code |
| 18:52 | <Krinkle> | https://github.com/wikimedia/mediawiki-core/blob/bc725806ac301baa92b7ff61d958be577e514a0b/resources/src/jquery/jquery.accessKeyLabel.js#L27-L74 |
| 20:36 | <SimonSapin_> | When a test https://github.com/w3c/web-platform-tests does not seem to match the spec, should I file a bug on that repo or on the spec? (The bug could be in the spec as well as in the test) |
| 20:36 | <SimonSapin_> | jgraham: ^ |
| 20:42 | <caitp> | depends |
| 20:42 | <caitp> | sometimes the test is wrong, sometimes the spec isn't clear, sometimes both |
| 20:42 | <caitp> | probably quite often both |
| 20:46 | <gsnedders> | SimonSapin: I'd file a bug on the test first |
| 20:46 | <gsnedders> | and see if anyone claims the test is right :P |
| 20:48 | <SimonSapin> | There are test for IPv4 normalization (from octal or hex, with less than four pieces) but the spec does not mention that. https://github.com/w3c/web-platform-tests/issues/1104 |
| 20:48 | <SimonSapin> | … in URL parsing |
| 20:54 | <jgraham> | SimonSapin: Ask zcorpan I guess |
| 20:54 | <jgraham> | But file a bug on the test |
| 20:55 | <SimonSapin> | jgraham: that’s on https://github.com/w3c/web-platform-tests/issues/ , right? |
| 20:59 | <caitp> | from what I've seen, a lot of the tests (for older specs in particular) seem to have either been ported directly from browser tests, or have been heavily influenced by a particular browser's implementation, and don't necessarily assert anything specified anywhere normative |
| 21:00 | <caitp> | maybe "a lot" is too strong, but a few |
| 21:14 | <jgraham> | SimonSapin: Yeah |
| 21:14 | <jgraham> | caitp: Examples? |
| 21:15 | <SimonSapin> | jgraham: https://github.com/w3c/web-platform-tests/pull/771/files comes from webkit |
| 21:16 | <SimonSapin> | and tests behavior that’s not in the spec |
| 21:25 | <caitp> | jgraham, some of the xhr tests, I raised an issue about one of them which I'm not sure has been resolved yet |
| 21:26 | <caitp> | basically asserting something which isn't said anywhere in the IETF or WHATWG, far as I can tell |
| 21:26 | <caitp> | i'm sure there are other examples, but i've only spent any time poking through the XHR tests so far |
| 21:37 | <jgraham> | Well you mainly need to talk to hallvors about that |
| 21:38 | <jgraham> | But actually XHR has an unusually large number of tests that were written especially for the testsuite |
| 21:40 | <caitp> | https://github.com/w3c/web-platform-tests/issues/980 is interesting, because Chromium (along with webkit/safari and IE) will send a content-length of 0 for HEAD requests, for a reason which is explained in a comment in chrome's source, so I think Firefox is the only mainstream browser that actually passes that test |
| 21:40 | <caitp> | but none of the HTTP rfcs or anything from the XHR spec say anything about this whatsoever, I spent a good while looking =P |
| 21:41 | <caitp> | and, it's only the only such case, there are a few others I ran into a while ago |
| 21:42 | <caitp> | so from my perspective it seems like someone either copy/pasted a test from gecko, or was just looking at the gecko implementation and writing tests based on that, rather than based on the spec itself |
| 21:51 | <MikeSmith> | SimonSapin: yeah I think all those PR #771 tests came from webkit. I guess I wrongly assumed they were actually testing requirements in a spec. |
| 21:53 | <MikeSmith> | SimonSapin: Santiago Mola uses them as part of the test suite for galimatias, so I assume galimatias pass those tests. But I don't know whether that's because he implemented something according a particular spec, or whether he implemented something in order to pass those tests. |
| 22:05 | <jgraham> | caitp: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.13 seems pretty specific. I haven't checked the updates. |
| 22:06 | <caitp> | there's nothing in any of those RFCs which says anything like "a client MUST not send an entity body if the request method is HEAD or GET" |
| 22:06 | <caitp> | at best there's a "should not", or "probably not a good idea" |
| 22:06 | <gsnedders> | I thought one the httpbis things changed that? |
| 22:07 | <caitp> | but if it weren't a good idea, the big 3 browsers would probably be thoroughly broken any time anyone ever wanted to send a HEAD request |
| 22:09 | <caitp> | basically http just doesn't care if there's a payload or not |
| 22:09 | <caitp> | http doesn't care, and xhr doesn't care, so it's not clear why we're making any assertion in the first place |
| 22:10 | <jgraham> | caitp: Anyway what zcorpan says in that bug is right |
| 22:10 | <jgraham> | The goal is to get interop |
| 22:10 | <caitp> | yes, I agree with that |
| 22:11 | <caitp> | but my position is still that we should be testing compliance with the spec |
| 22:11 | <caitp> | not with a particular implementation |
| 22:11 | <jgraham> | In this case it seems like specs are half-assing things and we should just agree what the right behaviour is and get everyone to implement it |
| 22:11 | <jgraham> | caitp: We're not |
| 22:12 | <jgraham> | You are assuming some sort of malice here when there is none |
| 22:12 | <caitp> | oh no no no |
| 22:12 | <caitp> | i'm not assuming malice |
| 22:12 | <caitp> | it's not "malice", it seems like an honest mistake, like maybe it's testing something that _should_ be specified but isn't |
| 22:12 | <caitp> | but regardless, no implementation that I've seen (not tested netsurf, does netsurf even have XHR yet?) passes that test, apart from gecko |
| 22:14 | <caitp> | the comment which explains this reasoning for this behaviour in chromium is interesting, I linked to it in either the issue or PR |
| 22:14 | <caitp> | http://mxr.mozilla.org/chromium/source/src/net/http/http_network_transaction.cc#866 |
| 22:15 | <caitp> | when you word the reasoning like that, it's almost a "feature" to send the header |
| 22:15 | <jgraham> | Presto passes |
| 22:15 | <caitp> | okay, opera might still pass without opera, since it's not blink which breaks this |
| 22:15 | <caitp> | er |
| 22:15 | <caitp> | opera might still pass without presto* |
| 22:16 | <caitp> | not sure if modern opera shares more of the chromium tree or if it's just blink |
| 22:16 | <gsnedders> | it's the chromium content api |
| 22:16 | <caitp> | ah |
| 22:16 | <gsnedders> | (which was why when Blink happened there was no practical choice) |
| 22:17 | <caitp> | interesting =) |
| 22:21 | <jgraham> | Anyway, I don't think it's reasonable to assume that Blink behaviour is somehow more authorative than Gecko. The only relevant question is "what will everyone agree to implement". If you think gecko should change, file a bug. Or if you think that Blink+etc. should, file bugs there. It seems like there can't be a strong compat. argument either way, so there ought not to be too much resistance to changing. Reality might not be so straightforward. |
| 22:21 | <jgraham> | Also yell at the IETF for not specifying anything clear and unambiguous here |
| 22:21 | <caitp> | that's not it, per se, i am just not sure it's right to assert things which aren't specified anywhere |
| 22:22 | <caitp> | i agree that changing the test to assert for just a falsy content-length request header isn't right |
| 22:22 | <caitp> | hmm webkit nightly and ie11 still fail that test, so I guess it's still true |
| 22:23 | <jgraham> | I think it's better to have tests and argue about what the result should be than weaken the test just because people have failed to achieve interop |
| 22:24 | <gsnedders> | caitp: webkit doesn't have a single network layer, FWIW, depends on port |
| 22:25 | <caitp> | if one line of code was changed in a fork of chromium, "chromium would pass", too :p |
| 22:25 | <caitp> | but yeah you're right |
| 22:26 | <caitp> | primarily referring to http://nightly.webkit.org/, which is basically safari afaict |
| 22:26 | <gsnedders> | IIRC it uses the system Safari with a bit of magic |
| 22:27 | <gsnedders> | so yeah, that uses NSURL |
| 22:28 | <SimonSapin> | MikeSmith: Galimatias does have code for parsing IPv4, but seems to handle none of the funny cases I mentioned in the bug |
| 22:28 | <caitp> | anyhow, in the case of that particular issue, I'm not sure it matters a whole lot if browsers behave identically or not. like, the web doesn't care |
| 22:29 | <caitp> | so it's just a weird assertion to make |
| 22:29 | <caitp> | anyways, time to drop it and make dinner, fun chat \o |
| 22:30 | <jgraham> | Every time we decide that poor interop is OK, the web gets a little bit harder to author content for, and other platforms get a little more compelling |
| 22:31 | <jgraham> | So it's not a great position to take |
| 22:33 | <MikeSmith> | SimonSapin: ok, so yeah, would be good to hear back from smola |