2

I am trying to set up a form that displays a vertical separator between two elements that appear side by side. These are the problem parameters:

  1. The height of either element is unknown and will change by virtue of the contents being modified with JavaScript in response to user interaction.
  2. The separator should cover the whole of the elements' shared vertical border, irrespective of which element happens to be taller at any given time.

Given the above it seems that this setup will do the trick:

<div>This is some text on top.</div>
<ol>
  <li id="a">Lalalala</li>
  <li id="b">Lololol</li>
</ol>
<div>And some text on the bottom.</div>

CSS

ol { overflow: hidden }
li { float: left; width: 5em; padding: 4px }
div { clear: both }

#a { background: gold; min-height: 100px }
#b { background: yellow; border-left: 1px black dotted }
#b { padding-bottom: 400px; margin-bottom: -400px } /* "infinitely" tall */

The idea is that the second element becomes "infinitely tall" by applying bottom padding and gets a left border; elements following the group are brought back into their original position by counteracting the padding with negative bottom margin; and the "unused" portion of the vertical border is hidden by giving the parent overflow: hidden.

This setup indeed works correctly (JsFiddle) on Firefox, Chrome and IE >=8 (my compatibility requirements):

Proof of concept

However, when I try to apply the same technique in my real HTML Firefox breaks down and seems to not honor the overflow: hidden set on the parent element. As a result the infinitely tall vertical border bleeds through all elements following the two panels on the page.

Here is a JSFiddle of (simplified) real copy/pasted content together with my actual CSS rules that shows the problem. Note that only Firefox mishandles this; other browsers continue to display it properly.

Correct render:

Correct render

Firefox render:

Firefox render

I am properly stumped: why would Firefox display the proof of concept correctly and botch the real deal? And how can I fix it?

Jon
  • 428,835
  • 81
  • 738
  • 806
  • 1
    Have you tried the search function? http://stackoverflow.com/questions/1673346/fieldset-firefox-overflow-css-fix http://stackoverflow.com/questions/19025873/how-come-overflowhidden-works-on-a-div-but-not-a-fieldset-in-firefox – Jarno Dec 09 '13 at 13:04
  • @Jarno Interesting link. This other question might point to a related bug but the solution/workaround doesn't seem obvious. The present question is still valid for me. – Denys Séguret Dec 09 '13 at 13:09
  • 2
    @Jarno: Actually I have, but without the benefit of hindsight it's not at all clear that one should include "fieldset" in the search -- it might filter out genuinely interesting results. In any case, thanks for the contribution. – Jon Dec 09 '13 at 13:13
  • Actually I've observed overflow related bugs in FF without fieldsets so a confirmation of how you work around the bug would be interesting. – Denys Séguret Dec 09 '13 at 13:14
  • @dystroy: Considering that the [bug](https://bugzilla.mozilla.org/show_bug.cgi?id=261037) is marked fixed in FF 27, I am very tempted to use the `-moz-hidden-unscrollable` hack as a stopgap measure right now; other browsers don't seem to mind, I won't have to add a hack into the HTML and future propects seem good: the hack won't stop working any time soon and when FF27 has established itself I can simply remove it. – Jon Dec 09 '13 at 13:19

1 Answers1

1

I was able to fix your JSFiddle by changing the fieldset element to a div or by surrounding the fieldset with a div that had overflow set to hidden. Maybe worth a try. Is the fieldset tag essential to your HTML?

devonnigelreed
  • 106
  • 3
  • 1
    Thanks for your input. The fieldset is essential and not subject to change. Surrounding it with another element would solve the issue but it introduces extra markup which in this case is undesirable. I will probably use another solution, but in the general case this could be fine. – Jon Dec 10 '13 at 12:12