What's wrong with my website? (it's weird in Opera and Safar browser)


what did I do wrong?

I take it you’ve tested it in some other browser, which doesn’t look weird, is that right? From where I am, it looks pretty strange in both Firefox and Chromium, I have to say, but then I’m not sure how it’s meant to look. :slight_smile: Perhaps you could explain more clearly which parts are faulty and how they should appear.

I would normally suggest running your pages through the W3C Validator as a first step in trouble-shooting, but the validator is choking on some of the characters in your home page. On your other pages, it gives this warning:

Character Encoding mismatch!

The character encoding specified in the HTTP header (utf-8) is different from the value in the <meta> element (iso-8859-1). I will use the value from the HTTP header (utf-8) for this validation.

You seem to have lots of text not inside a paragraph?
And you seem to use a span as if it was a div (with a h3 and lots of paragraphs (but without the <p> tags) of text inside it).
And don’t use <br> tags to create a margin between your headers and the text. Use CSS instead.

One thing you should also note is that your doctype is incomplete. You don’t have an ending URI to the end of it. Also why did you choose transitional? WHat’s transitioning about the page? Use this doctype instead :).

<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01//EN” “http://www.w3.org/TR/html4/strict.dtd”>

Well, as pointed out you’ve got invalid characters… I can’t quite say what browser it looks ‘right’ in as they’re all pretty messed up, so I’m going to just go down the code and point out what I’m seeing ‘wrong’. Warning, I can be brutally frank on this – don’t take it personally, I’m trying to HELP.

The first thing to catch my eye is the Tranny doctype. That is basically the equivalent to saying “I’m writing HTML 3.2 and slapping this on it to PRETEND I’m writing modern code” – it LITERALLY means “coding in transition from 1997 to 1998”… There’s a reason none of us should be writing anything but STRICT after around 2001. (when it truly became real world deployable).

Inlining your style in the page is a waste of bandwidth when it comes to your sub-pages; that’s what external stylesheets are for… even during the development stage it’s just bad practice to do that; it’s also easier to deal with in a separate file since you can open it as a separate window (if your editor is worth a flying fig leaf) and see them side-by-side; the style and what it’s being applied to.

You’re spending a lot of time setting margins that could be collapsing differently across browsers, NOT resetting all the elements you are using (like the numbered headings), and you should look into the “condensed” versions of properties like margin or font.

… and the fixed width layout with FIXED side margins is really bad from an accessibility standpoint.

You’re values are just all over the place – setting family and size here, margins over here, colors over here… Condense that down to make it easier to maintain and to prevent you from declaring the same things more than once. You’ve got line-heights smaller than the font-size (which usually doesn’t work – IE will ignore that)…

… and the lack of a MEDIA attribute means your ‘screen’ style is being sent to everything. I’d put media=“screen,projection,tv” on that so that you aren’t wasting people’s ink on print, and so things like handheld just get the semantic markup instead of trying to give them a layout too big for their displays. (or make a tuned handheld.css to apply little more than FaC - Fonts and Colors)

Not all of that is related to your issue, it’s just what I’m seeing.

Once we get down to the markup your heading orders make no sense – that H2 is NOT starting a new subsection of the page, you’re using double breaks to do paragraphs job, you seem to have a div#header element for no good reason, a section of single line break items that LOOKS like it should be a list…

Also if you’re going to have block level openings, don’t stuff them at the end of excessively long lines… line them up properly – I think you’re missing a few opening tags, but I could simply just not be seeing them (and with the validator rejecting it’s character encoding can’t verify that).

… and not having the header stuff inside .container is likely why it’s not lining up in all browsers here.

The inconsistent placement of comments could also trip bugs in legacy versions of FF/IE – it kind-of looks like you were trying to place them to mitigate that, but missed it in a couple places i[/i]

Also, why say end? Can’t we tell that </div> might be the end of something? Just saying…

Likewise you’ve got a bit of presentational/outdated markup going on (transitional doctype allows for it, doesn’t mean one should do it) – attributes like align or vspace on IMG for example – much less the inlined style on said plate images.

… and you also have the accessibility failing of using px metric fonts on your content.

First order of business is to drag the markup into this decade by switching to strict, removing the handful of outdated/unneccesary properties, and making the markup a wee bit more semantic. REALLY for everything I just said, your HTML isn’t too bad – the ‘content driven’ nature of the page left plenty of wiggle room in that regard – and that’s a good thing. Content is king, and on the internet TEXT is the primary type of content.

So… for HTML I’d have:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"

	content="text/html; charset=utf-8"



	SOOPA - Similkameen Okanagan Organic Producers Association


<div id="pageWrapper">

		<small>Similkameen Okanagan Organic Producers Association</small>
	<ul id="mainMenu">
		<li><a href="index.html">HOME</a></li>
		<li><a href="farms_1.html">FARMS_1</a></li>
		<li><a href="farms_2.html">FARMS_2</a></li>
		<li><a href="farms_3.html">FARMS_3</a></li>
		<li><a href="links.html">LINKS</a></li>
		<li><a href="mailto:soopa@nethop.net">CONTACT US</a></li>
	<hr />
	<div id="content">
			The Similkameen Valley is unique in having one of the highest concentrations of organic growers and processors in Canada.
			width="400" height="206"
			The Organic movement started with small-scale farm growers who believed in healthy, natural, environmentally friendly farming. We have growers in the Valley that have been growing food without toxic chemical inputs for 30 years and longer. These pioneer organic farmers inspired others who moved into the area and began farming organically. They were concerned not only with producing wholesome harvests. They were also determined to improve the quality of the environment that their own food was grown in. Believing that toxic chemical sprays would be harmful to themselves and kill their beneficial insects, whose work they would then inherit, they abandoned the use of pesticides, herbicides and artificial fertilizers. Since healthy soil is the basis for plant health, a strong emphasis on soil building began to develop.
		<h2>Environment Awareness</h2>
			alt="S.O.O.P.A. Certified Stamp"
			width="140" height="136"
			This new attitude that began developing within the farm community coincided with a heightened awareness of toxic chemical inputs and their damage to the environment. Rachel Carson&rsquo;s book &ldquo;Silent Spring&rdquo; was one of the main influences in the increased interest in the concept of organic farming. There were no standards for organic farmers at this point in time and no definition of what an organic farmer was, there was just a persistent notion that if alternatives to toxic chemical controls were sought, they would very likely be found. In the Similkameen Valley, farm workers were becoming more vocal about their poisonous work environment and began to demand that farmers not spray while they were working in the orchard. A new attitude within the &ldquo;farm workers community&rdquo; was growing as well and it was represented by the formation of a Farm Workers Union that called for safer working conditions for people working around toxic chemicals commonly used on farms. Shortly after this the WCB developed the pesticide applicators course, which is designed to teach farm workers about safe application of toxic pesticides and other toxic chemical inputs.
		<h2>The Development of Certification Programs &amp; the Formation of SOOPA</h2>
			Following the trend developing in the organic industry, the Similkameen Valley organic growers followed suit in 1986 when 10 founding members initiated the formation of the Similkameen Okanagan Organic Producers Association (SOOPA).
			SOOPA was formed to develop a certification process and draft standards for our local organic farm community and to give some definition to a way of farming.
			Certification had developed in the United States with the formation of the organization called the California Certified Organic Farmers (CCOF), which was founded in 1975. The Organic Crop Improvement Association (OCIA) was founded at about the same time and they were followed by the formation of many other certification organizations. These organizations were in the process of defining the term &ldquo;organic&rdquo; by drafting standards that would guarantee quality assurance to their customers.
			SOOPA encouraged, and still encourages, a high level of participation from its members
			alt="grapes on the vine, ready for picking"
			width="380" height="285"
			...and the task of drafting comprehensive grower guidelines was undertaken. As a result of these guidelines its membership grew. Originally SOOPA had a 5-year transition period, a very limited material list of allowed substances and a rigid whole farm policy. The system of third party verification was developed within the industry, which led to the formation of the &ldquo;Independent Organic Inspector Association&rdquo;, the organization that oversees and trains our verification officers. Over time some of the policies that were drafted when the group first formed have been changed. These changes reflect an attempt to bring all standards for organic production into worldwide unity. In 1995 SOOPA changed from a 5-year transition period to a 3-year transition period. SOOPA was the first certifying organization in British Columbia. SOOPA has farmers in its program producing everything from fruit and grapes, to ground crops, livestock, greenhouse crops and processed products. SOOPA and other BC certification groups created the Organic Alliance, the provincial association of organic groups functioning up to 1993. The Certified Organic Associations of British Columbia (COABC) was founded in 1993 by the provincial government with the help of SOOPA and other BC certification groups using the Food Choice and Disclosure Act. SOOPA has served as a model and inspired other organizations in the area. Today the Similkameen Valley has the highest concentration of organic growers per capita in Canada and it is growing every year.
		<h2>Sterile Insect Release Program</h2>
			The history of organic farming in the Similkameen Valley is uniquely joined to the fate of the codling moth in this farming area. Codling moth cydia pomenella is the worm in the apple. An uncontrolled population will explode and render an apple crop unmarketable in two years. Agriculture Canada scientists used the Similkameen Valley to develop a non-chemical control method for the codling moth in the 1970&rsquo;s. By releasing large numbers of sterile males into the wild population they were able to virtually eradicate the insect. In the absence of the persistent presence of the highly toxic chemicals normally used for codling moth control the populations of beneficial parasites and predators were able to grow and do their job of managing secondary pest populations. S.I.R. has proven to be very successful and is an ongoing program.
		<h3>Then and Now</h3>
				In 1999 SOOPA adopted the COABC standards.
				In 2001, at the SOOPA AGM, a resolution was passed to redefine SOOPA&rsquo;s Whole Farm Organic Policy.
		<a href="http://www.certifiedorganic.bc.ca/">
			COABC- Certified Organic Associations of BC
		<h2>The definition of the Whole Farm Organic is:</h2>
				An organic farmer or processor must be committed to managing his/her land, growing or producing a crop or product without the use of harmful, toxic chemicals or substances.
				A &ldquo;farm&rdquo; means any land used to produce any agricultural commodity.
				&ldquo;Commodity&rdquo; means any article of trade. Commodities include but are not limited to: produce, farm products, livestock, medicinal and cosmetic materials.
				No non-organic agricultural commodities can be grown on a farm.
			WHOLE FARM ORGANIC reflects traditional farming methods, as it does not accept the use of toxic chemicals, synthetic fertilizers and genetically modified crops. In an attempt to approach the ideal model, Whole Farm Organic attempts to coexist with and respect all of nature.
		<h2>Whole Farm Organic uses:</h2>
				Few off-farm inputs
				Crop/animal diversity
				Crop rotations
				Green manures and fallow cycles for fertility
				Spreading of crop residues or animal manures
				Mulching and sheet composting
				Acceptance of some crop loss due to insect cycles and other natural occurrences
				Companion planting to enhance growth and combat insect infestation
				There is an emphasis on mechanical and hand labour.
			In 2002, a new certification body in BC, PACS , was created primarily for expediting international trade of BC organic products. Several larger SOOPA growers and handlers became members of PACS and SOOPA&rsquo;s membership was reduced. At the 2002 AGM, a vote was held and it was decided to maintain SOOPA as a certifying body. SOOPA retained its fundamental role of certifying organic farms and continues to serve its members in this capacity.
			As members of SOOPA, we pride ourselves on the integrity of our organic methods of farming and the quality of our products. Organic agriculture provides people with healthy, wholesome food. It is also an attempt to create a healthier environment for all living organisms. Hopefully, some day, many more people will realize the importance of healthy soils and clean air and water.
			<strong>Happy Organic Farming and Eating</strong>
	<!-- #content --></div>
	<hr />
	<div id="footer">
		&copy; 2012 SOOPA<br />
		BOX 577, KEREMEOS BC V0X 1N0<br />
	<!-- #footer --></div>
<!-- #pageWrapper --></div>


I switched to ID’s instead of classes on the ‘big containers’ so that if you want to index using hash, you can. I’d consider perhaps tossing verbose ID’s on the various subsections for that reason, but that’s up to you.

Gimme a few minutes and I’ll belt out the CSS I’d be using with that.

Here’s what I came up with:

as with all my examples the directory:

… is wide open for easy access – and stuffed behind a robots.txt telling search engines not to steal your mojo. Valid XHTML 1.0 Strict, would be valid CSS 2.1 if not for a few IE workarounds.

Gimme a few more minutes and I’ll type up a section by section breakdown of the code for you to follow along with the how/why/what/where of my choices, and comparing it to your original.

Ok, let’s talk markup.

First big change in mine is switching to STRICT. That’s what you should be using as the stricture structural rules make it easier to debug, and it means a whole slew of tags and attributes you shouldn’t be using for being presentational, redundant or even bad for accessibility.

You’ll notice I redid the ENITRE markup before I even THOUGHT about layout/style. Desktop resolution screen is not the only thing one should be designing for, so using semantic markup of the content first means that CSS off or images off or scripting off or whatever – doesn’t matter, the user will get usable content.

I added proper language encodings, did a proper LINK to the screen stylesheet with a ‘proper’ media target. Screen covers the majority of desktop resolution devices, projection covers a handful of similar capability devices like Opera operating in full screen or several different Internet kiosks. TV is for the old webtv folks, and every now and then the Wii browser (based on Opera) seems to want to use that.

This also means that print and handheld users will NOT get this styling – and that’s actually a good thing as why waste the users ink or send widths and paddings that won’t look good on handheld? A more robust version of the page would have specific stylesheets for those, as well as the new CSS3 media queries to target smaller displays.

I use a single outer #pageWrapper as opposed to your .container which you only had on the inner elements. Since it’s all getting the same width that means it only needs one container.

The h1 is all one heading - you aren’t starting a main section and subsection with a title and tagline… The span with the hyphen inside it is there for non-CSS users. View the page with CSS disabled, and you get a simple, reasonably attractive and easy to follow layout. That’s actually the point of semantic markup and it means as a rule of thumb, screen readers will love it too.

There is literally no reason to have a div.header around the h1 or menu – it’s why I think HTML 5’s elements like NAV and HEADER are pointless trash.

You’ll see two horizontal rules in the markup. I use HR to indicate a change in topic that doesn’t warrant a header. The first one is mostly there just to separate the ‘header type’ stuff of the h1 and menu from the content. The second one between content and footer is the more important of the two, as it’s basically saying that the text in #footer is not part of the h2 “Whole Farm Organic uses”. That’s what headings do, declare the start of subsections; HR semantically means a change in topic without a heading.

div#content is relatively unchanged, though the use of an ID instead of a class means if you wanted to add a accesskeys or skipto menu you could easily point at template.html#content to skip the menu and h1.

Because we no longer have the non-semantic use of a H2 in the way, we promote all the content elements to H2 instead of H3… likewise we turn all your paragraphs into… paragraphs… getting rid of the double breaks and using block-level containers means when it comes time to style we’ll have predictable/controllable block-level containers instead of having to play guessing games with line-height.

The images on the page get one of three ‘plate’ type classes. (though we only actually use two of them). A ‘plate’ is the old print term for them, and the three types tend to work well for most site designs… simply “plate” being centered without text wrapping it. a “leadingPlate” being displayed before the text (float:left) and a “trailingPlate” being after (float:right)… all of them assigning all the margins and other formatting we want without having to say it explicitly in the markup each time.

I swtiched some of your content to unordered lists becuase, well… they looked like bullet point list items to me. I also used one H3 because the wording of the content there felt either like an incomplete sentence, or the start of a subsection – I assumed the latter.

Oh, you’ll also notice I converted all your oddball characters to entities… it now fits into the bottom 7 bits (128 characters) of the original ASCII character set, meaning it’s valid in just about every major character encoding; for English language websites this is usually the best approach… fancy encodings should be reserved for non-English language pages.

Finally the footer I just re-arranged a bit for aesthetics. In your original there wasn’t really anything wrong there.

Oh, you’ll notice I put </head><body> and </body></html> on the same lines. These are static elements common to every page so there’s no reason to separate them – and having nothing between them serves as a reminder that NOTHING should EVER go between them. YMMV, but I find the occasional reminder of things like that keeps me out of trouble.

That’s the markup… I’ll start documenting the CSS which is where the really big changes took place.

On to the CSS.

I start all my CSS files with a simple reset. You can’t trust margins, paddings or even the borders on a few elements; there are bigger resets, but those tend to cause more problems than they solve and start to border on being frameworks; and in CSS frameworks tend to be rubbish. There are smaller ones like the ‘universal reset’ of * { margin:0; padding:0} but that can make styling form elements painful. At less than a quarter K I’ve never wanted less, and I’ve never needed more.

I also strip out those horizontal rules. They are there for semantic and CSS off, not for our screen.css users.

body - the text align means this layout will even work in IE 5.5; it’s a handful of characters to support it, so let’s support it! The font declaration uses the condensed property for clarity and reduced file size – I always set the size I’m going to use on my content FIRST, then size based off of that.

#pageWrapper - You’ll notice I switched this to a semi-fluid layout. The px min-width prevents it from getting so small the layout breaks, the em max-width means people using large fonts/120dpi or higher (like win7/8’s “large” that’s 144dpi) will get a larger maximum width to fit the larger text. The 95% means at the in-between sizes we get a bit of your background showing to make it pretty… the margin:0 auto; centers it in modern browsers, and from there it’s simply a matter of background color and the side borders.

* html #pageWrapper - unfortunately IE6 and lower don’t know what min-width and max-width are… we could fake it with an ‘expression’ but with those browsers on the decline I no longer bother, and simply give them the narrow fixed width. While I continue to support those browsers in a ‘usable’ manner, I no longer waste time making things 100% perfect for them. It’s what graceful degradation is about – older user-agents still supported, they just don’t get all the bells and whistles.

h1 – I hate using PX fonts, but with the image interaction and being we’re talking 24px or larger, it’s FINE. Nobody is going to kvetch about 24px, much less 40px being “too small”. The 25px top and bottom padding plus the 44px line-height plus the 28px ‘small’ line-height comes out to the 122px of your original.

Again, notice the line-heights are TALLER than the font… as it should be. That’s probably one of the things that was biting you on yours – you were declaring a 22px line-height on a 40px font.

The background image I also remastered to fade to that background blue - that way centered it looks good at any total width.

h1 span – the hyphen for CSS off… we don’t want it showing for screen.

h1 small – display:block makes it shrink to the 28px line-height. Without that it would expand to the 44px of it’s parent… also shoves it on it’s own line as desired.

#mainMenu – strip the bullets, give it a background color, pad it to be pretty, and add the top/bottom border.

#mainMenu li – setting these to display:inline puts the anchors all on one line.

#mainMenu a – inline-block lets us set top/bottom paddings; I use paddings on both the A and the UL so that should you want to use backgrounds on the hover states they’ll be pretty. I also brightened the color since what you had was below accessibility minimums.

#mainMenu a:active,
#mainMenu a:focus,
#mainMenu a:hover
– hover and keyboard navigation states… color… oooh.

Content – since we already have the background color on #pageWrapper, all we want here is some padding… 2em is about what you had, and will get larger for larger font users. The top/bottom padding, well… more on that in a moment.

Content h2 – just some sizes and padding, nothing fancy.

Content h3 – ditto, ditto.

Content p,
Content ul,
Content li
– I use padding on the bottom of these to space them apart instead of margins… for good reason: margin collapse.

Margin collapse in layouts can get very unpredictable at times, so I just try to avoid it by using padding wherever possible. The reason I made the top and bottom paddings so short on Content was that the top padding I put on the h2 and the bottom padding from the P and UL combines with the top/bottom padding of the outer wrapper to total 2em, same as the sides which is why it looks evenly spaced.

Avoiding margins unless you really need them can REALLY make life simpler… though it does take a wee bit more planning/thinking to pull it off.

Likewise you’ll notice I don’t declare a lot of widths or heights and instead let flow with paddings, line-height and border ‘do it’s work’. Width AND heights declared fixed the same time as border or padding is also just asking for headaches, particularly in older browsers; especially in IE5 or IE6 when in quirks – the latter is not a concern here – but it can also just make you have to ‘think more’ in modern browsers to remember how it all adds up. It’s why I try to only use one or two width declarations on the whole page – typically the outer wrapper and then on any sub-columns. (leaving the main content column fluid).

#footer – simple padding, colors, borders… nothing to write home about.

– the three of these are as discussed in the markup breakdown. Centered, floated to each side, and appropriate borders. Lot simpler to just slap the class on them as needed instead of constantly saying vspace and style= on each of them – and you can quickly change their margins and behaviors when it comes time for other stylesheets…

… a MEDIA query for narrow width for example might force a max-width on them, then display them all as per .plate due to space constraints.

… and that’s all there is to it. Really after rewriting it I’m convinced a lot of your issues were the oddball line-heights and use of margins on things that really should have had their parents padded as well. I know I took a few liberties with the content and design, but hopefully you can see the reasoning behind said changes.

Hope this all helps – I know it’s a lot to take in all at once, so any questions fire away.