►
From YouTube: Static Site Editor - Handling non-Markdown content
Description
A group discussion on how we might handle non-Markdown content
First half is discussing the UX side of things
Second half is discussing the technical approaches
A
A
Alright,
so
this
is
the
issue
that
we're
talking
about
right
now.
The
reason
we're
having
this
group
call
is
there's
a
little
bit
of
discussion
about
how
far
and
how
D
like
how
far
we
want
to
take
this
for
the
milestone
and
plus,
probably
long
term
thinking
what
we're
planning
to
do
here,
so
that,
from
a
design
perspective,
what
I'm
aligned
with
how
it'll
be
implemented
on
the
front
end
side.
B
Sure
so
I
mean
basically
just
for
a
small
piece,
a
history
so
month
and
a
half
ago
two
months
ago,
is
when
I
joined
the
team
and
kind
of
prior
to
that.
I
was
thinking
about
this
problem
and
kind
of
dug
into
it.
So
I
haven't
dug
in
deeply
kind
of
since
then,
but
my
gut
kind
of
still
remains
the
same
in
terms
of
we
would
likely
need
some
kind
of.
B
We
need
an
intermediate
format,
no
matter
what
whether
that's
actually
a
full-blown
ast,
which
is
much
more
complex,
especially
because
each
of
these
files
has
multiple
different
languages
in
it
per
tick.
It's
so
that's
kind
of
a
little
bit
concerning,
but
just
kind
of
a
quick
summary
is
yesterday
and
doing
some
research
just
doing
an
audit
of
our
Handbook
itself.
I
think
we
might
be
able
to
get
away
with
kind
of
a
more
regular
expression
approach.
B
That's
more
riddle,
but
basically
what
I
was
going
to
do
is
set
up
a
meeting
to
brainstorm
ideas
and
I've.
So
I've
added
a
few
of
those
down
below
that
I
linked
to
I'm
gonna,
add
people
to
add
thoughts
at
a
high
level.
I
kind
of
anticipate
some
technical
implementations
and
I
tried
to
share
those
with
how
those
might
compete
or
conflict
with
kind
of
the
initial
design
intention.
B
So
that
was
basically
why,
if
you
scrolled
up
earlier
that
was
kind
of
what
that
comment
was
about
in
response
to
your
kind
of
a
more
ideal
design
solution,
we
might
be
restricted
a
little
bit
by
that.
So
one
example
is.
We
might
actually
have
to
have
multiple
editors
as
opposed
to
just
one,
but
that
may
not
be
the
case,
but
that's
just
an
example
of
how
that
might
you
might
have
might
be
constrained
basically.
A
That
makes
sense
to
me,
so
this
response
is
kind
of
my
idea
around.
Like
should
you
should
we
have
like
a
great
out
state
for
like
content
that
you
can't
edit
or
whatnot
and
yeah
you're
kind
of
your
author
here
is
really
useful
to
see
like
all
the
different
types
of
things
that
could
be
there.
So
that's
good.
A
D
A
Yep
so
I
think
the
intention
of
this
meeting
here
is
alignment
on
what
we
want
to
do
for
a
13.1
in
terms
of
displaying
non
markdown
content
in
the.
What
you
see
is
what
you
get
editor.
So
that
means
all
the
different
types
that
exists.
You
know
different
types
of
content.
How
might
we
present
that,
but
also
for
13.1
we're
starting
to
tackle
images,
so
it's
getting
into
there?
What
I
kind
of
was
exploring
was
this
idea
of
like
do
we
just
gray
out
the
content?
A
Do
we
have
an
image
snapshot
and
then
I
think
this
opens
up
like
Pandora's
box
about
thinking
about?
Okay,
you
know,
there's
lots
of
different
types
of
things
that
we
need
to
do.
Do
we
have
something
specific
so
like
let's
say
if
it's
that
like,
if
it's
a
mermaid
thing
like
do,
we
do
something
special
with
that
or
is
it
just
one
giant
great
thing
that
we
just
I
block
out
completely
so.
D
A
D
D
What
is
what
does
the
user
experience
look
like
for
how
we
handle
non
marked
on
content,
rather
than
do
we
parse
and
end
up
with
abstract,
syntax,
trees
and
stuff,
like
that
and
I
think
those
are
two
really
important
conversations
to
have,
but
I
feel
like
we
shouldn't
have
them
both
from
the
same
conversation,
because
then
we
have
it.
Then
we
have
a
risk
of
of
just
talking
for
hours
and
so
I.
E
If
it,
if
it
might
help
I,
want
to
try
and
be
concise
about
the
product
requirements,
I
was
trying
to
do
this
yesterday
and
I
tend
to
to
ramble
and
concise.
It's
not
something
that
comes
naturally,
but
the
from
from
my
standpoint.
I
think
what
we
need
to
to
address
is
there
will
always
be
situations
where
there's
content
that
we
don't
know
how
to
parse
in
the
WYSIWYG
editor,
whether
it's
a
partial
or
include,
or
whatever
the
template
language.
E
However,
it
implements
like
bringing
in
external
content
or
it
inline,
HTML
or
inline
Ruby,
or
maybe
it's
a
mermaid
diagram
for
the
near
term.
We
have
to
assume
that
there's
going
to
be
content
that
our
was
a
wig
editor
doesn't
understand.
So
how
can
we
display?
That
was
the
the
content
that
is
editable
in
a
way?
E
That
is,
that
continues
what
we've
already
implemented
and
make
it
a
very
pleasant
editing,
experience
without
being
destructive
to
the
rest
of
the
file,
so
identify
the
part
of
the
file
and
I
don't
mean
identify
visually
necessarily,
even
but
just
I
in
the
back
end
identify
the
part
of
the
file
that
we
don't
know.
How
to
render,
or
edit
and
squirrel
it
away
for
a
little
while
allow
the
user
to
edit
the
stuff
that
can
be
edited
and
then
reconcile
that
later
and
I
know.
E
That's
a
big
ask
and
I
think
that's
what
we
need
to
figure
out.
The
technical
direction
or
and
I
do
think
that,
as
we
figure
out
the
technical
direction
it
is,
we
will
necessarily
be
starting
to
talk
about
longer
term
how
we
can
identify
things
like
YouTube
blocks
and
mermaid
diagrams,
and
things
like
that
right
now
for
this
iteration,
what
we
want
to
do
is
just
make
sure
we're
not.
B
D
A
E
E
A
D
E
E
So
yeah
this
was
just
kind
of
for
the
sake
of
conversation,
a
multiple
editor
situation,
where
we
have
a
block
of
markdown
content
that
we
understand
and
then
we
hit
a
break
and
we
say
here's
a
here's,
a
partial
this
is
this
is
some
syntax.
We
don't
understand,
maybe
there's
multiple
lines
under
this,
and
so
we
can
kind
of
collapse
it
and
only
show
the
first
couple
lines
or
something
like
that,
and
then
we
resume
editable
with
a
new
editor.
That's
not
to
imply
that
that
is
a
requirement.
A
E
A
F
D
One
of
the
things
I
want
to
to
maybe
just
throw
out
there,
and
this
might
be
more
to
the
technical
side,
so
we
can
pause
on
it.
If
we
need
to
is
where
they're
having
multiple
editors
on
the
page
will
have
any
sort
of
performance
overhead
it
recur.
It
me
if
I'm
wrong,
but
we
want
to
consider
mobile
as
a
it
kind
of
like
a
medium
that
people
interact
with
the
static
side
editor
with.
D
So
if
we
have
friends
as
a
page
with
yeah,
four
or
five
of
six
different
editor
blocks
on
it,
it
could
potentially
become
you
know
to
initialize
all
of
that
editors
at
page
load,
it
could
be,
could
be
expensive,
and
so
we
might
need
to
have
a
strategy
around
only.we
voices.
We
might
be
to
have
a
pre
editor
state,
where
only
once
you
click
on
it
doesn't
actually
yes
generating
things
out
into
multiple
editors
versus
potentially
I,
know.
Enrique,
you've
mentioned
and
there's
a
custom
renderer.
We
can.
E
Think
you're
right
for
first
of
all,
I
think
until
we
validate
otherwise
we
should
consider
mobile
as
a
maybe
not
a
primary
use
case,
but
certainly
an
important
one,
and
then
I
also
think
that
the
UX
around
multiple
editors
can
be
confusing
I
like
the
idea
of
just
clicking
into
any
content
chunk
and
it
activates.
The
editor
I
also
like
Michael's
exploration
that
he's
shared
I
think
widely
with
moving
towards
more
like
a
medium
type.
You
know
tooltip
formatting
bar
that
activates
as
you
move
down
the
page,
so
yeah
certainly
don't
take
this
as
prescriptive.
D
D
Out
of
the
box,
but
if
you,
if
you
could,
for
instance,
have
a
custom
regular
fall
for
a
piece
of
code,
you
could
potentially
your
wrap
it
and
have
a
clause
and
make
the
text
not
selectable
and
stuff
like
that.
So
this
I
guess
there's
this
workaround
around
it
not
having
building
functionality.
Yeah.
E
A
Works
on
mobile,
for
example,
if
you
open
up
the
mermaid
file,
you
don't
want
to
like
launch
that
on
the
get-go.
Only
if
you
really
need
to
dive
into
that,
and
you
want
that
for
immersive
experience
to
edit
it
and
like
on
mobile.
Maybe
some
editors
just
are
not
supported
on
mobile
like
right
now,
editing
the
handbook
on
mobile
is
already
is
something
that
we
want
to
increase
the
numbers
or
like
observe
the
behavior.
F
B
A
Okay,
cool
I'm
kind
of
good
with
this
kind
of
general
direction
and
if
we're
able
to
parse
they're
like
markdown
file,
detect
that
section
and
like
just
say,
this
is
not
an
editable
right
now
and
display
something
there
in
the
short
term,
we'll
keep
trying
to
keep
it
simple,
as
in
we'll
either
just
have
the
text
there.
We're
not
gonna,
be
super
fancy
and
by
having
an
image
snapshot
or
anything
like
that.
How
does
everyone
feel
about
that?
I.
C
Think
that
an
immersive
snapshot
will
be
something
expensive
to
produce,
at
least
on
the
fly.
When
you
are
trying
to
it,
you
know
a
document,
so
perhaps
we
can
create
something
that
is
very
similar
in
the
turn
in
the
sense
of
creating,
maybe
with
only
element
in
the
editor
that
I'm
not
fully
sure
that
we
can
stop
a
user
from
the
leading
that,
with
only
element
within
the
editor.
At
least.
B
Know
enough
about
the
tous
editor
itself
and
then
also
a
longer
term
I,
don't
know
how
much
we
want
to
you
know.
We
want
to
keep
our
cans
open
in
case.
We
want
to
change
it
and
there's
two:
that's
something
to
consider
if
a
different
editor
doesn't
have
that,
so
my
gut
basically,
is
that
we
have
one.
We
need
the
technical
understanding
to
know
how
to
distinguish
between.
B
It
will
know
that
it
will
and
we'll
talk
about
that
and
figure
that
out
later,
but
once
we
have
that,
then
it's
a
matter
of
if
we
want
to
it
kind
of
consider
John's
thought
about
the
having
multiple
editors
will
have
the
blocks
that
are
editable
and
uneditable,
but
then,
when
you
actually
would
have
that
opt
in
to
actually
do
the
editing.
That's
when
the
editor
instance
itself
would.
A
B
B
Unless
again
toast
you
have,
for
example,
or
any
other
editors
editor
is
able
to
actually
properly
prevent
editing
of
particular
blocks.
Then
we
could,
then
we
could
go
entertain
that
idea
more,
but
otherwise
I
think
it's
it's
hard
for
me
to
envision.
Another
solution
at
the
moment
doesn't
mean
that's
there
isn't
one
it's
it's
just
kind
of
what
I'm
seeing.
D
So
I
think
the
the
the
kind
of
like
summary
de
I
would
say
is
that
for
going
back
to
what
we
want
to
achieve
with
this
call
is
we're
happy
with
the
the
kind
of
like
Lewis
direction
that
was
originally
provided
by
Eric
by
providing
some
sort
of
demarcation
around
the
text
that
is
not
editable?
How
we
technically
achieve
it
is
up
for
debate
still
and
but
from
a
from
user
experience
point
of
view
you
know,
will
show
the
role
content
as
it
is.
A
D
Well,
I
was
actually
gonna
consider
since
we
had
an
hour
booked
for
this
meeting.
Why
don't
we
switch
direction
not
out
to
a
more
technical
discussion
not
at
week?
We've
got
clarity
of
what
we
want
to
achieve
from
a
visual
point
of
view
for
13.1,
the
technical
challenge
remains
is
is
around
identifying
what
is
editable
and
what
is
not,
and
then
you
know
how
do
we
actually
present
that?
F
That
I
had
the
lyrics
for
Michael
if
you
can
make
a
known
and
misses
some
of
the
as
far
as
showing
the
raw
text
I
like
that,
but
some
of
it
may
be
really
verbose,
like
in
the
case
of
mermaid,
charts
or
other
things
like
that.
Maybe
not
the
first
generation,
but
maybe
a
close,
follow
one
like
per
only
show
a
innovator
like
making
it
collapsible,
so
it
really
doesn't
give
them
a
way
of
editing
the
rest
of
the
page.
B
E
We're
adding
scope,
I
I
think
it
might
be
nice
to
indicate
in
this
block
that
it
is
editable
in
markdown
mode,
I
think
similar
to
how
we're
gonna
handle
both
the
Hamel
frontmatter.
This
one,
we
probably
wouldn't
represent
in
the
WYSIWYG,
so
I'm
not
trying
to
add
scope
that
issue,
but
further
down.
If
we
could
have
like
a
link
or
a
button
or
something
that's
like
edit
in
markdown
mode
or
something
like
that,
it
toggles
over.
It's
just
like
an
inline
way
to
switch
over
if
somebody
were
to
want
to
edit
it.
At
this
point.
E
B
And
I
do
want
to
say:
Michael,
don't
I
don't
want
this
to.
This
might
be
now
more
of
a
primary
type
exploration
in
terms
of
design
constraints,
but
don't
let
that
be
the
only
constraint
right
like
because
you
can
still
come
up
with
an
idea.
It
like
allows
us
to
think
differently
about
the
problem
or
something
right.
There's
always
that
potential
stuff.
Just
one
throw
that
out
there.
B
B
All
right
so,
let's
see
where
so
I
don't
know.
If
how
much
we
want
to
follow
so
I
guess,
let's
see
where
I'll
start
is
henrique.
Do
you
want
to
talk
about
anything
specific
in
terms
of
your
additions
here
as
of
right
now?
What
was
it
like
one
through
eight
we're
kind
of
Michael,
and
then
your
next,
if
you
want
to,
if
we
kind
of
want
to
skip
that
way,
anything
you
want
to
talk
about
sure.
C
So
before
I
made
a
comment
there
about
the
eye
weight
which
we
could
organize
cold
if
we
decided
to
follow
the
big
customer
interest
approach,
but
I
don't
know
if
we
are
gonna
follow
that
approach
in
the
first
place.
So
what
I
could
like
the
point
that
I
would
like
to
touch
it's
about.
First,
are
we?
How
do
we
detect
voice
a
because
change
that
we
cannot
display
right
right
now
day
later?
So,
if
we
want
to
that,
we
don't
have
like
they
told
you,
I
ate
it
or
doesn't
tell
me
in
anyways.
C
So
I
think
that,
considering
that,
if
we
have
10
or
20
type
of
content
that
we
cannot
display,
we
have
to
write
code
to
the
tectum
individually.
So
that's
something
that
maybe
could
increase
the
scope
of
what
we
are
working
on
here
so
a
bit.
Let's
say
that,
initially
in
this
iteration
we
decide
that
we
want
to
display
these
on
this
view,
but
we
decided
before
for
every
type
of
content
that
we
cannot
support.
We
will
have
to
write
code
to
it
all
of
those
types
of
content,
so
we
should
consider
that
within
the
scope.
B
I
think
I
think
I
totally
makes
sense.
Now
is
my
understanding
as
well
as
for
it's
almost
like.
We
need
a
cut
for
each
piece
of
content
that
the
editor
itself
doesn't
know.
We'd,
essentially
I
have
to
find
or
author
our
own
and
manage
custom
render
for
that.
That
subset,
and
that
seems
and
I,
think
your
concern
is
right,
like
that's,
it's
a
little
concerning
that
we'd
be
managing
all
those
differences,
especially
in
relation
to
Michael's.
B
C
C
Let's
say
like
that:
they
don't
you
know
way
in
which
the
content
should
be
safe
in
the
repository
that
can
be
extremely
complex
and
also
end
up
that
discards.
The
the
transformation
approach
but
I
think
that
if
we
follow
that
route
we
should
be
very
strict,
or
you
know,
be
very,
very
formal
about
the
way
that
we
define
that
intermediate
approach.
I
would.
D
D
Did
see
I
did
see
an
issue
where
toggling
between
markdown
and
WYSIWYG
mode
has
the.
There
was
a
scenario
where
those
code
was,
but
it
was
it
was
when
it
was
mixed
format.
When
there
was
HTML
left
the
markdown
there
was
being
modified,
but
I
haven't
looked
at
what
it
does
from
a
general
formatting
point
of
view,
I'm
not.
D
It
actually
internally
uses
in
ASD
because
lift-away,
then
it
does
this
this
and
allows
you
to
write
your
own
HTML
over
a
merciful
content.
I
would
assume
that
it.
It
interprets
the
markdown
and
then
uses
its
own
predefined
renderer
for
how
displays
it,
so
it
doesn't
actually
create
that
intermediary
later
I.
C
I
noticed
that,
because
every
time
that
I,
open
the
8
or
they
submit
changes,
button
is
enabled
which
means
that
at
some
point
by
a
tourist,
you
know
making
some
change
in
changes
in
the
content.
You
know
also
noticing
so
I
think
that
it
is
worth
getting
very
familiar
here
with
those
UI
which
is
rendering
engine
and
we,
you
know
everything
that
is
doing.
The
controls.
B
Communicating
that,
if
you're,
really
particular
about
the
source
and
the
forfeiting
of
the
source
may
be
downstream
like
later,
we
can
allow
that
to
more
of
a
option,
but
in
terms
of
more
boring
solutions,
I
think
it's
hard
not
to
see
that
the
solution
is
to
be
like
it's
formatted
this
way,
and
it's
just
that's
it
later.
We
could
change
that.
B
That's
something
you
just
opt
into
when
you
use
this
editor
is
kind
of
how
I
was
envisioning
that
doesn't
make
it
right,
but
that's
how
I
was
thinking
about
it
because
and
to
your
point
Enrique.
It
looks
like
it's
already
happening
and
on
the
last
line
like
if
this
is
a
big,
hard
problem
to
solve
and
the
editors
a
tool,
that's
solved
that
to
some
extent,
but
even
it's
still,
you
know
changing
the
source,
essentially
I.
D
The
line
will
require
us
to
stitch
things
together
and
we
won't
be
able
to
necessary,
preserve
somebody's
personal
preference,
but
in
that
sense
we
should
just
stick
as
close
as
possible
to
to
our
our
our
markdown
Bible,
which
is
the
common
mark,
spec
and
and
just
follow
that
then,
and
as
long
as
we
conform
to
that
we
can.
We
can
always
say
that
this
editor
is,
you
know,
trying
to
be
compliant
to
that.
To
that
that's
vague.
B
B
I
guess,
with
my
analysis
that
I
have
down
here
in
item
10
is
if
we,
if
we
say,
there's
only
text
edits
that
might
save
us
some
time
like
that
might
be
a
good
milestone
to
get
to,
but
as
long
as
whatever
that
solution
is,
it
doesn't
shoot
us
shoot
ourselves
in
the
foot
that
might
be
something
worth
exploring
unless
Jean,
you
know
in
advance
that
we
want.
The
end
goal
is
to
the
near
term.
D
E
I
think
the
yeah
and
yeah
relatively
near
term
I,
wouldn't
say
it's
a
hard
requirement
from
being
in
the
handbook,
but
ideally
we
don't
want
to
have
to
switch
to
the
WYSIWYG
mode
to
edit
non
markdown
content.
So
it'd
be
great.
If
we
could
click
into
these
blocks
of
non
markdown
content
edited
like
any
text
editor,
we
wouldn't
necessarily
need
formatting
or
a
formatting
bar
or
any
knowledge
of
what
syntax
it
was,
but
to
edit
raw
text
within
that
would
be
would
be
helpful.
Also.
D
Potentially
sorry
Derek
so
potentially,
if
we,
if
we
think
back
to
that
to
that
UI
mock-up,
you
know,
if
you
did
click
on
on
edit
for
that
non
editable
block,
it
would
potentially
just
bring
up
some
sort
of
modal
that
allows
you
to
edit
it
in
not
necessary
using
toast
UI,
because
those
UI
is
specifically
focused
just
on
markdown
editing
and
not
trying
to
make
it
do
more
than
that.
What
what
it's
intended
to
do,
but,
rather
than
just
you
know
some
sort
of
editing
experience
outside
of
after
toast.
You
editor
I,
guess.
B
B
A
fine
line
between
a
source
file
can
be
edited,
but
portions
of
it
it's
it's
almost
desirable
for
there
to
be
potentially
two
different
editors,
because
we
don't
want
to
open
up
the
can
of
worms
of
editing
and
the
WYSIWYG
editor
or
whatever
this
markdown
editor
or
whatever
editing
non
markdown
content
is.
Am
I
hearing
that
right
or
well?
I.
D
Mean
from
my
point
of
view,
the
static
site
editor,
you
know,
toast
UI
is
not
a
static
site.
Editor.
The
static
site
editor
is
a
is
a
product
in
github
that
allows
you
to
edit
things
relating
to
static
sites.
Now,
when
we're
talking
about
editing,
markdown
context,
we're
currently
using
toast
yo,
but,
for
instance,
one
of
the
major
kind
of
like
areas
of
traffic
on
the
handbook
is
editing.
Yambol
files,
people
adding
themselves
to
the
team
got
channel
and
stuff
like
that
now
are
we
gonna
we're
not
going
to
create?
D
You
know
a
llamo
editing
experience
within
toast
ER,
but
we
will
likely
need
a
llamo
editor
for
to
create
a
a
more
user-friendly
editing
experience
for
for
a
llamo
file,
so
I
wouldn't
met.
I
would
say
you
know.
Toast
UI
is
a
component
of
the
editing
tool
box
that
we
have
for
static
site
editor.
The
static
site
editor
product
has
a
whole
bunch
of
tools
in
it.
It's
going
to
have
a
file
explorer
tool
that
allows
you
to
to
navigate
the
tree
of
your
site.
It's
gonna
have
a
markdown
unit
or
two.
D
E
You
know
it
iterates
over
a
group
of
I'm,
sorry,
so
maybe
there's
a
maybe
there's
a
loop
that
goes
over
a
data
file
like
like
the
team
yamo
and
pulls
out
our
team's
anybody,
that's
name
that
has
the
the
group
ID
of
a
certain
amount,
and
then
you
maybe
want
to
reorder
those
within
that.
Like
there's
there's
we
can
push
this
further,
but
totes
UI
is
what
we've
identified
as
the
markdown
editor
of
choice.
Right
now,
it
doesn't
necessarily
need
to
be
the
only
other.
So
yes,
I
agree
with.
E
With
that,
it
should
also
be
noted
that
the
the
web
IDE
team
is
looking
into
like
a
pleasant
editing
experience
around
the
get
web
CI
config
file,
so
they're
exploring
a
similar
UX
around
what
like
a
yeah
mole,
or
you
know
what
a
structured
data
file
might
look
like
in
the
web
IDE.
We
should
certainly
talk
to
them.
D
B
So
so
thank
you
again,
John
and
Eric
for
clarifying
Matt
and
Micah,
reminding
us
that,
like
right
now,
we're
kind
of
a
little
bit
focused
on
the
WYSIWYG
editor
and
it's
toast
UI
specifically,
but
really
they
were
trying
to
encapsulate
using
the
UX
of
editing
source
of
all
kinds.
Essentially
what
that
comes
out
to
so
that
lends
itself
a
little
bit
to
this
block
and
kind
of
talked
about.
So
I
just
did
a
quick
and
kind
of
file
audit
of
what's
in
the
in
the
repo
it
just
kind
of
threw
some
numbers
by.
B
Obviously,
I
can
clean
a
lot
of
this
up
as
some
of
this
as
noise,
but
that
I
think
will
lend
it
itself
to
what
you
just
talked
about.
John
is
you
know
for
llamó
files?
Maybe
we
actually
just
launched
a
different
editor
specifically
for
that
same
thing,
with
markdown,
maybe
dot
HTML
dot.
Markdown
is
handled
slightly
differently
in
some
way.
B
Obviously,
I
don't
know
exactly
how
that
manifests,
but
I
think
that
might
help
us
not
have
kind
of
a
god.
Editor
in
the
sense
of
this
editor
does
everything
we
basically
are
able
to
know
based
off
the
multiple
file
extension
pattern
that
currently
exists,
we're
able
to
know
there's
this
type
and
then
it's
like,
and
when
that
that's
the
scenario,
the
editor
there's
a
more
reasonable
editor
to
leverage
or
something
like
that.
So
this
kind
of
aligns
with
what
we've
kind
of
done
already,
where
we
just
allow
markdown
files
to
be
edited.
B
So
I
don't
know
for
what
it's
worth
I
think
there
there
might
be
some
possibility
there.
So
it's
like,
for
example,
yellow
file.
It's
easy
to
at
least
envision
is
probably
a
more
difficult
to
actually
do
like
parsed
it
and
actually
create
a
select
box
for
the
dropdownlist
like
I.
Imagine,
there's
something
that
already
exists
to
actually
parse
the
mo
file
and
map
that
to
form
controls,
essentially
I'd,
be
hard-pressed
if
that
didn't
already
exist,
at
least
in
some
some
form
yeah.
E
I
think
you're
thinking
and
exactly
the
right
direction
there
and
and
I
think
that
some
of
the
some
of
the
explorations
that
I
saw
of
Michaels,
where
it's
more
of
a
block,
editor
and
the
formatting
bar,
is
kind
of
a
tool
tip
I
think
lends
itself
to
that
experience
as
well,
so
like.
If
you
hit
a
block
of
content,
that's
a
it's
a
different
type.
That
requires
a
different
editor.
It
would
just
show
different
tooltip
options.
E
B
Liken
this
a
little
bit
to
unmold,
right,
yeah
and
will
will
essentially
but
like
for
text
inputs
right,
you
can
put
the
I,
don't
know
if
it
it's
tight
but
like
you
can
put
number
or
email
or
whatever
and
then
mold
what
keyboard
actually
changes
right
to
it.
What
types
of
editing
you're
doing
so
I
would
find
that
various
of
elements.
B
Obviously
it's
a
little
not
concerning,
but
something
to
think
about
or
like
we
ideally
there'd,
be
OB
all
one
all
solution,
but
that's
I
think
gonna
be
too
complex.
So
from
a
UX
perspective,
it'll,
probably
look
like
that's
the
case,
but
behind
the
scenes
will
likely
swap
out
what
that
editing
actually
is,
whether
that's
an
editor,
a
custom
form
input
or
whatever
that
happens
to
be
so.
F
D
F
D
D
Gonna
be
the
right
head,
etre
long
term,
but
I
I
had
no
idea
how
long
our
runway
was
left
host
UI
now
the
reason
I
mentioned,
that
is
that,
for
instance,
when
I
looked
into
editor
DOJ's,
it
is
essentially
works
off
a
Jason
AST
internally
and
that's
what
it
gives
you
as
an
output
as
well,
you
know,
and
then
you
can.
You
can
do
with
that.
What
you
need
to
in
terms
of
formatting
it
and
converting
it
to
two
other
options
now.
D
The
reason
we
did
ago
was
there,
for
our
kind
of
initiative
was
just
there
mark
down
conversion
and
stuff.
It
wasn't
there
yet,
in
terms
of
you
know,
just
supporting
what
would
what
we
needed
and
we
believed
in
the
in
the
short
term,
Toshi
I
would
have
would
have
given
us
better
legs,
but
I
am
now
of
the
I'm,
not
questioning
how
much
runway
do
we
have
of
the
toast.
You
are
before
we
run
out
of
out
of
Fox
News
for
it.
Now.
E
In
my
opinion,
we
could
be
successful
on
the
handbook
for
80%
of
the
pages,
with
just
what
we
described
in
the
previous
conversation,
which
is
a
toast,
UI
editor,
but
finding
a
way
to
show
anything,
that's
not
marked
down
as
raw
text
and
and
hopefully
making
it
so
that
people
can't
go
in
and
mess
it
up,
because
we
can't,
you
know,
render
it
properly
or
something
like
that.
So
that
said,
you
know
that's
probably
like.
E
Maybe
this
quarter
of
work,
so
we
we
don't
need
to
kick
off
an
exploration,
replacing
toast
UI
for
the
next
milestone,
but
we,
we
absolutely
should
have
that
conversation
as
early
as
possible
so
that
we
can
do
our
due
diligence
and
make
a
roadmap
for
replacing
it
because
I
agree,
it's
probably
not
what
we're
going
to
be
using
in
a
year.
I
think.
B
It's
worth
mentioning
to
like
a
and
I
haven't
personally
Diana,
no
Enrique
has
more
in
shock
as
well
like
that
might
for
a
specific
example.
Chad
like
that,
might
just
be
a
setting
right
that
we,
it
auto
cleans
that
up
or
we
just
have
to
tap
into
a
particular
life
cycle,
hook
to
clean,
so
I.
Imagine
I
won't
be
surprised
if
something
like
that
exists,
but.
B
So
if
we
already
know
that
we're
only
going
to
allow
the
toast
that's
specific
to
the
toast
UI
editor
we're
not
doing
the
animal
thing
or
the
different
other
things
we're
just
doing
the
toast
UI
for
markdown,
we
have
HTML
AMD's,
where
HTML
DMD
is
the
air
B.
Is
you
can
already
see
that
there
aren't
that
many
air
B's?
We
could
just
say
if
it's
not
a
or
b,
it's
still
edible
and
then
for
dye,
HTML
dot
md's.
That
implies-
and
this
is
work
for
the
research-
would
need
to
be
done.
B
That
is
just
HTML
blocks
and
markdown
blocks,
and
if
that's
the
case,
then
we
can
much
more
easily
I
expect
to
be
able
to
parse
out.
What's
editable
or
not
editable,
anything,
that's
HTML,
we
can
chunk.
Those
out
is
uneditable
just
as
kind
of
like
a
v1
and
everything
else.
In
theory,
I
guess
that's
not
totally
true,
I
guess
what
I'm
trying
to
say
is.
We
could
pluck
out
just
the
things
that
are
actually
headings
and
paragraphs
and
everything
else
if
it's
any
other
kind
of
markdown
syntax.
B
E
D
I
was
gonna,
wrap
up
because
we're
at
timed
and
and
say
like
if
I
put
nice
it
head
on,
he
would
say
just
keep
iterating
until
and
get
keep
getting
feedback.
I
think
the
long-term
vision
we
have
is
something
that
needs
user
research
and
more
time,
and
that
that's
not
that.
Well,
it's
important
to
keep
these
things
in
mind,
and
and
because
we
don't
want
to
chuck
away
everything,
we've
done
and
have
to
start
from
scratch.
D
I
think
when
we
shouldn't
forget
that
we
should
just
keep
iterating
small
incremental
improvements
that
gets
us
there
and
and
to
your
point
Derek.
If
a
boring
solution
gets
us
there,
it's
very
likely
that
it's
a
low
impact
solution
as
well
and
so
that,
if
we
have
to
throw
it
away
for
something
else,
it's
it's
not
it's
not
a
big
piece
of
what
it'd
be
throwing
away
so
I'm.
Definitely
in
favor
of
going
for
boring
I've
got
two
actions
that
I've
summarized
at
the
bottom
of
for
what
I
think
is
coming
out
of
this.
D
The
first
one
is
investigate
where
the
toast
UI
editor
reformat
the
markdown.
If
anything
you
in
WYSIWYG
mode,
that's
purely
said,
we
can
clearly
communicate
to
our
end
user.
If
that
is
going
to
be
the
case
and
then
investigate
showing
non
info
block
in
toast
UI
versus
reading
different
blocks
of
multiple
Toshio
auditory
senses.
I
think
that's
another
consider
from
a
technical
point
of
view
for
for
13.1,
so
anything
else
that
anybody
can
think
of
that.
B
C
Know
I
think
that
young
summarize
it
pretty
well
I
think
that
I
won't
explore
what
we
can
do
with
consumer
interests.
I
think
that's
a
probably
the
most
appropriate
approach
for
the
blocks
and
then
I
really
like
they
be
of
also
like
explaining
and
documenting
these
blocks
that
you
know
that
we
can
actually
load
into
the
ether.
I
think
that
those
are
the
most
viable
options.