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
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 shweta...@opera.com
Why did you feel it was necessary to write a layer on top of IndexedDB?
I think this is
On Wed, Mar 6, 2013 at 3:22 AM, Anne van Kesteren ann...@annevk.nl 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
On Wed, Mar 6, 2013 at 2:21 PM, Glenn Maynard gl...@zewt.org 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
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
On Wed, Mar 6, 2013 at 8:01 AM, Alex Russell slightly...@google.com 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
On Wednesday, March 6, 2013, Glenn Maynard wrote:
On Wed, Mar 6, 2013 at 8:01 AM, Alex Russell
slightly...@google.comjavascript:_e({}, 'cvml', 'slightly...@google.com');
wrote:
Comments inline. Adding some folks from the IDB team at Google to the
thread as well as public-webapps.
(I
On Wednesday, March 6, 2013, Glenn Maynard wrote:
On Wed, Mar 6, 2013 at 8:01 AM, Alex Russell
slightly...@google.comjavascript:_e({}, 'cvml', 'slightly...@google.com');
wrote:
Comments inline. Adding some folks from the IDB team at Google to the
thread as well as public-webapps.
(I
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
On Wed, Mar 6, 2013 at 6:29 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Wed, Mar 6, 2013 at 2:21 PM, Glenn Maynard gl...@zewt.org 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
On Tue, Feb 26, 2013 at 1:43 PM, Blake Kaplan mrb...@gmail.com wrote:
On Tue, Feb 26, 2013 at 11:05 AM, Erik Arvidsson a...@google.com 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
On Wed, Mar 6, 2013 at 5:47 PM, Darin Fisher da...@chromium.org 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.
--
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
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 this
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
On Wed, Mar 6, 2013 at 1:12 PM, Rafael Weinstein rafa...@google.com 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
On Wed, Mar 6, 2013 at 11:02 AM, Ian Fette (イアンフェッティ) ife...@google.comwrote:
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
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) Not
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20302
Ian 'Hixie' Hickson i...@hixie.ch changed:
What|Removed |Added
CC|
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 foo-raj
element, and
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
*
On 6.3.2013 18:50, Dimitri Glazkov wrote:
On Tue, Feb 26, 2013 at 1:43 PM, Blake Kaplan mrb...@gmail.com
mailto:mrb...@gmail.com wrote:
On Tue, Feb 26, 2013 at 11:05 AM, Erik Arvidsson a...@google.com
mailto:a...@google.com wrote:
Also, if shadows are public by default the API to
On Wed, Mar 6, 2013 at 2:05 PM, Dimitri Glazkov dglaz...@google.com 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
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,
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,
On Wed, Mar 6, 2013 at 10:12 AM, Rafael Weinstein rafa...@google.com 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
On Wed, Mar 6, 2013 at 2:20 PM, Scott Miles sjmi...@google.com 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
On Wed, Mar 6, 2013 at 2:26 PM, Bronislav Klučka
bronislav.klu...@bauglir.com 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
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
Inline
On Wed, Mar 6, 2013 at 7:03 PM, Hajime Morrita morr...@google.com 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
On Wed, Mar 6, 2013 at 1:55 PM, Dimitri Glazkov dglaz...@google.com wrote:
1) Somehow magically chain create callbacks. In Lucy's case,
foo-lucy 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
On Thu, Mar 7, 2013 at 9:13 AM, Erik Arvidsson a...@chromium.org wrote:
Inline
On Wed, Mar 6, 2013 at 7:03 PM, Hajime Morrita morr...@google.com wrote:
One consequence is that it will become harder to cache (including
negative cache) these values. We need to traverse the prototype chain in
On Wed, Mar 6, 2013 at 8:29 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Wed, Mar 6, 2013 at 2:21 PM, Glenn Maynard gl...@zewt.org 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
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
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
On Tue, Feb 26, 2013 at 7:53 AM, Glenn Maynard gl...@zewt.org wrote:
On Tue, Feb 26, 2013 at 4:56 AM, Anne van Kesteren ann...@annevk.nlwrote:
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.
36 matches
Mail list logo
