Clipped Scrollbar and Border in Webkit

Part of the textarea scrollbar and border is cut off:

<!DOCTYPE html>
<html>

<head>
    <meta charset="UTF-8">
    <title>Clipped Scrollbar and Border in Webkit</title>
    <style>
        textarea,
        iframe {
            display: block;
            width: 300px;
            margin: 0;
            padding: 0;
        }
        textarea {
            height: 200px;
            resize: none;
            outline: 0;
            border: solid red;
            border-width: 0 0 5px;
        }
        iframe {
            height: 0;
            border: 0;
        }
    </style>
</head>

<body>
    <textarea>
        <p>Hello, world!</p>
        <p>Hello, world!</p>
        <p>Hello, world!</p>
        <p>Hello, world!</p>
        <p>Hello, world!</p>
        <p>Hello, world!</p>
        <p>Hello, world!</p>
        <p>Hello, world!</p>
        <p>Hello, world!</p>
        <p>Hello, world!</p>
        <p>Hello, world!</p>
        <p>Hello, world!</p>
        <p>Hello, world!</p>
        <p>Hello, world!</p>
        <p>Hello, world!</p>
        <p>Hello, world!</p>
        <p>Hello, world!</p>
        <p>Hello, world!</p>
        <p>Hello, world!</p>
        <p>Hello, world!</p>
        <p>Hello, world!</p>
    </textarea>
    <iframe srcdoc="<p>xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx</p>"></iframe>
</body>

</html>

DEMO

Why does it happen? What’s the fix?

Hi there Rain Lover,

The cause of your problem appears to be…

[color=navy]
iframe {
    height:0;
    border:0;
 }
[/color]

If you don’t want it behave oddly, why not just use this instead…

[color=navy]
iframe {
    display:none;
 }
[/color]

coothead

Hi,

Another weird chrome behaviour :slight_smile:

If you add position:relative to the textarea then the iframe drops behind it and doesn’t cover the scrollbar on the textarea any more. Or perhaps better position:relative on the iframe itself seems to cure the problem.

Once you set the iframe back to height auto (or height greater than about 5px) then it behaves correctly again anyway (if that’s what you were going to do).

Chrome is definitely having problems there because if you add a margin-top to the iframe (in your code) you can see the top right corner of the iframes scrollbar only.

Perfect – as always! :slight_smile:
Seems like a z-index problem: the textarea scrollbar bottom and border hide behind the iframe horizontal scrollbar when they overlap:
DEMO

What do you think?

The main ‘strangeness’ is that they shouldn’t really overlap at all as there is no positioning involved. I’m guessing that because the height is zero then the calculation to accommodate a scrollbar are throwing Chrome out.

Position relative on just the iframe seems to cure it and if it was a z-index issue that should put the iframe back on top but it doesn’t. It probably triggers a more involved algorithm and tidies up the mess it made when it was non positioned (similar to IE of old).

However that’s just a guess :slight_smile:

I just realized we can resolve the issue for height:0 by:

iframe::-webkit-scrollbar-corner {
    background:transparent;
}

But the problem is if you change the iframe height to 1px, for example, the “overlapping” issue appears again. :frowning:

Yes, its a nasty Chrome bug. I think the only thing you can do is make sure that the iframe is about 15px away from the element above so that it dosen’t overlap.

Overlapping doesn’t seem to be limited to positioned elements or a certain browser. Elements scrollbars and borders can overlap. Just for instance try the following in Firefox:
DEMO

I think that’s more an issue of the contents of the element being bigger than the width you prescribed. Remember that overflow is visible by default so anything that doesn’t fit will spill out and overlap.

e.g.


textarea {
    border: 0 none;
[B]    overflow: hidden;[/B]
    resize: none;
    width: 2px;
}

Browsers historically have had a little problem with scrollbars and where to put them. Some used to put them outside the element and some inside. It’s not surprising that in edge case example we get these discrepancies.

The issue is resolved in the latest version of Chrome.

Great :slight_smile: