This is a submission for Frontend Challenge - Comfort Food Edition, CSS Art.
Inspiration
A classic French gâteau aux fraises. Before developer education, developer relations, conference talks, and software architecture, I spent years in professional kitchens. I worked as an Executive Chef and competed in culinary competitions. If I was going to build a dessert out of HTML and CSS, there was only ever going to be one candidate.
Demo
An honest disclosure up front: I did not draw these. Every line of CSS below was generated by a frontier model from a single prompt I wrote, and this article is about what happened when three of them received that identical prompt.
- ChatGPT:
- Gemini:
- Claude:
Journey
I set out to survey what modern CSS could do before deciding whether to relearn it well enough to enter properly. I never got there, because the stylesheets turned out to be more interesting than the cakes. What follows is the write-up.
What Three AI Models Taught Me About Software Architecture
Or: how one recipe became three architectural philosophies.
When Dev.to announced its Comfort Food Frontend Challenge, I smiled. Not because I'm a frontend engineer, but because of the kitchens. Then reality set in. The challenge prohibits images, SVG, Canvas, and JavaScript. Everything has to be built from nothing but HTML and CSS.
I haven't seriously worked in CSS for quite a while. I could have skipped the challenge, but curiosity won. I wanted to see how far CSS had come, and what today's frontier models could do inside the same intentionally cruel rules.
What I expected was a quick tour of modern CSS.
What I got was a lesson about specifications.
The Recipe Card
Every professional kitchen runs on recipes.
That doesn't mean every pastry coming out of the kitchen looks identical.
A recipe isn't the finished dessert.
It's an agreement about ingredients, technique, and expected outcome.
Experience, interpretation, and craftsmanship still matter.
Software specifications aren't much different.
Before comparing any of the cakes, it's worth looking at the recipe card every model received.
Create a polished, visually impressive CSS-only illustration of a French gâteau aux fraises.
Deliver the result as one complete, self-contained HTML file containing all HTML and CSS. Do not use
JavaScript, SVG, canvas, external images, icon libraries, base64 images, or external stylesheets.
The composition should show:
* A complete round strawberry layer cake viewed from a three-quarter angle
* One wedge-shaped slice removed from the cake
* The missing wedge clearly visible in the cake body
* The removed slice plated beside the cake
* Visible sponge, whipped cream, and sliced strawberry layers inside both the cake and the plated slice
* Whole strawberries and piped chantilly cream decorating the top
* Strawberry slices arranged around the outer side of the cake
* The top marzipan layer should be in a pale green color
* A few crumbs or small pastry details on the plate
* Realistic shadows, highlights, depth, texture, and dimensional layering
* A sophisticated dark or neutral background resembling professional pastry photography
* Elegant ceramic plates beneath the cake and slice
The cake should resemble a carefully made French pâtisserie dessert, not a cartoon icon or flat infographic.
Use modern CSS techniques where useful, including: gradients, pseudo-elements, clip-path, masks,
transforms, perspective, filters, box shadows, layered backgrounds, CSS custom properties.
Prioritize convincing composition and visual depth over minimizing the amount of CSS.
Make the internal layers particularly clear. The removed slice must align visually with the missing
section of the cake so that it appears to have genuinely been cut from it.
The final page should be responsive and centered in the viewport. Include a subtle title, but keep the
pastry as the dominant visual element.
Comment the major CSS sections so the illustration can be studied and iterated upon later.
Each model got exactly one pass. No follow-up, no clarifying questions, no chance to revise. What's in the three pens above is what came back the first time.
Notice how prescriptive that prompt is. This matters, and it is the single most important thing to hold onto while reading the rest. I did not hand these models a vague brief and watch their personalities emerge. I handed them something closer to a Jira ticket written by someone who knows the domain, with sixteen acceptance criteria and a list of approved techniques.
Which means the interesting question is not "what did each model decide to make?" It is "given identical, unusually specific requirements, why did they produce such different code, and what did each one quietly ignore?"
A few things this experiment is not. It is not a benchmark. One task, one prompt, a small number of runs, evaluated by one person with strong opinions about French pastry. Outputs vary between runs and a different prompt would produce different tendencies. It is also not a claim about what these models fundamentally are. Treat what follows as three case studies, not a leaderboard.
This is why I wanted to include the full prompt instead of summarizing it.
If you've ever watched three pastry chefs work from the same recipe, you already know what happened next.
Nobody ignores the recipe.
Nobody follows it in exactly the same way, either.
Some chefs chase consistency.
Others chase presentation.
Others quietly optimize technique.
Software specifications behave exactly the same way.
One Spec, Three Desserts
Here is what came back.
| ChatGPT | Gemini | Claude | |
|---|---|---|---|
| CSS size | ~8 KB | ~22 KB | ~40 KB |
| Documentation comments | 0 | 42 | 70 |
| Custom property references | 10 | 18 | 319 |
Used perspective
|
no | yes | no |
| 3D strategy | stacked gradients | real 3D transforms | hand-derived projection |
Same requirements document. A fivefold spread in code volume. Three incompatible theories of how to fake a cylinder.
Every engineering manager who has ever written a detailed specification and every chef who has ever handed out the same recipe card has seen this phenomenon.
The recipe constrained the outcome.
It didn't determine it.
That's true in kitchens, and it's true in code reviews.
Imagine Three Pastry Chefs
Imagine three accomplished pastry chefs at adjacent workbenches. Each receives the same recipe card, and it is a detailed one. Quantities. Technique. Plating notes. Even the color of the marzipan.
Nobody asks a question. Nobody negotiates the requirements. They simply begin.
One reads it fast and starts sketching the finished presentation.
One builds the plate, the lighting, and the camera angle before touching the cake.
One quietly reaches for calipers and a basket of strawberries.
Three hours later you have three desserts that share a recipe and almost nothing else.
Chef One: The Sketch Artist (ChatGPT)
ChatGPT produced the smallest result by a wide margin, and it got there by being genuinely clever about the layer stack. The entire sponge-cream-fruit interior is one repeating gradient:
.cake{
background:
linear-gradient(90deg,#6e351f44,transparent 14% 81%,#6e351f55),
repeating-linear-gradient(
var(--cake) 0 39px, var(--cream) 40px 59px,
var(--cake2) 60px 99px, var(--cream2) 100px 121px,
var(--cake) 122px 163px, var(--cream) 164px 181px,
var(--cake2) 182px 210px);
}
That is a real economy of means. One declaration, seven bands, done.
It also read instantly as "cake," which is not nothing. Recognition is a legitimate optimization target and it is the one ChatGPT hit hardest. There is real engineering discipline in recognizing when "good enough to communicate" is the correct optimization target. If you've ever judged plated desserts, you know the first bite happens with your eyes. ChatGPT clearly understood that. The cake looked like a cake before it worried about how the cake was built.
But here is the thing I did not notice until I opened the file properly. The prompt's final instruction asked all three models to comment the major CSS sections so the illustration could be studied and iterated on later. ChatGPT's stylesheet contains zero comments. It is also almost entirely minified, several rules per line, no whitespace to speak of.
So my first read, that this was a model optimizing for readability, was exactly wrong. It optimized for time to a recognizable result and silently dropped a stated requirement about maintainability. The output is smaller because it is doing less, not because it found a tighter abstraction.
I have shipped that pull request. I suspect you have too.
Chef Two: The Cinematographer (Gemini)
Gemini did something none of the others attempted: it took "viewed from a three-quarter angle" literally and built an actual camera.
:root{
/* Global Perspective */
--perspective: 1200px;
--rotate-x: 58deg;
--rotate-z: -25deg;
}
.scene-3d{
transform-style: preserve-3d;
transform: rotateX(var(--rotate-x)) rotateZ(var(--rotate-z));
}
Every subsequent element lives inside that transformed space. The cake walls are extruded with stacked box shadows in Z. There is a marble countertop. The section comments carry headings like DISPLAY STAGE & 3D CANVAS.
It is the only implementation where the viewing angle is a parameter you could change. Adjust --rotate-x and the whole scene reorients. In the other two, the angle is baked into every hand-placed ellipse and would take a rewrite to alter.
It reminded me of preparing desserts for a magazine shoot. The lighting, the angle, the setting, the plate...everything around the dessert became part of the experience.
That is a genuine architectural advantage and I want to be fair to it, because my aesthetic reaction ran the other way. The more the scene invested in staging, the less convincing the cake at the center of it became. I found myself looking at a beautifully lit environment containing something cake-adjacent.
In a real production application, I'd much rather inherit Gemini's camera model than Claude's hard-coded geometry if I expected the design to evolve.
Some architects build the engine first. Others build the environment the engine will run in. Both ship. They just fail differently, and Gemini failed toward the picture rather than the pastry.
Chef Three: The Draftsman (Claude)
Claude never used perspective at all. It reminded me of watching pastry chefs who quietly spend thirty minutes making templates before anyone else has even picked up a piping bag. It worked out the projection by hand and wrote down its own math:
/* GĂ‚TEAU AUX FRAISES
HOW THE GEOMETRY WORKS
----------------------
The cake is a cylinder projected orthographically inside a "group" whose
local origin is its top-left corner:
rim ellipse centre C = (220, 90)
horizontal radius rx = 200
vertical radius ry = 66 (this ratio IS the camera angle)
wall height H = 158
A rim point at angle a is ( 220 + 200*cos(a) , 90 + 66*sin(a) ).
a = 90deg is nearest the viewer. The wedge is removed between 48deg and
122deg; because that straddles 90deg, both cut faces turn toward us.
The knife did NOT pass through the centre. The two cuts meet at
K = (223, 92), three pixels off axis, which is what a real hand does. */
That last line is where I stopped.
The wedge requirement in my prompt was purely visual: remove a slice, make the gap match the plated piece. Claude turned it into a geometry problem, solved it parametrically, then deliberately introduced a three-pixel error because a human hand does not cut through the exact center.
The 319 custom property references are the same instinct. One layer stack is defined once and reused across every cut surface in the scene, with the fruit running on three different pitches so that the two faces of the cut do not mirror each other suspiciously. There is a defined air pocket in the upper sponge. There is a documented spot where the fruit did not quite reach the cut.
At several points I forgot I was reading CSS. It reads like computational geometry with a pastry theme.
The cost is real, though, and worth naming. Forty kilobytes, and the camera angle is welded to that ry/rx ratio. Gemini could re-shoot the scene with one variable change. Claude would need surgery.
What Each One Threw Away
The most useful thing this exercise surfaced is not what any model built. It is what each one decided it could skip, given identical instructions.
ChatGPT dropped maintainability. It was asked for commented, studyable sections and delivered a minified block.
Gemini dropped fidelity to the subject. It was asked for a carefully made French dessert and delivered a carefully made photograph of one.
Claude dropped flexibility and economy. It was asked for convincing depth and delivered a rigid, expensive, beautifully documented model that resists change.
None of these is wrong. Each is a defensible reading of an over-specified brief by an implementer who had to prioritize something. That is precisely what happens when you hand a detailed ticket to three engineers and come back on Friday.
The specification did not determine the architecture.
It never does.
Layers Matter
As I looked at all three implementations, I kept returning to something I learned years ago in professional kitchens.
Recipes describe outcomes.
Architecture determines whether those outcomes are repeatable.
Anyone can accidentally produce an excellent dessert once. The craft is producing the same dessert tomorrow, and the day after that, with a different team and a different oven. Software architecture serves exactly the same purpose. It's less about making something work once than making success repeatable.
A proper fraisier isn't simply decorated.
It's engineered.
Every pastry chef knows the decoration is never what keeps a dessert standing.
Pipe mousseline onto a sponge that wasn't baked or trimmed correctly and the entire gâteau slowly begins to lean.
Cut the strawberries too thick and the layers separate.
Rush the chilling step and the first slice collapses on the plate.
None of those mistakes are visible while you're assembling the cake.
They're painfully obvious once someone tries to serve it.
Software architecture has the same habit.
The failure rarely begins where the customer notices it.
When someone admires a polished application, they're usually seeing the marzipan.
The real engineering is hidden inside the sponge.
Craftsmanship Lives in the Details
One of the first things you're taught in a professional kitchen is mise en place. Before a single pan gets hot, every ingredient is measured, every tool is within reach, every garnish is prepared. To an observer it can look like nothing is happening.
In reality, almost all of the work has already been done.
Great software architecture feels much the same, and so, it turns out, does CSS art. Every one of those three stylesheets was somebody's mise en place. Claude's 319 custom property references are the instinct carried to its logical end, everything measured and labeled before a single element is drawn. ChatGPT's ten are a cook who started sautéing and went looking for the salt mid-pan.
One unexpected outcome of this experiment was a renewed appreciation for CSS artists. The deeper I went into these implementations, the more obvious it became that CSS art is its own discipline. This isn't simply "knowing CSS."
It's geometry.
Typography.
Composition.
Color theory.
Visual perception.
Frontend engineering.
All of it working together under severe constraints.
Professional pastry chefs obsess over details most diners never consciously notice, and software architects do exactly the same thing. The best work looks effortless precisely because someone obsessed over hundreds of tiny decisions no one will ever see.
"Qu'ils mangent de la brioche"
It's almost impossible to write about French cakes without someone mentioning:
"Qu'ils mangent de la brioche."
In English it's literally "Let them eat brioche", most commonly known as "Let them eat cake."
Marie Antoinette almost certainly never said it. The line appears in Rousseau's Confessions, written before she became queen, and historians generally treat the later attribution as apocryphal.
I have to admit something here, because I nearly made the same mistake in this article.
An earlier draft praised Claude for abandoning a generic cake aesthetic in favor of the pale green marzipan traditional to a proper fraisier. It read like insight. It was not. Go back and look at the prompt: I specified the pale green marzipan myself. I had read my own requirement back out of the output and mistaken it for the model's taste.
That is exactly how bad attribution happens, and it is a small, embarrassing, extremely instructive version of the thing this section is about. When you are impressed by an output, check whether you are admiring the system or admiring your own instructions coming back to you.
Evidence matters. Whether you're documenting history, evaluating a model, or debugging a distributed system.
It's why the full prompt is at the top of this article rather than summarized, and why the numbers in that table are counted rather than asserted.
Final Thoughts
So here's my entry.
Not a cake. An essay about three cakes that turned out to matter more than the cakes did.
I want to be straightforward about how I got here. I set out to find whether modern CSS and a few good models could get me to a fraisier worth submitting. Somewhere in the middle of the second stylesheet, I stopped looking at the rendered output entirely and started reading the code, and the stylesheets were far more interesting than anything they produced.
To everyone who actually hand-crafted CSS art for this challenge: you have my respect. I came here expecting to brush the dust off skills I hadn't used in years. I left with a newfound appreciation for a craft that blends engineering, mathematics, and illustration in ways I hadn't fully appreciated before.
I'm not going to become a CSS illustrator on the strength of one challenge. Professional kitchens taught me something a long time ago. You don't become a pâtissier because you successfully bake one cake. You become one by baking thousands of them. CSS art is a similar craft. It belongs to people who have spent years on it, and after a week inside their medium I have considerably more respect for what they do than I did going in. Every hand-built entry in this challenge represents a skill I do not have.
But the constraint did what good constraints do. Take away images, SVG, Canvas, and JavaScript, and there is nowhere to hide. What's left is how something chooses to decompose a problem, and three different somethings decomposed it three irreconcilable ways from the same sixteen bullet points.
Sometimes the artifact isn't the story.
Professional kitchens don't produce identical desserts, because recipes aren't programs. They're specifications. They describe the destination, not every movement along the way, which is exactly why one card handed to three benches comes back as three desserts. Specifications don't guarantee identical software for the same reason. They define the boundaries inside which craftsmanship has room to show up.
I came looking for a cake and left thinking about recipes, implementations, and engineering judgment.
The desserts were interesting. The recipes were more interesting still.
Bon appétit.
Top comments (0)