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
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.
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.
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.
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.
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.
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.
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.
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.
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:
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.
They've never said that you cannot redistribute the pre-release versions, but that if you do, you've basically forked the code and it's your release now. You provide all support and further maintainance on it and you forfeit your subscription to future prerelease versions.
When they say "if you redistribute this code, your subscription is cancelled", they are placing an additional restriction upon redistribution, and thus violating section 6 of the GPL:
6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License.
That seems like a straightforward violation to me.
None of this I have a problem with. It's an unreleased version of the code; they shouldn't be expected to support it. If one of my beta testers leaks my code to the internet, I'm certainly not going to be sympathetic if someone downloads it and has problems with it and calls my tech support for help. Why should Sveasoft?
Huh? People aren't complaining that Sveasoft aren't supporting prerelease software. They have every right to tell people using it to go to hell. But they don't have the right to prevent people from distributing it.
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.
>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.
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?
>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?
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.
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?
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.
RSS already supports the <ttl> element type, which indicates how long a client should wait before looking for an update. Additionally, HTTP servers can provide this information through the Expires header.
Furthermore, well-behaved clients issue a "conditional GET" that only requests the file if it has been updated, which cuts back on bandwidth quite a bit, as only a short response saying it hasn't been updated is necessary in most cases.
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.
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.
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.
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.
Slashdot Mirror
Then I'm sure Microsoft will deal with them for us...
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.
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.
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?
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 it's "entirely" true, except when it isn't? ;)
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.
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.
Sorry, Lynx doesn't render HTML properly either.
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.
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.
That's because I'm not arguing that you shouldn't. Is English your first language (honest question)?
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?
I never said that either.
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.
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.
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!
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 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.
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?
Once more, you are putting words in my mouth. I never said that.
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?
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.
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.
To ensure it works correctly for the most people possible.
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.
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 would people deliberately shut out the majority of their visitors?
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.
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.
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.
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.
There are unreliable ways of detecting the browser type. If you've found a way that is reliable, then by all means, enlighten me.
At no point have I advocated writing code that is incompatible with the specifications. Please point out where you think I did.
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.
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?
"A good job" isn't good enough. It only takes a single bug to render a page unreadable. Your exact words were:
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.
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:
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.
When they say "if you redistribute this code, your subscription is cancelled", they are placing an additional restriction upon redistribution, and thus violating section 6 of the GPL:
That seems like a straightforward violation to me.
Huh? People aren't complaining that Sveasoft aren't supporting prerelease software. They have every right to tell people using it to go to hell. But they don't have the right to prevent people from distributing it.
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.
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.
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 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?
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 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.
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.
I've never said otherwise. In fact, that's exactly why I said "Browsers have bugs. You can deal with that by testing..."
"...or you can stick your head in the sand."
Exactly which browsers do you think render HTML 4.0 properly?
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?
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.
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?
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.
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.
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.
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.
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.
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?
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.
RSS already supports the <ttl> element type, which indicates how long a client should wait before looking for an update. Additionally, HTTP servers can provide this information through the Expires header.
Furthermore, well-behaved clients issue a "conditional GET" that only requests the file if it has been updated, which cuts back on bandwidth quite a bit, as only a short response saying it hasn't been updated is necessary in most cases.
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.
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"?
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.
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.
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.