[whatwg] More template feedback

[Ian Hickson]

(trimmed cc list so that I'm not cross-posting to half a dozen lists)

On Sat, 1 Nov 2008, Mike Schinkel wrote:
> 
> If URI Templates are added I can see them be immediately incorporated 
> into CMS like Drupal, WordPress and Joomla (I use the former two so I'll 
> add it if nobody else does) and frameworks like Ruby on Rails, Django, 
> and CakePHP. Most (all?) of those frameworks use clean URLs but can't 
> use forms w/o using Javascript and URI templates would be a cleaner and 
> simplier approach that it would be crazy for people NOT to use it.

This only works if the form data is in the format you need it in. Say that 
you have a calendar-like feature -- if the server uses

   .../year/month/day/...

...as the URL form, you can't just convert an <input type=date> value into 
that URL, so you still have to have script or server-side redirection or 
some logic in the templating language -- and short of making it turing 
complete, the templating language won't ever be a complete solution.


On Sat, 1 Nov 2008, Mike Schinkel wrote:
>
> http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_the_spec.3F
> 
> In my case, unfortunately, I don't have anyone paying me to participate 
> so my own personal financial requirements don't allow me to perform the 
> exhaustive research you are requesting. By requiring that you 
> effectively disenfranchise all those like myself who are not paid to 
> participate and thus have only a limited amount of time to be involved.

As I have not always been paid to participate in the standards process, I 
can say from personal experience that it is quite possible to spend free 
time doing this if one wants to. It's not that much work.


> > Why isn't the current form submission mechanism, with a redirect on 
> > the server-side, not acceptable?
> 
> Two main reasons:
> 
> 1.) Use cases where the person writing the form is not technically in 
> control of the server and where Javascript is unavailable and the 
> percentage of places where these use-cases exist are growing rapidly 
> because of social media and content management systems.

What are the places that allow you to write forms but don't allow you to 
write scripts on either the client or the server?


> 2.) Performance best practices frown on it: 
> http://developer.yahoo.com/performance/rules.html#redirects 

Sre, that's what the scripts are for -- making it faster if possible.


> I keep saying "where Javascript is unavailable and the percentage of 
> places where these use-cases exist are growing rapidly because of social 
> media and content management systems" but you are not acknowledging. Are 
> you implicitly discrediting that as a concern, or have you missed those 
> comments of mine?

I don't see evidence that there are places that let you do forms and 
service interaction but don't let you have scripts or server-side scripts. 
Indeed, at this point writing server-side script is easy and cheap, with 
services like Dreamhost, Google App Engine, etc.


> > Because it adds significant complexity to the browser platform, 
> > without really adding new functionality.
> 
> Significant? Srsly?  Seems to me we are talking about simply a URI 
> Template variable substitution.  Since it is *easy* to do in Javascript 
> how can it be adding "significant complexity" to the browser platform?  
> It seems your two points are in direct contradiction; how are they not?

A script can implement a hard-coded conversion, it doesn't have to 
implement templating. Templates themselves are a non-trivial feature in 
terms of complexity.


> > And are you really expecting search engines to fill in forms that 
> > would use templates?
> 
> YES!!  Why would they not, if they could?

How would they know what to say?


> > Something that can't be done without the feature.
> 
> When the use-case is no access to the server and only Javascript then 
> this use-case can't be done.
> 
> When the members of the web team say NO REDIRECTs on performance 
> grounds, it can't be done.

You don't have to do redirects, just support two URIs, one for the 
permalinks (nice URIs) one for form submissions (parsing query data).


> > Something that allows authors to write applications that make users 
> > say "wow!", which they can't do today.
> 
> URI Templates in forms would make core devs on content management 
> systems and frameworks go WOW once they realized what it can empower.  
> I'm soliciting such feedback on Twitter: 
> http://twitter.com/mikeschinkel/status/985784895

The response was not overwhelming.


> > What if the user types something that isn't supported by weather.com, 
> > like the string "x"?
> 
> HTTP handles that elegantly; 404.

With all due respect, that is hardly elegant.


> > Also, why can't you just do:
> >   <form method="get" action="http://www.weather.com/search/enhanced">
> >    <input type="text" name="where"/>
> >    <input type="submit" value="Check Weather!">
> >   </form>
> 
> So obvious it hurts: Because I don't current control Weather's server 
> and they have no http://www.weather.com/search/enhanced URL.

Yes they do. Did you try it? It works just like yours would, except with 
better error-handling.


> > I don't really follow what you're saying here. I see no practical 
> > difference between URI templates and normal forms in terms of Google 
> > crawling the results.
> 
> "Normal forms?"  Google is not going to try to parse out javascript code 
> that is custom to a website nor "user added" form attributes.

No, but it can use unscripted forms today the same as it could use 
templated forms. 


> Also, adding a template attribute to a form element w/o it being in spec 
> causes it to fail validation; I thought validation was a holy grail but 
> you are instead suggesting we write HTML that doesn't validate?  Why 
> only argue for validation when it is convenient?

Validation is a tool, not a holy grail.

(If you wanted to use a script, you could use data-template="" to store 
the template. That would validate.)


> > I don't think anyone is denying that it is useful in certain cases. 
> > The question is whether it will be used widely enough to make it worth 
> > it.
> 
> What's more important; critical in 5% of cases or nice-to-have in 50% of 
> cases?

I don't understand the relevance of the question.


On Wed, 5 Nov 2008, Mike Schinkel wrote:
>
> Well said; I concur with this analysis and this goal completely. Adding 
> URI Template support to HTML forms reduces the disparity between what 
> can be done with a "website" and what must be done with an "RESTful API 
> server" per se.

It seems like you are arguing here that HTTP URIs with query parameters 
aren't RESTful, which seems like an odd position.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'