►
Description
A sync up covering:
- HTML in WYSIWYG mode
- Custom renderer issues status
- Next steps for handbook integration
A
A
A
So
I
sent
this
meeting
initially
just
with
Enrique
I
just
wanted
to
sync
on
some
things.
Obviously
I'm
glad
Eric,
you
could
join
as
well.
So
if
you
have
anything
to
add,
definitely
please
do,
but
these
are
the
kind
of
high-level
things
that
I
wanted
personally
to
kind
of
sync
with
Enrique
on.
So,
if
there's
something
else,
please
let
me
know
so
I'll
just
kind
of
go
over
them
top
level.
A
B
I,
the
Peroni
said
they
ate
or
was
removing
HTML
blocks,
probably
because
they
were
video,
they
were
embedding
videos
or
an
iframe,
and
that's
probably
not
secure
right.
So
I
think
that
since
you
implemented
our
something
that
is
converting
those
HTML
blocks
into
safe
content,
like
text
content,
that's
probably
address
right.
Yeah.
A
So
so,
yes,
and
so
v1
is
basically
so
and
I
can't
remember
if
your
comment
was
related
to
the
v1
implementation
or
no
implementation,
so
basically
we'll
walk
through
that.
So
v-0
is
basically
what
we
had
we're.
Whatever
is
HTML
in
the
initial
file.
That's
edited
the
toast
UI
in
WYSIWYG
mode,
we'll
try
to
just
render
that
HTML.
A
So
that's,
basically
how
so
that's
v-0
v1
was
us
actually
wrapping
it
in
the
uneditable
block
and
that's
merged
now,
and
then
v2
is
basically
so
what
he
wanted
Able's
is
it
at
least
prevents
you
from
editing
that
HTML?
But
again,
it's
not
like
the
end
in
game
solution,
because
you
could
technically
still
interact
with
it,
for
example,
if
there
were
buttons
within
it
and
things
like
that,
it
was
a
small
technicality
where
we
could
have
prevented
that
also,
but
because
we
knew
there
was
a
b2
coming
that
it
wasn't
worth
it.
A
So
v2
actually
converts
it
as
a
noreagaaa
just
mentioned
to
rita
as
text
instead
of
HTML
and
what
that
allows
it
to
be,
as
it's
just
plain
text
and
as
such,
that
enter
doesn't
interpret
it
as
HTML
and
as
such
it
doesn't
render
in
the
various
HTML
blocks
you
might
otherwise
expect.
So
this
is
a
good
blanket
solution.
A
I
think
for
right
now,
in
terms
of
preventing
editing,
I
know,
maybe
you
know
in
iteration,
people
might
want
certain
content
show
in
line
and
then,
unless
we
figure
something
else
out,
I
think
we're
gonna
have
to
go
on
a
case-by-case
basis
of
saying
certain
subsets
of
HTML.
We
want
to
actually
render
as
HTML
and
some
we
don't.
So
that's
that's
something
we'll
have
to
figure
out
downstream.
So
that's
just
kind
of
the
status
of
that
so
I
will
v1
diverged,
I
will
rebase
v2
and
depending
how
quick
the
approval
process
is.
A
Okay
and
the
next
one
is
just
a
general
chat
of
status.
So
then
the
last
big
one
is
what
we
just
kind
of
talked
about.
The
v2
HTML
custom
render
the
other
one,
which
is
a
follow
up,
which
kind
of
relates
to
the
previous
one,
with
respect
to
Henrique
talking
about.
Sometimes
the
toast
UI
editor
just
removes
the
notes
completely.
So
one
example,
for
example,
with
the
v1
implementation,
was,
if
you
had
a
link
tag
that
was
loading
a
stylesheet.
A
You
know
in
the
source,
dot
MD
file
once
that
converted
it
would
get
rendered
and
consumed
by
the
browser.
And
then,
when
you
went
back
to
mark
download,
the
link
tag
would
be
gone
completely.
So
I
think
that's
the
one
I
experienced
it
sounds
like
you
may
have
experienced
that
with
iframes
and
videos,
and
things
like
that.
So
again,
the
b2
solution
will
solve
back.
A
But
what
that
means
I
ran
into
something
similar
with
this
identifiers.
Syntax
and
I
can
go
to
this
link.
I.
Think
so.
Can
you
guys
see
my
still
see
my
these
screenshots
yep
thanks
Pete?
So
this
one-
and
this
is
so
this
line
this
paragraph
right
here-
this
is
the
before-
and
what
it
has
is
this
special
syntax
for
its
bracket
bracket
and
then
optional
bracket
bracket,
and
what
this
is
is
basically
a
you
know.
A
You
alert
boxes,
for
example
right
here,
and
it
points
to
this
URL,
and
then
you
can
reuse
that
numerous
times
within
the
content.
So
that's
what
this
is.
So
that
make
sense,
so
so
that's
handled
down
here,
but
the
actual
instances
of
when
you
use
these.
That's
what
I'm
trying
to
solve
for
right
now.
So
in
line
that's
why
they're
still
showing
up
as
raw
text
I
ran
into
so
this
is
what
it
looks
like
rendered
when
it
actually
works.
A
So
now
you
can
edit
the
text
you
wouldn't
be
able
to
edit
just
the
portions
that
match
those
that
syntax
the
problem
I'm
are
running
into
right
now
is
that
when
you
go
to
markdown
mode,
these
the
HTML,
the
custom
HTML
that
we
wrap
these
in
is
persisted
in
markdown
mode,
and
we
obviously
don't
want
that.
So
I'm
gonna
spend
a
little
bit
more
time,
trying
to
solve
that.
If
I,
don't
I,
think
what
we're
just
gonna
right
now
so
I
think
I'll
try
to
solve
that
number.
A
A
C
A
There
are
obviously
some
subtle,
odd.
You
know
less
known
instances
that
we
have
to
handle
right.
It's
like
how
much
resources,
how
much
time
should
we
spend
on
these
kind
of
more
exception
case,
ask
less
used
features.
We
I
think
it
might
be
in
our
best
interest
as
an
entire
team
to
push
back,
maybe
remove
some
of
that
stuff,
especially
as
we're
becoming
actual
owners
of
the
handbook.
Do
we
really
need
these
things?
Another
one
that
comes
to
mind
is
another
one
I'm
working
on
for.
A
Right
here
so
the
having
was
it
cold
bootstraps,
basically
like
special
icons,
I'm
spacing
the
name
right
now,
but
you
see
it's
just
a
little
rendered
square
but
like
basically
emoji
esque
kind
of
characters,
but
it's
actually
HTML
still
so
that's
another
kind
of
exception
case
people
I,
remember
in
kind
of
the
user
interviews
that
some
people
really
like
that
right,
because
one
of
the
kind
of
perceived
UX
problems
is
it's
so
mundane
just
having
text
text
text
text
text.
So
this
is
a
way
to
have
enable
contributors
to
have
this
level
of
visual.
A
C
One
that
I
see
is
implementation
of
collapsible
section
yes,
which
is
like
a
custom
JavaScript
thing
that
was
contributed
to
the
handbook
and
it's
not
really
something.
That's
that's.
You
know
official,
but
might
be
something
we
need
to
be
able
to
address
or
pull
out
like
if
we're
gonna,
standardize
on
something
and
and
say,
look
I'm.
Sorry,
we're
gonna
improve
the
UX
of
reading
to
the
point
where
that's
not
necessary,
but
for
now
we
need
to.
We
need
to
remove
that
custom
JavaScript,
because
it
doesn't
work
well,
yeah.
We.
A
The
second
part
of
that
was,
if
we
did
expect
these
types
of
things
to
render
and
they
require
JavaScript
right,
that's
a
whole
another
thing
we
have
to
kind
of
handle
and
again
that
goes
now
that
I
remember
when
just
showing
the
this
example
of
the
kind
of
icon,
it's
rendering
as
a
square,
because
we're
not
loading
certain
additional
stuff.
It
expects.
So
that's
that's
kind
of
related,
but
anyway,
I
totally
agree.
A
So
that's
kind
of
the
status
of
things
is
all
the
custom
renders
will
be
that
were
assigned
to
me
are
basically
going
to
be
done.
The
v2
of
the
HTML
is
going
to
be
like
the
big
one
that
identifiers
syntax
I
just
mentioned
is
you
know
there
might
have
solved,
but
anyway
it's
it'll
be
enough
of
a
iteration
one
spot.
A
B
So
last
week,
I
found
that
the
probably
the
best
path
forward
he's
a
to
make
the
site
accept
a
tour
consistent
when,
with
the
hand,
format
in
there,
they
markdown
syntax.
So
that
should
be
the
focus
for
this
week
and
probably
they
kept
coming
quick
modified
the
editor
to
adopt
doing
the
guidelines
of
the
of
the
handbook
markdown
guide.
B
Last
friday,
I
created,
I
embedded
an
issue
that
is
about
a
lot
exchanges
that
the
Toshio
acid
is
introduced
into
to
martin
documents
and
that
pretty
much
is
usually
been
consistencies
in
the
preferences
between
the
reset
ater
and
the
handbook.
So
the
works
of
solving
that
is
going
through
all
of
those
formatting
differences
and
making
them
consistent.
B
B
This
one
in
there
is
about
a
single
tax,
as
we
said,
one
that
we
were
talking
about
right,
that
you
that
you
addressed
and
they,
for
example,
that
we
found
was
a
Texas
caping.
That
was
that
it
was
breaking
the
Magnum
documents
so
yeah
we
should
use
address
all
of
those
points
and
then
we
can
continue
perform
adding
there
they
have,
but
with
a
success.
Ater.
A
Cool,
so
just
just
recap
there:
basically,
what
that
essentially
means
right
is
in
our
current
source
files
in
the
handbook
itself.
It
expects
one
syntax
and
when
it
gets
consumed
by
our
editor
once
it
goes
to
markdown
mode
or
maybe
even
before
it
converts
it
to
what
it
expects
correct.
That's
the
main
J
are
not
changing
the
we're
changing
toast
UI
to
work
for
our
source,
not
updating
our
source
to
match
what
toys
do.
I
expects
correct.
That's
right,
cool,
just
I,
just
want
to
make
that
super
clear
cool.
A
So
then
my
next
question
is:
do
you
know,
and
this
might
get
into
a
little
bit
of
technical
implementation
and
stuff?
Do
we
have
a
good
path
forward
for?
Is
there
a
certain
API?
Is
there
a
certain
hook
or
whatever
for
us
to
consume
this,
or
do
you
anticipate
this
being
a
hint
hacky
or
what's
your
expectation
about.
B
B
In
the
in
the
first
item
they
fixing
they
didn't
correct.
Texas
caping
I
made
some
research
to
understand
wat.
How
we
could
fix
that
and
I
found
that
we
could
tweak
the
day
engine
that
converts
HTML
into
markdown,
so
they
will
at
OC.
Why
it
works
is
that
there
are
two
waiters:
they
square,
a
turd.
That
is
a
rich
content,
editor
that
has
HTML
and
code
meter.
That
is
a
that
is
a
from
our
town.
B
So
when
tosya
I
conversed
HTML
to
markdown,
it
doesn't
remember
any
of
the
preferences
that
came
with
the
document
with
the
document
that
already
exists.
So
the
idea
is
that
we
can
find
ways
of
tweaking
that
HTML
to
mark
down
conversion
with
a
you
know
we
some
rappers
or
adaptors,
that
I
created.
So
the
B
is
AB
with
the
other
two
issues
about
checking,
listen
and
emphasis
on
a
boat
is
just
sustained.
They
were
that
that
I
started
there.
B
We
create
new
visitors
here
that
that
one
about
text
note
that
one
is
just
pretty
much
saying
hey.
If
you
find
a
text
note
do
this
and
that
to
compare
the
frictional
to
markdown,
we
need
to
create
one
for
the
least
notes
and
they
bought
on
the
analytics
to
compare
them
to
markdown.
You
know
follow
inner
preferences.
B
Very
important
is
that
I
was
thinking
that
now
we
are
trying
to
update
or
to
follow
they
and
books
back
down
guidelines,
but
since
this
is
a
product
that
it
should
work
for
for
everyone,
probably
we
should
find
a
way
of
doing
that.
Don't
version
of
of
passing
those
preferences
to
later,
like
you
know,
right
now,
little
videos
like
a
JavaScript,
probably
can
say
hey.
We
want
the
leads
to
have
some
spaces
and
and
use
this
polish
are,
but
then
eventually
we
want
to
scale
that
to
use
our
configuration
file.
A
Sure,
I
guess
that's
a
time
in.
Yes,
it's
all
in
one
one
location,
that's
what
I
wasn't
100%
sure
about.
So
it
sounds
like
you
anticipate
that
one
location
being
where
we
have
all
these
and
then
you
added
the
context
of
longer
term.
We
want
to
make
it
so
it's
configurable
and
we
can
pass
this.
This
information
in.
B
A
So
so
that's
great!
So
what
that
means
too
is
when
I
mentioned
earlier
about
the
v2
right
now,
hTML
is
going
to
convert
into
text
in
the
future.
We
could
leave
it
as
HTML
and
then,
where
you
had
that
text
note
at
all
caps,
we
could
obviously
have
HTML
block,
and
we
can
you
know
that's
where
we
can
filter
on
allowing
certain
HTML
through
or
certain
converting
into
text,
for
example,
or
something
like
that
so
cool
that
may
not
be
the
best
way,
but
that's
a
way.
I
guess
I'm.
C
I
just
want
to
say:
I
am
excited
and
I
agree
that
sooner
than
later,
we
should
try
and
find
a
way
to
to
pass
the
configuration
to
somewhere
where
a
user
can
and
tweak
that
I
think
that
is
consistent
with
the
long
term
vision.
I
can
see
a
future
where
we
have
in
the
config
yeah
mold
file,
just
a
bunch
of
properties
that
you
can
set,
or
even
some
preset.
You
know
configurations
that
set
a
bunch
of
things
at
once
or
being
able
to
override
the
entire
markdown.
C
Editor
I
mean
markdown
translator
just
to
to
HTML
converter,
just
to
provide
your
own
like.
If
you
wanted
to
write
a
custom,
one
be
able
to
pass
that
in
would
be
really
cool,
making
it
extensible
I'm
all
for
that,
and
if,
if
the
easiest
way
now
would
be
to
like
document
in
the
documentation,
a
JavaScript
block
that
you
could
pass
in
I'm
all
for
that.
But
it
doesn't
need
to
be
in
scope
for
this
particular
issue.
I'll
just
clarify
that
as
well
cool.
A
I
think
that
makes
sense,
Enrique
feel
free
to
add
something
here.
So
my
understanding
is
basically
toast
UI
by
default
uses
gfm,
which
is
github
flavored
markdown.
We
have
get
lab
flavored
markdown,
which
unfortunately
also
is
referred
to
as
gfm
as
I
understand
it.
So
that's
what's
been
kind
of
confusing
to
me,
which
is
the
initial
github
gfm,
but
with
you
know,
additional
extended.
Syntax,
basically
is
what
that
comes
down
to
so
probably,
and
I
could
be
wrong.
Right
is
my
assumption.
A
C
B
So
you
can
have,
for
example,
say:
hey,
my
preference
is
up,
every
bullet
chart
will
be
a
dash
and
that's
something
that
is
valid
in
the
github
flavored
markdown
or
in
the
kidnap
one.
So
it's
like.
That's
it.
That's
a
distinction
like
they
make
flavor
of
markdown
doesn't
dictate
the
formatting
preferences.
A
Thank
you
for
clarifying
that.
That's
a
great
point
totally
a
great
point
like
do
we
have.
We
don't
have
with
this.
I
mean
we're
kind
of
at
the
end
here,
but
I'm
curious.
Do
we
have?
Is
there
I?
Imagine
there's
a
document
of
exactly
what
those
are
right,
we're
not
reinventing
the
wheel.
So
it
sounds
like
it's
a
straightforward
problem
to
solve.
I,
don't
know
if
that's
true
or
not,
but
I
assume
that's
already
kind
of
documented,
and
then
people
can
just
choose
their
preferences
in
terms
of
the
rendering
of
of
that.
B
Yes,
I
made
the
documentation,
languid
happy,
they
have,
if
they
hand
books,
mark
damn
guy
and
we
are
gonna.
The
first
iteration
will
be
a
trick
and
a
tour
to
follow
top
guide.
You
know
with
the
vision
of
of
thinking
that
we
want
to
in
some
ways
create
some
open
doors
or
people
in
the
future
to
to
set
their
own
preferences.
Sure
cool.