⌘T | go to file |
⌘⌃P | go to project |
⌘R | go to methods |
⌃G | go to line |
⌘KB | toggle side bar |
⌘⇧P | command prompt |
/* | |
* anchor-include pattern for already-functional links that work as a client-side include | |
* Copyright 2011, Scott Jehl, scottjehl.com | |
* Dual licensed under the MIT | |
* Idea from Scott Gonzalez | |
* to use, place attributes on an already-functional anchor pointing to content | |
* that should either replace, or insert before or after that anchor | |
* after the page has loaded | |
* Replace: <a href="..." data-replace="articles/latest/fragment">Latest Articles</a> | |
* Before: <a href="..." data-before="articles/latest/fragment">Latest Articles</a> |
/* | |
* Updated to use the function-based method described in http://www.phpied.com/social-button-bffs/ | |
* Better handling of scripts without supplied ids. | |
* | |
* N.B. Be sure to include Google Analytics's _gaq and Facebook's fbAsyncInit prior to this function. | |
*/ | |
(function(doc, script) { | |
var js, | |
fjs = doc.getElementsByTagName(script)[0], |
<!DOCTYPE html> | |
<head> | |
<title>Stay Standalone</title> | |
<meta name="apple-mobile-web-app-capable" content="yes"> | |
<meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=no"> | |
<script src="stay_standalone.js" type="text/javascript"></script> | |
</head> | |
<body> | |
<ul> | |
<li><a href="http://google.com/">Remote Link (Google)</a></li> |
/**********************************************/ | |
/* | |
/* IR_Black Skin by Ben Truyman - 2011 | |
/* | |
/* Based on Todd Werth's IR_Black: | |
/* http://blog.toddwerth.com/entries/2 | |
/* | |
/* Inspired by Darcy Clarke's blog post: | |
/* http://darcyclarke.me/design/skin-your-chrome-inspector/ | |
/* |
// Source: http://www.google.com/codesearch#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/platform/ColorData.gperf&exact_package=chromium&type=cs | |
// There's also an RGB one defined here: http://www.google.com/codesearch#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/inspector/front-end/Color.js&exact_package=chromium&q=indianred&l=393 | |
var CSS_NAMED_COLORS = { | |
aliceblue: "#f0f8ff", | |
antiquewhite: "#faebd7", | |
aqua: "#00ffff", | |
aquamarine: "#7fffd4", | |
azure: "#f0ffff", | |
beige: "#f5f5dc", |
/* | |
* Normalized hide address bar for iOS & Android | |
* (c) Scott Jehl, scottjehl.com | |
* MIT License | |
*/ | |
(function( win ){ | |
var doc = win.document; | |
// If there's a hash, or addEventListener is undefined, stop here | |
if( !location.hash && win.addEventListener ){ |
<head> | |
<style type="text/css"> | |
picture source { | |
src: image-set(url({filename}@2x.{ext} 2x high-bandwidth)); | |
} | |
@media screen and (min-width:321px){ | |
picture source { | |
src: image-set(url({filename}-m.{ext}), url({filename}-m@2x.{ext} 2x high-bandwidth)); | |
} | |
} |
Many agree that the newly proposed srcset
attribute is much less syntactically intuitive than the widely appreciated picture
element. I hope that the WHATWG and W3C review all of the efforts that the web dev community have put into the picture
element proposal in their own community group and go back on this recent addition.
Syntax aside... if srcset
was here to stay regardless of what we want, is there any way we could make it work in existing browsers without introducing unnecessary overhead or potentially buggy markup? At a glance, it looks shaky to me.
The main problem is request overhead, and attempting to work around that.
Given the following markup, existing browsers will prefetch/fetch the image referenced in the src
attribute, and JavaScript can not prevent that request from going out. This means larger screen devices will request an unnecessary image for every imgset
on a page - not good.
(by @andrestaltz)
If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.