MozillaZine

Links Toolbar Landed

Wednesday October 3rd, 2001

Gervase Markham writes: "The Links Toolbar from bug 87428 has finally landed, bringing us ever-closer to full support for HTML 2.0. You'll see it in this morning's builds. The auto-show is still in development over in bug 102832. Good places to try it out are Bugzilla buglists, the W3C, htmlhelp.com and many machine-generated manuals or documents, such as the GNU Make manual."


#80 Re: Re: Re: Re: Re: Cool, but ...

by choess <choess@stwing.upenn.edu>

Friday October 5th, 2001 2:14 PM

You are replying to this message

As I said above, trying to make sense of the supposedly RFC-normative language in HTML4 is a canard; such language is much better suited to describing protocol handling than general UI. Regardless, the W3C Note Common User Agent Problems says that while HTML 4.01 does not specify definitive rendering for <link> elements, user agents should interpret them in useful ways. That's a very clear call for this feature.

>>It doesn't matter. Netscape people manage the source, and they let this checkin happen during feature freeze based on fallacious arguments about standards.<<

No, they checked it in because it had gotten an obscene amount of code review and looked like a safe patch. Did you even bother looking at bug 87248? None of the testers and reviewers noticed perf problems before this was checked in; I presume that the addition of the toolbar makes the *perceived* time appear the same (because there's a new bit of chrome that catches your eye as the page loads), but actually increased it a bit. Standards don't have Get-Into-The-Tree-Free cards.

>>Now a bunch of Netscape people are spending a ton of time working on evaluating this new feature and making determinations about it, time which they could be using to drive down the upward-spiraling defect line. It's bad project management and it's hurting the software's chances of ever attaining a stable release.<<

Huh? Netscape people are not spending "a ton of time" on this. jrgm saw a spike on his performance tests, re-ran them with and without the patch, and hyatt pulled it out. sballard, non-NS, produced several perf patches, including one that keeps it from using resources when disabled; hyatt saw that it was good, and the toolbar was put back in, disabled-by-default. I'd say that's fairly good for getting in a feature which is on a par with Print Preview for bugzilla votes (distributed across bugs 2800, 87428 and 103053). As things stand, there's absolutely no need for NS people to be "evaluating it and making determinations about it"-it's in the build, it works if you want it, and it doesn't hurt you if you don't.