87724 - [INLINE-H] negative text-indent paragraphs starting with bullets

Status: RESOLVED WORKSFORME

(Core :: Layout, defect, P3)

Description

[clarke68]

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

Comment 1

[Boris Zbarsky [:bzbarsky]]

[e-mail], 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.

Comment 2

[Jason Johnston]

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.

Comment 3

[Jason Johnston]

Attachment: Testcase for 3rd scenario described above

Comment 4

[Jason Johnston]

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

Comment 5

[clarke68]

Attachment: html file

Comment 6

[clarke68]

Attachment: linked css file

Comment 7

[clarke68]

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.

Comment 8

[Jason Johnston]

Attachment: Clark68's 2 attachments combined into one document for ease of viewing

Comment 9

[Jason Johnston]

Attachment: More examples of behavior -- **clarke68 please see temporary workaround in attachment.

Comment 10

[Bob Clary [:bc] (inactive)]

any reason why we can't confirm this ?

Comment 11

[clarke68]

Jason,

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

Comment 12

[Jason Johnston]

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

Comment 13

[Boris Zbarsky [:bzbarsky]]

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.

Comment 14

[Bob Clary [:bc] (inactive)]

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?

Comment 15

[Boris Zbarsky [:bzbarsky]]

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

Comment 16

[Jason Johnston]

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 • jumps
to the far left of the text-indent, overlapping the •.  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.

Comment 17

[Boris Zbarsky [:bzbarsky]]

> the behavior where the first inline element after • jumps
> to the far left of the text-indent, overlapping the •

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.

Comment 18

[Jason Johnston]

> 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.

Comment 19

[basic]

Attachment: testcase showing different font sizes, margins and text indents

Comment 20

[Pierre Saslawsky]

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

Comment 21

[Simon Montagu :smontagu]

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.

Comment 22

[Boris Zbarsky [:bzbarsky]]

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.