http://validator.w3.org/check?uri=http%3A%2F%2Fwww.hotlinkhosting.com%2Fwelcome.php

How do I fix these errors?

is this because of the space after the first set of quotes ?

lol, no

Move those table backgrounds into a style sheet. The background attribute has never existed in any version of HTML, ever. It's proprietary, obsolete, will never pass through a validator and there is no guarantee of future browser support (it's luck that most browsers even support it now).

How much familiarity do you have with CSS?

Not a whole lot. I can add styles to words, that's about it.

Do what "the_pm" said.

You're building a xhtml page with old code - kinda defeats the purpose of making an xhtml page doesnt it?

If you're going for standards - then you're going to have to learn some css.

To illeviate that issue you're having, change the ( td background="images/7.jpg" ) to a ( td class="tdbgnew" )
and in your css sheet you'd need to do something like:
td .tdbgnew {
backgroung-image: url(images/7.jpg); }

For lack of better coding practices, that will fix your validation issue for now...

Well, the best way to tackle this is for you to give each element a class (or unique id) to indicate you intend to write a CSS rule for it.

For example, let's take your first error and change it to read:

<td class="foo">

Now, we go into your CSS document (or you create and link to a new document if you don't already have one), and you create a new rule:

.foo {
background: url(images/7.jpg);
height: 54px;
width: 192px;
}

By doing this, you've created one rule that can be used across every page on your site, should this table cell happen to show up on every page or in multiple places on a page. Now, the W3C validator will only show an error once, regardless of how many times it shows up on the page, so if you intend to stick with using tables in this layout (which is unnecessary - you could reduce 90%+ of your code using proper CSS techniques), you'll have quite the task ahead of you getting this to function the way you want.

But this is how it's done, if you'd like to pursue making your site valid, and more importantly, making sure you use techniques guarenteed to be recognized by browser manufacturers in the future!

Edit: Looks like Ryno beat me to the punch :) He just missed the part about not needing all that table bloat!

lol.. thats cool - I just gave him that little bit to fix his one error... I WOULD code the whole thing... haha...

what he SHOULD do is NOT use tables... heh... ahh if the whole world was perfect....


@ "the_pm" - take it easy.. ;)

You too bro :)

I have fixed the errors, but how do I not use tables?

use divs and css.

Sorry, I didn't mean to ask how, but rather why not? Why are tables bad?

Tables are for tabular data--such as a pricing or inventory list. They were not made for layouts.

Divs, on the other hand, are made specifically for presentation. CSS lets you control how the divs look.

I'd only suggest looking into it if you have the time to spend learning how to code correctly--and don't mind losing a lot of hair in the process.

I've allready started looking into it and recoding my pages. I basically only have to recode one, for mostly all of my pages use the same layout. Are there any benefits to quality coding besides compatibility with browsers?

Tables may or may not be "bad," depending on how they're used, but they are ultimately the worst choice for 99.9% of all design layouts. Here's a little list off the top of my head, starting from the fundamentals:

1. Tables were never meant to be used as layout devices. The purpose of tables has always been to display tabular data, not to give a page its structure. The gentleman who first conceived of using tables for layout in 1996 lamented it about two years later, saying "The Web is dead, and I killed it." Ok, but it works, right? Maybe...

2. Table bloat your code. I've seen sites, properly optimized, go from 30 kb./page in just code down to 3 kb. or less. The reduction in bandwidth can make for significant savings, and the load speed is always appreciated by the end user.

3. Tables are rigid. If you want to make adjustments to the structure of your site, you have to make those adjustment to every single page. When you move away from tables, you can do the same task by just changing a single line of text in a CSS document.

4. Tables rarely play nice with non-traditional browsing devices, such as cell phones and PDAs. At least, they do not play as nice as a well-designed tableless site.

5. Tables can cause problems for visitors with special needs. Depending on how you lay out your site, you can make it very difficult for visitors with limited sight to use your site with ease. Tables can make it difficult for special browsing devices to override important structural mechanism necessary for people with disabilities to use a page. This is not always the case, but it's far less of a risk using the better tableless methods.

6. If being more user-friendly isn't enough, well-optimized sites play much friendlier with search engines. To a great degree, this goes beyond validation (which is nothing more than a baseline), and it goes past tableless design to sematic validity.

So, there are some reasons. You're experiencing one of those reasons now, having to dig through endless lines of code bloat on endless pages of a site. Does that help?

Thanks alot for your help. Can you answer one more question?
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.hotlinkhosting.com%2Ftos.php
The javascript I use to display my email address is giving many incompatible errors.

Just include the javascript via a <script type="javascript" src="javascript.js"></javascript> tag.

Also, you do not have to escape quotes unless they are nested within the same type.

ie:echo "Hello \"Dan!\"";echo "Hello 'Dan!'";echo 'Hello \'Dan!\'';echo 'Hello, "Dan!";Those would all be correct usages.

You can fix the first two errors yourself. :stickout:

Edit: The third one should have the quotes escaped--seems to be a vB bug.

Make that <script type="text/javascript" src="javascript.js"></script> ;)

That's what I get for not paying attention to myself. :emlaugh:

Isn't it better to do this, or does it really matter? <script type="text/javascript" src="javascript.js" />

The <script> tag does come with an end tag. It's not a tag you self close. You close it the same way you'd close an empty textarea, with the close tag immediately following the open tag.