First, Do No Harm

• It’s a lot to cover,
• And we’ll move pretty quickly sometimes
• Skimming past some demos that you can come back to,
• But then really digging in where it makes sense

• Don’t need to memorize everything
• Understand the mental model, what’s possible
• And I want to leave you with resources
• You can come back to on your own time

• Feel free to stop me if you have questions
• Q&A at end of each day
• I can’t see all of you, so you’ll need to interrupt me
• (I don’t mind)

• Any questions before we start?

ok, here we go…

• We’re talking about the origins of the web,
• But especially design on the web, using

• Håkon Lie, 1994
• email, still archived online

• not the only proposal for styles on the web
• not the first
• solves a major problem for the new platform

• not technical
• but philosophical
• political, like all decisions we make
• designing a new platform or interface

• first web browser
• Hypermedia WWW Browser and Editor
• CERN
• NeXt machine
• graphic interface

You can’t make a web that’s world-wide, by saying it works on my machine, and everyone else is an edge-case.

• Nicola Pellow
• Line Mode browser
• text-only
• no install
• any device with an internet connection

• Mission statement of W3C

• includes devices without screen
• or screen readers
• read the screen (a combination)

• If we really want this to work
• Everywhere for everyone

• leads to some interesting constraints
• documented on the original website
• (still online)

• browsers ignore code they don’t understand

[DEMO]

• individual attributes
• entire HTML tags

• the code is optional
• the content is essential
• whatever else happens
• browsers should protect the content
• that’s why…

• we can still see
• first website on modern browsers

• modern website, on the first browser
• (this is an emulator you can play with)
• No css
• No images
• all the text is there

• limitation is more dramatic
• for graphic design
• to be a common language anywhere…

• The problem isn’t styles
• Early browsers all had built-in stylesheets,
• We think of these as browser defaults to override
• but they used to be the only styles available.
• They’re sometimes different from one browser to the next
• but they’re the same for any website we visit

• Even the text-only browser
• uppercase headings, space between paragraphs, etc

• This is not the way print works
• If we’re designing a book, we don’t get defaults from our printer
• We control everything…
• page size (static, forever)
• down to the inks used, and the paper to print on

• It just sits there
• The same was true for other digital formats at the time…

• PostScript around almost a decade
• page description language
• Like print
• describes a static page
• how big is it? where does each thing go?
• We set fonts, colors, etc.
• We have complete control, but…

• That control comes at a cost
• The page, print or PDF, is a static medium
• can’t adapt to context or preferences
• a limitation of the medium

• web is different
• even static sites aren’t static
• what we ship is not always what our audience sees
• styles must adapt to situations…
• the web is responsive to context

• Not just the width of the viewport

• user needs & preferences

• device interfaces

• changing capabilities over time

• And often unpredictable content
• Changing all the time
• All of these variables, because…

• We’re not alone here
• We’re part of an ecosystem
• Our decisions impact other people
• And on the web, we don’t get final say

• We’re collaborating with browsers
• (instructed to ignore us)

• Also the people who interact with our sites
• (super cute in their handy tool belts)
• On their chosen devices
• (with varying capabilities)
• And we’re also collaborating with…

• aliens 👽
• Maybe, who knows?

• They’re probably just trying to get home.

• So we’re here, supposed to do…
• (slide)
• It’s absurd

• Under those constraints,
• design seemed impossible, but…

• No one was happy with that outcome
• When every site looks the same
• That’s boring for both authors and users

• Turning point, 1993
• Mosaic added image tag to HTML
• Before web standards
• web styles suddenly possible
• put everything in an image, and it never changes
• Just like print design!

• or it doesn’t show up at all
• and we lose everything that makes HTML special
• Can’t protect structured content in an image…
• If it doesn’t load, it’s lost

• A real risk to the platform
• (slide)

• And so we get a rush of proposals
• around 1993 and 1994
• trying to save the web from images!

• It’s time to take HTML to the max!

• Pei Wei’s Viola browser
• Was the first to allow custom style sheets for a page
• About a year before CSS was proposed
• It has familiar selectors, nesting, property-value pairs,
• And even inheritance
• They all have inheritance…

• Robert Raisch’s ‘easily parsable format’
• Was proposed even a few months earlier
• I assume he means parsable by machines?
• Because I can’t parse it, I had to memorize the first few lines.
• You can see the default selector there,
• We’re setting our default fonts in the fo function
• Family=times, spacing is proportional, size 14,
• and then ‘we’ is ‘me’, which…

• I don’t know,
• Sounds like a Beatles song?
• John Lennon had a lot to say about web typography

• But Robert is clear that these styles are only suggestions!
• Even the times font-family
• doesn’t mean we get the ‘times’ font specifically,
• it just means we want something like times,
• a serif font!
• And he repeats this phrasing…

• Over and over,
• We’re not writing rules,
• but suggestions or hints about behavior.

• Sometimes all-caps
• hints and suggestions which might not be used.
• And the other proposals pick this up…

• Jon Bosak’s
• Hints that will degrade in a controlled way
• Or, with CHSS…

• We can allow the author to attach style hints

• Hints that the browser may or may not use

• Authors should have stylistic influence,
• without resorting to page description languages
• without giving us full control
• Use the same resilient logic as HTML…

• browsers ignore css that they don’t understand
• We don’t get a blank page with an error message,
• We get the content with default styles.
• Always protect the content!

• This becomes another design principle of the w3c
• content should be viewable and accessible by default
• Which is why…

• The default overflow is visible
• if we get so cocky
• that we try to shove large text in a small box
• The browser will try to bail us out
• Not because it’s the best-looking solution
• but because the web is unpredictable
• and browsers prioritize content over style
• That’s a good thing!
• What’s the alternative?

• InDesign doesn’t even worry about accidental overflow
• The whole word just disappears!
• But that’s fine, because we can fix it
• before we hit print,
• and it will stay fixed forever

• Unchanging
• Unaware of context
• Unable to adapt
• By giving up some deign control

• We allow the web to carry our designs
• Farther than we could ever go alone

• Because we’re not alone,
• While CHSS wasn’t the first stylesheet proposal,
• It didn’t invent selectors, or properties, or even inheritance
• It was the first to suggest an equal collaboration

• Designed to soften the tension
• Between the author and the reader

• Authors want to show their creativity and branding,
• with a distinct look and feel,
• make their document visually interesting.
• But users will have preferences,
• styles that they like better (or even require)
• like larger text or dark mode,
• and sites to respect those preferences!

• We do that by allowing everyone to contribute styles
• Written in the same language

• Each of us providing
• our style hints as declarations,
• a property and a value

• We can group those together,
• and add selectors
• forming rule-sets…

• Which can be attached to an HTML document,
• Giving us…

• An ordered list (or ‘cascade’) of stylesheets
• all applied to the same web site,
• But not coordinated…

• Remember, anyone can add styles to the page
• So, of course, this leads to conflicts!…

• We have any number of declarations
• coming from different sources
• likely applying different values
• to the same properties, on the same elements!
• So what now? What background should we apply the the button?
• The last one? Who gets to go last?
• Should we…

• Some way to thunder-dome our declarations
• And choose a single winner
• Two styles enter, one style leaves

• The simplest way to choose a winner,
• We can let each declaration override the previous one
• Until there’s only one left
• Last takes precedence
• We’ll start there, but…

• But someone has to go first,
• so we’ll start with…

• The browser, or user agent
• providing legible defaults
• That’s essential!

• This email archive doesn’t add any document styles,
• But the browser is providing some!
• Let’s see what happens when we remove those.
• [demo]
• * { all: initial; }

• You can’t render text without styling it somehow!
• So CSS provides…

• Several layers of ‘default’
• The specification defines
• An initial value for each property
• Display inline, background transparent, and so on

• The initial value for display
• is always inline!
• Doesn’t matter what element we’re talking about
• Body, section, div, span…

• Even something hidden like the head or title element
• Would get display:inline by default
• If the browser didn’t come along and set…

• display:block and display:none
• everywhere we expect it

• They also add things like
• 8px margin on the body
• Link colors and underlines
• Heading styles, large bold text
• Space around paragraphs and lists, etc

• These are the user agent styles
• And they apply to every site on the web
• With only minor differences between browsers

• After browser defaults
• Users apply their preferences

• Originally using CSS syntax as well

• Safari still supports this option
• In the settings panel, upload a stylesheet

• Other browsers have mostly switched
• To limited preference settings in a graphic interface

• The details are different
• But the results are the same
• Users get to set some default preferences
• That are applied to every site they visit

• And to be clear,
• When we talk about ‘users’ or ‘readers’
• on the web…

• We’re talking about all of us
• We all use the web
• And I think it’s safe to say
• We spend more time using the web
• Than we spend building it

• And we’re all allowed to have preferences!
• Not just light mode or dark mode,
• But fonts, font sizes, all of it.
• I used to worry as a dev
• “but I’ll see something different than the user”
• That’s the point! People might see something different!
• Having a unique setting is a great way to remember that

• Finally, ‘document’ or ‘author’ styles
• (also us, making stuff for the web)
• We come last

• And so we get the highest priority,
• Last takes precedence, remember!
• These are called the ‘cascade origins’
• We override the user preferences
• Which override the browser defaults

• Which is a lot of power for us to have!
• Sometimes we’re not even paying attention
• Or we throw a fit…

• And stomp around force-choking everyone in our way
• But Håkon was clear…

• That user should have the last word
• When it really matters!

• This has also become a W3C principle
• Always put user needs above all

• So the original proposal included
• A percentage next to each declaration
• Expressing how important that style is

• And if the user requests 64% control,
• It doesn’t matter how much we want,
• This isn’t winner-takes-all,
• It’s first-come-first-served
• And there’s only 36% remaining influence for us…

• And the result is a weighted average of our styles!
• I wanted blue, but you asked for red,
• So here’s the purple no one asked for!
• People immediately pointed out how this could go wrong
• And how hard it would be to average other values like fonts

• Although I wish we had tried harder on that one

• I honestly love this final diagram that Håkon provides
• ASCII art of a graphic interface with range sliders
• So users can fine-tune their design
• Live-mixing the relative weights of every declaration

• It was simplified into a binary option
• 0% by default, or 100% with the important flag…

• Important styles generate three new origins!
• They always win over normal styles,
• But now we go in reverse order –
• Authors first, but then user preferences
• And the browser plays cleanup

• It’s a mirror universe where
• All our evil twins have goatees

• Yes, browsers defaults are often important

• And users can set important styles
• Using CSS in Safari
• Or a checkbox in the Firefox settings

• Importance doesn’t change specificity
• It changes the origins
• And the priority of origins
• The purpose…

• Is not for fighting each other
• In big teams who can’t agree
• Or angrily trying to override
• Styles we wrote last year

• The purpose is for users and browsers
• To protect style from future origins
• Someone that might come along later…

• That’s us
• Importance exists to
• protect our users from what we might do!

• But the way our origins (normal and important)
• Are isolated together…

• We start to think
• We’re the center of the universe

• When we’re really just one pale blue dot
• In the solar system of the cascade
• Which rotates around user needs!
• Fair, it’s what we deal with every day
• But we need to have perspective

• So now we’re not just dealing with
• some extreme unknowns

• Infinite diversity in infinite combinations

• But the browser is allowed to ignore us
• And the user can override anything we say
• There are two many variables,
• and everything we say is a suggestion…

• But everything we say is also a hint
• Telling the browser something about our intent

• CSS is a declarative language

• Some declarations seem simple,
• the width of a box

• While some are more abstract,
• wrapping text so it looks ‘pretty’
• (whatever that means)

• But even ‘simple’ declarations contain subtext
• What do we mean by a pixel?
• Should this box get smaller on a screen with higher resolution?
• How should it respond to zooming in and out?

• Are we setting the width of the content box?
• (so padding and border are added to our width)

• Or the width of the entire box,
• so padding and border are subtracted to get the content size?

• Maybe it’s not the width we care about exactly,
• that’s just the direction text flows.
• Are we trying to set the length of a line of text?

• Should it be based on the size of the font?

• Or maybe the box should re-size based on the contents inside?
• Their minimum or maximum size?

• Or based on context
• a parent element, viewport, or container

• Or some combination
• Like the minimum, of two values

• Everything in CSS based on
• constant back-and-forth
• context pushing in,
• (defining available space)
• content pushing out
• (taking up space)

• How do we ensure
• Our content will fit
• any container we put it in?

• We don’t have all the information, but the browser does
• So the most useful tools in CSS
• express this kind of abstract behavior
• let the browser work out details

• Like all design choices
• Our styles are contextual
• Properties often behave differently
• or not at all, depending on other properties

• As a result, CSS features tend to be intertwined
• Behavior is never isolated,
• And everything has side-effects
• We’re not doing functional programming,

• What we do is more expressive, like poetry
• Not describing the page in step-by-step detail
• but communicating high-level ideas through subtext
• Not just the result we want
• But the intent behind each choice

• Units are great at this
• (it’s why CSS has so many of them)
• On the surface 1em is sometimes 16px
• But they carry different implications
• And adapt differently in context

• Similar with layout methods
• We can sometimes get the same result
• using either flexbox or grid
• But they move differently at the edges,

• And our job, the entire reason we’re here
• Is not to make things look good on one device,
• Or in a single browser
• But to design for change
• And the only way we get there…

• Is by letting go of control…

• While expressing ourselves clearly
• Providing hints and suggestions
• Which the browser can adapt…

• to handle new and unexpected situations

To me, this meme perfectly captures what is actually awesome about CSS – and how we can go wrong by taking too much control without considering the consequences. So how can we lighten our grip here?

[demo] change to use intrinsic sizes

• This is our job as designers, design engineers
• Not forcing everyone into a singular experience
• But setting up the circumstances for communication
• In an unpredictable world,
• adapting to the incongruities of human experience

• We’re not alone on this platform
• and everything about CSS
• is built around that political vision

• Respect the user

• Protect the content

• Do no harm