Re: [WSG] opacity as a hover for photo gallery thumbnails

2005-03-02 Thread Gunlaug Srtun
john wrote:
I know it may be unnecessary, but I'd like to put a hover on them 
anyway.  Try as I might to understand the CSS better, it's still
unclear to me how to properly put a hover on the thumbnails.  I've
tried so many things that it's a jumble in my mind now...but it seems
like if I increase the border on the thumbs (for the hover), they all
shift their position.  Other things I've tried seems to affect the
main photo itself.  I really could use some tips on this so I can
finish it.
Didn't look too much into it, but a simple hover-effect can be created
by adjusting both margins and border on hover.
1: by making the basic 3px margin into this:
margin-width: 2px 4px 4px 2px; on hover, you'll get a noticeable shift
of that particular image 1px up and 1px left, that doesn't affect the
position of any other image.
2: changing the color and/or width of the border in a similar way, on
all four sides, may also give the right effect.
Just count the total width and height of each image, with border and
margin (83px by 58px), and play around within that exact space.
The discussion list for
for some hints on posting to the list  getting help

Re: [WSG] IE: why are you so...

2005-02-28 Thread Gunlaug Srtun
Thanks a lot russ! Can I ask you (all) what do you think about my 
site? The address is .
I like it, but my Opera doesn't. :-)
Think there's a missing min-width somewhere, since the background on
the right column is pushed to the left on narrow windows.
No other problems observed.
The discussion list for
for some hints on posting to the list  getting help

Re: [WSG] Cool css box idea

2005-02-21 Thread Gunlaug Srtun
Zachary Hopkins wrote:
I've recently been fascinated by round boxes on pages.  I will have 
to wait for CSS3 to be officially released and then adopted before I
 can use the border-radius feature.
Or you can cheat a little while waiting for CSS3:
... my page is getting old...
Until then, I am experimenting with my own rounded boxes, with 
corners generated in PHP.  If you have Firefox or Opera available to
 you, please take a look and tell me what you think -
Opera: fine.
Firefox  Safari: also fine, but those two boxes will overlap on narrow
screens. I can see that those images are not optimized yet, and they're
slightly out of position on lower right corner. A bit more, and it will
come out right.
You use almost as many extra divs as I did, and have got a shadow too.
Guess the difference between yours and mine is that my boxes are still
round when images are turned off.
It's nice to play with these style-features, even if the source-code
looks a bit crappy. Hope those standards, and browsers, will catch up
with us soon.
The discussion list for
for some hints on posting to the list  getting help

Re: [WSG] accessibilty and responsibility

2005-02-10 Thread Gunlaug Srtun
designer wrote:
What exactly is the position?
Opera's zoom-feature is nice - and useful, but comes more as an addition
provided in that browser. IE6 can also zoom pages, but not that
user-friendly. We may want browsers to have useful features like this,
but that's not what we want first and most (I hope).
All the real shortcomings are more important to push for improvements
on. Like: 'standard code should work predictable in all browsers'.
That's what standard [W3C] tools should give us across browser-land,
instead of us having to counteract browser-weaknesses and bugs, and hack
our way through a maze of non-standard behavior., and similar initiatives, is one way we can
push (a little) in the right direction.
Some accessibility-features are our responsibility as web designers. We
also have to follow standard(s). But when we do, then it should at least
*work* across browser-land.
Of course: I tell everyone that Opera has the greatest features. But I
can't rely on that everyone else agrees with me, so I may have to add
'something' for those who choose Firefox too. :-)
It's OK, as long as I don't have to /hack/ it in.
Giving users a reasonable time to upgrade to the latest-- and hopefully
best-- version of the browser of their choice, and then simply
forgetting to code for the older versions, is one way we can push (a
little) where it matters. Regrettably, that's not what we usually do, so
I guess we've asked for status quo and slow progress, by debugging
browsers at our end.
The discussion list for
for some hints on posting to the list  getting help

Re: [WSG] 2 Column Symetrical Stretching Layout?

2005-02-05 Thread Gunlaug Srtun
Joey wrote:
Is it really that difficult to create a simple 2 column layout in 
CSS? Im beggining to doubt CSS if this is the case. All i need is a 2
 column layout with each column being 50% and when u stretch the 
browser each column increases (but both stay at 50%)

Here is a table version of what i am trying to acheive:

I hope some one has a solution...
Well, my old list a table doesn't fill the browser-window, but the
method is the same no matter what it is supposed to fill.
... bilingual, select language on arrival.
Maybe it's a bit more than you asked for, but there's no tables
involved - just some CSS and (x)html-elements. Simplify it and use other
elements, and you can create pretty much any table look-alike you can
come up with.
My solution is flexible within a flexible column, and it will stay just
as flexible if you recreate it on its own. The code for that part is in
the page-head-- included IE/win corrections.
(Never - ever - underestimate CSS :) )
The discussion list for
for some hints on posting to the list  getting help

Re: [WSG] Nav Before or After Main Content

2005-01-25 Thread Gunlaug Srtun
Patrick H. Lauke wrote:
Users relying on screenreaders really don't have the same choice of 
simply downloading a better browser, as the assistive technology 
would not support it...
Valid point, although it looks more and more like there's a lack of
knowledge about what's available, than a lack of choices.
Remember WCAG 1.0 guideline 10:  Use interim accessibility 
Literally, that should be covered by the solution I mentioned earlier in
this tread:
The only reason for having ordinary links for this most important
navigation at all, is that there are so many browsers that can't make
use of link-relations. So I put these ordinary most important links at
the bottom of my pages, to help out on less powerful browsers.
If I am to implement extra links _above_ the main content, I would most
likely put them inside a conditional comment for IE/win, since that
browser most likely will not support any standard solutions for many,
many, years to come. I believe most other browsers have, or will get,
the minimum support needed.
I'm open for comments on my understanding of, and solutions for, this
important issue.
The discussion list for
for some hints on posting to the list  getting help

Re: [WSG] Nav Before or After Main Content

2005-01-24 Thread Gunlaug Srtun
Mike Pepper wrote:
One thing highlighted at an accessibility site design awards ceremony
 I recently attended was the wish for developers to include a site
map link at the head jump links on all pages so non-sighted users
could immediately jump to the page and get a feel for site relevance
to search topic, especially when hitting a site - often for the first
 time - when Googling.
This is similar to responses I've got about how a group of visitors to
my site like to surf web sites - by using a separate site map.
This was requested as a key development feature by the head of the 
British National Blind Library.
Wouldn't this request be met by providing link-relations like:
link rel=home href=../index.html /
link rel=contents href=maincontent.html /
... on all pages?
I know there are browsers that doesn't make use of these, but how many
shortcomings in browsers should we cover up for - if we want them to
catch up?
The discussion list for
for some hints on posting to the list  getting help

Re: [WSG] Browser Check - such inconsistencies!

2004-12-29 Thread Gunlaug Srtun
Lori Leach wrote:
Apparently then there is nothing that I can do to keep the menu from
 breaking when you zoom as I have a fixed width design and not fluid.
 I am in a corner of sorts, as this is the layout he wants, refuses 
fluid, and this is the menu he wants. So I conclude that there is 
nothing I can do - right?
There is a lot you can do-- if you think it's worth the extra work.
That's up to you, of course, but it may pay of on a later job.
I've had a look at this one, without really looking into the code / css.
It is a fine looking page, but it is a bit weak... :-)
Fixed width isn't really a problem-- if the content can use the height
for readjustments when we zoom text of force a minimum font size.
Containers with no set height, or a min-height / IE/win height-hack set,
would take up a lot of adjustment before anything would break or overflow.
We don't use hacks to make web pages work across browserland - we use
standard css for standard-compliant browsers. Only old browsers like
IE/win is in need of hacks in most layouts. That's why many of us trim
IE/win last, when all the standard-compliant browsers presents a web
page styled as we like it.
If you use IE/win as design-default, then you should at least test with
IE's accessibility-options. IE/win can ignore your font sizes, and a web
page should survive that option since it is one of the few options
IE/win users have (although few are aware of it). It doesn't have to
look perfect though.
The same with the standard-compliant browsers like Opera, FF and Safari.
Things will have to move away from pixel-perfection when we use
text zoom options, but it's alright as long as the page can take it.
Personally I zoom text on all web pages to at least 200%, and use
minimum font size = 28px as a sort of benchmark. What font size the
page has doesn't matter all that much if it can take this test. Few
pages on the web can, and few will need to go this far.
Those two images with text on top, in the right column, can't adjust of
course, and because containers have fixed height there, the text will
overlap if I change font size too much in a standard compliant browser.
IE6 just pushes everything downwards, which at least keeps the text
readable. Improvements are possible there.
The footer has a similar, fixed, height-problem if I zoom text. In IE6
the height expands and the background-image repeats, so the text becomes
dark on dark background. In the standard-compliant browsers the text
overflows downwards. Should also be possible to improve on.
There is a strange thing with the width on that page though, as its
visible and centering part is less than 780px wide-- but it creates a
scrollbar just below 1000px width. What makes your nav-bar act strange
on text zoom is that the nav-bar expands outside the visible
page-border, and into this extra space at the right side.
If the page's real width was the same as the visible page, then the
nav-bar would adjust into two lines-- which it does if I zoom high
enough. That doesn't really break the page, and is something that is
worth looking into.
Plenty to do-- or ignore. :-)

The discussion list for
for some hints on posting to the list  getting help

Re: [WSG] Float problem in IE6

2004-12-24 Thread Gunlaug Srtun
Tatham Oddie wrote:
Im getting a float problem in IE6 that I dont understand.
The URL is
The problem is known as margin-doubling in IE/win.
display: inline will fix that in your case.
On top of that you have also made it a bit tight in there, so IE/win
will drop the main column on narrow window.
A small negative back-margin on the float will help.
For an idea of how it should display (the problem is pretty obvious)
 take a look in Firefox.
This should make it hold in IE/win, until the window gets really narrow.
Put it at the bottom of your stylesheet.
@media all {
* html div.blockRight {display: inline; margin-left: -3%;}
The discussion list for
for some hints on posting to the list  getting help