[Bug 6610] add a preventable forced-fragment method

http://www.w3.org/Bugs/Public/show_bug.cgi?id=6610





--- Comment #4 from Nick Levinson <Nick_Levinson@yahoo.com>  2009-02-28 04:44:19 ---
What if Google's and Yahoo's search results routinely included forced-fragment
identifiers in most of their results? Their results often show phrasing that
surrounds the string I wanted. But when I click on a result, I often have to
use my browser's Find function to find what the search engine already found. If
Yahoo or Google generated forced-fragment identifiers with their URLs, I'd save
a step, and Google or Yahoo would be more relevant right away. An HTML
technology that doesn't depend on content or page authors to cooperate would
allow Yahoo and Google to generate forced-fragment identifiers for most of
their results at little additional cost.

Some pages have many links embedded in the content (ignoring navbars, headers,
etc.). Some have few. It's a lot of work to add lots of tags. Some high-quality
content has few or no tags and will probably always have few or no tags. If we
insist that only authors can link from their content, HTML 4/5  suffices, but
we who read would like to be heard about someone else's work. Depending on
elements works for people who understand invisible markup, which is not most
people, or would require a browser or extension that would interpret a user's
intention by translating into element identification (such as <h4>), and that
seems complicated and very prone to the chicken-and-egg problem.
Forced-fragment identifiers, I think, are easier to implement.

In that context, the chicken-and-egg problem is not with page or content
authors. It's with a browser or extension designer, of whom only one is needed,
which makes it easier, and the standard being in HTML5 would be a reason for
someone to do that, solving the problem. Google or Yahoo wanting the facility
would speed embracing the concept across the industry.

I understand hesitating to change any well-established standard format,
including that for URLs. But I'm not sure that it's conceptually different than
changing a computer language so that comments formerly never parsed by a
compiler or interpreter are sometimes so parsed once a comment can possibly
include an executable script, even though the script-announcing string could
possibly have been used in a non-scripting comment earlier when it was legal.
(Apple used to reserve some commands for future use. Woe befell the programmer
who preempted one early. Perhaps that concept should be more widely considered
in standards-setting, as it sometimes is now.) If a double-hash might be
confusing, perhaps some other string could be proposed, although I think
problems will be least if that string were to begin with a hash.

Avoiding proprietary ownership of a functionality means avoiding a solution
that only one browser would understand, as that would force both a visitor and
a prospective visitor to have the same browser, and that would be practical
mainly if IE were that browser, unlikely if MS doesn't think there's a market
large enough to justify the financial liability inherent in introducing any new
feature. It would be better for Firefox or Opera to offer the URL-making
feature, if then IE or almost any browser could apply it to any canvas, and
then IE and others would be likelier to add URL-making.

Only two extensions are needed. One extension would make URLs by adding a
forced-fragment identifier to the URL already in the address bar, deleting any
existing non-forced fragment identifier. A menu command would be a good vehicle
to that end. If text was preselected on the canvas, good; if not, selecting the
command could bring up an alert requesting selection first, with the side
effect of keeping the command almost never dimmed, thus in front of people's
eyes. If the preselected text was very long, only its beginning would be
needed, just enough of the beginning to ensure uniqueness on the page. The user
could then edit the URL in the address bar to add more of the selection in
anticipation of possible page edits, if desired.

The other extension would recognize and extract from the URL in the address bar
the forced-fragment identifier, apply the browser's native search function to
either the canvas or the source code to find the fragment, and scroll the page
to put the found string at the top of the canvas. This seems to combine
abilities already in most major browsers, so relatively little new programming
would be required.

Dynamic or other page changes would only be a minor problem. If a string can't
be found, so be it; the user would get the top of the page. A browser maker who
wants to offer an additional bell or whistle could announce via an icon that
the fragment could not be found, in addition to giving the user the top of the
page, but that announcement would be optional, and the HTML standard wouldn't
have to specify it.

I don't think the two purposes (improving interfaces and adding hypermedia
abilities) are in contradiction and I don't think this proposal would bloat
HTML5, since it would add only a couple of lines to the standard.

I lack the time to really pursue this idea. I have to leave it to others to
decide if it's important enough to reopen this and to evaluate the browser
extension mentioned by Jeff on your blog page. Meanwhile, your blog entry
inspired the search-engine idea. Thanks.

-- 
Nick


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Saturday, 28 February 2009 04:44:30 UTC