Web Design

[sayers6]

What you did I understand how to do, But I'm only talking about the various shades and box's, not the text. Like hoe they aren't the same exact color on all of them, but they get darker on some points, is that all done with regular CSS, or are img's involved?


EDIT: Let me change that to "I know how to get very similar results to what you did using my basic knowledge of CSS" XD
A lot of the various things like <span>, margin-left/right, and id's, I'm still trying to wrap my head around...but thanks to Scotty, I'm getting it a hell of a lot quicker than I would've. As always, thanks you guys :D

[igufed]

But I'm only talking about the various shades and box's, not the text. Like hoe they aren't the same exact color on all of them, but they get darker on some points, is that all done with regular CSS, or are img's involved?

Gradients are possible with only CSS, but, I find them to be a pain to accomplish how I want them exactly in all major browsers.  I just find it easier to make an image and use it as the background of the div or cell I want them in.

[sayers6]

Alright, so I'll just continue using a image made in paint for the background until Scotty comes in and tells me a different better way. Which he seems to do a lot, But I have found images so much easier so far.

[Scotty]

And I love how you said "a week's work of books", then linked to a 1098 page book. I'd hate to see your heavy reading.

It is rather intimidating, but once you get past the basics, you'll find that almost any of what I like to call "reference-type books" will go mostly unread until you need to know something.  This book is exhaustive in that regard, as it goes through a lot of content.  Don't read it just for the sake of reading it.  Go through the first couple of chapters to get the basics, then use the rest as it applies to whatever you need to do.

Anyways, I know there is a way to do some of this, and I'm nowhere near it, but how exact could you be about what a computer sees when one has Firefox 6.0, and a different one with IE6, and yet another with 7? Could you completely change what the webpage shows just off of a minor browser difference? I've seen huge differences with Firefox/IE/Chrome, but I just wonder if you could change it to where there is a difference between someone viewing with Firefox 6.0.1.01 and 6.0.1.02? Just wondering. And it is possible to have several versions of each browser without a lot of work? I'd like to see the subtle differences of each one.

This is by far going to be your biggest headache inducer of web development.  You won't notice a lot of differences between the minor releases, but the major releases will definitely show the differences you are looking for.  Although, that is not necessarily going to be the case with the last two Firefox releases as they are kinda getting ridiculous with their definition of "major" release.  To install multiple browsers, you can definitely do it with Firefox, I haven't tried Chrome, and Internet Explorer has a compatibility mode in their newer browsers that allow you to emulate an older version.  You can't install more than one version of Internet Explorer, which I think is good and bad.  Good for the end-user, bad for the developer.  It sort of deters the end user from going back to a browser that is a royal pain for developers to work with.

As far as how to code for different browsers, well that's part of the education.  There is no good cut and dry conditional coding for browser versions that is considered "best practice".  The best practice is to understand how the different browsers adapt to CSS and Javascript, and do what's necessary to accommodate as many as you can.  This is where stackoverflow.com is a Godsend, as you'll get an answer to whatever question about this kind of stuff in minutes, if the question hasn't already been asked.  A basic example of how some things just don't adapt across all browsers is the HTML5 <canvas> tag.  Internet Explorer 9 supports it, where previous versions didn't, and without doing third party add-ons, there's no way a developer can intervene to emulate one on older browsers.  In that case, they make it stupid simple to warn the user that they can't see the canvas, while still giving the developer enough control over how to present the fact that they are outdated so that it isn't too high-level or "generic".

Also, is it a good idea to have code "layered" (I think that's what it's called anyways) or does it really not matter? Where the code is moved to the right the more tags it has around it? My teacher never seems to do it, but videos I've seen always show it, so I try to do it.

If I understand that correctly, you're speaking of indentation.  Absolutely use indentation.  It isn't required in HTML, CSS, Javascript, or pretty much any other popular programming/scripting language that I'm aware of (with the exception of Python), but if you don't do it, navigating through divs is going to be a pain.  A simple example is to take Igu's code example, which looks like:

Code Select Expand

<BODY>
<div id="topdiv">
<p class="toptext">Just text at the top...</p>
</div>
<div id="undertop">
<p class="undertoptext">Different text.</p>
<p class="undertop-but-different">Something other than the text above.</p>
<div id="inside-undertop">
<p class="morestyles">This div should be inside the above div.</p>
<span class="forfun">FUN!</span>
<span class="span-to-the-right">Yea, <span class="omgfun">FUN!</span> no line breaks.</span>
</div>
<p class="undertoptext">This should use the same style as 'Different text.' above.</p>
</div>
</BODY>

and remove all the indentation:

Code Select Expand

<BODY>
<div id="topdiv">
<p class="toptext">Just text at the top...</p>
</div>
<div id="undertop">
<p class="undertoptext">Different text.</p>
<p class="undertop-but-different">Something other than the text above.</p>
<div id="inside-undertop">
<p class="morestyles">This div should be inside the above div.</p>
<span class="forfun">FUN!</span>
<span class="span-to-the-right">Yea, <span class="omgfun">FUN!</span> no line breaks.</span>
</div>
<p class="undertoptext">This should use the same style as 'Different text.' above.</p>
</div>
</BODY>

What's easier to read for you?  Simple answer right?  The fact that your teacher isn't doing it is dumbfounding.  She's complicating things by not showing it, and it shouldn't come as a surprise when the students are able to learn off of it.  Consistent (as in, always follow a pattern, whatever pattern you choose doesn't matter, as long as you follow a pattern and not switch it up half way through) indentation and syntax structure will save you DAYS worth of time trying to debug and maintain in the overall scheme of development.  HTML, CSS, and (mostly) Javascript don't rely on whitespace to parse out the code.  I won't get into why I said mostly javascript, as you'll know what I mean when you go through the book.  Because they don't rely on whitespace, you can indent as much as you want, or as little as you want.  My personal preference is two spaces for tabs.  That way I don't have ridiculous indentations that make it near unreadable when there's a lot of child objects in the DOM, but it is still visible.  You can choose your own, whatever works best for you.

Also for a beginner would you recommend using The comment lines a lot to mark what things are all the time, or just learn how to pull out what is what by looking at it?

Comment away.  People always say "don't over-comment", but that is a subjective definition they always throw out.  Comment as much as you need to, or as little as you need to.  Your definition of over-commenting is different than somebody else's.  The only catch is that when you deploy your code, and you finish the "development" stage, you will want to remove your comments.  You don't have to do this by hand, as there are parsers out there that can do it for you.  I don't have one off the top of my head, but they do exist.  Try googling "HTML minifier", and I'm sure you'll come up with something.  The reason I say this is that when it loads in the browser, if you comment a lot, it could slow down the page render, also, depending on the content, you may not want to have some comments exposed to the browser where the user can view them.

Also worth noting, I love to over comment when I pick up an existing project.  Often times comments are meant for THE developer who wrote the code, and not so well for other developers who are not familiar with it.  If I pick up a project, the first thing I do to help understand it is to go through and comment everything.  Where is this function getting called, this object is called in this order, etc... I find that as I comment, I begin to better understand how existing code works, because it slows me down, has me running back and forth to make sure my comments are accurate, and gets me to actually read the code and understand the order of different parts.  Your experiences may vary.

And how are the various labels done on the forums, like in the left corner where it says "Stick Online Forums" over to the right and down where it is shaded differently than the rest of the page? and so on and so forth, like how the area around the text box I'm typing into is bubbled out from the white page and stuff like that

Igu did an excellent job of showing what happens when you use divs to break out the content.  The way he's doing a majority of the placement of divs is through CSS "margin" and "padding".  Using these, you can do just what the names imply.   Set a margin around an object (doesn't have to be a div as his example shows) so that it isn't nudged right up against another, or you can pad the contents inside of an object so they don't nudge right up against the sides of it's containing object.  As far as how to get things like gradients and such, I won't rehash what Igu said, but there are multiple ways to do it.  Using CSS2 (the accepted universal version of CSS currently), the only way to get gradients is to use images.  with CSS3, just like how you can set margins and padding, you can also create gradients.  The problem is, since CSS3 is so new and ever evolving, every browser does them differently, so you'll essentially have to double if not triple your CSS to accommodate all the different (modern) browsers.  Not the easiest solution, but I prefer it as I'm all about performance.  Did I scare you away from using CSS for gradients?  Well here, I'll reel ya back in:

http://www.colorzilla.com/gradient-editor/

There ya go.  generate your gradients, let it generate the CSS for you, copy and paste it into your HTML file (or a separate CSS file if you've gotten to that point yet), and assign your object's classes and id's appropriately.  Mission accomplished, and at that point, with the exception of making your page cross browser compliant for the outdated browsers that don't support that sort of CSS, it's actually easier to use than images.

If you do go with image gradients, just remember to make the image as small as possible.  If the SO forums background (the very dark blue to very light blue visible to the far far left and far far right were an image, it would only be one pixel in width, pretty much invisible to the user unless they zoom in on the image.  Smaller image = quicker load.

[sayers6]

Well seeing that I'm still just starting I'll be staying away from gradients for awhile. Our class is on our 3rd "web page". Really rather boring. Anyways, is it better to use an external CSS sheet, or just keep it in the head? I like having standalone CSS to where it's easy to edit some of it, but what about load speeds? May edit for future questions depending on how long a reply takes.

[Scotty]

Well seeing that I'm still just starting I'll be staying away from gradients for awhile. Our class is on our 3rd "web page". Really rather boring. Anyways, is it better to use an external CSS sheet, or just keep it in the head? I like having standalone CSS to where it's easy to edit some of it, but what about load speeds? May edit for future questions depending on how long a reply takes.

Absolutely go with external.  The reasons are plentiful.  1) It's easier to work with, without cluttering up your HTML document.  2) You can cache external CSS whereas when you start to get into server side scripting, your HTML files become templates or files that are otherwise generated dynamically and can't be cached, which essentially means pages load faster. 3) For the love of all that's holy, reduce down inline CSS to as little as possible.  It increases the HTML documents file size and becomes un-readable very quickly, which equates to slower loading and longer time spent debugging. 

We've been using in-line (although I'm not entirely sure why) and putting it in the <head> object so that it is convenient and easy to show examples, but that doesn't mean that should be how it's done for large files.

[igufed]

I've just been doing it in-line so he has only 1 file/source to look at.  I definitely prefer css in its own file.

[Scotty]

I've just been doing it in-line so he has only 1 file/source to look at.  I definitely prefer css in its own file.

I should clarify.  By inline I mean <p style="...">...</p>, not put into <style> tags in the <head> object.  Still not ideal with the latter, but much better.

[igufed]

I should clarify.  By inline I mean <p style="...">...</p>, not put into <style> tags in the <head> object.  Still not ideal with the latter, but much better.

Ha, duh.  I've gotta not respond to things on here while working on other things.  Latest project is taking up my entire brain capacity.

I wouldn't dare use that method for an entire site.  Definitely give you a headache.

[Lucifer]

You know it's a topic about web design when you can spot the word headache at least twice on the same page.

[sayers6]

Lmao, anyways, are there other in-browser validators besides w3c? The site is blocked at school, but w3schools is allowed....

[sayers6]

Scotty, in an example you put "border 1px solid gray;" instead of "border:1 px solid gray;". That just cost me an hour trying to figure out why my border wasn't working. I was using your example so I thought it was right. But, I learned something, when you think a ":" belongs somewhere in CSS, you should atleast try it. It can be undone.


Sorry for double post.

[Scotty]

My apologies.  You'll soon learn that simple typos are the root of all evil when it comes to web design.  There's a couple of ways to make sure you don't make the same mistakes as I've made.

1) What IDE are you using?  In case this is jibberish, IDE means Integrated Development Environment, or editor.  Some people swear by notepad on windows, which I am highly against, others use Notepad++ for windows, which is excellent, I use vim on Linux, also great.  The main reason I bring this up is that IDE's often color code stuff for you, and based off color coding alone, you may be able to detect some mis-colored syntax, which would point to an issue a lot easier.  Some also even have an interactive syntax checker that will scan your syntax for errors and point them out to you while you're editing.  If you ever get serious with large scale projects, you may want to check out Netbeans or Eclipse.  Notepad++ is excellent because it's great for quick edits, and they also bundle a no-installer version so you don't need admin privileges to install it at school.  Eclipse also is the same, but requires java (which is hopefully installed).  I don't think netbeans has a no-installer version, at least not the last time I used it, which was years ago.  If you're looking to only edit a few files here and there, stick with notepad++, it's great for quick edits, and the latter two are likely a little overkill for what you're doing.

2) To answer your question about validators, try http://html5.validator.nu/.  Don't get too wound up on validating your code, as with HTML5, the general realization is that XML is not the future of syntax (Amen).  You can cheat a lot of tags and get away with it in HTML5, such as how you could theoretically leave out the <head> or <html> tags.  I wouldn't recommend doing that though as it takes out some of the organization, and others may wish harm upon you if they have to reference your source code for whatever reason.  Use a validator as a tool, a means to an end, not a goal.  It will pick up on CSS errors like the one you encountered with my code though, so its definitely worth a try.  That is my opinion, others may have their own.

3) Get Firebug, it's an excellent debugging tool: http://getfirebug.com/  It will scour your syntax and look for all sorts of stuff.  You can do on the fly style edits, has an excellent debugger, and a javascript console that will help point out errors made in javascript.  It's a simple browser extension for modern browsers, and I don't know what I'd do without it.

[igufed]

Psht, don't knock on notepad. :O  To me for some reason, most of the features in every other editor clutter my view, even color-coding distracts me.  I just want to see my code in there and that is all.  I'm sure you can customize the view and remove things, but, I just haven't tried.

Definitely get Firebug.  Just 10 minutes ago it helped me fix my javascript for my current project.

[Scotty]

Not really looking for an IDE war, I'm just saying that with notepad, such basics like inline numbering (I'm aware that the status bar will work as well), consistent auto-indentation, color coding for those who like it, and a few other features, it doesn't really have it.  Works for some, not for others.  My biggest complaint is how notepad will throw in carriage returns which can often times cause problems when it's sent over to a linux server.

Besides, IDE wars are up there on the list of stupidest arguments ever to behold.  Everyone has their own opinions and preferences.  Kinda like how everyone has their own asshole, and we all love the smell of our own farts but hate other's.