This week, I attended my now third W3C TPAC. After TPAC 2017 in Burlingame, CA, United States of America and TPAC 2018 in Lyon, France, TPAC 2019 was held in Fukuoka, Japan. For the first time, I felt like I could somewhat meaningfully contribute and had at least a baseline understanding of the underlying W3C mechanics. As each year, the TPAC agenda was crammed and overlaps were unavoidable. Below is the write-up of the meetings I had time to attend.
On Monday, I attended the Service Workers Working Group (WG) meeting. The agenda this time was a mix of implementor updates, new proposals, and a lot of discussion of special cases. I know Jake Archibald is working on a summary post, so I leave it to him to summarize the day. …
On the Google Chrome team, we’re working on solving the interesting problem that some platforms like Windows 10 show a native ← Back button in the app window’s title bar when the user has navigated into a standalone or fullscreen Progressive Web App (PWA). This can lead to PWAs inadvertently showing two means of in-app navigation: one from the operating system and one from the app itself. The screenshot below from Twitter’s PWA illustrates this issue well. The two back buttons are highlighted in red, the Windows-generated button is in the title bar.
In order for PWAs to be able to detect the presence or absence of system-level navigation controls, we’ve proposed a new, aptly named CSS media query called
navigation-controls. The Explainer goes into great detail on how this media query works, but the most basic way to use it can be seen in the code sample below. …
While preparing for my presentation at the Google Developer Days 2019 in Shanghai, China I was reminded again that China is a market where few super apps like WeChat host a gazillion mini apps or mini programs that fulfill everyday needs like booking cabs, reserving tables, etc.
I got curious and downloaded the SDK and after playing a bit with the Your First Mini App tutorial, I realized the whole thing is so close to building for the actual web, it both fascinates, intrigues, and honestly somewhat infuriates me.
(Originally published on https://web.dev/prefers-color-scheme/.)
📚 I have done a lot of background research on the history and theory of dark mode, if you are only interested in working with dark mode, feel free to skip the introduction.
We have gone full circle with dark mode. In the dawn of personal computing, dark mode wasn’t a matter of choice, but a matter of fact: Monochrome CRT computer monitors worked by firing electron beams on a phosphorescent screen and the phosphor used in early CRTs was green. …
A couple of weeks ago, I have collected feedback regarding people’s preferences when it comes to re-colorization of websites for dark mode. The core research question was: “Do people expect images to look different in dark mode than in light mode?”
I created a little Dark Mode Colors 🌘 Re-Colorization Playground app that allows people to toy around with different re-colorization options and report their preferences in a survey. The playground app was shared on Twitter and also on multiple Google-internal misc mailing lists with both technical and non-technical audiences.
I’m now happy to briefly report on the results. All in all, I have collected 137 responses, the raw results are available in this spreadsheet. The majority of people (57.7%) preferred a grayscale filter, 40.9% of people preferred no filter (that is, leaving the colors as-is), and a tiny fraction of people (1.5%) preferred a combination of grayscale and inversion filters. No one liked inversion in isolation, which is in accordance with findings from Szpiro et al. in their paper How People with Low Vision Access Computing Devices: Understanding Challenges and Opportunities. …
With Dark Mode, Apple in macOS Mojave introduced what they call “a dramatic new look that’s easy on your eyes and helps you focus on your work. [It] uses a dark color scheme that works system wide, including with the apps that come with your Mac.” The Safari browser doesn’t allow Dark Mode to automatically change the appearance of web pages, but in Safari Technology Preview 68, Apple added support for the
prefers-color-scheme user preference media query that allows developers to manually style their content for Dark Mode. There also is a meta tag
<meta name="supported-color-schemes"> and corresponding CSS property
supported-color-schemes that are currently being standardized so that sites can explicitly express that they fully support a dark theme and that the browser should load a different user agent stylesheet and not ever apply transformations. The media query is supported in Firefox since version 67 and Chrome started work on it. This media query enables (and also requires!) CSS designers to craft special CSS rules for Dark Mode, however, not everyone will do this! So where does this leave us? …
🚨 Update: you probably want to read the more up-to-date article https://web.dev/color-scheme/. The present article was written before full standardization of the feature when some things were still undefined.
The Release Notes of Safari Technology Preview 71 mentioned two new dark mode features:
• Added experimental support for a
supported-color-schemesCSS property (r238001).
• Changed the default document background and text colors in dark mode and when
darkis listed as a
supported-color-schemeson the document or body element (r238212).
These were renamed to just
color-scheme in Technology Preview 81:
• Standardized the
The other day, one of my former Google Mobile Solutions Consultant colleagues sent an email to an internal mailing list that (paraphrased) went like this:
“I was shocked that during now more than two years of supporting Service Worker implementations, I only found out about the
service-worker-allowedheader today.” 😳
I suspect at least some of you are the same, so let me explain not just this, but also a second interesting HTTP header related to Service Workers that are both probably not the ones you read about when you follow any of the many Service Worker tutorials out there.
This is one of the a little more obscure Service Worker features, but it’s very useful. You can see it in action on Google Docs, where the URL you’re on with multi-account login is something like
😨📖 tl;dr: Whether you want to add something new to an already existing feature or propose a completely new one, it all starts with finding out in what organization the standardization process for this kind of feature happens and where this organization’s discussions take place. This post suggests a possible approach to engaging in standardization work in a meaningful way for regular web developers whose day job is not standards by following along a step-by-step real-world example that takes you through the journey and encourages you to make your voice heard.
At Google, we have a humbling 👌(!) team of amazing Google Developer Experts that specialize on Web Technologies. The other day, one of them on a mailing list suggested the following feature (paraphrased from the email thread): “Consider adding support for a
titlecase keyword for the CSS
text-transform property”. …
As a regular (and passionate) iOS user with a strong belief in the Web, I beta-test any and all new iOS builds as soon as I can get my hands on them. My main motivation is to see how they do when it comes to Progressive Web App features. Each new iOS version comes with a new version of Safari, yet changes in Safari tend to almost never get highlighted in the iOS release notes (and the 12.2 beta 1 release notes were no exception). …