Re: [webcomponents] HTML Parsing and the element

On Fri, Jun 15, 2012 at 4:04 AM, Henri Sivonen wrote: > On Thu, Jun 14, 2012 at 11:48 PM, Ian Hickson wrote: > > Does anyone object to me adding , , and 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 ro

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 wrote: > On Tue, Jun 19, 2012 at 10:52 PM, Olli Pettay > 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

[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:

Re: [webcomponents] HTML Parsing and the element

(Please bottompost! Being a Googler teaches you bad email habits. ^_^) On Tue, Jun 26, 2012 at 1:34 PM, Elliott Sprehn wrote: > On Tue, Jun 26, 2012 at 1:19 PM, Tab Atkins Jr. > wrote: >> On Tue, Jun 26, 2012 at 1:03 PM, Elliott Sprehn wrote: >> > Silly question but why not specify the template

Re: [webcomponents] HTML Parsing and the 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 . There's a lot of simplicity in the DOM design that's lost from these two

Re: [webcomponents] HTML Parsing and the element

On Tue, Jun 26, 2012 at 1:03 PM, Elliott Sprehn 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 . Because you can't nest inside of itself, but w

Re: [webcomponents] HTML Parsing and the 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 . On Tue, Jun 26, 2012 at 8:25 AM, Rafael Weinstein wrote: > I think I'm not understanding the implications of

[Bug 16726] Remove quotes in "transparent" and "native" values

https://www.w3.org/Bugs/Public/show_bug.cgi?id=16726 Arun changed: What|Removed |Added Status|NEW |RESOLVED Resolution|

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: Agreem

[Bug 17125] Add a FileList.drop(index) method

https://www.w3.org/Bugs/Public/show_bug.cgi?id=17125 Max Lohrmann changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX

[Bug 17125] Add a FileList.drop(index) method

https://www.w3.org/Bugs/Public/show_bug.cgi?id=17125 Arun changed: What|Removed |Added Status|NEW |RESOLVED Resolution|

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

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,

[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

Re: [webcomponents] HTML Parsing and the 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 (

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 n

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 . If you have any comments or co

Re: [FileAPI] File.slice spec bug

On Tue, 26 Jun 2012 00:44:15 +0200, Andy Hou wrote: 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 Please use the new slice() sp

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