Enabling the creation of maintainable sites and apps that look great across a variety of different devices and contexts.
Choose your Learning Path. Our new Learning Paths will help you get where you want to go, whether it’s learning a programming language, developing new skills, or getting started with something entirely new.
CSS’ declarative model can be uniquely efficient, but requires an understanding not only of the features you want to use but the approach you want to take in decorating a document tree. That means understanding the document tree (and there may be many variations as you apply the same style sheet to multiple documents), the selectors used to identify points on the tree, the cascade that resolves conflicts among selectors, and the properties applied to that tree. Of course, the properties interact with each other and a shared model, so you’ll need to understand how the properties how to make those interactions produce your vision.
:focus'ing on users.
Editor’s note: The author would like to acknowledge her co-author, Brian Kardell, who contributed many insights to the ideas presented here, along with a substantial number of the words.
Web developers and web standards authors alike strive to live up to the promise of “universality” — the idea that the web should be available to all. This concept drives many innovations in web technology, as well as being fundamentally built in to the philosophy of the open standards on which the web is based.
In order to achieve this, we frequently find that having some carefully chosen information about how the user intends to view the content (a concept we’ll refer to in this article as “user context”) allows web developers to create more flexible and useful user experiences. In this post, we’ll lay out a case that it’s time to expand our view of user context to include the concept of modality (how the user is interacting with the page), but before we flesh that out, let’s take a look at “user context”.
Learning from the Fluent Conference.
At Fluent 2015, we brought together a variety of stories about front-end engineering – some technical, some social, some more intricately intertwined.
From the very first day, it was clear that React was the big technical story of the conference, taking the place that Angular (which is still clearly important!) had had the previous year. Tutorials and sessions were busy, and I kept hearing conversation about React. Sometimes it was “what is React supposed to do?” but other times people were talking about exciting corners of React Native or techniques for integrating React with a variety of frameworks.
React makes me happy because it solves the problem a lot of people didn’t quite realize they had. Suddenly they are very enthusiastic about stuff that used to be really annoying. The Document Object Model (DOM) has been the foundation of most of the interactive work on the web since 1998, but it wasn’t very much fun then. As developers really get deeper into these things, the DOM has not exactly been a crowd-pleaser. In some ways React is a wrapper for the DOM, and in many ways it’s a just a better way to interact with the document tree.
How much do you need to know?
I expected that CSSDevConf would be primarily a show about front-end work, focused on work in clients and specifically in browsers. I kept running into conversations, though, about the challenges of moving between the front and back end, the client and the server side. Some were from developers suddenly told that they had to become “full-stack developers” covering the whole spectrum, while others were from front-end engineers suddenly finding a flood of back-end developers tinkering with the client side of their applications. “Full-stack” isn’t always a cheerful story.
In the early days of the Web, “full-stack” was normal. While there were certainly people who focused on running web servers or designing sites as beautiful as the technology would allow, there were lots of webmasters who knew how to design a site, write HTML, manage a server, and maybe write some CGI code for early applications.
Even as the bust set in, specialization remained the trend because Web projects — especially on the server side — had grown far more complicated. They weren’t just a server and a few scripts, but a complete stack, including templates, logic, and usually a database. Whether you preferred the LAMP stack, a Microsoft ASP stack, or perhaps Java servlets and JSP, the server side rapidly became its own complex arena. Intranet development in particular exploded as a way to build server-based applications that could (cheaply) connect data sources to users on multiple platforms. Writing web apps was faster and cheaper than writing desktop apps, with more tolerance for platform variation.
An experiment in containing stylesheet complexity.
This post is part of my personal notes about the benefits currently specified in Shadow DOM, but contentious and held up in committee. We’ll work it out in standards, I’m sure — but given the number of things Shadow DOM was addressing, it may still be several years until we have solutions widely implemented and deployed that solve all of them. This has me doing a lot of thought exercises about what can be done in the meantime. The following reflects one such exercise: specifically, what would it mean to solve just the styling end of this on its own. Warning: it may be mildly crazy.
The Pandora Box
CSS works really well if you can follow good patterns and have nice rich markup. It lets you define broad rules and inherit and override selectively, and if used well it cleanly decouples a separation of concerns — it’s pretty elegant actually.
On the other hand, in the real world, things are often not that simple: until pretty recently, HTML wasn’t especially expressive natively, so we worked around it — many times on our own by adding classes like “article.” But, there wasn’t a standard. Likewise, our ideas about the patterns we should follow or best practices continues to change as we gain new powers or spend more time with the technology. Of course, there are a vast number of cases where you’ll just go and upgrade your philosophy and be the better for it, but there are a number of times when this just isn’t an option. This is sometimes referred to in standards circles, less colorfully, as “the composition problem.”
When it comes to these sorts of cases, quality and philosophy are inevitably mixed and not entirely in the control of any one team. In these sorts of cases, CSS selectors are kind of like live hand grenades, it’s just way too easy to do damage you didn’t intend to do because it requires a level of coordination of approach which is, for business reasons, highly impractical. And so you try really hard to analyze the problem, get the right select/cascade/descend/inherit/specificity, pull the pin, lob it into the pages and… hope. Frequently, all hell breaks loose. The more you mix it up, the harder it gets to reason about and the more our stylesheets explode in complexity. You’ve opened the proverbial Pandora’s Box.
Avoid problems associated with a quick fix by creating a stable workflow.
A long time ago (circa 1999) a creative director tried very hard to convince me how great working in print design was compared to web design. One afternoon before a big event for a Fortune 100 company, she showed me an invitation her team had been working on for the past 2 weeks. It had folds, panels, and colors that would wow anyone. It had just come back from the printing press and she was excited to show me how amazing it was. She began reading me the big invitation title first — to her horror she found that there was a spelling mistake on the cover. The entire set of 10,000 invites would have to be thrown in the trash and at the cost of $15,000 — that would be hard mistake to swallow. She was speechless.
My response to what had just happened was this…”That’s why I like designing for the web. I would have been able to change that spelling mistake in 5 minutes…”
At that point in the web’s history anyone with a web connection, an FTP program and a text editor could edit HTML code on the fly. It really was the wild wild west of web development — this was the web’s best and worst attribute. For many young developers and designers it gave us a chance to create, edit, and publish web pages as fast as we could code them.
Uncertainty is a feature, not a bug.
After decades of work on programming, we finally got a development environment with massive reach and tremendous power. Somehow, though, the web isn’t centered on a comprehensive programming environment. The web succeeded with a (severely) lowest-common denominator, specification-driven approach that let it grow with time, technology, and multiple communities, across multiple platforms.
Almost two decades ago, I was all excited about Java. Write applets once, run anywhere, with libraries to make sure it all came out the same wherever anywhere might be. Java is still a powerhouse, but it all worked out differently than I expected. Even in Java’s early years, before the Java news was filled with security bulletins, applets felt like a strange mix with their surrounding web pages. Creating an applet demanded programmers to build every detail. Even with Java’s ever-improving libraries, creating a Java applet that did much was an intense experience focused on programming.
Java wasn’t the only comprehensive way to build web apps, of course. Flash demanded programming, but its values always incorporated design, action, and well, flash, in ways that meshed well with the way people built sites. Flash kept growing and growing before its ecosystem took a fatal hit from the iPhone as HTML5 offered replacements for some of its key strengths. I mostly notice Flash these days because it asks me to update it regularly and because pages tell me when it’s crashed.
Compared to either of those rich environments, web technology is a tangled mess. The early web was functional but unstyled, with no behavior beyond navigating among pages. That? That would dominate client-side computing? Read more…
Site speed is essential to business success, yet many pages are getting bigger and slower.
Earlier this year, I was researching online consumer preferences for a client and discovered, somewhat unsurprisingly, that people expect web sites to be fast and responsive, particularly when they’re shopping. What did surprised me, however, were findings in Radware’s “State of the Union Report Spring 2014” (registration required) that showed web sites, on average, were becoming bigger in bytes and slower in response time every year. In fact, the average Alexa 1000 web page has grown from around 780KB and 86 resources in 2011 to more than 1.4MB and 99 resources by the time of the early “2014 State of the Union Winter Report.”
As an experiment, I measured the resources loaded for Amazon.com on my own computer: 2.6MB loaded with 252 requests!
This seemed so odd. Faster is more profitable, yet companies were actually building fatter and slower web sites. What was behind all these bytes? Had web development become so sophisticated that all the technology would bust the seams of the browser window? Read more…
A new mantra for your next (programming) meditation session.
You might feel fine.