Karl Ove Hufthammer Reporter
	Description • 25 years ago

The marker value on the display property isn't supported.

In the document at <URL:http://home.sol.no/~huftis/mozilla/marker.html>, the
list item marker should be a single en dash with no square.

	kipp
	Comment 1 • 25 years ago

That's a css2 feature that we won't be doing until later, so I'm latering the
bug.

	Chris Petersen
	Comment 2 • 25 years ago

Based on kipp's comments, marking as verified later.

	Karl Ove Hufthammer Reporter
	Comment 3 • 25 years ago

Just reminding you of this.

This bug actually *is* a bit important. If you use a standard-complient HTML
browser to view <URL:http://home.sol.no/~huftis/mozilla/marker.html>, it will
work OK. If you use a browser which supports CSS 1, it will work OK. If you use
a browser which supports CSS 2, it will work OK.

Now, the page breaks (doesn't work properly) in Mozilla. If the 'content'
property is supported then 'display: marker' should be supported too (if not,
it would be like supporting 'color', but not 'background-color'!).

	Karl Ove Hufthammer Reporter
	Comment 4 • 25 years ago

Changing severity based on my own comment above.

	Karl Ove Hufthammer Reporter
	Comment 5 • 25 years ago

Reopening ...

I really *do* think it's important that this get fixed before the Mozilla 5.0
release. If you disagree (why?), mark it as later again.

	Hixie (not reading bugmail)
	Comment 6 • 25 years ago

Migrating from {css2} to css2 keyword. The {css1}, {css2}, {css3} and {css-moz}
radars should now be considered deprecated in favour of keywords.
I am *really* sorry about the spam...

	buster
	Comment 7 • 25 years ago

mozilla's first release will not be a full CSS-2 compliant browser. we will 
support all of CSS-1, and most of CSS-2, but some things won't be supported and 
marker might be one of them.  this doesn't mean we don't think it's important, 
it's just a matter of prioritization vs. resources.

	Karl Ove Hufthammer Reporter
	Comment 8 • 25 years ago

I understand this, and it's OK that you won't support CSS 2 (fully). What's not 
OK is *buggy* support that will cause *valid* pages to *not* work in Mozilla, 
but work in Lynx, Opera 3.6 and CSS 2 browsers.

E.g., supporting the CSS 2 cursor property will no cause any problems. 
Supporting the content property, but *not* supporting 'display: marker', *will* 
cause problems.

One solution is to not support 'content' on elements which have 'display: 
marker' set. It's not a _good_ solution, but it's at least better than what you 
have ...

And BTW, the web page mentionen earlier 
<URL:http://home.sol.no/~huftis/mozilla/marker.html> is available again.

	Terry Weissman
	Comment 9 • 25 years ago

Cleared the resolution.  (Bugzilla no longer supports the idea that an open bug
can have any kind of resolution set.)

	buster
	Comment 11 • 25 years ago

mine! mine mine mine!  all mine!  whoo-hoo!

	Pierre Saslawsky
	Comment 12 • 25 years ago

Display:marker/run-in/compact are not supported. Closed as Later like bug 2055 
and bug 2056.

The parser drops any declaration that contains one of these display types (see 
bug 15432).

	shwag
	Comment 13 • 25 years ago

Pierre - I think you might have skipped huftis's comments above.  I'll quote 
them for you.  Is his concerns resolved?

from huftis@bigfoot.com 2000-02-01 13:25 -------
I understand this, and it's OK that you won't support CSS 2 (fully). What's not 
OK is *buggy* support that will cause *valid* pages to *not* work in Mozilla, 
but work in Lynx, Opera 3.6 and CSS 2 browsers.

	Hixie (not reading bugmail)
	Comment 14 • 24 years ago

Reopening and moving to Future...

	Karl Ove Hufthammer Reporter
	Comment 15 • 24 years ago

Updating URL.

	Karl Ove Hufthammer Reporter
	Comment 16 • 24 years ago

As I mentioned, one solution is to not support 'content' on elements which 
have 'display: marker' set. It's not a _good_ solution, but it's at least 
better than what we have ...

	Hixie (not reading bugmail)
	Comment 17 • 24 years ago

You mean 'pseudo-elements', not 'elements', right?

If so, then your solution is against the CSS WG's recommendations. If we don't
support 'marker' we should drop it. But we should not drop 'content' as well.

	Karl Ove Hufthammer Reporter
	Comment 18 • 24 years ago

> You mean 'pseudo-elements', not 'elements', right?

Yes, of course.

>If so, then your solution is against the CSS WG's recommendations.

Ehm, not supporting 'display: marker' is also against the CSS WG's 
recommendation.

> If we don't support 'marker' we should drop it. But we should not
> drop 'content' as well.

Well, the result is that pages (and now I'm repeating myself) that this "will 
cause *valid* pages to *not* work in Mozilla, but work in Lynx, Opera 3.6 and 
CSS 2 browsers."

The test case displays correctly in all browsers I've tried (including Opera 
4), and will display corectly in all HTML, CSS 1 and/or CSS 2 browser, but will 
*not* work in Mozilla (making 'display: marker' virtually useless in pages 
which wants to retain backward compatibility (with Mozilla 1.0)).

	Hixie (not reading bugmail)
	Comment 19 • 24 years ago

Ok, point taken. Then let's just implement display:marker and quit worrying 
about what happens if we don't! ;-) We need to implement display:marker anyway,
because our lack of support for the full marker box thing is causing us 
headaches with our support of list-item. See bug 54644, bug 21562, bug 54979...

	Karl Ove Hufthammer Reporter
	Comment 20 • 24 years ago

> Ok, point taken. Then let's just implement display:marker
> and quit worrying about what happens if we don't! ;-)

Hurray! :)

	Kevin McCluskey (gone)
	Comment 21 • 23 years ago

Build reassigning Buster's bugs to Marc.

	Hixie (not reading bugmail)
	Comment 22 • 23 years ago

display:marker might get dropped, let's see what happens on this front before
even considering this bug again.

	Hixie (not reading bugmail)
	Comment 23 • 22 years ago

Marking WONTFIX like a similar bug recently.

	Hixie (not reading bugmail)
	Comment 24 • 22 years ago

(The other bug was bug 26710.)

	Greg K.
	Comment 25 • 22 years ago

Shouldn't this stay open as Future since it's already part of a published W3 TR?
Whatever happens in the future, it's not going to be retroactively backed out of
CSS2.

	David Baron :dbaron:
	Comment 26 • 22 years ago

How do you know that?  If the CSS working group wanted to release a revised
version of CSS2, that revised version (unlike CSS2 itself) would have to go
through the Candidate Recommendation phase, which requires implementations
before moving to Proposed Recommendation.

	Garth Wallace
	Comment 27 • 22 years ago

*** Bug 149844 has been marked as a duplicate of this bug. ***

	Scott A. Colcord
	Comment 28 • 17 years ago

Reopening for consideration, as display: marker remains in CSS2.

<http://www.w3.org/TR/1998/REC-CSS2/generate.html#markers>

	Phil Ringnalda (:philor)
	Comment 29 • 17 years ago

Last I heard, Gecko implements CSS 2.1, where it does not remain: http://www.w3.org/TR/CSS21/changes.html#q20

	David Baron :dbaron:
	Comment 30 • 17 years ago

It's removed in both CSS 2.1 and css3-lists.

Bug 205202 covers implementing the (better-designed) css3-lists replacement for it.