Exercise 2: A Genuine Specificity Tie Between UA and Author — Possible Solution
====================================================================

THE TEST
------------------------------
    elem2 = Element('h1', {})
    author_h1 = Stylesheet([Rule(['h1'], [Declaration('font-weight', 'normal')])])

    result2 = cascade_with_origin(elem2, UA_STYLESHEET, author_h1)
    result2['font-weight']

RESULT
------------------------------
    'normal'   -- the author's rule wins, despite an exact specificity tie.

WHICH COMPARISON DECIDES IT
------------------------------
Both the UA's own 'h1' rule (font-weight: bold) and the author's own
'h1' rule (font-weight: normal) are plain tag selectors -- both have
specificity (0, 0, 1), identical in every component. cascade_with_origin
builds each match as a 4-tuple:

    (origin, best_spec, order_counter, rule.declarations)

and sorts by `(m[0], m[1], m[2])` -- origin FIRST, specificity second,
order third. The UA rule's tuple starts with origin=0; the author
rule's tuple starts with origin=1. Since 0 < 1, the UA rule sorts
BEFORE the author rule in the "weakest first" ordering the cascade
uses -- meaning the author rule is treated as the STRONGER one and is
applied LAST, overwriting whatever the UA rule set.

Critically, Python's tuple comparison never even LOOKS at the second
element (specificity) here, because the first elements (0 vs 1) are
already different -- exactly the same lexicographic short-circuiting
Chapter 6 demonstrated for specificity's own (id, class, tag)
components. The tie in specificity is real, but it's never actually
reached during the comparison, because origin alone already settles
the outcome.

WHY THIS WORKS AS AN ANSWER
------------------------------
This is the cleanest possible demonstration that origin is a strictly
higher-priority tier than specificity, not merely a common special
case that happens to correlate with it: even when the two competing
rules are IDENTICAL in every specificity-related respect -- same
selector shape, same tag, same match -- origin alone is sufficient to
decide the winner outright. If cascade_with_origin's sort key were
ordered the other way, `(specificity, origin, order)`, this exact test
would still pass (since the specificities are equal, Python would fall
through to comparing origin next, and 0 < 1 would still make the
author entry sort as the "later/stronger" one) -- but that would be
accidental correctness for THIS particular case, not a design that
correctly reflects the real CSS spec, where origin outranks
specificity unconditionally, including in cases where the specificities
genuinely differ (as demonstrated in the chapter's own main example,
where the UA rule's specificity was actually HIGHER than the author's,
and the author still had to win).