W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2009

[whatwg] Rel and META values

From: Jeremy Keith <jeremy@adactio.com>
Date: Thu, 2 Jul 2009 13:22:48 +0100
Message-ID: <EB3952B9-1EB8-46C2-80CC-BC4D0A55A557@adactio.com>
I'm a bit confused by the conditions set out at the bottom of the rel  
extensions wiki page:
http://wiki.whatwg.org/wiki/RelExtensions

"For the "Status" section to be changed to "Accepted", the proposed  
keyword must either have been through the Microformats process, and  
been approved by the Microformats community; or must be defined by a  
W3C specification in the Candidate Recommendation or Recommendation  
state. If it fails to go through this process, it is "Rejected"."

1. Should I change all of the values derived from XFN from "proposal"  
to "accepted" as they seem to fit this criteria?

2. I don't think passing the buck to the microformats community is  
necessarily a good idea. There are perfectly  good values listed (e.g.  
rel="accessibility") that would/should probably never become a  
microformat but are still good semantic values. Will they really be  
rejected outright?

Then there's the wiki page for META values:
http://wiki.whatwg.org/wiki/MetaExtensions

"For the "Status" section to be changed to "Accepted", the proposed  
keyword must either have been through the Microformats process and  
been approved by the Microformats community; or must be defined by a  
W3C specification in the Candidate Recommendation or Recommendation  
state. If it fails to go through this process, it is "Unendorsed"."

This is kinda nuts. No META value will *ever* become a microformat;  
the very concept of invisible metadata is anathema to microformats? 
it's impossible for a META keyword value to pass the microformats  
process.

Should everything on the wiki page be marked as "unendorsed" or, more  
realistically, should the conditions for acceptance be altered?

-- 
Jeremy Keith

a d a c t i o

http://adactio.com/
Received on Thursday, 2 July 2009 05:22:48 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:13 UTC