Given the all the fuss over the blue/black or white/gold dress this week, I whipped up a quick simulation that allows you to view the dress under different lighting conditions.

Slide the control from side-to-side to fade between the three images: a “blue/black” version where we subtract out the theoretical color of the light (#524922), the original picture, and a “white/gold” version where we add color to compensate for the perceived shadow (#392c00).

qz.com picked this up and created their own version as well.

Grab the source from GitHub.

Two new technologies – the modular smartphone and USB 3.1 – are set to radically accelerate the convergence of everything to a single, in-pocket device. In fact, they are so revolutionary that they will change the entire way we think about mobile computing as the iPhone did earlier this millennium.

Modules will eat custom hardware

Modular smartphones, the first of which being Project Ara, will shift the way we buy devices while opening up new markets.

The backbone of Project Ara is UniPro – a standard for communication not unlike Intel’s Thunderbolt – with significant bandwidth, enough to push 4k video uncompressed between them. Modules are built on top of this high-speed network.

The current pipeline for a “revolutionary” add-on in the mobile space has many gatekeepers. When FLIR wanted to launch a smartphone IR camera, they needed to build an entire phone backpack around it.

Another company, Lytro, has no smartphone equivalent to their light-field camera. Instead, you need to buy an entire custom camera or point-and-shoot system which significantly adds to the cost of the system, and requires the end-user to commit to carrying a full, purpose-built device.

The same story is playing out in the construction space. Laser measuring tools are following in the same backpack space. Unsurprisingly, the same pattern of building significant packaging around simple components has played out for construction tools, battery cases, high-end cameras, and Tazers as well.

The obvious advantage to an Ara-like device is that manufacturers can bring a module to market without the traditional risk-averse gatekeepers in the manufacturer (Samsung, LG, etc.) and carriers (AT&T, Verizon, etc.). If the manufacturers decide that this custom module isn’t a fit for their mass-market devices, they’ll pass.

Rather than Lytro or a small Kickstarter team convincing one of the big names to include their custom module at significant risk to both parties, the team can produce the module themselves and directly market to end-users without the overhead of developing a bulky backpack add-on.

By subverting the manufacturer channels, this significantly de-risks the process of bringing new concepts to market and will open up a flood of novel ideas.

Module development provides another channel for manufacturers to rely on the smartphone to be the “brains” of their devices. Making a custom device OS and shell will no longer make sense for companies like FLIR and Fluke when building IR cameras and borescopes for a large part of their product line – at least the products that can be used outside of emergency situations. While this is possible now through Bluetooth or audio jack hacks like Ryobi’s phoneworks, making a module will make more sense.

USB’s type-C: one cable to rule them all

USB 3.1 and the type-C cable give us the ability to reliably connect a device to external components – even those requiring high bandwidth. By plugging in a single cable, you’ll have access to over 10 Gb/s of bandwidth for transmitting USB data. In addition, the type-C cable can be used in “alternate modes” like DisplayPort for pushing video outside of the USB protocol.

What USB-C will enable is the ultimate computing convergence. When you’re at home or work and need to use the “big” screen, along with keyboard and mouse, you’ll plug into a desktop dock. This is already something happening for MacBooks: you can plug a single Thunderbolt cable into a dock and get access to a wide variety of ports.

If you need a larger experience, but don’t want to be tied to a desk, the laptop dock will be your friend. Motorola’s Atrix was the first rough iteration of this idea. It required both a USB micro and HDMI connection and it was tied to a single device. With the USB type-C connector, we will have the ability to plug a single cable into an supported device while getting video out and pushing power and keyboard/trackpad in.

The Future

The era of the laptop and personal computer will eventually come to an end, but not until they allow developers and power users to do everything they can on high-end devices as easily on mobile devices. Before this can happen professionals of all sorts, the power users of the various platforms will need as much memory and processing power as they are currently using.

The type-C connector gets us part of the way there by moving graphics and input off your mobile device, but you’ll still be processing with whatever you can carry with you on your phone. While processor speeds will be improving the mobile space, it is likely that chips on larger boards will always be more powerful.

What we’ll see is the evolution of devices that can move computation from one place to another, in near-real-time. You’ll carry a modular smartphone on your person and have a more powerful version in desktop or laptop form. Plugging the device into the larger form factor will move your computation over to a more powerful CPU/GPU with significantly more RAM. You’ll bring your storage with you – the experience of computing will expand and contract depending on where you are and what you need.

We’re not far away from this right now. With applications running on JIT systems like Dalvik, the same code can be run on two different CPU types and the same techniques we use to juggle Javascript between interpreted and optimized states can transport an application between them.

Your pocket device will be the center of your digital life: a single mobile device when you’re on the go that can act as everything you need for work and play, an entertainment source and gaming console when you’re at home in front of your TV, the storage for your laptop when you need to work on the go, and the core of your desktop computing environment for the professionals who need high performance.

Thoughts? Follow me on Twitter @mmastrac and let me know.

Translations: Пост доступен на сайте softdroid.net.

Please note that this article is written about an Editor’s Draft of a specification as of January 2015, which means the information may change without notice

CSS Selectors Level 4 is the next iteration of the CSS selector spec, the last version of which was made a recommendation in 2011 after being a working draft for a number of years.

So, what’s new?

Selector Profiles

CSS selectors are now categorized into two groups: fast and complete. Fast selectors are those selectors appropriate for use in a dynamic CSS engine. Complete selectors are appropriate for use in cases where being as fast as possible isn’t necessarily a problem, document.querySelector, for instance.

Selectors are used in many different contexts, with wildly varying performance characteristics. Some powerful selectors are unfortunately too slow to realistically include in the more performance-sensitive contexts. To accommodate this, two profiles of the Selectors spec are defined [ref].

:has

:has is the most interesting part of CSS Selectors 4, but it comes with an important caveat described below. What it allows you to do is change the subject of the selector – i.e., the element that will actually be styled – while continuing to match elements that appear later in document order.

This opens up a great deal of new ways to match content. For instance, matching sections with a header:

// Any section that has a header element
section:has(h1, h2, h3, h4, h5, h6)

Or a developer can match all paragraphs that contain nothing but any number of images:

// Match a paragraph that does not have anything that is not an image
p
  :has(img)             // has an image
  :not(:has(:not(img))) // does not have anything not an image

Even matching an element that has a specific number of children (in this case, five):

// Sidebar with five children
div.sidebar
    :has(*:nth-child(5))       // Has a fifth child
    :not(:has(*:nth-child(6))) // But not a sixth child

Caveat: at this time the :has selector is not considered fast, which means that it may not be available for use in stylesheets. As nobody has implemented this selector yet, its performance characteristics are still an open question. If browser vendors can make it fast, it may be available for general styling as well.

In previous versions of the specification this was indicated using an exclamation mark (!) next to the subject – that syntax is now gone.

:matches

:matches is a standardization of :moz-any and :webkit-any that have existed with browser prefixes for some time. This allows a stylesheet author to collapse duplicate rule paths.

This will be useful for collapsing generated Cartesian-product-esque SCSS/SASS output like this:

  body > .layout > .body > .content .post p a.image.standard:first-child:nth-last-child(4) ~ a.image.standard, 
  body > .layout > .body > .content .post p a.image.standard:first-child:nth-last-child(4), 
  body > .layout > .body > .content .post li a.image.standard:first-child:nth-last-child(4) ~ a.image.standard, 
  body > .layout > .body > .content .post li a.image.standard:first-child:nth-last-child(4), 
  body > .layout > .body > .content .page p a.image.standard:first-child:nth-last-child(4) ~ a.image.standard, 
  body > .layout > .body > .content .page p a.image.standard:first-child:nth-last-child(4), 
  body > .layout > .body > .content .page li a.image.standard:first-child:nth-last-child(4) ~ a.image.standard, 
  body > .layout > .body > .content .page li a.image.standard:first-child:nth-last-child(4) {
       ....
  }

into the slightly more manageable:

  body > .layout > .body > .content 
    :matches(.post, .page) 
    :matches(p, li) 
    :matches(a.image.standard:first-child:nth-last-child(4), 
             a.image.standard:first-child:nth-last-child(4) ~ a.image.standard), 
       ....
  }

The Mozilla reference page above lists some caveats about performance. As this selector makes it out into a standard, we will hopefully see performance work on this to make it leaner.

:nth-child(An+B [of S])

While :nth-of-type has existed since the turn of the millennium, CSS Selectors Level 4 is adding the ability to filter based on a selector:

div :nth-child(2 of .widget)

The selector S is used for determining the index and it is independent of the selector to the left of the pseudo-class. As noted in the specification, if you know the type of the element ahead of time the :nth-of-type selector can be converted into :nth-child(... of S) like so:

img:nth-of-type(2) => :nth-child(2 of img)

The difference between this selector and the :nth-of-type selector is subtle but important. For :nth-of-type, each element –whether or not you have applied a selector to it – has an implicit index for itself amongst its siblings with the same tag name. The selector in the :nth-child(n of S) expression creates a new counter each time you use a new selector.

There’s potential for bugs with this new selector. Since the selector inside the :nth-child pseudo-class is independent of the selector to the left of it, you can accidentally omit your subject if you specify a selector to the left that isn’t a superset of the selector inside of :nth-child. For example:

tr:nth-child(2n of [disabled])

might not work as you expect if another, non-<tr> element has the disabled attribute.

In previous versions of the specification this was the :nth-match selector.

:not()

While you might have been using :not for some time, you’ll now be able to pass multiple arguments to it to save some bytes and typing:

// Equivalent to:
//    :not(h1):not(h2):not(h3)...
:not(h1, h2, h3, h4, h5, h6)

Descendant combinator (>>)

The descendant combinator has existed in CSS from the beginning as a space ( ), but now there’s an explicit version of it:

// Equivalent to:
//    p img { ... }
p >> img { ... }

The reasoning for this is to provide a bridge between the direct descendant (>), and the shadow DOM (>>>) operator.

Column combinator (||) and :nth-column

CSS Selectors 4 adds column operations that will allow stylesheet developers to more easily style individual columns in a table. The current approach to table styling requires using :nth-child, which does not always match up with table columns when using colspan attributes.

By using the new column combinator (||) you can now style table cells that are in the same column as a given <col> element:

// The following example makes cells C, E, and G yellow. 
// (example taken from the CSS Selectors 4 specification)
col.selected || td {
  background: yellow;
  color: white;
  font-weight: bold;
}

<table>
  <col span="2">
  <col class="selected">
  <tr><td>A <td>B <td>C
  <tr><td colspan="2">D <td>E
  <tr><td>F <td colspan="2">G
</table>

Alternatively, a stylesheet author may use :nth-column and :nth-last-column to style cells.

In either case, if a cell spans multiple columns it will match a selector for any of those columns.

:placeholder-shown

One small addition to the selector language is :placeholder-shown. This matches an input element if and only if the placeholder attribute text is visible.

:any-link

The :any-link is another small selector addition. It is defined as matching anything that either :link or :visited would match.

// Equivalent to:
//    a:link, a:visited { ... } 
a:any-link { ... }

Conclusions

CSS Selectors 4 is still a work-in-progress, but there are already useful selectors that we’ve seen that will offer web developers new patterns and tools for styling. There are other new selectors in the specification that I haven’t discussed here for concepts like accessibility, validity checking and style scoping.

If you’d like to play around with these selectors, you’ll need to wait for browsers vendors to catch up, or use some of the earlier implementations. :matches is available as :moz-any and :webkit-any, and WebKit nightlies have early support for :nth-child selectors behind a flag.

Since this is an editor’s draft, pseudo-class names may change without notice. Keep an eye on the specification for more information.

Comments? Follow me on Twitter @mmastrac and let me know.

If you find this interesting, read more about CSS Selectors Level 4 which will offer you even more tools for stylesheet development.

CSS3’s :nth-child and :nth-last-child selectors are powerful: not only can they replace :first-child and :last-child, but they can style more complex patterns like the first (or all but the first) three children, every fourth child, or combinations of the pattern “a*n+b”.

But did you know that you can do more interesting things with the selectors? For example, you can style the third element, but only when it’s one of five child (the virtual :nth-of-m-child selector we’ll discuss below). Or that you can style all of the children of an element with m children (another virtual selector we’ll call :family-of-m).

You might ask why we’d want to do this – the particular use case that I had in mind was a Javascript-free, automatically-sizing image gallery that I could toss in the stylesheet for my Jekyll-based site and have it “just work” regardless of the number of images I threw at it.

Here’s an example of what it looks like (click here to view it full-page). Note how the images automatically size to a regular grid without having to use Javascript:

:nth-of-m-child

Thanks to xantys on HN for pointing me at much earlier work in this area here and here.

The first virtual selector we’ll construct is something I call :nth-of-m-child. This will allow us to style the nth child when it’s one of m children, and will be our building block for further work.

So, how do we get this selector? Easy: we combine :nth-child and :nth-last-child on a single element to select when the element to be styled is in the correct position from the start and end of the list of children. For example, we can style the third element, if and only if it’s one of five children:

span:nth-child(3):nth-last-child(3) { ... }

Breaking that down: that’s the third child and the third-last child. Given ‘n’ and ‘m’, the general formula is :nth-child(n):nth-last-child(m+1-n).

Here’s an example of this in action (click here to view it full-page):

:family-of-m

Now that we have the ability to style n-of-m, we can expand that out to style all of the children where there are m of them directly underneath a parent node. The secret to this is using the CSS3 ~ non-adjacent sibling selector which will continue matching elements across siblings. For example, the selector:

img ~ span { ... }

will match a <span> if and only if one of its previous siblings was an <img> element regardless of the number of siblings between them. We’ll combine this selector with our :nth-of-m-child pattern like so:

span:nth-child(1):nth-last-child(5) ~ span { ... }

This pattern will match any adjacent siblings to the first element of five, ie: the second through the fifth of five. We can make it match the entire row by using a comma to match the first element as well.

span:nth-child(1):nth-last-child(5), 
	span:nth-child(1):nth-last-child(5) ~ span { ... }

Here’s an example of this in action (click here to view it full-page):

Advanced techniques

Alright, now we have the tools in place for us to style images as seen in the example.

The first grouping of one through four are simple applications of the technique. When we get to five we want to start using a pattern where the first line or two are larger pairs and the remainder of the images are in triplets. This pattern should repeat regardless of the number of images.

Here’s a commented example. Note that this might potentially be simplified using flexbox and wrapping, but that’s an exercise for the reader.

Let’s start with fifth, eighth, eleventh and the remainder of this pattern. Instead of using the :nth-child(1):nth-last-child(...) as we did before, we’ll use :nth-child(1):nth-last-child(3n+5). This will match the first element of a grouping of 5, 8, 11, …:

/* First two are half-sized (99% / 2) */
img:first-child:nth-last-child(3n+5) ~ img, img:first-child:nth-last-child(3n+5) {
	max-width: 49.5%;
	margin-right: 1%;
}

/* Last n - 2 are (98% / 3) */
img:first-child:nth-last-child(3n+5) + img ~ img {
	max-width: 32.6%;
	margin-right: 1%;
}

/* But second, fifth, eighth, ... have no right margin */
img:first-child:nth-last-child(3n+5) ~ img:nth-child(3n+2) {
	margin-right: 0;
}

Six, nine, and twelve are much simpler.

/* Six, nine, twelve, ... are all (98% / 3) */
img:first-child:nth-last-child(3n+6) ~ img, img:first-child:nth-last-child(3n+6) {
	max-width: 32.6%;
	margin-right: 1%;
}

/* Every third one of these has no right margin. */
img:first-child:nth-last-child(3n+6) ~ img:nth-child(3n) {
	margin-right: 0;
}

Seven, ten, thirteen, and the remainder of the pattern are similar to the 5/8/11 pattern:

/* First four are half-sized (99% / 2) */
img:first-child:nth-last-child(3n+7) ~ img, img:first-child:nth-last-child(3n+7) {
	max-width: 49.5%;
	margin-right: 1%;
}

/* Last n - 4 are (98% / 3) */
img:first-child:nth-last-child(3n+7) + img + img + img ~ img {
	max-width: 32.6%;
	margin-right: 1%;
}

/* The second and fourth, seventh, tenth, ... have no right margin */
img:first-child:nth-last-child(3n+7) + img, 
	img:first-child:nth-last-child(3n+7) ~ img:nth-child(3n+4) {
	margin-right: 0;
	outline: 1px solid red;
}

Conclusions, notes, and further work

We can do some really interesting things making using of :nth-child and sibling selectors. The techniques in this post will also work for the related selectors :nth-of-type and :nth-last-of-type.

Browser performance doesn’t appear to be noticeably affected on mobile or desktop using this technique. If you plan on scaling this up it’s obviously something you’ll want to test.

If you were to combine this with flexbox and flex-wrap you might be able to simplify the example even further and might be able to handle images of different sizes more elegantly.

You also can also use this to create other interesting patterns, like matching only when the total number of children is even or odd, or other factor-based qualifiers.

I’d love to hear of any ideas or improvements you might have. Play around with the JSFiddle here.

Thanks to Webucator for creating a video for this post as part of their CSS3 training course series:

Comments? Follow me on Twitter @mmastrac and let me know.

I’m now on my fifth – though I’m sure not my last – iteration of blog management, Jekyll. It’s a slick static site generator and from what I can tell, the most popular.

One of the benefits of a static site generation tool is that you can aggressively cache the content. For that I’ve thrown Cloudflare in front of everything and have it both caching and optimizing all of my assets.

As part of the re-launch I wanted to offer some basic site search. I looked into a few options for static search in pure Javascript, but the most convenient turned out to be Swiftype which was not much more work than clicking a switch on Cloudflare’s app page.

While I was somewhat happy on Wordpress, my biggest issue with it was that everything lived in a database rather than source control, and that it required constant attention updating it for each release. I spent nearly five years on the platform, however, which puts it at the longest I’ve stayed on any one tool.

Obviously, publishing posts with static site generators isn’t quite as convenient. For that I’m making use of Travis CI and a private GitHub repo. It runs linklint over everything, then pushes it out to the static host via rsync.