Re: CfC: to publish a new WD of the DOM3 Events spec; deadline Sep 4
Arthur Barstow: This is a Call for Consensus (CfC) to publish a new WD of the DOM 3 Events spec: http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html +1 -- Cameron McCormack ≝ http://mcc.id.au/
Re: [widgets] PC, assertion in wrong spec
On Aug 30, 2009, at 18:54 , Marcos Caceres wrote: Oh yeah, explaining why would help:) Like with the UI product from the prev email, this UA does not execute or deal with scripts. It only deals with processing config.xml and zip files. It should not behave as a policy enforcement point. I think this requirement isn't appropriate for what we should consider a strict P+C UA. As such, this bug could be addressed in a number of ways including making the text non-normative, removing the text from the spec, etc. The text could also be included in a document that describes or defines a Widget [runtime] User Agent. I've requested that Robin add this text to the Widget URI spec. I think this text should live there for now, until we see if we have enough requirements to make a Widget UA spec. Actually I think that the two issues should be kept separate. This may have a room in the WURI spec because it's about enforcing access rules for certain URIs. I tend to think that the WUA spec is different: it's what you conform to if you're a UA. It would include some UI shoulds, and arguably a pointer to all the specs in the family (i.e. it could be the profile spec). -- Robin Berjon - http://berjon.com/
[webdatabase] Transaction Locks
Hi, In the processing model [1], step 2 says: If an error occurred in the opening of the transaction (e.g. if the user agent failed to obtain an appropriate lock after an appropriate delay), jump to the last step. It's not clear if the spec requires the transaction to fail to open in the case that it can't yet obtain an appropriate lock, or whether the spec just allows that as an implementation decision. According to our developer, the way we've implemented it is that we will always create a new transaction and run the transaction callback, but the SQL statements themselves will be queued up and run whenever the lock becomes available. There is no timeout that will cause it to invoke the error callback. Is this acceptable, or should the transaction callback not be run while there is another lock in effect on the database? [1] http://dev.w3.org/html5/webdatabase/#processing-model -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
[WebDatabase] Ready for First Public WD?
Hi Ian, All, Is the Web Database spec ready for a First Public Working Draft [1]? http://dev.w3.org/html5/webdatabase/ If not, what needs to be done before it is ready for FPWD and what is the best guestimate as to when it will be ready? -Regards, Art Barstow [1] http://www.w3.org/2005/10/Process-20051014/tr.html#first-wd
Re: [widget] relax NG schema
On Aug 31, 2009, at 15:58 , Marcos Caceres wrote: As we have partitioned the PC spec into multiple specs, the RelaxNG schema is no longer complete (e.g., excludes updates and warp). I suggest we rip the relax NG schema out of the PC spec and republish it as a non-normative note. That way, we can update it separately if we spawn any new specs or if things change. That's one option. Another option is to define it using groups, and have the other specs compose their additions in the groups. It's not very hard to do. -- Robin Berjon - http://berjon.com/
Re: [widget] relax NG schema
Robin Berjon wrote: On Aug 31, 2009, at 15:58 , Marcos Caceres wrote: As we have partitioned the PC spec into multiple specs, the RelaxNG schema is no longer complete (e.g., excludes updates and warp). I suggest we rip the relax NG schema out of the PC spec and republish it as a non-normative note. That way, we can update it separately if we spawn any new specs or if things change. That's one option. Another option is to define it using groups, and have the other specs compose their additions in the groups. It's not very hard to do. Bah, sounds messy. Better to have everything in one place. Then you don't need to go hunting around.
WebDatabase open interface methods
There seems to be no difference between the openDatabase methods
defined in WindowDatabase and WorkerUtilsDatabase.
Is it possible to restructure these interfaces differently so that
there is less redundancy?
My proposal is the following IDL:
[Supplemental, NoInterfaceObject]
interface DatabaseAsyncOpen {
Database openDatabase(in DOMString name, in DOMString version, in
DOMString displayName, in unsigned long estimatedSize, in optional
DatabaseCallback creationCallback);
};
Window implements DatabaseAsyncOpen;
[Supplemental, NoInterfaceObject]
interface DatabaseSyncOpen {
DatabaseSync openDatabaseSync(in DOMString name, in DOMString
version, in DOMString displayName, in unsigned long estimatedSize, in
optional DatabaseCallback creationCallback);
};
WorkerUtils implements DatabaseSyncOpen;
WorkerUtils implements DatabaseAsyncOpen;
Nikunj
http://o-micron.blogspot.com
WebStorage and WebDatabase - creation and exceptions
In WebDatabase: The user agent may raise a SECURITY_ERR exception instead of returning a Database object if the request violates a policy decision (e.g. if the user agent is configured to not allow the page to open databases). In WebStorage (emphasis mine): When a new HTMLDocument is created, the user agent must check to see if the document's top-level browsing context has allocated a session storage area for that document's origin. If it has not, a new storage area for that document's origin must be created. When the localStorage attribute is accessed, the user agent must check to see if it has allocated a local storage area for the origin of the Document of the Window object on which the method was invoked. If it has not, a new storage area for that origin must be created. A browser may not allow local storage for a certain origin, just like it may not allow cookies to be stored. What is the expected behavior in that case? Alternatively, why allow browsers to selectively block out WebDatabase and not other kinds of storage? Nikunj http://o-micron.blogspot.com
Re: [widget] relax NG schema
On Mon, Aug 31, 2009 at 4:10 PM, Robin Berjonro...@berjon.com wrote: On Aug 31, 2009, at 15:58 , Marcos Caceres wrote: As we have partitioned the PC spec into multiple specs, the RelaxNG schema is no longer complete (e.g., excludes updates and warp). I suggest we rip the relax NG schema out of the PC spec and republish it as a non-normative note. That way, we can update it separately if we spawn any new specs or if things change. That's one option. Another option is to define it using groups, and have the other specs compose their additions in the groups. It's not very hard to do. +1 for using groups Xmlizer
CfC: to publish the First Public Working Draft of Web Database spec; deadline 7 September
This is a Call for Consensus (CfC) to publish the First Public Working Draft (FPWD) of the Web Database spec: http://dev.w3.org/html5/webdatabase/ Note that at one point in time, the Web Database spec's functionality was included in the Web Storage spec. As with all of our CfCs, positive response is preferred and encouraged and silence will be assumed to be assent. The deadline for comments is September 7. -Regards, Art Barstow
CfC: to publish a new Working Draft of Web Storage spec; deadline 7 September
This is a Call for Consensus (CfC) to publish a new WD of the Web Storage spec: http://dev.w3.org/html5/webstorage/ As with all of our CfCs, positive response is preferred and encouraged and silence will be assumed to be assent. The deadline for comments is September 7. -Regards, Art Barstow
Re: [widget] relax NG schema
On Aug 31, 2009, at 8:06 PM, mozer xmli...@gmail.com wrote: On Mon, Aug 31, 2009 at 4:10 PM, Robin Berjonro...@berjon.com wrote: On Aug 31, 2009, at 15:58 , Marcos Caceres wrote: As we have partitioned the PC spec into multiple specs, the RelaxNG schema is no longer complete (e.g., excludes updates and warp). I suggest we rip the relax NG schema out of the PC spec and republish it as a non-normative note. That way, we can update it separately if we spawn any new specs or if things change. That's one option. Another option is to define it using groups, and have the other specs compose their additions in the groups. It's not very hard to do. +1 for using groups Ok, what are these crazy groups you speak of? Please explain. Xmlizer
Re: [webdatabase] Transaction Locks
1. Open a new SQL transaction to the database, and create a SQLTransactionhttp://dev.w3.org/html5/webdatabase/#sqltransaction object that represents that transaction. If the *mode* is read/write, the transaction must have an exclusive write lock over the entire database. If the *mode* is read-only, the transaction must have a shared read lock over the entire database. The user agent should wait for an appropriate lock to be available. 2. If an error occurred in the opening of the transaction (e.g. if the user agent failed to obtain an appropriate lock after an appropriate delay), jump to the last step. 3. If a *preflight operation* was defined for this instance of the transaction steps, run that. If it fails, then jump to the last step. (This is basically a hook for the changeVersion()http://dev.w3.org/html5/webdatabase/#dom-database-changeversion method.) 4. Queue a task to invoke the *transaction callback* with the aforementioned SQLTransactionhttp://dev.w3.org/html5/webdatabase/#sqltransaction object as its only argument, and wait for that task to be run. 10. (last) Queue a task to invoke the *error callback* with a newly constructed SQLError http://dev.w3.org/html5/webdatabase/#sqlerror object that represents the last error to have occurred in this transaction. Rollback the transaction. Any still-pending statements in the transaction are discarded. I think its clear what the intent is. A failure to acquire the lock (BEGIN fails) leads to an error callback w/o having called the transaction callback. At least thats my reading of it. On Mon, Aug 31, 2009 at 4:37 AM, Lachlan Hunt lachlan.h...@lachy.id.auwrote: Hi, In the processing model [1], step 2 says: If an error occurred in the opening of the transaction (e.g. if the user agent failed to obtain an appropriate lock after an appropriate delay), jump to the last step. It's not clear if the spec requires the transaction to fail to open in the case that it can't yet obtain an appropriate lock, or whether the spec just allows that as an implementation decision. According to our developer, the way we've implemented it is that we will always create a new transaction and run the transaction callback, but the SQL statements themselves will be queued up and run whenever the lock becomes available. There is no timeout that will cause it to invoke the error callback. Is this acceptable, or should the transaction callback not be run while there is another lock in effect on the database? [1] http://dev.w3.org/html5/webdatabase/#processing-model -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Exceptions in WebDatabase
After studying the current error codes in the WebDatabase spec, it is
clear that they are neither an exhaustive, nor a systematic
arrangement. As a result, applications will have a hard time
performing recovery with or without user help. To improve on this, I
analyzed the JDBC SQL exception hierarchy and matched it against the
WebDatabase spec.
Here are my findings about the main categories of exceptions and their
causes:
Non transient exception - a retry of the same operation would fail
unless the cause of the SQLException is corrected
Non transient connection exception - the connection operation that
failed will not succeed when the operation is retried without the
cause of the failure being corrected.
Syntax error exception - in-progress query has violated SQL syntax
rules.
Integrity constraint violation exception - an integrity constraint
(foreign key, primary key or unique key) has been violated.
Data exception - indicates various data errors, including but not
limited to not-allowed conversion, division by 0 and invalid arguments
to functions.
Feature not supported exception - UA does not support an optional
WebDatabase feature
Serialization exception - an error with the serialization or de-
serialization of SQL types or with the size of the data being returned
Recoverable exception - a previously failed operation might be able to
succeed if the application performs some recovery steps and retries
the entire transaction
Transient exception - a previoulsy failed operation might be able to
succeed when the operation is retried without any intervention by
application-level functionality.
Timeout exception - the timeout has expired without obtaining
necessary locks.
Transaction rollback exception - the current statement was
automatically rolled back by the database becuase of deadlock or other
transaction serialization failures.
Of these exception conditions:
VERSION_ERR corresponds to the Non transient connection exception
condition
SYNTAX_ERR corresponds to the Syntax error exception condition
CONSTRAINT_ERR corresponds to the Integrity constraint violation
exception condition
TOO_LARGE_ERR corresponds to the Serialization exception condition
QUOTA_ERR corresponds to the Recoverable exception condition
TIMEOUT_ERR corresponds to the timeout exception condition
On the other hand, the following errors say nothing about what the
application can do:
UNKNOWN_ERR and DATABASE_ERR
Here is a proposal for error codes that allows better recovery for
applications:
Constant, Code, description
NON_TRANSIENT_ERR, 1, cannot retry statement as is
VERSION_ERR, 2
SYNTAX_ERR, 3
CONSTRAINT_ERR, 4
DATA_ERR, 5
FEATURE_ERR, 6
SERIAL_ERR, 11, change something about the size of the result set to
continue
TOO_LARGE_ERR, 12
RECOVERABLE_ERR, 21, retry after taking some user action
QUOTA_ERR, 22
TRANSIENT_ERR, 31, retry after some time, without needing any user
action
TIMEOUT_ERR, 32
Since the UNKNOWN_ERR is unrelated to the database itself, I think we
can leave it unchanged. I do think that either DATABASE_ERR has to
clearly state the kind of problem that occurred, or else
Since the error codes in SQLException are local to WebDatabase, we
would need an additional state variable in the SQLException exception
that would identify the kind of problem encountered in the
implementation. XOPEN and SQL:2003 provide a full scheme of
identifiers that can be used for such reporting, which is needed in
applications so that appropriate action can be taken.
Based on both the above points, here's a proposed IDL for SQLException
exception SQLException {
const unsigned short UNKNOWN_ERR = 0;
const unsigned short NON_TRANSIENT_ERR = 1;
const unsigned short VERSION_ERR = 2;
const unsigned short SYNTAX_ERR = 3;
const unsigned short CONSTRAINT_ERR = 4;
const unsigned short DATA_ERR = 5;
const unsigned short FEATURE_ERR = 6;
const unsigned short SERIAL_ERR = 11;
const unsigned short TOO_LARGE_ERR = 12;
const unsigned short RECOVERABLE_ERR = 21;
const unsigned short QUOTA_ERR = 22;
const unsigned short TRANSIENT_ERR = 31;
const unsigned short TIMEOUT_ERR = 32;
unsigned short code;
DOMString sqlState;
DOMString message;
};
Nikunj
http://o-micron.blogspot.com
WebDatabase review: SQLResultSetRowList
SQLResultSetRowList The item() method may take a long time to process. Shouldn't this have an asynchronous version with a callback? The ability to randomly access rows in the row set increases the likelihood that the item operation will take an arbitrarily long time. Plus, supporting random access is very expensive on limited memory devices. Offer next() and previous() methods that returns the next and previous row respectively. Offer absolute() and relative() call that may fail. See java.sql.ResultSet.absolute() and java.sql.ResultSet.relative(). The length attribute could require accessing all the rows, which would use too much memory on limited memory devices. Specify that the SQLResultSetRowList that resulted from a call to SQLTransaction.executeSql() can only be accessed during the execution of the associated SQLStatementCallback Property names on result sets are based on column names used in the query or defined in the view/table. These name sources (colmns, selections) are case insensitive but the row object would have to use case-sensitive names. Is there a way that objects can be accessed without case insensitivity? Nikunj http://o-micron.blogspot.com
Re: [File API] feedback on August 1/5 draft
Anne van Kesteren wrote: On Sat, 22 Aug 2009 11:30:18 +0200, Simon Pieters sim...@opera.com wrote: On Wed, 12 Aug 2009 17:22:53 +0200, Arun Ranganathan a...@mozilla.com wrote: http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html Maybe the attribute should be called URL for consistency with HTMLDocument.URL? And also WebSocket.URL and EventSource.URL. I'll change this to be consistent. -- A*
Re: File API to separate reading from files
On Wed, Aug 19, 2009 at 11:47 AM, Nikunj R.
Mehtanikunj.me...@oracle.com wrote:
Here's an alternative, more easily extensible, proposal for reading files.
It provides applications a way to read small amounts of data at a time. It
also allows applications to concurrently read the same file.
I Agree.
[snip]
[snip example]
Secondly, a list of files can be obtained using some UI.
typedef sequenceFile FileList;
Agree.
Thirdly, an abstract interface is an input stream that is not limited to
files. It works at the level of bytes that files are made of. The read()
operation can specify the extent that is required. If an application wishes
to read small increments, it can thus specify those increments. Of course,
the File interface identifies its size, so the application can suitably
choose increments. Processing of blocks read from the file occurs in
callbacks. XHR could also consider taking an InputStream parameter during
the send() operation.
Would it be possible to have a reader handle creating the input stream
and making the decision based on what type of Reader it is, passing
byte offset lengths to the input stream -- essentially hiding those
details?
[snip example]
Fifthly, a file can be used for reading an input stream by specifying the
name of a file when constructing the stream
[Constructor(in File toOpen)]
interface FileInputStream : InputStream {
}
Sixthly, one can create various kinds of derived readers such as text
reader, binary string reader, and data URL reader. By inheriting from
InputStream, the basic mechanisms such as abort and onerror are inherited.
Moreover, the base read behavior is altered by the subclass although it
behaves in a similar manner, except that the data seen outside is different.
[Constructor(in InputStream base)]
interface BinaryStringInputStream : InputStream {
read(in StringDataHandler, [optional in] long long offset, [optional in]
long long length);
}
The callback is provided a DOMString. The String's length is expected to
match the increment requested.
[CallBack=FunctionOnly]
interface StringDataHandler {
handle(in DOMString data);
}
For text reading, encoding is optionally specified.
[Constructor(in InputStream base, [optional in] DOMString encoding)]
interface TextInputStream : InputStream {
read(in StringDataHandler, [optional in] long long offset, [optional in]
long long length);
}
A file can be alternatively read as a dataURL using a similar kind of
handler as above.
[Constructor(in InputStream base)]
interface FileDataURL: InputStream {
read(in StringDataHandler, [optional in] long long offset, [optional in]
long long length);
}
This API has the advantage that it can cleanly be extended to deal with both
writing use cases and binary data. Furthermore, it can also support
extensions that perform cryptographic, compression, or coding on top of the
basic interfaces.
To compare with the editor's draft, here's a typical programming case in
JavaScript:
var fileList = ...
// There is a mistake in the example provided in Section 3 where it does
fileList.files[0]
var myFile = fileList[0];
That's odd.
// *According to my proposal*
var stream = new TextInputStream(new FileInputStream(myFile), UTF-16);
stream.read(handleDataAsText);
// don't you need to add the onerror before read()?
stream.onerror = errorHandler;
function handleDataAsText(fileContent) {
}
function errorHandler(error) {
}
Note the two differences:
1. Error handling is separated from file reading
Right. Method handleDataAsText does one thing only, as does the error handler.
You seem to have misplaced the onerror. Shouldn't that, as
commented, be assigned before - read - is called? Could read() raise
an exception immediately?
Why put the callback as an argument? What is wrong with having a
success callback?
A generic read method puts the type of reading on the stream, as you
would have it. Read just sends a message: read, but does not specify
the details.
2. Two extra objects are needed to read text data out of the file. However,
the composability of input streams enables a far richer library to operate.
I don't see why this is important.
For the purpose of the goals of this specification, is it the
complexity justified? I had the Reader idea and that was deemed too
complex, but what I see you proposing sounds, well, flexible, but more
involved. There's more busywork just to read a file.
This API matches more closely the Java API for IO.
That is not necessarily ideal.
Design decisions a decade ago in a different language, for different
contexts might not be the best decisions for this context.
I feel a bit odd about giving an API critique to someone who seems to
be a lot more knowledgeable and experienced. But anyway, this proposal
is extensible. It does not paint itself into a corner like the other.
Is it possible to simplify the interface a little bit? I'm not married
to the Reader idea, but it was a simpler
Re: File API to separate reading from files
I would like to make another plug for
http://dev.w3.org/2006/webapi/fileio/fileIO.htm
This had the notion of writing files, file streams, directories, and
being able to integrate into the host filesystem. All of these are
important for reasons I outlined in
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022388.html
and subsequent replies.
Quoting that email:
I would much rather have a well thought-out local filesystem
proposal, than continued creep of the existing File and Local Storage
proposal. These proposals are both designed from the perspective of I
want to take some existing data and either put it into the cloud or
make it available offline. They don't really handle the use case of
I want to create new data and save it to the local filesystem, or I
want to modify existing data on the filesystem, or I want to
maintain a virtual filesystem for my application, and potentially map
in the existing filesystem (e.g. if I'm flickr and I want to be able
to read the user's My Photos folder, send those up, but also make
thumbnails that I want to save locally and don't care if they get
uploaded, maintain an index file with image metadata / thumbnails /
locally, save off some intermediate files, ... For this, I would
really like to see us take another look at
http://dev.w3.org/2006/webapi/fileio/fileIO.htm (I don't think this
spec is exactly what we need, but I like the general approach of
origins get a virtual filesystem tucked away that they can use, they
can fread/fwrite/fseek, and optionally if they want to interact with
the host FS they can request that and then get some sub-set of that
(e.g. my documents or my photos) mapped in..
2009/8/31 Garrett Smith dhtmlkitc...@gmail.com
On Wed, Aug 19, 2009 at 11:47 AM, Nikunj R.
Mehtanikunj.me...@oracle.com wrote:
Here's an alternative, more easily extensible, proposal for reading files.
It provides applications a way to read small amounts of data at a time. It
also allows applications to concurrently read the same file.
I Agree.
[snip]
[snip example]
Secondly, a list of files can be obtained using some UI.
typedef sequenceFile FileList;
Agree.
Thirdly, an abstract interface is an input stream that is not limited to
files. It works at the level of bytes that files are made of. The read()
operation can specify the extent that is required. If an application wishes
to read small increments, it can thus specify those increments. Of course,
the File interface identifies its size, so the application can suitably
choose increments. Processing of blocks read from the file occurs in
callbacks. XHR could also consider taking an InputStream parameter during
the send() operation.
Would it be possible to have a reader handle creating the input stream
and making the decision based on what type of Reader it is, passing
byte offset lengths to the input stream -- essentially hiding those
details?
[snip example]
Fifthly, a file can be used for reading an input stream by specifying the
name of a file when constructing the stream
[Constructor(in File toOpen)]
interface FileInputStream : InputStream {
}
Sixthly, one can create various kinds of derived readers such as text
reader, binary string reader, and data URL reader. By inheriting from
InputStream, the basic mechanisms such as abort and onerror are inherited.
Moreover, the base read behavior is altered by the subclass although it
behaves in a similar manner, except that the data seen outside is different.
[Constructor(in InputStream base)]
interface BinaryStringInputStream : InputStream {
read(in StringDataHandler, [optional in] long long offset, [optional in]
long long length);
}
The callback is provided a DOMString. The String's length is expected to
match the increment requested.
[CallBack=FunctionOnly]
interface StringDataHandler {
handle(in DOMString data);
}
For text reading, encoding is optionally specified.
[Constructor(in InputStream base, [optional in] DOMString encoding)]
interface TextInputStream : InputStream {
read(in StringDataHandler, [optional in] long long offset, [optional in]
long long length);
}
A file can be alternatively read as a dataURL using a similar kind of
handler as above.
[Constructor(in InputStream base)]
interface FileDataURL: InputStream {
read(in StringDataHandler, [optional in] long long offset, [optional in]
long long length);
}
This API has the advantage that it can cleanly be extended to deal with both
writing use cases and binary data. Furthermore, it can also support
extensions that perform cryptographic, compression, or coding on top of the
basic interfaces.
To compare with the editor's draft, here's a typical programming case in
JavaScript:
var fileList = ...
// There is a mistake in the example provided in Section 3 where it does
fileList.files[0]
var myFile = fileList[0];
That's odd.
// *According to my proposal*
Re: File API to separate reading from files
Ian Fette (イアンフェッティ) wrote: I would like to make another plug for http://dev.w3.org/2006/webapi/fileio/fileIO.htm This had the notion of writing files, file streams, directories, and being able to integrate into the host filesystem. All of these are important for reasons I outlined in http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022388.html and subsequent replies. Ian: Nothing in my draft precludes those from coming later, in a v2 (and subsequent iterations), modulo good proposals about platform differences and security issues. Writing out data to the filesystem is a very different set of issues, with different security issues. There are numerous issues that need resolution here. It turns out the File API is a controversial one, even to get right basic read features, and I'm keen to finish a v1 draft soon. It's clear that even within the spectrum of read, we may not quite satisfy all use cases (such as fseek) in v1, but I'd like something that we can iterate on later. *Even* addressing the use cases of reading data, we've encountered discussions about programming style (Java I/O vs. a model closer to XHR), progress events, etc. I'd like to resolve these in a v1 draft first. I think v1 should address the most common use cases, which really do appear to be: I want to take some existing data and either put it into the cloud or make it available offline. Right, because we can't even do this elegantly on the web today! Developers use Firefox's synchronous API for File access, or Gears, or Flash (at least to get data from the file system into web apps and then the cloud). Furthermore: They don't really handle the use case of I want to create new data and save it to the local filesystem, or I want to modify existing data on the filesystem, or I want to maintain a virtual filesystem for my application, and potentially map in the existing filesystem Not *yet* but I think that these features can be evolved over the course of time. The proposal you cite: http://dev.w3.org/2006/webapi/fileio/fileIO.htm doesn't adequately address security issues, and deals with use cases that I'm not so sure are critical for a first version. I appreciate that Google wants these next, and so I'd like to see proposals that address the open issues, some of which have been mentioned on the whatwg thread you posted a link to. I'm on vacation Sept. 1 - Sept. 4, so I'll respond to other email about this topic upon my return. -- A*
[WebIDL] Feedback on the August 30 Editor's draft
Cameron et al., I have a couple pieces of feedback on this draft. Let me start by saying that this is a wonderful spec-much needed by the working group, and much appreciated by the IE team in relation to the additional clarity it provides for interpretation of other specs. Before I launch into the specific feedback, let me explain the principle behind my thinking: make the DOM binding for JavaScript as extensible as possible. I'd like to ensure that within reason, there is sufficient language binding to make the DOM as extensible and customizable as possible for web developers. For example, web developers that want to customize DOM behavior via one of its APIs should only have to do so at most once (or several times if the API is a mixin). Most of the design decisions for IE8's DOM prototypes follow this principle. 1- Mixing-in mixins (regarding 4.2.8 [PrototypeRoot], and sundry other places in the spec) My first comment here is that this is overly complicated. I don't quite follow why the mixin prototype object is defined to exist one level up from the object instance. This pretty much ensures that it's impossible to override the behavior of a mixin property (operation) on any scope larger than instance-level. For example, a developer would like to customize the behavior of addEventListener by replacing the native property with his/her own behavior, which ultimately invokes the native addEventListener API via apply. To do this and comprehensively cover every case where a webpage could use addEventListener, the web developer must override every instance in the DOM. This is unmanageable for any practical application. Rather, if the mixin properties were defined to exist higher-up in the prototype chain, then much more coverage can be obtained by one replacement. Since the mixin may appear on other interfaces, the scenario is not a single-point of replacement, but in all likelihood, a manageable number. I propose simplifying the mixin design substantially. I would like to see TargetInterface implements MixinInterface; be interpreted as merging each property/operation that is defined on the MixinInterface interface with the properties/operations on the TargetInterface. Treat mixins as literally mixing in to their associated interface. This likely implies that no interface object nor associated interface prototype object need be created in the ECMAScript binding. Where the MixinInterface interface is implemented by AnotherInterface, it's properties/operations are merged to that interface as well (creating a copy of the property/operations on AnotherInterface). I believe that design is simpler for web developers to understand, and also increases the utility of extending the functionality of typical mixins (like EventTarget). Today, no browser implementation that I'm aware of handles this consistently, and thus the risk to change the spec is very low. 2- property inheritance (regarding 4.4.3 [interface prototype objects]) Again, from the extensibility point of view, it's concerning to me that properties as defined on an interface are not actually represented as properties on the corresponding interface prototype object! Rather, the spec as it is currently written, flattens all properties to the object instance (which appears to coincide with Safari's behavior for properties). With the current approach, properties (i.e., those defined with 'attribute' in the WebIDL) cannot be overridden (or replaced) on anything other than object instances themselves. A key scenario for IE8 was the ability to customize or replace the functionality of innerHTML globally for all elements. Thus, we provided a property for innerHTML on the most general element type we had (Element-yes I know it's not the correct prototype hierarchy-we're working on that :)). Web developers can customize and extend that property in one place for far-reaching impact with little effort. Naturally, properties on prototypes are meaningless when invoked directly (they need an instance object 'this' reference), which is why IE8 and Firefox require the use of call/apply to be used when direct-invoking these. Opera does not appear to define properties at any level in their prototype chain, yet respects the web author's intent to override them (again, at any point in the hierarchy). I favor IE, FF, and Opera's extensibility over Safari's simplicity on this point. I propose defining properties (not just operations) on interface prototype objects. This proposal allows properties to be overridden/extended as easily as operations currently are. It also results in nice symmetry between the properties and operations defined on a WebIDL interface and the resulting interface prototype object. Finally, it more closely approximates the behavior available in three of the four major browser venders. I'm eager to discuss these issues with the working group. Again, thanks for this great specification
Re: [WebIDL] Feedback on the August 30 Editor's draft
On Mon, Aug 31, 2009 at 10:07 PM, Travis Leitheadtra...@microsoft.com wrote: Cameron et al., I have a couple pieces of feedback on this draft. Let me start by saying that this is a wonderful spec—much needed by the working group, and much appreciated by the IE team in relation to the additional clarity it provides for interpretation of other specs. Before I launch into the specific feedback, let me explain the principle behind my thinking: make the DOM binding for JavaScript as extensible as possible. I’d like to ensure that within reason, there is sufficient language binding to make the DOM as extensible and customizable as possible for web developers. For example, web developers that want to customize DOM behavior via one of its APIs should only have to do so at most once (or several times if the API is a mixin). Most of the design decisions for IE8’s DOM prototypes follow this principle. 1- Mixing-in mixins (regarding 4.2.8 [PrototypeRoot], and sundry other places in the spec) My first comment here is that this is overly complicated. I don’t quite follow why the mixin prototype object is defined to exist one level up from the object instance. This pretty much ensures that it’s impossible to override the behavior of a mixin property (operation) on any scope larger than instance-level. I don't know what this means. For example, a developer would like to customize the behavior of addEventListener by replacing the native property with his/her own behavior, which ultimately invokes the native addEventListener API via apply. What for? [snip] I propose defining properties (not just operations) on interface prototype objects. This proposal allows properties to be overridden/extended as easily as operations currently are. It also results in nice symmetry between the properties and operations defined on a WebIDL interface and the resulting interface prototype object. Finally, it more closely approximates the behavior available in three of the four major browser venders. Sounds like a bad idea and YSCISB.
Re: [WebIDL] Feedback on the August 30 Editor's draft
On Tue, Sep 1, 2009 at 2:19 AM, Garrett Smithdhtmlkitc...@gmail.com wrote: On Mon, Aug 31, 2009 at 10:07 PM, Travis Leitheadtra...@microsoft.com wrote: Cameron et al., I have a couple pieces of feedback on this draft. Let me start by saying that this is a wonderful spec—much needed by the working group, and much appreciated by the IE team in relation to the additional clarity it provides for interpretation of other specs. Before I launch into the specific feedback, let me explain the principle behind my thinking: make the DOM binding for JavaScript as extensible as possible. I’d like to ensure that within reason, there is sufficient language binding to make the DOM as extensible and customizable as possible for web developers. For example, web developers that want to customize DOM behavior via one of its APIs should only have to do so at most once (or several times if the API is a mixin). Most of the design decisions for IE8’s DOM prototypes follow this principle. 1- Mixing-in mixins (regarding 4.2.8 [PrototypeRoot], and sundry other places in the spec) My first comment here is that this is overly complicated. I don’t quite follow why the mixin prototype object is defined to exist one level up from the object instance. This pretty much ensures that it’s impossible to override the behavior of a mixin property (operation) on any scope larger than instance-level. I don't know what this means. For example, a developer would like to customize the behavior of addEventListener by replacing the native property with his/her own behavior, which ultimately invokes the native addEventListener API via apply. What for? One thing that comes up every so often is a desire to know which event handlers a page has added to a node. The use cases so far haven't been compelling enough that we've added support for this to the spec, however a page could do something very similar by overriding addEventListener and storing the added eventhandlers separately using the UserData APIs. [snip] I propose defining properties (not just operations) on interface prototype objects. This proposal allows properties to be overridden/extended as easily as operations currently are. It also results in nice symmetry between the properties and operations defined on a WebIDL interface and the resulting interface prototype object. Finally, it more closely approximates the behavior available in three of the four major browser venders. Sounds like a bad idea and YSCISB. What is YSCISB? / Jonas
