I presume you are talking about current observed practice, yes? I've
checked RFCs 1738 and 1808 and find no such restriction.
> 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.
I agree with your suggestion as far as video and audio are concerned,
but not as far as images go. Some image file formats have the
capability to store multiple images, so the fragment identifier could
be used to identify an image within that object.
My platform (Acorn RISC OS) is one not supported much outside of the
UK, (primarily due to a lack of marketing budget and it not running
Microsoft software natively - although many users feel that the latter
is an advantage :-) but its primary bitmap graphics file format does
have multiple (named) sprite objects contained in it. My web browser
can pick individual sprites from the file based on the #fragment. This
was a design decision that I thought made sense, especially in light of
the multi-image support contained in GIF (this was in August 1994), and
appeared to me to be in the spirit of usage of #fragment. I also
cannot see a clear alternative to this whilst remaining within the URL
spec.
-- Stewart Brodie Dept. Electronics & Computer Science, Southampton University, UK. http://louis.ecs.soton.ac.uk/~snb94r/ http://delenn.ecs.soton.ac.uk/ <-- running on my Risc PC