| 00:00 | <zewt> | turn off hard tabs, use 4-space indents. problem solved in the simplest way imaginable |
| 00:00 | <SamB> | therefore, some people are reconfiguring the size AND not aware of the associated arcane rules |
| 00:01 | <SamB> | (or using braindead stuff like VS that starts out with a non-standard value) |
| 00:02 | <zewt> | I sure don't want to spend time (expensive time, since it involves getting other people to do it too) just to allow fiddling with the indentation; 4 spaces is fine |
| 00:02 | <SamB> | zewt: yeah, I prefer that approach |
| 00:03 | <SamB> | I set my Emacs to avoid TAB by default |
| 00:04 | <zewt> | and since it's an easy sell, it leaves more in the "arguing about code style with coworkers" budget for things like "don't write comments in stream of consciousness" |
| 00:05 | <montecfel> | This is unbelievably annoying. When drawing a text with fillText on a canvas, the font will randomly blur even though you Math.round() the x and y coordinates. The string "This is a text." is blurry. If I change it into "This is a text.aaa", it becomes sharp. If I remove or add any chars, it becomes blurry again. Can somebody save my computer from meeting with my sledgehammer? |
| 00:06 | <montecfel> | The font size is not dynamic, but fixed at 16px. |
| 01:42 | <TabAtkins> | zewt: Arguing about tab width is a fun thing to burn code-style budget on. Real tabs avoid this. |
| 01:43 | <TabAtkins> | SamB: The "arcane rules" are "indent with tabs, align with spaces". Not exactly hard. |
| 01:44 | <SamB> | I guess it isn't too complicated for *C* |
| 01:44 | <TabAtkins> | When aligning a broken line, you indent to the same level, then align the remaining with spaces. Trivial. |
| 01:44 | <SamB> | TabAtkins: it's arcane compared to "don't use TABs" |
| 01:45 | <TabAtkins> | "Arcane in comparison" doesn't carry much weight when both are so simple. ^_^ |
| 01:46 | <SamB> | well, a lot of people still manage to screw it up :-( |
| 01:46 | <TabAtkins> | A paperclip is heavy when compared to a feather, but that doesn't make it "heavy". |
| 01:47 | <TabAtkins> | Yeah, and those same people screw up space alignment too. I've never seen a space-indented file without an indentation mistake. |
| 01:48 | <caitp> | as long as it's "good enough", who cares |
| 01:48 | <SamB> | TabAtkins: I guess you haven't looked very hard ;-) |
| 01:48 | <TabAtkins> | Oh, I'm sure they exist, particularly when there are automated checks or strict style reviews. |
| 01:49 | <TabAtkins> | But I think they're rare. |
| 01:50 | <caitp> | if you abolish style rules, you don't even need git blame anymore, the blame is built into the file :D |
| 01:50 | <TabAtkins> | caitp: A file that randomly switches between 2 and 4 space indents isn't "good enough". |
| 01:50 | <SamB> | TabAtkins: oh, sure |
| 01:50 | <caitp> | i'm not being totally serious there tab, but I think there are a lot of things that you can let slide |
| 01:50 | <SamB> | but the indent width setting is totally different from the tab width settign |
| 01:50 | <caitp> | like aligning function parameters on a wrapped line |
| 01:50 | <TabAtkins> | And I've seen plenty of that, even for single-author files. |
| 01:50 | <othermaciej> | “never use tabs” is a much simpler rule to follow |
| 01:50 | <caitp> | stuff like that is pretty "who cares" |
| 01:51 | <caitp> | long as it's readable |
| 01:51 | <TabAtkins> | caitp: Yeah, I usually break lines by just indenting an extra level, rather than aligning anything. Even simpler. |
| 01:51 | <othermaciej> | consistency is important for code |
| 01:51 | <othermaciej> | irrelevant differences jump out at you, making it harder to notice the relevant differences |
| 01:51 | <TabAtkins> | Because then the rule is "always use tabs". |
| 01:52 | <caitp> | consistency is important |
| 01:52 | <caitp> | but it's not the -most important thing- |
| 01:52 | <SamB> | TabAtkins: that would work okay as long as it's fine if I leave tabs at the standard width |
| 01:52 | <TabAtkins> | othermaciej: You might want to figure out who you're arguing against, because it isn't me. ^_^ |
| 01:52 | <SamB> | so, you better not nest too much if you do that |
| 01:52 | <othermaciej> | TabAtkins: my statements were counters to things said by different people |
| 01:53 | <TabAtkins> | SamB: Eh, works fine for me at anything between 2 and 8 spaces. |
| 01:53 | <SamB> | anyway, obviously if you don't use tabs, everyone needs to use the same `c-basic-offset' |
| 01:53 | <caitp> | far more bothersome than any of that is the insistence on using hungarian notation |
| 01:54 | <SamB> | hmm, I'm still not sure how I feel about hungarian notation |
| 01:54 | <othermaciej> | TabAtkins: I am pretty sure you agree with me that consistency in code formatting is important, but you also seemed to advocate use of real TABs for indenting, which I am not a fan of |
| 01:54 | <SamB> | TabAtkins: anyway, it sounds like I would have no problem with YOUR files |
| 01:54 | <TabAtkins> | Nominative determinism really leaves me no choice. |
| 01:55 | <SamB> | but many people do not know that there are ANY rules, and that's a problem |
| 01:55 | <othermaciej> | hungarian notation often adds more noise than info |
| 01:55 | <TabAtkins> | Yes, those people are the devil. |
| 01:56 | <SamB> | I would really prefer if getting live TABs required completing a training course of some kind |
| 01:56 | <SamB> | and if clippy would pop up if you started ruining the indentation in a file by using the wrong basic offset ;-P |
| 01:56 | <caitp> | U+000B after every function, or else! |
| 01:56 | <TabAtkins> | Yeah, IDEs could help by highlighting lines that start with spaces. |
| 01:57 | <SamB> | TabAtkins: I think it's a *bit* more complicated than that |
| 01:57 | <TabAtkins> | Yeah, but it's a good start. |
| 01:58 | <SamB> | I mean, how do you know if those spaces are for normal indentation or alignment? |
| 01:59 | <caitp> | his argument was that alignment isn't really necessary -> just add an extra indentation on wrapped lines |
| 01:59 | <SamB> | anyway, you've really gotta throw TAB out the window in, say, Haskell ... |
| 01:59 | <TabAtkins> | Just stick with my "only tabs" rule. |
| 01:59 | <caitp> | which works great for that particular style |
| 01:59 | <caitp> | of course you can do that with spaces too, and then you get to hang out with the cool kids |
| 02:00 | <TabAtkins> | Of all the cool kids jumped off a bridge, would you? |
| 02:00 | <caitp> | depends on the bridge! |
| 02:00 | <TabAtkins> | (Probably yes, there's probably something cool down there.) |
| 02:00 | <SamB> | well, I'd make damn sure my glider was in good shape beforehand ... |
| 02:03 | <SamB> | anyway, I've seen three positions with any sanity to them: Tab's, the one where you use only spaces and you're careful to at least use the same `c-basic-offset' everywhere, and the one where you say tab stops occur every 8 columns and make sure to use the same `c-basic-offset' as everyone else. |
| 02:04 | <SamB> | probably all of these could use some settings in .dir-locals.el |
| 02:06 | <MikeSmith> | "if you abolish style rules, you don't even need git blame anymore, the blame is built into the file" wins |
| 02:06 | <SamB> | I don't even *understand* that utterance |
| 02:06 | <SamB> | oh, wait |
| 02:06 | <caitp> | you can infer authorship and date from writing style! |
| 02:06 | <SamB> | that means everyone uses a different `c-indent-offset'? |
| 02:07 | <caitp> | but it was not a serious comment |
| 02:07 | <SamB> | well, that won't tell you which commit it was though |
| 02:07 | <SamB> | ;-P |
| 02:07 | <caitp> | although of the set of useless super powers |
| 02:07 | <caitp> | that would be a pretty cool one |
| 02:07 | <zewt> | didn't know this thread was still going; i feel sort of bad :P |
| 02:08 | <SamB> | I think I'm done now |
| 02:08 | <SamB> | having given a list of positions I think are at all sane to have |
| 02:08 | <zewt> | i've been watching SGDQ (http://www.twitch.tv/speeddemosarchivesda) and having a beer |
| 02:10 | <TabAtkins> | zewt: It's cool, I'm having wine and flying. |
| 02:11 | <zewt> | TabAtkins, replying to the one thing highlighted at me: my experience is it's much easier to get consensus on "4-space soft tabs" than anything related to hard tab stops, which is a big benefit to me (we can just set it up and get back to work) |
| 02:12 | <TabAtkins> | zewt: On the other hand, Blink and Chromium use 2 and 4 space indents, respectively. Meeting the codebase is painful |
| 02:13 | <TabAtkins> | Merging, argh. |
| 02:14 | <caitp> | blink uses 2 space indents all over the place |
| 02:14 | <zewt> | 2-space indentation is unforgivable |
| 02:14 | <caitp> | er |
| 02:14 | <caitp> | 4 space* |
| 02:14 | <caitp> | are you saying there are files in blink that use 2 space? |
| 02:14 | <zewt> | but more than anything, changing indentation needs to be avoided at all costs |
| 02:15 | <zewt> | if they use different indentation across overlapping codebases, and they've reinvented code that needs to be merged, then somebody needs to be taken out of a decision-making position |
| 02:16 | <zewt> | because that's the worst possible result |
| 02:17 | <caitp> | to be fair, blink was inherited from webkit, and they probably weren't there when webkit decided on their style? but I am pretty sure it's 4 space indentation in chromium, blink and v8 |
| 02:17 | <zewt> | ... reindented (yeah, I'm on my phone) |
| 02:17 | <caitp> | oh i'm wrong, 2 space in v8 |
| 02:17 | <caitp> | there you go =) |
| 02:17 | <zewt> | but if you've forked code and you have any intention of sharing code, you keep the existing indentation style--period |
| 02:17 | <TabAtkins> | We might have aligned indentation after the fork. |
| 02:18 | <SamB> | TabAtkins: that probably wasn't a good idea if you wanted to steal patches ever ... |
| 02:18 | <SamB> | TabAtkins: anyway, .dir-locals.el is your friend! |
| 02:18 | <zewt> | i guess the most important thing to remember about code style is: it's not the most important thing |
| 02:19 | <caitp> | i haven't landed anything in webkit, just blink, so I can't recall |
| 02:20 | <SamB> | I like the coding style rules for the GDB testsuite |
| 02:21 | <zewt> | i assume it's gnu |
| 02:21 | <SamB> | where there *are* no rules for the programs to run GDB on, because some of GDB's bugs might actually depend on coding style ... |
| 02:23 | <TabAtkins> | That's horrifying. |
| 02:24 | <caitp> | it's only horrifying when you realize contractors for boeing might be debugging code on it |
| 02:25 | <caitp> | or toyota or pick your favourite |
| 02:25 | <MikeSmith> | what specifically is being discussed at the "Web Input" meeting? https://twitter.com/jacobrossi/status/481173650523955200 |
| 02:26 | <caitp> | input/touch/pointers/etc? |
| 02:27 | <MikeSmith> | must be I guess |
| 02:29 | <MikeSmith> | http://lists.w3.org/Archives/Public/public-pointer-events/2014AprJun/0084.html it seems |
| 02:30 | <SamB> | TabAtkins: well, you know, GNU have a lot of rules |
| 02:30 | <SamB> | I don't expect the indentation rules are actually involved here |
| 02:30 | <MikeSmith> | ah good TabAtkins was there |
| 02:30 | <MikeSmith> | and I see hober in the photo |
| 02:31 | <TabAtkins> | A bunch of things, trying to align on controversial cross-browser topics. |
| 02:32 | <MikeSmith> | TabAtkins: yeah I'm perusing https://docs.google.com/document/d/1C6P3Mhza1jdMJyP9G6fr7n7zcXrCmwih1o2xohFVEhc/edit now |
| 02:37 | <TabAtkins> | Yeah, Max took good notes. |
| 02:37 | <MikeSmith> | threaded input handling.. |
| 02:38 | <MikeSmith> | the overview at https://docs.google.com/presentation/d/1VYfCKye4TM-QiR_hiLvwYxhci_xc5YcA4oZxtrp2qes/edit#slide=id.p is nice |
| 02:45 | <MikeSmith> | TabAtkins: is there implied optional whitespace anywhere in CSS syntax? (similar to the way there is in grammars in some IETF specs, e.g., HTTP headers |
| 02:47 | <MikeSmith> | TabAtkins: I mean, if I'm looking at a railroad diagram for a certain thing and it doesn't explicitly show whitespace as being allowed in some particular place, does that that mean the corresponding parsing algorithm for that thing does not expect to find whitespace there? |
| 02:47 | <TabAtkins> | Yes, V&U defines all this. |
| 02:48 | <MikeSmith> | ah ok |
| 02:48 | <TabAtkins> | Not that railroad diagrams are non-normative. |
| 02:48 | <TabAtkins> | Note |
| 02:49 | <TabAtkins> | That yes was to your first question, not the second one. |
| 02:49 | <MikeSmith> | TabAtkins: roger that |
| 02:49 | MikeSmith | finds http://dev.w3.org/csswg/css-values/#component-whitespace |
| 02:49 | <TabAtkins> | Yup, that's it. |
| 02:49 | <MikeSmith> | TabAtkins: I guess I expected to find that stated in teh Syntax spec instead of V&U |
| 02:50 | <MikeSmith> | TabAtkins: cool, thanks |
| 02:51 | <TabAtkins> | Syntax does the core syntax, not the grammar of actual properties. |
| 02:51 | <MikeSmith> | ah ok |
| 02:51 | <TabAtkins> | But also, the location is idiot historical. |
| 02:52 | <TabAtkins> | Partly |
| 02:52 | <MikeSmith> | sure |
| 02:53 | <MikeSmith> | TabAtkins: so now I understand about WS among components but the thing I'm wondering about specifically is about WS around delimiters |
| 02:53 | <TabAtkins> | Delimiters? |
| 02:54 | <MikeSmith> | TabAtkins: I mean, e.g., parens in functions -- calc(1px + 3px) vs calc( 1px + 3px ) |
| 02:54 | <TabAtkins> | No rule there. |
| 02:55 | <TabAtkins> | Calc is a bit of a special case, but yeah, arguments to a function obey the same "component value" rules. |
| 02:56 | <MikeSmith> | ah OK sure, yeah, the WS in this case is space around the components, I see |
| 02:58 | MikeSmith | should write stuff out first before asking, since it's quite clear now when he actually looks at it written out |
| 13:56 | <annevk> | I hate these XMLHttpRequest state bugs :-( |
| 16:35 | <JonathanNeal> | Has anyone experimented with JavaScript generated markup how Google interprets it for search results? I’m thinking about entire pages of generated markup. |
| 16:46 | <annevk> | Domenic: when is it good to use null? |
| 16:49 | <TabAtkins> | JonathanNeal: Google hasn't been very detailed with what's happening, but they did announce recently that they're starting to execute at least some JS for indexing purposes. |
| 16:51 | <JonathanNeal> | Yes, clamstar was kind enough to share this with me http://googlewebmastercentral.blogspot.com/2014/05/understanding-web-pages-better.html |
| 16:58 | <Domenic> | annevk: kind of fuzzy, but in general it's a signifier for "there is purposefully nothing here," instead of "this was left unset" (which is `undefined`). |
| 16:59 | <Domenic> | E.g. it seems good that querySelector('asdf') returns `null`. If it returned `undefined`, that's what all functions without return values return, so it's kind of saying "I was supposed to return something, but there was nothing there." |
| 17:00 | <Domenic> | This whole distinction is kind of Stockholm-syndromey. I often catch myself saying "it makes perfect sense! How did we live without the distinction before!" And then I step back and say, WTF, clearly this language has changed your brain. |
| 17:23 | <annevk> | Domenic: so the problem with that is if you start returning null, you want to accept null too |
| 17:24 | <annevk> | Domenic: so you can't really make it a rule that methods accepting null should be retrofitted to use undefined/optional behavior instead |
| 17:24 | <annevk> | Domenic: e.g. node.insertBefore(..., otherNode.previousSibling) |
| 18:05 | <Domenic> | disagree |
| 18:05 | <Domenic> | null should throw in that situation |
| 18:06 | <Domenic> | undefined is a default-value signaler |
| 18:06 | <Domenic> | there's no sensible "default value" for a node that you want to insert |
| 18:06 | <Domenic> | annevk ^ |
| 18:06 | <Domenic> | (both null and undefined should throw in that situation) |
| 18:07 | <annevk> | append seems reasonable |
| 18:08 | <annevk> | (which is what DOM does) |
| 18:14 | <Domenic> | it seems reasonable if you're trying to trigger the default value, but it's more likely a bug if you're trying to pass in document.querySelector('#tpyo') |
| 18:28 | <annevk> | E.g. node.prepend(input) would be node.insertBefore(input, node.firstChild) |
| 18:30 | <annevk> | TabAtkins: with the addition of rebeccapurple various notes around http://dev.w3.org/csswg/css-color/#named-colors are no longer accurate |
| 18:30 | <TabAtkins> | annevk: Yeah, noticed that. |
| 18:30 | <TabAtkins> | Was wondering if/how to change that. |
| 18:30 | <annevk> | TabAtkins: removing the notes about X11, HTML, and SVG might make sense |
| 18:31 | <annevk> | TabAtkins: maybe saying that most of them came from X11 in a note, with a pointer to that email that does all the archeology |
| 18:31 | <TabAtkins> | Yeah, was thinking about that. It's a great email! |
| 18:31 | <annevk> | is |
| 18:34 | <Manishearth> | annevk: around? |
| 18:34 | <annevk> | Manishearth: sorta |
| 18:34 | <Manishearth> | Okay, in http://xhr.spec.whatwg.org/#interface-formdata, in the `create an entry` bit, the spec seems to rewrite the `value` argument multiple times |
| 18:35 | <Manishearth> | Is that intentional? |
| 18:35 | <Manishearth> | This affects step 4, since it says "If value is a File and filename is given" -- `value` will always be a File, since it was made a File in the previous step |
| 18:35 | <Manishearth> | (since it was overwritten) |
| 18:36 | <annevk> | it can also be a string |
| 18:36 | <annevk> | and yes, it is intentional that in case it was a Blob, that step is applied |
| 18:36 | <Manishearth> | annevk: `value` is a Blob |
| 18:36 | <annevk> | not necessarily |
| 18:36 | <Manishearth> | (a File is also a Blob) |
| 18:36 | <annevk> | agreed |
| 18:37 | <annevk> | value is either a string or a Blob |
| 18:37 | <Manishearth> | so in step 3, "If value is a Blob, set value to a new File object", we are overwriting value? |
| 18:37 | <annevk> | yes |
| 18:37 | <Manishearth> | oh, I get it, this is used elsewhere too |
| 18:38 | <Manishearth> | (for the append() and set() where a DOMString is passed) |
| 18:38 | <Manishearth> | er, ScalarValueString |
| 18:38 | <Manishearth> | thanks |
| 18:38 | <annevk> | step 3 should not apply if value is a File however |
| 18:38 | <annevk> | that could be clarified |
| 18:39 | <Manishearth> | annevk: "If value is a Blob but not a File?" |
| 18:39 | <annevk> | yeah |
| 18:39 | <annevk> | making that edit now |
| 18:40 | <Manishearth> | okay, thanks |
| 18:40 | <annevk> | done |
| 19:12 | <IZh> | Hi. Is there API to query file upload progress from JS? |
| 19:12 | <caitp> | what kind of file upload progress? |
| 19:12 | <IZh> | Percentage |
| 19:13 | <caitp> | you can look at XMLHttpRequestUpload progress events, but that obviously is restricted to xmlhttprequest |
| 19:13 | <caitp> | and doesn't work for like, <form method="POST"> |
| 19:13 | <IZh> | Lots of sites do it by using AJAX to query temporary file size from the server. But I would like to ask the browser itself. |
| 19:15 | <IZh> | Of course, I mean POST. |
| 19:16 | <caitp> | I mean, it would work for XHR (unless you're using like IE9 or under), but would not work for form submission |
| 19:17 | <IZh> | I think it would be great to implement some events for form's uploading progress. Because all modern sites need to display the progress. |
| 19:17 | <caitp> | couldn't hurt to ask if browsers are interested in doing that |
| 19:21 | <IZh> | I don't know whether they are, but it could make life easier. |
| 19:38 | <caitp> | well you might want to ask around here (there are some browser people hanging around), and maybe file a bug on the appropriate draft, which would probably be web-apps |
| 19:52 | <Domenic> | nah it'd be whatwg⊙wo |
| 19:52 | <Domenic> | this is about the HTML spec |
| 19:52 | <Domenic> | if it's about <form> |
| 19:55 | <caitp> | yeah, try that |
| 20:23 | <annevk> | IZh: the problem is that <form> causes navigate |
| 20:24 | <annevk> | IZh: which replaces the current document |
| 20:24 | <annevk> | IZh: events for navigation process don't make much sense if the document (and its associated global) change |
| 20:31 | <caitp> | it doesn't necessarily need to cause navigation, though, I think you'd make a lot of people happy if they could just <form method="POST" action="someroute" onprogress="updateWidget()">, heh |
| 20:32 | <caitp> | but I'm not going to get into that little discussion |
| 20:32 | <annevk> | That would cause navigation |
| 20:32 | <caitp> | it would _now_ |
| 20:32 | <caitp> | but it doesn't necessarily need to, if you have some attribute that says "don't navigate plz" |
| 20:32 | <annevk> | If you want a new kind of form submission behavior that would be a different discussion |
| 20:33 | <caitp> | I'm not the one that wants it, I'm just saying it's not really beyond the realm of the reasonable |
| 20:33 | <caitp> | it's doable, and it wouldn't likely break any existing apps |
| 20:34 | <annevk> | Sure, but it's a different feature from progress |
| 20:34 | <caitp> | whether anyone actually wants to do it or not is a different discussion |
| 20:36 | <smaug____> | ojan: does blink have usage data for mutation events |
| 20:37 | <smaug____> | in gecko the data is currently measuring mutation events used in a window, and of 2.1G windows 5.5M have had mutation event listeners |
| 20:43 | <Domenic> | Loving this WebIDL thread |
| 20:45 | <SamB> | smaug____: any idea how had NoScript installed |
| 20:45 | <SamB> | +many |
| 20:45 | <SamB> | or anything of that nature |
| 20:53 | <smaug____> | SamB: no idea |
| 20:54 | <smaug____> | does it use mutation events? |
| 20:54 | <SamB> | actually, I was just figuring sites wouldn't get a chance to use them if noscript blocked the script |
| 20:54 | <smaug____> | oh, those might not get mutation events recorded |