This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
On several places conformance of document relies on external registry which is not versioned -- it can add or remove any value at any time. This means that for frozen document its validity can change. This is unacceptable for many reasons. Each edition of HTML spec should include snapshot of such registries which can easily change over time to create more stable grounds for document conformance. This includes rel values, extensions of metadata names and extensions to pragma directives.
I strongly disagree with this. Since implementations can vary over time, conformance should vary over time too.
I agree with the original commenter. The point of document conformance is to encourage authors to do the right thing by letting them claim their page is conforming, as a reward for good behavior. If authors go to the effort of making a page conforming, they should be rewarded by having the page conform indefinitely. If authors do all that work and then overnight their pages retroactively become invalid due to some spec writers deciding some feature isn't a good idea anymore, they're going to become demoralized and not want to make their pages valid. Specifically, I propose the following approach to versioning for authoring conformance. Every X years (say two or four), declare a snapshot version of authoring requirements, maybe call it HTML 2012 or whatever. Anytime a page that was previously valid is made invalid by a spec or registry change, note in the spec or registry that it's still valid HTML 2012 (or whatever), but not later. Anytime a page that was previous invalid is made valid, make pages retroactively valid too, so authors don't have to rewrite their pages to use new features and remain valid. Then have the validator say "This is valid HTML 2012, but not HTML latest" or something. Examples: 1) In 2012, we take a snapshot of author conformance requirements. In 2013, we decide that <a name> should be made invalid. Then we change the spec to say something like: "The name attribute on the a element is not conforming in versions of HTML later than 2012. For HTML 2012 and earlier, conformance checkers must treat a nonempty name attribute on an a element as obsolete but conforming." When this spec change is made, validators will no longer say (e.g.) "This page is fully valid HTML", but instead something like "This page is valid HTML 2012", with a link you can click to see what stops it from being valid HTML. 2) In 2012, we take a snapshot of author conformance requirements. In 2017, we add a new <jack> element to support new hardware that allows users with appropriate neural implants to control their computer telekinetically, a feature that proprietary application APIs had for a few years but which was only just stable enough to add to the web platform. Pages that were already valid HTML 2012 but use the new element are still valid HTML 2012. We'd have to make sure all the registries take the same approach, making sure that they don't outright remove things but instead just mark them as being only in the appropriate old version. All this isn't urgent, though, since HTML5 is still new and imposes lots of authoring conformance changes, and not many authors seem to be tracking it yet.
(In reply to comment #2) > ... I agree with most Aryeh said. However, versioning registries may be tricky and overkill. Furthermore, registries aren't supposed to *remove* entries anyway -- at least not in the case of "we don't like this anymore". A simpler approach to deal with registries is not to make validity depend on them. It's fine to issue a warning for unregistered values, but it shouldn't be a conformance violation. Also note that having unstable conformance criteria should prevent the IESG from accepting the specification as a description of the text/html media type.
I disagree. If something is harmful, it should affect conformance retroactively.
(In reply to comment #4) > I disagree. If something is harmful, it should affect conformance > retroactively. I disagree. But to move forward. On assumption that registries in question will be reasonably managed it is very unlikely that such situation will ever appear. But it is bad in principle if conformance is depending on external resource which can constantly change and there is no trusted gatekeeper for this registry. So I still think that each published edition of HTML5 should either include snapshot of those registries or release relevant conformance criteria to allow any values.
(In reply to comment #4) > I disagree. If something is harmful, it should affect conformance > retroactively. If something was originally valid but become invalid, in most cases that should mean that it wasn't harmful originally but became harmful later, perhaps because better alternatives became reliably supported. E.g., a page written in 1996 using <font> was written according to best practices at the time, and it's harmless to leave it as-is. Authors should be encouraged to avoid <font> in all new pages, but there's no reason to encourage them to remove it from old pages that are already stable, especially since that's extremely burdensome if you have lots of pages. This is especially true because one major use of conformance checking is to gauge how knowledgeable the page author was. People who make assumptions about the quality of a page based on its conformance will be misled if it became non-conforming retroactively. You might argue that this is misuse of conformance checking, but I'd disagree: whether the author bothered to use a validator tells you something about them. Of course, none of this is to say that conformance requirements have to be absolutely set in stone. If there are outright bugs or serious oversights, those can be applied retroactively. But not stuff like "you shouldn't be doing X anymore now that there are better ways to do it".
mass-move component to LC1
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: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: The spec itself shouldn't be versioned, let alone the registries.
I believe that basing document conformance on out-of-band information is a bad idea; if others agree with this we should make this as TrackerIssue.
(In reply to comment #9) > I believe that basing document conformance on out-of-band information is a bad > idea; if others agree with this we should make this as TrackerIssue. I agree. Julian could you please make TrackerIssue. I don't have experience with this and honestly too busy now for investigating it. Thanks, Jirka
(In reply to comment #10) > I agree. Julian could you please make TrackerIssue. I don't have experience > with this and honestly too busy now for investigating it. Actually, we start with TrackerRequest (adding the keyword now).
(In reply to comment #10) > (In reply to comment #9) > > I believe that basing document conformance on out-of-band information is a bad > > idea; if others agree with this we should make this as TrackerIssue. > I agree. Julian could you please make TrackerIssue. I don't have experience > with this and honestly too busy now for investigating it. > Thanks, > Jirka Can you please "suggest title and text for the tracker issue"? /paulc
Hi Paul, would that work: Title: Document conformance has to be stable over the time On several places conformance of document relies on external registry which is not versioned -- it can add or remove any value at any time. This means that for frozen document its validity can change. Each edition of HTML spec should include snapshot of registries that can easily change over the time to create more stable grounds for assessing document conformance. Thanks, Jirka
Raised as <https://www.w3.org/html/wg/tracker/issues/187>.
Jirka, see <http://lists.w3.org/Archives/Public/public-html/2011Dec/0037.html>: A change proposal is due next weekend. Are you planning to write one?
Julian, I'm extremely bussy now, so if you have time to write one it would be perfect. If not, I will try to do my best.
(In reply to comment #16) > Julian, I'm extremely bussy now, so if you have time to write one it would be > perfect. If not, I will try to do my best. Jirka, I've got another one to take care of. You may want to ask the chairs for an extension then.
WG Decision: http://lists.w3.org/Archives/Public/public-html/2012Mar/0556.html Change Proposal: http://www.w3.org/html/wg/wiki/ISSUE-187-CP
This bug was cloned to create bug 17969 as part of operation convergence.
[HTML5 ISSUE_187] Working Group Decision applied Relaxing rules for conformance checkers, so that they don't have to fail when MetaExtensions not enumerated in the current spec are encountered. Please see the diff for details: https://github.com/w3c/html/commit/c2bc33702feb6c47fd96fcf9ce85042df2e4ba1b