►
From YouTube: Typography sync session 2 of 2
Description
In this followup, Sascha, Pedro, and Jeremy continue the discussion on recent typography changes. Specifically, applying styles and communicating intent in Figma, and addressing community feedback through future exploration.
A
Awesome
so
yeah
thanks
again
for
carving
out
some
time
to
do
this
this
just
this
morning,
I
merged
the
the
branch
and
figma
for
the
typography
updates,
so
I'm
I'm
in
the
midst
of
kind
of
I,
think
I
typed
out
a
like
a
read-only
on
the
ux
weekly
for
that
and
linked
back
to
the
number
14
13
issue
in
pajamas
on
the
changes
but
yeah.
We
can
pick
up
with
some
of
the
items
that
we
didn't
get
to
last
time
and.
A
Awesome
all
right
so
textiles
and
figma,
so
we
went
ahead.
The
the
update
that
I
just
mentioned
we
put
together
and
we
kept
things
pretty
one-to-one
as
with
where
they
were
as
far
as
defaults.
So
we
didn't
change
anything
with
like
the
alert
headings
or
the
drawer
per
se
other
than
making
some,
maybe
some
minor
adjustments,
but
we've
currently
been
discussing.
A
It
looks
like
three
different
things
in
there,
which
is
a
like
how
to
present
sensible
defaults
and
what
I
mean
by
that
is
our
designers
start
with
Excel.
Excuse
me,
and
so
you
know
a
larger
break
point
very
rarely.
Are
they
designing
smaller
initially,
if
at
all,
that's
a
topic
for
another
time
but
being
able
to
have
sensible
defaults
so
that
when
they
arrive
at
a
file
use
the
Styles,
they
know
what
they're
getting
out
of
the
box
immediately.
A
In
fact,
I
can
I
could
probably
just
share
that
quick
here,
all
right
go
to
component
Library,
so
an
alert,
for
example,
has
this
heading
style
which
I'd
recommend
being
semantically
in
H2?
However,
you
know
right
here
style
wise.
We
have
UI
label
bold
if
I
were
to
change
this
to
an
actual
H2
it'd,
be
much
larger
and
I
think
that
we
want
to
to
have
the
correct
semantics,
but
but
also
address
component
specific
Styles
and
and
we're
going
to
run
into
this
with
cards.
A
That
heading
would
theoretically
be
smaller
as
well
based
on
the
dynamic
scaling,
and
so
how
do
we
represent
that
in
figma,
so
that
if
a
designer
takes
this
component
and
resizes
it,
they
know
that
a
the
the
headings
should
update
or
B.
They
have
instances
of
it
at
different
break
points
and
we've
had
some
ideas
on
that,
but
we
can.
We
can
go
into
that
a
little
more.
So
all
right,
so
designers
use
that
breakpoint
by
default.
A
There's
only
three
components
that
are:
are
that
make
a
use
of
headings
that
would
be
impacted
by
the
typed
styles
and
then
I
mentioned
yeah
abstracting
those
component
headings.
So
this
point
more
on
the
abstraction
would
be.
Perhaps
maybe
we
can
do
something
where
Banner
alerts
and
drawer,
for
example,
all
use
the
same
abstracted
heading
right
where
we
do
something
where
it's
like
component
H2
or
you
know,
that's
kind
of
probably
a
silly
name,
but
something
along
those
lines
where
it's
abstracted.
A
A
B
B
C
Right
so
maybe
to
add
some
context
so
when
we
currently
doing
in
the
product-
and
we
actually
do
that
very
often
is
we
use
like
a
semantic
H2,
for
example,
but
then
we
slap
a
class
H4
or
H5
or
H3
or
whatever
on
it,
so
that
the
semantically
H2
looks
like
a
visual
H3
to
H,
whatever
right
and
to
bypass.
Basically,
what
we're
you
know
like
what
we're
currently
doing
is-
and
we
know
that
if
we
use
an
H2
in
a
component,
The
Heading
will
be.
You
know
too
big.
B
Yeah
yeah,
it
does
okay,
because
we-
because
you
were
talking
about
H2
in
in
figma,
we
don't
have
that
Semitic.
So
I
wasn't
understanding.
Why
or
how
would
you
have
that?
But
yeah
I
understand
that
it's
when
the
component
is
then
put
in
the
product,
the
element
would
be
an
H2
and
and
then
it
says
you
know
a
bit
up.
A
That
I
think
that's
a
good
question.
I.
Think
it's
too
to
be
determined.
I
know
that,
specifically
for
alerts,
we
would
recommend
an
H2
based
on
kind
of
a
defective
alerts
pop
in
they
have
their
own
section
if
somebody
was
navigating
via
heading
and
a
screen
reader
having
the
alert
be
closer
to
the
top
of
that,
of
that
priority,
I
think
would
be
makes
sense.
Banner
is,
is
potentially
similar.
A
It's
another
section
within
the
page,
so
I
think
that
that
those
two
connect
drawer
to
me
gets
a
little
fuzzy,
but
I
would
also
a
drawer
might
be
similar.
It
depends
on
how
close
we
get
to
modals
with
this,
and
actually
now
that
I'm
thinking
about
it,
modal
actually
has
headers
as
well.
So
that's
another
one
that
that
could
be
looped
in
there
and
both
of
those
it
kind
of
depends
on
your
Paradigm,
with
it
I've
seen,
recommendations
that
say
Hey.
A
You
know
what,
when
you
open
a
modal
which
a
drawer
effectively
is
a
modal
under
the
hood,
it's
just
different
styling
and
position,
but
very
similar
semantics
and
behavior.
When
you
open
that
it's
like
opening
another
document,
so
you
can
do
an
H1
I've
heard
that
argument,
but
I
think
there's
also
Arguments
for
no
it's
a
subset
of
what
you're
viewing.
So
it's
it's
still
within
the
the
page.
So
it's
an
H2.
A
So
some
of
that
we
would
have
to
to
kind
of
suss
out,
but
I
think
that
it
could
be
possible
to
to
align
on
on
a
style
and
then
even
to
to
Sasha's
point
it's
abstracted
enough
that
it
could
apply
to
any
semantic
having
heading
level,
but
it's
just
in
the
context
of
a
component
right.
So
it
would
all
look
the
same.
But
under
the
hood
there
there
might
be
a
different
weight
and
in
that
way,
that
abstraction
allows
us
to
make
it
reused
as
much
as
possible.
A
But
it
would
take
some
design
exercises
to
align
those
headings
and
decide
like
are
those
Dynamic
like
the
rest
of
the
type
scale
like?
Should
a
modal
heading
scale
should
an
alert
heading
scale:
we'd
have
to
sort
through
a
lot
of
those
things,
but
but
for
now
it's
just
tying
that
back
so
that
you
know
if
a
designer
today
goes
and
they
use
an
alert
and
then
the
you
know
they
hand
this
off
and
and
a
developer
goes
to
to
inspect
this
and
they're
like.
A
Oh,
that's,
just
bold
text
that
semantic
meaning
isn't
going
to
be
carried
through.
So
what
we
really
want
to
do
is
be
able
to
say:
okay,
this
is
an
H2.
So
upon
inspection,
okay,
I
see
I
see
that
semantically.
This
should
be
an
H2
and
being
able
to
kind
of
to
help
connect
the
dots
in
that
way,
so
that
are
design
intent,
isn't
Lost
in
Translation
or
handoff.
A
B
C
B
A
B
A
That
container
of
a
drawer
is
not
scaling,
and
so
because
of
that
that
heading,
if,
if
it
was
Dynamic,
it's
proportioned
to
the
rest
of
the
content
or
to
the
you
know
to
the
rest
of
it.
Could
just
you
bump
up
against
that
confined
space
right
and
that's
where,
like
container
queries,
would
be
really
helpful
in
the
future.
I
think
drawer,
drawer,
I
I,
you
know
I
would
lean
more
towards
Dynamic
and
that
being
because
of
how
we're
using
it
where
there
could
actually
be
static.
A
Content
with
other
heading
levels
in
there
put
something
like
a
modal
that
was
kind
of
the
thinking
is
like
this
doesn't
change.
Scale
alerts
can
do
both
they're
both
fixed
and
they
scale
and
their
end
content.
So
perhaps
an
argument
could
be
made
that
those
should
be
dynamic
because
they
are
adapting
to
the
content
as
well,
so
so
I
can
see
that
I
wanted
to,
and
so
so
I
guess
that
all
that
being
said,
I
would
probably
align
with
you
about
the
no
reason
for
them
to
not
be
dynamic,
at
least
by
default.
B
B
C
B
If
you're,
if
you're
able
to
contain
and
say
you
know,
the
fixed
scale
is,
for
you
know,
user
generated
content
or
markdown
or,
however,
you
want
to
contain
it,
and
everything
else
is
the
dynamic
I
think
it
greatly
simplifies
things
and
but
yeah
you
know
just
I.
Think
anyway,
we
should
experiment.
Yeah.
A
If
I
put
it
in
a
large
window,
then
all
these
headings
need
to
change
regardless
of
the
drawer
sizing,
it's
it's
based
on
the
container
around
it,
and
so
we
have
to
provide
that
for
a
designer
to
have.
Whereas,
if
we
just
said
hey
drawer
always
uses
fixed,
then
wherever
you
put
a
drawer
as
a
designer,
you
don't
have
to
worry
about
any
of
it
and
so
from
a
design
standpoint,
it's
probably
easier
to
do
fixed
same
with
alert
because
it's
like,
but
you
know
this
heading's
the
same
regardless
of
the
scale.
A
You
know
even
modal,
it
again
modal.
It's
like
well
the
heading's
not
going
to
change
based
on
the
width
of
the
the
modal
that
you've
chosen,
but
it's
actually
the
width
of
the
container
that
it's
in
that
that
I
think
adds
a
quite
a
bit
of
design,
complexity
so
and
then
I
and
then,
when
we
talk
about
handoff,
there's
more
room
for
air,
because
the
designer
is
providing
this
at
a
static
point
where
in
the
product
it's
not
going
to
be
and
so
trying
to
communicate.
Those
could
be
could
be
a
challenge.
A
B
B
Others
will
be
long,
the
same
thing
in
the
drawer
and
in
an
alert
likewise,
and
then
you
have
translations
as
well,
and
if
we,
if
the
argument
for
fixed
is
so
that
you
know,
designers
can
control
it
better
and
then
you
know
when
they
hand
it
off.
It
looks
as
they
designed
I
think
that
is
not
in
favor
of
you
know
more
elasticity
in
the
design
process
and
and
making
that
into
what
you're
designing.
And
you
know
knowing
that
you
can
control
all
of
the
variables
I
don't
know.
But
that's
that's.
A
I
I
I
think
that's
a
like
a
great
angle
to
come
at
it
I
think
in
the
back
of
my
mind,
I
still
think
of
the
fact
that
the
component
itself
has
its
own
purpose
and
intent,
and
so
letting
letting
your
you
know.
I've
got
a
fluid
with
viewport
and
the
drawer
is
way
over
here
on
this
massive
monitor,
like
the
drawer's
purpose,
is
still
the
same,
so
it
should
you
know,
and
its
width
is
still
the
same.
A
A
B
Yeah,
in
that
case,
I
would
argue
that
maybe
we
should
revisit
the
container
with
for
drawers
like
if
you
have
a
one
of
those
like
panoramic.
This
is
a.
This
is
a
an
extreme
example,
but
if
you
have
like
a
panoramic
monitor
really
wide
monitor,
would
the
drawer
have
exactly
the
same
width
as
if
you're,
in
a
much
smaller,
desktop,
monitor,
maybe
not
yeah.
A
I
I
think,
as
as
we
have
defined
them
today,
it
would
because
we
have
controls
like
this,
where,
if
we
start
to
stretch
those
out
a
little
bit
all
of
a
sudden
we're
losing
relationships
between
like
what
is
help
for
you
know,
it
makes
it
a
little
harder
to
track
things
or
or
we
or
we
get
into
the
argument
of
like
line
length
and
and
whatnot.
So
it's
I
think
there's
a
lot
of
that's
where,
like
once,
you
start
giving
those
components
that
freedom
it.
A
A
A
But
then
the
semantics
are
completely
misaligned
with
you
know
the
dong
and
the
hierarchy,
so
I,
guess
that
that's
where
I'm
getting
at
two
with
with
figma
being
able
to
help
translate
that
so,
like
maybe
some
of
your
thoughts
on
that
and
then
how
how
have
you,
coached
designers
or
yourself
to
provide
annotations
or
to
provide
that
communication,
because
it
and
I'll?
Maybe
my
last
point
on
this
is
it
goes
back
to
you
know.
A
Something
I
brought
up
in
other
scenarios
is
that
we
don't
do
a
lot
of
requirements,
Gathering
or
or
documentation
on
requirements
like
okay.
This
is
the
here's,
the
construct
of
the
thing
we're
building
it
needs
to
have
this
as
a
structure,
and
so
I'm
wondering
how
that
is
communicated
when
it
comes
to
development
and
how
it's
not
even
understood
by
a
designer
to
begin
with
it.
Oh,
this
should
be
an
H2.
This
should
be
an
H3
Etc.
B
B
B
So
I
think,
because
we
don't
have
that
it
leaves
a
lot
of
room
for
interpretation
of
how
you're
going
to
you
know
what
what
will
be
in
the
product
and
and
how
it's
going
to
be
implemented
when
I,
when
I've
designed
it
has
been
a
while
here
at
gitlab
and
when
I've
designed,
you
know
new
pages
from
scratch
that
have
you
know
one
two
or
three
headings:
I
tried
to
document
that
you
know
and
even
if
it's
not
using
the,
for
example,
the
H1
style.
Let's
imagine
I
would
say
hey.
B
This
is
actually
an
H2,
but
it's
using
an
H1
or
vice
so
I
I
made
sure
to
document
that
usually
usually
I've
documented
that
in
the
issue
itself,
because
I
I
that
I've
realized
that
usually
that's
where
developers
pay
the
most
attention,
not
so
much
in
in
figma,
but
I
may
be
wrong.
That
might
be
might
be.
My
experience
I
noticed
that
if
the
requirements
are
there
they're
more
likely
to
follow
that
as
a
single
source.
B
B
The
headings,
if
we're
using
the
proper
markup
for
it
and
usually
it's
it's-
really
easy
because
as
Sasha
was
saying,
you
know,
we
just
say
to
the
engineer:
hey:
can
you
swap
this
for
that
element
that
heading
elements,
but
you
know,
keep
that
class
and
you
know
it's.
It's
really
easy.
The
this
visual
style
is
the
same.
Nothing
breaks
it's
just
changing
the
HTML
element,
but
going
back
to
your
point
of
okay.
So
how
can
we
solve
this?
How
can
we
make
sure
that
there
is
a
good
communication
and
that
things
are
implemented
properly?
B
B
If
we
had
some
documentation
of
hey
you're
starting
a
new
settings,
page
and
you're
designing
that
from
scratch,
this
is
usually
the
hierarchy
and
the
kinds
of
heading
Styles
and
heading
elements
that
we
use
here
or,
if
you're
starting
to
design
a
new
I,
don't
know
Integrations
page,
which
maybe
would
be
similar
to
a
settings
page,
here's
what
you
would
do,
or
so
yeah
I,
think
I
would
try
to
solve
that
with
documentation
for
the
layouts
and
properly
implemented
components.
I
think
that
would
help.
A
That's
awesome:
that's
helpful,
I
just
realized
that
I
wasn't
even
sharing
my
screen,
so
I
was
I
was
going,
I
was
going
back
and
forth
into
figma
and
like
okay,
pulling
up
the
models
and
all
that
and
I
thought
it
was
on
screen.
So
I
apologize
that
that
was
I
was
not
in
there
yeah.
That's
that's
helpful.
I
I
agree
yeah
with
with
the
new
pajamas
update.
A
There
is
a
section
for
page
templates
and
we
don't
have
that
even
visible
yet,
and
that's
because
there
aren't
any
yet
and
so
I
want
to
get
there
to
help,
have
the
concept
of
the
page
structure
and
and
also
some
of
the
capture
some
of
those
templates
and
then
one
of
the
other
things
that
that
we've
talked
about
I.
Think
last
time
was
some
visual
examples.
I
think
you
had
highlighted
that
as
a
kind
of
a
takeaway
the
last
time
in
the
document
to
so
that
we
have
some
use.
A
Cases
represented
with
the
type
scale
and
I
know
we're
planning
on
doing
that
as
well.
Having
showing
some
of
the
break
points
demonstrating
that
so
I
I
hope
to
capture
some
of
that
too.
So
I
think
that's
good
Sasha.
Did
you
have
anything
else
there,
or
should
we
jump
over
to
the
typeface
issues
so
I
feel
like
that's.
B
A
Helpful
Pedro
and
I
think
we
have
like
some
yeah
I
appreciate
that,
because
yeah
and
I
want
to
be
clear
too
I,
don't
want
figma
to
be
like
the
end.
All
like
you
design
it
you
hand
it
off
and
everything's
annotated
in
there
right,
but
I
want
to
make
sure
that
whatever
we
build,
a
doesn't
detract
from
from
that
flow,
but
also
can
supplement
it
in
a
meaningful
way.
So.
C
B
A
C
A
C
A
C
Clear
type
on,
for
example,
can
lead
to
to
some
rendering
issues
at
smaller
font
sizes,
especially
at
14
pixels,
for
example,
IP
and
I.
Both
looked
into
that
there
seems
to
be
like
a
hinted
version
of
of
intern,
which
actually
enables
the
clear
type
feature
which
the
main
fund
does
not
so
we're
currently
looking
into.
C
You
know
if
this
should
be
like
the
sensible
default,
at
least
for
the
product
to
to
use
the
hinted
version
of
intern
or
that
we
built
on
top
of
that
for
our
kit
lab
science,
but
actually
to
this
point
there
was
like
positive
feedback.
If
we
would
go
with
that,
and
now
just
like
10
minutes
or
like
five
minutes
ago,
another
user
posted
that
if
we
would
use
that
font,
the
experience
for
him
would
be
terrible.
C
So
when
I
spin
up
like
a
virtual
machine
on
my
Mac
or
even
if
I
go
to
my
gaming
PC,
which
runs
on
Windows
I,
cannot
actually
see
that
the
issues,
so
it
actually
is
only
on
Lower
screens
and
not
high
risk
greens
and
I
only
have
a
4K
screen
at
home.
So
I
cannot,
you
know,
reproduce.
The
issue
same
goes
for
IP,
but
I
have
a
collab
just
down
the
road
and
they
have
some
old
1080p
screens.
C
C
It
shouldn't
affect
Linux
better.
As
far
as
we're
aware,
we
can
do
some
some
some
testing
on
on
on
different.
You
know
like
distress
as
well,
but
from
the
the
type
of
feedback.
We
got.
It's
all
windows
machines
at
this
point,
but
it's
a
very
good
point.
We
have
to
double
check
on
Linux
as
well,
but
they
use
a
different
rendering
engine
on
Linux
than
on
Windows.
You
know
it's
not
using
clear
types,
so
it
should
be
fine
but
yeah.
Let's
verify
that
this
one.
A
C
A
C
A
Yeah
yeah
I
think
that
yeah
that
feedbacks
it's
valid.
It's
it's.
It's
unfortunate
that
that!
That's
that
that's
happening,
I,
wonder
too.
If
we
can
investigate
even
potentially
some
media
queries
that
might
be
able
to
tap
into
something
like
that,
so
that
we
can
serve
up
something
different
if
needed.
C
Yes,
there
there
is
like
the
the
media.
Query
in
CSS
actually
has
a
density
property,
so
this
could
be
potentially
be
something
we
could
do
that
we,
you
know,
use
the
hinted
version
only
if
you
have
like
a
lowered,
MCT
screen,
for
example,
we
could
also
detect
if
it's
actually
only
you
know
affecting
Windows
machines.
We
could
also
detect.
C
A
specific
variant
you
know,
like
the
information
I
got
from
IP,
is
just
like
the
the
hinted
version
is
a
bit
bigger
because
it
has
all
the
clear
type
hints
in
it
which,
like
the
main
phone,
just
Stripped
Away
in
terms
of
file
size,
so
that
might
be
the
only
downside
of
using
it
for
all
the
systems
because
it
only
at
you
know
at
least
what
we
know.
It
only
affects
Windows
machines
so
but
yeah,
it's
a
very
good
point.
Jeremy.
A
So
providing
a
user
setting
to
fall
back
to
system
fonts,
that's
something
that
we've
also
it's
been
brought
up.
It's
kind
of
this
is
an
interesting
one,
because
we
have
the
the
web
IDE
settings,
which
I
I
think
should
remain
independent.
Probably
they
there
could
be
some
overlap
if
we
connected
them,
but
I
wouldn't
want
to
make
it
a
web
IDE
preference
change
and
have
that
propagate
to
the
product
like
I
might
want
to
go
the
other
way
like
holistically
everything
in
gitlab.
You
know
goes
this
way,
but
but
probably
not
Upstream.
A
One
of
the
reasons
we
did
this.
The
type
change
to
begin
with
was
I.
I
can't
remember
how
I
phrased
it
in
the
blog
post,
but
what
we're
able
to
do
with
one
font
is
we're
able
to
focus
on
many
enhancements,
whereas
if
it's
all
system
fonts,
we
have
like
limited
options
to
work
with,
because
we
can't
get
in
and
tweak
that
we
can't
adjust
the
font
weight,
for
example,
when
we're
using
system
fonts
as
granularly
as
we
can
now
so
so
going
back.
A
It
gets
us
back
potentially
into
the
place
where
some
UI
elements
are
just
going
to
be
wonky,
because
your
system,
font
or
whatever
you
know
like
the
line
height
the
Baseline
and
we're
not
going
to
be
able
to
to
control
that.
Like
that's
a
problem
today,
but
Josh
I'll,
let
you
get
in
your
question.
Sorry,
I!
Don't
want
to
ramble
on
that.
C
You
know
if
we
should,
or
at
least
there's
now,
an
issue
for
you
know
like
making
making
just
a
a
preference
for
the
monus
based
font.
I
feel
that
people,
especially
our
user
base,
is
more
opinionated
towards
the
monospace
pond.
That
was
also
like
95
or
even
more
than
95,
of
the
feedback
in
the
funds
issue
is
regarding
the
monospace
fund
and
not
like
the
UI
font
or
like
the
the
sansari
font
right.
C
C
C
You
already
mentioned
it
that
the
IDE
team
also
wants
to
do
the
same,
so
they
also
change
to
use
in
chaprain's
mono
as
default,
but
they
also
want
to
have
like
a
fallback
to
Menlo,
which
is
like
on
most
system
the
the
you
know
like
the
the
monospace
system
font,
but
we
would.
You
know
there
was
also
like
feedback.
Okay,
let's
give
us
the
chance
to
choose
our
own
font,
but
I
would
say
this.
C
For
me
this
would
be
a
full
stop
in
only
providing
you
know
like
our
default,
which
would
be
chap
brains,
mono
and
then
just
one
option
to
fall
back
to
system
font,
I,
wouldn't
open
the
rabbit
hole
of
you
know
like
just
giving
the
option
to
do
whatever,
because
I
can
already
see
a
lot
of
issues
open
that
the
phone
doesn't
work,
maybe
browsers
at
some
point.
Don't
support
loading
local
phones,
anymore,
I.
C
A
Awesome
I
I'll,
try
to
be
brief.
I
think
my
my
take
like.
If
we
did
any
kind
of
settings,
I
would
just
start
with
mono
spaced,
and
so
my
my
conclusion
would
be
like:
let's
optimize
for
gitlab
Sands,
there's
absolutely
much
as
we
can.
That's
really
where
we're
gonna
be
able
to
do
a
lot
with
the
UI
and
push
it
forward
in
the
ways
that
we
want
to
and
and
provide
a
monospace
preference
and
Pedro.
A
If
you
don't
mind
me,
skipping
really
quick
I
was
just
gonna
suggest
that
we
could.
We
could
explore
other
monofaced
fonts
still
so
one
of
one
of
the
things
I
tried
to
emphasize
in
the
blog
post,
I,
don't
know
how
clear
it
was
was
that
this
is
just
a
baseline
right
by
us
getting
alignment
on
type.
It's
going
to
allow
us
to
fix
so
many
other
issues,
so
the
The
Chosen
typeface
itself
isn't
really
what
it
comes
down
to,
and
so
you
know
like
updating
to
a
different
monospace
font
in
the
future.
A
A
B
Yeah,
just
it's
a
two-year-old
issue
about
custom
monospace
one,
it
doesn't
I,
don't
think
it
has
any
votes,
I
think
so.
When
we
had
the
system,
fonts
I
think
it
was
moral
I,
don't
I,
don't
know
if
it
is
written
anywhere,
but
I
I
think
it
was
General
assumption
was
that
we
would
support
all
system
funds
or
would
try
to
support
all
system
funds.
B
So
if
you're
in
a
Linux
distribution
that
uses
one
font
but
then
you're
in
Windows
and
it
uses
another
font
and
whenever
people
brought
up
issues
with
their
system
fonts,
we
would
try
to
address
them
if
they
were
using
custom
fonts.
We
would
say
you
know,
that's
a
custom
font,
so
I
think,
regardless
of
what
we
do
here,
I
think
we
need
to
have
and
a
stance
on
how
much
we
would
support
things,
because
in
this
case
right
now,
we
only
have
enter
and
and
jetbrains
mono
and
I'm.
B
Assuming
that
that's
the
only
fonts
that
we
would
support
like
if
someone
else
has
a
a
CSS,
you
know
override
to
use
custom
bonds.
We
wouldn't
support
it.
If
we're
opening
the
door
to
fall
back
to
system,
fonts
or
even
custom,
fonts
or
more
I,
think
we
need
to
be
clear
on
how
much
if
we
would
support
them
or
not,
basically
I
an
issue
with
the
custom
fonts,
and
we
we
had
that
as
well
with
the
system.
B
Fonts
is
that,
especially
with
mono
space
that
they
can
have
different,
X,
Heights
and
and
people
will
probably
want
to
also
tweak
the
font
size
of
the
mono
spaced
fonts
if
they
use
a
custom
one
because
they
might
say
oh
I,
love
how
it
is
designed,
but
because
it
has
a
smaller
x,
height
I
actually
want
to
increase
the
font
size.
So
that
might
be
the
follow-up
requests
after
a
custom
amount
of
space.
Fonts
is
custom,
mono
space
font
size
because
I
need
to
tweak
that
as
well
or
else
it
doesn't
work
for
me.
B
A
Yeah
I,
you
know
crazy
thought
is
if
we're
able
to
find
a
mono
space
font
like
variable
and
expose
the
variable
options
to
a
user
to
save
those
as
a
preference
that'd
be
pretty
interesting
because
you
could
adjust
weight
x,
height
width,
all
of
those
properties.
We
could.
We
could
still
load
one
font,
a
single
font,
but
then
you
could
essentially
tweak
these
things
for
your
own
preference,
with
the
variable
setting.
That
could
be
pretty
interesting,
but
anyways
I
know
we're
we're
at
times.
So
I
want
to
get
to
your
other
points.
Pedo.
B
Yeah
Point
beats
about
you
know.
This
was
expected.
Big
visual
change.
People
react.
Some
people
react
negatively.
We
had
I,
don't
think
it
was
such
a
strong
impacts
from
when
we
change
sources
Pros
to
system
fonts,
but
we
also
had
a
few
complaints,
especially
with
the
fact
that
in
many
Linux
distributions
the
system
fonts
have
poor
design
and
yeah
I'm
just
wondering
about
this
idea
of
the
user
preference,
because
it
seems
that
and
was
looking
through
the
comments
you
know
weeks
ago.
B
You
know
not
a
lot
of
recent
comments
other
than
the
windows,
blurriness
and
I
was
wondering
if,
if
the
issues
that
I
think
originated,
this
idea
of
the
user
preference
have
those
issues.
Initial
issues
have
they
been
addressed
and
if
so,
how
much
of
a
priority
this
is
and
what
problems
would
it
solve?.
C
Yeah,
that's
a
very
good
point.
I
think
like
most
like
I
totally
agree
like
most
of
the
feedback
in
in
the
feedback
issue
was
related
to
the
monospace
font
and
the
ligatures,
like
the
combination
of
both,
and
that
was
like
one
of
the
things
which
got
addressed
pretty
quickly
to
remove
the
ligatures
by
default.
C
You
know
just
to
to
have
like
system
like
the
default
system,
font
as
a
fallback
or
if
we
just
you
know
like
want
to
move
ahead,
and
just
say
you
know
like
with
all
the
implementation
which,
which
is
still
do
Jeremy
mentioned
that
you
know
this
is
just
like
the
the
starting
point
of
the
optimizations.
We
do
type
scale
might
be
one,
and
then
you
know
like
with
like
the
variable
font
nature.
We
can
do
a
lot
of
a
lot
more
optimizations,
so
yeah.
C
B
B
Because
this
this
was
expected
right,
so
are
we
do
we
think
those
problems
are
unexpected
and
because,
if
we
were
expecting
some
backlash,
we
would
also
you
know
kind
of
think
yeah
we're
probably
going
to
have
a
user
preference
because
of
this
this
and
that
if
we
weren't
thinking
about
that-
and
this
backlash
is
unexpected
or
certain
parts
of
this
backlash
isn't
expected.
Do
we
need
to
give
this
some
time
for
people
to
get
used
to
the
new
fonts?
B
C
Yeah,
it's
it's
a
very
good
point.
It's
also
where
I'm
a
bit
uncertain,
because
you
know
I
would
I
think
like
part
of
inclusive
design,
would
also
give
like
give
users
the
choice.
You
know.
At
least
you
know
that
they
can
it's.
This
is
like
a
primary
example
for
that
I
guess,
but
it's
also
like
it
could
be
the
starting
point
of
a
lot
of
follow-up
requests
like
you
mentioned,
pedal
right,
so
it
could
be
like
just
a
small
bit
that
we
try
to
to.
C
A
C
Know
like
different
monospace
font,
we
can
choose
from
and
stuff
like
that,
so
it
could
open
the
door
for
a
lot
of
customizations.
We
don't
want
to
have
in
the
product,
but
as
long
as
we
would
just
you
know
like
say:
okay,
this
is
as
far
as
we
go
just
providing
you
like,
the
the
you
know
like
the
fallback
to
what
we
had
before
to
the
system
fonts
and
that's
it.
We
won't
do
like
any
adjustments
in
size
or
whatever.
B
B
C
C
It's
inconsistent,
so
I
can
already
hear
that
feedback
if
we
would
say
no,
but
I.
Think
it's
important
to
just
you
know
like
to
just
have
like
a
starting
and
end
point
to
this
whole
thing
that
we
can
just
say:
okay,
this
is
as
far
as
we
go,
and
maybe
you
know
if,
if
you
go
the
route
in
in
choosing,
you
know
like
the
the
fallback
funds,
then
it's
maybe
just
not
as
supported
as
the
the
default.
A
Like
I
mentioned,
we
put
push
that
Branch
today
or
merge
that
branch
and
we're
going
to
continue
to
build
out
examples
in
figma
using
that
and
explore
that,
and
then
likewise
keep
an
eye
on
the
feedback
issue
to
see
what
we
might
do.
I
think
it'd
be
great
to
have
some
more
conversations
and
maybe
kind
of
take
a
tiered
approach
here
and
and
think
about
feature
flags
and
how
we
might
even
do
some
testing
like
provide
options.
A
Okay,
if
we
fell
back
to
a
system
font,
would
this
be
satisfactory
or
if
we
provided
a
subset
of
open
space
or
open
source
fonts
that
we,
you
know
like
a
set
of
them
that
we
want.
You
know
you
could
choose.
You
know
different
whatever,
or
we
provide
an
option
that
you
can
enter
your
own
font
stack
I!