Exercise 2: Explicit Width Is Independent of the Container — Possible Solution
====================================================================

THE TEST
------------------------------
    narrow = block({'width': '50px'})
    container2 = block({}, children=[narrow])

    layout_block(container2, root_containing_block)   # root width 300px
    narrow.dimensions.content.width
    container2.dimensions.content.width

RESULT
------------------------------
    narrow.content.width    -> 50
    container2.content.width -> 300

The child's own width (50) has no numeric relationship at all to the
container's own width (300) -- it's exactly the value written in the
CSS, unchanged.

WHY EXPLICIT WIDTH IGNORES THE CONTAINER ENTIRELY
------------------------------
calculate_block_width's own branch structure is:

    if width_str == 'auto':
        content_width = (containing_block.content.width
                          - margin.left - margin.right
                          - border.left - border.right
                          - padding.left - padding.right)
    else:
        content_width = parse_length(width_str)

The `else` branch -- taken here, since width_str is '50px', not 'auto'
-- never references containing_block at all. `parse_length('50px')`
returns 50.0 regardless of what value containing_block.content.width
holds. The containing block's own width is a completely unused input
for this specific code path.

WHY THIS IS FUNDAMENTALLY DIFFERENT FROM THE 'auto' CASE
------------------------------
The 'auto' case exists specifically to answer a question explicit
width never needs to ask: "since the author didn't specify a width,
how much space should this box actually take up?" That question can
only be answered by looking outward, at how much room is actually
available in the containing block -- which is exactly why the 'auto'
branch subtracts this box's own margin/border/padding FROM the
containing block's own width. An explicit width sidesteps that
question entirely: the author already answered it directly in the
CSS, so the algorithm has nothing left to infer from context. The two
branches aren't two variations on the same calculation -- they're
answers to two different questions, one of which happens to need the
containing block's own value and one of which doesn't need it at all.

A real consequence worth noting: because explicit width is
container-independent, a box CAN genuinely overflow or underflow its
own container this way -- a 500px-wide explicit box inside a 300px
container will happily compute content.width = 500, wider than its
own parent, with nothing in this chapter's own code preventing it.
Real CSS allows this too (it's normal, visible overflow behavior); the
'auto' case is the one specifically designed to avoid it by
construction, not because overflow is impossible in general.

WHY THIS WORKS AS AN ANSWER
------------------------------
Confirming container2's own width stays 300 (completely unaffected by
its child's own 50px width) additionally demonstrates that a PARENT's
own dimensions are computed independently of what its children end up
needing -- container2's width was already fixed before layout_block_children
was ever called, since calculate_block_width runs before
layout_block_children in layout_block's own four-step order. A child's
own explicit width can never retroactively change its parent's already-
computed width.