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."


#81 Re: Re: Re: Re: Re: Re: Cool, but ...

by strauss

Friday October 5th, 2001 2:44 PM

You are replying to this message

>> 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. <<

<http://www.w3.org/TR/cuap>

"This document is a Note made available by the W3C for discussion only. Publication of this Note by W3C indicates no endorsement by W3C or the W3C Team, or any W3C Members. There is no commitment by W3C to invest additional resources in topics addressed by this Note....

"Although the HTML 4.01 specification does not specify definitive rendering or behavior for these link types, user agents should interpret them in useful ways. For instance, the start, next, prev, and contents link types may be used to build a table of contents, or may be used to identify the print order of documents, etc."

So the actual status is not, as stated, that this is required by the HTML standard. Someone's opinion piece says that there ought to be some kind of useful support for them, while the standard leaves user agent support as a "may." That's a long way from the stated justification for the feature.There is no requirement for it in the HTML standard.

>> No, they checked it in because it had gotten an obscene amount of code review and looked like a safe patch. <<

All of which is time spent on a new feature rather than on fixing the bugs in existing features. And what do you know, it turned out it wasn't a safe patch after all, even after all that "obscene" (your word) resource drain. That's why after a certain point you just don't let new features in, barring some drop-dead requirement. They create new problems, and evaluating them take resources away from bug fixing.

Really, guys, this is technical project management 101 here. It's not some weird thing I just came up with.

>> As things stand, there's absolutely no need for NS people to be "evaluating it and making determinations about it" <<

Funny, you just cited several ways in which they were doing just that. There's a palpable resource drain. Just reading through the related bugs shows how much effort has gone in so far.