NOTE I now use the conventions detailed in the SUIT framework
Used to provide structural templates.
Pattern
t-template-name
(function() { | |
var CSSCriticalPath = function(w, d, opts) { | |
var opt = opts || {}; | |
var css = {}; | |
var pushCSS = function(r) { | |
if(!!css[r.selectorText] === false) css[r.selectorText] = {}; | |
var styles = r.style.cssText.split(/;(?![A-Za-z0-9])/); | |
for(var i = 0; i < styles.length; i++) { | |
if(!!styles[i] === false) continue; | |
var pair = styles[i].split(": "); |
NOTE I now use the conventions detailed in the SUIT framework
Used to provide structural templates.
Pattern
t-template-name
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:
#!/bin/bash | |
# cd into the directory | |
cd ~/gitsync/github-wordpress-sync/; | |
# Make sure we are not already running | |
if [ -f .sync-running ];then | |
if test ! `find ".sync-running" -mmin +10`;then | |
# Currently running, but not stuck | |
exit 1; | |
fi | |
fi; |
<!doctype html> | |
<html> | |
<head> | |
<!-- Encoding --> | |
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> | |
<!-- Always force latest IE rendering engine (even in intranet) & Chrome Frame --> | |
<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1"></meta> | |
This is a WORK IN PROGRESS intended for fleshing out and feedback
It's very common for people to be unhappy with how a WordPress plugin adds front end resources to their site. If a plugin needs CSS, the plugin will add a <link>
element to that CSS. If the plugin needs JavaScript, it will add a <script>
to that JavaScript.
Plugins do this because it works. It's damn important for a WordPress plugin to work, even in adverse conditions. They rightfully want good ratings and little customer support.
But this comes at the cost of additional HTTP requests. In optimizing front end performance of a site, reducing the number of HTTP requests is a huge thing. Front end developers want to decide and control how front end resources are being handled, and WordPress plugins don't typically make this easy on them.
/* | |
* Property prefix hacks | |
*/ | |
/* IE6 only - any combination of these characters */ | |
_ - £ ¬ ¦ | |
/* IE6/7 only - any combination of these characters */ |
#!/bin/sh | |
printf "Switching php to version 7.1 with symlinks.\n" | |
printf "Press any key to continue...\n" | |
read CONTINUE | |
printf "Creating backups..." | |
# Backup original binaries |
<?php | |
/* | |
* mytheme_form_submit_button | |
* | |
* Filter the Gravity Forms button type to change it to a proper button | |
*/ | |
function mytheme_form_submit_button( $button, $form ) { | |
$button = str_replace( "input", "button", $button ); | |
$button = str_replace( "/", "", $button ); | |
$button .= "{$form['button']['text']}</button>"; |
#js-mediaquery { | |
overflow: hidden; | |
width: 1px; | |
height: 1px; | |
position: absolute; | |
top: -999999em; | |
left: auto; | |
clip: rect(1px 1px 1px 1px); /* IE6, IE7 */ | |
clip: rect(1px, 1px, 1px, 1px); | |
} |