Aaron Gustafson's Blog, page 4

Locking down your GitHub-hosted Domains

The other day someone claimed a hostname on a domain I own and it took me a while to track down how. After a lot of digging around, trying to figure out how the hijack was accomplished, it turns out it was via GitHub Pages.

When you set up a custom domain with GitHub pages, you have to point your domain at GitHub���s servers. There are a bunch of ways to do this, but if you use an A record, you need to be careful with your DNS settings. The site in question had a wildcard hostname (*) A record pointed at GitHub���s servers. At the time I���d set it up, that was the recommendation if you wanted all traffic to go to the same place.

Fast forward a few years and it���s become a known exploit of GitHub Pages: when wildcard hostnames are in play, any repo can add a CNAME file to their repository and claim ownership of a hostname belonging to that domain. GitHub even warns you not to do this anymore, but I hadn���t checked the docs in years. In my particular case, it was an archived domain that I don���t really use anymore, but I wouldn���t have been aware of the DNS hijack if the attacker hadn���t taken the step of claiming the domain on Google���s Webmaster Central.

Thankfully the fix was simple: Remove the wildcard A record and point the Apex domain at GitHub���s IP addresses.

If you use GitHub pages to host any of your own domains, I highly recommend auditing their DNS records to ensure this doesn���t happen to you. You can also use domain verification for GitHub Pages and organizations to further protect yourself.

Equality vs. Equity

Over the last few years, I���ve been quietly leading training efforts within Microsoft focused on leveling up folks��� allyship skills. There are a ton of really important lessons to be learned form the curriculum my team and I developed, but one folks ofter struggle with is the concept of ���equality��� as compared to ���equity.���

I���ve found Kim Crayton���s approach of starting with definitions to be very helpful, so I���ll take a page from her and start there:

EqualityProviding the same level of opportunity and assistance to all people.EquityProviding various levels of support and assistance depending on specific needs or abilities.

Prior to working on diversity and inclusion efforts, I often framed these two states in the context of user experience. In that context, ���equality��� requires that we design our services such that everyone is given the same opportunity regardless of their situation. That may sound great, but the concept of equality makes a lot of assumptions about individuals and their circumstances. I���ll circle back to that in a moment.

���Equity,��� on the other hand, recognizes that we are all different and our situations are different and seeks to create services that can adapt to meet each person���s individual needs. Though I didn���t make the connection until much later, the philosophy of progressive enhancement in web design, which I���ve been advocating for nearly two decades now, is very much the embodiment of equity. It���s concerned with building interfaces that adapt to a wide range of circumstances, both tied to an individual user���s capabilities as well as those of the devices, networks, and environment in which they are accessing our creations.

I���ve seen dozens of attempts to explain the difference between equality and equity, but most seem to miss the mark in one way or another and haven���t quite sat right with me. There are a few analogies I like, however, and I want to share one with you. It also comes from Kim Crayton and I first heard share it in her ���Profit Without Oppression��� talk at the Apollo GraphQL conference.

I���m paraphrasing, but the gist is this: Your job is to distribute $200 to people in need to enable them to purchase healthy food. Consider two different customers; as it���s my paraphrase, I���ll call them Sally and Dave. Equality requires you to treat Sally and Dave the same, so you give them each $100. As I mentioned, while seemingly fair, this approach makes a lot of assumptions. For example: What if Sally lives close to a grocery store and Dave does not. Sally could walk to get her groceries on her lunch break, but Dave has to drive or take public transit, which is an additional expense. If it���s a particularly long way Dave may also be penalized through lost wages as he reallocates that time to getting to and from the grocery store. The problem is that the ���equality��� approach assumes Sally and Dave are interchangeable. If, however, you were to approach this situation with a focus on equity, you would take into account the differing capabilities of and circumstances surrounding each user and do your best to account for that in how you distribute the funds, perhaps giving Sally $85 and Dave $115 such that both end up with the same amount of money to spend on healthy groceries.

People are complex, as are our circumstances. Nothing is cut and dry and we need to build systems that are able to adapt to provide the right level of support in the right circumstances. That���s what equity is about and why it���s so powerful. It���s also why I���ve found so much alignment between it and my long-time passion for accessibility and progressive enhancement. Equity benefits everyone.

A Bitter��sweet Good��bye

June 3rd was my last day on the Edge team. It���s been an absolute honor and privilege to work with such an amazing team all these years, moving from Internet Explorer (IE) to ���Spartan��� Edge and, finally, to ���Anaheim��� Edge.

My first interactions with the IE team were back in 2006 and 2007, when I was representing the Web Standards Project (WaSP), pushing the team to deliver better JavaScript compatibility (especially the standardized event model). I continued to agitate for IE to up its standards game over the next few years and worked closely with folks on a number of projects. One that stands out was working on the X-UA-Compatible meta tag. PPK and I helped with the design of the somewhat controversial feature. I���m particularly proud that I pushed for IE to adopt an ���always-on��� standards mode for version targeting. I called it ���edge mode��� because it allowed developers to work with ���bleeding edge��� standards. I like to think that name inspired���in some small way���the name of the Edge browser today.

In 2015, I joined Microsoft as an evangelist for web standards, just before the team announced the move from IE to ���Spartan��� Edge. I chose to come to Microsoft because I saw a passion for web standards within the browser team. I also love underdogs and saw the IE team operating like a scrappy upstart (albeit backed by an industry titan). The IE team wasn���t allowed to hire remote folks���I was in Tennessee at the time���so I joined Microsoft as part of the Developer Experience, alongside Rey Bango and Christian Heilmann to form the first dedicated evangelism team the browser had in ages. We worked closely with the browser���s Ecosystem team to promote best practices in web standards, accessibility, and more.

After hopping around between a handful of different orgs, our little team was finally brought ���in house��� to Edge in 2018. Before that happened, however, I had already caught the PWA bug and had been working closely with Edge���s web apps team to chart the future of PWAs on Windows. Coming onto the Edge team opened up even more opportunities for me in this space and with the support from Rey (and then Kyle Pflug), I took an even more active role in the development of PWA-related standards, culminating in me becoming a spec editor for the Web App Manifest and developing features such as PWA Shortcuts (which Edge shipped first and up-streamed to Chromium) and Web Widgets (which are coming soon).

I���ve had an incredible amount of support from my management chain for so many ambitious and important projects over the years���The Web We Want, for one���and I am so thankful for that. I���m most especially appreciative of the support I���ve gotten to focus on D&I work. Culture and inclusion matters so much and I truly appreciate how much my team not only believes in, but invests in making Edge (and Microsoft) a more inclusive place to work.

I have so much love for the Edge team and will continue to root for them from not too far away. This Monday marked my first on the Technology & Corporate Responsibility team in CELA as their Accessibility Innovation Strategist. I���ll be charting the future of accessible technologies and directing future investments in this space across Microsoft products and beyond. I know my work will continue to overlap with Edge as there are so many ways we can use the browser to break down barriers and improve people���s lives.

A Bittersweet Goodbye

June 3rd was my last day on the Edge team. It���s been an absolute honor and privilege to work with such an amazing team all these years, moving from Internet Explorer (IE) to ���Spartan��� Edge and, finally, to ���Anaheim��� Edge.

My first interactions with the IE team were back in 2006 and 2007, when I was representing the Web Standards Project (WaSP), pushing the team to deliver better JavaScript compatibility (especially the standardized event model). I continued to agitate for IE to up its standards game over the next few years and worked closely with folks on a number of projects. One that stands out was working on the X-UA-Compatible meta tag. PPK and I helped with the design of the somewhat controversial feature. I���m particularly proud that I pushed for IE to adopt an ���always-on��� standards mode for version targeting. I called it ���edge mode��� because it allowed developers to work with ���bleeding edge��� standards. I like to think that name inspired���in some small way���the name of the Edge browser today.

In 2015, I joined Microsoft as an evangelist for web standards, just before the team announced the move from IE to ���Spartan��� Edge. I chose to come to Microsoft because I saw a passion for web standards within the browser team. I also love underdogs and saw the IE team operating like a scrappy upstart (albeit backed by an industry titan). The IE team wasn���t allowed to hire remote folks���I was in Tennessee at the time���so I joined Microsoft as part of the Developer Experience, alongside Rey Bango and Christian Heilmann to form the first dedicated evangelism team the browser had in ages. We worked closely with the browser���s Ecosystem team to promote best practices in web standards, accessibility, and more.

After hopping around between a handful of different orgs, our little team was finally brought ���in house��� to Edge in 2018. Before that happened, however, I had already caught the PWA bug and had been working closely with Edge���s web apps team to chart the future of PWAs on Windows. Coming onto the Edge team opened up even more opportunities for me in this space and with the support from Rey (and then Kyle Pflug), I took an even more active role in the development of PWA-related standards, culminating in me becoming a spec editor for the Web App Manifest and developing features such as PWA Shortcuts (which Edge shipped first and up-streamed to Chromium) and Web Widgets (which are coming soon).

I���ve had an incredible amount of support from my management chain for so many ambitious and important projects over the years���The Web We Want, for one���and I am so thankful for that. I���m most especially appreciative of the support I���ve gotten to focus on D&I work. Culture and inclusion matters so much and I truly appreciate how much my team not only believes in, but invests in making Edge (and Microsoft) a more inclusive place to work.

I have so much love for the Edge team and will continue to root for them from not too far away. This Monday marked my first on the Technology & Corporate Responsibility team in CELA as their Accessibility Innovation Strategist. I���ll be charting the future of accessible technologies and directing future investments in this space across Microsoft products and beyond. I know my work will continue to overlap with Edge as there are so many ways we can use the browser to break down barriers and improve people���s lives.

30 days of PWA

Today, some colleagues and I kicked off a new series on developing Progressive Web Apps. It will run for 30 days and takes you from the point of knowing nothing about PWAs all the way through integrating some of the amazing advanced capabilities available to web apps today.

I���ll be using this post to collect the articles as they publish. You can also check out the series on dev.to or on the canonical site.

Welcome to #30DaysOfPWADay 1 - Introducing Progressive Web Apps

Going dark (mode)

While working on tooling to analyze Web App Manifest usage in relation to some new feature proposals, it became clear we needed a test Manifest that included the proposed syntax for dark/light mode support. I decided to make this site the guinea pig and spent an hour or so tweaking things to make it happen. Here���s a run-down of what I did:

CSS tweaks ��

The first step was to add in the prefers-color-scheme Media Query. If you���re unfamiliar, it looks a little something like this:

/* Your regular rules go here */

@media(prefers-color-scheme: dark){
/* Overrides for the "dark" theme go here */
}

@media(prefers-color-scheme: light){
/* Overrides for the "light" theme go here */
}

I only wanted to add a ���dark��� theme as my default is pretty much a ���light��� theme anyway. For the most part, this was pretty straightforward��� just swapping color values, being sure to use the specific properties I wanted to change (e.g., background-color, border-color) rather than the shorthand. The only tricky/convoluted bit was updating my fancy link underlines (which don���t use text-decoration).

Tweaking SVGs ��

You may not have realized it, but SVGs also support the prefers-color-scheme Media Query. Most of my SVGs were black & white already, so I had no color definitions in them. Adding an embedded stylesheet to swap out colors did the trick though:

svg{background-color: white;}
path{fill: black;}
@media(prefers-color-scheme: dark){
svg{background-color: #454545;}
path{fill: #fffcf4;}
}

While most of these SVGs are in my HTML, some are referenced in my Web App Manifest. At the time I���m writing this, no browsers support SVG icons in the Manifest, but it���s something we (the Edge team) are working on adding for Chromium. And, when we land it, my hope is that we���ll include dark/light icon support by rastorizing the vector files in each of these contexts.

Tweaking the Manifest ��

Continuing in the realm of speculation, there���s a proposal to support user-prefered color schemes in the Manifest as well. That proposal calls for a user_preferences block, wherein certain keys can be redefined. Here���s what I did, based on our discussions:

"user_preferences":{
"color_scheme_dark":{
"background_color":"#5b5b5b",
"icons":[
{
"src":"/i/icon.svg",
"type":"image/svg+xml",
"sizes":"512x512",
"purpose":"any monochrome maskable"
},
{
"src":"/i/icon-reverse.png",
"type":"image/png",
"sizes":"512x512",
"purpose":"any monochrome maskable"
},
{
"src":"/i/notification-icon-reverse.png",
"type":"image/png",
"sizes":"256x256",
"purpose":"any monochrome maskable"
}
]
}
},

I���m not sure yet whether my color-adapting SVG icon would need to be included here so as not to be replaced by the PNG versions, so I went ahead and included it anyway.

And that���s pretty much it. With just a little bit of time, I got it all set up. If you happen to use the new theme and something looks wonky, please let me know.

Enhancing the Manifest

Since joining the esteemed group of editors maintaining the Web App Manifest spec for the W3C, I���ve been on the lookout for ways to enhance both web apps themselves���in terms of functionality���and how web apps are represented in app catalogs and digital storefronts. Some of that work is finally gaining traction and I���d love to get your input.

I briefly presented on a bunch of the different efforts I���m involved with at the W3C���s TPAC yesterday. Here���s a rundown of what I discussed as well as links you can follow if you want to get involved.

Indicating an app���s policies & other legalese ��

Many app catalogs enable developers to provide links to things like their app���s Privacy Policy and Terms of Use. There is no way, however, to semantically indicate this information in your markup; the closest you can get is link[rel="license"], but that���s limited in scope. Rather than propose including more link or meta elements (which would need to be included on every page of your site), we think it makes more sense to roll this information into the Manifest as part of a policies object.

My proposal enables developers to provide URLs for an app���s accessibility statement, content license, and policies governing privacy, security, support, and usage. Developers would be free to include whichever policies their app has and they can be URLs within the app itself or link off to other websites (such as the publisher���s). Here���s what that could look like:

"policies":{
"accessibility":"/accessibility",
"usage":"/terms",
"privacy":"http://publisher.tld/privacy"
}

So far, this seems to meet the needs of several of the app catalogs I���ve spoken with. I don���t know that browsers will make use of this information, but I could see it being useful in the context of an installed PWA as well as in app listings within the browser UI too.

In a related effort, I���m pushing for the Microsoft Store to support accessibility statements, which are helpful for explaining application functionality and providing details of any known accessibility limitations within an app.

Identifying an app���s publisher ��

When you���re considering installing any app, you want to know you can trust who���s behind it. Phishing sites are everywhere though, so we have to believe that phishing apps are here too (or not too far off). You want to be able to trust that an app purporting to be from your bank actually is from your bank. With such high stakes, opening up the possibility for an app to identify its publisher is quite dangerous, which is why this proposal has taken a while to germinate.

From the developer side of things, my proposed implementation is relatively straightforward. First, the app identifies its publisher in the Manifest:

"publisher":{
"name":"Organization Name",
"url":"https://organization.tld/"
}

The problem is that I could put anything in there, declaring my publisher to be any company or individual. In order to substantiate my app���s claim, the listed publisher needs to claim the app too. The publisher could do this by enumerating the apps it owns in a text file located at https://organization.tld/.well-known/published-web-apps:

https://origin1.tld/manifest.json
https://origin2.tld/static/manifest.json

Instead of using a text file, it may be possible to piggyback on the proposed web-app-origin-association file, but I���m concerned with overloading web-app-origin-association and confusing developers who are using it for URL handling.

Regardless of the mechanism, even with this bi-directional attestation, however, the system still has a gaping security hole: the publisher["name"] string can���t be validated this way. It would be relatively easy for an attacker to host 2 websites, one of which looks like your bank���s app and the other which merely hosts the published-web-apps file in order to support the bogus app���s claim of being published by your bank.

This is where the proposed processing algorithm adds an opaque validation step. Implementors are encouraged to verify that the publisher���s domain actually matches the claimed name. There are a number of services that offer name-to-url (or vice versa) lookup, but an implementor could even have a manual process in place to verify the provided information (which app catalogs do as a regular part of their business).

In the end, the publisher value will either be a validated name and URL pair or, if validation fails, the web app���s URL host string (e.g., ���twitter.com���), which many implementors already use as the publisher name.

Enabling server-side content negotiation ��

Though many folks these days focus their efforts on running as much code as possible on the client, there is a lot of value in making significant changes to your app on the server, before responding to a request. We���ve heard a number of use cases from folks building PWAs and have put together three proposals to help address them:

A Client Hint to indicate whether the app is installed. The Sec-CH-App-Installed header would give a server information about whether or not a user agent is representing the app in an ���installed��� state. The value would be a boolean true or false. We are discussing exposing this information via a DOM API as well.A Client Hint to indicate the display mode. We already have a way of detecting the display mode of a web app using matchMedia() and CSS���s display-mode media feature, but that is all client side code. The Sec-CH-Display-Mode header would provide the display value (taking into account display_override) on the server side as well. Using the Referer header to indicate installation source . I was working with a partner that wanted to beta their PWA to only people who���d installed their PWA from a specific app catalog. Even if they had supplied a separate Manifest with a unique start_url to that catalog, that would not have allowed them to limit their app���s distribution if the URL was shared. And so we proposed that the browser provide a catalog-associated Referer header when the PWA is first launched (and in the absence of a true referral). This feature has shipped in Edge for PWAs installed via the Microsoft Store and we are encouraging other app catalogs and browsers to consider the same approach.

It���s worth noting that all of these features can be used for analytics and (potentially) to violate someone���s privacy. That is why we���ve suggested they sit under the umbrella of the Privacy Sandbox.

Adapting app UI to user preferences ��

Shortly after OSes began rolling out support for color schemes (e.g., ���light��� and ���dark��� modes), I saw a need for web apps to be able to adapt to these user preferences. In CSS we have the prefers-color-scheme Media Query, but the Manifest had no way of accounting for these sorts of changes. My initial proposal centered around adding support for Media Queries in the ImageResource spec. Short of having CSS-driven, adaptive SVG web app icons (which I���m also working on), being able to associate an ImageResource bitmap with a Media Query seems like the way to go.

Here���s what that might look like in the context of the icons member:

"icons":[
{
"src":"/icons/play-later.png",
"type":"image/png",
"size":"512x512",
"media":"(prefers-color-scheme: light)"
},
{
"src":"/icons/play-later-reverse.png",
"type":"image/png",
"size":"512x512",
"media":"(prefers-color-scheme: dark)"
}
]

This approach would be applicable wherever ImageResource gets used, which includes app icons, shortcut icons, and screenshots within the context of the Manifest as well as the Notifications and Payment Request APIs.

Beyond images, however, as Jen Simmons pointed out, we need the ability to adapt colors within the Manifest as well. It���s early days in discussing this right now, but we���re thinking about adding a generic means of redefining Manifest keys, based on a particular context. It is going to be a challenge to figure this out because we don���t want to force Manifest authors to redefine an entire nested structure (such as a shortcut) just to swap out a single part of that object. But more on that in a moment.

Here is a simple example of how this might look:

"user_preferences":[{
"context":"(prefers-color-scheme: dark)",
"redefine":{
"theme_color":"#bdbdbd",
"background_color":"#000000"
}
}],

Ideally developers would not use this mechanism for redefining their icons, using the ImageResource option instead, but it does open the door to complexity.

Web app translations ��

Speaking of complexity, have you ever tried to build a web app that is translated into multiple languages? It���s an incredibly challenging task and the Manifest does not make it any easier. At present, the guidance for creating multi-lingual Manifests is to use a separate file for each language or make it a dynamic file that can be adjusted on the server side based on path or query string adjustments.

I���m currently working on a proposal to address this within a single document by introducing a translations member. My proposal offers two approaches, one favoring simpler Manifests, the other more useful for complex Manifests.

For simple Manifests, translations could be embedded directly within the Manifest file as members of the translations object, keyed by language code:

{
"name":"Good dog",
"description":"An app for dogs",
"lang":"en",
"translations":{
"fr":{
"name":"Bon chien",
"description":"Une application pour chiens"
}
},
}

For complex Manifests that may need to redefine text in shortcuts, screenshot labels, and the like, I proposed enabling translations to be managed in a separate file, offering alternative strings only for the items that need it. Using this approach, the above example could become:

// manifest.json
{
"name":"Good dog",
"description":"An app for dogs",
"lang":"en",
"translations":{
"fr":"manifest.fr.json"
}
}

// manifest.fr.json:
{
"name":"Bon chien",
"description":"Une application pour chiens"
}

One serious challenge (as with the user_preferences block, discussed above) is how to manage changing individual parts of a complex Manifest component. For example, you would likely need to change the text label of a shortcut, but may not need to change its url or icon. Thomas Steiner suggested that JSON Path may be a good solution here as it could enable you to do something like

{
"name":"Good dog",
"description":"An app for dogs",
"lang":"en",
"shortcuts":[
{
"name":"Pet Me",
"url":"/pet-me/"
},
{
"name":"Feed Me",
"url":"/feed-me/"
}
],
"translations":{
"fr":{
"name":"Bon chien",
"description":"Une application pour chiens",
"$['shortcuts'][0]['name']":"Nourrissez-moi",
"$['shortcuts'][1]['name']":"Caressez-moi"
}
},
}

This is still something we are actively working through, but it���s promising for sure.

Consider getting involved ��

There is a lot of really interesting work happening in Manifest-land these days. If you���d like to get involved, please follow the links and chime in on the discussions. We���d love to have you!

Dynamic shortcuts questions

You may or may not be aware, but the Shortcuts feature for PWAs has begun rolling out in Chromium-based browsers and implementation is underway in other browsers as well. The first version of Shortcuts provides you with the ability to define a small set of links in your Manifest. Rayan Kanso and I are currently working on a proposal for Shortcuts v2 which will introduce a JavaScript API for managing these links and we���d love your input too.

If you are unfamiliar with Shortcuts, this feature lets you declare a handful of links that will appear as part of the context menu of your PWA���s icon within the host OS. On most desktop operating systems, these actions are accessed by right clicking on the app icon. In iOS, you ���force touch��� or ���long touch��� (depending on your device generation) the icon, and on Android they appear when you ���long press��� the icon. You can learn more about Shortcuts in the Explainer.

In Shortcuts v2, we are looking at enabling JavaScript to add to or modify Shortcuts menu items. When I originally thought about this, I had assumed all of the Shortcuts defined in the Manifest would be able to be removed or adjusted via the JavaScript API. So, for example, a shortcut to ���Now Playing��� in a music app could be updated to ���Now Playing: Phone by Lizzo��� when that track is playing. In this case, the URL might remain exactly the same, but the label would be updated.

When discussing this with Rayan (and others), it appears that Android draws a distinction between ���static��� shortcuts and ���dynamic��� ones. Static shortcuts are generated when the app is installed; dynamic shortcuts don���t appear until the app has been run the first time. Static shortcuts are immutable (i.e., can���t be changed); dynamic shortcuts can be replaced by application logic at any time. These two different classes of shortcut also exist in different collections in the context menu and cannot be intertwined in the same menu system (i.e., all static shortcuts are in one group and all dynamic shortcuts are in another).

Further complicating things, iOS draws a distinction between ���static��� and ���dynamic��� shortcuts, but based on my cursory reading of the docs, even dynamic shortcuts are immutable once created. From what I���ve read, desktop OSes do not seem to support distinct shortcut types.

In order to set expectations properly and spec out the API, we need to decide on a direction to go in. That���s where you come in. I���ve created a Twitter Poll (below) that will allow you to vote for your preference. This will help us get a better sense of what you (folks who make websites) want and expect from a Shortcuts JavaScript API. If it means we need to come up with creative ways to manage the implementation under the hood in order to provide the right user experience and developer ergonomics, we���ll figure that out.

We are working on a JavaScript API for managing PWA Shortcuts and would appreciate your input on a core feature. This thread ends with a poll. Please read the whole thing before voting.

Background: https://t.co/NXhKogWzxQ

— Aaron Gustafson (@AaronGustafson) June 19, 2020

Here are the longform definitions of the choices in the poll:

Read/write dynamic: I want immutable "static" Shortcuts and separate "dynamic" Shortcuts I can add/update/remove via JavaScript.

— Aaron Gustafson (@AaronGustafson) June 19, 2020

Read all/write dynamic: I want JavaScript read access to all shortcuts, regardless of how they are defined, and I want to be able to add/update/remove new app shortcuts dynamically. Static ones would persist as defined by the Manifest.

— Aaron Gustafson (@AaronGustafson) June 19, 2020

Read/write all: I want JavaScript access to all shortcuts, regardless of how they are defined. This means I can update/remove Shortcuts defined in the Manifest too.

— Aaron Gustafson (@AaronGustafson) June 19, 2020

After reading all of that, how would you prefer to manage PWA Shortcuts in JavaScript?

— Aaron Gustafson (@AaronGustafson) June 19, 2020

Reefer 170, year 2

Facebook reminded me of a video I recorded of my reef tank a little over a year ago, so I thought I���d shoot another video, write a post about it, and share some of the interesting things that have changed over the last year.

This was the tank in May of 2019, at about 9 months after setting it up:

Watch this video on Instagram.

At that point, it was mostly zoanthid and LPS��� small frags. I had a few SPS frags that were given to me by a fellow hobbyist that I was using to see if I was ready for them yet. A year later, the tank is pretty much packed��� to the gills I guess:

Watch this video on Instagram.

The notable bare spot is that lower front pillar in the zoa garden. It had been home to my WWC Halle Berry zoanthids, which exploded in number shortly after being added to the tank and then began withering just as quickly a year and a half later without warning (and without any of the other polyps suffering). I managed to save 3 polyps and will try to re-establish them in the future.

All told, I���m pretty happy with the results of the Triton method for maintaining the acropora along the top of the arch. I started dosing Acropower recently as well, so we���ll see if that results in increased growth.

Interestingly, in the first video I had a frag of Tierra del Fuego acropora on the top right, but it kept struggling and nearly died like 3 times. I did a few dips in PolypLab���s Reef Primer and it finally started to look better. In the second video, you can see it in the back left of the arch when viewed from the front. It���s encrusted and super-happy now.

I also credit Reef Primer with saving my Dragon Soul goniastrea. You can see it as a small chunk on the sand in the first video, toward the bottom right of the tank. It had gotten a bacterial infection a few months after being introduced to the tank (it was a frag from my old brain) and the flesh was starting to receded from the skeleton, which is super depressing to watch. One dip and it started looking so much better. It���s fully recovered and has grown to easily ten times the size, which is incredibly fast for a brain coral.

Fish-wise, almost everything is new. I lost most of the ones from the first video shortly after trying to re-home a struggling Green Mandarin Dragonette for another reef keeper. It died and, shortly thereafter, I lost all but one of my fish (the Tailspot Blenny). I don���t know what the cause was, but this new batch of fish is looking good and I have no plans to add any more in the near future.

Anyway, I hope you enjoy the videos and if you ever want to talk about reef keeping (or want to talk about getting a frag or two from my tank for yours), please reach out.

Progressive Enhancement Just Works

In a recent blog post, Manuel Matuzovi�� offered a great case study covering how he built Front-end Bookmarks. In the course of developing it, Manuel found that following the progressive enhancement philosophy in his development made it easy to support older/less feature rich browsers and devices:

To my surprise, I only had to reduce some paddings and font sizes to make it look nice. I didn���t have to change much because I follow the Progressive Enhancement principle when I build websites.

We saw this same benefit back in 2013. When adding support for 1,400 new mobile browser/device combos to a project built for iOS and Android, we exceeded even our own expectations and were able to cut the timeline and budget in half!

It���s worth noting that this accomplishment had nothing to do with our bug-squashing prowess or our speed��� progressive enhancement just works. We were dealing with some heinous old browsers too���think Blackberry 4 and OpenWave���and they really didn���t present much of a challenge. So, for a very modest sum, we were able to quickly roll out additional support for over 1000 devices (and probably thousands more that didn���t make the list) and that created a huge opportunity for our client to attract and retain new customers.

I���ve been working on the web for a long time and few development philosophies have proven as timeless and resilient as progressive enhancement.