Open
Bug 172819
Opened 22 years ago
Updated 2 years ago
Spurious line breaks around inline <img> elements
Categories
(Core :: Layout: Block and Inline, defect)
Tracking
()
NEW
People
(Reporter: bronger, Unassigned)
References
(Depends on 2 open bugs, )
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.
Comment 2•22 years ago
|
||
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.
Reporter | ||
Comment 3•22 years ago
|
||
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.)
Comment 5•21 years ago
|
||
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
Whiteboard: [line-breaking]
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...
Depends on: 225382
I got a similar display problem for the following type of cell in a table : <td class="texte" bgcolor="#f6f6f6" valign="top"> 100 ml <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
Comment 8•17 years ago
|
||
So what do we want our breaking behavior around replaced inlines (images, form controls, etc) to be?
Reporter | ||
Comment 9•17 years ago
|
||
As if they were a single character of text.
Comment 10•17 years ago
|
||
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.
Comment 11•17 years ago
|
||
Should it depend on the alt text? (Is it difficult if some alt texts are blank?)
Comment 12•17 years ago
|
||
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.
Comment 13•17 years ago
|
||
but on ideal mark-upped documents, the alt text means the context of the image... (especially when the images are on lines.)
Comment 14•17 years ago
|
||
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?
Reporter | ||
Comment 16•17 years ago
|
||
An ordinary single letter. For example, '<img src="formula-0001.gif" alt="$x$"/>-Achse' should be broken like 'x-Achse'.
Comment 17•17 years ago
|
||
How about an image of a kanji glyph?
Reporter | ||
Comment 18•17 years ago
|
||
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).
Comment 19•17 years ago
|
||
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.)
Reporter | ||
Comment 20•16 years ago
|
||
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.
Comment 22•16 years ago
|
||
> 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.
Updated•15 years ago
|
Assignee: layout.block-and-inline → nobody
QA Contact: ian → layout.block-and-inline
Comment 24•10 years ago
|
||
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"> 123 </p> Without 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 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"> 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"> 123</span> </span> </p> Of course this is not possible in every situation...
Comment 25•9 years ago
|
||
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.
Comment 26•2 years ago
|
||
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).
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•