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

[Peter Foti]

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

[Barry Pearson]

Eric Bohlman wrote:

"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.

[snip]

It does cost them extra, apparently, so I guess they would charge more.

http://www.jrf.org.uk/knowledge/find...ousing/823.asp

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/

[Barry Pearson]

Steve Pugh wrote:

"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. [snip]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.

[snip]

Thanks. I'll act accordingly.

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/

[Brian]

Barry Pearson wrote:

I fully understand the difference between content and presentation. This leads
me to believe you haven't been reading what I've saying.
On the contrary. Anything I read, I read carefully.
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
Thank you. :)
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.
And thank you again. :) I'll pass that along. She's had moderate
success. I gather from your posts that you are a photographer, too.
You must then know that "moderate success" means she still has a day
job, and won't be giving it up any time soon. ;-)
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.
http://www.julietremblay.com/portfol...onze_woman.jpg

As far as HTML is concerned, this border is "content".
It's not really an HTML question, but yes, of course you are right,
the border is part of the photograph, and thus is content.
I have seen
photographic sites where a border has been added some other way.
There are many instances of borders used as decoration on
julietremblay.com. e.g., on the main portfolio page, the thumbnails
have a thin black border to make them stand out a bit from the
background. That's presentation.
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.
I did concede earlier that art sites sometimes blur the distinction.
Actually, that's not true. The content is visual, so that might
confuse things a tad.
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.
No. You are confusing the two.

The most important content on julietremblay.com is photographs. Those
photographs, in their entirety, are content. The border on the
photograph entitled "Bronze Woman" is part of the photograph. If you
ordered that photograph from her, you would receive it with that
border. I know, because I've see a large print of it hanging in her
house. This is not merely semantics. Consider it a matter of
importance, if that helps. "Bronze Woman" can only be displayed from
the web site with that border. The thumbnail images on porfolio/ can
be displayed without the borders, e.g., with a user-stylesheet. For
the artist, she thinks those thumbnails look good with them, but it is
not crucial if they are borderless. The only crucial material on
portfolio/ are the 4 thumbnails and the text. Nothing else is
content. Therefore, nothing else is crucial. Therefore, nothing else
is in the HTML.
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.
She does not care much about technical aspects. That does not
diminish the importance of those technical aspects. You want an
example? I redesigned her site. It already looked much as it does
now, but was done with Dreamweaver, in WYSIWYG mode, or whatever the
hell they call it. Nested tables galore. The thumbnail links did
nothing when js was not available to the browser. Not a title element
on the whole site.

When I explained the importance of these things, I got the sense that
she thought I was quaint, with my "structure" and html and css and God
knows what else. But she was positively wowed when she saw how much
faster her catalog page loaded with my redesign.
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.
No. The photos are content. Just like, on my personal site's home page

http://people.umass.edu/btrembla/

the poem extract is content. I am not a control freak for wanting 10
lines of the poem. That's my content. I want that extract to look
nice, and line up. So I set a margin, and floated the image of the
author to the left. But NS4 chokes on the margin. Solution?
Obvious: hide the margin from NS4. It doesn't look as nice, IMHO, but
NS4 users can still read the extract, can still read my (amateur)
translation, can still access the content.
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.

Decide what is core content. All else is presentation. For a
photography site, only the photos themselves are content. Sure,
present them in a way that is visually appealing. Put in borders,
padding, margin. Position things. Create pseudo frames for the
photos. But do all this in CSS. And let go. If the user-agent
cannot correctly put in the pseudo-frames, or the margins, or the
padding, the user can still see the photos. That's what your
photography section is all about, right? Presenting photos?

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

[Brian]

Jim Ley wrote:

ti**@greytower.net (Tina Holmboe) wrote:

ji*@jibbering.com (Jim Ley) exclaimed in
<3f****************@news.cis.dfn.de>:

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'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

Yes, it does. :-p
it has an explicit technical meaning in the context of SGML
authoring,
This is ciwas, not ciwah, that's true. But I don't think it's so far
off the mark to consider sgml to be a consideration. The w in ciwas
is www, html is common enough on the www, html is an sgml application.
that doesn't mean it loses its normal meaning, however
To have meaningful discussions, it's helpful to be working with the
same definitions. If someones says in one thread, "use several
browsers to make sure your page is valid," and in another, someone
says, "valid html does not permit block level elements inside a <p>
element," there's going to be confusion. "valid/ate/or" has a precise
meaning in SGML. Let's not muck things up by changing the meaning
of the word some of the time.
I only mentioned QA, are you also intending to disagree that QA is
more than validity?

Qa is certainly indispensible. But can't we call that, well, "qa?"
Or "testing a site?"

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

[Brian]

Jim Ley wrote:

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.

That may be true.

Warranted conclusion: adding style to documents to increase their
visual appeal and usability increases the costs of web authoring, in
some cases making such changes cost-prohibitive.

Unwarranted conclusion: adding accessibility to documents increases
the costs of web authoring, in some cases making such changes
cost-prohibitive.

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

[Brian]

Jim Ley wrote:

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,

That's nonsense. The accessible thing to do is not set a font-size at
all. (If you want to change the appearance of a site, the accessible
way to do so is to set body to 100%, and other elements relative to
it. But you already knew that.)

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

[Barry Pearson]

kchayka wrote:

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.

I'm sorry! I'm a consultant. I'll steal your watch then charge you if you want
to know the time. I push people to the limit. And they do the same to me. (I
maintain the FAQ for one NG and appear in another). I've got a lot of help
here. I won't push my luck - someone may charge me!

But I have now solved the problem of those 8 photograph-page CSSs. When I was
replying to you, I suddenly had an idea about contextual selectors. (No, you
can't charge me for it!) I've just tested the idea, and it works. I can get
down to 1 CSS for those pages! Instead of saying:

<link rel="stylesheet" href="style_dark_grey.css" type="text/css">
</head>
<body>

I can say:

<link rel="stylesheet" href="style_one_css.css" type="text/css">
</head>
<body class="dark_grey">

So, I can have just the one "style_one_css.css" for all my photograph pages.
Then I can say things like:

body.dark_grey { background-color: #191919; background-image:
url(../assets/dark_grey.gif); color: #C1C1C1; }

body.dark_grey a:link, body.dark_grey a:visited { color: #4444FF;
text-decoration: none; }
body.dark_grey a:hover { color: #FF0000; text-decoration: none;
background-color: #FFFFFF; }

body.dark_grey div.middle, body.dark_grey div.inner { padding: 7px; border:
solid #000000 1px; }
body.dark_grey div.middle { border-left-color: #666666; border-top-color:
#666666; }
body.dark_grey div.inner { border-right-color: #666666; border-bottom-color:
#666666; }

Blindingly obvious to experts. A breakthrough to me. Control photograph-page
colour and style via the body tag. (Hm! Should it be ID, not class?)

[snip]

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.

I hope those have been taken into account in the W3C guidelines.

But the real point is, getting the photograph on the right background is an
order of magnitude more important to me than getting the text the right
colour. (I used to use a pop-up window that only showed the photograph on a
chosen background, no text at all).

I accept the consequences if some people fundamentally disagree with my
choices.

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/

[Eric Jarvis]

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. 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.

I think the point here is what you feel should be included in the base
price...if one assumes that the base cost for a site includes an ability
to be adequately spidered and indexed by search engines then pretty much
every accessibility issue is already dealt with...If you merely include
the content being visible on the web to a small number of visual web
browsers then there might be some additional costs...however I'd assume
that ANYONE claiming to be a professional web designer would at the least
be ensuring that Google can index the site as an essential basic part of
the job

--
eric
www.ericjarvis.co.uk
all these years I've waited for the revolution
and all we end up getting is spin

[Tina Holmboe]

"Barry Pearson" <ne**@childsupportanalysis.co.uk> exclaimed in <t9*******************@newsfep2-win.server.ntli.net>:

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?
And you would be right.

Alan is quite capable of answering on his own, but if you got THAT response
out of HIM, then the world would be two days dead allready.

One of the reasons why accessibility is easier - and why cost does not
spring into play - on the web is the fact that the framework is allready
there.

Have you ever read Greg Bear's "Eon" ? If not, it comes warmly recommended
should you enjoy SF; and it has a few points that can be applied to this
topic.

IF the physical framework of a car - the steel - could adjust automatically
to fit any size or type of chair, then such a hypothetical answer would
be correct.

Steel does not. The web does.

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.

That's peculiar, really. It's mostly those of us working with accessibility
that are deemed "politically incorrect" ...

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

[Tina Holmboe]

"Barry Pearson" <ne**@childsupportanalysis.co.uk> exclaimed in <bA*******************@newsfep2-win.server.ntli.net>:

It does cost them extra, apparently, so I guess they would charge more.

http://www.jrf.org.uk/knowledge/find...ousing/823.asp

Now I'm confused. It seems, from the URI you quote, that few builders are
even able to quantify the additional costs.

I've got some experience with building various gadgets. Granted, I did
not personally build any liquid gas tankers ;) but it runs in the
family.

A construction company, typically, is slightly sloppy when it comes
to costs. The typical priority is time - material simply doesn't cost
as much as does people.

And it's faster to build an accessible site. Much faster. Well, IMnsHO,
naturally.

It's the tinkering that gets expensive, really.

"Oy, vey, we forgot to put in plumbling on this floor. Blast, where did
we leave the concrete saw ? Overtime again, damned!"

"Oh, no, we forgot to include skip-navigation links on all pages, we'll
have to recode every single one!" (why didn't they use templates ?)

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

[William Tasso]

Gerhard Fiedler wrote:

On Mon, 29 Sep 2003 12:13:11 +0100, William Tasso wrote:

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 :)

LOL: only on usenet ...

--
William Tasso - http://WilliamTasso.com

[Alan J. Flavell]

On Mon, 29 Sep 2003, Barry Pearson wrote:

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!

I think the problem we're having with this discussion is that you're
taking as your reference point the miniscule proportion of web sites
such as your own where the groundwork was already done, the site has
been composed by a serious practitioner according to rules of good
practice, the basic accessibility features have already been catered
for, and you're dealing with the extra cost of meeting additional
issues that are raised by the guidelines. Whereas I'm bleating about
the mass of websites produced with some unspeakable pretend-WYSIWYG
website-extruding package, where IMNSHO the issues that I am raising
are very real, and by no means "straw man" issues.
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".
Then I would have to agree. Car models appear to be designed with a
relatively narrow 'use case' in mind (different models aimed at
different use cases), and most of them don't include disability access
in their use case.

The web however was designed for diversity of access to information,
and although the original motive may have been diversity of equipment
rather than diversity of user, the fact is that for many kinds, at
least of non-specialised content, it works that way regardless of the
original motive, if the design task is approached flexibly.
I'm not talking about broken web sites.
Exactly! In terms of the criteria that we are discussing, the
majority of web sites _are_ broken, and IMHO that's the first priority
for action. I don't wish to see a ghetto-ised web, with a tiny
minority of sites accessible to disabilities to the n'th degree, while
the rest - whether by intent or by neglect - remains implacably
hostile.
That is why I consider accessibility to be a programme (or process), not a
standard. Making a start may well be cheapish.
I agree. So let's at least encourage folks to make the start.
But honestly, to say it doesn't cost anything, as others have done,
is wishful thinking.

To satisfy the full-blown array of guidelines at all levels is hard,
indeed for some kinds of material it's impossible because, in the end,
some of the guidelines become mutually contradictory. But that's no
excuse for those who insist on inserting pointless "kewl feechers" and
then proudly claiming that those features define their "target
audience".

[Barry Pearson]

Eric Jarvis wrote:

Barry Pearson wrote:

[snip] I think the point here is what you feel should be included in the base
price...if one assumes that the base cost for a site includes an
ability to be adequately spidered and indexed by search engines then
pretty much every accessibility issue is already dealt with...If you
merely include the content being visible on the web to a small number
of visual web browsers then there might be some additional
costs...however I'd assume that ANYONE claiming to be a professional
web designer would at the least be ensuring that Google can index the
site as an essential basic part of the job

I think you have made a good point here, although I don't know whether I am
reading it the same as you.

If a site can be indexed by search engines, then it is "visitable". That is
only a start, although a good one, to being accessible. It says that a dumb
engine with enough processing power can in principle navigate around the site.

But is it "livable"? Would a flesh & blood person draw the same conclusions
about the site as the search engine? Would a person tolerate what the search
engine will tolerate?

Perhaps "indexability" is "level 0" of accessibility?

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/

[Eric Jarvis]

Barry Pearson wrote:

Eric Jarvis wrote:

Barry Pearson wrote:

[snip]

I think the point here is what you feel should be included in the base
price...if one assumes that the base cost for a site includes an
ability to be adequately spidered and indexed by search engines then
pretty much every accessibility issue is already dealt with...If you
merely include the content being visible on the web to a small number
of visual web browsers then there might be some additional
costs...however I'd assume that ANYONE claiming to be a professional
web designer would at the least be ensuring that Google can index the
site as an essential basic part of the job

I think you have made a good point here, although I don't know whether I am
reading it the same as you.

If a site can be indexed by search engines, then it is "visitable". That is
only a start, although a good one, to being accessible. It says that a dumb
engine with enough processing power can in principle navigate around the site.

But is it "livable"? Would a flesh & blood person draw the same conclusions
about the site as the search engine? Would a person tolerate what the search
engine will tolerate?

Perhaps "indexability" is "level 0" of accessibility?

in most respects one has to treat a search engine spider as a blind, deaf,
but determined moron using an extremely stripped down and rare web
browser...so in terms of navigation one is dealing with an extreme case of
accessibility...in terms of the content though one looks more at the
searcher than at the bot...it's all about placing important content where
it is easy to get at and ensuring that everything is easily understood

by the time a site is competently set up for the search engines one would
have to put in some serious extra effort to make it inaccessible

sadly the normal design process is to make a totally broken and
inaccessible site and then spend large sums of money on an SEO to fix it

--
eric
www.ericjarvis.co.uk
all these years I've waited for the revolution
and all we end up getting is spin

[Barry Pearson]

Alan J. Flavell wrote:

On Mon, 29 Sep 2003, Barry Pearson wrote:

[snip] To satisfy the full-blown array of guidelines at all levels is hard,
indeed for some kinds of material it's impossible because, in the end,
some of the guidelines become mutually contradictory. But that's no
excuse for those who insist on inserting pointless "kewl feechers" and
then proudly claiming that those features define their "target
audience".

I think we understand one-another and pretty well agree.

And I run with Flash animation, GIF animation, ActiveX dialogues, and
unsolicited pop-ups, switched off by default. So you can guess my views on
"kewl feechers"!

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/

[Barry Pearson]

Brian wrote:

Barry Pearson wrote:

[snip]

But, stepping out of the narrow scope of HTML and CSS, I believe all
those borders are presentation.

No. You are confusing the two.

The most important content on julietremblay.com is photographs. Those
photographs, in their entirety, are content. The border on the
photograph entitled "Bronze Woman" is part of the photograph. If you
ordered that photograph from her, you would receive it with that
border. I know, because I've see a large print of it hanging in her
house. This is not merely semantics. Consider it a matter of
importance, if that helps. "Bronze Woman" can only be displayed from
the web site with that border. The thumbnail images on porfolio/ can
be displayed without the borders, e.g., with a user-stylesheet. For
the artist, she thinks those thumbnails look good with them, but it is
not crucial if they are borderless. The only crucial material on
portfolio/ are the 4 thumbnails and the text. Nothing else is
content. Therefore, nothing else is crucial. Therefore, nothing else
is in the HTML.

[snip]

Rather than debate terminology, I'll give you a demonstration of using
W3C-conformant CSS to add a border to a photograph before turning it into a
JPEG. I hope that you will then see that, for inherently visual material, the
split between content & presentation is forever blurred.

Here is the original JPEG, which has been on the web for some time:

http://www.barry.pearson.name/photog...01_09_09_2.jpg

Here is basically the same photograph, also a JPEG, to which I have added a
border using W3C-conformant CSS. (I'll tell you how, including the CSS itself,
later). Here is a URL to the JPEG, and a URL to a HTML document that
identifies the JPEG as its content

http://www.barry.pearson.name/photog..._09_09_2sc.jpg

http://www.barry.pearson.name/photog..._09_09_2sc.htm

Here is the extract from the stylesheet that I used to put the border into the
JPEG. This was obviously presentation when I added the border:

body { background-image: url(eggshell.gif); }
div.middle, div.inner { padding: 7px; border: solid #554433 1px; }
div.middle { border-left-color: #FFF7EE; border-top-color: #FFF7EE; }
div.inner { border-right-color: #FFF7EE; border-bottom-color: #FFF7EE; }

Here is the URL of the "eggshell.gif" used:

http://www.barry.pearson.name/assets/eggshell.gif

Now: given that I used the above CSS to add the border to the original
photograph, isn't that border presentation? Yet above is a JPEG with that
border inside it. So I guess you would call it content.

I expect you know how I used W3C-conformant CSS to do simple photo-editing,
before creating the JPEG. You have the tools on your computer too.

In case there is anyone reading this who doesn't know, I started with the
photograph page below, in which the original photograph is identified by the
HTML, and the border is added by the CSS (of which the above is an extract):

http://www.barry.pearson.name/photog...01_09_09_2.htm

I then did screen capture, and fed the results into a bog-standard
photo-editor to crop it and turn it into a JPEG. I didn't waste time on it (it
just tooks minutes). So I could get much better quality if I wanted to. (For
example, it is double-compressed).

What does this show? In a very narrow sense of just the use of HTML/CSS at the
very last stage, it is possible to decide what to call content and what to
call presentation. But in the total photographic process, genuine
presentation, as understood by this NG and others, can also be seen as genuine
content, as understood by this NG and others. After all - I did web authoring
with HTML/CSS at 2 different places in the process.

That is why, while I understand the narrow use of the words that some may use,
I see the entire process of photography as adding presentation by various
technologies and standards. There is nothing special about the last stage,
except simply that it IS the last stage, and can therefore still be
manipulated in ways that earlier results cannot. People who work with
inherently visual material can make decisions about where certain presentation
is added - before, during, or after the final HTML.

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/

[Gerhard Fiedler]

On Mon, 29 Sep 2003 22:11:19 +0100, Alan J. Flavell wrote:

I think the problem we're having with this discussion is that you're
taking as your reference point the miniscule proportion of web sites
such as your own where the groundwork was already done, the site has
been composed by a serious practitioner according to rules of good
practice, the basic accessibility features have already been catered
for, and you're dealing with the extra cost of meeting additional
issues that are raised by the guidelines. Whereas I'm bleating about
the mass of websites produced with some unspeakable pretend-WYSIWYG
website-extruding package, where IMNSHO the issues that I am raising
are very real, and by no means "straw man" issues.
But, getting back to the cost point, my experience in the industry is
that in general code of solid quality (and this seems to be what you
are talking about) costs -- initially at least -- more.

I'm not a frontend designer and usually am more concerned with stuff
that's not visible, but I guess the issues are the same. It is cheaper
to get a simple site up, done by somebody who has barely mastered the
most important menu options of a web site design tool, than to hire
one of the experienced designers. So, from the point of view of the
owner of that site, she got 10 pages that work for her. They are
crappy HTML and if they use CSS at all it's possibly even worse, they
are not "accessible", but to have them done with a solid, designed
structure could easily have cost multiples of what she paid for them.

Then I would have to agree. Car models appear to be designed with a
relatively narrow 'use case' in mind (different models aimed at
different use cases), and most of them don't include disability access
in their use case.

The web however was designed for diversity of access to information,
I think the analogy is broken here. A car would correspond to a site,
not the web, and the web would correspond to all the cars (and the
Internet to the roads and streets). This then becomes that the roads
accomodate all kinds of cars with their individually narrow use cases,
just as the web consists of all kinds of sites with more or less
narrow (possibly "non-accessible") use cases.

Exactly! In terms of the criteria that we are discussing, the
majority of web sites _are_ broken, and IMHO that's the first priority
for action. I don't wish to see a ghetto-ised web, with a tiny
minority of sites accessible to disabilities to the n'th degree, while
the rest - whether by intent or by neglect - remains implacably
hostile.
I didn't feel that anybody in this discussion wouldn't agree with you
on this. (I certainly do, even though Barry wrote pretty much what I
think, too.) But I don't think it comes for free. From the point of a
web site customer, this costs extra. I'm sure you charge more than a
high-school grad who knows a bit about Dreamweaver or whatever the
site generation tool is she uses.

I certainly do, and I know that I won't churn out simple VB apps for
the price some of the programmers out there do. I tend to think that I
produce better quality code than some of them, but I have my price --
and most everybody who does has.

To satisfy the full-blown array of guidelines at all levels is hard,
indeed for some kinds of material it's impossible because, in the end,
some of the guidelines become mutually contradictory. But that's no
excuse for those who insist on inserting pointless "kewl feechers" and
then proudly claiming that those features define their "target
audience".

This point is very much philosophical, I think. I don't see a
technical question here, and no budgetary question either. It is about
whether this is a "good" thing. Some people sure think it is. I don't
think that by alienating them you make a huge impact. In terms of
convincing people and educating them about pros and cons of what they
do it is usually much more efficient to work with them rather than
against them (unless you envision hard legal rules about what has to
be done and what must not be done). I don't see that happen a lot.

[Eric Bohlman]

Gerhard Fiedler <[e-mail]> wrote in
news:db********************************@4ax.com:

I'm not a frontend designer and usually am more concerned with stuff
that's not visible, but I guess the issues are the same. It is cheaper
to get a simple site up, done by somebody who has barely mastered the
most important menu options of a web site design tool, than to hire
one of the experienced designers. So, from the point of view of the
owner of that site, she got 10 pages that work for her. They are
crappy HTML and if they use CSS at all it's possibly even worse, they
are not "accessible", but to have them done with a solid, designed
structure could easily have cost multiples of what she paid for them.

You're making the common error of comparing initial purchase prices without
taking total cost into account. Lots of bad deals look good when you do
that. A quality expert (I think it was W. Edwards Deming) told a story
about a shoe manufacturer who "saved" money by buying cheaper thread than
he had been previously using. Sure, there was a saving on the line item
for thread. But the cheap thread broke frequently, forcing the stitching
machines to halt while the operator rethreaded them. The rethreading took
so much time that the manufacturer had to run the factory on overtime in
order to meet his production requirements. The extra cost of the overtime
more than completely wiped out the savings on the thread.

You say "she got 10 pages that work for her." What does that mean?
Assuming the site is supposed to promote or even conduct her business, it
matters not one whit how well it works for *her*. What matters is how it
works for her *customers*. Businesses make money by impressing their
customers, not by impressing their own management. The days are long gone
when a commercial Web site was simply a matter of marking territory on the
Web. If the site has to be reworked to make it useful to her customers,
then the cost of the rework has to be taken into account. You can't
pretend it doesn't exist. And if the rework isn't done, then the initial
money paid was *completely wasted*; the owner would have been better off
not spending it at all.

[Barry Pearson]

Eric Jarvis wrote:

Barry Pearson wrote:

[snip]

If a site can be indexed by search engines, then it is "visitable".
That is only a start, although a good one, to being accessible. It
says that a dumb engine with enough processing power can in
principle navigate around the site.

But is it "livable"? Would a flesh & blood person draw the same
conclusions about the site as the search engine? Would a person
tolerate what the search engine will tolerate?

Perhaps "indexability" is "level 0" of accessibility?

in most respects one has to treat a search engine spider as a blind,
deaf, but determined moron using an extremely stripped down and rare
web browser...so in terms of navigation one is dealing with an
extreme case of accessibility...in terms of the content though one
looks more at the searcher than at the bot...it's all about placing
important content where it is easy to get at and ensuring that
everything is easily understood

by the time a site is competently set up for the search engines one
would have to put in some serious extra effort to make it inaccessible

sadly the normal design process is to make a totally broken and
inaccessible site and then spend large sums of money on an SEO to fix
it

Sadly, I have to agree. Some sites defy both human navigation and search
engine navigation.

What we both appear to believe is that search engines and accessibility
principles are actually compatible with one-another. A search engine can't
just take "a bird's eye view" of a site or a page. Neither can a blind person.
Both rely on a certain amount of structure. Both tend to need a considerable
amount of serial processing of the material.

I wonder how much advocates of accessibility promote the idea that sites that
are accessible to (say) blind or physically handicapped people are probably
going to be accessible to search engines too? Perhaps they advocate it a lot,
and I've missed it. But at a basic level, it is true. And if you can answer
the site developer's question WIFM ("what's in it for me?") you are half-way
there.

If I had one wish to cater for both causes, I would say: "provide a properly
structured site-map accessible from pretty well every page". A site map is
often what stops me walking away from a site for ever.

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/

[Barry Pearson]

Tina Holmboe wrote:

I won't respond point by point. Here are just a few responses.

"Barry Pearson" <ne**@childsupportanalysis.co.uk> exclaimed in
<bU********************@newsfep1-win.server.ntli.net>:

[snip]

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.

You missed the point. I was talking about what I see in my own controlled
environment (see my words), and I control that. THEN I publish the material,
and I confidently expect that sorting things out in my own environment will
greatly improve the perception of my published material in other environments.

I try to achieve very similar results in a useful set of browsers (with
default settings) on my PC before I upload. I take the trouble to understand
any differences, and where possible reduce or eliminate the differences using
W3C-compliant CSS. As a result, I have confidence that a majority of people in
the world using those browers will see similar results to what I see. Since
the CSS is W3C-compliant, I can expect that many future browsers, or
brower-versions, will also show my published work in a very similar way, if
they are used on their default settings.

I also expect this to improve over time. We are currently going through a
transition phase, where many users haven't reached the 21st century yet. That
is a temporary situation. Perhaps, in 10 years time, 99% (choose your own
number) of users who are browsing according to "media type = screen" will be
using user agents that conform to CSS2. Perhaps (choose your own number) 80%
or 90% will be using user agents conforming to CSS3. This will enable us to
vastly reduce, and typically eliminate, the rendering differences between just
about all the common browsers at their default settings, if we choose to.

At the moment, we are lucky if most browsers support HTML properly! As the
years go by, daft browers will become irrelevant and new ones will be far
better. CSS1, then CSS2, then CSS3 will in turn become rendered in vastly more
consistent ways. People will publish valid CSS rules for eliminating the
remaining differences, for example to eliminate differences in defaults. (I
currently need CSS2 to eliminate certain peculiarities in Mozilla Firebird,
and CSS3 to eliminate others. I use the former because W3C validates it. I
don't do the latter because it doesn't. In a few years time, W3C will validate
CSS3, I will make the changes to my CSSs, and Mozilla Firebird with its
default settings will render my pages like other user agents do).

We are moving towards a world where people who care will be able to ensure
that just about all the common browsers, used at their default setting for
media type = screen, will render their material in pretty much an identical
way. And this will only need validated HTML and validated CSS - no frigs or
hacks. Let's continue the discussion in 2013!

[snip]

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.

Perhaps you mean:
http://www.htmlhelp.com/feature/art3.htm

I started the above thread about this:
http://groups.google.com/gr*********************************@newsfep1-win.server.ntli.net

Alan Flavell and many others contributed a lot. I read the above page quite
early on. With respect to Alan, it is a little bit out of date, and doesn't
really say "if you are a photographer producing thumbnail gallery, do this". I
want to write something that starts with what to do in specific circumstances,
and link to why. In other words, a process-oriented view.

For example, here is a reply to someone else:
http://groups.google.com/gr************************************@newsfep2-win.server.ntli.net

[snip]

I'm a competent IT person. I've snipped the obvious advice, while recognising
that it would be valuable for novices.

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/

[Gerhard Fiedler]

On 30 Sep 2003 14:13:32 GMT, Eric Bohlman wrote:

Gerhard Fiedler <[e-mail]> wrote in
news:db********************************@4ax.com :

I'm not a frontend designer and usually am more concerned with stuff
that's not visible, but I guess the issues are the same. It is cheaper
to get a simple site up, done by somebody who has barely mastered the
most important menu options of a web site design tool, than to hire
one of the experienced designers. So, from the point of view of the
owner of that site, she got 10 pages that work for her. They are
crappy HTML and if they use CSS at all it's possibly even worse, they
are not "accessible", but to have them done with a solid, designed
structure could easily have cost multiples of what she paid for them.
You're making the common error of comparing initial purchase prices without
taking total cost into account.

How do you know whether I took it into account or not? Of course I
did. But there is often the reality that you only have x dollars
today, and if that brings in some money, you may have x dollars (or
even a multiple of it) again next year. That's why it is a reality
that often stuff gets used that is on a prototype level, in terms of
code quality. It simply needs to generate revenue before someone can
invest further. But since most programmers never actually pay for
programming work, most don't take such issues into account.
You say "she got 10 pages that work for her." What does that mean?
"Work for her" meant "work for her in reaching the most potential
customers she could reach _with the money spent_."
Assuming the site is supposed to promote or even conduct her business, it
matters not one whit how well it works for *her*. What matters is how it
works for her *customers*.
We were talking about "accessability" -- that means in this context
mostly accessability for a number of rather marginal (in terms of
browser UA used) groups. Barry has brought up the 80-20 rule earlier.
For budget vs. accessability discussions, this is a quite important
matter. In many cases, it may make actually sense (from a budgetary
point of view) to only spend the 20% it takes to reach a potential
80%.

And in the terms of limited resources as mentioned above, it may make
sense to put up 10 pages that show this content satisfactorily to a
potential audience of 80% of the surfers with a crappy HTML and CSS,
rather than have only one page there with a thoroughly designed HTML
and CSS code that has a potential audience of 100% of the surfers but
shows only a fraction of the necessary content. The actually reached
audience in the first case may well be much larger than in the second
case -- and the added TCO irrelevant because of the much more
favorable distribution over time.
And if the rework isn't done, then the initial
money paid was *completely wasted*; the owner would have been better off
not spending it at all.

Possibly, sometimes. In many cases, however, the additional money gets
spent when some revenue has been generated. Budget is not a static
question, it has a very strong time dimension. TCO compresses the time
line, which in many cases distorts budget reality, especially in
start-up situations.

This is of course completely different when we are talking about an
established company with an established revenue stream, and the
investment in question is a tiny fraction of their overall operational
cost. I've been there, too, and then you are of course completely
right. Silly management decisions to go with the cheapo early on can
in the end make a project three times more expensive and take three
times longer than if they had gone with a decent solution (and a
decent solution provider :) in the first place.

But in most of my projects so far, the time dimension of budget was a
very crucial issue, as they were about new products with a rather
limited budget. In such cases, the sweet spot in the trade-off between
a solid, future-oriented design and initial functionality is not
always easy to find -- and definitely is not as clearly on the side of
the solid design as I as a programmer would like it to be. Engineering
work in general is mostly about finding this spot, not about
maximizing quality.

[Barry Pearson]

Gerhard Fiedler wrote:
[snip]

How do you know whether I took it into account or not? Of course I
did. But there is often the reality that you only have x dollars
today, and if that brings in some money, you may have x dollars (or
even a multiple of it) again next year. That's why it is a reality
that often stuff gets used that is on a prototype level, in terms of
code quality. It simply needs to generate revenue before someone can
invest further. But since most programmers never actually pay for
programming work, most don't take such issues into account. [snip] We were talking about "accessability" -- that means in this context
mostly accessability for a number of rather marginal (in terms of
browser UA used) groups. Barry has brought up the 80-20 rule earlier.
For budget vs. accessability discussions, this is a quite important
matter. In many cases, it may make actually sense (from a budgetary
point of view) to only spend the 20% it takes to reach a potential
80%.

And in the terms of limited resources as mentioned above, it may make
sense to put up 10 pages that show this content satisfactorily to a
potential audience of 80% of the surfers with a crappy HTML and CSS,
rather than have only one page there with a thoroughly designed HTML
and CSS code that has a potential audience of 100% of the surfers but
shows only a fraction of the necessary content. The actually reached
audience in the first case may well be much larger than in the second
case -- and the added TCO irrelevant because of the much more
favorable distribution over time. [snip] But in most of my projects so far, the time dimension of budget was a
very crucial issue, as they were about new products with a rather
limited budget. In such cases, the sweet spot in the trade-off between
a solid, future-oriented design and initial functionality is not
always easy to find -- and definitely is not as clearly on the side of
the solid design as I as a programmer would like it to be. Engineering
work in general is mostly about finding this spot, not about
maximizing quality.

Yes to all of the above, with qualifications:

1. First, an expansion of your last point, without disagreeing with it.
Engineering is about meeting the required quality (as well as cost &
timeframe), where that is likely to mean the specified quality (if the project
is defined competently). Maximising quality at extra cost without agreeing
this with your client can actually be unethical bad engineering!

2. I'm a bit dubious about that "crappy HTML and CSS" bit! I think I can guess
what you mean, but before you descend to crap you need to have a very clear
understanding with the client. You may be talking about having lower standards
for usability or performance or availability, or even security. That is OK,
but I wouldn't call that crappy material. Simply material developed to a
(hopefully) agreed specification that accepts those lower standards.

3. The single most important quality to get agreed is probably "potential for
change". Does the client see this as a one-off, or as the start of an evolving
resource that will gradually achieve higher standards across all the
qualities? This makes a considerable difference to many things, for example
tooling and project standards.

My reading of what you wrote is that you already knew all that.

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/

[Gerhard Fiedler]

On Wed, 1 Oct 2003 14:49:45 +0100, Barry Pearson wrote:

Yes to all of the above, with qualifications: [snip valid stuff]My reading of what you wrote is that you already knew all that.

Yes, and there's of course a lot more to be said about code quality,
client expectations, requirements and engineering ethics :)

I tried to stay succinct and make one tiny point about some budget
realities that often lead to code that I don't think is good code from
a coder's point of view (all those things about "best practices" and
so). But it still may be a good product from the point of view of the
person who pays the bill and has to create the revenue.

[Nikolaos Giannopoulos]

Barry Pearson wrote:

But I have now solved the problem of those 8 photograph-page CSSs. When I was
replying to you, I suddenly had an idea about contextual selectors. (No, you
can't charge me for it!) I've just tested the idea, and it works. I can get
down to 1 CSS for those pages! Instead of saying:

<link rel="stylesheet" href="style_dark_grey.css" type="text/css">
</head>
<body>

I can say:

<link rel="stylesheet" href="style_one_css.css" type="text/css">
</head>
<body class="dark_grey">
Use an id as it will only appear exactly once on any given page - I'm
surprised nobody mentioned this sooner. In my experience, all you
typically ever need is 1 or possibly 2 style sheets.

So, I can have just the one "style_one_css.css" for all my photograph pages.
Then I can say things like:

body.dark_grey { background-color: #191919; background-image:
url(../assets/dark_grey.gif); color: #C1C1C1; }
No need for "body." to be specified - especially when you use an id:

#dark_grey { background-color: #191919; background-image:
url(../assets/dark_grey.gif); color: #C1C1C1; }

Blindingly obvious to experts. A breakthrough to me.

This is why it sometimes makes sense to keep going back to tutorials or
the CSS spec as we go along - all too often people start learning CSS
and keep plowing not realizing that they missed things along the way
that may need to be re-clarified now that they have more experience.

--Nikolaos

[Barry Pearson]

Nikolaos Giannopoulos wrote:

Barry Pearson wrote: [snip]

I can say:

<link rel="stylesheet" href="style_one_css.css" type="text/css">
</head>
<body class="dark_grey">

Use an id as it will only appear exactly once on any given page - I'm
surprised nobody mentioned this sooner. In my experience, all you
typically ever need is 1 or possibly 2 style sheets.

Is there a specific advantage in using "id" instead of "class"? Does it make
it work in more cases? I thought I had read of problems with some browsers
(but probably they were older ones). While it would be easy enough to change,
I'm not sure what I would get from it. Either way the name needs to be unique
enough within the CSSs I am using.

One reason I use more than 1 CSS for a site is that it makes it easier to
re-use CSSs across sites. For example, I have a CSS that I use for on-line
academic papers that is common to all my sites with such papers on, a
photograph page style CSS common to all sites with photographs on, etc. Then
if I change one of these, I just copy the file to all relevant sites, I don't
have to change text within a file.

(I've taken the "_" character out of the name above - I think as a result of a
validation or other failure).

[snip] This is why it sometimes makes sense to keep going back to tutorials
or the CSS spec as we go along - all too often people start learning
CSS and keep plowing not realizing that they missed things along the
way that may need to be re-clarified now that they have more
experience.

Yes. And it is also one of the reasons I try to ensure that pages display the
same with my test-set of browsers at their default settings, or else I know
why not. I sometimes find that a misunderstanding will be tolerated by one
browser but not another. I learn a lot finding out why.

Thanks.

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/

[Tina Holmboe]

"Barry Pearson" <ne**@childsupportanalysis.co.uk> exclaimed in <Ln***************@newsfep1-gui.server.ntli.net>:

Nikolaos Giannopoulos wrote:

Barry Pearson wrote:

[snip]

I can say:

<link rel="stylesheet" href="style_one_css.css" type="text/css">
</head>
<body class="dark_grey">

Use an id as it will only appear exactly once on any given page - I'm
surprised nobody mentioned this sooner. In my experience, all you
typically ever need is 1 or possibly 2 style sheets.

Is there a specific advantage in using "id" instead of "class"? Does it make
it work in more cases? I thought I had read of problems with some browsers

Apart from in terms of select specificity - see also

http://www.w3.org/TR/CSS21/cascade.html#specificity

no. There is no need to use an ID where a CLASS would suffice. In your
example, class does the job without difficulty.
--
- Tina Holmboe Greytower Technologies
ti**@greytower.net http://www.greytower.net/
[+46] 0708 557 905

[Nikolaos Giannopoulos]

Barry Pearson wrote:

Brian wrote:

Here is a URL to the JPEG, and a URL to a HTML document that
identifies the JPEG as its content

http://www.barry.pearson.name/photog..._09_09_2sc.jpg

http://www.barry.pearson.name/photog..._09_09_2sc.htm

Here is the extract from the stylesheet that I used to put the border into the
JPEG. This was obviously presentation when I added the border:
I think you are mixing your use of "presentation" w.r.t. this NG to
imply both (a) visual effects incorporated into content and (b) visual
effects applied to content.

In (a) the content - the photograph - has been altered with the border
but the bottom line is that the photograph - complete "now" with border
- "is content" and even if CSS is turned off the border will show on
almost any browser because it is part of the content.

In (b) the content - the photograph - has presentation applied to it
through CSS, being the border, and if CSS is turned off it, the border
won't be visible - so the border is presentation not content.

Now: given that I used the above CSS to add the border to the original
photograph, isn't that border presentation?
If you are refering to using HTML/CSS to markup a web page and take a
snapshot of your screen and then cropping the image to include the
border then "NO" it is "still" content.

I think its your artistic background that is causing confusion as I can
see how you can interpret it both ways outside of this NG but there is
only one way to interpret presentatin in a CSS authoring NG. So once
again this is content.

Yet above is a JPEG with that
border inside it. So I guess you would call it content.
Yes - the border is part of the content.

What does this show? In a very narrow sense of just the use of HTML/CSS at the
very last stage, it is possible to decide what to call content and what to
call presentation.
Content is content. If you decide that you wanted round borders around
something and realized that browsers (except mozilla) don't support it
very well then by making a graphic image with round borders its still
content - it may look like presentation - but its still content.

If CSS is disabled the rounded border graphic still shows up right? The
rounded borders have nothing to do with presentation.

But in the total photographic process, genuine
presentation, as understood by this NG and others, can also be seen as genuine
content, as understood by this NG and others.
See my previous comment on "artistic background".

After all - I did web authoring
with HTML/CSS at 2 different places in the process.
Yes, you did but the end result is different and your missing that.

You could have used photoshop to create the borders instead of CSS for
the photograph (that contained the border) and in the end it would still
be content. In the other case you added presentation - CSS styles - to
create the border.

Just because on the surface they both have the same visual appearances
doesn't mean that they are both have presentation added.

That is why, while I understand the narrow use of the words that some may use,
I see the entire process of photography as adding presentation by various
technologies and standards.
Which is what I thought, but you need to understand that you are
discussing presentation in a CSS NG and as such this "interpration" does
not make sense here. In a photography NG you can most likely talk about
presentation as you perceive it with no issues. Of course, if in that
other NG you talk about using presentation w.r.t. CSS in this same light
then you may confuse people in that NG when they deal with CSS.

There is nothing special about the last stage,
except simply that it IS the last stage, and can therefore still be
manipulated in ways that earlier results cannot.
The end result is different - therefore there "is" something special.

In one case you only have content and in the other case you need
presentation applied to your content to acheive the same effect.

People who work with
inherently visual material can make decisions about where certain presentation
is added - before, during, or after the final HTML.

In other NG's not related to CSS - yes. In this one you will only cause
confusion by thinking that way.

In fact, having done extensive work in graphic design I can see where
you are coming from the problem is "context" w.r.t. CSS.

HTH,

--Nikolaos

[Nikolaos Giannopoulos]

Barry Pearson wrote:

Nikolaos Giannopoulos wrote:

Use an id as it will only appear exactly once on any given page - I'm
surprised nobody mentioned this sooner.
Let me clarify something here:

my surprise is not that someone didn't tell you to use an "id" sooner -
my surprise is that nobody told you to use a "class" or "id" to minimize
the number of style sheets that you would require - sooner.

In my experience, all you
typically ever need is 1 or possibly 2 style sheets.
Again, another clarification:

I use 1 to 2 style sheets "per project" and rarely see any reason to use
more.

Is there a specific advantage in using "id" instead of "class"?
Yes, - "for me that is" - and that is that I find it easier to tell when
looking at my CSS what rules apply to a complete page and what I may use
more than once - i.e. if I see an id then I know that, in my web page I
can look for it to be higher up in outer nested tags and once I find it
I know its not used elsewhere.

Tina, is right that either would do and that it is important to keep her
comment of specificity in mind as id's have higher specifity than
classes and this makes sense since they can only be used once on a page
(I think of it as an override behaviour).

Personally, I think it depends on your page but I tend to start with
id's when I know I am just doing something once.

Does it make
it work in more cases? I thought I had read of problems with some browsers
(but probably they were older ones).
None that I know of -

One reason I use more than 1 CSS for a site is that it makes it easier to
re-use CSSs across sites. For example, I have a CSS that I use for on-line
academic papers that is common to all my sites with such papers on, a
photograph page style CSS common to all sites with photographs on, etc. Then
if I change one of these, I just copy the file to all relevant sites, I don't
have to change text within a file.
Right. But it sounds like each of your CSS files suits a different
project - and I don't see any problem with that. It's using multiple
style sheets to have multiple different backgrounds that might be
overkill (unless you were doing something dynamic with JavaScript).

This is why it sometimes makes sense to keep going back to tutorials
or the CSS spec as we go along - all too often people start learning
CSS and keep plowing not realizing that they missed things along the
way that may need to be re-clarified now that they have more
experience.

Yes. And it is also one of the reasons I try to ensure that pages display the
same with my test-set of browsers at their default settings, or else I know
why not. I sometimes find that a misunderstanding will be tolerated by one
browser but not another. I learn a lot finding out why.

No, you missed the point of my comment. You said:
(Hm! Should it be ID, not class?)

You simply need look at the CSS spec or a CSS tutorial as this is a
basic CSS question.

--Nikolaos

[Jonathan Snook]

"Nikolaos Giannopoulos" <ni******@solmar.ca> wrote in message
news:d9********************@magma.ca...

After all - I did web authoring
with HTML/CSS at 2 different places in the process.

Yes, you did but the end result is different and your missing that.

This seems like a wierd way to argue. How is he "missing that" when he says:

That is why, while I understand the narrow use of the words that some may use, I see the entire process of photography as adding presentation by various technologies and standards.

Which is what I thought, but you need to understand that you are
discussing presentation in a CSS NG and as such this "interpration" does
not make sense here. In a photography NG you can most likely talk about
presentation as you perceive it with no issues. Of course, if in that
other NG you talk about using presentation w.r.t. CSS in this same light
then you may confuse people in that NG when they deal with CSS.

You then say, "Which is what I thought". Shouldn't you read the whole
message and argue based on the cumulative argument? But I digress.

Your argument that "any presentation done without CSS is content" seems
extreme. Would you argue that the <b> tag is presentation or content? How
about the content property in CSS? Is that presentation or content? In the
context of the web site user (which is how we should always look at it),
presentation and content can be created at any step of the way. Like putting
text into an image and applying a font style to it. Sure, the text is the
content but the font style is simply presentation. And thinking of it this
way should not confuse the masses who read this ng.

Jonathan

[Nikolaos Giannopoulos]

Jonathan Snook wrote:

"Nikolaos Giannopoulos" <ni******@solmar.ca> wrote in message
news:d9********************@magma.ca...

After all - I did web authoring
with HTML/CSS at 2 different places in the process.
Yes, you did but the end result is different and your missing that.

This seems like a wierd way to argue. How is he "missing that" when he says:

That is why, while I understand the narrow use of the words that some may use,I see the entire process of photography as adding presentation by varioustechnologies and standards.

Which is what I thought, but you need to understand that you are
discussing presentation in a CSS NG and as such this "interpration" does
not make sense here. In a photography NG you can most likely talk about
presentation as you perceive it with no issues. Of course, if in that
other NG you talk about using presentation w.r.t. CSS in this same light
then you may confuse people in that NG when they deal with CSS.

You then say, "Which is what I thought". Shouldn't you read the whole
message and argue based on the cumulative argument? But I digress.

Actually you do digress and I did read the whole message before
replying. Would you have prefered if I removed the words "Which is what
I thought" from the comment. Does that in any way change anything?

Barry presents a view that adding visual effects to an image is adding
presentation - while it may very well be in the context of other areas
it is not so in the context of CSS. In web authoring, an image can not
have visual aspects - which you call presntation - stripped from it and
whether or not CSS is available the visual aspects will be present.

Your argument that "any presentation done without CSS is content" seems
extreme. Would you argue that the <b> tag is presentation or content? How
about the content property in CSS? Is that presentation or content?
Your right there are some exceptions and these are definately exceptions
but that in no way validates his distinction between presentation and
content.

In the
context of the web site user (which is how we should always look at it),
presentation and content can be created at any step of the way. Like putting
text into an image and applying a font style to it. Sure, the text is the
content but the font style is simply presentation. And thinking of it this
way should not confuse the masses who read this ng.
Not in the context of *this* NG it isn't and not if we follow what is
being discussed.

Barry said:
Rather than debate terminology, I'll give you a demonstration of using
W3C-conformant CSS to add a border to a photograph before turning it
into a JPEG. I hope that you will then see that, for inherently visual
material, the split between content & presentation is forever blurred.

In the context of CSS there is no blur. What he calls content +
presentation above is simply content.

This is a style sheet authoring NG isn't it?

--Nikolaos

[Gerhard Fiedler]

On Sun, 12 Oct 2003 15:16:37 -0400, Nikolaos Giannopoulos wrote:

This is a style sheet authoring NG isn't it?

Yes, but the "stylesheets" come after comp and infosystems and www and
authoring. Which means IMO opinion (which is derived from general
inheritance principles as applied in many languages that are part of
the comp "domain") that the general principles of what makes content
and what makes presentation, as used in other domains of "comp" and
especially "www.authoring" should still be considered.

After all, most here create web sites (as opposed to style sheets
only) and discuss issues that pertain not only to the very limited
scope of CSS, but also to its application in the real world -- that
includes many techniques. It doesn't help a lot to have a CSS-specific
definition of content in web site creation that is not applicable
(because too centered on CSS) to a discussion of web authoring in a
larger context. Rather than coming up with exclusive nomenclature, it
would be preferrable to use inclusive nomenclature, that makes sense
in general. This also has the advantage that thoughts derived from
other environments (for example XML or MVC) can be helpful.

Of course that has the result that religiously strict definitions are
not easily available, but that's how programming tends to be (and life
in general :)

[Jonathan Snook]

"Nikolaos Giannopoulos" <ni******@solmar.ca> wrote in message
news:zG********************@magma.ca...

Actually you do digress and I did read the whole message before
replying. Would you have prefered if I removed the words "Which is what
I thought" from the comment. Does that in any way change anything?
It's not the "which is what I thought" that I had issue with. It was saying
that he was missing a point only to say in the next paragraph that you
understood that he got the point (although you disagreed with it, and that's
fine).
Your right there are some exceptions and these are definately exceptions
but that in no way validates his distinction between presentation and
content.

My examples enforce the concept that presentation can be added at any point
in the process and even in the context of this NG, it doesn't make it
invalid. Barry's issue was a matter of when. CSS is one method of adding
presentation. Presentation can be added on top of presentation like a
painter adding brush strokes unto a canvas. Each new stroke doesn't relegate
the previous to "content", even if applied with a different "brush".

Jonathan