RE: [whatwg] HTML5 and URI Templates

@Ian>>This might be a good time to bring the FAQ to people's attention -- it
covers what we ask people to go through when proposing new features:
>>
http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_t
o_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. 

That is an effect of your process; was that intended?  

Anyway, so please consider me to be one of the "authors and implementors"
your process refers to.

>> 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.

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

Snell>>>> FYI... I've put together a quick prototype example [1] of a html
form 
Snell>>>> using a URI Template [2].  The processing of the template is
performed 
Snell>>>> in the onsubmit event of the form.
Ian>> This is great -- why is it not enough?

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?

>> 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?

So, may I ask, who are the representatives of the browser platforms who
could give their feedback on this matter?

>> Why would scripts preclude accessibility? 

See Al Gilman excellent response.

>> And are you really expecting search engines to fill in forms that would
use templates? 

YES!!  Why would they not, if they could?

>> 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.

>> 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

>> There are many many gaps, why is this an important one to fill?

For the reasons given and because it makes URL templates declarative.

>> TBL did exactly what we're suggesting you do -- he wrote his own spec, 
wrote his own client, and wrote his own server, and put it out there. He 
didn't wait for a Standards Process to give him a stamp of approval.

And TBL worked for CERN, an organization that allowed lots of time to pursue
such interests. I instead am a working web developer and can't afford to go
off on such paths, I just need things to work better for which it has become
clear this standards process is a huge impediment.

>> Why not just provide links, or use a redirect?

Reasons already given. 

>> What if the URI you have to compute is more complicated than just
substitution, like some parts being dependent on others, or needing
calculation, or whatnot?

HTML doesn't any never will handle 100% of use-cases; that's actually one of
the things that is good about it; it forces people to deal with constraints.
Unfortunately the constraints currently in place cause web developers to
frequently create URLs that machines can easily understand but that are
foreign to most humans. Adding URI Templates would loosen those contraints
and give web developers the ability to create human friendly URLs in a more
robust manner (i.e. not requiring Javascript.)

URI Templates would be no different than HTML, i.e. it would have
constraints. Handing 90% is 90% better than we have right now.

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

HTTP handles that elegantly; 404. 

>> 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.

>> 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.

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?

>> 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?


-Mike Schinkel 
http://mikeschinkel.com

Received on Sunday, 2 November 2008 01:13:50 UTC