again assuming… well, i’m not going to fall for that.
in short:
i say there is a case where the layout is… ugly (it’s too much, but i could not find another word for it, i’m sorry for that). not everybody will surf maximized.
mixing unorthodox css with healthy css (like <center> in otherwise good html markup) will do you no good in near future, when unorthodox css is no longer needed. a little like <center>. or css3, that you don’t like or use. the same thing. css deserves the same treatment as html.
handheld css was used just to prove a point. a bad mixing of css, like screen and print, in the same file, following your idea of hacks together with the rest, that is my point.
my points. you can justify them. i don’t have to agree. so i will come up with an example, to see if you can criticize me as well as i did
and you could make a pretty good advocate for using <center>; only now you’re defending a use of hacks. what you said about ie css hacks, could be applied very easy to make a case for using <center>. a good practice is a good practice. even if you lose some.
In other words, making the WINDOW narrower than 800px wide… which means you are seeing the CORRECT behavior. That’s what I meant when I said 800px - the width of the WINDOW, not of your desktop.
The behavior at that point being entirely consistent with what a 800 friendly fixed-width page would do. Anyone with a screen that small (like first gen netbooks) are unlikely to ever consider running the browser anything but full screen (given the number of 800 friendly fixed width sites out there), and anything smaller (like handhelds that obey screen) are designed to work with 800px fixed width in the first place (iPhone, Opera Mini, etc)
Yeah, the right gets cut off - that’s a good thing, why waste screen space scrolling too far on a small display? I just wish there was a consistent way to make the padding on the left disappear like most browsers do with the right padding on BODY.
Though if REALLY concerned about that (for christ knows what reason) lose the padding on body, and set ‘width:90%; margin:0 auto;’ on #outerWrapper.
If half a k is a lot of bandwidth… if that. Hell, my comments to explain what ones are for that are probably bigger than the code for it.
Well, let’s see… Let’s take JUST the CSS that applies to legacy IE only and delete everything else:
383 bytes. Lose the comments, it’s 258 bytes. An IE conditional comment to send the haslayouts to all versions of IE, and lose the * html to send the expression to just IE6/earlier?
264 bytes… in the markup (uncached across pages). Basically you take the comments out of the CSS, it’s less code on the first page the user visits, with the comments still in it’s less bandwidth consumed the moment the user visits more than one page on the same site. You have something like a forums or informational site like a search engine or wiki where the average viewer goes to 10+ pages inside the cache limits, you’ve saved bandwidth despite the larger CSS file… Which is why that stuff does NOT belong in the markup.
and in a 30k screen.CSS (about the largest I’d ever make for a single website) there’s no excuse to have more than 1k devoted to IE hacks… so big deal.
I’d rather “waste bandwidth” in a file cached across pages than waste space in every page of HTML I send. Optimization efforts are better placed on having less markup and leveraging the caching model.
Again, assuming language barrier because that makes no sense - not all handhelds even obey screen, so handheld rules belong in… you guessed it, the handheld.css that you target with a MEDIA type. Much less generally I don’t WANT most of the screen being used on handhelds; though yes, the new big two (webkit on iPhone/Android and Opera Mini) that people talk about (despite combined being barely 14% of the market) do use screen, nobody else does… or at least does properly. Try Opera Mobile on a N70 sometime to see what I mean… or Blazer.
no, i’m viewing the page at a 1024x768 resolution.
you want a step by step:
hit the “Restore Down” button (you know, 3 buttons on your top left/right of the window: Minimize, Restore Down/Maximize, Close).
size down your browser window until a horizontal scrollbar appears (using handlers that appear when you move your mouse pointer over the edge of your browser windows)
scroll horizontally all the way on the right. scroll back horizontally on the left, all the way. margins are not the same size.
ok, now to ie: what if ie visitors are only 5%? don’t try and feed statistics, they are a lie or a truth, depending on your point of view. than you’ve waisted a lot of bandwidth with your css. you could also put handheld oriented rules in your screen.css. it’s the same.
… and from that I’m thinking you aren’t understanding a word I’ve said.
the same goes here. if it’s my broken english i promise to make it better
i was saying i will make an example of my own for MrGeeker, to point out a different approach, a reasonable one for a newbie. maybe the example will speak a better english for me
That’s going to be the complete content of the web page. I don’t know how much content will be in there until its on the page. But it wont be TOO much because I don’t like making one web page that scrolls down for ever, I think makes the website hard to read.
But that said, the style should go large enough to fix what ever goes in there. I may be putting a message board on there, so take a look at how large this thread got on the first page. It might from time to time need to hold some large posts.
–
I’m still looking over everything. I am trying to get my homework done first, so its taking a while to actually take the time and go through all the example that deathshadow60 allready gave me.
I’ll keep updating as I get through more of it, and once I start putting content on the page I’ll post if I notice any problems. So far I haven’t noticed any problems at all with it.
In other words… the appropriate behavior for a min-width layout that’s restricted to 800 friendly? If you’re getting a scrollbar, you’re viewing it at less than 800px wide, so of COURSE your going to have width issues. Like a fixed width would be any different on that?
‘default style’? What the devil does that even mean? Can you explain what this ‘problem’ is?
External CSS is cached, media types target devices and are NOT sent to all browsers – so one or two files is fine… but you get the people who use separate sheets for three different versions of IE, separate sheet for reset, separate sheets for ‘fac’ and ‘layout’… it turns into 2k of markup and eight handshakes by the time they’re through.
The idea is to get anything that can be cached across pages out of the markup while at the same time keeping total handshakes to a minimum – since it generally takes anywhere from 100ms to 1s for each file request past the first eight. Separate files for cache-able objects delivers bandwidth savings across pages; while keeping the number of UNNECESSARY separate files to a minimum speeds first load. This means you want an external file to cache it, but you don’t want to break it into more files than you have to.
It’s a balancing act.
No clue what you even mean by that.
… and from that I’m thinking you aren’t understanding a word I’ve said.
I think we’re hitting up against a language barrier issue? I’m having great difficulty deciphering your broken English.
there is a clear line between hand shake economy and coding disaster. keeping things separate and clear == very good. at least for the dev part. when going online, then you can mix thing up… a bit.
a question to MrGeeker: how long will Blah Blah Blah … be? how many lines? indefinite number? i’m trying to find out how far down will the page stretch because of the content.
What browser, given the math is perfect for it to be equal and I’m not seeing any difference between them in FF/Opera or Webkit, I’m assuming it’s some bizarre IE behavior.
See, I’m the exact opposite because I don’t want to waste markup on that html conditional comment bull, much less the handshake for another file.
By the time you add the 100+ bytes or so of markup to every page, is the 200 bytes of “haslayout” triggers in a file cached across pages on a site REALLY going to make a huge difference? Much less once you figure in the extra handshake… More files == BAD.
That and it becomes debugging hell for the next poor shlub to come along “what file is this even declared in?” being enough to say to hell with that kind of thinking.
It’s why every time I see IE conditional comments in someones markup I kneejerk into “well, this person didn’t know what they were doing.” – ESPECIALLY when you get three or four of them targeting each and every IE version specifically totalling 1k+. Goes with something I’m always saying – if you have 4k of markup before you even get to your BODY tag, you’ve probably royally screwed up somewhere.
Not sure what you mean by progressive enhancement in this case; Since what we have here works across all browsers and has graceful degradation…
Though the difference between progressive enhancement and graceful degradation is which end of the log you want to handle.
I prefer it for the cleaner structural rules; it just works/looks better with my formatting style. The rules of regular HTML – like being valid to omit structural tags like HEAD/BODY and closing tags like those on LI and P feels sloppy, and I’ve seen way too many instances of such things being the cause of people’s layout problems cross browser.
one problem i see. right white margin is not equal to the left white margin. it’s visible when the browser window it’s not maximized.
also i believe ie specific css hacks should be put in a separate css file and use the comment in html to target ie. i don’t like to put rotten eggs in the same basket with the good ones.
i might look this one up as it seems to me a little “overdone”. i guess i believe progressive enhancement would fit better. for such a simple layout, deathshadow60’s solution sure it’s not helping MrGeeker to give a worm embrace to tableless layout
also, too many divs, i think. the page it’s not that big as to imply divisions.
for the margin issue, actually in all of the big 5 (like africa’s big 5): ie, ff, ch, op, saf. but you need to make the browser window small enough for the horizontal scrollbar to appear.
also, with only the default style, the layout has some problems on <li> in the header and the footer.
more files == bad. then inline style == very good. why do you ever find the need for a css file, or even several for screen, print, handheld? i see a little contradiction here. of course, you can base64 encode all in a big file.
for the later, i first need to think and submit my own so as to have something concrete to argue about.
not trying to cross you, deathshadow60 but you seem to have lost your focus over rounded corners
I’d have to agree. I’ve honestly made a conscious decision to not even begin pursuing CSS3 or HTML5 at this time. Reason being, they are both a bit impractical at this point. I’ve never been afraid to adopt standards/software/etc before they are labeled ‘stable’ but it’s like DS said — most of the techniques we should even be considering for websites can still be accomplished (and often better) using the current standards.
This thread is quickly becoming what I’d call SitePoint’s most up-to-date reference on markup & stylesheet development best practices.
<mythbusters>Well there’s your problem</mythbusters> – little joke. See the quote in my sig about Dreamweaver? That applies to college degrees as well.
It’s a lot to take in - it doesn’t help that nobody seems to teach it properly… I’m TWO YEARS into trying to write a website to explain all that and I feel like I’ve barely scratched the surface (and I don’t lay down one line of HTML for a site until I have my base content written!)…
When haslayout actually makes a difference, practices that if you obey make things like the broken IE box model be a non-issue, things that just can’t be relied upon cross-browser… It’s a LOT of stuff and it’s all poorly documented if at all, spread out over dozens if not hundreds of different websites.
I’ve NEVER liked fixed width layouts, it always feels like a copout and invariably alienates somebody. See everyone running around with “nobody’s using 800 wide anymore” two years ago; tell that to the entire first generation netbooks, and all the ‘pad’ type devices coming along like the iPad and the $150 or less 7" chinese knockoffs.
Traditionally I always did 100% fluid, but I’ve warmed to the semi-fluid layout; auto adjusting between two extremes. It avoids the problem of lines getting too long and at the same time makes most users happy regardless of their screen size.
If you aren’t planning on coloring for that, it should be a simple matter of just defining your two columns inside .borderSecondSide - if you want the column colored, that gets a bit more difficult but is not impossible - quite easy if your sidebar (the narrower column) is a fixed width. That’s how my Pascal programming site layout works.
Excuse the green, it’s a retrocomputing joke. Amazingly opinions on the green are 50/50 love-hate.
Floats are one of the most difficult things to master… really if all you are doing is two columns all you need to do is float one of them, them set a margin equal to the floated columns width on the same side. That’s the ‘easy’ way. A more complex approach is the ‘content first columns’ approach, which I tried to explain here for doing a three column layout:
Tables for layout is hordes of markup – ESPECIALLY if you use it on presentational images that don’t belong in the markup in the first place or put all your styling in the HTML. Generally if you end up throwing classes on EVERY element - like you had to on the TD, you’re doing it wrong. I could tell you were feeling it was wrong; It feels dirty to have code like that. It still feels dirty to me having all those presentational DIV and SPAN – but at least they are DIV and SPAN, tags that do not apply meaning to their content semantically. CSS3 may SOMEDAY let us sever the ties to those, but being it’s not even CLOSE to being real world deployable we have to live with them for now.
Even with the issues, I could tell you had a firm grasp of the basics - you just need a little direction and nudge towards good practices and the stuff NOT covered by most books or courses on the subject.
Probably the biggest lesson I can give you is apparent in this thread if you know what to look for – I had written the entire HTML, almost 99% complete (I forgot one instance of .borderBottom) without laying down one line of CSS and didn’t have to make ANY major changes to it. This stems from my ‘content first’ approach.
Even when it’s an empty template, there is some content that’s going to be on all pages… the main heading, the menu, and the footer. Usually the sidebar and content containers are also standard issue.
So it works out to a three step process:
Content marked up semantically.
Layout in CSS with any extra DIV or SPAN hooks added to the markup as needed.
Start up the paint program to hang the graphics on the layout.
This flips the design process around 180 degrees from what most of the ‘industry’ has been advocating… Though if you look at most of what the industry is doing letting the PSD jockeys dictate layout and to hell with accessibility, maintainability or even what’s practical to actually code or include within reasonable bandwidth restrictions you see WHY it’s time to kick that approach to the curb.
If nothing else the net result is easier to work with when you integrate the code into your back end and runs faster, since it’s usually less markup for the back-end to handle.
… sorry, started foaming at the mouth on my pulpit.
While I have ZERO plans to use CSS3 until probably sometime around 2012 at the earliest, since it’s not even out of draft and it takes little to no extra effort to use a basic technique like sliding doors to do the same thing.
Much less I’m using enough browser specific crap as it is without getting that stupid malfing -moz and -webkit garbage involved. If their support for these properties is so ‘complete’ and ready to be used, why the hell don’t they call them the ACTUAL CSS3 name?
Since -moz, -webkit and other such properties are supposed to mean ‘for testing, do not use on real websites’… Seems like everyone and their brother is forgetting that little detail in their over-eagerness for shiney new toys when we can do all that stuff without them.
… and more consistently/better looking given what crap FF’s ‘shadow’ is when combined with rounding so far as AA is concerned.
Nice work, ds! I didn’t post that link above as an example of best practice necessarily… just that it’s where I had seen a similar, expanding shadow effect used before.
Personally, I would use CSS3 and let browsers that don’t support it go to the deuce.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Shadow</title>
<style type="text/css" media="all">
#outer1 {
-webkit-box-shadow: -3px -3px 8px #aaa;
-moz-box-shadow: -3px -3px 8px #aaa;
box-shadow: -3px -3px 8px #aaa;
margin:40px auto;
width:70%;
}
#outer2 {
-webkit-box-shadow: -3px 3px 8px #aaa;
-moz-box-shadow: -3px 3px 8px #aaa;
box-shadow: -3px 3px 8px #aaa;
}
#outer3 {
-webkit-box-shadow: 3px -3px 8px #aaa;
-moz-box-shadow: 3px -3px 8px #aaa;
box-shadow: 3px -3px 8px #aaa;
}
#content {
-webkit-box-shadow: 3px 3px 8px #aaa;
-moz-box-shadow: 3px 3px 8px #aaa;
box-shadow: 3px 3px 8px #aaa;
border:1px solid #333333;
min-height:0;
padding:20px;
text-align:justify;
}
</style>
</head>
<body>
<div id="outer1">
<div id="outer2">
<div id="outer3">
<div id="content">Lorem ipsum dolor sit amet consectetuer nibh elit a In ac. Orci et arcu orci convalli enim tellus ligula vestibulum hac. Risus felis nisl In at et in orci Curabitur mauris ipsum. In at Maecenas porttitor dui libero vel eros et quis condimentum. Et tempor ac vitae ut Vestibulum faucibus elit Phasellus netus ut. Id orci ipsum tellus convallis tincidunt sapien est. Lorem ipsum dolor sit amet consectetuer nibh elit a In ac. Orci et arcu orci convalli enim tellus ligula vestibulum hac. Risus felis nisl In at et in orci Curabitur mauris ipsum. In at Maecenas porttitor dui libero vel eros et quis condimentum. Et tempor ac vitae ut Vestibulum faucibus elit Phasellus netus ut. Id orci ipsum tellus convallis tincidunt sapien est.</div>
</div>
</div>
</div>
</body>
</html>
