Loading ...
Sorry, an error occurred while loading the content.

11427RE: [whatwg] Proposing URI Templates for WebForms 2.0

Expand Messages
  • Mike Schinkel
    Nov 1, 2008
    • 0 Attachment
      Mark Nottingham>>despite appearances, I actually think this is a pretty good
      idea; I just am concerned about how you're going about getting it accepted.

      I can understand, appreciate and respect that. FYI I lost patience with the
      standard process a while back because it seemed that no matter my input I
      was always told "no." Since I only found frustration, I gave up.

      I'm participating again because Ian included me on a follow email on this
      issue and because I really do want to see URI Templates become part of
      HTML5. That said, I really have no idea how to go about getting things
      accepted I think because I look for what could be and it seems most
      standards people only want to see what already is?

      If it takes untold hours of time to debate and to provide exhaustive
      supporting evidence I guess I'll have to give up on the hope for this since
      I really do need to use my time to make a living and no one is paying me for
      my time to participate here.

      If you can guide me as to how to efficently get something accepted, I'm all
      ears!

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

      Yes, thanks for catching my error.

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

      First, not asking for a fully-functional web app, just for the ability to
      incorporate usable forms into an HTML fragment where Javascript is not
      allowed.

      Second, hasn't it been obvious with the explosion of social media that over
      time the vast majority of content published on the web will be published by
      people using a server they do not control? Forums, Blog hosting, Facebook,
      LinkedIn, etc. etc. etc.

      Frankly it was over the lack of appreciation for social media's use of HTML
      that I gave up on participating in the HTML5 WG. My guess is that within ten
      years >90% of HTML on the web will be published on social media services
      (including self hosted open-source apps) yet the participants in the HTML5
      WG seemed to only consider HTML published by people in control of the server
      (i.e. my "<10%") were the only valid users.

      Honestly, there really should be a focus on making sure the HTML can work in
      "fragment-mode" (i.e. where someone provides a fragment of HTML that is
      incorporated within other HTML.) That calls the question of the need for a
      <fragment> element that can contain malformed HTML w/o breaking the
      containing HTML, but that's another subject...

      BTW, don't you think the geocities reference is a bit of a low blow? ;)

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

      Plenty do but more do not, and many people on forums, blog posts and mailing
      lists recommend to others not to do so because of the performance cost. The
      cost of round trips has been used as a reason against certain web
      architectures such as in discussions of ROBOTS.TXT and 303.

      Most notably people who write about web performance optimization who happen
      to work for your employer recommend against doing so:

      http://developer.yahoo.com/performance/rules.html#redirects
      http://developer.yahoo.com/performance/rules.html#num_http


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

      "heebee-jeebees?" Srsly?

      I've been trying to, but you are dismissing my needs as unimportant. I
      really don't know how to put it in terms that you guys appreciate.

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

      What about the case where I don't have running code because we can't
      currently do it? I am trying to empower uses where people simply can't do
      things right now.

      The irony is that if TBL had gotten this kind of resistance when he tried to
      launch the web it never would have happened because he couldn't demonstrate
      an existing use-case (Oh wait a minute, he DID get this kind of resistance
      from the IETF, and it almost killed the web stillborne. Thank god it
      didn't.)

      BTW, the only person I've gotten resistance from on this besides Hixie is
      you... :)

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

      Oh I agree with that, not that it is relevant here...

      >> Try what I did with hinclude...
      >> Oh, wait, I already did that...
      >> Sure, you don't get the leverage...

      Typically when I advocate for things like this it is rarely because I want
      it for something I need to implement, it's because I believe that it could
      improve things on a broad scale. Frequently people will say "But you can
      implement it yourself by doing 'x'" which totally misses the point.

      But that misses the point; the most compelling use-cases are for where
      Javascript isn't available!

      >> 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'll agree with you completely there about not implementing something people
      wouldn't use.

      What I'm having trouble with is that the benefits to using this are so
      obvious to me that I'm having trouble understanding why they are not obvious
      to others. Using a templated URL structure vs query parameters makes URLs so
      much cleaner looking and understandable that I can't imagine people wouldn't
      flock to using this, if available.

      So would it help if I could show you numerous examples where people are
      using Javascript to accomplish this with forms? Would that be the "pain" you
      are looking for?

      That said, what about the pain of not being able to crawl forms that use
      Javascript for this? Isn't that a compelling use case?

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

      As an aside, I'd be interested in any reference you have that I can read up
      on "standard's theory."

      -Mike Schinkel
      http://mikeschinkel.com


      -----Original Message-----
      From: Mark Nottingham [mailto:mnot@...]
      Sent: Saturday, November 01, 2008 5:51 AM
      To: Mike Schinkel
      Cc: 'Ian Hickson'; 'Jerome Louvel'; whatwg@...; 'URI'; 'REST
      Discuss'
      Subject: 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/
    • Show all 25 messages in this topic