►
From YouTube: yui open roundtable 1/17/2013
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
B
B
D
E
B
B
So
I
think
the
objective
of
what
I'm
talking
about
is:
should
we
bring
normalized
into
core,
and
if
we
do,
then
what
do
we
tell
people
who
are
using
CSS
reset
base
bonds
etc?
So
I
did
a
very
quick
call,
not
very
scientific
at
all
this
morning
on
IRC
and
what
I
got
from
that
is
that
there
are
a
bunch
of
people
who
are
using
reset
without
using
base
because
they
want
to
reset
a
lot
of
a
lot
of
the
styles,
but
they
don't
really
want
to
inherit
anything.
B
B
I
think
they
solve
different
use
cases,
so
I
didn't
really
look
too
much
into
this
I
think
CSS
reset
should
remain
for
for
what
it's
doing,
which
is
resetting
any
CSS
stuff
on
the
more
important
and
interesting
thing
for
me,
is
what
we're
doing
in
CSS
base
and
how
normalised
works
there.
So
I
just
look
through
what's
in
CSS
base
right
now
and
also
what's
in
normalized,
one
point
X
where
they
have
right
now
and
I.
Think
the
key
difference
here
is
that
normalized
is
more
than
just
add
bass.
B
Styles,
it
actually
does
normalization
of
browser.
Inconsistencies
and
I
have
listed
a
couple
of
these
here
that
they're,
probably
you
probably
more
useful
if
you
can
go
through
and
look
at
the
CSS
explicitly,
but
the
CSS
base
kind
of
just
does
basic
margins,
wits,
paddings,
etc,
and
there's
really
not
much.
There
is
pretty
small
normalizes,
definitely
bigger.
It
adds
styling
for
things
that
don't
exist
in
older
browsers,
more
quotes.
It
adds
a
lot
of
readability
stuff,
it's
very
good
when
it
comes
to
forms
form
controls.
B
B
It's
kind
of
hard
to
just
go
go
through
it
here
with
instead
of
going
through
the
code,
but
this
was
more
for
me
for
brain
dump
to
just
compare
the
two
straight
up
to
see
what
what
what's
going
on
so
my
I'll
get
everyone
else's
thoughts
on
this,
but
having
gone
through.
This
I
definitely
think.
There's
a
use
case
here,
because
normal
s
is
solving
something
that
we
don't
have
in
library
right
now,
which
is
these
browser
inconsistencies,
as
opposed
to
just
base
styles,
that
CSS
basis
providing
right
now.
B
Having
said
that,
I
think
it's
too
early
right
to
just
say
we
should
deprecated
deprecated
CSS
base
or
CSS
reset
and
bring
normalize
in
just
as
just
as
a
straight-up
replacement,
I
think
all
three
of
them
are
solving
slightly
different
use
cases.
So
my
I
think
my
understanding
from
what
I,
what
I've
kind
of
from
what
I've
gone
through
is.
We
can
bring
normalize
into
the
library.
B
I
actually
explicitly
depend
on
normalize,
especially
for
CSS
form,
because
normalize
has
loved
the
form
stuff
in
there.
So
I
just
wanted
to
get
everyone's
taught
so
on
for
future.
Css
modules
that'll
be
coming
down
in
core
of
which
there
are
gonna
be
quite
a
few,
should
I
depend
on
normalize
for
that
stuff,
so
yeah
I
just
wanted
to
open
up
the
floor
for
a
discussion
for
that.
Do.
B
C
B
B
C
The
the
thoughts
like
the
bolts
you
have
there
as
you're
going
through
them.
Basically
that's
what
I
was
nodding,
my
head,
agreeing
that
that
seemed
like
a
good
path,
the
especially
the
idea
that
we
can
determine
if
normalize
essentially
replaces
the
need
for
base
and
when
someone's,
like.
Oh
I,
want
bae
styles
and
we
say:
okay,
you
snore
Mille
eyes
and
when
someone
says
oh
I
just
want
a
blank
slate
and
we
say
okay
use
reset,
but
one
thing
we
say
plus
base
you.
B
Think
that's
I
think
if
we
have
normalized
that's
what
we
should
we
should
excel
or
we
should.
That
was
my
goal
like
if
you,
if
you're,
if
you're
doing
reset
buss
base
right
now
I'll
look
into
the
k
way,
but
assuming
that
the
k
weight
is,
I
think,
smaller
in
normalized,
then
we
should
say
why?
Don't
you
just
go
for
this
because
you
got
the
added
benefit
of
these
normalization.
F
B
F
F
A
C
C
B
B
B
Given
that,
if
we,
if
we
assume,
if
we
think
that
people
aren't
using
a
base
by
itself,
then
it
makes
sense
to
just
forget
base,
because
when,
if
film
was
using
base
with
reset
we'll
just
say,
okay,
why
don't
just
use
normalize
instead,
no
one's
using
base
by
itself?
If
they
are,
they
can
use
based
deprecated
um-hm.
F
F
B
F
B
F
G
F
F
E
F
C
B
B
A
F
B
That
was
my
other
idea
to
do
that.
So
that's
I
think
that
that's
the
only
that's
the
other
option
on
the
table.
The
other
thing
is
freedom
of
this
for
the
CSS
stuff,
explicitly
for
the
CSS
CSS
stuff
that
we
want
to
get
packaged,
call
a
bootstrap.
Maybe
that
stuff
does
have
some
dependencies
I'm,
not
sure,
because
if.
B
C
We
have
like
two
versions
of
this
one
that
will
scope
the
normalizing
styles
from
normalized
like
the
form
stuff,
the
our
CSS
forms
module.
We
can
have
one
version
which
includes
under
our
under
some
class
name,
that
we
use
all
those
normalizing
Styles
plus
what
we
build
on
top
of
there
and
then
a
smaller
version
of
that
which
says:
hey,
I
already
have
normalized
on
the
page.
Just
apply
the
form
styles,
because
I'm
already
using
normalized,
so
don't
try
to
reapply
them
with.
C
F
C
F
F
C
B
A
F
You
know
I
think
base
is
okay
to
not
be
prefixed
and
for
the
use
case
of
normalized
replacing
base
I,
don't
think
we
care
about
the
prefixing.
It's
really
when
one
another.
One
of
our
components
wants
to
depend
on
normalize
and
pulls
that
in
clobbers
existing
styling,
it's
just
impulsive.
It
resets.
F
I
F
Area
is
how
do
we
depend
on
that?
The
higher
level,
unless
they
normalize,
is
so
small
that
I
don't
think.
We
need
to
worry
too
much
about
answering
that
question,
but
at
the
same
time,
isn't
this
already
helping
with
basis
of
this
deprivation.
You
don't
have
dependencies
that
I
know
of
in
general.
Most
we
keep
our
widgets
and
components
with
with
views
font
and
reset
and
base
diagnostics
they
just
inherit
from
whatever
I
get
dropped
into.
So
we
could.
B
I
F
J
Slide
right,
it's
like
slowly
in
a
minimum
I
think
we
can
probably
all
agree
to
the
regardless
of
what
happens
with
normalized,
keep
CSS
preset,
because
I
think
there's
definitely
value
there
and
then
in
a
minimum
normalizing
the
gallery.
If
we
can
get
around
the
licensing
restrictions
with
it,
then
we
can
figure
out
how
far
we
want
to
go
with
normalize
and
play
around
with
it
and
use
it
with
some
components.
Yeah,
that's
participation.
J
B
F
F
B
F
We
can
also
think
about
media's
part
of
the
skinning
build
step,
potentially
how
did
share
and
repackage
normalize
that
way.
So
we
have
to
worry
so
much
about
chopping
it
up
and
sprinkling
this
bit
in
button
in
this
bit
in
form,
etc,
at
least
as
a
manual
process,
but
I
think
that's.
That
would
be
a
little
bit
more
of
a
medium
term
thing
I
think
in
the
short
term,
doing
what
you
were
talking
about
just
cherry
picking.
Styles
is
fine.
Well,.
B
H
B
C
J
A
B
The
whole
quants
concept
was
that
there
would
be
things
depending
on
it
for
some
of
the
CSS
stuff
that
we're
working
on
and
for
some
of
the
CSS
stuff.
There's
things
like
normalize.
Actually,
that
has
like
a
pretty
decent
minimal,
like
typography,
set
that
we
could
like
use
first,
one
for
CSS
stuff,
so
we
were
gonna
have
when
we,
if,
when
we
do
package
without
CSF
stuff
together
normal,
this
was
going
to
be
a
feature
of
that
saying
that
this.
F
C
There
but
there's
the
whole
thing
is
like
when,
in
our
in
our
thing
where
we
show
like.
Oh,
let's
use,
CSS
forms.
This
is
how
you
do
it.
It
makes
sense
that
the
best
presentation
of
that
is
to
say
first
use
our
normalize
or
use
normalize.
Css
then
include
the
form
CSS
and
that,
like
I,
don't
know
it
just
seems
if
forms
is
going
to
be
in
there
that
normalizes,
even
a
lower
level
while
or
what
I
should
really
be
in
there.
We.
C
C
F
B
F
A
G
B
Can
we
can
take
the
form
stuff?
The
CSS
form
store
doesn't
have
to
explicitly
depend
on
normalize.
We
can
say
we
can.
We
can
keep
normalized
similar
to
what
people
are
doing
with
base
right
now,
which
is
if
they
want
bathe.
They
just
pull
it
down
directly
for
the
CSS
form.
So
we
can
just
take
that
stuff
and
put
it
right
into
the
CSS
for
CSS
from
normalize,
so
that
way
won't
destroy
your
page.
C
F
G
G
Right,
so
the
only
ones
that
we
have
dependencies
on
is
grids,
which
is
that
that's
my
whole
point
as
long
as
we
make
sure
that
there's
a
distinction
that
we
do
not
allow
our
widgets
to
require
normalize
for
something
yeah
that
that's
my
my
biggest
thing
is
it
has
to
be.
It
has
to
be
nice,
though
they
are
mostly.
F
J
F
F
C
G
B
G
B
G
C
C
F
It's
the
destructive
nature
of
the
skyline
if
we
have
forms
and
tables
that
rely
on
Yui
prefixing
that
we
can
depend
on
those
in
other
modules
without
having
to
worry
about
depending
on
Ron
alliance.
So
if
you
want
to
go,
find
a
prefix
versions
of
your
boys,
that's
all
of
all
the
problems
go
just
say
you
have
to
change
it.
We
know
basically
be
our
CSS
forms
and
tables
and
whatnot
component
thinking,
I
Yvonne,
that
but.
B
Vs,
not
prefixed,
normalize,
not
putting
it
in
anywhere
and
then
I'm,
not
putting
it
into
core
and
then
taking
bits
and
pieces
of
it
whenever
we
need
to
use
it.
I
would
already
would
argue
that,
based
on
our
convention
of
with
just
with
how
the
skinning
works,
that
I
would
be
okay
with
the
prefix
normalize,
so
it
would.
C
C
K
C
Then,
if
forms
essentially
just
adds
to
that
prefix
or
something
so
that,
if
you
included
four
arms
or
see
our
CSS
forms,
it
would
use
the
same
prefix
that
normalized
styles
are
prefixed
and
then
just
essentially
add
to
that
add
to
those
rules.
Instead
of
having
to
tag
your
elements
with
all
these
class
names,
yeah.
F
I
mean
it's
starting
to
sound
like
the
context
versions
of
reset
and
base
that
we
have
today,
which
are
I
only
want
to
set
this
portion
of
the
page
or
I
only
my
face
to
apply
to
anything
inside
this
container
and
so
for
those
its
key
off
of
a
top
level
class
name.
There
were
safe,
and
so
that
seems
like
the
right
way
to
do
it
for
normalize.
F
C
F
That
make
sense.
So
if
that's
the
case,
then
we
would
basically
we
could
basically
say
we're
going
to
do
with
normalize
exactly
what
we're
doing
with
base
left
2
versions,
one
it
is
contextual
and
one
is
naked
and
the
contextual
one
literally
just
drops
it
an
extra
selector
around
the
top
level
and.
B
F
B
H
F
C
Because
that
there
is,
I
think,
there's
one
there's
one
distinct
difference
with
that,
and
the
contextual
reset
the
contextual
reset
will
win
in
the
normalized
case.
It's
not
necessarily
going
to
like
be
starting
from
zero
and
be
able
to
win
and
all
the
style
rules,
because
I
may
have
you
know
written
some.
I
may
include
my
base
style
sheet
at
the
top
of
the
page
that
that
does
a
few
things
and
you
know
maybe
my
base
reset
at
the
top
and
then
all
of
a
sudden.
C
I
add,
I
require
some
module
and
it
brings
normalizing
to
the
page.
Now
it's
normalizing
a
resetted
area
already,
so
it
doesn't
really
do
what
it's
supposed
to
do.
There's
no
guarantee
that
if
you're
normalizing,
something
that
started
with
no
Stiles
right
in
that
context
area
does
that
make
sense.
I'm
probably
not
saying
right,
but
like
think
about,
if
I'm
my
page
I
included,
it
makes
you
think
you're
still
destroying
the
page
just
out
your
city.
B
C
I
included
a
reset
on
at
the
top
of
my
page
and
then
I
tagged
like
just
the
sidebar
of
my
page
and
said.
I
want
this
to
use
CSS
forms
because
I
have
a
form
in
the
sidebar,
and
then
that
brings
in
normalized
normalizes
not
going
to
trump
the
styles
of
the
reset,
like
it's
going
to
be
wonky
in
there
always.
C
F
I
said
do
something
to
the
table
over
here
and
then
body
reset.
You
would
assume,
did
what
I
did
to
the
table
there.
For
example,
if
there
was
any
resetting
happening,
sure
yeah,
if
my
son
was
less
specific,
which
I
highly
doubt
is
going
to
be
less
specific,
plus
that's
a
bit
more.
According
to
unusually
the
globe
reset.
First
yeah
I
mean
the
main
issue
with
the
skin
style
approach
to
keene,
contextual
stuff,
where
I've
got
a
class
name
up
here
and
I'm,
assuming
everything
inside
of
there
is
now
acting.
F
C
F
B
C
Guess
what
I'm
wondering
is
how
big
of
a
problem
is
it
going
to
be
where
somebody's
page
gets
destroyed
and
it
seems
like
a
data
table
is,
is
the
most
likely
candidate
that
would
be
pulled
in
on
demand,
because
it's
a
it's
a
javascript
widget,
which
is
going
to
depend
on
the
CSS
tables,
which
is
going
to
depend
on
normalize
or
something.
But
I
guess
we're
saying
it
won't
depend
on
normalize.
I
don't
think
it
needs
to.
A
B
C
J
J
C
F
C
Well,
I
guess,
but
I
would
say
that,
if
we're
going
to,
if
we're
going
to
offer
style
like
here,
here's
how
you
could,
from
a
higher
level
style
your
forms.
But
we
don't
offer
anything
to
say:
here's
how
you
from
a
low
level,
just
style
the
you
know,
beginning
of
your
page,
that
that
seems
off
to
me
like
if,
if
normalize
doesn't
go
into
core,
then
why
a
CSS
forms
going
into
core
ya.
F
F
F
A
F
C
Mean
even
even
having
things
like
making
articles
asides
all
the
html5
elements
display
block
and
I,
even
like
there's
little
things
like
that
that
we
don't
have
now
and
I,
don't
know,
I
feel
like
I
feel,
like
the
the
ayah
every
project
I've
started
in
the
last
two
years.
The
first
thing
I
do
before
I
start.
Styling
is
I
slap
normalize
on
the
page
and
then
go
because
it's
much
easier
to
start
with
you.
B
B
I
think
I
think
we
can
decide
that
we're
not
going
to
use
as
a
dependency
for
another
four
components,
but
if,
if
we're
not
using
a
defense
for
the
component,
I
still
don't
think
it
should
be
like
it's
not
a
dependency.
Therefore
it
shouldn't
be
in
core,
because
it
is
so
upstream
that
I
I
do
feel
it
should
be.
Just
like
eric
said.
Oh
yeah,.
F
B
A
B
I
think
I'm.
Okay,
with
that,
like
if
people
know
that
I
think
that's
what
I
put
in
my
thoughts
as
we
put
a
normalized
today,
we
can
weaken
depth
like
we
can
sit,
they
can
co-exist
for
a
release
or
to
weaken
deprecated
base.
After
that
we
don't
know
you
defecate
base.
Now
sorry
in
two
releases
it
goes
away.
Yeah.
G
G
J
J
G
But
the
difference
with
a
JavaScript
module
pulling
in
something
like
CSS
button
is
usually
because
the
JavaScript
module
is
not
there
yet
yeah.
So
it's
kind
of
like
a
panel
that
that
you
open
and
suddenly
there's
a
button,
so
is
a
different
use
case.
I
mean
if
you
have
a
bunch
of
buttons
on
your
page,
then
of
course
you're
going
to
include
that
up
front.
But
if
you're
spawning
something
dynamically
that
just
happens
to
have
buttons
that
it's
probably
normal
for
it
to
go
out
and
fetch
it
and
are.
C
F
G
A
K
A
F
C
G
G
G
A
F
B
A
G
G
G
We
could
theoretically
start
moving
that
direction
by
moving
our
older
browser,
specific
code
into
modules
that
get
loaded
only
when
those
browsers
are
around,
and
then
we
can
tag
them
as
being
relatively
deprecated,
but
not
technically
deprecated.
So
if
there
is
a
bug,
we
could
go
in
and
fix
it
if
it
was
a
bad
enough
bug,
but
we
can
just
kind
of
leave
it
over
there
by
itself
and
move
ourselves
forward
and
I
think
that's
the
way.
G
G
Why
I
brought
that
up
as
we
do
that
in
several
places,
because
I
know
there's
a
couple
of
spots
in
like
selector?
That
has
a
big
fork
in
two
different
functions.
We
could
just
say
screw
it:
I'm
using
IE
six
you're
going
to
get
the
extra
you're
going
to
get
the
extra
module
download
plain
and
simple
you're
going
to
take
that
you're
going
to
take
the
hit
to
get
a
little.
G
G
C
G
It
was
in
the
way
way
add
statement,
it'll
be
processed
at
request,
whatever
it's
pulled
in
so
at
that
point,
that
would
say.
Oh,
this
is
a
this
needs
to
be
here,
go
out
and
fetch
this
other
thing
and
not
actually
include
that
in
loader,
so
they
take
the
hit
of
the
extra
module
and
the
the
request,
but
still
it
helped
clean
up
our
code
base.
That's
that's
what
I'm
aiming
for
is
to
standardize
how
we
do
this,
so
we
can
do
it
going
forward
and.
C
I
kind
of
like
that
idea,
if
the
metadata,
bloat
or
reduction
in
bloat
is
significant,
then
newer,
browsers
aren't
as
penalized
like
especially
mobile
devices
having
to
pull
down
and
parse
an
extra
on
one
on
gzipped,
like
30k
of
metadata,
is
going
to
be
slow
on
their
dinky
processors.
I,
see
a
benefit
and
letting
those
old
like
the
old
browsers.
Take
that
extra
dependency
hall
yeah.
G
Well,
I've
also
mentioned
this
before
too,
is
that
it
not
only
older
browsers
but
any
browser.
So
if
we
have
any
chunk
of
code
somewhere,
that's
just
for
WebKit
pull
it
out
into
a
WebKit,
only
module.
So
when
it
comes
time
for
people
to
package
like
an
html5,
iOS
app
or
the
upcoming
Firefox
OS.
So
we
know,
we've
got
some
code
in
there
just
for
Firefox.
G
C
Would
have
to.
We
would
want
to
do
that,
based
on
a
feature
detection,
though,
for
all
races
right
to
figure
out
which
okay,
here's
the
core
modules,
those
are
all
in
the
loader
metadata,
but
once
you
grab
those
core
modules
feature
detection
is
going
to
say
what
supplemental
modules
you
might
need
to
shim,
shim
and
stuff
right.
G
So
like
like
YQL,
is
a
good
example.
So
Yul
now
has
a
main
yql
module
and
three
plug-in
modules,
and
those
three
plug-in
modules
are
whether
it
supports
JSONP,
whether
it
supports
nodejs
or
right
now
it's
win-win
j/s,
but
it
should
actually
be
cores,
so
it
should
be
saying.
Does
this
thing
support
cores?
G
That's
exactly
where
Eric
and
I
have
been
talking
about
is
being
able
to
use
es5.
You
know
we're
starting
to
use
the
s5
shims,
but
that's
the
same
principle
is
that
if
that
feature
is
available,
we're
going
to
just
pull
that
in
and
not
pull
in
the
other
one,
but
but
if
we
do
have
sims
4
we're
going
to
pull
the
shims
in
and
that's
the
same
principle
as
our
you
know,
dealing
with
ie6
and
ie7
is
that
these
are
those
shims
we're
putting
these
things
in
place.
So
the
damn
browser
works.
G
C
I
think
one
one
thing
we'd
want
to
do
is
like
so
this
would
definitely
help
the
the
bundling
story
too.
If
somebody
wanted
to
build
their
own
seed,
they
could
build
their
own
seed
with
the
code
that
it's
going
to
be
a
relevant,
no
matter
which
browser
hits
it
which
is
ideal
and
then
so
they
they
package
all
that
up,
that's
their
seed.
Maybe
then,
then,
that
code
runs
feature
detection
tests
run
and
then
the
results
of
those
realize
that
they're
going
to
need.
You
know
some
other
modules
or
something.
C
G
The
same
goes
for
application,
bundling
too.
So,
if
they're,
but
if
they're
writing
an
html5
app
that's
going
to
go
in
WebKit
only
and
they
need
to
bundle
this
thing,
so
they
can
compile
it
and
package
it.
Then
that
gives
us
a
good
story
of
saying
this
is
all
you
need?
You
don't
need
to
require
the
entire
20
megs
of
the
build
directory.
Here's
exactly
what
you
need
to
get
your
job
done.
G
F
C
G
No
I'm
not
talking
about
it,
somebody
hitting
with
a
browser
I'm
talking
about
people
bundling
specific
apps
for
a
device
that
they
have
to
submit
to
like
an
app
store.
They
know
the
platform
they're
going
to
you
know.
The
same
goes
for
Windows
8.
If
you
could
load
up
this
little
app.
That
said,
here's
my
thing:
what
do
I
support
and
it
generates
the
the
list
of
you
know
our
hashtags,
for
this
is
what
your
feature
list
is
drop,
that
into
the
build
and
say
this
is
the
kind
of
built
that
I
want
sure.
G
So
that,
but
it
solves
both
problems
at
the
same
time,
that's
kind
of
my
whole
point
is
that
it
will
not
only
will
it
work
in
the
browser
whenever
the
browser
hits
it
it's
going
to
do
the
same
logic
it.
So
it's
going
to
execute
all
the
same
feature
test
and
it's
going
to
go
out
and
fetch
everything
it
needs
when.
C
C
B
H
B
F
B
G
C
Tilo,
if
you're
submitting
a
hybrid
app
to
Apple,
you
knew
it
was
going
to
be
touched.
So
you
would
turn
on
the
touch
feature
and
you
would
say
the
only
modules
I'm
going
to
use
our
then
the
node
and
events
modules.
Then
it
could
build
a
version,
a
package
of
Yui
that
included
all
the
stuff
that
only
the
stuff
that
you
need
and
only
the
stuff
that
you're
going
to
use.
Yeah.
G
It's
very
similar
to
the
way
lodash
does
they're
built
that
that's
what
I'm
looking
at,
because
lodash
I
mean
props
to
John
David
on,
but
lodash
has
a
really
badass
way
of
bundling
and
making
really
small
packages
for
exactly
what
you
want,
but
that's
the
idea
that
we
want
Yui
to
fit
into.
You
know
we
want
to
be
able
to
take.
G
G
G
G
C
G
F
G
F
And
in
terms
of
complexity,
that
it's
the
same
as
testing
our
browser
specific
steps-
oh
there's
code-
that
only
runs
nie,
for
example
today,
so
that
most
modules
would
only
get
loaded
in
the
IE
environment.
So
the
same
issues
could
apply.
That
would
have
liked
that
scenario,
which
are
there's
a
difference
between
the
module
footprint
in
this
test
environment.
Then
there
is
this
test
environment,
but
in
practice,
though,
she
there.
F
It
really
comes
down
to
where,
first
of
all,
when
you
consider
support,
we've,
always
taken
progressive
enhancement
approach
to
building
things
talking
about
getting
rid
of
this
browser
or
that
browser
doesn't
make
any
sense
in
that
context,
really
talking
about
what
features
do
we
support
and
what
are
our
target
environments
that
you
test
sounds?
This
is
the
thing
where
the
browser
versions
really
come
into
play
and
then.
C
But
I
think
I
think
it
creates
a
story
where
there's
there
becomes
no
negative
side
effect
like
especially
if
we
can
reduce
the
metadata
footprint
in
terms
of
the
huge
metadata
file
that
we
have.
If
we
can
even
reduce
that,
then
there
becomes
no
negative
impact
on
good
browsers
for
supporting
the
old
ones,
which
is
like
it.
F
Seems
like
the
idea
no
I
mean
I.
Imagine
when
people
are
asking
when
can
we
stop
supporting
browser?
X
is
because
they,
the
location,
is
there's
more
code
being
loaded
and
more
run
time
costs
and
overhead
associated
with
that.
But
if
we
can
say
that's
not
an
issue,
then
it
really
just
comes
down
to
how
much
how
many
different
things
do.
I
need
to
test
my
stuff
on
to
fair
yeah,
yeah.
C
I,
especially
for
if
our
implementation
is
some
wrapper,
function
equals
native
version
or
equals.
Are
you
know,
shimmed
implementation?
You
do
that
once
like
you
can't
you're
not
going
to
be
able
to
sense
that
that
overhead
there
in
any
type
of
like
application
running
so
yeah
I
like
that
story,
so.
F
G
C
G
Well,
theoretically
too,
we
could,
like
I
said
we
have
to.
We
have
to
redo.
Why
not
features,
and
why
not
feature
could,
theoretically,
we
could
bucket
those
and
actually
have
different
metadata
files
up
on
the
CDN
that
when
Yui
knows
that
I'm
in
this
environment,
I'm
gonna
go
fetch
that
extra
piece
of
metadata
that
I
need
that
might
work
just
as
well
too
yeah.
G
With
that
I'm
specifically
talking
about
older
browsers,
so
if
we
had
like
a
an
ie6
bucket
that
we
said
these
are
the
these
are
the
nine
sub
modules
we
know
we
have
that
are
just
there
to
give
support
to
IE
six
seven
and
eight.
We
could
generate
a
separate
loader
metadata
for
just
them
and
whenever
YY
gets
loaded,
it
would
go
fetch
that,
along
with
the
normal
metadata
and
then
run,
but
then
future
proofing,
we
do
it
exactly
like.
We
talked
about
yeah
I,
think
it
all
depends
on
the
number.
C
G
Two,
that's
not
that
big
of
a
deal,
but
when
you
start
getting
up
there
in
numbers,
that's
when
we
have
to
start
looking
at
it,
because
there
was
a
concept
I'm
looking
at
for
the
next
version
of
loader,
which
is
buckets
of
being
able
to
bucket.
I
certain
things
so
that
you
can
go
fetch
them,
and
this
is
the
same
principle,
is
that
I
could
say
you
know
I
could
go
into
my
config.
It
say:
I
want
these
nine
things
in
this
one
bucket
and
it's
always
going
to
fetch
these
nine
things
every
time.
G
Well,
not
not
to
mention
you,
you
could
you
would
always
just
put
it
in
your
youth
statement.
If
you
want
to
type
of
thing,
you
know
it's
it's
one
of
those
that
it
we
need
to
make
it
open
enough
that
the
developer
can
deal
with
it,
because
we
know
we
still
have
a
lot
of
developers
sitting
on
these
really
old
internal
intranet
things
that
they
would
need
to
use
it,
for
we
leave
it
into
their
hands
to
fix
their
own
problem,
but
but
we
did
at
the
same
time
we
don't
want
to
tie
their
hands.
C
Well,
I,
it
sounds
like
we
have
some
good
ideas
going
forward
with
with
making
all
this
better
and
still
saying
that
we
support
you
know
the
old
browsers.
Are
we
we
always
support
our
targeted
by
our
test,
our
target
environment
and-
and
we
don't
penalize
good
browsers
from
supporting
some
of
those
older
ones
in
the
target
of
iron.
I.
Think
that's
a
good
story.
Yeah
analyze.
J
F
G
That's
why
I
was
saying
cuz:
we've
already
got
the
code.
There,
we've
already
got
the
really
nice
module
system
that
takes
care
of
it
for
us,
so
that
this
is
just
like.
This
is
the
Yui
way
of
saying
we.
We
really
want
to
make
sure
the
good
browsers
have
support,
but
we
don't
want
to
forget
about
the
guys
that
we've
already
had
code
sitting
here
running
for
we're
not
going
to
forget
about
you,
but
you're
gonna
you're
going
to
take
the
hit
just
because
you
got
a
crap
browser.
Thank.
A
A
F
C
I'm
speaking
of
these
browsers
part
of
this,
this
sprint
that
we're
in
now
we
wanted
to
add
iOS
6
to
the
matrix,
which
it's
now
been
out
on,
like
hundreds
of
millions
of
devices,
and
we
don't
have
had
our
matrix
yet
do
you
know
where
we're
at
with
that
Andrew
it
I
know.
Didn't
we
have
a
report
on
track
report
just
for
iOS
6
tickets
yeah.
We.
A
A
C
C
We
don't
have
many
tickets
left
for
this
release.
That's
nice
yeah!
Oh,
so
mine
are
closed.
Matt's
a
checked
in
and
that's
it
yeah
so
I
mean
there
was
a
essentially
all
mine
were
false
positives
from
Yeti
not
being
able
to
handle
URL
navigation
or
something
going
on,
I'm
not
sure,
but
when
I
ran
them
all
locally
through
yogi
serving
them
and
then
going
on
my
iOS
6
device
and
trying
them
out,
they
all
work
perfectly
fine
and
they're
all
related
to
navigation
stuff.
C
G
G
A
C
G
F
C
F
B
I
found
I
found
some
data
here.
This
is
from
wikipedias
and
now
traffic
analysis
report
in
October
of
2012,
for,
like
all
all
like
what
devices
are
hitting
Wikipedia
essentially-
and
it's
like
just
to
give
they
do
hundred
percent
based
on
everything
like
desktop
and
mobile
put
together,
but
just
just
to
give
some
sense.
Ios6
is
a
three-point-five
percent
of
their
total
hits
and
iOS
four
is.
D
B
H
B
I
C
G
C
G
B
C
A
G
F
A
C
F
G
F
C
F
A
F
A
J
So
what
do
we
haven't?
Pull
requests
that
people
want
to
get
out
there
for
tomorrow's
breeze,
I
think
there's
two
others
to
button
ones.
They're
not!
It
would
be
nice
to
get
him
in
I
one
of
those
trivial,
but
they
less
than
72
hours
they
were
submitted
yesterday
morning.
So,
yes,
they
need
a
review
or
two
yeah
yeah.
So.
F
B
C
F
C
J
F
B
C
G
A
J
B
G
F
A
A
I
G
B
L
Place
so
if
pull
request,
discussions
are
happening
on
github.
They
also
want
their
issues
are
bugs
right
to
also
be
in
kippa.
My
concern
there
is
that
now
we
open
the
floodgates
and
the
people
are
going
to
start
filing
bugs
in
github
and
to
be
managing.
You
know
sprint
tasks
and
triaging
and
coming
stuff
that
doesn't
have
a
proper
workflow
setup.
I
feel
like
is
a
little
bit
risky.
Is
there
a
way
to
you,
know
ACL
or
prevent
just
Joe
Schmo
from
opening
issues
in
20,
not.
B
L
L
G
L
B
A
L
B
L
L
G
B
G
That's
the
thing
is
that
we
would
just
turn
around
and
ping
the
ticket
with
the
link
to
the
old
one
yeah
kind
of
thing,
just
to
kind
of
show
the
cycle
around,
so
that
the
the
component
ownership
is
one
thing
that
the
the
reason
I
haven't
written
anything
to
do
that
yet
is
because
there
is
no
posts
commit
hook.
You
know
no
web
hook
for
creating
a
new
issue,
so
it's
something
that
has
to
be
pulled
so
we'd
have
to
pull
their
API
at
a
certain
time
to
find
out.
G
C
Well,
I
think
that
the
if
we
did
some
type
of
yeah
so
so
the
hard
thing
is
if
we
don't
have
the
right
hook.
So
that's
a
pain
in
the
ass,
but
if
we
do
have
the
right
hooks,
we
don't
have
to
maintain
too
much
state
just
essentially
like
where
we're
at
an
issue
processing
land.
Then
you
know
where
I
think
we're
talking
about
a
lot
less
than
building
an
entire
bug.
Tracker.
Yes,.
K
L
I
D
G
L
G
G
C
G
L
J
C
A
C
G
L
I'm
gonna
propose
that
we
dip
our
toe
in
the
water
and
you
can
have
issues
for
the
way
way,
three
repo
by
turning
it
on
and
by
piecemeal
migrating.
What
kind
of
work
in
progress
bugs
from
track
into
github
/
developer
comfort.
So
if
you
want
all
your
buds
to
be
there
go
for
it.
If
you
want
zero,
that's
fine
for
men
too,.
J
L
C
L
G
G
G
E
A
A
G
All
right,
well,
the
one
that
I've
gotten
the
most
use
out
of
is
actually
creating.
One
called
needs
pull
request.
So
when
somebody
sends
me
an
issue
I'm,
like
yeah,
I
kind
of
sort
of
agree
with
that,
but
I'm
not
gonna
write
it.
It
needs
a
pull
request.
Nine
out
of
ten
of
them
have
getting
me
pull
requests
just
because
I
put
the
tag
on
there
saying
just
do
it
yourself
and
send
me
a
request
and.