Re: Line spacing not working
- From: Ben C <spamspam@xxxxxxxxx>
- Date: Sat, 31 Oct 2009 18:05:59 -0500
On 2009-10-31, Jukka K. Korpela <jkorpela@xxxxxxxxx> 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.
.
- Follow-Ups:
- Re: Line spacing not working
- From: Jukka K. Korpela
- Re: Line spacing not working
- Prev by Date: Write it up online
- Next by Date: Lunatic posts
- Previous by thread: Write it up online
- Next by thread: Re: Line spacing not working
- Index(es):
Relevant Pages
|
