Consider an autoincrementing IDBObjectStore with keyPath "foo.bar".
Which of the following (if any) should succeed?
1. objectStore.put({foo: null});
2. objectStore.put({foo: undefined});
3. objectStore.put({foo: {bar: null}});
4. objectStore.put({foo: {bar: undefined}});
By my reading of the spe
On Tue, Jun 19, 2012 at 1:38 PM, Tab Atkins Jr. wrote:
> ...
> This is not a good argument. qSA is used often enough, and has a long
> enough name, that the name is actually a pretty significant
> misfeature. This is a pretty core API, and both it and its precursors
> (getElementByID, etc.) are
IndexedDB should ignore document.domain.
Adam
On Tue, Jun 19, 2012 at 9:06 PM, Kyle Huey wrote:
> By my reading, the spec does not clearly specify what the 'origin' should
> be. IDBFactory.open/deleteDatabase say "Let origin be the origin of the
> IDBEnvironment used to access this IDBFactory.
By my reading, the spec does not clearly specify what the 'origin' should
be. IDBFactory.open/deleteDatabase say "Let origin be the origin of the
IDBEnvironment used to access this IDBFactory." The IDL states "Window
implements IDBEnvironment;" The HTML5 spec, as far as I can tell, does not
defi
On 6/20/12 12:05 AM, "Sylvain Galineau" wrote:
>
>[Daniel Glazman:]
>>
>>
>> That's also the reason why I asked to explain requestFullscreen(). It
>>can
>> sound obvious, but it's not. And in fact, we should _never_ introduce a
>>new
>> syntax, API, whatever w/o saying _what it does_ from a fun
[Daniel Glazman:]
>
>
> That's also the reason why I asked to explain requestFullscreen(). It can
> sound obvious, but it's not. And in fact, we should _never_ introduce a new
> syntax, API, whatever w/o saying _what it does_ from a functional point of
> view before explaining how it works.
>
T
20.06.2012, 00:38, "Tab Atkins Jr." :
> On Mon, Jun 18, 2012 at 10:59 PM, Simon Pieters wrote:
>
>> On Mon, 18 Jun 2012 16:57:17 +0200, Kang-Hao (Kenny) Lu
>> wrote:
>> We have lots of shipped APIs with worse names. I think we should live with
>> past mistakes, try not to make them again, and
Le 19/06/12 22:48, fantasai a écrit :
You could just work in the explanation I sent in
http://www.w3.org/mid/4fc64100.3060...@inkedblade.net
e.g.
| Each element in the top layer's stack has a ::backdrop pseudo-element,
| which can be styled to create a backdrop that hides the underlying
| docume
On 06/19/2012 11:37 PM, Adam Klein wrote:
On Sun, Jun 17, 2012 at 12:17 PM, Ryosuke Niwa mailto:rn...@webkit.org>> wrote:
On Sun, Jun 17, 2012 at 5:03 AM, Jonas Sicking mailto:jo...@sicking.cc>> wrote:
On Sat, Jun 16, 2012 at 7:04 AM, Rafael Weinstein mailto:rafa...@google.com>> wro
On 06/19/2012 12:49 AM, Daniel Glazman wrote:
Le 19/06/12 09:41, Anne van Kesteren a écrit :
On Tue, Jun 19, 2012 at 1:45 AM, fantasai wrote:
It looks like you missed #2.
I think ::backdrop is clear enough. Not entirely sure what you would
expect seeing there more than what it already says.
On Mon, Jun 18, 2012 at 10:59 PM, Simon Pieters wrote:
> On Mon, 18 Jun 2012 16:57:17 +0200, Kang-Hao (Kenny) Lu
> wrote:
>> (12/06/18 22:45), Simon Pieters wrote:
>>>
>>> I think we should instead either fix the old API (if it turns out to not
>>> Break the Web) or live with past mistake (if it
On Sun, Jun 17, 2012 at 12:17 PM, Ryosuke Niwa wrote:
> On Sun, Jun 17, 2012 at 5:03 AM, Jonas Sicking wrote:
>
>> On Sat, Jun 16, 2012 at 7:04 AM, Rafael Weinstein
>> wrote:
>> > I too thought we had intentionally spec'd them to not fire during load.
>> >
>> > The HTML spec is clear about this
On 06/19/2012 12:40 AM, Anne van Kesteren wrote:
On Tue, Jun 19, 2012 at 1:31 AM, fantasai wrote:
On 06/01/2012 05:02 AM, Anne van Kesteren wrote:
On Wed, May 30, 2012 at 5:47 PM, fantasai
wrote:
Though it seems likely that 'fixed' is required here, no?
The top layer concept is also used
On 6/19/12 3:49 AM, ext Daniel Glazman wrote:
Le 19/06/12 09:41, Anne van Kesteren a écrit :
On Tue, Jun 19, 2012 at 1:45 AM,
fantasai wrote:
It looks like you missed #2.
I think ::backdrop is clear enough. Not entirely sure what you would
expect seeing there more than what it already says.
I'm not sure this is a problem worth solving in the platform. In 5-10 years
I doubt we'll be typing our card numbers into pages. You'll tap your phone
to your laptop or use some kind of payment service like paypal/wallet/etc.
There's so many security/privacy issues with exposing your payment
infor
Nice idea Alex!
I have done some work on this in the past, but it didn't go very far. A few
tips:
1. As long as many users don't have this, websites would still have to do
form-based credit-card forms. But browsers and extensions are getting
pretty good at auto-filling these forms. So you have a t
Le 19/06/12 14:10, Arthur Barstow a écrit :
Given this interpretation - and of course, please correct it if it is
wrong - it appears the only remaining FPWD Showstopper is #2 in the
first set of comments. Is that correct?
Yes.
On 6/19/12 3:52 AM, ext Daniel Glazman wrote:
Le 18/06/12 13:09, Arthur Barstow a écrit :
On 5/30/12 10:38 AM, ext Daniel Glazman wrote:
Le 30/05/12 14:43, Arthur Barstow a écrit :
Chris, Daniel, Peter - when will the CSS WG make a decision on the
FPWD?
We'll try to make one today during ou
I am very opposed to this, they do different things. Having abilities
isn't a bad thing and numerous Web sites and libraries make use of qsa, not
just because find was not available but because different APIs shapes
interesting new possibilities, different ways of looking at problems,
etc... We so
On 5/29/12 2:45 PM, ext James Hawkins wrote:
Dave Raggett (d...@w3.org) made a call [1] on April 10 to publish a
first public working draft, and this is a Call for Consensus to do so,
using the following document as the basis:
I included public-webapps and public-device-apis on this CfC since
The "Independent User Interface" WG (aka IndieUI) was started a few
weeks ago [Charter] and they now have a CfP for the group's two
specifications: IndieUI Events, and IndieUI User Context. Details below.
-AB
[Charter] http://www.w3.org/2012/05/indie-ui-charter
Original Message -
On Wed, 06 Jun 2012 14:39:35 +0200, Henri Sivonen wrote:
On Sun, May 27, 2012 at 7:45 PM, Anant Narayanan
wrote:
Well, we haven't received this request from developers explicitly yet,
but one can imagine a situation in which a developer makes an app only
for mobile phones (Instagram?) and
On Sat, 16 Jun 2012 06:05:35 +0200, Alex MacCaw wrote:
I've been working on a way of integrating one-click payments (and signup)
into the browser, and I wanted to put it in front of a few people to get
some feedback.
The API I was playing about with was pretty simple, and is documented
here:
Le 18/06/12 13:09, Arthur Barstow a écrit :
On 5/30/12 10:38 AM, ext Daniel Glazman wrote:
Le 30/05/12 14:43, Arthur Barstow a écrit :
Chris, Daniel, Peter - when will the CSS WG make a decision on the FPWD?
We'll try to make one today during our weekly conf-call. Please note
that we're goin
Le 19/06/12 09:41, Anne van Kesteren a écrit :
On Tue, Jun 19, 2012 at 1:45 AM, fantasai wrote:
It looks like you missed #2.
I think ::backdrop is clear enough. Not entirely sure what you would
expect seeing there more than what it already says.
Well, the spec says how it's named, where
On Tue, Jun 19, 2012 at 1:31 AM, fantasai wrote:
> On 06/01/2012 05:02 AM, Anne van Kesteren wrote:
>> On Wed, May 30, 2012 at 5:47 PM, fantasai
>> wrote:
>>> Though it seems likely that 'fixed' is required here, no?
>>
>> The top layer concept is also used by HTML for its element.
>
> This resp
On Tue, Jun 19, 2012 at 1:45 AM, fantasai wrote:
> It looks like you missed #2.
I think ::backdrop is clear enough. Not entirely sure what you would
expect seeing there more than what it already says.
--
Anne — Opera Software
http://annevankesteren.nl/
http://www.opera.com/
On Mon, 18 Jun 2012 15:57:02 +0200, 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
28 matches
Mail list logo