Changes between Version 85 and Version 116 of WebKitIDL

Timestamp:

(multiple changes)

Author:

(multiple changes)

Comment:

(multiple changes)

WebKitIDL

@@ -10 +10 @@
  - [#TreatNullAs TreatNullAs(a,p), TreatUndefinedAs(a,p)][[br]]
  - [#TreatReturnedNullStringAs TreatReturnedNullStringAs(m,a)][[br]]
- - [#Optional Optional(p)][[br]]
+ - [#Default Default(p)][[br]]
  - [#Clamp Clamp(a,p)][[br]]
- - [#Callback Callback(i,p)][[br]]
- - [#Custom Custom(m,a), JSCustom(m,a), V8Custom(m,a), CustomGetter(a), JSCustomGetter(a), V8CustomGetter(a), CustomSetter(a), JSCustomSetter(a), V8CustomSetter(a)][[br]]
+ - [#Custom Custom(m,a), CustomGetter(a), CustomSetter(a)][[br]]
  - [#CallWith CallWith(i,m,a)][[br]]
  - [#StrictTypeChecking StrictTypeChecking(m,a,p)][[br]]
@@ -20 +19 @@
  - [#Reflect Reflect(a)][[br]]
  - [#Replaceable Replaceable(a)][[br]]
- - [#Deletable Deletable(a), NotEnumerable(a), V8ReadOnly(a)][[br]]
+ - [#Deletable Deletable(a), NotEnumerable(a)][[br]]
  - [#CachedAttribute CachedAttribute(a)][[br]]
- - [#V8Unforgeable V8Unforgeable(m,a), V8OnProto(m,a)][[br]]
- - [#URL URL(a)][[br]]
  - [#JSWindowEventListener JSWindowEventListener(a)][[br]]
- - [#Supplemental Supplemental(i)][[br]]
  - [#Constructor Constructor(i), CallWith(i,m,a), ConstructorRaisesException(i)][[br]]
  - [#ConstructorTemplate ConstructorTemplate(i), InitializedByEventConstructor(a)][[br]]
  - [#NamedConstructor NamedConstructor(i)][[br]]
- - [#CustomConstructor CustomConstructor(i), JSCustomConstructor(i), V8CustomConstructor(i), ConstructorParameters(i)][[br]]
+ - [#CustomConstructor CustomConstructor(i), ConstructorParameters(i)][[br]]
  - [#Conditional Conditional(i,m,a)][[br]]
- - [#V8EnabledAtRuntime V8EnabledAtRuntime(i,m,a)][[br]]
- - [#V8EnabledPerContext V8EnabledPerContext(i,m,a)][[br]]
- - [#CustomToJSObject CustomToJSObject(i), JSCustomToJSObject(i), V8CustomToJSObject(i), SuppressToJSObject(i)][[br]]
  - [#CheckSecurity CheckSecurity(i), DoNotCheckSecurity(m,a), DoNotCheckSecurityOnGetter(a), DoNotCheckSecurityOnSetter(a)][[br]]
  - [#CheckSecurityForNode CheckSecurityForNode(m,a)][[br]]
  - [#IndexedGetter IndexedGetter(i)][[br]]
- - [#V8CustomIndexedGetter V8CustomIndexedGetter(i)][[br]]
  - [#CustomIndexedSetter CustomIndexedSetter(i)][[br]]
  - [#NamedGetter NamedGetter(i)][[br]]
@@ -45 +37 @@
  - [#DoNotCheckConstants DoNotCheckConstants(i)][[br]]
  - [#ActiveDOMObject ActiveDOMObject(i)][[br]]
- - [#V8DependentLifeTime V8DependentLifeTime(i)][[br]]
  - [#CustomEnumerateProperty CustomEnumerateProperty(i), CustomDeleteProperty(i)][[br]]
  - [#IsWorkerContext IsWorkerContext(i)][[br]]
- - [#TransferList TransferList(p)][[br]]
  - [#TypedArray TypedArray(i), [ConstructorTemplate=TypedArray](i)][[br]]
  - [#CustomCall CustomCall(i)][[br]]
- - [#JSCustomToNativeObject JSCustomToNativeObject(i), JSCustomFinalize(i), JSCustomIsReachable(i), JSCustomMarkFunction(i), JSCustomNamedGetterOnPrototype(i), JSCustomPushEventHandlerScope(i), JSCustomDefineOwnProperty(i), JSCustomDefineOwnPropertyOnPrototype(i), JSCustomGetOwnPropertySlotAndDescriptor(i)][[br]]
+ - [#JSCustomToNativeObject JSCustomToNativeObject(i), JSCustomFinalize(i), CustomIsReachable(i), JSCustomMarkFunction(i), JSCustomNamedGetterOnPrototype(i), JSCustomPushEventHandlerScope(i), JSCustomDefineOwnProperty(i), JSCustomDefineOwnPropertyOnPrototype(i), JSCustomGetOwnPropertySlotAndDescriptor(i)][[br]]
  - [#JSGenerateToJSObject JSGenerateToJSObject(i), JSGenerateToNativeObject(i)][[br]]
- - [#JSGenerateIsReachable JSGenerateIsReachable(i)]
- - [#V8GenerateIsReachable V8GenerateIsReachable(i)]
- - [#V8CustomIsReachable V8CustomIsReachable(i)]
  - [#GenerateIsReachable GenerateIsReachable(i)]
- - [#JSCustomHeader JSCustomHeader(i)][[br]]
  - [#JSLegacyParent JSLegacyParent(i)][[br]]
  - [#JSInlineGetOwnPropertySlot JSInlineGetOwnPropertySlot(i)][[br]]
@@ -65 +51 @@
  - [#CustomReturn CustomReturn(p)][[br]]
  - [#ArrayClass ArrayClass(i)][[br]]
- - [#OmitConstructor OmitConstructor, Immutable, MasqueradesAsUndefined, CustomGetOwnPropertySlot, ReplaceableConstructor, ExtendsDOMGlobalObject, IsIndex, V8DoNotCheckSignature, NumericIndexedGetter][[br]]
+ - [#OmitConstructor OmitConstructor, Immutable, MasqueradesAsUndefined, CustomGetOwnPropertySlot, ReplaceableConstructor, ExtendsDOMGlobalObject, IsIndex, NumericIndexedGetter][[br]]
  - [#ImplementationNamespace ImplementationNamespace(i)][[br]]
- - [#V8SkipVTableValidation V8SkipVTableValidation(i), ImplementationLacksVTable(i),][[br]]
+ - [#SkipVTableValidation SkipVTableValidation(i), ImplementationLacksVTable(i),][[br]]
+ - [#NoInterfaceObject NoInterfaceObject(i)][[br]]
 
 
 = Overview = #Overview
 
-The [http://www.w3.org/TR/WebIDL/ Web IDL] is a language that defines how WebCore interfaces are bound to external languages such as JavaScriptCore, V8, ObjC, GObject and CPP. You need to write IDL files (e.g. XMLHttpRequest.idl, Element.idl, etc) to expose WebCore interfaces to those external languages. When WebKit is built, the IDL files are parsed, and the code to bind WebCore implementations and JavaScriptCore, V8, ObjC, GObject and CPP interfaces is automatically generated.
+The [http://www.w3.org/TR/WebIDL/ Web IDL] is a language that defines how WebCore interfaces are bound to external languages such as JavaScriptCore, ObjC, GObject and CPP. You need to write IDL files (e.g. XMLHttpRequest.idl, Element.idl, etc) to expose WebCore interfaces to those external languages. When WebKit is built, the IDL files are parsed, and the code to bind WebCore implementations and JavaScriptCore, ObjC, GObject and CPP interfaces is automatically generated.
 
 This document describes practical information about how the IDL bindings work and how you can write IDL files in WebKit. The syntax of IDL files is fairly well documented in the [http://www.w3.org/TR/WebIDL/ Web IDL spec], but it is too formal to read:-) and there are several differences between the Web IDL spec and the WebKit IDL due to implementation issues.
@@ -81 +68 @@
 {{{
 module core {
-    interface [
-        JSCustomHeader,
+    [
         CustomToJSObject
-    ] Node {
+    ] interface Node {
         const unsigned short ELEMENT_NODE = 1;
         attribute Node parentNode;
-        attribute [TreatReturnedNullStringAs=Null] DOMString nodeName;
-        [Custom] Node appendChild(in [CustomReturn] Node newChild);
-        void addEventListener(in DOMString type, in EventListener listener, in [Optional] boolean useCapture);
+        [TreatReturnedNullStringAs=Null] attribute DOMString nodeName;
+        [Custom] Node appendChild([CustomReturn] Node newChild);
+        void addEventListener(DOMString type, EventListener listener, optional boolean useCapture);
     };
 }
@@ -101 +87 @@
  * appendChild(...) and addEventListener(...) are '''method'''s of the Node interface.
  * type, listener and useCapture are '''parameter'''s of the Node interface.
- * [JSCustomHeader], [CustomToJSObject], [TreatReturnedNullStringAs=Null], [Custom], [CustomReturn] and [Optional] are '''IDL attribute'''s.
+ * `[CustomToJSObject]`, `[TreatReturnedNullStringAs=Null]`, `[Custom]` and `[CustomReturn]` are '''IDL attribute'''s.
 
 Note: These terminologies are not aligned with the Web IDL spec.
@@ -119 +105 @@
 {{{
 module MODULE_NAME {
-    interface [
+    [
         IDL_ATTRIBUTE_ON_INTERFACE1,
         IDL_ATTRIBUTE_ON_INTERFACE2,
-        ...;
-    ] INTERFACE_NAME {
+        ...
+    ] interface INTERFACE_NAME {
         const unsigned long value = 12345;
-        attribute [IDL_ATTRIBUTE_ON_ATTRIBUTE1, IDL_ATTRIBUTE_ON_ATTRIBUTE2, ...] Node node;
-        [IDL_ATTRIBUTE_ON_METHOD1, IDL_ATTRIBUTE_ON_METHOD2, ...] void func(in [IDL_ATTRIBUTE_ON_PARAMETER1, IDL_ATTRIBUTE_ON_PARAMETER2, ...] int param, ...);
+        [IDL_ATTRIBUTE_ON_ATTRIBUTE1, IDL_ATTRIBUTE_ON_ATTRIBUTE2, ...] attribute Node node;
+        [IDL_ATTRIBUTE_ON_METHOD1, IDL_ATTRIBUTE_ON_METHOD2, ...] void func([IDL_ATTRIBUTE_ON_PARAMETER1, IDL_ATTRIBUTE_ON_PARAMETER2, ...] int param, ...);
     };
 }
@@ -136 +122 @@
     interface INTERFACE_NAME {
         const unsigned long value = 12345;
-        attribute [IDL_ATTRIBUTE_ON_ATTRIBUTE1, IDL_ATTRIBUTE_ON_ATTRIBUTE2, ...] Node node;
-        [IDL_ATTRIBUTE_ON_METHOD1, IDL_ATTRIBUTE_ON_METHOD2, ...] void func(in [IDL_ATTRIBUTE_ON_PARAMETER1, IDL_ATTRIBUTE_ON_PARAMETER2, ...] int param, ...);
+        [IDL_ATTRIBUTE_ON_ATTRIBUTE1, IDL_ATTRIBUTE_ON_ATTRIBUTE2, ...] attribute Node node;
+        [IDL_ATTRIBUTE_ON_METHOD1, IDL_ATTRIBUTE_ON_METHOD2, ...] void func([IDL_ATTRIBUTE_ON_PARAMETER1, IDL_ATTRIBUTE_ON_PARAMETER2, ...] int param, ...);
     };
 }
@@ -160 +146 @@
 Tools/Scripts/run-bindings-tests tests IDL attributes.
 Specifically, run-bindings-tests reads WebCore/bindings/scripts/test/*.idl,
-and then generates bindings code to WebCore/bindings/scripts/test/{JS,V8,ObjC,GObject,CPP}/*.
+and then generates bindings code to WebCore/bindings/scripts/test/{JS,ObjC,GObject,CPP}/*.
 For example, run-bindings-tests reads WebCore/bindings/scripts/test/TestObj.idl,
 and then generates bindings code to WebCore/bindings/scripts/test/JS/JSTestObj.h, WebCore/bindings/scripts/test/JS/JSTestObj.cpp, etc.
@@ -203 +189 @@
     WebKitBuild/Release/DerivedSources/WebCore/JSXXX.cpp
 }}}
- * V8:
-
-{{{
-    out/Release/obj/gen/webkit/bindings/V8XXX.h
-    out/Release/obj/gen/webcore/bindings/V8XXX.cpp
-}}}
  * ObjC:
 
@@ -234 +214 @@
  * A name should be aligned with the Web IDL spec as much as possible.
  * JavaScriptCore-specific IDL attributes are prefixed by "JS".
- * V8-specific IDL attributes are prefixed by "V8".
  * ObjC-specific IDL attributes are prefixed by "ObjC".
  * GObject-specific IDL attributes are prefixed by "GObject".
@@ -240 +219 @@
  * IDL attributes for custom bindings are prefixed by "Custom".
 
-For example, [JSNoStaticTables], [CustomGetter], [V8CustomGetter], etc.
+For example, `[JSNoStaticTables]`, `[CustomGetter]`, etc.
 
 = IDL attributes = #IDLAttributes
@@ -246 +225 @@
 In the following explanations, (i), (m), (a) or (p) means that a given IDL attribute can be specified on interfaces, methods, attributes and parameters, respectively. For example, (a,p) means that the IDL attribute can be specified on attributes and parameters.
 
-== [TreatNullAs](a,p), [TreatUndefinedAs](a,p) == #TreatNullAs
+== `[TreatNullAs]`(a,p), `[TreatUndefinedAs]`(a,p) == #TreatNullAs
 
  * [http://dev.w3.org/2006/webapi/WebIDL/#TreatNullAs The spec of TreatNullAs] (Note: The WebKit behavior explained below is different from the spec)
@@ -253 +232 @@
 Summary: They control the behavior when a JavaScript null or undefined is passed to a DOMString attribute or parameter.
 
-Usage: The possible usage is [TreatNullAs=NullString] or [TreatUndefinedAs=NullString].
+Usage: The possible usage is `[TreatNullAs=NullString]` or `[TreatUndefinedAs=NullString]`.
 They can be specified on DOMString attributes or DOMString parameters only:
 {{{
-    attribute [TreatNullAs=NullString] DOMString str;
-    void func(in [TreatNullAs=NullString, TreatUndefinedAs=NullString] DOMString str);
-}}}
-
-[TreatNullAs=NullString] indicates that if a JavaScript null is passed to the attribute or parameter,
+    [TreatNullAs=NullString] attribute DOMString str;
+    void func([TreatNullAs=NullString, TreatUndefinedAs=NullString] DOMString str);
+}}}
+
+`[TreatNullAs=NullString]` indicates that if a JavaScript null is passed to the attribute or parameter,
 then it is converted to a WebKit null string, for which both String::IsEmpty() and String::IsNull() will return true.
-Without [TreatNullAs=NullString], a JavaScript null is converted to a WebKit string "null".
-
-[TreatNullAs=NullString] in WebKit corresponds to [TreatNullAs=EmptyString] in the Web IDL spec.
-Unless the spec specifies [TreatNullAs=EmptyString], you should not specify [TreatNullAs=NullString] in WebKit.
-
-[TreatUndefinedAs=NullString] indicates that if a JavaScript undefined is passed to the attribute or parameter,
+Without `[TreatNullAs=NullString]`, a JavaScript null is converted to a WebKit string "null".
+
+`[TreatNullAs=NullString]` in WebKit corresponds to `[TreatNullAs=EmptyString]` in the Web IDL spec.
+Unless the spec specifies `[TreatNullAs=EmptyString]`, you should not specify `[TreatNullAs=NullString]` in WebKit.
+
+`[TreatUndefinedAs=NullString]` indicates that if a JavaScript undefined is passed to the attribute or parameter,
 then it is converted to a WebKit null string, for which both String::IsEmpty() and String::IsNull() will return true.
-Without [TreatUndefinedAs=NullString], a JavaScript undefined is converted to a WebKit string "undefined".
-
-[TreatUndefinedAs=NullString] in WebKit corresponds to [TreatUndefinedAs=EmptyString] in the Web IDL spec.
-Unless the spec specifies [TreatUndefinedAs=EmptyString], you should not specify [TreatUndefinedAs=NullString] in WebKit.
-
-Note: For now the sole usage of [TreatUndefinedAs=NullString] is not allowed.
-[TreatUndefinedAs=NullString] must be used with [TreatNullAs=NullString], i.e. [TreatNullAs=NullString, TreatUndefinedAs=NullString].
-
-== [TreatReturnedNullStringAs](m,a) == #TreatReturnedNullStringAs
-
-Summary: [TreatReturnedNullStringAs] controls the behavior when a WebKit null string is returned from the WebCore implementation.
-
-Usage: The possible usage is [TreatReturnedNullStringAs=Null], [TreatReturnedNullStringAs=Undefined] or [TreatReturnedNullStringAs=False].
+Without `[TreatUndefinedAs=NullString]`, a JavaScript undefined is converted to a WebKit string "undefined".
+
+`[TreatUndefinedAs=NullString]` in WebKit corresponds to `[TreatUndefinedAs=EmptyString]` in the Web IDL spec.
+Unless the spec specifies `[TreatUndefinedAs=EmptyString]`, you should not specify `[TreatUndefinedAs=NullString]` in WebKit.
+
+Note: For now the sole usage of `[TreatUndefinedAs=NullString]` is not allowed.
+`[TreatUndefinedAs=NullString]` must be used with `[TreatNullAs=NullString]`, i.e. `[TreatNullAs=NullString, TreatUndefinedAs=NullString]`.
+
+== `[TreatReturnedNullStringAs]`(m,a) == #TreatReturnedNullStringAs
+
+Summary: `[TreatReturnedNullStringAs]` controls the behavior when a WebKit null string is returned from the WebCore implementation.
+
+Usage: The possible usage is `[TreatReturnedNullStringAs=Null]`, `[TreatReturnedNullStringAs=Undefined]` or `[TreatReturnedNullStringAs=False]`.
 They can be specified on DOMString attributes or methods that return a DOMString value:
 {{{
-    attribute [TreatReturnedNullStringAs=Null] DOMString str;
+    [TreatReturnedNullStringAs=Null] attribute DOMString str;
     [TreatReturnedNullStringAs=Undefined] DOMString func();
 }}}
 
- * [TreatReturnedNullStringAs=Null] indicates that if the returned DOMString is a WebKit null string, the returned value is treated as a JavaScript null.
- * [TreatReturnedNullStringAs=Undefined] indicates that if the returned DOMString is a WebKit null string, the returned value is treated as a JavaScript undefined.
- * [TreatReturnedNullStringAs=False] indicates that if the returned DOMString is a WebKit null string, the returned value is treated as a JavaScript false.
-
-Without [TreatReturnedNullStringAs=...], if the returned DOMString is a WebKit null string, then the returned value is treated as a JavaScript empty string ''.
-
-Note that what should be specified on [TreatReturnedNullStringAs=...] depends on the spec of each attribute or method.
-
-== [Optional](p) == #Optional
-
-Summary: [Optional] allows method overloading for methods whose argument counts are different with each other.
-
-Usage: The possible usage is [Optional], [Optional=DefaultIsUndefined] or [Optional=DefaultIsNullString].
-[Optional] and [Optional=DefaultIsUndefined] can be specified on parameters.
-[Optional=DefaultIsNullString] can be specified on DOMString parameters only:
+ * `[TreatReturnedNullStringAs=Null]` indicates that if the returned DOMString is a WebKit null string, the returned value is treated as a JavaScript null.
+ * `[TreatReturnedNullStringAs=Undefined]` indicates that if the returned DOMString is a WebKit null string, the returned value is treated as a JavaScript undefined.
+ * `[TreatReturnedNullStringAs=False]` indicates that if the returned DOMString is a WebKit null string, the returned value is treated as a JavaScript false.
+
+Without `[TreatReturnedNullStringAs=...]`, if the returned DOMString is a WebKit null string, then the returned value is treated as a JavaScript empty string ''.
+
+Note that what should be specified on `[TreatReturnedNullStringAs=...]` depends on the spec of each attribute or method.
+
+== `[Default]`(p) == #Default
+
+Summary: `[Default]` allows specifying the default values for optional parameters to simplify WebCore implementations which otherwise require overloads.
+
+Standard: In Web IDL, `[Default=NullString]` is written as `"type identifier = default"`, e.g. `optional DOMString? str = null`
+
+Usage: The possible usages are `[Default=Undefined]` or `[Default=NullString]`. `[Default=Undefined]` can be specified on any optional parameter. `[Default=NullString]` can be specified on DOMString parameters only:
+
 {{{
     interface HTMLFoo {
-        void func1(in int a, in int b, in [Optional] int c, in [Optional] int d);
-        void func2(in int a, in int b, in [Optional=DefaultIsUndefined] int c);
-        void func3(in int a, in int b, in [Optional=DefaultIsUndefined] DOMString c, in [Optional=DefaultIsNullString] DOMString d);
-    };
-}}}
-
-The parameters marked with [Optional=...] are optional, and JavaScript can omit the parameters. Obviously, if parameter X is marked with [Optional=...], then all subsequent parameters of X should be marked with [Optional=...].
-
-The difference between [Optional] and [Optional=DefaultIsUndefined] is whether the WebCore implementation has overloaded methods or not, as explained below.
-
-In case of func1(...), if JavaScript calls func1(100, 200), then HTMLFoo::func1(int a, int b) is called in WebCore.
-If JavaScript calls func1(100, 200, 300), then HTMLFoo::func1(int a, int b, int c) is called in WebCore.
-If JavaScript calls func1(100, 200, 300, 400), then HTMLFoo::func1(int a, int b, int c, int d) is called in WebCore.
-In other words, if the WebCore implementation has overloaded methods, you can use [Optional].
-
-In case of func2(...), if JavaScript calls func2(100, 200), then it behaves as if JavaScript called func2(100, 200, undefined).
-Consequently, HTMLFoo::func2(int a, int b, int c) is called in WebCore.
-100 is passed to a, 200 is passed to b, and 0 is passed to c.
-(A JavaScript undefined is converted to 0, following the value conversion rule in the Web IDL spec.)
-In this way, WebCore needs to just implement func2(int a, int b, int c) and needs not to implement both func2(int a, int b) and func2(int a, int b, int c).
-
-The difference between [Optional=DefalutIsUndefined] and [Optional=DefaultIsNullString] appears only when the parameter type is DOMString.
-In [Optional=DefalutIsUndefined], the "supplemented" JavaScript undefined is converted to a WebKit string "undefined".
-On the other hand, in [Optional=DefaultIsNullString], the "supplemented" JavaScript undefined is converted to a WebKit null string.
-For example, if JavaScript calls func3(100, 200), then HTMLFoo::func3(int a, int b, String c, String d) is called in WebCore.
-At this point, 100 is passed to a, 200 is passed to b, a WebKit string "undefined" is passed to c, and a WebKit null string is passed to d.
-d.IsEmpty() and d.IsNull() return true.
-
-== [Clamp](a,p) == #Clamp
+        void func1(int a, int b, optional int c, optional int d);
+        void func2(int a, int b, [Default=Undefined] optional int c);
+        void func3(int a, int b, [Default=Undefined] optional DOMString c, [Default=NullString] optional DOMString d);
+    };
+}}}
+
+The parameters marked with the standard Web IDL optional qualifier are optional, and JavaScript can omit the parameters. Obviously, if parameter X is marked with optional then all subsequent parameters of X should be marked with optional.
+
+The difference between optional and `[Default=Undefined]` optional is whether the WebCore implementation has overloaded methods or not, as explained below.
+
+In case of `func1(...)`, if JavaScript calls `func1(100, 200)`, then `HTMLFoo::func1(int a, int b)` is called in WebCore. If JavaScript calls `func1(100, 200, 300)`, then `HTMLFoo::func1(int a, int b, int c)` is called in WebCore. If JavaScript calls `func1(100, 200, 300, 400)`, then `HTMLFoo::func1(int a, int b, int c, int d)` is called in WebCore. In other words, if the WebCore implementation has overloaded methods, you can use optional.
+
+In case of `func2(...)` which adds `[Default=Undefined]`, if JavaScript calls `func2(100, 200)`, then it behaves as if JavaScript called `func2(100, 200, undefined)`. Consequently, `HTMLFoo::func2(int a, int b, int c)` is called in WebCore. 100 is passed to a, 200 is passed to b, and 0 is passed to c. (A JavaScript undefined is converted to 0, following the value conversion rule in the Web IDL spec.) In this way, WebCore needs to just implement `func2(int a, int b, int c)` and needs not to implement both `func2(int a, int b)` and `func2(int a, int b, int c)`.
+
+The difference between `[Default=Undefined]` and `[Default=NullString]` appears only when the parameter type is DOMString. In `[Default=Undefined]` the "supplemented" JavaScript undefined is converted to a WebKit string "undefined". On the other hand, in `[Default=NullString]` the "supplemented" JavaScript undefined is converted to a WebKit null string. For example, if JavaScript calls `func3(100, 200)`, then `HTMLFoo::func3(int a, int b, String c, String d)` is called in WebCore. At this point, 100 is passed to a, 200 is passed to b, a WebKit string "undefined" is passed to c, and a WebKit null string is passed to d. d.IsEmpty() and d.IsNull() return true.
+
+== `[Clamp]`(a,p) == #Clamp
 
  * [http://www.w3.org/TR/2012/CR-WebIDL-20120419/#Clamp The spec of Clamp]
 
-Summary: [Clamp] 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, 
+Summary: `[Clamp]` 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.).
 
-Usage: The [Clamp] extended attribute MUST NOT appear on a read only attribute, or an attribute, operation argument or dictionary member 
+Usage: 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.
 
@@ -347 +315 @@
 {{{
     interface XXX {
-        attribute [Clamp] unsigned short attributeName;
+        [Clamp] attribute unsigned short attributeName;
     };
 }}}
@@ -360 +328 @@
 }}}
 
-Calling the non-[Clamp] version of setColor() uses ToUint8 to coerce the Numbers to octets.
-Hence calling context.setColor(-1, 255, 257) is equivalent to calling setColor(255, 255, 1).
-
-Calling the [Clamp] version of setColor() uses clampTo() to coerce the Numbers to octets.
-Hence calling context.setColor(-1, 255, 257) is equivalent to calling setColorClamped(0, 255, 255).
-
-== [Callback](i,p) FIXME == #Callback
-
-Summary: ADD SUMMARY
-
-Usage: [Callback] can be specified on interfaces and parameters:
-{{{
-    interface [
-        Callback
-    ] HTMLFoo {
-        void func(in int a, in [Callback] int b);
-    };
-}}}
-
-ADD EXPLANATIONS
-
-== [Custom](m,a), [JSCustom](m,a), [V8Custom](m,a), [CustomGetter](a), [JSCustomGetter](a), [V8CustomGetter](a), [CustomSetter](a), [JSCustomSetter](a), [V8CustomSetter](a) == #Custom
+Calling the non-`[Clamp]` version of `setColor()` uses ToUint8 to coerce the Numbers to octets.
+Hence calling `context.setColor(-1, 255, 257)` is equivalent to calling `setColor(255, 255, 1)`.
+
+Calling the `[Clamp]` version of `setColor()` uses `clampTo()` to coerce the Numbers to octets.
+Hence calling `context.setColor(-1, 255, 257)` is equivalent to calling `setColorClamped(0, 255, 255)`.
+
+== `[Custom]`(m,a), `[CustomGetter]`(a), `[CustomSetter]`(a) == #Custom
 
 Summary: They allow you to write bindings code manually as you like.
 
-Usage: [Custom], [JSCustom] and [V8Custom] can be specified on methods or attributes. [CustomGetter], [JSCustomGetter], [V8CustomGetter], [CustomSetter], [JSCustomSetter], [V8CustomSetter] can be specified on attributes:
+Usage: `[Custom]` can be specified on methods or attributes. `[CustomGetter]`, `[CustomSetter]` can be specified on attributes:
 {{{
     [Custom] void func();
-    attribute [CustomGetter, JSCustomSetter] DOMString str;
+    [CustomGetter, JSCustomSetter] attribute DOMString str;
 }}}
 
 We should minimize the number of custom bindings as much as possible, since they are likely to be buggy.
-Before using [Custom], you should doubly consider if you really need custom bindings.
-You are recommended to modify code generators to avoid using [Custom].
+Before using `[Custom]`, you should doubly consider if you really need custom bindings.
+You are recommended to modify code generators to avoid using `[Custom]`.
 
 Before explaining the details, let us clarify the relationship of these IDL attributes.
 
- * [JSCustom] on a method indicates that you can write JavaScriptCore custom bindings for the method.
- * [V8Custom] on a method indicates that you can write V8 custom bindings for the method.
- * [Custom] on a method is equivalent to [JSCustom, V8Custom].
- * [JSCustomGetter] or [JSCustomSetter] on an attribute indicates that you can write JavaScriptCore custom bindings for the attribute getter or setter.
- * [V8CustomGetter] or [V8CustomSetter] on an attribute indicates that you can write V8 custom bindings for the attribute getter or setter.
- * [JSCustom] on an attribute is equivalent to [JSCustomGetter, JSCustomSetter].
- * [V8Custom] on an attribute is equivalent to [V8CustomGetter, V8CustomSetter].
- * [Custom] on an attribute is equivalent to [JSCustom, V8Custom], i.e. [JSCustomGetter, JSCustomSetter, V8CustomGetter, V8CustomSetter].
-
-For example, if you want to write custom bindings only for an attribute getter of JavaScriptCore and V8 and an attribute setter of JavaScriptCore, you can specify [CustomGetter, JSCustomSetter].
-
-How to write custom bindings is different between JavaScriptCore and V8 or between a method and an attribute getter/setter, as follows:
-
- * Method in JavaScriptCore: Consider the following example:
+ * `[Custom]` on a method indicates that you can write JavaScriptCore custom bindings for the method.
+ * `[CustomGetter]` or `[CustomSetter]` on an attribute indicates that you can write JavaScriptCore custom bindings for the attribute getter or setter.
+
+You can write custom bindings with JavaScriptCore for a method or an attribute getter/setter, as follows:
+
+ * Method: Consider the following example:
 
 {{{
     interface XXX {
-        [JSCustom] void func(in int a, in int b);
+        [Custom] void func(int a, int b);
     };
 }}}
@@ -426 +371 @@
 Refer to WebCore/bindings/js/JSXXXCustom.cpp for more details.
 
- * Attribute getter in JavaScriptCore: Consider the following example:
+ * Attribute getter: Consider the following example:
 
 {{{
     interface XXX {
-        attribute [JSCustomGetter] DOMString str;
+        [CustomGetter] attribute DOMString str;
     };
 }}}
@@ -442 +387 @@
 Refer to WebCore/bindings/js/JSXXXCustom.cpp for more details.
 
- * Attribute setter in JavaScriptCore: Consider the following example:
+ * Attribute setter: Consider the following example:
 
 {{{
     interface XXX {
-        attribute [JSCustomSetter] DOMString str;
+        [CustomSetter] attribute DOMString str;
     };
 }}}
@@ -456 +401 @@
     }
 }}}
-Refer to WebCore/bindings/js/JSXXXCustom.cpp for more details.
-
- * Method in V8: Consider the following example:
-
-{{{
-    interface XXX {
-        [V8Custom] void func(in int a, in int b);
-    };
-}}}
-You can write custom bindings in WebCore/bindings/v8/custom/V8XXXCustom.cpp:
-{{{
-    v8::Handle<v8::Value> V8XXX::funcCallback(const v8::Arguments& args)
-    {
-        ...;
-    }
-}}}
-Refer to WebCore/bindings/v8/custom/V8XXXCustom.cpp for more details.
-
- * Attribute getter in V8: Consider the following example:
-
-{{{
-    interface XXX {
-        attribute [V8CustomGetter] DOMString str;
-    };
-}}}
-You can write custom bindings in WebCore/bindings/v8/custom/V8XXXCustom.cpp:
-{{{
-    v8::Handle<v8::Value> V8XXX::strAccessorGetter(v8::Local<v8::String> name, const v8::AccessorInfo& info)
-    {
-        ...;
-    }
-}}}
-Refer to WebCore/bindings/v8/custom/V8XXXCustom.cpp for more details.
-
- * Attribute setter in V8: Consider the following example:
-
-{{{
-    interface XXX {
-        attribute [V8CustomSetter] DOMString str;
-    };
-}}}
-You can write custom bindings in WebCore/bindings/v8/custom/V8XXXCustom.cpp:
-{{{
-    void V8XXX::strAccessorSetter(v8::Local<v8::String> name, v8::Local<v8::Value> value, const v8::AccessorInfo& info)
-    {
-        ...;
-    }
-}}}
-Refer to WebCore/bindings/v8/custom/V8XXXCustom.cpp for more details.
 
 Note: ObjC, GObject and CPP bindings do not support custom bindings.
 
-== [CallWith](i,m,a) == #CallWith
-
-Summary: [CallWith] indicates that the bindings code calls a WebCore method with additional information.
-
-Usage: The possible usage is [CallWith=X1|X2|X3|...], where X1, X2, X3, ... is "ScriptExecutionContext", "ScriptState", "ScriptArguments" or "CallStack".
+== `[CallWith]`(i,m,a) == #CallWith
+
+Summary: `[CallWith]` indicates that the bindings code calls a WebCore method with additional information.
+
+Usage: The possible usage is `[CallWith=X1|X2|X3|...]`, where X1, X2, X3, ... is "ScriptExecutionContext", "ScriptState", "ScriptArguments" or "CallStack".
 "ScriptExecutionContext", "ScriptState" and "CallStack" can be specified on methods or attributes,
 but "ScriptArguments" can be specified on methods only:
 {{{
     interface HTMLFoo {
-        attribute [CallWith=ScriptExecutionContext] DOMString str;
-        [CallWith=ScriptExecutionContext] void func1(in int a, in int b);
-        [CallWith=ScriptState] void func2(in int a, in int b);
-        [CallWith=ScriptArguments|CallStack] void func3(in int a, in int b);
-        [CallWith=CallStack|ScriptArguments] void func4(in int a, in int b);
-    };
-}}}
-
-Note: [CallWith] can be also specified on interfaces but it has a different meaning.
-Refer to [#Constructor the [Constructor] section] for [CallWith] on interfaces.
+        [CallWith=ScriptExecutionContext] attribute DOMString str;
+        [CallWith=ScriptExecutionContext] void func1(int a, int b);
+        [CallWith=ScriptState] void func2(int a, int b);
+        [CallWith=ScriptArguments|CallStack] void func3(int a, int b);
+        [CallWith=CallStack|ScriptArguments] void func4(int a, int b);
+    };
+}}}
+
+Note: `[CallWith]` can be also specified on interfaces but it has a different meaning.
+Refer to [#Constructor the `[Constructor]` section] for `[CallWith]` on interfaces.
 
 In case of func1(...), HTMLFoo::func1(ScriptExecutionContext* context, int a, int b) is called in WebCore.
@@ -537 +433 @@
 In this way, the additional information is added at the head of normal arguments.
 The order of additional information is "ScriptExecutionContext", "ScriptState", "ScriptArguments", and then "CallStack",
-despite the order specified in [CallWith=X1|X2|X3|...].
-For example, in case of func4(...), HTMLFoo::func3(ScriptArguments* arguments, ScriptCallStack* callstack, int a, int b) is called in WebCore.
-
-== [StrictTypeChecking](m,a,p) FIXME == #StrictTypeChecking
+despite the order specified in `[CallWith=X1|X2|X3|...]`.
+For example, in case of `func4(...)`, `HTMLFoo::func3(ScriptArguments* arguments, ScriptCallStack* callstack, int a, int b)` is called in WebCore.
+
+== `[StrictTypeChecking]`(m,a,p) FIXME == #StrictTypeChecking
 
 Summary: ADD SUMMARY
 
-Usage: [StrictTypeChecking] can be specified on methods and attributes:
-{{{
-    attribute [StringTypeChecking] float x;
+Usage: `[StrictTypeChecking]` can be specified on methods and attributes:
+{{{
+    [StringTypeChecking] attribute float x;
     [StrictTypeChecking] DOMString func();
 }}}
@@ -552 +448 @@
 ADD EXPLANATIONS
 
-V8 and JSC: [StrictTypeChecking] can also be applied to a DOMString parameter in an overloaded method to make the
+JSC: `[StrictTypeChecking]` can also be applied to a DOMString parameter in an overloaded method to make the
 overload resolution only match for ECMAScript types null, undefined, string or object - and not number or boolean.
 This is to permit overloads which are not "distinguishable" in WebIDL, for example:
@@ -558 +454 @@
 {{{
     interface CanvasFoo {
-        void setColor(in [StrictTypeChecking] DOMString color);
-        void setColor(in float grayLevel);
-    };
-}}}
-
-== [ReturnNewObject](m,a) == #ReturnNewObject
-
-Summary: [ReturnNewObject] controls whether WebCore can return a cached wrapped object or WebCore needs to return a newly created wrapped object every time.
-
-Usage: [ReturnNewObject] can be specified on methods or attributes:
-{{{
-    attribute [ReturnNewObject] Node node;
+        void setColor([StrictTypeChecking] DOMString color);
+        void setColor(float grayLevel);
+    };
+}}}
+
+== `[ReturnNewObject]`(m,a) == #ReturnNewObject
+
+Summary: `[ReturnNewObject]` controls whether WebCore can return a cached wrapped object or WebCore needs to return a newly created wrapped object every time.
+
+Usage: `[ReturnNewObject]` can be specified on methods or attributes:
+{{{
+    [ReturnNewObject] attribute Node node;
     [ReturnNewObject] Node createTextNode();
 }}}
 
-Without [ReturnNewObject], JavaScriptCore and V8 cache a wrapped object for performance.
-For example, consider the case where node.firstChild is accessed:
-
- 1. Node::firstChild() is called in WebCore.
- 1. The result of Node::firstChild() is passed to toJS() or toV8().
- 1. toJS() or toV8() checks if a wrapped object of the result is already cached on the node.
+Without `[ReturnNewObject]`, JavaScriptCore cache a wrapped object for performance.
+For example, consider the case where `node.firstChild` is accessed:
+
+ 1. `Node::firstChild()` is called in WebCore.
+ 1. The result of `Node::firstChild()` is passed to `toJS()`.
+ 1. `toJS()` checks if a wrapped object of the result is already cached on the node.
  1. If cached, the cached wrapped object is returned. That's it.
- 1. Otherwise, toJS() or toV8() creates the wrapped object of the result.
+ 1. Otherwise, `toJS()` creates the wrapped object of the result.
  1. The created wrapped object is cached on the node.
  1. The wrapped object is returned.
 
 On the other hand, if you do not want to cache the wrapped object and want to create the wrapped object every time,
-you can specify [ReturnNewObject].
-
-== [ImplementedAs](m,a) == #ImplementedAs
-
-Summary: [ImplementedAs] specifies a method name in WebCore, if the method name in an IDL file and the method name in WebCore are different.
-
-Usage: The possible usage is [ImplementedAs=XXX], where XXX is a method name in WebCore.
-[ImplementedAs] can be specified on methods:
+you can specify `[ReturnNewObject]`.
+
+== `[ImplementedAs]`(m,a) == #ImplementedAs
+
+Summary: `[ImplementedAs]` specifies a method name in WebCore, if the method name in an IDL file and the method name in WebCore are different.
+
+Usage: The possible usage is `[ImplementedAs=XXX]`, where `XXX` is a method name in WebCore.
+`[ImplementedAs]` can be specified on methods:
 {{{
     [ImplementedAs=deleteFunction] void delete();
-    attribute [ImplementedAs=classAttribute] int class;
+    [ImplementedAs=classAttribute] attribute int class;
 }}}
 
 Basically a method name in WebCore should be the same as the method name in an IDL file.
 That being said, sometimes you cannot use the same method name; e.g. "delete" is reserved for a C++ keyword.
-In such cases, you can explicitly specify the method name in WebCore by [ImplementedAs].
-You should avoid using [ImplementedAs] as much as possible though.
-
-== [Reflect](a) == #Reflect
+In such cases, you can explicitly specify the method name in WebCore by `[ImplementedAs]`.
+You should avoid using `[ImplementedAs]` as much as possible though.
+
+== `[Reflect]`(a) == #Reflect
 
  * [http://www.whatwg.org/specs/web-apps/current-work/multipage/common-dom-interfaces.html#reflect The spec of Reflect]
 
-Summary: [Reflect] indicates that a given attribute should reflect the values of a corresponding content attribute.
-
-Usage: The possible usage is [Reflect] or [Reflect=X], where X is the name of a corresponding content attribute.
-[Reflect] can be specified on attributes:
+Summary: `[Reflect]` indicates that a given attribute should reflect the values of a corresponding content attribute.
+
+Usage: The possible usage is `[Reflect]` or `[Reflect=X]`, where `X` is the name of a corresponding content attribute.
+`[Reflect]` can be specified on attributes:
 {{{
     interface Element {
-        attribute [Reflect] DOMString id;
-        attribute [Reflect=class] DOMString className;
+        [Reflect] attribute DOMString id;
+        [Reflect=class] attribute DOMString className;
     };
 }}}
@@ -624 +520 @@
 Here 'id' and 'class' are content attributes.
 
-If a given attribute in an IDL file is marked as [Reflect],
+If a given attribute in an IDL file is marked as `[Reflect]`,
 it indicates that the attribute getter returns the value of the corresponding content attribute
 and that the attribute setter sets the value of the corresponding content attribute.
@@ -630 +526 @@
 
 If the name of the corresponding content attribute is different from the attribute name in an IDL file,
-you can specify the content attribute name by [Reflect=X].
-For example, in case of [Reflect=class], if 'div.className="barClass"' is evaluated, then "barClass" is set to the 'class' content attribute.
-
-Whether [Reflect] should be specified or not depends on the spec of each attribute.
-
-== [Replaceable](a) == #Replaceable
+you can specify the content attribute name by `[Reflect=X]`.
+For example, in case of `[Reflect=class]`, if `'div.className="barClass"'` is evaluated, then "barClass" is set to the 'class' content attribute.
+
+Whether `[Reflect]` should be specified or not depends on the spec of each attribute.
+
+== `[Replaceable]`(a) == #Replaceable
 
  * [http://dev.w3.org/2006/webapi/WebIDL/#Replaceable The spec of Replaceable]
 
-Summary: [Replaceable] controls if a given attribute is "replaceable" or not.
-
-Usage: [Replaceable] can be specified on attributes:
+Summary: `[Replaceable]` controls if a given attribute is "replaceable" or not.
+
+Usage: `[Replaceable]` can be specified on attributes:
 {{{
     interface DOMWindow {
-        attribute [Replaceable] screenX;
+        [Replaceable] attribute screenX;
     };
 }}}
@@ -651 +547 @@
 If you delete the new value, then the original value still remains.
 
-Specifically, without [Replaceable], the attribute behaves as follows:
+Specifically, without `[Replaceable]`, the attribute behaves as follows:
 {{{
     window.screenX; // Evaluates to 0
@@ -660 +556 @@
 }}}
 
-With [Replaceable], the attribute behaves as follows:
+With `[Replaceable]`, the attribute behaves as follows:
 {{{
     window.screenX; // Evaluates to 0
@@ -669 +565 @@
 }}}
 
-Whether [Replaceable] should be specified or not depends on the spec of each attribute.
-
-== [Deletable](a), [NotEnumerable](a), [V8ReadOnly](a) == #Deletable
+Whether `[Replaceable]` should be specified or not depends on the spec of each attribute.
+
+== `[Deletable]`(a), `[NotEnumerable]`(a)`(a) == #Deletable
 
  * [http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf The spec of Writable, Enumerable and Configurable (Section 8.6.1)]
 
-Summary: They control Writability, Enumerability and Configurability of attributes.
+Summary: They control `Writability`, `Enumerability` attributes (`readonly` keyword controls the `Configurability` attributes).
 
 Usage: They can be specified on attributes:
 {{{
-    attribute [NotEnumerable, Deletable] DOMString str;
+    [NotEnumerable, Deletable] attribute DOMString str;
     readonly attribute DOMString readonlyStr;
-    attribute [V8ReadOnly] DOMString readonlyStrOnV8;
-}}}
-
-By default, non-"readonly" attributes are enumerable, writable and not deletable. "readonly" attributes are enumerable, not writable and not deletable. You can change the default behavior using [Deletable], [NotEnumerable] or [V8ReadOnly].
-
- * [Deletable] indicates that the attribute is deletable.
- * [NotEnumerable] indicates that the attribute is not enumerable.
- * [V8ReadOnly] indicates that the attribute is readonly in V8 even if the attribute is not prefixed by "readonly".
-
-== [CachedAttribute](a) == #CachedAttribute
-
-Summary: For performance optimization, [CachedAttribute] indicates that a wrapped object should be cached on a DOM object.
-
-Usage: [CachedAttribute] can be specified on attributes:
+}}}
+
+By default, non-"readonly" attributes are enumerable, writable and not deletable. "readonly" attributes are enumerable, not writable and not deletable. You can change the default behavior using `[Deletable]`, `[NotEnumerable]` or `readonly`.
+
+ * `[Deletable]` indicates that the attribute is deletable.
+ * `[NotEnumerable]` indicates that the attribute is not enumerable.
+ * `readonly` indicates that the attribute is read only.
+
+== `[CachedAttribute]`(a) == #CachedAttribute
+
+Summary: For performance optimization, `[CachedAttribute]` indicates that a wrapped object should be cached on a DOM object.
+
+Usage: `[CachedAttribute]` can be specified on attributes:
 {{{
     interface HTMLFoo {
-        attribute [CachedAttribute] DOMString normalValue;
-        attribute [CachedAttribute] SerializedScriptValue serializedValue;
-    };
-}}}
-
-Without [CachedAttribute], the normalValue getter works in the following way:
-
- 1. HTMLFoo::normalValue() is called in WebCore.
- 1. The result of HTMLFoo::normalValue() is passed to toJS() or toV8(), and is converted to a wrapped object.
+        [CachedAttribute] attribute DOMString normalValue;
+        [CachedAttribute] attribute SerializedScriptValue serializedValue;
+    };
+}}}
+
+Without `[CachedAttribute]`, the normalValue getter works in the following way:
+
+ 1. `HTMLFoo::normalValue()` is called in WebCore.
+ 1. The result of `HTMLFoo::normalValue()` is passed to `toJS()`, and is converted to a wrapped object.
  1. The wrapped object is returned.
 
-In case where HTMLFoo::normalValue() or the operation to wrap the result is weight,
+In case where `HTMLFoo::normalValue()` or the operation to wrap the result is weight,
 you can cache the wrapped object onto the DOM object.
-With [CachedAttribute], the normalValue getter works in the following way:
+With `[CachedAttribute]`, the normalValue getter works in the following way:
 
  1. If the wrapped object is cached, the cached wrapped object is returned. That's it.
- 1. Otherwise, HTMLFoo::normalValue() is called in WebCore.
- 1. The result of HTMLFoo::normalValue() is passed to toJS() or toV8(), and is converted to a wrapped object.
+ 1. Otherwise, `HTMLFoo::normalValue()` is called in WebCore.
+ 1. The result of `HTMLFoo::normalValue()` is passed to `toJS()`, and is converted to a wrapped object.
  1. The wrapped object is cached.
  1. The wrapped object is returned.
 
-In particular, [CachedAttribute] will be useful for serialized values, since deserialization can be weight.
-Without [CachedAttribute], the serializedValue getter works in the following way:
-
- 1. HTMLFoo::serializedValue() is called in WebCore.
- 1. The result of HTMLFoo::serializedValue() is deserialized.
- 1. The deserialized result is passed to toJS() or toV8(), and is converted to a wrapped object.
+In particular, `[CachedAttribute]` will be useful for serialized values, since deserialization can be weight.
+Without `[CachedAttribute]`, the serializedValue getter works in the following way:
+
+ 1. `HTMLFoo::serializedValue()` is called in WebCore.
+ 1. The result of `HTMLFoo::serializedValue()` is deserialized.
+ 1. The deserialized result is passed to `toJS()`, and is converted to a wrapped object.
  1. The wrapped object is returned.
 
-In case where HTMLFoo::serializedValue(), the deserialization or the operation to wrap the result is weight,
+In case where `HTMLFoo::serializedValue()`, the deserialization or the operation to wrap the result is weight,
 you can cache the wrapped object onto the DOM object.
-With [CachedAttribute], the serializedValue getter works in the following way:
+With `[CachedAttribute]`, the serializedValue getter works in the following way:
 
  1. If the wrapped object is cached, the cached wrapped object is returned. That's it.
- 1. Otherwise, HTMLFoo::serializedValue() is called in WebCore.
- 1. The result of HTMLFoo::serializedValue() is deserialized.
- 1. The deserialized result is passed to toJS() or toV8(), and is converted to a wrapped object.
+ 1. Otherwise, `HTMLFoo::serializedValue()` is called in WebCore.
+ 1. The result of `HTMLFoo::serializedValue()` is deserialized.
+ 1. The deserialized result is passed to `toJS()`, and is converted to a wrapped object.
  1. The wrapped object is cached.
  1. The wrapped object is returned.
@@ -742 +637 @@
 In addition, setters always need to invalidate the cache.
 
-== [V8Unforgeable](m,a), [V8OnProto](m,a) == #V8Unforgeable
-
- * [http://dev.w3.org/2006/webapi/WebIDL/#Unforgeable The spec of Unforgeable]
-
-Summary: They control where a getter/setter of a given attribute is defined.
-
-Usage: They can be specified on methods or attributes:
-{{{
-    [V8Unforgeable] void func();
-    attribute [V8OnProto] DOMString str;
-}}}
-
-By default in JSC and V8, attribute getters/setters are defined on a DOM object, and methods are defined on a prototype chain 
-(although the Web IDL spec requires that both attribute getters/setters and methods should be defined on a prototype chain).
-
-If you want to explicitly control where an attribute getter/setter or a method is defined in V8,
-you can use [V8Unforgeable] or [V8OnProto].
-
- * [V8Unforgeable] indicates that an attribute getter/setter or a method should be defined on a DOM object.
- * [V8OnProto] indicates that an attribute getter/setter or a method should be defined on a prototype chain.
-
-Note: As explained above, the current implementation of JSC and V8 is wrong with the Web IDL spec,
-and [V8Unforgeable] and [V8OnProto] are used for hack.
-You should not use them unless you have a strong reason to use them.
-
-== [URL](a) == #URL
-
-Summary: [URL] indicates that a given DOMString represents a URL.
-
-Usage: [URL] can be specified on DOMString attributes only:
-{{{
-    attribute [Reflect, URL] DOMString url;
-}}}
-
-You need to specify [URL] if a given DOMString represents a URL,
-since getters of URL attributes need to be realized in a special routine in WebKit, i.e. Element::getURLAttribute(...).
-If you forgot to specify [URL], then the attribute getter might cause a bug.
-
-== [JSWindowEventListener](a) FIXME == #JSWindowEventListener
+== `[JSWindowEventListener]`(a) FIXME == #JSWindowEventListener
 
 Summary: ADD SUMMARY
 
-Usage: [JSWindowEventListener] can be specified on EventListener attributes only:
-{{{
-    attribute [JSWindowEventListener] EventListener onload;
+Usage: `[JSWindowEventListener]` can be specified on `EventListener` attributes only:
+{{{
+    [JSWindowEventListener] attribute EventListener onload;
 }}}
 
 ADD EXPLANATIONS
 
-== [Supplemental](i) == #Supplemental
-
- * [http://dev.w3.org/2006/webapi/WebIDL/#dfn-supplemental-interface The spec of Supplemental]
-
- * [http://old.nabble.com/Things-missing-from-Web-IDL-for-HTML5-td24873773.html Easy explanation of Supplemental]
-
-Summary: [Supplemental] helps WebKit modularization.
-[Supplemental] makes it possible to add XXX's APIs (e.g. XXX=WebAudio, WebSocket, Blob, GamePad, ...etc) without modifying code outside of WebCore/Modules/XXX/.
-This helps make XXX a "self-contained module".
-
-Usage: The possible usage is
-{{{
-    interface [
-        Supplemental=YYY
-    ] XXX {
-    };
-}}}
-where XXX implements YYY.
-[Supplemental] can be specified on interfaces.
-
-Without [Supplemental], if you want to add XXX's attributes or methods to DOMWindow,
-
- * you need to modify WebCore/page/DOMWindow.idl to add the XXX's attributes or methods
-
- * you need to modify WebCore/page/DOMWindow.{h,cpp} to add the WebCore implementation of the attribute getters and setters or the method callbacks.
-
-On the other hand, in the modularized world with [Supplemental], you just need to modify the code under WebCore/Modules/XXX/:
-
- * WebCore/Modules/XXX/DOMWindowXXX.idl
-
-{{{
-   interface [
-       Conditional=XXX,
-       Supplemental=DOMWindow    // The attributes and methods of this interface are exposed as those of DOMWindow.
-   ] DOMWindowXXX {
-       attribute int foo;
-       void bar();
-   };
-}}}
-
- * WebCore/Modules/XXX/DOMWindowXXX.h
-
-{{{
-   DOMWindowXXX::foo(...) { ... }   // The WebCore implementation of the foo attribute getter.
-   DOMWindowXXX::setFoo(...) { ... }   // The WebCore implementation of the foo attribute setter.
-   DOMWindowXXX::bar(...) { ... }   // The WebCore implementation of the bar() method callback.
-}}}
-
-As shown above, [Supplemental=DOMWindow] indicates that all the attributes and methods of DOMWindowXXX should be exposed on DOMWindow,
-but should be implemented in DOMWindowXXX.
-In this way, you can implement the attributes and methods without modifying code of DOMWindow.{h,cpp,idl}.
-
-If you want to add APIs whose implementations are likely to be independent from WebCore,
-it is strongly recommended to put the APIs and .h/.cpp files into WebCore/Modules/XXX/ using [Supplemental].
-On the other hand, if the implementations need to touch WebCore much,
-the APIs might not be good candidates for [Supplemental].
-
-== [Constructor](i), [CallWith](i,m,a), [ConstructorRaisesException](i) == #Constructor
+== `[Constructor]`(i), `[CallWith]`(i,m,a), `[ConstructorRaisesException]`(i) == #Constructor
 
  * [http://dev.w3.org/2006/webapi/WebIDL/#Constructor The spec of Constructor]
 
-Summary: [Constructor] indicates that the interface should have constructor, i.e. "new XXX()".
-[CallWith] and [ConstructorRaisesException] adds information when the constructor callback is called in WebCore.
-
-Usage: [Constructor], [CallWith] and [ConstructorRaisesException] can be specified on interfaces:
-{{{
-    interface [
-        Constructor(in float x, in float y, in DOMString str),
+Summary: `[Constructor]` indicates that the interface should have constructor, i.e. "new XXX()".
+`[CallWith]` and `[ConstructorRaisesException]` adds information when the constructor callback is called in WebCore.
+
+Usage: `[Constructor]`, `[CallWith]` and `[ConstructorRaisesException]` can be specified on interfaces:
+{{{
+    [
+        Constructor(float x, float y, DOMString str),
         ConstructorRaisesException,
         CallWith=ScriptExecutionContext|ScriptState
-    ] XXX {
-    };
-}}}
-
-[Constructor(in float x, in float y, in DOMString str)] means that the interface has a constructor
-and the constructor signature is (in float x, in float y, in DOMString str).
+    ] interface XXX {
+    };
+}}}
+
+`[Constructor(float x, float y, DOMString str)]` means that the interface has a constructor
+and the constructor signature is `(float x, float y, DOMString str)`.
 Specifically, JavaScript can create a DOM object of XXX by the following code:
 {{{
     var x = new XXX(1.0, 2.0, "hello");
 }}}
-Then XXX::create(float x, float y, String str) is called in WebCore.
+Then `XXX::create(float x, float y, String str)` is called in WebCore.
 That way WebCore needs to implement the following method as a constructor callback:
 {{{
@@ -880 +680 @@
 }}}
 
-[Constructor()] is equivalent to [Constructor].
-
-If XXX::create(...) can throw Exception, you can use [ConstructorRaisesException].
-With [ConstructorRaisesException], a placeholder for ExceptionCode is added to the tail argument of XXX::create(...).
+`[Constructor()]` is equivalent to `[Constructor]`.
+
+If `XXX::create(...)` can throw Exception, you can use `[ConstructorRaisesException]`.
+With `[ConstructorRaisesException]`, a placeholder for ExceptionCode is added to the tail argument of `XXX::create(...)`.
 {{{
     PassRefPtr<XXX> XXX::create(float x, float y, String str, ExceptionCode& ec)
@@ -895 +695 @@
 }}}
 
-If XXX::create(...) needs additional information like ScriptExecutionContext and ScriptState,
-you can specify [CallWith=ScriptExecutionContext|ScriptState].
-Then XXX::create(...) can have the following signature:
+If `XXX::create(...)` needs additional information like ScriptExecutionContext and ScriptState,
+you can specify `[CallWith=ScriptExecutionContext|ScriptState]`.
+Then `XXX::create(...)` can have the following signature:
 {{{
     PassRefPtr<XXX> XXX::create(ScriptExecutionContext* context, ScriptState* state, float x, float y, String str)
@@ -907 +707 @@
 Please see [#CallWith another [CallWith] section] for more details.
 
-Note that [CallWith=...] arguments are added at the head of XXX::create(...)'s arguments,
-and the ExceptionCode argument is added at the tail of XXX::create(...)'s arguments.
+Note that `[CallWith=...]` arguments are added at the head of `XXX::create(...)`'s arguments,
+and the ExceptionCode argument is added at the tail of `XXX::create(...)`'s arguments.
 
 Whether you should allow an interface to have constructor depends on the spec of the interface.
 
-Note: Currently [Constructor(...)] does not yet support [Optional] arguments. It just supports [Optional=DefaultIsUndefined] or [Optional=DefaultIsNullString].
-
-== [ConstructorTemplate](i), [InitializedByEventConstructor](a) == #ConstructorTemplate
+Note: Currently `[Constructor(...)]` does not yet support optional arguments w/o defaults. It just supports `[Default=Undefined] optional` or `[Default=NullString] optional`.
+
+== `[ConstructorTemplate]`(i), `[InitializedByEventConstructor]`(a) == #ConstructorTemplate
 
 Summary: They are used for Event constructors.
 
-Usage: The possible usage is [ConstructorTemplate=Event].
-[ConstructorTemplate=Event] can be specified on Event interfaces only.
-[InitializedByEventConstructor] can be specified on attributes in the Event interfaces:
-{{{
-    interface [
+Usage: The possible usage is `[ConstructorTemplate=Event]`.
+`[ConstructorTemplate=Event]` can be specified on Event interfaces only.
+`[InitializedByEventConstructor]` can be specified on attributes in the Event interfaces:
+{{{
+    [
         ConstructorTemplate=Event
-    ] FooEvent {
+    ] interface FooEvent {
         attribute DOMString str1;
-        attribute [InitializedByEventConstructor] DOMString str2;
+        [InitializedByEventConstructor] attribute DOMString str2;
     };
 }}}
 
 Since constructors for Event interfaces require special bindings,
-you need to use [ConstructorTemplate=Event] instead of normal [Constructor].
-
-If you specify [ConstructorTemplate=Event] on FooEvent,
+you need to use `[ConstructorTemplate=Event]` instead of normal `[Constructor]`.
+
+If you specify `[ConstructorTemplate=Event]` on FooEvent,
 JavaScript can create a DOM object of FooEvent in the following code:
 {{{
@@ -947 +747 @@
 }}}
 
-[InitializedByEventConstructor] should be specified on all the attributes
+`[InitializedByEventConstructor]` should be specified on all the attributes
 that needs to be initialized by the constructor.
 Which attributes need initialization is defined in the spec of each Event interface.
@@ -953 +753 @@
 The EventInit dictionary has bubbles and cancelable, and thus bubbles and cancelable are the only attributes
 that need to be initialized by the Event constructor.
-In other words, in case of Event, you should specify [InitializedByEventConstructor] on bubbles and cancelable.
-
-== [NamedConstructor](i) == #NamedConstructor
+In other words, in case of Event, you should specify `[InitializedByEventConstructor]` on bubbles and cancelable.
+
+== `[NamedConstructor]`(i) == #NamedConstructor
 
  * [http://dev.w3.org/2006/webapi/WebIDL/#NamedConstructor The spec of NamedConstructor]
 
 Summary: If you want to allow JavaScript to create a DOM object of XXX using a different name constructor
-(i.e. allow JavaScript to create an XXX object using "new YYY()", where YYY != XXX), you can use [NamedConstructor].
-
-Usage: The possible usage is [NamedConstructor=YYY].
-[NamedConstructor] can be specified on interfaces:
-{{{
-    interface [
+(i.e. allow JavaScript to create an XXX object using "new YYY()", where YYY != XXX), you can use `[NamedConstructor]`.
+
+Usage: The possible usage is `[NamedConstructor=YYY]`.
+`[NamedConstructor]` can be specified on interfaces:
+{{{
+    [
         NamedConstructor=Audio()
-    ] HTMLAudioElement {
-    };
-}}}
-
-The semantics is the same as [Constructor], except that JavaScript can make a DOM object not by "new HTMLAudioElement()" but by "Audio()".
+    ] interface HTMLAudioElement {
+    };
+}}}
+
+The semantics is the same as `[Constructor]`, except that JavaScript can make a DOM object not by "new HTMLAudioElement()" but by "Audio()".
 
 Whether you should allow an interface to have a named constructor or not depends on the spec of each interface.
 
-== [CustomConstructor](i), [JSCustomConstructor](i), [V8CustomConstructor](i), [ConstructorParameters](i) == #CustomConstructor
+== `[CustomConstructor]`(i), `[ConstructorParameters]`(i) == #CustomConstructor
 
 Summary: They allow you to write custom bindings for constructors.
 
 Usage: They can be specified on interfaces.
-Regarding [ConstructorParameters], the possible usage is [ConstructorParameters=X], where X is the maximum number of arguments of the constructor:
-{{{
-    interface [
+Regarding `[ConstructorParameters]`, the possible usage is `[ConstructorParameters=X]`, where `X` is the number of mandatory arguments of the constructor:
+{{{
+    [
         CustomConstructor,
         ConstructorParameters=4
-    ] XXX {
+    ] interface XXX {
     };
 }}}
 
 We should minimize the number of custom bindings as less as possible.
-Before using [CustomConstructor], you should doubly consider if you really need custom bindings.
-You are recommended to modify code generators to avoid using [Custom].
+Before using `[CustomConstructor]`, you should doubly consider if you really need custom bindings.
+You are recommended to modify code generators to avoid using `[Custom]`.
 
 Before explaining the details, let us clarify the relationship of these IDL attributes.
 
- * [JSCustomConstructor] on an interface indicates that you can write JavaScriptCore custom bindings for the constructor.
- * [V8CustomConstructor] on an interface indicates that you can write V8 custom bindings for the constructor.
- * [CustomConstructor] is equivalent to [JSCustomConstructor, V8CustomConstructor].
-
-For example, if you specify [Constructor, JSCustomConstructor],
-then the constructor is generated only for V8 and you need to write JavaScriptCore custom bindings for the constructor.
-
-How to write custom bindings is different between JavaScriptCore and V8.
-
- * JavaScriptCore: Consider the following example:
-
-{{{
-    interface [
+ * `[CustomConstructor]` on an interface indicates that you can write JavaScriptCore custom bindings for the constructor.
+
+You can write custom bindings for JavaScriptCore as follows.
+
+ * Consider the following example:
+
+{{{
+    [
         CustomConstructor,
         ConstructorParameters=2
-    ] XXX {
+    ] interface XXX {
     };
 }}}
@@ -1022 +817 @@
 Refer to WebCore/bindings/js/JSXXXCustom.cpp for more details.
 
- * V8: Consider the following example:
-
-{{{
-    interface [
-        CustomConstructor,
-        ConstructorParameters=2
-    ] XXX {
-    };
-}}}
-Then you can write custom bindings in WebCore/bindings/v8/custom/V8XXXConstructorCustom.cpp:
-{{{
-    v8::Handle<v8::Value> V8XXX::constructorCallback(const v8::Arguments& args)
-    {
-        ...;
-    }
-}}}
-Refer to WebCore/bindings/v8/custom/V8XXXConstructorCustom.cpp for more details.
-
-X of [ConstructorParameters=X] is the maximum number of arguments, including optional arguments.
-For example, if a constructor signature is [Constructor(in int a, in int b, in [Optional=DefaultIsUndefined] int c, in [Optional=DefaultIsUndefined] int d)], then X is 4.
-
-You do not need to specify [ConstructorParameters] if the interface does not have any of [JSCustomConstructor], [V8CustomConstructor] or [CustomConstructor].
-
-== [Conditional](i,m,a) == #Conditional
-
-Summary: [Conditional] inserts "#if ENABLE(SOME_FLAG) ... #endif" into the generated code.
-
-Usage: [Conditional] can be specified on interfaces, methods and attributes:
-{{{
-    interface [
+`X` of `[ConstructorParameters=X]` is the number of mandatory arguments.
+For example, if a constructor signature is `[Constructor(int a, int b, [Default=Undefined] optional int c, [Default=DefaultIsUndefined] optional int d)]`, then `X` is 2.
+
+You do not need to specify `[ConstructorParameters]` if the interface does not have `[CustomConstructor]` extended attribute.
+
+== `[Conditional]`(i,m,a) == #Conditional
+
+Summary: `[Conditional]` inserts "#if ENABLE(SOME_FLAG) ... #endif" into the generated code.
+
+Usage: `[Conditional]` can be specified on interfaces, methods and attributes:
+{{{
+    [
         Conditional=INDEXED_DATABASE
-    ] XXX {
+    ] interface XXX {
     };
 }}}
 {{{
     interface XXX {
-        attribute [Conditional=INDEXED_DATABASE] DOMString str;
+        [Conditional=INDEXED_DATABASE] attribute DOMString str;
         [Conditional=INDEXED_DATABASE] void open();
     };
 }}}
 
-[Conditional] is used to enable or disable the generated code based on a "flag".
+`[Conditional]` is used to enable or disable the generated code based on a "flag".
 If a given flag is enabled, the generated code is compiled. Otherwise, the generated code is not compiled.
 Whether a flag is enabled or disabled is controlled (mostly) by Tools/Scripts/build-webkit.
 
-If [Conditional] is specified on an interface, it means that [Conditional] is specified on all attributes and methods of the interface.
-
-== [CheckSecurity](i), [DoNotCheckSecurity](m,a), [DoNotCheckSecurityOnGetter](a), [DoNotCheckSecurityOnSetter](a) == #CheckSecurity
+If `[Conditional]` is specified on an interface, it means that `[Conditional]` is specified on all attributes and methods of the interface.
+
+== `[CheckSecurity]`(i), `[DoNotCheckSecurity]`(m,a), `[DoNotCheckSecurityOnGetter]`(a), `[DoNotCheckSecurityOnSetter]`(a) == #CheckSecurity
 
 Summary: They check whether a given access is allowed or not, in terms of the same-origin security policy.
 
-Usage: [CheckSecurity] can be specified on interfaces.
-[DoNotCheckSecurity] can be specified on methods or attributes that belong to interfaces that have [CheckSecurity].
-[DoNotCheckSecurityOnGetter] and [DoNotCheckSecurityOnSetter] can be specified on attributes
-that belong to interfaces that have [CheckSecurity]:
-{{{
-    interface [
+Usage: `[CheckSecurity]` can be specified on interfaces.
+`[DoNotCheckSecurity]` can be specified on methods or attributes that belong to interfaces that have `[CheckSecurity]`.
+`[DoNotCheckSecurityOnGetter]` and `[DoNotCheckSecurityOnSetter]` can be specified on attributes
+that belong to interfaces that have `[CheckSecurity]`:
+{{{
+    [
         CheckSecurity
-    ] DOMWindow {
+    ] interface DOMWindow {
         attribute DOMString str1;
-        attribute [DoNotCheckSecurity] DOMString str2:
-        attribute [DoNotCheckSecurityOnGetter] DOMString str3:
-        attribute [DoNotCheckSecurityOnSetter] DOMString str4:
+        [DoNotCheckSecurity] attribute DOMString str2:
+        [DoNotCheckSecurityOnGetter] attribute DOMString str3:
+        [DoNotCheckSecurityOnSetter] attribute DOMString str4:
         void func1();
         [DoNotCheckSecurity] void func2();
@@ -1092 +869 @@
 Consider the case where you access window.parent from inside an iframe that comes from a different origin.
 While it is allowed to access window.parent, it is not allowed to access window.parent.document.
-In such cases, you need to specify [CheckSecurity] in order to check
+In such cases, you need to specify `[CheckSecurity]` in order to check
 whether a given DOM object is allowed to access the attribute or method, in terms of the same-origin security policy.
 This is really important for security.
 
-If you specify [CheckSecurity] on an interface, the security check is enabled on all the attributes and methods of the interface.
+If you specify `[CheckSecurity]` on an interface, the security check is enabled on all the attributes and methods of the interface.
 To disable the security check for particular attributes or methods,
-you can use [DoNotCheckSecurity], [DoNotCheckSecurityOnGetter] or [DoNotCheckSecurityOnSetter].
-
- * [DoNotCheckSecurity] on a method disables the security check for the method.
- * [DoNotCheckSecurity] on an attribute disables the security check for a getter and setter of the attribute.
- * [DoNotCheckSecurityOnGetter] on an attribute disables the security check for a getter of the attribute.
- * [DoNotCheckSecurityOnSetter] on an attribute disables the security check for a setter of the attribute.
- * [DoNotCheckSecurity] on an attribute is equivalent to [DoNotCheckSecurityOnGetter, DoNotCheckSecurityOnSetter].
-
-== [CheckSecurityForNode](m,a) == #CheckSecurityForNode
-
-Summary: [CheckSecurityForNode] checks whether a given access to Node is allowed or not, in terms of the same-origin security policy.
-
-Usage: [CheckSecurityForNode] can be specified on methods or attributes:
-{{{
-    attribute [CheckSecurityForNode] Node contentDocument;
+you can use `[DoNotCheckSecurity]`, `[DoNotCheckSecurityOnGetter]` or `[DoNotCheckSecurityOnSetter]`.
+
+ * `[DoNotCheckSecurity]` on a method disables the security check for the method.
+ * `[DoNotCheckSecurity]` on an attribute disables the security check for a getter and setter of the attribute.
+ * `[DoNotCheckSecurityOnGetter]` on an attribute disables the security check for a getter of the attribute.
+ * `[DoNotCheckSecurityOnSetter]` on an attribute disables the security check for a setter of the attribute.
+ * `[DoNotCheckSecurity]` on an attribute is equivalent to `[DoNotCheckSecurityOnGetter, DoNotCheckSecurityOnSetter]`.
+
+== `[CheckSecurityForNode]`(m,a) == #CheckSecurityForNode
+
+Summary: `[CheckSecurityForNode]` checks whether a given access to Node is allowed or not, in terms of the same-origin security policy.
+
+Usage: `[CheckSecurityForNode]` can be specified on methods or attributes:
+{{{
+    [CheckSecurityForNode] attribute Node contentDocument;
     [CheckSecurityForNode] SVGDocument getSVGDocument();
 }}}
 
-In terms of the same-origin security policy, node.contentDocument should return undefined if the parent frame and the child frame are from different origins.
-If the security check is necessary, you should specify [CheckSecurityForNode].
+In terms of the same-origin security policy, `node.contentDocument` should return undefined if the parent frame and the child frame are from different origins.
+If the security check is necessary, you should specify `[CheckSecurityForNode]`.
 This is really important for security.
 
-== [IndexedGetter](i) == #IndexedGetter
+== `[IndexedGetter]`(i) == #IndexedGetter
 
  * [http://dev.w3.org/2006/webapi/WebIDL/#idl-indexed-properties The spec of indexed properties] (Note: The WebKit behavior explained below is different from the spec)
 
-Summary: [IndexedGetter] means that a given interface should have a getter of indexed properties.
-
-Usage: [IndexedGetter] can be specified on interfaces:
-{{{
-    interface [
+Summary: `[IndexedGetter]` means that a given interface should have a getter of indexed properties.
+
+Usage: `[IndexedGetter]` can be specified on interfaces:
+{{{
+    [
         IndexedGetter
-    ] XXX {
-    };
-}}}
-
-Indexed getters define the behavior when XXX[i] is evaluated.
-For example, if XXX is an array-type interface, it should have indexed getters (and setters).
-The bindings code for indexed getters is generated automatically so that XXX[i] behaves equivalent to XXX.item(i).
-
-== [V8CustomIndexedGetter](i) == #V8CustomIndexedGetter
-
-Summary: [V8CustomIndexedGetter] allows you to write custom bindings for a getter of indexed properties.
-
-Usage: [V8CustomIndexedGetter] can be specified on interfaces:
-{{{
-    interface [
-        V8CustomIndexedGetter
-    ] XXX {
-    };
-}}}
-
-Interface that have V8CustomIndexedGetter attribute must have also IndexedGetter attribute.
-
-== [CustomIndexedSetter](i) == #CustomIndexedSetter
+    ] interface XXX {
+    };
+}}}
+
+Indexed getters define the behavior when `XXX[i]` is evaluated.
+For example, if `XXX` is an array-type interface, it should have indexed getters (and setters).
+The bindings code for indexed getters is generated automatically so that `XXX[i]` behaves equivalent to `XXX.item(i)`.
+
+== `[CustomIndexedSetter]`(i) == #CustomIndexedSetter
 
  * [http://dev.w3.org/2006/webapi/WebIDL/#idl-indexed-properties The spec of indexed properties] (Note: The WebKit behavior explained below is different from the spec)
 
-Summary: [CustomIndexedSetter] allows you to write custom bindings for a setter of indexed properties.
+Summary: `[CustomIndexedSetter]` allows you to write custom bindings for a setter of indexed properties.
 
 Usage: [CustomIndexedSetter] can be specified on interfaces:
 {{{
-    interface [
+    [
         CustomIndexedSetter
-    ] XXX {
+    ] interface XXX {
     };
 }}}
@@ -1168 +931 @@
 Indexed setters define the behavior when "XXX[i] = ..." is evaluated.
 For example, if XXX is an array-type interface, it should have indexed (getters and) setters.
-[CustomIndexedSetter] allows you to write the custom bindings, as follows.
-
- * JavaScriptCore: You can write custom JSXXX::indexSetter(...) in WebCore/bindings/js/JSXXXCustom.cpp:
+`[CustomIndexedSetter]` allows you to write the custom bindings, as follows.
+
+ * JavaScriptCore: You can write custom `JSXXX::indexSetter(...)` in WebCore/bindings/js/JSXXXCustom.cpp:
 
 {{{
@@ -1178 +941 @@
     }
 }}}
- * In V8: You can write custom V8XXX::indexedPropertySetter(...) in WebCore/bindings/v8/custom/V8XXXCustom.cpp:
-
-{{{
-    v8::Handle<v8::Value> V8XXX::indexedPropertySetter(uint32_t index, const v8::AccessorInfo& info)
-    {
-        ...;
-    }
-}}}
-
-== [NamedGetter](i) == #NamedGetter
+
+== `[NamedGetter]`(i) == #NamedGetter
 
  * [http://dev.w3.org/2006/webapi/WebIDL/#idl-named-properties The spec of named properties] (Note: The WebKit behavior explained below is different from the spec)
 
-Summary: [NamedGetter] means that a given interface should have a getter of named properties.
-
-Usage: [NamedGetter] can be specified on interfaces:
-{{{
-    interface [
+Summary: `[NamedGetter]` means that a given interface should have a getter of named properties.
+
+Usage: `[NamedGetter]` can be specified on interfaces:
+{{{
+    [
         NamedGetter
-    ] XXX {
+    ] interface XXX {
     };
 }}}
@@ -1204 +959 @@
 The bindings code for named getters is generated automatically so that XXX.foooooooo behaves equivalent to XXX.namedItem(i).
 
-== [CustomNamedGetter](i), [CustomNamedSetter](i) == #CustomNamedGetter
+== `[CustomNamedGetter]`(i), `[CustomNamedSetter]`(i) == #CustomNamedGetter
 
  * [http://dev.w3.org/2006/webapi/WebIDL/#idl-named-properties The spec of named properties] (Note: The WebKit behavior explained below is different from the spec)
 
-Summary: [CustomNamedGetter] or [CustomNamedSetter] allows you to write custom bindings for a getter or setter of named properties.
+Summary: `[CustomNamedGetter]` or `[CustomNamedSetter]` allows you to write custom bindings for a getter or setter of named properties.
 
 Usage: They can be specified on interfaces:
 {{{
-    interface [
+    [
         CustomNamedGetter,
         CustomNamedSetter
-    ] XXX {
+    ] interface XXX {
     };
 }}}
@@ -1221 +976 @@
 Named getters define the behavior when XXX.foooooooo is evaluated, where foooooooo is not an attribute of XXX.
 Named setters define the behavior when "XXX.foooooooo = ..." is evaluated.
-[CustomNamedGetter] or [CustomNamedSetter] allow you to write the custom bindings, as follows:
-
- * [CustomNamedGetter] in JavaScriptCore: You can write custom JSXXX::canGetItemsForName(...) and JSXXX::nameGetter(...) in WebCore/bindings/js/JSXXXCustom.cpp:
+`[CustomNamedGetter]` or `[CustomNamedSetter]` allow you to write the custom bindings, as follows:
+
+ * `[CustomNamedGetter]` in JavaScriptCore: You can write custom `JSXXX::canGetItemsForName(...)` and `JSXXX::nameGetter(...)` in WebCore/bindings/js/JSXXXCustom.cpp:
 
 {{{
@@ -1236 +991 @@
     }
 }}}
- * [CustomNamedGetter] in V8: You can write custom V8XXX::namedPropertyGetter(...) in WebCore/bindings/v8/custom/V8XXXCustom.cpp:
-
-{{{
-    v8::Handle<v8::Value> V8XXX::namedPropertyGetter(v8::Local<v8::String> name, const v8::AccessorInfo& info)
-    {
-        ...;
-    }
-}}}
- * [CustomNamedSetter] in JavaScriptCore: You can write custom JSXXX::putDelegate(...) in WebCore/bindings/js/JSXXXCustom.cpp:
+ * `[CustomNamedSetter]` in JavaScriptCore: You can write custom `JSXXX::putDelegate(...)` in WebCore/bindings/js/JSXXXCustom.cpp:
 
 {{{
@@ -1252 +999 @@
     }
 }}}
- * [CustomNamedSetter] in V8: You can write custom V8XXX::namedPropertySetter(...) in WebCore/bindings/v8/custom/V8XXXCustom.cpp:
-
-{{{
-    v8::Handle<v8::Value> V8XXX::namedPropertySetter(v8::Local<v8::String> name, v8::Local<v8::Value> value, const v8::AccessorInfo& info)
-    {
-        ...;
-    }
-}}}
-
-== [InterfaceName](i) == #InterfaceName
-
-Summary: If you want to expose a different interface name to JavaScript, you can specify the name by [InterfaceName].
-
-Usage: The possible usage is [InterfaceName=X], where X is the interface name exposed to JavaScript.
-[InterfaceName] can be specified on interfaces:
+
+== `[InterfaceName]`(i) == #InterfaceName
+
+Summary: If you want to expose a different interface name to JavaScript, you can specify the name by `[InterfaceName]`.
+
+Usage: The possible usage is `[InterfaceName=X]`, where `X` is the interface name exposed to JavaScript.
+`[InterfaceName]` can be specified on interfaces:
 {{{
     interface [
@@ -1274 +1013 @@
 }}}
 
-Without [InterfaceName=...], the interface name exposed to JavaScript becomes the same as the interface name in an IDL file.
-If you want change it based on the spec, you can use [InterfaceName=...].
+Without `[InterfaceName=...]`, the interface name exposed to JavaScript becomes the same as the interface name in an IDL file.
+If you want change it based on the spec, you can use `[InterfaceName=...]`.
 In the above example, `window.toString()` will return `"[object Window]"` in JavaScript.
 
-== [EventTarget](i) FIXME == #EventTarget
+== `[EventTarget]`(i) FIXME == #EventTarget
 
 Summary: ADD SUMMARY
 
-Usage: [EventTarget] can be specified on interfaces:
-{{{
-    interface [
+Usage: `[EventTarget]` can be specified on interfaces:
+{{{
+    [
         EventTarget
-    ] XXX {
+    ] interface XXX {
     };
 }}}
@@ -1292 +1031 @@
 ADD EXPLANATIONS
 
-== [DoNotCheckConstants](i) == #DoNotCheckConstants
-
-Summary: [DoNotCheckConstants] indicates that constant values in an IDL file can be different from constant values in WebCore implementation.
-
-Usage: [DoNotCheckConstants] can be specified on interfaces:
-{{{
-    interface [
+== `[DoNotCheckConstants]`(i) == #DoNotCheckConstants
+
+Summary: `[DoNotCheckConstants]` indicates that constant values in an IDL file can be different from constant values in WebCore implementation.
+
+Usage: `[DoNotCheckConstants]` can be specified on interfaces:
+{{{
+    [
         DoNotCheckConstants
-    ] XXX {
+    ] interface XXX {
         const unsigned short NOT_FOUND_ERR = 12345;
         const unsigned short SYNTAX_ERR = 12346;
@@ -1306 +1045 @@
 }}}
 
-By default (i.e. without [DoNotCheckConstants]), compile-time assertions are inserted to check if the constant values defined in IDL files
+By default (i.e. without `[DoNotCheckConstants]`), compile-time assertions are inserted to check if the constant values defined in IDL files
 are equal to the constant values in WebCore implementation.
 In the above example, if NOT_FOUND_ERR were implemented as 100 in WebCore, the build will fail.
@@ -1313 +1052 @@
 and thus the values in WebCore implementation should be equal to the values defined in the spec.
 If you really want to introduce non-speced constant values and allow different values between IDL files and WebCore implementation,
-you can specify [DoNotCheckConstants] to skip the compile-time assertions.
-
-== [ActiveDOMObject](i) == #ActiveDOMObject
-
-Summary: [ActiveDOMObject] indicates that a given DOM object should be kept alive as long as the DOM object has pending activities.
-
-Usage: [ActiveDOMObject] can be specified on interfaces:
-{{{
-    interface [
+you can specify `[DoNotCheckConstants]` to skip the compile-time assertions.
+
+== `[ActiveDOMObject]`(i) == #ActiveDOMObject
+
+Summary: `[ActiveDOMObject]` indicates that a given DOM object should be kept alive as long as the DOM object has pending activities.
+
+Usage: `[ActiveDOMObject]` can be specified on interfaces:
+{{{
+    [
         ActiveDOMObject
-    ] XMLHttpRequest {
-    };
-}}}
-
-If a given DOM object needs to be kept alive as long as the DOM object has pending activities, you need to specify [ActiveDOMObject].
-For example, [ActiveDOMObject] can be used when the DOM object is expecting events to be raised in the future.
-
-If you use [ActiveDOMObject], the corresponding WebCore class needs to inherit ActiveDOMObject.
+    ] interface XMLHttpRequest {
+    };
+}}}
+
+If a given DOM object needs to be kept alive as long as the DOM object has pending activities, you need to specify `[ActiveDOMObject]`.
+For example, `[ActiveDOMObject]` can be used when the DOM object is expecting events to be raised in the future.
+
+If you use `[ActiveDOMObject]`, the corresponding WebCore class needs to inherit ActiveDOMObject.
 For example, in case of XMLHttpRequest, WebCore/xml/XMLHttpRequest.h would look like this:
 {{{
@@ -1339 +1078 @@
 Then you need to implement the virtual methods of the ActiveDOMObject class, e.g. contextDestroyed(), canSuspend(), suspend(), resume() and stop().
 
-If an interface X has [ActiveDOMObject] and an interface Y inherits the interface X,
-then the interface Y should also have [ActiveDOMObject].
-
-== [V8DependentLifeTime](i) FIXME == #V8DependentLifeTime
-
-Summary: ADD SUMMARY
-
-Usage: [V8DependentLifeTime] can be specified on interfaces:
-{{{
-    interface [
-        V8DependentLifeTime
-    ] XXX {
-    };
-}}}
-
-ADD EXPLANATIONS
-
-== [CustomEnumerateProperty](i), [CustomDeleteProperty](i) == #CustomEnumerateProperty
-
-Summary: [CustomEnumerateProperty] allows you to write custom bindings for the case where properties of a given interface are enumerated.
-[CustomDeleteProperty] allows you to write custom bindings for the case where a property of a given interface is deleted.
+If an interface X has `[ActiveDOMObject]` and an interface Y inherits the interface X,
+then the interface Y should also have `[ActiveDOMObject]`.
+
+== `[CustomEnumerateProperty]`(i), `[CustomDeleteProperty]`(i) == #CustomEnumerateProperty
+
+Summary: `[CustomEnumerateProperty]` allows you to write custom bindings for the case where properties of a given interface are enumerated.
+`[CustomDeleteProperty]` allows you to write custom bindings for the case where a property of a given interface is deleted.
 
 Usage: They can be specified on interfaces:
 {{{
-    interface [
+    [
         CustomEnumerateProperty,
         CustomDeleteProperty
-    ] XXX {
-    };
-}}}
-
- * [CustomEnumerateProperty] in JavaScriptCore: You can write custom bindings when properties of XXX are enumerated.
-Specifically, you can write custom JSXXX::getOwnPropertyNames(...) in WebCore/bindings/js/JSXXXCustom.cpp:
+    ] interface XXX {
+    };
+}}}
+
+ * `[CustomEnumerateProperty]` in JavaScriptCore: You can write custom bindings when properties of XXX are enumerated.
+Specifically, you can write custom `JSXXX::getOwnPropertyNames(...)` in WebCore/bindings/js/JSXXXCustom.cpp:
 
 {{{
@@ -1380 +1105 @@
 }}}
 
- * [CustomEnumerateProperty] in V8: You can write custom bindings as V8XXX::namedPropertyQuery(...) and V8XXX::namedPropertyEnumerator(...) in WebCore/bindings/v8/custom/V8XXXCustom.cpp:
-
-{{{
-    v8::Handle<v8::Integer> V8XXX::namedPropertyQuery(v8::Local<v8::String> name, const v8::AccessorInfo& info)
-    {
-        ...;
-    }
-
-    v8::Handle<v8::Array> V8XXX::namedPropertyEnumerator(const v8::AccessorInfo& info)
-    {
-        ...;
-    }
-}}}
-
- * [CustomDeleteProperty] in JavaScriptCore: You can write custom bindings for the case where a property of XXX is deleted.
-Specifically, you can write custom JSXXX::deleteProperty(...) in WebCore/bindings/js/JSXXXCustom.cpp:
+ * `[CustomDeleteProperty]` in JavaScriptCore: You can write custom bindings for the case where a property of XXX is deleted.
+Specifically, you can write custom `JSXXX::deleteProperty(...)` in WebCore/bindings/js/JSXXXCustom.cpp:
 
 {{{
@@ -1404 +1115 @@
 }}}
 
- * [CustomDeleteProperty] in V8: You can write custom bindings as V8XXX::namedPropertyDeleter(...) in WebCore/bindings/v8/custom/V8XXXCustom.cpp:
-
-{{{
-    v8::Handle<v8::Boolean> V8XXX::namedPropertyDeleter(v8::Local<v8::String> name, const v8::AccessorInfo& info)
-    {
-        ...;
-    }
-}}}
-
-== [IsWorkerContext](i) == #IsWorkerContext
-
-Summary: [IsWorkerContext] indicates that a given interface is a WorkerContext-related interface.
-
-Usage: [IsWorkerContext] can be specified on WorkerContext-related interfaces only:
-{{{
-    interface [
+== `[IsWorkerContext]`(i) == #IsWorkerContext
+
+Summary: `[IsWorkerContext]` indicates that a given interface is a WorkerContext-related interface.
+
+Usage: `[IsWorkerContext]` can be specified on WorkerContext-related interfaces only:
+{{{
+    [
         IsWorkerContext
-    ] SharedWorkerContext {
-    };
-}}}
-
-== [TransferList](p) == #TransferList
-
-Summary: [TransferList] allows a SerializedScriptValue parameter used
-with the structured clone algorithm to specify another parameter used
-to pass the transfer list.
-
-Usage: The possible usage is [TransferList=XXX] where XXX is another
-parameter in the same method signature as the SerializedScriptValue
-parameter on which the modifier is placed. The referenced parameter
-should be of type "Array" to be compatible with the Web Messaging
-standard.
-
-When this modifier is used, the code generation automatically creates
-a MessagePortArray and completes the structured clone algorithm using
-the input data from the JavaScript caller. The resulting
-MessagePortArray is then passed to the implementation's method
-signature in place of the Array parameter referenced.
-
-Example:
-{{{
-    interface Worker {
-        void postMessage(in [TransferList=transfer] SerializedScriptValue data, in [Optional=DefaultIsUndefined] Array transfer);
-    }
-}}}
-And in the implementation:
-{{{
-    class Worker {
-        virtual void postMessage(PassRefPtr<SerializedScriptValue> data, const MessagePortArray& ports);
-    }
-}}}
-
-== [TypedArray](i), [ConstructorTemplate=TypedArray](i) == #TypedArray
+    ] interface SharedWorkerContext {
+    };
+}}}
+
+== `[TypedArray]`(i), [ConstructorTemplate=TypedArray](i) == #TypedArray
 
 * [http://www.khronos.org/registry/typedarray/specs/latest/#7 The spec of TypedArray]
@@ -1463 +1134 @@
 TypedArray implements ArrayBufferView. Each of the typed array types has the following constructors, properties, constants and methods.
 
-Usage: [TypedArray] must be specified on interfaces in conjunction with [ConstructorTemplate=TypedArray]:
+Usage: `[TypedArray]` must be specified on interfaces in conjunction with `[ConstructorTemplate=TypedArray]`:
 Example:
 
 {{{
-interface [
-    ConstructorTemplate=TypedArray,
-    TypedArray=int
-] XXX : ArrayBufferView {
-    void set(TypedArray array, optional unsigned long offset);
-}
-}}}
-
-TypedArray=* Allows us to specify any valid typed array view type.
-TypedArray interfaces require special bindings code, you need to use [ConstructorTemplate=TypedArray] instead of normal [Constructor].
-
-== [CustomCall](i) == #CustomCall
-
-Summary: [CustomCall] allows you to write custom bindings for call(...) of a given interface.
-
-Usage: [CustomCall] can be specified on interfaces:
-{{{
-    interface [
+    [
+        ConstructorTemplate=TypedArray,
+        TypedArray=int
+    ] interface XXX : ArrayBufferView {
+        void set(TypedArray array, optional unsigned long offset);
+    }
+}}}
+
+`TypedArray=*` Allows us to specify any valid typed array view type.
+TypedArray interfaces require special bindings code, you need to use `[ConstructorTemplate=TypedArray]` instead of normal `[Constructor]`.
+
+== `[CustomCall]`(i) == #CustomCall
+
+Summary: `[CustomCall]` allows you to write custom bindings for `call(...)` of a given interface.
+
+Usage: `[CustomCall]` can be specified on interfaces:
+{{{
+    [
         CustomCall
-    ] XXX {
-    };
-}}}
-
-If you want to write custom bindings for XXX.call(...), you can use [CustomCall].
-
- * JavaScriptCore: You can write custom JSXXX::getCallData(...) in WebCore/bindings/js/JSXXXCustom.cpp:
+    ] interface XXX {
+    };
+}}}
+
+If you want to write custom bindings for XXX.call(...), you can use `[CustomCall]`.
+
+ * JavaScriptCore: You can write custom `JSXXX::getCallData(...)` in WebCore/bindings/js/JSXXXCustom.cpp:
 
 {{{
@@ -1500 +1171 @@
     }
 }}}
- * V8: You can write custom V8XXX::callAsFunctionCallback(...) in WebCore/bindings/v8/custom/V8XXXCustom.cpp:
-
-{{{
-    v8::Handle<v8::Value> V8XXX::callAsFunctionCallback(const v8::Arguments& args)
-    {
-        ...;
-    }
-}}}
-
-== [JSCustomToNativeObject](i), [JSCustomFinalize](i), [JSCustomIsReachable](i), [JSCustomMarkFunction](i), [JSCustomNamedGetterOnPrototype](i), [JSCustomPushEventHandlerScope](i), [JSCustomDefineOwnProperty](i), [JSCustomDefineOwnPropertyOnPrototype](i), [JSCustomGetOwnPropertySlotAndDescriptor](i) == #JSCustomToNativeObject
+
+== `[JSCustomToNativeObject]`(i), `[JSCustomFinalize]`(i), `[CustomIsReachable]`(i), `[JSCustomMarkFunction]`(i), `[JSCustomNamedGetterOnPrototype]`(i), `[JSCustomPushEventHandlerScope]`(i), `[JSCustomDefineOwnProperty]`(i), `[JSCustomDefineOwnPropertyOnPrototype]`(i), `[JSCustomGetOwnPropertySlotAndDescriptor]`(i) == #JSCustomToNativeObject
 
 Summary: They allow you to write custom bindings for the JavaScriptCore-specific code that would be generated automatically by default.
@@ -1515 +1178 @@
 Usage: They can be specified on interfaces:
 {{{
-    interface [
+    [
         JSCustomToNativeObject,
         JSCustomFinalize,
-        JSCustomIsReachable,
+        CustomIsReachable,
         JSCustomMarkFunction,
         JSCustomNamedGetterOnPrototype,
@@ -1525 +1188 @@
         JSCustomDefineOwnPropertyOnPrototype,
         JSCustomGetOwnPropertySlotAndDescriptor
-    ] XXX {
+    ] interface XXX {
     };
 }}}
@@ -1532 +1195 @@
 Refer to use cases in WebCore/bindings/js/JSXXXCustom.cpp for more details.
 
- * [JSCustomToNativeObject]: You can write custom toXXX(...):
+ * `[JSCustomToNativeObject]`: You can write custom `toXXX(...)`:
 
 {{{
@@ -1540 +1203 @@
     }
 }}}
- * [JSCustomFinalize]: You can write custom JSXXXOwner::finalize(...):
+ * `[JSCustomFinalize]`: You can write custom `JSXXXOwner::finalize(...)`:
 
 {{{
@@ -1548 +1211 @@
     }
 }}}
- * [JSCustomIsReachable]: You can write custom JSXXXOwner::isReachableFromOpaqueRoots(...):
+ * `[CustomIsReachable]`: You can write custom `JSXXXOwner::isReachableFromOpaqueRoots(...)`:
 
 {{{
@@ -1556 +1219 @@
     }
 }}}
- * [JSCustomMarkFunction]: You can write custom JSXXX::visitChildren(...):
+ * `[JSCustomMarkFunction]`: You can write custom `JSXXX::visitChildren(...)`:
 
 {{{
@@ -1564 +1227 @@
     }
 }}}
- * [JSCustomNamedGetterOnPrototype]: You can write custom JSXXXPrototype::putDelegate(...):
+ * `[JSCustomNamedGetterOnPrototype]`: You can write custom `JSXXXPrototype::putDelegate(...)`:
 
 {{{
@@ -1572 +1235 @@
     }
 }}}
- * [JSCustomPushEventHandlerScope]: You can write custom JSXXX::pushEventHandlerScope(...):
+ * `[JSCustomPushEventHandlerScope]`: You can write custom `JSXXX::pushEventHandlerScope(...)`:
 
 {{{
@@ -1580 +1243 @@
     }
 }}}
- * [JSCustomDefineOwnProperty]: You can write custom JSXXX::defineOwnProperty(...):
+ * `[JSCustomDefineOwnProperty]`: You can write custom `JSXXX::defineOwnProperty(...)`:
 
 {{{
@@ -1588 +1251 @@
     }
 }}}
- * [JSCustomDefineOwnPropertyOnPrototype]: You can write custom JSXXXPrototype::defineOwnProperty(...):
+ * `[JSCustomDefineOwnPropertyOnPrototype]`: You can write custom `JSXXXPrototype::defineOwnProperty(...)`:
 
 {{{
@@ -1596 +1259 @@
     }
 }}}
- * [JSCustomGetOwnPropertySlotAndDescriptor]: You can write custom JSXXX::getOwnPropertySlotDelegate(...) and JSXXX::getOwnPropertyDescriptorDelegate(...):
+ * `[JSCustomGetOwnPropertySlotAndDescriptor]`: You can write custom `JSXXX::getOwnPropertySlotDelegate(...)` and `JSXXX::getOwnPropertyDescriptorDelegate(...)`:
 
 {{{
@@ -1610 +1273 @@
 }}}
 
-== [JSGenerateToJSObject](i), [JSGenerateToNativeObject](i) == #JSGenerateToJSObject
+== `[JSGenerateToJSObject]`(i), `[JSGenerateToNativeObject]`(i) == #JSGenerateToJSObject
 
 Summary: They force JavaScriptCore bindings to generate JavaScriptCore-specific methods, even if a given interface has a parent interface.
@@ -1616 +1279 @@
 Usage: They can be specified on interfaces that do not have a parent interface:
 {{{
-    interface [
+    [
         JSGenerateToJSObject,
         JSGenerateToNativeObject
-    ] XXX {
-    };
-}}}
-
-toJS(...), isReachableFromOpaqueRoots(...) or toXXX() is not generated if XXX has a parent interface.
+    ] interface XXX {
+    };
+}}}
+
+`toJS(...)`, `isReachableFromOpaqueRoots(...)` or `toXXX()` is not generated if XXX has a parent interface.
 If you want to generate it even if XXX does not have a parent interface, you can specify
-[JSGenerateToJSObject] or [JSGenerateToNativeObject], respectively.
-
-== [JSGenerateIsReachable](i) == #JSGenerateIsReachable
+`[JSGenerateToJSObject]` or `[JSGenerateToNativeObject]`, respectively.
+
+== `[GenerateIsReachable]`(i) == #GenerateIsReachable
 
 Summary: This generates code that determines if a wrapper is reachable.
 
-Usage: The JSGenerateIsReachable can be specified on the interface. This attribute is ignored if CustomIsReachable is present.
-
-{{{
-    interface [
-        JSGenerateIsReachable=ImplBaseRoot
-    ] XXX {
-    };
-}}}
-
-The code generates a function called XXX::isReachableFromOpaqueRoots which returns a boolean if the wrapper is reachable.
+Usage: The `GenerateIsReachable` can be specified on the interface. This attribute is ignored if `CustomIsReachable` is present.
+
+{{{
+    [
+        GenerateIsReachable=ImplBaseRoot
+    ] interface XXX {
+    };
+}}}
+
+The code generates a function called `XXX::isReachableFromOpaqueRoots` which returns a boolean if the wrapper is reachable.
 
 The currently valid values are:
@@ -1654 +1317 @@
 The value of these represents the functions to call to get the object that determines whether the object is reachable or not. See CodeGeneratorJS.pm for more details. The values that end with Root calls WebCore::root to get the root. If the value is left out then WebCore::root is called on impl().
 
-== [V8GenerateIsReachable](i), V8CustomIsReachable(i) == #V8GenerateIsReachable
-
-Summary: This generates code that allows you to set up implicit references between wrappers which can be used to keep wrappers alive during GC.
-
-Usage: The V8GenerateIsReachable can be specified on the interface. This attribute is ignored if CustomIsReachable is present.
-
-{{{
-    interface [
-        V8GenerateIsReachable=ImplBaseRoot
-    ] XXX {
-    };
-}}}
-
-The code generates a function called XXX::visitDOMWrapper which is called by V8GCController before GC. The function adds implicit references to the wrapper which keeps it alive.
-
-The currently valid values are:
-
-|ImplElementRoot|ImplOwnerRoot|ImplOwnerNodeRoot|ImplBaseRoot
-
- - ImplOwnerRoot
- - ImplOwnerNodeRoot
- - ImplElementRoot
- - ImplBaseRoot
-
-The value of these represents the functions to call to get the object that determines whether the object is reachable or not. See CodeGeneratorV8.pm for more details.
-
-== [V8CustomIsReachable(i) == #V8CustomIsReachable
-
-Summary: Allows you to write custom code for visitDOMWrapper.
-
-Usage:
-
-{{{
-    interface [
-        V8CustomIsReachable
-    ] XXX {
-    };
-}}}
-
-And then in V8XXXCustom.cpp:
-
-{{{
-void V8XXX::visitDOMWrapper(DOMDataStore* store, void* object, v8::Persistent<v8::Object> wrapper)
-{
-  ...
-}
-}}}
-== [GenerateIsReachable](i) == #GenerateIsReachable
-
-Summary: This is the shared version of [JSGenerateIsReachable] and V8GenerateIsReachable. The accepted values are the intersection of those two.
-
- - ImplElementRoot
- - ImplBaseRoot
-
-== [JSCustomHeader](i) == #JSCustomHeader
-
-Summary: [JSCustomHeader] allows you to write a custom header for a given interface.
-
-Usage: [JSCustomHeader] can be specified on interfaces:
-{{{
-    interface [
-        JSCustomHeader
-    ] XXX {
-    };
-}}}
-
-By default, JSXXX.h and JSXXX.cpp are generated automatically.
-By specifying [Custom*], you can write custom bindings in WebCore/bindings/js/JSXXXCustom.cpp.
-In addition, by specifying [JSCustomHeader], you can write custom header in WebCore/bindings/js/JSXXXCustom.h, which will be included by JSXXX.h.
-
-== [JSLegacyParent](i) == #JSLegacyParent
-
-Summary: [JSLegacyParent] explicitly controls the parent interface of a given interface.
-
-Usage: [JSLegacyParent] can be specified on interfaces that do not have a parent interface:
-{{{
-    interface [
+== `[JSLegacyParent]`(i) == #JSLegacyParent
+
+Summary: `[JSLegacyParent]` explicitly controls the parent interface of a given interface.
+
+Usage: `[JSLegacyParent]` can be specified on interfaces that do not have a parent interface:
+{{{
+    [
         JSLegacyParent=JSDOMWindowBase
-    ] DOMWindow {
-    };
-}}}
-
-Even if a given interface does not have a parent interface, you can specify a parent interface using [JSLegacyParent].
-
-== [JSInlineGetOwnPropertySlot](i) == #JSInlineGetOwnPropertySlot
-
-Summary: For performance, [JSInlineGetOwnPropertySlot] makes getOwnPropertySlot(...) and getOwnPropertyDescriptor(...) an inline method.
-
-Usage: [JSInlineGetOwnPropertySlot] can be specified on interfaces:
-{{{
-    interface [
+    ] interface DOMWindow {
+    };
+}}}
+
+Even if a given interface does not have a parent interface, you can specify a parent interface using `[JSLegacyParent]`.
+
+== `[JSInlineGetOwnPropertySlot]`(i) == #JSInlineGetOwnPropertySlot
+
+Summary: For performance, `[JSInlineGetOwnPropertySlot]` makes `getOwnPropertySlot(...)` and `getOwnPropertyDescriptor(...)` an inline method.
+
+Usage: `[JSInlineGetOwnPropertySlot]` can be specified on interfaces:
+{{{
+    [
         JSInlineGetOwnPropertySlot
-    ] XXX {
-    };
-}}}
-
-== [JSNoStaticTables](i) == #JSNoStaticTables
+    ] interface XXX {
+    };
+}}}
+
+== `[JSNoStaticTables]`(i) == #JSNoStaticTables
 
 Summary: By default, there is only a single static prototype table for the interface.  This flag turns off creation of the static table, and each user gets its own table.
@@ -1756 +1349 @@
 Sharing a single static prototype table only works when a class is guaranteed to be accessed from a single heap, because the lookup code expects the key (attribute name) to have the same address across all instances of the object. For interfaces that are exposed to Workers, a single static table won't work because a given string used to look up a property on the object will lie at a different address in each heap.
 
-Usage: [JSNoStaticTables] can be specified on interfaces:
-{{{
-    interface [
+Usage: `[JSNoStaticTables]` can be specified on interfaces:
+{{{
+    [
         JSNoStaticTables
-    ] XXX {
+    ] interface XXX {
     };
 }}}
@@ -1766 +1359 @@
 ADD EXPLANATIONS
 
-== [ObjCProtocol](i), [ObjCPolymorphic](i), [ObjCLegacyUnnamedParameters](m), [ObjCUseDefaultView](m), [ObjCImplementedAsUnsignedLongLong](a) == #ObjCProtocol
+== `[ObjCProtocol]`(i), `[ObjCPolymorphic]`(i), `[ObjCLegacyUnnamedParameters]`(m), `[ObjCUseDefaultView]`(m), `[ObjCImplementedAsUnsignedLongLong]`(a) == #ObjCProtocol
 
 Used by ObjC bindings only.
 
-== [CPPPureInterface](i) == #CPPPureInterface
+== `[CPPPureInterface]`(i) == #CPPPureInterface
 
 Used by CPP bindings only.
 
-== [CustomReturn](p) == #CustomReturn
+== `[CustomReturn]`(p) == #CustomReturn
 
 Used by ObjC, GObject and CPP bindings only.
 
-== [ArrayClass](i) == #ArrayClass
+== `[ArrayClass]`(i) == #ArrayClass
 
 * [http://dev.w3.org/2006/webapi/WebIDL/#ArrayClass The spec of ArrayClass]
@@ -1784 +1377 @@
 Summary: Allows an interface to extend JavaScript arrays.
 
-Usage: [ArrayClass] can be specified on interfaces. An interface may not both have [ArrayClass] and extend another interface.
+Usage: `[ArrayClass]` can be specified on interfaces. An interface may not both have `[ArrayClass]` and extend another interface.
 
 The bindings for the interface will have the `[[Prototype]]` of the constructor prototype set to `Array.prototype` which means that the methods defined on JavaScript arrays work on the instances of this interface.
 
 {{{
-// IDL
-interface [
-    ArrayClass,
-    IndexedGetter
-] NodeList {
-    Node item(in unsigned long index);
-    readonly attribute unsigned long length;
-}
-
-// JS
-myNodeList instanceof Array  // true
-myNodeList.forEach(function(node) { console.log(node_; });
-}}}
-
-== [OmitConstructor], [Immutable], [MasqueradesAsUndefined], [CustomGetOwnPropertySlot], [ReplaceableConstructor], [ExtendsDOMGlobalObject], [IsIndex], [V8DoNotCheckSignature], [NumericIndexedGetter] == #OmitConstructor
+    // IDL
+    [
+        ArrayClass,
+        IndexedGetter
+    ] interface NodeList {
+        Node item(unsigned long index);
+        readonly attribute unsigned long length;
+    };
+
+    // JS
+    myNodeList instanceof Array  // true
+    myNodeList.forEach(function(node) { console.log(node_; });
+}}}
+
+== `[OmitConstructor]`, `[Immutable]`, `[MasqueradesAsUndefined]`, `[CustomGetOwnPropertySlot]`, `[ReplaceableConstructor]`, `[ExtendsDOMGlobalObject]`, `[IsIndex]`, `[NumericIndexedGetter]` == #OmitConstructor
 
 Might be deprecated. Discussion is on-going.
 
-== [ImplementationNameSpace] == #ImplementationNamespace
+== `[ImplementationNameSpace]` == #ImplementationNamespace
 
 Summary: Specifies the namespace for the corresponding native type.  
@@ -1813 +1406 @@
 By default, the namespace is WebCore.  This is presently used to mark WTF types.
 
-Usage: [ImplementationNamespace] can be specified on interfaces:
-{{{
-    interface [
+Usage: `[ImplementationNamespace]` can be specified on interfaces:
+{{{
+    [
         ImplementationNamespace=WTF
-    ] ArrayBuffer {
-    };
-}}}
-
-== [V8SkipVTableValidation], [ImplementationLacksVTable] == #V8SkipVTableValidation
-
-Summary: Specifies that a type can not be checked as part of the V8 Bindings Integrity option.
-
-V8 Bindings Integrity tries to ensure that free/corrupted objects are not wrapped by V8, thereby reducing their exploitability. In order for that to be the case, the implementation must have a distinct VTable pointer in its first word.
-
-Usage: [V8SkipVTableValidation] and [ImplementationLacksVTable] can be specified on interfaces.
-
-{{{
-    interface [
-        V8SkipVTableValidation
-    ] XXX {
-    };
-}}}
-
-{{{
-    interface [
+    ] interface ArrayBuffer {
+    };
+}}}
+
+== `[SkipVTableValidation]`, `[ImplementationLacksVTable]` == #SkipVTableValidation
+
+Summary: Specifies that a type can not be checked as part of the Bindings Integrity option.
+
+Bindings Integrity tries to ensure that free/corrupted objects are not wrapped by JSC, thereby reducing their exploitability. In order for that to be the case, the implementation must have a distinct VTable pointer in its first word.
+
+Usage: `[SkipVTableValidation]` and `[ImplementationLacksVTable]` can be specified on interfaces.
+
+{{{
+    [
+        SkipVTableValidation
+    ] interface XXX {
+    };
+}}}
+
+{{{
+    [
         ImplementationLacksVTable
-    ] XXX {
-    };
-}}}
+    ] interface XXX {
+    };
+}}}
+
+== `[NoInterfaceObject]`(i) == #NoInterfaceObject
+
+Standard: [http://dev.w3.org/2006/webapi/WebIDL/#NoInterfaceObject The spec of NoInterfaceObject]
+
+Summary: 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.
+
+Note that for every interface that:
+* 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 is added on the global Window object by the bindings generator.
+
+Usage: `[NoInterfaceObject]` can be specified on interfaces.
+
+{{{
+    [
+        NoInterfaceObject
+    ] interface XXX {
+        ...
+    };
+}}}