svallory

require 'colorize'

module Liftr
    module Importers
        class ImportOnce < ::Sass::Importers::FilesystemFilesystem

            attr_accessor :root, :debug_level, :staleness_check, :imported, :original_filename

            # Creates a new filesystem importer that imports files relative to a given path.
            #

scottjehl

I wanted to figure out the fastest way to load non-critical CSS so that the impact on initial page drawing is minimal.

TL;DR: Here's the solution I ended up with: https://github.com/filamentgroup/loadCSS/

---

For async JavaScript file requests, we have the async attribute to make this easy, but CSS file requests have no similar standard mechanism (at least, none that will still apply the CSS after loading - here are some async CSS loading conditions that do apply when CSS is inapplicable to media: https://gist.github.com/igrigorik/2935269#file-notes-md ).

Seems there are a couple ways to load and apply a CSS file in a non-blocking manner:

cowboy

document.write = (function(write){
  var override = function() {
    if(document.readyState !== "loading") { // document has finished loading - we want to intercept this call to document.write
      if (window.ueLogError) {
        try {
          throw new Error("`document.write` called after page load on the gateway.");
        }
        catch(e) {
          ueLogError(e, { logLevel : 'ERROR', attribution: 'gw-third-party-js' });
        }

nex3

// Imports zip.sass, zip.scss, or zip.css *nontransitively* with a "zip" prefix. 
@use "zip";

// Uses the "foo" mixin from zip.
@include zip-foo;

// The prefix is now "zap".
@use "zip" as zap;

// Everything is in the global namespace.

domenic

Auto-deploying built products to gh-pages with GitHub Actions

This is a set up for projects which want to check in only their source files, but have their gh-pages branch automatically updated with some compiled output every time they push.

A file below this one contains the steps for doing this with Travis CI. However, these days I recommend GitHub Actions, for the following reasons:

• It is much easier and requires less steps, because you are already authenticated with GitHub, so you don't need to share secret keys across services like you do when coordinate Travis CI and GitHub.
• It is free, with no quotas.
• Anecdotally, builds are much faster with GitHub Actions than with Travis CI, especially in terms of time spent waiting for a builder.

omegahm

#!/usr/bin/env bash

# Colours picked from https://robinpowered.com/blog/best-practice-system-for-organizing-and-tagging-github-issues/

###
# Label definitions
###
declare -A LABELS

# Platform

paullewis

/*!
 * Copyright 2015 Google Inc. All rights reserved.
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 * http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software