Question of font size change

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 body like

 
Abc 
Abc 
Abc 
Abc 
Abc 
Abc 
Abc 
Abc 
Def

 
Abc 
Abc 
Abc 
Abc 
Abc 
Abc 
Abc 
Abc 
Def


and what would an utterly W3-etc.-compliant system show?

Standard size at the beginning of each line, followed by eight
increment/decrement steps of one point size?

Standard size at the beginning of each line, followed by one
increment/decrement step of modest ratio, and the rest at that size?

Something in between those two?

Something different?

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.com/faq/> JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.

Dr John Stockton wrote:[color=blue]
>
> 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 body like
>
> 
> Abc 
> Abc 
> Abc 
> Abc 
> Abc 
> Abc 
> Abc 
> Abc 
> Def
> 
> 
> Abc 
> Abc 
> Abc 
> Abc 
> Abc 
> Abc 
> Abc 
> Abc 
> Def
> 
>
> and what would an utterly W3-etc.-compliant system show?
>
> Standard size at the beginning of each line, followed by eight
> increment/decrement steps of one point size?
>
> Standard size at the beginning of each line, followed by one
> increment/decrement step of modest ratio, and the rest at that size?
>
> Something in between those two?
>
> Something different?[/color]

Since you are using increments and not absolute sizes and since the
 elements are nested, you should see progressive increases or
decreases in sizes. However, the increments are not necessarily
one point; instead, different browsers may implement the increments
differently.

I still have Web pages that use the SIZE attribute with the 
element. As I update those pages, however, I'm converting to using
style-sheet sizing expressed in percentages. Then I don't have to
be concerned with how different browsers implement incremental
sizing.
I know that the element is deprecated in HTML 4.01. I'll
accept that for attributes on the element. However, I still like
to put styles on .

--

David E. Ross
<URL:http://www.rossde.com/>

I use Mozilla as my Web browser because I want a browser that
complies with Web standards. See <URL:http://www.mozilla.org/>.

On Thu, 05 May 2005 18:47:44 -0700, David Ross <nobody@nowhere.not>
wrote:
[color=blue]
> However, I still liketo put styles on .[/color]

Why not just use a ?

David Ross <nobody@nowhere.not> wrote:
[color=blue]
> Since you are using increments and not absolute sizes and since the
> elements are nested, you should see progressive increases or
> decreases in sizes.[/color]

That's what happens in practice, but specifications are vague on this.
They do explicitly remark that the effect is browser-dependent and that
not all browsers render all sizes. Moreover, CSS specifications say
that browser _may_ honor presentational hints expressed in HTML markup,
implying that they may ignore them as well.

The HTML specs vaguely say that a signed number in size="..." means
"a relative increase in font size", without saying what it is relative
to. But I agree with the idea that the _intent_ is that the effects of
nested font elements with relative size values are cumulative.

I can't help mentioning how foolish it was to define things so that
+1 is fundamentally different from 1.
[color=blue]
> However, the increments are not necessarily one point;[/color]

They are hardly ever one point. On IE, sizes 1 through 7 are mapped to
physical sizes 7.5, 10, 12, 13.5, 18, 24, and 36 points. By the way,
this alone should make us refrain from using or
equivalent relative size.
[color=blue]
> I know that the element is deprecated in HTML 4.01. I'll
> accept that for attributes on the element. However, I still like
> to put styles on .[/color]

The only case where using tags in new documents is a situation
where you are talking _about_ fonts, so that really corresponds
to the content of your message. Even in such cases (say, writing that
"text in Arial font looks much larger than
text in Times New Roman font),
it can well be argued that you should be using just normal text
accompanied with a separate illustration as an image.

Returning to the original question: it would be most essential to ask
why the document contains nested elements in the first place;
this would be more useful than any answer to the question what the
effect should be.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

"Jukka K. Korpela" <jkorpela@cs.tut.fi> posted:
[color=blue]
> On IE, sizes 1 through 7 are mapped to physical sizes 7.5, 10, 12, 13.5,
> 18, 24, and 36 points. By the way, this alone should make us refrain
> from using or equivalent relative size.[/color]

Interesting... I'd never actually looked into what MSIE used for those
sizes, other than noticing *too* small in some cases. On one of my old
browsers I manually set in what each font size was to be rendered with
(font face and size), one of the first things I did was make the first
(smallest) three sizes the same as each other, the second was making the
differences between the bigger fonts less extreme. I'm sure we've all had
to put up with at least a few pages where the webnutter has tried to make
everything 48 point text.

--
If you insist on e-mailing me, use the reply-to address (it's real but
temporary). But please reply to the group, like you're supposed to.

This message was sent without a virus, please delete some files yourself.

Andy Dingley wrote:[color=blue]
>
> On Thu, 05 May 2005 18:47:44 -0700, David Ross <nobody@nowhere.not>
> wrote:
>[color=green]
> > However, I still liketo put styles on .[/color]
>
> Why not just use a ?[/color]

I use because that flags for me what kind of style I'm
using. I have styles in my external style-sheet file defined only
for FONT because they affect how fonts are displayed.

 is somewhat ambiguous, not in the HTML specification, but in
reminding me what I'm doing in my Web page.

--

David E. Ross
<URL:http://www.rossde.com/>

I use Mozilla as my Web browser because I want a browser that
complies with Web standards. See <URL:http://www.mozilla.org/>.

Dr John Stockton wrote:[color=blue]
> 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 body like
>
> 
> Abc 
>[/color]
The standard font "sizes" are a range from 1 to 7, 1 is the smallest.
Each browser decides what size each of those are.
Each size=+1 increments to the next "size" relative to the current
Basefont (default size is 3).
The code you show has this effect:
- The size increases once since the basefont size does not change.
- The size decreases once since the basefont size does not change.

--
jmm dash list (at) sohnen-moe (dot) com
(Remove .AXSPAMGN for email)

JRS: In article <Xns964E87F89953Djkorpelacstutfi@193.229.0.31>, dated
Fri, 6 May 2005 10:24:25, seen in news:comp.infosystems.www.authoring.ht
ml, Jukka K. Korpela <jkorpela@cs.tut.fi> posted :[color=blue]
>David Ross <nobody@nowhere.not> wrote:[/color]
[color=blue][color=green]
>> However, the increments are not necessarily one point;[/color]
>
>They are hardly ever one point. On IE, sizes 1 through 7 are mapped to
>physical sizes 7.5, 10, 12, 13.5, 18, 24, and 36 points. By the way,
>this alone should make us refrain from using or
>equivalent relative size.[/color]

That agrees, more or less, with what I observe in my IE4 using
<URL:http://www.merlyn.demon.co.uk/js-anclk.htm>, radio "Do3", ...

However, the code I posted gives just one step up and one step down; the
steps are not cumulative (maybe a true bug); changing the +1 +1 +1 ...
to +1 +2 +3 ... gives 4 increasing steps before saturation; and changing
-1 -1 -1 ... gives 2 decreasing steps - 7 different sizes in all.
[color=blue]
>Returning to the original question: it would be most essential to ask
>why the document contains nested elements in the first place;
>this would be more useful than any answer to the question what the
>effect should be.[/color]

/Rem acu tetigisti/. It was demonstration code only.

We can, therefore, confidently accept your "They are hardly ever one
point."

Now we have, frequently posted and recently updated, a newsgroup article
containing, /inter alia/, <blockquote>

Subject: HTML FAQ (Frequently Asked Questions) List

along with the Frequently Encountered Problems list at
* http://www.htmlhelp.org/faq/fep/

If you do that, you may find that you've answered your question with
no need to post (and no confusion from well-meaning wrong answers).

</blockquote>

Now FEP is currently (unless *very* recently changed) at Version 1.005
of 1997-02-23. It contains "vi. Did you use the FONT element?".

That section asserts quite clearly that & change the size by +7 & -7 points, with a clear implication
that +n and -n will change the size by the corresponding number of
points, at least if the result is greater than zero.

SO:

ISTM questionable for a FAQ to refer to a FEP which is over 8 years old;
are there no new questions?

ISTM unreasonable for a newsgroup FAQ to cite a FEP which is
persistently wrong; do the regular experts not occasionally check what
their newsgroup's FAQ is citing?

ISTM that, when errors are reported to the given address, amendments
should be made within a reasonable period of time; the FEP does say
"This document is maintained by the WDG, ...".

ISTM that a FAQ posted to a technical newsgroup is better maintained by
an active expert participant in the group.

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.com/faq/> JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.

Dr John Stockton <spam@merlyn.demon.co.uk> wrote:
[color=blue]
> However, the code I posted gives just one step up and one step
> down; the steps are not cumulative (maybe a true bug);[/color]

Oh my. I seem to have commented on the code without actually checking
how browsers treat it, relying on my memory. I was probably thinking
about the cumulative effect of nested <big> (or ) elements.
Probably I never checked how nested works.
(By the way, it needs to by size="+1" with quotes, by all HTML specs;
the oddity that size=-1 is allowed without quotes, in good old HTML, is
explained by the fact that the "-" character is a name character due to
its use as a hyphen.)

But as I wrote, the specs just say that size="+1" means a relative
increase, without answering the question "relative to what?" So we
cannot really say that non-cumulative effect is a bug; just unexpected
behavior. It's yet another difference between and
<big>. Apparently size="+1" is relative to the base font as set by the
overall default of 3 or by a <basefont size="..."> tag but unaffected
by other markup.
[color=blue]
> Now we have, frequently posted and recently updated, a newsgroup
> article containing, /inter alia/, <blockquote>[/color]
- -[color=blue]
> Now FEP is currently (unless *very* recently changed) at Version
> 1.005 of 1997-02-23. It contains "vi. Did you use the FONT
> element?".[/color]

I hadn't realized it was _that_ old. The WDG FAQ is rather old too, but
mostly correct, though it does not cover some topics that have become
fairly relevant. But FEP is _really_ dusty.
[color=blue]
> That section asserts quite clearly that & size="-7"> change the size by +7 & -7 points, with a clear
> implication that +n and -n will change the size by the
> corresponding number of points, at least if the result is greater
> than zero.[/color]

Oh my. That's surely incorrect.
[color=blue]
> ISTM questionable for a FAQ to refer to a FEP which is over 8 years
> old; are there no new questions?[/color]

It is somewhat odd.
[color=blue]
> ISTM unreasonable for a newsgroup FAQ to cite a FEP which is
> persistently wrong;[/color]

The FEP document seems be just wrong in some items, and it's manifestly
old when it starts with a question on DOCTYPE, treating HTML 3.2 as the
modern version and not mentioning DOCTYPE sniffing at all.
[color=blue]
> do the regular experts not occasionally check
> what their newsgroup's FAQ is citing?[/color]

Apparently not. I'm afraid I haven't looked at it for 7 or 8 years.
[color=blue]
> ISTM that a FAQ posted to a technical newsgroup is better
> maintained by an active expert participant in the group.[/color]

Quite right. But a real face lift (checking the contents of the FAQ and
eliminating the FEP in the process) would be a major effort. Just
fixing a few errors and including a "last modified" date of 2005 would
be misleading. We would need a volunteer or two plus, and preferably
someone affiliated with the WDG, so that the change could consist of
fixing the WDG FAQ rather than creating a competing FAQ. Do I see any
hands?

So your point wasn't really font size change, was it? People would wake
up more probably if the Subject line referred to the need for a
major fix of the FEP or the FAQ.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

JRS: In article <Xns965151588E9EAjkorpelacstutfi@193.229.0.31>, dated
Mon, 9 May 2005 05:02:03, seen in news:comp.infosystems.www.authoring.ht
ml, Jukka K. Korpela <jkorpela@cs.tut.fi> posted :[color=blue]
> ...[/color]
[color=blue][color=green]
>> ISTM that a FAQ posted to a technical newsgroup is better
>> maintained by an active expert participant in the group.[/color]
>
>Quite right. But a real face lift (checking the contents of the FAQ and
>eliminating the FEP in the process) would be a major effort. Just
>fixing a few errors and including a "last modified" date of 2005 would
>be misleading. We would need a volunteer or two plus, and preferably
>someone affiliated with the WDG, so that the change could consist of
>fixing the WDG FAQ rather than creating a competing FAQ. Do I see any
>hands?[/color]

Agreed. However, the FAQ posted in this newsgroup can be fixed (it's
only two months old) - all it needs to do is to point out the age of the
WDG stuff and recommend perusal also of an auxiliary updating document.

Material for that document could be posted here and discussed until it
is right before putting it on the Web (I cannot host it; no spare
bandwidth). I could contribute to that discussion, perhaps; but my
knowledge is not broad enough to enable me to edit its prime copy.

[color=blue]
>So your point wasn't really font size change, was it? People would wake
>up more probably if the Subject line referred to the need for a
>major fix of the FEP or the FAQ.[/color]

You could have attended to that; I just did. I didn't want to wake them
up until my opinion was confirmed.

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.com/faq/> JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.

Question of font size change

re: Question of font size change

re: Question of font size change

re: Question of font size change

re: Question of font size change

re: Question of font size change

re: Question of font size change

re: Question of font size change

re: Question of font size change

re: Question of font size change

Similar HTML / CSS bytes

/bytes/development

/bytes/it

/bytes/about