DEV Community: Anatolii Ponomarenko

Your mobile screenshots are probably lying about your layout

Anatolii Ponomarenko — Thu, 22 Oct 2026 18:27:36 +0000

I sell HTML templates. Yesterday I found out that every mobile preview in every one of my product listings showed the product broken — cards clipped off the right edge, text cut mid-sentence, a button sliced in half.

The templates were fine. The screenshots were wrong.

Here is what happened, because the failure mode is quiet and I suspect it is common.

The setup

I take product screenshots with headless Chrome, which is the obvious thing to do:

chrome --headless=new --hide-scrollbars \
       --window-size=390,900 \
       --screenshot=mobile.png \
       https://example.com

One command, no dependencies, runs on any machine. For desktop widths it is perfect. I had twenty of these in a script and never looked twice.

The failure

At 390px the output looked like this: the page laid out, but every card ran past the right edge of the image. Not cropped by the screenshot — the content itself was wider than the viewport, as if the page had been rendered at desktop width and then the camera had been moved in close.

My first thought was that my own responsive CSS was broken.

It was not. I opened the same page in a real browser at 375px and measured:

document.documentElement.scrollWidth > window.innerWidth  // false
[...document.querySelectorAll('.card')]
  .filter(c => c.getBoundingClientRect().right > window.innerWidth + 1).length  // 0

No horizontal overflow, no card out of bounds. The live page was correct. Only the screenshot was wrong.

What I tried that did not work

Raising the virtual time budget. The obvious guess is a race: the shot is taken before layout and JavaScript settle. So:

--virtual-time-budget=20000

Twenty seconds instead of seven. Identical output, down to a few hundred bytes. Whatever is wrong is not a matter of waiting longer.

Blaming the charts. My dashboard draws its charts with JavaScript, reading host.clientWidth at draw time, so a stale width would explain over-wide SVG. Plausible — except the same clipping appeared on a plain marketing site with no scripted graphics at all. Different codebase, same artifact.

I stopped trying to diagnose it. The point was not to understand headless Chrome; the point was to get an honest picture of the page.

What worked

Render the page inside an <iframe> that is genuinely 390px wide, on a canvas that is a comfortable desktop size, and scale it down with a transform:

<style>
  :root { --ph-w: 390px; --ph-h: 860px; --scale: .482; }

  .frame {
    width:  calc(var(--ph-w) * var(--scale));
    height: calc(var(--ph-h) * var(--scale));
    overflow: hidden;
    border-radius: 18px;
  }
  .frame iframe {
    width:  var(--ph-w);
    height: var(--ph-h);
    border: 0;
    display: block;
    transform: scale(var(--scale));
    transform-origin: top left;
  }
</style>

<div class="frame">
  <iframe src="index.html" scrolling="no"></iframe>
</div>

Then screenshot that page at a normal desktop size:

chrome --headless=new --hide-scrollbars --allow-file-access-from-files \
       --force-device-scale-factor=2 \
       --window-size=910,607 \
       --virtual-time-budget=15000 \
       --screenshot=responsive.png \
       file:///path/_responsive.html

The iframe gets a real 390px layout — media queries fire, the sidebar collapses, the cards reflow — and the outer page is a width headless Chrome handles correctly. The clipping disappeared completely: cards with proper right margins, sparklines ending inside their cards with the end dot visible.

Two side benefits I did not expect:

Several phones in one image. Three iframes side by side, each a different page, one file. Much better than three separate narrow screenshots.
It is live. Change the CSS, re-run the command, the preview updates. No stale PNGs of an old design sitting in a listing for months.

--force-device-scale-factor=2 renders at 2× so the result is sharp on retina displays while the CSS layout stays at the size you reasoned about.

The part that actually costs money

While fixing this I checked what the marketplaces require, and the numbers are worth knowing before you export anything:

One marketplace asks for previews of exactly 1820×1214, not a range. Ordinary 1600×1000 page screenshots are refused.
Its stated minimum anywhere is 910×607. A raw phone screenshot at 390×844 is below the minimum width and cannot be uploaded at all.

So the composed canvas is not only more honest, it is the only shape that fits. A real phone screenshot, by itself, is not an acceptable preview on at least one major platform.

The lesson I will keep

A screenshot is a measurement, and measurements need calibrating against the thing they measure.

I had PNGs produced by a script I trusted, sitting in live product listings, showing customers a broken layout. Nobody told me. The only reason I found it was that I happened to open one at full size while working on something else — and a listing can sit like that for as long as nobody looks.

Now the rule is: before a screenshot goes anywhere a customer will see it, open the same page in a real browser at the same width and check that they agree. It takes thirty seconds.

If you generate previews, marketing images or documentation screenshots from a script, this is worth doing once today. The failure is silent, and the people who see it are exactly the people you were trying to impress.

The template this came out of is Mesa, a restaurant analytics dashboard. The free cut is MIT. The chart engine behind it is a separate library: mesa-charts — eleven chart types on one page.

Nine chart types in 878 lines of SVG, and what I kept getting wrong about axes

Anatolii Ponomarenko — Sun, 18 Oct 2026 17:03:25 +0000

I built a restaurant analytics dashboard with twelve pages of charts and no charting
library. Not because Chart.js is bad — it isn't — but because the thing I was building
had to open from a file on disk, on a locked-down machine, with no npm install and no CDN.
That constraint removed every option except writing the charts myself.

The engine ended up at 878 lines and ~37 KB of plain JavaScript: nine chart types in one
file, plus a heatmap and a set of trend rows in the page script. It draws SVG with
createElementNS and nothing else.

Most of what I learned had nothing to do with SVG. It was about axes, and about the two
or three decisions that quietly decide whether a chart tells the truth.

The tick loop that lets a bar escape

Here is the first version of the function that picks the axis ticks:

const ticks = (max, count = 5) => {
  const raw = max / count;
  const mag = Math.pow(10, Math.floor(Math.log10(raw)));
  const norm = raw / mag;
  const step = (norm <= 1 ? 1 : norm <= 2 ? 2 : norm <= 2.5 ? 2.5 : norm <= 5 ? 5 : 10) * mag;
  const out = [];
  for (let v = 0; v <= max; v += step) out.push(v);
  return out;
};

This is the standard "nice numbers" trick: take the raw interval, round it to the nearest
1, 2, 2.5, 5 or 10 times a power of ten, and you get ticks humans can read — 0, 2.5k, 5k
instead of 0, 2340, 4680.

It is also wrong, and the wrongness only shows up with certain data.

The loop stops at the last tick below or equal to max. If max is 11,200 and the
step is 2,500, the ticks are 0 … 10,000. The top of the plot area is now 10,000 — but the
tallest bar is 11,200. It renders twelve percent above the plot, straight through the top
of the card.

The fix is one line of intent: always climb past the data.

/* Always climb past max — otherwise the tallest mark renders above the
   plot area and escapes the card. */
const out = [];
for (let v = 0; ; v += step) {
  out.push(+v.toFixed(10));
  if (v >= max - step * 1e-9) break;
}
return out;

Two details in there cost me time:

+v.toFixed(10) — repeatedly adding 0.1 gives you 0.30000000000000004 as a tick label. Rounding the accumulator kills it.
max - step * 1e-9 instead of max — with the same float drift, the loop can stop one step early on a value that looks equal.

That one is a plain bug: wrong output, visible, fixed once. The mistakes that cost me more
were the ones where the chart rendered perfectly and still said nothing.

When a non-zero axis is honest

Averages are the awkward case. A twelve-week trend of average check moves from €44.10 to
€49.40 — a real 12 % climb. Drawn from zero it is a flat line in the top fifth of the card,
with four fifths of empty space underneath. Technically correct, and it tells you nothing.

So the line chart has an opt-out, and a second tick function behind it:

/* Ticks for a range that does NOT start at zero. Only for lines of averages,
   rates and indices, where the trend — not the absolute size — is the point.
   Never use this for bars: a bar's length must stay proportional to its value. */
const ticksRange = (min, max, count = 5) => {
  if (!(max > min)) return ticks(max, count);
  const raw = (max - min) / count;
  const mag = Math.pow(10, Math.floor(Math.log10(raw)));
  const norm = raw / mag;
  const step = (norm <= 1 ? 1 : norm <= 2 ? 2 : norm <= 2.5 ? 2.5 : norm <= 5 ? 5 : 10) * mag;
  const lo = Math.floor(min / step) * step;
  const out = [];
  for (let v = lo; ; v += step) {
    out.push(+v.toFixed(10));
    if (v >= max - step * 1e-9) break;
  }
  return out;
};

The comment is the important part, and it is in the shipped source for a reason.

The rule I settled on: a non-zero baseline is fine when the mark's position carries the
meaning, and dishonest when the mark's size does. A line sits at a height; your eye reads
where it is. A bar has length; your eye reads how long it is. Cut the bottom off a bar
chart and a 3 % difference becomes a doubling.

So ticks is the default everywhere, ticksRange is opt-in through a single flag, and
bars never get it:

const ty = zeroBased ? ticks(max, yTickCount)
                     : ticksRange(Math.min(...all), max, yTickCount);

When the axis isn't the answer at all

Then I hit a case the flag could not fix. The same average-check card had two series:
dine-in around €44–49, delivery around €28–33. Both climbing, both interesting.

Zero-based, they are two flat lines stacked in the upper half. Scaled to the data, they are
two flat lines with a canyon between them — because the gap between the series is far
bigger than the movement inside either one. The axis is not the problem. Sharing an axis
is the problem.

The fix was to stop drawing one chart. Each series got its own row, its own scale and its
own sparkline — small multiples — plus a third derived row for the gap itself, which turned
out to be the number an owner actually cares about:

const [dine, del] = DATA.avgCheckTrend.series;
const gap = dine.values.map((v, i) => +(v - del.values[i]).toFixed(2));
UI.trendRows('#chart-check', {
  currency: C, decimals: 2,
  rows: [
    { name: dine.name, color: dine.color, values: dine.values },
    { name: del.name,  color: del.color,  values: del.values },
    { name: 'Gap', values: gap, derived: true }
  ]
});

I spent a while tuning an axis before accepting that the chart type was wrong. And I only
accepted it the second time — I had already made the same "two averages, one axis, now
it's flat" mistake on a different card weeks earlier, fixed it, and then walked straight
into it again. Knowing the rule and applying it under deadline are apparently two different
skills.

The more useful lesson of the two: reach for a different form before you reach for a
different scale.

Labels that know when to leave

Direct labels on bars are better than a legend — the number sits where the eye already is.
Until the window narrows, the bars get thinner, and the labels start overlapping each
other into mush.

Every bar chart can carry a caption above each column. The whole of the logic that decides
whether to draw it is this:

const cap = topLabels ? topLabels[i] : (withPercent ? Math.round((totals[i] / grand) * 100) + '%' : null);
if (cap != null && slot >= 34) {
  const p = el('text', { class: 'value-label', x: cx, y: Y(totals[i]) - 8, 'text-anchor': 'middle' });
  // …
}

slot is the horizontal space one column gets — the plot width divided by the number of
columns. Below 34 pixels the caption cannot fit without touching its neighbour, so it is
simply not drawn.

That threshold is the entire feature, and the reasoning behind it is the one line of
comment next to it in the source: a collided label is worse than no label. A chart with
captions on twelve columns and none on thirty is not inconsistent, it is responsive. A
chart where thirty captions overlap into a grey smear is broken, and worse, it looks like
nobody checked.

The same instinct shows up in a few places once you go looking for it — share labels on a
donut are skipped on slices under 6 %, where the text would be wider than the slice it
belongs to.

Themes: redraw, don't invert

The dashboard ships dark and switches to light. The tempting shortcut is a CSS filter over
the whole page. Don't — it inverts your photographs, flips your semantic colours so green
"good" becomes magenta, and leaves the charts looking like a photo negative.

Because every colour in the engine is a CSS custom property read at draw time:

const css = (name) => getComputedStyle(document.documentElement).getPropertyValue(name).trim();

…switching themes is just redrawing. Every chart registers its own render function when it
mounts:

function mount(selector, draw) {
  const host = typeof selector === 'string' ? document.querySelector(selector) : selector;
  if (!host) return null;
  const render = () => {
    const w = host.clientWidth;
    if (!w) return;
    host.innerHTML = '';
    host.appendChild(draw(w));
  };
  registry.push(render);
  render();
  return host;
}

const redrawAll = () => registry.forEach(f => f());

The same registry powers responsive resizing, debounced so a window drag doesn't rebuild
forty SVGs per second:

let resizeTimer;
addEventListener('resize', () => {
  clearTimeout(resizeTimer);
  resizeTimer = setTimeout(() => registry.forEach(f => f()), 140);
});

And the theme button is three lines:

root.setAttribute('data-theme', next);
try { localStorage.setItem(KEY, next); } catch (e) { /* ignore */ }
if (window.Mesa) Mesa.redrawAll();   // charts re-read their CSS variables

The try/catch is not decoration: localStorage throws in some privacy modes, and a theme
toggle is not worth a broken page.

One tooltip serves every chart on the page — a single div created lazily and moved
around, rather than one node per chart:

let tipEl = null;
const tip = {
  node() {
    if (!tipEl) {
      tipEl = document.createElement('div');
      tipEl.className = 'tip';
      tipEl.setAttribute('role', 'status');
      document.body.appendChild(tipEl);
    }
    return tipEl;
  },
  // …show / move / hide
};

It also flips itself when it would run off the right edge of the viewport, which is the
kind of thing a library gives you for free and you forget you need until you hover the
last bar.

Colours, briefly

There is no colour cycling in the engine, and that is deliberate: each series names its own
CSS variable, so series four keeps its colour whether or not series two is filtered out.
Generated hues would quietly repaint the survivors every time a filter changed.

The palette itself is eight fixed steps, and the line above them in the stylesheet records
what they were checked for:

/* --- categorical series (validated: adjacent CVD ΔE ≥ 8) --- */
--s1: #2a78d6;  /* blue   */
--s2: #eb6834;  /* orange */
--s3: #1baf7a;  /* aqua   */
--s4: #eda100;  /* yellow */

Every adjacent pair stays distinguishable under deuteranopia, protanopia and tritanopia.
Status colours (good / warning / critical) are a separate set and always ship with a label,
never colour alone.

That last rule is the one most dashboards break. If the only thing marking a row as
critical is that it is red, a meaningful slice of your users sees an unmarked row.

Should you write your own?

Mostly no.

If you need zoom, brushing, animated transitions, a time axis that handles daylight saving,
or a hundred thousand points, use a library. That work is enormous and it is already done.

Write your own when:

the deliverable must run with no network and no build step;
you need a handful of chart types rather than a general-purpose grammar;
the bundle budget is small enough that 40 KB of charting matters;
you want to be able to read every line that renders your numbers.

What surprised me is how much of the work is not drawing. Drawing a bar is four lines of
path data. Deciding where the axis starts, which labels to drop when the column gets too
narrow, and when the honest answer is a different chart entirely — that is where the time
goes, and that is also what separates a chart that informs from a chart that decorates.

The engine lives inside a restaurant analytics dashboard template I sell. The free cut —
two full pages, the engine, MIT — is here:
github.com/Anatolii198/mesa-lite
(live demo).

The full twelve-page version is here if you want
to see all eleven chart types in one place.
Update: the engine is now a standalone library — mesa-charts, MIT, with a demo of all eleven chart types on one page.

Happy to argue about axis baselines in the comments.