Re: how to organize the DOM specs [Was: CfC: publish new WD of DOM Core]
On 08/22/2011 11:22 AM, Jonas Sicking wrote: http://www.whatwg.org/specs/web-apps/current-work/complete/ I *always* used the much smaller document that used to be available here: www.whatwg.org/specs/web-workers/current-work/ I don't really understand your point here. If you used the smaller document presumably you could just have easily have read the relevant chapter from the larger document. When implementing a spec, the first thing I'd like to do is to read the whole spec front to back. This in order to get a sense for the various concepts involved which affects the implementation strategy. It is also important as it's required to review the specification. With a spec the size of, for example, the HTML5 spec, this is substantially more difficult. Not only does it take significantly longer to read the full HTML5 spec if all I want to implement is the pushState feature. It's also impossible to hold the fully spec in memory, even at a high level. Why would you read the whole spec to implement features contained in a single subsection? Alternatively, why wouldn't you read the whole HTML5 spec to implement web workers since there are normative dependences? It seems very arbitrary to base your choice of what is enough background information on someone else's choice of multiple files vs multiple sections in a single file. Small specs are absolutely more easily implemented and reviewed. I think this is an illusion. Self-contained features are more easily implemented and reviewed. There is no reason that a relatively self-contained feature can't be a section of a larger document. Small specs encourage people - including the spec editors - to perceive that features are more self-contained than they really are, leading to the problem of important detail dropping into the gaps between the specs. Additionally, having releases of a spec makes it possible to know what browser vendors and other significant players agree on. A ever changing slowly evolving spec doesn't say what browser vendors agree is good as opposed to what the editor happened to have put in since the various stake holders took a look at it. What browser vendors agree on is entirely unimportant to authors. What they care about is what actually ships. Once things are shipping browser vendors typically don't have much leeway to change things even when they all agree that it would be a nice idea. We should fix the authors need to know what is stable problem by understanding it is actually an authors need to know what is shipping problem and implementing something like caniuse.com directly in the spec, with links to the relevant parts of the testsuite where appropriate.
[Bug 13844] Does web work add complex to web?
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13844 Tab Atkins Jr. jackalm...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||jackalm...@gmail.com Resolution||INVALID --- Comment #1 from Tab Atkins Jr. jackalm...@gmail.com 2011-08-22 14:37:50 UTC --- I'm sorry, but I can't decipher this as English. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: [XHR2] Blobs, names and FormData
A few of us on the chrome team just discussed this. We see this as a deficiency in the FormData interface and intend to address it by providing a variant of FormData.append(...) that allows the caller to provide a 'filename' when appending a blob. We don't intend to implement BlobBuilder.getFile(). Anne, would you be willing to massage the XHR2 spec to allow for the additional param in the case of a blob? On Mon, Jul 18, 2011 at 3:00 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Jul 18, 2011 at 2:52 PM, Charles Pritchard ch...@jumis.com wrote: On 7/18/2011 2:42 PM, Jonas Sicking wrote: If there is an API that replies on File to work correctly we think we should fix it to work with Blob. For example, FileReader is really BlobReader and works fine with Blobs. To me, getFile() should be unnecessary and the best fix for FormData is to just modify append for this situation. While File and Blob are indeed very similar, they are also not the same thing. I think being able to create files is an easy addition for implementations, while it means not restricting getting Files from the users file system. So if you have code that expects to read a File from IndexedDB, the page can either populate that from the users filesystem, or by generating the data manually and using BlobBuilder.getFile. I'm very interested in this use case; I've been told that there may be issues with IndexedDB transaction constraints and FileReader/writer. Afaik, filewriter doesn't apply to blobs in this case. I don't know the consequences of callbacks to reader functions in the event loop, and whether that would end up blocking idb events. I'd imagine the blob is simply reset, and the stale reference remains until it can be cleaned up. Note that File objects are immutable just like Blobs are, so none of this applies here. The issues that you're talking about come up once we start talking about FileEntries, but that's an entirely different beast which are unrelated to this thread. No-one has suggested being able to create a FileEntry using BlobBuilder, nor that FileEntries are required to submit named content using FormData. Hope that helps. / Jonas
Re: DOM Mutation Events Replacement: Findings from implementing net-effect projections
On Wed, Aug 17, 2011 at 3:17 AM, Olli Pettay olli.pet...@helsinki.fiwrote:
On 08/17/2011 04:54 AM, Rafael Weinstein wrote:
TL;DR;
1) ObserveSubtree semantics doesn't provide a robust mechanism for
observing a tree/fragment, and if we don't provide something more
complete, libraries will likely register observers at every node in
the document.
ModificationBatch approach should provide as much information as
current mutation events.
No, the problem is that the list of mutations is given asynchronously in
some cases.
Say you have the following DOM tree:
body
div
span class=special
#text('hello')
and div is removed. At this point, the list of mutations we have is:
(ChildlistChanged, body, div)
where div has the subtree:
span class=special
#text('hello')
If observers (e.g. of widget library) wanted to detect whether any span with
the special classname has been removed from the document, it can do so
when it receives this list of mutations in this case.
But now suppose that another observer of this mutation list decides to
remove span from div's child list before my observer sees the list of
mutations. Oops! I don't have any idea whether span was removed or not
because all I get to see is (ChildlistChanged, body, div) and div doesn't
have any children.
Sure, this issue is prevalent in the existing mutation events but it's a
good use case to address. In fact, providing a way to work-around this
issue (by providing means to watch all nodes with the same owner document)
might provide a strong incentive for authors to start using our new API.
But is that a common enough case which the API needs to handle.
I would think that a script library which wants to handle such case,
can just use the API to observe everything.
Recall the distributed editing use cases pointed by Dave Raggett for
example:
http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0416.html
http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0381.html
- Ryosuke
RE: FW: [indexeddb] transaction commit failure
I added a step 3 to 4.3 Steps for committing a transaction: 3. If an error occurs while committing the transaction, fire an error event with type set to UNKNOWN_ERROR, and then follow the steps for aborting a transaction. Thanks, Eliot -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps- requ...@w3.org] On Behalf Of Jonas Sicking Sent: Wednesday, August 17, 2011 4:56 PM To: Israel Hilerio Cc: public-webapps@w3.org; Tom Bolds; Adam Herchenroether; Victor Ngo; m...@shawnwilsher.com Subject: Re: FW: [indexeddb] transaction commit failure On Wed, Aug 17, 2011 at 3:08 PM, Israel Hilerio isra...@microsoft.com wrote: On Tuesday, August 16, 2011 8:08 AM, Jonas Sicking wrote: On Monday, August 15, 2011, Shawn Wilsher m...@shawnwilsher.com wrote: On 8/15/2011 3:31 PM, Israel Hilerio wrote: When the db is doing a commit after processing all records on the transaction, if for some reason it fails, should we produce an error event first and let the bubbling produce a transaction abort event or should we only produce a transaction abort event. It seems that doing the first approach would be more complete. I agree; the first approach seems better and I can't think of any reason why it would be difficult to implement. The catch is that calling `preventDefault` will not prevent the abort, which is (I think) different from how we handle other errors, right? Yeah, I'm tempted to say that that is enough of a reason for simply firing abort directly, but I could be convinced otherwise. / Jonas We would like to follow the first approach because it allows us to notify the developer that there was an error on the transaction and that is the reason the transaction was aborted. Ok, that works for me. / Jonas
RE: [indexeddb] Handling negative parameters for the advance method
Hmm.. Yeah, I suspect that is the better behavior here. We should probably also throw if the number is 0. / Jonas If a developer specifies zero as a value, we could throw an IDBDatabaseException with a value of NON_TRANSIENT_ERR. What about doing the same for negative values? Israel For cursor.advance() in sync async, I changed count parameter type to long and added NON_TRANSIENT_ERR: ExceptionDescription IDBDatabaseExceptionNON_TRANSIENT_ERR The value passed into the count parameter was zero or a negative number. Thanks, Eliot
[Bug 13786] Drop the charset parameter or made it non-conforming. Other MIME types introduced by this specification do not allow the charset parameter.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13786 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|NEW |RESOLVED CC||i...@hixie.ch Resolution||WONTFIX --- Comment #2 from Ian 'Hixie' Hickson i...@hixie.ch 2011-08-23 00:05:35 UTC --- EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: The problem is that a number of servers actually send charset= parameters, so we have to support it. We can't ignore it because if the character encoding is set to something else then we would be corrupting the data if we interpreted it as UTF-8. (What if one day we all move on to some new encoding scheme? It's important that we be able to migrate. We can't easily do so if we are ignoring charset=!) -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: [XHR2] Blobs, names and FormData
Given that this seems to be the way people prefer to do it, I'm fine with doing that for Gecko too. But we definitely would need to get FormData.append changed so that it supports the use case. / Jonas On Mon, Aug 22, 2011 at 1:40 PM, Michael Nordman micha...@google.com wrote: A few of us on the chrome team just discussed this. We see this as a deficiency in the FormData interface and intend to address it by providing a variant of FormData.append(...) that allows the caller to provide a 'filename' when appending a blob. We don't intend to implement BlobBuilder.getFile(). Anne, would you be willing to massage the XHR2 spec to allow for the additional param in the case of a blob? On Mon, Jul 18, 2011 at 3:00 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Jul 18, 2011 at 2:52 PM, Charles Pritchard ch...@jumis.com wrote: On 7/18/2011 2:42 PM, Jonas Sicking wrote: If there is an API that replies on File to work correctly we think we should fix it to work with Blob. For example, FileReader is really BlobReader and works fine with Blobs. To me, getFile() should be unnecessary and the best fix for FormData is to just modify append for this situation. While File and Blob are indeed very similar, they are also not the same thing. I think being able to create files is an easy addition for implementations, while it means not restricting getting Files from the users file system. So if you have code that expects to read a File from IndexedDB, the page can either populate that from the users filesystem, or by generating the data manually and using BlobBuilder.getFile. I'm very interested in this use case; I've been told that there may be issues with IndexedDB transaction constraints and FileReader/writer. Afaik, filewriter doesn't apply to blobs in this case. I don't know the consequences of callbacks to reader functions in the event loop, and whether that would end up blocking idb events. I'd imagine the blob is simply reset, and the stale reference remains until it can be cleaned up. Note that File objects are immutable just like Blobs are, so none of this applies here. The issues that you're talking about come up once we start talking about FileEntries, but that's an entirely different beast which are unrelated to this thread. No-one has suggested being able to create a FileEntry using BlobBuilder, nor that FileEntries are required to submit named content using FormData. Hope that helps. / Jonas
Re: FW: [indexeddb] transaction commit failure
We should also explicitly mention that canceling the event (by calling preventDefault) does *not* prevent the transaction from being aborted. / Jonas On Mon, Aug 22, 2011 at 2:27 PM, Eliot Graff eliot.gr...@microsoft.com wrote: I added a step 3 to 4.3 Steps for committing a transaction: 3. If an error occurs while committing the transaction, fire an error event with type set to UNKNOWN_ERROR, and then follow the steps for aborting a transaction. Thanks, Eliot -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps- requ...@w3.org] On Behalf Of Jonas Sicking Sent: Wednesday, August 17, 2011 4:56 PM To: Israel Hilerio Cc: public-webapps@w3.org; Tom Bolds; Adam Herchenroether; Victor Ngo; m...@shawnwilsher.com Subject: Re: FW: [indexeddb] transaction commit failure On Wed, Aug 17, 2011 at 3:08 PM, Israel Hilerio isra...@microsoft.com wrote: On Tuesday, August 16, 2011 8:08 AM, Jonas Sicking wrote: On Monday, August 15, 2011, Shawn Wilsher m...@shawnwilsher.com wrote: On 8/15/2011 3:31 PM, Israel Hilerio wrote: When the db is doing a commit after processing all records on the transaction, if for some reason it fails, should we produce an error event first and let the bubbling produce a transaction abort event or should we only produce a transaction abort event. It seems that doing the first approach would be more complete. I agree; the first approach seems better and I can't think of any reason why it would be difficult to implement. The catch is that calling `preventDefault` will not prevent the abort, which is (I think) different from how we handle other errors, right? Yeah, I'm tempted to say that that is enough of a reason for simply firing abort directly, but I could be convinced otherwise. / Jonas We would like to follow the first approach because it allows us to notify the developer that there was an error on the transaction and that is the reason the transaction was aborted. Ok, that works for me. / Jonas
Re: [indexeddb] Updates to the IDBCursor.advance method text and exception list.
On Mon, Aug 22, 2011 at 5:24 PM, Israel Hilerio isra...@microsoft.com wrote: I wanted to confirm with you that we want to add the following text to the IDBCursor.advance to keep it consistent with IDBCursor.continue: Before this method returns, unless an exception was thrown, it sets the got value flag on the cursor to false. Calling this method more than once before the cursor data has been loaded is not allowed and results in a NOT_ALLOWED_ERR exception being thrown. For example, calling advance() twice from the same onsuccess handler results in a NOT_ALLOWED_ERR being thrown on the second call. IDBDatabaseException: * TRANSACTION_INACTIVE_ERR - The transaction this IDBCursor belongs to is not active. * NOT_ALLOWED_ERR - The cursor is currently being iterated, or has iterated past its end. If we agree, we can make this change. Sounds good to me. / Jonas
[Bug 13373] Privacy: Limit SharedWorker connections to same top-level domain
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13373 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WONTFIX --- Comment #3 from Ian 'Hixie' Hickson i...@hixie.ch 2011-08-23 05:19:27 UTC --- (In reply to comment #2) It sounds like you are saying that as an implementor, I am free to define that when two frames are not in a unit of related browing contexts (which I will define as a tab for illustrative purposes), then they don't need to connect to the same SharedWorker instance (even if they share the same domain and other criteria as specified in [2]). As a browser user agent, I might allow the round-about scenario described above (because there is an opt-in path), but disallow the case where the frames are trying a connection from different tabs. If such a behavior is conforming per this specification, then I guess I don't have any further concern. If they can communicate indirectly, then they should be able to open a shared worker. That's the entire point of the shared worker feature. With what you propose, there would be no way for sites to provide shared services. For example, imagine if example.com provided a dictionary (spelling checking) service, and facebook.com and plus.google.com both wanted to be able to use that service. So that example.com uses only minimal resources on each user's machine (it expects to be used by many sites), it uses a shared worker to communicate back to its server. Both facebook.com and plus.google.com open an iframe to example.com and that iframe then opens the shared worker. The sites can then check spelling by communicating to a port vended from the worker through the iframe to the sites, and all the checking happens in the one worker. If we did what you suggested, this would not be possible. Indeed, either example.com would have to run multiple copies of the spelling checker service (wasting user resources), or it would have to open a top-level window to open the shared worker (which would mean highly annoying popups). Since your proposal does not improve privacy in any material way, and harms legitimate use cases, I do not think it makes sense. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
