HYPERTEXT & CODE: Safari as Prime Browser Check

October 29th, 2010 by susan

So far, Safari has been able to point out various HTML errors that Firefox automatically appears to override and fix.  I’ve used Firefox and like it, but when working on a hypertext piece that’s going to go online, it’s become obvious that you need to pick one of the pickier browsers to work with.

What worked beautifully in Firefox didn’t work with all browsers. I have FF and Safari on the Mac–which is naturally where I’m working since I use Tinderbox to start the piece out. On my PC, which I rarely use but have for backup and to hold all the years’ worth of stuff pre-Mac, I use Internet Explorer as the default browser and have since downloaded Chrome and Opera. That gives me two operating systems and five browsers to check the work. Also, I might add, different screen resolutions because of the various monitor sizes. This led to the last problem I need to deal with, the background images which looked great on my Mac, but fell a couple hundred pixels short on the PCs.

Safari’s refusal to accept font color tags unless they were posted before each paragraph of hidden or stretch text (in a group of three paragraphs, the middle one would return to the main text color) was similar to one of the other browsers that would only take the first paragraph and then return. I’m sure there’s a more professional way of doing this–which is why I wish I’d learned coding from the basics instead of jumping into the middle–but I did manage to fix by tagging each paragraph.

The problem of an uncentered image on the first page, where I inserted a 400px wide image instead of the 550px, I had used the proper code within the head:

<style type=”text/css”>

.stretchTarget {
margin: none;
margin-left: 100px;


It wasn’t until I studied another page where I’d done the same thing in stretchtext that I discovered I had changed a headline size from h1 to h2 but hadn’t changed the closing tag. (The image came from the linked headline) and so even though the headline was okay, it messed up what followed–the image.

So while I’ll likely still work in Firefox, I’ll know enough to doublecheck immediately each page in Safari as I work. Of course the best way would be to run the pages through the W3C Validation Service, but that shows me that my pages really have no right to be working at all and just makes me feel bad.

2 Responses to “HYPERTEXT & CODE: Safari as Prime Browser Check”

  1. Mark bernstein Says:

    The firebugs plug in for Firefox can be a big help.

    So can bbedit’s “check syntax”.

    Also, learn to distinguish real issues in the validator report from mere fussiness; the validator complains too much, but you can distinguish real problems from mere nagging.

  2. susan Says:

    Hmmm. I have the Firebugs plugin and should learn how to use it. Just tried it out and familiarized myself with it a bit more. I haven’t heard of bbedit’s “check syntax” but will look into that. The validator was a huge help when I was first learning css and html and really, I should take it with a grain of salt, as you suggest, and learn to spot the real problem areas vs. the slightly improper. Particularly if I’m getting into HTML5 soon. Thanks, Mark!

Leave a Reply