[whatwg] More template feedback

[Ian Hickson]

On Thu, 4 Dec 2008, Mike Schinkel wrote:
> Ian Hickson wrote:
> >
> > 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.
> 
> Nothing in HTML has ever been able to handle all potential use cases so 
> bringing this up is a red herring.  85% is far better than 0%.

Sure, but in this case it's not clear to me we're anywhere near 85%. Most 
blogs seem to use the above syntax, for instance.


> > 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?
> 
> WordPress.com, Typepad.com, Posterous.com, Vox.com, MySpace, Facebook, and a
> myriad of forums and online content sites where people publish content but
> don't control the servers.
>
> > 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.
> 
> That's because you've not been paying attention to are large segment on 
> the HTML authoring spectrum.
> 
> For example: http://support.wordpress.com/code/3/

But this also disallows <form>, so form templates wouldn't be any help 
here either.


> >>> 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?
> 
> Given the following, how would they not know what to "say?"
> 
> <form template="http://example.com/{color}/">
> <select name="color">
>   <option value="red">Red</option>
>   <option value="green">Green</option>
>   <option value="blue">Blue</option>
> </select>
> <input type="submit">
> </form>

Even I don't know what to say here, how would a search engine? Is the 
correct answer red, green, or blue?

What about for:

   <form template="/{x}/">
    <input name="x">
    <input type=submit>
   </form>

What should the search engine write in?


> > You don't have to do redirects, just support two URIs, one for the 
> > permalinks (nice URIs) one for form submissions (parsing query data).
> 
> Without redirects you get fragmentation of PageRank and the duplicate 
> content penalty.

Use rel=canonical.


> >>> 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.
> 
> That's a Red Herring anyway. The important use-cases are using 
> Select/Option and using open-ended URI (such as for search.)

For search, surely a query parameter is the right solution.

If the list of URIs is finite, then there's no need for a form. Just have 
a list of links and style it as you wish (e.g. as a dropdown).


> >>> 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.
> 
> One positive example does not support a generality.

I was just taking the example you gave, and showing that you didn't need 
templates to achieve it. It wasn't supposed to support a generality.


> >>> 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.
> 
> You are arguing that google will try to grok code in Javascript where 
> there isn't even any standard?  Srsly?

No, I'm arguing that 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.
> 
> It may be a tool but it is a tool far too many people require because of 
> the standardistas who have convinced them it is require. Your proposal 
> to "just add a custom attribute and try to get people to support it" is 
> a non-starter.

The custom attributes will validate. data-template="" is valid in HTML5.

   http://www.whatwg.org/specs/web-apps/current-work/#attr-data-*


> >>> 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.
> 
> I argue for it because you simply can't put up a form in HTML that will 
> support a templated-style URL unless you can *depend* on script and/or 
> server-side support which in many cases is not an option.

It isn't clear to me that there are enough places that allow forms but 
don't allow scripts, and that have open-ended URIs that use templates but 
that don't have a corresponding form interface, to make this feature 
important enough to add to the core language.



> How about this: Publicly state in a blog post that you have no problem 
> disenfranchising all HTML authors that cannot publish script and are not 
> in control of the servers one which they publish and I will drop my 
> opposition (btw, your insistence on using script as an alternative to 
> features spans a much wider range of disenfranchisement than just URI 
> Templates in forms.)

I do not believe that "all HTML authors that cannot publish script and are 
not in control of the servers one which they publish" will be able to use 
forms, have an open-ended URI space on which to map a form, and don't have 
a query-based solution available to them. So I don't think this is 
actually disenfranchising a great number of people.

I have no problem disenfranchsising a small number of HTML authors, 
though. If we were to support every feature everyone ever wanted, the HTML 
spec would balloon to be WAY bigger than it is even now, and none of it 
would ever get implemented correctly.

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