What Happened on Google+, the Web Development Archives

Post from March 9, 2019 (↻ November 14, 2021), filed under and (feed).

Google+ is still shutting down. Following a few philosophy posts to be archived, here are some of the technical entries. Nothing more, nothing less, for they’re again a little random outside their original context.


  1. 2011
  2. 2012
  3. 2013
  4. 2014
  5. 2015
  6. 2016
  7. 2017
  8. 2018


July 19, 2011:

HTML/CSS validation.

Read on Google’s Webmaster Central Blog how the Webmaster Team sees and approaches validation.

I feel honored to contribute to the Webmaster Central Blog, hope our experience is inspiring for web developers, and may thank a few Googlers, including Tony Ruscoe and John Mueller, for their thoughts in the process.

July 21, 2011:

[…] specialists have the benefit of focusing on just their area of expertise. Web developers don’t have that benefit: they need to marry all the different topics that impact their work, like HTML, CSS, scripting, accessibility, performance, maintainability, HTTP, URLs, encodings, &c. pp.

Finding a good balance between all these topics is the challenge web developers face, and the success in doing so makes for the difference between [just] a web developer and an expert web developer.

Shared from a conversation I had on a W3C mailing list. The particulars of that balance are on my mind for a while but as long as I don’t get to sit down and pour it all on paper a sole Google+ post needs to do.

July 30, 2011:

CSS mirroring: managing major updates in heterogenous environments.

  • Test, normalize, and QA your CSS update. (As we know, and always do.)

  • Take a diff and “mirror” the changes to come up with old.css and new.css (these style sheets only reflect differences). Mirroring means that both style sheets use exactly the same properties: for something you removed you simply set a declaration that uses the expected, now possibly inherited value.

  • Pre-launch: use new.css to, for example, create a bookmarklet—you read [about] that already—to then propagate for testing.

  • Post-launch: use old.css to create an emergency escape in case things go wrong (typically because of however motivated style sheet overwrites or use on pages that better applied a custom style sheet) and can’t be fixed immediately. That style sheet is your trump card. Again, only for emergencies and for temporary “local” use.

This is the short story, I’m working on a more detailed article. The approach has been proven invaluable in a number of complex projects: you don’t need it in single project, single locale, single player mode.

CC Tab Atkins Jr., Paul Irish, Harry Roberts, Jonathan Snook, Jeffrey Zeldman

August 4, 2011:

Internet Explorer and CSS.

Just now learned about a few more limitations in IE:


Kudos to whoever felt the need to fathom IE’s boundaries. I’d like to see (but not work with) your projects 😬

August 10, 2011:

CSS hacks.

We all know it’s tempting to address styling differences over user agent detection or special CSS filters, workarounds, and “hacks.” Both detection and hacks should always be considered last resort though in order to achieve and maintain an efficient and manageable code base.

Avoid giving detection and hacks any kind of free pass as they hurt projects in the long run as projects tend to take the way of least resistance. That is, allowing and making it easy to use detection and hacks means using detection and hacks more frequently. More frequently is too frequently.

What to do instead? Always look for alternative styling solutions. More often than enough there are several ways to do something in CSS.

August 16, 2011:

CSS and risk-taking.

You cannot exercise proper code hygiene and maintain good code health without keeping house, and keeping house means taking risks.

This is particularly true in complex environments (several sites, several locales, several templates, several developers, several unknowns) in which you know but one thing, namely that you have no clue: how are your style sheets really used (and where, and by who, and, sometimes, why)?

Contrary to what feels like the next logical step the biggest mistake then is to shy away from proper maintenance. There is nothing more threatening to code efficiency, hygiene, and health than a complex environment (well, or a fearful lead developer).

It is important to take risks. You have to probe projects and check what is really needed. Don’t be afraid of breaking things if it can be for the long-term benefit of the project (remember it’s easy to roll back that one CSS change). Just getting the job done may make you a good subordinate but not a good web developer.

What you get when you don’t take risks are higher level problems like poor performance and manageability, then hacks like versioned style sheets, and sometimes, in disguise, stuff like user agent and feature detection or “compiler” tools (they can but sometimes only appear to be BFFs).

What you can do when you do take risks is focusing on mitigation: Make sure the HTML is right in the first place (ground rule!). Keep at least one communication channel open to inform about and clarify on CSS updates in advance (it’s a whole different story then if nobody listened). Offer fellow developers time and tools to test, and also a way out for exceptions (isolate those, don’t have them drag you down in your core style sheets).

As always there is a whole lot more to add: this is what makes web development so exciting. (I still ♥ it.)

September 12, 2011:

Usability—and design.

Research concludes that “[…] high usability cannot overcome a low visual appeal.”

Not sure I completely buy the method—the sites tested seemed extreme—and would hence welcome additional research, however it’s another indicator not to underestimate visual appeal.

October 26, 2011:

Semantics in HTML:

In essence, semantics in HTML is all about who and how many agree on the meaning of elements and ID and class names.

November 11, 2011:

HTML and CSS skills.

I always find it interesting how people assess their own HTML and CSS skills. If you ask them to rate themselves you quickly hear 5/5, 9/10, 10/10, “expert,” whatever scale you use.

Sure, you want to make a statement, and you may well know a whole lot more than other people while all these other people do happily grade themselves as Royal Highnesses of Web Development. But, pardon my French, this is all BS.

HTML is so much more than just angle brackets. CSS, in its entirety, is a moving and enormously complex target.

There are not more than a handful true HTML experts in this World. More from a theoretical angle, one of them is Ian [Hickson]. (That’s right, which makes it very promising for the HTML spec that some HTML Working Group members miss no chance to mistrust his judgment and use ad hominem attacks to argue.) Regardless, chances are, you’re not one of the other four (and neither am I).

On the CSS end I am willing to put a lot of money on the table telling you that there’s just no one who is an expert at all of it. (Tab [Atkins] might. A whole lot of people who come to both your and my mind are not. They even know that but it will take them to admit.)

So if you’ve done some HTML and CSS coding, be a bit more humble and realistic. Most people can probably divide the score they’re giving themselves by two, maybe even three. There’s nothing wrong with that, just don’t kid yourself and everyone else that you’d totally get HTML and CSS.

Happy Friday. 😊


January 5, 2012:

CSS and vertical centering.

The question on why it’s not that easy to center anything vertically in CSS is probably as old as CSS itself. Tab with a nice short explanation on why this is so:

“Because it’s hard. CSS’s existing layout algorithms are biased towards blocks that fill their containers horizontally and stack vertically. In this model, horizontal centering is easy (just put the free space on either side), but vertical centering is hard (what do you do if one element wants to be centered but the next doesn’t?).”

January 16, 2012:

Web development.

I got the question the other day on why we went to create a new HTML/CSS framework for a new design that we were deploying, and why that framework had to have a different name than the design that triggered its creation.

My (shortened) answer had two parts:

  1. Normally you want to work with your existing infrastructure, i.e. maintain the HTML/CSS framework you’re already using. However, if you’re dealing with major content and thus structural changes, it can well be justified (and more economic) to create a new framework. (We had another good reason but it’s not related to the point I’m trying to make.)

  2. CSS, and thus HTML/CSS frameworks, are design-agnostic. You do not want to name a framework (or simply a style sheet) the same way you name your design because it should be your sincere goal to use the same framework for the next design iteration (and the next, and so on), all of which may have different names again. (Note that you could also end up having two or more frameworks for the same design—I’ve had this case, also in a complex environment—which could obviously not have the same name. As frameworks are design-agnostic, this is fine, though maintaining two or more frameworks is pure luxury.)

February 14, 2012:

CSS and vendor-specific extensions.

Chris Coyier has a nice summary of what’s going on so I’ll just focus on the main point: Soup’s cooked hotter than it’s eaten.

That means, take a step back for a moment. The Web’s not going to end tomorrow. The whole vendor-specific extensions situation is a mess for a long time and for a variety of reasons. You can blame the specs, user agents, and web developers. It was only a matter of time until one side would “break” (and what surprise it’s not the spec side).

For some reason I’m quite relaxed (and, as you know, I’m writing as an individual here). If all user agents were to support -webkit- that was a spec conflict and quite a neat naming issue—but it might well have benefits in terms of speeding up CSS support and consolidating the vast number of vendor-specific extensions there are which may make things simpler for everyone.

We got so used to plastering our style sheets with vendor-specific extensions by now that it’s not pretty. We can tolerate them as it’s cheap to live with the chaos (it’s just affecting style sheets). But we may have lost sight of the fact that we don’t really want any of this stuff. So what happens now may mean some cleansing we deserved, and needed.

February 21, 2012:

Web development.

class=no-js turned into a popular practice to cater for non-script styling. Alas, there is a problem with this approach: HTML itself doesn’t care how it is manipulated, and ID and class naming is important to get right for maintenance reasons.

Details and alternatives.

April 25, 2012:


We’ve just released the Google HTML/CSS style guide.

Two notes before we get to share more: We published the style guide for inspiration, and it’s a living document as we’re constantly looking into improving pretty much everything.

May 3, 2012:

History of HTML and CSS.

Check out these W3C workshop notes from 1995.

What I found most interesting was this comment on the situation with SGML/HTML back then, by Kevin Hughes:

Originally, SGML was meant to convey content and structure, not presentation. The same with the Web. And it did catch on because content was so easy to make.

Unfortunately, content gets boring eventually and that’s when the extensions were introduced. But they mix content and presentation, and they are also non-standard.

A quick count of the speed with which HTML is breaking down: Netscape 1.1 introduced 4 non-standard tags and 23 attributes, Microsoft another 3 tags and 7 attributes, and so it goes on.

Not only are new tags being invented, people also abuse existing tag for the wrong purpose. Multiple title elements in a document cause some browsers to display different titles while the document is being loaded. Tables are used for layout purposes instead of for tabular data. Blank images are used to introduce whitespace, etc.

Th conclusion must be that to most users SGML means nothing and that, therefore, the original purpose of the Web has failed.

…as well as this remark from Håkon Wium Lie:

One reason for developing CSS is certainly “damage control”: avoiding an uncontrolled growth of HTML extensions. But CSS has other goals as well.

There is value in looking back at the challenges in the past.

May 11, 2012:

Maintainability and CSS.

Snippets from an article I didn’t have time to doll up:

Site contents change, and they should change. It’s always been a reality of our work that content changes can mean structural changes which then mean HTML changes; and it’s always been a reality for us that these HTML changes can mean additional changes, like CSS updates. In other words, there’ll never be a place for us web developers to rest. […]

[We] need to make sure we can tell bugs and features apart. I’ve known web developers who complained that CSS updates would affect their sites (sic), and were worried about possibly “breaking things.” It’s mistaking the feature of CSS (central maintenance) with a process problem (testing). […]

It’s important to differentiate between two things: There are avoidable HTML changes and there are unavoidable HTML changes. Separation of concerns targets avoidable HTML changes. It minimizes the number and hence cost of HTML changes. It works.

The other side of the coin, unavoidable HTML changes, is relatively simple to deal with: You can’t, that is, you can really only deal with them once they’re specific needs, not theoretical events. They’re not worth even thinking about unless you know, for sure, that something’s happening, or when the new mocks or copy changes lie right in front of you. And once you do need to deal with such unavoidable changes, all the measures you put in place earlier so to write more maintainable code will be your allies.

May 25, 2012:

Maintainability and technical debt.

From a great article in CACM, Managing Technical Debt. Must read.

  • […] the person who takes on technical debt is not necessarily the one who has to pay it off—in fact, most of the time the one who takes on the debt can shuffle the costs on to other people, which encourages taking on debt. Far too many developers do not maintain their own code. […] little incentive to do the job right the first time.”

  • “There is a saying to the effect that there are three variables in engineering: time, functionality, and resources—pick two. In fact, there is a fourth variable: debt. Of these four variables, you can set any three of them, but you can never set all four; something just has to give, and very commonly debt is the free variable in the equation. Debt can seem ‘free’ at first, but technical debt tends to build on itself.”

  • […] distinguishes between unintentional and intentional debt, which in turn is broken up as short-term (tactical) versus long-term (strategic) debt. He also notes that when a system is nearing end of life, incurring debt becomes more attractive, since all debt is retired when a system is decommissioned.”

  • “Management all too often aids and abets this problem. The current business mantra of ‘shareholder value’ would be fine if shareholders were patient enough to reward long-term value creation. Instead the tendency is to think quarter to quarter rather than decade to decade, which puts immense pressure on everyone in the organization to produce as much as possible as quickly as possible, regardless of the longer-term costs (as indicated by the old lament, ‘there’s never time to do it right, but there’s always time to do it over’).”

  • […] an average-speed, steady, experienced programmer who produces maintainable code may be a better long-term producer and ultimately higher-quality engineer than a ‘super-stud programmer’ who can leap tall prototypes in a single bound but has never had to maintain mature code.”

June 3, 2012:

CSS performance.

Selector performance is important. Of course you want things faster. Practically, however, selector performance rarely matters, which translates to doesn’t matter. Only with thousands of selectors is there ever a perceptible slowdown. See Steve Souders’s ever young tests.

Yet ever since the publishing of CSS performance data have code guidelines been devised to “improve” the situation. Ironically, these guidelines have consistently reduced markup performance, by causing bloat. They have negatively impacted maintainability and code understanding. And they have impaired effective coding practices. (Ironically we, Google, promoted some of these selector guidelines too, for example with our “Make the Web Faster” initiative.)

Not that I haven’t written about this before, however selector performance optimization efforts have probably caused more problems than solved. It’s years that Steve and others began their invaluable performance research. It’s time that developers learn how to read and use that data.

July 14, 2012:


There are fantastic web developers out there these days. But while you find the most amazing sparks of genius in their work, it [sometimes] lacks basic understanding of technology. Common still are issues of the most fundamental kind, like presentational markup (this includes poor choice of ID and class names), and even inconsistencies in the way a single file is written (not: generated); then, reset style sheets in astounding numbers, and Conditional Comments, and what not.

I think, sometimes, that web developers are like magpies, they’re attracted to shiny things. 😉

July 16, 2012:

Web semantics.

I’ve written some sort of introduction over at our Webmaster Central blog.

Thanks Tony Ruscoe and Zakaria El Fassi for kind words and the reminder 😉

August 7, 2012:


I would in fact prefer, instead of <H1>, <H2> etc for headings [those come from the AAP DTD] to have a nestable <SECTION>..</SECTION> element, and a generic <H>..</H> which at any level within the sections would produce the required level of heading.

Tim Berners-Lee in… 1991.

You may be learning HTML 5, but there we go.

August 9, 2012:

CSS resets.

The term “reset” is a misnomer as these style sheets don’t technically “reset” anything. They are setting. This however is the job of respective project’s style sheet. Any discrepancies in layout should be noticed while testing (“resets” don’t save anyone from that), and if such discrepancies don’t get noticed, chances are nobody notices.

Using a “reset” style sheet is an unnecessary detour that a) introduces ballast (look at popular “resets” and notice that they are defining styles for elements that most projects don’t even use), b) may lead to another HTTP request (a performance hit), and c) generally means bad code style because authors end up overwriting the reset which overwrites the user agent style.

The key is to not think of a reset as a reset. In a way it’s a regular style sheet that matches nobody’s layout expectations. Developers could as well use any style sheet out there and overwrite that one just for the heck of it 😊

—In my quest to build the perfect case against resets (after I helped coming up with them in 2003/2004), this is probably closest. I wrote this some time last year on a mailing list.

August 20, 2012:

HTML/CSS frameworks.

I was asked what the most important thing was when creating and maintaining frameworks. (Google’s informational sites run on two that I’ve architected, Go and Maia.)

I responded, to set expectations that there is no certainty: Web sites and apps live, and so do any frameworks underneath them. The more used and hence successful a framework is, the more likely is it that things will break over regular maintenance. And I said, such maintenance is key, yet avoiding things to break is impossible, and the attempt alone unbelievably expensive. And then, while things go wrong, things never go wrong badly. And that leads back to setting expectations: Frameworks should be light-weight and tailored and optimized to respective needs, they should be centralized (one style sheet to embed), and people should embrace, not fear, updates to them.

(Shameless plug: It’s not the first time that I write about frameworks.)

September 12, 2012:


There was a discussion on whatwg@lists.whatwg.org the other day on why there was no “strict HTML spec.”

The thread is not necessary for everyone to read, but web developers should all understand what Tab was explaining:

The parsing rules of HTML aren’t set to accommodate old browsers, they’re set to accommodate old content (which was written for those old browsers). There is an enormous corpus of content on the web which is officially “invalid” according to various strict definitions, and would thus not be displayable in your browser.

[…] years of evidence have provided strong evidence that a large majority of authors cannot guarantee that their pages are valid all of the time. This covers both authoring-time validity and validity after including user comments or the like.

If you want a mode that guarantees validity, that already exists—it’s called “put a validator into your workflow.” Many popular text editors offer plugins that validate your markup as you go, as well.

The problem with breaking visibly is that it doesn’t punish authors, it punishes users, who overwhelmingly blame the browser rather than the site author when the site won’t display for whatever reason.

It’s a very simple equation: being strict is sometimes of minor benefit to authors, but it’s commonly very bad for users, and users most often blame the browsers for not displaying the page rather than the authors for writing invalid code. Thus, it’s simply not in the browsers’ or the users’ best interests to be strict. It may be in the authors’ best interests sometimes, but definitely not all of the time, and in any case, the needs of the user trump those of the author.

September 26, 2012:


So people use stuff like

<!--[if lt IE 7]>      <html class="no-js lt-ie9 lt-ie8 lt-ie7"> <![endif]-->
<!--[if IE 7]>         <html class="no-js lt-ie9 lt-ie8"> <![endif]-->
<!--[if IE 8]>         <html class="no-js lt-ie9"> <![endif]-->
<!--[if gt IE 8]><!--> <html class="no-js"> <!--<![endif]-->

and nobody asks what’s wrong with that picture?

I keep on seeing this, and it’s ridiculous. What you really want to write is this instead:

[This paragraph intentionally left blank.]

Seriously: The <html> start tag is optional (as is its end tag), and the rest has no business to do in an HTML document.

What I really want to say is two things:

  1. Web developers, don’t just blindly copy code. Ever.

  2. HTML5 Boilerplate folk (Paul Irish, Mathias Bynens, others?), I love you, I know you do this to help people (and you do so a lot), but here you well end up doing the opposite.

October 8, 2012:

HTML/CSS frameworks.

It’s surprising how often I still get to discuss public frameworks and script libraries. Recently: “Frameworks are only efficient in the short term (setup time) but inefficient in the long run (not tailored to long term project needs), and they’re also, easily inefficient for users (payload). Public frameworks are like pretty off-the-rack suits—they’re cheap but don’t fit very well, and don’t last very long.”

As you can tell, I don’t get tired of quoting myself.

October 22, 2012:


I love how this thread starts:

Media queries provide the equivalent of an if statement, but not an equivalent of else. While else is generally syntactic sugar (in the sense that you can always replace if (x) {} else {} with if (x) {} if (not x) {}, it’s very useful syntactic sugar, especially in cases that involve an if cascade.

Specifically, consider how one would express “Use rule set A if width is 500px or less, use rule set B if width is more than 500px but no more than 1000px, use rule set C if width is more than 1000px.” As far as I can tell, this cannot be done, because max-width and min-width describe closed ranges, there is no or, and not can only appear at the start of a query. As a result, I believe there is no way to express 500px < width <= 1000px as a media query.

Read the rest and see what happens 😊


January 10, 2013:


In the end, the most horrible parts of the Web are also the most successful, because it’s the most successful parts that get extended by the most people, and so that have the least coordination in terms of their long-term evolution, which is how things end up being horrible.

If you haven’t already, check HTML5 Doctor’s splendid interview with Ian [Hickson].

Ian has always been one of the people web developers better listen to (and hear out).

March 12, 2013:

CSS and resets I.

Not sure how many developers, including Googlers, have realized that we at Google have cultivated reset-less development.

We’ve never talked about the Google-proprietary HTML/CSS frameworks Go and Maia in public (maybe Tony Ruscoe and I will change that at some point), however both have never used reset style sheets. Go has been created 5 years ago, Maia 1.5 years ago. Resets are superfluous even in highly complex commercial environments.

This is not the first time I gently steer against the public’s view on resets, and it won’t be the last time.

March 16, 2013:

CSS and resets II.

A while back Six Revisions published a “history of CSS resets.” It attributes the * { margin: 0; padding: 0; } hard reset to Andrew Krespanis, who wrote about the technique in October 2004. This is likely inaccurate. As I wrote in a comment on the Six Revisions post, the technique has been known and used much earlier—see my own post to www-style in September 2004. I don’t claim ownership myself but the technique has likely been used in 2003, or even 2002.

Though, I wouldn’t mind the ironic twist around promoting the hard reset to then yell at everyone for using any other type of reset.

May 24, 2013:


I’ve always been a fan of specifications in a sense that they’re crucial to know as a diehard professional web developer. When people ask me what to read in order to learn CSS, I thus like to give the dry answer, “start with the specs.”

There are certainly more good reads, however. I could probably point to some by O’Reilly or from some Google co-workers, in fact. Years back, however, Håkon Wium Lie, who has been involved in standards for a long, long time, wrote a doctor’s thesis about CSS.

I think his thesis deserves a bit more attention. I would go so far as to say it should rank second after the specs. I’ve read it back in 2006, and I just printed (I seriously can’t read on notebook/desktop screens) the first couple of sections again for a refresh.

Check it out!

October 28, 2013:


  1. Respect syntax and semantics.
  2. Don’t use presentational or behavioral markup.
  3. Leave everything out that is not absolutely necessary.

Ground rules established in 2009. I re-discovered the post the other day and after a morning of getting all dragged into debates about web development principles, I figured it’s worth pulling them out again.

December 5, 2013:

CSS, HTML, and the Problem of Spec Fragmentation:

Spec fragmentation is a huge problem (and the other fundamental problem CSS suffers from beside unrestricted growth and complexity) and we should respond by creating authoritative overview pages, refactoring what we have, and looking into policy adjustments.

December 15, 2013:

Image optimization.

I like to share a little love for one of my favorite tools these days, ImageOptim. It’s a Mac app to compress JPEG, GIF, and PNG graphics.

ImageOptim’s been a great help to easily and quickly optimize all my projects’ assets (folder drag FTW), and it’s also helped me save hundreds of MB of currently extraordinarily valuable disk space (and bandwidth syncing with my servers) by optimizing all my travel photos.

I don’t have any “hard” facts to share here but a) my experience does suggest ImageOptim is sailing right at the edge of what’s possible, b) I’ve never had any quality or other issues with it, and c) a Xoogler who has extensively studied image compression said “as long as it does [use Zopfli] sensibly it should be pretty great.”

So if you don’t have a nice nifty shell script that auto-optimizes all your images either (I miss that, Google), maybe ImageOptim is something for you too. I recommend it.


January 2014:


I think Yiannis Konstantakopoulos nails it in his Smashing Magazine article:

Workaholism is often confused with hard work. Some people who work on the Web seem not only to disregard its dangers, but to actively promote it. They see it as a badge of honor—but is it really? On the contrary, it’s a serious issue that can damage Web teams.

Working long hours has in no point in history meant good nor efficient work, and workaholism really is a sanctimonious defense mechanism. But I don’t want to talk smart here: I’ve embraced it just as much, I pride myself being able to work hard and long too (even when I’m not doing so), and I have no good solution either. But I do believe that a workaholic culture is damaging and that we need to start looking a bit different at those who work 100 hours a week. Or, 60.

January 24, 2014:

Website management.

Quick tip: If you have a small, relatively stable site with a not inherently local scope, consider using Fiverr to translate it into other languages.

After just discovering Fiverr (and, though tempted, disregarding their online marketing services) I tried them for exactly that, and I’ve been quite happy with the results. The turnaround time was quick in each case, and (so far) there are no quality complaints. I found $5 to be a very decent price for translation work.

What I had translated? The World’s Highest Website into Hindi, Japanese, and Italian, and Code Responsibly into Korean (of course I need to be exact here). I did the math and WHWS is now available in 27 languages, accessible to 3.8 billion people. I mean, why not—a happy camper here.

January 27, 2014:


I’m feeling a little belligerent today, so anyone arguing that omitting optional tags makes markup harder to write or more complicated: That was, is, and will remain complete bullshit, and people who claim that must be blind or in denial.

[Check the] not less certain public-html@w3.org version of this statement.

People may not like to omit optional tags—but nobody’s forcing them to do so. More importantly, not liking something has never lent itself to better engineering practices. Apart from edge cases that one can well document and work around, omitting optional tags leads to more compact and more understandable code.

If the “critics” had not spent the last umpteen years closing their eyes in horror they would have gotten used to the approach by now, and had allowed us to actually advance and improve on it.

Can’t be omitted: [Optional HTML Tags] (2009). More dislikes equal more right, of course 😉

February 12, 2014:

CSS retrospective.

The easiest way to write a print style sheet is still “not” to write a print style sheet. Assuming nice proper pretty HTML.

Not to write any print rules is easily achieved by being specific about what other rules are there for. Like, wrapping everything in @media screen {} as well as media queries.

After that it’s easier, and oftentimes also easier than writing a print style sheet “backwards” from existing screen styles, to do some basic print tweaks, like adjusting logo placement, hiding interactive elements like navigation, &c., simply through a @media print {} block.

This version is probably both shorter and friendlier than what I pitched a few years back, but still, here are the thoughts from the archives.

February 24, 2014:

CSS: When to Use Generated Content:

A web developer likely already knows so, just for the record (and to make a point with a Google example).

February 28, 2014:

CSS retrospective.

If I were to talk about CSS prefixes or namespaces (.prefix-class/#prefix-id) today, I’d recommend them under two conditions: a large project, and either a large or a distributed team. Otherwise I recommend KISS to stay in charge and to go ahead with functional, short ID and class names (as we know).

But, seven tenths of a decade ago I commanded all the English I knew to go into more detail, naming three cons and five pros for prefixes—from “they require code conventions” swinging to “they mean more safety.” To say almost the same thing as I said above maybe.

The thoughts from the archives.

June 13, 2014:

Standards retrospective.

The mid-2000s were very interesting from a standards point of view. HTML was falling apart (a handful of people worked on the ideal XHTML 2.0 world while others engaged in some form of mutiny forming the WHATWG), CSS was under attack by vendors (lack of tests and generally slow progress), and many others waited desperately for WCAG 2.0 to arrive (which it did, with half a decade delay). For the history-minded, a tiny, not very well articulated glimpse at that can be attained in my own WCAG, HTML, and CSS: Maybe the Standards Need a Break.

More useful, however, may be fully processing and working on what we face next as the result of growing spec complexity and fragmentation (I wrote about both in a more clear fashion in The CSS Problem and CSS, HTML, and the Problem of Spec Fragmentation). What I foretell is that code optimization will suffer an identity crisis because features keep pouring in on us (only writing documents, as opposed to apps, will fare better because of lower complexity), and that we’ll observe more specialization among developers (I’ve introduced a distinction between research and production coders at Google, and will write about that a bit more shortly).

June 23, 2014:

CSS retrospective.

In both theoretical models and actual projects everything style-related is to be moved into external style sheets. The reason: maintainability (CSS’s key benefit).

But, there still are three cases in which “internal” styling can be the better choice. Or, two and a half if I kept up with the discussions around 3):

  1. for guaranteed unique styles;
  2. for third party embeds, like ads;
  3. for scoped styles.

The thoughts from the archives. (You see that not much changed since 2007, though I’d, like often with these old posts, phrase things a bit differently now.)

June 25, 2014:

Design. Google Design.

Design is the art of considered creation. Our goal as designers is to satisfy the diverse spectrum of human needs. As those needs evolve, so too must our designs, practices, and philosophies.

Hello world, we’re Google Design, and we’re here to share our stories and ideas about design throughout Google—from how Google search evolved, and continues to evolve, to our latest ideas on #materialdesign, an approach to experience design that we announced earlier today at #io14.

We’re also here to listen to your stories and ideas, and to help you, the designer and developer, create amazing products for your users on platforms like Android and the web. After all, design is a conversation, and great design is inherently collaborative.

And as the design conversation evolves here on Google+, we’re going to collect the key principles and the best stories on google.com/design, a new web property that brings it all together, from design specifications, to inspiring videos, all in one convenient location. Check it out by following the link below.

The idea for this, this I may share, originated in my old team (of which you find remnants at… twitter.com/googlewebstudio). But how much of our work went into google.com/design, and whether anything of my old concept made it, I can’t tell.

And so it’s interesting for me to see this go live. It’s like I somewhat have everything to do with it. And nothing, given the time that passed and the lack of association now. What is sure are my congratulations to Google Design—I think everyone is excited as you are to see this!

July 3, 2014:

HTML quality and CSS.

CSS can be very effective in exposing HTML issues. Eric [Meyer] may have been the first to prominently show so with his Diagnostic CSS. In my studies at Google I developed the QA Style Sheet. Karl Groves, to name one more, created Diagnostic.css.

While all these style sheets are still useful, we can do more. For that purpose I’m looking for contributors and a new owner for the QA Style Sheet. If you’re interested in contributing or taking over, please let me know. And yes, it can well move over to GitHub 😉

This development follows loose talks between Karl and me, a while back, on whether and how to join forces. We both appear caught up in our affairs, however, and I need to pick my battles more carefully. I recognized that work on the QA Style Sheet, even with Karl or Eric if they opted to, won’t be a priority for me for very long.

If you too believe that we can push CSS further as a diagnostics and quality tool, please come forward. There are no strings attached other than making a serious attempt. Comment here or send me a line. Cheers.

(Random CC my dear Tony Ruscoe, Zacky Ma, Harry Roberts, Christian Heilmann, Vitaly Friedman—you guys may have a good eye for what we can do here, too.)

July 30, 2014:

Code Responsibly just got relaunched, explained, and facelifted.

Background and credits.

Still basic ideas, but now with much better reasons to actually keep them in mind. 😊

August 25, 2014:

HTML and Specifying Language:

On the suspicion that we should prefer indicating document language through Content-Language, and better require user agents and assistive technology to detect changes in language, where that is relevant.

October 12, 2014:

HTML retrospective.

On the long path to becoming an expert for minimal, tailored web development I had phases in which minimalism didn’t go too well with exaggeration—as a tool to add emphasis. One such occasion was probably when I proclaimed “the World’s best HTML template.” One could have done this a bit more subtly.

However, a minimalist and tailor I still caution when it comes to third-party templates, for if templates are to be minimal and tailored, not much remains to be useful for the very unique needs of our projects. And so I still, now more jokingly, assert to just start with what’s also the smallest valid document:

<!DOCTYPE html>

The thoughts from the archives.

November 2, 2014:

Google and web development.

The first time I responded to something on Quora—a light-weight note on grids and frameworks at Google.

November 3, 2014:

Web Components.

Web Components and custom elements rank the same as IDs or class names in terms of meaning, and the same naming best practices apply. Probably more to be said, just a lazy extension of [my article on semantics].

November 30, 2014:


This has been puzzling me for a long time: Why do so many designers bet all their money on low information density, especially in the context of—displaying content?

Whenever I run into it—and that happens several times a day for a couple of years now—I deem this form of designing a grave mistake. Low information density, and I’m leaning on Edward Tufte here, tends to dumb things down, and it’s more often than enough an obstacle between the user and his goals.

Google (just as an example), who have at times been belittled for their design, have significantly improved over the years but in my view finally overshot—and now become rather leading when it comes to pruning workspaces of information: marketing pages with twenty words on endlessly scrolling pages all the way to apps like Gmail with five emails on a four inch device appear to be but two summits of this information diet iceberg.

An information designer I believe that websites and apps that deal with content should use and always err on the side of higher, not lower, information density. Yet although I have my convictions I’m looking forward to learning more about views from some designers I respect, here particularly Jon Wiley, and possibly how his idea of Material Design fits rich content (and I’m just going to appreciate, not accuse).

December 14, 2014:

Disease and data.

One of the most important questions we can ask is, “compared to what?” (Edward Tufte explains this best). It’s so important because it provides context. Sadly, journalists and designers often omit useful context, and then fail to answer the question for us. But it’s not just these professions that at times let us down. It’s also doctors.

When I was a smoker I occasionally wondered, what is actually my risk of getting a bad disease? When you hear about the risks of smoking, it appears near-certain that you’ll die a gruesome death. But when you search for data, nothing. At least I, a few years back, couldn’t find any good information on actual incidence rates, à la “how many people out of 100 get (lung) cancer”?

Over my studies I then ran into two books that contained a little bit of data. One is Mukherjee’s cancer-related book The Emperor of All Maladies (2010), the other Brandt’s The Cigarette Century (2009). Both are highly interesting reads; I think both, for that reason, won the Pulitzer price. Here some quotes of what they found out.

[…] the annual incidence of cancer in 1985 [was] 448 new cancer cases diagnosed for every 100,000 Americans, or about 1 million every year—and the mortality from cancer in 1985—211 deaths for every 100,000, or 500,000 deaths every year.

[…] the increased risk of cancer was nearly five- or tenfold in smokers.

[…] mammography had resulted in 20 to 30 percent reductions in breast cancer mortality for women aged [55] to [70]. But for women below [55], the benefit was barely discernible.


[…] about 390,000 smokers in the United States […] died of a smoking-related disease that year [1984].

The National Academy of Sciences study estimated that [environmental tobacco smoke] caused between 2,500 and 8,400 lung cancer deaths per year in the United States. Surgeon General Koop placed the number at approximately 3,000.


December 19, 2014:

Maintainable Social Script Integration:

I’ve open-sourced a functioning but scrappy script, or three of those, that shield markup from social widgets or their scripts or so, and throw it all at everyone around: github.com/j9t/social-widget-wrapper. Maybe that should have been the intro.


January 5, 2015:

HTML/CSS retrospective.

  1. Keep use of IDs and classes to a minimum; then
  2. use functional ID and class names; otherwise
  3. use generic ID and class names.

Accompanied by using names that are as short as possible but as long as necessary, and noting that the same rules essentially apply to custom elements, too, I’ve not more to add, more than six years later. I very much deem these rules, that by the way clearly ban presentational names for these are not maintainable, golden.

The thoughts from the archives.

January 15, 2015:

iOS and Android.

A few weeks back I bought an iPod Touch. I got the iPod to eventually replace my Nexus 4—over my travels I got used to being off the (phone) grid and relying on wifi, and I liked the perks the iPod offered, like the nice size, a superior battery life, and better privacy for lack of cell phone capability.

Meanwhile, Android came as 5.0, of which I got parts OTA. Here’s what I observed software-wise, and I wish both Android (Google) and Apple to listen 😊

iOS fails:

  • Text selecting and editing is, for such a basic task, a disaster—it’s cumbersome and easily requires several (high precision) taps. Editing a word is pure chance and oftentimes requires deleting and typing it all again.

  • The app choice is, for my needs, poor to non-existent (I’m not sure what Apple advertises but Play has actually apps one needs). For all practical purposes it’s as if there are no apps at all. Try, for example, to find a file manager that works, or a media player that plays all common formats. Or try to find something useful for free (you can on Play). I get it, Apple likes to make it all easy for us, but until they do, we don’t need hundreds of $2.99 apps that do s (and don’t even “look” good).

  • Either click areas are too small or screen sensitivity is too bad, for many buttons need multiple presses. I’m not sure whether this goes away with practice, but it’s pretty noticeable and annoying.

Android fails:

  • Google apps. This has been bad for, forever. At first Google apps were just scattered around for poor naming conventions, then they got welded into the system only to be disabled, not uninstalled, and now they spread cancerously. Docs, Sheets, Slides, seriously? I’m waiting for Google Type, Google Copy, and Google Paste.

  • No system photo app. The idea to remove Gallery, a fine, decently designed, well-integrated app in favor of, um, Photos, is astonishingly bad. It’s really so bad, I’m editing out some ungoogliness. (Gallery KK helped a little, in case you looked at this dumbfounded, too.)

  • This… thing called Google Now. I know. The third fail that involves Google apps 😉 But even though you can supposedly deactivate Google Now, it’ll still stick around, and there’s this Now button that pops in your way all the time. I have strong negative feelings about Now. I don’t want it, and its trigger-happiness to claim ownership over microphones is offensive (as if Google wasn’t an American company).

    (Another Google app fail, some actually useful apps don’t get maintained or improved. Like Finance or Voice. But it’s enough here.)

iOS tops:

Android tops:

  • Design! I think there were a few regressions since Android 4.4 but overall Android is much more usable and appealing than iOS. (Go figure. Well done, Matias Duarte and team. I love this.)

  • Performance! Android is wonderfully smooth and snappy on a 2012 Nexus.

A note on hardware:

That Apple keeps on inventing their own adapters (that they overcharge costumers and pollute the environment for) is something I much hold against them. But, then, the hardware seems otherwise very nicely done. The latest iPod Touch is maybe a bit too long, but it’s otherwise a neat device. I quite like it.


I wish Apple to focus more on usability and design (this still reads odd, no?), and to stick to standards for their hardware. For Google, I wish them to become more open again software-wise (ha, that’s newish, too), and to allow people to get rid of Google apps. And to maintain all their apps. This has gotten a bit microsoft-esque almost. I also see a danger of overshooting with the design efforts; less may be more now.

Okay, this just had to get out.

January 16, 2015:

HTML retrospective.

When we provide code for others to embed on their sites, we better make sure it’s top-notch. Code that’s for others must be better than code we use for ourselves. Special focus must lie on economy (minimalism), validation (who are we to pull down the quality of other sites), and maintainability.

Most f this up (notably Google, who I still hope the most will start paying attention to this).

The thoughts from the archives (though neither particularly eloquent nor powerful).

February 15, 2015:

Security, encryption, volunteering.

I put in some pro bono work to furnish the Android app Crypt4All (AES) with a German translation. (Note that I’m not all too versed when it comes to security, but I do occasionally use AES, through AES Crypt, to encrypt some data.)

I believe encryption to be critical to protect us from rogue states like the Five Eyes, and deem pro bono work to never get out of fashion. There’s always something nice we can do, for free.

March 19, 2015:

Remember: April 9 is CSS Naked Day:

Let’s keep the tradition alive. Mark the day in your calendar, and consider signing up for reminders (basic event support from my end).

March 22, 2015:

CSS retrospective.

Around 2003–2005, I had a phase in which I wrote most of my sites without any IDs and classes. Simple sites, like uitest.com. Back then, selector choice and support was limited however, and so I soon eased out and used IDs and classes again. (There’s nothing per se wrong with them, of course.)

What I learned, however, influences me to this date: to be as frugal as possible when it comes to using IDs and classes. Relying on the most minimal markup possible is demanding, but pays off greatly in terms of efficiency and maintenance.

The (as always somewhat cheeky) thoughts from the archives.

May 13, 2015:

A Vision of Web Development:

Reminding that “writing HTML, design-agnostic as it should be, has always been underestimated”—and is “the hardest to write well.”

May 18, 2015:

Web Standards: We’re F’ing It Up:

It’s a problem to just change specs. But it’s an increasingly bigger problem not to clean and prune them. The intimidating complexity of web standard specs should precisely be a motivation, not a threat, to come up with a plan. Here, the populist version.

June 16, 2015:

Education, connection, responsibility.

The other week I visited my old school, the BBS Varel, where I made my “auxiliary” computer science degree. I had the pleasure to talk to three classes about life after said degree, and some lessons learned.

Among the tips I shared were the following:

  • Focus on reliable, excellent sources.
  • Don’t shy away from, in fact seek pro bono work.
  • Though a somewhat sad indicator of the times, set aside time for self-marketing (perhaps through maintaining a little, business card style website).
  • Automate what you can, both in your professional as well as your personal affairs (aka the Google spirit).
  • Take responsibility for your work, and be aware how it may be used (privacy! rights!).

I thank the team and students of the BBS for having me.

July 13, 2015:

Typography retrospective.

Brief story. I had fixed but also filed an insane number of bugs in my time at Google. One of the ones that I still find sad, embarrassing even, to still see open is that on Google’s homepage, we’ve never used actual apostrophes: “I’m Feeling Lucky” says the poor thing since time immemorial.

This issue of poor punctuation, of course, is wide-spread (and I’ll pull out another retrospective later, musing about why we may never cure it). But apart from using and producing smarter software, there are also crutches like: typography cheat sheets. And one of those I once compiled and shared, documenting correct punctuation for several dozen languages.

The thoughts from the archives. (Cheat sheet.)

September 16, 2015:

Maintainability retrospective.

There’s almost nothing on HTML and CSS maintenance out there. That nothing includes a little guide, following, that needs reviewing and updating.

Beside poor habits of code optimization (WET CSS!), lack of sense (and best practices) for maintenance is a serious inhibitor for our field. The HTML and CSS Working Groups can throw as many features at us as they like, here we, the web dev community, desperately need to get better. Preferably with, otherwise without the working groups.

The thoughts from the archives.

November 25, 2015:

Modern web development: use resets, frameworks, libraries, pre-processors, package and build management &c. pp. ad nauseam.

Quality web development: understand and use what’s needed.

December 8, 2015:

HTML retrospective.

Writing HTML is extraordinarily easy, writing good HTML quite the opposite. How convenient that there are ground rules.

The thoughts from the archives.


January 6, 2016:

The Law of Maintainability:

One cannot not maintain.

June 14, 2016:

Website ownership.

Since 2008 I suffer from nightmares that meiert.com still uses an XHTML doctype: No other project does that I’ve worked on since.

This and many other decisions do have good—I hope—reasons, however. And those reasons I recently jotted down in a “meta” post at meiert.com/meta.

I’m sharing this not because of the doctype, then, but for three other reasons. One, to solicit feedback—explaining [my] quality efforts, I sure make mistakes. Two, I wish to pass on some hands-on experience working on websites for almost two decades. Three, related, I believe in web design as a process, and more often than enough I’ve missed the opportunity to illustrate what that means through examples. Here’s one.

July 12, 2016:


How many (and which) elements have been part of every single version of HTML?

15: a, address, dd, dl, dt, h1, h2, h3, h4, h5, h6, li, p, title, ul.

That’s it. No body and no html element (these came with HTML 2.0, or perhaps a draft prior to that).

All elements of HTML, over time, with additional information.

November 14, 2016:

Stop Using the Old “Clearfix”:

Write clean HTML and rely on the overflow property.

December 21, 2016:

CSS Shorthand Syntax Considered Important:

CSS shorthands are no anti-pattern, just as little as universal selectors, just as little as !important, and just as little as no-js would not be one. Now we learn that shorthands were an anti-pattern. No, they’re not. Yes, they are! No they’re not.


February 16, 2017:

Principles of Web Development:

Web development, at more than 20 years of age, is becoming an increasingly mature profession. Web development is also subject to constant change, and the field produces more of that change, out of itself. More technological standards, possibilities, and practices; standards, possibilities, and practices that have attracted, but also frustrated us, the people in the field. But as many have observed, more recently perhaps Jeremy Keith in his Design Principles, there are principles for us to hold on to.

April 28, 2017:

Technical progress threatens to become the source of values, and thus does away with the norm that man has believed in for thousands of years: that one ought to do what is true, beautiful, and conducive to the unfolding of man’s soul.

—Erich Fromm: On Being Human.

I’m at a crossroads with my work, where I zero in on joining another tech endeavor (company) I believe in, and to throttle my studies even though they’ve led to invaluable lessons. But this may well be an eye of a needle, a narrow passage through which I and my work must go.

What is my work, precisely? Developing a model of reality that allows us to reclaim our freedom, for we’ve always been free but somehow imprisoned ourselves. What we appear to be going through is an incredibly complicated story, one that is not told by religion, nor science, nor spirituality, nor by those schools that preach Optimism or Acceptance or the Now or what not (no), and neither by philosophy, yet. But while the story is complicated and perhaps forever indecipherable (there’s the idea of physical reality as a perfect illusion, so for us to truly learn), there seems to be a model, a world view that can explain well enough. What I have to do with it, then, and whether I’ll be able to make a contribution, any contribution, I don’t know. Yet I’m not interested in anything but truly appreciating the very magic and beauty of our lives and realities. Life is magic, and there’s no need to fear. That’s why I’m [also] a philosopher, and that much for a glimpse, at my non-technical work.

May 31, 2017:

70% Repetition in Style Sheets: Data on How We Fail at CSS Optimization:

Looking at data for some of the most popular websites, we repeat ourselves too much in CSS; using declarations just once is often one solid avenue to avoid repetition; together, we need to put more focus on style sheet optimization.

This is probably one of the more in-depth articles about web development I’ve written this year, with I believe important points for us to find more effective ways of writing CSS.

June 26, 2017:

Web development.

When I created UITest.com in 2004 I set it up to simply collect resources to build and analyze websites. Soon I focused only on featuring high quality or unique tools (for many things there’s an abundance of resources—for other things it’s really hard). I added Site Check to just generate a basic pre-filled list of whatever tools allowed direct access, so to make testing in many tools a little easier. A bookmarklet followed suit. Only last year did I also start posting new tools on Twitter. And then I wrote a little book about website quality control that was heavily inspired by both my Google work but also this work on UITest.com.

UITest.com is still quite plain and I’m not sure whether or when that would change. But hacking around this evening I got to pry the door open of something I’ve always wanted to do: make Site Check a better tool of its own. And based on a few PHP scripts I had actually written in my early time at Google (we open-sourced them but it seems they died with Google Code) I’ve introduced a very basal, very humble first nudge in that direction: Site Check’s “first impression.”

This first impression which you can now inspect with any Site Check analysis – say, here, of w3.org – simply takes a few data points and gives a thumbs up or down.

Is that useful website testing? No, rather not. But it’s an uncontroversial start. It’s one that sits nicer with many of us than a blunt unexplained number, and it’s one that I want to begin with when improving UITest.com. Expect more tools, usually one each week, and more features, probably with more individual tests, more data points, and a more reliable, better explained “first impression.”

Until then 👍

July 2, 2017:


I once (2014?) built a password generator.

And like many things it was just a test balloon and I never talked about it.

Not that I am now—there are much nicer tools than this one—, it just came to my mind. I love this about being in tech—sometimes we just hack something about, and sometimes the result is great and we do more with it, sometimes we toss it right away, and sometimes it’s just fine to have it sit around (and then it does). 😇

(For something more useful wrt security check out the Traffic Randomizer Chrome extension. At least I believe it’s useful, and I welcome ideas to make it better.)

July 13, 2017:

Stop Using Resets: Visual Examples of the Practical Nonsense of Resets and Normalizers:

Or, when Jens found out that he could just collect websites that use reset style sheets and the like, disable those style sheets, document the results and write a post with the diffs for visual evidence. All because “we ran after this mirage for more than a decade.”

July 25, 2017:

What I Learned Building Google’s Web Frameworks:

On building Google’s Go and Maia HTML/CSS frameworks, and succeeding and failing as a tech lead.

August 1, 2017:

Web Development: How Making Our Own Lives Difficult Is More Important Than We Think:

On craftsmanship. And sugar drinks.

August 24, 2017:

How to order CSS selectors.


Positive surprise: Researching selector order standards I ran into a one-box for my own draft.

Negative surprise: After many years, there are no other proposals? I’m just working on a brief section about the need for a basic sense of selector order in my upcoming book, on CSS optimization, and now wonder whether we need more, sooner? Has anyone else touched the subject lately?

August 29, 2017:

What Kills and What Will Save Content Management Systems:

Imagine you just moved into a new place, and realize that you lack a screwdriver to put up some of your furniture (it’s not from IKEA). You ring at your neighbors’, find one who’s home, and she…

September 11, 2017:

CSS @-Rules, an Overview:

From @charset to @viewport. Or from @bottom-center to @top-right-corner.

September 12, 2017:

Web development.

Everyone can write invalid HTML and CSS. One thing that makes us experts is that we write quality code. Whether in 2000, 2010, 2020, or 2030: Experts validate.

And yes, there are exceptions. But when we validate our and other properties, rarely do we run into any exceptions that are, um, valid. There’s a difference between special and sloppy.

(Cf. validators on UITest.com.)

September 14, 2017:

The Cost of Frameworks, Illustrated:

A visual attempt to show how for everything built for the long run, external frameworks are a pricey crutch that has to be avoided or be thrown away at the earliest time. The reasons: quality—and cost.

October 1, 2017:


I’ve set up CSSTidy, including a fix for it to work with https URLs.

However, it’s also a test: Is CSSTidy at all as useful as it once was? I haven’t embedded it in any dev processes in a while.

October 9, 2017:

Web development.

I like this piece by Mandy Michael. We do have a problem here because we need specialists to at all identify excellent coding practices and to enable us to write true quality code, yet what “full service” and “full stack” have bred and raised are generalists, i.e., people who may be good at one or two things but that aren’t in others.

Show me someone good in HTML, CSS, and JavaScript and I show you one who’s not. Not in all three.

We also have a problem here because no website can exist without HTML, quite improbably without CSS, but definitely very clearly without JavaScript. HTML and CSS are the true necessities—and as we, some of us very familiar with CSS, have quipped many years ago, no one even masters CSS.

Yes, it’s always good to see the big picture. But it’s indeed important to specialize—and not be dinged for that by hiring standards that have the understandable but unrealistic and quality-wise harmful goal of hiring people who can do “everything.”

October 12, 2017:


There’s a new CSS reset, reboot.css, and I’ve just added it to be caught through the Reset Style Sheet Highlighter extension (when referenced individually).

The field seems to insist on a need, but do we not learn? Does no one question the need for a reset when, upon removing it, there’s no effect? Or when there are frameworks that thrive without using any “reset,” “normalizer,” or “reboot”?

October 14, 2017:


As with every tool, one can use it wrong. Using a knife to eat a soup is frustrating. Using a hammer to solder circuit boards is difficult. Using !important to fix every layout problem is like using pesticides against bugs around crops: It’s tough on the environment.

…but !important is still a tool, and a useful one. A brief snippet from my upcoming book on CSS optimization ☺


October 17, 2017:

Web development.

What is a compilation framework?

Compilation frameworks are frameworks that include third-party style sheets and scripts. These may be public reset style sheets but can extend to elaborate UI elements. Skeleton, for example, used to [still does?] build on Normalize.css; Blueprint is thought to incorporate Eric Meyer’s CSS reset. WrapBootstrap and Flat UI Pro are arguably compilation frameworks by extending Bootstrap, but we typically find the compilation framework species internally, when institutions build their own frameworks on the basis of public ones.


[…] composite frameworks mean composite problems, and there’s extra work involved in testing and maintaining. Special attention is in order.

I’m sharing this definition as the term comes up rarely, and as I couldn’t spot any good public definitions. The snippets I lazily took from The Little Book of HTML/CSS Frameworks.

October 21, 2017:


Here’s an interesting document that sheds a particular and instructive light on the severity and history of current day mass surveillance and espionage: the European Union’s Report on the Existence of a Global System for the Interception of Private and Commercial Communications (ECHELON Interception System) of 2001.

(This is an official EU document. For a shorter read and a first impression, I’ve made my own highlights available publicly.)

What happened exactly I don’t want to speculate about: How is it that we (Europeans) have known since 2001 that the United States, the United Kingdom, Canada, Australia, and New Zealand are systematically violating human rights and international law, but have not done anything about it; how did the report disappear from the news cycle; why were no connections made to it since the 2013 revelations; &c.

We knew many years before Snowden that there are mass surveillance and espionage by the “Five Eyes.”

Yet, as relevant as the report still is, as relevant are some of the conclusions and recommendations made by the rapporteur, 16 years ago; notably:

Conclusion and amendment of international agreements on the protection of citizens and firms[:]

  • States […] that the existence of a global system for intercepting communications, operating with the participation of the United States, the United Kingdom, Canada, Australia and New Zealand under the UKUSA Agreement, is no longer in doubt;

  • Calls on the Secretary-General of the Council of Europe to submit to the Ministerial Committee a proposal to protect private life […];

  • Calls on the Member States […] to provide all European citizens with the same legal guarantees concerning the protection of privacy and the confidentiality of correspondence; […]

  • Calls on the Member States to adopt the EU Charter of Fundamental Rights as a legally binding and enforceable act at the next Intergovernmental Conference in order to raise the standard of protection for fundamental rights, particularly with regard to the protection of privacy; […]

  • Calls on the Member States to aspire to a common level of protection against intelligence operations and, to that end, to draw up a Code of Conduct […] based on the highest level of protection which exists in any Member State, since as a rule it is citizens of other states, and hence also of other Member States, that are affected by the operations of foreign intelligence services;

  • Calls on the Member States to negotiate with the USA a Code of Conduct similar to that of the EU; […]

  • Urges the Council and the Member States to establish as a matter of priority a system for the democratic monitoring and control of the autonomous European intelligence capability and other joint and coordinated intelligence activities at European level;

  • Calls on the Member States to make sure that their intelligence systems are not misused for the purposes of gathering competitive intelligence […];

  • Calls on Germany and the United Kingdom to make the authorisation of further communications interception operations by US intelligence services on their territory conditional on their compliance with the ECHR […];

  • Calls on the Commission, the Council and the Member States to develop and implement an effective and active policy for security in the information society; […]

  • Calls on the Commission and Member States to promote software projects whose source text is made public (open-source software), as this is the only way of guaranteeing that no backdoors are built into programmes; […]

  • Calls on the European institutions and the public administrations of the Member States systematically to encrypt e-mails, so that ultimately encryption becomes the norm; […].

[…] while the exact motives may still be obscure, we’ve been dealing with reckless violation of our civil rights for around two decades now. It must stop.

October 26, 2017:

DRY CSS: How to Use Declarations Just Once, Effectively:

Using declarations just once is one way to control repetition in style sheets. It’s not a silver bullet, as we’ve seen with recent data, but it’s so powerful as to make for a key style sheet optimization method. A look at the process and examples.

November 6, 2017:

Web Development: When to Automate:

A few thoughts from an upcoming lengthier essay on minimal web development.

November 17, 2017:

CSS: The Reason Why Selectors Should Be Ordered, Too:

We’ve talked a lot about declarations as declarations are at the heart of our work with direct consequences for the quality of our style sheets. We’ve not talked much about selectors, though, and that may be a mistake.

November 20, 2017:

Web development.

Different context—hardware and programming—but for HTML and CSS I can still much relate: “I, for one, look forward to the end of the barnstorming era and the onset of the era of professional, and ethical craftsmanship.”

For that, craftsmanship, do we of course all talk about quality.

November 22, 2017:

On Big Picture Thinking in Web Development:

Thoughts on thinking outside the box, in tech, with examples ranging from selector performance to a general development vision, to illustrate how very different issues can all reach beyond their perimeter.

November 29, 2017:

Performance of CSS Selectors Is Still Irrelevant:

From my upcoming book on CSS optimization: Selector performance is not something to optimize for as the price we pay for it is, indeed, terrible: We micro-manage our work for gains that aren’t even noticeable.

December 13, 2017:

Expert Web Development: A 3rd Key Differentiator:

On complexity and how we make a mistake deducing that when Google, Facebook, or Twitter present a technical solution to a problem, we’re dealing with the same problem and need the same solution.

December 15, 2017:

Privacy Experiments: How to Auto-Generate Random Web Traffic:

I believe that privacy, which has never been about “hiding something,” is a fundamental civil right, one that is but must not be infringed on; so I once more played with randomizing personal web traffic.


January 2, 2018:

The Two Extremes of Writing CSS, and What We Can Learn from Them:

Extremes can be useful. In practice they help get the maximum out of a given approach, and in theory they can show what we’re headed to. Compare two ways of writing CSS—like Tachyons or Atomic CSS, and 2000’s idealistic coding.

January 8, 2018:

Web development.

Paul Kinlan created a nice page (with feed) featuring the latest from all Google Developers Experts: webgdedeck.com. One convenient way to follow them—us—all.

January 9, 2018:

Web development.

UITest.com is a long-term side project of mine where I regularly publish web-based development and design tools. I keep it quite simple (the site hasn’t changed all that much since 2004) but iterate just as I do with other projects. These days, I implemented some gentle design and typography changes and lightly restructured Site Check.

Site Check, indeed, is what I suggest to check out if you haven’t already. See e.g. [a test run], or pipe in your own site. Site Check performs only a few tests itself, returning a rough indicator for the tested site’s quality; but as you can tell, it gives the opportunity to immediately get the test results from by now more than 70 (!) other tools. Although there are better development tools, and better-integrated ones, I believe this has always meant great time savings, and I’ve accordingly been using Site Check myself since, of course, 2004.

If you like to help, however (and I could much use a hand), it would be most useful if you would 1) share any ideas for improvement particularly around the way the tools are organized, as well as Site Check itself (email info at uitest dot com), and 2) spread the word. I’m not a marketer, but if UITest.com has value then I like to increase this value further, but also make it more clear. For a start, UITest.com has a Twitter account (twitter.com/uitestcom) where all new tools are posted.

Thanks! 🙏

January 11, 2018:

On Material Design:

When Google introduced Material Design back in 2014, I was happy; I was happy for the team and I was happy for Google to mark another milestone on the long way of improving the aesthetics of their products. But, I was also concerned.

(More tough love for Google right after ampletter.org? This was just long ready for release.)

January 23, 2018:


Useful reminders: Jon Yablonski’s “Laws of UX: A collection of the key maxims that designers must consider when building user interfaces.”

(I wish the icons and the poster text would back up the laws more forcefully.)

January 24, 2018:

The Compact Guide to Web Maintainability: 200 Tips and Resources:

The result of reviewing, normalizing, rephrasing, sorting, and testing 134 responses to a maintainability survey that yielded more than 500 data points, to form a new guide, a new and more definite guide to web maintainability.

February 7, 2018:

How Declaration Repetition Developed over Time, a Statistically Insignificant Sample:

We know that there’s excessive declaration repetition in the Web’s style sheets, that each declaration is on average repeated 2–3 times. Now we know a little more.

February 13, 2018:


I much like how Andrew Hunt and David Thomas have (in 1999?) applied the broken window theory to software.

February 16, 2018:

Web development.

If we put Gzip into the picture, then things look even better. That’s because a lot of repetition means a better compression ratio.

One version of a popular argument, and it’s not helping us to fight bloat.

February 19, 2018:


There are two ways of constructing a software design: one way is to make it so simple that there are obviously no deficiencies; the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.

I love it 😬

February 22, 2018:


There’s an index for all HTML elements, and with today’s update it features HTML 5.2, too.

However, I’ve decided not to feature all W3C versions of HTML “5” anymore, but only the latest: I want to limit the confusion the W3C causes with their own brew of HTML. For the latest in HTML it’s best to refer to the WHATWG specification.

March 6, 2018:

Web development.

I’m glad I could publish [We Write CSS Like We Did in the 90s, and Yes, It’s Silly] with A List Apart because I believe that the subject of how we write CSS deserves much more attention. Our whole situation, then, with great new technological possibilities, with ever better tools, and yet some really old ways much intrigues me.

March 14, 2018:

User-Centered Web Development:

A few thoughts on how as developers, we certainly have users.

April 12, 2018:

CSS Optimization Basics:

My latest little book, covering mindsets needed for writing effective style sheets, optimization options during operation and for production, and useful resources to aid and inform the work with CSS. (Pay what you want.)

May 8, 2018:

Web development.

The video for my talk at beyond tellerrand, on the dangers of being a web developer (and the awesomeness of our field), is live. 🙏 #btconf

June 27, 2018:

The Craft of CSS:

An interlude of sort.

July 5, 2018:

AMP, a Strategy:

There are problems with AMP. Three ideas on how to deal with them.

July 10, 2018:

Web development.

To me, view-source: is so great and important because it anchors the idea that web development is, in essence, simple and for everyone. And it is, no matter how hard we try to make it complicated, and therefore I wish view-source: to remain a feature, forever.


July 27, 2018:

News and information transfer.

How fitting when you learn that Mozilla Firefox removes native feed support through your feed reader.

In 20 years on the Internet, I still haven’t seen anything more effective to stay informed than RSS or Atom syndication feeds. But though browsers will influence the development, for this statement it’s still a bigger problem when sites stop to offer feeds than when browsers drop support. (We’ll see what site owners decide to do.)

I believe the better route would have been to make it easier, really really easy, to understand, subscribe to, and manage feeds for the less technical users. We left that road when Google shot down Google Reader. I believe that was a disservice to the Web, one that now reached Mozilla.

August 13, 2018:


For sum.cumo I’ve reviewed the base configuration of stylelint as well as our own adjustments. I liked inspecting stylelint more thoroughly; it’s pretty powerful and the standard config sound.

My only (public) override recommendations:

  • disable declaration-no-important (rationale) and
  • set number-leading-zero to never.

Optionally for rather a matter of taste (and then something to bring even closer in line with e.g. our old guidelines at Google), I also suggest to

  • set function-url-quotes to never,
  • set string-quotes to single,
  • set declaration-block-semicolon-newline-after to always, and
  • set rule-empty-line-before to always.

This isn’t complete, this is even ignoring that in the meantime, I’ve joined the wider stylelint team (in some unspecified capacity), but it reflects the notes I took a few weeks ago. Swimming in a sea of code.

September 25, 2018:

A Short Guide to Minimal Web Development:

There’s an art and even a bit of magic around simple frontend code. Writing such code comes with a few preconditions: perhaps a firm understanding of core technologies, a lot of practice, public scrutiny, and then some. Thoughts.

October 8, 2018:


In my column at heise I’ve recently sketched how style sheet quality is quite a particular topic—and in sum.cumo’s blog I’ve explained in English.

After all, so it seems, we’ve survived 20 years of CSS without much validating.

October 30, 2018:

EOT—consider following me on twitter.com/j9t instead.

Goodbye, Google+.

Toot or tweet about this?

About Me

Jens Oliver Meiert, on September 30, 2021.

I’m Jens, and I’m an engineering lead and author. I’ve worked as a technical lead for Google, I’m close to W3C and WHATWG, and I write and review books for O’Reilly. I love trying things, sometimes including philosophy, art, and adventure. Here on meiert.com I share some of my views and experiences.

If you have a question or suggestion about what I write, please leave a comment (if available) or a message. Thank you!