undefined should not be an acceptable value for list-style-type

RESOLVED DUPLICATE of bug 1027647

Status

()

Core
CSS Parsing and Computation
RESOLVED DUPLICATE of bug 1027647
3 years ago
3 years ago

People

(Reporter: Pavlo Mykhalov, Unassigned)

Tracking

34 Branch
x86
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

3 years ago
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.71 Safari/537.36

Steps to reproduce:

Set "list-style-type: undefined" via style attribute or CSS rule.
Demo: http://jsbin.com/tafocacomi/2/edit?html,css,output


Actual results:

"list-style-type: undefined" is accepted, ul is displayed as ol


Expected results:

"list-style-type: undefined" should be dropped
I guess this is because list-style-type accepts identifiers (for custom counters), and we're converting JS undefined to the string "undefined".

Is there a chance we need to [TreatUndefinedAs=Null] here?  What happens on other properties that have always accepted an arbitrary identifier (e.g. counter-increment)?
Status: UNCONFIRMED → NEW
Ever confirmed: true
This is the new behavior defined in CSS Counter Styles Level 3.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1027647
BTW, why the User Agent is Chrome?
> and we're converting JS undefined to the string "undefined".

The testcase doesn't involve JS undefined in any way.
(In reply to Xidorn Quan [:xidorn] (UTC+11) from comment #3)
> BTW, why the User Agent is Chrome?

(That just means the reporter happened to be using chrome when filing the bug. Bugzilla auto-pastes that into the bug comment, for new bugzilla accounts, IIRC.)
You need to log in before you can comment on or make changes to this bug.