►
From YouTube: Backdrop Design & UX - Feb 25th, 2021
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,
you're
live
today
is
thursday
february
25th,
and
this
is
our
fortnightly,
design
and
user
experience
meeting
tonight.
It
is
just
earth
today
this
morning,
depending
on
where
you
are
in
the
world,
is
just
myself
and
tim.
I
will
introduce
myself
first.
My
name
is
jan
lipton.
I
am
joining
from
oakland
california.
A
Noises
and
I
will
try
to
mute
when
I
can
but
tim,
would
you
like
to
introduce
yourself.
D
Sure
I'm
tim
from
deerwood
minnesota
otherwise
known
as
st
paul
tim
on
github
and
other
places
and
jen
saw
me
peeking
out
the
window
to
see.
If
there
was
anything
there.
I
could
talk
about
and
there's
none.
It's
a
really
boring
day.
It's
it's
gotten
warmer,
though
up
here
in
the
north
winds.
So
it's
above
freezing.
So
that's
warm
for
us,
given
the
late
yeah,
we'll
just
leave
it
at
that.
We
got
a
full
agenda.
A
D
The
intent
was
that
the
the
initiative
has
been
going
on
for
about
now
at
nine
months,
and
the
intent
is
that
we
were
looking
for
kind
of
what
the
endpoint
would
be
and
how
we
could
sort
of
wrap
up
this
state
at
least
this
stage
of
this
initiative,
and
we
walked
through
I'm
not
gonna,
go
into
detail
because
we
did
record
the
meeting,
so
anybody
who's
interested
can
go
back
and
watch
what
we
did.
D
Luke
did
a
summary
of
kind
of
what's
been
accomplished
so
far,
and
a
number
of
things
have
been,
I
think
part
of
our
the
issue.
With
that
initiative
was
it
started
to
get
sort
of
wandering
goals,
so
we
were
never
quite
sure
what
the
end
point
was,
and
the
outcome
of
that
meeting
I
would
say,
is
that
luke
feels
like
that.
Maybe
the
thing
to
do
is
sort
of
report
back
is
to
sort
of
bring
that
initiative
to
a
close
with
the
center.
D
With
a
report
on
what
we've
accomplished,
what
we've
learned
sort
of
recommendations
for
what
work
needs
to
be
done
and
then
regroup,
and
if
we
want
to
form
a
new
initiative
we
can
luke
certainly
has
expressed
some
interest
in
moving
on
and
working
on
other
things.
D
So
that's
where
that's
at,
if
you,
the
I'll
post
the
link
in
this
agenda,
but
it's
also
been
posted
in
zulu
to
the
recording
or
you
can
just
go
to
our
youtube
channel.
It's
there.
A
Great
I'm
getting
a
little
bit
of
an
echo,
I'm
not
sure
if
you
can
hear
that
or
not
tim,
I
don't
my
voice
or
my
computer,
it
might
be.
A
D
A
We'll
keep
an
error
in
it.
If
we
get
any
complaints,
we
can
worry
about
it.
Okay,
all
right
for
backdrop:
the
product
we
have
a
couple
of
usability
issues
that
we'd
like
to
talk
about.
One
of
them
is
the
issue
number
2353
to
move
the
clear
log
messages
button
to
the
bottom
of
the
dblog
messages
page.
A
This
is
one
that
we
talk
about
this
week
only
because
it
needs
to
be
escalated
to
the
project
management
committee
for
a
decision
on
what
to
do
next
with
that
issue.
If
anything,
peter
did
a
great
job
of
summarizing
the
issue
and
found
some
comparable
interfaces
in
core
that
we
can
use
as
a
comparison,
and
so
I
think,
we're
probably
a
good
place
where
that
can
be
written
up
in
the
pmcq.
Now
we
just
need
to
actually
do
it.
A
The
next
issue,
and
one
that
I
would
like
to
briefly
mention
this
week-
is
this
new
issue
that
was
reported
recently.
We
got
an
email
through
the.
A
I
think
the
contact
form
on
backdrops
vanessa
org,
where
somebody
who
uses
the
screen
reader
to
navigate
the
website,
reported
that
they
were
unable
to
move
blocks
on
the
manage
blocks
page,
and
I
think
this
is
something
that
we
knew
at
the
very
beginning
of
putting
in
the
layout
system
that
that
manage
block
page
was
going
to
be
hard
to
navigate
using
a
screen
reader,
because
we
don't
have
a
giant
table
that
you
can
just
slide
rows
or
up
and
down
in
which
is
what
we
were
replacing,
but
because
it's
a
visual
representation
of
the
page
trying
to
make
that
navigateable
via
keyboard
was
going
to
be
really
hard.
A
So
we
have
a
couple
of
solutions
that
will
make
it
possible
to
do
what
people
want
to
do
using
screen
readers,
including
adding
a
weight
option
and
a
region
option
on
the
blocked
configure
form.
But
we
also
wanted
to
see
if
we
could
change
the
manage
layouts
or
manage
blocks
page
to
accomplish
the
ability
to
move
things
around
and
doc.
Willmott
wrote
a
pull
request.
That
does
make
the
interface
navigable
using
your
arrow
keys,
but
it's
not
discoverable.
A
There
was
a
huge
flurry
of
movement
on
it
almost
immediately
after
it
was
opened
with
a
lot
of
help
from
indigozella,
dr
and
all
all
of
people
who
have
been
helping
us
with
feedback
too,
and
so
I
just
have
been
really
impressed
with
the
community's
response
to
that
problem
and
wanted
to
say
thank
you
to
everybody
on
that.
A
If
anyone
is
particularly
interested
in
usability,
focused
issues
for
backdrop,
cms
you're
welcome
to
search
our
issue
queue.
Every
issue
that
is
usability
focus
should
have
square
brackets
in
the
title,
with
the
letters
u
and
x
between
them,
and
that
should
indicate
that
that
issue
is
user
experience
issue
any
issue
that
is
tagged
as
user
experience
issue
with
that
pattern
in
the
title
can
get
into
any
bug
fix
release
if
it
gets
resolved.
So
those
are
not
waiting
for
future
releases.
A
We
have
a
few
design
focused
issues
too.
One
of
them
is
issue
number
4113,
which
is
better
defaults
for
page
layouts.
D
Yeah,
a
small
development
on
that
is
that
I
started
a
new
theme
called
opera
that
I'm
working
on
and
your
you
had
suggested
and
you've
made
a
few
suggestions
on
how
to
solve
that.
That
I
had
never
tried,
and
I
tried
one
of
them
in
my
new
theme
and
liked
it
not
quite
sure
what
the
implications
are
for
core.
We
could
talk
about
it
for
a
second,
and
it
was,
I
think
I
think,
you've
suggested
a
couple
of
different
things.
D
D
You
can
get
around
this
issue
once
you
turn
off
the
default
title
block,
that's
in
core
and
I
just
basically
move
that
block
on
our
templates,
but
a
lot
of
people
end
up
disabling
that
anyways,
because
once
you
create
your
own
title
block,
then
that's
no
longer
active.
So
again
in
my
you
know
in
my
overrides
once
you've
disabled
the
default
block,
you
have
the
same
options
that
you
would
have
had
anyways,
it's
just.
It
starts
out
in
a
different
place,
yeah,
and
so
I
don't,
I
think
at
some
point.
D
A
So
that
is
my
preferred
approach
for
all
of
the
sites
that
I
work
on
when
I
make
a
custom
theme
and
it
needs
to
have
there's
like
five
five
blocks
that
are
hard
coded
into
the
layout,
because
they're
really
important,
like
you,
can't
not
have
them
so
sort
of
as
a
fallback
position
and
that's
like
messages
tabs
the
title
and
like
local
actions
or
there's
some
some
other
things,
maybe
they're
all
included
in
the
in
the
maybe
I
don't
know,
maybe
there's
only
four,
but
there
there
are
a
couple
that
are
really
important
because
vector
wouldn't
work
if
you
didn't
have
them
and
for
most
of
my
custom
themes.
A
If,
if
those
have
to
go
somewhere
other
than
where
they
are
by
default
in
the
layouts,
then
I
move
them
into
themes,
and
I
find
that
makes
a
better
user
experience
on
the
layout
side,
because
I
usually
end
up
with
a
lot
of
blocks
in
my
layouts
and
so
not
having
to
worry
about
where
those
are
and
moving
stuff
around
them.
There
I
I
like,
but
it
does
present
a
problem
for
existing
sites
who
maybe
have
already
configured
their
layouts.
A
When
you
then
move
something
in
a
region
in
the
template,
it
is
going
to
affect
those
sites,
whereas
if
it
was
moved
in
configuration
it
would
not
affect
those
sites.
If
we
didn't
override
the
configuration
in
the
update,
so
there's
backwards
compatibility
consideration
involved,
which
is
yeah,
it
makes
it
makes
it
a
harder
decision
like
do
we
want
to
oh
and
then,
once
once
you
do
place
a
block
in
configuration,
you
can't
unplace
it.
A
You
can't
like
go
back
to
the
to
the
other
one
in
in
an
update
like
because
we
don't
know
whether
people
have
placed
another
block
or
not.
So
it's
like
whether
you're
changing
for
new
sites
only
or
existing
sites
too,
and
then
what
would
you
do
later?
If
you
change
your
mind,
so
I
definitely
think
that
for
two
backdrop,
two,
we
should
make
all
the
changes
in
the
template
files
where
we
want
them
so
that
we
don't
have
to
worry
about
the
block
ui
for
backdrop,
one.
A
The
question
is:
is
the
placement
of
these
blocks
important
enough
that
we
need
to
make
all
of
these
overrides
in
the
configuration
out
of
the
box
or
not?
And
the
breadcrumb
block
was
sensible
because
it's
already
placed
his
configuration
to
just
move
it
for
new
installs.
A
There
isn't
going
to
be
any
difference,
but
adding
a
title
block
will
disable
the
default
title
block
position,
adding
the
bread
crumb
or
the
messages
in
the
tabs
and
the
local
tasks
is
another
thing:
that's
more
complicated,
it's
something
that
most
people
don't
think
about,
and
they
just
sort
of
like
appear
on
the
page
and
then
later
on.
If
you're
like.
Oh,
I
don't
like
where
that
is.
You
have
the
opportunity
to
move
them,
but
I'm
not
sure
it's
something
we
need
to
put
on
everyone's
layout
out
of
the
box.
A
So
yeah
I
don't
it's.
Both
solutions
are
possible.
I
don't
really
know
which
one
is
better.
I
don't
know
which
one
is,
which
considerations
are
more
important
but
yeah.
I'm
glad
you
tried
the
the
theme
one
though
the
template
file
override
approach,
at
least.
D
Exactly-
and
I
feel
I
mean
it
was
kind
of
a
breakthrough
just
because
I
hadn't
done
that
before
and
now
having
done
it,
it
opens
up
other.
You
know
sort
of
gives
me
a
better
understanding.
A
D
D
I
understand
now
why
you're
reluctant
to
do
that,
because
you
know
this
is
a
better
long-term
solution,
but
it
doesn't
address
the
backward
compatibility
part.
So
you
know
my
thought.
You
know
again
my
I
have
a
pr.
I
think,
right
that
we've
looked
at,
that
that
moves.
Basically
what
it
does
is
it
just.
It
adds
a
title
block
and
gets
by
adding
a
title
block.
We
don't
use
the
existing
one,
I'm
not
sure
how
we
can
with
config
move
the
breadcrumbs
without
doing
that
in
config,
so
and
and
to
me
the
current.
D
The
default
way
that
backdrop
handles
the
title
is
actually
out
of
sync
with
what
I
think
the
new
backdrop
way
is
right.
I
mean
the
fact
that
the
title
is
available
as
a
block
is
like
a
really
cool
thing
to
me,
but
we're
not
using
it
as
a
block
out
of
the
box,
and
I
guess
your
argument
might
be
that
that's
what
people
are
used
to
coming
from
drupal.
But
to
me
it's
always
kind
of
puzzled.
Me
like
why.
If
we
have
a
block,
are
we
not
using
it
right
out
of
the
box
yeah.
A
My
issue
isn't
so
much
that
it's
not
coming
from
drupal.
It's
just
that.
It's
extra
work
that
shouldn't
be
necessary,
like
you
shouldn't,
have
to
think
about
where
your
title
is.
It
should
just
go
where
it's
supposed
to
go
and
it
should
go
where
it
is
on
every
page.
You
should
need
to
place
it
like
per
layout,
and
so,
if
your
theme
is
controlling
that,
then
it's
not
something
you
need
to
worry
about.
A
But
if
you
have
it
a
specific
use
case
where,
like
on
one
page,
you
needed
to
go
somewhere
different,
that's
a
good
place
for
your
layout
to
take
that
over.
So
it's
not
so
much
that,
like
I
agree,
it's
a
good
feature
and
I'm
glad
we
have
it
in
core
and
I
was
thrilled
when
duck
won't
figure
out
a
way
to
add
the
blocks
with
fallback
locations.
I
think
it
was
document,
but
it
seems
like
extra
work
that
shouldn't
be
necessary
for
every
site
to
have.
D
The
the
current
request,
the
current
poll,
request
that
what
it
does
is
it
adds
the
block
title
to
the
layout
in
install,
but
it
just
adds
it
to
basis.
So
I
think
I'm
pretty
sure.
C
D
A
The
block
is
your
title:
block
is
not
placed
as
a
block
in
configuration
out
of
the
box
yeah.
So
there's!
No.
If
you
change
the
theme,
it
goes
where
it's
supposed
to
go,
there's
only
work.
If
you
want
to
move
it
right
or
if
you
change
your
theme,
for
example,
right
now,
you're
overriding
your
theme
settings
with
your
layout.
If
you
have
anything
in
the
layout,
so
if
you
change
the
theme
you're
not
going
to
see
where
the
theme
wants
the
title
to
go,
you're
only
going
to
see
your
overrides
for
it.
Okay,.
D
Maybe
I
have
to
experiment
with
it.
I
mean
from
from
my
perspective,
unless
I
go,
try
it.
Maybe
then,
when
I
visualize
it
I'll
see
what
you're
talking
about.
But
for
me
it's
like
it's
in
a
default
position
and
unless
you
consciously
decide
to
move
it,
it's
just
there
for
all
of
your
layouts
for
all
of
your.
So
there
is
no
extra
work
unless
you're
going
to
move
it,
but
if
you're
going
to
move
it,
then
there's
going
to
be
extra
work,
anyways,
no
matter
how
we
do
it.
D
A
So
so
what
I'm
saying
is
that,
like
by
default,
if
you
don't
have
any
configuration
for
it,
the
title
goes
where
the
theme
wants
it
to
go,
and
so
in
basis.
It'll
put
it
in
one
place,
another
female
but
another
place
whatever
it
is,
and
only
when
you
have
one
page
that
requires
your
title
somewhere
different.
Do
you
need
to
do
anything
at
all?
A
But
if
you
place
that
title
on
every
single
layout
for
your
site,
you
and
you
change
your
theme.
You
now
have
to
like
unplace
it
for
every
single
layout
on
your
site,
or
you
need
to
unplace
it
for
every
page.
That's
not
that
one
page
you
want
it
overwritten,
so
it
just
it
creates
this,
and
part
of
this
is
related
to
the
fact
that
our
layouts
don't
like
inherit
from
the
default
layout
in
the
way
you
would
expect.
A
So
if
you
have
to
make
a
change
like
the
header
you
have
to
on
every
single
layout
out
of
the
box,
there's
only
like
three
of
them
or
something
two
of
them.
So
it's
not
so
much
work,
but
within
actual
productions
that
you
end
up
with.
I
don't
know
ten
of
them
or
something
then
there's
a
lot
of
work.
A
Every
time
you
place
a
block
somewhere,
you
have
to
do
it
consistently
across
ten
layouts,
and
so
every
time
you
add
another
block
like
a
title,
it's
now
10
extra
changes
that
you
need
to
make
in
order
to
you
know,
make
any
changes
to
the
title,
even
if
just
like
a
heading
tag
or
something
I
don't
know
a
class.
But
if
it's
in
the
theme
there's
zero
changes,
because
it's
already
placed
where
it's
supposed
to
be.
D
So
I
think
I'm
getting
closer
to
understanding
your
point.
If
you,
let
me
ask
one
more
question
and
then
we
don't
need
to
belabor
this
if,
right
now,
if
you're
going
to
move
the
the
the
title-
and
you
wanted
to
affect
all
of
your
layouts,
how
would
you
do
that?
A
Are
you
talking
about
doing
it
in
configuration?
Are
you
doing
it
in
the
theme.
A
So
if
I
have
a
custom
theme
and
my
site
is
using
like
a
moscone
flipped
layout
or
something
like
that-
and
I
want
that
block
title
to
be
moved
on
that
layout,
I'll,
move
I'll,
override
the
core
layout
and
put
it
into
my
theme
now.
If
I
wanted
to
work
on
all
layouts,
I
will
override
all
core
layouts
and
put
them
into
my
name,
but
for
most
part
my
my
theme
will
then
control
where
that
block
is-
and
I
don't
have
to
do
anything
in
configuration.
A
So
if
I
wanted
yeah,
I
don't
know
so
it's
it's
really
about
like.
If
you
don't
want
to
make
the
changes
to
your
theme
and
you
want
to
make
them
in
configuration,
there's
easier
and
there's
a
user
interface
for
that,
but
I'm
not
sure
that
that
is
a
better
way
to
solve
it,
because
it
also
clutters
the
user
interface
for
anything
else.
People
are
trying
to
do
there,
so
I
don't
know
I
mean
this
also
might
be
a
thing
that
you
know.
A
Maybe
we
just
need
to
have
more
people
weigh
in
on,
because
I
still
I
don't
know
I
don't.
I
don't
usually
give
my
editors
access
to
the
layout
ui,
so
a
lot
of
this
is
around
like
my
preference
for
managing
layouts
and
I
have
a
lot
of
layouts
and
I
get
really
complicated.
So
I
don't
want
to
have
like
title
configurations
on
there,
but
other
people
might
be
like
this
is
a
fantastic
tool.
We
need
to
have
it
everywhere,
but
yeah.
D
D
Okay,
let's
let's
move
on,
but
it
yeah.
I
don't
know
well
personally
to
me,
as
I've
mentioned
it
to
you
before
this.
I
was
the
one
who
was
sort
of
advocating
for
this
issue
for
a
while,
and
I
have
de
emphasized
it
because
I,
my
new
approach
is
just
him.
You
know
using
contrib
things
and
not
trying
to
solve
this
in
court.
So
until
I
mean
I
think
this
is
totally
solvable
into
2x
and
we
should.
A
D
But
I
don't
think
we
can
move
them
to
where
we
want
them
unless
we
mess
with
the
title,
at
least
until
you
show
me
how
that's
the
reason
I
moved
the
title.
The
only
reason
I
moved
the
title
in
that
poll
request.
I
was
fine
with
the
title
where
it
was,
but
I
didn't
know
how
to
get
the
breadcrumbs
where
I
wanted
them.
Unless
I
moved
the
title.
C
D
A
So
we
also
have
this
ongoing
issue
of
how
do
we
change
css
safely
in
within
the
one.x
milestone,
and
we
have
a
couple
of
different
approaches.
The
most
recent
one
is
currently
called
supplemental,
css,
selectors
and
issue
number
is
47.82,
and
this
issue
is
around
adding
body
classes.
A
A
D
A
Think
it
might
be
useful
at
this
point
to
file
an
initial
pull
request
that
uses
them,
because
talking
about
it
in
concept
is
not
as
good
for
most
people
as
looking
at
it
in
reality,
so
that
might
be
something
good
to
try.
I
think
we
have
a
couple
of
good
issues
that
are
slated
for
that.
The
one
with
the
space
around
the
hero
block
might
be
a
good
one,
which
would
be
a
fairly
simple
example
that
we
could
do
specifically
for
basis.
A
Oh
another
advantage
for
this
is
that
this
would
work
for
any
style
sheet
in
core,
where
supplemental
style
shields
were
trying
to
figure
out
whether
we
were
only
going
to
do
it
for
basis
or
whether
we
were
going
to
allow
like
modules
to
do
it.
This
could
work.
You
know
code
base
wide,
which
is
also
without
you
know,
100
extra
supplemental
style
sheets.
We
would
only
need
that
you
know
what
whatever
number
we
have
now
could
say.
D
So
the
point-
the
point
I
think
you're
just
making
which
hadn't
occurred
to
me,
is
that
this
is
really
a
policy
decision.
There's
not
a
there's,
not
a
code
change
just
for
this
issue,
really
what
we
would
do
is
we
would
take
another
issue
and
solve
it
with
the
solution
and
then
that's
where
the
debate
yeah.
A
A
Okay
and
then
I
think,
if
we
get
agreement
on
the
policy,
we
would
publicize
it,
maybe
even
send
it
to
pmc
for
approval
and
say
hey
we're
going
to
do
this
crazy
thing.
What
do
you
guys
think
and
if
we
can
do
something
that
we
can
improve,
doesn't
break
backwards,
compatibility
and
allows
us
to
add
incremental
design
and
style
improvements?
A
I
think
that
would
be
a
no-brainer
but
publicizing
how
we
do
that,
for
the
future
would
be
good
too.
So,
if
anyone's
working
on
a
pull
request,
that
requires
a
css
change.
They
know
how
to
introduce
it
safely.
A
D
A
I
think
what
I
would
do
is
I
would
probably
file
a
pull
request
for
this
issue
that
solves
the
other
problem
and
leave
it
like
experimental,
do
not
merge
or
something
so
that
we
can
keep
all
the
conversation
here
and
if
people
like
it,
then
we
can
re
name
the
branch
and
apply
it
to
the
other
issue
and
let
it
go
over
there
but
yeah.
It
is
a
process
question
like
maybe
we
just
solve
it
over
there,
but.
D
But
I
think
I
think
you,
your
last
idea
makes
sense,
okay,
so
about
just
filing
an
issue
but
using
the
current
discussion
and
attaching
it
to
that
for
now.
Yeah,
maybe
I
don't
know:
hey
gregory
hello,
having
a
small
intimate
meeting
today
no
worries,
but
we
were
working
through
the
agenda.
We
just
got
past
all
the
fun
stuff,
though.
B
A
That
could
also
raise
an
interesting
point
with
our
process,
where,
if
we
end
up
having
supplemental
css
sectors
that
had
only
once
a
year
just
had
this
thought
we
could
create
like
two
milestones
ahead.
So
we
always
have
a
year
worth
of
minor
release
milestones,
and
then
we
get
an
issue
that
has
a
solution
that
can
just
be
slotted
for
like
next
may
or
whenever
that
releases.
That
has
the
right.
I
think.
D
I
added
that
idea
just
in
the
last
week,
which
is
that
we
just
do
that.
We
only
do
them
once
a
year
or
something
because
I
think
a
big
objection
is
going
to
be
the
potential
for
a
lot
of
selectors
yeah,
the
other.
I
don't
know
if
you
saw
my
other
solution
and
this
might
be
a
really
bad
idea,
but
maybe
we
can
just
decide
that
real
quickly
and
head
off
debate,
which
is
that
we
just
have.
D
One,
oh,
oh,
that
we
just
insert
one
per
site
when
uninstall,
but
then
have
the
css,
so
I
have
multiple.
I
I
have
some
code
example
which
will
be
easier
than
me
trying
to
describe
it
in
the
issue.
I
think
this
would
also
work
and
it
it
actually
adds
more
like
characters
to
core
my
idea,
but
the
characters
are
in
the
css
files
instead
of
in
the
the
the
you
know,
the
markup,
so
it
leaves
prettier
markup
but
means
more
changes.
D
Yes,
okay
and
that
you
could
do
that
just
by
adding
each
year
adding
another
criteria
for
each
rule
right,
so
that
that
I
have
examples
again
in
the
issues.
So
I'm
doing
a
crappy
job
explaining
it.
But
if
you
look
at
the.
A
A
Yeah,
I
think
the
amount
of
work
burden
that
would
put
on
core
developers
makes
it
unlikely
to
be
effective
because
we're
going
to
forget
but
yeah.
I
also
am
not.
I
don't
particularly
care
about
the
prettiness
of
the
html
markup.
I
care
about
the
greenness
of
the
software.
There
are
probably
other
people
in
the
community
who
are
a
lot
more
concerned
about
what
the
markup
looks
like.
So
I
might
not
be
a
good
person
asked
by
that.
I'm
just
like
make
it
messy
and
make
it
easy
on
developers,
but.
D
I
threw
this
idea
in
the
mix
just
for
discussion
and
in
hopes
that
maybe
it
would
stimulate
another
idea
like
somebody
that
might
spring
some,
even
even
better
idea,
but
probably
I
mean
I
would
probably
vote
right
now
for
the
just
adding
them.
You
know
having
a
lot
of
years
or
a
market
a
lot
of
some
lectures
in
the
market
or
classes
adding
classes.
Sorry,
okay,.
B
D
D
D
A
A
A
We
could
do
that
if
we
needed
to
it
would
be
nice
to
have
a
consistent
pattern
from
the
beginning,
but
we
can
change
our
mind
later
if
we
need
to.
B
Yeah
we
can
clean
up
eventually
like
two
point:
whatever?
Can
you
remind
me
if
you
remember
what
was
the
the
argument
against
having
those
be
features
that
could
be
not
features
but
settings
that
could
be
enabled
or
disabled
on
the
theme
with
checkboxes
like
being
separate
files
or.
A
If
this
would
this
new
approach
would
be
core
wide,
it
wouldn't
be
limited
to
a
theme,
but
I
could
definitely
see
a
contrib
module
building
a
user
interface
that
would
be
like
do
you
want
to
include
css
fixes
from,
and
let
you
add
them-
I'm
not
sure
I'd
want
to
put
it
in
core,
though,
because
it
would
give
people
a
user
interface
that
might
allow
them
to
break
their
site,
which
I
generally
don't
like,
because
you
don't
know
if
whatever
they
have
built
before
they
added
that
tool
is
gonna
work
with
it
or
not.
A
Just
because
the
number
of
opportunities
to
make
things
that
don't
work
is
vast,
they
would
have
an
opportunity
to
uncheck
the
box
and
turn
it
off
if
everything
broke,
but
I
would
prefer
not
to
have
a
like.
Does
it
break
my
site
or
not
checkbox
in
core,
but
I
I
definitely
could
see
that
happening
in
trip,
and
I
envision
it.
If
we
build
something
like
this,
I
would
envision
it
happening
almost
immediately
that
someone
would
build
that.
D
B
D
Was
just
gonna
say
I
just
don't
see
a
need
for
it,
because
I
think
it's
a
really
rare
number
of
people
that
would
want
newer
style
sheets.
This
style
sheets
are
to
fix
things
for
future
sites.
My
assumption
is
that
older
sites
have
already
fixed
them
or
learned
to
live
with
them,
and
they
don't
they're,
not
looking
for
these
fixes.
So
to
me
there
might
be
some
people
who
want
to
do
that,
but
I
think
they're
going
to
be
very
small
and
they
could
fix
it
just
by
editing
their
their
config
file.
B
So
I
think
yeah.
I
think
that
that
was
that
idea
was
first
of
all,
we
would
add
a
timestamp
of
installation
for
his
site
somehow,
and
then
we
would
not
flood
the
settings
page
with
like
a
huge
amount
of
checkboxes
for
new
sites.
It
would
be
only
for
you
know
the
older
sites,
it's
kind
of
a
complicated
solution.
B
A
B
A
Right,
the
marker
for
the
classes
will
be
set
at
installation.
So,
like
it'll
say
you.
A
At
it'll,
be
like
backdrop
119
or
what
year
do
you
whatever
it?
Is
we
decide
and
then
it
when
your
page
template
is
being
rendered
or
your
html
template
it'll
say
what
year
were
you
installed
and
then
it'll
add
all
of
the
classes
that
should
come
before
that,
and
none
of
the
questions
that
you
come
after.
D
B
And
and
if
people
like
say
advanced
users
wanted
the
fix
that
we
included
and
they
wanted
those
classes
that
come
after,
they
would
have
a
way
to
say.
Yes
include
those
classes
right
or
move
the
marker
somewhere
move
the
marker
to
another
word.
D
E
A
A
D
B
Yes,
it's
just
that.
I
don't
want
to
be
steering
things,
but
you
know
that
I
kick
the
tires
afterwards
and
then
I
come
up
with
issues.
The
only
issue
is
that
yeah
we
can
have
a
separate
thing
which
is
a
timestamp
and
then
the
market
can
be
depending
on
that,
so
people
can
change
the
market,
but
not
the
installation,
time
stuff.
So
that's
a
solution
to
that.
A
D
D
A
A
B
Big
fat
warnings
of
yeah
least
that's
this
only
if
you
know
what
you're
doing
yeah
fair
enough
all
right
cool.
Let's,
let's
wrap
this
up
baby.
Okay,.