Font sizes - Best practice... px vs. em

[Brian]

Re: Font sizes - Best practice... px vs. em

Barry Pearson wrote:[color=blue]
> Brian wrote:
>[color=green]
>>Barry Pearson wrote:
>>[color=darkred]
>>>A lot of advice on the web appears to be absolute advice: "do this".
>>>In fact it is really conditional advice: "if you want everyone to be
>>>able to access your web site, do this"; "if you want minimum
>>>maintenanc e effort, do this"; "if you want people with old browsers
>>>to be able to access your web site, do this". Sometimes those
>>>conditions don't apply.[/color][/color]
>[color=green]
>>This is ciwas. The subject is the presentation of web content, most
>>often about the styling of html documents. It's true that I assume
>>that people want to make their content accessible rather than
>>inaccessibl e, and want maintenance to be easy rather than hard.[/color]
>
> Note how you changed what I said to mean something different![/color]

Uh, no. I don't not[ice] that. I can't figure out what you're on about.
[color=blue]
> "if you want everyone to be able to access your web site" became "people want
> to make their content accessible rather than inaccessible". I was making a
> distinction between developing a web site that "everyone" (see my words) can
> access, and one that some can access. I obviously wasn't talking about one
> that was inaccessible![/color]

A website that only some can access is a site that is not accessible
to everyone. You're trying to split hairs that cannot be split.
[color=blue]
> "if you want minimum maintenance effort" became the opposite of "wants a
> solution that is very difficult to maintain".[/color]

Actually, I wrote, "want maintenance to be easy rather than hard"
(it's in the quoted part of this message). I'd consider "minimum
maintenance effort" to be "easy rather than hard."
[color=blue]
> It is easy to appear to refute what I say if you first rewrite what I say to
> be something different that you are able to refute! I choose my words
> carefully. If you paraphrase them, you are pretty certain to get it wrong.[/color]

With all due respect, I think I get you just fine. We've seen these
arguments scores of times. There's nothing new here.
[color=blue]
> if it costs extra development effort to provide
> accessibility to people who are NOT in your target audience[/color]

You have that backwards. Certainly providing extra *content* costs
more money. But this is ciwas, where we discuss not web content so
much as the presentation of that content. And in presentation, it
costs more money to restrict a site's potential audience. If someone
is foolish enough to put up obstacles, it will cost ever more money to
try to overcome those obstacles. You want to save money and time?
don't put up the obstacles in the first place.
[color=blue]
> it is a valid choice not to put in that effort.[/color]

Sure. It's a valid choice not to put in the effort to change the oil
in your car, too. But I wouldn't recommend it. (Sorry: *if you don't
want to replace your transmission*, I'd recommend that you change the
oil.)
[color=blue]
> For example, when I
> display a 700 x 500 pixel 100 KB 24-bit colour photograph, that is hell for
> someone with dial-up VGA (if there is any such person left).[/color]

This is content, not presentation. It appears that you simply refuse
to acknowledge the distinction.
[color=blue]
> I'm realising
> just how much effort can be spent on trying to write CSS that is able to
> accommodate older browsers.[/color]

What does css have to do with displaying a 700x500 pixel photograph?
[color=blue]
> I sometimes come across the assumption (at least implicit) that web site
> developers need to supply what even non-paying viewers want.[/color]

They don't need to do anything unless law requires it. If they want to
write a browser sniffer and refuse to deliver content to all but MSIE
6/Win, they can do so. It might not do what exactly what they want,
but it will reduce their potential audience.
[color=blue]
> I have one web site designed to be accessible by poor people using public
> library computers. Another is targetted at people with good eyesight,
> high-speed internet connection, calibrated monitors, modern software, etc.
> (And that latter audience happens to the one that pays most!) Yes, obviously
> try to write good HTML & CSS. But know your audience, and know when to stop
> wasting any more time on people who are not in your target audience.[/color]

Tailor your content to your audience. Don't[1] try to tailor a
presentation to what you think that audience uses for hardware or
software, where they access it, etc.

Or do try, and limit the audience who would be interested in your
content. Your call.

--
Brian
follow the directions in my address to email me

[Barry Pearson]

Re: Font sizes - Best practice... px vs. em

William Tasso wrote:[color=blue]
> Barry Pearson wrote:[/color]
[snip][color=blue][color=green]
>> Yes it does! I've spent a lot of effort over the last month trying to
>> make my web sites more accessible to people who can't use
>> conventional browsers.[/color]
>
> ok - my point wasn't about you and your web sites. More of a general
> comment, let me restate it: It is less effort to build an accessible
> web site than a broken one - it is certainly less effort to build it
> right the first time than it is to go back and fix up the issues.[/color]
[snip]

Let's see if there something we can agree on:

- For a given development cost, there is a whole range of levels of
accessibility that can be achieved. The trick is to know what the equal-cost
good ways are. (I suspect that this is a point that you and others are trying
to emphasise). It still costs effort - but that is in the learning, rather
than per-page costs.

- There are some things that can be done to further improve accessibility at
relatively low cost. For example, there may be a simple navigation mechanism
that can be devised for a web site then replicated throughout the site via a
template. (One of my sites uses invisible-GIF links to by-pass navigation and
go directly to the first <h1>. Once I had the designed it, I was able to
rapidly replicate it across 100s of pages via "find & replace").

I'll even go to an extreme that you may not have wanted to go to:

- Some things that reduce the accessibility (especially the navigability) of
web sites cost money to put there! (Pop-ups, complex Flash, perhaps frames?
Some of those irritate me, and I am not disabled). "Simple" tends to be more
accessible, and often cheaper - but perhaps not as impressive initially.
However, if the impressive effects can be put via in the style sheets rather
than the HTML, it can be win-win. (And suspect that this is another thing
that you and others believe, given this NG. But only you can say).

But, on the whole, accessibility costs extra. I believe that those who say
otherwise are setting the level too low. A building can be made accessible by
directing wheel-chair users round the back where they can use the freight
elevators. But coming through the front doors is likely to cost extra, even if
done from the start. Builders in the UK believe that Part M of the Building
regulations will add to construction costs, for example wider doors. Yet some
disabled people feel Part M has not gone far enough and may only lead to
"visitable" rather than liveable" housing.

--
Barry Pearson

http://www.Barry.Pearson.name/photography/

http://www.BirdsAndAnimals.info/

http://www.ChildSupportAnalysis.co.uk/

[Barry Pearson]

Re: Font sizes - Best practice... px vs. em

Alan J. Flavell wrote:[color=blue]
> On Fri, 26 Sep 2003, Barry Pearson wrote:[color=green]
>>[/color][/color]
[snip][color=blue]
> But when content which could perfectly well be available to any web
> browser is deliberately made into some kind of less-accessible format
> for the sheer kewlness of the technology, that's when I get crabby.[/color]

Er ... what is this "deliberate ly"? I don't know who, if anyone, that was a
response to but certainly not to anything I've said or believed.

There are plenty of arguments that can be brought to bear against the sort of
thoughtless/silly authoring that you are arguing against. I can make those
arguments myself. Over the last year I've stripped a lot of complexity off my
web sites, such as pop-ups to show photographs, roll-over GIFs, etc. And
obviously one method I've used has been CSSs, to try to make good-looking
pages that don't need "clever" HTML gimmicks.

I was making a much more moderate point. Typically, catering for the more
"extreme" user-technologies, such as small screens, limited colour range,
older or badly-designed browsers, costs extra effeort. (Or if it doesn't, why
do I see so much advice on how to cater for those, all of which costs extra
effort? And why have I found that, indeed, it does cost extra effort?) It is
entirely valid, unless there is specific legislation against it (such as DDA
1995) to focus the development budget and concentrate on the target audience
rather than others who "want" access but are not paying (enough) for it.
[color=blue][color=green]
>> Just because we put up a web site without passwords doesn't
>> mean we have a duty to enable all users in the world to access it.[/color]
>
> But this isn't the point at all. The point, as I see it, is that in
> general, there's no reason to presume that the people who take an
> interest in your specialised web pages are characterised by a
> particular technological profile. Some might first meet your material
> at the office, on a handheld, at an internet cafe or public library
> facility. If you tell them to b*gger off because their technology
> doesn't suit you, how much chance is there going to be that they'll
> dutifully return when they're finally seated at their high-resolution
> high-performance all-safety-catches-off calibrated multimedia station?
> Far more likely they'll say dumb fool of an ill-mannered author, I'm
> not going _there_ again, and visit the next site on their shopping
> list or search index.[/color]

The laws of supply and demand come into play.

One of my web sites is the most authoritative source of information on its
particular area of social concern in the UK. (Perhaps the world?) I've
designed it around the needs of people in public libraries, but even so they
may struggle. But I doubt if they will walk away if they need the information!
In fact, for that web site, the key to maximising the audience isn't the
design of the web site. It is "pressing the flesh". Trying to ensure that the
maximum number of people know about it. They'll come if they need to, as long
as they know about it. Beyond a certain point, my limited effort is best spent
on promotion.

People with most money to spend on photographs ARE characterised by a
particular technological profile. My experience is that they find out in 2
ways (given that I don't actively sell to them). Some browse sites. In that
case the trick is to make the site known to them. Others search for specific
topics. In that case the trick is to make individual photographs known to
search engines. And then to make a good impression on their high-end
equipment, and ensure that it is easy to navigate from the page they find to
my contact details. Those people know all about presentation - they don't make
rash decisions.

If the above sounds like classic marketing - it is. The standard marketing
mix - the 4 "P"s - apply. Product. Price. Place. Promotion. Spread the
resource among these. (There is no point in spending effort making a site
accessible to people who will never hear about it! Or to people who have no
need of it).

--
Barry Pearson

http://www.Barry.Pearson.name/photography/

http://www.BirdsAndAnimals.info/

http://www.ChildSupportAnalysis.co.uk/

[Stephen Poley]

Re: Font sizes - Best practice... px vs. em

On Thu, 25 Sep 2003 15:48:59 -0400, "Peter Foti"
<peterf@systoli cnetworks.com> wrote:
[color=blue]
>Also, what about the differences with font sizes in relation to the actual
>font family? For example, Verdana looks larger than Times, so perhaps
>something that looks good in Verdana font with an em font size will look too
>small when inherited by something with Times font. How are these issues
>addressed in the real world... that's what I'm hoping to learn. :)[/color]

Best bet is simply to avoid fonts which are exceptionally small or
(especially) exceptionally large, like Verdana. In the former case I can
understand that someone might occasionally want to use a script font (at
250% or so) for a particular effect. If the reader doesn't have that
font, the result will look a bit odd, but will be readable. But there
really is no need whatever to use Verdana - its popularity on the Web is
a classic example of people copying without understanding.

--
Stephen Poley

http://www.xs4all.nl/~sbpoley/webmatters/

[kchayka]

Re: Font sizes - Best practice... px vs. em

Barry Pearson wrote:[color=blue]
>
> Typically, catering for the more
> "extreme" user-technologies, such as small screens,[/color]

@media screen, projection {
/* rules hidden from mobile devices and some buggy browsers */
}
[color=blue]
> limited colour range,[/color]

Avoiding conditions where content might be inaccessible to color-blind
users (like red text on green background) should be considered
regardless of content, as should ensuring there is sufficient contrast
between foreground and background colors. Other than that, color range
is probably a minor consideration at best. In your particular case, the
photos are _best_ viewed in certain environments, but they are still
accessible in others. No?
[color=blue]
> older or badly-designed browsers,[/color]

@import "style.css" ; /* hide these rules from older browsers */
[color=blue]
> costs extra effeort.[/color]

So far, the effort has been about 3 lines of code.
[color=blue]
> (Or if it doesn't, why
> do I see so much advice on how to cater for those, all of which costs extra
> effort? And why have I found that, indeed, it does cost extra effort?)[/color]

It depends on what you are trying to achieve whether more than these 3
lines of code are needed. The more complex the layout, the more
additional tweaks are probably needed.

--
To email a reply, remove (dash)un(dash). Mail sent to the un
address is considered spam and automatically deleted.

[Barry Pearson]

Re: Font sizes - Best practice... px vs. em

Brian wrote:[color=blue]
> Barry Pearson wrote:[/color]
[snip][color=blue][color=green]
>> It is easy to appear to refute what I say if you first rewrite what
>> I say to be something different that you are able to refute! I
>> choose my words carefully. If you paraphrase them, you are pretty
>> certain to get it wrong.[/color]
>
> With all due respect, I think I get you just fine. We've seen these
> arguments scores of times. There's nothing new here.[/color]

I doubt that. I suspect that you erroneously assumed that I was saying
something you had seen scores of times before, and responded to that, instead
of what I actually said.

The instant you start to paraphrase what I say, you start to waste your time.
You are then talking to someone who only exists in your imagination. Why not
consider, and respond to, what I actually say?
[color=blue][color=green]
>> if it costs extra development effort to provide
>> accessibility to people who are NOT in your target audience[/color]
>
> You have that backwards. Certainly providing extra *content* costs
> more money. But this is ciwas, where we discuss not web content so
> much as the presentation of that content. And in presentation, it
> costs more money to restrict a site's potential audience. If someone
> is foolish enough to put up obstacles, it will cost ever more money to
> try to overcome those obstacles. You want to save money and time?
> don't put up the obstacles in the first place.[/color]

The people who say that it costs extra resource (time and money) to make CSS
presentation suitable for a wide range of user agents are CSS experts. They
keep doing so on Usenet & the web. Here are the sorts of statements they make.
I suspect you will be aware of such statements:

- Someone criticised one of my web pages and provided an example of how to do
it properly. His example failed the W3C CSS validation. When I pointed this
out, he pointed to the author's explanation of what he had done to cater for a
range of browsers. (I have decided that I will use CSSs that pass the W3C
validation, and not put in browsers hacks that would make it fail. Stuff any
browsers that need such hacks).

- I asked what 2 or 3 browsers I should use to validate my pages. I got back a
long list, and clearly it wasn't complete. (I've decided on a much smaller
set - IE6, Mozilla Firebird 0.6.1, Opera 7.2 & IBM Home Page Reader 3.0, at
the moment. IE5/5.5 is a concern, because it is common. But apart from those,
I'm ignoring earlier browsers. They can take or leave my web sites).

- I saw someone say what he expected the sort of person worth hiring for one's
web development to validate against. He included various things on Mac. (I
have just 1 PC, a laptop, running Windows 2000. I rely on feedback and
guesswork for the rest).

- I was checking out how to do better buttons than the CSS-rollover buttons I
previously had. I came across what I can only call browser hacks. (Eg. {
width: 99.99%; display: block; } because IE5 apparently won't accept 100%!) It
takes effort to check out things like that. I don't know what my pages look
like outside the above range, except for specific feedback. (I've now changed
the buttons for the web sites in my sig. I actually had to use "97%" in one
case because of a flaw in IE6! I have a hypothesis that I should actually have
used 97.14% in that specific case. I quite like the new effect - do they work
on your system?)

- All over the web are those matrixes of CSS-features versus browser-support,
with green, orange, and red boxes, or ticks & crosses. Often they are out of
date, leaving more investigation. NN4.7 is an obvious user-agent to ignore,
and I have noticed experts saying they now do so, along with earlier IEs and
some others. (I simply don't care if a computer running one of those earlier
ones blows up accessing one of my web sites! Their problem, not mine).

- When I first validated some pages against "Bobby", it was like running into
a brick wall. I decided that if it was hard to make a site that could seen
easily into one accessible to disabled people, I simply didn't have the
effort. Eventually, after discussing this with people who actually use
accessibility technology, and trying the IBM HPR myself, I realised that
"Bobby" was, in effect, lying. Indeed, some of its advice would make things
worse in IBM HPR. (It was advice about links with only white space between
them, and hence the proposal to separate such links with extra characters). (I
now treat accessibility as a "programme" , not as a "standard") .

- I validated some CSSs using the Web Design Group validator. They failed, but
they passed the W3C validation. Why? Apparently the WDG works to an older
standard that won't accept ">" for selectors (in this case, child selectors).
I guess older browsers will ignore those too. (I don't THINK that will matter
in this case, but I'm not going to waste time finding out). OK, not a big
deal, but yet another waste of time trying to validate my material.

- I put navigational-assistance links based on invisible-GIFs across much of
one of my web site. How can anyone claim that isn't extra effort?
Accessibility costs effort. Anyone who says otherwise is wrong, or is setting
too low a standard.

If you believe that widely-accessible web sites can be done without extra
cost, perhaps I could have a look at some of yours, to see how you did it?

[snip][color=blue]
> They don't need to do anything unless law requires it. If they want to
> write a browser sniffer and refuse to deliver content to all but MSIE
> 6/Win, they can do so. It might not do what exactly what they want,
> but it will reduce their potential audience.[/color]

It might reduce the potential audience. But it might increase the actual
audience. Consider:

I often seek 80:20 solutions, because of limited resources. Often, getting 80%
of the coverage for 20% of the effort is a good deal. My web sites are only
known to a tiny fraction of the potential audience. If I save 80% (use your
own figure) of the effort on presentation, I might lose 20% of the current
audience. But if I can spend the money instead on reaching a much larger
audience, and only 20% of the extra walk away, I might end up with a much
larger actual audience.

Those won't be the actual numbers, of course. But the principle is valid. If I
can move resource into extra content or extra promotion, there may be a net
gain. So, except for disability, which is a special case, I've stopped
worrying about minority cases that look like wasting too much of my time. Even
disability only gets a certain budget. I probably won't do any more work to
improve accessibility for the disabled next month.

[snip][color=blue]
> Tailor your content to your audience. Don't[1] try to tailor a
> presentation to what you think that audience uses for hardware or
> software, where they access it, etc.[/color]

If it is their hardware & software that causes me problems, obviously I will
tailor it to the software & hardware! Anything else wouldn't make sense.
[color=blue]
> Or do try, and limit the audience who would be interested in your
> content. Your call.[/color]

Or, as I showed above, reach more of the audience who would be interested in
my content, by putting the effort saved effort into promotion.

--
Barry Pearson

http://www.Barry.Pearson.name/photography/

http://www.BirdsAndAnimals.info/

http://www.ChildSupportAnalysis.co.uk/

[Barry Pearson]

Re: Font sizes - Best practice... px vs. em

kchayka wrote:[color=blue]
> Barry Pearson wrote:[color=green]
>>
>> Typically, catering for the more
>> "extreme" user-technologies, such as small screens,[/color]
>
> @media screen, projection {
> /* rules hidden from mobile devices and some buggy browsers */
> }[/color]

But I don't know what rules to hide. That is part of the point I'm making. I
haven't time to study the matter across the complete browser range, nor the
ability to check that the resultant sets (full and reduced) work.

[snip][color=blue][color=green]
>> older or badly-designed browsers,[/color]
>
> @import "style.css" ; /* hide these rules from older browsers */[/color]

Chuckle! I was recently dissuaded from using multiple CSS because of the file
access costs:

http://groups.google.com/groups?as_umsgid=3f7059df.4726916@news.cis.dfn.de

[color=blue][color=green]
>> costs extra effeort.[/color]
>
> So far, the effort has been about 3 lines of code.[/color]

"Why are you charging me £100 for removing that dent with just one blow of the
hammer?" "I'm charging you because I knew where to hit it!".

It is much easier simply to ignore them. If they can see the page - OK. If
they can't - they can walk away.
[color=blue][color=green]
>> (Or if it doesn't, why
>> do I see so much advice on how to cater for those, all of which
>> costs extra effort? And why have I found that, indeed, it does cost
>> extra effort?)[/color]
>
> It depends on what you are trying to achieve whether more than these 3
> lines of code are needed. The more complex the layout, the more
> additional tweaks are probably needed.[/color]

Indeed. I'm doing very simple things, but slowly adding tweaks as something
else fails. Each case takes effort. So I've stopped worrying about the more
"extreme" cases. My web sites that existed a year ago look far worse now to
people who can't use CSS. Because I didn't use CSS then, and now have moved
lots of stuff across. That is another category that I don't bother much
about - sighted people who can't or don't use CSS.

Having said that, I have been having a discussion in uk.net.web.auth oring
about whether a table-using or tableless version of my photograph pages is
better for people without CSS. I have designed HTML & CSS for both cases. She
prefers the table-using version. Do you have a view?

Current version:

http://www.barry.pearson.name/photography/pictures/k94/k94_14_25_3.htm

New version without any tables at all:

http://www.barry.pearson.name/test/k94_14_25_3_tableless.htm

--
Barry Pearson

http://www.Barry.Pearson.name/photography/

http://www.BirdsAndAnimals.info/

http://www.ChildSupportAnalysis.co.uk/

[Tina Holmboe]

Re: Font sizes - Best practice... px vs. em

"Barry Pearson" <news@childsupp ortanalysis.co. uk> exclaimed in <CLCdb.952$hL4. 266@newsfep3-gui.server.ntli .net>:
[color=blue]
> keep doing so on Usenet & the web. Here are the sorts of statements they make.
> I suspect you will be aware of such statements:[/color]

From the statements you qoute, I will be blunt and say: you have been
listening to the wrong people. Let's look at this.


[color=blue]
> - Someone criticised one of my web pages and provided an example of how to do
> it properly. His example failed the W3C CSS validation. When I pointed this[/color]

If an example of how to do something right - and remember: this is a
technical issue, and there IS right and wrong here - does not pass validation
without it being a simple spelling error or similar, then you can quite
safely disregard the advice and the advisor.

Why ? The CSS 'validator' isn't perfect, nor is it a validator in the
strict sense of the word. However, someone who offers an explanation and
a "right" method but has not taken the effort to remove such glaring quality
problems as might be revealed by the CSS lint looses credibility.



[color=blue]
> range of browsers. (I have decided that I will use CSSs that pass the W3C
> validation, and not put in browsers hacks that would make it fail. Stuff any
> browsers that need such hacks).[/color]

Correct methodology. It will, on occation, create problems with user-agents
that are none too picky about what they do to entirely correct CSS, but that
is something one can live with.



[color=blue]
> - I asked what 2 or 3 browsers I should use to validate my pages. I got back a
> long list, and clearly it wasn't complete. (I've decided on a much smaller[/color]

It could never be complete. There are numerous browsers out there which you
have probably never heard of, quite likely can't get at, and probably would
waste your time with.

But that isn't the issue. The correct answer to the question you asked is to
NOT use browsers to "validate" pages. Webpages won't look the same in all
browsers - new or 'old'. That is a concept you're better off forgetting;
it won't happen, it shouldn't happen.



[color=blue]
> set - IE6, Mozilla Firebird 0.6.1, Opera 7.2 & IBM Home Page Reader 3.0, at
> the moment. IE5/5.5 is a concern, because it is common. But apart from those,
> I'm ignoring earlier browsers. They can take or leave my web sites).[/color]

Wrong assumption, right idea. If you do your right, "earlier" browsers
will be able to handle your site just fine - you don't need to do something
as unneighbourly as "ignoring" them.

- Plan the site. This won't take any longer for an accessible one.

- Structure up the information with HTML. Don't mess about with anything
else. No physical markup, no visual markup, no browser specific markup.

- Suggest a design using CSS. Not IE-CSS, not Mozilla-CSS. CSS. Use the
fact that Netscape 4 only supports media="screen" to hide the styles
from it.

- Use ECMAscript / DOM to create decorative or helpful effects, but make
sure no essential functionality is created that way. It won't work in
all browsers, but it won't hurt anyone.

- Use a server-side template/pre-processing tool to assemble the site from
the templates you've created above.

No, basic accessibility does not cost "extra". It's a myth.



[color=blue]
> - I saw someone say what he expected the sort of person worth hiring for one's
> web development to validate against. He included various things on Mac. (I[/color]

Eh ? The person worth hiring is one with a good theoretical grasp of the
issues. Anyone can test against a multitude of browsers - *that won't help
anything*.

Make sure the HTML is correct, the information structured, the CSS not
harmful, and the scripts non intrusive. The rest will sort itself out.

No, it won't look the same. It never will. That isn't a goal. It never was.



[color=blue]
> - I was checking out how to do better buttons than the CSS-rollover buttons I
> previously had. I came across what I can only call browser hacks. (Eg. {[/color]

Y'know, Javascript-based rollover buttons work quite nicely and degrade
even better. CSS works too, as long as you don't expect things to look
the same. All you *must* do is make sure the links never cease to work.




[color=blue]
> - All over the web are those matrixes of CSS-features versus browser-support,
> with green, orange, and red boxes, or ticks & crosses. Often they are out of[/color]

So ignore them. They are not authoritative, and they only lead you believe
even more firmly in the religion that is "It Must Look The Same!".



[color=blue]
> date, leaving more investigation. NN4.7 is an obvious user-agent to ignore,
> and I have noticed experts saying they now do so, along with earlier IEs and[/color]

Experts do not ignore Netscape's 4-series. They make sure CSS is hidden
from it. Even NS 4 is capable of handling structured HTML.



[color=blue]
> - When I first validated some pages against "Bobby", it was like running into
> a brick wall. I decided that if it was hard to make a site that could seen[/color]

Bobby never validated anything, never do, and never will. It is, like
"Site Valet" and Greytower's siteSifter, "accessibil ity lints". It can
make recommendations . It can tip you off to things you've missed.

Bobby, to be even more blunt, is not the best of them. If you want to check
your site's accessibility, run it through the W3C's "Preliminar y Review"
list of checkpoints. It'll not take you long, but it'll cost you thought.



[color=blue]
> "Bobby" was, in effect, lying. Indeed, some of its advice would make things
> worse in IBM HPR. (It was advice about links with only white space between
> them, and hence the proposal to separate such links with extra characters). (I[/color]

It might make things worse in *HPR*. The world is not HPR. Don't disregard
that advice.



[color=blue]
> - I validated some CSSs using the Web Design Group validator. They failed, but
> they passed the W3C validation. Why? Apparently the WDG works to an older
> standard that won't accept ">" for selectors (in this case, child selectors).[/color]

Indeed it does - as is explicitly written on the validator page. It's a
different CSS lint; it works on CSS 1 with some pieces of CSS 2 thrown in.

Whilst I am proud of our CSS lint (the WDGs, that is), we are not
autoritative. The W3C one is, as far as anything automated can be.




[color=blue]
> - I put navigational-assistance links based on invisible-GIFs across much of
> one of my web site. How can anyone claim that isn't extra effort?[/color]

It is extra effort - why the bloody hell do you want to go and do something
silly like that for ? The standard says "A method to skip over navigation";
not "invisible gif navigational assistance links".

"Invisible gif skip-to-link" crap. Ditch that idea. It'll only make things
difficult for some groups, whilst being of little or no use to others. Try
this:

(1) id="content" on the very first element in the content;
(2) <a href="#content" >skip to content</a> before the menu.

Effort ? Yes, on a very, very picky level that IS extra effort. A full five
seconds worth.



[color=blue]
> If you believe that widely-accessible web sites can be done without extra
> cost, perhaps I could have a look at some of yours, to see how you did it?[/color]

You're free to look at ours. Do me a favour first though: don't tell me
it looks ugly. Ugly does not come into it. Ugly is not interesting. Ugly
has no place in this discussion.

It does meet, to the best of my knowledge, WCAG 1.0 'AAA' though. I'm not
going to spend my evening reviewing that once more.



[color=blue]
> Accessibility costs effort. Anyone who says otherwise is wrong, or is setting
> too low a standard.[/color]

When it comes to accessibility, you need to decide what YOUR baseline is.
Unless you live and do work in a jurisdiction in which one is decided
for you - federal work and Section 508 as well as the EU and WCAG 1.0
springs to mind - then YOU are the one who need to define that baseline.

If you want to have an international standard - ie. WCAG 1.0 - as that
base, then there are things you must do. Depending on the baseline, it
might cost you effort. It's not all that likely, though, unless your
methods could do with a very thorough review as it is.

The very first thing, however, is starting to sift *very hard* the sources
and the people you listen to.

--
- Tina Holmboe Greytower Technologies
tina@greytower. net http://www.greytower.net/
[+46] 0708 557 905

[Brian]

Re: Font sizes - Best practice... px vs. em

Barry Pearson wrote:[color=blue]
>[color=green]
>> in presentation, it costs more money to restrict a site's
>> potential audience. If someone is foolish enough to put up
>> obstacles, it will cost ever more money to try to overcome those
>> obstacles. You want to save money and time? don't put up the
>> obstacles in the first place.[/color]
>
>
> The people who say that it costs extra resource (time and money) to
> make CSS presentation suitable for a wide range of user agents are
> CSS experts.[/color]

You continue to refuse to distinguish between content and
presentation. I'm not sure why.

Task: navigation menu. Solution:

<UL class="nav">
<LI><A HREF="portfolio ">portfolio </A></LI>
<LI><A HREF="resume.ht ml">resume</A></LI>
<LI><A HREF="catalog.h tml">catalog</A></LI>
</UL>

This is pretty straightforward , and is fully accessible for all
conforming user-agents. You are 95% of the way there. I'll concede
your point about skip-nav links for the blind. There are, btw, other
examples of accessibility issues that require additional markup and
thus increased work, but so far they have not been discussed in this
thread, whose subject is the decidedly non-content matter of font-size.

Back to our example site. Even without skip links, it is still
largely accessible to the blind. For sighted visitors, you're 100% of
the way there. "Done and done. And I mean done."[1]

Any css that you add is not additional cost to make the site more
accessible. It is additional cost to make the site more visually
appealing, and, perhaps, increase usability. But the list was already
accessible in every browser I've ever used. Mind, I'm not arguing
against adding css to a site.
[color=blue]
> - I asked what 2 or 3 browsers I should use to validate my pages.[/color]

Use an sgml validator to check your html against the dtd. This is not
a css issue, but an html one. Regardless of style, your site should
validate. This helps keep content accessible. But you must also
write to the spirit of html, if you will.

<div class="nav">
<A HREF="portfolio ">portfolio </A></br>
<A HREF="resume.ht ml">resume</A></br>
<A HREF="catalog.h tml">catalog</A></br>
</div>

This is valid html, but less robust than the first solution. Once
again, this is not a css issue.
[color=blue]
> I've decided on a much smaller set - IE6, Mozilla Firebird 0.6.1,
> Opera 7.2 & IBM Home Page Reader 3.0, at the moment. IE5/5.5 is a
> concern, because it is common.[/color]

So, you *test* on these browsers. I'm not trying to nitpick, but it's
helpful to use clear definitions. "valid"/"validate" have precise
meanings in sgml applications.
[color=blue]
> But apart from those, I'm ignoring earlier browsers. They can take
> or leave my web sites).[/color]

You decide these things. But make no mistake, you are talking about
presentation. Take the first example I gave, the <ul> menu solution.
Put that in a web page, and *stop*. That is already accessible, even
in old browsers. Forget NS4, I'm talking NS 2 and Mosaic. Fully
accessible.[2]

You should write robust html, meaning don't misuse elements, and
explicitly close elements even where the closing tag is optional
(<p>...</p>). That will keep certain browsers happy. And I would
recommend testing in several browsers to make sure that it works.
Your list of test browsers seems quite reasonable to me. But with
html 4.01/strict and no additional code, you have a good chance of it
working "out of the box," as they say.
[color=blue]
> If you believe that widely-accessible web sites can be done without
> extra cost, perhaps I could have a look at some of yours, to see
> how you did it?[/color]

http://www.julietremblay.com/ (fine art photography)

http://people.umass.edu/btrembla/ (my personal web site)

NB: in both case, I expended considerable effort on css, including
efforts to make sure that, after adding certain visual effects, the
site was *still* accessible in a suite of test browsers. That is, the
content was accessible before and styling. I wanted to maintain that
accessibility.
[color=blue][color=green]
>> If they want to write a browser sniffer and refuse to deliver
>> content to all but MSIE 6/Win, they can do so. It might not do
>> what exactly what they want, but it will reduce their potential
>> audience.[/color]
>
> It might reduce the potential audience. But it might increase the
> actual audience.[/color]

Doubtful. There is no way to count the visitors you gain from a
spiffy presentation. Besides, as I said much earlier in this thread:
people are on the web for content. And no wonder: the www is a
content-rich medium driven by pull technology. This will likely
elicit a counter argument from you that the web is not always about
content, but then you don't recognize the distinction between content
and presentation.
[color=blue]
> I often seek 80:20 solutions, because of limited resources. Often,
> getting 80% of the coverage for 20% of the effort is a good deal.
> My web sites are only known to a tiny fraction of the potential
> audience. If I save 80% (use your own figure) of the effort on
> presentation, I might lose 20% of the current audience. But if I
> can spend the money instead on reaching a much larger audience, and
> only 20% of the extra walk away, I might end up with a much larger
> actual audience.
>
> Those won't be the actual numbers, of course.[/color]

Therein lies the problem with all such arguments. There is no way to
confirm any actual numbers.
[color=blue]
> But the principle is valid.[/color]

Well, no. Not without real numbers.
[color=blue][color=green]
>> Tailor your content to your audience. Don't try to tailor a
>> presentation to what you think that audience uses for hardware or
>> software, where they access it, etc.[/color]
>
> If it is their hardware & software that causes me problems,
> obviously I will tailor it to the software & hardware! Anything
> else wouldn't make sense.[/color]

What doesn't make sense is to try to guess at their hardware and
software setup, and plan for every possible combination, which would
certainly lead to high develpment costs.

The whole point of html is to avoid that. On the authoring end,
markup the content to describe what it is. On the reader's end,
choose a presentation of the described document that is appropriate to
the device. The author need not know nor concern her/himself with the
properties of the display device (resolution, size, aural
capabilities, etc.).


[1]quoted from Homer Simpson
[2]it's been a while since I used old browsers, e.g., NS2. I'm fairly
certain, though, that it handled lists just fine.

--
Brian
follow the directions in my address to email me

[kchayka]

Re: Font sizes - Best practice... px vs. em

Barry Pearson wrote:
[color=blue]
> kchayka wrote:[color=green]
>> Barry Pearson wrote:[color=darkred]
>>>
>>> Typically, catering for the more
>>> "extreme" user-technologies, such as small screens,[/color]
>>
>> @media screen, projection {
>> /* rules hidden from mobile devices and some buggy browsers */
>> }[/color]
>
> But I don't know what rules to hide. That is part of the point I'm making. I
> haven't time to study the matter across the complete browser range, nor the
> ability to check that the resultant sets (full and reduced) work.[/color]

My suggestion is to hide the same "advanced" CSS rules from both mobile
devices and buggy/old browsers. Don't give them anything more than
basic color and font styles. There is not much point in trying to
position or float elements on a phone or PDA display, is there?

If your html is structurally valid, they can live with no CSS at all.
That's how it should be.

The @import rules will shield some old browsers, the @media rules should
do the rest.
[color=blue][color=green]
>> @import "style.css" ; /* hide these rules from older browsers */[/color]
>
> Chuckle! I was recently dissuaded from using multiple CSS because of the file
> access costs:
> http://groups.google.com/groups?as_u...ews.cis.dfn.de[/color]

8 separate CSS files does seem a bit excessive to me. I won't argue
that there is no cost for retrieving separate files from a server, but I
don't necessarily agree that putting everything in one file is always
the right thing to do, either. It is easier from a maintenance
standpoint to keep some things separated, which is part of the equation,
too. So far, I haven't really needed more than 2 stylesheets.
[color=blue]
> It is much easier simply to ignore them. If they can see the page - OK. If
> they can't - they can walk away.[/color]

That is where structured markup comes in - there shouldn't be any
browsing environment where the user couldn't access the content without
CSS. Even with CSS, it doesn't have to look the same, or even
necessarily be "pretty", it just needs to be accessible and usable.
[color=blue]
> My web sites that existed a year ago look far worse now to
> people who can't use CSS.[/color]

Those who browse without CSS do so for a reason. Why isn't important.
I see no benefit in trying to force something on them when they either
don't want it in the first place, or don't care whether they get it or
not. If they did care, they would likely use a different browsing
environment. Give them structured markup and let the browser take care
of the rest.
[color=blue]
> Having said that, I have been having a discussion in uk.net.web.auth oring
> about whether a table-using or tableless version of my photograph pages is
> better for people without CSS. I have designed HTML & CSS for both cases. She
> prefers the table-using version. Do you have a view?
>
> http://www.barry.pearson.name/photog...94_14_25_3.htm
> http://www.barry.pearson.name/test/k..._tableless.htm[/color]

Nothing personal, but I don't really care for either. I find gray text
on a black background very hard to read - not enough contrast for my
reading pleasure. The italic serif fonts hurt readability even more. I
don't think the photos need a black background to look good, so I would
just as soon override all your CSS.

BTW, I'll never again code a table-based layout. From a development
standpoint, layout tables are a big PITA unless you are using a tool
that generates the code for you. Data tables are bothersome enough for me.

--
To email a reply, remove (dash)un(dash). Mail sent to the un
address is considered spam and automatically deleted.

[Jim Ley]

Re: Font sizes - Best practice... px vs. em

On Sun, 28 Sep 2003 16:54:26 GMT, tina@greytower. net (Tina Holmboe)
wrote:
[color=blue]
> But that isn't the issue. The correct answer to the question you asked is to
> NOT use browsers to "validate" pages. Webpages won't look the same in all
> browsers - new or 'old'. That is a concept you're better off forgetting;
> it won't happen, it shouldn't happen.[/color]

That's ridiculous, QA is as much about user experience as it is with
anything else, you do need to check your documents in user agents,
technical validity is only part of QA. Barrie is certainly aware that
webpages won't look the same, but there's a difference between things
not looking the same, and looking bad in certain UAs - you do need to
check in UAs, which ones, not many at all, but you still need to check
in them.
[color=blue]
> Wrong assumption, right idea. If you do your right, "earlier" browsers
> will be able to handle your site just fine[/color]

Yet to do this "earlier" browsers people in these parts need to do the
"hide CSS from netscape 4", so this requires specialised knowledge to
even work with broken NN4, if you then want to start looking at other
broken browsers you're struggling big time.
[color=blue]
> - Suggest a design using CSS. Not IE-CSS, not Mozilla-CSS. CSS. Use the
> fact that Netscape 4 only supports media="screen" to hide the styles
> from it.[/color]

Why protect NN4, why not protect other UA's with weak CSS
implementations ? what's so special about protecting NN4 - If
protecting browsers is necessary, how do we know only NN4 needs
protection -
[color=blue]
> - Use ECMAscript / DOM to create decorative or helpful effects, but make
> sure no essential functionality is created that way. It won't work in
> all browsers, but it won't hurt anyone.[/color]

So NN4 needs protection from certain CSS, yet using ecmascript/DOM
"won't hurt anyone" that's ridiculous, I wouldn't recommend anyone
who doesn't know the myriad of techniques to use any script in pages
because it will hurt someone.
[color=blue]
> No, basic accessibility does not cost "extra". It's a myth.[/color]

It costs to obtain the knowledge to be able to do it, that is
certainly true, once you have that knowledge certain parts of
accessibile authoring do not cost any more, but other parts do.
[color=blue]
> (1) id="content" on the very first element in the content;
> (2) <a href="#content" >skip to content</a> before the menu.
>
> Effort ? Yes, on a very, very picky level that IS extra effort. A full five
> seconds worth.[/color]

It's also often harmful to the accessibility of the document, what
would be better is to have the content first!
[color=blue]
> You're free to look at ours. Do me a favour first though: don't tell me
> it looks ugly. Ugly does not come into it. Ugly is not interesting. Ugly
> has no place in this discussion.[/color]

Of course it does, the usability and appearance of the site is a key
component to authoring a successful site (above a certain level it's
the usability more than the look, the big successful online brands all
have poor looks but good usability) but looks are important.

Jim.
--
comp.lang.javas cript FAQ - http://jibbering.com/faq/

[Barry Pearson]

Re: Font sizes - Best practice... px vs. em

Jim Ley wrote:

Some excellent points. More responses below.
[color=blue]
> On Sun, 28 Sep 2003 16:54:26 GMT, tina@greytower. net (Tina Holmboe)
> wrote:
>[color=green]
>> But that isn't the issue. The correct answer to the question you
>> asked is to NOT use browsers to "validate" pages. Webpages won't
>> look the same in all browsers - new or 'old'. That is a concept
>> you're better off forgetting; it won't happen, it shouldn't happen.[/color]
>
> That's ridiculous, QA is as much about user experience as it is with
> anything else, you do need to check your documents in user agents,
> technical validity is only part of QA. Barrie is certainly aware that
> webpages won't look the same, but there's a difference between things
> not looking the same, and looking bad in certain UAs - you do need to
> check in UAs, which ones, not many at all, but you still need to check
> in them.[/color]

Right. There are real people using those UAs out there. And some of them,
probably many of them, really do care about the presentation of that they are
seeing. I try to identify my target audience, and even to get inside their
minds. What do I think matters to them? Then act upon the conclusion.

We all know you can't control what the user sees (or perceives some other
way). But I now have a answer (that I've stated earlier here) to the question
"should the web site developer try to ensure that things look the same to
himself/herself, with different browsers, at least with default settings?"

And I think the answer is: "either make them the same or at least understand
why they look different". Because you can learn a lot by doing so, publish
better HTML/CSS, and probably reduce the unwanted variety.

Nearly every time I see a significant difference in the way different browsers
present one of my pages to me, on investigation I find something significant.
I have found errors in my CSS because I have mis-read the spec, or simply
typed it in wrong. I have found bugs in browsers that I can by-pass by some
simple safe avoidance action. I have found aspects where the standards appear
not to have an answer at all.

In each case, the result is better for everyone. Me, because I know more and
have fewer problems to sort out later, and users, because some things that
might puzzle them because of their UAs never become published.
[color=blue][color=green]
>> Wrong assumption, right idea. If you do your right, "earlier"
>> browsers will be able to handle your site just fine[/color]
>
> Yet to do this "earlier" browsers people in these parts need to do the
> "hide CSS from netscape 4", so this requires specialised knowledge to
> even work with broken NN4, if you then want to start looking at other
> broken browsers you're struggling big time.[/color]

Precisely! It is this specialised knowledge that I have decided not to bother
to gain. "Try this hack"; "put in this code and it will by-pass browser XYZ";
get a life!

I'll check my CSS against W3C validator. I'll check my HTML (DOCTYPE = 4.01
Transitional in "standard" mode) against the W3C validator. I'll do the above
test to ensure that either "modern" browsers render the pages the same or else
I understand why not, and I'll check against one of the "readers". After
that - the users can adapt to my pages or walk away.
[color=blue][color=green]
>> - Suggest a design using CSS. Not IE-CSS, not Mozilla-CSS. CSS.
>> Use the fact that Netscape 4 only supports media="screen" to
>> hide the styles from it.[/color]
>
> Why protect NN4, why not protect other UA's with weak CSS
> implementations ? what's so special about protecting NN4 - If
> protecting browsers is necessary, how do we know only NN4 needs
> protection -[/color]

Precisely! (It isn't the only one - as I understand it, other early browers
have their peculiarities. Tough for their users. They'll upgrade when they get
irritated enough).
[color=blue][color=green]
>> - Use ECMAscript / DOM to create decorative or helpful effects,
>> but make sure no essential functionality is created that way. It
>> won't work in all browsers, but it won't hurt anyone.[/color]
>
> So NN4 needs protection from certain CSS, yet using ecmascript/DOM
> "won't hurt anyone" that's ridiculous, I wouldn't recommend anyone
> who doesn't know the myriad of techniques to use any script in pages
> because it will hurt someone.[/color]

I'm going for simplicity. A year ago I had kilobytes of Javascript on each
page. Now I have none. No frames, no pop-ups, no new windows, no Flash, no
animated graphics, and no Java or JavaScript or other active content. My
reading is that that, by itself, makes things vastly easier for disabled
people.
[color=blue][color=green]
>> No, basic accessibility does not cost "extra". It's a myth.[/color]
>
> It costs to obtain the knowledge to be able to do it, that is
> certainly true, once you have that knowledge certain parts of
> accessibile authoring do not cost any more, but other parts do.
>[color=green]
>> (1) id="content" on the very first element in the content;
>> (2) <a href="#content" >skip to content</a> before the menu.
>>
>> Effort ? Yes, on a very, very picky level that IS extra effort. A
>> full five seconds worth.[/color]
>
> It's also often harmful to the accessibility of the document, what
> would be better is to have the content first![/color]

Whatever you have first may be the wrong default! Sighted people can make the
choice easily, so I'm doing what "jake" suggested in uk.net.web.auth oring and
adding a navigation aid.

I may have made the wrong choice of link - I gave a "name" of "h1" to the
Header 1. It will be easy enough to change to an ID at some point. Is it safe
to change all "name" to "id"?
[color=blue][color=green]
>> You're free to look at ours. Do me a favour first though: don't
>> tell me it looks ugly. Ugly does not come into it. Ugly is not
>> interesting. Ugly has no place in this discussion.[/color]
>
> Of course it does, the usability and appearance of the site is a key
> component to authoring a successful site (above a certain level it's
> the usability more than the look, the big successful online brands all
> have poor looks but good usability) but looks are important.[/color]

Precisely! If I am prepared to reprocess and replace one of my photographs on
the web because 2 pixels out of 300,000 were clearly wrong, then I will not
subscribe to any policy of lowering my presentation standards. I have personal
standards, which may be a bit higher than those of some people here.

--
Barry Pearson

http://www.Barry.Pearson.name/photography/

http://www.BirdsAndAnimals.info/

http://www.ChildSupportAnalysis.co.uk/

[Tina Holmboe]

Re: Font sizes - Best practice... px vs. em

jim@jibbering.c om (Jim Ley) exclaimed in <3f771a8d.19349 2998@news.cis.d fn.de>:
[color=blue][color=green]
>> But that isn't the issue. The correct answer to the question you asked is to
>> NOT use browsers to "validate" pages. Webpages won't look the same in all
>> browsers - new or 'old'. That is a concept you're better off forgetting;
>> it won't happen, it shouldn't happen.[/color]
>
> That's ridiculous, QA is as much about user experience as it is with
> anything else, you do need to check your documents in user agents,[/color]

'Valid' has explicit, technical, meaning in the context of the WWW. You
do not 'validate' in a browser. You might test to see if things look
like you want it - sure.


[color=blue]
> technical validity is only part of QA. Barrie is certainly aware that
> webpages won't look the same, but there's a difference between things
> not looking the same, and looking bad in certain UAs - you do need to
> check in UAs, which ones, not many at all, but you still need to check
> in them.[/color]

Which "them" ? There are quite a few, and no *reliable* statistics exist
as to which are in use. So, how many would YOU suggest testing in ? 10 ?
50 ? 500 ?


[color=blue]
> Yet to do this "earlier" browsers people in these parts need to do the
> "hide CSS from netscape 4", so this requires specialised knowledge to
> even work with broken NN4, if you then want to start looking at other
> broken browsers you're struggling big time.[/color]

You are right, I was too kind. Forget about Netscape 4, then.



[color=blue]
> Why protect NN4, why not protect other UA's with weak CSS
> implementations ? what's so special about protecting NN4 - If
> protecting browsers is necessary, how do we know only NN4 needs[/color]

Well, personally I protect two weak browsers: Netscape 4 and IE. But
I wouldn't recommend it. Too much work, too little gain.



[color=blue][color=green]
>> No, basic accessibility does not cost "extra". It's a myth.[/color]
>
> It costs to obtain the knowledge to be able to do it, that is
> certainly true, once you have that knowledge certain parts of[/color]

It costs to obtain the knowledge to do anything. That's part of
living. It is an investment one must be willing to make. If not,
no amount of information provided here will help.


- The of re-implementing a website that was designed poorly, and
built on worse foundation by happy amateurs can be compared to
that of repearing a house with the same problem. It's often
cheaper to knock it down and start over.

- The cost of fixing small problems with accessibility is comparable
to laying a ramp to achive wheelchair access. It doesn't cost much
in terms of concrete or manpower, but won't fix everything that is
wrong.

- The cost of designing and building something *right* the first time
around is marginally higher than doing it *wrong* the first time;
it goes for websites as well as buildings.



[color=blue][color=green]
>> (1) id="content" on the very first element in the content;
>> (2) <a href="#content" >skip to content</a> before the menu.
>>
>> Effort ? Yes, on a very, very picky level that IS extra effort. A full five
>> seconds worth.[/color]
>
> It's also often harmful to the accessibility of the document, what
> would be better is to have the content first![/color]

I seem to recall having this debate before. I've yet to see how an
internal link between two points in a document can be 'harmful' to
accessibility.



[color=blue]
> the usability more than the look, the big successful online brands all
> have poor looks but good usability) but looks are important.[/color]

Oh, I'm pretty sure that some believe a site is more accessible to
*others* if it looks good to *them*.

I just happen to disagree.

--
- Tina Holmboe Greytower Technologies
tina@greytower. net http://www.greytower.net/
[+46] 0708 557 905

[Barry Pearson]

Re: Font sizes - Best practice... px vs. em

kchayka wrote:[color=blue]
> Barry Pearson wrote:[/color]
[snip][color=blue][color=green]
>> But I don't know what rules to hide. That is part of the point I'm
>> making. I haven't time to study the matter across the complete
>> browser range, nor the ability to check that the resultant sets
>> (full and reduced) work.[/color]
>
> My suggestion is to hide the same "advanced" CSS rules from both
> mobile devices and buggy/old browsers. Don't give them anything more
> than
> basic color and font styles. There is not much point in trying to
> position or float elements on a phone or PDA display, is there?[/color]

I have no idea. I don't do such things, or view such things on a mobile.
[color=blue]
> If your html is structurally valid, they can live with no CSS at all.
> That's how it should be.[/color]

Thank you for telling us what all those people who can't/don't use CSS can
live with.

But how do you know? Can you point to the survey? Did you ask all of them?

[snip][color=blue][color=green]
>> Chuckle! I was recently dissuaded from using multiple CSS because of
>> the file access costs:
>> http://groups.google.com/groups?as_u...ews.cis.dfn.de[/color]
>
> 8 separate CSS files does seem a bit excessive to me. I won't argue
> that there is no cost for retrieving separate files from a server,
> but I don't necessarily agree that putting everything in one file is
> always
> the right thing to do, either. It is easier from a maintenance
> standpoint to keep some things separated, which is part of the
> equation, too. So far, I haven't really needed more than 2
> stylesheets.[/color]

See the following. They are described there:

http://www.birdsandanimals.info/web_site/formats.htm

(I use 9, not 8. One is used for the non-photograph pages).

If you can think of a way of reducing the numbers of CSSs, please tell me.

(I wondered if there was a way of using 1 CSS for all the photograph pages,
then using a class in the <body> to select the colour differences. The trouble
is, there are 2 different values of such things as "border-top-color" in each
CSS, so I couldn't see how to make the class-approach work. I wonder if I
could use contextual selectors? I'll investigate when I have time).

[snip][color=blue][color=green]
>> My web sites that existed a year ago look far worse now to
>> people who can't use CSS.[/color]
>
> Those who browse without CSS do so for a reason. Why isn't important.
> I see no benefit in trying to force something on them when they either
> don't want it in the first place, or don't care whether they get it or
> not. If they did care, they would likely use a different browsing
> environment. Give them structured markup and let the browser take
> care of the rest.[/color]

As someone on uk.net.web.auth oring said "We don't all choose our OS primarily
for browsing!"

http://groups.google.com/groups?as_umsgid=183a402d4c.ri48000239@v-liz.co.uk

[snip][color=blue][color=green]
>> http://www.barry.pearson.name/photog...94_14_25_3.htm
>> http://www.barry.pearson.name/test/k..._tableless.htm[/color]
>
> Nothing personal, but I don't really care for either. I find gray
> text
> on a black background very hard to read - not enough contrast for my
> reading pleasure. The italic serif fonts hurt readability even more.
> I don't think the photos need a black background to look good, so I
> would just as soon override all your CSS.[/color]

Your choice. All the common combinations of text colour and background colour
used there pass the thresholds for both the Colour Brightness Formula and the
Colour Difference Formula suggested by the World Wide Web Consortium (W3C).

Perhaps they have it wrong. If they change their recommendation, I'll rethink.
[color=blue]
> BTW, I'll never again code a table-based layout. From a development
> standpoint, layout tables are a big PITA unless you are using a tool
> that generates the code for you. Data tables are bothersome enough
> for me.[/color]

The photographs above didn't use table-based layout. They used tables to
supply semantically-related content. After a lot of thought and discussion, I
think it was the correct mark-up in this case.

Thanks.

--
Barry Pearson

http://www.Barry.Pearson.name/photography/

http://www.BirdsAndAnimals.info/

http://www.ChildSupportAnalysis.co.uk/

[Jim Ley]

Re: Font sizes - Best practice... px vs. em

On Sun, 28 Sep 2003 22:12:02 GMT, tina@greytower. net (Tina Holmboe)
wrote:
[color=blue]
>jim@jibbering. com (Jim Ley) exclaimed in <3f771a8d.19349 2998@news.cis.d fn.de>:
>[color=green][color=darkred]
>>> But that isn't the issue. The correct answer to the question you asked is to
>>> NOT use browsers to "validate" pages. Webpages won't look the same in all
>>> browsers - new or 'old'. That is a concept you're better off forgetting;
>>> it won't happen, it shouldn't happen.[/color]
>>
>> That's ridiculous, QA is as much about user experience as it is with
>> anything else, you do need to check your documents in user agents,[/color]
>
> 'Valid' has explicit, technical, meaning in the context of the WWW.[/color]

No it doesn't it has an explicit technical meaning in the context of
SGML authoring, that doesn't mean it loses its normal meaning, however
I only mentioned QA, are you also intending to disagree that QA is
more than validity?
[color=blue]
> Which "them" ? There are quite a few, and no *reliable* statistics exist
> as to which are in use. So, how many would YOU suggest testing in ? 10 ?
> 50 ? 500 ?[/color]

That would be the authors choice, but it is important to do some QA
against User Agents, especially in a world where we know there are no
spec compliant user agents.
[color=blue]
> It costs to obtain the knowledge to do anything. That's part of
> living. It is an investment one must be willing to make.[/color]

Certainly but we know the costs of learning how to go "file - save as
webpage" from MS office, or Open Office, is very different from the
cost of learning which of all the CSS recomendations work in which of
a myriad of browsers and which need hiding from various UA's.
[color=blue]
>The of re-implementing a website that was designed poorly, and
> built on worse foundation by happy amateurs can be compared to
> that of repearing a house with the same problem. It's often
> cheaper to knock it down and start over.[/color]

Certainly, you still need a skilled builder, and gaining those skills
is expensive - yes you need a professional to do a professional job,
there's no point pretending to the new amateur that there's not a lot
of cost in learning those skills, by saying "it costs no more to do it
right than wrong".
[color=blue]
> I seem to recall having this debate before. I've yet to see how an
> internal link between two points in a document can be 'harmful' to
> accessibility.[/color]

There's a comprehension problem of "jump to content", many UA's won't
move at all on certain documents, leading to confusion...
[color=blue][color=green]
>> the usability more than the look, the big successful online brands all
>> have poor looks but good usability) but looks are important.[/color]
>
> Oh, I'm pretty sure that some believe a site is more accessible to
> *others* if it looks good to *them*.[/color]

Do you also disagree that a site that good looks to you is more
accessible to you? In which case an attempt to make the site look
attractive is very important, looking the same in every browser isn't
something anyone this deep the thread has disagreed on, just the
importance on it looking good in as many situations as possible,
because that is important on usability and comprehension.

Jim.
--
comp.lang.javas cript FAQ - http://jibbering.com/faq/