css - Block element inside inline-block acting strangely in Firefox -

can explain behavior in ff?

fiddle: http://jsfiddle.net/4mrt8wq3/

<style>     .b { display: inline-block; }     #a { display: block; } </style>  <div class="b">     <label>xxxxxxxxxx</label>      <input type="text" id="a"/> </div> <div class="b">     <label>xxxxxxxxxx</label>     <div> / </div> </div> 

only in firefox, first div positioned 1 line lower second. works correctly in chrome , ie (at least ie11). it's if block element within inline-block wrapping below second element reason.

using overflow: hidden on first div fixes problem, second div positioned oddly 4 or 5 pixels of margin above it. placing overflow-hidden on both causes render correctly.

i not looking solution problem, i've found one, i'm @ loss of explaining behavior... can explain why it's doing this?

yes, interesting question. first need understand default vertical alignment of inline-block elements baseline, , baseline of each such element baseline of last line box in them.

in second div class "b", inner div contains line box hold '/' character. provides baseline second div class "b".

that baseline must align level baseline of first div class "b". question becomes: baseline of last line box in div?

by making input element display:block, firefox¹ takes view input element "replaced", it's contents opaque css, therefore no line box ever created input element. last line of first div class "b" 1 containing label, , aligned level line of '/' character.

chrome takes different view. chrome treats input element having internal structure visible css, innards of element form line box, baseline becomes baseline of first div class "b", , aligned level '/' character.

when add `overflow:hidden', affects baseline of inline-blocks such baselines cease baseline of last contained line box, , becomes bottom margin edge of element.

---

which behaviour correct unclear. depends on history , adulterated notion of replaced elements. in days of browsers, rendering of elements delegated external systems, either underlying operating system or plug-in. in particular, true of input element, rendering done o/s calls. o/s had no notion of css, rules had defined allow black boxes interact rest of page. such elements classified "replaced" elements.

note way defined. there no official list of elements replaced elements, element replaced element if browser chooses delegate rendering system outside css world, in theory have 2 browsers, 1 delegating rendering of element , 1 natively rendering it, , css rules quite different interactions.

as browsers progressed, stopped delegating rendering of input element , rendered themselves, in process making renderings css aware. causes problem because extant web pages, assume input elements rendered using replaced elements' rules, can become unusable. if browser allowed happen, lose market share. part, avoid this, browsers implement elements' layouts interact page if replaced elements, though in reality not.

how far go in respect not specified. html5 spec not recognise form controls replaced elements, , suggests rendered inline-block, make chrome's behaviour correct, there many ways in browsers including chrome don't behave way. backward compatibility perspective old web content, firefox behaviour more reliable.

until layout of form controls specified more tightly case currently, impossible conclusively behaviour correct.

---

¹_{for me, ie11 behaves firefox. opera 28 (blink engine chrome) behaves chrome. opera 12 (presto engine) behaves firefox.}