Bug 17684 - Wiki documentation of Pragma directive requirements are unworkable as currently written
Wiki documentation of Pragma directive requirements are unworkable as current...
Status: NEW
Product: HTML WG
Classification: Unclassified
Component: HTML5 spec
Other All
: P2 normal
: ---
Assigned To: This bug has no owner yet - up for the taking
HTML WG Bugzilla archive list
Depends on:
  Show dependency treegraph
Reported: 2012-07-03 23:16 UTC by theimp
Modified: 2013-01-21 16:00 UTC (History)
6 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description theimp 2012-07-03 23:16:44 UTC
The HTML5 spec. (Meta/Other pragma directives) currently states:

> Extensions to the predefined set of pragma directives may, under certain conditions, be registered in the WHATWG Wiki PragmaExtensions page.

> Such extensions must use a name that is identical to an HTTP header registered in the Permanent Message Header Field Registry, and must have behavior identical to that described for the HTTP header.

This seems to be a problem, because there seems to be significant interest in “documenting reality”: put it in the wiki first, sort out conformance with the IANA later (ie. never). The argument goes that the ends justify the means; that conformance with the spec. (indeed, with any spec.) is relatively unimportant if you're a vendor, that developers are better off understanding how the real world works than how to play nice, and that documenting how to do things that you're not allowed to do is the ideal role of a specification.

The situation we have at this stage, is that people put whatever they want in the wiki, which the HTML5 spec. says is invalid (IANA registration is required before directives can be added to the wiki), but which it also says is valid (defer to the wiki for a list of valid directives).

[The preceding paragraph is, in essence, the totality of this bug.]

This might be a minor issue, except that attempts to reconcile the wiki with the spec. seem to spark edit/revert wars.

So, if the HTML5 spec. is to avoid contradicting itself, one, or both, of those requirements must change, or something else must change which will render the contradiction moot.

Apparently, there is agreement on that wiki, that this situation must indeed be resolved, and by changing this spec.; so, I have filed this bug so that the issue can be formally considered.

Possible resolutions include:

* Remove the IANA requirement requirements from that part of the HTML5 spec. Apparently dealing with the IANA “annoying”, and there is “No need to abide” with such annoyance (according to the Talk page on that wiki). Expect new pragma directives to flourish.

* Remove the wiki requirements from that part of the HTML5 spec. Just delegate to the IANA, as was done in the past. The spec. won't be wrong, but it apparently won't match reality.

* Remove all requirements from that part of the HTML5 spec. Let people check with the vendor as to what is required for compatibility with a given product, and decide for themselves what to do.

* Clarify in the spec. that non-IANA registered entries are permitted in the wiki for documentation purposes, but remain invalid for use without IANA registration. Then people can document reality all they like, while developers now have to check two registries to determine pragma validity.

* Create an additional "informative" wiki entry for adding known (invalid) pragma directives, for the purposes of documenting them. To satisfy developer curiosity, I presume, since they are invalid for use.

* Eliminate the registry, and update the spec. every time a new and important header enters widespread use (the “living document” argument).

* Do nothing, let edit wars rage on the wiki, requiring hourly updates to conformance checkers, and crush the hope out of anyone who wants to code their websites to the standard.

See also:
Bug 9530
Comment 1 contributor 2012-07-18 15:55:08 UTC
This bug was cloned to create bug 18025 as part of operation convergence.
Comment 2 Michael[tm] Smith 2012-10-22 04:58:18 UTC
I think this bug describes some valid problems, but note that Hixie has marked this resolved=later upstream. I'd suggest doing something similar for this, so we're all on the same page.
Comment 3 Michael[tm] Smith 2012-10-22 04:59:04 UTC
see bug 18025 for upstream status

Comment 4 Edward O'Connor 2012-10-23 22:46:03 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
satisfied with this response, please change the state of this bug to CLOSED. If
you have additional information and would like the Editor to reconsider, please
reopen this bug. If you would like to escalate the issue to the full HTML
Working Group, please add the TrackerRequest keyword to this bug, and suggest
title and text for the Tracker Issue; or you may create a Tracker Issue
yourself, if you are able to do so. For more details, see this document:


Status: Rejected
Change Description: No spec change.

Rationale: Let's take this up in HTML.next, as Mike™ suggests.
Comment 5 theimp 2012-10-24 11:55:20 UTC
I do not think that this is a satisfactory response.

It is of course the spec. writer's prerogative as to when and which bugs are resolved, but as stated, the spec. is contradictory and therefore unimplementable as currently written.

Any one of the many obvious solutions (most of which are semantic and not technical) would serve well enough for now, even if they are not ideal in the long term. However, I disagree strongly with not addressing this in any way at this stage, because the current state benefits no-one.

There is already evidence that, for example, validator user agents have completely refused to implement the contents of the wiki in any way, and this bug is one of many reasons why (along with other issues such as the spontaneity of updates to the wiki, and the unavailability of the wiki content as machine-readable output).

As it is already unimplemented, and there is both observed and documented dissatisfaction with the current state of the spec. by vendors, in respect of this bug, I do not think that "deal with it in the indefinite future" is acceptable.
Comment 6 Robin Berjon 2013-01-21 15:58:04 UTC
Mass move to "HTML WG"
Comment 7 Robin Berjon 2013-01-21 16:00:50 UTC
Mass move to "HTML WG"