ENTRIES TAGGED "css"

Can We Extend the Web Cleanly?

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?

The Manifesto

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.

Today, most new features require months or years of standardization, followed by careful implementation by browser vendors, only then followed by developer feedback and iteration. We prefer to enable feature development and iteration in JavaScript, followed by implementation in browsers and standardization.

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.

Read more…

Comment |

Tailoring CSS for performance

Rethinking CSS delivery

In my last article, I demonstrated how improved performance and a lower PageSpeed Insights score were accomplished by removing unnecessary external JavaScript and CSS requests. YepNope was also used to manage the asynchronous loading of external requests.

After the improvements, I thought it was time to move on but PageSpeed Insights advised there was more work to do.

vel-after-js-removal-pagespeed74

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.

Read more…

Comment |

Transforming the Web (through transformation)

Decorating content may no longer be enough

Photo: http://commons.wikimedia.org/wiki/File:Metamorphosis_frog_Meyers.pngThousands 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.

“Templating” doesn’t quite capture what’s happening here. While templates are often a key tool, describing that tool doesn’t explain the shift from server to client. Templating also misses the many cases where developers are using plain JavaScript to insert, delete, and modify the document tree in response to incoming data.

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.
  • Ajax opened the door to shell pages, apps that set up a UI, but get most of their content elsewhere, using JavaScript to put it in place.
  • 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.

Read more…

Comment |

Yes, CSS is code

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.)

Read more…

Comments: 3 |

Tailoring for performance

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.

vel-before-js-removal

Even though the load and start render times from WPT weren’t bad, the PageSpeed Insights score demonstrated that further improvements could be made.

Read more…

Comments: 2 |

Go node without code

Command line tools improve development workflow

At Fluent 2013, O’Reilly’s Web Platform, JavaScript and HTML5 conference, Adobe Community Manager Brian Rinaldi showed off ways Node makes possible a new world of utilities, showing JavaScript developers a toolkit they will want to integrate into their workflows.

In his talk, Go Node Without Code, Brian talked about the many ways Node and the npm ecosystem of JavaScript packages can help front-end developers, even if they don’t want to leap to server-side programming.

Tools Brian explored include:

  • UglifyJS, the “JavaScript parser / mangler / compressor / beautifier toolkit” [at 02:00]
  • Less, “for building CSS, but offers a lot of features you don’t get in straight CSS” [at 06:15]
  • Grunt, addressing the “just adding steps to my workflow” problem. [at 9:09]
  • GruntIcon, “A mystical CSS icon solution” [at 18:18]
  • Automaton, a “task automation tool” [at 25:00]
  • HTTPster, a dead-simple “local static development server” [at 30:05]
  • The slightly more configurable Node-static [at 32:00]

You will need to be familiar with the command line for a lot of it – if you’re not, it’s a great time to learn!

If the Web Platform, JavaScript, and HTML5 interest you, consider checking out our growing collection of top-rated talks from Fluent 2013.

Comment |

Web application development is different (and better)

On both front and back end, the Web challenges conventional wisdom

The Web became the most ubiquitous distributed application system because it didn’t have to think of itself as a programming environment. Almost every day I see comments or complaints from programmers (even brilliant programmers) muttering about how many strange and inferior parts they have to deal with, how they’d like to fix a historical accident by ripping out HTML completely and replacing it with Canvas, and how separation of concerns is an inconvenience. Everything should be JavaScript.

(Apologies to Tom Dale, who tweeted a perfect series of counterpoints just as I was writing. He has visions of rebuilding the rendering stack in JavaScript, but those tweets are not unusual opinions.)

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?

Read more…

Comments: 3 |

HTML and CSS performance

Efficient, reusable markup reduces development work while boosting page load time

[Ed note: This is the third in a series of posts on web design and performance. You can see the first two posts here and here.]

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.

site-cleanup

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.

Read more…

Comment |

Please nominate for the web platform awards

Recognizing the people who've built the Web

This March, we’ll be announcing the Web Platform Awards at the O’Reilly Fluent Conference. Fluent is all about JavaScript, HTML5, CSS3, and the best practices that make up the Web Platform, and we’d like to recognize the people who’ve made it the powerful ecosystem it is today.

The description is pretty simple, but I think includes a huge number of potentially great awardees:

The awards recognize individual contributors who have demonstrated exceptional leadership, creativity, and collaboration in the development of JavaScript, HTML, CSS, and the supporting Web ecosystem.

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.

Read more…

Comment |

Declare and It Happens

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).

“Being a programming language” was never a goal for CSS, which pushed the opposite direction in contrast to Netscape’s JavaScript Style Sheets. There are moments, of course, when developers wish otherwise, and the SASS and LESS preprocessors can give them more functionality. As Keith points out, however:

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.

Read more…

Comments: 7 |