If you are using an XHTML DOCTYPE, the / is absolutely required (e.x., <br />).
If you are using an HTML 4.01 DOCTYPE, you should leave it out (e.x., <br>).
If you are using the HTML 5 DOCTYPE, you can have it either way (which makes DS’ brain explode =p).
Personally, when I work with HTML 5 I always leave it out, though some people prefer to always leave it in. It’s up to you, but it’s important to stay consistent.
Also, in defense of jQuery: if you are doing a large Javascript heavy project (like a web app), jQuery can actually substantially reduce the amount of Javascript required overall. However, for little effects it is often quite overused.
Also in defense of minification/whitespace stripping: if you have something on your site which automatically does it for you, it can’t hurt. I actually have something that does some other type of processing to certain files and caches the results. As an added bonus, I had it do whitespace stripping as well. Set it and forget it. =p
Some may disagree, but I recommend from this point on you only learn what is correct using the HTML 5 DOCTYPE:
<!DOCTYPE html>
I’m not saying learning HTML 5 only though… far from it. I just prefer the DOCTYPE because it gets rid of a lot of the other stuff, simplifies things, and will be valid for many years to come.
However, the catch with HTML 5, which drives many of us crazy, is that HTML 5 is rather forgiving in it’s syntax. This is not really a good thing. Do to this, you’ll want to make sure you are always writing valid markup (I highly recommend running it through the W3C validator). Also, make sure you enforce string syntax upon yourself. Decide if you want to close self-closing tags or not, and then stick with it.
If you are counting votes, I agree with samamine. He explained it very thoroughly.
CRTolbert, you should know that just because one carries a green name on an online forum…doesn’t mean they are knowledgable in web design and HTML. Some may have been plain taught wrong (note, I’m not saying this is true about anybody, I’m just saying to be wary).
AH YES, this BULL… and it’s exactly that, 100% undiluted grade A farm fresh rose fertilizer.
What they MEAN to say is that it is not a complete implementation of XML, specifically the extensible part – BUT THAT IS NOT WHAT XHTML 1.0 IS FOR. That’s what XHTML 2 was supposed to be for, and was aborted faster than … ok, I won’t make a simile on that one… But it was abandoned as a avenue of development because it turned out the whole “XML Application” nonsense was needlessly complicated, painful to maintain, and all but a handful of holdouts backpedalled away from it faster than a squirrel at a skunk convention once any of it’s concepts actually tried to be applied in practice.
IF you are using XHTML 1.0, you are doing so to create a well formed document with consistent rules that it is possible to parse with an XML parser – it exists to bridge the gap between XML parsing and legacy HTML. Trying to use it for ANYTHING ELSE, is… well, as outlined above in terms of the truckload of farm fresh manure.
This ENTIRE mime-type asshattery (which honestly I’ve never liked the NOTION of mime-types in the first place - as if extensions are some great evil we have to hide from people and never actually use – until the server has to figure out what mime-type to use defeating the point) in terms of the ‘xml application’ idiocy is just promoted by those who fail to grasp the point of XHTML 1.0, can’t be bothered to read the specification that DEFINES WHAT XHTML 1 IS, and specifically where it SAYS it’s ENTIRELY VALID to serve it as text/html.
When the SPECIFICATION DEFINING WHAT IT IS says it’s ok to use the text/html mime-type, claiming it’s somehow magically not XHTML anymore is outright ignorant NONSENSE! Anyone using logic reasoning like that needs to go learn what logic is.
So ignore that idiocy and go ahead and use XHTML 1.0 strict if you are doing so just for the more rigid and consistent structural rules. It does NO harm, it is in no way magically somehow not XHTML or broken in IE no matter what the XML application whackjobs say, and if you bother to read and shock comprehend it’s structural rules (like the shortform / close only being valid on EMPTY elements, empty elements NOT being ones that contain no content but those that CAN’T contain content) you’ll rapidly find a lot of the misinformation and outright ignorant bull it’s opponents spout has absolutely no basis in FACT.
Usually boiling down to them parroting what some other “expert” told them, or not taking the time to investigate their own claims.
Thanks again for all the replies. Since the issue is still “clear as mud” to me, I’m going to post the brand new markup for my (hypothetical) website. My goal right now is to follow progressive enhancement to create a site that will be visible in all modern browsers at a display of at least 800 x 600. I would also like for it to be fluid and degrade graciously. I’ll post my line of thinking so that you guys will know why I did what I did and hopefully correct me where I’m wrong (although I understand that is subjective).
FYI: this code validated on W3C’s XHTML 1.0 Strict Validator (which I know that doesn’t mean it’s “right”).
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
<title>BTS Consulting - Security Services</title>
<link href="layout.css" rel="stylesheet" type="text/css" media="screen" />
<link href="type.css" rel="stylesheet" type="text/css" media="screen" />
<link href="color.css" rel="stylesheet" type="text/css" media="screen" />
</head>
<body>
<div id="wrapper">
<div id="header">
<h1>BTSercurity Consulting</h1>
<ul class="topMenu>
<li><a href="#">Home</a></li>
<li><a href="#">About</a></li>
<li><a href="#">Services</a>
<ul>
<li><a href="#">Service1</a></li>
<li><a href="#">Service2</a></li>
<li><a href="#">Service3</a></li>
<li><a href="#">Service4</a></li>
</ul></li>
<li><a href="#">Contact</a></li>
</ul>
<!-- header --></div>
<div id="leadIn">
<h2>The world today can be a dangerous place...</h2>
<p>Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. Vestibulum tortor quam, feugiat vitae, ultricies eget, tempor sit amet, ante. Donec eu libero sit amet quam egestas semper. Aenean ultricies mi vitae est. Mauris placerat eleifend leo.</p>
<!-- leadIn --></div>
<div id="slideShow">
<!-- Slide show will go here -->
<!-- slideShow --></div>
<div id="infoBar">
<h3>BTS Consulting is ...</h3>
<p>Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. Vestibulum tortor quam, feugiat vitae, ultricies eget, tempor sit amet, ante. Donec eu libero sit amet quam egestas semper. Aenean ultricies mi vitae est. Mauris placerat eleifend leo.</p>
<a href="#"><img src="button.png" alt="Click for Contact Form" /></a>
<!-- infoBar --></div>
<div id="footer">
<ul>
<li>Copyright © 2012</li>
<li>CRTolbert</li>
</ul>
<!-- footer --></div>
<!-- wrapper --></div>
</body>
</html>
My line of thinking:
I declared an XHTML 1.0 Strict doctype. I’m still not sure if that is the best way, because I still don’t understand the differences between XHTML and HTML and the benefits of using one over the other. I chose to go ahead and use XHTML here because all the books I’ve been exposed to so far use it as well as the W3Schools tut I went through. I will continue studying the differences and adjust what I use accordingly.
I chose to use “utf-8” as my charset because some of the books and tuts I’ve read say it should be used because it’s pretty much universal. I haven’t studied that out completely yet, but that is on my list of things to know better.
In the head section, I plan on calling three different stylesheets based on an article I read by Aaron Gustafson on Progressive Enhancement. The reasoning is that, while each on is a separate request, once cached, speed shouldn’t be an issue. Manageability is improved though as well as workflow when it comes to dealing with different media types, which I plan on learning more about.
Moving on to the body, I have a “wrapper” div because I want to center the page in the viewer. The header will contain my <h1>, which I plan on doing an image replacement with the logo. It will also contain the <ul> for navigation.
The “leadIn” div is basically just a left column that I’m using to lead into my “why you should choose me” blurb (which will be my <h3>). Next to that will by my “slideShow” div as I plan on circling through images that show what type of services this firm offers. Each image will link to that services page as well. I just commented there because I haven’t even begun to think about how to actually do the slide show (JavaScript I suppose) and that will come later.
The “infoBar” div will contain the “why you should choose me” blurb. In that same container, but positioned to the right will be a big “Get Free Consultation” button (which doesn’t actually exist yet) that links the user to the contact form page.
Finally the “footer” div will contain the copyright and credits.
Okay, so that is how my newbie brain is thinking. Am I on the right track or do I need to think about things differently? I eagerly await your responses. Thanks.
First off, and this is very important: never ever ever ever use w3cschools. =p They have “w3c” in their name, so you’d think they are authoritative, but they aren’t at all. They also have exactly zero affiliation with W3C.
While I don’t personally agree of the split style sheet approach for a single media type, it’s not a terrible method (and the caching reasoning is accurate). One thing I would warn you about is because you explicitly defined the media attribute as “screen”, it means those CSS pages won’t do anything at all for other devices (like mobile or print). This may or may not be intentional, but it’s important to remember. I would probably make at least type (assuming by “type” you mean text/font stuff) and color as media=“all” so it affects everything. Leaving layout as just screen probably isn’t a bad idea.
Others may disagree with me, but I actually find that comments at the end of blocks like you have reduce readability. Once you get used to “reading” indentation, it becomes very easy to see where blocks start and end, and the comments have an annoying habit of masking that a bit. That’s just personal opinion though.
Otherwise I don’t see anything particularly “wrong” with your implementation. Nice work.
On the topic of those of us with “green” (or orange or blue), Ryan is correct that it doesn’t automatically make us super experts. However, most of us do generally know what we are talking about in our respective areas (not all of us are developers). However, like he said, that doesn’t mean we necessarily know more than others. So, feel free to disagree with us if you think we’re wrong.
First off, and this is very important: never ever ever ever use w3cschools. =p They have “w3c” in their name, so you’d think they are authoritative, but they aren’t at all. They also have exactly zero affiliation with W3C.
Point taken. I hope to gain a deeper understanding of XHTML vs HTML so that I can know for myself why I’m choosing one over the other. It may be that for a specific project I should choose one over the other, but at this time I just don’t know enough about them both. Definitely on my list to study though.
While I don’t personally agree of the split style sheet approach for a single media type, it’s not a terrible method (and the caching reasoning is accurate). One thing I would warn you about is because you explicitly defined the media attribute as “screen”, it means those CSS pages won’t do anything at all for other devices (like mobile or print). This may or may not be intentional, but it’s important to remember. I would probably make at least type (assuming by “type” you mean text/font stuff) and color as media=“all” so it affects everything. Leaving layout as just screen probably isn’t a bad idea.
Yeah, I don’t have a good understanding of how the “media” attribute works yet, but you’ve actually helped me understand it a little better. And yes, by “type” I do mean “text/font” stuff.
Others may disagree with me, but I actually find that comments at the end of blocks like you have reduce readability. Once you get used to “reading” indentation, it becomes very easy to see where blocks start and end, and the comments have an annoying habit of masking that a bit. That’s just personal opinion though.
I understand what you mean about the comments, and I’ve taken them out of my markup. I guess readability is the whole purpose of the indents and Notepad++ does a good job of showing the divs.
Thank you for replying. I feel that slowly (very slowly), but surely I’m beginning to grasp and organize all the information I’ve been inputting for the last month. Feels good.
I would disagree – it IS a terrible method because it makes you have to hunt between different sheets to find anything instead of having your properties actually together, but more importantly it’s multiple handshakes; something you want to keep to a minimum… you start getting images in there and the extra handshaking will slow the page load regardless of the file sizes.
I would HOPE it is intentional since omitting MEDIA or using ALL is a horrible idea; given that for print a screen.css is usually a waste of ink, and that a screen layout usually looks like garbage on handheld unless the handheld in question ignores everything but FaC.
I would suggest ADDING projection and TV alongside screen, since they tend to have similar capabilities; see the handful of people still using webTV, Opera in fullscreen or Kiosk modes, the Wii browser (based on Opera), etc, etc… It’s why I use media=“screen,projection,tv”.
Unless the sections end up so large once content is in there it doesn’t fit the screen – then you’re stuck scrolling back up to figure out “hey, which one is this closing again?” – omitting them makes things less clear to me. Especially when you get to things like the outer wrappers or the content wrapper.
But to keep that in perspective, I’m the guy who finds color syntax highlighting to be impossible to read acid trip flashback, tabbed editors a step backwards in functionality, tools like autocomplete getting in the way of me just typing the blasted code, etc, etc…
Also why I tend to put my properties on multiple lines instead of shoving it all onto an illegible single line (drives me nuts) and prefer XHTML over XML – since if I was to do:
HTML 4 style, then scroll down until only the last line is showing on the screen, I’m left with no clue if that bracket is closing a tag or opening it… XHTML’s /> on ‘empty’ tags makes it clear exactly what you are doing.
But that’s formatting - use what feels right for you.
My observations about your new page – you’ve got no language encodings, it’s hard to read your LINK properties all shoved onto one line like that (though not as bad as say… shoving your CSS properties all into one line in a stylesheet)… your formatting and BODY area on the other hand is clean, good use of commenting, though I’d probably add a few more carriage returns and one less layer of indents – since there’s no reason to be indenting static sections of the page that never change; it’s also why I put </head><body> and </body><html> on the same lines – they’re unchanging statics that should be on every page; no need to indent them, have space between them; besides, putting no whitespace space between them serves as a reminder that NOTHING should EVER go in-between them – something you’ll see people screw up all the time.
Good stuff in there, Jason. I forgot to put the language encodings, but I fixed that. I don’t mind the LINK properties being on one line, but I did like your idea about the </head><body> and </body></html>. Pretty neat. I did take out the comments since it’s not too hard to see that </div> is the end of a particular DIV. And I like the indents, so I’ll keep them.
I’m still up in the air on the multiple style sheets. There was something in the article about it being nice for when styling for multiple types of media (ie. mobile), but I’m still working on solidifying that concept in my brain. We’ll see how it turns out.
modernHandheld.css
media=“screen and (max-width:750px)”
One other thing, don’t use vague/meaningless filenames like “style” – you’ll see that asshattery all the time and the question is style for WHAT? Print? Screen? Toblerone wrappers? Coke cans?
The vague/meaningless names people slap on things always bugs me – it’s why I’m not a fan of that Ruby nonsense (a language that should have stayed stillborn instead of being resurrected by Rails) or newer garbage like “Rust”. Syntax that makes C look verbose; when the ONLY reason C syntax languages were so cryptic in the first place was they were designed for being typed in at 150 baud to a mainframe… meaning it should have gone the way of the dodo once microcomputers and connections faster than 2400 baud came along.
Great example from Ruby: “elsif”… Really? REALLY?!? really… what {expletive omitted} thought that was a good idea? Oh noes, can’t possibly have that ONE extra character in there.
Again, Wirth language elitist checking in.
I also find it confusing/hard to follow when people start separating ‘color’ from ‘layout’ (and again, color for WHAT? layout for WHAT? – vague/meaningless names, just like ‘nav’) – since I go to look for one elements properties and it’s spread out over two, three, ten separate files… It’s no wonder other people need firebug to handle their own code.
Which to be frank if you need firebug or dragonfly as a tool for your own code, there’s something WRONG with your code. Should only really be useful as a tool for cleaning up other people’s messes… assuming you go in with a plan, keep things in a sensible order; in other words basic organizational skills instead of just slapping everything in there any old way.
I agree with you DS on the Ruby stuff. I was taking another look at it yesterday to see if I wanted to use it for a future project since I’ve heard lots of things. However, when I was going through some tutorials I kept thinking “How on earth am I going to enforce good coding practices and clear code…” It’s in the same boat as Python, it’s fun, but the syntax just isn’t clear enough. Being verbose isn’t being inefficient.
For the multiple style sheets, I agree with DS. You should split them by media, not by type.
The one scenario I can think of where splitting them into files like “color” and “layout” would be if it was some kind of application that had a skin chooser, where you could swap out a color set and a layout set to rearrange the site. But those apps are few and far between. For your typical site, I don’t see much point in keeping them separate.
Sure, if you have colors all in one and you want to change a color, you know to look in the color.css file. But where? You’d have to figure that out. Same with layout. If they were in one, then you’d just have to find an area once.
I’ve seen the separate approach employed and described several times, but never found any way that made it easier. If anything, I think it gets a bit confusing. What happens if you get lazy and a few colors slip into layout, or vice versa.
This might be a little late, as we’re already on page 2 (at least for my 25 per page setting), but I agree 100% with this.
I disagree with you. I find it much easier to read, although I leave my comments out after the closing tag. Especially if you’re going to condense code before publishing, it helps.
Which I did right up until it started biting me in the backside cross-browser in legacy IE and some versions of FF once floats are on the table. You’ll go insane trying to figure out why your content appears twice on the page or doesn’t appear at all – then stare in disbelief when you find out that comments between floats or inline-blocks, and even just between certain sibling block-level containers can trip rendering bugs.
Comments tripping rendering bugs – seriously, how dumb is that? Almost as dumb as treating a script tag as a block-level container, right FF3?
Which is why I put them before the closing tag – that way there’s no chance of it tripping those bugs. Looks funny at first, but you get used to it. Actually seems clearer after a while because you’re saying what’s being effected, then what you are doing to it. Though I do understand the people who can actually use that color syntax highlighting nonsense have a harder time with it.
A concept that seems lost on so many of these “new” languages – It’s like they never heard of making fun of C for being needlessly cryptic; To the point there is actually an annual code obfuscation contest and jokes floating around the web about how C and Unix are a Hoax
But the inverse is true too – being short and succinct doesn’t have to be inefficient or hard to use; though I might be prejudiced on that since as I’ve said several times, I’d sooner hand compile 8k of machine language and enter it one bit at a time on toggle switches on a cosmac elf, than even try to maintain 100 lines of C code.
The H1 is where I want my logo image. The big image is where I want the slide show. I’m thinking that I’m going to have to add a DIV to wrap the leadIn and slideShow. Other than that, is my markup ready to start laying out with CSS?
Also, all this will be contained in a wrapper that will be centered ( margin: 0 auto; ) and take up 90% of the viewport. Will that work?
What’s the button for? Seems odd to just be sitting there.
The only other major red flags I see there are a lag of negavite/white space in the divs, and the menu doesn’t look fleshed out enough to start styling. Other than that, we’re guessing based on that very rudimentary layout. Like the headings - why do you have a h2 and a h3 like that? The headings are supposed to cascade down (h3 is a subheading of h2, which is a sub-heading of h1). If they’re not related (and seeing how they’re in different boxes, I’m guessing they’re not), I would suggest using a h2 and styling the h2 in that one div differently than the other div.
I’m with Dave that the H3 may or may not make sense – but that’s a guess since we’re not seeing real content which AGAIN, is why I say write up some real content BEFORE even THINKING about markup, much less layout.
That massive image area is most likely what I would consider “not viable for web deployment” – the filesize would be unacceptably large, it shoehorns you into a massive fixed width, requires a good deal of trickery to make the content area to the left of it display as if it’s an equal height… Again, there’s a reason you only see things like that on goofy little personal pages by art f… folks or small businesses that end up raped by a “designer” because the suits don’t know any better.
… and again why I consider wasting time drawing goofy pictures of a layout to be a waste of time compared to generating content, marking up that content semantically, and THEN generating the layout using CSS.
Oh, and you know your 1024 wide pic isn’t 1024 friendly, right? You have to take at least 36px off for browser chrome (scrollbars, window borders, etc), and I like to do 48px… and if you were designing for fluid or semi-fluid, you should be starting with more like a 752 wide layout and then keep in mind it can get bigger.
Which is another strike against massive images as they tend to break fluid layouts badly.
Apart from that, again it’s hard to tell without actual content – you’ve got some placeholders, no real style to it… illegible font sizes in an illegible face, but that’s most likely whatever you drew the picture in’s fault.
I’d probably shrink the image area to around 256px wide, let the content area next to it expand to fit the screen, and either move the second content area below the first one riding up next to the image ‘column’, or make it a subsection below it… but that’s just because I don’t consider content images greater in width than 256px to belong on a content page – you want a bigger image, treat it as a thumbnail. Anything else is a waste of space, bandwidth and most likely to cause bounce.
Though it could be worse, you could put some massively bloated and ultimately useless flashtard banner up there.
