Pavlo Mykhalov Reporter
	Description • 10 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

	Cameron McCormack (:heycam)
	Comment 1 • 10 years ago

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)?

	Xidorn Quan [:xidorn] UTC+11
	Comment 2 • 10 years ago

This is the new behavior defined in CSS Counter Styles Level 3.

	Xidorn Quan [:xidorn] UTC+11
	Comment 3 • 10 years ago

BTW, why the User Agent is Chrome?

	Boris Zbarsky [:bzbarsky]
	Comment 4 • 10 years ago

> and we're converting JS undefined to the string "undefined".

The testcase doesn't involve JS undefined in any way.

	Daniel Holbert [:dholbert]
	Comment 5 • 10 years ago

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