Explain an HTML structure, a block of CSS, or both together, covering the nesting and cascade rules a browser uses to decide what renders.
You are a front-end instructor who has watched students get the visual result they wanted through trial and error, nudging a margin here and adding an extra class there, without ever building a mental model for why any of it worked, which holds together fine until one small change breaks the whole page and there is nothing to reason from. Work in [MODE:select:explain the HTML structure,explain the CSS styling,explain both together] mode. My code is: [CODE] If I left [CODE] blank, ask me to paste it before doing anything else instead of inventing markup or styles to explain in its place. If I chose to explain the HTML structure, walk through the elements in nesting order, describing the document the way a browser builds it, this element contains these children, which contain these children in turn, rather than describing tags in the flat order they appear as text. For any semantic element, such as `nav`, `header`, `main`, `section`, or `article`, explain what that tag communicates that a generic `div` would not, both to a browser's accessibility tree and to another developer reading the code. Point out any attribute that does meaningful work, such as `id`, `class`, `href`, `src`, or `alt`, and what role it plays. If I chose to explain the CSS styling, do not walk through the rules in the order they are written in the file. Instead, for each element that has visible styling, determine which selector actually wins under the cascade, and explain it using the real precedence order, inline styles first, then the selector with the highest specificity, calculated from the count of IDs, classes, and element types in the selector, and only when specificity ties does the rule that appears later in the file win. State the winning selector and the specificity reasoning in plain terms before describing what it does. For any property affecting size or spacing, `margin`, `padding`, `border`, or `width`, explain it in terms of the box model, that padding and border sit inside the declared width while margin sits outside it, unless `box-sizing: border-box` changes that. If the code uses `flex` or `grid`, describe the layout in terms of a container handing out space to its children along one or two axes, rather than listing each property in isolation. If I chose to explain both together, connect the two explanations, for each meaningful HTML element, state which CSS selector or selectors target it and which one wins, so I can see the structure and the styling as one system instead of two separate documents that happen to reference each other. Close by asking whether a specific visual result in my head does not match what the explanation says the code should produce, since that mismatch is usually the exact bug worth digging into, and offer to trace just that one element's styling in more detail if so.
Use this prompt anywhere
10,000+ expert prompts for ChatGPT, Claude, Gemini, and wherever you use AI.
Get Early AccessCSS rarely fails loudly. A style you expected to apply just quietly loses to a different rule, and without understanding the cascade, the only available strategy is trial and error, nudging a value and reloading the page until something looks right. That approach works until one small change breaks a layout that was never actually understood in the first place.
This tool explains CSS in the order the browser actually resolves it, not the order the rules are written in the file. For each styled element in your [CODE], it works out which selector wins using real specificity rules, inline styles first, then the count of IDs, classes, and element types in a selector, with ties broken by which rule appears later. It states the winning selector and the reasoning before describing what the rule does, and explains spacing properties through the actual box model instead of listing margin and padding as unrelated settings.
The HTML mode walks the document the way a browser builds it, parent to child, and explains what semantic tags like nav or article communicate that a generic div doesn't. Choose both together and it connects structure to styling, showing exactly which selector targets which element and why. Run it in the Dock Editor to build a reference of explained layouts, pair with the code explanation generator for the JavaScript that manipulates this markup, or the javascript code explainer once static markup needs to become interactive.
Drop your markup, your styles, or both together into [CODE]. Leaving it blank prompts a request for real code instead of an invented example.
Set [MODE] to HTML structure for the document tree, CSS styling for the cascade and box model, or both together to connect elements to the selectors that style them.
HTML explanations follow parent-to-child nesting the way a browser builds the page, not the flat top-to-bottom order tags appear as text.
CSS explanations state the winning selector for each element using real specificity rules, inline styles, then ID count, then class count, then element count, with ties broken by file order.
If a visual result in your head doesn't match what the explanation says the code should produce, flag that element and get a deeper trace of exactly what's overriding what.
Paste a full page and use both together mode to see the document structure and the styling that targets it as one connected system instead of two separate files.
You added a CSS rule and nothing changed. Use CSS styling mode to see which selector is actually winning under the cascade and why your rule is losing to it.
Margins and padding aren't behaving the way you expect. Get spacing properties explained through the actual box model, what's inside the declared width and what's outside it.
Understand why a codebase uses nav, main, and article instead of div everywhere, and what those tags communicate to browsers and accessibility tools that a generic div doesn't.
Discover more prompts that could help with your workflow.
Build a small working program that calls a real public API, with the request, response, and API key setup explained step by step.
Explain a core functional programming idea, such as pure functions or immutability, with a broken code example and its fixed version shown side by side.
Explain a built-in math function, square root, power, absolute value, or rounding, covering math and syntax, then generate practice calls to predict before revealing results.
10,000+ expert-curated prompts for ChatGPT, Claude, Gemini, and wherever you use AI. Our extension helps any prompt deliver better results.