Using the Adjacent Sibling Combinator
To change the style of a paragraph that immediately follows a heading, you can use the adjacent sibling combinator (+). This targets only the first element directly after the specified element.
Syntax: h1 + p selects the first <p> that immediately follows an <h1>.
Only the next sibling is targeted; other paragraphs or siblings are not affected.
Useful for styling content that follows headings consistently without adding extra classes.
How would you write CSS to make the paragraph right after an h2 turn red, but leave other paragraphs unchanged?
What happens if you use h1 ~ p instead of h1 + p? Can you explain the difference in behavior?
You applied the selector but the paragraph isn’t changing color — what are the first three things you’d check?
A designer says the paragraph after any heading should be styled differently, but now the styling breaks when we add a caption between the heading and paragraph — how do you fix it without changing the HTML?
Our team’s CSS file has 500+ rules — a paragraph after a heading stopped styling after a recent update. How would you debug which rule is overriding it?
We’re using a CMS that sometimes inserts empty divs between headings and paragraphs. How do you ensure the styling still works reliably?
We’re building a reusable content component that renders headings and paragraphs dynamically — how do you design the CSS to be robust against unpredictable DOM structure while keeping specificity low?
In a large-scale documentation site, we need to style paragraphs after headings differently based on section type — how would you structure the CSS to avoid specificity wars and enable theming?
How would you approach this problem if the headings and paragraphs are rendered by different micro-frontends with isolated CSS scopes?
We’re migrating a legacy site with hundreds of pages using inline styles and table-based layouts — how do you systematically enforce consistent heading-paragraph styling without breaking existing content or requiring full HTML rewrites?
Our design system needs to support multiple themes and accessibility modes — how would you architect the CSS layer to allow dynamic styling of heading-following paragraphs without increasing bundle size or runtime complexity?
A cross-team component library is being adopted company-wide, but different teams are using inconsistent heading hierarchies. How do you design a CSS strategy that scales across teams while minimizing maintenance overhead and enforcing semantic correctness?