Bullet Spacing

Jim Dabell <jim-usenet (AT) jimdabell (DOT) com> wrote:

What about the list-style-position property?

URL:http://www.w3.org/TR/REC-CSS2/genera...style-position

The list-style-position is used to position the marker box (that
contains the bullet) inside or ouside of the principal box.

You *should* be able to change the position of the marker box relatively
to the list box with the marker-offset property.
See <http://www.w3.org/TR/REC-CSS2/generate.html#markers>

Unfortunatly, marker-offset is not widely supported by the current
browsers.

Ok, perhaps I should used a nicer tone. (I did include the warning
rant "tag," for what that was worth. Not much, I suppose.) It wasn't
intended as a swipe against you. But, judging from your message, I
guess the stylesheet is your work (mostly? entirely?). So forgive the
tone of my previous message.

Eric A. Meyer wrote:

http://devedge.netscape.com/viewsource/2002/list-indent

Oh, and you forgot to say how you would have better solved the same
problems we faced.

I'll respond within the message where it seem appropriate.

rant> That devedge site really has some design problems. The
font size is tiny on my monitor. But I'm sure being on the edge
of development means they know better than I the right size for
my monitor.

The font sizing was dictated by... well, let's just say
non-engineering types. Yes, that's right, folks, even in WWW
design the visual design choices are not always in the hands of the
person doing the CSS, who must make the best of the situation in
which he finds himself.

If I read you correctly, then we agree that setting a small font-size
was not a good choice. Not to beat a dead horse, but I didn't intend
this barb to be aimed at the person who authored the site, but at
whomever decided that small font-size had to be used. Naturally, I
would have specified body {font-size: 100%}

Still, being insolent, I increased the font-size, and voila! a
horizontal scroll bar, and the search box and links are partially
off the screen.

Well, yes-- the design is set up to hang together no matter how the
font size is changed. It's a bit better than most designs, I'd
like to think, which fall apart when the text size is changed by
the user.

I prefer not to have to scroll horizontally. Scrolling horizontally
is a pita, no matter how much it "hang[s] together."

I tried to find the right stylesheet to see what you did, and I may
have found the relevant stuff. #main has width of 100%, so I'm not
sure what specifically causes the horizontal scrolling. Perhaps the
divs which are inside of main, whose widths are specified in em units?
I suppose, give the center a flexible width. Or don't specify one at
all.

Sorry I cannot be more specific. All I know is that with my Mozilla
browswer at full screen (on my admittedly small laptop monitor) I get
a horizontal scrollbar.

Then there's the style switcher. Might be nice, but I have to
enable cookies. Ironic, since the homepage encourages visitors
to get Netscape 7.1, which can load alternative stylesheets
without the aid of cookies or javascript.

...but which won't remember that alternative choice once you leave
the page you're viewing.

A problem to be sure.

Until user agents manage to remember alternate-style selections
from one page to another, cookie-based (or URL-encoded) theme
systems are the best we can do.

Why not offer both? Let me view an alternative stylesheet. If I
decide I like it enough, I can enable cookies to keep that one
selected during my visit to the site. This is especially true since
the Netscape browser that you plug on the home page has a menu item to
allow loading alt stylesheets. Let users of that browser see how it
works, even if it doesn't work as well as it might.

BTW, the page
< http://devedge.netscape.com/lib/themes/ >
contains erroneous information re: switching stylesheets via the menu.

So, I reluctantly accepted cookies. Guess what? The switcher
still did not work. I had to select a new style, then reload the
page in the browser. Slick. Real slick.

I haven't seen that problem until you mentioned it, which makes me
think that something's gone awry with our server-side script.
I'll see if I can figure out what's causing it and get it fixed

I tried again today. Still not working. I have to do a ctrl-shift-r
reload to get the new stylesheet loaded.

--
Brian
follow the directions in my address to email me

In article <zdYQa.59376$sY2.25498 (AT) rwcrnsc51 (DOT) ops.asp.att.net>,
Brian <brian (AT) wfcr (DOT) org.invalid-remove-this-part> wrote:

But, judging from your message, I guess the stylesheet is your work
(mostly? entirely?). So forgive the tone of my previous message.

Not to worry-- I didn't take offense, but also did think the
questions raised deserved responses. My tone may have matched yours, so
my apologies if I was sounded more harsh than necessary.

The font sizing was dictated by... well, let's just say
non-engineering types.

If I read you correctly, then we agree that setting a small font-size
was not a good choice.

I would have preferred another choice. In fact, I fought for a
different choice throughout most of the redesign and overhaul process,
which was about three monts long. In the end, I was overruled. C'est
la geurre.

I prefer not to have to scroll horizontally. Scrolling horizontally
is a pita, no matter how much it "hang[s] together."

I tried to find the right stylesheet to see what you did, and I may
have found the relevant stuff. #main has width of 100%, so I'm not
sure what specifically causes the horizontal scrolling. Perhaps the
divs which are inside of main, whose widths are specified in em units?
I suppose, give the center a flexible width. Or don't specify one at
all.

There's a 'min-width' on the 'body' element that prevents the design
from compressing too far. (Where "too far" was a measure we arrived at
over time.) The design does flex, it just has limits.

Until user agents manage to remember alternate-style selections
from one page to another, cookie-based (or URL-encoded) theme
systems are the best we can do.

Why not offer both? Let me view an alternative stylesheet. If I
decide I like it enough, I can enable cookies to keep that one
selected during my visit to the site. This is especially true since
the Netscape browser that you plug on the home page has a menu item to
allow loading alt stylesheets. Let users of that browser see how it
works, even if it doesn't work as well as it might.

You can already do that. In Netscape, you can pick any of the
alternate stylesheets through the browser UI, like you say. Then, if
you find one you like, you can use the "Customize" menu to make that
choice permanent (in theory, anyway).

I haven't seen that problem until you mentioned it, which makes me
think that something's gone awry with our server-side script.
I'll see if I can figure out what's causing it and get it fixed

I tried again today. Still not working. I have to do a ctrl-shift-r
reload to get the new stylesheet loaded.

It turns out it's due to a bug where if you have more than a certain
number of cookies, say 100 or so, the CGI doesn't see the cookie it's
seeking and the script silently fails. Once I deleted enough cookies,
the script started working again. Given the number of ad-related
cookies that had crept in over time, this turned out to be a good thing
for me personally, but obviously it's not an optimal behavior for a
public service.
I'd like to say that these problems will be fixed, but after the
events of yesterday, I seriously doubt there will ever be another update
to DevEdge. I don't even know how long the server will remain running,
for that matter. If there's anything there you particularly like, now
would be a good time to download it to your hard drive for future
reference. (Plus that way you'll get structured markup that you can
style however you like.)

--
Eric A. Meyer
http://www.meyerweb.com/eric/

In article <1fy6zco.1l0u771ttotyN%ned-ml (AT) idsland (DOT) com>, ned-
ml (AT) idsland (DOT) com says...

Jacqui or (maybe) Pete <porjes (AT) spamcop (DOT) net> wrote:
However, I just had a play with an image bullet, and it seems that IE6
and Opera allocate a certain width for the bullet (about 25px?). So,
with a carefully crafted (ahem) image, we can get them to play ball:

http://porjes.com/tightbullet.html

Moz adds some padding to the bullet, so no joy there.

KHTML (safari, etc) doens't work either.

on the other hand, I found a hack that works in Moz and KHTML, but not
in IE : set a negative text-indent on the <li>, so the text is shifted
to the left, closer to the bullet.

A combination of the two approaches seems to work OK in Mozilla 1.5b,

Opera 7.2b, and IE6:

http://porjes.com/tightbullet2.html

I put in a javascript preload which seems to help Mozilla a bit.

Eric A. Meyer <eric (AT) meyerweb (DOT) com> wrote:

I'd like to say that these problems will be fixed, but after the
events of yesterday, I seriously doubt there will ever be another update
to DevEdge. I don't even know how long the server will remain running,
for that matter. If there's anything there you particularly like, now
would be a good time to download it to your hard drive for future
reference. (Plus that way you'll get structured markup that you can
style however you like.)

Thanks for the tip
wget -m worked fine for me, the site is juste over 40 megs. Many links
are based on the site root, so you can either do some wget magic to make
them relative, or just create a local virtual host in apache.

I would just like to say thank you for all your work, done on devedge or
elsewhere (I've been working with your 'Programmer's Reference' book in
my daybag for the last year).

All the best.