Open Bug 172819 Opened 23 years ago Updated 3 years ago

Spurious line breaks around inline <img> elements

Categories

(Core :: Layout: Block and Inline, defect)

Product:
Core
Component:
Layout: Block and Inline
Platform:
x86
Linux
Type:
defect

Tracking

()

People

(Reporter: bronger, Unassigned)

References

(Depends on 2 open bugs,
URL
)

Details

(Whiteboard: [line-breaking])

An inline <img> element immediately followed by text without white space inbetween, may be separated from that text by a line break. In the example URL you may have to adjust the window width to see this effect. Inline images are used there to represent formulae, but in expressions like "(001)-Fläche", a line break before the hyphen is orthographically wrong and therefore not acceptable.
shanjian, don't you already have bugs on this?
Whiteboard: DUPEME
I am pretty sure there are similar problem filed, but that bug is not one in my assgined list. I could not find the bug.
I experience the same problem with <mml:math> elements. Would this be a duplicate or is this a separate bug? (The newsgroup didn't help, sorry.)
related: bug 98379
Over to inline layout and confirming.
Assignee: attinasi → block-and-inline
Status: UNCONFIRMED → NEW
Component: Layout → Layout: Block & Inline
Depends on: 98379
Ever confirmed: true
QA Contact: cpetersen0953 → ian
Whiteboard: DUPEME
Is this related to the HACK_MEW code attinasi wrote? We should really figure out what the line breaking algorithm most compatible with the web is, and stick to it. Although maybe IE/Windows is really doing multiple things...
I got a similar display problem for the following type of cell in a table : <td class="texte" bgcolor="#f6f6f6" valign="top"> 100&nbsp;ml&nbsp;<span class="texte-ref">PF01026</span> 15€<a href="panier_ajouter.php?s=106"><img src="../img/commun/fleche_ajout.gif" alt="" align="middle" border="0" height="11" hspace="4" vspace="2" width="11"></a></td> There is a space to allow the browser to wrap the line if there is to many cols in the table. But Mozilla wrap between the text(15€) and the img and not at the space before "15€". Mozilla 1.7RC1 : Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040421
Blocks: 264110
Blocks: 139723
So what do we want our breaking behavior around replaced inlines (images, form controls, etc) to be?
As if they were a single character of text.
Is that what other UAs (in particular IE) do in all cases? In any case, the question was more directed at roc and Masayuki Nakano, who're actively working on line-breaking right now.
Should it depend on the alt text? (Is it difficult if some alt texts are blank?)
If the image is showing as an nsImageFrame, I don't think the alt text should matter. If it gets replaced by its alt text, there is no issue, since then it's just text.
but on ideal mark-upped documents, the alt text means the context of the image... (especially when the images are on lines.)
Hmm... I see what you mean. Yeah, ok. If we want to be really cool we could do that. ;)
(In reply to comment #9) > As if they were a single character of text. OK but *which* character?
An ordinary single letter. For example, '<img src="formula-0001.gif" alt="$x$"/>-Achse' should be broken like 'x-Achse'.
How about an image of a kanji glyph?
You may use complex heuristics -- possibly by looking also at the alt attribute -- to try to find out the best-fitting behaviour in a certain context. However, from the typographical point of view, the appearance of an image in inline text leads to undefined behaviour anyway. Moreover, using <img> for inserting unicode characters is a poor man's fallback. So I vote for the KISS approach that is easily predictable for authors: It clings to surrounding characters like a "c" would do, and if you don't want that, add whitespace (possibly a zero-space one).
Kanji and most Japanese characters should be breakable on both sides. Therefore, there is no problem on current behavior. (I think it is same with Chinese, but I don't know with Korean.)
Then, there is no problem for Kanji text, which doesn't mean that there is no problem at all. For Latin scripts, the current behaviour is unfortunate, and even worse, there is no workaround. If, however, the default was that an <img> tag is broken like a Latin letter, it would work for Latin scripts (and for formulae which is a very significant use case), *and* there would be a workaround for Kanji.
In Gecko 1.9 you can use "white-space:nowrap" on inline elements to prevent breaking.
> In Gecko 1.9 you can use "white-space:nowrap" on inline elements > to prevent breaking. I just want to mention, that this is *not* (always) a solution. In times of dynamic content generation there is not always the option to add "nowrap" in a useful way (without disabling real whitespace for wrapping). This is a behavior breaking what we knew from HTML, XML processing and it should be treated as such, a bug.
Assignee: layout.block-and-inline → nobody
QA Contact: ian → layout.block-and-inline
I noticed this bug through this stackoverflow question: http://stackoverflow.com/questions/26590996/how-to-prevent-linebreaks-after-an-inline-image/26591064 ### Summary of the above question ### Take the following code: <p style="width: 12ex; font-family:monospace;"> 12345678 <img style="width: 2ex" src="https://upload.wikimedia.org/wikipedia/commons/thumb/8/85/Smiley.svg/25px-Smiley.svg.png">&nbsp;123 </p> Without &nbsp; the simley would be on the first line and the second word "123" would be on the second line (paragraph is 12 characters long = 12ex, first word + space + smiley = 8ex + 1ex + 2ex = 11ex). Because the image tag is followed by &nbsp; the smiley should be on the second line which is not the case in Firefox 33. The first answer on the question suggested to add "display: inline-block;" to the image tag: <p style="width: 12ex; font-family:monospace;"> 12345678 <img style="width: 2ex; display: inline-block;" src="https://upload.wikimedia.org/wikipedia/commons/thumb/8/85/Smiley.svg/25px-Smiley.svg.png">&nbsp;123 </p> This works for Chromium 36 and 38 but not for Firefox 33... Unfortunately I do not know, what should be the line-breaking behavios of images with "display:inline-block;"... ### A workaround in Firefox ### One can use "whitespace: nowrap": <p style="width: 12ex; font-family:monospace;"> 12345678 <span style="white-space: nowrap"><img style="width: 2ex" src="https://upload.wikimedia.org/wikipedia/commons/thumb/8/85/Smiley.svg/25px-Smiley.svg.png">&nbsp;123</span> </span> </p> Of course this is not possible in every situation...
It seems to me that an inline image should behave like an 'ordinary' character, without workarounds. I want to write 'buttons x, y, and z', where 'x', 'y', and 'z' are images of the buttons. So obviously I don't want a break before a comma (i.e. the comma at the start of the next line). IE does work like this. The problem with characters which allow breaks on both sides could be solved by letting the adjacent character determine the breaking behaviour, e.g. 'xK', where 'x' is an image and 'K' is Kanji text would allow a break, but 'xR' where 'R' is Roman text (or punctuation) would not.

I had a similar issue, though punctuation was involved: bug 1684705, which was regarded as invalid due to https://drafts.csswg.org/css-text/#line-break-details saying "there is a soft wrap opportunity before and after each replaced element or other atomic inline". So it seems that this bug should be regarded as invalid too (whether this is punctuation or text, this doesn't matter).

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.