On Fri, 19 Jun 2009, Cameron McCormack wrote:
An alternative would be to reverse the omission of methods, so that
“getter” on an operation would always have both the getter. Then if
you wanted to omit the method if getters are supported you could do
something like:
interface
This mail slipped my attention. Probably you know that these features
were added, but for completeness:
Ian Hickson:
It would be useful to be able to specify a method to implement [[Delete]]
on an interface.
You have [NameDeleter] and [IndexDeleter].
It would be useful to be able to define
Hi David.
David Andersson:
I think this algorithm as written is severely broken. The reason is
that [[HasProperty]] will travel the entire chain for each of the
interfaces in order.
…
I propose a change to instead use the C3 algorithm as used in Dylan,
Python 2.3, Perl 6:
A while ago I
Dear,
Very interesting part of the whole Widget Sorcery
Here are few comments
1) In the same spirit as WARP, it would be interesting to make HTML5
reference, an informative one
2) Probably the link between authority and opaque-autorithy should be clearer
3) Update reference to Working Draft
.
This feedback is extremely useful. I, too, would like the chance to
speak with the developers of (that particular application) as well as
with other developers.
Maciej said that the MobileMe developers gave pretty much the same feedback:
http://krijnhoetmer.nl/irc-logs/whatwg/20090619#l
On Fri, 19 Jun 2009 06:54:45 +0200, Cameron McCormack c...@mcc.id.au wrote:
So if we are happy to extend the IDL syntax, I think any extended
attribute that is intended to have some effect across all language
bindings should be moved to the syntax proper. Following are my half
baked
For what concerns the file as URI feature:
What about reusing the cid scheme?
- It would avoid collisions, as anything can be used as Content-ID,
including a progressive number or the name of the input element
- It would not be problematic to implement, as cid URIs are already
supported by
Hi Lachlan,
On Jun 17, 2009, at 14:15 , Lachlan Hunt wrote:
*CR Exit Criteria*
I propose the following as the CR exit criteria:
At least two interoperable implementations of each feature,
dependent upon the following conditions:
* Each individual test in the test suite must pass in at
Hi Cameron,
I will review your proposal in detail soon.
In general this seems fine to me. As long as you help reviewing
specifications that use Web IDL :-)
+1
Please bear in mind that there are specs that rely on Web IDL.
E.g. BONDI (http://bondi.omtp.org/1.0/)
defines in Web IDL:
178 methods,
Arun,
On Jun 18, 2009, at 23:02 , Arun Ranganathan wrote:
- For FileListDataCallback what happens if the user cancels? Do I
get an error? A defined but empty FileList? I have a slight
preference for the latter, but either way the author should be
notified.
I should make this clearer, but
On Jun 19, 2009, at 05:30 , Ian Hickson wrote:
On Fri, 19 Jun 2009, timeless wrote:
On Fri, Jun 19, 2009 at 4:13 AM, Arun Ranganathana...@mozilla.com
wrote:
Hixie, I think a Base64 representation of the file resource may be
sufficient, particularly for the image use case (which is how it
is
Hi Cameron,
On Jun 19, 2009, at 06:54 , Cameron McCormack wrote:
I’m thinking about removing some of the extended attributes in Web IDL
and replacing them with non-extension syntax in the language.
Originally, I had a goal of keeping compatibility with OMG IDL,
which is
why many features
On Jun 19, 2009, at 16:57 , Boris Zbarsky wrote:
Robin Berjon wrote:
* Test failures in a given implementation caused by the lack of
support
for a particular feature of an independent specification are not
counted.
I should note that if we consider WebIDL an independent
specification then
On Jun 19, 2009, at 17:14 , Lachlan Hunt wrote:
Robin Berjon wrote:
Out of curiosity, why not make it two interoperable implementations
of
*all* the tests, except those stemming from a lack of support for
CSS?
I was advised to set the requirements low so that it would be easier
to
Robin Berjon wrote:
Out of curiosity, why not make it two interoperable implementations of
*all* the tests, except those stemming from a lack of support for CSS?
I was advised to set the requirements low so that it would be easier to
proceed past CR. With these requirements, we can get past
On Fri, 19 Jun 2009, Robin Berjon wrote:
On Jun 19, 2009, at 17:14 , Lachlan Hunt wrote:
Robin Berjon wrote:
Out of curiosity, why not make it two interoperable implementations of
*all* the tests, except those stemming from a lack of support for CSS?
I was advised to set the
Reminder: the W3C is seeking input on prior art on Apple's 5,764,992
patent.
Details below.
-Regards, Art Barstow
Begin forwarded message:
From: ext Rigo Wenning r...@w3.org
Date: June 12, 2009 2:23:08 PM EDT
To: public-webapps@w3.org public-webapps@w3.org
Cc: widget-pag
The HTML5 spec says to fire the input event when the user changes a radio
button or a checkbox. However, the spec says When the input event applies,
any time the user causes the element's *value* to change. For
input[type=radio] and input[type=checkbox] the input event should be
fired any time the
feedback:
http://krijnhoetmer.nl/irc-logs/whatwg/20090619#l-90
Is it really that bad to wait with evaluating this feature until v1
is more widely deployed?
Given that we're still in WD, how about simply adding a note
indicating that this feature is under scrutiny (with pointers
On Thu, Jun 18, 2009 at 8:30 PM, Ian Hicksoni...@hixie.ch wrote:
On Fri, 19 Jun 2009, timeless wrote:
On Fri, Jun 19, 2009 at 4:13 AM, Arun Ranganathana...@mozilla.com wrote:
Hixie, I think a Base64 representation of the file resource may be
sufficient, particularly for the image use case
On Fri, Jun 19, 2009 at 2:10 PM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Jun 18, 2009 at 8:30 PM, Ian Hicksoni...@hixie.ch wrote:
On Fri, Jun 19, 2009 at 4:13 AM, Arun Ranganathana...@mozilla.com
wrote:
Hixie, I think a Base64 representation of the file resource may be
sufficient,
On Fri, 19 Jun 2009, Jonas Sicking wrote:
The problems that seems like they need to be solved are security (are
these URIs accessible by any domain), and lifetime (how long does the
URI work).
The security would be that the origin of these URLs is fixed to be the
origin of the script
Hi Oliver.
Oliver Hunt:
Conceivably the language could be a relatively simple and broad
statement along the lines of:
Any type conversions needed for a language binding should occur before
an API function is called, if a type conversion fails for any reason the
call should be aborted
Cameron McCormack:
Done:
The value of the internal [[Class]] property of a host object is
determined as follows:
* If the host object implements a single interface, then the value
of the internal [[Class]] property MUST be the identifier of
that interface.
Ian
24 matches
Mail list logo
