►
From YouTube: Editor discussion - Content editor and context menus
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
All
right,
so
this
is
a
conversation
with
enrique
and
michael
of
the
editor
group
about
context
menus
relating
to
the
context
editor.
So
the
thing
that
sparked
this
whole
thing
up
was
this
first
issue
here
around
like
technical
analysis
of
the
context
menu
and
it
pertains
to
a
whole
bunch
of
stuff.
So
maybe
enrique,
if
you
want
to
verbalize
your
answer
here,.
B
Sure
so
I
created
a
technical
discovery
issue
with
the
purpose
of
understanding
how
we
can
implement
context
menus
in
the
in
the
content
editor.
What
what
drove
this
requirement
is
that,
on
this
medicine,
we
are
implementing
images,
support
for
inserting
images
and
for
rendering
tables
and
both
of
those
actions
along
with
links
require
a
special
special
actions
to
modi
to
modify
those
type
of
content.
B
For
example,
we
want
to
add
or
add
rows
on
a
table
or
or
remove
columns,
or
in
the
case
of
the
images
we
want
to
change
the
the
alternative
text
or
the
or
the
source
url.
B
So,
based
on
that,
we
notice
that
we
probably
need
a
generic
component,
a
generic
context,
menu
component,
that
we
can
customize
for
each
of
those
type
of
content,
and
that's
the
purpose
of
this
of
this
issue.
It's
like
coming
up
with
a
common
pattern
that
we
can
share
across
all
of
the
content
types
in
the
editor.
A
When
we
talk
about
the
block,
editor
menu,
we're
kind
of
thinking
of
what
you
might
see
when
you
press
the
backslash
in
issues
right
now,
and
you
have
like
quick
actions
or
a
notion
where,
if
you
click
on
the
plus
sign
you
get
this
like
giant
list
and
then
the
context
menu
is
are
like
the
menus
that
pop
up
rather
to
take
some
specific
action
on
the
text
or
the
link.
A
So
this
could
be
like
inserting
the
links
or
this
kind
of
idea
here,
where
you
have
like
pasting
the
url,
and
then
you
can
customize
it
to
have.
You
know
text
up
here
or,
like
anything
else,
we
want
to
do.
But
what
we're
kind
of
talking
about
today
is
kind
of
like
setting
the
foundations
or
the
generic
kind
of
like,
for
example,
for
this
would
be
like
the
pop-up
and
then
yeah,
depending
on
the
different
content
type.
We
can
fill
in
the
context
menu
with
whatever
things
in
there.
A
So
yeah,
so
I
think
that
covers
this
block
here.
So
I
think
I
I
agree
with
you
with
the
context
menu
in
the
block
menu
and
that
makes
sense
to
me
yeah.
A
The
next
question
I
had
was
like:
what
do
you
need
to
help
with
your
technical
analysis,
and
you
said
just
general
design,
product
expectations
of
how
the
menus
should
look
and
behave
yeah
in
the
spirit
of
iteration.
We
can
always
change
this
in
the
future,
but
kind
of
setting
that
foundation,
and
then
you
linked
off
to
this
issue,
which
is
creating
links
yep.
B
Yeah,
the
the
the
purpose
of
me
linking
to
that
issue
is
that
well,
it's
still
to
make
the
case
that
every
every
content
type
has
a
different
has
different
requirements
for
their
context
menus.
So
I
think
that
our
design
discussion,
our
design
conversation,
will
continue
as
we
work
on
specific
content
context
menus
for
those
type
of
content.
B
For
example,
we
need
to
to
understand
how
we
want
to
what
we
want
to
do
when
we
want
to
insert
anything
you
know
like
in
this
case,
I
I
shared
to
a
screenshot
of
two
very
different
approaches
between
certain
links,
one
in
notion
one
in
google
docs.
B
So
I
think
that
at
some
point
we
will
have
that
conversation
as
well
like
how
we
want
to
what
let's
say
like
pictures
or
we
want
to
provide
in
the
in
the
context
menu
for
for.
A
Links,
yeah
cool,
so
what
I
said
that
was
today,
I
was
taking
a
look
at
this
issue
here:
the
snippet
in
the
content,
editor
and.
A
A
So
this
is
like
the
wiki
page,
which
is
the
home
of
the
content
editor
right
now.
It
looks
like
that
we
aligned
on
the
backslash
for
quick
actions,
we'll
talk
about
we'll
across
that
bridge.
Once
we
clash
with
existing
quick
actions,
but
right
now
in
the
wiki,
I
think
we're
safe
to
just
live
on
our
own.
A
I
tried
to
use
things
that
exist
in
in
the
gitlab
ui
kit.
Here,
where
we
have
the
pop-up
and
some
kind
of
search.
I
think
the
search
could
either
be
at
the
bottom
or
at
the
top,
depending
on
like
where
the
screen
real
estate
is
and
all
that
stuff.
A
But
I
think
at
the
bottom
is
a
good
start,
and
this
is
where
so,
if
I
clicked
on
snippet,
it
would
open
up
this
screen,
and
I
think
this
is
kind
of
like
me
thinking
a
little
bit
about
the
foundation
of
how
these
com
these
blocks
get
added.
That
they'll
be
like
some
kind
of
gray
bit
where
it's
like
a
placeholder
for
that
spot,
and
then
you
do
some
action
here.
A
This
is
like
an
example
where
you
could
search
at
the
list
of
public
names.
Kind
of
like
your
your
example
with
the
google
docs,
inserting
a
link
to
something,
or
if
you
had
the
specific
url
to
snippet.
You
could
add
it
in
here.
A
A
B
A
A
B
Help
now
I'll
be
yeah,
we
have
a
bit
more
of
control.
Now,
over
the
selected
selected,
you
know
selected
content
in
general.
We
also
have
like
some
tools
from
tiptop
to
display
ui
elements
based
on
the
on
the
on
the
selection
context.
So
I
think
that
we
can,
you
know,
give
it
a
try
immediately
to
something
more
contextual.
That's
my
preference,
but
I
don't
know
you
know,
that's
even
the
right
thing.
A
I
think,
being
more
contextual
is
the
right
way
for
it
and
that's
the
whole
spirit
of
this,
where
we
one
day
that
this
thing
will
be
like
gone
right.
Like
pretend
like
that's
whether
we
go
that
far
like
I'm,
not
100
sure
yet
but
like
it
could
go
like.
A
Why
we're
operating
like
this,
and
we
have
these
things
close,
so
that
you
don't
need
to
jump
up
to
the
top
once
the
snippets
added
it's
added,
and
this
is
where
life
gets
kind
of
interesting.
A
We
could
do
something
with
tool
tips
or
we
could
just
leverage
the
triple
dots
to
like
show
like
deletion
or
changing
as
the
first
iteration,
always
just
happy
to
say
like
if
you
click
on
this
and
press
like
delete
or
backspace,
it
deletes
the
whole
thing.
That's
that's
also
pretty
common
behavior,
so
having
like
an
explicit
delete
button
is
not
really
necessary
and
day
one.
I
think,
having
like
the
kind
of
area
to
like.
A
To
like
hold
it
just
while
you're
edit,
while
you're
in
draft
mode
make
sense,
because
it
gives
you
kind
of
a
sense
of
where
the
thing
will
happen
yeah.
A
This
is
like
one
execution
that
I
was
playing
around
with
and
then
the
other
thing
that
I
was
playing
around
with
is
this
kind
of
contextual
menu,
where,
if
you
added
add
a
link
to
the
page,
then,
for
example,
if
it's
an
image
or
something
like
that,
perhaps
you
can
convert
that
into
like
a
image
block
or
a
snippet
block
or
and
that
kind
of
idea.
So
this
is
another
kind
of
contextual.
This
would
be
a
context,
menu
right,
specific
to
text,
but
yeah.
B
So
I
I
noticed
that
we
had
a
a
style
that
resembles
tooltips
in
one
example,
and
this
one
is
more,
it's
more
similar
to
drop
downs.
So
that's
why
yeah?
So
the
ambition
like
having
those
type
of
you
know
different
different
styles
of
different
styling
for
context
menus
like,
depending
on
the
on
the
type
of
action.
A
So,
for
example,
the
question
is
like:
should
the
pop-up
should
the
context
menu?
Have
these
icon
things
in
there
as
well?
A
B
Oh,
that
was
not
like
my
question,
it's
more
like
when
you
were
showing
the
example
that
the
ad
also
had
an
image.
I
think
that
it
was
like.
B
Yeah
yeah
this
guy.
Yes,
so
this
one
looks
very
different
from
from
the
other
menus.
Do
you
envision
like
having
these
different
types
based
on
their?
I
don't
know,
maybe
on
the
content
type
or
any
other
criteria.
A
Short
answer
is
I
I
did
this
to
kind
of
spark
conversation
and.
A
B
A
Our
current
state,
I
would
probably
say,
try
to
keep
things
as
consistent
as
possible
because
if
we
do
have
where
this
came
from
is
like
you
know
in
the
handbook,
when
you
select
over
text,
I
was
like
playing
around
with
that
idea.
It
doesn't
need
to
happen
like
that.
The
reason
that
I
did
try
with
the
tooltip
here
is
in
the
context
of
like
what
would
trigger
what
would
trigger
this
menu
here
right.
A
So
I
was
trying
to
figure
out
if,
like
this
thing
should
like
exist
on
the
side
or
like
in
it
or
somewhere.
So
I
think
this
stuff.
We
can
figure
out
the
finer
details
later,
but
yeah.
I
was
just
trying
to
figure
out
what
would
trigger
this
menu
right.
Is
it
clicking
on
the
area
itself
to
trigger
it?
It
might
work
when
the
thing
is
small,
but
if
it's
like
edge
to
edge
like
is
there
enough
hit
area?
A
Is
this
thing
really
like
an
interactable
snippet
in
this
state,
or
is
it
only
interactable
once
it's
once?
We
click
save
because
we're
currently
in
edit
mode
so
yeah?
This
is
why
I
think
this
is
really
good
to
have
this
type
of
conversation,
because
it's
really
hard
to
assess
this
one.
Now
from
just
looking
at
the
pictures
so
yeah,
I
would.
A
I
would
defer
to
your,
like
both
executions,
probably
to
me
make
sense.
I
feel
this
is
introducing
another
pattern
that
may
not
scale,
because
you
know
there's
more
actions
or
stuff
like
that.
It
may
not
hold
up
having
something
like
this
is
very
similar
to
like
how
notion
handles
their
like
list
of
actions.
A
B
You
know,
like
add
to
my
list
of
things
that
I
have
to
investigate
how
to
include
include
those
three
dot
buttons
in
in
complex
content.
Types
like
snippets.
B
A
Snippets,
I
think
we
can
hope
we
can
cross
that
bridge
near
in
the
future,
because
snippets
have
a
different
problem
as
well
that
they're
actually
a
script
in
the
iframe
and
our
editor
parses
that
out
anyway.
So
it
shows
like
nothing
to
the
preview
here
in
in
the
scenario,
so
we
need
to
cross
that
bridge.
A
What
might
be
more
interesting
or
like
equally
relevant
is
like.
How
would
you
do
this
for
an
image
that's
like
like
edge
to
edge?
Where,
like
would
you
click
on
like?
Maybe
that's
like
good,
because
at
the
same
time
it
should
be
foundational
right
like
it
should
be
consistent
across
object
types
so
like
the
button
to
edit
it
shouldn't
change
depending
on
the
content
type,
because
it's
a
block.
It's
almost
like
these
are
actions
you
can
do
to
the
this
magical
block.
A
B
Yeah,
I
can
imagine,
like
I
see
images
as
a
simpler
scenario,
because
in
the
case
like
we
have
we
don't
follow
the
the
pattern
of
just
selecting
the
image.
You
know
when
you
are
not
in
a
text
state
or
you
can
select
select.
B
Anything
like
the
concept
of
selection
applies
to
any
type
of
content
and
in
the
in
the
at
the
moment
that
you
like,
select
an
image,
and
you
are
not
selecting
any
other
content
that
you
are
not
selecting
text
an
image
at
the
same
time
or
link
an
image,
then
you
can
just
like
say.
Oh,
I
detected
an
image
in
this
selection
and
then
I
can
immediately
display
the
context.
A
A
Yeah
a
pattern
that
I've
seen
before
is
like
hovering
on
the
area.
Then
surfaces
this
like
other
menu,
only
on
hover
and
then
clicking
on
that
then
removes
it
or
you
can
even
have
this
always
persistent
and
then
it's
just
like
a
it's
like
a
layer
on
top
of
your
content
and
the
question.
A
It
could
also
be
like
something
at
the
bottom
here,
like
a
little
tab
or
some
kind
of
thing,
while
you're
in
edit
mode
that
you
can
hit
to
say
change
it
yeah.
I
think,
there's
many
different
patterns
that
we
could
do
here
and
that's
something
that
I
can
spend
some
time
to
just
like
investigate,
because
it
feels
like
we're
creating
like
these
nice
little
containers
and
if
we
just
solve
it
once
and
we
kind
of
have
one
pattern.
B
Investigating
as
well,
is
how
we
can
make
this
keyboard
friendly.
I
think
that's
one
of
the
points
that
you
have
that
you
made
into
documents.
Yes,.
A
A
This
is
this
is
a
interesting
question.
In
general,
like
I
thought
these
elements
in
in
google
docs
was
keyboard
accessible
but
they're.
Not
so
you
can't
really
tab
across.
So
if
I
tap
tab
tab,
I
get
here,
but
then
I
can't
go
through
the
toolbar
right
and
like
the
accessibility
pattern
for
keyboard
is
like
shortcuts
right,
like
commands.
B
A
So
I
think
using
this,
like
quick
actions,
is
a
is
one
good
way.
Then
yeah
the
command
k
is
a
good
one.
You
can
also
display
context
menu
where
shift
arrow
keys
and
yeah.
B
Yeah,
that's
exactly
what
I
was
talking
about
with
images
like
you
know,
you
can
press
shift
and
then
move
the
arrows
keys.
The
arrow
keys
to
select
select
something
indeed
or
it
can
be
text.
It
can
be
anything
so
when,
based
on
the
on
the
selected
content,
you
can
display
you
know
a
context
menu
that
is
only
relevant
to
that.
To
that
selected
context,
content.
B
The
only
parent
that
I
noticed
with
that
in
in
existing
heaters
is
that
that
context,
menu
on
itself
is
not
accessible
via
keyword.
You
know
keyboard.
A
Do
you
select
an
oh
yeah
so,
for
example,
right
now
I
have
the
context
menu
here.
I
selected
that
by
shift
arrowing
onto
the
image,
but
then
yeah
good
luck
getting
to
because
tap
just
moves
it,
but.
A
I
think
we
do
have
to
introduce
more
keyboard
shortcuts,
so
it's
it's,
then
we
have
a
lot
of
keyboard
shortcuts
within
github.
So
it's
probably
we
should
have
a
map
so
that
we
don't
we
don't
conflict
and
we
probably
should
just
use
what
people
are
used
to
like
command
and
like
control,
b
or
command
b.
To
do
bold
texts,
things
like
that
could
help.
I
think
our
heading
heading
with
markdown
is
pretty
good,
because
it's
we
support
that.
So,
if
you
use
double
hashes,
you
get
a
heading
two.
So
that's
already
implemented.
A
A
B
Yeah,
that's
something
that
that
we
should
be
careful
about.
Is
I
think
that
you
said
you
even
said
that
is
there
the
conflicting
keyword
shortcuts?
That's
something
that
we
are
dealing
with
now
with
the
with
the
circuit
of
pressing
command
post
return,
because
I'll
say
the
keyboard
shortcut
used
for
saving
content
in
the
wiki,
but
at
the
same
time,
in
the
content
territories
that
he
worked
for
inserting
a
heartbreak.
A
Okay,
that's
so
maybe
like
an
action
item
here,
would
be
like
just
to
map
out
all
the
keyboard
shortcuts
that
we
have
now
and
then
it's
like
cool
content,
editor
one.
So
it's
just
like
a
google
sheet
and
just
like
cool
conflict,
no
conflict
and
then
have
like
google
docs
or
like
word
ones
like
common
commands
for
them
and
see
where
they
contact
them,
where
they
don't
and
make
a
decision
from
there.
B
Anyway,
how
do
we-
I
I've,
been
thinking
this
week
also
that
we
don't
have
a
central
documentation
for
the
content
editor
where
we
document
those
keyword
shortcuts?
B
We
created
a
documentation
for
the
development
guidelines,
how
you
can
insert
how
you
can
use
a
container
in
other
pictures,
and
we
also
have
like
some
wiki
specific
documentation
about
the
content
editor.
But
we
don't
have
a
place
where
we
can
say,
let's
document
out
of
the
keyword
shortcuts
for
for
that
component
and
perhaps
something
that
we
should
do.
And
I
and
something
that
I
noticed
in
the
feedback
issue-
is
that
some
users
recommended
displaying
the
the
keyboard
shortcut
in
the
tooltip
for
the
toolbar
buttons.
B
A
Yeah,
I
have
an
issue
for
that
I'll
I'll,
follow
up
later
with
it,
because
that's
something
I
wanted
to
introduce
in
our
sidebars
menu,
because
we
already
have
keyboard
shortcuts
to
jump
to
like
issues
and
stuff
like
that,
and
it's
just
surfacing
them
throughout
the
whole
application
very
similar
to
like
how
slack
does
it
where,
if
you
hover
over
it-
and
you
can
see
like
this
yeah
there's
a.
A
There
kind
of
similarly
it's
like
onboarding
users
to
the
content.
Editor
is
something
that
we
spoke
about
very
briefly
like
in
the
product
and
design
chat.
So
far
we
haven't
talked
about
it
much
in
depth,
but
the
idea
is
like
there's
a
lot
of
features
that
we're
gonna
have
in
there
a
lot
of
block
editing.
A
So
the
way
that
we
could
think
about
if
the
things
that
we're
building
are
useful
to
people
is
not
only
looking
at
how
many
commits
that
they're
making
with
it
is
like
how
many
of
the
formatting
tools
that
they're,
using
how
many
different
elements
that
they're
using
to
express
their
thoughts.
So
it's
almost
it's
taking
that
idea
that
everyone
can
contribute
but
like
elevating
it
to
like
richer
content.
That's
why
we're
doing
this
so
that
you
can
express
different
things
so
that
will
help
fuel
future
work.
A
So
so
yeah
roughly,
I
think
we're
we're
pretty
much
on
the
same
page
on
context,
menu
and
block
editors.
In
my
view,
because
I
feel
like
we're
trying
to
just
follow
industry
norms
at
the
moment
and
and
stick
from
there
and
where
we
need
to
deviate
we'll
cross
that
bridge
when
we
need
to.
A
B
No,
I
just
wanna,
I
just
want
to
stay
in
touch
with
you
and
and
try
to
you
know
to
request
your
feedback
as
well
as
soon
as
I
have
something
that
is,
that
is
tesla.