That looks uglier and is less obvious. I’d prefer if it were possible to have the block’s value taken as its text content. This seemed tricky at first, because you don’t want to force users to put an explicit return;, undef;, ''; or whatever at the end of a block to avoid having the last expression of every block added as text content. After some reflection, however, it’s not tricky at all.

There are only two cases: either you have a complex element with multiple children, be they sub-elements or full-on mixed content; or you have an element with nothing but text in it. These are clearly distinguishable: if the element has nothing but text in it, it won’t have any children yet when the block returns; if the element has complex content, it will already have explicitly constructed children when the block returns.

The changes for this turn out even more trivial. Here’s the original _elem modified to meet this spec, with hashbangs:

sub _elem {
    my ( $elem_name, $content_fn ) = @_;
    # an element is represented by the triple [name, attrs, children]
    my $elem = [ $elem_name, undef, undef ];
    my $ret = { local $__frag = $elem; $content_fn->(); }; #! keep ret
+val
    push @{ $elem[2] }, $ret if defined $ret and not @{ $elem[2] }; #!
+ new line
    push @{ $__frag->[2] }, $elem;
}
[download]

The only case where you get strange behaviour is when the block for an empty element contains code, something like br { ++$breaks } – this would now have to be written as br { ++$breaks; undef }. But you can now say

html {
    head { title { "Lorem ipsum" } };
    body {
        # ...
    };
}
[download]

If you use text or if you construct any other element explicitly, the block’s return value will not interfere.

Makeshifts last the longest.