This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 10879 - Including "impossible" requirements even as a SHOULD is unnecessary
Summary: Including "impossible" requirements even as a SHOULD is unnecessary
Status: RESOLVED WONTFIX
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML5 spec (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: All All
: P3 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL: http://dev.w3.org/html5/spec/infrastr...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-09-30 17:37 UTC by Adrian Bateman [MSFT]
Modified: 2010-10-05 20:31 UTC (History)
5 users (show)

See Also:


Attachments

Description Adrian Bateman [MSFT] 2010-09-30 17:37:05 UTC
The spec states that "Conformance checkers...should also check that the input document conforms when parsed with a browsing context in which scripts execute, and that the scripts never cause non-conforming states to occur other than transiently during script execution itself. (This is only a "SHOULD" and not a "MUST" requirement because it has been proven to be impossible.)

Making a requirement a SHOULD instead of a MUST if it has been proven impossible is unncessary and should be removed. If there editor believes there is a different recommendation to be made here, it should be worded appropriately.
Comment 1 Ian 'Hixie' Hickson 2010-09-30 19:05:31 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:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: 

It's a SHOULD because it is possible to make serious inroads into implementing this requirement, it's just that there are always going to be limits to how far one can go. For example, one could execute the page and spam the page with user interaction events, while monitoring the DOM for validity. However, if a bug occurs only with particular combinations of values, it's possible that the failure case will never be reached.

So in conclusion, I think "SHOULD" is actually appropriate here, even if, as the spec says, it's impossible to do a perfect job.
Comment 2 Maciej Stachowiak 2010-10-02 04:53:05 UTC
It doesn't seem sensible to me to have a SHOULD-level requirement for something provably impossible. If there is to be a SHOULD requirement, at most it should be to do however much of such checking as is actually possible.
Comment 3 Simon Pieters 2010-10-04 06:41:01 UTC
A realistic implementation of this requirement is to have the conformance checker as a browser plugin/extension which checks conformance of the document over time while the user interacts with it. (It still cannot prove that scripts never cause non-conforming states to occur, but it can catch a non-conforming state when it actually happens for the user.)
Comment 4 Adrian Bateman [MSFT] 2010-10-05 20:31:50 UTC
The requirement could be rewritten as an author requirement so that the author should ensure that scripts don't cause non-conforming states to occur. Conformance checkers could do whatever they like to approximate this behaviour.