[whatwg] rel/rev for <form> ?

[Mike Dierken]

> >
> >  <form action="houses-for-sale.cgi" method='GET'>
> >   <input name='zip' class='gov.us/postal/zip-code' type='text' />  
> > </form>
> >
> > It would be cool to have a service that discovered these forms and 
> > then provided a search of all the URIs that accepted 
> > social-security-number, or zip-code.
> 
> I must say you came with a really interesting idea. Yes, that 
> would be good. I suppose you don't want the CLASS attribute 
> for the INPUTs to serve the purpose you've emphased. The REL 
> attribute wouldn't be good in this case. So, definitely a new 
> one is needed.
> 
> My suggestion would be to use the attribute named TAGS (yes, 
> I know it is inspired by del.icio.us and co., but ideas are 
> always welcome).
> 
> <input name='zip' tags='gov.us postal zip-code' type='text' />
> 
> Separated by spaces, working much in the same way as REL. The 
> order of the tags does not matter and these could provide 
> clues to web crawlers and even browsers on the expected 
> input. Microformats, in the same way as with REL, could 
> define various <input> tags serving various purposes. Based 
> on this, for example, a web browser could automatically 
> provide a list of known ZIP codes in the US.
I was thinking too twentieth century - using multiple values to 'tag' the
semantic meaning of the input is better than a single URI style 'unambigous'
value. As long as the syntax of the values within the 'tag' allows for URI
style 'unambigous' values, then both approaches (URI-namespaces and
folksonomy) can be used.

> 
> This would be awesome, and would provide backwards 
> compatibility, because everything else is still the same. 
> Only newer browsers could greatly enhance (when users fill 
> forms) the user experience.
> 
> Yet, this is very different from the initial proposal Charles made.
Yeah, but I couldn't resist talking about what I've hoped would come along
all these years...