2011/3/3 Garrett Smith :
> On 3/2/11, Shiki Okasaka wrote:
>>>> * we want Node to inherit from EventTarget
>>> That can be stated in DOM Core. For example: The Node Interface
>>> implements EventTarget [Events Core].
>>
>> I guess the reason behind
>> * we want Node to inherit from EventTarget
> That can be stated in DOM Core. For example: The Node Interface
> implements EventTarget [Events Core].
I guess the reason behind this has been discussed around:
http://lists.w3.org/Archives/Public/public-script-coord/2010OctDec/0081.html
Actua
rmack :
> -minus various people
>
> Shiki Okasaka:
>> You've been missed, Cameron!
>>
>> Just a reminder, my wish list is here (this doesn't have to be
>> reflected in the very next WD, though):
>>
>> http://lists.w3.org/Archives/Public/public-script-c
You've been missed, Cameron!
Just a reminder, my wish list is here (this doesn't have to be
reflected in the very next WD, though):
http://lists.w3.org/Archives/Public/public-script-coord/2010JanMar/0003.html
A signed 8 bit integer type has been required in WebGL.
Best,
- Shiki
2010/10/12 Jo
I'd like to see the resolution for this, too.
If what is held inside the browser for a Date object is just a double
or a long long value of the JS [[PrimitiveValue]] internal property
for Date, I guess providing programming language specific bindings for
Date would be easy (java.util.Date in Java,
operty in ECMAScript, I
agree it would be very practical to have accessor properties on the
corresponding interface prototype objects.
Is there any plan to specify ES5 (or maybe existing ES getter/setter
implementation) binding in Web IDL?
Best,
- Shiki
>
> -Travis
>
> -Orig
s for the accessor (getter/setter) introduced in ECMAScript 5?
Regards,
- Shiki Okasaka
On Tue, Sep 1, 2009 at 2:07 PM, Travis Leithead wrote:
> Cameron et al.,
>
>
>
> I have a couple pieces of feedback on this draft.
>
>
>
> Let me start by saying that this is
, Jul 10, 2009 at 12:54 PM, Cameron McCormack wrote:
> Shiki Okasaka:
>> I see. Thanks Cameron. So even though it seems those can be replaced
>> by 'implements', is it not a plan?
>
> They could be replaced with ‘implements’, but not without breaking Java
> bind
> I think the “Object”, “TRUE” and “FALSE” keywords should be made
> lowercase.
It seems the lower case "object" has been used as an interface member
in HTMLAppletElement. Probably should we keep "Object" as it is? Both
"true" and "false" look fine with me.
- Shiki
, Cameron McCormack wrote:
> Shiki Okasaka:
>> 'InterfaceInheritance' is currently defined as a ScopedNameList or
>> epsilon. But in practice I don't see any web interface that actually
>> uses the multiple interface inheritance like,
>>
>> inter
Hi,
> Any other vestiages from the past in the IDL that seems ripe for change?
'InterfaceInheritance' is currently defined as a ScopedNameList or
epsilon. But in practice I don't see any web interface that actually
uses the multiple interface inheritance like,
interface X : A, B, C
{
}
>> If we are breaking syntax, then it seems more compelling to make
>> “DOMString” be “string”.
>>
>> Maybe we could drop the “in” keyword. Seems better to stick with
>> plain “in” arguments, for compatibility across language bindings,
>> than to also allow “out” and “inout” ones.
>
> I'd vote for
, Jun 17, 2009 at 6:15 PM, Cameron McCormack wrote:
> Shiki Okasaka:
>> The [AllowAny] extended attribute looks nice, and it will provide a
>> clearer ECMAScript runtime semantics. One thing still not very clear
>> to me is that a DOMString with [AllowAny] and a primit
with [AllowAny] like an 'any' type in an effective overload
set for simplicity?
Thank you,
- Shiki
ps. it's good to see the 'double' type in Web IDL.
On Wed, Jun 17, 2009 at 3:34 PM, Cameron McCormack wrote:
> Hi Shiki.
>
> Shiki Okasaka:
>> I've c
> Shiki, I notice that in your es-operating-system project you’re using
> booleans and strings in consts, but just in the test suite. Do you need
> these types in practice?
I think the use of string constants should be avoided to keep
specifications natural-language-neutral in practice even after
tedOn], [Optional],
and [Variadic] extended attributes, it might be better to avoid
operator overloading by using the same identifier as much as possible.
I may be missing some nuance here, but the current draft
specification, which does not distinguish primitive types for
overloaded operation resolut
ceable] readonly attribute unsigned value; # 'long' or 'short'
is missing after 'unsigned'
void increment();
};
Best,
--
Shiki Okasaka
Google
17 matches
Mail list logo
