Originally Posted by
PearlDoves
I sincerely hope you didn't pay for that. Some of its information is misleading, and I wouldn't suggest that you use it.
But I was also checking against the one you mentioned.
Sorry about the broken link, by the way. I think I missed a closing square bracket (it's been fixed).
The first two paragraphs in the explanation of the first error give a fairly good overview of errors 1-9, including why an id attribute (which is available for almost all HTML elements) is flagged as invalid. The attributes that were flagged are either presentational and should be replaced by CSS, or were never part of HTML in the first place (for example, marginheight, which is proprietary).
The body attributes can be replaced by the following CSS rule:
Code:
body {
background: #000034;
color: #rrggbb;
margin: 0;
padding: 0; /* Some browsers use padding, not margins, for the body element. */
}
The color property is incomplete, but would take the value of that lighter blue (as it's anti-aliased, I'll leave the real [rather than apparent] colour to you).
The height attribute on the table is a problem because tables have never had an explicit height: it has been computed as a sum of each row height. A height property can be applied via CSS, but if the heights don't match, it's undefined how the space is distributed. Still, you can do it if you want.
Rather than placing a border attribute on every image within an anchor, you can use:
Code:
a:link img {
border: none;
}
Similarly, to keep that border for images within the gallery:
Code:
#motiongallery a:link img {
border: 1px solid;
}
The width attribute on table cells can be replaced by the width property in CSS. Alternatively, you could use columns (col elements). However, I wonder whether you need it at all for that lone cell.
Image Ready and Golive seem to default to XHTML ...
Yes, it's an unfortunate trend in editors. There's no problem in using XHTML in server-side processes (it can be useful for content management), but it's pointless for serving to clients: they don't process it as XHTML so any potential benefits are lost.
... if I seriously don't need this: <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" > I'll be willing to take it out
Technically yes, technically no. By default, text media types sent without a character set parameter should be processed as ISO-8859-1 (Latin-1). However, most browsers are configured to assume some other value (often Windows-1252). As a result, an explicit character set should be sent.
That said, you still shouldn't use a meta element, but actually configure the server to send it as part of the HTTP headers that begin the response. My IIS documentation is broken, so I'm afraid I can't tell you how do this for your site. If no-one else knows, you could try asking the server provider. The administrator might have to make the change, anyway.
So yea, my text editor.. When I open up my file in it, it shows up like a webpage in a browser would pretty much, which I thought was strange.
It certainly is. An odd (and slightly patronising; sorry) question: are you sure you used a text editor, rather than a word processor or some Web development-specific software? At most, text editors provide syntax highlighting or visual cues like bracket matching, but not fullblown rendering.
[Regarding document type declarations] ... do browsers not care unless you have the declaration spelled out for them?
As I mentioned in a previous post, the document type declaration is used by many modern browsers solely to switch to standard-compliant rendering. This is usually desirable because the CSS Specification provides rules that define precisely how a browser should respond to a particular CSS property value. There are of course problems with implementation bugs (MSIE being the worst recent browser), but there are usually workarounds.
It's not something that's necessary, but it does tend to make life a little easier.
Mike, I dunno if I'll know what to do if you take away the tables, lol, (because its easy to update due to the code that spits out of the programs).
Heh. 
They are a pain to manage by hand though, and to problem-shoot (at least when you get confronted with nested tables to the sixth degree, and other silliness).
But at the very least it'll be a good lesson in CSS.
Hopefully. I should get it done this weekend. The only thing that's putting me off is fiddling with the decorative images (I'll be aiming to convert most of the content to pure text, but keeping the same look).
But in a nutshell the probs seem to be coming from NOBR ID and the body tag, and I don't know how to manipulate code to make it work.
Maybe the above will help nudge you in the right direction. Ask, though, if you'd like a stronger push.
But part of me wonders if this is being flagged because the validator isn't taking into consideration the external files that go with the Dynamic Drive CMotion script?
No, that's not it.
I know one of those files is Java
Javascript. There's a (big) difference.
and I think the other is CSS related...
The style sheet is included via the link element, and there's no problem with that apart from the trailing slash you removed.
AHHHHHH! NOOOOO! lol, I've seen this problem before though, at another location, it had to do with monitor adjusting.
Yes, monitor calibration is a pain. I have recalibrated mine visually (just for you 
) and it's better, but I'd still prefer it to be ever so slightly brighter. It's not my decision, though.
But it sounds like you need to up your brightness and mess with your contrast a bit,
Actually, I had the ramp the gamma slightly.
because the background color should look like a darker (yet reasonably colorful) blue #000034.
I could see that today as there was a thunderstorm overhead and less ambient light, but I couldn't yesterday.
If you have a tube monitor, it could slowly die like a TV ...
I know, but...eek! Don't say things like that. This CRT isn't that old!
I'd hate to see you miss out on a colorful internet world
The problem I've always had with monitor calibration is conflicting advice about the right targets (I'm not a graphics person, so I listen to others who should know better) and the inevitable mixed results: colours look great in some cases, but washed out or subdued in others. Things seem to be going well at the moment, though.
However, you have to consider that the average user won't have calibrated their display (or even know that they should), and so they might still be in the same boat. Also, simple colour analysis does put the contrast under the recommended limits.
Out of idle curiosity, what have you set the colour temperature of your display to? The only advice that I didn't follow was to set it to 6500K. Though my eyes did adjust to the apparent yellow tint after a few minutes, it still seemed a little strange. And besides, I like blue (9300K).
Thanks again Everybody, I appreciate all this
a lot.
You're welcome! Again. 
Haha.
Mike
.src = Problem.yes; Site not showing up, extentions and doctypes
Bookmarks