h1 aligned right, and I can't move it left

Hello!

I can not understand why <h1>Welcome to Our Website!</h1> is aligned right, there are no margins, paddings and positioning, etc. I do not understand why it sticks right. Please, help! It should be on the left.

Full code http://codepen.io/maxwl/pen/MwyxLN
HTML http://codepen.io/maxwl/pen/MwyxLN.html
CSS http://codepen.io/maxwl/pen/MwyxLN.css

 

It's because the div with the class mainContent is floated right and doesn't have a specified width. This will make the h1 appear to the right as long as it's the element with the 'biggest' width in that mainContent. One way of solving that would be changing the order of mainContent and sidebar and remove the float:right.

<div class="contentWrapper">
  <div class="sidebar">...</div>
  <div class="mainContent">...</div> <!-- remove the float:right for mainContent in your CSS -->
  <br class="clear">
</div>

Code (markup):

Others will likely going to tell you that you should change even more stuff in your HTML structure (like not using any 'clear' elements). And they are right, but I'm not going into that since that has nothing to do with your question.

 

Thank you, but you can not do that. The page layout will be broken. The mainContent should be floated right to keep that div right.

I cooked the page layout in accordance with the book "CSS3: The Missing Manual" by David Sawyer McFarland. What have I done wrong? May be I misunderstood something?

 

Then just set the width of mainContent to 520px or the like.

 

the class mainContent is floated right and doesn't have a specified width - I did so as McFarland recommends it:

"Avoid setting a width for the main content div. It’s not necessary, since browsers simply expand it to fit the available space. Even if you want a fixed-width design, you don’t need to set a width for the main content div, as you’ll see in the next section"

changing the order of mainContent and sidebar - sidebar is under the mainContent is made on purpose. And again McFarland:

The order of the < div > tags in the HTML may not seem like a big deal until you try to browse the web page without CSS, which is the case for many alternative browsers, including screen readers that read a page’s content aloud to visually impaired visitors. Without CSS, all the sidebar material (which often includes navigational elements, ads, or other information that’s not relevant to the main topic of the page) appears before the content the visitor came to read in the first place. The inconvenience of having to scroll past the same sidebar content on each page will turn off some visitors. Furthermore, your page is less accessible to vision-impaired visitors, who have to listen to their screen readers read off a long list of links and ads before coming to any real information. And if that doesn’t sway you, you’ve got the search engines to worry about. Most search engines limit the amount of HTML they read when searching a site. On a particularly long web page, they simply stop at a
certain point — possibly missing important content that should be indexed by the search engine. Also, most search engines give greater value to the HTML near the beginning of the file. So if you’re worried about getting good placement in search engine results, it’s in your best interest to make sure the important content is as close as possible to the top of the page’s HTML code

 

That's simply wrong. It would be the case if you had enough text in there or an element that fills the width.
I gave you the 3rd 'valid' solution now (even if just adding enough text is a very bad approach in your case).
Take one or wait until someone else is trying to help you. This is getting silly. I'm done here.

 

If you are convinced that the book "guru" you are odediently following is correct why are you asking mere mortals like us how to solve the problem. The recommendations and ideas in the book are not wrong; but they are also not right and the way it is presented results in bad advice the description of how a crawler works is out of date. the problem with using books to do web sites is that the time involved between writing and publishing means that by the time you get the book it is 2 year ideas in an are of technology where anything more than 6 months old is approching its "best before" date. If I was you I would throw the book in the garbage, and learn by doing, instead of looking for some rigid "Holy Grail" solution to fit all situations. But what do I know compared to Gods who write books; I have only been programming for 50 years.

 

That would be correct, EXCEPT:

A floated element shrink-wraps its content, as do {display: table;} and {position:absolute;}, for example, and others.

cheers,

gary

 

Typical HTML 5-tardery, ignoring what the HTML 5 tags mean, how to use headings, and in general the markup alone shows whatever source you are learning from to be rubbish. Admittedly I say that about 99.999% of the stuff published the past six years.

Multiple sibling-level H1 (gibberish), clearing div/classes like it's still 2001, paragraph around non-flow non-content text (that really should be sub-text under the h1), fixed width design (which is mouth-breathing idiocy any way you look at it), multiple stylesheets with no media targets, etc, etc...

... and of course codepen pissing all over the code certainly isn't likely much help either; there's a reason I won't use that crap even for just sharing code. (not a fan)

First step would be to drag that markup kicking and screaming into the light by first writing it in a logical order WITHOUT worrying about layout, that would go something like this:

<h1>
	<a href="#">Canvass</a>
	<small>By <a href="#">Free CSS Templates</a></small>
</h1>
	
<ul>
	<li><a href="#">Home</a></li>
	<li><a href="#">Blogs</a></li>
	<li><a href="#">Photos</a></li>
	<li><a href="#">Links</a></li>
	<li><a href="#">About</a></li>
	<li><a href="#">Contact</a></li>
</ul>

<h2>Welcome to Our Website!</h2>
<img src="img/img03.jpg" alt="DESCRIBE THIS IMAGE!!!">
<p>
	Canvass is a free template from Free CSS Templates released under a Creative Commons Attribution 2.5 License. The photo is from PDPhoto.org. You're free to use it for both commercial or personal use. I only ask that you link back to my site in some way. Enjoy :)
</p>	

<h2>categories</h2>
<ul>
	<li>6/15: <a href="#">Donec dictum metus lorem ipsum...</a></li>
	<li>6/12: <a href="#">Etiam rhoncus volutpat lorem ipsum...</a></li>
	<li>6/9: <a href="#">Integer gravida nibh lorem ipsum...</a></li>
</ul>

<h2>archives</h2>
<ul>
	<li><a href="#">June 2007</a> (2)</li>
	<li><a href="#">May 2007</a> (31)</li>
	<li><a href="#">April 2007</a> (30)</li>
</ul>

<hr>
Disclaimer goes here

Code (markup):

Remembering that h2 means "the start of a subsection of the h1 preceeding it" just as H1 means "the heading under which everything on the page is a subsection" and HR means "a change in topic is unwanted/unwarranted" -- well, unless you get HTML 5's pointlessly redundant SECTION or ARTICLE in the mix which just piss all over the existing HTML semantics -- which is why I advise AGAINST using those elements. (along with other 5-tardery like NAV and FOOTER that too serve no legitimate purpose). The SMALL inside the h1 says it's all the same header, but that part gets "de-emphasis", the reason in professional writing text in a header is 'smaller'. (remember, B, I and SMALL have the semantic meaning of what they would be used for in professional writing, and NOT that you actually have to convey it that way, hence why B, I, EM and STRONG all have different meanings -- you aren't emphasizing a book title!)

This gives a clean baseline for non-screen or non-CSS devices with ALL the semantics the page needs. Hence why any additional tags should be semantically neutral containers like DIV and SPAN.

Given the menu should go before content, and it's likely we'd want to show/hide it, but you want it as a two column layout, you need the left-right-left negative margin layout trick -- likewise I'd make it a flex-box min-height layout so the footer is pushed down. To do that we'll need an outermost wrapper (I call it #top so you can target it via the URL if desired) to flex-grow pushing the footer down, an inner wrapper to go around the columns, two wrappers around the content so we can do the left-right-left trick while staying fluid, and of course a div around the footer. We don't need the FOOTER tag, that HR already says that. I'd probably add some .subSection DIV around the 'extras' (I don't actually call anything "sidebar" since on some layouts it won't be a sidebar!) just to make styling easier and/or more consistent, and give those ID as well to again be targeted via hashes in the URL if desired. (handy if you want to add an accesskeys or mobile skip navigation). A inner widthWrapper inside #top would then let us set our semi-fluid and elastic widths, as well as hooks for responsive design.

<div id="top"><div class="widthWrapper">

	<h1>
		<a href="#">Canvass</a>
		<small>By <a href="#">Free CSS Templates</a></small>
	</h1>
	
	<div class="columnWrapper">
	
		<ul id="mainMenu">
			<li><a href="#">Home</a></li>
			<li><a href="#">Blogs</a></li>
			<li><a href="#">Photos</a></li>
			<li><a href="#">Links</a></li>
			<li><a href="#">About</a></li>
			<li><a href="#">Contact</a></li>
		</ul>
		
		<div class="contentWrapper"><div id="content">
			<h2>Welcome to Our Website!</h2>
			<img src="img/img03.jpg" alt="DESCRIBE THIS IMAGE!!!">
			<p>
				Canvass is a free template from Free CSS Templates released under a Creative Commons Attribution 2.5 License. The photo is from PDPhoto.org. You're free to use it for both commercial or personal use. I only ask that you link back to my site in some way. Enjoy :)
			</p>	
		<!-- #content, .contentWrapper --></div></div>
		
		<div id="extras">
			
			<div id="categories" class="subSection">
				<h2>categories</h2>
				<ul>
					<li>6/15: <a href="#">Donec dictum metus lorem ipsum...</a></li>
					<li>6/12: <a href="#">Etiam rhoncus volutpat lorem ipsum...</a></li>
					<li>6/9: <a href="#">Integer gravida nibh lorem ipsum...</a></li>
				</ul>
			<!-- #categories.subSection --></div>
			
			<div id="archives" class="subSection">
				<h2>archives</h2>
				<ul>
					<li><a href="#">June 2007</a> (2)</li>
					<li><a href="#">May 2007</a> (31)</li>
					<li><a href="#">April 2007</a> (30)</li>
				</ul>
			<!--- #archives.subSection --></div>

		<!-- #extras --></div>
		
	<!-- .columnWrapper --></div>
	
<!-- .widthWrapper, #top --></div></div>

<div id="footer">
	<hr>
	Disclaimer goes here
</div>

Code (markup):

Gimme a few and I'll toss together some CSS and a live demo of that to show you how I'd be approaching your layout.

 

... and here's that rewrite:
http://www.cutcodedown.com/for_others/maxK/template.html

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

Is wide open for easy access, I made a non-CSS copy of the markup in there as well as the semantic baseline.

I'm out the door for a while, but when I get back I'll write up a breakdown of the CSS so you can understand the how/what/why of the choices made, in particular how/why it's a semi-fluid elastic responsive layout.

Originally I was going to pull the show/hide menu stunt with it, but honestly you don't have enough menu items to waste time or code on that.

 

First off let's break down the markup.

I condense the doctype, html, head and charset meta to a single line, as well as the close of head/open of body and the close of body and end of HTML not so much to save on characters, but as a reminder that the page should ALWAYS have those elements and that nothing should go between those elements. Remember the doctype should ALWAYS be your first line with NO whitespace before it, and the charset meta really should be the first thing after you open HEAD.

The viewport META tells mobile browser we now what the *** we are doing and to stop lying to us about screen resolution and not to dick with the default zoom. There are other properties that some people set there, but those break zooming. Some say you don't have to do the height there, but many android 4.x phones will start lying about width in landscape mode if you don't set that.

Notice that the CSS LINK uses a media target. I NEVER write my CSS in my markup becuase apparance customization has NO FREAKING BUSINESS THERE!!! If your editor is worth a flying purple fish it will support multiple windows, and generally it's easier to have your style in a separate window so you can look at the CSS and HTML side-by-side.

The rest of it is pretty much what I discussed before -- a #top wrapper for flex-box to push the footer to the bottom on modern browsers, with a widthWrapper inside it. In theory we could use just one DIV for this if IE's flex implementation wasn't utter and complete rubbish.

The h1 is the heading under which everything on the page is a subsection, with small providing de-emphasis of the sub-text.

.columnWrapper is there to contain floats and for hooks like that 1px border you had.

#mainMenu is just the menu, YAWN.

The double wrapping .contentWrapper + #content is there for our left-right-left semi-fluid layout. I make the inner one a ID so it can be targeted by JS or by a hash in the URL if desired.

#extras is just the second half of the side column. It's broken into subsections and they all get Id's for targeting purposes should we want that in the future.

Be it content or subsections they are all sibling-level subsections, so they all start with a H2. "Categories" and "Archives" are NOT subsections of "Welcome to our website" which is why making the content header a H1 makes no sense... just as demoting the .subsecton headings to H3 would make no sense.

Think of a newspaper; just because "MAYOR CAUGHT TAKING MILLIO DOLLAR BRIBE" is the main headline in massive bold text, that does NOT mean that "WOMAN RAPED AND BEATEN IN ALLEY" and "K-6 GET NEW BUILDING" are subsections of that article. Unless that's one really jacked up town... The size is presentation, NOT heading level. Again if you choose your tags based on their default appearance, you are choosing all the wrong tags for all the wrong reasons.

div#footer gets a div since we use a HR to semantically say this is a new subsection... the DIV is there for style, not semantics.

Which is why NAV, ARTICLE, SECTION and FOOTER are pointless idiotic redundancies introduced by WhatWG out of ignorance on how to use HTML properly.

Also notice my commenting style... I don't need to say "start" becuase duh, that's what the <div> is for, likewise using meaningful ID's and classes means we don't need to say what we are starting. With closing DIV I like to say what I'm closing, using the CSS notation for that. I don't say "end" or "closing" becuse duh, that's what </div> means. I put the comment before the closing tag both for clarity and becuase comments between sibling-level elements can trip rendering bugs in legacy IE and some builds of FF. It's just a good habit to get into and the handful of bytes needed in both formatting and comments should NOT have a significant impact upon speed or performance -- and if it DOES, you've probably done something horrifically wrong. (see bootstrap and other HTML/CSS frameworks, along with presentational markup)

... and that's the markup.

On the CSS side, follow along with:
http://www.cutcodedown.com/for_others/maxK/screen.css

I always start out with a reset -- I use a monolithic stylesheet (single file) for each media target as every handshake has a speed penalty, so the more files you use the slower the page REGARDLESS of connection speed.

Resets exist because you CANNOT trust the default margins, paddings or borders to be the same across browsers. There are smaller resets like the so called 'universal reset' of "* { margin:0; padding:0; border:0; } but thanks to IE and FF being retards about elements like INPUT, SELECT and TEXTAREA that can lead to major headaches getting those to appear the same.

There are larger resets like Eric Meyer's "reset reloaded" -- but that fat bloated train wreck does more harm than good and borders on being a framework unto itself! Resets like that are what gives resets a bad name and why many in the industry would rather waste massive amounts of time cross-brower testing and manually saying it every time it's needed rather than even TRY using a reset.

The one I use (designed by Dan Schulz some seven or eight years ago) is small (under a quarter of a K), efficient, and targets JUST the elements we 'need' to worry about. It's the perfect middle-ground.

hr -- since these are for semantics and do NOT mean "draw a line across the screen" (even if that's the default appearance) we hide them for screen media targets.

-text-size-adjust -- these two vendor specific properties are much like our viewport meta, telling mobile browsers to leave our fonts the **** alone! -- thankfully the devices that need this stopped being made larger than 480px, so we can put this into a media query to stop it being used on larger displays, since for some jacktard reason if you send -webkit-text-size-adjust to desktop Safari it breaks zooming, even though it does NOT break zoom on mobile Safari. :/

html, body -- I set the 100% height so we can do our flex-height properly to push the footer to the bottom. You have to remember that by default both shrink to the content size, and if an element's parent does not have a height specified on it any declared height is ignored.

body -- the min-width is for older browsers that can't swap out the columns, preventing the layout from breaking but forcing users on older crappy browsers to scroll. It's an "OH well" solution but more than adequate.

You'll notice I declare the font-size in %, percentages of font-size are based off the parent element, and in the case of BODY that means the browser default size. Across the entire layout I declare everything like widths, margins and paddings in

Finally in there we declare BODY as a flex-box; sadly flex is still very new and a lot of browsers (ok, two browsers, webkit and IE) need the vendor specific properties to pull it off. This basically tells modern browsers that the content of our page should stretch to the height of the window when the content is shorter than the window height.

a; a:pseudostates -- set up the anchor behavior for most of the page. Your colour choices were fine, I added a transition to the color just to make it a bit prettier. Notice I target :active, :focus and :hover for this. That is so people using keyboard navigation aren't left out in the cold -- technically keyboard nav should be responding to :focus, but some older browsers incorrectly use :active (aka it's been clicked on) for the keyboard state instead. :/

#top -- first an overflow state to wrap floats and margins means we can margin-bottom child elements without flex-overflow kicking in. (a cousin of margin overflow that can drive you nuts). IE10 / newer won't properly shrink the width of a flex-box (aherpaderp) if no width is set, so we max-width this to force the issue. We then set up the flex-box behavior telling #top to grow to fit the available space -- boom the footer is pushed to the bottom and no further code is needed for our flex behavior. In THEORY we shouldn't need align-self or the old vendor specific -flex-item-align, but again IE and Safari lag horribly on proper implementation.

.widthWrapper -- forces our maximum width so that our layout is semi-fluid; automatically expanding and contracting without our paragraphs of content getting too long to follow. Simple padding at the sides makes it pretty at desktop sizes, with margin to center it.

* html .widthWrapper -- the comment pretty much describes this. REALLY old IE can't do min or max-width, so force it to a crappy fixed elastic width; at least it's elastic (based on the font-size).

#footer -- padding all around, centering, colouration. No need to get fancy on this as everything else handles pushing it around.

h1, .columnWrapper -- both of these need float wrapping behavior.

h1 -- here's some funs stuff, first I push every inline/flow to the right, and set up that nice big font-size. Again, font based in % and margin in EM so it's based off the browser default. I went with segoe-ui since you seemed to be using just "sans-serif" on those instead of arial, and for Vista/newer that's the default.

Notice I used the full condensed property as it's just easier to declare and see everything that's going on that way.

h1 a -- float the anchor left, strip off the underline and set the color...

h1 a:pseudostates -- do NOT show underline on hover with these. (overriding global style)

h1 small -- some side padding to make it impossible for the two texts to overlap each-other, then shrinking the text to 25% of that 400%, resulting in our original default text size.

h1 small a -- the anchor inside the small we don't want floated so turn that off, then increase the fonts-size again. I could have used the adjacent sibling selector h1>a to set the float instead of unsetting it, but legacy browsers don't know ">" so it's more compatible this way.

The thing to remember about %/em font sizes is they are based on the size of the element's parent... so if we started with the normal default of 16px, h1's 400% is 64px, h1 small's 25% is 16px (64 * 0.25), and h1 small a at 150% ends up 24px... Of course since the default on my workstation is 20px instead of 16px, and my media center is set to 24px instead the entire layout will auto-scale without having to dick with the zoom on such machines! That's the "elastic" part of doing a proper design.

.columnWrapper -- I set up relative positioning to use generated content to make the dividing 1px border between columns. This technique is known as "Faux columns" and is a simple but reliable way of doing it consistently across all browsers. I margin the bottom to push the footer away from the border (which will work thanks to the overflow state on #top - if we lacked that overflow it would behave as padding on #footer due to margin overlap), then set the border.

.columnWrapper:before -- I use a space instead of empty content for this generation so that IE7 behaves, then absolute position this div. Using :before means that anything relative or absolute positioned after this in the DOM will depth sort over this generated area so we don't have to dick with z-index.

#mainMenu -- turn off bullets, relative position to depth sort over that generated content and .contentWrapper (we'll explain the latter shortly), float it left, set an elastic width and pad the bottom to push the rest of the sidebar away from it.

#mainMenu li -- I set these to inline so that when we make it responsive it's easier to strip the columns off, and so that IE's oddball "height grow" bug doesn't rear it's ugly head. Good rule of thumb with LI on things like menus is to set it to inline and avoid styling it if at all possible.

#mainMenu a -- which is why we use the anchor for all our styling. In this case simply setting it to block, padding and adding border handles it all nicely.

h2 -- all our headings basically get the larger text. IF you change the font-size change the line-height as you cannot trust it to inherit properly. There is a LIE being circulated that if you omit the metric and just said "line-height:1.2" it would work -- only does so at the default font size and even then in only two modern browsers... You change font-size, change the line-height. Since the font-size is 150%, 0.33em bottom padding is roughly the same as 0.5em at the normal size.

I like to use 125% and 150% for the reason the math is easier, since 0.5 / 1.5 == 0.33, 0.5 / 1.25 == 0.4, etc...

.contentWrapper -- here's where the magic begins. 100% width and right float leaves 0 width free for anything to be next to this element, but if we make a negative left margin the element becomes "smaller" in how it reports it's "flow" -- aka how other elements should position around it. This slides .contentWrapper up underneath #mainMenu.

#content -- which means we just do a positive margin-left to push the #content inside it out from underneath #mainMenu.

#extras -- relative positioning for proper depth sorting, clearing left makes sure this doesn't try to ride up next to #mainMenu, floating it left makes it ride up next to .contentWrapper, and again it gets the same width as the rest of the column.

BOOM, menu left, content right, rest of the column left in that code order, so that your logical document structure is maintained.

.subSection -- simple padding. Not really getting fancy with these in this layout.

.subSection ul -- turn off bullets, yawn.

#content img -- set a max-width so that the image will be forced smaller if the layout becomes too narrow for it to fit full size.

... and that's the full size desktop layout. Now for more fun, the media queries to make this layout responsive by stripping off columns.

Don't know if you've learned about media queries yet, but basically the rule I use the most is max-width which means "if the screen is bigger than this, don't apply these rules". So if the screen is smaller than the size declared, these will be used to override the styles we just declared.

max-width:48em -- first thing we do is override the min-width we set for non media-query capable browsers. Realistically we shouldn't need to target anything smaller than 192px wide. I lower the padding on #top since we have less space available, and shrink the H1 text for the same reasons. Killing off the floats and making the header go to multiple lines with display:block.

Stripping the floats, widths and margins off #mainMenu, .contentWrapper, #content and #extras removes our fancy columnar layout, while adding padding and borders to #mainMenu, #content and .subSection makes it 'pretty again'.

I kill the outer border and generated content since those really aren't needed when there are no columns, and re-arrange the menu to go across the screen word-wrapping normally. Thankfully the paddings used above are big enough they are 'finger spaced' apart so it will be usable on a touch interface.

with #categories I float it left with some right padding so that #archives can ride up next to it. You MAY want to set a max-width on it, but that would hinge on how you are generating the content for those elements. I set overflow on #archives so should that be taller than #categories it will NOT ride under it, and I align it right to make the two columns more defined.

max-width:28em -- we get down this small we kill off the #extras .subSections being two columns by stripping the float off #categories, and tweak it to be pretty by setting the text-align to center on both of those subsections and the headings.

... and that is basically how it most likely should be done. Semi-fluid elastic responsive layout with gracefully degrading semantic markup that delivers content in a useful manner even to people with CSS off or where screen layout is inapplicable... aka the entire reason HTML even exists in the first place.

Hopefully you can learn from that; I know it's a lot to take in, so any questions fire away.

 

It solves the problem. But it will not work unless you do not remove margin-left for .mainContent.

And I do not want to change the order of mainContent and sidebar and remove the float:right, as I want mainContent to be on top of the sidebar. But this is also a valid solution (in accordance with the book).

 

Thanks a lot to all of you guys!!!