[whatwg] framesets

[Michael Enright]

PB,

No matter what display method you use, it sounds like an important
requirement is to keep users from ever viewing the HTML of a row other
than from your display app/page. It seems to me to achieve this you
must not use URIs alone to fetch the row view that goes in the row's
frame, because it's likely that the URI could be observed by a bad
guy.

If someone types (somewhat fanciful example URLs here)
wget http://10.0.0.1/artfuldata/main/table7/row432
or
wget http://10.0.0.1/artfuldata/showRow?432
or whatever form of URL you use, and gets one of your row's pages,
isn't that a problem?

Otherwise, it seems that for a browser to be found compliant with
HTML5 it must render framesets in accordance with HTML5, so in that
practical sense you can still use framesets.

On Wed, Oct 14, 2009 at 8:56 AM, Peter Brawley <pb at artfulsoftware.com> wrote:
> Rimantas,
>
>>Maybe there are not many sites because nobody wants this type of sites?
>
> You think nobody wants Javadoc? Javadoc has been shipping with an read-only
> version of this use case for years.
>
> The full use case is treeview database maintenance. Tree logic has been slow
> to mature in SQL, is non-trivial in HTML as we see, and is hard to generate
> from PHP/Ruby/whatever.
>
>>I hate this type of documentation sites personally.
>
> Fine, you've no need for website maintenance of data-driven trees. That's
> not a rationale for excluding framesets from HTML5.
>
>> And to me this use case looks built around the chosen implementation,
>
> Wrong. Frameset was chosen because it provides the most efficient available
> implementaiton.
>
>> while I prefers solutions built around solving the real need.
>
> Which this is.
>
>>So you want HTML5 spec tailored for this particular case of yours?
>>Can I have <dancinghampsters> tag, please?
>
> May I have rational responses please? This is not a request for a new
> feature. I want HTML5 to continue support for useful HTML.
>
>>Nobody forbids you from using previous versions of HTML.
>
> Correct, but excluding frameset from HTML5 increases the likelihood that
> browsers will drop support for the feature.
>
> PB
>
> -----
>
> Rimantas Liubertas wrote:
>
> So it does not answer the question: if framesets are as you claim not needed
> for the full spec, there should be lots of non-frameset sites which meet
> this spec as efficiently as ours does.
>
>
> Maybe there are not many sites because nobody wants this type of sites?
> I hate this type of documentation sites personally.
> And to me this use case looks built around the chosen implementation,
> while I prefers solutions built around solving the real need.
>
>
>
> If that blocks a use case, by all means don't use a frameset for it. For
> this use, the above poses no problem at all. And if CSS were actually as
> efficient for this spec as framesets, surely some developers would have
> taken advantage of that by now.
>
>
> Once again you assume that your spec is highly desired. Maybe it is not
> the case and so nobody bothered.
>
> <…>
>
>
> No need in this case.
>
>
> <…>
>
>
> Not an issue for this use.
>
>
> So you want HTML5 spec tailored for this particular case of yours?
> Can I have <dancinghampsters> tag, please?
>
>
>
> Here's an application for framesets which is valid on previous versions of
> HTML,
>
>
> Nobody forbids you from using previous versions of HTML.
>
>
>
> meets a need, is more efficient than known implemented alternatives
> for this use case,
>
>
> You have framed (pardon the pun) this use case this way and reject all
> other options. Once again—you can use HTML4.01 frameset document
> with HTML5 documents loaded to frames. This was suggested more
> than once.
>
>
>
> and does not suffer from any of the frameset deficiencies
> you have listed.
>
>
> How so?
>
>
>
> Framesets remain useful, excluding them from HTML5
> undermines support for those uses, and that weakens HTML5.
>
>
> I'd argue that it strengthens HTML5.
>
> Regards,
> Rimantas
> --
> http://rimantas.com/
>
> ________________________________
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
>
> Version: 8.5.421 / Virus Database: 270.14.16/2435 - Release Date: 10/14/09
> 06:33:00
>
>