What Happened on Google+, the Web Development Archives
Published on March 9, 2019 (ā» June 14, 2024), filed under Development and Design (RSS feed for allĀ categories).
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.
Contents
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.
[ā¦]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.
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
Internet Explorer and CSS.
Just now learned about a few more limitations in IE:
- 4,096 rules per style sheet.
- Appr. 288 KB style sheet file size limit.
- Maximum of 31/32 style sheets (various statements out there).
Interesting.
Kudos to whoever felt the need to fathom IEās boundaries. Iād like to see (but not work with) your projects š¬
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.
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.)
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.
In essence, semantics in HTML is all about who and how many agree on the meaning of elements and ID and class names.
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. š
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?).ā
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:
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.)
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.)
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.
Web development.
class=no-jsturned 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.
HTML/CSS.
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.
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.
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.
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.ā
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.
HTML and CSS.
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. š
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 š
HTML.
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.
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.
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.)
HTML.
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.
HTML.
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:
Web developers, donāt just blindly copy code. Ever.
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.
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.
CSS.
I love how this thread starts:
Media queries provide the equivalent of an
ifstatement, but not an equivalent ofelse. Whileelseis generally syntactic sugar (in the sense that you can always replaceif (x) {} else {}withif (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-widthandmin-widthdescribe closed ranges, there is noor, andnotcan only appear at the start of a query. As a result, I believe there is no way to express500px < width <= 1000pxas a media query.Read the rest and see what happens š
2013
HTML.
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).
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.
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.
CSS.
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!
HTML.
- Respect syntax and semantics.
- Donāt use presentational or behavioral markup.
- 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.
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.
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.
2014
Workaholism.
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.
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.
HTML.
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.
PS.
Canāt be omitted: [Optional HTML Tags] (2009). More dislikes equal more right, of course š
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.
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).
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.
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).
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):
- for guaranteed unique styles;
- for third party embeds, like ads;
- 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.)
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!
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.)
Code Responsibly just got relaunched, explained, and facelifted.
Still basic ideas, but now with much better reasons to actually keep them in mind. š
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.
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> <title>ā£</title>
Google and web development.
The first time I responded to something on Quoraāa light-weight note on grids and frameworks at Google.
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].
Design.
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).
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.āMukherjee.
[ā¦]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.
āBrandt.
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.
2015
HTML/CSS retrospective.
- Keep use of IDs and classes to a minimum; then
- use functional ID and class names; otherwise
- 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.
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.
Overall:
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.ļ»æ
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).
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.
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).
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 [later Frontend Dogma]. 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.
Reminding that āwriting HTML, design-agnostic as it should be, has always been underestimatedāāand is āthe hardest to write well.ā
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.
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.
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.
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.
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.
HTML retrospective.
Writing HTML is extraordinarily easy, writing good HTML quite the opposite. How convenient that there are ground rules.
2016
One cannot not maintain.
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.
HTML.
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
bodyand nohtmlelement (these came with HTML 2.0, or perhaps a draft prior to that).All elements of HTML, over time, with additional information.
Stop Using the Old āClearfixā:
Write clean HTML and rely on the
overflowproperty.
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 asno-jswould not be one. Now we learn that shorthands were an anti-pattern. No, theyāre not. Yes, they are! No theyāre not.
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.
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.
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.
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 š
Security.
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.)
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.ā
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.
Web Development: How Making Our Own Lives Difficult Is More Important Than We Think:
On craftsmanship. And sugar drinks.
CSS.
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?
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ā¦
From
@charsetto@viewport. Or from@bottom-centerto@top-right-corner.
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.)
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.
CSS.
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.
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.ā
CSS.
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ā?
CSS.
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
!importantto fix every layout problem is like using pesticides against bugs around crops: Itās tough on the environment.ā¦but
!importantis still a tool, and a useful one. A brief snippet from my upcoming book on CSS optimization āŗ
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.
Yet:
[ā¦]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.
Surveillance.
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.
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.
Web Development: When to Automate:
A few thoughts from an upcoming lengthier essay on minimal web development.
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.
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.
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.
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.
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.
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.
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.
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.
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! š
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.)
UX.
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.)
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.
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.
Quality.
I much like how Andrew Hunt and David Thomas have (in 1999?) applied the broken window theory to software.
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.
Quality.
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 š¬
HTML.
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.
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.
User-Centered Web Development:
A few thoughts on how as developers, we certainly have users.
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.)
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
An interlude of sort.
There are problems with AMP. Three ideas on how to deal with them.
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.
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.
CSS.
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-zerotonever.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-quotestonever,- set
string-quotestosingle,- set
declaration-block-semicolon-newline-aftertoalways, and- set
rule-empty-line-beforetoalways.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.
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.
CSS.
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.
EOTāconsider following me on twitter.com/j9t instead.
Goodbye, Google+.
About Me
Iām Jens (long: Jens Oliver Meiert), and Iām a frontend engineering leader and tech author/publisher. Iāve worked as a technical lead for companies like Google and as an engineering manager for companies like Miro, Iām a contributor to several web standards, and I write and review books for OāReilly and FrontendĀ Dogma.
I love trying things, not only in web development (and engineering management), but also in other areas like philosophy. Here on meiert.com I share some of my experiences and views. (Please be critical, interpret charitably, and giveĀ feedback.)
Read More
Maybe of interest to you,Ā too:
- Next: Highlights From āFree Thought and Official Propagandaā (Bertrand Russell)
- Previous: What Happened on Google+, the Philosophy Archives
- More under Development or Design
- More from 2019
- Most popular posts
Looking for a way to comment? Comments have been disabled,Ā unfortunately.
Get a good look at web development? Try WebGlossary.infoāand The Web Development Glossary 3K. With explanations and definitions for thousands of terms of web development, web design, and related fields, building on Wikipedia as well as MDN Web Docs. Available at Apple Books, Kobo, Google Play Books, andĀ Leanpub.