Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > HTML > Re: Converting transitional to strict

Reply
Thread Tools

Re: Converting transitional to strict

 
 
Neil Gould
Guest
Posts: n/a
 
      06-03-2010
dorayme wrote:
> In article <hu03c8$ilv$(E-Mail Removed)>,
> "Neil Gould" <(E-Mail Removed)> wrote:
>
>> dorayme wrote:
>>> In article <htu4ud$vm0$(E-Mail Removed)>,
>>> "Neil Gould" <(E-Mail Removed)> wrote:
>>>
>>>> dorayme wrote:
>>>>> In article <htr4ve$u1k$(E-Mail Removed)>,
>>>>> "Neil Gould" <(E-Mail Removed)> 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!
>

Yes, I found unrestricted bookmarking to be a curious presumption on the
part of such arguments.

As for the other examples, it turns out that frames are much better
supported by browsers for making one portion of the screen static while
another portion changes than CSS. Though this is unimportant for the
majority of web pages, there are applications where such a presentation is
desirable, and the examples are a few such applications.

--
Hope this helps,

Neil




 
Reply With Quote
 
 
 
 
Adrienne Boswell
Guest
Posts: n/a
 
      06-03-2010
Gazing into my crystal ball I observed "Neil Gould"
<(E-Mail Removed)> writing in news:hu83ts$qo4$(E-Mail Removed):

> dorayme wrote:
>> In article <hu03c8$ilv$(E-Mail Removed)>,
>> "Neil Gould" <(E-Mail Removed)> wrote:
>>
>>> dorayme wrote:
>>>> In article <htu4ud$vm0$(E-Mail Removed)>,
>>>> "Neil Gould" <(E-Mail Removed)> wrote:
>>>>
>>>>> dorayme wrote:
>>>>>> In article <htr4ve$u1k$(E-Mail Removed)>,
>>>>>> "Neil Gould" <(E-Mail Removed)> 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!
>>

> Yes, I found unrestricted bookmarking to be a curious presumption on
> the part of such arguments.
>
> As for the other examples, it turns out that frames are much better
> supported by browsers for making one portion of the screen static
> while another portion changes than CSS. Though this is unimportant for
> the majority of web pages, there are applications where such a
> presentation is desirable, and the examples are a few such
> applications.
>


One more thing that only frames can do, framesets can be resized, unless
the author has used the noresize attribute.

--
Adrienne Boswell at Home
Arbpen Web Site Design Services
http://www.cavalcade-of-coding.info
Please respond to the group so others can share

 
Reply With Quote
 
 
 
 
dorayme
Guest
Posts: n/a
 
      06-03-2010
In article <Xns9D8C43820FC5Darbpenyahoocom@81.169.183.62>,
Adrienne Boswell <(E-Mail Removed)> wrote:

> Gazing into my crystal ball I observed "Neil Gould"
> <(E-Mail Removed)> writing in news:hu83ts$qo4$(E-Mail Removed):
>
> > dorayme wrote:
> >> In article <hu03c8$ilv$(E-Mail Removed)>,
> >> "Neil Gould" <(E-Mail Removed)> wrote:
> >>
> >>> dorayme wrote:
> >>>> In article <htu4ud$vm0$(E-Mail Removed)>,
> >>>> "Neil Gould" <(E-Mail Removed)> wrote:
> >>>>
> >>>>> dorayme wrote:
> >>>>>> In article <htr4ve$u1k$(E-Mail Removed)>,
> >>>>>> "Neil Gould" <(E-Mail Removed)> 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!
> >>

> > Yes, I found unrestricted bookmarking to be a curious presumption on
> > the part of such arguments.
> >


The argument that cautions against frames is that it does not
allow natural bookmarking, which is something that is generally
desirable. It is not an argument that excludes the rare cases
where users are not inclined to pull their hair out, kick the cat
or throttle their mother in law upon finding they cannot bookmark
or use the back or forward buttons as they might be expecting.

> > As for the other examples, it turns out that frames are much better
> > supported by browsers for making one portion of the screen static
> > while another portion changes than CSS. Though this is unimportant for
> > the majority of web pages, there are applications where such a
> > presentation is desirable, and the examples are a few such
> > applications.
> >


I am not as confident as you that Jonathan Little and others
could not produce pages using includes and CSS positioning that
are well supported by browsers which appear to have a section
stay still throughout changes - without the downsides of document
frames.

>
> One more thing that only frames can do, framesets can be resized...


Yes, this has always been a neat feature (the user drags the
edges of the members of the frameset with a mouse. And sometimes
needed because, for one, I don't think you can specify frame dims
in em units and this can militate against truly fluid design.

--
dorayme
 
Reply With Quote
 
Neil Gould
Guest
Posts: n/a
 
      06-04-2010
dorayme wrote:
>> "Neil Gould" wrote:
>>> As for the other examples, it turns out that frames are much better
>>> supported by browsers for making one portion of the screen static
>>> while another portion changes than CSS. Though this is unimportant
>>> for the majority of web pages, there are applications where such a
>>> presentation is desirable, and the examples are a few such
>>> applications.
>>>

>
> I am not as confident as you that Jonathan Little and others
> could not produce pages using includes and CSS positioning that
> are well supported by browsers which appear to have a section
> stay still throughout changes - without the downsides of document
> frames.
>

Having recently converted a site to CSS that originally depended on frames
for just this purpose, I was brought up-to-date on how different browsers
rendered the box model and the viewport. It took a lot of CSS hacks to even
come close to replicating the presentation of some of those pages in
different browsers. Frames required no hacks, and both CSS and HTML can be
validated. That said, I suspect that for the vast majority of pages, one can
get "close enough" that it wouldn't matter.

Server-side code is a non-issue when it comes to this kind of presentation,
since it has no information about what is going on client-side. It's great
for dynamic content, but can't have any impact on box model rendering beyond
elementary presumptions based on header-sniffing, and that approach would
take a lot of code to do very little.

--
best regards,

Neil


 
Reply With Quote
 
dorayme
Guest
Posts: n/a
 
      06-04-2010
In article <hualgv$qtj$(E-Mail Removed)>,
"Neil Gould" <(E-Mail Removed)> wrote:

> dorayme wrote:
> >> "Neil Gould" wrote:
> >>> As for the other examples, it turns out that frames are much better
> >>> supported by browsers for making one portion of the screen static
> >>> while another portion changes than CSS. Though this is unimportant
> >>> for the majority of web pages, there are applications where such a
> >>> presentation is desirable, and the examples are a few such
> >>> applications.
> >>>

> >
> > I am not as confident as you that Jonathan Little and others
> > could not produce pages using includes and CSS positioning that
> > are well supported by browsers which appear to have a section
> > stay still throughout changes - without the downsides of document
> > frames.
> >

> Having recently converted a site to CSS that originally depended on frames
> for just this purpose, I was brought up-to-date on how different browsers
> rendered the box model and the viewport. It took a lot of CSS hacks to even
> come close to replicating the presentation of some of those pages in
> different browsers. Frames required no hacks, and both CSS and HTML can be
> validated. That said, I suspect that for the vast majority of pages, one can
> get "close enough" that it wouldn't matter.
>


Well, OK. It is always hard to get the very exact same thing,
pixel for pixel, across browsers. And we might have some vague
notion of what is acceptable leeway for best practice among
reasonable website makers. The question then is, when you do
without frames, either because you never use them or convert
existing, can we work within this leeway without frames Mostly,
I agree with you, we can.

> Server-side code is a non-issue when it comes to this kind of presentation,
> since it has no information about what is going on client-side. It's great
> for dynamic content, but can't have any impact on box model rendering beyond
> elementary presumptions based on header-sniffing, and that approach would
> take a lot of code to do very little.


Not sure I follow this. We never really know what is going on on
the user's machine. Not sure why this ignorance is an argument in
favour of frames? There is a large and useful subset of CSS that
is reliably interpreted by all modern browsers. True, some older
IE need watching carefully for misbehaviour. But note, even if
you use frames, the documents that are srcd for the frames are
just html and css and IE can just as easily muck those up - the
point is that IE will cause trouble wherever it can and frames
are not like a wooden cross to a vampire on this matter.

--
dorayme
 
Reply With Quote
 
Neil Gould
Guest
Posts: n/a
 
      06-05-2010
dorayme wrote:
> "Neil Gould" <(E-Mail Removed)> wrote:
>
>> Server-side code is a non-issue when it comes to this kind of
>> presentation, since it has no information about what is going on
>> client-side. It's great for dynamic content, but can't have any
>> impact on box model rendering beyond elementary presumptions based
>> on header-sniffing, and that approach would take a lot of code to do
>> very little.

>
> Not sure I follow this. We never really know what is going on on
> the user's machine. Not sure why this ignorance is an argument in
> favour of frames?
>

It isn't an argument in favor of frames; server-side code makes no
difference in the context of whether to use frames. The HTML is what
matters, so introducing server-side code into the discussion may be
misleading to those unfamiliar with it.

> There is a large and useful subset of CSS that
> is reliably interpreted by all modern browsers. True, some older
> IE need watching carefully for misbehaviour. But note, even if
> you use frames, the documents that are srcd for the frames are
> just html and css and IE can just as easily muck those up - the
> point is that IE will cause trouble wherever it can and frames
> are not like a wooden cross to a vampire on this matter.
>

No need to single IE out for this perspective. Other browsers do similarly
odd things with the box model and viewport. At least Microsoft provided a
method of singling out IE versions so that an appropriate and valid CSS
modifier can be applied without having to hack the main file into
non-compliance.

--
best regards,

Neil




 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: Converting transitional to strict GTalbot HTML 0 05-20-2010 04:26 AM
Re: Converting transitional to strict dorayme HTML 1 05-18-2010 11:12 PM
Re: Converting transitional to strict Beauregard T. Shagnasty HTML 3 05-17-2010 05:39 PM
Re: Converting transitional to strict Neredbojias HTML 1 05-16-2010 07:32 PM
Re: Converting transitional to strict Adrienne Boswell HTML 1 05-16-2010 06:37 PM



Advertisments