146888 - [RFE] Branding: Site Search For ...

Status: RESOLVED WONTFIX

(SeaMonkey :: UI Design, enhancement)

Description

[rbs]

It is amazing all the buzz that reviews are making about "Web Search For ...".
Seeing all that, one could hardly imagine that the feature is equivalent to
just copy-paste the selected text in the location bar & hitting enter.

In view of the acceptance of "Web Search For ...", I am filing this RFE for a 
"Site Search For ...".

Basically, a site that wants this would just set a default search url, using a 
default:

   <link rel="moz-search" url="...the-search-uri...">

and the context menu will do the rest (I am leaving the precise details/syntax 
to you folks... knowing that other browsers will be embracing & extending "Web 
Search For ..." pretty soon, and perhaps this RFE too).

Comment 1

[rbs]

What do you folks think of this? Knowing that it wouldn't be that hard to
implement, would that entice new IE users to switch? The branding could allow
authors to set their own title prefix in the <link> tag to get a customized
appearance such as: 

Search Bugzilla For "..."
Search Nestcape.com For "..."
Search CNN For "..."
Search BBCi For "..."
Search hixie.ch For "..."

etc, depending on what the webpage might say in its <link> to override the
default prefix (will need a spec with the syntax, maxlength for the prefix, etc).

Comment 2

[rbs]

Cc:ing [e-mail] from bug 90966 where link toolbar folks were 
discussing what to do from their perspective.

The spec for the <link> is here:
http://www.w3.org/TR/REC-html40/struct/links.html#h-12.3
and apparently what to do with it is pretty much left to imagination and 
evangelism.

For the purpose of this bug, it is conceivable that one could try:

   <link rel="search selection" title="...%s..." href="url?q=">

-> i.e., require/evangelize that the title needs a '%s' (or whathever) where to 
substitute the selection, and simply popup the context menu with the resulting 
title, append the selection to the href and launch it when that menu item is 
clicked.

Even sites that don't have their own search engines are increasingly using 
Google these days and so they can support such an option with the <link>.

Comment 3

[Hixie (not reading bugmail)]

...and if there is no %s, default to appending the search string to the end. And
if there is no <link rel="search"> at all, default to using the current search
engine.

Sounds good to me. What I am worried about, though, is that this is yet another
context menu item... we want to be keeping the length of context menus down,
down, down. Not bloating them further.

Also, how about if the search menu item is just "http://search.cpan.org/", a
very valid value?

Comment 4

[rbs]

> if there is no <link rel="search"> at all, default to using the current search
> engine.

This requires knowing how to set a custom site-search. Google uses domain=...,
but I don't know the precise syntax for other engines. Maybe, for simplicity,
the default could always be Google for Mozilla? (and some branded search engine
for commercial distributors, allowing to get more traffic since most pages won't
have such a <link> at the beginning).

> What I am worried about, though, is that this is yet another
> context menu item...

It was just recently in bug 122524 that I learned how painful it can be to touch
that dreaded context menu, remember? It wasn't easy for me to sit down and enter
this RFE while that bug was still fresh in my mind. At the end, I just said to
myself that I will file the proposal and see what others think. Unfortunately,
this is in the sensitive area of the context menu where any proposal is viewed
with suspicion until proven otherwise. Given the vital need to continue to
innovate to attract more users, I finally filed the bug to at least put a food
for thoughts on the table.

The persuasives to me were: 
- such an option achieves a better value than filling people's desktop/personal
toolbar with invasive icons that turn people off. From there on, other
things/ads can be added indirectly from the search branding (e.g., to continue
to fund the development)
- it is so easy and appealing to authors to customize that they will be enticed
to keep Mozilla/Nestcape in mind
- it fits in the "click-to-search" paradigm that is getting dazzling reviews
- it gives a nifty/useful option in its own right to users; the competition will
have to catch up (i.e., copy) and so when reviewers will mention it, they will
refer back to its origin, making another wave of people to comeback and download
to see for themselves, like when you set out to buy something you end up buying
other things).

The dissuasive was that it added yet another context-menu option. If the
front-end people find the dissuasive stronger than the persuasives, so be it. I
won't really push much.

> Also, how about if the search menu item is just "http://search.cpan.org/", a
> very valid value?

It is in the interest of authors to be more specific. Since customization is
possible down to the <link> on a single page, any particular reason why there
should be much attention to special cases? It looks like the similar problem of
broken links that are to be fixed by authors.

Comment 5

[Hixie (not reading bugmail)]

rbs: I agree with all your points. The benefits are indeed tangible. The
question is whether the UI benefits outweight the usability hit. marlon? mpt?
Comments?

Regarding the last point -- I was under the mistaken assumption that the HTML4
spec mentioned 'search' explicitly. As it does not, please disregard my comment.

Comment 6

[Serge Gautherie (:sgautherie)]

Filter "spam" on "guifeatures-nobody-20080610".

Comment 7

[Philip Chee]

> Regarding the last point -- I was under the mistaken assumption that the HTML4
> spec mentioned 'search' explicitly. As it does not, please disregard my comment.
WONTFIX.