Re: [IndexedDB] Inform script of corruption recovery
On Mon, Feb 11, 2013 at 2:55 PM, Kyle Huey wrote: > On Mon, Feb 11, 2013 at 10:40 PM, David Grogan wrote: > >> 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().
Re: [XHR] withCredentials and HTTP authentication
On Tue, Feb 12, 2013 at 7:52 PM, Monsur Hossain 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: [XHR] withCredentials and HTTP authentication
On Tue, Feb 12, 2013 at 1:36 PM, Anne van Kesteren wrote: > On Tue, Feb 12, 2013 at 7:30 PM, Monsur Hossain wrote: > > On Tue, Feb 12, 2013 at 3:37 AM, Anne van Kesteren > 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:30 PM, Monsur Hossain wrote: > On Tue, Feb 12, 2013 at 3:37 AM, Anne van Kesteren 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 3:37 AM, Anne van Kesteren wrote: > On Tue, Feb 12, 2013 at 4:24 AM, Monsur Hossain 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://@: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: document.register and ES6
On Mon, Feb 11, 2013 at 8:40 PM, Boris Zbarsky 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: [webcomponents] Making the shadow root an Element
On Tue, Feb 12, 2013 at 1:56 AM, Anne van Kesteren wrote: > On Tue, Feb 12, 2013 at 6:11 AM, Tab Atkins Jr. > wrote: > > Sorry, my mistake. My point is that it won't appear in the box tree. > > I think if you put in a normal tree it should just be > display:none. Similar to and friends. No reason for its > descendants to show up. > It's currently spec'd as being inactive ( https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#dfn-inactive-insertion-point). I don't want to break sites that use as a tag today. :DG<
Re: Monkeypatching document.createElement() is wrong
On Tue, Feb 12, 2013 at 9:13 AM, Anne van Kesteren wrote: > On Tue, Feb 12, 2013 at 5:06 PM, Dimitri Glazkov > 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: [shadow-dom] Event Retargeting
On Tue, Feb 12, 2013 at 7:55 AM, Anne van Kesteren 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 > . Now to we apply a shadow tree with an insertion point > for . 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 5:06 PM, Dimitri Glazkov 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: Monkeypatching document.createElement() is wrong
On Tue, Feb 12, 2013 at 3:24 AM, 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.
>
... 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: DRM nonsense in HTML
On Tue, 12 Feb 2013 17:20:56 +0100, Tobie Langel wrote: On 2/12/13 5:05 PM, "Florian Bösch" 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: DRM nonsense in HTML
On 2/12/13 5:05 PM, "Florian Bösch" 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
DRM nonsense in HTML
DRM does not belong into HTML, nor into any kind of W3C standard. It does not belong because it is not a technical capability or discipline, but a pseudo-technical sounding attempt at obfuscation. There are fundamental flaws with the whole media "industries" conception of DRM which are the following: 1) DRM attempts to use encryption with only one trusted party, obviously that is doomed from the start. 2) In order for user-agents to do their jobs, they need to be able to decode media to its raw representation. Since a browser cannot be trusted, but is also the only party able to work with the data, DRM is not gonna work. 3) A standard is intended to define clearly how something works. There can be no such standard for DRM because the intent is not technical, but an exercise in obfuscation, which ipso-facto cannot be defined without defying the intent purpose. As such it would be a standard of absence, where the essential bits are left out, have to be left out. 4) A range of useful technical capabilities (Web Audio Data API, WebGL, CSS shaders etc.) will not be able to work with such DRMed content precisely because they would defy obfuscation. 5) Open source implementations of browsers cannot implement any DRM scheme, because they would have to include an implementation into their source, which ipso-facto, again defies the intent of obfuscation. 6) A DRMed media stream cannot trust a user-agent. It can also not trust the operating system, the video driver or the audio driver. That leaves no trustworthy party to actually implement the standard. 7) DRM schemes as a means of copy-protection are a red-herring of the media industry. The real purpose is to create new barriers of entry to competition. Interoperability is intentionally broken by means of proprietary file-format that enjoy ridiculous legal protection. It cannot be the purpose of the W3C to help an "industry" execute their anti-competitive, market fracturing, barrier raising harebrained schemes. A standard is supposed to make things work better for everyone, everywhere, not the exact diametric opposite. A DRM standard would be exclusionary. 8) DRM methods are among the most patented technologies in existence. Any standards body which dabbles in them and any browser vendor implementing them would draw inevitable lawsuits from patent trolls (non practicing entities) and real companies alike. 9) Since DRM relies solely on obfuscation, but a standard relies on definition, the standard would be subject to a constant cat&mouse game. It cannot be the intent of a standard to be a permanent provisorium. Closing note: DRM is often touted by the media "industry" as a technology. Its relationship to actual technology is about the same as the one of faith-healing to the discipline of actual medicine. It cannot work, it cannot be defined, yet it can hinder interoperability, ease of use and competition. Attempts at the corruption of standards bodies by the media "industry" (or any other industry) have to be vehemently resisted. As a leading example of this one needs to look no further than Microsofts subversion of ISO/ANSI on document standards that set back adoption of common word processor standards to this day.
[shadow-dom] Event Retargeting
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. 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. Also, I think this algorithm gives the wrong result. Given a tree . Now to we apply a shadow tree with an insertion point for . 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? -- 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: 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/
>
>
Monkeypatching document.createElement() is wrong
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 Tue, Feb 12, 2013 at 6:11 AM, Tab Atkins Jr. wrote: > Sorry, my mistake. My point is that it won't appear in the box tree. I think if you put in a normal tree it should just be display:none. Similar to and friends. No reason for its descendants to show up. -- http://annevankesteren.nl/
Re: [XHR] withCredentials and HTTP authentication
On Tue, Feb 12, 2013 at 4:24 AM, Monsur Hossain 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://@: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/
