9396 2010-04-03 14:10:23 +0000 Make meta http-equiv="PICS-Label" conforming 2010-10-04 14:32:26 +0000 1 1 1 Unclassified HTML WG pre-LC1 HTML5 spec (editor: Ian Hickson) unspecified PC Linux RESOLVED NEEDSINFO P2 normal --- 1 rubys ian ian mike mjs public-html-admin public-html-wg-issue-tracking public-html-bugzilla oldest_to_newest 34469 0 rubys 2010-04-03 14:10:23 +0000 As seen on IBM.com: http://intertwingly.net/stories/2010/03/21/www.ibm.com#extensibility_meta And documented on the W3C site: http://www.w3.org/PICS/labels.html 34473 1 mjs 2010-04-03 16:20:45 +0000 http://www.apple.com/ also has this. (I have suggested to the site maintainers to move it into http headers, however, I do not see a good reason for it to be invalid.) 34810 2 ian 2010-04-12 23:14:13 +0000 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: Did Not Understand Request Change Description: no spec change Rationale: How does this help users? What is the use case? 34944 3 rubys 2010-04-13 12:00:20 +0000 Use case can be found here: http://www.fosi.org/icra/ Evidence of browser support: http://blogs.msdn.com/ie/archive/2010/03/17/more-standards-documentation-available.aspx Maciej hits the nail on the head: what reason is there for this markup, which is a documented standard, deployed on high profile web sites, and implemented by tools including at least one major browser, to be labeled non-conforming? 34976 4 ian 2010-04-13 23:00:12 +0000 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: Did Not Understand Request Change Description: no spec change Rationale: The provided links did not provide clear use cases. Could you provide a simple statement explaining how PICS helps a user? If PICS doesn't do anything useful, then it would be better to let the PICS community register the value using the existing registration mechanism rather than have the spec itself mention it, since having the spec mention it would give it undue support. (I agree that there's no reason to make it non-conforming, but that wasn't what I was suggesting. There are clearly implementations and deployed uses; that wasn't challenged either.) 34982 5 rubys 2010-04-13 23:38:16 +0000 (In reply to comment #4) > > Status: Did Not Understand Request > Change Description: no spec change > Rationale: The provided links did not provide clear use cases. > > Could you provide a simple statement explaining how PICS helps a user? > > If PICS doesn't do anything useful, then it would be better to let the PICS > community register the value using the existing registration mechanism rather > than have the spec itself mention it, since having the spec mention it would > give it undue support. (I agree that there's no reason to make it > non-conforming, but that wasn't what I was suggesting. There are clearly > implementations and deployed uses; that wasn't challenged either.) I must confess that I do not understand this response. It was not my intent to give PIC "undue" support, merely to make it conforming. If there were an existing registration mechanism that would enable the markup that was already standardized, implemented, and deployed markup to be considered conforming, that would suffice for my needs. However, I have failed to find such a mechanism. Instead, I see "The http-equiv attribute is an enumerated attribute. The following table lists the keywords defined for this attribute.". Only four keywords are defined, and PICS-Label is not one of them. Nor is there a provision for defining new http-equiv attributes mentioned in the Extensibility section. Nor is such mentioned in the whatwg wiki FAQ (which I recognize is not authoritative, but does tend to be helpful). For the moment, I am not flipping the status back to REOPENed as I truly don't believe I've provided any additional information; but I will say that if there is an existing registration mechanism that enables this markup to be conforming, I will suggest that the specification make that clearer, and I will agree that that serves my purposes. 34987 6 mjs 2010-04-14 00:15:05 +0000 (In reply to comment #5) > > For the moment, I am not flipping the status back to REOPENed as I truly don't > believe I've provided any additional information; but I will say that if there > is an existing registration mechanism that enables this markup to be > conforming, I will suggest that the specification make that clearer, and I will > agree that that serves my purposes. http://dev.w3.org/html5/spec/Overview.html#other-pragma-directives I agree with you though that this could be made more clear by referring to it in other sections of the spec. 34991 7 rubys 2010-04-14 00:32:19 +0000 (In reply to comment #6) > (In reply to comment #5) > > > > > For the moment, I am not flipping the status back to REOPENed as I truly don't > > believe I've provided any additional information; but I will say that if there > > is an existing registration mechanism that enables this markup to be > > conforming, I will suggest that the specification make that clearer, and I will > > agree that that serves my purposes. > > http://dev.w3.org/html5/spec/Overview.html#other-pragma-directives > > I agree with you though that this could be made more clear by referring to it > in other sections of the spec. OK, I'm testing out the registry (in the spirit of the current status of issue 27). Should that work out, and modulo the editorial concerns about this extension mechanism not being readily discoverable in the current spec, and modulo any potential follow-on to issue-27 which moves this registration to another registration facility, I will agree that this extension mechanism serves my needs.