RE: [IUG] font size for text in search box on webpac
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Yes, thanks.
Bob Duncan from Lafayette helped me out.
Kathy
-----Original Message-----
From: innopac-bounces at innopacusers dot org
[mailto:innopac-bounces at innopacusers dot org] On Behalf Of Valentina Mayz
Sent: Monday, April 03, 2006 5:05 AM
To: 'IUG INNOPAC List'
Subject: RE: [IUG] font size for text in search box on webpac
Hi Kathy,
Did you already solve this? I looked at both your live and staging OPAC
and
couldn't see anything wrong with your font size.
Valentina
-----Original Message-----
From: Kathy Johnson [mailto:kjohnson at library dot caltech dot edu]
Sent: Friday, March 31, 2006 1:23 PM
To: IUG INNOPAC List
Subject: [IUG] font size for text in search box on webpac
Hi,
For some reason, the font size for the search boxes in our webpac has
decided to shrink, which makes the listed choices hard to read. Can
anyone
help me out in figuring out which css class is regulating the font size?
I
even tried adding a .form to the style sheet, which has an effect in
Dreamweaver but not on the web - very strange.
Katherine Johnson
Head of Metadata Resources and Services, Caltech Libraries California
Institute of Technology Pasadena, CA 91125
(626) 395-6065 -- kjohnson at library dot caltech dot edu
-----Original Message-----
From: innopac-bounces at innopacusers dot org
[mailto:innopac-bounces at innopacusers dot org] On Behalf Of Duimovich, George
Sent: Wednesday, December 14, 2005 8:47 AM
To: 'innopac at innopacusers dot org'
Subject: [IUG] WebOPAC + Dreamweaver templates..
The WebOPAC has always had critical limitations for management and
administration, not least of which is the apparent lack of support for
standards based production. It's not really that long ago that I had to
wrangle a DW template solution with the awkwardness of the "TRANSFER
Graphic
(GIF) Files Using FTS" feature (in which it was assumed that your *.gif
images didn't have the *.gif extension, etc.). We're past that, but
further
voodoo areas to figure out is how the proprietary "top secret" web
server is
actually setup, so that we can solve mysteries such why 'relative urls'
don't work as expected...
Here are two helpful hints that seem to be working well in our re-do of
our
site - currently still in "Staging" phase only (Note: thanks to Karen
Hein
@ University of Nebraska at Omaha for the base href suggestion):
Problem: I want to keep my images in a separate directory, but why do my
image links appear "broken" in certain conditions in the WebOPAC? [the
apparent solution being to dump all the images back into the root
directory
instead of in a helpful sub-directory like: /images/ ]
Tip: try this code in your template (or pages) and you should be able to
use
an /images/ sub-folder and not experience broken images (or similar
relative
URL problems):
<base href="http://serverURL/screens/" /> <link href="styles.css"
rel="stylesheet" type="text/css" />
Make sure your reference to your style sheet comes after the <base href>
code. Note that any new images or style sheet changes must be posted
first
to the server IF you want to view local html file changes via F12
command.
Problem: I want to use templates, but I can't seem to make the <body>
tag an
editable region to support the customization of the various "<body
onload=....>" variables.
Tip: you can't make <body> tag an editable region as you normally would,
but
you can make the tag attributes editable [I could have used this tip 2
years
ago!!]. A snip of code looks like this:
<!-- TemplateParam name="onload" type="text"
value="document.forms[0].elements[0].focus();" --> </head>
<!-- NOTE: check body tag for page specific instances for onLoad
parameters
-->
<body onload="@@(onload)@@" bgcolor="#FFFFFF" text="#000000">
To modify the "onLoad" parameter, select Modify >>Template Properties
and
you can reset the value to the specific search page's requirement. In
this
way, you could make the <body> opening tag sufficiently editable so that
you
can then use a template for more of your site pages, reducing the manual
tweaks you need to make before posting.
George D
BTW, I have an enhancement request (no. 2777) re: need to move away from
"proprietary web server" in case you want to support.
--- StripMime Report -- processed MIME parts --- multipart/alternative
text/plain (text body -- kept)
text/html
---
--
This message was distributed through the Innovative Users Group INNOPAC
list
Public replies: INNOPAC at innopacusers dot org Update your subscription
options:
http://innopacusers.org/mailman/listinfo/innopac
--
This message was distributed through the Innovative Users Group INNOPAC
list
Public replies: INNOPAC at innopacusers dot org
Update your subscription options:
http://innopacusers.org/mailman/listinfo/innopac