Open dadaphl opened 6 years ago
One example that lead me to create this issue is that I can't use the latest version of the ae-address
component in the blockchain explorer. ae-address
has a strong opinion about its own font-size. The design files of the explorer don't match that.
So either the design of the explorer is wrong or the components need to be improved.
see #96
Thinking of components in a responsive way is definitely one goal we have to aim for, not only in regards of design, but also in regards of development.
We should never understand designed components of the files we exchange in e.g. Zeplin as blueprints for component development.
… of the components we’re developing and publishing can be described as universal, and atomic. Universal components need to function and look correct anywhere. On any device, on any screen size, on any operating system, in any browser, everywhere. These universal components should follow the philosophy of atomic design. Components with lots of elements—sometimes called organisms, e.g. our transaction confirmation screen—are made of smaller components with less elements—sometimes called molecules, e.g. our address from–to section—which again are made of several elements—sometimes called atoms, e.g. just the identicon or just the mnemonic name or just the address.
Not working with fixed font sizes anymore, anywhere, is an important step and I think it’s even mandatory. Probably we shouldn’t use px
almost ever and we maybe wouldn’t want to use em
units for calculating e.g. font sizes or margins due to markup, and inheritance. What about using or changing the devices or browsers root font size and use that for our calculations.
$base-font-size: 1rem;
$font-sizes: (
xxs: $base-font-size / 1.6,
xs: $base-font-size / 1.4,
s: $base-font-size / 1.2,
m: $base-font-size,
l: $base-font-size * 1.4,
xl: $base-font-size * 1.8,
xxl: $base-font-size * 2.4;
);
:root {
calc(1vw + 1vh + .5vmin)
}
$base-font-size: calc(1vw + 1vh + .5vmin);
NOTE: root font-size calculations based on viewport width and height are probably not WCAG 2.0 compliant due to zooming issues in some(?) browsers
I used to work for the ICRC, and have developed components for them. The web sites for the ICRC have different themes and also the font size is changeable. In (http://e-brief.icrc.org/issue/new-technologies-and-the-modern-battlefield-humanitarian-perspectives) you can click the cog wheel icon at the right top and use the slider to adjust the font size. And all the components adapt their size. To make this happen we used the CSS unit rem to specify the font size and em to specify the height (if necessary). In this case whatever font size you give the html
element becomes the $base-font-size
. This way nobody needs to introduce SCSS as a dependency to use the components.
In code
$font-sizes: (
xxs: 0.2rem,
xs: 0.4rem,
s: 0.6rem,
m: 1rem,
l: 1.4rem,
xl: 1.8rem,
xxl: 2.4rem
);
ok, then lets move forward with this approach. shall we adjust all components?
Not all aepps will be designed with the same fixed font-sizes in mind.
I'm proposing to develop a size system for aepp-components in which the size can be overwritten by the developers by either setting a different base-font-size or changing the settings of each size directly.
Im proposing seven font-sizes:
xxs, xs, s, m, l, xl and xxl
Each component (that has text) should decide for a default size that can be overwritten (prop). Maybe there could be some exceptions, headline in
xxs
would probably be unreasonable.So far I have not thought about the best way to implement it. Its a proposal for a idea/concept.
Example:
This example is derived from the fixed font sizes found in the explorer design. It could be adjusted for defining a default size for aepp-components.
Please tell me what you think, help me improve my idea and the technical details or propose a different strategy.