Skip to content

Instantly share code, notes, and snippets.

View bkardell's full-sized avatar

Brian Kardell bkardell

View GitHub Profile
@bkardell
bkardell / whatiwasthinking.md
Last active August 29, 2015 13:56
object mapping to DOM

We identify HTML :mappable types. All form elements are :mappable, but it should be plausible to create your own.

:mappable types have a .mapToObject(?Object) method and an .mapFromObject(Object) methods

##mapToObject(?Object)

Given

    <input name="foo" value="bar">
@bkardell
bkardell / observer-confusion.html
Last active August 29, 2015 13:56
A fairly minimal example of confusion about the results I see with MutationObservers
<!doctype html>
<html>
<head>
<style>#gonnaputstuffhere { position:absolute; top:0; right:0; background-color:yellow!important; padding:5em; color:blue !important;}</style>
<script>
/* setup a mutation observer watching subtree of body and begin observing immediately...
collect information about the total number of mutation records, as well as their type
*/
var total = 0;
var matrix = {};
@bkardell
bkardell / render.md
Last active August 29, 2015 13:56
Progressive rendering facilitation

#Our Asynchronous Past One of the things that made the early Web interesting was the fact that the page could render as it was downloading. When we introduced images, design wasn't much of a thing on the web, so we made them async. The browser rendered a placeholder and when the image downloaded it would pop into existence. This was great in some respects because authors could get the (then) majority text content much more quickly so a user can start reading, and on the low banwidth connections of the past this was a pretty huge deal.

Still, a page isn't exactly readable if the text is radically jumping around. To combat this, we simply made sure that the placeholder itself could be appropriately sized and the screen simply 'painted' that part later. This wasn't much of a problem because typically images play a pretty important design element role, so the page would know how big it should be.

#Our Unhappy Middle As the Web started to gain capabilities and grow in new and originally unexpected ways we

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...

<!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]>
/**
* StyleFix 1.0.3 & PrefixFree 1.0.7
* @author Lea Verou
* MIT license
*/
(function(){
if(!window.addEventListener) {
return;
@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

"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 / 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)

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);