Line spacing not working

Ben C wrote:

This reveals you know nothing about testing.

Your statement is bad manners [...]

You started it.

At this point I need to ask you to keep using the same forged sender
identity until you get both a clue and some manners.

You are still babbling about ways to detect whether a browser correctly
implements initial values, which is both off-topic here and ridiculous. Your
procedure is both sloppily formulated and obviously ineffective.

You can tell that a span is display: inline very easily.

Actually, this depends on the context.

At last something of what I have been trying to explain seems to have
sunk in!

I don't see any point in trying to explain anything to you, in this issue at
least, since you seem to gladly accept a point that proves your whole
approach wrong, yet you claim it as a victory. The initial values do _not_
depend on context. If you didn't know even this, I start to understand why
you have gone so wrong. I still don't know why you started making foolish
statements like "you know nothing about testing", which can hardly be
anything but feeble attempts at making insults.

--
Yucca, http://www.cs.tut.fi/~jkorpela/

On 2009-11-01, Jukka K. Korpela <jkorpela (AT) cs (DOT) tut.fi> wrote:

Ben C wrote:

This reveals you know nothing about testing.

Your statement is bad manners [...]

You started it.

At this point I need to ask you to keep using the same forged sender
identity until you get both a clue and some manners.

Thank you in advance.

[...]

You can tell that a span is display: inline very easily.

Actually, this depends on the context.

At last something of what I have been trying to explain seems to have
sunk in!

I don't see any point in trying to explain anything to you, in this issue at
least, since you seem to gladly accept a point that proves your whole
approach wrong, yet you claim it as a victory. The initial values do _not_
depend on context.

Of course we both know that.

The point is, in order to test the effects of certain values of certain
properties, you need to place the element in a a particular context.

I believe I gave an example of how you might test whether or demonstrate
that the initial value of table-layout is auto.

Ben C:

[Jukka K. Korpela:]

More importantly, testing the effects of properties on SPAN reveals
you nothing about initial values. If you set a property for it, you
override any initial value.

This reveals you know nothing about testing.

Your statement is bad manners [...]

You started it.

I think when Yucca wrote "reveals you nothing" he meant "tells you
nothing" not "reveals you [know] nothing".

--
John

On 2009-11-01, John Dunlop <john (AT) dunlop (DOT) name> wrote:

Ben C:

[Jukka K. Korpela:]

More importantly, testing the effects of properties on SPAN reveals
you nothing about initial values. If you set a property for it, you
override any initial value.

This reveals you know nothing about testing.

Your statement is bad manners [...]

You started it.

I think when Yucca wrote "reveals you nothing" he meant "tells you
nothing" not "reveals you [know] nothing".

I think you're right, that _is_ what he meant, but I did read it as
"reveals you [know] nothing", which is why I said he knew nothing about
testing, and things kind of escalated from there.

But perhaps I started it... One always thinks one is the good guy.

In which case, if you're reading this Mr K, then I apologize. You don't
necessarily know nothing about testing.

Although I still don't agree with you that it isn't possible,
practically speaking, to distinguish between a browser's implementations
of default styles for HTML elements and of initial values of CSS
properties.

dorayme wrote:

If you want to think of initial values as coming from a fictitious
sheet, which you can if you like,

That's a pointless assumption, so why do you play in terms of it, instead of
expressing your ideas in CSS terms.

My motive is to get away from
such a variable as "normal", to cash its value!

It is not a variable and it is not replaceable by any other value, within
CSS.

In this sheet, there
would simply be

body {line-height: 1.2;}

That would correspond to a poor implementation, as in a good implementation,
the meaning of the value normal for line-height depends on the font. (This
does not make the value normal a variable. Its effect varies, but you cannot
assign a value to it etc.)

The point of the 'useful fiction' is to not worry where values are
coming from, they are what actually confronts the website maker.

The fiction is worse than useless since it has misled you.

The master sheet will be different for every browser but not that
different. Although you and he might not know it, when JK says words
to the effect that line-height is set too small..., this in effect
means that in most browsers, the master sheet is giving too much
below 1.3 to be comfortable with some popular fonts.

No, the bottom line is that the value normal is, on many browsers for many
fonts, too small for normal use of the font, especially when line length is
large. And by browser defaults, lines extend from the left of the browser
window to its right, with small margins.

Moreover, the line height isn't something that can be regarded as selected
by the user in the same sense as default font face and size can. Setting
default font face and size in a browser is easy, though less common than it
should be; it is normal control of a program, quite comparable to how you
set font face and size in your favorite word processor. You don't need to
understand anything about CSS or HTML for that.

Setting default line-height in a browser requires a stylesheet, and though
it can be trivial to us, it isn't trivial at all to a person who never heard
of CSS and never needed to. Moreover, any value would be a wild guess. If
you set line-height so that it suits the default font face and family you
have set (in browser settings or in a user style sheet), it will also be
applied when the font is something different. This would not create a
problem if authors always set line-height when they set font, but we know
they don't, and this discussion has contained opinions saying that they even
shouldn't!

So override with at least 1.3 in author sheet. Simple enough. Try
working all this out in terms of what exactly it is in each browser
that sets 1.2 when it comes brand new out of the box. No thanks,
would say the practical website designer.

OK, but it's worth clarifying what the spec means when it talks about
"initial values".

No, it does not clarify that at all.

This is an excellent point and I am not meaning to dispute it.

Well, maybe there is no point to be disputed, but the statements were
grossly misleading. They obscure rather than clarify the concept of "initial
value".

The "initial value" concept is simple enough and needs no clarification, but
it may need a motivation, a description of _why_ initial values need to be
set.

Consider an XML document, for a change. As such, it is a data structure with
some data in it, without any defined or suggested rendering. Now, if you add
a reference to a CSS style sheet in it, the picture changes. You can set
values for properties of elements as you like, but what happens to
properties that you don't set at all? Without defined initial values, you
would have to set them all - all CSS properties for all elements (though
admittedly you could use the universal selector *) - in order to have a
defined rendering. The initial values set simple, unimaginative rock-bottom
defaults for everything. Of course they are partly quite inappropriate e.g.
for headings, paragraphs, tables, etc., but it is the author's
responsibility to set the properties that are essential to rendering - but
he does not need to worry about setting _everything_.

With HTML, the picture is different, since many elements have default
renderings different from those corresponding to initial values in CSS.
Thus, what you see (when not using any author or user style sheet) is the
net effect of initial values, browser's style sheet, and browser
idiosyncracies (like rendering elements outside the scope and control of
CSS, as browser often do, and used to do even more often, with form fields.
When authoring HTML documents, you cannot rely on initial values.

We recommend a used value for
'normal' between
1.0 to 1.2). Between indeed! It is either 1.bloody2 or not for the
practical website maker! <g

That's not practical at all. The practical, and also theoretical, situation
is that the meaning of normal varies, within one browser, depending on font,
and maybe even other factors.

The problem with a suggested range of 1.0 to 1.2 is that such values are
generally too small: 1.0 is absurd for most fonts, and even 1.2 isn't
usually sufficient for the fonts people actually use on their web pages.

To me this sounds like the master CSS sheet contains the initial
values.

Yes, indeed, that is the idea.

No, that's not the idea at all. The idea is that the initial values exist
outside all style sheets and never participate the cascade (remember the
most misunderstood of all CSS concepts?) except in the sense that when
absolutely no style sheet assigns a value to a property of an element, the
initial value is applied.

For example, if you wake up in the middle of the night in a bad
sweat thinking your browser makes child divs of divs inline, you can
easily test that this is not so by

div div {display: block}

and seeing if anything at all changes on the pages you might have had
in mind as examples.

And then you get shocked when you detect that a div inside a div is inline
when the outer div is inside a table. Well, it isn't, but the risk for that,
however miniscule, is surely much greater than getting simple nested divs
wrong.

This, however, has nothing to do with initial values (which you seem to be
trying to discuss).

So what do you make of FF showing a line-height of a mere 1 times font
size when "Browser Default Style' is turned off?

Beats me. Maybe I'll take a look and give the issue some consideration. My
bet is that there's a misunderstanding. You seem to be implying that such a
setting would set all properties to their initial values. It is easy to see
that this does not happen. Headings still have large font size and margins,
<i> still causes italics, etc. Why would you thus assume that this browser
function, which has no adequate documentation published, would show the
effect of line-height: normal, especially if you think it always means "mere
1 times font size" in this browser. That would be rather abnormal
implementation of normal.

That is the initial value, no?

No it isn't.

I know, it is "normal" - but I am talking brass tacks, what
it comes down to.

It comes down to different things, as it should. If it comes down to the
font size, it's either an odd font or an odd browser feature.

Followups trimmed.

--
Yucca, http://www.cs.tut.fi/~jkorpela/

Mon, 02 Nov 2009 13:41:46 +1100 from dorayme
<doraymeRidThis (AT) optusnet (DOT) com.au>:

In this sheet, there would
simply be

body {line-height: 1.2;}

or even, I don't mind and it makes no difference anyway, other things
being equal,

* {line-height: 1.2]

The point of the 'useful fiction' is to not worry where values are
coming from, they are what actually confronts the website maker. The
master sheet will be different for every browser but not that different.
Although you and he might not know it, when JK says words to the effect
that line-height is set too small..., this in effect means that in most
browsers, the master sheet is giving too much below 1.3 to be
comfortable with some popular fonts.

Sorry, I don't understand. Given that 1.2 is too low for some
popular fonts, why set it to 1.2? I found when I had line-
height:1.2, and selected Palatino in my browser, then printed my Web
page, that the underscores under links sometimes didn't print because
they interfered with the ascenders of the following line.

Isn't "normal" better than a specific number because it lets the
browser pick a line-height based on choice of font?

--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2.1 spec: http://www.w3.org/TR/CSS21/
validator: http://jigsaw.w3.org/css-validator/
Why We Won't Help You:
http://diveintomark.org/archives/2003/05/05/why_we_wont_help_you

Mon, 2 Nov 2009 09:08:11 +0200 from Jukka K. Korpela
<jkorpela (AT) cs (DOT) tut.fi>:

No, the bottom line is that the value normal is, on many browsers for many
fonts, too small for normal use of the font, especially when line length is
large. And by browser defaults, lines extend from the left of the browser
window to its right, with small margins.

So you're saying that "many browsers" have implemented "normal"
poorly?

--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2.1 spec: http://www.w3.org/TR/CSS21/
validator: http://jigsaw.w3.org/css-validator/
Why We Won't Help You:
http://diveintomark.org/archives/2003/05/05/why_we_wont_help_you

Stan Brown wrote:

Mon, 2 Nov 2009 09:08:11 +0200 from Jukka K. Korpela
jkorpela (AT) cs (DOT) tut.fi>:
No, the bottom line is that the value normal is, on many browsers for many
fonts, too small for normal use of the font, especially when line length is
large. And by browser defaults, lines extend from the left of the browser
window to its right, with small margins.

So you're saying that "many browsers" have implemented "normal"
poorly?

It's a matter of opinion, influenced by the fact that screen sizes have
almost doubled in the lifetime of current browsers.

If you faced me with default text spread across the full width of my 24"
display, I'd find it most uncomfortable reading.


--
Steve Swift
http://www.swiftys.org.uk/swifty.html
http://www.ringers.org.uk

Stan Brown wrote:

Given that 1.2 is too low for some
popular fonts, why set it to 1.2?

There's no good reason to do so, except perhaps that 1.2 tends to be
somewhat larger and therefore somewhat better than common browser defaults.

The line-height should be set according to the font properties (and other
specifics of the page). This creates a problem, since it implies that in
practice you need to set the font face, more or less. Yet you need to
consider that users may override your font settings easily, so the
line-height should be tolerable for any typical font. That's rather awkward
of course.

I found when I had line-
height:1.2, and selected Palatino in my browser, then printed my Web
page, that the underscores under links sometimes didn't print because
they interfered with the ascenders of the following line.

My system lacks a font named Palatino but it has "Palatino Linotype".
Testing it on IE 8 supports your observations: with line-height defaulted,
the rendering is OK, apparently with a fairly large line height, whereas
line-height: 1.2 makes the rendering worse, though not illegible.

Isn't "normal" better than a specific number because it lets the
browser pick a line-height based on choice of font?

In theory it is, but in practice browsers aren't that clever at all.

Testing with Arial, probably the most common font on web pages, I see lines
too close to each other even for a short line length, when line-height is
default. Setting it to 1.2 is an improvement over the browser default, but
the optimum is somewhere near 1.4, depending on line length of course. With
Verdana, the situation is even worse.

Followups set to alt.html only.

--
Yucca, http://www.cs.tut.fi/~jkorpela/

In article <MPG.255895c7c7c2a20a98bd06 (AT) news (DOT) individual.net>,
Stan Brown <the_stan_brown (AT) fastmail (DOT) fm> wrote:

Mon, 02 Nov 2009 13:41:46 +1100 from dorayme
doraymeRidThis (AT) optusnet (DOT) com.au>:
In this sheet, there would
simply be

body {line-height: 1.2;}

or even, I don't mind and it makes no difference anyway, other things
being equal,

* {line-height: 1.2]

The point of the 'useful fiction' is to not worry where values are
coming from, they are what actually confronts the website maker. The
master sheet will be different for every browser but not that different.
Although you and he might not know it, when JK says words to the effect
that line-height is set too small..., this in effect means that in most
browsers, the master sheet is giving too much below 1.3 to be
comfortable with some popular fonts.

Sorry, I don't understand. Given that 1.2 is too low for some
popular fonts, why set it to 1.2? I found when I had line-
height:1.2, and selected Palatino in my browser, then printed my Web
page, that the underscores under links sometimes didn't print because
they interfered with the ascenders of the following line.

Isn't "normal" better than a specific number because it lets the
browser pick a line-height based on choice of font?

I was not meaning to recommend 1.2, it was just an instance of putting
in a line-height rule. I am not surprised by your experience. I really
do think that unless we nail this business down a bit better, it is
better not to say anything at all about line-height except for really
clear cases for elements where you really don't want any fine tuning but
maybe quite big gaps (perhaps for graphic effect). Or just be happy with
* {line-height: 1.3} as if it is a sort of min-line-height that will
never be too bad.

But really, you might have to ask JK for some practical examples of
author style sheets he thinks are good that avoid the problem of
browsers settling on too low a figure. There are too many variables in
this matter that cloud the issue to say anything practical and general.
Not much use in saying browsers are too mingy with some fonts if there
is no practical and general policy to address this inadequacy.

--
dorayme