Closed
Bug 150770
Opened 22 years ago
Closed 22 years ago
Lost <nobr> arround query results
Categories
(Bugzilla :: Query/Bug List, defect)
Tracking
()
RESOLVED
FIXED
Bugzilla 2.16
People
(Reporter: bbaetz, Assigned: bbaetz)
References
Details
(Keywords: regression)
Attachments
(1 file)
4.77 KB,
patch
|
jouni
:
review+
justdave
:
review+
|
Details | Diff | Splinter Review |
The old query code had <nobr> arround the values it didn't quote. We've lost taht, and so bmo is now wrapping the "Bugzilla 2.1x" milestones. We probably need to just add a nobr attribute to the column list in the template, and then apply the no_br filter to those columns. Regression, so -> 2.16
Assignee | ||
Updated•22 years ago
|
Keywords: regression
Target Milestone: --- → Bugzilla 2.16
Comment 2•22 years ago
|
||
<nobr> is non-standard. Add an (or use the no_br filter in the template)
Comment 3•22 years ago
|
||
The filter is called no_break.
Comment 4•22 years ago
|
||
Nobr is nonstandard allright, but you should note that IE wraps on hyphens (and several other characters), so simply using nbsps won't prevent uncool wrapping. You might want to consider td nowrap for the column that contains the info - that's even valid HTML 4.01 Transitional. Outside td's, nobr element is still a good alternative IMO.
Assignee | ||
Comment 5•22 years ago
|
||
There are no hyphens in dates. I guess there could be in a milestone, though. Does IE not wrap hyphens for td nowrap? Else, is there a non-breaking hyphen thingy we can add to the no_break filter?
Comment 6•22 years ago
|
||
Even dates contain hyphens in some formats like "2002-04-01" (which is used in showing dates older than a week). And no, IE doesn't wrap on hyphens if the nowrap attribute is used. Unicode contains several characters which could be used as non-breaking hyphens, but you don't want to use any of them until browser support has improved considerably.
Comment 7•22 years ago
|
||
Well, we could do it properly, using SPANs and CSS.
Comment 8•22 years ago
|
||
As far as I know, CSS has no construct that would properly handle the role of NOWRAP. If you're referring to white-space property, it will allow you to remove nbsp's etc., but it won't help with hyphens which are not white space by definition. In addition to that, using span and white-space is not correct because the white-space property applies to blocks (which spans are not).
Comment 9•22 years ago
|
||
white-space applies to all elements (CSS2 is in error about this), white-space applies to hyphens (the name is misleading about this), and in any case you could just stick it on the cells. td { white-space: nowrap; } ...or whatever.
Comment 10•22 years ago
|
||
Hixie: I stand corrected about the errors in applicability scope of white-space in CSS2 spec, didn't know about that. Thanks. As for the definition of white-space: since CSS2 specifically defined that "Only the characters "space" (Unicode code 32), "tab" (9), "line feed" (10), "carriage return" (13), and "form feed" (12) can occur in whitespace.", how safe it is to think that white-space property applies to hyphens too? Do you have practical experience of browser support here? IIRC, at least IE 5.5 doesn't prevent wrapping on hyphens even when white-space: nowrap is set. I may be wrong, though - currently I don't have an IE newer than 5.0 available, and that doesn't support white-space property at all.
Comment 11•22 years ago
|
||
I have no ideas what browsers support what, I'm just telling you the theory. white-space does apply to more than white space. It sets the word breaking algorithm, which, e.g. in ideographic typography, sometimes does not involve spaces at all. See http://www.w3.org/TR/css3-text/#line-breaking for the current thinking about the scope of the white-space property.
Assignee | ||
Comment 12•22 years ago
|
||
We could use FILTER no_break and css, and get the best of both worlds.
Comment 13•22 years ago
|
||
I think we should just use FILTER no_break here. That IE will wrap on hyphens is something we can worry about another time.
Comment 14•22 years ago
|
||
Is there a particular reason for _not_ using td nowrap here? For our installation, there are hyphens in quite many milestones. Also, most of the developers use IE. It's not an irrelevant point and there's no sense to "worry about it another time" if it can be solved trivially now.
Comment 15•22 years ago
|
||
I suppose not, however the issue is a lot broader as FILTER no_break is used in various other places too, so a bug needs to be filed on that.
Assignee | ||
Comment 16•22 years ago
|
||
Well, one reason for not using <td nowrap> is that somethings arne't by themselgs - if you add nowrap then we'd never wrap on the spaces between the |, in the footer, for example, would we? What about if the no_break filter converted spaces to _AND_ wrapped the entire thing in a <span style="white-space: nowrap;"> ? (We'd use a class in reality, which would mean a global.css style sheet added in the header template) That way things work out for: a) Things without - b) Things with - on browsers which don't break on - (ns4? mozilla? ie-something?) c) Things with - on browsers which do break on - but don't support the white-space property (IE < 5.5 on pc, 5 on mac, according to msdn) I tested that setting white-space: nowrap does stop wrapping on - for IE6 on windows. I don't have access to an earlier version of IE. We could also add nowrap onto the <td> for buglists, which would solve this particular instance of the problem but that wouldn't help with footer queries and the like. Thoughts?
Comment 17•22 years ago
|
||
>We could also add nowrap onto the <td> for buglists, which would solve this
>particular instance of the problem but that wouldn't help with footer queries
>and the like.
Let's add td nowrap where it can be done (buglists in particular). Other than
that, your proposal sounds good to me.
Comment 18•22 years ago
|
||
bbaetz: are you going to produce a patch for this, then? :-) Gerv
Assignee | ||
Comment 19•22 years ago
|
||
I have a patch for this, but I want to talk to hixie about a possibly cleaner way to handle it.
Assignee | ||
Comment 20•22 years ago
|
||
OK, I spoke to Hixie about this. He suggested that since we're using transitional HTML anyway, just use <nobr>. When (and if) bugzilla moves to structural html (4.01 strict/xhtml), then we can use css for this. Patch coming.
Assignee | ||
Comment 21•22 years ago
|
||
Comment 22•22 years ago
|
||
Comment on attachment 89655 [details] [diff] [review] v1 >+ "summary" => { maxlength => 60 , ellipsis => "..." , wrap => 1 } , >+ "summaryfull" => { wrap => 1 } , >+ "status_whiteboard" => { title => "StatusSummary" , wrap => 1 } , ... I'm not quite certain on which fields should have wrap set to one; for example, <nobr>ing "P2" seems like a waste of bandwidth. The same goes for severities and priorities. However, if people have customized their priority and severity settings, then this might be necessary. Each "<nobr>".."</nobr>" is 13 characters. If we have a 100 bug list with three unnecessarily nobr'd fields, that's 3,9 kb. It's not that much, though... Bbaetz, what do you think about this?
Assignee | ||
Comment 23•22 years ago
|
||
I did what 2.14 had, sort of. With 2.14, it was either html_quoted _OR_ <nobr>'d. Email addresses probably don't need to be wrapped, either. We probably waste more bandwidth on whitespace, anyway, and I say this as someone who was behind a 33.6k cnnection to the net until earlier this year. For the record, since I didn't mention it here earlier, Hixie's suggestion was to give each td a class for 'assignee', 'summary', etc, and then use css for assigning the whitespace attribute. (Looking now, 2.14 had a class on each column, current cvs/2.16 doesn't. Should we fix this?)
Comment 24•22 years ago
|
||
Comment on attachment 89655 [details] [diff] [review] v1 >We probably waste more bandwidth on whitespace, anyway Yes, this is true. If we need to, let's optimize later; the current approach is good enough for 2.16. >(Looking now, 2.14 had a class on each column, current cvs/2.16 doesn't. >Should we fix this?) Nah. We need to rethink the classes anyway when proper CSS support is implemented, and I don't believe anyone really depended on those classes. If someone did, he/she can easily redo the customizations in the template anyway. Let's get the party started. r=jouni
Attachment #89655 -
Flags: review+
Comment 25•22 years ago
|
||
Comment on attachment 89655 [details] [diff] [review] v1 r= justdave
Attachment #89655 -
Flags: review+
Assignee | ||
Comment 27•22 years ago
|
||
Checked in, trunk + branch
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Updated•12 years ago
|
QA Contact: matty_is_a_geek → default-qa
You need to log in
before you can comment on or make changes to this bug.
Description
•