| 00:17 | <Hixie_> | gavinc: HTML fragments aren't really something that HTML supports currently |
| 00:17 | <Hixie_> | gavinc: not in a useful fashion, anyway |
| 00:17 | <Hixie_> | gavinc: the best we have is what innerHTML uses, which is a disaster |
| 00:20 | <gavinc> | okay, so... keep doing what we're doing and hope someone comes up with a solution soon? |
| 00:21 | <gavinc> | no implementation experience yet on our end that I know of |
| 01:52 | <zewt> | heh http://www.jwz.org/blog/2012/10/marketing-fuels-the-world-it-is-as-american-as-apple-pie/ |
| 02:34 | <Hixie_> | gavinc: my recommendation would be to not use string fragments at all |
| 02:35 | <Hixie_> | gavinc: i don't really understand why you need to |
| 02:35 | <Hixie_> | gavinc: so it's hard for me to give good advice |
| 02:51 | <karlcow> | http://blog.lumino.so/2012/08/20/fix-unicode-mistakes-with-python/ |
| 03:43 | <annevk> | gavinc: hey hey, did I really say to refer to TR/dom/? I kinda doubt that |
| 03:44 | <annevk> | gavinc: I might have suggested http://domparsing.spec.whatwg.org/ or whatwg.org/html I suppose, but this stuff is still being discussed and not defined |
| 03:53 | <Hixie_> | domparsing.spec.whatwg.org didn't exist back in may, iirc |
| 03:54 | <annevk> | yeah, but http://html5.org/specs/dom-parsing.html redirects to that |
| 04:19 | <zcorpan> | annevk: i'm not sure we should introduce new Document before Document has been implemented properly |
| 04:29 | <annevk> | what order things is implemented is not really up to me |
| 04:31 | <annevk> | data:image/svg+xml,<script xmlns="http://www.w3.org/1999/xhtml">alert(document.rootElement)</script>; |
| 04:32 | <annevk> | throws in Gecko, returns undefined in Opera, null in Chrome |
| 04:32 | <annevk> | doesn't seem like .rootElement has much interop to begin with |
| 04:32 | <annevk> | context is https://bugzilla.mozilla.org/show_bug.cgi?id=799937#c11 |
| 04:52 | <zcorpan> | hmm, https://developer.mozilla.org/en-US/docs/HTML/Element/video#Browser_compatibility has outdated browser compat information for all browsers except firefox, i think |
| 04:55 | <Hixie_> | what is document.rootElement?? |
| 04:55 | <Hixie_> | surely it's document.document.Element |
| 04:55 | <Hixie_> | er |
| 04:55 | <Hixie_> | document.documentElement |
| 05:04 | <othermaciej> | document.rootElement? what? |
| 05:07 | <othermaciej> | omg, SVG actually defined a weird SVG-specific synonym for documentElement |
| 05:07 | othermaciej | reminds himself of the topic motto |
| 05:14 | <zcorpan> | Hixie_: if your plan with "all documents are Document" succeeds, document.rootElement will be available in html docs, too :-P |
| 05:16 | <Hixie_> | zcorpan: sounds like a win over what we have now, but seems like the even better win would be to just drop it... |
| 05:19 | <zcorpan> | http://code.google.com/codesearch#search/&q=document%5C.rootElement%20lang:svg&type=cs http://code.google.com/codesearch#search/&q=document%5C.rootElement%20lang:js&type=cs |
| 05:25 | <zcorpan> | annevk: data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg"><script>alert(document.rootElement)</script></svg>; alerts [object SVGSVGElement] in opera |
| 05:25 | <zcorpan> | annevk: turns out rootElement isn't actually "root element" but "root element but only if it's <svg>" |
| 05:26 | <annevk> | zcorpan: and otherwise it's undefined? that's crazy |
| 05:26 | <zcorpan> | no, otherwise it's null |
| 05:26 | <zcorpan> | it was undefined in opera because the root element's namespace was HTML |
| 05:26 | <annevk> | o_O |
| 05:27 | <zcorpan> | recall this Document issue? |
| 05:27 | <annevk> | I did not know Opera determines the type of Document based on the root element... |
| 06:36 | <AryehGregor> | Hixie_, here now. I'm UTC+0200, generally not around at 1:40 AM. :) |
| 06:37 | <SamB_MacG5> | AryehGregor: but this is 2:40 AM! |
| 06:37 | <AryehGregor> | It's 8:40 AM for me. :) |
| 06:40 | <annevk> | whoa that's the same time zone as Paris |
| 06:41 | <annevk> | time zones around there seem weird anyway, Greece is like Finland, Romania like France |
| 06:46 | <zcorpan> | Hixie_: what's the problem with depending on 'word-wrap'? we reference lots of specs that are "unstable" |
| 06:56 | <AryehGregor> | Aren't all interesting specs unstable? |
| 07:02 | <annevk> | I guess the API decode stuff needs special casing anyway for the way the API deals with streaming |
| 07:16 | <annevk> | I'm removing AnonXMLHttpRequest from XMLHttpRequest fwiw |
| 07:26 | <hsivonen> | is everything in MIME types ASCII case-insensitive? Including stuff in quotes in the codecs parameter? |
| 07:26 | <annevk> | I suspect: "it depends" |
| 07:27 | <hsivonen> | aargh. the RFC says sensitive |
| 07:27 | <hsivonen> | FAIL |
| 07:28 | <Ms2ger> | You had me at "the RFC ... FAIL" |
| 08:07 | <annevk> | https://twitter.com/mathias/status/256296595866406912 welcome to 2010 (or so) matjas :p |
| 08:07 | <annevk> | hsivonen: does it actually matter anywhere in practice? |
| 08:07 | <annevk> | hsivonen: oh codecs |
| 08:08 | <hsivonen> | http://lists.w3.org/Archives/Public/www-forms/2012Oct/0000.html |
| 08:08 | <hsivonen> | annevk: the part after “avc1.” is case-sensitive per spec |
| 08:09 | <hsivonen> | annevk: but WebKit doesn’t care, because it wildcards the part after “avc1.” |
| 08:09 | <hsivonen> | annevk: moreover, Apple publishes documentation with wrong-case examples |
| 08:10 | <hsivonen> | codec levels and profiles are so full of fail in an of themselves |
| 08:10 | <annevk> | can't actually blame them; HTTP and MIME are some of the worst specs to read through and HTTP is getting worse |
| 08:10 | <hsivonen> | and then this syntax |
| 08:11 | <matjas> | annevk: non-native RTing in 2010 I’d understand… but you’d think people would’ve figured it out by now |
| 08:12 | <annevk> | hsivonen: so many layers of shit, can't asshole or angel against that |
| 08:12 | <hsivonen> | people have also missed the memo on Twitter now autoshortening URLs (or they want their own “social analytics”) |
| 08:14 | <annevk> | would be nice if twitter's short URLs normalized to the final URL |
| 08:32 | <annevk> | MikeSmith: maybe we should have components in WHATWG for XHR and such too so when I close a bug it can stay closed... |
| 08:32 | <annevk> | MikeSmith: and since there's now three people "editing" it on the W3C side... |
| 08:32 | <MikeSmith> | yeah |
| 08:32 | <MikeSmith> | I can add those |
| 08:33 | <annevk> | MikeSmith: dunno though, maybe wait until after TPAC |
| 08:33 | <MikeSmith> | oh? |
| 08:33 | <MikeSmith> | either way works for me |
| 08:33 | <MikeSmith> | I guess there's no rush |
| 08:33 | <annevk> | MikeSmith: I rather not have the split, and since Jeff asked to meet maybe we can work something out |
| 08:34 | <MikeSmith> | ah yeah |
| 08:34 | <MikeSmith> | yeah would be great if that happened |
| 08:35 | <smaug____> | so foo.outerHTML = ""; just removes foo from the parent ? |
| 08:35 | smaug____ | can't recall whether outerHTML works similarly to innerHTML |
| 08:36 | <annevk> | smaug____: http://domparsing.spec.whatwg.org/ |
| 08:38 | <annevk> | smaug____: mostly yes btw |
| 08:43 | <jgraham> | AryehGregor: So, I was thinking. Do you think it would sway the testharness.js doubters if we added a second way of writing async tests; instead of being forced to write t.step(function(){/*stuff*/}) you would be able to write t.assert_whatever(). In order to assure a consistent number of tests we would impose the further restriction that trying to add a test after asserting something on a previous test would fail, so defining your tests upfront wou |
| 08:43 | <jgraham> | I am kind of loathe to add more API surface |
| 08:43 | <AryehGregor> | jgraham, you got cut off at "upfront wou". |
| 08:44 | <jgraham> | AryehGregor: Oh, lame. That's what's splitlong is supposed to solve. "would be enforced" |
| 08:44 | <AryehGregor> | I haven't seen any complaints about testharness.js from people who've actually used it nontrivially, so I'm unsure whether any substantive change would be sufficient to sway the doubters. |
| 08:45 | <AryehGregor> | hsivonen, tell me what problems you have with testharness.js again relative to mochitest? I've found nothing wrong with it in practice. It's slightly more verbose, but it's not a noticeable issue when I actually use it. |
| 08:45 | <AryehGregor> | (except for lack of features, and the fact that Mozilla people aren't familiar with it, since both of those would apply to essentially anything other than mochitest) |
| 08:48 | <jgraham> | I have some difficulty telling whether the fundamental problem is that saying "I spent time releasing tests" will be frowned on in your quaterly review. If it's that calss of problme, I'm not sure how much I can do to solve it. |
| 08:49 | <AryehGregor> | I can certainly attest that that's not true for Mozilla in general. I don't know if it's true for certain specific teams. |
| 08:50 | <AryehGregor> | My manager is obviously happy to have me spend time on releasing tests, but I'm not responsible for any features. Maybe some teams/managers/projects are more focused on shipping specific features and want them shipped on a schedule that's competitive with other browsers. |
| 08:50 | <AryehGregor> | I dunno, though. |
| 08:51 | <AryehGregor> | I don't think that testharness.js has to take any more time to write than mochitest, if we have the right infrastructure and it's being used wisely. |
| 09:05 | <Ms2ger> | AryehGregor, well, except for the point that th.js does have longer names for its methods |
| 09:06 | <AryehGregor> | Ms2ger, yes, but that doesn't substantially affect readability or writability once you get used to it. |
| 09:06 | <annevk> | I'm going to remove all throwing for user/password in XMLHttpRequest; if you think that's a bad idea, let me know |
| 09:07 | <annevk> | also, if you pass user/password that's going to count as appending an Authorization header to the "author request headers" thingie |
| 09:09 | <jgraham> | Ms2ger: I feel quite strongly opposed to the simple "ok" design at least |
| 09:09 | <jgraham> | "is this a thing that can be cast to boolean true", or whatever the method does, doesn't seem like it makes for the soundest tests |
| 09:29 | <foolip> | Hixie_, I've already implemented what https://www.w3.org/Bugs/Public/show_bug.cgi?id=17483#c3 so if that matches what you've spec'ed it should be fine. I haven't reviewed the spec change yet though. |
| 09:32 | <foolip> | Trying to minimize overlap with other cues would also be a worthy goal, but perhaps slightly more complicated, for doubtful gain |
| 09:33 | <annevk> | odinho: you still have your server setup test thingie? I'm wondering how http://user:pass@test/ and open(..., ..., ..., user, pass) interact |
| 09:33 | <annevk> | odinho: in particular if you set the latter to null or undefined or some such |
| 09:34 | <annevk> | odinho: if that overrides the former |
| 09:34 | <odinho> | annevk: Okay, -- have a test or want me to write one? :P |
| 09:34 | <annevk> | odinho: I wanted you to write one :-) I hate HTTP auth |
| 09:35 | <odinho> | annevk: Don't we all, don't we all ... :-) |
| 09:37 | <annevk> | the main problem is that credentials are cached |
| 09:37 | <annevk> | so you need some kind of elaborate scheme around that, which I wrote at some point but that didn't work either |
| 09:38 | <annevk> | I then gave up |
| 09:39 | <odinho> | Yeah. Hm. You have a test in send-authentication.htm -- it hardcodes a few paths which it shouldn't. And uses Math.random for users. |
| 09:41 | <annevk> | what I want to define in particular is how userinfo and user/password arguments interact |
| 09:42 | <annevk> | e.g. open(,,, null, null) reset them |
| 09:42 | <annevk> | what does "", "" mean |
| 09:43 | <odinho> | annevk: In the test you at least you wanted the open to win all the time. |
| 09:43 | <annevk> | even for null? |
| 09:44 | <annevk> | because the spec says null loses |
| 09:44 | <odinho> | annevk: Hmm. Not for null, no, because userwin = null || "user1" would become user1 |
| 09:46 | <annevk> | okay for now I'll clean up the spec |
| 09:46 | <annevk> | then later someone can tell me it's wrong :-) |
| 09:46 | <odinho> | So. I managed to make your former test work. :P |
| 09:47 | <annevk> | neato |
| 09:47 | <odinho> | Hmm. A little bit at least. |
| 09:47 | <annevk> | what's wrong with the path hardcoding btw? |
| 09:47 | <annevk> | and why does WebIDL require "optional" if you give the argument a default value? |
| 09:47 | <odinho> | hardcodes localhost, that's not where people normally have the resources. And also hardcoding /xhr/ as the url :-) |
| 09:55 | <odinho> | Hmmmmm... There something strange happening with the URL-based logins, -- it seems like the requests never go down to the PHP script. Like if nginx and apache eats them and just does everything on its own. Also, dragonfly doesn't say anything. I'll check with wireshark and other browsers. |
| 09:56 | <annevk> | these servers and taking away full control over what is happening are annoying |
| 09:59 | <annevk> | man that Ms2ger is studying or what, never online |
| 10:00 | <odinho> | Hmm. So, chromium actualyl does some interesting stuff, only one of the tests is a "testing error". So its behaviour doesn't trigger any vodoo as much as the others. |
| 10:08 | <annevk> | nice, bz wanted this fixed in the same way |
| 10:08 | <annevk> | on a roll today |
| 10:28 | <smaug____> | annevk: "If authentication fails, XMLHttpRequest origin and the request URL are same origin, Authorization is not in the list of author request headers, request username is null, and request password is null, user agents should prompt the end user for their username and password." |
| 10:29 | <smaug____> | what is the reason for same origin there |
| 10:30 | <smaug____> | baku: I just asked annevk about the issue |
| 10:30 | <baku> | smaug____, tnx |
| 10:30 | <smaug____> | baku: http://logbot.glob.com.au/?c=freenode%23whatwg&s=11%20Oct%202012&e=11%20Oct%202012#c729093 |
| 10:31 | <annevk> | no twitter accounts for now; https://github.com/github/github-services/issues/418 |
| 10:32 | <annevk> | smaug____: to restrict bad UI from propagating further |
| 10:32 | <annevk> | smaug____: I'd rather not prompt the user ever if we can make that work |
| 10:32 | <smaug____> | ah, right |
| 10:34 | <annevk> | smaug____: will fix the NodeList thing |
| 10:34 | <annevk> | smaug____: also for MutationObserverInit, should we give the members default values? |
| 10:34 | <annevk> | smaug____: seems more sensible |
| 10:35 | <smaug____> | IIRC there are limitations for the init members |
| 10:35 | <smaug____> | I mean, you just have to have certain properties |
| 10:35 | <annevk> | sure |
| 10:38 | <annevk> | baku: smaug____: I'll add a note about the reasoning to the spec |
| 10:38 | <annevk> | baku: smaug____: I hope you guys are reading xhr.spec.whatwg.org |
| 10:38 | <smaug____> | uh, actually no |
| 10:39 | <smaug____> | I haven't removed W3C XHR from browser's history |
| 10:39 | <smaug____> | did that to DOM |
| 10:39 | <baku> | annevk, ok thanks. if you add that note is great. |
| 10:43 | <annevk> | baku: how would you like to appear in the acknowledgments? |
| 10:43 | <annevk> | (you can appear as "baku" if you want, full name or something else is also fine) |
| 10:43 | <baku> | I am Andrea Marchesini |
| 10:43 | <baku> | thank you |
| 10:43 | <annevk> | thank you really :-) |
| 10:45 | <baku> | it seems that chrome and FF do not check the same-origin |
| 10:45 | <smaug____> | baku: except Nightly does have the same-origin check |
| 10:45 | <baku> | the prompt is shown if the authentication is needed |
| 10:46 | <baku> | right. and this is the reason why I'm here :) |
| 10:46 | <smaug____> | yup, but annevk might not know that :) |
| 10:46 | <baku> | good point. |
| 10:46 | <jgraham> | metadata :( |
| 10:46 | <annevk> | didn't know, happy you guys aligned |
| 10:47 | <jgraham> | (that was not apropos what everyone else is talking about) |
| 10:47 | <Stevef__> | annevk: i use http://twitterfeed.com/ for https://twitter.com/HTML_Commits |
| 10:48 | <smaug____> | baku: should find someone with IE9 or 10 |
| 10:48 | <Stevef__> | seems to work |
| 10:48 | <annevk> | Stevef__: I'd rather not have a level of indirection |
| 10:48 | <baku> | smaug____, yep |
| 10:48 | <annevk> | Stevef__: so that if I commit something I can retweet as appropriate if I want to directly, instead of later when the feed is read again and then tweeted from |
| 10:50 | <Stevef__> | annevk: ok |
| 10:50 | <smaug____> | baku: since if IE and FF and Chrome all have the prompt, it is probably not possible to change the behavior |
| 10:50 | <annevk> | smaug____: sorry yeah, I meant the CORS handling |
| 10:51 | <annevk> | smaug____: "sync CORS" so to say |
| 10:52 | <smaug____> | annevk: I think we didn't change that behavior... let me check |
| 10:54 | <smaug____> | annevk: oh, setting withCredentials does check asyncness |
| 10:55 | <smaug____> | (I apparently reviewed that patch. I can't remember everything :) ) |
| 10:56 | <annevk> | yeah, withCredentials does, but without withCredentials? |
| 10:56 | <annevk> | we could also still make the anonymous flag throw for sync usage btw |
| 10:56 | <annevk> | as that's just landed |
| 10:57 | <annevk> | and only in Gecko thus far |
| 10:57 | <smaug____> | yup |
| 11:01 | <annevk> | okay, so I'll add the anonymous flag to the list of things that should not work sync |
| 11:02 | <annevk> | but straight "sync CORS" will work |
| 11:02 | <annevk> | because of compat concerns |
| 11:08 | <annevk> | smaug____: okay I'll make open() throw if the anonymous flag is set |
| 11:12 | <smaug____> | one day we'll notice that we can kill sync XHR. |
| 11:13 | <annevk> | not for workers :-) |
| 11:14 | <jgraham> | Or for introducing sync pauses into testsuites :p |
| 11:16 | <odinho> | Should really be a standardized way to log out of http auth. |
| 11:21 | <smaug____> | hmm, so now I get W3C bugmail twice |
| 11:21 | <smaug____> | once in text form, once in html |
| 11:22 | <smaug____> | I don't understand the latter one |
| 11:22 | <smaug____> | since my w3 bugzilla account has the text-email pref on |
| 11:25 | <annevk> | smaug____: the other is from the mailing list |
| 11:25 | <annevk> | smaug____: maybe mike should configure the mailing list to prefer text-email too |
| 11:25 | <annevk> | I think that's what actually changed |
| 11:25 | <annevk> | with the update |
| 12:23 | <darobin> | smaug____: don't hesitate to file a bug report on bugzilla issues |
| 12:23 | <darobin> | you can ping sysreq@ |
| 12:23 | <smaug____> | I don't know where to file w3c bugzilla bugs |
| 12:23 | <darobin> | write to sysreq |
| 12:23 | <darobin> | they handle that |
| 12:26 | <smaug____> | what sis sysreq? |
| 12:26 | <smaug____> | s/sis/is/ |
| 12:26 | <smaug____> | sysreq⊙wo ? |
| 12:30 | <darobin> | sorry — yes |
| 12:36 | <jgraham> | They should use bugzilla, really ;) |
| 13:12 | AryehGregor | gives Gecko a 100% pass rate on his newly-written Node-properties.html, once his patches land |
| 13:12 | <AryehGregor> | It's not that I'm writing the test so Gecko has an advantage, but I may as well fix any bugs I find too, so . . . |
| 13:13 | <jgraham> | AryehGregor: Dude, that's the *point* of writing tests |
| 13:13 | <AryehGregor> | :) |
| 13:13 | <jgraham> | No need to apologise |
| 13:14 | <AryehGregor> | No, but it does look slightly fishy when a browser vendor sponsors tests that it scores 100% on, right? A la Microsoft. |
| 13:16 | <jgraham> | Looks fishy if you only ever release tests that you pass 100% of, and the tests have obvious gaps |
| 13:22 | <darobin> | nah I think this looks fishy, I don't trust that AryehGregor guy |
| 13:22 | <darobin> | and Gecko, you know, it just spells evil |
| 13:24 | <odinho> | If you take the second letter of Gecko, and append "vil", what do you get? ... Something to think about. Just sayin'. |
| 13:24 | <darobin> | damn right |
| 13:26 | <zcorpan> | let's do the same with "Opera". "pvil"? seems we're good. |
| 13:26 | <odinho> | zcorpan: undoubtedly |
| 13:26 | <annevk> | flawless logic |
| 13:27 | <odinho> | WebKit --> you know what |
| 13:27 | <zcorpan> | "IE" --> same |
| 13:27 | <odinho> | And IE. Just continuing sayin'. |
| 13:27 | <jgraham> | So, IE is evil, but Internet Explorer merely nvil? |
| 13:27 | <odinho> | ^_^ It all fits |
| 13:29 | <annevk> | the new XHR editors don't make much sense to me |
| 13:29 | <annevk> | I'm biased, though |
| 13:30 | <zcorpan> | annevk: how do they not make sense? |
| 13:37 | <AryehGregor> | Hixie_, I just filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=19473. Mozilla bug 799475 is blocked on it. It's not particularly important, but I would try to implement whatever it winds up being, provided you respond within about two days. So if you're interested, take a look sooner rather than later. |
| 13:37 | <AryehGregor> | (I have lots of free time for the next few days, but starting Wednesday break is over, so I'm unlikely to implement it anytime soon after that) |
| 13:42 | <AryehGregor> | annevk, so it seems case of charsets in Gecko matches the IANA spec. Is there a good reason for your encoding spec not to match the IANA spec, given that Gecko and WebKit apparently follow it? https://bugzilla.mozilla.org/show_bug.cgi?id=799917#c11 |
| 13:43 | <AryehGregor> | If it were just IE/Opera vs. Gecko/WebKit it would be a tossup to me, perhaps with slight edge to Gecko/WebKit because they're most likely to be web-compatible, but if there's an existing spec Gecko/WebKit are following that pushes things substantially toward them IMO. |
| 13:43 | <annevk> | do you mean the IANA charset registry? |
| 13:43 | <annevk> | since when are we adhering to that? everyone breaks it |
| 13:43 | <AryehGregor> | Simon linked to this: http://www.iana.org/assignments/character-sets |
| 13:43 | <annevk> | that's a pretty useless document though |
| 13:43 | <AryehGregor> | Even so, no need to deviate unnecessarily, is there? |
| 13:44 | <AryehGregor> | If Gecko/WebKit were doing the right thing and following whatever spec existed, even if that spec was a bad one, they shouldn't be the ones we ask to change. |
| 13:44 | <AryehGregor> | We should ask the ones who weren't following any spec to change. |
| 13:44 | <annevk> | if the spec was crappy and others did a better job I think it only makes sense to ignore prior art |
| 13:45 | <annevk> | e.g. Gecko implemented Mutation Observers without nullable NodeList |
| 13:45 | <annevk> | punishment is going to be for WebKit, not Gecko |
| 13:45 | <annevk> | because what Gecko did makes more sense |
| 13:45 | <AryehGregor> | Sure, because that was the only existing implementation. Here implementations are split. |
| 13:45 | <AryehGregor> | If all implementations did lowercase, then of course we should ignore the IANA. |
| 13:45 | <annevk> | no WebKit was first |
| 13:45 | <AryehGregor> | Well, okay. |
| 13:46 | <AryehGregor> | But I don't think lowercase makes more sense, necessarily. |
| 13:46 | <AryehGregor> | Although I guess it makes more sense than the IANA casing, which seems fairly inconsistent. |
| 13:47 | <AryehGregor> | Why "windows-1252" and not "Windows-1252"? |
| 13:47 | <annevk> | Gecko does windows-1252... |
| 13:47 | <smaug____> | Hmm, Stream API |
| 13:47 | <AryehGregor> | Right, I know. |
| 13:47 | <AryehGregor> | My point is just that it's inconsistent. |
| 13:48 | <annevk> | well yeah it is |
| 13:48 | <annevk> | Gecko seems to lowercase gbk btw, although I believe that's largely obsolete anyway |
| 13:50 | <annevk> | (euh, gbk is correct per the Encoding Standard) |
| 13:50 | <annevk> | gb18030 is also lowercase in Gecko |
| 13:51 | <zcorpan> | isn't a lowercase list nicer to have if you want to casefold for ascii-case-insensitive comparison? |
| 13:52 | <AryehGregor> | You can always case-fold both things you're comparing. |
| 13:52 | <AryehGregor> | So it's not a big deal either way. |
| 13:52 | <zcorpan> | not a big deal, sure |
| 13:53 | <annevk> | it would be nice if this could just be a lowercase enum in the end |
| 13:53 | <annevk> | although maybe there's not much point expressing it as such |
| 13:54 | <zewt> | AryehGregor: wonder if the spellcheck thing is related to Gmail (iirc) randomly showing spellcheck squiggles for words that aren't misspelled at all, which go away when I cursor over them |
| 13:54 | <AryehGregor> | zewt, in Gecko? |
| 13:54 | <zewt> | since presumably Gmail is doing a ton of script manipulation of the text, which might confuse the browser about what's user-entered and what's not |
| 13:54 | <zewt> | chrome, iirc |
| 13:55 | <zewt> | (not sure; i use FF at home and Chrome at work) |
| 13:55 | <zewt> | actually probably chrome since I have spellcheck turned off in FF |
| 13:56 | <AryehGregor> | I'm not sure what Chrome's algorithm is. |
| 14:09 | <annevk> | AryehGregor: anyway, we can match IANA, or match Gecko, or match WebKit, or Opera, or IE; in the end IE is the hardest to change and IE does the nicest thing here; I'd rather just align with IE |
| 14:09 | <gavinc> | annevk, Hixie: the use case is for a document that contains a fragment of HTML, as it might today contain a fragment of XML. There is some marked up content, but not a whole page/document worth. |
| 14:10 | <annevk> | gavinc: I'm aware of the use case |
| 14:10 | <gavinc> | annevk: Ah, okay, Hixie_ wasn't |
| 14:12 | <gavinc> | annevk: Todays RDF recomends using XML fragments. That seems a poor way forward for storing HTML. |
| 14:12 | <gavinc> | annevk: currently people do things like store random bits of HTML in xsd:strings, or other random datatypes |
| 14:13 | <gavinc> | annevk: http://www.w3.org/TR/rdf11-concepts/#section-html is what we currently have |
| 14:17 | <zewt> | (IE/MS has pretty much stonewalled and said they'll never, ever change anything to do with legacy encodings in any way, so the choice is "do what IE does" or "never have interop") |
| 14:17 | <annevk> | no that was just one guy |
| 14:17 | <annevk> | and he already backtraced later on |
| 14:19 | <zcorpan> | MS also have a track record of saying they'll never do something and then do it anyway |
| 14:20 | <zewt> | it sounded to me like he was equating "IE's encodings" to "the underlying codepage tables in Windows", which seemed wrong, but for legacy codepages it doesn't really matter to me which implementation to move towards, as long as we do |
| 14:24 | <annevk> | XHR2 was also not going to happen |
| 14:24 | <annevk> | I don't really care about their statements anymore, long term it'll be okay |
| 14:35 | <annevk> | miketaylr: browser.js should really be out of scope for the user-agent discussion |
| 14:35 | <annevk> | miketaylr: borwser.js can have all kinds of enhancements and access to special APIs |
| 14:36 | <annevk> | miketaylr: what's important for the XHR Standard is what happens if scripts all around the web can set a header that was previously thought of as "safe" |
| 14:37 | <miketaylr> | sure, i'm not really sold either way |
| 14:37 | <miketaylr> | just wanted to chime in on the "contact all sites" bit |
| 14:38 | <miketaylr> | because we all know how that turns out |
| 14:39 | <miketaylr> | annevk: are there any actual security concerns, or is it more of a "dont rock the boat" thing? |
| 14:39 | <miketaylr> | (though that's probably terrible wording to describe it) |
| 15:01 | <annevk> | miketaylr: don't remember all the details, abarth might know |
| 15:01 | <annevk> | miketaylr: that list is pretty old |
| 15:01 | <miketaylr> | k |
| 15:19 | <AryehGregor> | annevk, do you know of any way to test encoding canonicalization (via .characterSet) without using PHP or anything? |
| 15:19 | <AryehGregor> | IE doesn't support data: as iframe src, and IE/Opera don't work with document.open() (apparently). |
| 15:20 | <AryehGregor> | I'd write tests, but I don't know what a good way to do it is. |
| 15:20 | <AryehGregor> | (also, do we have any place to put such tests?) |
| 15:21 | <annevk> | other than data: URLs I don't really know, does that not work in IE10 either? |
| 15:21 | <AryehGregor> | (I've been using the W3C for DOM, but maybe that's not the best idea) |
| 15:21 | <annevk> | I wonder how data URLs function in IE10... |
| 15:21 | <AryehGregor> | No, IE deliberately only allows data: in very limited contexts. |
| 15:21 | <annevk> | ooh |
| 15:21 | <AryehGregor> | I'm not sure why. |
| 15:22 | <AryehGregor> | I understand they don't allow them in the URL bar, but why not as an iframe src? |
| 15:22 | AryehGregor | double-checks to be sure |
| 15:22 | <annevk> | I guess in theory you could navigate to a data URL and then navigate back |
| 15:22 | <annevk> | oh, not in the URL bar either |
| 15:23 | <AryehGregor> | "The webpage cannot be displayed. Most likely cause: Some content or files on this webpage require a program that you don't have installed. . . ." |
| 15:23 | <annevk> | if the server does not set charset you could just generate a bunch of pages |
| 15:24 | <annevk> | I mean apart from utf-16 they're all ASCII-compatible so that's not very hard |
| 15:24 | <AryehGregor> | There are what, a couple hundred things to test? |
| 15:25 | <annevk> | different labels? I suppose |
| 15:25 | <AryehGregor> | I'd prefer using PHP to that. |
| 15:26 | <annevk> | yeah, Gecko seems to frown upon PHP though |
| 15:27 | <annevk> | disregard that, I'm not sure if that was the real concern |
| 15:27 | <AryehGregor> | Yes, I'd really prefer to avoid PHP. |
| 15:27 | <AryehGregor> | I could make two different test versions, with one using data: URLs and one PHP but with all the same underlying code. |
| 15:28 | <jgraham> | The PHP thing is something we need to sort out |
| 15:29 | <jgraham> | It sucks if people are all writing tests in formats that only work on their setup as soon as anything dynamic is required on the server side |
| 15:29 | <AryehGregor> | If something is really required to be dynamic on the server side, is there any easier/more portable solution than PHP? |
| 15:30 | <AryehGregor> | Python would be harder to set up, if anything. |
| 15:30 | <jgraham> | AryehGregor: Well Mozilla are the people that object to PHP |
| 15:30 | <AryehGregor> | Except that Gecko already depends on Python, and probably WebKit does too. |
| 15:30 | <AryehGregor> | "Mozilla" doesn't object to anything, some people at Mozilla might. :) |
| 15:30 | <jgraham> | Let me rephrase |
| 15:30 | <AryehGregor> | annevk, also, do you have a place to put encoding tests? The WHATWG needs a place to put its tests. |
| 15:31 | <AryehGregor> | In some runnable fashion. |
| 15:31 | <jgraham> | Running PHP with your test setup seems like a headache |
| 15:31 | <jgraham> | I wouldn't want to do it, I don't think |
| 15:31 | <AryehGregor> | Preferably using github instead of Mercurial. :) |
| 15:31 | <AryehGregor> | (assuming Ms2ger is okay using hg-git ;) ) |
| 15:31 | <annevk> | AryehGregor: all tests in a single repo? |
| 15:31 | <jgraham> | annevk: One module per spec, please |
| 15:32 | <jgraham> | *repo |
| 15:32 | <annevk> | jgraham: what if we move specs around? |
| 15:32 | <AryehGregor> | Either way works for me. |
| 15:32 | <AryehGregor> | annevk, well, we could move tests around too, then. :) |
| 15:32 | <jgraham> | annevk: Then we will move the tests around |
| 15:32 | <AryehGregor> | I'd go with one repo, but I don't care much. |
| 15:32 | <jgraham> | You can even keep history, maybe |
| 15:32 | <annevk> | I don't care either, so I guess jgraham wins? |
| 15:32 | <jgraham> | Yay! |
| 15:32 | <annevk> | poor decision making... |
| 15:32 | <AryehGregor> | Yeah, you can with git, if you want to do voodoo magic. |
| 15:32 | <AryehGregor> | git-filter-branch, scary stuff. |
| 15:33 | <annevk> | AryehGregor: you can create repos I think |
| 15:33 | <jgraham> | I think you can do it without filter-branch |
| 15:33 | <jgraham> | Oh, well I guess you mean for the case where a subset of tests move |
| 15:33 | <jgraham> | Yeah, then you need filter-branch |
| 15:33 | <jgraham> | Or maybe git subtree |
| 15:33 | <annevk> | AryehGregor: I could give you access to http://testsuite.org/ maybe or have Hixie_ setup test.whatwg.org |
| 15:34 | <annevk> | preferably public domain btw for "our" tests |
| 15:35 | <annevk> | should we have some kind of naming convention? |
| 15:35 | <annevk> | e.g. encoding = spec; encoding.test = tests? |
| 15:35 | <annevk> | in the end though, if AryehGregor is going to set this up and prefers a single repo, have a single repo |
| 15:39 | <AryehGregor> | annevk, oh, HTML still references IANA for charsets. Do you have a bug open to get Hixie to switch? |
| 15:39 | <annevk> | yes |
| 15:43 | <annevk> | am I missing something or does https://www.w3.org/Bugs/Public/show_bug.cgi?id=17003 seem really bad for streaming? |
| 15:45 | <annevk> | ah no, it's not |
| 15:48 | <annevk> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=14689#c28 lol lol lol |
| 15:49 | <annevk> | refuse to define xml-stylesheet for years, then demand some other group to fix it by some deadline |
| 15:49 | <annevk> | classic |
| 15:49 | <annevk> | time to remove myself from the cc list |
| 16:06 | <dglazkov> | good morning, Whatwg! |
| 16:09 | <annevk> | morning dglazkov |
| 16:13 | <hober> | annevk: do you have citations for their prior refusals? that would help me to wontfix it. :) |
| 16:14 | <annevk> | zcorpan worked on defining xml-stylesheet and it was dumbed down all the time |
| 16:14 | <annevk> | I suspect you can find some of that discussion on their mailing list |
| 16:18 | <annevk> | I wonder what happens if I tell the CSS WG they have to define how two legacy encoding names influence bidi: https://www.w3.org/Bugs/Public/show_bug.cgi?id=17003 |
| 16:20 | <SimonSapin> | annevk: I don’t quite understand, how does this CSS? |
| 16:21 | <annevk> | DOM is identical, visually the text is reversed |
| 16:21 | <SimonSapin> | Based on the source character encoding? Should it? |
| 16:21 | <annevk> | every browser does it |
| 16:21 | <Hixie_> | gavinc: how does a document contain a fragment of xml/html? |
| 16:22 | <SimonSapin> | I’m still a few light-years away from implementing bidi at all :) |
| 16:24 | <annevk> | lucky you |
| 16:24 | <annevk> | this is for legacy content only btw; maybe you can demand utf-8 only stuff? |
| 16:26 | <SimonSapin> | maybe, but I generally don’t care much about legacy content in weasyprint |
| 16:27 | <AryehGregor> | annevk, jgraham: FTR, for the editing spec I just put the tests in the same repo as the spec. I think that actually makes quite a bit of sense. |
| 16:27 | <annevk> | AryehGregor: that works for me too, you have access to dom / encoding etc. already |
| 16:28 | <AryehGregor> | They just need to be checked out somewhere where they're runnable. |
| 16:28 | <AryehGregor> | Preferably in a way that allows running arbitrary old revisions. |
| 16:28 | <annevk> | AryehGregor: hmm I was gonna say that shouldn't be too hard... |
| 16:28 | <Hixie_> | AryehGregor: there was some designMode bug i cc'ed you on |
| 16:29 | <jgraham> | AryehGregor: That sounds fine |
| 16:29 | <AryehGregor> | Hixie_, I replied, didn't I? |
| 16:29 | <jgraham> | I wasn't really objecting to that, maybe I misunderstood the question |
| 16:29 | <Hixie_> | AryehGregor: probably, i haven't seen my bugmail yet. :-) if so, thanks muchly |
| 16:39 | <jsbell> | stupid undefined |
| 16:50 | <annevk> | jsbell: how do you feel about just supporting #2? |
| 16:51 | <annevk> | jsbell: I mean we can expose all kinds of things, but so far we only heard requests for not propagating the weird BOM behavior of the web to the API |
| 16:51 | <jsbell> | Let me dig up the message requesting for BOM handling for utf-16 specifically... |
| 16:51 | <annevk> | jsbell: the weird BOM behavior is ignoring the encoding label in favor of the BOM, this is the reverse |
| 16:54 | <jsbell> | Looks like http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-August/036821.html and no-one else championed for it |
| 16:54 | <jsbell> | zewt: ^^ your message (re: special casing "utf-16" like iconv) |
| 16:54 | <annevk> | I talked with zewt and my impression is that mainly he cares about not propagating utf-16 |
| 16:55 | <jsbell> | annevk: if we do #2 only then if users want BOM-switching they can sniff the first two bytes themselves. I'm fine with that. |
| 16:56 | <jsbell> | (or 3 if they care about UTF-8) |
| 16:56 | <annevk> | jsbell: as for speccing the streaming variant, it seems that needs some special casing to only consume the BOM at the start |
| 16:56 | <jsbell> | I don't think anyone was championing #1 over #2 ever |
| 16:58 | <jsbell> | annevk: yes... the spec right now attempts to define a byte stream provided by multiple calls and special handling of the start (i.e. suspending processing until N bytes are present), but it's not very clearly written. |
| 16:58 | <annevk> | and the Encoding spec just assumes a byte stream whereas the API really provides a fixed set of bytes each time |
| 16:58 | <jsbell> | annevk: I was hoping to excise that into a more algorithmic form but $WORK + $FAMILY |
| 16:58 | <annevk> | yeah fair enough |
| 16:59 | <annevk> | I'll think about it a bit, not sure when I'll have time to draft, maybe tomorrow |
| 16:59 | <annevk> | I've been meaning to get to URLs, but they can wait a little longer |
| 16:59 | <annevk> | bbl |
| 17:00 | <jsbell> | Hrm, I probably need to dust off my URL polyfill |
| 17:07 | <Hixie_> | hober: what crack are they smoking over there |
| 17:07 | <Hixie_> | hober: that change of screen readers to printers completely misses the point of the paragraph |
| 17:10 | <hober> | Hixie_: fortunately, that change doesn't alter any normative requirements. silver lining? |
| 17:11 | <gavinc> | Hixie_: A Turtle document contains the data about a book. Part of that data is a description of the book which includes markup such as <em>, <strong>, <ul>, maybe a <ruby> or two. The description is not a complete HTML page, but might be designed to be displayed inside another page along with the rest of the data. |
| 17:11 | <Hixie_> | gavinc: oh, i see. If you just want to describe a DOM fragment in a non-XML non-HTML document, I would strongly recommend using XML only. |
| 17:12 | <gavinc> | Hixie_: ... really? |
| 17:12 | <gavinc> | Hixie_: How would I insert that into an HTML document? |
| 17:12 | <Hixie_> | gavinc: yeah, XML can describe arbitrary DOM fragments much better than HTML |
| 17:12 | <Hixie_> | gavinc: parse it into a DOM fragment, then insert it, once it's in DOM form, there's no issue |
| 17:12 | <gavinc> | Hixie_: Yes, I agree, but putting that fragment into an HTML document... ahh, use DOM as the interchange? |
| 17:13 | <Hixie_> | well how else would you do it? |
| 17:13 | <gavinc> | Simple string concat ;) |
| 17:13 | <gavinc> | The same way most CMSes do today |
| 17:14 | <Hixie_> | oh well if you just want to do string concatenation, then you don't have to worry about parsing the fragment |
| 17:14 | <Hixie_> | so then just include a fragment, datatype "string" |
| 17:15 | <Hixie_> | but that's just asking for trouble |
| 17:15 | <gavinc> | Yes, thus the goal of having an HTML datatype |
| 17:15 | <Hixie_> | i mean string concatenation is asking for trouble |
| 17:15 | <gavinc> | Yes |
| 17:15 | <Hixie_> | having an HTML datatype doesn't help if you're still concatenating |
| 17:15 | <gavinc> | No, but it does say "THIS IS NOT A STRING" |
| 17:16 | <gavinc> | since doing string concat with strings is perfectly fine |
| 17:16 | <gavinc> | but not with HTML |
| 17:16 | <Hixie_> | if the data type you're trying to represent is just a dom fragment, then XML is your best bet. |
| 17:16 | <Hixie_> | text/html doesn't have a sane way to represent fragments |
| 17:17 | <Hixie_> | whereas XML is perfect for it |
| 17:17 | <gavinc> | in that case, can you look at http://dvcs.w3.org/hg/rdf/raw-file/default/rdf-concepts/index.html#section-XMLLiteral ? |
| 17:17 | <Hixie_> | what about it? |
| 17:18 | <gavinc> | So if we added to that a note about how to store HTML fragments using that, it would make more sense then recommending the new HTML datatype? |
| 17:19 | <Hixie_> | just drop the HTML datatype entirely |
| 17:19 | <gavinc> | the value space for XMLLiteral USED to be the canonical lexical form of the XML |
| 17:19 | <gavinc> | I think changing it to the DOM makes this all saner? |
| 17:20 | <gavinc> | okay |
| 17:20 | <Hixie_> | i don't understand what you just said |
| 17:20 | <gavinc> | yes, that's alright |
| 17:20 | <gavinc> | 1.0 had a very bad idea |
| 17:20 | <gavinc> | that no one implemented correctly |
| 17:21 | <Hixie_> | you have no idea how hard it is for me to hold my tongue when you give me openings like that |
| 17:21 | <gavinc> | heh |
| 17:21 | <gavinc> | indeed |
| 17:22 | <gavinc> | and once there is a DOM DocumentFragment, that can easily be added to an HTML document |
| 17:22 | <gavinc> | okay |
| 17:22 | <gavinc> | and your preferred reference for DOM is http://dom.spec.whatwg.org/ |
| 17:23 | <Hixie_> | once there is a DOM DocumentFragment, that can easily be added to a DOM Document, which could contain HTML |
| 17:23 | <Hixie_> | http://dom.spec.whatwg.org/ is to my knowledge the only current reference of the DOM spec |
| 17:24 | <Hixie_> | AryehGregor: if you're still around, see https://www.w3.org/Bugs/Public/show_bug.cgi?id=19473 |
| 17:24 | <gavinc> | mmm, not exactly sure how to link non living standards to living ones |
| 17:24 | <gavinc> | sigh |
| 17:24 | <Hixie_> | <a href="url...">name...</a> |
| 17:24 | <gavinc> | I'll make that someone elses issue ;) |
| 17:25 | <gavinc> | yes :D |
| 17:46 | <annevk> | jsbell: https://github.com/annevk/url patches welcome |
| 17:46 | <annevk> | jsbell: it's based on http://url.spec.whatwg.org/ (or rather the other way around) |
| 17:53 | <Ms2ger> | annevk, yeah, I am |
| 18:23 | <hober> | hsivonen++ |
| 18:26 | <annevk> | that bug I just unsubscribed from? |
| 18:27 | <annevk> | nope |
| 18:37 | <annevk> | hober: could you maybe ask ap about https://www.w3.org/Bugs/Public/show_bug.cgi?id=17053 ? |
| 18:38 | <annevk> | bbl |
| 18:53 | <Hixie_> | i have lost one of my scripts |
| 18:54 | <Hixie_> | it runs every hour and futzes with my imap folders to track the work i have to do |
| 18:54 | <Hixie_> | but i can't recall where it is |
| 18:54 | <Hixie_> | -_- |
| 18:54 | Hixie_ | looks up the crontab file |
| 18:59 | <Hixie_> | hsivonen: for the record, with the menuitem thing, it's in the spec because everyone seems to agree that it's a problem we should resolve, and nobody has proposed something better. The only feedback I'm aware of is the <menuitem> feedback, and I considered it carefully, but it had numerous flaws (e.g. poor back-compat story) which is why I didn't adopt it. |
| 19:00 | <Hixie_> | hsivonen: I certainly object to the characterisation of having it in the spec being "bait for indifferent implementors" |
| 19:00 | <Hixie_> | hsivonen: I think I've shown numerous times over the years that things without buy-in get dropped. |
| 19:01 | <Hixie_> | hsivonen: including dropping entire specs that did have buy-in from multiple vendors but didn't have buy-in from Mozilla (e.g. WebSQL, the original networking stuff, many parts of Web Forms 2) |
| 19:03 | <annevk> | what are all you guys talking about? |
| 19:03 | <annevk> | ooh, is this public-html |
| 19:07 | <Hixie_> | anyone got any plugin test cases? I need a way to test whether an <embed> element is instantiating a plugin or not |
| 19:07 | <Hixie_> | a possibly invisible <embed> |
| 19:07 | <Hixie_> | anyone got a flash file that goes "bing" or something? |
| 19:07 | <annevk> | you had plenty yourself iirc |
| 19:07 | <Hixie_> | well i wrte my own NPAPI plugin once but I don't know where that is nowadays |
| 19:08 | <Hixie_> | and I don't really want to try to recompile it :-) |
| 19:10 | <annevk> | http://www.bobbyvandersluis.com/flashembed/testsuite/ has a bunch of tests anyway |
| 19:11 | <Hixie_> | thanks |
| 19:11 | <Hixie_> | seems like none of those woudl work if the plugin is invisible |
| 19:11 | <Hixie_> | damnit |
| 19:13 | <annevk> | Hixie_: found this http://flashbeep.net/ |
| 19:13 | <annevk> | Hixie_: via that tool from your employer |
| 19:13 | <annevk> | dunno if it works via <embed> though |
| 19:13 | <Hixie_> | ho ho! |
| 19:13 | <annevk> | hmm |
| 19:13 | <Hixie_> | thanks |
| 19:14 | <Hixie_> | will try |
| 19:17 | <Hixie_> | nope, looks like <embed> doesn't expose the interface, at least not in chrome |
| 19:18 | <Hixie_> | hm, the spec says it should |
| 19:19 | <annevk> | http://www.hark.com/clips/pvhqchpdfl-data-beep-modern-1 autoplays a beep it seems |
| 19:20 | <Hixie_> | oh i was trying to make the other one work cross-origin, that'll be my problem |
| 19:21 | <Hixie_> | ohh, let's try that one |
| 19:21 | <annevk> | can't get it to work |
| 19:21 | <annevk> | oh maybe same problem |
| 19:22 | <Hixie_> | that page has all kinds of new HTML elements on it |
| 19:22 | <Hixie_> | <figure>, <header>, microdata... |
| 19:22 | <Hixie_> | lol |
| 19:22 | <Hixie_> | that page is using <audio> |
| 19:23 | <annevk> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3Cembed%20src%3D%22http%3A%2F%2Fcdn.hark.com%2Fswfs%2Fplayer_fb.swf%3Fpid%3Dpvhqchpdfl%26as%3D1%22%3E |
| 19:23 | <annevk> | Hixie_: doesn't autoplay when display:none |
| 19:23 | <Hixie_> | doesn't instantiate when display:none, i hope |
| 19:23 | <annevk> | (the embed code it provides is for Flash) |
| 19:23 | <annevk> | I guess that's what happens, right |
| 19:23 | <Hixie_> | that live dome page doesn't do anything for me |
| 19:24 | <Hixie_> | oh, i know why |
| 19:24 | <Hixie_> | silly xss protection |
| 19:24 | <annevk> | :/ |
| 19:24 | <Hixie_> | thanks, that's perfect |
| 19:24 | <Hixie_> | annevk++ |
| 19:55 | <siebrand> | Hi. I'd like to fix an HTML5 validation issue MediaWiki is having by adding ResourceLoaderDynamicStyles as a meta extension. See http://www.mediawiki.org/wiki/Thread:Project:Support_desk/ResourceLoaderDynamicStyles_and_Wiki_validation for details. |
| 19:55 | <siebrand> | How to proceed? |
| 19:56 | <Hixie_> | is there a spec for this meta value? |
| 19:56 | <Hixie_> | (you can add it to the wiki, just give me your e-mail address, name, and preferred username and i'll create an account) |
| 20:04 | <annevk> | (you only need email/username) |
| 20:04 | annevk | lowballs Hixie_ :p |
| 20:05 | <siebrand> | Hixie_: I'll make sure we'll get a spec. |
| 20:06 | <siebrand> | Hixie_: Details provided in prig msg. |
| 20:06 | <siebrand> | priv, even |
| 20:09 | <siebrand> | Hixie_: While Im at it, can you maybe ping the wiki maintainer about possibly updating the wiki? MediaWiki 1.17alpha is slightly outdated :) |
| 20:10 | <annevk> | siebrand: I did the other day, he's afraid of regressions and rather works on standards/tests |
| 20:10 | <annevk> | siebrand: if you're interested in helping us out, ping AryehGregor ;-) |
| 20:11 | <siebrand> | annevk: Are you guys doing anything special? From what I can see you're only got two very well maintained extensions set up (both in use by Wikimedia). |
| 20:11 | <annevk> | siebrand: I doubt it, AryehGregor might know, he updated it the last time |
| 20:11 | <siebrand> | annevk: You should be able to update to a Wikimedia Git branch without issue, as far as I can tell. Is Aryeh the maintainer? |
| 20:12 | <annevk> | yeah |
| 20:12 | <siebrand> | annevk: well, he knows his shit when it comes to MediaWiki, but has been very inactive for the past 12-18 months. |
| 20:14 | <Hixie_> | he's been active over here :-) |
| 20:14 | <Hixie_> | setting up your account now, one sec |
| 20:15 | <Hixie_> | done |
| 20:15 | <Ms2ger> | siebrand, he mentioned updating it earlier, but didn't want to spend his employer's time on doing it :) |
| 20:15 | <siebrand> | Hixie_: Much appreciated. Might take a few days before I've got the table row content together. |
| 20:15 | <Hixie_> | siebrand: btw we'd love to just reenable arbitrary logins on that wiki, but we got snowed under with spam |
| 20:16 | <Hixie_> | siebrand: so if y'all over in mediawiki land can figure out how to get rid of spammers, that'd be awesome. ;-) |
| 20:16 | <siebrand> | Hixie_: it's really hard to combat lately :( |
| 20:16 | <Hixie_> | yeah, tell me about it |
| 20:16 | <jgraham> | Hmm, when hsivonen says "our" is he stating an official Mozilla position? |
| 20:16 | <Hixie_> | i'm actually surprised nobody has just asked us for an account |
| 20:16 | <siebrand> | we're using QueryCaptcha at translatewiki.net. |
| 20:16 | <siebrand> | That 4-5 custom questions tends to work for 14 days or less. |
| 20:16 | <Hixie_> | jgraham: last i heard, mozilla was like google, with as many opinions as contributors :-P |
| 20:17 | <siebrand> | Then someone's automated that too. |
| 20:17 | <siebrand> | Recaptcha is solved by computers, so no more luck there. |
| 20:17 | <Hixie_> | siebrand: we were getting lots of people who weren't even automating things, just doing it manually |
| 20:17 | <Ms2ger> | jgraham, in general, don't assume anybody is stating an official Mozilla position :) |
| 20:17 | <jgraham> | Ms2ger, Hixie_: That's why I ask |
| 20:17 | <Ms2ger> | jgraham, pointer? |
| 20:18 | <jgraham> | http://lists.w3.org/Archives/Public/public-html/2012Oct/0055.html |
| 20:18 | <jgraham> | (I haven't read the full message yet) |
| 20:20 | <Ms2ger> | Not something I remember hearing many people complain about, but that might just be me |
| 20:23 | <Hixie_> | food time |
| 20:23 | <Hixie_> | bbl |
| 23:59 | <ap__> | Hixie_: can shared workers actually be created by name "without the applications having to keep track of a common URL for the script used to provide the service"? I only see SharedWorker constructor that requires a matching URL even if a name is provided. Is there another API that can find a worker by name? |