Category: CSS

Unlock the next era of UI development with Polymer

Video from Google I/O 2014

Polymer is a new type of library for the web, built on top of Web Components, and designed to leverage the evolving web platform on modern browsers.

Entering the multi-screen era means rethinking how we build our applications. Producing a few PSDs doesn’t cut it anymore, we have to start seeing the things we design as components within larger systems. Join us to learn how to use Polymer to revolutionize your design process. With these new tools we can create the UIs of the future, and shorten the time between concept and reality.

source

Webcomponents.org

Web Components are a collection of standards which are working their way through the W3C. They enable truly encapsulated and reusable components for the web. And if you think HTML5 changed the web, wait to see what Web Components will do. (source: customelements.io)

WebComponents.org is where pioneers and community-members of the Web Components ecosystem (like Polymer, X-tags, and other interested parties) document web components best practices so that others can follow the same path instead of needlessly striking out on their own.

web-components-org

source

Tablesaw: A Flexible Tool for Responsive Tables

Following lots of early experiments with responsive tables, we came to the conclustion that any approach to “responsive tables” needs to address a few key points:

First and foremost, it needs to flexibly reformat table layouts in a way that’s suitable for compact screens, without removing any data outright from the markup

tablesaw-stack

If any data are hidden by default, it should provide some method to let users to access that information (we can’t make assumptions about what data will be relevant based on the screen size)

Tablesaw lets developers apply rules to determine display presentation layout, data priority, and adds a range of extensions to give users control over data display and interaction.

source

Foundation: A New Grid

New grids for new experiences and applications. Highly recommended.

Using a Hammer When You Need a Nail Gun
Building things is hard. Building things with the wrong tools is even harder. The web has changed over the past several years and will continue to rapidly change. We’re racing away from an advertising web that discusses things to a web of doing and creating things.

The shift from native apps to web apps has begun. Yet, we’re using the wrong tool to build these web apps — hacking away at frameworks and grids meant for marketing sites. In other words, we’re still swinging a hammer when we could be shooting a nail gun.

A 960° Look at the Grids of Internet Past
Nearly every grid system today is based on the same principals of the 960 Grid — a grid nearly a decade old — that has affected how nearly every site is coded today. A model that uses rows and columns, set to 12 or 16 numbered increments, to create nearly any layout.

The 960 Grid allowed for rapid prototyping on the web and lowered the learning curve for designers to wrangle code. It gave us the start. And more powerful frameworks emerged offering UI libraries, predefined styles and JavaScript capabilities, yet the same grid style remained.

Over the last three years, Foundation has taken this grid style and made huge improvements in functionality. We were the first framework to go responsive with the grid and also the first to take the grid mobile-first. We’ve built upon it, adding offsets, source ordering right-to-left options and block grids. We’ve even harnessed the awesome power of Sass to have powerful Mixins that allow designers to build fully semantic markup with little-to-no presentational classes.

These things are all great, but they were still built for a different type of web experience.

Web Apps are the Future
As we said above, the web is changing. We’re transitioning to a more app-centric web. It’s time our grids followed suit.

source

CSS at Groupon

This post was inspired by the recent wave of people sharing info about their CSS: Mark Otto at Github, Ian Feather at Lonely Planet and Chris Coyier at Codepen.

About two years ago I was working on a redesign of Groupon’s consumer website (which was later scrapped) when I was asked if I wanted to work on our internal tools team. “You won’t have to support Internet Explorer,” they said.

* Cue chorus of angels *

As Groupon had been experiencing exponential growth, many of our “internal tools” consisted of a bunch of Google Docs and things scribbled on cocktail napkins. The internal tools team was tasked with streamlining those processes. We had a half dozen or so dev teams working on different tools supported by just two designers. The challenge we faced was how to quickly crank out designs for these tools without having a horrible mishmash of CSS.

At first we debated the merits of using Twitter Bootstrap, which had just started gaining popularity at the time. We also looked at Zurb’s Foundation. Eventually we decided that we would roll our own CSS framework in order to keep things light and consistent with our designs. We called it Toolstrap (Bootstrap for Internal Tools).

source