Standardize size of WebUI controls for touch and non-touch.

chrome/browser/resources/shared/css/widgets.css

 /* Copyright (c) 2012 The Chromium Authors. All rights reserved.
  * Use of this source code is governed by a BSD-style license that can be
  * found in the LICENSE file.
  */
 
 /* This file defines styles for form controls. The order of rule blocks is
  * important as there are some rules with equal specificity that rely on order
  * as a tiebreaker. These are marked with OVERRIDE.
  */
 
@@ skipping 47 matching lines @@
   -webkit-appearance: none;
   -webkit-padding-end: 20px;
   -webkit-padding-start: 6px;
   /* OVERRIDE */
   background-image: url('../images/select.png'),
       -webkit-linear-gradient(#ededed, #ededed 38%, #dedede);
   background-position: right center;
   background-repeat: no-repeat;
 }
 
+:-webkit-any(button,
+             input[type='button'],
+             input[type='submit'],
+             select):not(.custom-appearance):not(.link-button) {
+  margin-bottom: 6px;
+  margin-top: 6px;

[Evan Stade, 2012/08/10 02:44:16]

how much verification did you do that this doesn't make anything look crazy?

[kevers, 2012/08/10 13:56:03]

This rule has been in effect for a while now with the touch optimized UI. 
Without it, a vertical stack of buttons are nearly touching, which creates some
tap errors.  The alternative is to use larger buttons; however, UX feedback
suggests keeping the button sizes smaller if possible.

One place where this pattern is used is on the keyboard shortcuts dialog. 
Attached a screenshot in the email.  Can do some experimentation to determine
how small the margin can be before tap error rates climb.

[Evan Stade, 2012/08/10 21:21:08]

sorry, I wasn't clear enough. I didn't mean that the margin would be too big and
look weird. I was thinking about all the many pages that use buttons and these
other elements, and wondering if one of the many pages would be broken by this
change.

The fact that it has been on for a while with the touch optimized build doesn't
give me much confidence, although it's better than nothing. But I'm still wary
without a manual pass over all webui pages because 1) we have a ton of pages and
2) poor spacing or padding or alignment in the past has often persisted for
several releases in a row, showing that most people don't care to file a bug
report when they notice issues, or simply don't consciously notice the issues.

so basically I was looking for an answer like "I manually inspected every page
in chrome://chrome, every dialog I could find in settings, downloads, feedback,
etc."

[kevers, 2012/08/13 17:18:46]

Removed rule in favor of standardizing the formatting of settings pages instead.
 Added "settings-row" as appropriate to fix the vertical spacing.

+}
+
 html[dir='rtl'] select {
   background-position: center left;
 }
 
 input[type='checkbox'] {
   bottom: 2px;
   height: 13px;
   position: relative;
   vertical-align: middle;
   width: 13px;
@@ skipping 206 matching lines @@
  * these classes with the markup structure:
  *
  *   <div class="checkbox">
  *     <label>
  *       <input type="checkbox"></input>
  *       <span>
  *     </label>
  *   </div>
  */
 
-.checkbox,
-.radio {
-  margin: 0.65em 0;
-}
-
 :-webkit-any(.checkbox, .radio) label {
   /* Don't expand horizontally: <http://crbug.com/112091>. */
   display: -webkit-inline-box;
+  padding-bottom: 7px;
+  padding-top: 7px;
 }
 
 :-webkit-any(.checkbox, .radio) label input ~ span {
   -webkit-margin-start: 0.6em;
   /* Make sure long spans wrap at the same horizontal position they start. */
   display: block;
 }
 
 :-webkit-any(.checkbox, .radio) label:hover {
   color: black;
 }
 
 label > input:disabled:-webkit-any([type='checkbox'], [type='radio']) ~ span {
   color: #999;
 }