1

I think there is a bug in Chrome with the <label> element:

<div style="border:1px green solid; overflow:hidden;height:20px;">
  <div style="border:1px red solid;">
    <div>visible</div>
    <div style="position:absolute; border:1px solid;">
      <div style="position:relative;">
        ffff
        <label><input type="checkbox" name="check" /> click label to see hidden content</label>
      </div>
    </div>
    <div>hidden</div>
  </div>
</div>

When you click on the checkbox itself, Chrome scrolls content to the position of the input control. Why does Chrome do this while other browsers (IE, Firefox) work correctly?

TylerH
  • 20,799
  • 66
  • 75
  • 101
Majid Majed
  • 326
  • 2
  • 12
  • 1
    Verified on Linux Chrome. This is indeed strange. – Michael Hobbs Jan 31 '16 at 10:41
  • 1
    Wow, That's crazy. Some how the element `
    visible
    ` is getting pushed up.
    – rrk Jan 31 '16 at 10:43
  • Verified on Win10 Chrome – Jens Meinecke Jan 31 '16 at 10:45
  • This happens even when the placing the block inside a normalized html doc. – Michael Hobbs Jan 31 '16 at 10:50
  • The browser thinks the checkbox is not visible so it scrolls the parent down. Kind of an edge case but definitely a bug though so it should be reported to the bug tracker rather than here. – JJJ Jan 31 '16 at 10:51
  • 1
    This is very interesting. You do not even have to click on the label and I think this is the clue. Reload the page and then hit tab, you will see the same behavior. – Michael Hobbs Jan 31 '16 at 11:06
  • 2
    I don't see it exactly as a bug, it's scrolling the div inside overflow:hidden to the form control when the label is clicked, wich is normal behaviour... Remove this inner div and the beahaviour disappear (because it don't scroll the overflow:hidden div). – miguel-svq Jan 31 '16 at 11:20
  • 1
    I kind of agree with miguel-svq. The label is propagating a page scroll to the input when clicked, Seems like a normal behavior. [dramatic example](https://jsfiddle.net/2aa4m233/) – mattdevio Jan 31 '16 at 11:30
  • @miguel-svq: What evidence is there to suggest that this is normal (or *expected*) behavior? Does that mean the bug is in other browsers not scrolling the hidden content into view? – BoltClock Jan 31 '16 at 11:33
  • @BoltClock see my answer. – Michael Hobbs Jan 31 '16 at 11:38
  • 1
    Why should the div with overflow: hidden scroll when it's not the containing block of the absolutely positioned element, and therefore the checkbox has absolutely nothing to do with any of the content inside that div? – BoltClock Jan 31 '16 at 11:41
  • This feels it falls under bad practice anyways. Why nest form controls inside their label? I understand that nesting an input inside of a label removes the need for an id; however, i see the `for` attribute as a symbolic link between the label and the the form element. If we can't decide as a community that this is allowed (nesting input fields), we have to lean toward the side of avoidance. – mattdevio Jan 31 '16 at 11:44
  • @magreenberg: The community doesn't need to decide because this behavior has been defined by the spec since the label element was first introduced - https://www.w3.org/TR/html401/interact/forms.html#h-17.9.1 – BoltClock Jan 31 '16 at 11:46
  • @magreenberg This question has nothing to do with nesting or not nesting the input inside the label. It behaves exactly the same both ways. – JJJ Jan 31 '16 at 11:47
  • @BoltClock: There is not really hidden content, just content out of the scroll area. About focus, HTML specification, sections 7.4, 17.9.1, 17.11... (and all browsers scroll to focused items, but with those "edge-case" we could get different results) – miguel-svq Jan 31 '16 at 11:51
  • @miguel-svq: If you're saying that Chrome is thinking of this in terms of the DOM and not the visual formatting structure, then I see where you're coming from. – BoltClock Jan 31 '16 at 12:02
  • All this really is, is an example of terrible HTML/CSS and what not to do. Sure if you nest and use many different positioning along with attributes like overflow: hidden I am quite sure you can come up with unexpected behavior. It also has nothing to do with clicking as pressing Tab / Shift Tab generates the same results. – Michael Hobbs Jan 31 '16 at 14:57
  • according to the spec "In the absolute positioning model, a box is explicitly offset with respect to its containing block. It is removed from the normal flow entirely (it has no impact on later siblings)." the absolute positioned element is contained inside body so scrolling another div is kind of weird.In my opinion while both of label and input control are in the same container, there is no need to scroll enything else. – Majid Majed Jan 31 '16 at 19:00

1 Answers1

0

As @miguel-svq pointed out the box is being scrolled and the correct behavior. According to the MDN docs: https://developer.mozilla.org/en-US/docs/Web/CSS/overflow we see that overflow: hidden also hides the scrolls. If anything this is a bug in FireFox which I tested this against and it does not scroll the box as expected. You can verify this with the following:

    <div style="border:1px green solid; overflow: hidden; overflow-y: scroll; height:20px;">
        <div style="border:1px red solid;">
            <div>
                vivsible
            </div>
            <div style="position:absolute; border:1px solid;">
                <div style="position:relative;">
                    ffff
                    <label><input type="checkbox" name="check" /> click label to see hidden content</label>
                </div>
            </div>
            <div>hidden</div>
        </div>

    </div>
Michael Hobbs
  • 1,663
  • 1
  • 15
  • 26