| 07:07 | <Ms2ger> | annevk-cloud, it's resolved positively if you consider it ;) |
| 07:46 | <zcorpan> | jgraham: now i get the following error when trying to start wptserve |
| 07:46 | <zcorpan> | from wptserve import server as wptserve, handlers |
| 07:46 | <zcorpan> | ImportError: cannot import name handlers |
| 09:07 | <zcorpan> | there's no non-rendering almost standards quirk, right? |
| 09:08 | <zcorpan> | MikeSmith: any news on FXTF? |
| 09:08 | <MikeSmith> | oh |
| 09:08 | <MikeSmith> | forgot |
| 09:08 | <MikeSmith> | lemme do it now |
| 09:09 | <MikeSmith> | zcorpan: for dvcs.w3.org, right? |
| 09:09 | <jgraham> | zcorpan: OK, I will fix |
| 09:09 | <zcorpan> | my user is spieters |
| 09:09 | <zcorpan> | MikeSmith: yeah |
| 09:09 | <MikeSmith> | npok |
| 09:09 | <MikeSmith> | oops |
| 09:09 | <MikeSmith> | ok checking now |
| 09:12 | <MikeSmith> | zcorpan: ok should be working now |
| 09:13 | <zcorpan> | nice way to resolve bugs http://www.w3.org/2011/webappsec/minutes/webappsec-minutes-27-Aug-2013.html#item03 |
| 09:18 | <MikeSmith> | haha |
| 09:20 | <zcorpan> | MikeSmith: hmm, still get auth failed |
| 09:21 | <MikeSmith> | hmm |
| 09:21 | <MikeSmith> | zcorpan: you only have one w3c username, right? |
| 09:22 | <zcorpan> | yeah |
| 09:22 | <zcorpan> | should it work with user+password? |
| 09:23 | <MikeSmith> | yeah |
| 09:23 | <MikeSmith> | lemmme try right now myself |
| 09:24 | <MikeSmith> | with my credentials |
| 09:27 | <MikeSmith> | so it works for me |
| 09:27 | <MikeSmith> | zcorpan: another thing I can try just for the heck of it is to add you to the "CSS-SVG Task Force" |
| 09:28 | <MikeSmith> | the ACLs allows anybody in that DB group to push |
| 09:28 | <MikeSmith> | OK if I add you there? |
| 09:28 | <zcorpan> | sure |
| 09:29 | <MikeSmith> | OK, I've added you |
| 09:29 | <MikeSmith> | so please try again |
| 09:29 | <MikeSmith> | I don't think it will make a difference but who knows |
| 09:32 | <MikeSmith> | yeah error logs show 401 for earlier attempts |
| 09:43 | zcorpan | testing ... |
| 09:43 | <zcorpan> | seems to work! |
| 09:44 | <zcorpan> | thanks MikeSmith |
| 09:44 | <MikeSmith> | cool |
| 09:47 | <MikeSmith> | zcorpan: btw I guess you already know there's a big delay when pushing to the csswg repo and the FXTF one too |
| 09:47 | <MikeSmith> | it's expected due to stuff on the hg server side that Peter asked me to set up |
| 10:01 | <hsivonen> | Lots of words in a destined-to-be-WONTFIXed bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23646 |
| 10:01 | <MikeSmith> | zcorpan: any idea where the editor's draft of CORS is? |
| 10:02 | <annevk-cloud> | MikeSmith: fetch.spec.whatwg.org |
| 10:02 | <MikeSmith> | hsivonen: yeah |
| 10:03 | <annevk-cloud> | hsivonen: whoah |
| 10:04 | <MikeSmith> | annevk-cloud: :) I meant the WebAppSec one. Last I saw they still had your name on it as editor, which seems especially odd now that they've summarily closed bugs you raised against the spec. |
| 10:05 | <MikeSmith> | hmm, or are they not even maintaining a separate ED at all? |
| 10:19 | <zcorpan> | why maintain a spec if you can INVALID the bugs? |
| 10:20 | <zcorpan> | (dunno where the spec is if there is one) |
| 10:23 | <hsivonen> | Whoa. Web MIDI. Is Chrome implementing that stuff? |
| 10:24 | <MikeSmith> | hsivonen: yeah I think they already have |
| 10:24 | <MikeSmith> | cwilso been working on it |
| 10:25 | <MikeSmith> | hsivonen: why Whoa? bad idea? |
| 10:29 | <MikeSmith> | hsivonen: also https://bugzilla.mozilla.org/show_bug.cgi?id=836897 (re: Web MIDI) |
| 10:31 | <odinho> | The CORS-thingy is meant to go through the process about as it is now. |
| 10:36 | <MikeSmith> | odinho: if that's how the group wants to do things, I won't complain but I guess it means the W3C spec is just going to become further irrelevant to implementors |
| 10:37 | <MikeSmith> | in which case the sooner it goes to Rec the better, I guess |
| 10:38 | <odinho> | CORS is not getting a frenzy of updates by annevk-cloud either. And yes, everyone is clear (I think) that the canonical spec is at fetch.spec.whatwg.org |
| 10:38 | <odinho> | At least that's how I think of it. |
| 10:38 | <MikeSmith> | ah OK |
| 10:44 | <Ms2ger> | zcorpan, bah, high-quality review comments :) |
| 10:46 | <cwilso> | Hsivonen: yup, chrome canary on osx has experimental web midi support. I also wrote an NPAPI-based plugin. |
| 10:47 | <cwilso> | And yes, please elaborate "whoa." :) |
| 10:48 | <MikeSmith> | http://chrislord.net/index.php/2013/10/28/sabbatical-over/ is a good read; "WebGL cannot be relied upon", "Canvas performance isn’t great", "Appcache is awful", "DOM rendering is slow" ... |
| 11:03 | <zcorpan> | Ms2ger: sorry :-P |
| 11:04 | <zcorpan> | Ms2ger: you could review my PRs as payback :-) |
| 11:10 | <zcorpan> | does w3cmemes have a mod queue for new posts? |
| 11:12 | <hsivonen> | cwilso, MikeSmith: whoa as in "I didn't realize Google cared about MIDI peripherals." |
| 11:13 | <MikeSmith> | hsivonen: ah OK |
| 12:05 | <jgraham> | zcorpan: Pushed the directory listing fixes |
| 12:06 | <zcorpan> | jgraham: thanks |
| 12:14 | <annevk> | Ms2ger: seems zcorpan already reviewed |
| 12:14 | <Ms2ger> | Yeah |
| 12:15 | <Ms2ger> | annevk, so I made the characterSet test a case-insensitive match for now, if you don't object |
| 12:15 | <annevk> | ew |
| 12:15 | <annevk> | I won't object, but ew |
| 12:15 | <annevk> | Ms2ger: IE10 does lowercase |
| 12:16 | <Ms2ger> | Yeah, agreed with ew |
| 12:16 | <Ms2ger> | I'll check if we have a test for characterSet itself already |
| 12:22 | <cwilso> | Hsivonen well, some of us definitely do. :) |
| 12:27 | <MikeSmith> | cwilso: I guess you know MIDI-peripheral vendors seem to care about Web MIDI too |
| 12:28 | <cwilso> | Yeah. Now I just need to get some other browsers interested. |
| 12:28 | <MikeSmith> | yeah |
| 12:29 | <cwilso> | And yeah - I'm meeting with some of the this week (I'm in Tokyo) |
| 12:29 | <Ms2ger> | cwilso, seems like patches to Gecko might get accepted ;) |
| 12:29 | <MikeSmith> | cwilso: ahah |
| 12:29 | <cwilso> | Ms2ger: dunno. Really need some more review of the spec. |
| 12:29 | <Ms2ger> | zcorpan, reviewing your PRs hardly seems like payback :) |
| 12:30 | <zcorpan> | worth a shot |
| 12:30 | <Ms2ger> | Also, those are all complex ones, no? :) |
| 12:31 | <Ms2ger> | "move Opera's media tests" - aaah |
| 12:31 | <Ms2ger> | "Add media resource selection tests" - aaah |
| 12:32 | <Ms2ger> | "Add tests for structured clone for workers" - hrm, maybe |
| 12:33 | <MikeSmith> | cwilso: if you're free for lunch some time this week, please ping me. I'll probably be nearby the Mori-tower area tomorrow around lunchtime. I meet up with Dominic Cooney for lunch now and then, and sometimes Eiji Kitamura and others there |
| 12:34 | <Ms2ger> | jgraham, uh, looks like you're getting a few error emails from critic :) |
| 12:34 | <cwilso> | MikeSmith: sounds good. Might be able to do tomorrow, or Wednesday. |
| 12:36 | <MikeSmith> | cwilso: OK. I'll try to ping you around 11am or so tomorrow |
| 12:38 | Ms2ger | poofs |
| 12:41 | <smaug____> | cwilso: I'd be interested to see midi in gecko, but need to figure out first whether it is possible to get reasonable low latency midi+audio handling |
| 12:41 | <smaug____> | midi api should be exposed in workers as the audio api |
| 12:42 | smaug____ | has tried to find some midi experts in Finland to comment the spec |
| 12:42 | <cwilso> | Smaug: of course. Audio latency can be around 3ms; MIDI should be around that, but I haven't tested yet. |
| 12:43 | <cwilso> | And yeah, we've discussed availability in workers, but we should solve that together with audio in workers. |
| 12:44 | <smaug____> | cwilso: what kind of latency you get midi-input->synthesizing audio->audio output |
| 12:46 | <cwilso> | It's audio hardware dependent, of course - but under ten ms, on osx at least. |
| 12:47 | <cwilso> | (Sorry for brevity - on mobile) |
| 12:48 | <smaug____> | ok, under 10 is better than I thought |
| 12:48 | <smaug____> | anything complex in the main thread ofc breaks that |
| 12:48 | <smaug____> | which is why worker support is rather crucial |
| 13:10 | jgraham | is worried Ms2ger works for the NSA |
| 14:16 | <annevk> | I guess I should clone those CORS bugs... |
| 14:21 | <annevk> | And done... |
| 14:49 | <MikeSmith> | I know I'm preaching to the choir here, but how incredibly assheaded is it for a W3C WG to fork a spec from somewhere else and then just ignore legitamate bugs/comments that are raised against the spec, refuse to make any changes to it, and so force the bugs to get cloned |
| 14:49 | <MikeSmith> | nobody is forcing the WebAppSec WG to do this |
| 14:49 | <annevk> | So what I think is going on here is that Brad wants to publish it as a REC |
| 14:50 | <annevk> | Because p-word |
| 14:50 | <MikeSmith> | ah |
| 14:50 | <annevk> | And he's taking every shortcut he can, although I'm in the loop |
| 14:50 | <annevk> | So I might be wrong |
| 14:50 | <MikeSmith> | christ the levels of absurdity we have reached here |
| 14:50 | <annevk> | I definitely don't hope the plan is for other specifications to reference the CORS REC, that'd be terrible |
| 14:50 | <jgraham> | So this kind of feels like a fundamental tension at the W3C |
| 14:51 | <annevk> | (And doesn't work anyway.) |
| 14:51 | <jgraham> | The W3C's big value proposition is the P— Policy |
| 14:52 | <MikeSmith> | jgraham: yeah |
| 14:52 | <jgraham> | But having to get specs through a process to Rec. means the specs are, generally speaking, wrong |
| 14:52 | <annevk> | I meant to say I'm not in the loop above... All I know about WebAppSec can be observed on the public list. |
| 14:52 | <jgraham> | Because the needs of The Process are very different to the needs of implementors |
| 14:53 | <MikeSmith> | jgraham: the p policy is still important, since despite years of talking about it, we still offer no alternative for that part |
| 14:53 | <MikeSmith> | jgraham: right again |
| 14:54 | <jgraham> | This is the fundamental problem that the W3C has to resolve, or someone will come along and eat its lunch |
| 14:54 | <gsnedders> | I see no end of people stopping caring about the W3C brand, though, outside of the browser vendors. |
| 14:55 | <MikeSmith> | but we would maybe have that problem regardless of where we did things, if we have any mechanism for getting actual RF agreements |
| 14:55 | <jgraham> | gsnedders: Try that sentence again with fewer negatives |
| 14:56 | <MikeSmith> | jgraham: I mean maybe we would have such as tension anywhere, if we were to be implementing some way to get RF agreements |
| 14:56 | <jgraham> | MikeSmith: It is very unclear that an organisation set up with the goal of having the lowest-overhead-possible process and a RF policy would look much like the W3C |
| 14:56 | <jgraham> | MikeSmith: You aren't gsnedders, I think :) |
| 14:56 | <MikeSmith> | jgraham: there's only one way to test that |
| 14:56 | <gsnedders> | s/no end of people/nobody/ |
| 14:57 | <jgraham> | gsnedders: Or, with fewer negatives, "People outside the browser vendors continue to care about the W3C brand"? |
| 14:58 | <MikeSmith> | annevk: I guess the sad part is that there will be other specs referencing the CORS REC and we won't have any way to stop them |
| 14:58 | <gsnedders> | It's sad there's been no real process towards RF agreements, and as long the W3C WGs have more members, the W3C RF agreements will still be more valuable. |
| 14:58 | <gsnedders> | jgraham: Indeed. |
| 14:58 | <jgraham> | MikeSmith: Yes. If I was the W3C I might be worried that someone was going to test that |
| 14:58 | <annevk> | MikeSmith: we'll wave the 386 flag |
| 14:58 | <MikeSmith> | hehheh |
| 14:58 | <jgraham> | gsnedders: If only the W3C found an easy way to drag its name through the mud. Like getting on board with the DRM people, for example. |
| 14:59 | <MikeSmith> | somebody should make an actual 386 flag |
| 14:59 | <gsnedders> | jgraham: But most W3C members don't care, AFAICT. |
| 14:59 | <jgraham> | gsnedders: Oh, you mean Members |
| 15:00 | <annevk> | What have W3C Members ever done for the web? |
| 15:00 | <annevk> | Most of them, not much, as far as I can tell |
| 15:00 | <jgraham> | Well I find it very hard to understand why most Members even join. |
| 15:01 | <annevk> | They pay the W3C, which puts the money towards getting more W3C Members |
| 15:01 | <gsnedders> | jgraham: I posit the W3C brand still being valuable is because of the Members. |
| 15:01 | <jgraham> | And keeping MikeSmith in trousers |
| 15:01 | <jgraham> | That's very important |
| 15:01 | <MikeSmith> | I think most sane people care about having an environment to work in that isn't causing redunancy and out-of-date information to be published as standards, and referenced by others as standard |
| 15:01 | <jgraham> | gsnedders: Really? Does anyone know or care that Disney and Boeing are part of the W3C? |
| 15:02 | <annevk> | jgraham: hah, agreed |
| 15:02 | <MikeSmith> | people care |
| 15:02 | <annevk> | (with keeping MikeSmith dressed) |
| 15:02 | <MikeSmith> | heh |
| 15:03 | <MikeSmith> | Members are companies comprised of people |
| 15:03 | <jgraham> | People that aren't W3C Team or employees of those companies? |
| 15:03 | <MikeSmith> | people who are generally pretty smart |
| 15:03 | <MikeSmith> | employees |
| 15:03 | <MikeSmith> | jgraham: ^ |
| 15:04 | <jgraham> | Right. So, I don't think that is relevant to gsnedders' point |
| 15:04 | <gsnedders> | jgraham: Evangelism |
| 15:04 | <gsnedders> | Which is mostly done by W3C Members, no? |
| 15:04 | <gsnedders> | Or rather their employees. |
| 15:04 | <jgraham> | Evangalism of what, to whom? |
| 15:04 | <gsnedders> | If you want to wreck the W3C's standing, convince browser manufacturers to terminate their membership. |
| 15:05 | <gsnedders> | It'd be stupid given the IP rules, but it would make a big statement. |
| 15:05 | <MikeSmith> | I would think anybody in the W3C membership who's objectively looking at what the WebAppSec WG is doing with CORS would have to be kinda wondering WTF? |
| 15:05 | <MikeSmith> | anyway, I should shut up and take a break |
| 15:06 | <jgraham> | gsnedders: To do that you would need somewhere else to go that had a similar RF agreement |
| 15:06 | <jgraham> | Hence my point above that the W3C should be worried that if they don't fix their Process someone will come along with a much lighter-weight process, but the same or similar IPR rules and eat their lunch |
| 15:07 | <jgraham> | It would perhaps have happened with WHATWG if we had had the IPR stuff to get Microsoft on board |
| 15:08 | <gsnedders> | jgraham: The value of the IPR agreements at the W3C comes from the number of Members, though. What does the WHATWG have to offer? It makes it harder for employees of plenty of orgs to join the mailing list if you require everyone on the mailing list to have agreed to IPR agreement. |
| 15:08 | <jgraham> | Does it? |
| 15:09 | <annevk> | W3C does not require that either for its mailing lists. |
| 15:09 | <jgraham> | It only comes from the Members that are actually in the group publishing the spec |
| 15:09 | <annevk> | So I guess I should define document.origin. People have been asking about it for a while now... |
| 15:10 | <gsnedders> | annevk: Which mailing lists? I thought this was the reason why public-html-comments was a separate list? |
| 15:10 | <annevk> | And so document.origin would return the global object's associated document's origin. |
| 15:11 | <annevk> | gsnedders: e.g. I'm on plenty of lists without being a WG Member |
| 15:11 | <gsnedders> | jgraham: Well, the number of patents you get RF licensing of is presumably linked to the number of members. |
| 15:11 | <gsnedders> | annevk: You're employed by a member though, which seems to have an effect. |
| 15:11 | <annevk> | not as far as subscribing rules go... |
| 15:13 | <gsnedders> | So, one can still get patented stuff into a W3C spec by sending feedback on a spec, then suing everyone? |
| 15:13 | <gsnedders> | Then what's the worth of the patent agreement. |
| 15:14 | <gsnedders> | Why not just not "join" any WG, because that means you then need to declare patents? |
| 15:17 | <annevk> | gsnedders: dude, given that the W3C blatantly copies WHATWG drafts, there's any number of ways that can happen |
| 15:19 | <gsnedders> | Then what does the W3C actually gain you? |
| 15:19 | <gsnedders> | And can it please stop raining? I know I'm in Glasgow, but... |
| 15:21 | <jgraham> | gsnedders: The W3C gains you that Apple can't sue you. It doesn't prevent Eolas suing you. |
| 15:23 | <jgraham> | (other litigators are avaliable) |
| 16:04 | <Domenic_> | annevk: seems like it's time to bust out the streams API counterproposal... |
| 16:04 | <annevk> | Domenic_: referring to Brian's tweet? |
| 16:04 | <Domenic_> | annevk: ya and the public-webapps mailing list post |
| 16:05 | <annevk> | Domenic_: would be pretty great if you have the time |
| 16:05 | <annevk> | Domenic_: talked with sicking a bit last Tuesday and basically it seems Firefox OS will go with MozStream (details unclear) if we don't have something soon |
| 16:06 | <annevk> | Domenic_: (which might be fine as long as it remains contained in the Firefox OS walled garden) |
| 16:06 | <Domenic_> | annevk: Yeah well I just finished my major promises refactor so should be able to do it this week/end. |
| 16:07 | <annevk> | Domenic_: also talked with Max Ogden at MozFest and he was mostly like "just give us the features" :-) |
| 16:07 | <Domenic_> | annevk: haha yeah. he will just build a solid abstraction on top of it, as long as it is possible. |
| 16:07 | <annevk> | right |
| 16:08 | <Domenic_> | but it would be good to have something usable by specs, not just people who consume Max's libraries :) |
| 16:10 | <annevk> | Domenic_: do you want me to email public-webapps about your forthcoming proposal or do it yourself? |
| 16:11 | <annevk> | Domenic_: or maybe wait until Monday |
| 16:11 | <annevk> | ooh wait, Monday it will have expired |
| 16:12 | <Domenic_> | annevk: not sure what would be best. Advertising semi-vaporware seems bad. I could have it done by Sunday-ish. Or I could outline what's wrong with the current proposal pretty quickly? Get Isaac to chip in on that? |
| 16:14 | <marcosc> | Domenic_: yeah, comment on the current one. |
| 16:14 | <marcosc> | We can postpone the current CFC then |
| 16:15 | <marcosc> | We can just mention you have an alternative and need a few more days |
| 16:15 | <annevk> | Domenic_: yeah, a hint of sorts that you're working on something seems helpful though |
| 16:15 | <marcosc> | Having multiple specs published will be confusing |
| 16:15 | <marcosc> | I'm happy to block the other one if need be |
| 16:16 | <Domenic_> | kk awesome thanks guys. will reply tonight. |
| 16:25 | <Hixie> | i love that a bug not having any activity since it was filed is an argument for closing it |
| 16:31 | <Hixie> | cabanier: your most recent e-mail is again lacking in reasons. Any time you write "I think" or "We should" you need to add "because..." or "as shown by..." explaining your reasons, otherwise the feedback just gets dismissed as not having any rationale. |
| 16:32 | <Ms2ger> | That sounds better in the active mood |
| 16:32 | <Ms2ger> | ... otherwise I just dismiss the feedback as ... |
| 16:33 | <cabanier> | Hixie: why am I held to a different standard? |
| 16:33 | <Hixie> | well it's not necessarily me, the same would apply to any other whatwg spec |
| 16:33 | <Hixie> | cabanier: you're not |
| 16:33 | <Hixie> | cabanier: you're just particularly bad at giving rationale |
| 16:33 | <Hixie> | cabanier: yet give a lot of feedback |
| 16:34 | <cabanier> | Hixie: I'm stating how stroking is done. If this was the first email, I'd agree but we've been going back and forth |
| 16:35 | <cabanier> | Hixie: Isn't the whatwg spec supposed to reflect what browser do? |
| 16:35 | <cabanier> | Hixie: I'm not proposing anything new |
| 16:35 | <Hixie> | your most recent e-mail did not provide ay argument showing that what the spec says differs from what browsers do |
| 16:35 | <Hixie> | as far as i'm aware, i've already fixed the spec to match what browsers do on every test people have shown a difference on |
| 16:36 | <cabanier> | Hixie: OK. I will recheck |
| 16:37 | <cabanier> | Hixie: it would be better if the spec describes what actually happens in case there are weird side effects |
| 16:38 | <Hixie> | that begs the question of in what way it doesn't currently describe what actually happens. |
| 16:38 | <cabanier> | Hixie: I find the current spec very hard to read |
| 16:38 | <Hixie> | (woot, i got to use "begs the question" the way the pedants always want it to be used) |
| 16:39 | <TabAtkins> | I've given up on that, and just resolved to use the older "beggars the question" for the "proper" meaning. |
| 16:39 | <cabanier> | :-) |
| 16:39 | <Hixie> | cabanier: if the problem is just that it's hard to read, that's an entirely different argument than "Isn't the whatwg spec supposed to reflect what browser do?" |
| 16:39 | <Hixie> | cabanier: hence why it's important to describe your actual problems and reasons and arguments and data |
| 16:39 | <cabanier> | ok |
| 16:40 | <cabanier> | Hixie: we did settle on the dashing, correct? |
| 16:40 | <cabanier> | Hixie: by breaking dashing out, the current spec will already get more readable |
| 16:40 | <Hixie> | cabanier: if it's hard to read, then the thing to do is to walk through the spec and show, quoting each statement in the spec, where you are finding it hard to read, what terms are confusing, etc. |
| 16:41 | <Hixie> | cabanier: the way i did e.g. here: http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Oct/0345.html |
| 16:47 | <annevk> | kinda wish DOM was in WHATWG as well in W3C Bugzilla, would be easier when moving things around |
| 16:47 | <Hixie> | you could move the product over |
| 16:48 | <Hixie> | since it's a WHATWG spec now anyway |
| 16:48 | <Hixie> | or create a new component and move the bugs over |
| 16:50 | <annevk> | haha http://nodejsreactions.tumblr.com/ |
| 16:50 | <annevk> | Hixie: yeah, been thinking about doing just that |
| 16:51 | <dglazkov> | good morning, Whatwg! |
| 16:52 | <annevk> | oops |
| 16:52 | <annevk> | forgot to actually serialize the origin |
| 17:04 | <Domenic_> | annevk: GitHub issues FTW? |
| 17:05 | <annevk> | Domenic_: I'm still kinda conservative with respect to that... |
| 17:05 | <annevk> | Domenic_: Bugzilla has some nice properties such as mailing list integration and being able to move issues between specifications |
| 17:05 | <annevk> | Domenic_: but maybe at some point I'll start doing that instead |
| 17:05 | <Domenic_> | annevk: I've drunk the coolaid... but yes, I see how those could be useful properties. |
| 17:06 | <Domenic_> | annevk: what do you mean mailing list integration? |
| 17:06 | <annevk> | I could give it a go maybe for the Notifications API |
| 17:06 | <Ms2ger> | Github issues are pretty terrible |
| 17:06 | <annevk> | Domenic_: just that emails go to the mailing list if someone opens a new issue or one is resolved |
| 17:06 | <annevk> | Ms2ger: not useful |
| 17:07 | <Ms2ger> | Sure, not useful either ;) |
| 17:07 | <Domenic_> | annevk: ah OK. Yeah I guess you could hack it by creating a GitHub user for that mailing list and having him watch the repo, but, meh. |
| 17:07 | <gsnedders> | It's so plainly obviously fucked up when "working to contracted hours" is sufficient to be considered practically a strike. |
| 17:07 | <Domenic_> | annevk: on the other hand most devs are much happier with teh GitHub interface than the mailing list interface. |
| 17:08 | <gsnedders> | (Universiy teaching staff, in the UK) |
| 17:08 | <annevk> | Domenic_: yeah, seems like you might get some kind of involvement that is lacking now |
| 17:08 | <jgraham> | annevk: Ms2ger is right though, they are |
| 17:09 | <Ms2ger> | (For once) |
| 17:10 | <annevk> | jgraham: not useful |
| 17:11 | <Ms2ger> | annevk, itym "please elaborate" |
| 17:11 | <annevk> | itym? |
| 17:12 | <jgraham> | annevk: Well it's pretty annoying that the rallying cry is "GitHub all the things" when GitHub isn't obviously a win |
| 17:13 | <annevk> | jgraham: given that everyone and their dog is on GH you really have to say something more coherent than that |
| 17:13 | <jgraham> | Everyone and their dog is on twitter too, but it doesn't make it a good medium for spec development |
| 17:13 | <jgraham> | So you'll need a better argument than "look at all the people" |
| 17:14 | <jgraham> | I don't have a problem with hosting specs on github |
| 17:16 | <jgraham> | But I think that the issue tracker sucks compared to almost all other issue trackers |
| 17:16 | <Domenic_> | It depends on what features you want |
| 17:16 | <Domenic_> | It definitely has holes |
| 17:16 | <annevk> | Well Domenic_ gave his argument. Developers are familiar with doing development on GH. Specifications are already on GH. We could move a larger part of that development there, to more closely involve everyone following the specification there. |
| 17:16 | <Domenic_> | But those holes don't impact my use cases |
| 17:16 | <jgraham> | And there is a tendecy to ghettoise because you have to actively know about the spec and subscribe to a huge firehose of notifications |
| 17:17 | <annevk> | public-webapps⊙wo is a similar firehose though... |
| 17:17 | <annevk> | And less focused. |
| 17:17 | <Domenic_> | Whereas its ergonomics are *way* better, in terms of ecosystem integration, Markdown support, lightweight tags and milestones, a sane notification interface, ... |
| 17:18 | <jgraham> | I really don't consider the GH notification system to be a "feature" |
| 17:18 | <Domenic_> | It's definitely a value judgement though, whether you prefer the features of other issue trackers over the ones GitHub provides (including the community involvement it brings). |
| 17:18 | <Domenic_> | I really like them. Nice to get them bucketed. |
| 17:18 | <jgraham> | And I don't think that merely being on GitHub brings community involvement |
| 17:19 | <Domenic_> | Obviously not. It just lowers the barrier to both entry and continued participation. |
| 17:19 | <jgraham> | Really? |
| 17:19 | <umgrosscol> | Yeah. You can just git it. |
| 17:20 | <annevk> | jgraham: yes, you don't have to create a Bugzilla account |
| 17:20 | <annevk> | jgraham: or subscribe to a mailing list |
| 17:20 | <umgrosscol> | Single link to the project, and it makes contributing pretty easy. |
| 17:20 | <jgraham> | For example, a lot of the feedback on specs is from a mail to a mailing list that someone who might previously have been unaware of the spec can respond to intelligently based on their knowledge of the web platform |
| 17:20 | <jgraham> | But with github you have to know that the repo exists |
| 17:21 | <Domenic_> | the mailing list <-> spec correspondence is insanely arcane |
| 17:21 | <TabAtkins> | That's my big problem with doing things solely on github, too - the fact that you have to magically know that a given repo exists. |
| 17:21 | <Domenic_> | and the archives are not easy to interface with |
| 17:21 | <Domenic_> | as for the repo's existence, i find organizations can be quite helpful with that. i like browsing through github.com/whatwg and such. |
| 17:21 | <Domenic_> | but I am not sure even where I would browse on the W3C's site to find all the specs under development? |
| 17:21 | <TabAtkins> | The archives aren't *great*, but I've repeatedly stumbled on spec repos only *well after* they've started making progress, when someone mentions the repo on a mailing list. |
| 17:21 | <Domenic_> | last time I did that I found a bunch of XHTML2 stuff. |
| 17:21 | <jgraham> | I don't generally spend my time browsing for repos that might exist |
| 17:22 | <jgraham> | and if I did I wouldn't know where to start on githib. Your personal account? |
| 17:22 | <jgraham> | Some specific organisation for a single project/spec? |
| 17:22 | <Domenic_> | I guess I don't understand why this problem is unique to GitHub vs. to wherever the WHATWG or W3C hosts their specs? |
| 17:23 | <Domenic_> | Mailing list lurkers need to be made aware of a new mailing list/spec URL somehow. |
| 17:23 | <Domenic_> | whether that URL starts with github.com or not doesn't seem to make things more or less easy to find. |
| 17:23 | <jgraham> | The WHATWG only has one mailing list. TC39 has one mailing list. The W3C has a few relevant ones broadly split up by area |
| 17:23 | <TabAtkins> | *Anyone* talking about the spec on a mailing list alerts all the lurkers. Anyone talking about the spec in a github issue alerts no one that isn't already following the spec. |
| 17:24 | <jgraham> | And as I said before it's not the actual hosting that's the problem |
| 17:24 | <Domenic_> | Ah so you appreciate the constant reminders of a spec's existence that come from conflating its issue tracking into the general whatwg mailing list. |
| 17:24 | <jgraham> | For example it would be an improvement if Hixie hosted HTML on GH. But it would be much worse if he moved discussion to there |
| 17:24 | <TabAtkins> | Domenic_: Basically, yeah. |
| 17:24 | <TabAtkins> | What jgraham just said, too. |
| 17:25 | <TabAtkins> | Domenic_: It's just a social issue, unfortunately. If you're not already looped into the right cliques, GH is much harder to follow. |
| 17:25 | <Hixie> | jgraham: there's a github repo that mirrors the svn repo, fwiw |
| 17:25 | <Hixie> | foolip maintains it |
| 17:25 | <jgraham> | Hixie: I know that :) |
| 17:25 | <Hixie> | k |
| 17:26 | <Domenic_> | TabAtkins: and I guess the argument is that getting looped into a single whatwg mailing list is easier than getting looped into the right GH cliques? makes sense i guess. |
| 17:26 | <Domenic_> | If this is a real issue though it's easy to solve, by making a whatwg user that watches all under-development specs. |
| 17:26 | <TabAtkins> | Yeah, one is a single point, easily communicated or stumbled upon. The latter is a mishmash of social circles. |
| 17:26 | <TabAtkins> | Domenic_: Solve it first, then ask to switch. ^_^ |
| 17:26 | <TabAtkins> | Don't deprecate the existing solution while the new solution isn't finished yet. |
| 17:27 | <Domenic_> | TabAtkins: seems doable. Just never realizde that people wanted that feature. |
| 17:28 | <Domenic_> | Maybe if annevk moves notifications to GH he can set up that watched-by whatwg⊙wo association as a good test. |
| 17:28 | <TabAtkins> | Does that spam the mailing list with every commit? |
| 17:28 | <Domenic_> | no just issues |
| 17:28 | jgraham | thinks that will just fragment the discussion |
| 17:28 | <TabAtkins> | New issues, or every comment to an issue? |
| 17:29 | <Domenic_> | both |
| 17:29 | <TabAtkins> | Hm, okay. |
| 17:29 | <Domenic_> | you've used GitHub before right? And gotten emails from it for projects you're watching? |
| 17:29 | <TabAtkins> | Yeah. |
| 17:29 | <Domenic_> | yeah should be just like that. |
| 17:29 | <umgrosscol> | They get nicely sorted by gmail, if you use that. |
| 17:30 | <TabAtkins> | Just making sure it's not leaning too far into the spam territory. Mailing lists, while noisy, at least have humans behind the wheel that prevent accidentally sending 500 unique messages in a few minutes. |
| 17:30 | <Domenic_> | nice feature: if people stay inside their mail clients and reply, the reply gets into the issue tracker just fine, but the conversation can continue by email. I guess this is just a parity-bugzilla feature though tbh. |
| 17:30 | <jgraham> | But you couldn't reply to a mail from GH, address it to whatwg@ and have it show up in GH. So you need to be super-careful about how you reply |
| 17:30 | <jgraham> | Otherwise people will miss stuff |
| 17:30 | <Domenic_> | Right, but I mean, that's the same thing as how bugzilla spams mailing lists. |
| 17:31 | <Domenic_> | jgraham: indeed if you change the "To" header it'll not show up. |
| 17:31 | <Domenic_> | jgraham: seems the same as bugzilla I assume? |
| 17:31 | <jgraham> | Yeah, the bugzilla integration with mailing lists has also not been great :| |
| 17:32 | jgraham | has always got all commits and issues when he subscribed to a GH repo |
| 17:32 | <jgraham> | And all other random things too |
| 17:32 | <annevk> | We could set up whatwg-issues maybe |
| 17:32 | <annevk> | Or whatwg-gh |
| 17:34 | <annevk> | And we can set up email preferences to be sane |
| 17:34 | <annevk> | MikeSmith: maybe we can get public-whatwg-github⊙wo or some such? |
| 17:34 | <annevk> | Hixie: or would you prefer this to be on whatwg⊙wo? |
| 17:35 | <annevk> | TabAtkins: jgraham: Domenic_: ^^ |
| 17:35 | <Hixie> | what's the problem we're trying to solve here? |
| 17:36 | <Domenic_> | I believe: Tab likes having one mailing list to subscribe to in order to get ambient notifications about all new and ongoing spec activity. |
| 17:36 | jgraham | wonders where this setting is to only get issue comments and not other types of notifications |
| 17:36 | <TabAtkins> | More specifically: Moving spec dev to GitHub and using GitHub Issues to track issues has a number of benefits over using mailing lists, but you lose the ambient notification quality of MLs. |
| 17:37 | <jgraham> | As far as I can tell the level of granularity is "single issues" or "everything" |
| 17:37 | <Hixie> | imho we should stick to a minimum number of mechanisms |
| 17:37 | <jgraham> | But I will be very happy if I am wrong |
| 17:37 | <Hixie> | a mailing list, a bug system |
| 17:37 | <Hixie> | we have too many of both already |
| 17:37 | <TabAtkins> | I'm hoping there's a way to get "all issues, no commits". |
| 17:38 | <annevk> | Hixie: make it easier for everyone on GH to give feedback and get involved in spec development |
| 17:39 | <annevk> | Hixie: we use GH issues for javascript.spec.whatwg.org at the moment |
| 17:39 | <Domenic_> | TabAtkins: jgraham: I've never found the ability to get notifications on all commits (unless someone tagged me in them); would actually love to be able to turn that on in some cases. |
| 17:39 | <Hixie> | easier than what? right now contributing to HTML just involves loading the spec, typing in a box, and hitting enter |
| 17:39 | <Hixie> | there's a point below which making it easier to participate starts making it too easy for us to get spammed or receive junk feedback... |
| 17:39 | <Hixie> | (that point might be the form on the w3 TR/ page, i get a ton of nonsense feedback through those forms) |
| 17:40 | <annevk> | Hixie: that's one-off feedback which doesn't really give good ways for follow ups |
| 17:40 | <Hixie> | plenty of people cc themselves on those bugs |
| 17:40 | <Hixie> | or leave their e-mail address |
| 17:40 | <Hixie> | (though in my experience they rarely respond to e-mails when i follow up with them directly) |
| 17:41 | <jgraham> | Domenic_: Hmm, maybe you are right. It might be that I was thinking of repos that have noisy bots adding comments for each commit |
| 17:43 | <annevk> | Lol, some guy on Twitter suggests DRM should be in WHATWG instead. Not very good at reading tea leaves it seems... |
| 17:43 | <Domenic_> | O_____o |
| 17:43 | <gsnedders> | annevk: Hey, it would all be okay if it were! |
| 17:43 | <gsnedders> | The WHATWG design better stuff! |
| 17:43 | <jgraham> | (so it's still all-or-nothing for notifications, which is generally very annoying, but might be OK for this use case) |
| 17:43 | <Hixie> | DRM in the WHATWG would be a very short spec |
| 17:44 | <TabAtkins> | "No" |
| 17:45 | <jgraham> | We could give them the spec encrypted, and explain that we don't trust them not to use it in a way that breaks various laws related to reverse engineering, fair use, etc. |
| 17:46 | <jgraham> | *that doesn't break |
| 17:46 | jgraham | gives up |
| 17:47 | <annevk> | Hixie: So I agree that generally I want fewer ways of doing something. It's just not completely clear to me the current GitHub / Bugzilla / Email setup is the best. Making it GitHub / Email seems like we'd have less in the end and less things to learn. |
| 17:47 | <annevk> | Hixie: there's a transition cost of course. |
| 17:48 | <jgraham> | (just because someone will say this: it would also mean that we had a greater dependence on third-party infrastructure) |
| 17:49 | <Ms2ger> | Third party to the W3C? ;) |
| 17:50 | <Hixie> | annevk: github is the one from that pile that i would most quickly dispose of :-) |
| 17:51 | <Ms2ger> | Hixie++ |
| 17:51 | <Hixie> | i know it's all the rage today, but so was code.google.com before that, and sourceforge before that, and most developers don't use any of these |
| 17:52 | <Hixie> | optimising for "developers who use github" is short-sighted imho |
| 17:53 | <Hixie> | not saying there's anything _wrong_ with github |
| 17:53 | <Hixie> | and using it is fine |
| 17:53 | <Hixie> | just, we should be careful not to assume it's The One True Way |
| 17:53 | <Hixie> | mailing lists and bugzilla might not be the current fashion, but they're proven technologies that are highly mature and have been used for literally decades |
| 17:54 | <Hixie> | (ok, 1.something decades in bugzilla's case) |
| 17:54 | <jgraham> | I don't think that code.google.com was ever all the rage :) But I think there is substance to the general point |
| 17:54 | <Hixie> | it was all the rage enough that we hosted a bunch of stuff on it before transitioning to github |
| 17:54 | <jgraham> | That is true |
| 17:54 | <Domenic_> | I don't think anyone's claiming GH is The One True Way. Just that it has advantages worth pursuing. |
| 17:55 | <Hixie> | what are those advantages? |
| 17:55 | <annevk> | And in fact, the current proposal was to have a mailing list backup of everything going on GitHub. |
| 17:55 | <Ms2ger> | "It's github" |
| 17:55 | <annevk> | Hixie: familiar to part of our target audience |
| 17:56 | <Hixie> | lots of things are familiar to part of our target audience |
| 17:56 | <Hixie> | if we're going by that, we should probably move all development to a facebook group |
| 17:58 | <annevk> | I wonder how you end up there |
| 17:58 | <annevk> | I don't know anyone who uses FB for development other than FB engineers |
| 17:58 | <Ms2ger> | More of our target audience are on facebook than on github? |
| 17:58 | <TabAtkins> | Because Hixie likes reductio ad adbsurdum? |
| 17:58 | <marcosc> | It might be best to think about this in terms of the people we want to participate in the spec development process at particular stages. Like Service Workers was a closed group of folks working on stuff first stuff... then opened up a bit to more folks on GH. Eventually, dev of that spec will likely move to a mailing list or continue on GH. |
| 17:59 | <Ms2ger> | marcosc, that's a pretty good point against gh |
| 17:59 | <marcosc> | it might be... that's not the point tho. I'm just saying that it's about finding what is best for people to collaborate on stuff |
| 17:59 | <annevk> | Yes, because us not using GH issues will totally prevent that from happening. Oh wait it didn't Ms2ger... |
| 17:59 | <Hixie> | the way Service Workers has been developed is a case study in how now to do things |
| 18:00 | <Hixie> | how not to do things |
| 18:00 | <marcosc> | now or not? |
| 18:00 | <Ms2ger> | Not |
| 18:00 | <marcosc> | Hixie, why is that? |
| 18:00 | <annevk> | (Not that I think doing development in private is ever a good idea, but it seems unrelated.) |
| 18:01 | <Hixie> | marcosc: because it was designed in a silo without seeking feedback from people who are likely to disagree with the design |
| 18:02 | <Hixie> | marcosc: it's the best way to end up with a tech that doesn't take off |
| 18:02 | <Ms2ger> | In any case, it seems that gh issues make it impossible to receive a different amount of email than everything or nothing |
| 18:02 | <jgraham> | Can we pretend that service workers wan't mentioned? I think that's a path we don't want to go down |
| 18:02 | <TabAtkins> | Ms2ger: I don't understand that objection. Mailing lists give you everything. |
| 18:02 | <Ms2ger> | What? |
| 18:02 | <TabAtkins> | Unless you meant "also commit messages" by "everything"? |
| 18:02 | <Hixie> | i really don't understand what we're trying to solve here. |
| 18:03 | <Ms2ger> | I don't want everything |
| 18:03 | <Ms2ger> | I also don't want nothing |
| 18:03 | <TabAtkins> | I don't know what you mean by "everything". |
| 18:03 | <Ms2ger> | All comments ever |
| 18:03 | <TabAtkins> | I want every issue and comment. That's precisely what I get today on mailing lists. |
| 18:03 | <Ms2ger> | I don't! |
| 18:03 | <Ms2ger> | But gh issues supports your preference, not mine |
| 18:03 | <TabAtkins> | Then you're screwed in all cases, I guess? |
| 18:03 | <jgraham> | Hixie: So, in the spirit of trying to argue both sides, I think that the high level goal is to get more people who are web technology users but aren't browser engineers to give feedback on specs |
| 18:04 | <Ms2ger> | Not with bugzilla |
| 18:04 | <Hixie> | jgraham: ok, that seems like a solid goal. |
| 18:11 | <Hixie> | walk me through what you think it would look like to file feedback on github, for the reviewer and the editor. i'm nothing if not willing to be convinced. :-) |
| 18:11 | <Ms2ger> | Plausibly more people know how to do it / have an account on github vs the w3c bugzilla |
| 18:11 | <jgraham> | Right, but we are assuming as an axiom that there exists a large population of users who are comfortable with that kind of thing on GH but not bugzilla |
| 18:12 | <jgraham> | I *also* assume that there is a class of bugs that don't work well with the inout widget in the spec |
| 18:12 | <Ms2ger> | A way to subscribe to bugs without having to deal with bugzilla somehow might be interesting |
| 18:12 | <jgraham> | Things like "this whole design sucks" |
| 18:13 | <jgraham> | Which might need to be longer than one text input |
| 18:13 | <jgraham> | And that is also a kind of feedback we would like |
| 18:13 | <Hixie> | well for that kind of feedback you really need a mailing list |
| 18:13 | Hixie | hasn't been impressed by github for _any_ kind of feedback |
| 18:14 | <marcosc> | I guess fixing Bugzilla so people can log in with Twitter, GH, or even FB might help? |
| 18:14 | <jgraham> | So I think the idea here is that the spec would have a home on gh like github.com/whatwg/brain-transfer |
| 18:14 | <jgraham> | And the issue tracker would be enabled |
| 18:15 | <jgraham> | But all issue notifications would *also* be sent to the mailing list |
| 18:16 | <jgraham> | So people could write their long issue on GH and just subscribe to that issue |
| 18:16 | <jgraham> | Or they could subscribe to all notifications just for that spec |
| 18:16 | <jgraham> | Or they could get notifications for all specs |
| 18:16 | <Hixie> | this would be a separate list? like whatwg-commits? |
| 18:17 | <jgraham> | It could be, but I guess then only zcorpan would subscribe and it would be rather pointless |
| 18:17 | <jgraham> | IMHO, anything we do is a failure if it doesn't pass the "bz test" |
| 18:17 | <jgraham> | Which is more or less what it sounds like |
| 18:18 | <Ms2ger> | Bugzilla or Boris? |
| 18:18 | <jgraham> | Boris |
| 18:18 | <jgraham> | i.e. given some discussion happening, will someone who engages in the way that bz does see the discussion |
| 18:18 | <jgraham> | And have the chance to comment on it |
| 18:19 | <marcosc> | how does bz engage that is differently from other people? |
| 18:19 | <jgraham> | I don't know |
| 18:19 | <jgraham> | But he is very good at providing "ambient" feedback |
| 18:19 | <Hixie> | i really don't get why mailing lists are so hard here |
| 18:20 | <Hixie> | but ok |
| 18:20 | <Ms2ger> | People don't like mailing lists much ;) |
| 18:20 | <marcosc> | email sucks |
| 18:20 | <jgraham> | Well I also don't think that mailing lists are hard, obviously |
| 18:20 | <Ms2ger> | It's only better than all the alternatives |
| 18:20 | <Ms2ger> | jgraham, you're pretty literally a rocket scientist, though |
| 18:20 | <marcosc> | some people just seem to have more meaningful interactions on things like GH issues |
| 18:20 | <Ms2ger> | (Except maybe nntp) |
| 18:21 | <jgraham> | Really? |
| 18:21 | <jgraham> | marcosc: ^ |
| 18:21 | <cabanier> | Hixie: didn't you have a jsfiddle-like site? Should I use that to post samples? |
| 18:21 | <Ms2ger> | bit.ly/livedom |
| 18:21 | <jgraham> | Some distressingly high fraction of GH issue comments are inane comments |
| 18:21 | <cabanier> | Hixie: codepend and jsfiddle are not permanent |
| 18:21 | <jgraham> | s/comments/graphics/ |
| 18:22 | <cabanier> | Ms2ger: is that permanent? |
| 18:22 | <Ms2ger> | cabanier, permanent how? |
| 18:22 | <jgraham> | One *big* disadvantage of this kind of proposal is that it will make it much harder to exert the kind of etiquette controls that you can on a mailing list |
| 18:23 | <cabanier> | Ms2ger: If I create it and link to it from a message, will it ever be deleted? |
| 18:23 | <jgraham> | cabanier: It comes with a real long URL |
| 18:23 | <jgraham> | Just use that |
| 18:24 | <marcosc> | jgraham: sure. It's the point I was trying to make earlier. Depending on the group: some people like mailing lists, other people like GH issues, other like other things or a combination. |
| 18:25 | <marcosc> | jgraham: the inane comments just serve as a replacement for IRC |
| 18:25 | <jgraham> | IRC doesn't go to my inbox |
| 18:26 | <Ms2ger> | I can fix that |
| 18:26 | <marcosc> | heh |
| 18:27 | <Ms2ger> | One email per line, you say? |
| 18:27 | <marcosc> | Ms2ger: he particularly needs to know when people join and leave the channel |
| 18:28 | <Ms2ger> | Ouch |
| 18:28 | <Ms2ger> | Even *I* wouldn't be that cruel |
| 18:35 | <Hixie> | jgraham: well my experience with w3c lists is we _definitely_ don't want bugzilla bugs forwarding to a mailing list with discussion. that's a recipe for driving people away. |
| 18:35 | <Hixie> | jgraham: but anyway |
| 18:35 | <Hixie> | if people want to try using github as a source of issues, i'm all for y'all trying |
| 18:38 | <jgraham> | FWIW the webapps solution where the new bug notification comes to the list is an OK compromise |
| 18:38 | <jgraham> | But you can't do that with GH (unless you build a custom thing using the API) |
| 18:39 | <Hixie> | i don't read web-apps anymore in part because of that, fwiw |
| 18:39 | <jgraham> | Heh |
| 18:39 | <jgraham> | You probably use the bug tracker as a bug tracker more than most people though |
| 18:39 | <annevk> | Hixie: so you're okay with missing out on what issues are filed and what's decided on in Bugzilla? |
| 18:40 | <jgraham> | So one compromise solution (which might just combine the worst parts of all worlds) |
| 18:40 | <jgraham> | Is that you build a special thing that uses the GH API |
| 18:41 | <jgraham> | And sends one email per issue to the main list, with a single click link to opt in to getting more mail for that issue |
| 18:42 | <jgraham> | Bonus points if it deletes messages containing graphics with prejudice |
| 18:42 | <jgraham> | s/messages/comments/ |
| 18:42 | <Hixie> | annevk: there is zero way i can keep track of everything that's going on on every web spec |
| 18:42 | <Hixie> | annevk: i trust the editors to take feedback into account and do the right thing |
| 18:42 | <Hixie> | annevk: and for them to cc me when they think i might have a relevant opinion |
| 18:43 | <Hixie> | (i can barely keep track of the stuff that affects the spec i edit, heh) |
| 18:45 | <Ms2ger> | You can? |
| 18:46 | <annevk> | Seems fair. Open bugs are still accessible via the standard... Might be transparent enough although not super useful towards newcomers with knowledge about a particular subject. |
| 18:46 | <Ms2ger> | jgraham, no tests/non-functional dir in wptserve? |
| 18:46 | <jgraham> | Ms2ger: All my tests function! |
| 18:47 | <jgraham> | But in this case the atonym of "functional" would be "unit". And indeed there are no unit tets. |
| 18:47 | <Ms2ger> | jgraham, I see |
| 18:47 | <annevk> | It happens quite often that people I had not thought of ask about some issue (in a way that suggests they've done a bunch of work) that's been long on file. Always feels like a waste of time for them. |
| 18:48 | <Hixie> | annevk: how do you mean? |
| 18:49 | <Ms2ger> | jgraham, does docs/makefile come from somewhere? |
| 18:49 | <jgraham> | Ms2ger: Sphinx |
| 18:49 | <annevk> | Hixie: e.g. someone will do some research around something incompatible they've found only to realize it's already been done before one I point towards the bug |
| 18:49 | <jgraham> | Ms2ger: I would never write a Makefile :) |
| 18:49 | jgraham | is not MikeSmith |
| 18:49 | <Ms2ger> | Heh |
| 18:49 | <annevk> | once* |
| 18:49 | <Ms2ger> | They're not too terrible for small things |
| 18:50 | <Hixie> | annevk: ah, yeah. making the bugs more visible in the spec would help with that, but we already don't expose e.g. the mailing list feedbac in that manner. |
| 18:51 | <Hixie> | annevk: (i don't see how github issues would make this any better, though maybe you're not saying it would) |
| 18:52 | <annevk> | I'm not saying GH would make this better. This is separate. |
| 18:52 | <Ms2ger> | jgraham, is the output of the docs somewhere? |
| 18:53 | <Hixie> | annevk: k |
| 18:54 | <jgraham> | Ms2ger: http://wptserve.readthedocs.org/en/latest/ |
| 18:55 | <Ms2ger> | Ta |
| 18:56 | <Ms2ger> | jgraham, hrm, is :: at the end of a line some special syntax? |
| 18:57 | <jgraham> | Ms2ger: Yeah |
| 18:57 | <jgraham> | ReST is kind of horrible |
| 18:58 | <jgraham> | http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#literal-blocks |
| 18:59 | <Ms2ger> | FAscinating |
| 19:01 | <Ms2ger> | jgraham, I'll assume you didn't write make.bat either ;) |
| 19:07 | <annevk> | zcorpan: https://github.com/w3c/web-platform-tests/pull/319#commits-pushed-fe71648 |
| 19:08 | <jgraham> | Ms2ger: That would be a good assumption :) |
| 19:09 | <jgraham> | annevk: It's OK zcorpan *reads* his critic email :) |
| 19:48 | <Ms2ger> | jgraham, is wptserve py3k-ready? |
| 19:56 | <Hixie> | anyone on non-mac around? i'm looking to see what http://www.hixie.ch/tests/adhoc/html/global-attributes/title/003.html does on non-mac browsers |
| 19:58 | <TabAtkins> | What exactly do you want me to report? |
| 20:05 | <Hixie> | reload it, look at the tooltip on the last one. what does it look like? (screenshot might be easiest) |
| 20:06 | <Hixie> | i'm trying to work out how many spaces the browsers are using as the replacement for 'tab' |
| 20:11 | <TabAtkins> | okay, sent |
| 20:12 | <Hixie> | thanks! |
| 20:17 | <Hixie> | TabAtkins: where did you send it? |
| 20:17 | <TabAtkins> | ian⊙hc |
| 20:17 | <Hixie> | k |
| 20:17 | Hixie | pokes his server |
| 20:18 | <jgraham> | Ms2ger: No |
| 20:22 | <Krinkle> | MikeSmith: Hi, I noticed you mentioned "ResourceLoader". |
| 20:22 | <Krinkle> | If you have any questions regarding the meta tag in Wikipedia's MediaWiki software, I can answer any :) |
| 20:27 | <Hixie> | TabAtkins: fwiw, still haven't gotten it :-( |
| 20:28 | <TabAtkins> | It's in my sent mail from 17 minutes ago. |
| 20:28 | <Hixie> | i have nothing from you since 10:50am |
| 20:29 | <Hixie> | aah, e-mail. |
| 20:30 | <Hixie> | i loe you so. |
| 20:30 | <Hixie> | love, even |
| 20:30 | <Hixie> | though "loathe" might be closer? |
| 20:30 | <Hixie> | TabAtkins: well in any case, https://www.w3.org/Bugs/Public/show_bug.cgi?id=22973 is the bug for that test, if you have anything to comment on it |
| 20:30 | <Hixie> | (mostly pasting that here so i can find it again when i do get your mail) |
| 20:43 | <TabAtkins> | Hixie: I just attached it to the bug. |
| 20:46 | <Hixie> | thanks |
| 20:56 | <Hixie> | TabAtkins: wohay, got your e-mail |
| 20:56 | <Hixie> | TabAtkins: my server must just have been taking the day off |
| 21:50 | <Hixie> | TabAtkins: what's the story on the 'content' property in CSS applying to elements, do you know?L |
| 21:50 | <Hixie> | -? |
| 21:50 | <Hixie> | er, +?, -L. |
| 21:50 | <TabAtkins> | The spec says to do it, it's just a matter of browsers actually doing so. |
| 21:51 | <Hixie> | do you know which spec it's in? |
| 21:51 | <TabAtkins> | Content |
| 21:51 | <Hixie> | thanks |
| 21:52 | <Hixie> | hm, is there a more up to date version than http://dev.w3.org/csswg/css-content/ ? that says it's dead. |
| 21:52 | <matjas> | afaik only old Opera (<= 12) implemented that |
| 21:52 | <matjas> | …unfortunately |
| 21:53 | <Hixie> | oh wow, parts of that still refer to my old 'move-to' idea |
| 21:53 | <TabAtkins> | Nah, I haven't taken the time to fix it up yet. |
| 21:53 | <Hixie> | k |
| 21:53 | <Hixie> | we're fast coming up on the date i said i'd actually resume work on that spec |
| 21:53 | <Hixie> | that's scary |
| 22:07 | <zcorpan> | Hixie: what date? |
| 22:12 | <Domenic_> | I still want ::before::before::before and ::after(5) and all that. That was a great spec. |
| 22:15 | <Hixie> | cabanier: i haven't changed the canvas stuff in at least a week... |
| 22:16 | <Hixie> | zcorpan: 2018, iirc |
| 22:16 | <Hixie> | Domenic_: that's a great example of what i come up with when i just brute-force my way to a solution and ignore design aesthetics. :-) |
| 22:20 | <Domenic_> | Hixie: oh man I didn't even notice the editor, awesome :D. |
| 22:22 | <Hixie> | i wish we'd come up with a good way to wrap siblings in a pesudo-element |
| 22:33 | <cabanier> | Hixie: you did it 2 weeks ago. "[giow] (3) Change how tracing a path works so that it's more similar …" |
| 22:34 | <cabanier> | Hixie: I didn't realize you changed the spec until I started reading it :-) |
| 22:37 | <crocket> | hi guys |
| 22:37 | <crocket> | Is HTML5 still a moving target? |
| 22:37 | <Hixie> | HTML5 is dead |
| 22:37 | <Hixie> | long live HTML! |
| 22:37 | <crocket> | Hixie : not funny |
| 22:37 | <Hixie> | no i mean that seriously |
| 22:37 | <Hixie> | we dropped the version number |
| 22:37 | <Hixie> | http://whatwg.org/html |
| 22:38 | <crocket> | Hixie : What about WC3? |
| 22:38 | <crocket> | Did WC3 also drop 5? |
| 22:38 | <Hixie> | the w3c forked html a while back and have kinda gone into the weeds |
| 22:38 | <crocket> | Hixie : Does it mean WC3 HTML is incompatible with WHATWG HTML? |
| 22:39 | <jgraham> | crocket: Browsers are a moving target |
| 22:39 | <jgraham> | crocket: But by, and large, the things that work today will continue to work tomorrow |
| 22:39 | <crocket> | jgornick: If HTML moves too, it's hard to get on the train. |
| 22:39 | <jgraham> | and that fact has nothing to do with the status of the spec |
| 22:39 | <crocket> | I want to get on the web bandwagon. |
| 22:40 | <crocket> | Is it a mistake to read an HTML5 book now? |
| 22:40 | <Hixie> | crocket: you'd have to ask them (whether there's is compatible with the trunk/whatwg version of html), because last i heard they weren't documenting their differences |
| 22:40 | <jgraham> | It's entirely a product of the fact that browsers that break sites are unpopular and so don't keep marketshare |
| 22:40 | <Hixie> | crocket: but the whatwg spec intends to remain compatible with browsers, fwiw |
| 22:40 | <jgraham> | So once a feature is used by enough sites, browsers can't change the way it works, whatever any spec says and however much they might want to |
| 22:40 | <crocket> | Will browser vendors keep up with WHATWG or WC3? |
| 22:41 | <Hixie> | crocket: whatwg will keep up with browser vendors |
| 22:41 | <crocket> | the hell? |
| 22:41 | <crocket> | Hixie : I feel frightened to start learning HTML. |
| 22:41 | <jgraham> | Developing web technologies isn't a top down process |
| 22:41 | <Hixie> | crocket: you may be suffering from the impression that standards are developed in isolation and browsers then do what the specs say |
| 22:42 | <Hixie> | crocket: what actually happens is that the browsers and the specs develop in tandem, and continually converge over time |
| 22:42 | <Hixie> | (at least, the whatwg specs converge, in theory. dunno about others.) |
| 22:42 | <crocket> | Hixie : So is it a mistake to learn HTML? |
| 22:42 | <Hixie> | crocket: nope |
| 22:42 | <Hixie> | crocket: HTML is a great technology to use if what you want to do is target the Web |
| 22:43 | <Hixie> | crocket: just like any other platform, it's in active development |
| 22:43 | <Hixie> | well, any other platform that's not dead |
| 22:43 | <crocket> | Without explicit version management, it's more confusing. |
| 22:43 | <Hixie> | why? |
| 22:43 | <crocket> | Hixie : Without version management, you always have to keep up with the master branch. |
| 22:43 | <Hixie> | the difference between the web and other platforms is that there's more than one implementation of the web |
| 22:44 | <Hixie> | crocket: no, because with html if something works, we don't break it |
| 22:44 | <crocket> | Hixie : Any HTML book you recommend? |
| 22:44 | <Hixie> | crocket: so web sites written in the 90s and not maintained since still work today, by and large |
| 22:45 | <Hixie> | (assuming they worked on more than one browser of the time, anyway) |
| 22:45 | <Hixie> | crocket: i'm not familiar with the books, sorry |
| 22:45 | <crocket> | Hixie : Did WC3 drop the version number, too? |
| 22:46 | <Hixie> | crocket: it's not clear what they're doing. they've got two versions of HTML with different numbers that are different from each other and that are both changing regularly. |
| 22:46 | <Hixie> | crocket: i would encourage you to ignore them :-) |
| 22:46 | <cabanier> | :-) |
| 22:46 | <crocket> | what the hell |
| 22:48 | <Hixie> | like i said, i'd encourage ignoring them |
| 22:48 | <Hixie> | they mostly just copy what we do anyway |
| 22:49 | <jsbell> | The phrase "reality-based spec writing" just got stuck in my head. |
| 22:51 | <TabAtkins> | Ugh, github's insistence on serving everything as text/plain is frustrating as hell, as it means I can't link to an SVG file that's just in the repo alongside everything else. |
| 22:51 | <Hixie> | crocket: you may find http://whatwg.org/faq interesting |
| 22:51 | <Hixie> | TabAtkins: it'd be a security wackamole for them to do anything else |
| 22:52 | <Hixie> | but yeah |
| 22:53 | <TabAtkins> | They serve things just fine if you put it on your gh-pages branch and link to it from [repo].github.io, though. |
| 22:53 | <Hixie> | ah, interesting |
| 22:53 | <Hixie> | well, that's cross-origin |
| 22:53 | <Hixie> | so that'd be ok |
| 22:54 | <Hixie> | i'm rapidly running out of words in the english vocabulary |
| 22:54 | <Hixie> | object. collection. bag. list. |
| 22:54 | <Hixie> | pile of things |
| 22:54 | <Hixie> | stack of widgets |
| 22:55 | <Hixie> | heap of thingymajimmies |
| 22:55 | <Hixie> | assemblage, haven't used that yet. |
| 22:55 | <jsbell> | TabAtkins: For non-production use, there's http://rawgithub.com/ |
| 22:55 | <Hixie> | (it's amusing how many words in the thesaurus under "collection" are terms of art by now) |
| 22:55 | <TabAtkins> | jsbell: Yeah, but I don't like using that in my project docs. |
| 22:56 | <TabAtkins> | But I guess whatever |
| 22:56 | <crocket> | yo |
| 23:00 | <Domenic_> | TabAtkins: you can just remove the dot from raw.github.com and it works. rawgithub.com is a proxy service that sets the right content type |
| 23:00 | <TabAtkins> | Domenic_: Yeah, I know, I've used it before. |
| 23:00 | <Domenic_> | oh whoops i was 5 minutes too late, that's what i get for not scrolling |
| 23:07 | <TabAtkins> | If anyone ever wanted to put railroad diagrams in their spec, a la CSS Syntax or JSON.org, Bikeshed now does that automatically. |
| 23:08 | <crocket> | Does anyone know a good HTML book? |
| 23:15 | <jsbell> | crocket: I don't think you'll get a good answer here. It's like wandering into the records room of a Boeing factory and asking for recommendations on learning to fly a plane. |
| 23:15 | <crocket> | jsbell: A funny analogy |
| 23:28 | <annevk> | TabAtkins: sounds like I should give it a try at some point |
| 23:29 | <annevk> | TabAtkins: make some railroads for URL and such |
| 23:29 | <Domenic_> | ooh that'd be cool |
| 23:29 | <TabAtkins> | Yeah, that'd be great. Railroads are so easy to read for simple constructions like that. |
| 23:30 | <Hixie> | mmm, railroads |
| 23:42 | <jgraham> | TabAtkins: Dammit, now we have lost Hixie for two months as he tries to invent a way to 3D-print model railway pieces from his web browser |
| 23:43 | <TabAtkins> | I accept no blame for this. |
| 23:45 | <jgraham> | Railroads. You mentioned railroads. You should know that's a bad idea |
| 23:45 | <Hixie> | teehee |
| 23:46 | <Hixie> | i can already 3d-print model railway pieces from my web browser |
| 23:46 | <Hixie> | it's called "shapeways.com" |
| 23:47 | <jgraham> | OK, crisis averted |