Typography type feedback #102
Comments
|
Thanks @c1rrus for the amazing work on composite types. It's been fantastic from a tool makers perspective to have these properly defined. There are a couple of things on Typography I'm unsure of: |
|
I think that the typography composite type serves as a good test balloon (or stress test, or canary in the coal mine, maybe) for some of the higher-level ideas about composite types. For example, #86 defines a typography token as one that must include the following five values:
However, in CSS alone, there are at least 57 properties that can change the way text is displayed. CSS properties that modify text
I know it's a bit obtuse to imply that anyone would use all those properties in any given type definition. But It raises an important point: when we choose a subset of these options, we're going to leave out use cases. One approach to this problem is to allow composite types to "openly defined," in that they have a minimum requirement for definition, but that an author may choose to include as many additional properties as they see fit. I'd suggest that if the spec is "open", each composite type is defined as the minimum amount of information necessary to render a given element. In the case of typography, that might just be "fontName" (or "fontFamily") and ("fontSize"). This approach takes a lot of pressure off of the spec, but makes it harder for implementers on the tool side. Another approach is to use a "closed" definition — each composite type has a maximum set of properties, and authors can choose a subset of those properties. In that case, the typography composite type would be defined as one that includes any number of a fixed set of properties (like the ones in the collapsible above). This approach makes it much easier for implementers, since the possibilities for the token are limited. But it does put a lot of pressure on the spec to get the list "right." Typography is definitely the pressure test here; for a token like "shadow," it's possible to just require the full list of properties, since that list is short. But the approach should be consistent between composite types, so typography is a good place to start with some of these challenging questions. |
|
Really insightful. Typography is interesting because it does feel like some of those properties (like the specific five you called out) are very "core" to the look and feel and function of text, and some of them like I think the crucial questions are: do we think we can adequately nail down the right set of those "core" properties in the first group? Do all people have approximately the same mental picture of what text properties are really core and which ones are things that you decide for each specific instance of text? If we can't answer "yes" very confidently to those two questions, I'm a lot more inclined to agree with you here. |
|
Re the “open spec” idea from @ilikescience, I don’t think including all the properties would be too hard on implementers, because most tools will be somewhat platform-specific. For example, several of the 57 CSS properties named don’t work for all browsers on the web yet. Or if they work on web, they may not for native apps. Since typographic attributes are somewhat platform-specific, there could be a wide list of properties and every tool only selects the subset its build target can use. |
|
I, too want to point out that the current selection of properties seems very restrictive. To make it more explicit these are a few I use regularly in our token system:
If they were missing from the spec I would definitely be unable to use the token format for our design tokens. I do think they are important because they finally allow designers more control over the typography in digital designs. My preferred solution would be to have an open spec (minimum requirements + users can add any property), with a list of spellings and definitions for common properties, that is not exhaustive but serves as a guide to tool-makers. If the decision is made to make the spec closed and the list exhaustive, there are some properties that I’d consider out of scope because for me they are about the box that contains the type, rather than the type itself if that makes sense? E.g.:
On another note, I think the description of the lineHeight property is somewhat ambiguous:
“The vertical spacing between lines of typography” doesn’t seem quite right to me. It sounds like it is describing leading, as in the size of the lead strip put between two lines of text, when it is (probalby?) actually refering to the space from one baseline to the next (as in CSS and common design tools). |
c1rrus
added
the
Needs Feedback/Review
|
Hi Community, how about open font features. E. g. to activate a stylistic set? I would like to use a token like
or a little bit more explicit:
|
|
Hi, Whilst I know color is not part of the typography properties as fontSize, lineHeight or even textDecoration, it is intrinsically related to the overall style. ie: assigning specific colors to links or connoting danger through the use of red typography is a common practice. The use of a "typography composite token" relating 2 existing tokens could be extremely beneficial to the overall simplicity. What I mean by this is the following use case.
This logic could be applied to even a default color across typography, communicate different status, etc... |
|
I think that the type for
Currently lineHeight only supports em and letterSpacing only supports px and rem. I would like to suggest the creation of a new type with a name like |
|
Why do the Typography values use "fontFamily" instead of "family"? When comparing, e.g. shadow to typography I see that shadow's values are more context-based, but when writing typography, it's more based on the CSS properties. "microcopy": {
"$type": "typography",
"$value": {
"fontFamily": "{font.serif}",
"fontSize": "{font.size.smallest}",
"fontWeight": "{font.weight.normal}",
"letterSpacing": "0px",
"lineHeight": "1"
}We could make it more context based so it matches the other types in the spec by replacing some of the keys like this? "microcopy": {
"$type": "typography",
"$value": {
"family": "{font.serif}",
"size": "{font.size.smallest}",
"weight": "{font.weight.normal}",
"spacing": "0px",
"height": "1"
}The only problem I encounter is the height property's meaning since we removed the "letter" part. |
I encounter an issue were we don't define a I think there should be a minimum requirement like CC: @ilikescience |
|
Even font family or size could be inherited.
…On Thu, 29 Sep, 2022, 1:08 pm Lukas Oppermann, ***@***.***> wrote:
One approach to this problem is to allow composite types to "openly
defined," in that they have a minimum requirement for definition, but that
an author may choose to include as many additional properties as they see
fit.
I encounter an issue were we don't define a lineHeight so that it
inherits the parents lineHeight in css. However this is not possible with
the current definition as lineHeight is required.
I think there should be a minimum requirement like fontFamily and fontSize
and leave the rest optional.
CC: @ilikescience <https://github.com/ilikescience>
—
Reply to this email directly, view it on GitHub
<#102 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEKS36CHO6OJEAO2L4IJ4ULWAVBOPANCNFSM5L454Y7Q>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
True, from a css centric view those are required for the |
kevinmpowell
removed
Needs Feedback/Review
|
Looking at WCAG 2.1 Success Criterion 1.4.12: Text Spacing it describes all of the values relative to the font size:
So being able to use something like |
|
I couldn't find another issue to tack this on, but I've run into a scenario where I want to use the keyword But, (and now that I think about it, at least in CSS, there's A LOT of properties that can be either a keyword (string), or some other specific type (dimension, duration, color ...) perhaps there is already discussion on how we're supposed to handle a "union" type like that?) |
|
Are all properties of a composite I'd like to define partial token definitions so that I can compose more complex styles after translation? { fontFamily, fontWeight } # base
+ { fontSize, lineHeight, letterSpacing } # extended
-----------------------------------------------------------------
{ fontFamily, fontWeight, fontSize, lineHeight, letterSpacing } # composedContextI've got a slew of various font + style combinations for my typography styles (3 different fonts, 10 different styles/font), and I'd like to minimize the amount of duplicate definitions. I'm thinking that I could define a "base" token, that defines common styles among typography tokens for a particular font, so that I can compose a final value out of {
"type": {
"base": {
"$type": "typography",
"$value": {
"fontFamily": [ "Arial", "sans-serif" ],
"fontWeight": 400,
}
},
"heading1": {
"$value": {
"fontSize": "48px",
"lineHeight": "1.25",
"letterSpacing": "0px",
}
}
}
}When I apply this to Sass, I should then be able to compose a final definition as follows... @use "sass:map";
// generated from tokens.json
$type-base: (
"fontFamily": (Arial, sans-serif),
"fontWeight": 400
);
$type-heading1: (
"fontSize": 48px,
"lineHeight": 1.25,
"letterSpacing": 0px
);
// manually composed style Map
$heading1: map.merge($type-base, $type-heading1);
// ^^ should be equivalent to...
$heading1: (
"fontFamily": (Arial, sans-serif),
"fontWeight": 400,
"fontSize": 48px,
"lineHeight": 1.25,
"letterSpacing": 0px
); |
@EllyLoel -- I think
|
@chris-dura Yeah I'm on the same page, "unitless" |
|
I agree, there may be valid use cases for defining a
|
@CITguy -- fwiw, the current draft for the |
|
Having just read this topic in its entirety, I feel the above definitions of Typography seem to differ more in the sense of Typography as a Design Token vs. Typography as a Component. For a lot of the above-discussed properties a defined composite token might make sense, but in some cases such as the question of whether this might include color attributes it is less clear. If the goal here is to define a format to share combinations of tokens, perhaps something less strictly defined is more appropriate. But at what point are you defining CSS in JSON? And how would changes to a coupled system like that of CSS impact the maintainability of this composite token? |
|
I think the typography type is trying to do too much. There are multiple areas we can split the current implementation in a way that would be easier to use and easier to reason through without having to go through every single CSS property and its equivalent in design tools that consume the tokens. I'm also assuming that if a tool cannot use a given property, it will ignore it The ones that come to mind off the top of my head:
|
|
This feels like a game of 80/20 here. How can the typography catch 80% of use cases? Out of the 57 CSS properties some are more useful than others. The ones that I feel should be at least included, that would cover many cases are text-decoration(useful for link styles), and text-transform(useful for all caps titles/labels). |
|
After much thought, I firmly believe that font weight should not be part of typographic tokens. For example, in the example in the screenshot below, the regular weight content contains a small amount of bold-weight content. 
|
|
These bold text would have to be in a DOM element anyway, a different token would be used.
|
|
My thinking is that the font-weight attribute should be applied to the tokens individually. typography token don't need a font-weight attribute.
|
|
In this case the font weight tokens are telling you what the "normal" and "bold" weights are, so tokens are still a great match for this. For example, maybe design wants "Apple Design Resources" and all of the other bolded sections to appear in weight 600 instead of 700. That's still typically a decision for the design language—the tokens—and not the content being presented. |
IMO, I think the idea behind "typography/type-style tokens" is that this would not be thought of as "regular weight content"... it would be thought of as "body paragraph style content", and it has a couple "strong body paragraph style content" elements. |
|
Small question...why are we putting inside the spec terms that exist only inside CSS? DT are platform agnostic, they must be transformed for each platform and |
|
The technical term for letter spacing would be tracking, not kerning. (Kerning is different from tracking—in CSS that's I'm in favor of terms everyone can understand, and "letter spacing" is self-explanatory and familiar to everyone, where "tracking" is not. I agree it's very important that this spec not become CSS-only, but it's just natural that CSS terms are going to be familiar to the most people. (So for example, I'd prefer "line height" instead of "leading," too.) |
Agreed. I always have to stop and think about which is which (leading vs tracking) when using Tailwind CSS for example, whereas something like "line height" and "letter spacing" is self-explanatory. |
|
And if we need both kerning and tracking? Letter-spacing will fall pretty quick |
I ran into this debate with letter spacing and iOS, too. However, I think the reality of the situation is that most “design system thinking” is going to “start” with the Web platform simply because it’s arguably the largest, and most popular community, so most people will likely be coming from that background, and will understand “the visual language of the Web”, aka CSS. Plus, imo, Design Tokens are going to scale in purpose, but their core feature is to attempt to “describe the visual aspects, attributes and presentation of your design system” —- in that regard, with over 3000 properties (most with common sense names), CSS and the box model do a pretty good job of defining an understandable and common vocabulary to describe a component’s visual attributes (regardless of platform). 🤷🏻 |
|
Topic: line height This is a tough one. Why is it relative to the font size? Also, CSS line height is an aggregated value (baseline divided by font size). If we consider design tokens as the status quo of a visual appearance with an absolute character instead of relations and logic, the value should be an absolute one. |
This is one of the core concept of design tokens. They should always contain raw values, then compiled for different platforms. On iOS there nothing called |
I wonder who the target group of the design tokens will be. Is it okay to be more professional and therefore more precise in the naming, which leaves more room for interpretation and will make it easier for translation tools? |
|
The way I see it, design tokens as both a concept and a file format really only make sense if they're used end-to-end. If you leave an engineer long enough they will inevitably come up with their own form of design tokens: if you remove the standardization bits, apps have been using design tokens for decades, for as long as apps have tried to have visual theming capabilities. Both designers and engineers already have tools that accomplish similar things (color styles in design software, CSS variables, platform-specific resource files, custom tables of color values and font sizes, etc.), and they already use them. The problem that design tokens attempt to solve is that often there's little to no standardization for that handoff from designer to engineer: the way the Figma color styles are set up does not match the way the CSS variables are set up, for example. Details get lost in translation and bugs show up and engineers have to keep asking "what about if it's hovered and focused?" Design tokens as a concept are an attempt to get the designer and the web engineer and the iOS engineer all speaking the same language, clearly. From my perspective, almost all of the value of design tokens comes when you use them end-to-end. |
|
My personal feedback (even though some of this has already been mentioned above):
|
|
Yes, |
|
I think we should consider an approach which contains a parallel to Font Face TokensWith a fontFace token type, we could define all the required font characteristics for font loading Vendors could make use of $extensions to load fonts from their own CDNs, at a bare minimum 'src' could contain the postScript name for trying to find the file, either locally or from a database. PANOSE might also be useful information to store, allowing vendors to get some high-level metrics for the font, without needing to actually touch a font file. Using font faces in typography tokensWith fontFace tokens it would become easy to call the necessary properties by making use of aliases |
I would like to jump on this suggestion, as i agree with the need for a separate
On Android, a user can configure both the system wide screen zoom scaling level and the system wide font size scaling level, from the phone settings. The system wide zoom scaling level affects both dp and sp, when they're transformed to actual pixel sizes The system wide font size scaling affects only sp, when they're transformed to actual pixel sizes |
and others
Is the typography composite type fit for purpose? Should the
lineHeightsub-value use a number value, dimension or a new line-height type?Please share your feedback, thoughts and ideas in this issue.
The text was updated successfully, but these errors were encountered: