►
From YouTube: Typography sync session 1 of 2
Description
Sascha, Pedro, and Jeremy discuss a variety of items related to ongoing typography updates both in Figma and the product.
B
Yeah
thanks
thanks
for
inviting
me
and
thank
you
for
the
well-prepared
agenda.
I
was
able
to
go
through
all
of
these
points.
Some
of
them
I
had
some
questions,
others
not
so
much
and
I.
Think
the
one
that
I'm
still
unsure
of
how
it
would
be
represented
is
the
textiles
and
figma,
but
we'll
get
to
that
and
and
I
hope
that
you,
if
you
have
some,
you
know
visual
examples,
it
might
help
so
yeah.
Okay,
do
you
want
to
go
through
the
list
from.
A
A
C
A
Yeah
sure
we
can
do
that.
Yes,
okay,
all
right,
so
just
at
the
top
here,
I'll
just
start.
You
know
discussion
points,
typeface
choices.
We
we
worked
through
this.
We
chose
enter
and
jetbrains
model
and
then
I
link
to
the
blog
post.
Just
a
little
background
there
you
know
enter
I
know
enter
is
popular.
Everybody
knows
that.
A
You
know
digital
first
approach,
it's
a
UI
typeface
and
for
that
reason,
get
that
being
a
digital
product.
I
think
it
was
apt
to
to
choose
that.
It
also
works
really
well
with
just
geometrically
with
the
Tanuki
and
and
has
some
relationship
there.
So
we
chose
that.
For
that
reason,
jet
bearings
mono
was
chosen
because
of
its
taller
excite
that
that
aligns
with,
inter
where
many
of
the
the
monospace
fonts
are,
are
lower
or
wider.
A
What
I've
told
like
Community
contributors
and
and
whatnot
or
feedback
the
feedback
issue
is
like
hey?
This
is
not.
This
does
not
represent,
like
our
Die
Hard
opinion.
Moving
forward
right,
jetbrain's
mono
could
change
I,
don't
know,
there's
some
other
typefaces,
like
hacker
I,
think
it's
called
or
hack
I'm,
not
sure
that
might
fit
the
bill
as
well.
A
However,
based
on
our
analysis,
this
this
does
that,
but
some
of
the
the
objective
reasons
for
typography
changes
behind
the
scenes
were
actually
so
that
we
could
solidify
and
have
more
consistency
throughout
the
product,
and
now
that
we
are
getting
in
that
direction,
the
font
Choice
itself.
We
have
more
levity
to
kind
of
update
and
and
experiment
with
that,
as
we
get
things
in
alignment,
so
we're.
A
And
then
from
there
we'll
be
able
to
to
make
some
other
decisions
in
the
future
or
or
enhancements
and
address
Community
feedback
concerns
Etc,
and
the
last
point
on
that
is
that
I
would
love
to
see
our
design
be
more
more
opinionated
and
I
know
that
word's
getting
thrown
out
with
competitors
and
other
things,
but
that's
something
that's
been
in
the
back
of
my
mind
for
for
a
few
years
and
I,
don't
I
think
Pedro.
We
probably
talked
about
this
out
of
social.
A
B
Yeah
yeah
just
big
thumbs
up
for
me.
I
was
here
when
we
were
still
using
Source,
Sans
Pro.
For
both
you
know
the
mono
space
version
and
the
Sans
version,
and
we
then
decided
to
switch
to
system
fonts,
yeah
and
I
think
it
was
a
decision
that
had
its
its
pros
and
cons
of
course,
and
had
it
I
think,
more
importantly,
it
had
its
time.
It
was
the
right
moments
and
the
right
decision
at
that
point
in
time
and
and
now
we're
in
a
different
place.
B
The
performance
of
git
love
as
well
is
in
a
different
State,
it's
much
more
performant
than
what
it
was,
and
you
know
that
was
one
of
the
main
reasons
why
we
decided
to
switch
to
system
fonts
back
then
and
and
yeah
I'm.
Personally,
you
know,
as
a
user
I'm
loving
the
the
new
fonts
and
I've
got
feedback
from
friends
that
use
gitlab.
That
immediately
noticed
the
change
and
they
lived
it
as
well,
and
so
yeah
I'm
I
think
we
still
I
mean
this.
A
Answers
here,
so
maybe
I'll
I'll
try
to
be
more
brief,
and
then
we
can
get
to
some
of
your
other
questions,
so
the
type
scale
Direction
just
you
know
mentioning
I
think
I
kind
of
alluded
to
this,
but
you
know
moving
towards
that
single
type
scale
that
has
Dynamic
option
and
allows
some
headings
to
scale,
and
so
I
know
that
the
it's
kind
of
unfortunate,
because
the
type
scales
that
you
had
created
like
we
never
got
them
implemented
into
the
product.
You
know.
B
A
But
then,
as
part
of
that,
allowing
some
flexibility
for
for
dynamic
headings
for
different
areas
and
I
I
think
that'll.
Allow
us
to
have
a
little
more.
You
know,
content
awareness,
if
you
will,
you
know
going
from
docs
to
just
straight
up
issuables
or
something
so
anyways
I'll.
Let
you
jump
in
there,
foreign.
B
That's
actually
something
that
I
have
designed
and
worked
on
for
my
my
personal
websites
and
years
ago,
using
this
I,
don't
know
if
it's
the
same,
but
it's
a
similar
approach
and
yeah,
and
that
was
more
work,
so
I
think
I
didn't
go
that
route
and
I
just
leveraged
the
existing
breakpoints
just
to
yeah,
not
scare.
You
know
engineering
about
the
type
scale,
but
yeah.
C
Yes,
so
the
as
you
mentioned
right,
the
the
current
type
scale
actually
uses
used
break
points,
maybe
just
to
double
down
on
on
that.
We
we
don't
use
any
breakpoints
anymore.
We
just
scale
between
two
break
points,
but
without
actually
having
to
use
break
points.
It's
quite
technical,
but
you
know
we
now
have
like
possibilities
to
to
in
between
changes
with
with
font
sizes
and
other,
like
also
width
and
other
properties,
so
we're
making
use
of
that.
C
So
we
can
actually
use
like
the
starting
point
of
of
the
dynamic
one,
which
is
then
just
like
a
fixed
value
of
all.
The
different
headings
might
be
too
technical
to
follow,
but
I
can
also.
You
know,
like
afterwards
like
link
the
the
actual
code
pen,
because
we
I
did
a
Copan.
So
you
know
that
we
basically
can
see
like
the
difference
between
the
fixed
and
the
fluid
one.
B
A
B
B
A
B
The
fixed
scale
for
compact
markdown
and
it
is
based
off
the
it
basically
has
the
same
values.
I
believe
that
we
have
for
this
small
screen
in
the
dynamic
scale
and
and
yeah.
My
question
was
when
we
had
as
an
example,
I
I
was
using
the
issue
page
where
it
is
possible
that
we
have
competing
heading
levels.
So
indeed,
page
would
be
the
issue
title,
which
would
probably
use
a
heading
one
with
Dynamic
scale,
and
then
we
also
have
heading
ones
in
markdown.
A
C
B
A
B
Just
something
that
I'd
like
to
see
us
explore,
because
on
small
screens
there
would
be
absolutely
no
difference.
I
mean
you
could
potentially
you
know,
add
a
divider
like
an
horizontal
rule
between
the
issue
title
and
the
issue
description
for
example,
so
that
you
know
would
make
some
separation,
but
still
the
visual
hierarchy
would
be.
You
know
there
would
be
no
difference
and,
and
it
might
be
difficult
for
people
to
differentiate
and
even
in
in
the
dynamic
scale.
Sorry,
even
in
in
large,
on
large
viewports
there's
the
subtle.
B
It
was
embracing
that
the
way
that
the
headings
are
used
and
that
allowed
us
to
emphasize
the
difference
for
heading
three
two
and
one
and
then
the
display
as
well,
because
we
were
not
making
differences
from
heading
for
them,
but
yeah
just
something
to
this
to
explore
further
yeah.
So
we
don't
have
to
decide
that
now,
I'm.
Okay,
with
with
just
raising
this
point
and-
and
you
know,
raising
this
so
that
you
can-
you
can
take.
C
C
Has
you
know
like
the
pronunciation
between
H3
and
and
the
display
heading
is,
is
more
or
is
currently
more
nuanced
in
the
new
one
than
in
the
current
one
right.
So
I
totally
agree
with
that,
but
that
was
like
a
trade-off.
Basically,
you
know
like
to
to
accomplish
that.
We
only
can
have
one
for
everything
yeah,
but
yeah
yeah.
B
That's
something
I
like
I,
like
I,
haven't
said
that
before
I
should
have
but
I
like
that,
we
are
removing
one
of
the
type
scales,
so
that
I
think
is
the
documentation.
Markdown,
sorry,
the
documentation,
markdown
type
skill
and
we're
just
going
to
have
you
know
a
dynamic
and
fixed
one
where
the
fixed
is
is
the
recommended
or
Compact
smartdown
and
the
other
one
is
used.
You
know
for
everything
you
know
both
documentation,
markdown
and
the
UI
everywhere.
I,
like
that
change
and
yeah.
A
B
B
B
There
is
a
real
need
for
differentiation
there
and
and
I've
seen
designers
picking.
You
know,
for
example,
heading
to
or
sometimes
even
in
heading
one,
because
they
want
that
differentiation
and
they
can't
get
that
differentiation.
If
they
pick,
you
know
heading
four
or
heading
three,
which
would
be
you
know,
perhaps
the
more
appropriate,
because
you're
just
going
up
one
level
but
going
up
just
one
level
is
so
subtle
that
in
the
UI,
when
you
have
so
many
informed
Fields
yeah
just
another
example.
A
Yeah
I
I
think
click
on
that
I
know
we're
almost
at
time,
and
maybe
we
can
schedule
like
a
follow-up.
If
that
would
be
helpful.
I
think
that
yeah,
the
the
new
type
scale,
is
a
little
more
linear
and
how
it
scales
versus
exponential
I.
The
the
deal
with
the
like
initiable
title
versus
what
somebody
might
enter
and
mark
down
is
an
interesting
one.
I
purposely
always
use
H2
in
the
markdown.
A
You
know,
like
you,
said,
an
underline
some
kind
of
a
separate
section
to
delineate
that
that
might
not
impact
the
type
scale
right,
and
in
that
way
it
would
be
consistent
whether
you're
looking
at
a
Wiki
or
an
issueable.
At
least
you
have
like
a
similar
hierarchy
and
then
on
the
the
point
of
the
forms
and
stuff
you
know,
I,
I,
agree
and
I
think
there's
a
lot
that
we
can
do
to
to
help.
A
Look
at
the
hierarchy
in
that
one
of
the
things
that
we
we
haven't
really
explored
quite
yet
is
are
different
weights.
I
would
love
like,
for
example,
with
our
forms.
I
would
love
to
say
instead
of
bold
for
the
label
weight
I
would
love
to
be
like,
let's
use
semi-bold
or
since
we're
using
a
variable
weight.
A
Let's
lighten
that
up
a
bit
and-
and
we
have
this
typeface
in
in
place
with
other
capabilities,
we
have
other
kind
of
knobs
and
dials
that
we
can
tweak
to
help
with
that
hierarchy,
and
that's
one
of
the
awesome
goals
about
moving
away
from
the
system.
Fonts
is
now
we
have
these
extra
levers
to
to
use
to
do
that,
and
so
I'd
love
to
be
able
to
to
see
how
we
can
do
that
and
then
help
designers
and
say:
okay,
here's
a
new
section.
A
You
know
in
a
form
like
how
is
that
communicated,
semantically
and
and
how?
How
would
we
structure
that,
because
I
don't
like
headings
in
a
form,
I'm
kind
of
you
know,
even
that
in
itself
is
a
whole
conversation
when
it
comes
to
to
semantics
and
stuff,
but
anyways
I,
I
think
there'll
be
some
more
capabilities
for
us
to
to
express
differences
in
visual
weight.
A
B
Was
saying
I'm
sorry
when
I
was
saying
that
headings
just
to
clarify
when
I
was
saying
the
headings
in
the
form,
it
was
more
just
the
visual
style
right
so
to
I.
I
believe
that
you
know
to
simplify
we.
We
should
try
to
rely
on
the
heading
Styles,
not
necessarily
on
the
heading
elements
in
HTML,
but
when
you
know
designers
are
designing,
you
know,
for
example,
for
the
field
set.
They
might
want
to
use
a
specific
heading
style
so
that
we
don't
need
to
design
a
specific
Style
just
for
the
field
set.
A
B
B
B
Notionable
with
comments,
because
even
here,
if
we
just
zoom
in
there
is
intention
from
the
content
author
to
create
different
headings
and
have
a
you
know
the
hierarchy,
but
that
intention
is
deluded
I
believe
for
the
reader,
because
it
is
so
subtle.
The
differences
in
sizes.
Like
you
just
look
at
these
two
here.
C
C
A
Yeah
that'd
be
awesome,
I
think
that's
a
great
suggestion,
Pedro
and
just
to
wrap
us
up,
because
I
gotta
jump
to
another
meeting.
But
if
you,
if
you
wouldn't
mind,
I'll
set
up
a
follow-up
too,
but
in
the
meantime
like,
if
you,
if
there's
like
pages,
that
that
you're
aware
of
that
you're
like
man,
I'd
love
to
see
how
the
hierarchy
plays
out
on
that
like
as
as
like
representational
examples,
I
would
love
to
take
those
and
build
those
out
and
and
kind
of
play
with
that
and
see
what
the
result
looks
like.
A
B
A
C
C
But
you
know
you
already
get
a
glimpse,
how
it
looks
and
feels,
and
also
in
that
issue
we
have
like
a
you
know,
a
compact,
smart
markdown
example.
So
you
can
already
see
like
the
difference
between
that
and
like
the
other
headings
we
have.
So
you
know.
If
you
have
time,
you
can
also
have
a
look
there
as
well.