Another day, another idea: generic handling of fragment identifiers

Right now, #fragment identifiers are only interpreted for URLs that
resolve to text/html. I'd like to push forward to define some
interpretation for fragment identifiers for other media types.

First, we define that each media type in the MIME registration may
optionally define a semantics for fragment identifiers for that media
type.

Second, we define the meaning of fragment identifiers for the
media types commonly recognized by web browsers:  image/gif &
image/jpeg, video/mpeg, audio/basic, multipart/*.

For images, this might be an area which should be highlighted or
scrolled to, for video, it might be a frame range, while for audio, it
might be a time range.

Finally, we ask that browsers interact with their helper applications
as configured by passing the fragment identifier along with the data
in a standard way. (This is platform dependent, however.)

This requires a bit of work, and imposes on future MIME type
registrations to define (if desired) a semantics for fragment
identifiers, but it regularizes the use of #nnnnn for things other
than HTML.

I'd like to define the fragment identifier for application/postscript
and application/pdf as a page number or range, for example, perhaps
augmented with an offset.

Opinions?

Received on Friday, 1 September 1995 01:11:42 UTC