[Bug 5744] Improved Fragment Identifiers

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





--- Comment #31 from Michael(tm) Smith <mike@w3.org>  2008-06-21 05:43:08 ---
(In reply to comment #30)
> (In reply to comment #28)
> > It's also not clear that
> > HTML5 would even be the appropriate place to spec it (my personal opinion,
> > fwiw, is that it would not be).
> 
> it is part of html 4.01:
> 
> http://www.w3.org/TR/html401/intro/intro.html#h-2.1.2

We have in the years of time that the work that HTML5 has been going on
explicitly avoided using the HTML 4.01 spec as any kind of precedent for this
kind of stuff. The HTML 4.01 spec is of a completely different era, one that
occurred long before we know what we know now, and it is now widely agreed that
the HTML 4.01 spec is in no way an adequate model of proper specification for
defining HTML user-agent conformance criteria.

> it is part of the current html 5 draft:
> 
> http://www.w3.org/TR/2008/WD-html5-20080610/history.html#scroll-to-fragid

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.

> 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.

> 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 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.


-- 
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:43:42 UTC