Steps to reproduce: 1. Go to url (http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?db=PubMed) 2. Enter search term, e.g. "Watson JD"[AU] AND "Crick FH"[AU] 3. Hit Enter, or press the GO Button 4. In the resulting list, the numbers are rendered below the checkboxes. In Firefox, the numbers are rendered next to the checkboxes. The Firefox rendering is preferable, as it is more compact (all 13 results fit easily on my screen in Firefox, but go off the bottom of my page in Safari). Tested in using the nightly build of Safari (r23922) on 10.4.10. This is not a regression, as shipping Safari shows the same behavior, as does the earliest available build of Webkit.
Added NeedsReduction keyword
Created attachment 15387 [details] Reduction
Comment in RenderTableCell::setStyle(): // [...] If the width of the cell is fixed, then // we don't actually use NOWRAP. Firefox respects nowrap in strict mode even in fixed width cells.
(In reply to comment #3) > Firefox respects nowrap in strict mode even in fixed width cells. But WinIE doesn't (at least in the reduction).
The actual bug appears to be fixed, at least in Safari 3.04 on Leopard (follow instructions in initial bug report and compare Safari and Firefox). However, the reduction itself renders differently between Safari and Firefox, making me think that the reduction wasn't a valid reduction of the problem that was exhibited. Am closing as WORKSFORME, but it would be good if there were a test associated with this bug to prevent future regressions.
I think this bug should be reopened to track the issue in the reduction (which still renders differently on Firefox 2.0.0.11 versus ToT WebKit). I think the web site has probably changed from using tables to using div's and stylesheets. (Mitz wouldn't have reduced a page without tables to a reduction using a table.) The question is whether to follow MSIE's behavior or Firefox's behavior.
(In reply to comment #6) > The question is whether to follow MSIE's behavior or Firefox's behavior. Maybe an option could be added to ask chrome to follow MSIE behaviour or Firefox behaviour on this case :) I have the same problem: nowrap for TD of fixed width is ignored. I use a second table as table header in a web based database management application, so that the column headers are still displayed when scrolling the table below. For this i must set a fixed width for cells in both tables. Yeah i do use <table> for this, no offense to css dogmatists although: i do use css for the general layout :) To keep the table as compact as possible, i use the table cells width to resize column header cells with javascript, then i use the column header cells width to resize table cells when width mismatch (ie: when the header cell content width is wider than the cell content width ) The problem with chrome is that the sorting icon (img) beside the column header label appears on the line below when the header cell content is wider than the table cell content. It works nicely with Firefox. I will never make it MSIE compatible because beside the fact i hate MS anti-interoperability policy, i dont run Windows; but i love Chrome javascript native engine. Please do something :)
(In reply to comment #6) > The question is whether to follow MSIE's behavior or Firefox's behavior. In the presence of nowrap and a width, Firefox 12a in strict mode will not wrap. Firefox in quirks mode will wrap. IE in quirks mode and versions up to IE7 will also wrap. IE8 and IE9 in standards mode will not wrap. WebKit will always wrap. It seems like to be consistent with other browsers, WebKit should not wrap in standards mode and wrap in quirks mode. If someone wanted to fix this, the code is in CSSStyleSelector::adjustRenderStyle (the check against KHTML_NOWRAP). That said, I'm not sure how much of an issue this is today. It would have to be a page rendering in standards mode using the nowrap attribute on a table cell. The workaround is to use CSS white-space: nowrap instead.
This continues to be an issue in Safari 15.
<rdar://problem/96618379>
(In reply to Radar WebKit Bug Importer from comment #10) > <rdar://problem/96618379> This got fixed in Safari Technical Preview 155 because I removed -webkit-nowrap and also KHTML. So we don't have this quirk anymore. Marking this as "RESOLVED CONFIGURATION CHANGED".