Re-code to get rid of Absolute Postioning?

hello...

In my designs, I almost always create a Parent Layer (div)...w/ relative positioning; & w/ a margin of '0 auto' so it remains centered on the page (since I almost always use background images)...& then my other divs (nested inside the parent) are always positioned absolutely...the code of which would look something like this:

<div id="Layer1" style="position:relative; width:840px; height:2500px; margin: 0 auto; background color: #FFFFF; layer-background-color: #FFFFFF">
  <div id="Layer2" style="position:absolute; left:0px; top:0px; width:840px; height:222px; z-index:1; background-color: #00CCFF; layer-background-color: #00CCFF; border: 1px none #000000;"></div>
  <div id="Layer3" class="style1" style="position:absolute; left:0px; top:50px; width:840px; height:136px; z-index:1">
  <div align="center">TITLE</div>
  </div>
  <div id="Layer4" style="position:absolute; left:0px; top:250px; width:440px; height:380px; z-index:1"><img src="SomePhoto.jpg" width="440" height="380"></div>
  <div id="Layer5" style="position:absolute; left:300px; top:720px; width:460px; height:330px; z-index:1">Some Text </div>
</div>

HTML:

...with a result similar to this:

http://www.moonjams.net/EXAMPLE.png

So...I'm not a pro coder by a long shot...I design like a graphic illustrator would in laying out a magazine page...but...given the fact that I've been told never to use Absolute Positioning (on the Child divs inside the Parent), how would I now re-code that page (using I'm assuming CSS thrown in w/ the HTML) so that it looks like that until the browser gets resized...& then all the elements flow correctly, stacking the way they're supposed to...left to right, top to bottom...WITHOUT USING THE DREADED ABSOLUTE POSITIONING...???

[btw...not asking to have my work done for me...but if someone could please provide just a short code example using a couple fictitious image blocks, I would be appreciative...OR...direct me to an informational on the web detailing exactly how to do it...thanx].

thanx,

dox

 

Instead of giving you the code, I would refer you to bootstrap's docs for their grid here https://getbootstrap.com/docs/4.0/layout/overview/ and their docs for positioning here https://getbootstrap.com/docs/4.0/utilities/position/ as well as how to offset blocks here https://getbootstrap.com/docs/4.0/layout/grid/#offsetting-columns

Barring that, I would use margins and paddings on the elements combined with breakpoints(media queries) for flow on smaller devices. This will let you relative positioning with the assumption that the body elements is always absolutely positioned

 

Both your question AND your methodology are flawed. What you are trying to accomplish for a layout is NOT good web design by a long-shot and a half.

This is apparent from the fact you are even THINKING in pixels and elements with fixed heights. Pixels are non-elastic, they do not adjust to the browser or OS font size which the user can change. That's why we're told to use % or EM for font-size and as such any containers with CONTENT in them (aka text) would/should ALSO have their widths (if any) declared in EM.

In that same way your containers should be at least semi-fluid. Auto expanding/shrinking as needed to contain their content, with a max-width to prevent long lines from being hard to follow. Declaring a fixed width or percentage of screen width is garbage.

That you're screwing around with DIV -- including one for what is clearly the document H1 -- isn't helping matters. CONTENT dictates markup which is why you should be starting out with your content or a reasonable facsimile of your future content FIRST in a flat text editor, organizing it logically as if HTML and layout doesn't even exist. Then you add HTML to semantically (no DIV or SPAN at this point) say what things are, NOT what you want them to look like. THEN you bend that markup to your will with CSS adding DIV and SPAN only where and as needed once you've expended what can be declared on the semantic elements.

It's called progressive enhancement and is how you create accessible websites that gracefully degrade. Starting out dicking around with the appearance before you have that is utterly back-assward, and is why the PSD jockeys under the DELUSION that they are "web designers" are at best nothing more than ignorant, at worst a bunch of sleazy scam artists.

As to placing things generally as you ask, why aren't you just leaving them in flow and using margins or padding to space them apart. What makes you even think in absolute positioning terms in the first place. You're not even placing anything side-by-side so you don't even need floats!

You have an H1 for the heading, a P for the text related to the heading, more P for the text that follows, an IMG, more P, then an IMG. Group them by DIV with classes or ID's to say what those sections ARE not what you want them to look like, then position and style them from your EXTERNAL stylesheet.

Since style="" is also epic /FAIL/ at web development and should only be used when the style helps convey meanings -- such as font-size on a tag cloud or the width of bars in a bar-graph. Otherwise do NOT use that.

Do NOT declare fixed heights, do NOT declare fixed widths. That is where you are failing. Let flow do its job!

Also, well...@kennedygitahi suggested bootcrap and, well... the only thing you can learn from it is how NOT to build a website. I would advise you learn to use HTML and CSS properly BEFORE you try the sleazy half-witted shortcut that pisses on good practices from orbit. You do so and you'll realize just how mind-numbingly dumbass HTML/CSS frameworks like bootcrap, w3.css, etc, etc, really are.

 

deathshadow...

Everything here? Gibberish. & that's certainly no reflection on yer skills, which are obviously multitudinal & magnificent...it's that I can't understand most of it. You can poke fun of the way I design [& the old-fashioned code method I actually learned (I now know to be incorrectly) from DW 2004 (WYSIWYG-type web design software)]...have at it...but the truth is, I do not have the time to now go back & learn 'progressive enhancement' or 'flex box' or 'stack overflow' or any of it. I have graphic illustrator & some IT skills; & a good eye (& no time in my life)...period. I would be immensely grateful if you could simply mark me up a quick code example (I could fit between body tags), based on my example image...whereby if I pasted it into my web design software it would look reasonably similar to that image...& whereby I could then manipulate that code w/ my own images & text...& thereby complete the website I am designing for my local area of NA...& also learn by doing, which would be a greater help to me in the long run.

thanx,

dox

 

Then you are NOT actually interested in doing this. You're going to have to learn SOMETHING more than what you already know.

Let's start with those terms by defining them:

1) progressive enhancement -- adding parts of the puzzle from content to markup to CSS to scripting one after the other so that should any of those parts go missing or be inapplicable the website is still useful to the visitor. It is the cornerstone of accessible development.

2) flex box -- a modern CSS layout technique, best used for handling sticky footers and complex columnar layouts. You don't have columns so there is ZERO reason to use it for this layout.

3) Stack overflow -- either a low level programming concept, or a very poorly maintained programming information website. I would ASSUME you mean the latter. That you even mentioned it suggests that you may have gotten bad or even inapplicable advice asking elsewhere. (lemme guess, Sitepoint? I see you also posted this over on CodingForums to no response yet. Some people will give you s*** for cross posting the same question multiple places -- f*** 'em! More answers and more eyes on target is a good thing.)

Wasn't meant to poke fun, but to try and explain that your layout methodology is conceptually flawed... You actually said a LOT of your problem here:

Magazines are a fixed size, websites are NOT. There's a saying we used endlessly over a decade ago as 'graphic designers' came from print to the web: "The web is not print!". If you are coming from that mindset, you need to forget EVERYTHING you THINK you know about layout and design.

Websites are supposed to and generally need to be three things:

1) Fluid -- this means adjusting to the screen width. Semi-fluid design is where you set a max-width so the layout doesn't grow large enough that long paragraphs are hard to follow. You should be building that way instead of setting a fixed width.

2) Elastic -- using the EM or % font size which inherits off the parent element, and in the case of BODY inherits off of the browser or OS default. This allows the entire layout and page to shrink and grow with the font-size, something pixels do not bring to the table. A lot of people will say it's always 16px as the default -- which led to the "62.5% = 10 pixels" LIE -- generally such people are talking out their arse.

3) Responsive -- using media queries to re-arrange the layout to best fit a shrinking screen-size, or to better use availabel space on larger displays. Typically this involves adding/removing columns, excess presentation, and so forth.

You're not going to get that saying "well I want the outer container 840px wide".
You're REALLY not going to get that declaring fixed heights on anything!

NOR do most of the garbage "web design software" out there provide it, which is why universally be it Dreamweaver, the artist formerly known as frontpage, or half-witted scams like Wix/Weebly are NOT design tools no matter how many scam artists and nube predators try to sell you on the idea. The MOMENT it has a WYSIWYG it is universally garbage vomiting up garbage results.

If you ACTUALLY want to 'learn by doing' you're going to have to grab a flat text editor, and learn to use HTML and CSS PROPERLY -- not take the sleazy mentally enfeebled shortcuts that ALWAYS result in broken toy-like rinky trash.

Now, all that said, gimme a few minutes and I'll belt out a working example and then I'll document it section by section to explain the choices made, so you can read through it and understand the how/what/why of what I did. I used to do two or three of these a week, but lately the audience of people ACTUALLY willing to learn to do things properly has evaporated in the face of sleazy dirtbags peddling lies.

 

Alright, first up the HTML:

<!DOCTYPE html><html lang="en"><head><meta charset="utf-8">
<meta
	name="viewport"
	content="width=device-width,height=device-height,initial-scale=1"
>
<link
	rel="stylesheet"
	href="screen.css"
	media="screen,projection,tv"
>
<title>
	[Page Title - ]Site Title
</title>
</head><body>

<div class="widthWrapper">

	<div id="top">
		<h1>Page Title</h1>
		<p>
			Description Text
		</p>
	<!-- #top --></div>
	
	<!--
		using DIV around paragraphs on the assumption they might have
		headers or multiple paragraphs
	-->
	
	<!-- in production DESCRIBE what this text *IS* for the class -->
	<div id="firstTextSection">
		<p>
			Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut tincidunt lacinia magna at cursus. Maecenas non sagittis urna. Aenean tempor justo a ex fringilla, a sagittis eros pharetra. Aenean a mi pretium urna dapibus pretium. Mauris volutpat iaculis lobortis. Morbi at nisl quis sem varius fermentum eget et metus. Suspendisse cursus nec lorem eget scelerisque. Fusce posuere vestibulum enim, ac semper risus vehicula eu. Ut cursus risus id ex feugiat mattis. Proin tempor tempus diam sed gravida. Cras tempus magna ut scelerisque cursus. Ut blandit sagittis ante, id malesuada massa volutpat eu. Vivamus rhoncus nec odio tincidunt rhoncus. Integer varius massa id vehicula volutpat. Interdum et malesuada fames ac ante ipsum primis in faucibus. Nulla sit amet nisl ut leo fermentum gravida facilisis vel risus.
		</p>
	<!-- #firstTextSection --></div>
	
	<img
		src="images/placeholder_3_2.png"
		alt="placeholder image"
		width="300" height="200"
		class="plate"
	>
	
	<!-- in production DESCRIBE what this text *IS* for the class -->
	<div id="secondTextSection">
		<p>
			In hac habitasse platea dictumst. Proin ullamcorper, metus ac laoreet interdum, turpis nisl posuere nibh, a sodales enim orci maximus metus. Proin non fermentum mi, nec imperdiet velit. Maecenas semper id magna id faucibus. Maecenas non arcu et nulla condimentum consequat. Phasellus eleifend libero vitae purus convallis finibus. Sed tincidunt leo urna, in condimentum neque dapibus nec. Interdum et malesuada fames ac ante ipsum primis in faucibus. Nulla sed porta diam.
		</p>
	<!-- #secondTextSection --></div>
	
	<img
		src="images/placeholder_3_1.png"
		alt="placeholder image"
		width="300" height="100"
		class="endPlate"
	>

<!-- #top --></div>

</body></html>

Code (markup):

I condense the doctype through charset meta to a single line as a reminder that these elements MUST appear in this order, with NOTHING else pasted in-between them. I condense </head><body> and </body></html> for the same reason. It's just a helpful reminder to not cock it up.

The viewport META exists to tell mobile browsers we know what we're doing. There are other values other folks set like maximum-scale -- those people are morons. Setting any other values breaks the ability to zoom on mobile, telling such users to go f*** themselves. Good rule of thumb? Don't tell visitors to your websites to go f*** themselves. If we do not declare the values I set, mobile devices will lie (more) about their actual resolution screwing over our style, and apply their own random zoom values.

Mobile browsers do this to deal with websites built before CSS3 and responsive design existed. As we are building anew, the viewport META lets them know we're doign it right.

The stylesheet link puts our style into an external file WHERE IT BELONGS and only targeting relevant screen media targets. Screen layout is usually gibberish nonsense for print, it certainly doesn't make any sense for aural, which is why when people <link> to a stylesheet without a media attribute or declare media="all" they're ignorant twaddles not qualified to write a single line of HTML.

HTML 5 validation will bitch about "projection" and "tv" -- f*** 'em! There are plenty of devices still in circulation that will apply their own rules or ignore our style outright if we don't include those! (realistically the actual valid values in media="" is none of the HTML specifications business, but HTML 5 has a lot of derptitude like that!)

Hopefully I dont' have to explain what a title tag does. Eh, I better anyways. It exists as the title to be shown on a tab, in the window frame, on the taskbar or stacks, or as the link text on a SERP or other off-site link. That's it, that's what it's FOR. It is NOT a place to stuff a full-on description, and it sure as shine-ola is not a place to blindly stuff a ass-ton of keywords like the two-bit half-wit black-hat SEO scam artist dirtbags do.

In case you couldn't guess, there are a LOT of predatory dirtbag scam artists out there who will try to pack you full of manure. Many of them run allegedly 'professional' websites like W3Schools or stamp out any dissension to maintain their own little echo-chamber of suck-ups and sycophants like Sitepoint does.

I use the code notation of brackets to indicate 'optional' as a reminder that the contents of the title tag should follow that pattern AND NO OTHER. Optional current page name, a hyphen, then the site title. Nothign more, nothing less. (It's scary how many people screw that up!)

Close the head, open the body, on to our content. This follows something I said in my first reply:

DIV.widthWrapper is the outer container to set the width constraint. I call it widthWrapper to say what it is going to do, without saying WHAT SPECIFIC WIDTH it is setting. It might be setting none. Again, WHAT it looks like has ZERO business in your HTML in all but the rarest of corner-cases, which is why the <style> tag shouldn't even EXIST, and style="" should be avoided unless that style conveys meaning. (a very rare situation)

DIV#top wraps our header and description text. I call it #top since it's the first element, and if later on you want to add something like <a href="#top">Back to Top</a> it becomes a no-brainer to implement.

Inside that are the h1 as "the heading that everything on every page of the site is a subsection" -- what H1 MEANS! H1..H6 do not mean "text in different weights and sizes", they mark the start of sections and subsections. Which is why HTML 5's SECTION tag is a pointless redundancy!

Then a paragraph for the description text... assuming it's a grammatical paragraph and not some other form of content. Sadly saying what the ACTUAL markup should be is impossible since you've shown no content, and starting with the content or a reasonable facsimile of future content should be your starting point BEFORE you even write a single character of HTML. That's why starting out with a picture is a back-assward approach to design, and is in fact not design at all -- no matter how many PSD jockeys under the DELUSION they are "web designers" will claim otherwise.

DIV#firstTextSection and DIV#secondTextSection both should have names to describe what their content IS. Again, why we kind-of 'need' content and context to declare our HTML properly. Without the content most of this markup is nonsensical wild guesses. I used DIV to wrap the P instead of targeting the placeholder paragraphs on the assumption that real content sections might have their own headings or multiple paragraphs.

The two images are pretty vanilla -- their native widths and heights declared in the markup to speed render when CSS is not being applied, but with classes on each to declare how we place them. If you're coming from print can I assume you know the difference between a plate, startPlate, endPlate, leadingPlate, and trailingPlate? In this case they are clearly a plate and a endplate and not leading/trailing since you don't have text riding up next to them.

... and that's really all the HTML should be. Lemme toss together some style for that, I'll put it up live on my server, and then write a breakdown of the CSS.

Laugh is, these breakdowns of the code always take longer to write than the code itself.

 

alright, a live copy is here:
http://www.cutcodedown.com/for_others/mark4man/template.html

As with all my examples the directory:
http://www.cutcodedown.com/for_others/mark4man/

Is wide open for easy access to the gooey bits and pieces -- feel free to look around.

Let's break down the CSS, follow along with:

http://www.cutcodedown.com/for_others/mark4man/screen.css

The first thing I have in every stylesheet is a "reset". These exist because the default appearance of HTML elements is actually NONE of HTML's business... there's no such thing, as such browser makers in the early days all went their own direction. This was on purpose, though it would take a bit too long to explain the how/why of that right now.

Bottom line, the padding, margins, and borders of certain elements are inconsistent cross browser, a reset puts them all at zero so you know where you're starting from.

There are smaller resets, but those can screw up form elements. There are larger resets that border upon being frameworks unto themselves, but these are what gives resets a bad name (to the point many developers dismiss the concept outright JUST because of the crappy ones). The one I use -- developed by Dan Schulz, RIP -- is a nice safe middle ground. At a quarter K it's not so big that you can bitch about the size, and it doesn't target anything that doesn't need resets or would be screwed up by them.

After the reset I hide HR as a matter of course. HR exist to be a change in topic where heading text is unwanted/unwarranted, and NOT to just 'draw a line across the screen'. To that end in my screen media layout such meaning is usually conveyed by other means, so I hide the HR. That doesn't mean I don't use them in the HTML for their SEMANTICS.

Next is a media query targeting just devices reporting a width smaller than 480px. The two text-size adjustment values inside it are a bugfix for early iOS and Windows Embedded devices. I isolate them in a media query by width as sending them to desktop OSX resolutions can break desktop Safari's ability to zoom, even though it has ZERO impact on iOS Safari's zooming. (Way to herp that derp crApple!)

html, body I set 100% height on these as one aspect of CSS is that no element can have a height or min-height in percentages if the parent doesn't -- except for HTML. On both these tags height is treated as min-height, so we're saying the BODY should expand to screen height as the minimum. It will still grow larger if the content is taller. This is done for .widthWrapper which I'll explain momentarily.

body -- I like to manually declare the font used for the majority of the document on the body. I set a taller line-height than the default as 1) the default line-height is inconsistent cross-browser, and 2) it improves legibility. Good rule of thumb, use a sans-serif font stack for flow content, as most screen media devices lack the resolution to render serif fonts clearly. (serif improves legibility in print, but can compromise it on screens, fun stuff)

.widthWrapper -- I set overflow just to make sure any margins or floats we might use don't try to 'bust out' of this container. The max-width means this div can grow to this wide AND NO WIDER. This way it can still shrink to fit the screen. This is done in EM (a multiple of the current font size) so again the layout is ELASTIC and can grow to properly fit the content and user preferences.

The 100% min-height means if the content is shorter than the display, .widthWrapper will grow to screen height. This only works here becuase of the 100% height declared on HTML and BODY.

auto side margins centers it... and then the border.

#top -- pad it pretty. Again using EM so it is based on the current font size, not pixels so the whole thing dynamically adjusts. Since all the text is centered we center here, add a margin to push the first content text section away from things, and of course colouration and a border.

h1 -- inline-block makes our H1 shrink to fit it's content. This technically makes it display inline with other elements, but since our P will remain block it will get its own line, and be centered thanks to the text-align on #top. The padding is smaller because EM is based on the current font-size, which you can see I doubled.

You'll notice I (most) always use the full condensed font declaration. I like to see what EXACTLY is being set for face and style, and more importantly you cannot trust line-height to inherit properly. There is a LIE circulated about the past six or seven years that omitting a metric from the line-height (ex: line-height:1.5 will inherit correctly, that's bullshit. If you change the font size, redeclare the line-height. ALWAYS... and by the time you type "font-size:200%; line-height:150%;" you're at damned near as many characters as just saying the whole condensed property.

... and if gzip compression is enabled for CSS on your hosting, it actually ends up smaller. :/

#top p -- pad it all around, margin the top to push it away from the H1. Nothing fancy.

h1,
#top p,
#firstTextSection,
#secondTextSection,
.plate,
.endPlate -- I set the border on all these from one easy spot so you can quickly change or remove it from all of them. Aka the reason 'mixins' in LESS/SASS/SCSS are pointless if you understand selectors. SCSS is ANOTHER bit of BS you likely haven't encountered yet some people will tell you to use/do that's incompetent nonsense.

#firstTextSection,
#secondTextSection -- these both get the same width, half our .widthWrapper's maximum, but I set a max-width of 100% so they will shrink to fit the screen as needed. I pad the top and sides so that bottom padding can be applied to the content instead of relying on margins. I'll explain that shortly.

#firstTextSection since it's up against the left edge, I pulled its left border to just make it look nicer.

#secondTextSection I pushed this in 3em, which at default font-size on a stock system is 48px -- not quite the 40 you said but consistent with the text-size and twice the line-height, which is a good trick to get a clean consistent looking layout. Also keep in mind since this is EM it will NOT EVER be a fixed number of pixels, for example on the workstation I'm on right now that 3EM would provide 60px, and on my media center set for a ten foot interface it would be 72px.

#firstTextSection p,
#secondTextSection p I pad the bottom of my paragrpahs then pad thier container on the other three sides so as to avoid a layout headache called "margin collapse" which can result in margins busting out of their parent, or screwing up the application of backgrounds. (FF Quantum just re-introduced this decade old bug they fixed eight years ago in the old bulds. GO PROGRESS!). Margin should be used only once padding has been expended or you "need" it outside of a border where you can't do it from the parent.

.plate, .endPlate -- these two share a lot of properties in common, so again I nest them. (and again, who needs "mixins"? Not me, not me...). Display:block forces them to their own lines, the max-width will make them shrink to fit if the screen is smaller than they are, the height:auto overrides the HTML value so that the aspect ratio of the images is maintained, and again and auto-margin with a bottom margin to space them apart. (since padding is iffy on images).

.endPlate -- then the values that are DIFFERENT -- killing the auto margin on the right slides it flush with that side, then kill the side border like we did with the first text area.

... and that's the primary desktop/high resolution semi-fluid elastic layout. Now we need to make it responsive for mobile devices.

max-width:54em -- I give it a couple extra EM over the .widthWrapper size as a 'fudge factor'. A good rule is to toss an extra EM or two on your media queries so they trigger early given the measurements aren't always exact. It's better to have it trigger before it's needed than to have it accidentally not trigger when it is.

This one just kills the border on .widthWrapper since when it's flush with the sides of the window there's no real reason to have it there.

max-width:32em -- down this small we're butting heads with the indent on the second section and their widths, so just strip off the side margins, lower the side padding to make more room, and kill off the side borders so they can expand to fill the entire screen width.

... and that in a nutshell is how you do it.

Plug that into some rubbish design software, and watch it go bits-up face-down near instantly. Seriously, if you WANT to do this properly, kick that garbage to the curb and take the time to LEARN. Otherwise all you are doing is screwing yourself over.

 

Jezziz...!!!

Can I/should I pay you?...that's the most remarkable (pardon the pun) informational on the whole shebang I've ever witnessed...!!! I'll grab the code/images tomorrow; & begin to read & absorb. You have really done me a great service, man...not only did you provide the technique, you've explained it (in detail) in a way I'll be able to grasp (once I sink my teeth into it)...& not only will this allow me to finish the site I'm designing correctly...but it will help me to learn the correct methodology for the long haul...thanx a million...I am in awe & have great gratitude...!!!

dox

 

deathshadow...

something's wrong...I took the entire code & created an exact html document w/ it in my web creation software (i.e., only your code in the doc), along w/ including your placeholder images in the same html directory w/ the page file...previewed it in a number of browsers; & it doesn't look the same, at all. I even used your template.html & did the same thing. It looks like this:


what am I doing wrong? thanx,

dox

 

never mind...forgot to pop the screen.css doc in the directory...sorry...thanx

dox