Re: [FileAPI] File.slice spec bug
Hi, It looks like IE10 supports File.slice() using the new spec. Is it safe to use the new File.slice() spec, or should IE be using a vendor prefix like Firefox and Chrome are currently doing. Thanks, Andy
Re: CfC: publish a LCWD of Selectors API Level 1; deadline June 25
On 2012-06-18 15:57, Arthur Barstow wrote: Lachlan has made some changes to the Selectors API Level 1 spec (last published as a CR) and we consider the changes sufficient to require the spec be published as a Working Draft (see the [1] thread). As such, this is a Call for Consensus to publish a new LCWD of this spec using the following document as the basis http://dev.w3.org/2006/webapi/selectors-api/. If you have any comments or concerns about this CfC, please send them to public-webapps@w3.org by June 25 at the latest. Positive response is preferred and encouraged and silence will be considered as agreement with the proposal. This draft has been prepared for publication and checked into the repository. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: CfC: publish WD of Selectors API Level 2; deadline June 25
On 2012-06-18 15:41, Arthur Barstow wrote: Lachlan would like to publish a new Working Draft of the Selectors API Level 2 spec and this is a Call for Consensus to do so using the following Editor's Draft as the basis http://dev.w3.org/2006/webapi/selectors-api2/. If you have any comments or concerns about this proposal, please reply to this e-mail by June 25 at the latest. This draft has been prepared for publication and checked into the repository. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [webcomponents] HTML Parsing and the template element
I think I'm not understanding the implications of your argument. You're making a principled argument about future pitfalls. Can you help me get my head around it by way of example? Perhaps: -pitfalls developers fall into -further dangerous points along the slippery slope you think this opens up (you mentioned pandoras box) On Fri, Jun 15, 2012 at 4:04 AM, Henri Sivonen hsivo...@iki.fi wrote: On Thu, Jun 14, 2012 at 11:48 PM, Ian Hickson i...@hixie.ch wrote: Does anyone object to me adding template, content, and shadow to the HTML parser spec next week? I don't object to adding them if they create normal child elements in the DOM. I do object if template has a null firstChild and the new property that leads to a fragment that belongs to a different owner document. (My non-objection to creating normal children in the DOM should not be read as a commitment to support templates Gecko.) -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
[IndexedDB] Null argument for optionalParameters?
What should the behavior be in the following calls?
db.createObjectStore('storename', null);
db.createObjectStore('storename', undefined);
store.createIndex('storename', 'keypath', null);
store.createIndex('storename', 'keypath', undefined);
As a reminder, the IDL for the final argument in both methods is:
optional IDBObjectStoreParameters optionalParameters
Both Chrome 20 and Firefox 13 appears to treat null and undefined the same
as if no argument was provided (i.e. no exception). Both Chrome and Firefox
throw for arguments of type string (etc).
The arguments are marked as optional but not nullable, and there is
no [TreatUndefinedAs=Null] or [TreatUndefinedAs=Missing] attribute. My
reading of the WebIDL spec is that without these qualifiers the above calls
should throw.
If the current behavior in those two browsers is desirable (and we have
developer feedback that it is), then I believe the IDL for these arguments
needs to be amended to:
[TreatUndefinedAs=Null] optional IDBObjectStoreParameters?
optionalParameters
All that said, this seems like a common pattern. Is there something in
WebIDL I'm not seeing that implies this behavior for dictionaries already?
Thoughts?
Re: [IndexedDB] Null argument for optionalParameters?
On 6/26/12 12:59 PM, Joshua Bell wrote:
All that said, this seems like a common pattern. Is there something in
WebIDL I'm not seeing that implies this behavior for dictionaries already?
No, but there have definitely been proposals (from me and Jonas at
least) that WebIDL treat null, undefined, not passed, and {} as exactly
identical for optional dictionary arguments...
-Boris
Re: [IndexedDB] Null argument for optionalParameters?
On 06/26/2012 07:15 PM, Boris Zbarsky wrote:
On 6/26/12 12:59 PM, Joshua Bell wrote:
All that said, this seems like a common pattern. Is there something in
WebIDL I'm not seeing that implies this behavior for dictionaries
already?
No, but there have definitely been proposals (from me and Jonas at
least) that WebIDL treat null, undefined, not passed, and {} as exactly
identical for optional dictionary arguments...
This was fixed yesterday over in bug 16725; [1] see the spec. [2]
HTH
Ms2ger
[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=16725
[2] http://dev.w3.org/2006/webapi/WebIDL/#es-dictionary
[Bug 17125] Add a FileList.drop(index) method
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17125 Arun a...@mozilla.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 17125] Add a FileList.drop(index) method
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17125 Max Lohrmann p...@wickenrode.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX | --- Comment #4 from Max Lohrmann p...@wickenrode.com 2012-06-26 17:52:12 UTC --- 2. Erroneous files can be eliminated. This request was specifically because exactly that is not possible. Once multiple files are selected for an input element you can only drop all of them at once. I guess the way Gmail does it is by going all the way: Getting the File objects and attaching them to a XmlHttpRequest. I made this request because I think that should not be necessary. Browsers have been providing logic for file uploads for years now and making every web developer write another layer (the one that handles the XmlHttpRequest) on top of that probably won't make it better. I think the suggestion as per comment 1 would be enough to solve this problem and also add a feature that is the logical consequence of having a File object. -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
CfC: publish new WD of File API; deadline July 3
Hi All - Arun is back to actively editing the File API spec and this is a Call for Consensus to publish a new WD of the spec. Please note that Arun will be committing some changes during this CfC and that the ED does not yet use the WD template: http://dev.w3.org/2006/webapi/FileAPI/ Agreement to this proposal: a) indicates support for publishing a new WD; and b) does not necessarily indicate support of the contents of the WD. If you have any comments or concerns about this proposal, please reply to this e-mail by July 3 at the latest. Positive response to this CfC is preferred and encouraged and silence will be assumed to mean agreement with the proposal. -Thanks, AB
[Bug 16726] Remove quotes in transparent and native values
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16726 Arun a...@mozilla.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Arun a...@mozilla.com 2012-06-26 19:10:46 UTC --- Fixed. http://dev.w3.org/2006/webapi/FileAPI/ -- Configure bugmail: https://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: [webcomponents] HTML Parsing and the template element
Silly question but why not specify the template element as if it's contents were PCDATA, and the document fragment is the value. Then this whole thing isn't really any different than a textarea. On Tue, Jun 26, 2012 at 8:25 AM, Rafael Weinstein rafa...@google.comwrote: I think I'm not understanding the implications of your argument. You're making a principled argument about future pitfalls. Can you help me get my head around it by way of example? Perhaps: -pitfalls developers fall into -further dangerous points along the slippery slope you think this opens up (you mentioned pandoras box) On Fri, Jun 15, 2012 at 4:04 AM, Henri Sivonen hsivo...@iki.fi wrote: On Thu, Jun 14, 2012 at 11:48 PM, Ian Hickson i...@hixie.ch wrote: Does anyone object to me adding template, content, and shadow to the HTML parser spec next week? I don't object to adding them if they create normal child elements in the DOM. I do object if template has a null firstChild and the new property that leads to a fragment that belongs to a different owner document. (My non-objection to creating normal children in the DOM should not be read as a commitment to support templates Gecko.) -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [webcomponents] HTML Parsing and the template element
On Tue, Jun 26, 2012 at 1:03 PM, Elliott Sprehn espr...@gmail.com wrote: Silly question but why not specify the template element as if it's contents were PCDATA, and the document fragment is the value. Then this whole thing isn't really any different than a textarea. Because you can't nest textarea inside of itself, but we want templates to be nestable. ~TJ
Re: [webcomponents] HTML Parsing and the template element
Hmm, I might be in agreement with Henri then. Having all these parallel trees in the DOM is getting kind of out of control. Now there's the shadow DOM trees on every node, and also this nested tree of document fragments from template. There's a lot of simplicity in the DOM design that's lost from these two changes. On Tue, Jun 26, 2012 at 1:19 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Tue, Jun 26, 2012 at 1:03 PM, Elliott Sprehn espr...@gmail.com wrote: Silly question but why not specify the template element as if it's contents were PCDATA, and the document fragment is the value. Then this whole thing isn't really any different than a textarea. Because you can't nest textarea inside of itself, but we want templates to be nestable. ~TJ
Re: [webcomponents] HTML Parsing and the template element
(Please bottompost! Being a Googler teaches you bad email habits. ^_^) On Tue, Jun 26, 2012 at 1:34 PM, Elliott Sprehn espr...@gmail.com wrote: On Tue, Jun 26, 2012 at 1:19 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, Jun 26, 2012 at 1:03 PM, Elliott Sprehn espr...@gmail.com wrote: Silly question but why not specify the template element as if it's contents were PCDATA, and the document fragment is the value. Then this whole thing isn't really any different than a textarea. Because you can't nest textarea inside of itself, but we want templates to be nestable. Hmm, I might be in agreement with Henri then. Having all these parallel trees in the DOM is getting kind of out of control. Now there's the shadow DOM trees on every node, and also this nested tree of document fragments from template. There's a lot of simplicity in the DOM design that's lost from these two changes. The problem is that this is a very theoretical opinion. In reality, these parallel trees *already exist*, except they're not DOM, they're bespoke JS trees that don't interoperate between libraries and have a decent impedance mismatch with the real DOM APIs, resulting in significant duplication. Let's get rid of these parallel trees isn't an option. Our choices are only maintain the status quo of multiple layers of DOM incompatibly stacked on top of each other or complicate DOM a bit to pull those trees into the fold. ~TJ
[Bug 17609] New: [IndexedDB] Events fired after transaction abort should not set active flag
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17609 Summary: [IndexedDB] Events fired after transaction abort should not set active flag Product: WebAppsWG Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: dave.n...@w3.org ReportedBy: jsb...@chromium.org QAContact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org At the point where a transaction is aborted, it's active flag becomes false - either implicitly (because the abort happens outside a callback) or explicitly due to a call to abort() (...this method sets the transaction's active flag to false...) In the steps for aborting a transaction, the any requests in the transaction's request list whose done flag is still false are run through sub-steps including: Fire an error event at the request. However when running these steps, ignore any request to run the steps for aborting a transaction as those steps are already running. Which indicates the steps for Fire an error event are processed, which includes: 2. Set the active flag of transaction to true. The clause in the steps for aborting a transaction should either be changed to read: Fire an error event at the request. However when running these steps, ignore any request to run the steps for aborting a transaction as those steps are already running, and do not set the active flag of the transaction. Or the steps for aborting a transaction should drop the fire an error event reference and in-line the relevant steps instead (that'd be step 1 and parts of step 3) -- Configure bugmail: https://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: Should MutationObservers be able to observe work done by the HTML parser?
On Wed, Jun 20, 2012 at 12:29 AM, Anne van Kesteren ann...@annevk.nlwrote: On Tue, Jun 19, 2012 at 10:52 PM, Olli Pettay olli.pet...@helsinki.fi wrote: end-of-microtask or end-of-task everywhere. And yes, some parsing / networking details may unfortunately be exposed, but in a way which should be quite random. Web devs just can't really rely on network packages to be delivered to parser in some exact way. I think the original solution we had to not expose parser mutations was better. Exposing this can lead to all kinds of subtle bugs that are hard to detect for developers. I take it from your reply that you and I had the same view of what's specced in DOM4. That is, that MutationObservers are not specified to be notified of actions taken by the parser. Given that fact, it seems that either the spec should be changed (and by spec here I think the required changes are in HTML, not DOM), or Firefox's implementation ought to be changed. Anne, Ian, Olli, Jonas, your thoughts? - Adam
Re: [webcomponents] HTML Parsing and the template element
On Fri, Jun 15, 2012 at 4:04 AM, Henri Sivonen hsivo...@iki.fi wrote: On Thu, Jun 14, 2012 at 11:48 PM, Ian Hickson i...@hixie.ch wrote: Does anyone object to me adding template, content, and shadow to the HTML parser spec next week? I don't object to adding them if they create normal child elements in the DOM. If we go this route how does template iterate work when the array is empty? Could you give some detail on what you'd like the behavior to be for iterate over [], [oneThing] and [oneThing, twoThings] ? - E
