[00:14:22] Was RT duty abolished or is the topic just omissive? :) [11:19:56] apergos: LZMA multithreaded, hurray https://sourceforge.net/p/lzmautils/discussion/708858/thread/d37155d1/#d8af [11:21:05] we already use multiple cores by doing several chunks at once in different processes but it's nice [12:58:05] Nemo_bis: RT duty goes in the -operations topic. [13:13:16] Sure. :) I confused the two windows again [18:49:01] MatmaRex: it's not clear to me why the overflow-x: auto; solution was rejected [18:49:04] 10 second summary? [18:49:12] So far people have been happy we did that. [18:50:19] StevenW: it makes it nigh impossible to horizontally scroll 
 blocks higher than the browser's window
[18:51:12] 	 i don't really know myself if it's better or worse than status quo, no strong opinions either way
[18:51:43] 	 the right way to do it would be to make it wrap, but that's blocked by some Tidy issues as detailed on the bug
[18:52:12] 	 !bug 260
[18:52:26] 	 (huh, no bot here?)
[18:54:21] 	 StevenW: the typography update is leaving beta?
[18:54:42] 	 matanya: yes, arriving next week
[18:55:00] 	 I so the blog post, but i wasn't clear at first
[18:55:02] 	 tahnk you
[18:57:19] 	 *saw
[18:57:22] 	 it
[19:42:39] 	 StevenW: i'm sorry to nudge, but where is the place to conplain about the typography update? I looks really bad in my machine
[19:43:07] 	 [[mw:Talk:Typography refresh]]
[19:43:32] 	 bloody bots, nowhere when you need one
[19:43:41] 	 thanks twkozlowski 
[19:45:30] 	 i need to enlarge mw 3 times in order to read :/
[19:46:40] 	 matanya: welcome to the club
[19:47:00] 	 the buy-in fee is three stroopwafel, by the way
[19:47:11] 	 known issue?
[19:47:27] 	 not sure, StevenW would know
[19:50:49] 	 matanya: considering the font size is actually larger across the board, this should make the font size issue better, not worse
[19:51:09] 	 StevenW: screenshots will help?
[19:51:22] 	 There are screenshots in the page
[19:51:29] 	 it is blurry for some reason on the normal size
[19:51:30] 	 For Ubuntu, Windows, OSX
[19:51:57] 	 StevenW: I mean screenshot from my machine
[19:52:05] 	 ah. Sure.
[19:52:14] 	 that's always helpful
[19:52:47] * twkozlowski  awaits screenshots of elinks under slackware
[19:54:44] 	 StevenW: http://imgur.com/modkHJe
[19:55:40] 	 ugh, that hurts matanya
[19:55:47] 	 big time
[19:56:00] 	 looks like no subpixel rendering, just regular antialiasing
[19:56:45] 	 I saw the images on the page befofe it was released and really wanted it
[19:56:52] 	 now i regret
[19:57:10] 	 I'd suggest posting to the talk page about it.
[19:57:28] 	 including with browser/OS specs for what you use
[19:57:37] 	 why is this happening StevenW ?
[19:58:34] 	 There is a really comprehensive FAQ about it at https://www.mediawiki.org/wiki/Typography_refresh which explains it more fully than I ever could on IRC.
[19:59:14] 	 I can barely read mw now :)
[20:00:18] <^d>	 https://www.mediawiki.org/wiki/Typography_refresh?uselang=monobook
[20:00:23] <^d>	 Now you won't get the new fonts ;-)
[20:00:30] <^d>	 *useskin
[20:00:38] 	 I'm not sure why, from that screenshot, it seems completely unreadable.
[20:01:19] 	 StevenW: my diagnosis would be grey text color + no subpixel rendering
[20:01:33] 	 it just looks blurry instead of antialiased
[20:01:36] 	 it looks bad on fedora too
[20:01:44] 	 The grey text is different, yes. But it still has a AAA (best possible) rating on WCAG contrast guidelines.
[20:01:46] 	 was it tested on fedora?
[20:02:08] 	 Was it tested on PuppyLinux?
[20:02:51] 	 i wouldn't compare the user base
[20:03:01] 	 that also looks like the liberation sans font, and it apparently has much lower x-height than arial
[20:03:21] 	 i don't have non-free fonts on my box
[20:03:21] 	 These are also answered in the FAQ. We typically test on Windows, OS X, and Ubuntu or Debian. These represent the vast majority of desktop readers. 
[20:03:24] 	 i see the same thing (with less bad rendering) and i also find it a bit hard to reda now, eh
[20:04:12] 	 my screenshot: http://i.imgur.com/lciFn7v.png (Opera 12 on Windows 7)
[20:04:15] 	 StevenW: so all rpm best are ignored? not that i'm a user of those, just wonder
[20:04:48] 	 omg MatmaRex
[20:05:01] 	 the bold font looks real ugly
[20:05:02] 	 oh no
[20:05:16] 	 *based
[20:05:34] 	 So to compare to the OS's we tested on I listed, and my own machine. 
[20:05:36] 	 I can say that
[20:05:48] 	 None of these experiences are degraded compared to other platforms with the new version
[20:06:06] 	 my suggestion would be to give this a try for a few hours and see how you feel after. 
[20:06:29] 	 If you hate it there's always User:Foo/vector.css and Monobook etc.
[20:06:56] 	 i don't hate it, i love how it looks in the ads, it just doesn't work for me
[20:07:07] 	 and i want it to work
[20:07:12] 	 Well, you can see that the experience /is/ degraded to what it was before
[20:07:20] 	 otherwise matanya wouldn't complain, I believe
[20:07:30] 	 i had no idea liberation sans looks that awful as main body font…
[20:07:45] 	 matanya: quick question is the body font changed for you, or the same as before?
[20:07:56] 	 what
[20:08:09] 	 i don't even understand the question
[20:08:23] 	 Not everyone actually experiences a change in the body content font family setting. 
[20:08:33] 	 Windows users, for instance. Has it changed for you?
[20:08:34] 	 matanya: can you screenshot wikipedia too, so we can compare?
[20:08:41] 	 yes
[20:08:57] * StevenW  just trying to diagnose the exact part of the changes that might be causing you most grief. 
[20:10:32] 	 StevenW: http://imgur.com/TTCn1Om
[20:11:22] 	 i'm not the complianing type of person, just want things not to break if you improve (which is great you do)
[20:11:30] 	 MatmaRex: see above
[20:12:53] 	 i retract my diagnosis from earlier, it's not the grey text, it's the awful font.
[20:13:12] 	 matanya: so I notice a few things... x-height actually seems improved, etc. but headings not as distinct/readable for you. That feel right? Not sure what serif you'd get on fedora, but it's not ideal. Georgia and similar are much more readable than that, which is what we're going for.
[20:13:36] 	 One of the goals is to make headings stand out more, not less, so if there's a way we can improve that we should for you. 
[20:13:56] 	 StevenW: i'm using arch, not fedora
[20:14:00] 	 ah, sorry
[20:14:19] 	 and the fond is droid sans hebrew
[20:14:22] 	 *font
[20:14:58] 	 On Ubuntu and Debian, we set the font stack to shoot for https://en.wikipedia.org/wiki/Nimbus_Roman_No9_L as the header serif. Is that what you get too?
[20:15:21] 	 how can i check that ?
[20:15:50] 	 i can change the font to liberation for testing
[20:17:48] 	 and basiclly, san-serif fonts are better for screens
[20:20:35] 	 StevenW: ^
[20:25:36] 	 matanya: sorry, was distracted for a moment. 
[20:26:22] 	 Not sure what browser you're using, but Chromium and Firefox should let you see what the displayed font is, if you right-click and inspect element on a header
[20:26:43] 	 firefox
[20:27:51] 	 Liberation Sans is the font
[20:27:58] 	 on the refresh
[20:28:23] 	 and DejaVu Sans on the old 
[20:29:27] 	 so StevenW seems like it does change the font
[20:31:50] 	 Oh well.
[20:32:10] 	 Now I'm forced to have my own vector.css now I visited MW.org after the deployment of TR
[20:33:11] 	 seems so
[20:38:38] 	 csteipp, hexmode, I'm back and ready to go
[20:44:39] 	 mglaser: Go for it (from my perspective)
[20:45:04] 	 :)
[20:47:20] 	 csteipp, attachment 14938 for MW 1.21 is still unconfirmed. Similar patches for 1.22 and 1.19 are tested. can I assume safely that 1.21 is ok?
[20:47:48] 	 mglaser: Sorry, let me look
[20:49:40] 	 mglaser: Yeah, looks good
[20:50:58] 	 thanks
[20:52:46] 	 StevenW: my title (h1) is Nimbus, while body is Liberation, that expected?
[20:53:49] 	 StevenW: NEVERMIND!
[20:54:01] 	 StevenW: I'LL GO AHEAD AND READ WHAT YOU TYPED FIRST
[20:54:06] 	 heh
[20:54:22] 	 They say Firebolt is better than Nimbus
[20:54:22] * greg-g  missed that line
[20:54:23] 	 I hear.
[21:02:49] 	 greg-g: what did you say before i disconnected ?
[21:04:12] 	 matanya: when were you disconnected? the ping timout didn't happen until after you rejoined
[21:04:28] 	 my title (h1) is Nimbus, while body is Liberation, that expected
[21:05:16] 	 this line greg-g ^
[21:05:17] 	 He said he needed to RTFM
[21:05:44] 	 oh well. i'll refresh my css knowlegde
[21:06:43] 	 yeah, Steven said above that that was expected
[21:06:51] 	 MatmaRex, thedj, jdlrobson: Maybe it would be easier if we discuss the typography stuff on IRC :)
[21:07:09] 	 sure
[21:07:45] 	 Issue #1: Do we want to inlcude .mw-editsection-like in the new CSS? I'm agnostic about it.
[21:08:13] 	 It's in the old CSS, but we should probably deprecate it at some point.
[21:08:23] 	 Is now the time to do that?
[21:08:29] 	 greg-g: i really hoped not to hear that
[21:08:45] 	 ugh, i haven't replied to some things on gerrit yet
[21:08:52] 	 matanya: why? looks bad?
[21:08:58] 	 horrible
[21:09:01] * greg-g  nods
[21:09:08] 	 i actually added mw-editsection-like a few months ago
[21:09:10] * greg-g  doesn't notice the stuff easily
[21:09:30] 	 greg-g: did you see my screenshots above ?
[21:09:34] 	 because abusing mw-editsection, along with scripts that hook to it to e.g. provide inline editing, caused issues on pl.wp
[21:10:10] 	 MatmaRex: what was the reason not to just add it to Common.css on-wiki?
[21:10:32] 	 matanya: yeah, but again, I read it just fine :/
[21:10:40] 	 as I assume most wikis are not going to have a use for that selector
[21:10:45] 	 kaldari: so that when people make changes like this one the looks is updated across all wikis
[21:10:49] 	 my eyes might tell you differently after a few hours, but...
[21:11:12] 	 i can only say good for you then :)
[21:11:33] 	 my eyes hurt very quickly with bad fonts
[21:11:42] 	 15 minutes or so
[21:13:28] 	 MatmaRex: FWIW, I edit on a lot of wikis, and I've never before seen an interface like the one at https://pl.wikipedia.org/wiki/Wikipedia:Indeks_biografii/Kal
[21:14:06] 	 kaldari: i know, i wrote that
[21:14:29] 	 but the template documentation looks the same across most large wikipedias at least
[21:14:53] 	 or, well, should look the same. it probably doesn't exactly, because people are not using this class. :)
[21:15:34] 	 MatmaRex: Hmm, personally I don't like crossing the streams, as they say, but I'm willing to put it in if you really think it will be useful to most wikis (not just a small handful).
[21:15:55] 	 What's wrong with that page on pl.wp?
[21:15:59] 	 I used to edit those a lot
[21:16:06] 	 nothing's wrong with it
[21:16:07] 	 oh, you mean Wikidata
[21:16:15] 	 kaldari: i won't veto if everyone wants to kill that class, just please give me a heads-up so i can update everywhere i've used it
[21:16:40] 	 jdlrobson, thedj: what do you think?
[21:16:41] 	 BTW, why is it full of divs and weird stuff?
[21:16:42] 	 kaldari: but for now i think we should try being consistent within core, commonSomething defines this class, so let's do the same in vector where we restyle it
[21:17:02] 	 issue 1: no. mw-editsection-like should die
[21:17:30] 	 meh, this probably won't change the display in most cases anyway
[21:17:42] 	 we should not be inventing classes that do the same thing
[21:17:47] 	 it's just more inconsistencies, and technical debt in a way
[21:18:17] 	 jdlrobson: mw-editsection has a "semantic" meaning, mw-editsection-like doesn't - there is a difference
[21:18:38] 	 pl.wp has at least three user scripts or gadgets that hook to the (real) section edit links to perform inline editing
[21:18:47] 	 then we should rename mw-editsection :-)
[21:18:56] 	 (and a few more which hook to them when they actually want to hook to headings)
[21:19:01] 	 sounds like we need a non-semantic class that is basically the same as mw-editsection to replace it with
[21:19:26] 	 kaldari: replace what?
[21:19:36] 	 ah, mw-editsection? D:
[21:19:52] 	 i just told you that's used to improve editing experience and you tell me we should kill it…
[21:21:07] 	 I mean we should have something like mw-inline-button and actually use it in core instead of or alongside mw-editsection
[21:22:14] 	 hmm, anyway, sounds like we don't have any consensus on this, so let's discuss the other issues...
[21:22:14] 	 hm, if we stick to alongside, then that makes sense
[21:23:07] 	 oh, i just realize you guys were talking here :D
[21:23:10] 	 #2. Should we just get rid of the overflow-x: auto completely or restrict it to non-javascript and non-lua pages?
[21:23:27] 	 thedj: howdy :)
[21:23:58] 	 isn't it a problem for any geshi formatted block ?
[21:24:14] 	 i don't really have a strong opinion on this, but restricting it in this way is a rather major hack, since this makes core depend on the SyntaxHighlight extension
[21:24:25] 	 for proper rendering
[21:24:37] 	 thedj: yes, but we don't have a generic selector for that
[21:24:48] 	 MatmaRex: that's also true.... 
[21:24:57] 	 MatmaRex: Ah, I didn't think about that
[21:25:08] 	 we should fix bug 260 the right way instead, but i can't do it alone in my free time
[21:25:13] 	 kaldari: think of people describing latex
[21:25:16] 	 (the right way = murdering tidy)
[21:25:31] 	 i know there is a wikibook that has huge blobs of geshi latex examples
[21:25:33] 	 James_F: https://gerrit.wikimedia.org/r/#/c/119913/
[21:25:38] 	 You guys have been busy? :-))
[21:25:51] 	 death to tidy !
[21:26:09] 	 sigh, I was so looking forward to not having huge pre blocks, but I guess it'll have to wait for another day :(
[21:26:30] 	 twkozlowski: a little bit ;)
[21:26:56] 	 kaldari: a lot of people were, the bug's number is just three digits long after all ;)
[21:27:24] 	 on the way for 10 years now :D
[21:27:30] 	 OK, so I guess we'll kill that one. Next issue….
[21:27:36] 	 doing the overflow thing might be a bit better than status quo for the most common case, but it will be a lot worse for some less common cases :(
[21:28:12] 	 #3: sup line-height. I think we all agree now that 0 isn't ideal, but I prefer 1 over 1em. What do you guys think?
[21:28:15] 	 !version
[21:28:23] 	 oh dear.
[21:28:26] 	 kaldari: like i added to the review a few mins ago.
[21:28:32] 	 the problem is in nesting
[21:29:02] 	 1 results at half the line-height for the fontsize after a few levels of nesting. whereas 1em is always equal to the font-size
[21:29:06] 	 if just "1" works, i'm alright with it, but i've only seen "1em" in action
[21:29:54] 	 1 should be fine with nesting, in fact it should be better for nesting I believe as it will deal with font-size changes in nesting better.
[21:30:21] 	 it should, but it isn't because with have a lineheight with a unit already at a 'higher' level
[21:30:52] 	 the problem is mixing unitless with units. unitless is better, but it's either everywhere, or nowhere.
[21:31:23] 	 thedj: yes that is true. We're trying to move towards unitless line-heights everywhere
[21:31:33] 	 i made patches at some point to remove units from line-height everywhere, but it didnt get merged because no one had done the testing
[21:31:56] 	 1 should be fine
[21:32:22] 	 thedj: See for example https://gerrit.wikimedia.org/r/#/c/120978/3/skins/vector/variables.less
[21:32:35] 	 https://gerrit.wikimedia.org/r/#/c/27043/
[21:32:36] 	 there's a bug for making everything unitless, with a few dead bodies on failed attempts on it
[21:32:44] 	 that was the one
[21:32:44] 	 of failed attempts*
[21:33:47] 	 kaldari: thedj: https://bugzilla.wikimedia.org/show_bug.cgi?id=2013
[21:34:10] 	 another small-number bug, that no one is willing to commit resources towards fixing
[21:34:21] 	 everyone just wants to write new features instead
[21:34:26] 	 but i digress.
[21:34:30] 	 hehe
[21:35:03] 	 well, my patch no longer applies i'm sure, but that's the difference, nesting and not everything being unitless just yet.
[21:35:22] 	 so, i'd be more comfortable with 1em per what thedj says, but just 1 is probably good enough too; 0 is probably not a good idea though.
[21:35:24] 	 and since sup/sub is often nested, i think that difference is important there
[21:37:18] 	 the problem with having 'half the lineheight' of your font size, is that you can get undesirable overlapping if i remember correctly...
[21:37:25] 	 90% of the line-heights will be unitless now that https://gerrit.wikimedia.org/r/#/c/120978/3/skins/vector/variables.less has been merged, so it still really an issue?
[21:37:45] 	 i don't know, we didn't test :D
[21:38:01] 	 fair enough
[21:38:15] 	 but should be quyick to find out.
[21:38:27] * thedj  copies example to betalabs
[21:39:55] 	 twkozlowski: A bit, yes. :-)
[21:42:42] 	 James_F: Yeah, I thought so :-) I'll leave it up to you, as always, to decide what to feature in #14
[21:43:09] 	 James_F: Not that I am suggesting you should spend some time on Tech News today :-P
[21:43:13] 	 twkozlowski: Not much this week, I think; next week is likely to be bigger.
[21:43:16] 	 twkozlowski: Ha. :-)
[21:46:06] 	 kaldari: ok, i don't see much of a difference in betalabs, but neither if i disable all unit based line-height rules of the parents.
[21:47:23] 	 How about this: we try using 1 (since it's a better long-term solution) and if anyone complains about it, we change to 1em :)
[21:48:26] 	 and everyone can blame me for it
[21:49:04] 	 I'm also OK with 1em if people are really set on that
[21:49:23] 	 No, i'm ok with 1 and seeing if ppl complain.
[21:49:49] 	 MatmaRex: Any objection?
[21:50:24] 	 sorry, got distracted. alright with me.
[21:50:44] 	 cool
[21:51:00] 	 lemme make a follow-up patch...
[21:51:16] 	 then I have to get back to my real job :)
[21:51:28] * thedj  goes to reread the old en.wp discussion to make sure we didn't try that before and failed.
[21:52:00] 	 I didn't see anything in the enwiki discussion about using 1, but I did see that de.wiki changed from 1em to 1.
[21:56:17] 	 MatmaRex, thedj: Thanks to both of you for your help hashing this out.
[21:57:03] 	 it would seem this is what i'm here for ;)
[21:57:16] 	 let's just not do this at 11 pm the next time? ;)
[21:58:03] 	 good idea :)
[21:59:54] * MatmaRex  afk
[22:01:52] 	 kaldari: btw, P and bodyContent are the most important em based line-heights that remain now it seems.
[22:03:58] 	 kaldari: perhaps you wanna note in the summary the removal of the pre styling
[22:05:33] 	 thedj: we got rid of the p line-height in the refresh. I guess we missed the one in BodyContent :(
[22:05:45] 	 thedj: oops...
[22:06:51] 	 eh, in beta i still see the p one...
[22:07:34] 	 p { line-height: 1.5em; } div#content p { line-height: inherit; }
[22:07:57] 	 thedj: the 2nd one trumps the first since it is more specific.
[22:08:18] 	 but it ends up inheriting the BodyContent line-height
[22:08:21] 	 :(
[22:08:47] 	 Not sure how that was missed in this whole process
[22:09:12] 	 might not be inside vector
[22:09:17] 	 but a global one
[22:10:10] 	 True, but we should have overridden it with inherit as well. Too late now I'm afraid. We'll need to beta test it :P
[22:12:17] 	 kaldari: i hope that whoever runs any new experiments will learn from what we're doing here right now (you're probably not the person to blame, but i hope you can pass this off to whoever)
[22:12:31] 	 kaldari: the announcement page will also have to be updated if we're killing the 
 thing, btw
[22:12:38] 	 true
[22:13:11] 	 StevenW: you the guy to ping about this? ^
[22:13:59] * MatmaRex  afk again
[22:15:30] 	 MatmaRex: In the future I think we should make sure that any experiments have developers officially assigned to them and responsible for them (which seems to be the case generally). I think the problem this time is that the designers and product people assume that CSS is easy and doesn't really take dedicated developers to work on :P
[22:16:15] 	 If only they knew how much of a nightmare CSS actually is :)
[22:16:18] 	 well yes, but is' also that I'm not code reviewing what's basiclly a sandbox
[22:17:07] 	 so this only pops up, because i'm only now putting on the review mode. before it was just the 'test as a user' mode
[22:17:21] 	 or rather Matmarex in this case.
[22:17:36] 	 true, more reviewer eyeballs on experiements would be useful
[22:18:44] 	 MatmaRex: If you want to drop the +2 hammer, we can probably get this update pushed out with the typography refresh.
[22:18:46] 	 yes I can update the announcements on the pre thing
[22:18:56] 	 and I think it's fine to merge, if there is no easy fix
[22:19:36] 	 StevenW: Yeah, sounds like the correct way to fix it is going to be complicated
[22:19:47] 	 quiddity: ^ we're going to go and remove the pre change. It's really minor and MatmaRex et al were correct to bring up some issues with it.
[22:20:03] 	 It's not a big deal. It was a "this seems like an easy fix to include". If it's not, that's fine.
[22:20:20] 	 Do you want me to merge, or do you want jdlrobson to?
[22:20:26] 	 kaldari: ^
[22:20:28] 	 go for it
[22:20:42] 	 I want to put in on the SWAT team radar ASAP
[22:21:28] 	 anyway, there are many super small things
[22:21:33] 	 i'm happy to merge
[22:21:37] 	 just send me the link here
[22:21:41] 	 Done.
[22:22:13] 	 i mean, the .off() without scoping that I noticed in hovercards is also very small, hard to notice, but if i'd do a full review on the extension, -2 -2 -2
[22:22:45] 	 but now it's just a beta feature, so i file a bugreport
[22:23:02] 	 and then hopes someone reviews the code before it goes live :D
[22:23:20] 	 the thing is pretty buggy. 
[22:23:31] 	 yeh very very :-)
[22:23:42] 	 but hey, first release. I was more concerned about the potential performance issue.
[22:23:48] 	 StevenW: thedj it would be great to get some lessons learnt from this beta feature deployment
[22:23:58] 	 Maybe we should start a wiki page "Releasing a beta feature"
[22:24:04] 	 jdlrobson: I want to do a public retrospective after the launch
[22:24:11] 	 with a Talk page for community input
[22:24:18] 	 StevenW: That would be a great idea - you gonna use a flow board?
[22:24:26] 	 No way. 
[22:24:31] 	 Whyz noz?
[22:24:40] 	 csteipp, the tarballs are produced but we're having an issue with the extension versions again. hexmode is investigating.
[22:24:56] 	 Speaking of Flow though... good news is they removed their own font overrides mostly, so it will pick up the typography refresh from Vector core.
[22:24:57] 	 i just witnessed a flow retrospective using flow and thought it was a really good tool for collecting what went well / what didn't
[22:25:21] 	 mebbe
[22:25:21] 	 mglaser: cool, thanks for the update
[22:25:44] 	 jdlrobson: I am all for dogfooding but not if we want to collect feedback from end users who may be grumpy about beta features rollout to begin with
[22:25:50] 	 seems like a recipe to increase frustration.
[22:26:22] 	 ok anyway important thing is i think a retrospective would be useful
[22:26:31] 	 but it would be useful to start documenting this process
[22:26:46] 	 i still think that i have way too little text in flow.
[22:28:10] 	 greg-g: FYI: https://wikitech.wikimedia.org/w/index.php?title=Deployments&diff=107778&oldid=107775
[22:28:15] 	 it's interesting, with flow on hovercards talk, i notice i'm just scrolling all over the place, because i don't know where 'new' comments are.
[22:28:32] 	 Already mentioned it to Ori in case he's doing the SWAT deploy
[22:28:48] 	 i'm reading bits and the giong 'wait, i alaready read that last time.. scroll scroll. did i read this ?'
[22:28:55] 	 big swat day
[22:29:35] 	 kaldari: wow, no movement on the bug for almost a year then BAM, fixed.
[22:30:22] 	 greg-g: We aim to please
[22:30:46] 	 :)
[22:31:39] 	 kaldari: jdlrobson: thank you both for responding so quickly, btw :)
[22:38:37] 	 thedj, moar onwiki feedback pls and thank you!
[22:39:16] 	 moar, i don't have moar time :D
[22:45:08] 	 StevenW: did you see Edokter's thumb gadget ?
[22:46:56] 	 thedj, yup, because I pinged him in the Enwiki thread about it ;)   https://en.wikipedia.org/wiki/Wikipedia:VPT#New_image_thumb_design
[22:47:20] 	 thedj: yeah
[22:47:39] 	 that's part of why I didn't wanted to hold off on including the thumbnail designs in the typography release
[22:48:11] 	 I am honestly not a fan of the drop shadow approach. I think it makes the images pop out too much. But in any case the issue isn't settled and needs more experimentation.
[22:49:05] 	 There is also an issue James_F|Away brought up: which is if we remove borders on the default thumb style... why do we have frame forcing still in the markup? Should we change/simplify markup too to reflect a simpler thumb style?
[22:50:06] 	 (and galleries)
[22:52:12] 	 quiddity: yup
[22:53:38] 	 kaldari: want to self-reply to https://bugzilla.wikimedia.org/show_bug.cgi?id=260#c32 ? (i can try to summarize what we talked about here if you don't)
[22:54:08] 	 yeah, I can update that. Thanks for reminding me
[22:55:28] 	 greg-g, If the images were in the public domain yet, we should've called them "Flit deploys"   https://www.google.com/search?q=Flit+seuss&tbm=isch
[22:56:28] 	 quiddity: hah
[22:56:52] 	 kaldari: thedj: more line-height-related comments on https://gerrit.wikimedia.org/r/#/c/121419/5 :(
[22:57:08] 	 if only anything would be (naturally) entering the PD in the US ever again
[22:57:08] 	 responding
[22:57:30] 	 i think i'll be off for the night for now