We now have a links toolbar. Auto-show support is in now, and will be available tomorrow. It works, and is extremely useful, in Bugzilla bug lists. It would be really cool if more sites supported it - search engines (Google, Altavista, Netscape, Yahoo), news sites (Slashdot, Kuro5hin, BBC), online newspapers (Telegraph, Times, New York Times, Wall Street Journal) etc. The possibilities are endless. From a Mozilla point of view, the more sites implement logical navigation, the better. (From a Netscape point of view, if we can get a bunch of sites using this in time for MachV, it will be a far more trumpetable feature.) In most cases, it's merely a replication in <link> tags in the <head> of the same info that's already in <a> tags in the body. So it's not a major code change. This bug has been filed to get the advice and help of the evangelism team in this effort. Gerv
Since bug 103082 has removed the links toolbar, I think we can put this off for a while. While increasing support for the more general uses of LINK is a good idea, I think there are many other areas where evangelism is needed in terms of communicating with site owners, developing documentation, tools, etc. We still have to contend with the immediate fact the market share of Gecko based browsers is still very small and we are having difficulty getting site owners to update their content to support Mozilla/Gecko. Adding additional requests for site maintenance tied to a feature that is only supported by very recent Mozilla builds will be a hard sell. Considering that www.mozilla.org is for and about Mozilla, I think we can use this feature on our own documentation first. We can then begin the process of educating site developers on the usefulness of LINKs by demonstration. Finally, I don't understand how a general search engine could use LINK effectively. The LINKs would have to be inserted into the pages returned by the search engine wouldn't they?
> I think we can put this off for a while. I disagree. Jag made the excellent point that we should have had sites supporting <link> before we even launched the toolbar. Let's not make the same mistake twice. > that is only supported by very recent Mozilla builds And iCab :-) It's been in the HTML spec since HTML 2.0. > will be a hard sell. If it involved any major changes to pages, it would. But, as I said, it's merely a replication of information and therefore, in most cases, not hard to add. > I don't understand how a general search engine could use LINK effectively. Anything that has a sequence of numbered pages could use <link> effectively. Google returns 20 pages of search results <link> them together. It would be a trivial server-side change for them, as I outlined in the original comment. Gerv
It is hard to sell any maintenance to sites where there is no immediate benefit to them to perform the maintenance. We can promote the idea but I don't see that it is a very high priority issue now. I think using the idea on www.mozilla.org will help demonstrate it's usefulness and help fine tune the implementation since we will gain experience from it's use. I can see this being useful for documents in general that have an ordered sequence of pages, but I still don't see how a general search engine would use this. Google may return a list of pages, but those pages are owned by other sites and do not contain the sequence info from the Google search. For this to work in a general search engine, the retrieved pages would have to be retrieved by the search engine, then modified to insert the LINKs (which would point back to the search engine themselves), and then return the result to the user. I don't consider that a minor issue for the search engine, for the site whose content is being retrieved nor the person doing the search.
Bob: for search engines, I believe the idea was to put the <link> tags in the search results pages (much like they have custom navigation controls in there right now), instead of in the actual pages they've found.
Yes, exactly :-) Google are friendly towards Mozilla, and very popular. We could start with them. Gerv
Ok. I get it now. Do we have a contact for them?
I got email from firstname.lastname@example.org about their XUL toolbar - that was signed: Regards, The Google Team So that might be a good place to start. CCing a couple of people who might have time to write a short explanation and fire it off to a few well-selected emails. Gerv
I've emailed LWN but got no response - that was back way before the toolbar was checked in, though. I'll follow it up after 0.9.5 gets released, especially if it's defaulted to autoshow in the release. To be honest, I don't think the outlook is as bad as it could be anyway - already it's quite rare for me to find myself thinking "I wish this site had links" on a site that doesn't. The places that could really stand to benefit - mailing list archives, texi2html'd documents etc - already seem to have it. The best bet for mainstream corporate-owned sites would be some kind of official contact from The Behemoth That Is Netscape-AOL-TimeWarner. Are the appropriate people for that kind of corporate evangelism on this bug yet?
Attaching to the tracker bug so we can keep an eye on this. Wouldn't another angle of attack be web-design sites? Once whatever products have been made from 0.9.5 appear, they might be interested in writing articles on how to take advantage of this new feature of $PRODUCT...
Does anyone feel like drafting a form letter? Someone with previous evangelism experience would probably be good. Gerv
I think we should start by making a "how to use <link> elements effectively" document for www.mozilla.org rather than by contacting speicifc sites. Other Mozilla features we should encourage web authors to take advantage of: - the ability to have a different alt= and title= for images - <abbr title=> and other elements that get dotted underlines - accesskey (IE supports accesskeys better, but Nav4 didn't have them at all) - alternate stylesheets - any interesting CSS2 features that might be popular if authors had heard of them - XUL: make your web page feel like part of the browser These could be lumped with documents related to traditional tech evangelism, such as "how to convert old JS to cross-browser JS" and "what Nav4/IE quirks Mozilla doesn't support and why", or they could be separate.
Well, why not widen the scope of this bug a bit? :-) Seriously, if the evangelism team want to do "cool stuff evangelism" as well as "your site is broken" evangelism, that would be great. But I don't want the grand plan to stop the small one, which is to mail the tech teams of a few well-chosen sites asking them to implement <link> support. Gerv
Considering that the evangelism team has more than enough "your site is broken" issues, -> Future. If anyone would like to contact Google or anyone else about adding support for links, please feel free to take this bug.
I think sites will be quick to pick it up. Webmasters are very enthusiastic about any possible way to influence the user's UI. We just need some initial documentation, if possible on some large site (e.g. WebMonkey). Also note that some of the buttons we have in the Site Navigation Bar aren't defined in the Link Types section of W3C's HTML 4.01. For example, the Up button, the First button, the Last button. We need our own page outlining what LINK types we support and how they correspond to the UI buttons.
I agree with the idea. Mozilla is also there to support standards. So why not push them as well? I would like to point out that there are many open source programs that generate pages that could have use of Links. I am thinking of Open Source search engines: - mnoGoSearch (Debian) [http://search.mnogo.ru/] - swish-e (Apache) [http://swish-e.org/] - ht://Dig (KDE) [http://www.htdig.org/] - ... Another field would be sites programs that generates HTML. I am thinking of programs like latex2html. E.g. http://cbl.leeds.ac.uk/nikos/tex2html/examples/IRCprimer1.1/IRCprimer1.1.html We are open source developers. We can improve these programs so that they generate <link> tags. Before dealing with closed 'software', let's push adoption by improving standards thanks to Open Source.
Jerome: thank you for volunteering to help! If you could draft a letter, that would be great. You may want to link to choess' draft document on link types. Gerv
Gerv, where *is* "choess' draft document"? I just added LINK tags to <a href="http://sincerity-forever.lcs.mit.edu/photo/pcd0262/">some of my (mostly-automatically generated) photo pages</a>, and I looked all over for any kind of documentation on just what LINK tags were supported. The W3 has <a href="http://www.w3.org/TR/html4/types.html#type-links">a short description</a> on the basic next/prev/start/etc types, a <a href="http://www.w3.org/TR/html4/present/styles.html#style-external">description of using LINK to implement alternate style sheets</a>, and a short discussion of <a href="http://www.w3.org/TR/html4/struct/links.html#linksandss">providing indexing hints to search engines using LINK</a>, but it's hard to sort through this information. Basic usage examples are omitted, as well: nowhere is it stated how to use the "Chapter" LINK (for example) to actually create chapters in a document. A central home for this information is badly needed.
choess should be able to point you at it himself :-) His document is exactly what you are asking for. Gerv
Mass reassign of all tech-evangelism us general bugs assigned to bc to doron except bc's P1 bugs. You may search for this mass reassign (it is 305 bugs) by searching for the keyword 'greeneggsandham'
accessibility is another reason to evangelism link: http://diveintoaccessibility.org/day_9_providing_additional_navigation_aids.html
tech evang june 2003 reorg
This ship has sailed. Gerv
Says me, and I filed the bug. Firefox has no UI for the <link>s in question, and won't have. There's not much point in evangelising it without that. Gerv
Though the SeaMonkey suite does. However, the lack of comments for about five years does seem to show lack of interest. It's a shame.
(In reply to comment #24) > Says me, and I filed the bug. Firefox has no UI for the <link>s in question, > and won't have. There's not much point in evangelising it without that. Yes, Fireforx has no UI for the <link>s in question. I don't primarily use Firefox (but SeaMonkey) but for tests I use the Link Widgets <https://addons.mozilla.org/firefox/addon/2933> extension which is really nice. It would be great if it could be integrated into the standard code base.
Talk to the SeaMonkey devs. The closure of this bug doesn't prevent anyone going out and doing some <link> evangelism if they feel it's a good use of their time. You don't need a bug for that. Enough, already. Gerv