Why Is CSS So Weird?


(upbeat music) – If you’re anything like me, you spend a lot of time
making things for the web. And that often involves using CSS to lay things out on the web. Whether you’re using
that with a preprocessor or directly in raw text files or through JavaScript in some way, CSS is something that we
all have to use on the web. And we hear quite often a
lot of opinions about CSS. It’s either broken or it’s awesome or maybe sometimes both at once. This popular meme, CSS is awesome but seems
to imply that maybe there’s something wrong
with this overflow default. And it’s a little bit
of a, is it a rabbit? Is it a duck? Depending on how you look at this, it’s either a feature or a bug, but either way we have to express our opinion loudly on Twitter. And I hear often that the problem with CSS is that CSS is for documents. And now we’re building applications, and applications are in
such a different field that CSS will never make that transition. And that’s partially true. When Tim Berners-Lee invented the web in 1989 and 1990 and
made the first website, he was very clear that he was trying to make a web of connected documents, and specifically at that
point scientific articles. He had this vision for
making these articles available to scientists
around the world for free. You can see here emulated
the Line Mode Browser for older machines without
graphic interfaces. And I have to use numbers to go to a link. Here it says the project is based on the philosophy that
much academic information should be freely available to anyone. But it’s not really fair to say that CSS was only for documents. It’s the entire web that’s only
for documents at that point. And it’s a little bit like saying that the Gutenberg
press is only for bibles just because that was one
of the first use cases. The web is a very young medium, at this point less than 30 years old, and we’re still figuring it out as we go. But the underlying technology
is developing quickly, both the devices and computers
that we’re working on, also the languages themselves,
and also what we’re building. And it’s an open standard so we can all work on that together. And as the web grows, we make
more and more web things, moving from documents and
sites to applications, basically full desktop
and mobile applications, entire businesses exist on the web. We’re building all sorts of cool things and they’re getting bigger and cooler and more difficult to
build in lots of ways, and that raises the question what are we going to do now that everything is on the web? Do the same rules apply? Does CSS specifically
work on the modern web? And really why is CSS so weird? ‘Cause it is weird. It doesn’t work the way that
a lot of other languages work, and it doesn’t work the way that we’re used to
design programs working. It is a very strange language. And part of that goes back
to these early documents. And this time I’m going to
look at it in a modern browser. The same file still work
even in our latest browsers. And some of the constraints that Tim Berners-Lee mentions here in this first website already, when designing the HTML document type, consideration was given
to a certain simplicity in order to allow many browsers and hopefully many editors to be developed on many platforms. In order to make this platform agnostic, HTML is a very simple
language intentionally. And the same is true of
CSS a couple years later. But here, this implies no
device-specific markup. That makes sense, we don’t want anything that can only run on one
machine or on another because that would defeat
this global idea of the web. Or anything which requires control over fonts or colors for example. And what he’s noticing here is that if we’re going
to allow multiple devices with different graphic abilities
to display the same web, then we have to give up control of fonts and colors
and display properties. So right from the beginning, there’s a problem with design on the web. It’s problematic to design in a way that’s going to be device agnostic. In 1994 Tim Berners-Lee forms the World Wide Web Consortium with a number of businesses. The membership is quite large and made up of all sorts of organizations from easily recognizable tech companies to browser vendors to banks. Anybody that is interested
in the future of the web can become a member of this organization and help guide the web into the future. More important here on the W3C website is this idea that it
has a mission statement. The web has a mission statement
and it’s based very much on that initial document
from Tim Berners-Lee. We have the open standards
principles which mean that everything is going
to be developed in the open and no one company isn’t
going to have control over the future of the web. But then we also have these ideas, this principles of the web. It’s a web for everyone which includes both accessibility issues
and internationalization. And it’s a web on everything, it’s a web of devices, it’s a web that can be on mobile, it can be on watches, all sorts of different technologies. That mission carries on and some of the same design
problems carry on with it. This is a radical shift in power from creators to consumers to audience. Audience now controls
the display of my content which wasn’t true on the printing press. If I’m designing a poster or a T-shirt or anything that’s going to be printed, I can control every step of the process from the colors and the fonts to what I’m printing on and what type of printing I’m doing. And when I ship a final product, the audience that I send it to
gets exactly what I designed and they see exactly what
I intended for them to see. On the web that’s just not the case. On the web the client
controls the display. And by client I mean everything on the other end of the system. The people on the other end can choose their settings,
their default settings, they can add styles to my
site for their browser. Their device has some control over what it can handle
and what it can do. The browser itself also
affects the capabilities. There’s all these pieces
that have to get put together on the client side to display. And I don’t know all those variables when I’m writing an application. In reality we’re designing for
an unknown infinite canvas, and we don’t have all the variables. Rather than designing with this control over exactly what we should ship, we’re designing for change and for movement and for adaptation. We know how to do this, this is not unfamiliar territory. We can make car seats that
move forward and backward so that different people fit. Seat belts do the same thing. We can broadcast color TV and watch it on a black
and white television because the technology understands how to degrade gracefully in these ways. Cascading style sheets are
built around the same idea. They’re first proposed in 1994 and then the spec is written in 1996, but they don’t actually appear fully in any browser until the year 2000. What cascading style sheets do, the reason for the cascade is to take all these different
sources of information, all these different variables,
and put them together. The cascade is a set of rules
for how these different styles are going to fit together
and override each other, and in the end the browser
takes all of those variables, puts it all together and comes out with a single final rendering style. And only the browser can do that because only the browser
has all that information. So as a designer I’m no
longer controlling the output, I’m suggesting and that’s why
CSS is a declarative language. That means that rather than describing, as we might in JavaScript, the steps to take to
recreate a specific outcome, I instead describe the
intent of my outcome. What am I going for? What am I pushing towards? And I’m trying to give the browser as much meaningful
information as possible, subtext and implications, so that the browser can
make smart decisions about what to do with those styles. That’s where things like Normal Flow, the way that block and inline
elements flow together, and relative units allow us to create these relationships in a meaningful way so that the browser can
make smart decisions. It’s an intentionally resilient system and resilient language where
everything fails silently, and we can actually see
that here again on his site. The hypertext markup language, parsers should ignore tags
which they do not understand, and ignore attributes
which they don’t understand of tags that they do. So even at the smallest level, browsers are supposed to understand everything they can and
ignore everything else, and that’s how we get this total backwards compatibility
where the early website is still available on modern browsers because everything is resilient, everything is backwards compatible. It also has to be intentionally
contextual for this to work. Everything depends on not only the size of the screen but the type of interface. How are you interacting with it? Is it a keyboard? Is it touch? And broadening out, is it a braille keyboard? Is it headphones? Are you listening to websites? There are so many different
interfaces that the same styles just wouldn’t make
sense across interfaces. And so context is very important to CSS. And that’s fundamentally
different from most languages. In JavaScript we try to isolate functions, and in CSS isolation doesn’t
actually make much sense if we’re looking at this in terms of the fundamental vision of device agnostic content. So really CSS is this presentation layer that we’re okay losing. That’s fundamental to the web that we can layer these styles on top but they have to be optional because some people are using the internet through systems where they
won’t see this presentation. And that gives us right
away graceful degradation and progressive enhancement built in. The whole thing is supposed to
fall apart in a graceful way. That’s how the web is designed. So when we’re looking at this meme, we’ve over-defined some
things for how CSS works. CSS is going to work
best when we don’t define both height and width at the same time, or in this case define a
font size that is so large that the font overflows
the width that we’ve set. It generally works better
if we use min-content or something that is going
to respect the content that it’s flowing around because the browser has to
make these decisions for us. We don’t have to get that visual overflow. There’s many different
settings that we can use. Overflow visible is just the default because CSS is designed
to not lose content, to not cause harm. In order to not cause harm, we show what overflows by default. And we can see that that’s different from a program like InDesign where here I had to use two separate boxes in order to get that same image. Because in InDesign when I overflow a box, and let’s actually take that slower, things simply disappear completely. I don’t think that that’s a
better system for the web. That doesn’t seem like the
sensible default either. But they’re trying to
solve different problems. InDesign knows that you’ll come back in and make some adjustments, whereas in CSS the browser has to make the adjustments for you. As a playwright, this stands out to me as something that I do in another field. So when I write a script,
I know that the actors are going to say the lines that I wrote, and they’ll say them in the
order that I wrote them, and I can even mark it up
with who should say what. But when I write stage directions, I can say how I think the set should look and how I think the characters should look and how I think they should act. And I can say all these things but all of them are suggestions, and the production company is likely to make their own decisions and to throw out my stage directions and do something completely unique because they’re working
with different actors in different spaces under
different constraints and for a different audience. And it makes sense that the performance has to be updated to fit a new context. Like theater, CSS is contextual, and we can make those suggestions, but we can’t insist on the final design. CSS is intentionally different. It intentionally works this way. And to quote John Allsopp
from the year 2000 when CSS was first coming into browsers, he says, “Really we can think of this “as a bug of the system, “or we can think of control “as really a limitation
of the printed page.” It’s a limitation of print that I can control everything in it, and if I hand my poster
to somebody who can’t see, they have no ability to read it. And it’s a feature of the web that anybody can access it
from any different device. That’s actually a feature
and that’s something that we should embrace
and figure out how to use. And it doesn’t mean that the
problem is solved entirely, but CSS is designed around that idea, and that’s always going to be
a difficult problem to solve, but one that we have to do in a smart way that keeps the control on the client side. Because the web adapts to context, so even the modern web, even the most powerful applications, desktop style applications
on the modern web, when we put them on the web, the reason to do that is we
get universal device support, but the trade-off is we lose
control, and that’s a feature. And CSS is there to help us design for that audaciously unknown canvas in a way that no programmatic
language would be able to do. That’s why CSS is so weird. (upbeat music)

23 Comments

Add a Comment

Your email address will not be published. Required fields are marked *