CSS complications

the a:hover doest work on NS4.x but the font coloring does.

a:link {...}
a:active {...}
a:visted {...}
a:hover {...}

are for normal text links, for secondary links you need something like:

a:link.menu {...}
a:active.menu {...}
a:visted.menu {...}
a:hover.menu {...}

and in the tag you have class="menu"

also dont use quotes around RGB colors, color:#CCCCCC; is how it should be written

Ah, Busy beat me to it.

S

forgot to add using link colors in your body tag can cause different effects in older browsers if used with CSS

Well a couple of things. One if you remove the quotes "" around the rgb color value:
a.menu { color: "#ffaa00"; to a.menu { color: #ffaa00;

That should fix the NS problem. The hover color won't work in NS 4.7 but the link still works okay. I would also clean it up a little to make it easier to follow and add the a:visited, a:active and a:link tags also. I usually make them the same as my a: value. I would also consider using an external stylesheet.

Here is kind of a generic one that I use some, changing the font size and color to fit:

Thank you all. I was actually HOPING that I was doing something that was obviously wrong, thereby making it easier to find what it was I should fix. It'll be a few days before I can sit down and work on it but all the above responses looks very promising for me fixing it. (And if the hover doesn't work in some browsers than that's not major). I'm thanking you guys just about everyday lately but Thanks again!

hey Mike - why is everything on one line? - makes it tough to diagnose

here's mmy analysis:

1) since this is a .shtml file, you are correct in not including and tags - however, you do have a closing tag in there - probably ignored

2) Busy's right - the attributes you've set in your BODY tag are overwriting the style sheet - e.g., link="#0000ff" is making the links blue instead of orange

3) vspace and hspace are not supported as attributes for TD, but rather for IMG

mmi -- html doesn't over-ride CSS -- only when the CSS is malformed and dysfunctional. Then the browser reverts to html.

Suzanne

I believe you're correct, Suzanne - in this case, mmy reasoning was "malformed and dysfunctional"

I hate to change the subject here but MMI, why do you always put mm's when you type my or me?
Just curious is all. *like a cat*

and you know what curiosity did to the cat!

Stick with it Mike, it's taken me a while to get to grips with css but it's well worth it. A good tool is TopStyle from bradsoft.com and you can use the evaluation copy to check compatability, clean up your style sheet and many other useful things. Well worth checking it out.

Quote: Originally posted by mairving
I would also consider using an external stylesheet.

One quick question, I am using SSI to call a header and footer. The header encompasses everything from to the beginning of the text in the main table, including all the CSS info. Knowing this, is there still an advantage in using an exernal CSS file? I just figured that I would still have to edit only one file (the header), and my thinking was that doing it this way would cut down on the browser and server having to call extra files. Was my thinking valid? and is there an advantage of using external CSS if it's in the header SSI anyway?

if content being styled appears on only one page, I'm guessing there's no advantage to "externalizing" - on another point, is there any consequence to placing a TITLE in an SSI file?

DM: I need to clean mmy keyboard - sommetimmes the em sticks

Julia: I believe curiosity killed the cat - but did you know that "satisfaction brought 'im back?"

mmi-

the only reason I start my header file after the title tag is because I found that some search engines put a heavy emphasis on words found in page titles. This way I can title pages individually, like "Mysite.com - sub-title."

Otherwise, back to the CSS, I would maintain the CSS from the one header file, but all my site's pages will be utilizing this file via SSI, which will in turn create the menu.

hey - I figured search engines was the reason - I know VERY little about this topic, but is an SSI "detected" by any of them?

Anybody can correct me if I'm wrong, but when you use SSI, it's just like breaking up parts of your web page into sections. You can theoretically have a webpage with nothing in it except all SSI calls. Then when a browser requests that page from your server, the server recognizes the .shtml extention and knows that it must first look for SSI calls and put the page together first. The end user never sees a difference. Even if you read the source code you wouldn't know (unless it's noted in a comment tag) because the SSI call will be replaced by whatever is in that external file. it's all been pre-assembled before it gets to your computer. This will also be true for search engines because once it requests your .shtml page, the server will gather up all the SSI elements and add them to produce the page before it is sent.

(If I've got part of that explaination wrong anybody can correct me )

No, SSI, like PHP, ASP, et cetera is server-side. The search engines pull the parsed page -- as it appears in the browser.

The only advantage to using external CSS in this case would be for validating it and developing it in the first place, or if you are using more advanced CSS and want to hide some parts from older browsers.

Of course, if you have any pages that aren't parsed, it would be helpful, but that doesn't appear to be the case.

Suzanne

Sorry, Mike, looks like I'm disagreeing with you -- I'm not. You have it right. But you beat me to the post!

Suzanne

so is there any SE-related reason to include a TITLE in an SSI? - it would appropriately be placed inside the HEAD, right? - and ya don't want multi-headed pages, do ya? :eek:

If you have this as an include...

$variable

Or, in otherwords, if you have both SSI and a database. For some sites I've used conditional scripting in the SSI to make the titles happen -- itservices.ubc.ca for instance -- so when new pages are created, the navigation and the header include are edited, and the new page is a list of includes only.

This was to prepare for database integration in a future version of the site.

So yes -- the title is included in the header SSI so there can be unique meta tags and titles for the pages to prepare for database integration in the future.

Suzanne

well, I appreciate that url - but would the example you've provided be an appropriate structure for an include, i.e., with HTML and HEAD tags?

Anything, ANYTHING can be in an include. I could make a page thusly:

include header file
include body file
include footer file

And in the header file have to , in the body file, the content, and in the footer file

It doesn't matter to the browser because they are glued together on the server before the browser sees it.

S

So I've now implemented a combination of everybody's CSS suggestions. Thanks. From my tests it works and looks good in IE 5 and NS 6. It still has some problems in NS 4, but the glass-half-full side is that it isn't lime green and aqua anymore either. Plus I cleaned up the code to make it easier for y'all to read.

Check it out at charlottemlb.com/softball/home.shtml

Let me know if everything seems okay for the most part and I'll consider my CSS adventure to be over (for now) and I'll move back into building up the content of my site. Thanks again everyone.

P.S. The 'font size=1' tag overrides my CSS properties in the copyright at the bottom. So why do my 'font size=1' tags NOT override the CSS properties in that yellow calendar box?

logically there is an error in your CSS -- again, HTML does not override CSS, but if the CSS is busted, then the browser will revert to the HTML specifications.

Part of the problem is that you are not using well-formed HTML. Close up those paragraph tags.

Also, there is nothing specified in that area?

a:link.menu should be a.menu:link, et cetera, as well. (Check in Opera to see if it's working).

Should be:

Of course, it would be even better if you just turfed the font tags.

I don't see anything else glaringly wrong with the CSS, did you validate it?

well playing around fixing the a.class:pseudoclass thing makes the colours work in Opera, but I'm having the same problem with the bottom.

more later.

You have a whack of other errors in the HTML -- validating that will help considerably.

You could also set the font tag in the CSS, btw.

font {font-size: ....}

And the reason the font tag is affecting things? Two reasons: one, no valid DOCTYPE, and two, you're actually using a tag, but not declaring it in the CSS. The HTML is not overriding the CSS so much as you are setting a new state for things within the font tags. You can remove them entirely.

The inheritance is like this for that section -- Make everything what the CSS says for P, except for here, this bit, use the FONT declaration. But there is no font declaration in the CSS, so it uses the HTML instead.

If you put all the information into the CSS, it will render fine for people without CSS support (default colours and links) -- which is less than 1% of the audience for most sites. AND that way you can remove the font tags entirely.

Suzanne

Quote: Originally posted by Suzanne
well playing around fixing the a.class:pseudoclass thing makes the colours work in Opera, but I'm having the same problem with the bottom.

more later.

Actually, the bottom copyright part is working the way I wanted to, being font size=1. It's that calendar box that I can't figure out. I realize that eventually I should change everything to CSS, and I will eventually, but it's just bugging me how the copyright section and the calendar are done the same exact way ( x ) but for some reason it works in one place and not another. But anyway, yes, I will eventually change over to inline CSS for variable text sizes.

Probably because of inheritance issues -- some things inherit properly, others don't.

Good luck!

Suzanne