Bug 284441 – WebKit ignores margin-top on 'legend' element (in fieldset)

• Component: Layout and Rendering
• Status: NEW

[Daniel Holbert]

STR:
1. Load https://bug1936475.bmoattachments.org/attachment.cgi?id=9442850

EXPECTED RESULTS:
100px of empty space above the legend.

ACTUAL RESULTS:
No empty space.

Firefox gives EXPECTED RESULTS; WebKit (and Chromium) give ACTUAL RESULTS.

It looks like WebKit and Chromium honor `margin` on all other sides of the legend; just not the top for some reason.

For reference, I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1936475 to investigate this on the Firefox side since we got a report (https://bugzilla.mozilla.org/show_bug.cgi?id=1935129) of a site that looks different-though-not-necessarily-broken in Firefox due to the site (maybe-inadvertently?) putting margin-top on a legend element. I also filed https://issues.chromium.org/issues/383368170 on this in Chromium.

[Karl Dubost]

This is even more interesting, because the margin is not added visually, but it is here in the getComputedStyle. 

```
window.getComputedStyle(document.querySelector('legend')).marginTop
# reports 100px
```

padding on the other end is taken into account on all sides. 

In `RenderBox.cpp` there is a special case for Legend, inside
`bool RenderBox::sizesLogicalWidthToFitContent(SizeType widthType) const {… }`
https://searchfox.org/wubkat/rev/a6aecb7cb3614074b11d5db8390698e4ef53b110/Source/WebCore/rendering/RenderBox.cpp#2956-2961

```
    // Button, input, select, textarea, and legend treat width value of 'auto' as 'intrinsic' unless it's in a
    // stretching column flexbox.
    // FIXME: Think about block-flow here.
    // https://bugs.webkit.org/show_bug.cgi?id=46473
    if (logicalWidth.isAuto() && !isStretchingColumnFlexItem() && element() 
         && (is<HTMLInputElement>(*element()) 
         || is<HTMLSelectElement>(*element()) 
         || is<HTMLButtonElement>(*element()) 
         || is<HTMLTextAreaElement>(*element()) 
         || is<HTMLLegendElement>(*element()))
        ) {
        return true;
       }
```

and in html.css

```
legend {
    padding-inline-start: 2px;
    padding-inline-end: 2px;
    border: none;
}
```

Ah probably more interesting `isLegend()` 
https://searchfox.org/wubkat/search?q=symbol:_ZNK7WebCore12RenderObject8isLegendEv&redirect=false
which triggers specific rules for layout computations including.
https://searchfox.org/wubkat/search?q=isExcludedAndPlacedInBorder&redirect=false

[Radar WebKit Bug Importer]

<rdar://problem/141267953>

[Karl Dubost]

Setting 

legend { margin: 100px;float:left} 

triggers interesting differences too. 
It's like a double margin was added inside the fieldset box.

[Karl Dubost]

Nice find Ahmad! Bug 9243
https://lists.w3.org/Archives/Public/www-style/2013Jun/thread.html#msg34

[Daniel Holbert]

There are two web-platform-tests that exercise this issue:
https://wpt.fyi/results/html/rendering/non-replaced-elements/the-fieldset-and-legend-elements/legend-block-margins.html
https://wpt.fyi/results/html/rendering/non-replaced-elements/the-fieldset-and-legend-elements/legend-block-margins-2.html

[Karl Dubost]

Created attachment 476670 [details]
rendering in safari, firefox

When I disable the green border. We can see the different position in the case of WebKit and Firefox. 

It's like the text legend contributes to the position. The top of the box text aligns with the legend.

[Karl Dubost]

Created attachment 476671 [details]
rendering in safari, firefox

Changing a bit the parameters of the boxes styles.

We can see better the relative position.