[Bug 6610] New: add a preventable forced-fragment method

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

           Summary: add a preventable forced-fragment method
           Product: HTML WG
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: HTML 5: The Markup Language
        AssignedTo: mike@w3.org
        ReportedBy: Nick_Levinson@yahoo.com
         QAContact: public-html-bugzilla@w3.org
                CC: public-html@w3.org


Could you please add an ability for a user to go to a fragment even though the
fragment has not been identified by the website owner? That way, I, as an
ordinary user, could tell someone about an interesting item that's down a long
page or buried in text, by sending a link that would take the user directly to
the destination I intend.

Versions of this idea were discussed at
http://esw.w3.org/topic/HTML/DocFragPointer and as bug 5744, closed as a
wontfix largely on a question of lack of evidence for need based on lack of
evidence that workarounds are in common use or that browser makers' customer
research reveals such a need.

The need to identify a locus within a document is more likely in academic
papers and in Chinese sites, where longer pages are the norm. Scholarly
citation guides sometimes point out the problem of citing to pages in WWW
documents given inconsistencies in printout paginations. PDFs are a partial
solution since even documents without page numbering benefit from the PDF
reader's own paginations. This is also relevant to forum threads that run at
length; some fora support linking to a single post but not all do. Writing in
longhand how to go to a fragment without an author's support is feasible but
the longhand is offputting; people would rather have a link to the exact
destination and even a long URL is more convenient than a narrative
description, because it doesn't have to be remembered after one has left the
citing document, especially among people who are used to a link being all they
need to find what they want.

I suggest a double hash as the URL forced-fragment identifier to be followed by
a string from phrasing content or visible text and, even if no one has adopted
or defined the double hash as a URL element, I recommend that HTML 5 recognize
the double hash for the purpose in a draft. If the concept appears acceptable,
that may be enough to justify asking IETF or another appropriate body concerned
with URLs not to contradictorily define the double hash but to reserve it for
this purpose. I don't think there's any conflict extant.

Thus, I might send a URL such as
<http://www.example.com/directory/page.html##Further%20Reflection>. If "Further
Reflection" appears in one place on the page as it would be interpreted by a
standards-compliant browser, using that URL would take the visitor there,
possibly saving some scrolling or any need to use a Find function. If "Further
Reflection" appears twice on the page, the URL could take the visitor to the
first occurrence. If "Further Reflection" doesn't appear on the page, the URL
would take the visitor to the top of the page, as if the URL was
<http://www.example.com/directory/page.html>. If "Further Reflection" appears
only in an alt text for an image, an alt text would be treated as a destination
after those that would ordinarily appear in a browser, i.e., a visitor would be
taken to the image only if "Further Reflection" doesn't appear anywhere else
but in alt texts, thus accommodating page designs in which illustrations appear
above or before section headlines and body texts.

Two or three problems could often arise. One is a user's difficulty in forming
the linking URL especially with percent-encoding, but that could be left to
third-party tools, but that requires someone to develop a third-party tool. In
time, a browser maker or extension maker could add a menubar or contextual menu
command by which a selection in the window would be turned into a link with a
forced fragment unless forbidden by the page author, and that integration into
the browser would facilitate automatically checking source code for anything
needed to make the string successfully match later, such as finding an
invisible character and stripping markup.

A related problem is failing to correctly quote a string for the URL's
forced-fragment string, such as if a page uses a nonbreaking space the quoter
doesn't notice, but a comparable problem is in quoting from PDFs that were made
by scanning text as images or that have odd spacing and word-breaking for page
layout purposes, but, as with PDFs, selecting and highlighting text will solve
the problem often enough.

The third problem is quoting a string that actually appears as artwork, as when
a page author wanted platform-independent font choice, but in that case alt
text could fulfill the user's need, so a forced-fragment URL would be feasible
even there.

User agent designers should be advised that the browser should automatically
scroll so that the top of the fragment should be at the top of the browser's
drawing area. That would be contrary to the behavior of many browsers, which
present a found string at the bottom of the drawing area, a behavior which may
be retained for the Find function if the browser designer so wishes, but
shouldn't be applied to fragment-finding.

As a complement, the ability to block going to an unapproved fragment should be
provided, so website owners who, for example, want to ensure that every user
sees the top of a page will be shown it in their browser. In that case, the
string beginning with ## (or other forced-fragment identifier) would be
ignored, while being preserved for possible use for history or as a referer if
a user clicks on a link on the destination page. To that end, if the general
idea of forcing fragment identification is accepted, I would propose as an
optional preventer for site owners a meta element using a new keyword, e.g.,
<meta name="allow-forcing-fragments" content="false" /> (the only other value
being "true", trivial since the tag could be eliminated for true). I can add
this to the appropriate Wiki for meta tag proposals.

This responds to <http://www.w3.org/TR/html5/single-page/>, Working Draft, 12
February 2009. For Bugzilla, I selected all OSes; I develop on Win95a and 98SE
and Linux and want pages to work on whatever users use.

Thank you.

-- 
Nick


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

Received on Sunday, 22 February 2009 08:34:15 UTC