diff --git a/Makefile b/Makefile index 020c143a..15aa8cd4 100644 --- a/Makefile +++ b/Makefile @@ -1,15 +1,9 @@ all : index.html -index.html : index.xml WebIDL.xsl - xsltproc --nodtdattr --param now `date +%Y%m%d` WebIDL.xsl index.xml >index.html - -index.ids : index.xml - ./xref.pl -d index.xml http://heycam.github.io/webidl/ > index.ids - -java.html : java.xml WebIDL.xsl index.ids - xsltproc --nodtdattr --param now `date +%Y%m%d` WebIDL.xsl java.xml | ./xref.pl -t - index.ids > java.html +index.html : index.bs + bikeshed spec index.bs clean : - rm -f index.html java.html index.ids + rm -f index.html .PHONY : all clean diff --git a/PrototypeRoot-example.png b/PrototypeRoot-example.png deleted file mode 100644 index 282b5ce8..00000000 Binary files a/PrototypeRoot-example.png and /dev/null differ diff --git a/PrototypeRoot-example.svg b/PrototypeRoot-example.svg deleted file mode 100644 index 0f20b3fd..00000000 --- a/PrototypeRoot-example.svg +++ /dev/null @@ -1,173 +0,0 @@ - - - - - - Object prototype object → - - - - - - [[Prototype]] - toString - function - null - - - - - Node prototype object → - - - - - - [[Prototype]] - appendChild - function - - - - - - - - - - - - - - - - - Element prototype object → - - - - - - [[Prototype]] - getAttribute - function - - - - - - - - - - - - - - - - - HTMLElement prototype object → - - - - - - [[Prototype]] - focus - function - - - - - - - - - - - - - - - - - Mixin prototype object → - - - - - - [[Prototype]] - addEventListener - function - - - - - - - - - - - - - - - - - E → - - - - - - [[Prototype]] - nodeType - 1 - - - - - - - - - - - - - - - - - diff --git a/WebIDL.css b/WebIDL.css deleted file mode 100644 index 38a1dc20..00000000 --- a/WebIDL.css +++ /dev/null @@ -1,402 +0,0 @@ -.sym, pre, code, .esstring, .javavalue, .idlstring, .xattr, .regex, .prod-number, .prod-lines, .prod-mid { - font-size: 14px; -} -pre code, .prod-lines .sym { - font-size: 14px !important; -} -pre.syntax { background: #ddffdd; padding: 1em; margin: 1em 2em; font-weight: bold } -pre.syntax var, pre.syntax em, pre.syntax i { font-weight: normal; } -pre.syntax em { color: red } -.ednote, code, .esstring, .javavalue, .idlstring, .example, .note, blockquote { - background: #d9e8ff; -} -code { color: #ff4500; background: inherit } -.note code, .example code, .ednote code, .warning code { color: #802200; } -.note pre code, .example pre code, .ednote pre code, .warning pre code, pre code { color: black; } -td code { - background: inherit; -} -.example blockquote { - background: #f0f6ff; -} -.char { font-size: 85% } -table.grammar { - background: #eee; -} -.ednote { - border-top: 3px solid red; - border-bottom: 3px solid red; - margin: 1em 2em; - padding: 0 1em 0 1em; - background: #f8eeee; -} -.ednoteHeader { - font-weight: bold; - display: block; - padding-top: 0.5em; -} -.warning { - border-top: 3px solid rgb(255, 20, 147); - border-bottom: 3px solid rgb(255, 20, 147); - margin: 1em 2em; - padding: 0 1em 0 1em; - background: rgb(255, 228, 225); -} -.warningHeader { - font-weight: bold; - display: block; - padding-top: 0.5em; -} -.toc ul li { - list-style-type: none; - margin-top: 0; - margin-bottom: 0; -} -.toc ul { - margin-bottom: 0.5em; -} -.sym, code, .esstring, .javavalue, .idlstring, .input { - font-family: /*Consolas, Monaco,*/ monospace !important; -} -pre.code code { - background: inherit; -} -.descriptor { -} -th { - text-align: left; -} -table.vert { - border-collapse: collapse; - border-top: 2px solid #005a9c; - border-bottom: 2px solid #005a9c; - margin-top: 1em; - margin-bottom: 1em; - margin-left: auto; - margin-right: auto; -} -table.vert td { - background: #f0f6ff; -} -table.vert th { - text-align: left; - vertical-align: bottom; - background: #d9e8ff; - color: #005a9c; - color: black; - border-bottom: 2px solid #005a9c; - white-space: nowrap; -} -table.vert td { - /*border-top: 1px solid #a2c4e6; - border-bottom: 1px solid #a2c4e6;*/ - vertical-align: baseline; -} -table.vert th, table.vert td { - padding: 0.25em 0.75em; -} -table.vert td.table-note { - background: none; - border-left: 1px solid white; - border-right: 1px solid white; - border-bottom: 1px solid white; - font-size: 90%; -} -.xattr { - font-family: /*Consolas, Monaco,*/ monospace; -} -table.grammar { - border-collapse: collapse; - padding: 0.5em; - margin: 1em 2em; - overflow: auto; -} -table.grammar td { - vertical-align: top; - margin: 0; - padding: 0.325em 1em; - font-family: /*Consolas, Monaco,*/ monospace; -} -table.grammar td.prod-rhs { - vertical-align: inherit; -} -.sym, .prod-lines { - font-family: /*Consolas, Monaco,*/ monospace; - white-space: nowrap; -} -.idltype, .idlvalue { - font-weight: bold; -} -.idlop { - font-weight: bold; -} -.esvalue, .estype { - font-weight: bold; -} -.javatype, .javapkg { - font-weight: bold; -} -.regex { - font-family: /*Consolas, Monaco,*/ monospace; - white-space: nowrap; -} -.regex-slash { - color: orangered; -} -.typevar { - font-style: italic; -} -.example, .note { - border-top: 3px solid #005a9c; - border-bottom: 3px solid #005a9c; - margin: 1em 2em; - padding: 0 1em 0 1em; -} -.exampleHeader, .noteHeader { - font-weight: bold; - display: block; - color: #005a9c; - color: black; - padding-top: 0.5em; -} -pre { - overflow: auto; - margin: 0; - font-family: /*Consolas, Monaco,*/ monospace; -} -pre.code { - padding: 0 1em; - margin: 0; - margin-bottom: 1em; -} -.block { - border: 1px solid #90b8de; - border-left: 3px double #90b8de; - border-left: none; - border-right: none; - background: #f0f6ff; - margin: 2em; - margin-top: 1em; - margin-bottom: 1em; - padding: 0 0.5em; - padding-bottom: 0.5em; -} -.blockTitleDiv { - text-align: left; -} -.blockTitle { - position: relative; - top: -0.75em; - left: -1.5em; - /*border: 1px solid #90b8de; - border-left: none; - border-right: none;*/ - background: #90b8de; - color: white; - padding: 0.25em 1em 0.25em 1em; - font-weight: bold; - font-size: 80%; -} -dfn { - font-weight: bold; - font-style: italic; -} -.dfnref { -} -li { - margin-top: 0.5em; - margin-bottom: 0.5em; -} -ul > li { - list-style-type: disc; -} -ul > li > ul > li { - list-style-type: circle; -} -.norm { - font-style: italic; -} -.rfc2119 { - text-transform: lowercase; - font-variant: small-caps; -} -dfn var { - font-style: normal; -} -blockquote { - padding: 1px 1em; - margin-left: 2em; - margin-right: 2em; -} -a.placeholder { - color: #00e; -} -dl.changes > dd { - margin-left: 0; -} -dd > :first-child { - margin-top: 0; -} -caption { - caption-side: bottom; - margin-top: 1em; - font-weight: bold; -} -body { - line-height: 1.3; -} -@media print { - .section-link { - display: none; - } -} -.section-link { - visibility: hidden; - width: 1px; - height: 1px; - overflow: visible; - font-size: 10pt; - font-style: normal; - margin-left: 4px; - vertical-align: middle; -} -.section-link a { - color: #666; - font-weight: bold; - text-decoration: none; - padding: 2px 4px; - background: #eee; -} -.section-link a:hover { - color: #c00; -} -.section > *:hover > .section-link { - visibility: visible; -} -div.set { - margin-left: 3em; - margin-bottom: 1em; - text-indent: -1em; -} -ol.algorithm ol { - border-left: 1px solid #90b8de; - margin-left: 1em; -} -ol.algorithm ol.algorithm { - border-left: none; - margin-left: 0; -} -dl.switch > dd > ol.only { - margin-left: 0; -} -dl.switch > dd > ol.algorithm { - margin-left: -2em; -} -dl.switch { - padding-left: 2em; -} -dl.switch > dt { - text-indent: -1.5em; - margin-top: 1em; -} -dl.switch > dt + dt { - margin-top: 0; -} -dl.switch > dt:before { - content: '\21AA'; - padding: 0 0.5em 0 0; - display: inline-block; - width: 1em; - text-align: right; - line-height: 0.5em; -} -.diagram { - text-align: center; -} -iframe { - border: 0; -} -/* -.ignore { - opacity: 0.5; -} -*/ -.comment { - color: #005a9c; -} - -#distinguishable-table { - font-size: 80%; -} -#distinguishable-table td { - text-align: center; -} -#distinguishable-table th:first-child { - white-space: nowrap; -} -.matrix { - border-collapse: collapse; - margin-left: auto; - margin-right: auto; -} -.matrix tr:first-child th { - vertical-align: top; - text-align: center; - min-width: 5em; -} -.matrix th { - background: #d9e8ff; - text-align: right; -} -.matrix td, .matrix th { - border: 1px solid #90b8de; - padding: 4px; -} -.matrix th.corner { - border: 0; - background: none; -} -.matrix td { - text-align: center; - background: #f0f6ff; -} -.matrix .belowdiagonal { - background: #ddd; -} - -ul.notes { font-size: 90%; padding-left: 0 } -ul.notes li { list-style-type: none } -ul.notes .note-link { vertical-align: super } -.note-link { font-size: 90% } - -.code var { color: #f44; } - -.external:link, .external:visited { border-bottom: 2px solid rgb(153, 204, 153); text-decoration: none; color: inherit } - -.print { display: none } -@media print { .print { display: initial } } - -#publication-warning { position: fixed; top: 1em; right: 1em; width: 20em; padding: 1em; border: 2px solid red; background: rgb(255, 224, 224) } - -#sections h2, #sections h3 { margin-top: 2em; } - -#error-names dfn { font-style: normal; } - -/* For dfn.js */ -body.dfnEnabled dfn { cursor: pointer; } -.dfnPanel { - display: inline; - position: absolute; - height: auto; - width: auto; - padding: 0.5em 0.75em; - font: small sans-serif; - background: #DDDDDD; - color: black; - border: outset 0.2em; - cursor: default; -} -.dfnPanel * { margin: 0; padding: 0; font: inherit; text-indent: 0; } -.dfnPanel :link, .dfnPanel :visited { color: black; } -.dfnPanel p { font-weight: bolder; } -.dfnPanel li { list-style-position: inside; } diff --git a/WebIDL.xsl b/WebIDL.xsl deleted file mode 100644 index 6542c21e..00000000 --- a/WebIDL.xsl +++ /dev/null @@ -1,847 +0,0 @@ - - - - - - - - - - 12340506 - - - - - - - index.html - Web IDL - - Note: This file is generated from index.xml. Run "make" to regenerate it. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - unknown term '' - - - - - - - - - - - - - - - - - ( - - [] - - , section - - ) - - - - - - - - - @@ - - - - - - - - - - - - - -
-
W3C
-

-

- W3C - - First Public Working Draft - First Public and Last Call Working Draft - and Last Call Working Draft - Working Draft - Candidate Recommendation - Proposed Recommendation - Proposed Edited Recommendation - Recommendation - Working Group Note - Editor’s Draft - - - -

- -
-
This Version:
- - - -
-
- -
-
-
- -
Current Editor’s Draft:
-
- - -
-
- -
Latest Version:
-
-
- -
Previous Versions:
- - -
-
-
-
- - - -
Participate:
-
- - Send feedback to - - - - - or - file a bug - - - File a bug - - - ( - open bugs) - -
-
-
Editors:
- -
- - - - - - - - - - , - - - - - - - - - - - < - - > - -
-
-
- - - - - - - - - - - -
-
- - - - diff --git a/dfn.js b/dfn.js deleted file mode 100644 index 280d8f62..00000000 --- a/dfn.js +++ /dev/null @@ -1,129 +0,0 @@ -/* - * Taken from http://www.whatwg.org/specs/web-apps/current-work/dfn.js - * as of Wed Dec 10 13:08:00 Australia/Melbourne 2008. - * - * With modifications to make it work with the Web IDL section structure. - */ - -// dfn.js -// makes elements link back to all uses of the term -// no copyright is asserted on this file - -var dfnMapTarget = -1; -var dfnMapDone = 0; -var dfnMap = {}; -document.addEventListener('DOMContentLoaded', function (event) { - var links = []; - dfnMapTarget = document.links.length; - for (var i = 0; i < dfnMapTarget; i += 1) - links[i] = document.links[i]; - var inc = 100; - for (var i = 0; i < dfnMapTarget; i += inc) { - setTimeout(function (j) { - for (var k = j; k < j+inc && k < dfnMapTarget; k += 1) { - if (links[k].href.indexOf('#') >= 0) { - if (links[k].className != "no-backref" && - links[k].parentNode.className != "no-backref") { - var s = links[k].href.substr(links[k].href.indexOf('#') + 1); - if (!(s in dfnMap)) - dfnMap[s] = []; - dfnMap[s].push(links[k]); - } - } - dfnMapDone += 1; - } - }, 0, i); - } - document.body.className += " dfnEnabled"; -}, false); - -var dfnPanel; -var dfnUniqueId = 0; -var dfnTimeout; -document.addEventListener('click', dfnShow, false); -function dfnShow(event) { - if (dfnTimeout) { - clearTimeout(dfnTimeout); - dfnTimeout = null; - } - if (dfnPanel) { - dfnPanel.parentNode.removeChild(dfnPanel); - dfnPanel = null; - } - if (dfnMapDone == dfnMapTarget) { - var node = event.target; - while (node && (node.nodeType != event.target.ELEMENT_NODE || node.tagName != "DFN")) - node = node.parentNode; - if (node) { - var panel = document.createElement('div'); - panel.className = 'dfnPanel'; - if (node.id) { - var permalinkP = document.createElement('p'); - var permalinkA = document.createElement('a'); - permalinkA.href = '#' + node.id; - permalinkA.textContent = '#' + node.id; - permalinkP.appendChild(permalinkA); - panel.appendChild(permalinkP); - } - var p = document.createElement('p'); - panel.appendChild(p); - if (node.id in dfnMap || node.parentNode.id in dfnMap) { - p.textContent = 'Referenced in:'; - var ul = document.createElement('ul'); - var lastHeader; - var lastLi; - var n; - var sourceLinks = []; - if (node.id in dfnMap) - for (var i = 0; i < dfnMap[node.id].length; i += 1) - sourceLinks.push(dfnMap[node.id][i]); - if (node.parentNode.id in dfnMap) - for (var i = 0; i < dfnMap[node.parentNode.id].length; i += 1) - sourceLinks.push(dfnMap[node.parentNode.id][i]); - for (var i = 0; i < sourceLinks.length; i += 1) { - var link = sourceLinks[i]; - var header = dfnGetCaption(link); - var a = document.createElement('a'); - if (!link.id) - link.id = 'dfnReturnLink-' + dfnUniqueId++; - a.href = '#' + link.id; - if (header != lastHeader) { - lastHeader = header; - n = 1; - var li = document.createElement('li'); - var cloneHeader = header.cloneNode(true); - while (cloneHeader.hasChildNodes()) - if (cloneHeader.firstChild.className == 'section-link') - cloneHeader.removeChild(cloneHeader.firstChild); - else - a.appendChild(cloneHeader.firstChild); - lastLi = li; - li.appendChild(a); - ul.appendChild(li); - } else { - n += 1; - a.appendChild(document.createTextNode('(' + n + ')')); - lastLi.appendChild(document.createTextNode(' ')); - lastLi.appendChild(a); - } - } - panel.appendChild(ul); - } else { - p.textContent = 'No references in this file.'; - } - node.appendChild(panel); - dfnPanel = panel; - } - } else { - dfnTimeout = setTimeout(dfnShow, 250, event); - } -} - -function dfnGetCaption(link) { - var node = link; - while (node && !(node.parentNode.tagName == "DIV" && node.parentNode.className == "section")) - node = node.parentNode; - while (node && (node.nodeType != node.ELEMENT_NODE || !node.tagName.match(/^H[1-6]$/))) - node = node.previousSibling; - return node; -} diff --git a/dom/dom2css.idl b/dom/dom2css.idl deleted file mode 100644 index 15252c01..00000000 --- a/dom/dom2css.idl +++ /dev/null @@ -1,491 +0,0 @@ -/* - * dom2css.idl - * - * DOM Level 2 CSS IDL definitions, rewritten in Web IDL. - * - * Original OMG IDL: - * - * http://www.w3.org/TR/2000/REC-DOM-Level-2-Style-20001113/css.idl - */ - -module css { - - typedef dom::Document Document; - typedef dom::Element Element; - typedef dom::DOMImplementation DOMImplementation; - typedef dom::DOMException DOMException; - typedef views::AbstractView AbstractView; - - // Introduced in DOM Level 2: - interface CSSRuleList { - readonly attribute unsigned long length; - getter CSSRule item(in unsigned long index); - }; - - // Introduced in DOM Level 2: - [PrototypeRoot] - interface CSSRule { - - // RuleType - const unsigned short UNKNOWN_RULE = 0; - const unsigned short STYLE_RULE = 1; - const unsigned short CHARSET_RULE = 2; - const unsigned short IMPORT_RULE = 3; - const unsigned short MEDIA_RULE = 4; - const unsigned short FONT_FACE_RULE = 5; - const unsigned short PAGE_RULE = 6; - - readonly attribute unsigned short type; - attribute DOMString cssText setraises(DOMException); - - readonly attribute CSSStyleSheet parentStyleSheet; - readonly attribute CSSRule parentRule; - }; - - // Introduced in DOM Level 2: - interface CSSStyleRule : CSSRule { - attribute DOMString selectorText setraises(DOMException); - - readonly attribute CSSStyleDeclaration style; - }; - - // Introduced in DOM Level 2: - interface CSSMediaRule : CSSRule { - readonly attribute stylesheets::MediaList media; - readonly attribute CSSRuleList cssRules; - unsigned long insertRule(in DOMString rule, - in unsigned long index) - raises(DOMException); - void deleteRule(in unsigned long index) - raises(DOMException); - }; - - // Introduced in DOM Level 2: - interface CSSFontFaceRule : CSSRule { - readonly attribute CSSStyleDeclaration style; - }; - - // Introduced in DOM Level 2: - interface CSSPageRule : CSSRule { - attribute DOMString selectorText setraises(DOMException); - - readonly attribute CSSStyleDeclaration style; - }; - - // Introduced in DOM Level 2: - interface CSSImportRule : CSSRule { - readonly attribute DOMString href; - readonly attribute stylesheets::MediaList media; - readonly attribute CSSStyleSheet styleSheet; - }; - - // Introduced in DOM Level 2: - interface CSSCharsetRule : CSSRule { - attribute DOMString encoding setraises(DOMException); - - }; - - // Introduced in DOM Level 2: - interface CSSUnknownRule : CSSRule { - }; - - // Introduced in DOM Level 2: - interface CSSStyleDeclaration { - attribute DOMString cssText setraises(DOMException); - - DOMString getPropertyValue(in DOMString propertyName); - CSSValue getPropertyCSSValue(in DOMString propertyName); - DOMString removeProperty(in DOMString propertyName) - raises(DOMException); - DOMString getPropertyPriority(in DOMString propertyName); - void setProperty(in DOMString propertyName, - in DOMString value, - in DOMString? priority) - raises(DOMException); - readonly attribute unsigned long length; - getter DOMString item(in unsigned long index); - readonly attribute CSSRule parentRule; - }; - - // Introduced in DOM Level 2: - [PrototypeRoot] - interface CSSValue { - - // UnitTypes - const unsigned short CSS_INHERIT = 0; - const unsigned short CSS_PRIMITIVE_VALUE = 1; - const unsigned short CSS_VALUE_LIST = 2; - const unsigned short CSS_CUSTOM = 3; - - attribute DOMString cssText setraises(DOMException); - - readonly attribute unsigned short cssValueType; - }; - - // Introduced in DOM Level 2: - interface CSSPrimitiveValue : CSSValue { - - // UnitTypes - const unsigned short CSS_UNKNOWN = 0; - const unsigned short CSS_NUMBER = 1; - const unsigned short CSS_PERCENTAGE = 2; - const unsigned short CSS_EMS = 3; - const unsigned short CSS_EXS = 4; - const unsigned short CSS_PX = 5; - const unsigned short CSS_CM = 6; - const unsigned short CSS_MM = 7; - const unsigned short CSS_IN = 8; - const unsigned short CSS_PT = 9; - const unsigned short CSS_PC = 10; - const unsigned short CSS_DEG = 11; - const unsigned short CSS_RAD = 12; - const unsigned short CSS_GRAD = 13; - const unsigned short CSS_MS = 14; - const unsigned short CSS_S = 15; - const unsigned short CSS_HZ = 16; - const unsigned short CSS_KHZ = 17; - const unsigned short CSS_DIMENSION = 18; - const unsigned short CSS_STRING = 19; - const unsigned short CSS_URI = 20; - const unsigned short CSS_IDENT = 21; - const unsigned short CSS_ATTR = 22; - const unsigned short CSS_COUNTER = 23; - const unsigned short CSS_RECT = 24; - const unsigned short CSS_RGBCOLOR = 25; - - readonly attribute unsigned short primitiveType; - void setFloatValue(in unsigned short unitType, - in float floatValue) - raises(DOMException); - float getFloatValue(in unsigned short unitType) - raises(DOMException); - void setStringValue(in unsigned short stringType, - in DOMString stringValue) - raises(DOMException); - DOMString getStringValue() - raises(DOMException); - Counter getCounterValue() - raises(DOMException); - Rect getRectValue() - raises(DOMException); - RGBColor getRGBColorValue() - raises(DOMException); - }; - - // Introduced in DOM Level 2: - interface CSSValueList : CSSValue { - readonly attribute unsigned long length; - getter CSSValue item(in unsigned long index); - }; - - // Introduced in DOM Level 2: - interface RGBColor { - readonly attribute CSSPrimitiveValue red; - readonly attribute CSSPrimitiveValue green; - readonly attribute CSSPrimitiveValue blue; - }; - - // Introduced in DOM Level 2: - interface Rect { - readonly attribute CSSPrimitiveValue top; - readonly attribute CSSPrimitiveValue right; - readonly attribute CSSPrimitiveValue bottom; - readonly attribute CSSPrimitiveValue left; - }; - - // Introduced in DOM Level 2: - interface Counter { - readonly attribute DOMString identifier; - readonly attribute DOMString listStyle; - readonly attribute DOMString separator; - }; - - // Introduced in DOM Level 2: - interface ElementCSSInlineStyle { - readonly attribute CSSStyleDeclaration style; - }; - - // Introduced in DOM Level 2: - interface CSS2Properties { - attribute DOMString azimuth setraises(DOMException); - - attribute DOMString background setraises(DOMException); - - attribute DOMString backgroundAttachment setraises(DOMException); - - attribute DOMString backgroundColor setraises(DOMException); - - attribute DOMString backgroundImage setraises(DOMException); - - attribute DOMString backgroundPosition setraises(DOMException); - - attribute DOMString backgroundRepeat setraises(DOMException); - - attribute DOMString border setraises(DOMException); - - attribute DOMString borderCollapse setraises(DOMException); - - attribute DOMString borderColor setraises(DOMException); - - attribute DOMString borderSpacing setraises(DOMException); - - attribute DOMString borderStyle setraises(DOMException); - - attribute DOMString borderTop setraises(DOMException); - - attribute DOMString borderRight setraises(DOMException); - - attribute DOMString borderBottom setraises(DOMException); - - attribute DOMString borderLeft setraises(DOMException); - - attribute DOMString borderTopColor setraises(DOMException); - - attribute DOMString borderRightColor setraises(DOMException); - - attribute DOMString borderBottomColor setraises(DOMException); - - attribute DOMString borderLeftColor setraises(DOMException); - - attribute DOMString borderTopStyle setraises(DOMException); - - attribute DOMString borderRightStyle setraises(DOMException); - - attribute DOMString borderBottomStyle setraises(DOMException); - - attribute DOMString borderLeftStyle setraises(DOMException); - - attribute DOMString borderTopWidth setraises(DOMException); - - attribute DOMString borderRightWidth setraises(DOMException); - - attribute DOMString borderBottomWidth setraises(DOMException); - - attribute DOMString borderLeftWidth setraises(DOMException); - - attribute DOMString borderWidth setraises(DOMException); - - attribute DOMString bottom setraises(DOMException); - - attribute DOMString captionSide setraises(DOMException); - - attribute DOMString clear setraises(DOMException); - - attribute DOMString clip setraises(DOMException); - - attribute DOMString color setraises(DOMException); - - attribute DOMString content setraises(DOMException); - - attribute DOMString counterIncrement setraises(DOMException); - - attribute DOMString counterReset setraises(DOMException); - - attribute DOMString cue setraises(DOMException); - - attribute DOMString cueAfter setraises(DOMException); - - attribute DOMString cueBefore setraises(DOMException); - - attribute DOMString cursor setraises(DOMException); - - attribute DOMString direction setraises(DOMException); - - attribute DOMString display setraises(DOMException); - - attribute DOMString elevation setraises(DOMException); - - attribute DOMString emptyCells setraises(DOMException); - - attribute DOMString cssFloat setraises(DOMException); - - attribute DOMString font setraises(DOMException); - - attribute DOMString fontFamily setraises(DOMException); - - attribute DOMString fontSize setraises(DOMException); - - attribute DOMString fontSizeAdjust setraises(DOMException); - - attribute DOMString fontStretch setraises(DOMException); - - attribute DOMString fontStyle setraises(DOMException); - - attribute DOMString fontVariant setraises(DOMException); - - attribute DOMString fontWeight setraises(DOMException); - - attribute DOMString height setraises(DOMException); - - attribute DOMString left setraises(DOMException); - - attribute DOMString letterSpacing setraises(DOMException); - - attribute DOMString lineHeight setraises(DOMException); - - attribute DOMString listStyle setraises(DOMException); - - attribute DOMString listStyleImage setraises(DOMException); - - attribute DOMString listStylePosition setraises(DOMException); - - attribute DOMString listStyleType setraises(DOMException); - - attribute DOMString margin setraises(DOMException); - - attribute DOMString marginTop setraises(DOMException); - - attribute DOMString marginRight setraises(DOMException); - - attribute DOMString marginBottom setraises(DOMException); - - attribute DOMString marginLeft setraises(DOMException); - - attribute DOMString markerOffset setraises(DOMException); - - attribute DOMString marks setraises(DOMException); - - attribute DOMString maxHeight setraises(DOMException); - - attribute DOMString maxWidth setraises(DOMException); - - attribute DOMString minHeight setraises(DOMException); - - attribute DOMString minWidth setraises(DOMException); - - attribute DOMString orphans setraises(DOMException); - - attribute DOMString outline setraises(DOMException); - - attribute DOMString outlineColor setraises(DOMException); - - attribute DOMString outlineStyle setraises(DOMException); - - attribute DOMString outlineWidth setraises(DOMException); - - attribute DOMString overflow setraises(DOMException); - - attribute DOMString padding setraises(DOMException); - - attribute DOMString paddingTop setraises(DOMException); - - attribute DOMString paddingRight setraises(DOMException); - - attribute DOMString paddingBottom setraises(DOMException); - - attribute DOMString paddingLeft setraises(DOMException); - - attribute DOMString page setraises(DOMException); - - attribute DOMString pageBreakAfter setraises(DOMException); - - attribute DOMString pageBreakBefore setraises(DOMException); - - attribute DOMString pageBreakInside setraises(DOMException); - - attribute DOMString pause setraises(DOMException); - - attribute DOMString pauseAfter setraises(DOMException); - - attribute DOMString pauseBefore setraises(DOMException); - - attribute DOMString pitch setraises(DOMException); - - attribute DOMString pitchRange setraises(DOMException); - - attribute DOMString playDuring setraises(DOMException); - - attribute DOMString position setraises(DOMException); - - attribute DOMString quotes setraises(DOMException); - - attribute DOMString richness setraises(DOMException); - - attribute DOMString right setraises(DOMException); - - attribute DOMString size setraises(DOMException); - - attribute DOMString speak setraises(DOMException); - - attribute DOMString speakHeader setraises(DOMException); - - attribute DOMString speakNumeral setraises(DOMException); - - attribute DOMString speakPunctuation setraises(DOMException); - - attribute DOMString speechRate setraises(DOMException); - - attribute DOMString stress setraises(DOMException); - - attribute DOMString tableLayout setraises(DOMException); - - attribute DOMString textAlign setraises(DOMException); - - attribute DOMString textDecoration setraises(DOMException); - - attribute DOMString textIndent setraises(DOMException); - - attribute DOMString textShadow setraises(DOMException); - - attribute DOMString textTransform setraises(DOMException); - - attribute DOMString top setraises(DOMException); - - attribute DOMString unicodeBidi setraises(DOMException); - - attribute DOMString verticalAlign setraises(DOMException); - - attribute DOMString visibility setraises(DOMException); - - attribute DOMString voiceFamily setraises(DOMException); - - attribute DOMString volume setraises(DOMException); - - attribute DOMString whiteSpace setraises(DOMException); - - attribute DOMString widows setraises(DOMException); - - attribute DOMString width setraises(DOMException); - - attribute DOMString wordSpacing setraises(DOMException); - - attribute DOMString zIndex setraises(DOMException); - - }; - - // Introduced in DOM Level 2: - interface CSSStyleSheet : stylesheets::StyleSheet { - readonly attribute CSSRule ownerRule; - readonly attribute CSSRuleList cssRules; - unsigned long insertRule(in DOMString rule, - in unsigned long index) - raises(DOMException); - void deleteRule(in unsigned long index) - raises(DOMException); - }; - - // Introduced in DOM Level 2: - interface ViewCSS /*: views::AbstractView*/ { - CSSStyleDeclaration getComputedStyle(in Element elt, - in DOMString? pseudoElt); - }; - - AbstractView implements ViewCSS; - - // Introduced in DOM Level 2: - interface DocumentCSS /*: stylesheets::DocumentStyle*/ { - CSSStyleDeclaration getOverrideStyle(in Element elt, - in DOMString? pseudoElt); - }; - - Document implements DocumentCSS; - - // Introduced in DOM Level 2: - interface DOMImplementationCSS /*: DOMImplementation*/ { - CSSStyleSheet createCSSStyleSheet(in DOMString title, - in DOMString media) - raises(DOMException); - }; - - DOMImplementation implements DOMImplementationCSS; -}; diff --git a/dom/dom2events.idl b/dom/dom2events.idl deleted file mode 100644 index 343c4068..00000000 --- a/dom/dom2events.idl +++ /dev/null @@ -1,139 +0,0 @@ -/* - * dom2events.idl - * - * DOM Level 2 Events IDL definitions, rewritten in Web IDL. - * - * Original OMG IDL: - * - * http://www.w3.org/TR/2000/REC-DOM-Level-2-Events-20001113/events.idl - */ - -module events { - - typedef dom::DOMTimeStamp DOMTimeStamp; - typedef dom::Node Node; - typedef dom::DOMException DOMException; - - // Introduced in DOM Level 2: - exception EventException { - // EventExceptionCode - const unsigned short UNSPECIFIED_EVENT_TYPE_ERR = 0; - - unsigned short code; - }; - - - // Introduced in DOM Level 2: - interface EventTarget { - void addEventListener(in DOMString type, - in EventListener listener, - in boolean useCapture); - void removeEventListener(in DOMString type, - in EventListener listener, - in boolean useCapture); - boolean dispatchEvent(in Event evt) - raises(EventException); - }; - - Node implements EventTarget; - - // Introduced in DOM Level 2: - [Callback] - interface EventListener { - void handleEvent(in Event evt); - }; - - // Introduced in DOM Level 2: - [PrototypeRoot] - interface Event { - - // PhaseType - const unsigned short CAPTURING_PHASE = 1; - const unsigned short AT_TARGET = 2; - const unsigned short BUBBLING_PHASE = 3; - - readonly attribute DOMString type; - readonly attribute EventTarget target; - readonly attribute EventTarget currentTarget; - readonly attribute unsigned short eventPhase; - readonly attribute boolean bubbles; - readonly attribute boolean cancelable; - readonly attribute DOMTimeStamp timeStamp; - void stopPropagation(); - void preventDefault(); - void initEvent(in DOMString eventTypeArg, - in boolean canBubbleArg, - in boolean cancelableArg); - }; - - // Introduced in DOM Level 2: - interface DocumentEvent { - Event createEvent(in DOMString eventType) - raises(DOMException); - }; - - Document implements DocumentEvent; - - // Introduced in DOM Level 2: - interface UIEvent : Event { - readonly attribute views::AbstractView view; - readonly attribute long detail; - void initUIEvent(in DOMString typeArg, - in boolean canBubbleArg, - in boolean cancelableArg, - in views::AbstractView viewArg, - in long detailArg); - }; - - // Introduced in DOM Level 2: - interface MouseEvent : UIEvent { - readonly attribute long screenX; - readonly attribute long screenY; - readonly attribute long clientX; - readonly attribute long clientY; - readonly attribute boolean ctrlKey; - readonly attribute boolean shiftKey; - readonly attribute boolean altKey; - readonly attribute boolean metaKey; - readonly attribute unsigned short button; - readonly attribute EventTarget relatedTarget; - void initMouseEvent(in DOMString typeArg, - in boolean canBubbleArg, - in boolean cancelableArg, - in views::AbstractView viewArg, - in long detailArg, - in long screenXArg, - in long screenYArg, - in long clientXArg, - in long clientYArg, - in boolean ctrlKeyArg, - in boolean altKeyArg, - in boolean shiftKeyArg, - in boolean metaKeyArg, - in unsigned short buttonArg, - in EventTarget relatedTargetArg); - }; - - // Introduced in DOM Level 2: - interface MutationEvent : Event { - - // attrChangeType - const unsigned short MODIFICATION = 1; - const unsigned short ADDITION = 2; - const unsigned short REMOVAL = 3; - - readonly attribute Node relatedNode; - readonly attribute DOMString? prevValue; - readonly attribute DOMString? newValue; - readonly attribute DOMString? attrName; - readonly attribute unsigned short attrChange; - void initMutationEvent(in DOMString typeArg, - in boolean canBubbleArg, - in boolean cancelableArg, - in Node relatedNodeArg, - in DOMString? prevValueArg, - in DOMString? newValueArg, - in DOMString? attrNameArg, - in unsigned short attrChangeArg); - }; -}; diff --git a/dom/dom2ranges.idl b/dom/dom2ranges.idl deleted file mode 100644 index 9eb01282..00000000 --- a/dom/dom2ranges.idl +++ /dev/null @@ -1,105 +0,0 @@ -/* - * dom2ranges.idl - * - * DOM Level 2 Ranges IDL definitions, rewritten in Web IDL. - * - * Original OMG IDL: - * - * http://www.w3.org/TR/2000/REC-DOM-Level-2-Traversal-Range-20001113/ranges.idl - */ - -module ranges { - - typedef dom::Node Node; - typedef dom::Document Document; - typedef dom::DOMException DOMException; - typedef dom::DocumentFragment DocumentFragment; - - // Introduced in DOM Level 2: - exception RangeException { - // RangeExceptionCode - const unsigned short BAD_BOUNDARYPOINTS_ERR = 1; - const unsigned short INVALID_NODE_TYPE_ERR = 2; - - unsigned short code; - }; - - // Introduced in DOM Level 2: - interface Range { - readonly attribute Node startContainer getraises(DOMException); - - readonly attribute long startOffset getraises(DOMException); - - readonly attribute Node endContainer getraises(DOMException); - - readonly attribute long endOffset getraises(DOMException); - - readonly attribute boolean collapsed getraises(DOMException); - - readonly attribute Node commonAncestorContainer getraises(DOMException); - - void setStart(in Node refNode, - in long offset) - raises(RangeException, - DOMException); - void setEnd(in Node refNode, - in long offset) - raises(RangeException, - DOMException); - void setStartBefore(in Node refNode) - raises(RangeException, - DOMException); - void setStartAfter(in Node refNode) - raises(RangeException, - DOMException); - void setEndBefore(in Node refNode) - raises(RangeException, - DOMException); - void setEndAfter(in Node refNode) - raises(RangeException, - DOMException); - void collapse(in boolean toStart) - raises(DOMException); - void selectNode(in Node refNode) - raises(RangeException, - DOMException); - void selectNodeContents(in Node refNode) - raises(RangeException, - DOMException); - - // CompareHow - const unsigned short START_TO_START = 0; - const unsigned short START_TO_END = 1; - const unsigned short END_TO_END = 2; - const unsigned short END_TO_START = 3; - - short compareBoundaryPoints(in unsigned short how, - in Range sourceRange) - raises(DOMException); - void deleteContents() - raises(DOMException); - DocumentFragment extractContents() - raises(DOMException); - DocumentFragment cloneContents() - raises(DOMException); - void insertNode(in Node newNode) - raises(DOMException, - RangeException); - void surroundContents(in Node newParent) - raises(DOMException, - RangeException); - Range cloneRange() - raises(DOMException); - DOMString toString() - raises(DOMException); - void detach() - raises(DOMException); - }; - - // Introduced in DOM Level 2: - interface DocumentRange { - Range createRange(); - }; - - Document implements DocumentRange; -}; diff --git a/dom/dom2stylesheets.idl b/dom/dom2stylesheets.idl deleted file mode 100644 index f77f4b37..00000000 --- a/dom/dom2stylesheets.idl +++ /dev/null @@ -1,63 +0,0 @@ -/* - * dom2stylesheets.idl - * - * DOM Level 2 Style Sheets IDL definitions, rewritten in Web IDL. - * - * Original OMG IDL: - * - * http://www.w3.org/TR/2000/REC-DOM-Level-2-Style-20001113/stylesheets.idl - */ - -module stylesheets { - - typedef dom::Node Node; - typedef dom::Document Document; - typedef dom::ProcessingInstruction ProcessingInstruction; - typedef dom::DOMException DOMException; - - // Introduced in DOM Level 2: - [PrototypeRoot] - interface StyleSheet { - readonly attribute DOMString type; - attribute boolean disabled; - readonly attribute Node ownerNode; - readonly attribute StyleSheet parentStyleSheet; - readonly attribute DOMString? href; - readonly attribute DOMString title; - readonly attribute MediaList media; - }; - - // Introduced in DOM Level 2: - interface StyleSheetList { - readonly attribute unsigned long length; - getter StyleSheet item(in unsigned long index); - }; - - // Introduced in DOM Level 2: - interface MediaList { - attribute DOMString mediaText setraises(DOMException); - - readonly attribute unsigned long length; - getter DOMString? item(in unsigned long index); - void deleteMedium(in DOMString oldMedium) - raises(DOMException); - void appendMedium(in DOMString newMedium) - raises(DOMException); - }; - - // Introduced in DOM Level 2: - interface LinkStyle { - readonly attribute StyleSheet sheet; - }; - - // HTMLLinkElement implements LinkStyle; - // HTMLStyleElement implements LinkStyle; - ProcessingInstruction implements LinkStyle; - - // Introduced in DOM Level 2: - interface DocumentStyle { - readonly attribute StyleSheetList styleSheets; - }; - - Document implements DocumentStyle; -}; diff --git a/dom/dom2traversal.idl b/dom/dom2traversal.idl deleted file mode 100644 index 9f49a767..00000000 --- a/dom/dom2traversal.idl +++ /dev/null @@ -1,91 +0,0 @@ -/* - * dom2traversal.idl - * - * DOM Level 2 Traversal IDL definitions, rewritten in Web IDL. - * - * Original OMG IDL: - * - * http://www.w3.org/TR/2000/REC-DOM-Level-2-Traversal-Range-20001113/traversal.idl - */ - -module traversal { - - typedef dom::Node Node; - typedef dom::DOMException DOMException; - - interface NodeFilter; - - // Introduced in DOM Level 2: - interface NodeIterator { - readonly attribute Node root; - readonly attribute unsigned long whatToShow; - readonly attribute NodeFilter filter; - readonly attribute boolean expandEntityReferences; - Node nextNode() - raises(DOMException); - Node previousNode() - raises(DOMException); - void detach(); - }; - - // Introduced in DOM Level 2: - [Callback] - interface NodeFilter { - - // Constants returned by acceptNode - const short FILTER_ACCEPT = 1; - const short FILTER_REJECT = 2; - const short FILTER_SKIP = 3; - - - // Constants for whatToShow - const unsigned long SHOW_ALL = 0xFFFFFFFF; - const unsigned long SHOW_ELEMENT = 0x00000001; - const unsigned long SHOW_ATTRIBUTE = 0x00000002; - const unsigned long SHOW_TEXT = 0x00000004; - const unsigned long SHOW_CDATA_SECTION = 0x00000008; - const unsigned long SHOW_ENTITY_REFERENCE = 0x00000010; - const unsigned long SHOW_ENTITY = 0x00000020; - const unsigned long SHOW_PROCESSING_INSTRUCTION = 0x00000040; - const unsigned long SHOW_COMMENT = 0x00000080; - const unsigned long SHOW_DOCUMENT = 0x00000100; - const unsigned long SHOW_DOCUMENT_TYPE = 0x00000200; - const unsigned long SHOW_DOCUMENT_FRAGMENT = 0x00000400; - const unsigned long SHOW_NOTATION = 0x00000800; - - short acceptNode(in Node n); - }; - - // Introduced in DOM Level 2: - interface TreeWalker { - readonly attribute Node root; - readonly attribute unsigned long whatToShow; - readonly attribute NodeFilter filter; - readonly attribute boolean expandEntityReferences; - attribute Node currentNode setraises(DOMException); - - Node parentNode(); - Node firstChild(); - Node lastChild(); - Node previousSibling(); - Node nextSibling(); - Node previousNode(); - Node nextNode(); - }; - - // Introduced in DOM Level 2: - interface DocumentTraversal { - NodeIterator createNodeIterator(in Node root, - in unsigned long whatToShow, - in NodeFilter filter, - in boolean entityReferenceExpansion) - raises(DOMException); - TreeWalker createTreeWalker(in Node root, - in unsigned long whatToShow, - in NodeFilter filter, - in boolean entityReferenceExpansion) - raises(DOMException); - }; - - Document implements DocumentTraversal; -}; diff --git a/dom/dom2views.idl b/dom/dom2views.idl deleted file mode 100644 index d39ee909..00000000 --- a/dom/dom2views.idl +++ /dev/null @@ -1,27 +0,0 @@ -/* - * dom2views.idl - * - * DOM Level 2 Views IDL definitions, rewritten in Web IDL. - * - * Original OMG IDL: - * - * http://www.w3.org/TR/2000/REC-DOM-Level-2-Views-20001113/views.idl - */ - -module views { - - typedef dom::Document Document; - - // Introduced in DOM Level 2: - [PrototypeRoot] - interface AbstractView { - readonly attribute DocumentView document; - }; - - // Introduced in DOM Level 2: - interface DocumentView { - readonly attribute AbstractView defaultView; - }; - - Document implements DocumentView; -}; diff --git a/dom/dom3core.idl b/dom/dom3core.idl deleted file mode 100644 index 7c3d62d0..00000000 --- a/dom/dom3core.idl +++ /dev/null @@ -1,524 +0,0 @@ -/* - * dom3core.idl - * - * DOM Level 3 Core IDL definitions, rewritten in Web IDL. - * - * Original OMG IDL: - * - * http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/idl/dom.idl - */ - -module dom { - - typedef unsigned long long DOMTimeStamp; - - typedef any DOMUserData; - - typedef object DOMObject; - - exception DOMException { - - // ExceptionCode - const unsigned short INDEX_SIZE_ERR = 1; - const unsigned short DOMSTRING_SIZE_ERR = 2; - const unsigned short HIERARCHY_REQUEST_ERR = 3; - const unsigned short WRONG_DOCUMENT_ERR = 4; - const unsigned short INVALID_CHARACTER_ERR = 5; - const unsigned short NO_DATA_ALLOWED_ERR = 6; - const unsigned short NO_MODIFICATION_ALLOWED_ERR = 7; - const unsigned short NOT_FOUND_ERR = 8; - const unsigned short NOT_SUPPORTED_ERR = 9; - const unsigned short INUSE_ATTRIBUTE_ERR = 10; - // Introduced in DOM Level 2: - const unsigned short INVALID_STATE_ERR = 11; - // Introduced in DOM Level 2: - const unsigned short SYNTAX_ERR = 12; - // Introduced in DOM Level 2: - const unsigned short INVALID_MODIFICATION_ERR = 13; - // Introduced in DOM Level 2: - const unsigned short NAMESPACE_ERR = 14; - // Introduced in DOM Level 2: - const unsigned short INVALID_ACCESS_ERR = 15; - // Introduced in DOM Level 3: - const unsigned short VALIDATION_ERR = 16; - // Introduced in DOM Level 3: - const unsigned short TYPE_MISMATCH_ERR = 17; - - unsigned short code; - }; - - // Introduced in DOM Level 3: - interface DOMStringList { - // This uses DOMString? since DOM3Val expects the list can contain null. - getter DOMString? item(in unsigned long index); - readonly attribute unsigned long length; - boolean contains(in DOMString? str); - }; - - // Introduced in DOM Level 3: - interface NameList { - // DOMString? used here since DOM3Val assumes null can be used for both name and namespaceURI. - DOMString? getName(in unsigned long index); - DOMString? getNamespaceURI(in unsigned long index); - readonly attribute unsigned long length; - boolean contains(in DOMString? str); - boolean containsNS(in DOMString? namespaceURI, - in DOMString? name); - }; - - // Introduced in DOM Level 3: - interface DOMImplementationList { - getter DOMImplementation item(in unsigned long index); - readonly attribute unsigned long length; - }; - - // Introduced in DOM Level 3: - interface DOMImplementationSource { - // Feature strings can't be null. - DOMImplementation getDOMImplementation(in DOMString features); - DOMImplementationList getDOMImplementationList(in DOMString features); - }; - - interface DOMImplementation { - // Feature string and version string can't be null. - boolean hasFeature(in DOMString feature, - in DOMString version); - // Introduced in DOM Level 2: - // The qualifiedName can't be null, but publicId and systemId can. - DocumentType createDocumentType(in DOMString qualifiedName, - in DOMString? publicId, - in DOMString? systemId) - raises(DOMException); - // Introduced in DOM Level 2: - Document createDocument(in DOMString? namespaceURI, - in DOMString? qualifiedName, - in DocumentType doctype) - raises(DOMException); - // Introduced in DOM Level 3: - DOMObject getFeature(in DOMString feature, - in DOMString version); - }; - - [PrototypeRoot] - interface Node { - - // NodeType - const unsigned short ELEMENT_NODE = 1; - const unsigned short ATTRIBUTE_NODE = 2; - const unsigned short TEXT_NODE = 3; - const unsigned short CDATA_SECTION_NODE = 4; - const unsigned short ENTITY_REFERENCE_NODE = 5; - const unsigned short ENTITY_NODE = 6; - const unsigned short PROCESSING_INSTRUCTION_NODE = 7; - const unsigned short COMMENT_NODE = 8; - const unsigned short DOCUMENT_NODE = 9; - const unsigned short DOCUMENT_TYPE_NODE = 10; - const unsigned short DOCUMENT_FRAGMENT_NODE = 11; - const unsigned short NOTATION_NODE = 12; - - readonly attribute DOMString nodeName; - attribute DOMString? nodeValue getraises(DOMException) setraises(DOMException); - - readonly attribute unsigned short nodeType; - readonly attribute Node parentNode; - readonly attribute NodeList childNodes; - readonly attribute Node firstChild; - readonly attribute Node lastChild; - readonly attribute Node previousSibling; - readonly attribute Node nextSibling; - readonly attribute NamedNodeMap attributes; - // Modified in DOM Level 2: - readonly attribute Document ownerDocument; - // Modified in DOM Level 3: - Node insertBefore(in Node newChild, - in Node refChild) - raises(DOMException); - // Modified in DOM Level 3: - Node replaceChild(in Node newChild, - in Node oldChild) - raises(DOMException); - // Modified in DOM Level 3: - Node removeChild(in Node oldChild) - raises(DOMException); - // Modified in DOM Level 3: - Node appendChild(in Node newChild) - raises(DOMException); - boolean hasChildNodes(); - Node cloneNode(in boolean deep); - // Modified in DOM Level 3: - void normalize(); - // Introduced in DOM Level 2: - boolean isSupported(in DOMString feature, - in DOMString version); - // Introduced in DOM Level 2: - readonly attribute DOMString? namespaceURI; - // Introduced in DOM Level 2: - attribute DOMString? prefix setraises(DOMException); - - // Introduced in DOM Level 2: - readonly attribute DOMString? localName; - // Introduced in DOM Level 2: - boolean hasAttributes(); - // Introduced in DOM Level 3: - readonly attribute DOMString? baseURI; - - // DocumentPosition - const unsigned short DOCUMENT_POSITION_DISCONNECTED = 0x01; - const unsigned short DOCUMENT_POSITION_PRECEDING = 0x02; - const unsigned short DOCUMENT_POSITION_FOLLOWING = 0x04; - const unsigned short DOCUMENT_POSITION_CONTAINS = 0x08; - const unsigned short DOCUMENT_POSITION_CONTAINED_BY = 0x10; - const unsigned short DOCUMENT_POSITION_IMPLEMENTATION_SPECIFIC = 0x20; - - // Introduced in DOM Level 3: - unsigned short compareDocumentPosition(in Node other) - raises(DOMException); - // Introduced in DOM Level 3: - attribute DOMString? textContent getraises(DOMException) setraises(DOMException); - - // Introduced in DOM Level 3: - boolean isSameNode(in Node other); - // Introduced in DOM Level 3: - DOMString? lookupPrefix(in DOMString? namespaceURI); - // Introduced in DOM Level 3: - boolean isDefaultNamespace(in DOMString? namespaceURI); - // Introduced in DOM Level 3: - DOMString? lookupNamespaceURI(in DOMString? prefix); - // Introduced in DOM Level 3: - boolean isEqualNode(in Node arg); - // Introduced in DOM Level 3: - DOMObject getFeature(in DOMString feature, - in DOMString version); - // Introduced in DOM Level 3: - // Don't think it makes sense to allow null as a key, but Fx allows it. - DOMUserData setUserData(in DOMString key, - in DOMUserData data, - in UserDataHandler handler); - // Introduced in DOM Level 3: - DOMUserData getUserData(in DOMString key); - }; - - interface NodeList { - getter Node item(in unsigned long index); - readonly attribute unsigned long length; - }; - - interface NamedNodeMap { - Node getNamedItem(in DOMString name); - Node setNamedItem(in Node arg) - raises(DOMException); - Node removeNamedItem(in DOMString name) - raises(DOMException); - getter Node item(in unsigned long index); - readonly attribute unsigned long length; - // Introduced in DOM Level 2: - // Should we allow null for localName? It's probably not useful to be able to get a {null,null}-named node, but such nodes can exist. - Node getNamedItemNS(in DOMString? namespaceURI, - in DOMString? localName) - raises(DOMException); - // Introduced in DOM Level 2: - Node setNamedItemNS(in Node arg) - raises(DOMException); - // Introduced in DOM Level 2: - Node removeNamedItemNS(in DOMString? namespaceURI, - in DOMString? localName) - raises(DOMException); - }; - - interface CharacterData : Node { - attribute DOMString data getraises(DOMException) setraises(DOMException); - - readonly attribute unsigned long length; - DOMString substringData(in unsigned long offset, - in unsigned long count) - raises(DOMException); - void appendData(in DOMString arg) - raises(DOMException); - void insertData(in unsigned long offset, - in DOMString arg) - raises(DOMException); - void deleteData(in unsigned long offset, - in unsigned long count) - raises(DOMException); - void replaceData(in unsigned long offset, - in unsigned long count, - in DOMString arg) - raises(DOMException); - }; - - interface Attr : Node { - readonly attribute DOMString name; - readonly attribute boolean specified; - attribute DOMString value setraises(DOMException); - - // Introduced in DOM Level 2: - readonly attribute Element ownerElement; - // Introduced in DOM Level 3: - readonly attribute TypeInfo schemaTypeInfo; - // Introduced in DOM Level 3: - readonly attribute boolean isId; - }; - - interface Element : Node { - readonly attribute DOMString tagName; - // While the spec says to return an empty string if the attr doesn't exist, the real world disagrees. - DOMString getAttribute(in DOMString name); - void setAttribute(in DOMString name, - in DOMString value) - raises(DOMException); - void removeAttribute(in DOMString name) - raises(DOMException); - Attr getAttributeNode(in DOMString name); - Attr setAttributeNode(in Attr newAttr) - raises(DOMException); - Attr removeAttributeNode(in Attr oldAttr) - raises(DOMException); - NodeList getElementsByTagName(in DOMString name); - // Introduced in DOM Level 2: - DOMString getAttributeNS(in DOMString? namespaceURI, - in DOMString localName) - raises(DOMException); - // Introduced in DOM Level 2: - void setAttributeNS(in DOMString? namespaceURI, - in DOMString qualifiedName, - in DOMString value) - raises(DOMException); - // Introduced in DOM Level 2: - void removeAttributeNS(in DOMString? namespaceURI, - in DOMString localName) - raises(DOMException); - // Introduced in DOM Level 2: - Attr getAttributeNodeNS(in DOMString? namespaceURI, - in DOMString localName) - raises(DOMException); - // Introduced in DOM Level 2: - Attr setAttributeNodeNS(in Attr newAttr) - raises(DOMException); - // Introduced in DOM Level 2: - NodeList getElementsByTagNameNS(in DOMString? namespaceURI, - in DOMString localName) - raises(DOMException); - // Introduced in DOM Level 2: - boolean hasAttribute(in DOMString name); - // Introduced in DOM Level 2: - boolean hasAttributeNS(in DOMString? namespaceURI, - in DOMString localName) - raises(DOMException); - // Introduced in DOM Level 3: - readonly attribute TypeInfo schemaTypeInfo; - // Introduced in DOM Level 3: - void setIdAttribute(in DOMString name, - in boolean isId) - raises(DOMException); - // Introduced in DOM Level 3: - void setIdAttributeNS(in DOMString? namespaceURI, - in DOMString localName, - in boolean isId) - raises(DOMException); - // Introduced in DOM Level 3: - void setIdAttributeNode(in Attr idAttr, - in boolean isId) - raises(DOMException); - }; - - interface Text : CharacterData { - Text splitText(in unsigned long offset) - raises(DOMException); - // Introduced in DOM Level 3: - readonly attribute boolean isElementContentWhitespace; - // Introduced in DOM Level 3: - readonly attribute DOMString wholeText; - // Introduced in DOM Level 3: - Text replaceWholeText(in DOMString content) - raises(DOMException); - }; - - interface Comment : CharacterData { - }; - - // Introduced in DOM Level 3: - interface TypeInfo { - readonly attribute DOMString? typeName; - readonly attribute DOMString? typeNamespace; - - // DerivationMethods - const unsigned long DERIVATION_RESTRICTION = 0x00000001; - const unsigned long DERIVATION_EXTENSION = 0x00000002; - const unsigned long DERIVATION_UNION = 0x00000004; - const unsigned long DERIVATION_LIST = 0x00000008; - - boolean isDerivedFrom(in DOMString? typeNamespaceArg, - in DOMString typeNameArg, - in unsigned long derivationMethod); - }; - - // Introduced in DOM Level 3: - [Callback] - interface UserDataHandler { - - // OperationType - const unsigned short NODE_CLONED = 1; - const unsigned short NODE_IMPORTED = 2; - const unsigned short NODE_DELETED = 3; - const unsigned short NODE_RENAMED = 4; - const unsigned short NODE_ADOPTED = 5; - - void handle(in unsigned short operation, - in DOMString key, - in DOMUserData data, - in Node src, - in Node dst); - }; - - // Introduced in DOM Level 3: - interface DOMError { - - // ErrorSeverity - const unsigned short SEVERITY_WARNING = 1; - const unsigned short SEVERITY_ERROR = 2; - const unsigned short SEVERITY_FATAL_ERROR = 3; - - readonly attribute unsigned short severity; - readonly attribute DOMString message; - readonly attribute DOMString type; - readonly attribute DOMObject relatedException; - readonly attribute DOMObject relatedData; - readonly attribute DOMLocator location; - }; - - // Introduced in DOM Level 3: - interface DOMErrorHandler { - boolean handleError(in DOMError error); - }; - - // Introduced in DOM Level 3: - interface DOMLocator { - readonly attribute long lineNumber; - readonly attribute long columnNumber; - readonly attribute long byteOffset; - readonly attribute long utf16Offset; - readonly attribute Node relatedNode; - readonly attribute DOMString? uri; - }; - - // Introduced in DOM Level 3: - interface DOMConfiguration { - void setParameter(in DOMString name, - in DOMUserData value) - raises(DOMException); - DOMUserData getParameter(in DOMString name) - raises(DOMException); - boolean canSetParameter(in DOMString name, - in DOMUserData value); - readonly attribute DOMStringList parameterNames; - }; - - interface CDATASection : Text { - }; - - interface DocumentType : Node { - readonly attribute DOMString name; - readonly attribute NamedNodeMap entities; - readonly attribute NamedNodeMap notations; - // Introduced in DOM Level 2: - readonly attribute DOMString? publicId; - // Introduced in DOM Level 2: - readonly attribute DOMString? systemId; - // Introduced in DOM Level 2: - readonly attribute DOMString? internalSubset; - }; - - interface Notation : Node { - readonly attribute DOMString? publicId; - readonly attribute DOMString? systemId; - }; - - interface Entity : Node { - readonly attribute DOMString? publicId; - readonly attribute DOMString? systemId; - readonly attribute DOMString? notationName; - // Introduced in DOM Level 3: - readonly attribute DOMString? inputEncoding; - // Introduced in DOM Level 3: - readonly attribute DOMString? xmlEncoding; - // Introduced in DOM Level 3: - readonly attribute DOMString? xmlVersion; - }; - - interface EntityReference : Node { - }; - - interface ProcessingInstruction : Node { - readonly attribute DOMString target; - attribute DOMString data setraises(DOMException); - - }; - - interface DocumentFragment : Node { - }; - - interface Document : Node { - // Modified in DOM Level 3: - readonly attribute DocumentType doctype; - readonly attribute DOMImplementation implementation; - readonly attribute Element documentElement; - Element createElement(in DOMString tagName) - raises(DOMException); - DocumentFragment createDocumentFragment(); - Text createTextNode(in DOMString data); - Comment createComment(in DOMString data); - CDATASection createCDATASection(in DOMString data) - raises(DOMException); - ProcessingInstruction createProcessingInstruction(in DOMString target, - in DOMString data) - raises(DOMException); - Attr createAttribute(in DOMString name) - raises(DOMException); - EntityReference createEntityReference(in DOMString name) - raises(DOMException); - NodeList getElementsByTagName(in DOMString tagname); - // Introduced in DOM Level 2: - Node importNode(in Node importedNode, - in boolean deep) - raises(DOMException); - // Introduced in DOM Level 2: - Element createElementNS(in DOMString? namespaceURI, - in DOMString qualifiedName) - raises(DOMException); - // Introduced in DOM Level 2: - Attr createAttributeNS(in DOMString? namespaceURI, - in DOMString qualifiedName) - raises(DOMException); - // Introduced in DOM Level 2: - NodeList getElementsByTagNameNS(in DOMString? namespaceURI, - in DOMString localName); - // Introduced in DOM Level 2: - Element getElementById(in DOMString elementId); - // Introduced in DOM Level 3: - readonly attribute DOMString? inputEncoding; - // Introduced in DOM Level 3: - readonly attribute DOMString? xmlEncoding; - // Introduced in DOM Level 3: - attribute boolean xmlStandalone setraises(DOMException); - - // Introduced in DOM Level 3: - attribute DOMString? xmlVersion setraises(DOMException); - - // Introduced in DOM Level 3: - attribute boolean strictErrorChecking; - // Introduced in DOM Level 3: - attribute DOMString? documentURI; - // Introduced in DOM Level 3: - Node adoptNode(in Node source) - raises(DOMException); - // Introduced in DOM Level 3: - readonly attribute DOMConfiguration domConfig; - // Introduced in DOM Level 3: - void normalizeDocument(); - // Introduced in DOM Level 3: - Node renameNode(in Node n, - in DOMString? namespaceURI, - in DOMString qualifiedName) - raises(DOMException); - }; -}; diff --git a/dom/dom3ls.idl b/dom/dom3ls.idl deleted file mode 100644 index 4907d421..00000000 --- a/dom/dom3ls.idl +++ /dev/null @@ -1,155 +0,0 @@ -/* - * dom3ls.idl - * - * DOM Level 3 Load and Save IDL definitions, rewritten in Web IDL. - * - * Original OMG IDL: - * - * http://www.w3.org/TR/2004/REC-DOM-Level-3-LS-20040407/ls.idl - */ - -module ls { - - typedef Object LSInputStream; - - typedef Object LSOutputStream; - - typedef Object LSReader; - - typedef Object LSWriter; - - typedef dom::DOMConfiguration DOMConfiguration; - typedef dom::DOMException DOMException; - typedef dom::Node Node; - typedef dom::Document Document; - typedef dom::Element Element; - - exception LSException { - // LSExceptionCode - const unsigned short PARSE_ERR = 81; - const unsigned short SERIALIZE_ERR = 82; - - unsigned short code; - }; - - interface DOMImplementationLS { - - // DOMImplementationLSMode - const unsigned short MODE_SYNCHRONOUS = 1; - const unsigned short MODE_ASYNCHRONOUS = 2; - - LSParser createLSParser(in unsigned short mode, - in DOMString? schemaType) - raises(DOMException); - LSSerializer createLSSerializer(); - LSInput createLSInput(); - LSOutput createLSOutput(); - }; - - DOMImplementation implements DOMImplementationLS; - - interface LSParser { - readonly attribute DOMConfiguration domConfig; - attribute LSParserFilter filter; - readonly attribute boolean async; - readonly attribute boolean busy; - Document parse(in LSInput input) - raises(DOMException, - LSException); - Document parseURI(in DOMString uri) - raises(DOMException, - LSException); - - // ACTION_TYPES - const unsigned short ACTION_APPEND_AS_CHILDREN = 1; - const unsigned short ACTION_REPLACE_CHILDREN = 2; - const unsigned short ACTION_INSERT_BEFORE = 3; - const unsigned short ACTION_INSERT_AFTER = 4; - const unsigned short ACTION_REPLACE = 5; - - Node parseWithContext(in LSInput input, - in Node contextArg, - in unsigned short action) - raises(DOMException, - LSException); - void abort(); - }; - - [Callback] - interface LSInput { - // Depending on the language binding in use, - // this attribute may not be available. - attribute LSReader characterStream; - attribute LSInputStream byteStream; - attribute DOMString? stringData; - attribute DOMString? systemId; - attribute DOMString? publicId; - attribute DOMString? baseURI; - attribute DOMString? encoding; - attribute boolean certifiedText; - }; - - [Callback] - interface LSResourceResolver { - LSInput resolveResource(in DOMString type, - in DOMString? namespaceURI, - in DOMString? publicId, - in DOMString? systemId, - in DOMString? baseURI); - }; - - [Callback] - interface LSParserFilter { - - // Constants returned by startElement and acceptNode - const short FILTER_ACCEPT = 1; - const short FILTER_REJECT = 2; - const short FILTER_SKIP = 3; - const short FILTER_INTERRUPT = 4; - - unsigned short startElement(in Element elementArg); - unsigned short acceptNode(in Node nodeArg); - readonly attribute unsigned long whatToShow; - }; - - interface LSSerializer { - readonly attribute DOMConfiguration domConfig; - attribute DOMString? newLine; - attribute LSSerializerFilter filter; - boolean write(in Node nodeArg, - in LSOutput destination) - raises(LSException); - boolean writeToURI(in Node nodeArg, - in DOMString uri) - raises(LSException); - DOMString writeToString(in Node nodeArg) - raises(DOMException, - LSException); - }; - - [Callback] - interface LSOutput { - // Depending on the language binding in use, - // this attribute may not be available. - attribute LSWriter characterStream; - attribute LSOutputStream byteStream; - attribute DOMString? systemId; - attribute DOMString? encoding; - }; - - interface LSProgressEvent : events::Event { - readonly attribute LSInput input; - readonly attribute unsigned long position; - readonly attribute unsigned long totalSize; - }; - - interface LSLoadEvent : events::Event { - readonly attribute Document newDocument; - readonly attribute LSInput input; - }; - - [Callback] - interface LSSerializerFilter : traversal::NodeFilter { - readonly attribute unsigned long whatToShow; - }; -}; diff --git a/dom/dom3validation.idl b/dom/dom3validation.idl deleted file mode 100644 index 53002c72..00000000 --- a/dom/dom3validation.idl +++ /dev/null @@ -1,109 +0,0 @@ -/* - * dom3val.idl - * - * DOM Level 3 Validation IDL definitions, rewritten in Web IDL. - * - * Original OMG IDL: - * - * http://www.w3.org/TR/2004/REC-DOM-Level-3-Val-20040127/validation.idl - */ - -module validation { - - typedef dom::DOMStringList DOMStringList; - typedef dom::Node Node; - typedef dom::NameList NameList; - typedef dom::Attr Attr; - typedef dom::DOMConfiguration DOMConfiguration; - typedef dom::DOMException DOMException; - - exception ExceptionVAL { - // ExceptionVALCode - const unsigned short NO_SCHEMA_AVAILABLE_ERR = 71; - - unsigned short code; - }; - - [PrototypeRoot] - interface NodeEditVAL { - - // validationType - const unsigned short VAL_WF = 1; - const unsigned short VAL_NS_WF = 2; - const unsigned short VAL_INCOMPLETE = 3; - const unsigned short VAL_SCHEMA = 4; - - - // validationState - const unsigned short VAL_TRUE = 5; - const unsigned short VAL_FALSE = 6; - const unsigned short VAL_UNKNOWN = 7; - - readonly attribute DOMString? defaultValue; - readonly attribute DOMStringList enumeratedValues; - unsigned short canInsertBefore(in Node newChild, - in Node refChild); - unsigned short canRemoveChild(in Node oldChild); - unsigned short canReplaceChild(in Node newChild, - in Node oldChild); - unsigned short canAppendChild(in Node newChild); - unsigned short nodeValidity(in unsigned short valType); - }; - - interface ElementEditVAL : NodeEditVAL { - - // ContentTypeVAL - const unsigned short VAL_EMPTY_CONTENTTYPE = 1; - const unsigned short VAL_ANY_CONTENTTYPE = 2; - const unsigned short VAL_MIXED_CONTENTTYPE = 3; - const unsigned short VAL_ELEMENTS_CONTENTTYPE = 4; - const unsigned short VAL_SIMPLE_CONTENTTYPE = 5; - - readonly attribute NameList allowedChildren; - readonly attribute NameList allowedFirstChildren; - readonly attribute NameList allowedParents; - readonly attribute NameList allowedNextSiblings; - readonly attribute NameList allowedPreviousSiblings; - readonly attribute NameList allowedAttributes; - readonly attribute NameList requiredAttributes; - readonly attribute unsigned short contentType; - unsigned short canSetTextContent(in DOMString? possibleTextContent); - unsigned short canSetAttribute(in DOMString attrname, - in DOMString attrval); - unsigned short canSetAttributeNode(in Attr attrNode); - unsigned short canSetAttributeNS(in DOMString? namespaceURI, - in DOMString qualifiedName, - in DOMString value); - unsigned short canRemoveAttribute(in DOMString attrname); - unsigned short canRemoveAttributeNS(in DOMString? namespaceURI, - in DOMString localName); - unsigned short canRemoveAttributeNode(in Node attrNode); - unsigned short isElementDefined(in DOMString name); - unsigned short isElementDefinedNS(in DOMString? namespaceURI, - in DOMString name); - }; - - interface CharacterDataEditVAL : NodeEditVAL { - unsigned short isWhitespaceOnly(); - unsigned short canSetData(in DOMString arg); - unsigned short canAppendData(in DOMString arg); - unsigned short canReplaceData(in unsigned long offset, - in unsigned long count, - in DOMString arg) - raises(DOMException); - unsigned short canInsertData(in unsigned long offset, - in DOMString arg) - raises(DOMException); - unsigned short canDeleteData(in unsigned long offset, - in unsigned long count) - raises(DOMException); - }; - - interface DocumentEditVAL : NodeEditVAL { - attribute boolean continuousValidityChecking setraises(DOMException, ExceptionVAL); - - readonly attribute DOMConfiguration domConfig; - NameList getDefinedElements(in DOMString? namespaceURI); - unsigned short validateDocument(); - }; -}; diff --git a/dom/dom3xpath.idl b/dom/dom3xpath.idl deleted file mode 100644 index 5dc49ad6..00000000 --- a/dom/dom3xpath.idl +++ /dev/null @@ -1,97 +0,0 @@ -/* - * dom3xpath.idl - * - * DOM Level 3 XPath definitions, rewritten in Web IDL. - * - * Original OMG IDL: - * - * http://www.w3.org/TR/2004/NOTE-DOM-Level-3-XPath-20040226/xpath.idl - */ - -module xpath { - - typedef dom::Node Node; - typedef dom::DOMObject DOMObject; - typedef dom::Element Element; - typedef dom::Document Document; - typedef dom::DOMException DOMException; - - exception XPathException { - // XPathExceptionCode - const unsigned short INVALID_EXPRESSION_ERR = 51; - const unsigned short TYPE_ERR = 52; - - unsigned short code; - }; - - interface XPathEvaluator { - XPathExpression createExpression(in DOMString expression, - in XPathNSResolver resolver) - raises(XPathException, - DOMException); - XPathNSResolver createNSResolver(in Node nodeResolver); - DOMObject evaluate(in DOMString expression, - in Node contextNode, - in XPathNSResolver resolver, - in unsigned short type, - in DOMObject result) - raises(XPathException, - DOMException); - }; - - Document implements XPathEvaluator; - - interface XPathExpression { - DOMObject evaluate(in Node contextNode, - in unsigned short type, - in DOMObject result) - raises(XPathException, - dom::DOMException); - }; - - [Callback] - interface XPathNSResolver { - DOMString? lookupNamespaceURI(in DOMString prefix); - }; - - interface XPathResult { - - // XPathResultType - const unsigned short ANY_TYPE = 0; - const unsigned short NUMBER_TYPE = 1; - const unsigned short STRING_TYPE = 2; - const unsigned short BOOLEAN_TYPE = 3; - const unsigned short UNORDERED_NODE_ITERATOR_TYPE = 4; - const unsigned short ORDERED_NODE_ITERATOR_TYPE = 5; - const unsigned short UNORDERED_NODE_SNAPSHOT_TYPE = 6; - const unsigned short ORDERED_NODE_SNAPSHOT_TYPE = 7; - const unsigned short ANY_UNORDERED_NODE_TYPE = 8; - const unsigned short FIRST_ORDERED_NODE_TYPE = 9; - - readonly attribute unsigned short resultType; - readonly attribute double numberValue getraises(XPathException); - - readonly attribute DOMString stringValue getraises(XPathException); - - readonly attribute boolean booleanValue getraises(XPathException); - - readonly attribute Node singleNodeValue getraises(XPathException); - - readonly attribute boolean invalidIteratorState; - readonly attribute unsigned long snapshotLength getraises(XPathException); - - Node iterateNext() - raises(XPathException, - DOMException); - Node snapshotItem(in unsigned long index) - raises(XPathException); - }; - - interface XPathNamespace : Node { - - // XPathNodeType - const unsigned short XPATH_NAMESPACE_NODE = 13; - - readonly attribute Element ownerElement; - }; -}; diff --git a/empty.svg b/empty.svg deleted file mode 100644 index 681ab1a6..00000000 --- a/empty.svg +++ /dev/null @@ -1,2 +0,0 @@ - - diff --git a/file-bug.js b/file-bug.js deleted file mode 100644 index 499dfd87..00000000 --- a/file-bug.js +++ /dev/null @@ -1,53 +0,0 @@ -/* Usage: include a link like: - * file a bug - * and somewhere after that, include the following: - * - * If you don't want the script to inject styles, use a data-no-style="" - * attribute on the script element. - */ -(function(){ - var prevSelection=''; - var bugLink = document.createElement('a'); - bugLink.className = 'bug-link'; - bugLink.textContent = 'File a bug about the selected text'; - var link = document.querySelector('a[href^="https://www.w3.org/Bugs/Public/enter_bug.cgi?"]'); - link.parentNode.appendChild(bugLink); - var originalHref = link.href; - if (!document.querySelector('script[data-no-style][src$="/file-bug.js"]')) { - var style = document.createElement('style'); - style.textContent = '.bug-link { position:fixed; bottom:0; left:0; background:rgba(255,255,255,0.8) !important; width:115px; font-size:smaller; padding:0 10px; z-index:1; visibility:hidden; opacity:0; transition:0.3s; text-decoration:underline } .bug-link[href] { visibility:visible; opacity:1 } .bug-link:not([href]) { color:gray }'; - document.head.appendChild(style); - } - onmouseup=onkeyup=function(e){ - var selectionObj = getSelection(); - var selection = String(selectionObj); - if (selection == prevSelection) - return; - prevSelection = selection; - if (selection == '') { - bugLink.removeAttribute('href'); - bugLink.removeAttribute('accesskey'); - return; - } - var node = e.target; - if (selectionObj.anchorNode) { - node = selectionObj.anchorNode; - if (selectionObj.focusNode && selectionObj.focusNode.compareDocumentPosition) { - var compare = selectionObj.focusNode.compareDocumentPosition(selectionObj.anchorNode); - if (compare == 20 || compare == 4) // descendant or following - node = selectionObj.focusNode; - } - } - while (node && !node.id) { - node = node.previousSibling || node.parentNode; - } - var summary = selection.replace(/\n/g, ' '); - if (summary.length > 50) - summary = summary.substr(0,47)+'...'; - if (selection.length > 1000) - selection = selection.substr(0,997)+'...'; - var url = location.protocol+'//'+location.host+location.pathname+(node ? '#'+node.id : ''); - bugLink.href = originalHref + '&short_desc='+encodeURIComponent('"'+summary+'" ')+'&comment='+encodeURIComponent(url+'\n\n[[\n'+selection+'\n]]\n\n'); - bugLink.accessKey = '1'; - }; -})(); diff --git a/index.bs b/index.bs new file mode 100644 index 00000000..a0645589 --- /dev/null +++ b/index.bs @@ -0,0 +1,13930 @@ + + +
+urlPrefix: http://www.unicode.org/glossary/; spec: UNICODE
+    type: dfn
+        text: Unicode scalar value; url: unicode_scalar_value
+urlPrefix: https://tc39.github.io/ecma262/; spec: ECMA-262
+    type: dfn
+        text: NumericLiteral; url: sec-literals-numeric-literals
+        text: ECMAScript error objects; url: sec-error-objects
+        text: ToBoolean; url: sec-toboolean
+        text: ToNumber; url: sec-tonumber
+        text: ToUint16; url: sec-touint16
+        text: ToInt32; url: sec-toint32
+        text: ToUint32; url: sec-touint32
+        text: ToString; url: sec-tostring
+        text: ToObject; url: sec-toobject
+        text: IsAccessorDescriptor; url: sec-isaccessordescriptor
+        text: IsDataDescriptor; url: sec-isdatadescriptor
+        url: sec-ecmascript-data-types-and-values
+            text: Type
+            text: Type(x)
+        url: sec-algorithm-conventions
+            text: sign
+            text: floor
+            text: abs
+            text: modulo
+            text: !
+            text: ?
+            text: ECMA-262 section 5.2
+            text: conventions of the ECMAScript specification
+        text: element; url: sec-ecmascript-language-types-string-type
+        url: sec-iscallable
+            text: IsCallable
+            text: callable
+        url: sec-well-known-intrinsic-objects
+            text: %ArrayPrototype%
+            text: %ArrayProto_values%
+            text: %MapPrototype%
+            text: %SetPrototype%
+            text: %Error%
+            text: %ErrorPrototype%
+            text: %ObjProto_toString%
+            text: %IteratorPrototype%
+        text: %ObjectPrototype%; url: sec-properties-of-the-object-prototype-object
+        text: %FunctionPrototype%; url: sec-properties-of-the-function-prototype-object
+        text: %Promise%; url: sec-promise-constructor
+        text: Property Descriptor; url: sec-property-descriptor-specification-type
+        text: array index; url: sec-array-exotic-objects
+        text: OrdinaryGetOwnProperty; url: sec-ordinarygetownproperty
+        text: OrdinaryDefineOwnProperty; url: sec-ordinarydefineownproperty
+        text: default [[Set]] internal method; url: sec-ordinary-object-internal-methods-and-internal-slots-set-p-v-receiver
+        text: equally close values; url: sec-ecmascript-language-types-number-type
+        text: internal slot; url: sec-object-internal-methods-and-internal-slots
+        text: JavaScript execution context stack; url: execution-context-stack
+        text: running JavaScript execution context; url: running-execution-context
+        text: ReturnIfAbrupt; url: sec-returnifabrupt
+        text: GetIterator; url: sec-getiterator
+        text: IteratorStep; url: sec-iteratorstep
+        text: NormalCompletion; url: sec-normalcompletion
+        text: IteratorValue; url: sec-iteratorvalue
+        url: sec-well-known-symbols
+            text: @@iterator
+            text: @@toStringTag
+        text: CreateArrayIterator; url: sec-createarrayiterator
+        text: CreateIterResultObject; url: sec-createiterresultobject
+        text: CreateMapIterator; url: sec-createmapiterator
+        text: CreateSetIterator; url: sec-createsetiterator
+        text: ArrayCreate; url: sec-arraycreate
+        text: CreateDataProperty; url: sec-createdataproperty
+        text: DetachArrayBuffer; url: sec-detacharraybuffer
+        text: IsDetachedBuffer; url: sec-isdetachedbuffer
+        text: SetIntegrityLevel; url: sec-setintegritylevel
+        url: sec-array-iterator-objects
+            text: array iterator object
+            text: array iterator objects
+        text: Call; url: sec-call
+        text: Get; url: sec-get-o-p
+        text: Set; url: sec-set-o-p-v-throw
+        text: IsConstructor; url: sec-isconstructor
+        text: Construct; url: sec-construct
+        text: DefinePropertyOrThrow; url: sec-definepropertyorthrow
+        url: sec-code-realms
+            text: Realm
+            text: ECMAScript global environment
+        text: Completion; url: sec-completion-record-specification-type
+        text: ObjectCreate; url: sec-objectcreate
+        text: CreateBuiltinFunction; url: sec-createbuiltinfunction
+        text: SetFunctionName; url: sec-setfunctionname
+        text: immutable prototype exotic object; url: sec-immutable-prototype-exotic-objects
+        text: sections 9.1; url: sec-ordinary-object-internal-methods-and-internal-slots
+        text: 9.3.1; url: sec-built-in-function-objects-call-thisargument-argumentslist
+        text: ECMA-262 section 9.1.8; url: sec-ordinary-object-internal-methods-and-internal-slots-get-p-receiver
+        text: ECMA-262 section 19.2.2.3; url: sec-function-@@create
+        text: ECMA-262 section 19.2.3.8; url: sec-function.prototype-@@hasinstance
+        text: Array methods; url: sec-properties-of-the-array-prototype-object
+        text: typed arrays; url: sec-typedarray-objects
+        text: GetMethod; url: sec-getmethod
+        text: @@unscopables; url: sec-well-known-symbols
+urlPrefix: https://html.spec.whatwg.org/multipage/webappapis.html; spec: HTML
+    type: dfn
+        text: relevant settings object
+        text: relevant Realm; url: concept-relevant-realm
+        text: Prepare to run script
+        text: Clean up after running script
+        text: Prepare to run a callback
+        text: Clean up after running a callback
+        text: incumbent settings object
+        text: event handler IDL attributes; url: event-handler-attributes
+        text: settings object; url: concept-realm-settings-object            
+
+ + + + +

Introduction

+ +This section is informative. + +Technical reports published by the W3C that include programming +language interfaces have typically been described using the +Object Management Group’s Interface Definition Language (IDL) +[[OMGIDL]]. The IDL provides a means to +describe these interfaces in a language independent manner. Usually, +additional language binding appendices are included in such +documents which detail how the interfaces described with the IDL +correspond to constructs in the given language. + +However, the bindings in these specifications for the language most +commonly used on the web, ECMAScript, are consistently specified with +low enough precision as to result in interoperability issues. In +addition, each specification must describe the same basic information, +such as DOM interfaces described in IDL corresponding to properties +on the ECMAScript global object, or the {{unsigned long}} IDL type mapping to the Number +type in ECMAScript. + +This specification defines an IDL language similar to OMG IDL +for use by specifications that define interfaces for Web APIs. A number of extensions are +given to the IDL to support common functionality that previously must +have been written in prose. In addition, precise language bindings +for ECMAScript Edition 6 are given. + + +

Typographic conventions

+ +The following typographic conventions are used in this document: + +* Defining instances of terms: example term +* Links to terms defined in this document or elsewhere: [=example term=] +* Grammar terminals: sometoken +* Grammar non-terminals: ExampleGrammarNonTerminal +* Grammar symbols: identifier +* IDL and ECMAScript types: ExampleType +* Code snippets: a = b + obj.f() +* Unicode characters: U+0030 DIGIT ZERO ("0") +* Extended attributes: [ExampleExtendedAttribute] +* Variable names in prose and algorithms: |exampleVariableName|. +* Algorithms use the [=conventions of the ECMAScript specification=], + including the ! and ? notation for unwrapping completion records. +* IDL informal syntax examples: +
+        interface identifier {
+          /* interface_members... */
+        };
+    
+ + (Specific parts of the syntax discussed in surrounding prose are highlighted.) +* IDL grammar snippets: +
+        ExampleGrammarNonTerminal :
+            OtherNonTerminal "sometoken"
+            other AnotherNonTerminal
+            ε  // nothing
+    
+* Non-normative notes: + + Note: This is a note. + +* Non-normative examples: +
+ This is an example. +
+* Normative warnings: +

+ This is a warning. +

+* Code blocks: +
+        // This is an IDL code block.
+        interface Example {
+          attribute long something;
+        };
+    
+
+        // This is an ECMAScript code block.
+        window.onload = function() { window.alert("loaded"); };
+    
+ + +

Conformance

+ +Everything in this specification is normative except for diagrams, +examples, notes and sections marked as being informative. + +The keywords “must”, +“must not”, +“required”, +“shall”, +“shall not”, +“should”, +“should not”, +“recommended”, +“may” and +“optional” in this document are to be +interpreted as described in +Key words for use in RFCs to +Indicate Requirement Levels +[[!RFC2119]]. + +The following conformance classes are defined by this specification: + + : conforming set of IDL fragments + :: A set of [=IDL fragments=] is considered + to be a [=conforming set of IDL fragments=] if, taken together, they satisfy all of the + must-, + required- and shall-level + criteria in this specification that apply to IDL fragments. + : conforming implementation + :: A user agent is considered to be a + [=conforming implementation=] + relative to a [=conforming set of IDL fragments=] if it satisfies all of the must-, + required- and shall-level + criteria in this specification that apply to implementations for all language + bindings that the user agent supports. + : conforming ECMAScript implementation + :: A user agent is considered to be a + [=conforming ECMAScript implementation=] + relative to a [=conforming set of IDL fragments=] if it satisfies all of the must-, + required- and shall-level + criteria in this specification that apply to implementations for the ECMAScript + language binding. + + +

Conformant Algorithms

+ +Requirements phrased in the imperative as part of algorithms (such as +“strip any leading space characters” or “return false and abort these +steps”) are to be interpreted with the meaning of the key word (“must”, +“should”, “may”, etc) used in introducing the algorithm. + +Conformance requirements phrased as algorithms or specific steps can be +implemented in any manner, so long as the end result is equivalent. In +particular, the algorithms defined in this specification are intended to +be easy to understand and are not intended to be performant. Implementers +are encouraged to optimize. + + +

Interface definition language

+ +This section describes a language, Web IDL, which can be used to define +interfaces for APIs in the Web platform. A specification that defines Web APIs +can include one or more IDL fragments that +describe the interfaces (the state and behavior that objects can exhibit) +for the APIs defined by that specification. +An [=IDL fragment=] is +a sequence of definitions that matches the Definitions grammar symbol. +The set of [=IDL fragments=] that +an implementation supports is not ordered. +See [[#idl-grammar]] for the complete grammar and an explanation of the notation used. + +The different kinds of definitions that can appear in an +[=IDL fragment=] are: +[=interfaces=], +[=partial interface|partial interface definitions=], +[=namespaces=], +[=partial namespace|partial namespace definitions=], +[=dictionary|dictionaries=], +[=partial dictionary|partial dictionary definitions=], +[=typedefs=] and +[=implements statements=]. +These are all defined in the following sections. + +Each [=definition=] +(matching Definition) +can be preceded by a list of [=extended attributes=] (matching +ExtendedAttributeList), +which can control how the definition will be handled in language bindings. +The extended attributes defined by this specification that are language binding +agnostic are discussed in [[#idl-extended-attributes]], +while those specific to the ECMAScript language binding are discussed +in [[#es-extended-attributes]]. + +
+    [extended_attributes]
+    interface identifier {
+      /* interface_members... */
+    };
+
+ +
+    Definitions :
+        ExtendedAttributeList Definition Definitions
+        ε
+
+ +
+    Definition :
+        CallbackOrInterface
+        Namespace
+        Partial
+        Dictionary
+        Enum
+        Typedef
+        ImplementsStatement
+
+ +
+    CallbackOrInterface :
+        "callback" CallbackRestOrInterface
+        Interface
+
+ +
+ + The following is an example of an [=IDL fragment=]. + +
+        interface Paint { };
+        
+        interface SolidColor : Paint {
+          attribute double red;
+          attribute double green;
+          attribute double blue;
+        };
+        
+        interface Pattern : Paint {
+          attribute DOMString imageURL;
+        };
+        
+        [Constructor]
+        interface GraphicalWindow {
+          readonly attribute unsigned long width;
+          readonly attribute unsigned long height;
+        
+          attribute Paint currentPaint;
+        
+          void drawRectangle(double x, double y, double width, double height);
+        
+          void drawText(double x, double y, DOMString text);
+        };
+    
+ + Here, four [=interfaces=] + are being defined. + The GraphicalWindow interface has two + [=read only=] [=attributes=], + one writable attribute, and two [=operations=] + defined on it. Objects that implement the GraphicalWindow interface + will expose these attributes and operations in a manner appropriate to the + particular language being used. + + In ECMAScript, the attributes on the IDL interfaces will be exposed as accessor + properties and the operations as Function-valued + data properties on a prototype object for all GraphicalWindow + objects; each ECMAScript object that implements GraphicalWindow + will have that prototype object in its prototype chain. + + The [{{Constructor}}] that appears on GraphicalWindow + is an [=extended attribute=]. + This extended attribute causes a constructor to exist in ECMAScript implementations, + so that calling new GraphicalWindow() would return a new object + that implemented the interface. + +
+ + +

Names

+ +Every [=interface=], +[=partial interface|partial interface definition=], +[=namespace=], +[=partial namespace|partial namespace definition=], +[=dictionary=], +[=partial dictionary|partial dictionary definition=], +[=enumeration=], +[=callback function=] and +[=typedef=] (together called named definitions) +and every [=constant=], +[=attribute=], +and [=dictionary member=] has an +identifier, as do some +[=operations=]. +The identifier is determined by an +identifier token somewhere +in the declaration: + +* For [=named definitions=], + the identifier token that appears + directly after the interface, namespace, + dictionary, enum + or callback keyword + determines the identifier of that definition. +
+        interface interface_identifier { /* interface_members... */ };
+        partial interface interface_identifier { /* interface_members... */ };
+        namespace namespace_identifier { /* namespace_members... */ };
+        partial namespace namespace_identifier { /* namespace_members... */ };
+        dictionary dictionary_identifier { /* dictionary_members... */ };
+        partial dictionary dictionary_identifier { /* dictionary_members... */ };
+        enum enumeration_identifier { "enum", "values" /* , ... */ };
+        callback callback_identifier = return_type (/* arguments... */);
+    
+* For [=attributes=], + [=typedefs=] + and [=dictionary members=], + the final identifier token before the + semicolon at the end of the declaration determines the identifier. +
+        interface identifier {
+          attribute type attribute_identifier;
+        };
+        
+        typedef type typedef_identifier;
+        
+        dictionary identifier {
+          type dictionary_member_identifier;
+        };
+    
+* For [=constants=], + the identifier token before the + equals sign determines the identifier. +
const type constant_identifier = 42;
+* For [=operations=], the + identifier token that appears + after the return type but before the opening parenthesis (that is, + one that is matched as part of the OptionalIdentifier + grammar symbol in an OperationRest) determines the identifier of the operation. If + there is no such identifier token, + then the operation does not have an identifier. +
+        interface interface_identifier {
+          return_type operation_identifier(/* arguments... */);
+        };
+    
+ +Note: Operations can have no identifier when they are being used to declare a +[=special operation|special kind of operation=], such as a getter or setter. + +For all of these constructs, the [=identifier=] +is the value of the identifier token with any leading +U+005F LOW LINE ("_") character (underscore) removed. + +Note: A leading "_" is used to escape an identifier from looking +like a reserved word so that, for example, an interface named “interface” can be +defined. The leading "_" is dropped to unescape the +identifier. + +Operation arguments can take a slightly wider set of identifiers. In an operation +declaration, the identifier of an argument is specified immediately after its +type and is given by either an identifier +token or by one of the keywords that match the ArgumentNameKeyword +symbol. If one of these keywords is used, it need not be escaped with a leading +underscore. + +
+    interface interface_identifier {
+      return_type operation_identifier(argument_type argument_identifier /* , ... */);
+    };
+
+ +
+    ArgumentNameKeyword :
+        "attribute"
+        "callback"
+        "const"
+        "deleter"
+        "dictionary"
+        "enum"
+        "getter"
+        "implements"
+        "inherit"
+        "interface"
+        "iterable"
+        "legacycaller"
+        "maplike"
+        "namespace"
+        "partial"
+        "required"
+        "serializer"
+        "setlike"
+        "setter"
+        "static"
+        "stringifier"
+        "typedef"
+        "unrestricted"
+
+ +If an identifier token is used, then the +[=identifier=] of the operation argument +is the value of that token with any leading +U+005F LOW LINE ("_") character (underscore) removed. +If instead one of the ArgumentNameKeyword +keyword token is used, then the [=identifier=] of the operation argument +is simply that token. + +The [=identifier=] of any of the abovementioned +IDL constructs must not be “constructor”, +“toString”, “toJSON”, +or begin with a U+005F LOW LINE ("_") character. These +are known as reserved identifiers. + +Note: Further restrictions on identifier names for particular constructs may be made +in later sections. + +Within the set of [=IDL fragments=] +that a given implementation supports, +the [=identifier=] of every +[=interface=], +[=namespace=], +[=dictionary=], +[=enumeration=], +[=callback function=] and +[=typedef=] +must not +be the same as the identifier of any other +[=interface=], +[=namespace=], +[=dictionary=], +[=enumeration=], +[=callback function=] or +[=typedef=]. + +Within an [=IDL fragment=], a reference +to a [=definition=] need not appear after +the declaration of the referenced definition. References can also be made +across [=IDL fragments=]. + +
+ + Therefore, the following [=IDL fragment=] is valid: + +
+        interface B : A {
+          void f(SequenceOfLongs x);
+        };
+        
+        interface A {
+        };
+        
+        typedef sequence<long> SequenceOfLongs;
+    
+
+ +
+ + The following [=IDL fragment=] + demonstrates how [=identifiers=] + are given to definitions and [=interface members=]. + +
+        // Typedef identifier: "number"
+        typedef double number;
+        
+        // Interface identifier: "System"
+        interface System {
+        
+          // Operation identifier:          "createObject"
+          // Operation argument identifier: "interface"
+          object createObject(DOMString _interface);
+        
+          // Operation argument identifier: "interface"
+          sequence<object> getObjects(DOMString interface);
+        
+          // Operation has no identifier; it declares a getter.
+          getter DOMString (DOMString keyName);
+        };
+        
+        // Interface identifier: "TextField"
+        interface TextField {
+        
+          // Attribute identifier: "const"
+          attribute boolean _const;
+        
+          // Attribute identifier: "value"
+          attribute DOMString? _value;
+        };
+    
+ + Note that while the second [=attribute=] + on the TextField [=interface=] + need not have been escaped with an underscore (because “value” is + not a keyword in the IDL grammar), it is still unescaped + to obtain the attribute’s [=identifier=]. + +
+ + +

Interfaces

+ +[=IDL fragments=] are used to +describe object oriented systems. In such systems, objects are entities +that have identity and which are encapsulations of state and behavior. +An interface is a definition (matching +Interface or +callback Interface) that declares some +state and behavior that an object implementing that interface will expose. + +
+    interface identifier {
+      /* interface_members... */
+    };
+
+ +An interface is a specification of a set of +interface members +(matching InterfaceMembers), +which are the [=constants=], +[=attributes=], +[=operations=] and +other declarations that appear between the braces in the interface declaration. +Attributes describe the state that an object +implementing the interface will expose, and operations describe the +behaviors that can be invoked on the object. Constants declare +named constant values that are exposed as a convenience to users +of objects in the system. + +Interfaces in Web IDL describe how objects that implement the +interface behave. In bindings for object oriented languages, it is +expected that an object that implements a particular IDL interface +provides ways to inspect and modify the object's state and to +invoke the behavior described by the interface. + +An interface can be defined to inherit from another interface. +If the identifier of the interface is followed by a +U+003A COLON (":") character +and an [=identifier=], +then that identifier identifies the inherited interface. +An object that implements an interface that inherits from another +also implements that inherited interface. The object therefore will also +have members that correspond to the interface members from the inherited interface. + +
+    interface identifier : identifier_of_inherited_interface {
+      /* interface_members... */
+    };
+
+ +The order that members appear in has significance for property enumeration in the ECMAScript binding. + +Interfaces may specify an interface member that has the same name as +one from an inherited interface. Objects that implement the derived +interface will expose the member on the derived interface. It is +language binding specific whether the overridden member can be +accessed on the object. + +
+ + Consider the following two interfaces. + +
+        interface A {
+          void f();
+          void g();
+        };
+        
+        interface B : A {
+          void f();
+          void g(DOMString x);
+        };
+    
+ + In the ECMAScript language binding, an instance of B + will have a prototype chain that looks like the following: + +
+        [Object.prototype: the Object prototype object]
+             ↑
+        [A.prototype: interface prototype object for A]
+             ↑
+        [B.prototype: interface prototype object for B]
+             ↑
+        [instanceOfB]
+    
+ + Calling instanceOfB.f() in ECMAScript will invoke the f defined + on B. However, the f from A + can still be invoked on an object that implements B by + calling A.prototype.f.call(instanceOfB). + +
+ +The inherited interfaces of +a given interface |A| is the set of all interfaces that |A| +inherits from, directly or indirectly. If |A| does not [=interface/inherit=] +from another interface, then the set is empty. Otherwise, the set +includes the interface |B| that |A| [=interface/inherits=] +from and all of |B|’s [=inherited interfaces=]. + +An interface must not be declared such that +its inheritance hierarchy has a cycle. That is, an interface +|A| cannot inherit from itself, nor can it inherit from another +interface |B| that inherits from |A|, and so on. + +Note that general multiple inheritance of interfaces is not supported, and +objects also cannot implement arbitrary sets of interfaces. +Objects can be defined to implement a single given interface |A|, +which means that it also implements all of |A|’s +[=inherited interfaces=]. In addition, +an implements statement can be +used to define that objects implementing an interface will always +also implement another interface. + +Each interface member can be preceded by a list of [=extended attributes=] (matching +ExtendedAttributeList), +which can control how the interface member will be handled in language bindings. + +
+    interface identifier {
+    
+      [extended_attributes]
+      const type constant_identifier = 42;
+    
+      [extended_attributes]
+      attribute type identifier;
+    
+      [extended_attributes]
+      return_type identifier(/* arguments... */);
+    };
+
+ +A callback interface is +an [=interface=] +that uses the callback keyword at the start of +its definition. Callback interfaces are ones that can be +implemented by [=user objects=] +and not by [=platform objects=], +as described in [[#idl-objects]]. + +
+    callback interface identifier {
+      /* interface_members... */
+    };
+
+ +Note: See also the similarly named [=callback function=] definition. + +[=Callback interfaces=] +must not [=interface/inherit=] +from any non-callback interfaces, and non-callback interfaces must not +inherit from any callback interfaces. +Callback interfaces must not have any +[=consequential interfaces=]. + +[=Static attributes=] and +[=static operations=] must not +be defined on a [=callback interface=]. + +
+ + Specification authors should not define + [=callback interfaces=] + that have only a single [=operation=], + unless required to describe the requirements of existing APIs. + Instead, a [=callback function=] should be used. + + The definition of EventListener as a + [=callback interface=] + is an example of an existing API that needs to allow + [=user objects=] with a + given property (in this case “handleEvent”) to be considered to implement the interface. + For new APIs, and those for which there are no compatibility concerns, + using a [=callback function=] will allow + only a Function object (in the ECMAScript + language binding). + +
+ +

+ Perhaps this warning shouldn't apply if you are planning to extend the callback + interface in the future. That's probably a good reason to start off with a single + operation callback interface. +

+ +

+ I think we need to support operations not being implemented on a given + user object implementing a callback interface. If specs extending an existing + callback interface, we probably want to be able to avoid calling the + operations that aren't implemented (and having some default behavior instead). + So we should perhaps define a term that means whether the operation is + implemented, which in the ECMAScript binding would correspond to checking + for the property's existence. +

+ +
+ + Specification authors wanting to define APIs that take ECMAScript objects + as “property bag” like function arguments are suggested to use + dictionary types rather than + [=callback interfaces=]. + + For example, instead of this: + +
+        callback interface Options {
+          attribute DOMString? option1;
+          attribute DOMString? option2;
+          attribute long? option3;
+        };
+        
+        interface A {
+          void doTask(DOMString type, Options options);
+        };
+    
+ + to be used like this: + +
+        var a = getA();  // Get an instance of A.
+        
+        a.doTask("something", { option1: "banana", option3: 100 });
+    
+ + instead write the following: + +
+        dictionary Options {
+          DOMString? option1;
+          DOMString? option2;
+          long? option3;
+        };
+        
+        interface A {
+          void doTask(DOMString type, Options options);
+        };
+    
+
+ +The IDL for interfaces can be split into multiple parts by using +partial interface definitions +(matching partial PartialInterface). +The [=identifier=] of a partial +interface definition must be the same +as the identifier of an interface definition. All of +the members that appear on each of the partial interfaces are considered to be +members of the interface itself. + +
+    interface SomeInterface {
+      /* interface_members... */
+    };
+    
+    partial interface SomeInterface {
+      /* interface_members... */
+    };
+
+ +Note: Partial interface definitions are intended for use as a specification +editorial aide, allowing the definition of an interface to be separated +over more than one section of the document, and sometimes multiple documents. + +The order of appearance of an [=interface=] +definition and any of its [=partial interface=] +definitions does not matter. + +Note: A partial interface definition cannot specify that the interface +[=interface/inherits=] from another interface. +Inheritance must be specified on the original [=interface=] +definition. + +[=Extended attributes=] can be specified on +[=partial interface=] definitions, with some +limitations. The following extended attributes must not +be specified on partial interface definitions: +[{{Constructor}}], +[{{ImplicitThis}}], +[{{LegacyArrayClass}}], +[{{NamedConstructor}}], +[{{NoInterfaceObject}}]. + +Note: The above list of [=extended attributes=] +is all of those defined in this document that are applicable to +[=interfaces=] except for +[{{Exposed}}], +[{{Global}}], +[{{OverrideBuiltins}}], +[{{PrimaryGlobal}}], +[{{SecureContext}}] and +[{{Unforgeable}}]. + +Any [=extended attribute=] specified +on a [=partial interface=] definition +is considered to appear on the [=interface=] +itself. + +The relevant language binding determines how interfaces correspond to constructs +in the language. + +The following extended attributes are applicable to interfaces: +[{{Constructor}}], +[{{Exposed}}], +[{{Global}}], +[{{ImplicitThis}}], +[{{LegacyArrayClass}}], +[{{NamedConstructor}}], +[{{NoInterfaceObject}}], +[{{OverrideBuiltins}}], +[{{PrimaryGlobal}}], +[{{SecureContext}}], +[{{Unforgeable}}]. + +
+ +
+    CallbackRestOrInterface :
+        CallbackRest
+        Interface
+
+ +
+    Interface :
+        "interface" identifier Inheritance "{" InterfaceMembers "}" ";"
+
+ +
+    Partial :
+        "partial" PartialDefinition
+
+ +
+    PartialDefinition :
+        PartialInterface
+        PartialDictionary
+        Namespace
+
+ +
+    PartialInterface :
+        "interface" identifier "{" InterfaceMembers "}" ";"
+
+ +
+    InterfaceMembers :
+        ExtendedAttributeList InterfaceMember InterfaceMembers
+        ε
+
+ +
+    InterfaceMember :
+        Const
+        Operation
+        Serializer
+        Stringifier
+        StaticMember
+        Iterable
+        ReadOnlyMember
+        ReadWriteAttribute
+        ReadWriteMaplike
+        ReadWriteSetlike
+
+ +
+    Inheritance :
+        ":" identifier
+        ε
+
+ +
+ + The following [=IDL fragment=] + demonstrates the definition of two mutually referential [=interfaces=]. + Both Human and Dog + inherit from Animal. Objects that implement + either of those two interfaces will thus have a name attribute. + +
+        interface Animal {
+          attribute DOMString name;
+        };
+        
+        interface Human : Animal {
+          attribute Dog? pet;
+        };
+        
+        interface Dog : Animal {
+          attribute Human? owner;
+        };
+    
+
+ +
+ + The following [=IDL fragment=] defines + simplified versions of a few DOM [=interfaces=], one of which + is a [=callback interface=]. + +
+        interface Node {
+          readonly attribute DOMString nodeName;
+          readonly attribute Node? parentNode;
+          Node appendChild(Node newChild);
+          void addEventListener(DOMString type, EventListener listener);
+        };
+        
+        callback interface EventListener {
+          void handleEvent(Event event);
+        };
+    
+ + Since the EventListener interface is annotated + callback interface, [=user objects=] + can implement it: + +
+        var node = getNode();                                // Obtain an instance of Node.
+        
+        var listener = {
+          handleEvent: function(event) {
+            // ...
+          }
+        };
+        node.addEventListener("click", listener);            // This works.
+        
+        node.addEventListener("click", function() { ... });  // As does this.
+    
+ + It is not possible for a user object to implement Node, however: + +
+        var node = getNode();  // Obtain an instance of Node.
+        
+        var newNode = {
+          nodeName: "span",
+          parentNode: null,
+          appendChild: function(newchild) {
+            // ...
+          },
+          addEventListener: function(type, listener) {
+            // ...
+          }
+        };
+        node.appendChild(newNode);  // This will throw a TypeError exception.
+    
+
+ + +

Constants

+ +A constant is a declaration (matching +Const) used to bind a constant value to a name. +Constants can appear on [=interfaces=]. + +

+ Constants have in the past primarily been used to define + named integer codes in the style of an enumeration. The Web platform + is moving away from this design pattern in favor of the use of strings. + Specification authors who wish to define constants are strongly advised to discuss + this on the public-script-coord@w3.org + mailing list before proceeding. +

+ +
const type constant_identifier = 42;
+ +The [=identifier=] of a +[=constant=] +must not be the same as the identifier +of another [=interface member=] +defined on the same interface. +The identifier also must not +be “length”, “name” or “prototype”. + +Note: These three names are the names of properties that exist on all +Function objects. + +The type of a constant (matching ConstType) +must not be any type other than +a [=primitive type=] +or a [=nullable type|nullable=] primitive type. +If an [=identifier=] is used, +it must reference a [=typedef=] +whose type is a primitive type or a nullable primitive type. + +The ConstValue part of a +constant declaration gives the value of the constant, which can be +one of the two boolean literal tokens (true +and false), +the null token, an +integer token, +a float token, +or one of the three special floating point constant values +(-Infinity, Infinity and NaN). + +Note: These values – in addition to strings and the empty sequence – can also be used to specify the +[=dictionary member/default value|default value of a dictionary member=] or [=optional argument/default value|of an optional argument=]. Note that strings and the +empty sequence [] cannot be used as the value of a +[=constant=]. + +The value of the boolean literal tokens true and +false are the IDL {{boolean}} values +true and false. + +The value of an integer token is an integer +whose value is determined as follows: + +
    + 1. Let |S| be the sequence of characters matched by the integer token. + 1. Let |sign| be −1 if |S| begins with U+002D HYPHEN-MINUS ("-"), and 1 otherwise. + 1. Let |base| be the base of the number based on the characters that follow the optional leading U+002D HYPHEN-MINUS ("-") character: +
    + : U+0030 DIGIT ZERO ("0"), U+0058 LATIN CAPITAL LETTER X ("X") + : U+0030 DIGIT ZERO ("0"), U+0078 LATIN SMALL LETTER X ("x") + :: The base is 16. + : U+0030 DIGIT ZERO ("0") + :: The base is 8. + : Otherwise + :: The base is 10. +
    + 1. Let |number| be the result of interpreting all remaining characters following the optional leading U+002D HYPHEN-MINUS ("-") + character and any characters indicating the base as an integer specified in base |base|. + 1. Return |sign| × |number|. +
+ +The type of an integer token is the same +as the type of the constant, dictionary member or optional argument it is being used as the value of. +The value of the integer token must not +lie outside the valid range of values for its type, as given in +[[#idl-types]]. + +

+ The value of a float token is + either an IEEE 754 single-precision floating point number or an IEEE 754 + double-precision floating point number, depending on the type of the + constant, dictionary member or optional argument it is being used as the value for, determined as follows: +

+ +
    + 1. Let |S| be the sequence of characters matched by the float token. + 1. Let |value| be the Mathematical Value that would be obtained if |S| were + parsed as an ECMAScript [=NumericLiteral=]. + 1. If the float token is being + used as the value for a {{float}} or + {{unrestricted float}}, then + the value of the float token + is the IEEE 754 single-precision floating point number closest to + |result|. Otherwise, the float token is being + used as the value for a {{double}} or + {{unrestricted double}}, and + the value of the float token + is the IEEE 754 double-precision floating point number closest to + |result|. + [[!IEEE-754]] +
+ +The value of a constant value specified as +Infinity, -Infinity or NaN is either +an IEEE 754 single-precision floating point number or an IEEE 754 +double-precision floating point number, depending on the type of the +constant, dictionary member or optional argument is is being used as the +value for: + +
+ : Type {{unrestricted float}}, constant value Infinity + :: The value is the IEEE 754 single-precision positive infinity value. + : Type {{unrestricted double}}, constant value Infinity + :: The value is the IEEE 754 double-precision positive infinity value. + : Type {{unrestricted float}}, constant value -Infinity + :: The value is the IEEE 754 single-precision negative infinity value. + : Type {{unrestricted double}}, constant value -Infinity + :: The value is the IEEE 754 double-precision negative infinity value. + : Type {{unrestricted float}}, constant value NaN + :: The value is the IEEE 754 single-precision NaN value with the bit pattern 0x7fc00000. + : Type {{unrestricted double}}, constant value NaN + :: The value is the IEEE 754 double-precision NaN value with the bit pattern 0x7ff8000000000000. +
+ +The type of a float token is the same +as the type of the constant, dictionary member or optional argument it is being used as the value of. The value of the +float token must not +lie outside the valid range of values for its type, as given in +[[#idl-types]]. +Also, Infinity, -Infinity and NaN must not +be used as the value of a {{float}} +or {{double}}. + +The value of the null token is the special +null value that is a member of the +[=nullable types=]. The type of +the null token is the same as the +type of the constant, dictionary member or optional argument it is being used as the value of. + +If |VT| is the type of the value assigned to a constant, and |DT| +is the type of the constant, dictionary member or optional argument itself, then these types must +be compatible, which is the case if |DT| and |VT| are identical, +or |DT| is a [=nullable type=] +whose [=inner type=] is |VT|. + +[=Constants=] are not associated with +particular instances of the [=interface=] +on which they appear. It is language binding specific whether +[=constants=] are exposed on instances. + +
+ + The ECMAScript language binding does however + allow [=constants=] to be accessed + through objects implementing the IDL [=interfaces=] + on which the [=constants=] are declared. + For example, with the following IDL: + +
+        interface A {
+          const short rambaldi = 47;
+        };
+    
+ + the constant value can be accessed in ECMAScript either as + A.rambaldi or instanceOfA.rambaldi. + +
+ +The following extended attributes are applicable to constants: +[{{Exposed}}], +[{{SecureContext}}]. + +
+    Const :
+        "const" ConstType identifier "=" ConstValue ";"
+
+ +
+    ConstValue :
+        BooleanLiteral
+        FloatLiteral
+        integer
+        "null"
+
+ +
+    BooleanLiteral :
+        "true"
+        "false"
+
+ +
+    FloatLiteral :
+        float
+        "-Infinity"
+        "Infinity"
+        "NaN"
+
+ +
+    ConstType :
+        PrimitiveType Null
+        identifier Null
+
+ +
+ + The following [=IDL fragment=] + demonstrates how [=constants=] + of the above types can be defined. + +
+        interface Util {
+          const boolean DEBUG = false;
+          const octet LF = 10;
+          const unsigned long BIT_MASK = 0x0000fc00;
+          const double AVOGADRO = 6.022e23;
+        };
+    
+
+ + +

Attributes

+ +An attribute is an [=interface member=] +(matching +inherit ReadOnly AttributeRest, +static ReadOnly AttributeRest, +stringifier ReadOnly AttributeRest, +or ReadOnly AttributeRest) +that is used to declare data fields with a given type and +[=identifier=] whose value can +be retrieved and (in some cases) changed. There are two kinds of attributes: + +1. [=regular attributes=], which are those + used to declare that objects implementing the [=interface=] + will have a data field member with the given [=identifier=] +
+        interface interface_identifier {
+          attribute type identifier;
+        };
+    
+1. [=static attributes=], which are used + to declare attributes that are not associated with a particular object implementing the interface +
+        interface interface_identifier {
+          static attribute type identifier;
+        };
+    
+ +If an attribute has no static keyword, then it declares a +regular attribute. Otherwise, +it declares a [=static attribute=]. + +The [=identifier=] of an +[=attribute=] +must not be the same as the identifier +of another [=interface member=] +defined on the same [=interface=]. +The identifier of a static attribute must not +be “prototype”. + +The type of the attribute is given by the type (matching Type) +that appears after the attribute keyword. +If the Type is an +[=identifier=] or an identifier followed by ?, +then the identifier must +identify an interface, [=enumeration=], +[=callback function=] or [=typedef=]. + +The type of the attribute, after resolving typedefs, must not be a +[=nullable type|nullable=] or non-nullable version of any of the following types: + +* a sequence type +* a dictionary +* a [=union type=] + that has a nullable or non-nullable sequence type or dictionary + as one of its [=flattened member types=] + +The attribute is read only if the +readonly keyword is used before the attribute keyword. +An object that implements the interface on which a read only attribute +is defined will not allow assignment to that attribute. It is language +binding specific whether assignment is simply disallowed by the language, +ignored or an exception is thrown. + +
+    interface interface_identifier {
+      readonly attribute type identifier;
+    };
+
+ +A [=regular attribute=] +that is not [=read only=] +can be declared to inherit its getter +from an ancestor interface. This can be used to make a read only attribute +in an ancestor interface be writable on a derived interface. An attribute +[=inherit its getter|inherits its getter=] if +its declaration includes inherit in the declaration. +The read only attribute from which the attribute inherits its getter +is the attribute with the same identifier on the closest ancestor interface +of the one on which the inheriting attribute is defined. The attribute +whose getter is being inherited must be +of the same type as the inheriting attribute, and inherit +must not appear on a [=read only=] +attribute or a [=static attribute=]. + +
+    interface Ancestor {
+      readonly attribute TheType theIdentifier;
+    };
+    
+    interface Derived : Ancestor {
+      inherit attribute TheType theIdentifier;
+    };
+
+ +When the stringifier keyword is used +in a [=regular attribute=] +declaration, it indicates that objects implementing the +interface will be stringified to the value of the attribute. See +[[#idl-stringifiers]] for details. + +
+    interface interface_identifier {
+      stringifier attribute DOMString identifier;
+    };
+
+ +

+ If an implementation attempts to get or set the value of an + [=attribute=] on a + [=user object=] + (for example, when a callback object has been supplied to the implementation), + and that attempt results in an exception being thrown, then, unless otherwise specified, that + exception will be propagated to the user code that caused the + implementation to access the attribute. Similarly, if a value + returned from getting the attribute cannot be converted to + an IDL type, then any exception resulting from this will also + be propagated to the user code that resulted in the implementation + attempting to get the value of the attribute. +

+ +The following [=extended attributes=] +are applicable to regular and static attributes: +[{{Clamp}}], +[{{EnforceRange}}], +[{{Exposed}}], +[{{SameObject}}], +[{{SecureContext}}], +[{{TreatNullAs}}]. + +The following [=extended attributes=] +are applicable only to regular attributes: +[{{LenientSetter}}], +[{{LenientThis}}], +[{{PutForwards}}], +[{{Replaceable}}], +[{{Unforgeable}}]. + +
+    ReadOnlyMember :
+        "readonly" ReadOnlyMemberRest
+
+ +
+    ReadOnlyMemberRest :
+        AttributeRest
+        ReadWriteMaplike
+        ReadWriteSetlike
+
+ +
+    ReadWriteAttribute :
+        "inherit" ReadOnly AttributeRest
+        AttributeRest
+
+ +
+    AttributeRest :
+        "attribute" Type AttributeName ";"
+
+ +
+    AttributeName :
+        AttributeNameKeyword
+        identifier
+
+ +
+    AttributeNameKeyword :
+        "required"
+
+ +
+    Inherit :
+        "inherit"
+        ε
+
+ +
+    ReadOnly :
+        "readonly"
+        ε
+
+ +
+ + The following [=IDL fragment=] + demonstrates how [=attributes=] + can be declared on an [=interface=]: + +
+        interface Animal {
+        
+          // A simple attribute that can be set to any string value.
+          readonly attribute DOMString name;
+        
+          // An attribute whose value can be assigned to.
+          attribute unsigned short age;
+        };
+        
+        interface Person : Animal {
+        
+          // An attribute whose getter behavior is inherited from Animal, and need not be
+          // specified in the description of Person.
+          inherit attribute DOMString name;
+        };
+    
+
+ + +

Operations

+ +An operation is an [=interface member=] +(matching static OperationRest, +stringifier OperationRest, +serializer OperationRest, +ReturnType OperationRest or +SpecialOperation) +that defines a behavior that can be invoked on objects implementing the interface. +There are three kinds of operation: + +1. [=regular operations=], which + are those used to declare that objects implementing the + [=interface=] will have a method with + the given [=identifier=] +
+        interface interface_identifier {
+          return_type identifier(/* arguments... */);
+        };
+    
+1. [=special operations=], + which are used to declare special behavior on objects + implementing the interface, such as object indexing and stringification +
+        interface interface_identifier {
+          /* special_keywords... */ return_type identifier(/* arguments... */);
+          /* special_keywords... */ return_type (/* arguments... */);
+        };
+    
+1. [=static operations=], + which are used to declare operations that are not associated with + a particular object implementing the interface +
+        interface interface_identifier {
+          static return_type identifier(/* arguments... */);
+        };
+    
+ +If an operation has an identifier but no static +keyword, then it declares a regular operation. +If the operation has one or more +[=special keywords=] +used in its declaration (that is, any keyword matching +Special, or +the stringifier keyword), +then it declares a special operation. A single operation can declare +both a regular operation and a special operation; +see [[#idl-special-operations]] for details on special operations. +Note that in addition to being [=interface members=], +regular operations can also be [=namespace members=]. + +If an operation has no identifier, +then it must be declared to be a special operation +using one of the special keywords. + +The identifier of a [=regular operation=] or [=static operation=] +must not be the same as the identifier +of a [=constant=] or [=attribute=] +defined on the same [=interface=]. +The identifier of a static operation must not be “prototype”. + +Note: The identifier can be the same +as that of another operation on the interface, however. +This is how operation overloading is specified. + +The [=identifier=] of a [=static operation=] +also must not be the same as the identifier +of a [=regular operation=] +defined on the same [=interface=]. + +The return type of the operation is given +by the type (matching ReturnType) +that appears before the operation’s optional [=identifier=]. +A return type of void indicates that the operation returns no value. +If the return type is an +[=identifier=] followed by ?, +then the identifier must +identify an interface, dictionary, [=enumeration=], +[=callback function=] or [=typedef=]. + +An operation’s arguments (matching ArgumentList) +are given between the parentheses in the declaration. Each individual argument is specified +as a type (matching Type) followed by an [=identifier=] +(matching ArgumentName). + +Note: For expressiveness, the identifier of an operation argument can also be specified +as one of the keywords matching the ArgumentNameKeyword +symbol without needing to escape it. + +If the Type of an operation argument is an identifier +followed by ?, +then the identifier must identify an interface, +[=enumeration=], [=callback function=] +or [=typedef=]. +If the operation argument type is an [=identifier=] +not followed by ?, then the identifier must +identify any one of those definitions or a [=dictionary=]. + +
+    interface interface_identifier {
+      return_type identifier(type identifier, type identifier /* , ... */);
+    };
+
+ +The identifier of each argument must not be the same +as the identifier of another argument in the same operation declaration. + +Each argument can be preceded by a list of +[=extended attributes=] (matching +ExtendedAttributeList), +which can control how a value passed as the argument will be handled in +language bindings. + +
+    interface interface_identifier {
+      return_type identifier([extended_attributes] type identifier, [extended_attributes] type identifier /* , ... */);
+    };
+
+ +
+ + The following [=IDL fragment=] + demonstrates how [=regular operations=] + can be declared on an [=interface=]: + +
+        interface Dimensions {
+          attribute unsigned long width;
+          attribute unsigned long height;
+        };
+        
+        interface Button {
+        
+          // An operation that takes no arguments and returns a boolean.
+          boolean isMouseOver();
+        
+          // Overloaded operations.
+          void setDimensions(Dimensions size);
+          void setDimensions(unsigned long width, unsigned long height);
+        };
+    
+
+ +An operation is considered to be variadic +if the final argument uses the ... token just +after the argument type. Declaring an operation to be variadic indicates that +the operation can be invoked with any number of arguments after that final argument. +Those extra implied formal arguments are of the same type as the final explicit +argument in the operation declaration. The final argument can also be omitted +when invoking the operation. An argument must not +be declared with the ... token unless it +is the final argument in the operation’s argument list. + +
+    interface interface_identifier {
+      return_type identifier(type... identifier);
+      return_type identifier(type identifier, type... identifier);
+    };
+
+ +[=Extended attributes=] +that [=takes an argument list|take an argument list=] +([{{Constructor}}] and +[{{NamedConstructor}}], of those +defined in this specification) and [=callback functions=] +are also considered to be [=variadic=] +when the ... token is used in their argument lists. + +
+ + The following [=IDL fragment=] defines an interface that has + two variadic operations: + +
+        interface IntegerSet {
+          readonly attribute unsigned long cardinality;
+        
+          void union(long... ints);
+          void intersection(long... ints);
+        };
+    
+ + In the ECMAScript binding, variadic operations are implemented by + functions that can accept the subsequent arguments: + +
+        var s = getIntegerSet();  // Obtain an instance of IntegerSet.
+        
+        s.union();                // Passing no arguments corresponding to 'ints'.
+        s.union(1, 4, 7);         // Passing three arguments corresponding to 'ints'.
+    
+ + A binding for a language that does not support variadic functions + might specify that an explicit array or list of integers be passed + to such an operation. + +
+ +An argument is considered to be an optional argument +if it is declared with the optional keyword. +The final argument of a [=variadic=] operation +is also considered to be an optional argument. Declaring an argument +to be optional indicates that the argument value can be omitted +when the operation is invoked. The final argument in an +operation must not explicitly be declared to be +optional if the operation is [=variadic=]. + +
+    interface interface_identifier {
+      return_type identifier(type identifier, optional type identifier);
+    };
+
+ +Optional arguments can also have a default value +specified. If the argument’s identifier is followed by a U+003D EQUALS SIGN ("=") +and a value (matching DefaultValue), +then that gives the optional argument its [=optional argument/default value=]. +The implicitly optional final argument of a [=variadic=] +operation must not have a default value specified. +The default value is the value to be assumed when the operation is called with the +corresponding argument omitted. + +
+    interface interface_identifier {
+      return_type identifier(type identifier, optional type identifier = "value");
+    };
+
+ +

+ It is strongly suggested not to use [=optional argument/default value=] + of true for {{boolean}}-typed arguments, + as this can be confusing for authors who might otherwise expect the default + conversion of undefined to be used (i.e., false). +

+ +If the type of an argument is a dictionary type +or a [=union type=] that has a +dictionary type as one of its [=flattened member types=], +and that dictionary type and its ancestors have no [=required dictionary member|required members=], +and the argument is either the final argument or is followed only by +[=optional arguments=], then +the argument must be specified as optional. +Such arguments are always considered to have a +[=optional argument/default value=] of an empty dictionary, +unless otherwise specified. + +
+ + This is to encourage API designs that do not require authors to pass an + empty dictionary value when they wish only to use the dictionary’s + default values. + + Dictionary types cannot have a default value specified explicitly, so the + “unless otherwise specified” clause above can only be invoked for + a [=union type=] that has a + dictionary type as one of its [=flattened member types=]. + +
+ +When a boolean literal token (true or false), +the null token, +an integer token, a +float token or one of +the three special floating point literal values (Infinity, +-Infinity or NaN) is used as the +[=optional argument/default value=], +it is interpreted in the same way as for a [=constant=]. + +

+ Optional argument default values can also be specified using a string + token, whose value is a [=string type=] + determined as follows: +

+ +
    + 1. Let |S| be the sequence of [=Unicode scalar values=] matched by + the string token + with its leading and trailing U+0022 QUOTATION MARK ('"') characters removed. + 1. Depending on the type of the argument: +
    + : {{DOMString}} + : an [=enumeration=] type + :: The value of the string token + is the sequence of 16 bit unsigned integer code units + (hereafter referred to just as code units) + corresponding to the UTF-16 encoding of |S|. + : {{ByteString}} + :: The value of the string token + is the sequence of 8 bit unsigned integer code units + corresponding to the UTF-8 encoding of |S|. + : {{USVString}} + :: The value of the string token is |S|. +
    +
+ +If the type of the [=optional argument=] +is an [=enumeration=], then its +[=optional argument/default value=] if specified must +be one of the [=enumeration values|enumeration’s values=]. + +Optional argument default values can also be specified using the +two token value [], which represents an empty sequence +value. The type of this value is the same the type of the optional +argument it is being used as the default value of. That type +must be a +sequence type or a +[=nullable type=]. + +
+ + The following [=IDL fragment=] + defines an [=interface=] + with a single [=operation=] + that can be invoked with two different argument list lengths: + +
+        interface ColorCreator {
+          object createColor(double v1, double v2, double v3, optional double alpha);
+        };
+    
+ + It is equivalent to an [=interface=] + that has two [=overloaded=] + [=operations=]: + +
+        interface ColorCreator {
+          object createColor(double v1, double v2, double v3);
+          object createColor(double v1, double v2, double v3, double alpha);
+        };
+    
+
+ +

+ If an implementation attempts to invoke + an [=operation=] on a [=user object=] + (for example, when a callback object has been supplied to the implementation), + and that attempt results in an exception being thrown, then, + unless otherwise specified, + that exception will be propagated to + the user code that caused the implementation to invoke the operation. + Similarly, if a value returned from invoking the operation + cannot be converted to an IDL type, + then any exception resulting from this will also + be propagated to the user code + that resulted in the implementation attempting to invoke the operation. +

+ +The following extended attributes are applicable to operations: +[{{Exposed}}], +[{{NewObject}}], +[{{SecureContext}}], +[{{TreatNullAs}}], +[{{Unforgeable}}]. + +The following extended attributes are applicable to operation arguments: +[{{Clamp}}], +[{{EnforceRange}}], +[{{TreatNullAs}}]. + +
+    DefaultValue :
+        ConstValue
+        string
+        "[" "]"
+
+ +
+    Operation :
+        ReturnType OperationRest
+        SpecialOperation
+
+ +
+    SpecialOperation :
+        Special Specials ReturnType OperationRest
+
+ +
+    Specials :
+        Special Specials
+        ε
+
+ +
+    Special :
+        "getter"
+        "setter"
+        "deleter"
+        "legacycaller"
+
+ +
+    OperationRest :
+        OptionalIdentifier "(" ArgumentList ")" ";"
+
+ +
+    OptionalIdentifier :
+        identifier
+        ε
+
+ +
+    ArgumentList :
+        Argument Arguments
+        ε
+
+ +
+    Arguments :
+        "," Argument Arguments
+        ε
+
+ +
+    Argument :
+        ExtendedAttributeList OptionalOrRequiredArgument
+
+ +
+    OptionalOrRequiredArgument :
+        "optional" Type ArgumentName Default
+        Type Ellipsis ArgumentName
+
+ +
+    ArgumentName :
+        ArgumentNameKeyword
+        identifier
+
+ +
+    Ellipsis :
+        "..."
+        ε
+
+ +
+ +
+    ReturnType :
+        Type
+        "void"
+
+ + +

Special operations

+ +A special operation is a +declaration of a certain kind of special behavior on objects implementing +the interface on which the special operation declarations appear. +Special operations are declared by using one or more +special keywords +in an operation declaration. + +There are six kinds of special operations. The table below indicates +for a given kind of special operation what special keyword +is used to declare it and what the purpose of the special operation is: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Special operationKeywordPurpose
GettersgetterDefines behavior for when an object is indexed for property retrieval.
SetterssetterDefines behavior for when an object is indexed for property + assignment or creation.
DeletersdeleterDefines behavior for when an object is indexed for property deletion.
Legacy callerslegacycallerDefines behavior for when an object is called as if it were a function.
StringifiersstringifierDefines how an object is converted into a {{DOMString}}.
SerializersserializerDefines how an object is converted into a serialized form.
+ +Not all language bindings support all of the six kinds of special +object behavior. When special operations are declared using +operations with no identifier, then in language bindings that do +not support the particular kind of special operations there simply +will not be such functionality. + +
+ + The following IDL fragment defines an interface with a getter and a setter: + +
+        interface Dictionary {
+          readonly attribute unsigned long propertyCount;
+        
+          getter double (DOMString propertyName);
+          setter void (DOMString propertyName, double propertyValue);
+        };
+    
+ + In language bindings that do not support property getters and setters, + objects implementing [=Dictionary=] will not + have that special behavior. + +
+ +Defining a special operation with an [=identifier=] +is equivalent to separating the special operation out into its own +declaration without an identifier. This approach is allowed to +simplify prose descriptions of an interface’s operations. + +
+ + The following two interfaces are equivalent: + +
+        interface Dictionary {
+          readonly attribute unsigned long propertyCount;
+        
+          getter double getProperty(DOMString propertyName);
+          setter void setProperty(DOMString propertyName, double propertyValue);
+        };
+    
+
+        interface Dictionary {
+          readonly attribute unsigned long propertyCount;
+        
+          double getProperty(DOMString propertyName);
+          void setProperty(DOMString propertyName, double propertyValue);
+        
+          getter double (DOMString propertyName);
+          setter void (DOMString propertyName, double propertyValue);
+        };
+    
+
+ +A given [=special keyword=] must not +appear twice on an operation. + +Getters and setters come in two varieties: ones that +take a {{DOMString}} as a property name, +known as +named property getters and +named property setters, +and ones that take an {{unsigned long}} +as a property index, known as +indexed property getters and +indexed property setters. +There is only one variety of deleter: +named property deleters. +See [[#idl-indexed-properties]] +and [[#idl-named-properties]] +for details. + +On a given [=interface=], +there must exist at most one +stringifier, at most one serializer, at most one +[=named property deleter=], +and at most one of each variety of getter and setter. +Multiple legacy callers can exist on an interface +to specify overloaded calling behavior. + +If an interface has a setter of a given variety, +then it must also have a getter of that +variety. If it has a [=named property deleter=], +then it must also have a +[=named property getter=]. + +Special operations declared using operations must not +be [=variadic=] nor have any +[=optional arguments=]. + +Special operations must not be declared on +[=callback interfaces=]. + +If an object implements more than one [=interface=] +that defines a given special operation, then it is undefined which (if any) +special operation is invoked for that operation. + + +
Legacy callers
+ +When an [=interface=] has one or more +[=legacy callers=], it indicates that objects that implement +the interface can be called as if they were functions. As mentioned above, +legacy callers can be specified using an [=operation=] +declared with the legacycaller keyword. + +
+    interface interface_identifier {
+      legacycaller return_type identifier(/* arguments... */);
+      legacycaller return_type (/* arguments... */);
+    };
+
+ +If multiple legacy callers are specified on an interface, overload resolution +is used to determine which legacy caller is invoked when the object is called +as if it were a function. + +Legacy callers must not be defined to return a +promise type. + +

+ Legacy callers are universally recognised as an undesirable feature. They exist + only so that legacy Web platform features can be specified. Legacy callers + should not be used in specifications unless required to + specify the behavior of legacy APIs, and even then this should be discussed on + the public-script-coord@w3.org + mailing list before proceeding. +

+ +
+ + The following [=IDL fragment=] + defines an [=interface=] + with a [=legacy caller=]. + +
+        interface NumberQuadrupler {
+          // This operation simply returns four times the given number x.
+          legacycaller double compute(double x);
+        };
+    
+ + An ECMAScript implementation supporting this interface would + allow a [=platform object=] + that implements NumberQuadrupler + to be called as a function: + +
+        var f = getNumberQuadrupler();  // Obtain an instance of NumberQuadrupler.
+        
+        f.compute(3);                   // This evaluates to 12.
+        f(3);                           // This also evaluates to 12.
+    
+
+ + +
Stringifiers
+ +When an [=interface=] has a +[=stringifier=], it indicates that objects that implement +the interface have a non-default conversion to a string. As mentioned above, +stringifiers can be specified using an [=operation=] +declared with the stringifier keyword. + +
+    interface interface_identifier {
+      stringifier DOMString identifier();
+      stringifier DOMString ();
+    };
+
+ +If an operation used to declare a stringifier does not have an +[=identifier=], then prose +accompanying the interface must define +the stringification behavior +of the interface. If the operation does have an identifier, +then the object is converted to a string by invoking the +operation to obtain the string. + +Stringifiers declared with operations must +be declared to take zero arguments and return a {{DOMString}}. + +As a shorthand, if the stringifier keyword +is declared using an operation with no identifier, then the +operation’s [=return type=] and +argument list can be omitted. + +
+    interface interface_identifier {
+      stringifier;
+    };
+
+ +
+ + The following two interfaces are equivalent: + +
+        interface A {
+          stringifier DOMString ();
+        };
+    
+
+        interface A {
+          stringifier;
+        };
+    
+
+ +The stringifier keyword +can also be placed on an [=attribute=]. +In this case, the string to convert the object to is the +value of the attribute. The stringifier keyword +must not be placed on an attribute unless +it is declared to be of type {{DOMString}} or {{USVString}}. +It also must not be placed on +a [=static attribute=]. + +
+    interface interface_identifier {
+      stringifier attribute DOMString identifier;
+    };
+
+ +
+    Stringifier :
+        "stringifier" StringifierRest
+
+ +
+    StringifierRest :
+        ReadOnly AttributeRest
+        ReturnType OperationRest
+        ";"
+
+ +
+ + The following [=IDL fragment=] + defines an interface that will stringify to the value of its + name attribute: + +
+        [Constructor]
+        interface Student {
+          attribute unsigned long id;
+          stringifier attribute DOMString name;
+        };
+    
+ + In the ECMAScript binding, using a Student + object in a context where a string is expected will result in the + value of the object’s “name” property being + used: + +
+        var s = new Student();
+        s.id = 12345678;
+        s.name = '周杰倫';
+        
+        var greeting = 'Hello, ' + s + '!';  // Now greeting == 'Hello, 周杰倫!'.
+    
+ + The following [=IDL fragment=] + defines an interface that has custom stringification behavior that is + not specified in the IDL itself. + +
+        [Constructor]
+        interface Student {
+          attribute unsigned long id;
+          attribute DOMString? familyName;
+          attribute DOMString givenName;
+        
+          stringifier DOMString ();
+        };
+    
+ + Thus, prose is required to explain the stringification behavior, such + as the following paragraph: + +
+ + Objects that implement the Student + interface must stringify as follows. If the value of the + familyName attribute is + null, the stringification of the + object is the value of the givenName + attribute. Otherwise, if the value of the + familyName attribute is not null, + the stringification of the object is the concatenation of the + value of the givenName attribute, + a single space character, and the value of + the familyName attribute. + +
+ + An ECMAScript implementation of the IDL would behave as follows: + +
+        var s = new Student();
+        s.id = 12345679;
+        s.familyName = 'Smithee';
+        s.givenName = 'Alan';
+        
+        var greeting = 'Hi ' + s;  // Now greeting == 'Hi Alan Smithee'.
+    
+
+ + +
Serializers
+ +When an [=interface=] has a +[=serializer=], it indicates that objects provide +a way for them to be converted into a serialized form. Serializers can be declared +using the serializer keyword: + +
+    interface interface_identifier {
+      serializer;
+    };
+
+ +Prose accompanying an interface that declares a serializer in this +way must define the +serialization behavior +of the interface. Serialization behavior is defined as returning +a serialized value of one of the following types: + +* a map of key–value pairs, where the keys are + {{DOMString}} values (unique in the map) and the + values are [=serialized values=] +* a list of [=serialized values=] +* a {{DOMString}} value +* an {{unrestricted double}} value +* a {{boolean}} value +* the null value + +How the [=serialization behavior=] +is made available on an object in a language binding, and how exactly the abstract +[=serialized value=] is converted into +an appropriate concrete value, is language binding specific. + +Note: In the ECMAScript language binding, +[=serialization behavior=] +is exposed as a toJSON method which returns the +[=serialized value=] converted +into an ECMAScript value that can be serialized to JSON by the +JSON.stringify function. See [[#es-serializer]] for details. + +[=Serialization behavior=] +can also be specified directly in IDL, rather than separately as prose. +This is done by following the serializer keyword with +a U+003D EQUALS SIGN ("=") character and +a serialization pattern, +which can take one of the following six forms: + +* A map with entries corresponding to zero or more attributes from the interface, and optionally + attributes from an inherited interface: + +
+        interface interface_identifier {
+          serializer = { attribute_identifier, attribute_identifier /* , ... */ };
+          serializer = { inherit, attribute_identifier, attribute_identifier /* , ... */ };
+        };
+    
+ + Each identifier must be the identifier of an attribute declared + on the interface. The identified attributes all must have a + [=serializable type=]. + + The inherit keyword must not be used unless + the interface inherits from another that defines a serializer, and the closest such interface + defines its serializer using this [=serialization pattern=] + form or the following form (i.e. { attribute }). + + The [=serialization behavior=] for this + form of serialization pattern is as follows: + +
    + 1. Let |map| be an empty map. + 1. If the inherit keyword was used, then set |map| to be the result of + the [=serialization behavior=] of the + closest inherited interface that declares a serializer. + 1. For each attribute identifier |i| in the serialization pattern, in order: + 1. Remove any entry in |map| with key name |i|. + 1. Let |V| be the value of the attribute with identifier |i|. + 1. Add an entry to |map| whose key name is |i| and whose + value is result of [=converted to a serialized value|converting=] + |V| to a serialized value. + 1. Return |map|. +
+* A map with entries corresponding to all attributes from the interface that have + a [=serializable type=], and optionally + attributes from an inherited interface: + +
+        interface interface_identifier {
+          serializer = { attribute };
+          serializer = { inherit, attribute };
+        };
+    
+ + The inherit keyword must not be used unless + the interface inherits from another that defines a serializer, and the closest such interface + defines its serializer using this [=serialization pattern=] + form or the previous form. + + The [=serialization behavior=] for this + form of serialization pattern is as follows: + +
    + 1. Let |map| be an empty map. + 1. If the inherit keyword was used, then set |map| to be the result of + the [=serialization behavior=] of the + closest inherited interface that declares a serializer. + 1. For each identifier |i| of an attribute on the interface whose type is + a [=serializable type=], in the order they appear + on the interface: + 1. Remove any entry in |map| with key name |i|. + 1. Let |V| be the value of the attribute with identifier |i|. + 1. Add an entry to |map| whose key name is |i| and whose + value is result of [=converted to a serialized value|converting=] + |V| to a serialized value. + 1. Return |map|. +
+* A map with entries corresponding to the named properties: + +
+        interface interface_identifier {
+          serializer = { getter };
+        };
+    
+ + This form must not be used unless the interface or one it + inherits from supports named properties and the return type of the named property getter + is a serializable type. + + The [=serialization behavior=] for this + form of serialization pattern is as follows: + +
    + 1. Let |map| be an empty map. + 1. For each supported property name |n| on the object, in order: + 1. Let |V| be the value of the named property with name |n|. + 1. Add an entry to |map| whose key name is |i| and whose + value is result of [=converted to a serialized value|converting=] + |V| to a serialized value. + 1. Return |map|. +
+* A list of value of zero or more attributes on the interface: + +
+        interface interface_identifier {
+          serializer = [ attribute_identifier, attribute_identifier /* , ... */ ];
+        };
+    
+ + Each identifier must be the identifier of an attribute declared + on the interface. The identified attributes all must have a + [=serializable type=]. + + The [=serialization behavior=] for this + form of serialization pattern is as follows: + +
    + 1. Let |list| be an empty list. + 1. For each attribute identifier |i| in the serialization pattern: + 1. Let |V| be the value of the attribute with identifier |i|. + 1. Append to |list| the value that is the result of + [=converted to a serialized value|converting=] + |V| to a serialized value. + 1. Return |list|. +
+* A list with entries corresponding to the indexed properties: + +
+        interface interface_identifier {
+          serializer = [ getter ];
+        };
+    
+ + This form must not be used unless the interface or one it + inherits from supports indexed properties and the return type of the indexed property getter + is a serializable type. + + The [=serialization behavior=] for this + form of serialization pattern is as follows: + +
    + 1. Let |list| be an empty list. + 1. Let |i| be 0. + 1. While |i| is less than or equal to the greatest supported property index on the object: + 1. Let |V| be the value of the indexed property with index |i| + if |i| is a supported property index, or null otherwise. + 1. Append to |list| the value that is the result of + [=converted to a serialized value|converting=] + |V| to a serialized value. + 1. Set |i| to |i| + 1. + 1. Return |map|. +
+* A single attribute: + +
+        interface interface_identifier {
+          serializer = attribute_identifier;
+        };
+    
+ + The identifier must be the identifier of an attribute declared + on the interface, and this attribute must have a + [=serializable type=]. + + The [=serialization behavior=] for this + form of serialization pattern is as follows: + +
    + 1. Let |V| be the value of the attribute with the specified identifier. + 1. Return the result of [=converted to a serialized value|converting=] + |V| to a serialized value. +
+ +Note: Entries are added to maps in a particular order so that in the ECMAScript language binding +it is defined what order properties are added to objects. This is because this order +can influence the serialization that JSON.stringify can produce. + +The list of serializable types and how they are +converted to serialized values is as follows: + +
+ : {{long long}} + :: converted by choosing the closest equivalent {{double}} value + (as when converting a long long to an ECMAScript Number value) + : {{unsigned long long}} + :: converted by choosing the closest equivalent {{double}} value + (as when converting a unsigned long long to an ECMAScript Number value) + : any other [=integer type=] + : {{float}} + :: converted by choosing the equivalent {{double}} value + : {{double}} + : {{boolean}} + : {{DOMString}} + :: the same value of the respective type + : an [=enumeration|enumeration type=] + :: the equivalent {{DOMString}} value + : a {{USVString}} + :: the {{DOMString}} produced by + encoding the given sequence of [=Unicode scalar values=] in + UTF-16 + : a {{ByteString}} + :: the equivalent {{DOMString}} value where each code unit has the same value as the corresponding byte value + : a [=nullable type|nullable=] serializable type + :: converted to null if that is its value, + otherwise converted as per its [=inner type=] + : a [=union type=] where all of its [=member types=] are serializable types + :: converted as per its [=specific type=] + : a sequence type that has a serializable type as its element type + :: converted to a list where each element is the result of converting its + corresponding sequence element to a serialized value + : a [=dictionary=] where all of its [=dictionary members|members=] have serializable types + :: converted to a map consisting of an entry for each dictionary member + that is present, where the entry’s key is the identifier of the dictionary + member and its value is the result of converting the dictionary member’s + value to a serializable type + : an interface type that has a [=serializer=] + :: converted by invoking the object’s serializer +
+ +Serializers can also be specified using an [=operation=] +with the serializer keyword: + +
+    interface interface_identifier {
+      serializer identifier();
+    };
+
+ +Serializers declared with operations must +be declared to take zero arguments and return a [=serializable type=]. + +The [=serialization behavior=] +of the interface with a serializer declared with an operation is the result of +[=converted to a serialized value|converting=] +the value returned from invoking the operation to a serialized value. + +
+    Serializer :
+        "serializer" SerializerRest
+
+ +
+    SerializerRest :
+        OperationRest
+        "=" SerializationPattern ";"
+        ";"
+
+ +
+    SerializationPattern :
+        "{" SerializationPatternMap "}"
+        "[" SerializationPatternList "]"
+        identifier
+
+ +
+    SerializationPatternMap :
+        "getter"
+        "inherit" Identifiers
+        identifier Identifiers
+        ε
+
+ +
+    SerializationPatternList :
+        "getter"
+        identifier Identifiers
+        ε
+
+ +
+    Identifiers :
+        "," identifier Identifiers
+        ε
+
+ +
+ + The following [=IDL fragment=] defines + an interface Transaction that has a + [=serializer=] defines in prose: + +
+        interface Transaction {
+          readonly attribute Account from;
+          readonly attribute Account to;
+          readonly attribute double amount;
+          readonly attribute DOMString description;
+          readonly attribute unsigned long number;
+        
+          serializer;
+        };
+        
+        interface Account {
+          attribute DOMString name;
+          attribute unsigned long number;
+        };
+    
+ + The serializer could be defined as follows: + +
+ + The [=serialization behavior=] + of the Transaction interface is to run the following + algorithm, where |O| is the object that implements Transaction: + +
    + 1. Let |map| be an empty map. + 1. Add an entry to |map| whose key is “from” and whose value is + the [=serialized value=] of + the number attribute on the Account + object referenced by the from attribute on |O|. + 1. Add an entry to |map| whose key is “to” and whose value is + the [=serialized value=] of + the number attribute on the Account + object referenced by the from attribute on |O|. + 1. For both of the attributes amount and description, + add an entry to |map| whose key is the + [=identifier=] of the attribute + and whose value is the [=serialized value=] + of the value of the attribute on |O|. + 1. Return |map|. +
+
+ + If it was acceptable for Account objects to be serializable + on their own, then [=serialization patterns=] + could be used to avoid having to define the [=serialization behavior=] + in prose: + +
+        interface Transaction {
+          readonly attribute Account from;
+          readonly attribute Account to;
+          readonly attribute double amount;
+          readonly attribute DOMString description;
+          readonly attribute unsigned long number;
+        
+          serializer = { from, to, amount, description };
+        };
+        
+        interface Account {
+          attribute DOMString name;
+          attribute unsigned long number;
+        
+          serializer = number;
+        };
+    
+ + In the ECMAScript language binding, there would exist a toJSON method on + Transaction objects: + +
+        // Get an instance of Transaction.
+        var txn = getTransaction();
+        
+        // Evaluates to an object like this:
+        // {
+        //   from: 1234
+        //   to: 5678
+        //   amount: 110.75
+        //   description: "dinner"
+        // }
+        txn.toJSON();
+        
+        // Evaluates to a string like this:
+        // '{"from":1234,"to":5678,"amount":110.75,"description":"dinner"}'
+        JSON.stringify(txn);
+    
+
+ + +
Indexed properties
+ +An [=interface=] that defines +an [=indexed property getter=] +is said to support indexed properties. + +If an interface [=support indexed properties|supports indexed properties=], +then the interface definition must be accompanied by +a description of what indices the object can be indexed with at +any given time. These indices are called the supported property indices. + +Indexed property getters must +be declared to take a single {{unsigned long}} argument. +Indexed property setters must +be declared to take two arguments, where the first is an {{unsigned long}}. + +
+    interface interface_identifier {
+      getter type identifier(unsigned long identifier);
+      setter type identifier(unsigned long identifier, type identifier);
+    
+      getter type (unsigned long identifier);
+      setter type (unsigned long identifier, type identifier);
+    };
+
+ +The following requirements apply to the definitions of indexed property getters and setters: + +* If an [=indexed property getter=] was specified using an [=operation=] + with an [=identifier=], + then the value returned when indexing the object with a given [=supported property indices|supported property index=] + is the value that would be returned by invoking the operation, passing + the index as its only argument. If the operation used to declare the indexed property getter + did not have an identifier, then the interface definition must be accompanied + by a description of how to determine the value of an indexed property + for a given index. +* If an [=indexed property setter=] was specified using an operation + with an identifier, + then the behavior that occurs when indexing the object for property assignment with a given supported property index and value + is the same as if the operation is invoked, passing + the index as the first argument and the value as the second argument. If the operation used to declare the indexed property setter + did not have an identifier, then the interface definition must be accompanied + by a description of how to set the value of an existing indexed property + and how to set the value of a new indexed property + for a given property index and value. + +
+ + Note that if an [=indexed property getter=] or + [=indexed property setters|setter=] + is specified using an [=operation=] with an [=identifier=], + then indexing an object with an integer that is not a [=supported property indices|supported property index=] + does not necessarily elicit the same behavior as invoking the operation with that index. The actual behavior in this + case is language binding specific. + + In the ECMAScript language binding, a regular property lookup is done. For example, take the following IDL: + +
+        interface A {
+          getter DOMString toWord(unsigned long index);
+        };
+    
+ + Assume that an object implementing A has [=supported property indices=] + in the range 0 ≤ |index| < 2. Also assume that toWord is defined to return + its argument converted into an English word. The behavior when invoking the + [=operation=] with an out of range index + is different from indexing the object directly: + +
+        var a = getA();
+        
+        a.toWord(0);  // Evalautes to "zero".
+        a[0];         // Also evaluates to "zero".
+        
+        a.toWord(5);  // Evaluates to "five".
+        a[5];         // Evaluates to undefined, since there is no property "5".
+    
+
+ +
+ + The following [=IDL fragment=] defines an interface + OrderedMap which allows + retrieving and setting values by name or by index number: + +
+        interface OrderedMap {
+          readonly attribute unsigned long size;
+        
+          getter any getByIndex(unsigned long index);
+          setter void setByIndex(unsigned long index, any value);
+        
+          getter any get(DOMString name);
+          setter void set(DOMString name, any value);
+        };
+    
+ + Since all of the special operations are declared using + operations with identifiers, the only additional prose + that is necessary is that which describes what keys those sets + have. Assuming that the get() operation is + defined to return null if an + attempt is made to look up a non-existing entry in the + OrderedMap, then the following + two sentences would suffice: + +
+ + An object |map| implementing OrderedMap + supports indexed properties with indices in the range + 0 ≤ |index| < map.size. + + Such objects also support a named property for every name that, + if passed to get(), would return a non-null value. + +
+ + As described in [[#es-platform-objects]], + an ECMAScript implementation would create + properties on a [=platform object=] implementing + OrderedMap that correspond to + entries in both the named and indexed property sets. + These properties can then be used to interact + with the object in the same way as invoking the object’s + methods, as demonstrated below: + +
+        // Assume map is a platform object implementing the OrderedMap interface.
+        var map = getOrderedMap();
+        var x, y;
+        
+        x = map[0];       // If map.length > 0, then this is equivalent to:
+                          //
+                          //   x = map.getByIndex(0)
+                          //
+                          // since a property named "0" will have been placed on map.
+                          // Otherwise, x will be set to undefined, since there will be
+                          // no property named "0" on map.
+        
+        map[1] = false;   // This will do the equivalent of:
+                          //
+                          //   map.setByIndex(1, false)
+        
+        y = map.apple;    // If there exists a named property named "apple", then this
+                          // will be equivalent to:
+                          //
+                          //   y = map.get('apple')
+                          //
+                          // since a property named "apple" will have been placed on
+                          // map.  Otherwise, y will be set to undefined, since there
+                          // will be no property named "apple" on map.
+        
+        map.berry = 123;  // This will do the equivalent of:
+                          //
+                          //   map.set('berry', 123)
+        
+        delete map.cake;  // If a named property named "cake" exists, then the "cake"
+                          // property will be deleted, and then the equivalent to the
+                          // following will be performed:
+                          //
+                          //   map.remove("cake")
+    
+
+ + +
Named properties
+ +An [=interface=] that defines +a [=named property getter=] +is said to support named properties. + +If an interface [=support named properties|supports named properties=], +then the interface definition must be accompanied by +a description of the ordered set of names that can be used to index the object +at any given time. These names are called the +supported property names. + +Named property getters and deleters must +be declared to take a single {{DOMString}} argument. +Named property setters must +be declared to take two arguments, where the first is a {{DOMString}}. + +
+    interface interface_identifier {
+      getter type identifier(DOMString identifier);
+      setter type identifier(DOMString identifier, type identifier);
+      deleter type identifier(DOMString identifier);
+    
+      getter type (DOMString identifier);
+      setter type (DOMString identifier, type identifier);
+      deleter type (DOMString identifier);
+    };
+
+ +The following requirements apply to the definitions of named property getters, setters and deleters: + +* If a [=named property getter=] was specified using an [=operation=] + with an [=identifier=], + then the value returned when indexing the object with a given [=supported property name=] + is the value that would be returned by invoking the operation, passing + the name as its only argument. If the operation used to declare the named property getter + did not have an identifier, then the interface definition must be accompanied + by a description of how to determine the value of a named property + for a given property name. +* If a [=named property setter=] was specified using an operation + with an identifier, + then the behavior that occurs when indexing the object for property assignment with a given supported property name and value + is the same as if the operation is invoked, passing + the name as the first argument and the value as the second argument. If the operation used to declare the named property setter + did not have an identifier, then the interface definition must be accompanied + by a description of how to set the value of an existing named property + and how to set the value of a new named property + for a given property name and value. +* If a [=named property deleter=] was specified using an operation + with an identifier, + then the behavior that occurs when indexing the object for property deletion with a given supported property name + is the same as if the operation is invoked, passing + the name as the only argument. If the operation used to declare the named property deleter + did not have an identifier, then the interface definition must be accompanied + by a description of how to delete an existing named property + for a given property name. + +Note: As with indexed properties, +if an [=named property getter=], +[=named property setters|setter=] or +[=named property deleters|deleter=] +is specified using an [=operation=] with an [=identifier=], +then indexing an object with a name that is not a [=supported property name=] +does not necessarily elicit the same behavior as invoking the operation with that name; the behavior +is language binding specific. + + +

Static attributes and operations

+ +Static attributes and +static operations are ones that +are not associated with a particular instance of the +[=interface=] +on which it is declared, and is instead associated with the interface +itself. Static attributes and operations are declared by using the +static keyword in their declarations. + +It is language binding specific whether it is possible to invoke +a static operation or get or set a static attribute through a reference +to an instance of the interface. + +Static attributes and operations must not be +declared on [=callback interfaces=]. + +
+    StaticMember :
+        "static" StaticMemberRest
+
+ +
+    StaticMemberRest :
+        ReadOnly AttributeRest
+        ReturnType OperationRest
+
+ +
+ + The following [=IDL fragment=] defines an interface + Circle that has a static + operation declared on it: + +
+        interface Point { /* ... */ };
+        
+        interface Circle {
+          attribute double cx;
+          attribute double cy;
+          attribute double radius;
+        
+          static readonly attribute long triangulationCount;
+          static Point triangulate(Circle c1, Circle c2, Circle c3);
+        };
+    
+ + In the ECMAScript language binding, the Function object for + triangulate and the accessor property for triangulationCount + will exist on the [=interface object=] + for Circle: + +
+        var circles = getCircles();           // an Array of Circle objects
+        
+        typeof Circle.triangulate;            // Evaluates to "function"
+        typeof Circle.triangulationCount;     // Evaluates to "number"
+        Circle.prototype.triangulate;         // Evaluates to undefined
+        Circle.prototype.triangulationCount;  // Also evaluates to undefined
+        circles[0].triangulate;               // As does this
+        circles[0].triangulationCount;        // And this
+        
+        // Call the static operation
+        var triangulationPoint = Circle.triangulate(circles[0], circles[1], circles[2]);
+        
+        // Find out how many triangulations we have done
+        window.alert(Circle.triangulationCount);
+    
+
+ + +

Overloading

+ +If a [=regular operation=] +or [=static operation=] +defined on an [=interface=] +has an [=identifier=] +that is the same as the identifier of another operation on that +interface of the same kind (regular or static), then the operation is said to be +overloaded. When the identifier +of an overloaded operation is used to invoke one of the +operations on an object that implements the interface, the +number and types of the arguments passed to the operation +determine which of the overloaded operations is actually +invoked. If an interface has multiple +[=legacy callers=] defined on it, +then those legacy callers are also said to be overloaded. +In the ECMAScript language binding, constructors +can be overloaded too. There are some restrictions on the arguments +that overloaded operations, legacy callers and constructors can be +specified to take, and in order to describe these restrictions, +the notion of an effective overload set is used. + +[=Operations=] and [=legacy callers=] +must not be overloaded across [=interface=] +and [=partial interface=] definitions. + +
+ + For example, the overloads for both |f| and |g| + are disallowed: + +
+        interface A {
+          void f();
+        };
+        
+        partial interface A {
+          void f(double x);
+          void g();
+        };
+        
+        partial interface A {
+          void g(DOMString x);
+        };
+    
+ + Note that the [{{Constructor}}] and + [{{NamedConstructor}}] + [=extended attributes=] are disallowed from appearing + on [=partial interface=] definitions, + so there is no need to also disallow overloading for constructors. + +
+ +An effective overload set +represents the allowable invocations for a particular +[=operation=], +constructor (specified with [{{Constructor}}] +or [{{NamedConstructor}}]), +[=legacy caller=] or +[=callback function=]. +The algorithm to compute an [=effective overload set=] +operates on one of the following six types of IDL constructs, and listed with them below are +the inputs to the algorithm needed to compute the set. + + : For regular operations + : For static operations + :: * the [=interface=] on which the [=operations=] are to be found + * the [=identifier=] of the operations + * the number of arguments to be passed + : For legacy callers + :: * the [=interface=] on which the [=legacy callers=] are to be found + * the number of arguments to be passed + : For constructors + :: * the [=interface=] on which the [Constructor] [=extended attributes=] are to be found + * the number of arguments to be passed + : For named constructors + :: * the [=interface=] on which the [NamedConstructor] [=extended attributes=] are to be found + * the [=identifier=] of the named constructors + * the number of arguments to be passed + : For callback functions + :: * the [=callback function=] + * the number of arguments to be passed + +An effective overload set is used, among other things, to determine whether there are ambiguities in the +overloaded operations, constructors and callers specified on an interface. + +The elements of an effective overload set are tuples of the form +<|callable|, |type list|, |optionality list|>. If the effective overload +set is for regular operations, static operations or legacy callers, then |callable| is an operation; +if it is for constructors or named constructors, then |callable| is an +extended attribute; and if it is for callback functions, then |callable| +is the callback function itself. In all cases, |type list| is a list +of IDL types, and |optionality list| is a list of three possible optionality values – +“required”, “optional” or “variadic” – indicating whether +the argument at a given index was declared as being [=optional argument|optional=] +or corresponds to a [=variadic=] argument. +Each tuple represents an allowable invocation of the operation, +constructor, legacy caller or callback function with an argument value list of the given types. +Due to the use of [=optional arguments=] +and [=variadic=] operations +and constructors, there may be multiple entries in an effective overload set identifying +the same operation or constructor. + +The algorithm below describes how to compute an effective overload set. +The following input variables are used, if they are required: + +* the identifier of the operation or named constructor is |A| +* the argument count is |N| +* the interface is |I| +* the callback function is |C| + +Whenever an argument of an extended +attribute is mentioned, it is referring to an argument of the +extended attribute’s [=takes a named argument list|named argument list=]. + +
    + 1. Initialize |S| to ∅. + 1. Let |F| be a set with elements as follows, according to the kind of effective overload set: +
    + : For regular operations + :: The elements of |F| are the [=regular operations=] with + identifier |A| defined on interface |I|. + : For static operations + :: The elements of |F| are the [=static operations=] with + identifier |A| defined on interface |I|. + : For constructors + :: The elements of |F| are the + [{{Constructor}}] + [=extended attributes=] on interface |I|. + : For named constructors + :: The elements of |F| are the + [{{NamedConstructor}}] + [=extended attributes=] on interface |I| whose + [=takes a named argument list|named argument lists’=] + identifiers are |A|. + : For legacy callers + :: The elements of |F| are the [=legacy callers=] + defined on interface |I|. + : For callback functions + :: The single element of |F| is the callback function itself, |C|. +
    + + 1. Let |maxarg| be the maximum number of arguments the operations, constructor extended attributes or callback functions in |F| are declared to take. + For [=variadic=] operations and constructor extended attributes, + the argument on which the ellipsis appears counts as a single argument. + + Note: So void f(long x, long... y); is considered to be declared to take two arguments. + + 1. Let |m| be the maximum of |maxarg| and |N|. + 1. For each operation, extended attribute or callback function |X| in |F|: + 1. Let |n| be the number of arguments |X| is declared to take. + 1. Let |t|0..|n|−1 be a list of types, where |t||i| + is the type of |X|’s argument at index |i|. + 1. Let |o|0..|n|−1 be a list of [=optionality values=], where |o||i| + is “variadic” if |X|’s argument at index |i| is a final, variadic argument, + “optional” if the argument is [=optional argument|optional=], + and “required” otherwise. + 1. Add to |S| the tuple <|X|, |t|0..|n|−1, |o|0..|n|−1>. + 1. If |X| is declared to be [=variadic=], then: + 1. For every integer |i|, such that |n| ≤ |i| ≤ |m|−1: + 1. Let |u|0..|i| be a list of types, where |u|j = |t|j (for |j| < |n|) and |u|j = |t||n|−1 (for |j| ≥ |n|). + 1. Let |p|0..|i| be a list of [=optionality values=], where |p|j = |o|j (for |j| < |n|) and |p|j = “variadic” (for |j| ≥ |n|). + 1. Add to |S| the tuple <|X|, |u|0..|i|, |p|0..|i|>. + 1. Initialize |i| to |n|−1. + 1. While |i| ≥ 0: + 1. If argument |i| of |X| is not + [=optional argument|optional=] + (i.e., it is not marked as optional and is not + a final, variadic argument), then break this loop. + 1. Otherwise, add to |S| the tuple <|X|, |t|0..|i|−1, |o|0..|i|−1>. + 1. Set |i| to |i|−1. + 1. The effective overload set is |S|. +
+ +
+ + For the following interface: + +
+        interface A {
+          /* f1 */ void f(DOMString a);
+          /* f2 */ void f(Node a, DOMString b, double... c);
+          /* f3 */ void f();
+          /* f4 */ void f(Event a, DOMString b, optional DOMString c, double... d);
+        };
+    
+ + assuming Node and Event + are two other interfaces of which no object can implement both, + the [=effective overload set=] + for [=regular operations=] with + identifier f and argument count 4 is: + +
+      { <f1, (DOMString), (required)>,
+        <f2, (Node, DOMString), (required, required)>,
+        <f2, (Node, DOMString, double), (required, required, variadic)>,
+        <f2, (Node, DOMString, double, double), (required, required, variadic, variadic)>,
+        <f3, (), ()>,
+        <f4, (Event, DOMString), (required, required)>,
+        <f4, (Event, DOMString, DOMString), (required, required, optional)>,
+        <f4, (Event, DOMString, DOMString, double), (required, required, optional, variadic)> }
+    
+
+ +Two types are distinguishable if +at most one of the two [=includes a nullable type=] +or is a dictionary type, +and at least one of the following three conditions is true: + +1. The two types (taking their [=inner types=] + if they are [=nullable types=]) appear + in the following table and there is a “●” mark in the corresponding entry + or there is a letter in the corresponding entry and the designated additional + requirement below the table is satisfied: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ boolean +
+ numeric types +
+ string types +
+ interface +
+ object +
+ callback function +
+ dictionary +
+ sequence<|T|> +
+ FrozenArray<|T|> +
+ RegExp +
+ exception types +
+ buffer source types +
boolean
numeric types
string types
interface(a)(b)(b)
object
callback function
dictionary
sequence<|T|>
FrozenArray<|T|>
RegExp
exception types
buffer source types
+ +
    + 1. The two identified [=interfaces=] are + not the same, it is not possible for a single [=platform object=] + to implement both [=interfaces=], + and it is not the case that both are [=callback interfaces=]. + 1. The interface type is not a [=callback interface=]. +
+1. One type is a [=union type=] or nullable union type, + the other is neither a union type nor a nullable union type, and each + [=member type=] of the first is distinguishable + with the second. +1. Both types are either a union type or nullable union type, and each member type of the one + is distinguishable with each member type of the other. + +Note: Promise types do not appear in the above table, and as a consequence +are not distinguishable with any other type. + +If there is more than one entry in an [=effective overload set=] +that has a given type list length, then for those entries there +must be an index |i| such +that for each pair of entries the types at index |i| are +[=distinguishable=]. +The lowest such index is termed the distinguishing argument index +for the entries of the effective overload set with the given type list length. + +
+ + Consider the effective overload set shown in the previous example. + There are multiple entries in the set with type lists 2, 3 and 4. + For each of these type list lengths, the [=distinguishing argument index=] is 0, since Node and + Event are [=distinguishable=]. + + The following use of overloading however is invalid: + +
+        interface B {
+          void f(DOMString x);
+          void f(double x);
+        };
+    
+ + since {{DOMString}} and + {{double}} are not distinguishable. + +
+ +In addition, for each index |j|, where |j| is less than the +[=distinguishing argument index=] +for a given type list length, the types at index |j| in +all of the entries’ type lists must be the same +and the booleans in the corresponding list indicating argument optionality must +be the same. + +
+ + The following is invalid: + +
+        interface B {
+          /* f1 */ void f(DOMString w);
+          /* f2 */ void f(long w, double x, Node y, Node z);
+          /* f3 */ void f(double w, double x, DOMString y, Node z);
+        };
+    
+ + For argument count 4, the effective overload set is: + +
+      { <f1, (DOMString), (required)>,
+        <f2, (long, double, Node, Node), (required, required, required, required)>,
+        <f3, (double, double, DOMString, Node), (required, required, required, required)> }
+    
+ + Looking at entries with type list length 4, the + [=distinguishing argument index=] + is 2, since Node and + {{DOMString}} are [=distinguishable=]. + However, since the arguments in these two overloads at index 0 are different, + the overloading is invalid. + +
+ + +

Iterable declarations

+ +An [=interface=] can be declared to be +iterable by using an iterable declaration +(matching Iterable) in the body of the interface. + +
+    interface interface_identifier {
+      iterable<value_type>;
+      iterable<key_type, value_type>;
+    };
+
+ +Objects implementing an interface that is declared to be iterable +support being iterated over to obtain a sequence of values. + +Note: In the ECMAScript language binding, an interface that is iterable +will have “entries”, “forEach”, “keys”, “values” and [=@@iterator=] +properties on its [=interface prototype object=]. + +If a single type parameter is given, then the interface has a +value iterator and provides +values of the specified type. +If two type parameters are given, then the interface has a +pair iterator and provides +value pairs, where the first value is a key and the second is the +value associated with the key. + +A [=value iterator=] +must only be declared on an interface +that [=support indexed properties|supports indexed properties=] +and has an [=integer types|integer-typed=] +[=attribute=] named “length”. +The value-type of the [=value iterator=] +must be the same as the type returned by +the [=indexed property getter=]. +A [=value iterator=] is implicitly +defined to iterate over the object’s indexed properties. + +A [=pair iterator=] +must not be declared on an interface +that [=support indexed properties|supports indexed properties=]. +Prose accompanying an interface with a +[=pair iterator=] +must define what the list of +value pairs to iterate over +is. + +
+ + The ECMAScript forEach method that is generated for a + [=value iterator=] + invokes its callback like Array.prototype.forEach does, and the forEach + method for a [=pair iterator=] + invokes its callback like Map.prototype.forEach does. + + Since [=value iterators=] + are currently allowed only on interfaces that + [=support indexed properties=], + it makes sense to use an Array-like forEach method. + There may be a need for [=value iterators=] + (a) on interfaces that do not + [=support indexed properties=], + or (b) with a forEach method that instead invokes its callback like + Set.protoype.forEach (where the key is the same as the value). + If you’re creating an API that needs such a forEach method, please send a request to + public-script-coord@w3.org. + +
+ +Note: This is how [=array iterator objects=] work. +For interfaces that [=support indexed properties=], +the iterator objects returned by “entries”, “keys”, “values” and [=@@iterator=] are +actual [=array iterator objects=]. + +Interfaces with iterable declarations must not +have any [=interface members=] +named “entries”, “forEach”, “keys” or “values”, +or have any [=inherited interfaces|inherited=] +or [=consequential interfaces|consequential=] +interfaces that have interface members with these names. + +
+ + Consider the following interface SessionManager, which allows access to + a number of Session objects: + +
+        interface SessionManager {
+          Session getSessionForUser(DOMString username);
+          readonly attribute unsigned long sessionCount;
+        
+          iterable<Session>;
+        };
+        
+        interface Session {
+          readonly attribute DOMString username;
+          // ...
+        };
+    
+ + The behavior of the iterator could be defined like so: + +
+ + The values to iterate over + are the open Session objects + on the SessionManager sorted by username. + +

+ Fix reference to removed definition for "values to iterate over". +

+
+ + In the ECMAScript language binding, the [=interface prototype object=] + for the SessionManager [=interface=] + has a values method that is a function, which, when invoked, + returns an iterator object that itself has a next method that returns the + next value to be iterated over. It has values and entries + methods that iterate over the indexes of the list of session objects + and [index, session object] pairs, respectively. It also has + a [=@@iterator=] method that allows a SessionManager + to be used in a for..of loop: + +
+        // Get an instance of SessionManager.
+        // Assume that it has sessions for two users, "anna" and "brian".
+        var sm = getSessionManager();
+        
+        typeof SessionManager.prototype.values;            // Evaluates to "function"
+        var it = sm.values();                              // values() returns an iterator object
+        String(it);                                        // Evaluates to "[object SessionManager Iterator]"
+        typeof it.next;                                    // Evaluates to "function"
+        
+        // This loop will alert "anna" and then "brian".
+        for (;;) {
+          let result = it.next();
+          if (result.done) {
+            break;
+          }
+          let session = result.value;
+          window.alert(session.username);
+        }
+        
+        // This loop will also alert "anna" and then "brian".
+        for (let session of sm) {
+          window.alert(session.username);
+        }
+    
+
+ +An interface must not have more than one +[=iterable declaration=]. +The [=inherited interfaces|inherited=] +and [=consequential interfaces|consequential=] +interfaces of an interface with an +[=iterable declaration=] +must not also have an +[=iterable declaration=]. +An interface with an [=iterable declaration=] +and its [=inherited interfaces|inherited=] +and [=consequential interfaces|consequential=] +interfaces must not have a +[=maplike declaration=] or +[=setlike declaration=]. + +The following extended attributes are applicable to [=iterable declarations=]: +[{{Exposed}}], +[{{SecureContext}}]. + +
+    Iterable :
+        "iterable" "<" Type OptionalType ">" ";"
+
+ +
+    OptionalType :
+        "," Type
+        ε
+
+ + +

Maplike declarations

+ +An [=interface=] can be declared to be +maplike by using a maplike declaration +(matching ReadWriteMaplike or +readonly MaplikeRest) in the body of the interface. + +
+    interface interface_identifier {
+      readonly maplike<key_type, value_type>;
+      maplike<key_type, value_type>;
+    };
+
+ +Objects implementing an interface that is declared to be maplike +represent an ordered list of key–value pairs known as its map entries. +The types used for the keys and values are given in the angle +brackets of the maplike declaration. Keys are required to be unique. + +The [=map entries=] of an object +implementing a [=maplike=] interface is empty at +the of the object’s creation. Prose accompanying the interface can +describe how the [=map entries=] +of an object change. + +Maplike interfaces support an API for querying the map entries +appropriate for the language binding. If the readonly +keyword is not used, then it also supports an API for modifying +the map entries. + +Note: In the ECMAScript language binding, the API for interacting +with the map entries is similar to that available on ECMAScript +Map objects. If the readonly +keyword is used, this includes “entries”, “forEach”, “get”, “has”, +“keys”, “values”, [=@@iterator=] methods and a “size” getter. +For read–write maplikes, it also includes “clear”, “delete” and +“set” methods. + +Maplike interfaces must not +have any [=interface members=] +named “entries”, “forEach”, “get”, “has”, “keys”, “size”, or “values”, +or have any [=inherited interfaces|inherited=] +or [=consequential interfaces|consequential=] +interfaces that have interface members with these names. +Read–write maplike interfaces must not +have any [=attributes=] +or [=constants=] named +“clear”, “delete”, or “set”, or have any [=inherited interfaces|inherited=] +or [=consequential interfaces|consequential=] +interfaces that have attributes or constants with these names. + +Note: Operations named “clear”, “delete”, or “set” are allowed on read–write maplike +interfaces and will prevent the default implementation of these methods being +added to the interface prototype object in the ECMAScript language binding. +This allows the default behavior of these operations to be overridden. + +An interface must not have more than one +[=maplike declaration=]. +The [=inherited interfaces|inherited=] +and [=consequential interfaces|consequential=] +interfaces of a maplike interface must not +also have a [=maplike declaration=]. +A maplike interface and its [=inherited interfaces|inherited=] +and [=consequential interfaces|consequential=] +interfaces must not have an +[=iterable declaration=] or +[=setlike declaration=]. + +
+ +
+ +
+    ReadWriteMaplike :
+        MaplikeRest
+
+ +
+    MaplikeRest :
+        "maplike" "<" Type "," Type ">" ";"
+
+ +No [=extended attributes=] +defined in this specification are applicable to [=maplike declarations=]. + +

+ Add example. +

+ + +

Setlike declarations

+ +An [=interface=] can be declared to be +setlike by using a setlike declaration +(matching ReadWriteSetlike or +readonly SetlikeRest) in the body of the interface. + +
+    interface interface_identifier {
+      readonly setlike<type>;
+      setlike<type>;
+    };
+
+ +Objects implementing an interface that is declared to be setlike +represent an ordered list of values known as its set entries. +The type of the values is given in the angle +brackets of the setlike declaration. Values are required to be unique. + +The [=set entries=] of an object +implementing a [=setlike=] interface is empty at +the of the object’s creation. Prose accompanying the interface can +describe how the [=set entries=] +of an object change. + +Setlike interfaces support an API for querying the set entries +appropriate for the language binding. If the readonly +keyword is not used, then it also supports an API for modifying +the set entries. + +Note: In the ECMAScript language binding, the API for interacting +with the set entries is similar to that available on ECMAScript +Set objects. If the readonly +keyword is used, this includes “entries”, “forEach”, “has”, +“keys”, “values”, [=@@iterator=] methods and a “size” getter. +For read–write setlikes, it also includes “add”, “clear”, and “delete” methods. + +Setlike interfaces must not +have any [=interface members=] +named “entries”, “forEach”, “has”, “keys”, “size”, or “values”, +or have any [=inherited interfaces|inherited=] +or [=consequential interfaces|consequential=] +interfaces that have interface members with these names.. +Read–write setlike interfaces must not +have any [=attributes=] +or [=constants=] named +“add”, “clear”, or “delete”, or have any [=inherited interfaces|inherited=] +or [=consequential interfaces|consequential=] +interfaces that have attributes or constants with these names. + +Note: Operations named “add”, “clear”, or “delete” are allowed on read–write setlike +interfaces and will prevent the default implementation of these methods being +added to the interface prototype object in the ECMAScript language binding. +This allows the default behavior of these operations to be overridden. + +An interface must not have more than one +[=setlike declaration=]. +The [=inherited interfaces|inherited=] +and [=consequential interfaces|consequential=] +interfaces of a setlike interface must not +also have a [=setlike declaration=]. +A setlike interface and its [=inherited interfaces|inherited=] +and [=consequential interfaces|consequential=] +interfaces must not have an +[=iterable declaration=] or +[=maplike declaration=]. + +
+ +
+ +
+    ReadWriteSetlike :
+        SetlikeRest
+
+ +
+    SetlikeRest :
+        "setlike" "<" Type ">" ";"
+
+ +No [=extended attributes=] +defined in this specification are applicable to [=setlike declarations=]. + +

+ Add example. +

+ + +

Namespaces

+ +A namespace is a definition (matching Namespace) that declares a global singleton with +associated behaviors. + +
+    namespace identifier {
+      /* namespace_members... */
+    };
+
+ +A namespace is a specification of a set of namespace members (matching NamespaceMembers), which are the [=regular operations=] that appear between the braces in +the namespace declaration. These operations describe the behaviors packaged into the +namespace. + +As with interfaces, the IDL for namespaces can be split into multiple parts by using +partial namespace definitions +(matching partial Namespace). The [=identifier=] of a partial namespace definition must be the same as the identifier of a namespace definition. +All of the members that appear on each of the partial namespace definitions are +considered to be members of the namespace itself. + +
+    namespace SomeNamespace {
+      /* namespace_members... */
+    };
+    
+    partial namespace SomeNamespace {
+      /* namespace_members... */
+    };
+
+ +Note: As with partial interface definitions, partial namespace definitions are intended for +use as a specification editorial aide, allowing the definition of a namespace to be +separated over more than one section of the document, and sometimes multiple +documents. + +The order that members appear in has significance for property enumeration in the ECMAScript binding. + +Note that unlike interfaces or dictionaries, namespaces do not create types. + +Of the extended attributes defined in this specification, only the [{{Exposed}}] and [{{SecureContext}}] extended attributes are applicable to +namespaces. + +
+ +
+ +
+    Namespace :
+        "namespace" identifier "{" NamespaceMembers "}" ";"
+
+ +
+    NamespaceMembers :
+        ExtendedAttributeList NamespaceMember NamespaceMembers
+        ε
+
+ +
+    NamespaceMember :
+        ReturnType OperationRest
+
+ +
+ + The following [=IDL fragment=] defines an + [=namespace=]. + +
+        namespace VectorUtils {
+          double dotProduct(Vector x, Vector y);
+          Vector crossProduct(Vector x, Vector y);
+        };
+    
+ + An ECMAScript implementation would then expose a global property named + VectorUtils which was a simple object (with prototype + [=%ObjectPrototype%=]) with enumerable data properties for each declared operation: + +
+        Object.getPrototypeOf(VectorUtils);                         // Evaluates to Object.prototype.
+        Object.keys(VectorUtils);                                   // Evaluates to ["dotProduct", "crossProduct"].
+        Object.getOwnPropertyDescriptor(VectorUtils, "dotProduct"); // Evaluates to { value: <a function>, enumerable: true, configurable: true, writable: true }.
+    
+
+ + +

Dictionaries

+ +A dictionary is a definition (matching +Dictionary) +used to define an associative array data type with a fixed, ordered set of key–value pairs, +termed dictionary members, +where keys are strings and values are of a particular type specified in the definition. + +
+    dictionary identifier {
+      /* dictionary_members... */
+    };
+
+ +Dictionaries are always passed by value. In language bindings where a dictionary is represented by an object of some kind, passing a +dictionary to a [=platform object=] will not result in a reference to the dictionary being kept by that object. +Similarly, any dictionary returned from a platform object will be a copy and modifications made to it will not be visible to the platform object. + +A dictionary can be defined to inherit from another dictionary. +If the identifier of the dictionary is followed by a colon and a [=identifier=], +then that identifier identifies the inherited dictionary. The identifier +must identify a dictionary. + +A dictionary must not be declared such that +its inheritance hierarchy has a cycle. That is, a dictionary +|A| cannot inherit from itself, nor can it inherit from another +dictionary |B| that inherits from |A|, and so on. + +
+    dictionary Base {
+      /* dictionary_members... */
+    };
+    
+    dictionary Derived : Base {
+      /* dictionary_members... */
+    };
+
+ +The inherited dictionaries of +a given dictionary |D| is the set of all dictionaries that |D| +inherits from, directly or indirectly. If |D| does not [=dictionary/inherit=] +from another dictionary, then the set is empty. Otherwise, the set +includes the dictionary |E| that |D| [=interface/inherits=] +from and all of |E|’s [=inherited dictionaries=]. + +A dictionary value of type |D| can have key–value pairs corresponding +to the dictionary members defined on |D| and on any of |D|’s +[=inherited dictionaries=]. +On a given dictionary value, the presence of each dictionary member +is optional, unless that member is specified as required. +When specified in the dictionary value, a dictionary member is said to be +present, otherwise it is [=present|not present=]. +Dictionary members can also optionally have a default value, which is +the value to use for the dictionary member when passing a value to a +[=platform object=] that does +not have a specified value. Dictionary members with default values are +always considered to be present. + +

+ As with [=optional argument/default value|operation argument default values=], + is strongly suggested not to use of true as the + [=dictionary member/default value=] for + {{boolean}}-typed + [=dictionary members=], + as this can be confusing for authors who might otherwise expect the default + conversion of undefined to be used (i.e., false). +

+ +Each [=dictionary member=] (matching +DictionaryMember) is specified +as a type (matching Type) followed by an +[=identifier=] +(given by an identifier token following +the type). The identifier is the key name of the key–value pair. +If the Type +is an [=identifier=] +followed by ?, then the identifier +must identify an +interface, [=enumeration=], +[=callback function=] or [=typedef=]. +If the dictionary member type is an identifier +not followed by ?, then the identifier must +identify any one of those definitions or a [=dictionary=]. + +
+    dictionary identifier {
+      type identifier;
+    };
+
+ +If the identifier is followed by a U+003D EQUALS SIGN ("=") +and a value (matching DefaultValue), +then that gives the dictionary member its [=dictionary member/default value=]. + +
+    dictionary identifier {
+      type identifier = "value";
+    };
+
+ +When a boolean literal token (true or false), +the null token, +an integer token, a +float token, +one of the three special floating point literal values (Infinity, +-Infinity or NaN), +a string token or +the two token sequence [] used as the +[=dictionary member/default value=], +it is interpreted in the same way as for an [=operation=]’s +[=optional argument/default value|optional argument default value=]. + +If the type of the [=dictionary member=] +is an [=enumeration=], then its +[=dictionary member/default value=] if specified must +be one of the [=enumeration values|enumeration’s values=]. + +If the type of the dictionary member is preceded by the +required keyword, the member is considered a +required dictionary member +and must be present on the dictionary. A +[=required dictionary member=] must not have a default value. + +
+    dictionary identifier {
+      required type identifier;
+    };
+
+ +The type of a dictionary member must not include +the dictionary it appears on. A type includes a dictionary |D| +if at least one of the following is true: + +* the type is |D| +* the type is a dictionary that [=interface/inherits=] from |D| +* the type is a [=nullable type=] + whose [=inner type=] includes |D| +* the type is a sequence type or frozen array + whose element type includes |D| +* the type is a [=union type=], + one of whose [=member types=] + includes |D| +* the type is a dictionary, one of whose members or inherited members has + a type that includes |D| + +As with interfaces, the IDL for dictionaries can be split into multiple parts +by using partial dictionary definitions +(matching partial Dictionary). +The [=identifier=] of a partial +dictionary definition must be the same as the +identifier of a dictionary definition. All of the members that appear on each +of the partial dictionary definitions are considered to be members of +the dictionary itself. + +
+    dictionary SomeDictionary {
+      /* dictionary_members... */
+    };
+    
+    partial dictionary SomeDictionary {
+      /* dictionary_members... */
+    };
+
+ +Note: As with partial interface definitions, partial dictionary definitions are intended for use as a specification +editorial aide, allowing the definition of an interface to be separated +over more than one section of the document, and sometimes multiple documents. + +The order of the [=dictionary members=] +on a given dictionary is such that inherited dictionary members are ordered +before non-inherited members, and the dictionary members on the one +dictionary definition (including any partial dictionary definitions) are +ordered lexicographically by the Unicode codepoints that comprise their +identifiers. + +
+ + For example, with the following definitions: + +
+        dictionary B : A {
+          long b;
+          long a;
+        };
+        
+        dictionary A {
+          long c;
+          long g;
+        };
+        
+        dictionary C : B {
+          long e;
+          long f;
+        };
+        
+        partial dictionary A {
+          long h;
+          long d;
+        };
+    
+ + the order of the [=dictionary members=] + of a dictionary value of type C is + c, d, g, h, a, b, e, f. + + Dictionaries are required to have their members ordered because + in some language bindings the behavior observed when passing + a dictionary value to a platform object depends on the order + the dictionary members are fetched. For example, consider the + following additional interface: + +
+        interface Something {
+          void f(A a);
+        };
+    
+ + and this ECMAScript code: + +
+        var something = getSomething();  // Get an instance of Something.
+        var x = 0;
+        
+        var dict = { };
+        Object.defineProperty(dict, "d", { get: function() { return ++x; } });
+        Object.defineProperty(dict, "c", { get: function() { return ++x; } });
+        
+        something.f(dict);
+    
+ + The order that the dictionary members are fetched in determines + what values they will be taken to have. Since the order for + A is defined to be c then d, + the value for c will be 1 and the value for d will be 2. + +
+ +The identifier of a dictionary member must not be +the same as that of another dictionary member defined on the dictionary or +on that dictionary’s [=inherited dictionaries=]. + +Dictionaries must not be used as the type of an +[=attribute=] or +[=constant=]. + +The following extended attributes are applicable to dictionaries: +[{{Constructor}}], +[{{Exposed}}], +[{{SecureContext}}], + +The following extended attributes are applicable to dictionary members: +[{{Clamp}}], +[{{EnforceRange}}]. + +
+ +
+ +
+    Dictionary :
+        "dictionary" identifier Inheritance "{" DictionaryMembers "}" ";"
+
+ +
+    DictionaryMembers :
+        ExtendedAttributeList DictionaryMember DictionaryMembers
+        ε
+
+ +
+    DictionaryMember :
+        Required Type identifier Default ";"
+
+ +
+    Required :
+        "required"
+        ε
+
+ +
+    PartialDictionary :
+        "dictionary" identifier "{" DictionaryMembers "}" ";"
+
+ +
+    Default :
+        "=" DefaultValue
+        ε
+
+ +
+ +
+ +
+ + One use of dictionary types is to allow a number of optional arguments to + an [=operation=] without being + constrained as to the order they are specified at the call site. For example, + consider the following [=IDL fragment=]: + +
+        [Constructor]
+        interface Point {
+          attribute double x;
+          attribute double y;
+        };
+        
+        dictionary PaintOptions {
+          DOMString? fillPattern = "black";
+          DOMString? strokePattern = null;
+          Point position;
+        };
+        
+        interface GraphicsContext {
+          void drawRectangle(double width, double height, optional PaintOptions options);
+        };
+    
+ + In an ECMAScript implementation of the IDL, an Object + can be passed in for the optional PaintOptions dictionary: + +
+        // Get an instance of GraphicsContext.
+        var ctx = getGraphicsContext();
+        
+        // Draw a rectangle.
+        ctx.drawRectangle(300, 200, { fillPattern: "red", position: new Point(10, 10) });
+    
+ + Both fillPattern and strokePattern are given [=dictionary member/default values=], + so if they are omitted, the definition of drawRectangle can assume that they + have the given default values and not include explicit wording to handle + their non-presence. + +
+ + +

Exceptions

+ +An exception is a type of object that +represents an error and which can be thrown or treated as a first +class value by implementations. Web IDL does not allow exceptions +to be defined, but instead has a number of pre-defined exceptions +that specifications can reference and throw in their definition of +operations, attributes, and so on. Exceptions have an +error name, +a {{DOMString}}, +which is the type of error the exception represents, and a +message, which is an optional, +user agent-defined value that provides human readable details of the error. + +There are two kinds of exceptions available to be thrown from specifications. +The first is a simple exception, which +is identified by one of the following names: + +* "Error" +* "EvalError" +* "RangeError" +* "ReferenceError" +* "TypeError" +* "URIError" + +These correspond to all of the [=ECMAScript error objects=] (apart from +SyntaxError, which is deliberately omitted as +it is for use only by the ECMAScript parser). +The meaning of +each [=simple exception=] matches +its corresponding Error object in the +ECMAScript specification. + +The second kind of exception is a DOMException, +which is an exception that encapsulates a name and an optional integer code, +for compatibility with historically defined exceptions in the DOM. + +For [=simple exceptions=], +the [=error name=] is the name +of the exception. +For a {{DOMException}}, +the [=error name=] must +be one of the names listed in the [=error names table=] +below. The table also indicates the {{DOMException}}'s integer code +for that error name, if it has one. + +There are two types that can be used to refer to +exception objects: {{Error!!interface}}, which encompasses all exceptions, +and {{DOMException}} which includes just DOMException objects. +This allows for example an [=operation=] +to be declared to have a {{DOMException}} +[=return type=] or an [=attribute=] +to be of type {{Error!!interface}}. + +Exceptions can be created by providing its +[=error name=]. +Exceptions can also be thrown, by providing the +same details required to [=created|create=] one. + +The resulting behavior from creating and throwing an exception is language binding-specific. + +Note: See [[#es-creating-throwing-exceptions]] for details on what creating and throwing an exception +entails in the ECMAScript language binding. + +
+ + Here is are some examples of wording to use to create and throw exceptions. + To throw a new [=simple exception=] named + {{TypeError}}: + +
+ + [=Throw=] a TypeError. + +
+ + To throw a new {{DOMException}} with + [=error name=] + {{IndexSizeError}}: + +
+ + [=Throw=] an IndexSizeError. + +
+ + To create a new {{DOMException}} with + [=error name=] + {{SyntaxError}}: + +
+ + Let |object| be a newly [=created=] SyntaxError. + +
+
+ + +

Error names

+ +The error names table below lists all the allowed error names +for {{DOMException|DOMExceptions}}, a description, +and legacy code values. + +Note: If an error name is not listed here, please file a bug as indicated at the top of this specification and it will be addressed shortly. Thanks! + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
NameDescriptionLegacy {{DOMException|code}} name and value
"IndexSizeError"The index is not in the allowed range.INDEX_SIZE_ERR (1)
"HierarchyRequestError"The operation would yield an incorrect node tree.HIERARCHY_REQUEST_ERR (3)
"WrongDocumentError"The object is in the wrong document.WRONG_DOCUMENT_ERR (4)
"InvalidCharacterError"The string contains invalid characters.INVALID_CHARACTER_ERR (5)
"NoModificationAllowedError"The object can not be modified.NO_MODIFICATION_ALLOWED_ERR (7)
"NotFoundError"The object can not be found here.NOT_FOUND_ERR (8)
"NotSupportedError"The operation is not supported.NOT_SUPPORTED_ERR (9)
"InUseAttributeError"The attribute is in use.INUSE_ATTRIBUTE_ERR (10)
"InvalidStateError"The object is in an invalid state.INVALID_STATE_ERR (11)
"SyntaxError"The string did not match the expected pattern.SYNTAX_ERR (12)
"InvalidModificationError"The object can not be modified in this way.INVALID_MODIFICATION_ERR (13)
"NamespaceError"The operation is not allowed by Namespaces in XML. [[XML-NAMES]]NAMESPACE_ERR (14)
"InvalidAccessError"The object does not support the operation or argument.INVALID_ACCESS_ERR (15)
"SecurityError"The operation is insecure.SECURITY_ERR (18)
"NetworkError"A network error occurred.NETWORK_ERR (19)
"AbortError"The operation was aborted.ABORT_ERR (20)
"URLMismatchError"The given URL does not match another URL.URL_MISMATCH_ERR (21)
"QuotaExceededError"The quota has been exceeded.QUOTA_EXCEEDED_ERR (22)
"TimeoutError"The operation timed out.TIMEOUT_ERR (23)
"InvalidNodeTypeError"The supplied node is incorrect or has an incorrect ancestor for this operation.INVALID_NODE_TYPE_ERR (24)
"DataCloneError"The object can not be cloned.DATA_CLONE_ERR (25)
"EncodingError"The encoding operation (either encoded or decoding) failed.
"NotReadableError"The I/O read operation failed.
"UnknownError"The operation failed for an unknown transient reason (e.g. out of memory).
"ConstraintError"A mutation operation in a transaction failed because a constraint was not satisfied.
"DataError"Provided data is inadequate.
"TransactionInactiveError"A request was placed against a transaction which is currently not active, or which is finished.
"ReadOnlyError"The mutating operation was attempted in a "readonly" transaction.
"VersionError"An attempt was made to open a database using a lower version than the existing version.
"OperationError"The operation failed for an operation-specific reason.
"NotAllowedError"The request is not allowed by the user agent or the platform in the current context, possibly because the user denied permission.
+ + +

Enumerations

+ +An enumeration is a definition (matching +Enum) used to declare a type +whose valid values are a set of predefined strings. Enumerations +can be used to restrict the possible +{{DOMString}} values that can be assigned to an +[=attribute=] or passed to an +[=operation=]. + +
enum identifier { "enum", "values" /* , ... */ };
+ +The enumeration values are specified +as a comma-separated list of string literals. +The list of [=enumeration values=] +must not include duplicates. + +

+ It is strongly suggested that enumeration values be all lowercase, + and that multiple words be separated using dashes or not be + separated at all, unless there is a specific reason to use another + value naming scheme. For example, an enumeration value that + indicates an object should be created could be named + "createobject" or "create-object". + Consider related uses of enumeration values when deciding whether + to dash-separate or not separate enumeration value words so that + similar APIs are consistent. +

+ +The behavior when a string value that is not one a valid enumeration value +is used when assigning to an [=attribute=], +or passed as an [=operation=] argument, +whose type is the enumeration, is language binding specific. + +Note: In the ECMAScript binding, assignment of an invalid string value to an +[=attribute=] is ignored, while +passing such a value as an [=operation=] argument +results in an exception being thrown. + +No [=extended attributes=] +defined in this specification are applicable to [=enumerations=]. + +
+    Enum :
+        "enum" identifier "{" EnumValueList "}" ";"
+
+ +
+    EnumValueList :
+        string EnumValueListComma
+
+ +
+    EnumValueListComma :
+        "," EnumValueListString
+        ε
+
+ +
+    EnumValueListString :
+        string EnumValueListComma
+        ε
+
+ +
+ + The following [=IDL fragment=] + defines an [=enumeration=] + that is used as the type of an [=attribute=] + and an [=operation=] argument: + +
+        enum MealType { "rice", "noodles", "other" };
+        
+        interface Meal {
+          attribute MealType type;
+          attribute double size;     // in grams
+        
+          void initialize(MealType type, double size);
+        };
+    
+ + An ECMAScript implementation would restrict the strings that can be + assigned to the type property or passed to the initializeMeal function + to those identified in the [=enumeration=]. + +
+        var meal = getMeal();                // Get an instance of Meal.
+        
+        meal.initialize("rice", 200);        // Operation invoked as normal.
+        
+        try {
+          meal.initialize("sandwich", 100);  // Throws a TypeError.
+        } catch (e) {
+        }
+        
+        meal.type = "noodles";               // Attribute assigned as normal.
+        meal.type = "dumplings";             // Attribute assignment ignored.
+        meal.type == "noodles";              // Evaluates to true.
+    
+
+ + +

Callback functions

+ +

+ The “Custom DOM Elements” spec wants to use callback function types for + platform object provided functions. Should we rename “callback functions” to + just “functions” to make it clear that they can be used for both purposes? +

+ +A callback function is a definition (matching +callback CallbackRest) used to declare a function type. + +
callback identifier = return_type (/* arguments... */);
+ +Note: See also the similarly named [=callback interfaces=]. + +The [=identifier=] on the +left of the equals sign gives the name of the [=callback function=] +and the return type and argument list (matching ReturnType +and ArgumentList) on the right side of the equals +sign gives the signature of the callback function type. + +[=Callback functions=] must not +be used as the type of a [=constant=]. + +The following extended attribute is applicable to callback functions: +[{{TreatNonObjectAsNull}}]. + +
+ +
+ +
+    CallbackRest :
+        identifier "=" ReturnType "(" ArgumentList ")" ";"
+
+ +
+ + The following [=IDL fragment=] defines + a [=callback function=] used for an API that + invokes a user-defined function when an operation is complete. + +
+        callback AsyncOperationCallback = void (DOMString status);
+        
+        interface AsyncOperations {
+          void performOperation(AsyncOperationCallback whenFinished);
+        };
+    
+ + In the ECMAScript language binding, a Function object is + passed as the operation argument. + +
+        var ops = getAsyncOperations();  // Get an instance of AsyncOperations.
+        
+        ops.performOperation(function(status) {
+          window.alert("Operation finished, status is " + status + ".");
+        });
+    
+
+ + +

Typedefs

+ +A typedef is a definition (matching +Typedef) +used to declare a new name for a type. This new name is not exposed +by language bindings; it is purely used as a shorthand for referencing +the type in the IDL. + +
typedef type identifier;
+ +The type being given a new name is specified after the typedef +keyword (matching Type), and the +identifier token following the +type gives the name. + +The Type must not +identify the same or another [=typedef=]. + +No [=extended attributes=] +defined in this specification are applicable to [=typedefs=]. + +
+    Typedef :
+        "typedef" Type identifier ";"
+
+ +
+ + The following [=IDL fragment=] + demonstrates the use of [=typedefs=] + to allow the use of a short + [=identifier=] instead of a long + sequence type. + +
+        interface Point {
+          attribute double x;
+          attribute double y;
+        };
+        
+        typedef sequence<Point> Points;
+        
+        interface Widget {
+          boolean pointWithinBounds(Point p);
+          boolean allPointsWithinBounds(Points ps);
+        };
+    
+
+ + +

Implements statements

+ +An implements statement is a definition +(matching ImplementsStatement) +used to declare that all objects implementing an interface |A| +(identified by the first [=identifier=]) +must additionally implement interface |B| +(identified by the second identifier), including all other interfaces that +|B| inherits from. + +
identifier_A implements identifier_B;
+ +Transitively, if objects implementing |B| +are declared with an [=implements statement=] +to additionally implement interface |C|, then all objects implementing +|A| do additionally implement interface |C|. + +The two [=identifiers=] must +identify two different interfaces. + +The interface identified on the left-hand side of an implements statement +must not [=interface/inherit=] +from the interface identifier on the right-hand side, and vice versa. Both identified +interfaces also must not be +[=callback interfaces=]. + +If each [=implements statement=] is +considered to be an edge in a directed graph, from a node representing the interface +on the left-hand side of the statement to a node representing the interface on the +right-hand side, then this graph must not have any cycles. + +Interfaces that a given object implements are partitioned into those that are considered +supplemental interfaces and those that are not. +An interface |A| is considered to be a +[=supplemental interface=] of an object +|O| if: + +* |O| implements a different interface |B|, and the IDL states that + B implements A; or +* |O| implements a different [=supplemental interface=] + |C|, and |C| [=interface/inherits=] from |A|. + +
+ + Specification authors are discouraged from writing [=implements statements=] + where the [=interface=] on the left-hand side + is a [=supplemental interface=]. + For example, if author 1 writes: + +
+        interface Window { /* ... */ };
+        interface SomeFunctionality { /* ... */ };
+        Window implements SomeFunctionality;
+    
+ + and author 2 later writes: + +
+        interface Gizmo { /* ... */ };
+        interface MoreFunctionality { /* ... */ };
+        SomeFunctionality implements MoreFunctionality;
+        Gizmo implements SomeFunctionality;
+    
+ + then it might be the case that author 2 is unaware of exactly which + interfaces already are used on the left-hand side of an + implements SomeFunctionality statement, and so has + required more objects implement MoreFunctionality + than he or she expected. + + Better in this case would be for author 2 to write: + +
+        interface Gizmo { /* ... */ };
+        interface MoreFunctionality { /* ... */ };
+        Gizmo implements SomeFunctionality;
+        Gizmo implements MoreFunctionality;
+    
+
+ +The consequential interfaces of an interface +|A| are: + +* each interface |B| where the IDL states A implements B; +* each interface that a consequential interface of |A| inherits from; and +* each interface |D| where the IDL states that C implements D, + where |C| is a consequential interface of |A|. + +For a given interface, there must not +be any member defined on any of its consequential interfaces +whose identifier is the same as any other member defined on any +of those consequential interfaces or on the original interface itself. + +
+ + For example, that precludes the following: + +
+        interface A { attribute long x; };
+        interface B { attribute long x; };
+        A implements B;  // B::x would clash with A::x
+        
+        interface C { attribute long y; };
+        interface D { attribute long y; };
+        interface E : D { };
+        C implements E;  // D::y would clash with C::y
+        
+        interface F { };
+        interface H { attribute long z; };
+        interface I { attribute long z; };
+        F implements H;
+        F implements I;  // H::z and I::z would clash when mixed in to F
+    
+
+ +No [=extended attributes=] +defined in this specification are applicable to +[=implements statements=]. + +
+    ImplementsStatement :
+        identifier "implements" identifier ";"
+
+ +
+ + The following [=IDL fragment=] + defines two [=interfaces=], stating + that one interface is always implemented on objects implementing the other. + +
+        interface Entry {
+          readonly attribute unsigned short entryType;
+          // ...
+        };
+        
+        interface Observable {
+          void addEventListener(DOMString type,
+                                EventListener listener,
+                                boolean useCapture);
+          // ...
+        };
+        
+        Entry implements Observable;
+    
+ + An ECMAScript implementation would thus have an “addEventListener” + property in the prototype chain of every Entry: + +
+        var e = getEntry();          // Obtain an instance of Entry.
+        typeof e.addEventListener;  // Evaluates to "function".
+    
+ + Note that it is not the case that all Observable + objects implement Entry. + +
+ + +

Objects implementing interfaces

+ +In a given implementation of a set of [=IDL fragments=], +an object can be described as being a platform object, a +user object, or neither. There are two kinds of +object that are considered to be platform objects: + +* objects that implement a non-[=callback interface|callback=] [=interface=]; +* objects representing IDL {{DOMException|DOMExceptions}}. + +In a browser, for example, +the browser-implemented DOM objects (implementing interfaces such as Node and +Document) that provide access to a web page’s contents +to ECMAScript running in the page would be platform objects. These objects might be exotic objects, +implemented in a language like C++, or they might be native ECMAScript objects. Regardless, +an implementation of a given set of IDL fragments needs to be able to recognize all platform objects +that are created by the implementation. This might be done by having some internal state that records whether +a given object is indeed a platform object for that implementation, or perhaps by observing +that the object is implemented by a given internal C++ class. How exactly platform objects +are recognised by a given implementation of a set of IDL fragments is implementation specific. + +All other objects in the system would not be treated as platform objects. For example, assume that +a web page opened in a browser loads an ECMAScript library that implements DOM Core. This library +would be considered to be a different implementation from the browser provided implementation. +The objects created by the ECMAScript library that implement the Node interface +will not be treated as platform objects that implement Node by the browser implementation. + +User objects are those that authors would create, implementing +[=callback interfaces=] that the Web APIs use to be able to invoke author-defined +operations or to send and receive values to the author’s program through +manipulating the object’s attributes. In a web page, an ECMAScript object +that implements the EventListener interface, which is +used to register a callback that the DOM Events implementation invokes, would be considered +to be a user object. + +Note that user objects can only implement [=callback interfaces=] +and platform objects can only implement non-callback interfaces. + + +

Types

+ +This section lists the types supported by Web IDL, the set of values +corresponding to each type, and how [=constants=] +of that type are represented. + +The following types are known as integer types: +{{byte}}, +{{octet}}, +{{short}}, +{{unsigned short}}, +{{long}}, +{{unsigned long}}, +{{long long}} and +{{unsigned long long}}. + +The following types are known as numeric types: +the [=integer types=], +{{float}}, +{{unrestricted float}}, +{{double}} and +{{unrestricted double}}. + +The primitive types are +{{boolean}} and the [=numeric types=]. + +The string types are +{{DOMString}}, all enumeration types, +{{ByteString}} and {{USVString}}. + +The exception types are +{{Error!!interface}} and {{DOMException}}. + +The typed array types are +{{Int8Array}}, +{{Int16Array}}, +{{Int32Array}}, +{{Uint8Array}}, +{{Uint16Array}}, +{{Uint32Array}}, +{{Uint8ClampedArray}}, +{{Float32Array}} and +{{Float64Array}}. + +The buffer source types +are {{ArrayBuffer}}, +{{DataView}}, +and the [=typed array types=]. + +The {{object}} type, +all [=interface types=] +and the [=exception types=] +are known as object types. + +Every type has a type name, which +is a string, not necessarily unique, that identifies the type. +Each sub-section below defines what the type name is for each +type. + +

+ When conversions are made from language binding specific types to + IDL types in order to invoke an [=operation=] + or assign a value to an [=attribute=], + all conversions necessary will be performed before the + specified functionality of the operation or attribute assignment + is carried out. If the conversion cannot + be performed, then the operation will not run or + the attribute will not be updated. In some language bindings, + type conversions could result in an exception being thrown. + In such cases, these exceptions will be propagated to the + code that made the attempt to invoke the operation or + assign to the attribute. +

+ +
+    Type :
+        SingleType
+        UnionType Null
+
+ +
+    SingleType :
+        NonAnyType
+        "any"
+
+ +
+    UnionType :
+        "(" UnionMemberType "or" UnionMemberType UnionMemberTypes ")"
+
+ +
+    UnionMemberType :
+        NonAnyType
+        UnionType Null
+
+ +
+    UnionMemberTypes :
+        "or" UnionMemberType UnionMemberTypes
+        ε
+
+ +
+    NonAnyType :
+        PrimitiveType Null
+        PromiseType Null
+        "ByteString" Null
+        "DOMString" Null
+        "USVString" Null
+        identifier Null
+        "sequence" "<" Type ">" Null
+        "object" Null
+        "RegExp" Null
+        "Error" Null
+        "DOMException" Null
+        BufferRelatedType Null
+        "FrozenArray" "<" Type ">" Null
+
+ +
+ +
+    PrimitiveType :
+        UnsignedIntegerType
+        UnrestrictedFloatType
+        "boolean"
+        "byte"
+        "octet"
+
+ +
+    UnrestrictedFloatType :
+        "unrestricted" FloatType
+        FloatType
+
+ +
+    FloatType :
+        "float"
+        "double"
+
+ +
+    UnsignedIntegerType :
+        "unsigned" IntegerType
+        IntegerType
+
+ +
+    IntegerType :
+        "short"
+        "long" OptionalLong
+
+ +
+    OptionalLong :
+        "long"
+        ε
+
+ +
+    PromiseType :
+        "Promise" "<" ReturnType ">"
+
+ +
+    Null :
+        "?"
+        ε
+
+ + +

any

+ +The {{any}} type is the union of all other possible +non-union types. +Its [=type name=] is “Any”. + +The {{any}} type is like +a discriminated union type, in that each of its values has a +specific non-{{any}} type +associated with it. For example, one value of the +{{any}} type is the +{{unsigned long}} +150, while another is the {{long}} 150. +These are distinct values. + +The particular type of an {{any}} +value is known as its specific type. +(Values of union types also have +[=specific types=].) + + +

boolean

+ +The {{boolean}} type has two values: +true and false. + +{{boolean}} constant values in IDL are +represented with the true and +false tokens. + +The [=type name=] of the +{{boolean}} type is “Boolean”. + + +

byte

+ +The {{byte}} type is a signed integer +type that has values in the range [−128, 127]. + +{{byte}} constant values in IDL are +represented with integer +tokens. + +The [=type name=] of the +{{byte}} type is “Byte”. + + +

octet

+ +The {{octet}} type is an unsigned integer +type that has values in the range [0, 255]. + +{{octet}} constant values in IDL are +represented with integer +tokens. + +The [=type name=] of the +{{octet}} type is “Octet”. + + +

short

+ +The {{short}} type is a signed integer +type that has values in the range [−32768, 32767]. + +{{short}} constant values in IDL are +represented with integer +tokens. + +The [=type name=] of the +{{short}} type is “Short”. + + +

unsigned short

+ +The {{unsigned short}} type is an unsigned integer +type that has values in the range [0, 65535]. + +{{unsigned short}} constant values in IDL are +represented with integer +tokens. + +The [=type name=] of the +{{unsigned short}} type is “UnsignedShort”. + + +

long

+ +The {{long}} type is a signed integer +type that has values in the range [−2147483648, 2147483647]. + +{{long}} constant values in IDL are +represented with integer +tokens. + +The [=type name=] of the +{{long}} type is “Long”. + + +

unsigned long

+ +The {{unsigned long}} type is an unsigned integer +type that has values in the range [0, 4294967295]. + +{{unsigned long}} constant values in IDL are +represented with integer +tokens. + +The [=type name=] of the +{{unsigned long}} type is “UnsignedLong”. + + +

long long

+ +The {{long long}} type is a signed integer +type that has values in the range [−9223372036854775808, 9223372036854775807]. + +{{long long}} constant values in IDL are +represented with integer +tokens. + +The [=type name=] of the +{{long long}} type is “LongLong”. + + +

unsigned long long

+ +The {{unsigned long long}} type is an unsigned integer +type that has values in the range [0, 18446744073709551615]. + +{{unsigned long long}} constant values in IDL are +represented with integer +tokens. + +The [=type name=] of the +{{unsigned long long}} type is “UnsignedLongLong”. + + +

float

+ +The {{float}} type is a floating point numeric +type that corresponds to the set of finite single-precision 32 bit +IEEE 754 floating point numbers. [[!IEEE-754]] + +{{float}} constant values in IDL are +represented with float +tokens. + +The [=type name=] of the +{{float}} type is “Float”. + +

+ Unless there are specific reasons to use a 32 bit floating point type, + specifications should use + {{double}} rather than {{float}}, + since the set of values that a {{double}} can + represent more closely matches an ECMAScript Number. +

+ + +

unrestricted float

+ +The {{unrestricted float}} type is a floating point numeric +type that corresponds to the set of all possible single-precision 32 bit +IEEE 754 floating point numbers, finite and non-finite. [[!IEEE-754]] + +{{unrestricted float}} constant values in IDL are +represented with float +tokens. + +The [=type name=] of the +{{unrestricted float}} type is “UnrestrictedFloat”. + + +

double

+ +The {{double}} type is a floating point numeric +type that corresponds to the set of finite double-precision 64 bit +IEEE 754 floating point numbers. [[!IEEE-754]] + +{{double}} constant values in IDL are +represented with float +tokens. + +The [=type name=] of the +{{double}} type is “Double”. + + +

unrestricted double

+ +The {{unrestricted double}} type is a floating point numeric +type that corresponds to the set of all possible double-precision 64 bit +IEEE 754 floating point numbers, finite and non-finite. [[!IEEE-754]] + +{{unrestricted double}} constant values in IDL are +represented with float +tokens. + +The [=type name=] of the +{{unrestricted double}} type is “UnrestrictedDouble”. + + +

DOMString

+ +The {{DOMString}} type corresponds to +the set of all possible sequences of [=code units=]. +Such sequences are commonly interpreted as UTF-16 encoded strings [[!RFC2781]] +although this is not required. +While {{DOMString}} is defined to be +an OMG IDL boxed {{sequence}}<{{unsigned short}}> valuetype +in [[DOM-LEVEL-3-CORE/core#ID-C74D1578|DOM Level 3 Core §The DOMString Type]], +this document defines {{DOMString}} to be an intrinsic type +so as to avoidspecial casing that sequence type +in various situations where a string is required. + +Note: Note also that null +is not a value of type {{DOMString}}. +To allow null, a +nullable {{DOMString}}, +written as DOMString? in IDL, needs to be used. + +Nothing in this specification requires a {{DOMString}} +value to be a valid UTF-16 string. For example, a {{DOMString}} +value might include unmatched surrogate pair characters. However, authors +of specifications using Web IDL might want to obtain a sequence of +[=Unicode scalar values=] given a particular sequence of +[=code units=]. +The following algorithm defines a way to +convert a DOMString to a sequence of Unicode scalar values: + +
    + 1. Let |S| be the {{DOMString}} value. + 1. Let |n| be the length of |S|. + 1. Initialize |i| to 0. + 1. Initialize |U| to be an empty sequence of Unicode characters. + 1. While |i| < |n|: + 1. Let |c| be the [=code unit=] in |S| at index |i|. + 1. Depending on the value of |c|: +
    + : |c| < 0xD800 or |c| > 0xDFFF + :: Append to |U| the Unicode character with code point |c|. + + : 0xDC00 ≤ |c| ≤ 0xDFFF + :: Append to |U| a U+FFFD REPLACEMENT CHARACTER. + + : 0xD800 ≤ |c| ≤ 0xDBFF + ::
      + 1. If |i| = |n|−1, then append to |U| a U+FFFD REPLACEMENT CHARACTER. + 1. Otherwise, |i| < |n|−1: + 1. Let |d| be the code unit in |S| at index + |i|+1. + 1. If 0xDC00 ≤ |d| ≤ 0xDFFF, then: + 1. Let |a| be |c| & 0x3FF. + 1. Let |b| be |d| & 0x3FF. + 1. Append to |U| the Unicode character with + code point 216+210|a|+|b|. + 1. Set |i| to |i|+1. + 1. Otherwise, |d| < 0xDC00 or |d| > 0xDFFF. + Append to |U| a U+FFFD REPLACEMENT CHARACTER. +
    +
    + 1. Set |i| to |i|+1. + 1. Return |U|. +
+ +There is no way to represent a constant {{DOMString}} +value in IDL, although {{DOMString}} [=dictionary member=] +and [=optional argument|operation optional argument=] default values +can be specified using a string literal. + +The [=type name=] of the +{{DOMString}} type is “String”. + + +

ByteString

+ +The {{ByteString}} type +corresponds to the set of all possible sequences of bytes. +Such sequences might be interpreted as UTF-8 encoded strings [[!RFC3629]] +or strings in some other 8-bit-per-code-unit encoding, although this is not required. + +There is no way to represent a constant {{ByteString}} +value in IDL, although {{ByteString}} [=dictionary member=] +and [=optional argument|operation optional argument=] default values +can be specified using a string literal. + +The [=type name=] of the +{{ByteString}} type is “ByteString”. + +

+ Specifications should only use + {{ByteString}} for interfacing with protocols + that use bytes and strings interchangably, such as HTTP. In general, + strings should be represented with + {{DOMString}} values, even if it is expected + that values of the string will always be in ASCII or some + 8 bit character encoding. Sequences, + frozen arrays or [=Typed Arrays=] + with {{octet}} or {{byte}} + elements should be used for holding + 8 bit data rather than {{ByteString}}. +

+ + +

USVString

+ +The {{USVString}} type +corresponds to the set of all possible sequences of +[=Unicode scalar values=], +which are all of the Unicode code points apart from the +surrogate code points. + +There is no way to represent a constant {{USVString}} +value in IDL, although {{USVString}} [=dictionary member=] +and [=optional argument|operation optional argument=] default values +can be specified using a string literal. + +The [=type name=] of the +{{USVString}} type is “USVString”. + +

+ Specifications should only use + {{USVString}} for APIs that perform + text processing and need a string of Unicode + scalar values to operate on. Most APIs that use strings + should instead be using {{DOMString}}, + which does not make any interpretations of the [=code units=] + in the string. When in doubt, use {{DOMString}}. +

+ + +

object

+ +The {{object}} type corresponds to the set of +all possible non-null object references. + +There is no way to represent a constant {{object}} +value in IDL. + +To denote a type that includes all possible object references plus the +null value, use the nullable type +object?. + +The [=type name=] of the +{{object}} type is “Object”. + + +

Interface types

+ +An [=identifier=] that +identifies an [=interface=] is used to refer to +a type that corresponds to the set of all possible non-null references to objects that +implement that interface. + +For non-callback interfaces, an IDL value of the interface type is represented just +by an object reference. For [=callback interfaces=], an IDL value of the interface type +is represented by a tuple of an object reference and a callback context. +The [=callback context=] is a language +binding specific value, and is used to store information about the execution context at +the time the language binding specific object reference is converted to an IDL value. + +Note: For ECMAScript objects, the [=callback context=] is used to hold a reference to the [=incumbent settings object=] at the time the Object value +is converted to an IDL callback interface type value. See [[#es-interface]]. + +There is no way to represent a constant object reference value for +a particular interface type in IDL. + +To denote a type that includes all possible references to objects implementing +the given interface plus the null value, +use a nullable type. + +The [=type name=] of an interface type +is the [=identifier=] of the interface. + + +

Dictionary types

+ +An [=identifier=] that +identifies a [=dictionary=] is used to refer to +a type that corresponds to the set of all dictionaries that adhere to +the dictionary definition. + +There is no way to represent a constant dictionary value in IDL. + +The [=type name=] of a dictionary type +is the [=identifier=] of the dictionary. + + +

Enumeration types

+ +An [=identifier=] that +identifies an [=enumeration=] is used to +refer to a type whose values are the set of strings (sequences of +[=code units=], as with +{{DOMString}}) that are the +[=enumeration values|enumeration’s values=]. + +Like {{DOMString}}, there is no way to represent a constant [=enumeration=] +value in IDL, although enumeration-typed [=dictionary member=] +[=dictionary member/default values=] can be specified using a +string literal. + +The [=type name=] of an enumeration type +is the [=identifier=] of the enumeration. + + +

Callback function types

+ +An [=identifier=] that identifies +a [=callback function=] is used to refer to +a type whose values are references to objects that are functions with the given signature. + +An IDL value of the callback function type is represented by a tuple of an object +reference and a [=callback context=]. + +Note: As with callback interface types, the [=callback context=] is used to hold a +reference to the [=incumbent settings object=] at +the time an ECMAScript Object value is converted to an IDL +callback function type value. See [[#es-callback-function]]. + +There is no way to represent a constant [=callback function=] +value in IDL. + +The [=type name=] of a callback function type +is the [=identifier=] of the callback function. + + +

Nullable types — |T|?

+ +A nullable type is an IDL type constructed +from an existing type (called the inner type), +which just allows the additional value null +to be a member of its set of values. [=Nullable types=] +are represented in IDL by placing a U+003F QUESTION MARK ("?") +character after an existing type. The inner type must not +be {{any}}, +another nullable type, or a [=union type=] +that itself has [=includes a nullable type=] +or has a dictionary type as one of its +[=flattened member types=]. + +Note: Although dictionary types can in general be nullable, they cannot when used +as the type of an operation argument or a dictionary member. + +Nullable type constant values in IDL are represented in the same way that +constant values of their [=inner type=] +would be represented, or with the null token. + +The [=type name=] of a nullable type +is the concatenation of the type name of the inner type |T| and +the string “OrNull”. + +
+ + For example, a type that allows the values true, + false and null + is written as boolean?: + +
+        interface MyConstants {
+          const boolean? ARE_WE_THERE_YET = false;
+        };
+    
+ + The following [=interface=] has two + [=attributes=]: one whose value can + be a {{DOMString}} or the null + value, and another whose value can be a reference to a Node + object or the null value: + +
+        interface Node {
+          readonly attribute DOMString? namespaceURI;
+          readonly attribute Node? parentNode;
+          // ...
+        };
+    
+
+ + +

Sequences — sequence<|T|>

+ +The sequence<|T|> +type is a parameterized type whose values are (possibly zero-length) sequences of +values of type |T|. + +Sequences are always passed by value. In +language bindings where a sequence is represented by an object of +some kind, passing a sequence to a [=platform object=] +will not result in a reference to the sequence being kept by that object. +Similarly, any sequence returned from a platform object +will be a copy and modifications made to it will not be visible to the platform object. + +There is no way to represent a constant sequence value in IDL. + +Sequences must not be used as the +type of an [=attribute=] or +[=constant=]. + +Note: This restriction exists so that it is clear to specification writers +and API users that sequences +are copied rather than having references +to them passed around. Instead of a writable [=attribute=] of a sequence +type, it is suggested that a pair of [=operations=] to get and set the +sequence is used. + +The [=type name=] of a sequence type +is the concatenation of the type name for |T| and +the string “Sequence”. + + +

Promise types — Promise<|T|>

+ +A promise type is a parameterized type +whose values are references to objects that “is used as a place holder +for the eventual results of a deferred (and possibly asynchronous) computation +result of an asynchronous operation”. +See section 25.4 +of the ECMAScript specification for details on the semantics of promise objects. + +There is no way to represent a promise value in IDL. + +The [=type name=] of a promise type +is the concatenation of the type name for |T| and +the string “Promise”. + + +

Union types

+ +A union type is a type whose set of values +is the union of those in two or more other types. Union types (matching +UnionType) +are written as a series of types separated by the or keyword +with a set of surrounding parentheses. +The types which comprise the union type are known as the +union’s member types. + +
+ + For example, you might write (Node or DOMString) + or (double or sequence<double>). When applying a + ? suffix to a + [=union type=] + as a whole, it is placed after the closing parenthesis, + as in (Node or DOMString)?. + + Note that the [=member types=] + of a union type do not descend into nested union types. So for + (double or (sequence<long> or Event) or (Node or DOMString)?) the member types + are double, (sequence<long> or Event) and + (Node or DOMString)?. + +
+ +Like the {{any}} type, values of +union types have a [=specific type=], +which is the particular [=member type=] +that matches the value. + +The flattened member types +of a [=union type=] is a set of types +determined as follows: + +
    + 1. Let |T| be the [=union type=]. + 1. Initialize |S| to ∅. + 1. For each [=member type=] |U| of |T|: + 1. If |U| is a [=nullable type=], then + set |U| to be the [=inner type=] of |U|. + 1. If |U| is a [=union type=], then + add to |S| the [=flattened member types=] + of |U|. + 1. Otherwise, |U| is not a [=union type=]. + Add |U| to |S|. + 1. Return |S|. +
+ +Note: For example, the [=flattened member types=] +of the [=union type=] +(Node or (sequence<long> or Event) or (XMLHttpRequest or DOMString)? or sequence<(sequence<double> or NodeList)>) +are the six types Node, sequence<long>, Event, +XMLHttpRequest, DOMString and +sequence<(sequence<double> or NodeList)>. + +The number of nullable member types +of a [=union type=] is an integer +determined as follows: + +
    + 1. Let |T| be the [=union type=]. + 1. Initialize |n| to 0. + 1. For each [=member type=] |U| of |T|: + 1. If |U| is a [=nullable type=], then: + 1. Set |n| to |n| + 1. + 1. Set |U| to be the [=inner type=] of |U|. + 1. If |U| is a [=union type=], then: + 1. Let |m| be the [=number of nullable member types=] of |U|. + 1. Set |n| to |n| + |m|. + 1. Return |n|. +
+ +The {{any}} type must not +be used as a [=member types|union member type=]. + +The [=number of nullable member types=] +of a [=union type=] must +be 0 or 1, and if it is 1 then the union type must also not have +a [=dictionary type=] in its +[=flattened member types=]. + +A type includes a nullable type if: + +* the type is a [=nullable type=], or +* the type is a [=union type=] and its + [=number of nullable member types=] is 1. + +Each pair of [=flattened member types=] +in a [=union type=], |T| and |U|, +must be [=distinguishable=]. + +[=Union type=] constant values +in IDL are represented in the same way that constant values of their +[=member types=] would be +represented. + +The [=type name=] of a union +type is formed by taking the type names of each member type, in order, +and joining them with the string “Or”. + +
+ +
+ +
+ +
+ + +

RegExp

+ +The {{RegExp}} type is a type +whose values are references to objects that represent regular expressions. +The particular regular expression language and the features it supports +is language binding specific. + +There is no way to represent a constant {{RegExp}} +value in IDL. + +The [=type name=] of the +{{RegExp}} type is “RegExp”. + + +

Error

+ +The {{Error!!interface}} type corresponds to the +set of all possible non-null references to exception objects, including +[=simple exceptions=] +and {{DOMException|DOMExceptions}}. + +There is no way to represent a constant {{Error!!interface}} +value in IDL. + +The [=type name=] of the +{{Error!!interface}} type is “Error”. + + +

DOMException

+ +The {{DOMException}} type corresponds to the +set of all possible non-null references to objects +representing {{DOMException|DOMExceptions}}. + +There is no way to represent a constant {{DOMException}} +value in IDL. + +The [=type name=] of the +{{DOMException}} type is “DOMException”. + + +

Buffer source types

+ +There are a number of types that correspond to sets of all possible non-null +references to objects that represent a buffer of data or a view on to a buffer of +data. The table below lists these types and the kind of buffer or view they represent. + + + + + + + + + + + + + +
TypeKind of buffer
ArrayBufferAn object that holds a pointer (which may be null) to a buffer of a fixed number of bytes
DataViewA view on to an {{ArrayBuffer}} that allows typed access to integers and floating point values stored at arbitrary offsets into the buffer
+ Int8Array,
+ Int16Array,
+ Int32Array
A view on to an {{ArrayBuffer}} that exposes it as an array of two’s complement signed integers of the given size in bits
+ Uint8Array,
+ Uint16Array,
+ Uint32Array
A view on to an {{ArrayBuffer}} that exposes it as an array of unsigned integers of the given size in bits
Uint8ClampedArrayA view on to an {{ArrayBuffer}} that exposes it as an array of unsigned 8 bit integers with clamped conversions
+ Float32Array,
+ Float64Array
A view on to an {{ArrayBuffer}} that exposes it as an array of IEEE 754 floating point numbers of the given size in bits
+ +Note: These types all correspond to classes defined in ECMAScript. + +To detach an {{ArrayBuffer}} +is to set its buffer pointer to null. + +There is no way to represent a constant value of any of these types in IDL. + +The [=type name=] of all +of these types is the name of the type itself. + +At the specification prose level, IDL [=buffer source types=] +are simply references to objects. To inspect or manipulate the bytes inside the buffer, +specification prose must first either +get a reference to the bytes held by the buffer source +or get a copy of the bytes held by the buffer source. +With a reference to the buffer source’s bytes, specification prose can get or set individual +byte values using that reference. + +
+ + Extreme care must be taken when writing specification text that gets a reference + to the bytes held by a buffer source, as the underyling data can easily be changed + by the script author or other APIs at unpredictable times. If you are using a buffer source type + as an operation argument to obtain a chunk of binary data that will not be modified, + it is strongly recommended to get a copy of the buffer source’s bytes at the beginning + of the prose defining the operation. + + Requiring prose to explicitly get a reference to or copy of the bytes is intended to + help specification reviewers look for problematic uses of these buffer source types. + +
+ +
+ + When designing APIs that take a buffer, it is recommended to use the + {{BufferSource}} typedef rather than {{ArrayBuffer}} + or any of the view types. + + When designing APIs that create and return a buffer, it is recommended + to use the {{ArrayBuffer}} type rather than + {{Uint8Array}}. + +
+ +Attempting to [=get a reference to the buffer source|get a reference to=] or +[=get a copy of the buffer source|get a copy of the bytes held by a buffer source=] +when the {{ArrayBuffer}} has been [=detach|detached=] +will fail in a language binding-specific manner. + +Note: See [[#es-buffer-source-types]] below for +how interacting with buffer source types works in the ECMAScript language binding. + +

+ We should include an example of specification text that uses these types and terms. +

+ +
+    BufferRelatedType :
+        "ArrayBuffer"
+        "DataView"
+        "Int8Array"
+        "Int16Array"
+        "Int32Array"
+        "Uint8Array"
+        "Uint16Array"
+        "Uint32Array"
+        "Uint8ClampedArray"
+        "Float32Array"
+        "Float64Array"
+
+ + +

Frozen arrays — FrozenArray<|T|>

+ +A frozen array type is a parameterized +type whose values are references to objects that hold a fixed length array +of unmodifiable values. The values in the array are of type |T|. + +Since FrozenArray<|T|> values +are references, they are unlike sequence types, +which are lists of values that are passed by value. + +There is no way to represent a constant frozen array value in IDL. + +The [=type name=] of a frozen array +type is the concatenation of the type name for |T| and the string +“Array”. + + +

Extended attributes

+ +An extended attribute is an annotation +that can appear on +definitions, +[=interface members=], +[=namespace members=], +[=dictionary members=], +and [=operation=] arguments, and +is used to control how language bindings will handle those constructs. +Extended attributes are specified with an +ExtendedAttributeList, +which is a square bracket enclosed, comma separated list of +ExtendedAttributes. + +The ExtendedAttribute +grammar symbol matches nearly any sequence of tokens, however the +[=extended attributes=] +defined in this document only accept a more restricted syntax. +Any extended attribute encountered in an +[=IDL fragment=] is +matched against the following six grammar symbols to determine +which form (or forms) it is in: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Grammar symbolFormExample
+ ExtendedAttributeNoArgs + + takes no arguments + + [Replaceable] +
+ ExtendedAttributeArgList + + takes an argument list + + [Constructor(double x, double y)] +
+ ExtendedAttributeNamedArgList + + takes a named argument list + + [NamedConstructor=Image(DOMString src)] +
+ ExtendedAttributeIdent + + takes an identifier + + [PutForwards=name] +
+ ExtendedAttributeIdentList + + takes an identifier list + + [Exposed=(Window,Worker)] +
+ +This specification defines a number of extended attributes that +are applicable to the ECMAScript language binding, which are described in +[[#es-extended-attributes]]. +Each extended attribute definition will state which of the above +six forms are allowed. + +
+    ExtendedAttributeList :
+        "[" ExtendedAttribute ExtendedAttributes "]"
+        ε
+
+ +
+    ExtendedAttributes :
+        "," ExtendedAttribute ExtendedAttributes
+        ε
+
+ +
+    ExtendedAttribute :
+        "(" ExtendedAttributeInner ")" ExtendedAttributeRest
+        "[" ExtendedAttributeInner "]" ExtendedAttributeRest
+        "{" ExtendedAttributeInner "}" ExtendedAttributeRest
+        Other ExtendedAttributeRest
+
+ +
+    ExtendedAttributeRest :
+        ExtendedAttribute
+        ε
+
+ +
+    ExtendedAttributeInner :
+        "(" ExtendedAttributeInner ")" ExtendedAttributeInner
+        "[" ExtendedAttributeInner "]" ExtendedAttributeInner
+        "{" ExtendedAttributeInner "}" ExtendedAttributeInner
+        OtherOrComma ExtendedAttributeInner
+        ε
+
+ +
+    Other :
+        integer
+        float
+        identifier
+        string
+        other
+        "-"
+        "-Infinity"
+        "."
+        "..."
+        ":"
+        ";"
+        "<"
+        "="
+        ">"
+        "?"
+        "ByteString"
+        "DOMString"
+        "FrozenArray"
+        "Infinity"
+        "NaN"
+        "RegExp"
+        "USVString"
+        "any"
+        "boolean"
+        "byte"
+        "double"
+        "false"
+        "float"
+        "long"
+        "null"
+        "object"
+        "octet"
+        "or"
+        "optional"
+        "sequence"
+        "short"
+        "true"
+        "unsigned"
+        "void"
+        ArgumentNameKeyword
+        BufferRelatedType
+
+ +
+    OtherOrComma :
+        Other
+        ","
+
+ +
+    IdentifierList :
+        identifier Identifiers
+
+ +
+ +
+    ExtendedAttributeNoArgs :
+        identifier
+
+ +
+    ExtendedAttributeArgList :
+        identifier "(" ArgumentList ")"
+
+ +
+    ExtendedAttributeIdent :
+        identifier "=" identifier
+
+ +
+    ExtendedAttributeIdentList :
+        identifier "=" "(" IdentifierList ")"
+
+ +
+    ExtendedAttributeNamedArgList :
+        identifier "=" identifier "(" ArgumentList ")"
+
+ + +

ECMAScript binding

+ +This section describes how definitions written with the IDL defined in +[[#idl]] correspond to particular constructs +in ECMAScript, as defined by the ECMAScript Language Specification 6th Edition +[[!ECMA-262]]. + +Objects defined in this section have internal properties as described in +ECMA-262 [=sections 9.1=] and +[=9.3.1=] unless otherwise specified, in which case one or +more of the following are redefined in accordance with the rules for exotic objects: +\[[Call]], +\[[Set]], +\[[DefineOwnProperty]], +\[[GetOwnProperty]], +\[[Delete]] and +\[[HasInstance]]. + +Other specifications may override the definitions +of any internal method of a [=platform object=] +that is an instance of an [=interface=]. + +

+ As overriding internal ECMAScript object methods is a low level operation and + can result in objects that behave differently from ordinary objects, + this facility should not be used unless necessary + for security or compatibility. The expectation is that this will be used + for Location objects + and possibly WindowProxy objects. +

+ +Unless otherwise specified, the \[[Extensible]] internal property +of objects defined in this section has the value true. + +Unless otherwise specified, the \[[Prototype]] internal property +of objects defined in this section is the Object prototype object. + +Some objects described in this section are defined to have a class string, +which is the string to include in the string returned from Object.prototype.toString. +If an object has a class string, then the object must, +at the time it is created, have a property whose name is the [=@@toStringTag=] symbol +and whose value is the specified string. + +

+ Should define whether [=@@toStringTag=] is writable, enumerable and configurable. + All [=@@toStringTag=] properties in the ES6 spec are non-writable and non-enumerable, + and configurable. +

+ +If an object is defined to be a function object, then +it has characteristics as follows: + +* Its \[[Prototype]] internal property is + [=%FunctionPrototype%=] unless otherwise specified. +* Its \[[Get]] internal property is set as described in [=ECMA-262 section 9.1.8=]. +* Its \[[Construct]] internal property is set as described in [=ECMA-262 section 19.2.2.3=]. +* Its @@hasInstance property is set as described in [=ECMA-262 section 19.2.3.8=], unless otherwise specified. + +

+ The list above needs updating for the latest ES6 draft. +

+ +

+ Algorithms in this section use the conventions described in [=ECMA-262 section 5.2=], such as the use of steps and substeps, the use of mathematical + operations, and so on. The + [=ToBoolean=], + [=ToNumber=], + [=ToUint16=], + [=ToInt32=], + [=ToUint32=], + [=ToString=], + [=ToObject=], + [=IsAccessorDescriptor=] and + [=IsDataDescriptor=] abstract operations and the + [=Type|Type(x)=] + notation referenced in this section are defined in ECMA-262 sections 6 and 7. +

+ +When an algorithm says to +throw a SomethingError +then this means to construct a new ECMAScript SomethingError object +and to throw it, just as the algorithms in ECMA-262 do. + +Note that algorithm steps can call in to other algorithms and abstract operations and +not explicitly handle exceptions that are thrown from them. When an exception +is thrown by an algorithm or abstract operation and it is not explicitly +handled by the caller, then it is taken to end the algorithm and propagate out +to its caller, and so on. + +
+ + Consider the following algorithm: + +
    + 1. Let |x| be the ECMAScript value passed in to this algorithm. + 1. Let |y| be the result of calling [=ToString=](|x|). + 1. Return |y|. +
+ + Since [=ToString=] can throw an exception (for example if passed the object + ({ toString: function() { throw 1 } })), and the exception is + not handled in the above algorithm, if one is thrown then it causes this + algorithm to end and for the exception to propagate out to its caller, if there + is one. + +
+ + +

ECMAScript environment

+ +In an ECMAScript implementation of a given set of +[=IDL fragments=], +there will exist a number of ECMAScript objects that correspond to +definitions in those [=IDL fragments=]. +These objects are termed the initial objects, +and comprise the following: + +* [=interface objects=] +* [=named constructors=] +* [=interface prototype objects=] +* [=named properties objects=] +* [=iterator prototype objects=] +* [=attribute getters=] +* [=attribute setters=] +* the Function objects that correspond to operations +* the Function objects that correspond to stringifiers +* the Function objects that correspond to serializers +* the Function objects that correspond to iterators +* [=default unforgeable valueOf functions=] +* [=map size getters=] +* [=DOMException constructor objects=] +* [=DOMException prototype objects=] +* [=named properties objects=] + +Each [=Realms|ECMAScript global environment=] +must have its own unique set of each of +the [=initial objects=], created +before control enters any ECMAScript execution context associated with the +environment, but after the global object for that environment is created. The \[[Prototype]]s +of all initial objects in a given global environment must come from +that same global environment. + +
+ + In an HTML user agent, multiple global environments can exist when + multiple frames or windows are created. Each frame or window will have + its own set of [=initial objects=], + which the following HTML document demonstrates: + +
+        <!DOCTYPE html>
+        <title>Different global environments</title>
+        <iframe id=a></iframe>
+        <script>
+        var iframe = document.getElementById("a");
+        var w = iframe.contentWindow;              // The global object in the frame
+        
+        Object == w.Object;                        // Evaluates to false, per ECMA-262
+        Node == w.Node;                            // Evaluates to false
+        iframe instanceof w.Node;                  // Evaluates to false
+        iframe instanceof w.Object;                // Evaluates to false
+        iframe.appendChild instanceof Function;    // Evaluates to true
+        iframe.appendChild instanceof w.Function;  // Evaluates to false
+        </script>
+    
+
+ +Unless otherwise specified, each ECMAScript global environment exposes +all [=interfaces=] +that the implementation supports. If a given ECMAScript global environment does not +expose an interface, then the requirements given in +[[#es-interfaces]] are +not followed for that interface. + +Note: This allows, for example, ECMAScript global environments for Web Workers to [=ECMAScript global environment/expose=] +different sets of supported interfaces from those exposed in environments +for Web pages. + +Although at the time of this writing the ECMAScript specification does not reflect this, +every ECMAScript object must have an associated [=Realm=]. The mechanisms +for associating objects with Realms are, for now, underspecified. However, we note that +in the case of [=platform objects=], the +associated Realm is equal to the object's [=relevant Realm=], and +for non-exotic function objects (i.e. not callable proxies, and not bound functions) +the associated Realm is equal to the value of the function object's \[[Realm]] internal +slot. + + +

ECMAScript type mapping

+ +This section describes how types in the IDL map to types in ECMAScript. + +Each sub-section below describes how values of a given IDL type are represented +in ECMAScript. For each IDL type, it is described how ECMAScript values are +converted to an IDL value +when passed to a [=platform object=] expecting that type, and how IDL values +of that type are converted to ECMAScript values +when returned from a platform object. + + +

any

+ +Since the IDL {{any}} type +is the union of all other IDL types, it can correspond to any +ECMAScript value type. + +

+ How to [=converted to an IDL value|convert an ECMAScript value=] to an IDL {{any}} value depends on the type of the + ECMAScript value: +

+ +
+ : The undefined value + :: The IDL value is an + {{object}} reference + to a special object that represents the ECMAScript + undefined value. + : The null value + :: The IDL value is the null + {{object|object?}} reference. + : A Boolean value + :: The IDL value is the + {{boolean}} + value that represents the same truth value. + : A Number value + :: The IDL value is that which is obtained + by following the rules for converting the + Number to an IDL + {{unrestricted double}} value, + as described in [[#es-unrestricted-double]]. + : A String value + :: The IDL value is that which is obtained + by following the rules for converting the + String to an IDL + {{DOMString}} value, + as described in [[#es-DOMString]]. + : An {{object}} value + :: The IDL value is an + {{object}} value that + references the same object. +
+ +

+ An IDL {{any}} value is + [=converted to an ECMAScript value=] + as follows. If the value is an {{object}} + reference to a special object that represents an ECMAScript undefined + value, then it is converted to the ECMAScript + undefined value. Otherwise, + the rules for converting the [=specific type=] + of the IDL {{any}} value + as described in the remainder of this section are performed. +

+ + +

void

+ +The only place that the {{void}} type may appear +in IDL is as the [=return type=] of an +[=operation=]. Functions on [=platform objects=] +that implement an operation whose IDL specifies a +{{void}} return type must return the +undefined value. + +ECMAScript functions that implement an operation whose IDL +specifies a {{void}} return type +may return any value, which will be discarded. + + +

boolean

+ +

+ An ECMAScript value |V| is + [=converted to an IDL value|converted=] + to an IDL {{boolean}} value + by running the following algorithm: +

+ +
    + 1. Let |x| be the result of computing [=ToBoolean=](|V|). + 1. Return the IDL {{boolean}} value that is the one that represents the same truth value as the ECMAScript Boolean value |x|. +
+ +

+ The IDL {{boolean}} value true + is [=converted to an ECMAScript value|converted=] to + the ECMAScript true value and the IDL {{boolean}} + value false is converted to the ECMAScript + false value. +

+ + +

byte

+ +

+ An ECMAScript value |V| is + [=converted to an IDL value|converted=] + to an IDL {{byte}} value + by running the following algorithm: +

+ +
    + 1. Initialize |x| to [=ToNumber=](|V|). + 1. If the conversion to an IDL value is being performed due to any of the following: + * |V| is being assigned to an [=attribute=] annotated with the [{{EnforceRange}}] [=extended attribute=], + * |V| is being passed as an [=operation=] argument annotated with the [{{EnforceRange}}] extended attribute, or + * |V| is being used as the value of a [=dictionary member=] annotated with the [{{EnforceRange}}] extended attribute, + + then: + + 1. If |x| is NaN, +∞, or −∞, then throw a TypeError. + 1. Set |x| to [=sign=](|x|) * [=floor=]([=abs=](|x|)). + 1. If |x| < −27 or |x| > 27 − 1, then throw a TypeError. + 1. Return the IDL {{byte}} value that represents the same numeric value as |x|. + 1. If |x| is not NaN and the conversion to an IDL value is being performed due to any of the following: + * |V| is being assigned to an [=attribute=] annotated with the [{{Clamp}}] [=extended attribute=], + * |V| is being passed as an [=operation=] argument annotated with the [{{Clamp}}] extended attribute, or + * |V| is being used as the value of a [=dictionary member=] annotated with the [{{Clamp}}] extended attribute, + + then: + + 1. Set |x| to min(max(|x|, −27), 27 − 1). + 1. Round |x| to the nearest integer, choosing the even integer if it lies halfway between two, and choosing +0 rather than −0. + 1. Return the IDL {{byte}} value that represents the same numeric value as |x|. + 1. If |x| is NaN, +0, −0, +∞, or −∞, then return the IDL {{byte}} value that represents 0. + 1. Set |x| to [=sign=](|x|) * [=floor=]([=abs=](|x|)). + 1. Set |x| to |x| [=modulo=] 28. + 1. If |x| ≥ 27, return the IDL {{byte}} value that represents the same numeric value as |x| − 28. + Otherwise, return the IDL {{byte}} value that represents the same numeric value as |x|. +
+ +

+ The result of [=converted to an ECMAScript value|converting=] + an IDL {{byte}} value to an ECMAScript + value is a Number that represents + the same numeric value as the IDL {{byte}} value. + The Number value will be an integer in the range [−128, 127]. +

+ + +

octet

+ +

+ An ECMAScript value |V| is + [=converted to an IDL value|converted=] + to an IDL {{octet}} value + by running the following algorithm: +

+ +
    + 1. Initialize |x| to [=ToNumber=](|V|). + 1. If the conversion to an IDL value is being performed due to any of the following: + * |V| is being assigned to an [=attribute=] annotated with the [{{EnforceRange}}] [=extended attribute=], + * |V| is being passed as an [=operation=] argument annotated with the [{{EnforceRange}}] extended attribute, or + * |V| is being used as the value of a [=dictionary member=] annotated with the [{{EnforceRange}}] extended attribute, + + then: + + 1. If |x| is NaN, +∞, or −∞, then throw a TypeError. + 1. Set |x| to [=sign=](|x|) * [=floor=]([=abs=](|x|)). + 1. If |x| < 0 or |x| > 28 − 1, then throw a TypeError. + 1. Return the IDL {{octet}} value that represents the same numeric value as |x|. + 1. If |x| is not NaN and the conversion to an IDL value is being performed due to any of the following: + * |V| is being assigned to an [=attribute=] annotated with the [{{Clamp}}] [=extended attribute=], + * |V| is being passed as an [=operation=] argument annotated with the [{{Clamp}}] extended attribute, or + * |V| is being used as the value of a [=dictionary member=] annotated with the [{{Clamp}}] extended attribute, + + then: + + 1. Set |x| to min(max(|x|, 0), 28 − 1). + 1. Round |x| to the nearest integer, choosing the even integer if it lies halfway between two, and choosing +0 rather than −0. + 1. Return the IDL {{octet}} value that represents the same numeric value as |x|. + 1. If |x| is NaN, +0, −0, +∞, or −∞, then return the IDL {{octet}} value that represents 0. + 1. Set |x| to [=sign=](|x|) * [=floor=]([=abs=](|x|)). + 1. Set |x| to |x| [=modulo=] 28. + 1. Return the IDL {{octet}} value that represents the same numeric value as |x|. +
+ +

+ The result of [=converted to an ECMAScript value|converting=] + an IDL {{octet}} value to an ECMAScript + value is a Number that represents + the same numeric value as the IDL + {{octet}} value. + The Number value will be an integer in the range [0, 255]. +

+ + +

short

+ +

+ An ECMAScript value |V| is + [=converted to an IDL value|converted=] + to an IDL {{short}} value + by running the following algorithm: +

+ +
    + 1. Initialize |x| to [=ToNumber=](|V|). + 1. If the conversion to an IDL value is being performed due to any of the following: + * |V| is being assigned to an [=attribute=] annotated with the [{{EnforceRange}}] [=extended attribute=], + * |V| is being passed as an [=operation=] argument annotated with the [{{EnforceRange}}] extended attribute, or + * |V| is being used as the value of a [=dictionary member=] annotated with the [{{EnforceRange}}] extended attribute, + + then: + + 1. If |x| is NaN, +∞, or −∞, then throw a TypeError. + 1. Set |x| to [=sign=](|x|) * [=floor=]([=abs=](|x|)). + 1. If |x| < −215 or |x| > 215 − 1, then throw a TypeError. + 1. Return the IDL {{short}} value that represents the same numeric value as |x|. + 1. If |x| is not NaN and the conversion to an IDL value is being performed due to any of the following: + * |V| is being assigned to an [=attribute=] annotated with the [{{Clamp}}] [=extended attribute=], + * |V| is being passed as an [=operation=] argument annotated with the [{{Clamp}}] extended attribute, or + * |V| is being used as the value of a [=dictionary member=] annotated with the [{{Clamp}}] extended attribute, + + then: + + 1. Set |x| to min(max(|x|, −215), 215 − 1). + 1. Round |x| to the nearest integer, choosing the even integer if it lies halfway between two, and choosing +0 rather than −0. + 1. Return the IDL {{short}} value that represents the same numeric value as |x|. + 1. If |x| is NaN, +0, −0, +∞, or −∞, then return the IDL {{short}} value that represents 0. + 1. Set |x| to [=sign=](|x|) * [=floor=]([=abs=](|x|)). + 1. Set |x| to |x| [=modulo=] 216. + 1. If |x| ≥ 215, return the IDL {{short}} value that represents the same numeric value as |x| − 216. + Otherwise, return the IDL {{short}} value that represents the same numeric value as |x|. +
+ +

+ The result of [=converted to an ECMAScript value|converting=] + an IDL {{short}} value to an ECMAScript + value is a Number that represents the + same numeric value as the IDL + {{short}} value. + The Number value will be an integer in the range [−32768, 32767]. +

+ + +

unsigned short

+ +

+ An ECMAScript value |V| is + [=converted to an IDL value|converted=] + to an IDL {{unsigned short}} value + by running the following algorithm: +

+ +
    + 1. Initialize |x| to [=ToNumber=](|V|). + 1. If the conversion to an IDL value is being performed due to any of the following: + * |V| is being assigned to an [=attribute=] annotated with the [{{EnforceRange}}] [=extended attribute=], + * |V| is being passed as an [=operation=] argument annotated with the [{{EnforceRange}}] extended attribute, or + * |V| is being used as the value of a [=dictionary member=] annotated with the [{{EnforceRange}}] extended attribute, + + then: + + 1. If |x| is NaN, +∞, or −∞, then throw a TypeError. + 1. Set |x| to [=sign=](|x|) * [=floor=]([=abs=](|x|)). + 1. If |x| < 0 or |x| > 216 − 1, then throw a TypeError. + 1. Return the IDL {{unsigned short}} value that represents the same numeric value as |x|. + 1. If |x| is not NaN and the conversion to an IDL value is being performed due to any of the following: + * |V| is being assigned to an [=attribute=] annotated with the [{{Clamp}}] [=extended attribute=], + * |V| is being passed as an [=operation=] argument annotated with the [{{Clamp}}] extended attribute, or + * |V| is being used as the value of a [=dictionary member=] annotated with the [{{Clamp}}] extended attribute, + + then: + + 1. Set |x| to min(max(|x|, 0), 216 − 1). + 1. Round |x| to the nearest integer, choosing the even integer if it lies halfway between two, and choosing +0 rather than −0. + 1. Return the IDL {{unsigned short}} value that represents the same numeric value as |x|. + 1. Set |x| to [=ToUint16=](|x|). + 1. Return the IDL {{unsigned short}} value that represents the same numeric value as |x|. +
+ +

+ The result of [=converted to an ECMAScript value|converting=] + an IDL {{unsigned short}} value to an ECMAScript + value is a Number that + represents the same numeric value as the IDL + {{unsigned short}} value. + The Number value will be an integer in the range [0, 65535]. +

+ + +

long

+ +

+ An ECMAScript value |V| is + [=converted to an IDL value|converted=] + to an IDL {{long}} value + by running the following algorithm: +

+ +
    + 1. Initialize |x| to [=ToNumber=](|V|). + 1. If the conversion to an IDL value is being performed due to any of the following: + * |V| is being assigned to an [=attribute=] annotated with the [{{EnforceRange}}] [=extended attribute=], + * |V| is being passed as an [=operation=] argument annotated with the [{{EnforceRange}}] extended attribute, or + * |V| is being used as the value of a [=dictionary member=] annotated with the [{{EnforceRange}}] extended attribute, + + then: + + 1. If |x| is NaN, +∞, or −∞, then throw a TypeError. + 1. Set |x| to [=sign=](|x|) * [=floor=]([=abs=](|x|)). + 1. If |x| < −231 or |x| > 231 − 1, then throw a TypeError. + 1. Return the IDL {{long}} value that represents the same numeric value as |x|. + 1. If |x| is not NaN and the conversion to an IDL value is being performed due to any of the following: + * |V| is being assigned to an [=attribute=] annotated with the [{{Clamp}}] [=extended attribute=], + * |V| is being passed as an [=operation=] argument annotated with the [{{Clamp}}] extended attribute, or + * |V| is being used as the value of a [=dictionary member=] annotated with the [{{Clamp}}] extended attribute, + + then: + + 1. Set |x| to min(max(|x|, −231), 231 − 1). + 1. Round |x| to the nearest integer, choosing the even integer if it lies halfway between two, and choosing +0 rather than −0. + 1. Return the IDL {{long}} value that represents the same numeric value as |x|. + 1. Set |x| to [=ToInt32=](|x|). + 1. Return the IDL {{long}} value that represents the same numeric value as |x|. +
+ +

+ The result of [=converted to an ECMAScript value|converting=] + an IDL {{long}} value to an ECMAScript + value is a Number that + represents the same numeric value as the IDL + {{long}} value. + The Number value will be an integer in the range [−2147483648, 2147483647]. +

+ + +

unsigned long

+ +

+ An ECMAScript value |V| is + [=converted to an IDL value|converted=] + to an IDL {{unsigned long}} value + by running the following algorithm: +

+ +
    + 1. Initialize |x| to [=ToNumber=](|V|). + 1. If the conversion to an IDL value is being performed due to any of the following: + * |V| is being assigned to an [=attribute=] annotated with the [{{EnforceRange}}] [=extended attribute=], + * |V| is being passed as an [=operation=] argument annotated with the [{{EnforceRange}}] extended attribute, or + * |V| is being used as the value of a [=dictionary member=] annotated with the [{{EnforceRange}}] extended attribute, + + then: + + 1. If |x| is NaN, +∞, or −∞, then throw a TypeError. + 1. Set |x| to [=sign=](|x|) * [=floor=]([=abs=](|x|)). + 1. If |x| < 0 or |x| > 232 − 1, then throw a TypeError. + 1. Return the IDL {{unsigned long}} value that represents the same numeric value as |x|. + 1. If |x| is not NaN and the conversion to an IDL value is being performed due to any of the following: + * |V| is being assigned to an [=attribute=] annotated with the [{{Clamp}}] [=extended attribute=], + * |V| is being passed as an [=operation=] argument annotated with the [{{Clamp}}] extended attribute, or + * |V| is being used as the value of a [=dictionary member=] annotated with the [{{Clamp}}] extended attribute, + + then: + + 1. Set |x| to min(max(|x|, 0), 232 − 1). + 1. Round |x| to the nearest integer, choosing the even integer if it lies halfway between two, and choosing +0 rather than −0. + 1. Return the IDL {{unsigned long}} value that represents the same numeric value as |x|. + 1. Set |x| to [=ToUint32=](|x|). + 1. Return the IDL {{unsigned long}} value that represents the same numeric value as |x|. +
+ +

+ The result of [=converted to an ECMAScript value|converting=] + an IDL {{unsigned long}} value to an ECMAScript + value is a Number that + represents the same numeric value as the IDL + {{unsigned long}} value. + The Number value will be an integer in the range [0, 4294967295]. +

+ + +

long long

+ +

+ An ECMAScript value |V| is + [=converted to an IDL value|converted=] + to an IDL {{long long}} value + by running the following algorithm: +

+ +
    + 1. Initialize |x| to [=ToNumber=](|V|). + 1. If the conversion to an IDL value is being performed due to any of the following: + * |V| is being assigned to an [=attribute=] annotated with the [{{EnforceRange}}] [=extended attribute=], + * |V| is being passed as an [=operation=] argument annotated with the [{{EnforceRange}}] extended attribute, or + * |V| is being used as the value of a [=dictionary member=] annotated with the [{{EnforceRange}}] extended attribute, + + then: + + 1. If |x| is NaN, +∞, or −∞, then throw a TypeError. + 1. Set |x| to [=sign=](|x|) * [=floor=]([=abs=](|x|)). + 1. If |x| < −253 + 1 or |x| > 253 − 1, then throw a TypeError. + 1. Return the IDL {{long long}} value that represents the same numeric value as |x|. + 1. If |x| is not NaN and the conversion to an IDL value is being performed due to any of the following: + * |V| is being assigned to an [=attribute=] annotated with the [{{Clamp}}] [=extended attribute=], + * |V| is being passed as an [=operation=] argument annotated with the [{{Clamp}}] extended attribute, or + * |V| is being used as the value of a [=dictionary member=] annotated with the [{{Clamp}}] extended attribute, + + then: + + 1. Set |x| to min(max(|x|, −253 + 1), 253 − 1). + 1. Round |x| to the nearest integer, choosing the even integer if it lies halfway between two, and choosing +0 rather than −0. + 1. Return the IDL {{long long}} value that represents the same numeric value as |x|. + 1. If |x| is NaN, +0, −0, +∞, or −∞, then return the IDL {{long long}} value that represents 0. + 1. Set |x| to [=sign=](|x|) * [=floor=]([=abs=](|x|)). + 1. Set |x| to |x| [=modulo=] 264. + 1. If |x| is greater than or equal to 263, then set |x| to |x| − 264. + 1. Return the IDL {{long long}} value that represents the same numeric value as |x|. +
+ +

+ The result of [=converted to an ECMAScript value|converting=] + an IDL {{long long}} value to an ECMAScript + value is a Number value that + represents the closest numeric value to the {{long long}}, + choosing the numeric value with an even significand if there are + two [=equally close values=]. + If the {{long long}} is in the range + [−253 + 1, 253 − 1], then the Number + will be able to represent exactly the same value as the + {{long long}}. +

+ + +

unsigned long long

+ +

+ An ECMAScript value |V| is + [=converted to an IDL value|converted=] + to an IDL {{unsigned long long}} value + by running the following algorithm: +

+ +
    + 1. Initialize |x| to [=ToNumber=](|V|). + 1. If the conversion to an IDL value is being performed due to any of the following: + * |V| is being assigned to an [=attribute=] annotated with the [{{EnforceRange}}] [=extended attribute=], + * |V| is being passed as an [=operation=] argument annotated with the [{{EnforceRange}}] extended attribute, or + * |V| is being used as the value of a [=dictionary member=] annotated with the [{{EnforceRange}}] extended attribute, + + then: + + 1. If |x| is NaN, +∞, or −∞, then throw a TypeError. + 1. Set |x| to [=sign=](|x|) * [=floor=]([=abs=](|x|)). + 1. If |x| < 0 or |x| > 253 − 1, then throw a TypeError. + 1. Return the IDL {{unsigned long long}} value that represents the same numeric value as |x|. + 1. If |x| is not NaN and the conversion to an IDL value is being performed due to any of the following: + * |V| is being assigned to an [=attribute=] annotated with the [{{Clamp}}] [=extended attribute=], + * |V| is being passed as an [=operation=] argument annotated with the [{{Clamp}}] extended attribute, or + * |V| is being used as the value of a [=dictionary member=] annotated with the [{{Clamp}}] extended attribute, + + then: + + 1. Set |x| to min(max(|x|, 0), 253 − 1). + 1. Round |x| to the nearest integer, choosing the even integer if it lies halfway between two, and choosing +0 rather than −0. + 1. Return the IDL {{unsigned long long}} value that represents the same numeric value as |x|. + 1. If |x| is NaN, +0, −0, +∞, or −∞, then return the IDL {{unsigned long long}} value that represents 0. + 1. Set |x| to [=sign=](|x|) * [=floor=]([=abs=](|x|)). + 1. Set |x| to |x| [=modulo=] 264. + 1. Return the IDL {{unsigned long long}} value that represents the same numeric value as |x|. +
+ +

+ The result of [=converted to an ECMAScript value|converting=] + an IDL {{unsigned long long}} value to an ECMAScript + value is a Number value that + represents the closest numeric value to the {{unsigned long long}}, + choosing the numeric value with an even significand if there are + two [=equally close values=]. + If the {{unsigned long long}} is less than or equal to 253 − 1, + then the Number will be able to + represent exactly the same value as the + {{unsigned long long}}. +

+ + +

float

+ +

+ An ECMAScript value |V| is + [=converted to an IDL value|converted=] + to an IDL {{float}} value + by running the following algorithm: +

+ +
    + 1. Let |x| be [=ToNumber=](|V|). + 1. If |x| is NaN, +Infinity or + −Infinity, then throw a TypeError. + 1. Let |S| be the set of finite IEEE 754 single-precision floating + point values except −0, but with two special values added: 2128 and + −2128. + 1. Let |y| be the number in |S| that is closest + to |x|, selecting the number with an + even significand if there are two [=equally close values=]. + (The two special values 2128 and −2128 + are considered to have even significands for this purpose.) + 1. If |y| is 2128 or −2128, then throw a TypeError. + 1. If |y| is +0 and |x| is negative, return −0. + 1. Return |y|. +
+ +

+ The result of [=converted to an ECMAScript value|converting=] + an IDL {{float}} value to an ECMAScript + value is the Number value that represents the same numeric value as the IDL + {{float}} value. +

+ + +

unrestricted float

+ +

+ An ECMAScript value |V| is + [=converted to an IDL value|converted=] + to an IDL {{unrestricted float}} value + by running the following algorithm: +

+ +
    + 1. Let |x| be [=ToNumber=](|V|). + 1. If |x| is NaN, then return the IDL {{unrestricted float}} value that represents the IEEE 754 NaN value with the bit pattern 0x7fc00000 [[!IEEE-754]]. + 1. Let |S| be the set of finite IEEE 754 single-precision floating + point values except −0, but with two special values added: 2128 and + −2128. + 1. Let |y| be the number in |S| that is closest + to |x|, selecting the number with an + even significand if there are two [=equally close values=]. + (The two special values 2128 and −2128 + are considered to have even significands for this purpose.) + 1. If |y| is 2128, return +∞. + 1. If |y| is −2128, return −∞. + 1. If |y| is +0 and |x| is negative, return −0. + 1. Return |y|. +
+ +Note: Since there is only a single ECMAScript NaN value, +it must be canonicalized to a particular single precision IEEE 754 NaN value. The NaN value +mentioned above is chosen simply because it is the quiet NaN with the lowest +value when its bit pattern is interpreted as an unsigned 32 bit integer. + +

+ The result of [=converted to an ECMAScript value|converting=] + an IDL {{unrestricted float}} value to an ECMAScript + value is a Number: +

+ +* If the IDL {{unrestricted float}} value is a NaN, + then the Number value is NaN. +* Otherwise, the Number value is + the one that represents the same numeric value as the IDL + {{unrestricted float}} value. + + +

double

+ +

+ An ECMAScript value |V| is + [=converted to an IDL value|converted=] + to an IDL {{double}} value + by running the following algorithm: +

+ +
    + 1. Let |x| be [=ToNumber=](|V|). + 1. If |x| is NaN, +Infinity or + −Infinity, then throw a TypeError. + 1. Return the IDL {{double}} value + that has the same numeric value as |x|. +
+ +

+ The result of [=converted to an ECMAScript value|converting=] + an IDL {{double}} value to an ECMAScript + value is the Number value that represents the + same numeric value as the IDL {{double}} value. +

+ + +

unrestricted double

+ +

+ An ECMAScript value |V| is + [=converted to an IDL value|converted=] + to an IDL {{unrestricted double}} value + by running the following algorithm: +

+ +
    + 1. Let |x| be [=ToNumber=](|V|). + 1. If |x| is NaN, then return the IDL {{unrestricted double}} value that represents the IEEE 754 NaN value with the bit pattern 0x7ff8000000000000 [[!IEEE-754]]. + 1. Return the IDL {{unrestricted double}} value + that has the same numeric value as |x|. +
+ +Note: Since there is only a single ECMAScript NaN value, +it must be canonicalized to a particular double precision IEEE 754 NaN value. The NaN value +mentioned above is chosen simply because it is the quiet NaN with the lowest +value when its bit pattern is interpreted as an unsigned 64 bit integer. + +

+ The result of [=converted to an ECMAScript value|converting=] + an IDL {{unrestricted double}} value to an ECMAScript + value is a Number: +

+ +* If the IDL {{unrestricted double}} value is a NaN, + then the Number value is NaN. +* Otherwise, the Number value is + the one that represents the same numeric value as the IDL + {{unrestricted double}} value. + + +

DOMString

+ +

+ An ECMAScript value |V| is + [=converted to an IDL value|converted=] + to an IDL {{DOMString}} value + by running the following algorithm: +

+ +
    + 1. If |V| is null + and the conversion to an IDL value is being performed due + to any of the following: + * |V| is being passed as an [=operation=] + argument that is annotated with [{{TreatNullAs}}], + * |V| is being assigned to an [=attribute=] + annotated with [{{TreatNullAs}}], + * |V| is being returned from a [=user object=] implementation of an + operation annotated with [{{TreatNullAs}}], or + * |V| is being returned from a [=user object=] implementation of an + attribute annotated with [{{TreatNullAs}}], + + then return the {{DOMString}} + value that represents the empty string. + 1. Let |x| be [=ToString=](|V|). + 1. Return the IDL {{DOMString}} value that represents the same sequence of code units as the one the ECMAScript String value |x| represents. +
+ +

+ The result of [=converted to an ECMAScript value|converting=] + an IDL {{DOMString}} value to an ECMAScript + value is the String + value that represents the same sequence of [=code units=] that the + IDL {{DOMString}} represents. +

+ + +

ByteString

+ +

+ An ECMAScript value |V| is + [=converted to an IDL value|converted=] + to an IDL {{ByteString}} value + by running the following algorithm: +

+ +
    + 1. Let |x| be [=ToString=](|V|). + 1. If the value of any [=element=] + of |x| is greater than 255, then throw a TypeError. + 1. Return an IDL {{ByteString}} value + whose length is the length of |x|, and where the value of each element is + the value of the corresponding element of |x|. +
+ +

+ The result of [=converted to an ECMAScript value|converting=] + an IDL {{ByteString}} value to an ECMAScript + value is a String + value whose length is the length of the {{ByteString}}, + and the value of each element of which is the value of the corresponding element + of the {{ByteString}}. +

+ + +

USVString

+ +

+ An ECMAScript value |V| is + [=converted to an IDL value|converted=] + to an IDL {{USVString}} value + by running the following algorithm: +

+ +
    + 1. Let |string| be the result of [=converted to an IDL value|converting=] |V| + to a {{DOMString}}. + 1. Return an IDL {{USVString}} value + that is the result of [=obtain Unicode|converting string to a sequence of Unicode scalar values=]. +
+ +

+ An IDL {{USVString}} value is + [=converted to an ECMAScript value|converted=] + to an ECMAScript value by running the following algorithm: +

+ +
    + 1. Let |scalarValues| be the sequence of [=Unicode scalar values=] the {{USVString}} represents. + 1. Let |string| be the sequence of [=code units=] that results from encoding |scalarValues| in UTF-16. + 1. Return the String value that represents the same sequence of [=code units=] as |string|. +
+ + +

object

+ +IDL {{object}} +values are represented by ECMAScript Object values. + +

+ An ECMAScript value |V| is + [=converted to an IDL value|converted=] + to an IDL {{object}} value + by running the following algorithm: +

+ +
    + 1. If [=Type=](|V|) is not Object, then throw a TypeError. + 1. Return the IDL {{object}} value that is a reference to the same object as |V|. +
+ +

+ The result of [=converted to an ECMAScript value|converting=] + an IDL {{object}} value to an ECMAScript + value is the Object value that represents a reference to the same object that the + IDL {{object}} represents. +

+ + +

Interface types

+ +IDL interface type +values are represented by ECMAScript Object or +Function values. + +

+ An ECMAScript value |V| is + [=converted to an IDL value|converted=] + to an IDL interface type value + by running the following algorithm (where |I| is the [=interface=]): +

+ +
    + 1. If [=Type=](|V|) is not Object, then throw a TypeError. + 1. If |V| is a [=platform object=] that implements |I|, then return the IDL interface type value that represents a reference to that platform object. + 1. If |V| is a [=user object=] + that is considered to implement |I| according to the rules in [[#es-user-objects]], then return the IDL interface type value that represents a reference to that + user object, with the [=incumbent settings object=] as the [=callback context=]. + 1. Throw a TypeError. +
+ +

+ The result of [=converted to an ECMAScript value|converting=] + an IDL interface type + value to an ECMAScript value is the Object + value that represents a reference to the same object that the IDL + interface type value represents. +

+ + +

Dictionary types

+ +IDL dictionary type values are represented +by ECMAScript Object values. Properties on +the object (or its prototype chain) correspond to [=dictionary members=]. + +

+ An ECMAScript value |V| is + [=converted to an IDL value|converted=] + to an IDL dictionary type value + by running the following algorithm (where |D| is the [=dictionary=]): +

+ +
    + 1. If [=Type=](|V|) is not Undefined, Null or Object, then throw a TypeError. + 1. If |V| is a native RegExp object, then throw a TypeError. + 1. Let |dict| be an empty dictionary value of type |D|; + every [=dictionary member=] + is initially considered to be [=present|not present=]. + 1. Let |dictionaries| be a list consisting of |D| and all of |D|’s [=inherited dictionaries=], + in order from least to most derived. + 1. For each dictionary |dictionary| in |dictionaries|, in order: + 1. For each dictionary member |member| declared on |dictionary|, in lexicographical order: + 1. Let |key| be the [=identifier=] of |member|. + 1. Let |value| be an ECMAScript value, depending on [=Type=](|V|): +
    + : Undefined + : Null + :: |value| is undefined. + : anything else + :: |value| is the result of calling the \[[Get]] internal method on |V| with property name |key|. +
    + 1. If |value| is not undefined, then: + 1. Let |idlValue| be the result of [=converted to an IDL value|converting=] |value| to an IDL value whose type is the type |member| is declared to be of. + 1. Set the dictionary member on |dict| with key name |key| to the value |idlValue|. This dictionary member is considered to be [=present=]. + 1. Otherwise, if |value| is undefined but the [=dictionary member=] has a [=dictionary member/default value=], then: + 1. Let |idlValue| be the dictionary member’s default value. + 1. Set the dictionary member on |dict| with key name |key| to the value |idlValue|. This dictionary member is considered to be [=present=]. + 1. Otherwise, if |value| is + undefined and the + [=dictionary member=] is a + [=required dictionary member=], then throw a TypeError. + 1. Return |dict|. +
+ +Note: The order that [=dictionary members=] are looked +up on the ECMAScript object are not necessarily the same as the object’s property enumeration order. + +

+ An IDL dictionary value |V| is + [=converted to an ECMAScript value|converted=] + to an ECMAScript Object value + by running the following algorithm (where |D| is the [=dictionary=]): +

+ +
    + 1. Let |O| be a new Object value created as if by the expression ({}). + 1. Let |dictionaries| be a list consisting of |D| and all of |D|’s [=inherited dictionaries=], + in order from least to most derived. + 1. For each dictionary |dictionary| in |dictionaries|, in order: + 1. For each dictionary member |member| declared on |dictionary|, in lexicographical order: + 1. Let |key| be the [=identifier=] of |member|. + 1. If the dictionary member named |key| is [=present=] in |V|, then: + 1. Let |idlValue| be the value of |member| on |V|. + 1. Let |value| be the result of [=converted to an ECMAScript value|converting=] |idlValue| to an ECMAScript value. + 1. Call [=CreateDataProperty=](|O|, |key|, |value|. + 1. Return |O|. +
+ + +

Enumeration types

+ +IDL enumeration types are represented by ECMAScript String +values. + +

+ An ECMAScript value |V| is + [=converted to an IDL value|converted=] + to an IDL [=enumeration|enumeration type=] + value as follows (where |E| is the [=enumeration=]): +

+ +
    + 1. Let |S| be the result of calling [=ToString=](|V|). + 1. If |S| is not one of |E|’s [=enumeration values=], then throw a TypeError. + 1. Return the enumeration value of type |E| that is equal to |S|. +
+ +

+ The result of [=converted to an ECMAScript value|converting=] + an IDL [=enumeration|enumeration type=] value to an ECMAScript + value is the String + value that represents the same sequence of [=code units=] as + the [=enumeration value=]. +

+ + +

Callback function types

+ +IDL callback function types are represented by ECMAScript Function +objects, except in the [{{TreatNonObjectAsNull}}] case, +when they can be any object. + +

+ An ECMAScript value |V| is + [=converted to an IDL value|converted=] + to an IDL callback function type value + by running the following algorithm: +

+ +
    + 1. If the result of calling [=IsCallable=](|V|) is false and the conversion to an IDL value + is not being performed due + to |V| being assigned to an [=attribute=] + whose type is a [=nullable type|nullable=] + [=callback function=] + that is annotated with [{{TreatNonObjectAsNull}}], + then throw a TypeError. + 1. Return the IDL callback function type value + that represents a reference to the same object that |V| represents, with the + [=incumbent settings object=] as the [=callback context=]. +
+ +

+ The result of [=converted to an ECMAScript value|converting=] + an IDL callback function type + value to an ECMAScript value is a reference to the same object + that the IDL callback function type value represents. +

+ + +

Nullable types — |T|?

+ +IDL [=nullable type=] values are represented +by values of either the ECMAScript type corresponding to the [=inner type|inner IDL type=], or +the ECMAScript null value. + +

+ An ECMAScript value |V| is + [=converted to an IDL value|converted=] + to an IDL [=nullable type=] |T|? + value (where |T| is the [=inner type=]) as follows: +

+ +
    + 1. If [=Type=](|V|) is not Object, and + the conversion to an IDL value is being performed due + to |V| being assigned to an [=attribute=] + whose type is a [=nullable type|nullable=] + [=callback function=] + that is annotated with [{{TreatNonObjectAsNull}}], + then return the IDL + [=nullable type=] |T|? + value null. + 1. Otherwise, if |V| is null or undefined, then return the IDL + [=nullable type=] |T|? + value null. + 1. Otherwise, return the result of + [=converted to an IDL value|converting=] |V| + using the rules for the [=inner type|inner IDL type=] T. +
+ +

+ The result of [=converted to an ECMAScript value|converting=] + an IDL [=nullable type=] value to an ECMAScript value is: +

+ +* If the IDL [=nullable type=] |T|? + value is null, + then the ECMAScript value is null. +* Otherwise, the ECMAScript value is the result of + [=converted to an ECMAScript value|converting=] + the IDL [=nullable type=] value + to the [=inner type|inner IDL type=] T. + + +

Sequences — sequence<|T|>

+ +IDL sequence<|T|> values are represented by +ECMAScript Array values. + +

+ An ECMAScript value |V| is [=converted to an IDL value|converted=] + to an IDL sequence<|T|> value as follows: +

+ +
    + 1. If |V| is not an object, + throw a TypeError. + 1. If |V| is a native RegExp object, + throw a TypeError. + 1. Let |method| be the result of + [=GetMethod=](|V|, [=@@iterator=]). + 1. [=ReturnIfAbrupt=](|method|). + 1. If |method| is undefined, + throw a TypeError. + 1. Return the result of + . +
+ +

+ An IDL sequence value |S| of type + sequence<|T|> is + [=converted to an ECMAScript value|converted=] + to an ECMAScript Array object as follows: +

+ +
    + 1. Let |n| be the length of |S|. + 1. Let |A| be a new Array object created as if by the expression []. + 1. Initialize |i| to be 0. + 1. While |i| < |n|: + 1. Let |V| be the value in |S| at index |i|. + 1. Let |E| be the result of [=converted to an ECMAScript value|converting=] + |V| to an ECMAScript value. + 1. Let |P| be the result of calling [=ToString=](|i|). + 1. Call [=CreateDataProperty=](|A|, |P|, |E|). + 1. Set |i| to |i| + 1. + 1. Return |A|. +
+ + +
Creating a sequence from an iterable
+ +To create an IDL value of type sequence<|T|> given an +iterable |iterable| and an iterator getter +|method|, perform the following steps: + +
    + 1. Let |iter| be + [=GetIterator=](|iterable|, |method|). + 1. [=ReturnIfAbrupt=](|iter|). + 1. Initialize |i| to be 0. + 1. Repeat + 1. Let |next| be [=IteratorStep=](|iter|). + 1. [=ReturnIfAbrupt=](|next|). + 1. If |next| is false, + then return an IDL sequence value of type + sequence<|T|> + of length |i|, where the value of the element + at index |j| is + |S||j|. + 1. Let |nextItem| be + [=IteratorValue=](|next|). + 1. [=ReturnIfAbrupt=](|nextItem|). + 1. Initialize |S||i| to the result of + [=converted to an IDL value|converting=] + |nextItem| to an IDL value of type |T|. + 1. Set |i| to |i| + 1. +
+ +
+ + The following [=interface=] defines + an [=attribute=] of a sequence + type as well as an [=operation=] + with an argument of a sequence type. + +
+        interface Canvas {
+        
+          sequence<DOMString> getSupportedImageCodecs();
+        
+          void drawPolygon(sequence<double> coordinates);
+          sequence<double> getLastDrawnPolygon();
+        
+          // ...
+        };
+    
+ + In an ECMAScript implementation of this interface, an Array + object with elements of type String is used to + represent a sequence<DOMString>, while an + Array with elements of type Number + represents a sequence<double>. The + Array objects are effectively passed by + value; every time the getSupportedImageCodecs() + function is called a new Array is + returned, and whenever an Array is + passed to drawPolygon no reference + will be kept after the call completes. + +
+        // Obtain an instance of Canvas.  Assume that getSupportedImageCodecs()
+        // returns a sequence with two DOMString values: "image/png" and "image/svg+xml".
+        var canvas = getCanvas();
+        
+        // An Array object of length 2.
+        var supportedImageCodecs = canvas.getSupportedImageCodecs();
+        
+        // Evaluates to "image/png".
+        supportedImageCodecs[0];
+        
+        // Each time canvas.getSupportedImageCodecs() is called, it returns a
+        // new Array object.  Thus modifying the returned Array will not
+        // affect the value returned from a subsequent call to the function.
+        supportedImageCodecs[0] = "image/jpeg";
+        
+        // Evaluates to "image/png".
+        canvas.getSupportedImageCodecs()[0];
+        
+        // This evaluates to false, since a new Array object is returned each call.
+        canvas.getSupportedImageCodecs() == canvas.getSupportedImageCodecs();
+        
+        // An Array of Numbers...
+        var a = [0, 0, 100, 0, 50, 62.5];
+        
+        // ...can be passed to a platform object expecting a sequence<double>.
+        canvas.drawPolygon(a);
+        
+        // Each element will be converted to a double by first calling ToNumber().
+        // So the following call is equivalent to the previous one, except that
+        // "hi" will be alerted before drawPolygon() returns.
+        a = [false, '',
+             { valueOf: function() { alert('hi'); return 100; } }, 0,
+             '50', new Number(62.5)];
+        canvas.drawPolygon(s);
+        
+        // Modifying an Array that was passed to drawPolygon() is guaranteed not to
+        // have an effect on the Canvas, since the Array is effectively passed by value.
+        a[4] = 20;
+        var b = canvas.getLastDrawnPolygon();
+        alert(b[4]);    // This would alert "50".
+    
+
+ + +

Promise types — Promise<|T|>

+ +IDL promise type values are +represented by ECMAScript Promise +objects. + +

+ An ECMAScript value |V| is + [=converted to an IDL value|converted=] + to an IDL Promise<|T|> value as follows: +

+ +
    + 1. Let |resolve| be the original value of [=%Promise%=].resolve. +

    + ECMAScript should grow a %Promise_resolve% well-known intrinsic object that can be referenced here. +

    + 1. Let |promise| be the result of calling |resolve| with [=%Promise%=] + as the this value and |V| as the single argument value. + 1. Return the IDL promise type value that is a reference to the + same object as |promise|. +
+ +

+ The result of [=converted to an ECMAScript value|converting=] + an IDL promise type value to an ECMAScript + value is the Promise value that represents a reference to the same object that the + IDL promise type represents. +

+ +One can perform some steps once a promise is settled. +There can be one or two sets of steps to perform, covering when the promise is fulfilled, rejected, or both. +When a specification says to perform some steps once a promise is settled, the following steps +must be followed: + +
    + 1. Let |promise| be the promise object of type Promise<|T|>. + 1. Let |onFulfilled| be a new [=function object=] whose + behavior when invoked is as follows: + 1. If |T| is {{void}}, then: + 1. Return the result of performing any steps that were required to be run if the promise was fulfilled. + 1. Otherwise, |T| is a type other than {{void}}: + 1. Let |V| be the first argument to |onFulfilled|. + 1. Let |value| be the result of [=converted to an IDL value|converting=] + |V| to an IDL value of type |T|. + 1. If there are no steps that are required to be run if the promise was fulfilled, then + return undefined. + 1. Otherwise, return the result of performing any steps that were required to be run if the promise was fulfilled, + with |value| as the promise’s value. + 1. Let |onRejected| be a new [=function object=] whose + behavior when invoked is as follows: + 1. Let |R| be the first argument to |onRejected|. + 1. Let |reason| be the result of [=converted to an IDL value|converting=] + |R| to an IDL value of type {{any}}. + 1. If there are no steps that are required to be run if the promise was rejected, then + return undefined. + 1. Otherwise, return the result of performing any steps that were required to be run if the promise was rejected, + with |reason| as the rejection reason. + 1. Let |then| be the result of calling the internal \[[Get]] method of |promise| with property name “then”. + 1. If |then| is not [=callable=], then throw a TypeError. + 1. Return the result of calling |then| with |promise| as the this value and |onFulfilled| and |onRejected| + as its two arguments. +
+ +

+ Include an example of how to write spec text using this term. +

+ + +

Union types

+ +IDL union type values are +represented by ECMAScript values that correspond to the union’s +[=member types=]. + +

+ To [=converted to an IDL value|convert an ECMAScript value=] |V| to an IDL union type + value is done as follows: +

+ +
    + 1. If the [=union type=] + [=includes a nullable type=] and + |V| is null or undefined, + then return the IDL value null. + 1. Let |types| be the [=flattened member types=] + of the [=union type=]. + 1. If |V| is null or + undefined, and + |types| includes a + dictionary type, then return the + result of + [=converted to an IDL value|converting=] + |V| to that dictionary type. + 1. If |V| is a [=platform object=], then: + 1. If |types| includes an interface type that |V| + implements, then return the IDL value that is a reference to the object |V|. + 1. If |types| includes {{object}}, then return the IDL value + that is a reference to the object |V|. + 1. If |V| is a native RegExp object, then: + 1. If |types| includes {{RegExp}}, then return the + result of [=converted to an IDL value|converting=] + |V| to {{RegExp}}. + 1. If |types| includes {{object}}, then return the IDL value + that is a reference to the object |V|. + 1. If |V| is a {{DOMException}} platform object, then: + 1. If |types| includes {{DOMException}} or + {{Error!!interface}}, then return the + result of [=converted to an IDL value|converting=] + |V| to that type. + 1. If |types| includes {{object}}, then return the IDL value + that is a reference to the object |V|. + 1. If |V| is a native Error object (that is, it has an \[[ErrorData]] [=internal slot=]), then: + 1. If |types| includes {{Error!!interface}}, then return the + result of [=converted to an IDL value|converting=] + |V| to {{Error!!interface}}. + 1. If |types| includes {{object}}, then return the IDL value + that is a reference to the object |V|. + 1. If |V| is an object with an \[[ArrayBufferData]] [=internal slot=], then: + 1. If |types| includes {{ArrayBuffer}}, then return the + result of [=converted to an IDL value|converting=] + |V| to {{ArrayBuffer}}. + 1. If |types| includes {{object}}, then return the IDL value + that is a reference to the object |V|. + 1. If |V| is an object with a \[[DataView]] [=internal slot=], then: + 1. If |types| includes {{DataView}}, then return the + result of [=converted to an IDL value|converting=] + |V| to {{DataView}}. + 1. If |types| includes {{object}}, then return the IDL value + that is a reference to the object |V|. + 1. If |V| is an object with a \[[TypedArrayName]] [=internal slot=], then: + 1. If |types| includes a [=typed array type=] + whose name is the value of |V|’s \[[TypedArrayName]] [=internal slot=], then return the + result of [=converted to an IDL value|converting=] + |V| to that type. + 1. If |types| includes {{object}}, then return the IDL value + that is a reference to the object |V|. + 1. If [=IsCallable=](|V|) is true, then: + 1. If |types| includes a [=callback function=] + type, then return the result of + [=converted to an IDL value|converting=] + |V| to that callback function type. + 1. If |types| includes {{object}}, then return the IDL value + that is a reference to the object |V|. + 1. If |V| is any kind of object except for + a native RegExp object, then: + 1. If |types| includes a sequence type, then + 1. Let |method| be the result of + [=GetMethod=](|V|, [=@@iterator=]). + 1. [=ReturnIfAbrupt=](|method|). + 1. If |method| is not + undefined, + return the result of + . + 1. If |types| includes a frozen array type, then + 1. Let |method| be the result of + [=GetMethod=](|V|, [=@@iterator=]). + 1. [=ReturnIfAbrupt=](|method|). + 1. If |method| is not + undefined, + return the result of + [=Creating a frozen array from an iterable|creating a frozen array of that type from V and method=]. + 1. If |types| includes a dictionary type, then return the + result of [=converted to an IDL value|converting=] + |V| to that dictionary type. + 1. If |types| includes a [=callback interface=] + type, then return the result of + [=converted to an IDL value|converting=] + |V| to that interface type. + 1. If |types| includes {{object}}, then return the IDL value + that is a reference to the object |V|. + 1. If |V| is a Boolean value, then: + 1. If |types| includes a {{boolean}}, + then return the result of [=converted to an IDL value|converting=] + |V| to {{boolean}}. + 1. If |V| is a Number value, then: + 1. If |types| includes a [=numeric type=], + then return the result of [=converted to an IDL value|converting=] + |V| to that [=numeric type=]. + 1. If |types| includes a [=string type=], + then return the result of + [=converted to an IDL value|converting=] + |V| to that type. + 1. If |types| includes a [=numeric type=], + then return the result of [=converted to an IDL value|converting=] + |V| to that [=numeric type=]. + 1. If |types| includes a {{boolean}}, + then return the result of [=converted to an IDL value|converting=] + |V| to {{boolean}}. + 1. Throw a TypeError. +
+ +

+ An IDL union type value is + [=converted to an ECMAScript value=] + as follows. If the value is an {{object}} + reference to a special object that represents an ECMAScript undefined + value, then it is converted to the ECMAScript + undefined value. Otherwise, + the rules for converting the [=specific type=] + of the IDL union type value as described in this section ([[#es-type-mapping]]). +

+ + +

RegExp

+ +IDL {{RegExp}} values are represented by +ECMAScript RegExp objects. + +

+ An ECMAScript value |V| is + [=converted to an IDL value|converted=] + to an IDL {{RegExp}} value + by running the following algorithm: +

+ +
    + 1. If [=Type=](|V|) is not Object, + or |V| is not a native RegExp object, + then set |V| to be a newly created RegExp object created as if by the + expression new RegExp(|V|), where RegExp is the standard built-in constructor with that name + from the [=current global environment=]. + + Note: Note that this can result in an exception being thrown, if |V|, when converted to a string, + does not have valid regular expression syntax. + + 1. Return the IDL {{RegExp}} value that is a reference to the same object as |V|. +
+ +

+ The result of [=converted to an ECMAScript value|converting=] + an IDL {{RegExp}} value to an ECMAScript + value is the RegExp value that represents a reference to the same object that the + IDL {{RegExp}} represents. +

+ + +

Error

+ +IDL {{Error!!interface}} values are represented +by native ECMAScript Error objects and +platform objects for {{DOMException|DOMExceptions}}. + +

+ An ECMAScript value |V| is + [=converted to an IDL value|converted=] + to an IDL {{Error!!interface}} value + by running the following algorithm: +

+ +
    + 1. If [=Type=](|V|) is not Object, + or |V| does not have an \[[ErrorData]] [=internal slot=], then throw a TypeError. + 1. Return the IDL {{Error!!interface}} value that is a reference to the same object as |V|. +
+ +

+ The result of [=converted to an ECMAScript value|converting=] + an IDL {{Error!!interface}} value to an ECMAScript + value is the Error value that represents a reference to the same object that the + IDL {{Error!!interface}} represents. +

+ + +

DOMException

+ +IDL {{DOMException}} values are represented +by platform objects for {{DOMException|DOMExceptions}}. + +

+ An ECMAScript value |V| is + [=converted to an IDL value|converted=] + to an IDL {{DOMException}} value + by running the following algorithm: +

+ +
    + 1. If [=Type=](|V|) is not Object, + or |V| is not a platform object that represents a {{DOMException}}, then throw a TypeError. + 1. Return the IDL {{DOMException}} value that is a reference to the same object as |V|. +
+ +

+ The result of [=converted to an ECMAScript value|converting=] + an IDL {{DOMException}} value to an ECMAScript + value is the Object value that represents a reference to the same object that the + IDL {{DOMException}} represents. +

+ + +

Buffer source types

+ +Values of the IDL [=buffer source types=] +are represented by objects of the corresponding ECMAScript class. + +

+ An ECMAScript value |V| is + [=converted to an IDL value|converted=] + to an IDL {{ArrayBuffer}} value + by running the following algorithm: +

+ +
    + 1. If [=Type=](|V|) is not Object, + or |V| does not have an \[[ArrayBufferData]] [=internal slot=], + or [=IsDetachedBuffer=](|V|) is true, + then throw a TypeError. + 1. Return the IDL {{ArrayBuffer}} value that is a reference to the same object as |V|. +
+ +

+ An ECMAScript value |V| is + [=converted to an IDL value|converted=] + to an IDL {{DataView}} value + by running the following algorithm: +

+ +
    + 1. If [=Type=](|V|) is not Object, + or |V| does not have a \[[DataView]] [=internal slot=], + then throw a TypeError. + 1. Return the IDL {{DataView}} value that is a reference to the same object as |V|. +
+ +An ECMAScript value |V| is +[=converted to an IDL value|converted=] +to an IDL {{Int8Array}}, +{{Int16Array}}, +{{Int32Array}}, +{{Uint8Array}}, +{{Uint16Array}}, +{{Uint32Array}}, +{{Uint8ClampedArray}}, +{{Float32Array}} or +{{Float64Array}} value +by running the following algorithm: + +
    + 1. Let |T| be the IDL type |V| is being converted to. + 1. If [=Type=](|V|) is not Object, + or |V| does not have a \[[TypedArrayName]] [=internal slot=] + with a value equal to the name of |T|, + then throw a TypeError. + 1. Return the IDL value of type |T| that is a reference to the same object as |V|. +
+ +The result of [=converted to an ECMAScript value|converting=] +an IDL value of any [=buffer source type=] +to an ECMAScript value is the Object value that represents +a reference to the same object that the IDL value represents. + +When [=get a reference to the buffer source|getting a reference to=] +or [=get a copy of the buffer source|getting a copy of the bytes held by a buffer source=] +that is an ECMAScript ArrayBuffer, DataView +or typed array object, these steps must be followed: + +
    + 1. Let |O| be the ECMAScript object that is the buffer source. + 1. Initialize |arrayBuffer| to |O|. + 1. Initialize |offset| to 0. + 1. Initialize |length| to 0. + 1. If |O| has a \[[ViewedArrayBuffer]] [=internal slot=], then: + 1. Set |arrayBuffer| to the value of |O|’s \[[ViewedArrayBuffer]] [=internal slot=]. + 1. If |arrayBuffer| is undefined, then + throw a TypeError. + 1. Set |offset| to the value of |O|’s \[[ByteOffset]] [=internal slot=]. + 1. Set |length| to the value of |O|’s \[[ByteLength]] [=internal slot=]. + 1. Otherwise, set |length| to the value of |O|’s \[[ArrayBufferByteLength]] [=internal slot=]. + 1. If [=IsDetachedBuffer=](|O|), then + throw a TypeError. + 1. Let |data| be the value of |O|’s \[[ArrayBufferData]] [=internal slot=]. + 1. Return a reference to or copy of (as required) the |length| bytes in |data| + starting at byte offset |offset|. +
+ +To [=detach=] an {{ArrayBuffer}}, +these steps must be followed: + +
    + 1. Let |O| be the ECMAScript object that is the {{ArrayBuffer}}. + 1. [=DetachArrayBuffer=](|O|). +
+ + +

Frozen arrays — FrozenArray<|T|>

+ +Values of frozen array types are represented by frozen ECMAScript +Array object references. + +An ECMAScript value |V| is +[=converted to an IDL value|converted=] +to an IDL FrozenArray<|T|> value +by running the following algorithm: + +
    + 1. Let |values| be the result of + [=converted to an IDL value|converting=] + |V| to IDL type sequence<|T|>. + 1. Return the result of + [=create a frozen array|creating a frozen array=] + from |values|. +
+ +To create a frozen array from a sequence +of values of type |T|, follow these steps: + +
    + 1. Let |array| be the result of + [=converted to an ECMAScript value|converting=] + the sequence of values to an ECMAScript value. + 1. Perform [=SetIntegrityLevel=](|array|, "frozen"). + 1. Return |array|. +
+ +The result of [=converted to an ECMAScript value|converting=] +an IDL FrozenArray<|T|> value to an ECMAScript +value is the Object value that represents a reference +to the same object that the IDL FrozenArray<|T|> represents. + + +
Creating a frozen array from an iterable
+ +To create an IDL value of type FrozenArray<|T|> given an +iterable |iterable| and an iterator getter +|method|, perform the following steps: + +
    + 1. Let |values| be the result of + . + 1. Return the result of [=create a frozen array|creating a frozen array=] from |values|. +
+ + +

ECMAScript-specific extended attributes

+ +This section defines a number of +[=extended attributes=] +whose presence affects only the ECMAScript binding. + + +

[Clamp]

+ +If the [{{Clamp}}] +[=extended attribute=] +appears on an [=operation=] argument, +writable [=attribute=] or +[=dictionary member=] +whose type is one of the [=integer types=], +it indicates that when an ECMAScript Number is +converted to the IDL type, out of range values will be clamped to the range +of valid values, rather than using the operators that use a modulo operation +([=ToInt32=], [=ToUint32=], etc.). + +The [{{Clamp}}] +extended attribute must +[=takes no arguments|take no arguments=]. + +The [{{Clamp}}] extended attribute +must not appear on a [=read only=] +attribute, or an attribute, operation argument or dictionary member +that is not of an integer type. It also must not +be used in conjunction with the [{{EnforceRange}}] +extended attribute. + +See the rules for converting ECMAScript values to the various IDL integer +types in [[#es-type-mapping]] +for the specific requirements that the use of +[{{Clamp}}] entails. + +
+ + In the following [=IDL fragment=], + two [=operations=] are declared that + take three {{octet}} arguments; one uses + the [{{Clamp}}] [=extended attribute=] + on all three arguments, while the other does not: + +
+        interface GraphicsContext {
+          void setColor(octet red, octet green, octet blue);
+          void setColorClamped([Clamp] octet red, [Clamp] octet green, [Clamp] octet blue);
+        };
+    
+ + In an ECMAScript implementation of the IDL, a call to setColorClamped with + Number values that are out of range for an + {{octet}} are clamped to the range [0, 255]. + +
+        // Get an instance of GraphicsContext.
+        var context = getGraphicsContext();
+        
+        // Calling the non-[Clamp] version uses ToUint8 to coerce the Numbers to octets.
+        // This is equivalent to calling setColor(255, 255, 1).
+        context.setColor(-1, 255, 257);
+        
+        // Call setColorClamped with some out of range values.
+        // This is equivalent to calling setColorClamped(0, 255, 255).
+        context.setColorClamped(-1, 255, 257);
+    
+
+ + +

[Constructor]

+ +If the [{{Constructor}}] +[=extended attribute=] +appears on an [=interface=], it indicates that +the [=interface object=] for this interface +will have an \[[Construct]] internal method, +allowing objects implementing the interface to be constructed. + +Multiple [{{Constructor}}] extended +attributes may appear on a given interface. + +The [{{Constructor}}] +extended attribute must either +[=takes no arguments|take no arguments=] or +[=takes an argument list|take an argument list=]. +The bare form, [Constructor], has the same meaning as +using an empty argument list, [Constructor()]. For each +[{{Constructor}}] extended attribute +on the interface, there will be a way to construct an object that implements +the interface by passing the specified arguments. + +The prose definition of a constructor must +either return an IDL value of a type corresponding to the interface +the [{{Constructor}}] +extended attribute appears on, or throw an exception. + +The [{{Constructor}}] and +[{{NoInterfaceObject}}] +extended attributes must not be specified on the same interface. + +The [{{Constructor}}] extended attribute +must not be used on a [=callback interface=]. + +See [[#es-interface-call]] for details on how a constructor +for an interface is to be implemented. + +
+ + The following IDL defines two interfaces. The second has the + [{{Constructor}}] extended + attribute, while the first does not. + +
+        interface NodeList {
+          Node item(unsigned long index);
+          readonly attribute unsigned long length;
+        };
+        
+        [Constructor,
+         Constructor(double radius)]
+        interface Circle {
+          attribute double r;
+          attribute double cx;
+          attribute double cy;
+          readonly attribute double circumference;
+        };
+    
+ + An ECMAScript implementation supporting these interfaces would + have a \[[Construct]] property on the + Circle interface object which would + return a new object that implements the interface. It would take + either zero or one argument. The + NodeList interface object would not + have a \[[Construct]] property. + +
+        var x = new Circle();      // The uses the zero-argument constructor to create a
+                                   // reference to a platform object that implements the
+                                   // Circle interface.
+        
+        var y = new Circle(1.25);  // This also creates a Circle object, this time using
+                                   // the one-argument constructor.
+        
+        var z = new NodeList();    // This would throw a TypeError, since no
+                                   // [Constructor] is declared.
+    
+
+ + +

[EnforceRange]

+ +If the [{{EnforceRange}}] +[=extended attribute=] +appears on an [=operation=] argument, +writable [=regular attribute=] or +[=dictionary member=] +whose type is one of the [=integer types=], +it indicates that when an ECMAScript Number is +converted to the IDL type, out of range values will cause an exception to +be thrown, rather than converted to being a valid value using the operators that use a modulo operation +([=ToInt32=], [=ToUint32=], etc.). The Number +will be rounded towards zero before being checked against its range. + +The [{{EnforceRange}}] +extended attribute must +[=takes no arguments|take no arguments=]. + +The [{{EnforceRange}}] extended attribute +must not appear on a [=read only=] +attribute, a [=static attribute=], +or an attribute, operation argument or dictionary member +that is not of an integer type. It also must not +be used in conjunction with the [{{Clamp}}] +extended attribute. + +See the rules for converting ECMAScript values to the various IDL integer +types in [[#es-type-mapping]] +for the specific requirements that the use of +[{{EnforceRange}}] entails. + +
+ + In the following [=IDL fragment=], + two [=operations=] are declared that + take three {{octet}} arguments; one uses + the [{{EnforceRange}}] [=extended attribute=] + on all three arguments, while the other does not: + +
+        interface GraphicsContext {
+          void setColor(octet red, octet green, octet blue);
+          void setColorEnforcedRange([EnforceRange] octet red, [EnforceRange] octet green, [EnforceRange] octet blue);
+        };
+    
+ + In an ECMAScript implementation of the IDL, a call to setColorEnforcedRange with + Number values that are out of range for an + {{octet}} will result in an exception being + thrown. + +
+        // Get an instance of GraphicsContext.
+        var context = getGraphicsContext();
+        
+        // Calling the non-[EnforceRange] version uses ToUint8 to coerce the Numbers to octets.
+        // This is equivalent to calling setColor(255, 255, 1).
+        context.setColor(-1, 255, 257);
+        
+        // When setColorEnforcedRange is called, Numbers are rounded towards zero.
+        // This is equivalent to calling setColor(0, 255, 255).
+        context.setColorEnforcedRange(-0.9, 255, 255.2);
+        
+        // The following will cause a TypeError to be thrown, since even after
+        // rounding the first and third argument values are out of range.
+        context.setColorEnforcedRange(-1, 255, 256);
+    
+
+ + +

[Exposed]

+ +If the [{{Exposed}}] +[=extended attribute=] +appears on an [=interface=], +[=partial interface=], +[=namespace=], +[=partial namespace=], or +an individual [=interface member=] or +[=namespace member=], +it indicates that the construct is exposed +on a particular set of global interfaces, rather than the default of +being exposed only on the [=primary global interface=]. + +The [{{Exposed}}] +[=extended attribute=] +must either +[=takes an identifier|take an identifier=] or +[=takes an identifier list|take an identifier list=]. +Each of the identifiers mentioned must be +a [=global name=]. + +Every construct that the [{{Exposed}}] +[=extended attribute=] +can be specified on has an exposure set, +which is a set of [=interfaces=] +defining which global environments the construct can be used in. +The [=exposure set=] +for a given construct is defined as follows: + +* If the [{{Exposed}}] + [=extended attribute=] + is specified on the construct, then the [=exposure set=] + is the set of all interfaces that have a [=global name=] + that is listed in the extended attribute's argument. +* If the [{{Exposed}}] + [=extended attribute=] + does not appear on a construct, then its + [=exposure set=] is defined + implicitly, depending on the type of construct: + +
+ : interface + : namespace + :: The [=exposure set=] of the + interface or namespace only contains the + [=primary global interface=]. + : partial interface + : partial namespace + :: The [=exposure set=] of the partial + interface or namespace is the [=exposure set=] of the original interface or namespace definition. + : interface member + :: The [=exposure set=] of the interface member + is the [=exposure set=] of the interface or + partial interface the member is declared on. + : namespace member + :: The [=exposure set=] of the + namespace member is the [=exposure set=] of the namespace or partial namespace the member is declared on. +
+ +If [{{Exposed}}] appears on an +[=overloaded=] [=operation=], +then it must appear identically on all overloads. + +The [{{Exposed}}] extended attribute +must not be specified on both an interface +member and a partial interface definition the interface member is declared on. +Similarly, the [{{Exposed}}] extended attribute +must not be specified on both a namespace +member and a partial namespace definition the namespace member is declared on. + +If [{{Exposed}}] appears an interface member, then +the interface member's [=exposure set=] +must be a subset of the [=exposure set=] of the interface or partial interface it's a +member of. Similarly, if [{{Exposed}}] appears on a +namespace member, then the namespace member's [=exposure set=] must be a +subset of the [=exposure set=] of the +namespace or partial namespace it's a member of. + +An interface's [=exposure set=] +must be a subset of the +[=exposure set=] of all +of the interface's [=consequential interfaces=]. + +If an interface |X| +[=interface/inherits=] from another interface +|Y| then the +[=exposure set=] of +|X| must be a subset of the +[=exposure set=] of +|Y|. + +An [=interface=], [=namespace=], [=interface member=], or [=namespace member=] is +exposed in a given ECMAScript global environment if the +ECMAScript global object implements an interface that is in the construct's [=exposure set=], and either: + +* the [=relevant settings object=] for the ECMAScript global object is a [=secure context=]; or +* the construct is not [=available only in secure contexts=]. + +Note: Since it is not possible for the [=relevant settings object=] +for an ECMAScript global object to change whether it is a +[=secure context=] or not over time, an implementation's +decision to create properties for an interface or interface member +can be made once, at the time the +[=initial objects=] +are created. + +See +[[#es-interfaces]], +[[#es-constants]], +[[#es-attributes]], +[[#es-operations]] and +[[#es-iterators]] +for the specific requirements that the use of +[{{Exposed}}] entails. + +
+ + [{{Exposed}}] + is intended to be used to control whether interfaces, namespaces, or individual + interface or namespace members are available for use only in workers, only in the + Window, or in both. + + The following IDL fragment shows how that might be achieved: + +
+        [PrimaryGlobal]
+        interface Window {
+          // ...
+        };
+        
+        // By using the same identifier Worker for both SharedWorkerGlobalScope
+        // and DedicatedWorkerGlobalScope, both can be addressed in an [Exposed]
+        // extended attribute at once.
+        [Global=Worker]
+        interface SharedWorkerGlobalScope : WorkerGlobalScope {
+          // ...
+        };
+        
+        [Global=Worker]
+        interface DedicatedWorkerGlobalScope : WorkerGlobalScope {
+          // ...
+        };
+        
+        // Dimensions is available for use in workers and on the main thread.
+        [Exposed=(Window,Worker), Constructor(double width, double height)]
+        interface Dimensions {
+          readonly attribute double width;
+          readonly attribute double height;
+        };
+        
+        // WorkerNavigator is only available in workers.  Evaluating WorkerNavigator
+        // in the global scope of a worker would give you its interface object, while
+        // doing so on the main thread will give you a ReferenceError.
+        [Exposed=Worker]
+        interface WorkerNavigator {
+          // ...
+        };
+        
+        // Node is only available on the main thread.  Evaluating Node
+        // in the global scope of a worker would give you a ReferenceError.
+        interface Node {
+          // ...
+        };
+        
+        // MathUtils is available for use in workers and on the main thread.
+        [Exposed=(Window,Worker)]
+        namespace MathUtils {
+          double someComplicatedFunction(double x, double y);
+        };
+        
+        // WorkerUtils is only available in workers.  Evaluating WorkerUtils
+        // in the global scope of a worker would give you its namespace object, while
+        // doing so on the main thread will give you a ReferenceError.
+        [Exposed=Worker]
+        namespace WorkerUtils {
+          void setPriority(double x);
+        };
+        
+        // NodeUtils is only available in the main thread.  Evaluating NodeUtils
+        // in the global scope of a worker would give you a ReferenceError.
+        namespace NodeUtils {
+          DOMString getAllText(Node node);
+        };
+    
+
+ + +

[ImplicitThis]

+ +If the [{{ImplicitThis}}] +[=extended attribute=] +appears on an [=interface=], +it indicates that when a Function corresponding +to one of the interface’s [=operations=] +is invoked with the null or undefined +value as the this value, that the ECMAScript global +object will be used as the this value instead. +This is regardless of whether the calling code is in strict mode. + +The [{{ImplicitThis}}] +extended attribute must +[=takes no arguments|take no arguments=]. + +See [[#es-operations]] +for the specific requirements that the use of +[{{ImplicitThis}}] entails. + +Note: The [{{ImplicitThis}}] [=extended attribute=] +is intended for use on the {{Window}} [=interface=]. + +
+ + In the following example, the Window + [=interface=] is defined + with the [{{ImplicitThis}}] + [=extended attribute=]. + +
+        [ImplicitThis]
+        interface Window {
+          // ...
+          attribute DOMString name;
+          void alert(DOMString message);
+        };
+    
+ + Since the Window object is used as + the ECMAScript global object, calls to its functions can be made + without an explicit object, even in strict mode: + +
+        "use strict";
+        
+        window.alert("hello");      // Calling alert with an explicit window object works.
+        alert("hello");             // This also works, even though we are in strict mode.
+        alert.call(null, "hello");  // As does passing null explicitly as the this value.
+        
+        // This does not apply to getters for attributes on the interface, though.
+        // The following will throw a TypeError.
+        Object.getOwnPropertyDescriptor(Window.prototype, "name").get.call(null);
+    
+
+ + +

[Global] and [PrimaryGlobal]

+ +If the [{{Global}}] +or [{{PrimaryGlobal}}] +[=extended attribute=] +appears on an [=interface=], +it indicates that objects implementing this interface can +be used as the global object in an ECMAScript environment, +and that the structure of the prototype chain and how +properties corresponding to [=interface members=] +will be reflected on the prototype objects will be different from other +interfaces. Specifically: + +1. Any named properties + will be exposed on an object in the prototype chain – the + [=named properties object=] – + rather than on the object itself. +1. [=Interface members=] from the + [=interface=] (or + [=consequential interfaces=]) + will correspond to properties on the object itself rather than on + [=interface prototype objects=]. + +
+ + Placing named properties on an object in the prototype chain + is done so that variable declarations and bareword assignments + will shadow the named property with a property on the global + object itself. + + Placing properties corresponding to interface members on + the object itself will mean that common feature detection + methods like the following will work: + +
+        var indexedDB = window.indexedDB || window.webkitIndexedDB ||
+                        window.mozIndexedDB || window.msIndexedDB;
+        
+        var requestAnimationFrame = window.requestAnimationFrame ||
+                                    window.mozRequestAnimationFrame || ...;
+    
+ + Because of the way variable declarations are handled in + ECMAScript, the code above would result in the window.indexedDB + and window.requestAnimationFrame evaluating + to undefined, as the shadowing variable + property would already have been created before the + assignment is evaluated. + +
+ +If the [{{Global}}] or +[{{PrimaryGlobal}}] +[=extended attributes=] +is used on an [=interface=], then: + +* The interface must not define a [=named property setter=]. +* The interface must not also be declared with the [{{OverrideBuiltins}}] + extended attribute. +* The interface must not [=interface/inherit=] from another interface with the + [{{OverrideBuiltins}}] extended attribute. +* Any other interface must not [=interface/inherit=] from it. + +If [{{Global}}] or [{{PrimaryGlobal}}] is specified on +a [=partial interface=] +definition, then that partial interface definition must +be the part of the interface definition that defines +the [=named property getter=]. + +The [{{Global}}] and [{{PrimaryGlobal}}] +[=extended attribute=] must not +be used on an [=interface=] that can have more +than one object implementing it in the same ECMAScript global environment. + +Note: This is because the [=named properties object=], +which exposes the named properties, is in the prototype chain, and it would not make +sense for more than one object’s named properties to be exposed on an object that +all of those objects inherit from. + +If an interface is declared with the [{{Global}}] or +[{{PrimaryGlobal}}] +[=extended attribute=], then +there must not be more than one +[=interface member=] across +the interface and its [=consequential interfaces=] +with the same [=identifier=]. +There also must not be more than +one [=stringifier=], +more than one [=serializer=], +or more than one [=iterable declaration=], +[=maplike declaration=] or +[=setlike declaration=] +across those interfaces. + +Note: This is because all of the members of the interface and its consequential +interfaces get flattened down on to the object that implements the interface. + +The [{{Global}}] and +[{{PrimaryGlobal}}] extended attributes +can also be used to give a name to one or more global interfaces, +which can then be referenced by the [{{Exposed}}] +extended attribute. + +The [{{Global}}] and +[{{PrimaryGlobal}}] +extended attributes must either +[=takes no arguments|take no arguments=] +or [=takes an identifier list|take an identifier list=]. + +If the [{{Global}}] or +[{{PrimaryGlobal}}] +[=extended attribute=] +is declared with an identifier list argument, then those identifiers are the interface’s +global names; otherwise, the interface has +a single global name, which is the interface's identifier. + +Note: The identifier argument list exists so that more than one global interface can +be addressed with a single name in an [{{Exposed}}] +[=extended attribute=]. + +The [{{Global}}] and +[{{PrimaryGlobal}}] +[=extended attributes=] +must not be declared on the same +interface. The [{{PrimaryGlobal}}] +extended attribute must be declared on +at most one interface. The interface [{{PrimaryGlobal}}] +is declared on, if any, is known as the primary global interface. + +See [[#named-properties-object]], +[[#getownproperty]] and +[[#defineownproperty]] +for the specific requirements that the use of +[{{Global}}] and [{{PrimaryGlobal}}] +entails for named properties, +and [[#es-constants]], +[[#es-attributes]] and +[[#es-operations]] +for the requirements relating to the location of properties +corresponding to [=interface members=]. + +
+ + The [{{PrimaryGlobal}}] [=extended attribute=] is intended + to be used by the {{Window}} interface. + ([{{Global}}] is intended to be used by worker global interfaces.) + The Window interface exposes frames as properties on the Window + object. Since the Window object also serves as the + ECMAScript global object, variable declarations or assignments to the named properties + will result in them being replaced by the new value. Variable declarations for + attributes will not create a property that replaces the existing one. + +
+        [PrimaryGlobal]
+        interface Window {
+          getter any (DOMString name);
+          attribute DOMString name;
+          // ...
+        };
+    
+ + The following HTML document illustrates how the named properties on the + Window object can be shadowed, and how + the property for an attribute will not be replaced when declaring + a variable of the same name: + +
+        <!DOCTYPE html>
+        <title>Variable declarations and assignments on Window</title>
+        <iframe name=abc></iframe>
+        <!-- Shadowing named properties -->
+        <script>
+          window.abc;    // Evaluates to the iframe's Window object.
+          abc = 1;       // Shadows the named property.
+          window.abc;    // Evaluates to 1.
+        </script>
+        
+        <!-- Preserving properties for IDL attributes -->
+        <script>
+          Window.prototype.def = 2;         // Places a property on the prototype.
+          window.hasOwnProperty("length");  // Evaluates to true.
+          length;                           // Evaluates to 1.
+          def;                              // Evaluates to 2.
+        </script>
+        <script>
+          var length;                       // Variable declaration leaves existing property.
+          length;                           // Evaluates to 1.
+          var def;                          // Variable declaration creates shadowing property.
+          def;                              // Evaluates to undefined.
+        </script>
+    
+
+ + +

[LegacyArrayClass]

+ +If the [{{LegacyArrayClass}}] +[=extended attribute=] +appears on an [=interface=] +that is not defined to [=interface/inherit=] +from another, it indicates that the internal \[[Prototype]] +property of its [=interface prototype object=] +will be the Array prototype object rather than +the Object prototype object. This allows +Array methods to be used more easily +with objects implementing the interface. + +The [{{LegacyArrayClass}}] extended attribute +must [=takes no arguments|take no arguments=]. +It must not be used on an interface that +has any [=inherited interfaces=]. + +Note: Interfaces using [{{LegacyArrayClass}}] will +need to define a “length” [=attribute=] +of type {{unsigned long}} that exposes the length +of the array-like object, in order for the inherited Array +methods to operate correctly. Such interfaces would typically also +[=support indexed properties=], +which would provide access to the array elements. + +See [[#interface-prototype-object]] for the +specific requirements that the use of [{{LegacyArrayClass}}] +entails. + +
+ + The following [=IDL fragment=] + defines two [=interfaces=] + that use [{{LegacyArrayClass}}]. + +
+        [LegacyArrayClass]
+        interface ItemList {
+          attribute unsigned long length;
+          getter object getItem(unsigned long index);
+          setter object setItem(unsigned long index, object item);
+        };
+        
+        [LegacyArrayClass]
+        interface ImmutableItemList {
+          readonly attribute unsigned long length;
+          getter object getItem(unsigned long index);
+        };
+    
+ + In an ECMAScript implementation of the above two interfaces, + with appropriate definitions for getItem, setItem and removeItem, + Array methods to inspect and + modify the array-like object can be used. + +
+        var list = getItemList();  // Obtain an instance of ItemList.
+        
+        list.concat();             // Clone the ItemList into an Array.
+        list.pop();                // Remove an item from the ItemList.
+        list.unshift({ });         // Insert an item at index 0.
+    
+ + ImmutableItemList has a read only + length [=attribute=] + and no indexed property [=indexed property setters|setter=]. The + mutating Array methods will generally not + succeed on objects implementing ImmutableItemList. + The exact behavior depends on the definition of the [=Array methods=] themselves. + +
+ + +

[LegacyUnenumerableNamedProperties]

+ +If the [{{LegacyUnenumerableNamedProperties}}] +[=extended attribute=] +appears on a [=interface=] +that [=support named properties|supports named properties=], +it indicates that all the interface's named properties are unenumerable. + +The [{{LegacyUnenumerableNamedProperties}}] +extended attribute must +[=takes no arguments|take no arguments=] +and must not appear on an interface +that does not define a [=named property getter=]. + +If the [{{LegacyUnenumerableNamedProperties}}] +extended attribute is specified on an interface, then it applies to all its derived interfaces and +must not be specified on any of them. + +See [[#property-enumeration]] +for the specific requirements that the use of +[{{LegacyUnenumerableNamedProperties}}] +entails. + + +

[LenientSetter]

+ +If the [{{LenientSetter}}] +[=extended attribute=] +appears on a [=read only=] +[=regular attribute=], +it indicates that a no-op setter will be generated for the attribute’s +accessor property. This results in erroneous assignments to the property +in strict mode to be ignored rather than causing an exception to be thrown. + +
+ + Specifications should not use [{{LenientSetter}}] + unless required for compatibility reasons. Pages have been observed + where authors have attempted to polyfill an IDL attribute by assigning + to the property, but have accidentally done so even if the property + exists. In strict mode, this would cause an exception to be thrown, + potentially breaking page. Without [{{LenientSetter}}], + this could prevent a browser from shipping the feature. + + Specification authors who + wish to use this feature are strongly advised to discuss this on the + public-script-coord@w3.org + mailing list before proceeding. + +
+ +The [{{LenientThis}}] extended attribute +must +[=takes no arguments|take no arguments=]. +It must not be used on anything other than +a [=read only=] +[=regular attribute=]. + +An attribute with the [{{LenientSetter}}] +extended attribute must not also be declared +with the [{{PutForwards}}] +or [{{Replaceable}}] extended attributes. + +See the Attributes section for how +[{{LenientSetter}}] +is to be implemented. + +
+ + The following IDL fragment defines an interface that uses the + [{{LenientSetter}}] extended + attribute. + +
+        interface Example {
+          [LenientSetter] readonly attribute DOMString x;
+          readonly attribute DOMString y;
+        };
+    
+ + An ECMAScript implementation that supports this interface will + have a setter on the accessor property that correspond to x, + which allows any assignment to be ignored in strict mode. + +
+        "use strict";
+        
+        var example = getExample();  // Get an instance of Example.
+        
+        // Fine; while we are in strict mode, there is a setter that is a no-op.
+        example.x = 1;
+        
+        // Throws a TypeError, since we are in strict mode and there is no setter.
+        example.y = 1;
+    
+
+ + +

[LenientThis]

+ +If the [{{LenientThis}}] +[=extended attribute=] +appears on a [=regular attribute=], +it indicates that invocations of the attribute’s getter or setter +with a this value that is not an +object that implements the [=interface=] +on which the attribute appears will be ignored. + +The [{{LenientThis}}] extended attribute +must +[=takes no arguments|take no arguments=]. +It must not be used on a +[=static attribute=]. + +

+ Specifications should not use [{{LenientThis}}] + unless required for compatibility reasons. Specification authors who + wish to use this feature are strongly advised to discuss this on the + public-script-coord@w3.org + mailing list before proceeding. +

+ +See the Attributes section for how +[{{LenientThis}}] +is to be implemented. + +
+ + The following IDL fragment defines an interface that uses the + [{{LenientThis}}] extended + attribute. + +
+        interface Example {
+          [LenientThis] attribute DOMString x;
+          attribute DOMString y;
+        };
+    
+ + An ECMAScript implementation that supports this interface will + allow the getter and setter of the accessor property that corresponds + to x to be invoked with something other than an Example + object. + +
+        var example = getExample();  // Get an instance of Example.
+        var obj = { };
+        
+        // Fine.
+        example.x;
+        
+        // Ignored, since the this value is not an Example object and [LenientThis] is used.
+        Object.getOwnPropertyDescriptor(Example.prototype, "x").get.call(obj);
+        
+        // Also ignored, since Example.prototype is not an Example object and [LenientThis] is used.
+        Example.prototype.x;
+        
+        // Throws a TypeError, since Example.prototype is not an Example object.
+        Example.prototype.y;
+    
+
+ + +

[NamedConstructor]

+ +If the [{{NamedConstructor}}] +[=extended attribute=] +appears on an [=interface=], +it indicates that the ECMAScript global object will have a property with the +specified name whose value is a constructor function that can +create objects that implement the interface. +Multiple [{{NamedConstructor}}] extended +attributes may appear on a given interface. + +The [{{NamedConstructor}}] +extended attribute must either +[=takes an identifier|take an identifier=] or +[=takes a named argument list|take a named argument list=]. +The first form, [NamedConstructor=identifier], has the same meaning as +using an empty argument list, [NamedConstructor=identifier()]. For each +[{{NamedConstructor}}] extended attribute +on the interface, there will be a way to construct an object that implements +the interface by passing the specified arguments to the constructor function +that is the value of the aforementioned property. + +The identifier used for the named constructor must not +be the same as that used by an [{{NamedConstructor}}] +extended attribute on another interface, must not +be the same as an identifier of an interface +that has an [=interface object=], +and must not be one of the +[=reserved identifiers=]. + +The [{{NamedConstructor}}] extended attribute +must not be used on a [=callback interface=]. + +See [[#named-constructors]] for details on how named constructors +are to be implemented. + +
+ + The following IDL defines an interface that uses the + [{{NamedConstructor}}] extended + attribute. + +
+        [NamedConstructor=Audio,
+         NamedConstructor=Audio(DOMString src)]
+        interface HTMLAudioElement : HTMLMediaElement {
+          // ...
+        };
+    
+ + An ECMAScript implementation that supports this interface will + allow the construction of HTMLAudioElement + objects using the Audio constructor. + +
+        typeof Audio;                   // Evaluates to 'function'.
+        
+        var a1 = new Audio();           // Creates a new object that implements
+                                        // HTMLAudioElement, using the zero-argument
+                                        // constructor.
+        
+        var a2 = new Audio('a.flac');   // Creates an HTMLAudioElement using the
+                                        // one-argument constructor.
+    
+
+ + +

[NewObject]

+ +If the [{{NewObject}}] +[=extended attribute=] +appears on a [=regular operation|regular=] +or [=static operations|static=] +[=operation=], +then it indicates that when calling the operation, +a reference to a newly created object +must always be returned. + +The [{{NewObject}}] +extended attribute must +[=takes no arguments|take no arguments=]. + +The [{{NewObject}}] +extended attribute must not +be used on anything other than a [=regular operation|regular=] +or [=static operations|static=] +[=operation=] +whose [=return type=] +is an interface type or +a [=promise type=]. + +
+ + As an example, this extended attribute is suitable for use on + the createElement + operation on the Document + interface ([[DOM]], section 6.5), + since a new object should always be returned when + it is called. + +
+        interface Document : Node {
+          [NewObject] Element createElement(DOMString localName);
+          // ...
+        };
+    
+
+ + +

[NoInterfaceObject]

+ +If the [{{NoInterfaceObject}}] +[=extended attribute=] +appears on an [=interface=], +it indicates that an +[=interface object=] +will not exist for the interface in the ECMAScript binding. + +

+ The [{{NoInterfaceObject}}] extended attribute + should not be used on interfaces that are not + solely used as [=supplemental interfaces|supplemental=] interfaces, + unless there are clear Web compatibility reasons for doing so. Specification authors who + wish to use this feature are strongly advised to discuss this on the + public-script-coord@w3.org + mailing list before proceeding. +

+ +The [{{NoInterfaceObject}}] extended attribute +must [=takes no arguments|take no arguments=]. + +If the [{{NoInterfaceObject}}] extended attribute +is specified on an interface, then the [{{Constructor}}] +extended attribute must not also be specified on that interface. +A [{{NamedConstructor}}] extended attribute is fine, +however. + +The [{{NoInterfaceObject}}] extended attribute +must not be specified on an interface that has any +[=static operations=] defined on it. + +The [{{NoInterfaceObject}}] extended attribute +must not be specified on a [=callback interface=] +unless it has a [=constant=] declared on it. +This is because callback interfaces without constants never have +[=interface objects=]. + +An interface that does not have the [{{NoInterfaceObject}}] extended +attribute specified must not inherit +from an interface that has the [{{NoInterfaceObject}}] extended +attribute specified. + +See [[#es-interfaces]] +for the specific requirements that the use of +[{{NoInterfaceObject}}] entails. + +
+ + The following [=IDL fragment=] defines two interfaces, one whose interface object + is exposed on the ECMAScript global object, and one whose isn’t: + +
+        interface Storage {
+          void addEntry(unsigned long key, any value);
+        };
+        
+        [NoInterfaceObject]
+        interface Query {
+          any lookupEntry(unsigned long key);
+        };
+    
+ + An ECMAScript implementation of the above IDL would allow + manipulation of Storage’s + prototype, but not Query’s. + +
+        typeof Storage;                        // evaluates to "object"
+        
+        // Add some tracing alert() call to Storage.addEntry.
+        var fn = Storage.prototype.addEntry;
+        Storage.prototype.addEntry = function(key, value) {
+          alert('Calling addEntry()');
+          return fn.call(this, key, value);
+        };
+        
+        typeof Query;                          // evaluates to "undefined"
+        var fn = Query.prototype.lookupEntry;  // exception, Query isn’t defined
+    
+
+ + +

[OverrideBuiltins]

+ +If the [{{OverrideBuiltins}}] +[=extended attribute=] +appears on an [=interface=], +it indicates that for a [=platform object=] implementing the interface, +properties corresponding to all of +the object’s [=supported property names=] +will appear to be on the object, +regardless of what other properties exist on the object or its +prototype chain. This means that named properties will always shadow +any properties that would otherwise appear on the object. +This is in contrast to the usual behavior, which is for named properties +to be exposed only if there is no property with the +same name on the object itself or somewhere on its prototype chain. + +The [{{OverrideBuiltins}}] +extended attribute must +[=takes no arguments|take no arguments=] +and must not appear on an interface +that does not define a [=named property getter=] +or that also is declared with the [{{Global}}] +or [{{PrimaryGlobal}}] +extended attribute. If the extended attribute is specified on +a [=partial interface=] +definition, then that partial interface definition must +be the part of the interface definition that defines +the [=named property getter=]. + +See [[#indexed-and-named-properties]] +and [[#defineownproperty]] +for the specific requirements that the use of +[{{OverrideBuiltins}}] entails. + +
+ + The following [=IDL fragment=] + defines two [=interfaces=], + one that has a [=named property getter=] + and one that does not. + +
+        interface StringMap {
+          readonly attribute unsigned long length;
+          getter DOMString lookup(DOMString key);
+        };
+        
+        [OverrideBuiltins]
+        interface StringMap2 {
+          readonly attribute unsigned long length;
+          getter DOMString lookup(DOMString key);
+        };
+    
+ + In an ECMAScript implementation of these two interfaces, + getting certain properties on objects implementing + the interfaces will result in different values: + +
+        // Obtain an instance of StringMap.  Assume that it has "abc", "length" and
+        // "toString" as supported property names.
+        var map1 = getStringMap();
+        
+        // This invokes the named property getter.
+        map1.abc;
+        
+        // This fetches the "length" property on the object that corresponds to the
+        // length attribute.
+        map1.length;
+        
+        // This fetches the "toString" property from the object's prototype chain.
+        map1.toString;
+        
+        // Obtain an instance of StringMap2.  Assume that it also has "abc", "length"
+        // and "toString" as supported property names.
+        var map2 = getStringMap2();
+        
+        // This invokes the named property getter.
+        map2.abc;
+        
+        // This also invokes the named property getter, despite the fact that the "length"
+        // property on the object corresponds to the length attribute.
+        map2.length;
+        
+        // This too invokes the named property getter, despite the fact that "toString" is
+        // a property in map2's prototype chain.
+        map2.toString;
+    
+
+ + +

[PutForwards]

+ +If the [{{PutForwards}}] +[=extended attribute=] +appears on a [=read only=] +[=regular attribute=] declaration whose type is +an interface type, +it indicates that assigning to the attribute will have specific behavior. +Namely, the assignment is “forwarded” to the attribute (specified by +the extended attribute argument) on the object that is currently +referenced by the attribute being assigned to. + +The [{{PutForwards}}] extended +attribute must [=takes an identifier|take an identifier=]. +Assuming that: + +* |A| is the [=attribute=] + on which the [{{PutForwards}}] + extended attribute appears, +* |I| is the [=interface=] + on which |A| is declared, +* |J| is the interface type + that |A| is declared to be of, and +* |N| is the [=identifier=] + argument of the extended attribute, + +then there must be another +[=attribute=] |B| +declared on |J| whose [=identifier=] +is |N|. Assignment of a value to the attribute |A| +on an object implementing |I| will result in that value +being assigned to attribute |B| of the object that |A| +references, instead. + +Note that [{{PutForwards}}]-annotated +[=attributes=] can be +chained. That is, an attribute with the [{{PutForwards}}] +[=extended attribute=] +can refer to an attribute that itself has that extended attribute. +There must not exist a cycle in a +chain of forwarded assignments. A cycle exists if, when following +the chain of forwarded assignments, a particular attribute on +an [=interface=] is +encountered more than once. + +An attribute with the [{{PutForwards}}] +extended attribute must not also be declared +with the [{{LenientSetter}}] or +[{{Replaceable}}] extended attributes. + +The [{{PutForwards}}] +extended attribute must not be used +on an [=attribute=] that +is not [=read only=]. + +The [{{PutForwards}}] extended attribute +must not be used on a +[=static attribute=]. + +The [{{PutForwards}}] extended attribute +must not be used on an attribute declared on +a [=callback interface=]. + +See the Attributes section for how +[{{PutForwards}}] +is to be implemented. + +
+ + The following [=IDL fragment=] defines interfaces for names and people. + The [{{PutForwards}}] extended + attribute is used on the name attribute + of the Person interface to indicate + that assignments to that attribute result in assignments to the + full attribute of the + Person object: + +
+        interface Name {
+          attribute DOMString full;
+          attribute DOMString family;
+          attribute DOMString given;
+        };
+        
+        interface Person {
+          [PutForwards=full] readonly attribute Name name;
+          attribute unsigned short age;
+        };
+    
+ + In the ECMAScript binding, this would allow assignments to the + “name” property: + +
+        var p = getPerson();           // Obtain an instance of Person.
+        
+        p.name = 'John Citizen';       // This statement...
+        p.name.full = 'John Citizen';  // ...has the same behavior as this one.
+    
+
+ + +

[Replaceable]

+ +If the [{{Replaceable}}] +[=extended attribute=] +appears on a [=read only=] +[=regular attribute=], +it indicates that setting the corresponding property on the +[=platform object=] will result in +an own property with the same name being created on the object +which has the value being assigned. This property will shadow +the accessor property corresponding to the attribute, which +exists on the [=interface prototype object=]. + +The [{{Replaceable}}] +extended attribute must +[=takes no arguments|take no arguments=]. + +An attribute with the [{{Replaceable}}] +extended attribute must not also be declared +with the [{{LenientSetter}}] or +[{{PutForwards}}] extended attributes. + +The [{{Replaceable}}] +extended attribute must not be used +on an [=attribute=] that +is not [=read only=]. + +The [{{Replaceable}}] extended attribute +must not be used on a +[=static attribute=]. + +The [{{Replaceable}}] extended attribute +must not be used on an attribute declared on +a [=callback interface=]. + +See [[#es-attributes]] +for the specific requirements that the use of +[{{Replaceable}}] entails. + +
+ + The following [=IDL fragment=] + defines an [=interface=] + with an [=operation=] + that increments a counter, and an [=attribute=] + that exposes the counter’s value, which is initially 0: + +
+        interface Counter {
+          [Replaceable] readonly attribute unsigned long value;
+          void increment();
+        };
+    
+ + Assigning to the “value” property + on a [=platform object=] implementing Counter + will shadow the property that corresponds to the + [=attribute=]: + +
+        var counter = getCounter();                              // Obtain an instance of Counter.
+        counter.value;                                           // Evaluates to 0.
+        
+        counter.hasOwnProperty("value");                         // Evaluates to false.
+        Object.getPrototypeOf(counter).hasOwnProperty("value");  // Evaluates to true.
+        
+        counter.increment();
+        counter.increment();
+        counter.value;                                           // Evaluates to 2.
+        
+        counter.value = 'a';                                     // Shadows the property with one that is unrelated
+                                                                 // to Counter::value.
+        
+        counter.hasOwnProperty("value");                         // Evaluates to true.
+        
+        counter.increment();
+        counter.value;                                           // Evaluates to 'a'.
+        
+        delete counter.value;                                    // Reveals the original property.
+        counter.value;                                           // Evaluates to 3.
+    
+
+ + +

[SameObject]

+ +If the [{{SameObject}}] +[=extended attribute=] +appears on a [=read only=] +[=attribute=], then it +indicates that when getting the value of the attribute on a given +object, the same value must always +be returned. + +The [{{SameObject}}] +extended attribute must +[=takes no arguments|take no arguments=]. + +The [{{SameObject}}] +extended attribute must not +be used on anything other than a [=read only=] +[=attribute=] +whose type is an interface type +or {{object}}. + +
+ + As an example, this extended attribute is suitable for use on + the implementation + attribute on the Document + interface ([[DOM]], section 6.5), + since the same object is always returned for a given + Document object. + +
+        interface Document : Node {
+          [SameObject] readonly attribute DOMImplementation implementation;
+          // ...
+        };
+    
+
+ + +

[SecureContext]

+ +If the [{{SecureContext}}] +[=extended attribute=] +appears on an [=interface=], +[=partial interface=], +[=namespace=], +[=partial namespace=], +[=interface member=], or +[=namespace member=], +it indicates that the construct is exposed +only within a +[=secure context=]. + +The [{{SecureContext}}] +extended attribute must +[=takes no arguments|take no arguments=]. + +The [{{SecureContext}}] +extended attribute must not +be used on anything other than an +[=interface=], +[=partial interface=], +[=namespace=], +[=partial namespace=], +[=interface member=], or +[=namespace member=]. + +Whether a construct that the [{{SecureContext}}] +[=extended attribute=] +can be specified on is available only in secure contexts +is defined as follows: + +* If the [{{SecureContext}}] + [=extended attribute=] + is specified on the construct, then it is + [=available only in secure contexts=]. +* Otherwise, if the [{{SecureContext}}] + [=extended attribute=] + does not appear on a construct, then whether it is + [=available only in secure contexts=] + depends on the type of construct: + +
+ : interface + : namespace + :: The interface or namespace is not + [=available only in secure contexts=]. + + : partial interface + : partial namespace + :: The partial interface or partial namespace is [=available only in secure contexts=] if and only if the original interface or namespace definition + is. + + : interface member + :: The interface member is [=available only in secure contexts=] + if and only if the interface or partial interface the member is declared on is. + + : namespace member + :: The namespace member is [=available only in secure contexts=] + if and only if the namspace or partial namespace the member is declared on is. +
+ +Note: Whether a construct is +[=available only in secure contexts=] +influences whether it is [=exposed=] in a given +ECMAScript global environment. + +If [{{SecureContext}}] appears on an +[=overloaded=] [=operation=], +then it must appear on all overloads. + +The [{{SecureContext}}] extended attribute +must not be specified on both an interface member and the +interface or partial interface definition the interface member is declared on, or +on both a namespace member and the namespace or partial namespace definition the +namespace member is declared on. + +An interface without the [{{SecureContext}}] extended attribute +must not [=interface/inherit=] from another interface +that does specify [{{SecureContext}}]. + +
+ + The following [=IDL fragment=] defines an interface + with one [=operation=] that is executable from all + contexts, and two which are executable only from secure contexts. + +
+        interface PowerfulFeature {
+          // This call will succeed in all contexts.
+          Promise <Result> calculateNotSoSecretResult();
+        
+          // This operation will not be exposed to a non-secure context. In such a context,
+          // there will be no "calculateSecretResult" property on PowerfulFeature.prototype.
+          [SecureContext] Promise<Result> calculateSecretResult();
+        
+          // The same applies here: the attribute will not be exposed to a non-secure context,
+          // and in a non-secure context there will be no "secretBoolean" property on
+          // PowerfulFeature.prototype.
+          [SecureContext] readonly attribute boolean secretBoolean;
+        };
+    
+
+ + +

[TreatNonObjectAsNull]

+ +If the [{{TreatNonObjectAsNull}}] +[=extended attribute=] +appears on a [=callback function=], +then it indicates that any value assigned to an [=attribute=] +whose type is a [=nullable type|nullable=] +[=callback function=] +that is not an object will be converted to +the null value. + +

+ Specifications should not use [{{TreatNonObjectAsNull}}] + unless required to specify the behavior of legacy APIs or for consistency with these + APIs. Specification authors who + wish to use this feature are strongly advised to discuss this on the + public-script-coord@w3.org + mailing list before proceeding. At the time of writing, the only known + valid use of [{{TreatNonObjectAsNull}}] + is for the [=callback functions=] used as the type + of [=event handler IDL attributes=] + such as onclick and onerror. +

+ +See [[#es-nullable-type]] +for the specific requirements that the use of +[{{TreatNonObjectAsNull}}] entails. + +
+ + The following [=IDL fragment=] defines an interface that has one + attribute whose type is a [{{TreatNonObjectAsNull}}]-annotated + [=callback function=] and another whose type is a + [=callback function=] without the [=extended attribute=]: + +
+        callback OccurrenceHandler = void (DOMString details);
+        
+        [TreatNonObjectAsNull]
+        callback ErrorHandler = void (DOMString details);
+        
+        interface Manager {
+          attribute OccurrenceHandler? handler1;
+          attribute ErrorHandler? handler2;
+        };
+    
+ + In an ECMAScript implementation, assigning a value that is not + an object (such as a Number value) + to handler1 will have different behavior from that when assigning + to handler2: + +
+        var manager = getManager();  // Get an instance of Manager.
+        
+        manager.handler1 = function() { };
+        manager.handler1;            // Evaluates to the function.
+        
+        try {
+          manager.handler1 = 123;    // Throws a TypeError.
+        } catch (e) {
+        }
+        
+        manager.handler2 = function() { };
+        manager.handler2;            // Evaluates to the function.
+        
+        manager.handler2 = 123;
+        manager.handler2;            // Evaluates to null.
+    
+
+ + +

[TreatNullAs]

+ +If the [{{TreatNullAs}}] +[=extended attribute=] +appears on an [=attribute=] +or [=operation=] argument whose type is +{{DOMString}}, +it indicates that a null value +assigned to the attribute or passed as the operation argument will be +handled differently from its default handling. Instead of being stringified +to “null”, which is the default, +it will be converted to the empty string “”. + +If [{{TreatNullAs}}] is specified on +an operation itself, and that operation is on a [=callback interface=], +then it indicates that a user object implementing the interface will have the return +value of the function that implements the operation handled in the same way as for operation arguments +and attributes, as above. + +The [{{TreatNullAs}}] +extended attribute must [=takes an identifier|take the identifier=] +EmptyString. + +The [{{TreatNullAs}}] extended attribute +must not be specified on an operation argument, +attribute or operation return value whose type is not {{DOMString}}. + +Note: This means that even an attribute of type DOMString? must not +use [{{TreatNullAs}}], since null +is a valid value of that type. + +The [{{TreatNullAs}}] extended attribute +also must not be specified on an operation on +a non-callback interface. + +See [[#es-DOMString]] +for the specific requirements that the use of +[{{TreatNullAs}}] entails. + +
+ + The following [=IDL fragment=] defines an interface that has one + attribute with the [{{TreatNullAs}}] + extended attribute, and one operation with an argument that has + the extended attribute: + +
+        interface Dog {
+          attribute DOMString name;
+          [TreatNullAs=EmptyString] attribute DOMString owner;
+        
+          boolean isMemberOfBreed([TreatNullAs=EmptyString] DOMString breedName);
+        };
+    
+ + An ECMAScript implementation implementing the Dog + interface would convert a null value + assigned to the “owner” property or passed as the + argument to the isMemberOfBreed function + to the empty string rather than "null": + +
+        var d = getDog();         // Assume d is a platform object implementing the Dog
+                                  // interface.
+        
+        d.name = null;            // This assigns the string "null" to the .name
+                                  // property.
+        
+        d.owner = null;           // This assigns the string "" to the .owner property.
+        
+        d.isMemberOfBreed(null);  // This passes the string "" to the isMemberOfBreed
+                                  // function.
+    
+
+ + +

[Unforgeable]

+ +If the [{{Unforgeable}}] +[=extended attribute=] +appears on a non-[=Static attributes|static=] +[=attribute=] +or non-[=static operations|static=] +[=operations=], it indicates +that the attribute or operation will be reflected as an ECMAScript property in +a way that means its behavior cannot be modified and that performing +a property lookup on the object will always result in the attribute’s +property value being returned. In particular, the property will be +non-configurable and will exist as an own property on the object +itself rather than on its prototype. + +If the [{{Unforgeable}}] +[=extended attribute=] +appears on an [=interface=], +it indicates that all of the non-[=Static attributes|static=] +[=attributes=] +and non-[=static operations|static=] +[=operations=] declared on +that interface and its [=consequential interfaces=] +will be similarly reflected as own ECMAScript properties on objects +that implement the interface, rather than on the prototype. + +An attribute or operation is said to be unforgeable +on a given interface |A| if any of the following are true: + +* The attribute or operation is declared on |A| or one + of |A|’s [=consequential interfaces=], + and is annotated with the [{{Unforgeable}}] + [=extended attribute=]. +* The attribute or operation is declared on |A| or one + of |A|’s [=consequential interfaces=], + and that interface is annotated with the [{{Unforgeable}}] + [=extended attribute=]. +* There exists an interface |B|, which is either |A| or one of + |A|’s [=consequential interfaces=], + |B| is annotated with the [{{Unforgeable}}] + [=extended attribute=], + and the attribute or operation is declared on one of |B|’s consequential interfaces. + +The [{{Unforgeable}}] +extended attribute must +[=takes no arguments|take no arguments=]. + +The [{{Unforgeable}}] +extended attribute must not appear on +anything other than an [=attribute=], +non-[=static operations|static=] [=operation=] +or an [=interface=]. If it does +appear on an [=operation=], then +it must appear on all operations with +the same [=identifier=] on that interface. + +If an attribute or operation |X| is [=unforgeable=] +on an interface |A|, and |A| is one of the +[=inherited interfaces=] +of another interface |B|, then |B| and all of its +[=consequential interfaces=] +must not have a non-static attribute or +[=regular operation=] with the same +[=identifier=] as |X|. + +
+ + For example, the following is disallowed: + +
+        interface A1 {
+          [Unforgeable] readonly attribute DOMString x;
+        };
+        interface B1 : A1 {
+          void x();  // Invalid; would be shadowed by A1's x.
+        };
+        
+        interface B2 : A1 { };
+        B2 implements Mixin;
+        interface Mixin {
+          void x();  // Invalid; B2's copy of x would be shadowed by A1's x.
+        };
+        
+        [Unforgeable]
+        interface A2 {
+          readonly attribute DOMString x;
+        };
+        interface B3 : A2 {
+          void x();  // Invalid; would be shadowed by A2's x.
+        };
+        
+        interface B4 : A2 { };
+        B4 implements Mixin;
+        interface Mixin {
+          void x();  // Invalid; B4's copy of x would be shadowed by A2's x.
+        };
+        
+        interface A3 { };
+        A3 implements A2;
+        interface B5 : A3 {
+          void x();  // Invalid; would be shadowed by A3's mixed-in copy of A2's x.
+        };
+    
+
+ +See [[#es-attributes]], +[[#es-operations]], +[[#es-platform-objects]], +[[#indexed-and-named-properties]] and +[[#defineownproperty]] +for the specific requirements that the use of +[{{Unforgeable}}] entails. + +
+ + The following [=IDL fragment=] defines + an interface that has two [=attributes=], + one of which is designated as [{{Unforgeable}}]: + +
+        interface System {
+          [Unforgeable] readonly attribute DOMString username;
+          readonly attribute long long loginTime;
+        };
+    
+ + In an ECMAScript implementation of the interface, the username attribute will be exposed as a non-configurable property on the + object itself: + +
+        var system = getSystem();                      // Get an instance of System.
+        
+        system.hasOwnProperty("username");             // Evaluates to true.
+        system.hasOwnProperty("loginTime");            // Evaluates to false.
+        System.prototype.hasOwnProperty("username");   // Evaluates to false.
+        System.prototype.hasOwnProperty("loginTime");  // Evaluates to true.
+        
+        try {
+          // This call would fail, since the property is non-configurable.
+          Object.defineProperty(system, "username", { value: "administrator" });
+        } catch (e) { }
+        
+        // This defineProperty call would succeed, because System.prototype.loginTime
+        // is configurable.
+        var forgedLoginTime = 5;
+        Object.defineProperty(System.prototype, "loginTime", { value: forgedLoginTime });
+        
+        system.loginTime;  // So this now evaluates to forgedLoginTime.
+    
+
+ + +

[Unscopable]

+ +If the [{{Unscopable}}] +[=extended attribute=] +appears on a [=regular attribute=] +or [=regular operation=], it +indicates that an object that implements an interface with the given +interface member will not include its property name in any object +environment record with it as its base object. The result of this is +that bare identifiers matching the property name will not resolve to +the property in a with statement. This is achieved by +including the property name on the +[=interface prototype object=]’s +[=@@unscopables=] property’s value. + +The [{{Unscopable}}] +extended attribute must +[=takes no arguments|take no arguments=]. + +The [{{Unscopable}}] +extended attribute must not appear on +anything other than a [=regular attribute=] +or [=regular operation=]. + +See [[#interface-prototype-object]] +for the specific requirements that the use of +[{{Unscopable}}] entails. + +
+ + For example, with the following IDL: + +
+        interface Thing {
+          void f();
+          [Unscopable] g();
+        };
+    
+ + the “f” property an be referenced with a bare identifier + in a with statement but the “g” property cannot: + +
+        var thing = getThing();  // An instance of Thing
+        with (thing) {
+          f;                     // Evaluates to a Function object.
+          g;                     // Throws a ReferenceError.
+        }
+    
+
+ + +

Security

+ +Certain algorithms in the sections below are defined to +perform a security check on a given +object. This check is used to determine whether a given +[=operation=] invocation or +[=attribute=] access should be +allowed. The security check takes the following four inputs: + +1. the [=platform object=] on + which the operation invocation or attribute access is being done, +1. the ECMAScript global environment associated with the + Function object that implements the + operation or attribute, +1. the [=identifier=] + of the operation or attribute, and +1. the type of the Function object – + “method” (when it corresponds to an IDL operation), or + “getter” or “setter” (when it corresponds to the + getter or setter function of an IDL attribute). + +Note: The expectation is that the HTML specification defines how a +security check is performed, and that it will either throw an +appropriate exception or return normally. [[!HTML]] + + +

Overload resolution algorithm

+ +In order to define how overloaded function invocations are resolved, the +overload resolution algorithm +is defined. Its input is an [=effective overload set=], +|S|, and a list of ECMAScript values, |arg|0..|n|−1. +Its output is a pair consisting of the [=operation=] or +[=extended attribute=] of one of |S|’s entries +and a list of IDL values or the special value “missing”. The algorithm behaves as follows: + +
    + 1. Let |maxarg| be the length of the longest type list of the entries in |S|. + 1. Initialize |argcount| to be min(|maxarg|, |n|). + + 1. Remove from |S| all entries whose type list is not of length |argcount|. + + 1. If |S| is empty, then throw a TypeError. + + 1. Initialize |d| to −1. + + 1. Initialize |method| to + undefined. + + 1. If there is more than one entry in |S|, then set + |d| to be the [=distinguishing argument index=] + for the entries of |S|. + + 1. Initialize |values| to be an empty list, where each entry will be either an IDL value or the special value “missing”. + + 1. Initialize |i| to 0. + + 1. While |i| < |d|: + 1. Let |V| be |arg||i|. + 1. Let |type| be the type at index |i| in the type list of any entry in |S|. + + Note: All entries in |S| at this point have the same type and [=optionality value=] at index |i|. + + 1. Let |optionality| be the value at index |i| in the list of [=optionality values=] of any entry in |S|. + 1. If |optionality| is “optional” and |V| is undefined, then: + 1. If the argument at index |i| is declared with a [=optional argument/default value=], + then append to |values| that default value. + 1. Otherwise, append to |values| the special value “missing”. + 1. Otherwise, append to |values| the result of [=converted to an IDL value|converting=] + |V| to IDL type |type|. + 1. Set |i| to |i| + 1. + + 1. If |i| = |d|, then: + 1. Let |V| be |arg||i|. + + Note: This is the argument that will be used to resolve which overload is selected. + + 1. If |V| is undefined, and there is an entry in |S| + whose list of [=optionality values=] has “optional” at index |i|, + then remove from |S| all other entries. + + 1. Otherwise: if |V| is null or undefined, + and there is an entry in |S| that has one of the following types at position |i| of its type list, + * a [=nullable type=] + * a dictionary type + * a [=union type=] that + [=includes a nullable type=] or that + has a dictionary type in its [=flattened member types|flattened members=] + + then remove from |S| all other entries. + + 1. Otherwise: if |V| is a [=platform object=], and + there is an entry in |S| that has one of the following types at position |i| of its type list, + * an interface type that |V| implements + * {{object}} + * a [=nullable type|nullable=] version of any of the above types + * a [=union type=] or a [=nullable type|nullable=] union type + that has one of the above types in its [=flattened member types=] + + then remove from |S| all other entries. + + 1. Otherwise: if |V| is a RegExp object and + there is an entry in |S| that has one of the following types at position |i| of its type list, + * {{RegExp}} + * {{object}} + * a [=nullable type|nullable=] version of either of the above types + * a [=union type=] or [=nullable type|nullable=] union type + that has one of the above types in its [=flattened member types=] + + then remove from |S| all other entries. + + 1. Otherwise: if |V| is a {{DOMException}} platform object and + there is an entry in |S| that has one of the following types at position |i| of its type list, + * {{DOMException}} + * {{Error!!interface}} + * {{object}} + * a [=nullable type|nullable=] version of either of the above types + * a [=union type=] or [=nullable type|nullable=] union type + that has one of the above types in its [=flattened member types=] + + then remove from |S| all other entries. + + 1. Otherwise: if |V| is an Error object (that is, it has an \[[ErrorData]] [=internal slot=]) and + there is an entry in |S| that has one of the following types at position |i| of its type list, + * {{Error!!interface}} + * {{object}} + * a [=nullable type|nullable=] version of either of the above types + * a [=union type=] or [=nullable type|nullable=] union type + that has one of the above types in its [=flattened member types=] + + then remove from |S| all other entries. + + 1. Otherwise: if |V| is an object with an \[[ArrayBufferData]] [=internal slot=] and + there is an entry in |S| that has one of the following types at position |i| of its type list, + * {{ArrayBuffer}} + * {{object}} + * a [=nullable type|nullable=] version of either of the above types + * a [=union type=] or [=nullable type|nullable=] union type + that has one of the above types in its [=flattened member types=] + + then remove from |S| all other entries. + + 1. Otherwise: if |V| is an object with a \[[DataView]] [=internal slot=] and + there is an entry in |S| that has one of the following types at position |i| of its type list, + * {{DataView}} + * {{object}} + * a [=nullable type|nullable=] version of either of the above types + * a [=union type=] or [=nullable type|nullable=] union type + that has one of the above types in its [=flattened member types=] + + then remove from |S| all other entries. + + 1. Otherwise: if |V| is an object with a \[[TypedArrayName]] [=internal slot=] and + there is an entry in |S| that has one of the following types at position |i| of its type list, + * a [=typed array type=] whose name + is equal to the value of |V|’s \[[TypedArrayName]] [=internal slot=] + * {{object}} + * a [=nullable type|nullable=] version of either of the above types + * a [=union type=] or [=nullable type|nullable=] union type + that has one of the above types in its [=flattened member types=] + + then remove from |S| all other entries. + + 1. Otherwise: if [=IsCallable=](|V|) is true, + and there is an entry in |S| that has one of the following types at position |i| of its type list, + * a [=callback function=] type + * {{object}} + * a [=nullable type|nullable=] version of any of the above types + * a [=union type=] or [=nullable type|nullable=] union type + that has one of the above types in its [=flattened member types=] + + then remove from |S| all other entries. + + 1. Otherwise: if |V| is any kind of object except for + a native RegExp object, and + there is an entry in |S| that has one of the + following types at position |i| of its type list, + * a sequence type + * a frozen array type + * a [=nullable type|nullable=] version of any of the above types + * a [=union type=] or [=nullable type|nullable=] union type + that has one of the above types in its [=flattened member types=] + + and after performing the following steps, + + 1. Let |method| be the result of + [=GetMethod=](|V|, [=@@iterator=]). + 1. [=ReturnIfAbrupt=](|method|). + + |method| is not undefined, then remove from |S| all + other entries. + + 1. Otherwise: if |V| is any kind of object except for + a native RegExp object, and + there is an entry in |S| that has one of the following types at position |i| of its type list, + * a [=callback interface=] type + * a dictionary type + * {{object}} + * a [=nullable type|nullable=] version of any of the above types + * a [=union type=] or [=nullable type|nullable=] union type + that has one of the above types in its [=flattened member types=] + + then remove from |S| all other entries. + + 1. Otherwise: if |V| is a Boolean value, + and there is an entry in |S| that has one of the following types at position |i| of its type list, + * {{boolean}} + * a [=nullable type|nullable=] {{boolean}} + * a [=union type=] or [=nullable type|nullable=] union type + that has one of the above types in its [=flattened member types=] + + then remove from |S| all other entries. + + 1. Otherwise: if |V| is a Number value, + and there is an entry in |S| that has one of the following types at position |i| of its type list, + * a [=numeric type=] + * a [=nullable type|nullable=] [=numeric type=] + * a [=union type=] or [=nullable type|nullable=] union type + that has one of the above types in its [=flattened member types=] + + then remove from |S| all other entries. + + 1. Otherwise: if there is an entry in |S| that has one of the following types at position |i| of its type list, + * a [=string type=] + * a [=nullable type|nullable=] version of any of the above types + * a [=union type=] or [=nullable type|nullable=] union type + that has one of the above types in its [=flattened member types=] + + then remove from |S| all other entries. + + 1. Otherwise: if there is an entry in |S| that has one of the following types at position |i| of its type list, + * a [=numeric type=] + * a [=nullable type|nullable=] [=numeric type=] + * a [=union type=] or [=nullable type|nullable=] union type + that has one of the above types in its [=flattened member types=] + + then remove from |S| all other entries. + + 1. Otherwise: if there is an entry in |S| that has one of the following types at position |i| of its type list, + * {{boolean}} + * a [=nullable type|nullable=] {{boolean}} + * a [=union type=] or [=nullable type|nullable=] union type + that has one of the above types in its [=flattened member types=] + + then remove from |S| all other entries. + + 1. Otherwise: if there is an entry in |S| that has {{any}} at position |i| + of its type list, + then remove from |S| all other entries. + + 1. Otherwise: + throw a TypeError. + + 1. Let |callable| be the [=operation=] or [=extended attribute=] + of the single entry in |S|. + + 1. If |i| = |d| and |method| is not undefined, then + 1. Let |V| be |arg||i|. + 1. Let |T| be the type at index |i| in the + type list of the remaining entry in |S|. + 1. If |T| is a sequence type, then + append to |values| the result of + . + 1. Otherwise, |T| is a frozen array type. + Append to |values| the result of + [=Creating a frozen array from an iterable|creating a frozen array of type T from V and method=]. + 1. Set |i| to |i| + 1. + + 1. While |i| < |argcount|: + 1. Let |V| be |arg||i|. + 1. Let |type| be the type at index |i| in the type list of the remaining entry in |S|. + 1. Let |optionality| be the value at index |i| in the list of [=optionality values=] of the remaining entry in |S|. + 1. If |optionality| is “optional” and |V| is undefined, then: + 1. If the argument at index |i| is declared with a [=optional argument/default value=], + then append to |values| that default value. + 1. Otherwise, append to |values| the special value “missing”. + 1. Otherwise, append to |values| the result of + [=converted to an IDL value|converting=] |V| to IDL type |type|. + 1. Set |i| to |i| + 1. + + 1. While |i| is less than the number of arguments |callable| is declared to take: + 1. If |callable|’s argument at index |i| is declared with a [=optional argument/default value=], + then append to |values| that default value. + 1. Otherwise, if |callable|’s argument at index |i| is not variadic, then append to |values| the special value “missing”. + 1. Set |i| to |i| + 1. + + 1. Return the pair <|callable|, |values|>. +
+ +
+ + The overload resolution algorithm performs both the identification + of which overloaded operation, constructor, etc. is being called, + and the conversion of the ECMAScript argument values to their + corresponding IDL values. Informally, it operates as follows. + + First, the selection of valid overloads is done by considering + the number of ECMAScript arguments that were passed in to the function: + + * If there are more arguments passed in than the longest + overload argument list, then they are ignored. + * After ignoring these trailing arguments, only overloads + that can take this exact number of arguments are considered. + If there are none, then a TypeError is thrown. + + Once we have a set of possible overloads with the right number + of arguments, the ECMAScript values are converted from left to right. + The nature of the restrictions on overloading means that if we + have multiple possible overloads at this point, then there will + be one position in the argument list that will be used to + distinguish which overload we will finally select; this is + the [=distinguishing argument index=]. + + We first convert the arguments to the left of the distinguishing + argument. (There is a requirement that an argument to the left of + the distinguishing argument index has the same type as in the other + overloads, at the same index.) Then we inspect the type of the + ECMAScript value that is passed in at the distinguishing argument + index to determine which IDL type it may correspond to. + This allows us to select the final overload that will + be invoked. If the value passed in is undefined + and there is an overload with an optional argument at this position, then + we will choose that overload. If there is no valid overload for the type of + value passed in here, then we throw a TypeError. + The inspection of the value at the distinguishing argument index does not have any side effects; + the only side effects that come from running the overload resolution + algorithm are those that come from converting the ECMAScript values + to IDL values. + + At this point, we have determined which overload to use. We now + convert the remaining arguments, from the distinguishing argument onwards, + again ignoring any additional arguments that were ignored due to being passed + after the last possible argument. + + When converting an optional argument’s ECMAScript value to its equivalent IDL value, + undefined will be converted into + the [=optional argument/default value|optional argument’s default value=], + if it has one, or a special value “missing” otherwise. + + Optional arguments corresponding to a final, variadic argument do not treat + undefined as a special “missing” value, however. + The undefined value is converted to the type + of variadic argument as would be done for a non-optional argument. + +
+ + +

Interfaces

+ +For every [=interface=] that +is [=exposed=] in a given +ECMAScript global environment and: + +* is a [=callback interface=] + that has [=constants=] declared on it, or +* is a non-callback [=interface=] + that is not declared with the [{{NoInterfaceObject}}] + [=extended attribute=], + +a corresponding property must exist on the +ECMAScript environment's global object. +The name of the property is the [=identifier=] of the interface, +and its value is an object called the interface object. + +The property has the attributes { \[[Writable]]: true, \[[Enumerable]]: false, \[[Configurable]]: true }. +The characteristics of an interface object are described in [[#interface-object]]. + +In addition, for every [{{NamedConstructor}}] +extended attribute on an [=exposed=] interface, a corresponding property must +exist on the ECMAScript global object. The name of the property is the +identifier that occurs directly after the +“=”, and its value is an object called a +named constructor, which allows +construction of objects that implement the interface. The property has the +attributes { \[[Writable]]: true, \[[Enumerable]]: false, \[[Configurable]]: true }. +The characteristics of a named constructor are described in +[[#named-constructors]]. + + +

Interface object

+ +The interface object for a given non-callback [=interface=] +is a [=function object=]. +It has properties that correspond to +the [=constants=] and +[=static operations=] +defined on that interface, as described in sections +[[#es-constants]] and +[[#es-operations]]. + +The \[[Prototype]] internal property of +an interface object for a non-callback interface is determined as +follows: + +1. If the interface inherits from some other interface, the value + of \[[Prototype]] is the interface + object for that other interface. +1. If the interface doesn't inherit from any other interface, + the value of \[[Prototype]] is + [=%FunctionPrototype%=]. + +An interface object for a non-callback interface must have a property named “prototype” +with attributes +{ \[[Writable]]: false, \[[Enumerable]]: false, \[[Configurable]]: false } +whose value is an object called the interface prototype object. This object has properties +that correspond to the [=regular attributes=] and +[=regular operations=] defined on the interface, +and is described in more detail in +[[#interface-prototype-object]]. + +Note: Since an interface object for a non-callback interface is a [=function object=] the typeof operator will return +"function" when applied to +such an interface object. + +The internal \[[Prototype]] property +of an interface object for a callback interface must be +the Object.prototype object. + +Note: Remember that interface objects for callback interfaces only exist if they have +[=constants=] declared on them; +when they do exist, they are not [=function objects=]. + + +
Interface object \[[Call]] method
+ +If the [=interface=] is declared with a +[{{Constructor}}] [=extended attribute=], +then the [=interface object=] +can be called as a function to create an object that implements that +interface. Interfaces that do not have a constructor will throw +an exception when called as a function. + +The internal \[[Call]] method +of the interface object behaves as follows, assuming +|arg|0..|n|−1 is the list +of argument values passed to the constructor, and |I| +is the [=interface=]: + +
    + 1. If |I| was not declared with a [{{Constructor}}] + [=extended attribute=], then + throw a TypeError. + 1. Let |id| be the identifier of interface |I|. + 1. Initialize |S| to the + [=effective overload set=] + for constructors with [=identifier=] + |id| on [=interface=] + |I| and with argument count |n|. + 1. Let <|constructor|, |values|> be the result of passing |S| and + |arg|0..|n|−1 to the + [=overload resolution algorithm=]. + 1. Let |R| be the result of performing the actions listed in the description of + |constructor| with |values| as the argument values. + 1. Return the result of [=converted to an ECMAScript value|converting=] + |R| to an ECMAScript interface type value + |I|. +
+ +If the internal \[[Call]] method +of the [=interface object=] +returns normally, then it must +return an object that implements interface |I|. +This object also must be +associated with the ECMAScript global environment associated +with the interface object. + +Interface objects for non-callback interfaces must have a property named “length” +with attributes { \[[Writable]]: false, \[[Enumerable]]: false, \[[Configurable]]: true } +whose value is a Number. +If the [{{Constructor}}] +[=extended attribute=] +does not appear on the interface definition, then the value is 0. +Otherwise, the value is determined as follows: + +
    + 1. Let |id| be the identifier of interface |I|. + 1. Initialize |S| to the + [=effective overload set=] + for constructors with + [=identifier=] + |id| on [=interface=] + |I| and with argument count 0. + 1. Return the length of the shortest argument list of the entries in |S|. +
+ +All interface objects must have a +property named “name” with attributes { \[[Writable]]: false, \[[Enumerable]]: false, \[[Configurable]]: true } +whose value is the identifier of the corresponding interface. + + +
Interface object \[[HasInstance]] method
+ +The internal \[[HasInstance]] method of every +[=interface object=] +|A| must behave as follows, +assuming |V| is the object +argument passed to \[[HasInstance]]: + +
    + 1. If |V| is not an object, return false. + 1. Let |O| be the result of calling the \[[Get]] method of |A| with property name “prototype”. + 1. If |O| is not an object, throw a TypeError exception. + 1. If |V| is a platform object that implements the + interface for which |O| is the [=interface prototype object=], + return true. + 1. Repeat: + 1. Set |V| to the value of the \[[Prototype]] internal property of |V|. + 1. If |V| is null, return false. + 1. If |O| and |V| refer to the same object, + return true. +
+ + +

Named constructors

+ +A [=named constructor=] +that exists due to one or more +[{{NamedConstructor}}] +[=extended attributes=] +with a given [=identifier=] +is a [=function object=]. +It must have a \[[Call]] +internal property, which allows construction of objects that +implement the interface on which the +[{{NamedConstructor}}] +extended attributes appear. It behaves as follows, assuming +|arg|0..|n|−1 is the list +of argument values passed to the constructor, |id| +is the identifier of the constructor specified in the +extended attribute [=takes a named argument list|named argument list=], +and |I| is the [=interface=] +on which the [{{NamedConstructor}}] +extended attribute appears: + +
    + 1. Initialize |S| to the + [=effective overload set=] + for constructors with [=identifier=] + |id| on [=interface=] + |I| and with argument count |n|. + 1. Let <|constructor|, |values|> be the result of passing |S| and + |arg|0..|n|−1 to the + [=overload resolution algorithm=]. + 1. Let |R| be the result of performing the actions listed in the description of + |constructor| with |values| as the argument values. + 1. Return the result of [=converted to an ECMAScript value|converting=] + |R| to an ECMAScript + interface type value + |I|. +
+ +If the internal \[[Call]] method +of the [=named constructor=] +returns normally, then it must +return an object that implements interface |I|. +This object also must be +associated with the ECMAScript global environment associated +with the [=named constructor=]. + +A named constructor must have a property named “length” +with attributes { \[[Writable]]: false, \[[Enumerable]]: false, \[[Configurable]]: true } +whose value is a Number determined as follows: + +
    + 1. Initialize |S| to the + [=effective overload set=] + for constructors with + [=identifier=] + |id| on [=interface=] + |I| and with argument count 0. + 1. Return the length of the shortest argument list of the entries in |S|. +
+ +A named constructor must have a property named “name” +with attributes { \[[Writable]]: false, \[[Enumerable]]: false, \[[Configurable]]: true } +whose value is the identifier used for the named constructor. + +A named constructor must also have a property named +“prototype” with attributes +{ \[[Writable]]: false, \[[Enumerable]]: false, \[[Configurable]]: false } +whose value is the [=interface prototype object=] +for the [=interface=] on which the +[{{NamedConstructor}}] +[=extended attribute=] +appears. + + +

Interface prototype object

+ +There must exist an +[=interface prototype object=] for every non-callback [=interface=] +defined, regardless of whether the interface was declared with the +[{{NoInterfaceObject}}] +[=extended attribute=]. +The interface prototype object for a particular interface has +properties that correspond to the [=regular attributes=] +and [=regular operations=] +defined on that interface. These properties are described in more detail in +sections [[#es-attributes]] and +[[#es-operations]]. + +As with the [=interface object=], +the interface prototype object also has properties that correspond to the +[=constants=] defined on that +interface, described in [[#es-operations]]. + +If the [{{NoInterfaceObject}}] +extended attribute was not specified on the interface, then +the interface prototype object must +also have a property named “constructor” with attributes +{ \[[Writable]]: true, \[[Enumerable]]: false, \[[Configurable]]: true } whose value +is a reference to the interface object for the interface. + +The [=interface prototype object=] +for a given interface |A| must have an internal +\[[Prototype]] property whose value is returned from +the following steps: + +
    + 1. If |A| is declared with the [{{Global}}] + or [{{PrimaryGlobal}}] + [=extended attribute=], and |A| + [=support named properties|supports named properties=], then + return the [=named properties object=] + for |A|, as defined in [[#named-properties-object]]. + 1. Otherwise, if |A| is declared to inherit from another + interface, then return the + [=interface prototype object=] + for the inherited interface. + 1. Otherwise, if |A| is declared with the [{{LegacyArrayClass}}] + extended attribute, then return [=%ArrayPrototype%=]. + 1. Otherwise, return [=%ObjectPrototype%=]. +
+ +
+ + The [=interface prototype object=] + of an [=interface=] that is defined with + the [{{NoInterfaceObject}}] + [=extended attribute=] + will be accessible if the interface is used as a + [=supplemental interfaces|non-supplemental interface=]. + For example, with the following IDL: + +
+        [NoInterfaceObject]
+        interface Foo {
+        };
+        
+        partial interface Window {
+          attribute Foo foo;
+        };
+    
+ + it is not possible to access the interface prototype object through + the [=interface object=] + (since it does not exist as window.Foo). However, an instance + of Foo can expose the interface prototype + object by gettings its internal \[[Prototype]] + property value – Object.getPrototypeOf(window.foo) in + this example. + + If the interface is used solely as a + [=supplemental interface=], + then there will be no way to access its interface prototype object, since no + object will have the interface prototype object as its internal + \[[Prototype]] property value. In such cases, + it is an acceptable optimization for this object not to exist. + +
+ +If the interface or any of its [=consequential interfaces=] +has any [=interface member=] declared with +the [{{Unscopable}}] extended attribute, +then there must be a property on the +interface prototype object whose name is the [=@@unscopables=] symbol +and whose value is an object created as follows: + +
    + 1. Let |object| be a new object created as if by the expression ({}). + 1. For each of the aforementioned [=interface members=] + declared with the [{{Unscopable}}] extended attribute, + call [=CreateDataProperty=](|object|, + the [=identifier=] of the + interface member, true). + 1. Return |object|. +
+ +If the interface is declared with the [{{Global}}] or +[{{PrimaryGlobal}}] [=extended attribute=], or the interface is in the set +of [=inherited interfaces=] for any +other interface that is declared with one of these attributes, then the [=interface prototype object=] +must be an [=immutable prototype exotic object=]. + +The [=class string=] of an +[=interface prototype object=] +is the concatenation of the [=interface=]’s +[=identifier=] and the string +“Prototype”. + + +

Named properties object

+ +For every [=interface=] declared with the +[{{Global}}] or +[{{PrimaryGlobal}}] +[=extended attribute=] +that [=support named properties|supports named properties=], +there must exist an object known as the +named properties object for that +interface. + +The [=named properties object=] +for a given interface |A| must have an internal +\[[Prototype]] property whose value is returned from +the following steps: + +
    + 1. If |A| is declared to inherit from another interface, then return the + [=interface prototype object=] + for the inherited interface. + 1. Otherwise, if |A| is declared with the [{{LegacyArrayClass}}] + extended attribute, then return [=%ArrayPrototype%=]. + 1. Otherwise, return [=%ObjectPrototype%=]. +
+ +The [=class string=] of a +[=named properties object=] +is the concatenation of the [=interface=]’s +[=identifier=] and the string +“Properties”. + + +
Named properties object \[[GetOwnProperty]] method
+ +When the \[[GetOwnProperty]] internal method of a [=named properties object=] +|O| is called with property key |P|, the following steps are +taken: + +
    + 1. Let |A| be the [=interface=] for the + [=named properties object=] |O|. + 1. Let |object| be the sole object from |O|’s ECMAScript global environment that implements |A|. + + Note: For example, if the [=interface=] is the {{Window}} interface, + then the sole object will be this global environment’s window object. + + 1. If the result of running the [=named property visibility algorithm=] with + property name |P| and object |object| is true, then: + 1. Let |operation| be the operation used to declare the named property getter. + + 1. Let |value| be an uninitialized variable. + 1. If |operation| was defined without an [=identifier=], then + set |value| to the result of performing the steps listed in the interface description to + [=determine the value of a named property=] + with |P| as the name. + 1. Otherwise, |operation| was defined with an identifier. Set |value| to the result + of performing the steps listed in the description of |operation| with |P| as the only argument value. + + 1. Let |desc| be a newly created [=Property Descriptor=] with no fields. + 1. Set |desc|.\[[Value]] to the result of [=converted to an ECMAScript value|converting=] + |value| to an ECMAScript value. + 1. If |A| implements an interface with the + [{{LegacyUnenumerableNamedProperties}}] + [=extended attribute=], + then set |desc|.\[[Enumerable]] to false, + otherwise set it to true. + 1. Set |desc|.\[[Writable]] to true and + |desc|.\[[Configurable]] to true. + 1. Return |desc|. + + 1. Return [=OrdinaryGetOwnProperty=](|O|, |P|). +
+ + +
Named properties object \[[DefineOwnProperty]] method
+ +When the \[[DefineOwnProperty]] internal method of a [=named properties object=] is +called, the following steps are taken: + +
    + 1. Return false. +
+ + +
Named properties object \[[Delete]] method
+ +When the \[[Delete]] internal method of a [=named properties object=] is called, the +following steps are taken: + +
    + 1. Return false. +
+ + +
Named properties object \[[SetPrototypeOf]] method
+ +When the \[[SetPrototypeOf]] internal method of a [=named properties object=] is +called, the same algorithm must be executed as is defined for the \[[SetPrototypeOf]] internal method of an +[=immutable prototype exotic object=]. + + +

Constants

+ +For each [=exposed=] +[=constant=] defined on +an [=interface=] |A|, there +must be a corresponding property. +The property has the following characteristics: + +* The name of the property is the [=identifier=] of the [=constant=]. +* The location of the property is determined as follows: + * If the interface was declared with the [{{Global}}] or [{{PrimaryGlobal}}] extended attribute, + then the property exists on the single object that implements the interface. + * Otherwise, if the interface is a [=consequential interface=] + of a [{{Global}}]- or [{{PrimaryGlobal}}] annotated interface, then + the property exists on the single object that implements the [{{Global}}]- or + [{{PrimaryGlobal}}]-annotated interface as well as on + the consequential interface’s [=interface prototype object=]. + * Otherwise, the property exists solely on the interface’s [=interface prototype object=]. +* The value of the property is that which is obtained by [=converted to an ECMAScript value|converting=] the [=constant=]’s IDL value to an ECMAScript value. +* The property has attributes { \[[Writable]]: false, \[[Enumerable]]: true, \[[Configurable]]: false }. + +In addition, a property with the same characteristics must +exist on the [=interface object=], if +that object exists. + + +

Attributes

+ +For each [=exposed=] +[=attribute=] of the +[=interface=], whether it +was declared on the interface itself or one of its +[=consequential interfaces=], +there must exist a corresponding property. +The characteristics of this property are as follows: + +* The name of the property is the [=identifier=] of the [=attribute=]. +* The location of the property is determined as follows: + * If the attribute is a [=static attribute=], + then there is a single corresponding property and it exists on the interface’s [=interface object=]. + * Otherwise, if the attribute is [=unforgeable=] on + the interface or if the interface was declared with the [{{Global}}] or [{{PrimaryGlobal}}] extended attribute, + then the property exists on every object that implements the interface. + * Otherwise, if the interface is a [=consequential interface=] + of a [{{Global}}]- or [{{PrimaryGlobal}}]-annotated interface, then + the property exists on the single object that implements the [{{Global}}]- or + [{{PrimaryGlobal}}]-annotated interface as well as on + the consequential interface’s [=interface prototype object=]. + * Otherwise, the property exists solely on the interface’s [=interface prototype object=]. +* The property has attributes { \[[Get]]: |G|, \[[Set]]: |S|, \[[Enumerable]]: true, \[[Configurable]]: |configurable| }, + where: + * |configurable| is false if the attribute was + declared with the [{{Unforgeable}}] extended attribute and true otherwise; + * |G| is the [=attribute getter=], defined below; and + * |S| is the [=attribute setter=], also defined below. +* The attribute getter is a Function + object whose behavior when invoked is as follows: +
    + 1. Let |idlValue| be an IDL value determined as follows. + 1. If the [=attribute=] is a [=regular attribute=], then: + 1. Let |I| be the [=interface=] + whose [=interface prototype object=] + this property corresponding to the attribute appears on. + + Note: This means that even if an implements statement was used to make + an attribute available on the interface, |I| is the interface + on the left hand side of the implements statement, and not the one + that the attribute was originally declared on. + + 1. Let |O| be the this value. + 1. If |O| is a [=platform object=], + then [=perform a security check=], passing: + * the platform object |O|, + * the ECMAScript global environment associated with this Function that + implements the [=attribute getter=], + * the [=identifier=] of the [=attribute=], and + * the type “getter”. + 1. If |O| is not a [=platform object=] that implements |I|, then: + 1. If the [=attribute=] was specified with the + [{{LenientThis}}] [=extended attribute=], + then return undefined. + 1. Otherwise, throw a TypeError. + 1. Set |idlValue| to be the result of performing the actions listed in the description of the attribute that occur when getting + (or those listed in the description of the inherited attribute, if this attribute is declared to + [=inherit its getter=]), + with |O| as the object. + 1. Otherwise, the attribute is a [=static attribute=]. + Set |idlValue| to be the result of performing the actions listed in the description of the attribute that occur when getting. + 1. Let |V| be the result of [=converted to an ECMAScript value|converting=] + |idlValue| to an ECMAScript value. + 1. Return |V|. +
+ + The value of the Function object’s “length” + property is the Number value 0. + + The value of the Function object’s “name” + property is a String whose value is the + concatenation of “get ” and the identifier of the attribute. + +* The attribute setter is undefined + if the attribute is declared readonly and does not have a + [{{LenientThis}}], [{{PutForwards}}] or + [{{Replaceable}}] + [=extended attribute=] declared on it. + Otherwise, it is a Function object whose behavior when invoked is as follows: +
    + 1. If no arguments were passed to the Function, then + throw a TypeError. + 1. Let |V| be the value of the first argument passed to the Function. + 1. If the [=attribute=] is a [=regular attribute=], then: + 1. Let |I| be the [=interface=] + whose [=interface prototype object=] + this property corresponding to the attribute appears on. + 1. Let |O| be the this value. + 1. If |O| is a [=platform object=], + then [=perform a security check=], passing: + * the platform object |O|, + * the ECMAScript global environment associated with this Function that + implements the [=attribute setter=], + * the [=identifier=] of the [=attribute=], and + * the type “setter”. + 1. Let |validThis| be true if |O| is a + [=platform object=] that implements |I|, or + false otherwise. + 1. If |validThis| is false and the + [=attribute=] was not specified with the + [{{LenientThis}}] [=extended attribute=], + then throw a TypeError. + 1. If the attribute is declared with a [{{Replaceable}}] + extended attribute, then: + 1. Let |P| be the identifier of the attribute. + 1. Call [=CreateDataProperty=](|O|, |P|, |V|). + 1. Return undefined. + 1. If |validThis| is false, then return undefined. + 1. If the attribute is declared with a [{{LenientSetter}}] + extended attribute, then return undefined. + 1. If the attribute is declared with a [{{PutForwards}}] + extended attribute, then: + 1. Let |Q| be the result of calling the \[[Get]] method + on |O| using the identifier of the attribute as the property name. + 1. If |Q| is not an object, then throw a TypeError. + 1. Let |A| be the attribute identified by the [{{PutForwards}}] extended attribute. + 1. Call the \[[Put]] method on |Q| + using the identifier of |A| as the property name and |V| as the value. + 1. Return undefined. + 1. Let |idlValue| be an IDL value determined as follows: + * If the type of the attribute is an [=enumeration=], then: + 1. Let |S| be the result of calling [=ToString=](|V|). + 1. If |S| is not one of the [=enumeration values|enumeration’s values=], then return undefined. + 1. The value of |idlValue| is the enumeration value equal to |S|. + * Otherwise, the type of the attribute is not an [=enumeration=]. + The value of |idlValue| is the result of [=converted to an IDL value|converting=] + |V| to an IDL value. + 1. If the attribute is a regular attribute, then perform the actions listed in the description of the attribute that occur when setting, + with |O| as the object and |idlValue| as the value. + 1. Otherwise, the attribute is a [=static attribute=]. + Perform the actions listed in the description of the attribute that occur when setting with |idlValue| as the value. + 1. Return undefined. +
+ + The value of the Function object’s “length” + property is the Number value 1. + + The value of the Function object’s “name” + property is a String whose value is the + concatenation of “set ” and the identifier of the attribute. + +Note: Although there is only a single property for an IDL attribute, since +accessor property getters and setters are passed a this +value for the object on which property corresponding to the IDL attribute is +accessed, they are able to expose instance-specific data. + +Note: Note that attempting to assign to a property corresponding to a +[=read only=] [=attribute=] +results in different behavior depending on whether the script doing so is in strict mode. +When in strict mode, such an assignment will result in a TypeError +being thrown. When not in strict mode, the assignment attempt will be ignored. + + +

Operations

+ +For each unique [=identifier=] +of an [=exposed=] [=operation=] +defined on the [=interface=], there +must exist a corresponding property, +unless the [=effective overload set=] +for that [=identifier=] and [=operation=] +and with an argument count of 0 has no entries. + +The characteristics of this property are as follows: + +* The name of the property is the [=identifier=]. +* The location of the property is determined as follows: + * If the operation is [=static operations|static=], then + the property exists on the [=interface object=]. + * Otherwise, if the operation is [=unforgeable=] on + the interface or if the interface was declared with the [{{Global}}] or [{{PrimaryGlobal}}] extended attribute, + then the property exists on every object that implements the interface. + * Otherwise, if the interface is a [=consequential interface=] + of a [{{Global}}]- or [{{PrimaryGlobal}}]-annotated interface, then + the property exists on the single object that implements the [{{Global}}]- or + [{{PrimaryGlobal}}]-annotated interface as well as on + the consequential interface’s [=interface prototype object=]. + * Otherwise, the property exists solely on the interface’s [=interface prototype object=]. +* The property has attributes + { \[[Writable]]: |B|, \[[Enumerable]]: true, \[[Configurable]]: |B| }, + where |B| is false if the operation is + [=unforgeable=] on the interface, + and true otherwise. +* The value of the property is a Function object whose + behavior is as follows, + assuming |id| is the + [=identifier=], + |arg|0..|n|−1 is the list + of argument values passed to the function: +
    + 1. Try running the following steps: + 1. Let |I| be the [=interface=] + whose [=interface prototype object=] + (or [=interface object=], for a static + operation) this property corresponding to the operation appears on. + + Note: This means that even if an implements statement was used to make + an operation available on the interface, |I| is the interface + on the left hand side of the implements statement, and not the one + that the operation was originally declared on. + + 1. Let |O| be a value determined as follows: + * If the operation is a static operation, then |O| is null. + * Otherwise, if the [=interface=] on which the + [=operation=] appears has an + [{{ImplicitThis}}] [=extended attribute=], + and the this value is null + or undefined, then |O| is + the ECMAScript global object associated with the Function object. + * Otherwise, if the this value is not null, + then |O| is the this value. + * Otherwise, throw a TypeError. + 1. If |O| is a [=platform object=], + then [=perform a security check=], passing: + * the platform object |O|, + * the ECMAScript global environment associated with this Function that + implements the [=operation=], + * the [=identifier=] of the [=operation=], and + * the type “method”. + 1. If |O| is not null and is also not a [=platform object=] + that implements interface |I|, throw a TypeError. + 1. Initialize |S| to the + [=effective overload set=] + for [=regular operations=] + (if the operation is a regular operation) or for + [=static operations=] + (if the operation is a static operation) with + [=identifier=] + |id| on [=interface=] + |I| and with argument count |n|. + 1. Let <|operation|, |values|> be the result of passing |S| and + |arg|0..|n|−1 to the + [=overload resolution algorithm=]. + 1. Let |R| be the result of performing (on |O|, if the operation + is not a static operation) the actions listed in the description of + |operation| with |values| as the argument values. + 1. Return the result of [=converted to an ECMAScript value|converting=] + |R| to an ECMAScript value of + the type |op| is declared to return. + + And then, if an exception was thrown: + + 1. If the operation has a [=return type=] + that is a promise type, then: + 1. Let |reject| be the initial value of [=%Promise%=].reject. + 1. Return the result of calling |reject| with [=%Promise%=] as the + this object and the exception as the single + argument value. + 1. Otherwise, end these steps and allow the exception to propagate. +
+* The value of the Function object’s “length” + property is a Number determined as follows: +
    + 1. Let |S| be the + [=effective overload set=] + for [=regular operations=] + (if the operation is a regular operation) or for + [=static operations=] + (if the operation is a static operation) with + [=identifier=] + |id| on [=interface=] + |I| and with argument count 0. + 1. Return the length of the shortest argument list of the entries in |S|. +
+* The value of the Function object’s “name” + property is a String whose value is the + identifier of the operation. + +We also define creating an operation function, given an [=operation=] +|op|, a [=namespace=] +|namespace|, and a [=Realm=] |realm|: + +Note: The astute reader may notice that what follows is very similar to the +above algorithm for operations on interfaces. It is currently only used for namespaces, +but we have near-future plans to generalize it slightly and then replace the above +definition so that this algorithm is useful both for interfaces and namespaces. + +1. Let |id| be |op|'s [=identifier=]. + +1. Let |steps| be the following series of steps, given function argument + values |arg|0..|n|−1: + + 1. Try running the following steps: + 1. Let |S| be the [=effective overload set=] for [=regular operations=] with + [=identifier=] |id| on + [=namespace=] |namespace| + and with argument count |n|. + + 1. Let <|operation|, |values|> be the result of passing + |S| and |arg|0..|n|−1 to the [=overload resolution algorithm=]. + + 1. Let |R| be the result of performing the actions listed in the + description of |operation| with |values| as the argument + values. + + 1. Return the result of [=converted to an ECMAScript value|converting=] |R| to + an ECMAScript value of the type |op| is declared to return. + + And then, if an exception was thrown: + + 1. If the operation has a [=return type=] + that is a promise type, then: + + 1. Let |reject| be the initial value of [=%Promise%=].reject. + 1. Return the result of calling |reject| with [=%Promise%=] as the this object + and the exception as the single argument value. + 1. Otherwise, end these steps and allow the exception to propagate. + +1. Let |F| be [=!=] [=CreateBuiltinFunction=](|realm|, + |steps|, the [=%FunctionPrototype%=] of |realm|). + +1. Perform [=!=] [=SetFunctionName=](|F|, |id|). + +1. Let |S| be the [=effective overload set=] for [=regular operations=] with [=identifier=] |id| on [=namespace=] |namespace| and with argument count 0. + +1. Let |length| be the length of the shortest argument list in the entries in + |S|. + +1. Perform [=!=] [=DefinePropertyOrThrow=](|F|, "length", + PropertyDescriptor{\[[Value]]: |length|, + \[[Writable]]: false, \[[Enumerable]]: false, \[[Configurable]]: true}). + + +
Stringifiers
+ +If the [=interface=] +has an [=exposed=] +[=stringifier=], then +there must exist a property with +the following characteristics: + +* The name of the property is “toString”. +* If the [=stringifier=] is + [=unforgeable=] on the interface + or if the interface was declared with the [{{Global}}] or [{{PrimaryGlobal}}] extended attribute, + then the property exists on every object that implements the interface. + Otherwise, the property exists on the [=interface prototype object=]. +* The property has attributes { \[[Writable]]: |B|, \[[Enumerable]]: true, \[[Configurable]]: |B| }, + where |B| is false if the stringifier is + [=unforgeable=] on the interface, + and true otherwise. +* The value of the property is a Function object, which behaves as follows: + +
    + 1. Let |O| be the result of calling [=ToObject=] on the this value. + 1. If |O| is a [=platform object=], + then [=perform a security check=], passing: + * the platform object |O|, + * the ECMAScript global environment associated with this Function that + implements the [=stringifier=], + * the [=identifier=] of the [=stringifier=], and + * the type “method”. + 1. If |O| is not an object that implements the [=interface=] + on which the stringifier was declared, then throw a TypeError. + 1. Let |V| be an uninitialized variable. + 1. Depending on where stringifier was specified: +
    + : on an [=attribute=] + :: Set |V| to the result of performing the actions listed in the description of the attribute that occur when getting + (or those listed in the description of the inherited attribute, if this attribute is declared to + [=inherit its getter=]), + with |O| as the object. + : on an [=operation=] with an identifier + :: Set |V| to the result of performing the actions listed in the description + of the operation, using |O| as the this value + and passing no arguments. + : on an [=operation=] with no identifier + :: Set |V| to the result of performing the [=stringification behavior=] + of the interface. +
    + 1. Return the result of [=converted to an ECMAScript value|converting=] |V| to a String value. +
+* The value of the Function object’s “length” + property is the Number value 0. +* The value of the Function object’s “name” + property is the String value “toString”. + + +
Serializers
+ +If the [=interface=] +has an [=exposed=] +[=serializer=], then +a property must exist +whose name is “toJSON”, +with attributes { \[[Writable]]: true, \[[Enumerable]]: true, \[[Configurable]]: true } +and whose value is a +Function object. + +The location of the property is determined as follows: + +* If the interface was declared with the [{{Global}}] or [{{PrimaryGlobal}}] extended attribute, + then the property exists on the single object that implements the interface. +* Otherwise, if the interface is a [=consequential interface=] + of a [{{Global}}]- or [{{PrimaryGlobal}}]-annotated interface, then + the property exists on the single object that implements the [{{Global}}]- or + [{{PrimaryGlobal}}]-annotated interface as well as on + the consequential interface’s [=interface prototype object=]. +* Otherwise, the property exists solely on the interface’s [=interface prototype object=]. + +The property’s Function object, when invoked, +must behave as follows: + +
    + 1. Let |O| be the result of calling [=ToObject=] on the this value. + 1. If |O| is a [=platform object=], + then [=perform a security check=], passing: + * the platform object |O|, + * the ECMAScript global environment associated with this Function that + implements the [=serializer=], + * the [=identifier=] of the [=serializer=], and + * the type “method”. + 1. If |O| is not an object that implements the [=interface=] + on which the serializer was declared, then throw a TypeError. + 1. Depending on how serializer was specified: +
    + : on an [=operation=] with an identifier + ::
      + 1. Return the result of performing the actions listed in the description of the + operation, using |O| as the this value + and passing no arguments. +
    + : as a keyword, either with or without a [=serialization pattern=] + ::
      + 1. Let |S| be the [=serialized value=] that is the result of invoking the [=serialization behavior=] of the + [=interface=] for object |O|. + 1. Return the result of [=convert a serialized value to an ECMAScript value|converting=] + |S| to an ECMAScript value. +
    +
    +
+ +The value of the Function object’s “length” +property is the Number value 0. + +The value of the Function object’s “name” +property is the String value “toJSON”. + +The following steps define how to convert a serialized value to an ECMAScript value: + +
    + 1. Let |S| be the [=serialized value=]. + 1. Depending on the type of |S|: +
    + : a map + ::
      + 1. Let |O| be a new object created as if by the expression ({}). + 1. For each entry in |S|, in the order they were added to the map: + 1. Let |V| be the result of [=convert a serialized value to an ECMAScript value|converting=] + the value of the entry to an ECMAScript value. + 1. Let |P| be the entry’s key. + 1. Call [=CreateDataProperty=](|O|, |P|, |V|). + 1. Return |O|. +
    + : a list + ::
      + 1. Let |A| be a new Array object created as if by the expression []. + 1. Let |index| be 0. + 1. While |index| is less than the number of elements in |S|: + 1. Let |V| be the result of [=convert a serialized value to an ECMAScript value|converting=] + the value of the element in |S| at index |index| to an ECMAScript value. + 1. Let |P| be [=ToString=](|index|). + 1. Call [=CreateDataProperty=](|O|, |P|, |V|). + 1. Return |A|. +
    + : any other serialized value + ::
      + 1. Let |V| be the result of [=converted to an ECMAScript value|converting=] + |S| to an ECMAScript value. + 1. Return |V|. +
    +
    +
+ + +

Common iterator behavior

+ + +
@@iterator
+ +If the [=interface=] +has any of the following: + +* an [=iterable declaration=] +* an [=indexed property getter=] + and an [=integer types|integer-typed=] + [=attribute=] named + “length” +* a [=maplike declaration=] +* a [=setlike declaration=] + +then a property must exist +whose name is the [=@@iterator=] symbol, +with attributes { \[[Writable]]: true, \[[Enumerable]]: false, \[[Configurable]]: true } +and whose value is a [=function object=]. + +The location of the property is determined as follows: + +* If the interface was declared with the [{{Global}}] or [{{PrimaryGlobal}}] extended attribute, + then the property exists on the single object that implements the interface. +* Otherwise, if the interface is a [=consequential interface=] + of a [{{Global}}]- or [{{PrimaryGlobal}}]-annotated interface, then + the property exists on the single object that implements the [{{Global}}]- or + [{{PrimaryGlobal}}]-annotated interface as well as on + the consequential interface’s [=interface prototype object=]. +* Otherwise, the property exists solely on the interface’s [=interface prototype object=]. + +If the interface defines an [=indexed property getter=], +then the Function object is [=%ArrayProto_values%=]. + +If the interface has a [=pair iterator=], +then the Function, when invoked, +must behave as follows: + +
    + 1. Let |object| be the result of calling [=ToObject=] on the this value. + 1. If |object| is a [=platform object=], + then [=perform a security check=], passing: + * the platform object |object|, + * the ECMAScript global environment associated with this Function, + * the identifier “@@iterator”, and + * the type “method”. + 1. Let |interface| be the [=interface=] + the [=iterable declaration=] is on. + 1. If |object| is not a [=platform object=] + that implements |interface|, + then throw a TypeError. + 1. Let |iterator| be a newly created [=default iterator object=] + for |interface| with |object| as its target and iterator kind “key+value”. + 1. Return |iterator|. +
+ +If the interface has a [=maplike declaration=] +or [=setlike declaration=], +then the Function object that is the value of the [=@@iterator=] property, +when invoked, must behave as follows: + +
    + 1. Let |object| be the result of calling [=ToObject=] on the this value. + 1. If |object| is a [=platform object=], + then [=perform a security check=], passing: + * the platform object |object|, + * the ECMAScript global environment associated with this Function, + * the identifier “@@iterator”, and + * the type “method”. + 1. If |object| is not a [=platform object=] + that implements the [=interface=] + on which the [=maplike declaration=] + or [=setlike declaration=] is defined, + then throw a TypeError. + 1. If the interface has a [=maplike declaration=], then: + 1. Let |backing| be the value of the \[[BackingMap]] [=internal slot=] of |object|. + 1. Return [=CreateMapIterator=](|backing|, "key+value"). + 1. Otherwise: + 1. Let |backing| be the value of the \[[BackingSet]] [=internal slot=] of |object|. + 1. Return [=CreateSetIterator=](|backing|, "value"). +
+ +The value of the [=@@iterator=] Function object’s “length” +property is the Number value 0. + +The value of the [=@@iterator=] Function object’s “name” +property is the String value “entries” if the interface has a +[=pair iterator=] or a +[=maplike declaration=] and the String “values” +if the interface has a +[=setlike declaration=]. + + +
forEach
+ +If the [=interface=] +has any of the following: + +* an [=iterable declaration=] +* a [=maplike declaration=] +* a [=setlike declaration=] + +then a property named “forEach” must exist +with attributes { \[[Writable]]: true, \[[Enumerable]]: true, \[[Configurable]]: true } +and whose value is a [=function object=]. + +The location of the property is determined as follows: + +* If the interface was declared with the [{{Global}}] or [{{PrimaryGlobal}}] extended attribute, + then the property exists on the single object that implements the interface. +* Otherwise, if the interface is a [=consequential interface=] + of a [{{Global}}]- or [{{PrimaryGlobal}}]-annotated interface, then + the property exists on the single object that implements the [{{Global}}]- or + [{{PrimaryGlobal}}]-annotated interface as well as on + the consequential interface’s [=interface prototype object=]. +* Otherwise, the property exists solely on the interface’s [=interface prototype object=]. + +If the interface defines an [=indexed property getter=], +then the Function object is +the initial value of the “forEach” data property of [=%ArrayPrototype%=]. + +If the interface has a [=pair iterator=], +then the Function must +have the same behavior as one that would exist assuming the interface had +this [=operation=] instead of the +[=iterable declaration=]: + +
+      interface Iterable {
+        void forEach(Function callback, optional any thisArg);
+      };
+
+ +with the following prose definition: + +
    + 1. Let |O| be the this value. + 1. Let |pairs| be the list of [=value pairs to iterate over=]. + 1. Let |i| be 0. + 1. While |i| is less than the length of |pairs|: + 1. Let |pair| be the entry in |pairs| at index |i|. + 1. Let |key| be |pair|’s key. + 1. Let |value| be |pair|’s value. + 1. Invoke |callback| with |thisArg| + (or undefined, if the argument was not supplied) + as the [=callback this value|callback this value=] and + |value|, |key| and |O| as its arguments. + 1. Update |pairs| to the current list of [=value pairs to iterate over=]. + 1. Set |i| to |i| + 1. +
+ +If the interface has a [=maplike declaration=] +or [=setlike declaration=] +then the Function, when invoked, +must behave as follows: + +
    + 1. Let |object| be the result of calling [=ToObject=] on the this value. + 1. If |object| is a [=platform object=], + then [=perform a security check=], passing: + * the platform object |object|, + * the ECMAScript global environment associated with this Function, + * the identifier “forEach”, and + * the type “method”. + 1. Let |interface| be the [=interface=] + on which the [=maplike declaration=] + or [=setlike declaration=] is declared. + 1. If |object| is not a [=platform object=] + that implements |interface|, + then throw a TypeError. + 1. Let |callbackFn| be the value of the first argument passed to the function, or undefined if the argument was not supplied. + 1. If [=IsCallable=](|callbackFn|) is false, throw a TypeError. + 1. Let |thisArg| be the value of the second argument passed to the function, or undefined if the argument was not supplied. + 1. Let |backing| be the value of the \[[BackingMap]] [=internal slot=] of |object|, + if the interface has a [=maplike declaration=], + or the \[[BackingSet]] [=internal slot=] of |object| otherwise. + 1. Let |callbackWrapper| be a Function that, when invoked, behaves as follows: + 1. Let |v| and |k| be the first two arguments passed to the function. + 1. Let |thisArg| be the this value. + 1. Call the \[[Call]] internal method of |callbackFn| with |thisArg| as |thisArgument| + and |v|, |k| and |object| as |argumentsList|. + + Note: The |callbackWrapper| function simply calls the incoming |callbackFn| + with |object| as the third argument rather than its internal \[[BackingMap]] or \[[BackingSet]] object. + +

    + Can the script author observe that |callbackWrapper| might be a new function + every time forEach is called? What's the best way of specifying that there's only + one function that has captured an environment? +

    + 1. Let |forEach| be the result of calling the \[[Get]] internal method of + |backing| with “forEach” and |backing| as arguments. + 1. If [=IsCallable=](|forEach|) is false, throw a TypeError. + 1. Call the \[[Call]] internal method of |forEach| with |backing| as |thisArgument| + and |callbackWrapper| and |thisArg| as |argumentsList|. + 1. Return undefined. +
+ +The value of the Function object’s “length” +property is the Number value 1. + +The value of the Function object’s “name” +property is the String value “forEach”. + + +

Iterable declarations

+ + +
entries
+ +If the [=interface=] has an +[=iterable declaration=], +then a property named “entries” must exist +with attributes { \[[Writable]]: true, \[[Enumerable]]: true, \[[Configurable]]: true } +and whose value is a [=function object=]. + +The location of the property is determined as follows: + +* If the interface was declared with the [{{Global}}] or [{{PrimaryGlobal}}] extended attribute, + then the property exists on the single object that implements the interface. +* Otherwise, if the interface is a [=consequential interface=] + of a [{{Global}}]- or [{{PrimaryGlobal}}]-annotated interface, then + the property exists on the single object that implements the [{{Global}}]- or + [{{PrimaryGlobal}}]-annotated interface as well as on + the consequential interface’s [=interface prototype object=]. +* Otherwise, the property exists solely on the interface’s [=interface prototype object=]. + +If the interface has a [=value iterator=], +then the Function object is +the initial value of the “entries” data property of [=%ArrayPrototype%=]. + +If the interface has a [=pair iterator=], +then the Function object is +the value of the [=@@iterator=] property. + + +
keys
+ +If the [=interface=] has an +[=iterable declaration=], +then a property named “keys” must exist +with attributes { \[[Writable]]: true, \[[Enumerable]]: true, \[[Configurable]]: true } +and whose value is a [=function object=]. + +The location of the property is determined as follows: + +* If the interface was declared with the [{{Global}}] or [{{PrimaryGlobal}}] extended attribute, + then the property exists on the single object that implements the interface. +* Otherwise, if the interface is a [=consequential interface=] + of a [{{Global}}]- or [{{PrimaryGlobal}}]-annotated interface, then + the property exists on the single object that implements the [{{Global}}]- or + [{{PrimaryGlobal}}]-annotated interface as well as on + the consequential interface’s [=interface prototype object=]. +* Otherwise, the property exists solely on the interface’s [=interface prototype object=]. + +If the interface has a [=value iterator=], +then the Function object is +the initial value of the “keys” data property of [=%ArrayPrototype%=]. + +If the interface has a [=pair iterator=], +then the Function, when invoked, must behave as follows: + +
    + 1. Let |object| be the result of calling [=ToObject=] on the this value. + 1. If |object| is a [=platform object=], + then [=perform a security check=], passing: + * the platform object |object|, + * the ECMAScript global environment associated with this Function, + * the identifier “keys”, and + * the type “method”. + 1. Let |interface| be the [=interface=] + on which the [=iterable declaration=] is declared on. + 1. If |object| is not a [=platform object=] + that implements |interface|, + then throw a TypeError. + 1. Let |iterator| be a newly created [=default iterator object=] + for |interface| with |object| as its target and iterator kind “key”. + 1. Return |iterator|. +
+ +The value of the Function object’s “length” property is the Number value 0. + +The value of the Function object’s “name” property is the String value “keys”. + + +
values
+ +If the [=interface=] has an +[=iterable declaration=], +then a property named “values” must exist +with attributes { \[[Writable]]: true, \[[Enumerable]]: true, \[[Configurable]]: true } +and whose value is a [=function object=]. + +The location of the property is determined as follows: + +* If the interface was declared with the [{{Global}}] or [{{PrimaryGlobal}}] extended attribute, + then the property exists on the single object that implements the interface. +* Otherwise, if the interface is a [=consequential interface=] + of a [{{Global}}]- or [{{PrimaryGlobal}}]-annotated interface, then + the property exists on the single object that implements the [{{Global}}]- or + [{{PrimaryGlobal}}]-annotated interface as well as on + the consequential interface’s [=interface prototype object=]. +* Otherwise, the property exists solely on the interface’s [=interface prototype object=]. + +If the interface has a [=value iterator=], +then the Function object is +the value of the [=@@iterator=] property. + +If the interface has a [=pair iterator=], +then the Function, when invoked, must behave as follows: + +
    + 1. Let |object| be the result of calling [=ToObject=] on the this value. + 1. If |object| is a [=platform object=], + then [=perform a security check=], passing: + * the platform object |object|, + * the ECMAScript global environment associated with this Function, + * the identifier “entries”, and + * the type “method”. + 1. Let |interface| be the [=interface=] + on which the [=iterable declaration=] is declared on. + 1. If |object| is not a [=platform object=] + that implements |interface|, + then throw a TypeError. + 1. Let |iterator| be a newly created [=default iterator object=] + for |interface| with |object| as its target and iterator kind “value”. + 1. Return |iterator|. +
+ +The value of the Function object’s “length” property is the Number value 0. + +The value of the Function object’s “name” property is the String value “values”. + + +
Default iterator objects
+ +A default iterator object for a given +[=interface=], target and iteration kind +is an object whose internal \[[Prototype]] property is the +[=iterator prototype object=] +for the [=interface=]. + +A [=default iterator object=] +has three internal values: + +1. its target, which is an object whose values are to be iterated, +1. its kind, which is the iteration kind, +1. its index, which is the current index into the values value to be iterated. + +Note: Default iterator objects are only used for [=pair iterators=]; +[=value iterators=], as they are currently +restricted to iterating over an object’s +[=support indexed properties|supported indexed properties=], +use standard ECMAScript Array iterator objects. + +When a [=default iterator object=] is first created, +its index is set to 0. + +The [=class string=] of a +[=default iterator object=] +for a given [=interface=] +is the result of concatenting the [=identifier=] +of the [=interface=] and +the string “ Iterator”. + + +
Iterator prototype object
+ +The iterator prototype object +for a given [=interface=] +is an object that exists for every interface that has a +[=pair iterator=]. It serves as the +prototype for [=default iterator objects=] +for the interface. + +The internal \[[Prototype]] property of an [=iterator prototype object=] +must be [=%IteratorPrototype%=]. + +An [=iterator prototype object=] +must have a property named “next” with +attributes { \[[Writable]]: true, \[[Enumerable]]: true, \[[Configurable]]: true } +and whose value is a [=function object=] +that behaves as follows: + +
    + 1. Let |interface| be the [=interface=] for which the + [=iterator prototype object=] exists. + 1. Let |object| be the result of calling [=ToObject=] on the this value. + 1. If |object| is a [=platform object=], + then [=perform a security check=], passing: + * the platform object |object|, + * the ECMAScript global environment associated with this Function, + * the identifier “next”, and + * the type “method”. + 1. If |object| is not a [=default iterator object=] for |interface|, + then throw a TypeError. + 1. Let |target| be |object|’s target. + 1. Let |index| be |object|’s index. + 1. Let |kind| be |object|’s kind. + 1. Let |values| be the list of [=value pairs to iterate over=]. + 1. Let |len| be the length of |values|. + 1. If |object|’s index is greater than or equal to |len|, then + return [=CreateIterResultObject=](undefined, true). + 1. Let |pair| be the entry in |values| at index |index|. + 1. Let |result| be a value determined by the value of |kind|: +
    + : key + ::
      + 1. Let |idlKey| be |pair|’s key. + 1. Let |key| be the result of [=converted to an ECMAScript value|converting=] |idlKey| to an ECMAScript value. + 1. |result| is |key|. +
    + : value + ::
      + 1. Let |idlValue| be |pair|’s value. + 1. Let |value| be the result of [=converted to an ECMAScript value|converting=] |idlValue| to an ECMAScript value. + 1. |result| is |value|. +
    + : key+value + ::
      + 1. Let |idlKey| be |pair|’s key. + 1. Let |idlValue| be |pair|’s value. + 1. Let |key| be the result of [=converted to an ECMAScript value|converting=] |idlKey| to an ECMAScript value. + 1. Let |value| be the result of [=converted to an ECMAScript value|converting=] |idlValue| to an ECMAScript value. + 1. Let |array| be the result of performing [=ArrayCreate=](2). + 1. Call [=CreateDataProperty=](|array|, "0", |key|). + 1. Call [=CreateDataProperty=](|array|, "1", |value|). + 1. |result| is |array|. +
    +
    + 1. Return [=CreateIterResultObject=](|result|, false). +
+ +The [=class string=] of an +[=iterator prototype object=] +for a given [=interface=] +is the result of concatenting the [=identifier=] +of the [=interface=] and +the string “Iterator”. + + +

Maplike declarations

+ +Any object that implements an [=interface=] +that has a [=maplike declaration=] +must have a \[[BackingMap]] [=internal slot=], which is +initially set to a newly created Map object. +This Map object’s \[[MapData]] internal slot is +the object’s [=map entries=]. + +If an [=interface=] |A| is declared with +a [=maplike declaration=], then +there exists a number of additional properties on |A|’s +[=interface prototype object=]. +These additional properties are described in the sub-sections below. + +Some of the properties below are defined to have a [=function object=] value +that forwards to the internal map object +for a given function name. Such functions behave as follows when invoked: + +
    + 1. Let |O| be the this value. + 1. Let |arguments| be the list of arguments passed to this function. + 1. Let |name| be the function name. + 1. If |O| is a [=platform object=], + then [=perform a security check=], passing: + * the platform object |O|, + * the ECMAScript global environment associated with this Function, + * an identifier equal to |name|, and + * the type “method”. + 1. If |O| is not an object that implements |A|, then throw a TypeError. + 1. Let |map| be the Map object that is the value of |O|’s \[[BackingMap]] [=internal slot=]. + 1. Let |function| be the result of calling the \[[Get]] internal method of |map| passing |name| and |map| as arguments. + 1. If [=IsCallable=](|function|) is false, then throw a TypeError. + 1. Return the result of calling the \[[Call]] internal method of |function| with |map| as |thisArg| and |arguments| as |argumentsList|. +
+ + +
size
+ +There must exist a property named “size” on +|A|’s [=interface prototype object=] +with the following characteristics: + +* The property has attributes { \[[Get]]: |G|, \[[Enumerable]]: false, \[[Configurable]]: true }, + where |G| is the interface’s map size getter, + defined below. +* The [=map size getter=] is + a Function object whose + behavior when invoked is as follows: + +
    + 1. Let |O| be the this value. + 1. If |O| is a [=platform object=], + then [=perform a security check=], passing: + * the platform object |O|, + * the ECMAScript global environment associated with this Function, + * the identifier “size”, and + * the type “getter”. + 1. If |O| is not an object that implements |A|, then throw a TypeError. + 1. Let |map| be the Map object that is the value of |O|’s \[[BackingMap]] [=internal slot=]. + 1. Return the result of calling the \[[Get]] internal method of |map| passing “size” and |map| as arguments. +
+ + The value of the Function object’s “length” property is the Number value 0. + + The value of the Function object’s “name” property is the String value “size”. + + +
entries
+ +A property named “entries” must exist on +|A|’s [=interface prototype object=] +with attributes { \[[Writable]]: true, \[[Enumerable]]: false, \[[Configurable]]: true } +and whose value is the [=function object=] that is the value of +the [=@@iterator=] property. + + +
keys and values
+ +For both of “keys” and “values”, there must exist a property with that name on +|A|’s [=interface prototype object=] +with the following characteristics: + +* The property has attributes { \[[Writable]]: true, \[[Enumerable]]: false, \[[Configurable]]: true }. +* The value of the property is a Function object that [=forwards to the internal map object|forwards that name to the internal map object=]. + +The value of the Function objects’ “length” properties is the Number value 0. + +The value of the Function object’s “name” property is the String value “keys” or “values”, correspondingly. + + +
get and has
+ +For both of “get” and “has”, there must exist a property with that name on +|A|’s [=interface prototype object=] +with the following characteristics: + +* The property has attributes { \[[Writable]]: true, \[[Enumerable]]: false, \[[Configurable]]: true }. +* The value of the property is a Function object that behaves as follows when invoked: +
    + 1. Let |O| be the this value. + 1. Let |name| be the name of the property – “get” or “has”. + 1. If |O| is a [=platform object=], + then [=perform a security check=], passing: + * the platform object |O|, + * the ECMAScript global environment associated with this Function, + * an identifier equal to |name|, and + * the type “method”. + 1. If |O| is not an object that implements |A|, then throw a TypeError. + 1. Let |map| be the Map object that is the value of |O|’s \[[BackingMap]] [=internal slot=]. + 1. Let |keyType| be the key type specified in the [=maplike declaration=]. + 1. Let |function| be the result of calling the \[[Get]] internal method of |map| passing |name| and |map| as arguments. + 1. Let |keyArg| be the first argument passed to this function, or undefined if not supplied. + 1. Let |keyIDL| be the result of [=converted to an IDL value|converting=] |keyArg| to an IDL value of type |keyType|. + 1. Let |key| be the result of [=converted to ECMAScript values|converting=] |keyIDL| to an ECMAScript value. + 1. Return the result of calling the \[[Call]] internal method of |function| with |map| as |thisArg| and the single value |key| as |argumentsList|. +
+ +The value of the Function objects’ “length” properties is the Number value 1. + +The value of the Function object’s “name” property is the String value “get” or “has”, correspondingly. + + +
clear
+ +If |A| and |A|’s +[=consequential interfaces=] +do not declare an [=interface member=] +with identifier “clear”, and +|A| was declared with a read–write maplike declaration, +then a property named “clear” and the following characteristics +must exist on |A|’s +[=interface prototype object=]: + +* The property has attributes { \[[Writable]]: true, \[[Enumerable]]: false, \[[Configurable]]: true }. +* The value of the property is a Function object that [=forwards to the internal map object|forwards “clear” to the internal map object=]. + +The value of the Function object’s “length” property is the Number value 0. + +The value of the Function object’s “name” property is the String value “clear”. + + +
delete
+ +If |A| and |A|’s +[=consequential interfaces=] +do not declare an [=interface member=] +with identifier “delete”, and +|A| was declared with a read–write maplike declaration, +then a property named “delete” and the following characteristics +must exist on |A|’s +[=interface prototype object=]: + +* The property has attributes { \[[Writable]]: true, \[[Enumerable]]: false, \[[Configurable]]: true }. +* The value of the property is a Function object that behaves as follows when invoked: +
    + 1. Let |O| be the this value. + 1. If |O| is a [=platform object=], + then [=perform a security check=], passing: + * the platform object |O|, + * the ECMAScript global environment associated with this Function, + * the identifier “delete”, and + * the type “method”. + 1. If |O| is not an object that implements |A|, then throw a TypeError. + 1. Let |map| be the Map object that is the value of |O|’s \[[BackingMap]] [=internal slot=]. + 1. Let |keyType| be the key type specified in the [=maplike declaration=]. + 1. Let |function| be the result of calling the \[[Get]] internal method of |map| passing “delete” and |map| as arguments. + 1. Let |keyArg| be the first argument passed to this function, or undefined if not supplied. + 1. Let |keyIDL| be the result of [=converted to an IDL value|converting=] |keyArg| to an IDL value of type |keyType|. + 1. Let |key| be the result of [=converted to ECMAScript values|converting=] |keyIDL| to an ECMAScript value. + 1. Return the result of calling the \[[Call]] internal method of |function| with |map| as |thisArg| and the single value |key| as |argumentsList|. +
+ +The value of the Function object’s “length” property is the Number value 1. + +The value of the Function object’s “name” property is the String value “delete”. + + +
set
+ +If |A| and |A|’s +[=consequential interfaces=] +do not declare an [=interface member=] +with identifier “set”, and +|A| was declared with a read–write maplike declaration, +then a property named “set” and the following characteristics +must exist on |A|’s +[=interface prototype object=]: + +* The property has attributes { \[[Writable]]: true, \[[Enumerable]]: false, \[[Configurable]]: true }. +* The value of the property is a Function object that behaves as follows when invoked: +
    + 1. Let |O| be the this value. + 1. If |O| is a [=platform object=], + then [=perform a security check=], passing: + * the platform object |O|, + * the ECMAScript global environment associated with this Function, + * the identifier “set”, and + * the type “method”. + 1. If |O| is not an object that implements |A|, then throw a TypeError. + 1. Let |map| be the Map object that is the value of |O|’s \[[BackingMap]] [=internal slot=]. + 1. Let |keyType| and |valueType| be the key and value types specified in the [=maplike declaration=]. + 1. Let |function| be the result of calling the \[[Get]] internal method of |map| passing “set” and |map| as arguments. + 1. Let |keyArg| be the first argument passed to this function, or undefined if not supplied. + 1. Let |valueArg| be the second argument passed to this function, or undefined if not supplied. + 1. Let |keyIDL| be the result of [=converted to an IDL value|converting=] |keyArg| to an IDL value of type |keyType|. + 1. Let |valueIDL| be the result of [=converted to an IDL value|converting=] |valueArg| to an IDL value of type |valueType|. + 1. Let |key| be the result of [=converted to ECMAScript values|converting=] |keyIDL| to an ECMAScript value. + 1. Let |value| be the result of [=converted to ECMAScript values|converting=] |valueIDL| to an ECMAScript value. + 1. Let |result| be the result of calling the \[[Call]] internal method of |function| with |map| as |thisArg| and |key| and |value| as |argumentsList|. + 1. Assert: |result| is not an abrupt completion. + 1. Return |O|. +
+ +The value of the Function object’s “length” property is the Number value 2. + +The value of the Function object’s “name” property is the String value “set”. + + +

Setlike declarations

+ +Any object that implements an [=interface=] +that has a [=setlike declaration=] +must have a \[[BackingSet]] [=internal slot=], which is +initially set to a newly created Set object. +This Set object’s \[[SetData]] internal slot is +the object’s [=set entries=]. + +If an [=interface=] |A| is declared with +a [=setlike declaration=], then +there exists a number of additional properties on |A|’s +[=interface prototype object=]. +These additional properties are described in the sub-sections below. + +Some of the properties below are defined to have a [=function object=] value +that forwards to the internal set object +for a given function name. Such functions behave as follows when invoked: + +
    + 1. Let |O| be the this value. + 1. Let |arguments| be the list of arguments passed to this function. + 1. Let |name| be the function name. + 1. If |O| is a [=platform object=], + then [=perform a security check=], passing: + * the platform object |O|, + * the ECMAScript global environment associated with this Function, + * an identifier equal to |name|, and + * the type “method”. + 1. If |O| is not an object that implements |A|, then throw a TypeError. + 1. Let |set| be the Set object that is the value of |O|’s \[[BackingSet]] [=internal slot=]. + 1. Let |function| be the result of calling the \[[Get]] internal method of |set| passing |name| and |set| as arguments. + 1. If [=IsCallable=](|function|) is false, then throw a TypeError. + 1. Return the result of calling the \[[Call]] internal method of |function| with |set| as |thisArg| and |arguments| as |argumentsList|. +
+ + +
size
+ +There must exist a property named “size” on +|A|’s [=interface prototype object=] +with the following characteristics: + +* The property has attributes { \[[Get]]: |G|, \[[Enumerable]]: false, \[[Configurable]]: true }, + where |G| is the interface’s set size getter, + defined below. +* The [=set size getter=] is + a Function object whose + behavior when invoked is as follows: + +
    + 1. Let |O| be the this value. + 1. If |O| is a [=platform object=], + then [=perform a security check=], passing: + * the platform object |O|, + * the ECMAScript global environment associated with this Function, + * the identifier “size”, and + * the type “getter”. + 1. If |O| is not an object that implements |A|, then throw a TypeError. + 1. Let |set| be the Set object that is the value of |O|’s \[[BackingSet]] [=internal slot=]. + 1. Return the result of calling the \[[Get]] internal method of |set| passing “size” and |set| as arguments. +
+ + The value of the Function object’s “length” property is the Number value 0. + + The value of the Function object’s “name” property is the String value “size”. + + +
values
+ +A property named “values” must exist on +|A|’s [=interface prototype object=] +with attributes { \[[Writable]]: true, \[[Enumerable]]: false, \[[Configurable]]: true } +and whose value is the [=function object=] that is the value of +the [=@@iterator=] property. + + +
entries and keys
+ +For both of “entries” and “keys”, there must exist a property with that name on +|A|’s [=interface prototype object=] +with the following characteristics: + +* The property has attributes { \[[Writable]]: true, \[[Enumerable]]: false, \[[Configurable]]: true }. +* The value of the property is a Function object that [=forwards to the internal set object|forwards that name to the internal set object=]. + +The value of the Function objects’ “length” properties is the Number value 0. + +The value of the Function object’s “name” property is the String value “entries” or “keys”, correspondingly. + + +
has
+ +There must exist a property with named “has” on +|A|’s [=interface prototype object=] +with the following characteristics: + +* The property has attributes { \[[Writable]]: true, \[[Enumerable]]: false, \[[Configurable]]: true }. +* The value of the property is a Function object that behaves as follows when invoked: +
    + 1. Let |O| be the this value. + 1. If |O| is a [=platform object=], + then [=perform a security check=], passing: + * the platform object |O|, + * the ECMAScript global environment associated with this Function, + * the identifier “has”, and + * the type “method”. + 1. If |O| is not an object that implements |A|, then throw a TypeError. + 1. Let |set| be the Set object that is the value of |O|’s \[[BackingSet]] [=internal slot=]. + 1. Let |type| be the value type specified in the [=setlike declaration=]. + 1. Let |function| be the result of calling the \[[Get]] internal method of |set| passing “has” and |set| as arguments. + 1. Let |arg| be the first argument passed to this function, or undefined if not supplied. + 1. Let |idlValue| be the result of [=converted to an IDL value|converting=] |arg| to an IDL value of type |type|. + 1. Let |value| be the result of [=converted to ECMAScript values|converting=] |idlValue| to an ECMAScript value. + 1. Return the result of calling the \[[Call]] internal method of |function| with |set| as |thisArg| and the single value |value| as |argumentsList|. +
+ +The value of the Function object’s “length” property is a Number value 1. + +The value of the Function object’s “name” property is the String value “has”. + + +
add and delete
+ +For both of “add” and “delete”, if: + +* |A| and |A|’s + [=consequential interfaces=] + do not declare an [=interface member=] + with a matching identifier, and +* |A| was declared with a read–write setlike declaration, + +then a property with that name and the following characteristics +must exist on |A|’s +[=interface prototype object=]: + +* The property has attributes { \[[Writable]]: true, \[[Enumerable]]: false, \[[Configurable]]: true }. +* The value of the property is a Function object that behaves as follows when invoked: +
    + 1. Let |O| be the this value. + 1. Let |name| be the name of the property – “add” or “delete”. + 1. If |O| is a [=platform object=], + then [=perform a security check=], passing: + * the platform object |O|, + * the ECMAScript global environment associated with this Function, + * an identifier equal to |name|, and + * the type “method”. + 1. If |O| is not an object that implements |A|, then throw a TypeError. + 1. Let |set| be the Set object that is the value of |O|’s \[[BackingSet]] [=internal slot=]. + 1. Let |type| be the value type specified in the [=setlike declaration=]. + 1. Let |function| be the result of calling the \[[Get]] internal method of |set| passing |name| and |set| as arguments. + 1. Let |arg| be the first argument passed to this function, or undefined if not supplied. + 1. Let |idlValue| be the result of [=converted to an IDL value|converting=] |arg| to an IDL value of type |type|. + 1. Let |value| be the result of [=converted to ECMAScript values|converting=] |idlValue| to an ECMAScript value. + 1. Let |result| be the result of calling the \[[Call]] internal method of |function| with |set| as |thisArg| and the single value |value| as |argumentsList|. + 1. Assert: |result| is not an abrupt completion. + 1. If |name| is "delete", then: + 1. Return |result|. + 1. Otherwise: + 1. Return |O|. +
+ +The value of the Function object’s “length” property is the Number value 1. + +The value of the Function object’s “name” property is the String value “add” or “delete”, correspondingly. + + +
clear
+ +If |A| and |A|’s +[=consequential interfaces=] +do not declare an [=interface member=] +with a matching identifier, and +|A| was declared with a read–write setlike declaration, +then a property named “clear” and the following characteristics +must exist on |A|’s +[=interface prototype object=]: + +* The property has attributes { \[[Writable]]: true, \[[Enumerable]]: false, \[[Configurable]]: true }. +* The value of the property is a Function object that [=forwards to the internal set object|forwards “clear” to the internal set object=]. + +The value of the Function object’s “length” property is the Number value 0. + +The value of the Function object’s “name” property is the String value “clear”. + + +

Initializing objects from iterables

+ +Some objects, which are attempting to emulate map- and set-like interfaces, will want to accept iterables +as constructor parameters and initialize themselves in this way. Here we provide some algorithms that can +be invoked in order to do so in the same way as in the ECMAScript spec, so that those objects behave +the same as the built-in Map and Set objects. + +To add map elements from an iterable |iterable| to +an object |destination| with adder method name |adder|, perform the following steps: + +
    + 1. If [=Type=](|destination|) is not Object, then, throw a TypeError. + 1. If |iterable| is not present, let |iterable| be undefined. + 1. If |iterable| is either undefined or null, then let |iter| be undefined. + 1. Else, + 1. Let |adder| be the result of [=Get=](|destination|, |adder|). + 1. [=ReturnIfAbrupt=](|adder|). + 1. If [=IsCallable=](|adder|) is false, throw a TypeError. + 1. Let |iter| be the result of [=GetIterator=](|iterable|). + 1. [=ReturnIfAbrupt=](|iter|). + 1. If |iter| is undefined, then return. + 1. Repeat + 1. Let |next| be the result of [=IteratorStep=](|iter|). + 1. [=ReturnIfAbrupt=](|next|). + 1. If |next| is false, then return [=NormalCompletion=](|destination|). + 1. Let |nextItem| be [=IteratorValue=](|next|). + 1. [=ReturnIfAbrupt=](|nextItem|). + 1. If [=Type=](|nextItem|) is not Object, then throw a TypeError. + 1. Let |k| be the result of [=Get=](|nextItem|, "0"). + 1. [=ReturnIfAbrupt=](|k|). + 1. Let |v| be the result of [=Get=](|nextItem|, "1"). + 1. [=ReturnIfAbrupt=](|v|). + 1. Let |status| be the result of calling the \[[Call]] internal method of |adder| with |destination| as + |thisArgument| and (|k|, |v|) as |argumentsList|. + 1. [=ReturnIfAbrupt=](|status|). +
+ + +

Implements statements

+ +The [=interface prototype object=] +of an interface |A| must have a copy of +each property that corresponds to one of the +[=constants=], +[=attributes=], +[=operations=], +[=iterable declarations=], +[=maplike declarations=] and +[=setlike declarations=] +that exist on all of the interface prototype objects of |A|’s +[=consequential interfaces=]. +For operations, where the property is a data property with a Function +object value, each copy of the property must have +distinct Function objects. For attributes, each +copy of the accessor property must have +distinct Function objects for their getters, +and similarly with their setters. + +
+ + When invoking an [=operation=] by calling + a Function object that is the value of one of the copies that exists + due to an implements statement, the this value is + checked to ensure that it is an object that implements the + [=interface=] corresponding to the + [=interface prototype object=] + that the property is on. + + For example, consider the following IDL: + +
+        interface A {
+          void f();
+        };
+        
+        interface B { };
+        B implements A;
+        
+        interface C { };
+        C implements A;
+    
+ + Attempting to call B.prototype.f on an object that implements + A (but not B) or one + that implements C will result in a + {{TypeError}} being thrown. However, + calling A.prototype.f on an object that implements + B or one that implements C + would succeed. This is handled by the algorithm in [[#es-operations]] + that defines how IDL operation invocation works in ECMAScript. + + Similar behavior is required for the getter and setter Function + objects that correspond to an IDL [=attributes=], + and this is handled in [[#es-attributes]]. + +
+ + +

Platform objects implementing interfaces

+ +Every [=platform object=] is associated with a global environment, just +as the [=initial objects=] are. +It is the responsibility of specifications using Web IDL to state +which global environment (or, by proxy, which global object) each platform +object is associated with. + +The primary interface of a platform object +that implements one or more interfaces is the most-derived [=supplemental interfaces|non-supplemental interface=] +that it implements. The value of the internal \[[Prototype]] +property of the platform object is the [=interface prototype object=] +of the [=primary interface=] +from the [=platform object=]’s associated global environment. + +The global environment that a given [=platform object=] +is associated with can change after it has been created. When +the global environment associated with a platform object is changed, its internal +\[[Prototype]] property must be immediately +updated to be the [=interface prototype object=] +of the [=primary interface=] +from the [=platform object=]’s newly associated global environment. + +Every platform object that implements an [{{Unforgeable}}]-annotated +interface and which does not have a [=stringifier=] +that is [=unforgeable=] on any of the +interfaces it implements must have a property with the +following characteristics: + +* The name of the property is “toString”. +* The property has attributes { \[[Writable]]: false, \[[Enumerable]]: true, \[[Configurable]]: false }. +* The value of the property is [=%ObjProto_toString%=], the initial value of Object.prototype.toString. + +Every platform object that implements an [{{Unforgeable}}]-annotated +interface and which does not have a [=serializer=] +that is [=unforgeable=] on any of the +interfaces it implements must have a property with the +following characteristics: + +* The name of the property is “toJSON”. +* The property has attributes { \[[Writable]]: false, \[[Enumerable]]: true, \[[Configurable]]: false }. +* The value of the property is undefined. + +Every platform object that implements an [{{Unforgeable}}]-annotated +interface must have a property with the +following characteristics: + +* The name of the property is “valueOf”. +* The property has attributes { \[[Writable]]: false, \[[Enumerable]]: true, \[[Configurable]]: false }. +* The value of the property is a Function object whose behavior + is as follows: +
    + 1. Return the this value. +
+ + This Function object is the + default unforgeable valueOf function. +* The value of the Function object’s “length” + property is the Number value 0. +* The value of the Function object’s “name” property is the + String value “valueOf”. + +The [=class string=] of +a platform object that implements one or more interfaces +must be the [=identifier=] of +the [=primary interface=] +of the platform object. + + +

Indexed and named properties

+ +If a [=platform object=] implements an [=interface=] that +[=support indexed properties|supports indexed=] or +[=support named properties|named properties=], +the object will appear to have additional properties that correspond to the +object’s indexed and named properties. These properties are not “real” own +properties on the object, but are made to look like they are by being exposed +by the \[[GetOwnProperty]] internal method. + +However, when the [{{Global}}] or +[{{PrimaryGlobal}}] +[=extended attribute=] has been used, +named properties are not exposed on the object but on another object +in the prototype chain, the [=named properties object=]. + +It is permissible for an object to implement multiple interfaces that support indexed properties. +However, if so, and there are conflicting definitions as to the object’s +[=supported property indices=], +or if one of the interfaces is a [=supplemental interface=] for the +platform object, then it is undefined what additional properties the object will appear to +have, or what its exact behavior will be with regard to its indexed properties. +The same applies for named properties. + +The [=indexed property getter=] +that is defined on the derived-most interface that the +platform object implements is the one that defines the behavior +when indexing the object with an array index. Similarly for +[=indexed property setters=]. +This way, the definitions of these special operations from +ancestor interfaces can be overridden. + +Platform objects implementing an interface that supports indexed or named properties cannot be fixed; if Object.freeze, Object.seal +or Object.preventExtensions is called on one of these objects, the function +must throw a TypeError. +Similarly, an [=interface prototype object=] +that exposes named properties due to the use of [{{Global}}] or +[{{PrimaryGlobal}}] +also must throw a TypeError +if one of the three functions above is called on it. + +The name of each property that appears to exist due to an object supporting indexed properties +is an array index property name, which is a property +name |P| such that [=Type=](|P|) is String +and for which the following algorithm returns true: + +
    + 1. Let |i| be [=ToUint32=](|P|). + 1. Let |s| be [=ToString=](|i|). + 1. If |s| ≠ |P| or |i| = 232 − 1, then return false. + 1. Return true. +
+ +A property name is an unforgeable property name on a +given platform object if the object implements an [=interface=] that +has an [=interface member=] with that identifier +and that interface member is [=unforgeable=] on any of +the interfaces that |O| implements. If the object implements an +[{{Unforgeable}}]-annotated +[=interface=], then “toString” and “valueOf” are +also [=unforgeable property names=] +on that object. + +The named property visibility algorithm is used to determine if +a given named property is exposed on an object. Some named properties are not exposed on an object +depending on whether the [{{OverrideBuiltins}}] +[=extended attribute=] was used. The algorithm +operates as follows, with property name |P| and object |O|: + +
    + 1. If |P| is an [=unforgeable property name=] + on |O|, then return false. + 1. If |O| implements an [=interface=] with + an [{{Unforgeable}}]-annotated [=attribute=] + whose [=identifier=] is |P|, then return false. + 1. If |P| is not a [=supported property name=] + of |O|, then return false. + 1. If |O| implements an interface that has the [{{OverrideBuiltins}}] + [=extended attribute=], then return true. + 1. If |O| has an own property named |P|, then return false. + 1. Initialize |prototype| to be the value of the internal \[[Prototype]] property of |O|. + 1. While |prototype| is not null: + 1. If |prototype| is not a [=named properties object=], + and |prototype| has an own property named |P|, then return false. + 1. Set |prototype| to be the value of the internal \[[Prototype]] property of |prototype|. + 1. Return true. +
+ +
+ + This should ensure that for objects with named properties, property resolution is done in the following order: + + 1. Indexed properties. + 1. Unforgeable attributes and operations. + 1. Then, if [{{OverrideBuiltins}}]: + 1. Named properties. + 1. Own properties. + 1. Properties from the prototype chain. + 1. Otherwise, if not [{{OverrideBuiltins}}]: + 1. Own properties. + + 1. Properties from the prototype chain. + + 1. Named properties. + +
+ +Support for [=getters=] is +handled by the platform object \[[GetOwnProperty]] method +defined in section [[#getownproperty]], and +for [=setters=] +by the platform object \[[DefineOwnProperty]] method +defined in section [[#defineownproperty]] and the platform object \[[Set]] method +defined in section [[#platformobjectset]]. + + +

The PlatformObjectGetOwnProperty abstract operation

+ +The PlatformObjectGetOwnProperty +abstract operation performs the following steps when called with an +object |O|, a property name |P|, and a boolean +|ignoreNamedProps| value: + +
    + 1. If |O| [=support indexed properties|supports indexed properties=] + and |P| is an [=array index property name=], then: + 1. Let |index| be the result of calling [=ToUint32=](|P|). + 1. If |index| is a [=supported property indices|supported property index=], then: + 1. Let |operation| be the operation used to declare the indexed property getter. + + 1. Let |value| be an uninitialized variable. + 1. If |operation| was defined without an [=identifier=], then + set |value| to the result of performing the steps listed in the interface description to + [=determine the value of an indexed property=] + with |index| as the index. + 1. Otherwise, |operation| was defined with an identifier. Set |value| to the result + of performing the steps listed in the description of |operation| with |index| as the only argument value. + + 1. Let |desc| be a newly created [=Property Descriptor=] with no fields. + 1. Set |desc|.\[[Value]] to the result of [=converted to an ECMAScript value|converting=] + |value| to an ECMAScript value. + 1. If |O| implements an interface with an [=indexed property setter=], then set + |desc|.\[[Writable]] to true, otherwise set it to + false. + 1. Set |desc|.\[[Enumerable]] and |desc|.\[[Configurable]] to true. + 1. Return |desc|. + 1. Set |ignoreNamedProps| to true. + + 1. If |O| [=support named properties|supports named properties=], |O| does not + implement an [=interface=] with the [{{Global}}] or [{{PrimaryGlobal}}] + [=extended attribute=], the result of running the [=named property visibility algorithm=] with + property name |P| and object |O| is true, and |ignoreNamedProps| is false, then: + 1. Let |operation| be the operation used to declare the named property getter. + + 1. Let |value| be an uninitialized variable. + 1. If |operation| was defined without an [=identifier=], then + set |value| to the result of performing the steps listed in the interface description to + [=determine the value of a named property=] + with |P| as the name. + 1. Otherwise, |operation| was defined with an identifier. Set |value| to the result + of performing the steps listed in the description of |operation| with |P| as the only argument value. + + 1. Let |desc| be a newly created [=Property Descriptor=] with no fields. + 1. Set |desc|.\[[Value]] to the result of [=converted to an ECMAScript value|converting=] + |value| to an ECMAScript value. + 1. If |O| implements an interface with a [=named property setter=], then set + |desc|.\[[Writable]] to true, otherwise set it to + false. + 1. If |O| implements an interface with the + [{{LegacyUnenumerableNamedProperties}}] + [=extended attribute=], + then set |desc|.\[[Enumerable]] to false, + otherwise set it to true. + 1. Set |desc|.\[[Configurable]] to true. + 1. Return |desc|. + + 1. Return [=OrdinaryGetOwnProperty=](|O|, |P|). +
+ + +

Platform object \[[GetOwnProperty]] method

+ +The internal \[[GetOwnProperty]] method of every +[=platform object=] |O| that implements an [=interface=] +which [=support indexed properties|supports indexed=] or +[=support named properties|named properties=] +must behave as follows when called with property name |P|: + +
    + 1. Return the result of invoking the [=The PlatformObjectGetOwnProperty abstract operation|PlatformObjectGetOwnProperty=] + abstract operation with + |O|, |P|, and false as + arguments. +
+ + +

Invoking a platform object indexed property setter

+ +To invoke an indexed property setter with property name |P| and ECMAScript value +|V|, the following steps must be performed: + +
    + 1. Let |index| be the result of calling [=ToUint32=](|P|). + 1. Let |creating| be true if |index| is not a [=supported property indices|supported property index=], and false otherwise. + 1. Let |operation| be the operation used to declare the indexed property setter. + 1. Let |T| be the type of the second argument of |operation|. + 1. Let |value| be the result of [=converted to an IDL value|converting=] |V| to an IDL value of type |T|. + 1. If |operation| was defined without an [=identifier=], then: + 1. If |creating| is true, then perform the steps listed in the interface description to + [=set the value of a new indexed property=] + with |index| as the index and |value| as the value. + 1. Otherwise, |creating| is false. Perform the steps listed in the interface description to + [=set the value of an existing indexed property=] + with |index| as the index and |value| as the value. + 1. Otherwise, |operation| was defined with an identifier. Perform the steps listed in the description of + |operation| with |index| and |value| as the two argument values. +
+ + +

Invoking a platform object named property setter

+ +To invoke a named property setter with property name |P| and ECMAScript value +|V|, the following steps must be performed: + +
    + 1. Let |creating| be true if |P| is not a [=supported property name=], and false otherwise. + 1. Let |operation| be the operation used to declare the named property setter. + 1. Let |T| be the type of the second argument of |operation|. + 1. Let |value| be the result of [=converted to an IDL value|converting=] |V| to an IDL value of type |T|. + 1. If |operation| was defined without an [=identifier=], then: + 1. If |creating| is true, then perform the steps listed in the interface description to + [=set the value of a new named property=] + with |P| as the name and |value| as the value. + 1. Otherwise, |creating| is false. Perform the steps listed in the interface description to + [=set the value of an existing named property=] + with |P| as the name and |value| as the value. + 1. Otherwise, |operation| was defined with an identifier. Perform the steps listed in the description of + |operation| with |index| and |value| as the two argument values. +
+ + +

Platform object \[[Set]] method

+ +The internal \[[Set]] method of every +[=platform object=] |O| that implements an [=interface=] +which [=support indexed properties|supports indexed=] or +[=support named properties|named properties=] +must behave as follows when called +with property name |P|, value |V|, and +ECMAScript language value |Receiver|: + +
    + 1. If |O| and |Receiver| are the same object, + then: + 1. If |O| [=support indexed properties|supports indexed properties=], |P| is an [=array index property name=], and |O| implements an interface with an [=indexed property setter=], then: + 1. Invoke the indexed + property setter with |P| and |V|. + 1. Return true. + + 1. If |O| [=support named properties|supports named properties=], [=Type=](|P|) is String, + |P| is not an [=array index property name=], and |O| implements an interface with a [=named property setter=], then: + 1. Invoke the named + property setter with |P| and |V|. + 1. Return true. + 1. Let |ownDesc| be the result of invoking the [=The PlatformObjectGetOwnProperty abstract operation|PlatformObjectGetOwnProperty=] + abstract operation with + |O|, |P|, and true as + arguments. + 1. Perform steps 3-11 of the [=default [[Set]] internal method=]. +
+ + +

Platform object \[[DefineOwnProperty]] method

+ +When the internal \[[DefineOwnProperty]] method of a +[=platform object=] |O| that +implements an [=interface=] which +[=support indexed properties|supports indexed=] or +[=support named properties|named properties=] is +called with property key |P| and [=Property Descriptor=] +|Desc|, the following steps must be taken: + +
    + 1. If |O| [=support indexed properties|supports indexed properties=] and + |P| is an [=array index property name=], then: + 1. If the result of calling [=IsDataDescriptor=](|Desc|) is + false, then return + false. + 1. If |O| does not implement an interface with an + [=indexed property setter=], then return false. + 1. Invoke the indexed property setter with + |P| and |Desc|.\[[Value]]. + 1. Return true. + + 1. If |O| [=support named properties|supports named properties=], + |O| does not implement an [=interface=] with the + [{{Global}}] or [{{PrimaryGlobal}}] [=extended attribute=] + and |P| is not an [=unforgeable property name=] + of |O|, then: + 1. Let |creating| be true if |P| is not a [=supported property name=], and false otherwise. + 1. If |O| implements an interface with the [{{OverrideBuiltins}}] + [=extended attribute=] or |O| does not have an own property + named |P|, then: + 1. If |creating| is false and |O| does not implement an + interface with a [=named property setter=], then return false. + 1. If |O| implements an interface with a + [=named property setter=], then: + 1. If the result of calling [=IsDataDescriptor=](|Desc|) is + false, then return + false. + 1. Invoke the named property setter + with |P| and + |Desc|.\[[Value]]. + 1. Return true. + + 1. If |O| does not implement an + [=interface=] with the + [{{Global}}] or + [{{PrimaryGlobal}}] + [=extended attribute=], then set + |Desc|.\[[Configurable]] to + true. + + 1. Return [=OrdinaryDefineOwnProperty=](|O|, |P|, + |Desc|). +
+ + +

Platform object \[[Delete]] method

+ +The internal \[[Delete]] method of every +[=platform object=] |O| that implements an [=interface=] +which [=support indexed properties|supports indexed=] or +[=support named properties|named properties=] +must behave as follows when called with property name |P|. + +
    + 1. If |O| [=support indexed properties|supports indexed properties=] and + |P| is an [=array index property name=], then: + 1. Let |index| be the result of calling [=ToUint32=](|P|). + 1. If |index| is not a [=supported property indices|supported property index=], then return true. + 1. Return false. + + 1. If |O| [=support named properties|supports named properties=], + |O| does not implement an [=interface=] with the + [{{Global}}] or [{{PrimaryGlobal}}] [=extended attribute=] + and the result of calling the [=named property visibility algorithm=] + with property name |P| and object |O| is true, then: + 1. If |O| does not implement an interface with a [=named property deleter=], then return false. + 1. Let |operation| be the operation used to declare the named property deleter. + 1. If |operation| was defined without an [=identifier=], then: + 1. Perform the steps listed in the interface description to + [=delete an existing named property=] + with |P| as the name. + 1. If the steps indicated that the deletion failed, then return false. + 1. Otherwise, |operation| was defined with an identifier: + 1. Perform the steps listed in the description of |operation| with |P| as the only argument value. + 1. If |operation| was declared with a [=return type=] of {{boolean}} + and the steps returned false, then return false. + 1. Return true. + + 1. If |O| has an own property with name |P|, then: + 1. If the property is not configurable, then return false. + 1. Otherwise, remove the property from |O|. + 1. Return true. +
+ + +

Platform object \[[Call]] method

+ +The internal \[[Call]] method of every +[=platform object=] |O| that implements an [=interface=] +|I| with at least one [=legacy caller=] +must behave as follows, assuming +|arg|0..|n|−1 is the list of argument +values passed to \[[Call]]: + +
    + 1. Initialize |S| to the [=effective overload set=] + for legacy callers on |I| and with argument count |n|. + 1. Let <|operation|, |values|> be the result of passing |S| and + |arg|0..|n|−1 to the + [=overload resolution algorithm=]. + 1. Perform the actions listed in the description of the legacy caller |operation| with + |values| as the argument values. + 1. Return the result of [=converted to an ECMAScript value|converting=] + the return value from those actions to an ECMAScript value of the type + |operation| is declared to return (or undefined + if |operation| is declared to return {{void}}). +
+ + +

Property enumeration

+ +This document does not define a complete property enumeration order +for all [=platform objects=] implementing [=interfaces=] +(or for platform objects representing exceptions). +However, if a platform object implements an interface that +[=support indexed properties|supports indexed=] or +[=support named properties|named properties=], then +properties on the object must be +enumerated in the following order: + +1. If the object [=support indexed properties|supports indexed properties=], then + the object’s [=supported property indices=] are + enumerated first, in numerical order. +1. If the object [=support named properties|supports named properties=] and doesn't implement an [=interface=] with the + [{{LegacyUnenumerableNamedProperties}}] + [=extended attribute=], then + the object’s [=supported property names=] that + are visible according to the [=named property visibility algorithm=] + are enumerated next, in the order given in the definition of the set of supported property names. +1. Finally, any enumerable own properties or properties from the object’s prototype chain are then enumerated, + in no defined order. + +Note: Future versions of the ECMAScript specification may define a total order for property enumeration. + + +

User objects implementing callback interfaces

+ +As described in [[#idl-objects]], +[=callback interfaces=] can be +implemented in script by an ECMAScript object. +The following cases determine whether and how a given object +is considered to be a user object implementing a callback interface: + +* If the interface is a [=single operation callback interface=] + (defined below) then any object apart from a native RegExp + object is considered to implement the interface. + The implementation of the operation (or set of overloaded operations) is + as follows: + * If the object is [=callable=], + then the implementation of the operation (or set of overloaded operations) is + the callable object itself. + * Otherwise, the object is not [=callable=]. + The implementation of the operation (or set of overloaded operations) is + the result of invoking the internal \[[Get]] method + on the object with a property name that is the [=identifier=] + of the operation. +* Otherwise, the interface is not a [=single operation callback interface=]. + Any object that is not a native + RegExp object is considered to implement the interface. + For each operation declared on the interface with a given [=identifier=], the implementation + is the result of invoking \[[Get]] on the object with a + property name that is that identifier. + +Note that ECMAScript objects need not have +properties corresponding to [=constants=] +on them to be considered as [=user objects=] +implementing [=interfaces=] that happen +to have constants declared on them. + +A single operation callback interface is +a [=callback interface=] that: + +* is not declared to [=interface/inherit=] from another interface, +* has no [=attributes=], and +* has one or more [=regular operations=] that all have the same [=identifier=], + and no others. + +To call a user object's operation, given a [=Interface types|callback interface type=] value |value|, sometimes-optional operation name |opName|, +list of argument values |arg|0..|n|−1 each of which is +either an IDL value or the special value “missing” (representing a missing optional +argument), and optional callback this value |thisArg|, perform the following steps. These steps will either +return an IDL value or throw an exception. + +
    + 1. Let |completion| be an uninitialized variable. + + 1. If |thisArg| was not given, let |thisArg| be undefined. + + 1. Let |O| be the ECMAScript object corresponding to |value|. + + 1. Let |realm| be |O|'s [=associated Realm=]. + + 1. Let |relevant settings| be |realm|'s [=settings object=]. + + 1. Let |stored settings| be |value|'s [=callback context=]. + + 1. [=Prepare to run script=] with |relevant settings|. + + 1. [=Prepare to run a callback=] with |stored settings|. + + 1. Determine the implementation of the operation, |X|: + + 1. If |value|'s interface is a [=single operation callback interface=] and [=!=] [=IsCallable=](|O|) is true, then set + |X| to |O|. + + 1. Otherwise, |opName| must be supplied: + 1. Let |getResult| be [=Get=](|O|, + |opName|). + + 1. If |getResult| is an abrupt completion, set |completion| + to |getResult| and jump to the step labeled return. + + 1. Set |X| to |getResult|.\[[Value]]. + + 1. If [=!=] [=IsCallable=](|X|) is false, + then set |completion| to a new [=Completion=]{\[[Type]]: throw, \[[Value]]: a + newly created TypeError object, \[[Target]]: empty}, and jump + to the step labeled return. + + 1. If |value|'s interface is not a [=single operation callback interface=], + or if [=!=] [=IsCallable=](|O|) is false, + set |thisArg| to |O| (overriding the provided value). + + 1. Let |esArgs| be an empty List of ECMAScript values. + + 1. Let |i| be 0. + + 1. Let |count| be 0. + + 1. While |i| < |n|: + + 1. If |arg||i| is the special value “missing”, then + append undefined to |esArgs|. + + 1. Otherwise, |arg||i| is an IDL value: + + 1. Let |convertResult| be the result of [=converted to an ECMAScript value|converting=] + |arg||i| to an ECMAScript value. + + 1. If |convertResult| is an abrupt completion, set |completion| + to |convertResult| and jump to the step labeled return. + + 1. Append |convertResult|.\[[Value]] to |esArgs|. + + 1. Set |count| to |i| + 1. + + 1. Set |i| to |i| + 1. + + 1. Truncate |esArgs| to have length |count|. + + 1. Let |callResult| be [=Call=](|X|, |thisArg|, + |esArgs|). + + 1. If |callResult| is an abrupt completion, set |completion| to + |callResult| and jump to the step labeled return. + + 1. Set |completion| to the result of [=converted to an IDL value|converting=] + |callResult|.\[[Value]] to an IDL value of the same type as the operation’s + return type. + + 1. Return: at this + point |completion| will be set to an ECMAScript completion value. + + 1. [=Clean up after running a callback=] with |stored settings|. + + 1. [=Clean up after running script=] with |relevant settings|. + + 1. If |completion| is a normal completion, return + |completion|. + + 1. If |completion| is an abrupt completion and the operation has a [=return type=] that is not a promise type, return |completion|. + + 1. Let |reject| be the initial value of [=%Promise%=].reject. + + 1. Let |rejectedPromise| be the result of calling |reject| with + [=%Promise%=] as the this value and + |completion|.\[[Value]] as the single argument value. + + 1. Return the result of [=converted to an IDL value|converting=] + |rejectedPromise| to the operation's return type. +
+ +To get a user object's attribute value, given a [=Interface types|callback interface type=] value |object| and attribute name |attributeName|, +perform the following steps. These steps will either return an IDL value or throw an +exception. + +
    + 1. Let |completion| be an uninitialized variable. + + 1. Let |O| be the ECMAScript object corresponding to |object|. + + 1. Let |realm| be |O|'s [=associated Realm=]. + + 1. Let |relevant settings| be |realm|'s [=settings object=]. + + 1. Let |stored settings| be |object|'s [=callback context=]. + + 1. [=Prepare to run script=] with |relevant settings|. + + 1. [=Prepare to run a callback=] with |stored settings|. + + 1. Let |getResult| be [=Get=](|O|, |attributeName|). + + 1. If |getResult| is an abrupt completion, set |completion| to + |getResult| and jump to the step labeled return. + + 1. Set |completion| to the result of [=converted to an IDL value|converting=] + |getResult|.\[[Value]] to an IDL value of the same type as the attribute's + type. + + 1. Return: at this + point |completion| will be set to an ECMAScript completion value. + + 1. [=Clean up after running a callback=] with |stored settings|. + + 1. [=Clean up after running script=] with |relevant settings|. + + 1. If |completion| is a normal completion, return + |completion|. + + 1. If |completion| is an abrupt completion and the attribute's type is + not a promise type, return + |completion|. + + 1. Let |reject| be the initial value of [=%Promise%=].reject. + + 1. Let |rejectedPromise| be the result of calling |reject| with + [=%Promise%=] as the this value and + |completion|.\[[Value]] as the single argument value. + + 1. Return the result of [=converted to an IDL value|converting=] + |rejectedPromise| to the attribute's type. +
+ +To set a user object's attribute value, given a [=Interface types|callback interface type=] value |object|, attribute name |attributeName|, and +IDL value |value|, perform the following steps. These steps will not return +anything, but could throw an exception. + +
    + 1. Let |completion| be an uninitialized variable. + + 1. Let |O| be the ECMAScript object corresponding to |object|. + + 1. Let |realm| be |O|'s [=associated Realm=]. + + 1. Let |relevant settings| be |realm|'s [=settings object=]. + + 1. Let |stored settings| be |object|'s [=callback context=]. + + 1. [=Prepare to run script=] with |relevant settings|. + + 1. [=Prepare to run a callback=] with |stored settings|. + + 1. Let |convertResult| be the result of [=converted to an ECMAScript value|converting=] |value| to an + ECMAScript value. + + 1. If |convertResult| is an abrupt completion, set |completion| to + |convertResult| and jump to the step labeled return. + + 1. Set |completion| to [=Set=](|O|, |attributeName|, + |convertResult|.\[[Value]], true). + + 1. Return: at this + point |completion| will be set to an ECMAScript completion value, which is + either an abrupt completion or a normal completion for the value true (as returned by [=Set=]). + + 1. [=Clean up after running a callback=] with |stored settings|. + + 1. [=Clean up after running script=] with |relevant settings|. + + 1. If |completion| is an abrupt completion, return + |completion|. + + 1. Return [=NormalCompletion=]({{void}}). +
+ + +

Invoking callback functions

+ +An ECMAScript [=callable=] object that is being +used as a [=callback function=] value is +called in a manner similar to how [=operations=] +on [=user objects=] are called (as +described in the previous section). + +To invoke a [=callback function type=] value |callable| with +a list of arguments |arg|0..|n|−1, each of which is either +an IDL value or the special value “missing” (representing a missing optional argument), +and with optional [=callback this value|callback this value=] |thisArg|, perform the following steps. These steps will either +return an IDL value or throw an exception. + +
    + 1. Let |completion| be an uninitialized variable. + + 1. If |thisArg| was not given, let |thisArg| be undefined. + + 1. Let |F| be the ECMAScript object corresponding to |value|. + + 1. If [=!=] [=IsCallable=](|F|) is false: + + 1. If the callback function's return type is {{void}}, + return. + + Note: This is only possible when the callback function came from an attribute + marked with [{{TreatNonObjectAsNull}}]. + + 1. Return the result of [=converted to an IDL value|converting=] undefined to the callback function's return type. + + 1. Let |realm| be |F|'s [=associated Realm=]. + + 1. Let |relevant settings| be |realm|'s [=settings object=]. + + 1. Let |stored settings| be |callable|'s [=callback context=]. + + 1. [=Prepare to run script=] with |relevant settings|. + + 1. [=Prepare to run a callback=] with |stored settings|. + + 1. Let |esArgs| be an empty List of ECMAScript values. + + 1. Let |i| be 0. + + 1. Let |count| be 0. + + 1. While |i| < |n|: + + 1. If |arg||i| is the special value “missing”, then + append undefined to |esArgs|. + + 1. Otherwise, |arg||i| is an IDL value: + + 1. Let |convertResult| be the result of [=converted to an ECMAScript value|converting=] + |arg||i| to an ECMAScript value. + + 1. If |convertResult| is an abrupt completion, set |completion| + to |convertResult| and jump to the step labeled return. + + 1. Append |convertResult|.\[[Value]] to |esArgs|. + + 1. Set |count| to |i| + 1. + + 1. Set |i| to |i| + 1. + + 1. Truncate |esArgs| to have length |count|. + + 1. Let |callResult| be [=Call=](|X|, |thisArg|, + |esArgs|). + + 1. If |callResult| is an abrupt completion, set |completion| to + |callResult| and jump to the step labeled return. + + 1. Set |completion| to the result of [=converted to an IDL value|converting=] + |callResult|.\[[Value]] to an IDL value of the same type as the operation’s + return type. + + 1. Return: at this + point |completion| will be set to an ECMAScript completion value. + + 1. [=Clean up after running a callback=] with |stored settings|. + + 1. [=Clean up after running script=] with |relevant settings|. + + 1. If |completion| is a normal completion, return + |completion|. + + 1. If |completion| is an abrupt completion and the callback function has a + [=return type=] that is not a promise type, return |completion|. + + 1. Let |reject| be the initial value of [=%Promise%=].reject. + + 1. Let |rejectedPromise| be the result of calling |reject| with + [=%Promise%=] as the this value and + |completion|.\[[Value]] as the single argument value. + + 1. Return the result of [=converted to an IDL value|converting=] + |rejectedPromise| to the callback function's return type. +
+ + +

Namespaces

+ +For every [=namespace=] that is [=exposed=] in a given ECMAScript global environment, +a corresponding property must exist on the ECMAScript +environment's global object. The name of the property is the [=identifier=] of the namespace, and its value is an object +called the namespace object. + +The property has the attributes { \[[Writable]]: true, \[[Enumerable]]: false, +\[[Configurable]]: true }. The characteristics of a +namespace object are described in [[#namespace-object]]. + + +

Namespace object

+ +The namespace object for a given [=namespace=] +|namespace| and [=Realm=] |realm| is created as +follows: + +
    + 1. Let |namespaceObject| be + [=!=] [=ObjectCreate=](the [=%ObjectPrototype%=] of |realm|). + + 1. For each [=exposed=] [=regular operation=] |op| that is a [=namespace member=] of this namespace, + + 1. Let |F| be the result of [=creating an operation function|creating an operation function=] given + |op|, |namespace|, and |realm|. + + 1. Perform [=!=] [=CreateDataProperty=](|namespaceObject|, + |op|'s [=identifier=], + |F|). +
+ + +

Exceptions

+ +There must exist a property on the ECMAScript global object +whose name is “DOMException” and value is an object called the +DOMException constructor object, +which provides access to legacy DOMException code constants and allows construction of +DOMException instances. +The property has the attributes { \[[Writable]]: true, \[[Enumerable]]: false, \[[Configurable]]: true }. + + +

DOMException constructor object

+ +The DOMException constructor object must be a [=function object=] +but with a \[[Prototype]] value of [=%Error%=]. + +For every legacy code listed in the error names table, +there must be a property on the DOMException constructor object +whose name and value are as indicated in the table. The property has +attributes { \[[Writable]]: false, \[[Enumerable]]: true, \[[Configurable]]: false }. + +The DOMException constructor object must also have a property named +“prototype” with attributes +{ \[[Writable]]: false, \[[Enumerable]]: false, \[[Configurable]]: false } +whose value is an object called the DOMException prototype object. +This object also provides access to the legacy code values. + + +
DOMException(message, name)
+ +When the DOMException function is called with arguments |message| and |name|, the following steps are taken: + +
    + 1. Let |F| be the active function object. + 1. If NewTarget is undefined, let |newTarget| be |F|, else let |newTarget| be NewTarget. + 1. Let |super| be |F|.\[[GetPrototypeOf]](). + 1. [=ReturnIfAbrupt=](|super|). + 1. If [=IsConstructor=](|super|) is false, throw a TypeError exception. + 1. Let |O| be [=Construct=](|super|, «|message|», |newTarget|). + 1. If |name| is not undefined, then + 1. Let |name| be [=ToString=](|name|). + 1. Let |status| be [=DefinePropertyOrThrow=](|O|, "name", PropertyDescriptor{\[[Value]]: |name|, \[[Writable]]: true, \[[Enumerable]]: false, \[[Configurable]]: true}). + 1. [=ReturnIfAbrupt=](|status|). + 1. Let |code| be the legacy code indicated in the [=error names table=] for error name |name|, or 0 if there is none. + 1. Let |status| be [=DefinePropertyOrThrow=](|O|, "code", PropertyDescriptor{\[[Value]]: |code|, \[[Writable]]: true, \[[Enumerable]]: false, \[[Configurable]]: true}). + 1. [=ReturnIfAbrupt=](|status|). + 1. Return |O|. +
+ + +

DOMException prototype object

+ +The DOMException prototype object must +have an internal \[[Prototype]] property whose value is [=%ErrorPrototype%=]. + +The [=class string=] of the +[=DOMException prototype object=] +is “DOMExceptionPrototype”. + +There must be a property named “constructor” +on the DOMException prototype object with attributes +{ \[[Writable]]: true, \[[Enumerable]]: false, \[[Configurable]]: true } +and whose value is the [=DOMException constructor object=]. + +For every legacy code listed in the error names table, +there must be a property on the DOMException prototype object +whose name and value are as indicated in the table. The property has +attributes { \[[Writable]]: false, \[[Enumerable]]: true, \[[Configurable]]: false }. + + +

Exception objects

+ +[=Simple exceptions=] are represented +by native ECMAScript objects of the corresponding type. + +{{DOMException|DOMExceptions}} are represented by +[=platform objects=] that inherit from +the [=DOMException prototype object=]. + +Every platform object representing a DOMException in ECMAScript is associated with a global environment, just +as the [=initial objects=] are. +When an exception object is created by calling the [=DOMException constructor object=], +either normally or as part of a new expression, then the global environment +of the newly created object is associated with must be the same as for the +[=DOMException constructor object=] itself. + +The value of the internal \[[Prototype]] +property of a {{DOMException}} +object must be the [=DOMException prototype object=] +from the global environment the exception object is associated with. + +The [=class string=] +of a {{DOMException}} object +must be “DOMException”. + +Note: The intention is for DOMException objects to be just like the other +various native Error objects that the +ECMAScript specification defines, apart from responding differently +to being passed to Object.prototype.toString and it having a “code” property. +If an implementation places non-standard properties on native +Error objects, exposing for example +stack traces or error line numbers, then these ought to be exposed +on exception objects too. + + +

Creating and throwing exceptions

+ +First, we define the current global environment +as the result of running the following algorithm: + +
    + 1. Let |F| be the Function object used + as the this value in the top-most call + on the ECMAScript call stack where |F| corresponds to an IDL + [=attribute=], + [=operation=], + indexed property, + named property, + constructor, + [=named constructor=] or + [=stringifier=]. + 1. If |F| corresponds to an attribute, operation or stringifier, then return + the global environment associated with the + [=interface=] that definition appears on. + 1. Otherwise, if |F| corresponds to an indexed or named property, then return + the global environment associated with the interface that + the indexed or named property getter, setter or deleter was defined on. + 1. Otherwise, if |F| is a named constructor for an interface, or is + an [=interface object=] for an + interface that is a constructor, then return the global environment + associated with that interface. + 1. Otherwise, |F| is an exception field getter. Return + the global environment associated with the exception on which the + exception field was defined. +
+ +When a [=simple exception=] or +{{DOMException}} +|E| is to be [=created=], +with [=error name=] |N| and +optional user agent-defined message |M|, +the following steps must be followed: + +
    + 1. If |M| was not specified, let |M| be undefined. Otherwise, let it be the result of [=converted to an ECMAScript value|converting=] |M| to a String value. + 1. Let |N| be the result of [=converted to an ECMAScript value|converting=] |N| to a String value. + 1. Let |args| be a list of ECMAScript values. +
    + : |E| is {{DOMException}} + :: |args| is (undefined, |N|). + : |E| is a [=simple exception=] + :: |args| is (|M|) +
    + 1. Let |G| be the [=current global environment=]. + 1. Let |X| be an object determined based on the type of |E|: +
    + : |E| is {{DOMException}} + :: |X| is the [=DOMException constructor object=] + from the global environment |G|. + : |E| is a [=simple exception=] + :: |X| is the constructor for the corresponding ECMAScript error + from the global environment |G|. +
    + 1. Let |O| be the result of calling |X| as a function + with |args| as the argument list. + 1. Return |O|. +
+ +When a [=simple exception=] or +{{DOMException}} +|E| is to be [=thrown=], +with [=error name=] |N| and +optional user agent-defined message |M|, +the following steps must be followed: + +
    + 1. Let |O| be the result of [=created|creating=] + the specified exception |E| with [=error name=] |N| and + optional user agent-defined message |M|. + 1. Throw |O|. +
+ +
+ + The above algorithms do not restrict [=Exception objects|platform objects representing exceptions=] + propagating out of a Function to be + ones that are associated with the global environment + where that Function object originated. + For example, consider the IDL: + +
+        interface A {
+        
+          /**
+           * Calls computeSquareRoot on m, passing x as its argument.
+           */
+          double doComputation(MathUtils m, double x);
+        };
+        
+        interface MathUtils {
+          /**
+           * If x is negative, throws a NotSupportedError.  Otherwise, returns
+           * the square root of x.
+           */
+          double computeSquareRoot(double x);
+        };
+    
+ + If we pass a MathUtils object from + a different global environment to doComputation, then the exception + thrown will be from that global environment: + +
+        var a = getA();                           // An A object from this global environment.
+        var m = otherWindow.getMathUtils();       // A MathUtils object from a different global environment.
+        
+        a instanceof Object;                      // Evaluates to true.
+        m instanceof Object;                      // Evaluates to false.
+        m instanceof otherWindow.Object;          // Evaluates to true.
+        
+        try {
+          a.doComputation(m, -1);
+        } catch (e) {
+          e instanceof DOMException;              // Evaluates to false.
+          e instanceof otherWindow.DOMException;  // Evaluates to true.
+        }
+    
+
+ +Any requirements in this document to throw an instance of an ECMAScript built-in +Error must use +the built-in from the [=current global environment=]. + + +

Handling exceptions

+ +None of the algorithms or processing requirements in the +ECMAScript language binding catch ECMAScript exceptions. Whenever +an ECMAScript Function is invoked due +to requirements in this section and that Function +ends due to an exception being thrown, that exception +must propagate to the caller, and if +not caught there, to its caller, and so on. + +
+ + The following [=IDL fragment=] + defines two [=interfaces=] + and an [=exception=]. + The valueOf attribute on ExceptionThrower + is defined to throw an exception whenever an attempt is made + to get its value. + +
+        interface Dahut {
+          attribute DOMString type;
+        };
+        
+        interface ExceptionThrower {
+          // This attribute always throws a NotSupportedError and never returns a value.
+          attribute long valueOf;
+        };
+    
+ + Assuming an ECMAScript implementation supporting this interface, + the following code demonstrates how exceptions are handled: + +
+        var d = getDahut();              // Obtain an instance of Dahut.
+        var et = getExceptionThrower();  // Obtain an instance of ExceptionThrower.
+        
+        try {
+          d.type = { toString: function() { throw "abc"; } };
+        } catch (e) {
+          // The string "abc" is caught here, since as part of the conversion
+          // from the native object to a string, the anonymous function
+          // was invoked, and none of the [[DefaultValue]], ToPrimitive or
+          // ToString algorithms are defined to catch the exception.
+        }
+        
+        try {
+          d.type = { toString: { } };
+        } catch (e) {
+          // An exception is caught here, since an attempt is made to invoke
+          // [[Call]] on the native object that is the value of toString
+          // property.
+        }
+        
+        d.type = et;
+        // An uncaught NotSupportedError DOMException is thrown here, since the
+        // [[DefaultValue]] algorithm attempts to get the value of the
+        // "valueOf" property on the ExceptionThrower object.  The exception
+        // propagates out of this block of code.
+    
+
+ + +

Common definitions

+ +This section specifies some common definitions that all +[=conforming implementations=] +must support. + + +

ArrayBufferView

+ +
+    typedef (Int8Array or Int16Array or Int32Array or
+             Uint8Array or Uint16Array or Uint32Array or Uint8ClampedArray or
+             Float32Array or Float64Array or DataView) ArrayBufferView;
+
+ +The {{ArrayBufferView}} typedef is used to represent +objects that provide a view on to an {{ArrayBuffer}}. + + +

BufferSource

+ +
typedef (ArrayBufferView or ArrayBuffer) BufferSource;
+ +The {{BufferSource}} typedef is used to represent objects +that are either themselves an {{ArrayBuffer}} or which +provide a view on to an {{ArrayBuffer}}. + + +

DOMTimeStamp

+ +
typedef unsigned long long DOMTimeStamp;
+ +The {{DOMTimeStamp}} type is used for representing +a number of milliseconds, either as an absolute time (relative to some epoch) +or as a relative amount of time. Specifications that use this type will need +to define how the number of milliseconds is to be interpreted. + + +

Function

+ +
callback Function = any (any... arguments);
+ +The {{Function}} [=callback function=] +type is used for representing function values with no restriction on what arguments +are passed to it or what kind of value is returned from it. + + +

VoidFunction

+ +
callback VoidFunction = void ();
+ +The {{VoidFunction}} [=callback function=] +type is used for representing function values that take no arguments and do not +return any value. + + +

Extensibility

+ +This section is informative. + +Extensions to language binding requirements can be specified +using [=extended attributes=] +that do not conflict with those defined in this document. Extensions for +private, project-specific use should not be included in +[=IDL fragments=] +appearing in other specifications. It is recommended that extensions +that are required for use in other specifications be coordinated +with the group responsible for work on Web IDL, which +at the time of writing is the +W3C Web Platform Working Group, +for possible inclusion in a future version of this document. + +Extensions to any other aspect of the IDL language are +strongly discouraged. + + +

Referencing this specification

+ +This section is informative. + +It is expected that other specifications that define Web platform interfaces +using one or more [=IDL fragments=] +will reference this specification. It is suggested +that those specifications include a sentence such as the following, +to indicate that the IDL is to be interpreted as described in this +specification: + +
+ + The IDL fragment in Appendix A of this specification must, in conjunction + with the IDL fragments defined in this specification's normative references, + be interpreted as required for conforming sets of IDL fragments, as described in the + “Web IDL” specification. \[WEBIDL] + +
+ +In addition, it is suggested that the conformance class for user +agents in referencing specifications be linked to the +[=conforming implementation=] class from this specification: + +
+ + A conforming FooML user agent must also be a + conforming implementation of the IDL fragment in Appendix A + of this specification, as described in the + “Web IDL” specification. \[WEBIDL] + +
+ + +

Acknowledgements

+ +This section is informative. + +The editor would like to thank the following people for contributing +to this specification: +Glenn Adams, +David Andersson, +L. David Baron, +Art Barstow, +Nils Barth, +Robin Berjon, +David Bruant, +Jan-Ivar Bruaroey, +Marcos Cáceres, +Giovanni Campagna, +Domenic Denicola, +Chris Dumez, +Michael Dyck, +Brendan Eich, +João Eiras, +Gorm Haug Eriksen, +Sigbjorn Finne, +David Flanagan, +Aryeh Gregor, +Dimitry Golubovsky, +James Graham, +Aryeh Gregor, +Kartikaya Gupta, +Marcin Hanclik, +Jed Hartman, +Stefan Haustein, +Dominique Hazaël-Massieux, +Ian Hickson, +Björn Höhrmann, +Kyle Huey, +Lachlan Hunt, +Oliver Hunt, +Jim Jewett, +Wolfgang Keller, +Anne van Kesteren, +Olav Junker Kjær, +Magnus Kristiansen, +Takeshi Kurosawa, +Yves Lafon, +Travis Leithead, +Jim Ley, +Kevin Lindsey, +Jens Lindström, +Peter Linss, +呂康豪 (Kang-Hao Lu), +Kyle Machulis, +Mark Miller, +Ms2ger, +Andrew Oakley, +岡坂 史紀 (Shiki Okasaka), +Jason Orendorff, +Olli Pettay, +Simon Pieters, +Andrei Popescu, +François Remy, +Tim Renouf, +Alex Russell, +Takashi Sakamoto, +Doug Schepers, +Jonas Sicking, +Garrett Smith, +Geoffrey Sneddon, +Jungkee Song, +Josh Soref, +Maciej Stachowiak, +Anton Tayanovskyy, +Peter Van der Beken, +Jeff Walden, +Allen Wirfs-Brock, +Jeffrey Yasskin and +Collin Xu. + +Special thanks also go to Sam Weinig for maintaining this document +while the editor was unavailable to do so. + + +

IDL grammar

+ +This section defines an LL(1) grammar whose start symbol, +Definitions, matches an +entire [=IDL fragment=]. + +Each production in the grammar has on its right hand side either a +non-zero sequence of terminal and non-terminal symbols, or an +epsilon (ε) which indicates no symbols. +Symbols that begin with an uppercase letter are non-terminal symbols. +Symbols in monospaced fonts are terminal symbols. +Symbols in sans-serif font that begin with a lowercase letter are terminal +symbols that are matched by the regular expressions (using Perl 5 regular +expression syntax [[!PERLRE]]) as follows: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
integer=/-?([1-9][0-9]*|0[Xx][0-9A-Fa-f]+|0[0-7]*)/
float=/-?(([0-9]+\.[0-9]*|[0-9]*\.[0-9]+)([Ee][+-]?[0-9]+)?|[0-9]+[Ee][+-]?[0-9]+)/
identifier=/_?[A-Za-z][0-9A-Z_a-z-]*/
string=/"[^"]*"/
whitespace=/[\t\n\r ]+/
comment=/\/\/.*|\/\*(.|\n)*?\*\//
other=/[^\t\n\r 0-9A-Za-z]/
+ +The tokenizer operates on a sequence of Unicode characters +[[!UNICODE]]. +When tokenizing, the longest possible match must be used. For example, if the input +text is “a1”, it is tokenized as a single identifier, +and not as a separate identifier and integer. +If the longest possible match could match one of the above named terminal symbols or +one of the other terminal symbols from the grammar, it must be tokenized as the latter. +Thus, the input text “long” is tokenized as the quoted terminal symbol +long rather than an identifier called “long”, +and “.” is tokenized as the quoted terminal symbol +. rather than an other. + +The IDL syntax is case sensitive, both for the quoted terminal symbols +used in the grammar and the values used for +identifier terminals. Thus, for +example, the input text “Const” is tokenized as +an identifier rather than the +terminal symbol const, an +[=interface=] with +[=identifier=] +“A” is distinct from one named “a”, and an +[=extended attribute=] +[constructor] will not be recognized as +the [{{Constructor}}] +extended attribute. + +Implicitly, any number of whitespace and +comment terminals are allowed between every other terminal +in the input text being parsed. Such whitespace and +comment terminals are ignored while parsing. + +The following LL(1) grammar, starting with Definitions, +matches an [=IDL fragment=]: + +
+ +Note: The Other +non-terminal matches any single terminal symbol except for +(, ), +[, ], +{, } +and ,. + +While the ExtendedAttribute +non-terminal matches any non-empty sequence of terminal symbols (as long as any +parentheses, square brackets or braces are balanced, and the +, token appears only within those balanced brackets), +only a subset of those +possible sequences are used by the [=extended attributes=] +defined in this specification — see +[[#idl-extended-attributes]] +for the syntaxes that are used by these extended attributes. + + +

Changes

+ +This section is informative. + +The following is a list of substantial changes to the document on each publication. +For the list of changes during the development of the First Edition of this +specification, see +that document's +Changes appendix. + +* Fixed unions containing a sequence and a dictionary to try the + sequence first when given an object, just like overload + resolution does. +* Removed support for [Constructor] on dictionaries. +* Added the [LenientSetter] extended attribute. +* Added the [SecureContext] extended attribute. +* Changed from [Unscopeable] to + [Unscopable] to match ES6 better. +* Removed the term "unenumerable" and its associated prose and replaced it by the + extended attribute [LegacyUnenumerableNamedProperties]. +* Allowed object internal methods to be overridden by other specifications. +* Added some more parameters to the “perform a security check” hook. +* Defined the “name” property for all Function + objects (including those for operations and attribute getters and setters). +* Removed the Date type. +* Disallowed “length” and “name” from being used as identifiers of + constants. +* Added a FrozenArray<|T|> type. +* Renamed [ArrayClass] to [LegacyArrayClass]. +* Removed T[] array types. +* Allowed [NewObject] to be used on things with + a promise type. +* Fix various cases in which maplike/setlike were operating on the wrong objects. + + Disallow maplike, setlike and iterable declarations from appearing more than + once on an interface and its inherited and consequential interfaces. + Also disallow the relevant restricted member names (such as “entries” and “values”) + on the inherited and consequential interfaces. + +* Allowed stringifier attributes to have type {{USVString}}. +* Gave interface objects, named constructors, and dictionary + constructors a "name" property to match ES6. +* Made the "length" property on dictionary constructors + configurable. +* Added types for {{ArrayBuffer}}, {{DataView}} + and typed array objects. +* Added {{USVString}} and allowed string literals in IDL to + be used to give values for all string-typed optional argument and dictionary + member default values. +* Made sequences distinguishable from dictionaries, callback + functions, and all interface types. +* Removed IDL exceptions, baked in {{DOMException}}, + and added {{Error!!interface}} and {{DOMException}} + as types. +* Removed [MapLike] and added + iterable, maplike and setlike declarations. +* Removed the custom Object.prototype.toString definition and instead + defined class strings to influence the @@toStringTag property + on objects. +* Added the [Unscopeable] extended attribute. +* Rewrote ES to IDL sequence conversion so that any iterable is + convertible to a sequence. +* Added grammar production for Promise<|T|> types + and allowed |T| to be {{void}}. +* Added a definition to "initialize an object from an iterable", + which behaves like the Map constructor. +* Added a default value [] that can be used for + sequence-typed operation argument default values and + dictionary member default values. +* Added promise types. +* Added the [NewObject] and + [SameObject] extended attributes. +* Allowed [Constructor] to be specified + on dictionaries. +* Added a RegExp type. +* Added iterators that can be declared on interfaces. +* Added an @@iterator method to objects with indexed + properties. +* Updated to ECMAScript 6th Edition. +* Added serializers. +* Added a {{ByteString}} type, for representing + 8 bit strings without a particular encoding as ECMAScript + String values. +* Added static attributes. + +* Make it clear that an interface can't be exposed in a global + where its parent interface is not exposed. +* Allow dictionary-typed trailing-position operation arguments not to + be optional, if and only if the dictionary type has a required + dictionary member. +* Added a platform object \[[Set]] internal method to handle + named and indexed setters better. +* Removed the concept of creators; setters are always also + creators. +* Disallowed an interface without [NoInterfaceObject] + inheriting from a [NoInterfaceObject] interface. +* Removed indexed deleters. +* Made the prototype of an interface object of a non-root + interface be the interface object of its ancestor interface. +* Clarified the property attributes of the "prototype" property + of non-callback interface objects. +* Made the "length" property on interface objects and named + constructors configurable. +* Added a way to mark dictionary members as required. +* Allowed hyphens in identifiers after the first character. +* Fix [Exposed] text to make it + clear that the value on the interface, if any, is used as the + value for its members by default. +* Fixed the grammar for extended attributes that take an identifier list, + such as [Exposed]. +* Add a term "unenumerable" to allow named properties to be exposed as + properties with \[[Enumerable]] set to false. +* Added the [Exposed] and + [PrimaryGlobal] extended attributes and + allowed an identifier to be used with [Global]. +* Removed [TreatUndefinedAs]. +* Renamed [TreatNonCallableAsNull] to [TreatNonObjectAsNull] + and changed its semantics to allow any object. Changed + callback function invocation to be a no-op when the object is + not callable, which can now happen in the + [TreatNonObjectAsNull] case. +* Changed the default this value for callbacks from null to undefined. +* Removed the requirement for named properties objects to be function objects. +* Disallowed properties from being defined on a named properties object. +* Fixed infinite loop in named property visibility algorithm. +* Made stringifiers and serializers not use \[[Get]] or \[[Call]] + for the their attribute or operation delegated behavior. +* Allowed trailing optional comma in enum lists. +* Disallowed static interface members from being defined on a callback interface. +* Added a hook to do a security check when invoking an operation + or accessing an attribute. +* Defined how callbacks influence the incumbent script. +* Changed how callback functions are invoked to support missing + optional arguments. +* Renamed [NamedPropertiesObject] to + [Global], which now also causes + properties for interface members to appear on the object + itself rather than on the interface prototype object. +* Split out {{boolean}} from the other + primitive types. Made {{boolean}}, + numeric types and {{DOMString}} distinguishable. +* Required a getter to be present on an interface if it has a + setter, creator or delete. +* Extended [Unforgeable] to apply to operations + and interfaces. +* Allowed all operation arguments to be specified as being optional and + changed back to the behavior of undefined + being treated as a missing optional argument value. Modified the + effective overload set and overload resolution algorithms to + take this into account, as well as allowing an undefined + value passed as the argument value at the distinguishing index to select the overload + with an optional argument at that index. + Also removed [TreatUndefinedAs=Missing]. +* Changed the ECMAScript to IDL dictionary conversion algorithm + to treat a property with the value undefined + as missing. +* Removed the ability to put extended attributes after the + typedef keyword, as that feature is unused. +* Fixed the {{long long}} and {{unsigned long long}} + conversion algorithms to correctly identify the range of contiguous, + exactly, uniquely representable integers you can get from a Number. +* Clarified that Function objects for + operations and attribute getters and setters are distinct on each + interface they are mixed in to using an implements statement, + and that each copy of the Function works + only on objects that implement the interface whose interface + prototype object the Function object + is on. +* Mention the named properties object in the list of initial objects. +* Added back a custom \[[HasInstance]] on interface objects to allow objects + from other windows to be considered instanceof them. +* Fixed conversion of Number values + to {{any}} by using the + conversion algorithm for {{unrestricted double}}. +* Allowed an identifier to be “prototype” for any construct except + constants and static operations. +* Fixed a bug in the user object definition where the internal \[[Call]] + method would be treated as the implementation of an operation even if + the callback interface had more than one operation. +* Further tweaked the overload resolution algorithm and union type conversion + algorithm for consistency. +* Lifted the restriction on [Unforgeable] appearing + on an IDL attribute if another interface inherits from the one the attribute + is declared on, but required that the inheriting interface not have an + attribute with the same identifier. +* Made attribute setters throw if no argument was passed to them, instead of + assuming undefined. +* Prevented dictionaries from referencing themselves. +* Made sequences, arrays and dictionaries undistingishable again, thereby allowing + non-Array ECMAScript objects to be converted + to sequence and array types. +* Added a requirement to state what the values of an exception’s fields are + when throwing it. +* Changed the “length” property on Function + objects for IDL operations to return the smallest number of required arguments. +* Clarified that dictionaries may not be nullable when used as + the type of an operation argument or dictionary member. +* Specify the value of the “length” property on interface objects + that do not have constructors. +* Do not treat array index properties as named properties if an object supports + both indexed and named properties. +* Require that dictionary type arguments followed by optional arguments + must also be optional, and that such optional arguments always are + assumed to have a default value of an empty dictionary. Also disallow + dictionary types from being used inside nullable types and from being + considered distinguishable from nullable types. +* Always consider dictionary members with default values as present. +* Tweak [Clamp] algorithms for clarity. +* Require exception objects to have \[[Class]] “Error” and suggest that they + have any non-standard properties that native Error objects do. +* Fixed a bug in the whitespace token regular expression. +* Explicitly disallow dictionaries from being used inside union types + as the type of an attribute or exception field. +* Fixed a bug in the definition of distinguishability where a nullable + union type and a non-nullable union type that has a nullable member type + were considered distinguishable. +* Disallowed callback interfaces from being used in implements statements. +* Renamed “exception types” to “exception names”. +* Disallowed non-callback interfaces from inheriting from callback interfaces. +* Changed the algorithm for conversion from a platform object with indexed + properties to a sequence type to use its internal knowledge of the + set of property indexes rather than getting the "length" property, which + may not even exist. +* Added a warning to prefer the use of {{double}} + to {{float}}, unless there are good + reasons to choose the 32 bit type. +* Changed the restriction on operation argument default values + so that all optional arguments to the left of one with a + default value must also have default values. (Previously, + this was to the right.) + + + + + + + diff --git a/index.html b/index.html index d2075b17..42667e1c 100644 --- a/index.html +++ b/index.html @@ -1,16425 +1,16452 @@ - - - - - - - - Web IDL (Second Edition) - - - + + + + + Web IDL + + + + + + + + + + + +
+

+

Web IDL

+

Editor’s Draft,

+
+
+
This version: +
https://heycam.github.io/webidl/ +
Feedback: +
public-script-coord@w3.org with subject line “[WebIDL] … message topic …” (archives) +
Issue Tracking: +
GitHub +
Editors: +
Cameron McCormack (Mozilla Corporation) +
(Mozilla Corporation) +
Participate: +
GitHub (new issue, open issues, legacy bug tracker) +
+
+
+ +
+
+

Abstract

+
+

This document defines an interface definition language, Web IDL, + +that can be used to describe interfaces that are intended to be +implemented in web browsers. Web IDL is an IDL variant with a +number of features that allow the behavior of common script objects in +the web platform to be specified more readily. How interfaces +described with Web IDL correspond to constructs within ECMAScript +execution environments is also detailed in this document. +It is expected that this document acts +as a guide to implementors of already-published specifications, +and that newly published specifications reference this +document to ensure conforming implementations of interfaces +are interoperable.

+
+

Status of this document

+
+

This is a public copy of the editors’ draft. + It is provided for discussion only and may change at any moment. + Its publication here does not imply endorsement of its contents by W3C. + Don’t cite this document other than as work in progress.

+

Changes to this document may be tracked at https://github.com/heycam/webidl.

+

If you wish to make comments regarding this document, please send them to this specification’s GitHub repository or (archived) public mailing list public-script-coord@w3.org (see instructions). When sending e-mail, please put the text “WebIDL” in the subject, preferably like this: “[WebIDL] …summary of comment…. All comments are welcome.

+

This document was produced by the Web Platform Working Group.

+

This document was produced by a group operating under + the 5 February 2004 W3C Patent Policy. + W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; + that page also includes instructions for disclosing a patent. + An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

+

This document is governed by the 1 September 2015 W3C Process Document.

+

+
+
+ +
+

1. Introduction

+

This section is informative.

+

Technical reports published by the W3C that include programming +language interfaces have typically been described using the +Object Management Group’s Interface Definition Language (IDL) [OMGIDL]. The IDL provides a means to +describe these interfaces in a language independent manner. Usually, +additional language binding appendices are included in such +documents which detail how the interfaces described with the IDL +correspond to constructs in the given language.

+

However, the bindings in these specifications for the language most +commonly used on the web, ECMAScript, are consistently specified with +low enough precision as to result in interoperability issues. In +addition, each specification must describe the same basic information, +such as DOM interfaces described in IDL corresponding to properties +on the ECMAScript global object, or the unsigned long IDL type mapping to the Number type in ECMAScript.

+

This specification defines an IDL language similar to OMG IDL +for use by specifications that define interfaces for Web APIs. A number of extensions are +given to the IDL to support common functionality that previously must +have been written in prose. In addition, precise language bindings +for ECMAScript Edition 6 are given.

+

1.1. Typographic conventions

+

The following typographic conventions are used in this document:

+
    +
  • +

    Defining instances of terms: example term

    +
  • +

    Links to terms defined in this document or elsewhere: example term

    +
  • +

    Grammar terminals: sometoken

    +
  • +

    Grammar non-terminals: ExampleGrammarNonTerminal

    +
  • +

    Grammar symbols: identifier

    +
  • +

    IDL and ECMAScript types: ExampleType

    +
  • +

    Code snippets: a = b + obj.f()

    +
  • +

    Unicode characters: U+0030 DIGIT ZERO ("0")

    +
  • +

    Extended attributes: [ExampleExtendedAttribute]

    +
  • +

    Variable names in prose and algorithms: exampleVariableName.

    +
  • +

    Algorithms use the conventions of the ECMAScript specification, +including the ! and ? notation for unwrapping completion records.

    +
  • +

    IDL informal syntax examples:

    +
    interface identifier {
    +  /* interface_members... */
     };
    -
    -interface Pattern : Paint {
    -  attribute DOMString imageURL;
    +
    +

    (Specific parts of the syntax discussed in surrounding prose are highlighted.)

    +
  • +

    IDL grammar snippets:

    +
    ExampleGrammarNonTerminal :
    +    OtherNonTerminal "sometoken"
    +    other AnotherNonTerminal
    +    ε  // nothing
    +
    +
  • +

    Non-normative notes:

    +

    Note: This is a note.

    +
  • +

    Non-normative examples:

    +
    This is an example.
    +
  • +

    Normative warnings:

    +

    This is a warning.

    +
  • +

    Code blocks:

    +
    // This is an IDL code block.
    +interface Example {
    +  attribute long something;
     };
    -
    -[Constructor]
    -interface GraphicalWindow {
    -  readonly attribute unsigned long width;
    -  readonly attribute unsigned long height;
    -
    -  attribute Paint currentPaint;
    -
    -  void drawRectangle(double x, double y, double width, double height);
    -
    -  void drawText(double x, double y, DOMString text);
    -};
    -

    - Here, four interfaces - are being defined. - The GraphicalWindow interface has two - read only attributes, - one writable attribute, and two operations - defined on it. Objects that implement the GraphicalWindow interface - will expose these attributes and operations in a manner appropriate to the - particular language being used. -

    -

    - In ECMAScript, the attributes on the IDL interfaces will be exposed as accessor - properties and the operations as Function-valued - data properties on a prototype object for all GraphicalWindow - objects; each ECMAScript object that implements GraphicalWindow - will have that prototype object in its prototype chain. -

    - -

    - The [Constructor] that appears on GraphicalWindow - is an extended attribute. - This extended attribute causes a constructor to exist in ECMAScript implementations, - so that calling new GraphicalWindow() would return a new object - that implemented the interface. -

    - - -
    -

    3.1. Names

    - -

    - Every interface, - partial interface definition, - namespace, - partial namespace definition, - dictionary, - partial dictionary definition, - enumeration, - callback function and - typedef (together called named definitions) - and every constant, - attribute, - and dictionary member has an - identifier, as do some - operations. - The identifier is determined by an - identifier token somewhere - in the declaration: -

    -
      -
    • - For named definitions, - the identifier token that appears - directly after the interface, namespace, - dictionary, enum - or callback keyword - determines the identifier of that definition. -
      interface interface-identifier { interface-members… };
      -partial interface interface-identifier { interface-members… };
      -namespace namespace-identifier { namespace-members… };
      -partial namespace namespace-identifier { namespace-members… };
      -dictionary dictionary-identifier { dictionary-members… };
      -partial dictionary dictionary-identifier { dictionary-members… };
      -enum enumeration-identifier { enumeration-values… };
      -callback callback-identifier = callback-signature;
      -
    • -
    • - For attributes, - typedefs - and dictionary members, - the final identifier token before the - semicolon at the end of the declaration determines the identifier. -
      interface identifier {
      -  attribute type attribute-identifier;
      +
      +
      // This is an ECMAScript code block.
      +window.onload = function() { window.alert("loaded"); };
      +
    +

    2. Conformance

    +

    Everything in this specification is normative except for diagrams, +examples, notes and sections marked as being informative.

    +

    The keywords “must”, +“must not”, +“required”, +“shall”, +“shall not”, +“should”, +“should not”, +“recommended”, +“may” and +“optional” in this document are to be +interpreted as described in Key words for use in RFCs to +Indicate Requirement Levels [RFC2119].

    +

    The following conformance classes are defined by this specification:

    +
    +
    +

    conforming set of IDL fragments

    +
    +

    A set of IDL fragments is considered +to be a conforming set of IDL fragments if, taken together, they satisfy all of the +must-, +required- and shall-level +criteria in this specification that apply to IDL fragments.

    +
    +

    conforming implementation

    +
    +

    A user agent is considered to be a conforming implementation relative to a conforming set of IDL fragments if it satisfies all of the must-, +required- and shall-level +criteria in this specification that apply to implementations for all language +bindings that the user agent supports.

    +
    +

    conforming ECMAScript implementation

    +
    +

    A user agent is considered to be a conforming ECMAScript implementation relative to a conforming set of IDL fragments if it satisfies all of the must-, +required- and shall-level +criteria in this specification that apply to implementations for the ECMAScript +language binding.

    +
    +

    2.1. Conformant Algorithms

    +

    Requirements phrased in the imperative as part of algorithms (such as +“strip any leading space characters” or “return false and abort these +steps”) are to be interpreted with the meaning of the key word (“must”, +“should”, “may”, etc) used in introducing the algorithm.

    +

    Conformance requirements phrased as algorithms or specific steps can be +implemented in any manner, so long as the end result is equivalent. In +particular, the algorithms defined in this specification are intended to +be easy to understand and are not intended to be performant. Implementers +are encouraged to optimize.

    +

    3. Interface definition language

    +

    This section describes a language, Web IDL, which can be used to define +interfaces for APIs in the Web platform. A specification that defines Web APIs +can include one or more IDL fragments that +describe the interfaces (the state and behavior that objects can exhibit) +for the APIs defined by that specification. +An IDL fragment is +a sequence of definitions that matches the Definitions grammar symbol. +The set of IDL fragments that +an implementation supports is not ordered. +See IDL grammar for the complete grammar and an explanation of the notation used.

    +

    The different kinds of definitions that can appear in an IDL fragment are: interfaces, partial interface definitions, namespaces, partial namespace definitions, dictionaries, partial dictionary definitions, typedefs and implements statements. +These are all defined in the following sections.

    +

    Each definition (matching Definition) +can be preceded by a list of extended attributes (matching ExtendedAttributeList), +which can control how the definition will be handled in language bindings. +The extended attributes defined by this specification that are language binding +agnostic are discussed in §3.12 Extended attributes, +while those specific to the ECMAScript language binding are discussed +in §4.3 ECMAScript-specific extended attributes.

    +
    [extended_attributes]
    +interface identifier {
    +  /* interface_members... */
     };
    -
    -typedef type typedef-identifier;
    -
    -dictionary identifier {
    -  type dictionary-member-identifier;
    -};
    -
  • -
  • - For constants, - the identifier token before the - equals sign determines the identifier. -
    const type constant-identifier = value;
    -
  • -
  • - For operations, the - identifier token that appears - after the return type but before the opening parenthesis (that is, - one that is matched as part of the OptionalIdentifier - grammar symbol in an OperationRest) determines the identifier of the operation. If - there is no such identifier token, - then the operation does not have an identifier. -
    return-type operation-identifier(arguments…);
    -
  • -
-
Note
-

- Operations can have no identifier when they are being used to declare a - special kind of operation, such as a getter or setter. -

-
-

- For all of these constructs, the identifier - is the value of the identifier token with any leading - U+005F LOW LINE ("_") character (underscore) removed. -

-
Note
-

- A leading "_" is used to escape an identifier from looking - like a reserved word so that, for example, an interface named “interface” can be - defined. The leading "_" is dropped to unescape the - identifier. -

-
-

- Operation arguments can take a slightly wider set of identifiers. In an operation - declaration, the identifier of an argument is specified immediately after its - type and is given by either an identifier - token or by one of the keywords that match the ArgumentNameKeyword - symbol. If one of these keywords is used, it need not be escaped with a leading - underscore. -

-
return-type operation-identifier(argument-type argument-identifier, …);
-
[71]ArgumentNameKeyword - "attribute"
 | - "callback"
 | - "const"
 | - "deleter"
 | - "dictionary" -
 | - "enum"
 | - "getter"
 | - "implements"
 | - "inherit"
 | - "interface"
 | - "iterable" -
 | - "legacycaller"
 | - "maplike"
 | - "namespace"
 | - "partial"
 | - "required" -
 | - "serializer"
 | - "setlike"
 | - "setter"
 | - "static"
 | - "stringifier" -
 | - "typedef"
 | - "unrestricted" -
-

- If an identifier token is used, then the - identifier of the operation argument - is the value of that token with any leading - U+005F LOW LINE ("_") character (underscore) removed. - If instead one of the ArgumentNameKeyword - keyword token is used, then the identifier of the operation argument - is simply that token. -

-

- The identifier of any of the abovementioned - IDL constructs MUST NOT be “constructor”, - “toString”, “toJSON”, - or begin with a U+005F LOW LINE ("_") character. These - are known as reserved identifiers. -

-
Note
-

Further restrictions on identifier names for particular constructs may be made - in later sections.

-
-

- Within the set of IDL fragments - that a given implementation supports, - the identifier of every - interface, - namespace, - dictionary, - enumeration, - callback function and - typedef - MUST NOT - be the same as the identifier of any other - interface, - namespace, - dictionary, - enumeration, - callback function or - typedef. -

-

- Within an IDL fragment, a reference - to a definition need not appear after - the declaration of the referenced definition. References can also be made - across IDL fragments. -

-
Example
-

Therefore, the following IDL fragment is valid:

-
IDL
interface B : A {
-  void f(SequenceOfLongs x);
+
+
Definitions :
+    ExtendedAttributeList Definition Definitions
+    ε
+
+
Definition :
+    CallbackOrInterface
+    Namespace
+    Partial
+    Dictionary
+    Enum
+    Typedef
+    ImplementsStatement
+
+
CallbackOrInterface :
+    "callback" CallbackRestOrInterface
+    Interface
+
+
+ +

The following is an example of an IDL fragment.

+
interface Paint { };
+        
+interface SolidColor : Paint {
+  attribute double red;
+  attribute double green;
+  attribute double blue;
 };
-
-interface A {
+        
+interface Pattern : Paint {
+  attribute DOMString imageURL;
 };
-
-typedef sequence<long> SequenceOfLongs;
-
- -
Example
-

- The following IDL fragment - demonstrates how identifiers - are given to definitions and interface members. -

-
IDL
// Typedef identifier: "number"
-typedef double number;
-
-// Interface identifier: "System"
-interface System {
-
-  // Operation identifier:          "createObject"
-  // Operation argument identifier: "interface"
-  object createObject(DOMString _interface);
-
-  // Operation argument identifier: "interface"
-  sequence<object> getObjects(DOMString interface);
-
-  // Operation has no identifier; it declares a getter.
-  getter DOMString (DOMString keyName);
+        
+[Constructor]
+interface GraphicalWindow {
+  readonly attribute unsigned long width;
+  readonly attribute unsigned long height;
+        
+  attribute Paint currentPaint;
+        
+  void drawRectangle(double x, double y, double width, double height);
+        
+  void drawText(double x, double y, DOMString text);
 };
-
-// Interface identifier: "TextField"
-interface TextField {
-
-  // Attribute identifier: "const"
-  attribute boolean _const;
-
-  // Attribute identifier: "value"
-  attribute DOMString? _value;
-};
-

- Note that while the second attribute - on the TextField interface - need not have been escaped with an underscore (because “value” is - not a keyword in the IDL grammar), it is still unescaped - to obtain the attribute’s identifier. -

-
-
- -
-

3.2. Interfaces

- -

- IDL fragments are used to - describe object oriented systems. In such systems, objects are entities - that have identity and which are encapsulations of state and behavior. - An interface is a definition (matching - Interface or - "callback" Interface) that declares some - state and behavior that an object implementing that interface will expose. -

-
interface identifier {
-  interface-members…
-};
-

- An interface is a specification of a set of - interface members - (matching InterfaceMembers), - which are the constants, - attributes, - operations and - other declarations that appear between the braces in the interface declaration. - Attributes describe the state that an object - implementing the interface will expose, and operations describe the - behaviors that can be invoked on the object. Constants declare - named constant values that are exposed as a convenience to users - of objects in the system. -

-

- Interfaces in Web IDL describe how objects that implement the - interface behave. In bindings for object oriented languages, it is - expected that an object that implements a particular IDL interface - provides ways to inspect and modify the object's state and to - invoke the behavior described by the interface. -

- -

- An interface can be defined to inherit from another interface. - If the identifier of the interface is followed by a - U+003A COLON (":") character - and an identifier, - then that identifier identifies the inherited interface. - An object that implements an interface that inherits from another - also implements that inherited interface. The object therefore will also - have members that correspond to the interface members from the inherited interface. -

-
interface identifier : identifier-of-inherited-interface {
-  interface-members…
-};
-

- The order that members appear in has significance for property enumeration in the ECMAScript binding. -

-

- Interfaces may specify an interface member that has the same name as - one from an inherited interface. Objects that implement the derived - interface will expose the member on the derived interface. It is - language binding specific whether the overridden member can be - accessed on the object. -

-
Example
-

- Consider the following two interfaces. -

-
IDL
interface A {
-  void f();
-  void g();
+
+

Here, four interfaces are being defined. + The GraphicalWindow interface has two read only attributes, + one writable attribute, and two operations defined on it. Objects that implement the GraphicalWindow interface + will expose these attributes and operations in a manner appropriate to the + particular language being used.

+

In ECMAScript, the attributes on the IDL interfaces will be exposed as accessor + properties and the operations as Function-valued + data properties on a prototype object for all GraphicalWindow objects; each ECMAScript object that implements GraphicalWindow will have that prototype object in its prototype chain.

+

The [Constructor] that appears on GraphicalWindow is an extended attribute. + This extended attribute causes a constructor to exist in ECMAScript implementations, + so that calling new GraphicalWindow() would return a new object + that implemented the interface.

+
+

3.1. Names

+

Every interface, partial interface definition, namespace, partial namespace definition, dictionary, partial dictionary definition, enumeration, callback function and typedef (together called named definitions) +and every constant, attribute, +and dictionary member has an identifier, as do some operations. +The identifier is determined by an identifier token somewhere +in the declaration:

+
    +
  • +

    For named definitions, +the identifier token that appears +directly after the interface, namespace, dictionary, enum or callback keyword +determines the identifier of that definition.

    +
    interface interface_identifier { /* interface_members... */ };
    +partial interface interface_identifier { /* interface_members... */ };
    +namespace namespace_identifier { /* namespace_members... */ };
    +partial namespace namespace_identifier { /* namespace_members... */ };
    +dictionary dictionary_identifier { /* dictionary_members... */ };
    +partial dictionary dictionary_identifier { /* dictionary_members... */ };
    +enum enumeration_identifier { "enum", "values" /* , ... */ };
    +callback callback_identifier = return_type (/* arguments... */);
    +
    +
  • +

    For attributes, typedefs and dictionary members, +the final identifier token before the +semicolon at the end of the declaration determines the identifier.

    +
    interface identifier {
    +  attribute type attribute_identifier;
     };
    -
    -interface B : A {
    -  void f();
    -  void g(DOMString x);
    -};
-

- In the ECMAScript language binding, an instance of B - will have a prototype chain that looks like the following: -

-
  [Object.prototype: the Object prototype object]
-       ↑
-  [A.prototype: interface prototype object for A]
-       ↑
-  [B.prototype: interface prototype object for B]
-       ↑
-  [instanceOfB]
-

- Calling instanceOfB.f() in ECMAScript will invoke the f defined - on B. However, the f from A - can still be invoked on an object that implements B by - calling A.prototype.f.call(instanceOfB). -

- -
-

- The inherited interfaces of - a given interface A is the set of all interfaces that A - inherits from, directly or indirectly. If A does not inherit - from another interface, then the set is empty. Otherwise, the set - includes the interface B that A inherits - from and all of B’s inherited interfaces. -

-

- An interface MUST NOT be declared such that - its inheritance hierarchy has a cycle. That is, an interface - A cannot inherit from itself, nor can it inherit from another - interface B that inherits from A, and so on. -

-

- Note that general multiple inheritance of interfaces is not supported, and - objects also cannot implement arbitrary sets of interfaces. - Objects can be defined to implement a single given interface A, - which means that it also implements all of A’s - inherited interfaces. In addition, - an implements statement can be - used to define that objects implementing an interface will always - also implement another interface. -

-

- Each interface member can be preceded by a list of extended attributes (matching - ExtendedAttributeList), - which can control how the interface member will be handled in language bindings. -

-
interface identifier {
-
-  [extended-attributes]
-  const type identifier = value;
-
-  [extended-attributes]
-  attribute type identifier;
-
-  [extended-attributes]
-  return-type identifier(arguments…);
-};
- -

- A callback interface is - an interface - that uses the callback keyword at the start of - its definition. Callback interfaces are ones that can be - implemented by user objects - and not by platform objects, - as described in section 3.10 - below. -

-
callback interface identifier {
-  interface-members…
-};
-
Note
-

See also the similarly named callback function definition.

-
-

- Callback interfaces - MUST NOT inherit - from any non-callback interfaces, and non-callback interfaces MUST NOT - inherit from any callback interfaces. - Callback interfaces MUST NOT have any - consequential interfaces. -

-

- Static attributes and - static operations MUST NOT - be defined on a callback interface. -

-
Warning
-

- Specification authors SHOULD NOT define - callback interfaces - that have only a single operation, - unless required to describe the requirements of existing APIs. - Instead, a callback function SHOULD be used. -

-

- The definition of EventListener as a - callback interface - is an example of an existing API that needs to allow - user objects with a - given property (in this case “handleEvent”) to be considered to implement the interface. - For new APIs, and those for which there are no compatibility concerns, - using a callback function will allow - only a Function object (in the ECMAScript - language binding). -

-
-
Editorial note
-

- Perhaps this warning shouldn't apply if you are planning to extend the callback - interface in the future. That's probably a good reason to start off with a single - operation callback interface. -

-
-
Editorial note
-

- I think we need to support operations not being implemented on a given - user object implementing a callback interface. If specs extending an existing - callback interface, we probably want to be able to avoid calling the - operations that aren't implemented (and having some default behavior instead). - So we should perhaps define a term that means whether the operation is - implemented, which in the ECMAScript binding would correspond to checking - for the property's existence. -

-
- -
Note
-

- Specification authors wanting to define APIs that take ECMAScript objects - as “property bag” like function arguments are suggested to use - dictionary types rather than - callback interfaces. -

-

- For example, instead of this: -

-
IDL
callback interface Options {
-  attribute DOMString? option1;
-  attribute DOMString? option2;
-  attribute long? option3;
+        
+typedef type typedef_identifier;
+        
+dictionary identifier {
+  type dictionary_member_identifier;
 };
-
-interface A {
-  void doTask(DOMString type, Options options);
-};
-

- to be used like this: -

-
ECMAScript
var a = getA();  // Get an instance of A.
-
-a.doTask("something", { option1: "banana", option3: 100 });
-

- instead write the following: -

-
IDL
dictionary Options {
-  DOMString? option1;
-  DOMString? option2;
-  long? option3;
+
+
  • +

    For constants, +the identifier token before the +equals sign determines the identifier.

    +
    const type constant_identifier = 42;
    +
  • +

    For operations, the identifier token that appears +after the return type but before the opening parenthesis (that is, +one that is matched as part of the OptionalIdentifier grammar symbol in an OperationRest) determines the identifier of the operation. If +there is no such identifier token, +then the operation does not have an identifier.

    +
    interface interface_identifier {
    +  return_type operation_identifier(/* arguments... */);
     };
    -
    -interface A {
    -  void doTask(DOMString type, Options options);
    -};
  • -
    - -

    - The IDL for interfaces can be split into multiple parts by using - partial interface definitions - (matching "partial" PartialInterface). - The identifier of a partial - interface definition MUST be the same - as the identifier of an interface definition. All of - the members that appear on each of the partial interfaces are considered to be - members of the interface itself. -

    -
    interface SomeInterface {
    -  interface-members…
    +
    + +

    Note: Operations can have no identifier when they are being used to declare a special kind of operation, such as a getter or setter.

    +

    For all of these constructs, the identifier is the value of the identifier token with any leading U+005F LOW LINE ("_") character (underscore) removed.

    +

    Note: A leading "_" is used to escape an identifier from looking +like a reserved word so that, for example, an interface named “interface” can be +defined. The leading "_" is dropped to unescape the +identifier.

    +

    Operation arguments can take a slightly wider set of identifiers. In an operation +declaration, the identifier of an argument is specified immediately after its +type and is given by either an identifier token or by one of the keywords that match the ArgumentNameKeyword symbol. If one of these keywords is used, it need not be escaped with a leading +underscore.

    +
    interface interface_identifier {
    +  return_type operation_identifier(argument_type argument_identifier /* , ... */);
     };
    -
    -partial interface SomeInterface {
    -  interface-members…
    -};
    -
    Note
    -

    Partial interface definitions are intended for use as a specification - editorial aide, allowing the definition of an interface to be separated - over more than one section of the document, and sometimes multiple documents.

    -
    -

    - The order of appearance of an interface - definition and any of its partial interface - definitions does not matter. -

    -
    Note
    -

    A partial interface definition cannot specify that the interface - inherits from another interface. - Inheritance must be specified on the original interface - definition.

    -
    -

    - Extended attributes can be specified on - partial interface definitions, with some - limitations. The following extended attributes MUST NOT - be specified on partial interface definitions: - [Constructor], - [ImplicitThis], - - [LegacyArrayClass], - [NamedConstructor], - [NoInterfaceObject]. -

    -
    Note
    -

    The above list of extended attributes - is all of those defined in this document that are applicable to - interfaces except for - [Exposed], - [Global], - [OverrideBuiltins], - [PrimaryGlobal], - [SecureContext] and - [Unforgeable].

    -
    -

    - Any extended attribute specified - on a partial interface definition - is considered to appear on the interface - itself. -

    -

    - The relevant language binding determines how interfaces correspond to constructs - in the language. -

    - - -

    - The following extended attributes are applicable to interfaces: - [Constructor], - [Exposed], - [Global], - [ImplicitThis], - - [LegacyArrayClass], - [NamedConstructor], - [NoInterfaceObject], - [OverrideBuiltins], - [PrimaryGlobal], - [SecureContext], - [Unforgeable]. -

    - -
    [3]CallbackOrInterface"callback" CallbackRestOrInterface
     | - Interface
    [4]CallbackRestOrInterfaceCallbackRest
     | - Interface
    [5]Interface"interface" identifier Inheritance "{" InterfaceMembers "}" ";"
    [6]Partial"partial" PartialDefinition
    [7]PartialDefinitionPartialInterface
     | - PartialDictionary
     | - Namespace
    [8]PartialInterface"interface" identifier "{" InterfaceMembers "}" ";"
    [9]InterfaceMembersExtendedAttributeList InterfaceMember InterfaceMembers
     | - ε
    [10]InterfaceMemberConst
     | - Operation
     | - Serializer
     | - Stringifier
     | - StaticMember
     | - Iterable
     | - ReadOnlyMember
     | - ReadWriteAttribute
     | - ReadWriteMaplike
     | - ReadWriteSetlike
    [18]Inheritance":" identifier
     | - ε
    - -
    Example
    - -

    - The following IDL fragment - demonstrates the definition of two mutually referential interfaces. - Both Human and Dog - inherit from Animal. Objects that implement - either of those two interfaces will thus have a name attribute. -

    -
    IDL
    interface Animal {
    -  attribute DOMString name;
    +
    +
    ArgumentNameKeyword :
    +    "attribute"
    +    "callback"
    +    "const"
    +    "deleter"
    +    "dictionary"
    +    "enum"
    +    "getter"
    +    "implements"
    +    "inherit"
    +    "interface"
    +    "iterable"
    +    "legacycaller"
    +    "maplike"
    +    "namespace"
    +    "partial"
    +    "required"
    +    "serializer"
    +    "setlike"
    +    "setter"
    +    "static"
    +    "stringifier"
    +    "typedef"
    +    "unrestricted"
    +
    +

    If an identifier token is used, then the identifier of the operation argument +is the value of that token with any leading U+005F LOW LINE ("_") character (underscore) removed. +If instead one of the ArgumentNameKeyword keyword token is used, then the identifier of the operation argument +is simply that token.

    +

    The identifier of any of the abovementioned +IDL constructs must not be “constructor”, +“toString”, “toJSON”, +or begin with a U+005F LOW LINE ("_") character. These +are known as reserved identifiers.

    +

    Note: Further restrictions on identifier names for particular constructs may be made +in later sections.

    +

    Within the set of IDL fragments that a given implementation supports, +the identifier of every interface, namespace, dictionary, enumeration, callback function and typedef must not +be the same as the identifier of any other interface, namespace, dictionary, enumeration, callback function or typedef.

    +

    Within an IDL fragment, a reference +to a definition need not appear after +the declaration of the referenced definition. References can also be made +across IDL fragments.

    +
    + +

    Therefore, the following IDL fragment is valid:

    +
    interface B : A {
    +  void f(SequenceOfLongs x);
     };
    -
    -interface Human : Animal {
    -  attribute Dog? pet;
    +        
    +interface A {
     };
    -
    -interface Dog : Animal {
    -  attribute Human? owner;
    -};
    -
    - -
    Example
    -

    - The following IDL fragment defines - simplified versions of a few DOM interfaces, one of which - is a callback interface. -

    -
    IDL
    interface Node {
    -  readonly attribute DOMString nodeName;
    -  readonly attribute Node? parentNode;
    -  Node appendChild(Node newChild);
    -  void addEventListener(DOMString type, EventListener listener);
    +        
    +typedef sequence<long> SequenceOfLongs;
    +
    +
    +
    + +

    The following IDL fragment demonstrates how identifiers are given to definitions and interface members.

    +
    // Typedef identifier: "number"
    +typedef double number;
    +        
    +// Interface identifier: "System"
    +interface System {
    +        
    +  // Operation identifier:          "createObject"
    +  // Operation argument identifier: "interface"
    +  object createObject(DOMString _interface);
    +        
    +  // Operation argument identifier: "interface"
    +  sequence<object> getObjects(DOMString interface);
    +        
    +  // Operation has no identifier; it declares a getter.
    +  getter DOMString (DOMString keyName);
     };
    -
    -callback interface EventListener {
    -  void handleEvent(Event event);
    -};
    -

    - Since the EventListener interface is annotated - callback interface, user objects - can implement it: -

    -
    ECMAScript
    var node = getNode();                                // Obtain an instance of Node.
    -
    -var listener = {
    -  handleEvent: function(event) {
    -    ...
    -  }
    +        
    +// Interface identifier: "TextField"
    +interface TextField {
    +        
    +  // Attribute identifier: "const"
    +  attribute boolean _const;
    +        
    +  // Attribute identifier: "value"
    +  attribute DOMString? _value;
     };
    -node.addEventListener("click", listener);            // This works.
    -
    -node.addEventListener("click", function() { ... });  // As does this.
    -

    - It is not possible for a user object to implement Node, however: -

    -
    ECMAScript
    var node = getNode();  // Obtain an instance of Node.
    -
    -var newNode = {
    -  nodeName: "span",
    -  parentNode: null,
    -  appendChild: function(newchild) {
    -    ...
    -  },
    -  addEventListener: function(type, listener) {
    -    ...
    -  }
    +
    +

    Note that while the second attribute on the TextField interface need not have been escaped with an underscore (because “value” is + not a keyword in the IDL grammar), it is still unescaped + to obtain the attribute’s identifier.

    +
    +

    3.2. Interfaces

    +

    IDL fragments are used to +describe object oriented systems. In such systems, objects are entities +that have identity and which are encapsulations of state and behavior. +An interface is a definition (matching Interface or callback Interface) that declares some +state and behavior that an object implementing that interface will expose.

    +
    interface identifier {
    +  /* interface_members... */
     };
    -node.appendChild(newNode);  // This will throw a TypeError exception.
    -
    - -
    -

    3.2.1. Constants

    - -

    - A constant is a declaration (matching - Const) used to bind a constant value to a name. - Constants can appear on interfaces. -

    -
    Warning
    -

    - Constants have in the past primarily been used to define - named integer codes in the style of an enumeration. The Web platform - is moving away from this design pattern in favor of the use of strings. - Specification authors who wish to define constants are strongly advised to discuss - this on the public-script-coord@w3.org - mailing list before proceeding. -

    -
    -
    const type identifier = value;
    -

    - The identifier of a - constant - MUST NOT be the same as the identifier - of another interface member - defined on the same interface. - The identifier also MUST NOT - be “length”, “name” or “prototype”. -

    -
    Note
    -

    - These three names are the names of properties that exist on all - Function objects. -

    -
    -

    - The type of a constant (matching ConstType) - MUST NOT be any type other than - a primitive type - or a nullable primitive type. - If an identifier is used, - it MUST reference a typedef - whose type is a primitive type or a nullable primitive type. -

    -

    - The ConstValue part of a - constant declaration gives the value of the constant, which can be - one of the two boolean literal tokens (true - and false), - the null token, an - integer token, - a float token, - or one of the three special floating point constant values - (-Infinity, Infinity and NaN). -

    -
    Note
    -

    - These values – in addition to strings and the empty sequence – can also be used to specify the - default value - of a dictionary member or of - an optional argument. Note that strings and the - empty sequence [] cannot be used as the value of a - constant. -

    -
    -

    - The value of the boolean literal tokens true and - false are the IDL boolean values - true and false. -

    -

    - The value of an integer token is an integer - whose value is determined as follows: -

    -
      -
    1. Let S be the sequence of characters matched by the integer token.
    2. -
    3. Let sign be −1 if S begins with U+002D HYPHEN-MINUS ("-"), and 1 otherwise.
    4. -
    5. Let base be the base of the number based on the characters that follow the optional leading U+002D HYPHEN-MINUS ("-") character: -
      -
      U+0030 DIGIT ZERO ("0"), U+0058 LATIN CAPITAL LETTER X ("X")
      -
      U+0030 DIGIT ZERO ("0"), U+0078 LATIN SMALL LETTER X ("x")
      -
      The base is 16.
      -
      U+0030 DIGIT ZERO ("0")
      -
      The base is 8.
      -
      Otherwise
      -
      The base is 10.
      -
      -
    6. -
    7. Let number be the result of interpreting all remaining characters following the optional leading U+002D HYPHEN-MINUS ("-") - character and any characters indicating the base as an integer specified in base base.
    8. -
    9. Return sign × number.
    10. -
    -

    - The type of an integer token is the same - as the type of the constant, dictionary member or optional argument it is being used as the value of. - The value of the integer token MUST NOT - lie outside the valid range of values for its type, as given in - section 3.11 below. -

    -

    - The value of a float token is - either an IEEE 754 single-precision floating point number or an IEEE 754 - double-precision floating point number, depending on the type of the - constant, dictionary member or optional argument it is being used as the value for, determined as follows: -

    -
      -
    1. Let S be the sequence of characters matched by the float token.
    2. -
    3. Let value be the Mathematical Value that would be obtained if S were - parsed as an ECMAScript NumericLiteral ([ECMA-262], section 11.8.3).
    4. -
    5. - If the float token is being - used as the value for a float or - unrestricted float, then - the value of the float token - is the IEEE 754 single-precision floating point number closest to - result. Otherwise, the float token is being - used as the value for a double or - unrestricted double, and - the value of the float token - is the IEEE 754 double-precision floating point number closest to - result. - [IEEE-754] -
    6. -
    -

    - The value of a constant value specified as - Infinity, -Infinity or NaN is either - an IEEE 754 single-precision floating point number or an IEEE 754 - double-precision floating point number, depending on the type of the - constant, dictionary member or optional argument is is being used as the - value for: -

    -
    -
    Type unrestricted float, constant value Infinity
    -
    The value is the IEEE 754 single-precision positive infinity value.
    -
    Type unrestricted double, constant value Infinity
    -
    The value is the IEEE 754 double-precision positive infinity value.
    -
    Type unrestricted float, constant value -Infinity
    -
    The value is the IEEE 754 single-precision negative infinity value.
    -
    Type unrestricted double, constant value -Infinity
    -
    The value is the IEEE 754 double-precision negative infinity value.
    -
    Type unrestricted float, constant value NaN
    -
    The value is the IEEE 754 single-precision NaN value with the bit pattern 0x7fc00000.
    -
    Type unrestricted double, constant value NaN
    -
    The value is the IEEE 754 double-precision NaN value with the bit pattern 0x7ff8000000000000.
    -
    -

    - The type of a float token is the same - as the type of the constant, dictionary member or optional argument it is being used as the value of. The value of the - float token MUST NOT - lie outside the valid range of values for its type, as given in - section 3.11 below. - Also, Infinity, -Infinity and NaN MUST NOT - be used as the value of a float - or double. -

    -

    - The value of the null token is the special - null value that is a member of the - nullable types. The type of - the null token is the same as the - type of the constant, dictionary member or optional argument it is being used as the value of. -

    -

    - If VT is the type of the value assigned to a constant, and DT - is the type of the constant, dictionary member or optional argument itself, then these types MUST - be compatible, which is the case if DT and VT are identical, - or DT is a nullable type - whose inner type is VT. -

    -

    - Constants are not associated with - particular instances of the interface - on which they appear. It is language binding specific whether - constants are exposed on instances. -

    -
    Note
    -

    - - The ECMAScript language binding does however - allow constants to be accessed - through objects implementing the IDL interfaces - on which the constants are declared. - For example, with the following IDL: -

    -
    IDL
    interface A {
    -  const short rambaldi = 47;
    -};
    -

    - the constant value can be accessed in ECMAScript either as - A.rambaldi or instanceOfA.rambaldi. -

    -
    -

    - The following extended attributes are applicable to constants: - [Exposed], - [SecureContext]. -

    - -
    [26]Const"const" ConstType identifier "=" ConstValue ";"
    [27]ConstValueBooleanLiteral
     | - FloatLiteral
     | - integer
     | - "null"
    [28]BooleanLiteral"true"
     | - "false"
    [29]FloatLiteralfloat
     | - "-Infinity"
     | - "Infinity"
     | - "NaN"
    [80]ConstTypePrimitiveType Null
     | - identifier Null
    -
    Example
    -

    - The following IDL fragment - demonstrates how constants - of the above types can be defined. -

    -
    IDL
    interface Util {
    -  const boolean DEBUG = false;
    -  const octet LF = 10;
    -  const unsigned long BIT_MASK = 0x0000fc00;
    -  const double AVOGADRO = 6.022e23;
    -};
    -
    -
    - -
    -

    3.2.2. Attributes

    - -

    - An attribute is an interface member - (matching - "inherit" ReadOnly AttributeRest, - "static" ReadOnly AttributeRest, - "stringifier" ReadOnly AttributeRest, - or ReadOnly AttributeRest) - that is used to declare data fields with a given type and - identifier whose value can - be retrieved and (in some cases) changed. There are two kinds of attributes: -

    -
      -
    1. regular attributes, which are those - used to declare that objects implementing the interface - will have a data field member with the given identifier -
      attribute type identifier;
    2. -
    3. static attributes, which are used - to declare attributes that are not associated with a particular object implementing the interface -
      static attribute type identifier;
    4. -
    -

    - If an attribute has no static keyword, then it declares a - regular attribute. Otherwise, - it declares a static attribute. -

    -

    - The identifier of an - attribute - MUST NOT be the same as the identifier - of another interface member - defined on the same interface. - The identifier of a static attribute MUST NOT - be “prototype”. -

    -

    - The type of the attribute is given by the type (matching Type) - that appears after the attribute keyword. - If the Type is an - identifier or an identifier followed by ?, - then the identifier MUST - identify an interface, enumeration, - callback function or typedef. -

    -

    - The type of the attribute, after resolving typedefs, MUST NOT be a - nullable or non-nullable version of any of the following types: -

    - -

    - The attribute is read only if the - readonly keyword is used before the attribute keyword. - An object that implements the interface on which a read only attribute - is defined will not allow assignment to that attribute. It is language - binding specific whether assignment is simply disallowed by the language, - ignored or an exception is thrown. -

    -
    readonly attribute type identifier;
    -

    - A regular attribute - that is not read only - can be declared to inherit its getter - from an ancestor interface. This can be used to make a read only attribute - in an ancestor interface be writable on a derived interface. An attribute - inherits its getter if - its declaration includes inherit in the declaration. - The read only attribute from which the attribute inherits its getter - is the attribute with the same identifier on the closest ancestor interface - of the one on which the inheriting attribute is defined. The attribute - whose getter is being inherited MUST be - of the same type as the inheriting attribute, and inherit - MUST NOT appear on a read only - attribute or a static attribute. -

    -
    interface Ancestor {
    -  readonly attribute TheType theIdentifier;
    +
    +

    An interface is a specification of a set of interface members (matching InterfaceMembers), +which are the constants, attributes, operations and +other declarations that appear between the braces in the interface declaration. +Attributes describe the state that an object +implementing the interface will expose, and operations describe the +behaviors that can be invoked on the object. Constants declare +named constant values that are exposed as a convenience to users +of objects in the system.

    +

    Interfaces in Web IDL describe how objects that implement the +interface behave. In bindings for object oriented languages, it is +expected that an object that implements a particular IDL interface +provides ways to inspect and modify the object’s state and to +invoke the behavior described by the interface.

    +

    An interface can be defined to inherit from another interface. +If the identifier of the interface is followed by a U+003A COLON (":") character +and an identifier, +then that identifier identifies the inherited interface. +An object that implements an interface that inherits from another +also implements that inherited interface. The object therefore will also +have members that correspond to the interface members from the inherited interface.

    +
    interface identifier : identifier_of_inherited_interface {
    +  /* interface_members... */
     };
    -
    -interface Derived : Ancestor {
    -  inherit attribute TheType theIdentifier;
    -};
    - -

    - When the stringifier keyword is used - in a regular attribute - declaration, it indicates that objects implementing the - interface will be stringified to the value of the attribute. See - section 3.2.4.2 - below for details. -

    -
    stringifier attribute DOMString identifier;
    -

    - If an implementation attempts to get or set the value of an - attribute on a - user object - (for example, when a callback object has been supplied to the implementation), - and that attempt results in an exception being thrown, then, unless otherwise specified, that - exception will be propagated to the user code that caused the - implementation to access the attribute. Similarly, if a value - returned from getting the attribute cannot be converted to - an IDL type, then any exception resulting from this will also - be propagated to the user code that resulted in the implementation - attempting to get the value of the attribute. -

    - -

    - The following extended attributes - are applicable to regular and static attributes: - [Clamp], - [EnforceRange], - [Exposed], - [SameObject], - [SecureContext], - [TreatNullAs]. -

    - -

    - The following extended attributes - are applicable only to regular attributes: - [LenientSetter], - [LenientThis], - [PutForwards], - [Replaceable], - [Unforgeable]. -

    - -
    [39]ReadOnlyMember"readonly" ReadOnlyMemberRest
    [40]ReadOnlyMemberRestAttributeRest
     | - ReadWriteMaplike
     | - ReadWriteSetlike
    [41]ReadWriteAttribute"inherit" ReadOnly AttributeRest
     | - AttributeRest
    [42]AttributeRest"attribute" Type AttributeName ";"
    [43]AttributeNameAttributeNameKeyword
     | - identifier
    [44]AttributeNameKeyword"required"
    [45]Inherit"inherit"
     | - ε
    [46]ReadOnly"readonly"
     | - ε
    - -
    Example
    -

    - The following IDL fragment - demonstrates how attributes - can be declared on an interface: -

    -
    IDL
    interface Animal {
    -
    -  // A simple attribute that can be set to any string value.
    -  readonly attribute DOMString name;
    -
    -  // An attribute whose value can be assigned to.
    -  attribute unsigned short age;
    +        
    +interface B : A {
    +  void f();
    +  void g(DOMString x);
     };
    -
    -interface Person : Animal {
    -
    -  // An attribute whose getter behavior is inherited from Animal, and need not be
    -  // specified in the description of Person.
    -  inherit attribute DOMString name;
    -};
    -
    -
    - -
    -

    3.2.3. Operations

    - -

    - An operation is an interface member - (matching "static" OperationRest, - "stringifier" OperationRest, - "serializer" OperationRest, - ReturnType OperationRest or - SpecialOperation) - that defines a behavior that can be invoked on objects implementing the interface. - There are three kinds of operation: -

    -
      -
    1. regular operations, which - are those used to declare that objects implementing the - interface will have a method with - the given identifier -
      return-type identifier(arguments…);
    2. -
    3. special operations, - which are used to declare special behavior on objects - implementing the interface, such as object indexing and stringification -
      special-keywords… return-type identifier(arguments…);
      -special-keywords… return-type (arguments…);
    4. -
    5. static operations, - which are used to declare operations that are not associated with - a particular object implementing the interface -
      static return-type identifier(arguments…);
    6. -
    -

    - If an operation has an identifier but no static - keyword, then it declares a regular operation. - If the operation has one or more - special keywords - used in its declaration (that is, any keyword matching - Special, or - the stringifier keyword), - then it declares a special operation. A single operation can declare - both a regular operation and a special operation; see - section 3.2.4 below - for details on special operations. Note that in addition to being interface members, regular operations can also be namespace members. -

    -

    - If an operation has no identifier, - then it MUST - be declared to be a special operation using one of the - special keywords. -

    -

    - The identifier of a - regular operation - or static operation - MUST NOT be the same as the identifier - of a constant or - attribute - defined on the same interface. - The identifier of a static operation MUST NOT - be “prototype”. -

    -
    Note
    -

    - The identifier can be the same as that of another operation on the - interface, however. This is how operation overloading is specified. -

    -
    -

    - The identifier of a static operation - also MUST NOT be the same as the identifier - of a regular operation - defined on the same interface. -

    -

    - The return type of the operation is given - by the type (matching ReturnType) - that appears before the operation’s optional identifier. - A return type of void indicates that the operation returns no value. - If the return type is an - identifier followed by ?, - then the identifier MUST - identify an interface, dictionary, enumeration, - callback function or typedef. -

    -

    - An operation’s arguments (matching ArgumentList) - are given between the parentheses in the declaration. Each individual argument is specified - as a type (matching Type) followed by an identifier - (matching ArgumentName). -

    -
    Note
    -

    For expressiveness, the identifier of an operation argument can also be specified - as one of the keywords matching the ArgumentNameKeyword - symbol without needing to escape it.

    -
    -

    - If the Type of an operation argument is an identifier - followed by ?, - then the identifier MUST identify an interface, - enumeration, callback function - or typedef. - If the operation argument type is an identifier - not followed by ?, then the identifier MUST - identify any one of those definitions or a dictionary. -

    -
    return-type identifier(type identifier, type identifier, …);
    -

    - The identifier of each argument MUST NOT be the same - as the identifier of another argument in the same operation declaration. -

    -

    - Each argument can be preceded by a list of - extended attributes (matching - ExtendedAttributeList), - which can control how a value passed as the argument will be handled in - language bindings. -

    -
    return-type identifier([extended-attributes] type identifier, [extended-attributes] type identifier, …);
    - -
    Example
    -

    - The following IDL fragment - demonstrates how regular operations - can be declared on an interface: -

    -
    IDL
    interface Dimensions {
    -  attribute unsigned long width;
    -  attribute unsigned long height;
    +
    +

    In the ECMAScript language binding, an instance of B will have a prototype chain that looks like the following:

    +
    [Object.prototype: the Object prototype object]
    +     ↑
    +[A.prototype: interface prototype object for A]
    +     ↑
    +[B.prototype: interface prototype object for B]
    +     ↑
    +[instanceOfB]
    +
    +

    Calling instanceOfB.f() in ECMAScript will invoke the f defined + on B. However, the f from A can still be invoked on an object that implements B by + calling A.prototype.f.call(instanceOfB).

    +
    +

    The inherited interfaces of +a given interface A is the set of all interfaces that A inherits from, directly or indirectly. If A does not inherit from another interface, then the set is empty. Otherwise, the set +includes the interface B that A inherits from and all of B’s inherited interfaces.

    +

    An interface must not be declared such that +its inheritance hierarchy has a cycle. That is, an interface A cannot inherit from itself, nor can it inherit from another +interface B that inherits from A, and so on.

    +

    Note that general multiple inheritance of interfaces is not supported, and +objects also cannot implement arbitrary sets of interfaces. +Objects can be defined to implement a single given interface A, +which means that it also implements all of A’s inherited interfaces. In addition, +an implements statement can be +used to define that objects implementing an interface will always +also implement another interface.

    +

    Each interface member can be preceded by a list of extended attributes (matching ExtendedAttributeList), +which can control how the interface member will be handled in language bindings.

    +
    interface identifier {
    +    
    +  [extended_attributes]
    +  const type constant_identifier = 42;
    +    
    +  [extended_attributes]
    +  attribute type identifier;
    +    
    +  [extended_attributes]
    +  return_type identifier(/* arguments... */);
     };
    -
    -interface Button {
    -
    -  // An operation that takes no arguments and returns a boolean.
    -  boolean isMouseOver();
    -
    -  // Overloaded operations.
    -  void setDimensions(Dimensions size);
    -  void setDimensions(unsigned long width, unsigned long height);
    -};
    -
    - -

    - An operation is considered to be variadic - if the final argument uses the ... token just - after the argument type. Declaring an operation to be variadic indicates that - the operation can be invoked with any number of arguments after that final argument. - Those extra implied formal arguments are of the same type as the final explicit - argument in the operation declaration. The final argument can also be omitted - when invoking the operation. An argument MUST NOT - be declared with the ... token unless it - is the final argument in the operation’s argument list. -

    -
    return-type identifier(type... identifier);
    -return-type identifier(type identifier, type... identifier);
    -

    - Extended attributes - that take an argument list - ([Constructor] and - [NamedConstructor], of those - defined in this specification) and callback functions - are also considered to be variadic - when the ... token is used in their argument lists. -

    - -
    Example
    -

    - The following IDL fragment defines an interface that has - two variadic operations: -

    -
    IDL
    interface IntegerSet {
    -  readonly attribute unsigned long cardinality;
    -
    -  void union(long... ints);
    -  void intersection(long... ints);
    -};
    -

    - In the ECMAScript binding, variadic operations are implemented by - functions that can accept the subsequent arguments: -

    -
    ECMAScript
    var s = getIntegerSet();  // Obtain an instance of IntegerSet.
    -
    -s.union();                // Passing no arguments corresponding to 'ints'.
    -s.union(1, 4, 7);         // Passing three arguments corresponding to 'ints'.
    -

    - A binding for a language that does not support variadic functions - might specify that an explicit array or list of integers be passed - to such an operation. -

    -
    - -

    - An argument is considered to be an optional argument - if it is declared with the optional keyword. - The final argument of a variadic operation - is also considered to be an optional argument. Declaring an argument - to be optional indicates that the argument value can be omitted - when the operation is invoked. The final argument in an - operation MUST NOT explicitly be declared to be - optional if the operation is variadic. -

    -
    return-type identifier(type identifier, optional type identifier);
    - -

    - Optional arguments can also have a default value - specified. If the argument’s identifier is followed by a U+003D EQUALS SIGN ("=") - and a value (matching DefaultValue), - then that gives the optional argument its default value. - The implicitly optional final argument of a variadic - operation MUST NOT have a default value specified. - The default value is the value to be assumed when the operation is called with the - corresponding argument omitted. -

    -
    return-type identifier(type identifier, optional type identifier = value);
    -
    Warning
    -

    - It is strongly suggested not to use default value - of true for boolean-typed arguments, - as this can be confusing for authors who might otherwise expect the default - conversion of undefined to be used (i.e., false). -

    -
    -

    - If the type of an argument is a dictionary type - or a union type that has a - dictionary type as one of its flattened member types, - and that dictionary type and its ancestors have no required members, - and the argument is either the final argument or is followed only by - optional arguments, then - the argument MUST be specified as optional. - Such arguments are always considered to have a - default value of an empty dictionary, - unless otherwise specified. -

    -
    Note
    -

    - This is to encourage API designs that do not require authors to pass an - empty dictionary value when they wish only to use the dictionary’s - default values. -

    -

    - Dictionary types cannot have a default value specified explicitly, so the - “unless otherwise specified” clause above can only be invoked for - a union type that has a - dictionary type as one of its flattened member types. -

    -
    -

    - When a boolean literal token (true or false), - the null token, - an integer token, a - float token or one of - the three special floating point literal values (Infinity, - -Infinity or NaN) is used as the - default value, - it is interpreted in the same way as for a constant. -

    -

    - Optional argument default values can also be specified using a string - token, whose value is a string type - determined as follows: -

    -
      -
    1. Let S be the sequence of Unicode scalar values matched by the string token with its leading and trailing U+0022 QUOTATION MARK ('"') characters removed.
    2. -
    3. Depending on the type of the argument: -
      -
      DOMString
      -
      an enumeration type
      -
      The value of the string token is the sequence of 16 bit unsigned integer code units (hereafter referred to just as code units) corresponding to the UTF-16 encoding of S.
      -
      ByteString
      -
      The value of the string token is the sequence of 8 bit unsigned integer code units corresponding to the UTF-8 encoding of S.
      -
      USVString
      -
      The value of the string token is S.
      -
      -
    4. -
    -

    - If the type of the optional argument - is an enumeration, then its - default value if specified MUST - be one of the enumeration’s values. -

    -

    - Optional argument default values can also be specified using the - two token value [], which represents an empty sequence - value. The type of this value is the same the type of the optional - argument it is being used as the default value of. That type - MUST be a - sequence type or a - nullable type. -

    - -
    Example
    -

    - The following IDL fragment - defines an interface - with a single operation - that can be invoked with two different argument list lengths: -

    -
    IDL
    interface ColorCreator {
    -  object createColor(double v1, double v2, double v3, optional double alpha);
    -};
    -

    - It is equivalent to an interface - that has two overloaded - operations: -

    -
    IDL
    interface ColorCreator {
    -  object createColor(double v1, double v2, double v3);
    -  object createColor(double v1, double v2, double v3, double alpha);
    -};
    -
    - - -

    - If an implementation attempts to invoke an - operation on a - user object (for example, when a callback object - has been supplied to the implementation), and that attempt results in an - exception being thrown, then, unless otherwise specified, that - exception will be propagated to the user code that caused the - implementation to invoke the operation. Similarly, if a value - returned from invoking the operation cannot be converted to - an IDL type, then any exception resulting from this will also - be propagated to the user code that resulted in the implementation - attempting to invoke the operation. -

    - -

    - The following extended attributes - are applicable to operations: - [Exposed], - [NewObject], - [SecureContext], - [TreatNullAs], - [Unforgeable]. -

    -

    - The following extended attributes are applicable to operation arguments: - [Clamp], - [EnforceRange], - [TreatNullAs]. -

    - -
    [17]DefaultValueConstValue
     | - string
     | - "[" "]"
    [47]OperationReturnType OperationRest
     | - SpecialOperation
    [48]SpecialOperationSpecial Specials ReturnType OperationRest
    [49]SpecialsSpecial Specials
     | - ε
    [50]Special"getter"
     | - "setter"
     | - "deleter"
     | - "legacycaller"
    [51]OperationRestOptionalIdentifier "(" ArgumentList ")" ";"
    [52]OptionalIdentifieridentifier
     | - ε
    [53]ArgumentListArgument Arguments
     | - ε
    [54]Arguments"," Argument Arguments
     | - ε
    [55]ArgumentExtendedAttributeList OptionalOrRequiredArgument
    [56]OptionalOrRequiredArgument"optional" Type ArgumentName Default
     | - Type Ellipsis ArgumentName
    [57]ArgumentNameArgumentNameKeyword
     | - identifier
    [58]Ellipsis"..."
     | - ε
    [71]ArgumentNameKeyword - "attribute"
     | - "callback"
     | - "const"
     | - "deleter"
     | - "dictionary" -
     | - "enum"
     | - "getter"
     | - "implements"
     | - "inherit"
     | - "interface"
     | - "iterable" -
     | - "legacycaller"
     | - "maplike"
     | - "namespace"
     | - "partial"
     | - "required" -
     | - "serializer"
     | - "setlike"
     | - "setter"
     | - "static"
     | - "stringifier" -
     | - "typedef"
     | - "unrestricted" -
    [89]ReturnTypeType
     | - "void"
    - - -
    -

    3.2.4. Special operations

    - -

    - A special operation is a - declaration of a certain kind of special behavior on objects implementing - the interface on which the special operation declarations appear. - Special operations are declared by using one or more - special keywords - in an operation declaration. -

    -

    - There are six kinds of special operations. The table below indicates - for a given kind of special operation what special keyword - is used to declare it and what the purpose of the special operation is: -

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Special operationKeywordPurpose
    GettersgetterDefines behavior for when an object is indexed for property retrieval.
    SetterssetterDefines behavior for when an object is indexed for property - assignment or creation.
    DeletersdeleterDefines behavior for when an object is indexed for property deletion.
    Legacy callerslegacycallerDefines behavior for when an object is called as if it were a function.
    StringifiersstringifierDefines how an object is converted into a DOMString.
    SerializersserializerDefines how an object is converted into a serialized form.
    -

    - Not all language bindings support all of the six kinds of special - object behavior. When special operations are declared using - operations with no identifier, then in language bindings that do - not support the particular kind of special operations there simply - will not be such functionality. -

    -
    Example
    -

    The following IDL fragment defines an interface with a getter and a setter:

    -
    IDL
    interface Dictionary {
    -  readonly attribute unsigned long propertyCount;
    -
    -  getter double (DOMString propertyName);
    -  setter void (DOMString propertyName, double propertyValue);
    -};
    -

    In language bindings that do not support property getters and setters, - objects implementing Dictionary will not - have that special behavior.

    -
    - -

    - Defining a special operation with an identifier - is equivalent to separating the special operation out into its own - declaration without an identifier. This approach is allowed to - simplify prose descriptions of an interface’s operations. -

    -
    Example
    -

    The following two interfaces are equivalent:

    -
    IDL
    interface Dictionary {
    -  readonly attribute unsigned long propertyCount;
    -
    -  getter double getProperty(DOMString propertyName);
    -  setter void setProperty(DOMString propertyName, double propertyValue);
    -};
    -
    IDL
    interface Dictionary {
    -  readonly attribute unsigned long propertyCount;
    -
    -  double getProperty(DOMString propertyName);
    -  void setProperty(DOMString propertyName, double propertyValue);
    -
    -  getter double (DOMString propertyName);
    -  setter void (DOMString propertyName, double propertyValue);
    -};
    -
    - -

    - A given special keyword MUST NOT - appear twice on an operation. -

    -

    - Getters and setters come in two varieties: ones that - take a DOMString as a property name, - known as - named property getters and - named property setters, - and ones that take an unsigned long - as a property index, known as - indexed property getters and - indexed property setters. - There is only one variety of deleter: - named property deleters. - See section 3.2.4.4 - and section 3.2.4.5 - for details. -

    -

    - On a given interface, - there MUST exist at most one - stringifier, at most one serializer, at most one - named property deleter, - and at most one of each variety of getter and setter. - Multiple legacy callers can exist on an interface - to specify overloaded calling behavior. -

    -

    - If an interface has a setter of a given variety, - then it MUST also have a getter of that - variety. If it has a named property deleter, - then it MUST also have a - named property getter. -

    -

    - Special operations declared using operations MUST NOT - be variadic nor have any - optional arguments. -

    -

    - Special operations MUST NOT be declared on - callback interfaces. -

    -

    - If an object implements more than one interface - that defines a given special operation, then it is undefined which (if any) - special operation is invoked for that operation. -

    - -
    -
    3.2.4.1. Legacy callers
    - -

    - When an interface has one or more - legacy callers, it indicates that objects that implement - the interface can be called as if they were functions. As mentioned above, - legacy callers can be specified using an operation - declared with the legacycaller keyword. -

    -
    legacycaller return-type identifier(arguments…);
    -legacycaller return-type (arguments…);
    -

    - If multiple legacy callers are specified on an interface, overload resolution - is used to determine which legacy caller is invoked when the object is called - as if it were a function. -

    -

    - Legacy callers MUST NOT be defined to return a - promise type. -

    -
    Warning
    -

    - Legacy callers are universally recognised as an undesirable feature. They exist - only so that legacy Web platform features can be specified. Legacy callers - SHOULD NOT be used in specifications unless required to - specify the behavior of legacy APIs, and even then this should be discussed on - the public-script-coord@w3.org - mailing list before proceeding. -

    -
    - -
    Example
    -

    - The following IDL fragment - defines an interface - with a legacy caller. -

    -
    IDL
    interface NumberQuadrupler {
    -  // This operation simply returns four times the given number x.
    -  legacycaller double compute(double x);
    -};
    -

    - An ECMAScript implementation supporting this interface would - allow a platform object - that implements NumberQuadrupler - to be called as a function: -

    -
    ECMAScript
    var f = getNumberQuadrupler();  // Obtain an instance of NumberQuadrupler.
    -
    -f.compute(3);                   // This evaluates to 12.
    -f(3);                           // This also evaluates to 12.
    -
    -
    - -
    -
    3.2.4.2. Stringifiers
    - -

    - When an interface has a - stringifier, it indicates that objects that implement - the interface have a non-default conversion to a string. As mentioned above, - stringifiers can be specified using an operation - declared with the stringifier keyword. -

    -
    stringifier DOMString identifier();
    -stringifier DOMString ();
    -

    - If an operation used to declare a stringifier does not have an - identifier, then prose - accompanying the interface MUST define - the stringification behavior - of the interface. If the operation does have an identifier, - then the object is converted to a string by invoking the - operation to obtain the string. -

    -

    - Stringifiers declared with operations MUST - be declared to take zero arguments and return a DOMString. -

    -

    - As a shorthand, if the stringifier keyword - is declared using an operation with no identifier, then the - operation’s return type and - argument list can be omitted. -

    -
    stringifier;
    -
    Example
    -

    The following two interfaces are equivalent:

    -
    IDL
    interface A {
    -  stringifier DOMString ();
    -};
    -
    IDL
    interface A {
    -  stringifier;
    -};
    -
    -

    - The stringifier keyword - can also be placed on an attribute. - In this case, the string to convert the object to is the - value of the attribute. The stringifier keyword - MUST NOT be placed on an attribute unless - it is declared to be of type DOMString or USVString. - It also MUST NOT be placed on - a static attribute. -

    -
    stringifier attribute DOMString identifier;
    - -
    [35]Stringifier"stringifier" StringifierRest
    [36]StringifierRestReadOnly AttributeRest
     | - ReturnType OperationRest
     | - ";"
    - -
    Example
    -

    - The following IDL fragment - defines an interface that will stringify to the value of its - name attribute: -

    -
    IDL
    [Constructor]
    -interface Student {
    -  attribute unsigned long id;
    -  stringifier attribute DOMString name;
    -};
    -

    - In the ECMAScript binding, using a Student - object in a context where a string is expected will result in the - value of the object’s “name” property being - used: -

    -
    ECMAScript
    var s = new Student();
    -s.id = 12345678;
    -s.name = '周杰倫';
    -
    -var greeting = 'Hello, ' + s + '!';  // Now greeting == 'Hello, 周杰倫!'.
    -

    - The following IDL fragment - defines an interface that has custom stringification behavior that is - not specified in the IDL itself. -

    -
    IDL
    [Constructor]
    -interface Student {
    -  attribute unsigned long id;
    -  attribute DOMString? familyName;
    -  attribute DOMString givenName;
    -
    -  stringifier DOMString ();
    -};
    -

    - Thus, prose is required to explain the stringification behavior, such - as the following paragraph: -

    -
    -

    - Objects that implement the Student - interface must stringify as follows. If the value of the - familyName attribute is - null, the stringification of the - object is the value of the givenName - attribute. Otherwise, if the value of the - familyName attribute is not null, - the stringification of the object is the concatenation of the - value of the givenName attribute, - a single space character, and the value of - the familyName attribute. -

    -
    -

    - An ECMAScript implementation of the IDL would behave as follows: -

    -
    ECMAScript
    var s = new Student();
    -s.id = 12345679;
    -s.familyName = 'Smithee';
    -s.givenName = 'Alan';
    -
    -var greeting = 'Hi ' + s;  // Now greeting == 'Hi Alan Smithee'.
    -
    -
    - -
    -
    3.2.4.3. Serializers
    - -

    - When an interface has a - serializer, it indicates that objects provide - a way for them to be converted into a serialized form. Serializers can be declared - using the serializer keyword: -

    -
    serializer;
    -

    - Prose accompanying an interface that declares a serializer in this - way MUST define the - serialization behavior - of the interface. Serialization behavior is defined as returning - a serialized value of one of the following types: -

    - -

    - How the serialization behavior - is made available on an object in a language binding, and how exactly the abstract - serialized value is converted into - an appropriate concrete value, is language binding specific. -

    -
    Note
    -

    In the ECMAScript language binding, - serialization behavior - is exposed as a toJSON method which returns the - serialized value converted - into an ECMAScript value that can be serialized to JSON by the - JSON.stringify function. See section 4.6.7.2 - below for details.

    -
    -

    - Serialization behavior - can also be specified directly in IDL, rather than separately as prose. - This is done by following the serializer keyword with - a U+003D EQUALS SIGN ("=") character and - a serialization pattern, - which can take one of the following six forms: -

    -
      -
    • -

      A map with entries corresponding to zero or more attributes from the interface, and optionally - attributes from an inherited interface:

      -
      serializer = { attribute-identifier, attribute-identifier, … };
      -serializer = { inherit, attribute-identifier, attribute-identifier, … };
      -

      Each identifier MUST be the identifier of an attribute declared - on the interface. The identified attributes all MUST have a - serializable type.

      -

      The inherit keyword MUST NOT be used unless - the interface inherits from another that defines a serializer, and the closest such interface - defines its serializer using this serialization pattern - form or the following form (i.e. { attribute }).

      -

      The serialization behavior for this - form of serialization pattern is as follows:

      -
        -
      1. Let map be an empty map.
      2. -
      3. If the inherit keyword was used, then set map to be the result of - the serialization behavior of the - closest inherited interface that declares a serializer.
      4. -
      5. For each attribute identifier i in the serialization pattern, in order: -
          -
        1. Remove any entry in map with key name i.
        2. -
        3. Let V be the value of the attribute with identifier i.
        4. -
        5. Add an entry to map whose key name is i and whose - value is result of converting - V to a serialized value.
        6. -
        -
      6. -
      7. Return map.
      8. -
      -
    • -
    • -

      A map with entries corresponding to all attributes from the interface that have - a serializable type, and optionally - attributes from an inherited interface:

      -
      serializer = { attribute };
      -serializer = { inherit, attribute };
      -

      The inherit keyword MUST NOT be used unless - the interface inherits from another that defines a serializer, and the closest such interface - defines its serializer using this serialization pattern - form or the previous form.

      -

      The serialization behavior for this - form of serialization pattern is as follows:

      -
        -
      1. Let map be an empty map.
      2. -
      3. If the inherit keyword was used, then set map to be the result of - the serialization behavior of the - closest inherited interface that declares a serializer.
      4. -
      5. For each identifier i of an attribute on the interface whose type is - a serializable type, in the order they appear - on the interface: -
          -
        1. Remove any entry in map with key name i.
        2. -
        3. Let V be the value of the attribute with identifier i.
        4. -
        5. Add an entry to map whose key name is i and whose - value is result of converting - V to a serialized value.
        6. -
        -
      6. -
      7. Return map.
      8. -
      -
    • -
    • -

      A map with entries corresponding to the named properties:

      -
      serializer = { getter };
      -

      This form MUST NOT be used unless the interface or one it - inherits from supports named properties and the return type of the named property getter - is a serializable type.

      -

      The serialization behavior for this - form of serialization pattern is as follows:

      -
        -
      1. Let map be an empty map.
      2. -
      3. For each supported property name n on the object, in order: -
          -
        1. Let V be the value of the named property with name n.
        2. -
        3. Add an entry to map whose key name is i and whose - value is result of converting - V to a serialized value.
        4. -
        -
      4. -
      5. Return map.
      6. -
      -
    • -
    • -

      A list of value of zero or more attributes on the interface:

      -
      serializer = [ attribute-identifier, attribute-identifier, … ];
      -

      Each identifier MUST be the identifier of an attribute declared - on the interface. The identified attributes all MUST have a - serializable type.

      -

      The serialization behavior for this - form of serialization pattern is as follows:

      -
        -
      1. Let list be an empty list.
      2. -
      3. For each attribute identifier i in the serialization pattern: -
          -
        1. Let V be the value of the attribute with identifier i.
        2. -
        3. Append to list the value that is the result of - converting - V to a serialized value.
        4. -
        -
      4. -
      5. Return list.
      6. -
      -
    • -
    • -

      A list with entries corresponding to the indexed properties:

      -
      serializer = [ getter ];
      -

      This form MUST NOT be used unless the interface or one it - inherits from supports indexed properties and the return type of the indexed property getter - is a serializable type.

      -

      The serialization behavior for this - form of serialization pattern is as follows:

      -
        -
      1. Let list be an empty list.
      2. -
      3. Let i be 0.
      4. -
      5. While i is less than or equal to the greatest supported property index on the object: -
          -
        1. Let V be the value of the indexed property with index i - if i is a supported property index, or null otherwise.
        2. -
        3. Append to list the value that is the result of - converting - V to a serialized value.
        4. -
        5. Set i to i + 1.
        6. -
        -
      6. -
      7. Return map.
      8. -
      -
    • -
    • -

      A single attribute:

      -
      serializer = attribute-identifier;
      -

      The identifier MUST be the identifier of an attribute declared - on the interface, and this attribute MUST have a - serializable type.

      -

      The serialization behavior for this - form of serialization pattern is as follows:

      -
        -
      1. Let V be the value of the attribute with the specified identifier.
      2. -
      3. Return the result of converting - V to a serialized value.
      4. -
      -
    • -
    - -
    Note
    -

    - Entries are added to maps in a particular order so that in the ECMAScript language binding - it is defined what order properties are added to objects. This is because this order - can influence the serialization that JSON.stringify can produce. -

    -
    - -

    The list of serializable types and how they are - converted to serialized values is as follows:

    -
    -
    long long
    -
    converted by choosing the closest equivalent double value - (as when converting a long long to an ECMAScript Number value)
    -
    unsigned long long
    -
    converted by choosing the closest equivalent double value - (as when converting a unsigned long long to an ECMAScript Number value)
    -
    any other integer type
    -
    float
    -
    converted by choosing the equivalent double value
    -
    double
    -
    boolean
    -
    DOMString
    -
    the same value of the respective type
    -
    an enumeration type
    -
    the equivalent DOMString value
    -
    a USVString
    -
    the DOMString produced by - encoding the given sequence of Unicode scalar values in - UTF-16
    -
    a ByteString
    -
    the equivalent DOMString value where each code unit has the same value as the corresponding byte value
    -
    a nullable serializable type
    -
    converted to null if that is its value, - otherwise converted as per its inner type
    -
    a union type where - all of its member types - are serializable types
    -
    converted as per its specific type
    -
    a sequence type that - has a serializable type as its element type
    -
    converted to a list where each element is the result of converting its - corresponding sequence element to a serialized value
    -
    a dictionary where - all of its members have - serializable types
    -
    converted to a map consisting of an entry for each dictionary member - that is present, where the entry’s key is the identifier of the dictionary - member and its value is the result of converting the dictionary member’s - value to a serializable type
    -
    an interface type that has a - serializer
    -
    converted by invoking the object’s serializer
    -
    - -

    - Serializers can also be specified using an operation - with the serializer keyword: -

    -
    serializer type identifier();
    -

    - Serializers declared with operations MUST - be declared to take zero arguments and return a serializable type. -

    -

    - The serialization behavior - of the interface with a serializer declared with an operation is the result of - converting - the value returned from invoking the operation to a serialized value. -

    - -
    [30]Serializer"serializer" SerializerRest
    [31]SerializerRestOperationRest
     | - "=" SerializationPattern ";"
     | - ";"
    [32]SerializationPattern"{" SerializationPatternMap "}"
     | - "[" SerializationPatternList "]"
     | - identifier
    [33]SerializationPatternMap"getter"
     | - "inherit" Identifiers
     | - identifier Identifiers
     | - ε
    [34]SerializationPatternList"getter"
     | - identifier Identifiers
     | - ε
    [91]Identifiers"," identifier Identifiers
     | - ε
    - -
    Example
    -

    - The following IDL fragment defines - an interface Transaction that has a - serializer defines in prose: -

    -
    IDL
    interface Transaction {
    -  readonly attribute Account from;
    -  readonly attribute Account to;
    -  readonly attribute double amount;
    -  readonly attribute DOMString description;
    -  readonly attribute unsigned long number;
    -
    -  serializer;
    +
    +

    A callback interface is +an interface that uses the callback keyword at the start of +its definition. Callback interfaces are ones that can be +implemented by user objects and not by platform objects, +as described in §3.10 Objects implementing interfaces.

    +
    callback interface identifier {
    +  /* interface_members... */
     };
    -
    -interface Account {
    -  DOMString name;
    -  unsigned long number;
    -};
    -

    - The serializer could be defined as follows: -

    -
    -

    - The serialization behavior - of the Transaction interface is to run the following - algorithm, where O is the object that implements Transaction: -

    -
      -
    1. Let map be an empty map.
    2. -
    3. Add an entry to map whose key is “from” and whose value is - the serialized value of - the number attribute on the Account - object referenced by the from attribute on O.
    4. -
    5. Add an entry to map whose key is “to” and whose value is - the serialized value of - the number attribute on the Account - object referenced by the from attribute on O.
    6. -
    7. For both of the attributes amount and description, - add an entry to map whose key is the - identifier of the attribute - and whose value is the serialized value - of the value of the attribute on O.
    8. -
    9. Return map.
    10. -
    -
    -

    - If it was acceptable for Account objects to be serializable - on their own, then serialization patterns - could be used to avoid having to define the serialization behavior - in prose: -

    -
    IDL
    interface Transaction {
    -  readonly attribute Account from;
    -  readonly attribute Account to;
    -  readonly attribute double amount;
    -  readonly attribute DOMString description;
    -  readonly attribute unsigned long number;
    -
    -  serializer = { from, to, amount, description };
    +
    +

    Note: See also the similarly named callback function definition.

    +

    Callback interfaces must not inherit from any non-callback interfaces, and non-callback interfaces must not +inherit from any callback interfaces. +Callback interfaces must not have any consequential interfaces.

    +

    Static attributes and static operations must not +be defined on a callback interface.

    +
    +

    Specification authors should not define callback interfaces that have only a single operation, + unless required to describe the requirements of existing APIs. + Instead, a callback function should be used.

    +

    The definition of EventListener as a callback interface is an example of an existing API that needs to allow user objects with a + given property (in this case “handleEvent”) to be considered to implement the interface. + For new APIs, and those for which there are no compatibility concerns, + using a callback function will allow + only a Function object (in the ECMAScript + language binding).

    +
    +

    Perhaps this warning shouldn’t apply if you are planning to extend the callback + interface in the future. That’s probably a good reason to start off with a single + operation callback interface.

    +

    I think we need to support operations not being implemented on a given + user object implementing a callback interface. If specs extending an existing + callback interface, we probably want to be able to avoid calling the + operations that aren’t implemented (and having some default behavior instead). + So we should perhaps define a term that means whether the operation is + implemented, which in the ECMAScript binding would correspond to checking + for the property’s existence.

    +
    +

    Specification authors wanting to define APIs that take ECMAScript objects + as “property bag” like function arguments are suggested to use dictionary types rather than callback interfaces.

    +

    For example, instead of this:

    +
    callback interface Options {
    +  attribute DOMString? option1;
    +  attribute DOMString? option2;
    +  attribute long? option3;
     };
    -
    -interface Account {
    -  DOMString name;
    -  unsigned long number;
    -
    -  serializer = number;
    -};
    -

    - In the ECMAScript language binding, there would exist a toJSON method on - Transaction objects: -

    -
    ECMAScript
    // Get an instance of Transaction.
    -var txn = getTransaction();
    -
    -// Evaluates to an object like this:
    -// {
    -//   from: 1234
    -//   to: 5678
    -//   amount: 110.75
    -//   description: "dinner"
    -// }
    -txn.toJSON();
    -
    -// Evaluates to a string like this:
    -// '{"from":1234,"to":5678,"amount":110.75,"description":"dinner"}'
    -JSON.stringify(txn);
    -
    -
    - -
    -
    3.2.4.4. Indexed properties
    - -

    - An interface that defines - an indexed property getter - is said to support indexed properties. -

    -

    - If an interface supports indexed properties, - then the interface definition MUST be accompanied by - a description of what indices the object can be indexed with at - any given time. These indices are called the supported property indices. -

    -

    - Indexed property getters MUST - be declared to take a single unsigned long argument. - Indexed property setters MUST - be declared to take two arguments, where the first is an unsigned long. -

    -
    getter type identifier(unsigned long identifier);
    -setter type identifier(unsigned long identifier, type identifier);
    -
    -getter type (unsigned long identifier);
    -setter type (unsigned long identifier, type identifier);
    -

    - The following requirements apply to the definitions of indexed property getters and setters: -

    -
      -
    • - If an indexed property getter was specified using an operation - with an identifier, - then the value returned when indexing the object with a given supported property index - is the value that would be returned by invoking the operation, passing - the index as its only argument. If the operation used to declare the indexed property getter - did not have an identifier, then the interface definition must be accompanied - by a description of how to determine the value of an indexed property - for a given index. -
    • -
    • - If an indexed property setter was specified using an operation - with an identifier, - then the behavior that occurs when indexing the object for property assignment with a given supported property index and value - is the same as if the operation is invoked, passing - the index as the first argument and the value as the second argument. If the operation used to declare the indexed property setter - did not have an identifier, then the interface definition must be accompanied - by a description of how to set the value of an existing indexed property - and how to set the value of a new indexed property - for a given property index and value. -
    • -
    - -
    Note
    -

    - Note that if an indexed property getter or - setter - is specified using an operation with an identifier, - then indexing an object with an integer that is not a supported property index - does not necessarily elicit the same behavior as invoking the operation with that index. The actual behavior in this - case is language binding specific. -

    -

    - In the ECMAScript language binding, a regular property lookup is done. For example, take the following IDL: -

    -
    IDL
    interface A {
    -  getter DOMString toWord(unsigned long index);
    -};
    -

    - Assume that an object implementing A has supported property indices - in the range 0 ≤ index < 2. Also assume that toWord is defined to return - its argument converted into an English word. The behavior when invoking the - operation with an out of range index - is different from indexing the object directly: -

    -
    ECMAScript
    var a = getA();
    -
    -a.toWord(0);  // Evalautes to "zero".
    -a[0];         // Also evaluates to "zero".
    -
    -a.toWord(5);  // Evaluates to "five".
    -a[5];         // Evaluates to undefined, since there is no property "5".
    -
    - -
    Example
    -

    - The following IDL fragment defines an interface - OrderedMap which allows - retrieving and setting values by name or by index number: -

    -
    IDL
    interface OrderedMap {
    -  readonly attribute unsigned long size;
    -
    -  getter any getByIndex(unsigned long index);
    -  setter void setByIndex(unsigned long index, any value);
    -
    -  getter any get(DOMString name);
    -  setter void set(DOMString name, any value);
    -};
    -

    - Since all of the special operations are declared using - operations with identifiers, the only additional prose - that is necessary is that which describes what keys those sets - have. Assuming that the get() operation is - defined to return null if an - attempt is made to look up a non-existing entry in the - OrderedMap, then the following - two sentences would suffice: -

    -
    -

    - An object map implementing OrderedMap - supports indexed properties with indices in the range - 0 ≤ index < map.size. -

    -

    - Such objects also support a named property for every name that, - if passed to get(), would return a non-null value. -

    -
    -

    - As described in section 4.8, - an ECMAScript implementation would create - properties on a platform object implementing - OrderedMap that correspond to - entries in both the named and indexed property sets. - These properties can then be used to interact - with the object in the same way as invoking the object’s - methods, as demonstrated below: -

    -
    ECMAScript
    // Assume map is a platform object implementing the OrderedMap interface.
    -var map = getOrderedMap();
    -var x, y;
    -
    -x = map[0];       // If map.length > 0, then this is equivalent to:
    -                  //
    -                  //   x = map.getByIndex(0)
    -                  //
    -                  // since a property named "0" will have been placed on map.
    -                  // Otherwise, x will be set to undefined, since there will be
    -                  // no property named "0" on map.
    -
    -map[1] = false;   // This will do the equivalent of:
    -                  //
    -                  //   map.setByIndex(1, false)
    -
    -y = map.apple;    // If there exists a named property named "apple", then this
    -                  // will be equivalent to:
    -                  //
    -                  //   y = map.get('apple')
    -                  //
    -                  // since a property named "apple" will have been placed on
    -                  // map.  Otherwise, y will be set to undefined, since there
    -                  // will be no property named "apple" on map.
    -
    -map.berry = 123;  // This will do the equivalent of:
    -                  //
    -                  //   map.set('berry', 123)
    -
    -delete map.cake;  // If a named property named "cake" exists, then the "cake"
    -                  // property will be deleted, and then the equivalent to the
    -                  // following will be performed:
    -                  //
    -                  //   map.remove("cake")
    -
    -
    - -
    -
    3.2.4.5. Named properties
    - -

    - An interface that defines - a named property getter - is said to support named properties. -

    -

    - If an interface supports named properties, - then the interface definition MUST be accompanied by - a description of the ordered set of names that can be used to index the object - at any given time. These names are called the - supported property names. -

    -

    - Named property getters and deleters MUST - be declared to take a single DOMString argument. - Named property setters MUST - be declared to take two arguments, where the first is a DOMString. -

    -
    getter type identifier(DOMString identifier);
    -setter type identifier(DOMString identifier, type identifier);
    -deleter type identifier(DOMString identifier);
    -
    -getter type (DOMString identifier);
    -setter type (DOMString identifier, type identifier);
    -deleter type (DOMString identifier);
    -

    - The following requirements apply to the definitions of named property getters, setters and deleters: -

    -
      -
    • - If a named property getter was specified using an operation - with an identifier, - then the value returned when indexing the object with a given supported property name - is the value that would be returned by invoking the operation, passing - the name as its only argument. If the operation used to declare the named property getter - did not have an identifier, then the interface definition must be accompanied - by a description of how to determine the value of a named property - for a given property name. -
    • -
    • - If a named property setter was specified using an operation - with an identifier, - then the behavior that occurs when indexing the object for property assignment with a given supported property name and value - is the same as if the operation is invoked, passing - the name as the first argument and the value as the second argument. If the operation used to declare the named property setter - did not have an identifier, then the interface definition must be accompanied - by a description of how to set the value of an existing named property - and how to set the value of a new named property - for a given property name and value. -
    • -
    • - If a named property deleter was specified using an operation - with an identifier, - then the behavior that occurs when indexing the object for property deletion with a given supported property name - is the same as if the operation is invoked, passing - the name as the only argument. If the operation used to declare the named property deleter - did not have an identifier, then the interface definition must be accompanied - by a description of how to delete an existing named property - for a given property name. -
    • -
    - -
    Note
    -

    - As with indexed properties, - if an named property getter, - setter or - deleter - is specified using an operation with an identifier, - then indexing an object with a name that is not a supported property name - does not necessarily elicit the same behavior as invoking the operation with that name; the behavior - is language binding specific. -

    -
    -
    -
    - -
    -

    3.2.5. Static attributes and operations

    - -

    - Static attributes and - static operations are ones that - are not associated with a particular instance of the - interface - on which it is declared, and is instead associated with the interface - itself. Static attributes and operations are declared by using the - static keyword in their declarations. -

    -

    - It is language binding specific whether it is possible to invoke - a static operation or get or set a static attribute through a reference - to an instance of the interface. -

    -

    - Static attributes and operations MUST NOT be - declared on callback interfaces. -

    - -
    [37]StaticMember"static" StaticMemberRest
    [38]StaticMemberRestReadOnly AttributeRest
     | - ReturnType OperationRest
    - -
    Example
    -

    - The following IDL fragment defines an interface - Circle that has a static - operation declared on it: -

    -
    IDL
    interface Point { /* ... */ };
    -
    -interface Circle {
    -  attribute double cx;
    -  attribute double cy;
    -  attribute double radius;
    -
    -  static readonly attribute long triangulationCount;
    -  static Point triangulate(Circle c1, Circle c2, Circle c3);
    -};
    -

    - In the ECMAScript language binding, the Function object for - triangulate and the accessor property for triangulationCount - will exist on the interface object - for Circle: -

    -
    ECMAScript
    var circles = getCircles();           // an Array of Circle objects
    -
    -typeof Circle.triangulate;            // Evaluates to "function"
    -typeof Circle.triangulationCount;     // Evaluates to "number"
    -Circle.prototype.triangulate;         // Evaluates to undefined
    -Circle.prototype.triangulationCount;  // Also evaluates to undefined
    -circles[0].triangulate;               // As does this
    -circles[0].triangulationCount;        // And this
    -
    -// Call the static operation
    -var triangulationPoint = Circle.triangulate(circles[0], circles[1], circles[2]);
    -
    -// Find out how many triangulations we have done
    -window.alert(Circle.triangulationCount);
    - -
    -
    - -
    -

    3.2.6. Overloading

    - -

    - If a regular operation - or static operation - defined on an interface - has an identifier - that is the same as the identifier of another operation on that - interface of the same kind (regular or static), then the operation is said to be - overloaded. When the identifier - of an overloaded operation is used to invoke one of the - operations on an object that implements the interface, the - number and types of the arguments passed to the operation - determine which of the overloaded operations is actually - invoked. If an interface has multiple - legacy callers defined on it, - then those legacy callers are also said to be overloaded. - In the ECMAScript language binding, constructors - can be overloaded too. There are some restrictions on the arguments - that overloaded operations, legacy callers and constructors can be - specified to take, and in order to describe these restrictions, - the notion of an effective overload set is used. -

    -

    - Operations and legacy callers - MUST NOT be overloaded across interface - and partial interface definitions. -

    -
    Note
    -

    - For example, the overloads for both f and g - are disallowed: -

    -
    IDL
    interface A {
    -  void f();
    +        
    +interface A {
    +  void doTask(DOMString type, Options options);
     };
    -
    -partial interface A {
    -  void f(double x);
    -  void g();
    +
    +

    to be used like this:

    +
    var a = getA();  // Get an instance of A.
    +        
    +a.doTask("something", { option1: "banana", option3: 100 });
    +

    instead write the following:

    +
    dictionary Options {
    +  DOMString? option1;
    +  DOMString? option2;
    +  long? option3;
     };
    -
    -partial interface A {
    -  void g(DOMString x);
    -};
    -

    Note that the [Constructor] and - [NamedConstructor] - extended attributes are disallowed from appearing - on partial interface definitions, - so there is no need to also disallow overloading for constructors.

    -
    -

    - An effective overload set - represents the allowable invocations for a particular - operation, - constructor (specified with [Constructor] - or [NamedConstructor]), - legacy caller or - callback function. - The algorithm to compute an effective overload set - operates on one of the following six types of IDL constructs, and listed with them below are - the inputs to the algorithm needed to compute the set. -

    -
    -
    For regular operations
    -
    For static operations
    -
    - -
    -
    For legacy callers
    -
    - -
    -
    For constructors
    -
    - -
    -
    For named constructors
    -
    - -
    -
    For callback functions
    -
    - -
    -
    -

    - An effective overload set is used, among other things, to determine whether there are ambiguities in the - overloaded operations, constructors and callers specified on an interface. -

    -

    - The elements of an effective overload set are tuples of the form - <callabletype list, optionality list>. If the effective overload - set is for regular operations, static operations or legacy callers, then callable is an operation; - if it is for constructors or named constructors, then callable is an - extended attribute; and if it is for callback functions, then callable - is the callback function itself. In all cases, type list is a list - of IDL types, and optionality list is a list of three possible optionality values – - “required”, “optional” or “variadic” – indicating whether - the argument at a given index was declared as being optional - or corresponds to a variadic argument. - Each tuple represents an allowable invocation of the operation, - constructor, legacy caller or callback function with an argument value list of the given types. - Due to the use of optional arguments - and variadic operations - and constructors, there may be multiple entries in an effective overload set identifying - the same operation or constructor. -

    -

    - The algorithm below describes how to compute an effective overload set. - The following input variables are used, if they are required: -

    -
      -
    • the identifier of the operation or named constructor is A
    • -
    • the argument count is N
    • -
    • the interface is I
    • -
    • the callback function is C
    • -
    -

    - Whenever an argument of an extended - attribute is mentioned, it is referring to an argument of the - extended attribute’s named argument list. -

    -
      -
    1. Initialize S to ∅.
    2. -
    3. Let F be a set with elements as follows, according to the kind of effective overload set: -
      -
      For regular operations
      -
      - The elements of F are the regular operations with - identifier A defined on interface I. -
      -
      For static operations
      -
      - The elements of F are the static operations with - identifier A defined on interface I. -
      -
      For constructors
      -
      - The elements of F are the - [Constructor] - extended attributes on interface I. -
      -
      For named constructors
      -
      - The elements of F are the - [NamedConstructor] - extended attributes on interface I whose - named argument lists’ - identifiers are A. -
      -
      For legacy callers
      -
      - The elements of F are the legacy callers - defined on interface I. -
      -
      For callback functions
      -
      - The single element of F is the callback function itself, C. -
      -
      -
    4. - -
    5. - Let maxarg be the maximum number of arguments the operations, constructor extended attributes or callback functions in F are declared to take. - For variadic operations and constructor extended attributes, - the argument on which the ellipsis appears counts as a single argument. -
      Note
      -

      So void f(long x, long... y); is considered to be declared to take two arguments.

      -
      -
    6. -
    7. Let m be the maximum of maxarg and N.
    8. -
    9. For each operation, extended attribute or callback function X in F: -
        -
      1. Let n be the number of arguments X is declared to take.
      2. -
      3. Let t0..n−1 be a list of types, where ti - is the type of X’s argument at index i.
      4. -
      5. Let o0..n−1 be a list of optionality values, where oi - is “variadic” if X’s argument at index i is a final, variadic argument, - “optional” if the argument is optional, - and “required” otherwise.
      6. -
      7. Add to S the tuple <Xt0..n−1, o0..n−1>.
      8. -
      9. If X is declared to be variadic, then: -
          -
        1. For every integer i, such that n ≤ i ≤ m−1: -
            -
          1. Let u0..i be a list of types, where uj = tj (for j < n) and uj = tn−1 (for j ≥ n).
          2. -
          3. Let p0..i be a list of optionality values, where pj = oj (for j < n) and pj = “variadic” (for j ≥ n).
          4. -
          5. Add to S the tuple <Xu0..ip0..i>.
          6. -
          -
        2. -
        -
      10. -
      11. Initialize i to n−1.
      12. -
      13. While i ≥ 0: -
          -
        1. If argument i of X is not - optional - (i.e., it is not marked as optional and is not - a final, variadic argument), then break this loop.
        2. -
        3. Otherwise, add to S the tuple <Xt0..i−1o0..i−1>.
        4. -
        5. Set i to i−1.
        6. -
        -
      14. -
      -
    10. -
    11. - The effective overload set is S. -
    12. -
    -
    Example
    -

    - For the following interface: -

    -
    IDL
    interface A {
    -  /* f1 */ void f(DOMString a);
    -  /* f2 */ void f(Node a, DOMString b, double... c);
    -  /* f3 */ void f();
    -  /* f4 */ void f(Event a, DOMString b, optional DOMString c, double... d);
    -};
    -

    - assuming Node and Event - are two other interfaces of which no object can implement both, - the effective overload set - for regular operations with - identifier f and argument count 4 is: -

    -
    - { <f1, (DOMString), (required)>,
    - <f2, (Node, DOMString), (required, required)>,
    - <f2, (Node, DOMString, double), (required, required, variadic)>,
    - <f2, (Node, DOMString, double, double), (required, required, variadic, variadic)>,
    - <f3, (), ()>,
    - <f4, (Event, DOMString), (required, required)>,
    - <f4, (Event, DOMString, DOMString), (required, required, optional)>,
    - <f4, (Event, DOMString, DOMString, double), (required, required, optional, variadic)> } -
    -
    - -

    - Two types are distinguishable if - at most one of the two includes a nullable type - or is a dictionary type, - and at least one of the following three conditions is true: -

    -
      -
    1. -

      - The two types (taking their inner types - if they are nullable types) appear - in the following table and there is a “●” mark in the corresponding entry - or there is a letter in the corresponding entry and the designated additional - requirement below the table is satisfied:

      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      booleannumeric typesstring typesinterfaceobjectcallback
      function
      dictionarysequence<T>FrozenArray<T>RegExpexception typesbuffer source types
      boolean
      numeric types
      string types
      interface(a)(b)(b)
      object
      callback function
      dictionary
      sequence<T>
      FrozenArray<T>
      RegExp
      exception types
      buffer source types
      -
        -
      1. The two identified interfaces are - not the same, it is not possible for a single platform object - to implement both interfaces, - and it is not the case that both are callback interfaces.
      2. -
      3. The interface type is not a callback interface.
      4. -
      -
    2. -
    3. - One type is a union type or nullable union type, - the other is neither a union type nor a nullable union type, and each - member type of the first is distinguishable - with the second. -
    4. -
    5. - Both types are either a union type or nullable union type, and each member type of the one - is distinguishable with each member type of the other. -
    6. -
    -
    Note
    -

    Promise types do not appear in the above table, and as a consequence - are not distinguishable with any other type.

    -
    -

    - If there is more than one entry in an effective overload set - that has a given type list length, then for those entries there - MUST be an index i such - that for each pair of entries the types at index i are - distinguishable. - The lowest such index is termed the distinguishing argument index - for the entries of the effective overload set with the given type list length. -

    -
    Example
    -

    - Consider the effective overload set shown in the previous example. - There are multiple entries in the set with type lists 2, 3 and 4. - For each of these type list lengths, the distinguishing - argument index is 0, since Node and - Event are distinguishable. -

    -

    - The following use of overloading however is invalid: -

    -
    IDL
    interface B {
    -  void f(DOMString x);
    -  void f(double x);
    -};
    -

    - since DOMString and - double are not distinguishable. -

    -
    -

    - In addition, for each index j, where j is less than the - distinguishing argument index - for a given type list length, the types at index j in - all of the entries’ type lists MUST be the same - and the booleans in the corresponding list indicating argument optionality MUST - be the same. -

    -
    Example
    -

    The following is invalid:

    -
    IDL
    interface B {
    -  /* f1 */ void f(DOMString w);
    -  /* f2 */ void f(long w, double x, Node y, Node z);
    -  /* f3 */ void f(double w, double x, DOMString y, Node z);
    -};
    -

    - For argument count 4, the effective overload set is: -

    -
    - { <f1, (DOMString), (required)>,
    - <f2, (long, double, Node, Node), (required, required, required, required)>,
    - <f3, (double, double, DOMString, Node), (required, required, required, required)> } -
    -

    - Looking at entries with type list length 4, the - distinguishing argument index - is 2, since Node and - DOMString are distinguishable. - However, since the arguments in these two overloads at index 0 are different, - the overloading is invalid. -

    -
    - -
    - -
    -

    3.2.7. Iterable declarations

    - -

    - An interface can be declared to be - iterable by using an iterable declaration - (matching Iterable) in the body of the interface. -

    -
    iterable<value-type>;
    -iterable<key-type, value-type>;
    -

    - Objects implementing an interface that is declared to be iterable - support being iterated over to obtain a sequence of values. -

    -
    Note
    -

    In the ECMAScript language binding, an interface that is iterable - will have “entries”, “forEach”, “keys”, “values” and @@iterator - properties on its interface prototype object.

    -
    -

    - If a single type parameter is given, then the interface has a - value iterator and provides - values of the specified type. - If two type parameters are given, then the interface has a - pair iterator and provides - value pairs, where the first value is a key and the second is the - value associated with the key. -

    -

    - A value iterator - MUST only be declared on an interface - that supports indexed properties - and has an integer-typed - attribute named “length”. - The value-type of the value iterator - MUST be the same as the type returned by - the indexed property getter. - A value iterator is implicitly - defined to iterate over the object’s indexed properties. -

    -

    - A pair iterator - MUST NOT be declared on an interface - that supports indexed properties. - Prose accompanying an interface with a - pair iterator - MUST define what the list of - value pairs to iterate over - is. -

    -
    Note
    -

    - The ECMAScript forEach method that is generated for a - value iterator - invokes its callback like Array.prototype.forEach does, and the forEach - method for a pair iterator - invokes its callback like Map.prototype.forEach does. -

    -

    - Since value iterators - are currently allowed only on interfaces that - support indexed properties, - it makes sense to use an Array-like forEach method. - There may be a need for value iterators - (a) on interfaces that do not - support indexed properties, - or (b) with a forEach method that instead invokes its callback like - Set.protoype.forEach (where the key is the same as the value). - If you’re creating an API that needs such a forEach method, please send a request to - public-script-coord@w3.org. -

    -
    -
    Note
    -

    This is how array iterator objects work. - For interfaces that support indexed properties, - the iterator objects returned by “entries”, “keys”, “values” and @@iterator are - actual array iterator objects.

    -
    -

    - Interfaces with iterable declarations MUST NOT - have any interface members - named “entries”, “forEach”, “keys” or “values”, - or have any inherited - or consequential - interfaces that have interface members with these names. -

    - -
    Example
    -

    Consider the following interface SessionManager, which allows access to - a number of Session objects:

    -
    IDL
    interface SessionManager {
    -  Session getSessionForUser(DOMString username);
    -  readonly attribute unsigned long sessionCount;
    -
    -  iterable<Session>;
    +    
    +partial interface SomeInterface {
    +  /* interface_members... */
     };
    -
    -interface Session {
    -  readonly attribute DOMString username;
    -  // ...
    -};
    -

    - The behavior of the iterator could be defined like so: -

    -
    -

    - The values to iterate over - are the open Session objects - on the SessionManager sorted by username. -

    -
    -

    - In the ECMAScript language binding, the interface prototype object - for the SessionManager interface - has a values method that is a function, which, when invoked, - returns an iterator object that itself has a next method that returns the - next value to be iterated over. It has values and entries - methods that iterate over the indexes of the list of session objects - and [index, session object] pairs, respectively. It also has - a @@iterator method that allows a SessionManager - to be used in a for..of loop: -

    -
    ECMAScript
    // Get an instance of SessionManager.
    -// Assume that it has sessions for two users, "anna" and "brian".
    -var sm = getSessionManager();
    -
    -typeof SessionManager.prototype.values;            // Evaluates to "function"
    -var it = sm.values();                              // values() returns an iterator object
    -String(it);                                        // Evaluates to "[object SessionManager Iterator]"
    -typeof it.next;                                    // Evaluates to "function"
    -
    -// This loop will alert "anna" and then "brian".
    -for (;;) {
    -  let result = it.next();
    -  if (result.done) {
    -    break;
    -  }
    -  let session = result.value;
    -  window.alert(session.username);
    -}
    -
    -// This loop will also alert "anna" and then "brian".
    -for (let session of sm) {
    -  window.alert(session.username);
    -}
    -
    - -

    - An interface MUST NOT have more than one - iterable declaration. - The inherited - and consequential - interfaces of an interface with an - iterable declaration - MUST NOT also have an - iterable declaration. - An interface with an iterable declaration - and its inherited - and consequential - interfaces MUST NOT have a - maplike declaration or - setlike declaration. -

    -

    - The following extended attributes are applicable to iterable declarations: - [Exposed], - [SecureContext]. -

    - - -
    [59]Iterable"iterable" "<" Type OptionalType ">" ";"
    [60]OptionalType"," Type
     | - ε
    -
    - -
    -

    3.2.8. Maplike declarations

    - -

    - An interface can be declared to be - maplike by using a maplike declaration - (matching ReadWriteMaplike or - "readonly" MaplikeRest) in the body of the interface. -

    -
    readonly maplike<key-type, value-type>;
    -maplike<key-type, value-type>;
    -

    - Objects implementing an interface that is declared to be maplike - represent an ordered list of key–value pairs known as its map entries. - The types used for the keys and values are given in the angle - brackets of the maplike declaration. Keys are required to be unique. -

    -

    - The map entries of an object - implementing a maplike interface is empty at - the of the object’s creation. Prose accompanying the interface can - describe how the map entries - of an object change. -

    -

    - Maplike interfaces support an API for querying the map entries - appropriate for the language binding. If the readonly - keyword is not used, then it also supports an API for modifying - the map entries. -

    -
    Note
    -

    - In the ECMAScript language binding, the API for interacting - with the map entries is similar to that available on ECMAScript - Map objects. If the readonly - keyword is used, this includes “entries”, “forEach”, “get”, “has”, - “keys”, “values”, @@iterator methods and a “size” getter. - For read–write maplikes, it also includes “clear”, “delete” and - “set” methods. -

    -
    -

    - Maplike interfaces MUST NOT - have any interface members - named “entries”, “forEach”, “get”, “has”, “keys”, “size”, or “values”, - or have any inherited - or consequential - interfaces that have interface members with these names. - Read–write maplike interfaces MUST NOT - have any attributes - or constants named - “clear”, “delete”, or “set”, or have any inherited - or consequential - interfaces that have attributes or constants with these names. -

    -
    Note
    -

    Operations named “clear”, “delete”, or “set” are allowed on read–write maplike - interfaces and will prevent the default implementation of these methods being - added to the interface prototype object in the ECMAScript language binding. - This allows the default behavior of these operations to be overridden.

    -
    -

    - An interface MUST NOT have more than one - maplike declaration. - The inherited - and consequential - interfaces of a maplike interface MUST NOT - also have a maplike declaration. - A maplike interface and its inherited - and consequential - interfaces MUST NOT have an - iterable declaration or - setlike declaration. -

    -
    [39]ReadOnlyMember"readonly" ReadOnlyMemberRest
    [40]ReadOnlyMemberRestAttributeRest
     | - ReadWriteMaplike
     | - ReadWriteSetlike
    [61]ReadWriteMaplikeMaplikeRest
    [63]MaplikeRest"maplike" "<" Type "," Type ">" ";"
    -

    - No extended attributes - defined in this specification are applicable to maplike declarations. -

    -
    Editorial note

    Add example.

    -
    - -
    -

    3.2.9. Setlike declarations

    - -

    - An interface can be declared to be - setlike by using a setlike declaration - (matching ReadWriteSetlike or - "readonly" SetlikeRest) in the body of the interface. -

    -
    readonly setlike<type>;
    -setlike<type>;
    -

    - Objects implementing an interface that is declared to be setlike - represent an ordered list of values known as its set entries. - The type of the values is given in the angle - brackets of the setlike declaration. Values are required to be unique. -

    -

    - The set entries of an object - implementing a setlike interface is empty at - the of the object’s creation. Prose accompanying the interface can - describe how the set entries - of an object change. -

    -

    - Setlike interfaces support an API for querying the set entries - appropriate for the language binding. If the readonly - keyword is not used, then it also supports an API for modifying - the set entries. -

    -
    Note
    -

    - In the ECMAScript language binding, the API for interacting - with the set entries is similar to that available on ECMAScript - Set objects. If the readonly - keyword is used, this includes “entries”, “forEach”, “has”, - “keys”, “values”, @@iterator methods and a “size” getter. - For read–write setlikes, it also includes “add”, “clear”, and “delete” methods. -

    -
    -

    - Setlike interfaces MUST NOT - have any interface members - named “entries”, “forEach”, “has”, “keys”, “size”, or “values”, - or have any inherited - or consequential - interfaces that have interface members with these names.. - Read–write setlike interfaces MUST NOT - have any attributes - or constants named - “add”, “clear”, or “delete”, or have any inherited - or consequential - interfaces that have attributes or constants with these names. -

    -
    Note
    -

    Operations named “add”, “clear”, or “delete” are allowed on read–write setlike - interfaces and will prevent the default implementation of these methods being - added to the interface prototype object in the ECMAScript language binding. - This allows the default behavior of these operations to be overridden.

    -
    -

    - An interface MUST NOT have more than one - setlike declaration. - The inherited - and consequential - interfaces of a setlike interface MUST NOT - also have a setlike declaration. - A setlike interface and its inherited - and consequential - interfaces MUST NOT have an - iterable declaration or - maplike declaration. -

    -
    [39]ReadOnlyMember"readonly" ReadOnlyMemberRest
    [40]ReadOnlyMemberRestAttributeRest
     | - ReadWriteMaplike
     | - ReadWriteSetlike
    [62]ReadWriteSetlikeSetlikeRest
    [64]SetlikeRest"setlike" "<" Type ">" ";"
    -

    - No extended attributes - defined in this specification are applicable to setlike declarations. -

    -
    Editorial note

    Add example.

    -
    -
    - -
    -

    3.3. Namespaces

    - -

    - A namespace is a definition (matching Namespace) that declares a global singleton with - associated behaviors. -

    - -
    namespace identifier {
    -  namespace-members…
    -};
    - -

    - A namespace is a specification of a set of namespace members (matching NamespaceMembers), which are the regular operations that appear between the braces in - the namespace declaration. These operations describe the behaviors packaged into the - namespace. -

    - -

    - As with interfaces, the IDL for namespaces can be split into multiple parts by using - partial namespace definitions - (matching "partial" Namespace). The identifier of a partial namespace definition MUST be the same as the identifier of a namespace definition. - All of the members that appear on each of the partial namespace definitions are - considered to be members of the namespace itself. -

    - -
    namespace SomeNamespace {
    -  namespace-members…
    +
    +

    Note: Partial interface definitions are intended for use as a specification +editorial aide, allowing the definition of an interface to be separated +over more than one section of the document, and sometimes multiple documents.

    +

    The order of appearance of an interface definition and any of its partial interface definitions does not matter.

    +

    Note: A partial interface definition cannot specify that the interface inherits from another interface. +Inheritance must be specified on the original interface definition.

    +

    Extended attributes can be specified on partial interface definitions, with some +limitations. The following extended attributes must not +be specified on partial interface definitions: +[Constructor], +[ImplicitThis], +[LegacyArrayClass], +[NamedConstructor], +[NoInterfaceObject].

    +

    Note: The above list of extended attributes is all of those defined in this document that are applicable to interfaces except for +[Exposed], +[Global], +[OverrideBuiltins], +[PrimaryGlobal], +[SecureContext] and +[Unforgeable].

    +

    Any extended attribute specified +on a partial interface definition +is considered to appear on the interface itself.

    +

    The relevant language binding determines how interfaces correspond to constructs +in the language.

    +

    The following extended attributes are applicable to interfaces: +[Constructor], +[Exposed], +[Global], +[ImplicitThis], +[LegacyArrayClass], +[NamedConstructor], +[NoInterfaceObject], +[OverrideBuiltins], +[PrimaryGlobal], +[SecureContext], +[Unforgeable].

    +
    +
    CallbackRestOrInterface :
    +    CallbackRest
    +    Interface
    +
    +
    Interface :
    +    "interface" identifier Inheritance "{" InterfaceMembers "}" ";"
    +
    +
    Partial :
    +    "partial" PartialDefinition
    +
    +
    PartialDefinition :
    +    PartialInterface
    +    PartialDictionary
    +    Namespace
    +
    +
    PartialInterface :
    +    "interface" identifier "{" InterfaceMembers "}" ";"
    +
    +
    InterfaceMembers :
    +    ExtendedAttributeList InterfaceMember InterfaceMembers
    +    ε
    +
    +
    InterfaceMember :
    +    Const
    +    Operation
    +    Serializer
    +    Stringifier
    +    StaticMember
    +    Iterable
    +    ReadOnlyMember
    +    ReadWriteAttribute
    +    ReadWriteMaplike
    +    ReadWriteSetlike
    +
    +
    Inheritance :
    +    ":" identifier
    +    ε
    +
    +
    + +

    The following IDL fragment demonstrates the definition of two mutually referential interfaces. + Both Human and Dog inherit from Animal. Objects that implement + either of those two interfaces will thus have a name attribute.

    +
    interface Animal {
    +  attribute DOMString name;
     };
    -
    -partial namespace SomeNamespace {
    -  namespace-members…
    -};
    - -
    Note
    -

    - As with partial interface definitions, partial namespace definitions are intended for - use as a specification editorial aide, allowing the definition of a namespace to be - separated over more than one section of the document, and sometimes multiple - documents. -

    -
    - -

    - The order that members appear in has significance for property enumeration in the ECMAScript binding. -

    - -

    - Note that unlike interfaces or dictionaries, namespaces do not create types. -

    - -

    - Of the extended attributes defined in this specification, only the [Exposed] and [SecureContext] extended attributes are applicable to - namespaces. -

    - -
    [6]Partial"partial" PartialDefinition
    [7]PartialDefinitionPartialInterface
     | - PartialDictionary
     | - Namespace
    [97]Namespace"namespace" identifier "{" NamespaceMembers "}" ";"
    [98]NamespaceMembersExtendedAttributeList NamespaceMember NamespaceMembers
     | - ε
    [99]NamespaceMemberReturnType OperationRest
    - - -
    Example
    -

    - The following IDL fragment defines an - namespace. -

    -
    IDL
    namespace VectorUtils {
    -  double dotProduct(Vector x, Vector y);
    -  Vector crossProduct(Vector x, Vector y);
    -};
    - -

    - An ECMAScript implementation would then expose a global property named - VectorUtils which was a simple object (with prototype - %ObjectPrototype%) with enumerable data properties for each declared operation: -

    - -
    ECMAScript
    Object.getPrototypeOf(VectorUtils);                         // Evaluates to Object.prototype.
    -Object.keys(VectorUtils);                                   // Evaluates to ["dotProduct", "crossProduct"].
    -Object.getOwnPropertyDescriptor(VectorUtils, "dotProduct"); // Evaluates to { value: <a function>, enumerable: true, configurable: true, writable: true }.
    -
    - -
    - -
    -

    3.4. Dictionaries

    - -

    - A dictionary is a definition (matching - Dictionary) - used to define an associative array data type with a fixed, ordered set of key–value pairs, - termed dictionary members, - where keys are strings and values are of a particular type specified in the definition. -

    -
    dictionary identifier {
    -  dictionary-members…
    -};
    -

    - Dictionaries are always passed by value. In language bindings where a dictionary is represented by an object of some kind, passing a - dictionary to a platform object will not result in a reference to the dictionary being kept by that object. - Similarly, any dictionary returned from a platform object will be a copy and modifications made to it will not be visible to the platform object. -

    -

    - A dictionary can be defined to inherit from another dictionary. - If the identifier of the dictionary is followed by a colon and a identifier, - then that identifier identifies the inherited dictionary. The identifier - MUST identify a dictionary. -

    -

    - A dictionary MUST NOT be declared such that - its inheritance hierarchy has a cycle. That is, a dictionary - A cannot inherit from itself, nor can it inherit from another - dictionary B that inherits from A, and so on. -

    -
    dictionary Base {
    -  dictionary-members…
    +        
    +interface Human : Animal {
    +  attribute Dog? pet;
     };
    -
    -dictionary Derived : Base {
    -  dictionary-members…
    -};
    -

    - The inherited dictionaries of - a given dictionary D is the set of all dictionaries that D - inherits from, directly or indirectly. If D does not inherit - from another dictionary, then the set is empty. Otherwise, the set - includes the dictionary E that D inherits - from and all of E’s inherited dictionaries. -

    -

    - A dictionary value of type D can have key–value pairs corresponding - to the dictionary members defined on D and on any of D’s - inherited dictionaries. - On a given dictionary value, the presence of each dictionary member - is optional, unless that member is specified as required. - When specified in the dictionary value, a dictionary member is said to be - present, otherwise it is not present. - Dictionary members can also optionally have a default value, which is - the value to use for the dictionary member when passing a value to a - platform object that does - not have a specified value. Dictionary members with default values are - always considered to be present. -

    -
    Warning
    -

    - As with operation argument default values, - is strongly suggested not to use of true as the - default value for - boolean-typed - dictionary members, - as this can be confusing for authors who might otherwise expect the default - conversion of undefined to be used (i.e., false). -

    -
    -

    - Each dictionary member (matching - DictionaryMember) is specified - as a type (matching Type) followed by an - identifier - (given by an identifier token following - the type). The identifier is the key name of the key–value pair. - If the Type - is an identifier - followed by ?, then the identifier - MUST identify an - interface, enumeration, - callback function or typedef. - If the dictionary member type is an identifier - not followed by ?, then the identifier MUST - identify any one of those definitions or a dictionary. -

    -
    dictionary identifier {
    -  type identifier;
    -};
    -

    - If the identifier is followed by a U+003D EQUALS SIGN ("=") - and a value (matching DefaultValue), - then that gives the dictionary member its default value. -

    -
    dictionary identifier {
    -  type identifier = value;
    -};
    -

    - When a boolean literal token (true or false), - the null token, - an integer token, a - float token, - one of the three special floating point literal values (Infinity, - -Infinity or NaN), - a string token or - the two token sequence [] used as the - default value, - it is interpreted in the same way as for an operation’s - optional argument default value. -

    -

    - If the type of the dictionary member - is an enumeration, then its - default value if specified MUST - be one of the enumeration’s values. -

    -

    - If the type of the dictionary member is preceded by the - required keyword, the member is considered a - required dictionary member - and must be present on the dictionary. A - required dictionary - member MUST NOT have a default value. -

    -
    dictionary identifier {
    -  required type identifier;
    -};
    -

    - The type of a dictionary member MUST NOT include - the dictionary it appears on. A type includes a dictionary D - if at least one of the following is true: -

    - -

    - As with interfaces, the IDL for dictionaries can be split into multiple parts - by using partial dictionary definitions - (matching "partial" Dictionary). - The identifier of a partial - dictionary definition MUST be the same as the - identifier of a dictionary definition. All of the members that appear on each - of the partial dictionary definitions are considered to be members of - the dictionary itself. -

    -
    dictionary SomeDictionary {
    -  dictionary-members…
    +        
    +interface Dog : Animal {
    +  attribute Human? owner;
     };
    -
    -partial dictionary SomeDictionary {
    -  dictionary-members…
    -};
    -
    Note
    -

    As with partial interface definitions, partial dictionary definitions are intended for use as a specification - editorial aide, allowing the definition of an interface to be separated - over more than one section of the document, and sometimes multiple documents.

    -
    -

    - The order of the dictionary members - on a given dictionary is such that inherited dictionary members are ordered - before non-inherited members, and the dictionary members on the one - dictionary definition (including any partial dictionary definitions) are - ordered lexicographically by the Unicode codepoints that comprise their - identifiers. -

    -
    Note
    -

    For example, with the following definitions:

    -
    IDL
    dictionary B : A {
    -  long b;
    -  long a;
    +
    +
    +
    + +

    The following IDL fragment defines + simplified versions of a few DOM interfaces, one of which + is a callback interface.

    +
    interface Node {
    +  readonly attribute DOMString nodeName;
    +  readonly attribute Node? parentNode;
    +  Node appendChild(Node newChild);
    +  void addEventListener(DOMString type, EventListener listener);
     };
    -
    -dictionary A {
    -  long c;
    -  long g;
    +        
    +callback interface EventListener {
    +  void handleEvent(Event event);
     };
    -
    -dictionary C : B {
    -  long e;
    -  long f;
    +
    +

    Since the EventListener interface is annotated + callback interface, user objects can implement it:

    +
    var node = getNode();                                // Obtain an instance of Node.
    +        
    +var listener = {
    +  handleEvent: function(event) {
    +    // ...
    +  }
    +};
    +node.addEventListener("click", listener);            // This works.
    +        
    +node.addEventListener("click", function() { ... });  // As does this.
    +

    It is not possible for a user object to implement Node, however:

    +
    var node = getNode();  // Obtain an instance of Node.
    +        
    +var newNode = {
    +  nodeName: "span",
    +  parentNode: null,
    +  appendChild: function(newchild) {
    +    // ...
    +  },
    +  addEventListener: function(type, listener) {
    +    // ...
    +  }
    +};
    +node.appendChild(newNode);  // This will throw a TypeError exception.
    +
    +

    3.2.1. Constants

    +

    A constant is a declaration (matching Const) used to bind a constant value to a name. +Constants can appear on interfaces.

    +

    Constants have in the past primarily been used to define + named integer codes in the style of an enumeration. The Web platform + is moving away from this design pattern in favor of the use of strings. + Specification authors who wish to define constants are strongly advised to discuss + this on the public-script-coord@w3.org mailing list before proceeding.

    +
    const type constant_identifier = 42;
    +

    The identifier of a constant must not be the same as the identifier +of another interface member defined on the same interface. +The identifier also must not +be “length”, “name” or “prototype”.

    +

    Note: These three names are the names of properties that exist on all Function objects.

    +

    The type of a constant (matching ConstType) +must not be any type other than +a primitive type or a nullable primitive type. +If an identifier is used, +it must reference a typedef whose type is a primitive type or a nullable primitive type.

    +

    The ConstValue part of a +constant declaration gives the value of the constant, which can be +one of the two boolean literal tokens (true and false), +the null token, an integer token, +a float token, +or one of the three special floating point constant values +(-Infinity, Infinity and NaN).

    +

    Note: These values – in addition to strings and the empty sequence – can also be used to specify the default value of a dictionary member or of an optional argument. Note that strings and the +empty sequence [] cannot be used as the value of a constant.

    +

    The value of the boolean literal tokens true and false are the IDL boolean values true and false.

    +

    The value of an integer token is an integer +whose value is determined as follows:

    +
      +
    1. +

      Let S be the sequence of characters matched by the integer token.

      +
    2. +

      Let sign be −1 if S begins with U+002D HYPHEN-MINUS ("-"), and 1 otherwise.

      +
    3. +

      Let base be the base of the number based on the characters that follow the optional leading U+002D HYPHEN-MINUS ("-") character:

      +
      +
      +

      U+0030 DIGIT ZERO ("0"), U+0058 LATIN CAPITAL LETTER X ("X")

      +
      +

      U+0030 DIGIT ZERO ("0"), U+0078 LATIN SMALL LETTER X ("x")

      +
      +

      The base is 16.

      +
      +

      U+0030 DIGIT ZERO ("0")

      +
      +

      The base is 8.

      +
      +

      Otherwise

      +
      +

      The base is 10.

      +
      +
    4. +

      Let number be the result of interpreting all remaining characters following the optional leading U+002D HYPHEN-MINUS ("-") character and any characters indicating the base as an integer specified in base base.

      +
    5. +

      Return sign × number.

      +
    +

    The type of an integer token is the same +as the type of the constant, dictionary member or optional argument it is being used as the value of. +The value of the integer token must not +lie outside the valid range of values for its type, as given in §3.11 Types.

    +

    The value of a float token is + either an IEEE 754 single-precision floating point number or an IEEE 754 + double-precision floating point number, depending on the type of the + constant, dictionary member or optional argument it is being used as the value for, determined as follows:

    +
      +
    1. +

      Let S be the sequence of characters matched by the float token.

      +
    2. +

      Let value be the Mathematical Value that would be obtained if S were +parsed as an ECMAScript NumericLiteral.

      +
    3. +

      If the float token is being +used as the value for a float or unrestricted float, then +the value of the float token +is the IEEE 754 single-precision floating point number closest to result. Otherwise, the float token is being +used as the value for a double or unrestricted double, and +the value of the float token +is the IEEE 754 double-precision floating point number closest to result. [IEEE-754]

      +
    +

    The value of a constant value specified as Infinity, -Infinity or NaN is either +an IEEE 754 single-precision floating point number or an IEEE 754 +double-precision floating point number, depending on the type of the +constant, dictionary member or optional argument is is being used as the +value for:

    +
    +
    +

    Type unrestricted float, constant value Infinity

    +
    +

    The value is the IEEE 754 single-precision positive infinity value.

    +
    +

    Type unrestricted double, constant value Infinity

    +
    +

    The value is the IEEE 754 double-precision positive infinity value.

    +
    +

    Type unrestricted float, constant value -Infinity

    +
    +

    The value is the IEEE 754 single-precision negative infinity value.

    +
    +

    Type unrestricted double, constant value -Infinity

    +
    +

    The value is the IEEE 754 double-precision negative infinity value.

    +
    +

    Type unrestricted float, constant value NaN

    +
    +

    The value is the IEEE 754 single-precision NaN value with the bit pattern 0x7fc00000.

    +
    +

    Type unrestricted double, constant value NaN

    +
    +

    The value is the IEEE 754 double-precision NaN value with the bit pattern 0x7ff8000000000000.

    +
    +

    The type of a float token is the same +as the type of the constant, dictionary member or optional argument it is being used as the value of. The value of the float token must not +lie outside the valid range of values for its type, as given in §3.11 Types. +Also, Infinity, -Infinity and NaN must not +be used as the value of a float or double.

    +

    The value of the null token is the special null value that is a member of the nullable types. The type of +the null token is the same as the +type of the constant, dictionary member or optional argument it is being used as the value of.

    +

    If VT is the type of the value assigned to a constant, and DT is the type of the constant, dictionary member or optional argument itself, then these types must +be compatible, which is the case if DT and VT are identical, +or DT is a nullable type whose inner type is VT.

    +

    Constants are not associated with +particular instances of the interface on which they appear. It is language binding specific whether constants are exposed on instances.

    +
    +

    The ECMAScript language binding does however + allow constants to be accessed + through objects implementing the IDL interfaces on which the constants are declared. + For example, with the following IDL:

    +
    interface A {
    +  const short rambaldi = 47;
     };
    -
    -partial dictionary A {
    -  long h;
    -  long d;
    -};
    -

    - the order of the dictionary members - of a dictionary value of type C is - c, d, g, h, a, b, e, f. -

    -

    - Dictionaries are required to have their members ordered because - in some language bindings the behavior observed when passing - a dictionary value to a platform object depends on the order - the dictionary members are fetched. For example, consider the - following additional interface: -

    -
    IDL
    interface Something {
    -  void f(A a);
    -};
    -

    - and this ECMAScript code: -

    -
    ECMAScript
    var something = getSomething();  // Get an instance of Something.
    -var x = 0;
    -
    -var dict = { };
    -Object.defineProperty(dict, "d", { get: function() { return ++x; } });
    -Object.defineProperty(dict, "c", { get: function() { return ++x; } });
    -
    -something.f(dict);
    -

    - The order that the dictionary members are fetched in determines - what values they will be taken to have. Since the order for - A is defined to be c then d, - the value for c will be 1 and the value for d will be 2. -

    -
    -

    - The identifier of a dictionary member MUST NOT be - the same as that of another dictionary member defined on the dictionary or - on that dictionary’s inherited dictionaries. -

    -

    - Dictionaries MUST NOT be used as the type of an - attribute or - constant. -

    -

    - The following extended attributes are applicable to dictionaries: - [Constructor], - [Exposed], - [SecureContext], -

    -

    - The following extended attributes are applicable to dictionary members: - [Clamp], - [EnforceRange]. -

    -
    [6]Partial"partial" PartialDefinition
    [7]PartialDefinitionPartialInterface
     | - PartialDictionary
     | - Namespace
    [11]Dictionary"dictionary" identifier Inheritance "{" DictionaryMembers "}" ";"
    [12]DictionaryMembersExtendedAttributeList DictionaryMember DictionaryMembers
     | - ε
    [13]DictionaryMemberRequired Type identifier Default ";"
    [15]PartialDictionary"dictionary" identifier "{" DictionaryMembers "}" ";"
    [16]Default"=" DefaultValue
     | - ε
    [17]DefaultValueConstValue
     | - string
     | - "[" "]"
    [18]Inheritance":" identifier
     | - ε
    -
    Example
    -

    - One use of dictionary types is to allow a number of optional arguments to - an operation without being - constrained as to the order they are specified at the call site. For example, - consider the following IDL fragment: -

    -
    IDL
    [Constructor]
    -interface Point {
    -  attribute double x;
    -  attribute double y;
    +
    +

    the constant value can be accessed in ECMAScript either as A.rambaldi or instanceOfA.rambaldi.

    +
    +

    The following extended attributes are applicable to constants: +[Exposed], +[SecureContext].

    +
    Const :
    +    "const" ConstType identifier "=" ConstValue ";"
    +
    +
    ConstValue :
    +    BooleanLiteral
    +    FloatLiteral
    +    integer
    +    "null"
    +
    +
    BooleanLiteral :
    +    "true"
    +    "false"
    +
    +
    FloatLiteral :
    +    float
    +    "-Infinity"
    +    "Infinity"
    +    "NaN"
    +
    +
    ConstType :
    +    PrimitiveType Null
    +    identifier Null
    +
    +
    + +

    The following IDL fragment demonstrates how constants of the above types can be defined.

    +
    interface Util {
    +  const boolean DEBUG = false;
    +  const octet LF = 10;
    +  const unsigned long BIT_MASK = 0x0000fc00;
    +  const double AVOGADRO = 6.022e23;
     };
    -
    -dictionary PaintOptions {
    -  DOMString? fillPattern = "black";
    -  DOMString? strokePattern = null;
    -  Point position;
    +
    +
    +

    3.2.2. Attributes

    +

    An attribute is an interface member (matching inherit ReadOnly AttributeRest, static ReadOnly AttributeRest, stringifier ReadOnly AttributeRest, +or ReadOnly AttributeRest) +that is used to declare data fields with a given type and identifier whose value can +be retrieved and (in some cases) changed. There are two kinds of attributes:

    +
      +
    1. +

      regular attributes, which are those +used to declare that objects implementing the interface will have a data field member with the given identifier

      +
      interface interface_identifier {
      +  attribute type identifier;
       };
      -
      -interface GraphicsContext {
      -  void drawRectangle(double width, double height, optional PaintOptions options);
      -};
    -

    - In an ECMAScript implementation of the IDL, an Object - can be passed in for the optional PaintOptions dictionary: -

    -
    ECMAScript
    // Get an instance of GraphicsContext.
    -var ctx = getGraphicsContext();
    -
    -// Draw a rectangle.
    -ctx.drawRectangle(300, 200, { fillPattern: "red", position: new Point(10, 10) });
    -

    - Both fillPattern and strokePattern are given default values, - so if they are omitted, the definition of drawRectangle can assume that they - have the given default values and not include explicit wording to handle - their non-presence. -

    -
    -
    - -
    -

    3.5. Exceptions

    - -

    - An exception is a type of object that - represents an error and which can be thrown or treated as a first - class value by implementations. Web IDL does not allow exceptions - to be defined, but instead has a number of pre-defined exceptions - that specifications can reference and throw in their definition of - operations, attributes, and so on. Exceptions have an - error name, - a DOMString, - which is the type of error the exception represents, and a - message, which is an optional, - user agent-defined value that provides human readable details of the error. -

    -

    - There are two kinds of exceptions available to be thrown from specifications. - The first is a simple exception, which - is identified by one of the following names: -

    -
      -
    • Error
    • -
    • EvalError
    • -
    • RangeError
    • -
    • ReferenceError
    • -
    • TypeError
    • -
    • URIError
    • -
    -

    - These correspond to all of the ECMAScript error objects ([ECMA-262], section 19.5) (apart from - SyntaxError, which is deliberately omitted as - it is for use only by the ECMAScript parser). - The meaning of - each simple exception matches - its corresponding Error object in the - ECMAScript specification. -

    -

    - The second kind of exception is a DOMException, - which is an exception that encapsulates a name and an optional integer code, - for compatibility with historically defined exceptions in the DOM. -

    -

    - For simple exceptions, - the error name is the name - of the exception. - For a DOMException, - the error name MUST - be one of the names listed in the error names table - below. The table also indicates the DOMException's integer code - for that error name, if it has one. -

    -

    - There are two types that can be used to refer to - exception objects: Error, which encompasses all exceptions, - and DOMException which includes just DOMException objects. - This allows for example an operation - to be declared to have a DOMException - return type or an attribute - to be of type Error. -

    -

    - Exceptions can be created by providing its - error name. - Exceptions can also be thrown, by providing the - same details required to create one. -

    -

    - The resulting behavior from creating and throwing an exception is language binding-specific. -

    -
    Note
    -

    - See section 4.14 - below for details on what creating and throwing an exception - entails in the ECMAScript language binding. -

    -
    -
    Example
    -

    - Here is are some examples of wording to use to create and throw exceptions. - To throw a new simple exception named - TypeError: -

    -
    -

    Throw a TypeError.

    -
    -

    - To throw a new DOMException with - error name - IndexSizeError: -

    -
    -

    Throw an IndexSizeError.

    -
    -

    - To create a new DOMException with - error name - SyntaxError: -

    -
    -

    Let object be a newly created SyntaxError.

    -
    -
    - -
    -

    3.5.1. Error names

    - -

    - The error names table below lists all the allowed error names - for DOMExceptions, a description, - and legacy code values. -

    - -
    Note
    -

    If an error name is not listed here, please file a bug as indicated at the top of this specification and it will be addressed shortly. Thanks!

    -
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    NameDescriptionLegacy code name and value
    "IndexSizeError"The index is not in the allowed range.INDEX_SIZE_ERR (1)
    "HierarchyRequestError"The operation would yield an incorrect node tree.HIERARCHY_REQUEST_ERR (3)
    "WrongDocumentError"The object is in the wrong document.WRONG_DOCUMENT_ERR (4)
    "InvalidCharacterError"The string contains invalid characters.INVALID_CHARACTER_ERR (5)
    "NoModificationAllowedError"The object can not be modified.NO_MODIFICATION_ALLOWED_ERR (7)
    "NotFoundError"The object can not be found here.NOT_FOUND_ERR (8)
    "NotSupportedError"The operation is not supported.NOT_SUPPORTED_ERR (9)
    "InUseAttributeError"The attribute is in use.INUSE_ATTRIBUTE_ERR (10)
    "InvalidStateError"The object is in an invalid state.INVALID_STATE_ERR (11)
    "SyntaxError"The string did not match the expected pattern.SYNTAX_ERR (12)
    "InvalidModificationError"The object can not be modified in this way.INVALID_MODIFICATION_ERR (13)
    "NamespaceError"The operation is not allowed by Namespaces in XML. [XMLNS]NAMESPACE_ERR (14)
    "InvalidAccessError"The object does not support the operation or argument.INVALID_ACCESS_ERR (15)
    "SecurityError"The operation is insecure.SECURITY_ERR (18)
    "NetworkError"A network error occurred.NETWORK_ERR (19)
    "AbortError"The operation was aborted.ABORT_ERR (20)
    "URLMismatchError"The given URL does not match another URL.URL_MISMATCH_ERR (21)
    "QuotaExceededError"The quota has been exceeded.QUOTA_EXCEEDED_ERR (22)
    "TimeoutError"The operation timed out.TIMEOUT_ERR (23)
    "InvalidNodeTypeError"The supplied node is incorrect or has an incorrect ancestor for this operation.INVALID_NODE_TYPE_ERR (24)
    "DataCloneError"The object can not be cloned.DATA_CLONE_ERR (25)
    "EncodingError"The encoding operation (either encoded or decoding) failed.
    "NotReadableError"The I/O read operation failed.
    "UnknownError"The operation failed for an unknown transient reason (e.g. out of memory).
    "ConstraintError"A mutation operation in a transaction failed because a constraint was not satisfied.
    "DataError"Provided data is inadequate.
    "TransactionInactiveError"A request was placed against a transaction which is currently not active, or which is finished.
    "ReadOnlyError"The mutating operation was attempted in a "readonly" transaction.
    "VersionError"An attempt was made to open a database using a lower version than the existing version.
    "OperationError"The operation failed for an operation-specific reason.
    "NotAllowedError"The request is not allowed by the user agent or the platform in the current context, possibly because the user denied permission.
    -
    -
    - -
    -

    3.6. Enumerations

    - -

    - An enumeration is a definition (matching - Enum) used to declare a type - whose valid values are a set of predefined strings. Enumerations - can be used to restrict the possible - DOMString values that can be assigned to an - attribute or passed to an - operation. -

    -
    enum identifier { enumeration-values… };
    -

    - The enumeration values are specified - as a comma-separated list of string literals. - The list of enumeration values - MUST NOT include duplicates. -

    -
    Warning
    -

    - It is strongly suggested that enumeration values be all lowercase, - and that multiple words be separated using dashes or not be - separated at all, unless there is a specific reason to use another - value naming scheme. For example, an enumeration value that - indicates an object should be created could be named - "createobject" or "create-object". - Consider related uses of enumeration values when deciding whether - to dash-separate or not separate enumeration value words so that - similar APIs are consistent. -

    -
    -

    - The behavior when a string value that is not one a valid enumeration value - is used when assigning to an attribute, - or passed as an operation argument, - whose type is the enumeration, is language binding specific. -

    -
    Note
    -

    - In the ECMAScript binding, assignment of an invalid string value to an - attribute is ignored, while - passing such a value as an operation argument - results in an exception being thrown. -

    -
    -

    - No extended attributes - defined in this specification are applicable to enumerations. -

    - -
    [19]Enum"enum" identifier "{" EnumValueList "}" ";"
    [20]EnumValueListstring EnumValueListComma
    [21]EnumValueListComma"," EnumValueListString
     | - ε
    [22]EnumValueListStringstring EnumValueListComma
     | - ε
    - -
    Example
    -

    - The following IDL fragment - defines an enumeration - that is used as the type of an attribute - and an operation argument: -

    -
    IDL
    enum MealType { "rice", "noodles", "other" };
    -
    -interface Meal {
    -  attribute MealType type;
    -  attribute double size;     // in grams
    -
    -  void initialize(MealType type, double size);
    -};
    -

    - An ECMAScript implementation would restrict the strings that can be - assigned to the type property or passed to the initializeMeal function - to those identified in the enumeration. -

    -
    ECMAScript
    var meal = getMeal();                // Get an instance of Meal.
    -
    -meal.initialize("rice", 200);        // Operation invoked as normal.
    -
    -try {
    -  meal.initialize("sandwich", 100);  // Throws a TypeError.
    -} catch (e) {
    -}
    -
    -meal.type = "noodles";               // Attribute assigned as normal.
    -meal.type = "dumplings";             // Attribute assignment ignored.
    -meal.type == "noodles";              // Evaluates to true.
    -
    -
    - -
    -

    3.7. Callback functions

    - -
    Editorial note
    -

    The “Custom DOM Elements” spec wants to use callback function types for - platform object provided functions. Should we rename “callback functions” to - just “functions” to make it clear that they can be used for both purposes?

    -
    -

    - A callback function is a definition (matching - "callback" CallbackRest) used to declare a function type. -

    -
    callback identifier = return-type (arguments…);
    -
    Note
    -

    See also the similarly named callback interfaces.

    -
    -

    - The identifier on the - left of the equals sign gives the name of the callback function - and the return type and argument list (matching ReturnType - and ArgumentList) on the right side of the equals - sign gives the signature of the callback function type. -

    -

    - Callback functions MUST NOT - be used as the type of a constant. -

    -

    - The following extended attribute is applicable to callback functions: - [TreatNonObjectAsNull]. -

    - -
    [3]CallbackOrInterface"callback" CallbackRestOrInterface
     | - Interface
    [4]CallbackRestOrInterfaceCallbackRest
     | - Interface
    [23]CallbackRestidentifier "=" ReturnType "(" ArgumentList ")" ";"
    - -
    Example
    -

    - The following IDL fragment defines - a callback function used for an API that - invokes a user-defined function when an operation is complete. -

    -
    IDL
    callback AsyncOperationCallback = void (DOMString status);
    -
    -interface AsyncOperations {
    -  void performOperation(AsyncOperationCallback whenFinished);
    -};
    -

    - In the ECMAScript language binding, a Function object is - passed as the operation argument. -

    -
    ECMAScript
    var ops = getAsyncOperations();  // Get an instance of AsyncOperations.
    -
    -ops.performOperation(function(status) {
    -  window.alert("Operation finished, status is " + status + ".");
    -});
    -
    -
    - -
    -

    3.8. Typedefs

    - -

    - A typedef is a definition (matching - Typedef) - used to declare a new name for a type. This new name is not exposed - by language bindings; it is purely used as a shorthand for referencing - the type in the IDL. -

    -
    typedef type identifier;
    -

    - The type being given a new name is specified after the typedef - keyword (matching Type), and the - identifier token following the - type gives the name. -

    -

    - The Type MUST NOT - identify the same or another typedef. -

    -

    - No extended attributes - defined in this specification are applicable to typedefs. -

    - -
    [24]Typedef"typedef" Type identifier ";"
    - -
    Example
    -

    - The following IDL fragment - demonstrates the use of typedefs - to allow the use of a short - identifier instead of a long - sequence type. -

    -
    IDL
    interface Point {
    -  attribute double x;
    -  attribute double y;
    +
    +
  • +

    static attributes, which are used +to declare attributes that are not associated with a particular object implementing the interface

    +
    interface interface_identifier {
    +  static attribute type identifier;
     };
    -
    -typedef sequence<Point> Points;
    -
    -interface Widget {
    -  boolean pointWithinBounds(Point p);
    -  boolean allPointsWithinBounds(Points ps);
    -};
  • -
    -
    - -
    -

    3.9. Implements statements

    - -

    - An implements statement is a definition - (matching ImplementsStatement) - used to declare that all objects implementing an interface A - (identified by the first identifier) - MUST additionally implement interface B - (identified by the second identifier), including all other interfaces that - B inherits from. -

    -
    identifier-A implements identifier-B;
    -

    - Transitively, if objects implementing B - are declared with an implements statement - to additionally implement interface C, then all objects implementing - A do additionally implement interface C. -

    -

    - The two identifiers MUST - identify two different interfaces. -

    -

    - The interface identified on the left-hand side of an implements statement - MUST NOT inherit - from the interface identifier on the right-hand side, and vice versa. Both identified - interfaces also MUST NOT be - callback interfaces. -

    -

    - If each implements statement is - considered to be an edge in a directed graph, from a node representing the interface - on the left-hand side of the statement to a node representing the interface on the - right-hand side, then this graph MUST NOT have any cycles. -

    -

    - Interfaces that a given object implements are partitioned into those that are considered - supplemental interfaces and those that are not. - An interface A is considered to be a - supplemental interface of an object - O if: -

    -
      -
    • O implements a different interface B, and the IDL states that - B implements A; or
    • -
    • O implements a different supplemental interface - C, and C inherits from A.
    • -
    -
    Note
    -

    - Specification authors are discouraged from writing implements statements - where the interface on the left-hand side - is a supplemental interface. - For example, if author 1 writes: -

    -
    IDL
    interface Window { ... };
    -interface SomeFunctionality { ... };
    -Window implements SomeFunctionality;
    -

    - and author 2 later writes: -

    -
    IDL
    interface Gizmo { ... };
    -interface MoreFunctionality { ... };
    -SomeFunctionality implements MoreFunctionality;
    -Gizmo implements SomeFunctionality;
    -

    - then it might be the case that author 2 is unaware of exactly which - interfaces already are used on the left-hand side of an - implements SomeFunctionality statement, and so has - required more objects implement MoreFunctionality - than he or she expected. -

    -

    - Better in this case would be for author 2 to write: -

    -
    IDL
    interface Gizmo { ... };
    -interface MoreFunctionality { ... };
    -Gizmo implements SomeFunctionality;
    -Gizmo implements MoreFunctionality;
    -
    -

    - The consequential interfaces of an interface - A are: -

    -
      -
    • each interface B where the IDL states A implements B;
    • -
    • each interface that a consequential interface of A inherits from; and
    • -
    • each interface D where the IDL states that C implements D, - where C is a consequential interface of A.
    • -
    -

    - For a given interface, there MUST NOT - be any member defined on any of its consequential interfaces - whose identifier is the same as any other member defined on any - of those consequential interfaces or on the original interface itself. -

    -
    Note
    -

    For example, that precludes the following:

    -
    IDL
    interface A { attribute long x; };
    -interface B { attribute long x; };
    -A implements B;  // B::x would clash with A::x
    -
    -interface C { attribute long y; };
    -interface D { attribute long y; };
    -interface E : D { };
    -C implements E;  // D::y would clash with C::y
    -
    -interface F { };
    -interface H { attribute long z; };
    -interface I { attribute long z; };
    -F implements H;
    -F implements I;  // H::z and I::z would clash when mixed in to F
    -
    -

    - No extended attributes - defined in this specification are applicable to - implements statements. -

    - -
    [25]ImplementsStatementidentifier "implements" identifier ";"
    - -
    Example
    -

    - The following IDL fragment - defines two interfaces, stating - that one interface is always implemented on objects implementing the other. -

    -
    IDL
    interface Entry {
    -  readonly attribute unsigned short entryType;
    -  // ...
    +
    + +

    If an attribute has no static keyword, then it declares a regular attribute. Otherwise, +it declares a static attribute.

    +

    The identifier of an attribute must not be the same as the identifier +of another interface member defined on the same interface. +The identifier of a static attribute must not +be “prototype”.

    +

    The type of the attribute is given by the type (matching Type) +that appears after the attribute keyword. +If the Type is an identifier or an identifier followed by ?, +then the identifier must +identify an interface, enumeration, callback function or typedef.

    +

    The type of the attribute, after resolving typedefs, must not be a nullable or non-nullable version of any of the following types:

    + +

    The attribute is read only if the readonly keyword is used before the attribute keyword. +An object that implements the interface on which a read only attribute +is defined will not allow assignment to that attribute. It is language +binding specific whether assignment is simply disallowed by the language, +ignored or an exception is thrown.

    +
    interface interface_identifier {
    +  readonly attribute type identifier;
     };
    -
    -interface Observable {
    -  void addEventListener(DOMString type,
    -                        EventListener listener,
    -                        boolean useCapture);
    -  // ...
    +
    +

    A regular attribute that is not read only can be declared to inherit its getter from an ancestor interface. This can be used to make a read only attribute +in an ancestor interface be writable on a derived interface. An attribute inherits its getter if +its declaration includes inherit in the declaration. +The read only attribute from which the attribute inherits its getter +is the attribute with the same identifier on the closest ancestor interface +of the one on which the inheriting attribute is defined. The attribute +whose getter is being inherited must be +of the same type as the inheriting attribute, and inherit must not appear on a read only attribute or a static attribute.

    +
    interface Ancestor {
    +  readonly attribute TheType theIdentifier;
     };
    -
    -Entry implements Observable;
    -

    - An ECMAScript implementation would thus have an “addEventListener” - property in the prototype chain of every Entry: -

    -
    ECMAScript
    var e = getEntry();          // Obtain an instance of Entry.
    -typeof e.addEventListener;  // Evaluates to "function".
    - -

    - Note that it is not the case that all Observable - objects implement Entry. -

    -
    -
    - -
    -

    3.10. Objects implementing interfaces

    - -

    - In a given implementation of a set of IDL fragments, - an object can be described as being a platform object, a - user object, or neither. There are two kinds of - object that are considered to be platform objects: -

    - -

    - In a browser, for example, - the browser-implemented DOM objects (implementing interfaces such as Node and - Document) that provide access to a web page’s contents - to ECMAScript running in the page would be platform objects. These objects might be exotic objects, - implemented in a language like C++, or they might be native ECMAScript objects. Regardless, - an implementation of a given set of IDL fragments needs to be able to recognize all platform objects - that are created by the implementation. This might be done by having some internal state that records whether - a given object is indeed a platform object for that implementation, or perhaps by observing - that the object is implemented by a given internal C++ class. How exactly platform objects - are recognised by a given implementation of a set of IDL fragments is implementation specific. -

    -

    - All other objects in the system would not be treated as platform objects. For example, assume that - a web page opened in a browser loads an ECMAScript library that implements DOM Core. This library - would be considered to be a different implementation from the browser provided implementation. - The objects created by the ECMAScript library that implement the Node interface - will not be treated as platform objects that implement Node by the browser implementation. -

    -

    - User objects are those that authors would create, implementing - callback interfaces that the Web APIs use to be able to invoke author-defined - operations or to send and receive values to the author’s program through - manipulating the object’s attributes. In a web page, an ECMAScript object - that implements the EventListener interface, which is - used to register a callback that the DOM Events implementation invokes, would be considered - to be a user object. -

    -

    - Note that user objects can only implement callback interfaces - and platform objects can only implement non-callback interfaces. -

    - -
    - - - -
    -

    3.11. Types

    - -

    - This section lists the types supported by Web IDL, the set of values - corresponding to each type, and how constants - of that type are represented. -

    -

    - The following types are known as integer types: - byte, - octet, - short, - unsigned short, - long, - unsigned long, - long long and - unsigned long long. -

    -

    - The following types are known as numeric types: - the integer types, - float, - unresticted float, - double and - unrestricted double. -

    -

    - The primitive types are - boolean and the numeric types. -

    -

    - The string types are - DOMString, all enumeration types, - ByteString and USVString. -

    -

    - The exception types are - Error and DOMException. -

    -

    - The typed array types are - Int8Array, - Int16Array, - Int32Array, - Uint8Array, - Uint16Array, - Uint32Array, - Uint8ClampedArray, - Float32Array and - Float64Array. -

    -

    - The buffer source types - are ArrayBuffer, - DataView, - and the typed array types. -

    -

    - The object type, - all interface types - and the exception types - are known as object types. -

    -

    - Every type has a type name, which - is a string, not necessarily unique, that identifies the type. - Each sub-section below defines what the type name is for each - type. -

    -

    - When conversions are made from language binding specific types to - IDL types in order to invoke an operation - or assign a value to an attribute, - all conversions necessary will be performed before the - specified functionality of the operation or attribute assignment - is carried out. If the conversion cannot - be performed, then the operation will not run or - the attribute will not be updated. In some language bindings, - type conversions could result in an exception being thrown. - In such cases, these exceptions will be propagated to the - code that made the attempt to invoke the operation or - assign to the attribute. -

    - -
    [73]TypeSingleType
     | - UnionType Null
    [74]SingleTypeNonAnyType
     | - "any"
    [75]UnionType"(" UnionMemberType "or" UnionMemberType UnionMemberTypes ")"
    [76]UnionMemberTypeNonAnyType
     | - UnionType Null
    [77]UnionMemberTypes"or" UnionMemberType UnionMemberTypes
     | - ε
    [78]NonAnyTypePrimitiveType Null
     | - PromiseType Null
     | - "ByteString" Null
     | - "DOMString" Null
     | - "USVString" Null
     | - identifier Null
     | - "sequence" "<" Type ">" Null
     | - "object" Null
     | - "RegExp" Null
     | - "Error" Null
     | - "DOMException" Null
     | - BufferRelatedType Null
     | - "FrozenArray" "<" Type ">" Null
    [80]ConstTypePrimitiveType Null
     | - identifier Null
    [81]PrimitiveTypeUnsignedIntegerType
     | - UnrestrictedFloatType
     | - "boolean"
     | - "byte"
     | - "octet"
    [82]UnrestrictedFloatType"unrestricted" FloatType
     | - FloatType
    [83]FloatType"float"
     | - "double"
    [84]UnsignedIntegerType"unsigned" IntegerType
     | - IntegerType
    [85]IntegerType"short"
     | - "long" OptionalLong
    [86]OptionalLong"long"
     | - ε
    [87]PromiseType"Promise" "<" ReturnType ">"
    [88]Null"?"
     | - ε
    - -
    -

    3.11.1. any

    - -

    - The any type is the union of all other possible - non-union types. - Its type name is “Any”. -

    -

    - The any type is like - a discriminated union type, in that each of its values has a - specific non-any type - associated with it. For example, one value of the - any type is the - unsigned long - 150, while another is the long 150. - These are distinct values. -

    -

    - The particular type of an any - value is known as its specific type. - (Values of union types also have - specific types.) -

    -
    - -
    -

    3.11.2. boolean

    - -

    - The boolean type has two values: - true and false. -

    -

    - boolean constant values in IDL are - represented with the true and - false tokens. -

    -

    - The type name of the - boolean type is “Boolean”. -

    -
    - -
    -

    3.11.3. byte

    - -

    - The byte type is a signed integer - type that has values in the range [−128, 127]. -

    -

    - byte constant values in IDL are - represented with integer - tokens. -

    -

    - The type name of the - byte type is “Byte”. -

    -
    - -
    -

    3.11.4. octet

    - -

    - The octet type is an unsigned integer - type that has values in the range [0, 255]. -

    -

    - octet constant values in IDL are - represented with integer - tokens. -

    -

    - The type name of the - octet type is “Octet”. -

    -
    - -
    -

    3.11.5. short

    - -

    - The short type is a signed integer - type that has values in the range [−32768, 32767]. -

    -

    - short constant values in IDL are - represented with integer - tokens. -

    -

    - The type name of the - short type is “Short”. -

    -
    - -
    -

    3.11.6. unsigned short

    - -

    - The unsigned short type is an unsigned integer - type that has values in the range [0, 65535]. -

    -

    - unsigned short constant values in IDL are - represented with integer - tokens. -

    -

    - The type name of the - unsigned short type is “UnsignedShort”. -

    -
    - -
    -

    3.11.7. long

    - -

    - The long type is a signed integer - type that has values in the range [−2147483648, 2147483647]. -

    -

    - long constant values in IDL are - represented with integer - tokens. -

    -

    - The type name of the - long type is “Long”. -

    -
    - -
    -

    3.11.8. unsigned long

    - -

    - The unsigned long type is an unsigned integer - type that has values in the range [0, 4294967295]. -

    -

    - unsigned long constant values in IDL are - represented with integer - tokens. -

    -

    - The type name of the - unsigned long type is “UnsignedLong”. -

    -
    - -
    -

    3.11.9. long long

    - -

    - The long long type is a signed integer - type that has values in the range [−9223372036854775808, 9223372036854775807]. -

    -

    - long long constant values in IDL are - represented with integer - tokens. -

    -

    - The type name of the - long long type is “LongLong”. -

    -
    - -
    -

    3.11.10. unsigned long long

    - -

    - The unsigned long long type is an unsigned integer - type that has values in the range [0, 18446744073709551615]. -

    -

    - unsigned long long constant values in IDL are - represented with integer - tokens. -

    -

    - The type name of the - unsigned long long type is “UnsignedLongLong”. -

    -
    - -
    -

    3.11.11. float

    - -

    - The float type is a floating point numeric - type that corresponds to the set of finite single-precision 32 bit - IEEE 754 floating point numbers. [IEEE-754] -

    -

    - float constant values in IDL are - represented with float - tokens. -

    -

    - The type name of the - float type is “Float”. -

    -
    Warning
    -

    - Unless there are specific reasons to use a 32 bit floating point type, - specifications SHOULD use - double rather than float, - since the set of values that a double can - represent more closely matches an ECMAScript Number. -

    -
    -
    - -
    -

    3.11.12. unrestricted float

    - -

    - The unrestricted float type is a floating point numeric - type that corresponds to the set of all possible single-precision 32 bit - IEEE 754 floating point numbers, finite and non-finite. [IEEE-754] -

    -

    - unrestricted float constant values in IDL are - represented with float - tokens. -

    -

    - The type name of the - unrestricted float type is “UnrestrictedFloat”. -

    -
    - -
    -

    3.11.13. double

    - -

    - The double type is a floating point numeric - type that corresponds to the set of finite double-precision 64 bit - IEEE 754 floating point numbers. [IEEE-754] -

    -

    - double constant values in IDL are - represented with float - tokens. -

    -

    - The type name of the - double type is “Double”. -

    -
    - -
    -

    3.11.14. unrestricted double

    - -

    - The unrestricted double type is a floating point numeric - type that corresponds to the set of all possible double-precision 64 bit - IEEE 754 floating point numbers, finite and non-finite. [IEEE-754] -

    -

    - unrestricted double constant values in IDL are - represented with float - tokens. -

    -

    - The type name of the - unrestricted double type is “UnrestrictedDouble”. -

    -
    - -
    -

    3.11.15. DOMString

    - -

    - The DOMString type - corresponds to the set of all possible sequences of code units. - Such sequences are commonly interpreted as UTF-16 encoded strings [RFC2781] - although this is not required. - While DOMString is defined to be an OMG IDL boxed - sequence<unsigned short> - valuetype in DOM Level 3 Core - ([DOM3CORE], section 1.2.1), - this document defines DOMString to be an intrinsic type so as to avoid - special casing that sequence type in various situations where a - string is required. -

    -
    Note
    -

    - Note also that null - is not a value of type DOMString. - To allow null, a - nullable DOMString, - written as DOMString? in IDL, needs to be used. -

    -
    -

    - Nothing in this specification requires a DOMString - value to be a valid UTF-16 string. For example, a DOMString - value might include unmatched surrogate pair characters. However, authors - of specifications using Web IDL might want to obtain a sequence of - Unicode scalar values given a particular sequence of - code units. - The following algorithm defines a way to - convert a DOMString to a sequence of Unicode scalar values: -

    -
      -
    1. Let S be the DOMString value.
    2. -
    3. Let n be the length of S.
    4. -
    5. Initialize i to 0.
    6. -
    7. Initialize U to be an empty sequence of Unicode characters.
    8. -
    9. While i < n: -
        -
      1. Let c be the code unit in S at index i.
      2. -
      3. Depending on the value of c: -
        -
        c < 0xD800 or c > 0xDFFF
        -
        Append to U the Unicode character with code point c.
        - -
        0xDC00 ≤ c ≤ 0xDFFF
        -
        Append to U a U+FFFD REPLACEMENT CHARACTER.
        - -
        0xD800 ≤ c ≤ 0xDBFF
        -
        -
          -
        1. If i = n−1, then append to U a U+FFFD REPLACEMENT CHARACTER.
        2. -
        3. Otherwise, i < n−1: -
            -
          1. Let d be the code unit in S at index - i+1.
          2. -
          3. If 0xDC00 ≤ d ≤ 0xDFFF, then: -
              -
            1. Let a be c & 0x3FF.
            2. -
            3. Let b be d & 0x3FF.
            4. -
            5. Append to U the Unicode character with - code point 216+210a+b.
            6. -
            7. Set i to i+1.
            8. -
            -
          4. -
          5. Otherwise, d < 0xDC00 or d > 0xDFFF. - Append to U a U+FFFD REPLACEMENT CHARACTER.
          6. -
          -
        4. -
        -
        -
        -
      4. -
      5. Set i to i+1.
      6. -
      -
    10. -
    11. Return U.
    12. -
    -

    - There is no way to represent a constant DOMString - value in IDL, although DOMString dictionary member - and operation optional argument default values - can be specified using a string literal. -

    -

    - The type name of the - DOMString type is “String”. -

    -
    - -
    -

    3.11.16. ByteString

    - -

    - The ByteString type - corresponds to the set of all possible sequences of bytes. - Such sequences might be interpreted as UTF-8 encoded strings [RFC3629] - or strings in some other 8-bit-per-code-unit encoding, although this is not required. -

    -

    - There is no way to represent a constant ByteString - value in IDL, although ByteString dictionary member - and operation optional argument default values - can be specified using a string literal. -

    -

    - The type name of the - ByteString type is “ByteString”. -

    -
    Warning
    -

    - Specifications SHOULD only use - ByteString for interfacing with protocols - that use bytes and strings interchangably, such as HTTP. In general, - strings SHOULD be represented with - DOMString values, even if it is expected - that values of the string will always be in ASCII or some - 8 bit character encoding. Sequences, - frozen arrays or Typed Arrays - with octet or byte - elements SHOULD be used for holding - 8 bit data rather than ByteString. - [TYPEDARRAYS] -

    -
    -
    - -
    -

    3.11.17. USVString

    - -

    - The USVString type - corresponds to the set of all possible sequences of - Unicode scalar values, - which are all of the Unicode code points apart from the - surrogate code points. -

    -

    - There is no way to represent a constant USVString - value in IDL, although USVString dictionary member - and operation optional argument default values - can be specified using a string literal. -

    -

    - The type name of the - USVString type is “USVString”. -

    -
    Warning
    -

    - Specifications SHOULD only use - USVString for APIs that perform - text processing and need a string of Unicode - scalar values to operate on. Most APIs that use strings - should instead be using DOMString, - which does not make any interpretations of the code units - in the string. When in doubt, use DOMString. -

    -
    -
    - -
    -

    3.11.18. object

    - -

    - The object type corresponds to the set of - all possible non-null object references. -

    -

    - There is no way to represent a constant object - value in IDL. -

    -

    - To denote a type that includes all possible object references plus the - null value, use the nullable type - object?. -

    -

    - The type name of the - object type is “Object”. -

    -
    - -
    -

    3.11.19. Interface types

    - -

    - An identifier that - identifies an interface is used to refer to - a type that corresponds to the set of all possible non-null references to objects that - implement that interface. -

    -

    - For non-callback interfaces, an IDL value of the interface type is represented just - by an object reference. For callback interfaces, an IDL value of the interface type - is represented by a tuple of an object reference and a callback context. - The callback context is a language - binding specific value, and is used to store information about the execution context at - the time the language binding specific object reference is converted to an IDL value. -

    -
    Note
    -

    For ECMAScript objects, the callback - context is used to hold a reference to the incumbent settings object [HTML] at the time the Object value - is converted to an IDL callback interface type value. See section 4.2.20 below.

    -
    -

    - There is no way to represent a constant object reference value for - a particular interface type in IDL. -

    -

    - To denote a type that includes all possible references to objects implementing - the given interface plus the null value, - use a nullable type. -

    -

    - The type name of an interface type - is the identifier of the interface. -

    -
    - -
    -

    3.11.20. Dictionary types

    - -

    - An identifier that - identifies a dictionary is used to refer to - a type that corresponds to the set of all dictionaries that adhere to - the dictionary definition. -

    -

    - There is no way to represent a constant dictionary value in IDL. -

    -

    - The type name of a dictionary type - is the identifier of the dictionary. -

    -
    - -
    -

    3.11.21. Enumeration types

    - -

    - An identifier that - identifies an enumeration is used to - refer to a type whose values are the set of strings (sequences of - code units, as with - DOMString) that are the - enumeration’s values. -

    -

    - Like DOMString, there is no way to represent a constant enumeration - value in IDL, although enumeration-typed dictionary member - default values can be specified using a - string literal. -

    -

    - The type name of an enumeration type - is the identifier of the enumeration. -

    -
    - -
    -

    3.11.22. Callback function types

    - -

    - An identifier that identifies - a callback function is used to refer to - a type whose values are references to objects that are functions with the given signature. -

    -

    - An IDL value of the callback function type is represented by a tuple of an object - reference and a callback context. -

    -
    Note
    -

    As with callback interface types, the callback context is used to hold a - reference to the incumbent settings object [HTML] at - the time an ECMAScript Object value is converted to an IDL - callback function type value. See section 4.2.23 below.

    -
    -

    - There is no way to represent a constant callback function - value in IDL. -

    -

    - The type name of a callback function type - is the identifier of the callback function. -

    -
    - -
    -

    3.11.23. Nullable types — T?

    - -

    - A nullable type is an IDL type constructed - from an existing type (called the inner type), - which just allows the additional value null - to be a member of its set of values. Nullable types - are represented in IDL by placing a U+003F QUESTION MARK ("?") - character after an existing type. The inner type MUST NOT - be any, - another nullable type, or a union type - that itself has includes a nullable type - or has a dictionary type as one of its - flattened member types. -

    -
    Note
    -

    Although dictionary types can in general be nullable, they cannot when used - as the type of an operation argument or a dictionary member.

    -
    -

    - Nullable type constant values in IDL are represented in the same way that - constant values of their inner type - would be represented, or with the null token. -

    -

    - The type name of a nullable type - is the concatenation of the type name of the inner type T and - the string “OrNull”. -

    -
    Example
    -

    - For example, a type that allows the values true, - false and null - is written as boolean?: -

    -
    IDL
    interface MyConstants {
    -  const boolean? ARE_WE_THERE_YET = false;
    -};
    -

    - The following interface has two - attributes: one whose value can - be a DOMString or the null - value, and another whose value can be a reference to a Node - object or the null value: -

    -
    IDL
    interface Node {
    -  readonly attribute DOMString? namespaceURI;
    -  readonly attribute Node? parentNode;
    -  // ...
    -};
    -
    -
    - -
    -

    3.11.24. Sequences — sequence<T>

    - -

    - The sequence<T> - type is a parameterized type whose values are (possibly zero-length) sequences of - values of type T. -

    -

    - Sequences are always passed by value. In - language bindings where a sequence is represented by an object of - some kind, passing a sequence to a platform object - will not result in a reference to the sequence being kept by that object. - Similarly, any sequence returned from a platform object - will be a copy and modifications made to it will not be visible to the platform object. -

    -

    - There is no way to represent a constant sequence value in IDL. -

    -

    - Sequences MUST NOT be used as the - type of an attribute or - constant. -

    -
    Note
    -

    - This restriction exists so that it is clear to specification writers - and API users that sequences - are copied rather than having references - to them passed around. Instead of a writable attribute of a sequence - type, it is suggested that a pair of operations to get and set the - sequence is used. -

    -
    -

    - The type name of a sequence type - is the concatenation of the type name for T and - the string “Sequence”. -

    -
    - -
    -

    3.11.25. Promise types — Promise<T>

    - -

    - A promise type is a parameterized type - whose values are references to objects that “is used as a place holder - for the eventual results of a deferred (and possibly asynchronous) computation - result of an asynchronous operation” [ECMA-262]. - See section 25.4 - of the ECMAScript specification for details on the semantics of promise objects. -

    -

    - There is no way to represent a promise value in IDL. -

    -

    - The type name of a promise type - is the concatenation of the type name for T and - the string “Promise”. -

    -
    - -
    -

    3.11.26. Union types

    - -

    - A union type is a type whose set of values - is the union of those in two or more other types. Union types (matching - UnionType) - are written as a series of types separated by the or keyword - with a set of surrounding parentheses. - The types which comprise the union type are known as the - union’s member types. -

    -
    Note
    -

    - For example, you might write (Node or DOMString) - or (double or sequence<double>). When applying a - ? suffix to a - union type - as a whole, it is placed after the closing parenthesis, - as in (Node or DOMString)?. -

    -

    - Note that the member types - of a union type do not descend into nested union types. So for - (double or (sequence<long> or Event) or (Node or DOMString)?) the member types - are double, (sequence<long> or Event) and - (Node or DOMString)?. -

    -
    -

    - Like the any type, values of - union types have a specific type, - which is the particular member type - that matches the value. -

    -

    - The flattened member types - of a union type is a set of types - determined as follows: -

    -
      -
    1. Let T be the union type.
    2. -
    3. Initialize S to ∅.
    4. -
    5. For each member type U of T: -
        -
      1. If U is a nullable type, then - set U to be the inner type of U.
      2. -
      3. If U is a union type, then - add to S the flattened member types - of U.
      4. -
      5. Otherwise, U is not a union type. - Add U to S.
      6. -
      -
    6. -
    7. Return S.
    8. -
    -
    Note
    -

    - For example, the flattened member types - of the union type - (Node or (sequence<long> or Event) or (XMLHttpRequest or DOMString)? or sequence<(sequence<double> or NodeList)>) - are the six types Node, sequence<long>, Event, - XMLHttpRequest, DOMString and - sequence<(sequence<double> or NodeList)>. -

    -
    -

    - The number of nullable member types - of a union type is an integer - determined as follows: -

    -
      -
    1. Let T be the union type.
    2. -
    3. Initialize n to 0.
    4. -
    5. For each member type U of T: -
        -
      1. If U is a nullable type, then: -
          -
        1. Set n to n + 1.
        2. -
        3. Set U to be the inner type of U.
        4. -
        -
      2. -
      3. If U is a union type, then: -
          -
        1. Let m be the number - of nullable member types of U.
        2. -
        3. Set n to n + m.
        4. -
      4. -
      -
    6. -
    7. Return n.
    8. -
    -

    - The any type MUST NOT - be used as a union member type. -

    -

    - The number of nullable member types - of a union type MUST - be 0 or 1, and if it is 1 then the union type MUST also not have - a dictionary type in its - flattened member types. -

    -

    - A type includes a nullable type if: -

    - -

    - Each pair of flattened member types - in a union type, T and U, - MUST be distinguishable. -

    -

    - Union type constant values - in IDL are represented in the same way that constant values of their - member types would be - represented. -

    -

    - The type name of a union - type is formed by taking the type names of each member type, in order, - and joining them with the string “Or”. -

    -
    [75]UnionType"(" UnionMemberType "or" UnionMemberType UnionMemberTypes ")"
    [76]UnionMemberTypeNonAnyType
     | - UnionType Null
    [77]UnionMemberTypes"or" UnionMemberType UnionMemberTypes
     | - ε
    [78]NonAnyTypePrimitiveType Null
     | - PromiseType Null
     | - "ByteString" Null
     | - "DOMString" Null
     | - "USVString" Null
     | - identifier Null
     | - "sequence" "<" Type ">" Null
     | - "object" Null
     | - "RegExp" Null
     | - "Error" Null
     | - "DOMException" Null
     | - BufferRelatedType Null
     | - "FrozenArray" "<" Type ">" Null
    -
    - -
    -

    3.11.27. RegExp

    - -

    - The RegExp type is a type - whose values are references to objects that represent regular expressions. - The particular regular expression language and the features it supports - is language binding specific. -

    -

    - There is no way to represent a constant RegExp - value in IDL. -

    -

    - The type name of the - RegExp type is “RegExp”. -

    -
    - -
    -

    3.11.28. Error

    - -

    The Error type corresponds to the - set of all possible non-null references to exception objects, including - simple exceptions - and DOMExceptions.

    -

    - There is no way to represent a constant Error - value in IDL. -

    -

    - The type name of the - Error type is “Error”. -

    -
    - -
    -

    3.11.29. DOMException

    - -

    The DOMException type corresponds to the - set of all possible non-null references to objects - representing DOMExceptions.

    -

    - There is no way to represent a constant DOMException - value in IDL. -

    -

    - The type name of the - DOMException type is “DOMException”. -

    -
    - -
    -

    3.11.30. Buffer source types

    - -

    - There are a number of types that correspond to sets of all possible non-null - references to objects that represent a buffer of data or a view on to a buffer of - data. The table below lists these types and the kind of buffer or view they represent. -

    - - - - - - - - - - - - -
    TypeKind of buffer
    ArrayBufferAn object that holds a pointer (which may be null) to a buffer of a fixed number of bytes
    DataViewA view on to an ArrayBuffer that allows typed access to integers and floating point values stored at arbitrary offsets into the buffer
    - Int8Array,
    - Int16Array,
    - Int32Array
    A view on to an ArrayBuffer that exposes it as an array of two’s complement signed integers of the given size in bits
    - Uint8Array,
    - Uint16Array,
    - Uint32Array
    A view on to an ArrayBuffer that exposes it as an array of unsigned integers of the given size in bits
    Uint8ClampedArrayA view on to an ArrayBuffer that exposes it as an array of unsigned 8 bit integers with clamped conversions
    - Float32Array,
    - Float64Array
    A view on to an ArrayBuffer that exposes it as an array of IEEE 754 floating point numbers of the given size in bits
    -
    Note
    -

    These types all correspond to classes defined in ECMAScript.

    -
    -

    - To detach an ArrayBuffer - is to set its buffer pointer to null. -

    -

    - There is no way to represent a constant value of any of these types in IDL. -

    -

    - The type name of all - of these types is the name of the type itself. -

    -

    - At the specification prose level, IDL buffer source types - are simply references to objects. To inspect or manipulate the bytes inside the buffer, - specification prose MUST first either - get a reference to the bytes held by the buffer source - or get a copy of the bytes held by the buffer source. - With a reference to the buffer source’s bytes, specification prose can get or set individual - byte values using that reference. -

    -
    Warning
    -

    - Extreme care must be taken when writing specification text that gets a reference - to the bytes held by a buffer source, as the underyling data can easily be changed - by the script author or other APIs at unpredictable times. If you are using a buffer source type - as an operation argument to obtain a chunk of binary data that will not be modified, - it is strongly recommended to get a copy of the buffer source’s bytes at the beginning - of the prose defining the operation. -

    -

    - Requiring prose to explicitly get a reference to or copy of the bytes is intended to - help specification reviewers look for problematic uses of these buffer source types. -

    -
    -
    Note
    -

    - When designing APIs that take a buffer, it is recommended to use the - BufferSource typedef rather than ArrayBuffer - or any of the view types. -

    -

    - When designing APIs that create and return a buffer, it is recommended - to use the ArrayBuffer type rather than - Uint8Array. -

    -
    -

    - Attempting to get a reference to or - get a copy of the bytes held by a buffer source - when the ArrayBuffer has been detached - will fail in a language binding-specific manner. -

    -
    Note
    -

    See section 4.2.31 below for - how interacting with buffer source types works in the ECMAScript language binding.

    -
    -
    Editorial note
    -

    We should include an example of specification text that uses these types and terms.

    -
    -
    - -
    -

    3.11.31. Frozen arrays — FrozenArray<T>

    - -

    - A frozen array type is a parameterized - type whose values are references to objects that hold a fixed length array - of unmodifiable values. The values in the array are of type T. -

    -

    - Since FrozenArray<T> values - are references, they are unlike sequence types, - which are lists of values that are passed by value. -

    -

    - There is no way to represent a constant frozen array value in IDL. -

    -

    - The type name of a frozen array - type is the concatenation of the type name for T and the string - “Array”. -

    -
    -
    - -
    -

    3.12. Extended attributes

    - -

    - An extended attribute is an annotation - that can appear on - definitions, - interface members, - namespace members, - dictionary members, - and operation arguments, and - is used to control how language bindings will handle those constructs. - Extended attributes are specified with an - ExtendedAttributeList, - which is a square bracket enclosed, comma separated list of - ExtendedAttributes. -

    -

    - The ExtendedAttribute - grammar symbol matches nearly any sequence of tokens, however the - extended attributes - defined in this document only accept a more restricted syntax. - Any extended attribute encountered in an - IDL fragment is - - matched against the following six grammar symbols to determine - which form (or forms) it is in: -

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Grammar symbolFormExample
    - ExtendedAttributeNoArgs - - takes no arguments - - [Replaceable] -
    - ExtendedAttributeArgList - - takes an argument list - - [Constructor(double x, double y)] -
    - ExtendedAttributeNamedArgList - - takes a named argument list - - [NamedConstructor=Image(DOMString src)] -
    - ExtendedAttributeIdent - - takes an identifier - - [PutForwards=name] -
    - ExtendedAttributeIdentList - - takes an identifier list - - [Exposed=(Window,Worker)] -
    - -

    - This specification defines a number of extended attributes that - are applicable to the ECMAScript language binding, which are described in - section 4.3. - Each extended attribute definition will state which of the above - six forms are allowed. -

    - -
    [65]ExtendedAttributeList"[" ExtendedAttribute ExtendedAttributes "]"
     | - ε
    [66]ExtendedAttributes"," ExtendedAttribute ExtendedAttributes
     | - ε
    [67]ExtendedAttribute - "(" ExtendedAttributeInner ")" ExtendedAttributeRest -
     | - "[" ExtendedAttributeInner "]" ExtendedAttributeRest -
     | - "{" ExtendedAttributeInner "}" ExtendedAttributeRest -
     | - Other ExtendedAttributeRest -
    [68]ExtendedAttributeRestExtendedAttribute
     | - ε
    [69]ExtendedAttributeInner - "(" ExtendedAttributeInner ")" ExtendedAttributeInner -
     | - "[" ExtendedAttributeInner "]" ExtendedAttributeInner -
     | - "{" ExtendedAttributeInner "}" ExtendedAttributeInner -
     | - OtherOrComma ExtendedAttributeInner -
     | - ε -
    [70]Other - integer
     | - float
     | - identifier
     | - string
     | - other -
     | - "-"
     | - "-Infinity"
     | - "."
     | - "..."
     | - ":"
     | - ";"
     | - "<"
     | - "="
     | - ">"
     | - "?" -
     | - "ByteString"
     | - "DOMString"
     | - "FrozenArray"
     | - "Infinity"
     | - "NaN"
     | - "RegExp"
     | - "USVString"
     | - "any"
     | - "boolean"
     | - "byte"
     | - "double"
     | - "false"
     | - "float" -
     | - "long"
     | - "null"
     | - "object"
     | - "octet"
     | - "or"
     | - "optional"
     | - "sequence" -
     | - "short"
     | - "true"
     | - "unsigned"
     | - "void" -
     | - ArgumentNameKeyword -
     | - BufferRelatedType -
    [72]OtherOrCommaOther
     | - ","
    [90]IdentifierListidentifier Identifiers
    [91]Identifiers"," identifier Identifiers
     | - ε
    [92]ExtendedAttributeNoArgsidentifier
    [93]ExtendedAttributeArgListidentifier "(" ArgumentList ")"
    [94]ExtendedAttributeIdentidentifier "=" identifier
    [95]ExtendedAttributeIdentListidentifier "=" "(" IdentifierList ")"
    [96]ExtendedAttributeNamedArgListidentifier "=" identifier "(" ArgumentList ")"
    - -
    - - -
    -

    4. ECMAScript binding

    - -

    - This section describes how definitions written with the IDL defined in - section 3 correspond to particular constructs - in ECMAScript, as defined by the ECMAScript Language Specification 6th Edition - [ECMA-262]. -

    -

    - Objects defined in this section have internal properties as described in - ECMA-262 sections 9.1 and - 9.3.1 unless otherwise specified, in which case one or - more of the following are redefined in accordance with the rules for exotic objects: - [[Call]], - [[Set]], - [[DefineOwnProperty]], - [[GetOwnProperty]], - [[Delete]] and - [[HasInstance]]. -

    -

    - Other specifications MAY override the definitions - of any internal method of a platform object - that is an instance of an interface. -

    -
    Warning
    -

    - As overriding internal ECMAScript object methods is a low level operation and - can result in objects that behave differently from ordinary objects, - this facility SHOULD NOT be used unless necessary - for security or compatibility. The expectation is that this will be used - for Location objects - and possibly WindowProxy objects. -

    -
    -

    - Unless otherwise specified, the [[Extensible]] internal property - of objects defined in this section has the value true. -

    -

    - Unless otherwise specified, the [[Prototype]] internal property - of objects defined in this section is the Object prototype object. -

    -

    - Some objects described in this section are defined to have a class string, - which is the string to include in the string returned from Object.prototype.toString. - If an object has a class string, then the object MUST, - at the time it is created, have a property whose name is the @@toStringTag symbol - and whose value is the specified string. -

    -
    Editorial note
    -

    Should define whether @@toStringTag is writable, enumerable and configurable. - All @@toStringTag properties in the ES6 spec are non-writable and non-enumerable, - and configurable.

    -
    -

    - If an object is defined to be a function object, then - it has characteristics as follows: -

    - -
    Editorial note
    -

    The list above needs updating for the latest ES6 draft.

    -
    -

    - Algorithms in this section use the conventions described in ECMA-262 - section 5.2, such as the use of steps and substeps, the use of mathematical - operations, and so on. The - ToBoolean, - ToNumber, - ToUint16, - ToInt32, - ToUint32, - ToString, - ToObject, - IsAccessorDescriptor and - IsDataDescriptor abstract operations and the - Type(x) - notation referenced in this section are defined in ECMA-262 sections 6 and 7. -

    -

    - When an algorithm says to “throw a SomethingError” then this means to - construct a new ECMAScript SomethingError object and to throw it, - just as the algorithms in ECMA-262 do. -

    -

    - Note that algorithm steps can call in to other algorithms and abstract operations and - not explicitly handle exceptions that are thrown from them. When an exception - is thrown by an algorithm or abstract operation and it is not explicitly - handled by the caller, then it is taken to end the algorithm and propagate out - to its caller, and so on. -

    -
    Example
    -

    - Consider the following algorithm: -

    -
      -
    1. Let x be the ECMAScript value passed in to this algorithm.
    2. -
    3. Let y be the result of calling ToString(x).
    4. -
    5. Return y.
    6. -
    -

    - Since ToString can throw an exception (for example if passed the object - ({ toString: function() { throw 1 } })), and the exception is - not handled in the above algorithm, if one is thrown then it causes this - algorithm to end and for the exception to propagate out to its caller, if there - is one. -

    -
    - -
    -

    4.1. ECMAScript environment

    -

    - In an ECMAScript implementation of a given set of - IDL fragments, - there will exist a number of ECMAScript objects that correspond to - definitions in those IDL fragments. - These objects are termed the initial objects, - and comprise the following: -

    - -

    - Each ECMAScript global environment ([ECMA-262], section 8.2) - MUST have its own unique set of each of - the initial objects, created - before control enters any ECMAScript execution context associated with the - environment, but after the global object for that environment is created. The [[Prototype]]s - of all initial objects in a given global environment MUST come from - that same global environment. -

    -
    Example
    -

    - In an HTML user agent, multiple global environments can exist when - multiple frames or windows are created. Each frame or window will have - its own set of initial objects, - which the following HTML document demonstrates: -

    -
    HTML
    <!DOCTYPE html>
    -<title>Different global environments</title>
    -<iframe id=a></iframe>
    -<script>
    -var iframe = document.getElementById("a");
    -var w = iframe.contentWindow;              // The global object in the frame
    -
    -Object == w.Object;                        // Evaluates to false, per ECMA-262
    -Node == w.Node;                            // Evaluates to false
    -iframe instanceof w.Node;                  // Evaluates to false
    -iframe instanceof w.Object;                // Evaluates to false
    -iframe.appendChild instanceof Function;    // Evaluates to true
    -iframe.appendChild instanceof w.Function;  // Evaluates to false
    -</script>
    -
    -

    - Unless otherwise specified, each ECMAScript global environment exposes - all interfaces - that the implementation supports. If a given ECMAScript global environment does not - expose an interface, then the requirements given in - section 4.6 are - not followed for that interface. -

    -
    Note
    -

    - This allows, for example, ECMAScript global environments for Web Workers to expose - different sets of supported interfaces from those exposed in environments - for Web pages. -

    -
    - -

    - Although at the time of this writing the ECMAScript specification does not reflect this, - every ECMAScript object must have an associated Realm. The mechanisms - for associating objects with Realms are, for now, underspecified. However, we note that - in the case of platform objects, the - associated Realm is equal to the object's relevant Realm, and - for non-exotic function objects (i.e. not callable proxies, and not bound functions) - the associated Realm is equal to the value of the function object's [[Realm]] internal - slot. -

    -
    - -
    -

    4.2. ECMAScript type mapping

    - -

    - This section describes how types in the IDL map to types in ECMAScript. -

    -

    - Each sub-section below describes how values of a given IDL type are represented - in ECMAScript. For each IDL type, it is described how ECMAScript values are - converted to an IDL value - when passed to a platform object expecting that type, and how IDL values - of that type are converted to ECMAScript values - when returned from a platform object. -

    - -
    -

    4.2.1. any

    - -

    - Since the IDL any type - is the union of all other IDL types, it can correspond to any - ECMAScript value type. -

    -

    - How to convert an ECMAScript value to an IDL any value depends on the type of the - ECMAScript value: -

    -
    -
    The undefined value
    -
    - The IDL value is an - object reference - to a special object that represents the ECMAScript - undefined value. -
    -
    The null value
    -
    - The IDL value is the null - object? reference. -
    -
    A Boolean value
    -
    - The IDL value is the - boolean - value that represents the same truth value. -
    -
    A Number value
    -
    - The IDL value is that which is obtained - by following the rules for converting the - Number to an IDL - unrestricted double value, - as described in section 4.2.15, - below. -
    -
    A String value
    -
    - The IDL value is that which is obtained - by following the rules for converting the - String to an IDL - DOMString value, - as described in section 4.2.16, - below. -
    -
    An object value
    -
    - The IDL value is an - object value that - references the same object. -
    -
    -

    - An IDL any value is - converted to an ECMAScript value - as follows. If the value is an object - reference to a special object that represents an ECMAScript undefined - value, then it is converted to the ECMAScript - undefined value. Otherwise, - the rules for converting the specific type - of the IDL any value - as described in the remainder of this section are performed. -

    -
    - -
    -

    4.2.2. void

    - -

    - The only place that the void type may appear - in IDL is as the return type of an - operation. Functions on platform objects - that implement an operation whose IDL specifies a - void return type MUST return the - undefined value. -

    -

    - ECMAScript functions that implement an operation whose IDL - specifies a void return type - MAY return any value, which will be discarded. -

    -
    - -
    -

    4.2.3. boolean

    - -

    - An ECMAScript value V is - converted - to an IDL boolean value - by running the following algorithm: -

    -
      -
    1. Let x be the result of computing ToBoolean(V).
    2. -
    3. Return the IDL boolean value that is the one that represents the same truth value as the ECMAScript Boolean value x.
    4. -
    -

    - The IDL boolean value true - is converted to - the ECMAScript true value and the IDL boolean - value false is converted to the ECMAScript - false value. -

    -
    - -
    -

    4.2.4. byte

    - -

    - An ECMAScript value V is - converted - to an IDL byte value - by running the following algorithm: -

    -
      -
    1. Initialize x to ToNumber(V).
    2. -
    3. If the conversion to an IDL value is being performed due to any of the following: - - then: -
        -
      1. If x is NaN, +∞, or −∞, then throw a TypeError.
      2. -
      3. Set x to sign(x) * floor(abs(x)).
      4. -
      5. If x < −27 or x > 27 − 1, then throw a TypeError.
      6. -
      7. Return the IDL byte value that represents the same numeric value as x.
      8. -
      -
    4. -
    5. If x is not NaN and the conversion to an IDL value is being performed due to any of the following: - - then: -
        -
      1. Set x to min(max(x, −27), 27 − 1).
      2. -
      3. Round x to the nearest integer, choosing the even integer if it lies halfway between two, and choosing +0 rather than −0.
      4. -
      5. Return the IDL byte value that represents the same numeric value as x.
      6. -
      -
    6. -
    7. If x is NaN, +0, −0, +∞, or −∞, then return the IDL byte value that represents 0.
    8. -
    9. Set x to sign(x) * floor(abs(x)).
    10. -
    11. Set x to x modulo 28.
    12. -
    13. If x ≥ 27, return the IDL byte value that represents the same numeric value as x − 28. - Otherwise, return the IDL byte value that represents the same numeric value as x.
    14. -
    -

    - The result of converting - an IDL byte value to an ECMAScript - value is a Number that represents - the same numeric value as the IDL byte value. - The Number value will be an integer in the range [−128, 127]. -

    -
    - -
    -

    4.2.5. octet

    - -

    - An ECMAScript value V is - converted - to an IDL octet value - by running the following algorithm: -

    -
      -
    1. Initialize x to ToNumber(V).
    2. -
    3. If the conversion to an IDL value is being performed due to any of the following: - - then: -
        -
      1. If x is NaN, +∞, or −∞, then throw a TypeError.
      2. -
      3. Set x to sign(x) * floor(abs(x)).
      4. -
      5. If x < 0 or x > 28 − 1, then throw a TypeError.
      6. -
      7. Return the IDL octet value that represents the same numeric value as x.
      8. -
      -
    4. -
    5. If x is not NaN and the conversion to an IDL value is being performed due to any of the following: - - then: -
        -
      1. Set x to min(max(x, 0), 28 − 1).
      2. -
      3. Round x to the nearest integer, choosing the even integer if it lies halfway between two, and choosing +0 rather than −0.
      4. -
      5. Return the IDL octet value that represents the same numeric value as x.
      6. -
      -
    6. -
    7. If x is NaN, +0, −0, +∞, or −∞, then return the IDL octet value that represents 0.
    8. -
    9. Set x to sign(x) * floor(abs(x)).
    10. -
    11. Set x to x modulo 28.
    12. -
    13. Return the IDL octet value that represents the same numeric value as x.
    14. -
    -

    - The result of converting - an IDL octet value to an ECMAScript - value is a Number that represents - the same numeric value as the IDL - octet value. - The Number value will be an integer in the range [0, 255]. -

    -
    - -
    -

    4.2.6. short

    - -

    - An ECMAScript value V is - converted - to an IDL short value - by running the following algorithm: -

    -
      -
    1. Initialize x to ToNumber(V).
    2. -
    3. If the conversion to an IDL value is being performed due to any of the following: - - then: -
        -
      1. If x is NaN, +∞, or −∞, then throw a TypeError.
      2. -
      3. Set x to sign(x) * floor(abs(x)).
      4. -
      5. If x < −215 or x > 215 − 1, then throw a TypeError.
      6. -
      7. Return the IDL short value that represents the same numeric value as x.
      8. -
      -
    4. -
    5. If x is not NaN and the conversion to an IDL value is being performed due to any of the following: - - then: -
        -
      1. Set x to min(max(x, −215), 215 − 1).
      2. -
      3. Round x to the nearest integer, choosing the even integer if it lies halfway between two, and choosing +0 rather than −0.
      4. -
      5. Return the IDL short value that represents the same numeric value as x.
      6. -
      -
    6. -
    7. If x is NaN, +0, −0, +∞, or −∞, then return the IDL short value that represents 0.
    8. -
    9. Set x to sign(x) * floor(abs(x)).
    10. -
    11. Set x to x modulo 216.
    12. -
    13. If x ≥ 215, return the IDL short value that represents the same numeric value as x − 216. - Otherwise, return the IDL short value that represents the same numeric value as x.
    14. -
    -

    - The result of converting - an IDL short value to an ECMAScript - value is a Number that represents the - same numeric value as the IDL - short value. - The Number value will be an integer in the range [−32768, 32767]. -

    -
    - -
    -

    4.2.7. unsigned short

    - -

    - An ECMAScript value V is - converted - to an IDL unsigned short value - by running the following algorithm: -

    -
      -
    1. Initialize x to ToNumber(V).
    2. -
    3. If the conversion to an IDL value is being performed due to any of the following: - - then: -
        -
      1. If x is NaN, +∞, or −∞, then throw a TypeError.
      2. -
      3. Set x to sign(x) * floor(abs(x)).
      4. -
      5. If x < 0 or x > 216 − 1, then throw a TypeError.
      6. -
      7. Return the IDL unsigned short value that represents the same numeric value as x.
      8. -
      -
    4. -
    5. If x is not NaN and the conversion to an IDL value is being performed due to any of the following: - - then: -
        -
      1. Set x to min(max(x, 0), 216 − 1).
      2. -
      3. Round x to the nearest integer, choosing the even integer if it lies halfway between two, and choosing +0 rather than −0.
      4. -
      5. Return the IDL unsigned short value that represents the same numeric value as x.
      6. -
      -
    6. -
    7. Set x to ToUint16(x).
    8. -
    9. Return the IDL unsigned short value that represents the same numeric value as x.
    10. -
    -

    - The result of converting - an IDL unsigned short value to an ECMAScript - value is a Number that - represents the same numeric value as the IDL - unsigned short value. - The Number value will be an integer in the range [0, 65535]. -

    -
    - -
    -

    4.2.8. long

    - -

    - An ECMAScript value V is - converted - to an IDL long value - by running the following algorithm: -

    -
      -
    1. Initialize x to ToNumber(V).
    2. -
    3. If the conversion to an IDL value is being performed due to any of the following: - - then: -
        -
      1. If x is NaN, +∞, or −∞, then throw a TypeError.
      2. -
      3. Set x to sign(x) * floor(abs(x)).
      4. -
      5. If x < −231 or x > 231 − 1, then throw a TypeError.
      6. -
      7. Return the IDL long value that represents the same numeric value as x.
      8. -
      -
    4. -
    5. If x is not NaN and the conversion to an IDL value is being performed due to any of the following: - - then: -
        -
      1. Set x to min(max(x, −231), 231 − 1).
      2. -
      3. Round x to the nearest integer, choosing the even integer if it lies halfway between two, and choosing +0 rather than −0.
      4. -
      5. Return the IDL long value that represents the same numeric value as x.
      6. -
      -
    6. -
    7. Set x to ToInt32(x).
    8. -
    9. Return the IDL long value that represents the same numeric value as x.
    10. -
    -

    - The result of converting - an IDL long value to an ECMAScript - value is a Number that - represents the same numeric value as the IDL - long value. - The Number value will be an integer in the range [−2147483648, 2147483647]. -

    -
    - -
    -

    4.2.9. unsigned long

    - -

    - An ECMAScript value V is - converted - to an IDL unsigned long value - by running the following algorithm: -

    -
      -
    1. Initialize x to ToNumber(V).
    2. -
    3. If the conversion to an IDL value is being performed due to any of the following: - - then: -
        -
      1. If x is NaN, +∞, or −∞, then throw a TypeError.
      2. -
      3. Set x to sign(x) * floor(abs(x)).
      4. -
      5. If x < 0 or x > 232 − 1, then throw a TypeError.
      6. -
      7. Return the IDL unsigned long value that represents the same numeric value as x.
      8. -
      -
    4. -
    5. If x is not NaN and the conversion to an IDL value is being performed due to any of the following: - - then: -
        -
      1. Set x to min(max(x, 0), 232 − 1).
      2. -
      3. Round x to the nearest integer, choosing the even integer if it lies halfway between two, and choosing +0 rather than −0.
      4. -
      5. Return the IDL unsigned long value that represents the same numeric value as x.
      6. -
      -
    6. -
    7. Set x to ToUint32(x).
    8. -
    9. Return the IDL unsigned long value that represents the same numeric value as x.
    10. -
    -

    - The result of converting - an IDL unsigned long value to an ECMAScript - value is a Number that - represents the same numeric value as the IDL - unsigned long value. - The Number value will be an integer in the range [0, 4294967295]. -

    -
    - -
    -

    4.2.10. long long

    - -

    - An ECMAScript value V is - converted - to an IDL long long value - by running the following algorithm: -

    -
      -
    1. Initialize x to ToNumber(V).
    2. -
    3. If the conversion to an IDL value is being performed due to any of the following: - - then: -
        -
      1. If x is NaN, +∞, or −∞, then throw a TypeError.
      2. -
      3. Set x to sign(x) * floor(abs(x)).
      4. -
      5. If x < −253 + 1 or x > 253 − 1, then throw a TypeError.
      6. -
      7. Return the IDL long long value that represents the same numeric value as x.
      8. -
      -
    4. -
    5. If x is not NaN and the conversion to an IDL value is being performed due to any of the following: - - then: -
        -
      1. Set x to min(max(x, −253 + 1), 253 − 1).
      2. -
      3. Round x to the nearest integer, choosing the even integer if it lies halfway between two, and choosing +0 rather than −0.
      4. -
      5. Return the IDL long long value that represents the same numeric value as x.
      6. -
      -
    6. -
    7. If x is NaN, +0, −0, +∞, or −∞, then return the IDL long long value that represents 0.
    8. -
    9. Set x to sign(x) * floor(abs(x)).
    10. -
    11. Set x to x modulo 264.
    12. -
    13. If x is greater than or equal to 263, then set x to x − 264.
    14. -
    15. Return the IDL long long value that represents the same numeric value as x.
    16. -
    -

    - The result of converting - an IDL long long value to an ECMAScript - value is a Number value that - represents the closest numeric value to the long long, - choosing the numeric value with an even significand if there are - two equally close values ([ECMA-262], section 6.1.6). - If the long long is in the range - [−253 + 1, 253 − 1], then the Number - will be able to represent exactly the same value as the - long long. -

    -
    - -
    -

    4.2.11. unsigned long long

    - -

    - An ECMAScript value V is - converted - to an IDL unsigned long long value - by running the following algorithm: -

    -
      -
    1. Initialize x to ToNumber(V).
    2. -
    3. If the conversion to an IDL value is being performed due to any of the following: - - then: -
        -
      1. If x is NaN, +∞, or −∞, then throw a TypeError.
      2. -
      3. Set x to sign(x) * floor(abs(x)).
      4. -
      5. If x < 0 or x > 253 − 1, then throw a TypeError.
      6. -
      7. Return the IDL unsigned long long value that represents the same numeric value as x.
      8. -
      -
    4. -
    5. If x is not NaN and the conversion to an IDL value is being performed due to any of the following: - - then: -
        -
      1. Set x to min(max(x, 0), 253 − 1).
      2. -
      3. Round x to the nearest integer, choosing the even integer if it lies halfway between two, and choosing +0 rather than −0.
      4. -
      5. Return the IDL unsigned long long value that represents the same numeric value as x.
      6. -
      -
    6. -
    7. If x is NaN, +0, −0, +∞, or −∞, then return the IDL unsigned long long value that represents 0.
    8. -
    9. Set x to sign(x) * floor(abs(x)).
    10. -
    11. Set x to x modulo 264.
    12. -
    13. Return the IDL unsigned long long value that represents the same numeric value as x.
    14. -
    -

    - The result of converting - an IDL unsigned long long value to an ECMAScript - value is a Number value that - represents the closest numeric value to the unsigned long long, - choosing the numeric value with an even significand if there are - two equally close values ([ECMA-262], section 6.1.6). - If the unsigned long long is less than or equal to 253 − 1, - then the Number will be able to - represent exactly the same value as the - unsigned long long. -

    -
    - -
    -

    4.2.12. float

    - -

    - An ECMAScript value V is - converted - to an IDL float value - by running the following algorithm: -

    -
      -
    1. Let x be ToNumber(V).
    2. -
    3. If x is NaN, +Infinity or - −Infinity, then throw a TypeError.
    4. -
    5. - Let S be the set of finite IEEE 754 single-precision floating - point values except −0, but with two special values added: 2128 and - −2128. -
    6. -
    7. - Let y be the number in S that is closest - to x, selecting the number with an - even significand if there are two equally close values ([ECMA-262], section 6.1.6). - (The two special values 2128 and −2128 - are considered to have even significands for this purpose.) -
    8. -
    9. - If y is 2128 or −2128, then throw a TypeError. -
    10. -
    11. - If y is +0 and x is negative, return −0. -
    12. -
    13. - Return y. -
    14. -
    -

    - The result of converting - an IDL float value to an ECMAScript - value is the Number value that represents the same numeric value as the IDL - float value. -

    -
    - -
    -

    4.2.13. unrestricted float

    - -

    - An ECMAScript value V is - converted - to an IDL unrestricted float value - by running the following algorithm: -

    -
      -
    1. Let x be ToNumber(V).
    2. -
    3. If x is NaN, then return the IDL unrestricted float value that represents the IEEE 754 NaN value with the bit pattern 0x7fc00000 [IEEE-754].
    4. -
    5. - Let S be the set of finite IEEE 754 single-precision floating - point values except −0, but with two special values added: 2128 and - −2128. -
    6. -
    7. - Let y be the number in S that is closest - to x, selecting the number with an - even significand if there are two equally close values ([ECMA-262], section 6.1.6). - (The two special values 2128 and −2128 - are considered to have even significands for this purpose.) -
    8. -
    9. - If y is 2128, return +∞. -
    10. -
    11. - If y is −2128, return −∞. -
    12. -
    13. - If y is +0 and x is negative, return −0. -
    14. -
    15. - Return y. -
    16. -
    -
    Note
    -

    - Since there is only a single ECMAScript NaN value, - it must be canonicalized to a particular single precision IEEE 754 NaN value. The NaN value - mentioned above is chosen simply because it is the quiet NaN with the lowest - value when its bit pattern is interpreted as an unsigned 32 bit integer. -

    -
    -

    - The result of converting - an IDL unrestricted float value to an ECMAScript - value is a Number: -

    -
      -
    • - If the IDL unrestricted float value is a NaN, - then the Number value is NaN. -
    • -
    • - Otherwise, the Number value is - the one that represents the same numeric value as the IDL - unrestricted float value. -
    • -
    -
    - -
    -

    4.2.14. double

    - -

    - An ECMAScript value V is - converted - to an IDL double value - by running the following algorithm: -

    -
      -
    1. Let x be ToNumber(V).
    2. -
    3. If x is NaN, +Infinity or - −Infinity, then throw a TypeError.
    4. -
    5. - Return the IDL double value - that has the same numeric value as x. -
    6. -
    -

    - The result of converting - an IDL double value to an ECMAScript - value is the Number value that represents the - same numeric value as the IDL double value. -

    -
    - -
    -

    4.2.15. unrestricted double

    - -

    - An ECMAScript value V is - converted - to an IDL unrestricted double value - by running the following algorithm: -

    -
      -
    1. Let x be ToNumber(V).
    2. -
    3. If x is NaN, then return the IDL unrestricted double value that represents the IEEE 754 NaN value with the bit pattern 0x7ff8000000000000 [IEEE-754].
    4. -
    5. - Return the IDL unrestricted double value - that has the same numeric value as x. -
    6. -
    -
    Note
    -

    - Since there is only a single ECMAScript NaN value, - it must be canonicalized to a particular double precision IEEE 754 NaN value. The NaN value - mentioned above is chosen simply because it is the quiet NaN with the lowest - value when its bit pattern is interpreted as an unsigned 64 bit integer. -

    -
    -

    - The result of converting - an IDL unrestricted double value to an ECMAScript - value is a Number: -

    -
      -
    • - If the IDL unrestricted double value is a NaN, - then the Number value is NaN. -
    • -
    • - Otherwise, the Number value is - the one that represents the same numeric value as the IDL - unrestricted double value. -
    • -
    -
    - -
    -

    4.2.16. DOMString

    - -

    - An ECMAScript value V is - converted - to an IDL DOMString value - by running the following algorithm: -

    -
      -
    1. If V is null - and the conversion to an IDL value is being performed due - to any of the following: - - then return the DOMString - value that represents the empty string. -
    2. -
    3. Let x be ToString(V).
    4. -
    5. Return the IDL DOMString value that represents the same sequence of code units as the one the ECMAScript String value x represents.
    6. -
    -

    - The result of converting - an IDL DOMString value to an ECMAScript - value is the String - value that represents the same sequence of code units that the - IDL DOMString represents. -

    -
    - -
    -

    4.2.17. ByteString

    - -

    - An ECMAScript value V is - converted - to an IDL ByteString value - by running the following algorithm: -

    -
      -
    1. Let x be ToString(V).
    2. -
    3. If the value of any element - of x is greater than 255, then throw a TypeError.
    4. -
    5. Return an IDL ByteString value - whose length is the length of x, and where the value of each element is - the value of the corresponding element of x.
    6. -
    -

    - The result of converting - an IDL ByteString value to an ECMAScript - value is a String - value whose length is the length of the ByteString, - and the value of each element of which is the value of the corresponding element - of the ByteString. -

    -
    - -
    -

    4.2.18. USVString

    - -

    - An ECMAScript value V is - converted - to an IDL USVString value - by running the following algorithm: -

    -
      -
    1. Let string be the result of converting V - to a DOMString.
    2. -
    3. Return an IDL USVString value - that is the result of converting string to a sequence of Unicode scalar values.
    4. -
    -

    - An IDL USVString value is - converted - to an ECMAScript value by running the following algorithm: -

    -
      -
    1. Let scalarValues be the sequence of Unicode scalar values the USVString represents.
    2. -
    3. Let string be the sequence of code units that results from encoding scalarValues in UTF-16.
    4. -
    5. Return the String value that represents the same sequence of code units as string.
    6. -
    -
    - -
    -

    4.2.19. object

    - -

    - IDL object - values are represented by ECMAScript Object values. -

    -

    - An ECMAScript value V is - converted - to an IDL object value - by running the following algorithm: -

    -
      -
    1. If Type(V) is not Object, then throw a TypeError.
    2. -
    3. Return the IDL object value that is a reference to the same object as V.
    4. -
    -

    - The result of converting - an IDL object value to an ECMAScript - value is the Object value that represents a reference to the same object that the - IDL object represents. -

    -
    - -
    -

    4.2.20. Interface types

    - -

    - IDL interface type - values are represented by ECMAScript Object or - Function values. -

    -

    - An ECMAScript value V is - converted - to an IDL interface type value - by running the following algorithm (where I is the interface): -

    -
      -
    1. If Type(V) is not Object, then throw a TypeError.
    2. -
    3. If V is a platform object that implements I, then return the IDL interface type value that represents a reference to that platform object.
    4. -
    5. If V is a user object - that is considered to implement I according to the rules in section 4.9, then return the IDL interface type value that represents a reference to that - user object, with the incumbent settings object as the callback context. [HTML]
    6. -
    7. Throw a TypeError.
    8. -
    -

    - The result of converting - an IDL interface type - value to an ECMAScript value is the Object - value that represents a reference to the same object that the IDL - interface type value represents. -

    -
    - -
    -

    4.2.21. Dictionary types

    - -

    - IDL dictionary type values are represented - by ECMAScript Object values. Properties on - the object (or its prototype chain) correspond to dictionary members. -

    -

    - An ECMAScript value V is - converted - to an IDL dictionary type value - by running the following algorithm (where D is the dictionary): -

    -
      -
    1. If Type(V) is not Undefined, Null or Object, then throw a TypeError.
    2. -
    3. If V is a native RegExp object, then throw a TypeError.
    4. -
    5. Let dict be an empty dictionary value of type D; - every dictionary member - is initially considered to be not present.
    6. -
    7. Let dictionaries be a list consisting of D and all of D’s inherited dictionaries, - in order from least to most derived.
    8. -
    9. For each dictionary dictionary in dictionaries, in order: -
        -
      1. For each dictionary member member declared on dictionary, in lexicographical order: -
          -
        1. Let key be the identifier of member.
        2. -
        3. Let value be an ECMAScript value, depending on Type(V): -
          -
          Undefined
          -
          Null
          -
          value is undefined.
          -
          anything else
          -
          value is the result of calling the [[Get]] internal method on V with property name key.
          -
          -
        4. -
        5. If value is not undefined, then: -
            -
          1. Let idlValue be the result of converting value to an IDL value whose type is the type member is declared to be of.
          2. -
          3. Set the dictionary member on dict with key name key to the value idlValue. This dictionary member is considered to be present.
          4. -
          -
        6. -
        7. Otherwise, if value is undefined but the dictionary member has a default value, then: -
            -
          1. Let idlValue be the dictionary member’s default value.
          2. -
          3. Set the dictionary member on dict with key name key to the value idlValue. This dictionary member is considered to be present.
          4. -
          -
        8. -
        9. - Otherwise, if value is - undefined and the - dictionary - member is a - required dictionary - member, then throw a TypeError. -
        10. -
        -
      2. -
      -
    10. -
    11. Return dict.
    12. -
    -
    Note
    -

    - The order that dictionary members are looked - up on the ECMAScript object are not necessarily the same as the object’s property enumeration order. -

    -
    -

    - An IDL dictionary value V is - converted - to an ECMAScript Object value - by running the following algorithm (where D is the dictionary): -

    -
      -
    1. Let O be a new Object value created as if by the expression ({}).
    2. -
    3. Let dictionaries be a list consisting of D and all of D’s inherited dictionaries, - in order from least to most derived.
    4. -
    5. For each dictionary dictionary in dictionaries, in order: -
        -
      1. For each dictionary member member declared on dictionary, in lexicographical order: -
          -
        1. Let key be the identifier of member.
        2. -
        3. If the dictionary member named key is present in V, then: -
            -
          1. Let idlValue be the value of member on V.
          2. -
          3. Let value be the result of converting idlValue to an ECMAScript value.
          4. -
          5. Call CreateDataProperty(O, key, value.
          6. -
          -
        4. -
        -
      2. -
      -
    6. -
    7. Return O.
    8. -
    -
    - -
    -

    4.2.22. Enumeration types

    - -

    - IDL enumeration types are represented by ECMAScript String - values. -

    -

    - An ECMAScript value V is - converted - to an IDL enumeration type - value as follows (where E is the enumeration): -

    -
      -
    1. Let S be the result of calling ToString(V).
    2. -
    3. If S is not one of E’s enumeration values, then throw a TypeError.
    4. -
    5. Return the enumeration value of type E that is equal to S.
    6. -
    -

    - The result of converting - an IDL enumeration type value to an ECMAScript - value is the String - value that represents the same sequence of code units as - the enumeration value. -

    -
    - -
    -

    4.2.23. Callback function types

    - -

    - IDL callback function types are represented by ECMAScript Function - objects, except in the [TreatNonObjectAsNull] case, - when they can be any object. -

    -

    - An ECMAScript value V is - converted - to an IDL callback function type value - by running the following algorithm: -

    -
      -
    1. If the result of calling IsCallable(V) is false and the conversion to an IDL value - is not being performed due - to V being assigned to an attribute - whose type is a nullable - callback function - that is annotated with [TreatNonObjectAsNull], - then throw a TypeError.
    2. -
    3. Return the IDL callback function type value - that represents a reference to the same object that V represents, with the - incumbent settings object as the callback context. [HTML].
    4. -
    -

    - The result of converting - an IDL callback function type - value to an ECMAScript value is a reference to the same object - that the IDL callback function type value represents. -

    -
    - -
    -

    4.2.24. Nullable types — T?

    - -

    - IDL nullable type values are represented - by values of either the ECMAScript type corresponding to the inner IDL type, or - the ECMAScript null value. -

    -

    - An ECMAScript value V is - converted - to an IDL nullable type T? - value (where T is the inner type) as follows: -

    -
      -
    1. - If Type(V) is not Object, and - the conversion to an IDL value is being performed due - to V being assigned to an attribute - whose type is a nullable - callback function - that is annotated with [TreatNonObjectAsNull], - then return the IDL - nullable type T? - value null. -
    2. -
    3. - Otherwise, if V is null or undefined, then return the IDL - nullable type T? - value null. -
    4. -
    5. - Otherwise, return the result of - converting V - using the rules for the inner IDL type T. -
    6. -
    -

    - The result of converting - an IDL nullable type value to an ECMAScript value is: -

    - -
    - -
    -

    4.2.25. Sequences — sequence<T>

    - -

    - IDL sequence<T> values are represented by - ECMAScript Array values. -

    -

    - An ECMAScript value V is converted - to an IDL sequence<T> value as follows: -

    -
      -
    1. - If V is not an object, - throw a - TypeError. -
    2. -
    3. - If V is a native RegExp object, - throw a - TypeError. -
    4. -
    5. - Let method be the result of - GetMethod(V, @@iterator). -
    6. -
    7. - ReturnIfAbrupt(method). -
    8. -
    9. - If method is undefined, - throw a - TypeError. -
    10. -
    11. - Return the result of - creating a sequence - of type sequence<T> - from V and method. -
    12. -
    - -

    - An IDL sequence value S of type - sequence<T> is - converted - to an ECMAScript Array object as follows: -

    -
      -
    1. Let n be the length of S.
    2. -
    3. Let A be a new Array object created as if by the expression [].
    4. -
    5. Initialize i to be 0.
    6. -
    7. While i < n: -
        -
      1. Let V be the value in S at index i.
      2. -
      3. Let E be the result of converting - V to an ECMAScript value.
      4. -
      5. Let P be the result of calling ToString(i).
      6. -
      7. Call CreateDataProperty(A, P, E).
      8. -
      9. Set i to i + 1.
      10. -
      -
    8. -
    9. Return A.
    10. -
    - -
    -
    4.2.25.1. Creating a sequence from an iterable
    -

    - To create an IDL value of type sequence<T> given an - iterable iterable and an iterator getter - method, perform the following steps: -

    -
      -
    1. - Let iter be - GetIterator(iterable, method). -
    2. -
    3. - ReturnIfAbrupt(iter). -
    4. -
    5. Initialize i to be 0.
    6. -
    7. Repeat -
        -
      1. - Let next be IteratorStep(iter). -
      2. -
      3. ReturnIfAbrupt(next).
      4. -
      5. - If next is false, - then return an IDL sequence value of type - sequence<T> - of length i, where the value of the element - at index j is - Sj. -
      6. -
      7. - Let nextItem be - IteratorValue(next). -
      8. -
      9. ReturnIfAbrupt(nextItem).
      10. -
      11. - Initialize Si to the result of - converting - nextItem to an IDL value of type T. -
      12. -
      13. Set i to i + 1.
      14. -
      -
    8. -
    -
    -
    Example
    -

    - The following interface defines - an attribute of a sequence - type as well as an operation - with an argument of a sequence type. -

    -
    IDL
    interface Canvas {
    -
    -  sequence<DOMString> getSupportedImageCodecs();
    -
    -  void drawPolygon(sequence<double> coordinates);
    -  sequence<double> getLastDrawnPolygon();
    -
    -  // ...
    -};
    -

    - In an ECMAScript implementation of this interface, an Array - object with elements of type String is used to - represent a sequence<DOMString>, while an - Array with elements of type Number - represents a sequence<double>. The - Array objects are effectively passed by - value; every time the getSupportedImageCodecs() - function is called a new Array is - returned, and whenever an Array is - passed to drawPolygon no reference - will be kept after the call completes. -

    -
    ECMAScript
    
    -// Obtain an instance of Canvas.  Assume that getSupportedImageCodecs()
    -// returns a sequence with two DOMString values: "image/png" and "image/svg+xml".
    -var canvas = getCanvas();
    -
    -// An Array object of length 2.
    -var supportedImageCodecs = canvas.getSupportedImageCodecs();
    -
    -// Evaluates to "image/png".
    -supportedImageCodecs[0];
    -
    -// Each time canvas.getSupportedImageCodecs() is called, it returns a
    -// new Array object.  Thus modifying the returned Array will not
    -// affect the value returned from a subsequent call to the function.
    -supportedImageCodecs[0] = "image/jpeg";
    -
    -// Evaluates to "image/png".
    -canvas.getSupportedImageCodecs()[0];
    -
    -// This evaluates to false, since a new Array object is returned each call.
    -canvas.getSupportedImageCodecs() == canvas.getSupportedImageCodecs();
    -
    -
    -// An Array of Numbers...
    -var a = [0, 0, 100, 0, 50, 62.5];
    -
    -// ...can be passed to a platform object expecting a sequence<double>.
    -canvas.drawPolygon(a);
    -
    -// Each element will be converted to a double by first calling ToNumber().
    -// So the following call is equivalent to the previous one, except that
    -// "hi" will be alerted before drawPolygon() returns.
    -a = [false, '',
    -     { valueOf: function() { alert('hi'); return 100; } }, 0,
    -     '50', new Number(62.5)];
    -canvas.drawPolygon(s);
    -
    -// Modifying an Array that was passed to drawPolygon() is guaranteed not to
    -// have an effect on the Canvas, since the Array is effectively passed by value.
    -a[4] = 20;
    -var b = canvas.getLastDrawnPolygon();
    -alert(b[4]);    // This would alert "50".
    -
    - -
    - -
    -

    4.2.26. Promise types — Promise<T>

    - -

    - IDL promise type values are - represented by ECMAScript Promise - objects. -

    -

    - An ECMAScript value V is - converted - to an IDL Promise<T> value as follows: -

    -
      -
    1. Let resolve be the original value of %Promise%.resolve. -
      Editorial note
      -

      ECMAScript should grow a %Promise_resolve% well-known intrinsic object that can be referenced here.

      -
      -
    2. -
    3. Let promise be the result of calling resolve with %Promise% - as the this value and V as the single argument value.
    4. -
    5. Return the IDL promise type value that is a reference to the - same object as promise.
    6. -
    -

    - The result of converting - an IDL promise type value to an ECMAScript - value is the Promise value that represents a reference to the same object that the - IDL promise type represents. -

    -

    - One can perform some steps once a promise is settled. - There can be one or two sets of steps to perform, covering when the promise is fulfilled, rejected, or both. - When a specification says to perform some steps once a promise is settled, the following steps - MUST be followed: -

    -
      -
    1. Let promise be the promise object of type Promise<T>.
    2. -
    3. - Let onFulfilled be a new function object whose - behavior when invoked is as follows: -
        -
      1. If T is void, then: -
        1. Return the result of performing any steps that were required to be run if the promise was fulfilled.
      2. -
      3. Otherwise, T is a type other than void: -
          -
        1. Let V be the first argument to onFulfilled.
        2. -
        3. Let value be the result of converting - V to an IDL value of type T.
        4. -
        5. If there are no steps that are required to be run if the promise was fulfilled, then - return undefined.
        6. -
        7. Otherwise, return the result of performing any steps that were required to be run if the promise was fulfilled, - with value as the promise’s value.
        8. -
        -
      4. -
      -
    4. -
    5. - Let onRejected be a new function object whose - behavior when invoked is as follows: -
        -
      1. Let R be the first argument to onRejected.
      2. -
      3. Let reason be the result of converting - R to an IDL value of type any.
      4. -
      5. If there are no steps that are required to be run if the promise was rejected, then - return undefined.
      6. -
      7. Otherwise, return the result of performing any steps that were required to be run if the promise was rejected, - with reason as the rejection reason.
      8. -
      -
    6. -
    7. Let then be the result of calling the internal [[Get]] method of promise with property name “then”.
    8. -
    9. If then is not callable, then throw a TypeError.
    10. -
    11. Return the result of calling then with promise as the this value and onFulfilled and onRejected - as its two arguments.
    12. -
    -
    Editorial note
    -

    Include an example of how to write spec text using this term.

    -
    -
    - -
    -

    4.2.27. Union types

    - -

    - IDL union type values are - represented by ECMAScript values that correspond to the union’s - member types. -

    -

    - To convert an ECMAScript value V to an IDL union type - value is done as follows: -

    -
      -
    1. If the union type - includes a nullable type and - V is null or undefined, - then return the IDL value null.
    2. -
    3. - Let types be the flattened member types - of the union type. -
    4. -
    5. - If V is null or - undefined, and - types includes a - dictionary type, then return the - result of - converting - V to that dictionary type. -
    6. -
    7. - If V is a platform object, then: -
        -
      1. If types includes an interface type that V - implements, then return the IDL value that is a reference to the object V.
      2. -
      3. If types includes object, then return the IDL value - that is a reference to the object V.
      4. -
      -
    8. -
    9. - If V is a native RegExp object, then: -
        -
      1. If types includes RegExp, then return the - result of converting - V to RegExp.
      2. -
      3. If types includes object, then return the IDL value - that is a reference to the object V.
      4. -
      -
    10. -
    11. - If V is a DOMException platform object, then: -
        -
      1. If types includes DOMException or - Error, then return the - result of converting - V to that type.
      2. -
      3. If types includes object, then return the IDL value - that is a reference to the object V.
      4. -
      -
    12. -
    13. - If V is a native Error object (that is, it has an [[ErrorData]] internal slot), then: -
        -
      1. If types includes Error, then return the - result of converting - V to Error.
      2. -
      3. If types includes object, then return the IDL value - that is a reference to the object V.
      4. -
      -
    14. -
    15. - If V is an object with an [[ArrayBufferData]] internal slot, then: -
        -
      1. If types includes ArrayBuffer, then return the - result of converting - V to ArrayBuffer.
      2. -
      3. If types includes object, then return the IDL value - that is a reference to the object V.
      4. -
      -
    16. -
    17. - If V is an object with a [[DataView]] internal slot, then: -
        -
      1. If types includes DataView, then return the - result of converting - V to DataView.
      2. -
      3. If types includes object, then return the IDL value - that is a reference to the object V.
      4. -
      -
    18. -
    19. - If V is an object with a [[TypedArrayName]] internal slot, then: -
        -
      1. If types includes a typed array type - whose name is the value of V’s [[TypedArrayName]] internal slot, then return the - result of converting - V to that type.
      2. -
      3. If types includes object, then return the IDL value - that is a reference to the object V.
      4. -
      -
    20. -
    21. - If IsCallable(V) is true, then: -
        -
      1. If types includes a callback function - type, then return the result of - converting - V to that callback function type.
      2. -
      3. If types includes object, then return the IDL value - that is a reference to the object V.
      4. -
      -
    22. -
    23. - If V is any kind of object except for - a native RegExp object, then: -
        -
      1. - If types includes a sequence type, then -
          -
        1. - Let method be the result of - GetMethod(V, @@iterator). -
        2. -
        3. - ReturnIfAbrupt(method). -
        4. -
        5. - If method is not - undefined, - return the result of - creating a - sequence of that type from V and - method. -
        6. -
        -
      2. -
      3. - If types includes a frozen array type, then -
          -
        1. - Let method be the result of - GetMethod(V, @@iterator). -
        2. -
        3. - ReturnIfAbrupt(method). -
        4. -
        5. - If method is not - undefined, - return the result of - creating a - frozen array of that type from V and - method. -
        6. -
        -
      4. -
      5. If types includes a dictionary type, then return the - result of converting - V to that dictionary type.
      6. -
      7. If types includes a callback interface - type, then return the result of - converting - V to that interface type.
      8. -
      9. If types includes object, then return the IDL value - that is a reference to the object V.
      10. -
      -
    24. -
    25. - If V is a Boolean value, then: -
        -
      1. - If types includes a boolean, - then return the result of converting - V to boolean. -
      2. -
      -
    26. -
    27. - If V is a Number value, then: -
        -
      1. - If types includes a numeric type, - then return the result of converting - V to that numeric type. -
      2. -
      -
    28. -
    29. - If types includes a string type, - then return the result of - converting - V to that type. -
    30. -
    31. - If types includes a numeric type, - then return the result of converting - V to that numeric type. -
    32. -
    33. - If types includes a boolean, - then return the result of converting - V to boolean. -
    34. -
    35. - Throw a TypeError. -
    36. -
    -

    - An IDL union type value is - converted to an ECMAScript value - as follows. If the value is an object - reference to a special object that represents an ECMAScript undefined - value, then it is converted to the ECMAScript - undefined value. Otherwise, - the rules for converting the specific type - of the IDL union type value as described in this section (4.2). -

    -
    - -
    -

    4.2.28. RegExp

    - -

    - IDL RegExp values are represented by - ECMAScript RegExp objects. -

    -

    - An ECMAScript value V is - converted - to an IDL RegExp value - by running the following algorithm: -

    -
      -
    1. If Type(V) is not Object, - or V is not a native RegExp object, - then set V to be a newly created RegExp object created as if by the - expression new RegExp(V), where RegExp is the standard built-in constructor with that name - from the current global environment. -
      Note
      -

      Note that this can result in an exception being thrown, if V, when converted to a string, - does not have valid regular expression syntax.

      -
      -
    2. -
    3. Return the IDL RegExp value that is a reference to the same object as V.
    4. -
    -

    - The result of converting - an IDL RegExp value to an ECMAScript - value is the RegExp value that represents a reference to the same object that the - IDL RegExp represents. -

    -
    - -
    -

    4.2.29. Error

    - -

    - IDL Error values are represented - by native ECMAScript Error objects and - platform objects for DOMExceptions. -

    -

    - An ECMAScript value V is - converted - to an IDL Error value - by running the following algorithm: -

    -
      -
    1. If Type(V) is not Object, - or V does not have an [[ErrorData]] internal slot, then throw a TypeError.
    2. -
    3. Return the IDL Error value that is a reference to the same object as V.
    4. -
    -

    - The result of converting - an IDL Error value to an ECMAScript - value is the Error value that represents a reference to the same object that the - IDL Error represents. -

    -
    - -
    -

    4.2.30. DOMException

    - -

    - IDL DOMException values are represented - by platform objects for DOMExceptions. -

    -

    - An ECMAScript value V is - converted - to an IDL DOMException value - by running the following algorithm: -

    -
      -
    1. If Type(V) is not Object, - or V is not a platform object that represents a DOMException, then throw a TypeError.
    2. -
    3. Return the IDL DOMException value that is a reference to the same object as V.
    4. -
    -

    - The result of converting - an IDL DOMException value to an ECMAScript - value is the Object value that represents a reference to the same object that the - IDL DOMException represents. -

    -
    - -
    -

    4.2.31. Buffer source types

    - -

    - Values of the IDL buffer source types - are represented by objects of the corresponding ECMAScript class. -

    -

    - An ECMAScript value V is - converted - to an IDL ArrayBuffer value - by running the following algorithm: -

    -
      -
    1. If Type(V) is not Object, - or V does not have an [[ArrayBufferData]] internal slot, - or IsDetachedBuffer(V) is true, - then throw a TypeError. -
    2. -
    3. Return the IDL ArrayBuffer value that is a reference to the same object as V.
    4. -
    -

    - An ECMAScript value V is - converted - to an IDL DataView value - by running the following algorithm: -

    -
      -
    1. If Type(V) is not Object, - or V does not have a [[DataView]] internal slot, - then throw a TypeError.
    2. -
    3. Return the IDL DataView value that is a reference to the same object as V.
    4. -
    -

    - An ECMAScript value V is - converted - to an IDL Int8Array, - Int16Array, - Int32Array, - Uint8Array, - Uint16Array, - Uint32Array, - Uint8ClampedArray, - Float32Array or - Float64Array value - by running the following algorithm: -

    -
      -
    1. Let T be the IDL type V is being converted to.
    2. -
    3. If Type(V) is not Object, - or V does not have a [[TypedArrayName]] internal slot - with a value equal to the name of T, - then throw a TypeError.
    4. -
    5. Return the IDL value of type T that is a reference to the same object as V.
    6. -
    -

    - The result of converting - an IDL value of any buffer source type - to an ECMAScript value is the Object value that represents - a reference to the same object that the IDL value represents. -

    -

    - When getting a reference to - or getting a copy of the bytes held by a buffer source - that is an ECMAScript ArrayBuffer, DataView - or typed array object, these steps MUST be followed: -

    -
      -
    1. Let O be the ECMAScript object that is the buffer source.
    2. -
    3. Initialize arrayBuffer to O.
    4. -
    5. Initialize offset to 0.
    6. -
    7. Initialize length to 0.
    8. -
    9. If O has a [[ViewedArrayBuffer]] internal slot, then: -
        -
      1. Set arrayBuffer to the value of O’s [[ViewedArrayBuffer]] internal slot.
      2. -
      3. If arrayBuffer is undefined, then - throw a TypeError.
      4. -
      5. Set offset to the value of O’s [[ByteOffset]] internal slot.
      6. -
      7. Set length to the value of O’s [[ByteLength]] internal slot.
      8. -
      -
    10. -
    11. Otherwise, set length to the value of O’s [[ArrayBufferByteLength]] internal slot.
    12. -
    13. If IsDetachedBuffer(O), then - throw a TypeError.
    14. -
    15. Let data be the value of O’s [[ArrayBufferData]] internal slot.
    16. -
    17. Return a reference to or copy of (as required) the length bytes in data - starting at byte offset offset.
    18. -
    -

    - To detach an ArrayBuffer, - these steps MUST be followed: -

    -
      -
    1. Let O be the ECMAScript object that is the ArrayBuffer.
    2. -
    3. DetachArrayBuffer(O).
    4. -
    -
    - -
    -

    4.2.32. Frozen arrays — FrozenArray<T>

    - -

    - Values of frozen array types are represented by frozen ECMAScript - Array object references. -

    -

    - An ECMAScript value V is - converted - to an IDL FrozenArray<T> value - by running the following algorithm: -

    -
      -
    1. Let values be the result of - converting - V to IDL type sequence<T>.
    2. -
    3. Return the result of - creating a frozen array - from values.
    4. -
    -

    - To create a frozen array from a sequence - of values of type T, follow these steps: -

    -
      -
    1. Let array be the result of - converting - the sequence of values to an ECMAScript value.
    2. -
    3. Perform SetIntegrityLevel(array, "frozen").
    4. -
    5. Return array.
    6. -
    -

    - The result of converting - an IDL FrozenArray<T> value to an ECMAScript - value is the Object value that represents a reference - to the same object that the IDL FrozenArray<T> represents. -

    - -
    -
    4.2.32.1. Creating a frozen array from an iterable
    -

    - To create an IDL value of type FrozenArray<T> given an - iterable iterable and an iterator getter - method, perform the following steps: -

    -
      -
    1. Let values be the result of - creating - a sequence of type sequence<T> - from iterable and method.
    2. -
    3. Return the result of creating a frozen - array from values.
    4. -
    -
    -
    -
    - -
    -

    4.3. ECMAScript-specific extended attributes

    - -

    - This section defines a number of - extended attributes - whose presence affects only the ECMAScript binding. -

    - -
    -

    4.3.1. [Clamp]

    - -

    - If the [Clamp] - extended attribute - appears on an operation argument, - writable attribute or - dictionary member - whose type is one of the integer types, - it indicates that when an ECMAScript Number is - converted to the IDL type, out of range values will be clamped to the range - of valid values, rather than using the operators that use a modulo operation - (ToInt32, ToUint32, etc.). -

    -

    - The [Clamp] - extended attribute MUST - take no arguments. -

    -

    - The [Clamp] extended attribute - MUST NOT appear on a read only - attribute, or an attribute, operation argument or dictionary member - that is not of an integer type. It also MUST NOT - be used in conjunction with the [EnforceRange] - extended attribute. -

    -

    - See the rules for converting ECMAScript values to the various IDL integer - types in section 4.2 - for the specific requirements that the use of - [Clamp] entails. -

    - -
    Example
    -

    - In the following IDL fragment, - two operations are declared that - take three octet arguments; one uses - the [Clamp] extended attribute - on all three arguments, while the other does not: -

    -
    IDL
    interface GraphicsContext {
    -  void setColor(octet red, octet green, octet blue);
    -  void setColorClamped([Clamp] octet red, [Clamp] octet green, [Clamp] octet blue);
    -};
    -

    - In an ECMAScript implementation of the IDL, a call to setColorClamped with - Number values that are out of range for an - octet are clamped to the range [0, 255]. -

    -
    ECMAScript
    // Get an instance of GraphicsContext.
    -var context = getGraphicsContext();
    -
    -// Calling the non-[Clamp] version uses ToUint8 to coerce the Numbers to octets.
    -// This is equivalent to calling setColor(255, 255, 1).
    -context.setColor(-1, 255, 257);
    -
    -// Call setColorClamped with some out of range values.
    -// This is equivalent to calling setColorClamped(0, 255, 255).
    -context.setColorClamped(-1, 255, 257);
    -
    -
    - -
    -

    4.3.2. [Constructor]

    - -

    - If the [Constructor] - extended attribute - appears on an interface, it indicates that - the interface object for this interface - will have an [[Construct]] internal method, - allowing objects implementing the interface to be constructed. -

    -

    - Multiple [Constructor] extended - attributes may appear on a given interface. -

    -

    - The [Constructor] - extended attribute MUST either - take no arguments or - take an argument list. - The bare form, [Constructor], has the same meaning as - using an empty argument list, [Constructor()]. For each - [Constructor] extended attribute - on the interface, there will be a way to construct an object that implements - the interface by passing the specified arguments. -

    -

    - The prose definition of a constructor MUST - either return an IDL value of a type corresponding to the interface - the [Constructor] - extended attribute appears on, or throw an exception. -

    -

    - The [Constructor] and - [NoInterfaceObject] - extended attributes must not be specified on the same interface. -

    -

    - The [Constructor] extended attribute - MUST NOT be used on a callback interface. -

    -

    - See section 4.6.1.1 - below for details on how a constructor - for an interface is to be implemented. -

    - -
    Example
    -

    - The following IDL defines two interfaces. The second has the - [Constructor] extended - attribute, while the first does not. -

    -
    IDL
    interface NodeList {
    -  Node item(unsigned long index);
    -  readonly attribute unsigned long length;
    +    
    +interface Derived : Ancestor {
    +  inherit attribute TheType theIdentifier;
     };
    -
    -[Constructor,
    - Constructor(double radius)]
    -interface Circle {
    -  attribute double r;
    -  attribute double cx;
    -  attribute double cy;
    -  readonly attribute double circumference;
    -};
    -

    - An ECMAScript implementation supporting these interfaces would - have a [[Construct]] property on the - Circle interface object which would - return a new object that implements the interface. It would take - either zero or one argument. The - NodeList interface object would not - have a [[Construct]] property. -

    -
    ECMAScript
    var x = new Circle();      // The uses the zero-argument constructor to create a
    -                           // reference to a platform object that implements the
    -                           // Circle interface.
    -
    -var y = new Circle(1.25);  // This also creates a Circle object, this time using
    -                           // the one-argument constructor.
    -
    -var z = new NodeList();    // This would throw a TypeError, since no
    -                           // [Constructor] is declared.
    -
    -
    - -
    -

    4.3.3. [EnforceRange]

    - -

    - If the [EnforceRange] - extended attribute - appears on an operation argument, - writable regular attribute or - dictionary member - whose type is one of the integer types, - it indicates that when an ECMAScript Number is - converted to the IDL type, out of range values will cause an exception to - be thrown, rather than converted to being a valid value using the operators that use a modulo operation - (ToInt32, ToUint32, etc.). The Number - will be rounded towards zero before being checked against its range. -

    -

    - The [EnforceRange] - extended attribute MUST - take no arguments. -

    -

    - The [EnforceRange] extended attribute - MUST NOT appear on a read only - attribute, a static attribute, - or an attribute, operation argument or dictionary member - that is not of an integer type. It also MUST NOT - be used in conjunction with the [Clamp] - extended attribute. -

    -

    - See the rules for converting ECMAScript values to the various IDL integer - types in section 4.2 - for the specific requirements that the use of - [EnforceRange] entails. -

    - -
    Example
    -

    - In the following IDL fragment, - two operations are declared that - take three octet arguments; one uses - the [EnforceRange] extended attribute - on all three arguments, while the other does not: -

    -
    IDL
    interface GraphicsContext {
    -  void setColor(octet red, octet green, octet blue);
    -  void setColorEnforcedRange([EnforceRange] octet red, [EnforceRange] octet green, [EnforceRange] octet blue);
    -};
    -

    - In an ECMAScript implementation of the IDL, a call to setColorEnforcedRange with - Number values that are out of range for an - octet will result in an exception being - thrown. -

    -
    ECMAScript
    // Get an instance of GraphicsContext.
    -var context = getGraphicsContext();
    -
    -// Calling the non-[EnforceRange] version uses ToUint8 to coerce the Numbers to octets.
    -// This is equivalent to calling setColor(255, 255, 1).
    -context.setColor(-1, 255, 257);
    -
    -// When setColorEnforcedRange is called, Numbers are rounded towards zero.
    -// This is equivalent to calling setColor(0, 255, 255).
    -context.setColorEnforcedRange(-0.9, 255, 255.2);
    -
    -// The following will cause a TypeError to be thrown, since even after
    -// rounding the first and third argument values are out of range.
    -context.setColorEnforcedRange(-1, 255, 256);
    -
    -
    - -
    -

    4.3.4. [Exposed]

    -

    - If the [Exposed] - extended attribute - appears on an interface, - partial interface, - namespace, - partial namespace, or - an individual interface member or - namespace member, - it indicates that the construct is exposed - on a particular set of global interfaces, rather than the default of - being exposed only on the primary global interface. -

    -

    - The [Exposed] - extended attribute - MUST either - take an identifier or - take an identifier list. - Each of the identifiers mentioned MUST be - a global name. -

    -

    - Every construct that the [Exposed] - extended attribute - can be specified on has an exposure set, - which is a set of interfaces - defining which global environments the construct can be used in. - The exposure set - for a given construct is defined as follows: -

    - -

    - If [Exposed] appears on an - overloaded operation, - then it MUST appear identically on all overloads. -

    -

    - The [Exposed] extended attribute - MUST NOT be specified on both an interface - member and a partial interface definition the interface member is declared on. - Similarly, the [Exposed] extended attribute - MUST NOT be specified on both a namespace - member and a partial namespace definition the namespace member is declared on. -

    -

    - If [Exposed] appears an interface member, then - the interface member's exposure set - MUST be a subset of the exposure set of the interface or partial interface it's a - member of. Similarly, if [Exposed] appears on a - namespace member, then the namespace member's exposure set MUST be a - subset of the exposure set of the - namespace or partial namespace it's a member of. -

    -

    - An interface's exposure set - MUST be a subset of the - exposure set of all - of the interface's consequential - interfaces. -

    -

    - If an interface X - inherits from another interface - Y then the - exposure set of - X MUST be a subset of the - exposure set of - Y. -

    -

    - An interface, namespace, interface member, or namespace member is exposed in a given ECMAScript global environment if the - ECMAScript global object implements an interface that is in the construct's exposure set, and either: -

    - -
    Note
    -

    Since it is not possible for the relevant settings object - for an ECMAScript global object to change whether it is a - secure context or not over time, an implementation's - decision to create properties for an interface or interface member - can be made once, at the time the - initial objects - are created.

    -
    -

    - See - section 4.6, - section 4.6.5, - section 4.6.6, - section 4.6.7 and - section 4.6.8 - for the specific requirements that the use of - [Exposed] entails. -

    -
    Example
    -

    [Exposed] - is intended to be used to control whether interfaces, namespaces, or individual - interface or namespace members are available for use only in workers, only in the - Window, or in both.

    -

    The following IDL fragment shows how that might be achieved:

    -
    IDL
    [PrimaryGlobal]
    -interface Window {
    -  ...
    +
    +

    When the stringifier keyword is used +in a regular attribute declaration, it indicates that objects implementing the +interface will be stringified to the value of the attribute. See §3.2.4.2 Stringifiers for details.

    +
    interface interface_identifier {
    +  stringifier attribute DOMString identifier;
     };
    -
    -// By using the same identifier Worker for both SharedWorkerGlobalScope
    -// and DedicatedWorkerGlobalScope, both can be addressed in an [Exposed]
    -// extended attribute at once.
    -[Global=Worker]
    -interface SharedWorkerGlobalScope : WorkerGlobalScope {
    -  ...
    +
    +

    If an implementation attempts to get or set the value of an attribute on a user object (for example, when a callback object has been supplied to the implementation), + and that attempt results in an exception being thrown, then, unless otherwise specified, that + exception will be propagated to the user code that caused the + implementation to access the attribute. Similarly, if a value + returned from getting the attribute cannot be converted to + an IDL type, then any exception resulting from this will also + be propagated to the user code that resulted in the implementation + attempting to get the value of the attribute.

    +

    The following extended attributes are applicable to regular and static attributes: +[Clamp], +[EnforceRange], +[Exposed], +[SameObject], +[SecureContext], +[TreatNullAs].

    +

    The following extended attributes are applicable only to regular attributes: +[LenientSetter], +[LenientThis], +[PutForwards], +[Replaceable], +[Unforgeable].

    +
    ReadOnlyMember :
    +    "readonly" ReadOnlyMemberRest
    +
    +
    ReadOnlyMemberRest :
    +    AttributeRest
    +    ReadWriteMaplike
    +    ReadWriteSetlike
    +
    +
    ReadWriteAttribute :
    +    "inherit" ReadOnly AttributeRest
    +    AttributeRest
    +
    +
    AttributeRest :
    +    "attribute" Type AttributeName ";"
    +
    +
    AttributeName :
    +    AttributeNameKeyword
    +    identifier
    +
    +
    AttributeNameKeyword :
    +    "required"
    +
    +
    Inherit :
    +    "inherit"
    +    ε
    +
    +
    ReadOnly :
    +    "readonly"
    +    ε
    +
    +
    + +

    The following IDL fragment demonstrates how attributes can be declared on an interface:

    +
    interface Animal {
    +        
    +  // A simple attribute that can be set to any string value.
    +  readonly attribute DOMString name;
    +        
    +  // An attribute whose value can be assigned to.
    +  attribute unsigned short age;
     };
    -
    -[Global=Worker]
    -interface DedicatedWorkerGlobalScope : WorkerGlobalScope {
    -  ...
    +        
    +interface Person : Animal {
    +        
    +  // An attribute whose getter behavior is inherited from Animal, and need not be
    +  // specified in the description of Person.
    +  inherit attribute DOMString name;
     };
    -
    -// Dimensions is available for use in workers and on the main thread.
    -[Exposed=(Window,Worker), Constructor(double width, double height)]
    -interface Dimensions {
    -  readonly attribute double width;
    -  readonly attribute double height;
    +
    +
    +

    3.2.3. Operations

    +

    An operation is an interface member (matching static OperationRest, stringifier OperationRest, serializer OperationRest, ReturnType OperationRest or SpecialOperation) +that defines a behavior that can be invoked on objects implementing the interface. +There are three kinds of operation:

    +
      +
    1. +

      regular operations, which +are those used to declare that objects implementing the interface will have a method with +the given identifier

      +
      interface interface_identifier {
      +  return_type identifier(/* arguments... */);
       };
      -
      -// WorkerNavigator is only available in workers.  Evaluating WorkerNavigator
      -// in the global scope of a worker would give you its interface object, while
      -// doing so on the main thread will give you a ReferenceError.
      -[Exposed=Worker]
      -interface WorkerNavigator {
      -  ...
      +
      +
    2. +

      special operations, +which are used to declare special behavior on objects +implementing the interface, such as object indexing and stringification

      +
      interface interface_identifier {
      +  /* special_keywords... */ return_type identifier(/* arguments... */);
      +  /* special_keywords... */ return_type (/* arguments... */);
       };
      -
      -// Node is only available on the main thread.  Evaluating Node
      -// in the global scope of a worker would give you a ReferenceError.
      -interface Node {
      -  ...
      +
      +
    3. +

      static operations, +which are used to declare operations that are not associated with +a particular object implementing the interface

      +
      interface interface_identifier {
      +  static return_type identifier(/* arguments... */);
       };
      -
      -// MathUtils is available for use in workers and on the main thread.
      -[Exposed=(Window,Worker)]
      -namespace MathUtils {
      -  double someComplicatedFunction(double x, double y);
      +
      +
    +

    If an operation has an identifier but no static keyword, then it declares a regular operation. +If the operation has one or more special keywords used in its declaration (that is, any keyword matching Special, or +the stringifier keyword), +then it declares a special operation. A single operation can declare +both a regular operation and a special operation; +see §3.2.4 Special operations for details on special operations. +Note that in addition to being interface members, +regular operations can also be namespace members.

    +

    If an operation has no identifier, +then it must be declared to be a special operation +using one of the special keywords.

    +

    The identifier of a regular operation or static operation must not be the same as the identifier +of a constant or attribute defined on the same interface. +The identifier of a static operation must not be “prototype”.

    +

    Note: The identifier can be the same +as that of another operation on the interface, however. +This is how operation overloading is specified.

    +

    The identifier of a static operation also must not be the same as the identifier +of a regular operation defined on the same interface.

    +

    The return type of the operation is given +by the type (matching ReturnType) +that appears before the operation’s optional identifier. +A return type of void indicates that the operation returns no value. +If the return type is an identifier followed by ?, +then the identifier must +identify an interface, dictionary, enumeration, callback function or typedef.

    +

    An operation’s arguments (matching ArgumentList) +are given between the parentheses in the declaration. Each individual argument is specified +as a type (matching Type) followed by an identifier (matching ArgumentName).

    +

    Note: For expressiveness, the identifier of an operation argument can also be specified +as one of the keywords matching the ArgumentNameKeyword symbol without needing to escape it.

    +

    If the Type of an operation argument is an identifier +followed by ?, +then the identifier must identify an interface, enumeration, callback function or typedef. +If the operation argument type is an identifier not followed by ?, then the identifier must +identify any one of those definitions or a dictionary.

    +
    interface interface_identifier {
    +  return_type identifier(type identifier, type identifier /* , ... */);
     };
    -
    -// WorkerUtils is only available in workers.  Evaluating WorkerUtils
    -// in the global scope of a worker would give you its namespace object, while
    -// doing so on the main thread will give you a ReferenceError.
    -[Exposed=Worker]
    -namespace WorkerUtils {
    -  void setPriority(double x);
    +
    +

    The identifier of each argument must not be the same +as the identifier of another argument in the same operation declaration.

    +

    Each argument can be preceded by a list of extended attributes (matching ExtendedAttributeList), +which can control how a value passed as the argument will be handled in +language bindings.

    +
    interface interface_identifier {
    +  return_type identifier([extended_attributes] type identifier, [extended_attributes] type identifier /* , ... */);
     };
    -
    -// NodeUtils is only available in the main thread.  Evaluating NodeUtils
    -// in the global scope of a worker would give you a ReferenceError.
    -namespace NodeUtils {
    -  DOMString getAllText(Node node);
    -};
    -
    -
    - -
    -

    4.3.5. [ImplicitThis]

    -

    - If the [ImplicitThis] - extended attribute - appears on an interface, - it indicates that when a Function corresponding - to one of the interface’s operations - is invoked with the null or undefined - value as the this value, that the ECMAScript global - object will be used as the this value instead. - This is regardless of whether the calling code is in strict mode. -

    -

    - The [ImplicitThis] - extended attribute MUST - take no arguments. -

    -

    - See section 4.6.7 - for the specific requirements that the use of - [ImplicitThis] entails. -

    -
    Note
    -

    The [ImplicitThis] - extended attribute - is intended for use on the Window - interface as defined - in HTML5 ([HTML5], section 5.2).

    -
    -
    Example
    -

    In the following example, the Window - interface is defined - with the [ImplicitThis] - extended attribute.

    -
    IDL
    [ImplicitThis]
    -interface Window {
    -  ...
    -  attribute DOMString name;
    -  void alert(DOMString message);
    -};
    -

    Since the Window object is used as - the ECMAScript global object, calls to its functions can be made - without an explicit object, even in strict mode:

    -
    ECMAScript
    "use strict";
    -
    -window.alert("hello");      // Calling alert with an explicit window object works.
    -alert("hello");             // This also works, even though we are in strict mode.
    -alert.call(null, "hello");  // As does passing null explicitly as the this value.
    -
    -// This does not apply to getters for attributes on the interface, though.
    -// The following will throw a TypeError.
    -Object.getOwnPropertyDescriptor(Window.prototype, "name").get.call(null);
    -
    -
    - -
    -

    4.3.6. [Global] and [PrimaryGlobal]

    - -

    - If the [Global] - or [PrimaryGlobal] - extended attribute - appears on an interface, - it indicates that objects implementing this interface can - be used as the global object in an ECMAScript environment, - and that the structure of the prototype chain and how - properties corresponding to interface members - will be reflected on the prototype objects will be different from other - interfaces. Specifically: -

    -
      -
    1. Any named properties - will be exposed on an object in the prototype chain – the - named properties object – - rather than on the object itself.
    2. -
    3. Interface members from the - interface (or - consequential interfaces) - will correspond to properties on the object itself rather than on - interface prototype objects.
    4. -
    -
    Note
    -

    - Placing named properties on an object in the prototype chain - is done so that variable declarations and bareword assignments - will shadow the named property with a property on the global - object itself. -

    -

    - Placing properties corresponding to interface members on - the object itself will mean that common feature detection - methods like the following will work: -

    -
    ECMAScript
    var indexedDB = window.indexedDB || window.webkitIndexedDB ||
    -                window.mozIndexedDB || window.msIndexedDB;
    -
    -var requestAnimationFrame = window.requestAnimationFrame ||
    -                            window.mozRequestAnimationFrame || ...;
    -

    - Because of the way variable declarations are handled in - ECMAScript, the code above would result in the window.indexedDB - and window.requestAnimationFrame evaluating - to undefined, as the shadowing variable - property would already have been created before the - assignment is evaluated. -

    -
    -

    - If the [Global] or - [PrimaryGlobal] - extended attributes - is used on an interface, then: -

    - -

    - If [Global] or [PrimaryGlobal] is specified on - a partial interface - definition, then that partial interface definition MUST - be the part of the interface definition that defines - the named property getter. -

    -

    - The [Global] and [PrimaryGlobal] - extended attribute MUST NOT - be used on an interface that can have more - than one object implementing it in the same ECMAScript global environment. -

    -
    Note
    -

    This is because the named properties object, - which exposes the named properties, is in the prototype chain, and it would not make - sense for more than one object’s named properties to be exposed on an object that - all of those objects inherit from.

    -
    -

    - If an interface is declared with the [Global] or - [PrimaryGlobal] - extended attribute, then - there MUST NOT be more than one - interface member across - the interface and its consequential interfaces - with the same identifier. - There also MUST NOT be more than - one stringifier, - more than one serializer, - or more than one iterable declaration, - maplike declaration or - setlike declaration - across those interfaces. -

    -
    Note
    -

    This is because all of the members of the interface and its consequential - interfaces get flattened down on to the object that implements the interface.

    -
    -

    - The [Global] and - [PrimaryGlobal] extended attributes - can also be used to give a name to one or more global interfaces, - which can then be referenced by the [Exposed] - extended attribute. -

    -

    - The [Global] and - [PrimaryGlobal] - extended attributes MUST either - take no arguments - or take an identifier list. -

    -

    - If the [Global] or - [PrimaryGlobal] - extended attribute - is declared with an identifier list argument, then those identifiers are the interface’s - global names; otherwise, the interface has - a single global name, which is the interface's identifier. -

    -
    Note
    -

    The identifier argument list exists so that more than one global interface can - be addressed with a single name in an [Exposed] - extended attribute.

    -
    -

    - The [Global] and - [PrimaryGlobal] - extended attributes - MUST NOT be declared on the same - interface. The [PrimaryGlobal] - extended attribute MUST be declared on - at most one interface. The interface [PrimaryGlobal] - is declared on, if any, is known as the primary global interface. -

    -

    - See section 4.6.4, - section 4.8.3 and - section 4.8.7 - for the specific requirements that the use of - [Global] and [PrimaryGlobal] - entails for named properties, - and section 4.6.5, - section 4.6.6 and - section 4.6.7 - for the requirements relating to the location of properties - corresponding to interface members. -

    -
    Example
    -

    - The [PrimaryGlobal] - extended attribute is intended - to be used by the Window interface as defined in - HTML5 ([HTML5], section 5.2). ([Global] - is intended to be used by worker global interfaces.) - The Window interface exposes frames as properties on the Window - object. Since the Window object also serves as the - ECMAScript global object, variable declarations or assignments to the named properties - will result in them being replaced by the new value. Variable declarations for - attributes will not create a property that replaces the existing one. -

    -
    IDL
    [PrimaryGlobal]
    -interface Window {
    -  getter any (DOMString name);
    -  attribute DOMString name;
    -  // ...
    -};
    -

    - The following HTML document illustrates how the named properties on the - Window object can be shadowed, and how - the property for an attribute will not be replaced when declaring - a variable of the same name: -

    -
    HTML
    <!DOCTYPE html>
    -<title>Variable declarations and assignments on Window</title>
    -<iframe name=abc></iframe>
    -<!-- Shadowing named properties -->
    -<script>
    -  window.abc;    // Evaluates to the iframe's Window object.
    -  abc = 1;       // Shadows the named property.
    -  window.abc;    // Evaluates to 1.
    -</script>
    -
    -<!-- Preserving properties for IDL attributes -->
    -<script>
    -  Window.prototype.def = 2;         // Places a property on the prototype.
    -  window.hasOwnProperty("length");  // Evaluates to true.
    -  length;                           // Evaluates to 1.
    -  def;                              // Evaluates to 2.
    -</script>
    -<script>
    -  var length;                       // Variable declaration leaves existing property.
    -  length;                           // Evaluates to 1.
    -  var def;                          // Variable declaration creates shadowing property.
    -  def;                              // Evaluates to undefined.
    -</script>
    -
    -
    - -
    -

    4.3.7. [LegacyArrayClass]

    - -

    - If the [LegacyArrayClass] - extended attribute - appears on an interface - that is not defined to inherit - from another, it indicates that the internal [[Prototype]] - property of its interface prototype object - will be the Array prototype object rather than - the Object prototype object. This allows - Array methods to be used more easily - with objects implementing the interface. -

    -

    - The [LegacyArrayClass] extended attribute - MUST take no arguments. - It MUST NOT be used on an interface that - has any inherited interfaces. -

    -
    Note
    -

    - Interfaces using [LegacyArrayClass] will - need to define a “length” attribute - of type unsigned long that exposes the length - of the array-like object, in order for the inherited Array - methods to operate correctly. Such interfaces would typically also - support indexed properties, - which would provide access to the array elements. -

    -
    -

    - See section 4.6.3 for the - specific requirements that the use of [LegacyArrayClass] - entails. -

    -
    Example
    -

    - The following IDL fragment - defines two interfaces - that use [LegacyArrayClass]. -

    -
    IDL
    [LegacyArrayClass]
    -interface ItemList {
    -  attribute unsigned long length;
    -  getter object getItem(unsigned long index);
    -  setter object setItem(unsigned long index, object item);
    +
    +
    + +

    The following IDL fragment demonstrates how regular operations can be declared on an interface:

    +
    interface Dimensions {
    +  attribute unsigned long width;
    +  attribute unsigned long height;
     };
    -
    -[LegacyArrayClass]
    -interface ImmutableItemList {
    -  readonly attribute unsigned long length;
    -  getter object getItem(unsigned long index);
    -};
    -

    - In an ECMAScript implementation of the above two interfaces, - with appropriate definitions for getItem, setItem and removeItem, - Array methods to inspect and - modify the array-like object can be used. -

    -
    ECMAScript
    var list = getItemList();  // Obtain an instance of ItemList.
    -
    -list.concat();             // Clone the ItemList into an Array.
    -list.pop();                // Remove an item from the ItemList.
    -list.unshift({ });         // Insert an item at index 0.
    -

    - ImmutableItemList has a read only - length attribute - and no indexed property setter. The - mutating Array methods will generally not - succeed on objects implementing ImmutableItemList. - The exact behavior depends on the definition of the Array methods - themselves ([ECMA-262], section 22.1.3). -

    -
    -
    - - -
    -

    4.3.8. [LegacyUnenumerableNamedProperties]

    - -

    - If the [LegacyUnenumerableNamedProperties] - extended attribute - appears on a interface - that supports named properties, - it indicates that all the interface's named properties are unenumerable. -

    -

    - The [LegacyUnenumerableNamedProperties] - extended attribute MUST - take no arguments - and MUST NOT appear on an interface - that does not define a named property getter. -

    -

    - If the [LegacyUnenumerableNamedProperties] - extended attribute is specified on an interface, then it applies to all its derived interfaces and - MUST NOT be specified on any of them. -

    -

    - See section 4.8.10 - for the specific requirements that the use of - [LegacyUnenumerableNamedProperties] - entails. -

    -
    - -
    -

    4.3.9. [LenientSetter]

    -

    - If the [LenientSetter] - extended attribute - appears on a read only - regular attribute, - it indicates that a no-op setter will be generated for the attribute’s - accessor property. This results in erroneous assignments to the property - in strict mode to be ignored rather than causing an exception to be thrown. -

    -
    Warning
    -

    - Specifications SHOULD NOT use [LenientSetter] - unless required for compatibility reasons. Pages have been observed - where authors have attempted to polyfill an IDL attribute by assigning - to the property, but have accidentally done so even if the property - exists. In strict mode, this would cause an exception to be thrown, - potentially breaking page. Without [LenientSetter], - this could prevent a browser from shipping the feature. -

    -

    - Specification authors who - wish to use this feature are strongly advised to discuss this on the - public-script-coord@w3.org - mailing list before proceeding. -

    -
    -

    - The [LenientThis] extended attribute - MUST - take no arguments. - It MUST NOT be used on anything other than - a read only - regular attribute. -

    -

    - An attribute with the [LenientSetter] - extended attribute MUST NOT also be declared - with the [PutForwards] - or [Replaceable] extended attributes. -

    -

    - See the Attributes section below for how - [LenientSetter] - is to be implemented. -

    -
    Example
    -

    - The following IDL fragment defines an interface that uses the - [LenientSetter] extended - attribute. -

    -
    IDL
    interface Example {
    -  [LenientSetter] readonly attribute DOMString x;
    -  readonly attribute DOMString y;
    -};
    -

    - An ECMAScript implementation that supports this interface will - have a setter on the accessor property that correspond to x, - which allows any assignment to be ignored in strict mode. -

    -
    ECMAScript
    "use strict";
    -
    -var example = getExample();  // Get an instance of Example.
    -
    -// Fine; while we are in strict mode, there is a setter that is a no-op.
    -example.x = 1;
    -
    -// Throws a TypeError, since we are in strict mode and there is no setter.
    -example.y = 1;
    -
    -
    - -
    -

    4.3.10. [LenientThis]

    -

    - If the [LenientThis] - extended attribute - appears on a regular attribute, - it indicates that invocations of the attribute’s getter or setter - with a this value that is not an - object that implements the interface - on which the attribute appears will be ignored. -

    -

    - The [LenientThis] extended attribute - MUST - take no arguments. - It MUST NOT be used on a - static attribute. -

    -
    Warning
    -

    - Specifications SHOULD NOT use [LenientThis] - unless required for compatibility reasons. Specification authors who - wish to use this feature are strongly advised to discuss this on the - public-script-coord@w3.org - mailing list before proceeding. -

    -
    -

    - See the Attributes section below for how - [LenientThis] - is to be implemented. -

    -
    Example
    -

    - The following IDL fragment defines an interface that uses the - [LenientThis] extended - attribute. -

    -
    IDL
    interface Example {
    -  [LenientThis] attribute DOMString x;
    -  attribute DOMString y;
    -};
    -

    - An ECMAScript implementation that supports this interface will - allow the getter and setter of the accessor property that corresponds - to x to be invoked with something other than an Example - object. -

    -
    ECMAScript
    var example = getExample();  // Get an instance of Example.
    -var obj = { };
    -
    -// Fine.
    -example.x;
    -
    -// Ignored, since the this value is not an Example object and [LenientThis] is used.
    -Object.getOwnPropertyDescriptor(Example.prototype, "x").get.call(obj);
    -
    -// Also ignored, since Example.prototype is not an Example object and [LenientThis] is used.
    -Example.prototype.x;
    -
    -// Throws a TypeError, since Example.prototype is not an Example object.
    -Example.prototype.y;
    -
    -
    - -
    -

    4.3.11. [NamedConstructor]

    -

    - If the [NamedConstructor] - extended attribute - appears on an interface, - it indicates that the ECMAScript global object will have a property with the - specified name whose value is a constructor function that can - create objects that implement the interface. - Multiple [NamedConstructor] extended - attributes may appear on a given interface. -

    -

    - The [NamedConstructor] - extended attribute MUST either - take an identifier or - take a named argument list. - The first form, [NamedConstructor=identifier], has the same meaning as - using an empty argument list, [NamedConstructor=identifier()]. For each - [NamedConstructor] extended attribute - on the interface, there will be a way to construct an object that implements - the interface by passing the specified arguments to the constructor function - that is the value of the aforementioned property. -

    -

    - The identifier used for the named constructor MUST NOT - be the same as that used by an [NamedConstructor] - extended attribute on another interface, MUST NOT - be the same as an identifier of an interface - that has an interface object, - and MUST NOT be one of the - reserved identifiers. -

    -

    - The [NamedConstructor] extended attribute - MUST NOT be used on a callback interface. -

    -

    - See section 4.6.2 - below for details on how named constructors - are to be implemented. -

    - -
    Example
    -

    - The following IDL defines an interface that uses the - [NamedConstructor] extended - attribute. -

    -
    IDL
    [NamedConstructor=Audio,
    - NamedConstructor=Audio(DOMString src)]
    -interface HTMLAudioElement : HTMLMediaElement {
    -  // ...
    -};
    -

    - An ECMAScript implementation that supports this interface will - allow the construction of HTMLAudioElement - objects using the Audio constructor. -

    -
    ECMAScript
    typeof Audio;                   // Evaluates to 'function'.
    -
    -var a1 = new Audio();           // Creates a new object that implements
    -                                // HTMLAudioElement, using the zero-argument
    -                                // constructor.
    -
    -var a2 = new Audio('a.flac');   // Creates an HTMLAudioElement using the
    -                                // one-argument constructor.
    -
    -
    - -
    -

    4.3.12. [NewObject]

    - -

    - If the [NewObject] - extended attribute - appears on a regular - or static - operation, - then it indicates that when calling the operation, - a reference to a newly created object - MUST always be returned. -

    -

    - The [NewObject] - extended attribute MUST - take no arguments. -

    -

    - The [NewObject] - extended attribute MUST NOT - be used on anything other than a regular - or static - operation - whose return type - is an interface type or - a promise type. -

    -
    Example
    -

    - As an example, this extended attribute is suitable for use on - the createElement - operation on the Document - interface ([DOM], section 6.5), - since a new object should always be returned when - it is called. -

    -
    IDL
    interface Document : Node {
    -  [NewObject] Element createElement(DOMString localName);
    -  ...
    -};
    -
    -
    - -
    -

    4.3.13. [NoInterfaceObject]

    - -

    - If the [NoInterfaceObject] - extended attribute - appears on an interface, - it indicates that an - interface object - will not exist for the interface in the ECMAScript binding. -

    -
    Warning
    -

    - The [NoInterfaceObject] extended attribute - SHOULD NOT be used on interfaces that are not - solely used as supplemental interfaces, - unless there are clear Web compatibility reasons for doing so. Specification authors who - wish to use this feature are strongly advised to discuss this on the - public-script-coord@w3.org - mailing list before proceeding. -

    -
    -

    - The [NoInterfaceObject] extended attribute - MUST take no arguments. -

    -

    - If the [NoInterfaceObject] extended attribute - is specified on an interface, then the [Constructor] - extended attribute MUST NOT also be specified on that interface. - A [NamedConstructor] extended attribute is fine, - however. -

    -

    - The [NoInterfaceObject] extended attribute - MUST NOT be specified on an interface that has any - static operations defined on it. -

    -

    - The [NoInterfaceObject] extended attribute - MUST NOT be specified on a callback interface - unless it has a constant declared on it. - This is because callback interfaces without constants never have - interface objects. -

    -

    - An interface that does not have the [NoInterfaceObject] extended - attribute specified MUST NOT inherit - from an interface that has the [NoInterfaceObject] extended - attribute specified. -

    -

    - See section 4.2.20 - for the specific requirements that the use of - [NoInterfaceObject] entails. -

    -
    Example
    -

    - The following IDL - fragment defines two interfaces, one whose interface object - is exposed on the ECMAScript global object, and one whose isn’t: -

    -
    IDL
    interface Storage {
    -  void addEntry(unsigned long key, any value);
    +        
    +interface Button {
    +        
    +  // An operation that takes no arguments and returns a boolean.
    +  boolean isMouseOver();
    +        
    +  // Overloaded operations.
    +  void setDimensions(Dimensions size);
    +  void setDimensions(unsigned long width, unsigned long height);
     };
    -
    -[NoInterfaceObject]
    -interface Query {
    -  any lookupEntry(unsigned long key);
    -};
    -

    - An ECMAScript implementation of the above IDL would allow - manipulation of Storage’s - prototype, but not Query’s. -

    -
    ECMAScript
    typeof Storage;                        // evaluates to "object"
    -
    -// Add some tracing alert() call to Storage.addEntry.
    -var fn = Storage.prototype.addEntry;
    -Storage.prototype.addEntry = function(key, value) {
    -  alert('Calling addEntry()');
    -  return fn.call(this, key, value);
    +
    +
    +

    An operation is considered to be variadic if the final argument uses the ... token just +after the argument type. Declaring an operation to be variadic indicates that +the operation can be invoked with any number of arguments after that final argument. +Those extra implied formal arguments are of the same type as the final explicit +argument in the operation declaration. The final argument can also be omitted +when invoking the operation. An argument must not +be declared with the ... token unless it +is the final argument in the operation’s argument list.

    +
    interface interface_identifier {
    +  return_type identifier(type... identifier);
    +  return_type identifier(type identifier, type... identifier);
     };
    -
    -typeof Query;                          // evaluates to "undefined"
    -var fn = Query.prototype.lookupEntry;  // exception, Query isn’t defined
    -
    -
    -
    - -
    -

    4.3.14. [OverrideBuiltins]

    - -

    - If the [OverrideBuiltins] - extended attribute - appears on an interface, - it indicates that for a platform object implementing the interface, - properties corresponding to all of - the object’s supported property names - will appear to be on the object, - regardless of what other properties exist on the object or its - prototype chain. This means that named properties will always shadow - any properties that would otherwise appear on the object. - This is in contrast to the usual behavior, which is for named properties - to be exposed only if there is no property with the - same name on the object itself or somewhere on its prototype chain. -

    -

    - The [OverrideBuiltins] - extended attribute MUST - take no arguments - and MUST NOT appear on an interface - that does not define a named property getter - or that also is declared with the [Global] - or [PrimaryGlobal] - extended attribute. If the extended attribute is specified on - a partial interface - definition, then that partial interface definition MUST - be the part of the interface definition that defines - the named property getter. -

    -

    - See section 4.8.1 - and section 4.8.7 - for the specific requirements that the use of - [OverrideBuiltins] entails. -

    -
    Example
    -

    - The following IDL fragment - defines two interfaces, - one that has a named property getter - and one that does not. -

    -
    IDL
    interface StringMap {
    -  readonly attribute unsigned long length;
    -  getter DOMString lookup(DOMString key);
    +
    +

    Extended attributes that take an argument list ([Constructor] and +[NamedConstructor], of those +defined in this specification) and callback functions are also considered to be variadic when the ... token is used in their argument lists.

    +
    + +

    The following IDL fragment defines an interface that has + two variadic operations:

    +
    interface IntegerSet {
    +  readonly attribute unsigned long cardinality;
    +        
    +  void union(long... ints);
    +  void intersection(long... ints);
     };
    -
    -[OverrideBuiltins]
    -interface StringMap2 {
    -  readonly attribute unsigned long length;
    -  getter DOMString lookup(DOMString key);
    -};
    -

    - In an ECMAScript implementation of these two interfaces, - getting certain properties on objects implementing - the interfaces will result in different values: -

    -
    ECMAScript
    // Obtain an instance of StringMap.  Assume that it has "abc", "length" and
    -// "toString" as supported property names.
    -var map1 = getStringMap();
    -
    -// This invokes the named property getter.
    -map1.abc;
    -
    -// This fetches the "length" property on the object that corresponds to the
    -// length attribute.
    -map1.length;
    -
    -// This fetches the "toString" property from the object's prototype chain.
    -map1.toString;
    -
    -
    -// Obtain an instance of StringMap2.  Assume that it also has "abc", "length"
    -// and "toString" as supported property names.
    -var map2 = getStringMap2();
    -
    -// This invokes the named property getter.
    -map2.abc;
    -
    -// This also invokes the named property getter, despite the fact that the "length"
    -// property on the object corresponds to the length attribute.
    -map2.length;
    -
    -// This too invokes the named property getter, despite the fact that "toString" is
    -// a property in map2's prototype chain.
    -map2.toString;
    -
    -
    - - - -
    -

    4.3.15. [PutForwards]

    - -

    - If the [PutForwards] - extended attribute - appears on a read only - regular attribute declaration whose type is - an interface type, - it indicates that assigning to the attribute will have specific behavior. - Namely, the assignment is “forwarded” to the attribute (specified by - the extended attribute argument) on the object that is currently - referenced by the attribute being assigned to. -

    -

    - The [PutForwards] extended - attribute MUST take an identifier. - Assuming that: -

    - -

    - then there MUST be another - attribute B - declared on J whose identifier - is N. Assignment of a value to the attribute A - on an object implementing I will result in that value - being assigned to attribute B of the object that A - references, instead. -

    -

    - Note that [PutForwards]-annotated - attributes can be - chained. That is, an attribute with the [PutForwards] - extended attribute - can refer to an attribute that itself has that extended attribute. - There MUST NOT exist a cycle in a - chain of forwarded assignments. A cycle exists if, when following - the chain of forwarded assignments, a particular attribute on - an interface is - encountered more than once. -

    -

    - An attribute with the [PutForwards] - extended attribute MUST NOT also be declared - with the [LenientSetter] or - [Replaceable] extended attributes. -

    -

    - The [PutForwards] - extended attribute MUST NOT be used - on an attribute that - is not read only. -

    -

    - The [PutForwards] extended attribute - MUST NOT be used on a - static attribute. -

    -

    - The [PutForwards] extended attribute - MUST NOT be used on an attribute declared on - a callback interface. -

    -

    - See the Attributes section below for how - [PutForwards] - is to be implemented. -

    -
    Example
    -

    - The following IDL fragment defines interfaces for names and people. - The [PutForwards] extended - attribute is used on the name attribute - of the Person interface to indicate - that assignments to that attribute result in assignments to the - full attribute of the - Person object: -

    -
    IDL
    interface Name {
    -  attribute DOMString full;
    -  attribute DOMString family;
    -  attribute DOMString given;
    +
    +
    +

    If an implementation attempts to invoke + an operation on a user object (for example, when a callback object has been supplied to the implementation), + and that attempt results in an exception being thrown, then, + unless otherwise specified, + that exception will be propagated to + the user code that caused the implementation to invoke the operation. + Similarly, if a value returned from invoking the operation + cannot be converted to an IDL type, + then any exception resulting from this will also + be propagated to the user code + that resulted in the implementation attempting to invoke the operation.

    +

    The following extended attributes are applicable to operations: +[Exposed], +[NewObject], +[SecureContext], +[TreatNullAs], +[Unforgeable].

    +

    The following extended attributes are applicable to operation arguments: +[Clamp], +[EnforceRange], +[TreatNullAs].

    +
    DefaultValue :
    +    ConstValue
    +    string
    +    "[" "]"
    +
    +
    Operation :
    +    ReturnType OperationRest
    +    SpecialOperation
    +
    +
    SpecialOperation :
    +    Special Specials ReturnType OperationRest
    +
    +
    Specials :
    +    Special Specials
    +    ε
    +
    +
    Special :
    +    "getter"
    +    "setter"
    +    "deleter"
    +    "legacycaller"
    +
    +
    OperationRest :
    +    OptionalIdentifier "(" ArgumentList ")" ";"
    +
    +
    OptionalIdentifier :
    +    identifier
    +    ε
    +
    +
    ArgumentList :
    +    Argument Arguments
    +    ε
    +
    +
    Arguments :
    +    "," Argument Arguments
    +    ε
    +
    +
    Argument :
    +    ExtendedAttributeList OptionalOrRequiredArgument
    +
    +
    OptionalOrRequiredArgument :
    +    "optional" Type ArgumentName Default
    +    Type Ellipsis ArgumentName
    +
    +
    ArgumentName :
    +    ArgumentNameKeyword
    +    identifier
    +
    +
    Ellipsis :
    +    "..."
    +    ε
    +
    +
    +
    ReturnType :
    +    Type
    +    "void"
    +
    +

    3.2.4. Special operations

    +

    A special operation is a +declaration of a certain kind of special behavior on objects implementing +the interface on which the special operation declarations appear. +Special operations are declared by using one or more special keywords in an operation declaration.

    +

    There are six kinds of special operations. The table below indicates +for a given kind of special operation what special keyword +is used to declare it and what the purpose of the special operation is:

    + + + + + + + + + +
    Special operation + Keyword + Purpose +
    Getters + getter + Defines behavior for when an object is indexed for property retrieval. +
    Setters + setter + Defines behavior for when an object is indexed for property + assignment or creation. +
    Deleters + deleter + Defines behavior for when an object is indexed for property deletion. +
    Legacy callers + legacycaller + Defines behavior for when an object is called as if it were a function. +
    Stringifiers + stringifier + Defines how an object is converted into a DOMString. +
    Serializers + serializer + Defines how an object is converted into a serialized form. +
    +

    Not all language bindings support all of the six kinds of special +object behavior. When special operations are declared using +operations with no identifier, then in language bindings that do +not support the particular kind of special operations there simply +will not be such functionality.

    +
    + +

    The following IDL fragment defines an interface with a getter and a setter:

    +
    interface Dictionary {
    +  readonly attribute unsigned long propertyCount;
    +        
    +  getter double (DOMString propertyName);
    +  setter void (DOMString propertyName, double propertyValue);
     };
    -
    -interface Person {
    -  [PutForwards=full] readonly attribute Name name;
    -  attribute unsigned short age;
    -};
    -

    - In the ECMAScript binding, this would allow assignments to the - “name” property: -

    -
    ECMAScript
    var p = getPerson();           // Obtain an instance of Person.
    -
    -p.name = 'John Citizen';       // This statement...
    -p.name.full = 'John Citizen';  // ...has the same behavior as this one.
    -
    -
    - -
    -

    4.3.16. [Replaceable]

    - -

    - If the [Replaceable] - extended attribute - appears on a read only - regular attribute, - it indicates that setting the corresponding property on the - platform object will result in - an own property with the same name being created on the object - which has the value being assigned. This property will shadow - the accessor property corresponding to the attribute, which - exists on the interface prototype object. -

    -

    - The [Replaceable] - extended attribute MUST - take no arguments. -

    -

    - An attribute with the [Replaceable] - extended attribute MUST NOT also be declared - with the [LenientSetter] or - [PutForwards] extended attributes. -

    -

    - The [Replaceable] - extended attribute MUST NOT be used - on an attribute that - is not read only. -

    -

    - The [Replaceable] extended attribute - MUST NOT be used on a - static attribute. -

    -

    - The [Replaceable] extended attribute - MUST NOT be used on an attribute declared on - a callback interface. -

    -

    - See section 4.6.6 - for the specific requirements that the use of - [Replaceable] entails. -

    -
    Example
    -

    - The following IDL fragment - defines an interface - with an operation - that increments a counter, and an attribute - that exposes the counter’s value, which is initially 0: -

    -
    IDL
    interface Counter {
    -  [Replaceable] readonly attribute unsigned long value;
    -  void increment();
    -};
    -

    - Assigning to the “value” property - on a platform object implementing Counter - will shadow the property that corresponds to the - attribute: -

    -
    ECMAScript
    var counter = getCounter();                              // Obtain an instance of Counter.
    -counter.value;                                           // Evaluates to 0.
    -
    -counter.hasOwnProperty("value");                         // Evaluates to false.
    -Object.getPrototypeOf(counter).hasOwnProperty("value");  // Evaluates to true.
    -
    -counter.increment();
    -counter.increment();
    -counter.value;                                           // Evaluates to 2.
    -
    -counter.value = 'a';                                     // Shadows the property with one that is unrelated
    -                                                         // to Counter::value.
    -
    -counter.hasOwnProperty("value");                         // Evaluates to true.
    -
    -counter.increment();
    -counter.value;                                           // Evaluates to 'a'.
    -
    -delete counter.value;                                    // Reveals the original property.
    -counter.value;                                           // Evaluates to 3.
    -
    -
    - -
    -

    4.3.17. [SameObject]

    - -

    - If the [SameObject] - extended attribute - appears on a read only - attribute, then it - indicates that when getting the value of the attribute on a given - object, the same value MUST always - be returned. -

    -

    - The [SameObject] - extended attribute MUST - take no arguments. -

    -

    - The [SameObject] - extended attribute MUST NOT - be used on anything other than a read only - attribute - whose type is an interface type - or object. -

    -
    Example
    -

    - As an example, this extended attribute is suitable for use on - the implementation - attribute on the Document - interface ([DOM], section 6.5), - since the same object is always returned for a given - Document object. -

    -
    IDL
    interface Document : Node {
    -  [SameObject] readonly attribute DOMImplementation implementation;
    -  ...
    -};
    -
    -
    - -
    -

    4.3.18. [SecureContext]

    - -

    - If the [SecureContext] - extended attribute - appears on an interface, - partial interface, - namespace, - partial namespace, - interface member, or - namespace member, - it indicates that the construct is exposed - only within a - secure context - ([SECURE-CONTEXTS], section 2). -

    -

    - The [SecureContext] - extended attribute MUST - take no arguments. -

    -

    - The [SecureContext] - extended attribute MUST NOT - be used on anything other than an - interface, - partial interface, - namespace, - partial namespace, - interface member, or - namespace member. -

    -

    - Whether a construct that the [SecureContext] - extended attribute - can be specified on is available only in secure contexts - is defined as follows: -

    - -
    Note
    -

    - Whether a construct is - available only in secure contexts - influences whether it is exposed in a given - ECMAScript global environment. -

    -
    -

    - If [SecureContext] appears on an - overloaded operation, - then it MUST appear on all overloads. -

    -

    - The [SecureContext] extended attribute - MUST NOT be specified on both an interface member and the - interface or partial interface definition the interface member is declared on, or - on both a namespace member and the namespace or partial namespace definition the - namespace member is declared on. -

    -

    - An interface without the [SecureContext] extended attribute - MUST NOT inherit from another interface - that does specify [SecureContext]. -

    -
    Example
    -

    The following IDL fragment defines an interface - with one operation that is executable from all - contexts, and two which are executable only from secure contexts.

    - -
    IDL
    interface PowerfulFeature {
    -  // This call will succeed in all contexts.
    -  Promise <Result> calculateNotSoSecretResult();
    -
    -  // This operation will not be exposed to a non-secure context. In such a context,
    -  // there will be no "calculateSecretResult" property on PowerfulFeature.prototype.
    -  [SecureContext] Promise<Result> calculateSecretResult();
    -
    -  // The same applies here: the attribute will not be exposed to a non-secure context,
    -  // and in a non-secure context there will be no "secretBoolean" property on
    -  // PowerfulFeature.prototype.
    -  [SecureContext] readonly attribute boolean secretBoolean;
    -};
    - -
    -
    - -
    -

    4.3.19. [TreatNonObjectAsNull]

    - -

    - If the [TreatNonObjectAsNull] - extended attribute - appears on a callback function, - then it indicates that any value assigned to an attribute - whose type is a nullable - callback function - that is not an object will be converted to - the null value. -

    -
    Warning
    -

    - Specifications SHOULD NOT use [TreatNonObjectAsNull] - unless required to specify the behavior of legacy APIs or for consistency with these - APIs. Specification authors who - wish to use this feature are strongly advised to discuss this on the - public-script-coord@w3.org - mailing list before proceeding. At the time of writing, the only known - valid use of [TreatNonObjectAsNull] - is for the callback functions used as the type - of event handler IDL attributes - ([HTML5], section 6.1.6.1) - such as onclick and onerror. -

    -
    -

    - See section 4.2.24 - for the specific requirements that the use of - [TreatNonObjectAsNull] entails. -

    -
    Example
    -

    - The following IDL fragment defines an interface that has one - attribute whose type is a [TreatNonObjectAsNull]-annotated - callback function and another whose type is a - callback function without the extended attribute: -

    -
    IDL
    callback OccurrenceHandler = void (DOMString details);
    -
    -[TreatNonObjectAsNull]
    -callback ErrorHandler = void (DOMString details);
    -
    -interface Manager {
    -  attribute OccurrenceHandler? handler1;
    -  attribute ErrorHandler? handler2;
    -};
    -

    - In an ECMAScript implementation, assigning a value that is not - an object (such as a Number value) - to handler1 will have different behavior from that when assigning - to handler2: -

    -
    ECMAScript
    var manager = getManager();  // Get an instance of Manager.
    -
    -manager.handler1 = function() { };
    -manager.handler1;            // Evaluates to the function.
    -
    -try {
    -  manager.handler1 = 123;    // Throws a TypeError.
    -} catch (e) {
    -}
    -
    -manager.handler2 = function() { };
    -manager.handler2;            // Evaluates to the function.
    -
    -manager.handler2 = 123;
    -manager.handler2;            // Evaluates to null.
    -
    -
    - -
    -

    4.3.20. [TreatNullAs]

    - -

    - If the [TreatNullAs] - extended attribute - appears on an attribute - or operation argument whose type is - DOMString, - it indicates that a null value - assigned to the attribute or passed as the operation argument will be - handled differently from its default handling. Instead of being stringified - to “null”, which is the default, - it will be converted to the empty string “”. -

    -

    - If [TreatNullAs] is specified on - an operation itself, and that operation is on a callback interface, - then it indicates that a user object implementing the interface will have the return - value of the function that implements the operation handled in the same way as for operation arguments - and attributes, as above. -

    -

    - The [TreatNullAs] - extended attribute MUST take the identifier - EmptyString. -

    -

    - The [TreatNullAs] extended attribute - MUST NOT be specified on an operation argument, - attribute or operation return value whose type is not DOMString. -

    -
    Note
    -

    This means that even an attribute of type DOMString? must not - use [TreatNullAs], since null - is a valid value of that type.

    -
    -

    - The [TreatNullAs] extended attribute - also MUST NOT be specified on an operation on - a non-callback interface. -

    -

    - See section 4.2.16 - for the specific requirements that the use of - [TreatNullAs] entails. -

    -
    Example
    -

    - The following IDL fragment defines an interface that has one - attribute with the [TreatNullAs] - extended attribute, and one operation with an argument that has - the extended attribute: -

    -
    IDL
    interface Dog {
    -  attribute DOMString name;
    -  [TreatNullAs=EmptyString] attribute DOMString owner;
    -
    -  boolean isMemberOfBreed([TreatNullAs=EmptyString] DOMString breedName);
    -};
    -

    - An ECMAScript implementation implementing the Dog - interface would convert a null value - assigned to the “owner” property or passed as the - argument to the isMemberOfBreed function - to the empty string rather than "null": -

    -
    ECMAScript
    var d = getDog();         // Assume d is a platform object implementing the Dog
    -                          // interface.
    -
    -d.name = null;            // This assigns the string "null" to the .name
    -                          // property.
    -
    -d.owner = null;           // This assigns the string "" to the .owner property.
    -
    -d.isMemberOfBreed(null);  // This passes the string "" to the isMemberOfBreed
    -                          // function.
    -
    -
    - -
    -

    4.3.21. [Unforgeable]

    - -

    - If the [Unforgeable] - extended attribute - appears on a non-static - attribute - or non-static - operations, it indicates - that the attribute or operation will be reflected as an ECMAScript property in - a way that means its behavior cannot be modified and that performing - a property lookup on the object will always result in the attribute’s - property value being returned. In particular, the property will be - non-configurable and will exist as an own property on the object - itself rather than on its prototype. -

    -

    - If the [Unforgeable] - extended attribute - appears on an interface, - it indicates that all of the non-static - attributes - and non-static - operations declared on - that interface and its consequential interfaces - will be similarly reflected as own ECMAScript properties on objects - that implement the interface, rather than on the prototype. -

    -

    - An attribute or operation is said to be unforgeable - on a given interface A if any of the following are true: -

    - -

    - The [Unforgeable] - extended attribute MUST - take no arguments. -

    -

    - The [Unforgeable] - extended attribute MUST NOT appear on - anything other than an attribute, - non-static operation - or an interface. If it does - appear on an operation, then - it MUST appear on all operations with - the same identifier on that interface. -

    -

    - If an attribute or operation X is unforgeable - on an interface A, and A is one of the - inherited interfaces - of another interface B, then B and all of its - consequential interfaces - MUST NOT have a non-static attribute or - regular operation with the same - identifier as X. -

    -
    Note
    -

    For example, the following is disallowed:

    -
    IDL
    interface A1 {
    -  [Unforgeable] readonly attribute DOMString x;
    +
    +

    In language bindings that do not support property getters and setters, + objects implementing Dictionary will not + have that special behavior.

    +
    +

    Defining a special operation with an identifier is equivalent to separating the special operation out into its own +declaration without an identifier. This approach is allowed to +simplify prose descriptions of an interface’s operations.

    +
    + +

    The following two interfaces are equivalent:

    +
    interface Dictionary {
    +  readonly attribute unsigned long propertyCount;
    +        
    +  getter double getProperty(DOMString propertyName);
    +  setter void setProperty(DOMString propertyName, double propertyValue);
     };
    -interface B1 : A1 {
    -  void x();  // Invalid; would be shadowed by A1's x.
    +
    +
    interface Dictionary {
    +  readonly attribute unsigned long propertyCount;
    +        
    +  double getProperty(DOMString propertyName);
    +  void setProperty(DOMString propertyName, double propertyValue);
    +        
    +  getter double (DOMString propertyName);
    +  setter void (DOMString propertyName, double propertyValue);
     };
    -
    -interface B2 : A1 { };
    -B2 implements Mixin;
    -interface Mixin {
    -  void x();  // Invalid; B2's copy of x would be shadowed by A1's x.
    +
    +
    +

    A given special keyword must not +appear twice on an operation.

    +

    Getters and setters come in two varieties: ones that +take a DOMString as a property name, +known as named property getters and named property setters, +and ones that take an unsigned long as a property index, known as indexed property getters and indexed property setters. +There is only one variety of deleter: named property deleters. +See §3.2.4.4 Indexed properties and §3.2.4.5 Named properties for details.

    +

    On a given interface, +there must exist at most one +stringifier, at most one serializer, at most one named property deleter, +and at most one of each variety of getter and setter. +Multiple legacy callers can exist on an interface +to specify overloaded calling behavior.

    +

    If an interface has a setter of a given variety, +then it must also have a getter of that +variety. If it has a named property deleter, +then it must also have a named property getter.

    +

    Special operations declared using operations must not +be variadic nor have any optional arguments.

    +

    Special operations must not be declared on callback interfaces.

    +

    If an object implements more than one interface that defines a given special operation, then it is undefined which (if any) +special operation is invoked for that operation.

    +
    3.2.4.1. Legacy callers
    +

    When an interface has one or more legacy callers, it indicates that objects that implement +the interface can be called as if they were functions. As mentioned above, +legacy callers can be specified using an operation declared with the legacycaller keyword.

    +
    interface interface_identifier {
    +  legacycaller return_type identifier(/* arguments... */);
    +  legacycaller return_type (/* arguments... */);
     };
    -
    -[Unforgeable]
    -interface A2 {
    -  readonly attribute DOMString x;
    +
    +

    If multiple legacy callers are specified on an interface, overload resolution +is used to determine which legacy caller is invoked when the object is called +as if it were a function.

    +

    Legacy callers must not be defined to return a promise type.

    +

    Legacy callers are universally recognised as an undesirable feature. They exist + only so that legacy Web platform features can be specified. Legacy callers + should not be used in specifications unless required to + specify the behavior of legacy APIs, and even then this should be discussed on + the public-script-coord@w3.org mailing list before proceeding.

    +
    + +

    The following IDL fragment defines an interface with a legacy caller.

    +
    interface NumberQuadrupler {
    +  // This operation simply returns four times the given number x.
    +  legacycaller double compute(double x);
     };
    -interface B3 : A2 {
    -  void x();  // Invalid; would be shadowed by A2's x.
    +
    +

    An ECMAScript implementation supporting this interface would + allow a platform object that implements NumberQuadrupler to be called as a function:

    +
    var f = getNumberQuadrupler();  // Obtain an instance of NumberQuadrupler.
    +        
    +f.compute(3);                   // This evaluates to 12.
    +f(3);                           // This also evaluates to 12.
    +
    +
    3.2.4.2. Stringifiers
    +

    When an interface has a stringifier, it indicates that objects that implement +the interface have a non-default conversion to a string. As mentioned above, +stringifiers can be specified using an operation declared with the stringifier keyword.

    +
    interface interface_identifier {
    +  stringifier DOMString identifier();
    +  stringifier DOMString ();
     };
    -
    -interface B4 : A2 { };
    -B4 implements Mixin;
    -interface Mixin {
    -  void x();  // Invalid; B4's copy of x would be shadowed by A2's x.
    +
    +

    If an operation used to declare a stringifier does not have an identifier, then prose +accompanying the interface must define +the stringification behavior of the interface. If the operation does have an identifier, +then the object is converted to a string by invoking the +operation to obtain the string.

    +

    Stringifiers declared with operations must +be declared to take zero arguments and return a DOMString.

    +

    As a shorthand, if the stringifier keyword +is declared using an operation with no identifier, then the +operation’s return type and +argument list can be omitted.

    +
    interface interface_identifier {
    +  stringifier;
     };
    -
    -interface A3 { };
    -A3 implements A2;
    -interface B5 : A3 {
    -  void x();  // Invalid; would be shadowed by A3's mixed-in copy of A2's x.
    -};
    -
    -

    - See section 4.6.6, - section 4.6.7, - section 4.8, - section 4.8.1 and - section 4.8.7 - for the specific requirements that the use of - [Unforgeable] entails. -

    -
    Example
    -

    - The following IDL fragment defines - an interface that has two attributes, - one of which is designated as [Unforgeable]: -

    -
    IDL
    interface System {
    -  [Unforgeable] readonly attribute DOMString username;
    -  readonly attribute long long loginTime;
    -};
    -

    - In an ECMAScript implementation of the interface, the username attribute will be exposed as a non-configurable property on the - object itself: -

    -
    ECMAScript
    var system = getSystem();                      // Get an instance of System.
    -
    -system.hasOwnProperty("username");             // Evaluates to true.
    -system.hasOwnProperty("loginTime");            // Evaluates to false.
    -System.prototype.hasOwnProperty("username");   // Evaluates to false.
    -System.prototype.hasOwnProperty("loginTime");  // Evaluates to true.
    -
    -try {
    -  // This call would fail, since the property is non-configurable.
    -  Object.defineProperty(system, "username", { value: "administrator" });
    -} catch (e) { }
    -
    -// This defineProperty call would succeed, because System.prototype.loginTime
    -// is configurable.
    -var forgedLoginTime = 5;
    -Object.defineProperty(System.prototype, "loginTime", { value: forgedLoginTime });
    -
    -system.loginTime;  // So this now evaluates to forgedLoginTime.
    -
    -
    - -
    -

    4.3.22. [Unscopable]

    - -

    - If the [Unscopable] - extended attribute - appears on a regular attribute - or regular operation, it - indicates that an object that implements an interface with the given - interface member will not include its property name in any object - environment record with it as its base object. The result of this is - that bare identifiers matching the property name will not resolve to - the property in a with statement. This is achieved by - including the property name on the - interface prototype object’s - @@unscopables property’s value. -

    -

    - The [Unscopable] - extended attribute MUST - take no arguments. -

    -

    - The [Unscopable] - extended attribute MUST NOT appear on - anything other than a regular attribute - or regular operation. -

    -

    - See section 4.6.3 - for the specific requirements that the use of - [Unscopable] entails. -

    -
    Note
    -

    For example, with the following IDL:

    -
    IDL
    interface Thing {
    -  void f();
    -  [Unscopable] g();
    -};
    -

    the “f” property an be referenced with a bare identifier - in a with statement but the “g” property cannot:

    -
    ECMAScript
    var thing = getThing();  // An instance of Thing
    -with (thing) {
    -  f;                     // Evaluates to a Function object.
    -  g;                     // Throws a ReferenceError.
    -}
    -
    -
    -
    - -
    -

    4.4. Security

    - -

    - Certain algorithms in the sections below are defined to - perform a security check on a given - object. This check is used to determine whether a given - operation invocation or - attribute access should be - allowed. The security check takes the following four inputs: -

    -
      -
    1. the platform object on - which the operation invocation or attribute access is being done,
    2. -
    3. the ECMAScript global environment associated with the - Function object that implements the - operation or attribute,
    4. -
    5. the identifier - of the operation or attribute, and
    6. -
    7. the type of the Function object – - “method” (when it corresponds to an IDL operation), or - “getter” or “setter” (when it corresponds to the - getter or setter function of an IDL attribute).
    8. -
    -
    Note
    -

    The expectation is that the HTML specification defines how a - security check is performed, and that it will either throw an - appropriate exception or return normally. [HTML]

    -
    -
    - -
    -

    4.5. Overload resolution algorithm

    - -

    - In order to define how overloaded function invocations are resolved, the - overload resolution algorithm - is defined. Its input is an effective overload set, - S, and a list of ECMAScript values, arg0..n−1. - Its output is a pair consisting of the operation or - extended attribute of one of S’s entries - and a list of IDL values or the special value “missing”. The algorithm behaves as follows: -

    -
      -
    1. Let maxarg be the length of the longest type list of the entries in S.
    2. -
    3. Initialize argcount to be min(maxargn).
    4. - -
    5. Remove from S all entries whose type list is not of length argcount.
    6. - -
    7. If S is empty, then throw a TypeError.
    8. - -
    9. Initialize d to −1.
    10. - -
    11. - Initialize method to - undefined. -
    12. - -
    13. If there is more than one entry in S, then set - d to be the distinguishing argument index - for the entries of S.
    14. - -
    15. Initialize values to be an empty list, where each entry will be either an IDL value or the special value “missing”.
    16. - -
    17. Initialize i to 0.
    18. - -
    19. While i < d: -
        -
      1. Let V be argi.
      2. -
      3. Let type be the type at index i in the type list of any entry in S. -
        Note

        All entries in S at this point have the same type and optionality value at index i.

        -
      4. -
      5. Let optionality be the value at index i in the list of optionality values of any entry in S.
      6. -
      7. If optionality is “optional” and V is undefined, then: -
          -
        1. If the argument at index i is declared with a default value, - then append to values that default value.
        2. -
        3. Otherwise, append to values the special value “missing”.
        4. -
        -
      8. -
      9. Otherwise, append to values the result of converting - V to IDL type type.
      10. -
      11. Set i to i + 1.
      12. -
      -
    20. - -
    21. If i = d, then: -
        -
      1. Let V be argi. -
        Note

        This is the argument that will be used to resolve which overload is selected.

      2. - -
      3. If V is undefined, and there is an entry in S - whose list of optionality values has “optional” at index i, - then remove from S all other entries.
      4. - -
      5. Otherwise: if V is null or undefined, - and there is an entry in S that has one of the following types at position i of its type list, - - then remove from S all other entries. -
      6. - -
      7. - Otherwise: if V is a platform object, and - there is an entry in S that has one of the following types at position i of its type list, - - then remove from S all other entries. -
      8. - -
      9. - Otherwise: if V is a RegExp object and - there is an entry in S that has one of the following types at position i of its type list, - - then remove from S all other entries. -
      10. - -
      11. - Otherwise: if V is a DOMException platform object and - there is an entry in S that has one of the following types at position i of its type list, - - then remove from S all other entries. -
      12. - -
      13. - Otherwise: if V is an Error object (that is, it has an [[ErrorData]] internal slot) and - there is an entry in S that has one of the following types at position i of its type list, - - then remove from S all other entries. -
      14. - -
      15. - Otherwise: if V is an object with an [[ArrayBufferData]] internal slot and - there is an entry in S that has one of the following types at position i of its type list, - - then remove from S all other entries. -
      16. - -
      17. - Otherwise: if V is an object with a [[DataView]] internal slot and - there is an entry in S that has one of the following types at position i of its type list, - - then remove from S all other entries. -
      18. - -
      19. - Otherwise: if V is an object with a [[TypedArrayName]] internal slot and - there is an entry in S that has one of the following types at position i of its type list, - - then remove from S all other entries. -
      20. - -
      21. - Otherwise: if IsCallable(V) is true, - and there is an entry in S that has one of the following types at position i of its type list, - - then remove from S all other entries. -
      22. - -
      23. - Otherwise: if V is any kind of object except for - a native RegExp object, and - there is an entry in S that has one of the - following types at position i of its type list, - - and after performing the following steps, -
          -
        1. - Let method be the result of - GetMethod(V, @@iterator). -
        2. -
        3. - ReturnIfAbrupt(method). -
        4. -
        - method is not undefined, then remove from S all - other entries. -
      24. - -
      25. - Otherwise: if V is any kind of object except for - a native RegExp object, and - there is an entry in S that has one of the following types at position i of its type list, - - then remove from S all other entries. -
      26. - -
      27. - Otherwise: if V is a Boolean value, - and there is an entry in S that has one of the following types at position i of its type list, - - then remove from S all other entries. -
      28. - -
      29. - Otherwise: if V is a Number value, - and there is an entry in S that has one of the following types at position i of its type list, - - then remove from S all other entries. -
      30. - -
      31. - Otherwise: if there is an entry in S that has one of the following types at position i of its type list, - - then remove from S all other entries. -
      32. - -
      33. - Otherwise: if there is an entry in S that has one of the following types at position i of its type list, - - then remove from S all other entries. -
      34. - -
      35. - Otherwise: if there is an entry in S that has one of the following types at position i of its type list, - - then remove from S all other entries. -
      36. - -
      37. - Otherwise: if there is an entry in S that has any at position i - of its type list, - then remove from S all other entries. -
      38. - -
      39. - Otherwise: - throw a TypeError. -
      40. -
      -
    22. - -
    23. Let callable be the operation or extended attribute - of the single entry in S.
    24. - -
    25. - If i = d and method is not undefined, then -
        -
      1. - Let V be argi. -
      2. -
      3. - Let T be the type at index i in the - type list of the remaining entry in S. -
      4. -
      5. - If T is a sequence type, then - append to values the result of - creating a sequence - of type T from - V and method. -
      6. -
      7. - Otherwise, T is a frozen array type. - Append to values the result of - creating a frozen array - of type T from - V and method. -
      8. -
      9. - Set i to i + 1. -
      10. -
      -
    26. - -
    27. - While i < argcount: -
        -
      1. Let V be argi.
      2. -
      3. Let type be the type at index i in the type list of the remaining entry in S.
      4. -
      5. Let optionality be the value at index i in the list of optionality values of the remaining entry in S.
      6. -
      7. If optionality is “optional” and V is undefined, then: -
          -
        1. If the argument at index i is declared with a default value, - then append to values that default value.
        2. -
        3. Otherwise, append to values the special value “missing”.
        4. -
        -
      8. -
      9. Otherwise, append to values the result of - converting V to IDL type type.
      10. -
      11. Set i to i + 1.
      12. -
      -
    28. - -
    29. While i is less than the number of arguments callable is declared to take: -
        -
      1. If callable’s argument at index i is declared with a default value, - then append to values that default value.
      2. -
      3. Otherwise, if callable’s argument at index i is not variadic, then append to values the special value “missing”.
      4. -
      5. Set i to i + 1.
      6. -
      -
    30. - -
    31. Return the pair <callable, values>.
    32. -
    -
    Note
    -

    - The overload resolution algorithm performs both the identification - of which overloaded operation, constructor, etc. is being called, - and the conversion of the ECMAScript argument values to their - corresponding IDL values. Informally, it operates as follows. -

    -

    First, the selection of valid overloads is done by considering - the number of ECMAScript arguments that were passed in to the function:

    -
      -
    • If there are more arguments passed in than the longest - overload argument list, then they are ignored.
    • -
    • After ignoring these trailing arguments, only overloads - that can take this exact number of arguments are considered. - If there are none, then a TypeError is thrown.
    • -
    -

    Once we have a set of possible overloads with the right number - of arguments, the ECMAScript values are converted from left to right. - The nature of the restrictions on overloading means that if we - have multiple possible overloads at this point, then there will - be one position in the argument list that will be used to - distinguish which overload we will finally select; this is - the distinguishing - argument index.

    -

    We first convert the arguments to the left of the distinguishing - argument. (There is a requirement that an argument to the left of - the distinguishing argument index has the same type as in the other - overloads, at the same index.) Then we inspect the type of the - ECMAScript value that is passed in at the distinguishing argument - index to determine which IDL type it may correspond to. - This allows us to select the final overload that will - be invoked. If the value passed in is undefined - and there is an overload with an optional argument at this position, then - we will choose that overload. If there is no valid overload for the type of - value passed in here, then we throw a TypeError. - The inspection of the value at the distinguishing argument index does not have any side effects; - the only side effects that come from running the overload resolution - algorithm are those that come from converting the ECMAScript values - to IDL values.

    -

    At this point, we have determined which overload to use. We now - convert the remaining arguments, from the distinguishing argument onwards, - again ignoring any additional arguments that were ignored due to being passed - after the last possible argument.

    -

    When converting an optional argument’s ECMAScript value to its equivalent IDL value, - undefined will be converted into - the optional argument’s default value, - if it has one, or a special value “missing” otherwise.

    -

    Optional arguments corresponding to a final, variadic argument do not treat - undefined as a special “missing” value, however. - The undefined value is converted to the type - of variadic argument as would be done for a non-optional argument.

    -
    -
    - -
    -

    4.6. Interfaces

    - -

    - For every interface that - is exposed in a given - ECMAScript global environment and: -

    - -

    - a corresponding property MUST exist on the - ECMAScript environment's global object. - The name of the property is the identifier of the interface, - and its value is an object called the interface object. -

    -

    - The property has the attributes { [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true }. - The characteristics of an interface object are described in section 4.6.1 - below. -

    - -

    - In addition, for every [NamedConstructor] - extended attribute on an exposed interface, a corresponding property MUST - exist on the ECMAScript global object. The name of the property is the - identifier that occurs directly after the - “=”, and its value is an object called a - named constructor, which allows - construction of objects that implement the interface. The property has the - attributes { [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true }. - The characteristics of a named constructor are described in - section 4.6.2 - below. -

    - -
    -

    4.6.1. Interface object

    - -

    - The interface object for a given non-callback interface - is a function object. - It has properties that correspond to - the constants and - static operations - defined on that interface, as described in sections - 4.6.5 and - 4.6.7 - below. -

    -

    - The [[Prototype]] internal property of - an interface object for a non-callback interface is determined as - follows: -

    -
      -
    1. - If the interface inherits from some other interface, the value - of [[Prototype]] is the interface - object for that other interface. -
    2. -
    3. - If the interface doesn't inherit from any other interface, - the value of [[Prototype]] is - %FunctionPrototype%. -
    4. -
    -

    - An interface object for a non-callback interface MUST have a property named “prototype” - with attributes - { [[Writable]]: false, [[Enumerable]]: false, [[Configurable]]: false } - whose value is an object called the interface prototype object. This object has properties - that correspond to the regular attributes and - regular operations defined on the interface, - and is described in more detail in - section 4.6.3 - below. -

    -
    Note
    -

    Since an interface object for a non-callback interface is a function object the typeof operator will return - "function" when applied to - such an interface object.

    -
    -

    - The internal [[Prototype]] property - of an interface object for a callback interface MUST be - the Object.prototype object. -

    -
    Note
    -

    Remember that interface objects for callback interfaces only exist if they have - constants declared on them; - when they do exist, they are not function objects.

    -
    - -
    -
    4.6.1.1. Interface object [[Call]] method
    - -

    - If the interface is declared with a - [Constructor] extended attribute, - then the interface object - can be called as a function to create an object that implements that - interface. Interfaces that do not have a constructor will throw - an exception when called as a function. -

    - - -

    - The internal [[Call]] method - of the interface object behaves as follows, assuming - arg0..n−1 is the list - of argument values passed to the constructor, and I - is the interface: -

    -
      -
    1. - If I was not declared with a [Constructor] - extended attribute, then - throw a TypeError. -
    2. -
    3. - Let id be the identifier of interface I. -
    4. -
    5. - Initialize S to the - effective overload set - for constructors with identifier - id on interface - I and with argument count n. -
    6. -
    7. - Let <constructor, values> be the result of passing S and - arg0..n−1 to the - overload resolution algorithm. -
    8. -
    9. - Let R be the result of performing the actions listed in the description of - constructor with values as the argument values. -
    10. -
    11. - Return the result of converting - R to an ECMAScript interface type value - I. -
    12. -
    -

    - If the internal [[Call]] method - of the interface object - returns normally, then it MUST - return an object that implements interface I. - This object also MUST be - associated with the ECMAScript global environment associated - with the interface object. -

    -

    - Interface objects for non-callback interfaces MUST have a property named “length” - with attributes { [[Writable]]: false, [[Enumerable]]: false, [[Configurable]]: true } - whose value is a Number. - If the [Constructor] - extended attribute - does not appear on the interface definition, then the value is 0. - Otherwise, the value is determined as follows: -

    -
      -
    1. - Let id be the identifier of interface I. -
    2. -
    3. - Initialize S to the - effective overload set - for constructors with - identifier - id on interface - I and with argument count 0. -
    4. -
    5. - Return the length of the shortest argument list of the entries in S. -
    6. -
    -

    - All interface objects MUST have a - property named “name” with attributes { [[Writable]]: false, [[Enumerable]]: false, [[Configurable]]: true } - whose value is the identifier of the corresponding interface. -

    -
    - -
    -
    4.6.1.2. Interface object [[HasInstance]] method
    - -

    - The internal [[HasInstance]] method of every - interface object - A MUST behave as follows, - assuming V is the object - argument passed to [[HasInstance]]: -

    -
      -
    1. If V is not an object, return false.
    2. -
    3. Let O be the result of calling the [[Get]] method of A with property name “prototype”.
    4. -
    5. If O is not an object, throw a TypeError exception.
    6. -
    7. If V is a platform object that implements the - interface for which O is the interface prototype object, - return true.
    8. -
    9. Repeat: -
        -
      1. Set V to the value of the [[Prototype]] internal property of V.
      2. -
      3. If V is null, return false.
      4. -
      5. If O and V refer to the same object, - return true.
      6. -
      -
    10. -
    -
    -
    - -
    -

    4.6.2. Named constructors

    - -

    - A named constructor - that exists due to one or more - [NamedConstructor] - extended attributes - with a given identifier - is a function object. - It MUST have a [[Call]] - internal property, which allows construction of objects that - implement the interface on which the - [NamedConstructor] - extended attributes appear. It behaves as follows, assuming - arg0..n−1 is the list - of argument values passed to the constructor, id - is the identifier of the constructor specified in the - extended attribute named argument list, - and I is the interface - on which the [NamedConstructor] - extended attribute appears: -

    -
      -
    1. - Initialize S to the - effective overload set - for constructors with identifier - id on interface - I and with argument count n. -
    2. -
    3. - Let <constructor, values> be the result of passing S and - arg0..n−1 to the - overload resolution algorithm. -
    4. -
    5. - Let R be the result of performing the actions listed in the description of - constructor with values as the argument values. -
    6. -
    7. - Return the result of converting - R to an ECMAScript - interface type value - I. -
    8. -
    -

    - If the internal [[Call]] method - of the named constructor - returns normally, then it MUST - return an object that implements interface I. - This object also MUST be - associated with the ECMAScript global environment associated - with the named constructor. -

    -

    - A named constructor MUST have a property named “length” - with attributes { [[Writable]]: false, [[Enumerable]]: false, [[Configurable]]: true } - whose value is a Number determined as follows: -

    -
      -
    1. - Initialize S to the - effective overload set - for constructors with - identifier - id on interface - I and with argument count 0. -
    2. -
    3. - Return the length of the shortest argument list of the entries in S. -
    4. -
    -

    - A named constructor MUST have a property named “name” - with attributes { [[Writable]]: false, [[Enumerable]]: false, [[Configurable]]: true } - whose value is the identifier used for the named constructor. -

    -

    - A named constructor MUST also have a property named - “prototype” with attributes - { [[Writable]]: false, [[Enumerable]]: false, [[Configurable]]: false } - whose value is the interface prototype object - for the interface on which the - [NamedConstructor] - extended attribute - appears. -

    -
    - -
    -

    4.6.3. Interface prototype object

    - -

    - There MUST exist an - interface prototype - object for every non-callback interface - defined, regardless of whether the interface was declared with the - [NoInterfaceObject] - extended attribute. - The interface prototype object for a particular interface has - properties that correspond to the regular attributes - and regular operations - defined on that interface. These properties are described in more detail in - sections 4.6.6 and - 4.6.7 below. -

    -

    - As with the interface object, - the interface prototype object also has properties that correspond to the - constants defined on that - interface, described in section - 4.6.5 below. -

    -

    - If the [NoInterfaceObject] - extended attribute was not specified on the interface, then - the interface prototype object MUST - also have a property named “constructor” with attributes - { [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true } whose value - is a reference to the interface object for the interface. -

    - -

    - The interface prototype object - for a given interface A MUST have an internal - [[Prototype]] property whose value is returned from - the following steps: -

    -
      -
    1. If A is declared with the [Global] - or [PrimaryGlobal] - extended attribute, and A - supports named properties, then - return the named properties object - for A, as defined in section 4.6.4 - below.
    2. -
    3. Otherwise, if A is declared to inherit from another - interface, then return the - interface prototype object - for the inherited interface.
    4. -
    5. Otherwise, if A is declared with the [LegacyArrayClass] - extended attribute, then return %ArrayPrototype% ([ECMA-262], section 6.1.7.4).
    6. -
    7. Otherwise, return %ObjectPrototype%. - ([ECMA-262], section 15.2.4).
    8. -
    -
    Note
    -

    - The interface prototype object - of an interface that is defined with - the [NoInterfaceObject] - extended attribute - will be accessible if the interface is used as a - non-supplemental interface. - For example, with the following IDL: -

    -
    IDL
    [NoInterfaceObject]
    -interface Foo {
    +
    +
    + +

    The following two interfaces are equivalent:

    +
    interface A {
    +  stringifier DOMString ();
     };
    -
    -partial interface Window {
    -  attribute Foo foo;
    -};
    -

    - it is not possible to access the interface prototype object through - the interface object - (since it does not exist as window.Foo). However, an instance - of Foo can expose the interface prototype - object by gettings its internal [[Prototype]] - property value – Object.getPrototypeOf(window.foo) in - this example. -

    -

    - If the interface is used solely as a - supplemental interface, - then there will be no way to access its interface prototype object, since no - object will have the interface prototype object as its internal - [[Prototype]] property value. In such cases, - it is an acceptable optimization for this object not to exist. -

    -
    - -

    - If the interface or any of its consequential interfaces - has any interface member declared with - the [Unscopable] extended attribute, - then there MUST be a property on the - interface prototype object whose name is the @@unscopables symbol - and whose value is an object created as follows: -

    -
      -
    1. Let object be a new object created as if by the expression ({}).
    2. -
    3. For each of the aforementioned interface members - declared with the [Unscopable] extended attribute, - call CreateDataProperty(object, - the identifier of the - interface member, true).
    4. -
    5. Return object.
    6. -
    - -

    - If the interface is declared with the [Global] or - [PrimaryGlobal] extended attribute, or the interface is in the set - of inherited interfaces for any - other interface that is declared with one of these attributes, then the interface prototype object - must be an immutable prototype exotic object. -

    - -

    - The class string of an - interface prototype object - is the concatenation of the interface’s - identifier and the string - “Prototype”. -

    -
    - -
    -

    4.6.4. Named properties object

    - -

    - For every interface declared with the - [Global] or - [PrimaryGlobal] - extended attribute - that supports named properties, - there MUST exist an object known as the - named properties object for that - interface. -

    -

    - The named properties object - for a given interface A MUST have an internal - [[Prototype]] property whose value is returned from - the following steps: -

    -
      -
    1. If A is declared to inherit from another interface, then return the - interface prototype object - for the inherited interface.
    2. -
    3. Otherwise, if A is declared with the [LegacyArrayClass] - extended attribute, then return %ArrayPrototype% ([ECMA-262], section 6.1.7.4).
    4. -
    5. Otherwise, return %ObjectPrototype%.
    6. -
    -

    - The class string of a - named properties object - is the concatenation of the interface’s - identifier and the string - “Properties”. -

    - -
    -
    4.6.4.1. Named properties object [[GetOwnProperty]] method
    - -

    - When the [[GetOwnProperty]] internal method of a named properties object - O is called with property key P, the following steps are - taken: -

    - -
      -
    1. Let A be the interface for the - named properties object O.
    2. -
    3. Let object be the sole object from O’s ECMAScript global environment that implements A. -
      Note
      -

      For example, if the interface is the Window - interface as defined in HTML5 ([HTML5], section 5.2), then the sole object - will be this global environment’s window object.

      -
      -
    4. -
    5. If the result of running the named property visibility algorithm with - property name P and object object is true, then: -
        -
      1. Let operation be the operation used to declare the named property getter.
      2. - -
      3. Let value be an uninitialized variable.
      4. -
      5. If operation was defined without an identifier, then - set value to the result of performing the steps listed in the interface description to - determine the value of a named property - with P as the name.
      6. -
      7. Otherwise, operation was defined with an identifier. Set value to the result - of performing the steps listed in the description of operation with P as the only argument value.
      8. - -
      9. Let desc be a newly created Property Descriptor ([ECMA-262], section 6.2.4) with no fields.
      10. -
      11. Set desc.[[Value]] to the result of converting - value to an ECMAScript value.
      12. -
      13. If A implements an interface with the - [LegacyUnenumerableNamedProperties] - extended attribute, - then set desc.[[Enumerable]] to false, - otherwise set it to true.
      14. -
      15. Set desc.[[Writable]] to true and - desc.[[Configurable]] to true.
      16. -
      17. Return desc.
      18. -
      -
    6. - -
    7. Return OrdinaryGetOwnProperty(O, P).
    8. -
    -
    - -
    -
    4.6.4.2. Named properties object [[DefineOwnProperty]] method
    - -

    - When the [[DefineOwnProperty]] internal method of a named properties object is - called, the following steps are taken: -

    - -
      -
    1. Return false.
    2. -
    -
    - -
    -
    4.6.4.3. Named properties object [[Delete]] method
    - -

    - When the [[Delete]] internal method of a named properties object is called, the - following steps are taken: -

    - -
      -
    1. Return false.
    2. -
    -
    - -
    -
    4.6.4.4. Named properties object [[SetPrototypeOf]] method
    - -

    - When the [[SetPrototypeOf]] internal method of a named properties object is - called, the same algorithm must be executed as is defined for the [[SetPrototypeOf]] internal method of an - immutable prototype exotic object. -

    -
    -
    - - - -
    -

    4.6.5. Constants

    - -

    - For each exposed - constant defined on - an interface A, there - MUST be a corresponding property. - The property has the following characteristics: -

    -
      -
    • The name of the property is the identifier of the constant.
    • -
    • - The location of the property is determined as follows: - -
    • -
    • The value of the property is that which is obtained by converting the constant’s IDL value to an ECMAScript value.
    • -
    • The property has attributes { [[Writable]]: false, [[Enumerable]]: true, [[Configurable]]: false }.
    • -
    -

    - In addition, a property with the same characteristics MUST - exist on the interface object, if - that object exists. -

    -
    - -
    -

    4.6.6. Attributes

    - -

    - For each exposed - attribute of the - interface, whether it - was declared on the interface itself or one of its - consequential interfaces, - there MUST exist a corresponding property. - The characteristics of this property are as follows: -

    -
      -
    • - The name of the property is the identifier of the attribute. -
    • -
    • - The location of the property is determined as follows: - -
    • -
    • - The property has attributes { [[Get]]: G, [[Set]]: S, [[Enumerable]]: true, [[Configurable]]: configurable }, - where: - -
    • -
    • - The attribute getter is a Function - object whose behavior when invoked is as follows: -
        -
      1. Let idlValue be an IDL value determined as follows.
      2. -
      3. If the attribute is a regular attribute, then: -
          -
        1. Let I be the interface - whose interface prototype object - this property corresponding to the attribute appears on. -
          Note
          -

          This means that even if an implements statement was used to make - an attribute available on the interface, I is the interface - on the left hand side of the implements statement, and not the one - that the attribute was originally declared on.

          -
          -
        2. -
        3. Let O be the this value.
        4. -
        5. If O is a platform object, - then perform a security check, passing: -
            -
          • the platform object O,
          • -
          • the ECMAScript global environment associated with this Function that - implements the attribute getter,
          • -
          • the identifier of the attribute, and
          • -
          • the type “getter”.
          • -
          -
        6. -
        7. If O is not a platform object that implements I, then: -
            -
          1. If the attribute was specified with the - [LenientThis] extended attribute, - then return undefined.
          2. -
          3. Otherwise, throw a TypeError.
          4. -
          -
        8. -
        9. - Set idlValue to be the result of performing the actions listed in the description of the attribute that occur when getting - (or those listed in the description of the inherited attribute, if this attribute is declared to - inherit its getter), - with O as the object. -
        10. -
        -
      4. -
      5. Otherwise, the attribute is a static attribute. - Set idlValue to be the result of performing the actions listed in the description of the attribute that occur when getting.
      6. -
      7. - Let V be the result of converting - idlValue to an ECMAScript value. -
      8. -
      9. - Return V. -
      10. -
      -

      The value of the Function object’s “length” - property is the Number value 0.

      -

      The value of the Function object’s “name” - property is a String whose value is the - concatenation of “get ” and the identifier of the attribute.

      -
    • -
    • - The attribute setter is undefined - if the attribute is declared readonly and does not have a - [LenientThis], [PutForwards] or - [Replaceable] - extended attribute declared on it. - Otherwise, it is a Function object whose behavior when invoked is as follows: -
        -
      1. If no arguments were passed to the Function, then - throw a TypeError.
      2. -
      3. Let V be the value of the first argument passed to the Function.
      4. -
      5. If the attribute is a regular attribute, then: -
          -
        1. Let I be the interface - whose interface prototype object - this property corresponding to the attribute appears on.
        2. -
        3. Let O be the this value.
        4. -
        5. If O is a platform object, - then perform a security check, passing: -
            -
          • the platform object O,
          • -
          • the ECMAScript global environment associated with this Function that - implements the attribute setter,
          • -
          • the identifier of the attribute, and
          • -
          • the type “setter”.
          • -
          -
        6. -
        7. Let validThis be true if O is a - platform object that implements I, or - false otherwise.
        8. -
        9. If validThis is false and the - attribute was not specified with the - [LenientThis] extended attribute, - then throw a TypeError.
        10. -
        11. If the attribute is declared with a [Replaceable] - extended attribute, then: -
            -
          1. Let P be the identifier of the attribute.
          2. -
          3. Call CreateDataProperty(O, P, V).
          4. -
          5. Return undefined.
          6. -
          -
        12. -
        13. If validThis is false, then return undefined.
        14. -
        15. If the attribute is declared with a [LenientSetter] - extended attribute, then return undefined.
        16. -
        17. If the attribute is declared with a [PutForwards] - extended attribute, then: -
            -
          1. Let Q be the result of calling the [[Get]] method - on O using the identifier of the attribute as the property name.
          2. -
          3. If Q is not an object, then throw a TypeError.
          4. -
          5. Let A be the attribute identified by the [PutForwards] extended attribute.
          6. -
          7. Call the [[Put]] method on Q - using the identifier of A as the property name and V as the value.
          8. -
          9. Return undefined.
          10. -
          -
        18. -
        -
      6. -
      7. Let idlValue be an IDL value determined as follows: -
          -
        • If the type of the attribute is an enumeration, then: -
            -
          1. Let S be the result of calling ToString(V).
          2. -
          3. If S is not one of the enumeration’s values, then return undefined.
          4. -
          5. The value of idlValue is the enumeration value equal to S.
          6. -
          -
        • -
        • Otherwise, the type of the attribute is not an enumeration. - The value of idlValue is the result of converting - V to an IDL value.
        • -
      8. -
      9. If the attribute is a regular attribute, then perform the actions listed in the description of the attribute that occur when setting, - with O as the object and idlValue as the value.
      10. -
      11. Otherwise, the attribute is a static attribute. - Perform the actions listed in the description of the attribute that occur when setting with idlValue as the value.
      12. -
      13. Return undefined.
      14. -
      -

      The value of the Function object’s “length” - property is the Number value 1.

      -

      The value of the Function object’s “name” - property is a String whose value is the - concatenation of “set ” and the identifier of the attribute.

      -
    • -
    -
    Note
    -

    - Although there is only a single property for an IDL attribute, since - accessor property getters and setters are passed a this - value for the object on which property corresponding to the IDL attribute is - accessed, they are able to expose instance-specific data. -

    -
    -
    Note
    -

    - Note that attempting to assign to a property corresponding to a - read only attribute - results in different behavior depending on whether the script doing so is in strict mode. - When in strict mode, such an assignment will result in a TypeError - being thrown. When not in strict mode, the assignment attempt will be ignored. -

    -
    -
    - -
    -

    4.6.7. Operations

    - -

    - For each unique identifier - of an exposed operation - defined on the interface, there - MUST exist a corresponding property, - unless the effective overload set - for that identifier and operation - and with an argument count of 0 has no entries. -

    -

    - The characteristics of this property are as follows: -

    -
      -
    • The name of the property is the identifier.
    • -
    • - The location of the property is determined as follows: - -
    • -
    • - The property has attributes - { [[Writable]]: B, [[Enumerable]]: true, [[Configurable]]: B }, - where B is false if the operation is - unforgeable on the interface, - and true otherwise. -
    • -
    • - The value of the property is a Function object whose - behavior is as follows, - assuming id is the - identifier, - arg0..n−1 is the list - of argument values passed to the function: -
        -
      1. - Try running the following steps: -
          -
        1. - Let I be the interface - whose interface prototype object - (or interface object, for a static - operation) this property corresponding to the operation appears on. -
          Note
          -

          This means that even if an implements statement was used to make - an operation available on the interface, I is the interface - on the left hand side of the implements statement, and not the one - that the operation was originally declared on.

          -
          -
        2. -
        3. - Let O be a value determined as follows: -
            -
          • - If the operation is a static operation, then O is null. -
          • -
          • - Otherwise, if the interface on which the - operation appears has an - [ImplicitThis] extended attribute, - and the this value is null - or undefined, then O is - the ECMAScript global object associated with the Function object. -
          • -
          • - Otherwise, if the this value is not null, - then O is the this value. -
          • -
          • - Otherwise, throw a TypeError. -
          • -
          -
        4. -
        5. If O is a platform object, - then perform a security check, passing: -
            -
          • the platform object O,
          • -
          • the ECMAScript global environment associated with this Function that - implements the operation,
          • -
          • the identifier of the operation, and
          • -
          • the type “method”.
          • -
          -
        6. -
        7. - If O is not null and is also not a platform object - that implements interface I, throw a TypeError. -
        8. -
        9. - Initialize S to the - effective overload set - for regular operations - (if the operation is a regular operation) or for - static operations - (if the operation is a static operation) with - identifier - id on interface - I and with argument count n. -
        10. -
        11. - Let <operation, values> be the result of passing S and - arg0..n−1 to the - overload resolution algorithm. -
        12. -
        13. - Let R be the result of performing (on O, if the operation - is not a static operation) the actions listed in the description of - operation with values as the argument values. -
        14. -
        15. - Return the result of converting - R to an ECMAScript value of - the type op is declared to return. -
        16. -
        - And then, if an exception was thrown: -
          -
        1. If the operation has a return type - that is a promise type, then: -
            -
          1. Let reject be the initial value of %Promise%.reject.
          2. -
          3. Return the result of calling reject with %Promise% as the - this object and the exception as the single - argument value.
          4. -
          -
        2. -
        3. Otherwise, end these steps and allow the exception to propagate.
        4. -
        -
      2. -
      -
    • -
    • - The value of the Function object’s “length” - property is a Number determined as follows: -
        -
      1. - Let S be the - effective overload set - for regular operations - (if the operation is a regular operation) or for - static operations - (if the operation is a static operation) with - identifier - id on interface - I and with argument count 0. -
      2. -
      3. - Return the length of the shortest argument list of the entries in S. -
      4. -
      -
    • -
    • The value of the Function object’s “name” - property is a String whose value is the - identifier of the operation.
    • -
    - -

    We also define creating an operation - function, given an operation - op, a namespace - namespace, and a Realm realm:

    - -

    The astute reader may notice that what follows is very similar to the - above algorithm for operations on interfaces. It is currently only used for namespaces, - but we have near-future plans to generalize it slightly and then replace the above - definition so that this algorithm is useful both for interfaces and namespaces.

    - -
      -
    1. - Let id be op's identifier. -
    2. - - -
    3. - Let steps be the following series of steps, given function argument - values arg0..n−1: - -
        -
      1. - Try running the following steps: -
          -
        1. - Let S be the effective overload set for regular operations with - identifier id on - namespace namespace - and with argument count n. -
        2. - -
        3. - Let <operation, values> be the result of passing - S and arg0..n−1 to the overload resolution - algorithm. -
        4. - -
        5. - Let R be the result of performing the actions listed in the - description of operation with values as the argument - values. -
        6. - -
        7. - Return the result of converting R to - an ECMAScript value of the type op is declared to return. -
        8. -
        -
      2. -
      - - And then, if an exception was thrown: - -
        -
      1. - If the operation has a return type - that is a promise type, then: - -
          -
        1. - Let reject be the initial value of %Promise%.reject. -
        2. -
        3. - Return the result of calling reject with %Promise% as the this object - and the exception as the single argument value. -
        4. -
        -
      2. -
      3. - Otherwise, end these steps and allow the exception to propagate. -
      4. -
      -
    4. - -
    5. - Let F be ! CreateBuiltinFunction(realm, - steps, the %FunctionPrototype% of realm). -
    6. - -
    7. - Perform ! SetFunctionName(F, id). -
    8. - -
    9. - Let S be the effective overload set for regular operations with identifier id on namespace namespace and with argument count 0. -
    10. - -
    11. - Let length be the length of the shortest argument list in the entries in - S. -
    12. - -
    13. - Perform ! DefinePropertyOrThrow(F, "length", - PropertyDescriptor{[[Value]]: length, - [[Writable]]: false, [[Enumerable]]: false, [[Configurable]]: true}). -
    14. -
    - -
    -
    4.6.7.1. Stringifiers
    - -

    - If the interface - has an exposed - stringifier, then - there MUST exist a property with - the following characteristics: -

    -
      -
    • The name of the property is “toString”.
    • -
    • If the stringifier is - unforgeable on the interface - or if the interface was declared with the [Global] or [PrimaryGlobal] extended attribute, - then the property exists on every object that implements the interface. - Otherwise, the property exists on the interface prototype object.
    • -
    • The property has attributes { [[Writable]]: B, [[Enumerable]]: true, [[Configurable]]: B }, - where B is false if the stringifier is - unforgeable on the interface, - and true otherwise.
    • -
    • -

      The value of the property is a Function object, which behaves as follows:

      -
        -
      1. Let O be the result of calling ToObject on the this value.
      2. -
      3. If O is a platform object, - then perform a security check, passing: -
          -
        • the platform object O,
        • -
        • the ECMAScript global environment associated with this Function that - implements the stringifier,
        • -
        • the identifier of the stringifier, and
        • -
        • the type “method”.
        • -
        -
      4. -
      5. If O is not an object that implements the interface - on which the stringifier was declared, then throw a TypeError.
      6. -
      7. Let V be an uninitialized variable.
      8. -
      9. Depending on where stringifier was specified: -
        -
        on an attribute
        -
        Set V to the result of performing the actions listed in the description of the attribute that occur when getting - (or those listed in the description of the inherited attribute, if this attribute is declared to - inherit its getter), - with O as the object.
        -
        on an operation with an identifier
        -
        Set V to the result of performing the actions listed in the description - of the operation, using O as the this value - and passing no arguments.
        -
        on an operation with no identifier
        -
        Set V to the result of performing the stringification behavior - of the interface.
        -
        -
      10. -
      11. Return the result of converting V to a String value.
      12. -
      -
    • -
    • The value of the Function object’s “length” - property is the Number value 0.
    • -
    • The value of the Function object’s “name” - property is the String value “toString”.
    • -
    -
    - -
    -
    4.6.7.2. Serializers
    - -

    - If the interface - has an exposed - serializer, then - a property MUST exist - whose name is “toJSON”, - with attributes { [[Writable]]: true, [[Enumerable]]: true, [[Configurable]]: true } - and whose value is a - Function object. -

    -

    - The location of the property is determined as follows: -

    - -

    - The property’s Function object, when invoked, - MUST behave as follows: -

    -
      -
    1. Let O be the result of calling ToObject on the this value.
    2. -
    3. If O is a platform object, - then perform a security check, passing: -
        -
      • the platform object O,
      • -
      • the ECMAScript global environment associated with this Function that - implements the serializer,
      • -
      • the identifier of the serializer, and
      • -
      • the type “method”.
      • -
      -
    4. -
    5. If O is not an object that implements the interface - on which the serializer was declared, then throw a TypeError.
    6. -
    7. Depending on how serializer was specified: -
      -
      on an operation with an identifier
      -
      -
        -
      1. Return the result of performing the actions listed in the description of the - operation, using O as the this value - and passing no arguments.
      2. -
      -
      -
      as a keyword, either with or without a serialization pattern
      -
      -
        -
      1. Let S be the serialized value that is the result of invoking the serialization behavior of the - interface for object O.
      2. -
      3. Return the result of converting - S to an ECMAScript value.
      4. -
      -
      -
      -
    8. -
    -

    The value of the Function object’s “length” - property is the Number value 0.

    -

    The value of the Function object’s “name” - property is the String value “toJSON”.

    -

    - The following steps define how to convert a serialized value to an ECMAScript value: -

    -
      -
    1. Let S be the serialized value.
    2. -
    3. Depending on the type of S: -
      -
      a map
      -
      -
        -
      1. Let O be a new object created as if by the expression ({}).
      2. -
      3. For each entry in S, in the order they were added to the map: -
          -
        1. Let V be the result of converting - the value of the entry to an ECMAScript value.
        2. -
        3. Let P be the entry’s key.
        4. -
        5. Call CreateDataProperty(O, P, V).
        6. -
        -
      4. -
      5. Return O.
      6. -
      -
      -
      a list
      -
      -
        -
      1. Let A be a new Array object created as if by the expression [].
      2. -
      3. Let index be 0.
      4. -
      5. While index is less than the number of elements in S: -
          -
        1. Let V be the result of converting - the value of the element in S at index index to an ECMAScript value.
        2. -
        3. Let P be ToString(index).
        4. -
        5. Call CreateDataProperty(O, P, V).
        6. -
        -
      6. -
      7. Return A.
      8. -
      -
      -
      any other serialized value
      -
      -
        -
      1. Let V be the result of converting - S to an ECMAScript value.
      2. -
      3. Return V.
      4. -
      -
      -
      -
    4. -
    -
    -
    - -
    -

    4.6.8. Common iterator behavior

    - -
    -
    4.6.8.1. @@iterator
    - -

    - If the interface - has any of the following: -

    - -

    - then a property MUST exist - whose name is the @@iterator symbol, - with attributes { [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true } - and whose value is a function object. -

    -

    - The location of the property is determined as follows: -

    - -

    - If the interface defines an indexed property getter, - then the Function object is %ArrayProto_values% ([ECMA-262], section 6.1.7.4). -

    -

    - If the interface has a pair iterator, - then the Function, when invoked, - MUST behave as follows: -

    -
      -
    1. Let object be the result of calling ToObject on the this value.
    2. -
    3. If object is a platform object, - then perform a security check, passing: -
        -
      • the platform object object,
      • -
      • the ECMAScript global environment associated with this Function,
      • -
      • the identifier “@@iterator”, and
      • -
      • the type “method”.
      • -
      -
    4. -
    5. Let interface be the interface - the iterable declaration is on.
    6. -
    7. If object is not a platform object - that implements interface, - then throw a TypeError.
    8. -
    9. Let iterator be a newly created default iterator object - for interface with object as its target and iterator kind “key+value”.
    10. -
    11. Return iterator.
    12. -
    -

    - If the interface has a maplike declaration - or setlike declaration, - then the Function object that is the value of the @@iterator property, - when invoked, MUST behave as follows: -

    -
      -
    1. Let object be the result of calling ToObject on the this value.
    2. -
    3. If object is a platform object, - then perform a security check, passing: -
        -
      • the platform object object,
      • -
      • the ECMAScript global environment associated with this Function,
      • -
      • the identifier “@@iterator”, and
      • -
      • the type “method”.
      • -
      -
    4. -
    5. If object is not a platform object - that implements the interface - on which the maplike declaration - or setlike declaration is defined, - then throw a TypeError.
    6. -
    7. If the interface has a maplike declaration, then: -
        -
      1. Let backing be the value of the [[BackingMap]] internal slot of object.
      2. -
      3. Return CreateMapIterator(backing, "key+value").
      4. -
      -
    8. -
    9. Otherwise: -
        -
      1. Let backing be the value of the [[BackingSet]] internal slot of object.
      2. -
      3. Return CreateSetIterator(backing, "value").
      4. -
      -
    10. -
    -

    - The value of the @@iterator Function object’s “length” - property is the Number value 0. -

    -

    The value of the @@iterator Function object’s “name” - property is the String value “entries” if the interface has a - pair iterator or a - maplike - declaration and the String “values” - if the interface has a - setlike declaration.

    -
    - -
    -
    4.6.8.2. forEach
    - -

    - If the interface - has any of the following: -

    - -

    - then a property named “forEach” MUST exist - with attributes { [[Writable]]: true, [[Enumerable]]: true, [[Configurable]]: true } - and whose value is a function object. -

    -

    - The location of the property is determined as follows: -

    - -

    - If the interface defines an indexed property getter, - then the Function object is - the initial value of the “forEach” data property of %ArrayPrototype% ([ECMA-262], section 6.1.7.4). -

    -

    - If the interface has a pair iterator, - then the Function MUST - have the same behavior as one that would exist assuming the interface had - this operation instead of the - iterable declaration: -

    -
    IDL
    void forEach(Function callback, optional any thisArg);
    -

    - with the following prose definition: -

    -
      -
    1. Let O be the this value.
    2. -
    3. Let pairs be the list of value pairs to iterate over.
    4. -
    5. Let i be 0.
    6. -
    7. While i is less than the length of pairs: -
        -
      1. Let pair be the entry in pairs at index i.
      2. -
      3. Let key be pair’s key.
      4. -
      5. Let value be pair’s value.
      6. -
      7. Invoke callback with thisArg - (or undefined, if the argument was not supplied) - as the callback this value and - value, key and O as its arguments.
      8. -
      9. Update pairs to the current list of value pairs to iterate over.
      10. -
      11. Set i to i + 1.
      12. -
      -
    8. -
    -

    - If the interface has a maplike declaration - or setlike declaration - then the Function, when invoked, - MUST behave as follows: -

    -
      -
    1. Let object be the result of calling ToObject on the this value.
    2. -
    3. If object is a platform object, - then perform a security check, passing: -
        -
      • the platform object object,
      • -
      • the ECMAScript global environment associated with this Function,
      • -
      • the identifier “forEach”, and
      • -
      • the type “method”.
      • -
      -
    4. -
    5. Let interface be the interface - on which the maplike declaration - or setlike declaration is declared.
    6. -
    7. If object is not a platform object - that implements interface, - then throw a TypeError.
    8. -
    9. Let callbackFn be the value of the first argument passed to the function, or undefined if the argument was not supplied.
    10. -
    11. If IsCallable(callbackFn) is false, throw a TypeError.
    12. -
    13. Let thisArg be the value of the second argument passed to the function, or undefined if the argument was not supplied.
    14. -
    15. Let backing be the value of the [[BackingMap]] internal slot of object, - if the interface has a maplike declaration, - or the [[BackingSet]] internal slot of object otherwise.
    16. -
    17. Let callbackWrapper be a Function that, when invoked, behaves as follows: -
        -
      1. Let v and k be the first two arguments passed to the function.
      2. -
      3. Let thisArg be the this value.
      4. -
      5. Call the [[Call]] internal method of callbackFn with thisArg as thisArgument - and v, k and object as argumentsList.
      6. -
      -
      Note
      -

      The callbackWrapper function simply calls the incoming callbackFn - with object as the third argument rather than its internal [[BackingMap]] or [[BackingSet]] object.

      -
      -
      Editorial note
      -

      Can the script author observe that callbackWrapper might be a new function - every time forEach is called? What's the best way of specifying that there's only - one function that has captured an environment?

      -
      -
    18. -
    19. Let forEach be the result of calling the [[Get]] internal method of - backing with “forEach” and backing as arguments.
    20. -
    21. If IsCallable(forEach) is false, throw a TypeError.
    22. -
    23. Call the [[Call]] internal method of forEach with backing as thisArgument - and callbackWrapper and thisArg as argumentsList.
    24. -
    25. Return undefined.
    26. -
    -

    - The value of the Function object’s “length” - property is the Number value 1. -

    -

    The value of the Function object’s “name” - property is the String value “forEach”.

    -
    -
    - -
    -

    4.6.9. Iterable declarations

    - -
    -
    4.6.9.1. entries
    - -

    - If the interface has an - iterable declaration, - then a property named “entries” MUST exist - with attributes { [[Writable]]: true, [[Enumerable]]: true, [[Configurable]]: true } - and whose value is a function object. -

    -

    - The location of the property is determined as follows: -

    - -

    - If the interface has a value iterator, - then the Function object is - the initial value of the “entries” data property of %ArrayPrototype% ([ECMA-262], section 6.1.7.4). -

    -

    - If the interface has a pair iterator, - then the Function object is - the value of the @@iterator property. -

    -
    - -
    -
    4.6.9.2. keys
    - -

    - If the interface has an - iterable declaration, - then a property named “keys” MUST exist - with attributes { [[Writable]]: true, [[Enumerable]]: true, [[Configurable]]: true } - and whose value is a function object. -

    -

    - The location of the property is determined as follows: -

    - -

    - If the interface has a value iterator, - then the Function object is - the initial value of the “keys” data property of %ArrayPrototype% ([ECMA-262], section 6.1.7.4). -

    -

    - If the interface has a pair iterator, - then the Function, when invoked, MUST behave as follows: -

    -
      -
    1. Let object be the result of calling ToObject on the this value.
    2. -
    3. If object is a platform object, - then perform a security check, passing: -
        -
      • the platform object object,
      • -
      • the ECMAScript global environment associated with this Function,
      • -
      • the identifier “keys”, and
      • -
      • the type “method”.
      • -
      -
    4. -
    5. Let interface be the interface - on which the iterable declaration is declared on.
    6. -
    7. If object is not a platform object - that implements interface, - then throw a TypeError.
    8. -
    9. Let iterator be a newly created default iterator object - for interface with object as its target and iterator kind “key”.
    10. -
    11. Return iterator.
    12. -
    -

    The value of the Function object’s “length” property is the Number value 0.

    -

    The value of the Function object’s “name” property is the String value “keys”.

    -
    - -
    -
    4.6.9.3. values
    - -

    - If the interface has an - iterable declaration, - then a property named “values” MUST exist - with attributes { [[Writable]]: true, [[Enumerable]]: true, [[Configurable]]: true } - and whose value is a function object. -

    -

    - The location of the property is determined as follows: -

    - - -

    - If the interface has a value iterator, - then the Function object is - the value of the @@iterator property. -

    - -

    - If the interface has a pair iterator, - then the Function, when invoked, MUST behave as follows: -

    -
      -
    1. Let object be the result of calling ToObject on the this value.
    2. -
    3. If object is a platform object, - then perform a security check, passing: -
        -
      • the platform object object,
      • -
      • the ECMAScript global environment associated with this Function,
      • -
      • the identifier “entries”, and
      • -
      • the type “method”.
      • -
      -
    4. -
    5. Let interface be the interface - on which the iterable declaration is declared on.
    6. -
    7. If object is not a platform object - that implements interface, - then throw a TypeError.
    8. -
    9. Let iterator be a newly created default iterator object - for interface with object as its target and iterator kind “value”.
    10. -
    11. Return iterator.
    12. -
    -

    The value of the Function object’s “length” property is the Number value 0.

    -

    The value of the Function object’s “name” property is the String value “values”.

    -
    - -
    -
    4.6.9.4. Default iterator objects
    - -

    - A default iterator object for a given - interface, target and iteration kind - is an object whose internal [[Prototype]] property is the - iterator prototype object - for the interface. -

    -

    - A default iterator object - has three internal values: -

    -
      -
    1. its target, which is an object whose values are to be iterated,
    2. -
    3. its kind, which is the iteration kind,
    4. -
    5. its index, which is the current index into the values value to be iterated.
    6. -
    -
    Note
    -

    - Default iterator objects are only used for pair iterators; - value iterators, as they are currently - restricted to iterating over an object’s - supported indexed properties, - use standard ECMAScript Array iterator objects. -

    -
    -

    - When a default iterator object is first created, - its index is set to 0. -

    -

    - The class string of a - default iterator object - for a given interface - is the result of concatenting the identifier - of the interface and - the string “ Iterator”. -

    -
    - -
    -
    4.6.9.5. Iterator prototype object
    - -

    - The iterator prototype object - for a given interface - is an object that exists for every interface that has a - pair iterator. It serves as the - prototype for default iterator objects - for the interface. -

    -

    - The internal [[Prototype]] property of an iterator prototype object - MUST be %IteratorPrototype% ([ECMA-262], section 6.1.7.4). -

    -

    - An iterator prototype object - MUST have a property named “next” with - attributes { [[Writable]]: true, [[Enumerable]]: true, [[Configurable]]: true } - and whose value is a function object - that behaves as follows: -

    -
      -
    1. Let interface be the interface for which the - iterator prototype object exists.
    2. -
    3. Let object be the result of calling ToObject on the this value.
    4. -
    5. If object is a platform object, - then perform a security check, passing: -
        -
      • the platform object object,
      • -
      • the ECMAScript global environment associated with this Function,
      • -
      • the identifier “next”, and
      • -
      • the type “method”.
      • -
      -
    6. -
    7. If object is not a default iterator object for interface, - then throw a TypeError.
    8. -
    9. Let target be object’s target.
    10. -
    11. Let index be object’s index.
    12. -
    13. Let kind be object’s kind.
    14. -
    15. Let values be the list of value pairs to iterate over.
    16. -
    17. Let len be the length of values.
    18. -
    19. If object’s index is greater than or equal to len, then - return CreateIterResultObject(undefined, true).
    20. -
    21. Let pair be the entry in values at index index.
    22. -
    23. Let result be a value determined by the value of kind: -
      -
      key
      -
      -
        -
      1. Let idlKey be pair’s key.
      2. -
      3. Let key be the result of converting idlKey to an ECMAScript value.
      4. -
      5. result is key.
      6. -
      -
      -
      value
      -
      -
        -
      1. Let idlValue be pair’s value.
      2. -
      3. Let value be the result of converting idlValue to an ECMAScript value.
      4. -
      5. result is value.
      6. -
      -
      -
      key+value
      -
      -
        -
      1. Let idlKey be pair’s key.
      2. -
      3. Let idlValue be pair’s value.
      4. -
      5. Let key be the result of converting idlKey to an ECMAScript value.
      6. -
      7. Let value be the result of converting idlValue to an ECMAScript value.
      8. -
      9. Let array be the result of performing ArrayCreate(2).
      10. -
      11. Call CreateDataProperty(array, "0", key).
      12. -
      13. Call CreateDataProperty(array, "1", value).
      14. -
      15. result is array.
      16. -
      -
      -
      -
    24. -
    25. Return CreateIterResultObject(result, false).
    26. -
    -

    - The class string of an - iterator prototype object - for a given interface - is the result of concatenting the identifier - of the interface and - the string “Iterator”. -

    -
    -
    - -
    -

    4.6.10. Maplike declarations

    - -

    - Any object that implements an interface - that has a maplike declaration - MUST have a [[BackingMap]] internal slot, which is - initially set to a newly created Map object. - This Map object’s [[MapData]] internal slot is - the object’s map entries. -

    - -

    - If an interface A is declared with - a maplike declaration, then - there exists a number of additional properties on A’s - interface prototype object. - These additional properties are described in the sub-sections below. -

    - -

    - Some of the properties below are defined to have a function object value - that forwards to the internal map object - for a given function name. Such functions behave as follows when invoked: -

    -
      -
    1. Let O be the this value.
    2. -
    3. Let arguments be the list of arguments passed to this function.
    4. -
    5. Let name be the function name.
    6. -
    7. If O is a platform object, - then perform a security check, passing: -
        -
      • the platform object O,
      • -
      • the ECMAScript global environment associated with this Function,
      • -
      • an identifier equal to name, and
      • -
      • the type “method”.
      • -
      -
    8. -
    9. If O is not an object that implements A, then throw a TypeError.
    10. -
    11. Let map be the Map object that is the value of O’s [[BackingMap]] internal slot.
    12. -
    13. Let function be the result of calling the [[Get]] internal method of map passing name and map as arguments.
    14. -
    15. If IsCallable(function) is false, then throw a TypeError.
    16. -
    17. Return the result of calling the [[Call]] internal method of function with map as thisArg and arguments as argumentsList.
    18. -
    - -
    -
    4.6.10.1. size
    - -

    - There MUST exist a property named “size” on - A’s interface prototype object - with the following characteristics: -

    -
      -
    • The property has attributes { [[Get]]: G, [[Enumerable]]: false, [[Configurable]]: true }, - where G is the interface’s map size getter, - defined below.
    • -
    • The map size getter is - a Function object whose - behavior when invoked is as follows:

      -
        -
      1. Let O be the this value.
      2. -
      3. If O is a platform object, - then perform a security check, passing: -
          -
        • the platform object O,
        • -
        • the ECMAScript global environment associated with this Function,
        • -
        • the identifier “size”, and
        • -
        • the type “getter”.
        • -
        -
      4. -
      5. If O is not an object that implements A, then throw a TypeError.
      6. -
      7. Let map be the Map object that is the value of O’s [[BackingMap]] internal slot.
      8. -
      9. Return the result of calling the [[Get]] internal method of map passing “size” and map as arguments.
      10. -
      -

      The value of the Function object’s “length” property is the Number value 0.

      -

      The value of the Function object’s “name” property is the String value “size”.

      -
    • -
    -
    - -
    -
    4.6.10.2. entries
    - -

    - A property named “entries” MUST exist on - A’s interface prototype object - with attributes { [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true } - and whose value is the function object that is the value of - the @@iterator property. -

    -
    - -
    -
    4.6.10.3. keys and values
    - -

    - For both of “keys” and “values”, there MUST exist a property with that name on - A’s interface prototype object - with the following characteristics: -

    - -

    The value of the Function objects’ “length” properties is the Number value 0.

    -

    The value of the Function object’s “name” property is the String value “keys” or “values”, correspondingly.

    -
    - -
    -
    4.6.10.4. get and has
    - -

    - For both of “get” and “has”, there MUST exist a property with that name on - A’s interface prototype object - with the following characteristics: -

    -
      -
    • The property has attributes { [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true }.
    • -
    • The value of the property is a Function object that behaves as follows when invoked: -
        -
      1. Let O be the this value.
      2. -
      3. Let name be the name of the property – “get” or “has”.
      4. -
      5. If O is a platform object, - then perform a security check, passing: -
          -
        • the platform object O,
        • -
        • the ECMAScript global environment associated with this Function,
        • -
        • an identifier equal to name, and
        • -
        • the type “method”.
        • -
        -
      6. -
      7. If O is not an object that implements A, then throw a TypeError.
      8. -
      9. Let map be the Map object that is the value of O’s [[BackingMap]] internal slot.
      10. -
      11. Let keyType be the key type specified in the maplike declaration.
      12. -
      13. Let function be the result of calling the [[Get]] internal method of map passing name and map as arguments.
      14. -
      15. Let keyArg be the first argument passed to this function, or undefined if not supplied.
      16. -
      17. Let keyIDL be the result of converting keyArg to an IDL value of type keyType.
      18. -
      19. Let key be the result of converting keyIDL to an ECMAScript value.
      20. -
      21. Return the result of calling the [[Call]] internal method of function with map as thisArg and the single value key as argumentsList.
      22. -
      -
    • -
    -

    The value of the Function objects’ “length” properties is the Number value 1.

    -

    The value of the Function object’s “name” property is the String value “get” or “has”, correspondingly.

    -
    - -
    -
    4.6.10.5. clear
    - -

    - If A and A’s - consequential interfaces - do not declare an interface member - with identifier “clear”, and - A was declared with a read–write maplike declaration, - then a property named “clear” and the following characteristics - MUST exist on A’s - interface prototype object: -

    - -

    The value of the Function object’s “length” property is the Number value 0.

    -

    The value of the Function object’s “name” property is the String value “clear”.

    -
    - -
    -
    4.6.10.6. delete
    - -

    - If A and A’s - consequential interfaces - do not declare an interface member - with identifier “delete”, and - A was declared with a read–write maplike declaration, - then a property named “delete” and the following characteristics - MUST exist on A’s - interface prototype object: -

    -
      -
    • The property has attributes { [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true }.
    • -
    • The value of the property is a Function object that behaves as follows when invoked: -
        -
      1. Let O be the this value.
      2. -
      3. If O is a platform object, - then perform a security check, passing: -
          -
        • the platform object O,
        • -
        • the ECMAScript global environment associated with this Function,
        • -
        • the identifier “delete”, and
        • -
        • the type “method”.
        • -
        -
      4. -
      5. If O is not an object that implements A, then throw a TypeError.
      6. -
      7. Let map be the Map object that is the value of O’s [[BackingMap]] internal slot.
      8. -
      9. Let keyType be the key type specified in the maplike declaration.
      10. -
      11. Let function be the result of calling the [[Get]] internal method of map passing “delete” and map as arguments.
      12. -
      13. Let keyArg be the first argument passed to this function, or undefined if not supplied.
      14. -
      15. Let keyIDL be the result of converting keyArg to an IDL value of type keyType.
      16. -
      17. Let key be the result of converting keyIDL to an ECMAScript value.
      18. -
      19. Return the result of calling the [[Call]] internal method of function with map as thisArg and the single value key as argumentsList.
      20. -
      -
    • -
    -

    The value of the Function object’s “length” property is the Number value 1.

    -

    The value of the Function object’s “name” property is the String value “delete”.

    -
    - -
    -
    4.6.10.7. set
    - -

    - If A and A’s - consequential interfaces - do not declare an interface member - with identifier “set”, and - A was declared with a read–write maplike declaration, - then a property named “set” and the following characteristics - MUST exist on A’s - interface prototype object: -

    -
      -
    • The property has attributes { [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true }.
    • -
    • The value of the property is a Function object that behaves as follows when invoked: -
        -
      1. Let O be the this value.
      2. -
      3. If O is a platform object, - then perform a security check, passing: -
          -
        • the platform object O,
        • -
        • the ECMAScript global environment associated with this Function,
        • -
        • the identifier “set”, and
        • -
        • the type “method”.
        • -
        -
      4. -
      5. If O is not an object that implements A, then throw a TypeError.
      6. -
      7. Let map be the Map object that is the value of O’s [[BackingMap]] internal slot.
      8. -
      9. Let keyType and valueType be the key and value types specified in the maplike declaration.
      10. -
      11. Let function be the result of calling the [[Get]] internal method of map passing “set” and map as arguments.
      12. -
      13. Let keyArg be the first argument passed to this function, or undefined if not supplied.
      14. -
      15. Let valueArg be the second argument passed to this function, or undefined if not supplied.
      16. -
      17. Let keyIDL be the result of converting keyArg to an IDL value of type keyType.
      18. -
      19. Let valueIDL be the result of converting valueArg to an IDL value of type valueType.
      20. -
      21. Let key be the result of converting keyIDL to an ECMAScript value.
      22. -
      23. Let value be the result of converting valueIDL to an ECMAScript value.
      24. -
      25. Let result be the result of calling the [[Call]] internal method of function with map as thisArg and key and value as argumentsList.
      26. -
      27. Assert: result is not an abrupt completion.
      28. -
      29. Return O.
      30. -
      -
    • -
    -

    The value of the Function object’s “length” property is the Number value 2.

    -

    The value of the Function object’s “name” property is the String value “set”.

    -
    -
    - -
    -

    4.6.11. Setlike declarations

    - -

    - Any object that implements an interface - that has a setlike declaration - MUST have a [[BackingSet]] internal slot, which is - initially set to a newly created Set object. - This Set object’s [[SetData]] internal slot is - the object’s set entries. -

    - -

    - If an interface A is declared with - a setlike declaration, then - there exists a number of additional properties on A’s - interface prototype object. - These additional properties are described in the sub-sections below. -

    - -

    - Some of the properties below are defined to have a function object value - that forwards to the internal set object - for a given function name. Such functions behave as follows when invoked: -

    -
      -
    1. Let O be the this value.
    2. -
    3. Let arguments be the list of arguments passed to this function.
    4. -
    5. Let name be the function name.
    6. -
    7. If O is a platform object, - then perform a security check, passing: -
        -
      • the platform object O,
      • -
      • the ECMAScript global environment associated with this Function,
      • -
      • an identifier equal to name, and
      • -
      • the type “method”.
      • -
      -
    8. -
    9. If O is not an object that implements A, then throw a TypeError.
    10. -
    11. Let set be the Set object that is the value of O’s [[BackingSet]] internal slot.
    12. -
    13. Let function be the result of calling the [[Get]] internal method of set passing name and set as arguments.
    14. -
    15. If IsCallable(function) is false, then throw a TypeError.
    16. -
    17. Return the result of calling the [[Call]] internal method of function with set as thisArg and arguments as argumentsList.
    18. -
    - -
    -
    4.6.11.1. size
    - -

    - There MUST exist a property named “size” on - A’s interface prototype object - with the following characteristics: -

    -
      -
    • The property has attributes { [[Get]]: G, [[Enumerable]]: false, [[Configurable]]: true }, - where G is the interface’s set size getter, - defined below.
    • -
    • The set size getter is - a Function object whose - behavior when invoked is as follows:

      -
        -
      1. Let O be the this value.
      2. -
      3. If O is a platform object, - then perform a security check, passing: -
          -
        • the platform object O,
        • -
        • the ECMAScript global environment associated with this Function,
        • -
        • the identifier “size”, and
        • -
        • the type “getter”.
        • -
        -
      4. -
      5. If O is not an object that implements A, then throw a TypeError.
      6. -
      7. Let set be the Set object that is the value of O’s [[BackingSet]] internal slot.
      8. -
      9. Return the result of calling the [[Get]] internal method of set passing “size” and set as arguments.
      10. -
      -

      The value of the Function object’s “length” property is the Number value 0.

      -

      The value of the Function object’s “name” property is the String value “size”.

      -
    • -
    -
    - -
    -
    4.6.11.2. values
    - -

    - A property named “values” MUST exist on - A’s interface prototype object - with attributes { [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true } - and whose value is the function object that is the value of - the @@iterator property. -

    -
    - -
    -
    4.6.11.3. entries and keys
    - -

    - For both of “entries” and “keys”, there MUST exist a property with that name on - A’s interface prototype object - with the following characteristics: -

    - -

    The value of the Function objects’ “length” properties is the Number value 0.

    -

    The value of the Function object’s “name” property is the String value “entries” or “keys”, correspondingly.

    -
    - -
    -
    4.6.11.4. has
    - -

    - There MUST exist a property with named “has” on - A’s interface prototype object - with the following characteristics: -

    -
      -
    • The property has attributes { [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true }.
    • -
    • The value of the property is a Function object that behaves as follows when invoked: -
        -
      1. Let O be the this value.
      2. -
      3. If O is a platform object, - then perform a security check, passing: -
          -
        • the platform object O,
        • -
        • the ECMAScript global environment associated with this Function,
        • -
        • the identifier “has”, and
        • -
        • the type “method”.
        • -
        -
      4. -
      5. If O is not an object that implements A, then throw a TypeError.
      6. -
      7. Let set be the Set object that is the value of O’s [[BackingSet]] internal slot.
      8. -
      9. Let type be the value type specified in the setlike declaration.
      10. -
      11. Let function be the result of calling the [[Get]] internal method of set passing “has” and set as arguments.
      12. -
      13. Let arg be the first argument passed to this function, or undefined if not supplied.
      14. -
      15. Let idlValue be the result of converting arg to an IDL value of type type.
      16. -
      17. Let value be the result of converting idlValue to an ECMAScript value.
      18. -
      19. Return the result of calling the [[Call]] internal method of function with set as thisArg and the single value value as argumentsList.
      20. -
      -
    • -
    -

    The value of the Function object’s “length” property is a Number value 1.

    -

    The value of the Function object’s “name” property is the String value “has”.

    -
    - -
    -
    4.6.11.5. add and delete
    - -

    - For both of “add” and “delete”, if: -

    - -

    - then a property with that name and the following characteristics - MUST exist on A’s - interface prototype object: -

    -
      -
    • The property has attributes { [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true }.
    • -
    • The value of the property is a Function object that behaves as follows when invoked: -
        -
      1. Let O be the this value.
      2. -
      3. Let name be the name of the property – “add” or “delete”.
      4. -
      5. If O is a platform object, - then perform a security check, passing: -
          -
        • the platform object O,
        • -
        • the ECMAScript global environment associated with this Function,
        • -
        • an identifier equal to name, and
        • -
        • the type “method”.
        • -
        -
      6. -
      7. If O is not an object that implements A, then throw a TypeError.
      8. -
      9. Let set be the Set object that is the value of O’s [[BackingSet]] internal slot.
      10. -
      11. Let type be the value type specified in the setlike declaration.
      12. -
      13. Let function be the result of calling the [[Get]] internal method of set passing name and set as arguments.
      14. -
      15. Let arg be the first argument passed to this function, or undefined if not supplied.
      16. -
      17. Let idlValue be the result of converting arg to an IDL value of type type.
      18. -
      19. Let value be the result of converting idlValue to an ECMAScript value.
      20. -
      21. Let result be the result of calling the [[Call]] internal method of function with set as thisArg and the single value value as argumentsList.
      22. -
      23. Assert: result is not an abrupt completion.
      24. -
      25. - If name is "delete", then: -
          -
        1. Return result.
        2. -
        -
      26. -
      27. - Otherwise: -
          -
        1. Return O.
        2. -
        -
      28. -
      -
    • -
    -

    The value of the Function object’s “length” property is the Number value 1.

    -

    The value of the Function object’s “name” property is the String value “add” or “delete”, correspondingly.

    -
    - -
    -
    4.6.11.6. clear
    - -

    - If A and A’s - consequential interfaces - do not declare an interface member - with a matching identifier, and - A was declared with a read–write setlike declaration, - then a property named “clear” and the following characteristics - MUST exist on A’s - interface prototype object: -

    - -

    The value of the Function object’s “length” property is the Number value 0.

    -

    The value of the Function object’s “name” property is the String value “clear”.

    -
    -
    - -
    -

    4.6.12. Initializing objects from iterables

    - -

    - Some objects, which are attempting to emulate map- and set-like interfaces, will want to accept iterables - as constructor parameters and initialize themselves in this way. Here we provide some algorithms that can - be invoked in order to do so in the same way as in the ECMAScript spec, so that those objects behave - the same as the built-in Map and Set objects. -

    - -

    - To add map elements from an iterable iterable to - an object destination with adder method name adder, perform the following steps: -

    -
      -
    1. If Type(destination) is not Object, then, throw a TypeError exception.
    2. -
    3. If iterable is not present, let iterable be undefined.
    4. -
    5. If iterable is either undefined or null, then let iter be undefined.
    6. -
    7. Else, -
        -
      1. Let adder be the result of Get(destination, adder).
      2. -
      3. ReturnIfAbrupt(adder).
      4. -
      5. If IsCallable(adder) is false, throw a TypeError exception.
      6. -
      7. Let iter be the result of GetIterator(iterable).
      8. -
      9. ReturnIfAbrupt(iter).
      10. -
      -
    8. -
    9. If iter is undefined, then return.
    10. -
    11. Repeat -
        -
      1. Let next be the result of IteratorStep(iter).
      2. -
      3. ReturnIfAbrupt(next).
      4. -
      5. If next is false, then return NormalCompletion(destination).
      6. -
      7. Let nextItem be IteratorValue(next).
      8. -
      9. ReturnIfAbrupt(nextItem).
      10. -
      11. If Type(nextItem) is not Object, then throw a TypeError exception.
      12. -
      13. Let k be the result of Get(nextItem, '0').
      14. -
      15. ReturnIfAbrupt(k).
      16. -
      17. Let v be the result of Get(nextItem, '1').
      18. -
      19. ReturnIfAbrupt(v).
      20. -
      21. Let status be the result of calling the [[Call]] internal method of adder with destination as - thisArgument and (k, v) as argumentsList.
      22. -
      23. ReturnIfAbrupt(status).
      24. -
      -
    12. -
    -
    -
    - -
    -

    4.7. Implements statements

    - -

    - The interface prototype object - of an interface A MUST have a copy of - each property that corresponds to one of the - constants, - attributes, - operations, - iterable declarations, - maplike declarations and - setlike declarations - that exist on all of the interface prototype objects of A’s - consequential interfaces. - For operations, where the property is a data property with a Function - object value, each copy of the property MUST have - distinct Function objects. For attributes, each - copy of the accessor property MUST have - distinct Function objects for their getters, - and similarly with their setters. -

    -
    Note
    -

    - When invoking an operation by calling - a Function object that is the value of one of the copies that exists - due to an implements statement, the this value is - checked to ensure that it is an object that implements the - interface corresponding to the - interface prototype object - that the property is on. -

    -

    - For example, consider the following IDL: -

    -
    IDL
    interface A {
    -  void f();
    +
    +

    In the ECMAScript binding, using a Student object in a context where a string is expected will result in the + value of the object’s “name” property being + used:

    +
    var s = new Student();
    +s.id = 12345678;
    +s.name = '周杰倫';
    +        
    +var greeting = 'Hello, ' + s + '!';  // Now greeting == 'Hello, 周杰倫!'.
    +

    The following IDL fragment defines an interface that has custom stringification behavior that is + not specified in the IDL itself.

    +
    [Constructor]
    +interface Student {
    +  attribute unsigned long id;
    +  attribute DOMString? familyName;
    +  attribute DOMString givenName;
    +        
    +  stringifier DOMString ();
     };
    -
    -interface B { };
    -B implements A;
    -
    -interface C { };
    -C implements A;
    -

    - Attempting to call B.prototype.f on an object that implements - A (but not B) or one - that implements C will result in a - TypeError being thrown. However, - calling A.prototype.f on an object that implements - B or one that implements C - would succeed. This is handled by the algorithm in section 4.6.7 - that defines how IDL operation invocation works in ECMAScript. -

    -

    - Similar behavior is required for the getter and setter Function - objects that correspond to an IDL attributes, - and this is handled in section 4.6.6. -

    -
    -
    - -
    -

    4.8. Platform objects implementing interfaces

    - -

    - Every platform object is associated with a global environment, just - as the initial objects are. - It is the responsibility of specifications using Web IDL to state - which global environment (or, by proxy, which global object) each platform - object is associated with. -

    -

    - The primary interface of a platform object - that implements one or more interfaces is the most-derived non-supplemental interface - that it implements. The value of the internal [[Prototype]] - property of the platform object is the interface prototype object - of the primary interface - from the platform object’s associated global environment. -

    -

    - The global environment that a given platform object - is associated with can change after it has been created. When - the global environment associated with a platform object is changed, its internal - [[Prototype]] property MUST be immediately - updated to be the interface prototype object - of the primary interface - from the platform object’s newly associated global environment. -

    - - - -

    - Every platform object that implements an [Unforgeable]-annotated - interface and which does not have a stringifier - that is unforgeable on any of the - interfaces it implements MUST have a property with the - following characteristics: -

    -
      -
    • The name of the property is “toString”.
    • -
    • The property has attributes { [[Writable]]: false, [[Enumerable]]: true, [[Configurable]]: false }.
    • -
    • The value of the property is %ObjProto_toString% ([ECMA-262], section 6.1.7.4), the initial value of Object.prototype.toString.
    • -
    - -

    - Every platform object that implements an [Unforgeable]-annotated - interface and which does not have a serializer - that is unforgeable on any of the - interfaces it implements MUST have a property with the - following characteristics: -

    -
      -
    • The name of the property is “toJSON”.
    • -
    • The property has attributes { [[Writable]]: false, [[Enumerable]]: true, [[Configurable]]: false }.
    • -
    • The value of the property is undefined.
    • -
    - -

    - Every platform object that implements an [Unforgeable]-annotated - interface MUST have a property with the - following characteristics: -

    -
      -
    • The name of the property is “valueOf”.
    • -
    • The property has attributes { [[Writable]]: false, [[Enumerable]]: true, [[Configurable]]: false }.
    • -
    • - The value of the property is a Function object whose behavior - is as follows: -
        -
      1. Return the this value.
      2. -
      - This Function object is the - default unforgeable valueOf function. -
    • -
    • The value of the Function object’s “length” - property is the Number value 0.
    • -
    • The value of the Function object’s “name” property is the - String value “valueOf”.
    • -
    - -

    - The class string of - a platform object that implements one or more interfaces - MUST be the identifier of - the primary interface - of the platform object. -

    - -
    -

    4.8.1. Indexed and named properties

    - -

    - If a platform object implements an interface that - supports indexed or - named properties, - the object will appear to have additional properties that correspond to the - object’s indexed and named properties. These properties are not “real” own - properties on the object, but are made to look like they are by being exposed - by the [[GetOwnProperty]] internal method. -

    -

    - However, when the [Global] or - [PrimaryGlobal] - extended attribute has been used, - named properties are not exposed on the object but on another object - in the prototype chain, the named properties object. -

    -

    - It is permissible for an object to implement multiple interfaces that support indexed properties. - However, if so, and there are conflicting definitions as to the object’s - supported property indices, - or if one of the interfaces is a supplemental interface for the - platform object, then it is undefined what additional properties the object will appear to - have, or what its exact behavior will be with regard to its indexed properties. - The same applies for named properties. -

    -

    - The indexed property getter - that is defined on the derived-most interface that the - platform object implements is the one that defines the behavior - when indexing the object with an array index. Similarly for - indexed property setters. - This way, the definitions of these special operations from - ancestor interfaces can be overridden. -

    - -

    - Platform objects implementing an interface that supports indexed or named properties cannot be fixed; if Object.freeze, Object.seal - or Object.preventExtensions is called on one of these objects, the function - MUST throw a TypeError. - Similarly, an interface prototype object - that exposes named properties due to the use of [Global] or - [PrimaryGlobal] - also MUST throw a TypeError - if one of the three functions above is called on it. -

    - -

    - The name of each property that appears to exist due to an object supporting indexed properties - is an array index property name, which is a property - name P such that Type(P) is String - and for which the following algorithm returns true: -

    -
      -
    1. Let i be ToUint32(P).
    2. -
    3. Let s be ToString(i).
    4. -
    5. If sP or i = 232 − 1, then return false.
    6. -
    7. Return true.
    8. -
    - - -

    - A property name is an unforgeable property name on a - given platform object if the object implements an interface that - has an interface member with that identifier - and that interface member is unforgeable on any of - the interfaces that O implements. If the object implements an - [Unforgeable]-annotated - interface, then “toString” and “valueOf” are - also unforgeable property names - on that object. -

    -

    - The named property visibility algorithm is used to determine if - a given named property is exposed on an object. Some named properties are not exposed on an object - depending on whether the [OverrideBuiltins] - extended attribute was used. The algorithm - operates as follows, with property name P and object O: -

    - -
      -
    1. If P is an unforgeable property name - on O, then return false.
    2. -
    3. If O implements an interface with - an [Unforgeable]-annotated attribute - whose identifier is P, then return false.
    4. -
    5. If P is not a supported property name - of O, then return false.
    6. -
    7. If O implements an interface that has the [OverrideBuiltins] - extended attribute, then return true.
    8. -
    9. If O has an own property named P, then return false.
    10. -
    11. Initialize prototype to be the value of the internal [[Prototype]] property of O.
    12. -
    13. While prototype is not null: -
        -
      1. If prototype is not a named properties object, - and prototype has an own property named P, then return false.
      2. -
      3. Set prototype to be the value of the internal [[Prototype]] property of prototype.
      4. -
      -
    14. -
    15. Return true.
    16. -
    -
    Note
    -

    This should ensure that for objects with named properties, property resolution is done in the following order:

    -
      -
    1. Indexed properties.
    2. -
    3. Unforgeable attributes and operations.
    4. -
    5. Then, if [OverrideBuiltins]: -
        -
      1. Named properties.
      2. -
      3. Own properties.
      4. -
      5. Properties from the prototype chain.
      6. -
      -
    6. -
    7. Otherwise, if not [OverrideBuiltins]: -
        -
      1. Own properties.
      2. - -
      3. Properties from the prototype chain.
      4. - -
      5. Named properties.
      6. -
      -
    8. -
    -
    -

    - Support for getters is - handled by the platform object [[GetOwnProperty]] method - defined in section 4.8.3, and - for setters - by the platform object [[DefineOwnProperty]] method - defined in section 4.8.7 and the platform object [[Set]] method - defined in section 4.8.6. -

    -
    - -
    -

    4.8.2. The PlatformObjectGetOwnProperty abstract operation

    - -

    - The PlatformObjectGetOwnProperty - abstract operation performs the following steps when called with an - object O, a property name P, and a boolean - ignoreNamedProps value: -

    - -
      -
    1. - If O supports indexed properties - and P is an array index property name, then: -
        -
      1. Let index be the result of calling ToUint32(P).
      2. -
      3. If index is a supported property index, then: -
          -
        1. Let operation be the operation used to declare the indexed property getter.
        2. - -
        3. Let value be an uninitialized variable.
        4. -
        5. If operation was defined without an identifier, then - set value to the result of performing the steps listed in the interface description to - determine the value of an indexed property - with index as the index.
        6. -
        7. Otherwise, operation was defined with an identifier. Set value to the result - of performing the steps listed in the description of operation with index as the only argument value.
        8. - -
        9. Let desc be a newly created Property Descriptor ([ECMA-262], section 6.2.4) with no fields.
        10. -
        11. Set desc.[[Value]] to the result of converting - value to an ECMAScript value.
        12. -
        13. If O implements an interface with an indexed property setter, then set - desc.[[Writable]] to true, otherwise set it to - false.
        14. -
        15. Set desc.[[Enumerable]] and desc.[[Configurable]] to true.
        16. -
        17. Return desc.
        18. -
        -
      4. -
      5. Set ignoreNamedProps to true.
      6. -
      -
    2. - -
    3. If O supports named properties, O does not - implement an interface with the [Global] or [PrimaryGlobal] - extended attribute, the result of running the named property visibility algorithm with - property name P and object O is true, and ignoreNamedProps is false, then: -
        -
      1. Let operation be the operation used to declare the named property getter.
      2. - -
      3. Let value be an uninitialized variable.
      4. -
      5. If operation was defined without an identifier, then - set value to the result of performing the steps listed in the interface description to - determine the value of a named property - with P as the name.
      6. -
      7. Otherwise, operation was defined with an identifier. Set value to the result - of performing the steps listed in the description of operation with P as the only argument value.
      8. - -
      9. Let desc be a newly created Property Descriptor ([ECMA-262], section 6.2.4) with no fields.
      10. -
      11. Set desc.[[Value]] to the result of converting - value to an ECMAScript value.
      12. -
      13. If O implements an interface with a named property setter, then set - desc.[[Writable]] to true, otherwise set it to - false.
      14. -
      15. If O implements an interface with the - [LegacyUnenumerableNamedProperties] - extended attribute, - then set desc.[[Enumerable]] to false, - otherwise set it to true.
      16. -
      17. Set desc.[[Configurable]] to true.
      18. -
      19. Return desc.
      20. -
      -
    4. - -
    5. Return OrdinaryGetOwnProperty(O, P).
    6. -
    -
    - -
    -

    4.8.3. Platform object [[GetOwnProperty]] method

    - -

    - The internal [[GetOwnProperty]] method of every - platform object O that implements an interface - which supports indexed or - named properties - MUST behave as follows when called with property name P: -

    - -
      -
    1. - Return the result of invoking the PlatformObjectGetOwnProperty - abstract operation with - O, P, and false as - arguments. -
    2. -
    -
    - -
    -

    4.8.4. Invoking a platform object indexed property setter

    -

    - To invoke an indexed property - setter with property name P and ECMAScript value - V, the following steps MUST be performed: -

    -
      -
    1. Let index be the result of calling ToUint32(P).
    2. -
    3. Let creating be true if index is not a supported property index, and false otherwise.
    4. -
    5. Let operation be the operation used to declare the indexed property setter.
    6. -
    7. Let T be the type of the second argument of operation.
    8. -
    9. Let value be the result of converting V to an IDL value of type T.
    10. -
    11. If operation was defined without an identifier, then: -
        -
      1. If creating is true, then perform the steps listed in the interface description to - set the value of a new indexed property - with index as the index and value as the value.
      2. -
      3. Otherwise, creating is false. Perform the steps listed in the interface description to - set the value of an existing indexed property - with index as the index and value as the value.
      4. -
      -
    12. -
    13. Otherwise, operation was defined with an identifier. Perform the steps listed in the description of - operation with index and value as the two argument values.
    14. -
    -
    - -
    -

    4.8.5. Invoking a platform object named property setter

    -

    - To invoke a named property - setter with property name P and ECMAScript value - V, the following steps MUST be performed: -

    -
      -
    1. Let creating be true if P is not a supported property name, and false otherwise.
    2. -
    3. Let operation be the operation used to declare the named property setter.
    4. -
    5. Let T be the type of the second argument of operation.
    6. -
    7. Let value be the result of converting V to an IDL value of type T.
    8. -
    9. If operation was defined without an identifier, then: -
        -
      1. If creating is true, then perform the steps listed in the interface description to - set the value of a new named property - with P as the name and value as the value.
      2. -
      3. Otherwise, creating is false. Perform the steps listed in the interface description to - set the value of an existing named property - with P as the name and value as the value.
      4. -
      -
    10. -
    11. Otherwise, operation was defined with an identifier. Perform the steps listed in the description of - operation with index and value as the two argument values.
    12. -
    -
    - -
    -

    4.8.6. Platform object [[Set]] method

    - -

    - The internal [[Set]] method of every - platform object O that implements an interface - which supports indexed or - named properties - MUST behave as follows when called - with property name P, value V, and - ECMAScript language value Receiver: -

    - -
      -
    1. If O and Receiver are the same object, - then: -
        -
      1. - If O supports indexed - properties, P is an array index property - name, and O implements an interface with an indexed - property setter, then: -
          -
        1. - Invoke the indexed - property setter with P and V. -
        2. -
        3. Return true.
        4. -
        -
      2. - -
      3. - If O supports named - properties, Type(P) is String, - P is not an array index property - name, and O implements an interface with a named - property setter, then: -
          -
        1. - Invoke the named - property setter with P and V. -
        2. -
        3. Return true.
        4. -
        -
      4. -
      -
    2. -
    3. - Let ownDesc be the result of invoking the PlatformObjectGetOwnProperty - abstract operation with - O, P, and true as - arguments. -
    4. -
    5. - Perform steps 3-11 of the default [[Set]] internal method ([ECMA-262], section 9.1.9). -
    6. -
    -
    - -
    -

    4.8.7. Platform object [[DefineOwnProperty]] method

    - -

    - When the internal [[DefineOwnProperty]] method of a - platform object O that - implements an interface which - supports indexed or - named properties is - called with property key P and Property Descriptor ([ECMA-262], section 6.2.4) - Desc, the following steps MUST be taken: -

    - -
      -
    1. - If O supports indexed properties and - P is an array index property name, then: -
        -
      1. - If the result of calling IsDataDescriptor(Desc) is - false, then return - false. -
      2. -
      3. - If O does not implement an interface with an - indexed property - setter, then return false. -
      4. -
      5. - Invoke the indexed property setter with - P and Desc.[[Value]]. -
      6. -
      7. - Return true. -
      8. -
      -
    2. - -
    3. - If O supports named properties, - O does not implement an interface with the - [Global] or [PrimaryGlobal] extended attribute - and P is not an unforgeable property name - of O, then: -
        -
      1. Let creating be true if P is not a supported property name, and false otherwise.
      2. -
      3. If O implements an interface with the [OverrideBuiltins] - extended attribute or O does not have an own property - named P, then: -
          -
        1. - If creating is false and O does not implement an - interface with a named - property setter, then return false. -
        2. -
        3. - If O implements an interface with a - named property - setter, then: -
            -
          1. - If the result of calling IsDataDescriptor(Desc) is - false, then return - false. -
          2. -
          3. - Invoke the named property setter - with P and - Desc.[[Value]]. -
          4. -
          5. - Return true. -
          6. -
          -
        4. -
        -
      4. -
      -
    4. - -
    5. - If O does not implement an - interface with the - [Global] or - [PrimaryGlobal] - extended attribute, then set - Desc.[[Configurable]] to - true. -
    6. - -
    7. - Return OrdinaryDefineOwnProperty(O, P, - Desc). -
    8. -
    -
    - -
    -

    4.8.8. Platform object [[Delete]] method

    - -

    - The internal [[Delete]] method of every - platform object O that implements an interface - which supports indexed or - named properties - MUST behave as follows when called with property name P. -

    - -
      -
    1. - If O supports indexed properties and - P is an array index property name, then: -
        -
      1. Let index be the result of calling ToUint32(P).
      2. -
      3. If index is not a supported property index, then return true.
      4. -
      5. Return false.
      6. -
      -
    2. - -
    3. - If O supports named properties, - O does not implement an interface with the - [Global] or [PrimaryGlobal] extended attribute - and the result of calling the named property visibility algorithm - with property name P and object O is true, then: -
        -
      1. If O does not implement an interface with a named property deleter, then return false.
      2. -
      3. Let operation be the operation used to declare the named property deleter.
      4. -
      5. If operation was defined without an identifier, then: -
          -
        1. Perform the steps listed in the interface description to - delete an existing named property - with P as the name.
        2. -
        3. If the steps indicated that the deletion failed, then return false.
        4. -
        -
      6. -
      7. Otherwise, operation was defined with an identifier: -
          -
        1. Perform the steps listed in the description of operation with P as the only argument value.
        2. -
        3. If operation was declared with a return type of boolean - and the steps returned false, then return false.
        4. -
        -
      8. -
      9. Return true.
      10. -
      -
    4. - -
    5. If O has an own property with name P, then: -
        -
      1. If the property is not configurable, then return false.
      2. -
      3. Otherwise, remove the property from O.
      4. -
      -
    6. -
    7. Return true.
    8. -
    -
    - -
    -

    4.8.9. Platform object [[Call]] method

    - -

    - The internal [[Call]] method of every - platform object O that implements an interface - I with at least one legacy caller - MUST behave as follows, assuming - arg0..n−1 is the list of argument - values passed to [[Call]]: -

    -
      -
    1. Initialize S to the effective overload set - for legacy callers on I and with argument count n.
    2. -
    3. - Let <operation, values> be the result of passing S and - arg0..n−1 to the - overload resolution algorithm. -
    4. -
    5. Perform the actions listed in the description of the legacy caller operation with - values as the argument values.
    6. -
    7. Return the result of converting - the return value from those actions to an ECMAScript value of the type - operation is declared to return (or undefined - if operation is declared to return void).
    8. -
    -
    - -
    -

    4.8.10. Property enumeration

    - -

    - This document does not define a complete property enumeration order - for all platform objects implementing interfaces - (or for platform objects representing exceptions). - However, if a platform object implements an interface that - supports indexed or - named properties, then - properties on the object MUST be - enumerated in the following order: -

    -
      -
    1. If the object supports indexed properties, then - the object’s supported property indices are - enumerated first, in numerical order.
    2. -
    3. If the object supports named properties and doesn't implement an interface with the - [LegacyUnenumerableNamedProperties] - extended attribute, then - the object’s supported property names that - are visible according to the named property visibility algorithm - are enumerated next, in the order given in the definition of the set of supported property names.
    4. -
    5. Finally, any enumerable own properties or properties from the object’s prototype chain are then enumerated, - in no defined order.
    6. -
    -
    Note
    -

    Future versions of the ECMAScript specification may define a total order for property enumeration.

    -
    -
    -
    - -
    -

    4.9. User objects implementing callback interfaces

    - -

    - As described in section 3.10 above, - callback interfaces can be - implemented in script by an ECMAScript object. - The following cases determine whether and how a given object - is considered to be a user object implementing a callback interface: -

    -
      -
    • - If the interface is a single operation callback interface - (defined below) then any object apart from a native RegExp - object is considered to implement the interface. - The implementation of the operation (or set of overloaded operations) is - as follows: -
        -
      • If the object is callable, - then the implementation of the operation (or set of overloaded operations) is - the callable object itself.
      • -
      • Otherwise, the object is not callable. - The implementation of the operation (or set of overloaded operations) is - the result of invoking the internal [[Get]] method - on the object with a property name that is the identifier - of the operation.
      • -
      -
    • -
    • - Otherwise, the interface is not a single operation callback interface. - Any object that is not a native - RegExp object is considered to implement the interface. - For each operation declared on the interface with a given identifier, the implementation - is the result of invoking [[Get]] on the object with a - property name that is that identifier. -
    • -
    - -

    - Note that ECMAScript objects need not have - properties corresponding to constants - on them to be considered as user objects - implementing interfaces that happen - to have constants declared on them. -

    - -

    - A single operation callback interface is - a callback interface that: -

    - - -

    - To call a user object's - operation, given a callback interface - type value value, sometimes-optional operation name opName, - list of argument values arg0..n−1 each of which is - either an IDL value or the special value “missing” (representing a missing optional - argument), and optional callback this - value thisArg, perform the following steps. These steps will either - return an IDL value or throw an exception. -

    - -
      -
    1. Let completion be an uninitialized variable.
    2. - -
    3. If thisArg was not given, let thisArg be undefined.
    4. - -
    5. Let O be the ECMAScript object corresponding to value.
    6. - -
    7. Let realm be O's associated Realm.
    8. - -
    9. Let relevant settings be realm's settings - object.
    10. - -
    11. Let stored settings be value's callback context.
    12. - -
    13. Prepare to run script with relevant settings.
    14. - -
    15. Prepare to run a callback with stored settings.
    16. - -
    17. - Determine the implementation of the operation, X: - -
        -
      1. If value's interface is a single operation callback - interface and ! IsCallable(O) is true, then set - X to O.
      2. - -
      3. - Otherwise, opName must be supplied: -
          -
        1. Let getResult be Get(O, - opName).
        2. - -
        3. If getResult is an abrupt completion, set completion - to getResult and jump to the step labeled return.
        4. - -
        5. Set X to getResult.[[Value]].
        6. -
        -
      4. -
      -
    18. - - -
    19. If ! IsCallable(X) is false, - then set completion to a new Completion{[[Type]]: throw, [[Value]]: a - newly created TypeError object, [[Target]]: empty}, and jump - to the step labeled return.
    20. - -
    21. If value's interface is not a single operation callback interface, - or if ! IsCallable(O) is false, - set thisArg to O (overriding the provided value).
    22. - -
    23. Let esArgs be an empty List of ECMAScript values.
    24. - -
    25. Let i be 0.
    26. - -
    27. Let count be 0.
    28. - -
    29. - While i < n: - -
        -
      1. If argi is the special value “missing”, then - append undefined to esArgs.
      2. - -
      3. - Otherwise, argi is an IDL value: - -
          -
        1. Let convertResult be the result of converting - argi to an ECMAScript value.
        2. - -
        3. If convertResult is an abrupt completion, set completion - to convertResult and jump to the step labeled return.
        4. - -
        5. Append convertResult.[[Value]] to esArgs.
        6. - -
        7. Set count to i + 1.
        8. -
        -
      4. - -
      5. Set i to i + 1.
      6. -
      -
    30. - -
    31. Truncate esArgs to have length count.
    32. - -
    33. Let callResult be Call(X, thisArg, - esArgs).
    34. - -
    35. If callResult is an abrupt completion, set completion to - callResult and jump to the step labeled return.
    36. - -
    37. Set completion to the result of converting - callResult.[[Value]] to an IDL value of the same type as the operation’s - return type.
    38. - -
    39. - Return: at this - point completion will be set to an ECMAScript completion value. - -
        -
      1. Clean up after running a callback with stored settings.
      2. - -
      3. Clean up after running script with relevant settings.
      4. - -
      5. If completion is a normal completion, return - completion.
      6. - -
      7. If completion is an abrupt completion and the operation has a return type that is not a promise type, return completion.
      8. - -
      9. Let reject be the initial value of %Promise%.reject.
      10. - -
      11. Let rejectedPromise be the result of calling reject with - %Promise% as the this value and - completion.[[Value]] as the single argument value.
      12. - -
      13. Return the result of converting - rejectedPromise to the operation's return type.
      14. -
      -
    40. -
    - -

    - To get a user object's - attribute value, given a callback - interface type value object and attribute name attributeName, - perform the following steps. These steps will either return an IDL value or throw an - exception. -

    - -
      -
    1. Let completion be an uninitialized variable.
    2. - -
    3. Let O be the ECMAScript object corresponding to object.
    4. - -
    5. Let realm be O's associated Realm.
    6. - -
    7. Let relevant settings be realm's settings - object.
    8. - -
    9. Let stored settings be object's callback context.
    10. - -
    11. Prepare to run script with relevant settings.
    12. - -
    13. Prepare to run a callback with stored settings.
    14. - -
    15. Let getResult be Get(O, attributeName).
    16. - -
    17. If getResult is an abrupt completion, set completion to - getResult and jump to the step labeled return.
    18. - -
    19. Set completion to the result of converting - getResult.[[Value]] to an IDL value of the same type as the attribute's - type.
    20. - -
    21. - Return: at this - point completion will be set to an ECMAScript completion value. - -
        -
      1. Clean up after running a callback with stored settings.
      2. - -
      3. Clean up after running script with relevant settings.
      4. - -
      5. If completion is a normal completion, return - completion.
      6. - -
      7. If completion is an abrupt completion and the attribute's type is - not a promise type, return - completion.
      8. - -
      9. Let reject be the initial value of %Promise%.reject.
      10. - -
      11. Let rejectedPromise be the result of calling reject with - %Promise% as the this value and - completion.[[Value]] as the single argument value.
      12. - -
      13. Return the result of converting - rejectedPromise to the attribute's type.
      14. -
      -
    22. -
    - -

    - To set a user object's - attribute value, given a callback - interface type value object, attribute name attributeName, and - IDL value value, perform the following steps. These steps will not return - anything, but could throw an exception. -

    - -
      -
    1. Let completion be an uninitialized variable.
    2. - -
    3. Let O be the ECMAScript object corresponding to object.
    4. - -
    5. Let realm be O's associated Realm.
    6. - -
    7. Let relevant settings be realm's settings - object.
    8. - -
    9. Let stored settings be object's callback context.
    10. - -
    11. Prepare to run script with relevant settings.
    12. - -
    13. Prepare to run a callback with stored settings.
    14. - -
    15. Let convertResult be the result of converting value to an - ECMAScript value.
    16. - -
    17. If convertResult is an abrupt completion, set completion to - convertResult and jump to the step labeled return.
    18. - -
    19. Set completion to Set(O, attributeName, - convertResult.[[Value]], true).
    20. - -
    21. - Return: at this - point completion will be set to an ECMAScript completion value, which is - either an abrupt completion or a normal completion for the value true (as returned by Set). - -
        -
      1. Clean up after running a callback with stored settings.
      2. - -
      3. Clean up after running script with relevant settings.
      4. - -
      5. If completion is an abrupt completion, return - completion.
      6. - -
      7. Return NormalCompletion(void).
      8. -
      -
    22. -
    -
    - -
    -

    4.10. Invoking callback functions

    - -

    - An ECMAScript callable object that is being - used as a callback function value is - called in a manner similar to how operations - on user objects are called (as - described in the previous section). -

    - -

    - To invoke a callback function type value callable with - a list of arguments arg0..n−1, each of which is either - an IDL value or the special value “missing” (representing a missing optional argument), - and with optional callback this - value thisArg, perform the following steps. These steps will either - return an IDL value or throw an exception. -

    - -
      -
    1. Let completion be an uninitialized variable.
    2. - -
    3. If thisArg was not given, let thisArg be undefined.
    4. - -
    5. Let F be the ECMAScript object corresponding to value.
    6. - -
    7. - If ! IsCallable(F) is false: - -
        -
      1. -

        If the callback function's return type is void, - return.

        - -
        Note
        -

        This is only possible when the callback function came from an attribute - marked with [TreatNonObjectAsNull].

        -
        -
      2. - -
      3. Return the result of converting undefined to the callback function's return type.
      4. -
      -
    8. - -
    9. Let realm be F's associated Realm.
    10. - -
    11. Let relevant settings be realm's settings - object.
    12. - -
    13. Let stored settings be callable's callback context.
    14. - -
    15. Prepare to run script with relevant settings.
    16. - -
    17. Prepare to run a callback with stored settings.
    18. - -
    19. Let esArgs be an empty List of ECMAScript values.
    20. - -
    21. Let i be 0.
    22. - -
    23. Let count be 0.
    24. - -
    25. - While i < n: - -
        -
      1. If argi is the special value “missing”, then - append undefined to esArgs.
      2. - -
      3. - Otherwise, argi is an IDL value: - -
          -
        1. Let convertResult be the result of converting - argi to an ECMAScript value.
        2. - -
        3. If convertResult is an abrupt completion, set completion - to convertResult and jump to the step labeled return.
        4. - -
        5. Append convertResult.[[Value]] to esArgs.
        6. - -
        7. Set count to i + 1.
        8. -
        -
      4. - -
      5. Set i to i + 1.
      6. -
      -
    26. - -
    27. Truncate esArgs to have length count.
    28. - -
    29. Let callResult be Call(X, thisArg, - esArgs).
    30. - -
    31. If callResult is an abrupt completion, set completion to - callResult and jump to the step labeled return.
    32. - -
    33. Set completion to the result of converting - callResult.[[Value]] to an IDL value of the same type as the operation’s - return type.
    34. - -
    35. - Return: at this - point completion will be set to an ECMAScript completion value. - -
        -
      1. Clean up after running a callback with stored settings.
      2. - -
      3. Clean up after running script with relevant settings.
      4. - -
      5. If completion is a normal completion, return - completion.
      6. - -
      7. If completion is an abrupt completion and the callback function has a - return type that is not a promise type, return completion.
      8. - -
      9. Let reject be the initial value of %Promise%.reject.
      10. - -
      11. Let rejectedPromise be the result of calling reject with - %Promise% as the this value and - completion.[[Value]] as the single argument value.
      12. - -
      13. Return the result of converting - rejectedPromise to the callback function's return type.
      14. -
      -
    36. -
    -
    - -
    -

    4.11. Namespaces

    - -

    - For every namespace that is exposed in a given ECMAScript global environment, - a corresponding property MUST exist on the ECMAScript - environment's global object. The name of the property is the identifier of the namespace, and its value is an object - called the namespace object. -

    -

    - The property has the attributes { [[Writable]]: true, [[Enumerable]]: false, - [[Configurable]]: true }. The characteristics of a - namespace object are described in section 4.11.1 below. -

    - -
    -

    4.11.1. Namespace object

    - -

    - The namespace object for a given namespace - namespace and Realm realm is created as - follows: -

    - -
      -
    1. - Let namespaceObject be - ! ObjectCreate(the %ObjectPrototype% of realm). -
    2. - -
    3. - For each exposed regular operation op that is a namespace member of this namespace, - -
        -
      1. - Let F be the result of creating an operation function given - op, namespace, and realm. -
      2. - -
      3. - Perform ! CreateDataProperty(namespaceObject, - op's identifier, - F). -
      4. -
      -
    4. -
    -
    -
    - -
    -

    4.12. Exceptions

    - -

    - There MUST exist a property on the ECMAScript global object - whose name is “DOMException” and value is an object called the - DOMException constructor object, - which provides access to legacy DOMException code constants and allows construction of - DOMException instances. - The property has the attributes { [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true }. -

    - -
    -

    4.12.1. DOMException constructor object

    - -

    - The DOMException constructor object MUST be a function object - but with a [[Prototype]] value of %Error% ([ECMA-262], section 6.1.7.4). -

    -

    - For every legacy code listed in the error names table, - there MUST be a property on the DOMException constructor object - whose name and value are as indicated in the table. The property has - attributes { [[Writable]]: false, [[Enumerable]]: true, [[Configurable]]: false }. -

    -

    - The DOMException constructor object MUST also have a property named - “prototype” with attributes - { [[Writable]]: false, [[Enumerable]]: false, [[Configurable]]: false } - whose value is an object called the DOMException prototype object. - This object also provides access to the legacy code values. -

    - -
    -
    4.12.1.1. DOMException(message, name)
    - -

    When the DOMException function is called with arguments message and name, the following steps are taken:

    - -
      -
    1. Let F be the active function object.
    2. -
    3. If NewTarget is undefined, let newTarget be F, else let newTarget be NewTarget.
    4. -
    5. Let super be F.[[GetPrototypeOf]]().
    6. -
    7. ReturnIfAbrupt(super).
    8. -
    9. If IsConstructor(super) is false, throw a TypeError exception.
    10. -
    11. Let O be Construct(super, «message», newTarget).
    12. -
    13. If name is not undefined, then -
        -
      1. Let name be ToString(name).
      2. -
      3. Let status be DefinePropertyOrThrow(O, "name", PropertyDescriptor{[[Value]]: name, [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true}).
      4. -
      5. ReturnIfAbrupt(status).
      6. -
      7. Let code be the legacy code indicated in the error names table for error name name, or 0 if there is none.
      8. -
      9. Let status be DefinePropertyOrThrow(O, "code", PropertyDescriptor{[[Value]]: code, [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true}).
      10. -
      11. ReturnIfAbrupt(status).
      12. -
      -
    14. -
    15. Return O.
    16. -
    -
    -
    - -
    -

    4.12.2. DOMException prototype object

    - -

    - The DOMException prototype object MUST - have an internal [[Prototype]] property whose value is %ErrorPrototype% ([ECMA-262], section 6.1.7.4). -

    -

    - The class string of the - DOMException prototype object - is “DOMExceptionPrototype”. -

    -

    - There MUST be a property named “constructor” - on the DOMException prototype object with attributes - { [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true } - and whose value is the DOMException constructor object. -

    -

    - For every legacy code listed in the error names table, - there MUST be a property on the DOMException prototype object - whose name and value are as indicated in the table. The property has - attributes { [[Writable]]: false, [[Enumerable]]: true, [[Configurable]]: false }. -

    -
    -
    - -
    -

    4.13. Exception objects

    - -

    - Simple exceptions are represented - by native ECMAScript objects of the corresponding type. -

    -

    - DOMExceptions are represented by - platform objects that inherit from - the DOMException prototype object. -

    -

    - Every platform object representing a DOMException in ECMAScript is associated with a global environment, just - as the initial objects are. - When an exception object is created by calling the DOMException constructor object, - either normally or as part of a new expression, then the global environment - of the newly created object is associated with MUST be the same as for the - DOMException constructor object itself. -

    -

    - The value of the internal [[Prototype]] - property of a DOMException - object MUST be the DOMException prototype object - from the global environment the exception object is associated with. -

    -

    - The class string - of a DOMException object - MUST be “DOMException”. -

    -
    Note
    -

    The intention is for DOMException objects to be just like the other - various native Error objects that the - ECMAScript specification defines, apart from responding differently - to being passed to Object.prototype.toString and it having a “code” property. - If an implementation places non-standard properties on native - Error objects, exposing for example - stack traces or error line numbers, then these ought to be exposed - on exception objects too.

    -
    -
    - -
    -

    4.14. Creating and throwing exceptions

    - -

    - First, we define the current global environment - as the result of running the following algorithm: -

    -
      -
    1. - Let F be the Function object used - as the this value in the top-most call - on the ECMAScript call stack where F corresponds to an IDL - attribute, - operation, - indexed property, - named property, - constructor, - named constructor or - stringifier. -
    2. -
    3. - If F corresponds to an attribute, operation or stringifier, then return - the global environment associated with the - interface that definition appears on. -
    4. -
    5. - Otherwise, if F corresponds to an indexed or named property, then return - the global environment associated with the interface that - the indexed or named property getter, setter or deleter was defined on. -
    6. -
    7. - Otherwise, if F is a named constructor for an interface, or is - an interface object for an - interface that is a constructor, then return the global environment - associated with that interface. -
    8. -
    9. - Otherwise, F is an exception field getter. Return - the global environment associated with the exception on which the - exception field was defined. -
    10. -
    -

    - When a simple exception or - DOMException - E is to be created, - with error name N and - optional user agent-defined message M, - the following steps MUST be followed: -

    -
      -
    1. If M was not specified, let M be undefined. Otherwise, let it be the result of converting M to a String value.
    2. -
    3. Let N be the result of converting N to a String value.
    4. -
    5. Let args be a list of ECMAScript values. -
      -
      E is DOMException
      -
      args is (undefined, N).
      -
      E is a simple exception
      -
      args is (M)
      -
      -
    6. -
    7. Let G be the current global environment.
    8. -
    9. Let X be an object determined based on the type of E: -
      -
      E is DOMException
      -
      X is the DOMException constructor object - from the global environment G.
      -
      E is a simple exception
      -
      X is the constructor for the corresponding ECMAScript error - from the global environment G.
      -
      -
    10. -
    11. Let O be the result of calling X as a function - with args as the argument list.
    12. -
    13. Return O.
    14. -
    -

    - When a simple exception or - DOMException - E is to be thrown, - with error name N and - optional user agent-defined message M, - the following steps MUST be followed: -

    -
      -
    1. Let O be the result of creating - the specified exception E with error name N and - optional user agent-defined message M.
    2. -
    3. Throw O.
    4. -
    -
    Note
    -

    - The above algorithms do not restrict platform objects representing exceptions - propagating out of a Function to be - ones that are associated with the global environment - where that Function object originated. - For example, consider the IDL: -

    -
    IDL
    interface A {
    -
    -  /**
    +
    +

    Thus, prose is required to explain the stringification behavior, such + as the following paragraph:

    +
    +

    Objects that implement the Student interface must stringify as follows. If the value of the familyName attribute is null, the stringification of the + object is the value of the givenName attribute. Otherwise, if the value of the familyName attribute is not null, + the stringification of the object is the concatenation of the + value of the givenName attribute, + a single space character, and the value of + the familyName attribute.

    +
    +

    An ECMAScript implementation of the IDL would behave as follows:

    +
    var s = new Student();
    +s.id = 12345679;
    +s.familyName = 'Smithee';
    +s.givenName = 'Alan';
    +        
    +var greeting = 'Hi ' + s;  // Now greeting == 'Hi Alan Smithee'.
    +
    +
    3.2.4.3. Serializers
    +

    When an interface has a serializer, it indicates that objects provide +a way for them to be converted into a serialized form. Serializers can be declared +using the serializer keyword:

    +
    interface interface_identifier {
    +  serializer;
    +};
    +
    +

    Prose accompanying an interface that declares a serializer in this +way must define the serialization behavior of the interface. Serialization behavior is defined as returning +a serialized value of one of the following types:

    + +

    How the serialization behavior is made available on an object in a language binding, and how exactly the abstract serialized value is converted into +an appropriate concrete value, is language binding specific.

    +

    Note: In the ECMAScript language binding, serialization behavior is exposed as a toJSON method which returns the serialized value converted +into an ECMAScript value that can be serialized to JSON by the JSON.stringify function. See §4.6.7.2 Serializers for details.

    +

    Serialization behavior can also be specified directly in IDL, rather than separately as prose. +This is done by following the serializer keyword with +a U+003D EQUALS SIGN ("=") character and +a serialization pattern, +which can take one of the following six forms:

    +
      +
    • +

      A map with entries corresponding to zero or more attributes from the interface, and optionally +attributes from an inherited interface:

      +
      interface interface_identifier {
      +  serializer = { attribute_identifier, attribute_identifier /* , ... */ };
      +  serializer = { inherit, attribute_identifier, attribute_identifier /* , ... */ };
      +};
      +
      +

      Each identifier must be the identifier of an attribute declared +on the interface. The identified attributes all must have a serializable type.

      +

      The inherit keyword must not be used unless +the interface inherits from another that defines a serializer, and the closest such interface +defines its serializer using this serialization pattern form or the following form (i.e. { attribute }).

      +

      The serialization behavior for this +form of serialization pattern is as follows:

      +
        +
      1. +

        Let map be an empty map.

        +
      2. +

        If the inherit keyword was used, then set map to be the result of +the serialization behavior of the +closest inherited interface that declares a serializer.

        +
      3. +

        For each attribute identifier i in the serialization pattern, in order:

        +
          +
        1. +

          Remove any entry in map with key name i.

          +
        2. +

          Let V be the value of the attribute with identifier i.

          +
        3. +

          Add an entry to map whose key name is i and whose +value is result of converting V to a serialized value.

          +
        +
      4. +

        Return map.

        +
      +
    • +

      A map with entries corresponding to all attributes from the interface that have +a serializable type, and optionally +attributes from an inherited interface:

      +
      interface interface_identifier {
      +  serializer = { attribute };
      +  serializer = { inherit, attribute };
      +};
      +
      +

      The inherit keyword must not be used unless +the interface inherits from another that defines a serializer, and the closest such interface +defines its serializer using this serialization pattern form or the previous form.

      +

      The serialization behavior for this +form of serialization pattern is as follows:

      +
        +
      1. +

        Let map be an empty map.

        +
      2. +

        If the inherit keyword was used, then set map to be the result of +the serialization behavior of the +closest inherited interface that declares a serializer.

        +
      3. +

        For each identifier i of an attribute on the interface whose type is +a serializable type, in the order they appear +on the interface:

        +
          +
        1. +

          Remove any entry in map with key name i.

          +
        2. +

          Let V be the value of the attribute with identifier i.

          +
        3. +

          Add an entry to map whose key name is i and whose +value is result of converting V to a serialized value.

          +
        +
      4. +

        Return map.

        +
      +
    • +

      A map with entries corresponding to the named properties:

      +
      interface interface_identifier {
      +  serializer = { getter };
      +};
      +
      +

      This form must not be used unless the interface or one it +inherits from supports named properties and the return type of the named property getter +is a serializable type.

      +

      The serialization behavior for this +form of serialization pattern is as follows:

      +
        +
      1. +

        Let map be an empty map.

        +
      2. +

        For each supported property name n on the object, in order:

        +
          +
        1. +

          Let V be the value of the named property with name n.

          +
        2. +

          Add an entry to map whose key name is i and whose +value is result of converting V to a serialized value.

          +
        +
      3. +

        Return map.

        +
      +
    • +

      A list of value of zero or more attributes on the interface:

      +
      interface interface_identifier {
      +  serializer = [ attribute_identifier, attribute_identifier /* , ... */ ];
      +};
      +
      +

      Each identifier must be the identifier of an attribute declared +on the interface. The identified attributes all must have a serializable type.

      +

      The serialization behavior for this +form of serialization pattern is as follows:

      +
        +
      1. +

        Let list be an empty list.

        +
      2. +

        For each attribute identifier i in the serialization pattern:

        +
          +
        1. +

          Let V be the value of the attribute with identifier i.

          +
        2. +

          Append to list the value that is the result of converting V to a serialized value.

          +
        +
      3. +

        Return list.

        +
      +
    • +

      A list with entries corresponding to the indexed properties:

      +
      interface interface_identifier {
      +  serializer = [ getter ];
      +};
      +
      +

      This form must not be used unless the interface or one it +inherits from supports indexed properties and the return type of the indexed property getter +is a serializable type.

      +

      The serialization behavior for this +form of serialization pattern is as follows:

      +
        +
      1. +

        Let list be an empty list.

        +
      2. +

        Let i be 0.

        +
      3. +

        While i is less than or equal to the greatest supported property index on the object:

        +
          +
        1. +

          Let V be the value of the indexed property with index i if i is a supported property index, or null otherwise.

          +
        2. +

          Append to list the value that is the result of converting V to a serialized value.

          +
        3. +

          Set i to i + 1.

          +
        +
      4. +

        Return map.

        +
      +
    • +

      A single attribute:

      +
      interface interface_identifier {
      +  serializer = attribute_identifier;
      +};
      +
      +

      The identifier must be the identifier of an attribute declared +on the interface, and this attribute must have a serializable type.

      +

      The serialization behavior for this +form of serialization pattern is as follows:

      +
        +
      1. +

        Let V be the value of the attribute with the specified identifier.

        +
      2. +

        Return the result of converting V to a serialized value.

        +
      +
    +

    Note: Entries are added to maps in a particular order so that in the ECMAScript language binding +it is defined what order properties are added to objects. This is because this order +can influence the serialization that JSON.stringify can produce.

    +

    The list of serializable types and how they are converted to serialized values is as follows:

    +
    +
    +

    long long

    +
    +

    converted by choosing the closest equivalent double value +(as when converting a long long to an ECMAScript Number value)

    +
    +

    unsigned long long

    +
    +

    converted by choosing the closest equivalent double value +(as when converting a unsigned long long to an ECMAScript Number value)

    +
    +

    any other integer type

    +
    +

    float

    +
    +

    converted by choosing the equivalent double value

    +
    +

    double

    +
    +

    boolean

    +
    +

    DOMString

    +
    +

    the same value of the respective type

    +
    +

    an enumeration type

    +
    +

    the equivalent DOMString value

    +
    +

    a USVString

    +
    +

    the DOMString produced by +encoding the given sequence of Unicode scalar values in +UTF-16

    +
    +

    a ByteString

    +
    +

    the equivalent DOMString value where each code unit has the same value as the corresponding byte value

    +
    +

    a nullable serializable type

    +
    +

    converted to null if that is its value, +otherwise converted as per its inner type

    +
    +

    a union type where all of its member types are serializable types

    +
    +

    converted as per its specific type

    +
    +

    a sequence type that has a serializable type as its element type

    +
    +

    converted to a list where each element is the result of converting its +corresponding sequence element to a serialized value

    +
    +

    a dictionary where all of its members have serializable types

    +
    +

    converted to a map consisting of an entry for each dictionary member +that is present, where the entry’s key is the identifier of the dictionary +member and its value is the result of converting the dictionary member’s +value to a serializable type

    +
    +

    an interface type that has a serializer

    +
    +

    converted by invoking the object’s serializer

    +
    +

    Serializers can also be specified using an operation with the serializer keyword:

    +
    interface interface_identifier {
    +  serializer identifier();
    +};
    +
    +

    Serializers declared with operations must +be declared to take zero arguments and return a serializable type.

    +

    The serialization behavior of the interface with a serializer declared with an operation is the result of converting the value returned from invoking the operation to a serialized value.

    +
    Serializer :
    +    "serializer" SerializerRest
    +
    +
    SerializerRest :
    +    OperationRest
    +    "=" SerializationPattern ";"
    +    ";"
    +
    +
    SerializationPattern :
    +    "{" SerializationPatternMap "}"
    +    "[" SerializationPatternList "]"
    +    identifier
    +
    +
    SerializationPatternMap :
    +    "getter"
    +    "inherit" Identifiers
    +    identifier Identifiers
    +    ε
    +
    +
    SerializationPatternList :
    +    "getter"
    +    identifier Identifiers
    +    ε
    +
    +
    Identifiers :
    +    "," identifier Identifiers
    +    ε
    +
    +
    + +

    The following IDL fragment defines + an interface Transaction that has a serializer defines in prose:

    +
    interface Transaction {
    +  readonly attribute Account from;
    +  readonly attribute Account to;
    +  readonly attribute double amount;
    +  readonly attribute DOMString description;
    +  readonly attribute unsigned long number;
    +        
    +  serializer;
    +};
    +        
    +interface Account {
    +  attribute DOMString name;
    +  attribute unsigned long number;
    +};
    +
    +

    The serializer could be defined as follows:

    +
    +

    The serialization behavior of the Transaction interface is to run the following + algorithm, where O is the object that implements Transaction:

    +
      +
    1. +

      Let map be an empty map.

      +
    2. +

      Add an entry to map whose key is “from” and whose value is +the serialized value of +the number attribute on the Account object referenced by the from attribute on O.

      +
    3. +

      Add an entry to map whose key is “to” and whose value is +the serialized value of +the number attribute on the Account object referenced by the from attribute on O.

      +
    4. +

      For both of the attributes amount and description, +add an entry to map whose key is the identifier of the attribute +and whose value is the serialized value of the value of the attribute on O.

      +
    5. +

      Return map.

      +
    +
    +

    If it was acceptable for Account objects to be serializable + on their own, then serialization patterns could be used to avoid having to define the serialization behavior in prose:

    +
    interface Transaction {
    +  readonly attribute Account from;
    +  readonly attribute Account to;
    +  readonly attribute double amount;
    +  readonly attribute DOMString description;
    +  readonly attribute unsigned long number;
    +        
    +  serializer = { from, to, amount, description };
    +};
    +        
    +interface Account {
    +  attribute DOMString name;
    +  attribute unsigned long number;
    +        
    +  serializer = number;
    +};
    +
    +

    In the ECMAScript language binding, there would exist a toJSON method on Transaction objects:

    +
    // Get an instance of Transaction.
    +var txn = getTransaction();
    +        
    +// Evaluates to an object like this:
    +// {
    +//   from: 1234
    +//   to: 5678
    +//   amount: 110.75
    +//   description: "dinner"
    +// }
    +txn.toJSON();
    +        
    +// Evaluates to a string like this:
    +// '{"from":1234,"to":5678,"amount":110.75,"description":"dinner"}'
    +JSON.stringify(txn);
    +
    +
    3.2.4.4. Indexed properties
    +

    An interface that defines +an indexed property getter is said to support indexed properties.

    +

    If an interface supports indexed properties, +then the interface definition must be accompanied by +a description of what indices the object can be indexed with at +any given time. These indices are called the supported property indices.

    +

    Indexed property getters must +be declared to take a single unsigned long argument. +Indexed property setters must +be declared to take two arguments, where the first is an unsigned long.

    +
    interface interface_identifier {
    +  getter type identifier(unsigned long identifier);
    +  setter type identifier(unsigned long identifier, type identifier);
    +    
    +  getter type (unsigned long identifier);
    +  setter type (unsigned long identifier, type identifier);
    +};
    +
    +

    The following requirements apply to the definitions of indexed property getters and setters:

    +
      +
    • +

      If an indexed property getter was specified using an operation with an identifier, +then the value returned when indexing the object with a given supported property index is the value that would be returned by invoking the operation, passing +the index as its only argument. If the operation used to declare the indexed property getter +did not have an identifier, then the interface definition must be accompanied +by a description of how to determine the value of an indexed property for a given index.

      +
    • +

      If an indexed property setter was specified using an operation +with an identifier, +then the behavior that occurs when indexing the object for property assignment with a given supported property index and value +is the same as if the operation is invoked, passing +the index as the first argument and the value as the second argument. If the operation used to declare the indexed property setter +did not have an identifier, then the interface definition must be accompanied +by a description of how to set the value of an existing indexed property and how to set the value of a new indexed property for a given property index and value.

      +
    +
    +

    Note that if an indexed property getter or setter is specified using an operation with an identifier, + then indexing an object with an integer that is not a supported property index does not necessarily elicit the same behavior as invoking the operation with that index. The actual behavior in this + case is language binding specific.

    +

    In the ECMAScript language binding, a regular property lookup is done. For example, take the following IDL:

    +
    interface A {
    +  getter DOMString toWord(unsigned long index);
    +};
    +
    +

    Assume that an object implementing A has supported property indices in the range 0 ≤ index < 2. Also assume that toWord is defined to return + its argument converted into an English word. The behavior when invoking the operation with an out of range index + is different from indexing the object directly:

    +
    var a = getA();
    +        
    +a.toWord(0);  // Evalautes to "zero".
    +a[0];         // Also evaluates to "zero".
    +        
    +a.toWord(5);  // Evaluates to "five".
    +a[5];         // Evaluates to undefined, since there is no property "5".
    +
    +
    + +

    The following IDL fragment defines an interface OrderedMap which allows + retrieving and setting values by name or by index number:

    +
    interface OrderedMap {
    +  readonly attribute unsigned long size;
    +        
    +  getter any getByIndex(unsigned long index);
    +  setter void setByIndex(unsigned long index, any value);
    +        
    +  getter any get(DOMString name);
    +  setter void set(DOMString name, any value);
    +};
    +
    +

    Since all of the special operations are declared using + operations with identifiers, the only additional prose + that is necessary is that which describes what keys those sets + have. Assuming that the get() operation is + defined to return null if an + attempt is made to look up a non-existing entry in the OrderedMap, then the following + two sentences would suffice:

    +
    +

    An object map implementing OrderedMap supports indexed properties with indices in the range + 0 ≤ index < map.size.

    +

    Such objects also support a named property for every name that, + if passed to get(), would return a non-null value.

    +
    +

    As described in §4.8 Platform objects implementing interfaces, + an ECMAScript implementation would create + properties on a platform object implementing OrderedMap that correspond to + entries in both the named and indexed property sets. + These properties can then be used to interact + with the object in the same way as invoking the object’s + methods, as demonstrated below:

    +
    // Assume map is a platform object implementing the OrderedMap interface.
    +var map = getOrderedMap();
    +var x, y;
    +        
    +x = map[0];       // If map.length > 0, then this is equivalent to:
    +                  //
    +                  //   x = map.getByIndex(0)
    +                  //
    +                  // since a property named "0" will have been placed on map.
    +                  // Otherwise, x will be set to undefined, since there will be
    +                  // no property named "0" on map.
    +        
    +map[1] = false;   // This will do the equivalent of:
    +                  //
    +                  //   map.setByIndex(1, false)
    +        
    +y = map.apple;    // If there exists a named property named "apple", then this
    +                  // will be equivalent to:
    +                  //
    +                  //   y = map.get('apple')
    +                  //
    +                  // since a property named "apple" will have been placed on
    +                  // map.  Otherwise, y will be set to undefined, since there
    +                  // will be no property named "apple" on map.
    +        
    +map.berry = 123;  // This will do the equivalent of:
    +                  //
    +                  //   map.set('berry', 123)
    +        
    +delete map.cake;  // If a named property named "cake" exists, then the "cake"
    +                  // property will be deleted, and then the equivalent to the
    +                  // following will be performed:
    +                  //
    +                  //   map.remove("cake")
    +
    +
    3.2.4.5. Named properties
    +

    An interface that defines +a named property getter is said to support named properties.

    +

    If an interface supports named properties, +then the interface definition must be accompanied by +a description of the ordered set of names that can be used to index the object +at any given time. These names are called the supported property names.

    +

    Named property getters and deleters must +be declared to take a single DOMString argument. +Named property setters must +be declared to take two arguments, where the first is a DOMString.

    +
    interface interface_identifier {
    +  getter type identifier(DOMString identifier);
    +  setter type identifier(DOMString identifier, type identifier);
    +  deleter type identifier(DOMString identifier);
    +    
    +  getter type (DOMString identifier);
    +  setter type (DOMString identifier, type identifier);
    +  deleter type (DOMString identifier);
    +};
    +
    +

    The following requirements apply to the definitions of named property getters, setters and deleters:

    +
      +
    • +

      If a named property getter was specified using an operation with an identifier, +then the value returned when indexing the object with a given supported property name is the value that would be returned by invoking the operation, passing +the name as its only argument. If the operation used to declare the named property getter +did not have an identifier, then the interface definition must be accompanied +by a description of how to determine the value of a named property for a given property name.

      +
    • +

      If a named property setter was specified using an operation +with an identifier, +then the behavior that occurs when indexing the object for property assignment with a given supported property name and value +is the same as if the operation is invoked, passing +the name as the first argument and the value as the second argument. If the operation used to declare the named property setter +did not have an identifier, then the interface definition must be accompanied +by a description of how to set the value of an existing named property and how to set the value of a new named property for a given property name and value.

      +
    • +

      If a named property deleter was specified using an operation +with an identifier, +then the behavior that occurs when indexing the object for property deletion with a given supported property name +is the same as if the operation is invoked, passing +the name as the only argument. If the operation used to declare the named property deleter +did not have an identifier, then the interface definition must be accompanied +by a description of how to delete an existing named property for a given property name.

      +
    +

    Note: As with indexed properties, +if an named property getter, setter or deleter is specified using an operation with an identifier, +then indexing an object with a name that is not a supported property name does not necessarily elicit the same behavior as invoking the operation with that name; the behavior +is language binding specific.

    +

    3.2.5. Static attributes and operations

    +

    Static attributes and static operations are ones that +are not associated with a particular instance of the interface on which it is declared, and is instead associated with the interface +itself. Static attributes and operations are declared by using the static keyword in their declarations.

    +

    It is language binding specific whether it is possible to invoke +a static operation or get or set a static attribute through a reference +to an instance of the interface.

    +

    Static attributes and operations must not be +declared on callback interfaces.

    +
    StaticMember :
    +    "static" StaticMemberRest
    +
    +
    StaticMemberRest :
    +    ReadOnly AttributeRest
    +    ReturnType OperationRest
    +
    +
    + +

    The following IDL fragment defines an interface Circle that has a static + operation declared on it:

    +
    interface Point { /* ... */ };
    +        
    +interface Circle {
    +  attribute double cx;
    +  attribute double cy;
    +  attribute double radius;
    +        
    +  static readonly attribute long triangulationCount;
    +  static Point triangulate(Circle c1, Circle c2, Circle c3);
    +};
    +
    +

    In the ECMAScript language binding, the Function object for triangulate and the accessor property for triangulationCount will exist on the interface object for Circle:

    +
    var circles = getCircles();           // an Array of Circle objects
    +        
    +typeof Circle.triangulate;            // Evaluates to "function"
    +typeof Circle.triangulationCount;     // Evaluates to "number"
    +Circle.prototype.triangulate;         // Evaluates to undefined
    +Circle.prototype.triangulationCount;  // Also evaluates to undefined
    +circles[0].triangulate;               // As does this
    +circles[0].triangulationCount;        // And this
    +        
    +// Call the static operation
    +var triangulationPoint = Circle.triangulate(circles[0], circles[1], circles[2]);
    +        
    +// Find out how many triangulations we have done
    +window.alert(Circle.triangulationCount);
    +
    +

    3.2.6. Overloading

    +

    If a regular operation or static operation defined on an interface has an identifier that is the same as the identifier of another operation on that +interface of the same kind (regular or static), then the operation is said to be overloaded. When the identifier +of an overloaded operation is used to invoke one of the +operations on an object that implements the interface, the +number and types of the arguments passed to the operation +determine which of the overloaded operations is actually +invoked. If an interface has multiple legacy callers defined on it, +then those legacy callers are also said to be overloaded. +In the ECMAScript language binding, constructors can be overloaded too. There are some restrictions on the arguments +that overloaded operations, legacy callers and constructors can be +specified to take, and in order to describe these restrictions, +the notion of an effective overload set is used.

    +

    Operations and legacy callers must not be overloaded across interface and partial interface definitions.

    +
    +

    For example, the overloads for both f and g are disallowed:

    +
    interface A {
    +  void f();
    +};
    +        
    +partial interface A {
    +  void f(double x);
    +  void g();
    +};
    +        
    +partial interface A {
    +  void g(DOMString x);
    +};
    +
    +

    Note that the [Constructor] and + [NamedConstructor] extended attributes are disallowed from appearing + on partial interface definitions, + so there is no need to also disallow overloading for constructors.

    +
    +

    An effective overload set represents the allowable invocations for a particular operation, +constructor (specified with [Constructor] +or [NamedConstructor]), legacy caller or callback function. +The algorithm to compute an effective overload set operates on one of the following six types of IDL constructs, and listed with them below are +the inputs to the algorithm needed to compute the set.

    +
    +
    +

    For regular operations

    +
    +

    For static operations

    +
    + +
    +

    For legacy callers

    +
    + +
    +

    For constructors

    +
    + +
    +

    For named constructors

    +
    + +
    +

    For callback functions

    +
    + +
    +

    An effective overload set is used, among other things, to determine whether there are ambiguities in the +overloaded operations, constructors and callers specified on an interface.

    +

    The elements of an effective overload set are tuples of the form +<callable, type list, optionality list>. If the effective overload +set is for regular operations, static operations or legacy callers, then callable is an operation; +if it is for constructors or named constructors, then callable is an +extended attribute; and if it is for callback functions, then callable is the callback function itself. In all cases, type list is a list +of IDL types, and optionality list is a list of three possible optionality values – +“required”, “optional” or “variadic” – indicating whether +the argument at a given index was declared as being optional or corresponds to a variadic argument. +Each tuple represents an allowable invocation of the operation, +constructor, legacy caller or callback function with an argument value list of the given types. +Due to the use of optional arguments and variadic operations +and constructors, there may be multiple entries in an effective overload set identifying +the same operation or constructor.

    +

    The algorithm below describes how to compute an effective overload set. +The following input variables are used, if they are required:

    +
      +
    • +

      the identifier of the operation or named constructor is A

      +
    • +

      the argument count is N

      +
    • +

      the interface is I

      +
    • +

      the callback function is C

      +
    +

    Whenever an argument of an extended +attribute is mentioned, it is referring to an argument of the +extended attribute’s named argument list.

    +
      +
    1. +

      Initialize S to ∅.

      +
    2. +

      Let F be a set with elements as follows, according to the kind of effective overload set:

      +
      +
      +

      For regular operations

      +
      +

      The elements of F are the regular operations with +identifier A defined on interface I.

      +
      +

      For static operations

      +
      +

      The elements of F are the static operations with +identifier A defined on interface I.

      +
      +

      For constructors

      +
      +

      The elements of F are the +[Constructor] extended attributes on interface I.

      +
      +

      For named constructors

      +
      +

      The elements of F are the +[NamedConstructor] extended attributes on interface I whose named argument lists’ identifiers are A.

      +
      +

      For legacy callers

      +
      +

      The elements of F are the legacy callers defined on interface I.

      +
      +

      For callback functions

      +
      +

      The single element of F is the callback function itself, C.

      +
      +
    3. +

      Let maxarg be the maximum number of arguments the operations, constructor extended attributes or callback functions in F are declared to take. +For variadic operations and constructor extended attributes, +the argument on which the ellipsis appears counts as a single argument.

      +

      Note: So void f(long x, long... y); is considered to be declared to take two arguments.

      +
    4. +

      Let m be the maximum of maxarg and N.

      +
    5. +

      For each operation, extended attribute or callback function X in F:

      +
        +
      1. +

        Let n be the number of arguments X is declared to take.

        +
      2. +

        Let t0..n−1 be a list of types, where ti is the type of X’s argument at index i.

        +
      3. +

        Let o0..n−1 be a list of optionality values, where oi is “variadic” if X’s argument at index i is a final, variadic argument, +“optional” if the argument is optional, +and “required” otherwise.

        +
      4. +

        Add to S the tuple <X, t0..n−1, o0..n−1>.

        +
      5. +

        If X is declared to be variadic, then:

        +
          +
        1. +

          For every integer i, such that nim−1:

          +
            +
          1. +

            Let u0..i be a list of types, where uj = tj (for j < n) and uj = tn−1 (for jn).

            +
          2. +

            Let p0..i be a list of optionality values, where pj = oj (for j < n) and pj = “variadic” (for jn).

            +
          3. +

            Add to S the tuple <X, u0..i, p0..i>.

            +
          +
        +
      6. +

        Initialize i to n−1.

        +
      7. +

        While i ≥ 0:

        +
          +
        1. +

          If argument i of X is not optional (i.e., it is not marked as optional and is not +a final, variadic argument), then break this loop.

          +
        2. +

          Otherwise, add to S the tuple <X, t0..i−1, o0..i−1>.

          +
        3. +

          Set i to i−1.

          +
        +
      +
    6. +

      The effective overload set is S.

      +
    +
    + +

    For the following interface:

    +
    interface A {
    +  /* f1 */ void f(DOMString a);
    +  /* f2 */ void f(Node a, DOMString b, double... c);
    +  /* f3 */ void f();
    +  /* f4 */ void f(Event a, DOMString b, optional DOMString c, double... d);
    +};
    +
    +

    assuming Node and Event are two other interfaces of which no object can implement both, + the effective overload set for regular operations with + identifier f and argument count 4 is:

    +
    { <f1, (DOMString), (required)>,
    +  <f2, (Node, DOMString), (required, required)>,
    +  <f2, (Node, DOMString, double), (required, required, variadic)>,
    +  <f2, (Node, DOMString, double, double), (required, required, variadic, variadic)>,
    +  <f3, (), ()>,
    +  <f4, (Event, DOMString), (required, required)>,
    +  <f4, (Event, DOMString, DOMString), (required, required, optional)>,
    +  <f4, (Event, DOMString, DOMString, double), (required, required, optional, variadic)> }
    +
    +
    +

    Two types are distinguishable if +at most one of the two includes a nullable type or is a dictionary type, +and at least one of the following three conditions is true:

    +
      +
    1. +

      The two types (taking their inner types if they are nullable types) appear +in the following table and there is a “●” mark in the corresponding entry +or there is a letter in the corresponding entry and the designated additional +requirement below the table is satisfied:

      + + + + + + + + + + + + + + + +
      + +
      boolean
      +
      +
      numeric types
      +
      +
      string types
      +
      +
      interface
      +
      +
      object
      +
      +
      callback function
      +
      +
      dictionary
      +
      +
      sequence<T>
      +
      +
      FrozenArray<T>
      +
      +
      RegExp
      +
      +
      exception types
      +
      +
      buffer source types
      +
      boolean + + ● + ● + ● + ● + ● + ● + ● + ● + ● + ● + ● +
      numeric types + + + ● + ● + ● + ● + ● + ● + ● + ● + ● + ● +
      string types + + + + ● + ● + ● + ● + ● + ● + ● + ● + ● +
      interface + + + + (a) + + (b) + (b) + ● + ● + ● + ● + ● +
      object + + + + + + + + + + + + +
      callback function + + + + + + + + ● + ● + ● + ● + ● +
      dictionary + + + + + + + + ● + ● + ● + ● + ● +
      sequence<T> + + + + + + + + + + ● + ● + ● +
      FrozenArray<T> + + + + + + + + + + ● + ● + ● +
      RegExp + + + + + + + + + + + ● + ● +
      exception types + + + + + + + + + + + + ● +
      buffer source types + + + + + + + + + + + + +
      +
        +
      1. +

        The two identified interfaces are +not the same, it is not possible for a single platform object to implement both interfaces, +and it is not the case that both are callback interfaces.

        +
      2. +

        The interface type is not a callback interface.

        +
      +
    2. +

      One type is a union type or nullable union type, +the other is neither a union type nor a nullable union type, and each member type of the first is distinguishable +with the second.

      +
    3. +

      Both types are either a union type or nullable union type, and each member type of the one +is distinguishable with each member type of the other.

      +
    +

    Note: Promise types do not appear in the above table, and as a consequence +are not distinguishable with any other type.

    +

    If there is more than one entry in an effective overload set that has a given type list length, then for those entries there +must be an index i such +that for each pair of entries the types at index i are distinguishable. +The lowest such index is termed the distinguishing argument index for the entries of the effective overload set with the given type list length.

    +
    + +

    Consider the effective overload set shown in the previous example. + There are multiple entries in the set with type lists 2, 3 and 4. + For each of these type list lengths, the distinguishing argument index is 0, since Node and Event are distinguishable.

    +

    The following use of overloading however is invalid:

    +
    interface B {
    +  void f(DOMString x);
    +  void f(double x);
    +};
    +
    +

    since DOMString and double are not distinguishable.

    +
    +

    In addition, for each index j, where j is less than the distinguishing argument index for a given type list length, the types at index j in +all of the entries’ type lists must be the same +and the booleans in the corresponding list indicating argument optionality must +be the same.

    +
    + +

    The following is invalid:

    +
    interface B {
    +  /* f1 */ void f(DOMString w);
    +  /* f2 */ void f(long w, double x, Node y, Node z);
    +  /* f3 */ void f(double w, double x, DOMString y, Node z);
    +};
    +
    +

    For argument count 4, the effective overload set is:

    +
    { <f1, (DOMString), (required)>,
    +  <f2, (long, double, Node, Node), (required, required, required, required)>,
    +  <f3, (double, double, DOMString, Node), (required, required, required, required)> }
    +
    +

    Looking at entries with type list length 4, the distinguishing argument index is 2, since Node and DOMString are distinguishable. + However, since the arguments in these two overloads at index 0 are different, + the overloading is invalid.

    +
    +

    3.2.7. Iterable declarations

    +

    An interface can be declared to be iterable by using an iterable declaration (matching Iterable) in the body of the interface.

    +
    interface interface_identifier {
    +  iterable<value_type>;
    +  iterable<key_type, value_type>;
    +};
    +
    +

    Objects implementing an interface that is declared to be iterable +support being iterated over to obtain a sequence of values.

    +

    Note: In the ECMAScript language binding, an interface that is iterable +will have “entries”, “forEach”, “keys”, “values” and @@iterator properties on its interface prototype object.

    +

    If a single type parameter is given, then the interface has a value iterator and provides +values of the specified type. +If two type parameters are given, then the interface has a pair iterator and provides +value pairs, where the first value is a key and the second is the +value associated with the key.

    +

    A value iterator must only be declared on an interface +that supports indexed properties and has an integer-typed attribute named “length”. +The value-type of the value iterator must be the same as the type returned by +the indexed property getter. +A value iterator is implicitly +defined to iterate over the object’s indexed properties.

    +

    A pair iterator must not be declared on an interface +that supports indexed properties. +Prose accompanying an interface with a pair iterator must define what the list of value pairs to iterate over is.

    +
    +

    The ECMAScript forEach method that is generated for a value iterator invokes its callback like Array.prototype.forEach does, and the forEach + method for a pair iterator invokes its callback like Map.prototype.forEach does.

    +

    Since value iterators are currently allowed only on interfaces that support indexed properties, + it makes sense to use an Array-like forEach method. + There may be a need for value iterators (a) on interfaces that do not support indexed properties, + or (b) with a forEach method that instead invokes its callback like + Set.protoype.forEach (where the key is the same as the value). + If you’re creating an API that needs such a forEach method, please send a request to public-script-coord@w3.org.

    +
    +

    Note: This is how array iterator objects work. +For interfaces that support indexed properties, +the iterator objects returned by “entries”, “keys”, “values” and @@iterator are +actual array iterator objects.

    +

    Interfaces with iterable declarations must not +have any interface members named “entries”, “forEach”, “keys” or “values”, +or have any inherited or consequential interfaces that have interface members with these names.

    +
    + +

    Consider the following interface SessionManager, which allows access to + a number of Session objects:

    +
    interface SessionManager {
    +  Session getSessionForUser(DOMString username);
    +  readonly attribute unsigned long sessionCount;
    +        
    +  iterable<Session>;
    +};
    +        
    +interface Session {
    +  readonly attribute DOMString username;
    +  // ...
    +};
    +
    +

    The behavior of the iterator could be defined like so:

    +
    +

    The values to iterate over are the open Session objects + on the SessionManager sorted by username.

    +

    Fix reference to removed definition for "values to iterate over".

    +
    +

    In the ECMAScript language binding, the interface prototype object for the SessionManager interface has a values method that is a function, which, when invoked, + returns an iterator object that itself has a next method that returns the + next value to be iterated over. It has values and entries methods that iterate over the indexes of the list of session objects + and [index, session object] pairs, respectively. It also has + a @@iterator method that allows a SessionManager to be used in a for..of loop:

    +
    // Get an instance of SessionManager.
    +// Assume that it has sessions for two users, "anna" and "brian".
    +var sm = getSessionManager();
    +        
    +typeof SessionManager.prototype.values;            // Evaluates to "function"
    +var it = sm.values();                              // values() returns an iterator object
    +String(it);                                        // Evaluates to "[object SessionManager Iterator]"
    +typeof it.next;                                    // Evaluates to "function"
    +        
    +// This loop will alert "anna" and then "brian".
    +for (;;) {
    +  let result = it.next();
    +  if (result.done) {
    +    break;
    +  }
    +  let session = result.value;
    +  window.alert(session.username);
    +}
    +        
    +// This loop will also alert "anna" and then "brian".
    +for (let session of sm) {
    +  window.alert(session.username);
    +}
    +
    +

    An interface must not have more than one iterable declaration. +The inherited and consequential interfaces of an interface with an iterable declaration must not also have an iterable declaration. +An interface with an iterable declaration and its inherited and consequential interfaces must not have a maplike declaration or setlike declaration.

    +

    The following extended attributes are applicable to iterable declarations: +[Exposed], +[SecureContext].

    +
    Iterable :
    +    "iterable" "<" Type OptionalType ">" ";"
    +
    +
    OptionalType :
    +    "," Type
    +    ε
    +
    +

    3.2.8. Maplike declarations

    +

    An interface can be declared to be maplike by using a maplike declaration (matching ReadWriteMaplike or readonly MaplikeRest) in the body of the interface.

    +
    interface interface_identifier {
    +  readonly maplike<key_type, value_type>;
    +  maplike<key_type, value_type>;
    +};
    +
    +

    Objects implementing an interface that is declared to be maplike +represent an ordered list of key–value pairs known as its map entries. +The types used for the keys and values are given in the angle +brackets of the maplike declaration. Keys are required to be unique.

    +

    The map entries of an object +implementing a maplike interface is empty at +the of the object’s creation. Prose accompanying the interface can +describe how the map entries of an object change.

    +

    Maplike interfaces support an API for querying the map entries +appropriate for the language binding. If the readonly keyword is not used, then it also supports an API for modifying +the map entries.

    +

    Note: In the ECMAScript language binding, the API for interacting +with the map entries is similar to that available on ECMAScript Map objects. If the readonly keyword is used, this includes “entries”, “forEach”, “get”, “has”, +“keys”, “values”, @@iterator methods and a “size” getter. +For read–write maplikes, it also includes “clear”, “delete” and +“set” methods.

    +

    Maplike interfaces must not +have any interface members named “entries”, “forEach”, “get”, “has”, “keys”, “size”, or “values”, +or have any inherited or consequential interfaces that have interface members with these names. +Read–write maplike interfaces must not +have any attributes or constants named +“clear”, “delete”, or “set”, or have any inherited or consequential interfaces that have attributes or constants with these names.

    +

    Note: Operations named “clear”, “delete”, or “set” are allowed on read–write maplike +interfaces and will prevent the default implementation of these methods being +added to the interface prototype object in the ECMAScript language binding. +This allows the default behavior of these operations to be overridden.

    +

    An interface must not have more than one maplike declaration. +The inherited and consequential interfaces of a maplike interface must not +also have a maplike declaration. +A maplike interface and its inherited and consequential interfaces must not have an iterable declaration or setlike declaration.

    +
    +
    +
    ReadWriteMaplike :
    +    MaplikeRest
    +
    +
    MaplikeRest :
    +    "maplike" "<" Type "," Type ">" ";"
    +
    +

    No extended attributes defined in this specification are applicable to maplike declarations.

    +

    Add example.

    +

    3.2.9. Setlike declarations

    +

    An interface can be declared to be setlike by using a setlike declaration (matching ReadWriteSetlike or readonly SetlikeRest) in the body of the interface.

    +
    interface interface_identifier {
    +  readonly setlike<type>;
    +  setlike<type>;
    +};
    +
    +

    Objects implementing an interface that is declared to be setlike +represent an ordered list of values known as its set entries. +The type of the values is given in the angle +brackets of the setlike declaration. Values are required to be unique.

    +

    The set entries of an object +implementing a setlike interface is empty at +the of the object’s creation. Prose accompanying the interface can +describe how the set entries of an object change.

    +

    Setlike interfaces support an API for querying the set entries +appropriate for the language binding. If the readonly keyword is not used, then it also supports an API for modifying +the set entries.

    +

    Note: In the ECMAScript language binding, the API for interacting +with the set entries is similar to that available on ECMAScript Set objects. If the readonly keyword is used, this includes “entries”, “forEach”, “has”, +“keys”, “values”, @@iterator methods and a “size” getter. +For read–write setlikes, it also includes “add”, “clear”, and “delete” methods.

    +

    Setlike interfaces must not +have any interface members named “entries”, “forEach”, “has”, “keys”, “size”, or “values”, +or have any inherited or consequential interfaces that have interface members with these names.. +Read–write setlike interfaces must not +have any attributes or constants named +“add”, “clear”, or “delete”, or have any inherited or consequential interfaces that have attributes or constants with these names.

    +

    Note: Operations named “add”, “clear”, or “delete” are allowed on read–write setlike +interfaces and will prevent the default implementation of these methods being +added to the interface prototype object in the ECMAScript language binding. +This allows the default behavior of these operations to be overridden.

    +

    An interface must not have more than one setlike declaration. +The inherited and consequential interfaces of a setlike interface must not +also have a setlike declaration. +A setlike interface and its inherited and consequential interfaces must not have an iterable declaration or maplike declaration.

    +
    +
    +
    ReadWriteSetlike :
    +    SetlikeRest
    +
    +
    SetlikeRest :
    +    "setlike" "<" Type ">" ";"
    +
    +

    No extended attributes defined in this specification are applicable to setlike declarations.

    +

    Add example.

    +

    3.3. Namespaces

    +

    A namespace is a definition (matching Namespace) that declares a global singleton with +associated behaviors.

    +
    namespace identifier {
    +  /* namespace_members... */
    +};
    +
    +

    A namespace is a specification of a set of namespace members (matching NamespaceMembers), which are the regular operations that appear between the braces in +the namespace declaration. These operations describe the behaviors packaged into the +namespace.

    +

    As with interfaces, the IDL for namespaces can be split into multiple parts by using partial namespace definitions +(matching partial Namespace). The identifier of a partial namespace definition must be the same as the identifier of a namespace definition. +All of the members that appear on each of the partial namespace definitions are +considered to be members of the namespace itself.

    +
    namespace SomeNamespace {
    +  /* namespace_members... */
    +};
    +    
    +partial namespace SomeNamespace {
    +  /* namespace_members... */
    +};
    +
    +

    Note: As with partial interface definitions, partial namespace definitions are intended for +use as a specification editorial aide, allowing the definition of a namespace to be +separated over more than one section of the document, and sometimes multiple +documents.

    +

    The order that members appear in has significance for property enumeration in the ECMAScript binding.

    +

    Note that unlike interfaces or dictionaries, namespaces do not create types.

    +

    Of the extended attributes defined in this specification, only the [Exposed] and [SecureContext] extended attributes are applicable to +namespaces.

    +
    +
    +
    Namespace :
    +    "namespace" identifier "{" NamespaceMembers "}" ";"
    +
    +
    NamespaceMembers :
    +    ExtendedAttributeList NamespaceMember NamespaceMembers
    +    ε
    +
    +
    NamespaceMember :
    +    ReturnType OperationRest
    +
    +
    + +

    The following IDL fragment defines an namespace.

    +
    namespace VectorUtils {
    +  double dotProduct(Vector x, Vector y);
    +  Vector crossProduct(Vector x, Vector y);
    +};
    +
    +

    An ECMAScript implementation would then expose a global property named VectorUtils which was a simple object (with prototype %ObjectPrototype%) with enumerable data properties for each declared operation:

    +
    Object.getPrototypeOf(VectorUtils);                         // Evaluates to Object.prototype.
    +Object.keys(VectorUtils);                                   // Evaluates to ["dotProduct", "crossProduct"].
    +Object.getOwnPropertyDescriptor(VectorUtils, "dotProduct"); // Evaluates to { value: <a function>, enumerable: true, configurable: true, writable: true }.
    +
    +

    3.4. Dictionaries

    +

    A dictionary is a definition (matching Dictionary) +used to define an associative array data type with a fixed, ordered set of key–value pairs, +termed dictionary members, +where keys are strings and values are of a particular type specified in the definition.

    +
    dictionary identifier {
    +  /* dictionary_members... */
    +};
    +
    +

    Dictionaries are always passed by value. In language bindings where a dictionary is represented by an object of some kind, passing a +dictionary to a platform object will not result in a reference to the dictionary being kept by that object. +Similarly, any dictionary returned from a platform object will be a copy and modifications made to it will not be visible to the platform object.

    +

    A dictionary can be defined to inherit from another dictionary. +If the identifier of the dictionary is followed by a colon and a identifier, +then that identifier identifies the inherited dictionary. The identifier +must identify a dictionary.

    +

    A dictionary must not be declared such that +its inheritance hierarchy has a cycle. That is, a dictionary A cannot inherit from itself, nor can it inherit from another +dictionary B that inherits from A, and so on.

    +
    dictionary Base {
    +  /* dictionary_members... */
    +};
    +    
    +dictionary Derived : Base {
    +  /* dictionary_members... */
    +};
    +
    +

    The inherited dictionaries of +a given dictionary D is the set of all dictionaries that D inherits from, directly or indirectly. If D does not inherit from another dictionary, then the set is empty. Otherwise, the set +includes the dictionary E that D inherits from and all of E’s inherited dictionaries.

    +

    A dictionary value of type D can have key–value pairs corresponding +to the dictionary members defined on D and on any of D’s inherited dictionaries. +On a given dictionary value, the presence of each dictionary member +is optional, unless that member is specified as required. +When specified in the dictionary value, a dictionary member is said to be present, otherwise it is not present. +Dictionary members can also optionally have a default value, which is +the value to use for the dictionary member when passing a value to a platform object that does +not have a specified value. Dictionary members with default values are +always considered to be present.

    +

    As with operation argument default values, + is strongly suggested not to use of true as the default value for boolean-typed dictionary members, + as this can be confusing for authors who might otherwise expect the default + conversion of undefined to be used (i.e., false).

    +

    Each dictionary member (matching DictionaryMember) is specified +as a type (matching Type) followed by an identifier (given by an identifier token following +the type). The identifier is the key name of the key–value pair. +If the Type is an identifier followed by ?, then the identifier +must identify an +interface, enumeration, callback function or typedef. +If the dictionary member type is an identifier +not followed by ?, then the identifier must +identify any one of those definitions or a dictionary.

    +
    dictionary identifier {
    +  type identifier;
    +};
    +
    +

    If the identifier is followed by a U+003D EQUALS SIGN ("=") and a value (matching DefaultValue), +then that gives the dictionary member its default value.

    +
    dictionary identifier {
    +  type identifier = "value";
    +};
    +
    +

    When a boolean literal token (true or false), +the null token, +an integer token, a float token, +one of the three special floating point literal values (Infinity, -Infinity or NaN), +a string token or +the two token sequence [] used as the default value, +it is interpreted in the same way as for an operation’s optional argument default value.

    +

    If the type of the dictionary member is an enumeration, then its default value if specified must +be one of the enumeration’s values.

    +

    If the type of the dictionary member is preceded by the required keyword, the member is considered a required dictionary member and must be present on the dictionary. A required dictionary member must not have a default value.

    +
    dictionary identifier {
    +  required type identifier;
    +};
    +
    +

    The type of a dictionary member must not include +the dictionary it appears on. A type includes a dictionary D if at least one of the following is true:

    + +

    As with interfaces, the IDL for dictionaries can be split into multiple parts +by using partial dictionary definitions +(matching partial Dictionary). +The identifier of a partial +dictionary definition must be the same as the +identifier of a dictionary definition. All of the members that appear on each +of the partial dictionary definitions are considered to be members of +the dictionary itself.

    +
    dictionary SomeDictionary {
    +  /* dictionary_members... */
    +};
    +    
    +partial dictionary SomeDictionary {
    +  /* dictionary_members... */
    +};
    +
    +

    Note: As with partial interface definitions, partial dictionary definitions are intended for use as a specification +editorial aide, allowing the definition of an interface to be separated +over more than one section of the document, and sometimes multiple documents.

    +

    The order of the dictionary members on a given dictionary is such that inherited dictionary members are ordered +before non-inherited members, and the dictionary members on the one +dictionary definition (including any partial dictionary definitions) are +ordered lexicographically by the Unicode codepoints that comprise their +identifiers.

    +
    +

    For example, with the following definitions:

    +
    dictionary B : A {
    +  long b;
    +  long a;
    +};
    +        
    +dictionary A {
    +  long c;
    +  long g;
    +};
    +        
    +dictionary C : B {
    +  long e;
    +  long f;
    +};
    +        
    +partial dictionary A {
    +  long h;
    +  long d;
    +};
    +
    +

    the order of the dictionary members of a dictionary value of type C is + c, d, g, h, a, b, e, f.

    +

    Dictionaries are required to have their members ordered because + in some language bindings the behavior observed when passing + a dictionary value to a platform object depends on the order + the dictionary members are fetched. For example, consider the + following additional interface:

    +
    interface Something {
    +  void f(A a);
    +};
    +
    +

    and this ECMAScript code:

    +
    var something = getSomething();  // Get an instance of Something.
    +var x = 0;
    +        
    +var dict = { };
    +Object.defineProperty(dict, "d", { get: function() { return ++x; } });
    +Object.defineProperty(dict, "c", { get: function() { return ++x; } });
    +        
    +something.f(dict);
    +

    The order that the dictionary members are fetched in determines + what values they will be taken to have. Since the order for A is defined to be c then d, + the value for c will be 1 and the value for d will be 2.

    +
    +

    The identifier of a dictionary member must not be +the same as that of another dictionary member defined on the dictionary or +on that dictionary’s inherited dictionaries.

    +

    Dictionaries must not be used as the type of an attribute or constant.

    +

    The following extended attributes are applicable to dictionaries: +[Constructor], +[Exposed], +[SecureContext],

    +

    The following extended attributes are applicable to dictionary members: +[Clamp], +[EnforceRange].

    +
    +
    +
    Dictionary :
    +    "dictionary" identifier Inheritance "{" DictionaryMembers "}" ";"
    +
    +
    DictionaryMembers :
    +    ExtendedAttributeList DictionaryMember DictionaryMembers
    +    ε
    +
    +
    DictionaryMember :
    +    Required Type identifier Default ";"
    +
    +
    Required :
    +    "required"
    +    ε
    +
    +
    PartialDictionary :
    +    "dictionary" identifier "{" DictionaryMembers "}" ";"
    +
    +
    Default :
    +    "=" DefaultValue
    +    ε
    +
    +
    +
    +
    + +

    One use of dictionary types is to allow a number of optional arguments to + an operation without being + constrained as to the order they are specified at the call site. For example, + consider the following IDL fragment:

    +
    [Constructor]
    +interface Point {
    +  attribute double x;
    +  attribute double y;
    +};
    +        
    +dictionary PaintOptions {
    +  DOMString? fillPattern = "black";
    +  DOMString? strokePattern = null;
    +  Point position;
    +};
    +        
    +interface GraphicsContext {
    +  void drawRectangle(double width, double height, optional PaintOptions options);
    +};
    +
    +

    In an ECMAScript implementation of the IDL, an Object can be passed in for the optional PaintOptions dictionary:

    +
    // Get an instance of GraphicsContext.
    +var ctx = getGraphicsContext();
    +        
    +// Draw a rectangle.
    +ctx.drawRectangle(300, 200, { fillPattern: "red", position: new Point(10, 10) });
    +

    Both fillPattern and strokePattern are given default values, + so if they are omitted, the definition of drawRectangle can assume that they + have the given default values and not include explicit wording to handle + their non-presence.

    +
    +

    3.5. Exceptions

    +

    An exception is a type of object that +represents an error and which can be thrown or treated as a first +class value by implementations. Web IDL does not allow exceptions +to be defined, but instead has a number of pre-defined exceptions +that specifications can reference and throw in their definition of +operations, attributes, and so on. Exceptions have an error name, +a DOMString, +which is the type of error the exception represents, and a message, which is an optional, +user agent-defined value that provides human readable details of the error.

    +

    There are two kinds of exceptions available to be thrown from specifications. +The first is a simple exception, which +is identified by one of the following names:

    +
      +
    • +

      "Error"

      +
    • +

      "EvalError"

      +
    • +

      "RangeError"

      +
    • +

      "ReferenceError"

      +
    • +

      "TypeError"

      +
    • +

      "URIError"

      +
    +

    These correspond to all of the ECMAScript error objects (apart from SyntaxError, which is deliberately omitted as +it is for use only by the ECMAScript parser). +The meaning of +each simple exception matches +its corresponding Error object in the +ECMAScript specification.

    +

    The second kind of exception is a DOMException, +which is an exception that encapsulates a name and an optional integer code, +for compatibility with historically defined exceptions in the DOM.

    +

    For simple exceptions, +the error name is the name +of the exception. +For a DOMException, +the error name must +be one of the names listed in the error names table below. The table also indicates the DOMException's integer code +for that error name, if it has one.

    +

    There are two types that can be used to refer to +exception objects: Error, which encompasses all exceptions, +and DOMException which includes just DOMException objects. +This allows for example an operation to be declared to have a DOMException return type or an attribute to be of type Error.

    +

    Exceptions can be created by providing its error name. +Exceptions can also be thrown, by providing the +same details required to create one.

    +

    The resulting behavior from creating and throwing an exception is language binding-specific.

    +

    Note: See §4.14 Creating and throwing exceptions for details on what creating and throwing an exception +entails in the ECMAScript language binding.

    +
    + +

    Here is are some examples of wording to use to create and throw exceptions. + To throw a new simple exception named TypeError:

    +
    +

    Throw a TypeError.

    +
    +

    To throw a new DOMException with error name IndexSizeError:

    +
    +

    Throw an IndexSizeError.

    +
    +

    To create a new DOMException with error name SyntaxError:

    +
    +

    Let object be a newly created SyntaxError.

    +
    +
    +

    3.5.1. Error names

    +

    The error names table below lists all the allowed error names +for DOMExceptions, a description, +and legacy code values.

    +

    Note: If an error name is not listed here, please file a bug as indicated at the top of this specification and it will be addressed shortly. Thanks!

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Name + Description + Legacy code name and value +
    "IndexSizeError" + The index is not in the allowed range. + INDEX_SIZE_ERR (1) +
    "HierarchyRequestError" + The operation would yield an incorrect node tree. + HIERARCHY_REQUEST_ERR (3) +
    "WrongDocumentError" + The object is in the wrong document. + WRONG_DOCUMENT_ERR (4) +
    "InvalidCharacterError" + The string contains invalid characters. + INVALID_CHARACTER_ERR (5) +
    "NoModificationAllowedError" + The object can not be modified. + NO_MODIFICATION_ALLOWED_ERR (7) +
    "NotFoundError" + The object can not be found here. + NOT_FOUND_ERR (8) +
    "NotSupportedError" + The operation is not supported. + NOT_SUPPORTED_ERR (9) +
    "InUseAttributeError" + The attribute is in use. + INUSE_ATTRIBUTE_ERR (10) +
    "InvalidStateError" + The object is in an invalid state. + INVALID_STATE_ERR (11) +
    "SyntaxError" + The string did not match the expected pattern. + SYNTAX_ERR (12) +
    "InvalidModificationError" + The object can not be modified in this way. + INVALID_MODIFICATION_ERR (13) +
    "NamespaceError" + The operation is not allowed by Namespaces in XML. [XML-NAMES] + NAMESPACE_ERR (14) +
    "InvalidAccessError" + The object does not support the operation or argument. + INVALID_ACCESS_ERR (15) +
    "SecurityError" + The operation is insecure. + SECURITY_ERR (18) +
    "NetworkError" + A network error occurred. + NETWORK_ERR (19) +
    "AbortError" + The operation was aborted. + ABORT_ERR (20) +
    "URLMismatchError" + The given URL does not match another URL. + URL_MISMATCH_ERR (21) +
    "QuotaExceededError" + The quota has been exceeded. + QUOTA_EXCEEDED_ERR (22) +
    "TimeoutError" + The operation timed out. + TIMEOUT_ERR (23) +
    "InvalidNodeTypeError" + The supplied node is incorrect or has an incorrect ancestor for this operation. + INVALID_NODE_TYPE_ERR (24) +
    "DataCloneError" + The object can not be cloned. + DATA_CLONE_ERR (25) +
    "EncodingError" + The encoding operation (either encoded or decoding) failed. + — +
    "NotReadableError" + The I/O read operation failed. + — +
    "UnknownError" + The operation failed for an unknown transient reason (e.g. out of memory). + — +
    "ConstraintError" + A mutation operation in a transaction failed because a constraint was not satisfied. + — +
    "DataError" + Provided data is inadequate. + — +
    "TransactionInactiveError" + A request was placed against a transaction which is currently not active, or which is finished. + — +
    "ReadOnlyError" + The mutating operation was attempted in a "readonly" transaction. + — +
    "VersionError" + An attempt was made to open a database using a lower version than the existing version. + — +
    "OperationError" + The operation failed for an operation-specific reason. + — +
    "NotAllowedError" + The request is not allowed by the user agent or the platform in the current context, possibly because the user denied permission. + — +
    +

    3.6. Enumerations

    +

    An enumeration is a definition (matching Enum) used to declare a type +whose valid values are a set of predefined strings. Enumerations +can be used to restrict the possible DOMString values that can be assigned to an attribute or passed to an operation.

    +
    enum identifier { "enum", "values" /* , ... */ };
    +

    The enumeration values are specified +as a comma-separated list of string literals. +The list of enumeration values must not include duplicates.

    +

    It is strongly suggested that enumeration values be all lowercase, + and that multiple words be separated using dashes or not be + separated at all, unless there is a specific reason to use another + value naming scheme. For example, an enumeration value that + indicates an object should be created could be named "createobject" or "create-object". + Consider related uses of enumeration values when deciding whether + to dash-separate or not separate enumeration value words so that + similar APIs are consistent.

    +

    The behavior when a string value that is not one a valid enumeration value +is used when assigning to an attribute, +or passed as an operation argument, +whose type is the enumeration, is language binding specific.

    +

    Note: In the ECMAScript binding, assignment of an invalid string value to an attribute is ignored, while +passing such a value as an operation argument +results in an exception being thrown.

    +

    No extended attributes defined in this specification are applicable to enumerations.

    +
    Enum :
    +    "enum" identifier "{" EnumValueList "}" ";"
    +
    +
    EnumValueList :
    +    string EnumValueListComma
    +
    +
    EnumValueListComma :
    +    "," EnumValueListString
    +    ε
    +
    +
    EnumValueListString :
    +    string EnumValueListComma
    +    ε
    +
    +
    + +

    The following IDL fragment defines an enumeration that is used as the type of an attribute and an operation argument:

    +
    enum MealType { "rice", "noodles", "other" };
    +        
    +interface Meal {
    +  attribute MealType type;
    +  attribute double size;     // in grams
    +        
    +  void initialize(MealType type, double size);
    +};
    +
    +

    An ECMAScript implementation would restrict the strings that can be + assigned to the type property or passed to the initializeMeal function + to those identified in the enumeration.

    +
    var meal = getMeal();                // Get an instance of Meal.
    +        
    +meal.initialize("rice", 200);        // Operation invoked as normal.
    +        
    +try {
    +  meal.initialize("sandwich", 100);  // Throws a TypeError.
    +} catch (e) {
    +}
    +        
    +meal.type = "noodles";               // Attribute assigned as normal.
    +meal.type = "dumplings";             // Attribute assignment ignored.
    +meal.type == "noodles";              // Evaluates to true.
    +
    +

    3.7. Callback functions

    +

    The “Custom DOM Elements” spec wants to use callback function types for + platform object provided functions. Should we rename “callback functions” to + just “functions” to make it clear that they can be used for both purposes?

    +

    A callback function is a definition (matching callback CallbackRest) used to declare a function type.

    +
    callback identifier = return_type (/* arguments... */);
    +

    Note: See also the similarly named callback interfaces.

    +

    The identifier on the +left of the equals sign gives the name of the callback function and the return type and argument list (matching ReturnType and ArgumentList) on the right side of the equals +sign gives the signature of the callback function type.

    +

    Callback functions must not +be used as the type of a constant.

    +

    The following extended attribute is applicable to callback functions: +[TreatNonObjectAsNull].

    +
    +
    +
    CallbackRest :
    +    identifier "=" ReturnType "(" ArgumentList ")" ";"
    +
    +
    + +

    The following IDL fragment defines + a callback function used for an API that + invokes a user-defined function when an operation is complete.

    +
    callback AsyncOperationCallback = void (DOMString status);
    +        
    +interface AsyncOperations {
    +  void performOperation(AsyncOperationCallback whenFinished);
    +};
    +
    +

    In the ECMAScript language binding, a Function object is + passed as the operation argument.

    +
    var ops = getAsyncOperations();  // Get an instance of AsyncOperations.
    +        
    +ops.performOperation(function(status) {
    +  window.alert("Operation finished, status is " + status + ".");
    +});
    +
    +

    3.8. Typedefs

    +

    A typedef is a definition (matching Typedef) +used to declare a new name for a type. This new name is not exposed +by language bindings; it is purely used as a shorthand for referencing +the type in the IDL.

    +
    typedef type identifier;
    +

    The type being given a new name is specified after the typedef keyword (matching Type), and the identifier token following the +type gives the name.

    +

    The Type must not +identify the same or another typedef.

    +

    No extended attributes defined in this specification are applicable to typedefs.

    +
    Typedef :
    +    "typedef" Type identifier ";"
    +
    +
    + +

    The following IDL fragment demonstrates the use of typedefs to allow the use of a short identifier instead of a long sequence type.

    +
    interface Point {
    +  attribute double x;
    +  attribute double y;
    +};
    +        
    +typedef sequence<Point> Points;
    +        
    +interface Widget {
    +  boolean pointWithinBounds(Point p);
    +  boolean allPointsWithinBounds(Points ps);
    +};
    +
    +
    +

    3.9. Implements statements

    +

    An implements statement is a definition +(matching ImplementsStatement) +used to declare that all objects implementing an interface A (identified by the first identifier) +must additionally implement interface B (identified by the second identifier), including all other interfaces that B inherits from.

    +
    identifier_A implements identifier_B;
    +

    Transitively, if objects implementing B are declared with an implements statement to additionally implement interface C, then all objects implementing A do additionally implement interface C.

    +

    The two identifiers must +identify two different interfaces.

    +

    The interface identified on the left-hand side of an implements statement +must not inherit from the interface identifier on the right-hand side, and vice versa. Both identified +interfaces also must not be callback interfaces.

    +

    If each implements statement is +considered to be an edge in a directed graph, from a node representing the interface +on the left-hand side of the statement to a node representing the interface on the +right-hand side, then this graph must not have any cycles.

    +

    Interfaces that a given object implements are partitioned into those that are considered supplemental interfaces and those that are not. +An interface A is considered to be a supplemental interface of an object O if:

    +
      +
    • +

      O implements a different interface B, and the IDL states that B implements A; or

      +
    • +

      O implements a different supplemental interface C, and C inherits from A.

      +
    +
    +

    Specification authors are discouraged from writing implements statements where the interface on the left-hand side + is a supplemental interface. + For example, if author 1 writes:

    +
    interface Window { /* ... */ };
    +interface SomeFunctionality { /* ... */ };
    +Window implements SomeFunctionality;
    +
    +

    and author 2 later writes:

    +
    interface Gizmo { /* ... */ };
    +interface MoreFunctionality { /* ... */ };
    +SomeFunctionality implements MoreFunctionality;
    +Gizmo implements SomeFunctionality;
    +
    +

    then it might be the case that author 2 is unaware of exactly which + interfaces already are used on the left-hand side of an implements SomeFunctionality statement, and so has + required more objects implement MoreFunctionality than he or she expected.

    +

    Better in this case would be for author 2 to write:

    +
    interface Gizmo { /* ... */ };
    +interface MoreFunctionality { /* ... */ };
    +Gizmo implements SomeFunctionality;
    +Gizmo implements MoreFunctionality;
    +
    +
    +

    The consequential interfaces of an interface A are:

    +
      +
    • +

      each interface B where the IDL states A implements B;

      +
    • +

      each interface that a consequential interface of A inherits from; and

      +
    • +

      each interface D where the IDL states that C implements D, +where C is a consequential interface of A.

      +
    +

    For a given interface, there must not +be any member defined on any of its consequential interfaces +whose identifier is the same as any other member defined on any +of those consequential interfaces or on the original interface itself.

    +
    +

    For example, that precludes the following:

    +
    interface A { attribute long x; };
    +interface B { attribute long x; };
    +A implements B;  // B::x would clash with A::x
    +        
    +interface C { attribute long y; };
    +interface D { attribute long y; };
    +interface E : D { };
    +C implements E;  // D::y would clash with C::y
    +        
    +interface F { };
    +interface H { attribute long z; };
    +interface I { attribute long z; };
    +F implements H;
    +F implements I;  // H::z and I::z would clash when mixed in to F
    +
    +
    +

    No extended attributes defined in this specification are applicable to implements statements.

    +
    ImplementsStatement :
    +    identifier "implements" identifier ";"
    +
    +
    + +

    The following IDL fragment defines two interfaces, stating + that one interface is always implemented on objects implementing the other.

    +
    interface Entry {
    +  readonly attribute unsigned short entryType;
    +  // ...
    +};
    +        
    +interface Observable {
    +  void addEventListener(DOMString type,
    +                        EventListener listener,
    +                        boolean useCapture);
    +  // ...
    +};
    +        
    +Entry implements Observable;
    +
    +

    An ECMAScript implementation would thus have an “addEventListener” + property in the prototype chain of every Entry:

    +
    var e = getEntry();          // Obtain an instance of Entry.
    +typeof e.addEventListener;  // Evaluates to "function".
    +

    Note that it is not the case that all Observable objects implement Entry.

    +
    +

    3.10. Objects implementing interfaces

    +

    In a given implementation of a set of IDL fragments, +an object can be described as being a platform object, a user object, or neither. There are two kinds of +object that are considered to be platform objects:

    + +

    In a browser, for example, +the browser-implemented DOM objects (implementing interfaces such as Node and Document) that provide access to a web page’s contents +to ECMAScript running in the page would be platform objects. These objects might be exotic objects, +implemented in a language like C++, or they might be native ECMAScript objects. Regardless, +an implementation of a given set of IDL fragments needs to be able to recognize all platform objects +that are created by the implementation. This might be done by having some internal state that records whether +a given object is indeed a platform object for that implementation, or perhaps by observing +that the object is implemented by a given internal C++ class. How exactly platform objects +are recognised by a given implementation of a set of IDL fragments is implementation specific.

    +

    All other objects in the system would not be treated as platform objects. For example, assume that +a web page opened in a browser loads an ECMAScript library that implements DOM Core. This library +would be considered to be a different implementation from the browser provided implementation. +The objects created by the ECMAScript library that implement the Node interface +will not be treated as platform objects that implement Node by the browser implementation.

    +

    User objects are those that authors would create, implementing callback interfaces that the Web APIs use to be able to invoke author-defined +operations or to send and receive values to the author’s program through +manipulating the object’s attributes. In a web page, an ECMAScript object +that implements the EventListener interface, which is +used to register a callback that the DOM Events implementation invokes, would be considered +to be a user object.

    +

    Note that user objects can only implement callback interfaces and platform objects can only implement non-callback interfaces.

    +

    3.11. Types

    +

    This section lists the types supported by Web IDL, the set of values +corresponding to each type, and how constants of that type are represented.

    +

    The following types are known as integer types: byte, octet, short, unsigned short, long, unsigned long, long long and unsigned long long.

    +

    The following types are known as numeric types: +the integer types, float, unrestricted float, double and unrestricted double.

    +

    The primitive types are boolean and the numeric types.

    +

    The string types are DOMString, all enumeration types, ByteString and USVString.

    +

    The exception types are Error and DOMException.

    +

    The typed array types are Int8Array, Int16Array, Int32Array, Uint8Array, Uint16Array, Uint32Array, Uint8ClampedArray, Float32Array and Float64Array.

    +

    The buffer source types are ArrayBuffer, DataView, +and the typed array types.

    +

    The object type, +all interface types and the exception types are known as object types.

    +

    Every type has a type name, which +is a string, not necessarily unique, that identifies the type. +Each sub-section below defines what the type name is for each +type.

    +

    When conversions are made from language binding specific types to + IDL types in order to invoke an operation or assign a value to an attribute, + all conversions necessary will be performed before the + specified functionality of the operation or attribute assignment + is carried out. If the conversion cannot + be performed, then the operation will not run or + the attribute will not be updated. In some language bindings, + type conversions could result in an exception being thrown. + In such cases, these exceptions will be propagated to the + code that made the attempt to invoke the operation or + assign to the attribute.

    +
    Type :
    +    SingleType
    +    UnionType Null
    +
    +
    SingleType :
    +    NonAnyType
    +    "any"
    +
    +
    UnionType :
    +    "(" UnionMemberType "or" UnionMemberType UnionMemberTypes ")"
    +
    +
    UnionMemberType :
    +    NonAnyType
    +    UnionType Null
    +
    +
    UnionMemberTypes :
    +    "or" UnionMemberType UnionMemberTypes
    +    ε
    +
    +
    NonAnyType :
    +    PrimitiveType Null
    +    PromiseType Null
    +    "ByteString" Null
    +    "DOMString" Null
    +    "USVString" Null
    +    identifier Null
    +    "sequence" "<" Type ">" Null
    +    "object" Null
    +    "RegExp" Null
    +    "Error" Null
    +    "DOMException" Null
    +    BufferRelatedType Null
    +    "FrozenArray" "<" Type ">" Null
    +
    +
    +
    PrimitiveType :
    +    UnsignedIntegerType
    +    UnrestrictedFloatType
    +    "boolean"
    +    "byte"
    +    "octet"
    +
    +
    UnrestrictedFloatType :
    +    "unrestricted" FloatType
    +    FloatType
    +
    +
    FloatType :
    +    "float"
    +    "double"
    +
    +
    UnsignedIntegerType :
    +    "unsigned" IntegerType
    +    IntegerType
    +
    +
    IntegerType :
    +    "short"
    +    "long" OptionalLong
    +
    +
    OptionalLong :
    +    "long"
    +    ε
    +
    +
    PromiseType :
    +    "Promise" "<" ReturnType ">"
    +
    +
    Null :
    +    "?"
    +    ε
    +
    +

    3.11.1. any

    +

    The any type is the union of all other possible +non-union types. +Its type name is “Any”.

    +

    The any type is like +a discriminated union type, in that each of its values has a +specific non-any type +associated with it. For example, one value of the any type is the unsigned long 150, while another is the long 150. +These are distinct values.

    +

    The particular type of an any value is known as its specific type. +(Values of union types also have specific types.)

    +

    3.11.2. boolean

    +

    The boolean type has two values: true and false.

    +

    boolean constant values in IDL are +represented with the true and false tokens.

    +

    The type name of the boolean type is “Boolean”.

    +

    3.11.3. byte

    +

    The byte type is a signed integer +type that has values in the range [−128, 127].

    +

    byte constant values in IDL are +represented with integer tokens.

    +

    The type name of the byte type is “Byte”.

    +

    3.11.4. octet

    +

    The octet type is an unsigned integer +type that has values in the range [0, 255].

    +

    octet constant values in IDL are +represented with integer tokens.

    +

    The type name of the octet type is “Octet”.

    +

    3.11.5. short

    +

    The short type is a signed integer +type that has values in the range [−32768, 32767].

    +

    short constant values in IDL are +represented with integer tokens.

    +

    The type name of the short type is “Short”.

    +

    3.11.6. unsigned short

    +

    The unsigned short type is an unsigned integer +type that has values in the range [0, 65535].

    +

    unsigned short constant values in IDL are +represented with integer tokens.

    +

    The type name of the unsigned short type is “UnsignedShort”.

    +

    3.11.7. long

    +

    The long type is a signed integer +type that has values in the range [−2147483648, 2147483647].

    +

    long constant values in IDL are +represented with integer tokens.

    +

    The type name of the long type is “Long”.

    +

    3.11.8. unsigned long

    +

    The unsigned long type is an unsigned integer +type that has values in the range [0, 4294967295].

    +

    unsigned long constant values in IDL are +represented with integer tokens.

    +

    The type name of the unsigned long type is “UnsignedLong”.

    +

    3.11.9. long long

    +

    The long long type is a signed integer +type that has values in the range [−9223372036854775808, 9223372036854775807].

    +

    long long constant values in IDL are +represented with integer tokens.

    +

    The type name of the long long type is “LongLong”.

    +

    3.11.10. unsigned long long

    +

    The unsigned long long type is an unsigned integer +type that has values in the range [0, 18446744073709551615].

    +

    unsigned long long constant values in IDL are +represented with integer tokens.

    +

    The type name of the unsigned long long type is “UnsignedLongLong”.

    +

    3.11.11. float

    +

    The float type is a floating point numeric +type that corresponds to the set of finite single-precision 32 bit +IEEE 754 floating point numbers. [IEEE-754]

    +

    float constant values in IDL are +represented with float tokens.

    +

    The type name of the float type is “Float”.

    +

    Unless there are specific reasons to use a 32 bit floating point type, + specifications should use double rather than float, + since the set of values that a double can + represent more closely matches an ECMAScript Number.

    +

    3.11.12. unrestricted float

    +

    The unrestricted float type is a floating point numeric +type that corresponds to the set of all possible single-precision 32 bit +IEEE 754 floating point numbers, finite and non-finite. [IEEE-754]

    +

    unrestricted float constant values in IDL are +represented with float tokens.

    +

    The type name of the unrestricted float type is “UnrestrictedFloat”.

    +

    3.11.13. double

    +

    The double type is a floating point numeric +type that corresponds to the set of finite double-precision 64 bit +IEEE 754 floating point numbers. [IEEE-754]

    +

    double constant values in IDL are +represented with float tokens.

    +

    The type name of the double type is “Double”.

    +

    3.11.14. unrestricted double

    +

    The unrestricted double type is a floating point numeric +type that corresponds to the set of all possible double-precision 64 bit +IEEE 754 floating point numbers, finite and non-finite. [IEEE-754]

    +

    unrestricted double constant values in IDL are +represented with float tokens.

    +

    The type name of the unrestricted double type is “UnrestrictedDouble”.

    +

    3.11.15. DOMString

    +

    The DOMString type corresponds to +the set of all possible sequences of code units. +Such sequences are commonly interpreted as UTF-16 encoded strings [RFC2781] although this is not required. +While DOMString is defined to be +an OMG IDL boxed sequence<unsigned short> valuetype +in DOM Level 3 Core §The DOMString Type, +this document defines DOMString to be an intrinsic type +so as to avoidspecial casing that sequence type +in various situations where a string is required.

    +

    Note: Note also that null is not a value of type DOMString. +To allow null, a nullable DOMString, +written as DOMString? in IDL, needs to be used.

    +

    Nothing in this specification requires a DOMString value to be a valid UTF-16 string. For example, a DOMString value might include unmatched surrogate pair characters. However, authors +of specifications using Web IDL might want to obtain a sequence of Unicode scalar values given a particular sequence of code units. +The following algorithm defines a way to convert a DOMString to a sequence of Unicode scalar values:

    +
      +
    1. +

      Let S be the DOMString value.

      +
    2. +

      Let n be the length of S.

      +
    3. +

      Initialize i to 0.

      +
    4. +

      Initialize U to be an empty sequence of Unicode characters.

      +
    5. +

      While i < n:

      +
        +
      1. +

        Let c be the code unit in S at index i.

        +
      2. +

        Depending on the value of c:

        +
        +
        +

        c < 0xD800 or c > 0xDFFF

        +
        +

        Append to U the Unicode character with code point c.

        +
        +

        0xDC00 ≤ c ≤ 0xDFFF

        +
        +

        Append to U a U+FFFD REPLACEMENT CHARACTER.

        +
        +

        0xD800 ≤ c ≤ 0xDBFF

        +
        +
          +
        1. +

          If i = n−1, then append to U a U+FFFD REPLACEMENT CHARACTER.

          +
        2. +

          Otherwise, i < n−1:

          +
            +
          1. +

            Let d be the code unit in S at index i+1.

            +
          2. +

            If 0xDC00 ≤ d ≤ 0xDFFF, then:

            +
              +
            1. +

              Let a be c & 0x3FF.

              +
            2. +

              Let b be d & 0x3FF.

              +
            3. +

              Append to U the Unicode character with +code point 216+210a+b.

              +
            4. +

              Set i to i+1.

              +
            +
          3. +

            Otherwise, d < 0xDC00 or d > 0xDFFF. +Append to U a U+FFFD REPLACEMENT CHARACTER.

            +
          +
        +
        +
      3. +

        Set i to i+1.

        +
      +
    6. +

      Return U.

      +
    +

    There is no way to represent a constant DOMString value in IDL, although DOMString dictionary member and operation optional argument default values +can be specified using a string literal.

    +

    The type name of the DOMString type is “String”.

    +

    3.11.16. ByteString

    +

    The ByteString type +corresponds to the set of all possible sequences of bytes. +Such sequences might be interpreted as UTF-8 encoded strings [RFC3629] or strings in some other 8-bit-per-code-unit encoding, although this is not required.

    +

    There is no way to represent a constant ByteString value in IDL, although ByteString dictionary member and operation optional argument default values +can be specified using a string literal.

    +

    The type name of the ByteString type is “ByteString”.

    +

    Specifications should only use ByteString for interfacing with protocols + that use bytes and strings interchangably, such as HTTP. In general, + strings should be represented with DOMString values, even if it is expected + that values of the string will always be in ASCII or some + 8 bit character encoding. Sequences, frozen arrays or Typed Arrays with octet or byte elements should be used for holding + 8 bit data rather than ByteString.

    +

    3.11.17. USVString

    +

    The USVString type +corresponds to the set of all possible sequences of Unicode scalar values, +which are all of the Unicode code points apart from the +surrogate code points.

    +

    There is no way to represent a constant USVString value in IDL, although USVString dictionary member and operation optional argument default values +can be specified using a string literal.

    +

    The type name of the USVString type is “USVString”.

    +

    Specifications should only use USVString for APIs that perform + text processing and need a string of Unicode + scalar values to operate on. Most APIs that use strings + should instead be using DOMString, + which does not make any interpretations of the code units in the string. When in doubt, use DOMString.

    +

    3.11.18. object

    +

    The object type corresponds to the set of +all possible non-null object references.

    +

    There is no way to represent a constant object value in IDL.

    +

    To denote a type that includes all possible object references plus the null value, use the nullable type object?.

    +

    The type name of the object type is “Object”.

    +

    3.11.19. Interface types

    +

    An identifier that +identifies an interface is used to refer to +a type that corresponds to the set of all possible non-null references to objects that +implement that interface.

    +

    For non-callback interfaces, an IDL value of the interface type is represented just +by an object reference. For callback interfaces, an IDL value of the interface type +is represented by a tuple of an object reference and a callback context. +The callback context is a language +binding specific value, and is used to store information about the execution context at +the time the language binding specific object reference is converted to an IDL value.

    +

    Note: For ECMAScript objects, the callback context is used to hold a reference to the incumbent settings object at the time the Object value +is converted to an IDL callback interface type value. See §4.2.20 Interface types.

    +

    There is no way to represent a constant object reference value for +a particular interface type in IDL.

    +

    To denote a type that includes all possible references to objects implementing +the given interface plus the null value, +use a nullable type.

    +

    The type name of an interface type +is the identifier of the interface.

    +

    3.11.20. Dictionary types

    +

    An identifier that +identifies a dictionary is used to refer to +a type that corresponds to the set of all dictionaries that adhere to +the dictionary definition.

    +

    There is no way to represent a constant dictionary value in IDL.

    +

    The type name of a dictionary type +is the identifier of the dictionary.

    +

    3.11.21. Enumeration types

    +

    An identifier that +identifies an enumeration is used to +refer to a type whose values are the set of strings (sequences of code units, as with DOMString) that are the enumeration’s values.

    +

    Like DOMString, there is no way to represent a constant enumeration value in IDL, although enumeration-typed dictionary member default values can be specified using a string literal.

    +

    The type name of an enumeration type +is the identifier of the enumeration.

    +

    3.11.22. Callback function types

    +

    An identifier that identifies +a callback function is used to refer to +a type whose values are references to objects that are functions with the given signature.

    +

    An IDL value of the callback function type is represented by a tuple of an object +reference and a callback context.

    +

    Note: As with callback interface types, the callback context is used to hold a +reference to the incumbent settings object at +the time an ECMAScript Object value is converted to an IDL +callback function type value. See §4.2.23 Callback function types.

    +

    There is no way to represent a constant callback function value in IDL.

    +

    The type name of a callback function type +is the identifier of the callback function.

    +

    3.11.23. Nullable types — T?

    +

    A nullable type is an IDL type constructed +from an existing type (called the inner type), +which just allows the additional value null to be a member of its set of values. Nullable types are represented in IDL by placing a U+003F QUESTION MARK ("?") character after an existing type. The inner type must not +be any, +another nullable type, or a union type that itself has includes a nullable type or has a dictionary type as one of its flattened member types.

    +

    Note: Although dictionary types can in general be nullable, they cannot when used +as the type of an operation argument or a dictionary member.

    +

    Nullable type constant values in IDL are represented in the same way that +constant values of their inner type would be represented, or with the null token.

    +

    The type name of a nullable type +is the concatenation of the type name of the inner type T and +the string “OrNull”.

    +
    + +

    For example, a type that allows the values true, false and null is written as boolean?:

    +
    interface MyConstants {
    +  const boolean? ARE_WE_THERE_YET = false;
    +};
    +
    +

    The following interface has two attributes: one whose value can + be a DOMString or the null value, and another whose value can be a reference to a Node object or the null value:

    +
    interface Node {
    +  readonly attribute DOMString? namespaceURI;
    +  readonly attribute Node? parentNode;
    +  // ...
    +};
    +
    +
    +

    3.11.24. Sequences — sequence<T>

    +

    The sequence<T> type is a parameterized type whose values are (possibly zero-length) sequences of +values of type T.

    +

    Sequences are always passed by value. In +language bindings where a sequence is represented by an object of +some kind, passing a sequence to a platform object will not result in a reference to the sequence being kept by that object. +Similarly, any sequence returned from a platform object +will be a copy and modifications made to it will not be visible to the platform object.

    +

    There is no way to represent a constant sequence value in IDL.

    +

    Sequences must not be used as the +type of an attribute or constant.

    +

    Note: This restriction exists so that it is clear to specification writers +and API users that sequences are copied rather than having references +to them passed around. Instead of a writable attribute of a sequence +type, it is suggested that a pair of operations to get and set the +sequence is used.

    +

    The type name of a sequence type +is the concatenation of the type name for T and +the string “Sequence”.

    +

    3.11.25. Promise types — Promise<T>

    +

    A promise type is a parameterized type +whose values are references to objects that “is used as a place holder +for the eventual results of a deferred (and possibly asynchronous) computation +result of an asynchronous operation”. +See section 25.4 of the ECMAScript specification for details on the semantics of promise objects.

    +

    There is no way to represent a promise value in IDL.

    +

    The type name of a promise type +is the concatenation of the type name for T and +the string “Promise”.

    +

    3.11.26. Union types

    +

    A union type is a type whose set of values +is the union of those in two or more other types. Union types (matching UnionType) +are written as a series of types separated by the or keyword +with a set of surrounding parentheses. +The types which comprise the union type are known as the +union’s member types.

    +
    +

    For example, you might write (Node or DOMString) or (double or sequence<double>). When applying a ? suffix to a union type as a whole, it is placed after the closing parenthesis, + as in (Node or DOMString)?.

    +

    Note that the member types of a union type do not descend into nested union types. So for (double or (sequence<long> or Event) or (Node or DOMString)?) the member types + are double, (sequence<long> or Event) and (Node or DOMString)?.

    +
    +

    Like the any type, values of +union types have a specific type, +which is the particular member type that matches the value.

    +

    The flattened member types of a union type is a set of types +determined as follows:

    +
      +
    1. +

      Let T be the union type.

      +
    2. +

      Initialize S to ∅.

      +
    3. +

      For each member type U of T:

      +
        +
      1. +

        If U is a nullable type, then +set U to be the inner type of U.

        +
      2. +

        If U is a union type, then +add to S the flattened member types of U.

        +
      3. +

        Otherwise, U is not a union type. +Add U to S.

        +
      +
    4. +

      Return S.

      +
    +

    Note: For example, the flattened member types of the union type (Node or (sequence<long> or Event) or (XMLHttpRequest or DOMString)? or sequence<(sequence<double> or NodeList)>) are the six types Node, sequence<long>, Event, XMLHttpRequest, DOMString and sequence<(sequence<double> or NodeList)>.

    +

    The number of nullable member types of a union type is an integer +determined as follows:

    +
      +
    1. +

      Let T be the union type.

      +
    2. +

      Initialize n to 0.

      +
    3. +

      For each member type U of T:

      +
        +
      1. +

        If U is a nullable type, then:

        +
          +
        1. +

          Set n to n + 1.

          +
        2. +

          Set U to be the inner type of U.

          +
        +
      2. +

        If U is a union type, then:

        +
          +
        1. +

          Let m be the number of nullable member types of U.

          +
        2. +

          Set n to n + m.

          +
        +
      +
    4. +

      Return n.

      +
    +

    The any type must not +be used as a union member type.

    +

    The number of nullable member types of a union type must +be 0 or 1, and if it is 1 then the union type must also not have +a dictionary type in its flattened member types.

    +

    A type includes a nullable type if:

    + +

    Each pair of flattened member types in a union type, T and U, +must be distinguishable.

    +

    Union type constant values +in IDL are represented in the same way that constant values of their member types would be +represented.

    +

    The type name of a union +type is formed by taking the type names of each member type, in order, +and joining them with the string “Or”.

    +
    +
    +
    +
    +

    3.11.27. RegExp

    +

    The RegExp type is a type +whose values are references to objects that represent regular expressions. +The particular regular expression language and the features it supports +is language binding specific.

    +

    There is no way to represent a constant RegExp value in IDL.

    +

    The type name of the RegExp type is “RegExp”.

    +

    3.11.28. Error

    +

    The Error type corresponds to the +set of all possible non-null references to exception objects, including simple exceptions and DOMExceptions.

    +

    There is no way to represent a constant Error value in IDL.

    +

    The type name of the Error type is “Error”.

    +

    3.11.29. DOMException

    +

    The DOMException type corresponds to the +set of all possible non-null references to objects +representing DOMExceptions.

    +

    There is no way to represent a constant DOMException value in IDL.

    +

    The type name of the DOMException type is “DOMException”.

    +

    3.11.30. Buffer source types

    +

    There are a number of types that correspond to sets of all possible non-null +references to objects that represent a buffer of data or a view on to a buffer of +data. The table below lists these types and the kind of buffer or view they represent.

    + + + + + + + + + +
    Type + Kind of buffer +
    ArrayBuffer + An object that holds a pointer (which may be null) to a buffer of a fixed number of bytes +
    DataView + A view on to an ArrayBuffer that allows typed access to integers and floating point values stored at arbitrary offsets into the buffer +
    Int8Array,
    Int16Array,
    Int32Array +
    A view on to an ArrayBuffer that exposes it as an array of two’s complement signed integers of the given size in bits +
    Uint8Array,
    Uint16Array,
    Uint32Array +
    A view on to an ArrayBuffer that exposes it as an array of unsigned integers of the given size in bits +
    Uint8ClampedArray + A view on to an ArrayBuffer that exposes it as an array of unsigned 8 bit integers with clamped conversions +
    Float32Array,
    Float64Array +
    A view on to an ArrayBuffer that exposes it as an array of IEEE 754 floating point numbers of the given size in bits +
    +

    Note: These types all correspond to classes defined in ECMAScript.

    +

    To detach an ArrayBuffer is to set its buffer pointer to null.

    +

    There is no way to represent a constant value of any of these types in IDL.

    +

    The type name of all +of these types is the name of the type itself.

    +

    At the specification prose level, IDL buffer source types are simply references to objects. To inspect or manipulate the bytes inside the buffer, +specification prose must first either get a reference to the bytes held by the buffer source or get a copy of the bytes held by the buffer source. +With a reference to the buffer source’s bytes, specification prose can get or set individual +byte values using that reference.

    +
    +

    Extreme care must be taken when writing specification text that gets a reference + to the bytes held by a buffer source, as the underyling data can easily be changed + by the script author or other APIs at unpredictable times. If you are using a buffer source type + as an operation argument to obtain a chunk of binary data that will not be modified, + it is strongly recommended to get a copy of the buffer source’s bytes at the beginning + of the prose defining the operation.

    +

    Requiring prose to explicitly get a reference to or copy of the bytes is intended to + help specification reviewers look for problematic uses of these buffer source types.

    +
    +
    +

    When designing APIs that take a buffer, it is recommended to use the BufferSource typedef rather than ArrayBuffer or any of the view types.

    +

    When designing APIs that create and return a buffer, it is recommended + to use the ArrayBuffer type rather than Uint8Array.

    +
    +

    Attempting to get a reference to or get a copy of the bytes held by a buffer source when the ArrayBuffer has been detached will fail in a language binding-specific manner.

    +

    Note: See §4.2.31 Buffer source types below for +how interacting with buffer source types works in the ECMAScript language binding.

    +

    We should include an example of specification text that uses these types and terms.

    +
    BufferRelatedType :
    +    "ArrayBuffer"
    +    "DataView"
    +    "Int8Array"
    +    "Int16Array"
    +    "Int32Array"
    +    "Uint8Array"
    +    "Uint16Array"
    +    "Uint32Array"
    +    "Uint8ClampedArray"
    +    "Float32Array"
    +    "Float64Array"
    +
    +

    3.11.31. Frozen arrays — FrozenArray<T>

    +

    A frozen array type is a parameterized +type whose values are references to objects that hold a fixed length array +of unmodifiable values. The values in the array are of type T.

    +

    Since FrozenArray<T> values +are references, they are unlike sequence types, +which are lists of values that are passed by value.

    +

    There is no way to represent a constant frozen array value in IDL.

    +

    The type name of a frozen array +type is the concatenation of the type name for T and the string +“Array”.

    +

    3.12. Extended attributes

    +

    An extended attribute is an annotation +that can appear on +definitions, interface members, namespace members, dictionary members, +and operation arguments, and +is used to control how language bindings will handle those constructs. +Extended attributes are specified with an ExtendedAttributeList, +which is a square bracket enclosed, comma separated list of ExtendedAttributes.

    +

    The ExtendedAttribute grammar symbol matches nearly any sequence of tokens, however the extended attributes defined in this document only accept a more restricted syntax. +Any extended attribute encountered in an IDL fragment is +matched against the following six grammar symbols to determine +which form (or forms) it is in:

    + + + + + + + + +
    Grammar symbol + Form + Example +
    ExtendedAttributeNoArgs + takes no arguments + [Replaceable] +
    ExtendedAttributeArgList + takes an argument list + [Constructor(double x, double y)] +
    ExtendedAttributeNamedArgList + takes a named argument list + [NamedConstructor=Image(DOMString src)] +
    ExtendedAttributeIdent + takes an identifier + [PutForwards=name] +
    ExtendedAttributeIdentList + takes an identifier list + [Exposed=(Window,Worker)] +
    +

    This specification defines a number of extended attributes that +are applicable to the ECMAScript language binding, which are described in §4.3 ECMAScript-specific extended attributes. +Each extended attribute definition will state which of the above +six forms are allowed.

    +
    ExtendedAttributeList :
    +    "[" ExtendedAttribute ExtendedAttributes "]"
    +    ε
    +
    +
    ExtendedAttributes :
    +    "," ExtendedAttribute ExtendedAttributes
    +    ε
    +
    +
    ExtendedAttribute :
    +    "(" ExtendedAttributeInner ")" ExtendedAttributeRest
    +    "[" ExtendedAttributeInner "]" ExtendedAttributeRest
    +    "{" ExtendedAttributeInner "}" ExtendedAttributeRest
    +    Other ExtendedAttributeRest
    +
    +
    ExtendedAttributeRest :
    +    ExtendedAttribute
    +    ε
    +
    +
    ExtendedAttributeInner :
    +    "(" ExtendedAttributeInner ")" ExtendedAttributeInner
    +    "[" ExtendedAttributeInner "]" ExtendedAttributeInner
    +    "{" ExtendedAttributeInner "}" ExtendedAttributeInner
    +    OtherOrComma ExtendedAttributeInner
    +    ε
    +
    +
    Other :
    +    integer
    +    float
    +    identifier
    +    string
    +    other
    +    "-"
    +    "-Infinity"
    +    "."
    +    "..."
    +    ":"
    +    ";"
    +    "<"
    +    "="
    +    ">"
    +    "?"
    +    "ByteString"
    +    "DOMString"
    +    "FrozenArray"
    +    "Infinity"
    +    "NaN"
    +    "RegExp"
    +    "USVString"
    +    "any"
    +    "boolean"
    +    "byte"
    +    "double"
    +    "false"
    +    "float"
    +    "long"
    +    "null"
    +    "object"
    +    "octet"
    +    "or"
    +    "optional"
    +    "sequence"
    +    "short"
    +    "true"
    +    "unsigned"
    +    "void"
    +    ArgumentNameKeyword
    +    BufferRelatedType
    +
    +
    OtherOrComma :
    +    Other
    +    ","
    +
    +
    IdentifierList :
    +    identifier Identifiers
    +
    +
    +
    ExtendedAttributeNoArgs :
    +    identifier
    +
    +
    ExtendedAttributeArgList :
    +    identifier "(" ArgumentList ")"
    +
    +
    ExtendedAttributeIdent :
    +    identifier "=" identifier
    +
    +
    ExtendedAttributeIdentList :
    +    identifier "=" "(" IdentifierList ")"
    +
    +
    ExtendedAttributeNamedArgList :
    +    identifier "=" identifier "(" ArgumentList ")"
    +
    +

    4. ECMAScript binding

    +

    This section describes how definitions written with the IDL defined in §3 Interface definition language correspond to particular constructs +in ECMAScript, as defined by the ECMAScript Language Specification 6th Edition [ECMA-262].

    +

    Objects defined in this section have internal properties as described in +ECMA-262 sections 9.1 and 9.3.1 unless otherwise specified, in which case one or +more of the following are redefined in accordance with the rules for exotic objects: +[[Call]], +[[Set]], +[[DefineOwnProperty]], +[[GetOwnProperty]], +[[Delete]] and +[[HasInstance]].

    +

    Other specifications may override the definitions +of any internal method of a platform object that is an instance of an interface.

    +

    As overriding internal ECMAScript object methods is a low level operation and + can result in objects that behave differently from ordinary objects, + this facility should not be used unless necessary + for security or compatibility. The expectation is that this will be used + for Location objects + and possibly WindowProxy objects.

    +

    Unless otherwise specified, the [[Extensible]] internal property +of objects defined in this section has the value true.

    +

    Unless otherwise specified, the [[Prototype]] internal property +of objects defined in this section is the Object prototype object.

    +

    Some objects described in this section are defined to have a class string, +which is the string to include in the string returned from Object.prototype.toString. +If an object has a class string, then the object must, +at the time it is created, have a property whose name is the @@toStringTag symbol +and whose value is the specified string.

    +

    Should define whether @@toStringTag is writable, enumerable and configurable. + All @@toStringTag properties in the ES6 spec are non-writable and non-enumerable, + and configurable.

    +

    If an object is defined to be a function object, then +it has characteristics as follows:

    + +

    The list above needs updating for the latest ES6 draft.

    +

    Algorithms in this section use the conventions described in ECMA-262 section 5.2, such as the use of steps and substeps, the use of mathematical + operations, and so on. The ToBoolean, ToNumber, ToUint16, ToInt32, ToUint32, ToString, ToObject, IsAccessorDescriptor and IsDataDescriptor abstract operations and the Type(x) notation referenced in this section are defined in ECMA-262 sections 6 and 7.

    +

    When an algorithm says to throw a SomethingError then this means to construct a new ECMAScript SomethingError object +and to throw it, just as the algorithms in ECMA-262 do.

    +

    Note that algorithm steps can call in to other algorithms and abstract operations and +not explicitly handle exceptions that are thrown from them. When an exception +is thrown by an algorithm or abstract operation and it is not explicitly +handled by the caller, then it is taken to end the algorithm and propagate out +to its caller, and so on.

    +
    + +

    Consider the following algorithm:

    +
      +
    1. +

      Let x be the ECMAScript value passed in to this algorithm.

      +
    2. +

      Let y be the result of calling ToString(x).

      +
    3. +

      Return y.

      +
    +

    Since ToString can throw an exception (for example if passed the object ({ toString: function() { throw 1 } })), and the exception is + not handled in the above algorithm, if one is thrown then it causes this + algorithm to end and for the exception to propagate out to its caller, if there + is one.

    +
    +

    4.1. ECMAScript environment

    +

    In an ECMAScript implementation of a given set of IDL fragments, +there will exist a number of ECMAScript objects that correspond to +definitions in those IDL fragments. +These objects are termed the initial objects, +and comprise the following:

    + +

    Each ECMAScript global environment must have its own unique set of each of +the initial objects, created +before control enters any ECMAScript execution context associated with the +environment, but after the global object for that environment is created. The [[Prototype]]s +of all initial objects in a given global environment must come from +that same global environment.

    +
    + +

    In an HTML user agent, multiple global environments can exist when + multiple frames or windows are created. Each frame or window will have + its own set of initial objects, + which the following HTML document demonstrates:

    +
    <!DOCTYPE html>
    +<title>Different global environments</title>
    +<iframe id=a></iframe>
    +<script>
    +var iframe = document.getElementById("a");
    +var w = iframe.contentWindow;              // The global object in the frame
    +        
    +Object == w.Object;                        // Evaluates to false, per ECMA-262
    +Node == w.Node;                            // Evaluates to false
    +iframe instanceof w.Node;                  // Evaluates to false
    +iframe instanceof w.Object;                // Evaluates to false
    +iframe.appendChild instanceof Function;    // Evaluates to true
    +iframe.appendChild instanceof w.Function;  // Evaluates to false
    +</script>
    +
    +

    Unless otherwise specified, each ECMAScript global environment exposes all interfaces that the implementation supports. If a given ECMAScript global environment does not +expose an interface, then the requirements given in §4.6 Interfaces are +not followed for that interface.

    +

    Note: This allows, for example, ECMAScript global environments for Web Workers to expose different sets of supported interfaces from those exposed in environments +for Web pages.

    +

    Although at the time of this writing the ECMAScript specification does not reflect this, +every ECMAScript object must have an associated Realm. The mechanisms +for associating objects with Realms are, for now, underspecified. However, we note that +in the case of platform objects, the +associated Realm is equal to the object’s relevant Realm, and +for non-exotic function objects (i.e. not callable proxies, and not bound functions) +the associated Realm is equal to the value of the function object’s [[Realm]] internal +slot.

    +

    4.2. ECMAScript type mapping

    +

    This section describes how types in the IDL map to types in ECMAScript.

    +

    Each sub-section below describes how values of a given IDL type are represented +in ECMAScript. For each IDL type, it is described how ECMAScript values are converted to an IDL value when passed to a platform object expecting that type, and how IDL values +of that type are converted to ECMAScript values when returned from a platform object.

    +

    4.2.1. any

    +

    Since the IDL any type +is the union of all other IDL types, it can correspond to any +ECMAScript value type.

    +

    How to convert an ECMAScript value to an IDL any value depends on the type of the + ECMAScript value:

    +
    +
    +

    The undefined value

    +
    +

    The IDL value is an object reference +to a special object that represents the ECMAScript undefined value.

    +
    +

    The null value

    +
    +

    The IDL value is the null object? reference.

    +
    +

    A Boolean value

    +
    +

    The IDL value is the boolean value that represents the same truth value.

    +
    +

    A Number value

    +
    +

    The IDL value is that which is obtained +by following the rules for converting the Number to an IDL unrestricted double value, +as described in §4.2.15 unrestricted double.

    +
    +

    A String value

    +
    +

    The IDL value is that which is obtained +by following the rules for converting the String to an IDL DOMString value, +as described in §4.2.16 DOMString.

    +
    +

    An object value

    +
    +

    The IDL value is an object value that +references the same object.

    +
    +

    An IDL any value is converted to an ECMAScript value as follows. If the value is an object reference to a special object that represents an ECMAScript undefined value, then it is converted to the ECMAScript undefined value. Otherwise, + the rules for converting the specific type of the IDL any value + as described in the remainder of this section are performed.

    +

    4.2.2. void

    +

    The only place that the void type may appear +in IDL is as the return type of an operation. Functions on platform objects that implement an operation whose IDL specifies a void return type must return the undefined value.

    +

    ECMAScript functions that implement an operation whose IDL +specifies a void return type +may return any value, which will be discarded.

    +

    4.2.3. boolean

    +

    An ECMAScript value V is converted to an IDL boolean value + by running the following algorithm:

    +
      +
    1. +

      Let x be the result of computing ToBoolean(V).

      +
    2. +

      Return the IDL boolean value that is the one that represents the same truth value as the ECMAScript Boolean value x.

      +
    +

    The IDL boolean value true is converted to + the ECMAScript true value and the IDL boolean value false is converted to the ECMAScript false value.

    +

    4.2.4. byte

    +

    An ECMAScript value V is converted to an IDL byte value + by running the following algorithm:

    +
      +
    1. +

      Initialize x to ToNumber(V).

      +
    2. +

      If the conversion to an IDL value is being performed due to any of the following:

      + +

      then:

      +
        +
      1. +

        If x is NaN, +∞, or −∞, then throw a TypeError.

        +
      2. +

        Set x to sign(x) * floor(abs(x)).

        +
      3. +

        If x < −27 or x > 27 − 1, then throw a TypeError.

        +
      4. +

        Return the IDL byte value that represents the same numeric value as x.

        +
      +
    3. +

      If x is not NaN and the conversion to an IDL value is being performed due to any of the following:

      + +

      then:

      +
        +
      1. +

        Set x to min(max(x, −27), 27 − 1).

        +
      2. +

        Round x to the nearest integer, choosing the even integer if it lies halfway between two, and choosing +0 rather than −0.

        +
      3. +

        Return the IDL byte value that represents the same numeric value as x.

        +
      +
    4. +

      If x is NaN, +0, −0, +∞, or −∞, then return the IDL byte value that represents 0.

      +
    5. +

      Set x to sign(x) * floor(abs(x)).

      +
    6. +

      Set x to x modulo 28.

      +
    7. +

      If x ≥ 27, return the IDL byte value that represents the same numeric value as x − 28. +Otherwise, return the IDL byte value that represents the same numeric value as x.

      +
    +

    The result of converting an IDL byte value to an ECMAScript + value is a Number that represents + the same numeric value as the IDL byte value. + The Number value will be an integer in the range [−128, 127].

    +

    4.2.5. octet

    +

    An ECMAScript value V is converted to an IDL octet value + by running the following algorithm:

    +
      +
    1. +

      Initialize x to ToNumber(V).

      +
    2. +

      If the conversion to an IDL value is being performed due to any of the following:

      + +

      then:

      +
        +
      1. +

        If x is NaN, +∞, or −∞, then throw a TypeError.

        +
      2. +

        Set x to sign(x) * floor(abs(x)).

        +
      3. +

        If x < 0 or x > 28 − 1, then throw a TypeError.

        +
      4. +

        Return the IDL octet value that represents the same numeric value as x.

        +
      +
    3. +

      If x is not NaN and the conversion to an IDL value is being performed due to any of the following:

      + +

      then:

      +
        +
      1. +

        Set x to min(max(x, 0), 28 − 1).

        +
      2. +

        Round x to the nearest integer, choosing the even integer if it lies halfway between two, and choosing +0 rather than −0.

        +
      3. +

        Return the IDL octet value that represents the same numeric value as x.

        +
      +
    4. +

      If x is NaN, +0, −0, +∞, or −∞, then return the IDL octet value that represents 0.

      +
    5. +

      Set x to sign(x) * floor(abs(x)).

      +
    6. +

      Set x to x modulo 28.

      +
    7. +

      Return the IDL octet value that represents the same numeric value as x.

      +
    +

    The result of converting an IDL octet value to an ECMAScript + value is a Number that represents + the same numeric value as the IDL octet value. + The Number value will be an integer in the range [0, 255].

    +

    4.2.6. short

    +

    An ECMAScript value V is converted to an IDL short value + by running the following algorithm:

    +
      +
    1. +

      Initialize x to ToNumber(V).

      +
    2. +

      If the conversion to an IDL value is being performed due to any of the following:

      + +

      then:

      +
        +
      1. +

        If x is NaN, +∞, or −∞, then throw a TypeError.

        +
      2. +

        Set x to sign(x) * floor(abs(x)).

        +
      3. +

        If x < −215 or x > 215 − 1, then throw a TypeError.

        +
      4. +

        Return the IDL short value that represents the same numeric value as x.

        +
      +
    3. +

      If x is not NaN and the conversion to an IDL value is being performed due to any of the following:

      + +

      then:

      +
        +
      1. +

        Set x to min(max(x, −215), 215 − 1).

        +
      2. +

        Round x to the nearest integer, choosing the even integer if it lies halfway between two, and choosing +0 rather than −0.

        +
      3. +

        Return the IDL short value that represents the same numeric value as x.

        +
      +
    4. +

      If x is NaN, +0, −0, +∞, or −∞, then return the IDL short value that represents 0.

      +
    5. +

      Set x to sign(x) * floor(abs(x)).

      +
    6. +

      Set x to x modulo 216.

      +
    7. +

      If x ≥ 215, return the IDL short value that represents the same numeric value as x − 216. +Otherwise, return the IDL short value that represents the same numeric value as x.

      +
    +

    The result of converting an IDL short value to an ECMAScript + value is a Number that represents the + same numeric value as the IDL short value. + The Number value will be an integer in the range [−32768, 32767].

    +

    4.2.7. unsigned short

    +

    An ECMAScript value V is converted to an IDL unsigned short value + by running the following algorithm:

    +
      +
    1. +

      Initialize x to ToNumber(V).

      +
    2. +

      If the conversion to an IDL value is being performed due to any of the following:

      + +

      then:

      +
        +
      1. +

        If x is NaN, +∞, or −∞, then throw a TypeError.

        +
      2. +

        Set x to sign(x) * floor(abs(x)).

        +
      3. +

        If x < 0 or x > 216 − 1, then throw a TypeError.

        +
      4. +

        Return the IDL unsigned short value that represents the same numeric value as x.

        +
      +
    3. +

      If x is not NaN and the conversion to an IDL value is being performed due to any of the following:

      + +

      then:

      +
        +
      1. +

        Set x to min(max(x, 0), 216 − 1).

        +
      2. +

        Round x to the nearest integer, choosing the even integer if it lies halfway between two, and choosing +0 rather than −0.

        +
      3. +

        Return the IDL unsigned short value that represents the same numeric value as x.

        +
      +
    4. +

      Set x to ToUint16(x).

      +
    5. +

      Return the IDL unsigned short value that represents the same numeric value as x.

      +
    +

    The result of converting an IDL unsigned short value to an ECMAScript + value is a Number that + represents the same numeric value as the IDL unsigned short value. + The Number value will be an integer in the range [0, 65535].

    +

    4.2.8. long

    +

    An ECMAScript value V is converted to an IDL long value + by running the following algorithm:

    +
      +
    1. +

      Initialize x to ToNumber(V).

      +
    2. +

      If the conversion to an IDL value is being performed due to any of the following:

      + +

      then:

      +
        +
      1. +

        If x is NaN, +∞, or −∞, then throw a TypeError.

        +
      2. +

        Set x to sign(x) * floor(abs(x)).

        +
      3. +

        If x < −231 or x > 231 − 1, then throw a TypeError.

        +
      4. +

        Return the IDL long value that represents the same numeric value as x.

        +
      +
    3. +

      If x is not NaN and the conversion to an IDL value is being performed due to any of the following:

      + +

      then:

      +
        +
      1. +

        Set x to min(max(x, −231), 231 − 1).

        +
      2. +

        Round x to the nearest integer, choosing the even integer if it lies halfway between two, and choosing +0 rather than −0.

        +
      3. +

        Return the IDL long value that represents the same numeric value as x.

        +
      +
    4. +

      Set x to ToInt32(x).

      +
    5. +

      Return the IDL long value that represents the same numeric value as x.

      +
    +

    The result of converting an IDL long value to an ECMAScript + value is a Number that + represents the same numeric value as the IDL long value. + The Number value will be an integer in the range [−2147483648, 2147483647].

    +

    4.2.9. unsigned long

    +

    An ECMAScript value V is converted to an IDL unsigned long value + by running the following algorithm:

    +
      +
    1. +

      Initialize x to ToNumber(V).

      +
    2. +

      If the conversion to an IDL value is being performed due to any of the following:

      + +

      then:

      +
        +
      1. +

        If x is NaN, +∞, or −∞, then throw a TypeError.

        +
      2. +

        Set x to sign(x) * floor(abs(x)).

        +
      3. +

        If x < 0 or x > 232 − 1, then throw a TypeError.

        +
      4. +

        Return the IDL unsigned long value that represents the same numeric value as x.

        +
      +
    3. +

      If x is not NaN and the conversion to an IDL value is being performed due to any of the following:

      + +

      then:

      +
        +
      1. +

        Set x to min(max(x, 0), 232 − 1).

        +
      2. +

        Round x to the nearest integer, choosing the even integer if it lies halfway between two, and choosing +0 rather than −0.

        +
      3. +

        Return the IDL unsigned long value that represents the same numeric value as x.

        +
      +
    4. +

      Set x to ToUint32(x).

      +
    5. +

      Return the IDL unsigned long value that represents the same numeric value as x.

      +
    +

    The result of converting an IDL unsigned long value to an ECMAScript + value is a Number that + represents the same numeric value as the IDL unsigned long value. + The Number value will be an integer in the range [0, 4294967295].

    +

    4.2.10. long long

    +

    An ECMAScript value V is converted to an IDL long long value + by running the following algorithm:

    +
      +
    1. +

      Initialize x to ToNumber(V).

      +
    2. +

      If the conversion to an IDL value is being performed due to any of the following:

      + +

      then:

      +
        +
      1. +

        If x is NaN, +∞, or −∞, then throw a TypeError.

        +
      2. +

        Set x to sign(x) * floor(abs(x)).

        +
      3. +

        If x < −253 + 1 or x > 253 − 1, then throw a TypeError.

        +
      4. +

        Return the IDL long long value that represents the same numeric value as x.

        +
      +
    3. +

      If x is not NaN and the conversion to an IDL value is being performed due to any of the following:

      + +

      then:

      +
        +
      1. +

        Set x to min(max(x, −253 + 1), 253 − 1).

        +
      2. +

        Round x to the nearest integer, choosing the even integer if it lies halfway between two, and choosing +0 rather than −0.

        +
      3. +

        Return the IDL long long value that represents the same numeric value as x.

        +
      +
    4. +

      If x is NaN, +0, −0, +∞, or −∞, then return the IDL long long value that represents 0.

      +
    5. +

      Set x to sign(x) * floor(abs(x)).

      +
    6. +

      Set x to x modulo 264.

      +
    7. +

      If x is greater than or equal to 263, then set x to x − 264.

      +
    8. +

      Return the IDL long long value that represents the same numeric value as x.

      +
    +

    The result of converting an IDL long long value to an ECMAScript + value is a Number value that + represents the closest numeric value to the long long, + choosing the numeric value with an even significand if there are + two equally close values. + If the long long is in the range + [−253 + 1, 253 − 1], then the Number will be able to represent exactly the same value as the long long.

    +

    4.2.11. unsigned long long

    +

    An ECMAScript value V is converted to an IDL unsigned long long value + by running the following algorithm:

    +
      +
    1. +

      Initialize x to ToNumber(V).

      +
    2. +

      If the conversion to an IDL value is being performed due to any of the following:

      + +

      then:

      +
        +
      1. +

        If x is NaN, +∞, or −∞, then throw a TypeError.

        +
      2. +

        Set x to sign(x) * floor(abs(x)).

        +
      3. +

        If x < 0 or x > 253 − 1, then throw a TypeError.

        +
      4. +

        Return the IDL unsigned long long value that represents the same numeric value as x.

        +
      +
    3. +

      If x is not NaN and the conversion to an IDL value is being performed due to any of the following:

      + +

      then:

      +
        +
      1. +

        Set x to min(max(x, 0), 253 − 1).

        +
      2. +

        Round x to the nearest integer, choosing the even integer if it lies halfway between two, and choosing +0 rather than −0.

        +
      3. +

        Return the IDL unsigned long long value that represents the same numeric value as x.

        +
      +
    4. +

      If x is NaN, +0, −0, +∞, or −∞, then return the IDL unsigned long long value that represents 0.

      +
    5. +

      Set x to sign(x) * floor(abs(x)).

      +
    6. +

      Set x to x modulo 264.

      +
    7. +

      Return the IDL unsigned long long value that represents the same numeric value as x.

      +
    +

    The result of converting an IDL unsigned long long value to an ECMAScript + value is a Number value that + represents the closest numeric value to the unsigned long long, + choosing the numeric value with an even significand if there are + two equally close values. + If the unsigned long long is less than or equal to 253 − 1, + then the Number will be able to + represent exactly the same value as the unsigned long long.

    +

    4.2.12. float

    +

    An ECMAScript value V is converted to an IDL float value + by running the following algorithm:

    +
      +
    1. +

      Let x be ToNumber(V).

      +
    2. +

      If x is NaN, +Infinity or −Infinity, then throw a TypeError.

      +
    3. +

      Let S be the set of finite IEEE 754 single-precision floating +point values except −0, but with two special values added: 2128 and +−2128.

      +
    4. +

      Let y be the number in S that is closest +to x, selecting the number with an even significand if there are two equally close values. +(The two special values 2128 and −2128 are considered to have even significands for this purpose.)

      +
    5. +

      If y is 2128 or −2128, then throw a TypeError.

      +
    6. +

      If y is +0 and x is negative, return −0.

      +
    7. +

      Return y.

      +
    +

    The result of converting an IDL float value to an ECMAScript + value is the Number value that represents the same numeric value as the IDL float value.

    +

    4.2.13. unrestricted float

    +

    An ECMAScript value V is converted to an IDL unrestricted float value + by running the following algorithm:

    +
      +
    1. +

      Let x be ToNumber(V).

      +
    2. +

      If x is NaN, then return the IDL unrestricted float value that represents the IEEE 754 NaN value with the bit pattern 0x7fc00000 [IEEE-754].

      +
    3. +

      Let S be the set of finite IEEE 754 single-precision floating +point values except −0, but with two special values added: 2128 and +−2128.

      +
    4. +

      Let y be the number in S that is closest +to x, selecting the number with an even significand if there are two equally close values. +(The two special values 2128 and −2128 are considered to have even significands for this purpose.)

      +
    5. +

      If y is 2128, return +∞.

      +
    6. +

      If y is −2128, return −∞.

      +
    7. +

      If y is +0 and x is negative, return −0.

      +
    8. +

      Return y.

      +
    +

    Note: Since there is only a single ECMAScript NaN value, +it must be canonicalized to a particular single precision IEEE 754 NaN value. The NaN value +mentioned above is chosen simply because it is the quiet NaN with the lowest +value when its bit pattern is interpreted as an unsigned 32 bit integer.

    +

    The result of converting an IDL unrestricted float value to an ECMAScript + value is a Number:

    +
      +
    • +

      If the IDL unrestricted float value is a NaN, +then the Number value is NaN.

      +
    • +

      Otherwise, the Number value is +the one that represents the same numeric value as the IDL unrestricted float value.

      +
    +

    4.2.14. double

    +

    An ECMAScript value V is converted to an IDL double value + by running the following algorithm:

    +
      +
    1. +

      Let x be ToNumber(V).

      +
    2. +

      If x is NaN, +Infinity or −Infinity, then throw a TypeError.

      +
    3. +

      Return the IDL double value +that has the same numeric value as x.

      +
    +

    The result of converting an IDL double value to an ECMAScript + value is the Number value that represents the + same numeric value as the IDL double value.

    +

    4.2.15. unrestricted double

    +

    An ECMAScript value V is converted to an IDL unrestricted double value + by running the following algorithm:

    +
      +
    1. +

      Let x be ToNumber(V).

      +
    2. +

      If x is NaN, then return the IDL unrestricted double value that represents the IEEE 754 NaN value with the bit pattern 0x7ff8000000000000 [IEEE-754].

      +
    3. +

      Return the IDL unrestricted double value +that has the same numeric value as x.

      +
    +

    Note: Since there is only a single ECMAScript NaN value, +it must be canonicalized to a particular double precision IEEE 754 NaN value. The NaN value +mentioned above is chosen simply because it is the quiet NaN with the lowest +value when its bit pattern is interpreted as an unsigned 64 bit integer.

    +

    The result of converting an IDL unrestricted double value to an ECMAScript + value is a Number:

    +
      +
    • +

      If the IDL unrestricted double value is a NaN, +then the Number value is NaN.

      +
    • +

      Otherwise, the Number value is +the one that represents the same numeric value as the IDL unrestricted double value.

      +
    +

    4.2.16. DOMString

    +

    An ECMAScript value V is converted to an IDL DOMString value + by running the following algorithm:

    +
      +
    1. +

      If V is null and the conversion to an IDL value is being performed due +to any of the following:

      + +

      then return the DOMString value that represents the empty string.

      +
    2. +

      Let x be ToString(V).

      +
    3. +

      Return the IDL DOMString value that represents the same sequence of code units as the one the ECMAScript String value x represents.

      +
    +

    The result of converting an IDL DOMString value to an ECMAScript + value is the String value that represents the same sequence of code units that the + IDL DOMString represents.

    +

    4.2.17. ByteString

    +

    An ECMAScript value V is converted to an IDL ByteString value + by running the following algorithm:

    +
      +
    1. +

      Let x be ToString(V).

      +
    2. +

      If the value of any element of x is greater than 255, then throw a TypeError.

      +
    3. +

      Return an IDL ByteString value +whose length is the length of x, and where the value of each element is +the value of the corresponding element of x.

      +
    +

    The result of converting an IDL ByteString value to an ECMAScript + value is a String value whose length is the length of the ByteString, + and the value of each element of which is the value of the corresponding element + of the ByteString.

    +

    4.2.18. USVString

    +

    An ECMAScript value V is converted to an IDL USVString value + by running the following algorithm:

    +
      +
    1. +

      Let string be the result of converting V to a DOMString.

      +
    2. +

      Return an IDL USVString value +that is the result of converting string to a sequence of Unicode scalar values.

      +
    +

    An IDL USVString value is converted to an ECMAScript value by running the following algorithm:

    +
      +
    1. +

      Let scalarValues be the sequence of Unicode scalar values the USVString represents.

      +
    2. +

      Let string be the sequence of code units that results from encoding scalarValues in UTF-16.

      +
    3. +

      Return the String value that represents the same sequence of code units as string.

      +
    +

    4.2.19. object

    +

    IDL object values are represented by ECMAScript Object values.

    +

    An ECMAScript value V is converted to an IDL object value + by running the following algorithm:

    +
      +
    1. +

      If Type(V) is not Object, then throw a TypeError.

      +
    2. +

      Return the IDL object value that is a reference to the same object as V.

      +
    +

    The result of converting an IDL object value to an ECMAScript + value is the Object value that represents a reference to the same object that the + IDL object represents.

    +

    4.2.20. Interface types

    +

    IDL interface type values are represented by ECMAScript Object or Function values.

    +

    An ECMAScript value V is converted to an IDL interface type value + by running the following algorithm (where I is the interface):

    +
      +
    1. +

      If Type(V) is not Object, then throw a TypeError.

      +
    2. +

      If V is a platform object that implements I, then return the IDL interface type value that represents a reference to that platform object.

      +
    3. +

      If V is a user object that is considered to implement I according to the rules in §4.9 User objects implementing callback interfaces, then return the IDL interface type value that represents a reference to that +user object, with the incumbent settings object as the callback context.

      +
    4. +

      Throw a TypeError.

      +
    +

    The result of converting an IDL interface type value to an ECMAScript value is the Object value that represents a reference to the same object that the IDL interface type value represents.

    +

    4.2.21. Dictionary types

    +

    IDL dictionary type values are represented +by ECMAScript Object values. Properties on +the object (or its prototype chain) correspond to dictionary members.

    +

    An ECMAScript value V is converted to an IDL dictionary type value + by running the following algorithm (where D is the dictionary):

    +
      +
    1. +

      If Type(V) is not Undefined, Null or Object, then throw a TypeError.

      +
    2. +

      If V is a native RegExp object, then throw a TypeError.

      +
    3. +

      Let dict be an empty dictionary value of type D; +every dictionary member is initially considered to be not present.

      +
    4. +

      Let dictionaries be a list consisting of D and all of D’s inherited dictionaries, +in order from least to most derived.

      +
    5. +

      For each dictionary dictionary in dictionaries, in order:

      +
        +
      1. +

        For each dictionary member member declared on dictionary, in lexicographical order:

        +
          +
        1. +

          Let key be the identifier of member.

          +
        2. +

          Let value be an ECMAScript value, depending on Type(V):

          +
          +
          +

          Undefined

          +
          +

          Null

          +
          +

          value is undefined.

          +
          +

          anything else

          +
          +

          value is the result of calling the [[Get]] internal method on V with property name key.

          +
          +
        3. +

          If value is not undefined, then:

          +
            +
          1. +

            Let idlValue be the result of converting value to an IDL value whose type is the type member is declared to be of.

            +
          2. +

            Set the dictionary member on dict with key name key to the value idlValue. This dictionary member is considered to be present.

            +
          +
        4. +

          Otherwise, if value is undefined but the dictionary member has a default value, then:

          +
            +
          1. +

            Let idlValue be the dictionary member’s default value.

            +
          2. +

            Set the dictionary member on dict with key name key to the value idlValue. This dictionary member is considered to be present.

            +
          +
        5. +

          Otherwise, if value is undefined and the dictionary member is a required dictionary member, then throw a TypeError.

          +
        +
      +
    6. +

      Return dict.

      +
    +

    Note: The order that dictionary members are looked +up on the ECMAScript object are not necessarily the same as the object’s property enumeration order.

    +

    An IDL dictionary value V is converted to an ECMAScript Object value + by running the following algorithm (where D is the dictionary):

    +
      +
    1. +

      Let O be a new Object value created as if by the expression ({}).

      +
    2. +

      Let dictionaries be a list consisting of D and all of D’s inherited dictionaries, +in order from least to most derived.

      +
    3. +

      For each dictionary dictionary in dictionaries, in order:

      +
        +
      1. +

        For each dictionary member member declared on dictionary, in lexicographical order:

        +
          +
        1. +

          Let key be the identifier of member.

          +
        2. +

          If the dictionary member named key is present in V, then:

          +
            +
          1. +

            Let idlValue be the value of member on V.

            +
          2. +

            Let value be the result of converting idlValue to an ECMAScript value.

            +
          3. +

            Call CreateDataProperty(O, key, value.

            +
          +
        +
      +
    4. +

      Return O.

      +
    +

    4.2.22. Enumeration types

    +

    IDL enumeration types are represented by ECMAScript String values.

    +

    An ECMAScript value V is converted to an IDL enumeration type value as follows (where E is the enumeration):

    +
      +
    1. +

      Let S be the result of calling ToString(V).

      +
    2. +

      If S is not one of E’s enumeration values, then throw a TypeError.

      +
    3. +

      Return the enumeration value of type E that is equal to S.

      +
    +

    The result of converting an IDL enumeration type value to an ECMAScript + value is the String value that represents the same sequence of code units as + the enumeration value.

    +

    4.2.23. Callback function types

    +

    IDL callback function types are represented by ECMAScript Function objects, except in the [TreatNonObjectAsNull] case, +when they can be any object.

    +

    An ECMAScript value V is converted to an IDL callback function type value + by running the following algorithm:

    +
      +
    1. +

      If the result of calling IsCallable(V) is false and the conversion to an IDL value +is not being performed due +to V being assigned to an attribute whose type is a nullable callback function that is annotated with [TreatNonObjectAsNull], +then throw a TypeError.

      +
    2. +

      Return the IDL callback function type value +that represents a reference to the same object that V represents, with the incumbent settings object as the callback context.

      +
    +

    The result of converting an IDL callback function type value to an ECMAScript value is a reference to the same object + that the IDL callback function type value represents.

    +

    4.2.24. Nullable types — T?

    +

    IDL nullable type values are represented +by values of either the ECMAScript type corresponding to the inner IDL type, or +the ECMAScript null value.

    +

    An ECMAScript value V is converted to an IDL nullable type T? value (where T is the inner type) as follows:

    +
      +
    1. +

      If Type(V) is not Object, and +the conversion to an IDL value is being performed due +to V being assigned to an attribute whose type is a nullable callback function that is annotated with [TreatNonObjectAsNull], +then return the IDL nullable type T? value null.

      +
    2. +

      Otherwise, if V is null or undefined, then return the IDL nullable type T? value null.

      +
    3. +

      Otherwise, return the result of converting V using the rules for the inner IDL type T.

      +
    +

    The result of converting an IDL nullable type value to an ECMAScript value is:

    + +

    4.2.25. Sequences — sequence<T>

    +

    IDL sequence<T> values are represented by +ECMAScript Array values.

    +

    An ECMAScript value V is converted to an IDL sequence<T> value as follows:

    +
      +
    1. +

      If V is not an object, throw a TypeError.

      +
    2. +

      If V is a native RegExp object, throw a TypeError.

      +
    3. +

      Let method be the result of GetMethod(V, @@iterator).

      +
    4. +

      ReturnIfAbrupt(method).

      +
    5. +

      If method is undefined, throw a TypeError.

      +
    6. +

      Return the result of +.

      +
    +

    An IDL sequence value S of type sequence<T> is converted to an ECMAScript Array object as follows:

    +
      +
    1. +

      Let n be the length of S.

      +
    2. +

      Let A be a new Array object created as if by the expression [].

      +
    3. +

      Initialize i to be 0.

      +
    4. +

      While i < n:

      +
        +
      1. +

        Let V be the value in S at index i.

        +
      2. +

        Let E be the result of converting V to an ECMAScript value.

        +
      3. +

        Let P be the result of calling ToString(i).

        +
      4. +

        Call CreateDataProperty(A, P, E).

        +
      5. +

        Set i to i + 1.

        +
      +
    5. +

      Return A.

      +
    +
    4.2.25.1. Creating a sequence from an iterable
    +

    To create an IDL value of type sequence<T> given an +iterable iterable and an iterator getter method, perform the following steps:

    +
      +
    1. +

      Let iter be GetIterator(iterable, method).

      +
    2. +

      ReturnIfAbrupt(iter).

      +
    3. +

      Initialize i to be 0.

      +
    4. +

      Repeat

      +
        +
      1. +

        Let next be IteratorStep(iter).

        +
      2. +

        ReturnIfAbrupt(next).

        +
      3. +

        If next is false, +then return an IDL sequence value of type sequence<T> of length i, where the value of the element +at index j is Sj.

        +
      4. +

        Let nextItem be IteratorValue(next).

        +
      5. +

        ReturnIfAbrupt(nextItem).

        +
      6. +

        Initialize Si to the result of converting nextItem to an IDL value of type T.

        +
      7. +

        Set i to i + 1.

        +
      +
    +
    + +

    The following interface defines + an attribute of a sequence + type as well as an operation with an argument of a sequence type.

    +
    interface Canvas {
    +        
    +  sequence<DOMString> getSupportedImageCodecs();
    +        
    +  void drawPolygon(sequence<double> coordinates);
    +  sequence<double> getLastDrawnPolygon();
    +        
    +  // ...
    +};
    +
    +

    In an ECMAScript implementation of this interface, an Array object with elements of type String is used to + represent a sequence<DOMString>, while an Array with elements of type Number represents a sequence<double>. The Array objects are effectively passed by + value; every time the getSupportedImageCodecs() function is called a new Array is + returned, and whenever an Array is + passed to drawPolygon no reference + will be kept after the call completes.

    +
    // Obtain an instance of Canvas.  Assume that getSupportedImageCodecs()
    +// returns a sequence with two DOMString values: "image/png" and "image/svg+xml".
    +var canvas = getCanvas();
    +        
    +// An Array object of length 2.
    +var supportedImageCodecs = canvas.getSupportedImageCodecs();
    +        
    +// Evaluates to "image/png".
    +supportedImageCodecs[0];
    +        
    +// Each time canvas.getSupportedImageCodecs() is called, it returns a
    +// new Array object.  Thus modifying the returned Array will not
    +// affect the value returned from a subsequent call to the function.
    +supportedImageCodecs[0] = "image/jpeg";
    +        
    +// Evaluates to "image/png".
    +canvas.getSupportedImageCodecs()[0];
    +        
    +// This evaluates to false, since a new Array object is returned each call.
    +canvas.getSupportedImageCodecs() == canvas.getSupportedImageCodecs();
    +        
    +// An Array of Numbers...
    +var a = [0, 0, 100, 0, 50, 62.5];
    +        
    +// ...can be passed to a platform object expecting a sequence<double>.
    +canvas.drawPolygon(a);
    +        
    +// Each element will be converted to a double by first calling ToNumber().
    +// So the following call is equivalent to the previous one, except that
    +// "hi" will be alerted before drawPolygon() returns.
    +a = [false, '',
    +     { valueOf: function() { alert('hi'); return 100; } }, 0,
    +     '50', new Number(62.5)];
    +canvas.drawPolygon(s);
    +        
    +// Modifying an Array that was passed to drawPolygon() is guaranteed not to
    +// have an effect on the Canvas, since the Array is effectively passed by value.
    +a[4] = 20;
    +var b = canvas.getLastDrawnPolygon();
    +alert(b[4]);    // This would alert "50".
    +
    +

    4.2.26. Promise types — Promise<T>

    +

    IDL promise type values are +represented by ECMAScript Promise objects.

    +

    An ECMAScript value V is converted to an IDL Promise<T> value as follows:

    +
      +
    1. +

      Let resolve be the original value of %Promise%.resolve.

      +

      ECMAScript should grow a %Promise_resolve% well-known intrinsic object that can be referenced here.

      +
    2. +

      Let promise be the result of calling resolve with %Promise% as the this value and V as the single argument value.

      +
    3. +

      Return the IDL promise type value that is a reference to the +same object as promise.

      +
    +

    The result of converting an IDL promise type value to an ECMAScript + value is the Promise value that represents a reference to the same object that the + IDL promise type represents.

    +

    One can perform some steps once a promise is settled. +There can be one or two sets of steps to perform, covering when the promise is fulfilled, rejected, or both. +When a specification says to perform some steps once a promise is settled, the following steps +must be followed:

    +
      +
    1. +

      Let promise be the promise object of type Promise<T>.

      +
    2. +

      Let onFulfilled be a new function object whose +behavior when invoked is as follows:

      +
        +
      1. +

        If T is void, then:

        +
          +
        1. +

          Return the result of performing any steps that were required to be run if the promise was fulfilled.

          +
        +
      2. +

        Otherwise, T is a type other than void:

        +
          +
        1. +

          Let V be the first argument to onFulfilled.

          +
        2. +

          Let value be the result of converting V to an IDL value of type T.

          +
        3. +

          If there are no steps that are required to be run if the promise was fulfilled, then +return undefined.

          +
        4. +

          Otherwise, return the result of performing any steps that were required to be run if the promise was fulfilled, +with value as the promise’s value.

          +
        +
      +
    3. +

      Let onRejected be a new function object whose +behavior when invoked is as follows:

      +
        +
      1. +

        Let R be the first argument to onRejected.

        +
      2. +

        Let reason be the result of converting R to an IDL value of type any.

        +
      3. +

        If there are no steps that are required to be run if the promise was rejected, then +return undefined.

        +
      4. +

        Otherwise, return the result of performing any steps that were required to be run if the promise was rejected, +with reason as the rejection reason.

        +
      +
    4. +

      Let then be the result of calling the internal [[Get]] method of promise with property name “then”.

      +
    5. +

      If then is not callable, then throw a TypeError.

      +
    6. +

      Return the result of calling then with promise as the this value and onFulfilled and onRejected as its two arguments.

      +
    +

    Include an example of how to write spec text using this term.

    +

    4.2.27. Union types

    +

    IDL union type values are +represented by ECMAScript values that correspond to the union’s member types.

    +

    To convert an ECMAScript value V to an IDL union type value is done as follows:

    +
      +
    1. +

      If the union type includes a nullable type and V is null or undefined, +then return the IDL value null.

      +
    2. +

      Let types be the flattened member types of the union type.

      +
    3. +

      If V is null or undefined, and types includes a dictionary type, then return the +result of converting V to that dictionary type.

      +
    4. +

      If V is a platform object, then:

      +
        +
      1. +

        If types includes an interface type that V implements, then return the IDL value that is a reference to the object V.

        +
      2. +

        If types includes object, then return the IDL value +that is a reference to the object V.

        +
      +
    5. +

      If V is a native RegExp object, then:

      +
        +
      1. +

        If types includes RegExp, then return the +result of converting V to RegExp.

        +
      2. +

        If types includes object, then return the IDL value +that is a reference to the object V.

        +
      +
    6. +

      If V is a DOMException platform object, then:

      +
        +
      1. +

        If types includes DOMException or Error, then return the +result of converting V to that type.

        +
      2. +

        If types includes object, then return the IDL value +that is a reference to the object V.

        +
      +
    7. +

      If V is a native Error object (that is, it has an [[ErrorData]] internal slot), then:

      +
        +
      1. +

        If types includes Error, then return the +result of converting V to Error.

        +
      2. +

        If types includes object, then return the IDL value +that is a reference to the object V.

        +
      +
    8. +

      If V is an object with an [[ArrayBufferData]] internal slot, then:

      +
        +
      1. +

        If types includes ArrayBuffer, then return the +result of converting V to ArrayBuffer.

        +
      2. +

        If types includes object, then return the IDL value +that is a reference to the object V.

        +
      +
    9. +

      If V is an object with a [[DataView]] internal slot, then:

      +
        +
      1. +

        If types includes DataView, then return the +result of converting V to DataView.

        +
      2. +

        If types includes object, then return the IDL value +that is a reference to the object V.

        +
      +
    10. +

      If V is an object with a [[TypedArrayName]] internal slot, then:

      +
        +
      1. +

        If types includes a typed array type whose name is the value of V’s [[TypedArrayName]] internal slot, then return the +result of converting V to that type.

        +
      2. +

        If types includes object, then return the IDL value +that is a reference to the object V.

        +
      +
    11. +

      If IsCallable(V) is true, then:

      +
        +
      1. +

        If types includes a callback function type, then return the result of converting V to that callback function type.

        +
      2. +

        If types includes object, then return the IDL value +that is a reference to the object V.

        +
      +
    12. +

      If V is any kind of object except for +a native RegExp object, then:

      +
        +
      1. +

        If types includes a sequence type, then

        +
          +
        1. +

          Let method be the result of GetMethod(V, @@iterator).

          +
        2. +

          ReturnIfAbrupt(method).

          +
        3. +

          If method is not undefined, +return the result of +.

          +
        +
      2. +

        If types includes a frozen array type, then

        +
          +
        1. +

          Let method be the result of GetMethod(V, @@iterator).

          +
        2. +

          ReturnIfAbrupt(method).

          +
        3. +

          If method is not undefined, +return the result of creating a frozen array of that type from V and method.

          +
        +
      3. +

        If types includes a dictionary type, then return the +result of converting V to that dictionary type.

        +
      4. +

        If types includes a callback interface type, then return the result of converting V to that interface type.

        +
      5. +

        If types includes object, then return the IDL value +that is a reference to the object V.

        +
      +
    13. +

      If V is a Boolean value, then:

      +
        +
      1. +

        If types includes a boolean, +then return the result of converting V to boolean.

        +
      +
    14. +

      If V is a Number value, then:

      +
        +
      1. +

        If types includes a numeric type, +then return the result of converting V to that numeric type.

        +
      +
    15. +

      If types includes a string type, +then return the result of converting V to that type.

      +
    16. +

      If types includes a numeric type, +then return the result of converting V to that numeric type.

      +
    17. +

      If types includes a boolean, +then return the result of converting V to boolean.

      +
    18. +

      Throw a TypeError.

      +
    +

    An IDL union type value is converted to an ECMAScript value as follows. If the value is an object reference to a special object that represents an ECMAScript undefined value, then it is converted to the ECMAScript undefined value. Otherwise, + the rules for converting the specific type of the IDL union type value as described in this section (§4.2 ECMAScript type mapping).

    +

    4.2.28. RegExp

    +

    IDL RegExp values are represented by +ECMAScript RegExp objects.

    +

    An ECMAScript value V is converted to an IDL RegExp value + by running the following algorithm:

    +
      +
    1. +

      If Type(V) is not Object, +or V is not a native RegExp object, +then set V to be a newly created RegExp object created as if by the +expression new RegExp(V), where RegExp is the standard built-in constructor with that name +from the current global environment.

      +

      Note: Note that this can result in an exception being thrown, if V, when converted to a string, +does not have valid regular expression syntax.

      +
    2. +

      Return the IDL RegExp value that is a reference to the same object as V.

      +
    +

    The result of converting an IDL RegExp value to an ECMAScript + value is the RegExp value that represents a reference to the same object that the + IDL RegExp represents.

    +

    4.2.29. Error

    +

    IDL Error values are represented +by native ECMAScript Error objects and +platform objects for DOMExceptions.

    +

    An ECMAScript value V is converted to an IDL Error value + by running the following algorithm:

    +
      +
    1. +

      If Type(V) is not Object, +or V does not have an [[ErrorData]] internal slot, then throw a TypeError.

      +
    2. +

      Return the IDL Error value that is a reference to the same object as V.

      +
    +

    The result of converting an IDL Error value to an ECMAScript + value is the Error value that represents a reference to the same object that the + IDL Error represents.

    +

    4.2.30. DOMException

    +

    IDL DOMException values are represented +by platform objects for DOMExceptions.

    +

    An ECMAScript value V is converted to an IDL DOMException value + by running the following algorithm:

    +
      +
    1. +

      If Type(V) is not Object, +or V is not a platform object that represents a DOMException, then throw a TypeError.

      +
    2. +

      Return the IDL DOMException value that is a reference to the same object as V.

      +
    +

    The result of converting an IDL DOMException value to an ECMAScript + value is the Object value that represents a reference to the same object that the + IDL DOMException represents.

    +

    4.2.31. Buffer source types

    +

    Values of the IDL buffer source types are represented by objects of the corresponding ECMAScript class.

    +

    An ECMAScript value V is converted to an IDL ArrayBuffer value + by running the following algorithm:

    +
      +
    1. +

      If Type(V) is not Object, +or V does not have an [[ArrayBufferData]] internal slot, +or IsDetachedBuffer(V) is true, +then throw a TypeError.

      +
    2. +

      Return the IDL ArrayBuffer value that is a reference to the same object as V.

      +
    +

    An ECMAScript value V is converted to an IDL DataView value + by running the following algorithm:

    +
      +
    1. +

      If Type(V) is not Object, +or V does not have a [[DataView]] internal slot, +then throw a TypeError.

      +
    2. +

      Return the IDL DataView value that is a reference to the same object as V.

      +
    +

    An ECMAScript value V is converted to an IDL Int8Array, Int16Array, Int32Array, Uint8Array, Uint16Array, Uint32Array, Uint8ClampedArray, Float32Array or Float64Array value +by running the following algorithm:

    +
      +
    1. +

      Let T be the IDL type V is being converted to.

      +
    2. +

      If Type(V) is not Object, +or V does not have a [[TypedArrayName]] internal slot with a value equal to the name of T, +then throw a TypeError.

      +
    3. +

      Return the IDL value of type T that is a reference to the same object as V.

      +
    +

    The result of converting an IDL value of any buffer source type to an ECMAScript value is the Object value that represents +a reference to the same object that the IDL value represents.

    +

    When getting a reference to or getting a copy of the bytes held by a buffer source that is an ECMAScript ArrayBuffer, DataView or typed array object, these steps must be followed:

    +
      +
    1. +

      Let O be the ECMAScript object that is the buffer source.

      +
    2. +

      Initialize arrayBuffer to O.

      +
    3. +

      Initialize offset to 0.

      +
    4. +

      Initialize length to 0.

      +
    5. +

      If O has a [[ViewedArrayBuffer]] internal slot, then:

      +
        +
      1. +

        Set arrayBuffer to the value of O’s [[ViewedArrayBuffer]] internal slot.

        +
      2. +

        If arrayBuffer is undefined, then throw a TypeError.

        +
      3. +

        Set offset to the value of O’s [[ByteOffset]] internal slot.

        +
      4. +

        Set length to the value of O’s [[ByteLength]] internal slot.

        +
      +
    6. +

      Otherwise, set length to the value of O’s [[ArrayBufferByteLength]] internal slot.

      +
    7. +

      If IsDetachedBuffer(O), then throw a TypeError.

      +
    8. +

      Let data be the value of O’s [[ArrayBufferData]] internal slot.

      +
    9. +

      Return a reference to or copy of (as required) the length bytes in data starting at byte offset offset.

      +
    +

    To detach an ArrayBuffer, +these steps must be followed:

    +
      +
    1. +

      Let O be the ECMAScript object that is the ArrayBuffer.

      +
    2. +

      DetachArrayBuffer(O).

      +
    +

    4.2.32. Frozen arrays — FrozenArray<T>

    +

    Values of frozen array types are represented by frozen ECMAScript Array object references.

    +

    An ECMAScript value V is converted to an IDL FrozenArray<T> value +by running the following algorithm:

    +
      +
    1. +

      Let values be the result of converting V to IDL type sequence<T>.

      +
    2. +

      Return the result of creating a frozen array from values.

      +
    +

    To create a frozen array from a sequence +of values of type T, follow these steps:

    +
      +
    1. +

      Let array be the result of converting the sequence of values to an ECMAScript value.

      +
    2. +

      Perform SetIntegrityLevel(array, "frozen").

      +
    3. +

      Return array.

      +
    +

    The result of converting an IDL FrozenArray<T> value to an ECMAScript +value is the Object value that represents a reference +to the same object that the IDL FrozenArray<T> represents.

    +
    4.2.32.1. Creating a frozen array from an iterable
    +

    To create an IDL value of type FrozenArray<T> given an +iterable iterable and an iterator getter method, perform the following steps:

    +
      +
    1. +

      Let values be the result of +.

      +
    2. +

      Return the result of creating a frozen array from values.

      +
    +

    4.3. ECMAScript-specific extended attributes

    +

    This section defines a number of extended attributes whose presence affects only the ECMAScript binding.

    +

    4.3.1. [Clamp]

    +

    If the [Clamp] extended attribute appears on an operation argument, +writable attribute or dictionary member whose type is one of the integer types, +it indicates that when an ECMAScript Number is +converted to the IDL type, out of range values will be clamped to the range +of valid values, rather than using the operators that use a modulo operation +(ToInt32, ToUint32, etc.).

    +

    The [Clamp] +extended attribute must take no arguments.

    +

    The [Clamp] extended attribute +must not appear on a read only attribute, or an attribute, operation argument or dictionary member +that is not of an integer type. It also must not +be used in conjunction with the [EnforceRange] +extended attribute.

    +

    See the rules for converting ECMAScript values to the various IDL integer +types in §4.2 ECMAScript type mapping for the specific requirements that the use of +[Clamp] entails.

    +
    + +

    In the following IDL fragment, + two operations are declared that + take three octet arguments; one uses + the [Clamp] extended attribute on all three arguments, while the other does not:

    +
    interface GraphicsContext {
    +  void setColor(octet red, octet green, octet blue);
    +  void setColorClamped([Clamp] octet red, [Clamp] octet green, [Clamp] octet blue);
    +};
    +
    +

    In an ECMAScript implementation of the IDL, a call to setColorClamped with Number values that are out of range for an octet are clamped to the range [0, 255].

    +
    // Get an instance of GraphicsContext.
    +var context = getGraphicsContext();
    +        
    +// Calling the non-[Clamp] version uses ToUint8 to coerce the Numbers to octets.
    +// This is equivalent to calling setColor(255, 255, 1).
    +context.setColor(-1, 255, 257);
    +        
    +// Call setColorClamped with some out of range values.
    +// This is equivalent to calling setColorClamped(0, 255, 255).
    +context.setColorClamped(-1, 255, 257);
    +
    +

    4.3.2. [Constructor]

    +

    If the [Constructor] extended attribute appears on an interface, it indicates that +the interface object for this interface +will have an [[Construct]] internal method, +allowing objects implementing the interface to be constructed.

    +

    Multiple [Constructor] extended +attributes may appear on a given interface.

    +

    The [Constructor] +extended attribute must either take no arguments or take an argument list. +The bare form, [Constructor], has the same meaning as +using an empty argument list, [Constructor()]. For each +[Constructor] extended attribute +on the interface, there will be a way to construct an object that implements +the interface by passing the specified arguments.

    +

    The prose definition of a constructor must +either return an IDL value of a type corresponding to the interface +the [Constructor] +extended attribute appears on, or throw an exception.

    +

    The [Constructor] and +[NoInterfaceObject] +extended attributes must not be specified on the same interface.

    +

    The [Constructor] extended attribute +must not be used on a callback interface.

    +

    See §4.6.1.1 Interface object [[Call]] method for details on how a constructor +for an interface is to be implemented.

    +
    + +

    The following IDL defines two interfaces. The second has the + [Constructor] extended + attribute, while the first does not.

    +
    interface NodeList {
    +  Node item(unsigned long index);
    +  readonly attribute unsigned long length;
    +};
    +        
    +[Constructor,
    + Constructor(double radius)]
    +interface Circle {
    +  attribute double r;
    +  attribute double cx;
    +  attribute double cy;
    +  readonly attribute double circumference;
    +};
    +
    +

    An ECMAScript implementation supporting these interfaces would + have a [[Construct]] property on the Circle interface object which would + return a new object that implements the interface. It would take + either zero or one argument. The NodeList interface object would not + have a [[Construct]] property.

    +
    var x = new Circle();      // The uses the zero-argument constructor to create a
    +                           // reference to a platform object that implements the
    +                           // Circle interface.
    +        
    +var y = new Circle(1.25);  // This also creates a Circle object, this time using
    +                           // the one-argument constructor.
    +        
    +var z = new NodeList();    // This would throw a TypeError, since no
    +                           // [Constructor] is declared.
    +
    +

    4.3.3. [EnforceRange]

    +

    If the [EnforceRange] extended attribute appears on an operation argument, +writable regular attribute or dictionary member whose type is one of the integer types, +it indicates that when an ECMAScript Number is +converted to the IDL type, out of range values will cause an exception to +be thrown, rather than converted to being a valid value using the operators that use a modulo operation +(ToInt32, ToUint32, etc.). The Number will be rounded towards zero before being checked against its range.

    +

    The [EnforceRange] +extended attribute must take no arguments.

    +

    The [EnforceRange] extended attribute +must not appear on a read only attribute, a static attribute, +or an attribute, operation argument or dictionary member +that is not of an integer type. It also must not +be used in conjunction with the [Clamp] +extended attribute.

    +

    See the rules for converting ECMAScript values to the various IDL integer +types in §4.2 ECMAScript type mapping for the specific requirements that the use of +[EnforceRange] entails.

    +
    + +

    In the following IDL fragment, + two operations are declared that + take three octet arguments; one uses + the [EnforceRange] extended attribute on all three arguments, while the other does not:

    +
    interface GraphicsContext {
    +  void setColor(octet red, octet green, octet blue);
    +  void setColorEnforcedRange([EnforceRange] octet red, [EnforceRange] octet green, [EnforceRange] octet blue);
    +};
    +
    +

    In an ECMAScript implementation of the IDL, a call to setColorEnforcedRange with Number values that are out of range for an octet will result in an exception being + thrown.

    +
    // Get an instance of GraphicsContext.
    +var context = getGraphicsContext();
    +        
    +// Calling the non-[EnforceRange] version uses ToUint8 to coerce the Numbers to octets.
    +// This is equivalent to calling setColor(255, 255, 1).
    +context.setColor(-1, 255, 257);
    +        
    +// When setColorEnforcedRange is called, Numbers are rounded towards zero.
    +// This is equivalent to calling setColor(0, 255, 255).
    +context.setColorEnforcedRange(-0.9, 255, 255.2);
    +        
    +// The following will cause a TypeError to be thrown, since even after
    +// rounding the first and third argument values are out of range.
    +context.setColorEnforcedRange(-1, 255, 256);
    +
    +

    4.3.4. [Exposed]

    +

    If the [Exposed] extended attribute appears on an interface, partial interface, namespace, partial namespace, or +an individual interface member or namespace member, +it indicates that the construct is exposed +on a particular set of global interfaces, rather than the default of +being exposed only on the primary global interface.

    +

    The [Exposed] extended attribute must either take an identifier or take an identifier list. +Each of the identifiers mentioned must be +a global name.

    +

    Every construct that the [Exposed] extended attribute can be specified on has an exposure set, +which is a set of interfaces defining which global environments the construct can be used in. +The exposure set for a given construct is defined as follows:

    +
      +
    • +

      If the [Exposed] extended attribute is specified on the construct, then the exposure set is the set of all interfaces that have a global name that is listed in the extended attribute’s argument.

      +
    • +

      If the [Exposed] extended attribute does not appear on a construct, then its exposure set is defined +implicitly, depending on the type of construct:

      +
      +
      +

      interface

      +
      +

      namespace

      +
      +

      The exposure set of the +interface or namespace only contains the primary global interface.

      +
      +

      partial interface

      +
      +

      partial namespace

      +
      +

      The exposure set of the partial +interface or namespace is the exposure set of the original interface or namespace definition.

      +
      +

      interface member

      +
      +

      The exposure set of the interface member +is the exposure set of the interface or +partial interface the member is declared on.

      +
      +

      namespace member

      +
      +

      The exposure set of the +namespace member is the exposure set of the namespace or partial namespace the member is declared on.

      +
      +
    +

    If [Exposed] appears on an overloaded operation, +then it must appear identically on all overloads.

    +

    The [Exposed] extended attribute +must not be specified on both an interface +member and a partial interface definition the interface member is declared on. +Similarly, the [Exposed] extended attribute +must not be specified on both a namespace +member and a partial namespace definition the namespace member is declared on.

    +

    If [Exposed] appears an interface member, then +the interface member’s exposure set must be a subset of the exposure set of the interface or partial interface it’s a +member of. Similarly, if [Exposed] appears on a +namespace member, then the namespace member’s exposure set must be a +subset of the exposure set of the +namespace or partial namespace it’s a member of.

    +

    An interface’s exposure set must be a subset of the exposure set of all +of the interface’s consequential interfaces.

    +

    If an interface X inherits from another interface Y then the exposure set of X must be a subset of the exposure set of Y.

    +

    An interface, namespace, interface member, or namespace member is exposed in a given ECMAScript global environment if the +ECMAScript global object implements an interface that is in the construct’s exposure set, and either:

    + +

    Note: Since it is not possible for the relevant settings object for an ECMAScript global object to change whether it is a secure context or not over time, an implementation’s +decision to create properties for an interface or interface member +can be made once, at the time the initial objects are created.

    +

    See §4.6 Interfaces, §4.6.5 Constants, §4.6.6 Attributes, §4.6.7 Operations and §4.6.8 Common iterator behavior for the specific requirements that the use of +[Exposed] entails.

    +
    + +

    [Exposed] + is intended to be used to control whether interfaces, namespaces, or individual + interface or namespace members are available for use only in workers, only in the Window, or in both.

    +

    The following IDL fragment shows how that might be achieved:

    +
    [PrimaryGlobal]
    +interface Window {
    +  // ...
    +};
    +        
    +// By using the same identifier Worker for both SharedWorkerGlobalScope
    +// and DedicatedWorkerGlobalScope, both can be addressed in an [Exposed]
    +// extended attribute at once.
    +[Global=Worker]
    +interface SharedWorkerGlobalScope : WorkerGlobalScope {
    +  // ...
    +};
    +        
    +[Global=Worker]
    +interface DedicatedWorkerGlobalScope : WorkerGlobalScope {
    +  // ...
    +};
    +        
    +// Dimensions is available for use in workers and on the main thread.
    +[Exposed=(Window,Worker), Constructor(double width, double height)]
    +interface Dimensions {
    +  readonly attribute double width;
    +  readonly attribute double height;
    +};
    +        
    +// WorkerNavigator is only available in workers.  Evaluating WorkerNavigator
    +// in the global scope of a worker would give you its interface object, while
    +// doing so on the main thread will give you a ReferenceError.
    +[Exposed=Worker]
    +interface WorkerNavigator {
    +  // ...
    +};
    +        
    +// Node is only available on the main thread.  Evaluating Node
    +// in the global scope of a worker would give you a ReferenceError.
    +interface Node {
    +  // ...
    +};
    +        
    +// MathUtils is available for use in workers and on the main thread.
    +[Exposed=(Window,Worker)]
    +namespace MathUtils {
    +  double someComplicatedFunction(double x, double y);
    +};
    +        
    +// WorkerUtils is only available in workers.  Evaluating WorkerUtils
    +// in the global scope of a worker would give you its namespace object, while
    +// doing so on the main thread will give you a ReferenceError.
    +[Exposed=Worker]
    +namespace WorkerUtils {
    +  void setPriority(double x);
    +};
    +        
    +// NodeUtils is only available in the main thread.  Evaluating NodeUtils
    +// in the global scope of a worker would give you a ReferenceError.
    +namespace NodeUtils {
    +  DOMString getAllText(Node node);
    +};
    +
    +
    +

    4.3.5. [ImplicitThis]

    +

    If the [ImplicitThis] extended attribute appears on an interface, +it indicates that when a Function corresponding +to one of the interface’s operations is invoked with the null or undefined value as the this value, that the ECMAScript global +object will be used as the this value instead. +This is regardless of whether the calling code is in strict mode.

    +

    The [ImplicitThis] +extended attribute must take no arguments.

    +

    See §4.6.7 Operations for the specific requirements that the use of +[ImplicitThis] entails.

    +

    Note: The [ImplicitThis] extended attribute is intended for use on the Window interface.

    +
    + +

    In the following example, the Window interface is defined + with the [ImplicitThis] extended attribute.

    +
    [ImplicitThis]
    +interface Window {
    +  // ...
    +  attribute DOMString name;
    +  void alert(DOMString message);
    +};
    +
    +

    Since the Window object is used as + the ECMAScript global object, calls to its functions can be made + without an explicit object, even in strict mode:

    +
    "use strict";
    +        
    +window.alert("hello");      // Calling alert with an explicit window object works.
    +alert("hello");             // This also works, even though we are in strict mode.
    +alert.call(null, "hello");  // As does passing null explicitly as the this value.
    +        
    +// This does not apply to getters for attributes on the interface, though.
    +// The following will throw a TypeError.
    +Object.getOwnPropertyDescriptor(Window.prototype, "name").get.call(null);
    +
    +

    4.3.6. [Global] and [PrimaryGlobal]

    +

    If the [Global] +or [PrimaryGlobal] extended attribute appears on an interface, +it indicates that objects implementing this interface can +be used as the global object in an ECMAScript environment, +and that the structure of the prototype chain and how +properties corresponding to interface members will be reflected on the prototype objects will be different from other +interfaces. Specifically:

    +
      +
    1. +

      Any named properties will be exposed on an object in the prototype chain – the named properties object – +rather than on the object itself.

      +
    2. +

      Interface members from the interface (or consequential interfaces) +will correspond to properties on the object itself rather than on interface prototype objects.

      +
    +
    +

    Placing named properties on an object in the prototype chain + is done so that variable declarations and bareword assignments + will shadow the named property with a property on the global + object itself.

    +

    Placing properties corresponding to interface members on + the object itself will mean that common feature detection + methods like the following will work:

    +
    var indexedDB = window.indexedDB || window.webkitIndexedDB ||
    +                window.mozIndexedDB || window.msIndexedDB;
    +        
    +var requestAnimationFrame = window.requestAnimationFrame ||
    +                            window.mozRequestAnimationFrame || ...;
    +

    Because of the way variable declarations are handled in + ECMAScript, the code above would result in the window.indexedDB and window.requestAnimationFrame evaluating + to undefined, as the shadowing variable + property would already have been created before the + assignment is evaluated.

    +
    +

    If the [Global] or +[PrimaryGlobal] extended attributes is used on an interface, then:

    + +

    If [Global] or [PrimaryGlobal] is specified on +a partial interface definition, then that partial interface definition must +be the part of the interface definition that defines +the named property getter.

    +

    The [Global] and [PrimaryGlobal] extended attribute must not +be used on an interface that can have more +than one object implementing it in the same ECMAScript global environment.

    +

    Note: This is because the named properties object, +which exposes the named properties, is in the prototype chain, and it would not make +sense for more than one object’s named properties to be exposed on an object that +all of those objects inherit from.

    +

    If an interface is declared with the [Global] or +[PrimaryGlobal] extended attribute, then +there must not be more than one interface member across +the interface and its consequential interfaces with the same identifier. +There also must not be more than +one stringifier, +more than one serializer, +or more than one iterable declaration, maplike declaration or setlike declaration across those interfaces.

    +

    Note: This is because all of the members of the interface and its consequential +interfaces get flattened down on to the object that implements the interface.

    +

    The [Global] and +[PrimaryGlobal] extended attributes +can also be used to give a name to one or more global interfaces, +which can then be referenced by the [Exposed] +extended attribute.

    +

    The [Global] and +[PrimaryGlobal] +extended attributes must either take no arguments or take an identifier list.

    +

    If the [Global] or +[PrimaryGlobal] extended attribute is declared with an identifier list argument, then those identifiers are the interface’s global names; otherwise, the interface has +a single global name, which is the interface’s identifier.

    +

    Note: The identifier argument list exists so that more than one global interface can +be addressed with a single name in an [Exposed] extended attribute.

    +

    The [Global] and +[PrimaryGlobal] extended attributes must not be declared on the same +interface. The [PrimaryGlobal] +extended attribute must be declared on +at most one interface. The interface [PrimaryGlobal] +is declared on, if any, is known as the primary global interface.

    +

    See §4.6.4 Named properties object, §4.8.3 Platform object [[GetOwnProperty]] method and §4.8.7 Platform object [[DefineOwnProperty]] method for the specific requirements that the use of +[Global] and [PrimaryGlobal] +entails for named properties, +and §4.6.5 Constants, §4.6.6 Attributes and §4.6.7 Operations for the requirements relating to the location of properties +corresponding to interface members.

    +
    + +

    The [PrimaryGlobal] extended attribute is intended + to be used by the Window interface. + ([Global] is intended to be used by worker global interfaces.) + The Window interface exposes frames as properties on the Window object. Since the Window object also serves as the + ECMAScript global object, variable declarations or assignments to the named properties + will result in them being replaced by the new value. Variable declarations for + attributes will not create a property that replaces the existing one.

    +
    [PrimaryGlobal]
    +interface Window {
    +  getter any (DOMString name);
    +  attribute DOMString name;
    +  // ...
    +};
    +
    +

    The following HTML document illustrates how the named properties on the Window object can be shadowed, and how + the property for an attribute will not be replaced when declaring + a variable of the same name:

    +
    <!DOCTYPE html>
    +<title>Variable declarations and assignments on Window</title>
    +<iframe name=abc></iframe>
    +<!-- Shadowing named properties -->
    +<script>
    +  window.abc;    // Evaluates to the iframe’s Window object.
    +  abc = 1;       // Shadows the named property.
    +  window.abc;    // Evaluates to 1.
    +</script>
    +        
    +<!-- Preserving properties for IDL attributes -->
    +<script>
    +  Window.prototype.def = 2;         // Places a property on the prototype.
    +  window.hasOwnProperty("length");  // Evaluates to true.
    +  length;                           // Evaluates to 1.
    +  def;                              // Evaluates to 2.
    +</script>
    +<script>
    +  var length;                       // Variable declaration leaves existing property.
    +  length;                           // Evaluates to 1.
    +  var def;                          // Variable declaration creates shadowing property.
    +  def;                              // Evaluates to undefined.
    +</script>
    +
    +

    4.3.7. [LegacyArrayClass]

    +

    If the [LegacyArrayClass] extended attribute appears on an interface that is not defined to inherit from another, it indicates that the internal [[Prototype]] +property of its interface prototype object will be the Array prototype object rather than +the Object prototype object. This allows Array methods to be used more easily +with objects implementing the interface.

    +

    The [LegacyArrayClass] extended attribute +must take no arguments. +It must not be used on an interface that +has any inherited interfaces.

    +

    Note: Interfaces using [LegacyArrayClass] will +need to define a “length” attribute of type unsigned long that exposes the length +of the array-like object, in order for the inherited Array methods to operate correctly. Such interfaces would typically also support indexed properties, +which would provide access to the array elements.

    +

    See §4.6.3 Interface prototype object for the +specific requirements that the use of [LegacyArrayClass] +entails.

    +
    + +

    The following IDL fragment defines two interfaces that use [LegacyArrayClass].

    +
    [LegacyArrayClass]
    +interface ItemList {
    +  attribute unsigned long length;
    +  getter object getItem(unsigned long index);
    +  setter object setItem(unsigned long index, object item);
    +};
    +        
    +[LegacyArrayClass]
    +interface ImmutableItemList {
    +  readonly attribute unsigned long length;
    +  getter object getItem(unsigned long index);
    +};
    +
    +

    In an ECMAScript implementation of the above two interfaces, + with appropriate definitions for getItem, setItem and removeItem, Array methods to inspect and + modify the array-like object can be used.

    +
    var list = getItemList();  // Obtain an instance of ItemList.
    +        
    +list.concat();             // Clone the ItemList into an Array.
    +list.pop();                // Remove an item from the ItemList.
    +list.unshift({ });         // Insert an item at index 0.
    +

    ImmutableItemList has a read only + length attribute and no indexed property setter. The + mutating Array methods will generally not + succeed on objects implementing ImmutableItemList. + The exact behavior depends on the definition of the Array methods themselves.

    +
    +

    4.3.8. [LegacyUnenumerableNamedProperties]

    +

    If the [LegacyUnenumerableNamedProperties] extended attribute appears on a interface that supports named properties, +it indicates that all the interface’s named properties are unenumerable.

    +

    The [LegacyUnenumerableNamedProperties] +extended attribute must take no arguments and must not appear on an interface +that does not define a named property getter.

    +

    If the [LegacyUnenumerableNamedProperties] +extended attribute is specified on an interface, then it applies to all its derived interfaces and +must not be specified on any of them.

    +

    See §4.8.10 Property enumeration for the specific requirements that the use of +[LegacyUnenumerableNamedProperties] +entails.

    +

    4.3.9. [LenientSetter]

    +

    If the [LenientSetter] extended attribute appears on a read only regular attribute, +it indicates that a no-op setter will be generated for the attribute’s +accessor property. This results in erroneous assignments to the property +in strict mode to be ignored rather than causing an exception to be thrown.

    +
    +

    Specifications should not use [LenientSetter] + unless required for compatibility reasons. Pages have been observed + where authors have attempted to polyfill an IDL attribute by assigning + to the property, but have accidentally done so even if the property + exists. In strict mode, this would cause an exception to be thrown, + potentially breaking page. Without [LenientSetter], + this could prevent a browser from shipping the feature.

    +

    Specification authors who + wish to use this feature are strongly advised to discuss this on the public-script-coord@w3.org mailing list before proceeding.

    +
    +

    The [LenientThis] extended attribute +must take no arguments. +It must not be used on anything other than +a read only regular attribute.

    +

    An attribute with the [LenientSetter] +extended attribute must not also be declared +with the [PutForwards] +or [Replaceable] extended attributes.

    +

    See the Attributes section for how +[LenientSetter] +is to be implemented.

    +
    + +

    The following IDL fragment defines an interface that uses the + [LenientSetter] extended + attribute.

    +
    interface Example {
    +  [LenientSetter] readonly attribute DOMString x;
    +  readonly attribute DOMString y;
    +};
    +
    +

    An ECMAScript implementation that supports this interface will + have a setter on the accessor property that correspond to x, + which allows any assignment to be ignored in strict mode.

    +
    "use strict";
    +        
    +var example = getExample();  // Get an instance of Example.
    +        
    +// Fine; while we are in strict mode, there is a setter that is a no-op.
    +example.x = 1;
    +        
    +// Throws a TypeError, since we are in strict mode and there is no setter.
    +example.y = 1;
    +
    +

    4.3.10. [LenientThis]

    +

    If the [LenientThis] extended attribute appears on a regular attribute, +it indicates that invocations of the attribute’s getter or setter +with a this value that is not an +object that implements the interface on which the attribute appears will be ignored.

    +

    The [LenientThis] extended attribute +must take no arguments. +It must not be used on a static attribute.

    +

    Specifications should not use [LenientThis] + unless required for compatibility reasons. Specification authors who + wish to use this feature are strongly advised to discuss this on the public-script-coord@w3.org mailing list before proceeding.

    +

    See the Attributes section for how +[LenientThis] +is to be implemented.

    +
    + +

    The following IDL fragment defines an interface that uses the + [LenientThis] extended + attribute.

    +
    interface Example {
    +  [LenientThis] attribute DOMString x;
    +  attribute DOMString y;
    +};
    +
    +

    An ECMAScript implementation that supports this interface will + allow the getter and setter of the accessor property that corresponds + to x to be invoked with something other than an Example object.

    +
    var example = getExample();  // Get an instance of Example.
    +var obj = { };
    +        
    +// Fine.
    +example.x;
    +        
    +// Ignored, since the this value is not an Example object and [LenientThis] is used.
    +Object.getOwnPropertyDescriptor(Example.prototype, "x").get.call(obj);
    +        
    +// Also ignored, since Example.prototype is not an Example object and [LenientThis] is used.
    +Example.prototype.x;
    +        
    +// Throws a TypeError, since Example.prototype is not an Example object.
    +Example.prototype.y;
    +
    +

    4.3.11. [NamedConstructor]

    +

    If the [NamedConstructor] extended attribute appears on an interface, +it indicates that the ECMAScript global object will have a property with the +specified name whose value is a constructor function that can +create objects that implement the interface. +Multiple [NamedConstructor] extended +attributes may appear on a given interface.

    +

    The [NamedConstructor] +extended attribute must either take an identifier or take a named argument list. +The first form, [NamedConstructor=identifier], has the same meaning as +using an empty argument list, [NamedConstructor=identifier()]. For each +[NamedConstructor] extended attribute +on the interface, there will be a way to construct an object that implements +the interface by passing the specified arguments to the constructor function +that is the value of the aforementioned property.

    +

    The identifier used for the named constructor must not +be the same as that used by an [NamedConstructor] +extended attribute on another interface, must not +be the same as an identifier of an interface +that has an interface object, +and must not be one of the reserved identifiers.

    +

    The [NamedConstructor] extended attribute +must not be used on a callback interface.

    +

    See §4.6.2 Named constructors for details on how named constructors +are to be implemented.

    +
    + +

    The following IDL defines an interface that uses the + [NamedConstructor] extended + attribute.

    +
    [NamedConstructor=Audio,
    + NamedConstructor=Audio(DOMString src)]
    +interface HTMLAudioElement : HTMLMediaElement {
    +  // ...
    +};
    +
    +

    An ECMAScript implementation that supports this interface will + allow the construction of HTMLAudioElement objects using the Audio constructor.

    +
    typeof Audio;                   // Evaluates to 'function'.
    +        
    +var a1 = new Audio();           // Creates a new object that implements
    +                                // HTMLAudioElement, using the zero-argument
    +                                // constructor.
    +        
    +var a2 = new Audio('a.flac');   // Creates an HTMLAudioElement using the
    +                                // one-argument constructor.
    +
    +

    4.3.12. [NewObject]

    +

    If the [NewObject] extended attribute appears on a regular or static operation, +then it indicates that when calling the operation, +a reference to a newly created object +must always be returned.

    +

    The [NewObject] +extended attribute must take no arguments.

    +

    The [NewObject] +extended attribute must not +be used on anything other than a regular or static operation whose return type is an interface type or +a promise type.

    +
    + +

    As an example, this extended attribute is suitable for use on + the createElement operation on the Document interface ([DOM], section 6.5), + since a new object should always be returned when + it is called.

    +
    interface Document : Node {
    +  [NewObject] Element createElement(DOMString localName);
    +  // ...
    +};
    +
    +
    +

    4.3.13. [NoInterfaceObject]

    +

    If the [NoInterfaceObject] extended attribute appears on an interface, +it indicates that an interface object will not exist for the interface in the ECMAScript binding.

    +

    The [NoInterfaceObject] extended attribute + should not be used on interfaces that are not + solely used as supplemental interfaces, + unless there are clear Web compatibility reasons for doing so. Specification authors who + wish to use this feature are strongly advised to discuss this on the public-script-coord@w3.org mailing list before proceeding.

    +

    The [NoInterfaceObject] extended attribute +must take no arguments.

    +

    If the [NoInterfaceObject] extended attribute +is specified on an interface, then the [Constructor] +extended attribute must not also be specified on that interface. +A [NamedConstructor] extended attribute is fine, +however.

    +

    The [NoInterfaceObject] extended attribute +must not be specified on an interface that has any static operations defined on it.

    +

    The [NoInterfaceObject] extended attribute +must not be specified on a callback interface unless it has a constant declared on it. +This is because callback interfaces without constants never have interface objects.

    +

    An interface that does not have the [NoInterfaceObject] extended +attribute specified must not inherit +from an interface that has the [NoInterfaceObject] extended +attribute specified.

    +

    See §4.6 Interfaces for the specific requirements that the use of +[NoInterfaceObject] entails.

    +
    + +

    The following IDL fragment defines two interfaces, one whose interface object + is exposed on the ECMAScript global object, and one whose isn’t:

    +
    interface Storage {
    +  void addEntry(unsigned long key, any value);
    +};
    +        
    +[NoInterfaceObject]
    +interface Query {
    +  any lookupEntry(unsigned long key);
    +};
    +
    +

    An ECMAScript implementation of the above IDL would allow + manipulation of Storage’s + prototype, but not Query’s.

    +
    typeof Storage;                        // evaluates to "object"
    +        
    +// Add some tracing alert() call to Storage.addEntry.
    +var fn = Storage.prototype.addEntry;
    +Storage.prototype.addEntry = function(key, value) {
    +  alert('Calling addEntry()');
    +  return fn.call(this, key, value);
    +};
    +        
    +typeof Query;                          // evaluates to "undefined"
    +var fn = Query.prototype.lookupEntry;  // exception, Query isn’t defined
    +
    +

    4.3.14. [OverrideBuiltins]

    +

    If the [OverrideBuiltins] extended attribute appears on an interface, +it indicates that for a platform object implementing the interface, +properties corresponding to all of +the object’s supported property names will appear to be on the object, +regardless of what other properties exist on the object or its +prototype chain. This means that named properties will always shadow +any properties that would otherwise appear on the object. +This is in contrast to the usual behavior, which is for named properties +to be exposed only if there is no property with the +same name on the object itself or somewhere on its prototype chain.

    +

    The [OverrideBuiltins] +extended attribute must take no arguments and must not appear on an interface +that does not define a named property getter or that also is declared with the [Global] +or [PrimaryGlobal] +extended attribute. If the extended attribute is specified on +a partial interface definition, then that partial interface definition must +be the part of the interface definition that defines +the named property getter.

    +

    See §4.8.1 Indexed and named properties and §4.8.7 Platform object [[DefineOwnProperty]] method for the specific requirements that the use of +[OverrideBuiltins] entails.

    +
    + +

    The following IDL fragment defines two interfaces, + one that has a named property getter and one that does not.

    +
    interface StringMap {
    +  readonly attribute unsigned long length;
    +  getter DOMString lookup(DOMString key);
    +};
    +        
    +[OverrideBuiltins]
    +interface StringMap2 {
    +  readonly attribute unsigned long length;
    +  getter DOMString lookup(DOMString key);
    +};
    +
    +

    In an ECMAScript implementation of these two interfaces, + getting certain properties on objects implementing + the interfaces will result in different values:

    +
    // Obtain an instance of StringMap.  Assume that it has "abc", "length" and
    +// "toString" as supported property names.
    +var map1 = getStringMap();
    +        
    +// This invokes the named property getter.
    +map1.abc;
    +        
    +// This fetches the "length" property on the object that corresponds to the
    +// length attribute.
    +map1.length;
    +        
    +// This fetches the "toString" property from the object’s prototype chain.
    +map1.toString;
    +        
    +// Obtain an instance of StringMap2.  Assume that it also has "abc", "length"
    +// and "toString" as supported property names.
    +var map2 = getStringMap2();
    +        
    +// This invokes the named property getter.
    +map2.abc;
    +        
    +// This also invokes the named property getter, despite the fact that the "length"
    +// property on the object corresponds to the length attribute.
    +map2.length;
    +        
    +// This too invokes the named property getter, despite the fact that "toString" is
    +// a property in map2’s prototype chain.
    +map2.toString;
    +
    +

    4.3.15. [PutForwards]

    +

    If the [PutForwards] extended attribute appears on a read only regular attribute declaration whose type is +an interface type, +it indicates that assigning to the attribute will have specific behavior. +Namely, the assignment is “forwarded” to the attribute (specified by +the extended attribute argument) on the object that is currently +referenced by the attribute being assigned to.

    +

    The [PutForwards] extended +attribute must take an identifier. +Assuming that:

    + +

    then there must be another attribute B declared on J whose identifier is N. Assignment of a value to the attribute A on an object implementing I will result in that value +being assigned to attribute B of the object that A references, instead.

    +

    Note that [PutForwards]-annotated attributes can be +chained. That is, an attribute with the [PutForwards] extended attribute can refer to an attribute that itself has that extended attribute. +There must not exist a cycle in a +chain of forwarded assignments. A cycle exists if, when following +the chain of forwarded assignments, a particular attribute on +an interface is +encountered more than once.

    +

    An attribute with the [PutForwards] +extended attribute must not also be declared +with the [LenientSetter] or +[Replaceable] extended attributes.

    +

    The [PutForwards] +extended attribute must not be used +on an attribute that +is not read only.

    +

    The [PutForwards] extended attribute +must not be used on a static attribute.

    +

    The [PutForwards] extended attribute +must not be used on an attribute declared on +a callback interface.

    +

    See the Attributes section for how +[PutForwards] +is to be implemented.

    +
    + +

    The following IDL fragment defines interfaces for names and people. + The [PutForwards] extended + attribute is used on the name attribute + of the Person interface to indicate + that assignments to that attribute result in assignments to the full attribute of the Person object:

    +
    interface Name {
    +  attribute DOMString full;
    +  attribute DOMString family;
    +  attribute DOMString given;
    +};
    +        
    +interface Person {
    +  [PutForwards=full] readonly attribute Name name;
    +  attribute unsigned short age;
    +};
    +
    +

    In the ECMAScript binding, this would allow assignments to the + “name” property:

    +
    var p = getPerson();           // Obtain an instance of Person.
    +        
    +p.name = 'John Citizen';       // This statement...
    +p.name.full = 'John Citizen';  // ...has the same behavior as this one.
    +
    +

    4.3.16. [Replaceable]

    +

    If the [Replaceable] extended attribute appears on a read only regular attribute, +it indicates that setting the corresponding property on the platform object will result in +an own property with the same name being created on the object +which has the value being assigned. This property will shadow +the accessor property corresponding to the attribute, which +exists on the interface prototype object.

    +

    The [Replaceable] +extended attribute must take no arguments.

    +

    An attribute with the [Replaceable] +extended attribute must not also be declared +with the [LenientSetter] or +[PutForwards] extended attributes.

    +

    The [Replaceable] +extended attribute must not be used +on an attribute that +is not read only.

    +

    The [Replaceable] extended attribute +must not be used on a static attribute.

    +

    The [Replaceable] extended attribute +must not be used on an attribute declared on +a callback interface.

    +

    See §4.6.6 Attributes for the specific requirements that the use of +[Replaceable] entails.

    +
    + +

    The following IDL fragment defines an interface with an operation that increments a counter, and an attribute that exposes the counter’s value, which is initially 0:

    +
    interface Counter {
    +  [Replaceable] readonly attribute unsigned long value;
    +  void increment();
    +};
    +
    +

    Assigning to the “value” property + on a platform object implementing Counter will shadow the property that corresponds to the attribute:

    +
    var counter = getCounter();                              // Obtain an instance of Counter.
    +counter.value;                                           // Evaluates to 0.
    +        
    +counter.hasOwnProperty("value");                         // Evaluates to false.
    +Object.getPrototypeOf(counter).hasOwnProperty("value");  // Evaluates to true.
    +        
    +counter.increment();
    +counter.increment();
    +counter.value;                                           // Evaluates to 2.
    +        
    +counter.value = 'a';                                     // Shadows the property with one that is unrelated
    +                                                         // to Counter::value.
    +        
    +counter.hasOwnProperty("value");                         // Evaluates to true.
    +        
    +counter.increment();
    +counter.value;                                           // Evaluates to 'a'.
    +        
    +delete counter.value;                                    // Reveals the original property.
    +counter.value;                                           // Evaluates to 3.
    +
    +

    4.3.17. [SameObject]

    +

    If the [SameObject] extended attribute appears on a read only attribute, then it +indicates that when getting the value of the attribute on a given +object, the same value must always +be returned.

    +

    The [SameObject] +extended attribute must take no arguments.

    +

    The [SameObject] +extended attribute must not +be used on anything other than a read only attribute whose type is an interface type or object.

    +
    + +

    As an example, this extended attribute is suitable for use on + the implementation attribute on the Document interface ([DOM], section 6.5), + since the same object is always returned for a given Document object.

    +
    interface Document : Node {
    +  [SameObject] readonly attribute DOMImplementation implementation;
    +  // ...
    +};
    +
    +
    +

    4.3.18. [SecureContext]

    +

    If the [SecureContext] extended attribute appears on an interface, partial interface, namespace, partial namespace, interface member, or namespace member, +it indicates that the construct is exposed +only within a secure context.

    +

    The [SecureContext] +extended attribute must take no arguments.

    +

    The [SecureContext] +extended attribute must not +be used on anything other than an interface, partial interface, namespace, partial namespace, interface member, or namespace member.

    +

    Whether a construct that the [SecureContext] extended attribute can be specified on is available only in secure contexts is defined as follows:

    + +

    Note: Whether a construct is available only in secure contexts influences whether it is exposed in a given +ECMAScript global environment.

    +

    If [SecureContext] appears on an overloaded operation, +then it must appear on all overloads.

    +

    The [SecureContext] extended attribute +must not be specified on both an interface member and the +interface or partial interface definition the interface member is declared on, or +on both a namespace member and the namespace or partial namespace definition the +namespace member is declared on.

    +

    An interface without the [SecureContext] extended attribute +must not inherit from another interface +that does specify [SecureContext].

    +
    + +

    The following IDL fragment defines an interface + with one operation that is executable from all + contexts, and two which are executable only from secure contexts.

    +
    interface PowerfulFeature {
    +  // This call will succeed in all contexts.
    +  Promise <Result> calculateNotSoSecretResult();
    +        
    +  // This operation will not be exposed to a non-secure context. In such a context,
    +  // there will be no "calculateSecretResult" property on PowerfulFeature.prototype.
    +  [SecureContext] Promise<Result> calculateSecretResult();
    +        
    +  // The same applies here: the attribute will not be exposed to a non-secure context,
    +  // and in a non-secure context there will be no "secretBoolean" property on
    +  // PowerfulFeature.prototype.
    +  [SecureContext] readonly attribute boolean secretBoolean;
    +};
    +
    +
    +

    4.3.19. [TreatNonObjectAsNull]

    +

    If the [TreatNonObjectAsNull] extended attribute appears on a callback function, +then it indicates that any value assigned to an attribute whose type is a nullable callback function that is not an object will be converted to +the null value.

    +

    Specifications should not use [TreatNonObjectAsNull] + unless required to specify the behavior of legacy APIs or for consistency with these + APIs. Specification authors who + wish to use this feature are strongly advised to discuss this on the public-script-coord@w3.org mailing list before proceeding. At the time of writing, the only known + valid use of [TreatNonObjectAsNull] + is for the callback functions used as the type + of event handler IDL attributes such as onclick and onerror.

    +

    See §4.2.24 Nullable types — T? for the specific requirements that the use of +[TreatNonObjectAsNull] entails.

    +
    + +

    The following IDL fragment defines an interface that has one + attribute whose type is a [TreatNonObjectAsNull]-annotated callback function and another whose type is a callback function without the extended attribute:

    +
    callback OccurrenceHandler = void (DOMString details);
    +        
    +[TreatNonObjectAsNull]
    +callback ErrorHandler = void (DOMString details);
    +        
    +interface Manager {
    +  attribute OccurrenceHandler? handler1;
    +  attribute ErrorHandler? handler2;
    +};
    +
    +

    In an ECMAScript implementation, assigning a value that is not + an object (such as a Number value) + to handler1 will have different behavior from that when assigning + to handler2:

    +
    var manager = getManager();  // Get an instance of Manager.
    +        
    +manager.handler1 = function() { };
    +manager.handler1;            // Evaluates to the function.
    +        
    +try {
    +  manager.handler1 = 123;    // Throws a TypeError.
    +} catch (e) {
    +}
    +        
    +manager.handler2 = function() { };
    +manager.handler2;            // Evaluates to the function.
    +        
    +manager.handler2 = 123;
    +manager.handler2;            // Evaluates to null.
    +
    +

    4.3.20. [TreatNullAs]

    +

    If the [TreatNullAs] extended attribute appears on an attribute or operation argument whose type is DOMString, +it indicates that a null value +assigned to the attribute or passed as the operation argument will be +handled differently from its default handling. Instead of being stringified +to “null”, which is the default, +it will be converted to the empty string “”.

    +

    If [TreatNullAs] is specified on +an operation itself, and that operation is on a callback interface, +then it indicates that a user object implementing the interface will have the return +value of the function that implements the operation handled in the same way as for operation arguments +and attributes, as above.

    +

    The [TreatNullAs] +extended attribute must take the identifier EmptyString.

    +

    The [TreatNullAs] extended attribute +must not be specified on an operation argument, +attribute or operation return value whose type is not DOMString.

    +

    Note: This means that even an attribute of type DOMString? must not +use [TreatNullAs], since null is a valid value of that type.

    +

    The [TreatNullAs] extended attribute +also must not be specified on an operation on +a non-callback interface.

    +

    See §4.2.16 DOMString for the specific requirements that the use of +[TreatNullAs] entails.

    +
    + +

    The following IDL fragment defines an interface that has one + attribute with the [TreatNullAs] + extended attribute, and one operation with an argument that has + the extended attribute:

    +
    interface Dog {
    +  attribute DOMString name;
    +  [TreatNullAs=EmptyString] attribute DOMString owner;
    +        
    +  boolean isMemberOfBreed([TreatNullAs=EmptyString] DOMString breedName);
    +};
    +
    +

    An ECMAScript implementation implementing the Dog interface would convert a null value + assigned to the “owner” property or passed as the + argument to the isMemberOfBreed function + to the empty string rather than "null":

    +
    var d = getDog();         // Assume d is a platform object implementing the Dog
    +                          // interface.
    +        
    +d.name = null;            // This assigns the string "null" to the .name
    +                          // property.
    +        
    +d.owner = null;           // This assigns the string "" to the .owner property.
    +        
    +d.isMemberOfBreed(null);  // This passes the string "" to the isMemberOfBreed
    +                          // function.
    +
    +

    4.3.21. [Unforgeable]

    +

    If the [Unforgeable] extended attribute appears on a non-static attribute or non-static operations, it indicates +that the attribute or operation will be reflected as an ECMAScript property in +a way that means its behavior cannot be modified and that performing +a property lookup on the object will always result in the attribute’s +property value being returned. In particular, the property will be +non-configurable and will exist as an own property on the object +itself rather than on its prototype.

    +

    If the [Unforgeable] extended attribute appears on an interface, +it indicates that all of the non-static attributes and non-static operations declared on +that interface and its consequential interfaces will be similarly reflected as own ECMAScript properties on objects +that implement the interface, rather than on the prototype.

    +

    An attribute or operation is said to be unforgeable on a given interface A if any of the following are true:

    + +

    The [Unforgeable] +extended attribute must take no arguments.

    +

    The [Unforgeable] +extended attribute must not appear on +anything other than an attribute, +non-static operation or an interface. If it does +appear on an operation, then +it must appear on all operations with +the same identifier on that interface.

    +

    If an attribute or operation X is unforgeable on an interface A, and A is one of the inherited interfaces of another interface B, then B and all of its consequential interfaces must not have a non-static attribute or regular operation with the same identifier as X.

    +
    +

    For example, the following is disallowed:

    +
    interface A1 {
    +  [Unforgeable] readonly attribute DOMString x;
    +};
    +interface B1 : A1 {
    +  void x();  // Invalid; would be shadowed by A1’s x.
    +};
    +        
    +interface B2 : A1 { };
    +B2 implements Mixin;
    +interface Mixin {
    +  void x();  // Invalid; B2’s copy of x would be shadowed by A1’s x.
    +};
    +        
    +[Unforgeable]
    +interface A2 {
    +  readonly attribute DOMString x;
    +};
    +interface B3 : A2 {
    +  void x();  // Invalid; would be shadowed by A2’s x.
    +};
    +        
    +interface B4 : A2 { };
    +B4 implements Mixin;
    +interface Mixin {
    +  void x();  // Invalid; B4’s copy of x would be shadowed by A2’s x.
    +};
    +        
    +interface A3 { };
    +A3 implements A2;
    +interface B5 : A3 {
    +  void x();  // Invalid; would be shadowed by A3’s mixed-in copy of A2’s x.
    +};
    +
    +
    +

    See §4.6.6 Attributes, §4.6.7 Operations, §4.8 Platform objects implementing interfaces, §4.8.1 Indexed and named properties and §4.8.7 Platform object [[DefineOwnProperty]] method for the specific requirements that the use of +[Unforgeable] entails.

    +
    + +

    The following IDL fragment defines + an interface that has two attributes, + one of which is designated as [Unforgeable]:

    +
    interface System {
    +  [Unforgeable] readonly attribute DOMString username;
    +  readonly attribute long long loginTime;
    +};
    +
    +

    In an ECMAScript implementation of the interface, the username attribute will be exposed as a non-configurable property on the + object itself:

    +
    var system = getSystem();                      // Get an instance of System.
    +        
    +system.hasOwnProperty("username");             // Evaluates to true.
    +system.hasOwnProperty("loginTime");            // Evaluates to false.
    +System.prototype.hasOwnProperty("username");   // Evaluates to false.
    +System.prototype.hasOwnProperty("loginTime");  // Evaluates to true.
    +        
    +try {
    +  // This call would fail, since the property is non-configurable.
    +  Object.defineProperty(system, "username", { value: "administrator" });
    +} catch (e) { }
    +        
    +// This defineProperty call would succeed, because System.prototype.loginTime
    +// is configurable.
    +var forgedLoginTime = 5;
    +Object.defineProperty(System.prototype, "loginTime", { value: forgedLoginTime });
    +        
    +system.loginTime;  // So this now evaluates to forgedLoginTime.
    +
    +

    4.3.22. [Unscopable]

    +

    If the [Unscopable] extended attribute appears on a regular attribute or regular operation, it +indicates that an object that implements an interface with the given +interface member will not include its property name in any object +environment record with it as its base object. The result of this is +that bare identifiers matching the property name will not resolve to +the property in a with statement. This is achieved by +including the property name on the interface prototype object’s @@unscopables property’s value.

    +

    The [Unscopable] +extended attribute must take no arguments.

    +

    The [Unscopable] +extended attribute must not appear on +anything other than a regular attribute or regular operation.

    +

    See §4.6.3 Interface prototype object for the specific requirements that the use of +[Unscopable] entails.

    +
    +

    For example, with the following IDL:

    +
    interface Thing {
    +  void f();
    +  [Unscopable] g();
    +};
    +
    +

    the “f” property an be referenced with a bare identifier + in a with statement but the “g” property cannot:

    +
    var thing = getThing();  // An instance of Thing
    +with (thing) {
    +  f;                     // Evaluates to a Function object.
    +  g;                     // Throws a ReferenceError.
    +}
    +
    +

    4.4. Security

    +

    Certain algorithms in the sections below are defined to perform a security check on a given +object. This check is used to determine whether a given operation invocation or attribute access should be +allowed. The security check takes the following four inputs:

    +
      +
    1. +

      the platform object on +which the operation invocation or attribute access is being done,

      +
    2. +

      the ECMAScript global environment associated with the Function object that implements the +operation or attribute,

      +
    3. +

      the identifier of the operation or attribute, and

      +
    4. +

      the type of the Function object – +“method” (when it corresponds to an IDL operation), or +“getter” or “setter” (when it corresponds to the +getter or setter function of an IDL attribute).

      +
    +

    Note: The expectation is that the HTML specification defines how a +security check is performed, and that it will either throw an +appropriate exception or return normally. [HTML]

    +

    4.5. Overload resolution algorithm

    +

    In order to define how overloaded function invocations are resolved, the overload resolution algorithm is defined. Its input is an effective overload set, S, and a list of ECMAScript values, arg0..n−1. +Its output is a pair consisting of the operation or extended attribute of one of S’s entries +and a list of IDL values or the special value “missing”. The algorithm behaves as follows:

    +
      +
    1. +

      Let maxarg be the length of the longest type list of the entries in S.

      +
    2. +

      Initialize argcount to be min(maxarg, n).

      +
    3. +

      Remove from S all entries whose type list is not of length argcount.

      +
    4. +

      If S is empty, then throw a TypeError.

      +
    5. +

      Initialize d to −1.

      +
    6. +

      Initialize method to undefined.

      +
    7. +

      If there is more than one entry in S, then set d to be the distinguishing argument index for the entries of S.

      +
    8. +

      Initialize values to be an empty list, where each entry will be either an IDL value or the special value “missing”.

      +
    9. +

      Initialize i to 0.

      +
    10. +

      While i < d:

      +
        +
      1. +

        Let V be argi.

        +
      2. +

        Let type be the type at index i in the type list of any entry in S.

        +

        Note: All entries in S at this point have the same type and optionality value at index i.

        +
      3. +

        Let optionality be the value at index i in the list of optionality values of any entry in S.

        +
      4. +

        If optionality is “optional” and V is undefined, then:

        +
          +
        1. +

          If the argument at index i is declared with a default value, +then append to values that default value.

          +
        2. +

          Otherwise, append to values the special value “missing”.

          +
        +
      5. +

        Otherwise, append to values the result of converting V to IDL type type.

        +
      6. +

        Set i to i + 1.

        +
      +
    11. +

      If i = d, then:

      +
        +
      1. +

        Let V be argi.

        +

        Note: This is the argument that will be used to resolve which overload is selected.

        +
      2. +

        If V is undefined, and there is an entry in S whose list of optionality values has “optional” at index i, +then remove from S all other entries.

        +
      3. +

        Otherwise: if V is null or undefined, +and there is an entry in S that has one of the following types at position i of its type list,

        + +

        then remove from S all other entries.

        +
      4. +

        Otherwise: if V is a platform object, and +there is an entry in S that has one of the following types at position i of its type list,

        + +

        then remove from S all other entries.

        +
      5. +

        Otherwise: if V is a RegExp object and +there is an entry in S that has one of the following types at position i of its type list,

        + +

        then remove from S all other entries.

        +
      6. +

        Otherwise: if V is a DOMException platform object and +there is an entry in S that has one of the following types at position i of its type list,

        + +

        then remove from S all other entries.

        +
      7. +

        Otherwise: if V is an Error object (that is, it has an [[ErrorData]] internal slot) and +there is an entry in S that has one of the following types at position i of its type list,

        + +

        then remove from S all other entries.

        +
      8. +

        Otherwise: if V is an object with an [[ArrayBufferData]] internal slot and +there is an entry in S that has one of the following types at position i of its type list,

        + +

        then remove from S all other entries.

        +
      9. +

        Otherwise: if V is an object with a [[DataView]] internal slot and +there is an entry in S that has one of the following types at position i of its type list,

        + +

        then remove from S all other entries.

        +
      10. +

        Otherwise: if V is an object with a [[TypedArrayName]] internal slot and +there is an entry in S that has one of the following types at position i of its type list,

        + +

        then remove from S all other entries.

        +
      11. +

        Otherwise: if IsCallable(V) is true, +and there is an entry in S that has one of the following types at position i of its type list,

        + +

        then remove from S all other entries.

        +
      12. +

        Otherwise: if V is any kind of object except for +a native RegExp object, and +there is an entry in S that has one of the +following types at position i of its type list,

        + +

        and after performing the following steps,

        +
          +
        1. +

          Let method be the result of GetMethod(V, @@iterator).

          +
        2. +

          ReturnIfAbrupt(method).

          +
        +

        method is not undefined, then remove from S all +other entries.

        +
      13. +

        Otherwise: if V is any kind of object except for +a native RegExp object, and +there is an entry in S that has one of the following types at position i of its type list,

        + +

        then remove from S all other entries.

        +
      14. +

        Otherwise: if V is a Boolean value, +and there is an entry in S that has one of the following types at position i of its type list,

        + +

        then remove from S all other entries.

        +
      15. +

        Otherwise: if V is a Number value, +and there is an entry in S that has one of the following types at position i of its type list,

        + +

        then remove from S all other entries.

        +
      16. +

        Otherwise: if there is an entry in S that has one of the following types at position i of its type list,

        + +

        then remove from S all other entries.

        +
      17. +

        Otherwise: if there is an entry in S that has one of the following types at position i of its type list,

        + +

        then remove from S all other entries.

        +
      18. +

        Otherwise: if there is an entry in S that has one of the following types at position i of its type list,

        + +

        then remove from S all other entries.

        +
      19. +

        Otherwise: if there is an entry in S that has any at position i of its type list, +then remove from S all other entries.

        +
      20. +

        Otherwise: throw a TypeError.

        +
      +
    12. +

      Let callable be the operation or extended attribute of the single entry in S.

      +
    13. +

      If i = d and method is not undefined, then

      +
        +
      1. +

        Let V be argi.

        +
      2. +

        Let T be the type at index i in the +type list of the remaining entry in S.

        +
      3. +

        If T is a sequence type, then +append to values the result of +.

        +
      4. +

        Otherwise, T is a frozen array type. +Append to values the result of creating a frozen array of type T from V and method.

        +
      5. +

        Set i to i + 1.

        +
      +
    14. +

      While i < argcount:

      +
        +
      1. +

        Let V be argi.

        +
      2. +

        Let type be the type at index i in the type list of the remaining entry in S.

        +
      3. +

        Let optionality be the value at index i in the list of optionality values of the remaining entry in S.

        +
      4. +

        If optionality is “optional” and V is undefined, then:

        +
          +
        1. +

          If the argument at index i is declared with a default value, +then append to values that default value.

          +
        2. +

          Otherwise, append to values the special value “missing”.

          +
        +
      5. +

        Otherwise, append to values the result of converting V to IDL type type.

        +
      6. +

        Set i to i + 1.

        +
      +
    15. +

      While i is less than the number of arguments callable is declared to take:

      +
        +
      1. +

        If callable’s argument at index i is declared with a default value, +then append to values that default value.

        +
      2. +

        Otherwise, if callable’s argument at index i is not variadic, then append to values the special value “missing”.

        +
      3. +

        Set i to i + 1.

        +
      +
    16. +

      Return the pair <callable, values>.

      +
    +
    +

    The overload resolution algorithm performs both the identification + of which overloaded operation, constructor, etc. is being called, + and the conversion of the ECMAScript argument values to their + corresponding IDL values. Informally, it operates as follows.

    +

    First, the selection of valid overloads is done by considering + the number of ECMAScript arguments that were passed in to the function:

    +
      +
    • +

      If there are more arguments passed in than the longest +overload argument list, then they are ignored.

      +
    • +

      After ignoring these trailing arguments, only overloads +that can take this exact number of arguments are considered. +If there are none, then a TypeError is thrown.

      +
    +

    Once we have a set of possible overloads with the right number + of arguments, the ECMAScript values are converted from left to right. + The nature of the restrictions on overloading means that if we + have multiple possible overloads at this point, then there will + be one position in the argument list that will be used to + distinguish which overload we will finally select; this is + the distinguishing argument index.

    +

    We first convert the arguments to the left of the distinguishing + argument. (There is a requirement that an argument to the left of + the distinguishing argument index has the same type as in the other + overloads, at the same index.) Then we inspect the type of the + ECMAScript value that is passed in at the distinguishing argument + index to determine which IDL type it may correspond to. + This allows us to select the final overload that will + be invoked. If the value passed in is undefined and there is an overload with an optional argument at this position, then + we will choose that overload. If there is no valid overload for the type of + value passed in here, then we throw a TypeError. + The inspection of the value at the distinguishing argument index does not have any side effects; + the only side effects that come from running the overload resolution + algorithm are those that come from converting the ECMAScript values + to IDL values.

    +

    At this point, we have determined which overload to use. We now + convert the remaining arguments, from the distinguishing argument onwards, + again ignoring any additional arguments that were ignored due to being passed + after the last possible argument.

    +

    When converting an optional argument’s ECMAScript value to its equivalent IDL value, undefined will be converted into + the optional argument’s default value, + if it has one, or a special value “missing” otherwise.

    +

    Optional arguments corresponding to a final, variadic argument do not treat undefined as a special “missing” value, however. + The undefined value is converted to the type + of variadic argument as would be done for a non-optional argument.

    +
    +

    4.6. Interfaces

    +

    For every interface that +is exposed in a given +ECMAScript global environment and:

    + +

    a corresponding property must exist on the +ECMAScript environment’s global object. +The name of the property is the identifier of the interface, +and its value is an object called the interface object.

    +

    The property has the attributes { [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true }. +The characteristics of an interface object are described in §4.6.1 Interface object.

    +

    In addition, for every [NamedConstructor] +extended attribute on an exposed interface, a corresponding property must +exist on the ECMAScript global object. The name of the property is the identifier that occurs directly after the +“=”, and its value is an object called a named constructor, which allows +construction of objects that implement the interface. The property has the +attributes { [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true }. +The characteristics of a named constructor are described in §4.6.2 Named constructors.

    +

    4.6.1. Interface object

    +

    The interface object for a given non-callback interface is a function object. +It has properties that correspond to +the constants and static operations defined on that interface, as described in sections §4.6.5 Constants and §4.6.7 Operations.

    +

    The [[Prototype]] internal property of +an interface object for a non-callback interface is determined as +follows:

    +
      +
    1. +

      If the interface inherits from some other interface, the value +of [[Prototype]] is the interface +object for that other interface.

      +
    2. +

      If the interface doesn’t inherit from any other interface, +the value of [[Prototype]] is %FunctionPrototype%.

      +
    +

    An interface object for a non-callback interface must have a property named “prototype” +with attributes { [[Writable]]: false, [[Enumerable]]: false, [[Configurable]]: false } whose value is an object called the interface prototype object. This object has properties +that correspond to the regular attributes and regular operations defined on the interface, +and is described in more detail in §4.6.3 Interface prototype object.

    +

    Note: Since an interface object for a non-callback interface is a function object the typeof operator will return +"function" when applied to +such an interface object.

    +

    The internal [[Prototype]] property +of an interface object for a callback interface must be +the Object.prototype object.

    +

    Note: Remember that interface objects for callback interfaces only exist if they have constants declared on them; +when they do exist, they are not function objects.

    +
    4.6.1.1. Interface object [[Call]] method
    +

    If the interface is declared with a +[Constructor] extended attribute, +then the interface object can be called as a function to create an object that implements that +interface. Interfaces that do not have a constructor will throw +an exception when called as a function.

    +

    The internal [[Call]] method +of the interface object behaves as follows, assuming arg0..n−1 is the list +of argument values passed to the constructor, and I is the interface:

    +
      +
    1. +

      If I was not declared with a [Constructor] extended attribute, then throw a TypeError.

      +
    2. +

      Let id be the identifier of interface I.

      +
    3. +

      Initialize S to the effective overload set for constructors with identifier id on interface I and with argument count n.

      +
    4. +

      Let <constructor, values> be the result of passing S and arg0..n−1 to the overload resolution algorithm.

      +
    5. +

      Let R be the result of performing the actions listed in the description of constructor with values as the argument values.

      +
    6. +

      Return the result of converting R to an ECMAScript interface type value I.

      +
    +

    If the internal [[Call]] method +of the interface object returns normally, then it must +return an object that implements interface I. +This object also must be +associated with the ECMAScript global environment associated +with the interface object.

    +

    Interface objects for non-callback interfaces must have a property named “length” +with attributes { [[Writable]]: false, [[Enumerable]]: false, [[Configurable]]: true } whose value is a Number. +If the [Constructor] extended attribute does not appear on the interface definition, then the value is 0. +Otherwise, the value is determined as follows:

    +
      +
    1. +

      Let id be the identifier of interface I.

      +
    2. +

      Initialize S to the effective overload set for constructors with identifier id on interface I and with argument count 0.

      +
    3. +

      Return the length of the shortest argument list of the entries in S.

      +
    +

    All interface objects must have a +property named “name” with attributes { [[Writable]]: false, [[Enumerable]]: false, [[Configurable]]: true } whose value is the identifier of the corresponding interface.

    +
    4.6.1.2. Interface object [[HasInstance]] method
    +

    The internal [[HasInstance]] method of every interface object A must behave as follows, +assuming V is the object +argument passed to [[HasInstance]]:

    +
      +
    1. +

      If V is not an object, return false.

      +
    2. +

      Let O be the result of calling the [[Get]] method of A with property name “prototype”.

      +
    3. +

      If O is not an object, throw a TypeError exception.

      +
    4. +

      If V is a platform object that implements the +interface for which O is the interface prototype object, +return true.

      +
    5. +

      Repeat:

      +
        +
      1. +

        Set V to the value of the [[Prototype]] internal property of V.

        +
      2. +

        If V is null, return false.

        +
      3. +

        If O and V refer to the same object, +return true.

        +
      +
    +

    4.6.2. Named constructors

    +

    A named constructor that exists due to one or more +[NamedConstructor] extended attributes with a given identifier is a function object. +It must have a [[Call]] +internal property, which allows construction of objects that +implement the interface on which the +[NamedConstructor] +extended attributes appear. It behaves as follows, assuming arg0..n−1 is the list +of argument values passed to the constructor, id is the identifier of the constructor specified in the +extended attribute named argument list, +and I is the interface on which the [NamedConstructor] +extended attribute appears:

    +
      +
    1. +

      Initialize S to the effective overload set for constructors with identifier id on interface I and with argument count n.

      +
    2. +

      Let <constructor, values> be the result of passing S and arg0..n−1 to the overload resolution algorithm.

      +
    3. +

      Let R be the result of performing the actions listed in the description of constructor with values as the argument values.

      +
    4. +

      Return the result of converting R to an ECMAScript interface type value I.

      +
    +

    If the internal [[Call]] method +of the named constructor returns normally, then it must +return an object that implements interface I. +This object also must be +associated with the ECMAScript global environment associated +with the named constructor.

    +

    A named constructor must have a property named “length” +with attributes { [[Writable]]: false, [[Enumerable]]: false, [[Configurable]]: true } whose value is a Number determined as follows:

    +
      +
    1. +

      Initialize S to the effective overload set for constructors with identifier id on interface I and with argument count 0.

      +
    2. +

      Return the length of the shortest argument list of the entries in S.

      +
    +

    A named constructor must have a property named “name” +with attributes { [[Writable]]: false, [[Enumerable]]: false, [[Configurable]]: true } whose value is the identifier used for the named constructor.

    +

    A named constructor must also have a property named +“prototype” with attributes { [[Writable]]: false, [[Enumerable]]: false, [[Configurable]]: false } whose value is the interface prototype object for the interface on which the +[NamedConstructor] extended attribute appears.

    +

    4.6.3. Interface prototype object

    +

    There must exist an interface prototype object for every non-callback interface defined, regardless of whether the interface was declared with the +[NoInterfaceObject] extended attribute. +The interface prototype object for a particular interface has +properties that correspond to the regular attributes and regular operations defined on that interface. These properties are described in more detail in +sections §4.6.6 Attributes and §4.6.7 Operations.

    +

    As with the interface object, +the interface prototype object also has properties that correspond to the constants defined on that +interface, described in §4.6.7 Operations.

    +

    If the [NoInterfaceObject] +extended attribute was not specified on the interface, then +the interface prototype object must +also have a property named “constructor” with attributes { [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true } whose value +is a reference to the interface object for the interface.

    +

    The interface prototype object for a given interface A must have an internal +[[Prototype]] property whose value is returned from +the following steps:

    +
      +
    1. +

      If A is declared with the [Global] +or [PrimaryGlobal] extended attribute, and A supports named properties, then +return the named properties object for A, as defined in §4.6.4 Named properties object.

      +
    2. +

      Otherwise, if A is declared to inherit from another +interface, then return the interface prototype object for the inherited interface.

      +
    3. +

      Otherwise, if A is declared with the [LegacyArrayClass] +extended attribute, then return %ArrayPrototype%.

      +
    4. +

      Otherwise, return %ObjectPrototype%.

      +
    +
    +

    The interface prototype object of an interface that is defined with + the [NoInterfaceObject] extended attribute will be accessible if the interface is used as a non-supplemental interface. + For example, with the following IDL:

    +
    [NoInterfaceObject]
    +interface Foo {
    +};
    +        
    +partial interface Window {
    +  attribute Foo foo;
    +};
    +
    +

    it is not possible to access the interface prototype object through + the interface object (since it does not exist as window.Foo). However, an instance + of Foo can expose the interface prototype + object by gettings its internal [[Prototype]] + property value – Object.getPrototypeOf(window.foo) in + this example.

    +

    If the interface is used solely as a supplemental interface, + then there will be no way to access its interface prototype object, since no + object will have the interface prototype object as its internal + [[Prototype]] property value. In such cases, + it is an acceptable optimization for this object not to exist.

    +
    +

    If the interface or any of its consequential interfaces has any interface member declared with +the [Unscopable] extended attribute, +then there must be a property on the +interface prototype object whose name is the @@unscopables symbol +and whose value is an object created as follows:

    +
      +
    1. +

      Let object be a new object created as if by the expression ({}).

      +
    2. +

      For each of the aforementioned interface members declared with the [Unscopable] extended attribute, +call CreateDataProperty(object, +the identifier of the +interface member, true).

      +
    3. +

      Return object.

      +
    +

    If the interface is declared with the [Global] or +[PrimaryGlobal] extended attribute, or the interface is in the set +of inherited interfaces for any +other interface that is declared with one of these attributes, then the interface prototype object must be an immutable prototype exotic object.

    +

    The class string of an interface prototype object is the concatenation of the interface’s identifier and the string +“Prototype”.

    +

    4.6.4. Named properties object

    +

    For every interface declared with the +[Global] or +[PrimaryGlobal] extended attribute that supports named properties, +there must exist an object known as the named properties object for that +interface.

    +

    The named properties object for a given interface A must have an internal +[[Prototype]] property whose value is returned from +the following steps:

    +
      +
    1. +

      If A is declared to inherit from another interface, then return the interface prototype object for the inherited interface.

      +
    2. +

      Otherwise, if A is declared with the [LegacyArrayClass] +extended attribute, then return %ArrayPrototype%.

      +
    3. +

      Otherwise, return %ObjectPrototype%.

      +
    +

    The class string of a named properties object is the concatenation of the interface’s identifier and the string +“Properties”.

    +
    4.6.4.1. Named properties object [[GetOwnProperty]] method
    +

    When the [[GetOwnProperty]] internal method of a named properties object O is called with property key P, the following steps are +taken:

    +
      +
    1. +

      Let A be the interface for the named properties object O.

      +
    2. +

      Let object be the sole object from O’s ECMAScript global environment that implements A.

      +

      Note: For example, if the interface is the Window interface, +then the sole object will be this global environment’s window object.

      +
    3. +

      If the result of running the named property visibility algorithm with +property name P and object object is true, then:

      +
        +
      1. +

        Let operation be the operation used to declare the named property getter.

        +
      2. +

        Let value be an uninitialized variable.

        +
      3. +

        If operation was defined without an identifier, then +set value to the result of performing the steps listed in the interface description to determine the value of a named property with P as the name.

        +
      4. +

        Otherwise, operation was defined with an identifier. Set value to the result +of performing the steps listed in the description of operation with P as the only argument value.

        +
      5. +

        Let desc be a newly created Property Descriptor with no fields.

        +
      6. +

        Set desc.[[Value]] to the result of converting value to an ECMAScript value.

        +
      7. +

        If A implements an interface with the +[LegacyUnenumerableNamedProperties] extended attribute, +then set desc.[[Enumerable]] to false, +otherwise set it to true.

        +
      8. +

        Set desc.[[Writable]] to true and desc.[[Configurable]] to true.

        +
      9. +

        Return desc.

        +
      +
    4. +

      Return OrdinaryGetOwnProperty(O, P).

      +
    +
    4.6.4.2. Named properties object [[DefineOwnProperty]] method
    +

    When the [[DefineOwnProperty]] internal method of a named properties object is +called, the following steps are taken:

    +
      +
    1. +

      Return false.

      +
    +
    4.6.4.3. Named properties object [[Delete]] method
    +

    When the [[Delete]] internal method of a named properties object is called, the +following steps are taken:

    +
      +
    1. +

      Return false.

      +
    +
    4.6.4.4. Named properties object [[SetPrototypeOf]] method
    +

    When the [[SetPrototypeOf]] internal method of a named properties object is +called, the same algorithm must be executed as is defined for the [[SetPrototypeOf]] internal method of an immutable prototype exotic object.

    +

    4.6.5. Constants

    +

    For each exposed constant defined on +an interface A, there +must be a corresponding property. +The property has the following characteristics:

    +
      +
    • +

      The name of the property is the identifier of the constant.

      +
    • +

      The location of the property is determined as follows:

      + +
    • +

      The value of the property is that which is obtained by converting the constant’s IDL value to an ECMAScript value.

      +
    • +

      The property has attributes { [[Writable]]: false, [[Enumerable]]: true, [[Configurable]]: false }.

      +
    +

    In addition, a property with the same characteristics must +exist on the interface object, if +that object exists.

    +

    4.6.6. Attributes

    +

    For each exposed attribute of the interface, whether it +was declared on the interface itself or one of its consequential interfaces, +there must exist a corresponding property. +The characteristics of this property are as follows:

    +
      +
    • +

      The name of the property is the identifier of the attribute.

      +
    • +

      The location of the property is determined as follows:

      + +
    • +

      The property has attributes { [[Get]]: G, [[Set]]: S, [[Enumerable]]: true, [[Configurable]]: configurable }, +where:

      +
        +
      • +

        configurable is false if the attribute was +declared with the [Unforgeable] extended attribute and true otherwise;

        +
      • +

        G is the attribute getter, defined below; and

        +
      • +

        S is the attribute setter, also defined below.

        +
      +
    • +

      The attribute getter is a Function object whose behavior when invoked is as follows:

      +
        +
      1. +

        Let idlValue be an IDL value determined as follows.

        +
      2. +

        If the attribute is a regular attribute, then:

        +
          +
        1. +

          Let I be the interface whose interface prototype object this property corresponding to the attribute appears on.

          +

          Note: This means that even if an implements statement was used to make +an attribute available on the interface, I is the interface +on the left hand side of the implements statement, and not the one +that the attribute was originally declared on.

          +
        2. +

          Let O be the this value.

          +
        3. +

          If O is a platform object, +then perform a security check, passing:

          +
            +
          • +

            the platform object O,

            +
          • +

            the ECMAScript global environment associated with this Function that +implements the attribute getter,

            +
          • +

            the identifier of the attribute, and

            +
          • +

            the type “getter”.

            +
          +
        4. +

          If O is not a platform object that implements I, then:

          +
            +
          1. +

            If the attribute was specified with the +[LenientThis] extended attribute, +then return undefined.

            +
          2. +

            Otherwise, throw a TypeError.

            +
          +
        5. +

          Set idlValue to be the result of performing the actions listed in the description of the attribute that occur when getting +(or those listed in the description of the inherited attribute, if this attribute is declared to inherit its getter), +with O as the object.

          +
        +
      3. +

        Otherwise, the attribute is a static attribute. +Set idlValue to be the result of performing the actions listed in the description of the attribute that occur when getting.

        +
      4. +

        Let V be the result of converting idlValue to an ECMAScript value.

        +
      5. +

        Return V.

        +
      +

      The value of the Function object’s “length” +property is the Number value 0.

      +

      The value of the Function object’s “name” +property is a String whose value is the +concatenation of “get ” and the identifier of the attribute.

      +
    • +

      The attribute setter is undefined if the attribute is declared readonly and does not have a +[LenientThis], [PutForwards] or +[Replaceable] extended attribute declared on it. +Otherwise, it is a Function object whose behavior when invoked is as follows:

      +
        +
      1. +

        If no arguments were passed to the Function, then throw a TypeError.

        +
      2. +

        Let V be the value of the first argument passed to the Function.

        +
      3. +

        If the attribute is a regular attribute, then:

        +
          +
        1. +

          Let I be the interface whose interface prototype object this property corresponding to the attribute appears on.

          +
        2. +

          Let O be the this value.

          +
        3. +

          If O is a platform object, +then perform a security check, passing:

          +
            +
          • +

            the platform object O,

            +
          • +

            the ECMAScript global environment associated with this Function that +implements the attribute setter,

            +
          • +

            the identifier of the attribute, and

            +
          • +

            the type “setter”.

            +
          +
        4. +

          Let validThis be true if O is a platform object that implements I, or false otherwise.

          +
        5. +

          If validThis is false and the attribute was not specified with the +[LenientThis] extended attribute, +then throw a TypeError.

          +
        6. +

          If the attribute is declared with a [Replaceable] +extended attribute, then:

          +
            +
          1. +

            Let P be the identifier of the attribute.

            +
          2. +

            Call CreateDataProperty(O, P, V).

            +
          3. +

            Return undefined.

            +
          +
        7. +

          If validThis is false, then return undefined.

          +
        8. +

          If the attribute is declared with a [LenientSetter] +extended attribute, then return undefined.

          +
        9. +

          If the attribute is declared with a [PutForwards] +extended attribute, then:

          +
            +
          1. +

            Let Q be the result of calling the [[Get]] method +on O using the identifier of the attribute as the property name.

            +
          2. +

            If Q is not an object, then throw a TypeError.

            +
          3. +

            Let A be the attribute identified by the [PutForwards] extended attribute.

            +
          4. +

            Call the [[Put]] method on Q using the identifier of A as the property name and V as the value.

            +
          5. +

            Return undefined.

            +
          +
        +
      4. +

        Let idlValue be an IDL value determined as follows:

        +
          +
        • +

          If the type of the attribute is an enumeration, then:

          +
            +
          1. +

            Let S be the result of calling ToString(V).

            +
          2. +

            If S is not one of the enumeration’s values, then return undefined.

            +
          3. +

            The value of idlValue is the enumeration value equal to S.

            +
          +
        • +

          Otherwise, the type of the attribute is not an enumeration. +The value of idlValue is the result of converting V to an IDL value.

          +
        +
      5. +

        If the attribute is a regular attribute, then perform the actions listed in the description of the attribute that occur when setting, +with O as the object and idlValue as the value.

        +
      6. +

        Otherwise, the attribute is a static attribute. +Perform the actions listed in the description of the attribute that occur when setting with idlValue as the value.

        +
      7. +

        Return undefined.

        +
      +

      The value of the Function object’s “length” +property is the Number value 1.

      +

      The value of the Function object’s “name” +property is a String whose value is the +concatenation of “set ” and the identifier of the attribute.

      +
    +

    Note: Although there is only a single property for an IDL attribute, since +accessor property getters and setters are passed a this value for the object on which property corresponding to the IDL attribute is +accessed, they are able to expose instance-specific data.

    +

    Note: Note that attempting to assign to a property corresponding to a read only attribute results in different behavior depending on whether the script doing so is in strict mode. +When in strict mode, such an assignment will result in a TypeError being thrown. When not in strict mode, the assignment attempt will be ignored.

    +

    4.6.7. Operations

    +

    For each unique identifier of an exposed operation defined on the interface, there +must exist a corresponding property, +unless the effective overload set for that identifier and operation and with an argument count of 0 has no entries.

    +

    The characteristics of this property are as follows:

    +
      +
    • +

      The name of the property is the identifier.

      +
    • +

      The location of the property is determined as follows:

      + +
    • +

      The property has attributes { [[Writable]]: B, [[Enumerable]]: true, [[Configurable]]: B }, +where B is false if the operation is unforgeable on the interface, +and true otherwise.

      +
    • +

      The value of the property is a Function object whose +behavior is as follows, +assuming id is the identifier, arg0..n−1 is the list +of argument values passed to the function:

      +
        +
      1. +

        Try running the following steps:

        +
          +
        1. +

          Let I be the interface whose interface prototype object (or interface object, for a static +operation) this property corresponding to the operation appears on.

          +

          Note: This means that even if an implements statement was used to make +an operation available on the interface, I is the interface +on the left hand side of the implements statement, and not the one +that the operation was originally declared on.

          +
        2. +

          Let O be a value determined as follows:

          +
            +
          • +

            If the operation is a static operation, then O is null.

            +
          • +

            Otherwise, if the interface on which the operation appears has an +[ImplicitThis] extended attribute, +and the this value is null or undefined, then O is +the ECMAScript global object associated with the Function object.

            +
          • +

            Otherwise, if the this value is not null, +then O is the this value.

            +
          • +

            Otherwise, throw a TypeError.

            +
          +
        3. +

          If O is a platform object, +then perform a security check, passing:

          +
            +
          • +

            the platform object O,

            +
          • +

            the ECMAScript global environment associated with this Function that +implements the operation,

            +
          • +

            the identifier of the operation, and

            +
          • +

            the type “method”.

            +
          +
        4. +

          If O is not null and is also not a platform object that implements interface I, throw a TypeError.

          +
        5. +

          Initialize S to the effective overload set for regular operations (if the operation is a regular operation) or for static operations (if the operation is a static operation) with identifier id on interface I and with argument count n.

          +
        6. +

          Let <operation, values> be the result of passing S and arg0..n−1 to the overload resolution algorithm.

          +
        7. +

          Let R be the result of performing (on O, if the operation +is not a static operation) the actions listed in the description of operation with values as the argument values.

          +
        8. +

          Return the result of converting R to an ECMAScript value of +the type op is declared to return.

          +
        +

        And then, if an exception was thrown:

        +
          +
        1. +

          If the operation has a return type that is a promise type, then:

          +
            +
          1. +

            Let reject be the initial value of %Promise%.reject.

            +
          2. +

            Return the result of calling reject with %Promise% as the this object and the exception as the single +argument value.

            +
          +
        2. +

          Otherwise, end these steps and allow the exception to propagate.

          +
        +
      +
    • +

      The value of the Function object’s “length” +property is a Number determined as follows:

      +
        +
      1. +

        Let S be the effective overload set for regular operations (if the operation is a regular operation) or for static operations (if the operation is a static operation) with identifier id on interface I and with argument count 0.

        +
      2. +

        Return the length of the shortest argument list of the entries in S.

        +
      +
    • +

      The value of the Function object’s “name” +property is a String whose value is the +identifier of the operation.

      +
    +

    We also define creating an operation function, given an operation op, a namespace namespace, and a Realm realm:

    +

    Note: The astute reader may notice that what follows is very similar to the +above algorithm for operations on interfaces. It is currently only used for namespaces, +but we have near-future plans to generalize it slightly and then replace the above +definition so that this algorithm is useful both for interfaces and namespaces.

    +
      +
    1. +

      Let id be op’s identifier.

      +
    2. +

      Let steps be the following series of steps, given function argument +values arg0..n−1:

      +
        +
      1. +

        Try running the following steps:

        +
          +
        1. +

          Let S be the effective overload set for regular operations with identifier id on namespace namespace and with argument count n.

          +
        2. +

          Let <operation, values> be the result of passing S and arg0..n−1 to the overload resolution algorithm.

          +
        3. +

          Let R be the result of performing the actions listed in the +description of operation with values as the argument +values.

          +
        4. +

          Return the result of converting R to +an ECMAScript value of the type op is declared to return.

          +
        +
      +

      And then, if an exception was thrown:

      +
        +
      1. +

        If the operation has a return type that is a promise type, then:

        +
          +
        1. +

          Let reject be the initial value of %Promise%.reject.

          +
        2. +

          Return the result of calling reject with %Promise% as the this object +and the exception as the single argument value.

          +
        +
      2. +

        Otherwise, end these steps and allow the exception to propagate.

        +
      +
    3. +

      Let F be ! CreateBuiltinFunction(realm, steps, the %FunctionPrototype% of realm).

      +
    4. +

      Perform ! SetFunctionName(F, id).

      +
    5. +

      Let S be the effective overload set for regular operations with identifier id on namespace namespace and with argument count 0.

      +
    6. +

      Let length be the length of the shortest argument list in the entries in S.

      +
    7. +

      Perform ! DefinePropertyOrThrow(F, "length", +PropertyDescriptor{[[Value]]: length, +[[Writable]]: false, [[Enumerable]]: false, [[Configurable]]: true}).

      +
    +
    4.6.7.1. Stringifiers
    +

    If the interface has an exposed stringifier, then +there must exist a property with +the following characteristics:

    +
      +
    • +

      The name of the property is “toString”.

      +
    • +

      If the stringifier is unforgeable on the interface +or if the interface was declared with the [Global] or [PrimaryGlobal] extended attribute, +then the property exists on every object that implements the interface. +Otherwise, the property exists on the interface prototype object.

      +
    • +

      The property has attributes { [[Writable]]: B, [[Enumerable]]: true, [[Configurable]]: B }, +where B is false if the stringifier is unforgeable on the interface, +and true otherwise.

      +
    • +

      The value of the property is a Function object, which behaves as follows:

      +
        +
      1. +

        Let O be the result of calling ToObject on the this value.

        +
      2. +

        If O is a platform object, +then perform a security check, passing:

        +
          +
        • +

          the platform object O,

          +
        • +

          the ECMAScript global environment associated with this Function that +implements the stringifier,

          +
        • +

          the identifier of the stringifier, and

          +
        • +

          the type “method”.

          +
        +
      3. +

        If O is not an object that implements the interface on which the stringifier was declared, then throw a TypeError.

        +
      4. +

        Let V be an uninitialized variable.

        +
      5. +

        Depending on where stringifier was specified:

        +
        +
        +

        on an attribute

        +
        +

        Set V to the result of performing the actions listed in the description of the attribute that occur when getting +(or those listed in the description of the inherited attribute, if this attribute is declared to inherit its getter), +with O as the object.

        +
        +

        on an operation with an identifier

        +
        +

        Set V to the result of performing the actions listed in the description +of the operation, using O as the this value +and passing no arguments.

        +
        +

        on an operation with no identifier

        +
        +

        Set V to the result of performing the stringification behavior of the interface.

        +
        +
      6. +

        Return the result of converting V to a String value.

        +
      +
    • +

      The value of the Function object’s “length” +property is the Number value 0.

      +
    • +

      The value of the Function object’s “name” +property is the String value “toString”.

      +
    +
    4.6.7.2. Serializers
    +

    If the interface has an exposed serializer, then +a property must exist +whose name is “toJSON”, +with attributes { [[Writable]]: true, [[Enumerable]]: true, [[Configurable]]: true } and whose value is a Function object.

    +

    The location of the property is determined as follows:

    + +

    The property’s Function object, when invoked, +must behave as follows:

    +
      +
    1. +

      Let O be the result of calling ToObject on the this value.

      +
    2. +

      If O is a platform object, +then perform a security check, passing:

      +
        +
      • +

        the platform object O,

        +
      • +

        the ECMAScript global environment associated with this Function that +implements the serializer,

        +
      • +

        the identifier of the serializer, and

        +
      • +

        the type “method”.

        +
      +
    3. +

      If O is not an object that implements the interface on which the serializer was declared, then throw a TypeError.

      +
    4. +

      Depending on how serializer was specified:

      +
      +
      +

      on an operation with an identifier

      +
      +
        +
      1. +

        Return the result of performing the actions listed in the description of the +operation, using O as the this value +and passing no arguments.

        +
      +
      +

      as a keyword, either with or without a serialization pattern

      +
      +
        +
      1. +

        Let S be the serialized value that is the result of invoking the serialization behavior of the interface for object O.

        +
      2. +

        Return the result of converting S to an ECMAScript value.

        +
      +
      +
    +

    The value of the Function object’s “length” +property is the Number value 0.

    +

    The value of the Function object’s “name” +property is the String value “toJSON”.

    +

    The following steps define how to convert a serialized value to an ECMAScript value:

    +
      +
    1. +

      Let S be the serialized value.

      +
    2. +

      Depending on the type of S:

      +
      +
      +

      a map

      +
      +
        +
      1. +

        Let O be a new object created as if by the expression ({}).

        +
      2. +

        For each entry in S, in the order they were added to the map:

        +
          +
        1. +

          Let V be the result of converting the value of the entry to an ECMAScript value.

          +
        2. +

          Let P be the entry’s key.

          +
        3. +

          Call CreateDataProperty(O, P, V).

          +
        +
      3. +

        Return O.

        +
      +
      +

      a list

      +
      +
        +
      1. +

        Let A be a new Array object created as if by the expression [].

        +
      2. +

        Let index be 0.

        +
      3. +

        While index is less than the number of elements in S:

        +
          +
        1. +

          Let V be the result of converting the value of the element in S at index index to an ECMAScript value.

          +
        2. +

          Let P be ToString(index).

          +
        3. +

          Call CreateDataProperty(O, P, V).

          +
        +
      4. +

        Return A.

        +
      +
      +

      any other serialized value

      +
      +
        +
      1. +

        Let V be the result of converting S to an ECMAScript value.

        +
      2. +

        Return V.

        +
      +
      +
    +

    4.6.8. Common iterator behavior

    +
    4.6.8.1. @@iterator
    +

    If the interface has any of the following:

    + +

    then a property must exist +whose name is the @@iterator symbol, +with attributes { [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true } and whose value is a function object.

    +

    The location of the property is determined as follows:

    + +

    If the interface defines an indexed property getter, +then the Function object is %ArrayProto_values%.

    +

    If the interface has a pair iterator, +then the Function, when invoked, +must behave as follows:

    +
      +
    1. +

      Let object be the result of calling ToObject on the this value.

      +
    2. +

      If object is a platform object, +then perform a security check, passing:

      +
        +
      • +

        the platform object object,

        +
      • +

        the ECMAScript global environment associated with this Function,

        +
      • +

        the identifier “@@iterator”, and

        +
      • +

        the type “method”.

        +
      +
    3. +

      Let interface be the interface the iterable declaration is on.

      +
    4. +

      If object is not a platform object that implements interface, +then throw a TypeError.

      +
    5. +

      Let iterator be a newly created default iterator object for interface with object as its target and iterator kind “key+value”.

      +
    6. +

      Return iterator.

      +
    +

    If the interface has a maplike declaration or setlike declaration, +then the Function object that is the value of the @@iterator property, +when invoked, must behave as follows:

    +
      +
    1. +

      Let object be the result of calling ToObject on the this value.

      +
    2. +

      If object is a platform object, +then perform a security check, passing:

      +
        +
      • +

        the platform object object,

        +
      • +

        the ECMAScript global environment associated with this Function,

        +
      • +

        the identifier “@@iterator”, and

        +
      • +

        the type “method”.

        +
      +
    3. +

      If object is not a platform object that implements the interface on which the maplike declaration or setlike declaration is defined, +then throw a TypeError.

      +
    4. +

      If the interface has a maplike declaration, then:

      +
        +
      1. +

        Let backing be the value of the [[BackingMap]] internal slot of object.

        +
      2. +

        Return CreateMapIterator(backing, "key+value").

        +
      +
    5. +

      Otherwise:

      +
        +
      1. +

        Let backing be the value of the [[BackingSet]] internal slot of object.

        +
      2. +

        Return CreateSetIterator(backing, "value").

        +
      +
    +

    The value of the @@iterator Function object’s “length” +property is the Number value 0.

    +

    The value of the @@iterator Function object’s “name” +property is the String value “entries” if the interface has a pair iterator or a maplike declaration and the String “values” +if the interface has a setlike declaration.

    +
    4.6.8.2. forEach
    +

    If the interface has any of the following:

    + +

    then a property named “forEach” must exist +with attributes { [[Writable]]: true, [[Enumerable]]: true, [[Configurable]]: true } and whose value is a function object.

    +

    The location of the property is determined as follows:

    + +

    If the interface defines an indexed property getter, +then the Function object is +the initial value of the “forEach” data property of %ArrayPrototype%.

    +

    If the interface has a pair iterator, +then the Function must +have the same behavior as one that would exist assuming the interface had +this operation instead of the iterable declaration:

    +
    interface Iterable {
    +  void forEach(Function callback, optional any thisArg);
    +};
    +
    +

    with the following prose definition:

    +
      +
    1. +

      Let O be the this value.

      +
    2. +

      Let pairs be the list of value pairs to iterate over.

      +
    3. +

      Let i be 0.

      +
    4. +

      While i is less than the length of pairs:

      +
        +
      1. +

        Let pair be the entry in pairs at index i.

        +
      2. +

        Let key be pair’s key.

        +
      3. +

        Let value be pair’s value.

        +
      4. +

        Invoke callback with thisArg (or undefined, if the argument was not supplied) +as the callback this value and value, key and O as its arguments.

        +
      5. +

        Update pairs to the current list of value pairs to iterate over.

        +
      6. +

        Set i to i + 1.

        +
      +
    +

    If the interface has a maplike declaration or setlike declaration then the Function, when invoked, +must behave as follows:

    +
      +
    1. +

      Let object be the result of calling ToObject on the this value.

      +
    2. +

      If object is a platform object, +then perform a security check, passing:

      +
        +
      • +

        the platform object object,

        +
      • +

        the ECMAScript global environment associated with this Function,

        +
      • +

        the identifier “forEach”, and

        +
      • +

        the type “method”.

        +
      +
    3. +

      Let interface be the interface on which the maplike declaration or setlike declaration is declared.

      +
    4. +

      If object is not a platform object that implements interface, +then throw a TypeError.

      +
    5. +

      Let callbackFn be the value of the first argument passed to the function, or undefined if the argument was not supplied.

      +
    6. +

      If IsCallable(callbackFn) is false, throw a TypeError.

      +
    7. +

      Let thisArg be the value of the second argument passed to the function, or undefined if the argument was not supplied.

      +
    8. +

      Let backing be the value of the [[BackingMap]] internal slot of object, +if the interface has a maplike declaration, +or the [[BackingSet]] internal slot of object otherwise.

      +
    9. +

      Let callbackWrapper be a Function that, when invoked, behaves as follows:

      +
        +
      1. +

        Let v and k be the first two arguments passed to the function.

        +
      2. +

        Let thisArg be the this value.

        +
      3. +

        Call the [[Call]] internal method of callbackFn with thisArg as thisArgument and v, k and object as argumentsList.

        +
      +

      Note: The callbackWrapper function simply calls the incoming callbackFn with object as the third argument rather than its internal [[BackingMap]] or [[BackingSet]] object.

      +

      Can the script author observe that callbackWrapper might be a new function + every time forEach is called? What’s the best way of specifying that there’s only + one function that has captured an environment?

      +
    10. +

      Let forEach be the result of calling the [[Get]] internal method of backing with “forEach” and backing as arguments.

      +
    11. +

      If IsCallable(forEach) is false, throw a TypeError.

      +
    12. +

      Call the [[Call]] internal method of forEach with backing as thisArgument and callbackWrapper and thisArg as argumentsList.

      +
    13. +

      Return undefined.

      +
    +

    The value of the Function object’s “length” +property is the Number value 1.

    +

    The value of the Function object’s “name” +property is the String value “forEach”.

    +

    4.6.9. Iterable declarations

    +
    4.6.9.1. entries
    +

    If the interface has an iterable declaration, +then a property named “entries” must exist +with attributes { [[Writable]]: true, [[Enumerable]]: true, [[Configurable]]: true } and whose value is a function object.

    +

    The location of the property is determined as follows:

    + +

    If the interface has a value iterator, +then the Function object is +the initial value of the “entries” data property of %ArrayPrototype%.

    +

    If the interface has a pair iterator, +then the Function object is +the value of the @@iterator property.

    +
    4.6.9.2. keys
    +

    If the interface has an iterable declaration, +then a property named “keys” must exist +with attributes { [[Writable]]: true, [[Enumerable]]: true, [[Configurable]]: true } and whose value is a function object.

    +

    The location of the property is determined as follows:

    + +

    If the interface has a value iterator, +then the Function object is +the initial value of the “keys” data property of %ArrayPrototype%.

    +

    If the interface has a pair iterator, +then the Function, when invoked, must behave as follows:

    +
      +
    1. +

      Let object be the result of calling ToObject on the this value.

      +
    2. +

      If object is a platform object, +then perform a security check, passing:

      +
        +
      • +

        the platform object object,

        +
      • +

        the ECMAScript global environment associated with this Function,

        +
      • +

        the identifier “keys”, and

        +
      • +

        the type “method”.

        +
      +
    3. +

      Let interface be the interface on which the iterable declaration is declared on.

      +
    4. +

      If object is not a platform object that implements interface, +then throw a TypeError.

      +
    5. +

      Let iterator be a newly created default iterator object for interface with object as its target and iterator kind “key”.

      +
    6. +

      Return iterator.

      +
    +

    The value of the Function object’s “length” property is the Number value 0.

    +

    The value of the Function object’s “name” property is the String value “keys”.

    +
    4.6.9.3. values
    +

    If the interface has an iterable declaration, +then a property named “values” must exist +with attributes { [[Writable]]: true, [[Enumerable]]: true, [[Configurable]]: true } and whose value is a function object.

    +

    The location of the property is determined as follows:

    + +

    If the interface has a value iterator, +then the Function object is +the value of the @@iterator property.

    +

    If the interface has a pair iterator, +then the Function, when invoked, must behave as follows:

    +
      +
    1. +

      Let object be the result of calling ToObject on the this value.

      +
    2. +

      If object is a platform object, +then perform a security check, passing:

      +
        +
      • +

        the platform object object,

        +
      • +

        the ECMAScript global environment associated with this Function,

        +
      • +

        the identifier “entries”, and

        +
      • +

        the type “method”.

        +
      +
    3. +

      Let interface be the interface on which the iterable declaration is declared on.

      +
    4. +

      If object is not a platform object that implements interface, +then throw a TypeError.

      +
    5. +

      Let iterator be a newly created default iterator object for interface with object as its target and iterator kind “value”.

      +
    6. +

      Return iterator.

      +
    +

    The value of the Function object’s “length” property is the Number value 0.

    +

    The value of the Function object’s “name” property is the String value “values”.

    +
    4.6.9.4. Default iterator objects
    +

    A default iterator object for a given interface, target and iteration kind +is an object whose internal [[Prototype]] property is the iterator prototype object for the interface.

    +

    A default iterator object has three internal values:

    +
      +
    1. +

      its target, which is an object whose values are to be iterated,

      +
    2. +

      its kind, which is the iteration kind,

      +
    3. +

      its index, which is the current index into the values value to be iterated.

      +
    +

    Note: Default iterator objects are only used for pair iterators; value iterators, as they are currently +restricted to iterating over an object’s supported indexed properties, +use standard ECMAScript Array iterator objects.

    +

    When a default iterator object is first created, +its index is set to 0.

    +

    The class string of a default iterator object for a given interface is the result of concatenting the identifier of the interface and +the string “ Iterator”.

    +
    4.6.9.5. Iterator prototype object
    +

    The iterator prototype object for a given interface is an object that exists for every interface that has a pair iterator. It serves as the +prototype for default iterator objects for the interface.

    +

    The internal [[Prototype]] property of an iterator prototype object must be %IteratorPrototype%.

    +

    An iterator prototype object must have a property named “next” with +attributes { [[Writable]]: true, [[Enumerable]]: true, [[Configurable]]: true } and whose value is a function object that behaves as follows:

    +
      +
    1. +

      Let interface be the interface for which the iterator prototype object exists.

      +
    2. +

      Let object be the result of calling ToObject on the this value.

      +
    3. +

      If object is a platform object, +then perform a security check, passing:

      +
        +
      • +

        the platform object object,

        +
      • +

        the ECMAScript global environment associated with this Function,

        +
      • +

        the identifier “next”, and

        +
      • +

        the type “method”.

        +
      +
    4. +

      If object is not a default iterator object for interface, +then throw a TypeError.

      +
    5. +

      Let target be object’s target.

      +
    6. +

      Let index be object’s index.

      +
    7. +

      Let kind be object’s kind.

      +
    8. +

      Let values be the list of value pairs to iterate over.

      +
    9. +

      Let len be the length of values.

      +
    10. +

      If object’s index is greater than or equal to len, then +return CreateIterResultObject(undefined, true).

      +
    11. +

      Let pair be the entry in values at index index.

      +
    12. +

      Let result be a value determined by the value of kind:

      +
      +
      +

      key

      +
      +
        +
      1. +

        Let idlKey be pair’s key.

        +
      2. +

        Let key be the result of converting idlKey to an ECMAScript value.

        +
      3. +

        result is key.

        +
      +
      +

      value

      +
      +
        +
      1. +

        Let idlValue be pair’s value.

        +
      2. +

        Let value be the result of converting idlValue to an ECMAScript value.

        +
      3. +

        result is value.

        +
      +
      +

      key+value

      +
      +
        +
      1. +

        Let idlKey be pair’s key.

        +
      2. +

        Let idlValue be pair’s value.

        +
      3. +

        Let key be the result of converting idlKey to an ECMAScript value.

        +
      4. +

        Let value be the result of converting idlValue to an ECMAScript value.

        +
      5. +

        Let array be the result of performing ArrayCreate(2).

        +
      6. +

        Call CreateDataProperty(array, "0", key).

        +
      7. +

        Call CreateDataProperty(array, "1", value).

        +
      8. +

        result is array.

        +
      +
      +
    13. +

      Return CreateIterResultObject(result, false).

      +
    +

    The class string of an iterator prototype object for a given interface is the result of concatenting the identifier of the interface and +the string “Iterator”.

    +

    4.6.10. Maplike declarations

    +

    Any object that implements an interface that has a maplike declaration must have a [[BackingMap]] internal slot, which is +initially set to a newly created Map object. +This Map object’s [[MapData]] internal slot is +the object’s map entries.

    +

    If an interface A is declared with +a maplike declaration, then +there exists a number of additional properties on A’s interface prototype object. +These additional properties are described in the sub-sections below.

    +

    Some of the properties below are defined to have a function object value +that forwards to the internal map object for a given function name. Such functions behave as follows when invoked:

    +
      +
    1. +

      Let O be the this value.

      +
    2. +

      Let arguments be the list of arguments passed to this function.

      +
    3. +

      Let name be the function name.

      +
    4. +

      If O is a platform object, +then perform a security check, passing:

      +
        +
      • +

        the platform object O,

        +
      • +

        the ECMAScript global environment associated with this Function,

        +
      • +

        an identifier equal to name, and

        +
      • +

        the type “method”.

        +
      +
    5. +

      If O is not an object that implements A, then throw a TypeError.

      +
    6. +

      Let map be the Map object that is the value of O’s [[BackingMap]] internal slot.

      +
    7. +

      Let function be the result of calling the [[Get]] internal method of map passing name and map as arguments.

      +
    8. +

      If IsCallable(function) is false, then throw a TypeError.

      +
    9. +

      Return the result of calling the [[Call]] internal method of function with map as thisArg and arguments as argumentsList.

      +
    +
    4.6.10.1. size
    +

    There must exist a property named “size” on A’s interface prototype object with the following characteristics:

    +
      +
    • +

      The property has attributes { [[Get]]: G, [[Enumerable]]: false, [[Configurable]]: true }, +where G is the interface’s map size getter, +defined below.

      +
    • +

      The map size getter is +a Function object whose +behavior when invoked is as follows:

      +
        +
      1. +

        Let O be the this value.

        +
      2. +

        If O is a platform object, +then perform a security check, passing:

        +
          +
        • +

          the platform object O,

          +
        • +

          the ECMAScript global environment associated with this Function,

          +
        • +

          the identifier “size”, and

          +
        • +

          the type “getter”.

          +
        +
      3. +

        If O is not an object that implements A, then throw a TypeError.

        +
      4. +

        Let map be the Map object that is the value of O’s [[BackingMap]] internal slot.

        +
      5. +

        Return the result of calling the [[Get]] internal method of map passing “size” and map as arguments.

        +
      +

      The value of the Function object’s “length” property is the Number value 0.

      +

      The value of the Function object’s “name” property is the String value “size”.

      +
    +
    4.6.10.2. entries
    +

    A property named “entries” must exist on A’s interface prototype object with attributes { [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true } and whose value is the function object that is the value of +the @@iterator property.

    +
    4.6.10.3. keys and values
    +

    For both of “keys” and “values”, there must exist a property with that name on A’s interface prototype object with the following characteristics:

    + +

    The value of the Function objects’ “length” properties is the Number value 0.

    +

    The value of the Function object’s “name” property is the String value “keys” or “values”, correspondingly.

    +
    4.6.10.4. get and has
    +

    For both of “get” and “has”, there must exist a property with that name on A’s interface prototype object with the following characteristics:

    +
      +
    • +

      The property has attributes { [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true }.

      +
    • +

      The value of the property is a Function object that behaves as follows when invoked:

      +
        +
      1. +

        Let O be the this value.

        +
      2. +

        Let name be the name of the property – “get” or “has”.

        +
      3. +

        If O is a platform object, +then perform a security check, passing:

        +
          +
        • +

          the platform object O,

          +
        • +

          the ECMAScript global environment associated with this Function,

          +
        • +

          an identifier equal to name, and

          +
        • +

          the type “method”.

          +
        +
      4. +

        If O is not an object that implements A, then throw a TypeError.

        +
      5. +

        Let map be the Map object that is the value of O’s [[BackingMap]] internal slot.

        +
      6. +

        Let keyType be the key type specified in the maplike declaration.

        +
      7. +

        Let function be the result of calling the [[Get]] internal method of map passing name and map as arguments.

        +
      8. +

        Let keyArg be the first argument passed to this function, or undefined if not supplied.

        +
      9. +

        Let keyIDL be the result of converting keyArg to an IDL value of type keyType.

        +
      10. +

        Let key be the result of converting keyIDL to an ECMAScript value.

        +
      11. +

        Return the result of calling the [[Call]] internal method of function with map as thisArg and the single value key as argumentsList.

        +
      +
    +

    The value of the Function objects’ “length” properties is the Number value 1.

    +

    The value of the Function object’s “name” property is the String value “get” or “has”, correspondingly.

    +
    4.6.10.5. clear
    +

    If A and A’s consequential interfaces do not declare an interface member with identifier “clear”, and A was declared with a read–write maplike declaration, +then a property named “clear” and the following characteristics +must exist on A’s interface prototype object:

    + +

    The value of the Function object’s “length” property is the Number value 0.

    +

    The value of the Function object’s “name” property is the String value “clear”.

    +
    4.6.10.6. delete
    +

    If A and A’s consequential interfaces do not declare an interface member with identifier “delete”, and A was declared with a read–write maplike declaration, +then a property named “delete” and the following characteristics +must exist on A’s interface prototype object:

    +
      +
    • +

      The property has attributes { [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true }.

      +
    • +

      The value of the property is a Function object that behaves as follows when invoked:

      +
        +
      1. +

        Let O be the this value.

        +
      2. +

        If O is a platform object, +then perform a security check, passing:

        +
          +
        • +

          the platform object O,

          +
        • +

          the ECMAScript global environment associated with this Function,

          +
        • +

          the identifier “delete”, and

          +
        • +

          the type “method”.

          +
        +
      3. +

        If O is not an object that implements A, then throw a TypeError.

        +
      4. +

        Let map be the Map object that is the value of O’s [[BackingMap]] internal slot.

        +
      5. +

        Let keyType be the key type specified in the maplike declaration.

        +
      6. +

        Let function be the result of calling the [[Get]] internal method of map passing “delete” and map as arguments.

        +
      7. +

        Let keyArg be the first argument passed to this function, or undefined if not supplied.

        +
      8. +

        Let keyIDL be the result of converting keyArg to an IDL value of type keyType.

        +
      9. +

        Let key be the result of converting keyIDL to an ECMAScript value.

        +
      10. +

        Return the result of calling the [[Call]] internal method of function with map as thisArg and the single value key as argumentsList.

        +
      +
    +

    The value of the Function object’s “length” property is the Number value 1.

    +

    The value of the Function object’s “name” property is the String value “delete”.

    +
    4.6.10.7. set
    +

    If A and A’s consequential interfaces do not declare an interface member with identifier “set”, and A was declared with a read–write maplike declaration, +then a property named “set” and the following characteristics +must exist on A’s interface prototype object:

    +
      +
    • +

      The property has attributes { [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true }.

      +
    • +

      The value of the property is a Function object that behaves as follows when invoked:

      +
        +
      1. +

        Let O be the this value.

        +
      2. +

        If O is a platform object, +then perform a security check, passing:

        +
          +
        • +

          the platform object O,

          +
        • +

          the ECMAScript global environment associated with this Function,

          +
        • +

          the identifier “set”, and

          +
        • +

          the type “method”.

          +
        +
      3. +

        If O is not an object that implements A, then throw a TypeError.

        +
      4. +

        Let map be the Map object that is the value of O’s [[BackingMap]] internal slot.

        +
      5. +

        Let keyType and valueType be the key and value types specified in the maplike declaration.

        +
      6. +

        Let function be the result of calling the [[Get]] internal method of map passing “set” and map as arguments.

        +
      7. +

        Let keyArg be the first argument passed to this function, or undefined if not supplied.

        +
      8. +

        Let valueArg be the second argument passed to this function, or undefined if not supplied.

        +
      9. +

        Let keyIDL be the result of converting keyArg to an IDL value of type keyType.

        +
      10. +

        Let valueIDL be the result of converting valueArg to an IDL value of type valueType.

        +
      11. +

        Let key be the result of converting keyIDL to an ECMAScript value.

        +
      12. +

        Let value be the result of converting valueIDL to an ECMAScript value.

        +
      13. +

        Let result be the result of calling the [[Call]] internal method of function with map as thisArg and key and value as argumentsList.

        +
      14. +

        Assert: result is not an abrupt completion.

        +
      15. +

        Return O.

        +
      +
    +

    The value of the Function object’s “length” property is the Number value 2.

    +

    The value of the Function object’s “name” property is the String value “set”.

    +

    4.6.11. Setlike declarations

    +

    Any object that implements an interface that has a setlike declaration must have a [[BackingSet]] internal slot, which is +initially set to a newly created Set object. +This Set object’s [[SetData]] internal slot is +the object’s set entries.

    +

    If an interface A is declared with +a setlike declaration, then +there exists a number of additional properties on A’s interface prototype object. +These additional properties are described in the sub-sections below.

    +

    Some of the properties below are defined to have a function object value +that forwards to the internal set object for a given function name. Such functions behave as follows when invoked:

    +
      +
    1. +

      Let O be the this value.

      +
    2. +

      Let arguments be the list of arguments passed to this function.

      +
    3. +

      Let name be the function name.

      +
    4. +

      If O is a platform object, +then perform a security check, passing:

      +
        +
      • +

        the platform object O,

        +
      • +

        the ECMAScript global environment associated with this Function,

        +
      • +

        an identifier equal to name, and

        +
      • +

        the type “method”.

        +
      +
    5. +

      If O is not an object that implements A, then throw a TypeError.

      +
    6. +

      Let set be the Set object that is the value of O’s [[BackingSet]] internal slot.

      +
    7. +

      Let function be the result of calling the [[Get]] internal method of set passing name and set as arguments.

      +
    8. +

      If IsCallable(function) is false, then throw a TypeError.

      +
    9. +

      Return the result of calling the [[Call]] internal method of function with set as thisArg and arguments as argumentsList.

      +
    +
    4.6.11.1. size
    +

    There must exist a property named “size” on A’s interface prototype object with the following characteristics:

    +
      +
    • +

      The property has attributes { [[Get]]: G, [[Enumerable]]: false, [[Configurable]]: true }, +where G is the interface’s set size getter, +defined below.

      +
    • +

      The set size getter is +a Function object whose +behavior when invoked is as follows:

      +
        +
      1. +

        Let O be the this value.

        +
      2. +

        If O is a platform object, +then perform a security check, passing:

        +
          +
        • +

          the platform object O,

          +
        • +

          the ECMAScript global environment associated with this Function,

          +
        • +

          the identifier “size”, and

          +
        • +

          the type “getter”.

          +
        +
      3. +

        If O is not an object that implements A, then throw a TypeError.

        +
      4. +

        Let set be the Set object that is the value of O’s [[BackingSet]] internal slot.

        +
      5. +

        Return the result of calling the [[Get]] internal method of set passing “size” and set as arguments.

        +
      +

      The value of the Function object’s “length” property is the Number value 0.

      +

      The value of the Function object’s “name” property is the String value “size”.

      +
    +
    4.6.11.2. values
    +

    A property named “values” must exist on A’s interface prototype object with attributes { [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true } and whose value is the function object that is the value of +the @@iterator property.

    +
    4.6.11.3. entries and keys
    +

    For both of “entries” and “keys”, there must exist a property with that name on A’s interface prototype object with the following characteristics:

    + +

    The value of the Function objects’ “length” properties is the Number value 0.

    +

    The value of the Function object’s “name” property is the String value “entries” or “keys”, correspondingly.

    +
    4.6.11.4. has
    +

    There must exist a property with named “has” on A’s interface prototype object with the following characteristics:

    +
      +
    • +

      The property has attributes { [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true }.

      +
    • +

      The value of the property is a Function object that behaves as follows when invoked:

      +
        +
      1. +

        Let O be the this value.

        +
      2. +

        If O is a platform object, +then perform a security check, passing:

        +
          +
        • +

          the platform object O,

          +
        • +

          the ECMAScript global environment associated with this Function,

          +
        • +

          the identifier “has”, and

          +
        • +

          the type “method”.

          +
        +
      3. +

        If O is not an object that implements A, then throw a TypeError.

        +
      4. +

        Let set be the Set object that is the value of O’s [[BackingSet]] internal slot.

        +
      5. +

        Let type be the value type specified in the setlike declaration.

        +
      6. +

        Let function be the result of calling the [[Get]] internal method of set passing “has” and set as arguments.

        +
      7. +

        Let arg be the first argument passed to this function, or undefined if not supplied.

        +
      8. +

        Let idlValue be the result of converting arg to an IDL value of type type.

        +
      9. +

        Let value be the result of converting idlValue to an ECMAScript value.

        +
      10. +

        Return the result of calling the [[Call]] internal method of function with set as thisArg and the single value value as argumentsList.

        +
      +
    +

    The value of the Function object’s “length” property is a Number value 1.

    +

    The value of the Function object’s “name” property is the String value “has”.

    +
    4.6.11.5. add and delete
    +

    For both of “add” and “delete”, if:

    + +

    then a property with that name and the following characteristics +must exist on A’s interface prototype object:

    +
      +
    • +

      The property has attributes { [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true }.

      +
    • +

      The value of the property is a Function object that behaves as follows when invoked:

      +
        +
      1. +

        Let O be the this value.

        +
      2. +

        Let name be the name of the property – “add” or “delete”.

        +
      3. +

        If O is a platform object, +then perform a security check, passing:

        +
          +
        • +

          the platform object O,

          +
        • +

          the ECMAScript global environment associated with this Function,

          +
        • +

          an identifier equal to name, and

          +
        • +

          the type “method”.

          +
        +
      4. +

        If O is not an object that implements A, then throw a TypeError.

        +
      5. +

        Let set be the Set object that is the value of O’s [[BackingSet]] internal slot.

        +
      6. +

        Let type be the value type specified in the setlike declaration.

        +
      7. +

        Let function be the result of calling the [[Get]] internal method of set passing name and set as arguments.

        +
      8. +

        Let arg be the first argument passed to this function, or undefined if not supplied.

        +
      9. +

        Let idlValue be the result of converting arg to an IDL value of type type.

        +
      10. +

        Let value be the result of converting idlValue to an ECMAScript value.

        +
      11. +

        Let result be the result of calling the [[Call]] internal method of function with set as thisArg and the single value value as argumentsList.

        +
      12. +

        Assert: result is not an abrupt completion.

        +
      13. +

        If name is "delete", then:

        +
          +
        1. +

          Return result.

          +
        +
      14. +

        Otherwise:

        +
          +
        1. +

          Return O.

          +
        +
      +
    +

    The value of the Function object’s “length” property is the Number value 1.

    +

    The value of the Function object’s “name” property is the String value “add” or “delete”, correspondingly.

    +
    4.6.11.6. clear
    +

    If A and A’s consequential interfaces do not declare an interface member with a matching identifier, and A was declared with a read–write setlike declaration, +then a property named “clear” and the following characteristics +must exist on A’s interface prototype object:

    + +

    The value of the Function object’s “length” property is the Number value 0.

    +

    The value of the Function object’s “name” property is the String value “clear”.

    +

    4.6.12. Initializing objects from iterables

    +

    Some objects, which are attempting to emulate map- and set-like interfaces, will want to accept iterables +as constructor parameters and initialize themselves in this way. Here we provide some algorithms that can +be invoked in order to do so in the same way as in the ECMAScript spec, so that those objects behave +the same as the built-in Map and Set objects.

    +

    To add map elements from an iterable iterable to +an object destination with adder method name adder, perform the following steps:

    +
      +
    1. +

      If Type(destination) is not Object, then, throw a TypeError.

      +
    2. +

      If iterable is not present, let iterable be undefined.

      +
    3. +

      If iterable is either undefined or null, then let iter be undefined.

      +
    4. +

      Else,

      +
        +
      1. +

        Let adder be the result of Get(destination, adder).

        +
      2. +

        ReturnIfAbrupt(adder).

        +
      3. +

        If IsCallable(adder) is false, throw a TypeError.

        +
      4. +

        Let iter be the result of GetIterator(iterable).

        +
      5. +

        ReturnIfAbrupt(iter).

        +
      +
    5. +

      If iter is undefined, then return.

      +
    6. +

      Repeat

      +
        +
      1. +

        Let next be the result of IteratorStep(iter).

        +
      2. +

        ReturnIfAbrupt(next).

        +
      3. +

        If next is false, then return NormalCompletion(destination).

        +
      4. +

        Let nextItem be IteratorValue(next).

        +
      5. +

        ReturnIfAbrupt(nextItem).

        +
      6. +

        If Type(nextItem) is not Object, then throw a TypeError.

        +
      7. +

        Let k be the result of Get(nextItem, "0").

        +
      8. +

        ReturnIfAbrupt(k).

        +
      9. +

        Let v be the result of Get(nextItem, "1").

        +
      10. +

        ReturnIfAbrupt(v).

        +
      11. +

        Let status be the result of calling the [[Call]] internal method of adder with destination as thisArgument and (k, v) as argumentsList.

        +
      12. +

        ReturnIfAbrupt(status).

        +
      +
    +

    4.7. Implements statements

    +

    The interface prototype object of an interface A must have a copy of +each property that corresponds to one of the constants, attributes, operations, iterable declarations, maplike declarations and setlike declarations that exist on all of the interface prototype objects of A’s consequential interfaces. +For operations, where the property is a data property with a Function object value, each copy of the property must have +distinct Function objects. For attributes, each +copy of the accessor property must have +distinct Function objects for their getters, +and similarly with their setters.

    +
    +

    When invoking an operation by calling + a Function object that is the value of one of the copies that exists + due to an implements statement, the this value is + checked to ensure that it is an object that implements the interface corresponding to the interface prototype object that the property is on.

    +

    For example, consider the following IDL:

    +
    interface A {
    +  void f();
    +};
    +        
    +interface B { };
    +B implements A;
    +        
    +interface C { };
    +C implements A;
    +
    +

    Attempting to call B.prototype.f on an object that implements A (but not B) or one + that implements C will result in a TypeError being thrown. However, + calling A.prototype.f on an object that implements B or one that implements C would succeed. This is handled by the algorithm in §4.6.7 Operations that defines how IDL operation invocation works in ECMAScript.

    +

    Similar behavior is required for the getter and setter Function objects that correspond to an IDL attributes, + and this is handled in §4.6.6 Attributes.

    +
    +

    4.8. Platform objects implementing interfaces

    +

    Every platform object is associated with a global environment, just +as the initial objects are. +It is the responsibility of specifications using Web IDL to state +which global environment (or, by proxy, which global object) each platform +object is associated with.

    +

    The primary interface of a platform object +that implements one or more interfaces is the most-derived non-supplemental interface that it implements. The value of the internal [[Prototype]] +property of the platform object is the interface prototype object of the primary interface from the platform object’s associated global environment.

    +

    The global environment that a given platform object is associated with can change after it has been created. When +the global environment associated with a platform object is changed, its internal +[[Prototype]] property must be immediately +updated to be the interface prototype object of the primary interface from the platform object’s newly associated global environment.

    +

    Every platform object that implements an [Unforgeable]-annotated +interface and which does not have a stringifier that is unforgeable on any of the +interfaces it implements must have a property with the +following characteristics:

    +
      +
    • +

      The name of the property is “toString”.

      +
    • +

      The property has attributes { [[Writable]]: false, [[Enumerable]]: true, [[Configurable]]: false }.

      +
    • +

      The value of the property is %ObjProto_toString%, the initial value of Object.prototype.toString.

      +
    +

    Every platform object that implements an [Unforgeable]-annotated +interface and which does not have a serializer that is unforgeable on any of the +interfaces it implements must have a property with the +following characteristics:

    +
      +
    • +

      The name of the property is “toJSON”.

      +
    • +

      The property has attributes { [[Writable]]: false, [[Enumerable]]: true, [[Configurable]]: false }.

      +
    • +

      The value of the property is undefined.

      +
    +

    Every platform object that implements an [Unforgeable]-annotated +interface must have a property with the +following characteristics:

    +
      +
    • +

      The name of the property is “valueOf”.

      +
    • +

      The property has attributes { [[Writable]]: false, [[Enumerable]]: true, [[Configurable]]: false }.

      +
    • +

      The value of the property is a Function object whose behavior +is as follows:

      +
        +
      1. +

        Return the this value.

        +
      +

      This Function object is the default unforgeable valueOf function.

      +
    • +

      The value of the Function object’s “length” +property is the Number value 0.

      +
    • +

      The value of the Function object’s “name” property is the String value “valueOf”.

      +
    +

    The class string of +a platform object that implements one or more interfaces +must be the identifier of +the primary interface of the platform object.

    +

    4.8.1. Indexed and named properties

    +

    If a platform object implements an interface that supports indexed or named properties, +the object will appear to have additional properties that correspond to the +object’s indexed and named properties. These properties are not “real” own +properties on the object, but are made to look like they are by being exposed +by the [[GetOwnProperty]] internal method.

    +

    However, when the [Global] or +[PrimaryGlobal] extended attribute has been used, +named properties are not exposed on the object but on another object +in the prototype chain, the named properties object.

    +

    It is permissible for an object to implement multiple interfaces that support indexed properties. +However, if so, and there are conflicting definitions as to the object’s supported property indices, +or if one of the interfaces is a supplemental interface for the +platform object, then it is undefined what additional properties the object will appear to +have, or what its exact behavior will be with regard to its indexed properties. +The same applies for named properties.

    +

    The indexed property getter that is defined on the derived-most interface that the +platform object implements is the one that defines the behavior +when indexing the object with an array index. Similarly for indexed property setters. +This way, the definitions of these special operations from +ancestor interfaces can be overridden.

    +

    Platform objects implementing an interface that supports indexed or named properties cannot be fixed; if Object.freeze, Object.seal or Object.preventExtensions is called on one of these objects, the function +must throw a TypeError. +Similarly, an interface prototype object that exposes named properties due to the use of [Global] or +[PrimaryGlobal] +also must throw a TypeError if one of the three functions above is called on it.

    +

    The name of each property that appears to exist due to an object supporting indexed properties +is an array index property name, which is a property +name P such that Type(P) is String +and for which the following algorithm returns true:

    +
      +
    1. +

      Let i be ToUint32(P).

      +
    2. +

      Let s be ToString(i).

      +
    3. +

      If sP or i = 232 − 1, then return false.

      +
    4. +

      Return true.

      +
    +

    A property name is an unforgeable property name on a +given platform object if the object implements an interface that +has an interface member with that identifier +and that interface member is unforgeable on any of +the interfaces that O implements. If the object implements an +[Unforgeable]-annotated interface, then “toString” and “valueOf” are +also unforgeable property names on that object.

    +

    The named property visibility algorithm is used to determine if +a given named property is exposed on an object. Some named properties are not exposed on an object +depending on whether the [OverrideBuiltins] extended attribute was used. The algorithm +operates as follows, with property name P and object O:

    +
      +
    1. +

      If P is an unforgeable property name on O, then return false.

      +
    2. +

      If O implements an interface with +an [Unforgeable]-annotated attribute whose identifier is P, then return false.

      +
    3. +

      If P is not a supported property name of O, then return false.

      +
    4. +

      If O implements an interface that has the [OverrideBuiltins] extended attribute, then return true.

      +
    5. +

      If O has an own property named P, then return false.

      +
    6. +

      Initialize prototype to be the value of the internal [[Prototype]] property of O.

      +
    7. +

      While prototype is not null:

      +
        +
      1. +

        If prototype is not a named properties object, +and prototype has an own property named P, then return false.

        +
      2. +

        Set prototype to be the value of the internal [[Prototype]] property of prototype.

        +
      +
    8. +

      Return true.

      +
    +
    +

    This should ensure that for objects with named properties, property resolution is done in the following order:

    +
      +
    1. +

      Indexed properties.

      +
    2. +

      Unforgeable attributes and operations.

      +
    3. +

      Then, if [OverrideBuiltins]:

      +
        +
      1. +

        Named properties.

        +
      2. +

        Own properties.

        +
      3. +

        Properties from the prototype chain.

        +
      +
    4. +

      Otherwise, if not [OverrideBuiltins]:

      +
        +
      1. +

        Own properties.

        +
      2. +

        Properties from the prototype chain.

        +
      3. +

        Named properties.

        +
      +
    +
    +

    Support for getters is +handled by the platform object [[GetOwnProperty]] method defined in section §4.8.3 Platform object [[GetOwnProperty]] method, and +for setters by the platform object [[DefineOwnProperty]] method defined in section §4.8.7 Platform object [[DefineOwnProperty]] method and the platform object [[Set]] method defined in section §4.8.6 Platform object [[Set]] method.

    +

    4.8.2. The PlatformObjectGetOwnProperty abstract operation

    +

    The PlatformObjectGetOwnProperty +abstract operation performs the following steps when called with an +object O, a property name P, and a boolean ignoreNamedProps value:

    +
      +
    1. +

      If O supports indexed properties and P is an array index property name, then:

      +
        +
      1. +

        Let index be the result of calling ToUint32(P).

        +
      2. +

        If index is a supported property index, then:

        +
          +
        1. +

          Let operation be the operation used to declare the indexed property getter.

          +
        2. +

          Let value be an uninitialized variable.

          +
        3. +

          If operation was defined without an identifier, then +set value to the result of performing the steps listed in the interface description to determine the value of an indexed property with index as the index.

          +
        4. +

          Otherwise, operation was defined with an identifier. Set value to the result +of performing the steps listed in the description of operation with index as the only argument value.

          +
        5. +

          Let desc be a newly created Property Descriptor with no fields.

          +
        6. +

          Set desc.[[Value]] to the result of converting value to an ECMAScript value.

          +
        7. +

          If O implements an interface with an indexed property setter, then set desc.[[Writable]] to true, otherwise set it to false.

          +
        8. +

          Set desc.[[Enumerable]] and desc.[[Configurable]] to true.

          +
        9. +

          Return desc.

          +
        +
      3. +

        Set ignoreNamedProps to true.

        +
      +
    2. +

      If O supports named properties, O does not +implement an interface with the [Global] or [PrimaryGlobal] extended attribute, the result of running the named property visibility algorithm with +property name P and object O is true, and ignoreNamedProps is false, then:

      +
        +
      1. +

        Let operation be the operation used to declare the named property getter.

        +
      2. +

        Let value be an uninitialized variable.

        +
      3. +

        If operation was defined without an identifier, then +set value to the result of performing the steps listed in the interface description to determine the value of a named property with P as the name.

        +
      4. +

        Otherwise, operation was defined with an identifier. Set value to the result +of performing the steps listed in the description of operation with P as the only argument value.

        +
      5. +

        Let desc be a newly created Property Descriptor with no fields.

        +
      6. +

        Set desc.[[Value]] to the result of converting value to an ECMAScript value.

        +
      7. +

        If O implements an interface with a named property setter, then set desc.[[Writable]] to true, otherwise set it to false.

        +
      8. +

        If O implements an interface with the +[LegacyUnenumerableNamedProperties] extended attribute, +then set desc.[[Enumerable]] to false, +otherwise set it to true.

        +
      9. +

        Set desc.[[Configurable]] to true.

        +
      10. +

        Return desc.

        +
      +
    3. +

      Return OrdinaryGetOwnProperty(O, P).

      +
    +

    4.8.3. Platform object [[GetOwnProperty]] method

    +

    The internal [[GetOwnProperty]] method of every platform object O that implements an interface which supports indexed or named properties must behave as follows when called with property name P:

    +
      +
    1. +

      Return the result of invoking the PlatformObjectGetOwnProperty abstract operation with O, P, and false as +arguments.

      +
    +

    4.8.4. Invoking a platform object indexed property setter

    +

    To invoke an indexed property setter with property name P and ECMAScript value V, the following steps must be performed:

    +
      +
    1. +

      Let index be the result of calling ToUint32(P).

      +
    2. +

      Let creating be true if index is not a supported property index, and false otherwise.

      +
    3. +

      Let operation be the operation used to declare the indexed property setter.

      +
    4. +

      Let T be the type of the second argument of operation.

      +
    5. +

      Let value be the result of converting V to an IDL value of type T.

      +
    6. +

      If operation was defined without an identifier, then:

      +
        +
      1. +

        If creating is true, then perform the steps listed in the interface description to set the value of a new indexed property with index as the index and value as the value.

        +
      2. +

        Otherwise, creating is false. Perform the steps listed in the interface description to set the value of an existing indexed property with index as the index and value as the value.

        +
      +
    7. +

      Otherwise, operation was defined with an identifier. Perform the steps listed in the description of operation with index and value as the two argument values.

      +
    +

    4.8.5. Invoking a platform object named property setter

    +

    To invoke a named property setter with property name P and ECMAScript value V, the following steps must be performed:

    +
      +
    1. +

      Let creating be true if P is not a supported property name, and false otherwise.

      +
    2. +

      Let operation be the operation used to declare the named property setter.

      +
    3. +

      Let T be the type of the second argument of operation.

      +
    4. +

      Let value be the result of converting V to an IDL value of type T.

      +
    5. +

      If operation was defined without an identifier, then:

      +
        +
      1. +

        If creating is true, then perform the steps listed in the interface description to set the value of a new named property with P as the name and value as the value.

        +
      2. +

        Otherwise, creating is false. Perform the steps listed in the interface description to set the value of an existing named property with P as the name and value as the value.

        +
      +
    6. +

      Otherwise, operation was defined with an identifier. Perform the steps listed in the description of operation with index and value as the two argument values.

      +
    +

    4.8.6. Platform object [[Set]] method

    +

    The internal [[Set]] method of every platform object O that implements an interface which supports indexed or named properties must behave as follows when called +with property name P, value V, and +ECMAScript language value Receiver:

    +
      +
    1. +

      If O and Receiver are the same object, +then:

      +
        +
      1. +

        If O supports indexed properties, P is an array index property name, and O implements an interface with an indexed property setter, then:

        +
          +
        1. +

          Invoke the indexed +property setter with P and V.

          +
        2. +

          Return true.

          +
        +
      2. +

        If O supports named properties, Type(P) is String, P is not an array index property name, and O implements an interface with a named property setter, then:

        +
          +
        1. +

          Invoke the named +property setter with P and V.

          +
        2. +

          Return true.

          +
        +
      +
    2. +

      Let ownDesc be the result of invoking the PlatformObjectGetOwnProperty abstract operation with O, P, and true as +arguments.

      +
    3. +

      Perform steps 3-11 of the default [[Set]] internal method.

      +
    +

    4.8.7. Platform object [[DefineOwnProperty]] method

    +

    When the internal [[DefineOwnProperty]] method of a platform object O that +implements an interface which supports indexed or named properties is +called with property key P and Property Descriptor Desc, the following steps must be taken:

    +
      +
    1. +

      If O supports indexed properties and P is an array index property name, then:

      +
        +
      1. +

        If the result of calling IsDataDescriptor(Desc) is false, then return false.

        +
      2. +

        If O does not implement an interface with an indexed property setter, then return false.

        +
      3. +

        Invoke the indexed property setter with P and Desc.[[Value]].

        +
      4. +

        Return true.

        +
      +
    2. +

      If O supports named properties, O does not implement an interface with the +[Global] or [PrimaryGlobal] extended attribute and P is not an unforgeable property name of O, then:

      +
        +
      1. +

        Let creating be true if P is not a supported property name, and false otherwise.

        +
      2. +

        If O implements an interface with the [OverrideBuiltins] extended attribute or O does not have an own property +named P, then:

        +
          +
        1. +

          If creating is false and O does not implement an +interface with a named property setter, then return false.

          +
        2. +

          If O implements an interface with a named property setter, then:

          +
            +
          1. +

            If the result of calling IsDataDescriptor(Desc) is false, then return false.

            +
          2. +

            Invoke the named property setter with P and Desc.[[Value]].

            +
          3. +

            Return true.

            +
          +
        +
      +
    3. +

      If O does not implement an interface with the +[Global] or +[PrimaryGlobal] extended attribute, then set Desc.[[Configurable]] to true.

      +
    4. +

      Return OrdinaryDefineOwnProperty(O, P, Desc).

      +
    +

    4.8.8. Platform object [[Delete]] method

    +

    The internal [[Delete]] method of every platform object O that implements an interface which supports indexed or named properties must behave as follows when called with property name P.

    +
      +
    1. +

      If O supports indexed properties and P is an array index property name, then:

      +
        +
      1. +

        Let index be the result of calling ToUint32(P).

        +
      2. +

        If index is not a supported property index, then return true.

        +
      3. +

        Return false.

        +
      +
    2. +

      If O supports named properties, O does not implement an interface with the +[Global] or [PrimaryGlobal] extended attribute and the result of calling the named property visibility algorithm with property name P and object O is true, then:

      +
        +
      1. +

        If O does not implement an interface with a named property deleter, then return false.

        +
      2. +

        Let operation be the operation used to declare the named property deleter.

        +
      3. +

        If operation was defined without an identifier, then:

        +
          +
        1. +

          Perform the steps listed in the interface description to delete an existing named property with P as the name.

          +
        2. +

          If the steps indicated that the deletion failed, then return false.

          +
        +
      4. +

        Otherwise, operation was defined with an identifier:

        +
          +
        1. +

          Perform the steps listed in the description of operation with P as the only argument value.

          +
        2. +

          If operation was declared with a return type of boolean and the steps returned false, then return false.

          +
        +
      5. +

        Return true.

        +
      +
    3. +

      If O has an own property with name P, then:

      +
        +
      1. +

        If the property is not configurable, then return false.

        +
      2. +

        Otherwise, remove the property from O.

        +
      +
    4. +

      Return true.

      +
    +

    4.8.9. Platform object [[Call]] method

    +

    The internal [[Call]] method of every platform object O that implements an interface I with at least one legacy caller must behave as follows, assuming arg0..n−1 is the list of argument +values passed to [[Call]]:

    +
      +
    1. +

      Initialize S to the effective overload set for legacy callers on I and with argument count n.

      +
    2. +

      Let <operation, values> be the result of passing S and arg0..n−1 to the overload resolution algorithm.

      +
    3. +

      Perform the actions listed in the description of the legacy caller operation with values as the argument values.

      +
    4. +

      Return the result of converting the return value from those actions to an ECMAScript value of the type operation is declared to return (or undefined if operation is declared to return void).

      +
    +

    4.8.10. Property enumeration

    +

    This document does not define a complete property enumeration order +for all platform objects implementing interfaces (or for platform objects representing exceptions). +However, if a platform object implements an interface that supports indexed or named properties, then +properties on the object must be +enumerated in the following order:

    +
      +
    1. +

      If the object supports indexed properties, then +the object’s supported property indices are +enumerated first, in numerical order.

      +
    2. +

      If the object supports named properties and doesn’t implement an interface with the +[LegacyUnenumerableNamedProperties] extended attribute, then +the object’s supported property names that +are visible according to the named property visibility algorithm are enumerated next, in the order given in the definition of the set of supported property names.

      +
    3. +

      Finally, any enumerable own properties or properties from the object’s prototype chain are then enumerated, +in no defined order.

      +
    +

    Note: Future versions of the ECMAScript specification may define a total order for property enumeration.

    +

    4.9. User objects implementing callback interfaces

    +

    As described in §3.10 Objects implementing interfaces, callback interfaces can be +implemented in script by an ECMAScript object. +The following cases determine whether and how a given object +is considered to be a user object implementing a callback interface:

    +
      +
    • +

      If the interface is a single operation callback interface (defined below) then any object apart from a native RegExp object is considered to implement the interface. +The implementation of the operation (or set of overloaded operations) is +as follows:

      +
        +
      • +

        If the object is callable, +then the implementation of the operation (or set of overloaded operations) is +the callable object itself.

        +
      • +

        Otherwise, the object is not callable. +The implementation of the operation (or set of overloaded operations) is +the result of invoking the internal [[Get]] method +on the object with a property name that is the identifier of the operation.

        +
      +
    • +

      Otherwise, the interface is not a single operation callback interface. +Any object that is not a native RegExp object is considered to implement the interface. +For each operation declared on the interface with a given identifier, the implementation +is the result of invoking [[Get]] on the object with a +property name that is that identifier.

      +
    +

    Note that ECMAScript objects need not have +properties corresponding to constants on them to be considered as user objects implementing interfaces that happen +to have constants declared on them.

    +

    A single operation callback interface is +a callback interface that:

    + +

    To call a user object’s operation, given a callback interface type value value, sometimes-optional operation name opName, +list of argument values arg0..n−1 each of which is +either an IDL value or the special value “missing” (representing a missing optional +argument), and optional callback this value thisArg, perform the following steps. These steps will either +return an IDL value or throw an exception.

    +
      +
    1. +

      Let completion be an uninitialized variable.

      +
    2. +

      If thisArg was not given, let thisArg be undefined.

      +
    3. +

      Let O be the ECMAScript object corresponding to value.

      +
    4. +

      Let realm be O’s associated Realm.

      +
    5. +

      Let relevant settings be realm’s settings object.

      +
    6. +

      Let stored settings be value’s callback context.

      +
    7. +

      Prepare to run script with relevant settings.

      +
    8. +

      Prepare to run a callback with stored settings.

      +
    9. +

      Determine the implementation of the operation, X:

      +
        +
      1. +

        If value’s interface is a single operation callback interface and ! IsCallable(O) is true, then set X to O.

        +
      2. +

        Otherwise, opName must be supplied:

        +
          +
        1. +

          Let getResult be Get(O, opName).

          +
        2. +

          If getResult is an abrupt completion, set completion to getResult and jump to the step labeled return.

          +
        3. +

          Set X to getResult.[[Value]].

          +
        +
      +
    10. +

      If ! IsCallable(X) is false, +then set completion to a new Completion{[[Type]]: throw, [[Value]]: a +newly created TypeError object, [[Target]]: empty}, and jump +to the step labeled return.

      +
    11. +

      If value’s interface is not a single operation callback interface, +or if ! IsCallable(O) is false, +set thisArg to O (overriding the provided value).

      +
    12. +

      Let esArgs be an empty List of ECMAScript values.

      +
    13. +

      Let i be 0.

      +
    14. +

      Let count be 0.

      +
    15. +

      While i < n:

      +
        +
      1. +

        If argi is the special value “missing”, then +append undefined to esArgs.

        +
      2. +

        Otherwise, argi is an IDL value:

        +
          +
        1. +

          Let convertResult be the result of converting argi to an ECMAScript value.

          +
        2. +

          If convertResult is an abrupt completion, set completion to convertResult and jump to the step labeled return.

          +
        3. +

          Append convertResult.[[Value]] to esArgs.

          +
        4. +

          Set count to i + 1.

          +
        +
      3. +

        Set i to i + 1.

        +
      +
    16. +

      Truncate esArgs to have length count.

      +
    17. +

      Let callResult be Call(X, thisArg, esArgs).

      +
    18. +

      If callResult is an abrupt completion, set completion to callResult and jump to the step labeled return.

      +
    19. +

      Set completion to the result of converting callResult.[[Value]] to an IDL value of the same type as the operation’s +return type.

      +
    20. +

      Return: at this +point completion will be set to an ECMAScript completion value.

      +
        +
      1. +

        Clean up after running a callback with stored settings.

        +
      2. +

        Clean up after running script with relevant settings.

        +
      3. +

        If completion is a normal completion, return completion.

        +
      4. +

        If completion is an abrupt completion and the operation has a return type that is not a promise type, return completion.

        +
      5. +

        Let reject be the initial value of %Promise%.reject.

        +
      6. +

        Let rejectedPromise be the result of calling reject with %Promise% as the this value and completion.[[Value]] as the single argument value.

        +
      7. +

        Return the result of converting rejectedPromise to the operation’s return type.

        +
      +
    +

    To get a user object’s attribute value, given a callback interface type value object and attribute name attributeName, +perform the following steps. These steps will either return an IDL value or throw an +exception.

    +
      +
    1. +

      Let completion be an uninitialized variable.

      +
    2. +

      Let O be the ECMAScript object corresponding to object.

      +
    3. +

      Let realm be O’s associated Realm.

      +
    4. +

      Let relevant settings be realm’s settings object.

      +
    5. +

      Let stored settings be object’s callback context.

      +
    6. +

      Prepare to run script with relevant settings.

      +
    7. +

      Prepare to run a callback with stored settings.

      +
    8. +

      Let getResult be Get(O, attributeName).

      +
    9. +

      If getResult is an abrupt completion, set completion to getResult and jump to the step labeled return.

      +
    10. +

      Set completion to the result of converting getResult.[[Value]] to an IDL value of the same type as the attribute’s +type.

      +
    11. +

      Return: at this +point completion will be set to an ECMAScript completion value.

      +
        +
      1. +

        Clean up after running a callback with stored settings.

        +
      2. +

        Clean up after running script with relevant settings.

        +
      3. +

        If completion is a normal completion, return completion.

        +
      4. +

        If completion is an abrupt completion and the attribute’s type is not a promise type, return completion.

        +
      5. +

        Let reject be the initial value of %Promise%.reject.

        +
      6. +

        Let rejectedPromise be the result of calling reject with %Promise% as the this value and completion.[[Value]] as the single argument value.

        +
      7. +

        Return the result of converting rejectedPromise to the attribute’s type.

        +
      +
    +

    To set a user object’s attribute value, given a callback interface type value object, attribute name attributeName, and +IDL value value, perform the following steps. These steps will not return +anything, but could throw an exception.

    +
      +
    1. +

      Let completion be an uninitialized variable.

      +
    2. +

      Let O be the ECMAScript object corresponding to object.

      +
    3. +

      Let realm be O’s associated Realm.

      +
    4. +

      Let relevant settings be realm’s settings object.

      +
    5. +

      Let stored settings be object’s callback context.

      +
    6. +

      Prepare to run script with relevant settings.

      +
    7. +

      Prepare to run a callback with stored settings.

      +
    8. +

      Let convertResult be the result of converting value to an +ECMAScript value.

      +
    9. +

      If convertResult is an abrupt completion, set completion to convertResult and jump to the step labeled return.

      +
    10. +

      Set completion to Set(O, attributeName, convertResult.[[Value]], true).

      +
    11. +

      Return: at this +point completion will be set to an ECMAScript completion value, which is +either an abrupt completion or a normal completion for the value true (as returned by Set).

      +
        +
      1. +

        Clean up after running a callback with stored settings.

        +
      2. +

        Clean up after running script with relevant settings.

        +
      3. +

        If completion is an abrupt completion, return completion.

        +
      4. +

        Return NormalCompletion(void).

        +
      +
    +

    4.10. Invoking callback functions

    +

    An ECMAScript callable object that is being +used as a callback function value is +called in a manner similar to how operations on user objects are called (as +described in the previous section).

    +

    To invoke a callback function type value callable with +a list of arguments arg0..n−1, each of which is either +an IDL value or the special value “missing” (representing a missing optional argument), +and with optional callback this value thisArg, perform the following steps. These steps will either +return an IDL value or throw an exception.

    +
      +
    1. +

      Let completion be an uninitialized variable.

      +
    2. +

      If thisArg was not given, let thisArg be undefined.

      +
    3. +

      Let F be the ECMAScript object corresponding to value.

      +
    4. +

      If ! IsCallable(F) is false:

      +
        +
      1. +

        If the callback function’s return type is void, +return.

        +

        Note: This is only possible when the callback function came from an attribute +marked with [TreatNonObjectAsNull].

        +
      2. +

        Return the result of converting undefined to the callback function’s return type.

        +
      +
    5. +

      Let realm be F’s associated Realm.

      +
    6. +

      Let relevant settings be realm’s settings object.

      +
    7. +

      Let stored settings be callable’s callback context.

      +
    8. +

      Prepare to run script with relevant settings.

      +
    9. +

      Prepare to run a callback with stored settings.

      +
    10. +

      Let esArgs be an empty List of ECMAScript values.

      +
    11. +

      Let i be 0.

      +
    12. +

      Let count be 0.

      +
    13. +

      While i < n:

      +
        +
      1. +

        If argi is the special value “missing”, then +append undefined to esArgs.

        +
      2. +

        Otherwise, argi is an IDL value:

        +
          +
        1. +

          Let convertResult be the result of converting argi to an ECMAScript value.

          +
        2. +

          If convertResult is an abrupt completion, set completion to convertResult and jump to the step labeled return.

          +
        3. +

          Append convertResult.[[Value]] to esArgs.

          +
        4. +

          Set count to i + 1.

          +
        +
      3. +

        Set i to i + 1.

        +
      +
    14. +

      Truncate esArgs to have length count.

      +
    15. +

      Let callResult be Call(X, thisArg, esArgs).

      +
    16. +

      If callResult is an abrupt completion, set completion to callResult and jump to the step labeled return.

      +
    17. +

      Set completion to the result of converting callResult.[[Value]] to an IDL value of the same type as the operation’s +return type.

      +
    18. +

      Return: at this +point completion will be set to an ECMAScript completion value.

      +
        +
      1. +

        Clean up after running a callback with stored settings.

        +
      2. +

        Clean up after running script with relevant settings.

        +
      3. +

        If completion is a normal completion, return completion.

        +
      4. +

        If completion is an abrupt completion and the callback function has a return type that is not a promise type, return completion.

        +
      5. +

        Let reject be the initial value of %Promise%.reject.

        +
      6. +

        Let rejectedPromise be the result of calling reject with %Promise% as the this value and completion.[[Value]] as the single argument value.

        +
      7. +

        Return the result of converting rejectedPromise to the callback function’s return type.

        +
      +
    +

    4.11. Namespaces

    +

    For every namespace that is exposed in a given ECMAScript global environment, +a corresponding property must exist on the ECMAScript +environment’s global object. The name of the property is the identifier of the namespace, and its value is an object +called the namespace object.

    +

    The property has the attributes { [[Writable]]: true, [[Enumerable]]: false, +[[Configurable]]: true }. The characteristics of a +namespace object are described in §4.11.1 Namespace object.

    +

    4.11.1. Namespace object

    +

    The namespace object for a given namespace namespace and Realm realm is created as +follows:

    +
      +
    1. +

      Let namespaceObject be ! ObjectCreate(the %ObjectPrototype% of realm).

      +
    2. +

      For each exposed regular operation op that is a namespace member of this namespace,

      +
        +
      1. +

        Let F be the result of creating an operation function given op, namespace, and realm.

        +
      2. +

        Perform ! CreateDataProperty(namespaceObject, op’s identifier, F).

        +
      +
    +

    4.12. Exceptions

    +

    There must exist a property on the ECMAScript global object +whose name is “DOMException” and value is an object called the DOMException constructor object, +which provides access to legacy DOMException code constants and allows construction of +DOMException instances. +The property has the attributes { [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true }.

    +

    4.12.1. DOMException constructor object

    +

    The DOMException constructor object must be a function object but with a [[Prototype]] value of %Error%.

    +

    For every legacy code listed in the error names table, +there must be a property on the DOMException constructor object +whose name and value are as indicated in the table. The property has +attributes { [[Writable]]: false, [[Enumerable]]: true, [[Configurable]]: false }.

    +

    The DOMException constructor object must also have a property named +“prototype” with attributes { [[Writable]]: false, [[Enumerable]]: false, [[Configurable]]: false } whose value is an object called the DOMException prototype object. +This object also provides access to the legacy code values.

    +
    4.12.1.1. DOMException(message, name)
    +

    When the DOMException function is called with arguments message and name, the following steps are taken:

    +
      +
    1. +

      Let F be the active function object.

      +
    2. +

      If NewTarget is undefined, let newTarget be F, else let newTarget be NewTarget.

      +
    3. +

      Let super be F.[[GetPrototypeOf]]().

      +
    4. +

      ReturnIfAbrupt(super).

      +
    5. +

      If IsConstructor(super) is false, throw a TypeError exception.

      +
    6. +

      Let O be Construct(super, «message», newTarget).

      +
    7. +

      If name is not undefined, then

      +
        +
      1. +

        Let name be ToString(name).

        +
      2. +

        Let status be DefinePropertyOrThrow(O, "name", PropertyDescriptor{[[Value]]: name, [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true}).

        +
      3. +

        ReturnIfAbrupt(status).

        +
      4. +

        Let code be the legacy code indicated in the error names table for error name name, or 0 if there is none.

        +
      5. +

        Let status be DefinePropertyOrThrow(O, "code", PropertyDescriptor{[[Value]]: code, [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true}).

        +
      6. +

        ReturnIfAbrupt(status).

        +
      +
    8. +

      Return O.

      +
    +

    4.12.2. DOMException prototype object

    +

    The DOMException prototype object must +have an internal [[Prototype]] property whose value is %ErrorPrototype%.

    +

    The class string of the DOMException prototype object is “DOMExceptionPrototype”.

    +

    There must be a property named “constructor” +on the DOMException prototype object with attributes { [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true } and whose value is the DOMException constructor object.

    +

    For every legacy code listed in the error names table, +there must be a property on the DOMException prototype object +whose name and value are as indicated in the table. The property has +attributes { [[Writable]]: false, [[Enumerable]]: true, [[Configurable]]: false }.

    +

    4.13. Exception objects

    +

    Simple exceptions are represented +by native ECMAScript objects of the corresponding type.

    +

    DOMExceptions are represented by platform objects that inherit from +the DOMException prototype object.

    +

    Every platform object representing a DOMException in ECMAScript is associated with a global environment, just +as the initial objects are. +When an exception object is created by calling the DOMException constructor object, +either normally or as part of a new expression, then the global environment +of the newly created object is associated with must be the same as for the DOMException constructor object itself.

    +

    The value of the internal [[Prototype]] +property of a DOMException object must be the DOMException prototype object from the global environment the exception object is associated with.

    +

    The class string of a DOMException object +must be “DOMException”.

    +

    Note: The intention is for DOMException objects to be just like the other +various native Error objects that the +ECMAScript specification defines, apart from responding differently +to being passed to Object.prototype.toString and it having a “code” property. +If an implementation places non-standard properties on native Error objects, exposing for example +stack traces or error line numbers, then these ought to be exposed +on exception objects too.

    +

    4.14. Creating and throwing exceptions

    +

    First, we define the current global environment as the result of running the following algorithm:

    +
      +
    1. +

      Let F be the Function object used +as the this value in the top-most call +on the ECMAScript call stack where F corresponds to an IDL attribute, operation, indexed property, named property, constructor, named constructor or stringifier.

      +
    2. +

      If F corresponds to an attribute, operation or stringifier, then return +the global environment associated with the interface that definition appears on.

      +
    3. +

      Otherwise, if F corresponds to an indexed or named property, then return +the global environment associated with the interface that +the indexed or named property getter, setter or deleter was defined on.

      +
    4. +

      Otherwise, if F is a named constructor for an interface, or is +an interface object for an +interface that is a constructor, then return the global environment +associated with that interface.

      +
    5. +

      Otherwise, F is an exception field getter. Return +the global environment associated with the exception on which the +exception field was defined.

      +
    +

    When a simple exception or DOMException E is to be created, +with error name N and +optional user agent-defined message M, +the following steps must be followed:

    +
      +
    1. +

      If M was not specified, let M be undefined. Otherwise, let it be the result of converting M to a String value.

      +
    2. +

      Let N be the result of converting N to a String value.

      +
    3. +

      Let args be a list of ECMAScript values.

      +
      +
      +

      E is DOMException

      +
      +

      args is (undefined, N).

      +
      +

      E is a simple exception

      +
      +

      args is (M)

      +
      +
    4. +

      Let G be the current global environment.

      +
    5. +

      Let X be an object determined based on the type of E:

      +
      +
      +

      E is DOMException

      +
      +

      X is the DOMException constructor object from the global environment G.

      +
      +

      E is a simple exception

      +
      +

      X is the constructor for the corresponding ECMAScript error +from the global environment G.

      +
      +
    6. +

      Let O be the result of calling X as a function +with args as the argument list.

      +
    7. +

      Return O.

      +
    +

    When a simple exception or DOMException E is to be thrown, +with error name N and +optional user agent-defined message M, +the following steps must be followed:

    +
      +
    1. +

      Let O be the result of creating the specified exception E with error name N and +optional user agent-defined message M.

      +
    2. +

      Throw O.

      +
    +
    +

    The above algorithms do not restrict platform objects representing exceptions propagating out of a Function to be + ones that are associated with the global environment + where that Function object originated. + For example, consider the IDL:

    +
    interface A {
    +        
    +  /**
        * Calls computeSquareRoot on m, passing x as its argument.
    -   */
    -  double doComputation(MathUtils m, double x);
    +   */
    +  double doComputation(MathUtils m, double x);
     };
    -
    -interface MathUtils {
    -  /**
    -   * If x is negative, throws a NotSupportedError.  Otherwise, returns
    +        
    +interface MathUtils {
    +  /**
    +   * If x is negative, throws a NotSupportedError.  Otherwise, returns
        * the square root of x.
    -   */
    -  double computeSquareRoot(double x);
    -};
    -

    - If we pass a MathUtils object from - a different global environment to doComputation, then the exception - thrown will be from that global environment: -

    -
    ECMAScript
    var a = getA();                           // An A object from this global environment.
    -var m = otherWindow.getMathUtils();       // A MathUtils object from a different global environment.
    -
    -a instanceof Object;                      // Evaluates to true.
    -m instanceof Object;                      // Evaluates to false.
    -m instanceof otherWindow.Object;          // Evaluates to true.
    -
    -try {
    -  a.doComputation(m, -1);
    -} catch (e) {
    -  e instanceof DOMException;              // Evaluates to false.
    -  e instanceof otherWindow.DOMException;  // Evaluates to true.
    -}
    -
    -

    - Any requirements in this document to throw an instance of an ECMAScript built-in - Error MUST use - the built-in from the current global environment. -

    -
    - -
    -

    4.15. Handling exceptions

    - -

    - None of the algorithms or processing requirements in the - ECMAScript language binding catch ECMAScript exceptions. Whenever - an ECMAScript Function is invoked due - to requirements in this section and that Function - ends due to an exception being thrown, that exception - MUST propagate to the caller, and if - not caught there, to its caller, and so on. -

    -
    Example
    -

    - The following IDL fragment - defines two interfaces - and an exception. - The valueOf attribute on ExceptionThrower - is defined to throw an exception whenever an attempt is made - to get its value. -

    -
    IDL
    interface Dahut {
    -  attribute DOMString type;
    +   */
    +  double computeSquareRoot(double x);
     };
    -
    -interface ExceptionThrower {
    -  // This attribute always throws a NotSupportedError and never returns a value.
    -  attribute long valueOf;
    -};
    -

    - Assuming an ECMAScript implementation supporting this interface, - the following code demonstrates how exceptions are handled: -

    -
    ECMAScript
    var d = getDahut();              // Obtain an instance of Dahut.
    -var et = getExceptionThrower();  // Obtain an instance of ExceptionThrower.
    -
    -try {
    -  d.type = { toString: function() { throw "abc"; } };
    -} catch (e) {
    -  // The string "abc" is caught here, since as part of the conversion
    -  // from the native object to a string, the anonymous function
    -  // was invoked, and none of the [[DefaultValue]], ToPrimitive or
    -  // ToString algorithms are defined to catch the exception.
    -}
    -
    -try {
    -  d.type = { toString: { } };
    -} catch (e) {
    -  // An exception is caught here, since an attempt is made to invoke
    -  // [[Call]] on the native object that is the value of toString
    -  // property.
    -}
    -
    -d.type = et;
    -// An uncaught NotSupportedError DOMException is thrown here, since the
    -// [[DefaultValue]] algorithm attempts to get the value of the
    -// "valueOf" property on the ExceptionThrower object.  The exception
    -// propagates out of this block of code.
    -
    -
    -
    - -
    -

    5. Common definitions

    - -

    - This section specifies some common definitions that all - conforming implementations - MUST support. -

    - -
    -

    5.1. ArrayBufferView

    - -
    IDL
    typedef (Int8Array or Int16Array or Int32Array or
    -         Uint8Array or Uint16Array or Uint32Array or Uint8ClampedArray or
    -         Float32Array or Float64Array or DataView) ArrayBufferView;
    -

    - The ArrayBufferView typedef is used to represent - objects that provide a view on to an ArrayBuffer. -

    -
    - -
    -

    5.2. BufferSource

    - -
    IDL
    typedef (ArrayBufferView or ArrayBuffer) BufferSource;
    -

    - The BufferSource typedef is used to represent objects - that are either themselves an ArrayBuffer or which - provide a view on to an ArrayBuffer. -

    -
    - -
    -

    5.3. DOMTimeStamp

    - -
    IDL
    typedef unsigned long long DOMTimeStamp;
    -

    - The DOMTimeStamp type is used for representing - a number of milliseconds, either as an absolute time (relative to some epoch) - or as a relative amount of time. Specifications that use this type will need - to define how the number of milliseconds is to be interpreted. -

    -
    - -
    -

    5.4. Function

    - -
    IDL
    callback Function = any (any... arguments);
    -

    - The Function callback function - type is used for representing function values with no restriction on what arguments - are passed to it or what kind of value is returned from it. -

    -
    - -
    -

    5.5. VoidFunction

    - -
    IDL
    callback VoidFunction = void ();
    -

    - The VoidFunction callback function - type is used for representing function values that take no arguments and do not - return any value. -

    -
    -
    - -
    -

    6. Extensibility

    - -

    This section is informative.

    - -

    - Extensions to language binding requirements can be specified - using extended attributes - that do not conflict with those defined in this document. Extensions for - private, project-specific use should not be included in - IDL fragments - appearing in other specifications. It is recommended that extensions - that are required for use in other specifications be coordinated - with the group responsible for work on Web IDL, which - at the time of writing is the - W3C Web Platform Working Group, - for possible inclusion in a future version of this document. -

    -

    - Extensions to any other aspect of the IDL language are - strongly discouraged. -

    -
    - -
    -

    7. Referencing this specification

    - -

    This section is informative.

    - -

    - It is expected that other specifications that define Web platform interfaces - using one or more IDL fragments - will reference this specification. It is suggested - that those specifications include a sentence such as the following, - to indicate that the IDL is to be interpreted as described in this - specification: -

    -
    -

    - The IDL fragment in Appendix A of this specification must, in conjunction - with the IDL fragments defined in this specification's normative references, - be interpreted as required for conforming sets of IDL fragments, as described in the - “Web IDL” specification. [WEBIDL] -

    -
    -

    - In addition, it is suggested that the conformance class for user - agents in referencing specifications be linked to the - conforming - implementation class from this specification: -

    -
    -

    - A conforming FooML user agent must also be a - conforming implementation of the IDL fragment in Appendix A - of this specification, as described in the - “Web IDL” specification. [WEBIDL] -

    -
    -
    - -
    -

    8. Acknowledgements

    - -

    This section is informative.

    - -

    - The editor would like to thank the following people for contributing - to this specification: - Glenn Adams, - David Andersson, - L. David Baron, - Art Barstow, - Nils Barth, - Robin Berjon, - David Bruant, - Jan-Ivar Bruaroey, - Marcos Cáceres, - Giovanni Campagna, - Domenic Denicola, - Chris Dumez, - Michael Dyck, - Brendan Eich, - João Eiras, - Gorm Haug Eriksen, - Sigbjorn Finne, - David Flanagan, - Aryeh Gregor, - Dimitry Golubovsky, - James Graham, - Aryeh Gregor, - Kartikaya Gupta, - Marcin Hanclik, - Jed Hartman, - Stefan Haustein, - Dominique Hazaël-Massieux, - Ian Hickson, - Björn Höhrmann, - Kyle Huey, - Lachlan Hunt, - Oliver Hunt, - Jim Jewett, - Wolfgang Keller, - Anne van Kesteren, - Olav Junker Kjær, - Magnus Kristiansen, - Takeshi Kurosawa, - Yves Lafon, - Travis Leithead, - Jim Ley, - Kevin Lindsey, - Jens Lindström, - Peter Linss, - 呂康豪 (Kang-Hao Lu), - Kyle Machulis, - Mark Miller, - Ms2ger, - Andrew Oakley, - 岡坂 史紀 (Shiki Okasaka), - Jason Orendorff, - Olli Pettay, - Simon Pieters, - Andrei Popescu, - François Remy, - Tim Renouf, - Alex Russell, - Takashi Sakamoto, - Doug Schepers, - Jonas Sicking, - Garrett Smith, - Geoffrey Sneddon, - Jungkee Song, - Josh Soref, - Maciej Stachowiak, - Anton Tayanovskyy, - Peter Van der Beken, - Jeff Walden, - Allen Wirfs-Brock, - Jeffrey Yasskin and - Collin Xu. -

    -

    - Special thanks also go to Sam Weinig for maintaining this document - while the editor was unavailable to do so. -

    -
    -
    - -
    -
    -

    A. IDL grammar

    - -

    - This section defines an LL(1) grammar whose start symbol, - Definitions, matches an - entire IDL fragment. -

    - -

    - Each production in the grammar has on its right hand side either a - non-zero sequence of terminal and non-terminal symbols, or an - epsilon (ε) which indicates no symbols. Symbols that begin with - an uppercase letter are non-terminal symbols. Symbols within quotes - are terminal symbols that are matched with the exact text between - the quotes. Symbols that begin with a lowercase letter are terminal - symbols that are matched by the regular expressions (using Perl 5 regular - expression syntax [PERLRE]) as follows: -

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    integer=/-?([1-9][0-9]*|0[Xx][0-9A-Fa-f]+|0[0-7]*)/
    float=/-?(([0-9]+\.[0-9]*|[0-9]*\.[0-9]+)([Ee][+-]?[0-9]+)?|[0-9]+[Ee][+-]?[0-9]+)/
    identifier=/_?[A-Za-z][0-9A-Z_a-z-]*/
    string=/"[^"]*"/
    whitespace=/[\t\n\r ]+/
    comment=/\/\/.*|\/\*(.|\n)*?\*\//
    other=/[^\t\n\r 0-9A-Za-z]/
    - -

    - The tokenizer operates on a sequence of Unicode characters - [UNICODE]. - When tokenizing, the longest possible match MUST be used. For example, if the input - text is “a1”, it is tokenized as a single identifier, - and not as a separate identifier and integer. - If the longest possible match could match one of the above named terminal symbols or - one of the quoted terminal symbols from the grammar, it MUST be tokenized as the quoted - terminal symbol. Thus, the input text “long” is tokenized as the quoted terminal symbol - "long" rather than an identifier called “long”, - and “.” is tokenized as the quoted terminal symbol - "." rather than an other. -

    -

    - The IDL syntax is case sensitive, both for the quoted terminal symbols - used in the grammar and the values used for - identifier terminals. Thus, for - example, the input text “Const” is tokenized as - an identifier rather than the quoted - terminal symbol "const", an - interface with - identifier - “A” is distinct from one named “a”, and an - extended attribute - [constructor] will not be recognized as - the [Constructor] - extended attribute. -

    -

    - Implicitly, any number of whitespace and - comment terminals are allowed between every other terminal - in the input text being parsed. Such whitespace and - comment terminals are ignored while parsing. -

    - -

    - The following LL(1) grammar, starting with Definitions, - matches an IDL fragment: -

    - -
    [1]DefinitionsExtendedAttributeList Definition Definitions
     | - ε
    [2]DefinitionCallbackOrInterface
     | - Namespace
     | - Partial
     | - Dictionary
     | - Enum
     | - Typedef
     | - ImplementsStatement
    [3]CallbackOrInterface"callback" CallbackRestOrInterface
     | - Interface
    [4]CallbackRestOrInterfaceCallbackRest
     | - Interface
    [5]Interface"interface" identifier Inheritance "{" InterfaceMembers "}" ";"
    [6]Partial"partial" PartialDefinition
    [7]PartialDefinitionPartialInterface
     | - PartialDictionary
     | - Namespace
    [8]PartialInterface"interface" identifier "{" InterfaceMembers "}" ";"
    [9]InterfaceMembersExtendedAttributeList InterfaceMember InterfaceMembers
     | - ε
    [10]InterfaceMemberConst
     | - Operation
     | - Serializer
     | - Stringifier
     | - StaticMember
     | - Iterable
     | - ReadOnlyMember
     | - ReadWriteAttribute
     | - ReadWriteMaplike
     | - ReadWriteSetlike
    [11]Dictionary"dictionary" identifier Inheritance "{" DictionaryMembers "}" ";"
    [12]DictionaryMembersExtendedAttributeList DictionaryMember DictionaryMembers
     | - ε
    [13]DictionaryMemberRequired Type identifier Default ";"
    [14]Required"required"
     | - ε
    [15]PartialDictionary"dictionary" identifier "{" DictionaryMembers "}" ";"
    [16]Default"=" DefaultValue
     | - ε
    [17]DefaultValueConstValue
     | - string
     | - "[" "]"
    [18]Inheritance":" identifier
     | - ε
    [19]Enum"enum" identifier "{" EnumValueList "}" ";"
    [20]EnumValueListstring EnumValueListComma
    [21]EnumValueListComma"," EnumValueListString
     | - ε
    [22]EnumValueListStringstring EnumValueListComma
     | - ε
    [23]CallbackRestidentifier "=" ReturnType "(" ArgumentList ")" ";"
    [24]Typedef"typedef" Type identifier ";"
    [25]ImplementsStatementidentifier "implements" identifier ";"
    [26]Const"const" ConstType identifier "=" ConstValue ";"
    [27]ConstValueBooleanLiteral
     | - FloatLiteral
     | - integer
     | - "null"
    [28]BooleanLiteral"true"
     | - "false"
    [29]FloatLiteralfloat
     | - "-Infinity"
     | - "Infinity"
     | - "NaN"
    [30]Serializer"serializer" SerializerRest
    [31]SerializerRestOperationRest
     | - "=" SerializationPattern ";"
     | - ";"
    [32]SerializationPattern"{" SerializationPatternMap "}"
     | - "[" SerializationPatternList "]"
     | - identifier
    [33]SerializationPatternMap"getter"
     | - "inherit" Identifiers
     | - identifier Identifiers
     | - ε
    [34]SerializationPatternList"getter"
     | - identifier Identifiers
     | - ε
    [35]Stringifier"stringifier" StringifierRest
    [36]StringifierRestReadOnly AttributeRest
     | - ReturnType OperationRest
     | - ";"
    [37]StaticMember"static" StaticMemberRest
    [38]StaticMemberRestReadOnly AttributeRest
     | - ReturnType OperationRest
    [39]ReadOnlyMember"readonly" ReadOnlyMemberRest
    [40]ReadOnlyMemberRestAttributeRest
     | - ReadWriteMaplike
     | - ReadWriteSetlike
    [41]ReadWriteAttribute"inherit" ReadOnly AttributeRest
     | - AttributeRest
    [42]AttributeRest"attribute" Type AttributeName ";"
    [43]AttributeNameAttributeNameKeyword
     | - identifier
    [44]AttributeNameKeyword"required"
    [45]Inherit"inherit"
     | - ε
    [46]ReadOnly"readonly"
     | - ε
    [47]OperationReturnType OperationRest
     | - SpecialOperation
    [48]SpecialOperationSpecial Specials ReturnType OperationRest
    [49]SpecialsSpecial Specials
     | - ε
    [50]Special"getter"
     | - "setter"
     | - "deleter"
     | - "legacycaller"
    [51]OperationRestOptionalIdentifier "(" ArgumentList ")" ";"
    [52]OptionalIdentifieridentifier
     | - ε
    [53]ArgumentListArgument Arguments
     | - ε
    [54]Arguments"," Argument Arguments
     | - ε
    [55]ArgumentExtendedAttributeList OptionalOrRequiredArgument
    [56]OptionalOrRequiredArgument"optional" Type ArgumentName Default
     | - Type Ellipsis ArgumentName
    [57]ArgumentNameArgumentNameKeyword
     | - identifier
    [58]Ellipsis"..."
     | - ε
    [59]Iterable"iterable" "<" Type OptionalType ">" ";"
    [60]OptionalType"," Type
     | - ε
    [61]ReadWriteMaplikeMaplikeRest
    [62]ReadWriteSetlikeSetlikeRest
    [63]MaplikeRest"maplike" "<" Type "," Type ">" ";"
    [64]SetlikeRest"setlike" "<" Type ">" ";"
    [65]ExtendedAttributeList"[" ExtendedAttribute ExtendedAttributes "]"
     | - ε
    [66]ExtendedAttributes"," ExtendedAttribute ExtendedAttributes
     | - ε
    [67]ExtendedAttribute - "(" ExtendedAttributeInner ")" ExtendedAttributeRest -
     | - "[" ExtendedAttributeInner "]" ExtendedAttributeRest -
     | - "{" ExtendedAttributeInner "}" ExtendedAttributeRest -
     | - Other ExtendedAttributeRest -
    [68]ExtendedAttributeRestExtendedAttribute
     | - ε
    [69]ExtendedAttributeInner - "(" ExtendedAttributeInner ")" ExtendedAttributeInner -
     | - "[" ExtendedAttributeInner "]" ExtendedAttributeInner -
     | - "{" ExtendedAttributeInner "}" ExtendedAttributeInner -
     | - OtherOrComma ExtendedAttributeInner -
     | - ε -
    [70]Other - integer
     | - float
     | - identifier
     | - string
     | - other -
     | - "-"
     | - "-Infinity"
     | - "."
     | - "..."
     | - ":"
     | - ";"
     | - "<"
     | - "="
     | - ">"
     | - "?" -
     | - "ByteString"
     | - "DOMString"
     | - "FrozenArray"
     | - "Infinity"
     | - "NaN"
     | - "RegExp"
     | - "USVString"
     | - "any"
     | - "boolean"
     | - "byte"
     | - "double"
     | - "false"
     | - "float" -
     | - "long"
     | - "null"
     | - "object"
     | - "octet"
     | - "or"
     | - "optional"
     | - "sequence" -
     | - "short"
     | - "true"
     | - "unsigned"
     | - "void" -
     | - ArgumentNameKeyword -
     | - BufferRelatedType -
    [71]ArgumentNameKeyword - "attribute"
     | - "callback"
     | - "const"
     | - "deleter"
     | - "dictionary" -
     | - "enum"
     | - "getter"
     | - "implements"
     | - "inherit"
     | - "interface"
     | - "iterable" -
     | - "legacycaller"
     | - "maplike"
     | - "namespace"
     | - "partial"
     | - "required" -
     | - "serializer"
     | - "setlike"
     | - "setter"
     | - "static"
     | - "stringifier" -
     | - "typedef"
     | - "unrestricted" -
    [72]OtherOrCommaOther
     | - ","
    [73]TypeSingleType
     | - UnionType Null
    [74]SingleTypeNonAnyType
     | - "any"
    [75]UnionType"(" UnionMemberType "or" UnionMemberType UnionMemberTypes ")"
    [76]UnionMemberTypeNonAnyType
     | - UnionType Null
    [77]UnionMemberTypes"or" UnionMemberType UnionMemberTypes
     | - ε
    [78]NonAnyTypePrimitiveType Null
     | - PromiseType Null
     | - "ByteString" Null
     | - "DOMString" Null
     | - "USVString" Null
     | - identifier Null
     | - "sequence" "<" Type ">" Null
     | - "object" Null
     | - "RegExp" Null
     | - "Error" Null
     | - "DOMException" Null
     | - BufferRelatedType Null
     | - "FrozenArray" "<" Type ">" Null
    [79]BufferRelatedType"ArrayBuffer"
     | - "DataView"
     | - "Int8Array"
     | - "Int16Array"
     | - "Int32Array"
     | - "Uint8Array"
     | - "Uint16Array"
     | - "Uint32Array"
     | - "Uint8ClampedArray"
     | - "Float32Array"
     | - "Float64Array"
    [80]ConstTypePrimitiveType Null
     | - identifier Null
    [81]PrimitiveTypeUnsignedIntegerType
     | - UnrestrictedFloatType
     | - "boolean"
     | - "byte"
     | - "octet"
    [82]UnrestrictedFloatType"unrestricted" FloatType
     | - FloatType
    [83]FloatType"float"
     | - "double"
    [84]UnsignedIntegerType"unsigned" IntegerType
     | - IntegerType
    [85]IntegerType"short"
     | - "long" OptionalLong
    [86]OptionalLong"long"
     | - ε
    [87]PromiseType"Promise" "<" ReturnType ">"
    [88]Null"?"
     | - ε
    [89]ReturnTypeType
     | - "void"
    [90]IdentifierListidentifier Identifiers
    [91]Identifiers"," identifier Identifiers
     | - ε
    [92]ExtendedAttributeNoArgsidentifier
    [93]ExtendedAttributeArgListidentifier "(" ArgumentList ")"
    [94]ExtendedAttributeIdentidentifier "=" identifier
    [95]ExtendedAttributeIdentListidentifier "=" "(" IdentifierList ")"
    [96]ExtendedAttributeNamedArgListidentifier "=" identifier "(" ArgumentList ")"
    [97]Namespace"namespace" identifier "{" NamespaceMembers "}" ";"
    [98]NamespaceMembersExtendedAttributeList NamespaceMember NamespaceMembers
     | - ε
    [99]NamespaceMemberReturnType OperationRest
    -
    Note
    -

    - The Other - non-terminal matches any single terminal symbol except for - "(", ")", - "[", "]", - "{", "}" - and ",". -

    -
    -

    - While the ExtendedAttribute - non-terminal matches any non-empty sequence of terminal symbols (as long as any - parentheses, square brackets or braces are balanced, and the - "," token appears only within those balanced brackets), - only a subset of those - possible sequences are used by the extended attributes - defined in this specification — see - section 3.12 - for the syntaxes that are used by these extended attributes. -

    -
    - -
    -

    B. References

    - -
    -

    B.1. Normative references

    - -
    -
    [ECMA-262]
    -
    - ECMAScript Language Specification. - Ecma International. -
    Available at https://tc39.github.io/ecma262/.
    -
    -
    [IEEE-754]
    -
    - IEEE Standard for Binary Floating-Point Arithmetic (ANSI/IEEE Std 754-1985). - Institute of Electrical and Electronics Engineers, 1985. -
    -
    [PERLRE]
    -
    - Perl regular expressions (Perl 5.8.8). - The Perl Foundation, February 2006. -
    Available at http://www.perl.com/doc/manual/html/pod/perlre.html.
    -
    -
    [RFC2119]
    -
    - Key words for use in RFCs to Indicate Requirement Levels, - S. Bradner. IETF, March 1997. -
    Available at http://tools.ietf.org/html/rfc2119.
    -
    -
    [RFC2781]
    -
    - UTF-16, an encoding of ISO 10646, - P. Hoffmann and F. Yergeau. IETF, February 2000. -
    Available at http://tools.ietf.org/html/rfc2781.
    -
    -
    [RFC3629]
    -
    - UTF-8, a transformation format of ISO 10646, - F. Yergeau. IETF, November 2003. -
    Available at http://tools.ietf.org/html/rfc3629.
    -
    -
    [SECURE-CONTEXTS]
    -
    - Secure Contexts. - M. West and Y. Zhu, Editors. World Wide Web Consortium, October 2015. -
    Available at https://w3c.github.io/webappsec-secure-contexts/.
    -
    -
    [TYPEDARRAYS]
    -
    - Typed Array Specification, - V. Vukicevic and K. Russell, eds. The Khronos Group, 08 February 2011. -
    Available at https://www.khronos.org/registry/typedarray/specs/1.0/.
    -
    -
    [UNICODE]
    -
    - The Unicode Standard, - Version 6.0 or later. The Unicode Consortium. Mountain View, California, 2011. - ISBN 978-1-936213-01-6. -
    Available at http://www.unicode.org/versions/Unicode6.0.0/.
    -
    -
    -
    - -
    -

    B.2. Informative references

    - -
    -
    [DOM]
    -
    - DOM Standard. - A. van Kesteren, A. Gregor and Ms2ger, Editors. WHATWG, 22 July 2013. -
    Available at http://dom.spec.whatwg.org/.
    -
    -
    [DOM3CORE]
    -
    - Document Object Model (DOM) Level 3 Core Specification. - A. Le Hors, et al., Editors. World Wide Web Consortium, April 2004. -
    Available at http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/.
    -
    -
    [HTML5]
    -
    - HTML5. - I. Hickson, Editor. World Wide Web Consortium, May 2011. -
    Available at http://www.w3.org/TR/2011/WD-html5-20110525/.
    -
    -
    [OMGIDL]
    -
    - CORBA 3.1 – OMG IDL Syntax and Semantics chapter. - Object Management Group, January 2008. -
    Available at http://www.omg.org/cgi-bin/doc?formal/08-01-04.pdf.
    -
    -
    [WEBIDL-JAVA]
    -
    - Java langage binding for Web IDL. - World Wide Consortium, work in progress. -
    Available at http://dev.w3.org/2006/webapi/WebIDL/java.html.
    -
    -
    [XMLNS]
    -
    - Namespaces in XML 1.0 (Third Edition), - T. Bray, D. Hollander, A. Layman, R. Tobin, H. Thompson, eds. - World Wide Web Consortium, 8 December 2009. -
    Available at http://www.w3.org/TR/2009/REC-xml-names-20091208/.
    -
    -
    -
    -
    - - - -
    -

    C. Changes

    - -

    This section is informative.

    - -

    - The following is a list of substantial changes to the document on each publication. - For the list of changes during the development of the First Edition of this - specification, see - that document's - Changes appendix. -

    -
    -
    Current editor’s draft
    -
    -
      -
    • -

      - Fixed unions containing a sequence and a dictionary to try the - sequence first when given an object, just like overload - resolution does. -

      -
    • -
    • -

      - Removed support for [Constructor] on dictionaries. -

      -
    • -
    • -

      - Added the [LenientSetter] extended attribute. -

      -
    • -
    • -

      - Added the [SecureContext] extended attribute. -

      -
    • -
    • -

      - Changed from [Unscopeable] to - [Unscopable] to match ES6 better. -

      -
    • -
    • -

      - Removed the term "unenumerable" and its associated prose and replaced it by the - extended attribute [LegacyUnenumerableNamedProperties]. -

      -
    • -
    • -

      - Allowed object internal methods to be overridden by other specifications. -

      -
    • -
    • -

      - Added some more parameters to the “perform a security check” hook. -

      -
    • -
    • -

      - Defined the “name” property for all Function - objects (including those for operations and attribute getters and setters). -

      -
    • -
    • -

      - Removed the Date type. -

      -
    • -
    • -

      - Disallowed “length” and “name” from being used as identifiers of - constants. -

      -
    • -
    • -

      - Added a FrozenArray<T> type. -

      -
    • -
    • -

      - Renamed [ArrayClass] to [LegacyArrayClass]. -

      -
    • -
    • -

      - Removed T[] array types. -

      -
    • -
    • -

      - Allowed [NewObject] to be used on things with - a promise type. -

      -
    • -
    • -

      - Fix various cases in which maplike/setlike were operating on the wrong objects. -

      -

      - Disallow maplike, setlike and iterable declarations from appearing more than - once on an interface and its inherited and consequential interfaces. - Also disallow the relevant restricted member names (such as “entries” and “values”) - on the inherited and consequential interfaces. -

      -
    • -
    • -

      - Allowed stringifier attributes to have type USVString. -

      -
    • -
    • -

      - Gave interface objects, named constructors, and dictionary - constructors a "name" property to match ES6. -

      -
    • -
    • -

      - Made the "length" property on dictionary constructors - configurable. -

      -
    • -
    • -

      - Added types for ArrayBuffer, DataView - and typed array objects. -

      -
    • -
    • -

      - Added USVString and allowed string literals in IDL to - be used to give values for all string-typed optional argument and dictionary - member default values. -

      -
    • -
    • -

      - Made sequences distinguishable from dictionaries, callback - functions, and all interface types. -

      -
    • -
    • -

      - Removed IDL exceptions, baked in DOMException, - and added Error and DOMException - as types. -

      -
    • -
    • -

      - Removed [MapLike] and added - iterable, maplike and setlike declarations. -

      -
    • -
    • -

      - Removed the custom Object.prototype.toString definition and instead - defined class strings to influence the @@toStringTag property - on objects. -

      -
    • -
    • -

      - Added the [Unscopeable] extended attribute. -

      -
    • -
    • -

      - Rewrote ES to IDL sequence conversion so that any iterable is - convertible to a sequence. -

      -
    • -
    • -

      - Added grammar production for Promise<T> types - and allowed T to be void. -

      -
    • -
    • -

      - Added a definition to "initialize an object from an iterable", - which behaves like the Map constructor. -

      -
    • -
    • -

      - Added a default value [] that can be used for - sequence-typed operation argument default values and - dictionary member default values. -

      -
    • -
    • -

      - Added promise types. -

      -
    • -
    • -

      - Added the [NewObject] and - [SameObject] extended attributes. -

      -
    • -
    • -

      - Allowed [Constructor] to be specified - on dictionaries. -

      -
    • -
    • -

      - Added a RegExp type. -

      -
    • -
    • -

      - Added iterators that can be declared on interfaces. -

      -
    • -
    • -

      - Added an @@iterator method to objects with indexed - properties. -

      -
    • -
    • -

      - Updated to ECMAScript 6th Edition. -

      -
    • -
    • -

      - Added serializers. -

      -
    • -
    • -

      - Added a ByteString type, for representing - 8 bit strings without a particular encoding as ECMAScript - String values. -

      -
    • -
    • -

      - Added static attributes. -

      -
    • - -
    • -

      - Make it clear that an interface can't be exposed in a global - where its parent interface is not exposed. -

      -
    • -
    • -

      - Allow dictionary-typed trailing-position operation arguments not to - be optional, if and only if the dictionary type has a required - dictionary member. -

      -
    • -
    • -

      - Added a platform object [[Set]] internal method to handle - named and indexed setters better. -

      -
    • -
    • -

      - Removed the concept of creators; setters are always also - creators. -

      -
    • -
    • -

      - Disallowed an interface without [NoInterfaceObject] - inheriting from a [NoInterfaceObject] interface. -

      -
    • -
    • -

      - Removed indexed deleters. -

      -
    • -
    • -

      - Made the prototype of an interface object of a non-root - interface be the interface object of its ancestor interface. -

      -
    • -
    • -

      - Clarified the property attributes of the "prototype" property - of non-callback interface objects. -

      -
    • -
    • -

      - Made the "length" property on interface objects and named - constructors configurable. -

      -
    • -
    • -

      - Added a way to mark dictionary members as required. -

      -
    • -
    • -

      - Allowed hyphens in identifiers after the first character. -

      -
    • -
    • -

      - Fix [Exposed] text to make it - clear that the value on the interface, if any, is used as the - value for its members by default. -

      -
    • -
    • -

      - Fixed the grammar for extended attributes that take an identifier list, - such as [Exposed]. -

      -
    • -
    • -

      - Add a term "unenumerable" to allow named properties to be exposed as - properties with [[Enumerable]] set to false. -

      -
    • -
    • -

      - Added the [Exposed] and - [PrimaryGlobal] extended attributes and - allowed an identifier to be used with [Global]. -

      -
    • -
    • -

      - Removed [TreatUndefinedAs]. -

      -
    • -
    • -

      - Renamed [TreatNonCallableAsNull] to [TreatNonObjectAsNull] - and changed its semantics to allow any object. Changed - callback function invocation to be a no-op when the object is - not callable, which can now happen in the - [TreatNonObjectAsNull] case. -

      -
    • -
    • -

      - Changed the default this value for callbacks from null to undefined. -

      -
    • -
    • -

      - Removed the requirement for named properties objects to be function objects. -

      -
    • -
    • -

      - Disallowed properties from being defined on a named properties object. -

      -
    • -
    • -

      - Fixed infinite loop in named property visibility algorithm. -

      -
    • -
    • -

      - Made stringifiers and serializers not use [[Get]] or [[Call]] - for the their attribute or operation delegated behavior. -

      -
    • -
    • -

      - Allowed trailing optional comma in enum lists. -

      -
    • -
    • -

      - Disallowed static interface members from being defined on a callback interface. -

      -
    • -
    • -

      - Added a hook to do a security check when invoking an operation - or accessing an attribute. -

      -
    • -
    • -

      - Defined how callbacks influence the incumbent script. -

      -
    • -
    • -

      - Changed how callback functions are invoked to support missing - optional arguments. -

      -
    • -
    • -

      - Renamed [NamedPropertiesObject] to - [Global], which now also causes - properties for interface members to appear on the object - itself rather than on the interface prototype object. -

      -
    • -
    • -

      - Split out boolean from the other - primitive types. Made boolean, - numeric types and DOMString distinguishable. -

      -
    • -
    • -

      - Required a getter to be present on an interface if it has a - setter, creator or delete. -

      -
    • -
    • -

      - Extended [Unforgeable] to apply to operations - and interfaces. -

      -
    • -
    • -

      - Allowed all operation arguments to be specified as being optional and - changed back to the behavior of undefined - being treated as a missing optional argument value. Modified the - effective overload set and overload resolution algorithms to - take this into account, as well as allowing an undefined - value passed as the argument value at the distinguishing index to select the overload - with an optional argument at that index. - Also removed [TreatUndefinedAs=Missing]. -

      -
    • -
    • -

      - Changed the ECMAScript to IDL dictionary conversion algorithm - to treat a property with the value undefined - as missing. -

      -
    • -
    • -

      - Removed the ability to put extended attributes after the - typedef keyword, as that feature is unused. -

      -
    • -
    • -

      - Fixed the long long and unsigned long long - conversion algorithms to correctly identify the range of contiguous, - exactly, uniquely representable integers you can get from a Number. -

      -
    • -
    • -

      - Clarified that Function objects for - operations and attribute getters and setters are distinct on each - interface they are mixed in to using an implements statement, - and that each copy of the Function works - only on objects that implement the interface whose interface - prototype object the Function object - is on. -

      -
    • -
    • -

      - Mention the named properties object in the list of initial objects. -

      -
    • -
    • -

      - Added back a custom [[HasInstance]] on interface objects to allow objects - from other windows to be considered instanceof them. -

      -
    • -
    • -

      - Fixed conversion of Number values - to any by using the - conversion algorithm for unrestricted double. -

      -
    • -
    • -

      - Allowed an identifier to be “prototype” for any construct except - constants and static operations. -

      -
    • -
    • -

      - Fixed a bug in the user object definition where the internal [[Call]] - method would be treated as the implementation of an operation even if - the callback interface had more than one operation. -

      -
    • -
    • -

      - Further tweaked the overload resolution algorithm and union type conversion - algorithm for consistency. -

      -
    • -
    • -

      - Lifted the restriction on [Unforgeable] appearing - on an IDL attribute if another interface inherits from the one the attribute - is declared on, but required that the inheriting interface not have an - attribute with the same identifier. -

      -
    • -
    • -

      - Made attribute setters throw if no argument was passed to them, instead of - assuming undefined. -

      -
    • -
    • -

      - Prevented dictionaries from referencing themselves. -

      -
    • -
    • -

      - Made sequences, arrays and dictionaries undistingishable again, thereby allowing - non-Array ECMAScript objects to be converted - to sequence and array types. -

      -
    • -
    • -

      - Added a requirement to state what the values of an exception’s fields are - when throwing it. -

      -
    • -
    • -

      - Changed the “length” property on Function - objects for IDL operations to return the smallest number of required arguments. -

      -
    • -
    • -

      - Clarified that dictionaries may not be nullable when used as - the type of an operation argument or dictionary member. -

      -
    • -
    • -

      - Specify the value of the “length” property on interface objects - that do not have constructors. -

      -
    • -
    • -

      - Do not treat array index properties as named properties if an object supports - both indexed and named properties. -

      -
    • -
    • -

      - Require that dictionary type arguments followed by optional arguments - must also be optional, and that such optional arguments always are - assumed to have a default value of an empty dictionary. Also disallow - dictionary types from being used inside nullable types and from being - considered distinguishable from nullable types. -

      -
    • -
    • -

      - Always consider dictionary members with default values as present. -

      -
    • -
    • -

      - Tweak [Clamp] algorithms for clarity. -

      -
    • -
    • -

      - Require exception objects to have [[Class]] “Error” and suggest that they - have any non-standard properties that native Error objects do. -

      -
    • -
    • -

      - Fixed a bug in the whitespace token regular expression. -

      -
    • -
    • -

      - Explicitly disallow dictionaries from being used inside union types - as the type of an attribute or exception field. -

      -
    • -
    • -

      - Fixed a bug in the definition of distinguishability where a nullable - union type and a non-nullable union type that has a nullable member type - were considered distinguishable. -

      -
    • -
    • -

      - Disallowed callback interfaces from being used in implements statements. -

      -
    • -
    • -

      - Renamed “exception types” to “exception names”. -

      -
    • -
    • -

      - Disallowed non-callback interfaces from inheriting from callback interfaces. -

      -
    • -
    • -

      - Changed the algorithm for conversion from a platform object with indexed - properties to a sequence type to use its internal knowledge of the - set of property indexes rather than getting the "length" property, which - may not even exist. -

      -
    • -
    • -

      - Added a warning to prefer the use of double - to float, unless there are good - reasons to choose the 32 bit type. -

      -
    • -
    • -

      - Changed the restriction on operation argument default values - so that all optional arguments to the left of one with a - default value must also have default values. (Previously, - this was to the right.) -

      -
    • -
    -
    -
    -
    -
    - - + +

    If we pass a MathUtils object from + a different global environment to doComputation, then the exception + thrown will be from that global environment:

    +
    var a = getA();                           // An A object from this global environment.
    +var m = otherWindow.getMathUtils();       // A MathUtils object from a different global environment.
    +        
    +a instanceof Object;                      // Evaluates to true.
    +m instanceof Object;                      // Evaluates to false.
    +m instanceof otherWindow.Object;          // Evaluates to true.
    +        
    +try {
    +  a.doComputation(m, -1);
    +} catch (e) {
    +  e instanceof DOMException;              // Evaluates to false.
    +  e instanceof otherWindow.DOMException;  // Evaluates to true.
    +}
    + +

    Any requirements in this document to throw an instance of an ECMAScript built-in Error must use +the built-in from the current global environment.

    +

    4.15. Handling exceptions

    +

    None of the algorithms or processing requirements in the +ECMAScript language binding catch ECMAScript exceptions. Whenever +an ECMAScript Function is invoked due +to requirements in this section and that Function ends due to an exception being thrown, that exception +must propagate to the caller, and if +not caught there, to its caller, and so on.

    +
    + +

    The following IDL fragment defines two interfaces and an exception. + The valueOf attribute on ExceptionThrower is defined to throw an exception whenever an attempt is made + to get its value.

    +
    interface Dahut {
    +  attribute DOMString type;
    +};
    +        
    +interface ExceptionThrower {
    +  // This attribute always throws a NotSupportedError and never returns a value.
    +  attribute long valueOf;
    +};
    +
    +

    Assuming an ECMAScript implementation supporting this interface, + the following code demonstrates how exceptions are handled:

    +
    var d = getDahut();              // Obtain an instance of Dahut.
    +var et = getExceptionThrower();  // Obtain an instance of ExceptionThrower.
    +        
    +try {
    +  d.type = { toString: function() { throw "abc"; } };
    +} catch (e) {
    +  // The string "abc" is caught here, since as part of the conversion
    +  // from the native object to a string, the anonymous function
    +  // was invoked, and none of the [[DefaultValue]], ToPrimitive or
    +  // ToString algorithms are defined to catch the exception.
    +}
    +        
    +try {
    +  d.type = { toString: { } };
    +} catch (e) {
    +  // An exception is caught here, since an attempt is made to invoke
    +  // [[Call]] on the native object that is the value of toString
    +  // property.
    +}
    +        
    +d.type = et;
    +// An uncaught NotSupportedError DOMException is thrown here, since the
    +// [[DefaultValue]] algorithm attempts to get the value of the
    +// "valueOf" property on the ExceptionThrower object.  The exception
    +// propagates out of this block of code.
    +
    +

    5. Common definitions

    +

    This section specifies some common definitions that all conforming implementations must support.

    +

    5.1. ArrayBufferView

    +
    typedef (Int8Array or Int16Array or Int32Array or
    +         Uint8Array or Uint16Array or Uint32Array or Uint8ClampedArray or
    +         Float32Array or Float64Array or DataView) ArrayBufferView;
    +
    +

    The ArrayBufferView typedef is used to represent +objects that provide a view on to an ArrayBuffer.

    +

    5.2. BufferSource

    +
    typedef (ArrayBufferView or ArrayBuffer) BufferSource;
    +

    The BufferSource typedef is used to represent objects +that are either themselves an ArrayBuffer or which +provide a view on to an ArrayBuffer.

    +

    5.3. DOMTimeStamp

    +
    typedef unsigned long long DOMTimeStamp;
    +

    The DOMTimeStamp type is used for representing +a number of milliseconds, either as an absolute time (relative to some epoch) +or as a relative amount of time. Specifications that use this type will need +to define how the number of milliseconds is to be interpreted.

    +

    5.4. Function

    +
    callback Function = any (any... arguments);
    +

    The Function callback function type is used for representing function values with no restriction on what arguments +are passed to it or what kind of value is returned from it.

    +

    5.5. VoidFunction

    +
    callback VoidFunction = void ();
    +

    The VoidFunction callback function type is used for representing function values that take no arguments and do not +return any value.

    +

    6. Extensibility

    +

    This section is informative.

    +

    Extensions to language binding requirements can be specified +using extended attributes that do not conflict with those defined in this document. Extensions for +private, project-specific use should not be included in IDL fragments appearing in other specifications. It is recommended that extensions +that are required for use in other specifications be coordinated +with the group responsible for work on Web IDL, which +at the time of writing is the W3C Web Platform Working Group, +for possible inclusion in a future version of this document.

    +

    Extensions to any other aspect of the IDL language are +strongly discouraged.

    +

    7. Referencing this specification

    +

    This section is informative.

    +

    It is expected that other specifications that define Web platform interfaces +using one or more IDL fragments will reference this specification. It is suggested +that those specifications include a sentence such as the following, +to indicate that the IDL is to be interpreted as described in this +specification:

    +
    +

    The IDL fragment in Appendix A of this specification must, in conjunction + with the IDL fragments defined in this specification’s normative references, + be interpreted as required for conforming sets of IDL fragments, as described in the + “Web IDL” specification. [WEBIDL]

    +
    +

    In addition, it is suggested that the conformance class for user +agents in referencing specifications be linked to the conforming implementation class from this specification:

    +
    +

    A conforming FooML user agent must also be a conforming implementation of the IDL fragment in Appendix A + of this specification, as described in the + “Web IDL” specification. [WEBIDL]

    +
    +

    8. Acknowledgements

    +

    This section is informative.

    +

    The editor would like to thank the following people for contributing +to this specification: +Glenn Adams, +David Andersson, +L. David Baron, +Art Barstow, +Nils Barth, +Robin Berjon, +David Bruant, +Jan-Ivar Bruaroey, +Marcos Cáceres, +Giovanni Campagna, +Domenic Denicola, +Chris Dumez, +Michael Dyck, +Brendan Eich, +João Eiras, +Gorm Haug Eriksen, +Sigbjorn Finne, +David Flanagan, +Aryeh Gregor, +Dimitry Golubovsky, +James Graham, +Aryeh Gregor, +Kartikaya Gupta, +Marcin Hanclik, +Jed Hartman, +Stefan Haustein, +Dominique Hazaël-Massieux, +Ian Hickson, +Björn Höhrmann, +Kyle Huey, +Lachlan Hunt, +Oliver Hunt, +Jim Jewett, +Wolfgang Keller, +Anne van Kesteren, +Olav Junker Kjær, +Magnus Kristiansen, +Takeshi Kurosawa, +Yves Lafon, +Travis Leithead, +Jim Ley, +Kevin Lindsey, +Jens Lindström, +Peter Linss, +呂康豪 (Kang-Hao Lu), +Kyle Machulis, +Mark Miller, +Ms2ger, +Andrew Oakley, +岡坂 史紀 (Shiki Okasaka), +Jason Orendorff, +Olli Pettay, +Simon Pieters, +Andrei Popescu, +François Remy, +Tim Renouf, +Alex Russell, +Takashi Sakamoto, +Doug Schepers, +Jonas Sicking, +Garrett Smith, +Geoffrey Sneddon, +Jungkee Song, +Josh Soref, +Maciej Stachowiak, +Anton Tayanovskyy, +Peter Van der Beken, +Jeff Walden, +Allen Wirfs-Brock, +Jeffrey Yasskin and +Collin Xu.

    +

    Special thanks also go to Sam Weinig for maintaining this document +while the editor was unavailable to do so.

    +

    IDL grammar

    +

    This section defines an LL(1) grammar whose start symbol, Definitions, matches an +entire IDL fragment.

    +

    Each production in the grammar has on its right hand side either a +non-zero sequence of terminal and non-terminal symbols, or an +epsilon (ε) which indicates no symbols. +Symbols that begin with an uppercase letter are non-terminal symbols. +Symbols in monospaced fonts are terminal symbols. +Symbols in sans-serif font that begin with a lowercase letter are terminal +symbols that are matched by the regular expressions (using Perl 5 regular +expression syntax [PERLRE]) as follows:

    + + + + + + + + + +
    integer + = + /-?([1-9][0-9]*|0[Xx][0-9A-Fa-f]+|0[0-7]*)/ +
    float + = + /-?(([0-9]+\.[0-9]*|[0-9]*\.[0-9]+)([Ee][+-]?[0-9]+)?|[0-9]+[Ee][+-]?[0-9]+)/ +
    identifier + = + /_?[A-Za-z][0-9A-Z_a-z-]*/ +
    string + = + /"[^"]*"/ +
    whitespace + = + /[\t\n\r ]+/ +
    comment + = + /\/\/.*|\/\*(.|\n)*?\*\// +
    other + = + /[^\t\n\r 0-9A-Za-z]/ +
    +

    The tokenizer operates on a sequence of Unicode characters [UNICODE]. +When tokenizing, the longest possible match must be used. For example, if the input +text is “a1”, it is tokenized as a single identifier, +and not as a separate identifier and integer. +If the longest possible match could match one of the above named terminal symbols or +one of the other terminal symbols from the grammar, it must be tokenized as the latter. +Thus, the input text “long” is tokenized as the quoted terminal symbol long rather than an identifier called “long”, +and “.” is tokenized as the quoted terminal symbol . rather than an other.

    +

    The IDL syntax is case sensitive, both for the quoted terminal symbols +used in the grammar and the values used for identifier terminals. Thus, for +example, the input text “Const” is tokenized as +an identifier rather than the +terminal symbol const, an interface with identifier “A” is distinct from one named “a”, and an extended attribute [constructor] will not be recognized as +the [Constructor] +extended attribute.

    +

    Implicitly, any number of whitespace and comment terminals are allowed between every other terminal +in the input text being parsed. Such whitespace and comment terminals are ignored while parsing.

    +

    The following LL(1) grammar, starting with Definitions, +matches an IDL fragment:

    +
    +

    Note: The Other non-terminal matches any single terminal symbol except for (, ), [, ], {, } and ,.

    +

    While the ExtendedAttribute non-terminal matches any non-empty sequence of terminal symbols (as long as any +parentheses, square brackets or braces are balanced, and the , token appears only within those balanced brackets), +only a subset of those +possible sequences are used by the extended attributes defined in this specification — see §3.12 Extended attributes for the syntaxes that are used by these extended attributes.

    +

    Changes

    +

    This section is informative.

    +

    The following is a list of substantial changes to the document on each publication. +For the list of changes during the development of the First Edition of this +specification, see that document’s +Changes appendix.

    +
      +
    • +

      Fixed unions containing a sequence and a dictionary to try the +sequence first when given an object, just like overload +resolution does.

      +
    • +

      Removed support for [Constructor] on dictionaries.

      +
    • +

      Added the [LenientSetter] extended attribute.

      +
    • +

      Added the [SecureContext] extended attribute.

      +
    • +

      Changed from [Unscopeable] to +[Unscopable] to match ES6 better.

      +
    • +

      Removed the term "unenumerable" and its associated prose and replaced it by the +extended attribute [LegacyUnenumerableNamedProperties].

      +
    • +

      Allowed object internal methods to be overridden by other specifications.

      +
    • +

      Added some more parameters to the “perform a security check” hook.

      +
    • +

      Defined the “name” property for all Function objects (including those for operations and attribute getters and setters).

      +
    • +

      Removed the Date type.

      +
    • +

      Disallowed “length” and “name” from being used as identifiers of +constants.

      +
    • +

      Added a FrozenArray<T> type.

      +
    • +

      Renamed [ArrayClass] to [LegacyArrayClass].

      +
    • +

      Removed T[] array types.

      +
    • +

      Allowed [NewObject] to be used on things with +a promise type.

      +
    • +

      Fix various cases in which maplike/setlike were operating on the wrong objects.

      +

      Disallow maplike, setlike and iterable declarations from appearing more than +once on an interface and its inherited and consequential interfaces. +Also disallow the relevant restricted member names (such as “entries” and “values”) +on the inherited and consequential interfaces.

      +
    • +

      Allowed stringifier attributes to have type USVString.

      +
    • +

      Gave interface objects, named constructors, and dictionary +constructors a "name" property to match ES6.

      +
    • +

      Made the "length" property on dictionary constructors +configurable.

      +
    • +

      Added types for ArrayBuffer, DataView and typed array objects.

      +
    • +

      Added USVString and allowed string literals in IDL to +be used to give values for all string-typed optional argument and dictionary +member default values.

      +
    • +

      Made sequences distinguishable from dictionaries, callback +functions, and all interface types.

      +
    • +

      Removed IDL exceptions, baked in DOMException, +and added Error and DOMException as types.

      +
    • +

      Removed [MapLike] and added +iterable, maplike and setlike declarations.

      +
    • +

      Removed the custom Object.prototype.toString definition and instead +defined class strings to influence the @@toStringTag property +on objects.

      +
    • +

      Added the [Unscopeable] extended attribute.

      +
    • +

      Rewrote ES to IDL sequence conversion so that any iterable is +convertible to a sequence.

      +
    • +

      Added grammar production for Promise<T> types +and allowed T to be void.

      +
    • +

      Added a definition to "initialize an object from an iterable", +which behaves like the Map constructor.

      +
    • +

      Added a default value [] that can be used for +sequence-typed operation argument default values and +dictionary member default values.

      +
    • +

      Added promise types.

      +
    • +

      Added the [NewObject] and +[SameObject] extended attributes.

      +
    • +

      Allowed [Constructor] to be specified +on dictionaries.

      +
    • +

      Added a RegExp type.

      +
    • +

      Added iterators that can be declared on interfaces.

      +
    • +

      Added an @@iterator method to objects with indexed +properties.

      +
    • +

      Updated to ECMAScript 6th Edition.

      +
    • +

      Added serializers.

      +
    • +

      Added a ByteString type, for representing +8 bit strings without a particular encoding as ECMAScript String values.

      +
    • +

      Added static attributes.

      +
    • +

      Make it clear that an interface can’t be exposed in a global +where its parent interface is not exposed.

      +
    • +

      Allow dictionary-typed trailing-position operation arguments not to +be optional, if and only if the dictionary type has a required +dictionary member.

      +
    • +

      Added a platform object [[Set]] internal method to handle +named and indexed setters better.

      +
    • +

      Removed the concept of creators; setters are always also +creators.

      +
    • +

      Disallowed an interface without [NoInterfaceObject] +inheriting from a [NoInterfaceObject] interface.

      +
    • +

      Removed indexed deleters.

      +
    • +

      Made the prototype of an interface object of a non-root +interface be the interface object of its ancestor interface.

      +
    • +

      Clarified the property attributes of the "prototype" property +of non-callback interface objects.

      +
    • +

      Made the "length" property on interface objects and named +constructors configurable.

      +
    • +

      Added a way to mark dictionary members as required.

      +
    • +

      Allowed hyphens in identifiers after the first character.

      +
    • +

      Fix [Exposed] text to make it +clear that the value on the interface, if any, is used as the +value for its members by default.

      +
    • +

      Fixed the grammar for extended attributes that take an identifier list, +such as [Exposed].

      +
    • +

      Add a term "unenumerable" to allow named properties to be exposed as +properties with [[Enumerable]] set to false.

      +
    • +

      Added the [Exposed] and +[PrimaryGlobal] extended attributes and +allowed an identifier to be used with [Global].

      +
    • +

      Removed [TreatUndefinedAs].

      +
    • +

      Renamed [TreatNonCallableAsNull] to [TreatNonObjectAsNull] +and changed its semantics to allow any object. Changed +callback function invocation to be a no-op when the object is +not callable, which can now happen in the +[TreatNonObjectAsNull] case.

      +
    • +

      Changed the default this value for callbacks from null to undefined.

      +
    • +

      Removed the requirement for named properties objects to be function objects.

      +
    • +

      Disallowed properties from being defined on a named properties object.

      +
    • +

      Fixed infinite loop in named property visibility algorithm.

      +
    • +

      Made stringifiers and serializers not use [[Get]] or [[Call]] +for the their attribute or operation delegated behavior.

      +
    • +

      Allowed trailing optional comma in enum lists.

      +
    • +

      Disallowed static interface members from being defined on a callback interface.

      +
    • +

      Added a hook to do a security check when invoking an operation +or accessing an attribute.

      +
    • +

      Defined how callbacks influence the incumbent script.

      +
    • +

      Changed how callback functions are invoked to support missing +optional arguments.

      +
    • +

      Renamed [NamedPropertiesObject] to +[Global], which now also causes +properties for interface members to appear on the object +itself rather than on the interface prototype object.

      +
    • +

      Split out boolean from the other +primitive types. Made boolean, +numeric types and DOMString distinguishable.

      +
    • +

      Required a getter to be present on an interface if it has a +setter, creator or delete.

      +
    • +

      Extended [Unforgeable] to apply to operations +and interfaces.

      +
    • +

      Allowed all operation arguments to be specified as being optional and +changed back to the behavior of undefined being treated as a missing optional argument value. Modified the +effective overload set and overload resolution algorithms to +take this into account, as well as allowing an undefined value passed as the argument value at the distinguishing index to select the overload +with an optional argument at that index. +Also removed [TreatUndefinedAs=Missing].

      +
    • +

      Changed the ECMAScript to IDL dictionary conversion algorithm +to treat a property with the value undefined as missing.

      +
    • +

      Removed the ability to put extended attributes after the typedef keyword, as that feature is unused.

      +
    • +

      Fixed the long long and unsigned long long conversion algorithms to correctly identify the range of contiguous, +exactly, uniquely representable integers you can get from a Number.

      +
    • +

      Clarified that Function objects for +operations and attribute getters and setters are distinct on each +interface they are mixed in to using an implements statement, +and that each copy of the Function works +only on objects that implement the interface whose interface +prototype object the Function object +is on.

      +
    • +

      Mention the named properties object in the list of initial objects.

      +
    • +

      Added back a custom [[HasInstance]] on interface objects to allow objects +from other windows to be considered instanceof them.

      +
    • +

      Fixed conversion of Number values +to any by using the +conversion algorithm for unrestricted double.

      +
    • +

      Allowed an identifier to be “prototype” for any construct except +constants and static operations.

      +
    • +

      Fixed a bug in the user object definition where the internal [[Call]] +method would be treated as the implementation of an operation even if +the callback interface had more than one operation.

      +
    • +

      Further tweaked the overload resolution algorithm and union type conversion +algorithm for consistency.

      +
    • +

      Lifted the restriction on [Unforgeable] appearing +on an IDL attribute if another interface inherits from the one the attribute +is declared on, but required that the inheriting interface not have an +attribute with the same identifier.

      +
    • +

      Made attribute setters throw if no argument was passed to them, instead of +assuming undefined.

      +
    • +

      Prevented dictionaries from referencing themselves.

      +
    • +

      Made sequences, arrays and dictionaries undistingishable again, thereby allowing +non-Array ECMAScript objects to be converted +to sequence and array types.

      +
    • +

      Added a requirement to state what the values of an exception’s fields are +when throwing it.

      +
    • +

      Changed the “length” property on Function objects for IDL operations to return the smallest number of required arguments.

      +
    • +

      Clarified that dictionaries may not be nullable when used as +the type of an operation argument or dictionary member.

      +
    • +

      Specify the value of the “length” property on interface objects +that do not have constructors.

      +
    • +

      Do not treat array index properties as named properties if an object supports +both indexed and named properties.

      +
    • +

      Require that dictionary type arguments followed by optional arguments +must also be optional, and that such optional arguments always are +assumed to have a default value of an empty dictionary. Also disallow +dictionary types from being used inside nullable types and from being +considered distinguishable from nullable types.

      +
    • +

      Always consider dictionary members with default values as present.

      +
    • +

      Tweak [Clamp] algorithms for clarity.

      +
    • +

      Require exception objects to have [[Class]] “Error” and suggest that they +have any non-standard properties that native Error objects do.

      +
    • +

      Fixed a bug in the whitespace token regular expression.

      +
    • +

      Explicitly disallow dictionaries from being used inside union types +as the type of an attribute or exception field.

      +
    • +

      Fixed a bug in the definition of distinguishability where a nullable +union type and a non-nullable union type that has a nullable member type +were considered distinguishable.

      +
    • +

      Disallowed callback interfaces from being used in implements statements.

      +
    • +

      Renamed “exception types” to “exception names”.

      +
    • +

      Disallowed non-callback interfaces from inheriting from callback interfaces.

      +
    • +

      Changed the algorithm for conversion from a platform object with indexed +properties to a sequence type to use its internal knowledge of the +set of property indexes rather than getting the "length" property, which +may not even exist.

      +
    • +

      Added a warning to prefer the use of double to float, unless there are good +reasons to choose the 32 bit type.

      +
    • +

      Changed the restriction on operation argument default values +so that all optional arguments to the left of one with a +default value must also have default values. (Previously, +this was to the right.)

      + +
    +
    + +

    Index

    +

    Terms defined by this specification

    + +

    Terms defined by reference

    + +

    References

    +

    Normative References

    +
    +
    [ECMA-262] +
    ECMAScript Language Specification. URL: https://tc39.github.io/ecma262/ +
    [HTML] +
    Ian Hickson. HTML Standard. Living Standard. URL: https://html.spec.whatwg.org/multipage/ +
    [IEEE-754] +
    IEEE Standard for Binary Floating-Point Arithmetic (ANSI/IEEE Std 754-1985). 29 August 2008. URL: http://ieeexplore.ieee.org/servlet/opac?punumber=4610933 +
    [PERLRE] +
    Perl regular expressions (Perl 5.8.8). February 2006. URL: http://search.cpan.org/dist/perl/pod/perlre.pod +
    [RFC2119] +
    S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119 +
    [RFC2781] +
    P. Hoffman; F. Yergeau. UTF-16, an encoding of ISO 10646. February 2000. Informational. URL: https://tools.ietf.org/html/rfc2781 +
    [RFC3629] +
    F. Yergeau. UTF-8, a transformation format of ISO 10646. November 2003. Internet Standard. URL: https://tools.ietf.org/html/rfc3629 +
    [SECURE-CONTEXTS] +
    Mike West. Secure Contexts. 19 July 2016. WD. URL: https://w3c.github.io/webappsec-secure-contexts/ +
    [UNICODE] +
    The Unicode Standard. URL: http://www.unicode.org/versions/latest/ +
    [WORKLETS-1] +
    Ian Kilpatrick. Worklets Level 1. 7 June 2016. WD. URL: https://drafts.css-houdini.org/worklets/ +
    +

    Informative References

    +
    +
    [DOM] +
    Anne van Kesteren. DOM Standard. Living Standard. URL: https://dom.spec.whatwg.org/ +
    [OMGIDL] +
    CORBA 3.1 – OMG IDL Syntax and Semantics chapter. January 2008. URL: http://www.omg.org/cgi-bin/doc?formal/08-01-04.pdf +
    [XML-NAMES] +
    Tim Bray; et al. Namespaces in XML 1.0 (Third Edition). 8 December 2009. REC. URL: https://www.w3.org/TR/xml-names +
    +

    IDL Index

    +
    typedef (Int8Array or Int16Array or Int32Array or
    +         Uint8Array or Uint16Array or Uint32Array or Uint8ClampedArray or
    +         Float32Array or Float64Array or DataView) ArrayBufferView;
    +
    +typedef (ArrayBufferView or ArrayBuffer) BufferSource;
    +typedef unsigned long long DOMTimeStamp;
    +callback Function = any (any... arguments);
    +callback VoidFunction = void ();
    +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + \ No newline at end of file diff --git a/index.xml b/index.xml deleted file mode 100644 index 9975101b..00000000 --- a/index.xml +++ /dev/null @@ -1,16418 +0,0 @@ - - - - - - - - - - Web IDL (Second Edition) - - - - - - - - -
    W3C

    Java language binding for Web IDL

    W3C Working Group Note 14 May 2013

    This Version:
    http://www.w3.org/TR/2013/NOTE-WebIDL-Java-20130514/
    Current Editor’s Draft:
    http://dev.w3.org/2006/webapi/WebIDL/java.html
    Latest Version:
    http://www.w3.org/TR/WebIDL-Java/
    Previous Version:
    http://www.w3.org/TR/2012/WD-WebIDL-Java-20120207/
    Editor:
    Cameron McCormack, Mozilla Corporation <cam@mcc.id.au>

    - -
    -

    Abstract

    -

    - This document defines the Java language binding for Web IDL, - the interface definition language for the Web platform. -

    -
    - -
    -

    Status of This Document

    -

    - This section describes the status of this document at the time of - its publication. Other documents may supersede this document. A list - of current W3C publications and the latest revision of this technical - report can be found in the W3C technical - reports index at http://www.w3.org/TR/. -

    - Please send comments about this document to - public-script-coord@w3.org - (archived). -

    -

    - This document originally existed as a section in the Web IDL - specification. [WEBIDL] It was split out into this Working Group Note due to the prospect of it - impeding the progress of Web IDL due to having insufficient implementations and because - of a general lack of interest in the Java binding. -

    -

    - This document is produced by the - Web Applications Working Group, part of the - Rich Web Clients Activity - in the W3C Interaction Domain. - Changes made to this document can be found in the - W3C - public CVS server. -

    -

    - Note: The Working Group reached consensus - to stop work on this specification. It is being published for archival - reasons and is no longer being progressed along the W3C's Recommendation Track. -

    - -

    - Publication as a Working Group Note does not imply endorsement by the - W3C Membership. This is a draft document and may be updated, replaced - or obsoleted by other documents at any time. It is inappropriate to cite - this document as other than work in progress. -

    - This document was produced by a group operating under the - 5 February - 2004 W3C Patent Policy. W3C maintains a - public list of - any patent disclosures made in connection with the deliverables of - the group; that page also includes instructions for disclosing a patent. - An individual who has actual knowledge of a patent which the individual - believes contains - Essential - Claim(s) must disclose the information in accordance with - section - 6 of the W3C Patent Policy. -

    -
    - - - -
    -
    -

    1. Introduction

    - -

    This section is informative.

    - -

    - This document defines a Web IDL language binding for Java 5. [WEBIDL] [JLS3] -

    - -
    -

    1.1. Typographic conventions

    -

    - The following typographic conventions are used in this document: -

    -
      -
    • Defining instances of terms: example term
    • -
    • Links to terms defined in this document: example term
    • -
    • Links to terms defined in other documents: example term
    • -
    • IDL and Java types: ExampleType
    • -
    • Code snippets: a = b + obj.f()
    • -
    • Unicode characters: U+0030 DIGIT ZERO ("0")
    • -
    • Extended attributes: [ExampleExtendedAttribute]
    • -
    • Variable names in prose and algorithms: exampleVariableName.
    • -
    • Non-normative notes:
      Note

      This is a note.

    • -
    • Non-normative examples:
      Example

      This is an example.

    • - -
    • Code blocks:
      IDL
      // This is an IDL code block.
      -interface Example {
      -  attribute long something;
      -};
      -
      Java
      // This is a Java code block.
      -Document doc = element.getOwnerDocument();
    • -
    -
    - -
    - -
    -

    2. Conformance

    - -

    - Everything in this specification is normative except for diagrams, - examples, notes and sections marked as being informative. -

    -

    - The keywords “MUST”, - “MUST NOT”, - “REQUIRED”, - “SHALL”, - “SHALL NOT”, - “SHOULD”, - “SHOULD NOT”, - “RECOMMENDED”, - “MAY” and - “OPTIONAL” in this document are to be - interpreted as described in - Key words for use in RFCs to - Indicate Requirement Levels - [RFC2119]. -

    -

    - The following conformance class is defined by this specification: -

    -
    -
    conforming Java implementation
    -
    -

    - A user agent is considered to be a - conforming Java implementation - relative to a conforming - IDL fragment if it satisfies all of the MUST-, - REQUIRED- and SHALL-level - criteria in this specification that apply to implementations for the Java - language binding. -

    -
    -
    -
    - -
    -

    3. Java binding

    - -

    - This section describes how definitions written with Web IDL [WEBIDL] - correspond to particular constructs in Java 5 [JLS3]. -

    - -
    -

    3.1. Names

    - -

    - Since Java has a number of reserved words in the language, some identifiers - of Java constructs corresponding to IDL definitions need to be escaped - to avoid conflicts. A name is Java escaped - as follows: -

    -
      -
    • - If the name is a Java reserved word, then the Java escaped name is the - name prefixed with a U+005F LOW LINE ("_") - character. -
    • -
    • - Otherwise, the name is not a Java reserved word. The Java escaped name - is simply the name. -
    • -
    - -
    Note
    -

    - At the time of publication, the list of Java reserved words is the following: - abstract, - assert, - boolean, - break, - byte, - case, - catch, - char, - class, - const, - continue, - default, - do, - double, - else, - enum, - extends, - final, - finally, - float, - for, - goto, - if, - implements, - import, - instanceof, - int, - interface, - long, - native, - new, - package, - private, - protected, - public, - return, - short, - static, - strictfp, - super, - switch, - synchronized, - this, - throw, - throws, - transient, - try, - void, - volatile, - while. -

    -
    -
    - -
    -

    3.2. Java type mapping

    - -

    - This section describes how types in the IDL map to types - in Java. -

    -

    - Each sub-section below describes how values of a given IDL type - are represented in Java. For each IDL type, it is described how - Java values are converted to an IDL value - when passed as an argument to a Java method (corresponding - to an operation or - attribute). Conversely, - it is described how IDL values of that type are - converted to Java values - when being used as the value of a Java final variable (corresponding - to a constant) or when - returned from a Java method (corresponding to an operation, - attribute or exception field). -

    - -
    -

    3.2.1. any

    -

    - The any IDL type corresponds to a - Java java.lang.Object value. -

    -

    - How to convert a Java value - to an IDL any value depends on the - type of the Java value: -

    -
    -
    A java.lang.Boolean object
    -
    - The IDL value is obtained - by converting - the result of calling the booleanValue() method on the - java.lang.Boolean object to an IDL - boolean value. -
    -
    A java.lang.Byte object
    -
    - The IDL value is obtained - by converting - the result of calling the byteValue() method on the - java.lang.Byte object to an IDL - byte value. -
    -
    A java.lang.Short object
    -
    - The IDL value is obtained - by converting - the result of calling the shortValue() method on the - java.lang.Short object to an IDL - short value. -
    -
    A java.lang.Integer object
    -
    - The IDL value is obtained - by converting - the result of calling the intValue() method on the - java.lang.Integer object to an IDL - long value. -
    -
    A java.lang.Long object
    -
    - The IDL value is obtained - by converting - the result of calling the longValue() method on the - java.lang.Long object to an IDL - long long value. -
    -
    A java.lang.Float object
    -
    - The IDL value is obtained - by converting - the result of calling the floatValue() method on the - java.lang.Float object to an IDL - float value. -
    -
    A java.lang.Double object
    -
    - The IDL value is obtained - by converting - the result of calling the doubleValue() method on the - java.lang.Double object to an IDL - double value. -
    -
    A java.lang.String object
    -
    - The IDL value is obtained - by converting - the java.lang.String object to an IDL - DOMString value. -
    -
    An array object
    -
    - The IDL value is the IDL sequence obtained - by converting - the Java array object to a sequence, as described in - section 3.2.23 below. -
    -
    An object that implements a Java array interface
    -
    - The IDL value is the IDL array obtained - by converting - the Java object to an array, as described in - section 3.2.24 below. -
    -
    An object of any other class
    -
    - The IDL value is an object value - that references the same object. -
    -
    null
    -
    - The IDL value is the null - object? value. -
    -
    -

    - How to convert - an IDL any value to a Java - java.lang.Object value depends on the - specific type of the IDL value: -

    -
    -
    A value of a primitive type
    -
    -

    - The Java value is the result of - converting - the IDL value of the given type to a Java value, and then passing - that value to the static method according to the following table: -

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    IDL typeMethod
    booleanjava.lang.Boolean.valueOf(boolean)
    bytejava.lang.Byte.valueOf(byte)
    octetjava.lang.Byte.valueOf(byte)
    shortjava.lang.Short.valueOf(short)
    unsigned shortjava.lang.Short.valueOf(short)
    longjava.lang.Integer.valueOf(int)
    unsigned longjava.lang.Integer.valueOf(int)
    long longjava.lang.Long.valueOf(long)
    unsigned long longjava.lang.Long.valueOf(long)
    floatjava.lang.Float.valueOf(float)
    unrestricted floatjava.lang.Float.valueOf(float)
    doublejava.lang.Double.valueOf(double)
    unrestricted doublejava.lang.Double.valueOf(double)
    -
    -
    An IDL value of any other type
    -
    - To obtain a Java value, the rules for converting the specific type - of the IDL any value as described - in the remainder of this section are performed. -
    -
    -
    - -
    -

    3.2.2. void

    - -

    - The only place that the void type may appear - in IDL is as the return type - of an operation. Methods on Java objects - that implement an operation whose IDL specifies a void - return type MUST be declared to have a return type of void. -

    -
    - -
    -

    3.2.3. boolean

    - -

    - IDL boolean values are represented by - Java boolean values. -

    -

    - The result of converting - a Java boolean value to an IDL value - is the IDL boolean - that represents the same truth value as the Java - boolean. -

    -

    - The result of converting - an IDL boolean value to a Java - value is the Java boolean that - represents the same truth value as the IDL - boolean. -

    -
    - -
    -

    3.2.4. byte

    - -

    - IDL byte values are - represented by Java byte values. -

    -

    - The result of converting - a Java byte value to an IDL value - is the IDL byte - that represents the same numeric value as the Java - byte. -

    -

    - The result of converting - an IDL byte value to a Java - value is the Java byte that - represents the same numeric value as the IDL - byte. -

    -
    - -
    -

    3.2.5. octet

    - -

    - IDL octet values are represented by - Java byte values. Note that while - the IDL octet type is unsigned, with a - range of [0, 255], the Java byte type - is signed, with a range of [−128, 127]. -

    -

    - Conversion - of an octet value to a - byte is performed as follows: -

    -
      -
    1. Let x be the octet value to convert.
    2. -
    3. If x < 128, return the byte whose value is x.
    4. -
    5. Otherwise x ≥ 128. Return the byte whose value is x − 256.
    6. -
    -
    Note
    -

    - In Java this is the same as having the - octet value stored in - an int and casting it to a - byte. -

    -
    -

    - Conversion - of a byte to an - octet is performed as - follows: -

    -
      -
    1. Let x be the byte value to decode.
    2. -
    3. If x ≥ 0, return the octet whose value is x.
    4. -
    5. Otherwise x < 0. Return the octet whose value is x + 256.
    6. -
    -
    Note
    -

    - In Java this is the same as performing a bit-wise AND of the - byte value with the - int constant - 0xff. -

    -
    -
    - -
    -

    3.2.6. short

    - -

    - IDL short values are - represented by Java short values. -

    -

    - The result of converting - a Java short value to an IDL value - is the IDL short - that represents the same numeric value as the Java - short. -

    -

    - The result of converting - an IDL short value to a Java - value is the Java short that - represents the same numeric value as the IDL - short. -

    -
    - -
    -

    3.2.7. unsigned short

    - -

    - IDL unsigned short values are - represented by Java short values. Note that while - the IDL unsigned short type is unsigned, with a - range of [0, 65535], the Java short type - is signed, with a range of [−32768, 32767]. -

    -

    - Conversion - of an IDL unsigned short value to a - Java short is performed as follows: -

    -
      -
    1. Let x be the IDL unsigned short value to convert.
    2. -
    3. If x < 32768, return the Java short whose value is x.
    4. -
    5. Otherwise x ≥ 32768. Return the Java short whose value is x − 65536.
    6. -
    -
    Note
    -

    - In Java this is the same as having the unsigned short value stored in - an int and casting it to a short. -

    -
    -

    - Conversion - of a Java short to an IDL - unsigned short value - is performed as follows: -

    -
      -
    1. Let x be the Java short value to decode.
    2. -
    3. If x ≥ 0, return the IDL unsigned short whose value is x.
    4. -
    5. Otherwise x < 0. Return the IDL unsigned short whose value is x + 65536.
    6. -
    -
    Note
    -

    - In Java this is the same as performing a bit-wise AND of the short value - with the int constant 0xffff. -

    -
    -
    - -
    -

    3.2.8. long

    - -

    - IDL long values are - represented by Java int values. -

    -

    - The result of converting - a Java int value to an IDL value - is the IDL long - that represents the same numeric value as the Java - int. -

    -

    - The result of converting - an IDL long value to a Java - value is the Java int that - represents the same numeric value as the IDL - short. -

    -
    - -
    -

    3.2.9. unsigned long

    - -

    - IDL unsigned long values are - represented by Java int values. Note that while - the IDL unsigned long type is unsigned, with a - range of [0, 4294967295], the Java int type - is signed, with a range of [−2147483648, 2147483647]. -

    -

    - Conversion - of an IDL unsigned long value to a - Java int is performed as follows: -

    -
      -
    1. Let x be the IDL unsigned long value to convert.
    2. -
    3. If x < 2147483648, return the Java int whose value is x.
    4. -
    5. Otherwise x ≥ 2147483648. Return the Java int whose value is x − 4294967296.
    6. -
    -
    Note
    -

    - In Java this is the same as having the unsigned long value stored in - a Java long and casting it to an int. -

    -
    -

    - Conversion - of a Java int to an IDL - unsigned long value - is performed as follows: -

    -
      -
    1. Let x be the Java int value to decode.
    2. -
    3. If x ≥ 0, return the IDL unsigned long whose value is x.
    4. -
    5. Otherwise x < 0. Return the IDL unsigned long whose value is x + 4294967296.
    6. -
    -
    Note
    -

    - In Java this is the same as performing a bit-wise AND of the int value - with the long constant 0xffffffffL. -

    -
    -
    - -
    -

    3.2.10. long long

    - -

    - IDL long long values are - represented by Java long values. -

    -

    - The result of converting - a Java long value to an IDL value - is the IDL long long - that represents the same numeric value as the Java - long. -

    -

    - The result of converting - an IDL long long value to a Java - value is the Java long that - represents the same numeric value as the IDL - long long. -

    -
    - -
    -

    3.2.11. unsigned long long

    - -

    - IDL unsigned long long values are - represented by Java long values. Note that while - the IDL unsigned long long type is unsigned, with a - range of [0, 18446744073709551615], the Java long type - is signed, with a range of [−9223372036854775808, 9223372036854775807]. -

    -

    - Conversion - of an IDL unsigned long long value to a - Java long is performed as follows: -

    -
      -
    1. Let x be the IDL unsigned long long value to convert.
    2. -
    3. If x < 18446744073709551616, return the Java long whose value is x.
    4. -
    5. Otherwise x ≥ 18446744073709551616. Return the Java long whose value is x − 18446744073709551615.
    6. -
    -

    - Conversion - of a Java long to an IDL - unsigned long long value - is performed as follows: -

    -
      -
    1. Let x be the Java long value to decode.
    2. -
    3. If x ≥ 0, return the IDL unsigned long long whose value is x.
    4. -
    5. Otherwise x < 0. Return the IDL unsigned long long whose value is x + 18446744073709551615.
    6. -
    -
    - -
    -

    3.2.12. float

    - -

    - IDL float values are - represented by Java float values. -

    -

    - A Java float value V is converted - to an IDL float value as follows: -

    -
      -
    1. - If V is non-finite, then throw a java.lang.IllegalArgumentException. -
    2. -
    3. - Otherwise, the IDL float value is the one - that represents the same IEEE 754 single precision floating point value as V. -
    4. -
    -

    - The result of converting - an IDL float value to a Java - value is the Java float that - represents the same IEEE 754 single precision floating point value as the IDL - float. -

    -
    - -
    -

    3.2.13. unrestricted float

    - -

    - IDL unrestricted float values are - represented by Java float values. -

    -

    - The result of converting - a Java float value to an IDL unrestricted float - value is the one that represents the same IEEE 754 single precision floating point value as the Java - float. -

    -

    - The result of converting - an IDL unrestricted float value to a Java - value is the Java float that - represents the same IEEE 754 single precision floating point value as the IDL - unrestricted float. -

    -
    - -
    -

    3.2.14. double

    - -

    - IDL double values are - represented by Java double values. -

    -

    - A Java double value V is converted - to an IDL double value as follows: -

    -
      -
    1. - If V is non-finite, then throw a java.lang.IllegalArgumentException. -
    2. -
    3. - Otherwise, the IDL double value is the one - that represents the same IEEE 754 double precision floating point value as V. -
    4. -
    -

    - The result of converting - an IDL double value to a Java - value is the Java double that - represents the same IEEE 754 double precision floating point value as the IDL - double. -

    -
    - -
    -

    3.2.15. unrestricted double

    - -

    - IDL unrestricted double values are - represented by Java double values. -

    -

    - The result of converting - a Java double value to an IDL unrestricted double - value is the one that represents the same IEEE 754 double precision floating point value as the Java - double. -

    -

    - The result of converting - an IDL unrestricted double value to a Java - value is the Java double that - represents the same IEEE 754 double precision floating point value as the IDL - unrestricted double. -

    -
    - -
    -

    3.2.16. DOMString

    - -

    - IDL DOMString values are - represented by Java java.lang.String reference - values. -

    -

    - A Java java.lang.String reference value is - converted - to an IDL DOMString value as follows: -

    -
      -
    • If the value is null, then throw a java.lang.NullPointerException.
    • -
    • - Otherwise, return the IDL DOMString - value that represents the same sequence of code units as the one - the Java java.lang.String value - represents. -
    • -
    -

    - The result of converting - an IDL DOMString value to a Java - java.lang.String value is a - java.lang.String - object that represents the same sequence of characters that the - IDL DOMString represents. -

    -
    - -
    -

    3.2.17. object

    - -

    - IDL object values are - represented by Java java.lang.Object reference - values. -

    -

    - A Java java.lang.Object reference value is - converted - to an IDL object value as follows: -

    -
      -
    • If the value is null, then throw a java.lang.NullPointerException.
    • -
    • - Otherwise, return the IDL object value that - is a reference to the same object. -
    • -
    -

    - The result of converting - an IDL object value to a Java - value is a Java java.lang.Object value - that is a reference to the same object. -

    -
    - -
    -

    3.2.18. Interface types

    - -

    - IDL interface type values are - represented by Java references of the corresponding Java interface type. - (See section 3.4 below - for how IDL interfaces have - corresponding Java interfaces.) -

    -

    - A Java value V is - converted - to an IDL interface type value - by running the following algorithm (where I is the interface): -

    -
      -
    1. If V is a platform object that implements I, - then return the IDL interface type value that represents a reference to that platform object.
    2. -
    3. Otherwise, throw a java.lang.IllegalArgumentException.
    4. -
    -

    - Conversions from IDL - interface type values to Java values - are performed in the same way as that for the IDL - object type. -

    -
    - -
    -

    3.2.19. Dictionary types

    - -

    - IDL dictionary type values are - represented by Java references to objects of the - java.util.HashMap<java.lang.String,java.lang.Object> class. - Each dictionary member that is - present - corresponds to an entry in the HashMap. -

    -

    - A Java java.util.HashMap<java.lang.String,java.lang.Object> reference value - O is - converted - to an IDL dictionary type value - by running the following algorithm (where D is the dictionary): -

    -
      -
    1. If O is null, then throw a java.lang.NullPointerException.
    2. -
    3. Let dict be an empty dictionary value of type D; - every dictionary member - is initially considered to be not present.
    4. -
    5. Let dictionaries be a list consisting of D and all of D’s inherited dictionaries, - in order from least to most derived.
    6. -
    7. For each dictionary dictionary in dictionaries, in order: -
        -
      1. For each dictionary member member declared on dictionary, in order: -
          -
        1. Let key be the identifier of member.
        2. -
        3. Let javaKey be the result of converting key to a java.lang.String.
        4. -
        5. Let present be the result of calling the containsKey method on O with javaKey as the only argument.
        6. -
        7. If present is true, then: -
            -
          1. Let value be the result of calling the get method on O javaKey as the only argument.
          2. -
          3. Let idlValue be the result of converting value to an IDL value whose type is the type member is declared to be of.
          4. -
          5. Set the dictionary member on dict with key name key to the value idlValue. This dictionary member is considered to be present.
          6. -
          -
        8. -
        -
      2. -
      -
    8. -
    9. Return dict.
    10. -
    -

    - An IDL dictionary type value V is - converted to a Java - java.util.HashMap<java.lang.String,java.lang.Object> reference value - by running the following algorithm (where D is the dictionary): -

    -
      -
    1. Let O be a new java.util.HashMap<java.lang.String,java.lang.Object> object.
    2. -
    3. Let dictionaries be a list consisting of D and all of D’s inherited dictionaries, - in order from least to most derived.
    4. -
    5. For each dictionary dictionary in dictionaries, in order: -
        -
      1. For each dictionary member member declared on dictionaries, in order: -
          -
        1. Let key be the identifier of member.
        2. -
        3. Let javaKey be the result of converting key to a java.lang.String.
        4. -
        5. If the dictionary member named key is present on V, then: -
            -
          1. Let idlValue be the value of member on V.
          2. -
          3. Let value be the result of converting idlValue to a Java value - as if value were an IDL any value.
          4. -
          5. Call the put method on O with arguments javaKey and value.
          6. -
          -
        6. -
        -
      2. -
      -
    6. -
    7. Return O.
    8. -
    -
    - -
    -

    3.2.20. Enumeration types

    - -

    - IDL enumeration type values are - represented by Java java.lang.String - reference values. -

    -

    - A Java java.lang.String reference value is - converted - to an IDL enumeration type value as follows - (where E is the enumeration): -

    -
      -
    • If the value is null, then throw a java.lang.NullPointerException.
    • -
    • If the java.lang.String object does not represent the - same string as any of the enumeration’s values, - then throw a java.lang.IllegalArgumentException.
    • -
    • Return the enumeration value of type E that is equal to the string - the java.lang.String object represents.
    • -
    -

    - The result of converting - an IDL enumeration type value to a Java - java.lang.String value is a - java.lang.String - object that represents the same sequence of code units - as the enumeration value. -

    -
    - -
    -

    3.2.21. Callback function types

    - -

    - IDL callback function type values are - represented by Java references of the corresponding Java interface type. - (See section 3.5 below - for how IDL callback functions have - corresponding Java interfaces.) -

    -

    - A Java value V is - converted - to an IDL callback function type value - by running the following algorithm (where C is the callback function): -

    -
      -
    1. If V is an object that implements the Java interface for C, then - return the IDL callback function type value that represents a reference to that object.
    2. -
    3. Otherwise, throw a java.lang.IllegalArgumentException.
    4. -
    -

    - Conversions from IDL - callback function type values to Java values - are performed in the same way as that for the IDL - object type. -

    -
    - -
    -

    3.2.22. Nullable types — T?

    - -

    - IDL nullable type - values are represented with Java object references of a particular - class, as determined by the table below: -

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Nullable typeJava classMethod to get value
    boolean?java.lang.BooleanbooleanValue()
    byte?java.lang.BytebyteValue()
    octet?java.lang.BytebyteValue()
    short?java.lang.ShortshortValue()
    unsigned short?java.lang.ShortshortValue()
    long?java.lang.IntegerintValue()
    unsigned long?java.lang.IntegerintValue()
    long long?java.lang.LonglongValue()
    unsigned long long?java.lang.LonglongValue()
    float?java.lang.FloatfloatValue()
    unrestricted float?java.lang.FloatfloatValue()
    double?java.lang.DoubledoubleValue()
    unrestricted double?java.lang.DoubledoubleValue()
    DOMString?java.lang.String
    Enumeration type T?java.lang.String
    Interface type T?The Java interface corresponding to IDL type T
    Dictionary type T?java.util.HashMap<java.lang.String,java.lang.Object>
    sequence<T>?U[], where U is the Java type used to represent the IDL type T
    T[]?The Java array interface for IDL type T
    Union type T?java.lang.Object
    -

    - How to convert a Java value - of one of the above classes to an IDL nullable type T? - depends on the object reference value and the type T: -

    -
    -
    If the object reference value is null
    -
    - The IDL value is the null T? value. -
    -
    If the value is not an object of the right type for T according to the table above
    -
    - Throw a java.lang.IllegalArgumentException. -
    -
    If T is a primitive type
    -
    - Let method be the method indicated in the table above for type T. - The IDL value is a T? whose value is obtained - by converting - the result of calling method on the object to type T. -
    -
    Anything else
    -
    - The IDL value is a T? whose value is obtained - by converting - the object reference value to type T. -
    -
    -

    - How to convert - an IDL nullable type value to a Java value depends on - its value and the inner type: -

    -
    -
    If the IDL value is null
    -
    - The Java value is null. -
    -
    If the IDL value is a non-null nullable primitive value
    -
    -

    - The Java value is the result of converting - the IDL inner type to a Java value, and then passing - that value to the static method according to the following table, - where T is the IDL inner type: -

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    TMethod
    booleanjava.lang.Boolean.valueOf(boolean)
    bytejava.lang.Byte.valueOf(byte)
    octetjava.lang.Byte.valueOf(byte)
    shortjava.lang.Short.valueOf(short)
    unsigned shortjava.lang.Short.valueOf(short)
    longjava.lang.Integer.valueOf(int)
    unsigned longjava.lang.Integer.valueOf(int)
    long longjava.lang.Long.valueOf(long)
    unsigned long longjava.lang.Long.valueOf(long)
    floatjava.lang.Float.valueOf(float)
    unrestricted floatjava.lang.Float.valueOf(float)
    doublejava.lang.Double.valueOf(double)
    unrestricted doublejava.lang.Double.valueOf(double)
    -
    -
    If the IDL value is a non-null DOMString? value
    -
    - The Java value is a java.lang.String object representing - the same sequence of code units as the DOMString? value. -
    -
    If the IDL value is a non-null nullable enumeration value
    -
    - The Java value is a java.lang.String object representing - the same sequence of code units as the enumeration value. -
    -
    If the IDL value is a non-null sequence<T>? value
    -
    - The Java value is the result of converting - the IDL sequence value to a Java array object, as described in - section 3.2.23 below. -
    -
    If the IDL value is a non-null T[]? value
    -
    - The Java value is the result of converting - the IDL array value to a Java object implementing the Java array interface - for T, as described in section 3.2.24 below. -
    -
    If the IDL value is a non-null nullable dictionary type value
    -
    - The Java value is the result of converting - the IDL dictionary value to a Java java.util.HashMap<java.lang.String,java.lang.Object> - object, as described in - section 3.2.19 above. -
    -
    If the IDL value is a non-null nullable interface type or object? value
    -
    - The Java value is a reference to the same object. -
    -
    If the IDL value is a non-null nullable union type value
    -
    - The Java value is the result of converting - the IDL union type value to a Java java.lang.Object reference, - as described in section 3.2.25 below. -
    -
    -
    - -
    -

    3.2.23. Sequences — sequence<T>

    - -

    - IDL sequence<T> values are - represented by Java arrays of type U, where U is the Java type used to - represent the IDL type T. -

    -

    - A Java array A of type U is converted - to an IDL sequence<T> as follows: -

    -
      -
    1. If A is null, then throw a java.lang.NullPointerException.
    2. -
    3. Let n be the length of the array A.
    4. -
    5. Initialize S0..n−1 to be an IDL sequence with elements of type T, where each element is uninitialized.
    6. -
    7. Initialize i to be 0.
    8. -
    9. While i < n: -
        -
      1. Let E be the value value of A at index i.
      2. -
      3. Set Si to the result of converting - E to an IDL value of type T.
      4. -
      5. Set i to i + 1.
      6. -
      -
    10. -
    11. Return S.
    12. -
    -

    - An IDL sequence value S0..n−1 of type - sequence<T> is - converted - to a Java array of type U object as follows: -

    -
      -
    1. Let A be a new Java array object with element type U and length n.
    2. -
    3. Initialize i to be 0.
    4. -
    5. While i < n: -
        -
      1. Let E be the result of converting - Si to a Java value of type U.
      2. -
      3. Set element i of the array A to the value E.
      4. -
      5. Set i to i + 1.
      6. -
      -
    6. -
    7. Return A.
    8. -
    -

    - A Java object implementing an interface - with an operation declared to return - a sequence<T> value - MUST NOT return null from the corresponding method. - Similarly, a getter method for an IDL - attribute MUST NOT - return null if the attribute - is declared to be of type sequence<T>. -

    -
    - -
    -

    3.2.24. Arrays — T[]

    - -

    - IDL T[] values are - represented by Java objects implementing a particular interface, - known as the Java array interface, - depending on the type T. -

    -

    - For each of the primitive types - there MUST exist a corresponding - Java array interface - of the following form: -

    -
    Java
    package org.w3c.dom;
    -
    -public interface PrimitiveNameArray {
    -  int getLength();
    -  void setLength(int length);
    -  PrimitiveType getElement(int index);
    -  void setElement(int index, PrimitiveType value);
    -}
    -

    - where PrimitiveName is the type name - of the primitive type and PrimitiveType is the Java type used - to represent it. -

    -
    Example
    -

    - For example, the Java array interface - for the octet[] type is: -

    -
    Java
    package org.w3c.dom;
    -
    -public interface OctetArray {
    -  int getLength();
    -  void setLength(int length);
    -  byte getElement(int index);
    -  void setElement(int index, byte value);
    -}
    -
    -

    - There MUST also exist the following interface, org.w3c.dom.ObjectArray<E>: -

    -
    Java
    package org.w3c.dom;
    -
    -public interface ObjectArray<E> {
    -  int getLength();
    -  void setLength(int length);
    -  E getElement(int index);
    -  void setElement(int index, E value);
    -}
    -

    - This interface, parameterized by the Java type used to represent array element - type T, is the corresponding Java array interface - for T. -

    -
    Example
    -

    - For example, the Java array interface - for the DOMString[]?[] type is - org.w3c.dom.ObjectArray<java.lang.ObjectArray<java.lang.String>>. -

    -
    - -

    - A Java object that implements a Java array interface - represents a given IDL array value of type T[]. - The methods on the object that implement that interface MUST behave as follows: -

    -
    -
    getLength()
    -
    -

    This method returns the current length of the IDL array value.

    -
    - -
    setLength(length)
    -
    -

    When called on an object representing a variable length - array, this method sets the length of the array to length. When the array is lengthened, the new - elements are set to the IDL value that results from converting to an IDL value the - default value - of the Java type that T corresponds to ([JLS3], section 4.12.5).

    - -

    When called on an object representing a fixed length - array, this method throws a java.lang.UnsupportedOperationException.

    -
    - -
    getElement(index)
    -
    -

    This method returns the IDL value of type T at the represented array’s index index - converted to a Java value.

    -
    - -
    setElement(index, value)
    -
    -

    When called on an object representing an array that is not read only, - this method sets the IDL value at the represented array’s index index to - the result of converting - value to an IDL value of type T.

    - -

    When called on an object representing an array that is read only, - this method throws a java.lang.UnsupportedOperationException.

    -
    -
    - -

    - A Java reference value O for an object implementing a - Java array interface - is converted to an - IDL array value as follows: -

    -
      -
    • If O is null, then throw a java.lang.NullPointerException.
    • -
    • Otherwise, if O is an object implementing a Java array interface - corresponding to a primitive type, then the IDL array value - is the array value that O represents. The type of the IDL array value is - T[], where T is the primitive type.
    • -
    • Otherwise, if O is an object implementing org.w3c.dom.ObjectArray<E>, - then the IDL array value is the array value that O represents. The type of - the IDL array value is the IDL type that E corresponds to.
    • -
    - -

    - An IDL array value A of type T[] - is converted to a - Java value whose type is an object implementing the Java array interface - corresponding to T, as follows: -

    -
      -
    • If A is already represented by an object implementing a Java array interface, - then the Java value is that object.
    • -
    • Otherwise, the Java value is newly created object implementing the Java array interface - that corresponds to T.
    • -
    -
    - -
    -

    3.2.25. Union types

    - -

    - IDL union type values are represented - by Java java.lang.Object reference values. -

    -

    - To convert a Java value V to an IDL union type - value is done as follows: -

    -
      -
    1. If the union type - includes a nullable type and - V is null object reference, - then return the IDL value null.
    2. -
    3. - Let types be the flattened member types - of the union type. -
    4. -
    5. - If V implements a Java array interface, then: -
        -
      1. If types includes an array type, then return the result of - converting - V to that type.
      2. -
      3. If types includes object, then return the IDL value - that is a reference to the object V.
      4. -
      -
    6. -
    7. - If V is an array object, then: -
        -
      1. If types includes an sequence type, then return the result of - converting - V to that type.
      2. -
      3. If types includes object, then return the IDL value - that is a reference to the object V.
      4. -
      -
    8. -
    9. - If V is any other platform object, then: -
        -
      1. If types includes an interface type that V - implements, then return the IDL value that is a reference to the object V.
      2. -
      3. If types includes object, then return the IDL value - that is a reference to the object V.
      4. -
      -
    10. -
    11. - If V is a java.util.Date object, then: -
        -
      1. If types includes Date, then return the - result of converting - V to Date.
      2. -
      3. If types includes object, then return the IDL value - that is a reference to the object V.
      4. -
      -
    12. -
    13. - If V is a java.lang.Boolean object, then: -
        -
      1. If types includes boolean, then return the - result of converting - the result of calling the booleanValue() method on V to boolean.
      2. -
      3. If types includes object, then return the IDL value - that is a reference to the object V.
      4. -
      -
    14. -
    15. - If V is a java.lang.Byte object, then: -
        -
      1. If types includes byte, then return the - result of converting - the result of calling the byteValue() method on V to byte.
      2. -
      3. If types includes object, then return the IDL value - that is a reference to the object V.
      4. -
      -
    16. -
    17. - If V is a java.lang.Short object, then: -
        -
      1. If types includes short, then return the - result of converting - the result of calling the shortValue() method on V to short.
      2. -
      3. If types includes object, then return the IDL value - that is a reference to the object V.
      4. -
      -
    18. -
    19. - If V is a java.lang.Integer object, then: -
        -
      1. If types includes long, then return the - result of converting - the result of calling the intValue() method on V to long.
      2. -
      3. If types includes object, then return the IDL value - that is a reference to the object V.
      4. -
      -
    20. -
    21. - If V is a java.lang.Long object, then: -
        -
      1. If types includes long long, then return the - result of converting - the result of calling the longValue() method on V to long long.
      2. -
      3. If types includes object, then return the IDL value - that is a reference to the object V.
      4. -
      -
    22. -
    23. - If V is a java.lang.Float object, then: -
        -
      1. If types includes float, then return the - result of converting - the result of calling the floatValue() method on V to float.
      2. -
      3. If types includes unrestricted float, then return the - result of converting - the result of calling the floatValue() method on V to unrestricted float.
      4. -
      5. If types includes object, then return the IDL value - that is a reference to the object V.
      6. -
      -
    24. -
    25. - If V is a java.lang.Double object, then: -
        -
      1. If types includes double, then return the - result of converting - the result of calling the doubleValue() method on V to double.
      2. -
      3. If types includes unrestricted double, then return the - result of converting - the result of calling the doubleValue() method on V to unrestricted double.
      4. -
      5. If types includes object, then return the IDL value - that is a reference to the object V.
      6. -
      -
    26. -
    27. - If V is a java.lang.String object, then: -
        -
      1. If types includes DOMString, then return the - result of converting - V to DOMString.
      2. -
      3. If types includes object, then return the IDL value - that is a reference to the object V.
      4. -
      -
    28. -
    29. - If V is any other type of object, then: -
        -
      1. If types includes a callback interface type, then return the result of - converting - V to that interface type.
      2. -
      3. If types includes a dictionary type, then return the - result of converting - V to that dictionary type.
      4. -
      5. If types includes object, then return the IDL value - that is a reference to the object V.
      6. -
      -
    30. -
    31. - Throw an IllegalArgumentException. -
    32. -
    -

    - An IDL union type is converted - to a Java value by following the same rules as if the IDL type were any. -

    -
    - -
    -

    3.2.26. Date

    - -

    - IDL Date values are - represented by Java java.util.Date reference - values. -

    -

    - A Java java.lang.Date reference value is - converted - to an IDL Date value as follows: -

    -
      -
    • If the value is null, then throw a java.lang.NullPointerException.
    • -
    • Let m be the millisecond that the java.util.Date object represents.
    • -
    • If m cannot be represented by an IDL Date value, then return the undefined IDL Date value.
    • -
    • Return the IDL Date value that represents m.
    • -
    -

    - An IDL Date value is - converted - to a java.lang.Date reference value as follows: -

    -
      -
    • If the value is the undefined IDL Date value, then return - a newly created java.util.Date object as if by calling new java.util.Date(Long.MIN_VALUE).
    • -
    • Otherwise, return a newly created java.util.Date - object that represents the same millisecond that the IDL Date value does.
    • -
    -
    -
    - -
    -

    3.3. Java-specific extended attributes

    - -

    - This section defines a single extended attribute - whose presence affects only the Java binding. -

    - -
    -

    3.3.1. [JavaPackage]

    - -

    - If the [JavaPackage] - extended attribute - appears on an interface or - exception, - it specifies that the corresponding Java interface or class MUST - be placed in the package identified. When [JavaPackage] - is not used, the Java interface or class MUST be placed - in the org.w3c.dom package. -

    -

    - The [JavaPackage] - extended attribute - MUST take a dotted name, - which is defined as the extended attribute matching ExtendedAttributeDottedName - in the following grammar, which is to be interpreted in the same manner - as the grammar in Web IDL ([WEBIDL], appendix A): -

    -
    [1]ExtendedAttributeDottedNameidentifier DottedNameParts
    [2]DottedNameParts"." identifier DottedNameParts
     | - ε
    -

    - The dotted name identifies the Java package in which the Java interface or class - is to be placed. -

    -

    - Interfaces defined for the Web platform SHOULD NOT - use [JavaPackage] unless required for - compatibility. -

    - -
    Example
    -

    - The following IDL fragment defines - an IDL interface whose corresponding - Java interface will not be in the org.w3c.dom package. -

    -
    IDL
    [JavaPackage=org.example]
    -interface Something {
    -};
    -
    -
    -
    - -
    -

    3.4. Interfaces

    - -

    - For every supported IDL interface, - there MUST exist a corresponding public Java interface - whose name is the Java escaped - identifier of the IDL interface. -

    -

    - The Java interface for an interface A MUST be declared to extend the following - Java interfaces: -

    -
      -
    • the Java interface that corresponds to the interface from which A - inherits, if it does inherit from one, and
    • -
    • the Java interfaces that correspond to each interface on the right-hand side of - an implements statement where A - is on the left-hand side.
    • -
    -

    - If the IDL interface has one or more static operations - declared on it, then there MUST also exist - a public, abstract Java class, which resides in the same Java - package as the interface. - This class is known as the utility class - for the IDL interface, and provides access to the static operations. - The name of the Java class is the concatenation - of the identifier of the IDL interface - and the string “Utils”. If this name is already - the name of a Java class or interface, due to IDL definitions, then - the name of the Java class is prefixed with a single - U+005F LOW LINE ("_") character - so as not to conflict. -

    - -
    -

    3.4.1. Constants

    -

    - For each constant defined on - the IDL interface, there - MUST be a corresponding constant declared on the Java interface - with the following characteristics: -

    -
      -
    • The constant has no modifiers.
    • -
    • - The type of the constant is the Java type that corresponds to the type of - the IDL constant, according to the rules in section 3.2 - above. -
    • -
    • - The name of the constant is the Java escaped - identifier of the constant. -
    • -
    • - The value of the constant is the result of converting - the constant’s IDL value to a Java value, according to the rules - in section 3.2 - above. -
    • -
    -
    - -
    -

    3.4.2. Operations

    -

    - The operations defined on - an IDL interface - will result in one or more methods being declared on the Java interface (for - regular operations) - or on a Java utility class (for static operations). -

    -

    - For each unique identifier id of the - regular operations - declared on the IDL interface: -

    -
      -
    • - For each pair <callabletype list> in the - effective overload set - for regular operations - with identifier id on the IDL interface and with argument - count 0, there MUST - exist a method on the Java interface whose name, its Java method name, - is determined as follows: -
        -
      1. Let identifier be the identifier of the operation callable.
      2. -
      3. Initialize name to be identifier Java escaped.
      4. -
      5. If name is the same as the name of - one of the methods defined on java.lang.Object, - then prepend a single U+005F LOW LINE ("_") character to name.
      6. -
      7. The name of the method is name.
      8. -
      -
    • -
    -

    - For each unique identifier id of the - static operations - declared on the IDL interface: -

    - -

    - For each identifierless special operation - declared on the IDL interface of the following types, -

    - -

    - there MUST exist a method on the Java interface whose - name is determined based on the type of special operation: -

    - - - - - - - -
    TypeName
    indexed or named property getter“_get”
    indexed or named property setter“_set”
    indexed or named property creator“_create”
    indexed or named property deleter“_delete”
    caller“_call”
    -

    - For all of the above operations – regular, static, and the abovementioned - special operations – their corresponding Java methods have the following - characteristics, based on the effective overload set - entry <callable, type list>: -

    -
      -
    • - The return type of the method is the Java type that corresponds to the operation - return type, according to the rules in - section 3.2 above. -
    • -
    • - The method has an argument for each type, in order, that is in type list. The type of - method argument j is the Java type that corresponds to the IDL type at - index j in type list, - according to the rules in section 3.2 - above. If the length of type list is the length of the - argument list callable is declared with, and callable is a - variadic operation, - then the method is a variable arity method ([JLS3], - section 8.4.1). -
    • - -
    • - An implementation of this method MUST - perform the following steps: -
        -
      1. - Let arg0..n−1 be the list - of Java argument values passed to the method. -
      2. -
      3. - Let idlarg0..n−1 be - a list of IDL values, where idlargi - is the result of converting - argi to an IDL value - of the type that the ith argument is declared to be. -
      4. -
      5. - Let R be the result of performing the actions listed in the description of the operation - callable with idlarg0..n−1 - as the argument values. -
      6. -
      7. - If the actions performed in the previous step resulted in an - exception being thrown, then allow that exception to propagate - out from this algorithm. Otherwise, return the result of - converting - R to a Java value of the type callable - is declared to return. -
      8. -
      -
    • -
    -
    - -
    -

    3.4.3. Attributes

    -

    - For each attribute defined on - the IDL interface that does not - inherit its getter, there - MUST be a corresponding getter method - declared on the Java interface with the following characteristics: -

    -
      -
    • The method has no modifiers.
    • -
    • - The return type of the method is the Java type that corresponds to the attribute type, - according to the rules in section 3.2 - above. -
    • -
    • - The name of the method is determined as follows: -
        -
      1. Let identifier be the identifier of the attribute.
      2. -
      3. Initialize name to be the string “get”.
      4. -
      5. Let ucIdentifier be identifier with first character uppercased, - as if passed to the java.lang.Character.toUpperCase() method.
      6. -
      7. If there exists another attribute on the interface - with identifier ucIdentifier, then append a single U+005F LOW LINE ("_") - character to name.
      8. -
      9. Append ucIdentifier to name.
      10. -
      11. If there exists a constant or - operation on the interface with - identifier name, or if name is the same as the name of - one of the methods defined on java.lang.Object, - then prepend a single U+005F LOW LINE ("_") character to name.
      12. -
      13. The name of the method is name.
      14. -
      -
    • -
    • - The method has no arguments. -
    • -
    • - An implementation of this method MUST - perform the following steps: -
        -
      1. - Let V be the IDL value that results from - performing the actions listed for getting the corresponding attribute - in the description of the interface. -
      2. -
      3. - If the actions performed in the previous step resulted in an - exception being thrown, then allow that exception to propagate - out from this algorithm. Otherwise, return the result of - converting - V to a Java value of the type op - is declared to return. -
      4. -
      -
    • -
    - -

    - For each attribute defined on the IDL interface that is not - read only, there - MUST be a corresponding setter method - declared on the Java interface with the following characteristics: -

    -
      -
    • The method has no modifiers.
    • -
    • - The return type of the method is void. -
    • -
    • - The name of the method is determined as follows: -
        -
      1. Let identifier be the identifier of the attribute.
      2. -
      3. Initialize name to be the string “set”.
      4. -
      5. Let ucIdentifier be identifier with first character uppercased, - as if passed to the java.lang.Character.toUpperCase() method.
      6. -
      7. If there exists another attribute on the interface - with identifier ucIdentifier, then append a single U+005F LOW LINE ("_") - character to name.
      8. -
      9. Append ucIdentifier to name.
      10. -
      11. If there exists a constant or - operation on the interface with - identifier name, or if name is the same as the name of - one of the methods defined on java.lang.Object, - then prepend a single U+005F LOW LINE ("_") character to name.
      12. -
      13. The name of the method is name.
      14. -
      -
    • -
    • - The method has a single argument whose type is the Java type that corresponds - to the attribute type, according to the rules in - section 3.2 above. -
    • -
    • - An implementation of this method MUST - perform the following steps: -
        -
      1. - Let arg be the Java value that was passed as the - argument to the method. -
      2. -
      3. - Let idlarg be the result of converting - arg to an IDL value of the type the attribute is declared to be. -
      4. -
      5. - Perform the actions for setting the corresponding attribute - with the value idlarg listed in the description of the interface. -
      6. -
      7. - If the actions performed in the previous step resulted in an - exception being thrown, then allow that exception to propagate - out from this algorithm. -
      8. -
      -
    • -
    - - -
    -
    - -
    -

    3.5. Callback functions

    - -

    - For every supported IDL callback function, - there MUST exist a corresponding public Java interface - whose name is the Java escaped - identifier of the callback function. -

    -

    - The Java interface for a callback function A MUST not - be declared to inherit from any other Java interface. -

    -

    - For each pair <callback, types> in the - effective overload set - for callback function A with argument count 0, - there MUST exist - a method on the Java interface with the following characteristics: -

    -
      -
    • The name of the method is call.
    • -
    • - The return type of the method is the Java type that corresponds to the callback function - return type, according to the rules in - section 3.2 above. -
    • -
    • - The method has an argument for each type, in order, that is in types. The type of - method argument j is the Java type that corresponds to the IDL type typesj, - according to the rules in section 3.2 - above. If the length of types is the length of the - argument list the callback function is declared with, and the callback function is declared - to be variadic, - then the method is a variable arity method ([JLS3], - section 8.4.1). -
    • -
    -
    - -
    -

    3.6. Platform objects implementing interfaces

    -

    - A Java platform object that implements an IDL interface - MUST be of a Java class which implements the Java interface - that corresponds to the IDL interface. -

    -

    - If the IDL interface has a stringifier, - the String toString() method - MUST be overridden to allow - stringification of the object as required by the IDL - interface. If the stringifier keyword - was used on an attribute A, - then, assuming O is the object on which - the method was invoked, the behavior of the overridden - toString method MUST - be as follows: -

    -
      -
    1. - Let R be the result of invoking the getter - method on O that corresponds to the IDL - attribute - A. -
    2. -
    3. Return R.
    4. -
    -

    - Otherwise, if the stringifier keyword - was used on an operation - O with an identifier, - then, assuming O is the object on which - the method was invoked, the behavior of the overridden - toString method MUST - be as follows: -

    -
      -
    1. - Let R be the result of invoking the method on O that corresponds to the IDL - operation - O, passing no arguments. -
    2. -
    3. Return R.
    4. -
    -

    - Otherwise, if the stringifier keyword - was used on an operation - without an identifier, then - the behavior of the overridden toString() - method is the stringification behavior - of the IDL interface, as described in the prose for the IDL interface. -

    -
    - -
    -

    3.7. User objects implementing callback interfaces

    - -

    - A Java user object that implements an IDL callback interface - MUST be of a Java class that implements the Java interface - that corresponds to the IDL interface, either by implementing the interface directly - on that class or by inheriting from another class that implements the interface. -

    -
    Note
    -

    For example, with the following IDL:

    -
    IDL
    callback interface Base {
    -  void f();
    -};
    -
    -callback interface Derived : Base {
    -  void g();
    -};
    -

    the Java implementation would provide the following interfaces:

    -
    Java
    public interface Base {
    -  void f();
    -}
    -
    -public interface Derived extends Base {
    -  void g();
    -}
    -

    and user objects implementing Derived - could be defined like the following:

    -
    Java
    // Directly implementing the interface
    -class DerivedImpl1 implements Derived {
    -  public void f() { ... }
    -  public void g() { ... }
    -}
    -
    -// Inheriting from a class that implements the interface
    -class DerivedImpl2 extends DerivedImpl1 { }
    -
    -
    - -
    -

    3.8. Exceptions

    -

    - For every IDL exception, there - MUST exist a corresponding Java class - whose name is the Java escaped - identifier of the IDL exception. -

    -

    - The Java class MUST have only the public modifier. - If the IDL exception inherits from another - exception, then the Java class MUST be declared to extend - the Java class corresponding to that inherited exception. Otherwise, the Java class MUST - be declared to extend org.w3c.dom.Exception. -

    -

    - The class MUST also have constructors and methods with definitions as follows, - where ExceptionName is the name of the class: -

    -
    Java
    public ExceptionName() {
    -}
    -
    -public ExceptionName(String message) {
    -    super(message);
    -}
    -
    -public ExceptionName(String message, Throwable cause) {
    -    super(message, cause);
    -}
    -
    -public ExceptionName(Throwable cause) {
    -    super(cause);
    -}
    -

    - The class org.w3c.dom.Exception is defined as follows: -

    -
    Java
    public class org.w3c.dom.Exception extends RuntimeException {
    -
    -    public Exception(String message) {
    -        super(message);
    -    }
    -
    -    public Exception(String message, Throwable cause) {
    -        super(message, cause);
    -    }
    -
    -    public Exception(Throwable cause) {
    -        super(cause);
    -    }
    -
    -    public void setName(String name) {
    -        this.name = name;
    -    }
    -
    -    public String getName() {
    -        return name;
    -    }
    -
    -    private String name;
    -}
    -
    -

    3.8.1. Constants

    -

    - For each constant defined on the - exception, there - MUST be a corresponding constant declared on the Java class - with the following characteristics: -

    -
      -
    • The constant has no modifiers.
    • -
    • - The type of the constant is the Java type that corresponds to the type of - the IDL constant, according to the rules in section 3.2 - above. -
    • -
    • - The name of the constant is the Java escaped - identifier of the constant. -
    • -
    • - The value of the constant is the result of converting - the constant’s IDL value to a Java value, according to the rules - in section 3.2 - above. -
    • -
    -
    - -
    -

    3.8.2. Exception fields

    -

    - For each exception field defined on the - exception, there - MUST be a corresponding instance variable declared on the Java class - with the following characteristics: -

    -
      -
    • The instance variable has only the modifier public.
    • -
    • - The type of the instance variable is the Java type that corresponds to the type of - the IDL exception field, according to the rules in section 3.2 - above. -
    • -
    • - The name of the instance variable is the Java escaped - identifier of the exception field. -
    • -
    • - The instance variable is not declared with an initializer. -
    • -
    -
    -
    - -
    -

    3.9. Throwing exceptions

    -

    - When an IDL exception or - predefined exception - E is to be thrown, - with an optional message M and name N, the following steps - MUST be followed: -

    -
      -
    1. Let C be the corresponding Java class for E if - E is an IDL exception, - or org.w3c.dom.Exception otherwise.
    2. -
    3. Let message be the result of - converting - M to a java.lang.String object - if one was specified, or null otherwise.
    4. -
    5. Let O be the result of constructing a new object of class C, - passing message as the sole argument to the constructor.
    6. -
    7. If an exception name N was specified, then call the - setName method of O with that type as a java.lang.String - as the sole argument.
    8. -
    9. Throw O.
    10. -
    -
    -
    - -
    -

    4. Extensibility

    - -

    This section is informative.

    - -

    - Extensions to the Java language binding requirements can be specified - using extended attributes - that do not conflict with those defined in this document. Extensions for - private, project-specific use should not be included in - IDL fragments - appearing in other specifications. It is recommended that extensions - that are required for use in other specifications be coordinated - with the group responsible for work on Web IDL, which - at the time of writing is the - W3C Web Applications Working Group, - for possible inclusion in a future version of this document. -

    -

    - Extensions to any other aspect of the IDL language are - strongly discouraged. -

    -
    - -
    -

    5. Referencing this specification

    - -

    This section is informative.

    - -

    - It is suggested that specifications defining interfaces with Web IDL for which Java - language bindings are required to exist include a sentence such as the following, - to indicate that the IDL is to be interpreted as described in this - specification: -

    -
    -

    - The IDL fragment in Appendix A of this specification must be interpreted - as required for conforming IDL fragments, as described in the - “Web IDL” specification. [WEBIDL] -

    -
    -

    - In addition, it is suggested that the conformance class for user - agents in referencing specifications be linked to the - conforming - Java implementation class from this specification: -

    -
    -

    - A conforming FooML user agent must also be a - conforming Java implementation of the IDL fragment in Appendix A - of this specification, as described in the - “Java language binding for Web IDL” specification. [WEBIDL-JAVA] -

    -
    -
    - -
    -

    6. Acknowledgements

    - -

    This section is informative.

    - -

    - The editor would like to thank contributors to the Web IDL specification, - from which this Java language binding was split out in December 2011. -

    -
    -
    - -
    -
    -

    A. References

    - -
    -

    A.1. Normative references

    - -
    -
    [JLS3]
    -
    - The Java Language Specification, Third Edition. - J. Gosling, et al. Upper Saddle River, New Jersey, Addison-Wesley, 2005. -
    Available at http://java.sun.com/docs/books/jls/.
    -
    -
    [RFC2119]
    -
    - Key words for use in RFCs to Indicate Requirement Levels, - S. Bradner. IETF, March 1997. -
    Available at http://tools.ietf.org/html/rfc2119.
    -
    -
    [WEBIDL]
    -
    - Web IDL. - C. McCormack, Editor. World Wide Web Consortium, work in progress, 19 April 2012. -
    Available at http://www.w3.org/TR/2012/CR-WebIDL-20120419/.
    -
    -
    -
    - - -
    - -
    -

    B. Changes

    -

    - The following is a list of substantial changes to the document on each publication. -

    -
    -
    14 May 2013 – NOTE
    -
    -
      -
    • -

      - Changed the org.w3c.dom.Exception class to take into account the - renaming of “exception types” to “exception names”. -

      -
    • -
    • -

      - Added support for IDL unrestricted float and double types. -

      -
    • -
    -
    -
    07 February 2012 – FPWD
    -
    -
      -
    • -

      - Added support for IDL callbacks and callback interfaces. -

      -
    • -
    • -

      - Added support for IDL union types. -

      -
    • -
    • -

      - Added support for IDL enumerations. -

      -
    • -
    -
    -
    12 December 2011 – ED
    -
    -
      -
    • -

      - Initial document creation. For changes prior to 12 December 2011, please see the - Web IDL Changes appendix. -

      -
    • -
    -
    -
    -
    -
    - - diff --git a/java.xml b/java.xml deleted file mode 100644 index f0fce9f6..00000000 --- a/java.xml +++ /dev/null @@ -1,2665 +0,0 @@ - - - - - - - - - - Java language binding for Web IDL - -