Claude Code Delivers Tina Chen's Awesome++ Inc

On a 2560-pixel monitor, the text column of my blog was 867 pixels wide. Not 33%. Not the result of a media query. Eight hundred and sixty-seven pixels, at every window size, forever. Here is how I found the number, and what a fourteen-year-old Blogger template teaches about how layouts get stuck.

The template is Awesome Inc., designed by Tina Chen and shipped with Blogger since around 2011. If your blog is more than a few years old there is a decent chance you are running it, or one of its siblings, and a decent chance you have already tried to widen it from the Template Designer and failed. The reason you failed is interesting, so let's do the archaeology properly.

Finding the number

Start by not opening dev tools. Open the template XML and search it for every declaration that sets a width. You are looking for one specific thing: a length that is not a percentage. A fluid layout that feels cramped is a padding problem. A layout that is exactly as wide on a laptop as on a 4K display is a hard number, and hard numbers are easy to find.

Three of them, right at the top of the layout block:

the three numbers that decide everything
<b:variable name='content.width'           value='1227px'/>
<b:variable name='main.column.left.width'  value='180px'/>
<b:variable name='main.column.right.width' value='180px'/>

That is the whole mystery, and the arithmetic is not subtle:

RegionSet byWidth
Whole pagecontent.width1227px
Left sidebarmain.column.left.width−180px
Right sidebarmain.column.right.width−180px
Your writingwhatever is left867px

867 pixels is 45% of a 1920px window and 34% of a 2560px one. Everything else on the screen — the black margins on both sides that you assumed were a design choice — is the layout declining to grow.

Before — 1920px window, everything pinned to 1227px
dead
180
post column · 867px
180
dead
346px
← 1227px fixed →
347px
After — post column pinned to 75% of the window instead
180
post column · 75% of window
180
← 75% + 360px, capped at the window →
The sidebars stay fixed. Every pixel the window gains goes to the text.
Lesson 1 · two stylesheets

The Template Designer edits the wrong file

A Blogger template carries two separate stylesheets, and almost nobody knows this until they need it.

<b:skin>

The theme. Colors, fonts, borders, shadows, radii. Its variables are the ones the Template Designer exposes as sliders and swatches. This is the file you have been editing.

<b:template-skin>

The structure. Page width, column widths, the geometry that decides where your text can go. It sits in a second block further down the file, and the Designer's width control writes here — but only within the range Blogger allows, which tops out well short of "as wide as the window".

Both blocks use the same $(variable) interpolation syntax, which is why they look identical and get confused for each other. They are not the same layer. If you are chasing a size problem and you are reading <b:skin>, you are in the wrong half of the file.

Worth knowing: the substitution happens on Blogger's servers, as plain text, before any browser sees the CSS. That means $(...) works in places you might not expect — including inside a calc(). We are about to rely on that.
Lesson 2 · the specificity trap

The full-width background is a decoy

Here is the part that cost me the most time. The template contains this, in the theme block:

html body .content-outer {
  min-width: 0;
  max-width: 100%;
  width: 100%;
}

and then this, in the structure block:

.content-outer, .content-fauxcolumn-outer, .region-inner {
  min-width: 1227px;
  max-width: 1227px;
}

Count the specificity. html body .content-outer is one class plus two elements: 0-1-2. The bare .content-outer is 0-1-0. The first wins, even though the second appears later in the document.

So .content-outer — the outermost wrapper, the one carrying the page background — really is fluid. It stretches edge to edge. But that rule names only .content-outer. The two other selectors in the same block are untouched by it, and one of them is .region-inner, which is the class on header-inner, tabs-inner, main-inner and footer-inner. That is where your words actually live, and it is still nailed to 1227px.

The general lesson: a background that reaches both edges of the screen is not evidence of a fluid layout. It is evidence that one wrapper is fluid. Inspect the element that directly contains the text, not the one that paints behind it. In a template this old, those can be eight divs apart.
Lesson 3 · the fossils

Why there are eleven nested divs

Reading the markup, you pass through content-outer, fauxborder-left, fauxborder-right, content-inner, main-outer, main-fauxborder-left, main-inner, columns, fauxcolumn-center-outer, column-center-outer, column-center-inner before you reach a single word of writing. It looks like madness. It is actually a fossil record of what CSS could not do in 2011.

01
The faux columnsThree columns of unequal content could not be made equal height. So the template paints a second, purely decorative set of full-height divs behind the real ones. That is every fauxcolumn-* you see.
02
The faux bordersborder-radius and box-shadow were unreliable, so rounded edges were assembled from cap-top / cap-bottom / fauxborder-left pieces. Cosmetic scaffolding, load-bearing in the markup.
03
The Holy GrailNo flexbox, no grid. Three columns with the centre one first in source order was a famous puzzle, solved with negative margins.

That third one is still genuinely clever, and it is the mechanism you have to respect when you change the widths:

the negative-margin three-column trick
/* carve out gutters the centre column will not enter */
.main-inner .columns {
  padding-left:  180px;
  padding-right: 180px;
}

/* then drag each sidebar back out into its gutter */
.main-inner .column-left-outer {
  width: 180px;
  right: 100%;
  margin-left: -180px;
}

The centre column is simply "the parent minus its own padding". It never has a width of its own. This matters enormously for the fix: you cannot set the width of the post column directly. You can only set the width of its container, and let the subtraction happen.

Three fossils you can safely ignore

_width: 1227px — the underscore hack. Only IE6 parsed a property with a leading underscore. Inert everywhere since.
_width: expression(...) — IE's dynamic properties, which ran JavaScript from a stylesheet on every reflow. A performance catastrophe, and a security hole. Removed in IE8.
*+html body ... — the star-plus-html hack, which targeted IE7 alone.

They are harmless, so leave them. But do not spend an hour wondering why editing one changed nothing.

Lesson 4 · the floor

min-width is why your phone scrolls sideways

One line, easy to skim past:

body { min-width: 1227px; }

A min-width on body is a promise that the document will never be narrower than that, no matter the viewport. Below 1227px the browser has one option left: a horizontal scrollbar. Every awkward sideways drag on a narrow window traces back to this. When you convert a fixed layout to a fluid one, removing the floor is not optional — a percentage width with a pixel floor underneath it is still a fixed layout, just one that lies to you above a certain size.

The fix

Six lines, in the structure block

Find <b:template-skin>, not <b:skin>. Leave the three b:variable declarations alone — the Template Designer still wants them to be lengths, and we will reuse two of them.

before / after
- body { min-width: $(content.width); }
+ body { min-width: 0; }

  .content-outer, .content-fauxcolumn-outer, .region-inner {
-   min-width: $(content.width);
-   max-width: $(content.width);
+   min-width: 0;
+   width: calc(75% + $(main.column.left.width) + $(main.column.right.width));
+   max-width: 100%;
+   margin-left: auto;
+   margin-right: auto;
    _width: $(content.width);  /* IE6 fossil, left alone */
  }

Reading it line by line:

min-width: 0 — removes the floor, in both places it was set.
calc(75% + 180px + 180px) — the important one. Because the sidebars are fixed and the centre column is the remainder, sizing the container at 75% plus both sidebars makes the post column land at exactly 75% of the window. Every pixel the window gains goes to the text; the sidebars never move.
max-width: 100% — the safety net. Below about 1440px the calc would exceed the viewport, so the cap takes over and the layout narrows gracefully instead of overflowing.
margin-left / right: auto — a fixed-width block was being centred by rules elsewhere; once the width is your own, centre it explicitly rather than inheriting someone else's assumption.
The ambiguity worth naming

"75% of the window" means two different things

This is the part I would have got wrong without stopping to think, and it generalises far beyond Blogger. When someone says a page should be "75% wide", they might mean the whole layout, or they might mean the part they read. With fixed sidebars in play, those are not close to each other.

ReadingDeclarationText on 1920px
The whole page is 75%width: 75%1080px · 56%
The text column is 75%calc(75% + 360px)1440px · 75%

A 360-pixel gap between two readings of the same sentence. When you are handed a percentage, always ask which column it describes before you type it.

One honest caveat. 75% of a 2560px monitor is 1920 pixels of running text, which is roughly 200 characters a line — well past the 65–75 that eyes track comfortably. Wide is right for code listings, tables and screenshots, and punishing for prose. If your posts are mostly words, consider pairing the fluid layout with .post-body { max-width: 90ch; } so the container is generous but the sentences are not. Fluid layout and readable measure are different problems, and you are allowed to solve both.
The method

Five questions for any stuck layout

None of this is specific to Blogger. Any template old enough to have a fixed grid will yield to the same sequence.

01
Find the numberSearch for width declarations and look for one that is not a percentage. A layout identical on every screen is a hard value, and it is usually declared exactly once.
02
Find the layer that sets itThemes and structure often live in separate blocks with separate editors. Confirm you are editing the one that owns geometry.
03
Find the element that holds the textNot the one painting the background. Compare specificity between the rules that touch each — the decoy is usually a more specific selector matching an outer wrapper only.
04
Check for a floorA min-width anywhere on the ancestor chain will quietly defeat every percentage you write.
05
Decide which column your percentage describesThen write the calc() that produces it, rather than the one that is easiest to type.

Six lines of CSS, and the window is finally mine. The 1227 was not a design decision anyone made about my writing — it was a default from 2011 that outlived the browsers it was compensating for. Most stuck layouts are that: not a choice, just a number nobody has questioned in a while.

— fin —

Comments

Popular posts from this blog

How Should You Put Your Text in a Box?

Click to Copy with Toast and No Alert Pop Up (thanks chatGPT and Sam Altman)