RE: [components] Isolated Imports and Foreign Custom Elements
On Thu Apr 23 02:58 PM, Maciej Stachowiak wrote: > > https://github.com/w3c/webcomponents/wiki/Isolated-Imports-Proposal > > I welcome comments on whether this approach makes sense. Security rules are unclear but love this approach https://lists.w3.org/Archives/Public/public-webapps/2014JulSep/0024.html (2) Ability to have the script associated with the component run in a separate “world” An alternative syntax: http://other-server.example.com/component-library.html";> Fits in nicely with ES realms/spaces/worlds/add your definition.
RE: Minimum viable custom elements
On Wed Feb 4 02:08 PM, Ryosuke Niwa wrote: > > > step="5"> > To me this seems like a winning pattern at least when it comes to input. This did a good job a describing the two approaches: https://wiki.whatwg.org/wiki/Behavior_Attachment Where does the decorator pattern/approach stand?
RE: FileSystem API Comments
On Tue Oct 21 09:36 PM, Jonas Sicking wrote:
> > 1.1 Use cases (3. Audio/Photo editor with offline access or local
> > cache for
> > speed)
> >
> > * Edited files should be accessible by other client-side
> > applications
> >
> > - Having the sandboxed file system share its contents between all
> > apps would allow apps to tamper with the files of another app. This
> > could result in corrupted files and perhaps an invalid state for some
> > apps that expect certain contents to exist in a file. This makes us
> > wonder: should we warn users about files that are being opened and
> > written to?
>
> Each origin has a separate sandboxed filesystem. There is no way for websites
> to read each other's filesystems. This is no different from IndexedDB or
> localStorage. This also means that we have the same prompting behavior, the
> same Quota Management dependency and the same security model as
> IndexedDB and localStorage.
>
That contradicts:
- Edited files should be accessible by other client-side applications
The api should allow for editing a 'shared folder' which multiple applications
/ web apps can access.
That implies a sort of locking/unlocking api:
e.g.
photo editor
fs = api.getFileSystem({shareName: "photos"}).then((dir) => {
dir.openWrite("pic.jpeg") });
super photo viewer
fs = api.getFileSystem({shareName: "photos"}).then((dir) => {
dir.openRead("pic.jpeg") });
What happens with the pic.jpeg?
RE: Passsword managers and autocomplete='off'
> On the other hand, if all browsers collectively chose to completely > ignore autocomplete=off, that might allow proceeding more > aggressively. > Sure, and that's why we're bringing it up with the > standards body. Before we proceed any further, we want to make sure that > (a) our intention is known, and (b) make sure we're not missing anything > critical. So far, the arguments in favor of autocomplete='off' are pretty > much as we already understood them. > Any legal perspective? Banks/financial sites may want autocomplete=off because the user is responsible for keeping his password safe. What happens in the case of fraud? Is the password manager/browser liable? The bank? The user? Who gets sued? That's probably the concern, maybe a liable="user" attribute with popup "hey by using auto-complete manager... do you agree to these risks, insert TOS here..." ?
RE: New manifest spec - ready for FPWD?
On Wed Nov 27 09:20 AM, Mounir Lamouri wrote: > On Wed, Nov 27, 2013, at 23:59, Jonathan Bond-Caron wrote: > > On Tue Nov 26 04:02 PM, Marcos Caceres wrote: > > > Over the last few weeks, a few of us folks in the Web Mob IG have > > > been investigating the use cases and requirements for bookmarking > > > web apps to home screen. The output of that research is this living > > > document: > > > http://w3c-webmob.github.io/installable-webapps/ > > > > > > > Would seem useful to add: MAY provide the application version number. > > Concept of version on the Web is pretty weak. > Depends how you look at the future of applications. Web/http needs to evolve, it was built for delivery of information not apps. Versioning means there's no need to parse a manifest on every single request. > > > That (ongoing) research is helping to inform the manifest spec. A > > > bunch of us have been working together on IRC, twitter, etc. on a > > > new version of the manifest > > > spec: > > > http://w3c.github.io/manifest/ > > > > Any thoughts on adding on 'app' tag? Why is the manifest in JSON? > > > > > > > manifest="more-detailed-stuff.foo"/> > > > > Isn't it pretty hairy to add any element to the because of the parsing > algorithm? > I'm not sure what you mean by hairy, it's simpler to have important metadata directly in the HTML.
RE: New manifest spec - ready for FPWD?
On Tue Nov 26 04:02 PM, Marcos Caceres wrote: > Over the last few weeks, a few of us folks in the Web Mob IG have been > investigating the use cases and requirements for bookmarking web apps to > home > screen. The output of that research is this living document: > http://w3c-webmob.github.io/installable-webapps/ > Would seem useful to add: MAY provide the application version number. > That (ongoing) research is helping to inform the manifest spec. A bunch > of us > have been working together on IRC, twitter, etc. on a new > version of the manifest > spec: > http://w3c.github.io/manifest/ > Any thoughts on adding on 'app' tag? Why is the manifest in JSON? That way the platform knows this 'app' can be "versioned" and can choose to update the application or ask the user what to do.
