kf-g-css-tak-responsive-rules

CSS Responsive Implementation Rules

This skill is for aligning the decision order of responsive CSS and reducing unnecessary breakpoints and ad-hoc unit choices. CSS is a suggestion to the browser, so prioritize Intrinsic adaptation first.

When to use this skill

When writing new CSS
When reviewing existing responsive implementations
When deciding how to use Media Queries and Container Queries differently
clamp() and when designing fluid values
svi svb cqi When reviewing unit choices such as
When checking whether AI-generated CSS contains dangerous responsive implementations

Decide first

Should that element be responsive in the first place?
Can it be made to work without queries?
Is the dependency the parent element's width, or the entire viewport?

Escalation order

Static

Elements that are essentially small and fixed, such as tags, badges, labels, icons, dividers, and fixed-size logos or avatars, should not be made responsive.
Adding clamp() or queries to such elements is excessive and only adds complexity.

Intrinsic

Use this with the highest priority.
auto fit-content min-content max-content Prioritize natural sizing using
flex-wrap: wrap、grid と auto-fit auto-fill minmax() Wrap naturally with
For fluid values, use clamp() min() max() to adjust smoothly.
Fixed width rather than max-inline-size, fixed height rather than min-block-size or aspect-ratio Prioritize
If there is a layer structure, first check whether it can be solved in a component-independent layout layer.

Container Queries

Use this when the same component is reused in multiple placement destinations.
Target elements whose appearance changes based on parent width, such as inside a sidebar, card, or modal.
Use this when you want to switch based on the width of the placement destination rather than the viewport.

Media Queries

Use this only when it cannot be solved with the higher-level methods.
Use this for macro layout changes across the entire page.
Use this for UI fixed to the viewport, or for blocks that only work at full page width.
Do not casually bring Media Queries into components that may be repositioned.

Designing container queries

Limit where they are applied

Apply only to the component root, or to a wrapper that is truly necessary.
Do not operate by adding container-type to everything just in case.
:scope When defining a container with something other than.sidebar-container , use a class name whose meaning is clear, such as
Do not use the class name .container for a generic wrapper.
html body Do not specify container-type or page-wide layout elements. Handle the page level with Media Queries.

Design with side effects in mind

The container itself cannot reference its own @container conditions. Use the container on the parent and the switch on the child.
container-type: inline-size は contain: inline-size , so applying it to elements whose width is determined by content tends to collapse the size.
inline elements,fit-content -dependent elements,flex-grow flex-basis unadjusted flex items, andauto or intrinsic grid items should be handled with care.
Do not give the container element padding や border ; offload the internal layout to child elements. This is because thresholds and cqi calculations tend to drift.
subgrid When you want to use it together with calc() .
In environments where legacy implementations remain, position: fixed may break, so do not hold fixed-position elements inside the container.
container-type: size is difficult to handle because it assumes a definite height, so in principle do not use it.
<source media> does not understand Container Queries. Handle image source switching based on the viewport or via markup branching.

Viewport units and container units

How to choose viewport units

For the horizontal direction choose svi dvi lvi, and for the vertical direction choose svb dvb lvb according to context.
If in doubt, prioritize svi と svb .
dvb tends to cause layout shifts, so use it only when the need is clear.
Even when always aiming for full screen height, prioritize fixed block-size rather than min-block-size .

Use viewport units in page context

Use viewport units in pairs with Media Queries and page-level decisions.
Use them for values that hold for the entire page, such as page margins, heroes, and full-width backgrounds.
Do not determine the inline-size block-size or font size of a component that gets repositioned using viewport units alone.

`cqi` Use the -family only when the container context is guaranteed

cqi Use it on the descendant side, and do not use it for the container's own self-sizing.
cqi If you use it, confirm that a corresponding container definition and @container conditions exist within the same component.
Do not use cqi in places where a valid query container cannot be guaranteed. This is because when unresolved it falls back to the small viewport basis and the meaning changes.
cqb cqw cqmin cqmax は size It is difficult to handle on the assumption of a container, so in principle do not use it.

Implementation notes

sv* dv* lv* Do not abuse the raw values of% or an intrinsic layout, prioritize that.
When using many viewport-unit-based fluid values, do not scatter the values directly; consolidate them into tokens or utilities.
When aiming for full screen width, first consider fixed inline-size rather than min-inline-size or an intrinsic layout.

Preferred techniques by layer

@layer pages Therefore, prioritize Media Queries.
@layer components Therefore, prioritize Container Queries.
Use Media Queries only as an exception for components that are inherently viewport-dependent, such as modals, toasts, and popped-over content.

How to Think About Breakpoints

Do Not Think in Device Categories

sp tablet pc Do not use device-first classifications such as.
Decide breakpoints at the positions where the content breaks down.

`rem` と `calc()` Use

The unit for breakpoints is rem .
calc(640 / 16 * 1rem) As in, px-derived values are calc() convert while preserving the meaning.
Write thresholds not as magic numbers, but as conditions for the layout to hold, such as column count, minimum width, gap, and margins.
clamp() min() max() Inside, too, if it adds meaning, calc() decompose into an expression with.

Checklist for AI Output

Are the thresholds not device-convention values, but conditions for the layout to hold?
Are the necessary elements such as gap, column count, and padding included in the expression?
Simply calc(48rem) fake just wrapped as calc() isn't it?

Fluid Sizing

clamp(min, preferred, max) Use to smoothly interpolate between the minimum and maximum values.
For the preferred value, in places where readability is important, use rem + 相対単位 in total.
Use viewport units for page-level fluid values, and cqi use separately for component-level fluid values.
Do not put only relative units directly into font size. Always fix the minimum with rem .

font-size: clamp(
  14 / 16 * 1rem,
  0.00455 * 100svi + 12.18 / 16 * 1rem,
  18 / 16 * 1rem
);

If you have unitless tokens, within the property value combine custom properties and calc() may be used to build the slope and intercept.

Layout pattern

Avoid Fixed Sizes

Fixed width instead of max-inline-size use.
Fixed height instead of min-block-size or aspect-ratio use.
When fixed values are needed, min(100%, var(--_size)) think about overflow prevention first.

`zoom` Is the Last Resort

zoom Use only when breakage cannot be avoided even after trying Intrinsic, Container Queries, and Media Queries.
Use it only for component roots whose assumed minimum width is clear.
Use it only in contexts where a query container is guaranteed.
zoom は 1 as the upper limit, and do not use it for enlargement.
Do not use it as a substitute for shrinking text size with viewport units.
progress() Keep it readable and operable even in unsupported environments.

Policy for Output

First, specify where to solve it among 0 to 3.
If you add Media Queries, explain why Intrinsic or Container Queries are not enough.
If you add Container Queries, clarify which element is the container and which child is switched.
If there is a problem with existing code or AI output, do not just rewrite it; briefly explain what is dangerous about it.
If there is an existing layer structure or naming convention, do not break it.

Final check

Does that element really need to be made responsive?
Have you tried intrinsic methods first?
Have you separated parent-width dependence from viewport dependence?
Are Media Queries really page-level or viewport-dependent requirements?
zoom Are you not using as an easy escape route?

References

TAK - CSS Responsive Rules