Re: [WSG] Absolute positioning in the flow of the document?

[Gunlaug Sørtun]

Paul Collins wrote:


http://www.method.com.au/newWebsite/

... The problem is that semantically this is not correct, the second
level here is relating to the home link and therefore should be a
sub-list contained in the  of the home link. If you look at my
example link, this is how the code appears now.


I think you've got your semantics wrong by over-complicating those 
relations, and thereby creating an (almost) unsolvable design problem. 
You can of course let your semantic reasoning control the entire design 
- change its appearance until it works, but I don't think you want that.


IMO: the second-level list doesn't/shouldn't relate to a particular 
list-item in the first-level list. Instead it does/should relate to the 
relevant _page_ itself. The links in the second-level list branches out 
to connect other pages (or sections or whatever) to that particular _page_.


This means that it doesn't really matter, semantically, where on the 
page the second-level list is, as it has no relations to any particular 
element on the page. The relevant second-level list just has to be on 
the relevant page.


The fact that you want the second-level list to appear under the 
first-level list, is perfectly understandable and reasonable - and a 
good design-choice, IMO.
You should then keep the second-level list separate, in the flow below 
the first-level one, and not complicate things any further. Your design 
is fine, and it can take whatever when you get the order right - again.


After all: semantics works best when it actually works in the real 
world. Otherwise it doesn't really make sense, IMHO :-)


regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] setting fontsize in body

[Gunlaug Sørtun]

Tee G. Peng wrote:

I got an impression that setting 100.1% fontsize in body tag is a
better approach and have been doing so for many sites. Also, with the
100.1% in the body, I usually declare .85em (.95 for my site as I
love big fontsize :) ) for paragraph and lists. I also find that I
get a more stable, closer fontsize across browsers.


I have the same experience, but I usually only set 100% - not 100.1% -
as starting-point, since the old problems that '.1' was supposed to
solve isn't there anymore. Besides, the only reason to set that
percentage as a starting-point at all, is to avoid IE's 'em sizing bug'...

...which also affects font-size keywords btw.


... I aware that Opera often makes the size a bit bigger but this is
a bit unusual for me. If I change the 62.5 to 100.1, nothing gets
change for the Tab nav in Opera, it still shows 3/4px bigger than
other browsers but the second level link text shrinks to like  4 or 5
pixel in IE, thus making it impossible to read.


I'm not aware of the latest Opera-versions having a _general_ problem
causing bigger font sizes. Haven't seen any such problems since around
version Op 7.20.
In today's version such deviations are usually caused by inheritance
through too many up and down sized wrappers, where Opera, or some other
browser, may (seem to) lose steps.
Sometimes that's caused by a a setting in a browser that is overlooked,
and sometimes it's caused by different tip-over values in browsers.
I may of course also have overlooked a genuine Opera-bug.


Client sent me this link, kind of suggesting that 62.5% is the better
 approach because his client isn't happy that now the heading texts
are too small and the paragraph texts are too big due to the changes
I made.

http://www.clagnut.com/blog/348/

What do you think?


The suggested 62.5% as starting-point is too vulnerable, IMO.

For the time being at least, the 'minimum font size' may create problems
when extremely small font-sizes are used as starting-points...


Add the effect of different, and growing, screen-resolutions - and how
browsers handle screen-resolutions differently - into the equation, and
small font-sizes as starting-points may create even more problems.

The "readable size" of different font-families shouldn't be forgotten
either, since readability _is_ the most important point, IMO.


Generally: if a document/design can take the stress from font-resizing
options in browsers reasonably well - not break too early and allow the
text to be easy to read without blowing up in the visitor's face, then
it doesn't really matter what method you choose.

I never argue against what browsers and screen-resolutions can do to my
designs when it comes to font-size, I just try to make it work well no
matter what.
Usually that means my font-sizing starts at 100% and doesn't deviate too
much from 100%, whereafter I leave to each visitor to decide what that
100% is.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] setting fontsize in body

[Gunlaug Sørtun]

Patrick H. Lauke wrote:

Ah, a misunderstanding of terminology. I thought "minimum font-size 
settings" referred to things like Firefox's preference setting for 
disallowing fonts, even when resized by the user, to fall below a 
certain fixed size...while in this case y'all seem to mean the default 
font size.


We better clear up the terminology then.

- 'minimum font size' is the user-option most browsers except IE have, 
as you describe. It works differently in those browsers that have this 
option, and the preset value varies.


- 'default font size' is most often referred to as the "medium", 
"normal" or "100%" font size, which can also be changed by the user in 
most browsers. Most browsers today also change their preset default(s) 
based on screen-DPI - one way or another.


The combination of altered 'minimum font size' and 'default font size' 
can create some interesting results for some unprepared pages with 
unnecessary complex font-sizing.



Back to Tee's problem with 'body {font-size: 62.5%}' etc in Opera/Mac. 
It may be caused by the preset value for 'minimum font size' in that 
browser/OS.
If someone can check the preset value for 'minimum font size' in an 
unaltered Opera/Mac, as I set mine to '14px' years ago and have since 
just updated it, and I can't remember the preset value. Now I can't even 
check Tee's problem, because my Mac is off-line.


Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] setting fontsize in body

[Gunlaug Sørtun]

Tee G. Peng wrote:

On Aug 3, 2007, at 8:19 PM, Philippe Wittenbergh wrote:

Unless my copy is sick, the default is 9px


Mine is 12px. I don't remember I ever altered the fontsize in Opera 
(9.22), as I only use this browser for testing.


Monitor Screen resolution: 1680 x 1050.


According to this...

... the default 'minimum font size' is '6px' for win-versions and
_'9px'_ for Mac-versions.

One reason the default may be '12px' in your version, is if you have
just updated versions and Opera has "inherited" an old setting. Most
browsers do inherit settings when updated.

I don't update Opera on windows - I install new versions separately so I
can test them properly and give them individual settings.
Unfortunately for this case I don't bother doing that on my Mac.

So, go ahead and change 'minimum font size' to '9px' in your Opera on
Mac, before further testing and discovering of unnecessary problems.


Just got an email from client, his client doesn't care the Opera, if
it can be fix with a 'conditional comment' like we treat the IE than
it's great, go ahead and do it,  if not, ignore. Which is very
unfortunately and I must admit I get discourage by this type of
attitude. It would be nice if every client can have the same attitude
toward IE :)


It would be nice if clients were *quality-minded*, but they rarely are.

FWIW: there are no "fixes" for browser-options in /any/ browser - except
in IE/win (to some degree). The only solution to font-resizing problems
is to use a font-size method that doesn't try to  override
browser-options and user-preferences.
The mentioned '62.5%' on body definitely isn't it.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] setting fontsize in body

[Gunlaug Sørtun]

Nick Fitzsimons wrote:

2. I trashed my Opera preferences and installed the latest version, 
and it has a minimum font size of 13px, which ties in with what I 
remember seeing previously.


On a brand-new, never-run Windows XP SP 2 install (gotta love 
Parallels): download and run Opera, minimum font size is 9px.


So it looks like somebody at Opera goofed, either in writing that 
document, or in not keeping it updated.


Just to check since there may also be another, so far pretty 
undocumented, variable at play here:

- does anyone know if this 'minimum font size' value changes/differs
with screen-DPI in Opera?


It is a bit problematic if a browser has undocumented
defaults/behaviors, as we cannot test based on knowledge then and the
guessing game is no fun.

On the other hand: such deviations shouldn't create any real problems if
the methods we use take the potential variables into account, and
browser-options aren't bugs designers should try to counter.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] setting fontsize in body

[Gunlaug Sørtun]

Tony Crockford wrote:
However, I do agree we shouldn't be preventing users adjusting font 
sizes.


Such a "prevention" is only relevant for IE-users who don't know how to
use their browsers to prevent such prevention from taking effect.
Actually, most pages break in IE because the designer think they can
prevent font resizing, and hasn't taken into account what happens _when_
a user know how to use IE/win (any version) to that effect.


you did once post a useful method for setting a default on body that 
allowed the use of ems, but didn't change the users browser defaults,

i can't remember what it was, though, was it set the body font-size
to medium? or just use 100%.

IE being broken requires some setting on body font-size or em sizing 
will break.


Not quite true.

IE needs the *base* font-size to be set in percentage, if we want to use
em further in without triggering the 'em font-resizing bug'...



However, that *base* can be any page-container, not just body or html.


For min/max workarounds (javascript or expressions) where IE6's internal
font-size has to be read, we _can't_ declare font-size on html or body.
Our declaration(s) will otherwise override IE's default, and return them
to our workarounds, making them useless. In such cases we have to move
our font-size *base* further in.

Example of such a case...





what's the best pragmatic approach?


My own pragmatic approach follows.

1: to declare 'font-size: 100%' on *base* (whatever element that is),
and not size down towards some conditional equalizer like the 62.5% and
then up again. The less deviation from a 100% base, the less problems
with font resizing options in browsers.


given that we can't (commercially) just let the browsers dictate font
 and font size (as times new roman at default doesn't give you many 
words per line and *is* hard to read) how best to set a font-size 
that doesn't prevent users from choosing something else.


2: to choose font-families with high readability factor regardless of
size, and make sure they don't deviate too much in readable size from
the most used font-families our text may end up as.

my view has been that those that need something special, generally 
know how to do it and those that don't either don't care or can't be 
bothered.  e.g I find white text on a dark background difficult to 
read, so rarely spend time on sites with a dark theme.  Others I know
 find black text on white harder...  flexibility and choice are the 
key surely?


3: test that the solution actually works over a wide range of existing
defaults and browser options.

4: keep on familiarizing ourselves with as many browsers, browser
options and other "smart" solutions and variables that are placed
between us and the end user, as possible, so we know what our solutions
may be exposed to.

5: accept that we can't expect to get any of our personal
design-preferences through to the end user - unaltered. There's rarely
any need to accept major breaking though - provided we have designed for
the web.


regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] display:table equal height and print style problem for Firefox

[Gunlaug Sørtun]

Tee G. Peng wrote:
[...]
Checked your perfect equal height page in IE6, there is a big gab 
between the first and second column. I don't see you have a print

style sheet but the equal height column declaration doesn't get in
the way. How come?


I use '@media screen' wrappers for existing styles, so they only work
"on screen". Browsers are using their own defaults for print, which
(generally speaking) is a lot better than most "designed" solutions.

We must override the expressions in print-styles though, as IE doesn't
respect @media when it sees expressions. That created the gaps between
"columns" for print. The fixed version is up now...



My IE7 is standalone version, the print preview doesn't work therefor
I can't test it. This is the same site that I can't show the URL, I
wonder if it's ok if I send you the page offlist again to take a 
look?


Is it up? I couldn't find any print-styles at first glance.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] display:table equal height and print style problem for Firefox

[Gunlaug Sørtun]

Tee G. Peng wrote:


A 3 column layout used the display table equal height technique



I am not going to worry the IE at this moment yet ( I understand I
can use Conditional comment for print style sheet too?), but want
to know if there is a way I can make the logo and the middle/right
columns stay in one page in Firefox. Obviously I can't declare
display:none for #outer and #inner.


#outer, #inner,#middle, #right {display: block;}
#left {display: none;}

...would be the a good print-base.

Floating should be avoided since large floating elements tends to
(still) break Gecko. That's probably why Firefox is messing it up now.

This often means CSS based column-layouts can't be (re)created for
print, which, IMO, isn't a bad thing since multi-columns running over
several printed pages doesn't make all that much sense.
Linearizing - one "column" after the other - makes a lot more sense on 
print.



Generally: you should not reuse your screen-styles for print and rely on
overriding with print-styles. Starting from scratch with a complete set
of print-styles, will usually result in less complex print-styles and
more reliable results.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] CSS Problem in Mozilla and IE6

[Gunlaug Sørtun]

Joyce Evans wrote:

http://www.nichemktghouston.com/mneiman/physician.html



So far, It looks proper in IE7, but in Mozilla, the horizontal
navigation links do not center but rather move to the right so that I
don't see the full "Contact" link.


Add...
ul {padding: 0;}
...to "zero out" Gecko's defaults on that list.

Nothing prevents that menu from getting skewed from font resizing though.


In IE 6, the pageHeader div is not stacked directly above the nav
div. There is some additional white space (from the background
color).


Add...
#pageHeader img {display: block;}
...to override the 'display: inline' default for that image.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Usability & Accessibility Over Design?

[Gunlaug Sørtun]

James Jeffery wrote:
When i said design, i was referring to the hi-end graphical content. 
The sites that are there to amaze people and go 'how did they do 
that' which is they way alot of people seem to be heading due to 
convention.


That's the "visual design" part of a visual design. Much like 'CSS Zen
garden' and with the same weaknesses as many visual designs there.
Visual design doesn't have to get in the way of overall design, but it
tends to.


A client generally knows nothing about anything, he tells you what he
 wants and expects the result. This is what im talking about. The 
clients see sites with some eye candy, and want something 'better' 
than that. If you give them a site that looks like, say the 
microformats site (which is a perfect example of the way websites 
these days should be) then there usual reply is ('Its boring, there 
isnt much to it').


Boring but informative.
You may have to add some "eye candy" - for the client, after the
usability/accessibility sides of it are in place.
Of course: too much "eye candy" may turn it into "interesting, but not
worth a revisit", but a client who knows nothing about nothing may not
be aware of - or interested in - that part.

I understand it is possible to create some amazing sites with 
usability and accessibility at the front of the line, but the only 
people that know this are people like you and me, again a client 
knows nothing and 90% of them don't care.They just want what they 
asked for. If you question why his navigation fonts are very small, 
his reply is something like ("becuase i need to fit them all on the 
one line so it dont look like the navigation is taking focus") and 
you cant really argue the point, because they dont tend to listen.


All you can say to that is: "Ok, but it can't be guaranteed to work like
that in any browser on earth, no matter who on earth creates or designs it".
You may of course be challenged to prove such a statement from time to
time, but that isn't hard if you know how browsers work.

I dont know what clients others have worked with, ive worked with 
some right nasty ones, they tell the designer onthe other end of the 
office how they want it, if you attempt to pick at it, they tell you 
there going to go elsewere, no i cant argue, ill get the sack.


It's definitely hard to argue about quality under such circumstances.
Making a living in web design can be hard, and it isn't the browsers and
their bugs and limitations that add most to the workload.

Again, you may have to add some "eye candy" - for the client, after the
usability/accessibility sides of it are in place.


Tis why i said, if there was a law the client would have no choice.


Laws may easily act as limitations on an open web, so I don't think
there should be anything but sensible guidelines.
OTOH: there's no laws against creativity on top of a solid "canvas"
either...

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] When is invalid CSS okay?

[Gunlaug Sørtun]

Rick Lecoat wrote:


So, is it considered 'okay', in a web standards sense, to have a non-
 valid "bug-fixes" stylesheet working alongside your perfect, 
pristine, uiber-valid main stylesheet?


It is considered "bad, but necessary and therefore acceptable" by most
web designers/developers.

To give an example, if I were to have an IE-specific stylesheet with 
a lot of stuff like filter: alpha(opacity=50) in it -- which, a quick

Google check informs me, does not validate -- would that be seen as a
breach of web standards?


It _is_ a breach of web standard, so some may see it as a "sin" :-)

However, since there's no other real-world option in many cases, you may
as well add the non-valid part to your pristine CSS and "confess" openly
to having done so. An ordinary CSS comment may make most reasonable web
designers/developers see the light, and make them defer from further
comments on the issue.

Perhaps this whole issue is me getting too focused on the nitty 
gritty, but I'm in the process of moving from 'old-school' to web 
standards and am trying very hard to get it 'right'. This is just one

 of the goal posts that I'd like to clearly identify.


- If there are valid and logical options, then non-valid solutions
should be avoided.
- If no valid and logical options are available, then the _logical_
thing to do is to make it work if at all possible - choosing the most
reliable workaround for weak standard-support and browser bugs, even if
validity suffers a bit.

Whether we separate the valid from the valid parts by using separate
stylesheets, or simply leave the non-valid parts "in the stream",
depends mostly on the local workflow and personal preferences.

'Conditional comments' for IE versions provides us with a practical
separation-solution, but the hiding-effect (that the validator can't see
the separate and non-valid workaround) doesn't make the non-valid
workaround more valid. Thus, my personal preference is *not* to use
'conditional comments' unless there's no other way to achieve separation
and prevent other _browsers_ from being disturbed by the non-valid
workarounds. I see no point in "hiding my sins", although I daily hide
lots of IE garbage as a result of the separation-process itself.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] When is invalid CSS okay?

[Gunlaug Sørtun]

Rick Lecoat wrote:

[..] However, I'm curious about why your personal preference is for 
NOT using Conditional Comments; you seem to equate them with trying 
to hide embarrassing non-valid code, and I'm sure that some designers

 might use them for that.


The "hiding" effect gained by 'CC' is used by many to justify hacking
and to declare their solutions valid - because the validator doesn't
complain.
To me, such "valid" claims are nonsensical, and cloud the issue that we
_have to_ hack our way around IE weaknesses one way or another.
To me, a working hack to make IE behave isn't embarrassing at all,
although it may be embarrassing for the creators of that browser.

The real reason for me to not use 'CC' for separation, is that the
versioning goes on on HTML level and adds unnecessary garbage to every
single page.
I prefer to separate on CSS level so the amount of garbage is kept to a
minimum, and so that I can limit creation and updating of workarounds to
a few lines in a stylesheet.


Most often I just add the necessary workarounds in the main stylesheets
- and just test to make sure the workarounds don't disturb other
browsers. This works for all browsers - with a bit of care.
The fact that the validator flags non-valid workarounds is a real
time-saver during upgrading, as I don't have to comment these
workarounds in order to find them later on.

At times I use IE's own CSS bugs to feed it a "fake" stylesheet while
feeding non-IE browsers a real stylesheet. This is true separation.
This method does indeed hide both valid and non-valid workarounds for IE
from the validator - same as with a 'CC', but this "hiding" effect can't
be avoided and I can live with it :-)

The latter method is described here...

...and is used throughout that private site. I won't recommend this
method, but it works just fine - with a bit of care.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] When is invalid CSS okay?

[Gunlaug Sørtun]

Rob Crowther wrote:

Gunlaug Sørtun wrote:
The "hiding" effect gained by 'CC' is used by many to justify 
hacking and to declare their solutions valid - because the 
validator doesn't complain.


It is ultimately laziness, but I don't want to have to expend the 
mental effort to distinguish between invalid CSS that is the result 
of a mistake and invalid CSS that is the result of hacking around IE.

 Or put another way, I don't want to get into the habit of being used
 to seeing my CSS not validate with the automatic test.


Well, since "valid" doesn't mean "applied according to standard", I have
to proofread my CSS anyway. I can't rely on the validator more than on
the spell-checker in the email client I use, so I do indeed distinguish
between "mistakes" and "intentional hacking" - regardless of whether the
latter are valid or not.

It would be nice if the validator would flag "nonsensical" combinations
of properties/values, so I could see at a glance where combinations like...
Element {
float: left;
margin: 6px;
display: inline;
}
...have been used, since "valid" combinations like that only serve the
purpose of killing an old browser bug. The usefulness of the validator
reports would be so much greater then.


This works for all browsers - with a bit of care.


I assume here you mean 'all current major desktop browsers'?


One has to draw the line somewhere, but I often check beyond the "major
desktop browsers" if I apply one of the potentially more disturbing
workarounds. How far I go depends on the case, the major user-group and
the client.
Whether or not a "disturbance" is acceptable, also depends on how
"standard compliant", implicit also how "current", the "disturbed"
browser is. That outweighs how "major" a browser in need of a workaround
is - in most cases.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Investigating the proposed alt attribute recommendations in HTML 5

[Gunlaug Sørtun]

Designer wrote:


[...] there is such a thing as a site whose prime function is visual.
 The only 'information' in the site I mentioned is what something 
'looks like'.  If you can't see it, there is nothing  you can do to 
help that.


Sure you can.
Being unable to see something doesn't mean "unable to visualize".
In fact, it may be the seeing who are less able to visualize - resulting
in missing cues, and missing or non-descriptive alt-attributes, for the
non-seeing to visualize on.

I'm deliberately not focusing on blind people, because they are just
part of the group that for one reason or another is unable to "see"
what's presented on a web site.
To me it is especially important to provide non-visual cues when a
site's prime function is visual - not necessarily so when the visual
side of a site is less important.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Font sizing: top down or bottom up

[Gunlaug Sørtun]

Rick Lecoat wrote:

This bring into question the advice of the W3C tips page www.w3.org/QA/Tips/font-size#goodcss> where it states: "1em (or 100%)
 is equivalent to setting the font size to the user's preference". 
The above statement makes the implicit assumption that 'Browser 
Default' equals 'User's Preference', an assumption that I can't help 
but question.


Me too. However, any assumption made by a designer that 100% does *not*
equals 'User Preference', is just as questionable.

The majority of 'Accessibility users' (for want of a better term) 
will, by contrast -- assuming that they use browsers at all -- have 
their default settings tuned to their preferences, and will be 
reasonably aware of how such settings are altered. Many will have a 
large minimum font size specified, and/or be using IE's facility to 
ignore any font size settings specified by the page.


Probably true. How many who know how to, and actively use, such browser
options, is unknown.

We do however know that the number of users who need to know and
actively use such browser options, is growing with the number of elderly
people on the web.
This need is to a large degree caused by the general use of small text,
which is based on designers' assumption that default size is too large.

What we get is a "perfect" circle of compensations for imposed
compensations, and the only somewhat reliable middle-ground is found at,
or close to, 'font-size: 100%'.

Accessibility is generally not improved by *not* declaring font-size
anywhere, but by averaging it for the users we want to reach and letting
size depend on readability and importance. Headlines should for instance
be larger than paragraph-text in most cases, but _much larger_ doesn't
necessarily help anyone.

If the designer has assumed that people who like smaller type sizes 
will adjust their browser settings accordingly, he or she will 
probably be disappointed much of the time.


Nevertheless, it is undeniably true that some people (myself 
included) feel that 16px text is /slightly/ too large from a 'design 
aesthetic' viewpoint [3].


My experience is that the average designer don't really _read_ stuff in
his/hers own creations, so "design aesthetic" viewpoints don't mean much
(to me) when it comes to what font-size to use.

This being the case, clearly /someone/ is going to be doing some 
resizing of text when they visit your page -- whether it is the 
person with perfect vision scaling things downward, or the person 
with accessibility issues scaling things up.


The most used rescaling seems to be "permanent change of screen
resolution to suit the smallest text each user wants to read".
This means everything, on every web site, gets scaled to suit the user's
preferences on his/her screen(s). This in turn affects how much real
estate is available to designers, as browser-windows can't be larger
than the actual screen and we know that few users like to scroll
horizontally.

Again: what we get is a "perfect" circle of compensations for imposed
compensations...

If I used that "rescaling" method, web sites would be left with around
600px window-width to display their stuff on on my screens. Since I
don't, I can offer sites 3800px window-width if needed. My set-up and
use of options are not representative though.

Would a Bottom Up approach not have more chance of giving everybody 
what they want to see?


Since that's what end-users has become used to by now because of all the
"compensations" that have flooded the web over the last 15 years or so,
you're probably (more or less) right.

It is not an ideal solution though, but I can't think of a "one size
fits all" solution other than that I personally tend to "size" close to
"average" = 100% = defaults when I have a say on the issue (as you have
probably already noticed over at [css-d] :-) ).

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Font sizing: top down or bottom up

[Gunlaug Sørtun]

Jixor - Stephen I wrote:
Wouldn't all those heading sizes would look fairly similar, 
especially 102%?


Indeed, but those are the sizes I found suitable for my own site, and I
have only *suggested* (over at css-d) those values for use on other
sites - as part of a method for inheriting font-sizes down the entire
chain of containers in a web page.

Designers should of course choose the values that suits their particular
designs, and that was made clear in the thread that suggestion is copied
from.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Font sizing: top down or bottom up

[Gunlaug Sørtun]

Jixor - Stephen I wrote:
Sorry, the point I'm making is why use 100 and 102, is there any 
visible difference?


Normally not, and 100% is the intended size. The reason for the
"slightly more than 100%" for h5 is that whatever the size 102% is
calculated from the h5 should end up _as large as or 1px larger_ than
the paragraphs (or whatever) its heading.

I would have thought the user would need to have a massive default 
font size to see any. However I have noticed myself that the way the 
browsers tend to size fonts can be quite strange. Sometimes a change 
of 5% in scaling can result in the same font ending up the same size 
however notably wider.


Exactly.

The particular layout it's used in don't have 100% font-size for all
containers all the way down the chain, and the "tip-over" changes when
sized down font-size on containers are subjected to resizing and used as
base for font-size on text-carrying elements - sometimes splitting
between 100% and 102%.

My entire site is used as a test-bed. I have hundreds of those "hardly
ever noticeable effects" baked in on my own site as part of continuous
testing of browsers, in the knowledge that browsers don't handle minute
differences exactly the same way.

The differences _I_ can then observe, will not disturb or distract a
visitor - unless that visitor (maybe a web designer) has particular
interests in why something looks slightly different in two browsers
under certain conditions.

I have received a few comments about such subtle differences over the
years, from fellow designers assuming I've gotten my values wrong.
That's great, as they are either confirming my own observations, or
informing me about something I haven't observed yet in a particular
browser under certain conditions. All good to know while I try to expand
my knowledge on how User Agents handle my work.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Font sizing: top down or bottom up

[Gunlaug Sørtun]

Tony Crockford wrote:
I'm still looking for a best practice solution to reducing font size 
to the *norm* and not causing problems when I do so.


The most cross-browser reliable method is to declare 'font-size: 100%'
as base, and size *down* _only_ on the text-carrying elements.

This approach let all container-elements inherit the base directly,
which means 100% = 1em = default = 'chosen or unchosen user preferences'
everywhere but on text. This will in most cases make it a lot easier to
size all elements to line up as intended relative to all others even
when 'em', '%' and 'px' is used in the element-size mix, than if each of
the container-elements rely on intermediate deviations from base font-size.

An added advantage is that text doesn't get unintentionally and
unnecessarily blown up in some browsers, because of how they apply
'minimum font size'. Call it browser-bugs or whatever, but too many
sites break under the slightest stress simply because they adjust
font-size _up_ from base (which usually is body) rather than down.


Once your font-size issue is solved in a way that makes it technically
able to take font-resizing well, then there's not much more you can do.
The need for font-resizing and how to achieve it, is for the end user to
decide on and solve, and your responsibility ends once you have made
absolutely sure _your_ solution doesn't prevent _them_ from using
_their_ software to resize.

The only way to make sure your method is not causing any unsolvable
problems at the user-end, is to test across browsers and browser-options
until breaking-point and a bit beyond. You should ideally know more
about how your solution behaves and how much stress it can take, than
any end user.
However, there's no way you can prevent a user from breaking your
well-prepared solution by adding a particularly nasty user-stylesheet,
so you can quietly limit your testing to the more ordinary, selectable,
browser-options.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Investigating the proposed alt attribute recommendations in HTML 5

[Gunlaug Sørtun]

Designer wrote:


http://www.nga.gov/feature/rothko/classic1.shtm.



Using this arbitrary example, I still maintain that a site of  images
 such as any of these will be of no more value to a blind user for 
having alt tags, other than to point out  that 'there is a picture 
there'. Of what, the blind user has no idea because they are 
impossible to describe.


You're arguing as if a site, or the web as a whole for that matter,
exists in isolation. The 'label' you mention in the part I've left out,
may indeed be just the cue a visitor need. More information can then
either be found on the page/site, somewhere else on the web, or in the
real world.

By providing cues - meaningful alt text and/or otherwise - about the
original, a suitable "translation" can often be found elsewhere by those
who want one.
By not providing cues, we do indeed leave visitors in the dark.

( The site you use as example, contains more than enough information
alongside the image. A reference - alt attribute - to tell _which_ image
that information belongs to is missing though.
Several other weaknesses on that example-site btw - all regarding images. )

There are art galleries that experiment with techniques to make art -
paintings or other types of art - more accessible to those who can't
fully use the senses the artist aimed at. Some of these techniques are
well suited for the digital world, but I don't think they have spread to
the web, yet.

Will something get lost in "translation"? Surely it will. However, that
doesn't mean a blind user is necessarily left with no idea.

Blind people's senses may also be developed far beyond what we - the
seeing - may imagine.
I do have a friend who can interpret flat images pretty well by the use
of her hands. She is sensing differences in reflected temperature,
instead of reflected light that most of us are limited too. That she
also tends to get the use of colors more or less right, is even more
surprising. Given a few more cues she gets a pretty good understanding
about most pictures.
This just to say: don't underestimate people's ability to appreciate
something, just based on what senses they do *not* have.

Alt attributes should stay - be required in HTML 5, and they should be
used in a meaningful way. What's meaningful depends on the case, but if
images are important parts of the content then an alt text should be
provided - even if it is just a 'label'.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Investigating the proposed alt attribute recommendations in HTML 5

[Gunlaug Sørtun]

Designer wrote:


I think we are just splitting hairs now.


I agree (to a degree), but I wanted to "paint it out" with a smaller
brush :-)

a) I personally do use alt tags, every time :  (In other words, I 
agree with you in principle)


Principles are good when aiming for "best practices", but are worth next
to nothing to the many who don't study (or care about) "best practices"
if those principles aren't at least (going to be) backed up by a
"standard" and can (to some degree) be checked automatically.

To (too) many the word "optional" means "not worth bothering about",
even if that's *not* the meaning given in the suggestion regarding alt
attribute for HTML5.

b) but I am aware of situations where they are pretty useless. (In 
other words I know their limitations in certain cases and can see why

 it is being suggested that they are 'optional'.


Personally I can't see any case where the alt attribute is completely
useless, but I definitely can see lots of cases where it in itself falls
short of solving the problems related to "alternative description of an
image".

We do have some optional additions to the alt attribute in existing
standards, but their use are not all that well defined, and they are
rarely used - maybe because they are, and have to be, optional.

So, I don't want the alt attribute to become optional just because we
don't have good solutions for its shortcomings, or the way it is used /
misused / not used, at the moment. Instead, we need to look for better
solutions, and they may even be based on progress in any field made
between now and the time HTML5 can be put to use.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Investigating the proposed alt attribute recommendations in HTML 5

[Gunlaug Sørtun]

Michael Yeaney wrote:
I find it interesting that everyone responding to this thread has 
failed to mention one very important aspect of any 
design-for-accessibility debate: Until you actually test it with a 
target audience/persona (i.e., someone who actually **is** blind), 
we're all just guessing at the relative importance of the issue at 
hand.


We're not all just guessing - at least I'm not. My base for saying
anything on the issue may be limited to national, and even regional,
target-groups, but the amount of guesswork I apply is also (to the best
of my ability) limited to an absolute minimum.

1: An alt-text should be short (a few words only) and to the point.
Anything in addition to that should be found elsewhere, and whether that
"elsewhere" is on the page, on the site, or somewhere else on or off the
web, depends on the case at hand.

2: the importance of anything on a web page, depends entirely on the
individual visitor's interests at the time of visit.

Keep in mind, that some may hear the page read aloud and think 
'Sheesh - enough with the graphics descriptions that keep 
interrupting the text flow of the page'.


The speed at which some hear a page read aloud can be (what we would
call) extreme, so we should indeed not interrupt the flow unnecessarily.
That's why it's a good thing to "silence" graphics that play no role in
the flow, and deliver something useful as part of the natural text flow
when it _does_ play a role.

And yes, I've witnessed this, and it is **very** humbling.  We can 
read the specifications all day long and apply them in a (seemingly) 
100% correct manner, and yet still totally ruin the experience for 
some.


Yes, but the main (original) issue here is about making the 'alt
attribute' itself optional _in_ a future specification.
Reading, and indeed writing, specifications on how to use or not to use
the 'alt attribute', only makes real sense if its existence is
_recommended_, IMO.


Test, test, test.


Testing may run into problems with my point 2 above, as few (if any) can
afford to do testing with a wide-spread enough panel to "catch all".
We have to make educated guesses - and choices - no matter how well we
test and tailor our solutions to any group and their recommendations, so
"self-education" and "use of common sense" is (at least) as important as
testing.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Investigating the proposed alt attribute recommendations in HTML 5

[Gunlaug Sørtun]

Designer wrote:

I notice that no-one has taken up the challenge of providing an 
emotional alt tag . . .  :-)


We have emoticons already, but I think they are optional...  ;-)

Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] width calculation linux / windows

[Gunlaug Sørtun]

ben van 't ende [netcreators] wrote:

Hey List,

[...] When I drop the borders all is well AFAICS in all browsers. I 
can see that in the two Linux browsers mentioned before the width of 
the center column is 2px more than in other browsers. This means to 
me the width is calculated differently here.


Can someone shed light on why this is so on the two Linux browsers 
and how I can solve this?



http://gbo.intermax.nl.


Solution, add...

#right {margin-left: -2px;}

...to pull in the backside margin on that float. That will provide
enough space - as the browsers calculates it.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] width calculation linux / windows

[Gunlaug Sørtun]

ben van 't ende [netcreators] wrote:

Wow! Gunlaug. Amazing I knew there had to be a solution. I am still
wondering why this works. Isn't CSS wonderous?


Yes, CSS can be wondrous at times.

A block-element occupy space to the outside of its margins. Floats are
no exception, but negative back-side margins' effect on floats and space
may be slightly harder to grasp...



regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] width calculation linux / windows

[Gunlaug Sørtun]

ben van 't ende [netcreators] wrote:





The only thing is ie6 crashes on resizing. That is a weird
phenomenon. Not much you can do about that i guess.


Probably a whole lot if I could isolate the IE6/OS/service-pack
combination - with settings - the crash happened on.
Win-XP/SP2 is said to introduce a nice soup of float-related
freeze/crash bugs in IE6, but I can't reproduce any such problems on any
of my installations with that or other win-OS/SPs for that page, and I
won't venture into blind debugging of IE6.

If anyone can reproduce this particular IE-bug and pin-point what
exactly that bugger chokes on, than a bug-fix may be found and added -
short of changing the actual 'negative margins on floats' demo as such.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] width calculation linux / windows

[Gunlaug Sørtun]

ben van 't ende [netcreators] wrote:

Ik looks like both M$ browsers have the same problem. Only IE6 
crashes on it. IE7 acts weird with the left column. I will try to 
focus on the ie specific stylesheet with the "width:expression ."

 thingies. to solve it.


More case-specific information, please.
- Which layout are you experiencing which problems with (links)
- Which stylesheets are involved (links)
- What's happening in which browser(s).
- What's supposed to happen - your intentions.

At the moment I'm just confused and have no idea what to look for,
where. (Happens at times when threads go back and forth for a while and
I'm busy doing my own things.)

Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Equal Height Columns/OTL background images

[Gunlaug Sørtun]

Joshua Street wrote:

Hi all,

I've got this design that requires equal height columns *and*
background images positioned at the bottom of each column.



The heights are fluid, the widths is fixed.


The "Companion column method"...

...allows for background images both at the top and bottom.

And then there are CSS tables ... (sight)...


regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] opera bug on hover, and the use of margins and left/right on absolute position

[Gunlaug Sørtun]

Tee G. Peng wrote:
Opera 9.02 has a problem with :hover span, part of the  popup box 
overlapping the link element's background on hover. When link is 
clicked,  the popup box shows up fine.


In my experience: Opera only reliably reveals a pop-up element from
inside a link, if the link itself is turned into a block-element.
Example: 

I seem to remember that there is another fix for this - one that works
fine for inline-links, but can't remember where I noted down the solution.

Also,  can someone explains the use of margins over  left/right [3] 
units with absolute position.


1: absolute positioned elements should be given actual horizontal
(left/right) and vertical (top/bottom) positions, to avoid differences
in defaults between browsers.

2: Offsetting an absolute positioned element from its 'px' or percentage
defined position by for example 10em in any direction, can only be done
by adding positive, or negative, margins to the mix. Works well with all
units / unit-mixes.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] opera bug on hover, and the use of margins and left/right on absolute position

[Gunlaug Sørtun]

Tee G. Peng wrote:
I have a concern regarding accessibility on this technique, if 
show/hide result isn't so much of a concern,would 'title' attribute a
 better choice?  Because, if style sheet is disable or pag viewed in 
Lynx Viewer, content in the span class is revealed. But we don't 
always want this.


My opinion is: if you don't want something to show up in a non-CSS
browser, don't put that "something" in the document in the first place.

An HTML document should (ideally at least) make perfect sense in a
non-css, text-only, browser - like Lynx. Only when that is assured
should styles, and/or anything else for that matter, be added to perfect
the design.

Problems with pop-ups that don't make sense in browsers like Lynx, can
usually be solved by adding more text to complete the message delivered
in the pop-up itself, and keep this extra text hidden in CSS capable
browsers. This way one can deliver meaningful messages on all levels.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Positioning a background image

[Gunlaug Sørtun]

Mike Brown wrote:

So, I want to position a background-image. It's a single px image. I
 want it to start on the left-hand-side of its containing div, and
120px from the top. I want it to repeat downwards.


Setting 'repeat-y' means: "repeat vertically - both up and down - from a
starting-point".

If you want it to go only downwards from a starting-point: declare
'no-repeat', and make the image itself as tall as it needs to be.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Cost of Accessibility

[Gunlaug Sørtun]

Gary Barber wrote:
You ask "do you want a good quality web site". The clients replies, 
"quality means expensive. As long as it looks good I don't care". 
Here in lies the problem.


That shouldn't be seen as a problem.
For me at least it takes longer, and cost more, to create a site
consisting of low quality code from scratch, than a good one, so that's
not the kind of question I would ask in the first place.

As I see it: what may be good accessibility-wise is even better for the
developer during the work-process, so I base my work on quality in order
to save time - and money.

Why bother taking the time to make something that is good quality 
when at the end of the day the client just wants cheap and functional

 and looks nice.


That's what the client wants. That's not often what s\he gets.
Dysfunctional and "anything but nice" seems to be the norm for both
cheap, and plenty of not so cheap, sites.

So the client says "Why should I use you with your standards and 
accessibility,  Cowboy Design Joe here is half the cost and looks the

 same, same Google ranking".


Then Cowboy Design Joe may get a "cheap" client. At least I won't - and
thanks heaven for that.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Cost of Accessibility

[Gunlaug Sørtun]

Steve Green wrote:
The complexity and cost of accessible design increase significantly 
when the content is more complex, such as very large forms (we have 
discussed a few real examples in this list), multimedia and 
interactive e-learning (especially when it is discovery-based rather

 than task-based).


You're right of course.
If a design _relies_ on screen, mouse, keyboard in the "normal" sense,
then it is nearly impossible to make such a design accessible, or
usable, if any of those input/output devices goes missing, are replaced
with something else, or are changed from the "norm".
This includes visitors with issues/needs that deviate from the "norm",
who may still use the "normal" devices in a "near-but-not-quite-normal" way.

The only way to make that work is to take away the _reliances_, and that
may mean:
1: a completely different design without such reliances.
2: a new, and accessible, base that everything else can stay on top of.
3: lots of workarounds/additions to make main parts of the design
somewhat accessible - for most.
4: side-by-side alternatives.

Of course this costs time and money - especially if client demands are
for "visual perfection" compared to a graphic design.
Few clients and/or graphic designers see anything but the visual, and
they rarely ever use their own creations to such a degree that they
realize any visual or non-visual weaknesses beyond their own "norm".

So, we may definitely have problems - with clients and graphic designers.


The question is whether we should solve the problems and have reasonably
happy visitors, make the paying client happy, forget the whole issue, or
leave the job to whoever wants it.

I prefer to combine the two first options if at all possible, but I'm no
stranger to the last option. I will never let myself "forget the whole
issue" for any price, so if the other parties involved are not willing
to compromise in order to reach a reasonably well-working solution, then
I'm not either.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Cost of Accessibility

[Gunlaug Sørtun]

Tee G. Peng wrote:
I want to build accessible sites because that is the right thing to 
do and I have pride in what I do.


Pride may be a costly commodity in more than one way. It sure beats
money as driving-force for real growth though.


Sometimes I do wonder, are some people (including me) in the WSG list
 live in our fancy world.


Yes, I think we are, and I also think that's a good thing - as long as
we can afford to.

Living in our own "fancy world" sure sounds, and feels, better than
having a "second life"[1] :-)

regards
Georg

[1]http://en.wikipedia.org/wiki/Second_Life
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] source order

[Gunlaug Sørtun]

Rick Lecoat wrote:


Is there a prevailing wisdom in this matter? Content first? Or
navigation first?


Point 4 in this article...

...seems to indicate "content first" as best, with the "navigation first
with skip link to content" as the second best option.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Priority 2 error - Clearly identify the target of each link.

[Gunlaug Sørtun]

Tee G. Peng wrote:
[...] In the same page more than one article is listed, that means 
more than one title attribute with 'continue reading', as a result I

 am unable to pass the Priority 2: 13.1 Clearly identify the target
of each link.
http://www.w3.org/TR/WAI-WEBCONTENT/#tech-meaningful-links

Can this idiotically error be ignored?


If each link text clearly identifies the relevant target, then whatever
is in the title attribute can be read for what it is: additional
information - an extension of the link text.
In this case the title attribute is mostly ignored by everyone, and you
can safely ignore it to - in this context.

If link text is the same, general repetition, on several links, then the
link text does *not* "clearly identify the target". In such a case the
link fails '13.1' regardless of what's in the title attribute.

Title attributes can't act as substitute for real link text, so if
there's no proper link text - or proper use of alt attribute for images,
the entire link fails no matter what.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Priority 2 error - Clearly identify the target of each link.

[Gunlaug Sørtun]

Is it an "Idiotic error"?

Imagine you're blind...


And my blind tester says: "it's an idiotic error - must have been
implemented by non-blind people for the sole purpose of satisfying
non-blind people's imagination of what it's like to be blind".

My blind tester can't even read such a title attribute out of context
- it's attached to the link itself, as an addition to the link text.

Russ is focusing on the uniqueness of the link text itself, and you
already have that sorted out with a unique and relevant link text for
each link - if I understood you correctly.
The title attribute is irrelevant for identifying the link as unique,
and it is an additional _may be used_ anyway.

Not having title attributes wouldn't make links any more unique or
affect the link text in any way, but its absence would make it pass the
"unique" test. Check the logic in that.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] skip to content: care of accessibility causing usability

[Gunlaug Sørtun]

Tee G. Peng wrote:

teesworks.com/

Been working on this site in the last 2 days, I find that I am 
getting so  annoyed by the "surprise' everytime the hover pops up.


If I, the site builder,  find it annoying, what will the users find ?


As a user I find that kind of "visual flicker" highly annoying.

I am beginning to think this is causing a usability issue and is 
killing all other usable elements that I work so hard to try to get 
them right.


A 'Skip to content' link may have its uses, but I don't see much need
for one in that design - too few links to skip (at least in that dev page).
Basic accessibility is too hard to sell anyway, and I don't see the
point in annoying clients and/or the majority of users with such minor
issues when there are so many other practical issues to take care of and
spend dev-time on.

Personally I don't provide "skip to (whatever)" links in a design unless
there's a client-request for them, and then I style them without any
"flicker" effects.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] skip to content: care of accessibility causing usability

[Gunlaug Sørtun]

Tee G. Peng wrote:

Georg, can you kindly take a look on IE6?  The horizontal menu 
doesn't load smoothly, when the page is fully loaded, the header's 
part reloads, I suspect it has to do with the clear both class yet I

 can't figure  a fix for IE (tried all tricks from hasLayout)


The page loads very much slower in IE6 than in other browser, presumably
because IE6 needs so many fixes. Can't see any reloads.

The use of 'hasLayout' related tricks should be kept at a minimum -
especially at early dev-stage, as that "bug/fix" can ruin any layout
more than it helps, and make all attempts to fix things in IE6 more or
less impossible.
Adding too many 'hasLayout' triggers is like bracing a building to the
point where one has no space left to move around on inside it. Not much
of a building then, and IE/win (any version) won't cooperate well either.

Once loaded, the right part is dropped below the left part, see...



...resulting in overlapping. It will jump back into place with smaller
than normal font-resizing, but won't stay there with normal or larger
font-resizing.

I think it's a case of "auto-expansion" - IE6 doesn't respect declared
dimensions and can't handle overflow properly. The only cure against
that bug is to hide the horizontal overflow with 'overflow-x: hidden' on
problematic containers, which _may_ hide a bit too much at times.


Generally it looks like you have mixed 'em', 'px' and '%' for
positioning and dimensions in ways that doesn't add up under anything
but ideal conditions, and the weaknesses show in any browser. Resizing
window and adding a bit of font-resizing create overlapping and
overshooting in all browsers.
No "elastic" or "conditional elastic" method works well for layouts with
that many fixed dimensions - images. Although it is possible to make
something like that work in better browsers, IE6 will put up such a
fight that it simply isn't worth the hassle, IMO.

A fixed-width approach will _just work_ in all browsers, and make it
much easier to get IE6 to behave like a browser.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Site check requested :: Lecoat

[Gunlaug Sørtun]

Rick Lecoat wrote:
[...] I'm not sure how to specify media types when most of my 
stylesheets are referenced by @import rules from inside a single 
stylesheet called import.css.


You can leave the @import without a media type, and use @media wrappers
around the entire set of relevant styles in each stylesheet...


I always do it this way, and leave old browsers with unstyled pages in
the process.

You can of course then also use IE/win's @import bug to feed IE/win some
additional styles...

...in case it needs any, and/or you can use the bug to keep IE/win from
seeing styles that upsets it.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Rounded Courners .... Your Take

[Gunlaug Sørtun]

James Jeffery wrote:

What methods do you find best when creating rounded corners and which
methods are the most supported?

I have been using span tags and absolute positioning. I have also 
recently started to use the sliding doors method because you can 
achive nice rounded boxes with some nice effects, even better if you

use PNG's.



Lets have your beloved methods then guys.


I add shapes by CSS-manipulating a number of script generated elements -
divs - above and below a box.

In its most basic form the boxes may come out like this...



...where ordinary CSS-borders are used on all but the last example.
(There's a 1px flaw in IE7 (and IE6 in standard mode) I haven't yet
bothered to correct for in the demo page itself. An ordinary 'hasLayout'
trigger does it in CSS anyway.)

I use 'onDOMContentLoaded' for the script to prevent flickering and
changes as the page gets completed, and add background colors and images
as I see fit.

There are of course very few limitations when it comes to styling the
generated elements. I add as many as I need in each case, and they are
not limited to enhancing corners.

I tend to go for the flat form with simple bordered shapes, and just
fill the generated elements with the box' background. Goes with any
page-background.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] CSS help

[Gunlaug Sørtun]

Rob Enslin wrote:


Is there a way, a logical procedure or rule which I should adopt to
prevent me from going forwards and backwards and constantly patching
it up?


A few: 

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Request possible?

[Gunlaug Sørtun]

Michael Vogt wrote:


html: 



I have 2 questions:



- is there a better way to do the html structure for this?


You'll have to make some structural/sequential changes to get the visual
effect you're after, since CSS alone can't handle such effects with any
accuracy yet. Thus, the visual won't reflect the source-order.

- is there a way  that only 2 lines of text are allowed above the 
small box? The other text should flow automatically around the box.


With a "spacer-float", yes. See example...



IE/win (all versions) need help though, as it mixes up the calculations.
Most of IE's problems can be avoided by reorganizing where the
margins/paddings go in the layout as a whole.

Also, the line-up won't be reliable using fixed dimensions, pixels,
since there isn't such a thing as fixed font-sizes/line-heights in web
design. Thus, you'll have to modify dimensions to work with relative
font-sizes/line-heights if you want to avoid all sorts of breaking and
overlapping when such a request gets subjected to the slightest amount
of stress across browser-land.

Otherwise: no problem.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Request possible?

[Gunlaug Sørtun]

Philippe Wittenbergh wrote:


On Nov 6, 2007, at 7:48 PM, Gunlaug Sørtun wrote:


<http://www.gunlaug.no/tos/alien/mv/test_07_1106.html>

...

Otherwise: no problem.


No problems ? With Fx Mac and Safari 2.04, 3.03beta and the latest 
WebKit builds, the is a slight overlap: the top part of the floated 
block is partly covered by the text outside of it. In Gecko the 
floated block is under that text, in WebKit, the floated block is on 
top. Depending on your font-size, this is more or less pronounced.


Yes, but there's no point in creating a flawless demo if pixel-defined
font-sizes and line-heights are used. It'll break everywhere anyway.
To create something useful out of it, one must get all the ordinary
layout-details right.

Those who want to know more, can dissect Ingo's old demo...
<http://www.satzansatz.de/cssd/tmp/floatspacer.html>
...but it's still incomplete, so /some/ browsers still need more help if
they should get that one right under stress.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Colour Blindness Statistics

[Gunlaug Sørtun]

Rahul Gonsalves wrote:
I'm searching for first-hand, authoritative statistics on colour 
blindness, for use in a formal, academic document. Would anyone be

able to point me in the right direction?


Maybe this will help in the search...



regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Help IE

[Gunlaug Sørtun]

Bob Schwartz wrote:

I have a site in progress that is currently "pixel perfect" in all
real browsers, it's all over the screen in IE 6 (don't yet know about
IE7).


IE7 is doing fine :-)


http://www.fgtestserver.net/rain/index.html


IE6' "margin-doubling on floats" bug is causing most damage.

Adding...

#con {
display:inline;
}

#rhtcol {
display:inline;
margin-left: -10px;
}

...will kill that bug, and also provide a bit more space for IE6 lack of
respect for declared dimensions.
Only a few more IE6 bugs left for you to fix then.


While you're at it: There's no point in declaring both 'min-height' and
'height' with same, fixed, value on an element. Fixed 'height' is fixed
'height' in all but IE6 and older.

True that IE6 doesn't understand 'min-height' but if that's what you're
trying to fix then make sure other browsers can't see that 'height'
you're serving IE6.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Help IE

[Gunlaug Sørtun]

Bob Schwartz wrote:

http://www.fgtestserver.net/rain/index.html


The other problems in IE6 are related to the "white-space bug" and IE's
need for 'Layout'.

#outerWrapper, #innerWrapper {height: 1%;}

...will act as 'hasLayout' triggers where necessary.


The "white-space" bug is caused by empty elements, which IE/win
interprets to have a space. That space is consequently given
line-height, and IE6 doesn't respect declared dimensions so the elements
get "spaced out".

The easiest way to fix that bug-combination is to eliminate the
"emptiness" by placing an HTML comment inside empty elements - tightly
with no space at either side, like so...



Repeating that on _all_ _empty_ elements makes IE/win understand that
there isn't any space for its bugs.
Result - which I of course have tested for your page - is near perfect
rendering in IE6 compared to other browsers.

You do have the 'overflow: hidden' alternative for that "white-space"
bug - forcing IE6 to respect declared dimensions. However, that solution
may hide too much in some cases, and I didn't bother to test it for your
layout.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Help IE

[Gunlaug Sørtun]

Bob Schwartz wrote:

I'm still getting a problem with the area under the tabs, IE is showing 
about 25px of the content background (con-cen) above the top content 
curve (con-top)


I can't see that in IE6 for my (original) test case...



regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Help IE

[Gunlaug Sørtun]

Bob Schwartz wrote:
I have a windows box for testing IE6, what I don't have is a good 
memory for IE6 bugs, especially since they only show up when I'm 
doing a tight "pixel perfect" design.


Don't memorize ... use online resources...






...and create absurd test-cases...



IE/win's bugs are always present - in all versions, so if you don't see
any then you're not trying hard enough to provoke them :-)

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Colour Blindness Statistics

[Gunlaug Sørtun]

Rahul Gonsalves wrote:





However, the statistics given there seem misleading -- as according 
to this linked page [1], there are 10 million men in the US alone who

 are colour blind, while this page [2] suggests that in the US, there
 are only 3.5 million people who are colour blind.


Guess that shows difference between what's known as "color blindness"
and "color deficiency". There's a deficiency-scale - not just different
forms, but both terms are used for both by many. Don't know how they
"count" in the US.

I suppose I should have made myself clearer as to why I was asking 
for this information on this particular forum - I am writing a paper
 on how one can design sensibly, and take into account various 
impairments - colour blindness being one of them.


I'm not sure how useful statistics are when it comes to describing
methods. Statistics are "good" for clients and designers, but
"selective" and "discriminating" for users.

Belonging to large or small groups in a population shouldn't matter, and
certainly not on the web where the numbers may differ greatly from
what's found in the real world.
The virtual world has the potential to even out both minor and major
differences, but most of the "leveling" that's known to actually work,
takes place at the user-end.


To design sensibly makes sense to most, so I'm looking forward to see at
least some of what you come up with. However, statistics are something I
rather not see much of anywhere.

regards
Georg

PS: personally I find "extremely accessible" sites as hard to use as
"completely inaccessible" ones, but my experiences are not statistically
significant.
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Idiot's guide to JavaScript

[Gunlaug Sørtun]

Rob Mason wrote:
I am looking for a really basic, plain English guide to JavaScript. 
Either on or offline will do.


A little of both...





regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Weird feature in Opera

[Gunlaug Sørtun]

Rob Mason wrote:

(www.spongeproject.co.uk )


Opera displays the image as intended, but also repeats 50px or so of 
the same image again, about half way up the page.


I have no idea what's going on. On a local copy I gave the image a
roundtrip through photoshop without making /any/ changes to it, and then
saved it again, and it worked just fine in Opera.

Maybe the image itself was corrupted in some way, and Opera solved the
problem in its own - not so pleasant - way.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] SIte Maps?

[Gunlaug Sørtun]

Designer wrote:
Any links or pointers to creating such an index/map would be most 
welcome. Needless to say, standards and accessibility are important

. . .


I split them up in section-maps - table of contents - and produce them
manually. An automated process is probably the only practical solution
on larger sites, but a regular nested list is probably the most
user-friendly end-result no matter how it is produced.

Example: 
(I used to have a dozen of those section-maps on my site, before I
deleted 3/4 of it. That explains the high (#7a) number.)

I link to sub-menus instead of including every single page in a
section-menu, as it would otherwise become too large.
My site is undergoing changes at the moment, so I'll have to reorganize
my section-maps and sub-maps soon.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Page shift in IE6

[Gunlaug Sørtun]

John Faulds wrote:

I've got a page shift happening when you hover over certain elements in 
the right column on this page:


http://www.gbjt.org.au/competitions/enrolment/


Can you provide a link directly to your IE stylesheet? It's a bit 
difficult to track down from the outside.


Looks like you're using "auto" as fall-back in your expression.
That'll trigger 'Layout' on and off, with the quite normal result that 
it messes with some of your positioning.


Can't suggest proper fix without seeing all your IE styles. However, 
adding 'hasLayout' triggers all over the place rarely fixes anything 
since we're dealing with a bug that has as many negative sides as it has 
positive.


regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Page shift in IE6

[Gunlaug Sørtun]

John Faulds wrote:


http://www.gbjt.org.au/competitions/enrolment/



http://www.gbjt.org.au/css/IE.css


1: the large shifting is easiest solved by deleting all R:P styles on
sidebar...

#sidebar {
position: relative; <-- delete
z-index: 200; <-- delete
}

...which leaves a very small shift that I'll track down later.


2: the IE-expression isn't used right on that page, since '80em' doesn't
correspond to _one_ specific pixel-width. In IE/win it corresponds to 5
different pixel-widths - one for each font-resizing step, which means
your expression have to "ask" IE6 which font-resizing step it's on.
No use doing that with an expression when font-size is declared on body.

The solution is to move _your_ font-size onto #wrap, and "ask" IE6 what
each user has chosen. IE6 has the answer styled in points on its
body-element - as long as you don't overwrite it.

A couple of working solutions can be found here...



...almost half way down the page under the headline:
"px/em-based min/max-width expression..."

The main column in that page has max-width in 'em', so you can see how
that works in IE6. I've just complicated it a bit by reducing the effect
of small font-resize settings in all versions of IE/win.



I'll see if I can find the last couple of pixels shift in your layout
... once I have had some sleep :-)
For now I'll just mention that IE/win doesn't handle negative backside
margins on right-floats very well - unlike on left-floats. Don't know if
that matters in your case though.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Page shift in IE6

[Gunlaug Sørtun]

John Faulds wrote:

I had that there because the top link in the sidebar seems to get 
partially obscured by the transparent PNG of the ball. I'm sure it 
was working at some point, but doesn't seem to be now. :/


You can keep the...

#sidebar {
position: relative;
z-index: 200;
}

..._if_ it solves the "obscuring-problem". It doesn't at my end.

However, then you must also stabilize  #sidebar's relation to #content,
and fix a few IE/win bugs while you're at it, by adding...

* html body #content {
overflow: visible;
zoom:1;
position: relative;
}

I won't start listing all potential IE/win bugs involved, but they are
the reason I never go anywhere near any of the latest "holy grail"
solutions.


I've tried moving the font-size to the wrapper and using the revised
 expression for px/em-based min/max-width from your example but it 
doesn't stop the page shift and also the max-width doesn't get 
applied either.


The pixel-based min/max version is a much easier solution then, but
yours needs adjustments. The 4% missing with a fluid state of 96% width,
is not identical to the 18px you have between "attack" and "max-width"
values, and same goes for the 'min-width' part. It is percentage of the
body-width you're dealing with, and that naturally varies with window-width.

Calculate new values or tune them by testing, until there's no jumping
at either end and no appearing horizontal scrollbar when in the fluid
state. Will work well enough for most, I think.

I see maybe a 1px horizontal jump when hovering any link now - in my
corrected copy and your present page, and that's hardly enough to "hunt
and kill IE/win bugs" for.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] SIte Maps?

[Gunlaug Sørtun]

Chris Taylor wrote:
But even for a relatively small site having a sitemap will help some 
users find what they want quickly. Those people are the same ones who

will scan the index of a book before flicking through the pages.

I've done that on this site: http://www.2plan.com/ despite it only 
being 15 pages or so. Does anyone think that is overkill?


Doesn't look like an overkill to me. The sitemap is a useful addition
for shortening the search - even on a small site like that.

I would however "kill" all "same page" links, and just keep them listed
as "you are here" references - without anchors. Same in the regular
navigation.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Page shift in IE6

[Gunlaug Sørtun]

John Faulds wrote:

Could you show me what you've got in your corrected copy because I'm
 unsure which values I'm supposed to be tuning?


Ok, here's a smooth-working version...

* html #wrap {
width: 95%;
width:expression(((document.compatMode &&
document.compatMode=='CSS1Compat') ?
document.documentElement.clientWidth
: document.body.clientWidth) > 1200 ?
"1140px" : (((document.compatMode &&
document.compatMode=='CSS1Compat') ?
document.documentElement.clientWidth
: document.body.clientWidth) < 860 ? "820px"
: "95%"));
}

...ready for copy and paste into the "IE.css", if all other parameters
in your page are as before.


In the above '> 1200' is the "attack", the value used in the "greater
than" argument for when the "1140px" - the "max-width" - should be used
as 'width'.

Likewise, the '< 860' is the "attack", the value used in the "smaller
than" argument for when the "820px" - the "min-width" - should be used
as 'width'.

In between those two "attack" points is the "fluid" state where the
'width' = "95%", which is the value I chose to avoid a flickering
horizontal scrollbar in that particular layout.


So, as you can see: there are 5 values that must fit the specific
layout. One can either calculate them, or one can simply test and adjust
- tune - until it all works smoothly and looks right - like I just did
on a copy of your page.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] question about max-width's behaviour

[Gunlaug Sørtun]

Tee G. Peng wrote:
I thought  max-width tells the browser: This is the limit of the 
width you can expand, regardless how big the screen is.


But  my testing shows that, with a max-width of 60em, a 1680px wide 
monitor, when a browser is opened in full screen, with fontsize 
increases, the page just continued expanding until it reaches 1680px 
full screen. If I drag the screen to the second monitor, it keeps 
expanding.  If I make the screen smaller to 900px, then expansion 
stop there.


You're describing how a "conditional elastic" layout works, in that it
will expand to a max-width of 60em (which increases with font size), as
long as it's within the width of the browser-window and larger than a
min-width of 900px.

You can keep on increasing font size and the max-width will grow with
it. The 'width: 100%' is keeping it within the browser-window.


The  is a bit weak in that it has fixed
height on some elements, which causes overlapping when font size is
increased a bit. Otherwise it's a typical "conditional elastic" layout.

Here's a simpler example...




regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Page shift in IE6

[Gunlaug Sørtun]

John Faulds wrote:
I appreciate all your efforst so far Georg, but could I impose a little 
bit more and ask you to put a version of the page you've made online so 
I can compare because I'm still getting a noticeable shift at my end?


Sure...



IE/win styles in the page head.

The last pixel-shift is due to the...

#wrap {
padding: 0 2%;
}

IE6 calculates that percentage-padding wrong on first load and shift 
#wrap 1px to one side and #content 1px to the other.
Once a link-hovering inside that construction causes IE6 to recalculate 
and re-render, the mistake is corrected - causing the visible shift.


My solution is to give IE6 something it can not miscalculate - pixels...

* html #wrap {
padding: 0 20px;
}


regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Opera files antitrust against MS: standards one part

[Gunlaug Sørtun]

John Faulds wrote:
"First, it requests the Commission to obligate Microsoft to unbundle 
Internet Explorer from Windows and/or carry alternative browsers 
pre-installed on the desktop."


I can't see that flying. Is anyone going to ask Apple to stop 
shipping their OS with Safari?


No, but Apple is hardly in a dominant position, and carrying
pre-installed alternatives to Safari can't be much of a problem.

Microsoft is in a "slightly" more dominant position, so a better control
of its practices sure wouldn't hurt. Delivering their OSes with half a
dozen pre-installed standard-compliant alternatives to IE/win isn't a
technical problem, so why not?

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Opera files antitrust against MS: standards one part

[Gunlaug Sørtun]

John Faulds wrote:
Delivering their OSes with half a dozen pre-installed 
standard-compliant alternatives to IE/win isn't a technical 
problem, so why not?


I'm no lawyer and I'm also no MS fanboy, but I think 'why?' is as 
equally a valid question as 'why not?'.


Indeed. Which would make any such case valid for testing.

[...] Is it reasonable for any OS vendor to have to install any more 
than one type of any application?


I think that would depend on the application in question. AFAIKS only
one application is mentioned in the article.

For the less savvy users, having more than one option may actually 
make things more difficult for them.


Sure, and the least savvy users may get lost with only one option -
especially if it's a weak one. Making choices for users rarely helps,
unless the aim is to keep them ignorant.

Surely it's any manufacturer's right to choose what components they 
use in their own product (as long as there aren't health and safety 
concerns involved)?


Don't know about the rest of the world, but in the EU there's also
something called "ethics" involved when products and sales methods are
evaluated.
Microsoft has been evaluated on ethics before - in the EU, and it didn't
pass the tests. The same has happened to other companies - big and
small, so it doesn't really matter what name it has and what its
products are.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Opera files antitrust against MS: standards one part

[Gunlaug Sørtun]

Al Sparber wrote:

From: "Michael Horowitz" <[EMAIL PROTECTED]>
Personally I'm looking forward to buying computers with virtually 
nothing pre installed.  I always end up deleting most of it anyway.
 Alot of people start off by reinstalling the OS to get rid of all 
the junk the PC manufacturers put on.


I buy the boxes empty, and install what I want/need from scratch. Since
I happen to prefer MS-OSes for the time being, it would be nice if I
could get clean ones.

Indeed. But to bring it on-topic, I doubt very highly that Opera's 
motivation is standards.


Opera's motivation is unimportant. I don't think they'll get much out of
it anyway - apart from maybe a more leveled and standard-based
playing-field.

How "the guardians" of a relatively large market like the EU looks at,
and reacts to, how the players behave, may be of some importance.
Whatever the outcome, I doubt if it'll only affect us in the EU area -
and we Norwegians are not even regular EU-members :-)

If the unimaginable happened and MSIE8 were as standards-comformant 
as Opera, it would also be stronger in the marketplace. The best 
thing that could happen for standards-oriented web developers would 
be that all computers shipped with a single, extensible browser 
appliance with a standards-based module, managed and updated by an 
independent party, being the chief extension.


If it was delivered with an excellent standard-support module and were
truly extensible beyond that, then we would indeed have something very
near what could be described as the ideal platform for web development -
for a short while. I'm wondering how an independent party should be
defined and organized though, and how such a party should secure
progress. I do seriously doubt if such a solution would stay "single"
for long, and even that it is a good idea.


It's better that the industry wake up now because eventually someone
 is going to figure out that a browser is an appliance and the only 
thing it should be doing is supporting standards and sitting 
unobtrusively in the background acting as a window to the web.


Guess it would have to support plenty of non-standards too, since such a
small segment of the web is following standards - any standards. Leaving
out the larger part of the web because it isn't "standard", isn't a
valid option. Standardizing non-standard rendering and behavior as part
of the main module, would be necessary, but we may get there too - one
day - before someone break too far out of the standards and the whole
"game" starts all over again.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] IE6 issue with a ul

[Gunlaug Sørtun]

Lyn Patterson wrote:


http://www.westernwebdesign.com.au/bluelightning/gallery.html

It is fine in Fx, IE7 and Opera.  In IE6, ul#img li is not
displaying. This is the bit that supplies the background  and room
for a large caption.

Can anyone tell me why this is so?


IE6 has "stacking bugs", which in your case results in a hidden ul.

Adding...

ul#img {position: relative;}

...will lift that container up in front - making it visible, without any
negative effects across browser-land AFAICS.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] IE6 issue with a ul

[Gunlaug Sørtun]

Lyn Patterson wrote:


"stacking bugs" ? something for me to research.


You'll find few references to that bug under that "name". It's rather a
description of how the bug works - individual layers of an element get
wrongly stacked relative to individual layers of other elements
_visually_  in the same area.

Search for "hasLayout" related bugs instead, and  look for bugs that
sometimes - *but not always* - can be fixed by adding 'hasLayout'
triggers. There you may find the fix: 'position: relative' on the
element itself and/or on related elements in combinations with or as
alternative for 'hasLayout' triggers, and can deduct what's really going
on from there.


FYI: IE7 has several new versions of these "stacking bugs", since all
they have done in IE7 is to _patch over_ the most documented and "talked
about" occurrences of bugs found in IE6. In doing so they have just
"moved the old bugs around" - especially the "stacking bugs",
without fixing more than an insignificant number of bugs for real.


In case you're not familiar with stacking of element-layers and
generation of anonymous boxes and such: browsers have to split all
elements into individual layers and add characteristics to each of them,
and then stack them all at the correct levels for visual appearance.
This is part of what makes rendering in browsers a bit more complex than
most web designers like to think, and needless to say that IE/win (any
version) isn't particularly good at this splitting and subsequent stacking.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Opera files antitrust against MS: standards one part

[Gunlaug Sørtun]

Al Sparber wrote:

[...]


Reducing the disparities is not the same as eliminating disparities. 
It is human nature to make mistakes. It's often the best way to 
learn.


Yes, it is. However, it is not human nature to make use of what they
have, or should have learned, if they can get away with their old
mistakes and maybe a few patches.
Just ask the IE7 team - or tear apart IE7 for a closer look.

This "human factor" is in part what's holding back all standard based
web development, as most of what's poured out as web sites today is
based on old mistakes and not standards. One can take any failing site
apart, and find that the main cause for failings in any somewhat
standard compliant browser is old and new designer mistakes which has
nothing to do with browser-bugs.


1. All browsers will always have some bugs


Yes.


2. Some users will always be browsers with an older version


Yes.

It is for these reasons that all browser makers need to provide 
developers with a means of eploying targeted workarounds.


For (users of) old versions, maybe, but certainly not for new ones -
unless one wants bugs to become permanent parts of particular browsers.
Since old browsers can't be retrofitted, we'll have to make use of some
kind of progressive enhancement or (dis)graceful degradation for those
anyway. Nothing new there, regardless of what the future brings.

MS has said they want old bugs to stick, apparently because they're
afraid they'll break the web otherwise. Thus, they have added ways for
us to work around their bugs when necessary ( = most of the time).
That's their strategy, and it'll probably work for them - but not
necessarily for us.

AFAIK: the developers of other major browsers want to find and get rid
of the bugs - any and all bugs, and don't want anyone to have to work
around them.
That's their strategy, and it sounds like a much better one
to me - even if human nature will prevent them from ever reaching
perfection.

In which way is it better to let developers send code specifically 
for fixing a bug, which creates a dependency of that code on the 
bug in question, than fixing the bug? If such dependencies are 
created, they make it harder to actually fix bugs.


That's a great philosophy for teachers and parents to have. It does 
not work so well, however, for businesses. The assumption, again, is 
that human nature is imperfect. Mistakes will always be made.


Mistakes should be corrected at the source - not "covered", or else the
mistakes risk becoming a permanent part of the source - see IE/win.
Whether the source is a browser, or, as is more common: the site and its
developer(s), doesn't really matter when dealing with human
imperfections. How should one learn of ones mistakes if there's never
any need to correct them?

So long as there are more than one browser, there will be unique 
bugs. It's useless to talk about MSIE having lots of bugs because it 
only takes one bug to keep a developer up at night. The reason I like

conditional comments is that once I identify a fix for IE, I can fix
it in a fully insulated way and for specific versions.


Conditional comments in IE/win are fine, because no-one in their right
mind will use them to break that browser. Site-developers would lose
their jobs if they did.

I'm not so sure that human nature and job-security will save other
browsers from being intentionally broken though - plenty of examples
around already. Thus, from a browser-developer or browser-user's point
of view I'd call built-in targeting-means a death-trap for any serious
contender on the browser-market.

We all know the use, mis-use and abuse of "browser sniffing", which have
lead to built-in cloaking of userAgent strings and lost value of an
otherwise perfectly good browser-ID. Any other built-in targeting-means
would need to have similar "off-switches" to defend against human
nature, which would make the whole targeting just as unreliable.

Consequently: I wouldn't go down that road for any price, even if it
might look like a good, short-term, solution.

I recognize differences of opinion here and am so glad that this 
discussion remains civil. The object is always better standards 
support. I can't change Opera's mind and while I disagree with their 
premise, I can only hope that as this thing runs its course there 
will be benefits for us web developers and a better window into the 
web for all users.


We agree on the objectives, so exchanging opinions on how to go about it
shouldn't lead to any side-tracking. I only want standards to be
properly supported across the board of new browsers, so I can develop
sites based on standards and not on browser-quirks. Fixing things in old
browsers provides enough "fun" to prevent death caused by boredom.

I'm looking forward to the day where we can rely on a perfect piece of
software to create the perfect "missing link" - generated page code -
between design and browsers/end-users, but that's probably a bit beyond
(X)HTML5, CSS3 and ES

Re: [WSG] BBC in Beta

[Gunlaug Sørtun]

Mike Brown wrote:


http://www.bbc.co.uk/home/beta



Thoughts/praise/comments :)



Overall, better, but, worse than good.



Oh come on, let's not be so blinkered that we can't appreciate really
 good work in most areas!


Since the example comes out like this...

...in IE7, Firefox and Opera - and a bit worse in IE6, when subjected to
regular, built-in, user-options, it has to be classified as "less than
good" at this stage.

The example is clearly in need of more testing and work if it is to pass
BBC's own "My web My Way" advice...

...somewhat intact, and the weakness doesn't go away by "snipping"
comments about it.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] strange cropping of divs in ie

[Gunlaug Sørtun]

kevin mcmonagle wrote:

If i can ask an old question, whats the best way to get margins and 
padding to be set the same across all browsers.


In standard mode with all other variables equal, margins and paddings
_are_ the same, so I guess that's not what your question is about.
Standard mode vs. Quirks mode box model differences are more likely
causing you problems.

If you want to cater for older IE/win and other Quirks mode only
versions, alongside the latest browsers: don't declare side-paddings on
elements – boxes – that have declared width. Instead, declare
side-margins on non-sized elements inside those sized boxes – like
paragraphs, lists and so on. That'll minimize differences, and you will
only have to take eventual border-widths into account.

I'm dealing with Standard mode vs. Quirks mode box model differences all
the time - by choice...

...so "hitting the middle-ground" has become routine.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] strange cropping of divs in ie

[Gunlaug Sørtun]

kevin mcmonagle wrote:

So do you separate your styles into quirks mode styles and strict 
styles in different css documents?


No, I make only one set of styles - not necessarily in one stylesheet,
making sure mode doesn't matter. Controlling where those
margins/paddings go is usually all that's needed for avoiding
problematic mode-differences.

I test by throwing IE6 and IE7 back and forth between Quirks and
Standard mode, and sometimes I switch mode for the other browsers too,
just to make sure my layouts are mode-independent enough for comfort.


I do feed IE/win (and even IE/Mac at times) separate styles and
stylesheets, but that's for regular bug-corrections and other
workarounds, which rarely have anything to do with which mode they are in.
IE's need for 'hasLayout' triggers and substitutes for properties/values
IE doesn't support, make up these extra styles.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Float-less layouts

[Gunlaug Sørtun]

Thierry Koblentz wrote:
Does your approach deal with "any column any order"? Is this a 
possibility?



As it says on this page [1]: "The sequence of the columns depends on
the source order..." As far as I know, "display:table" doesn't let us
play with columns the same way we can do with floats.


We can reverse column-order with rtl/ltr, and do some more
order-tricking between similar-width columns.

Example: 

Other than that there's not much we can do with CSS tables when it comes
to source order vs. visual order.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Compatibility and IE8

[Gunlaug Sørtun]

Ben Buchanan wrote:
Implementation specifics aside (yes I still think it's spam), the 
version target feature offers us a chance to lock our sites to the 
most convenient version of IE. MS has invited us to ignore their 
newer products. We can opt to save our energy for standards-based 
browsers and not bother learning new versions of IE. Lazy? Pragmatic?

 Mercenary?

Discuss?  :)  Surely this list has some opinions...


All of the above - depending on the situation at hand.

Being practical, it all comes down to what IE8 is worth - in any mode,
once it's released and thoroughly tested.

- IE6 and IE7 will need their workarounds for a few years, so it's
mostly "business as usual" on the IE/win front even after IE8' arrival.

- If IE8 can do without its own workarounds and isn't disturbed by any
workarounds for its predecessors, then triggering "IE8 mode" doesn't
cost anything. If not, then the "most solid" workarounds have to be
found and tested before seriously leaving the "IE7 forever mode" - if
that mode really works. The way the proposed switch works, we should be
able to relax and not bother looking for IE8 fixes until after IE9, or
IE10, is out - just to see how the browser is shaping up.

- If clients expect and/or demand triggering of a "beyond IE7 mode"
(which they probably won't), then they'll get it once any problems with
it are solved.


Bottom line: I don't like this new switch one bit, but I'm pretty
relaxed on the matter and will trigger a suitable "beyond IE7 mode" if
it serves any purpose - for me.

regards
Georg

--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] This IE8 controversy

[Gunlaug Sørtun]

Well, apart from that I don't like IE/win version targeting one bit, if
MSIE uphold this version targeting strategy in future versions, we may
as well use it to our advantage.

"Sidelining" IE/win while designing for standards and better browsers,
doesn't have to become a problem for designers or users, as we can keep
on designing for the present "edge" at any given time, and fix IE/win
when we get around to it.
That's how I go about it now anyway, and version targeting will only
make it easier to cover all IE/win versions that are still in use at any
one time.

We won't need several IE/win versions in order to test and tweak, as we
can just roll back the latest IE/win through previous versions during
the design-phase - providing "previous versions" are "flawless copies"
that we can target.
Once finished, we can decide which IE/win version is most suitable as
our own "IE-final" for that particular job, and leave it there.

Other browsers won't be affected - as long as they stay well away from
any form of version targeting.

Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Conflict between Mime Type and Document Type

[Gunlaug Sørtun]

Designer wrote:

Maybe, but coding in xhtml1.1 makes you MUCH more fussy about syntax
 etc. and it shows up any 'well formed' errors as soon as you browse.
So, whilst the user will know nothing about all this, it makes you as
a designer get lots of practice in using the stricter syntax, ready
for some day in the future when you will need it.

Maybe :-)


Yes, Maybe :-)

I don't know if this is a stable feature, but when I write documents in
XHTML 1.0 (intended to be served as 'text/html'), Opera 9.5 beta (build
9694) treats it as 'text/xml' off-line and refuses to render it if it
isn't well-formed and up to standard. Same document is treated as
'text/html' on-line - as intended.

Opera's behavior gives me immediate feedback during the design-phase
without having to bother with MIME type switching. No such on/off-line
MIME type switching in available versions of other browsers AFAIK.

regards

Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] IE6 3-pixel jog victim

[Gunlaug Sørtun]

Jens-Uwe Korff wrote:

I have restyled a timeline but have come stuck with IE6's 3-pixel 
jog.


I cannot apply the usual remedy (floating the paragraph) as I need 
any element next to the floated "offender" to be indented. Hence the 
paragraph has a left margin which cannot be zero.






You haven't exhausted the 'float' property yet.

By adding...

* html ol.timelineList dl {clear: both; margin-top: 1em;}
* html ol.timelineList li p {float: right; width: 500px; margin: 1em 1em
0 0; clear: right;}
* html ol.timelineList {float: left; margin-top: -1em;}

...you'll get rid of the 3-pixel jog and keep indentation.
The indentation will then be depending on the paragraph-width - not the
left margin, in IE6, and the whole line-up can be tuned to taste.

Note: the "em font-resizing bug in IE5 - IE7"...

...is hitting your creation hard.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] IE6 3-pixel jog victim

[Gunlaug Sørtun]

Jens-Uwe Korff wrote:

thanks very much for your solution - it works perfectly. Could you 
please explain how the margin works with IE6? I wonder how the top 
margin eliminates the left margin when I apply it. Thank you.


Not sure I understand your question - which margin eliminates what,
since there's a zero margin-left on the paragraph in my example.
The paragraph is "hanging on" its right margin - floated right with a
declared width, which means a left margin isn't needed.
That's the "trick", and would work the same in all browsers - if they
could "see" these styles.

IE6 ignores margin-bottom on floats in your line-up - an IE6 bug, so I
instead introduced margin-top for both the paragraph and the dl to
preserve the vertical spacing and line-up.
The negative margin on the floated ol then compensates for these top
margins that are pushing the whole line-up downwards, by moving the
entire ol upwards.


BTW: your page suffers from the "em font-resizing bug in IE5 - IE7"[1].

regards
Georg

[1]http://www.gunlaug.no/contents/wd_additions_13.html
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] re: generate data

[Gunlaug Sørtun]

dwain wrote:

if accessibility isn't cracked up to what it's supposed to be, then 
why are there laws about the subject?


The laws are probably there to prevent "accessibility" from falling
through the cracks. Consciously or unconsciously ignoring "access for
all" is after all more the norm than the exception, and that has to change.

The two levels of accessibility have been mention.

- The first level, where access to content and functionality should be
guaranteed on a "technical" level, is not much of a problem. Basic
understanding of how to build a site is all that's required to reach
that level.

The "challenged" user-groups I ask for advice, expect me to meet them at
that level - which is (slowly being) required by law for public sites in
my country anyway.



- The second level, where some kind of optimizing for specific
user-groups and their hardware/software solutions has to take place, is
of course harder.

I'm being told *not to go there* by the same "challenged" user-groups,
as "more accessible solutions for smaller groups" may end up being
tied to some weak end-user solutions that should rather be
upgraded/replaced and brought in line with the "technical" level most of
them are comfortable with. They work for improvements and solutions that
are tailor-made to the individual's needs - at their end, based on
common delivery-methods and techniques that can be made to work for all
- as long as we developers/designers don't get in their way.

A requirement for common delivery-methods and techniques is being
introduced by law in my country now anyway - for public sites, which
should mean solutions at the user-end will make the need for "more
accessible" solutions at our end a non-issue over time - in Norway.



What kind of "leveling" that is missing/introduced/necessary in other
parts of the world is somewhat unknown to me, but providing accessible
solutions on a "technical" level - and pretty much limit it to that, is
the only common and sensible approach if we want some progress, IMO.
Promoting the need for accessible solutions on a "technical" level on
top of existing and future web standards, should keep us busy enough for
quite a while.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Please help! - CSS Drop Down not working under IE 6

[Gunlaug Sørtun]

Cole Kuryakin wrote:


First, go here under IE 6: http://www.crewasia.ph/index.php

The drop down menuing system at the very top of the screen DOES work 
(it drops down correctly). You can even select the FIRST menu item on

each drop down menu. But, when you try to cursor over any other menu
item, POOF! The menu disappears!


The absolute positioned dropdowns are stacked behind the header, even
though they appear visually in front. This prevents interaction below a
certain point in both IE6 and IE7.

Try adding...

#navTop {position: relative; z-index: 1;}

...to fix that IE/win "stacking of A:P elements" bug.
I've only tested that it works in IE7.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] multiple css style sheets

[Gunlaug Sørtun]

dwain wrote:

On 3/1/08, Melissa Forrest <[EMAIL PROTECTED]> wrote:
aaah no, there is nothing invalid about more than one stylesheet 
 tag in the markup



do you have a link for your side?


Validity isn't a problem, but don't add too many stylesheet links or
style elements in the markup - unless one doesn't want IE/win to get
them all...



Haven't tested for number of @imports yet, but IE/win gets them wrong
anyway - so far...




regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] multiple css style sheets

[Gunlaug Sørtun]

dwain wrote:

On 3/1/08, Matthew Pennell <[EMAIL PROTECTED]> wrote:
On Sat, Mar 1, 2008 at 12:47 PM, dwain <[EMAIL PROTECTED]> 
wrote:



do you have a link for your side?


validator.w3.org?



what about the w3c specs?




I think this gives us the necessary freedom to add stylesheet links.


14.3.1 Preferred and alternate style sheets

HTML allows authors to associate any number of external style sheets 
with a document. The style sheet language defines how multiple 
external style sheets interact (for example, the CSS "cascade" 
rules).


...with this limitation...

If two or more LINK elements specify a preferred style sheet, the 
first one takes precedence.


regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Links are not "hot" in ie8

[Gunlaug Sørtun]

Thierry Koblentz wrote:

I think it's going to be a fun ride...


I really don't think it's time to saddle up yet :-)


http://tjkdesign.com/test/ie8/links.asp


So, they still have those stacking-bugs to sort out.

Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] inline floated right problem in Firefox

[Gunlaug Sørtun]

tee wrote:


http://lotusseedsdesign.com/firefoxbug.html

I have not tested this page in IE as my Parallels desktop has 
networking issue and I can't connect to the Internet  from Windows 
XP, so I am not 100% sure if the problem only occur in Gecko 
browsers.


IE/win handles it like Firefox. Gecko and IE have one interpretation of
such float line-ups, and Opera and Safari have another. I prefer the
Op/Saf one since it works well for all cases, but it's probably the
wrong one :-)

"Float first" is the only cross-browser reliable solution, but it
doesn't always suit the case.

I sometimes use the alternative styled into your "example 2"...



...but it has the same "potential overlapping" effect as absolute
positioning has, and does therefore only work well in some cases.

A better alternative is what I have overstyled a bit in the added
"example 2-b", as there's no chance of overlapping in such a "reverse
styled" case, and the source-order is the the same as the visual order.
One more span needed though.

Sorry for the mess, but I don't have time to create a new demo right now.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Opera 9.26 Problem

[Gunlaug Sørtun]

Web Dandy Design wrote:

[...] However the client's French distributor says that the site 
doesn't look right when they are using Opera v9.26, revision 8835, 
Win32, Windows XP.



Has anyone ever come across this problem before?



www.charis.uk.com  .


Breaks the same way in all versions of Opera and Firefox at first load
at my end, on win2K and winXP at 96dpi res.

Problem is known as "unprepared for font-resizing", and all these
browsers are preset at 'minimum font size: 14px' here.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Opera 9.26 Problem

[Gunlaug Sørtun]

Web Dandy Design wrote:


Can you advise what would need to be done to the site to 'make it
work' in Opera?


Add...
#left-col {clear: left;}
...and the problem is solved in all browsers and on all resolutions.
The problem was that the left-col got hung up on the horizontal nav's
right edge when that nav grew in height when subjected to font-resizing.

Opera has a 'minimum font size' default value around 9 - 14px depending
on OS and resolution, while Firefox has 'minimum font size' default of
"none".

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] inline floated right problem in Firefox

[Gunlaug Sørtun]

tee wrote:
IE/win handles it like Firefox. Gecko and IE have one 
interpretation of such float line-ups, and Opera and Safari have 
another. I prefer the Op/Saf one since it works well for all cases,

 but it's probably the wrong one :-)


'Probably the wrong one' because it's not according to the CSS spec?


The way I read the specs it _is_ in accordance with them...

" The outer top of an element's floating box may not be higher than the
top of any line-box containing a box generated by an element earlier in
the source document. "[1]

...so, a float _may_ line its top edge up with the top of the text-line
- the line-box[2] - preceding it, which is exactly how Opera and Safari
line up those floats.

Gecko and IE line those floats up with the bottom of the preceding
line-boxes, which is easy to see if you modify the line-height.

Two standard compliant browsers handle the same and other two the 
opposite; judging from IE's history, it's hard to believe IE would 
get it right.


From reading some of the comments in other threads, I think many
designers find it hard to believe that Firefox got it wrong. Maybe
the specs are wrong, or at least difficult to interpret on this point.

Maybe someone should ask for clarification over at the [EMAIL PROTECTED]

regards
Georg

[1]http://www.w3.org/TR/CSS21/visuren.html#float-position
[2]http://www.w3.org/TR/CSS21/visuren.html#line-box
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Spolsky on IE8 flag

[Gunlaug Sørtun]

Lea de Groot wrote:
Joel Spolsky has published an ... interesting article 
http://www.joelonsoftware.com/items/2008/03/17.html


Microsoft failed to follow the evolutionary trail and keep up with
common standards - to the degree that such exists, and now they try to
catch up without causing a revolution with subsequent riots all over
IE/win-hackery land.
I wish the IE team - and us - good luck.

A fresh start would indeed be worth considering - with name and all, but
I can't see that coming :-(

I like "Internet Avenger" for I am a romantic. Who can think of a 
better name?  :)


It already has one: "Internet Exploder", and I'm pragmatic and can't
think of a better name until I see a better browser.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] premature to test/worry new site for IE8?

[Gunlaug Sørtun]

tee wrote:
I am about to start coding for a new site, and client asked me to 
make sure my code will work for IE8, meaning when IE 8 comes out, she

 doesn't need to pay me extra to fix any problem that may occur in IE
 8.Client is from a web media company, though I understand her 
concerns and that she has to answer to her client, but I just don't 
know how or if I should commit to such 'expectation'.


You've got no real IE8 to make anything work for yet, so, no.

IE8b1 is so weak and broken that it doesn't make sense to do anything
but reporting its weaknesses back to the IE-team. Better wait for better
betas or the final version, or else you risk ending up having to redo
whatever you do for it now.

IE8 final will probably be relatively standard compliant - based on what
the IE-team has written about it and what one can imagine from studying
IE8b1, so there's a chance we won't have to do much for it if a design
is made to work well in better browsers.

Advice: just make sure IE8 can't see any fixes for IE6 and IE7, or for
IE/Mac, and leave it at that for now.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Rogue text appears in IE6.

[Gunlaug Sørtun]

Rob Enslin wrote:
I've recently built a website trying to move towards more 
standards-compliant code. After the delight at pushing the site live

my world 'caved in' (a little over-dramatic maybe) this morning when
a colleague noticed rogue 'ls." text some way down the home page.

Live site: http://www.londoncalling2008.com


Delete HTML-comments, and IE6 will stop "duplicating characters".

See: 
for more info about that bug.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] IE7 - content not displaying

[Gunlaug Sørtun]

Likely, James A. wrote:


The footer on the page is not appearing, but the space that it is
meant to hold the footer is present.  I know about the peek-a-boo
effect for IE, but this does not seem to be the case. Does any one
have any suggestions on how to fix this?

Example: http://wisconsin.joekiosk.com/version2/research.php


Start by adding a 'hasLayout'[1] trigger to the bottom-container, for
example...

#idx-content-bottom {height: 1%;}

That'll give IE/win something to hold on to when it tries to figure out
where to display the rest.


BTW: a div is 'display: block' by default, so all those 'display: block'
on divs is "butter on fat" that doesn't help any browser.

regards
Georg

[1]http://www.satzansatz.de/cssd/onhavinglayout.html
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] transitional vs. strict

[Gunlaug Sørtun]

Thierry Koblentz wrote:


On top of using a correct Doctype, authors need to make sure that
nothing (e.g., XML prolog or HTML comment) comes before the DTD or it
will send IE into Quirks mode.


"Quirks mode" is the best mode for the old bugger known as IE6, IMO,
which is why I make sure to always have an xml declaration above an
xhtml 1.0 Strict / Transitional DTD for any regular document.

A comment at the top is not practical though, since that'll disturb
later IE/win versions too.

Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] transitional vs. strict

[Gunlaug Sørtun]

Patrick H. Lauke wrote:

Gunlaug Sørtun wrote:

"Quirks mode" is the best mode for the old bugger known as IE6, 
IMO,


Care to clarify why, exactly?


I listed a few reasons down this page some time ago...
<http://www.gunlaug.no/contents/wd_additions_16.html>
...and nothing seems to have changed since then.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] IE8 beta's a nightmare

[Gunlaug Sørtun]

Jens-Uwe Korff wrote:


Did anyone do some more testing with IE8?


Yes, and I've concluded here...



Do we know any better release date than "mid year"?


The later the better, as the IE-team got plenty left to fix if they want
IE8 to end up as a serious replacement for earlier versions.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] help with menu positioning

[Gunlaug Sørtun]

tee wrote:
My brain isn't working. I thought I  have the answer but it's not 
working :-(


http://lotusseedsdesign.com/menu.html


Missing base-position...

#menu li a {background-position: left top;}

Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] IE6 background image positioning problem

[Gunlaug Sørtun]

Susie Gardner-Brown wrote:


http://crunchie.tedi.uq.edu.au/trials/UCTLC/index6.html



That big image on the right is a bg image in a container that has
absolute positioning. It works fine in Firefox on my Mac, but IE6 it
drops down.



Can anyone see what I'm doing wrong?


You're trying to fixed-position a background, which I don't think you
really want since that means the background is positioned relative to
the browser-window - not the page.

Anyway, IE6 can't handle fixed backgrounds on regular elements inside
body, so it is absolute positioning that background.

Change to...

#entryContainer {
background: #FFF url(entry-bg.jpg) no-repeat 193px 0;

}

...and IE6 will line up with the other browsers - or rather the other
way around but with all parts in the correct places.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] help with menu positioning

[Gunlaug Sørtun]

tee wrote:


Tell me, what do you like for Christmas gift ?


An internet-connection that is extremely fast and works all the time ;-)
(Maybe I'll get one before Christmas, but I'm not holding my breath.)

Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Alt versus Title Attribute

[Gunlaug Sørtun]

[EMAIL PROTECTED] wrote:

So what's the general consensus on the use of null or empty alt
strings as per the reasons outlined in the article below?

http://www.stuffandnonsense.co.uk/archives/accessible_alternatives.html


The choice between alt-text or no alt-text depends entirely on whether
an alt-text contributes something meaningful to the document, or not.
This often makes it hard for authors to decide what's best to add or
leave out, since most of us can't/won't read our documents as text-only.
Even if we do, we will still have the images fresh on our minds, which
affects our ability to make wise decisions.

Basically: If nothing gets lost when an image cannot be appreciated
visually, then its alt-text can be left out. If something/anything
important _do_ get lost, one should use the alt-text to restore the
meaning of the document in a "no-images, text-only" situation to as high
a level as possible - without cluttering it.

My own interpretation of the issue is presented in some length here...

...but whether or not that constitutes any level of consensus amongst
authors/designers is a big unknown.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Alt versus Title Attribute

[Gunlaug Sørtun]

Designer wrote:

I'm getting confused now - on MY IE6, the title is displayed on 
hover, not the alt. I was originally testing with my standalone IE6,

 so I checked on my laptop, (with 'real' IE6) and got the same
result!


Me too. IE/win shows title-text on images when such exists, otherwise it
shows the alt-text if such exists.

The most problematic with IE6' behavior comes when title is used on an
anchor containing an image with alt-text - with or without a title. IE
tends to show the image-title/image-alt while (at least most) other
browsers show only the anchor-title, (if I remember my last battle with
that correctly).

Changes in default-behavior announced for IE8, IIRC. Probably more
confusing than ever.

Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Alt versus Title Attribute

[Gunlaug Sørtun]

Darren West wrote:
There is the argument that you are changing the behaviour of IE, 
however wrong it is, it could be what users expect. I believe Jaws 
ignores empty attributes so all good there ...


I do not think one should meddle with a browser's behavior in minor
cases like "showing alt-text as tool-tip by default". Nothing gets
broken in most cases, and other browsers can show alt-text as tool-tip
too - via an option or add-on.

Only those cases where clearly a wrong and misguiding text pops up on
:hover in IE, should any form of workarounds be applied ... IMO.

Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Help setting current menu state on level2 menus

[Gunlaug Sørtun]

Susie Gardner-Brown wrote:

But when the link has sub-menu items under it, all of those get the 
same treatment! Because the styles are applied to the list item. Can 
anyone think of a way to do this that would not affect the sub-menu?






Add specificity to the selectors for sub-menu styles...

#lhnav #navcontainer li li a { ... }
#lhnav #navcontainer li li a:hover { ... }

...to make those styles override "ACTIVE" styles on first level.


BTW: font-resizing doesn't play well with that menu in any browser, and
IE/win's "em font-resizing bug"[1] doesn't help much either.

regards
Georg

[1]http://www.gunlaug.no/contents/wd_additions_13.html
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Help setting current menu state on level2 menus

[Gunlaug Sørtun]

Susie Gardner-Brown wrote:


Re the font-resizing - sigh!! For a lot of the websites we develop at
 the university here, we're supposed to use this awful template, 
which includes the lefthand menu like this. In the template it's all 
in tables!! I got the way of doing this menu from 
http://demo.pixelsandpages.com/test_dual.html and I thought it 
covered all problems!


For a menu in isolation, yes. When placed in your layout its 'em' sizes
creates more problems than it solves.

Once you start using 'em' for dimensions _one_ place, you'll have to
make sure _all_ elements play well together when subjected to font-resizing.

I already have the base body font size set at 62.5%. Are you saying 
that if I add in "html{ font-size: 100%;}" before that it 
will be OK?


If you check with the CSS validator you'll see that a big chunk of your
stylesheet disappears in a Parse Error - including the font-size on
body. Fix that part and you'll fix the "em bug".

Of course: such a small font-size as 62.5% as base will make the effect
of 'minimum font size' in Firefox and Opera ruin the page...


Of course, I'm a Mac-user, who pretty  much uses Firefox all the 
time. But I do have XP and IE6 installed in Parallels so I check on 
that. But I guess usually after I've developed in FF Mac ... :)


Cross-checking _during_ development will save you time - tons of it.

Testing with regular browser-option well beyond what "normal" users will
expose your work to, will save you from having to deal with
"user-introduced problems" later on.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Should we design for 800x600 screens?

[Gunlaug Sørtun]

Darren West wrote:
An alternative could be to develop with relative sizes for all 
measurements, allowing the interface to be scaled to any screen 
resolution. Examples can be seen at http://www.linkedin.com and 
http://www.sky.com


Dysfunctional examples, but they clearly show what many mean by
"relative sizes" - font-size dependent layouts, without looking into the
potential problems created by such a "framed" approach.

1: wanting or having a need for larger text, doesn't mean one has or
want a larger screen and/or browser-window.

2: having a larger screen and/or browser-window, doesn't mean one wants
or need larger text.

Thus, "relative sizes" means a/the layout only works well within a
certain window-size on a certain screen-resolution with a certain
font-size, and can not adapt well to the end-user's environment and
needs if they deviate from the designer's "frame".
Sounds designer-friendly enough since they get to keep the designed
proportions, but is not what I would call user-friendly.


Page zoom in Opera, Firefox 3 and Safari 3 allow layouts to adjust to
the end-user's environment and needs - unless the designer has declared
"relative sizes" and/or other width-barriers.
Since this user-friendly zoom-feature seems to be on its way in - after
having been found only in Opera for years, it would be better if
designers tried to make sure it could actually work as intended instead
of designing for certain "relative or absolute sized frames".

Since all browsers can also resize fonts (one way or another)
independent of page zoom, "relative sizes" risk creating even more
problems when both font resizing and page zoom are used.

The latest mobile browsers also incorporates page zoom and font resizing
in various forms in order to enhance the experience, so the more freedom
we give those browsers to perform their job the easier it'll be for the
end-user.


Optimizing our designs for an "average" window-size is an ok approach
IMO, as long as we don't "lock them in" so they fail too badly outside
that "average" window.


Personally I optimize for a range of 600 - 1200 in width, and am now
working on extending the "don't fail too badly" range to 200 - 2400 in
width by giving the browsers more freedom to determine proportions.
I also get to keep _my_ design-proportions, since I design for the way
browsers treat my layouts and make as much out of the many variables
introduced by browsers and their various options as I possibly can.

I use 3800 wide screens/browser-windows and mobile browser emulators to
test on, and although there may be quite a few problems getting older
browsers "perfectly" in line, I see no real problems in getting the new
ones to play ball.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Marking Up Poems

[Gunlaug Sørtun]

Must you Australian's *always* have the last say?  ;)


not always, but often. esp if it ends in beer and a party


Is that why what you say most often makes no sense?

:-)

Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***