From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-3 i686; en-US; m18) Gecko/20001014 BuildID: 0000000000 (CVS 11/9/2000) Many hyperlinks on http://www.w3.org/ are only partially underlined on my CVS build of Mozilla from 11/9/2000. I would think that the page was just bad HTML, if it wasn't at w3.org. :) Reproducible: Didn't try Steps to Reproduce: 1. Visit http://www.w3.org/ 2. Look at the links in the left and right sidebar, and some links in the main body of the page. Actual Results: Only some letters or words of the links are underlined. Expected Results: The entire link being underlined.

Confirmed with linux trunk build 2000-11-11-06. I have seen this for a while but never noticed that this was not an intentional presentation decision and that the underlining was very inconsistent! The problem is as follows: If text in one link is directly below text in another link, the background of the text in the lower link overlaps the underline and blots it out (it also partially blots out descenders if such exist). I have created a reduced testcase which I will attach, together with a screenshot of what this looks like. Over to layout.

Hixie: does ie5mac get this right? and which css is this?

It seems to me the problem is that the default font has a default line-height that's too small. What font server are you using, and what is the default font?

Fontserver: XFree86-xfs-4.0.1-1 X server: XFree86-4.0.1-1 Font packages: XFree86-75dpi-fonts-4.0.1-1 XFree86-100dpi-fonts-4.0.1-1 XFree86-ISO8859-2-75dpi-fonts-4.0.1-1 XFree86-cyrillic-fonts-4.0.1-1 I'll attach my /etc/X11/fs/config.

I have: XFree86-xfs-4.0.1-1 (the RedHat 7.0 xfs) X Server: XFree86-4.0.1 or XFree86-3.3.6 Font packages: XFree86-100dpi-fonts-4.0.1-1 XFree86-cyrillic-fonts-4.0.1-1 XFree86-ISO8859-7-100dpi-fonts-1.0-7 XFree86-KOI8-R-100dpi-fonts-1.0-2 XFree86-ISO8859-2-100dpi-fonts-1.0-12 XFree86-75dpi-fonts-4.0.1-1 XFree86-ISO8859-9-100dpi-fonts-2.1.2-13 The default mozilla font is Adobe-Times, with a height of 16 pixels (according to preferences). Such a font does not actually exist. Comparing to the fonts available, Mozilla is using -adobe-times-medium-r-normal--17-120-100-100-p-84-iso8859-1 Switching to the 18px font (which does exist) does not make this bug disappear.

Interesting that we're both using XFree86 4.x, and xfs 4.x. Is anybody seeing this who's still using XFree86 3.x?

I just tried it with XFree-3.3.6 reading the fonts directly (not going through the font server). Same problem. Next step would be to try the 3.3.6 fonts... :)

I have a 3.3.6 server and fonts and I see similar problems even though my default is sans-serif. You can set NS_FONT_DEBUG=3 in the environment and mozilla will tell which fonts it's loading but I don't think individual fonts are the problem. There are other font misalignment bugs, particularly in chrome, that make me think there is some fundamental issue. I wish I know what it was.

The problem is that Mozilla is using XFontStruct.ascent + .descent for CSS's "line-height: normal" when drawing the text and underlines, while it is using XFontStruct.max_bounds.ascent and .descent when drawing the background. The max bounds are often greater than the recommended line spacing on X, so the background will often overwrite text and underlines above it. I argue that XFontStruct.ascent + .descent is correct for normal line-height since the X protocol spec says that these are used for line spacing. Also, if you try to use the max bounds instead, the text will look strange (the line spacing will be too large). So, the problem is that the background is using the max bounds. I'm not sure where the background height is being computed. It may be here: http://lxr.mozilla.org/seamonkey/source/layout/html/base/src/nsInlineFrame.cpp#501 You will see that it is using GetMaxAscent, which of course returns the max ascent on X. I tried fiddling with that InlineFrame code, with some success. (Somehow, the backgrounds sometimes meet and sometimes don't meet, leaving a single pixel line in a different color between them.) Another problem is that the CSS spec says that the background is the content plus the padding, while the line box and line height calculations are independent. This means that if Mozilla follows CSS to the letter and the style sheet author specifies a large padding, then the background is supposed to be larger than the text, and it is supposed to bleed into adjacent lines.

But if the author specifies large padding without a large line-height, that's the author's fault. The same goes for small line-heights...

I have to say, though... if a font specifies a normal spacing that allows some characters to overlap, isn't it the font designer's fault? I think we're doing the right thing for the backgrounds.

fwiw, i've triaged a bug where the author specified borders or something that amounted to multiple lines around each line, which of course looked awful. But yes that was the author's fault, and any such bugs deserve to land in Evangelism.

>But if the author specifies large padding without a large line-height, that's >the author's fault. The same goes for small line-heights... Well, yes, under the current rules. But if the author specifies a normal padding (i.e. zero) and a normal line-height (i.e. "normal"), wouldn't it be nice if the background ended up being exactly the same as the line box? CSS doesn't specify these things in enough detail. I.e. should the background use the em square or the bounding box? Should the line box use the em square or bounding box? I've asked these questions before, on the www-style mailing list, but I don't think we reached a conclusion. (David, you seem to have pushed for em-square == bounding-box in CSS, but I'm convinced that in reality, font designers have made these two be different, and so CSS should just follow suit, instead of going against the grain.)

>I have to say, though... if a font specifies a normal spacing that allows some >characters to overlap, isn't it the font designer's fault? I think we're doing >the right thing for the backgrounds. The font designer specifies a normal line spacing that makes paragraphs of ordinary text look nice. Under some extreme circumstances, some glyphs may collide, but the designer is more concerned about the average case, not the worst case. I think there are at least 2 different solutions. One solution would be to draw the background in such a way that it never collides with the background in the line above or below (i.e. background == line box (or inline box)). This would require a change to the CSS spec. One problem with that solution is that text will sometimes protrude outside that background. So another solution would be to draw the background as large as the text or as large as the font's bounding box, but draw the text and underlines *after* all of the backgrounds have been drawn, so that text and underlines will never be overwritten by any background. Of course, one of the problems with this solution is that the backgrounds might overwrite each other, so we would need to determine what order to draw them in. My suggestion for the short term would be to make Mozilla implement my first solution above, and to continue talking to others in the CSS community.

The second solution would also require changing the CSS spec. (But we actually used to implement it that way before I fixed bug 36710.)

Actually, it wouldn't require changing it. It would just require a 4th paint layer. (But we could drop it down to 2 if the CSS spec changed to put floats above inlines, or 1 if we did that without the text change.)

I am not clear who should own this bug, but it shouldn't be Clayton. Since David (and Erik) have been discussing potential solutions, I am handing this over to David for now.

Giving to erik, since this is really his thing, although I argue about it a lot :-)

Per the Oslo face to face of the CSS WG, the background of inline elements has the height of the font box + padding + border. The font box has the height of the font INCLUDING ASCENDERS i.e. not the 'em' box. This is the opposite of what I had hoped would be agreed, but the majority of the WG thought it would be best this way...

Are there any minutes from the Oslo face-to-face? Any drafts or errata about the inline box model? Are you sure the background is font box + padding + border? I thought CSS2 said content + padding. I.e. no border included. I can't find it right now... However, it does say that the border is drawn on top of the background, so if the border is transparent, then you can see the background underneath: http://www.w3.org/TR/REC-CSS2/box.html#border-style-properties Also, this discussion is about background, but what about the line box? Does this also use the font's bounding box (as opposed to the em square)? What does "INCLUDING ASCENDERS" mean? Just the ascenders, or also descenders, accents, etc. I.e. are they really talking about the bounding box?

Haven't seen any activity on this bug for over a month, so I thought I'd note that this is still an issue in 2000122610.

Erik -- sorry, I missed your last questions. > Are there any minutes from the Oslo face-to-face? Yes, although they are not very detailed. Mail me if you can't find them. > Any drafts or errata about the inline box model? No W3C sanctioned ones that I know of. > Are you sure the background is font box + padding + border? I thought CSS2 > said content + padding. I.e. no border included. The content area is the font box when talking about the inline box background. The background image covers the content and the padding, the background colour goes under the background image and the border. > Also, this discussion is about background, but what about the line box? Does > this also use the font's bounding box (as opposed to the em square)? The line box is based on the em square, and _not_ the font's bounding box. > What does "INCLUDING ASCENDERS" mean? Just the ascenders, or also descenders, > accents, etc. I.e. are they really talking about the bounding box? This is actually unclear, since different OSes return different data for this. However it is basically the bounding box as opposed to the em square, where the em square height is the actual font-size value, and the bounding box is the box that the glyphs are drawn in within the font, and is actually totally unrelated to the size of the em square. The em square height and the bounding box height are only related to each other by the fact that they are both baseline-aligned to each other, if that makes sense. ;-) I believe this is therefore an INVALID bug that should go to Evangelisation. But I may be wrong, as usual... See also bug 27164, "line-height should be multiplied by em square height". This is, I believe our only remaining inline box model bug (unless you count text-decoration as inline box model, see bug 1777 "'text-decoration' should not be drawn by children"). This bug may be a dup of bug 27873, "inline bgs should use em square height, not bounding box height", which is INVALID but has some issues remaining with the working group that I wish to clear up.

We should probably be *EXTREMELY* sure this isn't a Mozilla bug before we go evangelizing to w3...

Well, I'm sure, anyone disagree? :-)

No disagreement, ->evang.

Hixie: Since you are SOOOOO sure that this is not a mozilla bug and that the w3 is wrong (they could be). Can you please bang your contacts at the w3 to fix this?

Ok.

You rock hixie!

*** Bug 65494 has been marked as a duplicate of this bug. ***

*** Bug 65916 has been marked as a duplicate of this bug. ***

Worksforme on Mac NS 6.0.1 and NT, Can we close this one unless it is in fact Linux specific......

I guess it's linux-specific. Broken with the 2001-03-20 builds on Linux.

Reassigning evangelism bugs to bclary@netscape.com.

I'm still seeing this problem and seeing that w3.org has not fixed it either. Can someone provide a non-font-geek response for how to fix this? I've got some real simple cases where this is failing too. <p> <a class="underline" href="http://link">text</a><br><a class="underline" href="http://link">text</a><br> <a class="underline" href="http://link">multi-line<br>text</a><br> <a class="underline" href="http://link">text</a><br> <a class="underline" href="http://link">text</a><br> </p> Note: for my case, it seems to only happen on multi-line links.

Arun, I'm giving you all the Linux bugs. If these bugs can be confirmed for other OS's please (someone) change the Platform/OS to All/All and reassign to the default Evangelism Component Owner.

Steve: Yes, just increase the line-height, e.g.: p { line-height: 1.3; } ...or some such. Taking bug. I've sent a comment to web-human@w3.org.

I think this would be fixed by the changes in bug 91794, anyway...

Got a response from Susan. She says she won't fix this immediately, because the workarounds I gave (line-height and background:transparent) cause problems in other browsers (IE3 and WebTV respectively). Marking FIXED, we've done our bit.

All Evangelism Bugs are now in the Product Tech Evangelism. See bug 86997 for details.

Fix for bug 91794 checked in 2001-08-23 06:44 PDT.

verified

hyperlink underlining is ok now, but <abbr> underlining is suffering from the same problem there.