Use views::style for buttons, bootstrap ash_typography to do so.

ui/views/style/typography.h

 // Copyright 2017 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.
 
 #ifndef UI_VIEWS_STYLE_TYPOGRAPHY_H_
 #define UI_VIEWS_STYLE_TYPOGRAPHY_H_
 
 #include "third_party/skia/include/core/SkColor.h"
 #include "ui/views/views_export.h"
 
@@ skipping 15 matching lines @@
 
   // A title for a dialog window. Usually 15pt. Multi-line OK.
   CONTEXT_DIALOG_TITLE = VIEWS_TEXT_CONTEXT_START,
 
   // Text to label a control, usually next to it. "Body 2". Usually 12pt.
   CONTEXT_LABEL,
 
   // An editable text field. Usually matches CONTROL_LABEL.
   CONTEXT_TEXTFIELD,
 
-  // Text that appears on a button control. Usually 12pt.
+  // Text that appears on a button control. This includes controls with
+  // button-like behaviour, such as Checkbox. Usually 12pt.
   CONTEXT_BUTTON,
 
+  // Text that appears on a button control under material design.
+  CONTEXT_BUTTON_MD,

[Peter Kasting, 2017/04/08 01:38:54]

I don't think I understand why we have to introduce this distinctly in the base
class instead of letting the harmony provider override the meaning of
CONTEXT_BUTTON.

[tapted, 2017/04/10 12:27:33]

The problem is that CONTEXT_BUTTON would also used for things like Checkbox (and
15 other subclasses of LabelButton).

But I think we can default to CONTEXT_LABEL in place of CONTEXT_BUTTON pretty
safely. (i.e. make that default: only pass CONTEXT_BUTTON in places where this
CL was passing CONTEXT_BUTTON_MD).

I considered whether we should use CONTEXT_BUTTON for LabelButtons created by
MdTextButton::CreateSecondaryUIButton() and decided "no". This is because MD
Browser UI (e.g. the download shelf) already uses MdTextButton::Create(..)
directly, even when --secondary-ui-md is DISABLED. The non-Harmony typography
provider needs a way to distinguish between MD and non-MD buttons when it sees
STYLE_DEFAULT_DIALOG_BUTTON since MD buttons should never "increase" in
boldness.

We may still be able to make the assumption that MdTextButton should only ever
be combined with STYLE_DEFAULT_DIALOG_BUTTON when --secondary-ui-md is enabled
(in which case the HarmonyTypographyProvider will just ignore it). But that
feels more risky, and MdTextButton::CreateSecondaryUIButton() will eventually
never create a LabelButton anyway.

[Peter Kasting, 2017/04/10 22:56:02]

But the downside of this is that these are now the buttons which don't get a 0
line height, right?  (See your comment elsewhere.)

If so, that seems worse than the downsides you describe here.  It also seems
less semantically correct: the buttons you describe really are more "button
context" than "label context" in principle, and if we can't handle the
consequences of that, we should cave in and temporarily add the third context
value like you did at first.

What is so bad about letting MD buttons increase in boldness pre-Harmony? 
That's the pre-MD way of indicating a default button.  Do you have some
comparison screenshots so I can see how the two choices there would look?

[tapted, 2017/04/11 01:56:50]

Yup. Have restored the separate MD context. I agree the CONTEXT_LABEL approach
didn't feel as correct semantically either.

 
This was just a case of MdTextButton::CreateSecondaryUiButton() having to do
"something reasonable" when it lacked CONTEXT_BUTTON_MD. Now it has that, we
don't have to worry about tradeoffs there.

And I don't think any of the places that MdTextButton is _currently_ used when
--secondary-ui-md is NOT enabled will ever be "default" buttons. But it's an
obscure thing to have to reason about. Semantics of
CONTEXT_BUTTON+CONTEXT_BUTTON_MD are much clearer.

[Peter Kasting, 2017/04/11 02:24:20]

Right, but if we can eliminate that behavioral special-case, can we eliminate
having CONTEXT_BUTTON_MD versus CONTEXT_BUTTON?  If so that's even better.

If not, what's the long-term plan?  Can we combine these once Harmony ships?  In
the meantime, can we comment more clearly at the declaration here what the
practical reason is for the distinction and when it will be safe to remove?

I'm also wondering if CONTEXT_BUTTON_TEXT_MD or something else more distinctive
might discourage people from using this widely -- it sort of sounds from the
name like CONTEXT_BUTTON_MD is the shiny new way of doing all buttons.

[tapted, 2017/04/12 07:31:48]

I don't think CONTEXT_BUTTON_MD makes sense for LabelButton (I was only
considering it for the special case in MdTextButton::CreateSecondaryUiButton()
when it falls back to using LabelButton). Too much inherits off LabelButton, and
it's used to implement buttons that are not dialog buttons, such as Checkboxes.

Long term (post harmony), I think these are different contexts (possibly more if
the scope of the spec grows to cover more than just "secondary" UI - i.e.
browser window and the Ash desktop).

CONTEXT_DIALOG_BUTTON (in this CL: CONTEXT_BUTTON_MD) - Used in dialogs. gets
bold. no line spacing.

CONTEXT_BUTTON (or something - CONTEXT_CONTROL?) - Used in toolbars, checkboxes
and elsewhere, no line spacing (probably always single-line)

CONTEXT_LABEL - Gets extra line spacing, may be multi-line


Outside of views there are also the "BODY_TEXT" contexts.



That is, after Harmony, there will be no "LabelButton" that is used directly for
buttons on Dialogs. But there will still be LabelButtons used for other things
and semantically it doesn't make sense for them to be CONTEXT_DIALOG_ANYTHING or
CONTEXT_LABEL, so we need a third option.

+
+  // Text for the menu items that appear in the touch-selection context menu.
+  CONTEXT_TOUCH_MENU,
+
   // Embedders must start TextContext enum values from this value.
   VIEWS_TEXT_CONTEXT_END,
 
   // All TextContext enum values must be below this value.
   TEXT_CONTEXT_MAX = 0x1000
 };
 
 // How a piece of text should be presented. This influences color and style, but
 // typically not size.
 enum TextStyle {
@@ skipping 14 matching lines @@
 
   // Active tab in a tabbed pane.
   STYLE_TAB_ACTIVE,
 
   // Hovered tab in a tabbed pane.
   STYLE_TAB_HOVERED,
 
   // Inactive tab in a tabbed pane.
   STYLE_TAB_INACTIVE,
 
+  // Style for the default button on a dialog.
+  STYLE_DEFAULT_DIALOG_BUTTON,

[Peter Kasting, 2017/04/08 01:38:54]

Nit: I'm inclined to name this STYLE_BUTTON_DIALOG_DEFAULT in keeping with e.g.
STYLE_TAB_XYZ.

[tapted, 2017/04/10 12:27:33]

Done. I caved in and sorted some stuff too ;)

+
   // Embedders must start TextStyle enum values from here.
   VIEWS_TEXT_STYLE_END
 };
 
 // Helpers to obtain font properties from the TypographyProvider given by the
 // current ViewsDelegate. |context| can be an enum value from TextContext, or a
 // value understood by the embedder's TypographyProvider. Similarly,
 // |text_style| corresponds to TextStyle.
 VIEWS_EXPORT const gfx::FontList& GetFont(int text_context, int text_style);
 VIEWS_EXPORT SkColor GetColor(int text_context, int text_style);
 VIEWS_EXPORT int GetLineHeight(int text_context, int text_style);
 
 }  // namespace style
 }  // namespace views
 
 #endif  // UI_VIEWS_STYLE_TYPOGRAPHY_H_