HTML mostly grew by accretion. Sure, there was a standards committee which set lots of standards (that's why we have so many); but the reality is that HTML evolved in the rough and tumble of the marketplace, and it shows. Various browser companies tried to distinguish themselves in the market by offering to "embrace and extend" the standard so as to fracture it to near un-usability. Lots of the code that services browsers checks to see which Version of IE is running so they know to rub their belly clockwise instead of counter-clockwise while standing on their heads. Then there is the whole disaster that is Flash, the delivery vehicle of choice for video.
To bring order from chaos it was decided on high that a new standard was needed. This is HTML 5. Currently HTML 4.01 is in broad use. There is a transition plan, of sorts. I suspect that, like Fortran and DOS, HTML 4.01 will never really die and the code written in it will always run in its own charmingly crippled fashion. But we can do better.
As a markup language HTML allows nearly infinite fiddling with page layout in great and fine detail. What it fails at is making any attempt at constructing a common theme or appearance for a collection of pages not be much more work than it is worth. It is this failing that CSS (Cascading Style Sheets) addresses.
HTML scatters appearance information throughout the document in <font size='3' color='red' face='ariel'> lots of fiddly bits. This is fundamentally wrong in that the information contained in the document is very distinct from the document's appearance. It is very easy to imagine the same document information in a variety of different appearances depending on the context. CSS solves this problem by moving all of the appearance information to one (or a few, it does cascade) place(s).
There is a starting place for all of this cascading. It's variable, but most folks start with a Style Sheet. It the case of this program it is located at ~/include/style/style.css This file is human readable text that describes the default appearance of the document it describes. This file is included as part of the <head>. What included means is that the contents of the file are inserted in that place. The head of an HTML document is non-printing (or rendering, it's only bits) as opposed to the body which is rendered (shown, painted on the screen). The head is where we put the bits of the document we don't want the reader to see. This includes information about the document itself (called meta-data), scripts that run when the user dinks with a control, and the appearance directives contained in the style.css file.
To make things a bit more concrete lets look at tables. Tables are wildly overused in HTML to position things relative to other things. The default appearance for a table is to have no border. Just for the sake of this illustration assume that the default for tables was a black border 1 pixel wide. Before CSS it was necessary to specifically turn on that border on each and every table in the document. This document makes extensive use of tables and the vast majority of them do not have borders. It would be nice if we could just turn them all off by default. Here's how it's done:
<style>
table,td,th
{
border:0px solid cyan;
}
</style>
This little fragment of style.css sets the default border for all tables in the document to be 0 pixels wide (which doesn't render), a solid as opposed to a dashed line, and colored cyan. While this is part of my file, style.css, you could just as easily drop that bit of code intact into the body of a document and it would work. Because it is between <style></style> tags the text describing what we want to do to tables is not rendered. The message is that you can use CSS anywhere, not just in the style.css file. Now, the default is that all table borders are turned off and for the few that I want to turn on I can do that locally by typing something like: <table style="border:4px solid black;padding:15px;">Which makes a table (much deleted detail) with a solid black border 4 pixels wide. The padding refers to an interior spacing within the table. CSS lets you set document wide defaults which are easily over-ridden locally at need. The closest CSS directive to an object controls its appearance. This is how styles cascade.
The syntax of CSS is a bit different than vanilla HTML. This is intentional so that the browsers can tell the difference so they know what to ignore, but it is also an improvement. HTML uses value="attribute" pairs to specify things. The CSS style is property:value; The semi-colon is required to delimit the end of the value(s) as property_0:value1 value2 value3;property_1:value1; is syntactically correct. A property and its associated values are referred to as a declaration.
Declarations are usually attached to a selector in style.css files. In the fragment above the selector(s) are table,td,th. This is what you hang the declaration on. As we have also seen above, declarations can appear in-line, as in
<table style="border:4px solid black;padding:15px;">Notice that while we are using CSS to specify the behavior of the table we still have an HTML value="attribute" pair which contains the CSS declarations. Since we are mostly using CSS in-line you will see style="declaration(s)" rather often.
I find that when debugging layout problems (too many tables) it is helpful to turn on the borders of tables so you can see where they are. CSS makes this easy. Another tip is that if you highlight all of your page (control-a, Select All) you can also easily see the table borders.
This document was originally written in an HTML 4.01 centric fashion. I am now trying to use CSS exclusively because it is so much better. Information will be provided on both styles, but CSS is preferred and it rules when used. What is meant by this is that if CSS is in use for defining table borders using HTML 4.01 appearance directives like:
<table border="2" color="red">will just fail without notification.
In my previous comment, I disparaged CSS a bit because I wanted to thumb my nose at the globalist folks who want to see old standards die. And I probably overstated my case, which may have prompted you to respond.
I use CSS and I wish FR allowed in-line CSS styling in posts and comments because CSS is familiar and more powerful for the user.
Agree too that CSS enables us to separate many of the design elements from the textual or structural HTML elements of a page. That creates cleaner, more efficient, and more easily maintained code.
And totally agree that includes in a web page are fantastic. It allows you to import a lengthy header, navigation, advertising, or footer section using only one line of reference code. Wish I had learned about "includes" earlier because they are so handy.
Let me introduce a new idea that your comment inspired. I wonder if we have taken CSS styling as far as it can — or should — go.
Consider this. At the end of each sentence in this comment, I have inserted a non-blank space symbol [ ] to increase text readability. For example:
Now rather than requiring me to manually insert these non-blank spaces after every sentence in a web page, wouldn't it be nice if we had a CSS function that globally inserted an extra space at the end of our sentences?
What do you think? I would personally use such a CSS rule extensively.
Finally, I'm glad you expanded on the CSS topic. We don't want people thinking they should go back to HTML element coding. We only do that as an expedient because that's all FR allows us to use today.
It's also fun to see a discussion of all this on FR. Cheers :- )