Conventions

When designing, coding, and otherwise creating JBT.name, I created a number of conventions which I followed to ensure consistency, usability, and beauty in JBT.name. Some of these conventions are immediately obvious when viewing any of my pages in a graphical web browser, while others require a more thorough examination of the code.

Fonts and Colors

For the main font of JBT.name, I use Arial. This is an easily readable font and is among the most widely supported fonts in the world. For devices that do not have Arial installed, I've set up a number of fallback fonts with similar style. Colorwise, I use a large amount of New Kidron Green,[1] my favorite color, but keep the majority of the text and background colors simple: black and white.

Font Sizes

For HTML pages, my titles are typically displayed at 26px, headings at 16px, and the majority of my text at 13px. For printable documents, such as ODT files, I use 20pt, 12pt, and 10pt sizes, respectively, which are roughly the same proportions. If the printable document needs to have larger font sizes, I might use the 24pt, 15pt, and 12pt sizes, respectively, which are likewise about the same proportions.

Links and Footnotes

I have styled all internal links (links to somewhere inside JBT.name) so that they are colored green. Links that are internal but not available to internet users are red. And blue links? These will take you outside of JBT.name.

My footnotes, being internal links, are always green. If a document already contains footnotes, these will be black and appear in the "Content" portion of a page, not in the "Metadata" portion; the metadata should only contain my own notes.

What about devices and/or browsers that don't support color? And what about color blind users? I have that covered, too. Since all public pages have a Size Indicator (described below), any links with such an indicator are publicly available. Any links that don't have them are either private or external. While it is usually obvious whether a link is private (e.g., it is in a directory) or external (e.g., it is on a Link Page) based on context, there is one more trick for figuring this out: external links all have "External Link" as their title. Hovering over one of these links will show that title in a tooltip box, if your device has an on-screen pointer.

Quotations and Citations

I use the <q> tag for quotations; this provides the best option aesthetically and semantically. Quoted text will look just like this: on modern browsers, it should be italicized and feature left- and right-handed quotation marks. What falls under the category of quotation? Any amount of text, taken word-for-word, from a source where I want to identify the text as coming from a source. This could be a dialogue between two speakers, text from a book, a short phrase from an audio clip, etc.

There are other places where I use quotation marks, as well. To distinguish these other uses, I use only straight quotation marks ("") in such cases. For instance, I may want to refer to a word as a word, not the concept it points to (i.e., I may want to talk about the spelling or etymology of a word). Or I may want to use so-called "scare quotes", quotation marks that can denote things such as irony (e.g., trying to impose "democracy" or the fact that this usage is called "scare quotes" in the first place!).

All book, movie, and album titles I reference will be contained in a <cite> tag and should be underlined. Chapters in a book or songs in an album will, at most, be enclosed in [straight] quotation marks. More formal citations of a work typically follow one of the formats laid out in the Chicago Manual of Style (the 16^th ed., specifically); it is simply the best and most comprehensive style guide for North American English and I make extensive use of it in my works, both online and off.

Language and Grammar

Since my native language is North American English, I create and update the site in that language. Grammatically, I generally keep to the conventions set forth in the the aforementioned Chicago Manual of Style; it forms the foundation of my website's grammar. I try to be consistent and obvious, exemplified by my use of the traditional serial comma. And I try to make my work accessible for the 21^st century. Because of this, I do sometimes deviate from the Chicago style. One of the most notable instances is in my use of punctuation with quotations. Whereas North American English typically has complex rules for what punctuation marks should be inside or outside of quotes (the period is almost always inside, whereas the semicolon is almost always not; I suspect these rules are leftovers from old typesetting more than anything), I've decided on what I believe to be a far better system: only those punctuation marks which are in the quotation stay inside the quotation, with the exception of the ellipsis (if needed). All other punctuation marks stay outside of the quotation marks. I later found out this is actually very common in British English. It is helpful enough when quoting more traditional prose, as it better preserves and communicates the context of the quote. But it is even more helpful when quoting modern works, or even code, where the exact placement of punctuation cannot be changed without causing a program to fail or a URL to point to the wrong place.

Measurements

When possible, I use metric measurements, such as meters (m), degrees Celsius (°C), and kilograms (kg). For measurements dealing with the binary system, such as bytes, I use IEC units, like kibibytes (KiB) and mebibytes (MiB), because they are more accurate for binary systems: whereas a metric kilobyte (KB) means 1,000 bytes (and is thus confusing and almost useless for binary information), a kibibyte (KiB) is 1,024 bytes (or 2^10th, a power of 2 and very helpful when dealing with computers). In digital measurement, I prefer pixels (px) to points (pts) or other measurements; pixels are the native unit of screens and this is the most appropriate measurement for on-screen text and graphics.

Preview Images

When I present a preview of an image in the Images directory, the maximum dimensions I will use are 111px for 1-dimensional images, 121x121px for 2-dimensional images, and 125x125x125vx for 3-dimensional images; this is to support small handheld devices.

File and Directory Names

For all files and directories, I use only lowercase letters with no spaces; so far, I've tried to avoid dashes and most other forms of punctuation, too. For directories, I do not allow underscores: directory names should be simple and obvious; they may be concatenated, abbreviated, or truncated where practical. For files, I am more flexible and verbose: I allow underscores to serve as spaces, allowing for longer, more descriptive, and more distinct filenames, when necessary. Of course, there are some instances where a filename is also a concatenation of two words without an underscore, but I try to limit this to cases where the words are already commonly combined (e.g., "sitemap" and "changelog"). As for length, I place a limit of 256 characters on the entire URL: some older systems cannot handle URLs longer than 255 bytes.

Because of these rules, it isn't very difficult to construct a filename from a page name, or vice versa. For example, a regular HTML page titled National Prayer of the Kingdom of New Kidron would have the filename "national_prayer_of_the_kingdom_of_new_kidron.html": everything is simply lowercased, spaces are turned into underscores, and the file type (.html) is appended; if there had been any form of punctuation, it would have probably been removed, too. To give an example of the reverse operation, consider a file named "personhood_vs_nationhood.html". To get a page title (and it is a page, because it is clearly a .html file), take everything but the file type (in this case, "personhood_vs_nationhood"), remove the underscores, captialize as needed, and add in any necessary punctuation (in this case, a period after "vs"): Personhood vs. Nationhood. It really is that easy!

The exceptions to this policy are pages in the Support directory and anything with a filename "index.html", "introduction.html", or "links.html"; these pages may have simpler names for ease of access and/or compatibility reasons. For example, the support page titled Introduction to JBT.name is actually just named "introduction.html". Or take "copyright.html": it is actually my Public Domain Notice; it is only called "copyright.html" by convention, so people know where to find that type of information!

What about non-HTML files or metadata pages for them? That is still very similar and still [usually] quite algorithmic. For more nuanced instructions on audio files and their associated metadata pages, visit Introduction to My Audio Directory. Other file types don't have more detailed instructions (yet!), but my rules for naming them should be straightforward enough to glean without much effort.

Index and Sitemap Conventions

On the top of each index page, I have clearly denoted the name of the directory it belongs to as well as its own parent directory (if it is a third-level directory). For example, Library: About Me is a third-level directory inside the second-level directory Library. Below the title, I've written a brief description of the directory and what kind of pages or files you can expect to find in it. The first link in the index is always to the index itself, and thus blacked out; it will always be followed by the text "You are here.". The Link Page, if present, will always be last on the list; the only exception to this is the main Link Page on my Root Index.

I have tried to keep images at a minimum in the indexes, so the links will always be plain text. In order to further prevent clutter, I typically use only the page's main title for the text of the link. With some types of files (such as audio files) or dated materials, I may add a small amount of extra information to aid in identification and differentiation of the pages. Because the focus of my website is communion, I have not directly linked to any actual files in my indexes, but rather the metadata pages about them. The files themselves, if I have them available for download, can be accessed from these metadata pages.

What is different on the Sitemap? First of all, each link is preceded by an image denoting what kind of file it is (e.g., HTML). Second, the names of pages appear in their URL forms only (except in the tooltips, where they have their usual name following their parent directory's URL). Everything else, such as page order, should be the identical to what is found in the indexes.

On both my indexes and the Sitemap, I do not always have pages arranged alphabetically; sometimes they are in groups, with or without subheadings. Another similarity is that I use vertical spacing to further separate files into blocks I consider more logical and easier to use. And finally, on both, I denote parent and child relationships between metadata pages and their files with extra indentation. For instance, on the Sitemap, the metadata page JBT [Full] (.png) is clearly the parent of the actual image, jbt_full.png.

File Size

To help preserve my own bandwidth and protect users from using too much of their own, I've set a limit of 3MiB on public files; anything larger than 3MiB will only be available to local users in New Kidron. To that same end, on both my indexes and the Sitemap, I've also added a series of vertically-centered degree marks (°) just to the left of every link to give a rough estimation of size of the file; I call this the Size Indicator, and this may help you particularly if you're using a slower connection or have a limited amount of bandwidth (e.g., you're using a device with a predetermined allowance of data transmission each month). One degree mark (°) denotes a file with a total size of less than 20KiB. Two degree marks (°°) highlight a file between 20 and 49.9 KiB in size. Three degree marks (°°°) announce that a file is between 50 and 99.9 KiB. Four degree marks (°°°°) indicate that the contents are between 100 and 499 KiB in size. And five degree marks (°°°°°) warn that a file is especially large, containing over 500KiB of text, images, etc. (This measurement includes images that are unique (or nearly so) to the file, but does not include the standard Style images that maybe found on every HTML page or my CSS file, which together only add about 15–30KiB, depending on your screen resolution.) Of course, I am still not offering any third-party programs at this time, regardless of size.

Metadata Section Order

Within my pages, I have a number of common metadata sections that I use.[2] Since I do not use every section on every page, I created an order to determine where each section should appear. From first to last, the sections are:

1. Mirror
2. Specifications
3. Description
4. [Special] (e.g., Installation & Configuration, Settings, Source Code, Lyrics)
5. Interpretation
6. Authorship

These sections are followed, if applicable, by the footnotes. Excepted from metadata are some of the pages in my Root and Support directories; these pages are simpler to better facilitate new users or users who are having trouble with some aspect the website. All indexes are excepted from having metadata, too, as this would be superfluous.

HTML Tags

When creating an HTML tag, I use only lowercase letters and offset new-line child tags by one space (e.g., an <li> tag, if on a new line, would be indented one space greater than its parent tag, <ul>). I also try to keep all of the tags' attributes in the same order, as follows:

<meta> Tags

1. http-equiv
2. name
3. content

General Tags

1. rel
2. id
3. name
4. class
5. type
6. media
7. style
8. width
9. height
10. value
11. title
12. alt
13. src
14. href
15. accesskey

<table> Tags

1. class
2. width
3. height
4. border
5. cellpadding
6. cellspacing
7. title
8. summary

I also have rules for when to use the various heading tags. I use <h1> only for the title and subtitle of my website ("JBT.name" and "...A Place for Personal Communion with Me", respectively). For page titles (e.g., "Conventions") and major portions of a page (i.e., "Quick Links" or "Metadata"), I use <h2>. I have the majority of my pages' content broken into sections, each with a heading in <h3>. For subsections, I typically use <h4>. Finally, for the subtitle and author of a work I have fully reproduced or to break down a subsection further, I use <h5>. Currently, I do not use <h6> anywhere.

CSS Rules

When I write CSS rules, I use much the same conventions as when I write an HTML tag: I use only lowercase letters and offset new-line child selectors by one space (e.g., a "ul li" selector, if on a new line, would be indented one space greater than its parent selector, "ul"). And, just as in the case of HTML, I try to keep all of the selectors and properties in the same order, as follows:

CSS Selectors

1. *
2. body
3. div
4. h1–6
5. p
6. a
7. ol
8. ul
9. img
10. span
11. table
12. form
13. br
14. q
15. cite
16. sup
17. sub
18. cite
19. kbd
20. hr
21. .
22. * html (Special IE-only hacks "commands")
23. @media

CSS Properties

1. width (max, min)
2. height (max, min)
3. margin (top, right, bottom, left)
4. border (top, right, bottom, left) (width, color, style, collapse)
5. padding (top, right, bottom, left)
6. font- (size, family, weight, style)
7. color
8. text- (indent, decoration, align)
9. vertical-align
10. line-height
11. list-style
12. background
13. position
14. top
15. right
16. bottom
17. left
18. clear
19. float
20. display

Of course, when it is possible to provide properties for different sides of an element (i.e., where I've put "(top, right, bottom, left)"), I often use shorthand. With one value, the value applies to all sides. With two values, the first applies to the top and bottom while the second applies to the right and left. With three values, the first applies to the top, the second to the right and left, and the third to the bottom. With all four values, the values apply in the standard order: top, right, bottom, left.