The king is dead.
Long live the king.
You've probably heard this phrase or a variation
on it.
It's a type of cliché called a snow cone.
This phrase was made in various European countries
fog the monarch to the thrown.
It stems from the law of the law that states
the transfer of sovereignty occurs simultaneously
upon the moment of death of the previous monarch.
So long live the king is referring to the
new king who is now in power.
Ironically enough I checked in here this morning
on swarm and stole the mayorship, I don't
know if that's a good sign or bad one.
Anyway what does a monarch have to do with
Web development?
Well, it's not like we ever jump from one
tool or library or framework to another as
soon as something new and shiny.
I'm not saying the community as a whole does
this, but there's something we trend la we
declare dead rather quickly.
Sometimes the king is a self-fulfilling prophecy
or we're out right murdering him.
Who knows.
But the last few years, CSS has been pronounced
dead many times or at least assumed and put
in the casket.
As preprocessors have taken the crowd, there's
a struggle although Sass seems to have a majority
of the population behind.
I'm sure some of you try to avoid CSS together,
at least some coming in from the JavaScript
world.
How many of you offer style sheets more or
less daily?
Show of hands?
All right.
So maybe half the room.
Keep your hands up.
Of those that author CSS, how many use preprocessor.
More hands went up.
All right.
So up coming code examples are using the Sass
syntax, I use that, but the concepts are available
in any of these tools.
So preprocessor are clearly useful, and there's
a good reason they're playing subpoena a significant
role.
They've enabled us to do things that just
a few years ago simply weren't possible or
at least easy with vanilla CSS.
You can break codes into multiple modules
and file.
You can create code that's usable yet easily
changed when needed with variables.
And they give us the ability to more easily
use small snippets of code.
They've even made CSS more beautiful with
less typing required.
Now, I'm not sure that features like easier
to type are really what we need from our main
languages.
But as the use of preprocessors have grown,
I've been looking at the complexity that they
add to the table and wondered if they're the
right approach.
Now, before I continue, please put down your
pitchforks and torches.
I'm not telling you not to use them.
They're awesome.
They give you a lot of flexibility.
And I'll point out that some of the problems
I'm about to describe aren't necessarily problems
with the language themselves, but more maybe
with how they're used.
So if you're familiar at all with CSS, one
of the first features of pro processors that
might have caught your eye is nesting, it's
lets you merge your syntax and styles together
so that you can write modular code that's
self-contained and you don't have to repeat
the parent sector for each element inside
the element that you're targeting.
So in this example you've got the Sass in
the left, and you can see that the H1 and
H2 elements are inside the alert as they might
be in the dom, but with the CSS, it gets split
out so the browser knows how to handle it.
Of course this gets taken way to far.
You may have come across something like this
in the past.
And you can got this with regular CSS, though,
though, it's an easier trap to fall into,
especially if an author isn't necessarily
thinking about the performance implications
of this on the generated CSS because each
one of these additional selectors slows the
browser down.
How much is up for debate.
But it can have an affect in the long run.
Something else that can come into play with
preprocessors is deprecation.
And I've had conversations with the maintainers
that how this is something they're actively
trying to avoid, they've been very deliberate
in the features they're trying to add and
the features of CSS.
However, there have been a few times that
I've opened an old Sass project only to find
tout outta that it's not filing and I've got
a console full of errors.
And because of that or some other weird configuration
issue, you're diving down the rabbit hole
into a series of more challenges to figure
out what's going on.
You've got different versions of preprocessor
which might need a new version of node or
Ruby.
Before you know you've lost half a day of
build.
These preprocessors end up being on top of
gulp, sure the old days we used to open up
and start.
But isn't some even of simplicity in our workflows
something we should aspire to?
And I don't think that simplicity is always
achieved by throwing more tools into the process.
So speaking of which, simplicity in tools,
you should remember that preprocessors are
just additional level of abstraction in your
project.
I'm actually a little bit concerned, I've
seen some guys that don't work predominantly
in CSS aren't always aware that at the end
of the day all of these do compile back down
to CSS.
I've heard of some boot camps that teach lesser
Sass, but don't necessarily teach Y, and,
you know, we're using it as a industry, but
sometimes it's not always clear what problems
are solving to people.
They're not imagine being I can tools, they're
conveniences -- athlete theoretically.
And the one by got me thinking but not just
what approach we should be taking, but about
what the future of front-end Web development
actually looks like.
I spent the last few weeks digging into the
CSS spec, fully around of developer tools
in browsers and talking to the people who
make this stuff happen.
I've come to a little bit of a conclusion.
Preprocessors saved us from CSS.
But CSS will save us from preprocessors.
Now, it's probably not going to be quite the
way you expect.
So pleas keep your mind open to the possibilities.
As I'm sure you've noticed sites have gone
from static styles to interactive applications
in which it's becoming increasingly difficult
to count for every single variation.
So it's rather natural the first way CSS has
started to evolve is to enable the browsers
to make certain rendering decisions for us.
After a few years of horizon, Plex box is
on the use, unless you still need to support
IE9 or below, and in which case you have my
condolences, and it's to describe how our
content should lay efforts itself out rather
than explicitly laying properties every element.
One of the most useful features is it can
respond to the amount of children an element
has which change the size of the children
based on the quantity of them.
So it's especially useful in content manages.
I came across a tweet a few weeks ago where
someone was asking if they could use Sass
box to update the Sass code.
And he had to add new content every time content
was removed.
And as you can imagine he was using code to
code project and to make this easier to keep
track of everything going on, especially if
you have a lot of components like this.
But isn't one of the ideas behind CSS that
your content should be separate from your
presentation?
At least that's what CSS zen garden told me.
We're fortunate we can handle these situations
in a of them much more graceful way.
With these two styles, or layers are further
separated.
You can imagine we have a item container,
and then any items inside of it with this
class will automatically be the same size
based on this, you know, these simple styles.
Doesn't that just give you the would remember
fuzzy feeling inside?
If you take this a little bit further, you
have some layouts that would have previously
required a lot of processors another tool
that we can eventually use for layouts, and
this is only on the horizon is the CSS grid
module.
This is useful for describing container behavior
at various screen sizes, month so than the
content based approach of flex box.
I don't want to get into the syntax of it,
it's gnarly, but it's a similar approach of
what Apple is taking for its framework for
universal apps, if any of you have looked
at that before.
You can declare flexible columns or rows with
minimum dimensions and of course use other
existing techniques to build the layout as
needed.
I'm pretty excited to see where this goes
as Web technologies use for development, features
like this will make our lives as developers
a lot easier.
So let's look at more tangible example of
how CSS is evolving directly into the path
of preprocessors.
Variables has been one of the easiest selling
points, I'm sure I don't have to explain any
of the utility here.
They're pretty straight forward, you declare
a variable and it gets injected into the CSS
at compile time.
As you might expect, they're coming in with
CSS.
They've already been implemented in Firefox
if you want to start playing around with them
today, and they look a little bit like this
or, you know, exactly like this.
There is one key difference you do need a
scope to define the variables.
I know it's CSS, you might expect it just
goes in the global scope; right?
But, hey, we're moving forward.
So anyway rapid root selector.
Now, I know what you're thinking.
They're not as nice to look at as preprocessor
variables.
Some preprocessors have been all about getting
rid of extra syntax while we're adding even
more here.
You know, what had to?
It doesn't matter.
One of the incredible things about CSS is
that it's both backward and forward compatible.
It has to make sure that it doesn't break
browsers and still stay compatible in new
browsers.
Because once you get something on the Web,
it shouldn't break later on, well, most of
the time.
Besides who cares if a variable is a few extra
letters to type.
And especially if you're against typing.
But you can use invariables processors today.
But who cares cite scythe.
Here's the awesome thing workers' compensation
you can do so much more with CSS variables
because they have this awareness of scope
that is precompiled static file simply can't
match.
I could probably give a whole talk demoing
their awesomeness, but for now you'll have
to take this sample.
We declared some variables at the root scope,
and then we used them to describe the text
color in a DIV.
That DIV will be hot pic pink.
But less add some magic and add some green
inside the class.
Take a look at what happens when we have another
DIV for the magic.
It goes white.
Let that sink in for a second.
You can declare a variable and all the previous
stuff herniated comes into it.
This is one of the cases where CSS is evolving
past the abilities of preprocessors.
Of course I'm not sure if I should be excited
or terrified of the inevitable bootstrap implementation
built on this, but I know some neat stuff
is going to come of it.
Another concept is the object of orientation
of CSS where classes can inherent from another.
It's a concept that keeps you from having
to litter your markup for multiple cases.
It can create some CSS slackers, so you can
declare or inherent a set of classes and it
will generate the CSS that has the common
elements in one selector and then the unique
elements to each class.
Similar to extends are mixins.
For their repeating groups of properties.
Of course most of have us have moved to tools
like auto prefixer for that, which itself
will be dead soon anyway as vendor stop with
this vendor prefixing nonsense.
There are others that can accept arguments.
But I think that starts to get us into an
area where we've got a little bit too far
down the rabbit hole, abstracting away from
the CSS actually is, and of course that's
an entirely different conversation.
Feel free to find me this week if you want
to argue about it.
So where do those stand?
I was talking to Google, and he was telling
me that this might actually be easier to implement,
extends that is, might be easier to implement
natively in CSS than it even is in preprocessors.
He's written a proposal and passed it around
the group mailing list.
There seems to be a interest in it so we'll
see where it goes.
I think the combination of extends and variables
might start to fill those gaps and, again,
it's about different ways of thinking about
how CSS is evolving, not necessarily a one-to-one
correlation from a preprocessor.
Nesting.
So you're already aware of my thought it on
the, but I'll admit there's some opportunity
for tactic sugar.
If JavaScript can get classes, we should have
something nice too.
So you should see that in here, you know,
you can use these nesting, and it starts to
generate a fair amount of CSS.
Well, CSS level 4 has a bunch of pseudo-selectors
that will make our lives easier.
Although this is my favorite.
It than manually listing out all the variations,
which is what the nesting preprocessor code
would end up spitting out.
So speaking of sin tactic sugar, there's another
proposal for stages for extensions to CSS,
this is really more of a bunch of open issues
you can find this link later.
That this might allow us to enhance CSS ourselves.
The document is still pretty much, you know,
that list of open questions, but it's an interesting
read nonetheless.
One example is that of defining custom selectors
so that instead of typing all, say, the heading
elements every single time you want to target
them all.
You can call them, you know, this heading
selector, use it once, and continue writing
CSS.
So it's kind of like variables for selectors
although there's some other stuff that comes
with it.
As I'm sure you've heard, Web components are
coming.
Eventually.
While they don't map to preprocessor feature
directly, I think they allow us to solve similar
problems in a different way.
Namely once we've gotten the hang of using
them, some of our global scope issues might
start to fade away.
There's a bit of a drama going on with them
where certain vendors pushing forward without
the collaboration, there's a Mozilla hacks
article if you want to give a read on that.
Do you remember the import statement?
Preprocessors have repurposed this over the
last few years.
If you use a preprocessor, it's going to put
your files together, that's because its original
use in CSS had the unfortunate side effect
of making another HTTP request, which is not
so great for performance.
So we built our modular preprocessor files
and glued them all together in one massive
style sheet using the preprocessors behavior.
Now, I don't know if you've heard of HTTP
2, but it's going to change the way the Web
works at a low level.
It's going to make better practices.
It's going to be better to make them separate
requests since they won't block one another
and they can only be called when needed.
This has some great implications, not just
for building modular coding, but also for
cashing.
And complete side note, did you know that
CSS support media queries?
I had no idea when I was discovering that
when I researched this because I was taught
not to use these import statements.
My mind was kind of blown.
Anyway if you're building a site that's going
to be served up using HTTP 2, you want to
know in advance so that you can change your
build in the development process so you know
what assets to load rather than shoving one
thing into one massive filing and throwing
it down the pipe.
So one last item I want to talk about is container
queries, you might have seen Matt's great
article last week on the responsive issues,
community group efforts to make container
queries a thing.
For those of you not familiar, container queries
is this theoretical syntax based on the parents
size instead of just being tied to be responsive
to the view port using married queries.
As I was actually headed up here Monday, there
was an interest happening on the GitHub repo
for container query use contains where there
were some implementations problems and how
they might be resolved.
The current suggestions get about 95 percent
of the Kay using just CSS.
But it's possible we'll need to sprinkle in
some JavaScript magic to get them working
as desired, you know, voiding things such
as infinite loops.
Keep your eyes peeled, maybe look at the W3C
drafts for the contain property, and, you
know, maybe we'll have one more powerful tool
to add to our bag of tricks in a few years.
So preprocessors with they're definitely a
great testing round.
I actually e-mailed Chris Epstein, who is
one of the core maintainers of Sass to get
his evolution on CSS and the idea that it
might replace tools like Sass.
While he doesn't necessarily thank Sass is
going to anywhere in the short-term, he said
that the Sass team loves the direction CSS
is moving in.
Even if it ultimately obsoletes their technology.
One of the early goals with Sass was to show
the CSS specification authors how adding programming
to our style sheets would actually simplify
them.
And, you know, they seem to have succeeded
at that.
Back when Sass was first created, there was
a post on the W3C about why CSS variables
were not coming to the native language.
And, you know, times have changed.
So what do we do?
If you look at JavaScript, it's kind of gone
through this transformation already.
CoffeeScript was a thing for a bit, and now
we've moved onto babble to build sites to
use tomorrow's syntax today.
Now, this isn't something that's available,
obviously there are tools like post CSS hitting
the scene, but they can only go so far in
allowing us to using tomorrow's stuff today.
The CSS polyfills are not quite the same as
they are in JavaScript.
And of course there's always the new hot CSS
like tools like react with building the still
built in.
I don't want to discount that, and preprocessors
and CSS are going to be useful for quite sometime,
but we should continue to use techniques like
progressive enhancement to bring in new shiny
whenever possible.
All the while CSS specification writers are
looking at what preprocessors are doing and
trying to find solutions for the root problems,
rather than a merely addressing the symptoms
with pretty syntax that might have capability
issues when you look at the bigger picture.
The king isn't dead.
He's just carefully planning what's best for
his subjects.
Thank you.
[clapping]
