-
Notifications
You must be signed in to change notification settings - Fork 45
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[RFC] Typography update #119
Comments
@owendodd - This page is currently private. Can you invite collaborators? |
@damassi yes, should be accessible now! |
cc @zephraph, @l2succes, @oxaudo, @anandaroop, @eessex, @jonallured. (Y'all have all use the type component pretty extensively) |
@owendodd - just a note that we've written a lot of code using the numeric system and this won't be a pleasant refactor! We'll need to discuss migration strategies. |
@damassi yes definitely. Let's discuss at the next meeting if / when / how we would approach this. |
Yeah, this was mentioned as a potential risk in the last meeting. |
Cool, this is totally what I was hoping for, thanks for writing this up! I find it easier to talk about proposals with a little sketch to point at so I whipped up this: jonallured@3be6387. I took the first three headings and wrote out what I think the implementation would be. Did I get the intention right here? We're basically just formalizing and naming certain family/size/weight/style combos, right? Would we be deprecating customers of palette that are using Regardless, I guess the migration would be some find/replace magic - easier for headings that don't cover both families, but shouldn't be too bad. We could also analyze where we have used combos not covered by this proposal. |
I recently finalized a proposal the outlines a refinement / evolution of our existing type system. This update would switch our naming conventions from our more abstract / value based system to something that implies the variables usage, with the hopes of increasing efficiency and ease of use.
This system also incorporates a few other ideas that have previously been discussed. Mainly, the addition of responsive resizing for each variable. There are also additional limitations in regards to available weights and styles at each step to further create consistency in the usage of each.
I'm looking for general feedback on this system and also any specific thoughts around ways we could potentially implement (whether this acts as a layer on top of our existing primitives or replaces them, etc.)
Specifics can be seen here:
Zeplin: zpl://screen?sid=5bd3461a2563d758311d772c&pid=5acd19ff49a1429169c3128b
Notion: https://www.notion.so/artsy/Typography-42e0e8e4f4e34ccc84c7de7adcd1b519
The text was updated successfully, but these errors were encountered: