Whenever you create a page, you at times notice that your text goes bye bye without telling you anything about the reason why it would do that.

The fact is that there are many reasons why this can happen. The following is here to remind me of the various possibilities that I've bumped into over time.

Text Color

The first one that got me many times is the color of the text. If that color is set to transparent or the same color as the background, then you won't see the text.

What I do to test that quickly is go to the block where the text is expected to appear and change the background color to the opposite or some other color. If the text appears at that point, I know what to fix next: the color of the text.

Text Visibility

The CSS setup includes a visibility capability. If set to false, then whatever is contained there is going to be hidden. Looking at the CSS in your debugger (i.e. Inspect Element), you should be able to see the visibility field.

One way to test quickly, though, is to add the visibility field to the element entry and set it to true there. Note that this could be false on the text itself, the parent, the parent of the parent, etc.

Why would you use visibility: false instead of display: none? In some situation, you want to hide the content of an element, but you want to keep the space used by the element taken as if the element was visible. This allows your page to not change size and start scrolling. It ease your formatting as it stays in place whether that item is shown or not.

Block Visibility

Another visibility field is called display and it can be set to none to hide the block in its entirety. Search for display and make sure it is not none.

Note that JavaScript often changes block visibility with commands such as hide() and show() in jQuery. If you have JavaScript running, this complicates the test. Although you should be able to make it reappear and if you're in control of the JavaScript, you could prevent it from running until you resolve other problems if there are other problems.

Why would you use display: none instead of visibility: false? Now a day, I most often see the hide() and show() functions being used, but I believe that the visibility field is more than likely to start being used again. The display: none means that the item gets removed from the screen. It remains in your DOM, but is not considered at all for display purposes. This is very useful for popups where it is used on very many websites. Popups, though, have no direct effects on the normal content of the page. So showing/hiding them won't affect the size of the content in the background.

Of course, the hide() and show() are used in many other situations. For example, you could have a line showing a status that changes over time (as you use HTTP 2 or AJAX to check said status). This means certain items could be hidden and shown as the status evolves.

Block Size

I often had problems where the size of a block is 0 in width or in height (or both). When a block has a size of zero, it is very similar to having a display: none. However, by default blocks usually leak data that appear inside them. So this happens only if the block is also marked with the clipping feature to clip away antying to leaks.

With the Inspect Element, just click on the Computed tab and the rectangle at the top shows the various dimensions. If the width and/or height are zero, then you know that's probably your problem.

Block Position

Similar to having a size of (0, 0), you may have a position placing your text outside of the window.

This technique is less used now that we have HTML5. But old websites are most certainly using this trick quite often.

There are two locations that are used the most. Placing the text on the top and/or left side with negative positions. You can't change the viewport position so whenever you place a block at a position such as (-width, -height), it ends up hidden.

When looking at the element (F12 to enter Inspect Element area), the position is shown if the position field allows for such a hard coded position (this is the same location where you can see the size.) After F12 or Inspect Element, clikc on the Computed tab to see the position and various sizes.

Font Size

How the size of the font affects text... Ha! Ha! I just rarely think about this one. Why would anyone ever want to set the size of their font to zero?

Also in some browser kill your text if any one parent block defines its text font-size as zero.

The size should be a percent, an em, or a pixel size to be compatible with most platforms. The pixel size is not recommended now that we have so many smartphones.

Overlay

Whenever you create blocks, you can change their position such fixed or absolute. This gives you the ability to change their z-index value. The default background has a z-index of zero. Other layers are given a positive z-index.

When a non-transparent block is over another, it hides everything that's behind. If your text is behind such a block, then you won't see your text.

I often delete overlays when I debug such problems to see whather what's behind is as expected. If the overlay block is not supposed to be like that, you may need to change its parameters. But often the fact that the text is hidden by an overlay is considered normal and you thus would have nothing to do about it.

JavaScript

As I mentioned above, you may have JavaScript that goes through your page and hides some things there. If that's the case, then you need to work on that.

To test this theory, you can remove the JS from your page until you debug whatever other problems you may have.

Note that the JS may need to be fixed instead.

Of course, you have more complicated web pages which run the JS to show the text... in that case, not running the JS is not going to help you with debugging.

With jQuery you can easily hide and show blocks:

$("#your-text-block").hide();
$("#your-text-block").show();

You can also remove a block, which has the same effect as hidding its content.

$("#block-be-gone").remove();

The remove() deletes the specified element and all of its children.

You may also want to just clear what's inside an element, but keep the element itself:

$("#clear-block-content").empty();

Some other functions will have similar effects. For example, the detach() function removes the element from its current DOM and creates a fragment with it. As far as the end user is concerned, it's gone from his screen.

First Element when Referenced by ID

In some cases, you may be working with a library such as jQuery and attempting to access a list of elements that all have the same ID. Only the first element is likely to be modified as a result, though.

The fact is only one element is expected to be given a specific ID. This is because the HTML (XML really) specification says that an ID has to be unique among all IDs of a document.

So if you name a <div> tag content, you write:

<div id="content">...</div>

If you create blocks that you want to display in your sidebar and you want to define the <div> within that block as a block of content (After all, each block in the sidebar also includes content, just like the main page...) you would end up with one  <div> per block in your sidebar plus the main content block all using the id="cotent" attribute. This is not valid HTML. As a result your JavaScript  may fail when attemptingto change all those tags at the same time.

The solution to fix this problem is to use a class instead of an id. The result would look like this:

<div class="content">...</div>

You can have any number of element with a given class and each element can have any number of class names separated by spaces.

I myself did the mistake, in the old days, to use id="..." with the same name in different places. Now I rarely use id="..." because in most cases a class is going to be much better. id="<name>" is useful to make the anchor (#<name>) in a URL work as expected. With a CMS, it is best to have those ID generated automatically for each section of your page.

CSS Error

In some cases, I have had text disappear because there was an error in my CSS and some rules did not apply. For example, the color of your text could be black by default and at the bottom of your screen you have a black area with white text. In this case, you would have some CSS with a color field set to white.

#this-block {
  background-color: black;
  unknown-field: 123;
  color: white;
}

Here I show that the background-color is changed first, then an unknown field is defined, and, finally, we change the text color to white. Some browsers are not capable of recovering from errors like these and end up ignoring the last part of the CSS declaration; the color setup.

I don't recall exactly what makes some browser fail in this way. But it happens and that's a good idea to test your CSS to make sure it is loading as expected.

Invalid HTML Code

Once in a while, I write a template directly in HTML and miss something or other. For example, I may forget closing a tag. When that happens, the rest of the page is not unlikely to not work as expected.

Some tags can be auto-closed in various situations, but not others. For example, opening a paragraph (<p>) will automatically close the previous paragraph. The browser is smart enough to do that. (Yes, this could be a way to compress HTML further... although I think that's not advisable because there could be situations where this wouldn't work right. Also all browsers are not born equal.)

If you are a developer, you certainly have access to a tool such as wget. I would retrieve the page with wget and then run the page content through an XML parser and see what it tells you. The parser I use is xmllint from the libxml2-utils project. Note that xmllint can be used with --html which thus allows you to skip on making your HTML code XHTML if you don't want to. Personally, I find it much safer to have an XHTML page. Also in my case, I read the page content and create a DOM in memory and make changes through that interface rather than generate HTML text which may be broken in so many more ways...

Note that broken HTML code may not be detected as such in other browsers,

White Screen of Death (WSoD)

When using a CMS such as WordPress, Drupal, or Jumla, and you add themes, plugins, or you develope your own theme or plugin (note that in Drupal a plugin is called a module,) you often get what we call a White Screen of Death. This is when you try to load a page and all you get is a white page with nothing in it.

The name, White Screen of Death (WSoD), comes from the Microsoft Windows environment which would often crash and show you a blue screen which people tend to call the Blue Screen of Death (BSoD).

At times this is limited to the bottom of the page. Something goes wrong midway and the bottom doesn't make it to your browser. This is why when you test your changes you want to verify that the bottom of the page looks as expected. Otherwise you may miss a bug!

Either way, you need to fix the problem on the server side. If you just installed new themes or plugins, then removing these plugins may magically resolve the problem. If you are a programmer and you just noticed that after modifying your code, check your apache error output because that's where PHP is likely to save errors that happened while loading the page. Correct those errors and try again.