ffoodd

Improved .sr-only

Theorically bulletproof CSS class for visually hide anything and keep it accessible to ATs.

A Pen by ffoodd on CodePen.

License.

mrmrs

How not to scale css

Several years ago I got curious about how css worked at scale. When I first started out, there weren’t nearly as many learning resources as there are now. CSS zen garden was amazing, at the time it showed how much you could change a design without altering the html.

In the beginning, that’s what people sold me as a feature. By writing css, you could make a change one place and have it propagate everywhere. In principle this sounds pretty good. I’m lazy so I like doing things one time. But eleven years later, my experience on both large and small teams is that this is the most terrifying thing about css.

https://twitter.com/thomasfuchs/status/493790680397803521

In the past few years a lot of very smart people have been thinking more about CSS and this has lead to some fascinating discussions around how to build ‘scalable’ ui and how that relates to CSS. When I first started to think about scalability I naturally started to read every blog post and watch every tech talk I could get

JulienCabanes

// les mixins commençant par with-*** concernent les conditions via sélecteur (parent)
@mixin with-two-sidebars {
	.l-main-wrapper--with-two-sidebars {
		@content;
	}
}

// les mixins commençant par when-*** concernent les conditions via media-query
@mixin when-sidebar-left-is-visible {
	@include for-min-width(40em) {

phamann

Lesson's learnt building the Guardian

Below is a collection of my favourite responses I gathered from Guardian engineers when asked the question: What have you learnt starting from scratch and building a mobile-first next generation web platform for the Guardian?

Daithi O Crualaoich

• Work with great people.
• Deploy like crazy. This means the team has to control the infrastructure as well as code.
• Design is not a service. Designers have to sit in the team.
• Infrastructure is intrinsically unreliable. Discard and replace is the robust strategy.
• Use your CDN for HTML too.
• Don't always do as you are told.

necolas

/**
 * Input CSS
 * No custom syntax. Just write "future" CSS without vendor prefixed properties or values.
 * Use a subset of CSS variables (not dynamic or scoped).
 * Specify a level of browser support: IE 8+, etc.
 * Tool takes browser support and specific declarations to generate vendor-specific variants.
 * This source code is just CSS and works in any browser with adequate support.
 * One day, perhaps you'll have no need to preprocess this code.
 */

thulstrup

$sprites: sprite-map("sprites/*.png");
$sprites-retina: sprite-map("sprites-retina/*.png");

@mixin sprite-background($name) {
  background-image: sprite-url($sprites);
  background-position: sprite-position($sprites, $name);
  background-repeat: no-repeat;
  display: block;
  height: image-height(sprite-file($sprites, $name));
  width: image-width(sprite-file($sprites, $name));

necolas

NOTE I now use the conventions detailed in the SUIT framework

Template Components

Used to provide structural templates.

Pattern

t-template-name

tdd

# Put this in your ~/.gitconfig or ~/.config/git/config
# Windows users: "~" is your profile's home directory, e.g. C:\Users\<YourName>
[user]
  name = Your Full Name
  email = your@email.tld
[color]
  # Enable colors in color-supporting terminals
  ui = auto
[alias]
  # List available aliases