Trying To Code Across All Browser Platforms

I’ve finally gone and done it; I changed the theme on my business blog, and if you’re so inclined you can take at look at it here.

I love the new theme, but of course it has some issues, just like many other sites do. One of the worst things about coding is that, sometimes, it doesn’t work across all browser platforms. Firefox is my browser of choice, and it looks perfect in Firefox; there’s nothing I can do to make it look bad. However, in IE7, I noticed that if one changes the size of the font, it suddenly doesn’t look right. I had to reduce my settings so it would fit properly, and that shouldn’t occur. It also looks bad in Opera, no matter what I do there.

The problem is with CSS, cascading stylesheets, which are great for allowing you to make changes to a bunch of webpages all at once, but sometimes is bad because not all browsers will view it properly. There’s also sometimes problems with PHP, which many people use to create dynamic sites or programs to be used on a website. Right now, for instance, some of the gaming programs on Facebook aren’t working properly in Firefox, and the programmers know it, as they’ve put out the message asking people to use IE instead.

This is a major gripe for programmers, and one of the reasons why many of us who create websites will never fully give up HTML. For all this noise people want to pass through in saying that CSS is a cleaner way to code and will allow search engines to go through your site easier, the other side of the equation is that if the sites look like they were put together by a child then who’s going to stick around to see that the code looks good? There’s one site I manage that was totally created in CSS, and it seems that every time there’s a new browser upgrade of some kind I have to go in and change something in the code to get the site to center again. Frankly it’s irritating, and makes me want to get all of the top guys for each of these browsers together and go an old Three Stooges slap on them. Heck, since I’m talking about it:

In general, I know we’re supposed to be coding for IE first, since it’s still the most prominent browser in the world, but we don’t have to like it.

20% off Custom Web Site Design

Digiprove sealCopyright secured by Digiprove © 2013 Mitch Mitchell

11 thoughts on “Trying To Code Across All Browser Platforms”

  1. A few years ago I had the displeasure of looking at some of my sites in pIE 3.0 (Pocket IE), which doesn’t support CSS at all.

    There is nothing quite like looking at your site without its style sheet to reveal the most serious design flaws. And while not many people are even using pIE 3.0, some of those design flaws can still affect how your site looks in other mobile browsers, especially if the visitor is viewing the Google Mobile version of it.

    So once you are finished fighting with and coding for all the desktop browsers and all their CSS quirks, don’t forget that more & more people are surfing the web on cell phones & PDA’s and your job isn’t finished yet.

  2. Good point, app. Everyone used to code for IE, which doesn’t always accept CSS, and now it’s getting harder to get it right across the board. I notice my sites look different on the Palm, but just figured it was how it was because it’s a Palm instead of a regular browser.

  3. There is certain CSS that some mobile browsers will completely ignore, so that the page can be properly formatted for viewing on a small screen without a lot of sideways scrolling.

    Another reason why certain CSS is ignored, is to cut down on the bandwidth & disk space needed, and to make the pages load faster by removing background images.

    Unfortunately, a lot of designers don’t know any better and use header banners as the background in the header box, rather than as an image in the foreground. This means that the chance of it being removed from the page is quite high when viewed in some mobile browsers.

    They also position other images incorrectly, that should be backgrounds for elements and they just use the z-index to set them behind other elements. This is also a bad thing to do, because this will cause the images to load seperate from the element you wanted them to show behind.

    When viewing a page like that in some mobile browsers, you’ll see no header graphic, and a bunch of nonsense images, followed by the page content.

    Some designers also don’t order the content properly, placing huge menus as the first thing in the code of the page, causing mobile users to have to scroll past the big menus to get to the actual content they want to see.

    The proper way to code it, is a link that allows mobile users to skip to the sidebar, that anchors to the sidebar. (it is possible to only have that link visible to handheld devices, in your CSS) That link should be followed by the code related to displaying the header image of the page, then the content, then the more important sidebar, followed by the lesser important sidebar (if you have 2 or more), followed by the footer content. Using CSS, position these on the page properly for desktop browsers. Now mobile users will see something much less annoying and much more useful and tailored to their special needs.

    Bonus is that the content being listed first, before the sidebar menus, has SEO value.

    app´s last blog post..Get Yourself Together in One Feed

    1. That was absolutely great stuff, App (sure that’s not your real name lol). That’s the failing of CSS, and I’m surprised WC3 hasn’t come up with a full standard for it yet.

      1. It wouldn’t matter if they did, as the fact that you have a full standard still doesn’t mean that developers will follow it when coding browsers (there is still stuff in the existing CSS standard that NO browser supports), nor should they in every case, since handheld devices are very different than desktops.

        Nor does it mean ignorant web designers will suddenly know how to code a page properly.

        Never blame a language for the bad grammar of people that try to speak it.

        The issue isn’t that CSS fails, it’s that too many people using it don’t know what they are doing or don’t really care, as long as it looks ok in whatever browser/version they happen to prefer for their own personal use.

        I love the lame excuses I get from some about how if the page looks ok in Firefox but screwed up in IE, that it doesn’t matter because people shouldn’t use IE any way. Or the ones that say that it was intentionally designed not to work in IE because they hate Microsoft.

        Or an even better example: I reported a bug in site behavior on MyBlogLog to the developers, telling them what browser I was using (K-Meleon), making the fact that the browser uses the same rendering engine as Firefox, quite clear.

        Their reply was that they only support IE and Firefox and I should switch to one of those browsers. The fact that the issue would also affect Firefox completely went over their heads.

        You can’t blame CSS for that kind of stupidity.

        As far as “App” being my real name, it’s been my real life nickname for close to 30 years. It’s short for “April”.

        When I was a kid, people had this strange need to shorten my already short name, and it was usually to “Ape”, which started a bunch of rather insulting jokes that lasted many years, till a friend of mine changed how it was pronounced to “App”.

        The fact I went on to become a coder is just an ironic coincidence.

        app´s last blog post..Get Yourself Together in One Feed

      2. It’s a great ironic coincidence, though; almost like you were predestined to do it.

        For my sites, I only use CSS for some very basic stuff, such as being able to change the colors on all pages at once rather than having to go in and write the code on every page. As I mentioned in my original post, having to go back into the one site I manage that I didn’t create and have to once again figure out how to center the page because it’s offset by both IE7 and FF3 is an irritant I’d rather not have to keep dealing with, but I’m also not in the mood to go in and recode the entire site with some HTML to hold it steady from this point on. That may be lazy, but I tend to see it as not being profitable, since the client wouldn’t pay for anything more than what the normal maintenance agreement calls for. But one day I just may do it and get it over with; luckily, there’s not tons of pages on that site, unlike my own sites.

        Still, I wish I could figure out how to keep the frame on my business blog steady across all platforms also, but with blog software, I can’t figure out how to get into the HTML structure to make any kinds of changes, and it’s probably a good thing I don’t even try.

  4. I would not suggest messing with any of the code in wordpress, itself, because every time there is an update everything you did will just come undone and be overwritten by the new files.

    The only html I would consider messing with would be what is included in your theme’s files, and if you want to mess with that, just open index.php from your theme in a text editor and take a look. There are a few others to take a look at, as well, such as page.php, sidebar.php, and maybe a few others, depending on how the theme was coded.

    If you want something centered, it might be just a case of locating it in your theme’s code and throwing an alignment div around it. Simple enough and it will last the life of your theme. (just remember that it relies heavily on PHP includes and you should be able able to figure it out)

    I would not suggest doing anything on a live site though. Better to have a copy of Apache, MySql, PHP installed on your local machine and set up with a test site.

    It’s a good way to test plugins and WordPress upgrades too, before putting them on your live site and ending up with unanticipated problems that could screw up your whole blog.

    app´s last blog post..Get Yourself Together in One Feed

    1. Oh, the centering I was talking about was for one of my client’s websites, and it’s not a blog, so I’m good there.

      And here, yeah, I noticed everything was in a php, and I haven’t really wanted to touch those because I’m not quite familiar with that stuff just yet. But you’ve given me good information again because I’d been wondering how people could test new blogs and blog formats offline, and you’ve just given 3 programs for that.

  5. If you want to make it easy, install Wampserver and you’ll get all 3 in one shot.

    Just don’t make it accessible from the internet (security reasons). Keep it local. Don’t forward any ports in your router for it, and don’t let it have any permission for outside connections in your firewall.

    PHP includes are great, just like CSS. For example: you don’t need to have the same menu code on every page. Just make one menu, putting all the html code for it in a txt file and give it a .php extention and use a php include to put it on pages, just where you want it. Give every page a .php extention instead of .html.

    The server will assemble everything before sending it to the visitor’s machine. Final result on the visitors side is a normal html file.

    Makes it easy to change stuff if you keep every element in it’s own .php file. That way you don’t have to sift through volumes of html code to find what you want to change…just open the file for the element and change that, and it changes on all pages that use it. And you can use the same element files over & over on all pages in your site (in different ways too).

    Bonus is that you can add more complicated server side scripts if you feel like learning the whole PHP language.

    app´s last blog post..Get Yourself Together in One Feed

    1. Good stuff, but a quick question. Did you read my post Fear Of The Hack, or, more specifically, John’s response to it? He seems to indicate that PHP scripting and some other stuff, if not done right, leaves your sites vulnerable.

  6. Long ago, you had to code every single page in full, on a static site, including every color change and image background. If you had a 100 page site, you had to change 100 pages to change the color of something that appeared on every page.

    Then CSS came along and let you do all that from 1 file.

    A long time ago if you had a menu on your site and you had 100 pages, the menu code had to be on all 100 pages and if you wanted to add a link, you had to edit 100 pages. Then along came frames, which let you make 1 menu page and the menu would load the desired page in another frame. But frames are icky and have issues, particularly with being able to bookmark a page on a site.

    So how do you not have to edit 100 pages on a static site if you want to add a link to the menu? PHP includes lets you do that and create a completely modular site.

    There is no user input boxes, databases, or any other stuff that would put your static site at risk of being hacked by simply assembling it with includes.

    While badly written scripts can put your site and server at risk, a simple include containing plain old html inserted into another plain old html page is 100% perfectly safe.

    Don’t be afraid of using includes containing plain old html. And once you start using them, you’ll wonder how you got along all this time without them and never want to stop using them. It’s more liberating than the day you discovered CSS.

    As far as more complicated things in PHP, some of it can put your site at risk if it’s coded badly, but so can outdated software run by your hosting company.

    A good friend of mine had his site hacked and a malicious script added to a bunch of pages to try and force visitors with older browsers to download malware. It was discovered pretty quick, the site was taken offline, and nobody was infected, thankfully. The forum thread I linked to is a really good eye opening read, and I highly recommend it.

    How did they get in to add the script to pages? An old outdated version of Subversion was installed on the server, which was exploited using a script kiddy kit that any 8 year old could download and use.

    The problem with that is that you don’t really know everything your hosting company has installed on their servers and if it is up to date. There is no way you can be fully sure everything is up to date unless you are paying a lot of money for a dedicated server and being very diligent to keep it all up to date, yourself, AND know a lot about web server security.

    So don’t be thinking that plain old static html sites are any safer than another type, because they are not. They are just safer from certain types of attacks.

    app´s last blog post..Get Yourself Together in One Feed

Comments are closed.