Welcome to WebmasterWorld Guest from 188.8.131.52
Frankly, I'm just pretty proud of myself, considering I didn't even know what HTML was last week. There have been many times I wanted to beat my head into a wall with frustration, but I got it done!
My question now is how to begin developing more than that 1 page "coming soon" that I put up. I learned a little bit of HTML from a site called "NCSA - A Beginner's Guide to HTML". While it covered the basics thoroughly I don't know where to go to learn more, or most importantly achieve fluency with HTML. I see two options, either learn HTML throughly from scratch, or find some type of HTML editor that can be toggled back and forth from the source code to editor so that I can use it and then reverse-engineer what it did.
Which would you reccomend to me? And where should I go to learn more HTML and/or what editor program might fit the bill? Unless of course you have a third option?
And thanks for providing a place like this where a newb can ask the dumb questions without fear.
- Propellor heads get paid more for contract work.
I seriously doubt it as propeller heads usually have no business skills, which is why they waste time twiddling bits to rack up more hours.
Ever hear of working smart and not working hard?
You charge per job, not hour.
Crank it out fast and solid, move on to the next site, and 100% hand editing HTML isn't the way to prosper in that business model.
Heck, I started my first assembly language programming in 1978 using an octal keyboard to type in CPU machine language direct they paid me well for doing it but it didn't make sense to keep doing it that way once better tools came along.
It's ok, while you're wasting your time typing in HTML junk nobody sees in the browser when they get to the web page I'm long since done for the day and sampling another pint of beer. :)
I see two options, either learn HTML throughly from scratch, or find some type of HTML editor that can be toggled back and forth from the source code to editor so that I can use it and then reverse-engineer what it did.
But tearing down websites by copying their code from source and into an editor, and then remove and mess around with it, can also be fun.
And donīt forget CSS, knowing to code that by hand is also hardcore!
Not many people are talking about the type of code you can write, in this thread.
I think that most people here will have already banished <font> and <br> tags, and single pixel spacer GIF images, to history now?
Using CSS for styling makes for very lean HTML code. However, there are several ways to use CSS.
Some people put inline style="..." attributes in their HTML code. That is not a good solution. It has almost as much code bloat as the <font> tags that it replaces.
The other way is to have all the CSS in a stylesheet. This can go in the <head> section of the document, or better yet in an external .css stylesheet file. The latter is the best, because the stylesheet will be served once per visitor, rather than once per page view, and having one file for the whole site means that the style of every page can be instantly changed with just one edit.
There are several ways of writing HTML too. One is an unstructured tag soup, which may or may not validate: people use <br> tags to make spaces, and multiple to indent. These produce bloated code too.
To use CSS you really need to get the page to validate, but even moreso it needs a structure.
There are at least two types of HTML structure too: one is to use multiple nested <div> and <span> tags to make logical blocks of code.
These, however, have no semantic meaning (like <div class="mainheader"> for example) but this method is often favoured by people that also use CSS for positioning as well as for style. Personally I don't like that method.
The methodology that I now prefer is to make the page from headings, paragraphs, lists, tables and forms and then to style those elements using CSS in an external stylesheet. I then apply classes for exceptions, like <p class="footer"> or <ul class="nav"> and so on. I also find that if I am repeating a class in the HTML multiple times, then it is better to add the class name to a parent container and rewrite the style definition using a different type of selector.
I find that writing structured code, using the proper HTML building blocks (h1, h2, ..., h6, p, ul, ol, table, form, img which are all block-level elements) makes for the leanest and most easy to understand HTML code of all... which then becomes very easy to style too. It is also a doddle to get it to validate, as there is never a heap of multiple nested tags to wade through.
To learn HTML you need to know a couple of dozen tags, and their acceptable attributes and attribute values. To learn CSS you need to know about 20 or 30 properties (margin, color, etc).
The W3C validators for HTML and CSS are the most useful tools on the web [validator.w3.org ] and [jigsaw.w3.org ], along with WebBug for checking response codes for pages (such 200, 301, 404, etc) and Xenu LinkSleuth for making sure that all of your internal linking is OK.
Whether that is by using PHP or SSI doesn't really matter, but "includes" allow you to have one separate mini-file with the main site navigation in, another mini-file containing the common footer, and then every "page" of the site then just has an instruction to "include" the content of the other files right there on the page. The server then puts the full page of HTML together before sending it out.
The benefit to you is that to edit your navigation or footer, you only need to edit one common file on the sever, not every one of the 1000 pages of content. Yes, there are text editors that will allow global changes to be made to thousands of pages at a time, but after editing you then have to upload every page to the server again. With the "include" file, there is only one file to edit, and only one file to upload when you are done. Yet another time and effort saver...
...and with that, best of luck!