Re: [whatwg] Proposing URI Templates for WebForms 2.0

*sigh* we seem to be talking past each other... despite appearances, I  
actually think this is a pretty good idea; I just am concerned about  
how you're going about getting it accepted.

On 01/11/2008, at 8:16 PM, Mike Schinkel wrote:

> Mark Nottingham>>Sorry, but no. Each of those, as Ian says, can be
> implemented with a very simple server-side script. Yes, it's true  
> that this
> requires somebody to write the script...
>
> How exact can it be implemented on the server when the person  
> writing the
> HTML form is in control of the server? THAT's the primary use case.

I suspect you meant to say when that person *isn't* in control of the  
server.

If so, I've never been very swayed by the notion that people  
publishing on geocities (or twitter or whatever else is the free  
hosting / republishing provider of the moment is) should be able to  
make a fully-functional Web app using nothing but HTML and sticky  
tape; see previous discussions about the cross-site access control  
mechanism.


> In the case of someone being in control of the server it then  
> requires two
> round-trips and from what I know is that too many people priorize
> performance over everything else which means too many people simple  
> won't
> implement on their servers.

Plenty of performance-sensitive sites use redirects to implement  
various functions, and they're good enough despite their two round  
trips. Perfect, no, but good enough.


> Adding URI Templates to forms fills a large hole in the forms  
> architecture;

Using "filling a hole in the architecture" as a justification for  
doing something gives me the screaming heebee-jeebees, and I suspect  
that this attitude is why you're getting a fairly cold shoulder from  
implementers. Show them the real market need that you're filling and I  
imagine you'll get a lot more of their attention.


> Mark Nottingham>> I'm not the person to ask that, but frankly if you  
> want
> the functionality, go ahead and write the software, publish the site,
> release the browser plug-in; the standards will follow if the minds  
> do.
>
> That's a non-sequitur; that's like telling me to build a natural-gas  
> powered
> car and expect that people will buy it when in fact there are not  
> enough
> natural-gas stations available. Your suggestion that the solution is  
> to
> write a browser plug-in is about like suggesting I just pound sand  
> although
> it is a bit less insulting. :-)

I wasn't suggesting a plug-in for the cases you were talking about,  
but rather in general, if you have running code and demonstrated pain,  
asking to put something into a standard is a lot more reasonable.


> No one will use the syntax until enough people have the plugin, and  
> nobody
> will install the plugin unless enough people are using the syntax;  
> it's a
> catch-22. This type of thing is where standards are needed in advance.

That is certainly how people often try to misuse standards, yes. Just  
because something is a standard doesn't make it implemented or  
successful.

Try what I did with hinclude <http://www.mnot.net/javascript/hinclude/ 
 >; write a javascript library to handle a declarative syntax, and  
have it gracefully degrade once the browsers handle it natively. If  
the markup is declarative, it doesn't matter if it's in HTML5 or not,  
you still can cater to unintended uses.

Oh, wait, I already did that: <http://www.mnot.net/javascript/template_form.js 
 >.

Sure, you don't get the leverage of having it in a mature standard,  
but if it's truly a good idea, you'll be able to convince people to  
use it without that. The point is that you can't force a good idea on  
the market with a standard; people have to want to use it. I've said  
about as much as I can about this without starting to babble about  
standards theory, so I think I'll stop now.

--
Mark Nottingham     http://www.mnot.net/

Received on Saturday, 1 November 2008 09:51:30 UTC