913 karma · joined April 26, 2011

> Are we really that afraid of hurting someone’s feelings…
I don’t do it to save peoples’ feelings: I do it because there are two separate use cases for determining the author of something—sometimes I really do not want to blame[1] someone.
1. blame — verb: feel or declare that (someone or something) is responsible for a fault or wrong.
1. http://www.bbc.co.uk/news/entertainment-arts-33198686
2. https://en.m.wikipedia.org/wiki/List_of_English_districts_by...
> Let's assume a reasonable 8mbit connection and 50ms RTT.
This is a huge assumption; you’ll be neglecting almost all of your mobile users there. But! Optimise for your use-case, of course.
If you’re self hosting your fonts I would leave them external, `preload` them, and use the preferred `font-display` mechanism to deal with (or elimiante) FOUT and/or FOIT. That’s your extra connections taken care of, and we’ve moved fonts back off of the critical path :)
I think what we’ve both hit upon here is the fact that browsers need to decide on a standard way of handling FOUT/FOIT. Leaving pages blank for up to 3s (or in Safari’s case, indefinitely) would completely eliminate the need to try and circumvent it by base64 inlining :(
101K 9 Dec 18:30 with.css
99K 9 Dec 18:31 with.min.css
73K 9 Dec 18:31 with.min.css.gz
6.8K 9 Dec 18:30 without.css
5.2K 9 Dec 18:31 without.min.css
1.8K 9 Dec 18:31 without.min.css.gz
Although this might be true:> …72k, which is not much bigger than the CSS without the fonts + the fonts separately.
The issue here is that CSS is a render-blocking resource and fonts are not; ergo you’ve increased render-blocking assets from 1.8K to 73K, meaning the user has to download 4056% more bytes before they get to see anything at all. Base64 encoding assets is usually a huge anti-pattern. You’d be better off moving those fonts back out into separate requests.
I hope this comment is taken in the spirit it’s intended: I like making the internet fast :)
Have a great weekend!
(If you’re interested in further reading, look up anything to do with the critical rendering path.)
Using `display: inline-block;` allows you to manipulate grids with text-level properties (e.g. `text-align: center;` to cause grid items to fill out from the center of the row), and also allows you to use `vertical-align: [top|middle|bottom];` to cause columns to start from different, well, alignments.
[1] https://github.com/csswizardry/csswizardry-grids/blob/master...
This then became the basis for CSS Wizardry Grids: http://csswizardry.com/2013/02/introducing-csswizardry-grids...
I was invited over to their HQ to give a talk late last year and wow. An amazing company, every employee has a huge smile and nothing but great things to say, they have a really great culture, are a very wealthy company, and engineers are given a lot of freedom. Had I not just started working for myself, I would have taken them up on the full-time jobs they offered me!
> I enjoyed your talk on abstracting the grid into it's own layer by adding extra markup.
Thank you very much!
> I was wondering if you've read Grid Systems in Graphic Design?
I haven’t actually, but I’ve always fancied myself a copy. Recommended?
This bit piqued my interest, so I made this: https://bitly.com/13F3dIy