On Tue, 7 Sep 2010, Darin Fisher wrote:
>
> Based on the ValidityState example, it seems that the members of Flags
> should be camelCase then instead of UPPERCASE?
The platform convention, insofar as there is a convention, is that
constants are uppercase, members are camelCase, and interfaces a
On Tue, Sep 7, 2010 at 5:23 PM, Kenneth Russell wrote:
> On Tue, Sep 7, 2010 at 4:19 PM, Nathan wrote:
> > Jian Li wrote:
> >>
> >> Hi,
> >>
> >> Several specs, like File API and WebGL, use ArrayBuffer, while other
> spec,
> >> like XMLHttpRequest Level 2, use ByteArray. Should we change to use
On Tue, Sep 7, 2010 at 8:41 PM, Ian Hickson wrote:
> On Tue, 7 Sep 2010, Adam Barth wrote:
> >
> > I think the bitfield approach is better. The current approach doesn't
> > work very well in strongly typed languages. Although we might think
> > that these APIs will be used most-often from JavaS
> On Tue, 7 Sep 2010, Arun Ranganathan wrote:
> >
> > It *does* seems sensible to use DOMException instead of
> > FileException in
> > the synchronous case (on WebWorkers). But in the asynchronous case,
> > DOMError seems a bit janky
> > (http://www.w3.org/TR/DOM-Level-3-Core/core.html#ERROR-Interf
On Tue, 7 Sep 2010, Adam Barth wrote:
>
> I think the bitfield approach is better. The current approach doesn't
> work very well in strongly typed languages. Although we might think
> that these APIs will be used most-often from JavaScript, these APIs are
> language neutral and should work in
On Tue, 7 Sep 2010, Arun Ranganathan wrote:
>
> It *does* seems sensible to use DOMException instead of FileException in
> the synchronous case (on WebWorkers). But in the asynchronous case,
> DOMError seems a bit janky
> (http://www.w3.org/TR/DOM-Level-3-Core/core.html#ERROR-Interfaces-DOMErr
On Tue, Sep 7, 2010 at 6:07 PM, Eric Uhrhane wrote:
> On Tue, Sep 7, 2010 at 12:41 AM, Kinuko Yasuda wrote:
>> Hi Eric,
>> (re-sending from the correct address)
>>
>> I've been re-reading the spec and started wondering if we really want to
>> have a new interface / javascript object for Flags.
>>
- Original Message -
> On Mon, 6 Sep 2010, Nathan wrote:
> >
> > Just noticed that File API specifies NOT_READABLE_ERR as code 24,
> > whereas 24 is already used for DATA_CLONE_ERR
> > http://dev.w3.org/html5/spec/common-dom-interfaces.html#data_clone_err
> >
> > Not sure if this is an issu
On Mon, Aug 30, 2010 at 9:27 PM, Kinuko Yasuda wrote:
> Hi,
> I have a question about Entry.moveTo/copyTo behavior defined in
> the File API: Directories and System [1].
> Currently the API doesn't specify how Entry.moveTo() and copyTo() should
> behave
> when a source entry is a file and there's
On Tue, Sep 7, 2010 at 12:41 AM, Kinuko Yasuda wrote:
> Hi Eric,
> (re-sending from the correct address)
>
> I've been re-reading the spec and started wondering if we really want to
> have a new interface / javascript object for Flags.
> The Flags interface is used to specify two behavioral option
On Mon, Sep 6, 2010 at 12:27 PM, Ian Hickson wrote:
> On Mon, 6 Sep 2010, Nathan wrote:
>>
>> Just noticed that File API specifies NOT_READABLE_ERR as code 24,
>> whereas 24 is already used for DATA_CLONE_ERR
>> http://dev.w3.org/html5/spec/common-dom-interfaces.html#data_clone_err
>>
>> Not sure
On Tue, Sep 7, 2010 at 4:19 PM, Nathan wrote:
> Jian Li wrote:
>>
>> Hi,
>>
>> Several specs, like File API and WebGL, use ArrayBuffer, while other spec,
>> like XMLHttpRequest Level 2, use ByteArray. Should we change to use the
>> same
>> name all across our specs? Since we define ArrayBuffer in
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10143
Ian 'Hixie' Hickson changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10131
Ian 'Hixie' Hickson changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
Jian Li wrote:
Hi,
Several specs, like File API and WebGL, use ArrayBuffer, while other spec,
like XMLHttpRequest Level 2, use ByteArray. Should we change to use the same
name all across our specs? Since we define ArrayBuffer in the Typed Arrays
spec (
https://cvs.khronos.org/svn/repos/registry/
Hi,
Several specs, like File API and WebGL, use ArrayBuffer, while other spec,
like XMLHttpRequest Level 2, use ByteArray. Should we change to use the same
name all across our specs? Since we define ArrayBuffer in the Typed Arrays
spec (
https://cvs.khronos.org/svn/repos/registry/trunk/public/webg
OK, thank you Darin :) This alleviates the naming tension.
FileReader, FileException, and FileError it is, then.
(Eliminating Blob from the inheritance hierarchy causes the problems Darin
mentions below).
On Mon, Aug 30, 2010 at 10:52 PM, Anne van Kesteren < ann...@opera.com > wrote:
Hello Webapps WG,
(This is a personal comment and is not necessarily indicative of the I18N WG's
opinion)
In Section 5 (The Widget Interface), the interface provides for retrieving
values such as 'name', 'shortName', etc. In Widgets P&C, these can be localized
in the configuration document (I
On Tue, Sep 7, 2010 at 12:12 PM, Adrian Bateman wrote:
> On Tuesday, September 07, 2010 11:46 AM, Chris Prince wrote:
> > >> 1. Most people that I talk to dislike the name Blob, much less having
> > >> it spread to things like BlobReader.
> >
> > I could maybe understand this if "blob" were a new
On Tue, Sep 7, 2010 at 11:45 AM, Chris Prince wrote:
>>> 1. Most people that I talk to dislike the name Blob, much less having
>>> it spread to things like BlobReader.
>
> I could maybe understand this if "blob" were a new term we were
> inventing. But it's not. It's a well-known computer scienc
On Tuesday, September 07, 2010 11:46 AM, Chris Prince wrote:
> >> 1. Most people that I talk to dislike the name Blob, much less having
> >> it spread to things like BlobReader.
>
> I could maybe understand this if "blob" were a new term we were
> inventing. But it's not. It's a well-known compu
Hi all.
Stumbled across this article on Ars Technica regarding the abuse of the
WebSQL spec. I thought I'd share it here for a couple of reasons:
1. Someone might want to point out that it's part of the Offline Storage
Spec, not strictly HTML5.
2. Security implications may inform some as
On Tue, Sep 7, 2010 at 2:22 AM, Anne van Kesteren wrote:
> On Tue, 07 Sep 2010 11:12:27 +0200, Jonas Sicking wrote:
>>
>> On Tue, Sep 7, 2010 at 2:06 AM, Anne van Kesteren
>> wrote:
>>>
>>> On Tue, 07 Sep 2010 10:47:01 +0200, Jonas Sicking
>>> wrote:
For what it's worth, we still thro
This is a Request for Comments (RfC) for a new Last Call Working Draft
(LCWD) of the Widget Interface spec that was published on September 7:
http://www.w3.org/TR/2010/WD-widgets-apis-20100907/
Changes since the last publication (December 2009 Candidate
Recommendation) are summarized in
On 8/21/10 3:39 PM, J David Eisenberg wrote:
Is it possible to extend the spec to allow a script to read any file that
can been loaded as part of the HTML page, such as an?
That would be a security hole, sorry.
I understand there are good security reasons for restricting file
reads; you don't
On Tue, 07 Sep 2010 11:12:27 +0200, Jonas Sicking wrote:
On Tue, Sep 7, 2010 at 2:06 AM, Anne van Kesteren
wrote:
On Tue, 07 Sep 2010 10:47:01 +0200, Jonas Sicking
wrote:
For what it's worth, we still throw WRONG_DOCUMENT_ERR in a few places
in gecko:
http://mxr.mozilla.org/mozilla-cent
On Tue, Sep 7, 2010 at 2:06 AM, Anne van Kesteren wrote:
> On Tue, 07 Sep 2010 10:47:01 +0200, Jonas Sicking wrote:
>>
>> For what it's worth, we still throw WRONG_DOCUMENT_ERR in a few places in
>> gecko:
>>
>>
>> http://mxr.mozilla.org/mozilla-central/search?string=WRONG_DOCUMENT_ERR&find=\.cpp
On Tue, 07 Sep 2010 10:47:01 +0200, Jonas Sicking wrote:
For what it's worth, we still throw WRONG_DOCUMENT_ERR in a few places
in gecko:
http://mxr.mozilla.org/mozilla-central/search?string=WRONG_DOCUMENT_ERR&find=\.cpp
Some, but likely not all, of these can and should probably be removed.
On Mon, Sep 6, 2010 at 7:20 PM, Anne van Kesteren wrote:
> On Mon, 06 Sep 2010 21:29:57 +0200, Ian Hickson wrote:
>>
>> On Mon, 6 Sep 2010, Anne van Kesteren wrote:
>>>
>>> This alternative would not throw HIERARCHY_REQUEST_ERR as much (maybe
>>> even not at all)
>>
>> Can you elaborate on this p
Hi Eric,
(re-sending from the correct address)
I've been re-reading the spec and started wondering if we really want to
have a new interface / javascript object for Flags.
The Flags interface is used to specify two behavioral options (CREATE and
EXCLUSIVE) for DirectoryEntry.getFile and getDirecto
30 matches
Mail list logo
