[whatwg] rel/rev for <form> ?

There is some relevant discussion on the rest-discuss forum:
http://groups.yahoo.com/group/rest-discuss/message/5423


> -----Original Message-----
> From: whatwg-bounces at lists.whatwg.org 
> [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Mike Dierken
> Sent: Sunday, November 06, 2005 12:42 PM
> To: 'ROBO Design'
> Cc: 'WHAT WG List'
> Subject: Re: [whatwg] rel/rev for <form> ?
> 
> 
> > >
> > >  <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...
>

Received on Sunday, 6 November 2005 14:08:05 UTC