Rant: Microsoft madness
in [CSS]
|
From: GTalbot on 7 May 2008 14:29 On 6 mai, 09:38, Andy Dingley <ding...(a)codesmiths.com> wrote: > On 6 May, 13:45, DuncanIdaho <Duncan.Idaho2...(a)googlemail.com> wrote: > > > IE7 is RUBBISH when it comes to css, at least in my experience. > > It's merely "poor" on CSS, only "rubbish" if you ask it to work with > non-conformant HTML & CSS. Mostly it gets it wrong in the areas around > error correction. Code perfectly (which isn't _that_ hard) and you'll > avoid the majority of the problems. Andy, While I really want to agree with you, it must be said that nevertheless IE 7 is really still very buggy (and I mean bugs here, incorrect implementations of CSS 2.1, incorrect implementations of DOM 1 Core, DOM 1 HTML, DOM 2 Core interfaces, even HTML 4.01) when comparing with Firefox 2, Opera 9.50, Safari 3.1.1. I've said about 12 months ago that IE 7 had about 750 bugs in HTML 4, CSS 1 and CSS 2.1 and in DOM 1. Yes, writing valid markup code and valid CSS code will avoid a majority of problems and issues but in a minority of cases, you will still have headaches, nightmares, etc... with IE 7. Worst bugs so far in IE 7: - float implementation - z-index implementation - adjoining margin collapsing - inherit keyword - still many positioning issues - inline box model implementation - negative margins 130 bugs in Internet Explorer 7 (but most likely 750 bugs) http://www.gtalbot.org/BrowserBugsSection/MSIE7Bugs/ Gérard
From: DuncanIdaho on 7 May 2008 14:44 GTalbot wrote: > On 6 mai, 08:45, DuncanIdaho <Duncan.Idaho2...(a)googlemail.com> wrote: > > >> Recently I was given the task of setting up a website from scratch >> including the front end. >> >> I chose Opera(V9.27), Firefox(V2.0.0.n) and Internet Explorer(V7.0) as >> my dev browsers as these were the ones used by the eventual users of the >> site. >> >> What a nightmare. > > > Duncan, > > If you want precise help, contextual help, first make sure your > webpage passes markup validation, also passes CSS validation and then > provide an URL where the problem occurs along with a short, clear > description of the problem. OK, well lots of good advice there and lots of reading to be done but I've already explained elsewhere on this thread why I am unable to post a URL. Actually I never explicitly asked for help, all I wanted to do was have a grizzle about the nonsense that I was experiencing with Microsoft IE 7 call it catharsis if you like. The line of code textanchor.className = nodeType; works in all my browsers seemingly independant of the DOCTYPE declaration, sorry if that offends anyone it's just observation that leads me to this conclusion. HTML DOM, XHTML DOM, FOO DOM whatever, it works regardless and for that I thank all of you who suggested it. This code does however make my code asymetric, as someone who has spent his entire working life using Object Oriented languages this offends me. Finally then, the fact that so many people have taken the time and trouble to explain why IE doesn't work in the way I was expecting (hoping) it would (ie like other browsers) only leads me to believe that my original assertion (slightly more qualified this time) is indeed correct. For me, in my experience, as someone who is working out of his comfort zone, IE 7 is indeed rubbish. However I have no choice but to live with it. Perhaps the developers of this piece of software read this list, at least it appears so from other responses. If so, for gods sake get a grip and get it working like other browsers do, rightly or wrongly it's what the vast majority of people who write for the web want. Idaho
From: DuncanIdaho on 7 May 2008 14:57 GTalbot wrote: > On 6 mai, 08:45, DuncanIdaho <Duncan.Idaho2...(a)googlemail.com> wrote: > > <a class="node" href="javascript:getMenuUpdate('1')">Jewellery</a> > > Duncan, > > To be more thorough, accurate on that issue...: > > "javascript:" links break accessibility and usability of webpages in > every browser. > > * "javascript:" pseudo-links become dysfunctional when javascript > support is disabled or inexistent. Several corporations allow their > employees to surf on the web but under strict security policies: no > javascript enabled, no java, no activeX, no Flash. For various reasons > (security, public access, text browsers, etc..), about 4% to 8% of > users on the web surf with javascript disabled. > * "javascript:" links will interfere with advanced features in tab- > capable browsers: eg. middle-click on links, Ctrl+click on links, tab- > browsing features in extensions, etc. > * "javascript:" links will interfere with the process of indexing > webpages by search engines. > * "javascript:" links interfere with assistive technologies (e.g. > voice browsers) and several web-aware applications (e.g. PDAs and > mobile browsers). > * "javascript:" links also interfere with "mouse gestures" > features implemented in browsers. > * Protocol scheme "javascript:" will be reported as an error by > link validators and link checkers. > > Regards, G�rard All good and valid reasons I'm sure Gerard, however I rather like the idea of making my web site behave more like a desktop application, consequently when I 'discovered' that the XMLHttpRequest class existed in my browser I was absolutely delighted. Are we now saying then that AJAX (to use a common acronym) should not be used to implement a smoother experience for our users ... do I really want to refresh an entire page just because a user selects a different node on my navigation tree or puts something in their cart ? no, not if I can help it. As I'm sure you know if you've read the rest of this thread I'm well out of my comfort zone here. So maybe you can help me out. If I can't use javascript:getMenuUpdate('1') to call a method of mine which in turn instantiates and invokes methods on a javascript component how might I do it otherwise. Thanks in advance Idaho
From: DuncanIdaho on 7 May 2008 14:59 GTalbot wrote: > On 6 mai, 09:38, Andy Dingley <ding...(a)codesmiths.com> wrote: >> On 6 May, 13:45, DuncanIdaho <Duncan.Idaho2...(a)googlemail.com> wrote: >> >>> IE7 is RUBBISH when it comes to css, at least in my experience. >> It's merely "poor" on CSS, only "rubbish" if you ask it to work with >> non-conformant HTML & CSS. Mostly it gets it wrong in the areas around >> error correction. Code perfectly (which isn't _that_ hard) and you'll >> avoid the majority of the problems. > > Andy, > > While I really want to agree with you, it must be said that > nevertheless IE 7 is really still very buggy (and I mean bugs here, > incorrect implementations of CSS 2.1, incorrect implementations of DOM > 1 Core, DOM 1 HTML, DOM 2 Core interfaces, even HTML 4.01) when > comparing with Firefox 2, Opera 9.50, Safari 3.1.1. > > I've said about 12 months ago that IE 7 had about 750 bugs in HTML 4, > CSS 1 and CSS 2.1 and in DOM 1. Yes, writing valid markup code and > valid CSS code will avoid a majority of problems and issues but in a > minority of cases, you will still have headaches, nightmares, etc... > with IE 7. > > Worst bugs so far in IE 7: > - float implementation > - z-index implementation > - adjoining margin collapsing > - inherit keyword > - still many positioning issues > - inline box model implementation > - negative margins > > 130 bugs in Internet Explorer 7 (but most likely 750 bugs) > http://www.gtalbot.org/BrowserBugsSection/MSIE7Bugs/ > > G�rard Can we add 'putting white space under a <form> element'. I mean, what he hell is that about. Idaho
From: GTalbot on 7 May 2008 15:04 On 7 mai, 14:44, DuncanIdaho <Duncan.Idaho2...(a)googlemail.com> wrote: > The line of code > textanchor.className = nodeType; works in all my browsers seemingly > independant of the DOCTYPE declaration, sorry if that offends anyone > it's just observation that leads me to this conclusion. We (a large majority of web developers) have reported buggy support for setAttribute in the past. It will be fixed in IE 8. Already, setAttribute for class attribute has been fixed in IE 8 beta 1; there are event handlers and a few cases still left (reated to table model) to fix for IE 8 final. > Finally then, the fact that so many people have taken the time and > trouble to explain why IE doesn't work in the way I was expecting > (hoping) it would (ie like other browsers) only leads me to believe that > my original assertion (slightly more qualified this time) is indeed > correct. For me, in my experience, as someone who is working out of his > comfort zone, IE 7 is indeed rubbish. Nobody seriously argued on this. The last time I checked the %tage of failure of IE 7 for the CSS 2.1 test suite, Internet Explorer 7 fails 129 tests out of 500 (25.8% failure) while other browsers failed less than 10%. I would have to run the tests again since the testsuite changed a bit and Opera, Safari and Firefox have new releases. Same thing with DOM 1 Core and DOM 1 HTML: IE 7 fails fails 85 tests out of 224 tests, a 37.9% rate failure which is well over/above the percentage rate of Firefox 2 (6.3% failure rate) and Opera 9 (5.1% failure rate). Remember that 25.8% and 37.9% still mean that IE 7 will pass the testsuite for a majority of cases. Same thing with HTML 4.01 tests. http://www.robinlionheart.com/stds/html4/results IE 7: 44; other browsers: 70 and higher > However I have no choice but to > live with it. Perhaps the developers of this piece of software read this > list Do you really think/expect/hope that IE dev. team visit and has been visiting comp.infosystems.www.authoring.stylesheets forum discussion in the last 6 years? Regards, Gérard
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 Prev: Rant: Microsoft madness Next: Help me confirm a bug in IE 8 b1 |