herenvardo at gmail.com
Fri Oct 9 17:18:41 PDT 2009
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
- 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
If you manage to do that, your proposal will be definitely be taken
much more seriously.
More information about the whatwg