aboutsummaryrefslogtreecommitdiff
path: root/doc/bugs/map_fails_to_close_ul_element_for_empty_list.mdwn
blob: 940e56cab4651a26b815ee129b0477be67ed426d (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
[[!tag plugins/map patch]]

input:

    before.
    \[[!map pages="sdfsdfsdfsd/*"]]
    after.

Presuming that the pagespec does not match, output:

    <p>before.
    <div class="map">
    <ul>
    </div></p>

The UL element is not closed.

Patch:

    --- /usr/share/perl5/IkiWiki/Plugin/map.pm  2009-05-06 00:56:55.000000000 +0100
    +++ IkiWiki/Plugin/map.pm   2009-06-15 12:23:54.000000000 +0100
    @@ -137,11 +137,11 @@
            $openli=1;
            $parent=$item;
        }
    -   while ($indent > 0) {
    +   while ($indent > 1) {
            $indent--;
            $map .= "</li>\n</ul>\n";
        }
    -   $map .= "</div>\n";
    +   $map .= "</ul>\n</div>\n";
        return $map;
     }
     

-- [[Jon]]

> Strictly speaking, a `<ul>` with no `<li>`s isn't valid HTML either...
> could `map` instead delay emitting the first `<ul>` until it determines that
> it will have at least one item? Perhaps refactoring that function into
> something easier to regression-test would be useful. --[[smcv]]

>> You are right (just checked 4.01 DTD to confirm). I suspect refactoring
>> the function would be wise. From my brief look at it to formulate the
>> above I thought it was a bit icky.  I'm not a good judge of what would
>> be regression-test friendly but I might have a go at reworking it. With
>> this variety of problem I have a strong inclination to use HOFs like map,
>> grep. - [[Jon]]

>>> The patch in [[map/discussion|plugins/map/discussion]] has the same
>>> problem, but does suggest a simpler approach to solving it (bail out
>>> early if the map has no items at all). --[[smcv]]