876220 - sizing inappropriate for high DPI (skin needs post-bug 537890 fix overhaul)

Status: RESOLVED INCOMPLETE

(bugzilla.mozilla.org :: User Interface, defect)

Description

[Felix Miata]

Attachment: SeaMonkey screenshot on WinXP desktop set to 120 DPI

Screenshot shows e.g.:
1-tabular comment content needlessly wraps
2-tiny comment headers.
3-overall narrow comment content
4-"overflowing" content

Current CSS sizes fonts in pt, which since bug 537890 was fixed makes pt sizes equal to px sizes. Neither pt nor px accommodate moderately high DPI users. Font sizing should be only as required for contextual effect, not dictatorial. Several specific suggestions for changes with comments I've included in diff format for showbug content areas for
https://bugzilla.mozilla.org/skins/contrib/Dusk/global.css and 
https://bugzilla.mozilla.org/skins/custom/show_bug.css

--- global1.css	2013-02-27 06:52:57.000000000 -0500
+++ global.css	2013-05-26 03:08:24.000000000 -0400
@@ -20,17 +20,19 @@
   *                 Frédéric Buclin <[e-mail]>
   */
 
 body {
     background: #c8c8c8;
-    font-family: Verdana, sans-serif;
+/*  font-family: Verdana, sans-serif;	# Verdana is ugly at comfortable font sizes, & is not a FOSS family */
+    font-family: sans-serif;	/* redundant due to below */
     padding-left: 1em;
     padding-right: 1em;
 }
 
 body, td, th, input {
-    font-family: Verdana, sans-serif;
+/*  font-family: Verdana, sans-serif;	# ditto */
+    font-family: sans-serif;	/* presumably user selected a friendly family in settings */
 }
 
 /* page title */
 
 #titles {
@@ -62,11 +64,13 @@
 #bugzilla-body {
     background: #f0f0f0;
     color: black;
     border: 1px solid #747e93;
     padding: 10px;
-    font-size: 10pt;
+/*  font-size: 10pt;	/* post-537890 this translates to 10px = mousetype at high DPI */
+/*  # no need to replace 10pt with something else here, as medium default respects users
+	and this is main page content */
     border-radius: 5px;
 }
 
 a {
     color: #6070cf;
@@ -96,11 +100,12 @@
 
 /* attachments */
 
 #attachment-list {
     border: 2px solid #c8c8ba;
-    font-size: 9pt;
+/*    font-size: 9pt;	# post-537890 this translates to 9px = mousetype at high DPI */
+    font-size: small;	/* one size smaller than UA's medium */
 }
 
 #attachment-list th {
     background-color: #e6e6d8;
     border: none;
@@ -123,11 +128,12 @@
 /************/
 /* Comments */
 /************/
 
 #comments th {
-    font-size: 9pt;
+/*    font-size: 9pt;	# post-537890 this translates to 9px = mousetype at high DPI */
+    font-size: small;	/* one size smaller than UA's medium */
     font-weight: bold;
     padding-top: 5px;
     padding-right: 5px;
     padding-bottom: 10px;
     text-align: right;
@@ -149,11 +155,12 @@
     margin: 1px 1px 10px 1px;
     border-width: 1px;
     border-style: solid;
     border-color: #c8c8ba;
     padding: 5px;
-    font-size: 9pt;
+/*    font-size: 9pt;	# post-537890 this translates to 9px = mousetype at high DPI */
+    font-size: small;	/* one size smaller than UA's medium */
 }
 
 .bz_comment_head, .bz_first_comment_head {
     margin: 0; padding: 0;
     background-color: transparent;
--- show_bug1.css	2013-02-27 06:52:49.000000000 -0500
+++ show_bug.css	2013-05-26 02:57:27.000000000 -0400
@@ -3,11 +3,12 @@
  * The rules you put here override rules in that stylesheet.
  */
 
 .last_comment_link {
     float: right;
-    font-size: 80%;
+/*  font-size: 80%;	# 80% is (nominal) CSS size, which means 64% in physical size */
+    font-size: small;	/* one size smaller than UA's medium */
     font-weight: normal;
     margin-left: 1em;
 }
 
 #legal_disclaimer {
@@ -28,12 +29,14 @@
     margin:0px;
     padding:5px;
     padding-right:20px;
     overflow:auto;
     float:left;
-    max-width:465px;
-    max-height:100px;
+/*  max-width:465px;	# sizing in px this way does not adapt to moderately high DPI, e.g. 144 */
+/*  max-height:100px;	# ditto */
+    max-width:	29.0625rem;	/* 465px divided by 16px */
+    max-height:	6.25rem;	/* 100px divided by 16px */
     border:1px solid #CCC;
 }
 
 .cc_list_display li {
     margin:0px;
@@ -46,11 +49,13 @@
 }
 
 /* put the width on the TD rather than the PRE to stop the col resizing
    when comments are hidden */
 .bz_comment {
-    width: 55em;
+/*  width: 55em;	# causes too narrow width when browser font settings are larger than  
+			as shipped by vendor; 55rem provides big improvement in current Geckos */
+    width: 55rem;	/* subject to tweaking */  
 }
 .bz_comment_text {
     width: auto;
 }

Comment 1

[Felix Miata]

Attachment: 144 DPI screenshot

The difference between SeaMonkey above and Firefox below is this in the Firefox profile's userContent.css:

	.bz_comment {width: 55rem !important}

which overrides this in https://bugzilla.mozilla.org/skins/custom/show_bug.css @ line 50:

	.bz_comment {width: 55em}

Comment 2

[Felix Miata]

Attachment: 120 DPI screenshot on Linux

Screenshot shows effect of the following in userContent.css:

	.bz_comment {
		width: 60rem !important;
		font-size: small !important;
	} 

Note:
1-absence of <PRE> content wrapping
2-legible comment header text size absent in prior attachments
3-12pt (20px) proportional default and 10.8pt (18px) monospace default in Firefox

Comment 3

[Gérard Talbot]

(In reply to Felix Miata from comment #0)
> Screenshot shows e.g.:
> 1-tabular comment content needlessly wraps
> 2-tiny comment headers.
> 3-overall narrow comment content
> 4-"overflowing" content

3 of the above "symptom"-items are really caused by just 1 item actually; you could say tabular comment content needlessly wraps because comment content is too narrow

>  body {
>      background: #c8c8c8;
> -    font-family: Verdana, sans-serif;
> +/*  font-family: Verdana, sans-serif;	# Verdana is ugly at comfortable font
> sizes, & is not a FOSS family */
> +    font-family: sans-serif;	/* redundant due to below */
>      padding-left: 1em;
>      padding-right: 1em;

Most browsers (all Gecko-based browsers, all Web-kit based browsers, Trident-based browsers [IE7 and above]) in use today have {margin: 8px} in their user agent stylesheet. So, in my opinion, there no need to use padding-left and padding-right here. I would just remove those
-    padding-left: 1em;  
-    padding-right: 1em;

Scalable design (using relative units) should make sense when an increase of font-size has to be taken into account, taken into consideration. Here, an 8px margin around the body will do fine regardless of font-size.

>  }
>  
>  body, td, th, input {
> -    font-family: Verdana, sans-serif;
> +/*  font-family: Verdana, sans-serif;	# ditto */
> +    font-family: sans-serif;	/* presumably user selected a friendly family
> in settings */

The stylesheet declarations could be tuned to reduce, to eliminate 1 rule here. Combine and compress.

>  }

[snipped]

> @@ -123,11 +128,12 @@
>  /************/
>  /* Comments */
>  /************/
>  
>  #comments th {
> -    font-size: 9pt;
> +/*    font-size: 9pt;	# post-537890 this translates to 9px = mousetype at
> high DPI */
> +    font-size: small;	/* one size smaller than UA's medium */
>      font-weight: bold;
>      padding-top: 5px;
>      padding-right: 5px;
>      padding-bottom: 10px;

Table header cells padding gets redeclared for the 2nd time:
<table class="bz_comment_table" cellpadding="0" cellspacing="0">
By default, user agent stylesheet have
th, td {padding: 1px}

So, such padding was initially 1px, then it was reset to 0, then reset to 5px and 10px.


>  /* put the width on the TD rather than the PRE to stop the col resizing
>     when comments are hidden */
>  .bz_comment {
> -    width: 55em;
> +/*  width: 55em;	# causes too narrow width when browser font settings are
> larger than  
> +			as shipped by vendor; 55rem provides big improvement in current Geckos */
> +    width: 55rem;	/* subject to tweaking */  
>  }


What I would like to know here is why a percentage of the table width can not be used. I believe that a percentage of the used width of a parent container is more adequate than using rem unit. It is not per se important what is the font-size of the user (expressed in px, pt, em or rem) if the most important symptom to be corrected is "narrow comment content".

The table is wrapped inside a div (weird and unneeded at first glance) and uses an extra empty column (really weird).

<div id="comments">
[several script blocks]
<table class="bz_comment_table" cellpadding="0" cellspacing="0"><tr>
<td>
[lots of div, span, pre styling for all comments]
</td>
<td>
</td>
</tr></table>
is the typical structure of the comments block; notice that the second cell is always empty.

In my opinion, there are too many containers in the above design. And so, I would put the width on a div wrapping all of the comments (<div id="comments">) and its width would be a percentage of the used width of its parent container. I would get rid of the whole table (<table class="bz_comment_table").

Gérard

Comment 4

[Felix Miata]

Attachment: show_bug screenshot @ comment 0 including Domi

(In reply to Gérard Talbot from comment #3)
> <table class="bz_comment_table" cellpadding="0" cellspacing="0"><tr>
> <td>
> [lots of div, span, pre styling for all comments]
> </td>
> <td>
> </td>
> </tr></table>
> is the typical structure of the comments block; notice that the second cell
> is always empty.

Domi shows a non-empty 2nd <TD> cell.

Note though that there's a third stylesheet 
https://bugzilla.mozilla.org/skins/standard/global.css
loaded here, with more (font-family: Verdana...) style replication @ line 32:
    body, td, th, input {
        font-family: Verdana, sans-serif;
        font-size: small;

Comment 5

[Gérard Talbot]

(In reply to Felix Miata from comment #4)

> > <table class="bz_comment_table" cellpadding="0" cellspacing="0"><tr>
> > <td>
> > [lots of div, span, pre styling for all comments]
> > </td>
> > <td>
> > </td>
> > </tr></table>
> > is the typical structure of the comments block; notice that the second cell
> > is always empty.
> 
> Domi shows a non-empty 2nd <TD> cell.

You're right. 
Such 2nd <TD> cell is not empty .. unless you are not logged in: that's probably what happened when I examined the source.

This is a very questionable usage of a table element here: a whole cell of table which is almost the height of the whole webpage is used to render only 3 links ("Collapse All Comments", "Expand All Comments", "Show CC Changes") but nevertheless uses from 5% to 15% (depending on the users' viewport) of the width of the table. 
In any case, table elements should be used to render tabular data and this is not tabular data.

Quick idea: I would put those 3 links in 2 simple <p> (1 before and 1 after comments block) and then ditch, remove the whole table and would try to combine and compress as much as possible some of the block containers here.

Eg.

<p class="bz_collapse_expand_comments"> [Collapse and expand comments links] [to be styled accordingly] </p>

<div class="bz_comment_table">
... comments  ...
</div>

<p class="bz_collapse_expand_comments"> [Collapse and expand comments links] [to be styled accordingly] </p>


> Note though that there's a third stylesheet 
> https://bugzilla.mozilla.org/skins/standard/global.css
> loaded here, with more (font-family: Verdana...) style replication @ line 32:
>     body, td, th, input {
>         font-family: Verdana, sans-serif;
>         font-size: small;

Yep.. undeniably there is a lot of redeclarations here.

Comment 6

[:glob ✱]

all the screenshots show the dusk skin, not mozilla. fixing component.

it would be best to keep this bug on the topic regarding the high dpi issues.

most of the suggested changes in comment 0 look sane, and we should do similar things 

> Verdana is ugly at comfortable font sizes

i agree, which is why the alternative font skins exist :)  we probably won't be changing that here, as we'll be defaulting to the mozilla skin at some stage.

-    width: 55em;
+/*  width: 55em; # causes too narrow width when browser font settings are larger than  
+		    as shipped by vendor; 55rem provides big improvement in current Geckos */
+    width: 55rem; /* subject to tweaking */  

we'll need to do some experimentation as we don't want to break our IE clients - ideally bmo should look fine with IE8, which doesn't support rem.  that said, i wouldn't put that as a show-stopper; however we shouldn't switch without first seeing the impact on older browsers.


note - bugzilla has 3 layers of css: base (upstream), custom (site-specific cusomtisations), and skin (skin-specific customisations).  unfortunately this results in the redeclarations you've mentioned.


i'll wrap this into a patch for review, and test on IE compatibility.

Comment 7

[Felix Miata]

For completeness, as comment 0 did not consider the third stylesheet, which contains the foundational bug 225639 blocker:
--- standard-global1.css	2013-05-16 02:46:22.000000000 -0400
+++ standard-global.css	2013-05-27 07:47:34.000000000 -0400
@@ -27,14 +27,16 @@
     body {
         font-family: sans-serif;
         color: #000;
         background: #fff url("global/body-back.gif") repeat-x;
     }
     body, td, th, input {
-        font-family: Verdana, sans-serif;
-        font-size: small;
+/*  font-family: Verdana, sans-serif;	# Verdana is ugly at comfortable font sizes, & is not a FOSS family */
+    font-family: sans-serif;	/* respect user's selection */
+/*        font-size: small;	# major reason why blocking bug 225639 (user disrepect) */
+        font-size: medium;	/* presumably user has made optimal selection for his environment (respectful) */
     }
     /* monospace is much smaller than Verdana by default, so we make it a bit bigger. */
     pre, code, kbd {
         font-size: medium;
     }
 /* global (end) */
@@ -244,13 +246,14 @@
 }
 
 div#docslinks {
     float: right;
     border: 1px solid black;
     padding: 1ex;
-    font-size: 80%;
+/*  font-size: 80%;	# 80% is (nominal) CSS size, which means 64% in physical size */
+    font-size: small;	/* one size smaller than UA's medium */
 }
 
 #docslinks h2 {
     margin: 0;
 }

Comment 8

[Felix Miata]

Attachment: WinXP screenshot @ 144 DPI show_bug page in freshly installed IE8

This is from same system as comment 0 screenshot after adjusting desktop DPI to 144.

Comment 9

[Felix Miata]

Attachment: WinXP screenshot @ 144 DPI show_bug page in IE8 with user CSS applied

Exactly the same as comment 8 screenshot except after applying the following user styles to IE:

body {font-family: sans-serif !important}

body, td, th, input {font-family: sans-serif !important}

#bugzilla-body {font-size: medium !important}

#attachment-list {font-size: small !important}

#comments th {font-size: small !important}

.bz_comment {font-size: medium !important}

.last_comment_link {font-size: /*80%*/small !important}

.cc_list_display {max-width: /*465px*/29.0625rem !important;
    max-height: /*100px*/ 6.25rem !important}

.bz_comment {width: 60rem !important}

body {font-family: sans-serif !important}

body, td, th, input {font-family: sans-serif !important;
font-size: /*small*/medium !important}

div#docslinks {font-size: /*80%*/small !important}

Comment 10

[Felix Miata]

Attachment: WinXP screenshot @ 144 DPI show_bug page in Gecko with user CSS applied

Same WinXP desktop as comments 0, 8 & 9 with comment 9 styles exclusively included in SeaMonkey's userContent.css.

Comment 11

[Kohei Yoshino]

Closing since we are not using the Dusk theme anymore and the legacy non-modal bug page is retiring.