Using a web worker to publish Markdown

Inspired by Surma’s article When should you be using Web Workers?, I’ve been looking at ways to use web workers on my projects and I think I’ve found a good candidate. I write in Markdown and, until now, have had to rely on the build process to generate HTML files from the Markdown. It works but it requires rebuilding all the files whenever I add new content. The idea is as follows: The page will create a worker The worker will convert the Markdown to HTML and process syntax highlight commands The worker will return the processed content to the

More Display Goodness

The CSS Display Module Level 3 has added new ways to tell browsers how we want to layout and display the content on our pages. We still have block, inline, none, and other values for display that have been available since CSS 1.0 back in the 1990s. The new features include a two-value version of the attribute. .container { /* these are equivalent */ display: block; display: block flow; } display outside: The outside container value The <display: outside>, the first value in the two-element display declaration, defines the outer display type, meaning the type of the outer box container.

Working with Jetpack in development mode

Plugins like Jetpack don’t work at all in development environments that don’t use a fully qualified domain name or a domain that uses non-standard local domains (like site.local or site.dev), making it impossible to use any of its features unless we use Development Mode. To enable development mode we need to define the JETPACK_DEV_DEBUG in wp-config.php. The code looks something like this: <?php define( ‘JETPACK_DEV_DEBUG’, true ); While in Development Mode, some features will not be available since they require WordPress.com for their functionality, for example, Related Posts and Publicize. Other features will have reduced functionality to give developers a

Critical Path CSS

I’ve been looking at Critical Path CSS again as I work trying to improve the performance of this blog. The idea behind Critical Path CSS (from now on, just Critical Path) is that we inline the CSS needed to render the first screen of content, what’s called above the fold (borrowing a term from printed media) and load the remaining CSS later. I know that inlining CSS or Javascript can negatively affect performance but in this case, reducing the number of HTTP request needed to render and only adding the smallest amount of CSS possible to render above the fold

Working With WordPress Development and Staging Environments

Although I’ve always thought about staging environments as clones of production systems, I understand the need to do things differently in production than in staging or development. This would be no different than using Gulp to only concatenate and minify scripts in production or use the compressed setting when transpiling SASS but until version 5.5 there was no native way to do it. WordPress 5.5 introduced the wp_get_environment_type() function that allows developers to branch code based on the type of server we’re running. First set the WP_ENVIRONMENT_TYPE variable in wp-config.php define( ‘WP_ENVIRONMENT_TYPE’, ‘staging’ ); When wp_get_environment_type() returns development, WordPress will