Child Elements and Content in Pseudo-Elements
Pseudo-elements like ::before and ::after cannot contain real child elements. They are not part of the DOM and exist purely for styling purposes. You can only insert text or other content through the CSS content property.
Pseudo-elements cannot have nested HTML elements inside them.
The only content they can hold is inserted via the CSS content property, which supports text, counters, or attr() values.
They are ideal for decorative content, icons, or visual enhancements without altering the HTML structure.
You can style them extensively with CSS properties like color, background, position, transform, and z-index, but not add real DOM children.
In this example, the ::before pseudo-element inserts a star character before the paragraph text. You cannot insert another HTML element, only textual or generated content.
Use pseudo-elements to add non-interactive decorative content.
Do not attempt to insert real HTML elements; use content for text or symbols.
Combine with CSS styling for effects like icons, badges, or overlays.
Remember pseudo-elements are virtual and cannot respond directly to JavaScript events.
You're trying to add a star icon after a review rating using ::after, but you want to put a span inside it to style part of the icon differently — what happens, and how do you fix it?
I wrote CSS with ::before { content: '<div>Warning</div>'; } and nothing shows up — why?
How would you add a tooltip icon after a link using pseudo-elements if you can't nest HTML inside them?
Our design system uses ::before for decorative badges on buttons, but now we need to make them focusable and keyboard-navigable — why is this impossible, and what’s your workaround?
A teammate used ::after to inject a dynamic count badge, but it breaks when the content changes via JS — what’s the root cause, and how do you debug it?
We’re seeing layout shifts when pseudo-element content changes on hover — is this related to how pseudo-elements render, and how do you stabilize it?
We’re building a scalable component library and considering pseudo-elements for all decorative UI elements — what are the performance, accessibility, and maintainability tradeoffs compared to real DOM nodes?
How would you design a responsive tooltip system that works across browsers and screen readers, given that pseudo-elements can't contain interactive children?
A legacy component uses ::before to inject ARIA labels dynamically — now we’re migrating to a framework that manages DOM state, how do you refactor this without breaking accessibility?
Our design system has hundreds of components using pseudo-elements for icons and badges — we’re now scaling to support internationalization and dynamic content injection. What architectural changes would you propose to future-proof this without sacrificing performance or accessibility?
We’re evaluating a CSS-in-JS migration and need to decide whether to replace all pseudo-element-generated content with real DOM nodes. What long-term maintenance, team onboarding, and accessibility risks do you weigh?
A cross-team component library relies on ::after for visual indicators that are now required to be interactive — how do you drive consensus on a migration strategy that balances technical debt, UX, and legacy browser support?