| 01:25 | <MikeSmith> | TabAtkins: so I need to come up with a one-sentence prose description of "valid source size list" to add to http://wiki.whatwg.org/wiki/MicrosyntaxDescriptions |
| 01:26 | <MikeSmith> | TabAtkins: how about "A comma-separated list of size expressions, with each size expression consisting of a CSS length optionally preceded by a CSS media condition."? |
| 01:54 | <MikeSmith> | Hixie: Clicking on the [FOO] text in the References section (in the single page spec) should ideally show me that <dfn> popup thing, listing all the places in the spec which reference [FOO] |
| 01:54 | <MikeSmith> | Hixie: I thought you had it doing that behavior before and it's regressed, but maybe I just imagined that it did it before but it never actually had |
| 01:56 | <MikeSmith> | Hixie: anyway it seems like with your current toolchain if you just wrapped the [FOO] text there is a <dfn> it would automatically give the behavior I want |
| 01:57 | <MikeSmith> | Hixie: and further anyway, please consider this a request to make your new toolchain do it at least |
| 02:35 | <Hixie> | MikeSmith: nted |
| 02:35 | <Hixie> | noted, even |
| 02:35 | <MikeSmith> | thanks |
| 02:35 | <MikeSmith> | raised a bug for it |
| 02:35 | <Hixie> | oh, excellent, thanks |
| 02:39 | <MikeSmith> | TabAtkins: I guess there's a reason why source-size lists can only contain <media-condition>s but not <media-query>s? |
| 02:42 | <TabAtkins> | <media-query> is stupid and legacy, that's why. |
| 02:43 | <TabAtkins> | Regarding a prose description, I might emphasize that there are pairs of conditions/sizes, and a final bare size. |
| 02:44 | <TabAtkins> | MikeSmith: How useful is that ref thing? I was thinking of adding it to Bikeshed. |
| 02:45 | <MikeSmith> | TabAtkins: for the HTML spec at least I find it extremely useful myself |
| 02:46 | <MikeSmith> | necessary even |
| 02:46 | <MikeSmith> | for smaller specs it might be less useful |
| 02:47 | <TabAtkins> | Interesting would be to ref cross-spec too. |
| 02:48 | <TabAtkins> | Would mean a larger database from Shepherd, but definitely possible. |
| 02:48 | <MikeSmith> | oooh yeah |
| 02:48 | <MikeSmith> | that would be very nice to have |
| 02:49 | <Hixie> | oh like a <dfn> pointing to where it's used in other specs? |
| 02:49 | <Hixie> | that'd be interesting |
| 02:49 | <MikeSmith> | yeah |
| 02:52 | <MikeSmith> | TabAtkins: hmm yeah about the prose description, from what you said and looking back at the grammar, I realize it's not pairs of "a CSS length optionally preceded by a CSS media condition. |
| 02:52 | <TabAtkins> | Hixie: Please make HTML Bikeshed friendly for its dfns, and I will produce wonders. |
| 02:52 | <Hixie> | file a bug letting me know what you need |
| 02:52 | <TabAtkins> | Kk |
| 02:53 | <Hixie> | i'm hoping to make my pipeline eventually just fetch the remote specs and figure it all out dynamically |
| 02:53 | <TabAtkins> | (It's a whole bunch of data-dfn-type attributes.) |
| 02:53 | <TabAtkins> | Yeah, you should be able to use Shepherd's data too. It's great. |
| 03:04 | <MikeSmith> | TabAtkins: OK so for the prose how about "A list of one or more condition-size pairs, each consisting of a required CSS media condition plus a required size (CSS length), then optionally with a single final (condition-less) size (CSS length) following the list of all condition-length pairs."? |
| 03:04 | <MikeSmith> | prose is hard |
| 03:05 | <TabAtkins> | Sounds reasonable |
| 03:05 | <MikeSmith> | cool, thanks |
| 03:06 | <TabAtkins> | Hixie: Let me know when you're interested, I can help you interface with Shepherd for linking data. |
| 03:15 | <MikeSmith> | TabAtkins: for <picture> is there a use case for specifying both media= and sizes= for the same <source> element? |
| 03:17 | <TabAtkins> | Yeah, for sure. Use sizes whenever the image is variable sized. |
| 03:17 | <TabAtkins> | That can definitely happen within media breakpoints. |
| 03:18 | <MikeSmith> | ok |
| 03:19 | <SamB> | TabAtkins: does he like keep it in a cyborg implant or something? |
| 03:19 | <SamB> | the linking data |
| 03:20 | <TabAtkins> | Shepherd is the name of the program. ^_^ |
| 03:21 | <TabAtkins> | plinss is the maintainer of the project. |
| 03:23 | <MikeSmith> | TabAtkins: so sizes='all 500px, 100vw' is disallowed, right? (because it has a media query, not a media condition) |
| 03:24 | <SamB> | TabAtkins: so how come the program is the one with a human-looking name! |
| 03:25 | <TabAtkins> | MikeSmith: Yes |
| 03:26 | <TabAtkins> | SamB: Shepherd is a title, not a name! |
| 03:26 | <SamB> | TabAtkins: some people seem to have it as a name anyway |
| 03:28 | <MikeSmith> | TabAtkins: so (sorry if I'm being daft) but why is "all 500px" disallowed? There's no use case for an author to use it? (Or to use some similar media query in sizes with whatever other media type) |
| 03:29 | <TabAtkins> | Media queries are obsolete. |
| 03:30 | <TabAtkins> | That is, the actual mq part. |
| 03:31 | <TabAtkins> | They're mostly deprecated in the spec. Only a handful of remaining ones are allowed to evaluate to anything. |
| 03:32 | <MikeSmith> | TabAtkins: ok, thanks |
| 04:19 | <MikeSmith> | TabAtkins: incidentally do you think it would be useful for the markup validator to emit a warning for use of media-type mqs in HTML markup -- e.g., source@media and link@media? |
| 04:19 | <MikeSmith> | TabAtkins: with the warning saying or paraphrasing the "It is expected that all of the media types will also be deprecated in time, as appropriate media features are defined which capture their important differences." statement from the MQ spec |
| 04:21 | <SamB> | so, what's the new way to handle style for printing? |
| 04:24 | <MikeSmith> | SamB: maybe "update-frequency:none, pointer:none, hover:none, overflow-block: paged, overflow-inline: none" |
| 04:24 | <MikeSmith> | per http://dev.w3.org/csswg/mediaqueries-4/#issue-ef9781e9 |
| 04:25 | SamB | wonders how pointer:none helps with that ... |
| 04:30 | <MikeSmith> | SamB: I see now my response wasn't an answer to the question you actually asked but instead an answer to the question, "What's the new way to do a media query for print?" |
| 04:32 | <MikeSmith> | or more specifically a media query for printer device, as opposed to say, an eink device, as opposed to a desktop computer |
| 04:33 | <SamB> | ah, I guess I see the point there ... |
| 04:34 | <MikeSmith> | yeah the actual CSS rules of your "print" stylesheet you'd just keep the same as now, I think |
| 04:34 | <SamB> | hmm, actually, wait, none of that indicates the need for a different color scheme |
| 04:35 | <MikeSmith> | well it's just an editor's note-to-self FIXME in the spec at this point, I think |
| 04:35 | <MikeSmith> | but it gives the general idea |
| 04:36 | <MikeSmith> | that idea being, you do finer-grained feature detection instead of simple-minded coarse media-type detection |
| 04:38 | <SamB> | which is why I thought of the lack of a hint for the different color needs presented by paper (like "don't wrinkle it to hell by putting ink everywhere for no reason") |
| 05:16 | <zcorpan> | MikeSmith: it should be zero or more ... Optionally followed by the default size. But at least one of them |
| 05:46 | <TabAtkins> | SamB: As noted, the answer is "figure out what things you actually depend on", and use MQs for those. |
| 05:47 | <SamB> | yeah |
| 07:13 | <mathiasbynens> | https://news.ycombinator.com/item?id=7928968 makes it seem like the URL Standard needs some evangelism |
| 07:15 | <MikeSmith> | https://twitter.com/shadow_hayato/status/480931013871165442 :-) |
| 07:15 | <MikeSmith> | hayato++ |
| 07:16 | <MikeSmith> | mathiasbynens: oh god |
| 07:18 | <MikeSmith> | "The relevant specs are..." [list of the wrong specs instead of the right one] |
| 07:18 | <mathiasbynens> | yep… and there are several comments like that |
| 07:19 | <mathiasbynens> | i replied, but it seems like More People™ need to know about the URL Standard |
| 07:23 | <MikeSmith> | mathiasbynens: your plan sounds logical but would result in much less entertainment value like what's provided in these comments |
| 07:40 | <Ms2ger> | mathiasbynens, that's not a real standard! It's not written for 80s printers! |
| 09:32 | <odinho> | http://blogs.opera.com/desktop/2014/06/opera-24-linux-released-developer-stream/ < opera developer 24 linux ♥ :) |
| 09:53 | <jgraham> | Better late than never I guess |
| 09:53 | <jgraham> | Although I was guessing "never" so apparently my guesses aren't worth much |
| 09:53 | <wilhelm> | I lost a bet. |
| 10:21 | <annevk> | mathiasbynens: talk about it at a conference? |
| 10:21 | <annevk> | mathiasbynens: could use some help with test suite and browser evangalism too |
| 10:22 | <annevk> | mathiasbynens: Gecko folks seem to be warming up to the idea of cleaning up URL code, but it's going to take a while |
| 10:23 | <annevk> | Domenic: when will streams.spec.whatwg.org be up? |
| 14:20 | <Domenic> | annevk_: good question. I have no idea how to get subdomains set up. Halp? |
| 14:20 | <annevk> | Domenic: Hixie can get you an account and ssh access |
| 14:21 | <annevk> | Domenic: unless you want me to handle a basic syncing thing that the other specs use too |
| 14:21 | <annevk> | Domenic: most *.spec.whatwg.org domains just have a webhook which is a simple script that gets files from GH |
| 14:22 | <Domenic> | annevk: hmm unsure. maybe i could see your scripts or whatevs, then figure out how to get them integrated into the CI? |
| 14:22 | <Domenic> | Right now I have https://github.com/whatwg/streams/blob/master/deploy-gh-pages.sh |
| 14:23 | <annevk> | #!/bin/sh |
| 14:23 | <annevk> | echo "Content-type: text/plain" |
| 14:23 | <annevk> | echo "" |
| 14:23 | <annevk> | curl -L https://raw.github.com/whatwg/dom/master/dom-core.html > dom-core.html |
| 14:23 | <annevk> | echo "teehee" |
| 14:23 | <Domenic> | heh fair |
| 14:23 | <Domenic> | I am aiming for a "v0.9" end of this week, so yeah getting the correct URL might be good. |
| 14:24 | <annevk> | So if you want to handle it yourself, just ask Hixie |
| 15:36 | <Domenic> | annevk: what does asBlob add that asArrayBuffer does not? |
| 18:30 | <annevk> | Domenic: MIME |
| 18:31 | <annevk> | Domenic: and being cloneable without memory impact |
| 18:31 | <Domenic> | annevk: aren't ArrayBuffers transferable? |
| 18:47 | <annevk> | Domenic: that makes them unreadable from the point of transfer |
| 18:47 | <annevk> | (which is why I said cloneable, not transferable) |
| 18:58 | <Domenic> | mmm, right, so they're the missing immutable array buffers |
| 20:13 | <Domenic> | WebIDL needs to be moved to Rec. That is exactly what it needs. |
| 20:24 | <Hixie> | yeah, nothing would help webidl more than to be moved to rec... |
| 20:41 | <jamesr_> | looks like target is a hook to avoid recursion |
| 20:41 | <annevk> | jamesr_: seems somewhat weird to me to invoke that |
| 20:41 | <jamesr_> | hmmm |
| 20:41 | <annevk> | jamesr_: what actually happens is that the ECMAScript engine terminates (engine started for that callback) |
| 20:42 | <annevk> | jamesr_: so something should just wrap the engine terminating and you should just cause it to terminate by rethrowing an exception |
| 20:42 | <annevk> | anyway, bedtime |
| 20:42 | <jamesr_> | and poor polyfill guy is boned |
| 20:43 | <jamesr_> | g'night |
| 20:43 | <JonathanNeal> | ouch |
| 21:08 | <JonathanNeal> | Any folks here using SVGs? I have some questions about using them in <use xlink:href> vs <img src>. |
| 21:09 | <JonathanNeal> | Namely, I have used <use xlink:href> because it allows me to style properties of the svg per instance per page. The downside is, IE does not support external sources and no browsers supports cross domain sources. |
| 21:28 | <TabAtkins> | JonathanNeal: And? |
| 21:28 | <JonathanNeal> | Well, since <img> doesn’t do the aforementioned things, I was wondering what techniques people have chosen and how they have worked around the drawbacks. |
| 21:29 | <SamB> | JonathanNeal: did you check if .svg can do those things? |
| 21:30 | <TabAtkins> | JonathanNeal: Ah, so you've got a collection of SVG images, and you're trying to use an inline <svg><use/></svg> in the page to try and produce colors to it via inheritance? |
| 21:30 | <SamB> | if that doesn't work, maybe you can, uh, use xinclude to *generate* the different-colored SVGs? |
| 21:32 | <SamB> | JonathanNeal: anyway, presumably using same-domain .svg files to set the different colors would at least help for the other browsers? |
| 21:32 | <JonathanNeal> | TabAtkins: yes, sometimes I am using svgs like folks use font icons. I wondered if someone had come from the other approach of replacing PNGs and using <img src="path/to/image.svg"> and I thought we could talk about how and why we used either. I just wanted to learn, and evaluate which method is best in certain circumstances. |
| 21:34 | <TabAtkins> | JonathanNeal: Okay, now I understand what you're doing. |
| 21:35 | <TabAtkins> | What you want is SVG Parameters, which are a way to set custom properties on an external SVG document via query params. |
| 21:35 | <TabAtkins> | Which... doesn't exist yet. |
| 21:35 | <SamB> | So, exactly to what extent does the SVG spec not support CORS? I mean, are there just some little changes needed, or are they somehow opposed to it? Is there some political problem preventing them from referring to the relevant algorithms? |
| 21:35 | <TabAtkins> | But when it does, you'll have what you want. |
| 21:35 | <SamB> | TabAtkins: so helpful ... |
| 21:35 | <TabAtkins> | SamB: Nah, just a matter of putting in the work. krit was working with annevk recently about it. |
| 21:36 | <SamB> | I guess it's not as trivial as I would have expected then |
| 21:39 | <moorsiek> | hey, guys! |
| 21:42 | <moorsiek> | Anybody knows the origins of the 16px font-size in browsers? I've dug many-many sites, specs, etc., but couldnt find when (or why) 16px became some sort of defacto standard. =| |
| 21:43 | <JonathanNeal> | moorsiek: I researched this once. |
| 21:43 | <JonathanNeal> | First, it’s because 16px is 12pt. |
| 21:48 | <TabAtkins> | Yup, 16px=12pt, the default in word processors and such. |
| 21:48 | <TabAtkins> | It's just a pretty standard size. |
| 21:54 | <moorsiek> | Okay, I see. Thank you, guys! So it appears that the www has inherited this size from the other field :) |
| 22:03 | <JonathanNeal> | moorsiek: we have inherited a lot from previous fields. |
| 22:03 | <JonathanNeal> | Keyboard layouts, font sizes, the 80 character thing, etc. |
| 22:14 | <JonathanNeal> | paul_irish: do you remember when we researched the 12pt thing? Didn’t you compile the history somewhere? |
| 22:14 | <JonathanNeal> | the 12pt being the default in browsers thing |
| 22:44 | <JonathanNeal> | moorsiek: In 1785, Francois Didot was refining typography standards. This was before TabAtkins and linear gradient. Back then, a lot of measurements were written non-numerically. Imagine if we wrote measurements like we write color: blue. e.g. font-size: parisienne. So, Francois “normalized” the standard size of type to be 1/72 of a French inch and he |
| 22:44 | <JonathanNeal> | called that a pica, which he divided into 12 points. Dividing by 12 was the natural thing to do back then. |
| 22:47 | <Hixie> | other way round (point = 1/72", pica = 1/12pt) |
| 22:48 | <Hixie> | no wait |
| 22:48 | <Hixie> | what you said was right except s/inch/foot/ |
| 22:49 | <JonathanNeal> | Yes, thanks. And really, Didot was reworking something he had seen from Truchet years earlier, much like we still do today. |
| 22:50 | <Hixie> | yeah. also all these numbers got renormalised a few times over the years |
| 22:51 | <JonathanNeal> | Yes, and eventually Adobe and Mac implemented the same standard that had been suggested something like twenty years prior. |
| 22:52 | <JonathanNeal> | Much like Firefox and IE. |
| 22:53 | <JonathanNeal> | And then we ruined line returns i mean carriage returns i mean, anyway, and then we had a standard. And that’s where standards come from. WHATWG is the best standard. The last standard, surely, for the rest of the history of mankind. |
| 22:59 | <JonathanNeal> | My favorite is the 80 character rule. It goes back to an 80 character limit on a screen, which goes back to 80 column standard on a punch card designed in 1928. |
| 23:01 | <caitp> | #927 |
| 23:11 | <JonathanNeal> | Hixie: here’s one I don’t know. Why do we use angled brackets for HTML? |
| 23:11 | <Hixie> | cos sgml used angle brackets and tim thought it looked cool, or something |
| 23:12 | <zewt> | my least favorite is people who try to tell me to mangle my python code so it doesn't wrap on an 80 column screen |
| 23:12 | <zewt> | re: no. |
| 23:13 | <Hixie> | 80's a bit narrow, but it's good to pick a fixed width so all the developers on a project know what size to make their edit windows |
| 23:14 | <zewt> | having a rough guideline, but having a couple lines wrapping is harmless in any reasonable programmer's editor |
| 23:14 | <Hixie> | there's nothing reasonable to do with wrapping lines |
| 23:14 | <zewt> | and my rough guideline is closer to 120 |
| 23:15 | <zewt> | doesn't give me any trouble |
| 23:15 | <Hixie> | 120's probably ok if nobody on your project likes to have lots of narrow edit windows next to each other |
| 23:15 | <zewt> | not mangling my code for people who do that |
| 23:15 | <Hixie> | that's fine if your project doesn't have such people |
| 23:16 | <a-ja> | but the lines always wrap on my TTY |
| 23:16 | <zewt> | my favorite is pep-8, which has a bunch of "how to wrap code to fit in 78 or whatever columns", and those examples are so hideous they make a joke of pep-8 |
| 23:16 | <Philip`> | 80 characters wide with 8-space tabs (e.g. the Linux kernel) is great - some people take the hint to avoid deep nesting and pull things out into helper functions, while other people decide to indent heavily and then split their code into a single symbol per line so it trickles down the right of the screen in a nice random pattern |
| 23:17 | <zewt> | such people can deal with it, because such people can't expect the whole world to bend their code for them |
| 23:17 | <Hixie> | zewt: not the whole world, just the people on their project. |
| 23:18 | <zewt> | i stick to 4-space tabs now, mostly because it's the most common and an easy sell to programmers--when it comes to indentation, consistency is more important than anything |
| 23:18 | <zewt> | some people dislike 8 as too wide; I consider 2 completely unreadable |
| 23:19 | <Hixie> | i assume you mean indents, not tabs |
| 23:19 | <zewt> | (and only gnu would use 3) |
| 23:19 | <Hixie> | using raw tabs is obviously crazy |
| 23:19 | <zewt> | yes, I always turn hard tabs off completely |
| 23:19 | <JonathanNeal> | Got it, so in 1974, Charles Goldfarb was looking to create a standard way to markup documents. His partners were Ed Mosher and Ray Lorie and they called it Generalized Markup Language because it matched their last initials. |
| 23:20 | <zewt> | since some editors conflate indentation and tab stops and some people can't understand the difference, or why hard tabs are always 8 spaces, and the easiest sell it just turn them off |
| 23:21 | <Hixie> | anyway the real reason to make sure you wrap to 80 chars is that that's the width of a punch card |
| 23:21 | <Hixie> | and if you overflow that, your punchcard processor is just gonna fail |
| 23:21 | <Hixie> | which is expensive |
| 23:21 | <Hixie> | and a waste |
| 23:21 | <zewt> | well, that's not why it's in pep-8 :P |
| 23:21 | <Hixie> | so, stick to 80 chars |
| 23:22 | <JonathanNeal> | Hixie is right. |
| 23:22 | <zewt> | which is the PEP I take least seriously, and which some people try to use as bible |
| 23:23 | <JonathanNeal> | I still haven’t learned why they choose angled brackets, but in the original GML of the 70’s tags were started with a colon and ended with a period, e.g. :h1. |
| 23:24 | <zewt> | maybe it's as simple as "tags starting with a colon and ending with a period is hideous" |
| 23:24 | <caitp> | at the end of the day, it doesn't really matter what they picked |
| 23:24 | <Hixie> | (and 72 characters is reasonable because the last 8 are typically used for sequence numbers so you can resort a deck if you drop it) |
| 23:27 | <JonathanNeal> | caitp: it doesn’t matter until someone wonders why all HTML isn’t slim-lang. |
| 23:28 | <JonathanNeal> | Or Coding Horror calls it a tax. http://blog.codinghorror.com/xml-the-angle-bracket-tax/ and pushes the industry further from XML-like protocols (and perhaps into JSON-like protocols) |
| 23:28 | <caitp> | even if html wound up looking like HAML or YAML or whatever else, people would still say it wasn't nice |
| 23:28 | <caitp> | because that's just what people do |
| 23:28 | <zewt> | json seriously needs to allow comments |
| 23:29 | <caitp> | the syntax/grammar of html is really one of the least offensive parts when you get down to it |
| 23:31 | <JonathanNeal> | I think I got it! In a 90’s book, some guy mentioned that writing out the code was part of the process, and it was a real pain, and certain decisions were made to help make physically writing the code easier. |
| 23:34 | <JonathanNeal> | Nevermind, I misunderstood it. Sorry, Steven J. DeRose. |
| 23:39 | <JonathanNeal> | Okay, so there were several standards. Because SGML had to allow for multiple delimiters, the spec was huge. Most folks found using <> was the most readable, thus “SGML elements were (nearly always) delimited with angle brackets.” http://www.snee.com/bobdc.blog/2012/01/a-brief-opinionated-history-of.html |
| 23:45 | <TabAtkins> | zewt: "hard tabs are always 8 spaces"? |
| 23:49 | <zewt> | the tab stop for ^I should always be 8 spaces, but people who confuse the hard tab stop with the code indentation size change it, resulting in WW3 |
| 23:50 | <zewt> | and visual studio's criminally incompetent developers set tab stops to 4, which badly aggravates the problem |
| 23:50 | <SamB> | zewt: it might not be the devs' fault |
| 23:51 | <SamB> | that might be management's mandate ... |
| 23:51 | <SamB> | (though perhaps they don't have many VS hackers *left* who still run Emacs) |
| 23:51 | <zewt> | to users that's not really a distinction, but okay |
| 23:52 | <zewt> | call it the visual studio team if you want |
| 23:53 | <TabAtkins> | zewt: Oh, right, hard tabs are "insert multiple spaces". Sorry, was confused. |
| 23:54 | <zewt> | hard tabs are insert tab control characters, soft tabs are insert spaces |
| 23:54 | <zewt> | (not sure if we're saying the same thing) |
| 23:54 | <TabAtkins> | Argh, dammit. I got it backwards again! |
| 23:55 | <TabAtkins> | Well, tab control characters are purposely resizable, but I think I've had this discussion with you before, and you wont' admit you're wrong. ^_^ |
| 23:55 | <JonathanNeal> | That’s why I prefer tabs. You decide! |
| 23:56 | <zewt> | changing the tab stop size means you have text files that are only viewable consistently f you configure your environment to match the one they were authored in |
| 23:57 | <TabAtkins> | As we've discussed in the past, that only happens if people misuse tab characters for alignment, rather than solely indentation. |
| 23:57 | <zewt> | code with the "wrong" tab stop is invariably hilarious but useless |
| 23:57 | <SamB> | TabAtkins: Knuth says tabstops are 8 spaces apart |
| 23:57 | <SamB> | are you gonna argue with Knuth? |
| 23:57 | <zewt> | things I'm not going to spend mental bandwidth on while working (and worse, time trying to explain to coworkers): whether I'm inserting spaces or tabs |
| 23:58 | <SamB> | but yeah, it's not so much an issue if you very carefully follow these arcane rules to ensure that they're only used for alignment, and that tabs and spaces are never mixed ... |
| 23:58 | <JonathanNeal> | Tabs are intended to be variable and responsive. That’s why we have .editorConfig and other tools to standardize them across machines to your hearts content. |
| 23:58 | <JonathanNeal> | And I can just undo all your two-spaces and put in tabs, and let you configure tabs to look like two-spaces. We both win. |
| 23:58 | <SamB> | I thought tabs were a primitive mechanism for text compression for teletypes |
| 23:59 | <JonathanNeal> | Until you start using tabs for space alignment, and at that point, you’re doing it wrong. |
| 23:59 | <SamB> | I always consider it a "lose" when I have to configure a tab size in my editor to make something look sensible |
| 23:59 | <SamB> | this happens far more than I should like |
| 23:59 | <JonathanNeal> | http://editorconfig.org/ problem solved |