[whatwg] rel/rev for <form> ?
mdierken at hotmail.com
Sun Nov 6 12:41:50 PST 2005
> > <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...
More information about the whatwg