My notes (and thoughts) from CSSconf 2014

1-style-guide-driven-development.md

Style Guide Driven Devleopment

by Nicole Sullivan

Problems:

• lots of CSS (91% unused on a standard page)
• really difcult to work with
• layout profiliferation (~7 different layouts that were not very different...)
• partials in partials.... for just the sake of having partials
• jQuery soup - custome one-off widgets everywhere

Live stylleguide: https://console.run.pivotal.io/style_guide
(generated using with http://trulia.github.io/hologram/)

Initially did not try to make the "most optimal system", just a system which you can iterate over.
The goal was to make reusable components that folks just pick up and go.
Current issue with the styleguide is that is is getting difficult to find stuff with in the categories and such.

Hypotheis: components should be hard, pages should be easy (a page has multiple components)

Documentation lives next to the CSS. The generator allows you to place Markdown into the coments of your CSS. Documentation includes sample markup to demonstrate what the HTML structure should be.

Process issues: who defines a "component"? Designer or devleoper?
Answer: it's everyones job. this was solved wtih close colaboration initally.

But what makes a "good component"?

• should be small (correct granulairty)
• fleixbility (what do you not know? particualrly width and height)
• low specificity
• encapsulation
• some level of predictability (ie: image always on the left, regardless of size)

Thanks that worked really well:

• design & dev pairing: awesome for nailing down animation and transitions
• color and spacing tweaks when didn't match the mockup
• general refinements

Results:

• no more view-specific CSS
• much easier to manage CSS code base (higher velocity in sprints)
• scope is eaier to determien (more accurate estiamtes)
• design is consistent (in place of looking at pages, would check the style guide)

The mentality changes...
berfore: what markup/CSS do I need to write? after: which compoennts is this page made of?

10-what-is-perspective.md

What is Perspective

by Evangelina Ferreira

slides: http://www.evaferreira.com.ar/perspective/

Perspective has 3 elements:

• point of sight
• horzontal line (or horizon)
• vanishing point

so how does this apply to CSS and web design?

using the transform property, we can change an elements perspective. (the origin is the center by default) we can also use transform-origin, to make that not the center. (basically move it anywhere around the element) --> but we can set the origin...outside of the element (aka: a 200px element, with a 400px 0 origin point). This causes problems.
We can solve these problems by adding a "father" (or parent) element.

.father {
  transform: perspective(200px);
  }

.child {
  transform: rotateX(90deg);
}

backface-visibility property indicates if a "back side" of an element should be visible or not (visible my default). This matters when rotating elements on a 3D plane.

Transforms can be mixed together (either rotations or translations, on the 2d or 3d plane).
ie:

.father {
  transform: translateX(45px) translateY(45px) translatee(45px)
}

is the same as...

transform: translate3d(45px, 45px, 45px)

webkit we needs prefixes (for now), Firefox does not, and IE dos not have 3d

11-parallax-performance.md

Parallax Performance

by Paul Irish

"clicking is a dicision, but scorlling is a continuation"
terminology:

• paralax: moving elemnets in the different z layers along the natural scorll pagce
• peeler: pealing of "layers" to reveal more content
• scroll jacks: taking over the natural scrolling behavriour.

When there is jank during scrolling... it means there is a "paint storm" going on (more paints than needed on the page). Paints are the thing that drop frame rate and make mobile devices feel laggy.

Things the browser can change super fast (using the transform CSS property):

• size
• position
• rotation
• opacity

How do we know if the user has scrolled? There are some events:

• touchstart --> delays everything
• mousewheel --> delays everything
• scroll --> adds some delay

Web Latency Benchmark: http://google.github.io/latency-benchmark/

Miniziing latency:

• bind callbacks on these events low in the DOM - avoid delegating to document because browsers always execute the handler
• bind late - don't bind stuff to non-visible elements
• unbind ASAP - if the element is gone, kill the handler
• avoid JS handlers, if you can't then debouce and bind/unbind is your friend! keep things trim.

Parallax with no JS? how is that posible? http://codepen.io/scottkellum/details/bHEcA/ <-- no paint storm!
The Kellum/Keith technique:

• each element is palced into their own layer (z-index)

sample sites: Tomato Can BLues (from the New York Times)
--> cool, but has some jank. why? they are modifying the top property as well as the transform. elimiante the top modification... and it would work better.

Carousel from DropBox
--> things are smooth, but the frame rate is still really high and the experience would suck on lower powered devices (looking at the inspector panel). so they ARE only modifying the transform...if we throw in a translateZ() in there... it moves these transforatmion to their own layer and the frame rate is a lot better.

translateZ() is on its way out as a hack, there is a new property called will-change which tells the browser what property you expect to change.

paralax stuff (not good for mobile, but performant on desktop):

• skorller
• stellar.js

for mobile only... either don't do it or use the Kellum/Keith technique

2-scaling-and-animating-svg-with-css.md

Styling & Animating SVG's with CSS

by Sara Soueidan

Most SVG-genrating tools out there (Ilustrator, etc) export "dirty" code with lots of meta-data that is unecesary.
Recomend using something like "SVG Editor" (http://petercollingridge.appspot.com/svg-editor?_sm_au_=iVVsLNMMV4NL7Qkr) to clean this up before styling and animating, or this: https://github.com/svg/svgo

You will also want to change the genric generated names to something more semantic that makes sense to you or your project.

A sub-set of the SVG properties are shard wit the CSS, not everything can be done in CSS since some are SVG only.

The styles can either be embded in the SVG file or externally.

SVG styles are stil subject to the cascade.

The recomended method of adding SVG's to the page is via the svg tag or the object tag if you want a fallback.
Animations are not preseved if you embed using an img tag, unless you're using an svg animation.

transform-origin for SVG elements are taken from position 0 0 (top left corner for the canvas), while with HTML elements it's taken at 50% 50% (center of the element). This mean we need to change the transform-origin when dealing with rotations on SVG elements.

To animate and draw an SVG path, you will need to know its final length. This is the trick to makeing it simple.
If you don't know it ahead of time, you can get it with JS (path.getTotalLength()).
Cool demo: http://blog.studio.gd/blog/id/6/how_to_use_svg_in_your_html_-_part_1-3

For mophing SVG paths, there is currenlty no way to do so with CSS. Recomendation is to use snap.svg (http://snapsvg.io/)

Some recomended reading:

• http://oak.is/thinking/animated-svgs/
• http://filamentgroup.com/lab/artifact-austin-svg-workflow.html

3-the-chroma-zone.md

#The Chroma Zone: Engineering Color on the Web by Lea Verou

RGB is a color system that is much closer to "the machine" and is not really intended to be human readable.
Hex colos are not much better... stil not intutive.
HSL (hue, saturation, lightness) was better. It's a bit more intutive and better than the others, but still not great yet. And HSL gives you the ability to apply SVG filters (with a decent notation) and they are combinable, so you can colorize images. (not supported in all browsers as yet, but the spec is there)

CSS blend modes = ability to use all the Photoshop blending mods in the browser. The spec is out there, but not ready for production as yet.

luminence !== lightness

spec is also working on a new keyword (or variale) named currentColor and is supported in native CSS (back to IE9) - http://css-tricks.com/currentcolor/

CSS varibles are coming

disclaimer: CSS Color Level 4 is still an initial draft (from all notes below this comment)

• some clors will become functions- like gray (gray(50%)) to changes the level of gray.
• maybe the ability to have semi-transparent hex values (add a sigle chracter value at the end)
• new color format HWB (hue, whiteness, blackness) - HWB !== HSB
• new color() function which has a few "adjusters" (like "tint", "shade", "blend", and many more)
• reg() and hsl() will accept alpha values

All slides are here: https://github.com/LeaVerou/css-colors

4-embrace-the-vertical.md

Embrace the Vertical

by Antoine Butler

slides: https://speakerdeck.com/aebsr/embrace-the-vertical

Responsive deisng always focuses on screen width... but what about height?
People can rotate these devices.... then what? Reponsive is not always the solution, things need to adapt (could be desktop or mobile).

Taking Wikiepdia as a "sample site" to try out the vertical media queries (change the height of the browser) http://bit.ly/WikiProto

Using vm.com as a sample site, the focus was the left-hand nave bar. How to allow it to support multiple items http://bit.ly/StickyNav

This concept of thinking abou the height can apply to lots of different things:

• single page natigation
• galleries
• scolling sites

5-making-your-css-happy.md

Making Your CSS Happy aka: testing your CSS

by Christopher Burgmer

Every layer of development has some type of testing methodology, but not hte HTML+CSS layer. Testing tools provide a "safety net" for when making changes...but we don't have this for the HTML+CSS aspect.

Some tools take screenshot and indicate when something changes - not if it's broken, that it has changed. Then the developer just needs to check the changes and see if they were expected / planned changes or not.

There are others that do similar stuff:

• Wraith: https://github.com/BBC-News/wraith
• PhantomCSS: https://github.com/Huddle/PhantomCSS
• Hardy: https://github.com/thingsinjars/Hardy
• CSScritic: https://github.com/cburgmer/csscritic
• Many others here: http://csste.st/

By using theese tools, you lear a lo about your UI compoennts. Screenshots can be flaky: content changes and rendings are unique snowfles, so you might need to use a different solution for different ploblems - find out what works for you!

Mixing concepts from talk #1 (styleguide driven development) - one neat trick would be to run your CSS tests against your styleguide (create tests for individual modules) in place of your app.

Downside is that at the moment there is no way to automate these tests (aka: run on every commit or from a CI), so some manual inspection is still necesary. Tho tools like PhantomCSS allow you to run these tests from the CLI.

6-bulletproof-font-icons.md

Bulletproof Font Icons

by Zach Leatherman

Recomended font formats are WOFF + TFF (for Android) + EOT (for ie8) + SVG (for Chrome on Windows XP), then you're covered.

But with using SVG... you need to be careful. Chrome for windows supposets TFF, and it will try to apply the first one that it finds.

By including the @font-family rule w/o using it, it won't get downloaded (expect in IE8). Only when you apply it in a class... then it will get downlaoded by the browser.

Unicode!
Every unicode "code" has a meaning. This is how you can use the same unicode across devices and fonts for the same symbol.
PAU = private use area = free-for-all area of unicode. This is what custom font-icon develoeprs use to avoide collisions.

Because of this PUA, since there is no "fallback" chracter, the text is blank (or show an unidentfiable chracter) until it the font downloads (flash of invisible text as well as flash of unstyled text). This is particualrly troublesum for content fonts.

7-css-in-your-pocket.md

CSS In Your Pocket (mobile CSS tips from the trenches)

Angelina Fabbro

Mobile is "a thing" now, and we can't denny it. There are many good tools out there, but no one tool solves all my problems.

There are 2 type of CSS debugging on mobile:

• layout
• performance

Cross-browser/cross-device isses:

Android 2.3 is "the new" IE6 - common pitfalls

• position: fixed does not work very well on mobile (even versions of iOS). There are some hacks... but some of them cause perfoamnce issues.
• min-height, -width, max-height, -iwdht behave inconsistently
• overflow: auto is also inconistent...
• z-index does not apply to absolutley positioned elements. fix? add a z-index: 0 on the body.
• ems are poorly supported, rems are not supported at all.
• no gradients
• media queries give @portrait dimentions, even after rotating...

More resourece: quircksmode.org, charlesproxy.com

Stay away from:

• "*" selector
• really long classnames
• broder-radius
• box-shadow
• transforms

8-css-and-the-critical-path.md

CSS and the critical path

by Patrick Hamann

slides: https://speakerdeck.com/patrickhamann/css-and-the-critical-path-cssconf-may-2014
src code for The Guardians mobile site, and their optimizations: https://github.com/guardian/frontend

As web developers, we should no longer think in seconds. It should be milliseconds.
0.1s = user experience slgiht delay
1.0s = user persives the machine "is working"
10.0s = task is abandonded

So we want to tarket 1s for our page loads.
But network latency (on mobile) takes ~600ms, so we really only have ~400ms to do our thing...
We need to get CSS down from the network ASAP (even before the JS files) since it will be the first thing the user sees.

(We define "critical path" as the main thing that the user is here for (in the case of this talk, the new article))

To ensure that our criticla path CSS gets to the user FAST... we put some in-line CSS (at the top of the page) so that the browser gets all the paint and layout info in a single request. The percived benefits are huge.
Another useful technique is to store the non-critical path CSS in localStorage so the broswer doesn't have to fetch it the 2nd time around.

This system also creates more resilient systems. We only need 1 request to get ALL the information necesary for painting and layout.

Resoureces! http://speedcurve.com/

In place of doing the in-lining manually or with a build tool... you can use the Apache (or nginx) "pagespeed" module to do this at a "proxy-level". There are some risks with doing this, but it is still an option.

HTTP/2 and ServiceWorker will avoid the need for all these "hacks" when they are finalized.

9-peachpuffs-and-lemonchiffons.md

Peachpuffs and Lemonchiffons (aka: CSS colors, the named ones)

by Alex Sexton

The history of named colors in CSS

The named colors come from the X11 color (or more specficially, X10R3) back in 1983, in a file named rgb.txt Started out wit just 69 entires, now there are a lot more. Originally for the DECVT240

FUN FACT: "gray" and "grey" are both a thing... becausoe of programmers that didn't know how to spell (the English way vs the American way).

Paul Raveling, John C thoman and Jim Fultom <-- fathers of modern X11 names.

Thank you very much for these notes.
You may want to add this link to Paul Irish's slides:
https://docs.google.com/presentation/d/1WsFzuaf595k4WL1nQK0kpkj3rYOP-Bm20jpHAB4YUGI/preview#slide=id.p