Last modified: 2013-09-23 11:42:59 UTC
When you expand a category, the symbol changes from '+' to '–'. This is visually unappealing because the characters have different widths. The minus sign, however, has the same width as the plus sign. Line 26 of CategoryTree.js should be changed to: lnk.innerHTML= '−'; to accomodate this.
I'd rather suggest the normal "-" sign (U+002D) since the − (U+2212) doesn't have to be rendered properly in user agents using poor fonts while "-" is ASCII and will be rendered properly everytime.
That would work only if a monospace font were used.
My very unscientific testing (one data point, Firefox 2.0 on Mac :) showed that −, −, and - all have a much shorter width from + in the default display, while – is slightly different but very close -- I have to zoom in a lot to see the difference. So if it's just going to get worse from using −, I don't see a big benefit here.
Any reason why we couldn't use monospace font for [+] and [-] ?
Should work. :)
(In reply to comment #3) > My very unscientific testing (one data point, Firefox 2.0 on Mac :) showed that > −, −, and - all have a much shorter width from + in the default > display, while – is slightly different but very close -- I have to zoom > in a lot to see the difference. Could you be using a font that doesn't contain −? AFAIK it's generally assumed that + and − are to be the same width, and in my experience that's always been true (but Unicode doesn't seem to specify it). Does any single font actually contain radically different-width plus and minus, and if so, what were its creators smoking? Not that this should really be a big factor in changing the status quo, if current browsers aren't rendering it properly, since pretty much everyone renders – as very close to the width of +. I'll change to LATER, it would be nice if this could be fixed eventually (when things aren't rendered so stupidly, one would hope).
[Removing RESOLVED LATER as discussed in http://lists.wikimedia.org/pipermail/wikitech-l/2012-November/064240.html . Reopening and setting priority to "Lowest". For future reference, please use either RESOLVED WONTFIX (for issues that will not be fixed), or simply set lowest priority. Thanks a lot!]
(In reply to comment #7) > [Removing RESOLVED LATER as discussed in > http://lists.wikimedia.org/pipermail/wikitech-l/2012-November/064240.html . > Reopening and setting priority to "Lowest". For future reference, please use > either RESOLVED WONTFIX (for issues that will not be fixed), or simply set > lowest priority. Thanks a lot!] No need to fix this one.
