►
From YouTube: Backdrop Weekly - 2021/11/18
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
All
right
we
are
live
today
is
thursday
november
18th.
Well
in
some
parts
of
the
world,
this
thursday
november
18th.
This
is
our
fortnightly
design
meeting
and
before
we
get
into
anything
on
the
agenda,
we
should
probably
go
around
and
do
some
quick
introductions,
I'm
happy
to
start.
My
name
is
john
lampton,
I'm
joining
from
oakland
california,
where
it
does
starting
to
feel
a
little
bit
like
winter.
A
B
C
Yeah
hi
I'm
tim
in
deerwood,
minnesota
and
yeah
gosh.
I
don't
even
lots
of
things
going
on,
so,
let's
just
get
to
it
ben.
Are
you
ready
to
take
over
again.
A
Sure
so,
as
greg
mentioned,
we
have
added
the
issue
number
1040
for
inline
formair
to
the
agenda.
We
talked
about
that
a
little
bit
before
we
started
the
recording
it's
something
that
I
think
could
be
really
useful
for
backdrop
in
general
right
now.
If
you
have
a
problem
on
a
form,
there's
a
little
error
printed
at
the
very
top
of
the
page.
That
tells
you
what
the
problem
is,
but
it
doesn't
indicate
where,
on
the
form,
the
error
has
occurred,
some
form
elements.
A
We
will
get
a
nice
border
around
them,
so
you
can
tell
there's
a
problem
with
that
particular
element.
But
if
you
end
up
having
four
or
five
errors
on
the
form,
knowing
which
error
matches
to
which
element
can
be
a
little
problematic,
this
solution
is
something
that
had
been
implemented
in
triple
eight
and
carried
forward
to
triple
nine,
where
it
will
take
the
particular
error
and
put
it
directly
on
the
field
to
indicate
what
the
problem
is
and
how
to
fix
it,
which
is
nice.
A
There
are
a
bunch
of
issues
that
have
come
up
with
the
drupal
8
implementation
that
cause
some
forms
to
have
no
errors
and
some
forms
to
have
errors
that
appear
in
problematic
ways.
So
we
just
need
to
figure
out
if
we're
going
to
implement
the
same
type
of
solution.
If
we
want
to
try
and
mitigate
any
of
the
problems
that
we
know
came
up
in
the
tripoli
implementation.
A
Robert
was
here
earlier
when
we
talked
about
this,
and
he
mentioned
that
cbcrm
has
something
similar.
It's
not
a
drupal
8's
form
error
solution,
inline
form
error
solution,
it's
a
different
one,
using
it
html
or
even
javascript
library.
I
think.
A
C
A
Greg
you've
been
following
this
issue
more
closely
than
anyone
else.
I
don't
know
if
you
want
to
give
us
an
update.
B
Yeah
because
it
took
us
quite
a
while
sort
of
like
scheduling
what's
going
to
go
into
121,
I
started
working
on
actually
studying
on
not
working
on
a
pr
but
working
on
drafting
a
pr
or
working
on
my
local
to
start
doing
the
pr,
and
then
I
noticed
this
other
things
that
need
to
be
done,
like
some
accessibility
problems,
with
the
form
api
that
needed
to
be
sorted.
B
So
the
only
the
only
problem
that
I
was
aware
from
my
little
bit
of
resets
that
I've
done
with
the
d8
inline
forms
was
that
some
sometimes
when
you
submit
the
form
that
the
error
is
there,
but
you're
not
automatically
scrolled
to
the
portion
of
the
form
that
has
the
error
so
and
if
you're,
if
the
form
is
way
too
long
and
then
you're
at
the
bottom
of
the
form,
then
the
error
that
comes
up
is
outside
your
viewport.
B
The
pull
request
for
it
is
small.
I
still
need
to
sort
out
some
some
automated
tests
errors
and
fix
them,
but
the
the
problem
with
that
is
that
it
switches
into
the
native
the
native
error
messages
that
browsers
support.
So
I
have
a
two
screenshots
at
the
top
at
the
bottom
of
that
issue,
and
it
shows
basically
that
the
native
error
messages
take
over
and
they
do
not
allow
you
to
add
any
custom
error
message
to
say
what
is
the
expectation
like
you
get
the
bulk
please
fill
in
this
field.
B
Error
messages,
so
drupal
has
also
an
issue
for
that.
So
then
I
raised
issue
5348,
which
is
which
basically
will
allow
the
native
browser,
these
native
browser
errors
to
be
customized.
B
A
B
B
A
Yeah
we'd
have
to
run
that
by
a
quark
winner.
I
think
if
it's
gonna
need
tests,
it's
not
gonna
qualify
as
a
task
might
have
to
go
in,
but
that
doesn't
mean
this
and
the
inline
four
and
errors
can't
both
go
into
121.
C
B
Some
of
these
things
are
in
order
to
have
features
in
place
that
I
can
take
advantage
of
for
building
the
end
feature,
but
some
of
them
are
actually
blockers.
They
might
be
like
accessibility
issues
that
need
to
be
sorted
first,.
C
B
Long
as
it's
merged
yeah,
the
other
alternative
that
I
can
think
is
I
can,
I
can
add,
a
a
temporary
pull
request
in
the
1040
issue,
which
includes
all
these
changes
for
the
purposes
of
people
testing
it.
C
B
Well,
I
have
a
question
in
my
pull
request
in
one
of
my
progress
for
it,
the
the
changes
that
went
into
core
are
changing
a.
B
What
is
my
understanding
is
a
helper
function,
so
my
understanding
is
that
any
function
that
starts
with
an
underscore
is
sort
of
like
local
to
that
module,
and
if
we
change
it
we're
not
breaking
anything
most
likely.
So
my
question
is
like:
should
I
change
it
basically
rename
it
or
would
we
need
a
backwards
compatibility
wrapper
around
it?
A
Yeah
in
general,
I
think
it's
not
an
api
change,
we
don't
strictly
need
it.
If
it's
something
that
form
api
functions
use
frequently,
it
might
be
nice
to
add
a
backwards,
compatible
wrapper
function
with
a
deprecation
watchdog
notice.
Anyway,
I
know
we
ran
into
that
a
lot
with
drupal
7's,
like
number
element
number
validate,
integer
or
whatever,
where
we
don't
use
this
anymore
in
backdrop,
but
there
were
so
many
contrib
modules
that
use
those
because
they
had
number
fields.
A
It
might
still
be
valuable
to
provide
the
wrapper
functions,
but
you
don't
get
php
errors
and
then
also
the
watchdog
notice.
So
the
people
who
are
using
the
functions
have
a
really
easy
way
to
identify
and
fix
problems
with
them.
So
I
could
go
either
way
on
that
one.
I
would
say
it
depends
on
what
the
function
is
and.
A
B
So
yeah
I
provided
a
a
link
to
the
pull
request
with
the
question
as
I
have
it
there
yeah,
so
just
so
that
you
can
see
what
kind
of
change
it
is
and
we
can
just
leave
it
as
a
to-do
thing.
B
B
So
yeah
it's!
Oh,
it's
these
these
sorts
of
sort
of
like
tiny
issues,
not
necessarily
bugs
or
problems,
but
things
that
needing
cleanup
or
sorting
before
I
can
actually
work
on
the
on
the
inline
error
issue,
the
main
one,
the
main
pull
request
so
yeah.
D
I
guess
if
if
this
is
just
kind
of
quick,
open
discussion,
so
what's
your
guys's
thoughts
are
on
kind
of
an
idea.
I've
had
with
accessibility
seems
like
the
approach
that
we've
taken
with
accessibility.
Up
to
this
point
is
to
just
kind
of
hard
code-
accessibility,
stuff
here
and
there,
when
it's
needed.
D
What
would
be
the
thought
on
kind
of
modularizing
accessibility
in
such
a
way
that
it
kind
of
overrides
anything?
That's
done
elsewhere,
but
then
it
can
kind
of
be
extended
kind
of
make
it
its
own
piece.
That
is
almost,
I
guess,
a
module.
If
you
will
of
accessibility,
I
realize
most
of
accessibility
is
overriding
css
things
of
that
nature.
I
understand
that
there's
some
other
pieces
that
how
you
deal
with
form
fields
and
whatnot
tie
in
with
accessibility,
but
the
other
thought
is
also
to
have
a
switch
specifically
for
accessibility.
D
D
A
Trying
to
find
a
way
in
general,
our
approach
to
accessibility
is
that
if
there
is
something
in
backdrop
that
isn't
accessible
and
should
be,
we
should
just
do
it.
It
shouldn't
be
any
something.
Anyone
needs
to
often
opt
in
to,
because
excessive
accessibility
features
aren't
something
that,
like
some
people
will
need,
and
some
people
won't
need.
It's
like
everybody's,
going
to
need
that
at
some
point
in
their
life,
and
so
it
shouldn't
be
up
to
that
person
to
like
tell
the
website
they
need
the
feature
to
just
always
be
there.
A
That
said,
you
are
right
that
there
are
a
lot
of
things
on
any
given
site
that
can't
be
customized
to
make
a
site
more
accessible,
and
it's
really
hard
to
get
like
100
of
those
features
that
everyone's
going
to
need
on
every
site
and
core,
and
I
think
there
are
a
collection
of
accessibility
modules
that
exist
for
drupal.
I
don't
know
how
many
of
them
exist
for
backdrop.
That
would
give
you
more
control
over
specific
things.
A
That
would
make
your
site
more
accessible,
but
you're
right
that
most
of
those
things
that
change
are
things
that
get
changed
in
the
theme
there
are
things
like:
adding
attributes
like
adding
aria
roles
or
aria
labels,
or
even
things
like
contrast
right,
which
is
really
hard.
We
can
do
that
in
basis.
But
if
you
have
another
theme,
we
can
do
that
seven,
but
if
you're
using
a
different
admin
theme,
it's
just
hard
for
us
to
control.
A
In
general,
though
I
would
say
if
you
find
something
that
you
think
isn't
accessible
enough,
we
should
just
try
and
make
it
better
in
core,
and
if
people
want
to
change
the
way
that
that's
done
for
their
individual
site,
we
need
to
make
sure
that
there
are
tools
available
to
do
that,
whether
it's
a
module
or
something
they
can
override
in
their
theme
or
even
like
a
setting
like,
for
example,
the
search
form
now
has
like
a
setting
where
you
can
provide
your
own.
A
What's
that
called
the
placeholder
text
stuff
like
that,
we
could
add
where
we
thought
it
made
sense
to
do
so.
I
think
there's
also
an
issue
for
fuse
exposed
forms
to
something
similar.
So
there's
places
like
that,
where
we
can
add
settings
directly
in
core
that'll,
make
it
easier
for
people
to
make
things
more
accessible
to
people.
It's
hard
to
talk
about
in
general,
though,
because
there's
so
many
specific
examples
of
stuff.
A
So
I
would
say
if
you
have
a
you're,
probably
working
on
making
a
site
accessible
right
now-
and
you
probably
have
a
list,
I
would
say
it
would
be
really
beneficial
for
us
to
see
those
specific
items
and
what
we
can
do
to
make
each
one
of
those
better.
B
Two
okay,
two
points,
so
we
have
an
accessibility
so
like
specialist
in
the
company
that
I
work
for
and
because
they're
slacking
randomly
various
things
that
the
people
that
do
not
have
the
issues
that
were
not
aware
of
them.
They,
like
she
made
made
us
aware
of
things
like.
I
can't
remember
what
they
called
like:
accessibility,
widgets
or
plugins
browser
plugins
and
they're
horrible,
and
this
was
coming
from
a
person
that
needs
accessibility.
So
it
wasn't,
it
wasn't
from
a
developer
perspective,
saying
oh,
I
don't
want
to
implement.
B
This
is
a
person
that
actually
needs
to
use
accessibility,
features
saying
these
do
not
work,
they
make
things
worse.
So
I
don't
think
that
we
should
add
any
sad
solution
in
core.
We
could
leave
that
to
contribute
and
if
any
site
wants
to
go
for
a
very
you
know,
quick
solution
that
promises
to
solve
every
accessibility
issue
that
should
be
in
the
trip.
B
That's
one
thing
that
I
wanted
to
say,
and
the
other
thing
was
that
if
you
I'm
not
sure
when
you
joined
phil,
but
one
of
the
issues
that
I
was
mentioning
was
a
an
accessibility
issue
that
required
a
forum
api
change
to
accommodate
for
accessibility
in
the
future.
D
D
Part
of
building
that
form
field
is
to
call
on
the
accessibility
api
so
that
just
automatically
pulls
the
accessibility
related
issues
down
to
it
I
mean
I,
I
don't
know
the
coding
side
well
enough
to
know
if
that's
even
a
possibility,
which
is
kind
of
why
I'm
I'm
asking,
but
the
other
piece
of
it,
too,
is
on
the
front
end.
I
agree
that
core
should
do
as
much
as
possible
to
deal
with
accessibility
for
all
front-facing
themes.
D
My
my
thought,
though,
is
to
have
a
switch
for
the
development
side
of
the
theme,
maybe
a
future
theme
that
is
more
congruent
with
actual
site
management,
and
that
would
have
a
toggle
to
go
between.
You
know:
usability
versus
accessibility.
A
great
example
is
the
the
image
field.
When
you
have
the
title
field
and
the
the
alt
field
for
an
image,
one
stacks
on
top
of
the
other,
my
suggestion
was
to
put
what
each
one
of
those
was
and
as
a
placeholder,
to
reduce
space.
D
That
way,
you
know
if
you've
got
15
20
different
images.
It's
not
this
huge
list
that
you
have
to
scroll
through,
because
it's
all
filled
up
with
these
form
fields.
You
know
you
can
reduce
a
lot
of
pixels
by
putting
the
title
of
you
know
the
image
title
and
the
alt
title
inside
as
a
placeholder,
but
that
was
brought
up
as
we
can't
do
that
because
it's
accessibility.
D
So
it's
like
people
that
don't
need
the
accessibility,
they're
suffering,
because
now
they
have
to
deal
with
an
additional
10,
15
pixels
of
height
per
image
field,
whereas
you
know
the
accessibility,
people
they're,
it
doesn't
affect
them
at
all,
because
that's
what
we're
going
to.
A
Probably
the
problem
that
specific
problem,
though,
is
that
you're
saying
that
the
developers
who
are
building
the
sites
don't
need
the
features
that
they're
building,
which
is
not
the
point
like
the
point
with
the
like
that
the
alt
attribute.
That's
not
for
the
developer,
that's
for
every
other
human
being
who
visits
that
website
and.
D
A
A
It's
not
it's
not
like
that
interface.
We
can't
do
that
for
accessibility.
It
isn't
the
in
that
interfaces.
Accessibility!
It's
the
accessibility
of
the
website
that
we're
talking
about,
and
so
it's
like.
If
we
build
an
interface,
that's
easier
for
developers
to
use.
That
means
all
backdrop.
Websites
are
going
to
be
less
accessible.
A
I
mean
there's
other
ways
we
can
solve
those
problems
too.
Like
you
know,
default
values
are
good,
but
if
every
default
value
for
an
image
is
like
the
file
name,
that
doesn't
add
any
value,
as
an
alternate
text
like
humans
need
to
think
about,
like
what
is
in
this
image
and
describe
the
image.
A
Default
value
for
an
image
that
we
could
provide.
That
would
include
that.
That's
that
this
maybe
isn't
a
great
example,
because
I
know
that
there's
a
lot
of
other
stuff
that
you
mentioned
that
isn't
covered
by
this.
But
the
there
isn't
a
website
that
doesn't
need
accessibility,
features.
D
D
D
It
purely
was
about-
let's
save
pixels,
that
way,
folks
that
don't
need
the
screen
readers,
because
that's
apparently
the
issue
with
putting
placeholders
in
is
for
screen
readers,
so
those
of
the
the
those
of
us
that
don't
use
a
screen
reader.
We
can
save
those
save
that
space
and
visually.
It's
easier
us
for
for
us
to
understand
the
ui
right
now.
C
D
A
B
And
I
understand
where
you're
coming
for
like
the
first
bit
when
you
started
talking,
I
was
ready
to
agree
with
you
and
I
still
agree
with
what
you
said
in
the
first
bit
and
I'll
explain
what
I'm
saying
but,
but
how
you
put
it
like.
I
know
what
you're
saying
you
you
want
to
fix.
For
example,
I
think
a
thing
that
bothers
sighted
people,
but
then,
if
we
fix
it
that
way,
then
we
break
accessibility
for
non-sighted
people.
That's
what
you're
saying.
B
So,
if
I'm
a
sighted
person
at
this
point
as
jen
said
at
this
point,
because
you
don't
know,
what's
going
to
happen
in
the
future,
I
don't
need
it,
and
I
was
looking
for
ways
this
for
for
browser
detection
to
see.
If
what
is
that
is
accessing
the
page
is
actually
a
a
screen.
Reader
or
a
an
accessibility
enabled
browser
like
if
it's
a
person
that
is
actually
doing
that.
A
A
I
think
we
might
need
to
talk
about
this
thing
like
as
a
specific
example,
though
too,
because
I
can't
imagine
a
change
that
would
benefit
sighted
people
that
wouldn't
that
would
negatively
affect
unsighted
people
like
if
it's
something
like
placeholder
text
or
default
value
text
like
that
benefits
everyone
and
it
doesn't
save
pixels.
So
I
think
I
might
not
know
exactly
what
we're
talking
about
here
it
could.
I
think
it
might
be
more
useful,
look
at
this
specific
problem
too.
So
imagine
imagine.
B
A
page
with
hundreds
of
images
and
fields
that
have
a
label,
so
what
phil
suggested
is
that
I
have
hundreds
of
these.
So
if
I
hide
the
labels
move
the
labels,
sorry
from
being
a
separate
thing
into
the
field
as
a
placeholder,
then
I
reduce
the
length
of
the
page.
So
sighted
people
don't
have
to
scroll
as
much
right.
Yes,
you
benefit
inside
the
people
that
way
in
this
specific
scenario,
but
then
using
placeholders
placeholder
text
breaks
accessibility
for
people
that
need
it.
So
that's
the
issue
there.
D
Yes,
I'm
not
trying
to
advocate
one
way
or
another,
I'm
just
trying
to
bring
up
a
little
bit
of
discussion
around
this
I've
kind
of
wondered
myself
for
a
while.
Is
it
worth
trying
to
just
cram
everything
to
literally
fit
everybody,
or
is
it
worth
going?
Okay.
Eighty
percent
of
people
do
not
need
these
accessibility
features.
D
B
B
I
think
that
the
disagreement
there
is
that
I
agree
with
zen,
because
it's
a
philosophical
thing
as
in
a
philosophy,
not
not
a
theoretical
like
right.
It's
a
philosophy,
thing
that
we
should
have
accessibility,
always
for
everybody
at
all
times,
and
I
know
where,
where
phil
is
coming
from,
which
is
like,
I
personally
don't
need
it
so,
and
I
think
that
most
people
don't
need
it
right.
Now,
I
don't.
I
want
to
have
the
option
yeah.
I
know
what
you're
saying
right,
but
it
makes
harder
things
harder
for
people.
I.
A
D
D
I
know
I'm
going
to
be
a
little
bit
harsh
in
saying
this,
but
you
know
the
so
backdrop
doesn't
want
to.
They
want
to
do
things
for
the
80
of
of
users,
but
when
it
comes
to
accessibility,
it's
kind
of
things
where
it's
like
well
we're
going
to
ignore
the
80
and
cater
to
the
20
and.
A
I
realized,
because
whenever
you're
making
up
isn't
real
100
of
people
are
going
to
need
accessibility
features
at
some
point
in
their
life.
It's
just
a
matter
of
like
you
know
we're
not
all
going
to
be
blind,
but
we
are
all
going
to
need
to
like
be
able
to
tab
through
form
fields
in
the
right
order.
Right
like
like
that,
what
accessibility
is
is
very
different
than
I
think.
Just
sighted
versus
unsighted,
like
there
are
people
with
like
cognition
problems.
A
There
are
people
with
mobility
problems
or
people
with
like
can't
use
their
hands
or
people
who
can't
use
their
it's
just
all
over
the
map,
and
so
these
features
cover.
All
of
that,
and
you
can't
just
sort
of
like
pick
and
choose
and
be
like
this
one
page
we're
going
to
not
use
this
one
feature
for
this.
One
type
of
issue.
D
Right,
I'm
not
trying
to
say
that
at
all.
So
if
you
look
at
windows,
you
look
at
apple,
you
look
at
ios,
you
look
at
android.
They
all
have
built-in
accessibility
features
that
are
an
opt-in.
You
turn
them
on.
They
are
not
pushed
on
every
single
person
that
uses
their
stuff
now
granted.
You
know
they
are
doing
some
things
under
the
hood
to
kind
of
cater
to
a
handful
of
those
people
that
are
in
between.
But
for
the
most
part
it
is
an
opt-in
option
because
they.
A
Integrate
that's
how
our
stuff
is
too
right,
like
every
browser
or
operating
system.
You
can
turn
on
the
ability
to
use
the
accessibility
features,
but
if
we
don't
even
put
it
there,
then
if
someone
turns
on
that
accessibility
feature
and
we
give
them
nothing
like
it's,
it's
not
it's
not
often
on
backdrop
side,
it's
often
a
different
level
and
that
we
either
provide
the
future.
We
don't.
D
Okay,
I
guess
where
I'm
coming
from
then
is
to
separate
it
from
a
visual
versus
non-visual
to
have
have
have
things
set
up
from
a
visual
versus
non-visual
standpoint
is,
is
I
agree?
I
mean
we
need
to
have
all
the
accessibility
for
screen
readers
stuff
built
in
on
on
the
core
side
of
things,
but
at
the
same
time,
there's
there's
times
when
visual
people
need
to
be
displayed,
something
different
than
non-visual
people.
A
C
It's
very
confusing,
because
are
you
talking
just
about
the
developer,
because
how
how
is
an
end
user
going
to
make
this
choice
an
end
user
can't
toggle
something
on
the
site
exactly
to
turn
on
or
off
accessibility?
That's
not
possible,
so
you
either
provide
so
you
so
phil!
You
must
be
talking
just
about
the
developer
right
that
you
just
want
the
developer
to
be
able
to
turn
these
things
off
for
themselves,
if
they're
turning
it
off
for
themselves,
they're,
not
providing
it
that
it's
not
available
to
their
users.
B
I
think
I
think
it's
one
key
difference.
One
key
difference
that
I
understand
what
phil
is
saying
that
one
key
difference
is
the
person
that
is
using
there's
a
single
person
that
is
using
the
computer
that
turns
off
the
the
on
off
things.
So
you
shouldn't
be
comparing
it
with
a
website
which
is
accessed
by
in
theory
thousands
of
people
at
the
same
time.
C
A
Yeah
I
mean
there
is
like
you
know:
people
have
the
option
now
of
like
choosing
a
dark
mode
for
their
theme
right
like
if
they
want
so
I
could
see
someone
could
create
a
can
drip
module.
That
would
have
like
a
big
button
on
the
top
of
your
website.
A
That
would
say
like
make
my
website
accessible,
and
it
would
turn
on
all
of
the
features
in
backdrop
core
that
make
things
accessible,
but
that
would
be
very
bad
move
for
corridor
support,
because
that
would
mean
that
100
of
the
time
we
would
be
helping
no
one,
and
only
if
you
turned
that
on.
But
if
you
wanted
to
install
the
module
where
you'd
say:
hey,
I'm
making
a
decision
where
my
website
is
definitely
not
going
to
be
accessible.
A
Unless
someone
who
needs
to
push
this
button
can
find
the
button
and
can
push
the
button
can
turn
it
on.
But
I
think
that's
not
something
that
we
should
consider
in
doing
in
in
core,
and
it
is
possible
that
there
are
websites
that
are
like
private
only
used
by
one
person
only
viewed
by
one
person.
You
know
only
edited
by
one
person
and
in
that
case,
if
that
person
says
you
know
I
might
get
hit
by
a
bus
next
week
and
not
be
able
to
turn
on
this
button.
A
But
for
today
I
don't
want
the
stuff
on
my
website
and
that's
totally
fine.
They
can.
They
could
can
make
that
decision,
but
I
don't
think
that
we
should
be
making
that
decision.
On
behalf
of.
D
Part
of
where
I'm
coming
from
on
this
is,
you
know,
logged
in
you
authenticated,
yes,
there's
there's
a
distinction
between
authenticated
non
non-authenticated,
non-authenticated
yeah
coordinates
just
flat
out,
handle
everything
from
a
non-authenticated
standpoint.
That
way
anything
that
gets
put
down
is
going
to
be
accessible
right.
So
then
you
have
the
authenticated
side
and
you
have
two
different
groups
on
the
authenticated
side.
D
What
I
would
like
to
see
happen
is
a
new
admin
theme
created
that
it's
a
little
bit
more
like
wordpress.
I
would
love
to
see
it
designed
around
a
better
javascript
framework.
I
don't
know
what
that's
going
to
be,
and
I
realize
that
there's
not
a
lot
of
strong
folks
in
the
community
right
now
that
could
pull
that
off,
but
the
admin
side
of
drupal
drupal
7,
even
drupal
8,
it's
not
until
they're.
D
A
A
Definitely
could
happen
and
if
someone
wants
to
build
that
theme
and
contrib,
that's
totally
fine,
I
have
zero
desire
to
make
core
less
accessible
for
anyone.
I
think
that's
a
terrible
idea.
However,
if
you
wanted
to
put
an
admin
theme
on
your
site
that
had
that
feature,
I
think
that's
totally
fine.
C
D
Just
kind
of
think
about
it
think
about
options
or
or
ways
that
you
know
we
might
be
able
to
make
to
me.
It's
there's
things
from
an
accessibility
standpoint
that
are
being
implemented
and
pushed
on
people
that
don't
need
accessibility,
and
it's
frustrating
that
you
know
those
of
us
that
don't
need
those
features
right
now
or
we
have
to
deal
with
it.
We
have
to
tweak
those
things
on
our
end
now
and
anyway,
all
right.
Let's
go
ahead
and
switch
over
I'm
good.