Simple question... which is better to use for defining font sizes and why?
px and em seem to be the leading candidates. I know what the general answer
is going to be, but I'm hoping to ultimately get some good real world
examples.
Fire away! :)
Regards,
Peter Foti
Jul 20 '05
131  21516 
Peter Foti wrote:
[snip]
I've been thinking about what you are trying to do, and the replies you've
been getting. I think there are 2 very different issues, with different
answers:
1. Should you try to ensure that things look the same to different users, who
may be using different browsers, and will often have different settings?
Much of the discussion has been about this point. I won't add any more here.
2. Should you try to ensure that things look the same to YOU, 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.
Example from recent experience:
I have many multi-column tables with text in. In IE6 the first line of the
text lines up across the row. With Mozilla Firebird it often didn't - in some
cells the text started nearly a line lower. I couldn't just shrug this off -
it looked bad. It turns out that the difference depends on whether the text
starts with <p> or not. Firebird puts extra margin-top on the text where there
is a <p>. (The discussion is in a thread called "Should <p> alter the
rendering?" in uk.net.web.authoring ).
OK, I can at least get them all lined up, for example by making all the text
in the table start <p>, even though I don't like the extra space. But I wanted
more. Firebird also puts extra margin-top on other elements such as headers
when they are first in a table cell compared with other browers. So I stumbled
across "first child pseudo-classes". (Damaged my toe). Super! IE6 doesn't
support them, I believe, but IE6 wasn't my problem. So I put the following in
the CSS (don't respond yet):
td > p { margin-top: 0; }
The problem went away. Then I noticed other anomalies between browsers. On
investigating, I learned that I had mis-read the spec, and should have said:
td > p:first-child { margin-top: 0; }
Suddenly, various things that I had been a bit unhappy with became OK. In
fact, doing this with <hn> elements too appears to be a safe way of curing
what I think is really a mistake in Firebird. (I hope no one will now tell me
that this will have terrible results in IE5 or crash every Mac in Russia!)
I learned something about CSS and about different browsers, and I hope
controlled variety a bit in a safe way. I can't control what happens after
stuff has left my hands, but I can, and should, control what it looks like
before it leaves my hands. You could too. It won't make you a bad person!
--
Barry Pearson http://www.Barry.Pearson.name/photography/ http://www.BirdsAndAnimals.info/ http://www.ChildSupportAnalysis.co.uk/
Brian wrote: Barry Pearson wrote: the web is at the moment a content-rich and production
values-poor medium. If many people are on the web, that indicates
that content means more than style.
No.
Let me explain what I mean: high production values would be animation,
moving images, real-time video, the sort of thing that broadcast
television does well.
[snip]
We have probably been mis-interpreting one-another.
To me, "high production values" doesn't mean all those extras. It really means
"produced for high value to the user". That may mean lots of complications, or
it may mean a very simple site if that is important to the user.
Simply putting in all those extras is more like "high production cost", which
is not what I meant.
I don't think we are disagreeing much, just using different language.
--
Barry Pearson http://www.Barry.Pearson.name/photography/ http://www.BirdsAndAnimals.info/ http://www.ChildSupportAnalysis.co.uk/
Barry Pearson wrote:
[snip] OK, I can at least get them all lined up, for example by making all
the text in the table start <p>, even though I don't like the extra
space. But I wanted more. Firebird also puts extra margin-top on
other elements such as headers when they are first in a table cell
compared with other browers. So I stumbled across "first child
pseudo-classes". (Damaged my toe). Super! IE6 doesn't support them, I
believe, but IE6 wasn't my problem. So I put the following in the CSS
[snip] td > p:first-child { margin-top: 0; }
Suddenly, various things that I had been a bit unhappy with became
OK. In fact, doing this with <hn> elements too appears to be a safe
way of curing what I think is really a mistake in Firebird. (I hope
no one will now tell me that this will have terrible results in IE5
or crash every Mac in Russia!)
[snip]
As a follow-up, just out of curiosity I tried the following as well:
td > p:last-child { margin-bottom: 0; }
Firebird appears to apply that too, and stops putting annoying (to me) extra
space at the bottom of the cell. I believe it is CSS3?
--
Barry Pearson http://www.Barry.Pearson.name/photography/ http://www.BirdsAndAnimals.info/ http://www.ChildSupportAnalysis.co.uk/
Barry Pearson wrote:
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 maintenance 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.
If someone had a 7-year-old and a 5-year-old, then purchased a couple
of hand guns and asked me for advice, I might say, "Put the guns in a
locked cabinet." I would not feel obligated to add a conditional
clause: "If you don't want your 7-year-old to kill your 5-year-old in
an accidental shooting, put the guns in a locked cabinet." In certain
contexts, assumptions make sense.
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
inaccessible, and want maintenance to be easy rather than hard. I
suppose there could be a masochist who wants a solution that is very
difficult to maintain, but (s)he ought to just state that in the op.
Something like, "I want to create a menu on my web site, and I want it
to be really difficult to maintain. If I have to change the name of a
link, I want it to require several days work. How do I do that?" :)
In any case, noone pays for advice. If they don't like what they get,
well, they got what they paid for. Many threads devolve into
accusations ("Who are you to tell me what to do on *my* site?!"). But
this isn't a help desk, it's a forum for discussion. Someone says,
"how do I do X?" Others are then free to discuss implementing X on a
web site, in any way they see fit. FWIW, my own meager input is
motivated largely by my experience as a user of sites whose
presentation is badly done. Not ugly, mind you, but badly done.
All sites don't have a potential audience of all people.
It'd be silly to think one web site will attract everybody. It'd be
wise to make the site accessible for everybody who *wants* to access
it. One best achieves that goal by avoiding unneccessary restrictions
on presentation.
--
Brian
follow the directions in my address to email me
Brian wrote: Barry Pearson wrote:
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
maintenance 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.
[snip] 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
inaccessible, and want maintenance to be easy rather than hard. I
suppose there could be a masochist who wants a solution that is very
difficult to maintain, but (s)he ought to just state that in the op.
Something like, "I want to create a menu on my web site, and I want it
to be really difficult to maintain. If I have to change the name of a
link, I want it to require several days work. How do I do that?"
:)
Note how you changed what I said to mean something different!
"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! (My web sites have different accessibilities).
"if you want minimum maintenance effort" became the opposite of "wants a
solution that is very difficult to maintain". There are grades of maintenance
cost, and they have to be traded off against other things. For example, some
people might put minimum maintenance cost as higher priority than presentation
quality, while others might be prepared to sacrifice some cost to achieve
highest presentation quality. (I adopt different policies on different web
sites).
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.
[snip] All sites don't have a potential audience of all people.
It'd be silly to think one web site will attract everybody. It'd be
wise to make the site accessible for everybody who *wants* to access
it. One best achieves that goal by avoiding unneccessary restrictions
on presentation.
My point was really that if it costs extra development effort to provide
accessibility to people who are NOT in your target audience, but who want to
access it, it is a valid choice not to put in that effort. 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). I'm realising
just how much effort can be spent on trying to write CSS that is able to
accommodate older browsers. It is hard enough to write CSS that works well
with my current test-set - IE6, Mozilla Firebird, and Opera 7.2. (The latter
appears OK). I've decided to ignore the problems of browsers earlier than IE5.
Not my problem. (My sites are still readable with CSS switched off).
I sometimes come across the assumption (at least implicit) that web site
developers need to supply what even non-paying viewers want. For government
sites, within reason, yes. I believe that in the UK Welsh is an official
language that government sites must support. And many sites support other
languages. Good!
But for people who are not constrained by such laws, as I am not, it becomes a
personal choice. I simply have to live with the consequences of my decisions.
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. You don't
have a duty to cater for them. There is a point at which, if they want to look
at your web site, they are the ones who have to make the effort.
I don't argue against "avoiding unneccessary restrictions on presentation". I
am simply saying that if it costs more than the developer willing to spend (in
time or money), the developer is entitled to draw a line and say "the problem
is now at your end - sort yourself out or go elsewhere". That is certainly
what I would say if someone with an uncalibrated monitor wanted me to revise
the colour balance of my photographs!
--
Barry Pearson http://www.Barry.Pearson.name/photography/ http://www.BirdsAndAnimals.info/ http://www.ChildSupportAnalysis.co.uk/
On Fri, 26 Sep 2003, Barry Pearson wrote: All sites don't have a potential audience of all people.
Which to me means there's even _more_ motivation for avoiding
additional obstacles for people who were specifically interested in
that specialised content.
It is entirely valid to develop a site that only 1000 people with
suitable technology will ever be able to view satisfactorily.
If that's the best way to make that particular content available, then
I entirely agree. I also deal with specialised content on occasions.
And speaking as a consumer rather than a developer, I have to say I
was seriously impressed by the SARA Virtual Reality Cave. Pity I
can't find any better pictures than the ones mentioned below, but even
a large picture couldn't do justice to the 3-D dynamics of the actual
thing. Google suggests
http://www.sara.nl/products/products_08a_01_ned.html
http://www.gris.uni-tuebingen.de/con...ides/anton.pdf (PDF,
see slides 7-8).
http://www.nikhef.nl/~stanb/Presenta...ity/sld010.htm
And Stan's remark was spot-on - I too felt some symptoms of
seasickness, even though *we* didn't move at all. At one point in the
demonstration we "flew through" a complex molecular biological
structure, and there were other impressive examples. Such a thing
could absolutely not have been done with an ordinary web browser!
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.
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.
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.
cheers
Barry Pearson wrote: ...
My point was really that if it costs extra development effort to
provide accessibility
it doesn't
to people who are NOT in your target audience,
but who want to access it, it is a valid choice not to put in that
effort.
there are no reliable studies that corelate desktop technology and/or
disabilities with any demographic profile
--
William Tasso - http://WilliamTasso.com
In <vn************@corp.supernews.com> "Peter Foti" <pe****@systolicnetworks.com> writes: Let me correct myself... I want the site to look the same (or very similar)
whether the user is browsing with IE, Mozilla, Opera, or any other UA, but
without taking away the user's ability to make the site use their own
usability settings (for someone with a disability, for example). Also, it
should degrade nicely (for obsolete UA versions, or text based UAs). But
for the most part, I want the user's experience to be the same no matter
which browser they use.
Then don't set a font size for the main text. When there are small
sections that need to be set aside as bigger/smaller, use relative font
size changes. Also, rely on the HTML for positioning/layout rather than
CSS.
--Dan
--
FREE scripts that make web and database programming easier http://www.analysisandsolutions.com/software/
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
4015 7th Ave #4AJ, Brooklyn NY v: 718-854-0335 f: 718-854-0409
William Tasso wrote: Barry Pearson wrote: ...
My point was really that if it costs extra development effort to
provide accessibility
it doesn't
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. I
have a page on each web site describing what I'm doing, but there is no doubt
whatsoever that it costs extra effort! (Do all of your web sites have a page
describing the accessibility programme for the web site?) See links below. http://www.childsupportanalysis.co.u...essibility.htm http://www.barry.pearson.name/web_si...essibility.htm http://www.birdsandanimals.info/web_...essibility.htm
And that is just for people using accessibility technology, such as IBM's Home
Page Reader, which is what I've downloaded and been using to investigate the
issues and check out what I've done. (Also check some of the threads in
uk.net.web.authoring to see the discussions I have been having on the topic).
Trying to cater for older browsers, and people without disabilities who have
limited technology, is proving too much trouble. As a rule of thumb, I
wouldn't spend an extra minute on trying to cater for people who were not
either using accessibility technology, or IE5 or a "6" or "7" browser. Either
they can live with what they get, or adapt to my sites, or they can go
elsewhere. Their problem, not mine. to people who are NOT in your target audience,
but who want to access it, it is a valid choice not to put in that
effort.
there are no reliable studies that corelate desktop technology and/or
disabilities with any demographic profile
Very few keen photographers I have ever come across are blind. And I have met
a lot of keen photographers.
Keen photographers, and people who buy photographs, are among my target
audiences, at least for my personal web site. They often have good eyesight,
high-speed internet connection, calibrated monitors, modern software, etc. The
ones with the most money to spend are also the ones who tend to be fanatics
about presentation quality and meticulous control of font sizes, etc.
Don't mistake me for someone who can't be bothered about accessibility. It
should be clear from the above that I can be bothered, and have spent a lot of
time trying to do something about it.
Which is why I find it a bit irritating when someone says that it doesn't cost
extra extra development effort! Gosh, where did the time go?
--
Barry Pearson http://www.Barry.Pearson.name/photography/ http://www.BirdsAndAnimals.info/ http://www.ChildSupportAnalysis.co.uk/
Barry Pearson wrote: William Tasso wrote: Barry Pearson wrote: ...
My point was really that if it costs extra development effort to
provide accessibility
it doesn't
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.
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.
I have a page on each web site describing what
I'm doing, but there is no doubt whatsoever that it costs extra
effort!
Then we must forever disagree.
(Do all of your web sites have a page describing the
accessibility programme for the web site?) ...
No - I went through a 'phase' when I would do that, but I don't do it any
more. Having said that, I may consider such a page as suitable marketing
material.
...
Gosh, where did the time go?
I dunno - fix ups?
--
William Tasso - http://WilliamTasso.com
Barry Pearson wrote: Brian wrote:
Barry Pearson wrote:
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
maintenance 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. 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
inaccessible, and want maintenance to be easy rather than hard.
Note how you changed what I said to mean something different!
Uh, no. I don't not[ice] that. I can't figure out what you're on about.
"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!
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.
"if you want minimum maintenance effort" became the opposite of "wants a
solution that is very difficult to maintain".
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."
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.
With all due respect, I think I get you just fine. We've seen these
arguments scores of times. There's nothing new here.
if it costs extra development effort to provide
accessibility to people who are NOT in your target audience
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.
it is a valid choice not to put in that effort.
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.)
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).
This is content, not presentation. It appears that you simply refuse
to acknowledge the distinction.
I'm realising
just how much effort can be spent on trying to write CSS that is able to
accommodate older browsers.
What does css have to do with displaying a 700x500 pixel photograph?
I sometimes come across the assumption (at least implicit) that web site
developers need to supply what even non-paying viewers want.
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.
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.
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
William Tasso wrote: Barry Pearson wrote:
[snip] 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.
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.
[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/
Alan J. Flavell wrote: On Fri, 26 Sep 2003, Barry Pearson wrote:
[snip] 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.
Er ... what is this "deliberately"? 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.
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.
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.
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/
On Thu, 25 Sep 2003 15:48:59 -0400, "Peter Foti"
<pe****@systolicnetworks.com> wrote: 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. :)
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/
Barry Pearson wrote:
Typically, catering for the more
"extreme" user-technologies, such as small screens,
@media screen, projection {
/* rules hidden from mobile devices and some buggy browsers */
}
limited colour range,
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?
older or badly-designed browsers,
@import "style.css"; /* hide these rules from older browsers */
costs extra effeort.
So far, the effort has been about 3 lines of code.
(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 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.
Brian wrote: Barry Pearson wrote:
[snip] 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.
With all due respect, I think I get you just fine. We've seen these
arguments scores of times. There's nothing new here.
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?
if it costs extra development effort to provide
accessibility to people who are NOT in your target audience
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.
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] 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.
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] 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.
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.
Or do try, and limit the audience who would be interested in your
content. Your call.
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/
kchayka wrote: Barry Pearson wrote:
Typically, catering for the more
"extreme" user-technologies, such as small screens,
@media screen, projection {
/* rules hidden from mobile devices and some buggy browsers */
}
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] older or badly-designed browsers,
@import "style.css"; /* hide these rules from older browsers */
Chuckle! I was recently dissuaded from using multiple CSS because of the file
access costs: http://groups.google.com/gr*********...ews.cis.dfn.de costs extra effeort.
So far, the effort has been about 3 lines of code.
"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. (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 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.
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.authoring
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/photog...94_14_25_3.htm
New version without any tables at all: http://www.barry.pearson.name/test/k..._tableless.htm
--
Barry Pearson http://www.Barry.Pearson.name/photography/ http://www.BirdsAndAnimals.info/ http://www.ChildSupportAnalysis.co.uk/
"Barry Pearson" <ne**@childsupportanalysis.co.uk> exclaimed in <CL***************@newsfep3-gui.server.ntli.net>: keep doing so on Usenet & the web. Here are the sorts of statements they make.
I suspect you will be aware of such statements:
From the statements you qoute, I will be blunt and say: you have been
listening to the wrong people. Let's look at this.
- 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
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.
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).
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.
- 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
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.
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).
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.
- 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
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.
- 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. {
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.
- 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
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!".
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
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.
- 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
Bobby never validated anything, never do, and never will. It is, like
"Site Valet" and Greytower's siteSifter, "accessibility 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 "Preliminary Review"
list of checkpoints. It'll not take you long, but it'll cost you thought.
"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
It might make things worse in *HPR*. The world is not HPR. Don't disregard
that advice.
- 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).
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.
- 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?
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.
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?
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.
Accessibility costs effort. Anyone who says otherwise is wrong, or is setting
too low a standard.
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 ti**@greytower.net http://www.greytower.net/
[+46] 0708 557 905
Barry Pearson wrote: 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.
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.
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.html">resume</A></LI>
<LI><A HREF="catalog.html">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.
- I asked what 2 or 3 browsers I should use to validate my pages.
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.html">resume</A></br>
<A HREF="catalog.html">catalog</A></br>
</div>
This is valid html, but less robust than the first solution. Once
again, this is not a css issue.
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.
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.
But apart from those, I'm ignoring earlier browsers. They can take
or leave my web sites).
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.
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?
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.
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.
It might reduce the potential audience. But it might increase the
actual audience.
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.
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.
Therein lies the problem with all such arguments. There is no way to
confirm any actual numbers.
But the principle is valid.
Well, no. Not without real numbers. 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.
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.
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
Barry Pearson wrote: kchayka wrote: Barry Pearson wrote:
Typically, catering for the more
"extreme" user-technologies, such as small screens,
@media screen, projection {
/* rules hidden from mobile devices and some buggy browsers */
}
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.
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.
@import "style.css"; /* hide these rules from older browsers */
Chuckle! I was recently dissuaded from using multiple CSS because of the file
access costs:
http://groups.google.com/gr*********...ews.cis.dfn.de
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.
It is much easier simply to ignore them. If they can see the page - OK. If
they can't - they can walk away.
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.
My web sites that existed a year ago look far worse now to
people who can't use CSS.
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.
Having said that, I have been having a discussion in uk.net.web.authoring
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
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.
On Sun, 28 Sep 2003 16:54:26 GMT, ti**@greytower.net (Tina Holmboe)
wrote: 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.
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.
Wrong assumption, right idea. If you do your right, "earlier" browsers
will be able to handle your site just fine
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.
- 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.
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 -
- 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.
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.
No, basic accessibility does not cost "extra". It's a myth.
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.
(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.
It's also often harmful to the accessibility of the document, what
would be better is to have the content first!
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.
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.javascript FAQ - http://jibbering.com/faq/
Jim Ley wrote:
Some excellent points. More responses below. On Sun, 28 Sep 2003 16:54:26 GMT, ti**@greytower.net (Tina Holmboe)
wrote:
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.
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.
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. Wrong assumption, right idea. If you do your right, "earlier"
browsers will be able to handle your site just fine
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.
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. - 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.
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 -
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). - 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.
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.
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. No, basic accessibility does not cost "extra". It's a myth.
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.
(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.
It's also often harmful to the accessibility of the document, what
would be better is to have the content first!
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.authoring 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"? 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.
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.
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/ ji*@jibbering.com (Jim Ley) exclaimed in <3f****************@news.cis.dfn.de>: 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.
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,
'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.
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.
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 ?
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.
You are right, I was too kind. Forget about Netscape 4, then.
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
Well, personally I protect two weak browsers: Netscape 4 and IE. But
I wouldn't recommend it. Too much work, too little gain.
No, basic accessibility does not cost "extra". It's a myth.
It costs to obtain the knowledge to be able to do it, that is
certainly true, once you have that knowledge certain parts of
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.
(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.
It's also often harmful to the accessibility of the document, what
would be better is to have the content first!
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.
the usability more than the look, the big successful online brands all
have poor looks but good usability) but looks are important.
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 ti**@greytower.net http://www.greytower.net/
[+46] 0708 557 905
kchayka wrote: Barry Pearson wrote:
[snip] 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.
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?
I have no idea. I don't do such things, or view such things on a mobile.
If your html is structurally valid, they can live with no CSS at all.
That's how it should be.
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] Chuckle! I was recently dissuaded from using multiple CSS because of
the file access costs:
http://groups.google.com/gr*********...ews.cis.dfn.de
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.
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] My web sites that existed a year ago look far worse now to
people who can't use CSS.
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.
As someone on uk.net.web.authoring said "We don't all choose our OS primarily
for browsing!"
http://groups.google.com/gr*********...**@v-liz.co.uk
[snip] http://www.barry.pearson.name/photog...94_14_25_3.htm
http://www.barry.pearson.name/test/k..._tableless.htm
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.
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.
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.
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/
On Sun, 28 Sep 2003 22:12:02 GMT, ti**@greytower.net (Tina Holmboe)
wrote: ji*@jibbering.com (Jim Ley) exclaimed in <3f****************@news.cis.dfn.de>:
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.
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,
'Valid' has explicit, technical, meaning in the context of the WWW.
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?
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 ?
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.
It costs to obtain the knowledge to do anything. That's part of
living. It is an investment one must be willing to make.
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.
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.
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".
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.
There's a comprehension problem of "jump to content", many UA's won't
move at all on certain documents, leading to confusion... the usability more than the look, the big successful online brands all
have poor looks but good usability) but looks are important.
Oh, I'm pretty sure that some believe a site is more accessible to
*others* if it looks good to *them*.
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.javascript FAQ - http://jibbering.com/faq/
Barry Pearson wrote: William Tasso wrote: Barry Pearson wrote: [snip] 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.
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.
[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.
ok - for me it has been like someone switching on several lights in a dark
room. each light revealing more. I understand that others experience of
the learning may be different, more a gradual assimilation.
html is trivial - if it hurts then one is doing it wrong (as they say)
<div id="heading">
<h1>blondes have more fun</h1>
</div>
<div id="content">
<p>It has been my life's work to verify that blondes do .....</p>
<p>...</p>
<p>...</p>
</div>
<div id="menu">
<li>The ideal blonde</li>
<li>Blondes at large</li>
<li>Blonde attitude</li>
<li>...</li>
</div>
- 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.
page/site construction techniques (although relevent to cost) are immaterial
to the discussion of accessibility which is a client side issue
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!
exactly the point.
(Pop-ups, complex
Flash, perhaps frames?
see, I knew you would get there.
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.
'impressive' is in the eye of the beholder. I don't know if it has meaning
in this context.
However, if the impressive
effects can be put via in the style sheets rather than the HTML, it
can be win-win.
all {ALL} presentational suggestions are best made as CSS
(And suspect that this is another thing that you and
others believe, given this NG. But only you can say).
quite possibly
But, on the whole, accessibility costs extra.
No it doesn't. Please stop saying that. It is untrue.
It may be true that accesibility costs /you/ extra time/effort/resources
atm, but it is *not* generally true.
I believe that those
who say otherwise are setting the level too low.
what level is that?
--
William Tasso - http://WilliamTasso.com
Tina Holmboe wrote: "Barry Pearson" <ne**@childsupportanalysis.co.uk> exclaimed in
<CL***************@newsfep3-gui.server.ntli.net>:
keep doing so on Usenet & the web. Here are the sorts of statements
they make. I suspect you will be aware of such statements:
From the statements you qoute, I will be blunt and say: you have
been listening to the wrong people. Let's look at this.
How do I judge? I have dozens of IE favourites for matters concerned with CSS.
Dozens concerned with validation and other checking. They often contradict
one-another. As you now do.
You are helping to make my point. Instead of being buffeted by the complexity,
I can apply Pareto (the 80:20 principle). Spend basic effort to satisfy 80%,
ignore the 20%, and let them make-do or whatever they choose.
- 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
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.
Here is the case concerned. This is the explanation:
http://www.fivesevensix.com/studies/onetruefit/
Note:
<quote>
Major Accomplishments
I'm happy to say the site looks great in:
IE 5 on OSX
Camino on OSX
Safari on OSX
OmniWeb 4.5 on OSX
IE 6 on Windows
IE 5.5 on Windows
IE 5 on Windows
Opera 7 on Windows
Netscape 6.2 on Windows
Other Mozilla browsers - Netscape 7, Firebird, etc.
Basic style - Netscape 4
Basic style - IE 4.5 on MacOS9
Each browser has its own quirks, but they've been worked around with various
hacks. In a few cases I had to change the design slightly for certain browsers
</quote>
If you look at the rest of the page for the URL, you will see a large number
of problems that the author had to overcome, or felt he had to. How can I, or
you for that matter, judge whether he made the right decisions? Were his
concerns important?
It is much simpler to identify a small set of environments that I want things
to look good in, then ignore the rest. "Chance" will determine what it looks
like there. (Having good HTML & CSS won't ensure that it looks good there!)
I spotted this:
http://www.greytower.net/en/archive/...customcss.html
Gosh!
"Hey ... is it worth it ? Yeah. Yeah, it's worth it" - but not to me!
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.
See above. I think he has gone way beyond the level you are talking about. He
isn't a novice. He gives the distinct impression of being an expert. Or else a
good imitation.
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).
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.
Who knows whether others can live with it? What I have decided is that I don't
care whether they can or not. It is not my problem.
- 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
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.
I now have an 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.
If you can't understand differences even in your own controlled environment,
who knows what will happen "out there"? So: "control the controllables". It
minimise risk and variety.
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).
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.
No they won't. That is quite clear from what I've read. They may be tolerable,
but that is vastly different from "just fine".
[snip] - 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.
No. I'll ignore NN 4, not put in a hack to cater for it. Or any of the others
that you have pointed out exist.
- 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.
I've stopped using scripts. I'm going for simplicity.
- 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.
Then we differ about what "basic" means. I don't think it means sending people
in wheelchairs to the back of the building to use the freight elevators. Or
the web equivalent.
- 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
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. That is clear from lots of published material.
No, it won't look the same. It never will. That isn't a goal. It
never was.
Whose goal? And why should I care about that person's goal?
I have MY own goals. They clearly differ from those of many people who develop
for the web, including you. Although I suspect there are more people who have
my view about the importance of presentation quality in certain cases that
some web authors might admit. I would expect CSS3 to make things easier for
such people over the coming decade or two.
If I have a goal about presentation quality, and find that my target audience
shares that goal and is likely to have suitable technology, we can be a happy
"implicit community". While we are seeing things in very much the same way, we
can ignore people who don't think the web can or should work like that. For
THAT topic. (We may then have different views for other topics). Perhaps only
1% of web-users in the world have that technology, but if there is a close
enough match to my target users, that is fine. It typically doesn't stop other
people having a look - I am happy for that. But they may get a degraded view
(at least in our terms).
- 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. {
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.
I got rid of my GIF buttons & the Javascript to handle them for a variety of
reasons, ncluding download-performance and ease of development. Going for a
CSS-based approach was my original reason for trying CSS. A good move. If the
only thing CSS could do was buttons, I would still use it!
- 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
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!".
Gosh! Do you actually have a clue what your stuff looks like out there?
And how the heck can you say (above) things like "Use the fact that Netscape 4
only supports media="screen" to hide the styles from it", while also telling
me to ignore those matrixes about browser support? Without those matrixes, how
I am supposed to know about Netscape 4?
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
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.
Some people, who appear to me to be experts, have decided it is time to ignore
NN4. I have read stuff on the web that suggests the usage has dropped to the
level where it isn't worth the effort any more. I can't judge whether you know
more or less than they do. But I know what is easiest for me.
- 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
Bobby never validated anything, never do, and never will. It is,
like "Site Valet" and Greytower's siteSifter, "accessibility
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
"Preliminary Review" list of checkpoints. It'll not take you long,
but it'll cost you thought.
I have done. It is like the same brick wall. I assume you mean:
http://www.w3.org/WAI/eval/
"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
It might make things worse in *HPR*. The world is not HPR. Don't
disregard that advice.
Indeed. Yet another browser related complication. When in doubt, I'll have to
go with what I personally know. I based what I did on this article, and the
comparison report he identified:
http://groups.google.com/gr*******************************@gododdin.demon.c o.uk
[snip] - 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?
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".
I did it because someone used to using assistive technologies suggested it.
Here is just one of his articles (he wrote a number of them, including the one
above, which helped me a lot):
http://groups.google.com/gr*******************************@gododdin.demon.c o.uk
Do I listen to you or to him? How much do you use assistive technology?
"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.
What menu? Here is an example:
http://www.childsupportanalysis.co.u...essibility.htm
The invisible GIF is just before the "This web site" at the top.
I've been told it works in practice. Perhaps just to some people, using
certain technology, perhaps not for others. All part of the cost of trying to
make things accessible. Fortunately I'm prepared to try to navigate through
all the conflicting advice to try to get it right eventually. But I won't
sacrifice the presentation for sighted people while I'm doing so.
Note the thread (on uk.net.web.authoring ) for the 2 articles above. I started
that to try to find out how to use alt" and "title" text for thumbnails in
photograph galleries. I now have a good view, and may write it up. But there
is little good advice on the web. And much of what there is is out of date.
Instead of a ready-made solution that can be adopted easily, much of
accessibility apears to be complicated and sometimes contradictory advice to
be navigated through.
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?
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.
Yes it does. For me, for some purposes, ugly is intolerable.
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.
Accessibility costs effort. Anyone who says otherwise is wrong, or
is setting too low a standard.
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.
Indeed. And I appear to chosen a baseline "off the no-cost floor".
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.
Give me a clue - how do I judge?
How can I even judge whether anything you have said is worth listening to? I'm
guessing it is, but you are simply another, contradictory, voice. And I'm
confident that some of the things you have said are wrong (see above).
--
Barry Pearson http://www.Barry.Pearson.name/photography/ http://www.BirdsAndAnimals.info/ http://www.ChildSupportAnalysis.co.uk/
William Tasso wrote: Barry Pearson wrote:
[snip] But, on the whole, accessibility costs extra.
No it doesn't. Please stop saying that. It is untrue.
[snip]
All the evidence I see here and across the web says it costs extra. My own
experience says it costs extra. It costs extra in training. Extra in
validation and other checking. Extra if a sighted person able to have an
overview of aspects of a page can easily do something that someone with a more
serial perception of the page needs extra assistance with.
I believe YOU are the one saying something untrue. We may have to differ on
this. However, if you can show me research / surveys, etc, that demonstrate
that it doesn't cost extra, I will read them and comment upon them.
--
Barry Pearson http://www.Barry.Pearson.name/photography/ http://www.BirdsAndAnimals.info/ http://www.ChildSupportAnalysis.co.uk/
Barry Pearson pounced upon this pigeonhole and pronounced:
Here is the case concerned. This is the explanation:
http://www.fivesevensix.com/studies/onetruefit/
Note:
http://www.onetruefit.com/style/global.css
body { font: normal 11px ...
<quote>
Major Accomplishments
I'm happy to say the site looks great in:
Except the font size is forced and too small.
On this page: http://www.onetruefit.com/privacy.php
in IE6, increasing the text size to Largest only makes the bullets in the
list larger. The font is unaffected and remains too small.
Had he set the font-size to 1em or 100%, it would work. (In my preferred
browser, Firebird, I can increase it because the browser works.
--
-bts
-This space intentionally left blank.
On Mon, 29 Sep 2003, Barry Pearson wrote: All the evidence I see here and across the web says it costs extra.
Most of the evidence I see across the web tells me that putting in
obstacles to accessibility costs extra, and taking them out again
costs even more. I think you can work out what I deduce from that.
It costs extra in training.
Would you hire a stonemason to design a new dress collection? Both are
respectable professions, but one of them is accustomed to dealing with
a medium which is hard and unyielding.[1]
Naturally, for someone accustomed to the stability of paper
publishing, it /would/ need an adjustment to deal with a medium which
has the important property of being _intended_ to adapt itself to a
wide range of sizes and situations.
I don't think anyone is trying to argue that adding _specific_
accessibility features to a page would involve no extra work. But a
large proportion of the pages that we see on the web would be
significantly more accessible if unnecessary obstacles had been left
out, and that's the sense in which some of us, at least, are saying
that basic accessibility comes with the medium, it isn't an expensive
extra as it would be in a building, a vehicle, etc.
None of this is meant to be a criticism of your own pages, and it's a
pity that you sometimes seem to react to general discussion as if you
thought that it was.
cheers
[1] which one, is left as an exercise for the student ;-)
On Mon, 29 Sep 2003 01:26:18 GMT, Beauregard T. Shagnasty
<a.*********@example.invalid> wrote: body { font: normal 11px ...
Except the font size is forced and too small.
A weakness of your UA surely? and there are lots of weak UA's out
there, one of the specific problems Barry is having is that gaining
the knowledge of all these weak UA's is expensive, too expensive for
the vast majority of people.
In any case px is defined to be scaleable to the output medium - I
certainly agree that setting body to any size other than 1em is bad,
but WAI don't say anything against it (not even an until UA's
support), the W3c do it on their own new pages, so I think you need to
be clearer about what is being done wrong here.
I agree with you it's a bad choice, but I get loads wrong.
Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/
"Barry Pearson" <ne**@childsupportanalysis.co.uk> exclaimed in <bU********************@newsfep1-win.server.ntli.net>: I spotted this:
http://www.greytower.net/en/archive/...customcss.html
Gosh!
"Hey ... is it worth it ? Yeah. Yeah, it's worth it" - but not to me!
I see I forgot to include the source of the quote. My fault, for assuming
that noone could have missed it. Perhaps I was a little too subtle in
using that.
I do not - with emphasis - recommend the method I describe in the article
quoted above. Not at all. Avoid it like the plague - avoid it like a
giant cockroach in a brand new Edgar suit.
If you can't understand differences even in your own controlled environment,
who knows what will happen "out there"? So: "control the controllables". It
minimise risk and variety.
None - claims to the contrary be damned - can know what will happen to a
webpage when it reaches it's destination. The trick is to embrace that
idea and live with it.
No, basic accessibility does not cost "extra". It's a myth.
Then we differ about what "basic" means. I don't think it means sending people
in wheelchairs to the back of the building to use the freight elevators. Or
the web equivalent.
That makes me happy to hear - we are making progress. However, why
do you insist on making nicely accessible doorways that only work with
the latest wheelchairs - if people have slightly older, heavier, wider
chairs they can juse take your building or leave it, eh ?
Netscape 4 is an old browser; it needs a tiny amount of coddling to
get it right. But you want to send people using that wheelchair away;
not to the back to the freight elevators, but *away*.
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. That is clear from lots of published material.
There is alot of published material. On the web, and off it. 90% of it
is STILL crap, and there is nothing you can do about it.
Graceful degradation is a fact. Your friend with the one-size-site has
actually managed to achive it *despite* tinkering - not because of it.
for the web, including you. Although I suspect there are more people who have
my view about the importance of presentation quality in certain cases that
some web authors might admit. I would expect CSS3 to make things easier for
If you, by that, mean that there are lots more people that care about how
things LOOK then, yes, you are right.
I am not one of them.
THAT topic. (We may then have different views for other topics). Perhaps only
1% of web-users in the world have that technology, but if there is a close
enough match to my target users, that is fine. It typically doesn't stop other
If your target users are equal to "those using a specific browser", then
that's fine. Go ahead and define your content accordingly.
But it really isn't productive. You can, with the same effort, reach so
many more. With a little more effort, you can reach ... everyone ?
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!".
Gosh! Do you actually have a clue what your stuff looks like out there?
Nope. But: I am fairly certain that only a very few people, if anyone
at all, cannot get to our content. If interested, of course.
And how the heck can you say (above) things like "Use the fact that Netscape 4
only supports media="screen" to hide the styles from it", while also telling
me to ignore those matrixes about browser support? Without those matrixes, how
I am supposed to know about Netscape 4?
That was a diplomatic mistake of mine - *I* would hide CSS from Netscape 4;
and it wouldn't cost any client of mine extra to do so. There is no
measurable cost involved.
If you choose not to do the same, then that IS your choice. It might not
be the most productive one.
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
"Preliminary Review" list of checkpoints. It'll not take you long,
but it'll cost you thought.
I have done. It is like the same brick wall. I assume you mean:
http://www.w3.org/WAI/eval/
That was what I meant, yes. I'm sorry that you see it as a brick wall;
the language used by the W3C can be a little on the gritty side.
Do I listen to you or to him? How much do you use assistive technology?
Here is the gist of it: does it *matter* how much I; or he, uses technology
X ?
As with beauty, accessibility is in the eye of the beholder. There are,
however, a few theoretical ideas that can be used to anticipate how
content will be presented in a person's physical reality.
What menu? Here is an example:
http://www.childsupportanalysis.co.u...essibility.htm
The invisible GIF is just before the "This web site" at the top.
Yes. And this - annoyingly - is what happens to, say, a user with the
latest version Mozilla, full sight, but restricted to using the keyboard:
(1) I type the URI into the address field of my browser,
(2) I press Enter, and it loads,
(3) I press tab to navigate to the first link,
(4) The focus - the outline around links - disappear. I can't find it.
"What ... where did the focus go ? Where am I ? Oh. Invisible gif to
skip navigation. Brilliant"
The site is paying lip-service to some accessibility standard without
bothering to understand it. This says it all:
<blockquote
cite="http://www.childsupportanalysis.co.uk/this_web_site/accessibility.htm">
Pages are also being tested against the "Bobby" standards for
accessibility.
</blockquote>
There is no "Bobby standard"; it is merely a lint, and it is leading
them - and you - astray.
Let's have a look at what the standard - WCAG - says on the topic:
<blockquote cite="http://www.w3.org/TR/WCAG10-HTML-TECHS/#group-bypass">
Navigation bars are usually the first thing someone encounters on a page.
For users with speech synthesizers, this means having to hear a number
of links on every page before reaching the interesting content of a page.
</blockquote>
I'll have to admit that this is poorly written - and lacks the phrase
"for example". A method for skipping over a navigational menu gives an
advantage to many users; it isn't restricted to those using a speech
browser. Everyone who need to bypass one section of a page (a menu)
can benefit. Think of it as an advanced "table of contents" - but would
you ever make a table of contents into a GIF and *hide* it ?[*]
I've been told it works in practice. Perhaps just to some people, using
It does, for a subset of users. Everyone else fails to benefit.
all the conflicting advice to try to get it right eventually. But I won't
sacrifice the presentation for sighted people while I'm doing so.
And you don't need to. See below, please.
Note the thread (on uk.net.web.authoring ) for the 2 articles above. I started
that to try to find out how to use alt" and "title" text for thumbnails in
photograph galleries. I now have a good view, and may write it up. But there
is little good advice on the web. And much of what there is is out of date.
Since you obviously know the WDG website, did you try the emminent article
by Alan Flavell on the topic ? It is certainly the best one I know of
in the field, and it does refer to thumbnails for images.
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.
Yes it does. For me, for some purposes, ugly is intolerable.
Yes - but that is a matter of taste; your personal taste. Which is
fine. I won't argue with it; I've never seen any proof that there exist
a universal taste; I wouldn't believe it if I saw it.
But: when all is said and done, the impossibility of prediction that
is a fact of life on the Web remains.
Yes, you could - and should, if it is important to you - use CSS to
create a packaging of content with which you feel comfortable. That
packaging won't last.
At some point down the line, the packaging will be stripped off and
the content laid bare - and that's where HTML and structure comes
into play. So far, so good. Let's revise my list from earlier:
- Plan your work. Look over the content you want to include on the
site, and determine how you want to organize it.
- Structure each piece physically (on disk) and logically (HTML). This
is when you create the templates you'll later use.
- Apply CSS to the structures. Many people find it useful to see the
results; so they use a reference browser. Mozilla is currently the
UA with best support for CSS.
- Add scripting if you absolutely must. Eyecandy is appreciated by
many; but forget about client-side functionality unless you have
very special needs.
- Use a server-side processing system to fill the templates with content
from files or databases.
- Publish.
A CSS aware browser will attempt to render your suggested layout, unless
the user tells it not to. A HTML agent will simply render the structure
as is, in the default fashion, or the way the user has configured it to
do.
It won't ever look exactly as you envisioned it - there will always
be differences; even with exactly the same technology as you use.
- For some, it'll look broadly as you wanted it to.
- For some, it'll look somewhat as you wanted it to.
- For quite a few others it'll look ... default.
- For many it won't "look" at all; it'll sound, or feel.
- For a number of people it won't look, sound, or feel, because their
browser mistakingly believe it knows CSS.
But most everyone will be able to get to your content - and it hasn't
cost you anything *more*.
Then you can start on the tiny details that might *enhance* the
possibility of people getting to the content; such as hiding CSS from
Netscape 4, including (textual) skip navigation links, and soforth.
But these things are also only needed once: as soon as that skip navigation
link is in place in the template, it will propagate to all the other
documents on the site. As soon as you've included the hide-from-NS-4
hack, it'll function on all pages.
When building a website from scratch is counted in the USD 85 per hour
priceclass (oh, yes, atleast here), then the extra minutes spent on
adding that textual link is neglible.
The baseline is up to you - but the basics never change; once you are
done with them you'll have met WCAG 1.0 'A' and most of 'AA'.
Yes, you'll need to learn alot - but you don't need to learn a
"special form of HTML", for instance. HTML is accessible. If you learn
HTML, and learn it right, you're well on your way. There isn't any
extra cost in learning something right, is there ?
The very first thing, however, is starting to sift *very hard* the
sources and the people you listen to.
Give me a clue - how do I judge?
How do you judge the information you receive in everyday life ? What you
find on the Internet is not really any different, save that it is often
in far prettier packages.
How can I even judge whether anything you have said is worth listening to? I'm
Good point. I can't convince you, and to be honest: I shouldn't. You'll
need to do that yourself.
Me, I don't think I want to continue this debate. It's pretty off topic and
I don't like it very much. But good luck in sifting through the debris that
is sure to follow.
[*]
We've hidden our textual skip-to-content link. That is one of the things
that really could be improved.
--
- Tina Holmboe Greytower Technologies ti**@greytower.net http://www.greytower.net/
[+46] 0708 557 905
Jim Ley pounced upon this pigeonhole and pronounced: On Mon, 29 Sep 2003 01:26:18 GMT, Beauregard T. Shagnasty
<a.*********@example.invalid> wrote:
body { font: normal 11px ...
Except the font size is forced and too small.
A weakness of your UA surely?
Not my UA. I notice you snipped the rest of my post, where I went on to
say: "(In my preferred browser, Firebird, I can increase it because the
browser works.)" A simple Ctrl-Plus.
I was pointing out that the millions of IE users who don't know how to
override the author's font choice will see small text.
and there are lots of weak UA's out
there, one of the specific problems Barry is having is that gaining
the knowledge of all these weak UA's is expensive, too expensive for
the vast majority of people.
In any case px is defined to be scaleable to the output medium - I
certainly agree that setting body to any size other than 1em is bad,
but WAI don't say anything against it (not even an until UA's
support), the W3c do it on their own new pages, so I think you need to
be clearer about what is being done wrong here.
Sorry, I thought I was clear.
"On this page: http://www.onetruefit.com/privacy.php
in IE6, increasing the text size to Largest only makes the bullets in the
list larger. The font is unaffected and remains too small."
I agree with you it's a bad choice, but I get loads wrong.
Jim.
--
-bts
-This space intentionally left blank.
Barry Pearson wrote: kchayka wrote: Barry Pearson wrote:
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've already spent much more time on this than I intended. If you
really want assistance with this, I suggest you start a new thread. My web sites that existed a year ago look far worse now to
people who can't use CSS.
As someone on uk.net.web.authoring said "We don't all choose our OS primarily
for browsing!"
http://groups.google.com/gr*********...**@v-liz.co.uk
What does OS have to do with it? The user either browses with CSS or
without it. The poster in the message you reference apparently goes
without due to system resource issues with graphical browsers, not that
it matters. The only important point is that they browse without CSS.
They still deserve access to content, don't they? BTW, I'd venture to
say that the poster probably cares less about aesthetics than you do.
http://www.barry.pearson.name/test/k..._tableless.htm
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).
<URL:http://www.w3.org/TR/AERT#color>
"Requirement: Determine color visibility.@@needs work?"
"This is a suggested algorithm that is still open to change."
IOW, don't take it as gospel. I'm sure that on your high-end, carefully
calibrated monitor everything looks peachy, but not everyone has such a
configuration. Nor does everyone have perfect lighting, the perfect
work space, or perfect eyesight.
If you search a bit more, you may find some articles on using dark
backgrounds vs light ones and which is generally better for on-screen
readability.
--
To email a reply, remove (dash)un(dash). Mail sent to the un
address is considered spam and automatically deleted.
"Barry Pearson" <ne**@childsupportanalysis.co.uk> wrote in
news:Uf*****************@newsfep2-gui.server.ntli.net: 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.
I don't think that anybody would argue that *retrofitting* accessibility
doesn't cost extra. If your doors are too small for a wheelchair to get
through, there's not a builder in the world who would enlarge them for
free. But those arguments don't apply to designing accessiblity in *from
the beginning*. If you haven't built your doors yet, no builder is going
to charge you extra for making them a little wider, since it doesn't cost
them anything extra to do so.
The key here is to realize that accessibility is a form of quality, and all
forms of quality are cheap or free to build into a product or service, but
quite expensive to add after the fact. Designing a process to produce
parts that all do better than to meet spec is easy and cheap. Culling out
parts that don't meet spec because the process that produces them relies on
luck to meet spec is hard and expensive. The manufacturing world learned
this decades ago.
On Mon, 29 Sep 2003 03:34:13 GMT, Beauregard T. Shagnasty
<a.*********@example.invalid> wrote: "On this page: http://www.onetruefit.com/privacy.php
in IE6, increasing the text size to Largest only makes the bullets in the
list larger. The font is unaffected and remains too small."
Yes, there's just no relevance to accessible authoring in saying that,
it's just a known bug in IE, there's thousands of known bugs in
browsers and if you're saying we can't use parts of the spec because
of those browsers then how is the author supposed to know all the
bugs?
Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/
Stephen Poley wrote: On Thu, 25 Sep 2003 15:48:59 -0400, "Peter Foti"
<pe****@systolicnetworks.com> wrote:
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. :)
Best bet is simply to avoid fonts which are exceptionally small or
(especially) exceptionally large, like Verdana. In the former case I can
Maybe an other possibility would be use the font-size-adjust property in
CSS (see http://www.w3.org/TR/CSS2/fonts.html...t-size-adjust).
I use it myself with a value I chose by trial and error but the result
is very satisfying... in Gecko-based browsers, because IE ignores this
property.
--
to email me, add "poinot" before the at-sign in my
address and wanadoo after it...
Beauregard T. Shagnasty wrote: Barry Pearson pounced upon this pigeonhole and pronounced:
Here is the case concerned. This is the explanation:
http://www.fivesevensix.com/studies/onetruefit/
Note:
http://www.onetruefit.com/style/global.css
body { font: normal 11px ...
<quote>
Major Accomplishments
I'm happy to say the site looks great in:
Except the font size is forced and too small.
[snip]
Indeed! One thing I have done as a result of this thread is remove all
font-related "px" from all my CSSs. (I got rid of all "font" in my HTML over
the last month or so). (I hope!)
I went through every font size I found, and replaced it by a % that displayed
the same in the set of browsers I use at their default settings. (IE 6, Opera
7.2, Firebird 0.6.1). Then I tested that all those browsers' text-size
adjustment worked as expected. (I only use font size adjustment for special
purposes anyway - headings, buttons, and admin stuff).
This still leaves me with the question of best practice in the body { } rule.
In fact, it applies to all font properties. (The other main one for me being
the font-family). I'm not seeing a clear consensus about how to tackle that. A
huge proportion of sites on the web specify one or both of these. (Many of
those that don't specify them in the body rule set them by more specific
rules).
I've been confused by the following page: http://msdn.microsoft.com/library/de...rties/font.asp
It is talking about the "font" property in CSS. (I use such a DOCTYPE):
"As of Internet Explorer 6, when you use the !DOCTYPE declaration to specify
standards-compliant mode, the following conditions apply to this property. The
font-size and font-family values must be declared. If font-size and
font-family are not declared, or are not in the correct order, the font
property is ignored. All specified values must appear in the correct order.
Otherwise, the font property is ignored. In standards-compliant mode, the
default font-size is small, not medium. If not explicitly set, font-size
returns a point value".
That last bit was a puzzle - it appears to say the IE 6 is not obeying the CSS
specification properly. Or it may mean something else entirely! It has led me
to specify "medium" in the body rule. I get the expected results in the
browsers I use, but I haven't a clue what it does to other cases "out there".
Is there actually a consensus on best practice for font properties in the body
rule? If there is, what are the implications for all those web sites?
--
Barry Pearson http://www.Barry.Pearson.name/photography/ http://www.BirdsAndAnimals.info/ http://www.ChildSupportAnalysis.co.uk/
Jim Ley wrote:
[snip] A weakness of your UA surely? and there are lots of weak UA's out
there, one of the specific problems Barry is having is that gaining
the knowledge of all these weak UA's is expensive, too expensive for
the vast majority of people.
[snip]
Thanks, Jim. Yes, that is indeed my problem.
And, as you say, a problem for others. It appears to me that, given that a
huge number of web sites are developed by people who don't know what best
practice is, the web will continue to be awash with not-best-practice. (I
suspect that all the advice from experts will have approximately the same
effect as advising everyone to like one-another so that we can have
world-peace!)
That in turn probably means that the trend will be for UAs to provide ever
more user-control, and current UA limitations are a temporary glitch. I'm not
sure what conclusions can be drawn from that.
--
Barry Pearson http://www.Barry.Pearson.name/photography/ http://www.BirdsAndAnimals.info/ http://www.ChildSupportAnalysis.co.uk/
Barry Pearson wrote: William Tasso wrote: Barry Pearson wrote: [snip] But, on the whole, accessibility costs extra.
No it doesn't. Please stop saying that. It is untrue.
[snip]
All the evidence I see here and across the web says it costs extra.
evidence?
My own experience says it costs extra.
It only costs extra if it is broken by design.
I believe YOU are the one saying something untrue.
so it seems
We may have to differ on this.
yep
However, if you can show me research / surveys, etc,
that demonstrate that it doesn't cost extra, I will read them and
comment upon them.
Sure, I'll write any report you like. Just send over your P.O. and the
ncessary data for credit references with your commission documentation and
I'll be off. Please allow for a minimum 21 days at (£900 + £250 exes) £1150
+ VAT (if applicable in your location). Please allow extra for travel and
accommodation if you require a personal presentation to your board of
directors. I am currently available from Tuesday of next week.
toodle-pip.
--
William Tasso - http://WilliamTasso.com
"Barry Pearson" <ne**@childsupportanalysis.co.uk> wrote: I've been confused by the following page:
http://msdn.microsoft.com/library/de...rties/font.asp
It is talking about the "font" property in CSS. (I use such a DOCTYPE):
"As of Internet Explorer 6, when you use the !DOCTYPE declaration to specify
standards-compliant mode, the following conditions apply to this property. The
font-size and font-family values must be declared. If font-size and
font-family are not declared, or are not in the correct order, the font
property is ignored. All specified values must appear in the correct order.
Otherwise, the font property is ignored. In standards-compliant mode, the
default font-size is small, not medium. If not explicitly set, font-size
returns a point value".
That is rather badly written isn't it?
That last bit was a puzzle - it appears to say the IE 6 is not obeying the CSS
specification properly. Or it may mean something else entirely! It has led me
to specify "medium" in the body rule. I get the expected results in the
browsers I use, but I haven't a clue what it does to other cases "out there".
If you set font-size: medium; in your CSS then you would expect this
to appear at the user's/browser's default font size, wouldn't you?
Not if you work for MS!
IE, up to version 5.5 assumed that the browser's default was what
should appear if you set font-size: small.
In IE6 doctype sniffing means that font-size: medium may be the
browser default size (if standards mode s triggered) or may be larger
than the default size (if quirks mode is triggered).
(NB, the CSS font-size: small, medium, etc., has nothing to do with
the IE font sizing, smallest, smaller, medium, etc. Whichever size is
set in the IE preferences is the browser default and hence becomes CSS
small/medium)
Opera also complicates matters. It used to get it right, then it got
it wrong and now it sniffs doctypes.
Is there actually a consensus on best practice for font properties in the body
rule? If there is, what are the implications for all those web sites?
If you set a font size for body then set it at either 100% or 1em (or
maybe at 101% to cope with an Opera 5/6 bug). 100% is preferred as it
avoids an IE bug when the default size in the browser is set to
anything other than Medium.
Of the other font properties, it would be rare to set font-weight,
font-style or font-variant on body. Setting font-family is common and
the only advice is to avoid fonts like Verdana that _appear_ to be
very different in size to the 'average'.
Steve
--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor
Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>
Brian wrote: Barry Pearson wrote:
[snip] 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.
[snip]
I fully understand the difference between content and presentation. This leads
me to believe you haven't been reading what I've saying. I'm convinced that
you have put me in a category that you have experience of, and you are then
responding to that category. I also appreciate the finer distinction between
structure, content, and presentation.
I want to use an example from one of your sites to make a point. So first,
I'll say that I think your sites are very well designed and make some of your
points well. And I think Julie Tremblay's photographs are excellent. I'll
spend more time looking at these sites.
She has a photograph "Bronze Woman". It is not only an image of a woman, but
also has a border like that of a photographic film. I can't tell whether it
comes from the original or was added later. It doesn't matter. People use both
techniques, for example in Photoshop. http://www.julietremblay.com/portfol...onze_woman.jpg
As far as HTML is concerned, this border is "content". I have seen
photographic sites where a border has been added some other way. It is
probably possible to add a border as further content in the HTML. It is
obviously possible to add borders via CSSs, and I do so throughout my web
sites. In that latter case, are they presentation or content? According the
language here, they are presentation. http://www.barry.pearson.name/photog...01_09_09_2.htm
But, stepping out of the narrow scope of HTML and CSS, I believe all those
borders are presentation. Sometimes they are simply presentation added at an
earlier stage of the process so that HTML sees them as content. I could easily
replace the borders, that I currently add to my photograph pages via CSS, by
borders that look identical across a large range of browsing conditions yet
are part of the JPEG.
I think Julie Tremblay and I have something in common. We both care
passionately how our photographs are presented to the viewer, including such
presentation details as the nature of the area around the image. We probably
both don't care much about fine distinctions between changes of name (from
"content" to "presentation") depending on where in the total process, from
taking the photograph to having it presented to the user, the details are
added.
Julie clearly wants that border round the photograph, exactly as she envisaged
it. It is her "work", and that is part of the work. I want borders round my
photographs exactly as I envisage them, for exactly the same reason. I accept
that once I have put them on the web, I have no final control. But ... I want
to ensure that in the maximum possible range of browsing conditions, they
appear exactly as I envisage them. If that makes me a control-freak, then
realise that Julie is even more of a control-freak, by locking the
presentation details in at an earlier stage.
Where the HTML content is inherently visual, distinctions between content and
presentation get frustrating, and ultimately get in the way of treating the
web as a full partner in the process of displaying that material.
It is related to another issue I've raised. The W3C recommendation for the
"px" unit in CSS is that it is a relative measure, related (approximately) to
the angle subtended at the eye. That is presentation, in terms used here. An
image in the HTML is content. Now what is the visual relationship between an
image of <img ...width="700">, and a description underneath it of { width:
700px; }? What should it be? I believe the "px" presentation value should be
"inherited" from the UA's pixel value, (or perhaps vice-versa, but surely the
UA is what knows?), but I can't find any indication to this effect. I worry
that the separation of presentation and content may screw up the display of
many pages on the web.
--
Barry Pearson http://www.Barry.Pearson.name/photography/ http://www.BirdsAndAnimals.info/ http://www.ChildSupportAnalysis.co.uk/
On Mon, 29 Sep 2003, it was written: Best bet is simply to avoid fonts which are exceptionally small or
(especially) exceptionally large, like Verdana. In the former case I can
Maybe an other possibility would be use the font-size-adjust property in
CSS (see http://www.w3.org/TR/CSS2/fonts.html...t-size-adjust).
That's what it was put there for, indeed. Except that it doesn't
really deal with Verdana, since Verdana seems subjectively
significantly larger than its objective em/ex ratio would imply (as
has been repeated numerous times before on this group).
If font-size-adjust could be based on some kind of subjective size
parameter for each font, it might be put to effective use. But...
But worse than all that, browser implementers wouldn't implement it,
and so the CSS2.1 working draft has dutifully taken it out of the
spec.
I use it myself with a value I chose by trial and error but the result
is very satisfying... in Gecko-based browsers, because IE ignores this
property.
[Cue standard response...]
Steve Pugh wrote: "Barry Pearson" <ne**@childsupportanalysis.co.uk> wrote:
I've been confused by the following page:
http://msdn.microsoft.com/library/de...thor/dhtml/ref
erence/properties/font.asp
It is talking about the "font" property in CSS. (I use such a
DOCTYPE):
"As of Internet Explorer 6, when you use the !DOCTYPE declaration to
specify standards-compliant mode, the following conditions apply to
this property. The font-size and font-family values must be declared.
If font-size and font-family are not declared, or are not in the
correct order, the font property is ignored. All specified values
must appear in the correct order. Otherwise, the font property is
ignored. In standards-compliant mode, the default font-size is small,
not medium. If not explicitly set, font-size returns a point value".
That is rather badly written isn't it?
Chuckle! Just a bit. That last bit was a puzzle - it appears to say the IE 6 is not
obeying the CSS specification properly. Or it may mean something else
entirely! It has led me to specify "medium" in the body rule. I get
the expected results in the browsers I use, but I haven't a clue what
it does to other cases "out there".
[snip]Is there actually a consensus on best practice for font properties in
the body rule? If there is, what are the implications for all those
web sites?
If you set a font size for body then set it at either 100% or 1em (or
maybe at 101% to cope with an Opera 5/6 bug). 100% is preferred as it
avoids an IE bug when the default size in the browser is set to
anything other than Medium.
[snip]
Aaaaarrrggh!
I currently have "medium" in the body rule throughout several CSSs on a number
of web sites. I don't want to change it to "1em" or "100%" if that would be
the same.
I have been influenced by something at W3Schools: "Note in IE 4.0+: Default
value of this property is "small", not "medium" as it should be according to
the W3C specification". And, indeed, the W3C statement is "Initial: medium".
So I assumed that if I specified "medium" in the body rule, I would simply
have a correct but redundant declaration in later browsers, but make earlier
IEs behave to standards. That sounded good to me - a sort of safe browser
hack.
Was that a mistake? Have I screwed up users who had corrected the IE bug using
their IE "view" setting? Do I NEED to change?
(IE 6 appears to behave exactly the same whether I say "medium" or not - I use
4.01 Transitional standards-compliance mode throughout).
--
Barry Pearson http://www.Barry.Pearson.name/photography/ http://www.BirdsAndAnimals.info/ http://www.ChildSupportAnalysis.co.uk/
On Mon, 29 Sep 2003 12:13:11 +0100, William Tasso wrote: Sure, I'll write any report you like. Just send over your P.O. and the
ncessary data for credit references with your commission documentation and
I'll be off. Please allow for a minimum 21 days at (£900 + £250 exes) £1150
+ VAT (if applicable in your location). Please allow extra for travel and
accommodation if you require a personal presentation to your board of
directors.
which in a way shows how expensive that can get... you might not have
intended this side-effect :)
On 29 Sep 2003 05:00:40 GMT, Eric Bohlman wrote: The key here is to realize that accessibility is a form of quality, and all
forms of quality are cheap or free to build into a product or service,
this is, as a matter of fact, wrong. some forms of quality are
extremely expensive to implement.
but quite expensive to add after the fact.
what most probably would agree upon is that designing quality in is
cheaper than retrofitting it. but cheaper != cheap.
"cheaper" means that there is still cost involved. this cost must be
offset by a gain somewhere. if the gain is 0 or smaller than the cost,
most people responsible for a budget would decide to not implement the
extra part -- even if it is cheaper now than later.
Designing a process to produce
parts that all do better than to meet spec is easy and cheap. Culling out
parts that don't meet spec because the process that produces them relies on
luck to meet spec is hard and expensive. The manufacturing world learned
this decades ago.
it seems you do not work in designing manufacturing processes. most
manufacturing processes work actually the other way round. for example
it is _very_ expensive to create 0 fault chip wafers. so what they do
is they simply work with the faults -- it is cheaper to work with a
certain fault rate and to test out the defect chips on a wafer than to
create a 0 fault wafer (which in some cases is next to impossible).
rest assured that only a small percentage of the readers here could
afford a computer made from 0 fault chip wafers. let's be happy with
the relatively cheap selected chips we are using.
of course, if it is possible to significantly improve the
manufacturing process with little extra cost in the design, it would
be foolish not to do so. but it is not always possible, and in many
cases, selecting is cheaper.
Alan J. Flavell wrote: On Mon, 29 Sep 2003, Barry Pearson wrote:
All the evidence I see here and across the web says it costs extra.
Most of the evidence I see across the web tells me that putting in
obstacles to accessibility costs extra, and taking them out again
costs even more. I think you can work out what I deduce from that.
I can spot a strawman a mile off! And when I see a strawman, or a paraphrase,
I wonder why the response doesn't stick to the point I was making?
Suppose (strawman / paraphrase coming up!) I had said:
"All the evidence I have seen says it costs extra to design and build cars to
handle wheelchairs".
And you had responded:
"Most of the evidence I see across the car-making industry tells me that
putting in obstacles to wheelchairs costs extra, and taking them out again
costs even more".
Don't you think that I might feel that you had failed to address the point?
Suppose that there were 2 companies, one competently designing cars to handle
wheelchairs, the other competently designing cars that didn't need to handle
wheelchairs. I believe the former would cost more. It is inherently a harder
task. I agee that if the latter company builds flexibility in, and especially
if it wanted to be able to handle wheelchairs later, it could ensure that
extra costs were minimised later.
I'm not talking about broken web sites. I am asserting that accessibility is a
progressive cost. It starts perhaps close to zero simply allowing assistive
technology to handle well-structured documents. But when I use IBM's Home Page
Reader on some pages that appear to obey the letter and the spirit of good
mark-up, there are still things where I say "but this is just "visitable", not
"livable"". (A comment by a disability lobby group on Part M of the Building
Regulations!)
I feel that, following training, and with extra testing for confirmation,
getting to the "visitable" stage may indeed be low. (I have been talking to
the team of a government department about the training they went on with the
RNIB to learn what was needed for accessibility. Their first efforts were not
cheap).
http://www.rnib.org.uk/xpedio/groups...inar_info.hcsp
See also:
http://www.rnib.org.uk/xpedio/groups...esscentre.hcsp
I also accept that some things that screw up accessibility cost money. But
that isn't because they are broken - they may well have their place. Pop-up
windows, automatic new windows, Flash, even frames, can all be a problem. But
many people think that pop-up windows & Flash are legitimate design features.
(I used to use pop-up windows for photographs, and that is common).
That is why I consider accessibility to be a programme (or process), not a
standard. Making a start may well be cheapish. But honestly, to say it doesn't
cost anything, as others have done, is wishful thinking.
[snip] None of this is meant to be a criticism of your own pages, and it's a
pity that you sometimes seem to react to general discussion as if you
thought that it was.
I'm sorry if I gave that impression. In fact, except for a couple of known
cases, I don't assume people have even looked at my pages.
What I feel is that I am thought to be "politically incorrect" by saying it
costs extra! It is a bit like saying "intelligence is partly inherited", or
"men's brains and women's brains have structural differences". It isn't
allowed to be thought possible - it has to be wrong on principle.
--
Barry Pearson http://www.Barry.Pearson.name/photography/ http://www.BirdsAndAnimals.info/ http://www.ChildSupportAnalysis.co.uk/
"Barry Pearson" <ne**@childsupportanalysis.co.uk> wrote: I currently have "medium" in the body rule throughout several CSSs on a number
of web sites. I don't want to change it to "1em" or "100%" if that would be
the same.
In theory medium = 100% = 1em = user's chosen default.
There may be minor variation, but there is only one major problem and
that is the one I outlined in my previous post.
I have been influenced by something at W3Schools: "Note in IE 4.0+: Default
value of this property is "small", not "medium" as it should be according to
the W3C specification". And, indeed, the W3C statement is "Initial: medium".
Badly worded but correct in a sense.
In IE4+ the browser default and the CSS size small are the same.
In correctly behaving browsers the browser default and the CSS size
medium are the same.
The browser default is still the same in both browsers (assuming
Windows, and small fonts selected, and Medium text size selected it
will be 16 pixels), it's just mapped to a different CSS keyword.
So I assumed that if I specified "medium" in the body rule, I would simply
have a correct but redundant declaration in later browsers,
Yes.
but make earlier IEs behave to standards.
No. It makes those IEs display the text one size larger than their
default.
Was that a mistake?
Have I screwed up users who had corrected the IE bug using
their IE "view" setting? Do I NEED to change?
You've made the text larger than their default for all users of older
IE versions, regardless of what they've set their font size to be in
the view setting.
As I said, the CSS font sizes and IE View > Text Size settings have
nothing to do with each other despite having similar keywords. Treat
them both as independent multipliers of the font size.
(IE 6 appears to behave exactly the same whether I say "medium" or not - I use
4.01 Transitional standards-compliance mode throughout).
Compare http://steve.pugh.net/test/test2a.html and http://steve.pugh.net/test/test2b.html
2a triggers quirks mode in IE6 and 2b triggers standards mode. Hence
2a is what IE5 will always display.
Steve
--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor
Steve Pugh <st***@pugh.net> <http://steve.pugh.net/>
On Thu, 25 Sep 2003 23:27:42 +0100, Eric Jarvis wrote: > px is no use...it causes accessibility pro[lems and you have no way of
> predicting it's appearance anyway...em is better, but the main use
> for em is in relating non text elements to text size
maybe only loosely related, it seems that most images get dimensioned
in pixels. this seems to me somewhat in contradiction to the common
ground in this thread. if i take the basic ideas for dimensioning text
and apply them to images, it seems to me that dimensioning images in
ems is the appropriate method.
> the best bet in most cases is to leave main body text as the default
> size and define larger and smaller text with %...it is the most
> predictable and accessible method
it's getting better now, but there was a time where a large percentage
of pages looked really ugly on high resolution monitors. it was very
evident that different types of content were dimensioned with
different units -- some pixel-based, some not.
Brian wrote:
[snip] http://www.julietremblay.com/ (fine art photography)
[snip]
Quick comment. I tried navigating round the site using IBM Home Page Reader &
the keyboard.
It was OK until I hit <return> to get to the photographs from the (colour)
portfolio. Then I lost track.
I think it was something to do with the pop-ups. With IE 6 I can tab around
the thumbnails, hit <return>, and I don't get a pop-up as I do if I click with
a mouse. Right, that appears to be good behaviour.
But as IBM HPR moves automatically through the links, if I hit <return> I
appear to get puzzling results. One effect is a new blank window. Another is
that the gallery window has been replaced by the photograph (good) but HPR
says "blank page".
I'm a novice with IBM HPR.
--
Barry Pearson http://www.Barry.Pearson.name/photography/ http://www.BirdsAndAnimals.info/ http://www.ChildSupportAnalysis.co.uk/ This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: James Moe |
last post by:
Hello,
I just joined this group and saw the discussion "What do you think of
resizing 1em to 10px?" I am somewhat confused by what y'all think should be
used as a reference size.
I was surprised...
|
by: BobK |
last post by:
Hello Everyone,
I am updating the CSS for my site but want new and original page to appear
the same.
My original CSS permits small increments of zooming (ctrl/mouse wheel) so
that you get...
|
by: Dr John Stockton |
last post by:
Assuming default set-ups and considering all reasonable browsers,
whatever that may mean, what should an author expect that his readers in
general will see (with visual browsers) for a page with...
|
by: JD |
last post by:
Hi guys
What's the best way to specify font size using CSS? I try to avoid
absolute units like pt and px because then users can't resize the fonts
in IE, but % and em are a complete pain to use...
|
by: deko |
last post by:
As I understand it, most browser manufacturers have agreed on 16px for their
default font size.
So, this should be an accurate conversion for percentages:
px %
16 = 100
14 = 87.5
13 =...
|
by: maya |
last post by:
I have heard so much preaching here about how font sizes should be set
as percentages so users can change font-sizes on their browsers... ok,
so now at work am working on a site where we need to do...
|
by: Mark |
last post by:
Sorry if the question is a bit basic.
I generally express my font sizes in pixels, originally to handle the
Macintosh/Windows font size differences (though I believe that they both
now treat...
|
by: 1001 Webs |
last post by:
I am trying to make my style sheet as compatible as possible and I'm
getting a bit confused here.
I've read that the best size for font-size would be 76.1%; due to
shortcomings in the way both...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| |
