This should be distributed to the bugs which specify certain typography sizes.

Mark following up with CrOS team on if this is for them, and relative priority.

From sgabriel@:

This expansion of the typescale is critical for Chrome OS as we are moving closer to harmony release. We have building our UI based on the sizes and line-height defined here with the assumption that they'll match implementation. We'll need it by 69.

I don't think I understand the scope here. We're definitely not adding Google Sans for 69 since that's a huge can o' worms. I'm not going to eagerly add a bunch of unused sizes/styles; if someone needs one for a new context, they're free to add it as part of creating that usage.

So then the remaining work is to increase Headline to 28pt, Body 1 to 14pt, and Body 2 to 13pt. I can do that, but it seems P3 to me (by analogy with the rest of Secondary UI work).

Ah. Let me add some context. CrOS needs these typeface alternatives for other parts of their UI.

Google Sans is NOT in scope for this work.

Right. These are not hypothetical numbers. It's to provide enough flexibility for CrOS and their distinct UIs like notifications, launcher, system tray, etc. 

So the ask here isn't "increase Headline to 28pt." It's "in addition to our current 20pt Headline constant, can we also add 28, 24, and 22."

Similarly with body text, it's not "increase body 1 to 14." It's "in addition to our current 13pt constant, can we add 14, 12, and 11." With that, renaming the constants so they make sense: XL, L, M, S.

#8: That's not how the constants work; they're based on the context where the text is shown. So either they want new sizes for the existing context, in which case we need to change BODY_TEXT_LARGE to 14pt, or they want new contexts, in which case they should add them.

Also: if they want multiple sizes for the same context, that is against the spirit of Harmony and shouldn't be allowed.

Looking at this: 

It looks to me like the way forward is for CrOS to define their own set of contexts, and their own TypographyProvider to resolve them. 

Does that make sense, or am I missing something here?

If their contexts are overlapping, and they really absolutely must have different values than Chrome's UI (which I would discourage), then yes they should have their own TypographyProvider.

But otherwise, there's not really a reason to do it other than code organization.

What would be an example of "based on the context where the text is shown"? Something like, if dialog needs body text, use body_text_large? 

If I understand #9 correctly, we want new contexts not multiple sizes for the same context. 

#13: Your example is correct. That's why I don't want just add a new 14pt body text, it becomes unclear which one you're supposed to use and why (we already had this problem with BODY_TEXT_LARGE vs BODY_TEXT_SMALL).

Adding new contexts is fine, I just don't know what they are. If someone needs one, it's a lost easier to add it alongside creating/updating the UI.

The important part of this for me is to get aligned line-heights so that what happened when we flipped the flag for harmony doesn't happen in the future, i.e line-heights being changed throughout the system and unbalancing the existing alignment of various UI surfaces using typography. 

That's why I thought adding variables already would be a good idea so that when we use 14/20 somewhere, it won't be changed in the future in case Chrome side decides that this type of typography size should actually be 14/18. 

We already went over this extensively in harmony/cros meetings so I'm not sure how to understand/make this clearer :s

Assigning to sgabriel@ for further evaluation. There's currently no additional action needed on dev.

Based on the meeting we had, we can probably close. We'll create new contexts as needed in the platform.