Can the adjacent sibling combinator select multiple elements? Write an example using the adjacent sibling combinator.

You're styling a blog post and want to add top margin only to the first paragraph after each heading. How would you use the adjacent sibling combinator to do that without affecting other paragraphs?

If you write h2 + p { color: blue; } but the blue color doesn't appear, what are two things you'd check in the HTML structure?

You have two divs back-to-back: <div>A</div><div>B</div>. What CSS rule would make only div B have a red border?

A designer says the spacing between section headers and their first paragraph is inconsistent across pages. You notice some headers have a span before the paragraph — how would you debug why your h2 + p rule isn't working in those cases?

You're building a responsive FAQ component where each question is a button and each answer is a div right after it. You use button + div to show/hide answers, but when a user clicks a button, JS inserts a loading spinner between them. What breaks and how do you fix it without changing the HTML?

Your team uses adjacent siblings to style form elements like label + input. But now you need to add a helper text element between them. How do you adjust your CSS without rewriting all selectors?

You're designing a reusable content block component that must support both markdown and CMS-generated HTML. The adjacent sibling combinator works in clean markup but fails when editors insert comments or whitespace nodes. How do you architect this to be robust without relying on JS?

A legacy UI uses adjacent siblings for vertical spacing between elements. As the system scales, you notice performance issues on mobile with 50+ sibling chains. Is the combinator itself the bottleneck, and what alternative approach would you propose for layout consistency?

You inherit a CSS suite where adjacent siblings are used heavily for typography hierarchy. New components are being added with dynamic content that sometimes inserts spans or divs between elements. How do you refactor this to be maintainable and predictable without breaking existing styles?

Your company is migrating from a legacy CMS that outputs non-standard HTML to a modern headless system. The old CSS relied on adjacent siblings for layout, but the new output sometimes wraps elements in extra divs. How do you design a migration strategy that preserves styling fidelity while enabling future flexibility?

You're leading a design system overhaul where adjacent sibling rules are used across 20+ components for spacing. Stakeholders want to adopt CSS Grid and custom properties. How do you phase out the combinator dependency without introducing visual regressions or requiring a full rewrite?

An external team uses your component library and has started overriding your adjacent sibling styles with !important in their app. How do you architect your CSS architecture to prevent this kind of cascade pollution and ensure long-term maintainability across teams?