I do marketing for HelloAI (https://tryhello.app), the app in this test. Insider test, not a neutral review. Short version: I asked for a CSS specificity cheat sheet, it produced an editable document, and every claim in it survived a check against MDN. Here is exactly what it gave me, and the check.

The prompt

Make me a CSS specificity cheat sheet with about 10 worked examples. For each example selector, show its specificity as a-b-c (ID, class, type) and one line on why. Include at least: a plain element selector, a class, an ID, an attribute selector, a pseudo-class like :hover, a :not() with an argument, a descendant selector, a combined selector like ul#nav li.active, an inline style case, and an !important case. End with a short "who wins" section for three conflicts.

The output

It opened an editable document (they call it Canvas) with this table:

Selector or case Specificity Why
p 0-0-1 One type selector
.note 0-1-0 One class selector
#header 1-0-0 One ID selector
[type="text"] 0-1-0 Attribute selectors count like classes
a:hover 0-1-1 :hover counts like a class, and a is a type
p:not(.muted) 0-1-1 :not() itself adds nothing; its .muted argument counts, along with p
main p 0-0-2 The descendant combinator adds nothing; the two type selectors count
ul#nav li.active 1-1-2 One ID, one class, and two type selectors
button.primary:hover 0-2-1 Two class-level selectors plus one type selector
Inline style="color: red" outside the a-b-c score Inline styles outrank normal author stylesheet rules
.notice { color: red !important; } selector is 0-1-0, plus important !important is not specificity; it changes cascade priority and beats normal declarations

Then three "who wins" conflicts:

  • p { color: blue } vs .note { color: green } - .note wins (0-1-0 beats 0-0-1)
  • #nav li vs ul#nav li.active - ul#nav li.active wins (1-1-2 beats 1-0-1)
  • p { color: blue !important } vs #main p { color: red } - the !important declaration wins despite the lower selector score

The MDN check

I verified each row against MDN's specificity page:

  • The column rules match: an ID column, a class column (classes, attribute selectors, pseudo-classes), and a type column (elements and pseudo-elements).
  • [type="text"] at 0-1-0: MDN uses [type="password"] as its own 0-1-0 example.
  • a:hover at 0-1-1: same shape as MDN's input:focus example.
  • The :not() row: :not() itself adds nothing; only its argument counts. Correct here.
  • The descendant combinator adds nothing. Correct.
  • The tie-break ("if specificity ties, the later rule wins, assuming the same cascade origin and importance") matches.
  • On inline styles, MDN also describes them as a hypothetical 1-0-0-0 when it extends the notation. The sheet kept them outside the a-b-c score instead and said why. Different presentation, same rules.

Wrong rows in this run: zero.

The honest limits

One run of one prompt, free plan, about 300 words of output. It says nothing about the next prompt or a harder one. The document is editable, which matters more than it sounds: I could have fixed a wrong row in place instead of re-prompting. This time there was nothing to fix.

Why I check generated references at all

Specificity is a topic where an almost-right cheat sheet quietly costs you an afternoon. Whatever tool you use, verify a reference before you trust it. This one happened to survive.

The app: https://tryhello.app (free plan, no card)