«

Jonathan N. Little wrote:
> Neil Gould wrote:
>>> Except the issues I list apply to 'frames' as well...
>>>
>> Not universally, and there are accommodations within the frames
>> model for most of the issues you've raised about iframes.
>
> Eh? Like what?
>
If you really don't know, the W3C HTML 4.0 spec is a good read, and explains
those accommodations concisely.

>> -- you don't have to know ahead of time what the size of the content
>> will be, unless your design demands it, then it isn't much of a
>> puzzle, is it?
>
> How? You must define the frames in row cols or % ahead of time.
>
Not for all frames in a frameset, you don't. And, for the case where it must
be defined, only the dimmest bulbs won't know the answer to the question.

I'm beginning to understand why you think frames and iframes are the same,
and conclude that it's best to just disagree about that and move on.

--
best regards,

Neil

Neil Gould wrote:
> Jonathan N. Little wrote:
>> Neil Gould wrote:
>>>> Except the issues I list apply to 'frames' as well...
>>>>
>>> Not universally, and there are accommodations within the frames
>>> model for most of the issues you've raised about iframes.
>>
>> Eh? Like what?
>>
> If you really don't know, the W3C HTML 4.0 spec is a good read, and explains
> those accommodations concisely.

I have read it, I think it is you that lack the understanding. Okay
let's take one of the issues that I raised for example. The stylesheet.
You cannot attach a single stylesheet to the outer frameset to
universally style the framed-assembled document. Each frame must have
its own stylesheet or reference. Unlike with server-side where the
document is assembled as a single document you can have a single
background image under all parts, where this is not an option with frames.

>
>>> -- you don't have to know ahead of time what the size of the content
>>> will be, unless your design demands it, then it isn't much of a
>>> puzzle, is it?
>>
>> How? You must define the frames in row cols or % ahead of time.
>>
> Not for all frames in a frameset, you don't. And, for the case where it must
> be defined, only the dimmest bulbs won't know the answer to the question.

Excuse me? If you have more than one frame in a frame set and to do not
define something in the rows and cols attributes ( a number for pixels,
a % of window, or a *ratio) the default is 100% and only one frame will
be visible.

<http://www.w3.org/TR/html401/present/frames.html#edef-FRAMESET#h-16.2.1.1>

"If the rows attribute is not set, each column extends the entire length
of the page. If the cols attribute is not set, each row extends the
entire width of the page. If neither attribute is set, the frame takes
up exactly the size of the page."

Don't believe me try it.

<frameset>
<frame src="include1.html">
<frame src="include2.html">
<frame src="include3.html">
</frameset>

Only include1.html will show....

>
> I'm beginning to understand why you think frames and iframes are the same,
> and conclude that it's best to just disagree about that and move on.
>

No I don't think you do. Maybe you need to do your homework.

--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com

In article <htu4ud$vm0$>,
"Neil Gould" <> wrote:

> dorayme wrote:
> > In article <htr4ve$u1k$>,
> > "Neil Gould" <> wrote:
> >
> >> dorayme wrote:
> >>>
> >>> All the best arguments against frames are exhausted in the set
> >>> that you suppose inadequate.
> >>>
> >> My issue with those arguments is that they are mostly a matter of
> >> preference, rather than of technical inadequacy of the frames
> >> element, yet they are presented as such. The same approach could be
> >> taken for any HTML element, and even more so for CSS.
> >>
> >
> > When people argue against frames, they argue on technical
> > grounds.
> >
> I did not mean to imply that *none* of the arguments are technical, hence
> the qualifier "mostly", above. Also, as I had written before, there are
> accommodations within the frames element for many of the issues presented in
> those arguments.
>

Here is a link by a former subscriber to this usenet group that
is one of the best in regard to these 'accomodations':

<http://www.markparnell.com.au/articles/frames.php>

> > I am curious to know what sort of pages cannot be presented
> > adequately without frames.
> >
> Pages where the context needs to be better controlled than one can do with
> CSS or simple HTML code.

What would be examples of such pages?

--
dorayme

Jonathan N. Little wrote:
> Neil Gould wrote:
>> Jonathan N. Little wrote:
>>> Neil Gould wrote:
>>>>> Except the issues I list apply to 'frames' as well...
>>>>>
>>>> Not universally, and there are accommodations within the frames
>>>> model for most of the issues you've raised about iframes.
>>>
>>> Eh? Like what?
>>>
>> If you really don't know, the W3C HTML 4.0 spec is a good read, and
>> explains those accommodations concisely.
>
> I have read it, I think it is you that lack the understanding. Okay
> let's take one of the issues that I raised for example. The
> stylesheet. You cannot attach a single stylesheet to the outer
> frameset to universally style the framed-assembled document. Each
> frame must have
> its own stylesheet or reference. Unlike with server-side where the
> document is assembled as a single document you can have a single
> background image under all parts, where this is not an option with
> frames.
>
To be clear, I am not claiming that one can or should do all things with
frames. But, that is hardly the same as saying that *nothing* should be done
with frames. Is not the whole idea of having various HTML elements to best
accommodate a design? If a design requires a single large background image,
then perhaps frames are not the way to go for that page. OTOH, since each
frame document is a complete HTML document, it is no real burden to refer
them all to the same stylesheet, and if the background image is a small,
repeated graphic, typical of many pages, it's no problem whatsoever to
display a continuous background.

>>>> -- you don't have to know ahead of time what the size of the
>>>> content will be, unless your design demands it, then it isn't much
>>>> of a puzzle, is it?
>>>
>>> How? You must define the frames in row cols or % ahead of time.
>>>
>> Not for all frames in a frameset, you don't. And, for the case where
>> it must be defined, only the dimmest bulbs won't know the answer to
>> the question.
>
> Excuse me?
>
I now think that it is the *misuse* of frames that has lead to your opinions
about them. We can move on to other topics.

--
best regards,

Neil

dorayme wrote:
> In article <htu4ud$vm0$>,
> "Neil Gould" <> wrote:
>
>> dorayme wrote:
>>> In article <htr4ve$u1k$>,
>>> "Neil Gould" <> wrote:
>>>
>>>> dorayme wrote:
>>>>>
>>>>> All the best arguments against frames are exhausted in the set
>>>>> that you suppose inadequate.
>>>>>
>>>> My issue with those arguments is that they are mostly a matter of
>>>> preference, rather than of technical inadequacy of the frames
>>>> element, yet they are presented as such. The same approach could be
>>>> taken for any HTML element, and even more so for CSS.
>>>>
>>>
>>> When people argue against frames, they argue on technical
>>> grounds.
>>>
>> I did not mean to imply that *none* of the arguments are technical,
>> hence the qualifier "mostly", above. Also, as I had written before,
>> there are accommodations within the frames element for many of the
>> issues presented in those arguments.
>>
>
> Here is a link by a former subscriber to this usenet group that
> is one of the best in regard to these 'accomodations':
>
> <http://www.markparnell.com.au/articles/frames.php>
>
Yes, I saw that a while back, and largely agree with Mark's statements.

>>> I am curious to know what sort of pages cannot be presented
>>> adequately without frames.
>>>
>> Pages where the context needs to be better controlled than one can
>> do with CSS or simple HTML code.
>
> What would be examples of such pages?
>
The control or disabling of bookmarking, A/B comparisons, complex relations
between page components where a static display and positioning is important,
etc.

--
Best regards,

Neil

Neil Gould wrote:
> Jonathan N. Little wrote:
>> Neil Gould wrote:

> To be clear, I am not claiming that one can or should do all things with
> frames. But, that is hardly the same as saying that *nothing* should be done
> with frames.

To be clear I did not state "*nothing* should be done with frames". I
just stated that the reasons many use to advocate for using frames
simplicity for document assembly and maintenance just are not true
compared to server-side when you have a web-server involved. Now for
local file systems where you don't have web-server or intranet
application, then *maybe* yes. Although pre-processor is a better option
in IMO. But frames like JavaScript are browser dependent and for online
web application browser-independent solutions like server-side are
superior from the start.

> Is not the whole idea of having various HTML elements to best
> accommodate a design? If a design requires a single large background image,
> then perhaps frames are not the way to go for that page.

A single large background image was only an example, colors, fonts, etc
do not apply to the individual frames, they are all independent.

<http://www.littleworksstudio.com/temp/usenet/frames>

Shows the main stylesheet does not effect the frames. You would have to
have a stylesheet for each frame. This was the management issue that I
mentioned, duplication is not efficient form of management.

> OTOH, since each
> frame document is a complete HTML document, it is no real burden to refer
> them all to the same stylesheet, and if the background image is a small,
> repeated graphic, typical of many pages, it's no problem whatsoever to
> display a continuous background.
>
>>>>> -- you don't have to know ahead of time what the size of the
>>>>> content will be, unless your design demands it, then it isn't much
>>>>> of a puzzle, is it?
>>>>
>>>> How? You must define the frames in row cols or % ahead of time.
>>>>
>>> Not for all frames in a frameset, you don't. And, for the case where
>>> it must be defined, only the dimmest bulbs won't know the answer to
>>> the question.
>>
>> Excuse me?
>>
> I now think that it is the *misuse* of frames that has lead to your opinions
> about them. We can move on to other topics.
>

Partly. But it is the basic underlying aspect that:

1) Server-side is browser-independent whereas frames are
browser-dependent, for online use browser-independent trumps
browser-dependent (JavaScript is a great example for this)

2) Server-side is not more complicated to implement than frames as many
claim.

3) With server-side true modular document assembly can be done without
having to duplicate anything. True efficiency in management and maintenance.

4) Server-side is more flexible and does not have to rely on a grid
layout as frames, so if the content changes or font size is enlarged not
scrollbars. You can also do flexible liquid layout that will work on
various devices like cell phones. Cell phones and other small devices
are now a credible component of online visitors, a trend that will not
reverse


So yes, if confronted with the two options for an online web site in
general server-side is superior and generally the better choice. You
still have not supplied a compelling reason for using frames.


--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com

Jonathan N. Little wrote:
> Neil Gould wrote:
>> Jonathan N. Little wrote:
>>> Neil Gould wrote:
>
>> To be clear, I am not claiming that one can or should do all things
>> with frames. But, that is hardly the same as saying that *nothing*
>> should be done with frames.
>
> To be clear I did not state "*nothing* should be done with frames". I
> just stated that the reasons many use to advocate for using frames
> simplicity for document assembly and maintenance just are not true
> compared to server-side when you have a web-server involved. Now for
> local file systems where you don't have web-server or intranet
> application, then *maybe* yes. Although pre-processor is a better
> option
> in IMO. But frames like JavaScript are browser dependent and for
> online
> web application browser-independent solutions like server-side are
> superior from the start.
>
I don't see frames and server-side scripting as either/or choices, and in
fact use both, frequently together.

>> Is not the whole idea of having various HTML elements to best
>> accommodate a design? If a design requires a single large background
>> image, then perhaps frames are not the way to go for that page.
>
> A single large background image was only an example, colors, fonts,
> etc
> do not apply to the individual frames, they are all independent.
>
Just as are any two or more web pages. Certainly, you're not advocating a
single web page for your entire application? That's pretty limiting.

> <http://www.littleworksstudio.com/temp/usenet/frames>
>
> Shows the main stylesheet does not effect the frames. You would have
> to have a stylesheet for each frame. This was the management issue
> that I mentioned, duplication is not efficient form of management.
>
And, just what is stopping you from referencing THE SAME style sheet for
each page in the frameset?

>> OTOH, since each
>> frame document is a complete HTML document, it is no real burden to
>> refer them all to the same stylesheet, and if the background image
>> is a small, repeated graphic, typical of many pages, it's no problem
>> whatsoever to display a continuous background.
>>
>>>>>> -- you don't have to know ahead of time what the size of the
>>>>>> content will be, unless your design demands it, then it isn't
>>>>>> much of a puzzle, is it?
>>>>>
>>>>> How? You must define the frames in row cols or % ahead of time.
>>>>>
>>>> Not for all frames in a frameset, you don't. And, for the case
>>>> where it must be defined, only the dimmest bulbs won't know the
>>>> answer to the question.
>>>
>>> Excuse me?
>>>
>> I now think that it is the *misuse* of frames that has lead to your
>> opinions about them. We can move on to other topics.
>
> Partly. But it is the basic underlying aspect that:
>
> 1) Server-side is browser-independent whereas frames are
> browser-dependent, for online use browser-independent trumps
> browser-dependent (JavaScript is a great example for this)
>
Server-side scripts still have to deliver content client-side via HTML/CSS,
and that is where things become browser-dependent. I don't see any way
around that, nor do I see that as an issue unique to frames.

(snip)

First, you were conflating frames and iframes to argue against the use of
frames, and now you're conflating server-side and client-side code. Without
HTML, server-side scripts display nothing in browsers. I don't expect to
convince you to accept frames as a practical component of HTML, and you
certainly aren't convincing or even confusing me with this kind of approach,
so, let's just move on, please?

--
best regards,

Neil

Neil Gould wrote:
> Jonathan N. Little wrote:

>> A single large background image was only an example, colors, fonts,
>> etc
>> do not apply to the individual frames, they are all independent.
>>
> Just as are any two or more web pages. Certainly, you're not advocating a
> single web page for your entire application? That's pretty limiting.
>
>> <http://www.littleworksstudio.com/temp/usenet/frames>

Apparently you are unaware of a front-end controller and templating.


>> 1) Server-side is browser-independent whereas frames are
>> browser-dependent, for online use browser-independent trumps
>> browser-dependent (JavaScript is a great example for this)
>>
> Server-side scripts still have to deliver content client-side via HTML/CSS,
> and that is where things become browser-dependent. I don't see any way
> around that, nor do I see that as an issue unique to frames.

Yes, but as far as the browser (client-side) it is one static page, with
frames the assembly is done client-side by the browser.

>
> (snip)
>
> First, you were conflating frames and iframes to argue against the use of
> frames, and now you're conflating server-side and client-side code. Without
> HTML, server-side scripts display nothing in browsers. I don't expect to
> convince you to accept frames as a practical component of HTML, and you
> certainly aren't convincing or even confusing me with this kind of approach,
> so, let's just move on, please?
>

Also apparently you do not understand the connection between frames and
iframes, nor the differences between server-side and client-side code. I
agree this is all futile.


--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com

Jonathan N. Little wrote:
> Neil Gould wrote:
>> Jonathan N. Little wrote:
>
>>> A single large background image was only an example, colors, fonts,
>>> etc
>>> do not apply to the individual frames, they are all independent.
>>>
>> Just as are any two or more web pages. Certainly, you're not
>> advocating a single web page for your entire application? That's
>> pretty limiting.
>>
>>> <http://www.littleworksstudio.com/temp/usenet/frames>
>
> Apparently you are unaware of a front-end controller and templating.
>
No, I'm not unaware of that approach, and I think it is limiting.

>>> 1) Server-side is browser-independent whereas frames are
>>> browser-dependent, for online use browser-independent trumps
>>> browser-dependent (JavaScript is a great example for this)
>>>
>> Server-side scripts still have to deliver content client-side via
>> HTML/CSS, and that is where things become browser-dependent. I don't
>> see any way around that, nor do I see that as an issue unique to
>> frames.
>
> Yes, but as far as the browser (client-side) it is one static page,
> with frames the assembly is done client-side by the browser.
>
Whether it is "one static page" depends on how the browser deals with the
new stream. Some won't update without flashing the page if they aren't
caching the repeated content, so it's still a browser-dependent approach if
presentation is driving the structural decisions.

Since you can not dispute the points I've raised about server-side code,
your assertion that I don't understand it makes no sense. As I have used a
variety of server-side technologies for more than a couple of decades, I'm
pretty sure I know what's going on, and not going on there. There is a
difference between a lack of understanding and a lack of agreement.

--
best regards,

Neil

In article <hu03c8$ilv$>,
"Neil Gould" <> wrote:

> dorayme wrote:
> > In article <htu4ud$vm0$>,
> > "Neil Gould" <> wrote:
> >
> >> dorayme wrote:
> >>> In article <htr4ve$u1k$>,
> >>> "Neil Gould" <> wrote:
> >>>
> >>>> dorayme wrote:
> >>> I am curious to know what sort of pages cannot be presented
> >>> adequately without frames.
> >>>
> >> Pages where the context needs to be better controlled than one can
> >> do with CSS or simple HTML code.
> >
> > What would be examples of such pages?
> >
> The control or disabling of bookmarking, A/B comparisons, complex relations
> between page components where a static display and positioning is important,
> etc.

Not sure I understand the last few (in relation to frames being
superior) but I note the first argument *for* frames that I am
not sure I have heard of: to make things unbookmarkable. This is
a bit bold considering it is usually considered that the breaking
of bookmarking is the strongest argument against frames!

--
dorayme