This morning I awakened with a question in my twitter stream from @deebeefunky. He was frustrated by the fact that when he sets a blur on box-shadow, it shows on two sides of the box. He wants it to show on only one side. Of course, that got me thinking. I did come up with [...]

In 1999, when I started my journey through the interwebs, I had no real idea where it would take me. I barely knew what was possible. I only knew that my brain loved puzzle-type thinking, detective work, research and figuring things out. And I suspected code would access the parts of my mind that love [...]

I ran into a very frustrating bug while using icon fonts on our site at Contatta. A bug I filed last April, and nurtured through the process of getting fixed, didn’t make the Mozilla release notes (though it was included in Firefox 28). Because I feel it’s a very useful solution, I wanted to bring [...]

I’ve been quiet lately. Startup life is busy… and exhausting. Blogging for me has pretty much gone the way of the Dodo. I’m planning to change that. Since technology is increasingly involved in a modern company’s marketing department, it’s become quite common for those of us who are developers to find ourselves deeply involved with [...]

While implementing the trial automation flows at Contatta, one of my goals was to create an exit survey email for people who did the 30-day trial but had decided not to move to the paid plan. I wanted to send a simple, multiple choice question with the final option being “other,” so trial users could [...]

Yesterday, we had a discussion at work about rems, ems and percentages. I’ve used ems for media queries for years. I’ve used rems for font sizing for a couple of years. I felt like I had a pretty good handle on how it all works. Most of you probably understand the difference, but let’s do [...]

As I’m self-isolating with my vegan daughter, I’ve been trying to cook healthy vegan meals. We had a couple of leeks in the fridge which needed to be used up, so I invented this leek and potato soup, which was pretty delicious. Ingredients leeks potatoes medium onion A stick of celery 2 Veg stock cubes […]

A right-wing friend got angry with me because I refused to “clap for Boris”, saying now is not the time to make political points. If you think this is not a time to make political points, you’re wrong. Boris Johnson has Covid-19 because he went around shaking Covid patients’ hands, against expert advice. Those experts […]

This week, my friend Vadim Makeev and I released the first episide of our podcast, The F-word, which discusses Front-end, browsers and standards. The web site is built on Eleventy, hosted on Github so anyone can contribute and has a 100% Lighthouse score. The pilot episode is 38 minutes long—why not have a listen!! Inclusive […]

I’m trying to record a cover version each week of songs that have really influenced me. They’re not especially polished, but it gives me a chance to experiment with my recording studio outside my usual working practices. This is the first Velvet Underground song I heard. I was at a student party, sitting next to […]

The Cost of Javascript Frameworks – “A framework should go beyond developer experience value and provide concrete value for the people using our sites” by TinkyWinky Catfish. HTML isn’t done! (Chrome Dev Summit 2019) – video by Greg Whitworth and Nicole Sullivan on the visual and accessibility revamp of form controls in Chromium Accessibility for […]

Link O’ The Week: Looking at coronavirus.data.gov.uk -Web superhero @dracos wrote up how he vastly improved the performance of the UK government Coronavirus data website. Spoiler alert: “The important thing is to have a resilient base layer of HTML and CSS, and then to enhance that with JavaScript.” The F-Word podcast, Episode 2 – What’s […]

Back from hiatus. I’m starting up serious planning and writing of “CSS for JavaScripters” so this is a CSS-heavy linkbait, mostly filled with reminders to myself.

• Every-layout.dev is easily the most important CSS resource to be unveiled in recent months. (In fact, it was unveiled at CSS Day, which was a nice touch.) Serious, in-depth, algorithmic discussion of several popular CSS layouts and how to construct them with care.
• The 2019 State of CSS survey results. Contains several interesting gems. The figure that really surprised me is that 85% of the respondents is male. I thought CSS had a slightly higher ratio of women. Then again, maybe it’s the marketing of the survey that caused the disparity. (I never heard of it until I saw the results.) Or my gender guesstimate is just wrong.
• The CSS mindset:

  [...] the declarative nature of CSS makes it particularly difficult to grasp, especially if you think about it in terms of a “traditional” programming language.

  Other programming languages often work in controlled environments, like servers. They expect certain conditions to be true at all times [...]

  CSS on the other hand works in a place that can never be fully controlled, so it has to be flexible by default. It’s less about “programming the appearance” and more about translating a design into a set of rules that communicate the intent behind it. Leave enough room, and the browser will do the heavy lifting for you.

  Interesting turn of phrase that echoes my own thoughts on the subject. Expect to find this in The Book.
• Excellent overview of render blocking in CSS and how to avoid it. It’s simple, really, but there will be countless CSS programmers who need this sort of tutorials. Will also go in The Book.
• An older article, but Harry Roberts’s Cyclomatic Complexity: Logic in CSS remains one cornerstone of CSS understanding, and teaching. This one is mostly meant to remind myself of its existence; you probably already read it.
• Facebook lost 20% of its usage (likes, shares, and such) since the Cambridge Analytica scandal broke.
  This sounds great in theory, but what if the people who are harder to dupe are the ones who stop using Facebook, while the more gullible people remain? The average Facebook user would become more stupid, and Facebook would become even better at influencing its users.
• Also, Facebook should be regulated. Not as a media company, but as a drug.
• We all know third-party scripts are among the worst offenders when it comes to website performance. But how bad is it actually, and who are the worst culprits? Third-party Web provides useful answers and treeviews.
• Excellent overview of WebViews, their purpose, their tricky bits, and their diversity. Required reading for all five people who care about the browser market.
• [In Dutch] List of websites closed on Sundays. In an ultimate meta-move this list is only available on Sundays.
  (And why are these websites closed? Because their proprietors subscribe to the strict Dutch Reformed view that Sundays are not for media enjoyment. See this article about the SGP political party for more background information.)
• You shouldn’t do thing with tool, you should do other thing
• Have a tip for the next Linkbait? Or a comment on this one? Let me know (or here or here).

I am going to write a “CSS for JavaScripters” book, and therefore I need to figure out how to explain CSS to JavaScripters. This series of article snippets are a sort of try-out — pre-drafts I’d like to get feedback on in order to figure out if I’m on the right track.

Today I present the first draft of the short overflow article. Feedback would be greatly appreciated.

*** START EXCERPT ***

"Web design is a constant battle against overflow."

- Rachel Andrew

Not knowing how tall something is is fundamental to web design. For instance, you cannot know in advance how long the texts will be that will be shown in your site. What happens if if the final text is much longer than the fake text you used during production? Or what if there's a wide image you hadn't counted on?

In both cases the content of your blocks will become larger than you expected, and if you've given them a fixed width or height that might lead to overflow: content escaping from the block — or at least, attempting to escape.

The easiest way to avoid overflow is not giving your blocks a fixed height in the first place. If you allow them to grow as tall and wide as they need to be you avoid quite a few problems.

This short chapter discusses how to deal with overflow.

CSS Is Awesome

The most famous example of overflow is the "CSS is Awesome" meme that's been around ever since 2009.

Born out of one web developer's frustration with CSS's overflow behavior, this meme took on a life of its own and became an example of what was wrong with CSS. Why would the 'Awesome' flow out of the box? Why should CSS be so complicated? Couldn't the box simply grow to contain the 'Awesome'?

Sure it could! And it would, except that you specifically instructed the box not to by giving it a fixed width. You could have used min-width or flexbox — both are good in dealing with unexpectedly large content — but you didn't. No doubt you had good reasons, but since it was your decision, the onus of solving any resulting issues is on you.

In these cases, the overflow declaration is your friend.

The overflow declaration

The overflow declaration allows you to define what to do with content that overflows its box. It has four values, visible, hidden, scroll, and auto. The default value is visible, and that's the one that causes the 'CSS is Awesome' effect.

overflow: visible means that you allow the content to spill out of its block. Although that keeps the content readable, it also means the content might overlap with the block below or to the right of the affected block, which can be very ugly.

When calculating the position of other blocks, the browsers' layout algorithm uses the width and height of the box you defined, and disregards the fact that content may be spilling out of the block. In fact, at that point in the algorithm the browsers have no way of knowing that the content overflows. [FACT-CHECK THIS]

Thus, when calculating the position of the next block the browsers place the block exactly where it should be given the height of the previous block and the margins of both. They do not pay the overflow any mind, wbich may cause the overflowing content to overlap the content of the next block.

Sometimes this is what you want — or rather, what you’re forced to live with. More often, though, you want to either generate scrollbars or hide the overflowing content entirely.

overflow: hidden hides the overflowing content. This creates a pleasing visual effect, but now there's no way for the user to get to the content. Therefore, hidden is something of a nuclear option: necessary in a few cases, but to be avoided whenever there's a better way of handling the situation.

overflow: scroll and overflow: auto generate scrollbars. The auto value generates scrollbars when they're necessary, while scroll scroll value always does so, even when no scrollbars are needed.

If scroll always generates those ungainly scrollbars, even when they're not needed, and auto only generates them when necessary, why would you ever use scroll? The reason is that a content change that generates or removes a scrollbar can be quite ugly.

Suppose you have a block with overflow: auto that initially does not need scrollbars. Then a script adds a lot of content to the block, causing overflow, and thus the generation of a scrollbar. Not only is this quite ugly in itself, but on some systems [BE MORE SPECIFIC] the scrollbar itself takes up about 16px of width and thus narrows the content area, which may lead to the reflowing of the text and even more overflow. And when the content is removed, all of that happens in reverse.

All this can give a quite jarring effect. For instance, see the position of the word "serves" in the two screenshots below. The creation of a scrollbar forces it to the next line, and that might be something you want to avoid.

The easiest way of preventing that effect is by giving the block overflow: scroll from the outset. Sure, the scrollbars may not be needed, but if they are there's no moving around of the content.

Block Formatting Context

[This is a practical tip that readers need to know about.]

An overflow value of anything but visible will create a new block formatting context. In old-fashioned float-based layouts it is sometimes necessary to create a block formatting context in order to contain a bunch of floats. (Just nod wisely for the moment; we'll get back to this.)

The easiest way of doing this is to add overflow: auto to the block, even though the block has no set height and the content will never actually overflow.

So if you're working in an old codebase and encounter a bunch of unexplained overflow: auto (or hidden) declarations on blocks that have height: auto, remember that they're meant to keep a float-based layout working properly. Only remove those overflows once you switched from floats to a modern layout system like grid or flex. If you do not intend to switch, leave the overflows in place as well.

Related declarations

In addition to the overflow declaration, there are also overflow-x and overflow-y declarations. They do what you'd expect them to do: they set the overflow on only the horizontal x-axis, or only the vertical y-axis. Otherwise they work exactly like overflow.

Also, iOS supports overflow-scrolling: touch, which enables momentum-based scrolling for overflowing elements. Without this declaration (or, more precisely, with the default overflow-scrolling: auto in place), overflowing elements scroll normally, i.e. they stop scrolling as soon as your finger leaves the screen. Android devices always use momentum-based scrolling, so they do not need this declaration. It doesn't hurt them, either, so it's perfectly safe to use. [TEST]

*** END EXCERPT ***

The ending is a bit abrupt, but I'm not entirely sure what to say next. Also, I'm not yet sure which chapter will come next, so I can't write a segue.

Anyway, please let me know what you think. I'm especially looking for feedback from JavaScript developers who are not all that good at CSS.

I think that CSS would be greatly helped if we solemnly state that “CSS4 is here!” In this post I’ll try to convince you of my viewpoint.

I am proposing that we web developers, supported by the W3C CSS WG, start saying “CSS4 is here!” and excitedly chatter about how it will hit the market any moment now and transform the practice of CSS.

Of course “CSS4” has no technical meaning whatsoever. All current CSS specifications have their own specific versions ranging from 1 to 4, but CSS as a whole does not have a version, and it doesn’t need one, either.

Regardless of what we say or do, CSS 4 will not hit the market and will not transform anything. It also does not describe any technical reality.

Then why do it? For the marketing effect.

I think that announcing a new CSS version will bring desperately-needed attention to CSS, and will help the people evangelising CSS in the field make an impression on web developers who are otherwise not very interested in it.

Web developers are profoundly influenced by the cult of the new. The best way of getting their attention is announcing a new version of something, and that’s exactly what we would be doing here.

I have been given to understand that the CSS WG might be willing to support this narrative and confirm the existence of CSS4 — if we web developers can make a strong enough case that it will be beneficial to CSS. Today I am starting to build such a case.

Head, torso, long tail

Influenced by Ilya Grigorik’s excellent performance.now() presentation, I segment web developers into a head, a torso, and a long tail. CSS4 would help the latter two groups.

• The head consists of clued-in web developers who closely follow what’s going on in our field
• The torso consists of those that have some clue what they’re doing and read up on their craft from time to time
• The long tail covers a wide range of web developers, from those who are fairly close to the torso to those that churn out interminable sites without understanding why using 7.8M of JavaScript per site is a really bad idea.

(These segments form by self-selection. Any web developer can become part of the head, but it takes more effort than being part of the long tail. Not everyone feels the need to put in that extra effort, and thus the three segments come into being.)

CSS is, and has always been, part of the head’s world. The head does not need CSS4 because it already follows CSS closely, goes to conferences, reads blogposts and articles about upcoming features, and knows what’s happening.

The torso does this to a much lesser extent, and the long tail doesn’t care one way or the other — they found all the answers when they selected their current toolchain. It’s them that we seek to influence by announcing CSS4.

In practice, all current outreach efforts such as conference presentations and blog posts or articles are aimed at the head. Not that the torso or long tail wouldn’t understand them, but they generally don’t seek them out. I would like to give them an incentive to do so.

In my opinion, “CSS4 is here!” would provide that incentive.

What do you think?

If you read this blog post you likely belong to the head. Based on your own experience you might not see the point of CSS4 because it doesn’t solve your problems. But CSS4 is not aimed at you; it’s aimed at the torso and the long tail.

When considering the pros and cons of CSS4, don’t reason from your own experience. Please put yourself in the shoes of someone whose time is limited, or who has never learned to pay a lot of attention to technical evangelisation. Will they be helped?

On the other hand, if your job, or your passion, includes evangelising CSS, you should definitely reason from your own experience. Will slapping on a “CSS4 compatible” tag help you?

So these are today’s questions. Will the announcement of CSS4 — new! shiny! cool! — spur on the torso and long tail to learn more about CSS? Will it help those who are already putting a lot of time and sweat into technical articles and presentations to reach a wider audience? Will it make a difference?

I think it will.

What do you think?

And if you agree with me, would you be willing to write something about it? That would show the CSS WG that there is developer support for this idea.

2020 is only three weeks old, but there has been a lot of browser news that decreases rendering engine diversity. It’s time for some good news on that front: a new rendering engine, Flow. Below I conduct an interview with Piers Wombwell, Flow’s lead developer.

This year alone, on the negative side Mozilla announced it’s laying off 70 people, most of whom appear to come from the browser side of things, while it turns out that Opera’s main cash cow is now providing loans in Kenya, India, and Nigeria, and it is looking to use 'improved credit scoring' (from browsing data?) for its business practices.

On the positive side, the Chromium-based Edge is here, and it looks good. Still, rendering engine diversity took a hit, as we knew it would ever since the announcement.

So let’s up the diversity a notch by welcoming a new rendering engine to the desktop space. British company Ekioh is working on a the Flow browser, which sports a completely new multi-threaded rendering engine that does not have any relation to WebKit, Gecko, or Blink.

The last new rendering engine to come to the desktop was KHTML back in 2000 in the form of the Konqueror browser. Later Apple adapted KHTML into WebKit. And then Google forked WebKit to become Blink. And ... well, almost everyone browses with a KHTML descendant now. Let’s not forget how it all began.

It is far too early to tell if Flow will have a similar impact, but the news was reason enough for me to conduct an interview with lead developer Piers Wombwell.

PPK: Hi Piers, could you please introduce yourself?

PW: I’m Piers Wombwell, the co-founder of Ekioh, the company behind the Flow browser. I’m also the architect of the project and one of the software engineers on it.

Why did Ekioh decide to create a new browser?

In 2006 we started developing an SVG engine for user interfaces in the set-top box market. No existing browser was full-featured, or was fast enough on the low-powered set-top box chips available at the time. User interface developers wanted HTML, but couldn’t get the performance they needed, especially in animations. SVG seemed better suited to user interfaces as there was no time spent in complex box model layout.

A user interface running on our SVG engine was much faster than any of the HTML browsers at the time and was very popular in this niche market with millions of STBs running it across most continents.

Over the next six or so years, STB chips started to move to multi-core GPUs, at the same as TV resolutions were moving to 4K. HTML was becoming fast enough on set-top boxes. On the other hand, a 4K TV has four times as many pixels as an HD TV, and a multi-core GPU doesn't make each individual core any faster. Thus, a single threaded browser won’t really see any significant speed improvements. That's why we decided to make Flow multi-threaded.

Dabbling with HTML/CSS layout seemed equally fun technically as building an SVG browser, so that’s been the main focus since. It started off being an XHTML/CSS layout engine on top of SVG, but we got carried away and over time moved to full HTML.

But, really, I suppose we did it because it would be fun to do it.

How far along is Flow? Can people download it and use it right now?

Well, it can render and interact with Gmail quite well. It’s pretty much perfect on a few sites we’ve targeted as focuses during development, but it struggles with many others. We only started implementing HTML forms in the last few months in order to log into Gmail.

It’s not yet available for download as I think we need to address the usability of it first. It currently needs a configuration file tailored to your computer, and has no toolbar. You don't want a toolbar for TV interfaces, so we never implemented one.

For which platforms is Flow currently available?

For Mac, Linux, and Android. Plus, of course, for the set-top boxes that are our main market, most of which run Linux. As to Windows, none of us run Windows so its development is untested and lags behind a bit, but I’ve just compiled a version and it seems to work.

Is Flow open source?

It’s not. There’s no current plan for that as we don’t have a large corporation backing our development.

Which JavaScript engine do you use?

We chose Spidermonkey in 2006, and as far as I recall it was because of both licensing and a documented embedding API. It was around the time that TiVo were having arguments over the GPL. The paranoia over that also ruled out use of LGPL licensed libraries for a few years.

The core browser code is abstracted away from any Spidermonkey APIs, largely so we could handle upgrades over the years - we can still handle its legacy garbage collection model quite happily.

What are your long-term goals with Flow?

The primary goal is stability, followed by getting more websites rendering perfectly in Flow. They generally fail because of either layout bugs or missing JavaScript APIs in Flow, so we have to solve those. Even for the embedded market, getting as many websites working as possible improves our confidence that a new HTML user interface will function correctly, first time.

Our roadmap is very flexible, usually because of commercial needs, but also we prioritise what’s interesting to a developer at that given time.

You said Flow is multi-threaded. Which tasks exactly are divided among the multiple threads?

HTML and CSS parsing is single-threaded, as is JavaScript (if you ignore WebWorkers). It’s the layout, primarily word wrap of text, that is done in parallel. Several caveats apply, but in general, two paragraphs can be laid out in parallel since they don’t impact each other apart from their vertical position.

We wrote some technical papers on this process.

Is the word wrap of paragraphs the computationally most expensive part of laying out an HTML page?

Yes. Each letter is a separate rectangle, plus you have word wrap rules for groups of letters. It’s also probably the hardest to achieve, so it's a good place to start. Desktop browsers haven’t touched layout, and have instead concentrated on making whole components run in separate threads.

Is Flexbox one of the caveats you mentioned?

There are multiple passes across the tree, all in parallel. We first calculate, in parallel, essentially the min-content and max-content widths of each paragraph, flexbox or table cell. Once we have those constraints, a relatively quick pass (not in parallel for that one flex box) works out the final widths of each box.

But we can handle multiple flexboxes in parallel, or one flex box and a paragraph outside the flexbox, and so on.

How integral is multi-threading to Flow and its architecture? Could you remove it? Would other browsers be able to copy Flow's multi-threading?

Multithreading can be turned off with a config setting. I suspect it’s always going to be easier to rewrite the layout code with multithreading in mind than rework existing layout algorithms - Mozilla took that approach that with Servo, rather than rework Gecko. The new layout engine could then, in theory, be combined with the rest of an existing browser.

Can you give an example of tricky problems you encountered while creating this browser?

Many sites, Gmail being a good example, were very frustrating as the JavaScript can be so large and obfuscated. It’s almost impossible to tell what they are doing, and much of the debugging was educated guesses as to what it was trying to do. Thankfully, the web platform tests help us make sure we are compatible with other browsers once we figured out the blocking bug or missing feature.

We can’t realistically pass these tests 100% as they test such a huge set of APIs - it would take us years to catch up with other browsers so we can only focus on what is used by priority websites.

And something that was much easier to implement than you thought?

The HTML parser. I first wrote an HTML parser back in 2002, and back then there was no detailed specification of how to handle badly-nested elements. We spent so much time writing test cases to figure out what desktop browsers did in each situation, and trying to behave the same. Ten years later, the detail in the WHAT-WG specification was amazing, and it was perfectly possible to write an HTML parser that is completely compatible with all other browsers.

And a feature you decided not to implement for now?

HTML forms. A TV user interface doesn’t use most, if any, of the features of HTML forms so it was a very low priority. We started adding them because they are needed for general web browsing, but they are not complete.

We haven’t yet implemented WebGL or IndexedDB because they are not used on most of the websites we’ve tried. Obviously Google Maps uses WebGL and Google Docs uses IndexedDB but both have fallbacks. Implementing more features to allow a larger number of websites to work is a priority.

What is Flow's UA string?

For the Mac version, it's the following:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_0) EkiohFlow/5.7.4.30559 
Flow/5.7.4 (like Gecko Firefox/53.0 rv:53.0)

The strings vary depending on the device, but the "EkiohFlow" and "Flow" strings should always occur.

Why do you emulate Firefox? I assumed it'd be Chrome.

We’ve spent ages on that UA string… I could probably write a blog post about it. Essentially, I copied Chrome. Things mostly worked. Then I hit the Instagram site, which decided to use ES6 features based on the UA string. I changed it to FireFox’s, using the version of SpiderMonkey that we were using (53 in the build you have), and the site worked. Then I added more afterwards (the rc:53) to get us to the more modern Google login box.

The UA string isn’t final at all but its choice is full of compromises.

Ekioh creates browsers for set-top boxes. What is Flow’s main purpose on set-top boxes?

It is used to render the UIs created by the box’s vendors, and not for actually surfing the web. But we don’t always get to see the UIs the vendors create, so being able to render all HTML flawlessly is the goal. That way, UI developers can do as they please.

Does the average set-top box have a browser meant for surfing the web?

Sort-of, but not really. I have a 2012 Sony TV with that functionality, but it was useless then and is useless now. IR has a significant lag, and that makes TV remotes far too painful to control a TV browser with. I don’t recall any modern TV/STBs that let you have open internet, but they probably exist. I can’t imagine anyone seriously using them.

Flow also runs on TVs and embedded devices. Could you give a few examples of embedded browsers? And TV browsers?

Back before we started our SVG engine, there were many HTML 4 browser engines for the TV market, such as ANT Fresco and Galio (which I also worked on), Access’s NetFront, Oregan, Espial and Opera. For the non-TV market, we have replaced Internet Explorer Mobile on a line of Windows CE devices. These days, almost all embedded browsers are based on Blink or WebKit.

What are your main competitors in the TV and embedded browser markets?

The main competitors to Flow are Blink and WebKit. Most STB providers often do their own port of one of these browsers. WebKit can be optimised for these low-powered devices, but Flow is usually able to out perform other browsers, and in the areas it’s not as fast, we can usually optimise it.

In a strange way, we also compete with ourselves - we offer our own embedded WebKit-based browser that is more feature-complete than Flow. The same developers work on maintaining and improving that.

Thanks for this interview!

You’re welcome.

If we want CSS4 to be a thing it is necessary to define it a little more. However, that does not mean it’s necessary to divide all existing CSS modules into CSS3 and CSS4 buckets. This article discusses these issues, and goes through some of the feedback to my original article.

Responses

My article led to a few responses. Louis Lazaris disagrees with me, and thinks we should stick to the individual modules, as we do today. I leave it to Dan Q to summarise my disagreement:

Nobody’s going to buy a book that promises to teach them “CSS3 Selectors Level 3, Fonts Level 3, Writing Modes Level 3, and Containment Level 1”: that title’s not even going to fit on the cover. But if we wrapped up a snapshot of what’s current and called it CSS4… now that’s going to sell.

In a comment, Ilya Streltsin points out that there are too many CSS modules, which makes them less suitable for high-level teaching and marketing. A list of twelve modules is inherently more boring than “CSS4.”

Still, Louis isn’t entirely wrong. We need to say something about what CSS4 is. Chris Coyier and Timothy Miller have some ideas that I’ll get back to below.

I think we should pick two or so modules that would become poster children for “CSS4,” mostly to raise awareness and enthusiasm among web developers who don’t follow CSS too closely.

CSS4 is undefined

Picking two or so modules is not the same as going through all of CSS and deciding which parts are CSS3 and which are CSS4. Therefore Johan Ronsse’s fears are unfounded:

As a teacher of sorts, I for one don’t want to explain the difference between CSS3 and CSS4 to junior web devs. There is simply no point. CSS is just CSS. We should be happy that it’s stable. We should be happy that we dropped the 3.

CSS modules are not CSS3 or CSS4; they’re just CSS. The term “CSS4” is meant to draw people to your teaching, but once you have their attenton you largely drop the term and just teach them what they need to know.

Instead of attempting to define it, we should airily refer to CSS4 but be rather vague about what it means exactly. That allows people to project their own feelings and ideas onto it. CSS4 is here, and it means whatever you want it to mean. Now come and learn. It’s cool!

Remember: this is a marketing exercise; not a technical description of CSS.

Setting minds at ease

Nonetheless, in order to prove that CSS4 is cool we need a few example modules. “Learn CSS4! It allows you to do X and Y!” Which modules should we pick?

When I was a history teacher, long ago, I learned one valuable trick: when writing tests for students, always start with a simple question that all of them know the answer to. The purpose is to put the students’ minds at ease and make them feel they know at least something about the topic.

For instance, if they have to learn the chapter on the French Revolution, start the test by asking “In which year did the French Revolution take place?” The chapter prominently states the answer, 1789, in the first two paragraphs, so you can be reasonably certain that almost all students have actually learned this by heart. So they’ll sigh a breath of relief, give the correct answer, and gain more confidence for the rest of the test.

I feel we should do something similar f0r CSS4. One of the modules we tout as “CSS4” should be one that even people who’re not all that good in CSS have used and know a little bit. That’ll make them feel that they already know something about the subject, so the rest shouldn’t be too hard. It will draw them in.

CSS4 — the known parts

Chris Coyier created a draft list, and Timothy Miller added a few ideas. The first module Chris mentions is Flexbox, but he notes it may be too old. Sadly, I must concur. Flexbox would have been a brilliant “set-your-mind-at-ease-CSS4-is-not-as-hard-as-you-think” module, because almost everyone has heard of it, and plenty of people who are otherwise not terribly into CSS have used it.

Unfortunately it’s really too old: if we’d use it as our poster child people might lose the suspension of disbelief that’s necessary for the CSS4 trick to work. “Huh? Flexbox? But that’s been around for ages!”

Grid is the obvious next option. It’s not too old, and some people have heard of it and use it. On the other hand, I learned doing research for the book that there are some web developers who feel they don’t have to learn Grid because they already know Flexbox. And both are for layout, right? So why learn two?

As an argument this does not make any sense, but the fact that this ideas is floating out there means using Grid as a poster child might backfire. (I’m not sure; I’m just guessing here. But my gut feeling says that Grid is the wrong module.) Update: I changed my mind: grid should definitely be part of CSS4.

For now I settled on CSS custom properties (or variables) as my choice. They are in use, but they’re not yet old news. More importantly, custom properties allow local scope in CSS, and that is quite important to JavaScripters and might draw them to the right articles and teachings.

I’m not quite sure yet if this is the best module — I’m open to arguments. But I have to say something, and this is where I stand right now.

CSS4 — the unknown parts

In addition to the well-known set-your-mind-at-ease module we should also have soemthing that’s really, really new. The idea would be to tout two modules as “CSS4.” People would lose their fear after recognizing custom properties, while the other module would intrigue them, and they’d be excited to learn about it.

But which module? I’m not sure. Chris mentions Houdini, CSS nesting, variable fonts, and offset paths as possibilities. Timothy adds media queries level 4 to the list. Chris also says:

Lemme just say I will personally spearhead this thing if container queries can get done and we make that a part of it.

Container queries would be suitable. Developers who predominantly use JavaScript would like to have them.

Unfortunately they’re not there yet. So although they’re an excellent choice for a future module (“CSS4 will eventually include container queries”), they won’t help us right now.

So ... does anyone have a useful suggestion for a new CSS module that is not well known yet, applies to more than just a subset of CSS, and that we can start teaching right now? (Lack of general applicability is my problem with variable fonts and offset paths.)

Houdini? I’m afraid its complexity will detract from learning simple CSS, so I’m not sold. Level 4 media queries? I feel there’s too little difference with level 3.

So I don’t know right now. I’ll continue to think about this, and meanwhile I’d appreciate hints and ideas.

I’m writing the Box Model chapter of the new book and came to the point where I had to treat negative margins. To my surprise, I found that there is no systematic treatment of negative margins anywhere. So I had to figure it out for myself. Below is my initial draft of the negative margin section.

The latest specification only says: “Negative values for margin properties are allowed, but there may be implementation-specific limits.” and leaves it at that. Not extremely helpful. MDN is mostly silent as well, and Rachel Andrew’s big overview article doesn’t mention negative margins at all.

That’s odd, especially since negative margins are a very old functionality that I might even have used in my very first CSS test somewhere back in 1998. (Unless I used position: relative; I can’t remember.)

But anyway, here is, apparently, the first-ever systematic treatment of negative margins in simple situations.

Negative margins in CSS

It is possible to give margins a negative value. This allows you to draw the element closer to its top or left neighbour, or draw its right and bottom neighbour closer to it. Also, there is an exception we’ll get to in a minute.

Here is our test element: a simple container with three paragraphs in it. Note that the paragraphs have a width of 250px. This is extremely important, due to the exception we’ll get to in a minute.

Negative margin-top and -bottom

To start, let’s give the first paragraph a -15px margin-bottom. Essentially, when the browser calculates the point where the second paragraph should start, it moves that point 15px upward. From then on the browser lays out all paragraphs as normal.

Therefore the second paragraph, being the bottom neighbour of the first one, is draw 15px closer to the first paragraph. The margin between the second and third paragraphs remains intact; the browser calculates it normally. Thus, the rest of the vertical rhythm is preserved.

This trick is useful for subtle tweaks, where the content of one element should slightly overlap the content of the one above it.

Now let’s give the second paragraph a -15px margin-top. As you see, this yields exactly the same effect. Again, the second paragraph is moved upward by 15px, and the subsequent paragraphs follow.

Margin collapsing

Also note that margin collapsing behaves different when you use negative margins. This, at least, is specified in CSS 2.1:

In the case of negative margins, the maximum of the absolute values of the negative adjoining margins is deducted from the maximum of the positive adjoining margins. If there are no positive margins, the maximum of the absolute values of the adjoining margins is deducted from zero.

In the last example, the first paragraph still has its default margin-bottom of 1em (Chrome; can’t find Firefox’s value).

Normally, the browser would take the first paragraph’s margin-bottom and the second one’s margin-top, figure out which one is larger, and apply that margin between the two, which would yield max(-15px,1em) = 1em. That’s not how it works, though.

In case of negative margins we take the absolute values of the two adjoining margins (15px for the second paragraph; 1em for the first), and deduct the smaller (15px) from the larger (1em). This yields about 1px (depending on the font size, of course).

Thus, negative margins are actually allowed to pull elements closer to their neighbours without being hindered by regular margin collapsing.

Now we treated negative margin-top and -bottom fully. It’s an occasionally useful effect.

Negative margin-left and -right

Negative margin-left and -right work the same, provided the element has a width. Here we apply margin-left: -10px and margin-right: 10px.

As you see, the first paragraph is now offset 10px to the left, while retaining its width. Thus, its right edge also moves 10px to the left.

The second paragraph with the negative margin-right is unaffected. The negative margin-right would influence any element to the right of the second paragraph, but there aren’t any.

To show negative margin-right in its full glory, let’s float the paragraphs, so that they have a right neighbour. Here is the reference element.

Now we’re going to sprinkle some negative margins on the paragraphs.

As you see, the second paragraph is now drawn 10px closer to the first one due to the first’s negative margin-right. This is exactly the same effect as with a negative margin-bottom.

Also note that the second paragraph has a negative margin-top, which means it is offset 10px upward. The third paragraph has a negative margin-bottom, which has no effect, since it does not have a bottom neighbour.

Remember: margin collapsing does not work on margin-left and -right; just on -top and -bottom. Therefore we do not have to worry about it in this case.

If we give the second paragraph a margin-left: -10px, the same happens. Just like with top and bottom, left and right are interchangeable for this effect.

So far, negative margin-left and -right behave exactly like negative margin-top and -bottom.

width: auto and negative margin-right

Now let’s change the behaviour of negative margin-right by giving the paragraphs width: auto. They do not have a fixed width any more; instead they fill up their parent element completely while respecting its padding. That’s how width: auto works.

The paragraph with margin-left: -10px is still offset 10px to the left, but its width grows. Thus, its right edge is not offset but stays where it is.

The negative margin-right now does the same thing. It offsets the paragraph’s right margin by 10px to the right, and the paragraph’s width increases, causing its left edge to stay where it is. This only happens when an element has width: auto. As we saw before, elements with a fixed width behave quite differently.

Finally, the third paragraph has both. Both its left and its right margins are offset by 10px, essentially negating the container’s padding: 10px;.

This is by far the most common use case for negative margins. You give a container a padding so that its contents have some breathing space. However, you want the header to span the entire container, ignoring the padding. Negative margins are the way to go.

These are the header styles; the container has padding: 10px

h5 {
	margin-left: -10px;
	margin-right: -10px;
	padding-left: 10px;
	margin-top: 0;
	margin-bottom: 0;
	background-color: grey;
	color: white;
	/* no width, so defaults to width: auto */	
}

Again, this is only possible if the header has width: auto. Fortunately that’s the case in 99% of real-world use cases.

This is how negative margins behave in simple situations. Now that I established a baseline I can look into how they behave in flexboxes and grids.

Links in times of chaos.

• Laura Schenck, whose thoughts on programming CSS are very interesting anyway, discusses a project where she had to battle specificity. Key thought:

  Specificity breeds, much like conditionals breed in imperative languages [...]. Adding specificity is adding conditional logic. Once you start adding that logic, the code-base snowballs and it becomes difficult to understand, and thus difficult to maintain.

  She also asks if anyone who writes CSS should understand specificity to this degree. My answer is a firm Yes, just like you're expected to understand if- and for-loops when programming in any other language.
• Rachel Andrew ponders the pros and cons of CSS4. She is afraid that people will get confused by “CSS4” because several articles said there will never be a CSS4, and the version number 4 does not align with the version numbers of existing modules. Although both are true, I seriously doubt whether the people that “CSS4” is aimed at (those I call the torso and long tail of the CSS world) are aware or care. To me, this argument is overly legalistic, in the sense that it doesn’t matter in the real world.
  A much more important argument is that the announcement of “CSS4” will make people expect a list of new features that work in all browsers. In itself that’s great, and I think it would be really helpful, but the problem is that someone will have to decide what goes on the list and what does not — and the CSS WG is already stretched thin and cannot spare the time to do this. Maybe we need a community effort to help them? Worth thinking about.
• Interesting Twitter thread on why CSS is perceived as simultaneously very simple and very complicated.

  Because we think it's a simple language, we don't dive deep into it like we do with "real" programming languages. background: blue; makes the background turn blue, why should we bother diving in?

  But then it's time to build a layout and suddenly the combination of user agent styles and a lack of understanding in the fundamentals of CSS makes things break, or not behave how we expect them to.

  Yup.
• Mostly for myself: the difference between defer and async on script tags. Or, as Nicholas Zakas puts it:
  • Do it now: <script src>
  • Do it later: <script defer src>
  • I don’t care when you do it, just not now: <script async src>
• Coil, the web monetization company, offers some interesting but too-much-under-the-radar thoughts on probabilistc revenue sharing. The idea is simple: if A, B, and C cooperate on a to-be-monetized article, and A is allotted 60% of the revenue, B 25% and C 15%, you simply add those probabilities to your payment pointers. Eventually a tool will draw a random and assign a specific payment to a specific author, but for now you can use a script to emulate that behaviour.
• Google proposes to sunset the User Agent string by freezing its version number and removing device information. The purpose here is to make fingerprinting (combining UA string, IP address, TCP/IP settings, device information and a host of other bits and pieces to accuratenly identify a web user) more difficult.
  The UA string will be replaced by client hints that give web developers some information about the browser, device, and platform. These hints will likely be more generic than the UA string, and thus hamper fingerprinting.
  The second problem with UA strings is the eternal arms race between clueless web developers and browser vendors, where web devs start using a certain badly-written browser detect, which forces browsers who want to end up on the good side of it to adjust their UA string, so that it gathers more and more cruft. (This is the reason every single browser string out there still starts with Mozilla.) I do not see this arms race go away. For instance, if the new Flow browser wants to defeat new browser detects written with client hints by clueless web developers, it will most likely be forced to announce itself as Chrome. Worse: we lose the ability to accurately identify it as Flow. As a result, new browser stats will make it appear as if Chrome is even more dominant than it actually is.
  Maybe we need another field Sec-CH-RealUA or something, where the browser can use its true name. On the other hand, that will be more fodder for clueless web developers and will perpetuate the arms race.
  In any case, to me it seems that more-or-less-accurate browser statistics will be the most important casualty of this switch.
  
  Related links (mostly for myself): client hints as currently implemented; discussion on a previous Safari attempt to do something similar; Blink intent to ship
• Mozilla and KaiOS Technologies are going to cooperate on future versions of KaiOS, the operating system for “smart feature phones” (read: cheap phones) that’s based on Firefox OS. Included in the article is a whole list of features Mozilla will work on, but they essentially boil down to keeping KaiOS updated for the ever-evolving web.

  Broadly speaking, these updates will mean many first-time internet users gain access to more of the web’s advanced digital services on devices that are affordable, reliable, and secure.

  Remember: KaiOS is aimed at not-so-rich people from emerging markets. As of May 2019 there were about 100 million devices out there. That’s piss poor compared to iOS and especially Android, but let’s see if their use explodes or not.
• Have a tip for the next Linkbait? Or a comment on this one? Let me know (or here or here).

To the surprise of exactly no one, we cancelled CSS Day 2020, originally slated for 11th and 12th of June. In this post I’d like to explain our reasoning, and call for a gesture of solidarity and support to small, independent conference organisers.

All CSS Day attendees received a mail with details about the reimbursement process. If you did not receive it we do not have your correct email address on file, and you should contact us.

Being a good attendee

If you want the independent web conference community to continue to exist in the future, there are a few things you can do for your friendly local conference organiser.

1. Make sure they can reach you. Check your email address in their sales system.
2. If the conference offers the option, and if you can afford it at all, allow them to move your ticket forward to the next edition. This will give them some financial breathing room. See it as an interest-free loan aimed at preserving the ecosystem all of us built.
3. Be understanding of delays and uncertainties. All conference organisers must chart their own course, and some will be taking a wait-and-see approach, especially if their conferences are scheduled for late June or beyond.
4. If conferences do run, be accepting of a sharply diminished experience. It is very likely that conferences sell way fewer tickets than usual, and the most obvious way of saving money is removing luxury items such as nice extra catering options, afterparties with free drinks, diversity tickets, captioning, possbily even wifi. Speakers may be asked to waive their speaking fee. The entire conference might be moved online. Be accepting of such occurrences, and remember that they’re aimed at allowing the organisers to support themselves and their families.

A good example of the last point is the perfmatters conference over in the US. It switched to an online conference, but offered no refunds for the sharp decline in experience because the money was already spent. As a partial recompense, all attendees were allowed to invite someone else to the online conference.

I fully support Estelle in this difficult decision, but at the same time I’m glad I don’t have to do the same.

More in general, the question is whether we want the independent web conference community to survive. (I do, but I’m biased.) If we stick together, and attendees are accepting of cancellations, sharp service level declines, and possibly even loss of money, we might survive.

If we don’t, in a few years we’ll only have corporate conferences with a corporate agenda to attend.

Your choice.

Being a good sponsor

As a sponsor, there are also a few things you can do:

1. If you can afford it, and the sum is not too large, allow cancelled conferences to retain your sponsorship money, possibly as a down payment for a sponsorship next year.
2. Be accepting of point 4 above. If you had earmarked your sponsorship for a specific purpose, be prepared to waive that purpose.
3. That last point will likely remain true for the next year. Please do not earmark future sponsorships, but allow the organiser to spend it as they see fit — and that includes avoiding personal bankruptcy.

Conference finances

Just so you understand my perspective: with one stroke I lost 1/3rd of my annual income. The situation is dire, though fortunately not hopeless. Other conference organisers are hit even harder.

The real question for me personally is whether performance.now(2020), 12th anf 13th of November, will run. Right now we think it will, but if it doesn’t I lose another third of my annual income and I have a real problem.

CSS Day was still far removed from the break-even point. That was completely expected at this time of the year, and even ten days ago we didn’t worry about it. Now, however, we must work with a scenario where we will not sell any more tickets, and where some current ticket holders will ask for a reimbursement. Thus, the financial risk of running the conference has gone from fairly low to enormous. This informs all decisions we took.

A small, independent web conference of our type breaks even when about 60-75% of the tickets are sold. Any number below 60% means that the organisers will have to pay money out of their own pocket.

We try to keep prices relatively restrained, that’s why the break-even point is so high. Huge corporate IT conferences have quite different break-even points, especially if they use the sponsor money to actually pay for the conference and put the complete proceedings of the ticket sales in their own pockets.

June cancelled

It is possible that the de-facto travel ban will be rescinded by early June. The big question is when exactly that will happen. Even if we are absurdly positive and say that we’ll be out of the woods by late April or early May, people will still be understandably concerned about their health, and will not be amenable to booking a trip for the next month.

That means that, in practice, even in a fairy-tale positve scenario we will sell way fewer tickets than last year. It is quite likely we will stay below the magical 65% line that breaks us even. Remember: every single cent we’d pay would come from our own pocket, since we’re going to reimburse the tickets and lose that money. The risk is simply too big, and we decline to run it. The organisers of the XOXO festival explain this problem more clearly than I can.

An added benefit is that we have not yet made any large payments to the venue and the hotel, and if we cancel now we won’t have to. Our suppliers are understanding of the situation, and it appears that the only costs we have to pay is a single speaker flight. That’s manageable.

Online conference? Nope

So: no physical conference in June. But what about an online conference or a postponed one?

Moving conferences online is frequently suggested on Twitter — mostly by people who have no experience in organising conferences. Sure we could try to do that, but there are considerable downsides:

1. Will our audience buy tickets for an online-only conference? Our mailing lists and past audience have self-selected for a desire to attend a physical conference, where not only the talks, but also the social gatherings in the hallways are very important. Some people don’t like that, but our audience very much does.
2. The ticket price would have to be significantly lower than for a physical conference. Of course, the costs would also be significantly lower, but a much lower ticket price still means much less profit per ticket. Financially, it might work. Then again, it might not. We just don’t know.
3. What about our current ticekt holders? Our ticketing system allows us to reimburse them (and we will do so), but it has no option to partially reimburse the tickets of those attendees who’d like to switch to the online conference. We’d have to go through a manual process of invoicing and reimbursing that is likely to take a LOT of time.
4. Then we’d have to find suitable software for online conferences. No doubt there are quite a few good options, but since we have no experience it would take us a long time to pick one.
5. The biggest problem with online conferencing software is that we cannot test it. If something goes wrong on the conference day itself, we essentially do not know what to do, attendees become dissatisfied, and our brand suffers. People might even ask for a reimbursement — and we can’t even tell them they’re wrong.
6. The massive uncertainty that comes with the software will have caused us to live in a state of ultra-stress for weeks, and that is not conducive to reasoning and clarity of thought.
7. Finally, all of this would take a lot of extra time that we cannot spend on other jobs. Although it’s possible we would make some money, it’s also possible that we won’t. The risk is too high.

So our huge time investment and stress load might not actually pay out, and I personally might still be left with a gaping hole of about 1/3rd of my annual income after spending way too many weeks on a solution that didn’t work, left everyone dissatisfied, and precluded me from doing other work while stressing me out so much that I have to take a few weeks’ break without having any money.

I will not go that route. The risk is too high.

Postponing? Nah

Postponing the conference is a more realistic approach. But to which dates? The venue was kind enough to offer us early September dates, but we doubt those are going to work.

Same problem as always: will people buy tickets? They might, but they might not. The risk is too high.

There are additional risks, as Niels Leenheer, who was recently forced to cancel the Fronteers 2020 conference, outlines in a recent article. If many conferences move to fall dates, they will compete not only with one another, but also with the regularly-scheduled conferences that would take place in fall anyway. It’s a lose-lose scenario for everyone.

Part of conference organising is the careful planning of the date. You do not want to be too close to similar conferences, and you’re bound to conference season anyway, which stretches from early March to late June and then from mid September to early December — at least in Europe.

Moreover, once you have a time slot that you have used for several years in a row, your attendees — and your competitors — adjust to that. Changing it is something not to be considered lightly, and will affect not only your own conference, but also other ones planned around the new dates. Solidarity requires us to stay away from the time slots of other independent web conferences.

Also, speakers may have other obligations by that time, or they might still decline to come due to health concerns. All this is entirely understandable, and while we have built up a great network of supportive former speakers who would probably be willing to help us out, it wouldn’t be the conference our attendees bought a ticket for. Besides, it would mean repeating speakers year over year, something we generally try to avoid.

Finally, this would cost us some extra time, though not nearly as much as moving the conference online. Is it the wisest course of action to spend that extra time on postponing the conference instead of looking for other jobs? I don’t think so.

The risk is too high. It’s far better to write off CSS Day 2020 entirely and use the freed-up time to make money in other ways.

***

So that’ where we stand right now. The independent web conference community is taking a severe hit, and we are no exception. Still, we aim to return.

There’s one silver lining: when all this is over there will be pent-up demand for conferences. Plenty of people enjoy going to them, and while skipping one is not a great hardship, skipping an entire conference season might be. So with a little bit of luck our conferences might return to normal in 2021.

If we stick together and show some solidarity we can survive this.

Stay healthy,

Inspired by Brad’s recent post, here’s a scattering of thoughts I had about things other than conferences (I already wrote about those.)

***

Amsterdam runs in idle, but it runs. That is good to see. As far as I know all cities run in idle right now, but are still running.

Civilization, society, and probably the economy as well, will not collapse. This is no extinction event, just a very bad spell. We will recover.

***

We can give up on the rest of the school year. In Holland the central examinations are cancelled for the first time since 1945. I am in touch with a bunch of 15- and 16-year olds, children of friends and their friends, that I play D&D and board games with. I mainly think of them in this item. I also think of the students I’m currently teaching (online) at university, who are around 20 or so.

Once social distancing is over they will likely go into party mode for months on end. It will be very difficult to get them to pay attention to school or studies, and in my opinion we shouldn’t try. They’re right.

(Note to self: figure out how the people born around 1330 fared after the Black Death. Re-read Froissart.)

Also, I predict a slight uptick in teen abortions during summer.

***

I’m teaching at university right now, and it really goes remarkably well. Still, this is the web faculty, which is the one faculty that’s most likely to adapt seamlessly to the current situation, since not only the students, but also the teachers are well at home on the web. Other faculties might likely have more problems — think a classics professor who never clicked on anything because Aristotle and Cicero didn’t either.

***

Twitter is a cesspool. I don’t go there any more. I get very tired of all the enraged Americans in particular, who think that the specific problems of their country are the most important ones in the world. Not fair, maybe, but that’s how it is. Deal with your orange monkey yourself, we don’t have the time for it.

***

I am supposed to be writing a book. I am currently not writing a book. But last week was very hard (teaching while cancelling a conference for the first time is not my favourite mix of activities), this week will be moderately busy, and we’ll see next week.

***

Eric said websites should get static, because the React monstrosities that rule the web now are too fucking slow and expensive on mobile devices, and people need information right now.

We should rule that important government websites are not allowed to use JavaScript at all. That’ll solve the problem.

Sure, reality is more nuanced, good JavaScript use is possible yaddah yaddah, but right now is not the time for nuance. We need one simple rule that actually does away with the problem and that even idiots understand.

So skip the JavaScript entirely. It’s just fluff. Do away with it.

***

I stopped paying taxes for the first time in my freelance career. Without taxes, I can probably hold on to November or December even without any extra income beyond what I already invoiced. This is definitely better than I initially thought, when I had to say goodbye to 1/3 of my annual income.

***

My first online D&D session was an astounding success. I use Whereby and I swear by it. (Install app for iOS; rest just works in the browser.) I have a Pro account, so my room accepts 12 connections simultaneously.

I used two devices as cameras on the battle mat and the initiative tracker (I use a slightly modified version of this initiative system), and my laptop for an image of myself and to see the players. Rolz for die rolls, Whatsapp for private communication between DM and one player, and that’s it, really. I occasionally added a fourth hand cam with an extra phone, but I could do without if necessary.

The only problem is that it turns out to be impossible to turn off sound entirely on the iPad. There are online instructions that claim otherwise, but they don’t work. Still, just now I realised I should kill all video feeds to the iPad except for its own; I only use it as a glorified web cam.

***

A lot is being said about mental health, and it’s all true. I also suffer a little bit — on average I get Corona about three times per day, but when I forget about it for five minutes my symptoms mysteriously disappear. I assume others have the same problem.

Many good points have already been made, and I’m not going to repeat them. The historian in me wants to make another point entirely.

Once upon a time, not so long ago, this feeling of permanent stress and helplessness, multiplied by two, three, or even four, was the natural state of being of just about all humans. Plagues, wars, famines, too-high taxes, they could all arrive at your doorstep, and in an average year at least one (most likely taxes) did.

People lived like this all the time. They were not aware that it is possible to live in any other way. The stress you’re feeling now is about one-half to one-quarter of what everybody felt all the time during most of human history, and before. As a result, all of them had PTSD. All of them. That’s why assholery is so widespread during all of history (except, in some parts of the world, for most of the people, for the last sixty years or so).

This is what we’re fighting for. We fight for our children to have the chance to live as we did, without constant fear.

Remember that. It gives you a goal to shoot for.

***

Jeremy is right. Writing helps. I feel better already.

One of the things that keeps me fairly upbeat these days is playing board games and D&D with my friends online. Since others might want to do the same, I thought I’d jot down some notes on how I do it.

I briefly tried Tabletopia but didn"t like it. I understand why they built the interface as they did, but I found it very hard and very confusing to use, and it took us about 45 minutes to even start understanding the system. Granted, we picked Teotihuacan for our test game, which may not have been the best of choices.

So I continued using my homebrew system, and it works great so far.

Technical set-up

I use Whereby (the former appear.in), a WebRTC service that works absolutely GREAT. I totally recommend it to everyone for your online communication needs. The greatest thing about it is that you just go to a URL, ask the people you want to communicate with to go to the same URL, give permissions, enter the room, and start talking. No sign-ups or logins or whatever.

I have a pro account (or whatever it’s called) that allows 12 simultaneous connections to my room. You can also just grab a room name, go there, and start communicating, but these free rooms have a maximum of four simultaneous connections. So I advise you to take a paid account; you will most likely need more than four connections for playing board games online.

Besides, fuck free. The free Internet is slowly coming to an end and you should pay for services you like and use, or they won’t survive (or sell your data; see also Zoom).

Whereby works on modern Chromium-based browsers, and also in Firefox (though I haven’t tried Firefox on Android yet). It does not work in Safari iOS, but an app is available that works as simply as the web client.

Then figure out how many devices you own that you can use. On the whole, I send out three streams: my 'social' stream (my face, basically) from my laptop, the main board stream from my iPad, and a secondary board stream from a Samsung S6 I happened to have lying around. I occasionally use my real Samsung phone (an S7) as a third cam, for instance to make sure that everyone has the same bits and pieces on mirrored player boards.

Plug in all devices you use, and make sure any phones are on at least 25% charge or so before starting. My Samsung phones, especially, tend to spend a lot of juice on keeping the streams running, and even though plugged in all the time they might end up with less battery charge after a gaming session.

Mute Whereby on all devices except for your social stream. One very annoying thing I noticed is that, both on the iPad and on the Samsungs, it is impossible to turn off the sound completely. Therefore you need to do two things:

1. Disable sound input by clicking on the microphone icon in the bottom bar.
2. Disable sound output of all connections by clicking the Mute option in the menu you get after clicking on the three bullets icon in the upper right corner. You must repeat this for every connection.

You can only mute the output once everyone else has joined the stream. If someone drops out and re-joins you must mute them again. This is annoying; but it’s caused by idiotic device vendors not allowing you to mute the sound completely by using the provided hardware buttons — don’t ask me why they took this stupid step.

Now ask the others to join you. If possible and necessary they can also add their own cameras, for instance to show their player boards.

Picking the game

With the technical set-up out of the way, you should pick your game. I found that there are two absolute necessities here:

1. All players must own the game, so that they can copy the moves of the other players.
2. The game should have little to no hidden information.

So you might need to buy the same game as your friends. If you are in the Amsterdam area, please support your friendly local game store Friends & Foes instead of the big online retailers. Friends & Foes deliver in Amsterdam (I just ordered Tzolkin from them).

The two games I played most often so far are Azul and Alchemists. I am currently gearing up to try Madeira, Istanbul and Tzolkin; they should work as well.

Azul, Madeira, and Tzolkin have no hidden information at all. They have a variable set-up (and in case of Azul this is repeated each round), but that should be no problem.

Appoint one player or group of players as the Master; the other ones have Copies. The Master players draw all the randoms and show them to the other players, who copy them on to their Copy boards. Having the Master set provide all random draws is very important, since usually quite a bit of design thought went in to deciding exactly how many of one type of card or tile are available. These distributions should not be disturbed!

Azul

With Azul it is very important that all players set up copies of all other players’ personal boards. Part of the game is figuring out which tiles other players are likely to want, and for that all players need an overview of who has which tiles in which position.

Wnen I stream Azul, the main camera is on the central part with the available tiles. Other players can copy that if they like, but it’s not really necessary if the stream is clear enough. My secondary camera is on my own player board, so that everyone can see what I’m doing.

During the game all players clearly state their moves; for instance “I take the two blues with the star, and I put them on my three row.” I take the tiles from the central part, and the other players see me doing that, so they can correct me. They don’t see my copy of their playing baords, but that has never been a problem yet, as long as everyone gives clear instructions.

Alchemists

Alchemists does have a little bit of hidden information: random ingredients drawn, and random helper cards we always call Friendly Friends. (I forget their official name.) The Master player draws these cards for me and shows them on their camera without looking. I take the corresponding cards from my own copy of the game. This works fine, and the distribution of ingredients and Friendly Friends remains intact.

Alchemists really only needs a Master main board stream and social streams; there is no reason to add more cameras.

Although Alchemists’ board is pretty big, it doesn’t contain all that much information, which is good for online gaming. I just need to see which artifacts and ingredients are drawn (and copy them to my own board), and where players place their action cubes (and copy them as well). If I can’t see it clearly I just ask, and that works fine.

Part of Alchemists becomes much easier. In real life every player needs a beautifully-designed but sometimes cumbersone player contraption to both visualise their research and hide it from the other players.

Credit: Karel_danek

Online, it’s not necessary, and I find that my research and thinking flows much easier. Other players cannot see my board, and that gives me a lot more space to work with.

Madeira, Istanbul and Tzolkin

I haven’t played Madeira, Istanbul and Tzolkin yet, but they do not contain hidden information; just start-of-game randoms, plus the random buildings that occasionally appear in Tzolkin and the bonus cards in Istanbul. I do not think these will cause a problem.

The bigger problem might be that their boards are much more involved, and there’s a lot of game state to track. I might need to use two cameras to stream them accurately; I’m not sure yet. We’ll figure that out once we do the first session.

When I joined OneSignal I was a design team of one so part of my job was establishing the toolset and workflow.

I had been tinkering with Figma on and off for about a year but had resisted going all in. On my last team we were comfortable with our design stack of Sketch, InVision, Abstract, so the thought of switching to another tool, moving things across, and having the team move across, wasn’t appealing.

With a clean slate at a new company, it seemed like the perfect time to start using Figma in earnest. This is my experience so far.

Read the full post here

tl;dr: If you just want to quickly get stats for a repo, you can find the app here. The rest of this post explains how it’s built with Mavo HTML, CSS, and 0 lines of JS. Or, if you’d prefer, you can just View Source — it’s all there! One of the cool things about […]

I was always interested in color science. In 2014, I gave a talk about CSS Color 4 at various conferences around the world called “The Chroma Zone”. Even before that, in 2009, I wrote a color picker that used a hidden Java applet to support ICC color profiles to do CMYK properly, a first on […]