Re: Streams and Blobs

On Tue, Feb 26, 2013 at 7:53 AM, Glenn Maynard wrote: > On Tue, Feb 26, 2013 at 4:56 AM, Anne van Kesteren wrote: > >> The advantage the Streams API seems to have over moz-blob is that you > > do not need to create a new object to read from each time there's >> fresh data. The disadvantage is tha

Re: [webcomponents]: What callbacks do custom elements need?

On 3/6/13 5:05 PM, Dimitri Glazkov wrote: * attributeChangedCallback -- synchronously called when an attribute of an element is added, removed, or modified Synchronously in what sense? Why are mutation observers not sufficient here? * insertedCallback -- asynchronously called when an eleme

Re: [webcomponents]: Moving custom element callbacks to prototype/instance

On 3/6/13 7:13 PM, Erik Arvidsson wrote: There is no reason to walk the prototype chain from C++ (speaking from WebCore+V8/JS experience). You can invoke the method using the V8/JSC APIs. This is just as slow as walking the proto chain, in the end, because it can't benefit from the various opt

Re: File API: Blob.type

On Wed, Mar 6, 2013 at 8:29 AM, Anne van Kesteren wrote: > On Wed, Mar 6, 2013 at 2:21 PM, Glenn Maynard wrote: > > Blob.type is a MIME type, not a Content-Type header. It's a string of > > codepoints, not a series of bytes. XHR is a protocol-level API, so > maybe it > > makes sense there, but

Re: [webcomponents]: Moving custom element callbacks to prototype/instance

On Thu, Mar 7, 2013 at 9:13 AM, Erik Arvidsson wrote: > Inline > > On Wed, Mar 6, 2013 at 7:03 PM, Hajime Morrita wrote: > >> One consequence is that it will become harder to cache (including >> negative cache) these values. We need to traverse the prototype chain in >> C++, which is typically s

Re: [webcomponents]: Moving custom element callbacks to prototype/instance

On Wed, Mar 6, 2013 at 1:55 PM, Dimitri Glazkov wrote: > 1) Somehow magically chain "create" callbacks. In Lucy's case, > will call both Raj's and Lucy's callbacks. > 2) Get rid of a separate lifecycle object and just put the callbacks > on the prototype object, similar to printCallback > (http:/

Re: IndexedDB, what were the issues? How do we stop it from happening again?

On Wed, Mar 6, 2013 at 10:18 AM, Alex Russell wrote: > So which part do you disagree with? That events are a bad model for a > one-time action? Or that it's not clear what the expected contract is? > Going by what you've written below, I have to assume the latter, so I'll > just say this: try sitt

Re: [webcomponents]: Moving custom element callbacks to prototype/instance

Inline On Wed, Mar 6, 2013 at 7:03 PM, Hajime Morrita wrote: > One consequence is that it will become harder to cache (including negative > cache) these values. We need to traverse the prototype chain in C++, which > is typically slower than doing it in JS, on every lifecycle event. Or we > need

Re: [webcomponents]: Moving custom element callbacks to prototype/instance

>From an implementors perspective: Putting such callbacks on the prototype object means that it can be changed, or even can be added after the element registration. This is different from a function parameter, which we can consider as a snapshot. One consequence is that it will become harder to c

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

On Wed, Mar 6, 2013 at 2:26 PM, Bronislav Klučka wrote: > What does the "exposing internals" means anyway? Does it mean that there are > no boundaries at all and e.g. document.querySelector can access internal? Or > does it mean that you can access internals only by explicitly asking for > existin

Re: [webcomponents]: Moving custom element callbacks to prototype/instance

On Wed, Mar 6, 2013 at 2:20 PM, Scott Miles wrote: > That's the ultimate goal IMO, and when I channel Alex Russell (without > permission). =P Don't we already have Fake Alex for that (https://twitter.com/FakeAlexRussell)? :DG<

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

On Wed, Mar 6, 2013 at 10:12 AM, Rafael Weinstein wrote: > It seems to me like if public-by-default was a design mistake on the > web, it'd be pretty clearly in evidence already. Is it? This might depend who you ask. I know from experience that public-by-default has bitten XBL1-implemented HTML e

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

On 6.3.2013 21:00, Boris Zbarsky wrote: On 3/6/13 1:31 PM, Scott González wrote: but we feel the pros of exposing internals outweigh the cons. When you say "exposing internals" here, which one of the following do you mean: 1) Exposing internals always. 2) Exposing internals by default, w

Re: [webcomponents]: Moving custom element callbacks to prototype/instance

I favor #2. It's much simpler. Simple is good. Fwiw, I'm filtering these things through the idea that someday we will be able to do: document.register("x-foo", XFoo); That's the ultimate goal IMO, and when I channel Alex Russell (without permission). =P Scott On Wed, Mar 6, 2013 at 1:55 PM, D

Re: [webcomponents]: What callbacks do custom elements need?

On Wed, Mar 6, 2013 at 2:05 PM, Dimitri Glazkov wrote: > ... > * insertedCallback -- asynchronously called when an element is added > to document tree (TBD: is this called when parser is constructing the > tree?) > > * removedCallback -- asynchronously called when an element is removed > from the

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

On 6.3.2013 18:50, Dimitri Glazkov wrote: On Tue, Feb 26, 2013 at 1:43 PM, Blake Kaplan > wrote: On Tue, Feb 26, 2013 at 11:05 AM, Erik Arvidsson mailto:a...@google.com>> wrote: > Also, if shadows are public by default the API to access the shadow is well

[webcomponents]: What callbacks do custom elements need?

Here are all the callbacks that we could think of: * readyCallback (artist formerly known as "create") -- called when the element is instantiated with generated constructor, createElement/NS or shortly after it was instantiated and placed in a tree during parser tree construction * attributeChang

[webcomponents]: Moving custom element callbacks to prototype/instance

A few of browser/webdev folks got together and went (again!) over the custom elements design. One problem stuck out: handling of "created" callbacks (and other future callbacks, by induction) for derived custom elements. For example, if Raj defined a "create" callback for his element, and Lucy la

[Bug 20302] Document.execCommand should use optional arguments with default values

https://www.w3.org/Bugs/Public/show_bug.cgi?id=20302 Ian 'Hixie' Hickson changed: What|Removed |Added CC||public-webapps@w3.org C

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

On 3/6/13 1:31 PM, Scott González wrote: but we feel the pros of exposing internals outweigh the cons. When you say "exposing internals" here, which one of the following do you mean: 1) Exposing internals always. 2) Exposing internals by default, with a way to opt into not exposing. 3) No

Re: IndexedDB, what were the issues? How do we stop it from happening again?

On Wed, Mar 6, 2013 at 11:02 AM, Ian Fette (イアンフェッティ) wrote: > I seem to recall we contemplated people writing libraries on top of IDB > from the beginning. I'm not sure why this is a bad thing. We originally > shipped "web sql" / sqlite, which was a familiar interface for many and > relatively ea

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

On Wed, Mar 6, 2013 at 1:12 PM, Rafael Weinstein wrote: > I'm curious if jQuery or others have experienced feeling restricted > because apps are depending on internals by way of having access to > them via monkey-patching > This is unfortunately a very real pain for jQuery. On the flip side, exp

Re: IndexedDB, what were the issues? How do we stop it from happening again?

I seem to recall we contemplated people writing libraries on top of IDB from the beginning. I'm not sure why this is a bad thing. We originally shipped "web sql" / sqlite, which was a familiar interface for many and relatively easy to use, but had a sufficiently large API surface area that no one f

Re: IndexedDB, what were the issues? How do we stop it from happening again?

My primary takeaway from both working on IDB and working with IDB for some demo apps is that IDB has just the right amount of complexity for really large, robust database use.. but for a "welcome to noSQL in the browser" it is way too complicated. Specifically: 1. *versioning* - The reason thi

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

So the two camps in the this argument seem to be arguing largely philosophical views. It's clear that Mozilla has experienced pain via plugins having access to browser internals. I'm curious if jQuery or others have experienced feeling restricted because apps are depending on internals by way of

Re: File API: Blob.type

On Wed, Mar 6, 2013 at 5:47 PM, Darin Fisher wrote: > So the intent is to allow specifying attributes like "charset"? That sounds > useful. Yeah I thought so. The value would be feeded straight there when reading as if it was an HTTP response. Arun would know for sure though. -- http://anneva

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

On Tue, Feb 26, 2013 at 1:43 PM, Blake Kaplan wrote: > On Tue, Feb 26, 2013 at 11:05 AM, Erik Arvidsson wrote: > > Also, if shadows are public by default the API to access the shadow is > well > > defined. If shadows are private by default and components decide to > expose > > the shadow ad hoc

Re: File API: Blob.type

On Wed, Mar 6, 2013 at 6:29 AM, Anne van Kesteren wrote: > On Wed, Mar 6, 2013 at 2:21 PM, Glenn Maynard wrote: > > Blob.type is a MIME type, not a Content-Type header. It's a string of > > codepoints, not a series of bytes. XHR is a protocol-level API, so > maybe it > > makes sense there, but

Re: IndexedDB, what were the issues? How do we stop it from happening again?

On Wednesday, March 6, 2013 at 5:51 PM, Jarred Nicholls wrote: > This is an entirely different conversation though. I don't know the answer to > why sync interfaces are there and expected, except that some would argue that > it makes the code easier to read/write for some devs. Since this is mirr

Re: IndexedDB, what were the issues? How do we stop it from happening again?

On Wednesday, March 6, 2013, Glenn Maynard wrote: > On Wed, Mar 6, 2013 at 8:01 AM, Alex Russell > > > wrote: > >> Comments inline. Adding some folks from the IDB team at Google to the >> thread as well as public-webapps. >> > > (I don't want to cold CC so many people, and anybody working on an

Re: IndexedDB, what were the issues? How do we stop it from happening again?

On Wednesday, March 6, 2013, Glenn Maynard wrote: > On Wed, Mar 6, 2013 at 8:01 AM, Alex Russell > > > wrote: > >> Comments inline. Adding some folks from the IDB team at Google to the >> thread as well as public-webapps. >> > > (I don't want to cold CC so many people, and anybody working on an

Re: IndexedDB, what were the issues? How do we stop it from happening again?

On Wed, Mar 6, 2013 at 8:01 AM, Alex Russell wrote: > Comments inline. Adding some folks from the IDB team at Google to the > thread as well as public-webapps. > (I don't want to cold CC so many people, and anybody working on an IDB implementation should be on -webapps already, so I've trimmed t

Re: IndexedDB, what were the issues? How do we stop it from happening again?

I wrote a quick overview of the issues I have had using the indexedDB API http://arandomurl.com/2013/02/21/thoughts-on-indexeddb.html Most of them are just implementation details, however I still havent met a webdev who understands the transaction model without having one of the indexeddb impleme

Re: File API: Blob.type

On Wed, Mar 6, 2013 at 2:21 PM, Glenn Maynard wrote: > Blob.type is a MIME type, not a Content-Type header. It's a string of > codepoints, not a series of bytes. XHR is a protocol-level API, so maybe it > makes sense there, but it doesn't make sense for Blob. It's a Content-Type header value an

Re: File API: Blob.type

On Wed, Mar 6, 2013 at 3:22 AM, Anne van Kesteren wrote: > Okay, so given https://bugs.webkit.org/show_bug.cgi?id=111380 I think > we should put at least minimal restrictions on Blob's constructor > concerning Blob.type. We made it "anything goes" because in theory > with Content-Type anything go

IndexedDB, what were the issues? How do we stop it from happening again?

Comments inline. Adding some folks from the IDB team at Google to the thread as well as public-webapps. On Sunday, February 17, 2013, Miko Nieminen wrote: > > > 2013/2/15 Shwetank Dixit > >> Why did you feel it was necessary to write a layer on top of IndexedDB? >>> >> >> I think this is the ma

File API: Blob.type

Okay, so given https://bugs.webkit.org/show_bug.cgi?id=111380 I think we should put at least minimal restrictions on Blob's constructor concerning Blob.type. We made it "anything goes" because in theory with Content-Type anything goes. But of course that is false and we should have noticed that at