The planned series is aimed at giving hints on specific tags and style features that could help get some web page developers out of snags they encounter when using a design tool that fails on some issue. That is the goal. However, before doing the first real coding lets look at the very simple development environment I use. In a pinch all a coder needs is a browser, a text editor and some disc space on a local computer. Eventually, however, a working internet connection is not an option - it's a requirement.
We begin by storing out files in a fixed set of locations. I would suggest something obvious like (in your home directory) naming your project by the site name. Hence, you could bring up the home page by typing in the file location. Under Linux it would look like this:
file:///home/<user alias>/<project or site name>/index.html
Typing something akin into the above in your browser's prompt will bring up your home page. Moreover, this page should exactly match what you would see if this page were served to you from a remote, internet server when viewed on the same machine and browser combination. Should this fail, begin by being certain you have your home page in both locations has the exact same version of the css file. But the server version of your home page uses the url to link properly in the <header> section. So set the link consistently:
<link rel="stylesheet" href="file:///home/<alias>/<project
or site url>/style-sheet.css" type="text/css" />
That's what the local version has. However, to remind yourself that the server version uses a url use a comment. The two can be exchanged to move from testing to production or the inverse. I store the actual url beneath in a comment format:
<!-- // Remember put in the url before loading on the server.
http://www.<site-name>.<whatever> // -->
[Note the double slashes (//) are for me, not a required part of the comment format.]
At this stage it is good idea to give some thought to a few issues that could determine the long term success of your development efforts. Begin with thinking how your actual site will be organized, i.e. the directory structure. In my case, I intend to mimic the directory structure locally to the one I build on the server. The next important issue is how to archive or store the site's web page evolution. For a large site a version control system [1.] has several advantages, these are: more efficient resources use, more rapid recovery and more easily reintroduction of dropped features from an intermediate phase. The last is your backend database, since the possibilities are both too diverse and the actual choice may not be given to the developer, I suggest making its acquaintance.
Regarding the retaining of previous versions of web pages, here is what I am doing currently. First testing is run on files in a subdirectory Ship-to-Server [2.]. Once I am satisfied with the test version, the previous version of the page is copied keeping the same time stamp and an added extension of the date. Should I do more than one alteration per day (unlikely) I will use roman numerals (soon after I would have a version control system installed). Then I copy the test version in with its time stamp unaltered into the local storage directory where it over writes the older version.
That is just a bit more that happens to the successful test file. The file references are replaced by URLs and this might also be the better time to add some of the <meta> tag lines in the header. On the next update, you might be surprised to see that your testing went well despite having forgotten to revert to file references in every link. Of course, this assumes you have a live connection to the internet. Let me warn you, however, that you could encounter frustration when expected changes do not seem to take upon a refresh. This happened to me when I kept altering the local version of the css file, but on checking my test version was actually using the unaltered version on the server.
Regarding my physical work environment I will have some words elsewhere in another How To topic. However, the circumstances many developers find themselves are not open to change. Hence, for now I see nothing constructive describing my setup.
To be effective and be able to code quickly, I have found having a set of on-line resources close at hand enhances my output. My list begins with the one most important to me - css Tutorial by the W3Schools, use the left hand column to find the topic you need. I find it a good source, with an easy lookup and ok examples.
Next, I find that color codes are needed often and on short notice, this exhibits examples of color and code. I had a link on this topic I liked better, however, I lost it. Nonetheless, this link may be superior showing clearly the actual color your monitor will reproduce. I put it to use often.
Moving down the list is the html tags, this is a quick route to the entire list of tags. When it comes to question of syntax or scope regarding tags I may not have used previously, here is the way they are shown by W3 Schools check here to see their explanation. Also use the left hand column to select other tags of interest. There are many html tags I rarely use, do not remember, or have never used. Hence, I need to be either reminded or told of their scope of control so that I use the proper properties or attributes in the associated css file. Finally, presentation matters. Thus, a page with a different look may be easier for some to comprehend than another with nearly matching content. Find those that suit your needs. For example here is another html information source I keep handy. Did you notice it's the same source I use for the color guide?
I suggest as a matter of principle visiting W3C, a.k.a. the World Wide Web Consortium. I believe I obtained a pdf version CSS2 documentation from this site. Parts of the documentation are difficult for me to understand than others. Nonetheless, I attempt to read and understand as much as I can. Unfortunately, there is more of the former than the latter. Perhaps you can do better than I.
Let's assume you built a pair of files for the main page and css file. It looks great on your browser, everything works perfectly. Unfortunately, your efforts are not quite ready for the production server. For example, what worked perfectly on Firefox may give you a shock when run by Internet Explorer 6. If you encounter such a barrier, use either an inspired guess or research to fix the flaw. Whether by inspiration or perspiration a work around has to be found. Once successful you can begin your transfer of the files to the server. Don't forget to change those files for URLs to match the production style sheet and add those meta tags you need and are appropriate for your site.
I am reluctant to say much on this topic, despite now being a web master. I am too certain that the environment I operated under is quite different than most, hence, I see little gain by my describing how I bring new files onto our server. If enough voices dissent we can converse via email or I will provide some detail on this site. [Check below for email links.]
My working assumption is that most readers of these How Tos will have more experience in web page creation than I. Moreover, I fully expect most to know tools and techniques that perhaps I will never learn. Nonetheless, I know from experience I have given insight and ideas to others that have had more experience. Furthermore, I know that expository explorations on technical topics some aver as the best in existence seems almost completely opaque and in the worse case devoid of content. Hence, should you think you can cover the same topic better, do it (send me a link so that I can learn to do it better). It may be again a case presentation. Search and find what is best for you, whether is one topic or everything. Look at the links above, they cover the same topics. However, some are better than others. Same could hold here.
If you happen to be new to web page coding, I will tend to be short on details a beginner might need. Nonetheless, take what you can get even if it is a sense how you might make more complex pages without the aid of a web design tool.
It is my intention to keep the discussions as tightly focused as I can on a single topic, meaning one particular tag or a logically grouped set. Coming soon my take on the <div> tag to create interestingly structured web pages.
Corrections, suggested extension or comments write: How-To-Guy. If the mailto does not work, use this: hcohen[-At-]bst-softwaredevs.com.
© Herschel Cohen, All Rights Reserved
____________________________________________________________________ 1. My views have changed: I was mistaken. Source / Version Control is a necessity. If your site is active, no matter how small, start early. Your work load will be lessened even when you have to revise the storage structure later. Return 2. This was another gross error, manual copying is too haphazard a method to store source versions. Moreover, the clutter created was confusing. Too often the latest, nearest to correct version resided only on the production server. Furthermore, a test only server is the better environment, upon which to catch your errors. Return