Chrome and FF align input elements in table-cells differently
Reported by
kandalka...@gmail.com,
Jul 2
|
||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36 Example URL: https://jsbin.com/kusuzitode/1/edit?html,output Steps to reproduce the problem: 1. Open link https://jsbin.com/kusuzitode/1/edit?html,output 2. Open same link in FF and check layout difference. 3. Alignment of both <input> element should be in same line. 3. To fix layout in Chromium, add float : left to <input> element inside div with blue border.(FF works fine without this change) Other issue might be similar to current behaviour : https://bugs.chromium.org/p/chromium/issues/detail?id=798478 What is the expected behavior? Both <input> elements should be in same line What went wrong? <input> element on right side in blue bordered div is moved somewhat down. Does it occur on multiple sites: N/A Is it a problem with a plugin? No Did this work before? N/A Does this work in other browsers? Yes Chrome version: 67.0.3396.99 Channel: stable OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version:
,
Jul 6
Able to reproduce the issue on reported chrome version 67.0.3396.99, on latest chrome 69.0.3483.0 using Windows 7 & 10, Mac 10.13.5 and Ubuntu 17.10. Same behavior is seen on M60(60.0.3112.113) hence considering it as non-regression and marking it as Untriaged. Thanks!
,
Jul 9
Behavior is identical in legacy and NG. Over to our resident float expert for triage.
,
Jul 9
This isn't a float issue, this testcase can be simplified down to:
<!DOCTYPE html>
<div style="display: table;height: 36px;">
<div style="display: table-cell;border:1px solid red;">
<button style="height: 28px;">
</div>
<div style="display: table-cell;border:1px solid green;">
<div style="height: 100%;border:1px solid blue;">
<input type="text" style="display: block; height:28px">
</div>
</div>
</div>
This is likely a quirk of how tables behave, and wouldn't be a web-compatible change to fix, given that Edge also has this behaviour.
But dgrogan might be able to confirm.
,
Jul 10
This is due to FF calculating baselines differently from Chrome/Edge. I'm not sure how button and input element baselines are supposed to work, but I don't think it's a tables issue. http://jsfiddle.net/dgrogan/dyc7a19b/2/ has some notes (you might be able to just use vertical-align:top as a non-surgical sledgehammer for your case) +forms Component to see if they know what's going on with input text/button baselines and if FF or Chrome/Edge are doing it right, or known issue, or what.
,
Jul 10
,
Jul 10
Is this specific to form controls? I saw similar behavior if I replaced <button> with non-empty <span>, and <input> with non-empty <span>. Basically empty form controls act like they have child text.
,
Jul 10
> Basically empty form controls act like they have child text. I don't think this is 100% true -- look at "original" vs "Button with text..." in http://jsfiddle.net/dgrogan/dyc7a19b/5/. The only difference is adding child text to the button, which appears to change the baseline.
,
Jul 10
Also, does > Basically empty form controls act like they have child text. mean that's what the spec wants, that's what chrome does, or that's what FF does?
,
Jul 17
> I don't think this is 100% true It's a known bug; Issue 304848. > mean that's what the spec wants, that's what chrome does, or that's what FF does? There is no specification about form control rendering. It's a de-facto behavior common in major browsers.
,
Jul 23
|
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by viswa.karala@chromium.org
, Jul 2