New to Web Design, Pointers About Positioning Wanted!

I'm a web design student. I'm fairly ahead of the class which started a month ago. I read the entire text book we were given (HTML and CSS by Jon Duckett). I've made a website that doesn't really have any sense of responsive design. It was mainly to just get me used to html and the intricacies. If you'd like to see it, the link is this:

http://www.4mystudents.com/3512arnold/project-resume-three/index.html (Best viewed in chrome since it's not a responsive style)

I'm hitting a wall in terms of understanding positioning. I've looked at a lot from Code Pen to CSS Zen Garden and positioning seems to be really fluid, not like what I processed in my CSS. To give an example-

CSS Zen Garden main site:C


header h1 {
background: transparent url(h1.gif) no-repeat top left;
margin-top: 10px;
display: block;
width: 219px;
height: 87px;
float: left;

text-indent: 100%;
white-space: nowrap;
overflow: hidden;
}
header h2 {
background: transparent url(h2.gif) no-repeat top left;
margin-top: 58px;
margin-bottom: 40px;
width: 200px;
height: 18px;
float: right;

text-indent: 100%;
white-space: nowrap;
overflow: hidden;
}

My code:

.sidebar-photo {
position: relative;
top: 288px;
left: 25px;
opacity: 0.5;
max-width: 170px;

}

.sidebar {
position: relative;
margin-bottom: -999px;
top: -400px;
right: 0px;
overflow: visible;
z-index: 1;
background: url(images/nav-header.png) no-repeat;
max-width: 300px;
}

header {
background: url(images/header1.png) no-repeat center;
}

.move-text {
position: relative;
left: -1000px;
}


My problem here resides in the fact that CSS Zen Garden positions all their pictures top left. How does that work and why does it work? Also, positioning seems very streamlined there. No messing with relative or absolute. Like I have margins and top/left/right for hundredths of pixels. CSS Zen Garden does no do that.

Could somebody maybe break down some specifics in terms of positioning. I already understand the intricacies of positioning elements using relative, absolute, fixed, and static. What I am concerned about is cleaning up that process like CSS Zen Garden.

Any help would be appreciated

 

Uhm... me thinks you have a LOT to learn, young padawan.
CSS Zen Garden isn't recommended, btw, they have a lot of nice designs, but their codebase is outdated by about 3-4 years.
For instance, they're still using 'px' to denote sizes, which is a stupid thing to do.

That being said - I think you're misunderstanding something. At least if that code is anything to go by (and please, for the love of something holy, learn how to use the [ code ] bbcode - it even has a button in the editor, under "insert"), the only think I can see positioned "top-left" is the backgrounds - which is perfectly fine. This has absolutely nothing to do with positioning, which is either relative (relative to the main elements), absolute (positioned at a set place inside the closest parent with position: relative, absolute or fixed; set - if no parent has a position set, it's positioned based on the page. Fixed is just that, fixed on the page, it won't move or change position regardless of other items on the page. Static is rarely used, it just means the element stays within the flow of the page.

It's late, I might have fucked up a bit, but that's the gist of it.

 

As a rule of thumb, do not use the position property for any major layout elements. Beyond that try to avoid its use at all. There are situations where it is appropriate, but there are huge gotchas just waiting to bite big chunks from your butt. Wait until you have a good understanding of html's flow before trying to deal with out of the flow positioned elements.

If your instructor even mentions the position property early on, I'd suggest he is gormless, or nearly so.

cheers,

gary

 

The natural flow of the markup will generally produce correct position relationships but the fine turning for position does not normally need to use the position property which is generally a last resort or used for special effects. The fine tuning is done with margins, , padding and display values. I left out float, because using it gets novice developers in trouble if they have not master using margins paging and the default behavior of the html tags.

The best way to learn is not from a book. The only way to get good at it is by coding experimentally. Try out combinations to see what they do. Don't limit yourself to what you think you know. Learn every tag, and all the css properties, not just the ones commonly used.

 

As @COBOLdinosaur said, and Gary kind of implied, the natural order of your markup should determine your "flow" and play towards helping with your layout. Generally speaking concepts like relative and absolute positioning should NOT be used for the normal position of elements, and should only be used to "tweak" minor flaws, create advanced methodology like image replacement (a technique for placing images over text for graceful degradation), or for advanced multi-column techniques. MUCH more important for you to master is the concept of "floats" before you even think positioning, along with concepts like elasticity, fluidity, and finally responsiveness.

Generally speaking responsive design is just the last in a long series of "progressive enhancements" one should use in building a website. As I often outline for people, the process I use is as follows:

1) Content -- I take the intended content or a reasonable facsimile of future content and arrange it into a logical order as if HTML didn't even EXIST.

2) Semantic Markup -- Apply all the semantic tags with meaning to that content to say what things ARE, and NOT what I want them to look like. Since this is the SEMANTIC stage tags like DIV and SPAN have no business being added at this point... and if you are using numbered headings and horizontal rules properly, HTML 5's garbage nonsense ARTICLE, SECTION, NAV, FOOTER and ASIDE tags serve no legitimate purpose either. (NOT a fan...)

Let's just say there's a reason a LOT of teachers and professionals will tell you to write as HTML 4 strict then deploy as HTML 5 for the handful of things that are being shoved down our throats like the pointlessly redundant VIDEO and AUDIO tags (They're redundant to OBJECT), or scripting only elements that shouldn't even HAVE tags like PROGRESS or CANVAS. (I LIKE CANVAS, I just think it has no damned business being a tag in the markup! The only purpose I can see for it's existence is to be redundant to NOSCRIPT!)... HTML 5 -- the bleeding edge of HTML 3.2 and 1997 methodologies come home to roost!

3) Create the LayoutS -- YES, PLURAL! I use placeholder blues or greys at this stage just to see the parts... and this is when I'd add DIV or SPAN, but only as needed or when I've expended what I can do with the existing tags. The layout I start with is the lowest common denominator, which some people say is mobile / small screen. Those people would be wrong as those are actually advanced browsers we can target with media queries. The actual question to be asked is what CAN'T we target? The answer there is IE8/earlier on desktop so that's what I make FIRST. Said design would use dynamic fonts (declared in % or EM), be elastic (any widths and paddings in EM), semi-fluid (max width so long lines aren't hard to follow), and THEN and only THEN once I have all that in place do I make the responsive layouts by stripping off formatting from it, or possibly even making larger layouts for massive displays that split single columns into multiple ones.

4) Make it Pretty. THIS is when you choose your final colouration, add presentational images (if any), etc, etc...

Looking at your site, you've got a LOT of flawed methodology in there from just a layout standpoint. Fixed width, massive background image, and WORST OF ALL -- a fixed HEIGHT; an absolute no-no you duped yourself into with that stupid background image that has no business on a website no matter what the artsy fartsy types who know jack about HTML, CSS, or accessibility might claim even if they have the unmitigated gall to call themselves "designers".

The code is pretty jacked too. Might help if you spelt "description" right, it's usually a good idea to put your charset META BEFORE you actually have CDATA (like say, your title tag or the content attributes of other META?), you've got double-breaks doing what should be handled by closing the paragraph and starting a new one (you know, those grammatical paragraphs you should have learned about by the 5th grade? Which is what, entry level college these days?)... You've got ARTICLE around what should be a BLOCKQUOTE, italic around what should be a CITE, presentational images in the markup, static style in the markup (generally just say NO to using <style> or style=""), multiple H1 without SECTION tags (again just HTML 5 pissing on logical document order and proper writing styles), paragraphs around things that quite clearly are NOT grammatical paragraphs, DIV around things I don't think even need DIV, that stupid malfing polyfill HTML 5 shim garbage (also not a fan of that), no media target for your stylesheet embed... and that's BEFORE I look at the CSS with it's uselessly pointlessly vague filename.

If you were using media targets, naming it the same as the target helps say WHAT that style is for... something that should have been covered the moment you were introduced to loading a stylesheet with LINK. If it's not in that book I've never heard of, the book is rubbish. (though honestly the use of 5-tardery had me thinking that already)

In the CSS, the methodology is ALL WRONG. Your ATTEMPT at using webfonts is incomplete broken gibberish, the use of relative positioning in the manner you have likely means you didn't have relPo explained to you properly (when you move something with that, it only moves where it's DRAWN, and NOT where other elements THINK it is!), that massive negative bottom margin is guaranteed to be a broken layout on EVERYTHING (I don't think the page is rendering as you intended on ANYTHING I have here -- including Chrome)...

Really all those ways your resorting to relative positioning? That's NOT how you make a layout. Dunno if you were taught that, found that from the book, or just blindly came up with it on your own -- but NO!

... and yet for ALL that I don't doubt it, you're probably light years ahead of the class; possibly even the teacher. That's just my experience talking. Even with your typo's and flawed methodology and all the things I just ragged on you're pretty much neck deep while most people at your stage likely have barely figured out how to put on their waders.

Oh, and for **** sake, do NOT take ANYTHING from "CSS Zen Garden" as examples of how things should be done or as good design; everything they have amounts to bloated, inaccessible buggy laundry lists of how NOT to build a website! This is evident in the site itself with it's reeking of "WCAG, what's that" in colour contrasts ALONE. It might be "pretty" but that doesn't matter if half the population can't actually read any of the headings!

I've NEVER seen ANYTHING on that site that wasn't an absolute bloated wreck and accessibility disaster.

 

Awesome information guys, I appreciate it! Death Shadow, you rock. I'm a journalist, so I'm all about the constructive criticism, and your straight forward attitude is not something I was finding from my professor, the internet, or the books I've picked up. One thing that was throwing me off big time was using the aside tag that didn't actually put the element on the side and still was aligning in a linear fashion, under the previous element instead. Maybe using HTML5 elements skewed the concepts a bit. We have not done media queries. The book only goes through HTML/CSS. I have very limited to no knowledge of Javascript, PHP, or Jquery, so everything I've tried to do has been CSS based. The class I am in just seems to be a "here's the different elements you can use" kind of class, with a touch of css. When we got to the CSS chapter and I was able to make things do things, that's when I really got into it and started to explore even more. I just got a paycheck from my GI Bill and I think I might pick up some books! What books would you guys recommend?

Could you explain "horizontal rules properly"? Is it possible to set elements side by side to each other by manipulating just padding and margins? And what is the best way to define images? In the HTML or in the CSS? And should pictures be contained in a div?

The class is still on floating an element left and right. The last assignment we had was to write about a hobby, add two pictures; one floated left, and the other floated right. They have not went over padding/margins/positioning at all. I found it very slow paced and boring so I went ahead. That specific site linked was something I knew was bad. But it was something I did during the process of learning.

 

There are options to floats. Put the images in block elements with widths expressed in % or vw; with total width slightly less than 100%. Then alter the display behaviour with CSS using display:inline-block; display:inline-table; or display table-cell;. The first one will position to the left and for the on the tight one use padding-left to move it to the right side of the wrapper.

Another option is to put them in a common container of full width and user margin-left on the second one.

However, you are going to learn a lot less by reading our posts and following instructions. You know what is available so play with the properties. In webdev you learn by doing and experimenting. You won't learn much but old techniques from books, and most courses are taught by "teachers" not "developers" so all you get is an academic view of the world.

From what I see you are already past you teacher, and you need you experiment and stretch yourself by exploring.

 

Yeah. I wouldn't really recommend anything CSS-based when it comes to books - if you do prefer books, though, you could probably find some good books on HTML - the structure and correct usage - however, you should probably stay clear of any books promising to teach you HTML5, since they're mostly not following good practice anyhow. See if you can find a book about HTML 4 strict, or XHTML - the latter because it has a much stricter structure, and if you forget something, like closing a tag, it quickly comes back to bite you. CSS and the rest is best to find on the web, in forums and the like.

 

I'll give that a try! Right now I have 3 element blocks, one <section> tied to id of sidebar1 which I want that to hold my twitter feed and links to my social accounts on the left. The middle will be the main content block ( about 3 paragraphs of text) set in a <section> id'd as main, and the far right I wanted 3-4 pictures in a succession that I placed in a <aside> element named extra. At first I just used figure and figcaption which worked, but it was boring. So I found something utilizing transform off of code pen that offered the same structure but better look. I floated all three of these left which lined them up perfectly except that the footer overflowed the entire page. I fixed it by adding a margin, but I lowered the size of the pictures which caused it to jump to the top under the nav bar. I deleted the footer for now so I can focus on these other elements. Another thing, the picture aside element will jump to the bottom of the screen when the resolution gets smaller even though the other two elements stay put. I thought it might have something to do with using the code from code pen to create the transformations, but even with my regular boring figures it did the same thing. So frustrating, but I love the headache regardless, haha. I attached my html and css files if you wanted to take a look. I took Deathshadow's advice and redid the markup and looked at how the content would flow best. I think the side by side option would be good, and it will work if I can stop the pictures from flowing to the bottom of the page when the resolution changes.

(I couldn't upload it as a css file)

Edit an hour later: Clearing floats makes so much sense and fixes so many issues >.>

 

The right way is to just paste the code in the post, using [ code] tags, or the insert-button in the editor

 

That's because most of the scam artists and fly by the seat of their pants know-nothings who end up running websites, writing books or teachers have done everything they can to stamp out anything resembling dissension. There's this disgusting "Status quo FTMFW" attitude right now where you say half the things I say here on DP, no matter HOW politely you put it, people will get their knickers in a twist and boom, instant banning, removal from groups, etc, etc... The wussy "don't make waves" "if you can't say anything nice" asshattery being a hefty chunk of why websites are growing less and less useful to visitors daily.

NOT helping is that the artsy fartsy types have taken over screwing over usability and accessibility with their very pretty but ultimately useless notions of "design". Which to be frank what MOST people are calling "design" right now isn't! It's Graphic Arts.

That behavior is what I would expect! WHY you ask? -- because HTML is NOT supposed to be about saying what things are going to look like. It's supposed to be about saying what things ARE.

... and let's look at the dictionary meaning of "ASIDE"

http://dictionary.reference.com/browse/aside?s=t

As an adverb the first meaning is purely presentation! That's NOT HTML's JOB to say if something is "off to one side" or "a short distance apart" -- that's NOT a semantic meaning. Generally speaking we'd have to go to the noun definitions to even have a semantic meaning akin to what headings, paragraphs and lists -- and at that point we're talking about some text that breaks the fourth wall... so unless you are typing out the script to Ferris Beuller's Day Off, ASIDE is probably the wrong tag. In fact it sits somewhere between ADDRESS and CENTER on the usefulness scale; ADDRESS' meaning is so specific you'd rarely if ever have a legitimate reason to put it on a site, whilst CENTER is purely presentational in meaning so it had no business ever being added to HTML in the first place. (there was a LOT of that in HTML 3.2, which is why I compare 5 to 3.2 a good deal)

Even the most generic of meanings that would fit semantics -- a temporary departure from the main theme or topic doesn't even come close to what people are misusing the tag for out of ignorance of the entire POINT of HTML. It does NOT mean "this is a sidebar" or "this should be put off to one side" since that's APPEARANCE.

As I've been saying for over a decade now, if you are choosing your tags based on their default appearance, you are choosing all the wrong tags for all the wrong reasons!

Which is entirely what I've come to expect from how it's been taught the past decade. Most of the educators teaching this stuff aren't qualified to open their mouths on the subject, and most of the people vomiting up books about it are equally unqualified to be flapping their gums about much of anything.

That's very hard for me to do at this point as HTML 5 is dragging everything back to the worst of pre HTML 4 practices. It's like a trip in the wayback machine with Mr. Peabody to 1997. The only book I've ever really recommended has even pissed itself from the 3rd edition onward thanks to adding the HTML 5 crap and effectively destroying the message of the original publication.

BUT, IF YOU CAN FIND IT, "Build Your Own Website The Right Way Using HTML & CSS" by Ian Lloyd in first or second edition is a much better start; do NOT bother with 3rd edition as it pretty well destroyed itself with the 'updates'.

Amazingly I've seen 2nd edition of that book on a number of library shelves, so I'd suggest looking there before spending money on it.

One thing I do recommend is this older reference site for HTML 4:
http://htmlhelp.com/reference/html40/

It's still one of the best organized and well written explanations of HTML I've ever come across. It takes the fancy legalese of the actual specification and turns it into plain english; it has a flat alpha index and a 'by type' section that makes it easy to find things, with fairly clear explanations. Some of it still has the "presentational markup" mentality, but it's still the best I've seen... and it makes the distinction between strict and non-strict elements.

... and like a lot of people I still say master HTML 4 STRICT before you even worry about the HTML 5 junk. If you master 4 strict you'll realize just how full of **** the majority of HTML 5 is in that it reintroduces redundancies that 4 Strict was trying to get rid of, and goes and introduces all new ones! (see the pointless section, article, nav, header and footer tags that I have zero plans to EVER use)

As a journalist, you do know what a horizontal rule is, right? The way you worded that question makes me think you misread by sentence... lemme add parenthesis mathematical style to show what I meant:

(numbered headings and horizontal rules) properly.

A horizontal rule (as you should know if you're writing professionally) is a element used as a break to indicate a change in scenery or topic without using a heading. HTML has a tag for this called <hr> -- horizontal rule.

Numbered headings (h1, h2, h3, h4, h5 and h6) are used to provide document structure by breaking the page into sections and subsections.. -- as in MEANING since HTML is NOT about what the page looks like, it's about what things ARE as not all visitors to a site are going to even be SIGHTED. An HR simply means the same thing as a numbered heading except that text describing the new section is unwanted or unwarranted. Just because the default appareance in MOST browsers of an HR is "a line across the screen" does NOT mean that's what HR means. Depending on the medium or even the layout artist for print, a HR could be a page-break, form-feed, three asterisks, a single enlarged tilde, a narrow row of hyphens, or any number of other visual indicators to say "hey, this is not part of the content before it".

Hence why things like <p> are for grammatical paragraphs, not typography. Why numbered headings divide the page into subsections and subsections of those subsections (which is why 5's <section> tag is idiotic BS), why the LI inside UL or OL are for grammatical bullet points, NOT "I want a bullet or number before them".

A subtle nuance that quite often seems lost on many people out there who have years of "experience". Educators and book/tutorial writers topping that list.

The entire concept of HTML is "device neutrality" -- the text and information passed in the markup should be useful to users regardless of what they are accessing pages with; in TBL's day it didn't matter if that was a teletype, daisy wheel print, dot matrix print, Commodore VIC-20 with it's ridiculously tiny 22x23 text display, or the 1152x864 NeXT workstation he was sitting at when he came up with it. Today we have even more targets; Screen media ranges from 192x256 handheld to 4096x2304 desktop displays -- but it's NOT just about visual targets! Braille readers, Screen Readers (aka software that reads the page aloud to you), morse tappers (taps morse on the arm of disabled people)... or even just other types of user-agents like search engines since, well... Search engines don't have eyeballs so they could give a flying purple fish about your for screen visual layout.

Which is why if some SEO retard starts saying your layout impacts your search, they're more full of **** than Biff Tannen's 1948 Ford Super De-Luxe!!! There are only a handful of CSS properties search engines even check for, and that's things like display:none or visibility:hidden to penalize people for content cloaking.

Not JUST with padding and margins, you need to get floats involved... or the new flex-box stuff. Flex-box is really still in it's infancy and I don't suggest trying it until you are much deeper into how HTML works -- and keep in mind that if you do use flex older browsers (IE9/earlier) have ZERO support for it, and IE9/10/edge support is still buggy as sin.

So stick to floats -- but beware floats are complex and take a good deal of effort to master.

Depends on what the image IS. IF the image is CONTENT, it belongs in the markup as a IMG tag with ALT text for people who can't see images. If the image is presentation and not part of the content, it belongs in the CSS.

Backgrounds for example rarely add anything of value or change the meaning of the content, that's why they go in the CSS. But if you were writing an article about the Somali civil war and had a picture of a 12 year old holding a AKS-74M to a 8 year old girls head while his buddies run a train on her, that would be an IMG tag. Writing an article about how to decorate a cake and have the step by step pictures? That goes in an IMG tag. You have some fancy checkmark you want to use instead of bullets on a list? That's CSS.

There is a middle-ground with things like icons. Take a set of social media links, most of the time you just want the icon, but you also want it useable for people without images AND as they are on every page and similar in colour spectrum you can get better optimization with the incorrectly named "CSS Sprites".... or let's say you have your H1 (the heading under which everything on the page is a subsection) that you want to have a graphical version of the title/text -- In those cases, you put the text in the markup and use positioning to place the image from the CSS over that text. Images off the text (Which you can then style) appears, images on you get the image instead of the text. It's called "image replacement" the most useful method of which is referred to as "Gilder-levin".

That might seem boring, but floats are very quirky and there's a lot to cover with their behaviors so pay attention to that. Floats have been the preferred method of making columnar layouts for close to 18 years, and with flex still being a cross-browser train wreck that's unlikely to change in production code any time soon.

Concepts like float clearing, float wrapping and preventing float de-indent being the most important things you can learn in making a layout! Sadly there are also a lot of outdated methods still in use like "clearing div" or the "clearfix" asshattery. Someone mentions those as something to use, they probably don't know enough to be advising you on how to do things.

If I have time later I'll write up a quick blurb for you about floats that will condense 90% or so of what you need to know into a quick read.

No shame to that. As I said for where you are in the class even with the problems you're pretty deep into it and likely way ahead of where your classmates will be even when the class is finished.

Hell, much to my shame my first website was built with Nyetscape Composer back in '97. We all have to start somewhere.