On 01 Jul 2001 22:44:08 +0200, infos wrote:

...

I just started playing Anarchy Online (a new online massively multiplayer game), and when visiting their community site (http://community.anarchy-online.com) I noticed some distinctive URLs :^)

--- a little off-topic, but this web site is truly bad in design. whoever designed this website is one of those people who try to shut out those whose web browser does not fit into his little world of thinking and all i got was some dumb page asking me to upgrade or download a different browser. this is about as cardinal a sin as saying "best viewed at 600x800"... ---

i don't think you can blame webdesigner to focus on making "cool" stuff instead of fighting netscape's buggy implementation of web standards...

Sure you can. is the point of the site to look cool, or to get osmething done? if the point is to get something done, then coolness is secondary, and focussing on coolness is faultiness.

i've made a lot of webdesigns and evrytime i could i made it netscpae/macintosh/etc... friendly, but sometimes you just have to get rid of netscape 4.x because it is such a piece of junk that you simply can't work with it...

Actually, if you look at it, NS 4.x follows more standards. IE made it's popularity by ignoring invalid HTML. The big, big, problem people have with Netscape's handling of *HTML* is that it will quite often not render incomplete table definitions. Just as it should be. Other than that, it does have nasty issues with javascript. Though, in fairness there are a lot of cross-browser libraries that handle most of the differences.

the reason why this particular website filters netscape 4 is because of its weird javascript handling of objects (div), and i can really understand why they are doing it.

you simply can't code "out of the w3c book" with netscape, it's impossible to get something working straight...

take a look at www.dhtml.com and you'll see that 90% of the code is netscape compatibility/bugs related.

So what does that have to do with HTML?? Dhtml is NOT html. it is javascript. If you code "out of the w3 book", you are _not_ doing dhtml. You are doing some sort of client-side scripting.

imho of course ;-)))

likewise

On 01 Jul 2001 17:38:59 -0400, marc lindahl wrote:

...

From: Bill Anderson <bill@libc.org>

Actually, if you look at it, NS 4.x follows more standards. IE made it's popularity by ignoring invalid HTML. The big, big, problem people have with Netscape's handling of *HTML* is that it will quite often not render incomplete table definitions. Just as it should be.

The big problem I have with NS4 is that it doesn't not render complete table definitions, if they're nested too deeply. And it does not deal with CSS correctly.

Yes, CSS support is terrible in NS4.x. Deeply nested tables are asking for trouble anyway ;) Of course, I could go into a litany on how MSIE screws up such things as the box model, which NS/MOZ get right, and other things, but you get the point I am sure.

In fact, there are so many bugs with this browser, there are piles of websites dedicated to it (google returned 150,000 hits for 'netscape 4 bug list'). For example:

Do a seacrh on google.com for "IE Bugs" and you get 389,000 hits, and for "IE bug list" and you only shrink it by 3000. The point? This is not a useful tool for determining the accuracy of any given browser's HTML compatibility. Oh, yes I realized after writing the above that Iwas opening up to all IE bugs, not just one browser. So, i went back and added the '5'. it climbed to 'about 567.000'. Dropping the 4 of of your netscape search returned 'about 297,000'.

http://www.richinstyle.com/bugs/netscape4.html

most of the 'tips on this page apply equally well to IE. In fact, most of these, if not all, apply to CSS, or at a minimum the use of Styles. And of course, one would be remiss to not point out it's counterpart in IE: http://www.richinstyle.com/bugs/ie5.html Which lists the numerous bugs in IE5/5.5 (ignoring for the moment IE3 and IE4). And of course, Nestcae 6, which is found at the same site: http://www.richinstyle.com/bugs/ I am sure you did no tintend to slant the state of affairs by intentionally not mentioning the problems/bugs with IE, but just teh same, it is "fair" to include them as well. It is also fair to all of the browsers that some of the alleged bugs with them are not bugs, but simply differences in handling unclear, or vague parts of the various specifications. Just because browser X does it differently than browser Y, does not make it a bug.

http://www.wowwebdesigns.com/power_guides/worst_nightmare.php

http://developer.netscape.com/support/bugs/known/css.html

Again, I have not made argument with CSS support, merely noted that CSS is not HTML. it is, indeed, a separate sepcification and standard.

...

Other than that, it does have nasty issues with javascript. Though, in fairness there are a lot of cross-browser libraries that handle most of the differences.

Can you provide some pointers for some good ones?

How abou thte best: dynapi.sourceforge.net This one sets us up the bomb. ;) It is very well done, and provides a nice API for building cross-browser sites. it handles animations, layers, dynamic layers, has widgets, does dragging, frames, floating layers, and more. Contrary to some people's uninformed opinions, a cross-platform library does not have to be huge, and generally only needs downloaded the first time, after which the browser stores it for future use (individiual reconfiguration the noted exception to all such configurations). DynAPI is more than just *a* tool for X-browser JS, it provides a rather nice foundation of tools, in a reasonable size. This is the descendant of DynDUO, for those who remember it. There is also DynaCore. at http://www.dynamic-core.net which has much of the same functionality. And, it is LGPL :) Bill

On 01 Jul 2001 23:00:02 -0400, marc lindahl wrote:

...

From: Bill Anderson <bill@libc.org>

...

I am sure you did no tintend to slant the state of affairs by intentionally not mentioning the problems/bugs with IE, but just teh same, it is "fair" to include them as well.

It is also fair to all of the browsers that some of the alleged bugs with them are not bugs, but simply differences in handling unclear, or vague parts of the various specifications.

Just because browser X does it differently than browser Y, does not make it a bug.

True. But if you read the HTML4 spec, XHTML, etc. and code a page following that, and see what you get, what happens. Are the W3C specs valid or not?

Well, much of the specs are incomplete, some intentionally so. Ther are uses of such words as "should, may, shall", in addition to the "must,will". If a spec says something 'should' do something, and it does not, it may be an annoyance, but it is not a bug. if it says 'may' or says it is up to the client program, nad it does not, is is neither a bug, nor non-conforming. As far as a spec being valid, I see quite often that a numbe rof HTML Spec releases specifically say they included a number of bugfixes -in-the-spec-. oh, and w3 still lists XHTML as a recommendation. IIRC, this means it has not been made a formal spec. While it will likely become one, it is not currently, and we cannot rightly fault current browsers for not adhering to it. In the world of standrads, it is an important distinction. Do some browsers render differently, even given strict HTML? yes. it is in the spec that they can, on various things. Even XHTML allows for a certain leeway in rendering choices.

My limited experience shows me that the IE browsers do a better job of rendering a moderately complicated page (like the CMF default template).

I have a number of sites I have had to make quite a bit of extra coding/authoring/whatever to work aorund IE's displaying patterns. Much of them due to a) it screws up the box model* and b) nested tables

...

Again, I have not made argument with CSS support, merely noted that CSS is not HTML. it is, indeed, a separate sepcification and standard.

But it is part of the HTML4 standard that CSS has to be supported, and all the standards after (e.g. XHTML), right?

I don't recall the spec saying that to follow this spec you have to follow all later ones. That would be nonsensical. or are you meaning something else? * IE Trashing the Box model According to the spec, a box that is listed as 300 wide, and a 20 internal padding is 340 wide. IE makes the box 300 wide, and shrinks internally to make the padding. Now, in 6.0beta, this has partially been resolved. Now, unless we can convert this back to zope-ness, I suggest we take it private if you wish to continue. Bill

On 02 Jul 2001 03:47:10 -0400, marc lindahl wrote:

...

From: Bill Anderson <bill@libc.org>

...

...

But it is part of the HTML4 standard that CSS has to be supported, and all the standards after (e.g. XHTML), right?

I don't recall the spec saying that to follow this spec you have to follow all later ones. That would be nonsensical. or are you meaning something else?

Of course I mean that CSS will be required to be supported in future HTML specs.

Oh, ok. it makes sense. Though we can't blame today's, or yesterday's in the case of NS4, browsers for not supporting tomorrow's stadards. :)

...

* IE Trashing the Box model

According to the spec, a box that is listed as 300 wide, and a 20 internal padding is 340 wide. IE makes the box 300 wide, and shrinks internally to make the padding. Now, in 6.0beta, this has partially been resolved.

True, but I see this as a minor annoyance compared to NS4's inability to set a zero left margin with CSS, for example, or randomly render moderately complicated table layouts.

It depends on layouts. I encounter the box-model problem more often than the zero-margin problem.

...

Now, unless we can convert this back to zope-ness, I suggest we take it private if you wish to continue.

I put up as an example, the layouts in CMF. They don't render correctly in NS4. Perhaps you can suggest some ways to fix it.

How do they not render correctly? I have hundreds of clients that use NS4, and have had no problems with the default CMF layout. I just loaded up 4.76, and it looks just like it does under mozilla, and IE, with the clear exception of font differences due to the platform.

Another thing that would be nice is if the ZMI worked in IE5 -- cut and paste don't work in that browser.

Hmmm ... the few times I've used IE5 for ZMI work, I've never noticed that problem. Do you mean cut and past of objects, or text? On that note, quite often, in Mozilla, it won't go back a page in the ZMI. That is friggin annoying. it is mostly when I forget to close a dtml-in or something, andit displays the error. Then I cannot go back and finish it, winding up losing all the changes. That is, IIRC, due to javascript issues, but I may be wrong. Bill PS either send to me, or the list, but please, not both.

---

i don't think you can blame webdesigner to focus on making "cool" stuff instead of fighting netscape's buggy implementation of web standards... Sure you can. is the point of the site to look cool, or to get osmething done? if the point is to get something done, then coolness is secondary, and focussing on coolness is faultiness.

when designing this kind of websites (game/community), the main point *is* coolness (this is what the client buys). ---

i've made a lot of webdesigns and evrytime i could i made it netscpae/macintosh/etc... friendly, but sometimes you just have to get rid of netscape 4.x because it is such a piece of junk that you simply can't work with it... Actually, if you look at it, NS 4.x follows more standards. IE made it's popularity by ignoring invalid HTML. The big, big, problem people have with Netscape's handling of *HTML* is that it will quite often not render incomplete table definitions. Just as it should be.

this is a JOKE, netscape's implementation is less compliant (check http://www.webstandards.org/upgrade/index_n4.html as marc suggests...). yes, ie handles pages that are incorrect and that's definitely *not* a good thing, but netscape actually forces you to use bad code just to circumvent its inherent bugs. the worst example is maybe the dreaded dhtml position on reload bug (http://www.webreference.com/dhtml/column21/addendum2/col21addII2.html) which is the best example of baaaad design. --- Other than that, it does have nasty issues with javascript. Though, in fairness there are a lot of cross-browser libraries that handle most of the differences. --- but having to put in an additional 12k of code just to circumvent bug is really annoying... and those css issues... aaarararaggghhhh... :-( --- So what does that have to do with HTML?? Dhtml is NOT html. it is javascript. If you code "out of the w3 book", you are _not_ doing dhtml. You are doing some sort of client-side scripting. --- div positioning is definitely xhtml. bonnyk

--- An again, an example of something separate from HTML. no matter how much you may like to believe otherwise, DHTML is NOT a standard. DHTML is NOT HTML. CSSW, is a _different_ standard than HTML. --- waow, great... so we have this so-called browser not being able to render anything else than html... that is a big help to all of us ;-))) and what about bugs like table width ? frameset size ? non-transparent radio buttons ? and lots more... those are html 4.x bugs and ugly ones... i don't see ie bugs of this magnitude... --- Oh, and BTW, one thing you leave out is the _fact_ that the way IE behaves is different on MAC than it is on Windows (In many cases, the MAC behaviour is correct, btw). Again, I _have_ done the research, thank you very much. I have hundreds of bugs I can send you to on IE 5,/5.5, and 4.x. I can also show you how many of these are not bugs, in either browser, but are in reality, simply differneces in implementation of incocnlusive, incomplete, or vagueness in the original standards. --- netscape too behaves differently on windows and macintosh, and thats a bad thing too. in this area, they're both pretty inconsistent. --- yet, for some reason, people like taking a browser that renders incorrect HTML, and use it as teh standard of behaviour in things that are _not_ defined, and then take it further and insist that many of the peculiarities of IE are the way the standard says, when they are flat out wrong. --- i insisted on this point in my previous post. it *is* a bad thing (to render invalid pages), and that's *not* the reason why i prefer ie over netscape. --- And, from my position, browsers displaying incorrect HTML are far worse than browsers that have quirky implementations you code around. There is no reason for people to learn the correct way, when there is no 'penalty' for doing it the wrong way. "Why close the table when it displays in the browser anyway?" "It doesn't display in all browsers.""Well then those are buggy, I won't worry about them" That is the real-world effect. That is a newbies introduction to the world of standards. What good are standards when failure to follow is ignored ? --- this has nothing to do with ie vs netscape, this has to do with the way people code. the problem of newbies not closing tables is quite irrelevant since they are ? should be ? using software to generate the page and "should" html tidy their pages when they're done. they are not doing it and it's a problem, but it's not limited to ie (what about those leftmargin tags ?) those actually force people to put bad/inexistant codes in their pages... the real world effect i see is that clients who pay to have a website want it to look nice period. if you tell your client you can't do this or that because of netscape, they're very likely to say "scrap netscape, how much marketshare anyway ?" so in term of real world, netscape is pretty much dead over here (europe). it is a problem too, but this is the real world (the world where 80% of people use ie) and it costs more (time/money) to make a web site netscape compatible (assuming you start by designing a standard compatible page). of course, experience, code libraries, etc... can make it easier, but it doesn't remove those dammmmm bugs. --- Oh, and just for fun, I took a trip back to the w3 website to see if by some chance, somebody slippe din a DHTML standard. nope, there is not one. Since oyu cannot lay claim to a DHTML standard, you cannot lay cliam to a particular browsers means of handling client-side scripting as a bug, simply because it differes from another. DHTML is a marketing term, not a standard. --- rethoric rethoric... --- Please, this is such a weak argument on many fronts. I'll put my straight HTML up against your javascript anyday, and see who has a smaller download. People concerned about a one-time download of a javascript library, are not using DHTML. The cycle is returning to --- the problem is you have to make/use a library to handle things !!! knowing how to defeat a bug doesn't kill it, it just forces you to add more code onto something !!! --- substance over style, and the use of cross-browser scripting is but one herald and earmark. In addition, these libraries provide more functionality than one itty bitty bug workaround. They provide a set of widgets and functionsin an API that allow the developer to develop widgets that are cross-browser, and do so with much more ease than developing them from whole cloth for a single browser. --- true --- This argument also is tantamount to this statement: "I know that there are ways of solving my problem, but I don't care, I'd rather make the end-user suffer because I was too lazy to use them, and to make it better,I'll blame it on slow downloads, thus making it look like I am doing them a favor." --- i'm *not* saying i'm leaving those user in the dark, but i'm saying that it's a pain in the ass to have to do it just because of thir browser... --- The big hype of the internet is finally being realized for the hype that it is,and thus we see the fall of many sites that were just a little bit of content wrapped in a huge pretty wrapper. In the rush to dominate, many companies bought into the propganda, and are now reaping the result; dying dot coms. Look at the more popular user-interactive sites, the ones that have survived the fallout, and you will see that most of them are: a) Cross platform b) Cross browser c) Dominantly server-side d) presenting substance over style --- i do agree with that, but this is has nothing to do with ie vs netscape. it is a design issue, if i want to / have to make a complex page i should be able to make it. ---

div positioning is definitely xhtml. Note the X in XHTML. XHTML is not HTML. XHTML is a stricter set of HTML, reformulated to be an XML application. XHTML is the current _recommendation_ for the next generation of HTML. As such, it is not HTML. SGML is an application of SGML. Why the change? According to the w3, it is because there are becoming more ways of accessing internet data. This means multiple kinds of clients, as well as multiple implementations. In HTML 4.0.1 (aka, the current standard), div is not a positioning tool:

i thought XHTML was the current standard (http://www.w3.org/MarkUp/#recommendations) --- Positioning is an aspect of style application. The w3 HTML 4.x standard doe snot indicate div is to be used for positioning. if you want to complain about a browser not positioning it the way anotehr does, or the way you think it does, your argument lies with the browser's implentation, or lack thereof, of CSS/CSS-P. --- ok, and *again* this doesn't come out on netscape's side... my point is just that when designing web pages (using html 3, 4 , x and css, javascript (ecmascript) or whatever other *standard*, netscape does a poor job with version 4.x bonnyk

While I agree that Netscape had it right when it didn't allow complete HTML, (opening AND closing tags where appropriate), IMHO Netscape 4 was still a piece of crap. It had problems with CSS and the like. Now, of course, the JavaScript DOM is different in Netscape than in IE, but I don't fault Netscape on this one. Here, IE shouldn't have ventured into their own "JavaScript" (JScript). But a clear determination can be made by comparing Netscape 6 vs 4.+ Much better handling of stylesheets, IE and Netscape work in the same code, DHTML works now --> simple text-rollovers now work in Netscape, and the like... Now it's possible to code a site without actually having the weigh functionality vs cool design. That question will always have to be evaluated, but at least now you can have some fun while still delivering what's truly important. Again IMHO, but I'm sure you knew already knew that! ;> Tommy