- From: Eduard Pascual <herenvardo@gmail.com>
- Date: Sat, 10 Oct 2009 02:18:41 +0200
I have been following this discussion for many hours and it's getting tiring. In addition, it doesn't seem to be leading anywhere; so please let me suggest some ideas that may, at least, help it advance: First: you have been asking for "counter-examples" (and you have been given the MSDN one), but you haven't provided any specific example to begin with. That would make a better starting point. Second: you reject sound arguments claiming that "the use case requires otherwise", but what's your use-case? Without clearly specifying the use case, your arguments based on it aren't going to be taken too seriously: they are basically based on nothing, until you properly define the case they are supposedly based on. To specify a use-case in a way that will be taken seriously by the editor and other contributors: - Clearly define the problem you are trying to solve. When doing so, describe the problem in a way that is independent to the solution you are proposing. For example, if you look on the archives, you'll see that the use case for RDFa was often defined as "including RDF triples on webpages": this didn't work because that's not the problem, RDF is the solution. The same way, if you describe the need as "allowing <frameset> on HTML5" you won't get anywhere: that's your own suggestion to address the need, but which is the need? Make sure that your use-case addresses real-world problems. - Clearly specify and justify the requirements. Keep in mind that "because the client wants it" is not enough justification; you'd need to get an answer to "why does the client want it?". For example, if someone hired me to build a web app that takes control of the users' computer, I might come to the lists and ask for a feature to implement that, based on the point that "the client wants it": that'd be pointless and would go nowhere. Third: once you have a well-defined use-case (or ideally, several use-cases), you have a chance to get your proposal being taken seriously. To do so, specify what you are proposing: - State why currently existing solutions don't meet the requirements. As far as this has gone, the only requirements that apparently aren't met by <iframe> and other alternatives are the "break deep-linking" and "break navigation" ones. Besides of the fact that you still need to justify such requirements, that's actually easy to achieve with a bit of ugly scripting. - Describe your solution. State clearly how/why it meets each of the requirements. Also, try to describe the specific changes required on the spec. If you manage to do that, your proposal will be definitely be taken much more seriously. Regards, Eduard Pascual
Received on Friday, 9 October 2009 17:18:41 UTC