[whatwg] More template feedback
(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 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: > > http://www.weather.com/search/enhanced";> > > > > > > > > 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 t
Re: [whatwg] More template feedback
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 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 , 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?"
>
> http://example.com/{color}/";>
>
> Red
> Green
> Blue
>
>
>
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:
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:
> >>>
> >>> http://www.weather.com/search/enhanced";>
> >>>
> >>>
> >>>
> >>
> >> 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; cri
Re: [whatwg] More template feedback
On Fri, 5 Dec 2008, Erik Wilde wrote: > > i think by looking at the decisions what to focus on and what to add to > html5, it is fair to say that the current html5 spec mostly focuses on > making the web a better place for browser-based applications. which is > an important and worthwhile thing to do, but it really has a specific > subset of the web in mind, and specific business models, if i dare say > so. when thinking of the interests involved, it is apparent that there > are more influential entities who are interested in a better web for > browser-based applications, whereas there are fewer major voices arguing > for the web becoming a better large-scale information system, because > this interest is not so much coupled with direct business interests of > any major player. That is indeed the focus; in fact what is now the HTML5 spec was originally called "Web Applications 1.0". > personally, i think it is unfortunate that this almost inevitably > undervalues the benefits of turning the web into a better information > system (and not just a better ajax platform), and i am wondering how the > html5 process could be tweaked to be a bit better balanced between these > two issues. HTML4 was focused on a better information system, at the cost of Web apps. HTML5 is just redressing the balance. I imagine going forward that both of these, along with other use cases, will be handled equally. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
