[Bug 5744] Improved Fragment Identifiers

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





--- Comment #33 from Erik Wilde <dret@berkeley.edu>  2008-06-21 05:59:22 ---
(In reply to comment #31)
> The HTML5 draft normatively references RFC 3987 for the actual definition of
> what a fragment id is. In particular, as far as I can see, the HTML5 draft
> doesn't redefine fragment IDs nor say anyting additional about their nature
> than what is already specified in RFC 3987. The HTML5 draft simply specifies
> what UA behavior should be with respect to the fragment IDs defined in RFC
> 3987.

rfc 3987 defines the syntax for a fragment identifier. what that part means
(i.e., actually identifies) is specific for a media type and must be defined
for that media type. this can be done in either the media type registration, or
in the media type definition itself. i think those are the formal rules
regarding fragment identifiers (as i recall them).

> > i think it would be bad design to not include fragment identifiers in the html5
> > spec (in their html4 form or an improved form).
> If that is the case, and you really feel strongly about it, I suggest taking
> that to public-html list for further discussion. It's not clear to me at least
> what value there would be in the spec trying to say anything more about what
> fragment IDs actually are than what is said about them in RFC 3987. But I will
> admit that I may be missing something here.

a media type has to say what is actually identified by the string found after
the '#'. rfc 3987 only says that anything after that string is a fragment
identifier. html4 for example says "search for */@id or a/@name with that value
and that's the fragment."

> > html is a document format
> > intended for publishing and navigating hypertext, and factoring out fragment
> > identifiers into the media type registration only would send a very clear
> > message that they are regarded as add-on, and not as an integral part of the
> > spec. 
> I can't say that I agree at all with that assessment. If we were to try to
> define in the HTML5 spec itself everything that is integral part of publishing
> and navigating hypertext, we would end up with a much big spec the gigantic one
> we already have and which many in the community think is way too big as is.

i think this again demonstrates my old school hypermedia background. the key
aspects of an hypermedia system are document formats and linking, and linking
must be specified for outgoing and incoming links. to me, that really is the
very core of hypermedia, and saying that "yes, we do specify outgoing links but
we leave incoming links to a secondary document, the media type registration"
to me would look like sending a bad signal. but that's just my opinion.

> I will concede that it is a fact that there are cases where the HTML5 draft
> does actually redefine or refine definitions of some things already definined
> in other specifications. But for most of those cases, the intent at least is to
> specify how browsers actually handle those cases -- in cases where browsers do
> something different that what those other specs say they should (and there are
> a number of such cases).
> The spec for fragments IDs does not seem to be one of those cases. If browsers
> treat fragment IDs as defined in RFC 3987 then there is no value in the HTML5
> draft providing its own separate definitino of them.

there is no other spec for fragment identifiers. there is the old html4 spec,
where it is an integral part of the spec. there is xpointer, which is
unfinished and has been designed for xml. other than that, there is nothing
that could be referenced. if it is decided that fragment identifers should be
improved in html5, it must be described in html5. if they should stay as in
html4, this also must be said in html5 (or its media type registration).


-- 
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, 21 June 2008 05:59:56 UTC