Normalize.css: Image input with inconsistent display mode in Firefox

[visicode]

Firefox sets image inputs display as inline, and not inline-block like other browsers
Should be:
[type="image"] {
display: inline-block; /* FF */
}

[visicode]

Simply check User Agent stylesheets

[jonathantneal]

That’s interesting. Firefox treats <input type="image"> like <img> where it gains inline-block like behavior once an image is loaded. See http://s.codepen.io/jonneal/debug/9f6e462527d0f57c838af7617102f79a

[visicode]

Should be forced, isn't it?
I had some alignments problems without it…
For example, paddings will make the field overflow the above and below fields

[jonathantneal]

This would be better bundled into opinionated stylesheets until such a time as something like the :loaded pseudo-selector exists.

[kevinvanrijn]

After applying display: inline-block Firefox still has vertical alignment issues.
See https://s.codepen.io/KIPdeKIP/debug/yJYowB

[thierryk]

After applying display: inline-block Firefox still has vertical alignment issues.

vertical-align should help:

[type="image"] {
    vertical-align: bottom;
}

Not perfect tough as the above won't align the box to the baseline.

As a side note, I prefer how Firefox deals with missing images. It makes sense to me that these boxes behave as _inline_ boxes when they are replaced by alt text and are only styled as inline-block when they are _replaced_ with an image. This behavior makes documents easier to read when images are not available.

[kevinvanrijn]

@thierryk I don't agree with that. Elements should be consistent in how they display. A single image failing to load could ruin a website's layout just because the browser decided it was better this way.

Aside from that,
I've managed to cause a similar vertical alignment issue in Chrome as well with <input type="image" src="data:;,">. Here's how that looks in both Chrome and Firefox:

---

Before applying vertical-align: bottom:

| Chrome | Firefox |
| --- | --- |
| | |

https://s.codepen.io/KIPdeKIP/debug/aZdGPO

---

After applying vertical-align: bottom:

| Chrome | Firefox |
| --- | --- |
| | |

https://s.codepen.io/KIPdeKIP/debug/rLxvEN

---

The inputs from left-to-right are: "no image", "valid image" and "empty data uri".

[thierryk]

@KIPdeKIP

A single image failing to load could ruin a website's layout just because the browser decided it was better this way.

As far as I know, Firefox does this only for input[type="image"], not for img, so I don't think it is _that_ bad.

I've managed to cause a similar vertical alignment issue in Chrome as well with

Actually, according to specs:

The src attribute must be present, and must contain a valid non-empty URL potentially surrounded by spaces referencing a non-interactive, optionally animated, image resource that is neither paged nor scripted.

Note that Firefox will submit coordinate (0,0) if the image fails to load—which shows that there is more to it than just visual issues.

[kevinvanrijn]

@thierryk As long as the URL is valid the browser will parse it. data:;, is not a valid image and the browser should display it as such. Chrome displaying it differently is nonsense. Having to break the spec to cause it makes it a nonissue imo though.

The main issue is this. Firefox displaying input[type="image"] wrong when the image fails to load. (Timeout in this case.)

Even though there's more going on then just visual issues it should still be normalized right?

[thierryk]

@KIPdeKIP

I think we all agree about normalizing input via display:inline-block but I don't think we can do much beyond that—like trying to address the vertical alignment issue.

From my understanding, Firefox display the _alternate_ text using ::before but Chrome uses the shadow DOM to display a broken image (via alttext-container).

The result of this is that Firefox treats the control as a inline element while browsers displaying a broken image treat that same control as a inline-replaced element which creates discrepancies between browsers, mostly issues related to dimensions, padding, and vertical alignment.

The vertical alignment issue that your examples show is the result of these elements being aligned to the baseline. The problem is that in Firefox it is the text that is aligned to the baseline, while in other browsers it is the bottom of the (broken) image.

Unfortunately, I don't think we can _normalize_ the vertical alignment for these controls because that could influence the styling of surrounding elements (depending on their nature and their own vertical alignment).

I hope this makes sense.

[kevinvanrijn]

@thierryk

I can agree on that. Applying vertical-align isn't worth the trouble.

If anything gets merged for this it should mention the alignment issue though. Either in the README or with "Known issue:" like v1 did.

[jonathantneal]

Unfortunately, display: inline-block; vertical-align: baseline; is not enough to normalize these elements without breaking from any default browser behavior. If someone would like to make a PR to add a note for this to the known issues section, I will accept it.