Web Analytics Made Easy -
StatCounter Tables Question - CodingForum


No announcement yet.

Tables Question

  • Filter
  • Time
  • Show
Clear All
new posts

  • Tables Question

    Hello everyone

    I am an HTML newbie and I maintain a website for a charity that was built by someone else. I have been teaching myself code to add bits and pieces to it. All has been going well until I needed to add a table of committee members/nominees to the AGM page and now the whole page has a black border, which the other pages haven't. It may be easier to see the page in order to see what I mean: AGM and Committee - if you look at the other pages you will see that they don't have the black lines. I have realised that it's probably because the whole page is built within a table (or as a table?) but I am not sure how to get rid of the black lines.

    Any help/advice would be much appreciated!

    Thank you!

  • #2
    You should not abuse a table for design purposes. Simple divs would do the same.
    The border is defined in line 50:
    table, th, td {
        border: 1px solid black;


    • #3
      that page REALLY has a lot of problems -- fixed width layout and tables for layout being just the tip of the iceberg. There's no doctype so browsers will try to render it in "quirks mode", basically making it harder to get a consistent appearance across different browsers. It's a hodge-podge of presentational markup -- a polite way of saying "using HTML incorrectly" -- with tags like <u> and <font> mated to attributes like BORDER, BGCOLOR, etc, that have ZERO business in any HTML written after 1997. It's got static presentation in the markup, images doing padding's job, paragraphs and bold around elements that should clearly be headings, headings around elements just because you wanted the text bigger (that's not what they MEAN)... it's the WORST of 1997 browser wars methodology.

      I have to ask, just which WYSIWYG editor were you DUPED into using to create that. It clearly wasn't coded by anyone who learned to use HTML directly and properly.

      First step would be to drag the HTML kicking and screaming into this century. You have a fairly simple page, but the first step would be to put the CONTENT in an order that makes sense with semantic markup, paying ZERO attention to how you want it to look. That might sound a bit odd, but HTML is for saying what things ARE so the user-agent (a browser is a UA, but a UA isn't always a browser) can decipher that meaning to best deliver it to users -- regardless of if they are on screen, handheld, teletype, printing it, braille reader, or having a "screen reader" read the page aloud to them. HTML is about MORE than just some fancy screen layout -- that part is CSS' job, preferably in an external stylesheet.

      You have a fairly simple page -- I'm going to do you a favor and do a quick rewrite of said page to illustrate what I'm talking about. I'm going to do it by each of my "steps" and explain the steps and the code used bit by bit so you can learn from it.

      Gimme a bit, gotta have lunch first, but then I'll belt out a quick rewrite. We'll start with semantics and structure.
      Walk the dark path, sleep with angels, call the past for help.


      • #4
        Thank you deathshadow. I 'inherited' the site after the previous webmaster left and picked it up from there with no experience whatsoever in coding or HTML. I have managed to work out a simple fix for now so that it looks 'okay' but I am interested in your rewrite as well... however, bearing in mind my lack of experience, would it be something that a novice would be able to get to grips with?

        I really appreciate the favor! I may not be able to look until the weekend now as I also have a day job that demands much of my time, but I am grateful for your help.


        • #5
          Thank you Sempervivum.


          • #6
            Originally posted by Medusa View Post
            Thank you deathshadow. I 'inherited' the site after the previous webmaster left and picked it up from there with no experience whatsoever in coding or HTML. I have managed to work out a simple fix for now so that it looks 'okay' but I am interested in your rewrite as well... however, bearing in mind my lack of experience, would it be something that a novice would be able to get to grips with?
            Well, if you got so far as adding those tables to an existing markup, you didn't do too badly... you at least HAVE <th> and some semblence of normal code. If anything, I'd say their previous webmaster was as green as you.

            HTML itself isn't hard when used properly, particularly if you have any grasp of English and writing. It's making it look how you want WITHOUT compromising the quality of the HTML that's the hard part. What it looks like is CSS' job, NOT your HTML. If you are choosing any of your HTML tags based on what you want it to look like, you are likely choosing the wrong tags for the wrong reasons. Not ALWAYS true -- there are always exceptions -- but tags like FONT, U, and CENTER went the way of the dodo 18 years ago for a reason, as did most all of the presentational attributes like border, bgcolor, alink, vlink, etc...

            Those are all a relic of a pissing contest between Netscape and Microsoft to see who could come up with the flashiest features fastest, and in the process they pretty much ignored the reason HTML even existed. HTML 4 Strict tried to drag us back to that intent using CSS as a way to not just say one appearance, but many different appearances across one set of HTML and content. Doesn't matter if it's a 3" smartphone or a 52" 4K-pixel TV, your site should be ready to adjust to that.

            I'm not gonna bull**** you on this, building websites properly is a bit of a high dive when you don't even know how deep the pool is. There's a LOT to learn -- what tags can go inside which, which tags you should use for what reasons, and of course CSS itself which can be a bit tricky thanks to things like selectors and cross-browser oddities.

            Browser makers don't make this any easier -- even when we have clear specifications they often can't even seem to agree on how to implement them, which can make really useful "new" features like "Flex-box" undeployable in their current form for certain tasks.

            I've pretty much done a complete rewrite of that single page to show how it should be done, or at least done in a way that actually follows the HTML and CSS specifications, as well as accessibility guides like the WCAG. (web content accessibility guidelines). I often do these full rewrites for people with full text explanations of the how/what/why -- in your case that this is for charity motivated me to help; a number of charities have helped me out greatly since I was diagnosed with Parkinsons (or more specifically since the diagnosis was changed from "Medication induced parkinsonism" to full blown "yes, you have Parkinsons") and never let it be said I don't try to pay it forward.

            Originally posted by Medusa View Post
            I really appreciate the favor! I may not be able to look until the weekend now as I also have a day job that demands much of my time, but I am grateful for your help.
            This is going to be spread out over several long-ish posts. Most likely I'll even hit up against the post limit here (20k) a couple times. But in around 64-80k of text I'm about to give you a more than you are likely to get from the next six tutorials and three books combined -- covering basics they barely even take the time to mention and concepts that will long-term make building and maintaining said site easier not just for yourself, but the next person to come along.

            Which is often a problem with small charity sites -- the arrogance that "I'm the only person working on it" and not caring what the next poor sod is saddled with.

            So feel free to take your time, this is going to be a lot to take in, but it's not as hard or intimidating as people might make it out to be once you get in the right mindset -- and the two big keys to that mindset is "separation of presentation from content" and "progressive enhancement" -- again, using HTML to say what things are and (external) CSS to say what they look like, as well as slowly and incrementally increasing the appearance and functionality of the page.

            For now, the full demo of the single page rewrite can be viewed here:

            AGM and Committee - Lifelines

            As with all my examples, the directory itself:
            Index of /for_others/Medusa/ - CutCodeDown

            is unlocked for easy access to the gooey bits and pieces, as well as a few files that show the various stages of development.

            The process I use is outlined in this article:
            Introduction / Article Index - Progressive Enhancement - CUTCODEDOWN

            It's an intermediate level tutorial meant for people who've mastered how to open and close HTML tags, and a general knowledge of how CSS is applied -- so here I'm going to break that down even further for you to follow.

            The first thing I do when working on a site is to start with the content -- as plaintext -- as if HTML didn't even EXIST. If I don't have the content for the various subpages or even a home page, I start with a reasonable facsimile of future content. I say it time and time again, CONTENT FIRST. The same goes for adding new content to an existing page. I start out with that content as HTML, I then use semantic markup to say what that content is, THEN I go ahead and add HTML to it, again saying what things are... for now though, this is my base starting point for your page:


            I didn't put the table data in as that's complex and subject to change, but for the most part that's my starting point before I even THINK about HTML or appearance. I then "progressively enhance" the page by adding HTML to it... I'm going to stop here and continue in the next post so I don't bang up against that pesky post size limit... but that's where any good website should start life -- the content, in an order that makes sense, as if even HTML itself didn't exist.

            (Which is why I say the scam artists who start out making websites by screwing around in Photoshop or the WYSIWYG parts of editors like Dreamweaver have it completely back-assward)
            Walk the dark path, sleep with angels, call the past for help.


            • #7
              As I said, next we have the semantic markup, I made a .txt of that so you can see the tags without hitting view-source:

              Because this is the semantics stage we're JUST using the HTML tags that have meanings. There are two tags -- DIV and SPAN that do NOT belong in the HTML at this point as they have "no meaning" they just exist as hooks for style without saying what that style IS. In that way they are what we call "semantically neutral". In that same way I generally don't add classes or ID's unless I'm REALLY sure they're going to have such identifiers.

              Classes are primarily for when you have style that might repeat itself -- such as our two menus -- on tags you may use for other purposes. ID's are for unique indentifiers you want to target on-page with a hash tag or via scripting. BOTH can be used as "Selectors" in CSS to uniquely identify elements for style. We'll get to more on that in the next step.

              Pretty much at this stage we're working JUST with the stuff that goes into <body>. In modern HTML all tags and attributes should be lower-case. In fact upper-case tags and attributes were invalid in HTML 4 Strict, all flavors of XHTML, and ... honestly I never looked at how HTML 5 handles that. It's just not something you should have in your code.

              The first content tag you should have in any document is a H1. An H1 doesn't mean "Giant honking text" -- it means "the heading on all pages that ties the entire site together." You know how in a newspaper or book the name of the paper or book is on the top of every page and/or fold-pair? That's the H1's job. In the case of a newspaper yes it's presented bigger on the front page, just as it's presented bigger on the cover of a book -- that's presentation, NOT MEANING. It's STILL a H1. Generally a page should only have a single H1 unless you use HTML 5's new <section> tag, but I say avoid section and just use numbered headings and horizontal rules properly since that's what existing UA's can actually use, and it keeps the code simpler. A LOT of the new tags in HTML 5 strike me as pointless redundancies, something 4 Strict was trying to eliminate!

              At this point we're not working with <title> yet, but title is more akin to it being printed on the spine of the book. It's there to be shown in the window title, tab title, or as the text inside the link to your site on a search engine result page.

              I put an anchor and actual text inside the h1 even though when styled, I'm going to swap out that image for the text. Even though the image appears after it in the design, the h1 as the topmost heading should remain your first element. There are styling tricks for getting around the document order we'll use later on. The anchor and link to the root is there because most people expect the site logo to link back to the home page -- you'll see it on pretty much every site and it helps form the semantic link. Even though we're going to use an image banner later, we use text now as not all users can see images, and that image is -- care to guess? PRESENTATIONAL. It's not "content" so it doesn't go in the markup as a IMG tag.

              I'll also be pulling some cute tricks by remastering that image slightly later on.

              Next up is the first of our two menus. Menus are lists of choices, and we have tags for lists. Semantically speaking a menu is an unordered list, so that's what we use with each anchor going into a list item. We do NOT waste images to try and space the elements apart, that's padding's job. We just have that they are list items, that they are anchors pointing someplace, and their text. Clean, simple, easy.

              Next up is the H2. An H2 means "the start of a major section of the page" as well as "the start of a subsection of the H1 before it". I changed "AGM" to the full words because not everyone is going to even know what a AGM is. Never make assumptions like that and always try to include the un-abbreviated version of a term at least ONCE on a page! It also helps with search to have it there at least once since people might google "Annual General Meeting Lifelines" instead of "AGM"... Besides, you really don't want people searching for your meeting to end up on sites about marine batteries. That's just some content advice, not so much a HTML thing.

              Paragraphs in modern markup are NOT markers like in a Word document to say "put two carriage returns here" - they are wrapping tags to say "this is a paragraph" which is why as of HTML 4 Strict (aka 1998) the closing tag was no longer optional. As such if you have a GRAMMATICAL paragraph you wrap it inside <p>Paragraph content here</p>. Do NOT waste paragraphs on sentence fragments, non-flow text, or elements that clearly are not grammatical paragraphs like single content images.

              Inside that first paragraph I put your abbreviation in an <abbr> tag with the title saying what it's abbreviating. That's just good practice as well since again, never assume the people landing on your page know what every abbreviation means.

              After the two paragraphs we have an H3. Know how I just said a H2 means the start of a subsection of the H1 before it? H3 means the start of a subsection of the H2 before it. That's what it does. Care to guess what H4, H5, and H6 means? Natural progression. They do NOT mean "bold text in different sizes", they imply the document structure.

              UA's (user-agents) for non-sighted or visually impaired users rely on these headings to help in navigation, and search engines (who don't even have eyeballs) leverage this to help them parse the content of the page. There's more to writing your HTML than worrying about what it looks like on desktop screen media!

              In fact that part shouldn't even play into it! Content dictates markup, content plus markup dictates layout -- again why the people who start out with layout first in paint programs IHMO (and if you bother undestanding HTML) have it completely backwards.

              Another H3 and we have our two tables. That text really describes the content of those tables, so I made them the caption forming that semantic relationship. There are more tags that go into TABLE than TR and TD.

              That said, your tables for these bits of content made sense as you actually had TABULAR DATA... and you tried to use TH which is a lot more than I'd expect from a normal greenhorn.

              But amongst these other tags and attributes we have THEADto say this is the headings, TBODY to say this is the table content, and SCOPE to say which direction (col or row) the heading applies.

              Apart from that, the markup for the tables remains pretty close to what you had... though I may add more TH as the person effected could be considered the header for that row...

              I also added headings to the first table as that one was a bit vague. I dislike having rows of TD if they have no associated TH in a THEAD.

              Next is an <hr>... Horizontal rules do NOT mean "draw a line across the screen" any more than H1..H6 mean "bold text of different sizes". They mean a paragraph level break in content or change in subject where a numbered heading is unwanted or inappropriate. In our case here, using a HR is saying tayht what follows -- basically your "about us" info, is NOT part of the section started by <h3>Annual Report</h3>... without a H3, H2, or HR to say that, that's what non-visual UA's are going to treat it as!

              You don't want the line on the screen media CSS layout, hide the HR and convey it some other manner.

              I dropped the paragraphs as there's no clear structure to these fragments. <br> are about as fancy as I'd get here though I'd probably drop the e-mails altogether and add a proper contact form since the "obfuscate with entities" # nonsense hasn't stopped spambots in nearly a decade and a half, and mailto: doesn't work for most people who have moved to webmail instead of old-fashioned 1990's style mail clients.

              That would take a bit of back-end coding to implement, so I left that alone for now.

              Finally an HR to again say that the menu is not part of the contact information section before it, then the second instance of the menu again getting the same class.

              ... and that's the semantics. As is (once a proper HTML header and </body></html> is attached) it's pretty plain, boring, and unattractive:


              ... and oops, found a typo in code, missing / . Corrected.

              But that's what non-visual non-CSS user-agents have to work with. That's the base on which all other aspects and appearances have to build and what should be done BEFORE you even THINK about that. I probably keep saying that, there's a reason!

              The next step is setting up our DIV and SPAN for styling it, and attaching a proper header/footer. I'll cover that in the next post.
              Walk the dark path, sleep with angels, call the past for help.


              • #8
                Our "final" HTML adds a proper modern HTML 5 header, we'll use the modern UTF-8 character set instead of the outdated iso-8859-1 one (that again we were supposed to stop using ages ago), and tack on our DIV and SPAN. If the CSS wasn't present, it would look just like our previous .html because DIV and SPAN do nothing. That's called "graceful degradation" -- it might not be pretty, but you can still use it.

                Tables for layout rarely provides that properly, is harder to test that with since tables ARE style in those cases (only Opera classic ever let you test that properly)... and, well... there's something else I'm providing that tables for layout sure as shine-ola would fall flat on it's face attempting. Responsive layout. More on that in the CSS post

                Again I've provided a .txt file so you don't have to try and do a view-source in the browser:

                AGM and Committee - Lifelines

                All modern documents should have a doctype declaration. The doctype was optional prior to HTML 3.2, and Internet Explorer (and some other browsers) use it's presence as a trigger to say if it should follow the standards, or use an outdated rendering model called "quirks mode". As a rule of thumb, you're better off including it for better consistency across browsers, which is why it's no longer optional.

                The one HTML 5 uses is mostly lip-service. It's just big enough to trigger the desired behavior without sucking down a bunch of characters for stuff no legitimate user-agent or user gives a flying purple fish about. As it's so short, I move the HTML, HEAD and charset META up to the same line. This also acts as a reminder that I should NEVER change the order of these tags, nor should I EVER add anything between them. I also do this with the </head><body> and </body></html> tags... it's far too easy and common for experts -- much less beginners -- to accidentally screw up and paste something between those tags when the only thing that's valid between them is whitespace. It's just a handy-helper shorthand.

                Your original page used the outmoded http-equiv="Content-Type" that nothing ever really used properly, and we just don't use anymore.

                Next is a <meta> for "viewport". This tells mobile browsers not to lie about their width and height, or to apply any extra default zoom. Basically we're telling mobile we know what the *** we are doing, leave the page alone. The default mobile behavior operates on the assumption they are working with a page that was NOT built for mobile, and they try to compensate accordingly -- usually with piss poor results.

                Then we have a <link> to our external stylesheet. When possible style should be kept in a separate file from the rest of the page -- and there's a good many reasons for this.

                First we have media targets -- see how I have a media attribute that says "screen,projection,tv" -- that says that the style should only be applied to those targets. This allows me to apply separate style for things like "print", "braille" or "aural" if so desired. The HTML 5 validator now complains if you include "projection" and "TV", but there are still far too many Kiosks and consoles that still will apply their own styles or fail to apply our style if you exclude those, so on that I say ignore the validation warning. It's ok to ignore a warning if you know WHY you are ignoring it. Actual errors, not so much.. IMHO the media targets are zero business of the HTML specification anyways.

                As of HTML 5 you no longer have to say type="text/css" on CSS links if they are rel="stylesheet". In theory if your hosting is properly configured you never had to say that in the first place as browsers could give a flying purple fish, but now it's official.

                Another big reason for keeping the stylesheet external is caching. If people visit the same page multiple times, the CSS is only loaded once even though the HTML might be loaded again. Likewise if you use the same style across multiple pages, that style is already loaded and doesn't have to be loaded again, speeding up that other page.

                I usually use what's called "monolithic stylesheets" -- a single sheet for the entire SITE. As a rule of thumb, there is little legitimate reason for a site's main template (not counting certain plugins like tracking, disqus, facebook, etc) to have more than 48k of CSS in ONE file -- and that's why it's truly terrifying when you come across "frameworks" that start out at twice that, and completed sites that end up with hundreds of K or even megabytes of CSS spanning dozens of files. That's just developer ineptitude and blind copypasta in action.

                Something that sadly, far too many beginners fall into the trap of -- and never actually mature out of. See all the mouth-breathers who talk about bootstrap or jQuery like they're the greatest thing ever, when all they do is piss on every website they are used on, make said sites cost more to host, harder to maintain, and in general make developers work harder, not smarter!

                Moving on...

                When creating a <title> tag I try to use the format "page title - site title" so as to be as useful as possible for what the tag is for -- being displayed in the window frame, in the tab, and as the link to the page on a SERP. (search engine results page). Stuffing it with keywords or filling it with paragraphs of text doesn't do that. Keep it short, keep it simple, keep it consistent.

                ... and for Christmas sake use hyphens not vertical break characters "|". Don't know where that trend came from but it's ugly, inconsistent, and gibberish.

                Close out </head> and open <body> as mentioned before, and we have our first DIV. I gave it the ID #top so if at some future date you wanted to add a "back to top" link you could just do it as <a href="#top">Back to top</a>. I will use this tag in styling the page to apply the width constraints to the layout.

                Inside this I have another div that I gave the class "h1MenuWrap". I need this div to reverse the render order of the H1 and the menu itself so we can apply that banner image below the menu.

                On that h1 I applied two span for an advanced technique called "sliding doors" as well as "gilder-levin image replacement". This was just me getting fancy and I'll explain it better when we get to the CSS breakdown. For now just assume these empty span are hooks for applying style without saying what that style is.

                When closing a DIV I like to include a comment to say what DIV I'm closing. DIV are generic, meaningless, formless, and the close can end up so far away from your opening that you can easily lose track. A lot of people would do it like this:

                </div><!-- end h1 and menu wrapper -->
                But there are certain problems with this. The biggest being that comments between sibling level elements -- like two div -- can trip rendering bugs if those DIV or their contents recieve any type of fancy CSS positioning in certain flavors of IE and Firefox. YES, comments -- those things browsers are supposed to ignore -- can trip rendering bugs!

                Moving the comment before the closing tag means it can NEVER be between sibling-level elements. Simple minor change that I've seen people waste hours or even days hacking around the bugs in outmoded browsers to address.

                Then there's the "end" part... Gak... It's a </div>, you mean that's the end of something?!? WHO KNEW!?!?!

                It's also why I use classes that describe what things are, and NOT what I want them to look like. People will go nuts creating classes for every possible appearance -- like "red" or "extraSmallColumn8" -- or worse make cryptic classes like "xs-cl-8" then wonder why they're banging their head against the wall trying to keep track of things or using two or three times the code needed. Once simple wrapping class or ID can let you easily style ALL the semantic tags inside it in the CSS. Which again will be covered more in depth in the next post

                To that end, I also use "." if I'm closing a class or "#" if I'm closing an ID, or both if I'm closing both to make it again perfectly clear WHAT I'm closing. Hence my approach being:

                <!-- .h1MenuWrap --></div>
                A good article I always link beginners to on the subject of clear code and commenting is here:

                Whilst it's meant for C developers, I think anyone working on any sort of code -- even HTML -- can benefit from reading it.

                I then put a DIV around the content. We can use this for borders, or padding in certian directions, or what-have-you. It's often easier, faster, and cleaner to style a single wrapper once, than it is to style every single tag inside it each and every time you use them.

                It also gives us a hook to style the tags inside it without interfering with the same semantic tags outside it. For example if you decided to add a H2 to the footer you might not want the same appearance on both.

                I added classes to both tables and ended up switching those "member" and "name" columns to TH with the SCOPE of "row". This says that the information in that row is related to that person. TH aren't just for columns!

                We close out the div#content, and now we have our div#footer... again because it recieves a different style from the rest of the page. I put a extra classless dummy div inside it as a target for the section that matches the outer/body backround, but from there we just close out #footer, #top, and </body></html>. I saw no reason to give it a class or ID as I see no real reason for such a simple footer to have more DIV inside it. In the CSS we'll be able to target that div as "#footer div" since it's a div inside #footer.

                A LOT of so called "tools" to tell you about how to make your site better -- like the various "LINTers" and Google's once useful now gone to hell in a handbasket "pagespeed insights" will feed you chazerei like "keep your selectors flat", "don't use tags as selectors" and so forth. Don't believe a word of it. They want to make you write more markup, more complex CSS, and fatter bloated sites so they can sell you more expensive hosting... more so now that Google has gotten into the cloud hosting game.

                Which I suspect is the entire reason for the whole bait and switch they pulled with pagespeed insights. Now penalizes you ridiculously for not using a CDN... pretty interesting for a company now selling expensive CDN space. Even more suspect when they'll give pages that take a minute and a half to load thanks to being megabytes in size built from hundreds of files a higher rating than a page that's 64k in 8 files that loads in two seconds. Pagespeed my arse!

                I would skip the tracking script nonsense, if your hosting is worth a damn it should be providing the same useful information via the server logs using tools like analog or webalizer. Any information those don't provide is just statistical nosnense SEO scam artists and their ilk use to dupe you into shelling out for one of their garbage overpriced services.

                Basically watch out, the wolves are out there... and part of my telling you all this is an attempt to warn you away from the forest. If you go down in the woods today, you're sure of a big surprise... and they're not Teddy-bears.

                One final note about the HTML, notice how rabid I am about indenting my code? Consistent block indenting can help you see and prevent errors faster than anything else. If you are using a GOOD code editor, you should be able to select an entire block of code and just hit "tab" to indent every line inside that block, or hit shift-tab to de-indent it by one. I cannot overemphasize how much good code formatting practices can pay off for you in the long run. It's a simple thing to do, and well worth any extra "effort".

                ... and any good editor should remove any alleged "effort" it takes, as can keeping your HTML simple. 'cause you have to admit, for the final HTML for the page, that's not THAT hard, is it?

                The hard part is coming -- CSS. Next post.
                Walk the dark path, sleep with angels, call the past for help.


                • #9
                  Alright, first off before we dive into the CSS internals, load up the finished page itself:

                  AGM and Committee - Lifelines

                  Now try shrinking down your browser window until it's narrower than the layout... Surprised? The narrowing width is called "semi-fluid layout", it can expand and contract between two points. See how the layout itself changes adapting to better fit the available space? That's called "responsive layout" and done properly lets one set of HTML scale to everything from 192 pixel wide handhelds to 4K pixel displays.

                  See the logo -- see how the middle part expands/contracts to fit the available space? That's called "sliding doors" a cute "trick" for making banners that fit all page sizes. I also used responsive layout to remove bits of the image when they're too narrow to fit, and axe images completely at really small sizes. That text only appearance is much akin as well to what happens if images are blocked.

                  A LOT of mobile -- and even desktop -- users block images in less fortunate neighborhoods. You'll often have our cheesy overpriveleged eurotrash friends bragging about how "everyone has broadband" -- but for use back-woods Appalacia redneck white trash, the picture isn't so bright. There are still large swaths of the world where 56k dialup would be a good day and 33.6 remains the reality. Whilst if you are designing high end crap for people with more brains than money you might not care about those users -- you work on a charity to help people, or a public utility where people are paying their bills, or a bank, or a federal entity that by law has to meet certain minimums, these types of issues become all the more important.

                  Which is why if you have presentational images for a logo, you have a proper text-off fallback... and why if a image is presentation and not content -- like a logo -- it goes in the CSS, not the HTML.

                  The method I used for that is calld "Gilder-levin image replacement" and basically consists of applying our image(s) to a span, (or in our case multiple spans), applying the logo image as a background to it, and positioning the image over the text.

                  Some people might say that's "content cloaking" and could risk getting slapped down by search, these people clearly never tested it and are talking out their arse... at least if you use gilder-levin or some other technique that gracefully degrades images off to show the text. Using methods like text-indent:-999em or display:none to hide it? THEN you're content cloaking!

                  So the CSS got pretty fancy as I tried to quickly dot all the t's and cross all the i's... or...uhm... yeah. Let's dig into that. Follow along here:

                  The first section of my CSS is called a reset. Resets kind of suck, some suck more than others. They exist becuase browser makers are jerks who can't agree on how the specifications are supposed to work. Admittedly this is in part HTML's fault as HTML isn't supposed to be about saying what things look like, so browser makers went ahead and came up with their own defaults for appearance... so when it's time to add CSS, nothing starts out the same across browser.

                  A reset just nulls the things that are different. There are smaller resets that use the "universal selector" of "*" to target everything, but that can make some elements like <input> and <select> go haywire cross browser. There are larger resets like the blight Eric Meyer unleashed upon the web called "reset reloaded" -- but that wastes time changing values that are not different across browsers or you're just going to change again anyways. The larger resets are in fact what gives resets a bad name and makes many rail against their use.

                  As with all things, there's a middle-ground. The one I use just nabs margins and paddings on offending elements and borders on images and fieldsets. That's it, all it does. At a quarter of a K it's not so big as to be a worry, and not so general it can screw you up. Whilst those bears were at the picnic, this was just right.

                  Credit for this reset goes to a friend who passed away six years ago, Dan Schulz. He was brilliant and it was hard to deal with his death given he was half my age and it was over something treatable... pnumonia.

                  From here out I'm going to do all my selectors in bold to make them stand out piece-by-piece.

                  hr -- the comment there says it all. I'm hiding them as we'll be conveying that meaning other ways in the style. They exist in the markup for non-screen media non-css users.

                  @media (max-width:512px) -- a quick correction to older versions of Windows mobile and Safari much akin to our viewport meta in the markup. It's telling them we know what we are doing and to leave the font sizes the hell alone. One of the few times I'd use the universal selector. If we sent this to everythign without the media query, it breaks the ability for users to zoom in desktop Safari. (but not mobile? Apple really loves putting the derp in the herp!). Thankfully I've never seen a crApple or Windows mobile device that reported wider than 480px that needed this fix.

                  Ok, I know what you are thinking -- "what's a media query?"

                  They are a way to make all the code inside them only apply when the condition inside the parenthesis are true. So, by saying "max-width:512px" everything between the {} only applies when the screen is smaller than that.

                  The next media query is more complex:

                  (-webkit-min-device-pixel-ratio:2) and (min-width:1600px),
                  (min-resolution:172dpi) and (min-width:1600px)

                  The comment says it all, it's there to double the font-size for "HDX devices". These are a fairly new thing and while Apple's retina displays will STILL flat out lie to us about their resolution even with the viewport meta -- and that's a good thing in practice -- things like Amazon's Kindle Fire HDX tablet does not resulting in miniscule undersized pages the user has to zoom. I just double the font size across the entire page since I use %/em... we'll get to more on that in a moment. For now, just know that there are TWO conditions here -- the first for older Android devices that still recognize the -webkit- prefix, and one that recognizes the min-resolution property. In both cases if the screen is big enough in pixels and in the pixel to inches ratio, we double-up everything.

                  That's complex, but really everything from this point up is copypasta that I use on every site. We don't get to the page unique stuff until...

                  body -- I pad the top and bottom to make it purty, pushing #top away from the top/bottom edges. I set a max-width so that browsers that can't do media queries will stop trying to make the layout smaller than that. The background-color is obvious, and I set the font size and colour most commonly used across the whole page here.

                  I state the font size and line-height in either % or em (they're interchangeable on font-size and line-height, 100% == 1EM, they are NOT interchangeable on padding or width!) so that they are based on the browser or OS default. This means that for users who have a non-standard size set for accessibility or usability reasons the ENTIRE page's layout and text will auto-enlarge or shrink to thier preference, without having to apply zoom!

                  There's this thing called the "web content accessibility guidelines" (link below) that tells us how to make pages accessible to as many users as possible. Depending on the type of website or the client you could be fined or sued for failing to obey it, and one of the biggest things it says is to use EM for font sizes, so use 'em!

                  To that end, you'll notice all my min-width, max-width, and paddings when involving text or major flow sections are done in EM.

                  One thing to remember about EM is that they are multiplicative. For example if you set:

                  <div style="font-size:1.5em;">
                  	Test 1
                  	<span style="font-size:1.5em;">
                  		Test 2
                  Test 1 would be whatever the body size is times 1.5. "test 2" would then be 1.5 times that larger. So for example if the body is set to a 16px default (the most common) "test 1" would be rendered as 24px in side, "test 2" would be rendered as 36px! 16 * 1.5 = 24. 24 * 1.5 = 36.

                  Some people will use the new REM measurement instead of EM, but browser support for it is spotty if you still support poor people (like those who might need the services of a charity?) instead of being an elitist prick, and really if you can't handle a little basic fourth grade level multiplication and division, you probably shouldn't be working on the code side of websites.

                  Admittedly there's a reason colleges now have to teach remedial math to freshmen, given a modern high school diploma seems to ingrain all the math skills of a 1970's 3rd grade education. When high school kids can't hande multiplying by ten in their head, you have no business trying to teach them Algebra, much less Calculus!

                  Reminds me of Jethro Bodine... dun got hisself a sixth grade education; hard to fault twelve years o' schoolin'.

                  Rant off, one other thing I do is when I change the font-size I change the line-height. This is because you cannot trust line-height to inherit properly or adjust. There is a LIE repeatedly being pushed on another site that if you omit the metric on line-height, aka just say "line-height:1.5" instead of "line-height:1.5em" that it will inherit... this is almost entirely false if you are building a layout with EM instead of pixels and is one of the number one things that breaks websites for users of non-standard default font sizes.

                  To that end, by the time I say:

                  font-size:100%; line-height:150%; font-family:arial,helvetica,sans-serif;

                  I'm at as many if not more characters than the full condensed font declaration that nabs everything:

                  font:normal 100%/150% arial,helvetica,sans-serif;

                  So as a rule of thumb, in all but the rarest of cases if I'm going to change the font size, I use the condensed font property and declare all of it. The "normal" part is font weight or style -- aka bold, italic, etc... if you omit it some older browsers may in fact ignore the whole line!

                  In the case of body, I use 85% as that delivers 14px for "16px/96dpi/100%/VGA/Windows Small/default" font-size users, and 17px for "20px/120dpi/125%/8514/Windows Large/Win Vista+ Medium/Pick a freaking name already" users. On my media center which uses the new windows large -- aka 24px -- it delivers 20px (or 21px in FF for some strange rounding bug reason)... that size seems to be the most comfortable for the majority of people when you use a sans-serif font like arial or helvetica.

                  Beware that not all font facess at the same font-size result in the same sizes. I made this chart AGES ago to show that:


                  Those are all declared as 1EM in the document that created it... So be ready for that.

                  Also keep in mind that as a rule of thumb, serif is for print, sans-serif is for screen. There's a conventional wisdom in the print world that serif fonts aid legibility, but they have 300dpi or higher rendering where the spurs, ears, plattens, and other serif elements of a font can render clearly. Screen media ranges from 72 to 150 pixels per inch, where there just aren't enough dots to render those parts clearly making sans-serif fonts the obvious winner.

                  Also be leery of custom fonts, use them with an eye dropper for flair, and don't put them on flow text. Many popular webfonts right now (like openSans) are a giant middle finger to legibility due to the bars and beams of their glyphs being too thin, requiring higher colour contrasts than even the WCAG AAA might suggest. This gets worse the smaller the size too in the age of sub-pixel font hinting.

                  So now that we have the body set, let's move on to...

                  #top -- our topmost wrapping div. I set a maximum width so that our long lines of text don't get too long. Really long lines can be hard to follow -- that's also why I use a much higher than default line-height to aid in that situation. Same way our schoolteachers used to ***** at us that if you were going to type your work, double-space it.

                  The auto-margin on the sides centers the page... oh, dunno how good your CSS knowledge is, I know you had SOME inlined in the code...

                  When condensed properties like border-width, padding, or margin are used, they work in the order top, right, left, bottom... and if you omit one from the end, the opposite sides value is used instead.


                  margin:0 auto;

                  Is the same as saying:

                  margin:0 auto 0 auto;

                  Just a handy shorthand.

                  Finally we set the background colour for most of our page. In theory if we wanted the ACTUAL background to show through for that one section of info, I would NOT set this here and instead set it on .mainMenu and #content, not setting a background on "#footer div"

                  .h1MenuWrap -- To move our H1 and it's associated image down under the menu, I pad the bottom of the wrapper the height our H1 image is as a space to slide it into. Setting position:relative on this DIV means that if we position:absolute an element left, right, bottom and top will be based on this DIV and not the document BODY.

                  h1 -- and here we move our SOLE H1 (remember a page really should only have one unless you're using HTML 5's pointless <section> tag) to be absolute positioned at the bottom of it's parent. When absolute positioning an element it's usually best to set the width as it doesn't always inherit from it's children properly. Conversely I prefer to let the element add up to the desired height instead of trying to create a fixed height. Less math and no padding issues.

                  ... oh, padding issues. In the "standard" box model if you set a height or width, padding and border are added TO that height/width. So if you said "width:50px; padding:8px;" the result would be 66px in width. Again, basic math. there are ways around that, but generally it's not that complicated to keep track of.

                  To that end:

                  h1 a -- Detroit avenue... Uhm, that's a Vanilla Ice joke. I'm rubber stamping my expiration date on my head again.

                  Anchors are inline-level elements, which means they default to display:inline... such elements shrink to their content instead of expanding to fit, and ignore top and bottom padding. Since I want the WHOLE logo to be clickable and the text centered, I set display:block and it fits to width and I can pad the top and bottom.

                  I strip the underscore off the anchor for obvious reasons. I advise AGAINST doing that inside your #content area as that's bad for usability -- just as using underscores inside your content when it's not an anchor confuses the ever living piss out of users. Makes them about as incontintent as Dodo's in Ark:Survival Evolved. There are only a handful of places where stripping underscores off anchors is warranted -- menus, logo's... image based links. Otherwise, leave them be.

                  Now, you'll notice I set the font size in pixels -- this is because we're going to be under an image and images are ALWAYS pixel based! This is one of the FEW corner cases where "always use EM" manages an exception. There are ALWAYS exceptions.

                  The line-height is fun... 64px line-height + 43px top padding + 43px bottom padding equals? Our 150px of image height. JOB DONE.

                  Slap a fallback background-colour in there for images off appearance and the repeating part of our logo image and we're good to go...

                  Wait, repeating part of our image? I went high hog here with an advanced technique, just to show you the possibilities and to make you aware of accessibility and designing presentation to fit the layout -- instead of the reverse course of making a presentation you have to try and shoe-horn your content into.

                  IF you look at how I remastered the logo image:

                  I put another very powerful technique into play on this, the incorrectly named "CSS sprites".

                  By putting the image in three parts in one file, we can "slide" it around as a background revealing the parts we want. The top part is a repeated background, the middle is the left side, the bottom is the right side. It then acts like "sliding doors" revealing the repeated center as the width grows.

                  A lot of these things -- like sliding doors -- have names that explain how it works VERY well.

                  The advantage to using a single file is that EVERY single separate file request made to the server adds time to how long the page loads, REGARDLESS of connection speed at EITHER end. I believe I mentioned that in the previous post about the monolithic stylesheet? Same goes for JavaScript. Less files == faster page loads, so if you CAN combine multiple files into one, DO IT!. It is often even worth larger file sizes.

                  If you've ever uploaded files via FTP, you might notice that it takes longer to upload 100 files 1k in size each than it does a single 100k file. That's handshaking -- abeit FTP's handshaking is ugly and a thousand times worse, but it's the same concept.

                  Also why if you are managing BIG sites, I usually suggest going someplace like Starbucks or Panera Bread while the college kids are in their with their croissants and metrosexual goofball names for small, medium, and large -- and see what that single free shared connection is like with your site. Can be a real eye-opener.

                  To show the left and right halves we have:

                  h1 span -- targets both span with the values they share that are the same, and I set the values for the outermost one as well. Full width, positioned over the text hiding it when images are enabled, and fixing the height to the image height. By saying "bottom right" as our background-position we get the right-hand image showing. For the left hand:

                  h1 span span -- the span inside the span. We restrict it's width to only show the left half letting the underlying background of the span and the anchor show through, whilst hiding our text if the right half fails. We just change the background position to show the middle slice. I did this in pixels as on zoom Firefox can do funky screwball rounding errors on "background-position:center left;"

                  Uhm, I'm going to have to stop here. Got to put some time into one of my own projects, and I've got friends coming in to watch last night's WWE PPV since somehow we all missed that it was yesterday... but you said you likely couldn't take a good hard look until the weekend anyways so...

                  Take your time, go through what I've written out so far, and if you have questions, ask. I know this is a LOT to dive into all at once, but if you are serious about maintaining that site I'd highly suggest fixing the problems and switching to modern accessible techniques. ESPECIALLY if it's a charity... Go slow, digest what I've written, and I'll post up the remainder sometime tomorrow when I have a break in what's looking to be a busy day. (Today I mostly got to sit here with my thumb up my backside waiting for a paying client to call back with revisions. Some medical retirement this is turning out to be.)

                  Even if the site is for for society's worst. If anything, that's an even higher moral ground to take. Forgiveness is an increasingly lost art... much like charity and patience.
                  Walk the dark path, sleep with angels, call the past for help.


                  • #10
                    Ok, where did I leave off? Oh, right after the h1... so on to:

                    .mainMenu -- turn off bullets, center the text, pad it. YAWN.

                    .mainMenu li -- I set these to display:inline as IE and FF both can behave strangely if we try to set inline-block or much of anything else on these. The worst bug possible is IE8's "staircase" bug where instead of sitting on a single line, they'll, well... position like a staircase. -- when possible I just set LI to display:inline and style their children instead of them. It's just safer.

                    .mainMenu a -- inline-block lets us set padding top and bottom, in modern browsers if the element were inline top/bottom padding is ignored. I used uneven top/bottom padding to compensate for arial and helvetica failing to account for descenders properly making them appear unevenly spaced. The white-space:nowrap prevents their contents from being dropped to a new line separately, from there we just turn off underscores, set the font bold and colour it. Not too fancy.

                    .mainMenu a:active,
                    .mainMenu a:focus,
                    .mainMenu a:hover
                    -- the hover and keyboard navigation states. In theory :active is only supposed to trigger if the link has been clicked on but hasn't moved us away from the page, but in practice some older UA's use that for keyboard navigation instead of :focus. Really most of the time if you're going to add style for a hover, just set all three psuedostates together.

                    #content -- the overflow:hidden is just so we don't need any sort of extra clearing should you decide to have floated content. Floats are by default ignored by their parents for determining height, overflow on that parent makes them obeyed.

                    I pad the top but not the bottom so that we can pad the bottom of content elements instead of using margin. "Margin collapse" -- how margins can overlap each-other is often a royal pain in the arse, so IMHO you're better off just using padding when possible.

                    #content h2 -- center it, pad it, style the font. Nothing fancy. Again I use the full condensed declaration since it's nearly as many characters as saying both line-height and font-size, and if you change font-size redeclare the line-height.

                    #content h3 same...

                    #content p -- as I said, pad the bottom instead of margin. No collapse headaches/issues. Since I use a taller than default line-height on flow text (1.5em aka 150%) a 1em padding between paragraphs just "feels right" in most cases.

                    .members -- our content table styles. I took some stylistic liberties to make it a bit more attractive AND usable. The classic thick borders can actually compromise usability, so like good old-fashioned chart paper I go with alternating the row colours.

                    Here though, we just tell the table to expand to fit the width, margin the bottom (can't use padding here as that would go inside the table not after), set border-collapse so we don't have to say cellpadding="0" cellspacing="0" in the markup, and a nice subtle thin border.

                    .members caption -- the text describing the table, stylistically we're just treating it like we would flow text.

                    .members th,
                    .members td
                    -- elements that get the same style I group together, in this case our TH and TD both get the same padding. I've always found that twice the vertical padding as your horizontal looks the best for content like this - it goes hand in hand with most fonts having a 1.5:1 or 2:1 aspect on the standard caps-width compared to the distance between the descender and ascender line.

                    .members thead th -- the ones in the head get a different colouration.

                    .members tbody th,
                    .members tbody td
                    -- the default background colour and centering for the majority of our cells. I do it this way so I only have to set what's different on specific elements instead of saying it on each and every one individually.

                    .members thead th:first-child,
                    .members tbody th
                    -- align the first column left... stylistically centering the first column most always looks funny even when the rest are centered, particularly when the content is text. nnGroup had an article on that a few years ago, can't seem to find it now. :first-child let's us target just the first TH inside THEAD, whilst we only have one TH on the content rows.

                    [b].members tbody tr:nth-child(even) th,
                    .members tbody tr:nth-child(even) td[/code] -- nth-child is a VERY powerful property that lets us target elements based on, well, which child they are. "even" and "odd" are the easiest and most useful and, well, do exactly what they sound like. By targeting just the even rows for a different background colour we're able to do that wonderful row-striping that makes the table more useful to visitors.

                    #footer div -- pad it, center the contents, make the background match body. Nothing fancy..

                    ... and that's how I'd do the "desktop" layout portion. Note that's JUST the desktop layout which I use as a starting point because that's the most likely lowest common denominator. "responsive layout" using "media queries" can target any mobile device we actually care about customizing for -- what we can't target is older desktop browsers that don't know what media queries are, so THAT's your starting point.

                    A LOT of people say "mobile first" on design, and IMHO like a lot of things "designers" say that's utterly back-assward. You don't start with what you CAN customize via specific targeting, you start with what you can only hit via blanket targeting.

                    So, on to our media queries, I'm just going to summarize these:

                    max-width:360px -- this media query exists to remove the logo when the screen is too small to show either half. I also swap the font size to EM and adjust the padding and spacing of the heading accordingly so it's accessible.

                    max-width:53em -- the point at which we no longer have enough screen space to "waste" on having the background show through, and the point at which the menu would drop to multiple lines.

                    First, I kill the body padding and lower the min-width to the smallest mobile target we are likely to care about. Again, the global min-width on body is for browsers that don't recognize media queries, so since on this query we KNOW they're available we lower that minimum.

                    The for .mainMenu having just one or two menu items drop looks uneven, so I just give it a max-width and center it so that it's split in half dropping at least three or four times when too narrow. I also increase the size of the padding on the anchors so that they are finger-sized since we get this small, it's highly likely we're looking at a touch interface.

                    A more robust version of the page might actually hide the menu behind a "show menu" link or a hamburger icon. If you're interested in adding such functionality, have a look at my article here:
                    Mobile hidden Menu without JavaScript - CUTCODEDOWN

                    Finally I lower the side padding on our #content area since as screen space dwindles we want to try and fit more content in. Those massive side paddings that look good at 10" tablet/ultra-mobile laptop and larger off the 16px default font-size just get in the way at 7" tablet and smaller sizings.

                    ... and that's how I'd have written that entire page.

                    I know it's a lot to take in and you said you'd not have a chance to look until the weekend, but take your time and when you have questions, fire away.

                    There are other steps on a site like this one that I'd take server side involving things like PHP to make maintaining the page easier for your -- if interested we can cover that too at a later point. I'm going a little above and beyond in this one because it's for a charity; I tend to do that a bit too much regardless of which charity it is. I'm a bit like Ben Franklin on that.
                    Walk the dark path, sleep with angels, call the past for help.


                    • #11
                      Hello Deathshadow

                      Wow - thank you so much for that. I will begin to work my way through it all shortly, though it may be a slow process! I was so sorry to hear of your friend Dan's death; my deepest condolences.



                      • #12
                        Originally posted by Medusa View Post
                        I was so sorry to hear of your friend Dan's death; my deepest condolences.
                        It's been six years, I was over it until people started in with the noodle doodle BS about Pneumonia not being a real disease in regards to Hilly and so forth... since that's what killed him.
                        Walk the dark path, sleep with angels, call the past for help.