Welcome to WebmasterWorld Guest from 18.104.22.168
Forum Moderators: incrediBILL
Why do people design for IE first? I don't get it!
I view the page in IE, but I sure don't use it as the corner stone of any development.
"this site accessible to anyone"
I've seen that on a couple of sites :) And I actually put that on one of my own a while back.
Yes, accessibility is most important. But don't you think it's easier to write accessible pages using standards compliant code? I've never seen IE choke on accessible pages either. But then again, accessible pages are rarely written using sloppy code ;)
In the Tables vs CSS thread I didn't see accessibility mentioned once
That's because, generally speaking tables do not cause accessibility problems. Don't take my word for it, either investigate for yourself or find Joe Clark's numerous statements on the matter.
...yet I never see, "this site accessible to anyone"
...and that's because it's impossible to have one set of content that's accessible to everyone regardless of what type of disability faced. e.g. folks with different cognitive disabilities may need the content to be written, structured and presented in completely different ways.
You're going to have to take my word for this, but after spending several sessions at several schools for the blind I quickly learned that tables do generally cause accessibility problems. Generally, the blind are surfing with older screen readers. The best ones are quite expensive. Generally. :)
Older screenreaders, however, read across table cells, making text incomprehensible.
I invited several teachers from schools for the blind to participate at WebmasterWorld some time ago but they are pretty busy folks. I also invited several accessibility "gurus" to participate but they're used to being paid for their advice and politely declined.
Spending a bit of time at some institutions that teach the blind certainly made me realize the problems they face.
Oddly enough, IE seemed to be the browser of choice. IE readily accepts some plugins that other browsers struggle with.
Here's Joe Clark's take (he's an "accessibility guru"):
[added: and of course, the UK RNIB site uses layout tables...these folks know more about visually impaired web accessibility than the rest of us put together - take my word for it]
No! It tells you nothing more than that 98% of the page views are IE/Win users. The actual amount of users that are turned away by your malformed page may very well be fairly high, 25% or more.
98% of the raw page views are generated with IE based browsers. none of the links pointing to my pages have any sort of "don't follow this link if your using netscape" warning. netscape users follow the same links the IE users do. they generate the same raw page views as the IE browsers do. same as opera and any other browser.
The problem is, if your site does not work in a non-IE browser, those people leave after going to one or two pages. If you coded by w3c standards, those people would stay and you'd have a higher percentage of them in your logs. :)
... those people would stay and you'd have a higher percentage of them in your logs. :)
98% of the raw page views are generated with IE based browsers
What would be interesting and compelling here would be that number broken down by landing pages vs "internal pages".
If (say) 90% of raw page views for the home page (or other major landing page) are IE while 99% for the links from it are IE, you'll have established a correlation between browser and potential loss of 10% or sales
On the other hand, if 100% of the home page views are IE while 96% of all other pages are IE, that clearly marks a case for a different sort of re-optimization.
But, either way, a site wide figure of raw views is not fine enough analysis to conclude whether remedial work to accommodate non-IE users is needed or not.
I looked at the title of this thread "Funny how people usually blame the non-IE browser" and decided to look at the posts on this forum about things that don't work in particular browsers. Almost every post was "Why does ... not work in Netscape" and "Why does ... not work in Opera". It's interesting to note that many of these posts appear to be using one of two things:
1) Coding errors which IE is forgiving and other browsers are not
2) HTML tags or CSS formatting which are not supported by the W3C or are so new that only some browsers support these tags
There are very few which turn out to be a bug in Netscape or Opera (although it does happen on occasion). The majority seem to be sites designed on IE and then tested on another browser and the website designer seems almost surprised that things don't work.
Even if you do use IE, validation is more important and whichever browser you use, checking out which CSS and HTML tags are supported by which browsers is also very important. I use some CSS which is supported by only some browsers, but it is non-essential (I don't worry why a little decorative dotted line does not appear in the odd browser - it will do in future versions, I am sure).
The problem is when the whole site is non-functional in another browser. Because of the simple nature of HTML (and yes it is very simple) there should be very few reasons why it would not work in other browsers. The main reason is the attitude we have in previous posts, why bother supporting other browsers when IE is the majority?
Well, I go back to a previous post where it was put forward that Opera took 25% of the market share. It is possible. Now, Opera as default disguises itself as Internet Exporer. So, going back through your logs, how many "Internet Explorer" users are actually Opera users? And how many "Internet Explorer" users are actually AOL users? And if AOL changed their rendering engine to something different?
I think it is quite scary how the browser market could change very quickly, particularly if AOL changed their engine. How much work would you have to put in if this happened? And if AOL forced users to change the rendering engine (perhaps even automatically without the user knowing)? This could happen overnight and would scare a lot of webdesigners.
None of this is likely to happen in the near future, but then again we did not expect MSN to drop LookSmart and we did not expect Yahoo to buy Inktomi. Things change quickly... how quickly can you keep up to date?
And who would get the clients? The webmasters who have designed sites to work with other browsers would take plenty of your customers. You could not update them all quickly enough, but those who already have thought about the future would have plenty of time to get new clients whilst you are working all the hours of the week trying to keep your existing clients who will not be happy to pay you to make their sites work in a browser that they should have worked on in the first place. Unless your contracts specifically state that the site would only work in IE. I bet most contracts do not mention that.
"So you will build a parking garage for the Toyoda Camay but if someone comes by driving a BMW, Ford Escort or Chevy, then they are SOL? That is essentially what you are saying, and it is just as ridicules."
I think the analogy you have is just a little off. Build your garage with roof clearance for normal cars and trucks, and loose the bus and monster truck business. Too bad those vehicles can't adapt and use the garage.
If I was on a browser design team, I'd want my browser to be able to interpret bad code as well as possible because its about layman computer users being able to view pages, not html writers and browser coders imposing themselves upon the mistakes of a website coder. It is the user that is screwed in that example.... and bad code is just reality. People are not perfect, standards are hard to follow without deviation.
TV's are made to deal with bad/weak signals as well as possible, radios are, etc. Why, because people dont care that a bad signal is coming in.... they just want to watch TV.
I am glad that my brain can do this as well, or instead of knowing that you were talking about a "TOYOTA CAMRY" and really meant "REDICULOUS". But for my own error processing and correction, I'd have no idea what your post said.... It just wouldn't have been langauge/html compatible, and would have thrown all sorts of errors! I, like IE, interpret bad code as best we can, to the benefit of the end user.
(btw, I understand there are foreign speakers here, typos, etc, this is in no way an attack on my fellow poster, just an example)
deft_spyder: the problem isn't that Mozilla can't interpret bad HTML - arguably it does a better job than IE. It's just that many sites are written in bad HTML that *happens to work* in IE, rather than bad HTML that *happens to work* in, say, Mozilla. Or, preferably, valid HTML that works in all browsers.
PCInk: There's plenty of CSS stuff that just won't work in IE. Admittedly there are sometimes workarounds, and good pages should degrade gracefully...
(As an aside, if IE supported the max-width and min-width attributes I would be a very happy bunny :-) )
IMO the two-and-a-half year old IE is *the* reason that web standards aren't universal, especially on big sites like Amazon. NN4 isn't a reason anymore - that small percentage of users are used to seeing websites a little differently to the rest of us :-)
That seems contradicting.
My point still remains that IE makes more code work more often than it's competitors.
I swear they should put it right on the box: "Our browser renders correctly more bad, old, deprecated, wacky, stupid, experimental, "cutting edge" code than our rivals so YOU see the page instead of the error"
If those designers had used Mozilla, then more sites would look better in Mozilla. Ditto Opera, Konqueror, Acme Browser, or whatever.
My point: If a website looks better in IE, it's written in an IE-flavoured version of bad HTML.
You're right that IE makes more sites look better, but only on sites that aren't well written.
Here is an example where IE does not work properly:
IE does not interpret absolute positioning using CSS properly. Case in point:
You can not highlight anything on my page when browsing with IE, but its fine in all other browsers. Here is an 'expert' article on just that matter- www-level3.experts-exchange.com/Web/Web_Languages/CSS/Q_20767525.html#9556723
Here's some good news! The number of people using IE to visit me has dropped!
IE visitors= 58%
MOZILLA visitors= 32%
-- YAY MOZILLA!
My point still remains that IE makes more code work more often than it's competitors.
Which is precisely why it is good to either thoroughly test the site in non-IE or to develop it under stricter conditions.
And it's not just IE's competitors you need to worry about....
Example: do you know the three common HTML errors that will cause Googlebot to miss content on a page?
They've all been mentioned in previous WebmasterWorld threads. Not one of them is detectable from a glance at IE's rendering. IE makes the code work: not want you want in this case, unless you don't want to be googlebotted.
IE makes more code work more often than it's competitors
Say that I live in the state XYZ and want to build a house. XYZ has just some general 'guidelines' you should follow, but they are not enforced. Now, I get two bids. The first contractor tells me that I can get a really nice house without worrying about the guidelines. "As long as it's a house you can live in, eh?" The second contract tells me that he follows all of XYZ's guidelines. Not only that, he follows those of MNO as well, even though they don't apply to my XYZ state (yet). Upon completing the building of my house, he will also get it tested to make sure it really follows all the guidelines.
My first thought would, of course, be that the second contractor is going to be much more expensive. But, if those were my only two options -- I'd still go for the second one! Of course, Web pages aren't as important as a house. But that second "contractor" is still the better option. Not only will it make your Web site look (and function) better -- it's not any more expensive to produce!
So, what's the difference between the first and the second contractor when it comes to Web pages?
Experience, knowledge, professionalism.