!!c1QfXUgcGY0

(Actual blog URL here)
On my screen, pixel-perfect alignment is achieved with .permalink {margin-top: -26px}
On chrome, messing with the styles on elements that only become visible onhover is much easier if you set it to always hover:

Now, that’s what you asked for, but I can’t help pointing out the hidden question: is this design a good idea?
Well.
Twee slide-out animations as beloved by theme designers are impossible to use on touchscreen devices, since you can’t hover, obviously. So this theme can’t be used on a tablet.
Additionally, hiding important stuff behind a user interaction makes it impossible to scan quickly. This theme hides post time, note count, and tags, so you can’t read any of that at a glance, which is annoying. Easy, solution: just rip out all the :hover rules entirely, and make the permalink div visible by default.
I made this edit, as well as a bunch of other really opinionated ones (It loads all of JQuery to do a onload CSS fade: I removed that. The theme hides the scrollbar by setting it the the same color as the background: I removed that. You can also change all the 0px attributes to 0, I didn’t do that because I didn’t want to make a bunch of edits and accidentally break something.) in this pastebin.

(Actual blog URL here)

On my screen, pixel-perfect alignment is achieved with .permalink {margin-top: -26px}

On chrome, messing with the styles on elements that only become visible onhover is much easier if you set it to always hover:

image

Now, that’s what you asked for, but I can’t help pointing out the hidden question: is this design a good idea?

Well.

Twee slide-out animations as beloved by theme designers are impossible to use on touchscreen devices, since you can’t hover, obviously. So this theme can’t be used on a tablet.

Additionally, hiding important stuff behind a user interaction makes it impossible to scan quickly. This theme hides post time, note count, and tags, so you can’t read any of that at a glance, which is annoying. Easy, solution: just rip out all the :hover rules entirely, and make the permalink div visible by default.

I made this edit, as well as a bunch of other really opinionated ones (It loads all of JQuery to do a onload CSS fade: I removed that. The theme hides the scrollbar by setting it the the same color as the background: I removed that. You can also change all the 0px attributes to 0, I didn’t do that because I didn’t want to make a bunch of edits and accidentally break something.) in this pastebin.

7:19pm | author:
Filed under:css

Anonymous said: There's a theme I really like but it comes with faded tumblr ui by default! how would i fiddle with the "html" tab to unfade the ui?

“An introduction to CSS”

  h1 { color: red }

A CSS rule consists of two main parts: selector (‘h1’) and declaration (‘color: red’). In HTML, element names are case-insensitive so ‘h1’ works just as well as ‘H1’. The declaration has two parts: property name (‘color’) and property value (‘red’).

We’re looking for the selector that targets the tumblr controls. There’s a number of different ways you could select that element, but the theme designer probably used the element’s id attribute, which is tumblr_controls.

So, open the theme source, search for #tumblr_controls, (CSS uses # to select elements by ID) and delete that CSS rule.

6:12pm | author:
(Notes:3)
Filed under:css html

A couple days ago, thepunchlineismachismo.com got a redesign. Let’s take a quick look at it.

Firstly, it loads 186 files, consuming 2.8MiB of transfer in the process. (10 CSS files, 15 javascript files) That’s a lot of files.

DOMContentLoaded fires at 3.2s, onload at 6.27s. (Eyeballing Google’s online PageSpeed waterfall graph puts it at about 2s and 2.9s, respectively.) Considering that all of the content on this page is just a single jpeg, that’s slow.

Why is it so slow? Let’s see:

The following images are resized in HTML or CSS. Serving scaled images could save 728.7KiB (64% reduction).

Compressing the following resources with gzip could reduce their transfer size by 162.5KiB (70% reduction).

My perennial bugaboo, resource caching, strikes yet again. The list is greatly abridged to save space: of the 186 files loaded, almost none are cached.

The following cacheable resources have a short freshness lifetime. Specify an expiration at least one week in the future for the following resources:

Unoptimized images? You bet your ass:

Optimizing the following images could reduce their size by 381.9KiB (24% reduction).

The usual small-file overhead is in evidence: next-bar.png is a 2,888 byte PNG with a 2,639 byte color profile, which makes the metainformation nearly 18 times larger than the actual image.

How’s the CSS? Well…

image

1,545 unused rules. Some great laughs in there, too:

@font-face {
  font-family: 'Open Sans';
  font-weight: 400;
  src: local('Open Sans'), local('OpenSans'), url(http://themes.googleusercontent.com/static/fonts/opensans/v6/cJZKeOuBrn4kERxqtaUH3T8E0i7KZn-EPnyo3HZu7kw.woff) format('woff');
}
@font-face {
  font-family: 'Open Sans';
  font-weight: 600;
  src: local('Open Sans Semibold'), local('OpenSans-Semibold'), url(http://themes.googleusercontent.com/static/fonts/opensans/v6/MTP_ySUJH_bn48VBG8sNSnhCUOGz7vYGh680lGh-uXM.woff) format('woff');
}
@font-face {
  font-family: 'Open Sans';
  font-weight: 700;
  src: local('Open Sans Bold'), local('OpenSans-Bold'), url(http://themes.googleusercontent.com/static/fonts/opensans/v6/k3k702ZOKiLJc3WVjuplzHhCUOGz7vYGh680lGh-uXM.woff) format('woff');
}

This loads three copies of Open Sans at three different typeface weights, at 30 kilobytes each, but only actually uses weight 700. And it’s just used to style header elements, too. Here’s the difference between Open Sans and the default sans font on my machine:

image

image

Worth 90 kilobytes, you think?

Here’s the entire contents of style.css:

/*
Theme Name:     Easel-Manly
Theme URI:      http://thepunchlineismachismo.com/
Description:    ComicEasel child theme for Manly Guys Doing Manly Things.
Author:         Jetha Chan
Author URI:     http://developersatlarge.com/
Template:       easel
Version:        0.1.0
*/

@import url("../easel/style.css");
@import url("lessgen.css");

Ah, @import, the CSS antifeature that’s never, ever a good idea. Every single @import forces another HTTP request, which blocks page rendering, since the browser can’t paint anything without loading all the CSS. @import can slow down page load 2x-5x, depending on how stupidly you use it.

Why do I keep seeing this on Wordpress themes? Does it not let you do SASS-style inlining?

6:31am | author:
CSS disasters: 01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37.
Some notes: (CSS reformatted for clarity)
.entry {width: 250px}
The default width of all tumblr themes, as well as the dashboard itself, is 500 pixels, which was established back in 2007. On modern monitors, six years later, this is pretty cramped. But in case 500 pixels isn’t narrow enough for you, this theme uses a content column that’s 250 pixels wide.
Why?
Who knows.
.entry {font-size: 11px}
Commandment #1: Do not make the font size smaller than default.
.entry {
  background-color: #2b2828;
  color: #888888;
}
Commandment #2: Do not use unreadable color combinations
Not as bad as some, but this still results in a contrast ratio of 4.12:1, which is Not Good Enough.

CSS disasters: 01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37.

Some notes: (CSS reformatted for clarity)

.entry {width: 250px}

The default width of all tumblr themes, as well as the dashboard itself, is 500 pixels, which was established back in 2007. On modern monitors, six years later, this is pretty cramped. But in case 500 pixels isn’t narrow enough for you, this theme uses a content column that’s 250 pixels wide.

Why?

Who knows.

.entry {font-size: 11px}

Commandment #1: Do not make the font size smaller than default.

.entry {
  background-color: #2b2828;
  color: #888888;
}

Commandment #2: Do not use unreadable color combinations

Not as bad as some, but this still results in a contrast ratio of 4.12:1, which is Not Good Enough.

1:28pm | author:
(Notes:5)
Filed under:html css CSS disasters

How to change the link text color in your theme

1.) Hi subterran.

2.) Contrast on link text isn’t nearly as important as contrast on main body text— obviously you’ll never have to read long stretches of link text.

3.) You can just switch themes. The transaction cost of changing themes is a lot lower than most people think, and you can always switch back.

4.) Well made themes will expose link color as a user-configurable option.

5.) You don’t need to hire a web developer to change link color, you can just DIY.

Both Firefox and Chrome have an element inspector, which allows you to examine the DOM of a page. Just right click on a link, select “inspect element” and boom,

Here it’s telling us that the operational CSS selector is .post .sidebar a {}, overriding a{}, and is setting the color to rgb(106, 0, 106). Fiddle with the color in the element inspector, then once you find a value you like, change it in your theme’s source code.

(99 times out of 100, the selector will be a{}, I picked a complicated instance for this example.)

9:37am | author:
(Notes:4)
Filed under:HTML CSS tumblr

"Profiling CSS for fun and profit"

  1. The fastest rule is the one that doesn’t exist. There’s a common strategy to combine stylesheet “modules” into one file for production. This makes for one big collection of rules, where some (lots) of them are likely not used by particular part of the site/application. Getting rid of unused rules is one of the best things your can do to optimize CSS performance, as there’s less matching to be done in the first place. There are certain benefits of having one big file, of course, such as the reduced number of requests. But it should be possible to optimize at least critical parts of the app, by including only relevant styles.

    This isn’t a new discovery by any means. Page Speed has always been warning against this. However, I was really surprised to see just how much this could really affect the rendering time. In my case, I shaved ~200-300ms of selector matching — according to Opera profiler — just by getting rid of unused CSS rules. Layout and paint times went down as well.

1:58pm | author:
(Notes:1)
Filed under:CSS
CSS disasters: 01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36.
Some notes: (CSS reformatted for clarity)
<!-- Custom Tumblr theme made by Fugiman for Octopimp -->
Ah, fugiman. And you were doing so well.
Let’s just get this out of the way first: it’s better than his previous effort, but it’s still ugly. Just godawful. It’s hard to know who to blame, precisely. Let’s take a tour of the code.




This is a doozy of a layout mistake. The problem is this rule:
.post-title {width:500px}
Change 500px to 400px, and it doesn’t happen anymore.
* {  margin: 0px;  padding: 0px;}
Still using the universal reset, I see.
if(location.pathname == "/ask" && false) {
$("#post- .post-footer").html("As an ongoing part of Operation Troll Octopimp, Anonymous asks have been turned off. Apologies for the inconvience, and let's see how long it takes him to realize! -Fugiman");
}
<!-- Just for funzies code. Remove before release
<script type="text/javascript">
	(function(file) {
			var myAudio = new Audio(file); 
			if (typeof myAudio.loop == 'boolean') {
				myAudio.loop = true;
			} else {
				myAudio.addEventListener('ended', function() {
					this.load();
					this.play();
					console.log("Looping...",this.buffered.start(0),this.buffered.end(0),this.seekable.start(0),this.seekable.end(0));
				}, false);
			}
		//myAudio.play();
	})('http://fugiman.com/octopimp/annoying.webm');
</script> -->
That’s professional.
blockquote {
  padding: 10px;
  margin: 5px;
}
The single-value margin/padding shorthand adds margin on all four sides of a block element, as you’d expect. But on Tumblr, where nested blockquotes are very common as the result of long reblog chains, you almost always don’t want to set margin-right, which is mostly useless, and only serves to crunch the deepest blockquote into a narrow single-word column of text. That’s bad. You don’t want that.
	    #header {
    text-shadow: #000000 0px 0px 10px,
		    #000000 0px 0px 10px,
	    #000000 0px 0px 10px,
	    #000000 0px 0px 10px,
		    #000000 0px 0px 10px;
}
Wow, that’s a wacky indentation style you got there. Zero values don’t need units, and you can use the color shorthand here, so a better version is,
#header {
text-shadow:#000 0 0 10px,
            #000 0 0 10px,
            #000 0 0 10px,
            #000 0 0 10px,
            #000 0 0 10px;
}
(Style quibbling: I’d use black here instead of #000. I mix up #000 and #FFF all the time, and black is only one byte longer.)
(The attribute is repeated to, not a joke, make the shadow darker. This is official W3C-endorsed best practices, and is due to the fact that text-shadow, unlike box-shadow, doesn’t have a spread attribute. Box shadows will always be convex polygons, while a text-shadow is concave, so the spread value wouldn’t be well-defined.)
.block-link{color: #000000 !important}
Whoops, someone left an !important directive in production code!
#header a {
  text-decoration: none;
}

.post-meta a {
  text-decoration: none;
}

.tags a {
  text-decoration: none;
}
These can all be combined into a single selector.
<meta name="image:Background" content="http://static.tumblr.com/wsidxpn/CLVm63xfi/kamen_rider_fourze_alex.png" />
<meta name="text:Transparency" content="80" />
Now the problem of attribution arises. The giant background image (896 kilobytes!) and semitransparent main column, creating yet another readability catastrophe, (Transparency compositing is also dog-slow, which makes scrolling sluggish and unresponsive) are both user-visible settings. Who set them? It’s impossible to know.
Also, I thought we stopped using gradients for backgrounds back in Hypercard.

CSS disasters: 01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36.

Some notes: (CSS reformatted for clarity)

<!-- Custom Tumblr theme made by Fugiman for Octopimp -->

Ah, fugiman. And you were doing so well.

Let’s just get this out of the way first: it’s better than his previous effort, but it’s still ugly. Just godawful. It’s hard to know who to blame, precisely. Let’s take a tour of the code.

This is a doozy of a layout mistake. The problem is this rule:

.post-title {width:500px}

Change 500px to 400px, and it doesn’t happen anymore.

* {
margin: 0px;
padding: 0px;
}

Still using the universal reset, I see.

if(location.pathname == "/ask" && false) {
$("#post- .post-footer").html("As an ongoing part of Operation Troll Octopimp, Anonymous asks have been turned off. Apologies for the inconvience, and let's see how long it takes him to realize! -Fugiman");
}
<!-- Just for funzies code. Remove before release
<script type="text/javascript">
	(function(file) {
			var myAudio = new Audio(file); 
			if (typeof myAudio.loop == 'boolean') {
				myAudio.loop = true;
			} else {
				myAudio.addEventListener('ended', function() {
					this.load();
					this.play();
					console.log("Looping...",this.buffered.start(0),this.buffered.end(0),this.seekable.start(0),this.seekable.end(0));
				}, false);
			}
		//myAudio.play();
	})('http://fugiman.com/octopimp/annoying.webm');
</script> -->

That’s professional.

blockquote {
  padding: 10px;
  margin: 5px;
}

The single-value margin/padding shorthand adds margin on all four sides of a block element, as you’d expect. But on Tumblr, where nested blockquotes are very common as the result of long reblog chains, you almost always don’t want to set margin-right, which is mostly useless, and only serves to crunch the deepest blockquote into a narrow single-word column of text. That’s bad. You don’t want that.

	    #header {
    text-shadow: #000000 0px 0px 10px,
		    #000000 0px 0px 10px,
	    #000000 0px 0px 10px,
	    #000000 0px 0px 10px,
		    #000000 0px 0px 10px;
}

Wow, that’s a wacky indentation style you got there. Zero values don’t need units, and you can use the color shorthand here, so a better version is,

#header {
text-shadow:#000 0 0 10px,
            #000 0 0 10px,
            #000 0 0 10px,
            #000 0 0 10px,
            #000 0 0 10px;
}

(Style quibbling: I’d use black here instead of #000. I mix up #000 and #FFF all the time, and black is only one byte longer.)

(The attribute is repeated to, not a joke, make the shadow darker. This is official W3C-endorsed best practices, and is due to the fact that text-shadow, unlike box-shadow, doesn’t have a spread attribute. Box shadows will always be convex polygons, while a text-shadow is concave, so the spread value wouldn’t be well-defined.)

.block-link{color: #000000 !important}

Whoops, someone left an !important directive in production code!

#header a {
  text-decoration: none;
}

.post-meta a {
  text-decoration: none;
}

.tags a {
  text-decoration: none;
}

These can all be combined into a single selector.

<meta name="image:Background" content="http://static.tumblr.com/wsidxpn/CLVm63xfi/kamen_rider_fourze_alex.png" />
<meta name="text:Transparency" content="80" />

Now the problem of attribution arises. The giant background image (896 kilobytes!) and semitransparent main column, creating yet another readability catastrophe, (Transparency compositing is also dog-slow, which makes scrolling sluggish and unresponsive) are both user-visible settings. Who set them? It’s impossible to know.

Also, I thought we stopped using gradients for backgrounds back in Hypercard.

6:10pm | author:
Drop-down list navigation needs to die.
It is the wrong UI metaphor. Just use some links! You&#8217;re making a user action that can be done with one click, into a user action that requires one precise click, a precise mouse movement, and another click. Don&#8217;t do that.

Drop-down list navigation needs to die.

It is the wrong UI metaphor. Just use some links! You’re making a user action that can be done with one click, into a user action that requires one precise click, a precise mouse movement, and another click. Don’t do that.

5:08pm | author:

Dragons must have better eyesight than humans.
(h/t zarla)
(Uh oh hope endofunctor doesn&#8217;t unfollow me for this post either)
EDIT:
03:23 &lt;yaoi_prophet&gt; c1QfXUgcGY0: i will if you keep up the passive-aggressive sniping hth
03:23 &lt;c1QfXUgcGY0&gt; :3

Dragons must have better eyesight than humans.

(h/t zarla)

(Uh oh hope endofunctor doesn’t unfollow me for this post either)

EDIT:

03:23 <yaoi_prophet> c1QfXUgcGY0: i will if you keep up the passive-aggressive sniping hth
03:23 <c1QfXUgcGY0> :3

12:22am | author:
(Notes:1)
Filed under:CSS CSS disasters
CSS disasters: 01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32.
Some notes: (CSS reformatted for clarity)
That&#8217;s not just a result of a weird window size, it looks like that no matter the viewport:
#sidebar {
  position: fixed !important;
  margin-top: 119px;
  margin-left: 134px;
  width: 285px;
}

#posts {
  margin-left: 220px;
  width: 504px;
}
Not sure how this got past testing, besides &#8220;the author did no testing&#8221;.
But wait, it gets worse.
document.title = scrol;
Title scrolling. But wait, it gets worse.
&lt;script type="text/javascript" src="http://scm.hypster.com/script.php"&gt;
Autoplaying music. But wait, it gets worse.
document.onmousedown=IE;document.onmouseup=NS;document.oncontextmenu=new Function("return false");
Right click disable script, that hoary old standby loved by people who don&#8217;t understand computers. It&#8217;s extra stupid here, since reblogging is, uh, a pretty big thing on Tumblr.
(h/t: thelatenightlife)

CSS disasters01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32.

Some notes: (CSS reformatted for clarity)

That’s not just a result of a weird window size, it looks like that no matter the viewport:

#sidebar {
  position: fixed !important;
  margin-top: 119px;
  margin-left: 134px;
  width: 285px;
}

#posts {
  margin-left: 220px;
  width: 504px;
}

Not sure how this got past testing, besides “the author did no testing”.

But wait, it gets worse.

document.title = scrol;

Title scrolling. But wait, it gets worse.

<script type="text/javascript" src="http://scm.hypster.com/script.php">

Autoplaying music. But wait, it gets worse.

document.onmousedown=IE;document.onmouseup=NS;document.oncontextmenu=new Function("return false");

Right click disable script, that hoary old standby loved by people who don’t understand computers. It’s extra stupid here, since reblogging is, uh, a pretty big thing on Tumblr.

(h/t: thelatenightlife)

11:52am | author:
(Notes:5)
Filed under:CSS CSS disasters
CSS disasters: 01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31.
Some notes: (CSS reformatted for clarity)
.entries {
  font-size: 11px;
  font-family: lobstertwo-regular;
}

(h/t ipgd)

CSS disasters01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31.

Some notes: (CSS reformatted for clarity)

.entries {
  font-size: 11px;
  font-family: lobstertwo-regular;
}

(h/t ipgd)

11:36am | author:

CSS Disasters #30

gilfaethwy:

sollux:

c1qfxugcgy0:

CSS disasters: 01,02,03,04,05,06,07,08,09,10,11,12,13,14,15,16,17,18,19,20,21, 22.

Some notes: (CSS reformatted for clarity)

hoo ha hey there i’m reblogging this from you so that you can directly see that you spent (i’m going to guess here) more than 10 minutes picking apart someone’s code   for… what purpose again?? like honestly i’m not being hostile but stop and think. think about what you just honestly did. “css disasters” like you’ve got to be kidding me. you are the epitome of a dweeb. and if you try and respond to this telling me that you’re more of an intellectual than i am just keep in mind i dont talk to haters 

Yeah I think there’s a big difference between just being helpful with coding work and… being a jerk about it since it was never asked for…

Not everyone’s looking for coding perfection anyway. It works? It works. You don’t see me complaining that that not all people properly trim their hedges and are now an eyesore to me so it’s

Sort of foolish to go out of your way to try to ‘help’ other people since that just comes across as trying to look superior even if that was not the intent.

EDIT: gilfaethwy has switched to a theme that is marginally less bad. The rest of this post is of historical interest only.

CSS disasters01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30.

Some notes: (CSS reformatted for clarity)

#content {opacity: 0.65}

You’re… making the text semitransparent? No.

Don’t use unreadable color combinations.

Don’t use image backgrounds under text.

Here’s what it looks like with that one single CSS rule removed:

The text is a little too small, (12px) and yellow on white is not brilliant, but it’s much better than before.

3:18am | author:
CSS disasters: 01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29.
Some notes: (CSS reformatted for clarity)
body  {color:#777777}
a:link {color:#1D6324}
This page has a really unfortunate choice of background, in clear violation of Commandment 2. But images are tricky to cleanly quantify, since they don&#8217;t have a single color. The average color can be fairly easily approximated, though. Just take the image:

(This is a 68.28KB .gif, by the way. Which intuitively seems completely bonkers: but it&#8217;s palletized, and only uses 8 colors. Converting it to .png and running it through optipng -o7 results in a 72KB file. The .jpeg version is 109KB.)
Then blur the shit out of it:

This 219 byte PNG is a single pixel of #2B3F32. We are now free to compare colors.

This is a bad theme. The prosecution rests.
It is, of course, worse than this. Averaging the entire image discounts background detail, which can greatly complicate reading. Consider the pathological case:* 

Averaging the background image gives us #D9D9D9, which is a very light shade of gray, and scores an excellent 13.88:1 contrast ratio&#8230; yet is completely unreadable.
You could imagine writing a contrast checker which would take into account visible detail, except the use case for such a utility would just be reviewing shitty Tumblr themes, so it&#8217;s probably not worth the development time.
*:(h/t foldingcookie, on the irc, who is better at remembering words than me)

CSS disasters01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29.

Some notes: (CSS reformatted for clarity)

body  {color:#777777}
a:link {color:#1D6324}

This page has a really unfortunate choice of background, in clear violation of Commandment 2. But images are tricky to cleanly quantify, since they don’t have a single color. The average color can be fairly easily approximated, though. Just take the image:

(This is a 68.28KB .gif, by the way. Which intuitively seems completely bonkers: but it’s palletized, and only uses 8 colors. Converting it to .png and running it through optipng -o7 results in a 72KB file. The .jpeg version is 109KB.)

Then blur the shit out of it:

This 219 byte PNG is a single pixel of #2B3F32. We are now free to compare colors.

This is a bad theme. The prosecution rests.

It is, of course, worse than this. Averaging the entire image discounts background detail, which can greatly complicate reading. Consider the pathological case:* 

Averaging the background image gives us #D9D9D9, which is a very light shade of gray, and scores an excellent 13.88:1 contrast ratio… yet is completely unreadable.

You could imagine writing a contrast checker which would take into account visible detail, except the use case for such a utility would just be reviewing shitty Tumblr themes, so it’s probably not worth the development time.

*:(h/t foldingcookie, on the irc, who is better at remembering words than me)

11:57pm | author:

12 things your theme should never do

I’m tired of repeating myself, so here’s a list of the 12 things you should never do in your tumblr theme.

1.) Don’t make the body text smaller than default.

W3 Consortium QA Tips, 2003/07/30:

A certain trend among designers, believing that small text gives a Web page a sleek appearance and provides more space per “page” for actual content, sometimes results in the use of unreasonably small font sizes.

Unfortunately, this does not go well with the diversity of platforms used to access Web pages, from portable devices with tiny screens to projection devices hooked to computers. And even within a specific platform, text settings may vary.

The problem here is a basic usability and accessibility issue: a good design should look good without requiring the user to enlarge or reduce the text size.

The default font size is 16px. If you override the standard font size, and make it smaller, you are making a mistake.

There are certain decorative elements which can use smaller text, sure, that’s fine. But making all the text on the page small is a mistake. Don’t do it.

CSS Disaster posts: #1, #2, #3, #9, #15, #18, #19, #22, #24,

2.) Don’t use unreadable color combinations.

ipgd, 2012/1/11:

[Do not] have a theme with transparent text boxes that overlays some obnoxiously patterned background so everything is unfuckingreadable, seriously that shit is neither kawaii nor kakkoii choose your fucking themes to be r e a d a b l e so people can READ THEM, because that is why you have A FUCKING BLOG, so that losers can look at this dumb shit you have deluded yourself into believing anyone else cares about and READ IT,

Dark gray on light gray is bad. Dark red on light red is bad. You want contrast, otherwise you can’t read the text.

There’s a contrast calculator which can give you objective numbers on just how bad a particular color combo is.

CSS Disaster posts: #5, #NA, #13, #14, #15, #19,

3.) Don’t scale images in software.

The rule of thumb with image scaling is that when you use it to make big images smaller, then you’re throwing away data that you spent time to transmit over the network; and when you use it to make small images bigger, then you just have a blurry mess. It has some uses, so it’s not a “never do this thing”, but if you ever write a theme that scales all _500 images up to 600px, then you are making another mistake. Use max-width or min-width instead.

CSS Disaster posts: #21, #22.

4.) Don’t screw up nested <blockquotes>.

Nested blockquotes aren’t common on the greater web, and they’re not in the standard set of example posts in Tumblr’s theme preview page, but long reblog chains are very, verycommonin everyday use by average Tumblr users. If your CSS reset does * {margin: 0}, then don’t forget to set 20 pixels of margin-left for blockquotes, or else it will be impossible to see who’s saying what.

CSS Disaster posts: #17, #26.

5.) Put the home link in the top left.

!!c1QfXUgcGY0, 2011/05/30:

The Web is a fairly mature platform, which means certain conventions have emerged, and unless you want everyone to hate your fucking guts, you have to respect those conventions. One of those conventions is to put the top level, or “home” link, up, and to the left. Up, and to the left. Up, and to the left.

Always. Always always always.

CSS Disaster posts: #25.

6.) Never move the Tumblr controls.

!!c1QfXUgcGY0, 2011/11/29:

The Principle Of Least Surprise is the absolute bedrock foundation of UI design. It’s the First Commandment: Least Surprise is the Lord your God, you shall follow no other God but him.

Never move the Tumblr controls. Never fade them out, or in any way obscure them. Make no CSS rule that targets their iframe, or any way violates their sanctity.

All these other elements are yours to style— except the Tumblr controls. Attempt no landing there.

CSS Disaster posts: #18, #22.

7.) Left is older, right is newer.

Pagination links are one of those bikeshedding arguments which spawn pages and pages of circular arguments. Screw those nerds, because there’s only One True Way to do it: older posts are viewed by clicking a link that points to the left, newer posts are viewed by clicking a link that points to the right.

8.) No autoplaying music, or sound of any kind.

Tumblr support, 2012:

Automatically playing music on your blog is incredibly tacky and not recommended.

CSS Disaster posts: all of them.

9.) No novelties.

ipgd, 2012/1/11:

[Do not] change the fucking mouse cursor, no stop this is dumb nobody thinks those little trailing pink sparkles is cool, it makes you look like a 13 year old girl, and if you are actually a 13 year old girl you should be working harder than the rest of us not to look like a 13 year old girl because there is absolutely nothing about 13 year old girls that is cool unless you are a pedophile i guess but somehow i doubt that is the target demographic,

In general, novelty features are bad. Everybody hates them. Javascript has its place, but if you’re using it to add sparkles, animate the page title, disable right click, or obscure the page text with falling rainbow stars, then stop. Do not. Step away from the computer.

CSS Disaster posts: #3, #24.


CSS is generally a less than powerful language, which is why SASS and LESS exist. But no language is so inexpressive that it can’t be used to shoot holes in things, and you’ll find yourself blowing your own foot off a lot less often if you avoid certain language features completely.

10.) Don’t touch the mouse cursor.

You can change the mouse cursor with cursor.

Don’t.

There’s no reason to do that, ever.

CSS Disaster posts: #2, #7, #11, #22, #23.

11.) Don’t use text-transform.

Never.

CSS Disaster posts: #16

12.) Don’t use -webkit-scrollbar.

This is only ever used to make the scrollbar harder to use. You don’t want to do that.

CSS Disaster posts: #7, #11.

There, now that I have enumerated a list of things you shouldn’t do, I fully expect to never have to do a CSS Disasters post again.

11:13pm | author:

jiontwings:

Im going to stop postin my quality art on tumblr

im kinda sick of having my doodle gettin more notes than stuff i worked on for than an hour
its9:35am but im goin back to sleep
thanks for lettin me know my effort is worth shit
thankbye

EDIT: Jiontwings has switched to a theme that is not terrible. The rest of this post is of historical interest only.


CSS disasters: 01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28

Some notes: (CSS reformatted for clarity)

This theme has no post links.

The date isn’t a permlink. The notes aren’t a permlink. There’s no title on this post, so no link there.

The only way I could get to this individual post’s page is by going into the archive to find it.

I know I say this a lot, but man, the mind boggles. Who thought that was a good idea?

#content {margin_top:40px;}

#posts {margin_top:80px;}

 .date{text_align:right;}

Syntax error. It’s margin-top, not margin_top.

.post-meta {
	width: 147px;
	display: inline;
}

What? Width is a block property, it’s not supposed to be used on an inline style. It works anyway, with the browser Doing What You Mean, but it’s still an error.

#container {margin: 100px auto 0 auto;}

You can use the margin shorthand to write this as margin: 100px auto 0;

Speaking to the actual content of the post, this seems like a classic cost/value confusion. Just because it took more time to make does not mean it’s better.

(Source: jionttt)

5:40am | author: