We're trying use CSS (instead of tables) to build bullet lists where, when text wraps, it lines up with the text of the line above, instead of the bullet. we don't like <ul> lists because of the indents and lack of control over the size of the bullet. This url above has several of my attempts: http://blues/users/clarke68/publish/phoenix/list.html Three solutions, three different problems. First (top) solution: bullet list in an <href>. The bullet character (&#149;) and the &nbsp; after are spanned with class="nou", where the only property is text-decoration: none. So, the bullet and the space after it should not be underlined. Nscp4 and IE 5 work perfectly, nscp6 does not. Oddly, nscp6 DOES support {text-decoration: blink} in the same situation. Second (middle) solution: The style is assigned to the <a> tag, the bullet is not part of the span. Normally, this would produce a line break between the bullet and the text, but the line break is adjusted for using {position: relative]. Works on all platforms, but produces too much space between multiple items in a bullet list. Also, doesn't work if the list is next to an <align=left>ed image. 3rd (bottom) solution: Like solution 2, all text is {margin-left}, but a {text-indent} with a negative indent moves the first line (with the bullet character). Works fine on all platforms until you add an <a> to the text, then it breaks in nscp 6.1 only. We're trying to roll out a redesign of netscape.com here, and this issue is seriously holding up production because we use a lot of bullet lists, and we're trying to get rid of as many nested tables as possible to improve performance. Please give me a call as soon as you can - x. 4424. Clarke

clarke68@netscape.com, could you attach the HTML to this bug using http://bugzilla.mozilla.org/createattachment.cgi?id=87724 ? Not everyone is inside Netscape's firewall. Based on your descriptions, your "top" solution is invalid. See bug 10458, bug 11377, bug 27245, etc. Basically, you can't "remove" an existing text decoration but only add new ones. That's why blink works. Since I can't quite figure out what the effect you desire is, I can't really tell you what you should be doing... some things I'd suggest based on the info you _have_ presented and some questions: 1) You may want to look into placing the bullet in a :before pseudo-element for the item 2) What sort of issues do you run into with the bullet in a <ul> list that you don't have with &#149; ? 3) would using a ul, controlling the indentation via css, and using list-style-image for the bulet work for you? Looking forward to working with you to get this resolved ASAP.

Ah, I see what he's talking about; I threw together a testcase to see what's going on since I'm one of those people without access to Netscape internal servers. Attaching testcase which illustrates the 3rd scenario, which I think is the most reasonable and feasible of the three. I've used this trick before but hadn't noticed this problem.

Something else intersting I just noticed-- changing the text size to anything EXCEPT 100% (Ctrl- / Ctrl+) displays correctly. (Win98 b.2001062204)

bzbarsky wrote: << Basically, you can't "remove" an existing text decoration but only add new ones. That's why blink works. >> Well, okay... I don't like it, but if that's how it is, that's how it is. It seems to me that if you can turn on underline (text-decoration: underline) then you should be able to turn it off also. << ... some things I'd suggest based on the info you _have_ presented and some questions: 1) You may want to look into placing the bullet in a :before pseudo-element for the item >> I'll give it a try, but I've had bad luck so far with pseudo classes on all the nscp browsers. << 2) What sort of issues do you run into with the bullet in a <ul> list that you don't have with &#149;? >> &#149; only inserts a character. It includes no formatting and the size can be controlled with CSS. <UL> creates an indent and causes line breaks. << 3) would using a ul, controlling the indentation via css, and using list-style-image for the bulet work for you? >> We tried that. It works across all platforms, but the things I didn't like were a.) not being able to control the size of the bullet b.) the only way to get rid of the line break is to not close the <ul>, which means using invalid html c.) We're trying to improve performance as much as possible, so I'd rather not create another server call for something I can produce in ascii d.) IE behaves differently, and this solution requires another stylesheet (margin-left: 17px in IE, -27px in nscp). So far we've been able to do everything with two CSS docs (one for 4.x generation browsers, and one for 5.x and 6.x), and I'd rather not add a third if I can help it.

any reason why we can't confirm this ?

Jason, your workaround rocks! We're implementing as we speak. I'll post if we hit any snags in QA.

This bug should be confirmed; I don't have permissions to do so.

Confirming. Is this a style system bug though? Or evangelism? ccing jason and bclary. A comment: > d.) IE behaves differently, and this solution requires another stylesheet > (margin-left: 17px in IE, -27px in nscp). That's because IE and NS implement indentation for list items differently. IE uses a margin on the <li> element itself. Thus resetting that margin gives you what you want. NS uses padding on the <ul> element. So to get IE behavior out of NS, you would want to set padding-left on the <ul> to 0 (which is the default for IE) and then just set the <li> margin to the same value for both browsers.

bz: is there something in the standard that is the cause of the difference in the way IE and Mozilla implement margins/padding on list items or is something that could be adjusted to increase cross browser compatibility? clarke: would setting display: inline on your UL help any?

The way we're doing it behaves better if a background is set on the <ul>. See bug 2038 and comments in bug 27851

It's hard to say exactly what the bug is here-- several issues have been discussed. We may need to break them out into separate bugs, or change the description of this one. The most relevant issue I see here (which is definitely a valid bug, I'd guess style system), is the behavior where the first inline element after &#149; jumps to the far left of the text-indent, overlapping the &#149;. See the behavior in my and Clarke's attachments. I don't think Evangelism applies here because whom would we evangelize to? (Besides browser makers who don't follow standards.... ahem.) I believe that Mozilla's interpretation of <ul> margin, padding, etc. is correct; Clarke's issue with it is simply that behavior is far too inconsistent across different browsers for it to be of use in his particular case. I don't think that part is actually a bug.

> the behavior where the first inline element after &#149; jumps > to the far left of the text-indent, overlapping the &#149; We get the same behavior with <img> tags instead of &#149; as well (at least that's filed somewhere). So I would check for dups before filing this.

> We get the same behavior with <img> tags instead of &#149; as well That other bug is bug 17644. But can we be sure that it's actually the same issue with &#149; and images? Is &#149; actually treated as an image for some reason? We probably need to get someone CC'd who could answer that question before we mark this as a dupe of 17644. The visual result may be the same but the source of the 2 could be different.

Changed summary, reassigned and marked dependency on bug 17644 for the Layout folks to investigate whether it really is a dup.

I share Jason's confusion in comment 16 as to exactly what this bug is about, so I'm not sure if it's fixed, but certainly some of the testcases look OK now after my patch in bug 17644.

OK, this bug is totally unclear, all the testcases now behave correctly as far as I can tell. Marking worksforme; please reopen with a testcase or clear explanation of expected behavior in the existing testcases if this is still a problem.