►
Description
Weekly sync call of the Static Site Editor group focused on product and design efforts.
A
A
We'll
start
with
the
issue
that
Enrique
left
a
very
in-depth
comment
about
to
summarize
the
problem
touch
UI
in
its
conversion
between
markdown
and
HTML,
in
order
to
render
it
is
making
may
be
slightly
over
aggressive
changes
to
the
syntax
and
actually
incorrectly
parsing.
In
my
opinion,
some
of
the
more
advanced
markdown
which
is
still
technically
standard,
markdown,
like
maybe
maybe
slightly
extended,
markdown
but
I-
think
it's
still
part
of
the
spec
about
using
footnotes
and
tilde
is
instead
of
dashes
for
code
blocks.
A
B
A
A
list
with
bullets
and
then
you
switch
and
you
publish
you,
come
back
to
it,
it'll
reparse
it
if
I
understand
correctly,
using
dashes
based
on
the
default
for
the
for
the
toast
you
I
marked
M
conversion,
not
ideal,
as
he
calls
out
in
the
issue.
It's
great.
If
this
is
the
only
if
you
make
the
project
and
you're
only
using
the
stax
I
editor,
you
would
never
know,
but
the
hint
for
the
handbook
that's
very
problematic,
because
we're
gonna
end
up
with
people's
worth
getting
reformatted.
A
Even
if
we
can
fix
the
the
formatting,
that's
actually
in
error.
The
stylistic
considerations
would
result
in
potentially
a
lot
of
mrs
of
or
a
lot
of
lines
of
code
changed
in
mrs,
that
don't
need
to
be
changed,
and
potentially
you
drive
some
people
a
little
bit
about
hers
with
the
choices
that
we
make
about
how
to
style
things.
People
get
rightly
very
particular
about
the
way
they
write.
Markdown.
A
A
I,
don't
know
if
we
have
an
easy
solution
here,
but
my
gut,
when
I
heard
about
the
issue
last
week
or
not
heard
about
it
when
I
realized
how
big
the
issue
was
gonna
be
last
week,
my
gut
was
just
like
at
least
for
now,
if
we
could
just
replace
the
markdown
conversion
and
or
the
markdown
converter
in
toast
UI,
with
a
fork
that
we
then
just
like
over,
we
I
know
it's
a
lot
of
hand
waving.
A
This
is
significant
work,
but
we
override
that
to
use
our
hand,
book
style
guidelines
and
adhere
to
those.
There
will
still
be
a
problem
with
anything
that
doesn't
follow
those
guidelines.
So
if
somebody's
using
bullets-
and
we
convert
it
to
dashes-
because
that's
the
markdown
style
guide
for
the
handbook
and
then
they
switch
back,
we
will
still
have
the
same
issue,
but
at
least
it
will
be
consistent
and
if
handbook
pages
are
written
consistently,
then
toast
you
I
shouldn't
be
too
noisy.
A
Long-Term
I
think
he's
getting
at
this.
In
the
comment
and
again
sorry
I
haven't
read
in
depth,
but
long-term.
This
would
be
something
that
I
would
expect
we'd
want
to
expose
in
a
config
file
or
some
kind
of
customization
allowing
users
to
maybe
write
their
own
markdown
rules
and
provide
it
to
our
editor
or
or
plug
in
a
different
market
on
parser
altogether.
A
B
It
kind
of
follows
that
kind
of
rules
around
linters
and
stuff,
like
that,
where
you
can
customize
the
rules
and
things,
but
yes
in
the
short
term
since
this
blocks
like
so
what
would
this
block
the
kind
of
swapping
between
the
rich
Texan
they're,
like
markdown
view,
or
do
you
see
us
changing
or
like
preventing
one
of
these
things
from
happening
so
that
we
don't
need
to
deal
with
this
or.
A
Aggressiveness
in
which
it
reformats
things
I,
don't
think
it
would
block
toggling
between
modes
yeah,
but
there
was
actually
an
external
user
there's
a
better
word
for
that
in
our
handbook.
I
know:
I'm
a
community
member
of
the
community
outside
the
gate,
lab
team.
That
left
a
comment
on
this
issue
and
they
were
very
excited
about
the
static
site
editor
but
found
it
to
be
a
blocker
for
them
using
the
tool.
The
WYSIWYG
editor
in
particular
because
of
the
way
it
broke
their
footnotes.
A
So
if
we
can,
if
we
can
fix
that,
but
we
can't
fix
the
aggressive
reformatting
as
you
switch
between
them,
we
might
have
to
disable
the
markdown
mode
until
we
have
a
resolution,
but
that
seems
also
problematic,
because
we
that's
the
only
way
we're
exposing
an
editing,
frontmatter
or
anything.
That's
not
purely
markdown.
A
C
C
Like
how
do
you
want
to
handle
bullets?
How
do
you
want
to
handle
code
blocks
and
these
various
levers,
or
else
we
like?
We
could
start
by
just
saying
here's
a
couple
of
flavors
that
we
support,
but
this
seems
like
to
make
Midori
that
people
happy
we're
gonna
have
to
make
it
really
configurable.
If
we
go
down
that
route,
yeah.
A
I
agree,
and
we
don't
want
to
have
to
like
the
whole
point.
This
is
making
this
an
easy
for
people
to
use,
but
we
also
need
to
remember
that
we
were
always
assuming
there
would
be
a
front-end
engineer
during
the
configuring.
This
was,
it
was
not
meant
to
be
easy
to
I
should
say
it
easy,
it's
not
the
right
adjective.
It
was
not
meant
to
be
like
a
one-click
setup
or
anything
or
like
a
non
technical
setup
wizard'.
A
A
I
think
my
my
feeling
right
now
is
that
we
would
just
continue
to
support
markdown,
but
similarly,
in
our
handbook,
how
we
define
our
markdown
writing
style.
Those
would
be
the
types
of
things
we
would
call
out.
As
customization,
like
you
said,
bullet
style
like
weather
quotes,
get
care
it
on
every
line
or
just
the
first
line
and
honestly
I.
Think
for
the
for
the
near
term
iterations
we
wouldn't
expose
that
at
all.
A
A
C
A
That
was
a
musical
for
them.
Yeah
I'd
be
fantastic,
the
other
thing
I
should
we
should
look
into
and
I
haven't
looked
too
much
into
the
proposed
UX
for
this,
but
I
know
the
web
IDE
teams
working
on
simplifying
the
get
web,
CI
yeah
Mille,
like
creation,
and
giving
real-time
feedback
as
as
that
very
complex
files
being
are,
in
my
opinion,
very
complex
files
being
configured
and
it's
the
beginning
of
a
strategy
to
to
enhance
with
a
live
ID.
A
Static
site
editor,
you
know
config
file
and
we
use
the
the
web
IDE
as
a
you
know,
vector
for
creating
that
file
and
use
the
work
there.
They're
doing
it
doesn't
actually
have
to
be
a
tool
that
I'll
have
to
define
that
in
our
tool
and
if
someone
else
is
doing
something,
that's
making
this
easier
for
people
we
could
probably
piggyback
on
their
their
solution,
but
that
I,
don't
know
I,
know
they're
working
on
actively
I,
don't
know
when
they
expect
to
extend
it
beyond
the
get
live.
A
Ci
file
and
yes,
I-
agree
that
o
pie-in-the-sky
long
term
18
months
from
now.
We
could
absolutely
see
like
feed
me
or
your
project
and
we
could
either
detect
based
on
like
oh,
we
know
you're
using
cramdown
like
we
know
about
that
one.
But
if
we
don't
recognize
it,
we
could
say
like
okay,
well,
give
us
a
give
us
an
output
and
your
source
file
and
we'll
try
and
match
them
up
and
imply
good
sort
of
implicit.
A
Well,
I
think
I
need
to
give
this
issue,
and
this
comment
in
the
issue
a
lot
more
thought
and
a
thorough
response,
but
that's
kind
of
my
take
on
on
skimming
it
over
dinner
and
obviously
it's
it's
probably
the
one
of
the
bigger
decisions
we'll
have
to
make
this
this
month.
So
I
want
to
give
it
to
time.
If
we
have
any
concern,
I
guess
the
the
question.
A
A
One
hand
we
have
very
few
active
users
be
fairly
minimal
disruption
to
change
the
editor.
But
we've
been
you
know:
I,
don't
want
a
sunk
cost
fallacy
this,
but
we
have
invested
some
time
and
getting
it
up
and
running
and
it
works
somewhat.
So
if
there's
another
way,
if
there's
another
approach,
we
can
take
to
handling
handbook
content
in
the
toast
UI
editor
I'm,
open.
B
Cool
I
guess
the
other
one
that
I
have
a
mind
is
like,
potentially
just
not
allowing
the
toggle,
and
then
it
forces
us
to
handle
the
frontmatter
force
us
to
handle
like
editing
of
Mermaid
died
as
differently
in
the
toast
UI
editor
as
those
those
are
things
we
were
gonna
do
or
like.
We
currently
have
like
planned
in
the
future
in
milestones,
so
that
like,
if
he
did
want
to
edit
the
raw
markdown,
then
we
have
a
link
to
like
the
classic.
A
single
page,
editor.
C
B
You
want
to
deal
with
that
stuff,
it
does
make
things
a
lot
Messier
with
like
commits
and
branches,
and
you
know
whether
you're
still
in
the
same
branch
or
different
branch,
and
you
know
that
stuff-
that's
probably
like
another
way
because,
like
you
said
we're
not
there,
it
was
like
we
don't
have
many
users
yet
using
it,
and
we're
still
like
fleshing
out
the
experience
so
I
I
think
we
just
keep
toast
UI
now
until
we
find
a
better
solution,
but
this
is
yeah,
so
does
something
that
could
potentially
force
the
decision
sooner
than
later,
yeah.
A
And
that
that's
a
good
point
and
I'll
and
too
I've
mentioned
this
before,
but
I
think
just
to
reiterate.
I
think
my
take
is
that
our
long-term
goal
would
be
to
disable
that
source
code
editor
in
here
anyway,
like
I'm,
not
really
interested
in
building
a
split
screen.
Source
code,
editor
I,
think
that's
what
the
web
IDE
could
be
for,
or
the
single
file
editor,
but
I
want
to
make
the
WYSIWYG
editor
as
powerful
as
we
can
make
it
so
that
you
don't
have
to
use
anything
like
that.
So
yeah,
editing,
frontmatter.
A
You
know
pasting
code
snippets
into
code
blocks
that
then
aren't
actual
like
rendered
as
code
blocks,
but
you
could
like
set
what
language
or
something
like
that.
You
know.
There's
a
lot
of
things
we'll
have
to
solve
for
I
will
say
that
made
me
think
that
I,
wonder
I
believe
we've
talked
about
this
before,
but
I
wonder
if
there's
an
opportunity
to
try
and
target
only
the
changed
lines.
A
Instead
of
parsing
the
whole
file,
I,
throw
I
mean
you're
gonna
have
to
parse
the
whole
file
to
render
it
in
the
WYSIWYG
editor,
but
I
want
it's.
Probably
too
much
work
to
try
and
like
only
change
the
formatting
of
the
area
of
like
the
blocks
that
are
being
edited
because
I
think,
even
if
we
hide
the
markdown
editor
if
I'm
reading
this
comment
correctly,
you
load,
for
example,
a
very
long
handbook
page
like
the
product
page.
It's
gonna
reformat
everything.
As
soon
as
you
open
the
document.
A
Editor,
and
so
that
means
all
the
bullets
will
get
changed
to
the
style
and
all
the
code
blocks
will
be
formatted
and
pull
quotes
and
be
formatted.
The
way
the
toast
UI
wants
to
format
him,
which
will
have
a
very
large
footprint,
will
say
in
the
merge
request
and
make
the
actual
change
is
hard
to
parts
and,
potentially,
you
know,
go
against
people's
wishes
on
how
they
would
prefer
to
style
their
marketing.
So.
B
C
A
C
Not
necessarily
the
Sun
cost
fallacy
like
we've
invested
some
stuff
and
learning
how
to
do
this
and
understanding
toast
UI,
and
it's
just
code
like
if
in
if
it's
a
platform
that
offers
extensibility
or
it's
at
least
decoupled
enough
to.
Let
us
have
the
possibility
of
doing
this.
It's
it
seems
better
to
try
to
do
that.
Yeah.
A
And
that's
a
good
point:
we're
gonna
run
into
this,
no
matter
what,
unless
there's
something
out
there,
that
comes
with
a
configuration,
a
configurable
markdown
parser.
That's
like
already
covers
everything
we
need,
which
is
unlikely
right,
I
think
we
probably
would
have
come
across
that
already.
So
maybe
then
that's
the
answer.
We
just
need
to
build
that
and
decide
whether
we
contribute
it
back
to
the
project
or
build
it
in
a
way.
That's
only
long-term.
It
would
be
great
to
contribute
it
back
to
the
project.
A
I
will
say
that
okay,
well
I,
don't
want
to
spend
our
whole
half-hour
on
this
one
topic,
but
this
is
interesting
and
will
continue
to
I'll,
continue
to
think
about
it
tonight
and
tomorrow.
I'm
sure
the
conversation
will
continue
before
we
run
out
of
time.
I
did
just
want
to
touch
on
something
Michael.
A
We
talked
about
I
think
we
talked
about
it,
but
I
talked
about
it
with
Marcel
and
we've
talked
about
it
on
the
call,
and
it
looks
like
it's
it's
likely
to
happen,
but
that's
the
handbook
group,
which
is
also
the
statics
I,
headed
a
group
taking
formal
ownership
of
the
entire
handbook,
including
the
U
X.
Instead
of
right
now,
which
we
just
own
the
architecture
and-
and
we
can,
you
know
everybody
can
contribute,
we
can
make
changes.
We
have
made
changes
to
the
UX,
but
we
would
be
the
DRI
for
the
handbook.
A
I
think
we're
getting
some
support
in
conversations
we've
had
with
marketing
about
this
I
think
it
makes
a
lot
of
sense
for
the
handbook
as
a
thing
for
a
clear
owner
that
can
focus
on
it.
I
think
the
two
downsides
that
I
see
are
one.
There
are
some
gray
areas
in
content,
as
we've
discussed,
like
the
direction
pages
and
and
some
things
like
that,
where
we
will,
we
will
find
pages
that
belong
on
one
side
or
the
other
in
a
sort
of
ad
hoc
manner
like
we
can
do
an
audit
and
we
can.
A
We
can
prepare
as
much
as
we
want,
but
there's
gonna
be
someone
that
comes
across
a
page
and
since,
like
well
I
didn't
this
inherit
the
new
style,
or
why
did
you
change
my
page
related
to
X
and
it'll?
Be
because
you
know
it's
on
the
wrong
side
of
whatever
line
we
draw,
not
a
big
deal,
but
it'll
be
something
we'll
have
to
come
up
with
all
right
come
up
with
an
answer
for
and
the
other
thing
is
it
just.
A
It
adds
additional
work
on
your
play,
Michael,
so
you
being
the
designer
for
our
group,
you
would
inherit
a
new
product
to
design
for
I
think
we
would
try
and
keep
the
work
at
least
this
quarter
fairly
minimal
and
go
for
some
low-hanging
fruit
on
the
UX
and
stalking,
with
Sean
about
this
and
I
totally
agree
that
if
we
can
just
find
a
few
wins
and
a
few
tweaks
rather
than
an
entire
overhaul,
that
can
start
to
differentiate
it.
That
way,
we
can
visualize
those
differences
in
the
pages
we
can.
A
We
can
force
that
conversation
about
the
direction
pages,
other
pages,
that
that
wouldn't
be
included
in
those
improvements,
and
that
should
be
then
we
can
work.
Maybe
you
know
through
the
rest
of
the
year
on
a
more
strategic
goal
for
the
handbook
and
and
optimizing
the
experience.
Maybe
do
some
research
figure
out
the
real
pain
points
and
and
propose
some
more
significant,
UX
improvements.
That
would
then
be.
C
We
little
more
freedom
before
time.
Is
that
one
a
Third,
Point
or
I?
Guess
it's
really
at
some
point
of
the
first
one?
There's
it's
not
necessarily
just
deciding
who
owns
a
a
piece
of
content.
It's
there's
a
lot
of
shared
stuff
and
it's
determining
the
dris
for
those
and
that's
and
I
talked
with
John
and
with
Lauren
today
and
I
think
we're
on
the
same
page,
doing
more
of
the
mono
repo
and
trying
to
get
everything
into
the
mono.
Repo
buckets
is
going
to
force
that
issue
and
it's
going
to
make
it.
C
You
know
in
the
data
mono
repo
to
that
yeah
mol
file.
It's
going
to
make
explicit
all
of
these
giant
list
of
files
which
are
shared
and
even
before
we
get
to
that
point,
some
blockers
to
say:
hey.
You
can't
have
this
on
that
part
of
the
site,
because
it's
owned
by
this
and
they're
going
to
be
built
differently
and
on
the
larger
goal,
like
maybe
they're,
moving
to
a
CMS
and
not
even
going
to
be
in
middleman.
C
So
that's
there's
a
lot
of
shared
stuff
and
there's
in
the
short
term,
I'm
mostly
concerned
about
approaching
cleaning
up
it
in
a
way
that
doesn't
introduce
a
lot
of
code.
Debt
like
we
heard
wholesale
start
copying
stuff,
but
that
also
means
we
could
like
copy
about
just
stuff.
We
don't
even
need
or
use
if
we're
not
deliberate
about
what
we
copy
and
maybe
splitting
it
out.
What
still
is
truly
shared
yeah.
A
I
think
that's
an
important
point
and
the
shared
assets
or
this
you
know
the
shared
code
is
a
really
great
way
to
think
about
this,
because
I
think
what
we
would
do
as
we
would.
You
know,
work
on
making
a
better
user
experience
is.
We
would
come
across
in
the
process
of
reality
and
everything
we'd
come
across
what
code
we
can
be
a
lot
more
deliberate
about.
This
should
be
shared
and
that's
the
kind
of
stuff.
We
would
then
know
that
we
need
to
involve
the
marketing
team
or
the
blog.
You.
A
Shares
that
code
with
us,
so
ever
it
also
impacts.
That's
that's
an
explicit
way
of
knowing
that
this
is
and
there's
something
that
should
be
communicated
outside
of
our
group
as
well.
But
if
there's
something
that's
like,
oh,
this
couldn't
be
applied
just
to
the
handbook,
and
it's
it's
for
the
better
that
it's
just
for
the
handbook.
That's
that's
another.
That's
another
decision
we
can
make
and.
C
The
stories
we
have
in
the
epic
are
thinking
along
those
lines.
For
example,
we
want
to
get
everything
into
mono,
Rico
buckets,
and
then
that
will
let
us
stop
having
middleman
at
the
top
level,
be
responsible
for
handling
the
assets
and
then
each
individual
side
have
its
own
webpack.
It
can
build
what
it
wants
the
way
it
wants,
not
what
it
wants.
Maybe
some
some
of
its
own
stuff,
maybe
some
share
stuff,
and
so
those
are
all
stories
in
the
epic
that
they're
gonna
be
a
lot
of
work.
C
A
I,
do
I
see
this
results.
Yeah
I
see
this
as
an
extension
of
the
mono
repo
focus
like
this
is
something
that
we've
been
talking
about
for
months
like
who
owns
this
like.
Should
we
be
doing
this,
but
this
is
just
saying,
like
you
know
what
it
just
makes
sense
and
everybody
seems
to
agree
I,
don't
think
this
is
gonna.
We're
not
gonna
get
a
lot
of
pushback
on
this,
but
I
do
want
to
go
over
a
few
minutes
and
let
let
Michael
chime
in
because
I've
been
talking
for
the
whole
13.
B
A
B
Maybe
these
pages
become
their
own
like
repos
and
stuff
like
that,
so
I
think
owning
the
experience
of
the
handbook
itself
is
makes
sense,
and
you
know
I
think
marketing
will
have
their
own
direction.
That
will
say
like
yeah
we're
looking
after
these
pages,
whatever
that
might
be
so
yeah
I
was
like
I
was
more
concerned
about
kind
of
like
the
turnaround
times
on
marketing
pages,
that,
like
it's
like
you
and
I,
that
this
whole
group,
you
wouldn't
have
any
contacts.
It's
just
like.