why not get rid of it completely, it’s totally unnecessary. I see the point of having a comment for /div#content, but that’s all.
No you can’t. in your case, the ul for the menu is pretty much the only ul that is ever going to be within your div#header. But in that case you’re referring, that mainMenu ul might not be the only UL that’s within the div#outerWrapper.
also, I wonder why nobody objects his use of linebreaks?
really. and you know that how? did w3c put a limit on my number of lists in my header <div>? or did they agree to multiple lists in outerWrapper <div>s? biased are you? “No you can’t” don’t go well with “pretty much” or “might not”. lists can also be just that, lists, not only menus. and can appear pretty much anywhere in any number as well as the <div> footer can have multiple lists in it. biased are you.
you mean THEIR USE. i didn’t see you protest earlier on deathshadow60’s use of them. take a closer look at at it. or at the original poster’s code, MrGeeker? and you are free to be the first to protest to all three of them
The comment at the start of each is what’s really throwing up warning flags with me, but that’s because if I did that on any of my pages I’d end up hacking IE unnecessarily because that ends up between floats, you’ll trip the double-render or disappearing content bugs.
Almost guaranteed to cause layout issues in IE once you get floats on the page… It’s why one of my rules is comments go INSIDE elements, not outside them.
I include the “#” if it’s an ID, a “.” if it’s a class — gee, wonder where that came from.
I abandoned SHTML years ago as impractical/underpowered, so the idea of not using # to indicate an ID just because Apache SSI uses it for SHTML seems a bit silly to me.
You’ve got a perfectly good ID around it, what does the UL need an ID on it for?
You really have no idea how painful that is to read, right? <MrMike>Imagine someone took 2 foot long knitting needles and stabbed them into Tony Orlando and Dawn’s eyes. I think it might go a little something like this.</MrMike>
i’ve kept start comments for the <div>s. when the page code gets bigger, for me it’s very helpful to see just from one look where is what. i don’t have to read all the <div id="…, instead <!-- header… is distinct enough for me to quickly spot it.
Now this is what I was talking about, this layout is just like mine, but it has columns inside the layout. The problem is their source has nearly 3,000 lines of code/markup so there isn’t a way for me to see how they’ve done it.
This would be amazing if I could do this column layout with my website.
I am trying to put text in the side DIVs like you had said to do but the text shows up above the header logo, I’m not sure why.
i’ve only used a comment to point to the start of <div>s just to underline the lack of semantics for <div> elements. when you look at the page code you don’t need to see <div id=“header”>, but only where the header starts (and where it ends). it’s a lot easier for me this way to navigate through the code.
one man’s trash is another man’s treasure
for me it’s not trash. it’s a way to organize my code.
as for # i have to say thanks to deathshadow60 for it except i’ve left out some spaces :injured:
@noonnope – Nice use of non-semantic markup and comment placement likely to trip IE rendering bugs (yes, I said COMMENTS)
Much less the silly comments bits like ‘start’ and ‘end’ – as if we magically don’t know that <div> might be the start of something and </div> might be the end of something – just poking fun, though you may want to take the time to read:
Specifically “Oh? We’re done? Thanks for letting me know. That big right bracket and the infinite expanse of empty space beyond really didn’t tip me off to that.”
<!–#header start–><div id=“header”>
No, really? <div id=“header”> is the start of our header? Nobody EVER would have figured that out.
If that’s the markup you plan on working with though, you’ve already thrown semantics and accessibility out the window since those two menus should be lists.
Nice use of non-semantic markup and comment placement likely to trip IE rendering bugs
dully noted. although i have to say i erase all comments (developer’s comments) in the live pages.
about the two menus: to keep it simple to understand
arguably, i didn’t wrapped yet any <a> groups in <ul>s
it’s possible we’ve hit another language barrier this is only a bare markup. first little step.
When I load this page on my computer I get a warning about an ActiveX control. I don’t understand why I see this. The only thing I did was add one link to the header.
i guess you are no better sometimes? i’m glad to see you take such a great interest in my Katakoto eigo. but i do really appreciate your insight, no matter you poking me and all that you probably meant
text by it self may be coherent… it’s meaning as a hole (post) it’s not making much sense to you but as i stated before, i’ll try and make it better.
I agree with you about not needing a comment at the start of an element, but commenting the end of an element can be very helpful when you’re trying to figure out why your layout isn’t working and why the validator’s telling you there’s an unclosed <div> and you can’t figure out where…
But there is a problem with the way the comments are written! There shouldn’t be a # in there, that’s for when you have things like virtual includes. <!-- end header –> works a treat.
ok mrgeeker. you need to adopt a new way of thinking when it comes to layout. so it will be a little of a longer road, with small steps.
your first little step: as deathshadow60 put it first, you need to go down to the basics of your page: the content.
to do that, see your page table design without css. then sort out the content and elements to use for that content alone. don’t try to see in the future of the page, just use the bare minimum. this page in particular, is very helpful, being so simple, and serves our purpose very well.
i’ve attached a screen shot that makes it easy for you to see how it looks now without css, as opposed on how it should look. remember, your page could be viewed only in text mode (no images), or maybe not even seen at all, but read.
also, below it’s the html code. to make it short:
the page is divided in three sections (header, content, footer), using <div>s
between them, for aesthetics reasons, <hr>s
logo has been replaced by a <h1> (this one may be subject to future changes. we could keep the <img>.)
arguably, i didn’t wrapped yet any <a> groups in <ul>s
the only important attribute for html now is dir=“ltr”. more attributes for it (lang…) as well as other head rules will be added later on.
now, your page looks good and clean. also, separation among sections it’s very clear.
true. i try to treat them equally fair. a clean base css i think will save me some troubles in the future. whereas ill css will just be put down when it’s time comes and that will require no extra effort from my part.
and i’m also looking forward to see what i’ll come up with
True, but without resorting to mcSwitchy try making a modern layout that’s 640 or smaller friendly while not making the people at 1920 want to ***** slap you.
Said window sizes being below what the majority of people are coding for - that’s why I don’t get why it was even pointed out given the number of people now only coding 1024 friendly or even larger ONLY as fixed width.
I mean, if I made it fixed width 768px (800 friendly) would it behave any different? of course not.
No, because that’s putting presentation in the markup - something entirely different…
You seem to see no distinction between markup and stylesheet… More markup bad. Non-semantic markup bad. Pretty simple.
Though I’m looking forward to seeing what you come up with - new and different approaches are always a good thing since there’s so many different ways of doing layouts.
In my opinion, that really isn’t worth worrying about.
I would be worried that you have a horizontal scrollbar at all, but I really wouldn’t lose any sleep over the fact that in some browsers at some window sizes, some people might notice that two margins that you can’t see on the screen at the same time are different.