Re: [XHR] withCredentials and HTTP authentication
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
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
+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
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
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
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
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
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
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
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
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
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
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
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
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
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().
