Advanced
This chapter covers advanced topics, such as offline support and custom JS builds. Codings skills are recommended.
Enabling offline support
DeepDive v8 introduces experimental “cache as you go” offline support. This is implemented via the Service Worker API, a new browser standard that is now supported in the latest versions of all major browsers. However, it is a very powerful feature and should be used with a lot of care.
Enabling this feature requires that your content meets the following criteria:
- Content doesn’t change between deploys (e.g. manually adding things to
_siteetc.) - All assets in
assetsare immutable, i.e. they never change (when changing a file in assets, it needs to have a new name and links need to point to the new file). - The site is mostly self-contained, i.e. assets are served from the same domain (offline support will not download assets form external sites by default)
- The site is served via HTTPS (this is a Service Worker requirement)
To enable this feature, create a sw.js file in the root of your project and add the following content:
---
---
importScripts("{{ '/assets/js/sw.js' | relative_url }}?t={{ site.time | date_to_xmlschema }}");
This will load the main service worker script from DeepDive’s assets. The site.time part is necessary to make the service worker “byte different” every time you create a new build of your site, which triggers an update.
In your config.yml under the deepdive key, add the following:
offline:
enabled: true
cache_version: 1
The current implementation does not cache resources from external domains. There is now way of knowing if external sites conform to the conditions mentioned above, hence caching can be problematic and result in unexpected behavior.
For example, Google Analytics uses GET requests to send page views, each of which would be cached by the service worker without this policy. Frequently updating images, such as badges would never change.
However, if you include resources that are hosted on another domain and don’t change, you can add the sw-cache query parameter to the URL, e.g.
https://upload.wikimedia.org/wikipedia/commons/b/b1/57_Chevy_210.jpg?sw-cache
This will cause them to be cached like resources from the assets folder.
If you want to serve a file from the assets folder but NOT cache it for offline use, add the no-cache query parameter instead:
/assets/lfs/download.bin?no-cache
How offline storage works
DeepDive’s custom service worker implementation stores files for offline use on three different levels:
- Shell
- The shell files are the core DeepDive files (CSS, JS) that only change between version updates. If you made changes to any of these after enabling offline support, you must force an update by bumping the
cache_versionnumber in the config file. - Assets
- These are presumed to be immutable. In other words, every file is cached indefinitely. E.g.: If you want to update an image after enabling offline support, add the image under a different name and change the link in the content. Alternatively, you can bump the
cache_version, but this will remove all other cached files from the asset cache. - Content
- The content cache exploits the fact that your content can’t change between builds, so that it can be stored for offline use until you upload a new build. For now, the entire content cache is discarded every time you publish new content (future versions could cache them based on last modified dates).
Other things to note are that the implementation will always cache the pages listed under legal, as well as the 404.html page, which will be shown when the user is offline.
Adding a custom social media icon
DeepDive includes a number of social media icons by default (in fact, everything that is provided by IcoMoon), but since the landscape is always changing, it is likely that a platform that is important to you will be missing at some point.
You can add any platform by simply providing a complete URL. However, a fallback icon will be used.
Creating the icon font
In order to add a custom social media icon you have to use the IcoMoon App (free) to create a custom icon webfont. However, it is important that the generated font include all icons already in use by DeepDive. For this purpose, find the selection.json in assets/icomoon/selection.json and upload it to the app via “Import Icons”. Then, use the app to add your icon(s). Consult the IcoMoon docs for additional help.
Once you’ve created and downloaded the icon font form IconMoon, replace the icomoon folder in assets in its entirety. Keep in mind that future updates of DeepDive will override this folder.
Adding the platform’s metadata
For the second step it is necessary to add the network’s metadata to _data/social.yml. An entry looks like:
deviantart:
name: DeviantArt
icon: icon-deviantart
prepend: "https://"
append: ".deviantart.com"
name- The name of the network. Used for the title attribute and screen readers.
icon- The icon CSS class. Can be chosen during the IcoMoon creation process.
prepend- Optional. A string that is prepended to the username to form the link to the profile. If the final URL should be
https://<username>.deviantart.com, this would behttps:// append- Optional. A string that is appended to the username to form the link to the profile. If the final URL should be
https://<username>.deviantart.com, this would be.deviantart.com.
How CSS is organized in DeepDive
DeepDive takes a quite unique approach to CSS, which is motivated by the ability to inline essential CSS rules in a style tag in the <head/> of a page (to increase the loading speed), while serving the rest in a separate file.
The styles are written in SCSS and are located in the _sass folder, which looks like
├── deepdive
│ ├── __inline__
│ ├── __link__
│ ├── _base.pre.scss
│ ├── ...
│ └── _social.pre.scss
├── pooleparty
│ ├── __inline__
│ ├── __link__
│ ├── _base.pre.scss
│ ├── ...
│ └── _type.pre.scss
├── mixins.scss
├── my-inline.scss
├── my-style.scss
├── syntax.scss
└── variables.scss
The style rules are organized alongside components (or rather, topics) like “sidebar” and “footer”. Further, there are two separate frameworks, “pooleparty” and “deepdive”, which grew out of the original Poole and Hyde projects. Poole/party contains more general style rules, while Hyde/jack contains those that more are specific to the theme. However, this separation has blurred over time.
Inside those folders, you will notice the __inline__ and __link__ folders. The unfriendly names are intentional, because their contents are generated by a script and shouldn’t be modified directly. The source files are located in the same folder and end with .pre.scss. They are fully valid SCSS files, but contain comments that mark which lines should be inlined and which should be fetched asynchronously.
The rules are as follows:
- Every line between
// <<< inlineand// >>>will be inlined - Every line between
// <<< linkand// >>>will be linked - Every line that isn’t contained in a block and ends with
// inlinewill be inlined - Every line that isn’t contained in a block and ends with
// linkwill be linked - Every line for which none of the above applies will be included in both.
The actual splitting happen with the .scripts/build-css.sh script (requires node.js 8+). You can run the script once by using
npm run build:css
or rebuild the CSS on every file change
npm run watch:css
Note that my-inline.scss and my-style.scss are not affected by this. Also, since all files are valid SCSS, the splitting part is entirely optional. If you would like to build just one regular CSS file, add
deepdive:
no_inline_css: true
to your config file.
