DEV Community: Desolo Sub Humus 🌎🌍

Offline PWAs and JSON Limitation Issue

Desolo Sub Humus 🌎🌍 — Thu, 10 Oct 2019 18:16:26 +0000

Offline PWAs and JSON Limitation Issue

The addition of a simple Service Worker and a JSON file to save us from writing the same tags over and over again in every head element on every page and to make our web apps load even faster is a wonderful idea, though I've encountered a huge issue with the implementation.

I tried to turn my Azure Alphant repo on GitHub into a fully-fledged PWA, however this is not possible for apps which will be used offline at all. The issue is a bit complex, and involves a built-in security feature for JSON use.

Each page in the app needs to be able to use the Service Worker in order to tell the browser the conditions which should be met for certain events to take place. (Example: What the browser should detect before installing, how it should allow the app to be installed, determining it the app has finished installing and whether it has installed properly, and to apply the manifest.JSON file when everything checks out.) Each page also needs to reference the manifest.JSON file. So far, so good.

The problem I found became apparent when I tried to test-use the app offline. In order to use JSON, certain CORS requirements need to be met, and the pages can only load the JSON file(s) specified, assuming you want to keep a tighter handle on security. The problem lies in the fact that the only acceptable files must begin with HTTP://, HTTPS://, and a few others like data- which do not apply to JSON files. Now, a truly offline app will need access to all necessary files locally, as trying to access them online while you are completely offline simply will not work. This means the manifest JSON file must be accessible online only for CORS requirements to be satisfied, but must be accessible as a local file only when offline. Either CORS will break when the file location begins with C:// (or whichever drive you have it on) or it will break when it can't find the JSON file online when there is no online connection.

Instead of the app working both online and offline, its ability to fetch the manifest file is broken both as online and local files

I've wondered, is there a way around this problem? So far, I haven't found a solution that actually works (saving a file that was semantically JSON as manifest.js didn't work at all during testing). However, since we are still pushing for apps to feel more native, and it just makes sense to give users some control over what happens locally (for example, not specifying a font-family on a website allows the site to display either the default font or a user-specified font as per the user's browser settings), could there be a possible future in which a user could choose manifest file settings to be used for their installed apps directly in the browser?

Sure, I'd have my work cut out for me in that scenario in that I'd have to write code that allowed for those user settings and still keeps the app running and displaying as intended, but doing so could allow for a system that relied on local security instead of on the current CORS system, which is built to keep the online JSON files we need a bit more secure. In the event that an offline JSON file or browser manifest settings could even be fetched, the manifest JSON file would have to be swapped out locally, or the settings changed locally for security issues to crop up locally. This seems to me to be a much more secure option than trying to secure online files online from online viruses, hacking attempts, and such.

Granted, there's still quite a bit that would be app-dependent and couldn't be added as a local setting, but perhaps we could still put that on every page (I know, ugh, no), but at least we wouldn't be dealing with an app-breaking mess where important information couldn't be loaded (breaking the entire app) due to CORS vs. JSON issues.

I could be wrong (I do not work in any Security capacity in terms of coding and I'm fairly new to dealing with CORS), so take this as a fairly random idea that isn't actually in the works anywhere (that I know of), and of course, if I am wrong, please let me know that I am and explain to me what I'm missing in the comments. In the unlikely event that I've come up with the most perfect and unbreakable solution to this conundrum, feel free to let me know about that in the comments, too.

Mind you, I do understand that the 'W' in PWA is for Web, which implies this is for online purposes, but even Google gives tutorial instructions on how Developers should set up offline use for PWAs. This was how I found the issue in the first place - by researching why Azure Alphant did not work as a PWA and instead threw a list of errors in the DevTool panel while refusing to load after I had followed the PWA tutorial perfectly.

All I DO know absolutely for sure is that there has to be a better way to set up PWAs.

Using CSS filters and either CSS variables or @keyframes together

Desolo Sub Humus 🌎🌍 — Thu, 02 Aug 2018 21:21:28 +0000

Using CSS filters and either CSS variables or @keyframes together for some different styling tricks

This all started as a personal recipe book. I wanted to create an HTML file for each recipe and another for a menu for navigating the whole thing like a table of contents in a traditional print cookbook. It could be a little messy, since it was to be local files only, but still, if I wanted to create separate styling for different types of recipes, I could end up with an unmanageable cluster of stylesheets rather quickly.

Of course, once I solved that problem with filters, I decided to experiment with my newly created fix to see what else I could do with it. As it turns out, I could make drastic changes fairly easily. I let CSS filters change the colors of each element relative to the background color, experimented with CSS variables (and a bit of JavaScript) to assign different background colors to different pages using little more than a single hex color (rgb, hsl, and named colors work fine, too), and even played around with animating the entire color scheme by adding in a bit of @keyframes API. That said, this still takes more processing in the browser than I'd normally recommend, since I'm a stickler for loading speed, so use these tricks sparingly.

The filters

An easy way to let the browser calculate an entire color palette for a website is to use filters. It's not quite as good as designing using popular prefab color palettes or coming up with a new color palette based on either trends or your own colorful innovation, but it is mathematically valid. For example, let's say you want to create a color palette using a monochromatic color scheme. You could eyeball a color wheel and pick out multiple shades, tints, and tones of the same color, you could use a site like ColorHexa, or you could just let the browser figure it out using filters.


body{background:#9eb89e;}
    /*the body background color is a gray-green tone, almost sage*/

div{border:3px solid #dfe7df;}
    /*the div border is a pale mint*/

p{border:3px solid #353d35;}
    /*the paragraph border is a dark forest green*/

becomes


body{background:#9eb89e;}
    /*the body background color is a gray-green tone, almost sage*/

div{filter:invert(100%);border:3px solid currentColor;}
    /*the div border is a pale mint*/

p{filter:brightness(10%);border:3px solid currentColor;}
    /*the paragraph border is a dark forest green*/

Once all but the main color in your stylesheet is defined by filters calculating new colors based on your main color, changing the entire color scheme is simple, assuming you stick to the same type of color scheme. This will not work well if you plan on going from a monochromatic to a triadic color scheme, but it's perfect for going from one monochromatic scheme to another monochromatic scheme. At this point, you could add in a style switcher that allows the user to control the entire color scheme using a single variable.

The variable

To set this up as a style switcher, you'll need a bit of JavaScript. In this option, you'll be setting up buttons to click on for each color scheme, but altering it to accept input from a form would work just as well. This is only one example.


const root = document.documentElement 
const themeBtns = document.querySelectorAll('.theme > button')

themeBtns.forEach((btn) => {
  btn.addEventListener('click', handleThemeUpdate)
})
    /*this creates the ability to control styles with buttons using the click events*/

function handleThemeUpdate(e) {
  switch(e.target.value) {
    case 'sage': 
      root.style.setProperty('--main', '#9eb89e')
      break
    case 'wetsand': 
      root.style.setProperty('--main', '#b8b89e')
      break
  }
}
    /*this is where we add the styling that changes by way of CSS variables*/

Then all you have to do is reference the script in your HTML, add the class 'theme' to the containing element for your style switcher buttons, add the value and id 'sage' and 'wetsand' to your buttons, and you are ready to use your variable.


body{background:var(--main);}
    /*the body background color is a gray-green tone, almost sage*/

div{filter:invert(100%);border:3px solid currentColor;}
    /*the div border is a pale mint*/

p{filter:brightness(10%);border:3px solid currentColor;}
    /*the paragraph border is a dark forest green*/

Now, at the click of a button, your users can change from one color scheme to another using JavaScript to change one single color, which, in turn, cascades using filters to control all the other colors mathematically. We could make different change and animate the whole process, though.

Animation with the @keyframes API

For an automatically changing color scheme, skip the CSS variable and scripting above and add an @keyframes animation to control the main color.


body{background:#9eb89e;}
    /*the body background color is a gray-green tone, almost sage, as a fallback*/
    /*@keyframes will animate this color scheme in browsers that support it*/

div{filter:invert(100%);border:13px solid currentColor;}
    /*the div border is a paler tint of the body background color*/

p{filter:brightness(10%);border:13px solid currentColor;}
    /*the paragraph border is a darker shade of the body background color */

@keyframes colorSwitch{
0%{background:#9eb89e;}
25%{background:#b8b89e;}
50%{background:#b89eb8;}
75%{background:#9e9eb8;}
100%{background:#9eb89e;}}
body{animation-name:colorSwitch;animation-duration:15s;animation-iteration-count:infinite;}
    /*the main body color will change over the course of 15 seconds and then repeat */

Now the whole style will infinitely loop through four different monochromatic color schemes. To keep the separate schemes from being to jarring when going from one to the next, I chose to use a tetradic color scheme to define all four main colors.

Update: I've created a Gist to demonstrate the use of filters in calculating an entire color scheme using only one specified color in the CSS. Please excuse the garish colors in the examples; they are used to demonstrate how the filters work, NOT as a suggested set of color schemes.