SitePoint Sponsor

User Tag List

Page 2 of 2 FirstFirst 12
Results 26 to 38 of 38
  1. #26
    SitePoint Member
    Join Date
    Feb 2012
    Location
    Southeast Georgia, USA
    Posts
    24
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    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").

    Code:
    <!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 &#169; 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.

  2. #27
    SitePoint Wizard
    Join Date
    Dec 2003
    Location
    USA
    Posts
    2,582
    Mentioned
    29 Post(s)
    Tagged
    0 Thread(s)
    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.

  3. #28
    SitePoint Member
    Join Date
    Feb 2012
    Location
    Southeast Georgia, USA
    Posts
    24
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    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.

  4. #29
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by samanime View Post
    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.
    Ditto, ditto, oh hells ditto.

    Quote Originally Posted by samanime View Post
    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).
    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.

    Quote Originally Posted by samanime View Post
    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 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".

    Quote Originally Posted by samanime View Post
    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
    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:

    Code:
    <link
      type="text/css"
      rel="stylesheet"
      href="screen.css"
      media="screen,projection,tv"
    >
    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.

  5. #30
    SitePoint Member
    Join Date
    Feb 2012
    Location
    Southeast Georgia, USA
    Posts
    24
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    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.

    Thank you for taking the time to reply.

  6. #31
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by CRTolbert View Post
    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.
    That's for when you use the OTHER media types.

    screen.css
    media="screen,projection,tv"

    print.css
    media="print"

    handheld.css
    media="handheld"

    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.

  7. #32
    SitePoint Wizard
    Join Date
    Dec 2003
    Location
    USA
    Posts
    2,582
    Mentioned
    29 Post(s)
    Tagged
    0 Thread(s)
    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.

  8. #33
    <title class="lol"> bronze trophy TehYoyo's Avatar
    Join Date
    Feb 2012
    Location
    Northeast Chicago Suburbs
    Posts
    806
    Mentioned
    18 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by samanime View Post
    However, the catch with HTML 5, which drives many of us crazy, is that HTML 5 is rather forgiving in it's syntax.
    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.

    Quote Originally Posted by Samanime
    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
    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.

    ~TehYoyo

  9. #34
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by TehYoyo View Post
    although I leave my comments out after the closing tag.
    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.

  10. #35
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by samanime View Post
    Being verbose isn't being inefficient.
    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.

  11. #36
    SitePoint Member
    Join Date
    Feb 2012
    Location
    Southeast Georgia, USA
    Posts
    24
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Below is what I want the page to look like:

    bts-wireframe1.png

    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?

    Thank you.

  12. #37
    Just Blow It bronze trophy
    DaveMaxwell's Avatar
    Join Date
    Nov 1999
    Location
    Mechanicsburg, PA
    Posts
    7,283
    Mentioned
    121 Post(s)
    Tagged
    1 Thread(s)
    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.
    Dave Maxwell - Manage Your Site Team Leader
    My favorite YouTube Video! | Star Wars, Dr Suess Style
    Learn how to be ready for The Forums' Move to Discourse

  13. #38
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    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.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •