- From: Mike Schinkel <mikeschinkel@gmail.com>
- Date: Sat, 1 Nov 2008 06:44:29 -0400
- To: "'Mark Nottingham'" <mnot@mnot.net>
- Cc: "'Ian Hickson'" <ian@hixie.ch>, "'Jerome Louvel'" <contact@noelios.com>, <whatwg@lists.whatwg.org>, "'URI'" <uri@w3.org>, "'REST Discuss'" <rest-discuss@yahoogroups.com>
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@mnot.net] Sent: Saturday, November 01, 2008 5:51 AM To: Mike Schinkel Cc: 'Ian Hickson'; 'Jerome Louvel'; whatwg@lists.whatwg.org; '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/
Received on Saturday, 1 November 2008 10:45:13 UTC