Welcome to WebmasterWorld Guest from 188.8.131.52
Forum Moderators: incrediBILL
I started with just setting the type to application/xhtml+xml, as it should be, but IE's download dialog could only be qualified as annoying. Why in hell doesn't IE take the MIME if it can, after all, render XHTML?
So I went the hard way and implemented a bit of content negotiation. I made up a simple script to parse the options given in the Accept header, then gracefully degraded:
if client accepts application/xhtml+xml then serve as application/xhtml+xml,
else if client accepts application/xml then serve as application/xml,
else if client accepts text/xml then serve as text/xml,
else if client accepts text/html then serve as text/html,
else HTTP Status code "406 Not Acceptable".
I was a bit worried about IE triggering the "application/xml" case and rendering the pages as generic XML, so I did a test and got... :o 406 :o
Had the script been a bit more complex, I would have considered the chance of having done something wrong and started debugging it, but just a chain of if-elseif's-else doesn't make too much room for errors. I tweaked a bit the last else, to add a Content-type: text/plain and output the contents of the header:
IE7 accepts: "image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/x-ms-application, application/x-ms-xbap, application/vnd.ms-xpsdocument, application/xaml+xml, application/x-silverlight, application/vnd.ms-excel, application/msword, */*". So, is IE7 unable to handle html or even plain text? ¬¬'
Honestly, I think of this as quite insulting: the standard bodies, specially the W3C (of which Microsoft is an active member) make a serious effort to define vendor-neutral, interoperable standards. Most browser developers make a serious effort to comply with these standards. And last but not least, most content authors also put a serious effort to create documents that follow the standards, so users can chose any standards-compliant browser and rest assured they will be able to visit any standards-compliant site. Now, a major vendor with more resources than most of its competitors decides not to follow the standards, and everybody else gets hurt: authors must abstain from using some technologies because they aren't properly supported, and users can't enjoy these technologies even from browsers that do support them, because authors are avoiding them. So these "good" browsers are perceived as equivalent as the non-compliant one, and their developers don't get the recognition they deserve. In summary, IE's disdain towards standards (lets be clear: on some cases it is possible that IE tried to follow some standard, and failed; but in most of them it is quite obvious that no effort has been made on it) feels like a blatant lack of respect towards all the efforts made by the different Web communities (authors, developers, standard bodies, etc).
Let's keep in mind that the Accept header issue is just one among so many; but is a blatant example because it is impossible to send such a wrong header without explicitly wanting to do so.
I do not want to take part on these insulting behaviors, and I really think that the right thing to do (from a normative point of view) would be to simply serve the content as application/xhtml+xml and, if the browser doesn't "accept" it, return a 406 code.
But, of course, that would only hurt the users (and my site as well). If enough authors took a similar approach, users might start migrating to more compliant browsers, thus pressing MS to improve IE's compliance; but most websites (specially bussinesses') can't afford leaving out the 70% of their potential visitors/customers. Even I could afford that (my site produces no income, after all, so less traffic = less bandwith costs), me alone doing that serves no purpose.
So, here is the conflict: I don't want to contribute to IE's insults against the entire Web community; but the only way to achieve that would have the side effect of hurting an average of 70-75% of visitors, and myself; without these visitors understanding what's really happenning.
I would like to know what are other authors' and developers' thoughts on this topic.
Web Design isn't about using the newest features - its about knowing what features you can get away with so that they work for the past 3 versions of any major browser (except FF with their forced automatic updates). It's about working with technology at the rate it is adapted into society.
So while I can appreciate W3C Standards and the whole standardization movement - they are for the future. There needs to be pressure NOW for those changes to take effect - but not at the price of making your websites unaccessible to users. Personally - I comply with standards up to the point that it begins to make my job as a web designer/programmer more difficult.
I do not build separate style sheets for specific browsers and versions (with the exception of IE6 and below for png transperancy) and I will use tables for layout if they are the best solution (I don't care for semantic arguments). I avoid hacks at all cost (filters are ok).
Well, those are my thoughts on the subject
So, two problems: First your content-negotiation Accept-header parser should treat that "*/*" as a fall-through "if none of the preceding, send anything you've got" and second, IE can't handle what you've got...
I'd like to give you an answer, but I'm afraid I don't know it. I got into this problem because people were trying to view my text/xhtml+xml Mobile Profile pages with IE7, and it just displayed the code. So, I detect IE and send it alternate content -- text/html derived (downgraded) from my text/xhtml+xml page by leaving out stuff that's not valid for the HTML DTD.
I hope someone comes along who can offer us both a better solution...
I believe W3C Standards - while ideal - are still 10 to 20 years away from being Real World Standards
My main concern is that it's Microsoft, through IE, who (due to their comfortable market advantage) is keeping actual progress so behind.
There needs to be pressure NOW for those changes to take effect - but not at the price of making your websites unaccessible to users.
I will use tables for layout if they are the best solution (I don't care for semantic arguments)
So as not to lose focus, the "*/*" at the very end of the HTTP-Accept header posted above says the client will accept "anything else."
IE can't handle what you've got
I have done a bit more of testing and, in summary, IE behaves so unconsistently it's impossible to know what the hell is it doing. And such unconsistency must have been coded into the browser explicitly: why the hell does IE behave this way?
So, I detect IE and send it alternate content -- text/html derived (downgraded) from my text/xhtml+xml page by leaving out stuff that's not valid for the HTML DTD.
As a side note, I want to say that I'm quite excited about XHTML 2: it looks really good, and it seems that it will soon go into Last Call, so I'm doing these experiments to get an idea of what to expect from browsers when the new standard is endorsed (in terms of implementation efforts). I would really like be able to create new sites using it (and even migrate some sites to it), and it looks like IE will be the only obstacle.
If we leave IE out of the picture for a moment, then suddenly W3C Standards become outdated compared with Real World (actually, with "Hipotetic non-IE World", but all other major browsers are quite real): XHTML and CSS 2 are quite well supported by all major browsers, being IE the only exception; and the de facto XmlHTTPRequest standard has a quite interesting technology (Ajax) built around it, to the point that the W3C is already working on providing a "standard" for it gathering the implicit consensus among current implementations.
Well, lets consider how things stand - if IE were hypothetically non-existent. First off, while the current versions of the major browsers are pretty good at following standards - they all have their own issues where they don't follow the standards and have problems implementing various css properties. For example - I know FireFox 2 has issues with the page-break-before, after, and inside properties. Hopefully this is fixed in 3 - which I believe is now available for download. Some browsers like FF are good at fixing any issues immediately - of course some they can't and leave to be fixed in future versions - hence we don't tend to notice their flaws as much as IE which comes out with a new browser like every 3 years or so. So while they are better at maintaining standards there are still issues.
But besides this - the real issue isn't whether or not the most current version of these browsers supports standards to the nth degree - its a matter of what browsers and what versions of those browsers are still being used today. Most people don't go around trying to download the latest browsers. Most people use w/e the default browser is that there computer comes with - and most people keep the same computer for 5 to 15 years. So if tommorow all the major browsers released a new version for their browsers which had no bugs and followed standards perfectly, and displayed everything the exact same way - you would still have to program for the older versions, and thus you would still be stuck with the same limitations. True - an immediate release of fully standardized browsers would speed the process up - but being realistic your looking at 10 to 20 years and that's IF all browsers suddenly become compliant.
My main concern is that it's Microsoft, through IE, who (due to their comfortable market advantage) is keeping actual progress so behind.
Again - even if IE suddenly became 100% compliant tomorrow with a new version release (or even if it was a automatic patch for IE 7) it would still take 10 to 20 years for the other older versions of IE and other browsers to die out. And of course - this is just to support the CURRENT technologies and standards. As new technology, new versions of existing technology, and new standards come out - the more issues are going to pop-up regardless of how compliant IE and everyone else is trying to be.
As for IE keeping progress behind - yes they are. But, again, that's why I say we need to program according to Real World Standards, not W3C Standards.
100% agree. So I'm trying to find the way to make pressure without hurting the users. But still, user-awareness is needed, because it is the users who can really make pressure. That's quite a paradox.
True - if all users suddenly decided to not use IE anymore - that would force them to either comply or leave the market. But - most users don't care, only web developers care. And seeings how IE is easily accessible (as it comes pre-installed w/ windows) they aren't likely to go browser shopping. The reason conform is so slow is because IE knows that - and that developers are going to be forced to develop specifically for IE because of that. So realistically you aren't going to get any pressure from users. Rather - its IE placing pressure on developers to develop according to their own private standards. They are losing their grip - but it is a slow process.
I bet you have never need to target an aural browser and visually-impaired users. The last time I had to target such audience, I was volunteering to help on an already-made site, and it relied so deeply on tables and iframes for layout, that we decided to build a specialised, independent site for non-visual browsers.
In general, I find the semantic arguments on this topic interesting, but I value much more the accessibility ones, because they have a direct impact on some users.
Your right - I've never had to develop a site specifically for the visually impaired. Nonetheless - while tables CAN and HAVE been abused in the design process - they can be made just as clean (if not cleaner) than a div alternative and just as accessible. Just look at the Section508.gov website - THEY USE TABLES FOR LAYOUT! As do several other government sites and other accessibility sites (like screenreader.net).
Using the CSS-Div only approach makes a website naturally accessible as it is built up from its degraded form usually. But Tables - with a little effort and foresight - can be made to degrade just as nicely. Its just a matter of good coding.
Well, lets consider how things stand - if IE were hypothetically non-existent. First off, while the current versions of the major browsers are pretty good at following standards - they all have their own issues where they don't follow the standards and have problems implementing various css properties.
Again - even if IE suddenly became 100% compliant tomorrow with a new version release (or even if it was a automatic patch for IE 7) it would still take 10 to 20 years for the other older versions of IE and other browsers to die out.
But - most users don't care, only web developers care. And seeings how IE is easily accessible (as it comes pre-installed w/ windows) they aren't likely to go browser shopping.
Just look at the Section508.gov website - THEY USE TABLES FOR LAYOUT!
A side reflexion: Browser Wars - Episode II
Between August 1995 and August 1996 Microsoft released no less than 3 major versions of the IE browser (versions 1.0 through 3.0). Next version, 4.0, would take an entire year, and was released on September 1997. Version 5.0 took 1 and half years (released on March 1999); 6.0 would take 2 and half years (August 2001); and 7.0 took more than 5 years (October 2006). Not even two years have passed since 7.0, and there is already a beta of IE 8 out there.
Coincidentally (well, this is not a coincidence), it was after IE 4 that IE gained dominance over Netscape; and it was after Firefox started gaining some foothold on the browser market that Microsoft launched IE 7 and kept working hard on improvements for the next (8) version.
Competition is already putting pression on IE, and Microsoft is answering with efforts in improving compliance. I hope that in some months there will be at least 2 or 3 browsers competing with comparable percentage of users; and that the competition will remain fierce for long, thus forcing every competitor to work hard on improving the browsers, which will ultimatelly benefit everybody.
(I don't fully agree on your timespans, but let that aside for now). Ok, you may be right. But in that case, if it takes 10 years before MS releases a IE complying with current standards, then it will take 20 to 30 years for older versions to die out. If there is any way to put some pressure on MS for them to improve IE's compliance ASAP, then we should indeed put that pressure, so we will be able to use these features in 10-20 years rather than 30 or even more.
My guesstimation maybe off - I'm just speaking from personal experience + a little guess work :D. But It would EASILY take 10 to 15 years. And, yes - if possible it would be nice if all of us developers could get together and suddenly only display a degraded version of all pages for IE. However - the fact remains that most of the sites we develop are for clients - and our clients aren't about to make it any more difficult for their clients to access their website. That leaves us with our own personal sites. You could turn em all into gracefully degraded pages and the only ones who would notice would be web developers. Because of this - all pages are going to be made compliant with IE and thus there is no reason for users to switch browsers because they are just going to see the same page anyways!
Placing pressure on IE is more easily said than done. NOW - if you managed to get lots of MAJOR businesses to suddenly stop supporting IE, you might have something. But this would more or less have to be a nation-wide web designer/business movement - and the cost would be the initial loss of sales from people not being able to access your site. Hardly a worthy pursuit for businesses - especially when there are going to be a few out there who refuse to join the movement and thus take up all of the sales.
The only real way to take care of IE would be if everyone would switch their computers to anything but windows (Macs, Linux, etc). However, I personally refuse to do this because Windows - with all of its faults - is my personal favorite. I grew up on it - I know how to use it, doesn't have to many limitations. And, most importantly - IT DOESN'T HAVE A MAC GUI >.< I H8 MAC GUI! Most people are going to continue to buy Windows and thus get IE.
The only reason users don't care is because they don't understand: sites are "downgraded by default" so they render properly on IE, hence users don't see any real difference when using IE or a more compliant browser. That's why I spoke in my previous post about raising user's awareness on the topic; and I feel even more convinced about this now, after having read your reply: I'm indeed going to take the "Downgraded button approach" and put two versions of my sites up: one will target the "Happy non-IE Compliant World" and the other will target the "IE & Old browsers World". And, most of it: on the "explanation" page linked from the "Downgraded for IE" button, I'll make sure to provide several screenshots, showing how the "happy" site renders in compliant browsers (which I'll make sure has a better appeal than the "compatible" site), and how would it be rendered by the last IE version (if "that" can even be called "rendered" :P ). This should help users understand that the main thing that has kept us, authors, from giving them better sites has been IE; but they will still be able to browse the entire site's content. And that is exactly what I mean by "raising user-awareness" ;)
For the most part - IE doesn't really limit the designs you can make. It forces you to code a bit more using hacks and what not - but I haven't see a design which - if you take the time - can't be made to work with IE. Its a major incovenience for web developers - but not for your average viewer. Not to mention most viewers don't care about the layout to much - so long as it isn't butt ugly and so long as you can find stuff easily.
Most users (including me most likely) who see your degraded text only page are going to simply leave the second it loads. Those who stay to read might be somewhat interested - but they to will leave for a site that offers what ever you offer in a nice IE friendly site - of which there are a LOT. You buy yourself will have no impact upon the web. Now, if you can get everyone to do it - and on big commercial sites - you might have something. For example - if you could get Yahoo or Google - you'd make lots of converts immediately. But its those kinds of sites that are going to have the real control over standards - not some random developers site that 99.99% of the public will never see.
ROFL! Do you mean with that that the site is accessible? Just try to "listen" it with an aural-browser, and you will hear the entire list of font types and sizes, and all the navigation links, before you reach any of the contents ¬¬.
Indeed, a site can be made accessible even when using tables for layout. But you have choosen a quite bad example. To put it briefly: if that site added a class="nav" to navigation parts and a class="visual" to the "font selector" part; and then a linked sheet for the appropriate media that simply hides these parts, the site would become much more accessible (and without any need to change the layout offered to visual browsers).
I have used a screen reader on it - and I don't hear any of the font tag stuff. And that's just using the free one at screenreader.net - I'm sure commercial ones would be even better at reading the page. Furthermore, blind users are use to navigating sites and know how to use various shortcuts to navigate the page (like going straight to headers). IMHO - browsing the web will always be a pain for the visually impaired no matter how compliant we are - its made to be seen not read. Furthermore - while they might be able to make it even easier for screen readers, they are fully accessible according to standards.
And, on the issue of tables - your arguments for why the site is less accessible than it could be have nothing to do with tables - showing that tables can be made accessible (and quite easily I might add).
So, IE's lack of support for text/xhtml+xml seems to be purely in the content-type response header handling, and not in the markup language parser or the rendering engine.