Open julien-deramond opened 1 month ago
After discussion a pixel in figma is a point on iOS
For information, a first draft is available in the implementation of #33 due to the need to test the architect with available tokens. Of course any improvements, fixes and implementations after the merge of #33 must be linked to this issue to keep consistency.
In addition, "shared" raw tokens defined in OUDSTheme
module (common to all themes) are not customisable as is in OUDS iOS and should not supposed to be because they define raw types and true values for everything, like a kind of source of truth for everyone. However any theme can define its own raw tokens and assign them to semantic tokens. Of course raw tokens values can be defined thanks to generated Swift code, if we have any efficient and relevant tools suite.
What should be done for this issue:
Some questions and comments to tackle for this issue:
This feature is almost done, however a topic must be tackled about which seems to be a web paradigm. Indeed for some semantic tokens, we may have 3 types of values depending to something which seems to be a screen breakpoint or viewports (e.g. Token value (col-xs-sm) Token value (col-md-lg) Token value (col-xl-2xl-3xl))
What should we do on iOS side? We don't have such logics. Today for the semantic tokens with these three possible values only the one mentioned for case (col-xl-2xl-3xl) is applied, but we need confirmation before review and merge.
In order to test our CI/CD pipeline velocity, avoid to have stale branches, have a fresh code base for documentation and test our production build (for a fake 0.0.0 version), a first version of the tokens has been merged as is, but the issue is not closed because there are some topics to deal about these dimensions tokens.
For several tokens with have three types of values for cases col-xs-sm, col-md-lg and col-xl-2xl-3xl. These notions are very "web" and do not match anything in iOS side. Should we only consider the col-xl-2xl-3xl case?
cc @B3nz01d @mccart77 @ludovic35
FYI first version delivered with commit 5799e669ec87124ec82f2bc0c08bbd4359ec28be and released before version 0.1.0
Description
The aim of this issue is to study and implement the dimension tokens taking into account the cohesive multi-platform approach, the customization by libraries inheriting OUDS iOS, but also what we're using for OUDS iOS: Swift UI, etc.
Reminder: there will be in the end 3 layers of tokens:
Tokens: Dimension
Raw primitive values
{dimension-base}*0=0
{dimension-base}*0.5=2
{dimension-base}*1=4
{dimension-base}*1.5=6
{dimension-base}*2=8
{dimension-base}*3=12
{dimension-base}*4=16
{dimension-base}*5=20
{dimension-base}*6=24
{dimension-base}*7=28
{dimension-base}*8=32
{dimension-base}*9=36
{dimension-base}*10=40
{dimension-base}*11=44
{dimension-base}*12=48
{dimension-base}*13=52
{dimension-base}*14=56
{dimension-base}*15=60
{dimension-base}*16=64
{dimension-base}*18=72
{dimension-base}*20=80
{dimension-base}*24=96
{dimension-base}*28=112
{dimension-base}*32=128
{dimension-base}*36=144
{dimension-base}*40=160
{dimension-base}*80=320
{dimension-base}*120=480
{dimension-base}*140=560
{dimension-base}*160=640
{dimension-base}*180=720
{dimension-base}*220=880
{dimension-base}*260=1040
Semantic applications
Spacing
All spacing properties
Padding inline
Padding stack
Padding inset
Gap inline
Gap stack
Sizing
Width-height: Icon (decorative)
Width-height: Icon (component)
Width-height: Icon (typography)
Max width: Typography
Max width: Component
Study
Technical details
TODO