Category: HTML

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

How we make RWD sites load fast as heck

RWD: Responsive Web Design

In the past year I’ve spent a lot of time researching page loading performance, both for our ongoing client work here at FG and for my soon-to-be-released book for A Book Apart. In the process, I’ve reaffirmed my belief that we don’t need to compromise the well-known benefits of a responsive layout in order to make our sites load as fast as heck.

In this post, I’ll outline some recent observations and approaches to delivering sites for speed and broader access, and link out to various tools we are using to facilitate our approach. All of the tips mentioned in this post are implemented on this very site, and we’ve tested them heavily to ensure that they’re working as well as they can.

source

Site Optimization Case Study: Responsive Web Design (RWD) Bloat Part II

Also see Part I. Tools and techniques to optimize and improve speed of responsive web sites.

Building off of my previous post on RWD Bloat, the following is step-by-step how I made my site faster over the course of a few days. For the purposes of this test, I’m hyper-focused on my Speed Index numbers for my Home and Article templates (the 2 most visited templates of my site).

I’ve nearly doubled the speed of my site. Not too shabby for a responsive design with jQuery, two webfonts, third-party ad, third-party comments, all while being tested on a 3G Connection. My Speed Index on Cable is currently 400~414 for both templates.

Hopefully that helps underline the point, as Scott Jehl so eloquently puts it , “How we load assets matters just as much as how many assets we’re loading.”

source

Grid Style Sheets for Constraint-based Layouts

iOS-like Auto Layout applied to browser displays. Based on the same constraint algorithm.

CSS manages features like color and font selection quite well. But there’s an important fault at the core of CSS that rears its head when designing the actual layout of pages. Despite its declarative syntax it merely describes how a page will fit together, almost in an imperative way. An element will have so many pixels of padding, be a certain width, be floated right – but this doesn’t say anything about where it fits in relation to its neighbours and the page as a whole. It certainly doesn’t account for where it should be displayed on different sized screens, as this requires multiple definitions for a selector with media queries controlling the breakpoints.

Fortunately, there’s a better way. The solution is nothing short of the drastic solution of bypassing the entire browser layout engine, and replacing it with one that doesn’t suck. This way, we get to define what we want the layout to be, not how the layout should be constructed…

The solution is a JS library Grid Style Sheets, and it’s available right now for use in today’s browsers. It’s an implementation of the Cassowary constraint solver algorithm – the very same one used by Apple in its recent Auto Layout tooling – and it feels like something from the future. Note that this has nothing to do with traditional Layout Grids as used by designers, and available in CSS form – The Grid is the startup who has created GSS.

source

The Future of Javascript Animation with Famo.us

After much anticipation, hype and controversy, Famo.us is finally being released today for limited public consumption. When I first saw the Famo.us webpage in late 2012, I was intrigued by what I thought was impossible to do on the web. Suspending disbelief for a moment, I began to wonder what code would look like if the animation magic I was seeing were suddenly possible to write in JavaScript.

Ultimately, developing in Famo.us is straightforward; however the concepts do differ from standard web development. In this primer I’m going to go over why Famo.us is different, the basics of writing Famo.us apps, and a list of resources to help you become a guru.

These days, web browsers apply hardware acceleration to certain CSS properties. When rendering a typical webpage, you can gain the benefits of this acceleration if you trigger CSS based animations. The browser still has to work hard to recompute the layout of your page from a change to the DOM. In practice this means that if your app is making changes to the DOM that require the browser to re-layout your page, you’ll lose hardware acceleration and generally see inconsistent and slow performance.

Famo.us is built around a neat idea: by directly using the CSS matrix3d transform in combination with the window.requestAnimationFrame function, you can describe the complete layout and animation of your app in a way that’s hardware accelerated with consistent performance.

Surfaces

The basic building blocks of a Famo.us application are Surfaces. Surfaces are simply divs that contain HTML. They make up your app at the most granular level and often do not contain sophisticated layout or content that you want to animate within the surface. A typical app is built out of many surfaces containing mostly text or images and targeted with basic visual CSS.

The Scene Graph contains your app’s surfaces along with Transforms. Transforms are used to position surfaces and thereby layout the UI of your app. They are also used to describe animation.

source