14523 2007-07-04 11:48:15 -0700 nowrap attribute in table cell is ignored in strict mode 2022-10-05 14:12:57 -0700 1 1 1 Unclassified WebKit Tables 523.x (Safari 3) Mac OS X 10.4 RESOLVED FIXED http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?db=PubMed HasReduction, InRadar P2 Normal --- 1 gsherloc webkit-unassigned ahmad.saleem792 bfulgham hyatt luxigo mitz tony webkit-bug-importer oldest_to_newest 5599 0 gsherloc 2007-07-04 11:48:15 -0700 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. 5598 1 gsherloc 2007-07-04 11:51:36 -0700 Added NeedsReduction keyword 5595 2 15387 mitz 2007-07-04 12:08:20 -0700 Created attachment 15387 Reduction 5593 3 mitz 2007-07-04 12:18:09 -0700 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. 5069 4 mitz 2007-07-10 09:40:48 -0700 (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). 65550 5 gsherloc 2007-12-28 21:32:19 -0800 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. 65688 6 ddkilzer 2007-12-29 22:38:51 -0800 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. 216879 7 luxigo 2010-04-25 20:28:43 -0700 (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 :) 551552 8 tony 2012-02-07 16:46:38 -0800 (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. 1881448 9 bfulgham 2022-07-07 12:44:50 -0700 This continues to be an issue in Safari 15. 1881449 10 webkit-bug-importer 2022-07-07 12:45:01 -0700 <rdar://problem/96618379> 1903524 11 ahmad.saleem792 2022-10-05 14:12:57 -0700 (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". 15387 2007-07-04 12:08:20 -0700 2007-07-04 12:08:20 -0700 Reduction 14523 reduction.html text/html 164 mitz PCFET0NUWVBFIEhUTUw+CjxodG1sPgo8aGVhZD4KPC9oZWFkPgo8Ym9keT4KICAgIDx0YWJsZT4K ICAgICAgICA8dHI+CiAgICAgICAgICAgIDx0ZCBub3dyYXAgd2lkdGg9IjEwIj5Mb3JlbSBpcHN1 bTwvdGQ+CiAgICAgICAgPC90cj4KICAgIDwvdGFibGU+CjwvYm9keT4KPC9odG1sPgo=