Web Analytics Made Easy -
StatCounter First website layout - Looking for feedback - CodingForum

Announcement

Collapse
No announcement yet.

First website layout - Looking for feedback

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • First website layout - Looking for feedback

    Hi, I'm a novice HTML & CSS "student"(self-taught) and over the last day or so I've compiled a basic website layout for a fake Manufacturing company I made up. It's just the homepage, I know know it's EXTREMELY amateur, but I'm just looking for feedback, and all is appreciated! Thank you! I will attach the files so you can download them, but I will also post a JS bin link so you can view them in your browser. Works best with Google Chrome, as that is the scale I used when doing layout. When you go into JSBin make sure you look at is in Console only mode, or it will look a mess! Thank you!
    (Note: I recommend downloading it if you're really looking to help out & give the best feedback because you'll get the best view!
    Note: Navigation links DO NOT work they're just there for show, and I do plan on furthering this project based on your feedback!)

    ==Links==
    JSBin]JS Bin - Collaborative JavaScript Debugging
    [url="http://download1325.mediafire.com/necibr7l67wg/71tdtkfq3h9bxie/Hardline-Precisions.rar"]Direct Download(Media Fire[Download will start immediately])

  • #2
    Sorry for the errors! I don't know how to edit!

    LINKS ----

    Direct Download
    JS Bin

    Comment


    • #3
      ***and nav links do work, they just lead to blank pages :P

      Comment


      • #4
        Ok, lets start with the biggest thing that I noticed.

        Tables should NEVER be used for layout purposes. Period.

        You should give divs a width and position them.

        Also, drop all the inline styles, all CSS should be in, well, a CSS file. Thats why you have it.

        Design wise, you will notice the clipping of the everything as you shrink the browser, as well as hard to read text due to a low contrast.

        Your text color should be easily readable, so if you have a dark background like you do, white text would probably be better,

        THIS vs THIS

        To be valid in the sense of code, it will need quite a bit of work. I would recommend studying HTML and CSS and learn why and how to make things work, instead of just writing anything to get what you want.

        Also, again. No more tables unless you are displaying tabular data.

        If you want a more in-depth review on my part, or have any questions, dont hesitate to ask.

        Good luck
        Riley
        Riley-Shannon.com - My Portfolio
        FraktalServices.com - My Company

        Comment


        • #5
          RShannon is exactly right, never use tables for layout, that went out the door years ago. Wherever you are picking up your knowledge they are way out of date.

          In line styles do not follow Best Practices and really slow down your page load, no professional developer will use inline styles for their page. External style sheets and imported styles are the way to go, they are much easier to maintain and much better for your site.

          Menu selection fonts are way too small and just do not look good, the colors, especially for a background, way too dark and the contrast between the background and the blocks is just not well laid out. I know you are just learning and when you start out it is always hard to get going.

          I will help you get started if you need some assistance. I teach web engineering, at the University, managed a large IT department for a fortune 50 company, and develop training websites for corporations.

          I also have a FREE Introduction to HTML & CSS video class that can get you started in the proper way to develop web pages. You can download it free here.

          Introduction the HTML / CSS

          If you need any help let me know, I will help you anyway that I can if you have questions.
          Mike
          Learn Web Development - OnLine Video Training OnTargetHTML5
          Have Questions On Training or Web Development: Contact Mike

          Comment


          • #6
            Absurdly undersized menu fonts, illegible black on grey text, broken layout when zooming, broken non-responsive design at smaller window/display sizes... pretty much a giant middle finger to accessibility and usability. Have you heard of the WCAG? You might want to go read up on that.

            Code-wise it's a laundry-list of how NOT to build a website. As others have mentioned tables around non-tabular data, but there's also endless pointless classes and ID's for nothing, endless pointless DIV for nothing, little if anything remotely resembling semantic markup, static scripting in the markup, that stupid inaccessible "scripted template" rubbish telling large swaths of users to go plow themselves, and even if it WERE tabular data, you've no scope and now row TH on what would obviously be row TH.

            Hence your ridiculous 16k of markup to deliver 1.2k of plaintext when you don't even have proper meta data yet -- easily three times the code that should have been used for such a relatively simple layout.

            I would suggest throwing that in the bin, taking a step back, and take the time to learn to use HTML properly before you even THINK about trying to style what the page looks like.
            Walk the dark path, sleep with angels, call the past for help.
            https://cutcodedown.com
            https://medium.com/@deathshadow

            Comment


            • #7
              Originally posted by MikeK View Post
              I also have a FREE Introduction to HTML & CSS video class that can get you started in the proper way to develop web pages. You can download it free here.
              Given the inaccessible broken disaster of a site that's hosted on, yer not blowing anyone's skirt up on faith in your ability to help. No offense but... WCAG, heard of it? When your first heading on a page is a H4, you don't know enough about HTML to be telling others how to do things -- which your little free "tutorial" more than proves.

              Of course that's par for the course with the mouth-breathingly idiotic nonsense known as bootcrap. The moment you see that, you know the person doesn't know enough HTML or CSS to be instructing anyone on doing anything!
              Walk the dark path, sleep with angels, call the past for help.
              https://cutcodedown.com
              https://medium.com/@deathshadow

              Comment


              • #8
                It amazes me how insulting you can be at times deathshadow. BootCrap as you call it is one of the most popular Frameworks out there.

                Many professional web developers, have used it for years, it written by the development team at Google, but then again you probably do not understand much about SEO anyway. It saves a ton of time in development, is used for extensive mobile responsive development. Now does it have some bloat, yes it does, but if you set the site up correctly and only incorporate the modules that the site needs, it is a very effective tool in web development.

                Have you ever developed a professional site, taught at a University in Computer Engineering or software engineering, worked in a training environment, developed a site based on the SEO guidelines of the major search engines? I know the answer to those questions, that is why I asked.

                Stop being so insulting, it is know wonder the popularity of this board has been dropping, with the comments you make to most people on this board its a wonder anyone posts anymore. You are a pretty nasty, thinks you know it all person, why not focus some of that energy on trying to be helpful instead constantly insulting. You might be surprised, you may gain some friends.

                You are a smart person, I know that. You don't have to be insulting to make a point or impress people. You might be surprised how helpful you could be if you funneled those energies in a positive direction instead of negative.

                I am really surprised that they allow you to continually insult members of this community.

                Krisb, I apologize for this getting off topic.
                Last edited by MikeK; Oct 1, 2016, 07:49 PM.
                Mike
                Learn Web Development - OnLine Video Training OnTargetHTML5
                Have Questions On Training or Web Development: Contact Mike

                Comment


                • #9
                  Originally posted by MikeK View Post
                  It amazes me how insulting you can be at times deathshadow. BootCrap as you call it is one of the most popular Frameworks out there.
                  Just because it's popular, doesn't make it good. Look at the candidates for the current US election... or Justin Bieber.

                  There's a lot of really sloppy, sleazy, scam-artist BULL being pushed as "the thing to do" -- and it's high time we all started calling it out for the dirtbag halfwit nonsense that it is. You find something being called ignorant, inaccessible, broken, bloated and bad practice to be insulting, fine... I'm highly offended by the second rate circus barkers who saddle up nubes and take them for a ride with this rubbish; just as I'm offended every time I come across a bloated, slow loading, broken inaccessible website that tells me -- and many others as users --- to sod off because the developer was either too ignorant or too lazy to bother using HTML or CSS properly, or meet even the simplest parts of accessibility guidelines!!!

                  Which the fixed metric slop it out any old way halfwit train wrecks of ineptitude that result from such site-building methodologies basically are doing to large swaths of users -- myself included. But again, Joe forbid anyone DARE to respond in kind to being told to **** off, by telling those garbage tools and the people who advocate their use to **** off.

                  Because whether you realize it or not, when you use non-semantic markup, gibberish document structure, bloated off the shelf code slopped together before you even understand it, that's PRECISELY what you are doing!

                  Hence why "wah, wah, he's using insulting words" holds little weight to me when what's being promoted and encouraged is a thousand times more insulting to the intellect; bordering upon outright bigotry given who gets the shaft from the resultant sites.

                  Originally posted by MikeK View Post
                  Many professional web developers, have used it for years
                  ... and if all the other lemming's went running off a cliff?

                  I also think we have a diffferent definition of the word "professional" as the majority of people vomiting up the typical "Every bootstrap website ever" are professionals at only one thing; blowing so much smoke up client's backside I could take a butchers knife, chop them into pieces, put them in a styrofoam tray, and win a BBQ cookoff with the remains.

                  Originally posted by MikeK View Post
                  it written by the development team at Google
                  Twitter, not Google. *sigh* You don't even know who made it...

                  Originally posted by MikeK View Post
                  but then again you probably do not understand much about SEO anyway.
                  More than you most likely, since you likely don't even know enough about HTML to know why logical heading orders are important, what a document outline is, or even why things like "placeholders for labels" are a bad thing.

                  In other words, what Matt Cutts told us ages ago: "Write for the user, not the search engine."

                  Which is why every single accessibility failing, non-semantic use of markup, and things that do not gracefully degrade on a page are telling visitors to your site you could care less about their needs, and in turn is bad for SEO either directly or indirectly.

                  Originally posted by MikeK View Post
                  It saves a ton of time in development
                  HOW? By adding something else to learn? By making you write two to five times the HTML needed? By making you have to edit the HTML to change the layout? My forcing you into broken layout methodologies that only work on that magical combination of 16px default font size and 100% zoom? By forcing you to use that X-UA nonsense proving that even they had no business writing a modern website since no NEW page should EVER need that? By making you do as much if not more work than you'd have had without the stupid bloated framework if you just took the time to practice accessible design, semantic markup, separation of presentation from content, and development methods that gracefully degrade?

                  EVERY time someone says "it saves a ton of time" or "it's easier" or anything else of that nature, I really have to wonder what the blazes is in the kool-aid because that's 100% grade A farm fresh prairie-pies! The only thing I can figure is that again, they don't know enough HTML or CSS to have an informed opinion on that, or they're just blindly parroting what they've been told like a good little drone.


                  Originally posted by MikeK View Post
                  is used for extensive mobile responsive development
                  By people who don't know enough about HTML or CSS to be creating either...

                  Originally posted by MikeK View Post
                  Now does it have some bloat, yes it does, but if you set the site up correctly and only incorporate the modules that the site needs, it is a very effective tool in web development.
                  SOME bloat... hahahahaha... right. That's like saying the Titanic took on SOME water. Given it forces you to write two to three times the HTML neccessary on most any page by crapping all over the place with endless pointless PRESENTATIONAL classes (and presentation having ZERO business in the markup), starts out BY ITSELF three times the size most stylesheets should be for an entire SITE -- "some bloat" doesn't even begin to cover the unparalleled level of developer ineptitude that everything built with it is the poster child for.

                  Originally posted by MikeK View Post
                  Have you ever developed a professional site, taught at a University in Computer Engineering or software engineering, worked in a training environment, developed a site based on the SEO guidelines of the major search engines? I know the answer to those questions, that is why I asked.
                  Professional site? Several. Taught? Not since the Novel CNE/CNA courses (Real useful skillset in this day and age -- oh momma did I back the wrong horse)... which only further confirmed my opinion that most career educators (like those I was working with at the time) are unqualified to flap their gums on the topics they are allegedly there to teach... Run multiple training environments (typically evening "classes" of 15-20 on everything from Word to Web Dev) and most CERTAINLY seem to know more and done more for meeting SEO guidelines than anything I've seen of yours.

                  Hence why you can't even form a keywords meta properly -- the laugh being you probably bought into the lie that it's ignored since your malformed one would be.

                  Just as this:
                  http://www.cutcodedown.com/for_other...enHeadings.png

                  Speaks volumes of your alleged skills in SEO and HTML... or accessibility. Of course that just loading your page said "oh, you're on a high DPI display? Well **** you" said a great deal about your again alleged skills and qualifications.

                  Though to be brutally frank, that's all completely inline with what I've come to expect from a career educator in the field of IT.

                  Originally posted by MikeK View Post
                  why not focus some of that energy on trying to be helpful instead constantly insulting.
                  I was trying to be helpful, by steering a greenhorn away from having the rose coloured glasses slapped on their head to be led down the garden path. That is my approach to positive energies and efforts, certainly far better than late 19th century hucksterism and promoting development techniques that just wholesale tell visitors to the resultant websites where to stick it!

                  Which even if your unaware of it, is PRECISELY what you seem to be doing! Again, WCAG? Heard of it? Progressive enhancement ring any bells? Graceful degradation? Emissive colourspace and how it relates to legible contrasts? Elastic layout? Dynamic fonts? I'm talking greek to you aren't I? That or out comes the endless parade of lame excuses for not developing websites properly; it's usually either one or the other!

                  ... as evidenced by your attempt at using "the real world" fallacy and excuse; implying I've never worked on a real website, had a real job doing it, etc, etc... Because if you can't argue actual FACTS...

                  If you had heard of those things and were QUALIFIED to write a website, you'd never have made a website like the one your "tutorials" are on in the first place; what with its blind copypasta of broken code, failure to adapt the code to match the site, broken alternative navigation, and utter complete lack of meeting even the simplest of accessibility norms!

                  hence gibberish use of numbered headings like this:
                  Code:
                   <div style="margin-top: 20px;" class="col-xs-10 col-xs-offset-1 col-md-10 col-md-offset-1"> 
                                  <p class="sales_text">Thank you for your support of OnTargetHTML5.  The tutorials listed on this page are availble for FREE and availble for an immediate download.</p>
                                  <p>Check back often, I will be adding to these tutorials frequently.</p>
                                  <h5>Let me know if you have any comments or questions on the tutorials.</h5>
                                  <h5>Thank you for supporting OnTargetHTML5.</h5>
                                  <p class="signature">Mike</p>
                                  <h4>Register and receive a download link in your confirmed email address, available for immediate download</h4>
                              </div> <!-- End of 12 Column Div -->
                  ... or this:
                  Code:
                  	<div class="panel-heading">
                  		<h2 class="panel-title">An Introduction to HTML & CSS</h2>
                  		<h2 class="panel-title">ABSOLUTELY FREE</h2>
                  	</div>
                  ...or putting your modals before the content (sure that's so useful on a braille reader), having no scripting off fallbacks for said modals, etc, etc... (laughably these days you could probably even do those modal dialogs without resorting to JS! JUST like how scripting for the responsive menu is broken inaccessible rubbish no matter how much bootcrap tries to tell you otherwise!)

                  ... and to think, you're out there telling other people how to do this? SCARY!

                  Originally posted by MikeK View Post
                  Krisb, I apologize for this getting off topic.
                  Same apology to Krisb -- but I wanted to warn you before you got led astray by blind copypasta, broken bloated methodologies, and inept rubbish that makes you work harder, not smarter!
                  Last edited by deathshadow; Oct 2, 2016, 12:57 AM. Reason: Removed some repetition, typo's... Eye halve a spelling chequer. It came with my pea sea.
                  Walk the dark path, sleep with angels, call the past for help.
                  https://cutcodedown.com
                  https://medium.com/@deathshadow

                  Comment


                  • #10
                    ... and actually, to drag this back on course, let's go through @krisb1220's code and actually break down what's silly, what's wrong, and what's not needed. There's a little bit of each. I actually started work on this before the little pissing contest got underway. Now to see if the silly post-limit size here barfs on this

                    You start out halfway decent... proper doctype, proper order of doctype, html, head, and charset meta. It's surprising how often people screw that simple bit up.

                    You have an author meta -- lose that. Not ONE legitimate UA does ANYTHING with that, so that's just a waste of bandwidth.

                    Your keywords <meta> is overstuffed. What I mean by that is you've basically broken the rules of what that tag is for and how it works. Using it the way you have -- and indeed the way many people abuse it -- has led to the LIE that said meta tag is ignored and it doesn't matter. This is in fact 100% grade A farm fresh manure; the key is to use it properly.

                    In your case, you're HALF right... you actually have ... words. It's called keyWORDS for a reason, so when you see people stuffing it with pointless redundant phrases, they're using it wrong. In that way, you're doing better than a lot of so called "experts'. It's not called keyphrases or keysentences for a reason; were that people paid attention to that. Single words being preferred, hyphenated and proper names being acceptable.

                    The problem is you've got too many of them. 7 or 8 is the recommended limit if you want that tag to do anything with those, so CHOOSE CAREFULLY. Also much like the title tag if you go past a certain length it will be ignored too -- some people say 128 characters, other 96... usually when sources disagree, go with the lower number; so get that under 96 character in addition to reducing it to 7 or 8 words.

                    Finally, if those words do not appear between <body> and </body> as CDATA (character data, plain text), they will be ignored and likely get the entire meta ignored in the process. This is the hardest part of such meta -- it's called "relevance" -- and if your keywords have no relevance to the content, why are they in there?

                    I have also found that generally speaking, if you go high hog on words, high hog on length, AND have zero relevance -- the trifecta of /FAIL/ at using META, it can get your site slapped down for suspected abuse of the system. So don't screw up big on that, it will bite you... you do it right, it will still work -- EVEN in search engines that claim it now doesn't because even they have forgotten their own rules. :/

                    Your stylesheet <link> is missing what are called "media targets". What that means is your style will be sent to ALL user-agents, not just the screen media it was designed for. Are you sure your screen media layout will make any sense as print, aural, or braille? Unlikely. (not that there's CSS for braille, but you get the idea). That is why you should add at bare minimum media="screen" to that <link>. I prefer to use media="screen,projection,tv" as there are still devices in circulation (Wii browser, DS browser, some public kiosks) that will ignore, or worse apply their own rules over yours if you omit those extra attributes. It's wierd that many Kiosks use projection, but... whatever.. As of the latest revision of HTML 5 the validator will now complain about projection and TV -- I ignore this warning as bull since to be frank, media targets for stylesheets have ZERO business being set, checked, or declared by the HTML specification or anything checking for validity of same!

                    But then I have a lot of... complaints about HTML 5 and how it's dragging us back to the worst of 1997 on a great many things.

                    Your <title> is nice and short, well done. I would suggest that when you have subpages you use the subpage title as a prefix to the site title -- so for example an "about us" page would have a title like:

                    <title>About Us - Hardline Precisions</title>

                    This is because the title exists for specific reasons -- to be used as the text on the window, on the tab, and as the default link text in your SERP (Search Engine Results Page) listing. A big fat paragraph isn't very useful as a title, neither would be all your pages having the same title, nor would putting it second since tabs cut off text when too narrow. You have multiple tabs open on the same site, it's nice to be able to tell at a glance what page each tab is.

                    Some of your comments in placement and meaning range from redundant to bug inducing. Yes, Comments -- the things browsers are SUPPOSED to ignore -- can introduce rendering bugs. If they end up between sibling level tags, they can actually cause old versions of IE and random versions of FF (seems like the bug comes back every six months) to screw up how they build your page. As such, when possible avoid putting them between sibling depth tags. Your "end navigation" for example could do that.

                    Likewise, avoid using comments that are painfully obvious and ultimately redundant. For example:

                    Code:
                    <!--BEGIN PAGE CONTENT--> 
                    <body>
                    Opening the body tag is the start of your page content?!? WHO KNEW!

                    Joking aside, pointless comments like that are just a waste of bandwidth and anyone qualified to work on the page shouldn't need that. Likewise, if you're going to waste time on saying something like this:

                    Code:
                    <div class="Nav">
                    <!--NAVIGATION-->
                    Why not just call it <div class="navigation"> and be done with it? Then you don't NEED the comment!

                    Though in that same way, I understand the desire for closing comments, particularly on major sections inside DIV. Unless your indenting habits are THAT GOOD, it's easy to lose track. In that way, I prefer to use a comment like:

                    Code:
                    <!-- .navigation --></div>
                    By putting the comment before the closure, it is impossible for it to end up between sibling depth tags... the period tells me I'm closing a class, and by using a verbose name I know exactly what it is that's being closed.

                    Commenting and indentation habits might seem trivial, but in the long run they can save you headaches and pain -- particularly if in a year or two you come back to an already built site and have to sit there trying to remember what in blazes you did. ... and trust me, it happens to all of us.

                    Moving on, it is REFRESHING to see someone using a H1 as the first heading of the site for the site's title. You may or may not have been taught this, but I'm going to quickly cover it. Unless you are using HTML 5's new <section> and <article> tags, an H1 is THE heading that everything on every page of the site is a subsection. Think of it like how on every page or fold-pair of a book or newspaper the title of that book is at the top. That's a H1's job. Some would argue that's <title>'s job, but that's a non-render element and NOT part of the content, so it doesn't count if we're talking about a logical document outline.

                    In that same way, a H2 indicates the start of a subsection of the H1, a H3 indicates the start of a subsection of the H2 preceding it, and so forth down the line to H6. This is why skipping over heading numbers results in a gibberish and broken document outline. Headings exist to create structure, not to make text in different sizes -- even if that's the default appearance. Appearance should have NOTHING to do with what you chose for your semantic tags. Also beware that <hr> means "a paragraph level change in topic or section" -- a nice way of saying a change in section where heading text is unwanted or unwarranted... footers are often a good example of this and why HTML 5's <footer> tag is a pointless redundancy. (like most of the new 5 tags)

                    Bottom line, H1..H6 do not MEAN text in different sizes nor does HR mean "draw a line across the screen" -- they exist to create your document structure and outline, regardless of what their default appearance might be! This is becuase HTML is about MORE than just delivering a visual appearance to users. It's also about making sites that are accessible to the blind and partially sighted, it's about presenting information in a manner that's digestible to search engines... and even when it's about what it looks like, thanks to different device capabilities, resolutions, and sizes, you might have MANY different appearances for your single HTML. That's why "what it looks like" has NO business being part of why you use a HTML tag. LEARN THE MEANINGS!

                    IF you decide to use HTML 5's new <section> and <article> tags, the "counter" on header depth is reset to one inside them... so functionally in setting up your document structure if you go without <section> it might go like this:

                    Code:
                    <h1>Site Title</h1>
                    <ul id="mainMenu">
                    	<li><a href="#">Home</a></li>
                    	<!-- etc, etc, etc -->
                    </ul>
                    
                    <h2>Welcome to blah blah blah</h2>
                    <p>Text explaining who we are</p>
                    
                    <h3>What we do</h3>
                    <ul><li>List of stuff</li></ul>
                    
                    <h3>Who we are</h3>
                    <p>Information about employees here</p>
                    
                    <h2>Featured Articles</h2>
                    <ul>
                    	<li>List of articles</li>
                    	<li>possibly as a sidebar?</li>
                    </ul>
                    
                    <hr>
                    <p>Disclaimer/footer stuff here, HR acts like a H2</p>
                    Using Section it would go like this:
                    Code:
                    <h1>Site Title</h1>
                    <ul id="mainMenu">
                    	<li><a href="#">Home</a></li>
                    	<!-- etc, etc, etc -->
                    </ul>
                    
                    <section>
                    	<h1>Welcome to blah blah blah</h1>
                    	<p>Text explaining who we are</p>
                    	
                    	<section>
                    		<h1>What we do</h1>
                    		<ul><li>List of stuff</li></ul>
                    	</section>
                    	
                    	<section>
                    		<h1>Who we are</h1>
                    		<p>Information about employees here</p>
                    	</section>
                    	
                    </section>
                    
                    <section>
                    	<h1>Featured Articles</h1>
                    	<ul>
                    		<li>List of articles</li>
                    		<li>possibly as a sidebar?</li>
                    	</ul>
                    </section>
                    
                    <footer>
                    	<p>Disclaimer/footer stuff here, HR acts like a H2</p>
                    </footer>
                    ... and people wonder what my problem with HTML 5 is?

                    Either of those would produce the same basic document outline for accessible non-visual or gracefully degraded non-css navigation:

                    Code:
                    + Site Title
                    +-- Welcome to blah blah blah
                       +-- What we do
                       +-- Who we are
                    +-- Featured Articles
                    Sadly no UA has as yet implemented <footer> or <hr> properly in such, which is why I would reserve those for things the user probably wouldn't normally navigate to if not on screen/mouse, such as the footer for the entire page.

                    Oh, UA means "user agent", aka software that turns HTML into something a user can use. All browsers are user agents, but not all user agent's are browsers. Screen readers (software to read the page aloud to you), braille readers (which right now I'm having to learn to use given the direction of my vision, as it is I'm typing blind here), puffer navigation (don't ask), and even search engine spiders are all "user agents".

                    Back to your code, you've got some BR in there just to space the image away from the H1. Try to avoid doing that as that's what we have padding in the CSS for. If you have a choice on presentation between doing it in the external stylesheet or in your markup, stylesheet wins. This is because if the same appearance is used across multiple pages, you can share that stylesheet meaning that same appearance doesn't need to be downloaded again. The same if the user revisits the page later. Stylesheets are cached, usually far, FAR longer than your HTML is. Another reason to get and keep as MUCH of your "presentation" -- what it looks like -- out of yer bloody markup!

                    You also have that DIV around the menu UL. Generally speaking for what you're doing on apparance that's not really necessary -- and rarely is. There's not a whole lot I've ever heard of you can do to a DIV you can't do to a UL, so I'd lose that and move the class and any styling onto that <ul>.

                    One big worry is all those target="_blank" -- that's outdated methodology and a giant middle finger to accessibility. That's why as of 1998 the target tag no longer officially existed in modern non-transitional non-frameset documents. NEVER shove a new window or tab down the user's throat without asking -- and do yourself and the world a favor and forget that attribute even EXISTS!

                    Also, even if you are doing local testing, avoid putting the entire path of the file in a src or href. Always use the relative link to the location of the document. In that way, putting your subpages in subdirectories with ALL of them as index.html? Sloppy, bad practice, don't do it!

                    On .ContainerOne, first off that's a pretty vague name. If you're going to have a container like that give it a meaningful name, even if it's just something like "mainContent" or even better, "ourMission" would fit that perfectly. I might even consider making that an ID... why an ID instead of a class? Later on you might get into accesskey menus (which ARE still a thing) or want internal site navigation, and a ID can be targeted via a hash in a URL. So if you had this page as index.html and had a link <a href="index.html#ourMission"> clicking on said link would scroll to that part of the page.

                    The "Our Mission" text itself is in a paragraph when really, that feels like it should be a heading. As the start of your content that should either be a H2 or a H1 inside a SECTION tag, to mark the start of your content section. (Either way of doing so makes the HTML 5's <nav> tag a pointless redundancy)

                    You also seem to have the content paragraph wrapped in a preformatted text tag. Given that a good layout should be elastic (adjusting to the user's default font size preference), semi-fluid (having a max width so long lines of text don't get hard to follow, and maybe a min-width to prevent legacy browsers from breaking when they cant' handle media queries), and responsive (using media queries to change the layout to best fit the display) overriding the natural line-breaks for your own formatting is likely broken, and the antithesis of good content development practices. Ditch the pre, let normal formatting do it's job. If you're worried about lines being too long, set a max-width on .ContainerOne and center it.

                    The text after the next image is a laundry list of how NOT to add text to a page... It's not a proper name or organization title, so why is it in a <b> tag. <b> is for when GRAMMATICALLY in a professionally written document said text would be bold when not recieving "more emphasis" (which is <strong>'s job). Same way <i> is for when something like a book title is being referred to without being <cite>d or receiving <em>phasis.

                    ... and remember what I was saying about how presentation has NO business in your markup? Well see all those style="" setting the font size? Yeah, that needs to go. 99% of the time if you're using style="" you are doing something wrong. The only exception to that is when doing something like a bar graph or progress bar where width is helping convey meaning, or something like a tag cloud where font-size is communicating popularity. What you have here qualifies as neither.

                    I would also point out that PT is points, a 1/72ths of an inch. As such that's more of a print media size than a screen one. The WCAG -- Web Content Accessibility Guidelines -- says that whenever possible ALL your font sizes should be declared in EM, so use 'em! or %... percentage on font-size is the same thing as EM times 100. 150% == 1.5EM for font size. Just watch out for that as percent can have up to three different meanings depending on what property and elements you are applying it to. (sucks)... but for now just know that for font-size and line-height, 100% == 1EM.

                    Then *SIGH* the table... At least you tried to use TH properly for the column headings, but when there's only one TR for the "body", that's not tabular data. There is no semantic relationship in the rows. It's also painful to read non-visual since the headings are nowhere near their content in the source.

                    Each of those sections should likely have a DIV (or SECTION around them your call) with a H2 (or h1 if using section) for what you have as the TH. You would then wrap them, float them, and apply any desired style. You may find that cross-browser it's easier to apply those borders and styles too, what with most non-blink browsers ignoring border-radius on form elements.

                    Makign their borders equal-height can be problematic -- I would probably use the new flex-box property for that, and if they arent' equal in legacy browsers/UA's, OH WELL. Another approach might be to use what's called "faux-columns",


                    The big advantage of floated div or flex-box is that when the screen gets too narrow it's easier to make them STOP being multiple columns and shift to being one-below the other. This is the age of mobile design, that's a must-have. Also why keeping the headings with their content is a must-have.

                    ... and again, for the love of Christmas, ease up on the bloody <pre> tag and let normal wrapping do its job!

                    Continued in next post
                    Last edited by deathshadow; Oct 2, 2016, 02:26 AM.
                    Walk the dark path, sleep with angels, call the past for help.
                    https://cutcodedown.com
                    https://medium.com/@deathshadow

                    Comment


                    • #11
                      ... continued from prev post. Or at least once that absurd 60 seconds between posts limit dies..



                      Now, in my previous post, I mentioned the dubious legibility of your text. Black on #333 gray is pretty much saying "I don't care if you can read it". One thing to be aware of -- and rarely pointed out to nubes before they get themselves in it deep -- is there are rules for knowing if a combination of colours will be legible or not. The math is a bit complex and takes from the YCrCb formula, but thankfully there's a website that will do all that for you! Several actually, but this seems one of the best...

                      WebAIM: Color Contrast Checker

                      Plug in your foreground and background. If you are using a fairly thick-glyph font, you can usually go for large AA as acceptable, but normal AA is the ideal. Beware that if you use a font with really thin bars, hoops, and slabs (that's actually the terminology -- don't get me started on hooks, spurs, and other serif characteristics) commonly found in a number of the "hot and trendy" (and ultimately illegible) Google Fonts, even if you are using them at a large size you may have to go all the way to "normal AAA" as the test to pass. In that way, the goofy Google fonts you included? Just making the page slower and harder to read, as if you didn't have enough of that already!

                      IF you can't make your foreground and background meet those minimums, it's time to rethink your inks and choose a different colour plan!

                      In that same way, your font sizes are "all over the place", and not in a good way. You're mixing all sorts of metrics such as px and pt, when really again what you SHOULD be using is EM. There are only a handful of corner cases where declaring a font size in something other than EM is acceptable -- such as when dealing with complex layout concepts like "gilder-levin image replacement". Some folks might point you at REM, but in real world deployment browser support is still spotty, and really if you can't handle the simple multiplicative nature of EM (aka 3rd grade math) you probably shouldn't be trying to do anything involving code just yet.

                      What to I mean when I say EM are 'multiplicative'?

                      Code:
                      <body>
                      	<h1>
                      		Our Blah Blah Blah<br>
                      		<small>Putting the blah in blah</small>
                      	</h1>
                      	<p>Test P</p>
                      </body>
                      If we set this as the CSS:

                      Code:
                      body {
                      	font:normal 85%/150% arial,helvetica,sans-serif;
                      	/* or 0.85em size and 1.5em line-height */
                      }
                      
                      h1 {
                      	font-size:200%; /* you could also say 2EM here */
                      }
                      
                      h1 small {
                      	display:block; /* removes oddball inherited line-height */
                      	font-size:80%; /* you could also say 0.8em */
                      }
                      for MOST users the default font size is 16px. This would make body and everything inside it -- like our P -- be 13.6, which gets rounded up to 14px. I use 85% for Arial a lot as it will resolve to 17px for users like myself who have a 20px default instead of a 16px one.

                      Our H1 being set to 200% aka 2em, would give us twice that -- 27.2 which usually gets rounded to 27px. The small tag inside it, providing de-emphasis for the tagline (the semantic meaning of small -- we don't actually HAVE to show it smaller) would be based on it's parent, so that's 27.2 * 0.8 == 21.76, so 22px as the size used.

                      Now, notice I said 16px default and how I use 20px? A LOT of users rather than resorting to zoom -- or on systems that have far higher DPI than normal -- will have a different default size. You declare any font sizes in pixels (and to a lesser extent PT) they won't get that auto-enlargement sending them diving for the zoom; or more likely saying "screw this" and going somewhere else should your layout break when zoomed -- or just out of being too lazy or too ignorant to even know there is a zoom. My media center for example has a 24px default -- aka 150%.

                      There's actually a slew of names for the standard/larger sizes... but for now just beware that not everyone has that magical 16px default or wants to put up with agonizingly bad sizes like the 10.66px your uselessly small 8pt comic sans menu is. (comic sans? REALLY?)

                      Good rule of thumb, use em and if your calculated font size for a 16px default would go below 14px, DON'T GO THAT SMALL!!! Yer just pissing people off!

                      That's about all for now... I'd go through your CSS, but there's as much wrong there and it would take me even longer to dissect that properly. The changes I propose to your markup would likely require a complete rewrite of your style anyways.
                      Last edited by deathshadow; Oct 2, 2016, 02:27 AM.
                      Walk the dark path, sleep with angels, call the past for help.
                      https://cutcodedown.com
                      https://medium.com/@deathshadow

                      Comment


                      • #12
                        It's a good thing deathshadow kept his reply short...

                        My advice for the OP is to ignore the advice here and get the latest edition of How to write HTML/CSS book and learn from there, plus maybe a book on graphics design that targets typography specifically. Typography is key in getting nice reading content and that is probably the most imporant thing on a website is content. The one thing I do agree with deathshadow is to throw the current HTML markup away and just because one person says that something is rubbish doesn't mean it is if millions have been using it with success. Oh I can't wait for deathshadow's reply, but I will probably not read it for I enough of a sermon when I go to church.
                        Last edited by Strider64; Oct 2, 2016, 08:05 AM.
                        "A person who never made a mistake never tried anything new." ~ Albert Einstein https://www.miniaturephotographer.com

                        Comment


                        • #13

                          Originally posted by Strider64 View Post

                          My advice for the OP is to ignore the advice here...
                          My advice for the OP is to to ignore Strider64's advice.

                          coothead
                          ~ the original bald headed old fart ~

                          Comment


                          • #14
                            Thank you for the detailed reply deathshadow, I do appreciate it. You make a lot of good points and I will go back and review the content. You are right in many aspects. As we get busy we tend to get a little lazy in how we do things and that is never an excuse.
                            Mike
                            Learn Web Development - OnLine Video Training OnTargetHTML5
                            Have Questions On Training or Web Development: Contact Mike

                            Comment


                            • #15

                              Comment

                              Working...
                              X