Re: [XHR] withCredentials and HTTP authentication

2013-02-12 Thread Anne van Kesteren
On Tue, Feb 12, 2013 at 4:24 AM, Monsur Hossain mon...@gmail.com wrote:
 The XHR spec defines user credentials as cookies, HTTP authentication,
 and client-side SSL certificates. Its not clear to me what HTTP
 authentication referring to.

 I assumed it was referring to the HTTP authentication in RFC 2617, which
 uses the Authorization header. But a quick test shows that arbitrary
 Authorization headers are allowed on CORS requests.

 It could also mean the http://username@password:domain.com form of
 authentication (not sure where this is formally defined).

 What type of http authentication is the XHR spec referring to?

User credentials stored by the user agent based on a previous visit to the URL.

Authorization is only allowed through CORS if the server opts in, btw.

These details should become more clear once I turn
http://wiki.whatwg.org/wiki/Fetch into a proper specification.


-- 
http://annevankesteren.nl/



Re: [webcomponents] Making the shadow root an Element

2013-02-12 Thread Anne van Kesteren
On Tue, Feb 12, 2013 at 6:11 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 Sorry, my mistake.  My point is that it won't appear in the box tree.

I think if you put shadow in a normal tree it should just be
display:none. Similar to element and friends. No reason for its
descendants to show up.


-- 
http://annevankesteren.nl/



Re: Monkeypatching document.createElement() is wrong

2013-02-12 Thread Alex Russell
+others who have been involved in the design phase of the Google proposal

So there are several viable points in the design space here. I'll try to
outline them quickly:


   1. An internal lifecycle driver for element + shadow creation.
   In this strategy, an element's constructor either calls
   createShadow()/finalizeInitialization() methods directly, or calls the
   superclass constructor to ensure that they are invoked.
   2. External lifecycle driver.
   In this design, it's up to whoever new's up an Element to ensure that
   it's fully formed before injecting it into the DOM.

The current design codifies the second.

Regarding Audio() and Image(), it's possible to model them as having
internal already called flags on their shadow creation methods that
prevent double initialization by createElement(). But I agree that it's
messier and muddies the de-sugaring story.

Dimitri? Dominic?

On Tuesday, February 12, 2013, Anne van Kesteren wrote:

 If the goal of custom elements is to expose the guts of what happens

 https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html#monkeypatch-create-element
 is the wrong solution. Currently new Image() and createElement(img)
 are equivalent and no additional magic is required. Same for new
 Audio() and createElement(audio). What we want is that

 var x = document.createElement(name)

 maps to / is identical to

 var x = new name's-corresponding-object

 and nothing else.


 --
 http://annevankesteren.nl/




Re: [webcomponents] Making the shadow root an Element

2013-02-12 Thread Boris Zbarsky

On 2/12/13 1:11 AM, Tab Atkins Jr. wrote:

Not given the flattened tree construction algorithm I last saw...  Am I just
missing something?


Right, because it's not an element yet, and thus can't appear in the
tree like all the other elements do.  Once it becomes an element, I
presume it would.


I presume it wouldn't; there's no reason for it to.  As in, it's equally 
magic for it to appear and not appear (but its kids appear), as far as I 
can tell.



Sorry, my mistake.  My point is that it won't appear in the box tree.


Yes, on that we agree, even if we disagree on the reasons for why it 
doesn't appear there.  ;)


-Boris




Re: DRM nonsense in HTML

2013-02-12 Thread Tobie Langel
On 2/12/13 5:05 PM, Florian Bösch pya...@gmail.com wrote:

DRM does not belong into HTML, nor into any kind of W3C standard. [...]

This is the wrong mailing list. You might want to look at
http://www.w3.org/html/wg/lists/.

--tobie





Re: DRM nonsense in HTML

2013-02-12 Thread Charles McCathie Nevile

On Tue, 12 Feb 2013 17:20:56 +0100, Tobie Langel to...@fb.com wrote:


On 2/12/13 5:05 PM, Florian Bösch pya...@gmail.com wrote:


DRM does not belong into HTML, nor into any kind of W3C standard. [...]


This is the wrong mailing list. You might want to look at
http://www.w3.org/html/wg/lists/.


Exactly. Discussion on this list should be restricted to work items of  
this group - http://www.w3.org/2008/webapps/wiki/PubStatus - or proposals  
for new work items. Things other groups should or should not do are  
explicitly off-topic.


for the chairs

Chaals

--
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
  cha...@yandex-team.ru Find more at http://yandex.com



Re: Monkeypatching document.createElement() is wrong

2013-02-12 Thread Dimitri Glazkov
On Tue, Feb 12, 2013 at 3:24 AM, Anne van Kesteren ann...@annevk.nl wrote:

 If the goal of custom elements is to expose the guts of what happens

 https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html#monkeypatch-create-element
 is the wrong solution. Currently new Image() and createElement(img)
 are equivalent and no additional magic is required. Same for new
 Audio() and createElement(audio). What we want is that

 var x = document.createElement(name)

 maps to / is identical to

 var x = new name's-corresponding-object

 and nothing else.


... and that's exactly how custom elements are being spec'd. See how
constructor is generated:
https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html#dfn-custom-element-constructor-generation

By the wrongness, do you mean the running shadow tree instantiation and
element finalization steps? If so, they are workarounds for our inability
to define an author-defined constructor.

There's a nice thread that tries to enable this and eliminate these extra
steps, but from what I understand, there's a monkey wrench thrown by
inability of current JS engines to accommodate the proposed design:
http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/thread.html#msg250

:DG


Re: Monkeypatching document.createElement() is wrong

2013-02-12 Thread Anne van Kesteren
On Tue, Feb 12, 2013 at 5:06 PM, Dimitri Glazkov dglaz...@chromium.org wrote:
 By the wrongness, do you mean the running shadow tree instantiation and
 element finalization steps? If so, they are workarounds for our inability to
 define an author-defined constructor.

Yes.


 There's a nice thread that tries to enable this and eliminate these extra
 steps, but from what I understand, there's a monkey wrench thrown by
 inability of current JS engines to accommodate the proposed design:
 http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/thread.html#msg250

Given all the other plumbing that's required to get web components
working and ES6 requires said design to work, I'd think that waiting a
little longer to do the right thing is acceptable.


-- 
http://annevankesteren.nl/



Re: [shadow-dom] Event Retargeting

2013-02-12 Thread Dimitri Glazkov
On Tue, Feb 12, 2013 at 7:55 AM, Anne van Kesteren ann...@annevk.nl wrote:

 The more I read this algorithm to figure out how to rewrite DOM event
 dispatch the more confused I get. For starters it would probably help
 if ancestor was renamed to event parent.


Well.. I am not sure what event parent is, but the ancestor is just an
item along the event path.



 I was wondering if this rewrite of 3.1-3.3 is correct:

 1. Let CONTEXT be null.
 2. If ANCESTOR is an insertion point, set CONTEXT to the top-most item
 in STACK that is not an insertion point, if any.
 3. If STACK is empty, push ANCESTOR on STACK.

 I think this would be quite a bit clearer.


Cool! Filed a bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20982




 Also, I think this algorithm gives the wrong result. Given a tree
 ab//a. Now to a we apply a shadow tree with an insertion point
 for b. This algorithm seems to say that we go through the shadow
 tree and when we reach the shadow root we change the target, but that
 would mean the shadow tree is observable from the DOM, which is bad.
 Am I misunderstanding something here?


Okay, let's unroll this. Suppose we have this tree:

a -- [sr] -- 
|
b

(where  is the insertion point, and [sr] is the shadow root)

1) Event is fired on b.
2) ANCESTOR = b
3) ANCESTOR is not an insertion point
4) CONTEXT = null
5) STACK is empty, so STACK.push(b) (STACK now [b])
6) TARGET = b
7) Adding (b, b) to TARGETS
8) ANCESTOR is not a shadow root
9) ANCESTOR = 
10) ANCESTOR is an insertion point
11) CONTEXT = b
12) TOP = b
13) STACK.push(b) (STACK now [b,b])
14) TARGET = b
15) Adding (b, ) to TARGETS
16) ANCESTOR is not a shadow root
17) ANCESTOR = [sr]
18) ANCESTOR is not an insertion point
19) CONTEXT = null
20) TARGET = b
21) Adding (b, [sr]) to TARGETS
22) ANCESTOR is a shadow root, so STACK.pop() (STACK now [b])
23) ANCESTOR = a
24) ANCESTOR is not an insertion point
25) CONTEXT = null
26) TARGET = b
27) Adding (b, a) to TARGETS
28) ANCESTOR is not a shadow root
29) ANCESTOR = null (for our tree)
30) stop.

At the end of the road, our TARGETS looks like this:

Adjusted target is b when at b
Adjusted target is b when at 
Adjusted target is b when at a

As you can see, no details about the shadow tree have leaked. This is a
simple example, but once you get into nested trees, you'll see that the
algo still works.

:DG


Re: Monkeypatching document.createElement() is wrong

2013-02-12 Thread Dimitri Glazkov
On Tue, Feb 12, 2013 at 9:13 AM, Anne van Kesteren ann...@annevk.nl wrote:

 On Tue, Feb 12, 2013 at 5:06 PM, Dimitri Glazkov dglaz...@chromium.org
 wrote:
  By the wrongness, do you mean the running shadow tree instantiation and
  element finalization steps? If so, they are workarounds for our
 inability to
  define an author-defined constructor.

 Yes.


  There's a nice thread that tries to enable this and eliminate these extra
  steps, but from what I understand, there's a monkey wrench thrown by
  inability of current JS engines to accommodate the proposed design:
 
 http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/thread.html#msg250

 Given all the other plumbing that's required to get web components
 working and ES6 requires said design to work, I'd think that waiting a
 little longer to do the right thing is acceptable.


Waiting a little bit longer is a fine phrase, except it neither sets the
timeline nor priorities. If it's weeks, not months, I agree. Otherwise, I
would rather consider workable solutions. We've been waiting for XBL2 for
a little bit now :)

:DG


Re: document.register and ES6

2013-02-12 Thread Dimitri Glazkov
On Mon, Feb 11, 2013 at 8:40 PM, Boris Zbarsky bzbar...@mit.edu wrote:

 On 2/7/13 6:15 PM, Dimitri Glazkov wrote:

 1) Expose the ability to override [[Construct]]. Arv tells me that he
 spoke with V8 peeps and they think they can do this fairly easily. How's
 the SpiderMonkey story looking here?


 Requires major surgery on how functions are implemented; not likely in the
 foreseeable future.


Yikes.


Re: [XHR] withCredentials and HTTP authentication

2013-02-12 Thread Monsur Hossain
On Tue, Feb 12, 2013 at 3:37 AM, Anne van Kesteren ann...@annevk.nl wrote:

 On Tue, Feb 12, 2013 at 4:24 AM, Monsur Hossain mon...@gmail.com wrote:
  The XHR spec defines user credentials as cookies, HTTP authentication,
  and client-side SSL certificates. Its not clear to me what HTTP
  authentication referring to.
 
  I assumed it was referring to the HTTP authentication in RFC 2617, which
  uses the Authorization header. But a quick test shows that arbitrary
  Authorization headers are allowed on CORS requests.
 
  It could also mean the http://username@password:domain.com form of
  authentication (not sure where this is formally defined).
 
  What type of http authentication is the XHR spec referring to?

 User credentials stored by the user agent based on a previous visit to the
 URL.


Ok thanks. I think it would be useful if the HTTP authentication in the
above sentence snippet were either dropped or clarified (The CORS spec also
uses the same sentence).

Authorization is only allowed through CORS if the server opts in, btw.

 These details should become more clear once I turn
 http://wiki.whatwg.org/wiki/Fetch into a proper specification.


 --
 http://annevankesteren.nl/



Re: [XHR] withCredentials and HTTP authentication

2013-02-12 Thread Anne van Kesteren
On Tue, Feb 12, 2013 at 7:30 PM, Monsur Hossain mon...@gmail.com wrote:
 On Tue, Feb 12, 2013 at 3:37 AM, Anne van Kesteren ann...@annevk.nl wrote:
 User credentials stored by the user agent based on a previous visit to the
 URL.

 Ok thanks. I think it would be useful if the HTTP authentication in the
 above sentence snippet were either dropped or clarified (The CORS spec also
 uses the same sentence).

How is it different from mentioning cookies? It has the same effect, no?


-- 
http://annevankesteren.nl/



Re: [XHR] withCredentials and HTTP authentication

2013-02-12 Thread Monsur Hossain
On Tue, Feb 12, 2013 at 1:36 PM, Anne van Kesteren ann...@annevk.nl wrote:

 On Tue, Feb 12, 2013 at 7:30 PM, Monsur Hossain mon...@gmail.com wrote:
  On Tue, Feb 12, 2013 at 3:37 AM, Anne van Kesteren ann...@annevk.nl
 wrote:
  User credentials stored by the user agent based on a previous visit to
 the
  URL.
 
  Ok thanks. I think it would be useful if the HTTP authentication in the
  above sentence snippet were either dropped or clarified (The CORS spec
 also
  uses the same sentence).

 How is it different from mentioning cookies? It has the same effect, no?


I think what was confusing to me is that the
Access-Control-Allow-Credentials section of the CORS spec indicates that a
true value indicates that the actual request can include user
credentials.

In the case of cookies, both the client's .withCredentials and the server's
Access-Control-Allow-Credentials must be true in order for the user-agent
to return the response to the client.

But in the case of the Authorization header, the server's opt-in
mechanism is Access-Control-Allow-Headers, and has no connection to
Access-Control-Allow-Credentials.

The sentence above reads as if cookies and HTTP Authentication are
both governed by the Access-Control-Allow-Credentials header, which is not
the case in practice.

Note that I am assuming that HTTP Authentication is referring to RFC 2617
and the use of the Authorization header. But the definition for user
credentials in the Terminology section of the CORS spec doesn't say
either way. If this is the case, there should be a reference to RFC 2617 in
the Terminology section (Next to [COOKIES]). And if this is not the
case, there should be more information to disambiguate the term HTTP
Authentication from RFC2617.

Thanks,
Monsur




 --
 http://annevankesteren.nl/



Re: [XHR] withCredentials and HTTP authentication

2013-02-12 Thread Anne van Kesteren
On Tue, Feb 12, 2013 at 7:52 PM, Monsur Hossain mon...@gmail.com wrote:
 I think what was confusing to me is that the
 Access-Control-Allow-Credentials section of the CORS spec indicates that a
 true value indicates that the actual request can include user
 credentials.

 In the case of cookies, both the client's .withCredentials and the server's
 Access-Control-Allow-Credentials must be true in order for the user-agent
 to return the response to the client.

 But in the case of the Authorization header, the server's opt-in mechanism
 is Access-Control-Allow-Headers, and has no connection to
 Access-Control-Allow-Credentials.

Hmm I see what you mean. But the user agent can provide the
Authorization header too based on a previous visit. That is the
meaning that is most often meant, but in the particular case of CORS
the semantics are subtly different. Not sure how to clarify that
exactly.


-- 
http://annevankesteren.nl/



Re: [IndexedDB] Inform script of corruption recovery

2013-02-12 Thread David Grogan
On Mon, Feb 11, 2013 at 2:55 PM, Kyle Huey m...@kylehuey.com wrote:

 On Mon, Feb 11, 2013 at 10:40 PM, David Grogan dgro...@chromium.orgwrote:

 When chrome opens an IDB database, it attempts to detect corruption. If
 the database appears to have been corrupted, either via software bug or
 hardware fault, chrome performs recovery. As currently implemented (we
 may try to do something more surgical in the future), recovery
 means removing all the origin's databases from disk and creating a new
 empty database. It would be useful to alert script that some data has been
 lost in this situation. The web app could then alert the user or take other
 appropriate action. This is important in offline editing scenarios, where
 this represents true user data loss rather than just a flush of a data
 cache.


 Do you expect to ever be able to implement something more granular than a
 per-database recover or discard?  I would imagine that's as surgical as it
 is going to get.


We've talked about checkpointing, which would allow chrome to recover
everything except the last N commits.


 I think the answer to that question impacts how we design this.


I'm assuming you mean because a surgical recovery could leave the version
intact and make a new property on the upgradeneeded event inaccessible? In
that case we could also put the property on the success event that comes in
response to open().