Jonathan T. Neal

Thoughts on Media Queries for Elements

jonathantneal — Thu, 07 Feb 2013 23:10:40 +0000

This post was inspired by my friend and co-creator of normalize.css, Nicolas Gallagher.

We need native CSS media queries at the element/component/widget level, not just the viewport. Make it so, internetz.

— @necolas

So, without any fanfare, I want to share my thoughts on element media queries, and then open it up for discussion in the comments.

Thought #1: What the Markup Would Be

We would use a pseudo class, because we are targeting the state of an element. Some examples of pseudo classes are :hover, :focus, and :checked.

We would not use a pseudo element, since we are not targeting a shadow element within the element. Some examples of pseudo elements are ::first-letter, ::before, and ::after. Don’t be fooled by IE7&8, :before is not the correct syntax. In fact, if you are not supporting IE7&8, you should start using the correct syntax to free yourself of this legacy inconsistency.

[The] :: notation is introduced by the current document in order to establish a discrimination between pseudo-classes and pseudo-elements. For compatibility with existing style sheets, user agents must also accept the previous one-colon notation for pseudo-elements introduced in CSS levels 1 and 2 (namely, :first-line, :first-letter, :before and :after).

— Selectors W3C Working Draft

We would name the pseudo class media after its predecessor, using parenthesis to wrap the queries, similar to :not and :contains.

.widget:media(max-width: 30em) {
	color: tomato;
}

Multiple queries would require multiple parentheses.

.widget:media((max-width: 30em) and (min-width: 30em)) {
	color: bisque;
}

Thought #2: How Ems Would Work

The size of an em would be relative to the font size of the element, just as it works with existing CSS values. The rem unit would be used to target the font size of the document.

html {
	font-size: 16px;
}

.parent {
	font-size: 12px;
}

.parent > *:media(max-width: 30em) {
	/* applied up to 360px */
} 

.parent > *:media(max-width: 30rem) {
	/* applied up to 480px */
}

This brings up an issue with existing media queries. Presently, when we define the font size of html as 12px, does @media (max-width: 30em) evaluate to 360px or 480px? If we believe that @media “lives” on the html element, then the answer is 360px. On the other hand, if we believe that @media “lives” in some ether beyond html, then the answer is 480px. Sadly, most browsers agree with the later interpretation. Therefore, as a side benefit to this element media queries discussion, we should specify that the size of an em in a @media query should be relative to the font size of the html element.

Thought #3: How Infinite Loops Would Be Handled

Infinite loops would freeze at the offending block. While infinite loops are much more likely to happen with element media queries, this issue has been around since :hover. Therefore, a clear specification would be doubly useful.

.widget {
	color: salmon;
	width: 100%;
}

.widget:media(max-width: 320px) {
	color: whitesmoke;
	width: 321px;
} /* the infinite loop is stopped, .widget is whitesmoke with a width of 321px */

Similarly, this would address classic CSS looping issues.

.widget {
	color: plum;
}

.widget:hover {
	color: orange;
	display: none;
} /* the infinite loop is stopped, .widget is not displayed, but is otherwise orange */

Q&A

Should element media queries be able to target the page, like .widget:media(page-max-width: 30em) and .widget:media(device-max-width: 30em)?

Yes, taking advantage of the syntax like this could really improve the readability of stylesheets. I could imagine a lot of developers preferring these kinds of :media pseudo class queries over traditional @media queries. In fact, a lot of developers are already trying to do things like this with nesting in SASS.

Should the number of queries in the :media pseudo class add to the selector weight, so that .widget:media((min-width: 2em) and (max-width: 30em)) wins over .widget:media(max-width: 30em)?

No, because @media queries are not selectors and therefore do not have any weight. In contrast, *:not(#foo) has more weight than *:not(.foo) because the pseudo class is evaluating selectors, and selectors always add weight. On the other hand, @media (min-width: 5em) and (max-width: 500em) does not have more weight than @media (max-width: 500em).

Inspirations

Necolas’ Tweet, Chris Coyier on CSS Specificity, MediaClass (polyfills element media queries), and a great conversation with Ian Hickson, who taught me the difference between : and ::.

Understand the Favicon

jonathantneal — Wed, 16 Jan 2013 20:19:21 +0000

When Alec Rust asked the HTML5 Boilerplate project to switch to a HiDPI favicon, I realized how little I knew about favorite icons, touch icons, and tile icons. When I decided to dive in a little deeper, things got interesting.

Since they were first introduced by Internet Explorer in 1999, almost nothing about favicons has changed. They have almost-always been ICO files, either nested in the root of the domain as /favicon.ico, or organized by a CMS into a theme or images directory and displayed with:

The classic favicon.ico is a 16×16 ICO file, often served in either 16-color or 24bit alpha-transparency format. More recently, favicons have been served as 32×32, which is appropriately scaled down in all major and popular-legacy browsers. In IE10 Metro, the 32×32 icon is used in the address bar.

The rel attribute of a favicon is a product of evolution. Internet Explorer 5 intended shortcut icon to represent the relationship between the page and the icon, but when the specification separated relationships by space, this theoretically created two relationships, shortcut and icon. It wasn’t until 2010 when the HTML5 specification declared icon alone to be the standard identifier. In non-IE browsers, favicons can be served without the shortcut property.

The type attribute of a favicon is about as useful as the type attribute of a

Unsatisfied with either solution? All is not lost. IE10 users are mostly Windows 8 users for now, and Windows 8 introduces a new kind of display icon for websites — tile icons.

With IE10 Metro we can display a unique tile icon when the visitor pins our site to their Start screen. These tile icons are 144×144 PNG files, and for best results they use a transparent background. A background tile color can be specified using a hex RGB color (using the six-character #RRGGBB notation), a CSS color name, or the CSS rgb() function. The markup is pretty simple.

Okay, so let’s put it all together, accepting the potential limitation of IE10, and keeping the sane parts of everything else.

It’s a start, at least.

If you want to learn more about creating favicons, I recommend Create the perfect favicon from Jon Hicks’ The Icon Handbook, and Making a good favicon by Jonathan Snook. Also, I want to thank @alrra for telling me about tile icons.

The HTML5 Invoice

jonathantneal — Mon, 25 Jun 2012 19:16:31 +0000

One of my favorite developers to follow is Chris Coyier. His posts and tutorials at CSS-Tricks are a delight to read. Of his many innovations, one of my favorite is the handy, lightweight HTML Invoice. After using it myself, I thought I would share my own tribute to his work.

So here it is, HTML5 Invoice, a tool that helps you create invoices on the fly, anywhere, without any additional software. Pages are printed perfectly to 8.5×11 standard sheets.

The output is precise. The CSS -webkit-print-color-adjust property is used to ensure the print is exactly what one would expect. The @page rule is used to normalize margins across printers. The markup is short and sweet. Validators, lifeless or living can appreciate the semantic usage of old and new HTML elements. The page is easily and fully customizable. Content editable is employed to update labels and values as the balance calculations refresh and beautify themselves through JavaScript. Branding can be modified with a click on the picture, or my simply dragging and dropping a new one onto the existing image.

Use it now, or download the source to give it a new style.

Simple Stacks and Panels

jonathantneal — Thu, 21 Jun 2012 10:00:43 +0000

Layout frameworks should be simple, not complicated. The CSS and HTML source should be concise, yet compact. The selector chains should be shallow or non-existant. Naming conventions, clear and conformed.

We should step back, relax, and consider how easy it should be. Here is everything you need to start building elegant layouts.

.stack, .panel { display: inline-block; vertical-align: top; width: 100%; } .stack { font-size: 0; text-align: justify; } .stack:after { content: ""; display: inline-block; width: 100%; } .panel { font-size: 16px; font-size: 1rem; text-align: left; }

And here is everything you need to use them.

Just create a stack and add panels to it. If you want, you can add stacks inside stacks too. Layouts are as mild or as flexible as you need them to be. Panels snap to the left and right sides perfectly. Every stack and panel can be styled individually, using small, readable classnames. Responsive designs are a breeze.

/* Default / Tablet Portrait View */ .p2, .p3, .p4 { width: 33.3333%; } /* Handheld Portrait View */ @media screen and (max-width: 479px) { .stack, .panel { width: 100%; } } /* Handheld Landscape View */ @media screen and (min-width: 480px) and (max-width: 719px) { .stack, .panel { width: 100%; } .p2, .p3 { width: 50%; } } /* Tablet Landscape / Desktop View */ @media screen and (min-width: 960px) { .stack, .panel { width: 100%; } .s1 { max-width: 1200px; } .p1, .s2 { width: 50%; } .p2 { width: 66.6665%; } .p3 { width: 33.3333%; } }

Open in JSFiddle

Support is superb. This technique will work in Opera 9+, Firefox 3+, Safari 5+, Chrome 4+, and IE8+. IE6 & IE7 support is available for the price of a couple lines of unsightly CSS.

.stack, .panel { *display: inline; *zoom: 1; } .iestack { *letter-spacing: -10px; } .iestack .panel { *letter-spacing: 0; } .stack { *-ms-stack: expression(this.firstChild.className!="iestack"&&this.appendChild((function(c,e,i){e.className="iestack";while(c.length)e.appendChild(c[0]);return e})(this.childNodes,document.createElement("div"),0))); }

Need Nine-Sixty layouts? No problem.

/* Default / Tablet Portrait View */ .stack, .panel { width: 720px; } .p2, .p3, .p4 { width: 240px; } /* Handheld Portrait View */ @media screen and (max-width: 479px) { .stack, .panel { width: 320px; } } /* Handheld Landscape View */ @media screen and (min-width: 480px) and (max-width: 719px) { .stack, .panel { width: 480px; } .p2, .p3 { width: 240px; } } /* Tablet Landscape / Desktop View */ @media screen and (min-width: 960px) { .stack, .panel { width: 960px; } .p1, .s2, .p4 { width: 480px; } .p2, .p3 { width: 240px; } }

Open in JSFiddle

Have fun. Build. Here’s a refresher on the conventions.

Stack

A container of panels and other stacks.

Panel

A container of anything else.

sX

A unique class for each stack. s stands for Stack. X can be anything.

pX

A unique class for each panel. p stands for Panel. X can be anything.

Faking the Future

jonathantneal — Wed, 20 Jun 2012 10:00:13 +0000

Ah, querySelector, the native answer to the best part of jQuery, or rather Sizzle.querySelector returns the first matching element descended from the element on which it is used. When used as querySelectorAll, it returns the entire list of matching descendant elements. It is elegant, and yet so useful. It’s proof that JavaScript just keeps getting better and better.

document.getElementsByTagName('h1')[0]; // the old way document.querySelector('h1'); // the new way someElement.getElementsByClassName('foo'); // the old way, which never worked until IE9 someElement.querySelectorAll('.foo'); // the new way, which even works in IE8

Regarding querySelector performance: getElementsByTagName appears lightyears faster because it returns a dynamic NodeList, effectively an empty object. Once the NodeList is actually used, speeds becomes very comparable.

What bums me out about querySelector is that it implies some other APIs that are missing. For example, if we wanted to check whether an element is matched by a selector, we would use matchesSelector. That kind of functionality would be especially useful in event delegation where the returning target is unknown. Unfortunately, matchesSelector is unavailable in IE8, Safari 4, and, as of mid-2012 exclusively vendor prefixed while the Selectors API 2 remains a draft.

document.addEventListener('click', function (e) { var matches = e.target.matchesSelector('a[rel="external"]'); // doesn't work anywhere in 2012. if (matches) { // cancel the default action e.preventDefault(); // do something special, like open the anchor in a new window open(e.target, '_blank'); } // (moz|ms|o|webkit)MatchesSelector all work though. });

One way around this almost-standard API is to polyfill the eventual implementation with either the vendor version or something original. This is faking the future.

this.Element && (function (ElementPrototype) { ElementPrototype.matchesSelector = ElementPrototype.matchesSelector || ElementPrototype.mozMatchesSelector || ElementPrototype.msMatchesSelector || ElementPrototype.oMatchesSelector || ElementPrototype.webkitMatchesSelector || function matchesSelector(selector) { var results = this.parentNode.querySelectorAll(selector), resultsIndex = -1; while (results[++resultsIndex] && results[resultsIndex] != this) {} return !!results[resultsIndex]; }; })(Element.prototype);

UPDATE:: A previous version of this article used Array.prototype.indexOf, to polyfill matchesSelector which was then also polyfilled for Internet Explorer 8. Unfortunately, doing this would make indexOf enumerable on all arrays, and that would be super annoying.

With matchesSelector polyfilled, we can check whether an element matches a selector. Using querySelector we can return a descendant matching a selector. Now, what if we wanted to get an ancestor that matched a selector, similar to jQuery’s closest() method? we would need an ancestorQuerySelector method. ancestorQuerySelector would return the first matching ancestor of the element on which it is used. When used as ancestorQuerySelectorAll, it would return the entire list of matching ancestor elements.

document.addEventListener('click', function (e) { var // set the selector selector = 'a[rel="external"]', // get the closest matching element closestElement = e.target.matchesSelector(selector) ? e.target : e.target.ancestorQuerySelector(selector); if (closestElement) { // cancel the default action e.preventDefault(); // do something special, like open the anchor in a new window open(e.target, '_blank'); } });

Unfortunately, ancestorQuerySelector doesn’t have a native implementation in any browser. So, if we were to add it? And what if we were to check for native or vendor-prefixed functionality first? Is that still polyfilling? Can a developer make such a suggestion without writing a selector draft? Are we faking the future or fauxing the future?

this.Element && (function (ElementPrototype, polyfill) { function NodeList() { [polyfill] } NodeList.prototype.length = ArrayPrototype.length; ElementPrototype.ancestorQuerySelectorAll = ElementPrototype.ancestorQuerySelectorAll || ElementPrototype.mozAncestorQuerySelectorAll || ElementPrototype.msAncestorQuerySelectorAll || ElementPrototype.oAncestorQuerySelectorAll || ElementPrototype.webkitAncestorQuerySelectorAll || function ancestorQuerySelectorAll(selector) { for (var cite = this, newNodeList = new NodeList; cite = cite.parentElement;) { if (cite.matchesSelector(selector)) ArrayPrototype.push.call(newNodeList, cite); } return newNodeList; }; ElementPrototype.ancestorQuerySelector = ElementPrototype.ancestorQuerySelector || ElementPrototype.mozAncestorQuerySelector || ElementPrototype.msAncestorQuerySelector || ElementPrototype.oAncestorQuerySelector || ElementPrototype.webkitAncestorQuerySelector || function ancestorQuerySelector(selector) { return this.ancestorQuerySelectorAll(selector)[0] || null; }; })(Element.prototype);

A Close Shiv

jonathantneal — Tue, 19 Jun 2012 10:00:07 +0000

As some history books of the www read, I am more than a little obsessed with the legacy of HTML5, particularly with the legacy browsers. The fixation runs deep, and I find my lamentations becoming songs about Internet Explorer 6. Most of my real contributions to HTML5 “legacy” have landed themselves in a script known as HTML5Shiv, maintained by Alexander Farkas, John-David Dalton, and myself.

A shiv works by running the createElement method on a document, which, in IE, triggers support for the element in the document tree.

document.body.innerHTML = 'Mark my words.'; // fails to render correctly. document.createElement('mark'); // shivs . document.body.innerHTML = 'Mark my words.'; // renders correctly.

Of course, not all HTML is added directly to the document. Many times, HTML is added to detached elements, which also must be shivved.

document.createElement('mark'); // shivs var p = document.createElement('p'); p.innerHTML = 'Mark my words.'; // fails to render correctly. p.document.createElement('mark'); // shivs on
's internal document. p.innerHTML = 'Mark my words.'; // renders correctly.

The work adds up, and HTML5Shiv handles all of this. HTML5Shiv enables Internet Explorer to properly render about 23 HTML5 sectioning elements, providing default styles for them and ensuring that they print successfully.

HTML5Shiv has been integrated into almost every CMS and JavaScript DOM library out there. That’s not surprising, considering that 30% of the popular web is using HTML5 despite Internet Explorer 6, 7, and 8 completely disregarding HTML5 elements. The situation is compounded by IE’s 20%-50% browser market share, depending upon who is asked. These statistics do not change one imperative reality: HTML5Shiv is a surrogate, a crutch, destined to wither away with each passing of Internet Explorer, until the day it accompanies IE8 into the sunset, and flights of angels sing them to their rest.

For developers, desperate to drop any and all of these oldies, the time ticks too slowly. But now, Google, Facebook, and even Microsoft have made heavy-handed moves to raise the bar of browser expectations. They are dropping support for IE6 and IE7, and leaving IE8 as the new low in browser compatibility. With this change, the browser compatibility clock is moved forward 8 years.

In a world where IE6 and IE7 step aside, IE8 would then offer new approaches to the same HTML5 incompatibilities. One approach would be to drop the list of sectioning elements in lieu of a defineProperty listener, hijacking the innerHTML setter, and shivving support for new elements responsively.

document.documentMode == 8 && this.Element && (function (document, innerHTMLPropertyDescriptor) { Object.defineProperty(Element.prototype, 'innerHTML', { set: function (content) { var cite = this; innerHTMLPropertyDescriptor.set.call(cite, content.replace(/<(\w+)/g, function (m, m1) { cite.document.createElement(m1); return m; })); } }); document.attachEvent('onreadystatechange', function () { document.body && (document.body.innerHTML = document.body.innerHTML); }); })(document, Object.getOwnPropertyDescriptor(Element.prototype, 'innerHTML'));

There are issues to consider, like redeclaring the entire body of HTML (oh, you noticed that). Also, the cloneNode method would still break HTML5 elements, although there may be a solution to that as well, using protyping.

document.documentMode == 8 && this.Element && (Element.prototype.cloneNode = function (deep) { var cite = this, element = document.createElement(cite.parentNode.nodeName); element.innerHTML = deep ? cite.outerHTML : cite.outerHTML.replace(/<(\w+)([^>]*)>[\W\w]*$/, '<$1$2>'); return element.removeChild(element.firstChild); });

This back and forth could go on, further feeding my fixation, but the point is clear. The higher the browser bar is raised, the better the band-aids get. Now, if you don’t mind, I’ll be writing a program. See you next time.

Polyfills and Prototypes

jonathantneal — Mon, 18 Jun 2012 10:00:08 +0000

Polyfills are a welcome step forward for the www, allowing web developers to write their best code for today’s browsers without sacrificing the experience of those visitors still running the older stuff. A polyfill is code that fills in missing gaps of functionality in a web browser. Browsers that already have the functionality ignore the polyfill. As a result, all browsers get the same functionality, and developers spend less time debugging individual browsers and more time creating great experiences. Think of polyfills as a set of reading glasses for aging browsers.

A polyfill, or polyfiller, is a piece of code (or plugin) that provides the technology that you, the developer, expect the browser to provide natively. Flattening the API landscape if you will.

Remy Sharp, What is a Polyfill?

Most polyfilling on the web is done through JavaScript prototyping. In JavaScript, a prototype is an object that other objects inherit, and prototyping refers to the process of modifying the prototype object. For example, if the String prototype was given a trim function which removed white-space from both ends of a string, then all strings would have this functionality.

String.prototype.trim = function() { return this.replace(/^\s+|\s+$/g, ''); }; ' Hello World '.trim(); // becomes 'Hello World'

What makes polyfilling unique from prototyping is the intention or expectation of some browsers to handle the functionality without any assistance. Good polyfilling does not overwrite existing functionality. For example, if a trim function already existed on the String prototype (which, in many browsers, it does), then prototyping would only occur if and when the native functionality was not already present.

!String.prototype.trim && (String.prototype.trim = function() { return this.replace(/^\s+|\s+$/g, ''); });

A good polyfill is also distinguished by its ability to mimic native functionality as closely as possible. For example, an addEventListener polyfill for IE8 would not only pass events to attachEvent, but it would also mimic the Event object passed into the listener, imitating the target and currentTarget properties, as well as the preventDefault and stopPropagation methods. Good polyfills are meticulous.

// EventListener | @jon_neal | //github.com/jonathantneal/EventListener !this.addEventListener && this.Element && (function () { function addToPrototype(name, method) { Window.prototype[name] = HTMLDocument.prototype[name] = Element.prototype[name] = method; } var registry = []; addToPrototype("addEventListener", function (type, listener) { var target = this; registry.unshift({ __listener: function (event) { event.currentTarget = target; event.pageX = event.clientX + document.documentElement.scrollLeft; event.pageY = event.clientY + document.documentElement.scrollTop; event.preventDefault = function () { event.returnValue = false }; event.relatedTarget = event.fromElement || null; event.stopPropagation = function () { event.cancelBubble = true }; event.relatedTarget = event.fromElement || null; event.target = event.srcElement || target; event.timeStamp = +new Date; listener.call(target, event); }, listener: listener, target: target, type: type }); this.attachEvent("on" + type, registry[0].__listener); }); addToPrototype("removeEventListener", function (type, listener) { for (var index = 0, length = registry.length; index < length; ++index) { if (registry[index].target == this && registry[index].type == type && registry[index].listener == listener) { return this.detachEvent("on" + type, registry.splice(index, 1)[0].__listener); } } }); addToPrototype("dispatchEvent", function (eventObject) { try { return this.fireEvent("on" + eventObject.type, eventObject); } catch (error) { for (var index = 0, length = registry.length; index < length; ++index) { if (registry[index].target == this && registry[index].type == eventObject.type) { registry[index].call(this, eventObject); } } } }); })();

To better understand how and when to polyfill JavaScript, surf and study Mozilla’s JavaScript Reference and Kangax’s ECMAScript 5 Compatibility Table, or drink from the firehose at the official ECMAScript website.