By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
438,625 Members | 2,250 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 438,625 IT Pros & Developers. It's quick & easy.

Faking up a run-in header

P: n/a

Posting here always feels a bit like poking one's head into
the mouth of a lion, but here goes:

I have someone who wants some headings (h3) to run-in to the
following paragraph. Obviously, the "correct" thing to do is
to use display: run-in for the h3s and say that it'll work
in opera and konqueror, be readable in the other browsers
and look right when the implementations catch up (nine years
since the omission was reported for mozilla, I believe, so
there's an implication of non-breath-holding in this).

The other thing to do is to add some non-semantic mark-up
and fake the effect that way. I've made a couple of
attempts; neither is entirely satisfactory:

http://www.cl.cam.ac.uk/~jf15/StyleT...ke-run-in.html

(which begins with real run-in h3s) The first method I tried
is to style the h3 and following paragraph as inline. This
sort of works with problems mentioned at the url above, the
most irritating of which is the requirement for something to
prevent running in if the text under the header is only one
paragraph (using an empty paragraph works in everything I've
tried except IE7, which doesn't seem to collapse it).

The second is to use floats, but I can't see how to get the
baselines to line up correctly.

Have I missed something obvious? Is there a better way of
preventing run-in with the first method? Is there a better
method all together?

--
J贸n Fairbairn Jo***********@cl.cam.ac.uk
Apr 18 '07 #1
Share this Question
Share on Google+
5 Replies


P: n/a
J贸n Fairbairn wrote:
>
The second is to use floats, but I can't see how to get the
baselines to line up correctly.
Try offsetting the header with some negative margins and/or relative
positioning. How much depends on the font-size, but if you set values in
ems, it should adapt reasonably well.

--
Berg
Apr 18 '07 #2

P: n/a
Bergamot <be******@visi.comwrites:
J贸n Fairbairn wrote:

The second is to use floats, but I can't see how to get the
baselines to line up correctly.

Try offsetting the header with some negative margins and/or relative
positioning. How much depends on the font-size, but if you set values in
ems, it should adapt reasonably well.
Thanks, but. I've already tried the first and thought about
the second, but what I'm missing is how to work out where
the baseline will be in the floated block, and hence by how
much to offset it. With the current (zero) margins, Firefox
and Opera display the floated text too low, but Konqueror
and IE6 put it in the right place. I don't know which of
them is doing the right thing...

--
J贸n Fairbairn Jo***********@cl.cam.ac.uk

Apr 18 '07 #3

P: n/a
On 2007-04-18, J髇 Fairbairn <jo***********@cl.cam.ac.ukwrote:
Bergamot <be******@visi.comwrites:
>J髇 Fairbairn wrote:
>
The second is to use floats, but I can't see how to get the
baselines to line up correctly.

Try offsetting the header with some negative margins and/or relative
positioning. How much depends on the font-size, but if you set values in
ems, it should adapt reasonably well.

Thanks, but. I've already tried the first and thought about
the second, but what I'm missing is how to work out where
the baseline will be in the floated block, and hence by how
much to offset it. With the current (zero) margins, Firefox
and Opera display the floated text too low, but Konqueror
and IE6 put it in the right place. I don't know which of
them is doing the right thing...
The baseline of the text in the float should be lower than that of the
adjoining text if the font size for h3 is larger, which it usually is.

Second-guessing the offset from the top of a linebox to the baseline is
not feasible I don't think. It depends on the font, its various metrics
and on how the browser interprets them. You don't get fine-grained
control over that stuff with CSS.

display: inline is really the only way to do this (and use a span for
the first-letter etc. the way you are).
Apr 18 '07 #4

P: n/a
Ben C <sp******@spam.eggswrites:
On 2007-04-18, J髇 Fairbairn <jo***********@cl.cam.ac.ukwrote:
Bergamot <be******@visi.comwrites:
J髇 Fairbairn wrote:

The second is to use floats, but I can't see how to get the
baselines to line up correctly.

The baseline of the text in the float should be lower than that of the
adjoining text if the font size for h3 is larger, which it usually is.
I believe that I set the font-size to be the same as the
paragraph text. It's possible that font-weight might make a
difference, though it doesn't seem to. In fact, what seems
to happen (in firefox) is that the position of the float
beats with the pixel alignment at a slightly different rate
from the lines in the paragraphs, so some of the floated
headings line up and some are 1px lower. Strange.
Second-guessing the offset from the top of a linebox to the baseline is
not feasible I don't think. It depends on the font, its various metrics
and on how the browser interprets them. You don't get fine-grained
control over that stuff with CSS.
Seems like a bit of a deficiency to me, though I don't mean
control of font and metrics); the baseline of a line of text
is a fundamental typographic property, yet block boxes don't
have them.
display: inline is really the only way to do this (and use a span for
the first-letter etc. the way you are).
What would be the correct way of introducing the break? I
don't think I fully understand the way margins are supposed
to collapse (and possibly, neither does IE7), so while most
browsers produce a reasonable spacing when an empty
paragraph is used, IE7 introduces extra space. (I think
that's what happens; I don't normally have windows running)

* * *

One last bit of unpleasantness: neither using display:
inline no floats produces the correct effect if display:
run-in is also set. With the inline version, the markup for
the following paragraph messes it up, and with float, the
float seems to take precedence (in Opera at least), though
I'm not sure it should.

Thanks for your help,

--
J贸n Fairbairn Jo***********@cl.cam.ac.uk
Apr 20 '07 #5

P: n/a
On 2007-04-20, J髇 Fairbairn <jo***********@cl.cam.ac.ukwrote:
Ben C <sp******@spam.eggswrites:
>On 2007-04-18, J?n Fairbairn <jo***********@cl.cam.ac.ukwrote:
Bergamot <be******@visi.comwrites:

J?n Fairbairn wrote:

The second is to use floats, but I can't see how to get the
baselines to line up correctly.

The baseline of the text in the float should be lower than that of the
adjoining text if the font size for h3 is larger, which it usually is.

I believe that I set the font-size to be the same as the
paragraph text.
Ah, I missed that detail.
It's possible that font-weight might make a
difference, though it doesn't seem to. In fact, what seems
to happen (in firefox) is that the position of the float
beats with the pixel alignment at a slightly different rate
from the lines in the paragraphs, so some of the floated
headings line up and some are 1px lower. Strange.
That is a bit strange.
>Second-guessing the offset from the top of a linebox to the baseline is
not feasible I don't think. It depends on the font, its various metrics
and on how the browser interprets them. You don't get fine-grained
control over that stuff with CSS.

Seems like a bit of a deficiency to me, though I don't mean
control of font and metrics); the baseline of a line of text
is a fundamental typographic property, yet block boxes don't
have them.
The baseline of a block box would presumably be the baseline of the
first linebox in it (which might be nested in several more block boxes).
That's how the baseline for a table cell is determined.

It's not clear how you'd use the baseline on a block box, but it makes
sense on a table cell or inline-block because they can line up with
other things to their left and right.

In Opera you vertical-align: baseline on an inline-block works (and
could be used for your headings). Konqueror on the other hand considers
inline blocks not to have a baseline and so aligns the inline-block's
bottom margin edge with the parent baseline instead. FF doesn't support
inline-blocks at all.

It comes down to whether an inline-block is "inline-level" or not. I
think it is, and therefore that Opera is right.
>display: inline is really the only way to do this (and use a span for
the first-letter etc. the way you are).

What would be the correct way of introducing the break? I
don't think I fully understand the way margins are supposed
to collapse (and possibly, neither does IE7), so while most
browsers produce a reasonable spacing when an empty
paragraph is used, IE7 introduces extra space.
The top and bottom margins of an empty <pshould collapse with each
other: they count as "adjoining" since there is nothing in between. So

div { margin: 20px 0; }

<div>Hello</div>
<div></div>
<div>world</div>

should display just the same as

<div>Hello</div>
<div>world</div>

I use <divin this example rather than <pbecause <pintroduces an
extra confusion here. The HTML 4.0 spec says:

"We discourage authors from using empty P elements. User agents
should ignore empty P elements."

even though <p></pis technically valid [assuming (%inline;)* means "0
or more inlines" which I should think it does].

It doesn't normally make a difference, but if I write:

<p>Hello</p>
<p style="margin: 600px 0"></p>
<p>world</p>

Should I get a 600px gap between the first and third paragraphs or not?
Not if I ignore empty P elements.
(I think that's what happens; I don't normally have windows running)
I don't know what IE does either.
* * *

One last bit of unpleasantness: neither using display:
inline no floats produces the correct effect if display:
run-in is also set. With the inline version, the markup for
the following paragraph messes it up, and with float, the
float seems to take precedence (in Opera at least), though
I'm not sure it should.
It should. If you set float to anything other than "none" you get
display: block regardless of what you set for display. This is in
section 9.7 of the CSS 2.1 spec.
Apr 20 '07 #6

This discussion thread is closed

Replies have been disabled for this discussion.