When Adaptive Font Scaling Destroys Grid-Based Expert Workflows

We've all seen it: you're deep in a grid—maybe a spreadsheet with 40 columns, maybe an IDE with nested code blocks, maybe a dashboard with aligned charts. Then the browser decides to help. It scales the font. Suddenly your columns misalign, your indentation looks wrong, or a crucial number gets cut off. Adaptive font scaling, designed for readability on small screens, becomes the enemy of spatial reasoning.

This isn't about hating accessibility. It's about a collision of two design philosophies: fluid typography that adjusts for comfort vs. pixel-grid interfaces that depend on fixed proportions. For experts who rely on muscle memory and consistent visual spacing, adaptive scaling can destroy workflow. Here's what you need to know.

Who Needs This and What Goes Wrong Without It

The power user's dilemma: readability vs. spatial memory

You run a dashboard of fifteen revenue tiles—each painstakingly aligned to a 4-column grid. Every morning your eyes snap to the third cell, second row, without reading a single label. That muscle memory took weeks to build. Then the browser auto-scales font size to 125% because you connected an external monitor. Suddenly the fourth column wraps below, the KPI header overflows, and that reliable third cell now shows a truncated metric you don't trust. The layout is technically responsive—it just isn't yours anymore. This is the audience: developers, analysts, and ops leads who treat screen real estate like a cockpit. They don't want fluid adaptation—they want predictable placement.

The tricky part is that accessibility advocates are right—small fonts hurt readability, especially on high-DPI panels. But accessibility means different things to a designer drafting a marketing site versus a trader scanning thirty streaming prices. For the power user, adaptive font scaling doesn't just resize text; it resizes the grid's implicit contract. That 12-column layout you tuned so carefully? The browser's font inflation algorithm treats it as a suggestion. I have seen a pivot table's column headers collapse into ellipsis hell because a viewport change triggered a 110% font bump. The user didn't notice the font change—they noticed the missing sales region.

'The browser thinks it's helping. My grid thinks it's drowning. Neither asked me.'

— Front-end engineer, after a production dashboard reflow incident

Concrete breakdowns: pivot tables, code editors, grid dashboards

Start with pivot tables—the worst offender. A 10-column cross-tab relies on every cell holding its horizontal space. Font scaling by 115% can push the last three columns off-screen or, worse, force the table into a horizontal scroll that breaks the row-highlighting script. Code editors suffer differently: adaptive scaling that kicks in mid-session shifts line numbers and gutter widths, making cursor-to-line correspondence unreliable. We fixed this once by locking the editor container's font-size to a px value and scaling only the surrounding chrome—but that fix took three days of regression testing. Grid dashboards are subtler. A weather-radar tile with overlays might look fine at 100% zoom, but at 110% the radar layer misaligns with the map tiles underneath. That hurts. The seam blows out, and nobody catches it until the morning shift panics.

What usually breaks first is the spacing between grouped widgets—the gap that makes a grid feel intentional. Font scaling changes line-height, which changes the effective height of each card, which pushes the next row down. Suddenly your 2×2 quadrant becomes a lopsided stack. Power users notice before the dev team does, because their eyes already memorized where the red-alert panel lives. Wrong order. That muscle memory is expensive to rebuild.

Why 'just zoom out' isn't a fix

Because zooming out shrinks everything uniformly—including the navigation, the tooltips, and the critical labels you already struggle to read. The user wants larger text without blowing up the grid. 'Just zoom out' trades one broken layout for another: you gain column fit but lose the ability to discern data values. That's not a trade-off; it's a failure mode. Most teams skip this part in QA because they test at 100% zoom on a single monitor. Real workflows cascade across a 27-inch primary screen and a 13-inch laptop lid, each with its own OS-level text scaling. The browser mediates between them poorly. Worth flagging—this isn't a bug report; it's a design mismatch between CSS rem units inherited from a global style and the pixel-perfect constraints of a grid-based tool. 'Just zoom out' solves nothing, but it's the first thing a tired support rep suggests. Don't accept it.

Prerequisites: What You Should Settle First

Understanding your grid's layout logic

Most expert workflows lean on a grid that feels stable — until it isn't. The tricky part is that adaptive font scaling doesn't touch layout coordinates directly. It stretches text. Then the grid, which you tuned pixel-perfect for the old font size, starts to buckle. I have seen a data-heavy dashboard where a single line of "Price / Volume / Bid" suddenly wrapped to three lines after an OS zoom change, pushing three adjacent panels out of alignment. That breaks the mental map. Before you patch anything, you need to know: is your grid defined as a fixed pixel array, or does it use fractional units? If your grid tracks are set in px, a 1.2× font scale compresses your content container until text spills over the edge. If you use fr or percentage-based columns, the grid adapts — but the text inside may now overflow the cell's min-content boundary. The catch is that both approaches hide vulnerabilities until a specific zoom level. So sit down and map every grid container in your app. Which ones hold text? Which ones hold text inside nested flex elements? That nesting is where the seam blows out first.

Identifying critical viewport widths and font families

Not every font reacts the same way. A narrow grotesque like Helvetica Neue has tight letter-spacing and a short x-height — it can absorb a 10% scale increase without breaking a line. A humanist face like Georgia? It opens up visibly, and its descenders clip into the row below when the grid row is a fixed 32px. Most teams skip this: they test with one browser default font, deploy to a mixed-font environment, and then the complaint tickets arrive. You need to audit font families used in each grid cell — especially for data tables, parameter inputs, or any truncated text that relies on text-overflow: ellipsis. Worth flagging—ellipsis is a fragile friend. At 110% zoom the text might not overflow yet, but the visible characters shrink, confusing operators who expected to see "5.13.8.2" and instead see "5.1…". So list your font stack, then check each family against the OS-level accessibility font scaling slider. Does the grid cell hold numeric identifiers? Dates? Short action buttons? Each type poses a different risk.

'We pinned every column to 80px because that looked clean at 100% zoom. Then an analyst with low vision bumped the font scale to 130% and half the table turned into an overlapping mess.'

— former QA lead at a trading platform, internal post-mortem

Auditing your own reliance on fixed spacing

Now get honest about your margins, padding, and gap values. Adaptive font scaling doesn't adjust white space. If you set gap: 12px between grid items and a scaled font now requires 18px of breathing room, text collides with adjacent cells. The fix is not to make every gap enormous — that destroys information density, which is the whole point of an expert grid. What usually breaks first is the internal padding inside a card or cell: a padding: 8px that once felt roomy becomes a choke point under 125% scaling. I fixed a similar issue by refactoring all critical grid cells to use min-content row heights with a clamp() on the font size, but that trade-off can introduce vertical drift if the grid has many rows. Here is the self-check: open your app at 100% zoom, screenshot a grid section. Then set the browser zoom to 125% (Ctrl/Cmd +, three times). Compare the two screenshots. Are any text fragments overlapping? Are any cells suddenly taller, pushing the row below out of alignment? If you see horizontal scrollbars appear inside a cell, you have fixed spacing that doesn't yield. That hurts. The next chapter will show you exactly how to measure and mitigate it — but only after you have catalogued these weak points. Write them down. You will need that list.

Reality check: name the accommodations owner or stop.

Core Workflow: How to Diagnose and Mitigate Adaptive Scaling

Step 1: Record baseline viewport and font sizes

Open your grid interface in a controlled browser instance—no extensions, default zoom. I have seen teams waste hours chasing phantom alignment bugs, only to discover their browser zoom was set to 110% from a misclick. Measure the actual rendered pixel width of one grid cell at the default state. Not the CSS `grid-template-columns` value; the real computed width. Then measure the rendered font size of the same cell. You need both numbers because adaptive scaling distorts the relationship between them before you ever touch a breakpoint. Write these two values down. That sounds trivial, but when a 12-column grid suddenly shows 11 columns on a 4K monitor, you need to know whether the font grew or the viewport shrank.

Most teams skip the baseline. Then they blame the grid. The grid was fine — the root font size had shifted.

— overheard in a debugging session, 2024

Now check the browser's reported `devicePixelRatio` and the OS-level text scaling setting. On Windows, that's under `Settings > Display > Scale`. On macOS, `System Settings > Displays > Scaled`. The tricky part is that these settings compound silently. A 125% OS scale plus a 90% browser zoom creates a layout that passes visual inspection but fails at every grid alignment edge case. Worth flagging—resetting the zoom to 100% is not enough; you must also normalize the OS text scaling to 100% or record its deviation.

Step 2: Test with scaling enabled and disabled

Create a minimal test page: one grid container, three cells, fixed font-size values in `px`. Not `rem`, not `em`—raw pixels. Take a screenshot, measure the distances. Then re-enable your normal adaptive scaling rules—this could be `clamp()`, viewport units, or a user preference media query. Compare the two states. What usually breaks first is the gap between cell borders and the text inside. Not the cell width itself. The font grows, the padding stays fixed, and the content overflows by one or two pixels per cell. Times 12 columns, that's a 24-pixel shift across the whole row. That hurts. A single row might look fine, but an entire dashboard panel off by 24px screams 'broken grid' to any power user.

Is this always a scaling problem? Not necessarily. Sometimes it's a `box-sizing: border-box` omission. But if your baseline test (fixed px) holds alignment exactly, and the scaled version drifts, you have diagnosed the root cause. Document the drift delta per cell. That delta is your mitigation target.

Step 3: Implement CSS or settings overrides

Add a CSS rule that explicitly resets the font size on your grid container to a `clamp()` value with a tight upper bound. Example: `font-size: clamp(14px, 1.2vw, 16px)`. The `vw` unit lets the text grow with the viewport, but the `clamp` ceiling stops it from expanding beyond your grid's tolerance. I have seen this single rule fix a 40-pixel misalignment across three breakpoints. However—and this is the pitfall—`clamp()` interacts badly with OS-level text scaling on some Chromium builds. Test it on Chrome, Edge, and Firefox. If the seam blows out on Firefox, switch to a media query that targets `prefers-reduced-transparency` or a custom `@media (min-resolution: 2dppx)` override instead.

For enterprise deployments where you control the runtime environment, push a settings override through your configuration management tool. Force the browser zoom to 100% on launch, disable automatic text scaling in the Electron or WebView shell. That eliminates the variable entirely. The trade-off is blunt—users lose accessibility zoom. But for a grid-heavy expert workflow where pixel alignment is non-negotiable, a fixed font scale beats a broken grid every shift. We fixed this by adding a small floating toggle: 'Lock grid scale' in the toolbar. Users can unlock it when they need accessibility zoom, but the default state preserves the grid. Next action: build that baseline measurement step into your startup routine. Record it once, cache it, and compare it against the live state every time the viewport resizes.

Tools, Setup, and Environment Realities

Browser dev tools for font inspection

Start with what you already have. Chrome’s Rendering tab — buried under the three-dot menu in DevTools — exposes a “Paint Flashing” view that highlights every repaint triggered by a font-size change. Worth flagging: most teams skip this and wonder why their grid shudders during resize. Open that panel, resize the viewport slowly, and watch the red rectangles bloom. One concrete test: load your grid at 1440px, write down the computed `font-size` for a key text node, then shrink to 1024px. If that number jumps by more than 2px, you have a scaling event that probably shifts your grid cells. Firefox has a similar overlay under “Layout” — “Scroll Hit Regions” — but I have seen fewer false positives there.

But DevTools alone can't tell you why the font changed. You need the Computed panel side by side with the Styles panel. The tricky part is that `clamp()` values look fine in the Styles pane; the computed value hides the actual interpolation. A tip: copy the raw `clamp()` expression into a console snippet that logs the output at different viewport widths. We fixed this by writing a quick bookmarklet that reads `window.innerWidth` and spits back the active font-size — catches rogue container queries that DevTools sometimes ignore.

CSS properties: font-size, clamp(), and container queries

Most adaptive scaling disasters originate in three CSS properties: `font-size` with viewport units, `clamp()`, and `container-type`. That sounds straightforward — until you realize container queries break the cascade. A grid cell inside a `container-type: inline-size` parent doesn't inherit the global `clamp()` anymore; it responds to the container’s own width. The catch? Container queries create a new sizing context, and if your font-size references `cqi` (container query inline-size units) instead of `vw`, the scaling curve shifts entirely. I have debugged a Tableau dashboard where the labels overlapped because a container query on a sidebar panel compressed the font to 9px while the grid stayed at 14px. The fix: enforce a minimum `font-size` floor using `max()` over a static pixel value — never rely on `clamp()` alone when containers nest.

A second pitfall: mixing `em` and `clamp()` inside the same grid. `em` cascades from the parent’s computed font-size, which may itself be a `clamp()` value. That double application — parent clamp multiplied by child em — produces nonlinear scaling. One Tableau workbook I saw had three nested grids, each amplifying the font shift until the bottom cell text was 40% larger than intended. The editorial signal here: use `rem` for grid text, reserve `em` only for padding or decorative elements. Test with a 50% viewport shrink and measure the cell heights — if they vary by more than 5px, your cascade is compounding.

App-specific settings: Excel, VS Code, Tableau

Different tools expose different levers. In VS Code, the setting `editor.fontSize` is absolute — 14px stays 14px regardless of zoom — but the interface font (the sidebar, the tabs) respects the system’s display scaling. That mismatch causes grid misalignment when you open a split view: the editor panel keeps its font, the explorer panel resizes, and the layout shifts by 3–4px. The workaround is to disable `window.zoomLevel` and set `editor.fontSize` to match the OS scaling factor exactly. In Excel, the problem is inverse: the grid cells adapt to the zoom level, but the formula bar uses a separate `font-size` controlled by the “Display” settings under Options. Most users never touch that. The result: a 150% zoom makes the grid readable but the formula bar text bleeds into the column headers. We fixed this by locking Excel’s `Zoom` to 100% and scaling the monitor’s DPI instead — crude but stable.

Not every accessibility checklist earns its ink.

Tableau presents the worst case. Desktop dashboards respect the OS scaling, but Tableau Server renders at whatever viewport the browser provides. A dashboard built at 125% scaling on a 4K monitor looks broken at 100% on a laptop — the grid gutters widen because title font-sizes are fixed but the container widths shrink. The only reliable setup we found is to test every dashboard at three presets: 100%, 125%, and 150% in the browser’s zoom settings, not the OS. Then set `text-size` in Tableau’s dashboard pane to `clamp(11px, 1.2vw, 16px)` for body labels and min-width constraints on containers. One concrete rule: if a container width is expressed as a percentage and paired with a clamp() font, you will hit a breakpoint where the text overflows — add a max-width in pixels to cap the container before the font hits its upper clamp.

“The first time I saw a Tableau dashboard break at 125% scaling, I blamed the grid. The grid was fine — the font-size was lying about its container width.”

— senior BI engineer, after a three-hour debug session

Next action: open your most-used tool, set the zoom to 110%, and measure the grid cell height before and after. If it changes, you have a scaling leak. Hunt it down with the DevTools overlay first, then lock the container constraints. Don't skip this — one pixel of font growth across forty columns compounds into a 40px blowout that users will blame on you.

Variations for Different Constraints

Mobile vs. desktop: when scaling is unavoidable

The core workflow you just built assumes a certain fixed real estate—maybe a 24-inch monitor at 1920×1080. Then someone opens the same grid on a 13-inch laptop at 2560×1600. That hurts. Text that was crisp becomes microscopic. The natural instinct is to let the browser handle font scaling, but on a dense screen the grid columns suddenly hold 17 characters instead of 12. Everything reflows. I have seen a financial dashboard collapse into a single column because the developer set clamp() values that ignored the viewport-plus-DPR equation. The fix isn't to ban mobile—you can't. Instead, introduce a secondary scaling cap: font-size: clamp(0.75rem, 1vw + 0.5rem, 1.1rem) only if the viewport width exceeds 1024px. Below that, lock the minimum to 14px. The trade-off is obvious: small screens lose some information density. But a grid that stays a grid beats a grid that turns into a vertical list.

Accessibility requirements vs. grid stability

Accessibility mandates—WCAG 2.1 AA, for instance—force a minimum 12px font, sometimes larger if the user has zoomed the OS to 150%. That sounds fine until a 200% zoom setting hits your 12-column layout. The grid holds, but the text overflows its cells. What usually breaks first is the tooltip or the inline label that was sized at 11px to fit inside a 40px-high row. You can't just bump everything up by 20% because the column gutters stay fixed. The pragmatic solution: use min() for cell padding rather than absolute pixel values, and test with the browser's forced zoom at 200%—not just the pinch-zoom gesture. Anecdote: a team I worked with shipped a scheduling board that passed Lighthouse audits but failed a real user test because the 14px fallback still clipped inside 3rem-high rows. We fixed this by adding a line-height: 1.3 minimum and letting the row height grow by 0.5rem per 10% zoom increment. The grid lost some visual symmetry. The user kept their data readable.

'When accessibility and grid rigidity clash, the grid always bends. The trick is to bend it in a controlled way, not let it snap.'

— senior UI engineer, internal post‑mortem

Team environments: shared settings and consistency

Most teams skip this: the designer develops at 100% browser zoom on a Retina display, the front-end engineer uses a 125% scaled Windows machine, and the QA reviewer has macOS scaled to 'More Space'. Three different renderings of the same grid. I have debugged a layout that only broke on the PM's laptop—turned out their Chrome zoom was set to 110% globally and nobody noticed. The fix is blunt but necessary: enforce a single reference environment for grid reviews. Pick one OS zoom, one browser zoom, and one viewport width. Then run a secondary check at 150% OS zoom and 80% viewport. Variations like dev tool overrides or Display Zoom on Mac will produce inconsistent line-heights—document that as a known delta. Worth flagging—CSS text-size-adjust: 100% is not enough to prevent Safari from inflating text on landscape phones. You will need to lock it globally on the grid container. The catch is that some assistive tools override that property. So test with VoiceOver or NVDA zoom active, not just the standard browser. Consistency across the team means agreeing on which scaling variables are negotiable and which are not. Otherwise, every pull request becomes a debate about pixel-perfect vs. accessible.

Pitfalls, Debugging, and What to Check When It Fails

The viewport-resize trap

You test your grid at 1440px, then at 1024px, and everything holds. Then a user tabs through a presentation on a 13-inch laptop with the browser snapped to 60% width—and suddenly your six-column grid collapses into a three-column jumble with half the text clipped. That's the viewport-resize trap. Most adaptive scaling mitigations assume a clean breakpoint transition, but real viewports don't snap; they drift. The font-size calculation that looked beautiful at 1280px may produce fractional rem values at 1057px, causing a character to overflow its grid cell by exactly one pixel. One pixel. The seam blows out.

The fix is not more media queries. A better first move: clamp your scaling function inside a narrow operating band—something like clamp(0.9rem, 0.5rem + 1vw, 1.25rem)—then test at every 20px interval between 800px and 1400px. I have seen teams spend two days patching breakpoints when the root cause was a fluid type calculator that produced 13.47px at a viewport where the grid expected an integer multiple of 14px.

Nested scaling from OS, browser, and app

The operating system zooms the display. The browser applies its own default zoom. The user's IDE or browser extension injects a second font-scaling layer. And your CSS `font-size: clamp()` is still trying to negotiate with a viewport that already got doubled. This nested scaling chain is the most common cause of "it works on my machine but not in production"—and it's nearly invisible in DevTools because each layer reports its own separate scaling factor.

Worth flagging—Chrome's remote debugging rarely replicates OS-level zoom settings. We fixed this by shipping a small diagnostic overlay: a single line of `1em` text rendered inside a `1rem` box, visible only when you press `Ctrl+Shift+D`. If the text overflows the box, you know scaling is stacking. The trade-off is maintenance overhead, but catching nested scaling before it hits the grid saves a lot of angry issue-tracker comments.

“The grid was pixel-perfect in three browsers. Then a designer opened it in Firefox with a 125% system scale and the layout wept.”

— lead front-end engineer, enterprise SaaS team, 2024 postmortem

Reality check: name the accommodations owner or stop.

Most teams skip checking OS-level zoom because it feels like a user preference, not a development variable. But when your grid depends on `1rem` matching exactly `16px`, and the system says `1rem` is now `20px`, your `clamp()` function shifts its entire range. The pragmatic cure: write all grid sizing in `ch` units for text-heavy columns, then enforce a single `rem` baseline with a CSS custom property that overrides any OS scaling below 150%. It's not elegant—it's defensive.

False positives: when it's not scaling but something else

You have diagnosed three layers of zoom. You have clamped every font. The grid still breaks at intermediate viewport widths. The culprit might not be scaling at all. A common false positive: your grid template uses `minmax(250px, 1fr)` and a long unbreakable word—like "Konstantinopolshchikova"—forces the column wider than your type scaling expects. That's a line-break problem, not a scaling problem.

Another decoy: CSS subgrid gaps that compound unexpectedly when a nested component changes its `font-size` from `1rem` to `1.25rem` at a breakpoint you forgot existed. The grid holds, the type grows, the gap between cards expands by 0.25rem because you used `gap: 1em` instead of `gap: 16px`. The alignment breaks, and everyone blames adaptive scaling. The debugging move: strip all `em` values from grid gaps, switch to `px` or `rem` for spacing, then reintroduce type scaling in isolation. That hurts, but it isolates the actual failure mode.

What usually breaks first is the developer's assumption that font scaling and layout spacing can share the same relative unit. They can't, not in production. I keep a checklist taped to my monitor: 'Is the break visible at 100% zoom? If yes, it's not scaling. Is the break visible only with non-default OS zoom? If yes, it's scaling. Is the break visible only when a specific font loads later? If yes, your font loading strategy is the problem—go fix that first.'

One rhetorical question to close this section: if you stripped all font-size overrides and used only the browser default, would your grid still look correct at 1100px? If the answer is no, you're hunting the wrong dragon.

FAQ or Checklist: Quick Reference for the Trenches

Quick diagnostic checklist

Before you blame the grid, run this five-step sequence in under two minutes. Open DevTools, set your viewport to 1440px, then scale it down to 320px—slowly. Watch the grid columns, not the text. If the layout holds but words overflow, the fault is almost certainly adaptive scaling. If the grid itself jumps or collapses, you have a viewport-unit or minmax() issue instead. The checklist: (1) toggle font-size between clamp(1rem, 2.5vw, 1.5rem) and fixed 16px—does alignment snap back? (2) check your base font on the `` element, not just on body text. (3) inspect computed values on any grid item that uses `ch` or `ex` units inside column tracks. (4) zoom to 200% and look for horizontal scrollbars triggered by one oversize word. (5) test in the browser your designer doesn't use—Safari handles sub-pixel font differently. Most teams skip step four. That hurts.

The tricky part is distinguishing between a scaling problem and a content-collision problem. I have seen layouts where the grid was mathematically perfect, yet a single long German compound noun blew the column width. We fixed this by applying `overflow-wrap: anywhere` on grid children—but only after confirming the clamp() was actually the culprit. Wrong order leads to days of CSS thrash.

Common questions about CSS clamp() and viewport units

Does clamp() always break grid layouts? No—but it exposes fragility. The formula `clamp(1rem, 2.5vw, 1.5rem)` works fine when your grid tracks use `1fr` or fixed lengths. Pair it with `minmax(20ch, 1fr)` and you invite conflict: the `ch` unit inherits from the computed font, which changes as the viewport shrinks. That creates a feedback loop. The grid track shrinks, the font shrinks, the `ch` value shrinks, and suddenly your 20-character target column holds 14 characters. What viewport unit should I use instead? Consider `cqi` (inline container query units) for components inside a constrained box—this decouples text scale from the full viewport width. Can I use clamp() inside grid template columns? Technically yes, practically not—you lose the ability to reason about column behavior. Reserve clamp() for font-size and padding. Let the grid manage widths.

One rhetorical question worth asking your team: "Would this layout survive if a user increased their default browser font to 24px?" If the answer is "probably not," you're over-relying on viewport-based scaling that your grid never accounted for.

'We spent three weeks tuning clamp() values only to realize our grid relied on line-height for vertical rhythm—and line-height doesn't scale the same way.'

— front-end lead on a dashboard project, after rollback to fixed rem units

When to accept scaling and adjust your grid instead

Sometimes the battle isn't worth fighting. If your users work on a narrow range of devices—say, a fleet of identical laptops or a single-screen kiosk—adaptive scaling is overhead you don't need. Lock font-size to `1rem` or `0.875rem` and move on. But if your audience includes power users who zoom, multi-screen analysts who resize constantly, or anyone using a 4K laptop at 150% scaling, fighting clamp() is a losing strategy. The pragmatic play: accept that font will scale, then redesign your grid to absorb that variance. Use `auto-fill` with `minmax()` that references `max-content` rather than `ch` units. Let columns stretch. Accept wider gaps at large viewports. You lose pixel precision, yes—but you gain robustness across environments where the user's font preference is not negotiable.

The next action: audit your most complex grid page using the checklist above. Identify one component where scaling and grid fight. Then either freeze the font on that component or refactor the grid tracks to tolerate a 30% swing in text size. Don't accept both instability and inflexibility—pick one and code accordingly.