Evangelism - Get more sites to support <link>



Tech Evangelism Graveyard
English US
16 years ago
3 years ago


(Reporter: gerv, Unassigned)



(Whiteboard: aok)



16 years ago
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)


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.


Comment 1

16 years ago
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?

Comment 2

16 years ago
> 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.


Comment 3

16 years ago
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.

Comment 4

16 years ago
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.

Comment 5

16 years ago
Yes, exactly :-) Google are friendly towards Mozilla, and very popular. We could
start with them.


Comment 6

16 years ago
Ok. I get it now. Do we have a contact for them?

Comment 7

16 years ago
I got email from googletech@google.com about their XUL toolbar - that was signed: 

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.


Comment 8

16 years ago
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...
Blocks: 103053

Comment 10

16 years ago
Does anyone feel like drafting a form letter? Someone with previous evangelism
experience would probably be good.



16 years ago
Summary: Get more sites to support <link> → Evangelism - Get more sites to support <link>

Comment 11

16 years ago
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 
- 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.

Comment 12

16 years ago
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.


Comment 13

16 years ago
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.
Target Milestone: --- → Future

Comment 14

16 years ago
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.
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.

Comment 15

16 years ago
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.

Comment 16

16 years ago
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.


Comment 17

16 years ago
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
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.

Comment 18

16 years ago
choess should be able to point you at it himself :-) His document is exactly
what you are asking for.



16 years ago
Whiteboard: aok

Comment 19

16 years ago
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'
Assignee: bclary → doronr
Target Milestone: Future → ---


15 years ago
Depends on: 103469

Comment 20

15 years ago
accessibility is another reason to evangelism link: 

Comment 21

15 years ago
tech evang june 2003 reorg
Assignee: doron → english-us
QA Contact: zach → english-us

Comment 22

10 years ago
This ship has sailed.

Last Resolved: 10 years ago
Resolution: --- → WONTFIX

Comment 23

10 years ago
Says who?

Comment 24

10 years ago
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.


Comment 25

10 years ago
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.

Comment 26

10 years ago
(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.

Comment 27

10 years ago
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.

Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.