How Do You Test Your Web Pages?

code to the standard by Numeric · 2004-07-20 06:06 · Score: 2, Insightful

thats usually your best bet

--
-- ladies and gentlemen we are floating in space!

Re:code to the standard by Hank+Reardon · 2004-07-20 06:10 · Score: 5, Informative

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. 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.

--
There's so little difference between politics and jihad lately...
Re:code to the standard by cyber0ne · 2004-07-20 06:15 · Score: 5, Insightful

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."

--
http://publicvoidlife.blogspot.com
Re:code to the standard by silverfuck · 2004-07-20 06:17 · Score: 3, Informative

The W3C Validator is your friend. There's also one for validating CSS.

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

--
You know you've been IMing too long when you almost say 'lol' out loud to a non-geeky friend...
Re:code to the standard by chris_mahan · 2004-07-20 06:27 · Score: 1, Insightful

>But even "standard" code can render differently in different browsers on different platforms

Exactly. Things will look different. Go with standard code, and let browsers render as they will.

I would say that if you want paper-like precision, go with paper. If you want to display data, go with a simple format, and keep to the standards.

if your clients don't like it, and you want to accomodate them, then it's a business expense. Buy 8 computers and install all the different browsers on them. It will be expensive, yes, but you should pass that to your customers as a cost of development.

--
"Piter, too, is dead."
Re:code to the standard by Anonymous Coward · 2004-07-20 06:39 · Score: 0

You are aware that there are many "standards" that are supported by zero web browsers, including Mozilla, right?

Go code a XForms, SVG, and CSS3 site and then try explaining to your boss how the W3C "recommended" all of this stuff.
Re:code to the standard by Basje · 2004-07-20 06:47 · Score: 4, Insightful

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.

--
the pun is mightier than the sword
Re:code to the standard by Phillup · 2004-07-20 06:56 · Score: 3, Informative

I do it with three computers.

One dual Xeon system with a shitload of memory running Linux and VMWare... and several versions of Windows/IE via VMWare.

And, two Macs. One running OS9 and the other running OSX.

That gives me the greatest OS coverage with the minimum number of machines.

And... I load each OS with as many clients as I can test.

--

--Phillip

Can you say BIRTH TAX
Re:code to the standard by wishus · 2004-07-20 07:10 · Score: 2, Insightful

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.
Re:code to the standard by britrock · 2004-07-20 07:41 · Score: 5, Informative

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 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.
Re:code to the standard by WebCrapper · 2004-07-20 07:59 · Score: 1

I basically do the same thing.

I have a Win2k box with VMWare running several other OS's - each with thier own browser lists, a FreeBSD box running all browsers I can test in (including Lynx) as well as two laptops running XP and Win98 with their own list of browsers.

On top of that, I use Dreamweavers compatibility script and use the W3C Validator.

Its really a pain when you think you've got something perfectly done and you find a small bug in 1 browser...
Re:code to the standard by FuzzyBad-Mofo · 2004-07-20 08:03 · Score: 4, Informative

Or use BrowserCam. For a small fee, they will provide screenshots of your site from all the major browsers on demand.
Re:code to the standard by chris_mahan · 2004-07-20 08:11 · Score: 1, Insightful

You have no control over which browser people use. Once the packets have left your server, they're gone. Gone.

What you have to do is spread packets that follow the standards, so that users can decide for thmselves which browser they want to use.

For example, would it be amazing if every gas station in the country had different octane levels, and some had lead, others had pcbs, and yet others put ethanol, alcohol, or whatever in them.
No, standards insure that if you buy a BMW, you can get fuel anywhere in the country (and the industrialized world) and won't damage your car.

--
"Piter, too, is dead."
Re:code to the standard by FuzzyBad-Mofo · 2004-07-20 08:19 · Score: 1

I agree, that's why practically all my web development is XHTML+CSS compliant. However, if a particular browser has a rendering bug, I'd like to know about it.
Re:code to the standard by AllUsernamesAreGone · 2004-07-20 09:03 · Score: 3, Insightful

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.
Re:code to the standard by orangesquid · 2004-07-20 09:14 · Score: 1, Informative

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

Someone recently commented in my livejournal 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 specific browser, resolution, platform, graphics capabilities, or fonts.
of course, if you use proper CSS, you can still encourage the browser to display things in certain styles of fonts (with keywords like serif, sans-serif, monospaced, emphasized, slanted) etc., and you can put low-importance tags to give a prioritized list of specific typefaces to use.
also, HTML must use CSS dynamic placement and not tables or frames for layout (and if iframes are used, they must be used in such a way that browsers that don't support iframes can still access all the content)
and CSS has to be organized with identifiers, classes, and such used as appropriately
oooohh and the pages better be split up using HTML structure codes (H1,H2,H3,P,HR, etc.) which have appropriate anchors and references.
also, all images must have ALT tags and must look respectable in a web-safe palette... no GIFs (PNGs and/or MNGs only)
no browser-specific features, javascript, DHTML, ActiveX, Shockwave, or Java
and all pages must properly use META tags. no EMBED tags, and all MIME types must be correct.

for an example of a page that follows all these guidelines, see the page i'm designing for my sister's harping career at BlueHarpDiva.com

still interested? ;)

yes, i know, i'm an ultra-anal bitch.

--
--TheOrangeSquid Is it any wonder things seem so awry? We swim in a sea of confusion and don't have to think to survive
Re:code to the standard by aWalrus · 2004-07-20 09:18 · Score: 1

"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.

--
Overcaffeinated. Angry geeks.
Re:code to the standard by mini+me · 2004-07-20 09:30 · Score: 1

But even "standard" code can render differently in different browsers on different platforms.

So? I, as a user, couldn't care less. As long as the content is visible and the navigation works, I'll be happy.
Re:code to the standard by Carnildo · 2004-07-20 09:43 · Score: 1

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 validator produces a "403 forbidden" error).

--
"They redundantly repeated themselves over and over again incessantly without end ad infinitum" -- ibid.
Re:code to the standard by Hank+Reardon · 2004-07-20 09:43 · Score: 1

And that's precisely why I put standards-compliant in "quotes". :)

--
There's so little difference between politics and jihad lately...
Re:code to the standard by Hank+Reardon · 2004-07-20 09:48 · Score: 1

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's so little difference between politics and jihad lately...
Re:code to the standard by Captain+Splendid · 2004-07-20 10:25 · Score: 2, Insightful

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.

--
Linux, you magnificent bastard, I read the fucking manual!
Re:code to the standard by aWalrus · 2004-07-20 10:31 · Score: 1

Oops. My bad. =)

--
Overcaffeinated. Angry geeks.
Re:code to the standard by Rick+the+Red · 2004-07-20 10:35 · Score: 3, Insightful

Go with standard code, and let browsers render as they will.
So, are you saying we should ignore the 600 pound gorilla, or thumb our noses at it? Most people code to the standards, then tweak each page so the gorilla won't barf on them.
When over 80% of your clients use one browser, you either alienate 80% of your clients or you code to their browser, however sucky it may be. "Coding to standards" sounds good on paper, but we live in the real world. BTW, the gorilla thinks it is the standard, and with it's market share it really has become one, like it or not.

P.S., in the read world the Mac doesn't even exist -- I've tested web pages for some Fortune 500 companies and while mostly they said to test on MSIE and Netscape, none of them required me to test on Mac.

--
If all this should have a reason, we would be the last to know.
Re:code to the standard by Anonymous Coward · 2004-07-21 00:51 · Score: 0

Err, that page looks crappy in Mozilla based browsers, uses frames, the sites in his portfolio don't validate, ... Why would one trust his advice?
Re:code to the standard by Tofurkey · 2004-07-21 09:05 · Score: 1

BrowserCam will soon be offering Remote Access, so you can VNC to a machine and actually use your target browser on your target platform. Looks to be pretty cool, though I've never had really good experiences with VNC....

--
writeSig(!funny);
Re:code to the standard by orangesquid · 2004-07-21 09:29 · Score: 1

True.. there are some limitations in (and horrible implementations of) CSS currently. I'm hoping this gets conquered soon..

--
--TheOrangeSquid Is it any wonder things seem so awry? We swim in a sea of confusion and don't have to think to survive
Re:code to the standard by Tezkah · 2004-07-21 12:59 · Score: 1

Which is why google doesn't show much lynx action from me, some BAD HTTP REQUEST deal. :(
Re:code to the standard by Anonymous Coward · 2004-07-22 00:08 · Score: 0

You're right. The guy has a chip on his shoulder about standards. Don't trust his advice. But he is actually quite experienced, and he is trying to be accurate, so you are probably safe by trusting the information he provides.
Re:code to the standard by vrt3 · 2004-07-22 03:05 · Score: 1

I'm beginning to think CSS is bad by design. It's called cascaded style sheets, and I believe it indeed works quite good for defining styles.

But it's also advocated to be used for defining layout, which IMHO does a pretty bad job of. IMO with a good layout engine you should be able to define a number of blocks in the HTML-code and lay them out using the style sheet in any layout you'd like (horizontal, vertical, different order, one in front of the other, ...) without changing the HTML. I've never been able to do it satisfactorily, and I think it's not completely trough a fault of my own.

--
This sig under construction. Please check back later.
Re:code to the standard by Anonymous Coward · 2004-07-26 08:39 · Score: 0

the gorilla thinks it is the standard, and with it's market share it really has become one
There is an important difference between MSIE and a true standard, and that is, MSIE version 7 will probably be closer to W3C standards than MSIE 6 is. So anyone who just codes to MSIE 6's bugs (and there are a lot of dim bulbs who are doing exactly that) will get a lot of rework to do when MSIE 7 hits.

Of course... by sribe · 2004-07-20 06:06 · Score: 3, Funny

Do I need a Mac and a Linux machine to make sure it is working on these platforms?

Yes. Glad I could help out ;-)

Re:Of course... by elmegil · 2004-07-20 06:07 · Score: 1

At the very least you need to be able to run some variant of VirtualPC or wine or whatever.

--
7 November 2006: The day Americans realized corruption and incompetence weren't addressing 11 September 2001
Re:Of course... by vijaya_chandra · 2004-07-20 06:11 · Score: 2, Insightful

I don't think you can run OSX on x86 using any emulator/vm yet

but you can use vmware and an iso of knoppix to check out different browsers available for linux
Re:Of course... by Sepper · 2004-07-20 07:05 · Score: 2, Interesting

I don't think you can run OSX on x86 using any emulator/vm yet

PearPC

If you do a little search, someone (on OSNews.com I think) managed to install OS X...

It's not perfect (yet), but it's better than nothing!

On a side note: checking their webpage, one of the Dev died of an Accident on July 2.
23 Years old. I guess only the good die young :(

--
I live in Soviet Canuckistan you insensitive clod!
Re:Of course... by phlyingpenguin · 2004-07-20 07:07 · Score: 1

All except for PearPC...
Re:Of course... by elmegil · 2004-07-20 07:41 · Score: 1

So get a Mac and run x86 emulation on it then.

--
7 November 2006: The day Americans realized corruption and incompetence weren't addressing 11 September 2001
Re:Of course... by dubl-u · 2004-07-20 16:27 · Score: 1

Yes, you really do need the proper OSes.

For us, developer boxes are all Linux, so the app works great in Mozilla. The UI designer uses OS X and a manager uses Windows, so we get good casual testing coverage.

But for formal testing, we use VMWare to make sure the app works under older versions of IE. It turns out that IE5Mac has a special set of bugs all its own, so we will be getting an old iMac and serving it up to the developers via VNC.

VMWare is pretty swell, as you can juggle multiple virtual disks in separate files. That way we can bring up Win98, Win2k, or WinXP when we need to test with the IE versions they come with. Even better, it has a non-persistent mode, so that Windows can't get corrupted or set to other than the default settings.

Also, once we discover non-visual browser quirks, we add to our automated test suite, to make sure the app doesn't break in the future. For that, we use HttpUnit with a custom wrapper and a fair bit of XPath assertions.

Depends. by Hank+Reardon · 2004-07-20 06:07 · Score: 3, Interesting

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.

--
There's so little difference between politics and jihad lately...

Re:Depends. by Kris_J · 2004-07-20 10:58 · Score: 1

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.
Re:Depends. by Hank+Reardon · 2004-07-20 18:23 · Score: 1

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. According to what I've been reading, usage of Explorer on OSX has been declining, mostly because 5.2 was a huge step backwards from 5.1 or 5.0 in terms of stability and compatibility with IE under Windows.

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.

Ugh. Explaining to the boss how you have no control over somebody else's proxy can be a nightmare. 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've also noticed some of the malware and Trojans under Windows that do funky things to Winsock seem to have problems with things like compressed documents.

The worst part about being standards compliant is spending time trying to work out ways to fix your output for others who aren't...

--
There's so little difference between politics and jihad lately...
Re:Depends. by Kris_J · 2004-07-20 19:25 · Score: 1

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 by sampowers · 2004-07-20 06:08 · Score: 3, Informative

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.

Re:Virtual Machines by Pieroxy · 2004-07-21 12:47 · Score: 1

Is there a lot of browsers with no stylesheet support? I mean, browsers that are more than 0.01% of the browser population?

--
Write boring code, not shiny code!

Virtualisation thing by rikkus-x · 2004-07-20 06:09 · Score: 3, Informative

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

Re:Virtualisation thing by pfaut · 2004-07-20 06:13 · Score: 1

I'll second the vote for VMWare. A friend of mine designs websites for a living. He uses IIS on his server so all his development is done on Microsoft platforms. I help him out a bit on the side and ended up buying VMWare so I wouldn't have to dual boot. I can maintain access to all of my linux files (my primary environment) while running Windows in a window.
Re:Virtualisation thing by orthogonal · 2004-07-20 06:46 · Score: 4, Informative

Ever heard of VMWare or Virtual PC?

Or consider the Free alternative of coLinux, which allows you to run several linux distrubtions under MS-Windows.

--
Opinions on the Twiddler2 hand-held keyboard?
Re:Virtualisation thing by Doctor+O · 2004-07-21 06:40 · Score: 1

For MacOS, you can use PearPC. I haven't tried it yet, but even if it's slow (which I suppose according to the site), it should be well usable to test web sites.

--
Who is General Failure and why is he reading my hard disk?

Validator by wishus · 2004-07-20 06:09 · Score: 4, Informative

http://validator.w3.org/

Re:Validator by Plake · 2004-07-20 06:23 · Score: 1, Informative

Other useful validators:

W3C CSS Validator
XHTML Validator

And.. HTML Tidy to clean up code.

--
Check out Mon and Mon.cgi
Re:Validator by JimDabell · 2004-07-20 06:40 · Score: 4, Insightful

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.
Re:Validator by wishus · 2004-07-20 06:45 · Score: 1

The link I posted above will validate HTML, XHTML, and CSS, all in the same page. Besides auto-detecting DOCTYPE, it will also validate CSS if you put the URL of the CSS into the box.
Re:Validator by chris_mahan · 2004-07-20 06:57 · Score: 2, Funny

>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.

--
"Piter, too, is dead."
Re:Validator by DougWebb · 2004-07-20 07:10 · Score: 2, Insightful

Nice, but irrelevant. How do you test the browser-specific templates?
Re:Validator by chris_mahan · 2004-07-20 07:14 · Score: 1

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).

--
"Piter, too, is dead."
Re:Validator by dpilot · 2004-07-20 07:14 · Score: 1

Two unfortunate answers, here:

Yes, the html is valid and the browser fails, but the browser is IE6, so it IS correct.

No, the html is valid and the browser doesn't fail, but the browser is not IE6, so it doesn't matter whether it is correct, or not.

If anything is going to change the playing field with browsers, it's the web-aware cell phone.

--
The living have better things to do than to continue hating the dead.
Re:Validator by JimDabell · 2004-07-20 07:23 · Score: 2, Insightful

Yes and no. Firstly, it's quite possible to write valid, but stupid code. All a validator does is check for syntax errors, logical errors are outside of its problem space.

Secondly, and more importantly, of course there's something wrong with a browser if it can't display correct code sensibly. Newsflash: browsers aren't perfect, and when a client complains that Internet Explorer 6 users can't see any of the text on their website, they aren't going to care that the syntax is correct, they are going to care that you didn't ensure their website could be viewed in the web browser the majority of the world uses.
Re:Validator by JimDabell · 2004-07-20 07:26 · Score: 1

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"?
Re:Validator by chris_mahan · 2004-07-20 07:44 · Score: 1

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.

--
"Piter, too, is dead."
Re:Validator by Apreche · 2004-07-20 07:48 · Score: 1

Yeah, it's assholish of me. But this is exactly what I do. The only site I really make anymore is my blog. I test it against the w3c validator for XHTML and I keep twiddling with it until it passes. I also make sure to do valid CSS also. When I have both those things I twiddle it until it looks exactly how I want in Firefox. I know that my site looks wrong in IE, but I don't care.

Of course, this isn't an option if you are making websites for profit as well as fun. But for my personal website for my personal uses I personally give IE users a big 'ol middle finger.

--
The GeekNights podcast is going strong. Listen!
Re:Validator by JimDabell · 2004-07-20 08:10 · Score: 1

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 design and hoping they didn't make any mistakes.
Re:Validator by chris_mahan · 2004-07-20 08:19 · Score: 1

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

Granted.

But that's bad how?

--
"Piter, too, is dead."
Re:Validator by JimDabell · 2004-07-20 08:39 · Score: 1

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.
Re:Validator by chris_mahan · 2004-07-20 08:43 · Score: 1

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.

--
"Piter, too, is dead."
Re:Validator by JimDabell · 2004-07-20 08:54 · Score: 1

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 in talking about how your templating system is so great. That's irrelevent. What matters is what code the browser sees.

If you don't use other peoples templates, then at some point, you have decided what HTML, CSS, etc the browser sees.

So once again, we are back to the original point: how do you ensure that the HTML, CSS, etc you have chosen works with popular browsers?
Re:Validator by wishus · 2004-07-20 09:13 · Score: 1

If there is anything worth seeing on the website, then users will find a way to see it, even if that means downloading a new program. This is the paradigm that has worked for Real, Macromedia, and the thousands of companies that use their products.

Web developers complain about having to code around IE's bugs, yet by continuing to do so they perpetuate the problem.

Can you imagine if Mozilla introduced a new "feature" that was of benefit to the porn industry, and all of a sudden porn sites couldn't be viewed by IE? There would be a new "de facto standard browser" overnight.

Tell the client that if there is any worthwhile content on his site, his audience will find it. If the audience isn't willing to upgrade a broken, worthless browser to see his content, then the content itslef is worthless.
Re:Validator by JimDabell · 2004-07-20 09:34 · Score: 2, Insightful

If there is anything worth seeing on the website, then users will find a way to see it, even if that means downloading a new program.

No, they are far more likely to simply go to another website. And how are they to know what to fix? The average user doesn't have a clue that a rendering flaw is caused by a bug in their web browser and they could fix it by switching browsers.

This is the paradigm that has worked for Real, Macromedia, and the thousands of companies that use their products.

No, those are helper apps, not alternative browsers. That's a massive difference. Even so, when somebody offers Real and Macromedia files, it's usually content that you can't get elsewhere. The same is not normally true of HTML/CSS/Javascript/etc.

Web developers complain about having to code around IE's bugs, yet by continuing to do so they perpetuate the problem.

I don't disagree there. But it's the lesser of two evils. People develop websites to communicate with people, not to admire the cleanliness of the code. The content you produce is irrelevent if people don't see it.

Can you imagine if Mozilla introduced a new "feature" that was of benefit to the porn industry, and all of a sudden porn sites couldn't be viewed by IE? There would be a new "de facto standard browser" overnight.

Why would a porn website turn away the vast majority of their visitors? Sure, if all of them did it at once, it might be effective. But nobody will make the first move, as it would be commercial suicide - their competitors would just sit back and soak up all the Internet Explorer visitors they've turned away.

Tell the client that if there is any worthwhile content on his site, his audience will find it. If the audience isn't willing to upgrade a broken, worthless browser to see his content, then the content itslef is worthless.

That's a very arrogant attitude. What about people at work who can't upgrade? What about the people who aren't technically adept enough to even know about alternative browsers, let alone switch? What about people with vision problems who use expensive screen readers based around Internet Explorer? You really want to make it difficult for people to view your websites because of some browser snobbery? You might be willing to do that, but the people who commission the websites surely don't.
Re:Validator by chris_mahan · 2004-07-20 10:32 · Score: 0, Troll

>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.

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

To address your question specifically:
>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.

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.)

--
"Piter, too, is dead."
Re:Validator by JimDabell · 2004-07-20 11:54 · Score: 3, Insightful

>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?
Re:Validator by jon787 · 2004-07-20 13:00 · Score: 1

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.

--
X(7): A program for managing terminal windows. See also screen(1).
Re:Validator by SaDan · 2004-07-20 16:23 · Score: 1

>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?

He's right. 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 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-compliant.

You have a browser that is supposed to be HTML 4.0 compatible, but can't render my site? Go file a bug with the company/person who wrote the browser, or go and get a browser that CAN render HTML 4.0 properly.

Writing code to handle ten different browsers is a waste of time. Why can't the browsers just fucking WORK like they're supposed to, and render code properly?
Re:Validator by dubl-u · 2004-07-20 16:30 · Score: 1

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.
Re:Validator by ebbe11 · 2004-07-20 19:06 · Score: 1

There would be a new "de facto standard browser" overnight.
Making it possible to see all the pictures without paying would do the trick.

--

My opinion? See above.
Re:Validator by jswhiting · 2004-07-21 00:25 · Score: 1

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-compliant.

have you told your clients that this is your position? or maybe you don't have clients and aren't in any way responsible or accountable for the design work you do? i wouldn'hire a web designer who thinks that way.

if some people can't see the site or are seeing it render improperly, then not only has valuable interest in the site been wasted, but those people will then carry negative impressions which will, by word of mouth etc, spread.

if you aren't worried about a rotting userbase, then you can think that way, but most people care if someone wants to see their site but can't. making a site that everyone can see and use properly is overkill, but if you're not even catering to IE6 then either you are trying to target a niche market (okay), or you just don't have your priorities straight, or you just don't have any responsibilities at all.
Re:Validator by Iaughter · 2004-07-21 00:57 · Score: 1

Real robust enterprise web site design uses table-driven database-back-end solid server-side code with (x)html templating
I'm trying to explore some templating options for a smaller web site within a university's site. The setup is solaris, apache 1.3, and postgresql. Currently, the site is running php4 using smarty for templating.
My initial reaction to smarty is: wth? we're simply adding a layer of complexity (and another layer of computation) by putting a different programming language in the html page.
It seems to me that templating systems often end up arbitrarily complicated; hence the desire for a more standard templating structure.
I would like to ask what other professional web masters/developers/designers use to accomplish templating.
How exactly would (x)html templating work?
Re:Validator by JimDabell · 2004-07-21 03:06 · Score: 1

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-compliant.

"...or you can stick your head in the sand."

You have a browser that is supposed to be HTML 4.0 compatible, but can't render my site? Go file a bug with the company/person who wrote the browser, or go and get a browser that CAN render HTML 4.0 properly.

Exactly which browsers do you think render HTML 4.0 properly?
Re:Validator by chris_mahan · 2004-07-21 05:27 · Score: 1

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 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.

I am not writing browsers. People that write browsers have to render pages well. They are the consumers, wweb developers are producers of the data. If web developers don't produce valid data, browser people can't/don't want to make their browser compliant.

>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.

My plan, rather, is to wait for IE to catch up and then change the mime type on my site (and yes I am aware of that). Of course, I also looked at just changing page extensions to xml.

Again, Pocket IE not my problem. I don't implement browser technology.

>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?

Excellent point.

I think I'll go back to HTML3.2 and hang my head in shame.
Actually, I'll go download .NET and pray to Bill at each reboot.

--
"Piter, too, is dead."
Re:Validator by JimDabell · 2004-07-21 06:14 · Score: 1

>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 pages well. They are the consumers, wweb developers are producers of the data. If web developers don't produce valid data, browser people can't/don't want to make their browser compliant.

Stop right there. At no point did I advocate writing invalid code. But the point you seem to be arguing is that, as a web developer, once the code is valid, your job is done. That's complete rubbish, unless you don't mind your websites being inaccessible to everybody. Valid code is just a single step, it's not the finishing line.

My plan, rather, is to wait for IE to catch up and then change the mime type on my site (and yes I am aware of that).

So in other words, you plan to continue to violate RFCs 2616 and 2854? Isn't that a little odd for somebody who is arguing standards-compliance is the be-all and end-all to website robustness?

Again, Pocket IE not my problem. I don't implement browser technology.

It is your problem, because people use Pocket IE. Of course, I'm assuming that you want your website to actually work properly when somebody visits it. If you didn't create your website so people could use it, what did you create it for?

I think I'll go back to HTML3.2 and hang my head in shame.

I never suggested that. XHTML 1.0 works in the web browser used by the majority of surfers. XHTML 1.1 does not. There is a clearly massive compatibility advantage in dropping back to XHTML 1.0. There is no similar advantage to dropping back to HTML 3.2.

Actually, I'll go download .NET and pray to Bill at each reboot.

If you are trying to paint me as some type of Microsoft fanboy, you can forget it. I despise Internet Explorer and the way Microsoft has acted towards the web.

If you can't argue against my points, but simply ridicule ones I didn't make, perhaps you should just give up.
Re:Validator by JimDabell · 2004-07-21 06:26 · Score: 1

You're mostly right. PHP itself started out as a simple templating language, so adding another one on top is overkill. The trick is to use the different aspects of PHP in different places - put the complicated database stuff in included files, and just put the simple echo() stuff in the pages themselves.

Generally speaking, I write back-end PHP code that doesn't output anything at all. The front-end pages simply include() it and use the functions provided by the back-end to get the relevent data and present it to the user. This means that the actual pages themselves aren't very complex at all, and so there is little need for a templating system.

Of course, it helps that I use clean XHTML and CSS liberally, so there's no great tangle of tags to pick through.

There is a market for templating systems like Smarty, it's just much smaller than a lot of people believe - most general-purpose websites don't require user-specified skins, multiple HTML/WML/XML interfaces, etc.
Re:Validator by Doctor+O · 2004-07-21 06:45 · Score: 1

I don't really see how this is possibly funny. This is how it's done for *huge* projects in the real world, have templates for the different browsers and let that browser detection sort out which template to display. Hell, use smarty and do it for your private stuff as well even if you don't use different templates for different browsers. Separating code from presentation is a Good Thing(TM). You can fiddle with the look as much as you want, without even touching that PHP stuff.

--
Who is General Failure and why is he reading my hard disk?
Re:Validator by way2trivial · 2004-07-21 08:38 · Score: 1

It's a hell of a start, 40 problems found with
drumroll
the main google page
see it here

--
every day http://en.wikipedia.org/wiki/Special:Random
Re:Validator by Plac3bo · 2004-07-21 09:19 · Score: 1

This really isn't a trolling response, but all of these "hardcore-follow-the-standards" people are missing whats most important. That the page you build works correctly on the MAJORITY of browsers.

I make sure all my code is XHTML and CSS compliant, and that it works and looks good in IE, Firefox, Lynx/Links.

Too many people let their personal emotions get in the way. Most of the people with the same view as the parent here are anti-Microsoft, anti-BillGates, and pro-OSS. This is fine, except when it clouds your view of perspective.

"giving IE users a big 'ol middle finger" only makes you look like an incompetant programmer. Don't misunderstand me on this point, I know the browser does not render to standards, and that is a problem with the browser, not the site, but, to people that aren't programmers and don't know this (the majority of the population), they will only view your site as a POS.

Open your mind and see the big picture, not what your emotions are leading you towards.
Re:Validator by Pieroxy · 2004-07-21 12:52 · Score: 1

If there is anything worth seeing on the website, then users will find a way to see it
But how will the user know if there is something worth seeing on the website if he can't see it?

Web developers complain about having to code around IE's bugs, yet by continuing to do so they perpetuate the problem
If you don't care whether your web page works on IE, then you don't care about it at all. That's the other alternative.

--
Write boring code, not shiny code!
Re:Validator by SaDan · 2004-07-22 05:55 · Score: 1

have you told your clients that this is your position? or maybe you don't have clients and aren't in any way responsible or accountable for the design work you do? i wouldn'hire a web designer who thinks that way.

I used to design sites when I ran a small ISP, and later when I worked for a scientific research company out west.

Every site I designed displayed the W3C validated image for whatever version of HTML I was using at the time.

You wouldn't hire a designer who adhere's to standards? If that's the case, you have no one but yourself to blame when things take too long to code, or don't work properly in the end. No skin off my back, I wouldn't do work for you if that's the attitude you have.

if some people can't see the site or are seeing it render improperly, then not only has valuable interest in the site been wasted, but those people will then carry negative impressions which will, by word of mouth etc, spread.

That's not my problem. If the site is validated for HTML X.XX, and their browser doesn't handle it, it's their problem. Stay current, file a bug report, replace the browser, etc.

Also, there ARE ways of detecting what browser type is being used to view a site, and displaying a warning that the browser is incompatible, if the designer chooses to do so.

if you aren't worried about a rotting userbase, then you can think that way, but most people care if someone wants to see their site but can't. making a site that everyone can see and use properly is overkill, but if you're not even catering to IE6 then either you are trying to target a niche market (okay), or you just don't have your priorities straight, or you just don't have any responsibilities at all.

Funny, but for the most part, everything I've coded in the past tended to work very well, and I mainly used HTML 4.0 Strict. Sites were designed to be ADA compliant, and if it was too difficult to do with the normal site layout, I made a seperate, text only ADA site (which was accessed by being the very first link displayed on the page, upper left-hand corner of the browser window).

My priorities are perfectly fine. I've never had a complaint about any of my sites, and the code was very tight. Easy to read, easy to maintain, and 100% compliant, according to the W3C validators.

The best part was, I didn't waste hours of time designing a site around browser flaws.
Re:Validator by SaDan · 2004-07-22 06:13 · Score: 1

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

So, by testing your code, and then writing in fixes for browsers that are incompatible with HTML spec, that somehow fixes the larger problem of incompatible browsers?

"...or you can stick your head in the sand."

Or I can write compliant code, and the people who write browsers can fix their broken software.

Exactly which browsers do you think render HTML 4.0 properly?

IE and Mozilla do a good job, if the pages aren't overly complicated.
Re:Validator by SaDan · 2004-07-22 06:23 · Score: 1

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.

Is it still his fault if a company hires him to write a new web site in XHTML 1.1, and it doesn't work on IE? No, it's Microsoft's fault. Same goes for Mozilla, etc... Browsers need to render published spec properly, period.

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

They don't have too, no one's forcing them. Of course, no one will use their product if people start using XHTML 1.1 for all of their sites.

Gotta stay current with published specs if you want to play with the new toys on the 'net.

Stop right there. At no point did I advocate writing invalid code. But the point you seem to be arguing is that, as a web developer, once the code is valid, your job is done. That's complete rubbish, unless you don't mind your websites being inaccessible to everybody. Valid code is just a single step, it's not the finishing line.

So, in order to make the web sites accessible to everyone, he has to write invalid code, or just simply a lot more of it to cater to incompatible browsers.

Valid code should be the ONLY step.
Re:Validator by SaDan · 2004-07-22 06:30 · Score: 1

You write your code to W3C specs, and let the browser coders worry about meeting those specs.
Re:Validator by JimDabell · 2004-07-22 06:53 · Score: 1

So, by testing your code, and then writing in fixes for browsers that are incompatible with HTML spec,

At no point have I advocated writing code that is incompatible with the specifications. Please point out where you think I did.

that somehow fixes the larger problem of incompatible browsers?

No, writing valid code, testing, and including workarounds for browser bugs, solves the immediate problem of creating a website that is easily viewable by most people.

Or I can write compliant code, and the people who write browsers can fix their broken software.

In other words, you can stick your head in the sand. Ignoring browser bugs doesn't make the bugs go away, it makes your visitors go away. What's the point of building a website if you don't care whether people can use it or not?

Exactly which browsers do you think render HTML 4.0 properly?

IE and Mozilla do a good job, if the pages aren't overly complicated.

"A good job" isn't good enough. It only takes a single bug to render a page unreadable. Your exact words were:

You have a browser that is supposed to be HTML 4.0 compatible, but can't render my site? Go file a bug with the company/person who wrote the browser, or go and get a browser that CAN render HTML 4.0 properly.

Show me a browser that can render HTML 4.0 documents properly. I don't mean implements 95% of the specification, I mean 100%. You're so keen to point out that you should be able to just author to the spec and be done with it, but you have yet to name a browser that actually lives up to your ideals. No version of Internet Explorer or Mozilla has implemented the HTML 4 specification 100% correctly. It's no good authoring to spec and hoping that you didn't hit the 5% that a browser screws up.
Re:Validator by JimDabell · 2004-07-22 06:58 · Score: 1

You wouldn't hire a designer who adhere's to standards?

Straw-man. You seem to be interpreting "coding to spec isn't enough" as "coding to spec is wrong". You either don't have very good English comprehension skills, or you deliberately mischaracterise our points because you can't argue against our real points.

I certainly wouldn't hire a designer that didn't make sure the website was usable by its target audience.

if some people can't see the site or are seeing it render improperly, then not only has valuable interest in the site been wasted, but those people will then carry negative impressions which will, by word of mouth etc, spread.

That's not my problem. If the site is validated for HTML X.XX, and their browser doesn't handle it, it's their problem.

Wrong. In almost all cases, the user can simply go to another website to get what they want. It is, however, the website owner's problem, as they are losing visitors. No doubt this is why jswhiting asked if your clients knew about your attitude.

Also, there ARE ways of detecting what browser type is being used to view a site, and displaying a warning that the browser is incompatible, if the designer chooses to do so.

There are unreliable ways of detecting the browser type. If you've found a way that is reliable, then by all means, enlighten me.
Re:Validator by JimDabell · 2004-07-22 07:06 · Score: 1

Is it still his fault if a company hires him to write a new web site in XHTML 1.1, and it doesn't work on IE? No, it's Microsoft's fault.

No, it's the company's decision to use XHTML 1.1. As a responsible web developer, it's his responsibility to make sure that they are aware of the consequences. If they are aware, and still choose to go with XHTML 1.1, then it's their fault their website doesn't work in Internet Explorer. There are published specifications they can adhere to that work across many browsers including Internet Explorer, and they decided to go with a different format that doesn't work in Internet Explorer. That's their informed choice.

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

They don't have too, no one's forcing them. Of course, no one will use their product if people start using XHTML 1.1 for all of their sites.

Why would people deliberately shut out the majority of their visitors?

Gotta stay current with published specs if you want to play with the new toys on the 'net.

So which parts of XHTML 1.1 do you think are compelling enough to shut out the majority of surfers for? No, "because it's the highest version number" isn't an acceptable answer.

Stop right there. At no point did I advocate writing invalid code. [...]

So, in order to make the web sites accessible to everyone, he has to write invalid code, or just simply a lot more of it to cater to incompatible browsers.

What part of my plain English sentences do you not get? I'm not saying people should write invalid code! I'm saying that if you want any reasonable expectation of constructing a website that works to an acceptable level, you need to test in a range of browsers.
Re:Validator by SaDan · 2004-07-22 10:00 · Score: 1

Straw-man. You seem to be interpreting "coding to spec isn't enough" as "coding to spec is wrong". You either don't have very good English comprehension skills, or you deliberately mischaracterise our points because you can't argue against our real points.

You have yet to make a valid argument for not adhering to published specs for web content.

Coding to spec IS enough.

I certainly wouldn't hire a designer that didn't make sure the website was usable by its target audience.

Great. That's your decision, and has nothing to do with the fact that coding to spec should be enough with regards to publishing web content.

Wrong. In almost all cases, the user can simply go to another website to get what they want. It is, however, the website owner's problem, as they are losing visitors. No doubt this is why jswhiting asked if your clients knew about your attitude.

Because coding to spec instantly makes that site completely unuseable? I didn't realize that not a single web browser out there could render ANY W3C standard properly.

My clients did know about my attitude. And no one complained, or received any complaints, about their sites.

In fact, most clients were happy with my code when I turned it over to them, because it was easy to maintain, and read.

There are unreliable ways of detecting the browser type. If you've found a way that is reliable, then by all means, enlighten me.

Hey, if people are going to modify their browsers to lie about the build/software revision, there isn't anything I can do about that. In fact, there's nothing you can do about it either.

You must be one of those web developers looking for work... I can't think of anyone who'd WANT to have to code the same page six different ways.
Re:Validator by SaDan · 2004-07-22 10:10 · Score: 1

At no point have I advocated writing code that is incompatible with the specifications. Please point out where you think I did.

So, why are you putting in "fixes" if the browsers are in spec?

In other words, you can stick your head in the sand. Ignoring browser bugs doesn't make the bugs go away, it makes your visitors go away. What's the point of building a website if you don't care whether people can use it or not?

I'm very much not ignoring those bugs. I encourage everyone to report them to whoever makes their browser.

I've not had any issues with the web sites I've designed in the past. Visitors did not go away. No one complained about pages rendering improperly, etc.

"A good job" isn't good enough. It only takes a single bug to render a page unreadable.

I guess I've never written code that found that one bug that would trash my site.

Show me a browser that can render HTML 4.0 documents properly. I don't mean implements 95% of the specification, I mean 100%. You're so keen to point out that you should be able to just author to the spec and be done with it, but you have yet to name a browser that actually lives up to your ideals. No version of Internet Explorer or Mozilla has implemented the HTML 4 specification 100% correctly. It's no good authoring to spec and hoping that you didn't hit the 5% that a browser screws up.

That's funny... Then why does IE and Mozilla render whatever I've written in HTML 4.0 Strict properly? Granted, it's not overly complicated stuff, but they look the same, and work just fine.

But, whatever. If you feel the need to write six different versions of the same code so you can be "compatible", that's your choice. I'll stick to what I know, and what's worked for me and the people who've visited my sites in the past.
Re:Validator by SaDan · 2004-07-22 10:20 · Score: 1

No, it's the company's decision to use XHTML 1.1. As a responsible web developer, it's his responsibility to make sure that they are aware of the consequences. If they are aware, and still choose to go with XHTML 1.1, then it's their fault their website doesn't work in Internet Explorer. There are published specifications they can adhere to that work across many browsers including Internet Explorer, and they decided to go with a different format that doesn't work in Internet Explorer. That's their informed choice.

So, it's the company's fault for Microsoft's inability to render XHTML 1.1? And you think I have issues with comprehension and the English language...

We're talking about code and browsers here, and regardless of who's writing code for who, as long as that code meets spec, the burden falls on the browser to render the site properly.

Why would people deliberately shut out the majority of their visitors?

To make a point? It's their choice, it's their site. If you can't render it because your browser is out of date, who's fault is it?

What part of my plain English sentences do you not get? I'm not saying people should write invalid code! I'm saying that if you want any reasonable expectation of constructing a website that works to an acceptable level, you need to test in a range of browsers.

Fine, don't have to write "invalid" code. Then why do you have to write more to make it work?

And just so I've said it somewhere in this crazy ass thread, I do NOT believe web designers should have to write code to support out of date browsers. People need to keep software current, if not for compatibility, for security.
Re:Validator by JimDabell · 2004-07-22 11:32 · Score: 1

So, it's the company's fault for Microsoft's inability to render XHTML 1.1?

Sigh. No. It's the company's fault that Internet Explorer can't render their particular website. It's Microsoft's fault that Internet Explorer can't render XHTML 1.1 in general. The company have the choice of adhering to the XHTML 1.0 specification and being compatible with far more surfer setups, if they choose not to that's their business.

You still haven't answered my question - what parts of XHTML 1.1 make it so compelling people would shut out most surfers for it? Do you even know the differences between XHTML 1.0 and 1.1?

We're talking about code and browsers here, and regardless of who's writing code for who, as long as that code meets spec, the burden falls on the browser to render the site properly.

Just because something is written down, and the label "specification" stamped upon it, it does not mean that suddenly every user-agent creator everywhere must implement it or they will be at fault. I don't see anybody blaming Microsoft for not implementing RFC 1149, for example.

There are certain specifications that you have a reasonable expectation of being implemented in a web browser. HTML 4.01 is one of them, it offers many advantages not found in earlier HTML specifications and is in widespread use. XHTML 1.1, on the other hand, offers very little beyond what XHTML 1.0 provides, and virtually nobody uses it or even wants to. So nobody is in a position to expect or demand implementation by user-agent developers.

Why would people deliberately shut out the majority of their visitors?

To make a point?

Believe it or not, most people have websites in order to communicate with people, not to make points by deliberately not communicating with people. And, given the context of the question "how do you test your websites?", it's quite clear that excluding people because of bugs is the last thing on anybody's mind.

Fine, don't have to write "invalid" code. Then why do you have to write more to make it work?

To ensure it works correctly for the most people possible.

I do NOT believe web designers should have to write code to support out of date browsers. People need to keep software current, if not for compatibility, for security.

The latest versions of all mainstream browsers get HTML at least a little bit wrong. Whether a browser is up-to-date or not doesn't matter in the context of HTML implementation bugs.
Re:Validator by JimDabell · 2004-07-22 11:51 · Score: 1

At no point have I advocated writing code that is incompatible with the specifications. Please point out where you think I did.

So, why are you putting in "fixes" if the browsers are in spec?

Once more, you are arguing against indefensible points I haven't made. Please point out where you think I said that browsers are in spec. I have repeatedly said otherwise in this thread. Please work on your English comprehension skills!

I've not had any issues with the web sites I've designed in the past. Visitors did not go away. No one complained about pages rendering improperly, etc.

Lucky you. It sounds like you have coincidentally used parts of HTML that fall in the 95% compatible range, and not the 5% incompatible range. If somebody complained about your website breaking, what would you do if the code was completely valid? What if a hundred people complained? What about a thousand? What if everybody visiting your website complained?

I guess I've never written code that found that one bug that would trash my site.

I have. The most striking one I can recall was that all the text on the page would be invisible until you minimised and restored the window. That one affects completely valid code, and would have affected the majority of the website's visitors. The fix was a single line of code that was a complete no-op according to spec.

You are telling me that I shouldn't have put that line in, and told the majority of the visitors to switch browsers? How exactly was I supposed to tell them that, seeing as none of the text was showing up?

In case you are thinking it's made up, or that it's a contrived example, it's not. The bug was the well-documented Internet Explorer "peekaboo" bug.

No version of Internet Explorer or Mozilla has implemented the HTML 4 specification 100% correctly. It's no good authoring to spec and hoping that you didn't hit the 5% that a browser screws up.

That's funny... Then why does IE and Mozilla render whatever I've written in HTML 4.0 Strict properly? Granted, it's not overly complicated stuff, but they look the same, and work just fine.

Probably because of a combination of luck and the aforementioned lack of complicated stuff. Simple stuff like <p>foo...</p> is going to be well-tested in browsers.

You still haven't answered my question. Which browser can render HTML 4.0 documents properly? If I trigger a bug with my valid code, which browser am I supposed to tell people to switch to? You've told me that my visitors should switch to a decent browser, but the ones you've mentioned, Internet Explorer and Mozilla, don't implement HTML 4.0 without bugs that can make a website completely unusable. So what am I supposed to tell people to use?

If you feel the need to write six different versions of the same code so you can be "compatible", that's your choice.

Once more, you are putting words in my mouth. I never said that.
Re:Validator by JimDabell · 2004-07-22 12:01 · Score: 1

You have yet to make a valid argument for not adhering to published specs for web content.

That's because I'm not arguing that you shouldn't. Is English your first language (honest question)?

Coding to spec IS enough.

Enough to do what? Build a website that will be usable by most people? It certainly isn't. Are you saying that you think that, as long as a document is valid, a surfer will have little difficulty in reading it?

Because coding to spec instantly makes that site completely unuseable?

I never said that either.

I didn't realize that not a single web browser out there could render ANY W3C standard properly.

Okay. Let's say you were building a website. Are you saying that there is an HTML document type out there that mainstream browsers can handle without fault? Please provide exact names and versions of both the document type and the browsers that can supposedly handle it.

There are unreliable ways of detecting the browser type. If you've found a way that is reliable, then by all means, enlighten me.

Hey, if people are going to modify their browsers to lie about the build/software revision, there isn't anything I can do about that. In fact, there's nothing you can do about it either.

So your initial point that you can display a warning to incompatible browsers wasn't wholly true then, was it? Modification of the browser is not necessary either.
Re:Validator by SaDan · 2004-07-22 13:25 · Score: 1

That's because I'm not arguing that you shouldn't. Is English your first language (honest question)?

So, then what exactly are you arguing about?

And yeah, English is my first language. Is it yours? I ask because...

Enough to do what? Build a website that will be usable by most people? It certainly isn't. Are you saying that you think that, as long as a document is valid, a surfer will have little difficulty in reading it?

Enough to have a web site that works. If it "certianly isn't", then why does my HTML seem to work just fine between IE and Mozilla? No difficulties at all for the surfers.

I never said that either.

You didn't explicity say that, sure, but that's what you're implying, because everything I've said so far is in defense of using the spec and not putting in "fixes", and we're disagreeing somewhere.

Okay. Let's say you were building a website. Are you saying that there is an HTML document type out there that mainstream browsers can handle without fault? Please provide exact names and versions of both the document type and the browsers that can supposedly handle it.

Sure. HTML 4.0 Strict. Everything I've written that complied with that standard seems to work just fine and dandy under IE 5/6, and versions of Mozilla from 1.0 on up.

No, it's not complicated stuff, but it does render properly, and does adhere to HTML 4.0 Strict.

So your initial point that you can display a warning to incompatible browsers wasn't wholly true then, was it? Modification of the browser is not necessary either.

It's entirely true, it just may be ineffective with a small group of people who have their browsers report a different version than what's actually being run. It might be more work than it's worth, basically.. Kinda like putting in fixes to already properly written web pages.
Re:Validator by SaDan · 2004-07-22 13:42 · Score: 1

Once more, you are arguing against indefensible points I haven't made. Please point out where you think I said that browsers are in spec. I have repeatedly said otherwise in this thread. Please work on your English comprehension skills!

Then what points are you arguing here? I'm defending the use of spec code, and not messing with "fixes" to get around browser problems.

My English is fine, thank you. I completely understand what you are saying, I just don't agree with it.

You see, I understand your side. I really do. I just don't see why you think the way you do. Get it?

Lucky you. It sounds like you have coincidentally used parts of HTML that fall in the 95% compatible range, and not the 5% incompatible range. If somebody complained about your website breaking, what would you do if the code was completely valid? What if a hundred people complained? What about a thousand? What if everybody visiting your website complained?

I must be lucky. I probably did use all of the parts of HTML that work everywhere. Doesn't take away from the fact that HTML 4.0 Strict works for me.

If someone complained about my web site, I would ask them what browser they were using. If it's not compatible, I'd advise them to upgrade to a more modern browser.

If I had many people complaining, I'd have to put up a disclaimer on the web site stating that incompatible browsers may not render the site properly, and that users should seek a more modern browser.

I have. The most striking one I can recall was that all the text on the page would be invisible until you minimised and restored the window. That one affects completely valid code, and would have affected the majority of the website's visitors. The fix was a single line of code that was a complete no-op according to spec.

You are telling me that I shouldn't have put that line in, and told the majority of the visitors to switch browsers? How exactly was I supposed to tell them that, seeing as none of the text was showing up?

That's an interesting bug.

Yes, I would have told everyone their browser was defective, and that they needed to seek a fix from the software company that produced the browser.

How would I have told them? That's a good question... Actually, I would have called MS and reported the issue. It's their problem.

Probably because of a combination of luck and the aforementioned lack of complicated stuff. Simple stuff like
foo...
is going to be well-tested in browsers.

Yeah, all luck. I should start playing the lottery, because I apparently luck out with HTML!

You still haven't answered my question. Which browser can render HTML 4.0 documents properly? If I trigger a bug with my valid code, which browser am I supposed to tell people to switch to? You've told me that my visitors should switch to a decent browser, but the ones you've mentioned, Internet Explorer and Mozilla, don't implement HTML 4.0 without bugs that can make a website completely unusable. So what am I supposed to tell people to use?

Have them hit your ADA link/site with Lynx.

I can tell this kind of stuff keeps you up at night... I never new the internet could be so stressful.
Re:Validator by SaDan · 2004-07-22 13:55 · Score: 1

Sigh. No. It's the company's fault that Internet Explorer can't render their particular website. It's Microsoft's fault that Internet Explorer can't render XHTML 1.1 in general. The company have the choice of adhering to the XHTML 1.0 specification and being compatible with far more surfer setups, if they choose not to that's their business.

Thank you. I could care less about the company's decision, I just wanted to know who's at fault for IE not supporting XHTML 1.1.

You still haven't answered my question - what parts of XHTML 1.1 make it so compelling people would shut out most surfers for it? Do you even know the differences between XHTML 1.0 and 1.1?

I've never coded in XHTML. It was just used as an example because of the blatant incompatibilities with most browsers.

Just because something is written down, and the label "specification" stamped upon it, it does not mean that suddenly every user-agent creator everywhere must implement it or they will be at fault. I don't see anybody blaming Microsoft for not implementing RFC 1149, for example.

LOL... That's a good one.

Of course, it's completely irrelevant to our discussion, because RFC 1149 will not be widely used, whereas XHTML 1.1 will.

If MS and Mozilla are working on updates to their browsers that will include support with XHTML 1.1, that's fine. The good news is I can write a web site that will work properly when browsers can render it properly, right now.

Believe it or not, most people have websites in order to communicate with people, not to make points by deliberately not communicating with people. And, given the context of the question "how do you test your websites?", it's quite clear that excluding people because of bugs is the last thing on anybody's mind.

I have no problem with any of that, because it's all true, for the majority of people. I can respect that.

The latest versions of all mainstream browsers get HTML at least a little bit wrong. Whether a browser is up-to-date or not doesn't matter in the context of HTML implementation bugs.

If there are bugs, the browser is broke. That's all I'm trying to impress upon you.
Re:Validator by JimDabell · 2004-07-22 20:40 · Score: 1

Of course, it's completely irrelevant to our discussion, because RFC 1149 will not be widely used, whereas XHTML 1.1 will.

That's very doubtful. In practical terms, there is very little difference between XHTML 1.0 Strict and XHTML 1.1 for authoring websites, except that XHTML 1.1 cannot be served as text/html and so is far less compatible - not just with Internet Explorer, but with most search engines, most text-only web browsers, and, if it wasn't for a bug, Konqueror.

Most people will probably go as far as XHTML 1.0 before upgrading to whatever the next big thing is, whether that's XHTML 2.0 or whatever. XHTML 1.1 just isn't worthwhile for web authors except in very limited circumstances.

If there are bugs, the browser is broke. That's all I'm trying to impress upon you.

That I agree with. However we differ on whether it is acceptable to work around them or not. Given the context of "how do you test your web pages", or web authoring in general, I'd say it's not only acceptable but expected to go to reasonable efforts to accomodate common browsers, even if it's not your fault.
Re:Validator by JimDabell · 2004-07-22 20:55 · Score: 1

Then what points are you arguing here? I'm defending the use of spec code, and not messing with "fixes" to get around browser problems.

Are you aware that you can work around browser bugs without Herculean effort or going out of spec? For instance, when applied to an HTML document, the CSS "* html #foo { height: 1px; }" will fix a number of Internet Explorer bugs, even though, according to HTML and CSS specifications, it should do absolutely nothing.

It seems to me you are under the impression I am advocating developing multiple versions of websites and going out-of-spec. I am not. I have never said that. That is why I am saying you should check what I have actually said rather than reading something into it that simply isn't there.

Yes, I would have told everyone their browser was defective, and that they needed to seek a fix from the software company that produced the browser.

Well then, with all due respect, you are a very unusual case, and probably not the kind of person that somebody asking the question "how do you test your web pages?" is likely to respond well to.

I feel safe in the assumption that most people want their websites to be actually usable. The point that I am making about no browser being 100% compatible with HTML is very pertinent - unless you test, you don't know ahead of time whether your website is working for anyone.

Have them hit your ADA link/site with Lynx.

Sorry, Lynx doesn't render HTML properly either.
Re:Validator by JimDabell · 2004-07-22 21:46 · Score: 1

Enough to do what? Build a website that will be usable by most people? It certainly isn't. Are you saying that you think that, as long as a document is valid, a surfer will have little difficulty in reading it?

Enough to have a web site that works. If it "certianly isn't", then why does my HTML seem to work just fine between IE and Mozilla?

Because you happen to use the subset of HTML that works in those browsers and don't trigger any of their bugs. Since you aren't a fan of giving buggy browsers special consideration, I can only assume that this is simply a happy accident.

Because coding to spec instantly makes that site completely unuseable?

I never said that either.

You didn't explicity say that, sure, but that's what you're implying, because everything I've said so far is in defense of using the spec and not putting in "fixes", and we're disagreeing somewhere.

I am not saying that valid code instantly makes something unusable. I am saying that, given that no browser has flawless support for the specifications, you have no reasonable basis for believing that valid (or invalid, for that matter) code will work in any given browser unless you test in it. Like I keep saying, validation isn't enough to ensure things work.

Are you saying that there is an HTML document type out there that mainstream browsers can handle without fault? Please provide exact names and versions of both the document type and the browsers that can supposedly handle it.

Sure. HTML 4.0 Strict. Everything I've written that complied with that standard seems to work just fine and dandy under IE 5/6, and versions of Mozilla from 1.0 on up.

Okay, then try this HTML 4.0 Strict document in those browsers. It's valid, it's perfectly sane code and it doesn't use any special tricks.

In Safari 1.0.2, Mozilla 1.4, Mozilla 1.6, OmniWeb 4.5, Firefox 0.8, Konqueror 3.2.3, Dillo 0.8.0, w3m 0.5.1 and Links 2.1pre11, it displays a blank page.

In Opera 6.03, Opera 7.52, Netscape 4.79 and Windows Internet Explorer 5.0, 5.5 & 6.0, it displays the source code.

In Mac Internet Explorer 5.2.3, it displays the source code in the title bar.

Lynx 2.8.5rel.1 gets closest, actually displaying the content, but with slashes all over the place.

Now that's about as simple an HTML 4.0 document as you can get, containing nothing but a paragraph saying "This is a test.". According to you, as long as it's valid (and it is), I don't have a problem, right? After all, it's not my fault, it's the fault of browser creators. Suppose I triggered these browser bugs on a production website. Which browser would you suggest I tell people to switch to?

No, it's not complicated stuff, but it does render properly, and does adhere to HTML 4.0 Strict.

Well that's great, but deliberately or not, you are only using the bits of HTML that work in common browsers and are avoiding the bits that don't work in common browsers. Valid HTML isn't enough to make a website that works; you need to give special consideration to browsers with bugs. In your case, you do so by avoiding code that is valid but that browsers have difficulty with.

So your initial point that you can display a warning to incompatible browsers wasn't wholly true then, was it? Modification of the browser is not necessary either.

It's entirely true, it just may be ineffective with a small group of people

So it's "entirely" true, except when it isn't? ;)
Re:Validator by SaDan · 2004-07-23 03:33 · Score: 1

Interesting example. I've not written HTML in that style, so I've never seen that kind of behavior.

Of course, the following is your example how I would have written it.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> < html > < head > < meta http-equiv="Content-Type" content="text/html;charset=utf-8" > < title >Example< /title > < /head > < body > < p >This is a test< /p > < /body > < /html >
And that's valid as well. (spaces are in the tags to keep Slashdot from mangling the code)

I used the same bits of HTML you did, and managed to make it work with Mozilla.

Anyways... Your version is supposed to work. The browsers are broken.
Re:Validator by SaDan · 2004-07-23 03:42 · Score: 1

Lynx does render basic HTML very well. Lynx ran perfect with my ADA version of my old ISP's site, as did every other browser I tried at the time (this was a couple years ago).

It sounds like all of our disagreements are stemming from how each of us write HTML. I don't use anything fancy, probably stick more to the old-school methods of laying out a site and the content.

At any rate, it's a shame the people who write web browsers can't keep up with the standards.
Re:Validator by SaDan · 2004-07-23 03:46 · Score: 1

However we differ on whether it is acceptable to work around them or not. Given the context of "how do you test your web pages", or web authoring in general, I'd say it's not only acceptable but expected to go to reasonable efforts to accomodate common browsers, even if it's not your fault.

As I've said in a different reply, I must just use older HTML writing style, which works better with browsers than the latest style. My standard method of writing HTML is probably what you'd consider as a work around, because it's not as short as that example you gave in the other thread.

Stonewall IE by ArmorFiend · 2004-07-20 06:11 · Score: 1

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.

Re:Stonewall IE by Phillup · 2004-07-20 07:02 · Score: 1

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".

--

--Phillip

Can you say BIRTH TAX
Re:Stonewall IE by Anonymous Coward · 2004-07-20 07:13 · Score: 1, Informative

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".

No browser supports getElementById() when they have Javascript switched off. What, you pass up all the lucrative contracts with accessibility requirements? Web accessibility is the new Y2K, especially here in the UK where they are beginning to enforce the Disability Discrimination Act.
Re:Stonewall IE by Enrico+Pulatzo · 2004-07-20 07:14 · Score: 1

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).
Re:Stonewall IE by Anonymous Coward · 2004-07-20 08:18 · Score: 0

AFAIK, no "accessibility requirement" has ever prohibited Javascript. Stop using Lynx and get a screenreader that supports modern HTML. Problem solved.

Most of this seems to be FUD spread by old-timer grognards that are pissed they can't use Netscape 3 until the end of time.
Re:Stonewall IE by Anonymous Coward · 2004-07-20 09:17 · Score: 0

Bzzt, you've just sounded my "utterly clueless" alarm.

Firstly, nobody is talking about prohibiting Javascript. The person I was responding to was talking about requiring Javascript support. It's perfectly possibly to use Javascript without requiring it.

Not just that, but the first and foremost accessibility requirements are the ones laid out by the W3C. What do they say?

6.3 Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported.

So it's clear that when you are talking about what accessibility requirements are in place, you are talking directly out of your arsehole.

"A screenreader that supports modern HTML" isn't the problem. Perhaps you are unaware of what HTML and Javascript are? Javascript is not part of HTML, modern or otherwise. It's certainly not a required part of it.
Re:Stonewall IE by Phillup · 2004-07-20 10:45 · Score: 1

No browser supports getElementById() when they have Javascript switched off.

True.

But, I've yet to come across anyone that wants to pay to create a web *application* that is not also interested in some dynamic action.

It may be as simple as wanting to select all check boxes at once... or deselect them all at once.

This will either require JavaScript, Java, ActiveX... or some other technology above and beyond plain old HTML.

JavaScript is by far (IMHO) the least "bad" of the options. (For various definitions of "bad")

And, these applications are always (so far) inside the firewall (on the intranet) where the company can explicitly control what browser(s) will be used.

And, you can get around "accessibility requirements" by not requiring anyone with a disability to use the application.

Companies do it all the time. Most of them are in such a bind to get *something* up and running... that accessibility is way down on the list.

--

--Phillip

Can you say BIRTH TAX
Re:Stonewall IE by Phillup · 2004-07-20 10:56 · Score: 1

No browser supports getElementById() when they have Javascript switched off.

I gave a more serious answer above... here is the smartass answer. ;-)

You can explain why JavaScript was switched off to HR during your exit interview.

--

--Phillip

Can you say BIRTH TAX
Re:Stonewall IE by Anonymous Coward · 2004-07-20 12:47 · Score: 0

You've lost me. It looks like you are trying to suggest switching off Javascript in your browser is liable to get you fired, but that doesn't make any sense.
Re:Stonewall IE by Anonymous Coward · 2004-07-20 12:50 · Score: 0

But, I've yet to come across anyone that wants to pay to create a web *application* that is not also interested in some dynamic action.

Why is it that the people most interested in pushing Javascript are the ones who understand it the least?

It is perfectly possible to use Javascript without making your website dependent upon it. Javascript was designed that way. Stop with the straw man arguments, nobody is suggesting a ban on Javascript.

And, you can get around "accessibility requirements" by not requiring anyone with a disability to use the application.

What a ridiculous notion. If an employer here told an employee that they shouldn't use an intranet application because they are disabled, they'd be on the wrong end of a lawsuit very quickly.
Re:Stonewall IE by Phillup · 2004-07-21 03:43 · Score: 1

It is perfectly possible to use Javascript without making your website dependent upon it. Javascript was designed that way. Stop with the straw man arguments, nobody is suggesting a ban on Javascript.

Well, my point wasn't about "pushing" JavaScript.

My point was about using JavaScript to detect old and outdated browsers.

Someone else brought up the "but I don't have JavaScript enabled" blather.

That isn't my problem. If you don't want to meet the minimum requirements to use my site, then go away. It is my site (or the site of the person paying me) and the user is not part of the decision making process.

Options are weighed, decisions are made. Get over it.

Next, someone will say requiring a browser is "asking too much".

Not only that, but you are missing the point. The point is that JavaScript is REQUIRED as a design consideration. ON PURPOSE.

Yep, that is right. Someone is purposely making a decision to do something you (apparently) don't like... probably even something you or "they" consider to be a "bad" decision. I'm sure it won't be the last time that happens.

I'm not trying to make JavaScript optional, that isn't a goal. The goal is exactly the opposite. Anything that doesn't meet that goal, is failure.

If an employer here told an employee that they shouldn't use an intranet application because they are disabled, they'd be on the wrong end of a lawsuit very quickly.

Then don't say it is "because they are disabled". If that is the real reason, then there is a problem. And there should be trouble.

But, every job has skill requirements. And, the poeple doing the job should meet those requirements. People are not one to one interchangeable. So, every tool can not possibly be usable by every person.

That is life.

My point wasn't about "getting around" some accessibility law... it was about designing the tool for the people that are going to be doing the job. In the cases I've worked on to date, that meant people without disabilities.

The software designed by a company for it's EMPLOYEES should meet the needs of those people, not some imagined person that isn't there at the time and may never be. If none of them are disabled, then why should the product take into consideration a non-existant disability?

Next you would want to force Santa to have all of the tools in his workshop usable by "normal" sized people... even tho none of the workers are "normal" sized... and couldn't handle tools of that size to boot.

--

--Phillip

Can you say BIRTH TAX
Re:Stonewall IE by Phillup · 2004-07-21 03:47 · Score: 1

My original points in this thread were concerning development of web applications for a company intranet.

The company decides on the browser requirements for its employees... including turning JavaScript on (or off).

If you are saying you can't do your job (use the intranet software) because you have disabled JavaScript (even tho the company policy is to enable it)... then you can explain the problem on your way out the door.

It isn't a personal decision in the context of employeement.

And that is the context of my remarks.

HTH

--

--Phillip

Can you say BIRTH TAX
Re:Stonewall IE by Anonymous Coward · 2004-07-22 00:59 · Score: 0

Not only that, but you are missing the point. The point is that JavaScript is REQUIRED as a design consideration. ON PURPOSE.

And my point is that you are turning away legitimate users. In at least the UK, the USA, and Australia, these might be legitimate users that you have a legal responsibility to not discriminate against.

Sure, if you are coding some crappy homepage, feel free to turn people away on a whim. But when you have a responsibility to build a website for others, I'm sure they wouldn't appreciate your Javascript snobbery causing them to have less visitors, and I'm sure they wouldn't appreciate having to hire somebody else to fix your code when they are threatened with a lawsuit or get a bollocking from their superiors.

But, every job has skill requirements. And, the poeple doing the job should meet those requirements.

That's a red herring. To give an example, somebody who is blind could quite easily use intranet web apps via use of a screenreader as long as the web apps are coded right to begin with. But if you make it impossible for them to use the app, you'd better have a damn good reason, or you *will* fall foul of employment laws. Weeding out "crappy browsers" is not a damn good reason.

The software designed by a company for it's EMPLOYEES should meet the needs of those people, not some imagined person that isn't there at the time and may never be. If none of them are disabled, then why should the product take into consideration a non-existant disability?

Because they may have disabled employees in the future. This happened to a mate of mine a couple of years ago. They hired a bunch of people with your attitude to build a load of intranet web apps. A while down the line, the firm hired a disabled person. When the management found out that the apps didn't work for her because the people who built them cut corners, they went apeshit. And ended up having to put in a lot of resources to implement things all over again. At no point did they say "shit, let's just get rid of the disabled person" - she was a highly valuable employee, whose disability had no bearing on her actual job.
Re:Stonewall IE by Anonymous Coward · 2004-07-22 01:02 · Score: 0

My original points in this thread were concerning development of web applications for a company intranet.

Then perhaps you should have mentioned that. You only mentioned "web application". There are plenty of public web applications knocking about, so it doesn't imply "company intranet".

If you are saying you can't do your job (use the intranet software) because you have disabled JavaScript (even tho the company policy is to enable it)... then you can explain the problem on your way out the door.

If Javascript poses problems for you because you have a disability, and the company fired you, you'd have a rock-solid wrongful termination lawsuit.
Re:Stonewall IE by Phillup · 2004-07-23 12:28 · Score: 1

And my point is that you are turning away legitimate users.

How? It is a company intranet. The company decides on the browser to be used and the settings that browser will have.

Who is turned away?

Weeding out "crappy browsers" is not a damn good reason.

If the browser doen't do JavaScript, and the company spec's JavaScript, then it isn't suitable for the task.

Because they may have disabled employees in the future.

This is true. Very true.

But that is not my call. That is the call of the company requesting the work.

I can't make them pay for a feature they swear they don't need.

My point is that the company spec'ing the work gets to decide what they want to pay for. And, many of them will simply say that they won't have a person with disabilities do that particular task.

My job as the contractor is to give them options and complete the work. One of the most selected options is to not support older browsers. The other is to have some method of doing "interactive" tasks w/o a trip to the server.

Most IT departments I've worked with consider JavaScript to be the least burdomsome technology to deploy, especially across homogenous clients.

I am not a lawyer, and I often suggest to them that they may want to talk to their company lawyers about certain issues (mostly privacy stuff)... but, that is as far as my role goes in that respect.

--

--Phillip

Can you say BIRTH TAX
Re:Stonewall IE by Phillup · 2004-07-23 12:55 · Score: 1

I split this into two replies because there are two distinct issues here (in my mind).

That's a red herring.

Maybe, but I don't think so. Actually, your next statement looks like the red herring. Let's think about this a bit and see...

To give an example, somebody who is blind could quite easily use intranet web apps via use of a screenreader as long as the web apps are coded right to begin with.

Yeah, the web would be a great place if pages were coded "right" to begin with.

But, first one has to define "right".

Not only that, but the job could require looking at web pages not designed by your company. Pages you have no control over, at all.

And, to say that the blind person could us the app doesn't take into consideration what the app actually does. It is entirely possible that what it does falls outside the ability of a screen reader to "comprehend".

I used to have a job where I was tested each year to make sure I was not color blind. Not only did you have to have your sight, but you could not be color blind. Perfectly legal, because it was a legitimate need.

That's a lot of holes for such a generic statement...

But if you make it impossible for them to use the app, you'd better have a damn good reason, or you *will* fall foul of employment laws.

It isn't about making it impossible for them, it is about not making it possible for them. It is a matter of intent.

The company could just as easily have decided to create an application that ran on a palm pilot. Or as a Linux executable, or only runnable on the BeOS. None of these decisions are about making it impossible for a disabled person... they are technology choices.

Just as creating a web app is a technology choice. And, just as using JavaScript is a technology choice. They are not about excluding a class of people, they are about enabling certain features.

You stay out of trouble by doing things for legitimate reasons.

Weeding out "crappy browsers" is not a damn good reason.

If the company chooses not to use crappy browsers, it is a fine reason. It is no different than establishing a firewall policy and blocking ActiveX.

--

--Phillip

Can you say BIRTH TAX

Moz, IE and W3C standards by palfrey · 2004-07-20 06:14 · Score: 2, Insightful

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. 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.

--
Beware the psychokinetic mimes!

Its a nightmare... by haplo21112 · 2004-07-20 06:15 · Score: 1

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 started on the whole Javascript thing between browser makers. That one thing getting standardized, would simplifiy my life so much I scream for it...Make Java/Emca Script work the same in all broswers...it sounds so simple.

--
Power Corrupts,Absolute Power Corrupts Absolutely, leaving one person(group)in charge is absolutely corrupt.

BrowserCam by bjpirt · 2004-07-20 06:16 · Score: 4, Insightful

If you don't want to buy a mac, you could always use browsercam

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.

Re:BrowserCam by Jkames · 2004-07-20 07:05 · Score: 3, Interesting

Actually. You can get a program called PearPc which allows you to emulate a mac. It's was in constant developement before one of it's programmers got hit by a train.
Re:BrowserCam by Ianoo · 2004-07-20 07:21 · Score: 3, Insightful

If anyone hasn't heard what the parent is refering to, then see the announcement here. RIP to him and my thoughts to his family.
Re:BrowserCam by magefile · 2004-07-20 08:20 · Score: 1

I beg to differ. Windows IE renders differently from Mac IE. Unless you mean using a virtual machine. In which case, you're spending a few hundred; if you're in a company that has any money at all, just bite the goddamn bullet and buy the $500 Dell special of the week. Either way, burn Knoppix and test it in Linux (OTOH, Konq/Moz/Fire* are fairly standards-compliant, and Moz/Fire* are pretty much the same from OS to OS, unlike IE).
Re:BrowserCam by aWalrus · 2004-07-20 09:31 · Score: 4, Informative

Or you can try iCapture, which is free.

--
Overcaffeinated. Angry geeks.
Re:BrowserCam by Anonymous Coward · 2004-07-20 10:58 · Score: 0

He clearly meant using Virtual PC, which is cheaper than buying a separate PC. With Virtual PC, he can test different versions of IE (5, 5.5, 6) on Windows on his Mac. Actually using multiple versions of IE on a mere Windows machine is more difficult.

So with a Mac, you can test Safari, Mozilla, Firefox, Camino, Netscape, Opera, Omniweb, Mac IE, and Windows IE. The only thing you can't directly test is Konqueror, but I wouldn't worry about that one anyway.

Man, notice how much choice in browsers Mac users have compared to other people? They're all good, too.
Re:BrowserCam by WestonB · 2004-07-21 00:39 · Score: 1

Why can't you test Konqueror? Just install Linux on Virtual PC. You could even skip running X11 within the virtual machine and loop it back to X11.app

Or dual boot to a PowerPC version of Linux.

Using a Mac, I believe you can test just about every known browser.

Significant Other? by jtheory · 2004-07-20 06:18 · Score: 3, Interesting

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.

--
There are only 10 types of people: those who understand decimal, those who don't, and, uh, 8 other types I forget.

Re:Significant Other? by elementik · 2004-07-22 21:31 · Score: 1

I think its fantastic how you've used your wife as an excuse to get another machine in the house.

I salute you :D

--
--- Stop the world! I want to get off!

Mac by octover · 2004-07-20 06:19 · Score: 4, Interesting

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).

When are we going to get some challenging Ask /.? by stienman · 2004-07-20 06:20 · Score: 2, Insightful

Do a Google search, and you'll find companies, tools and instructions, 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

site mechanic by BugNuker · 2004-07-20 06:20 · Score: 1

there are sevral websites out there that will spider your webpage, check for broken links, bad code, browser corss compatibitly. I have even seen one before that took a screenshot of what your page looked like in other browsers. check it out, do some google, search for site mechanic good luck -BugNuker

Browsercam, standards by Bistronaut · 2004-07-20 06:23 · Score: 2, Informative

Browsercam 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 and the CSS-Discuss Wiki.

Simple enough by Arkham · 2004-07-20 06:23 · Score: 1

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.

--
- Vincit qui patitur.

Timely Ask Slashdot by Anonymous Coward · 2004-07-20 06:24 · Score: 0

Is this some sort of subtle jab at the slashdot editors in response to all the 503 errors we're getting today while trying to access slashdot?

I code under linux and then ask someone to check by xutopia · 2004-07-20 06:26 · Score: 1

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.

Test pages online by Nemozob · 2004-07-20 06:27 · Score: 1

This is a little time consuming and you can only test one page at a time, but in the absence of Virtual PC or the like (I'm on a Mac) or having all the browsers & platforms you need you can always test them here. I will usually run a page template through this using a free one-day trial account. http://browsercam.com/ I have no connection to the company, I'm just a satisfied leech.

Use Standards by rawg · 2004-07-20 06:30 · Score: 1

I have been using web standards for a long time. I have a few computers to test with here in my office. The only problems I ever run into is on MSIE. All the other major browsers display the standards web pages just fine.

What I do to fix the MSIE problems is not use the code that causes the problems. I stick with XHTML 1.0 and CSS 1.0. I have some CSS 2.0 elements that work in MSIE. There are a lot of others that don't.

The tools that I use for testing are:
One old Windows 98 laptop running MSIE.
One Mac OS X system running MSIE, Safari, Mozilla, and Omniweb (default browser).
One Linux system running Mozilla and Konqueror.
Heavy use of the W3C's validator application.

I do all my work on my Mac using Omniweb, SubEthaEdit, and the W3C Validator.

So far no problems with compatibility. All sites seem to render fine across all browsers.

--
The above is not worth reading.

Yes by ccarr.com · 2004-07-20 06:35 · Score: 2, Insightful

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.

--
I don't know half of you half as well as I should like, and I like less than half of you half as well as you deserve. BB

You made a bad choice by fozzmeister · 2004-07-20 06:38 · Score: 2, Insightful

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.

web devel environment by OmniVector · 2004-07-20 06:42 · Score: 2, Informative

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>

--
- tristan

Re:web devel environment by croddy · 2004-07-20 06:48 · Score: 1

decode64 is deprecated; use Base64.decode64 instead
Re:web devel environment by OmniVector · 2004-07-20 07:16 · Score: 1

hmm. i'm running ruby 1.8.1, but i get this:

ruby -e 'require "base64";puts Base64.decode64("U3RlcCByaWdodCB1cC4gTWFyY2guIFB1c 2gu")' -e:1: uninitialized constant Base64 (NameError)

--
- tristan
Re:web devel environment by Fweeky · 2004-07-20 07:31 · Score: 1

-e:1:in `decode64': _deprecated_base64 is deprecated; use Base64._deprecated_base64 instead ... -% ruby -v ruby 1.8.1 (2004-05-02) [i386-freebsd5]
Your install sounds broken. Base64.decode64 works fine here.
Re:web devel environment by magefile · 2004-07-20 08:22 · Score: 1

I don't know if it's Venkman itself, or a wrapper for Venkman (Moz's Javascript debugger), but there's an extension for Fire*, yeah.
Re:web devel environment by tcopeland · 2004-07-20 08:41 · Score: 1

Yup, I think those methods were moved into a new Base64 module after the 1.8.1 release. There are some notes on it here.

--
The Army reading list

Linux + VMWare by croddy · 2004-07-20 06:43 · Score: 1

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 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 your living developing web sites.

zerg by Lord+Omlette · 2004-07-20 06:44 · Score: 1

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.

--
[o]_O

What I test on... by TaraByte · 2004-07-20 06:44 · Score: 1

I test on Firefox on Windows and Mac, and IE6 on PC. I don't bother with Opera, but if it works in IE6 and works in Firefox, it covers a large enough % of the world to not really need to hassle with any of the other browsers. Sure, some people still use IE4 and NS4. If my sites don't work in those browsers, no real loss because they don't signify a large enough percentage to matter. If someone using such a browser complains, I send them download links to newer versions.

--
Security is inversely proportional to the commitment of one desiring to circumvent it.

standards by syrinx · 2004-07-20 06:51 · Score: 1

I basically follow the standards, testing on Firewhatever. At intervals, I'll test on IE. If there's a discrepency, I'll use Opera and/or borrow a Mac and use Safari.

If it works in both Gecko and MSHTML, it's probably fine, I've found. If it doesn't work in one of those, I use Opera or KHTML to find where the problem is. 99% of the time it's with MSHTML and IE.

--
Quidquid latine dictum sit, altum sonatur.

You need a Mac by JimDabell · 2004-07-20 06:55 · Score: 3, Informative

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 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.

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.

Linux live distro CDs? by Abraxis · 2004-07-20 07:00 · Score: 1

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 and test with Konqueror. As long as your PC hardware isn't too funky, this should be relatively painless.

Re:Linux live distro CDs? by Anonymous Coward · 2004-07-20 10:24 · Score: 0

There are Linux live CDs for Mac hardware too.

Linux, WINE, and WWW::Mechanize by markjugg · 2004-07-20 07:01 · Score: 3, Informative

Most of the web pages I develop are database driven. I use the WWW::Mechanize 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.

Re:Linux, WINE, and WWW::Mechanize by Anonymous Coward · 2004-07-20 07:17 · Score: 0

To manually test websites, I run Linux on my desktop. This allows me to test Windows/IE via WINE

If you find a bug, how do you know if it's a bug in IE or a bug in WINE?

Submit it to Slashdot ... by cybermage · 2004-07-20 07:12 · Score: 1

under a pseudonym, of course. If it survives a /.ing it must be fine. :)

--
Some people have a way with words, and some people, um, thingy.

Just save yourself the trouble and get a Mac. by tweder · 2004-07-20 07:13 · Score: 5, Informative

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.

Re:Just save yourself the trouble and get a Mac. by AlexMax2742 · 2004-07-22 03:18 · Score: 1

What about us Opera zealots. :(
But yeah, my co-worker does a bunch of the stuff you are describing, except he has a physical windows PC a few feet from his G5 with IE 5.0, and Opera. He has all the bases that you have described covered (except text-based), and if he needs something tested in Konqurer or something similar he asks me.

--
I'm the guy with the unpopular opinion
Re:Just save yourself the trouble and get a Mac. by AlexMax2742 · 2004-07-22 03:27 · Score: 1

Whoops, forgot that Safari and Konqurer usre the same engine. :)

--
I'm the guy with the unpopular opinion

Reduce the NEED for testing... by Dr.Dubious+DDQ · 2004-07-20 07:15 · Score: 2, Insightful

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 (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...)

--
Hacker Public Radio is our Friend

Re:Reduce the NEED for testing... by Skater · 2004-07-20 08:18 · Score: 1

I used that article (to get started; I had to look up some stuff on other sites) last weekend to convert my site's home page to use CSS instead of just HTML. The new page is at http://roller-skate.org/new, while the old is at http://roller-skate.org. I'm still working out some issues, but I can't recommend that article enough if you're just starting out with CSS and trying to understand how to set up everything.

--RJ

Multiple boxen available by dacarr · 2004-07-20 07:34 · Score: 1

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 - rendering text browsers (lynx, links) useless. (Most recent implementation I brought in for another site was Gallery, but the people who make that seem to be pretty sensible - I mean, hell, it puts out code for Netscape for OS/2.)

So after all is said and done, I don't test my code anymore because as a general rule, if it rendered for the last version of $browser correctly, it'll do the same this time, and if it rendered slightly weird, it might continue to do so. And since most of my stuff is simple stuff like tables (the most complex thing in my code tends to be the color implementations for a cell on a table), unless you've screwed with your browser's colors, it'll all come out the same tomorrow if I cruft up another page.

--
This sig no verb.

Windows IE compatability by zpiderz · 2004-07-20 07:45 · Score: 1

I've been working on a new layout for the website at work. The entire office uses Macs, so it's difficult to test on a Windows machine. The only Windows machines are down the hall in a windowless room!

After the last few months, my experience is that Windows IE is the hardest browser to satisfy. The content could look good in every other browser (Safari, MacIE, mozilla, netscape, etc.) but look like complete shit in Windows IE. And don't even get me started about them not having decent png support.

Worry more about making it look nice in IE. I would go home and check the site with mozilla and it looked fine every time.

Re:Windows IE compatability by Disti · 2004-07-20 11:10 · Score: 1

PNG support. That can be real funny sometimes. I created (unintentionally though) a page that is displayed fine with Firefox, Safari, Opera, Mac IE. The fun thing is that it's completely blank with Windows IE 6.0. (A bit of transparency everywhere on the page did that..)

So now I'm either have to think that no IE user will use the site (yeah, you know it - not an option). Or just duplicate that page as many times as required and "render" it with different background-colors. So it takes n-times the bandwidth.

(Yeah, I've tried pngbehavior. It not only crashed some older IE, but doesn't work at all with css backgrounds and stuff).

Only 2 solutions to this problem:
1. Create a worm to install Firefox with IE-theme.
2. Create ActiveX-object to render pages with Firefox.. And a worm to install that on IE.
Re:Windows IE compatability by zpiderz · 2004-07-21 01:45 · Score: 1

To solve my PNG support problem I had to have some javascript do a browser check and load a gif version if it was Windows IE. I've noticed that Windows IE doesn't support transparent PNGs but it can handle most other simpler PNGs. A quick Google search should give you more specific compatability details.
Re:Windows IE compatability by Disti · 2004-07-22 08:12 · Score: 1

Problem with gif files is that you can't have real alpha, only one color indexed to full transparency. There's only a few areas on my site that are fully opaque so most elements are influenced by background color. That's the reason I really would be glad not to use gif format. Google isn't really the answer for everything. =D

A couple more options by hether · 2004-07-20 08:14 · Score: 1

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.

--

Most people would die sooner than think; in fact, they do.

need testing? by Glog · 2004-07-20 08:22 · Score: 1

Post the links on Slashdot and a swarm of monkeys will proceed to bang on your server...

Forget web standards by phildog · 2004-07-20 08:24 · Score: 2, Interesting

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 :-)

--
slashsearch.org - slashdot search. powered by google.

Re:Forget web standards by Anonymous Coward · 2004-07-20 09:20 · Score: 0

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.

The "big boys" can afford large testing labs and can rely on their branding to get by. Average web developers don't have that luxury.
Re:Forget web standards by chaotic_synergy · 2004-07-20 11:08 · Score: 1

Wow, I so agree with you.
I work for a professional association, and our websites have to work with everybody's ancient netscape 4 installation. And they have to look GOOD in Netscape 4. I don't have to to spend hours getting css positioning to work in every browser.
All content gets saved in a database in a basic non-tables format (tables are used very occassionally for content that needs a more formatted layout). That content is then retrieved into a good old ugly tables template. CSS is only used for font information (colour, face, size, etc, etc).
For anything fancy, I use server-side scripting if possible, javascript for the most basic client side stuff(ie mouse-overs for menu icons), and flash for anything else client based.
Flash only gets used for extra utilities that that the average visitor won't need (online audio presentations, etc). Flash apps work almost anywhere, as long as the user has a plugin installed.
For platforms where tables don't work, I plan on creating separate non-table non-css-positioning templates. More and more pple are using palms and blackberries to access information so it'll be nice to cater to those needs.
IMHO using css-positioning to meet all browser needs is an exercise in frustration. Any advantages css would give me at this point are miniscule compared to the drawbacks. Yes I guess I would save some bandwidth ... but we're a small organization so our bandwidth charges are very very small.
And I agree with what a couple posters have said ... using your stats to decide whether to support a certain browser is kind of silly. Of course pple using that browser aren't going to visit if you've made the experience difficult for them.
One final thought ... if you were running a retail store in the mall would you randomly prevent 5% of your visitors from entering the store? If you're running a business, traffic is money. Don't turn it down.
Re:Forget web standards by chaotic_synergy · 2004-07-20 11:10 · Score: 1

The point is that anybody can visit google and use their site. They are creating basic websites that work in any browser. The rest of us should take heed.

Validators and Load Generators by MichaelCrawford · 2004-07-20 09:01 · Score: 2, Informative

Enjoy my article:

Use Validators and Load Generators to Test Your Web Applications

It is released under the GNU Free Documentation License.

--
Request your free CD of my piano music.

Have you noticed discrepancies on how a specific e by josepha48 · 2004-07-20 09:33 · Score: 1

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 things like window.innerWidth, document.all vs document.getElementbyId, etc. Do you need to access the DOM? If you can avoid then you can support more browser.

In my case I am working on a web based applicaiton but I can dictate what the requirements are. SO I have dictated IE 6 NS 7.1. There are some pages out there, start with devedge.netscape.com that talk about what browser support what stuff, and then go from there. Also think about using or creating a client side OR server side browser sniffer to get the useragent string and do some mojo based on that.

--

Only 'flamers' flame!
Does slashdot hate my posts?

3 Browsers by pabtro · 2004-07-20 10:33 · Score: 1

We test on:

Internet Explorer
Mozilla and siblings
Opera

For us this works very well.

Re:3 Browsers by Anonymous Coward · 2004-07-22 00:31 · Score: 0

I wouldn't exactly call that "three browsers". Internet Explorer 5.x and 6.x in quirks mode (Windows) gives different results to Internet Explorer 6.0 in strict mode. Internet Explorer on the Mac is a completely different browser, with absolutely no code in common.

There are a number of important differences between various versions of Mozilla and Netscape (e.g. CSS not served as text/css and the disappearing <label>s bug), so you need to test in multiple versions of those as well.

IE is no one's friend by Dracos · 2004-07-20 10:36 · Score: 2, Insightful

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.

Re:IE is no one's friend by Anonymous Coward · 2004-07-20 13:17 · Score: 1, Interesting

"And stop using dreamweaver."

I heartily agree. Dreamweaver may be the best WYSIWYG tool for old-fashioned table layouts, but it's useless when it comes to XHTML, CSS, and general web standards.

Designing your first layout with XHTML and CSS is a bit of a challenge, but it gets easy after that. I've discovered it's now easier to use a text editor than Dreamweaver; my code is lean and simple, and much easier for the developers I work with to plug their server-side code into.

Dreamweaver's time has come and gone. It's a useless tool until Macromedia chooses to turn it into an XHTML editor. Who knows when that'll be.
Re:IE is no one's friend by elemental23 · 2004-07-21 05:19 · Score: 1

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 like my women like my coffee... pale and bitter.
Re:IE is no one's friend by hsoft · 2004-07-23 02:10 · Score: 1

There is a lot more than DW and Notepad in source editing. I personally use Crimson Editor (Free, http://www.crimsoneditor.com/) for my XML/XSLT/XHTML/CSS edition, and the highlighting is mostly flawlessly.

wysiwyg is for wannabe.

--
perception is reality

Know your stuff by sboyle · 2004-07-20 10:50 · Score: 1

You can get by with one machine.

Get a Mac G4, max out the disk and memory, install Virtual PC, make disk images of the default versions of each MS OS, back them up, because you'll be referring to them and testing different versions of browsers, OS, plug-ins, etc. on them.

On OS X, you'll get Safari, MS IE, Mozilla, Opera, etc.

You can put linux on Virtual PC, or dual boot the mac, but you can install Gnome & KDE under fink, and Mozilla is cross-platform.

Code your pages to the standards and learn where each browser has bugs. It's a lot easier to code a workaround to something where you know you're dealing with a specific bug than it is to emulate broken behaviour in a working browser.

Visit http://www.positioniseverything.net/

Read up on the browser specific stylesheet hacks.

Only use them as a last resort.

If you're browser detecting, or mandating a browser based on what you think you know about it, then you've missed the points.

People will update browsers. Eventually your pages will be used on browsers that haven't been invented yet.

All your clients will care about is that their site isn't working.

Validator by the+eric+conspiracy · 2004-07-20 11:39 · Score: 1

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.

Emulators and simulators by Guspaz · 2004-07-20 16:31 · Score: 1

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.

Re:Emulators and simulators by Guspaz · 2004-07-20 16:39 · Score: 1

Screenshot of IE5/mac running on PearPC (Under Linux, but PearPC runs on Windows too):

http://pearpc.sourceforge.net/screenshots/macosx _b luegnu.jpg

Test With IE 5, FireFox, and For Kicks, NetScape by NoelWeb · 2004-07-20 16:32 · Score: 0

Testing with these 3 will cover 96% of your sites visitors. Testing on a Mac is always a good idea. For large sites, expecting large audiences, you may want to go further. As a web developer, I test with these 3, and that's it. Some people go to great lengths when testing, and all I can say is "you're lucky to have the time and budget to do all that." My personal "bread & butter" comes from $500 web sites that I build in a day or so. I am not going to add another 6 hours of testing to ensure broad-reaching compatibility. Besides, adding links to popular browsers and listing recommended viewing sizes gets you out of trouble.

Wish I could by Roguelazer · 2004-07-20 16:51 · Score: 1

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...).

--
My Systems

Re:Wish I could by PeterPumpkin · 2004-07-21 05:39 · Score: 1

If anyone knows how to make IE5/Mac recognize "background:#ff0000" applied to div's...

have you tried
DIV { background-color:red; }
?

Test with different *settings*, not just browsers by jonadab · 2004-07-20 17:12 · Score: 1

It's important to test at different resolutions, test on systems where the
default colors are set different from what you usually use, test with various
browser settings changed, and so on. This is all at least as important as
testing on multiple browsers.

Oh, and run it through validator.w3.org.

If you do all that, plus view it in MSIE, Gecko, and lynx, you should
be doing pretty well.

--
Cut that out, or I will ship you to Norilsk in a box.

from awstats by realkiwi · 2004-07-20 20:33 · Score: 1

Msie 5.23 No 44 0.2 %
Msie 5.22 No 88 0.5 %
Msie 5.21 No 4 0 %
Msie 5.17 No 36 0.2 %
Msie 5.16 No 20 0.1 %
Msie 5.15 No 1 0 %
Msie 5.14 No 28 0.1 %
Msie 5.13 No 5 0 %
Msie 5.01 No 404 2.5 %
Msie 5.00 No 1 0 %
Msie 5.0 No 484 3 %

Your Macs are the 5.22 od 5.23 from memory that is a whole 0.7%. People who complain that it doesn't work in IE Mac are invited to upgrade to Mozilla (for free...) and those who do always say thankyou. They keep IE Mac for those pages that don't render in Mozilla.

--
realkiwi

Re:from awstats by realkiwi · 2004-07-20 20:36 · Score: 1

fsck the coment filter that was a table

--
realkiwi
Re:from awstats by Anonymous Coward · 2004-07-22 00:35 · Score: 0

Ever thought that you get so few Mac IE visitors because you are so unfriendly towards them?

easy... by alex_ware · 2004-07-20 21:31 · Score: 1

just write good valid code and include workarounds for i.e.... if it validates its ok with me

--
If you have nothing useful to say post as AC.

My methods by TiggsPanther · 2004-07-20 23:17 · Score: 1

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 perfectly under both, or perfectly under Mozilla and fails nicely (i.e. "I can still read the content") under IE.

I then tend to shell into my older Linux box to test under Lynx and Links. The latter allows me to check for formatted plain text, and the former to make sure that even with minimal formatting (no tables or whatever) it's still easy enough to read and navigate.
I also will plug the laptop in and check IE (and now Firefox) on that. My main monitor runs at 1280 but the laptop is at 1024, so I can check that anything that looks fine at my resolution also still works at lower ones.

Next stage is dual-boot over to Linux. Just to make sure that whatever mozilla variant I'm using still renders the site corrently under Linux. Also to make sure that the "if all else fails" fonts (default "serif" and "sans-serif") still produce a readable page.
I should probably check it under stuff like Konqueror at this point.

I don't use Opera myself, but the first thing I do when I put my site live is to get my friend who runs Opera to see how it works on his.
I was never personally impressed by using Opera, so I've no real desire to install it on my own computer for what's basically a spare-time website. Though were I doing professional sites this would not be the case.

For personal curiosity's sake, whenever I'm online elsewhere I do have a look at how my site looks under different setups. Especially those who still insist on using 800x600.

--
Tiggs
"120 chars should be enough for everyone..."

Code To The Standard: IE, that is... by Anonymous Coward · 2004-07-21 00:42 · Score: 0

Keep in mind that even after all the noise about security, IE is still 95% of the browser market. If you spend more than an hour on penny-ante browsers, you're wasting your employer's money.

Re:Code To The Standard: IE, that is... by Anonymous Coward · 2004-07-21 02:20 · Score: 0

IE is not the standard. IE is becoming a dead product. Even the government says so. Until we get diversified browsers, hackers/crackers will stop coding malicious software just for IE, and unlike Microsoft, patching systems will happen so fast it's not worth hacking it. I'll stick with others and say that web standards are the way to go, regarless if IE supports them.

This is partly why I use a Mac by log0n · 2004-07-21 04:05 · Score: 1

I do all of my web work on a Mac for a variety of reasons, but the most relevant one is ease of testing. I've got Safari (primary browser) and Mozilla and Camino. I boot Virtual PC to windows 2000 and I've got IE6 and Firefox. I boot Virtual PC to windows 98 (most of the system I work for is still on 98SE) and I've got IE5.something. If/when people come to be with problems on Linux browsers, I'll get create a new Virtual PC linux disk. Best of all worlds all on a Powerbook 17.

My List by jc103 · 2004-07-21 06:05 · Score: 1

We test using the following on web apps:

Target browsers for intranet apps (even though we use standards as much as practically possible)
W3C validators for HTML, CSS, and Links
Validators within WebSphere Studio (Java, JSP, HTML), HomeSite (HTML) and TopStyle (CSS)
JavaScript Console and Debugger in Mozilla/Firefox
JUnit
Cactus
People. The users. The project owners. Us. Other web developers on e-mail lists.
We aren't currently using an automated tool to test the front-end flow, because we haven't found any good, easy-to-use, and cheap tools that support a modern version of DOM/JavaScript usage. If you know of something that you like and works, I'd love to know about it. I've tried httpUnit, but had trouble setting it up and it didn't support all the DOM methods we were using at the time.

--

--
Have you read the Moderation Guidelines Addendum

cheap old Macs by tverbeek · 2004-07-21 07:22 · Score: 1

You can pick up an early iMac or late beige G3, capable of running OS X nicely, for very little money. It might need a RAM upgrade, but they use the same sticks as old PCs of the same speed, so that's not going to cost you much. With the help of XPostFacto, you can even get some of the "unsupported" pre-G3 models to run OS X well enough for web-site testing purposes. Personally, I'd suggest spending a little more to get a used 12" G3 iBook (going for roughly $1/MHz on eBay), and get a swell little notebook in the process.

--
http://alternatives.rzero.com/

[lack of] control over the user experience by Anonymous Coward · 2004-07-21 07:47 · Score: 0

If you want control the user experience, then you have to use a well-defined format like images, movies or a proprietary executables, period. Remember: HTML is a just a data format, as opposed to a programming language. There is no such thing as a standard browser, so you cannot define the correct rendering of a particular document. In fact, the stanard permits users to ignore all of your formatting and meta-data if they want. That includes text size/color, images, sounds, style sheets, javascript, flash animations, etc.

Back the the idea of images and movies: For a given image, there is only one valid interpretation of the data. If you don't have a standards compliant gif decoder, you're not going to see the image. The same goes for movies. However, HTML documents have a nearly infinite number of valid interpretations. Therefore, you have two choices:

Don't use content with more than one valid interpretation.
Don't worry if someone else's browser/settings produce undesirable results.

Don't get me wrong. I'm all for letting people render data however they want. However, I'm realistic enough to understand that the price of letting people choose how to render data is to lose control over what they see.

This goes both ways. If I want you to be able to choose how to display something, I can present the data in a [compact] open format. That saves me bandwith, processing time and review time. However, if I want you to see exactly what I want, then I have to go the extra step and pre-render the data and encode it in an unambiguous format. This costs me time and money, but it gives me control over what you see.

Consider a seemingly unrelated problem: in first person shooters, having an open format allows users to customize their clients. However, this also enables people to cheat by doing wall-hacks, auto-aiming, teleportation, etc. If I want you to see a fuzzy outline of 'something', then I have to control the rendering process -- either by pre-rendering or by having an proprietary rendering engine on your system. Otherwise, you can just remove the 'option' that encourages a blurred rendering. The same goes for browsers.

Re: [continued] by Anonymous Coward · 2004-07-21 08:15 · Score: 0

Either you accept the fact that HTML isn't designed to do rich presentation, or you don't.

If you don't, then you're likely to spend a lot of money paying people to test your content on every platform in existence. And that's likely to exceed the cost of rendering and delivering the data in an unambiguous format; plus, you're still going to end up failing to support someone's browser/configuration. It's a lose-lose situation.

I can hear the screams now: "But what about the people who can't or don't want to use a closed format?" I hate to say it, but you were going to lose those people anyway (in the sense of controlling what we see). If you want us to see your content, give it to us in HTML. We'll worry about how it looks. What you intend and what we eventually see are going to be two radically different things; I can guarantee that.

Just one word by osho_gg · 2004-07-21 08:25 · Score: 1

Vmware.. .. http://www.vmware.com/ It is worth the coast of a few hundred dollars so you do not have to buy machines causing thousands. Vmware works really well if you only occasionally use the other OSes (like running konqueror/mozilla/safari etc.) Osho PS; NO, I am not affiliated with vmware in any ways.

Use the standards by Anonymous Coward · 2004-07-21 09:15 · Score: 0

I write to the W3 standards whenever I do a project. My level of irritation over f*ckware (read: Microsoft) and poor rendering determines how much phlegm I add to my pages so they render in non-standards compliant browsers (read: IE).

The fastest way to maintain the crappy software as it is now (read: IE), is to engineer in all the workarounds, tweaks, and eliminate anything above CSS version .01, sarcasm intended.

The fastest way to get software fixed from any vendor, is to make a site that people want to visit utilizing standards. Open source projects such as Moz will quickly fix very visible bugs. If IE authors ignore fixing their piles of dookie, then people with either gripe about it and accept it, or use a browser that works.

Do you want to sit here and bitch for years to come about the state of things and keep doing work-a-rounds, or do you want software authors to do things the right way and support the STANDARDS?

I use the W3 standards, for personal or corporate sites. I try very hard not to deviate from them just to allow a crappy browser to view my sites.

I'm sick and tired of the "don't use the standards if you want a website people can see" argument. F*ck the broken browsers, get a browser that works or stay in the manure pile of software and crappy websites. Ever notice how "standards" websites usually look better for ALL browsers than the websites that look great for IE and usually are really broken for all other browsers?

Blu3

Testing with Linux by Savet+Hegar · 2004-07-21 11:58 · Score: 1

While it doesn't help with testing sites with a Mac, you can use a live Linux cd such as Knoppix for konqueror and firefox testing. Firefox has a windows port though...so I guess the only benefit is for testing with Konqueror.

--
Mod points are pointless when you browse at -1.

Re:When are we going to get some challenging Ask / by Pieroxy · 2004-07-21 13:03 · Score: 1

While the second link you provide is a great resource, the first one isn't really answering the question. First it's not free, so I might as well buy a second HDD and install a Linux. Second it doesn't allow you to scroll down to see the entire pages. Third, you cannot test rollovers and any Javascript you may have.

It is still nice though, but just answers 10% of the question.

Thanks for the links though!

--
Write boring code, not shiny code!

Our IT guys typically use amaya... by riprjak · 2004-07-21 13:40 · Score: 1

...whilst no-one actually BROWSES with it; our standards (we are an ISO compliant automotive supplier, we have standards for EVERYTHING, it is so bloody annoying) require all content to be W3C compliant, so we test it with amaya (www.w3c.org) to verify it looks right on the "reference" platform. All our web content is developed for internal corporate deployment.

That being said, they still often have to run down bugs discovered in IE regularly (we would *love* to switch to png, but as IE cant spell alpha channel, let alone implelent it effectively, we stick with jpg), firefox bugs occasionally and the odd assortment of Epiphany/Safari bugs regularly. Since we use a variety of hardware (depending on need), we tend to fix bugs on the intranet content directly (often by building multiple versions of a page depending on the browser in the end) for expediency, not common sense; since we have a shiteload of web development guys and about 3 blokes who are paid to code/bugfix software.

Our typical desktop now has firefox since the Sysadmin finally spat the dummy with lUsers clicking on all kinds of crap. We are slowly deploying firefox across ALL OS's within the organisation to simplify life.

In summary, firefox seems to have the LEAST problems with web content not appearing as expected; but it still doesn't render everything exactly as the standards would have you believe they should appear.

course, I meandered around the point there...
err!
jak.

Re:Our IT guys typically use amaya... by Anonymous Coward · 2004-07-22 00:38 · Score: 0

our standards (we are an ISO compliant automotive supplier, we have standards for EVERYTHING, it is so bloody annoying) require all content to be W3C compliant, so we test it with amaya (www.w3c.org) to verify it looks right on the "reference" platform.

Amaya isn't a reference platform, it's a testbed browser for experimental stuff. It doesn't support the current recommendations very well at all (floats were only added recently, for example). It's certainly not a baseline browser for "standards".

as IE cant spell alpha channel, let alone implelent it effectively, we stick with jpg

Huh? JPEG doesn't have an alpha channel either. PNG at least has binary transparancy (totally opaque or totally transparent) in Internet Explorer.

You can run multiple versions of IE on Windows by noblethrasher · 2004-07-21 21:31 · Score: 1

I'm not sure if this was already mentioned, but it's possible to run multiple versions of IE on Windows. Check out this site for instructions: http://www.insert-title.com/web_design/?page=artic les/dev/multi_IE

I'm running IE 4.01, 5, 5.5, and 6 on one XP box as well as Netscape (4, 6 and 7), Opera 7, and Firefox 0.x

Re:Have you noticed discrepancies on how a specifi by JimDabell · 2004-07-22 00:26 · Score: 1

Gecko based browser don't seem to render span width or span height tags where IE does.

Do you mean "Gecko-based browsers ignore the width property of inline elements but Internet Explorer doesn't?" It's hard to understand what you mean when you mix up your terminology like that. Gecko is following the specification, Internet Explorer is not:

This property does not apply to non-replaced inline-level elements. The width of a non-replaced inline element's boxes is that of the rendered content within them (before any relative offset of children).

Also think about using or creating a client side OR server side browser sniffer to get the useragent string and do some mojo based on that.

There's no way of getting reliable results from that, as User-Agent headers are routinely spoofed or missing, and Javascript is often switched off by many people.

googlebot... by leuk_he · 2004-07-22 02:21 · Score: 1

Since setting your useragent to "googlebot" will allow you access to more and more sites without logging in this might be the next big browser in the browser wars.

You only needed a mac by Anonymous Coward · 2004-07-22 09:13 · Score: 0

on a mac you could install virtual pc, then test win, linux, and mac all on one. duh!

QTP & Load Runner by Anonymous Coward · 2004-07-22 12:53 · Score: 0

I use QTP and Load Runner. It may be high end but my company gives whatever tools I need to get the job done.

600 lb gorilla indeed by Anonymous Coward · 2004-07-22 13:23 · Score: 0

Most people code to the standards, then tweak each page so the gorilla won't barf on them.

I personally would modify a web site to avoid having a gorilla that big barf on me. Standards or no. RMS might strenuously object -- but I doubt any of us would want to be near him when he does.

Re:Have you noticed discrepancies on how a specifi by josepha48 · 2004-07-27 04:53 · Score: 1

It's hard to understand what you mean when you mix up your terminology like that

Obviously its not that hard to understand what I was talking about, cause you got it. The point was not which browser was right, the point is that they differ.

This property does not apply to non-replaced inline-level elements. The width of a non-replaced inline element's boxes is that of the rendered content within them (before any relative offset of children).

Yes I know, you got this from the spec. To me this is more confusing. What is a non-replaced in line level element?

Lastly if someone comes to a web site and decides to spoof a useragent, then their browser better be able to render the content like the useragent they are spoofing.

However in the dom there are otherways of spoofing out a useragents capabilities. EG:

if ( document.getElementById ) { do your document.getElementByID }

A web browser cant fake that kind of sniffing.

--

Only 'flamers' flame!
Does slashdot hate my posts?

Re:Have you noticed discrepancies on how a specifi by josepha48 · 2004-07-27 05:11 · Score: 1

In CSS1 it does not have this limitation. http://www.w3.org/TR/CSS1#width

It seems to be only CSS2. So I think that the issue is that Gecko based browser are using CSS2 rules and IE is still supporting CSS1 where it does not specfiy this.

--

Only 'flamers' flame!
Does slashdot hate my posts?

Re:Have you noticed discrepancies on how a specifi by JimDabell · 2004-07-27 05:24 · Score: 1

Obviously its not that hard to understand what I was talking about, cause you got it.

Well I had to re-read your post a few times to work it out, and I had to ask to be certain. It's a lot easier to just use the right words in the first place.

The point was not which browser was right, the point is that they differ.

Well the whole point of the specification is to get all the browsers agreeing on what stylesheets mean. If one browser ignores the specification, and the resulting mismatch causes you problems, then the fact that the browser is ignoring the specification is very relevent.

What is a non-replaced in line level element?

The section of the specification I referred you to had links to their definitions.

Lastly if someone comes to a web site and decides to spoof a useragent, then their browser better be able to render the content like the useragent they are spoofing.

You missed off the second part of my sentence, "User-Agent headers are routinely spoofed or missing ".

However in the dom there are otherways of spoofing out a useragents capabilities. EG:

if ( document.getElementById ) { do your document.getElementByID }

A web browser cant fake that kind of sniffing.

Of course, and sniffing a visitor's capabilities is a good technique to use. But your initial response explicitly referred to detecting the user-agent. Those are two different ways of approaching the same problem.

Re:Have you noticed discrepancies on how a specifi by JimDabell · 2004-07-27 05:28 · Score: 1

In CSS1 it does not have this limitation.

Yes it does.

Applies to: block-level and replaced elements

Re:Have you noticed discrepancies on how a specifi by josepha48 · 2004-08-01 14:31 · Score: 1

doh!

So what about div's? Aren't they also replaced elements? Aren't they supposed to allow setting of width and height?

--

Only 'flamers' flame!
Does slashdot hate my posts?

Start with going to w3.org and by josepha48 · 2004-08-01 14:34 · Score: 1

.. use their validator....http://validator.w3.org/

--

Only 'flamers' flame!
Does slashdot hate my posts?

Re:Have you noticed discrepancies on how a specifi by JimDabell · 2004-08-01 21:06 · Score: 1

No, elements are usually block-level elements, so that is why you are able to suggest a width or height for them.

Slashdot Mirror

How Do You Test Your Web Pages?

226 comments