Dedicated directory for web-apps
Hello everyone, I'm certainly not the first to think or to propose, but I think there is a huge deficiency on web-apps: there is no real dedicated directory for the application persistent data, where the app could read/write files without user intervention. Why this umpteenth interest in such a feature requiring enhanced security? --- I'm currently developing a web-app to communicate securely via an Encryption Algorithm that I developed. Considering that my users have a real need for such security, it goes without saying that they also need persistence. If the user clears its cache, he lose all application persistent data saved by LocalStorage and/or IndexedDB, then it needs a persistence... more persistent. Why without user intervention? --- Simply because it would be rather inconvenient to ask the user to store dataon each message. My idea is when the confirmation of installation, a message informs the user that the application will create the folder and will have rights to read/write, as well as its sub-folders (never a parent). This could also allow the user to store downloaded data in its preferred application (for example, because it is specially adapted to read). This would avoid having to re-download it especially if all emptied cache (in most countries, a mobile connection is still paying the volume of data transfer). Thanks for your advices. Cordialy, Michaël Rouges
Re: Shadow DOM and Fallback contents for images
On Tue, Oct 15, 2013 at 12:04 PM, Ryosuke Niwa rn...@apple.com wrote: On Oct 13, 2013, at 9:19 PM, Jonas Sicking jo...@sicking.cc wrote: On Sun, Oct 13, 2013 at 9:11 PM, Ryosuke Niwa rn...@apple.com wrote: On Oct 11, 2013, at 10:52 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Oct 11, 2013 at 10:23 PM, Ryosuke Niwa rn...@apple.com wrote: On Oct 7, 2013, at 1:38 PM, Jonas Sicking jo...@sicking.cc wrote: On Oct 7, 2013 6:56 AM, Hajime Morrita morr...@google.com wrote: Hi, I'm sorry that I didn't notice that you were talking about UA shadow DOM. It's an implementation detail and the standard won't care about that. That being said, it might be a good exercise to think about feasibility to implement img-like custom element which supports alternate text. 1. Selections – Which the specification is clear. It will not allow the selection range cannot span across different node trees. This again would hinder seamless experience with selection. Is this needed to implement alt text? Try this on Firefox: http://jsfiddle.net/8gkAV/2/ . The caret just skips the alt-text. I think we generally consider that a bug. I think this is a desirable behavior since the img element is atomic. I don't think we want to let the user start editing the alt text since the user can't stylize the alt anyway. Note that this part is about selection, not editing. I don't see any reason to treat the alt text different from any other text. I.e. that the user can select character-by-character by default, but that this can be overridden by the author if desired. If I'm not mistaken, how alternative text is presented is up to UA vendors. Given that, I don't think we should mandate one way or another with respect to this behavior. A more important question is what happens to selection inside a shadow DOM created by the author. 2. Editing – The spec says that the contenteditable attribute should not be propagated from the shadow host to the shadow root. Does this mean that and Shadow DOM cannot participate in editing? This I find is limiting to use shadow DOM to represent fallback content This is same as 1) above. The caret skips the alt-text. I think these are desirable behavior because, if Shadow DOM is editable in @contentEditable subtree by default, the component author (who added the shadow DOM) has to make the element definition ready for editing. Selection and editing are related but different. Text displayed on screen should by default always be selectable. The fact that it isn't in canvas for example is a bad thing. It is fine to enable the author to opt out of making the selection selectable, but the default should be that it is selectable Ugh, my text here is gibberish :) I think I intended to say: It is fine to enable the author to opt out of making the shadow content selectable, but the default should be that it is selectable. I don't think that's what the spec currently says. The way I interpret it, selection should work as if it's in a separate iframe. So the text will be selectable but the selection can only extend within the shadow DOM inside the shadow DOM, and selection will treat its shadow host as an atomic unit outside of it. Sounds like we should change the spec. Unless we have a good reason to treat selection as atomic? One good reason is that the editing specification needs to be aware of shadow DOM and various operations such as deletion and copy needs to take care of the shadow DOM boundaries. e.g. what should UA copy if selection ends points are in two different shadow trees. Requiring each selection end to be in the same shadow tree solves this problem. Again, most selections are not related to editing. As far as I know, the most common use case of selecting anything on a Web page is copying it to somewhere else. Sure. But copying is also different from editing. I think that if we made all text inside shadow content only selectable as a whole, that would make shadow content a second class citizen in the page. The result would be that authors actively avoid putting text inside shadow content since the user experience would be so surprising. What are concrete examples of components for which users have to select text across the shadow boundary? Any component which contains text in the shadow content. For example a component that generates the +-- Note - |Text here +-- That appears in many specs. The Note text here would likely appear in the shadow content. / Jonas
Re: Shadow DOM and Fallback contents for images
On Tue, Oct 15, 2013 at 2:39 AM, Hajime Morrita morr...@google.com wrote: The text in shadows are select-able, and it behaves kind of like iframes as Ryosuke mentioned. I'm not sure if these are clear from the current draft, but points are: - Users can select a part of the shadow tree. - If selected range is in a shadow tree, it isn't accessible (in API sense) outside the shadow. For one outside the shadow, that is document.getSelection(), the selection is represented as a range which selects the shadow host. Inside shadow, that is ShadowRoot.getSelection(), the selection points the node inside the shadow. This is how encapsulation works with Shadow DOM. It's just about API. The UA knows what part of the text is selected. Thus things like clipboards should work as expected. - The selection cannot cross the shadow boundary. Both ends of the selection should be in a same tree. I think this restriction is mainly for simplicity. Does this make sense? Yup, this sounds great. So selecting text inside shadow content will look exactly like selecting text text from outside the shadow content from a user's point of view. / Jonas On Mon, Oct 14, 2013 at 1:19 PM, Jonas Sicking jo...@sicking.cc wrote: On Sun, Oct 13, 2013 at 9:11 PM, Ryosuke Niwa rn...@apple.com wrote: On Oct 11, 2013, at 10:52 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Oct 11, 2013 at 10:23 PM, Ryosuke Niwa rn...@apple.com wrote: On Oct 7, 2013, at 1:38 PM, Jonas Sicking jo...@sicking.cc wrote: On Oct 7, 2013 6:56 AM, Hajime Morrita morr...@google.com wrote: Hi, I'm sorry that I didn't notice that you were talking about UA shadow DOM. It's an implementation detail and the standard won't care about that. That being said, it might be a good exercise to think about feasibility to implement img-like custom element which supports alternate text. 1. Selections – Which the specification is clear. It will not allow the selection range cannot span across different node trees. This again would hinder seamless experience with selection. Is this needed to implement alt text? Try this on Firefox: http://jsfiddle.net/8gkAV/2/ . The caret just skips the alt-text. I think we generally consider that a bug. I think this is a desirable behavior since the img element is atomic. I don't think we want to let the user start editing the alt text since the user can't stylize the alt anyway. Note that this part is about selection, not editing. I don't see any reason to treat the alt text different from any other text. I.e. that the user can select character-by-character by default, but that this can be overridden by the author if desired. If I'm not mistaken, how alternative text is presented is up to UA vendors. Given that, I don't think we should mandate one way or another with respect to this behavior. A more important question is what happens to selection inside a shadow DOM created by the author. 2. Editing – The spec says that the contenteditable attribute should not be propagated from the shadow host to the shadow root. Does this mean that and Shadow DOM cannot participate in editing? This I find is limiting to use shadow DOM to represent fallback content This is same as 1) above. The caret skips the alt-text. I think these are desirable behavior because, if Shadow DOM is editable in @contentEditable subtree by default, the component author (who added the shadow DOM) has to make the element definition ready for editing. Selection and editing are related but different. Text displayed on screen should by default always be selectable. The fact that it isn't in canvas for example is a bad thing. It is fine to enable the author to opt out of making the selection selectable, but the default should be that it is selectable Ugh, my text here is gibberish :) I think I intended to say: It is fine to enable the author to opt out of making the shadow content selectable, but the default should be that it is selectable. I don't think that's what the spec currently says. The way I interpret it, selection should work as if it's in a separate iframe. So the text will be selectable but the selection can only extend within the shadow DOM inside the shadow DOM, and selection will treat its shadow host as an atomic unit outside of it. Sounds like we should change the spec. Unless we have a good reason to treat selection as atomic? One good reason is that the editing specification needs to be aware of shadow DOM and various operations such as deletion and copy needs to take care of the shadow DOM boundaries. e.g. what should UA copy if selection ends points are in two different shadow trees. Requiring each selection end to be in the same shadow tree solves this problem. Again, most selections are not related to editing. I think that if we made all
Re: Shadow DOM and Fallback contents for images
On Oct 16, 2013, at 5:14 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Oct 15, 2013 at 12:04 PM, Ryosuke Niwa rn...@apple.com wrote: On Oct 13, 2013, at 9:19 PM, Jonas Sicking jo...@sicking.cc wrote: On Sun, Oct 13, 2013 at 9:11 PM, Ryosuke Niwa rn...@apple.com wrote: On Oct 11, 2013, at 10:52 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Oct 11, 2013 at 10:23 PM, Ryosuke Niwa rn...@apple.com wrote: On Oct 7, 2013, at 1:38 PM, Jonas Sicking jo...@sicking.cc wrote: On Oct 7, 2013 6:56 AM, Hajime Morrita morr...@google.com wrote: Hi, I'm sorry that I didn't notice that you were talking about UA shadow DOM. It's an implementation detail and the standard won't care about that. That being said, it might be a good exercise to think about feasibility to implement img-like custom element which supports alternate text. 1. Selections – Which the specification is clear. It will not allow the selection range cannot span across different node trees. This again would hinder seamless experience with selection. Is this needed to implement alt text? Try this on Firefox: http://jsfiddle.net/8gkAV/2/ . The caret just skips the alt-text. I think we generally consider that a bug. I think this is a desirable behavior since the img element is atomic. I don't think we want to let the user start editing the alt text since the user can't stylize the alt anyway. Note that this part is about selection, not editing. I don't see any reason to treat the alt text different from any other text. I.e. that the user can select character-by-character by default, but that this can be overridden by the author if desired. If I'm not mistaken, how alternative text is presented is up to UA vendors. Given that, I don't think we should mandate one way or another with respect to this behavior. A more important question is what happens to selection inside a shadow DOM created by the author. 2. Editing – The spec says that the contenteditable attribute should not be propagated from the shadow host to the shadow root. Does this mean that and Shadow DOM cannot participate in editing? This I find is limiting to use shadow DOM to represent fallback content This is same as 1) above. The caret skips the alt-text. I think these are desirable behavior because, if Shadow DOM is editable in @contentEditable subtree by default, the component author (who added the shadow DOM) has to make the element definition ready for editing. Selection and editing are related but different. Text displayed on screen should by default always be selectable. The fact that it isn't in canvas for example is a bad thing. It is fine to enable the author to opt out of making the selection selectable, but the default should be that it is selectable Ugh, my text here is gibberish :) I think I intended to say: It is fine to enable the author to opt out of making the shadow content selectable, but the default should be that it is selectable. I don't think that's what the spec currently says. The way I interpret it, selection should work as if it's in a separate iframe. So the text will be selectable but the selection can only extend within the shadow DOM inside the shadow DOM, and selection will treat its shadow host as an atomic unit outside of it. Sounds like we should change the spec. Unless we have a good reason to treat selection as atomic? One good reason is that the editing specification needs to be aware of shadow DOM and various operations such as deletion and copy needs to take care of the shadow DOM boundaries. e.g. what should UA copy if selection ends points are in two different shadow trees. Requiring each selection end to be in the same shadow tree solves this problem. Again, most selections are not related to editing. As far as I know, the most common use case of selecting anything on a Web page is copying it to somewhere else. Sure. But copying is also different from editing. I think that if we made all text inside shadow content only selectable as a whole, that would make shadow content a second class citizen in the page. The result would be that authors actively avoid putting text inside shadow content since the user experience would be so surprising. What are concrete examples of components for which users have to select text across the shadow boundary? Any component which contains text in the shadow content. For example a component that generates the +-- Note - |Text here +-- That appears in many specs. The Note text here would likely appear in the shadow content. In that case, the entire Note will be selected as an atomic unit. Is there a use case in which you want to select a part of Note and a part of Text here? As Hajime noted, users can select text as long as both ends of selections are in the same shadow tree. - R. Niwa
Re: [clipboard-apis] Seeking status and plans
Hi Arthur, the spec todo list is in bugzilla: https://www.w3.org/bugzilla_public/buglist.cgi?product=WebAppsWGcomponent=Clipboard%20API%20and%20eventsresolution=--- Some of these issues will need developer feedback. I need to try to find developers who have worked on clipboard implementations on various platforms. I hope to get that done and close all bugs not marked spec.next before going to TR. -Hallvord - Original Message - From: Arthur Barstow art.bars...@nokia.com To: Hallvord Steen hst...@mozilla.com Cc: public-webapps public-webapps@w3.org Sent: Wednesday, October 2, 2013 6:38:13 PM Subject: [clipboard-apis] Seeking status and plans Hi Hallvord, If any of the data for Clipboard APIs and Events in [PubStatus] is not accurate, please provide corrections. Also, if you have any new information re your plans for the spec, the spec's status with respect to being feature complete, implementation status, please let us know. -Thanks, ArtB [PubStatus] http://www.w3.org/2008/webapps/wiki/PubStatus
Re: Shadow DOM and Fallback contents for images
On Oct 16, 2013 8:04 PM, Ryosuke Niwa rn...@apple.com wrote: On Oct 16, 2013, at 5:14 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Oct 15, 2013 at 12:04 PM, Ryosuke Niwa rn...@apple.com wrote: On Oct 13, 2013, at 9:19 PM, Jonas Sicking jo...@sicking.cc wrote: On Sun, Oct 13, 2013 at 9:11 PM, Ryosuke Niwa rn...@apple.com wrote: On Oct 11, 2013, at 10:52 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Oct 11, 2013 at 10:23 PM, Ryosuke Niwa rn...@apple.com wrote: On Oct 7, 2013, at 1:38 PM, Jonas Sicking jo...@sicking.cc wrote: On Oct 7, 2013 6:56 AM, Hajime Morrita morr...@google.com wrote: Hi, I'm sorry that I didn't notice that you were talking about UA shadow DOM. It's an implementation detail and the standard won't care about that. That being said, it might be a good exercise to think about feasibility to implement img-like custom element which supports alternate text. 1. Selections – Which the specification is clear. It will not allow the selection range cannot span across different node trees. This again would hinder seamless experience with selection. Is this needed to implement alt text? Try this on Firefox: http://jsfiddle.net/8gkAV/2/ . The caret just skips the alt-text. I think we generally consider that a bug. I think this is a desirable behavior since the img element is atomic. I don't think we want to let the user start editing the alt text since the user can't stylize the alt anyway. Note that this part is about selection, not editing. I don't see any reason to treat the alt text different from any other text. I.e. that the user can select character-by-character by default, but that this can be overridden by the author if desired. If I'm not mistaken, how alternative text is presented is up to UA vendors. Given that, I don't think we should mandate one way or another with respect to this behavior. A more important question is what happens to selection inside a shadow DOM created by the author. 2. Editing – The spec says that the contenteditable attribute should not be propagated from the shadow host to the shadow root. Does this mean that and Shadow DOM cannot participate in editing? This I find is limiting to use shadow DOM to represent fallback content This is same as 1) above. The caret skips the alt-text. I think these are desirable behavior because, if Shadow DOM is editable in @contentEditable subtree by default, the component author (who added the shadow DOM) has to make the element definition ready for editing. Selection and editing are related but different. Text displayed on screen should by default always be selectable. The fact that it isn't in canvas for example is a bad thing. It is fine to enable the author to opt out of making the selection selectable, but the default should be that it is selectable Ugh, my text here is gibberish :) I think I intended to say: It is fine to enable the author to opt out of making the shadow content selectable, but the default should be that it is selectable. I don't think that's what the spec currently says. The way I interpret it, selection should work as if it's in a separate iframe. So the text will be selectable but the selection can only extend within the shadow DOM inside the shadow DOM, and selection will treat its shadow host as an atomic unit outside of it. Sounds like we should change the spec. Unless we have a good reason to treat selection as atomic? One good reason is that the editing specification needs to be aware of shadow DOM and various operations such as deletion and copy needs to take care of the shadow DOM boundaries. e.g. what should UA copy if selection ends points are in two different shadow trees. Requiring each selection end to be in the same shadow tree solves this problem. Again, most selections are not related to editing. As far as I know, the most common use case of selecting anything on a Web page is copying it to somewhere else. Sure. But copying is also different from editing. I think that if we made all text inside shadow content only selectable as a whole, that would make shadow content a second class citizen in the page. The result would be that authors actively avoid putting text inside shadow content since the user experience would be so surprising. What are concrete examples of components for which users have to select text across the shadow boundary? Any component which contains text in the shadow content. For example a component that generates the +-- Note - |Text here +-- That appears in many specs. The Note text here would likely appear in the shadow content. In that case, the entire Note will be selected as an atomic unit. Is there a use case in which you want to select a part of Note and a part of Text here? What if the text Note was longer? Is
Re: Shadow DOM and Fallback contents for images
Talking over an example might help... div Hello span #shadowroot Shadow /span World /div This renders text Hello Shadow World. In my understanding, following patterns of selections are allowed: A. H[ell]o Shadow World - selection stays outside shadow B. Hello S[had]ow world - selection stays inside shadow C. H[ello Shadow Worl]d - selection stays outside shadow, but its range contains a node with shadow. This is not allowed: D. H[ello Shado]w World - selection spans outside to inside. What unclear for me is: - For case of C, should we consider Shadow being selected? Naively thinking yes, but the implication isn't that clear. - Should we have a way to forbid B to ensure the selection atomicity? Probably yes, but I don't think we have one. The spec could clarify this point. My feeling is that this is tangential to Shadow DOM and is more about generic selection atomicity concept. It could be covered by a CSS property for example. On Thu, Oct 17, 2013 at 1:25 PM, Jonas Sicking jo...@sicking.cc wrote: On Oct 16, 2013 8:04 PM, Ryosuke Niwa rn...@apple.com wrote: On Oct 16, 2013, at 5:14 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Oct 15, 2013 at 12:04 PM, Ryosuke Niwa rn...@apple.com wrote: On Oct 13, 2013, at 9:19 PM, Jonas Sicking jo...@sicking.cc wrote: On Sun, Oct 13, 2013 at 9:11 PM, Ryosuke Niwa rn...@apple.com wrote: On Oct 11, 2013, at 10:52 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Oct 11, 2013 at 10:23 PM, Ryosuke Niwa rn...@apple.com wrote: On Oct 7, 2013, at 1:38 PM, Jonas Sicking jo...@sicking.cc wrote: On Oct 7, 2013 6:56 AM, Hajime Morrita morr...@google.com wrote: Hi, I'm sorry that I didn't notice that you were talking about UA shadow DOM. It's an implementation detail and the standard won't care about that. That being said, it might be a good exercise to think about feasibility to implement img-like custom element which supports alternate text. 1. Selections – Which the specification is clear. It will not allow the selection range cannot span across different node trees. This again would hinder seamless experience with selection. Is this needed to implement alt text? Try this on Firefox: http://jsfiddle.net/8gkAV/2/ . The caret just skips the alt-text. I think we generally consider that a bug. I think this is a desirable behavior since the img element is atomic. I don't think we want to let the user start editing the alt text since the user can't stylize the alt anyway. Note that this part is about selection, not editing. I don't see any reason to treat the alt text different from any other text. I.e. that the user can select character-by-character by default, but that this can be overridden by the author if desired. If I'm not mistaken, how alternative text is presented is up to UA vendors. Given that, I don't think we should mandate one way or another with respect to this behavior. A more important question is what happens to selection inside a shadow DOM created by the author. 2. Editing – The spec says that the contenteditable attribute should not be propagated from the shadow host to the shadow root. Does this mean that and Shadow DOM cannot participate in editing? This I find is limiting to use shadow DOM to represent fallback content This is same as 1) above. The caret skips the alt-text. I think these are desirable behavior because, if Shadow DOM is editable in @contentEditable subtree by default, the component author (who added the shadow DOM) has to make the element definition ready for editing. Selection and editing are related but different. Text displayed on screen should by default always be selectable. The fact that it isn't in canvas for example is a bad thing. It is fine to enable the author to opt out of making the selection selectable, but the default should be that it is selectable Ugh, my text here is gibberish :) I think I intended to say: It is fine to enable the author to opt out of making the shadow content selectable, but the default should be that it is selectable. I don't think that's what the spec currently says. The way I interpret it, selection should work as if it's in a separate iframe. So the text will be selectable but the selection can only extend within the shadow DOM inside the shadow DOM, and selection will treat its shadow host as an atomic unit outside of it. Sounds like we should change the spec. Unless we have a good reason to treat selection as atomic? One good reason is that the editing specification needs to be aware of shadow DOM and various operations such as deletion and copy needs to take care of the shadow DOM boundaries. e.g. what should UA copy if selection ends points are in two
