Skip to content

Instantly share code, notes, and snippets.

View bkardell's full-sized avatar

Brian Kardell bkardell

View GitHub Profile
@bkardell
bkardell / minimal-console.js
Created September 29, 2013 01:46
Your browser's console api now minimally conforms :-p
(function(){
var noOp = function(){};
var methods = [
'assert','clear','count','debug','dir','dirxml','error','exception',
'group', 'groupCollapsed', 'groupEnd', 'info', 'isIndependentlyComposed',
'log', 'profile', 'profileEnd', 'timeEnd', 'timeStamp', 'trace', 'warn'
];
methods.forEach(function (name) {
if( !console[name] ) {
console[name] = noOp;
@bkardell
bkardell / DOMModificationTargets.html
Last active December 26, 2015 05:49
DOMModificationTargets idea for sharing ...
<!DOCTYPE html>
<html>
<head>
<style>
html, body { height: 100%; width: 100%; }
pre {
padding: 1em;
border: 1px solid gray;
@bkardell
bkardell / gist:7128131
Last active December 26, 2015 09:19
WIP..
define([], function () {
function injectStyle(css) {
var st = document.createElement('style');
/* If you got here it is before anything is drawn -
Add a rule to hide it until it is widgetized...
*/
var head = document.getElementsByTagName('head')[0];
try {
st.innerHTML = css;

ElementControllers are really basic means of binding models with DOM and back and handling management of Views (different fragments of HTML inside the element being controlled) and interstitial states of those views. They can't handle complex relationships, and they don't have a whole templating solution wound up in them either. They don't infinitely shield your code in abstractions, but they keep it fairly clear and decoupled and they are really lightweight.

###Creating a ElementController You create a ElementController with an element...

var controller = new ElementController(document.body);
@bkardell
bkardell / progress.md
Last active December 27, 2015 01:09
Extensible Web Manifesto progress
  • Mutation Observers

  • Custom Elements / document.register

  • HTMLImports

  • Promises

  • Responsive Images (picture element/src-set)

"Idea: web server should observe traffic, learn what resources page needs, and use http/2 push automatically. No rel=subresource hints needed @pornelski"

I may actually blog about this at some point, but I've been circling this problem six ways from Sunday for about 6 years now and I've tried all sorts of solutions which inform my opinions about what might and might not work well for these problems - of course, none of them actually used http2/push since it wasn't a thing - but it's pretty easy to mentally map between them.

  • Anything that requires analysis of use to make optimizations "smartly" without your having to write something requires, well, data. Since the wins here could be really signficant, it means that for anyone using your site/app prior to that it means the costs of not having the optimizations grow really fast - so people jump to known solutions like bundling and manual optimizations which help defeat the purpose/promise of somethi
@bkardell
bkardell / gist:7806243
Created December 5, 2013 14:48
An optimization debate

Topic:

CDNs and other optimization techniques. This comes up a lot, it crosses numerous mailing lists and twitter. If you have thoughts on this, let's discuss and we can easily cite/refernce in the future....

Here is a statement from @scott_gonzales on twitter, and some thoughts from me to open the discussion

Scott: CDNs have much higher cache-miss rates than you'd think, and JS should be concatenated and deployed from the server

Me: It's true cache-misses are higher, but I don't want to throw the baby out with the bathwater. The advantages of concat will largely disappear with HTTP2. CDNs have a number of things (some in theory and some in practice) which seem good. At an incredibly utilitarian level, if I can offload that from my own infrastructure and maybe reduce hops for this requests too - seems good. At a more conceptual level, the idea that some resources are highly shareble and deserve a special home/cache seems good even if CDNs don't currently fully enable that - seems maybe not so much a

/**
* StyleFix 1.0.3 & PrefixFree 1.0.7
* @author Lea Verou
* MIT license
*/
(function(){
if(!window.addEventListener) {
return;
<!DOCTYPE>
<html>
<head>
<meta charset='utf-8'>
<meta http-equiv="X-UA-Compatible" content="chrome=1">
<link href='https://fonts.googleapis.com/css?family=Chivo:900' rel='stylesheet' type='text/css'>
<link rel="stylesheet" type="text/css" href="/stylesheets/stylesheet.css" media="screen" />
<link rel="stylesheet" type="text/css" href="/stylesheets/pygment_trac.css" media="screen" />
<link rel="stylesheet" type="text/css" href="/stylesheets/print.css" media="print" />
<!--[if lt IE 9]>

Has something really simple like actually exposing the render tree in some basic ways ever been proposed?

For example, what if there were an object called

css.renderTree;

And it just had a couple of static methods...