ENTRIES TAGGED "css"
The DOM and human nature create some challenges
“Design by Committee” is rarely a compliment. Can the Web shift away from that model, retaining some order without falling into troublesome chaos?
Part of the excitement around the Extensible Web Manifesto was that it wanted to move the Web to more of an evolutionary model:
We aim to tighten the feedback loop between the editors of web standards and web developers.
This sounds great. Web standards have always been difficult, their universal goals making it difficult to bring together different vendors and even different standards organizations. Developers are impatient, and most of us have little connection to the kinds of reasoning that drive vendors, consortia, and yes, committees. Open source and similar models have taught us that many eyes are valuable, and small experiments seem less likely to break the Web than specifications that lurch the wrong direction.
Unfortunately, extensibility is not, as we learned from XML, a magical way to speed things up and make committees disappear. The rest of the Extensible Web Manifesto explains how it hopes to make this work, but the key piece is the very first item:
Focus on adding new low-level capabilities to the web platform that are secure and efficient.
Rethinking CSS delivery
After the improvements, I thought it was time to move on but PageSpeed Insights advised there was more work to do.
Here are the WebPageTest results from my last article:
Eyes Above the Fold
PageSpeed Insights has helpful tips on optimizing your CSS delivery. Their rules suggest inlining critical Above-the-Fold (ATF) CSS rather than keeping all the CSS as an external resource. In addition, any Below-the-Fold (BTF) CSS can be deferred until after the ATF content has loaded.
Decorating content may no longer be enough
Thousands of people invented it independently. Millions use it without thinking about a broader context. It’s time to name it so we can talk about it.
Transformation is changing the way we look at the balance between clients and servers, our approach to formatting and layout, and our expectations of what’s possible on the Web. As applications shift from transformation on the server toward transformation on arrival on the client, transformation’s central role becomes more visible.
These practices have been emerging for a long time, in many different guises:
- In the Dynamic HTML days, scripts might tinker with the DOM tree as well as modify CSS presentation.
- Transformation was supposed to be a regular and constant thing in the early XSLT plans. Stylesheets on the client would generate presentation from clean blocks of XML content.
- New data format options evolved at about the same time that Ajax emerged. JSON offered a more concise set of programmer-friendly content tools. Many apps include a ‘bind JSON to HTML before showing it to the user’ step.
- Template systems now run on the client as well as the server. In many systems, templates on the server feed data to the client, which applies other templates to that data before presenting it to users.
- The HTTP powering Ajax still created a long slow cycle of interaction. WebSockets and WebRTC now offer additional approaches for collecting content with less overhead, making it easier to create many more small transformations.
- Some developers and designers have long thought of the document tree as a malleable collection of layout boxes rather than a deliberately coherent base layer. Separation of concerns? A dead horse, apparently. Recent debates over CSS Regions highlighted these issues again.
Learning from "The Humble Border-Radius"
One of the best things I overheard at the Fluent Conference was (more or less):
“CSS live coding? I was like, that isn’t code. But then it was.”
Lea Verou had changed the mind of a skeptic.
CSS is not Turing complete (Update: Lea points out that I’m wrong about that), and I’ve long been grateful that it wasn’t designed as an imperative programming language. It can be too much code for designers, too little code for programmers, and yet it’s code.
I think about the graphics work I tried to do with shapes and sprites and assorted kinds of vectors over the years, and then watch this keynote. Even with the glitches and coming improvements she notes, it’s clear that whatever tools I was using at the time, they weren’t declarative enough. (I’d also just seen this JSFest talk on CSS box-shadow by Vince Allen, so I was looking forward to more CSS graphics magic.)
One source does not fit all
Like a lot of web teams, O’Reilly’s web group has increased its focus on using global components to better scale maintenance and optimize workflow. From a load-time measurement perspective, our performance ratings stay near benchmarks. However, after a recent analysis, using metrics other than load time, we found that our global efforts may have sacrificed performance on a handful of highly visible and heavily visited web pages.
Identifying the popular pages, we sought to improve the use of global components with server side logic, regex, and asynchronous loading. After re-measuring these popular pages, we arrived at faster load times with improved perception of speed.
Taking a closer look
After the Velocity 2014 site was produced, I got the following results from PageSpeed Insights and Webpagetest (WPT) while testing the homepage. These results are close to our average benchmarks for load time but revealed further elements to fix.
PageSpeed Insights pointed out render-blocking scripts and advised how I can optimize CSS delivery. WPT provided a visual UI to demonstrate the user’s perception of speed and gave me an average load time and start render time. Together, these tools gave many angles of approach to improving load times and the perception of speed.
Even though the load and start render times from WPT weren’t bad, the PageSpeed Insights score demonstrated that further improvements could be made.
On both front and back end, the Web challenges conventional wisdom
The Web is different, and I can see why programmers might have little tolerance for the paths it chose, but this time the programmers are wrong. It’s not that the Web is perfect – it certainly has glitches. It’s not that success means something is better. Many terrible things have found broad audiences, and there are infinite levels to the Worse is Better conversations. And of course, the Web doesn’t solve every programming need. Many problems just don’t fit, and that’s fine.
So why is the Web better?
Efficient, reusable markup reduces development work while boosting page load time
Optimizing your markup can have a substantial impact on your site’s page load time. Bloated HTML leads to bloated CSS, and vice-versa. For example, during a semantics and reusability template cleanup, I was able to significantly reduce the file size of site-wide HTML, CSS, and stylesheet images.
I achieved this by simply renaming existing elements to have more semantic meaning and then removed unnecessary elements in the HTML (also known as divitis) to focus on reusability. Later in the same cleanup effort, I was able to cut CSS by 39% by removing unused selectors, combining and condensing styles, and normalizing the colors used across the site.
Recognizing the people who've built the Web
The description is pretty simple, but I think includes a huge number of potentially great awardees:
We hope to hear about many ways people have “demonstrated exceptional leadership”. It may be standards, it may be coding, it may be explaining, it may be community, or it may well be something I haven’t thought of yet. What matters is that you can tell us why you think they should get an award.
CSS already making Web code more approachable
Last week, I wrote about the need to make programming, at least much programming, more accessible. I was thinking in terms of business processes, so spreadsheets and flow-based programming sprang to mind. Today, though, Jeremy Keith reminds me that on the Web, we already have much of that world in Cascading Style Sheets (CSS).
There are a lot of really powerful programmatic concepts that we could add to CSS, all of which would certainly make it a more powerful language. But I think that power would come at an expense.
Right now, CSS is a relatively-straightforward language.
I suspect some readers are scratching their heads, wondering why CSS is even being considered a language, much less why adding programming features to it would be a bad thing. If you think of CSS as a simple object-manipulation language, though, it fits pretty neatly into the sweet spot I described last week.