Prompt and scope
You own a cross-browser card component. Modern browsers can render bevel, scoop, and squircle, while older browsers only understand border-radius. Explain the precondition for corner-shape, the fallback, and the visual and interaction acceptance plan.
This tests CSS geometry, progressive enhancement, and component engineering. corner-shape modifies corners produced by an existing border-radius; it has no effect when the radius resolves to zero. Separate painting, content layout, and pointer hit areas in the answer.
What the interviewer is testing
A strong answer keeps a usable border-radius baseline and layers the enhancement behind a feature query. It explains the one-to-four-value corner order, positive and negative superellipse() curvature, radius constraints when opposite corners overlap, and which painted effects follow the shape.
The interviewer also wants you to avoid treating the shape as a content clip. MDN notes that content is laid out against the original box and that hover can still apply outside the visible corner, so focus visibility and hit testing need their own checks.
Clarifying questions
What visual must older browsers preserve
If a rounded card is sufficient, keep border-radius. If brand geometry must match exactly, an SVG or pseudo-element fallback adds maintenance and rendering cost.
Does the shape define the interaction boundary
Confirm whether links, buttons, or drag targets must match the visible outline. A CSS corner shape does not necessarily change content or event hit testing, so a screenshot is not enough.
Are animation and RTL required
Check whether target browsers interpolate superellipse() and honor reduced-motion. Prefer logical corner longhands for multilingual layouts instead of assuming physical top-left is the inline start.
A 30-second answer
“I start with border-radius as the baseline and layer corner-shape inside @supports. The property changes painting of an existing radius, not content layout; browsers constrain radii when opposite corners would overlap, so I test extreme sizes. I separately verify focus rings, hit areas, and overflow, and provide feature and reduced-motion fallbacks for animation.”
Step-by-step solution
Step 1: Establish a degradable baseline
Write the base style first so cards retain border, background, shadow, and rounded corners without the new property. Add the enhancement behind a feature query:
.card {
border-radius: 24px;
background: var(--surface);
box-shadow: 0 8px 24px rgb(0 0 0 / 18%);
}
@supports (corner-shape: scoop) {
.card {
corner-shape: scoop notch;
}
}Unsupported browsers ignore the unknown declaration and keep the baseline. Do not put contrast, readable text, or essential instructions only in the enhancement.
Step 2: Explain value mapping and preconditions
One value applies to all four corners; two values form diagonal pairs; three values assign the third to the bottom-right; four values map top-left, top-right, bottom-right, and bottom-left clockwise. corner-shape depends on border-radius, so a zero radius produces no shape.
The superellipse() number controls curvature, with positive and negative directions producing convex and concave forms. In an interview, state that syntax names must be checked against rendered output in target browsers rather than inferred from a design tool label.
Step 3: Handle overlap and painting boundaries
When opposite corner radii and shapes would overlap, the browser constrains the radii to avoid a geometric collision. Test narrow cards, extreme percentage radii, and dense content so text, backgrounds, borders, and shadows remain coherent.
Backgrounds, borders, outlines, box shadows, overflow, and backdrop filters generally follow the corner shape. Content still follows the box model. If an image or interaction area truly needs clipping, use a separate clip-path, mask, or semantic hit layer.
Step 4: Test interaction and accessibility
The focus ring must remain visible and keyboard order, focus state, and pointer area should match across supported and fallback browsers. For a card that is a link, a full rectangular hit area is often more usable than a pixel-perfect outline; document that trade-off in visual tests.
Step 5: Animate and respect logical direction
Keywords may interpolate through equivalent superellipse values, but confirm implementation support. Give hover, focus, and state changes explicit durations and disable or shorten them under prefers-reduced-motion: reduce. Use logical corner longhands in multilingual components so RTL does not reverse the intended geometry.
Step 6: Build a compatibility matrix
Cover Chromium with support, partially supporting or unsupported browsers, narrow widths, long text, images, shadows, keyboard focus, touch hit testing, and reduced motion. Capture both enhanced and fallback states, recording whether the declaration applies, layout changes, and event targets remain consistent.
Model high-quality answer
I would make border-radius the product baseline and layer corner-shape through @supports. Older browsers still get a usable card, while the new shape improves appearance where supported. I would verify a nonzero radius, explain one-to-four-value mapping, and test narrow cards and extreme radii for overlap constraints.
I would not treat the corner shape as content clipping. Backgrounds, borders, and shadows usually follow it, but content layout and pointer hit testing need separate checks; the focus ring must stay visible. Animation gets a reduced-motion branch, RTL uses logical longhands, and the compatibility matrix compares visual, layout, keyboard, and touch behavior instead of relying on one modern-browser screenshot.
Common mistakes
- Symptom → Declare
corner-shapewithoutborder-radius→ Why it fails → No effective radius means no shape → Fix → Provide the rounded baseline first. - Symptom → Use
corner-shapeas image clipping → Why it fails → Content still follows the original box → Fix → Use overflow, clip-path, or a mask when clipping is required. - Symptom → Assume the visible corner shrinks the hit area → Why it fails → Events may still target the original box → Fix → Test keyboard, touch, and event targets separately.
- Symptom → Test one width only → Why it fails → Opposite radii can be constrained in a narrow container → Fix → Include extreme sizes and long text.
- Symptom → Show a blank card in unsupported browsers → Why it fails → Enhancement was treated as essential styling → Fix → Use a feature query over a stable baseline.
Follow-up questions and responses
Follow-up 1: What happens when border-radius uses percentages?
Verify the target browser's computed result instead of converting percentages to fixed pixels by assumption. Capture several aspect ratios to inspect overlap and shadow continuity. If the brand shape must be stable, use a controlled radius in the enhancement layer while retaining the base fallback.
Follow-up 2: How can the focus ring follow the shape?
First preserve visibility and contrast, then consider matching it with outline or a pseudo-element. If a technique clips the ring, keep a rectangular ring rather than sacrificing keyboard feedback.
Follow-up 3: What if corner-shape and border-shape are both declared?
W3C and MDN specify that border-shape makes border-radius ineffective, while corner-shape depends on border-radius. Treat them as alternative geometry paths and give the unused path a clear fallback instead of assuming they stack.
Follow-up 4: When would you avoid this property?
Avoid it when browser coverage is insufficient, the shape would affect required clipping, or the team cannot maintain visual fallbacks. Stable border-radius, SVG, or a pseudo-element can be the better choice when accessibility and performance goals are already met.