|"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 ;)
|IE never seems to choke on code that is written with accessibility in mind. |
And neither does Netscape.
|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.
>>generally speaking tables do not cause accessibility problems
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.
Dg: you're partly right, I should have been more specific: tables in themselves do not cause accessibility problems, but they can cause accessibility problems when used in certain ways (nested tables that don't linearise in a readable way)
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]
|Tip: Test your table layout in the Opera browser (free version available). It facilitates great user control. Tables can be turned off in File -> Preferences -> Page style. |
Ehm... Not in my browser...
Tables can be turned of from the User Mode drop down (next to the address bar).
|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. |
YES! and instead of trying to "spin" this as some kind of NN7 rules the web thread --interpret the stat for just what it is: 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. and page logging utilities log them all the same way. i haven't seen any stats packages that divide, drop or anything else on non-IE hits. numbers are numbers --and i'm not taking the "enron accounting" approach for interpreting the 98% figure
|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. :)
|If you coded by w3c standards, those people would stay |
Come on, this is a strawman argument.
Can we move on to another topic now? I think we beat this one to death once a month around here.
May be a strawman argument. Nevertheless, it proves true many times :)
|... those people would stay and you'd have a higher percentage of them in your logs. :) |
ummmm ... "where" exactly did i say they aren't staying and they're clicking off? "where" exactly did i say they can't or aren't following my links or can't/aren't viewing my sites? maybe you should go back a few pages and read what browsers i have installed to test with. the discussion was numbers --not your assumption that the numbers you're interested in prove some inability to view a web page because i happen to use IE to do the design and layout of that web page. those numbers show what percentage of surfers are using what browser.
|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.
It's funny how this discussion has crept into a "why we should not use IE for testing" discussion.
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?
Oh, and if it did change and you had a lot of work to do, how many clients would you lose?
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)
So, we still have the argument.
Can anyone give us an example of any W3C validated code that does not work on all IE and NN and Opera browsers?
|Oh, and if it did change and you had a lot of work to do, how many clients would you lose? |
i bet all those Opera and Netscape designers are sure havin' a laugh over that Eolas v/s microsoft decision ...
I've been reading this forum for a while now, and I thought I'd post my opinion.
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 :-)
Im confused.... if Mozilla can interpret and make work bad code better than IE, then why is it that "many sites" work in IE rather than Mozilla.
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"
Therefore IE encourages bad coding?
Is this a good thing? Does C++, Perl, ASP and PHP autocorrect your bad coding? If not, why not?
Does IE4, IE5, IE6 (and future versions) autocorrect your mistakes the same way every time?
P.S. min-width is CSS2, IE does not support CSS2 (partial support only)
The reason is that the designers of those sites used IE when developing them. The sites worked in IE, even though the HTML may not have been valid. The designers didn't check the site in other browsers, for whatever reason.
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.
|Can anyone give us an example of any W3C validated code that does not work on all IE and NN and Opera browsers? |
sure ... i've got some w3c xhtml 1.0 validated that doesn't render worth a crap in NN v4.73 or v4.80.
Does anything render like it should in NN4?
Try some incorrectly nested tables and -- viola -- your whole page is gone ;)
IE3 and IE2 still renders the page correctly though, right? :o
Let's at least stick to browsers newer than 7 years!
PCInk was obviously trying to push some w3c validation agenda and said ALL and included NN. i gave him one.
and you do bring up a good use for netscape v4.x --it is THE best table syntax and layout checker ever made.
That is true... It's one of the pickiest browsers when it comes to tables. Then again, that's perhaps the only good thing about it too :)
It's the same reason why a lot of new houses in Vancouver, Canada are built to be Feng Shui 'compatible' (huge asian population)
There are two types of customers:
1. Those who care about Feng Shui
2. Those who don't give a darn if it's Feng Shui or not.
If you don't develop using Feng Shui, you lose out on the people who care about Feng Shui.
If you do develop using Feng Shui, you lose out on nothing.
Might as well cover all bases no? It's not that tough to write valid code.
| This 125 message thread spans 5 pages: < < 125 ( 1 2 3  5 ) > > |