Posts

Creating a Maximum Page Width for Your Web Pages

Computer screens keep getting larger. This can create awkward and convoluted compromises if you’re trying to create a mobile first web design. Add to that problem the need to push out new content fast, and you may come to realize that adding a maximum page width to your web pages is the solution to solid design with efficient productivity.

Can’t Somebody Else Deal With This?

If you don’t have the time or patience to dive down the DIY rabbit hole, and you would rather have somebody solve this problem fot you, then feel free to contact me about my professional services.

The Fundamental Dilemma of Modern Web Page Dynamics

Picture the screen of your smart phone. Now picture one of those great big curved gaming screens that take up the top of a whole desk. Next try to picture the web page that looks good on both of those screens. Finally picture adding lots of new content to those sites over a short period of time. Can you see how if you don’t manage this properly, it can become difficult to deal with?

Understanding Mobile First Design

Purist mobile first designers will tell you that you should literally design the mobile layout first, then figure everything else out after. Sometimes that works. But often that isn’t the most realistic or exciting way to design a website. So an alternative design method is warranted. Another way to view mobile first design is to recognize that in every instance of page design, you must prioritize a way to get your web page looking good on the smallest mobile application that it may be featured on.

Mobile First Design and Maximum Page Width

Now that we have a standard for mobile first design, we have to consider how a site will feature a page on the largest screen imaginable. Keep in mind that a layout that loads well on a mobile screen can leave too much negative space on a large screen, and an layout on a large screen can run out of room if it is not repositioned on a small screen. So what do you do?

Using a WordPress Theme to Manage Page Width

In this article, I am going to show you how to use one of the Big Themes to manage width. The particular theme that I am going to use is the Big Chill theme. It is free through the wordpress.org repo.

Foreground Page Width Limits

A simple way to set a page width limit is to create a foreground that holds all of your content, then set a maximum width for that foreground.

Hypothetically, a foreground page width limit can be any value. However, I would consider two values in particular. The 1200px width limit is a conservative limit that is great if you want to be able to add content quickly without spending a lot of time making adjustments for edge cases, while still leaving yourself a lot of room for page design. The 1800px width limit is also a good limit that requires more management than the 1200px limit. But it is a good choice if you think that you will spend a lot of time serving your website to large screens. You can move beyond this limit. But ultimately you will want some kind of absolute limit because on a large enough screen almost any section of content will start to look awkward no matter how it is sized.

How to Set the Limits with the Big Chill Theme

You can download the Big Chill theme directly from wordpress.org, or you can go to your main admin page then go to Appearance > Themes > “Add New”, then type “Big Chill” into the search bar, then select install, then select activate.

To access the customizer from the main admin page. Go to Appearance > Customize. Page limits can easily be updated using the Big Chill Customizer. Find the Layout section, then scroll down to the control titled “Big Pages”.

1200px width limit

Once you are in the customizer, you can set the “Big Pages” control to on or off. The default setting is off. When the default setting is off, the page limit will not exceed 1200px, and margins will always be present surrounding the foreground. If the “Big Pages” control is turned on, then the foreground page width will only show margins when the page width exceeds 1800px.

1800px width limit

You’ll also want to set the top of your foreground body based on how you set your navbar. You should note that if “Big Pages” is off, you’ll use the top space controls above the “Big Pages” control. If “Big Pages” is on, then you will use the controls below, except on your blogging pages (posts). You will always use the top controls to define the blog pages. This allows you to create different page width standards based on the kind of content that you are publishing for a given page type.

Managing Negative Space in the Background

You can use a background image or even just a quality background color to fill in the remaining negative space on a large screen. The 1200px limit is the ideal limit for a background image.

1200px foreground width limit on a 2000px wide screen

Managing a Background Image

If you are going to use a background image, then you need to consider page load speed with particular attention being paid to your page’s load time in a mobile environment. Converting your images to webp is a great way to start to improve page load speed.

Managing Page Width With Columns

If you have a lot of content, and you need to serve a lot of links, a sidebar is a great way to solve both of those problems with one layout decision. Adding a sidebar using the Big Chill theme will set your total content maximum width to 1800px. This total content width includes the sidebar. So your main content width will never get too large. This works great for blogging environments.

Managing Page Width at the Section or Block Level

Theme developers will often design content to spread from one screen to the other by using a percentage value for content items. However, this can introduce a lot of problems. If you are considering future proofing your web page, you need to consider that a page screen has limits as to how small it can be before it becomes unusable, so you know that screen sizes are unlikely to get smaller than they are. However, there is hypothetically no limit to how large screens might become. Think of the side of a wall. A prudent web page ought to serve a layout that is ready to handle a visitor using a screen that is excessively large.

If you don’t use page width limits, then you will need to create custom section width limits using class names. And if you create custom content, then you may need to do this even if you are using page width limits.

Page Width Limits Allow Reduced Content Width Limits

It behooves you to always set some kind of width limit for every piece of content. This increases load speed, especially on mobile. Dealing with a background image is a good example of how to manage this problem. You should set your image background width to about 2560px. And it is also probably a good idea to not display the background image on mobile devices since it will be barely seen anyway, so it only serves to slow down the page load. You can make this update using Additional CSS.

For example, you could try the following with the Big Chill theme:

@media screen and (max-width: 600px) {
	#bb-back-image img,
	#bb-preloader {
		display: none;
	}
}
#bb-preloader{
	z-index: -999;
}
#bb-preloader:before {
	content: none;
}

A background image requires an inherently large file size that causes loading slow down on smaller screens. Now imagine having to deal with that problem for every image that you load.

When you use maximum page widths you know your image widths will not exceed certain sizes. You can then set image width at that size, and if the image size is mobile friendly, then there is nothing else to worry about.

The other major benefit of content width limits is it allows you to avoid creating too much negative space or rely on inappropriate font sizes.

Further Fine Tuning With Additional CSS

Everything above will give you what you need to know to get your page publication ready. But you can also explore page width management even further using Additional CSS with the Big Themes.

Questions?

If you have any questions, then please feel free to post them in the comments area. If you would prefer to have somebody build this kind of site for you, then feel free to contact me about my professional services.

WordPress 6.3 Site Editor Review

TL:DR
I still don’t like the site editor after version 6.3. It seems to have significant fundamental design flaws, and it is still considerably less powerful than the customizer.

Why Am I Reviewing After Version 6.3?

According to WordPress, starting with version 6.4, it will be the end of Gutenberg phase 2. This means that development emphasis will be taken off of the site editor. This implies that the site editor is fundamentally complete. That doesn’t mean that there won’t be more updates, but the updates should be expected to be comparatively minor to what was released during Phase 2.

I find this to be pretty discouraging. I really want the site editor to be more than it is. At this point, I can’t really figure out what value it adds. It does things that the customizer can already do, it just does them with a new user interface. But the customizer can do an awful lot that the site editor can’t do. And the site editor has a lot fewer options for adding developer controls, which seriously marginalizes both developer and designer creativity.

History (From the Classic Editor to the Block Editor and from the Customizer to the Site Editor)

The block editor is a more sophisticated version of the classic editor. It can be used in any WordPress site. Some people don’t like the block editor because they think it is hard to use. But a lot developers tend to like it because you can create sophisticated content quickly with little or no code writing. The block editor has a learning curve, but it is powerful, and it is lot less restrictive than page builders.

The site editor is an alternative to using the customizer. It can also be used in combination with the customizer or without the customizer. Developers can add controls to the customizer as they desire, and there’s a huge API. So the primary limitation is the developer’s creativity.

The site editor has substantially fewer options than the customizer for developers to create controls. It is also still confusing to use for the end client. Although pages can now be updated in the site editor, you also have to click around to change entire control sets depending on what you want to do, so effectively you end up having to move between different editing pages that look pretty similar. Also, it is still not possible to do everything you need to do from the site editor. For example, if you want to preview a draft, then you will still need to use the block editor. When you try to preview from the site editor, it just takes you to your site’s homepage.

The Site Editor is Not What I Had Hoped

I actually want the site editor to work. I keep hoping with each new version that I will be able to lay down a simple block pattern based theme that my customers can focus on loading their content into. That way they can get used to working with blocks, and then eventually transfer their content into something more sophisticated. But as it stands, it just makes more sense for people to learn from the block editor.

When you consider what the site editor seems like it ought to be, you get the impression that it ought to be able to do a good job of supporting a simple block pattern based theme. But the reality is it just doesn’t do that in a way that is intuitive or easily transferrable. In my opinion, the site editor still ought to be in it’s beta phase, and WordPress should still be focussing on how it works at a fundamental level. WordPress has been doing so well for so long. It seems like right now, they ought to have all the time in the world. I don’t know why they feel compelled to develop so much so fast.

If you’re interested in reading about what is good to use in WordPress, then please check out this get started guide.

Google Fonts CDN Versus the Cloudflare CDN

You probably have realized that serving your fonts through Google’s Font CDN is faster than serving your fonts locally, but if you’re like me you may be wondering if Google’s CDN is the fastest CDN available. So I decided to test the Google Fonts CDN versus the Cloudflare CDN.

TL:DR
My personal experience is that after using seven different series of fonts, the Cloudflare CDN is consistently faster on a 4G mobile network by about a second, but the difference on laptops or desktops with a good connection is less noticeable.

Assumptions of Knowledge

You will need to understand how a content delivery network and caching works if you want to understand this post.

The Kinds Of Pages That I Tested

I used both Bootstrap based and WordPress based pages. And each page had different kinds of content.

Update (7/31/24)

I have written a new article about Cloudflare Fonts that expands on this blog post’s discussion.

The Local Server I Tested On

I used a HostGator shared server to run every font series that I tested. This is hardly the world’s greatest server, but it isn’t terrible either. So it is a good local server to test on if you’re trying to determine average results.

The Tools I Tested With

I primarily relied on Google Page Speed Insights to test the performance of my different pages.

The Work Necessary to Perform the Updates

I wouldn’t say that performing the updates was complicated, but it was tedious and time consuming. It required a lot of attention to detail. Ordinarily, this is part of the fun of coding, but when you’re doing something as monotonous and repetitive as this, your mind might fight to wander off into more entertaining territory.

My method was to hard code the results when I used Bootstrap pages. And for my WordPress pages, I used a simple plugin that served primarily as a code template that resulted in mostly hard coding.

There are other WordPress plugins that don’t require you to write code, but they have inefficient coding, so I would be concerned that they would not be ideal for improving page speed. The plugins are only designed to host your fonts locally. So if they don’t process the results fast, then they will contradict the speed enhancement of being served through Cloudflare. The plugin that I used was designed so that each time you must rewrite it to host exact fonts for an exact page, so there is no processing waste needed to be performed for generalization.

The Results of the Google Fonts CDN Versus the Cloudflare CDN

Perfect 100 score on a smart phone utilizing a 4G Network. The loaded visible screen includes a full screen image, a typing feature, and an animated button.

I don’t want to be too presumptuous as to why the performance was faster; I only want to note that the performance was consistent. I don’t remember how many tests I performed, but after considering standard deviation, it was safe to say that the tests resulted in about a second faster in page speed on a 4G mobile network. However, desktops that already loaded fast didn’t load much faster.

Is It Worth the Time and Effort?

I don’t have a great answer to that question. Taking the time to do this isn’t something that I would encourage every website owner to perform. But if you get a lot of mobile traffic, and your visitors don’t have a lot of patience, then I would certainly consider it.

If you’re not a developer or you are not unusually tech savvy, then you may find this operation to be pretty difficult. There are a lot of different ways to make mistakes, so almost anybody that tries this is likely to make one. And if you don’t know how to troubleshoot, then you’ll probably get stuck. So if this is important to you, and you don’t have the means to do it yourself, then you should probably hire a pro.

Should You Update Your Website’s Software Version?

Should you update your website’s software version? It might seem intuitive to always update to the absolute latest version of whatever website software that you may be using as soon as it is available. However, adopting this philosophy dogmatically might lead to more problems than if you applied a less aggressive updating strategy.

Beta Versions and Alpha Versions

When I speak of the latest version of a piece of web software, I want to make it clear that I am not referring to alpha or beta versions. I am only referring to releases that are considered by its developers to be generally usable.

Two Use Cases: WordPress and Bootstrap

It’s impossible to give a completely exhaustive analysis of use cases, so what I will do in this post is review some use cases for some of the most popular web development software: Bootstrap and WordPress.

Should You Update Your Website’s Software Version? Assessing the WordPress Core

WordPress provides core feature updates about three times a year. They like to add new features pretty aggressively. Some new features are great as soon as they are released. Other features take a while to mature. And some are never really worth using.

WordPress Version Numbering Convention

The WordPress numbering convention is a little weird. The two leftmost digits on the WordPress version number essentially act as a single number. Neither number extends past nine. You could sort of think of WordPress version 6.2.2 as version 62.2. A minor version number may extend well past nine. For example, there is a WordPress version 4.1.38.

Minor Versions

Minor version releases are almost always related to enhanced security or critical performance issues. Minor releases often continue even if you do not update to the next major version.

Major Versions

Major version releases are primarily related to new features. One thing to keep in mind about a major version release is that it opens up opportunities for security vulnerabilities. While it is true that older software is also known for security vulnerabilities, some of the most secure software is software that is old without being too old. Software tends to improve in security after it has been around for awhile and has had ample opportunity to be tested in real world environments and patched with security updates. It doesn’t start to become more vulnerable until it becomes unpopular and people stop paying attention to it. Likewise, the period in the beginning when the software has relatively untested and unpatched new features is also a period with the potential for security vulnerabilities.

WordPress Version Support

Officially, the latest major version of WordPress is the only version that is supported. But unofficially, it is known that older versions of WordPress get security updates all of the time.

The Classic Editor Versus Gutenberg Argument

It’s hard to reference WordPress versions without at least mentioning the classic editor versus Gutenberg argument. If you are a classic editor user, then this argument may be particularly meaningful.

Classic Editor Plugin Versus Older WordPress Core Version

I don’t use the classic editor, so I’m not really sure that I am in a great position to give advice on whether or not you should use the classic editor plugin or the classic editor block or an older WordPress version. However, from my somewhat distant vantage point, it seems that using the Classic Editor plugin may be the more suitable alternative since it implies that more attention will be given to security and it doesn’t require any concession for the block environment. You can read about my policy on plugin updates down below.

The Site Editor (AKA “Full Site Editor”)

The new site editor‘s performance is still pretty bad. But if you are using Gutenberg and the customizer to build your site, then it is pretty safe to say that you can just ignore the site editor as a consideration. There hasn’t been even the faintest implication that I am aware of that WordPress has any intention of stopping customizer support at any point in the future. I imagine that their behavior has much to do with the backlash against Gutenberg. Even though a lot of us like Gutenberg, I think it did seem a little rough to remove the classic editor from the core.

What I Intend to Do

In the past, I have generally made it my policy to test core beta releases on my development environment then update to the next major version as soon as WordPress makes it available. However, I have begun to question this. Over the past couple of years, I have repeatedly found bugs in various WordPress blocks that beta testing and WordPress documentation did not prepare me for. Its hard to determine exactly what the cause of every problem was, so I don’t want to be too quick to assign blame. But it seems that at least in some cases, block updates have feature changes that do not provide adequate backwards compatibility. Similar problems sometimes extend into the block editor.

Although, I frequently find at least one new feature that I want use in each major WordPress version, I think that I will be less likely to adopt the newest major version as soon as it is released. I will continue to test the latest versions in development environments to make sure that it is compatible with my software. But I might wait for it to go through a minor release or two before updating it into a production environment. This creates improved security and allows for more time for new feature adjustment.

Finally, I can’t think of a good reason why I would stop updating minor versions.

Should You Update Your Website’s Software Version? Assessing WordPress Plugins and Themes

WordPress plugins and themes are designed to support the WordPress core. This means that plugin and theme developers often update with every new version of WordPress core. However, not every developer does this. One of my favorite plugins (which I won’t name because it’s one of my favorite) has a habit of putting off or never bothering to update the version number when WordPress updates its core. But not updating the plugin isn’t all that unreasonable. If the plugin still works and doesn’t require any change to its code, then updating just for the sake of changing a version number might seem like an unnecessary hassle even for the end user that has to take the time to run the update.

Major and Minor Versions for Plugins and Themes

Major and minor versions for plugins and themes are usually released in a single stream. That means that once there is a new major version, you should not expect support for a previous major version. So it usually behooves you to update regardless of what version type it is.

My Policy on Plugin and Theme Version Control

Once I have committed to a plugin or theme, I find that the best policy is to just update to the latest version as soon as it is available. If the software has any problems that become unmanageable and research shows that it does not appear that any corrective measures will be performed by its developer(s), then I stop using the software or replace it.

If a plugin stops updating for a significant period of time (usually at least a year), then I might do research to see whether there are still implications of support, and I might consider contacting the developer. I may also see if there are alternative resources for the plugin’s features.

Should You Update Your Website’s Software Version? Assessing Bootstrap

When Bootstrap 4 reached its end of life at the beginning of 2023, I figured it was a good time to start migrating my Bootstrap pages to Bootstrap 5. However, I have come to conclusion that it behooves me to be more hesitant.

Understanding How Bootstrap Numbers Its Versions

The Bootstrap version update strategy is much more conservative than the WordPress strategy. It adds fewer new features much less frequently. The Bootstrap version numbering convention is different than the WordPress version numbering convention. The leftmost number is the major version number, then the number to the right is the features version for that major version, then the rightmost digit is the patches version for the major version’s features number.

End of Life Software

An end of life version tends to imply that you should stop using that version and update to the newest version. Both Bootstrap 3 and 4 have hit end of life. Bootstrap 5 is considered active as of the date of this post’s publication.

Evaluating Bootstrap’s Older Version Quality

Older versions of Bootstrap (Versions 3 and 4 in particular) are of remarkably high quality and are stable and secure. Compare that to the latest version of Bootstrap (version 5) which has a lot of experiments with a lot problems, but not a lot of new features. This will make you question whether or not 5 is the best choice even though 3 and 4 are end of life.

Bootstrap Older Version Support

The documentation on Bootstrap older version support is a bit more cryptic than the WordPress documentation. According to their official documentation version 4 and version 3 have both hit end of life and no future support is implied. However if you read the release information for version 4, you can see that they explicitly state that you should feel free to continue to use it after end of life which implies potential security support. And if you read W3Schools documentation they state that both 3 and 4 are still supported for critical updates. Although, I’m not aware of official affiliation between Bootstrap and W3Schools. And it’s also possible that W3Schools simply needs to update its documentation. Also, there is unofficial documentation stating explicitly that older versions will not receive support.

My way of interpreting all of this (and this is somewhat speculative) is that if there was a problem with Bootstrap 3 or 4 and it still had a lot of users when the problem occurred and the Bootstrap team could create a patch without exerting an unreasonable effort, then they would probably write the patch. However, this is not something that they want to promise, and they aren’t actively looking for problems to correct.

Security is Relative to Use

The degree that a security vulnerability is meaningful is also related to its use case. If a security vulnerability only exists in a certain feature when it is used in a certain way, then its existence may not make your site any more vulnerable to a security threat than if you were to update to a more secure version. Prudent user management is always one of the most important elements of site security.

Bootstrap 5 Performance

Even if you just assume that support will not be provided for the end of life versions, and you don’t feel comfortable with your own management, whether or not to update to 5 still isn’t obvious. As I mentioned above, I tried to update to Bootstrap 5, however when I started to make updates, I noticed a lot of problems with scrollspy. And it turns out that, I wasn’t the only one with this problem. Also, anytime you have a new version of software with a lot of problems, you should consider that there may be unknown security vulnerabilities as well.

Bootstrap 4 Performance

Bootstrap 4 performs really well. And it has almost every feature that Bootstrap 5 has. The only real fundamental difference between 4 and 5 is Bootstrap 4 is dependent on JQuery which isn’t really a problem if you don’t mind using JQuery. And as of the publication of this post, version 4.6.2 has no known security vulnerabilities. I think that right now, at least for a little while longer, Bootstrap 4 might be the best version choice if I want to have a stable version of Bootstrap and keep all the features that I have been enjoying.

Should You Update Your Website’s Software Version? My Personal Experience With Supporting Older Software

As an open source developer, I appreciate the necessity of supporting older software. Like many open source developers, at the time of the publication of this post, my older software is still my most popular software in spite of everything that I have done to try to promote my newer software.

Even when my newer software is well tested and genuinely better, I know that change can be hard for my customers, especially if they are satisfied with what they have and have worked hard to achieve it.

Well developed older software actually tends to be pretty easy to manage when you make it easy for your users to report problems. So I can tell you from personal experience that it is usually the developer’s desire to provide as much support as possible for as long as possible.

So should you update your website’s software version? The bottom line is that there is no one size fits all answer for when to update. Hopefully, you realize that you should consider updating all of your web software at regular intervals and be prepared to do whatever work is necessary to perform the updates when the time is right.

Static HTML vs WordPress

I’m a fan of WordPress. I can’t imagine trying to build this blog without it. But it isn’t the answer to every web development problem. I still actively manage websites and webpages that don’t run WordPress. And I don’t have any plans to decommission them anytime soon. This post is about the benefits of NOT using a content management service like WordPress. In particular, it is about building a site with static HTML.

Specificity of Static HTML

One of the greatest advantages of using WordPress is its ability to add content quickly. However, this can sometimes be a disadvantage too. If you want to add content using specific standards, and your content manager doesn’t have options that fulfill your needs, then using a content manager can be more difficult than building your page from scratch. In other words, if there isn’t anything similar to what you are looking for that has already been created by somebody else, then it will probably be more difficult to find and modify an object than to build one from scratch.

This page has a lot of specific and dynamic elements that would be more difficult to implement and maintain if it relied on WordPress.

Simplicity of Static HTML

If the page that you are trying to build is simple, then building with WordPress may be an unnecessarily complicated experience. Do you want to build a website without a navbar and a few images and only a few hundred words of text that you don’t intend to update very often? Then you may be better off without a WordPress site.

This page was easiest to build with just HTML, CSS, and JS because it doesn’t have much content. It is also linked to a page with a simple PHP backend. And it is linked to a WordPress blog.

Total Control Over Updates

Content management services update several times a year. Whenever this occurs, all of its supporting software has to consider whether or not it needs to be updated.

If you want to work with a WordPress site, then you should expect to update it several times a year. If your idea of a website is “set it and forget it,” then a WordPress site might require you to spend a lot of time just keeping your site looking the way that it is.

However, static websites can sometimes be safely left for much longer periods of time without needing a consequential update. And sometimes the most effective way to manage a website is to remember that if it ain’t broke than don’t fix it. Static websites can be ideal for a one page site that has content that rarely needs to be updated.

This page was built using Bootstrap, and it rarely needs to be updated.

Security of Static HTML

You have to update your WordPress site if you want it to be secure. Any site can be hacked. But generally speaking, a simple website with a few files is a lot easier to keep secure than a complex site with multiple points of entry. If your site doesn’t need a database, then it’s safer not to use one. The same is true for input values. If your site is largely HTML with simple scripts, then there aren’t many ways for a hacker to exploit your site. Further, fewer update requirements reduce the likelihood that new security updates will be introduced.

Speed of Static HTML

Simple sites are almost always easier to get faster page loads as compared to CMS driven sites. And that speed is usually easier to maintain. To get a WordPress site running fast you usually need more software than a simple site. And that software needs to be updated.

When you hear about websites being “light”, there is no contest between a static site and a CMS site. A light site is a site that requires fewer files which means that it has fewer scripts to run. So a static HTML site has fewer bytes to load to the browser.

Static HTML is Ideal for One Page Sites

A WordPress site can utilize a lot of unnecessary overhead for a one page website. There is something to be said about having the ability to extend a WordPress one page site into a larger website. But it is also possible to add a WordPress site as a subdomain to a static HTML one page site. And if you don’t intend to use a lot of content until far into the future, then starting with a static site may be the simpler route. You also have the option of replacing your static site with a WordPress site.

Static HTML has Fewer Requirements for Caching

WordPress runs on PHP. This means in order to keep your pages loading quickly, you need to add page caching. This is unnecessary with static HTML because static HTML is the state that PHP page caching is trying to induce.

So Why Would You Use a CMS like WordPress?

When you’re dealing with a lot of content, and you need to add new content on a regular basis, a simple website isn’t efficient. Simple websites are great if you don’t have much content and you want to minimize how often you have to manage your website. But if you need to constantly add new content for your users to engage with, then a simple website just won’t do. If you just need to add a sentence every once in a while, then you can probably learn to read HTML well enough to directly update a file in your directory. But if you are routinely updating a lot of content, then you may want to consider WordPress.

Consider Using Both Static HTML and WordPress

It’s feasible to start with a custom homepage, then update your site by adding a WordPress site to your subdirectory. A static HTML site can be a great place to start if you need a website, but you are not sure how much time you want to invest into it. The best way to build a static HTML site is to contact a website professional and ask for a custom rate. Small one page static HTML websites can often be cheaper than a larger WordPress site.

Questions About Static HTML?

Please post any questions that you may have in the comments section.