"Bootstrap" a toolkit-views Typography spec.

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"
+
+namespace gfx {
+class FontList;
+}
+
+namespace views {
+namespace typography {

[sky, 2017/03/16 16:23:51]

How about putting this in the style namespace? Two reason for that. 'style'
matches the name of the directory, which is one of the agreed upon ways to use
namespaces, and 'style' is much shorter, and most importantly I don't have to
think about how to spell 'style':)

[tapted, 2017/03/17 10:33:11]

Done.

+
+// Where a piece of text appears in the UI. This influences size and weight, but
+// typically not style or color.
+enum TextContext {
+  VIEWS_TEXT_CONTEXT_START = 0,

[sky, 2017/03/16 16:23:51]

Can all these enums be named consistently? e.g. CONTEXT_START, CONTEXT_END,
CONTEXT_MAX? Similar with TextStyle enums should also start with STYLE_, e.g.
STYLE_START, STYLE_END...

[Peter Kasting, 2017/03/17 02:26:00]

I like having the "marker" values, which should never be used directly, have
different names.  CONTEXT_ are the real values, while TEXT_CONTEXT_ are markers.
 VIEWS_ prefixes marker values that are specific to the views side of the enum,
which is why MAX is different.

That said, this naming scheme could be one of the things a comment could talk
about, which explained why we're doing these markers.

[tapted, 2017/03/17 10:33:11]

Yeah - that was the intent. I've added an explainer.

+
+  // A title for a dialog window. Usually 15pt. Multi-line OK.
+  CONTEXT_DIALOG_TITLE,

[Peter Kasting, 2017/03/17 02:26:00]

Nit: Should be "= VIEWS_TEXT_CONTEXT_START" (then use >= in the DCHECK)

[tapted, 2017/03/17 10:33:11]

Done (did the same for STYLE). 

+
+  // Text to label a control, usually next to it. "Body 2". Usually 12pt.

[sky, 2017/03/16 16:23:51]

This description implies it's only for labels near other controls. Why not just
CONTEXT_LABEL?

[tapted, 2017/03/17 10:33:11]

Done.

+  CONTEXT_CONTROL_LABEL,
+
+  // An editable text field. Usually matches CONTROL_LABEL.

[sky, 2017/03/16 16:23:51]

That you say 'editable' implies we may have different fonts for editable vs
uneditable. Is that true? I also favor naming this CONTEXT_TEXT_FIELD.

[tapted, 2017/03/17 10:33:11]

There's no plan to make them different at this stage, but naming a 'context'
enum that encompasses both labels and fields. (I'm also considering the
possibility of using `context` to affect text alignment, or background colors in
a generic way, which might distinguish these two).

+  CONTEXT_FIELD,

[sky, 2017/03/16 16:23:51]

CONTEXT_TEXT_FIELD.

[tapted, 2017/03/17 10:33:11]

Done.

+
+  // Text that appears on a button control. Usually 12pt.
+  CONTEXT_BUTTON_TEXT,

[sky, 2017/03/16 16:23:51]

CONTEXT_BUTTON (for consistency with other names).

[tapted, 2017/03/17 10:33:11]

Done.

+
+  // 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 {
+  VIEWS_TEXT_STYLE_START = TEXT_CONTEXT_MAX,

[sky, 2017/03/16 16:23:51]

Why does this need to start at TEXT_CONTEXT_MAX? Aren't the style and context
separate values?

[Peter Kasting, 2017/03/16 19:33:13]

This was explained in previous CL comments, but it should be explained in code
comments here.  Basically, using distinct value ranges lets us get runtime
safety via DCHECKs that people have not swapped the context and style values.

[sky, 2017/03/16 20:48:47]

Ok, got it.

+
+  // Primary text: solid black, normal weight. Converts to DISABLED in some
+  // contexts (e.g. BUTTON_TEXT, FIELD).
+  STYLE_PRIMARY,
+
+  // Disabled "greyed out" text.
+  STYLE_DISABLED,
+
+  // The style used for links. Usually a solid shade of blue.
+  STYLE_LINK,
+
+  // Active tab in a tabbed pane.
+  STYLE_ACTIVE_TAB,

[Peter Kasting, 2017/03/17 02:26:00]

Nit: I tend to prefer STYLE_TAB_ACTIVE, which reads more poorly in English, but
groups better when alphabetizing.

Speaking of which, consider alphabetizing the CONTEXT_ and STYLE_ values.

[tapted, 2017/03/17 10:33:11]

Done.
I tried this out in a number of ways but it never felt right :/. Right now,
they're sorted roughly by size (context), or by frequency of use (for style).
Moving PRIMARY from the top, or making sizes non-monotonic felt weird.

Since typography.h and chrome_typography.h currently capture the entire spec I
don't think it will be common for values to be added or removed with regularity
(i.e. developers shouldn't be wondering "where do I put this"). Or if it's added
to the end, it's probably for an obscure case so satisfies the "frequency of
use" sorting.

+
+  // Inactive tab in a tabbed pane.
+  STYLE_INACTIVE_TAB,
+
+  // Hovered tab in a tabbed pane.
+  STYLE_HOVERED_TAB,
+
+  // 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 typography
+}  // namespace views
+
+#endif  // UI_VIEWS_STYLE_TYPOGRAPHY_H_