Feel free to assign to Autofill if they should do the work.

The action here probably depends on how we codify the designs that need "Headline 2". I don't think we should abandon the concept of typography context, since it's important for the API's clarity and usability. Which means we should add the context "Headline 2" will appear in, whatever that ends up being.

I think we should rename our contexts to match the spec (so e.g. the existing BODY_TEXT_LARGE becomes BODY_2) and add the others from that spec.  I'm open to name tweaks, but using the same terminology the design specs are using will help to ensure designers provide mocks that translate directly into implementation, so let's agree on something.

It does mean users will have more options to potentially "get it wrong".  Perhaps we can use default arguments or something to make it easiest to do what the existing system wants.  Alternatively, maybe the right course for now is to do nothing special on this front, and when the design team produces their more formal rules for how we're expanding the Harmony/GM2 rules in Chrome to cover cases like Unity/Paradise, we can encode those into the system at that point, and it will be good enough.

Chrome rules also cover more than what's in the spec (e.g. color).  I noticed that in the dialog using the new headline style, it was also setting the color to Grey 900.  Sounds like we probably need some colors to go with the font sizes and line heights here, as the original Harmony spec had.

Hmm, I'm not convinced. It'll be nicer to translate from spec -> code initially, but I think it'll make maintenance way harder, even if no one "gets it wrong" per se. Why is this dialog using BODY_2 and HEADLINE_4 and that one BODY_1 and HEADLINE_2? Like I said before, we /already/ have this problem with BODY_TEXT_LARGE vs BODY_TEXT_SMALL and STYLE_SECONDARY vs STYLE_PRIMARY.

As for using defaults, I kinda think that's what the context system gives us already... the main downside being that you can't really override it to do something custom. So maybe what we should do is have a set of styles equivalent to the spec (i.e. HEADLINE_X, BODY_Y, etc) that the contexts refer to. Then, when necessary, a client can do something like:

label = new Label("my text", CONTEXT_BODY_TEXT); // BODY_2 by default
label->OverrideStyle(BODY_3);

I think some of my comment is based on the assumption that the designers are never going to perfectly crystallize the rules here because in the end the rules are back-figured from "what looked good" -- and they seem to want some flexibility on that front.  So the existing confusion over use of large vs. small, etc., reflects designers making different calls that I am suggesting we let them make.  This does raise the risk of inconsistency, and make it harder for engineers to build things in the absence of input from the Chrome design team, but I feel like my efforts to push hard for those aspects have not been successful, and maybe I need to accept that "reality is messy" and at least say that a bunch of styles with similar names is a better world than "set some arbitrary font size and line height of your own".

I do think it would represent a pretty major retreat from the Harmony mindset of trying to enforce that everything is consistent. I can accept that; we might just not ever have authority powerful enough to make it realistic. But we should be fully aware that's the call we're making.

I think it would be good to raise these issues on the email thread bettes just started internally about how to have consistent concepts and terminology between design and engineering.