Line spacing not working

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

Ben C wrote:

The initial values are all in the CSS specification, and the browser
_has_ to do those as printed

We're in a wrong group...

I've set the Followup.

but anyway, the "_has_ to" part is misleading. The
initial values are just rock bottom defaults, and you cannot actually see
whether a browser "does" them, since a browser may apply a browser style
sheet without telling what it is.

In theory yes. But testing the effect of each property on <span> should
reveal the initial values, since it would be absurd if the browser
default stylesheet set any styles on span.

(In CSS3 you can set any property back to "initial").

Then for anything that differs from those values, there's the default
stylesheet, which is up to the individual browser, but usually mostly
the same,

No it isn't. It's rather different.

Well, I still think they're mostly the same. You are going to have to
provide examples if you want to convince me.

and the spec suggests a default stylesheet.

It presents it as descriptive _and_ (semi)normative, and in reality it's
neither. Most browsers mostly use something like it, but the "default
stylesheet" contains oddities and absurdities (partly not implemented in any
browser).

Go on, name and shame them. The only one I can think of is br:before {
content: "\A"; white-space: pre-line } since it doesn't appear to quite
achieve the HTML specification of BR (that it should behave like
U+2028).

Observe that the default stylesheet does not set span to display:
inline-- it doesn't need to, because the initial value of display is
inline.

And it would be most absurd to do otherwise.

On 2009-10-31, dorayme <doraymeRidThis (AT) optusnet (DOT) com.au> wrote:

In article <slrnhel82c.39n.spamspam (AT) bowser (DOT) marioworld>,
Ben C <spamspam (AT) spam (DOT) eggs> wrote:

On 2009-10-29, dorayme <doraymeRidThis (AT) optusnet (DOT) com.au> wrote:
In article <slrnheik1s.334.spamspam (AT) bowser (DOT) marioworld>,
Ben C <spamspam (AT) spam (DOT) eggs> wrote:

On 2009-10-29, dorayme <doraymeRidThis (AT) optusnet (DOT) com.au> wrote:
[...]
...
As with many other presentational matters, there are initial values set
by the browser via internal coding, sometimes in conjunction with user
preferences or options.

The initial values are all in the CSS specification, and the browser
_has_ to do those as printed (see the "full property table" in one of
the appendices).


The actual values set as 'normal' get to be decided, I was supposing, by
the browser via internal coding, sometimes in conjunction with user
preferences or options. Are we talking at cross purposes?

A sufficiently good mental model for everyone except Korpela is that the
browser hard-wires somewhere the initial values for each property and
then loads its own default stylesheet from somewhere just like any other
stylesheet.

So if the part of the browser trying to lay out the page finds a span,
it asks itself, should this be block or inline?

Then it looks in all the stylesheets, and can't find anything matching
the span, even in its own default stylesheet. So then it says, well,
display is always inline in the absence of anything else.

(Btw, it is hard to know which is the right group for this topic as it
is really about a number of issues that straddles HTML authoring and
CSS. Perhaps alt.html? Anyway, perhaps too late.)

A useful fiction to buy out of having to know the details of how
browsers are made and operate: A browser produces an output only with a
virtual master CSS sheet. In this sheet are all the styles down to as
exact a value as possible. This sheet can be overridden of course by
author or user sheets.

Yes, although in this "virtual master CSS sheet", all selectors are just
*. It would look this:

* display { inline }
* line-height { normal }

etc. The initial value is a property only of properties, not of elements.

I'm assuming by "virtual master CSS sheet" you don't mean the same thing
as "browser default stylesheet".

Now, to go into something, in FF, if you can, try:

http://dorayme.netweaver.com.au/anything.html

Open the web developer facilities and go to Edit CSS, stick in a style
on body for line-height. I have Geneva 16 set for my normal sans-serif
and if I set body {line-height: 1.36} I get about the same look as me
not setting any line-height. What do you want to say about where the
line height is being supplied from in the case? I am happy with my rich
fictitious master sheet that is very far from the minimalist:

http://www.w3.org/TR/CSS21/sample.html

Note how grabbing all this and making an explicit set of styles in the
head of anything.html, leaves the show virtually unchanged. Meaning
partly that this example sheet is certainly very congruent with the one
that FF actually operates with, it may even be exactly the same.

I think it's mostly the same, yes.

There is a menu item under Disable Styles that reads Browser Default
Styles.

I can't find that menu!

Tick this and see what happens to the line height. Now it is a
mingy thing! Where is this coming from? It is coming presumably from
browser coding. It looks like 'line-height: 1;' To see this, open a
couple of tabs. In one tick the Browser Default Styles, in the other
simply add under Edit CSS, body {line-height:1;}. Compare by eye.

You should get line-height: normal, which is usually a bit more than 1
(but depends on the font). And I would expect that to be the same as
with browser default styles since there aren't any line-height rules in
the suggested default stylesheet, which I think is very close to what
the main browsers use. But perhaps what you have discovered is that this
is not the case.

Ben C wrote:

We're in a wrong group...

I've set the Followup.

Overruled. That's not the way to move a discussion. The correct way would
have been to post to both groups, with adequate paraphrasis of preceding
discussion, and checking whether the Subject line corresponds to the actual
topic.

But it's become more or less hopeless to move discussions, and there's
already the confusion created by crossposting to this group and alt.html.
There was reason to add to the confusion by just setting followups, thery
causing messages pop up out of blue sky in a style sheet group, with Subject
"Line spacing not working" and the discussion revolving around something
completely different.

The discussion itself has become too confused, too.

The
initial values are just rock bottom defaults, and you cannot
actually see whether a browser "does" them, since a browser may
apply a browser style sheet without telling what it is.

In theory yes. But testing the effect of each property on <span
should reveal the initial values, since it would be absurd if the
browser default stylesheet set any styles on span.

Well, this is marginally related to HTML, so I'll comment on that side. It
is true that SPAN is defined as inline markup with no special features,
often said to be semantically empty, with the justification that no
semantics (logical meaning or even visual effect) is assigned to it in HTML
specifications. However, it would not be absurd to have a browser stylesheet
with a selector of the form SPAN.FOO, based on "microformat" ideas
(assigning "agreed" meanings to class names - not my piece of cake, but the
idea is just wrong, not absurd).

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. What you can do is to view a document with SPAN elements and
looking at their appearance to see any effects of possible browser style
sheet effects on it, and most probably you won't see any.

Most importantly, SPAN is uninteresting in this respect. Think about H1.
Looking at a document containing an H1 element, with no author style sheet,
you will see a browser's default in a particular situation (browser
settings, display device, phase of the moon, etc.). The HTML specifications
strongly suggest that you should then see quite noticeable effects. But how
would you see whether the browser correctly implements the _initial_ values
for properties? What you see is the effect of applying a browser stylesheet
that overrides any initial values defined in CSS specifications.

The only one I can think of is br:before {
content: "\A"; white-space: pre-line } since it doesn't appear to
quite achieve the HTML specification of BR (that it should behave like
U+2028).

You're wrong. The BR semantics is forced line break, not the use of a
particular control character, specifically not one that is not actually used
in general.

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

On Wed, 28 Oct 2009 14:39:19 -0400, Jonathan N. Little wrote:

Jukka K. Korpela wrote:
Jonathan N. Little wrote:

[...]
If you'd like to look at my site, it's at:
http://211alamedacounty.org/

Strangely, someone's newsreader has changed a server name to a URL.
That's useful in a sense, though questionable in many ways, and surely
not an excuse for not providing a URL proper.

Apparently John's 40tude Dialog.

Full confession: It wasn't my newsreader what done it, 'twas my
newsreader's *user*. I changed it myself, by hand (well, you know what I
mean), because I don't like non-clickable URLs in discussions which begin
based entirely on the content at those very URLs.

--
John
Let's consider it a service to the public, provided at no extra charge.

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

Ben C wrote:

We're in a wrong group...

I've set the Followup.

Overruled. That's not the way to move a discussion. The correct way would
have been to post to both groups, with adequate paraphrasis of preceding
discussion, and checking whether the Subject line corresponds to the actual
topic.

Well, you're the boss.

[...]
Korpela> The initial values are just rock bottom defaults, and you
Korpela> cannot actually see whether a browser "does" them, since a
Korpela> browser may apply a browser style sheet without telling what it
Korpela> is.

In theory yes. But testing the effect of each property on <span
should reveal the initial values, since it would be absurd if the
browser default stylesheet set any styles on span.

Well, this is marginally related to HTML, so I'll comment on that side. It
is true that SPAN is defined as inline markup with no special features,
often said to be semantically empty, with the justification that no
semantics (logical meaning or even visual effect) is assigned to it in HTML
specifications. However, it would not be absurd to have a browser stylesheet
with a selector of the form SPAN.FOO, based on "microformat" ideas
(assigning "agreed" meanings to class names - not my piece of cake, but the
idea is just wrong, not absurd).

OK but you wouldn't set a class of FOO if you were trying to see what
initial values were.

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. If I tried each of the
possible values of display on a SPAN, in a range of different contexts
(ideally all consisting of different configurations of variously styled
SPANs), and compared the results with not setting display on the SPAN at
all, then I would be able to get a pretty good idea which one the
browser was "doing" for the initial value.

What you can do is to view a document with SPAN elements and
looking at their appearance to see any effects of possible browser style
sheet effects on it, and most probably you won't see any.

You can tell that a span is display: inline very easily. You can also
tell that a span is float: none by putting one in the middle of a
paragraph of text and observing that it doesn't move to one side. You
can tell your span is table-layout: auto by setting it to display:
table, and filling it with a whole subtree of spans set to appropriate
table display types, widths, and with particular content in them, and
so on and so on.

Most importantly, SPAN is uninteresting in this respect. Think about H1.
Looking at a document containing an H1 element, with no author style sheet,
you will see a browser's default in a particular situation (browser
settings, display device, phase of the moon, etc.). The HTML specifications
strongly suggest that you should then see quite noticeable effects. But how
would you see whether the browser correctly implements the _initial_ values
for properties?

By testing them on SPAN not on H1 of course!

H1 is a very bad element to choose if you are trying to test initial
values, because, as you say, you would expect it to pick up quite a few
default styles.

Provided you make the assumption that SPAN gets nothing from the default
stylesheet, which is reasonable, then you can test fairly well both what
values the browser is picking as initial values for each property and
whether it is rendering correctly according to the specifications of
those values.

But don't use H1!

What you see is the effect of applying a browser stylesheet
that overrides any initial values defined in CSS specifications.

The only one I can think of is br:before {
content: "\A"; white-space: pre-line } since it doesn't appear to
quite achieve the HTML specification of BR (that it should behave like
U+2028).

You're wrong. The BR semantics is forced line break, not the use of a
particular control character,

OK, so why does the CSS spec suggest implementing it with U+000A, which,
insofar as control characters have semantics, has the wrong semantics?

I'm not saying this is strictly wrong-- there are interpretations under
which it is OK-- but it seems to me an oddity in the default stylesheet.

You said there were others (I forget your exact words), but we're still
waiting to hear what they are.

In article <slrnheo786.34o.spamspam (AT) bowser (DOT) marioworld>,
Ben C <spamspam (AT) spam (DOT) eggs> wrote:
....

On 2009-10-29, dorayme <doraymeRidThis (AT) optusnet (DOT) com.au> wrote:
[...]
...
A useful fiction to buy out of having to know the details of how
browsers are made and operate: A browser produces an output only with a
virtual master CSS sheet. In this sheet are all the styles down to as
exact a value as possible. This sheet can be overridden of course by
author or user sheets.

Yes, although in this "virtual master CSS sheet", all selectors are just
*. It would look this:

* display { inline }
* line-height { normal }

etc. The initial value is a property only of properties, not of elements.

I'm assuming by "virtual master CSS sheet" you don't mean the same thing
as "browser default stylesheet".

Well, no, not just this, but I did mean to include this latter.
Basically, it is a complicated business always having to think, what is
due to some actual but hidden default style sheet (a la the appendix one
you mentioned) and what to hard wiring and what to hard-wiring-with-some
values set by user preferences. Three different things here, all
contributing to what you get when you use a browser in anger. Two or
three technical levers complicating the understanding.

JK says things about browsers setting too small a line-height. For me,
this usefully means that the fictitious master sheet of many browsers
has body {line-height: 1.2} (or thereabouts) and this is too small for
some popular fonts. 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.

I was imagining a possible useful fiction that would free the practical
web designer uninterested in actual browser wiring to have a simple
model. The idea is a modernish one in that the browser is an engine that
has no internal biases towards any sort of presentation at all. Without
the virtual master CSS sheet, it simply cannot operate. It just sulks
and does nothing like some widowers and widows do sans their partners.
You cannot turn off this master sheet because it is its way into the
world. The browser becomes a useful object in conjunction with a master
CSS sheet.

Under this idea, what are to make of the act of turning styles off?
Well, for me, you can't turn all styles off, it is too absurd a concept.
Remove all styles and you remove all meaning and usefulness. But all is
not lost, it can mean turn off all author styles. It can mean, turn off
many or all the default styles in one of the actual but hidden sheets.
But it can't under my idea mean turn off the master sheet. I was
imagining a super el basic sheet when I ticked the command that you are
not seeing in your FF.

Now, to go into something, in FF, if you can, try:

http://dorayme.netweaver.com.au/anything.html

Open the web developer facilities and go to Edit CSS, stick in a style
on body for line-height. I have Geneva 16 set for my normal sans-serif
and if I set body {line-height: 1.36} I get about the same look as me
not setting any line-height. What do you want to say about where the
line height is being supplied from in the case? I am happy with my rich
fictitious master sheet that is very far from the minimalist:

http://www.w3.org/TR/CSS21/sample.html

Note how grabbing all this and making an explicit set of styles in the
head of anything.html, leaves the show virtually unchanged. Meaning
partly that this example sheet is certainly very congruent with the one
that FF actually operates with, it may even be exactly the same.

I think it's mostly the same, yes.

There is a menu item under Disable Styles that reads Browser Default
Styles.

I can't find that menu!

Tick this and see what happens to the line height. Now it is a
mingy thing! Where is this coming from? It is coming presumably from
browser coding. It looks like 'line-height: 1;' To see this, open a
couple of tabs. In one tick the Browser Default Styles, in the other
simply add under Edit CSS, body {line-height:1;}. Compare by eye.

You should get line-height: normal, which is usually a bit more than 1
(but depends on the font). And I would expect that to be the same as
with browser default styles since there aren't any line-height rules in
the suggested default stylesheet, which I think is very close to what
the main browsers use. But perhaps what you have discovered is that this
is not the case.

I am hard pressed to quite fathom all the conversation between you and
'the boss' <g> but I would not mind putting in my $US25's worth - OK, I
am not cheap, I have pride.

When we are testing what is 'given' by the browser as default, I feel
less confused when I think of this virtual master sheet. One can
*easily* test for what the master styles are. Just override with author
sheet in respect to a property *to see* if there is a change. If not,
you have all you need to really know for the practical website making.

Maybe under different pressures this idea is less than baked. But I go
with it for the moment.

--
dorayme

Ben C wrote:

OK but you wouldn't set a class of FOO if you were trying to see what
initial values were.

Of course I wouldn't, as I wouldn't experiment on it at all. I know what the
defined initial values are, and I know that it is impossible to study their
implementation in browsers by external observations, i.e. without using
browser source code or equivalent.

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 and stupid. It is also off-topic, as your
mistake does not depend on your misunderstanding of HTML but your
misunderstanding about CSS and implementations.

If I tried each of the
possible values of display on a SPAN,

then that would have no significance to the issue. By setting a display
value, you override the initial value and the browser default value (if
any). So the experiment would be pointless in any attempt to find out
whether a browser correctly implements the initial value.

in a range of different contexts
(ideally all consisting of different configurations of variously
styled SPANs), and compared the results with not setting display on
the SPAN at all, then I would be able to get a pretty good idea which
one the browser was "doing" for the initial value.

Nonsense. You can see that the observed browser behavior corresponds to
display: inline, in the absence of any author style sheet. This was never
under dispute. It would thus be pointless to prove it, and your hypothetical
test would not even do anything in that direction. It's irrelevant what
happens when you set display to another value.

The question was whether you can test whether a browser implements the
defined initial values correctly, and the correct answer is that you cannot,
since everything you see has at least the browser default style sheet
applied on top of the effects of initial value settings. That style sheet
need not be documented, and even if it is, why would you trust the
documentation? If you do, you might as well take their word for their having
correctly implemented the initial values.

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

Actually, this depends on the context. If you have
<td><span>foo</span></td>, how are you going to derive, from the observed
presentation, what the disply value for the span element is? But this is
still completely irrelevant to the question, and off-topic here.

H1 is a very bad element to choose if you are trying to test initial
values,

I admit that it manifestly proves that your idea of testing initial values
is misguided, more manifestly than in the uninteresting case of span.

Provided you make the assumption that SPAN gets nothing from the
default stylesheet,

I don't make such assumptions. You seem to be making, but then your "tests"
more or less postulate what they are supposed to prove. In circles you go.

You're wrong. The BR semantics is forced line break, not the use of a
particular control character,

OK, so why does the CSS spec suggest implementing it with U+000A,
which, insofar as control characters have semantics, has the wrong
semantics?

Ask the people who wrote the CSS spec. It was you who claimed that another
style sheet would be the correct one to use. Anyway, in HTML (which is the
topic of this group), a line break is U+000D or U+000A or U+000D U+000A by
definition.

You said there were others (I forget your exact words), but we're
still waiting to hear what they are.

If you wish to discuss CSS specs and hear my comments on them, try raising
your questions in the right group under an adequate Subject line.

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

On 2009-11-01, dorayme <doraymeRidThis (AT) optusnet (DOT) com.au> wrote:

In article <slrnheo786.34o.spamspam (AT) bowser (DOT) marioworld>,
Ben C <spamspam (AT) spam (DOT) eggs> wrote:
...
On 2009-10-29, dorayme <doraymeRidThis (AT) optusnet (DOT) com.au> wrote:
[...]
...
A useful fiction to buy out of having to know the details of how
browsers are made and operate: A browser produces an output only with a
virtual master CSS sheet. In this sheet are all the styles down to as
exact a value as possible. This sheet can be overridden of course by
author or user sheets.

Yes, although in this "virtual master CSS sheet", all selectors are just
*. It would look this:

* display { inline }
* line-height { normal }

etc. The initial value is a property only of properties, not of elements.

I'm assuming by "virtual master CSS sheet" you don't mean the same thing
as "browser default stylesheet".


Well, no, not just this, but I did mean to include this latter.
Basically, it is a complicated business always having to think, what is
due to some actual but hidden default style sheet (a la the appendix one
you mentioned) and what to hard wiring and what to hard-wiring-with-some
values set by user preferences. Three different things here, all
contributing to what you get when you use a browser in anger. Two or
three technical levers complicating the understanding.

JK says things about browsers setting too small a line-height.

He just thinks line-height: normal is too small.

For me, this usefully means that the fictitious master sheet of many
browsers has body {line-height: 1.2} (or thereabouts) and this is too
small for some popular fonts.

line-height isn't normally set in any sheets, so you get line-height:
normal, which is the initial value of line-height.

If you want to think of initial values as coming from a fictitious
sheet, which you can if you like, then that sheet would look something
like this:

* {line-height: normal}
* {display: inline}

etc.

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

I was imagining a possible useful fiction that would free the practical
web designer uninterested in actual browser wiring to have a simple
model. The idea is a modernish one in that the browser is an engine that
has no internal biases towards any sort of presentation at all.

Yes, that's pretty much what a modernish browser is with only a couple
of exceptions.

Without the virtual master CSS sheet, it simply cannot operate. It
just sulks and does nothing like some widowers and widows do sans
their partners. You cannot turn off this master sheet because it is
its way into the world. The browser becomes a useful object in
conjunction with a master CSS sheet.

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

Under this idea, what are to make of the act of turning styles off?
Well, for me, you can't turn all styles off, it is too absurd a concept.

In the CSS terminology, you can't turn off initial values, and it
wouldn't make sense to, so I think you are talking about the same thing.

Remove all styles and you remove all meaning and usefulness. But all
is not lost, it can mean turn off all author styles. It can mean, turn
off many or all the default styles in one of the actual but hidden
sheets. But it can't under my idea mean turn off the master sheet. I
was imagining a super el basic sheet when I ticked the command that
you are not seeing in your FF.

As you say it can't be done. A div can be display: inline without the
default stylesheet. But without an initial value for display, it isn't
display: anything, and the browser would be totally at a loss, like your
sulking widower.

Now, to go into something, in FF, if you can, try:

http://dorayme.netweaver.com.au/anything.html

Open the web developer facilities and go to Edit CSS, stick in a style
on body for line-height.

I didn't have the web developer facilities, but have now installed them,
and also have the Disable Styles button you mentioned.

I have Geneva 16 set for my normal sans-serif
and if I set body {line-height: 1.36} I get about the same look as me
not setting any line-height. What do you want to say about where the
line height is being supplied from in the case?

One may conclude that line-height: normal for Geneva 16 is about 1.36x
the height of that font.

[...]

You should get line-height: normal, which is usually a bit more than 1
(but depends on the font). And I would expect that to be the same as
with browser default styles since there aren't any line-height rules in
the suggested default stylesheet, which I think is very close to what
the main browsers use. But perhaps what you have discovered is that this
is not the case.

I am hard pressed to quite fathom all the conversation between you and
'the boss' <g> but I would not mind putting in my $US25's worth - OK, I
am not cheap, I have pride.

When we are testing what is 'given' by the browser as default, I feel
less confused when I think of this virtual master sheet. One can
*easily* test for what the master styles are. Just override with author
sheet in respect to a property *to see* if there is a change. If not,
you have all you need to really know for the practical website making.

Maybe under different pressures this idea is less than baked. But I go
with it for the moment.

All I am trying to explain is the distinction between the browser
default stylesheet and the initial values of properties.

It may seem like unnecessary entity multiplication, but it's the
terminology the spec uses, and sometimes one wants to understand the
spec.

The default stylesheet given in that Appendix also does not tell you the
whole story unless read in conjunction with the "full property table"
given in one of the other Appendices which lists initial values for each
property. This is because the default stylesheet does not set some value
of every property for every tag. It doesn't set anything at all for
span, for example. So how is the browser supposed to know that span is
display: inline, direction: ltr, and float: none, and so on? Well, you
can find those in the initial values column of the full property table.

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

Ben C wrote:

OK but you wouldn't set a class of FOO if you were trying to see what
initial values were.

Of course I wouldn't, as I wouldn't experiment on it at all. I know
what the defined initial values are, and I know that it is impossible
to study their implementation in browsers by external observations,
i.e. without using browser source code or equivalent.

It it not impossible and I explained in my previous post how to do it.

Software is tested against specifications without looking at the source
code all the time, and that a browser correctly implements initial
values as specified is not particularly difficult to test.

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.

[...]

If I tried each of the
possible values of display on a SPAN,

then that would have no significance to the issue. By setting a display
value, you override the initial value and the browser default value (if
any). So the experiment would be pointless in any attempt to find out
whether a browser correctly implements the initial value.

I recommend you read the whole sentence next time before replying.

in a range of different contexts
(ideally all consisting of different configurations of variously
styled SPANs), and compared the results with not setting display on
the SPAN at all, then I would be able to get a pretty good idea which
one the browser was "doing" for the initial value.

Nonsense. You can see that the observed browser behavior corresponds to
display: inline, in the absence of any author style sheet. This was never
under dispute. It would thus be pointless to prove it, and your hypothetical
test would not even do anything in that direction. It's irrelevant what
happens when you set display to another value.

The point you are missing is that using the procedure described you can
test which value of a property the browser applies as the initial value,
even if its implementation of the effect of that value is incorrect.

Yes, it would be an unusual test to perform, but you are the one with
the obsession that initial values have no epiphenomena and are
impossible to detect without looking at the source code.

The question was whether you can test whether a browser implements the
defined initial values correctly, and the correct answer is that you cannot,
since everything you see has at least the browser default style sheet
applied on top of the effects of initial value settings.

For a span this is very unlikely to be the case.

That style sheet need not be documented, and even if it is, why would
you trust the documentation? If you do, you might as well take their
word for their having correctly implemented the initial values.

All the style sheet does is get in the way of someone trying to design
stupid tests of initial values (like using H1).

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!

If you have
td><span>foo</span></td>, how are you going to derive, from the
observed presentation, what the disply value for the span element is?

When I said "very easily" I didn't mean, "so easily that you can do it
even if you design a deliberately stupid test".

For that I might use an expression like, "as easy as falling off a log".

[...]

OK, so why does the CSS spec suggest implementing it with U+000A,
which, insofar as control characters have semantics, has the wrong
semantics?

Ask the people who wrote the CSS spec. It was you who claimed that another
style sheet would be the correct one to use.

Where did I claim that?

On Nov 1, 4:52*am, dorayme <doraymeRidT... (AT) optusnet (DOT) com.au> wrote:

In article <slrnheo786.34o.spams... (AT) bowser (DOT) marioworld>,
*Ben C <spams... (AT) spam (DOT) eggs> wrote:
A sufficiently good mental model for everyone except Korpela is
that the browser hard-wires somewhere the initial values for each > > property and then loads its own default stylesheet from somewhere > > just like any other stylesheet.
JK says things about browsers setting too small a line-height.

sorry - I missed that.