| 00:09 | <gsnedders> | SimonSapin: you don't have a WTF-8 impl in Python, do you? |
| 00:13 | <gsnedders> | SimonSapin: (I realise the Py2 UTF-8 codec is actually WTF-8) |
| 01:54 | <Manishearth> | annevk: around? |
| 02:04 | <gsnedders> | jgraham: https://github.com/html5lib/html5lib-tests/pull/52 ASAP plz |
| 04:48 | <SimonSapin> | I don't, only Rust |
| 04:51 | <SimonSapin> | gsnedders: ⬆ |
| 09:00 | <Ms2ger> | Github uses emoji now? |
| 09:06 | <Ms2ger> | hsivonen, thanks, and no worries about the delay :) |
| 09:14 | <annevk> | Manishearth: yup |
| 09:49 | <foolip> | zcorpan: what is serializeAsCDATA? Blink doesn't have it and neither does Gecko it seems |
| 09:51 | <zcorpan> | foolip: it's an attribute of Text that ms2ger specified in domparsing as part of trying to kill cdata sections in dom. mostly because glazou wanted his editor to continue to emit cdata sections aiui |
| 09:52 | <zcorpan> | not sure the dom should have that sort of thing for the sake of editors, but anyway |
| 10:05 | <annevk> | I don't think we should |
| 10:05 | <annevk> | Editors would want preservation of spaces between attributes, original order of attributes, etc. as well |
| 10:09 | <annevk> | JakeA: thanks for opening #566 |
| 10:35 | <foolip> | annevk: if you're curious, I prepared a CL seeing what it would take to purge CDATASection from Blink: https://codereview.chromium.org/739433003/ |
| 10:35 | <foolip> | but that also removes createCDATASection, so doesn't seem viable |
| 10:36 | <foolip> | so the XML parser and createCDATASection is the only source of these objects, as you suspected |
| 10:38 | <foolip> | my hunch is that the likeliest compat issue would be script that parse and then serialize XML and expect cdata to survive intact |
| 10:38 | <foolip> | which is a bit odd, of one considers cdata like a form of escaping like &bla; |
| 10:39 | <foolip> | if |
| 10:43 | <JakeA> | annevk: no worries. Would have done it sooner, but Chrome Dev Summit. |
| 10:49 | <darobin> | foolip: anyone expecting CDATA to roundtrip likely deserves to break; a lot of mainstream XML tools won't roundtrip it either |
| 10:49 | <foolip> | darobin: deserving or not isn't really relevant :) |
| 10:50 | <darobin> | foolip: I know, but the underlying idea is that it seems unlikely to be common to me :) |
| 10:50 | <foolip> | that would be very nice |
| 10:50 | <foolip> | I should probably add a use counter for serializing cdata |
| 10:54 | <zcorpan> | i can imagine polyglot stuff breaking <script> if cdata starts serializing as text. but i don't know if the browser is in that "toolchain" typically |
| 10:57 | <darobin> | zcorpan: I wouldn't expect the browser to be involved there, and anyway: polyglot |
| 10:58 | <zcorpan> | darobin: right |
| 10:58 | <zcorpan> | just first thing i could think of that would break |
| 10:58 | <zcorpan> | another is substring or regex match against innerHTML |
| 10:59 | <zcorpan> | something that had us use literal < and > when serializing attribute values |
| 10:59 | <darobin> | XML + innerHTML + CDATASection + regex? |
| 11:00 | <zcorpan> | yep |
| 11:00 | <darobin> | that's some seriously fucked up combo :) |
| 11:00 | zcorpan | points at topic :-) |
| 11:00 | <darobin> | I know, I know :) |
| 11:01 | <darobin> | still |
| 11:01 | <darobin> | there are things that would be worthy of a StabInTheFaceCounter |
| 11:14 | <Ms2ger> | I wouldn't expect polyglot and browsers to overlap at all :) |
| 11:33 | <hsivonen> | Ms2ger: you're welcome. I wish I had had more insightful comments to make. |
| 11:35 | <gsnedders> | I need to refactor stuff so I can publish my script to update expected failures for html5lib, I think. So many failing tests if I update… |
| 11:42 | <jgraham> | gsnedders: If you want review for your encoding tests I suggest you ask annevk |
| 11:42 | <jgraham> | They were wpt changes, right? |
| 11:43 | <gsnedders> | jgraham: no, html5lib-tests |
| 11:43 | <gsnedders> | jgraham: they're all about encoding detection in HTML |
| 11:44 | <gsnedders> | It just updates the labels to be what the primary form is in the Encoding spec by and large. |
| 11:45 | <jgraham> | gsnedders: Oh, in that case you should get annevk to review ;) |
| 11:47 | <gsnedders> | annevk: https://critic.hoppipolla.co.uk/r/592 |
| 11:48 | <gsnedders> | jgraham: also I realised we have multiple bits of metadata for scripted tests in the tree-construction tests |
| 11:48 | <gsnedders> | jgraham: which is pretty bad |
| 11:49 | <jgraham> | We do? |
| 11:49 | <gsnedders> | We have a scripted folder, and then there's the fact that I realised I really don't like Hixie's #script-on and #script-off sections, because they're really just flags. I'd rather have a #scripting section containing {any,enabled,disabled}. |
| 11:51 | <jgraham> | That seems like bikeshedding |
| 11:51 | <gsnedders> | Yeah, on the whole it is |
| 11:51 | <gsnedders> | But we should probably get rid of the scripted folder |
| 11:51 | <jgraham> | That makes more sense |
| 11:51 | <gsnedders> | Which we currently totally ignore in html5lib-python, despite implementing the scripting enabled case and not supporting scripting. |
| 11:52 | <gsnedders> | jgraham: also see the question in https://github.com/html5lib/html5lib-python/pull/174 |
| 11:53 | <annevk> | gsnedders: I'm not sure I follow the yahoo example |
| 11:54 | <annevk> | gsnedders: I guess I need more context |
| 11:54 | annevk | finds a way to get more context |
| 11:54 | <gsnedders> | annevk: more context in what way? |
| 11:54 | <gsnedders> | annevk: surrounding lines? |
| 11:54 | <annevk> | gsnedders: yeah, reviewed now |
| 11:55 | <gsnedders> | annevk: thx |
| 12:03 | <jgraham> | gsnedders: I thought there already was a system of escapes although I don't remember exactly what it covered |
| 12:10 | <gsnedders> | jgraham: no, there isn't; we have double-escaped stuff for the JSON tests |
| 12:12 | <Manishearth> | annevk: Filed an issue https://www.w3.org/Bugs/Public/show_bug.cgi?id=27414 |
| 12:16 | <annevk> | coolio |
| 13:22 | <zcorpan> | darobin: what should i do with <img> bugs filed in html wg? |
| 13:23 | <darobin> | zcorpan: you mean ones that you've closed? or something else? |
| 13:23 | <darobin> | in general? |
| 13:23 | <zcorpan> | darobin: new ones |
| 13:23 | <zcorpan> | darobin: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27393 |
| 13:24 | <darobin> | zcorpan: well, at the technical level, I would say "solve them" but I'm guessing that's not your question :) |
| 13:25 | <zcorpan> | darobin: do i move them or clone them to whatwg - html <img> |
| 13:25 | <zcorpan> | i guess i could leave them and put "<img>" in the summary |
| 13:25 | <darobin> | zcorpan: if the choice is move or clone I would say clone, but wouldn't it be best if this had its own component? |
| 13:26 | <darobin> | yeah, that wfm |
| 13:26 | <zcorpan> | darobin: it has its own component for the whatwg product |
| 13:26 | <darobin> | oh right |
| 13:27 | <darobin> | I meant across the board |
| 13:27 | darobin | kicks irccloud back together |
| 13:31 | <zcorpan> | darobin: i guess i'll clone to whatwg for now |
| 13:31 | <darobin> | zcorpan: if you prefer it that way, you're the one working on the stuff; but I'd rather we could figure out a way to avoid dupes |
| 13:32 | <zcorpan> | darobin: my preference is to move the bug :-) |
| 13:32 | <darobin> | heh |
| 13:32 | <darobin> | zcorpan: I'd be happy with that, but I know others won't be |
| 13:33 | <darobin> | even better: just use the GH tracker :) |
| 13:34 | <zcorpan> | we use GH but that doesn't make bugzilla go away |
| 15:07 | <annevk> | jgraham: what's the current best way to test an API that requires permission, such as notification? |
| 15:08 | <annevk> | jgraham: I would also want to test the getting permission part, to be clear |
| 15:09 | <Ms2ger> | Manual tests |
| 15:12 | <darobin> | I don't even think that can be automated with webdriver |
| 15:12 | <darobin> | (worth checking though) |
| 15:17 | <jgraham> | Yeah, it's tough. For individual browsers it may be possible to enable a mode where no permission prompt is given, but we don't have a generic solution |
| 15:18 | <jgraham> | Periodically people suggest some way to tackle this, but it quickly ends up at "standardise a debug-only api" |
| 15:18 | <jgraham> | and we haven't even got good at standardising shipping apis yet |
| 16:18 | <annevk> | I shared some pain points on www-archive: http://lists.w3.org/Archives/Public/www-archive/2014Nov/ |
| 16:20 | <rubys> | annevk: Thank you. I'm responding now. |
| 16:34 | <rubys> | Email sent: http://lists.w3.org/Archives/Public/www-archive/2014Nov/0044.html . Now I plan to go back to evaluating to what extent existing browsers match the URL setter behavior as specified by the URL Standard. |
| 16:35 | <annevk> | rubys: thanks, I might wait a bit before replying |
| 16:36 | <annevk> | rubys: to be clear, if you want to work on URLs and it stays under CC0, I think I'm okay with you exploring what you're suggesting |
| 16:37 | <annevk> | rubys: I'm not happy with such a situation since I prefer more clarity for implementers, but if you're putting in the (CC0) work that's worth something too |
| 16:37 | <annevk> | rubys: and as noted I have tried to get such a thing in the past, but the W3C refused (although Jeff conveniently forgot about it) |
| 16:43 | <arunranga> | annevk, if you add something like an instanceOf Error to body, I think we’re mostly done with https://www.w3.org/Bugs/Public/show_bug.cgi?id=24338 but I’d like to define some of how filesystem: URLs behave next. |
| 16:43 | <arunranga> | (which may bring up similar constraints, but filesystem URLs don’t get revoked; they just return network errors when the underlying resource goes way, so they *should* be simpler) |
| 16:47 | <annevk> | arunranga: shall I add an "error flag" to body for now? |
| 16:48 | <annevk> | arunranga: yeah, for filesystem URLs we mostly need to figure out how we want host-less relative URLs to work |
| 16:48 | <arunranga> | annevk, that’s sufficient; it depends on how much error you can eat, really. Do you care about type of error (better for DOMException). Do you care about messages? If not, flag is probably ok. |
| 16:49 | <annevk> | arunranga: I don't know |
| 16:49 | <arunranga> | annevk, then let’s start eating the bare minimum. A flag will do the trick. |
| 16:50 | <annevk> | sgtm |
| 16:51 | <arunranga> | annevk, right now, the filesystem URL generator function takes a File as an argument, and appends “path from root” to the scheme and host components. They’ll not really be relative. |
| 16:51 | <arunranga> | In fact, relative URLs (in the form of strings of the sort “../../foo.txt”) aren’t usable. |
| 16:52 | <annevk> | oh, I think we should try to make those work |
| 16:52 | <arunranga> | annevk, I’m not so sure actually |
| 16:52 | <Ms2ger> | // Opera tries to allocate a canvas with the given width and height, so |
| 16:52 | <Ms2ger> | // it OOMs when given excessive sizes, so cut out those checks. |
| 16:53 | <Ms2ger> | Can we kill that already? |
| 16:53 | <annevk> | arunranga: okay, I guess I need to study the proposal at some point |
| 16:53 | <annevk> | Ms2ger: not sure where that is from, but file a bug? |
| 16:53 | <arunranga> | annevk, I’ll also need to flesh it out some more before the Fetch part needs to be worried about. |
| 16:53 | <Ms2ger> | annevk, Aryeh's reflection tests |
| 16:53 | <annevk> | arunranga: yeah, though this is mostly URL parsing |
| 16:56 | <annevk> | arunranga: added an error flag |
| 17:05 | <BasicLogic> | Hi guys, I'm fairly new to this but want to start coding like it should be done, trying to get things straight.. Does someone has some advice where to start? |
| 17:06 | <BasicLogic> | *not new to coding but build my website with every working answer found on google, so it a big mess now |
| 17:11 | <BasicLogic> | Not the channel for such questions? sorry for the inconvenience ;) |
| 17:16 | <Ms2ger> | BasicLogic, not really |
| 17:16 | <Ms2ger> | BasicLogic, we can suggest reading the specification; MDN is often a good resource too |
| 17:22 | arunranga | looks at the flag on annevk’s new body (an admitedly strange sentence to type) |
| 17:22 | <arunranga> | OK, read operation will set the error flag |
| 17:23 | <annevk> | arunranga: and length/transmitted? |
| 17:23 | <arunranga> | annevk, yes. It seems that length should be set initially, and transmitted as bytes are pushed to body |
| 17:23 | <annevk> | arunranga: yup |
| 17:27 | <BasicLogic> | Ms2ger, reading the specification is what i'm doing right now ;). on w3school I got my most info but I see a lot of: Not supported in HTML5 descriptions |
| 17:27 | <rubys> | annevk: I'm back from lunch. Waiting before replying is completely understandable. From my perspective, you have identified valid issues that have to be worked on the W3C side. Whether I, too, fail to get the W3C to address them is yet to be determined. |
| 17:27 | <Ms2ger> | BasicLogic, I'd definitely advise against reading anything on w3schools :) |
| 17:28 | <BasicLogic> | Ms2ger, I noticed, that's why I started looking for something that has correct information |
| 17:29 | <Domenic> | wat http://www.w3fools.com/ is gutted |
| 17:29 | <rubys> | annevk: my one remaining concern is that you've (unnecessarily, in my opinion) stated these concerns as a road block to collaborating with the WHATWG: http://lists.w3.org/Archives/Public/www-archive/2014Nov/0029.html I'm going to continue to pursue this on the W3C side, but I would appreciate a bit more than "years ago, Jeff said something that I interpreted in this way". |
| 17:31 | <annevk> | rubys: well it would help to have a public statement from Jeff that IBM is not in violation of its private copy of the W3C Member Agreement (Jeff didn't actually say that in any reply as far as I could tell) |
| 17:31 | <rubys> | annevk: I'll work on getting that |
| 17:31 | <annevk> | rubys: and this is not just years ago, I spoke with Jeff and others from W3C management a year ago too |
| 17:31 | <annevk> | rubys: 2012 was just the first time this topic came up |
| 17:32 | <rubys> | annevk: hopefully we can tag team this issue and drive it to a successful conclusion. |
| 17:35 | <annevk> | rubys: I don't want to throw up roadblocks, but I rather avoid legal issues and given that the actual Member Agreement is private combined with what I'm told about it, this seems to be one |
| 17:36 | <Domenic> | Hixie: you should read https://www.w3.org/Bugs/Public/show_bug.cgi?id=27420 (not sure if adding you to CC is the best way) |
| 17:36 | <Domenic> | (it is about custom elements stuff) |
| 17:39 | <rubys> | annevk: cool. I'm going to continue to push on both sides: I'm going to encourage the W3C to go on record; and continue to push back that nothing in the Member Agreement seems to support your claim. Meanwhile, I'm proceeding slowly in terms of actual merging. |
| 17:40 | <annevk> | rubys: but we don't know the contents of the Member Agreement |
| 17:40 | <annevk> | rubys: what's published doesn't necessarily match what IBM signed |
| 17:40 | <annevk> | rubys: the W3C only hosts a draft |
| 17:41 | <rubys> | annevk: I'll note that that is equally true for the Opera and Mozilla Member Agreements. I sincerely doubt that I will get any traction with IBM legal to solve a non-problem. Particularly given that the only evidence provided is a disputed recollection. |
| 17:41 | <annevk> | rubys: (what I mentioned so it's unclear to me what you use for your claim) |
| 17:43 | <rubys> | Oh, and it is equally true for Apple, Google, and many others who participate at the WHATWG. |
| 17:43 | <rubys> | Given this, I think it is entirely unnecessary to single IBM out. |
| 17:44 | <annevk> | Domenic: you want to read https://www.w3.org/Bugs/Public/show_bug.cgi?id=20567 and https://www.w3.org/Bugs/Public/show_bug.cgi?id=25529 |
| 17:44 | <Domenic> | Sounds like I've stumbled into something fun. |
| 17:46 | <Domenic> | Ah hmm so the problem is we might want to delay clonedCallback but not delay the cloning steps for HTMLInputElement. |
| 17:47 | <annevk> | rubys: hmm, I suppose that's true; if a Mozillian contributes to XMLHttpRequest in the W3C, does that affect what I write elsewhere... bah |
| 17:47 | <annevk> | Domenic: perhaps, unless you can prove it'll work either way |
| 17:47 | <annevk> | Domenic: we have to delay the callbacks at least a bit btw |
| 17:47 | <annevk> | Domenic: otherwise it's mutation events all over again |
| 17:48 | <Domenic> | annevk: hmm unsure i see exactly why, but i imagine you're right. |
| 17:48 | <rubys> | annevk: that's the beauty of doing the work in the open. If the W3C and $employer know of the work and do not object, that will diminish their ability to make claims. |
| 17:49 | <annevk> | rubys: that they could make claims at all about such a situation is rather scary |
| 17:49 | <Domenic> | oh man employers can own everything |
| 17:50 | <annevk> | rubys: although I guess that depends on how the legal situation between me and Mozilla is |
| 17:50 | <Domenic> | my last employer owned everything i did in my free time, it was fun, i had to get documents signed for all my spec work. |
| 17:50 | <annevk> | which is rather good |
| 17:50 | <rubys> | annevk: advice, don't worry about it. Somebody who is not involved at all can claim to have a patent. Doing the work in public is the best strategy. |
| 17:51 | <annevk> | rubys: I'm mostly concerned with standards being in the public domain |
| 17:51 | <rubys> | Domenic: your last employer *claimed" to own everything you did in your free time, depending on the jurisdiction in which you worked, that claim may not be valid. |
| 17:51 | <Domenic> | in NYC I think it is :( |
| 17:51 | <Domenic> | In CA it is not |
| 17:52 | <rubys> | I've sometimes wondered what I signed >> in 1981 << when I joined IBM, and whether or not it anticipated the internet. |
| 17:52 | <annevk> | Domenic: e.g. a bunch of Range algorithms invoke clone |
| 17:53 | <Domenic> | rubys: haha |
| 17:53 | <annevk> | Domenic: if JavaScript could suddenly run while those algorithms run, there's definitely going to be crashes |
| 17:53 | <Domenic> | annevk: yeah that's a good clear example, thanks. |
| 17:53 | <annevk> | rubys: you never got a new contract? |
| 17:54 | <rubys> | no |
| 17:54 | <annevk> | wow, cool |
| 17:54 | <annevk> | At Opera there was some new paperwork every so often |
| 17:55 | <annevk> | Not long enough with Mozilla to know and my current legal setup is rather involved anyway since I'm not officially employed by them |
| 17:55 | <rubys> | Annually, I need to re-certify that I've read http://www.ibm.com/investor/governance/business-conduct-guidelines.html |
| 17:56 | <rubys> | mostly that covers topics like "don't bribe public officials" |
| 17:57 | <Domenic> | drat, there goes our best plan for getting Spain to adopt the URL Standard. |
| 17:57 | <rubys> | :-) |
| 17:59 | <rubys> | In any case, I do believe that having WebApps "sponsor" the URL Standard in the way I describe would go a long way to resolving IP concerns. |
| 18:02 | <rubys> | Dominic: did you see that I updated https://url.spec.whatwg.org/interop/browser-results/ ? |
| 18:07 | <Domenic> | rubys: yeah ... still confused ... e.g. many rows are red but there are no user agents with differences? |
| 18:08 | <rubys> | "Red means that there isn't consensus. I'm no longer showing which user agents differ." -- http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Nov/0142.html |
| 18:10 | <Domenic> | Oh I see. |
| 18:11 | <Domenic> | wtf firefox https://url.spec.whatwg.org/interop/browser-results/4ef836f0aa "# e" for .hash but #%20e in .href |
| 18:12 | <rubys> | Per the spec, percent encoding rules differ for different pieces. |
| 18:12 | <Domenic> | oh... |
| 18:12 | <rubys> | In this case, firefox actually is consistently percent encoding space characters. |
| 18:13 | <rubys> | Other's differ based on which property is being handled, and the spec matches the majority of implementations in this (rather peculiar) behavior. |
| 18:14 | Domenic | reminds himself of the topic again |
| 18:14 | <rubys> | lol |
| 18:15 | <rubys> | the situation is even more bizarre with setters (i.e., doing things like x = new URL('...'). x.hash = '...'). |
| 18:21 | <Hixie> | Domenic: wow, i didn't realise that the callbacks weren't just regular "virtual method" lookups |
| 18:49 | <Domenic> | Hixie: yeah, it surprised me quite a bit. |
| 18:51 | <Domenic> | dang, i searched for clone, should have searched for cloneNode. |
| 18:56 | <Hixie> | man, don't we have bigger fish to fry than whatever resulted in https://www.w3.org/Bugs/Public/show_bug.cgi?id=27408 ? |
| 18:56 | <Hixie> | if y'all are running out of things to spec, i've plenty to give you |
| 19:27 | <SimonSapin> | Anyone has a Unicode test suite lying around? Specifically for case folding, NFKD, NFD. (HTML requires "compatibility caseless matching" for radio buttons, which is NFKD(toCasefold(NFKD(toCasefold(NFD(X))))) = NFKD(toCasefold(NFKD(toCasefold(NFD(Y)))))) |
| 20:25 | <Domenic> | mathiasbynens ^ |
| 20:33 | <zcorpan_> | SimonSapin: i think there is a test case for that for radio buttons in wpt |
| 20:34 | <zcorpan_> | SimonSapin: but iirc browsers don't really match the spec |
| 20:52 | <mathiasbynens> | SimonSapin: http://www.unicode.org/Public/UNIDATA/NormalizationTest.txt for normalization (NFD/NFC/NFKD/NFKC) |
| 21:12 | <SimonSapin> | thanks zcorpan_, mathiasbynens |
| 21:20 | <annevk> | SimonSapin: I think we want to change that to just be ASCII case-insensitive if we can |
| 21:20 | <annevk> | Hixie: everyone has some time for necessary refactoring every now and then |
| 21:21 | <SimonSapin> | oh, good |
| 21:21 | <Hixie> | it seems to be all we're doing these days |
| 21:21 | <Hixie> | and i don't have the time for it :-) |
| 21:21 | <Hixie> | got too many real bugs to fix :-) |
| 21:21 | <Ms2ger> | Hurry up, then :) |
| 21:21 | <annevk> | Hixie: well maybe I didn't have time for it five years ago and it just happens to be done now; we're not all on the same schedule ;-) |
| 21:23 | <annevk> | Hixie: and refactoring has positive benefits, e.g. the way I rewrote HTML's fetch has made introducing several APIs a lot easier |
| 21:24 | <Hixie> | how about bugs like https://www.w3.org/Bugs/Public/show_bug.cgi?id=18780 then :-P |
| 21:24 | <Ms2ger> | Oh, lovely, the shadow dom craphole |
| 21:24 | <annevk> | Hixie: no implementer seemed interested :/ |
| 21:26 | <Hixie> | anyway i'm not complaining abotu refactoring, i'm complaining about pure editorial changes that require other editors (me) to make apparently pointless changes |
| 21:29 | <Hixie> | (especially those done without warning or consultation) |
| 21:31 | <annevk> | I wish I had a bit more time to chat. But e.g. with Fetch you were opposed to the refactoring initially. And I wasn't quite sure what the uplift was going to be either other than a feeling that I was heading in the right direction... It's not real easy... |
| 21:31 | <Domenic> | See, if HTML was on GitHub and the tooling was open-source, we could just submit pull requests to fix them... |
| 21:31 | <Hixie> | with fetch i still haven't had time to fix html, so the concerns i had were valid |
| 21:31 | <annevk> | Will probably have some more time tomorrow evening |
| 21:32 | <Hixie> | Domenic: my experience is that when people submit patches to html, they _always_ screw it up |
| 21:32 | <Hixie> | Domenic: so... |
| 21:32 | <Hixie> | Domenic: (you're welcomet to submit pull requests to html-mirror) |
| 21:32 | <Domenic> | interesting |
| 21:44 | <zcorpan_> | i thought html-mirror was read-only |
| 21:45 | <zcorpan_> | but maybe that was the point |
| 21:45 | <Hixie> | it is, i wouldn't apply the pull requests directly |
| 21:45 | <zcorpan_> | "HTML Standard (SVN mirror only; no pull requests)" |
| 21:46 | <Hixie> | but if someone wants to send a patch and they prefer doing it with github than the svn repo, i don't mind |
| 21:47 | <zcorpan_> | ok so should it say so instead of "no pull requests"? |
| 21:48 | <Hixie> | i'd much rather people filed bugs saying what they want than submit patches |
| 21:48 | <Hixie> | patches are way more work |
| 21:48 | <Hixie> | for me |
| 21:48 | <Hixie> | because i first have to work out what the person was trying to do, then i have to actually do it the right way |
| 21:51 | <Domenic> | For cases like these patches make more sense |
| 21:51 | <Domenic> | (Agree/disagree?) |
| 21:51 | <Hixie> | which cases? |
| 21:51 | <Domenic> | Where another author updates their spec and needs you to update some link anchors or references |
| 21:52 | <Hixie> | depends, but in principle there can be such cases where a patch would be fine, sure |