Changes between Version 94 and Version 95 of WebKitIDL
- Timestamp:
- May 8, 2013, 12:52:44 AM (12 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
WebKitIDL
v94 v95 607 607 Whether `[Reflect]` should be specified or not depends on the spec of each attribute. 608 608 609 == [Replaceable](a) == #Replaceable609 == `[Replaceable]`(a) == #Replaceable 610 610 611 611 * [http://dev.w3.org/2006/webapi/WebIDL/#Replaceable The spec of Replaceable] 612 612 613 Summary: [Replaceable]controls if a given attribute is "replaceable" or not.614 615 Usage: [Replaceable]can be specified on attributes:613 Summary: `[Replaceable]` controls if a given attribute is "replaceable" or not. 614 615 Usage: `[Replaceable]` can be specified on attributes: 616 616 {{{ 617 617 interface DOMWindow { … … 623 623 If you delete the new value, then the original value still remains. 624 624 625 Specifically, without [Replaceable], the attribute behaves as follows:625 Specifically, without `[Replaceable]`, the attribute behaves as follows: 626 626 {{{ 627 627 window.screenX; // Evaluates to 0 … … 632 632 }}} 633 633 634 With [Replaceable], the attribute behaves as follows:634 With `[Replaceable]`, the attribute behaves as follows: 635 635 {{{ 636 636 window.screenX; // Evaluates to 0 … … 641 641 }}} 642 642 643 Whether [Replaceable]should be specified or not depends on the spec of each attribute.644 645 == [Deletable](a), [NotEnumerable](a), [V8ReadOnly](a) == #Deletable643 Whether `[Replaceable]` should be specified or not depends on the spec of each attribute. 644 645 == `[Deletable]`(a), `[NotEnumerable]`(a), `[V8ReadOnly]`(a) == #Deletable 646 646 647 647 * [http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf The spec of Writable, Enumerable and Configurable (Section 8.6.1)] 648 648 649 Summary: They control Writability, Enumerability and Configurabilityof attributes.649 Summary: They control `Writability`, `Enumerability` and `Configurability` of attributes. 650 650 651 651 Usage: They can be specified on attributes: … … 656 656 }}} 657 657 658 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].659 660 * [Deletable]indicates that the attribute is deletable.661 * [NotEnumerable]indicates that the attribute is not enumerable.662 * [V8ReadOnly]indicates that the attribute is readonly in V8 even if the attribute is not prefixed by "readonly".663 664 == [CachedAttribute](a) == #CachedAttribute665 666 Summary: For performance optimization, [CachedAttribute]indicates that a wrapped object should be cached on a DOM object.667 668 Usage: [CachedAttribute]can be specified on attributes:658 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]`. 659 660 * `[Deletable]` indicates that the attribute is deletable. 661 * `[NotEnumerable]` indicates that the attribute is not enumerable. 662 * `[V8ReadOnly]` indicates that the attribute is readonly in V8 even if the attribute is not prefixed by "readonly". 663 664 == `[CachedAttribute]`(a) == #CachedAttribute 665 666 Summary: For performance optimization, `[CachedAttribute]` indicates that a wrapped object should be cached on a DOM object. 667 668 Usage: `[CachedAttribute]` can be specified on attributes: 669 669 {{{ 670 670 interface HTMLFoo { … … 674 674 }}} 675 675 676 Without [CachedAttribute], the normalValue getter works in the following way:677 678 1. HTMLFoo::normalValue()is called in WebCore.679 1. The result of HTMLFoo::normalValue() is passed to toJS() or toV8(), and is converted to a wrapped object.676 Without `[CachedAttribute]`, the normalValue getter works in the following way: 677 678 1. `HTMLFoo::normalValue()` is called in WebCore. 679 1. The result of `HTMLFoo::normalValue()` is passed to `toJS()` or `toV8()`, and is converted to a wrapped object. 680 680 1. The wrapped object is returned. 681 681 682 In case where HTMLFoo::normalValue()or the operation to wrap the result is weight,682 In case where `HTMLFoo::normalValue()` or the operation to wrap the result is weight, 683 683 you can cache the wrapped object onto the DOM object. 684 With [CachedAttribute], the normalValue getter works in the following way:684 With `[CachedAttribute]`, the normalValue getter works in the following way: 685 685 686 686 1. If the wrapped object is cached, the cached wrapped object is returned. That's it. 687 1. Otherwise, HTMLFoo::normalValue()is called in WebCore.688 1. The result of HTMLFoo::normalValue() is passed to toJS() or toV8(), and is converted to a wrapped object.687 1. Otherwise, `HTMLFoo::normalValue()` is called in WebCore. 688 1. The result of `HTMLFoo::normalValue()` is passed to `toJS()` or `toV8()`, and is converted to a wrapped object. 689 689 1. The wrapped object is cached. 690 690 1. The wrapped object is returned. 691 691 692 In particular, [CachedAttribute]will be useful for serialized values, since deserialization can be weight.693 Without [CachedAttribute], the serializedValue getter works in the following way:694 695 1. HTMLFoo::serializedValue()is called in WebCore.696 1. The result of HTMLFoo::serializedValue()is deserialized.697 1. The deserialized result is passed to toJS() or toV8(), and is converted to a wrapped object.692 In particular, `[CachedAttribute]` will be useful for serialized values, since deserialization can be weight. 693 Without `[CachedAttribute]`, the serializedValue getter works in the following way: 694 695 1. `HTMLFoo::serializedValue()` is called in WebCore. 696 1. The result of `HTMLFoo::serializedValue()` is deserialized. 697 1. The deserialized result is passed to `toJS()` or `toV8()`, and is converted to a wrapped object. 698 698 1. The wrapped object is returned. 699 699 700 In case where HTMLFoo::serializedValue(), the deserialization or the operation to wrap the result is weight,700 In case where `HTMLFoo::serializedValue()`, the deserialization or the operation to wrap the result is weight, 701 701 you can cache the wrapped object onto the DOM object. 702 With [CachedAttribute], the serializedValue getter works in the following way:702 With `[CachedAttribute]`, the serializedValue getter works in the following way: 703 703 704 704 1. If the wrapped object is cached, the cached wrapped object is returned. That's it. 705 1. Otherwise, HTMLFoo::serializedValue()is called in WebCore.706 1. The result of HTMLFoo::serializedValue()is deserialized.707 1. The deserialized result is passed to toJS() or toV8(), and is converted to a wrapped object.705 1. Otherwise, `HTMLFoo::serializedValue()` is called in WebCore. 706 1. The result of `HTMLFoo::serializedValue()` is deserialized. 707 1. The deserialized result is passed to `toJS()` or `toV8()`, and is converted to a wrapped object. 708 708 1. The wrapped object is cached. 709 709 1. The wrapped object is returned. … … 714 714 In addition, setters always need to invalidate the cache. 715 715 716 == [V8Unforgeable](m,a), [V8OnProto](m,a) == #V8Unforgeable716 == `[V8Unforgeable]`(m,a), `[V8OnProto]`(m,a) == #V8Unforgeable 717 717 718 718 * [http://dev.w3.org/2006/webapi/WebIDL/#Unforgeable The spec of Unforgeable] … … 730 730 731 731 If you want to explicitly control where an attribute getter/setter or a method is defined in V8, 732 you can use [V8Unforgeable] or [V8OnProto].733 734 * [V8Unforgeable]indicates that an attribute getter/setter or a method should be defined on a DOM object.735 * [V8OnProto]indicates that an attribute getter/setter or a method should be defined on a prototype chain.732 you can use `[V8Unforgeable]` or `[V8OnProto]`. 733 734 * `[V8Unforgeable]` indicates that an attribute getter/setter or a method should be defined on a DOM object. 735 * `[V8OnProto]` indicates that an attribute getter/setter or a method should be defined on a prototype chain. 736 736 737 737 Note: As explained above, the current implementation of JSC and V8 is wrong with the Web IDL spec, 738 and [V8Unforgeable] and [V8OnProto]are used for hack.738 and `[V8Unforgeable]` and `[V8OnProto]` are used for hack. 739 739 You should not use them unless you have a strong reason to use them. 740 740 741 == [URL](a) == #URL742 743 Summary: [URL]indicates that a given DOMString represents a URL.744 745 Usage: [URL]can be specified on DOMString attributes only:741 == `[URL]`(a) == #URL 742 743 Summary: `[URL]` indicates that a given DOMString represents a URL. 744 745 Usage: `[URL]` can be specified on DOMString attributes only: 746 746 {{{ 747 747 attribute [Reflect, URL] DOMString url; 748 748 }}} 749 749 750 You need to specify [URL]if a given DOMString represents a URL,751 since getters of URL attributes need to be realized in a special routine in WebKit, i.e. Element::getURLAttribute(...).752 If you forgot to specify [URL], then the attribute getter might cause a bug.753 754 == [JSWindowEventListener](a) FIXME == #JSWindowEventListener750 You need to specify `[URL]` if a given DOMString represents a URL, 751 since getters of URL attributes need to be realized in a special routine in WebKit, i.e. `Element::getURLAttribute(...)`. 752 If you forgot to specify `[URL]`, then the attribute getter might cause a bug. 753 754 == `[JSWindowEventListener]`(a) FIXME == #JSWindowEventListener 755 755 756 756 Summary: ADD SUMMARY 757 757 758 Usage: [JSWindowEventListener] can be specified on EventListenerattributes only:758 Usage: `[JSWindowEventListener]` can be specified on `EventListener` attributes only: 759 759 {{{ 760 760 attribute [JSWindowEventListener] EventListener onload; … … 763 763 ADD EXPLANATIONS 764 764 765 == [Constructor](i), [CallWith](i,m,a), [ConstructorRaisesException](i) == #Constructor765 == `[Constructor]`(i), `[CallWith]`(i,m,a), `[ConstructorRaisesException]`(i) == #Constructor 766 766 767 767 * [http://dev.w3.org/2006/webapi/WebIDL/#Constructor The spec of Constructor] 768 768 769 Summary: [Constructor]indicates that the interface should have constructor, i.e. "new XXX()".770 [CallWith] and [ConstructorRaisesException]adds information when the constructor callback is called in WebCore.771 772 Usage: [Constructor], [CallWith] and [ConstructorRaisesException]can be specified on interfaces:769 Summary: `[Constructor]` indicates that the interface should have constructor, i.e. "new XXX()". 770 `[CallWith]` and `[ConstructorRaisesException]` adds information when the constructor callback is called in WebCore. 771 772 Usage: `[Constructor]`, `[CallWith]` and `[ConstructorRaisesException]` can be specified on interfaces: 773 773 {{{ 774 774 interface [ … … 780 780 }}} 781 781 782 [Constructor(float x, float y, DOMString str)]means that the interface has a constructor783 and the constructor signature is (float x, float y, DOMString str).782 `[Constructor(float x, float y, DOMString str)]` means that the interface has a constructor 783 and the constructor signature is `(float x, float y, DOMString str)`. 784 784 Specifically, JavaScript can create a DOM object of XXX by the following code: 785 785 {{{ 786 786 var x = new XXX(1.0, 2.0, "hello"); 787 787 }}} 788 Then XXX::create(float x, float y, String str)is called in WebCore.788 Then `XXX::create(float x, float y, String str)` is called in WebCore. 789 789 That way WebCore needs to implement the following method as a constructor callback: 790 790 {{{ … … 795 795 }}} 796 796 797 [Constructor()] is equivalent to [Constructor].798 799 If XXX::create(...) can throw Exception, you can use [ConstructorRaisesException].800 With [ConstructorRaisesException], a placeholder for ExceptionCode is added to the tail argument of XXX::create(...).797 `[Constructor()]` is equivalent to `[Constructor]`. 798 799 If `XXX::create(...)` can throw Exception, you can use `[ConstructorRaisesException]`. 800 With `[ConstructorRaisesException]`, a placeholder for ExceptionCode is added to the tail argument of `XXX::create(...)`. 801 801 {{{ 802 802 PassRefPtr<XXX> XXX::create(float x, float y, String str, ExceptionCode& ec) … … 810 810 }}} 811 811 812 If XXX::create(...)needs additional information like ScriptExecutionContext and ScriptState,813 you can specify [CallWith=ScriptExecutionContext|ScriptState].814 Then XXX::create(...)can have the following signature:812 If `XXX::create(...)` needs additional information like ScriptExecutionContext and ScriptState, 813 you can specify `[CallWith=ScriptExecutionContext|ScriptState]`. 814 Then `XXX::create(...)` can have the following signature: 815 815 {{{ 816 816 PassRefPtr<XXX> XXX::create(ScriptExecutionContext* context, ScriptState* state, float x, float y, String str) … … 822 822 Please see [#CallWith another [CallWith] section] for more details. 823 823 824 Note that [CallWith=...] arguments are added at the head of XXX::create(...)'s arguments,825 and the ExceptionCode argument is added at the tail of XXX::create(...)'s arguments.824 Note that `[CallWith=...]` arguments are added at the head of `XXX::create(...)`'s arguments, 825 and the ExceptionCode argument is added at the tail of `XXX::create(...)`'s arguments. 826 826 827 827 Whether you should allow an interface to have constructor depends on the spec of the interface. 828 828 829 Note: Currently [Constructor(...)] does not yet support optional arguments w/o defaults. It just supports optional [Default=Undefined] or optional [Default=NullString].829 Note: Currently `[Constructor(...)]` does not yet support optional arguments w/o defaults. It just supports `[Default=Undefined] optional` or `[Default=NullString] optional`. 830 830 831 831 == [ConstructorTemplate](i), [InitializedByEventConstructor](a) == #ConstructorTemplate