Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Programming The Internet IT Technology

How Do You Test Your Web Pages? 226

Pieroxy asks: "As a web developer, both professionally and personally, I try to always make sure what I write works in every browser at my disposal. When the choice came for me to choose a platform for my PC, I went the Windows route, because I cannot afford not to test IE on all those websites/applications. But now I am facing a problem with all browsers that don't have a native Windows port, such as IE5/Mac, Safari/Konqueror. kde-cygwin helped very little because the version of Konqueror shipped doesn't display most JPEG, making any testing worthless. IE5 for Mac should die soon, but is still widely used as being the default browser for so long. How do you test your web pages? Have you noticed discrepancies on how a specific engine (Gecko, Opera, KHTML) renders content on different Platforms? Do I need a Mac and a Linux machine to make sure it is working on these platforms?"
This discussion has been archived. No new comments can be posted.

How Do You Test Your Web Pages?

Comments Filter:
  • by Numeric ( 22250 )
    thats usually your best bet
    • by Hank Reardon ( 534417 ) on Tuesday July 20, 2004 @02:10PM (#9750976) Homepage Journal

      Not really...

      There are a ton of bigs with Internet Explorer and the way it "works" with the standards, particularly CSS Positioning.

      A site I frequent for various work-arounds to get things working under both IE and working CSSP browsers is A List Apart [alistapart.com]. It's amazing the number of funky comment-within-comment hacks that you have to perform to get sites to display properly across two or three "standards compliant" browsers.

      • by britrock ( 684244 ) on Tuesday July 20, 2004 @03:41PM (#9752124)
        I generally write to the standard, and then spend a few hours after the fact making it work in ie. Safari/Khtml and Mozilla/Firefox are really very good at following the standard.

        There are of course quirks in all of the browsers though. There is a REALLY great site to help with that though. quirksmode.org [quirksmode.org] lists each css attribute, and has a table showing which browsers it works in, and which it mostly works in and so on.

        You really can do some amazing things if you follow the standards AND work around the quirks. I try to avoid the comment-within-comment hacks, because they are ugly, and there is almost always a better way. Once you have a good knowledge of the quirks its not so bad.
        • Great link! A List Apart gives me some great ideas in implimentation, but the organization is more like a magazine. I've often wished for a tabular list of stuff I can use and stuff to stay away from.

          Thanks!

      • There are also some general guidelines to follow for writing interoperable webpages.

        Someone recently commented in my livejournal [livejournal.com] that my layout needed some work and she'd do a new one for me. I agreed, but I said that if she were to do a new one...

        i don't want my frontpage changed. actually, i'd love for my other pages to kinda match it, both in theme and in ascetics.
        also, the HTML better be layed out nicely (i.e. readable in a text editor), better comply with W3C standards, and not be designed for any s
        • HTML must use CSS dynamic placement and not tables

          Didn't work for me, so I went for a CSS/Table route (despite wanting to stay completely in CSS.) At some point you just have to get on with your site however you want, otherwise I'd be tweaking all day, trying to get it right.

          I like CSS a lot, though, anhd looking forward to it becoming a little more mature.

      • "It's amazing the number of funky comment-within-comment hacks that you have to perform to get sites to display properly across two or three "standards compliant" browsers."

        It should be pointed out that the reason you have to use hacks is precisely because the browsers are not standards-compliant.
    • by cyber0ne ( 640846 ) on Tuesday July 20, 2004 @02:15PM (#9751043) Homepage
      But even "standard" code can render differently in different browsers on different platforms. Depending on the complexity of the website/application, small differences can be a big problem.

      At my last job I kept a log of browsers/platforms that hit the webserver. From the vast majority (at the time, IE5 on Win9x) down through the percentages, I would run what I could for testing. For example, using whatever tool of choice (VMWare on my home network was what I used), I tested my sites in IE5 on Win9x, IE5 on Win2K, Netscape, Mozilla, etc, etc. I think I was regularly testing on maybe the top 6 percentages in the log, capturing about 99.5% of the hits.

      There will always be a percentage of browsers in the world you can't test, be they either little-used browsers on little-used platforms or widely-used browsers with some strange configuration that messes things up. But if you can identify the majority of the variations that are hitting your site(s), then just test as many of those as you can before you feel confident that it's "as compliant as it's going to get."
      • by Basje ( 26968 ) <bas@bloemsaat.org> on Tuesday July 20, 2004 @02:47PM (#9751454) Homepage
        That's a self fulfilling statistic: people with an unsupported browser (in which the page won't render correctly or at all) won't return. Thus, the supported browsers will always be top in the logs, unsupported browsers will stay at accidental hits.
      • But even "standard" code can render differently in different browsers on different platforms.

        That is by design, and it is a feature of standard-compliant design. You can code a web page once, and it will render for normal people, blind people, people with 640x480 displays, and everybody else.
    • The W3C Validator [w3.org] is your friend. There's also one for validating CSS [w3.org].

      It's not perfect, however, so take it with a (small) pinch of salt.

    • by AllUsernamesAreGone ( 688381 ) on Tuesday July 20, 2004 @05:03PM (#9753222)
      Nope, doesn't work. It'd be wonderful if it did, but .. well, just look at XHTML 1.1/CSS2 and tell me how many browsers you think will handle pages written in them correctly. The site I'm building can only be valid XHTML1.1/CSS2 when delivered to Mozilla or Firefox (although I've got to test it with Knoq/Safari yet). Opera doesn't (or didn't inthe last version I grabbed) support id attributes in object elements and IE... <shudder> Even if you code to older standards support is patchy at best, especially in IE which in places expects practically prehistoric versions of some standards.

      And even when browser do all support the standards you're using, they are somewhat liberal in their interpretation of them, especially when it omes to margins, padding, border sizes and whitespace in general.

      In short: coding to the standards is a bit like navigating a minefield in the dark with a map of the mine locations drawn by a guy with amnesia. If that is all you rely on, you are going to end up doing the biggest splits you'll ever do in your life.
    • code to the standard, thats usually your best bet

      I once wrote a web page that was HTML4.01/CSS2 compliant. It displayed fine in Mozilla, Opera, and Konquerer, and even broke in a usable way in Netscape 4. In IE5, a number of elements showed up in the wrong places (the footer, for example, was plastered across the middle of the page).

      (And as a side note, it seems that the Slashdot editors don't want any more people pointing out how bad the HTML on the main page is. Attempting to run it through the W3C
  • by sribe ( 304414 ) on Tuesday July 20, 2004 @02:06PM (#9750900)
    Do I need a Mac and a Linux machine to make sure it is working on these platforms?

    Yes. Glad I could help out ;-)
  • Depends. (Score:4, Interesting)

    by Hank Reardon ( 534417 ) on Tuesday July 20, 2004 @02:07PM (#9750914) Homepage Journal

    This really depends on the type of page I'm working on. If it's a personal page, I make sure it works with Mozilla and IEWin, because those are the two browsers I have available.

    If I'm working on a business project, I let the boss spec the work. If it's required to work under Safari and IEMac, then they have to provide a Mac for me to develop with, not just have somebody else test it.

    • What you do for your personal stuff, I do for work. I mostly use Mozilla, the rest of the team use IE. The result is very compatible. Some Mac users have reported problems with older version of IE, but they have all been quite receptive to installing Mozilla and that works very nicely.

      Our biggest problem appears to be that some older versions of Squid, installed in places we can't influence, began tripping over our pages when I installed mod_gzip.

      • What you do for your personal stuff, I do for work. I mostly use Mozilla, the rest of the team use IE. The result is very compatible. Some Mac users have reported problems with older version of IE, but they have all been quite receptive to installing Mozilla and that works very nicely.

        I'm not as worried about IE under Macintosh since Safari came out. Coding for Safari can be a bit of a pain, at times. Luckily, Konqueror running on my Fedora boxen seems to hit Safari oddities with about 75% accuracy. Acco

        • I had a similar issue a the last place I worked. We were able to work around it by having one of the Apache C gurus tweak mod_gzip to not compress stuff going to anything with one of the X-Proxy headers set, but even that wasn't 100% effective.
          I increased the minimum size required before a page would be compressed. I think I took it up to 3k. That solved the problem, or people just gave up, I'm never sure which it is.
  • Virtual Machines (Score:3, Informative)

    by sampowers ( 54424 ) on Tuesday July 20, 2004 @02:08PM (#9750935)
    Get yourself a copy of VMWare or Virtual PC, or something cheaper. Boot a Knoppix CD image, and test away. Konq and Mozilla are right there. Also test opera, but you can do that on whatever platform you want.

    I also reccomend testing with stylesheets turned off, if you're using them, to make sure your site degrades gracefully in browsers with no stylesheet support.
  • Virtualisation thing (Score:4, Informative)

    by rikkus-x ( 526844 ) <rik@rikkus.info> on Tuesday July 20, 2004 @02:09PM (#9750951) Homepage
    Ever heard of VMWare or Virtual PC? As for MacOS, well, they have Safari, which is basically KHTML of Konqueror, and Mozilla.

    Oh yes, and as another poster said, stick to the standard.

    Rik
  • Validator (Score:5, Informative)

    by wishus ( 174405 ) on Tuesday July 20, 2004 @02:09PM (#9750955) Journal
    • Re:Validator (Score:5, Insightful)

      by JimDabell ( 42870 ) on Tuesday July 20, 2004 @02:40PM (#9751378) Homepage
      I'm sorry, but that's simply not good enough. Writing valid code is only a very small part of making a robust website. You can write perfectly valid code that fails to display properly in any major browser. For example, not testing in Internet Explorer 6 will leave you prone to a couple of very nasty bugs that cause large sections of the page to simply not get shown.
      • >Internet Explorer 6

        Real robust enterprise web site design uses table-driven database-back-end solid server-side code with (x)html templating and so no, it does not matter, since it's easy to mod the templates to match the Browser du jour. It's part of the abstraction of presentation exercise.

        • Re:Validator (Score:2, Insightful)

          by DougWebb ( 178910 )
          Nice, but irrelevant. How do you test the browser-specific templates?
          • you make sure you get a toolkit that is tested by others, and you don't futz with it.

            And it's very relevant. For example, with plone, you can specify if you want html4 transitional (table layout) or xhtml1.0 (div layout).
            • you make sure you get a toolkit that is tested by others, and you don't futz with it.

              So in other words, your solution to "how do you test your web pages?" is "use somebody else's template and hope they didn't make any mistakes"?

              • No, you use a tested and reliable templating system, and you should be fine. Home-grown solutions rarely scale well without significant rework. I like to avoid work as much as possible. Hear that Larry? I'm lazy.
                • No, you use a tested and reliable templating system, and you should be fine. Home-grown solutions

                  The templating system has nothing to do with it. Like Doug said, how do you test the actual pages themselves? How the template system works is irrelevent in terms of browser compatibility, as that all happens server-side. What is actually sent to the browsers, the combination of the template and the content, is what is important.

                  So like I said, your argument boils down to using somebody else's page d

                  • >using somebody else's page design and hoping they didn't make any mistakes.

                    Granted.

                    But that's bad how?
                    • It's absolutely useless for the 99% of web designers who create their own designs.

                      It requires trusting somebody instead of objectively measuring success.

                      Have you ever actually seen the quality of the code that you get from the kind of companies that sell templates? Most of them aren't valid and a good portion obviously haven't been tested in anything but Internet Explorer.
                    • I don't buy templates.

                      I use templating objects within programming environments.

                      The thread implied large websites. If you have a 10,000 pages data-driven dynamic website, you're going to template one way or another.
                    • Sigh. You are either completely and utterly missing the point, or you are deliberately trolling. I'll go slow.

                      1. At some point, the browser recieves some HTML, CSS, etc. The whole point of testing in browsers is to ensure that things work properly.

                      2. Your initial buzzword-laden suggestion of using a templating system is irrelevent. A templating system uses templates to decide exactly which HTML, CSS, etc to send. The relevent code is the actual templates themselves.

                      You are still caught up i

                    • Re:Validator (Score:4, Insightful)

                      by JimDabell ( 42870 ) on Tuesday July 20, 2004 @07:54PM (#9754945) Homepage

                      >The whole point of testing in browsers is to ensure that things work properly.

                      The whole point of standards is that you don't have to. They will, all by themselves, if the browsers are standards-compliant.

                      The point of standards is to aid interoperability. They aren't a get-out clause to expect everybody else to write bug-free code. That is an unreasonable expectation, especially as validators themselves are only a tool to catch errors you've made yourself. So you make errors but nobody else is allowed to, is that it?

                      If I validate xhtml 1.1, that's the end of my testing phase.

                      You are aware that XHTML 1.1, per standards, will not work in Internet Explorer?

                      >How do you ensure that the HTML, CSS, etc you have chosen works with popular browsers?

                      By using standard-compliant xhtml and css. In and of itself, this guarantees that this will work in particular browsers.

                      Which particular browsers? There is no browser that gets XHTML or CSS completely right. It's quite obvious to anybody who has spent more than five minutes developing websites that standard-compliant XHTML and CSS does not guarantee your website will work in any particular browser. Browsers have bugs. You can deal with that by testing, or you can stick your head in the sand.

                      Note that I semantize, and don't go for special effects. (None. Go to my site, you'll see. It navigates and looks the same in Konq, Safari, Moz, Op, Lynx and Links.)

                      Your website violates RFC 2616 (HTTP 1.1) and RFC 2854 (the text/html media type), as XHTML 1.1 is not permissable to send as text/html. Also, by including an XML PI, you are screwing up rendering on Pocket IE and one other user-agent that I can't quite recall. If you want to comply with the specifications and also be accessible to the majority of the web, you'll have to drop back to XHTML 1.0 and follow Appendix C.

                      Or you could take your own advice, use the application/xhtml+xml media type, and say goodbye to Internet Explorer users, Lynx users, Links users and most search engines. After all, you just have to write to standards, and your job is done, right?

                    • Or you could take your own advice, use the application/xhtml+xml media type, and say goodbye to Internet Explorer users, Lynx users, Links users and most search engines. After all, you just have to write to standards, and your job is done, right?

                      A-fucking-men. I dunno why the just-code-to-standards guy writes software, but I make stuff because I want people to use it. I work hard to hew to the standards, of course. But that's not where my development ends, it's where it starts.
                    • There are standards in place for everyone to use. If I write code that is 100% compliant with standard "A", and a certian web browser can't render that page, there is a problem with the browser, not my code.

                      I've never said otherwise. In fact, that's exactly why I said "Browsers have bugs. You can deal with that by testing..."

                      I don't care what browser anyone uses to look at my web pages. My code adheres to published standards, and it is not my problem if a web browser is out of date, or non-compli

                    • The point of standards is to aid interoperability. They aren't a get-out clause to expect everybody else to write bug-free code. That is an unreasonable expectation, especially as validators themselves are only a tool to catch errors you've made yourself. So you make errors but nobody else is allowed to, is that it?

                      >You are aware that XHTML 1.1, per standards, will not work in Internet Explorer?

                      Again, whose fault?

                      >Which particular browsers? There is no browser that gets XHTML or CSS completely righ
                    • >You are aware that XHTML 1.1, per standards, will not work in Internet Explorer?

                      Again, whose fault?

                      It's Microsoft's fault that XHTML 1.1 will not work in Internet Explorer. It's your fault if somebody hires you to build a website and it doesn't work in a web browser that is used by the vast majority of surfers.

                      Why are Microsoft expected to implement XHTML 1.1 anyway? It brings virtually no advantages to their users.

                      I am not writing browsers. People that write browsers have to render p

      • You get the perversity prize for generating radically different behavior in different browsers and/or browser versions while only using valid HTML and CSS.
        Its really not that hard either.
  • I've decided to buck the trend and not support MSIE for many of my sites. Heh heh heh, people that are too lazy to upgrade are also too lazy to complain. Creating hobby websites is for my own enjoyment, and I just don't care to spend the sweat so the raggedy-assed-masses can continue to be ignorant savages.

    So I test on linux, since it has moz, konq, opera, and netscape 4.
    • I use this javascript when designing *web*applications*:
      var capable = document.getElementById;
      if(capable){
      ...
      }
      Does a good job of reducing the work load.

      ;-)

      I'm not even interested on bidding on a project that wants to support browsers that are so old (or lame) that they can't do a "getElementById".

      • you're actually a little better off using
        var capable = (document.getElementById && document.getElementsByTagName && document.createElement);
        . It helps to get around some browers that support the getelementbyid function, but not properly (older Opera).
  • Generally I'll do the dev work in $Mozilla-variant-of-the-week, but trying to keep with W3C standards and checking heavily against the validator [w3.org]. Provided the page is valid against various standards (HTML 4.01 Transitional as a minimum), and it renders ok in both Moz and IE, I'm happy. OTOH, I'm no longer a professional web developer (I have better things to do these days), and for a big client I'd want to check against various other platforms.
  • I have a windows machine as the primary, It runs IE 6.01sp1 currently...we also have a test lab with machines with IE machine 5.0 on them. My machine also runs netscape 7 (I have dropped 4/6 support its no longer current enough to care in my book), Mozilla and Firefox. I have a Linux machine with the same + Konquer. I don't test Mac its not relative for the environment.

    This is a standards nightmare of course since none of these all impliment the DOM, or CCS in exactly the same way. Don't even get me st
  • BrowserCam (Score:5, Insightful)

    by bjpirt ( 251795 ) on Tuesday July 20, 2004 @02:16PM (#9751050)
    If you don't want to buy a mac, you could always use browsercam [browsercam.com]

    Of course you messed up in the first place not getting a mac. You can test in PC/IE from the mac, but not the other way around.
  • Significant Other? (Score:4, Interesting)

    by jtheory ( 626492 ) on Tuesday July 20, 2004 @02:18PM (#9751081) Homepage Journal
    If you have a significant other (I'm married, so I do), sell them on getting a Mac. I bought an iBook for my wife, so I can test on my laptop (w2k), her Mac, and Linux by booting from my handy Knoppix CD.

    That covers the base pretty well.

    Of coures, it's always wise to generally try to avoid dicey display tricks that you know will probably give you problems... or if you absolutely *must* have that stock ticker, don't code it yourself -- find one whose creator is doing the testing for you.
  • Mac (Score:5, Interesting)

    by octover ( 22078 ) on Tuesday July 20, 2004 @02:19PM (#9751102) Homepage
    I have a PowerBook that I do my web development on. I then use Virtual PC to test the windows IE stuff. I have found that the Mozilla rendering engine on windows/mac/linux is pretty much the same, i.e. testing on one is good enough for all (granted I try and stick with writing things once and having it work everywhere so its the safer (X)HTML/CSS).
  • Do a Google search [google.com], and you'll find companies [browsercam.com], tools and instructions [thesitewizard.com], etc to help you do this if you are unable or unwilling to purchase the required equipment/software to do it yourself.

    Of course, half the problem is knowing the correct question to ask. That's why google is so popular - it gets good results with bad questions, and you can refine your question with repeated searches.

    -Adam
  • by Bistronaut ( 267467 ) on Tuesday July 20, 2004 @02:23PM (#9751155) Homepage Journal

    Browsercam [browsercam.com] is a good resource. Of course, you can't test functionality with it, but your layout is where you will run into the most browser bugs.

    Ultimately, the best route I've found is to stick like glue to the standards and don't use nested tables or rely on Javascript.

    As long as you stick valid HTML 4.01 or XHTML and CSS, the rendering bugs for IE5+/Win and IE5+/Mac are pretty well known. Older browsers can easily be sent plain text or minimal styling with media or @import hacks. Spend a lot of time lurking on the CSS-d mailing list.

    Where do you find out about the "well-known" rendering bugs? There are a ton of sites out there about them, but I like PositionIsEverything [positioniseverything.net] and the CSS-Discuss Wiki [incutio.com].

  • I do all my development on a Mac. As a result, I have Safari/KHTML, Mozilla/FireFox/Camino at my disposal. For IE/Windows, I usually will look on a PC or use VirtualPC if a real PC is not available. VirtualPC is an option if you want to test on Linux as well, although I generally assume that if it works in FireFox on one platform it will work on the others.
  • in IE. I also used http://www.danvine.com/icapture/ for safari testing but it seems to be down right now. In most cases if things work fine under a gecko based browser and Konqueror the rest will have no problem. Of course all the XHTML/CSS I create validates.
  • Yes (Score:3, Insightful)

    by ccarr.com ( 262540 ) <chris_carrNO@SPAMslashdot.ccarr.com> on Tuesday July 20, 2004 @02:35PM (#9751312) Homepage
    Buy a cheap used iMac and make your Windows box dual-boot to Linux. If your situation allows, write the iMac off as a business expense.
  • by fozzmeister ( 160968 ) on Tuesday July 20, 2004 @02:38PM (#9751346) Homepage
    and your paying the price, you should have tried writing IE and testing Moz, Opera etc. then Then writing Moz, then Opera.

    I personally find that if I write for Mozilla Firefox its usually only slight modifications needed for IE etc, and most of that is Javascript related.

    IE's rendering engine is deliberately not picky, therefore it stands to reason its a bad choice to program for. Safari (KHTML) and Moz (Gecko) are OSS and as such tend to stick to the standards pretty well.

    Opera used to (don't know if its still the case) stick absolutely to the standards so it may make a very good choice. I however don't test for it because of its small market share and it's still closed source.

    Use Moz and go with the Web Developer Tools (http://texturizer.net/firefox/extensions/#webdeve loper) and click on the little tick thing on the right side of the bar and make sure you have "Standards compliance mode" as the Render Mode, then a quick check on IE (Windows) and your pretty much gonna be OK.
  • by OmniVector ( 569062 ) <see my homepage> on Tuesday July 20, 2004 @02:42PM (#9751402) Homepage
    My web development environment consists of Firefox with Web Developer plugin, and DOM Inspector plugin, plus Mozilla with it's superb javascript debugger. on a side note, does firefox have a javascript debugger plugin?

    either way, i can't recommend that enough. the web developer plugin has all sorts of goodies like w3c validator, turning css stuff on/off (and even inserting css stuff on the fly). combine that with the javascript console and javascript debugger for debugging those DOM scripts. i'll also often use the DOM inspector to get a vew of my webpage's DOM tree or find suspect nodes which aren't coming up properly in my javascript.

    and i can't stress this enough: strive for 100% w3c compliance always. nothing is worse than a website that doesn't comply to the standards, because if it does not, it introduces nothing but headaches with the major rendering engines: khtml, gecko, opera, and mshtml. yes. some of the w3c specs want you to do fairly dumb things. who cares, just do it. i hate seeing sites that don't comply and then users ask "why doesn't it render properly in <insert my browser>
  • I use a Linux box with Apache 1.3.x, MySQL, and PHP4, because more often than not, that's what the production server will be using.

    I have VMWare installed so that I can check things in IE -- I have IE 4, IE 5.01, IE 5.5, and IE 6.01 all on the same virtual machine. of course, Mozilla and Konqueror practically always agree on how to render a page. I use iCapture [danvine.com] to look at it in 'for real' Safari.

    there's nothing quite like having a real *nix+apache setup. VMWare is well worth the price of entry if you make y

  • wishus just wrote validator.w3.org, and I have to second that. One of my coworkers in the lab told me that my website is one of the very few that show up properly in the PS2's webbrowser... and lynx... and a host of other web browsers. If it validates, it's usually good.
  • Comment removed based on user account deletion
  • You need a Mac (Score:4, Informative)

    by JimDabell ( 42870 ) on Tuesday July 20, 2004 @02:55PM (#9751566) Homepage

    I don't think there are any decent Mac emulators around. There are, however, decent PC emulators on the Mac.

    If that's not an option, then you can't really do anything about Mac/IE, as the Mac and Windows Internet Explorers use completely different rendering engines.

    Safari is based around the KHTML engine, and so you can be fairly safe with that browser as long as you test in Konqueror.

    Things like Browsercam [browsercam.com] aren't very helpful, as you can't interact with them, and a lot of bugs only show up when interaction takes place. But if you have no other option, like Mac/IE without owning a Mac, then it's better than nothing.

    Even if you aren't bothered about other platforms, virtual machines like VMWare are useful. You can set up a range of them with different screen resolutions, font size settings, Javascript on and off, and so on, so you don't have to keep fiddling with your settings.

    If you take the "fiddle with your settings" approach to testing, set up a second account on your workstation for just this purpose. That way, any plugins, settings, etc, that you use for normal day-to-day surfing won't interfere with your testing. Make sure you keep a checklist where you can tick off each combination of settings that you have tested against - you will miss combinations otherwise. You will probably find it useful to install multiple versions of Internet Explorer on the same machine [skyzyx.com].

    Obviously, run your code through HTML and CSS validators, and possibly linters as well. It's a good idea to incorporate validation into your publishing routine - nothing invalid ever reaches the server. If you can't do that, it's a good idea to set up a validator to automatically spider your websites on a regular basis and report any errors to you via email. Alternatively, check out Ben Hammersely's validation RSS feed. [benhammersley.com]

  • This doesn't help on the Mac end of things, but why worry about having a "linux machine" or dual booting when you can just boot to a live CD distro like Knoppix [knoppix.org] and test with Konqueror. As long as your PC hardware isn't too funky, this should be relatively painless.
  • by markjugg ( 21992 ) * <<mark> <at> <summersault.com>> on Tuesday July 20, 2004 @03:01PM (#9751642) Homepage
    Most of the web pages I develop are database driven. I use the WWW::Mechanize [cpan.org] module as part of an automated testing solution.

    To manually test websites, I run Linux on my desktop. This allows me to test Windows/IE via WINE, as well as Mozilla and Konqueror (which should render like Safari).

    It doesn't catch every issue, but it works well for me.

  • under a pseudonym, of course. If it survives a /.ing it must be fine. :)
  • by tweder ( 22759 ) <stwede@gmai l . c om> on Tuesday July 20, 2004 @03:13PM (#9751794) Homepage
    I'm a professional web developer and I can safely say I couldn't be nearly as productive without my Mac.

    I do my main development in BBEdit, checking against Safari's rendering engine. As things are shaping up, I'll check it in Mozilla (and variants), Mac/MSIE (we HATESSSS it!), as well as VirtualPC running Windows 2000 to keep ensure things are looking good in Win/MSIE, and lastly Lynx to ensure that content is properly available, despite lack of formatting.

    This way I feel I've got all my bases covered.

    KHTML (Safari, Konqueror)

    Gecko (Mozilla, Firefox, Camino, etc...)

    MSIE::Mac

    MSIE::Win

    Text-based (lynx, WAP, screen readers, etc...)

    My Macintosh lets me get everything done with ONE computer on my desk. No need to deal with the upkeep of several boxes, as well as the real estate they'd all require at my workspace.

  • by Dr.Dubious DDQ ( 11968 ) on Tuesday July 20, 2004 @03:15PM (#9751822) Homepage

    That is, make sure your design isn't dependent on pixel-level control of everyone's browser as far too many web developers (and damned "content-generator" programs) seem to insist on.

    Or in other words, always remind yourself that The Web is Not a Print Medium [alistapart.com] (Highly recommended, if slightly "fluffy", article). Most of the "hey, it doesn't work/look right in this OTHER browser" problems I've ever seen boil down to the web designer having a pressing attitude that they need to control the users' browsers down to the minutest pixel, and have a pile of browser-specific tricks that depend on recognizing the specific "brand name" of the browser and behaving in a different quirky manner depending on which (of the listed ones) it recognizes.

    Many others have already posted the good advice to just "stick to the standards". In case it isn't obvious, that most especially means "don't reference any 'browser quirks' anywhere in your design." Even IE seems to have reasonable support for "standards compatibility mode", so if you stick to standards, you will greatly cut down the potential problems that necessitate testing your pages in 10+ different browsers on 4+ different platforms in the first place.

    (The rare individual that really DOES require iron-fisted dictatorial control of the pixel-by-pixel layout of their page shouldn't be using HTML anyway - that's what PDF is for...)

  • I have at my general disposal a WinXP box in the management office where I live that has an Opera and an IE install, a Win98 system that I use at the workplace that runs IE, Opera and Firefox, a friend's Mac running OS 9 (has IE, natch, and Netscape Nav), and my own Linux box, which has a plethora of browsers.

    Having said that, I code *really* simply; most of my code, in fact, is just simple junk that I have a few shell or perl scripts spit out, since most of my code constitutes image or photo galleries

  • Lots of good options mentioned so far. Here are a couple more you can try.

    Test pages at the local university or library computer lab (depends on what they have available whether or not this will be of use to you). Some schools have separate Mac and PC labs.

    Also, in many webmaster forums it's standard practice to ask other users with the browser/platform combination you're missing to test it for you and send you a screenshot.
  • Post the links on Slashdot and a swarm of monkeys will proceed to bang on your server...
  • Forget web standards (Score:3, Interesting)

    by phildog ( 650210 ) on Tuesday July 20, 2004 @04:24PM (#9752729) Homepage
    You will probably never see this as the standards folks will mod me into oblivion, but here goes: if you use the time-tested combination of good old ugly tables and single pixel gifs, your site will look good in almost every browser imaginable. A quick test in Firefox and the latest IE should be all you need to do.

    One exception is to use CSS for the font formatting stuff.

    Standards are a great concept, but with web design you need to deal with harsh reality: browsers suck. Look at the source code at the front page of google.com or yahoo.com if you want to see what the big boys are doing.

    Wait until Firefox has 95% of the market, then move to standards :-)
  • by MichaelCrawford ( 610140 ) on Tuesday July 20, 2004 @05:01PM (#9753207) Homepage Journal
    Enjoy my article:

    It is released under the GNU Free Documentation License.

  • YES. They all render differently, and it makes things difficult.

    Gecko based browser don't seem to render span width or span height tags where IE does. At least not in the stylesheets. IE and Netscape handle pixels differently, where 100px does not layout the same in both browsers. So in the case you want to use absolute positioning to layout some images and then float text over them it could cause problems. CSS 1 support in all browsers is iffy. CSS2 hardly exists.

    Also watch out for handling of thin

  • by Dracos ( 107777 ) on Tuesday July 20, 2004 @06:36PM (#9754235)

    IE hasn't had any worthwhile rendering engine improvements since version 5, giving it the absolute worst standards compliance of any browser shipped today.

    Never forget that IE wan't designed as a developer tool, is was designed to kill Netscape. True to MS form, trying to decipher any of IE's pitiful error messages will only cause migraines.

    The W3C stopped development of their own reference browser (Amaya) because Mozilla's standards support is so good.

    And stop using dreamweaver. It is incapable of generating compliant code, its javascript library is optimized for 3.x browsers, and no one ever learned HTML by using dreamweaver. It's appaling to me how many people claim to know (X)HTML but don't. Macromedia doesn't really give a damn about standards anyway. DW is also why no one seems to understand CSS... they never see it used effectively. All this and DW uses IE to render pages; see above for why this is bad.

    Every so called "web designer" needs have their DW uninstalled and be forced to code pages by hand for a week to see how good they really are.

    • I beg to differ. Dreamweaver is the best web development environment I've tried for OS X, and second only to Homesite on Windows (IMO, YMMV). You can learn XHTML/CSS just as easily using Dreamweaver as you can in Notepad. Better actually, because DW does syntax highlighting and validation.

      Oh, you didn't know DW can be used in a 100% hand-edited text, non-WYSIWYG fashion? You've never actually used it, have you?

  • I use the HTML 4 strict Doctype and check it using the w3 validator, and proof it on Netscape Navigator 4.78 and IE 5.0. You might have to make a couple of tweaks for Netscape. That pretty much works 100%.

    DO NOT use transitional doctypes. That turns on something called 'tweaks mode' in a lot of browsers - in an attempt to be backward compatable. That usually translates into broken pages.

  • With something like VirtualPC or VMware, you can run one OS and simulate the rest.

    To test Safari and IE5/mac, you'll need a copy of PearPC ( http://pearpc.sourceforge.net/ ) or some other Mac emulator for PC. Generally they're not fast, but PearPC emulates at a 40th speed, which is more than enough for a web browser.
  • I write XHTML 1.1/CSS 2.1 code and test it on Microsoft Internet Explorer 6, Mozilla 1.0, Firefox 0.9, Opera 7.5.1, Dillo, Links and Konqueror. Then I get complaints that nothing works on MSIE5 for Mac. If anyone knows how to make IE5/Mac recognize "background:#ff0000" applied to div's, tell me, because I feel like shooting myself about now. Either that, or going out and buying an iMac for the SOLE purpose of testing IE5/Mac (why? an iMac is cheaper than OSX for use with PearPC...).
  • I mainly use Mozilla under Windows for browsing, so it's obviously what I check under first. Plus i've found (between mine and other sites) that Mozilla is less-forgiving over HTML errors, so I tend to catch more of my dumbest mistakes straight away.
    My next test tends to be IE - mainly 'cos it's in Windows and i can test it immediately. I've found this is where I pick up on where IE and Moz tend to render certain aspects of CSS differently. I'll then straighten it out, trying to make sure it either renders

He has not acquired a fortune; the fortune has acquired him. -- Bion

Working...