This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 23529 - Behavior of CSS.escape(undefined)
Summary: Behavior of CSS.escape(undefined)
Status: RESOLVED WONTFIX
Alias: None
Product: CSS
Classification: Unclassified
Component: CSSOM (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Simon Pieters
QA Contact: public-css-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-10-15 22:23 UTC by Simon Pieters
Modified: 2013-10-16 10:56 UTC (History)
0 users

See Also:


Attachments

Description Simon Pieters 2013-10-15 22:23:46 UTC
http://dev.w3.org/csswg/cssom/#the-css.escape()-method

[[
escape(DOMString ident)
]]

Consider returning "undefined" instead of throwing.

http://krijnhoetmer.nl/irc-logs/whatwg/20131015#l-485
http://krijnhoetmer.nl/irc-logs/whatwg/20131016
Comment 1 Simon Pieters 2013-10-16 10:56:07 UTC
I had misunderstood WebIDL. The current behavior is as follows:

CSS.escape() throws TypeError.
CSS.escape(undefined) returns "undefined"

This is consistent with other DOM methods like e.g. document.getElementById. However, it's inconsistent with JS functions like encodeURIComponent which makes omitted argument also return "undefined".

The pro-throwing argument is mainly that it's easier to debug an error like

   CSS.escape(someobject.propertyThatDoesntExist)

However, no other method that takes a DOMString seems to throw for that case.

I think this settles that CSS.escape(undefined) should return "undefined".

What to do for CSS.escape() without argument is less clear (be consistent with encodeURIComponent or with document.getElementById). But also seems less important. Let's stick with WebIDL's default for that case.