In article <astv56$[EMAIL PROTECTED]>, Daniel Wang <[EMAIL PROTECTED]> wrote:
> Anyhow, the document should explain its intent and the intended audience. OK. > From what I have read from postings in public forums from Web monsters, > most questions falll into two types; the questions are either "how do I > do this" or "why doesn't my site work in so and so browser"? The > document obviously does not deal with the first type of questions, so > I'd suppose its main concern to be general troubleshooting. The "how do I do this" questions aren't Mozilla-specific as long as the subject matter in in teh realm of standards. Since the FAQ is about Mozilla-specific questions, the questions are of the type "why doesn't this work". > >> 1.1 how is Mozilla different from Netscape 4? > > > > Is that a real question that is frequently asked by Web authors? > > Sure. Otherwise there won't be so many tech evangelism bugs? It isn't really a question that is asked, in my opinion. The question doesn't even occur to the people whose sites and up as 4.x-ism evang issues. > how about a link to http://webstandards.org/about/ ? The WaSP folks have been pushing buzzword compliance lately--that is XHTML-as-text/html over HTML without giving proper technical justification for doing so. Also, their technical FAQ seems to be spreading a common misconception about the relationship of HTML and XML and the make-up-tags-as-you-go method. > >> Mozilla currently has full support > > > > Claiming full support is always problematic. There are known bugs, so > > claming full support will look bad in the opinion of some observers. > > statement taken and modified from the wishlist FAQ (on mozilla.org site, > not my version). I think we should keep it simple and just say "full > support", otherwise we have to digress to what bugs there are... I think it would be better to leave out things that look more like an overview rather than answers to specific issues. > > I was actually considering approaching the issue from the point of view > > of the frequent "what the author intended" debates, but I thought the > > answer would be too hostile. > > Spill it out and we can discuss about it :) The problem with this sort of thing is that it will be perceived as advocacy which would better be avoided in a document that is intended to give strictly technical explanations. (The text contains some HTML-stuff in plain text.) Q: Why isn�t Mozilla rendering my page as I intended? So my page isn�t standards-compliant, but good browsers should render pages as the author intended anyway! A: Authors are supposed to communicate their intentions using the Web standards. Otherwise, finding out the intentions of each particular author would require psychic abilities which can�t be implemented in software. Even in cases where a human could deduce the intention, doing so in software would be very slow, bug-inducing, difficult and complicated. The usual counter argument is that there is no need to guess—Mozilla should do whatever browser X does (where X is the favorite non-Mozilla browser of whoever is presenting the counter argument). However, doing whatever browser X does in every conceivable case isn�t simple at all, even though it might appear to be simple when presented as a passing remark. Different people have different ideas about what X should be. The second problem is that Web authors are very creative in coming up with different ways of deviating from the standards. In fact, since the input to the browser can be of arbitrary length, there is no upper bound for the number of distinct ways of deviating from the standards. Therefore, it is impossible to test whether Mozilla reacts exactly like browser X to every possible input. (Likewise, there is no upper bound for the number of ways different features of the standards themselves can be combined, which makes software quality assurance challenging.) Also, the ways in which browser X reacts to some standards-incompliant input are not all intentional. Some of the reactions are due to unknown and unintentional interactions within a complex program. Even if you had the source code for browser X, you could change <em>anything</em> without risking changing one or more of the unknown and unintentional interactions within the program. The usual counter argument is that Mozilla doesn�t need to match the behavior of browser X in every possible case but only in the alleged <em>common</em> cases. However, it turns out Mozilla is doing that already. Mozilla�s Standards mode is, obviously, already compatible with other browsers that implement the same standards reasonably correctly. On the other hand, Mozilla�s quirks mode already accommodates common non-standardisms that are due to the behaviors of common legacy browsers. Instead of putting time and effort into reverse-engineering and cloning legacy browsers, it makes more sense to focus on implementing standards. Stadnards (when implemented by others as well) promote interoperability better than cloning legacy software bug by bug. > > Huh? I'm not going to suggest excessive table nesting. > > Well, I don't think I can explain the whole art of table-based layout in > a few sentences. Maybe I could write an elaborate tutorial on that and > have you link to it (btw, know a site where I can post such a tutorial?) One of my goals with the FAQ is to make it politically correct enough to get it referenced in comp.infosystems.www.authoring.* when a recurring Mozilla-specific question appears. Endorsing table layouts would not help with that goal, since the HTML purist concensus is against the practice. -- Henri Sivonen [EMAIL PROTECTED] http://www.hut.fi/u/hsivonen/
