Whither M14?Thursday February 17th, 2000M14 is being handled a little differently than previous Milestone builds, according to this news post from Jim Roskind. Instead of building a solo M14 branch, and stabilizing that, they are going to continue to squash PDT+ and Beta flagged bugs, and will flag some daily builds this week as potential M14 candidates. Jim also talks a bit about Netscape's beta plans. Their list of "beta blocking" bugs is shrinking quickly, but they haven't yet reached a point where Netscape feels comfortable doing a "beta" branch for stabilization. Jim says that he hope that happens "in short order". We have to wait, but if some of the improvements over the past week are any indication, it will definitely be worth it. Would anybody be so kind as to post the Deja link to the same article? I can't read news from my browser... :( I'm actually very pleased about this. The number of M14 bugs, and the number of beta1 bugs, still seem to be too high that pushing a beta out at this point would probably look bad on mozilla to the average joe. Not to mention that there seem to be quite a lot of bugs which are blockers to quite a lot of people that are scheduled for M15. On the other hand, for those of us who have been using Moz milestones for ages already, the sooner M14 is out the better (I want the cool new features... and debian only seems to want to package milestones). So I think this is good news for everyone concerned. The beta will be more polished and stable than it would have been if it had been pushed out now, so Mozilla looks better to the rest of the world. And we get another milestone without a long delay :) Stuart. I think this is it: http://x31.deja.com/getdoc.xp?AN=582585945.1&CONTEXT=950803341.633077760&hitnum=12 I sincerely hope that CSS1 support is 100% perfect in the final release. Otherwise, there will be yet another headache as developers "workaround" the bugs, which will cause problems when newer versions of the browser fix them. Some developers may say screw it, and stick with the 98% version to remain bug-for-bug compatible. I feel that this time, the browser shouldn't be released unless the HTML/CSS standards support is perfect, even if it means waiting. (I'm am talking about the FCS version, not the beta) The mozilla pages have listed the CSS support as 98% for a while now (all the way since M8 atleast). I'm wondering why progress has stopped on that 2%? Anyway, can anyone explain why Mozilla displays www.msgto.com with the widgets in the wrong place, but Netscape and IE display it correctly? It's probably bad HTML somewhere, but IE/NS4 still display it correctly. Why does it seem that you are wantinig to completely different goals? On one hand, you are saying that you want full 100% CSS1 compilance, and on the other hand you are saying that www.msgto.com isn't displaying properly and even if it is using bad HTML it should display properly (like IE and NS4). Do you want compliance or buggy implementation to display buggy HTML 'properly'? -Chris Maybe rjc999 wants the Internet thing to live up to its promises without failing on existing Webpages. Well, I didn't say it was definately bad html, just that I suspect it. BTW, I am the author of that site. I have a version that is "skinnable" via XML -> XSL->XHTML transformation and that version displays correctly. Only the non-XML straight-HTML version fails. I'd still like to know why Mozilla screws up. No advanced CSS features are used at all. Nevertheless, I am not talking mutually incompatible goals. It is certainly possible to support correct CSS rendering, and backwards-compatible buggy layout at the same time via a switch, or possibly even auto-detection. Do you suddenly expect 100 million web documents to be converted to spec-compliant HTML4.0/CSS overnight when Mozilla is released? I don't think so. Mozilla must be able to browse the vast majority of sites without error if it wants to replace NS4/IE4/5. Right now, the situation IMHO is worse than having both. CSS1 support isn't 100%, but neither is the layout compatible with "buggy layout" that exists in IE/NS. Therefore, Mozilla is introducing simply another non-compliant rendering that developers with have to test for. I'm already sick of testing my site on Mac IE/NS, Windows IE/NS, AOL, and WebTv. WIll I have to now test to see if Mozilla renders differently too? My expectation is that if I refrain from using CSS, and stick with simple HTML, the page should be readable on all browsers. I don't mean identical, but atleast being able to read all the text is important without gross layout errors. HTML4.0 should be "write once, browse anywhere", not "write once, test everywhere" That's why I continue to hope that Mozilla will not only display all existing web pages correctly, making it easy to migrate too, but that it fully supports HTML4/CSS1 such that it serves as a bridge between the old web, and the new. If I have to own two browsers, one to browse existing web sites, and one to browse sites that use the new working CSS features, I regret to say, I would probably stick with the old browsers, and not bother doing a lot of work to convert my documents. Of course, with AOL distributing Mozilla in AOL6, it probably won't matter if consumers will accept the inability to display some old pages. In that case, by sheer market share of AOL, I would support Mozilla directly, maybe even deliver XUL interfaces. The Mozilla project has taken its time to do Gecko correctly. They should not try to rush a release because of some artificially set milestone/deadline by AOL or a project manager. Mozilla/Netscape5 should ship "when it's done". That means freezing features, and fixing all critical bugs that cause it to diverge from specs (both new and old)
I completely disagree with the idea of Netscape continuing to support the mistakes of the past (Bugward compatibility, as it is commonly termed). Doing so would probably add another year onto the ship time, and an extra meg or two to the size of the distribution, and the only 'benefit' gained would be to allow/encourage web designers (and web authoring tool designers) to continue writing sloppy code. On the other hand, I completely agree with the rule of not shipping until HTML 4.01 and CSS1 are tested and known to be completely and precisely supported. Netscape and Mozilla have committed to this publicly for a long time, and it is, IMHO, Mozilla's major selling point. Breaking those promises and releasing with /any/ HTML or CSS bugs outstanding would greatly diminish Mozilla's reception, and I don't think anyone involved in the release decision would want such a thing. I think that if people download any Web browser built on Mozilla, and it does not display Webpages correctly while existing Web browsers do display them correctly, people will not assume something is wrong with the Websites. I think they are going to assume Mozilla is not working properly. What do you think will happen then? Do we want Mozilla to be one more branch of a long JavaScript condition? Is this not what Mozilla is supposed to put an end to? I suspect many of the Websites, which fail with Mozilla, are currently of More value to people than Mozilla, so if Mozilla attempts to force these sites to change, Mozilla will have to work against their popularity as well as the forced popularity of Internet Explorer (which works with these sites). An even worse condition would be an Internet Explorer 6 that is W3C-compliant and able to handle existing Webpages. I would agree that the volume of bad HTML out there will probably slow Mozilla's penetration. However I don't think that that should be Mozilla's concern. Mozilla isn't a commercial browser, and shouldn't be driven by a need to grab market share. Mozilla is an open source project designed to implement the W3C standards properly, and once it's accomplished that goal, and reached an acceptable threshold of stability and responsiveness, it's ready for release. If Netscape (or anyone else) then wants to put in the effort to extend their branded versions to address commercial concerns, that's up to them...Mozilla can independently move on toward adding support for CSS2 and XSL. If MS releases an IE6 that is fully W3C-compliant, I'll consider Mozilla to have been a resounding success for raising awareness of the issue. My goal is to see a web where a web developer can write a page to W3C specs and expect it to work. This brings back some old ideas discussed a while ago in Mozillazine: 1. A "bad HTML" message or icon somewhere. I know that Arena used to have this and it shows up badly-written sites easily to the end-user. Even better would be to have an option to pop-up a pro-forma dialogue box when you click on the bad HTML text/icon to send e-mail to the Webmaster to complain about badly-written HTML on their site. Webmasters aren't going to change unless they're told by their visitors that they can't view the site properly. 2. If you really *must* ship a Mozilla with support for non-compliant HTML (I personally don't agree with this, because it'll mean MS won't have to support standards fully with IE and the proprietary tag battle will continue), then a) only do it for stuff that's easy and quick to implement, b) make sure the default is to *not* support them, c) make the option to turn on broken support buried well down the preferences dialog and d) gradually phase out the broken support over time anyway. To me, adding support for bad HTML is the complete opposite of the ethos of Mozilla. It's the *other* browsers that should be *removing* support for bad HTML and become more W3C compliant. If Mozilla shipped with bad HTML support, the others will continue to leave such rubbish in their browsers. |