How to push content centered with css to the left instead of down on narrower screen

Hi guys,

The site is http://www.meldville.com

I use something like below to center the content:

.wrapper {
    width: 98%;
    margin: 0 auto;
}
.inside-wrapper {
    width: 60em;
    margin: 0 auto;
}

Code (markup):

Inside the inside-wrapper DIV there are a left column and a sidebar. [hope you see the picture]
On narrower screen, the break point for the sidebar is being pushed down to below the left column. --> This is the problem.
How do I make all the blocks moved to the left while remain centered.

Any additional suggestion would be greatly appreciated.

Thanks,

Edit: Additional info: for narrower screen, I mean the screen that is wider than 60em like an old squarely-computer monitor that is not a widescreen one.

 

Actually, it's not - not until you hover over it (ie, if I just resize the window, it works fine). So it might be some CSS or js-triggering (I'm suspecting the latter).

 

Can you be more elaborate please, I do not understand.

Here's what happened:


Though the site is built with widescreen device in mind, there are enough space on both sides to accommodate the side bar. I want the whole block move to the left so they are displayed in one piece.
The picture may look too narrow space, but even larger space it still go down to the bottom.

Thanks,

 

None of what you are doing seems to make any sense to me... a fixed container inside a "wrapper for nothing" with a pointless width and redundant centering? Just what are you even trying to accomplish.

Much less that MASSIVE fixed width being an accessibility/design disaster and what it's doing with dropping stuff down being the DESIRABLE behavior! You seem to be asking for the opposite of what you should be doing. Why would you want to make the page harder to use with a counter-intuitive scrolling direction instead of doing what a proper responsive layout SHOULD do and drop everything to one column?!?

The gibberish markup like the list inside a form for something that already has semantic meaning, false simplicity thanks to using placeholder instead of label (aka artsy fartsy bull that ignores how to use HTML properly), and ENDLESS POINTLESS DIV for NOTHING, overstuffed viewport meta BREAKING the usefulness of the site on mobile (NEVER EVER -- and I mean EVARRR!!! -- disable user scaling!)... even the design with it's illegible colour contrasts.

Don't know what you are trying to actually do here, but the first step I'd suggest is throw EVERYTHING you have so far in the trash and start over with actual semantic markup before you even THINK about styling it. You've got a bunch of pointless nonsensical markup, no logical document structure, utter and complete accessibility rubbish --- positioning and layout are the LEAST of your worries.

Really, even if using elastic layout, saying "width:60em" is such a miserable /FAIL/ at web development -- just as big as saying width:976px; --- that it's not a surprise you are having issues. Remember, it's elastic, semi-fluid AND responsive you should be aiming for.

The laugh being you have a viewport meta like you were intending to be responsive, but haven't done anything to make it responsive.

 

Thank @deathshadow,

I did built this site for two years and threw everything to a trash and rebuilt it for another two years, four in total.
I'm not going to throw it away again and watch people get past me on what I'm trying.

It's not perfect yet, some are still not working. I'm putting it on test before bring it to a presentation table. There are still much works to be done.

I don't want elastic layout, because image displayed on the canvas will be distorted the way I don't want it be and I stick to a 16:9 screen ratio.

It is a responsive design but aiming at targeted devices, not a wide range and any devices, because the web app is only work on Chrome and its beta version for Android devices.

DIVs for nothing... Hmmm! I don't care much what a mess inside but a drunk user must be able to use my service without an effort. That's what I'm trying to achieve.

And the design must be minimalistic.

Maybe, I'm not a front-end developer. So I'm not really good at this. When I make enough money someone must take over this job from me.

Do you have an idea how make it fit snugly to a window width before breaking?

Thanks,

 

Does it not follow, then, that you should listen to someone who is?

 

Even when the suggestion is to trash and restart based on a page that's not even close to being finished??

Suggestions to resolve some of deathshadow's issues:
1 - Add labels to the form fields, but make them hidden by pushing them off screen via CSS
2 - Try to reduce the number of pointless elements if possible - sometimes div are needed for CSS hooks, but be sure check to see if some other elements are more appropriate (http://perishablepress.com/power-of-html5-css3/ - I know deathshadow doesn't like HTML5 elements, but they are definitely more semantic than div and I'd recommend using them where possible)
3 - I've never liked the "em" trend for widths either. It ties the width to the inherited font-size - changing the font-size in any of the ancestors can break your layout.

Here's a tip: Try removing the stylesheet from the page - if the site still makes sense without the style, then you're heading in the right direction.

As for using a list in a form, this is a common pattern - what alternative would you suggest Deathshadow? Semantically, it makes sense to me - The form contains a list of fields.

Back to your original question
Looks like the logo height in the header is causing an issue with the layout. You've set the font-size value to be less than the header, but it's actually the line-height that determines the height of the line of text. My suggestion: Increase the height of the header.

 

Actually, a form is not necessary a list, and it's usually not needed at all - you can just have the form with fieldsets, labels and inputs and style them accordingly. There's rarely any need for a containing element.

 

What is important here is the base structure of the website which is where I believe you are going wrong. You may want to consider building the site around a grid. It is perhaps more to do with the structure of the HTML too. Consider what is contained within / outside what block.

You may want to also consider something like this example.

<div class="container">
<div class="block-wrapper"
<div class="block">
<h1>Hi Welcome to meldville</h1>
</div>

<div class="sidebar">
<ul>
<li>Demo</li>
<li>Explore</li>
</ul>
</div>
</div>
</div>

Code (markup):

.container {
position: relative;
width:100%;
max-width: 960px;
margin: 0 auto;
padding: 0;
}

.block-wrapper {
width:98%;
margin:1%;
}

.block {
width: 73%;
float: left;
display: inline;
margin-left: 1%;
margin-right: 1%;
}

.sidebar {
width:23%;
float: left;
     display: inline;
     margin-left: 1%;
     margin-right: 1%;}

Code (CSS):

Then when the screen gets too small we can tell the side bar to display underneath and centered like so.

@media only screen and (max-width: 767px) {

.container {
width:92%;
}

.block {
width:100%;
margin:0 0 4% 0;
}

.sidebar {
width:100%;
margin:0;
}

}

Code (CSS):

 

Thank you guys for helpful suggestions.

I'll look into the details you described as much as I can, because I'm intended to build this site in accordance with all the good practice ones.

Thanks @minionnz for additional suggestions. You see anything I should make improvement. Please feel free to talk about it.

 

It doesn't necessarily have to be a list, but a list of fields is a list of fields. If a container around each field/label is required for styling, then (semantically) I see nothing wrong with using a list. In this case, perhaps it is not needed but the page is not finished so I don't know if there are going to be additional floating fields etc.

 

Then why is your fixed width in EM's? That's what elastic MEANS! (auto-adjusting to the browser default size and/or inheriting through the document)

Which is probably why here for me your layout is dropping even on a 1920 wide screen.

... wha?!? I can only assume you don't realize that the canvas element and it's internal context size are independent of each-other. There is NO reason you can't make the canvas and it's content dynamically scale to screen width or whatever width you want to render for.

Check my crappy little demo:
http://www.deathshadow.com/canvasDemoRun

...with it set to "allow larger size" resize the window -- notice the canvas element is resizing to the same aspect ratio regardless of window size. That's one of the whole reasons to USE canvas!

Well then the "web app" is crap -- and if it's Chrome/Droid only why the **** would you be targeting desktop resolutions only?!? Again, doesnae make much sense.

George Carlin once joked "not every ejaculation deserves a name" -- in that same way not every element needs a div around it or a class/id... much less triple or quadruple DIV. There are times where such extra wrappers make sense (hence why DIV even exists) but you should expend your existing tags FIRST before diving for them. Said existing tags being your semantic markup providing logical document structure... which if you have done properly makes the HTML 5 tags and their alleged semantics utterly and completely redundant.

Let the extra crap drop so it goes single column, then make a routine that traps the width of the canvas element's parent and the height of the window, and calculates the optimal canvas display size. Call said routine at startup, AND when "window.onresize" triggers so you can adjust the canvas to fit.

Of course CANVAS being a scripting only element it really has no business in the HTML in the first place -- of course that's why I think it's jacktarded it's even part of the HTML 5 specification. (along with all the other jacktarded redundant pointless crap in 5)

Much less for *** sake it's new code, at least bother opening and closing parameters properly instead of sleazing them out without quotes like HTML 3 is the bleeding edge of web development. (again proving what I say about 5's target audience)

I mean, just for example:

	<div class=wrapper>
	<canvas id=c></canvas>
	<header>
		<div class=scale>
			<div class='logo left'>
				<a href="index.php?x=aW5j&y=aW5kZXgucGhw">meldville</a>
			</div>

Code (markup):

That's one giant mess of garbage doing the job of:

<div id="top">

	<h1>
		<a href="/">meldville</a>
	</h1>

Code (markup):

Scale div for nothing, "logo left" div doing H1's job AND using presentational classes, and of course the canvas element in the markup that doesn't seem to be there to do anything, and if it IS there to do something it should be added by the script since it's a scripting only element. IF that's presentational, I'd say screw it oh well, if that CANVAS is a functionality element, that's when you get a NOSCRIPT tag in there!

Or this mess:

					<div id=login>
				<form id=login_form method=post action='load.php'>
					<input type=hidden name=path value='systems' />
					<input type=hidden name=file value='login_ck' />
					<ul>
						<li><input type=text name=ln_email id=ln_email placeholder='Your Email' title='Your Email' autofocus required /></li>
						<li><input type=password name=ln_password id=ln_password placeholder='Your Password' title='Your Password' required /></li>
						<li><input type=submit id=ln_submit name=ln_submit value='Log in' /></li>
						<li>
							<input type=checkbox name=remember value=1 /> Stay signed in
							<a href="index.php?x=aW5j&y=Zm9yZ290LnBocA==" id=forget_pswd>
								Forgot password?
							</a>
						</li>
					</ul>
				</form>
			</div>

Code (markup):

DIV for nothing, no fieldset, placeholder doing label's job (again, false simplicity), title attributes for NOTHING, incomplete/invalid as of 1998 attribute / quotes (basically code that was invalid the DAY forms were introduced!), list for NOTHING since input already HAVE meanings.

	<form method="post" action="load.php">
		<a href="#topLogin" class="showLogin"></a>
		<a href="#" class="hideLogin"></a>
		<fieldset id="topLogin">
			<label for="ln_email">E-Mail Address:</label><br />
			<input type="text" name="ln_email id="ln_email" required /><br />
			<label for="ln_password">Password:</label><br />
			<input type="password" name="ln_password id="ln_password" required /><br />
			<input type="submit" class="submit" value="Log in" /><br />
			<input type="checkbox" name="remember" value="1" /> Stay signed in &bull;
			<a href="index.php?x=aW5j&y=Zm9yZ290LnBocA==">Forgot password?</a>
			<input type="hidden" name="path" value="systems" />
			<input type="hidden" name="file" value="login_ck" />
		</fieldset>
	</form>

Code (markup):

Oh noes, not a whole extra two lines of text to make the form accessible... I swear, what the **** is in the kool-aid that makes people think that putting the label in the input is a good thing? It was RUBBISH when people were doing it with scripttardery, and it's utter complete rubbish now that people are mis-using/abusing placeholder to do the exact same half-assed halfwit bull.

Since again, PLACEHOLDER IS NOT A REPLACEMENT FOR LABELS!!! -- see the big red warning box and the paragraph before it?

... and I quote:

But don't take my word or the specifications' word on it:
http://www.nngroup.com/articles/form-design-placeholders/
http://www.webaxe.org/placeholder-attribute-is-not-a-label/
http://www.pardot.com/faqs/forms/placeholders-and-labels/

... and no @minionnz, hiding the blighters is NOT the right answer; in fact it's completely missing the point!!!

You aren't even able to build a form properly/semantically/accessibly or even properly form a document, and you're worrying about layout and CANVAS stuff? That's like hopping in a SR-71 to go over Russia when you're not even qualified on daylight solo flight on a prop-jobber.

Also is there some reason you're sending things the user might not even access like the forgotten PW form hidden? Also, why bother sending the exact same form TWICE on the page?!? (once hidden in the heading, once next to the VIDEO?)

Those gibberish seemingly random search/user unfriendly and to be frank seemingly untrustworthy URI's on things aren't helping matters either.

 

They are not grammatically short bullet points or selections (as in literary bullets, not as in drawing dots before it) and as such they are NOT what belongs in an unordered list. NOT EVEN CLOSE to what goes in a UL unless you have zero command of semantics and no experience in the professional document writing on which HTML was originally based.

LABEL + INPUT already HAS a semantic meaning, why the **** would you wrap extra tags around them for NOTHING other than making the DOM (and therein any DOM searching scripting and application of style) bloated and slower? Admittedly he was dicking around pissing away accessibility and functionality abusing placeholder to do label's job, so SOME form of structure I guess was better than none... except it isn't actually better so...

Redunant semantics are worse than none at all since then it's just code bloat; hence why SECTION, HEADER, FOOTER and NAV are pointless redundant code bloat BS; at least if you understand how to use numbered headings, horizontal rules, etc, etc, properly. Those are NOT list items, THEY ALREADY HAVE MEANING, so don't waste time pissing on them with redundant code bloat doing the job of a line-break!

Part of why I prefer DIV to the ALLEGEDLY semantic new 5 tags -- since it's semantically neutral and implies no meaning other than "this or it's children may receive an as yet unspecified style" so it's NEVER redundant. There are MORE than enough semantic tags to convey document structure (H1..H6, HR, etc) that one should use up BEFORE adding DIV, and if they were used properly and browser makers (other than the now defunct Opera and JAWS) would get off their asses and implement properly would make the 5-tard BS nothing more than pointless code bloat and adding more tags to a "specification" that is already too damned big for it's own good.

But what do I know? I'm the guy who was looking forward to the "real" HTML 5 before the WTFWG came along with their BS, where redundancies like IMG were supposed to go away too.

 

So what exactly is the point??? It solves basic accessibility issues (eg Screen readers), while conforming to the page requirements. Is it the fact that the label isn't visible after the user fills the field? There's no reason the user can't provide some other hint AFTER the field has been filled - such as displaying the label above the field. http://mozmonkey.com/2013/12/good-ux-for-placeholders-as-field-labels/
The point is, the user doesn't want labels next to the field FOR STYLING/DESIGN reasons. Saying "Wrong! Do it again" doesn't help in the slightest - especially when there are other workarounds.

Rubbish. Opinion being posted as fact again. Straight from W3C: "The content model for list items is quite broad, including paragraphs, lists, performatted text, forms, tables, figures and admonishments." UL represents an "Unordered List". It doesn't necessarily have to be grammatically short bullet points just because the default styling shows a bullet.

For one, it's easier to float a field/label when it's wrapped. Secondly, it provides structure to the form - if a machine can't figure out which fields/labels/elements etc belong together (ignoring the for attribute for now), then this whole semantic argument is pointless.

It does imply meaning though. A div is a generic container that wraps child elements - it has virtually no semantic meaning. A section implies that the contents are a "section" of the current document (ie: grouping child elements with a heading). An Article can be used to represent an individual article/item that doesn't require the surrounding HTML to make sense - it is self-contained (a product in an e-commerce catalogue for example).

There's no such thing as redundant semantics. Semantically correct HTML is important to help bots/screen readers etc figure out the structure AND content of a page (surely you agree with this?) - so why would you not want to use more semantic containers if they exist? The more I can do to help a machine/bot read my HTML, the better.
It's the same reason I'd recommend using a wrapper to separate a set of fields/labels/elements instead of a br.

 

Better early than late. Consider, you're in Omaha and want to go to NYC. A few miles down the road you notice you're heading west; do you turn around now, or wait 'til you get to LA? If you find your web structure belongs in the toilet, do you flush it and start again or do you keep adding to the load?

 

Graceful degradation, fighting false simplicity, and maybe -- JUST MAYBE -- actually using all the HTML elements for what they are actually for? SOME of the other methods you mentioned have merits though they rely on scripttardery, which again a page should be fully functional BEFORE you start adding scripttard bullshit to it.

Since it's about more than just screen readers -- non-CSS UA's? Search engines possibly pre-parsing the form on the SERP? Much less if you use display:none or visibility:hidden screen readers like JAWS will ignore the label, and the placeholder, and leave the user going "what the blazes is this input even for?"

That's not the user, that's the developer or designer being ignorant asshats about accessibility JUST for their art faygelah BS; which is the point where I end up kicking most of the ignorant halfwits who call themselves "designers" right square in the junk. OH NOES, THE TEXT IS ABOVE and/or NEXT TO THE BOX!?! Cry me a ***ing river!

EXCEPT OF COURSE WHEN IT'S WRONG AND SHOULD BE DONE OVER AGAIN!!! -- blindly throwing more code at it in the form of gooftard tricks and scripttardery is NOT the answer!

Do you have a source for that because.. uhm... yeah. Not seeing it in 2, 3.2 or 4... is that some bit of crap they added to five like the rest of their pissing on document structure with redundancies? In fact I'm pretty sure that the W3C wouldn't misspell "pre-formatted".

Pretty much if it's not here:
http://www.w3.org/TR/html4/struct/lists.html

I don't give it a lot of weight.

So clearing on the fieldset or on the one (of two) floated elements is SO hard?!? Much less the godsend that is inline-block? NEVER understood why people do that pissing on the markup, I can only assume ignorance of how to use CSS properly.

Except that's why FOR is NOT optional if the LABEL isn't wrapping the INPUT, no matter how many ignorant halfwits

... and if you are using it for either of the purposes you just said, you're using them for presentation, NOT semantics... and since semantic is a sick euphemism for "using HMTL properly" that is used so as not to offend the mouth-breathers still vomiting up HTML 3.2 and slapping 4 tranny or 5 lip-service on it... well...

You are aware of why headings HAVE levels and what a horizontal rule is in professional writing, right? H1..H6 does NOT mean "draw text in different sizes" -- a H1 is the heading under which all content of the page is subsections. A H2 indicates the start of a subsection of the H1, a H3 indicates the start of a subsection of the H2 preceding it, and so forth; with a HR NOT meaning "draw a line across the screen" but "a change in topic/section where a heading is undesired or unwarranted" -- that's why in professional writing a horizontal rule can be anything from three asterisks, to a line, to a double-bar, to a page-feed.

... and since those tags divide the page up into SECTIONS, what the blazes do we need SECTION for? Pointless redundancy and EXACTLY the type of thing 4 STRICT was trying to get rid of. Since we have section starts why do we need NAV since we could/should be able to just navigate to the desired heading? (which JAWS will do, as did Opera 12/earlier). One would THINK that anything after the last HR and/or last H2 would be the footer, so why do we need FOOTER? We HAVE heading tags, what the hell do we need HEADER for?!?

Even ASIDE is nonsense; from a grammatical point of view (the only one that should matter for semantics) the only reason to use it would be to mark a literary aside - aka when a character breaks the fourth wall and talks directly to the audience while the rest of the cast continues on unawares... abusing it as people have to say "this is a sidebar" just makes it as presentational a tag as CENTER was. "But it's off to one side" -- that's presentation and as such has NO damned business in the markup!

Tell that to the makers of 4 Strict, who killed off MENU and DIR for being redundant to UL, APPLET, BGSOUND and EMBED as redundant to OBJECT (with IMG being on the chopping block next for the same reason), etc, etc... much less that doing dipshit BS like wrapping header around a heading, or section around a section started/marked by headings, or the dumbass ignorant prairie pie HGROUP tag; a tag so stupid it was FINALLY killed off but by it's mere existence showed that the WhatWG had no damned business making a "semantics" specification in the first place.

... as further evidenced by the new pointless garbage like VIDEO and AUDIO (redundant to OBJECT and promoting vendor lock-in in the name of fighting same), EMBED magically now being valid, MENU being back but repurposed for some strange thing I have yet to see a plain English explanation of or practical use for, elements like CANVAS or PROGRESS that have no damned business even HAVING a tag, etc, etc, etc...

Basically 5 seems crafted by and for people who never embraced 4 STRICT, never grasped the connection to professional writing that prompted TBL to create HTML in the first place, and on the whole has a target audience consisting of people too green to know the difference, or who never managed to extract their cranium from 1997's rectum.

While so far all 5 has done is BREAK it in existing accessibility UA's, I've yet to see ANYTHING other than data-scraping content theifs benefit from their presence, and they ARE pointless redundancies for what already exists. A larger harder to use "specification" (picture me making air quotes like Doctor Evil there... "laser") that consists of throwing more code at the problem for NOTHING is NOT the answer!

Whereas I'd try to leverage the LABEL and INPUT PROPERLY for that since they should have a semantic relationship already and require no extra tags or assistance. That's why you can either wrap the INPUT in the LABEL, or use the FOR attribute, or both... and why in STRICT the FOR attribute is NOT optional.

Which again means nothing to the people who still think it's the late 1990's and are still sleazing out HTML 3.2 with the vendor specific tags that followed, and now just slap 4 tranny or 5 lip-service around it so they can pat each-other on the back over how "modern" they are. It has reduced HTML 5 to a sick buzzword akin to Web 2.0, and developers worldwide are dumber as a whole for it even existing.

... and is why whenever someone calls HTML 5 "the future" I go "REALLY? Looks like the worst of pre-STRICT practices to me!"

 

@deathshadow the definition of the ul is taken from here: http://www.w3.org/MarkUp/html3/listitem.html - which isn't really "up-to-date" on anything. Oh well.
Granted, your strict definition of semantics and hierarchy, while perfectly valid, are a bit archaic, which is also reflected in HTML 5 - perhaps they realised that the marginal audience not on a graphical browser/screen-reader etc. would benefit from easier to understand structure? Granted, sections and articles both throw a warning if there's no header (h-element) - and yes, header and footer are a bit redundant, but they provide an ok container for both - instead of a <div id="header"> or <div id="footer"> which isn't seldomly used either - there might be plenty of reasons why you'd want to wrap the content of header and footer - for instance a different style (background-color maybe?) for the block - I dunno. There are possibilities that will still be worthy of implementation even though it might not be strictly semantic from a pure HTML standpoint. I for one can understand that people use different types of H-elements for their inherit size-difference - is that a bad thing? Maybe - but again, it only affects a tiny fraction of the users - mainly those using headings to navigate by keyboard. Maybe max 5-10% of all users, and that might mean none of them will ever go to your site - I know that is a cop out, and not necessarily even necessary, but it's not the end of the world if the h3 doesn't follow a h2 (or is contained within the container containing the h2.

 

To clarify, I wasn't suggesting using display:none, but setting the text position offscreen (which doesn't hide it from screen readers)

Fair point - though I was trying to suggest that developers/designers (didn't mean users, sorry) often get their requirements from management. And that UX and branding/theming is a valid concern - and can be achieved without killing accessibility.

The first website I ever created used frames and tables for layout, IE-specific elements and pretty much everything else I refuse to touch nowadays.. People have to start somewhere and they come to this forum for help - being constructive would benefit people a lot more in my opinion. Extremely negative comments can have a huge impact on someone's confidence which is why I always argue when I hear comments like that.

@PoPSiCLe found the reference - hadn't noticed it was HTML3 (really should have found a better source), but that doesn't necessarily make it invalid. If you can find something that suggests I'm wrong, I'll change my stance on this particular point (and apologise).

What about when you need to add a checkbox underneath a input field? Sure, it adds a little bloat but it's worth the trade-off IMO. Remove "label" from my argument then, I wasn't suggesting you shouldn't use the for attribute- just that there may be multiple form elements that need to be grouped including, but not limited to, input and label (See previous sentence). Would fieldset fit this scenario? Maybe, but I tend to think fieldset should be grouping a large set of fields - not just a few.

I generally think of semantic HTML as "allowing machines to read my document".. A machine can tell that it's a form containing a list of X number of fields. But perhaps you're right - maybe I'm just so used to using ul/li for forms that I'm thinking up arguments to justify it.

I think of it this way: It is easier to write software that can find a related element within a particular section on a page using a specific "section" container element than one using HR (using regular expressions for example)
Header/Footer - they're not just for text. They can mark a whole group of varying elements as "header content" - so the machine/bot knows that it's not the main focus of the page.
Same for aside - it places more emphasis on the actual body/content/focus of the page by marking certain elements as aside (eg: sidebar)

Admittedly, I am disappointed at the non-strict direction of HTML5 as well - I think it can be attributed to the fact that people are lazy and rather than fixing invalid code, it was easier to simply make lazy code valid. On the other hand, there are more uses for parsing/scraping HTML than just stealing - and if I can make it easier for machines to read my code by using valid HTML5 elements, I will.

@deathshadow - Just to be clear, even though I argue a lot, I do respect your opinion and you make many valid points. I know I'm new here so I want to make it clear I'm not trying to troll or start wars on this forum - if someone proves me wrong on anything, I'll admit I am wrong and apologise - but at the end of the day, I want to help other people learn and improve (which is why they come here). I'm not necessarily trying to prove you wrong on everything, I'm just trying to balance out the negative comments so the original poster doesn't get too demoralized.

 

Hi guys,

Thank you or all the good advice. I'll get my codes revised accordingly.

Wow! That's great. That's what I'm looking for.

I hope that you don't mind if I borrowed some of your codes

 

Damn it - now I wanna play a sub-sim :/