Proposal for new title class names

[Aveline-art]

At HackForLA website, we have seven title classes named .title-1 to title-7, each denoting a font size in descending order. This system works, for the most part, but what happens if we need a font size between .title-1 and .title-2? We can call it .title-1.5, but where does this decimal system end? 1.25? 1.125? This system will eventually break as we add more and more titles. Why does this break? Simply because adding titles is not a simple task. When a new title is added we need to:

1. add the class to our css store
2. shift all other classes down a title number
3. audit all shifted title numbers
4. replace all instances of shifted title numbers
5. verify that all shifts were done correctly in code
6. verify that all shifts were done correctly visually

These tasks requires not only the attention of the whole team, but would result in a massive increase in what is needless work.

To alleviate the above problem, I propose a new naming scheme for our title classes to more accurately reflect the font size, rather than an arbitrary descending list. For example, if we need a 40px font size which lies between .title-1 and .title-2, we will call it .title-40. If .title-1 is currently 50px, it will be renamed as .title-50.

Now, this proposal will does goes against the spirit of a design system, since it removes any standards whatsoever from the title sizes. This proposal, though, is made under the assumption that:

1. We need flexibility in the sizes we use because we are still trying to reach MVP, and as such design standards can change at the drop of a hat, and,
2. We need a greater workflow velocity, so that we can reach satisfactory MVP as quickly as possible and not get bogged down by low-impact refactoring work.

This proposal is made in order to satisfy these two needs at this pre-MVP stage of the project. This is by no means a permanent proposal. We can return to a more solid .title-1 to .title-7 system once we have a better understanding of what our top 7 sizes are. What we cannot do, however, is allow our design system to chain us to its standards and slow the team down--especially when the goal of a design system is to increase workflow by providing a quick and easy way to create and edit new pages.

Side observation: it is very simple to keep track of our usage of every new .title class we create. If we want some semblance of .title-1 to .title-7, we can create a counter that tracks our top used title sizes by raw usage and/or webpage usage. This allows us to see what the top used titles are, and encourages us to stick to those. At the same time, it also does not standardize the titles, and bind us to its inflexibility.

[Aveline-art]

@macho-catt @arghmatey This sounds insane, but how do we feel about the tentative feasibility of dynamically-created design system pages? I know that these pages are designed via collections or .yml files. Can the .yml files for title sizes (typography?) be dynamically created based on top 7 usage? The GHA will probably work as such:

1. Check out repo and look for .title classes in our html files.
2. Record it's usage (basically good ol' regEx)
3. Take the top 7
4. Sort the top 7
5. Place the top 7 sizes in a template title-size.yml file.
6. Push this template to the repo.
7. ???
8. Profit!

[macho-catt]

I do like the idea of tracking the usage of our title classes (just to understand how they are actually used), but could you elaborate more on the dynamically-created design system? How exactly will the usage of the title classes affect the design system pages? For example, if we find out that (this is just an example, I actually don't know what the usage is) the ranking is something like:

1. title-1
2. title-3
3. title-4
4. title-2
5. title-6
6. title-5
7. title-7

How would that ranking affect the design system page? And how often will this ranking actually change, if our code base doesn't really change that much in terms of typography?

[Aveline-art]

• The order will go from highest font size down, .title-7 -> .title-1.
• The design system page will take the top X number of titles by usage and use those as our standard up until such a time that a different title size supercedes the top X.
• Honestly, the thing I want to insulate against is a) creation of a new title class with ever new title sized used, and b) have our standard title sizes expand to the point of rendering title size standards moot.

Side note: I've asked a friend and the company she works at uses title-${font-size} as their standard internally in the dev team because of its flexibility.

[macho-catt]

I see, that makes a little bit more sense that way. Now, let's say we decide to use the top 4 title classes and they are (just throwing out random titles) title-7, title-6, title-5, title-4. However, the biggest font here is title-4 (24px on desktop). Will design system page then use title-4 for the big title headers, even though in theory the size is too small? Inversely, what if we need to use a small title header but the smallest one we get in the ranking is still too big?

Honestly, changing the title name to font sizes might be the way to go to allow more flexibility, but if we go this route we should be aware that there are traps with specificity like this. This article goes over it, but basically if we have a class title-20 and then designers decide we want to change all 20px to 22px. We have to go over each title-20 to title-22, and at that point it's just unmaintainable as well. I am, however, leaning towards this idea if we just ensure not to fall to that trap.

Maybe there are other ideas like keeping the 7 title classes, but having an eighth mixin/function that allows for any font that is not in the 7 to be used, and this should be used for special occasions. But that also presents its own problems.

[Aveline-art]

• It depends on the purpose of the DS. Is it to have one of each size that we arbitrarily call small, medium, large, etc? Or is it to keep track of common sizes we use, and ensure that the team understands that that is the standard?
• Needing something smaller is almost never a problem on the development side, because developers are never the ones to introduce a smaller size. If we need to use a size we don't have, say a new pages uses 2px, then just use .title-2. It might not be in the top 4, but we can just...kinda...do it, quick and easy...
• If a big title header does not make the cut, it might mean that it is underutilized, meaning that in theory, it would not be our "big title header" but "unusually large size that is used on special occasions".
• Sure, let's have top X title classes and a mixin class called "title-size-var-${val}". If size 20 is in like Top 4, changing it to size 22, will still put it in Top 4.
• There's also the option of having top X title sizes be just internally used data, and have our team interpret it as "we should stick to these because they are frequently used".