invalid list-style-type makes ordered list from unordered list

RESOLVED WONTFIX

Status

()

Core
CSS Parsing and Computation
RESOLVED WONTFIX
4 years ago
5 months ago

People

(Reporter: Lajos Koszti, Unassigned)

Tracking

({dev-doc-complete, regression, site-compat})

33 Branch
dev-doc-complete, regression, site-compat
Points:
---

Firefox Tracking Flags

(firefox32 unaffected, firefox33- wontfix)

Details

Attachments

(1 attachment)

(Reporter)

Description

4 years ago
Created attachment 8442832 [details]
invalid-list-style.html

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Firefox/33.0 (Beta/Release)
Build ID: 20140619030203

Steps to reproduce:

I made a typo in CSS, where I wrote ul {list-style-type: non;}
Not the missing "e" from the none property value.


Actual results:

In current Firefox nightly the list appeared as an ordered list.
Actually, trying out other invalid values the same happened. 


Expected results:

I would expect to drop that value, and render the list as a regular unordered list.

Comment 1

4 years ago
Regression window(m-i)
Good:
https://hg.mozilla.org/integration/mozilla-inbound/rev/8b34896e9109
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0 ID:20140612050131
Bad:
https://hg.mozilla.org/integration/mozilla-inbound/rev/c973795d46ae
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0 ID:20140612061232
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=8b34896e9109&tochange=c973795d46ae

Triggered by: Bug 966166
Blocks: 966166
Status: UNCONFIRMED → NEW
status-firefox32: --- → unaffected
status-firefox33: --- → affected
tracking-firefox33: --- → ?
Component: Untriaged → CSS Parsing and Computation
Ever confirmed: true
Keywords: regression
Product: Firefox → Core
This is the new expected behavior in http://dev.w3.org/csswg/css-counter-styles-3/#extending-css2 ; the question is whether it's actually compatible with Web content, or enough content uses invalid values that we'll have to change the behavior somehow.
(In reply to David Baron [:dbaron] (UTC-7) (needinfo? for questions) from comment #2)
> This is the new expected behavior in
> http://dev.w3.org/csswg/css-counter-styles-3/#extending-css2 ; the question
> is whether it's actually compatible with Web content, or enough content uses
> invalid values that we'll have to change the behavior somehow.

Since this is intended behavior and probably low impact do you have any interest in tracking?
I think it's worth tracking for now, but if significant duplicates don't come in, we should untrack during beta.
tracking-firefox33: ? → +
David, I don't see much duplicate here. Should we untrack it now? Thanks
Flags: needinfo?(dbaron)
Yes.

Wontfix for now, though willing to reconsider if the problem appears more significant.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
status-firefox33: affected → wontfix
tracking-firefox33: + → -
Flags: needinfo?(dbaron)
OS: Linux → All
Hardware: x86_64 → All
Resolution: --- → WONTFIX
Duplicate of this bug: 1084315

Updated

3 years ago
Keywords: dev-doc-needed, site-compat
Duplicate of this bug: 1091228

Comment 10

3 years ago
I encountered this issue due to a type in XWiki's colibri.css: 
ul {
    list-style-type: bullet;
}
Bullet is a common name for this marker and since two other popular browsers fall back to the default item marker for ul: disc, this invalid value can easily be overseen.

http://jigsaw.w3.org/css-validator/validator, however, correctly reports a warning: "can't find the warning message for style-type".
Duplicate of this bug: 1110094
Duplicate of this bug: 1392682
You need to log in before you can comment on or make changes to this bug.