12

I'm working with textareas on mobile safari and when a textarea is focussed the viewport seems to add padding underneath the document. When inspecting and selecting the area, it doesn't resolve to an element, or even the html node.

It doesn't seem to matter where the textarea is on the screen or whether or not it is absolutely position, the padding is always present when its focussed. You sometimes have to scroll down to make it visible, but ideally it shouldn't be possible to make it visible at all.

I've added an example with screenshots and code below. There is a cover that is 100% width and height to show where the regular bounds of the document are and the textarea is absolutely positioned at the bottom of the body.

Unfocussed: Unfocussed

Focussed (with arrow pointing to unwanted padding): enter image description here

Code:

<html>
  <head>
    <meta name="viewport" content="user-scalable=no, width=device-width" />
    <style>
      html{
        background-color: gray;
      }

      body{
        width: 100%;
        margin: 0px;
      }

      #cover{
        position: absolute;
        top: 0px;
        left: 0px;
        width: 100%;
        height: 100%;
        display: block;
        background-color: green;
      }

      #textarea{
        position: absolute;
        bottom: 0px;
        left: 0px;
        width: 100%;
        height: 100px;
        display: block;
        margin: 0px;
        font-size: 18px;
      }
    </style>
  </head>
  <body>
    <div id="cover">Cover</div>
    <textarea id="textarea"></textarea>
  </body>
</html>

I'd appreciate any insights people have. Thanks.

Marcus
  • 778
  • 9
  • 20
  • While I have no iPone, intuitively I would say add `html, body { width: 100%; height: 100%; margin: 0; padding: 0 }` at the top of your CSS to kill any default spacing and size to full screen. Maybe even add `overflow: hidden` to your `body`. When html/body have no specific height, some browser don't know what `height: 100%` in a child means, no initial height to refer to. – Rene van der Lende Nov 22 '15 at 14:02
  • I've noticed that if I add `` and pin the page to the iPhone home screen as a web app, the padding isn't there. I think this points to it being a bug in mobile safari. I had thought this originally because scrolling to make this padding visible would sometimes jerk. – Marcus Nov 26 '15 at 07:45
  • 1
    I have this issue as well. Did you manage to find a fix for it? – sammiepls Oct 31 '18 at 08:47

4 Answers4

4

I don't think this is solvable with CSS, it seems to be Safari chrome.

When I test it on an actual device (6+) the space at the bottom is white. I played with some :focus styles with positioning, and found I was only cutting off the container.

#textarea:focus {
  border-bottom: 14px solid red;
  bottom: -6px; //shows 1px of border
  //bottom: -7px; //shows no border
}

You can play here. http://codepen.io/ArleyM/pen/NGmbWW?editors=110

As far as a solution goes this is a design problem, I wonder if there's a way that you can use this white space to your advantage. Users will be focussed on what they're entering, you can make this look good :)

ArleyM
  • 855
  • 5
  • 15
0

That looks like iPhones input zoom feature causing that padding...

Check the answers here: Disable Auto Zoom in Input "Text" tag - Safari on iPhone

It seems setting the input field font to 16px disables this feature.

Community
  • 1
  • 1
bfritz
  • 2,416
  • 2
  • 20
  • 29
  • I've got the textarea's `font-size` set to 18px in the example code, so it doesn't seem to be the input zoom effect. I've also got `user-scalable=no` in the viewport meta tag, which should disable zooming completely. – Marcus Nov 27 '15 at 12:11
  • @Marcus You have to set the font-size to 16px to disable zooming... That's what the entire thread I linked was about, there is some "glitch" that ignores all user-scalable for inputs unless you do so apparently. – bfritz Nov 27 '15 at 12:22
  • I've got a codepen with the fixes that thread suggests here: http://codepen.io/anon/pen/epwbYP. It doesn't seem to make any difference. – Marcus Nov 27 '15 at 12:44
  • @Marcus I would recommend dropping the input tag and using an editable div...
    might not have the issue the input is giving you. https://jsfiddle.net/ThinkingStiff/AbKTQ/
    – bfritz Nov 27 '15 at 13:55
  • `contenteditable` doesn't seem to be any different. I think it's just Safari's response to having any focused input. It doesn't even matter where it is on the screen either. – Marcus Nov 27 '15 at 16:01
0

I've answered on another question with same issue.

But I'll answer it here also:

body {
  min-height: 100vh;
  min-height: -webkit-fill-available;
}
html {
  height: -webkit-fill-available;
}

-webkit-fill-available;

makes the "magic"

eboye
  • 318
  • 4
  • 10
-3

At the top of your css styles add this:

html, body, div, span, applet, object, iframe,
h1, h2, h3, h4, h5, h6, p, blockquote, pre,
a, abbr, acronym, address, big, cite, code,
del, dfn, em, img, ins, kbd, q, s, samp,
small, strike, strong, sub, sup, tt, var,
b, u, i, center,
dl, dt, dd, ol, ul, li,
fieldset, form, label, legend,
table, caption, tbody, tfoot, thead, tr, th, td,
article, aside, canvas, details, embed, 
figure, figcaption, footer, header, hgroup, 
menu, nav, output, ruby, section, summary,
time, mark, audio, video {
    margin: 0;
    padding: 0;
}

You should always do a reset at the top of your styles

The Beast
  • 1
  • 1
  • 2
  • 24
  • I added that reset and it didn't affect anything. I thought something similar too. I tried a lot of different combinations, but inspecting the elements showed that none had any margin or padding. – Marcus Nov 26 '15 at 07:49
  • @Marcus is there a way you can upload it to the internet i can probably figure out the problem – The Beast Nov 26 '15 at 23:14
  • @Marcus Do you use media querys? – The Beast Nov 26 '15 at 23:30
  • Not in the example causing this problem. If you're running on a Mac you can open the page I provided in the iOS Simulator. – Marcus Nov 27 '15 at 07:52
  • that is what i always use and i don't have problems like this – The Beast Nov 29 '15 at 04:27