text span 2 characters (fixed font width)

[Jukka K. Korpela]

123Jim wrote:

Quite right, like below (although it relies on the default in the
browser for text size ):
<div
style="display: inline; float: left; position: relative; font-family:
monospace;">

You're just playing with a CSS imitation of <pre>.

The real problem still remains unknown.

1<span style="padding-left: 4px; padding-right:
4px;">&Psi;</span>456789<span

And what happens when font size is, say, 100px?

 

[Jukka K. Korpela]

Are you trying to be funny?

Don't know which definition you're looking at.

What would you look at if you wanted to know how an HTML element is defined?

I would have thought
the essential feature was leaving the whitespace in.

That's one part. Being preformatted means more. Check out the HTML 4.01
Recommendation. It's sloppy as usual, but the intent is clear:

"The DTD fragment above indicates which elements may not appear within a PRE
declaration. This is the same as in HTML 3.2, and is intended to preserve
constant line spacing and column alignment for text rendered in a fixed
pitch font. Authors are discouraged from altering this behavior through
style sheets."

As usual, the HTML 2.0 specification is a great improvement over its
successors in clarity:

"The PRE element represents a character cell block of text and is suitable
for text that has been formatted for a monospaced font."

 

[123Jim]

That's odd. I looked at it in FF3.63 and Safari 4.0.5. and Chrome, but
not the newest Chrome. The sigma is in the second column.

This is what I see in Google Chrome:

<http://home.kreme.com/sigma.png>

Strange .. looks like the same font I get on XP for: font-family: monospace;
in my three browsers: IE, Firefox and Chrome.
.... but in each Neredbojias's code works fine.

I don't know if there is a connection to your image example above .. but my
system does not have Monaco font .. so I figured that is why the code you
posted earlier in the thread did not do the trick .. I don't know what font
I was getting .. but it didn't look monospace family.
cheers.

 

[123Jim]

You're just playing with a CSS imitation of <pre>.

The real problem still remains unknown.


And what happens when font size is, say, 100px?

something awful? .. yes, the alignment starts to break down .. but what sort
of crazy person want to zoom in that much really? .. reasons can't be
guessed .. but at that size the poor user is only going to get about 30
characters on the screen .. that's in IE only , because Firefox can't be
zoomed that much. .. which is a bit of a surprise I have to say.

A better solution was offered by Neredbojias in this thread with his nested
spans and inscrutable styles, ... and also anyone who said table with
colspan="2" for the cells containing the greek characters.
cheers

 

[dorayme]

It is not both, it is a block.

A block that is laid out inline, the same way an <img> would, instead of
forcing sibling boxes to pile up and down to it.

Good analogy. The similarity with images is that, like images (in
their default display), inline-blocks are inline but what is
inside them cannot be wrapped in the normal flow of the inline
boxes' containing block and yet what goes after them is normal
flow wrappable text again. Take as an example:

<div class="containingblock">
Text directly in div of class "container".
<div style="display: inline-block;>
Text directly in inline block.
</div>
More text directly in div of class "containingblock"
</div>

This will *look* in most browsing situations exactly as it would
if the inline div was not there at all. As in:

<div class="containingblock">
Text directly in div of class "container". Text directly in
inline block. More text directly in div of class "containingblock"
</div>

But the differences between the latter and the former are
significant and just with text alone, you can see this by simply
enlarging the text size or narrowing the browser window; the
inline stuff directly in "containingblock" will all wrap
perfectly but the stuff *directly inside* the inline block will
not unless it needs to because it cannot fit into its own width.

And you can verify this by simply giving this inline block a
small width forcing wrap of its own internal text. What happens
is that the inline block grows tall (like a tree from bottom up
and unlike a float which behaves more like a hanging monkey...)
to cope with its content. Yes, it becomes like a taller inline
image - a sort of intelligent image that can hold real HTML
wrappable text.

It is this intelligence, which includes shrink to fit qualities,
combined with that it grows from the bottom up with being inline
that makes it so attractive for laying out thumbnails. You don't
get the snagging that occurs with floats when there are all
different sizes and the thumbs *sit* nicely and intuitively on
lines.

 

[Jukka K. Korpela]

something awful? .. yes, the alignment starts to break down .. but
what sort of crazy person want to zoom in that much really? ..
reasons can't be guessed ..

Try again. Ever heard of eyesight problems? Actually, about 50 % of all
people have eyesight that is not as good as the average, which in turn is
lower than the eyesight of a typical young and anxious website deeziner.
Admittedly only a few million people would need a font size like 100px, but
of course the point I was making is that the trickery discussed relies on a
particular font size, or on the font size being within a narrow range. The
more the real size deviates from the assumption, the worse it gets

but at that size the poor user is only
going to get about 30 characters on the screen ..

How do you expect to know the size of the screen? For all that you can know,
the screen could be a movie screen. Well-designed web pages adapt to
rendering conditions ranging from a pocket-size device to a movie screen,
and more. All authors start at this flexibility, and then many of them work
hard to make their pages less and less adaptible, mostly for no good reason.

A better solution was offered by Neredbojias in this thread with his
nested spans and inscrutable styles, ... and also anyone who said
table with colspan="2" for the cells containing the greek characters.

Nobody described the real problem yet. People are just working on some
apparently wrong solution (using <pre> in a manner that cannot work) to an
unspecified problem.

So what is the real problem and its context?

 

[Neredbojias]

That's odd. I looked at it in FF3.63 and Safari 4.0.5. and Chrome,
but not the newest Chrome. The sigma is in the second column.

This is what I see in Google Chrome:

<http://home.kreme.com/sigma.png>

As in the first latest reply, I don't have Monaco, either, but I tried
a few different monospace fonts and they did center. So... I have no
idea what the story is.

 

[Neredbojias]

In message <[email protected]>


Interesting.

<http://home.kreme.com/test4.html>
<http://home.kreme.com/test4.png>

What font are you using for monospace?

Lewie, I'm afraid you're going to feel an awful lot like the hound dog
that led his master to the skunk nest.

It's "text-align" not "text- align".

 

[Neredbojias]

Ahahaha, oh man, that's funny. Must have been a space introduced by
the line wrapping in your post and it didn't show up as a HTML error,
of course.

Heh. Mystery solved.

Still, I have to say I'd prefer doing this without styling <pre> but
that's just personal preference I think.

I believe Jukka Korpela posted in this thread intimating that <pre> was
misapplied so you could have something there. Anyway, the OP seemed to
recoil at the "complexity" of the method so it was probably just
another wasted effort in the grand css of life, the universe, and
everything.