New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 753868 link

Starred by 4 users

Issue metadata

Status: Available
Merged: issue 752103
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: 2018-04-23
OS: Windows
Pri: 2
Type: Bug-Regression



Sign in to add a comment

Alt text on broken images overriding css dimensions

Reported by themitch...@gmail.com, Aug 9 2017

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.90 Safari/537.36

Steps to reproduce the problem:
1. Set up an <img> with a src that doesn't work and some alt text
2. Set css: display:block and explicit small width and height pixel values
3. View in browser

What is the expected behavior?
The image should have height and width as set in the css and display the broken image placeholder/icon, with the alt text next to the icon.

What went wrong?
If alt text is set, the broken image icon/placeholder doesn't display and the width and height are determined by the dimensions of the alt text, overriding the css settings.

Did this work before? Yes Last stable desktop release 59.something

Does this work in other browsers? Yes

Chrome version: 60.0.3112.90  Channel: stable
OS Version: 10.0
Flash Version: Shockwave Flash 26.0 r0
 
Chrome-60-img-bug.png
61.7 KB View Download
Cc: robhogan@chromium.org
Labels: BugSource-User PaintTeamTriaged-20170809
Mergedinto: 752103
Status: Duplicate (was: Unconfirmed)
Another argument for reverting to our former behavior.

Comment 2 by robho...@gmail.com, Aug 9 2017

Owner: robho...@gmail.com
Status: Assigned (was: Duplicate)
Treating the element as a replaced inline like this, shedding its dimensions, is what the spec tell us to do. Unless I've misunderstood the test case. 752103 is different - there the question is whether we should display the icon too. This issue is about retaining the dimensions.

Can the reporter provide a test case so we can see if we're not matching the spec?
Labels: Needs-Feedback
NextAction: 2017-08-28
I came here to file the same bug, almost. I'm not actually setting the alt attribute on my images; I'm setting the title attribute. Apparently Blink is using the title attribute as a fallback for alt, and so when the image URL is broken, the title text is shown instead (and is sized differently than the CSS for the image would imply).

I have no idea whether the spec allows or requires using title as a fallback for alt (technically alt is required, so my HTML is not compliant and I shouldn't complain, except that it works in EVERY OTHER BROWSER AND EVERY PREVIOUS VERSION OF CHROME...)

It seems very wrong to me that I can specify CSS height and width for an IMG and then it gets ignored, but I haven't studied the relevant sections of the spec.

Anyway, I have an easy workaround for my case: I can set alt="".

Here's my page that demos this issue, since there was a request for a test case: https://aldel.com/chromeimagebug/index.html (note that this is using title, not alt).
The NextAction date has arrived: 2017-08-28

Comment 6 by robho...@gmail.com, Sep 28 2017

Cc: -robhogan@chromium.org robho...@gmail.com
Owner: ----
Status: Available (was: Assigned)
This still needs feedback from the original reporter. The test case there is different fro the one in #4, which we're rendering correctly per the spec.
NextAction: 2017-10-16
robhogan@, could you link to the spec mentioned in comment #6 so that adelespinasse@ will understand our position?

You're right that we are still missing feedback from themitchweiss@.

Comment 8 by robho...@gmail.com, Oct 8 2017

The rule "If the src attribute is set and the alt attribute is set to a value that isn't empty" at https://html.spec.whatwg.org/multipage/embedded-content.html#the-img-element means that the image in the test case 'represents some text'. This means we apply bullet three at https://html.spec.whatwg.org/multipage/rendering.html#images-3 'The user agent is expected to treat the element as a non-replaced phrasing element whose content is the text, optionally with an icon indicating that an image is missing, so that the user can request the image be displayed or investigate why it is not rendering. In non-graphical contexts, such an icon should be omitted.'

This is why we get rid of the dimensions. To keep them, you need to ditch the alt text so that bullet 2 applies.
The NextAction date has arrived: 2017-10-16
I have a similar/different experience on latest stable. If no alt text and broken image, there is no broken image icon, or visual evidence of an image at all. This behavior seems to differ from other browsers
NextAction: 2018-04-23
Re comment #10, I believe you're seeing our implementation of this rule from https://html.spec.whatwg.org/multipage/rendering.html#images-3

"If the element is an img element that represents nothing and the user agent does not expect this to change
The user agent is expected to treat the element as an empty inline element. (In the absence of further styles, this will cause the element to essentially not be rendered.)"

But I thought we reverted the change that caused us to draw nothing at all for broken images. Do you have a test page that we can look at?
The NextAction date has arrived: 2018-04-23

Sign in to add a comment