Re: Frames links have stopped working in IE and Firefox but work in Opera

"Stevie D" <stevie@xxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:fs0af15e74tg0seo6387pceajbehl9dig1@xxxxxxxxxx
> Martin Underwood wrote:
>
>> How strange. On my father's computer and both of my computers (all XP
>> Home SP2), the links open all pages except "Historical Sources" (which
>> points to another frameset page) as full-page when viewed from the web
>> server but work fine if viewed locally. Why would the same browser
>> display the same pages differently depending on where they are being
>> sourced from?
>
> I can't think why it would. The only thing that I'm not sure about is
> the target attributes in the frameset - I've not come across these, so
> I don't know exactly how they are intended to work - but you'd think
> if FP was putting in anything dubious, the one program it _would_ work
> on would be IE...

Exactly. I'm wondering whether it's related to the revision level of the
browser. On all the 4 PCs that I've been able to try (Win XP Home, SP2 with
latest MS Windows Updates) it fails - with the exception of two older
Windows 98 PCs which have IE6 and the latest Windows Updates: those two PCs
work fine. It's something that's happened in the last month or so... and
almost certainly the site hasn't been modified in that time.

>> I'm not sufficiently familiar with all the parameters of a frameset to
>> know
>> what the significance of the 91* and the 705* is: that's how FrontPage
>> coded
>> it. The non-starred parameters are the panels which are fixed size (eg
>> the
>> height of the banner panel and the width of the menu panel), but I'm not
>> sure what the 91* is: presumably there needs to be a parameter that says
>> "there's also another panel which occupies the remainder of the browser's
>> width or height", so why should it be given a size that the browser is
>> going
>> to over-rule, I wonder?
>
> The 91 and 705 are unnecessary.
>
> The definition for framesets is fairly flexible. You can specify
> absolute values (ie, pixels) as you have done for the top and side
> bars. You can specify percentages. You can specify remainders with *
> ... and this too is flexible.
>
> You could set a <frameset cols="*,500,*"> (that's 2 stars either side
> of the 500, if your computer blends them with the quotes like mine
> does), which splits the remainder of the screen, once the 500px have
> been allocated, into two equal parts on either side.
> You can even set <frameset cols="3*,500,2*">, which puts 60% of the
> remainder on the left, and 40% on the right, of the central 500px.
>
> So if all you are specifying is one fixed-size panel and a remainder,
> all you need is, eg, "50,*" and "150,*" - the other numbers are
> superfluous.

Fine. I'll get rid of the superfluous 91 and 705. I wonder if FrontPage
assigns specific values when the frames page is initially created (with all
the panels fixed width) and then just adds a * (rather than deleting the
value) when I tell it that certain panels are variable width.

> I've just noticed something else.
>
> "This page uses frames but your browser doesn't support them".
>
> GET RID OF THAT!
>
> There is no excuse for FP putting that in the frameset page, none
> whatsoever. The site is perfectly accessible to non-frames browsers -
> what I would do is simply paste the navigation menu, shorn of effects,
> as a bulleted list into the <noframes> section - et voilà, perfectly
> accessible working site.

Yes, it is a bit draconian. I've not got any PCs with browsers that are old
enough not to support frames. I'll change to call the menu for non-frames
browsers - a bit more helpful!

> On a related note, it is a good idea to put a link to the frameset
> page, with an attribute of target="_top", on every page that you wish
> to see framed - that way, anyone who arrives at your site from a
> search engine will be able to access the site fully.
>
>> Yes, I'm not convinced that it needs the animated rollover images. My
>> father, who commissioned me to design the site, liked the effect, but
>> I'm not sure whether or not it's overkill. I think I'd still use a
>> single button image for each link rather than making it simple text,
>> because then you can get a proper button effect: underlined text as a
>> link looks a bit plain and naff these days.
>
> With judicious use of CSS, you can get terrific button and rollover
> effects, and turn off underlining. The CSS snippet I wrote would
> produce virtually the same effect as the button Javascript that FP has
> used, but in a fraction of the bytes. You would need to tinker with
> the colours, spacing etc to get the effect you want, but the bones of
> it are all there. With no images whatsoever.
>
>> I've not tried with images turned off. Would it actually display
>> "[image]" or would it use the text in the "title" attribute? I put the
>> "title" attribute in to cater for screenreaders for the blind etc and
>> for anyone who turned images off.
>
> It just displays [image]. The title attribute is applied to the link,
> not to the image, and so a browser won't link the two. Opera shows the
> title as a tooltip on mouseover, but all that appears on the page is a
> small box with "image" written in it.

I thought the title attribute related to the image. Certainly if I
deliberately delete an image jpg, the browser displays a rectangle with a
red cross and the text of the title attribute inside it. I thought the whole
point of title and alt attributes was to provide meaningful text for
non-image-enabled browsers to display in place of meaningless text "image"
(in addition to displaying it as a tooltip in mouseover).


> And yet interestingly, Lynx does use the link titles instead of
> [image]. Hmmm...
>
>> Ah. I see what you're doing here. Apart from any considerations about
>> setting the required font I can see how this would achieve the same
>> effect
>> without needing images at all, and more elegantly. I'll experiment with
>> this. Thanks for the suggestion.
>
> You can specify the font and size for these as well - although you do
> have to bear in mind that it will display differently if the user
> doesn't have your chosen font(s) installed - not that it makes a lot
> of difference, it will just have an ever so slightly different look to
> it.

Yes, I'll investigate all of this. I'm in favour of anything that doesn't
rely on images for "furniture".

> One other minor suggestion that I would make is to get rid of the
> capital letters in the filename. Unfortunately your server _is_ case
> sensitive. But people are used to typing in URLs all in lower case,
> and will often do this (as I did) even when the URL they have been
> given is mixed case. By putting it all in lower case, you avoid people
> getting 404 errors for that reason.

Hmmm! Yes, I see your point. I see how easy it is to rename the directory on
the server without having to upload the whole site all over again to make
the change.





.

Loading