** Observed with 5/13/99 Win32 and Mac apprunner ** This problem was obaserved on a Yahoo Japan new headlines page today. I copied the page to the above URL. It seems that we truncate a line when the items listed with <li> with <nobr> gets too long. These items are actually in a table cell. In 4.6, this page is displayed correctly like this: http://kaze:8000/bugs/4.6yahoo.gif Note there is no truncation on the 2nd bulleted item on the right column. Now contrast this with the view on 5.0 Browser: http://kaze:8000/bugs/5.0yahoo.gif Note that this time, the 2nd bulleted line is truncated. This can be avoided if we eliminate <nobr> ... </nobr> around the 2nd item. This page is in Japanese. You can display it with a Bitstream font or any other Japanese font as long as it's installed on your system. If you need a Windows Bitstream font, you can find it here: ftp://ftp.netscape.com/pub/communicator/extras/fonts/windows/Cyberbit.ZIP

A low priority issue for you when you get back. :)

Actually, the error is simply that <wbr> and <nobr> elements have different priorities in Gecko than in 4.x browsers. <nobr> This "should" never break, except at <br> elements (always) and at <wbr> elements (if required.) </nobr> Currently, <nobr> is overriding <wbr>, so the above would only ever break on the <br>. Here is a simplified test case for this: http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/wbr.html There is another bug on this page, namely the actual truncation. It is not actully related to <nobr>; it is a tables issue. I will file another bug.

The other bug is bug 6674.

Marking yikes since its hard to fix.

Overview Description: <wbr> weaker than <nobr> Steps to reproduct: 1) load the attachment 2 [details] [diff] [review]) have a look at line 2 Actual results: no line break, even if you resize the window so that the text doesn't fit the line. Expected resuls: line break Build Date & Platform: M7 & 1999071417 build

Updating to default Layout Assignee...kipp no longer with us :-(

Why are you re-reassing layout bugs? Do NOT touch layout bugs. The bugs are assigned to Kipp so they can stay neatly organized until we have a new owner for the block/inline code.

mass moving all Kipp's pre-beta bugs to M15. Nisheeth and I will prioritize these and selectively move high-priority bugs into M13 and M14.

Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!

I'm currently working on some related stuff, so I guess it's worth a look... Thank's to Momoi-san for pointing this bug...

jbetak: did you mean to assign this bug to yourself?

mine! mine mine mine! all mine! whoo-hoo!

moving all buster m15 bugs to m16.

will be very tough to get this fixed for FCS, unless someone else can do it.

jbetak: You commented above that you might look at this -- do you still intend to do so?

redistributing bugs across future milestones, sorry for the spam

This bug has been marked "future" because we have determined that it is not critical for netscape6.0. If you feel this is an error, or if it blocks your work in some way -- please attach your concern to the bug for reconsideration.

This isn't life-threatening or anything, but please consider making this a higher priority. It makes several of my web pages look really bad.

At this stage, we are pretty much only fixing life threatening bugs. So...... Don't forget that <wbr> is completely non-standard. Author valid HTML, and your pages are likely to come out a lot better in Mozilla.

I understand that. However, if you're going to take that line, nobr should be removed entirely. I'd prefer that it be fixed though, since a lot of pages (not just mine) do use it and now look silly. It's supported by both Netscape Navigator and MS Internet Explorer. (And since the standards process is essentially descriptive, it may eventually make it in.)

More pages would look silly if we didn't support <nobr> than look silly now with only <wbr> being not supported. Anyway, if you are worried about what your pages _look_ like then you have missed the point of HTML, which is that you should markup the *structure* of your documents and then rely on the web browser to render it correctly -- be it on a screen, by voice, or on a braille reader.

That's a religious issue and doesn't really belong here. The fact is, HTML in the real world today is mix of content-based and presentation-based markup. And, as appearance-based markup goes, wbr is a great tag. It exists so that pages can look good in a wide variety of browser/page widths.

Um, ok, so: <NOBR></NOBR> works exactly like <WBR>, as far as I can tell. Duh. I'll shut up about this now.

Do you mean </NOBR><NOBR> ?

Yes, sorry.

Excellent! In that case we have a workaround! RELNOTE ITEM: Mozilla does not support the <wbr> tag inside the <nobr> element. To work around this issue, replace all instances of <wbr> with </nobr><nobr>. Note, though, that both these elements are non-standard.

The same thing can be done with SPAN and white-space: nowrap. Unfortunately, while this works great in Mozilla, it doesn't work in Navigator 4.75...

(RELEASE NOTE ITEM: above -- need to explicitly say that to get it on my radar.) Marking WONTFIX. This is a compatability issue, but since we are not fixing it for this release, web authors will have to write their markup to work around the way we render it regardless of whether we 'fix' it in the future or not. Thus, fixing it in the future is a waste of our time. Note that the markup is invalid anyway; so the workaround is simply to fix the page in question.

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

I couldn't get </nobr><nobr> to work but </nobr><wbr><nobr> did...

See bug 256643

Damn, what is the workaround, when you need XSL transformation? Lookup if is child of <nobr> and then output as xsl:text the damn hack? How you want render complex chemical equation - you cannot break it anywhere you want, author gives you hint where to break it if necessary. And if we say, presentation should be controlled by CSS, ok - nobr ~ white-space:nowrap, but how you achieve wbr effect? Btw, do you know anyone from W3C? I can imagine such guy as little green man with big eyes and cute antennas on his head.

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

(In reply to comment #33) > Damn, what is the workaround, when you need XSL transformation? Lookup if is > child of <nobr> and then output as xsl:text the damn hack? > And if we say, presentation should be controlled by CSS, ok - nobr ~ > white-space:nowrap, but how you achieve wbr effect? The construct "&lt;span style="font-size: 0px"&gt; &lt;/span&gt;" can be used as a replacement for wbr. In Mozilla browsers it works fine and in MS-IE it renders as a nearly visible 1-pixel (?) space.

(In reply to comment #35) This is the correct construct: "<span style="font-size: 0px"> </span>"