563419 - aboutSupport.css rules .pref-name and .pref-value do not have desired effect of splitting table 70-30

Status: NEW

(Firefox :: Theme, defect)

Description

[Jens Hatlak (:InvisibleSmiley)]

aboutSupport.css contains rules for .pref-name and .pref-value. They should be changed to .prefs-table th.name and .pref-name th.value, respectively.

I'd appreciate it if someone who regularly builds Firefox can take over. Otherwise I'll take care of it eventually because this affects SeaMonkey's Default Theme as well.

Comment 1

[Jens Hatlak (:InvisibleSmiley)]

Hmm, I see that .pref-name and .pref-value do exist in the generated source code (class names of the tds inside the tbody) so I need to adjust the summary. However the rules that exist do not have the desired effect of splitting the table in a 70%/30% ratio. I'll see what we'll come up with in bug 561668 (for SeaMonkey's Modern theme which needs separate rules).

Comment 2

[Jens Hatlak (:InvisibleSmiley)]

Outcome and suggested fix: Change the existing rules to

.name {
  width: 70%;
}

.value {
  width: 30%;
}

.pref-name,
.pref-value {
  white-space: nowrap;
  overflow: hidden;
}

Comment 3

[Jens Hatlak (:InvisibleSmiley)]

Attachment: rules change

Comment 4

[:Gavin Sharp [email: [e-mail]]]

This works as advertised, but is it really what we want? I don't know why we'd want the pref name column to be 70% - if anything, wouldn't we want the value column to be wider, since it's most likely to be extra-long?

Comment 5

[Jens Hatlak (:InvisibleSmiley)]

(In reply to comment #4)
> This works as advertised, but is it really what we want? I don't know why we'd
> want the pref name column to be 70% - if anything, wouldn't we want the value
> column to be wider, since it's most likely to be extra-long?

From experience I'd say most preference values are actually short, e.g. booleans, integers and short strings. Of course there can be long strings as well but I'd say the probability is higher that the pref name is (relatively) long and since this is about:support the user is likely primarily interested in which prefs are set and not so much (in comparison) in their values. That was my reasoning (beyond the fact that the rules don't work as one might assume).

Maybe you'd like to ask some more people for input. Maybe in the end the outcome is that e.g. 50/50 is better from your POV. In any case I think the rules will need to be fixed according to that outcome.

Comment 6

[Curtis Bartley [:cbartley]]

(In reply to comment #5)
> (In reply to comment #4)
> > This works as advertised, but is it really what we want? I don't know why we'd
> > want the pref name column to be 70% - if anything, wouldn't we want the value
> > column to be wider, since it's most likely to be extra-long?
> 
> From experience I'd say most preference values are actually short, e.g.
> booleans, integers and short strings. Of course there can be long strings as
> well but I'd say the probability is higher that the pref name is (relatively)
> long and since this is about:support the user is likely primarily interested in
> which prefs are set and not so much (in comparison) in their values. That was
> my reasoning (beyond the fact that the rules don't work as one might assume).
> 
> Maybe you'd like to ask some more people for input. Maybe in the end the
> outcome is that e.g. 50/50 is better from your POV. In any case I think the
> rules will need to be fixed according to that outcome.

I think that Jens is right that the user will generally be more interested in the pref name than the pref value, and that most pref values will be short anyway, for whatever that's worth.

In terms of the optimal solution, I think what you really want to say is something like "use up to 70% of the table width to show the pref names, but no more than what the longest pref name requires".  I don't think there's any way to do that with just CSS and tables.  You probably could do a reasonable approximation with JavaScript where you compute the maximum pref name length, and set table cell widths based on that.  That might be more trouble than it's worth though.

Also note that I used overflow hidden.  If you can live with line-wrapping in some cases, maybe you can just set the size of the first column to zero (or very small), and let the table size to the contents of the first column.  Again that may or may not be worth the trouble.

Finally note that it might be desirable to use "text-overflow: ellipsis" when that's implemented.

Comment 7

[Dão Gottwald [:dao]]

I don't see why we'd want to specify widths at all, rather than letting layout size the columns automatically.

Also, displaying everything, even with line wrapping, seems desirable over cutting things off.

Finally, this code doesn't belong in themes.

Comment 8

[Curtis Bartley [:cbartley]]

(In reply to comment #7)
> I don't see why we'd want to specify widths at all, rather than letting layout
> size the columns automatically.

This may be true for pref names.  However, some pref values are very long and don't have any spaces.  As I recall, this played havoc with normal table layout.  But maybe it's worth experimenting with.

> Also, displaying everything, even with line wrapping, seems desirable over
> cutting things off.

This may be true of pref names.  Long pref values are usually not that interesting, and they're the most problematical for line wrapping and table layout.  Note that the full pref values are still available if you copy and paste.

Comment 9

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 443395 [details] [diff] [review]
rules change

Seems like we should just get rid of the non-functioning code and leaves things as they are.

Comment 10

[Dão Gottwald [:dao]]

(In reply to comment #8)
> (In reply to comment #7)
> > I don't see why we'd want to specify widths at all, rather than letting layout
> > size the columns automatically.
> 
> This may be true for pref names.  However, some pref values are very long and
> don't have any spaces.  As I recall, this played havoc with normal table
> layout.  But maybe it's worth experimenting with.

A slash, hyphen or comma should enable wrapping just like a space. If this doesn't work as expected or if we are concerned about pref values that don't contain any of these characters, I'd suggest applying a max-width to that column.

Comment 11

[Jens Hatlak (:InvisibleSmiley)]

Feel free to take.