In February 2007 this site published a tutorial called “How to Make Square Corners with CSS.” It promised an “epic journey of compassion and liberty that embodies the semantic markup movement in modern web design,” followed by a “coveted 84 step process.” It was a joke. The real instruction for square corners was, and remains, to write nothing at all.
The joke worked because the opposite problem was genuinely enormous. Rounded corners in 2007 cost you nested elements, sprite images or a JavaScript library, and the technique that made them possible had arrived only four years earlier: A List Apart published Doug Bowman’s Sliding Doors of CSS on 20 October 2003. Before that, per a later retrospective, “literally no one had figured out how to make rounded tabs using CSS.” Unprefixed `border-radius` did not work across the major browsers until around 2011, when IE9, Firefox 4, Safari 5 and Chrome 4 all supported it. That is an eight-year window in which a curve on a box was an engineering problem and a right angle was free.
Here is what the joke was actually pointing at, and what happened to it.
What rounded corners actually cost
Three approaches dominated, and each one taxed you differently.

Corner images. Four small graphics, one per corner, positioned by four extra elements or by multiple backgrounds. Change the box colour and you regenerate all four. Change the radius and you regenerate all four. A member of the SitePoint forums describing their default instinct as late as 2011: “Normally I would make up image upon image and make quite a complex set of tables and images.”
Sliding doors. Bowman’s technique, and the one that changed things. Two nested elements each carry part of a background image, one anchored left and one right, so the box can stretch with its content instead of breaking. The retrospective on its tenth anniversary is not modest about its importance, calling it the first of a series of articles that “not only pushed the limits of CSS but changed the web as we now know it.” It was also, unavoidably, two elements where the design called for one.
Nifty Corners. The image-free option, which paid for that with a different currency. As a contemporaneous write-up puts it, the method “uses no images and some clever JavaScript to achieve the effect,” so that “instead of creating various corner images of different colours that are combined with extra mark-up, the corner effect is created by specifying colours in the CSS stylesheet and the JavaScript code does the rest.”
It is worth being concrete about what the image approach meant in a working day. A designer hands you a panel in a slightly different shade of grey. With border-radius that is a one-character edit. With corner images it is four new PNGs, exported at the right radius, named consistently, uploaded, and referenced. Multiply by every panel style in a design system and you understand why sprite sheets were invented, and why an article promising to abolish all of it for square corners read as a mercy.
CSS 2 offered nothing better. The CSS Cookbook of the period says so directly: it “didn’t offer many ways of implementing rounded corners without abusing XHTML elements.”
Abusing. In a reference book. That is the vocabulary of the era.
| Approach | What it cost you | What broke it |
|---|---|---|
| Four corner images | 4 graphics, extra elements to position them, regenerated on any colour or radius change | Any design change at all |
| Sliding doors, 2003 | 2 nested elements per box, plus sprite images | Nothing, which is why it won |
| Nifty Corners | A JavaScript dependency | Script disabled |
| Square corners | Nothing | Nothing |
The contradiction the community had already admitted
This is the part that makes the satire sharper than it first appears, and it is preserved in public with dates and usernames.
The web standards movement of the 2000s had one central commitment: markup describes meaning, not appearance. Divs added purely to hold a corner graphic are the exact thing that commitment forbids.
| What the movement said | What rounded corners required |
|---|---|
| Markup describes meaning, not appearance | Elements that exist only to hold a corner graphic |
| Separate content from presentation | Presentation encoded directly into the document structure |
| Degrade gracefully without scripting | A JavaScript dependency, or four images |
| Keep documents lean | Markup a member of the period called “bloated with junk un-semantic elements” |
And practitioners knew. On the SitePoint forums in June 2010, a member arguing for the JavaScript approach states the problem outright: “if you are creating scalable corners you need to include un-semantic markup in your pages.” Their reason for preferring jQuery: “I found it much easier and my markup isnt bloated with junk un-semantic elements.”
Now read the opening line of the 2007 parody again. It claims square corners “embody the semantic markup movement in modern web design.”
That is not a random absurdity. It is precisely correct, and it is the joke. Square corners genuinely were the semantically pure choice, because they required no markup at all. The community was simultaneously committed to semantic markup and shipping un-semantic markup to get a curve, and had reached a quiet accommodation with the contradiction. The satire just said it out loud, in the register of a tutorial.
There is a second layer to it that is easy to miss. The standards movement was not wrong, and neither were the people shipping corner divs. Both were making a reasonable trade under a real constraint: browsers of the period could not do the thing, clients wanted the thing, and something had to give. The satire is not mocking anyone’s competence. It is pointing at the shape of the compromise, which nobody inside it could see clearly because everyone was busy being impressed by the workarounds.
You cannot parody a craft that is complaining. You can only parody one that has made its peace.
When did it stop being hard?
Slowly, then in one year.
Prefixed support arrived first and unevenly. Firefox took `-moz-border-radius`, while Safari and Chrome took `-webkit-border-radius` from version 3, with the prefix no longer needed from version 5. So for a stretch you wrote the same rule three times and hoped.
Internet Explorer was the wall. Prior to IE9, these CSS3 properties did not work in Internet Explorer at all. Not badly. At all. Which meant that during the entire prefix period, “supporting rounded corners” still meant maintaining a fallback for the most common browser on earth.

2011 is the year it ends. IE9, Firefox 4, Safari 5 and Chrome 4 and above all support the standard unprefixed property. Eight years after Sliding Doors, the curve became a single declaration.
Even then the tail was long. In an April 2011 SitePoint thread, a member is still explaining that “Not all browsers support CSS3 rounded corners. Versions of IE 8 and under don’t,” and pointing at shims: “There are many addon solutions to making CSS rounded corners work in IE, such as this one: CSS3 PIE.” The thread resolves with a line that will make anyone who worked in that era wince: “It turns out that the problem is the doctype.”
| Year | What was true |
|---|---|
| 2003 | A List Apart publishes Sliding Doors of CSS on 20 October. Rounded tabs become possible. |
| 2007 | The satire is published on 21 February. Rounded corners still cost markup, images or JavaScript. |
| Around 2009 | Prefixed support spreading: Firefox via -moz, Safari and Chrome via -webkit from version 3 |
| 2011 | IE9, Firefox 4, Safari 5 and Chrome 4 support the unprefixed property. The problem ends. |
| Today | One declaration, universally. Square is now the deliberate choice. |
The punchline nobody wrote down
The best joke in this entire story is not in the satire. It is sitting in the documentation of the technique the satire was mocking.
Describing why Nifty Corners was a good citizen, the write-up notes: “The technique degrades nicely as well. Users with JavaScript disabled will simply see square corners.”

The graceful degradation of the most elegant rounded-corner solution available was square corners. The same is true of the jQuery approach, as a forum member noted: “with jQuery/javascript the rounded corners would not show if the visitor has javascript disabled.”
So the fallback state of every sophisticated technique in the genre was the thing the parody was pretending to teach an 84-step process for. Turn the JavaScript off and you get, for free and instantly, the result the tutorial claimed was so elusive that “a simple, elegant solution for creating square corners has yet to emerge.”
Nobody in 2007 seems to have written that connection down. It was in the docs the whole time.
It is a good reminder of how craft blindness works. The people who wrote that documentation understood the technique better than anyone, described its failure mode accurately, and shipped the description without noticing it contained a complete refutation of the effort. Not because they were careless, but because the fallback was the boring case and nobody spends attention on the boring case. The satirist’s advantage was never superior knowledge. It was standing far enough back to read the sentence as written.
Was the effort worth it?
The forums argued about this in real time and the argument is better than the technique.
One position, from June 2010: “I personally think it’s time to move out of the ‘what about users without Javascript’ phase.” The counter, from the same thread, is the one that aged best: “My choice: progressive enhancement. Meaning: CSS3: round corners or multiple backgrounds. JS: jQuery (or other).”
That is the correct answer and it was available at the time. Use the native property where it exists, accept the plainer result where it does not, and stop treating a decorative curve as a requirement. Which is, functionally, agreeing with the joke.
| Position, from the 2010 forum thread | How it aged |
|---|---|
| “it’s time to move out of the ‘what about users without Javascript’ phase” | Broadly won on the modern web, though for reasons unrelated to corners |
| “with jQuery/javascript the rounded corners would not show if the visitor has javascript disabled” | Accurate, and became irrelevant once the CSS property landed |
| “progressive enhancement… CSS3: round corners or multiple backgrounds. JS: jQuery” | The correct answer then and the correct answer now |
There is a counterargument worth stating. Rounded corners were not purely decorative to the people commissioning them. In the mid 2000s a rounded panel signalled that a site had been designed rather than assembled, in exactly the way a custom typeface does now. Clients were not asking for a curve. They were asking not to look like a template. That the industry answered with four PNGs and a nested div is a story about the tools available, not about anyone’s judgement.
The honest verdict is that a great deal of skilled work went into a visual effect that carried no information. It produced real advances as a side effect, because Sliding Doors taught a generation how background positioning and stretchable boxes actually behaved, and that knowledge outlived the problem. But the effect itself was decoration, and the craft spent the better part of a decade on it.
What the joke means now
Something happened to this piece that its author cannot have intended.
In 2007, square corners were the default and rounded corners were the achievement, which is why a tutorial for the former was funny. Today the position is reversed in ordinary practice: `border-radius` is one line, it is everywhere, and a genuinely square corner is now a choice somebody made on purpose.
| 2007 | Now | |
|---|---|---|
| Square corners | The default. Free. Unremarkable. | A deliberate decision somebody has to make |
| Rounded corners | Nested elements, images or a script | One declaration, and often the default |
| An article teaching square corners | Obviously a joke | A reasonable thing to search for |
I want to be careful here, because that is an observation about what I see rather than a measured trend, and this site does not dress observations up as findings. But if it holds, the satire has quietly become sincere. “How to make square corners with CSS” is no longer an absurd article to want. It is a design decision with a rationale, and the instruction is still the same as it was in 2007:
Write nothing. That was always the whole technique.
If you want the companion piece about the gap between what code looks like and what it does, we took that apart in what code doesn’t do in real life, and there is more under developer culture.
FAQ
How do you make square corners with CSS?
You do not write anything. Square corners are the default rendering of a box. If a corner is rounded, something set border-radius on it, and the fix is to remove that declaration or set it to zero.
Why were rounded corners so hard before CSS3?
CSS 2 had no property for them. The available approaches were four corner images positioned by extra elements, the sliding doors technique of nesting two elements with left and right background images, or a JavaScript library that drew the corners. A reference book of the period described the alternatives as abusing XHTML elements.
When did border-radius get proper browser support?
Prefixed support came earlier, via -moz-border-radius in Firefox and -webkit-border-radius in Safari and Chrome from version 3, with the prefix dropped from version 5. Unprefixed support across the major browsers arrives around 2011 with IE9, Firefox 4, Safari 5 and Chrome 4 and above. Before IE9, Internet Explorer did not support it at all.
What was the Sliding Doors technique?
A method published by Doug Bowman on A List Apart on 20 October 2003, nesting two elements so each carries part of a background image, letting a rounded tab stretch with its text. A tenth-anniversary retrospective credits it with changing the web, noting that before it nobody had worked out how to make rounded tabs in CSS.
Is this article a joke?
The 2007 original at this address was. This one is not, though it is about the joke. The instruction it parodied is still accurate, which is the interesting part.
Sources
- Ten years of Sliding Doors of CSS, dating the technique and its impact
- Rounded corners with CSS, more Nifty Corners, on the JavaScript approach and its square-corner fallback
- CSS Cookbook on the sliding doors technique and the limits of CSS 2
- Schillmania, a working rounded-corner dialog of the era
- Filament Group on sliding doors with sprites and IE8 support
- Cross-Browser Rounded Corners Overview (2011) and The Art of Web on prefixes and support
- Can I Use and CSS-Tricks for the property itself
- CSS3.info, contemporaneous coverage of the property arriving
- SitePoint Forums, CSS Rounded Corners and Rounded Corners, CSS or jQuery?



















