Add border, all is good, no border, everything breaks

[rctneil]

Hey,

Working a small site for a friend, the progress is shown at Wilcox Construction.

For some reason the site looks just as i want it to if I add a 1 pixel border to the #container div.

As soon as I set the border to 0 pixels as I want to do then the sidebar, and nav div jump down.

Any ideas as to why this is occurring?

Thanks

Neil

[CyberAlien]

Its because of margin for #container. I suggest to change it to padding.

Here is explanation of why this happens: http://www.w3.org/TR/CSS21/box.html#collapsing-margins

[noonnope]

Why the absolute positioning?

Collapsing margins are to blame.

[Paul O'B]

As cyberAlien correctly said its due to collapsing margins and adding a 1px top padding should cure the problem.

#container {
  border: 0 solid red;
  margin: 0 auto;
  min-height: 400px;
  padding: 1px 0 0;
  position: relative;
  width: 975px;
}

You might find this entry in the Sitepoint Reference an easier read than the specs (especially as I wrote it myself .

Collapsing margins are quite awkward to understand at first and have consequence far deeper than the margins between elements but also the margin between nested elements which collapse onto the parent and become the parent margin instead when there is no content in the way (such as borders padding or physical content).

[rctneil]

ok, so it's a collapsing margins issue. Can you just explain what margins are being collapsed and why adding a border solves it?

[Paul O'B]

Hi,

There is a graphical explanation in the link I mentioned above which will clearly show the effect and makes it easier to visualise what's going on

In your page you have this element.

#content {
  background: none repeat scroll 0 0 #FFFFFF;
  border: 0 solid red;
  margin: 180px 0 0 245px;
  padding: 0 1em 1em 0;
}

Now there is nothing above that element except for #sidebar and #nav which are absolutely placed and removed form the flow so can be ignored.

This effectively leaves us with a structure like this.

<div id="container">
    <div id="content">
        <p><strong>Wilcox Construction Services Ltd</strong> is an innovative business offering a professional design and project management service supported by a construction team that delivers high quality through a skilled directly employed workforce</p>

#content has a margin top of 180px which collapses onto #container and becomes a top margin for #container instead and thus moves #container down the page by 180px.

The rules for collapsing margins are that if there is no content between the top edge of the parent and the top edge of the child then the child's margin collapses onto the parent and becomes the parents margin instead.

If the parent has a border, or padding or some text content then the margin would not collapse. It's only when there is nothing between them that it collapses. (The same would hold true for bottom margins but side margins don't collapse.)

These rules hold true for most elements but there are exceptions and elements that create a new block formatting context have different rules and do not collapse (which is why nested floats do not collapse or elements with overflow other than visible).

(Collapsing margins aren't the most intuitive of CSS rules but there is a need for them in some situations although perhaps it would have been better if the default was not to collapse.)

[rctneil]

Excellent. Received and Understood.

Neil

[deathshadow60]

Might I also suggest using a real doctype instead of the HTML5 lip-service one so you can actually validate your code with something meaningful, expanding the charset meta into the full meaningful version, taking an axe to the author and copyright meta's that NOTHING actually even tries to use, adding media types to your CSS embeds, naming your CSS something meaningful (like say the media type) instead of the vague/meaningless "style", swinging an axe at even TRYING to use fat bloated scripting libraries like jquery, and losing the "emtpy comments for nothing" trick on that menu, endless DIV for nothing, putting something resembling a HEADER tag in there, and flipping your comments around to before the tag being closed as that can trip rendering bugs in both IE and FF. (Yes, comments can trip bugs)

So change all these:
</div><!--content-->

To this
<!-- #content --></div>

To avoid that headache later on.

On the CSS side you seem to be using a particularly fat and heavy reset for nothing -- I'd highly suggest cutting that down; especially the HTML 5 nonsense since unless one is playing with it to see what we MIGHT be able to deploy SOMEDAY, nobody has any business trying to use it on production websites. (That and it's such a train wreck of a specification you're better off with XHTML 1.0 STRICT or HTML 4 STRICT)

First thing I'd suggest is cleaning up the markup into something real-world deployable instead of the HTML 5 fantasy-land nonsense... then as noonope mentioned, swing an axe at the APO since if you're going to make columns, that should be done with FLOATS. APO for columns == /FAIL/ 99.999% of the time.

Though I'm NOT wild about the positioning of the h1 inside the sidebar code-wise, or the side-bar stuff before the actual content. Given it's a fixed-width layout, there's little reason it couldn't simply have been done in the 'normal' source order for a page, regardless of the final appearance...

and on the subject of appearance, px fonts declaration on BODY? Bad/nonexistent accessibility.

My markup for that same page would probably look something like this:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html
	xmlns="http://www.w3.org/1999/xhtml"
	lang="en"
	xml:lang="en"
><head>

<meta
	http-equiv="Content-Type"
	content="text/html; charset=utf-8"
/>

<meta
	http-equiv="Content-Language"
	content="en"
/>

<link
	type="text/css"
	rel="stylesheet"
	href="screen.css"
	media="screen,projection,tv"
/>

<link
	rel="shortcut icon"
	href="http://www.sitepoint.com/forums/images/favicon.png"
/>

<link
	rel="apple-touch-icon"
	href="http://www.sitepoint.com/forums/images/apple-touch-icon.png"
/>

<title>
	Wilcox Construction
</title>
		
		
</head><body>

<div id="pageWrapper">
	
	<h1>
		Wilcox<br />
		<small><span>Construction</span> Services LTD</small>
		<b><!-- image replacement --></b>
	</h1>
	
	<ul id="mainMenu">
		<li class="home"><a href="index.php">Home</a></li>
	 	<li class="whoWeAre"><a href="about.php">Who we are</a></li>
	 	<li class="sectors"><a href="trips.php">Sectors</a></li>
	 	<li class="services"><a href="contact.php">Services</a></li>
	 	<li class="contactUs"><a href="trips.php">Contact us</a></li>
	</ul>
	
	<div id="content">
		<p>
			<strong>Wilcox Construction Services Ltd</strong> is an innovative business offering a professional design and project management service supported by a construction team that delivers high quality through a skilled directly employed workforce
		</p><p>
			We firmly believe that any building environment with appropriate treatment and development can be conditioned to support the delivery of quality Educational practice. Our role is to work closely with you the client to provide and manage development schemes of work that can physically transform your classroom environments, at a cost that is affordable and to a standard that is Academically inspiring.
		</p><p>
			We fully realize that the process of building redevelopment and change through the pathway of Local Government can be fraught with difficulty, inertia and frustration. What makes us different is that we apply a private sector ethos to public sector problems. Our project managers work closely with you the school directly, to place you at the very heart of the decision process. Our inclusive working relationship delivers buildings and solutions that are more effective, appropriate and economic than any that can be provided by traditional approaches to school redevelopment.
		</p><p>
			From classroom alterations to the design of bespoke offsite educational provision units, our teams are able to draw upon a wide spectrum of industry expertise and experience, to give you the client the confidence to move forward towards the environments your students and staff deserve.
		</p><p>
			Lorem ipsum dolor sit amet, consectetur adipiscing elit. Fusce erat tortor, commodo nec molestie et, tincidunt ut urna. Mauris id ornare ante. In ultrices suscipit nisi ut condimentum. Maecenas eros velit, commodo quis pharetra sed, rhoncus in metus. Morbi auctor bibendum elit, vel tincidunt dui semper a. Ut malesuada nisl quis odio dapibus hendrerit. Integer fermentum, augue sit amet ultricies hendrerit, dui ipsum feugiat velit, et tincidunt dui sapien in arcu. Phasellus eget nisi elit. Proin in sagittis sem. Quisque pellentesque elementum interdum.
		</p>
	<!-- #content --></div>
	
	<div id="sideBar">
		<img
			src="http://www.sitepoint.com/forums/images/picture1.jpg"
			alt="Project Plan Image"
			class="plate"
		/>
		<ul>
			<li>List of</li>
			<li>things goes</li>
			<li>here.</li>
		</ul>
		<img
			src="http://www.sitepoint.com/forums/images/picture2.jpg"
			alt="House Image"
			class="plate"
		/>
	<!-- #sideBar --></div>
	
<!-- #pageWrapper --></div>
	
<div id="footer">
	&copy; 2011 Wilcox Construction |
	Website design by <a href="mailto:rctneil@aol.com">Neil Tonge</a>
<!-- #footer --></div>
		
</body></html>

Gimme a few minutes to get dinner down my gullet, and I'll slap out the CSS I'd be using with that.

[deathshadow60]

... and here's how I'd be approaching that same layout:
Wilcox Construction

As with all my examples the directory:
Index of /for_others/rctneil

is wide open for easy access to the gooey bits and pieces -- like a new cleaned up logo image, images for the menus instead of the CSS3, and the faux-column image I applied since it looks like you were trying to use min-height to do that... Also why the footer was riding up when it shouldn't have -- APO for a column just doesn't work reliably -- it's like fixing the height of a content container; it's just going to break!

Which despite the extra images it STILL shaves about 6k off the total sizes of images... even more surprising once I added hover states to the menu image I created for it.

Built entirely with floats and putting the content in a more sensible order. Valid XHTML 1.0 Strict, Valid CSS 2.1, tested working IE 5.5, 6, 7, 8 and 9, FF 3.5 and 4.0, and the latest flavors each of Opera, Safari and Chrome... (though the sidebar images aren't centered in 5.5 -- oh noes, not that!)

Hope this helps.

[rctneil]

I really really appreciate your help here. I am going through your posts bit by bit.

Let's start at the top:

Might I also suggest using a real doctype instead of the HTML5 lip-service one so you can actually validate your code with something

meaningful,

What's wrong with using the HTML5 doctype.

http://stackoverflow.com/questions/5629/any-reason-not-to-start-using-the-html-5-doctype

expanding the charset meta into the full meaningful version,

If i'm using the HTML5 doctype then I might as well use it for the character set

taking an axe to the author and copyright meta's that NOTHING actually even tries to use

Agree and done in latest development version on local system

adding media types to your CSS embeds,

once again, done

naming your CSS something meaningful (like say the media type) instead of the vague/meaningless "style",

done again!

swinging an axe at even TRYING to use fat bloated scripting libraries like jquery,

I think we'll just have to agree to disagree here. I will be using jquery later in this site so that's that.

and losing the "emtpy comments for nothing" trick on that menu

This was carried over from another site where the links in the nav were horizontal and positioned inline-block and those comments fixed a slight

white space

, endless DIV for nothing,

Not sure what div you are referring to here?

putting something resembling a HEADER tag in there,

I thought <header> was an html5 tag? I have a <head> tag

and flipping your comments around to before the tag being closed as that can trip rendering bugs in both IE and FF. (Yes, comments can trip

bugs)

ok, i'll take your word on this. So once again done.

... and here's how I'd be approaching that same layout:
Wilcox Construction

As with all my examples the directory:

Index of /for_others/rctneil

is wide open for easy access to the gooey bits and pieces -- like a new cleaned up logo image,

The logo is temporary and was only print screened and cropped from a another design document so this will be redone.

images for the menus instead of the CSS3,

Now, this is the bit where I half agree and half disagree with yourself. I can see that your method with images and stuff is better backwards

compatible but my reasoning is that if no one starts to use the CSS3 stuff then how is it expected to come forard into the mainstream? The CSS

approach is also much much simpler. Is there not a way of adding in both methods and if a browser supports the method then they will be used?

What about Selectivizr?

and the faux-column image I applied since it looks like you were trying to use min-height to do that...

Pretty much same as above. In my dev version I got it working as I wanted to be honest

Also why the footer was riding up when it shouldn't have -- APO for a column just doesn't work reliably -- it's like fixing the height of a

content container; it's just going to break!

Hmmm, The absolutely positioned sidebar seemed to work fine on my local version, tested in severl browsers and it didn't break.

Which despite the extra images it STILL shaves about 6k off the total sizes of images... even more surprising once I added hover states to

the menu image I created for it.

once, again, images are not final

Built entirely with floats and putting the content in a more sensible order. Valid XHTML 1.0 Strict, Valid CSS 2.1, tested working IE 5.5,

6, 7, 8 and 9, FF 3.5 and 4.0, and the latest flavors each of Opera, Safari and Chrome... (though the sidebar images aren't centered in 5.5 -- oh

noes, not that!)

Hope this helps.

I do appreciate your advice and would like to hear your thoughts on the things I have presented above. None of the changes have been uploaded just

yet though.

Thanks

Neil

[deathshadow60]

What's wrong with using the HTML5 doctype. [URL="http://stackoverflow.com/questions/5629/any-reason-not-to-start-using-the-html-5-doctype"]

1) HTML 5 is still DRAFT, and DRAFT means "play with for debugging, not for deployment"

2) HTML 5 is a train wreck of a specification that seems to exist for the sole purpose of placating the people who never embraced/understood STRICT, and still just vomit up HTML 3.2 and slap a tranny doctype on it.

3) Because it's such a 'loose' specification, anything resembling "validation" is pointless -- making even the simplest of cross-browser and legacy support even MORE of a pain in the backside than it already is.

Just say no to HTML 5. The "gee ain't it neat" nonsense it brings doesn't offset the fact it's setting website coding practices BACK a decade!

NOT that the majority of developers have pulled their head out of 1997's backside anyways... I truly find it amazing the people who can't even be bothered to learn how to use a TH, LABEL or LEGEND are typically first in line to embrace HTML 5... when really it brings little if anything new that's actually USEFUL apart from maybe the form elements (and that's dubious) -- and it really seems to exist SOLELY to completely undo all the progress and intent of STRICT.

Let's just say... not a fan. I have NO plans to migrate to HTML 5 for the foreseeable future; and I suggest you do the same!

I think we'll just have to agree to disagree here. I will be using jquery later in this site so that's that.

My condolances on your loss -- seriously, jquery is such a bloated mess that just makes scripts bigger for NOTHING, more cryptic and as such HARDER to maintain -- why does ANYONE actually use that garbage?

Much less 90% of it is stupid animooted nonsense that just gets in the way of a pleasant user experience.

This was carried over from another site where the links in the nav were horizontal and positioned inline-block and those comments fixed a slight white space

Ah, copypasta -- why I generally avoid doing that in the first place.

Not sure what div you are referring to here?

In the original, div #logo, and both the div.sideBar_pic... it actually wasn't as bad as it initailly looked, but that's because the source order was kinda 'screwy' looking to me. (YMMV)... the "endless" part was more broken record syndrome -- I'm so used to seeing sites with double-digits of useless div and classes, it's become how I say it. "endless DIV for nothing" when in your case you really only had three.

I just hate "DIV for nothing" -- or "DIV's for what should be a semantic tag". The DIV around those images and the #logo DIV both qualified as such.

I thought <header> was an html5 tag? I have a <head> tag

header/heading, as in a numbered heading tag to say where sections begin, as well as what the content IS. Since all lower-order headings are by definition subsections of the h1, it's usually why I make the site title the h1 so it actually makes structural sense.

Basically I meant you should at LEAST have a H1 on the page... a heading tag.

Now, this is the bit where I half agree and half disagree with yourself. I can see that your method with images and stuff is better backwards compatible but my reasoning is that if no one starts to use the CSS3 stuff then how is it expected to come forard into the mainstream?

Has NO business being used on deployment sites while in DRAFT. Has no business being used on deployment websites when you have to use the -moz and -webkit prefixes for every useful value as those by definition mean "for testing only, not for production use".

Jumping the gun by deploying DRAFT code is what shtupped the entire industry with IE 5.0/5.5 legacy sites having to be supported on IE 6+ -- but of course nobody wants to learn from history and just make the same malfing mistakes over and over again. Be really funny when it's FF, Opera and Safari churning out "outdated browser support"... especially if whatWG has it's way and removes versioning from the spec. (idiots!)

The CSS approach is also much much simpler. Is there not a way of adding in both methods

Why write the same page TWICE?

What about Selectivizr?

Throwing an 18k javascript at it to avoid using a simple 5k image that works everywhere? To hell with that type of thinking... especially given what it does to the page load time on the legacy browsers given it's over the top DOM rewrites. Hell, the image is the same size as the stripped/compressed script... and as I've said a billion times, white-space stripping is usually just used to cover ineptitude.

It's part of what I've come to call "scripting for nothing" -- and it's why so many perfectly good websites end up flushed down the crapper by HUNDREDS of K of Javascript like the developer is getting paid by the K-LoC 70's style. ESPECIALLY annoying when it's "frameworks" like mootools or jquery taking what would be 4k standalone scripts and turning them into 16-20K BEFORE we even talk

Even MORE annoying when it's "flash over substance" crap that just gets in the way -- like slowly opening animations on dropdowns. (Maybe it's just me, but when I click on something I want it now, not later!)

Ajax for nothing and your scripts for free... that ain't working, and that's not how you do it. Lemme tell ya', those guys ARE dumb.

Hmmm, The absolutely positioned sidebar seemed to work fine on my local version, tested in severl browsers and it didn't break.

Footer is actually riding up OVER it in all browsers here (since the content is shorter), you would NEVER be able to clear it without fixing it's height (accessibility /FAIL/) and in IE6 the content wasn't even pushed over out of it's way.

APO has it's uses -- columns ain't one of them.

[spikeZ]

Neil, do you mind if I feature this on the front page?
Asking out of courtesy as it has your client site name on it.

[rctneil]

sure, if you wish to. Maybe I could see what other people's opinions are about this subject

[Black Max]

It took me a while to get my head around the concept of collapsing margins, and I still need to peek at the references now and again to keep it straight. Paul's link is an excellent reference.

[siteguru]

My 2¢ ... using Chrome 10.0.648.204 on Windows XP.

With Javascript disabled your test page (from first post) has the nav buttons 1/3 down the page and overlaying the text. Also the bullet list to the left has the bullets to the left of the background. When I enable Javascript it still looks the same.

Mr. Shadow's version of your site loads super-quick and everything is where it should be.

I appreciate you may have fixed some of the issues from that initial test page, but I thought I'd just give you feedback on what I can see as a site visitor.

[siteguru]

Just to add - looks exactly the same in Chrome10, FF4 and IE8 on Windows 7 Ultimate 64-bit. (I can't edit my previous post now to add this).

[rctneil]

My 2¢ ... using Chrome 10.0.648.204 on Windows XP.

With Javascript disabled your test page (from first post) has the nav buttons 1/3 down the page and overlaying the text. Also the bullet list to the left has the bullets to the left of the background. When I enable Javascript it still looks the same.

Mr. Shadow's version of your site loads super-quick and everything is where it should be.

I appreciate you may have fixed some of the issues from that initial test page, but I thought I'd just give you feedback on what I can see as a site visitor.

Thanks. I have not updated that test site since I originally posted.

I can fully understand what deathShadow60 is saying. I am just trying to fiure out the best way to go forward with my developments:

1.) Ignore latest technologies and stick with HTML4.01 and CSS2.1 and be stuck in the dark but reccommended ages.

2.) Use a mixture of old things with a splash of new techniques

3.) Go fully into HTML5 and CSS3.

I would prefer to try option 2.

My main reasons:

- A lot of the CSS3 features are working perfectly cross browser

- CSS3 functionality such as border-radius, pseudo selectors, opacity, shadows, gradients, things like that are extremely useful and quick to achieve. Doing a bit more work to fix older browsers is not a big deal. When css3 is recommended with browser vendor prefixes can be removed and the site won;t need a full recode.

- There are SO MANY people out there saying that a lot of this new stuff is usable online with a few of them needing a few workarounds,

- and the new stuff could be used to add extra functionality for the users who are using new browser versions. As long as the site content is visible in very old browsers then great. It gives them a reason to upgrade to get the latest and greatest experience. Why cater for really old browsers with diminishing usage share?

I KNOW deathshadow60 HATES extra packages like jquery and selectivzr but they are available to speed up the coding and development times (as far as i know anyway). Also, web speeds are increasing all the times so a few extra k shouldn;t harm anyone. Lots of people will have cached versions of the files anyway. Also about web speeds, I live out in the country so get slower speeds than most and I cope fine.

On the subject of jquery, As far as I know, it was made to solve cross browser bugs as a main feature and ahve been told that writing plain javascript and fixing individual browser bugs is a nightmare so I would have thought that a pre made library like jquery would be extremely useful. I've hardly done any javascript development so not 100% about this.

I really need to figure out what route I am taking in regards to development. Recently you (deathshadow) have posted long posts about 2 of my in progress sites about how they SHOULD be coded. I am in no way stating that you are wrong or incorrect or do not appreciate your advice or comments but both times, it has put me down and made me feel like I should just not be doing this at all. I know I shouldn;t feel like that as I know I am just being given advice but different people keep telling me different things from all different angles and It's extremely confusing deciding what to do.

Some people say stick to the old and reccommended stuff, some people say if a browser supports it then use it, some people say use anything, some people say support ALL browsers, some people say don;t bother, some people say this and others say that! This is what is confusing me.

See what I mean? - @deathShadow60, please don't don't attack me here. I am just trying to explain what I am going through with all of this.

Neil

[Stomme poes]

If the parent has a border, or padding or some text content then the margin would not collapse. It's only when there is nothing between them that it collapses. (The same would hold true for bottom margins but side margins don't collapse.)

Ok, sucks, Paul's not going to be around for a while, but when I read that I was wondering... if using :before and adding content (like a space) would "count".

It would have to be on #container, since :before basically creates a first-child of #container.

Not that it would be an actual solution (as IE6 and 7 don't know :before) but just curious. Guess I'll try it myself.

See what I mean? - @deathShadow60, please don't don't attack me here. I am just trying to explain what I am going through with all of this.

Don't worry, as gruff and grumpy as he sounds, he really only ever cares about code (even when he hates it)... trust me, his comments are never really directed at YOU. (You only know that after you've seen him on a forum for a while.) And like all of our loud-mouth critisisms, it's up to you to decide which of it you'll take on board and which you'll discard. What every developer does.

1.) Ignore latest technologies and stick with HTML4.01 and CSS2.1 and be stuck in the dark but reccommended ages.

While I'm not as fanatically against some of the newer stuff as Crusty (because I don't mind a degraded, not-so-pretty user experience for retarded/older browsers so long as the site still functions), he has a very good point.

I disagree about using the short doctype... it's true it works back to IE5 and Mozilla back when it had a dinosaur head for an icon, and what Crusty is talking about is the validator... BUT you can tell the validator to assume an HTML4.01 Strict doctype, and you SHOULD do this, for the reasons he mentioned: get real decent feedback from the validator.
The doctype only exists for two reasons anyway: tell the validators which rules you state you are playing by, and to keep browsers using their "standards mode" (only because they use "doctype switching" to decide which rendering mode to use).

I have no issue using <!doctype html>, but I would never validate with it, because I'm still writing HTML4.01 strict as far as the code goes. In fact I also tell it to test as XHTML1.0 Strict, since there it will complain about my quotes, uppercase (not that that's ever an issue), and missing </p> and </li> tags.

With CSS3, if your client/employer insists on having FF2 and IE6 look exactly the same as IE9 and FF4, then using half-working newer technologies and then a fat layer of scripting on top to do that is a slower, more bloated way to do it. I would take Crusty's old-fashioned image technique instead without further thought (option #1).

So when to use the CSS3 stuff (which by the way is NOT entirely draft, as you've noticed... modules instead of the whole spec get approved, not that I expect "candidate recommendation" to ever appear on any of them... not at least until I'm 40 or something)? Use it when you have simple code working for everyone, and then want to use the newer CSS properties to visually enhance the sites for the browsers who do understand... and I don't mind using the experimental prefix versions, since whenever someone releases a newer version that works with the default, it's one command in my text editor to remove the prefix. Also, prefixes allow you to NOT include any browser whose implementation isn't the same as the others, which is why prefixes are good. We don't have to hack to prevent a browser's crappy implementation from showing up, and ideally they'd only work with the default property (like border-radius) AFTER it actually works properly in their browser. So, your option #2.

I'd say option #1 is when you're required to have everyone the same, and are catering to absolutely "everyone".
Option #2 is when you have leeway to let older browsers get a degraded-but-functional experience, but still must cater to "everyone".

Option #3 seems to only be ok for fancy web designers who want to show off how on-top of the latest fad they are to other nerds who only surf with the latest technology (and aren't using NoScript, and aren't using a screen reader... which are still hiccupping on the latest HTML5 stuff). I know of a site based in Amsterdam which has gone entirely to HTML5 (with a ridiculous amount of scripting and hacks to get it all working in *some* IE's and older browsers) which, because their audience isn't necessarily only nerds, I would not have done. The pages are large and heavy.

See this page: http://www.nczonline.net/blog/2011/03/22/using-html5-semantic-elements-today/ and especially, read the comments.


One reason I have not written any "real" HTML5 page (with the newer tags I mean) is because IE requires Javascript simply to understand markup which is not something I can let pass. But that's me: every developer is different.

I KNOW deathshadow60 HATES extra packages like jquery and selectivzr but they are available to speed up the coding and development times (as far as i know anyway).

They speed up YOUR time but they add lots of code you aren't using to the BROWSER (which then might affect the user... depending on their browser and their internet access). Depending on what all you're loading, that's more bandwidth for users. Some users never notice, sitting on their fiber optic or T1 connection. Some people have crappy bandwidth and have to pay for it. Which group are you serving? If your site is meant "for everyone" then you're serving the second group too.

When I was asked to make a sliding photo thingie, I had to use jQuery, because my Javascript was not good enough to write that myself and have it work cross browser. But the amount of code I had to have the browser load: first the basic jQuery library, THEN the separate (and huge) UI widget thingie, THEN the scrolly script... which of course also was poorly written: did not work when scripts were off, was not keyboard-accessible, and I ended up still spending a bunch of time fixing those things. Which also added more Javascript (my fix-the-bad-jQuery script).

If you're running a whole crapload of scripts who all use jQuery, it starts getting more justified. You need to start with something as a library simply to get eventloaders working cross browser and "this" working in IE-- but if you're loading a whole library for something small and stupid, esp if it's just one or two things, hand-written Javascript (even with your own library behind it) will be smaller and faster, because jQuery is written to handle all sorts of stuff. And the browser downloads all of it and the parser parses all of it. People aren't always sitting behind a desktop power machine with the latest browsers, fastest drivers and a fat pipe. You also get people on mobiles sitting in a busy wi-fi cafe who's turned off images and scripts just so it doesn't take 3 hours to load a web page. And if you're serving any of the physically large countries (United States, Canada, Russia, China, Australia...) then you've got people on dial-up. 56K modems. That sucks, but they won't get better service until it becomes profitable for the providers to do last-mile installations.

Anyway, whether you stick with using jQuery all the time or not, it's worth your while to get good at vanilla Javascript anyway: this lets you debug jQuery easier, fix its bugs easier, and have a better idea when you could write something much smaller and faster instead. Most of the Javascript guys, including John Resig, encourage developers to learn vanilla Javascript anyway.

I really need to figure out what route I am taking in regards to development. Recently you (deathshadow) have posted long posts about 2 of my in progress sites about how they SHOULD be coded. I am in no way stating that you are wrong or incorrect or do not appreciate your advice or comments but both times, it has put me down and made me feel like I should just not be doing this at all. I know I shouldn;t feel like that as I know I am just being given advice but different people keep telling me different things from all different angles and It's extremely confusing deciding what to do.

It's both good and bad to get conflicting advice. It's bad if you're a n00b because you don't know who's right (for many things, there isn't one right anyway). It's good if you're learning though because you get all the other viewpoints.

Some people say stick to the old and reccommended stuff, some people say if a browser supports it then use it, some people say use anything, some people say support ALL browsers, some people say don;t bother, some people say this and others say that! This is what is confusing me.

Because once people have gotten over their n00b hump, they decide "I'm going to code like THIS for THESE browsers". Then they give you advice based on their decisions. A good dev is constantly re-evaluating their techniques and what they're coding for. In your case, it'll probably be best decided by "who are you coding for?" (meaning, visitors).

Generally when Crusty does a rewrite, it's pretty good and other experienced developers would consider it a good rewrite. But you don't have to use it. When I was a n00b, I learned a LOT from watching him (and others) rewrite other people's code, esp when there was commentary explaining Why this and Why that. Did I do everything that way? No. I take his rewrites as learning tools.

And if it makes you feel better, he rewrites good code other experienced devs have written too, maybe mostly because he disagrees with their coding style or particular techniques they've used. Meh. The more you code, they more you decide what you'll do and what you won't. Crusty supports IE5. Most developers don't. Some developers like optimisers and whitespace scrubbers. Some don't.

Anyway, this is a forum, not a boss. Learn what you can from it, and ultimately you'll decide what you take away from it. Don't feel like it must all be over your head and you must suck so should quit. The people who suck and should quit are the ones who continue writing garbage and are unwilling to learn from others. You came here with a question, and you didn't just want to know how to fix one particular bug, but you were willing to go into discussion about your code in general. That's good. That means you have in you what you need to be a good developer.

[cranial-bore]

Analysis paralysis (i.e. doing nothing) will be worse than doing this project 'wrong'. DeathShadow cares a lot about the quality of web development, and that's fair enough. Do keep in mind that if you do something 'wrong', like using CSS3 instead of background images that no one will die, your building will not collapse, and your dog won't get cancer. You seem to have a pretty good grip on things, so the worst case scenario is pretty mild. Just keep building and learning.

[rctneil]

Thanks guys, Those posts definitely help. As I mentioned in my long post above, I fully understand what deathShadow is saying and I thank him for hi explanations. I guess i'll just keep going along and trying different things. I ahve taken onboard certain comments such as adding media types to css links and things like that. I also think i will continue to use the HTML5 doctype but validate as 4.01.

Once again, thankyou for other opinions and i'll just keep on building and changing. Also i'll look into Vanilla Javascript. I think the main thing putting me off is the fact that when i do learn it, I'll be learning it, and knowing that there are easier solutions that what I am writing at the time. but i'll give it a go. I'll give Kevins, Javascript Live another go I think.

Neil

[siteguru]

If you're looking to avoid jQuery but have reservations about addressing cross-browser compatibility, you might find Mike Foster's X Library worth a look.

[deathshadow60]

- A lot of the CSS3 features are working perfectly cross browser

Depends on what you mean by cross-browser... when they don't work in 46% of users machines (IE8-), that's not cross-browser... and we're not saying IE9 adoption is slow, but I've got people already asking me how to go back to IE8. (and no, they don't want to try an alternative and get hostile when you suggest it -- #DDD users. If you are a Dee, please don't marry a Dee, it's genetics don't you see, the kids will be Dee Dee Dee)

- CSS3 functionality such as border-radius, pseudo selectors, opacity, shadows, gradients, things like that are extremely useful and quick to achieve. Doing a bit more work to fix older browsers is not a big deal. When css3 is recommended with browser vendor prefixes can be removed and the site won;t need a full recode.

Or you end up having to leave them in indefinately depending on the upgrade rate. See FF4 being out for over a month and still only a fraction of the userbase has moved over -- hell I'm staying with 3.5 as my primary FF install here because none of the tools I use it for (like the web dev toolbar) work properly in 3.6+

THOUGH, I'm more open to CSS3 than I am HTML 5. To me the latter is 90% pointless garbage and 10% stuff that has nothing to do with or should have nothing to do with the actual markup -- all the USEFUL bits (Excepting maybe one or two form elements) are Javascript, NOT HTML. One of my 'issues' with HTML5 -- all the NON markup crap thrown under it's umbrella.

I'll even use a few CSS3 properties -- but when I do it's generally just the ones that already existed in IE for over a decade... like word-wrap:break-word; or using Filters. Even then I do so sparingly as I cringe every time I 'have to' use something that's not part of at least 2.1.

Though it's funny how people focus on the stuff I consider silly like border-radius... I'm actually looking forward a whole lot more to border-image.

- There are SO MANY people out there saying that a lot of this new stuff is usable online with a few of them needing a few workarounds,

... and there are so many people still vomiting up HTML 3.2 and slapping a HTML 4 tranny or HTML 5 doctype on it -- doesn't mean it's good practice. I SHUDDER to think of the train wreck Wordpress would turn into as HTML 5 given it's already bloated/pointless markup.

and the new stuff could be used to add extra functionality for the users who are using new browser versions. As long as the site content is visible in very old browsers then great. It gives them a reason to upgrade to get the latest and greatest experience. Why cater for really old browsers with diminishing usage share?

When it's little to no extra effort, why not? Why alienate ANY potential visitors especially when many people "stuck" on legacy browsers like IE6 are FORCED to by their workplace (due to legacy crapplets), OS, or even bandwidth. Someone in the Dakota's or Coos county NH where 33.6 dialup is a good day isn't all that interested in downloading a multi-megabyte browser update.

I KNOW deathshadow60 HATES extra packages like jquery and selectivzr but they are available to speed up the coding and development times (as far as i know anyway).

seletivzr is just pointless bloat -- by the time you incorporate it you could have just written the page without the stuff it implements...

jquery, mootools and pals are far more insidious as yes, that's what the people using it CLAIM these libraries do -- speed up development time; but really the opposite is true as it makes the code needlessly cryptic, and what it does falls into two categories; useless animooted garbage that just interferes with the user actually USING the page (aka stuff I wouldn't put on a website in the first place) or bloated slow library functions that generally result in little to no graceful degradation, and LARGER scripts than the same code would be without the stupid library.

As I mentioned, it reminds me of the old days where Cobol and Fortran coders would rely on giant libraries whether the code in said libraries were even being called or not, filling up their pages with comments and long names on everything JUST because they were being paid by the K-Loc. (Thousand Lines of Code).

This is particularly true when I see pages with one to ten k of plaintext as their only real content on MEGABYTE sized websites... and why I still maintain that 70k total for a page is the ideal, with 140k being the upper limit I'll generally allow.

Which throws using "libraries" right out the window since they can chew half my ideal size in one fell swoop.

Also, web speeds are increasing all the times so a few extra k shouldn;t harm anyone.

Tell that to the places here in the US where 33.6 is a good connection -- tell that to people on cell phone connections that are narrow band throttled and pay as you go; Tell that to the people of Canada where the red menace government has forced everyone into being metered...

Canada, the new red menace. Time for John Candy to lead an invasion of Toronto.

On the subject of jquery, As far as I know, it was made to solve cross browser bugs as a main feature and ahve been told that writing plain javascript and fixing individual browser bugs is a nightmare so I would have thought that a pre made library like jquery would be extremely useful. I've hardly done any javascript development so not 100% about this.

Another of the claims I've never found any real proof of -- maybe I've just been writing code for too long (over three decades now) but to me jquery just makes it HARDER to create and maintain code. But then, I'm a Wirth Tanguage type, so even AT&T (aka C dialect) languages like .js, php, etc are needlessly/pointlessly cryptic at times. Taking an already cryptic language and making it even MORE cryptic -- starts to sound like the bit from the "C and Unix are a hoax" joke, where:

We stopped when we got a clean compile on the following syntax:

for(;P("n"),R-;P("|"))for(e=3DC;e-;P("_"+(*u++/8)%2))P("| "+(*u/4)%2);

At one time, we joked about selling this to the Soviets to set their computer science progress back 20 or more years.

Which looks an AWFUL lot like jquery to me... and that's coming from someone who still writes x86 ASM and has even hand compiled his assembly to machine language.

It has put me down and made me feel like I should just not be doing this at all. I know I shouldn;t feel like that as I know I am just being given advice but different people keep telling me different things from all different angles and It's extremely confusing deciding what to do.

Don't feel put down by my or anyone else's comments - we all have to start somewhere and draw our own conclusions... my conclusions, mostly thanks to decades of programming pretty much every dialect there is, are often radically different from the mainstream.

Some people say stick to the old and reccommended stuff, some people say if a browser supports it then use it, some people say use anything, some people say support ALL browsers, some people say don;t bother, some people say this and others say that! This is what is confusing me.

Well, ask yourself what it is you want the page to do? Who do you want the page to reach? Ask yourself "is the technology I'm proving interfering with that?"

That last question is where a lot of the "gee ain't it neat" nonsense needs to get the axe -- but again YMMV.

@deathShadow60, please don't don't attack me here. I am just trying to explain what I am going through with all of this.

Don't ever take anything I say as an attack -- we may disagree and I've got some radically different conclusions from the "mainstream" -- But again, when the mainstream just vomits up code any old way...

You are going to come across a LOT of conflicting advice -- there's a WONDERFUL mix out there of web rot, people who've never embraced STRICT, people who throw javascript at EVERY problem whether it's the right tool or not, etc, etc...

The key is to take in ALL the advice, conflicting or not, and make your own decision.

... and keep in mind one of my favorite quotes:

If everyone is thinking the same, somebody isn't thinking" -- General George S. Patton Jr.

We may disagree -- oh well

[noonnope]

See FF4 being out for over a month and still only a fraction of the userbase has moved over -- hell I'm staying with 3.5 as my primary FF install here because none of the tools I use it for (like the web dev toolbar) work properly in 3.6+

If this add-on is the one you talk about:
https://addons.mozilla.org/en-US/fir...web-developer/
you should be fair to the ones making it. It works. In FF4 even.


I'm a FF user, converted from Ch. I've used FF4 since beta, and I'm saying is better then Opera. Opera it's like a child with many good ideas that doesn't quite manage to see them through till the end.



Using libraries like jQuery does help build a better interface, it's not about animation and just animation. jQuery is modular, you don't have to take the whole cow for the little milk you need.

Finally, it's less kilobytes than dotNet or Java and it's cacheable. If so many use it, let's be fair and say it has its uses. Denying the obvious doesn't make you cool, it makes you extremist.


HTML5 and/or Fred worth a shot. It may have hidden benefits, not just hidden flaws. A wider range of tags can also help you achieve a faster CSS, if you care to look at CSS from this point also. Or if you have to, like in you have no choice but to through away all those slow generic tags and descendant selectors.

Standing crooked but judging fair, those who have things to say against HTML5 and/or Fred are doing all us a favor by forcing the specs improve.


The web dev will evolve. Testing and embracing new stuff can help you get ahead, while keeping just one old way may cripple your abilities in the near future. Or vice versa. It never hurts to try new stuff though, that's for sure. And use it in real projects. After all, HTML is live now!

[deathshadow60]

It works. In FF4 even.

Uhm... Not quite!!! Most of it's functionality is broken in anything newer than 3.6, even if the menu part itself runs!

It RUNS, does NOT mean it works. The only thing I really ever used it for was the "view document size" -- which has what? five things broken on FF 3.6+? 90% of the stuff on the "issues" page works just fine in FF 3.5.

The code base for that has basically been "rotting away to uselessness" with every new FF release.

I'm a FF user, I've used FF4 since beta, and I'm saying is better then Opera. Opera it's like a child with many good ideas that doesn't quite manage to see them through till the end.

Funny, since IMHO FF doesn't do anything useful out of the box for me, there are things Opera does that I STILL can't find plugins/mods/extensions/userscripts/"whatever you want to call them this week" to implement... and once you start applying all those extensions you can kiss stability goodbye.

With FF4 seeming to be about as stable as FF2 -- and that's NOT a compliment. In testing I've already seen it go off to never-never land sucking 100% cpu on image saves; probably a code regression. It's like back to the days when I couldn't understand why ANYONE was using FF to begin with as I could crash it so hard that it would lock up an entire CPU core (great on single core systems) and have to be killed in less than 20 minutes.

Which apparently was related to the memory use/cache issue, which we were told wasn't a bug, but a feature. 256 megs of RAM in use with 100% cpu use locked indefinately was a "feature".

I wouldn't even HAVE that trash INSTALLED if it wasn't for browser testing. I can't imagine trying to use FF as my daily use browser with it having ZERO out of box functionality, no way to put the tabs to one side in portrait, no drag and drop favicons, no easy way to make custom buttons... It's a buggy/bloated/broken TOY of a browser.

[noonnope]

Off Topic:


Well, I hate to make this about FF, but let's have it.

Those issues in the link you gave, are not all FF4 related, as many of those issues are present in 3.5 also, so I see no reason for you not to upgrade. Those issues are about the programming part in web developer tools, not about how good or bad FF is.

Opera has the fastest JS engine... when it works. Opera has the Dragonfly... to look pretty. Nowadays, Opera is trying the Google-ways with the dev bar it has. Opera can't tell you don't bloody want the Speed dial or some other default tab to be opened as well when you open a page "Open with Opera" way.

And many more. Again, if Opera was so good, it would rise above its 2%. It's not a big conspiracy against it. I gave it a try. I tried all big5. I thought Ch was better than IE. In some ways it is. But FF is better. And Opera and Safari expect to be courted like little princesses when they should work like coal miners: hard and in the front lines.

You complain FF lets you use so many extensions it freezes. Well, I merely use 3 or 4. That's about as many as you can find for Opera.

Also i'll look into Vanilla Javascript. I think the main thing putting me off is the fact that when i do learn it, I'll be learning it, and knowing that there are easier solutions that what I am writing at the time. but i'll give it a go. I'll give Kevins, Javascript Live another go I think.

Neil

Yous should learn JS not for the reason of not using jQuery, but for the reason of customizing and improving your own version of jQuery. Programming is about productivity. Building from the ground up each and every time is not productive. Using libraries is the way to go.

If size matters, be smart. jQuery is modular, take what you need from it, if not all. Use it, it's cacheable, you won't spend more bandwidth on it than on a medium size image.

jQuery is a community effort and hard work. Respect that. jQuery's code can be contributed. Don't stand on the side lines complaining, contribute if you think you can make it better.