Re: CFC: Publish a FPWD of IndexedDB 2.0
+1 Alexander Schmitz jQuery Foundation On Tue, Aug 9, 2016 at 8:45 AM, Dylan Barrell wrote: > +1 > > On Tue, Aug 9, 2016 at 5:06 AM, Léonie Watson wrote: > >> Quick reminder that this CFC closes at the end of day tomorrow (Wednesday >> 10th August). Thanks. >> >> Léonie. >> >> -- >> @LeonieWatson tink.uk Carpe diem >> >> On 03/08/2016 15:46, Léonie Watson wrote: >> >>> Hello WP, >>> >>> This is a Call For Consensus (CFC) to publish a First Public Working >>> Draft (FPWD) of IndexedDB 2.0 [1]. >>> >>> We are still exploring different ways of responding to a CFC. Please >>> choose one of the following methods: >>> >>> 1. Reply by email to this thread (on >>> public-webapps@w3.org). >>> >>> 2. Reply or +1 on Github: >>> https://github.com/w3c/IndexedDB/issues/84 >>> >>> There is no need to use more than one method. The WP chairs will collate >>> the results across all channels. >>> >>> Please respond by end of day on Wednesday 10th August. Positive >>> responses are encouraged, but silence will be taken as consent with the >>> proposal. >>> >>> Thanks >>> Léonie on behalf of the WP chairs and team >>> [1] >>> http://w3c.github.io/IndexedDB/ >>> >> >> > > > -- > Download the aXe browser extension for free: > > Firefox: https://addons.mozilla.org/en-US/firefox/addon/axe-devtools > Chrome: https://chrome.google.com/webstore/detail/axe/ > lhdoppojpmngadmnindnejefpokejbdd?hl=en-US > > Life is ten percent what happens to you and ninety percent how you respond > to it. - Lou Holtz > >
Re: CFC: Request to move HTML5.1 to Candidate Recommendation (CR)
+1 Alexander Schmitz jQuery Foundation On Mon, Jun 6, 2016 at 8:31 AM, Ian Pouncey wrote: > +1 > > On 2 June 2016 at 13:48, Léonie Watson wrote: >> >> Hello WP, >> >> This is a call for consensus to request that W3C publish the current HTML >> Working Draft (WD) as a Candidate Recommendation (CR). It has been posted >> to >> public-webapps@w3.org as the official email for this WG. >> >> Please reply to this thread on public-webapps@w3.org no later than end of >> day on 10 June. Positive responses are preferred and encouraged, silence >> will be considered as assent. >> >> The current HTML5.1 WD [1] improves upon HTML5. It includes updates that >> make it more reliable, more readable and understandable, and a better >> match >> for reality. Substantial changes between HTML5 and HTML5.1 can be found in >> the spec [2]. >> >> When a specification moves to CR it triggers a Call For Exclusions, per >> section 4 of the W3C Patent Policy [3]. No substantive additions can be >> made >> to a specification in CR without starting a new Call for Exclusions, so we >> will put HTML5.1 into "feature freeze". It is possible to make editorial >> updates as necessary, and features marked "At Risk" may be removed if >> found >> not to be interoperable. >> >> The following features are considered "at risk". If we cannot identify at >> least two shipping implementations, they will be marked "at risk" in the >> CR >> and may be removed from the Proposed Recommendation. >> >> keygen element. [issue 43] >> label as a reassociatable element [issue 109] >> Fixing requestAnimationFrame to 60Hz, not implementation-defined [issues >> 159/375/422] >> registerContentHandler [Issue 233] >> inputmode attribute of the input element [issue 269] >> autofill of form elements [issue 372] >> menu, menuitem and context menus. [issue 373] >> dialog element [issue 427] >> Text tracks exposing in-band metadata best practices [Issue 461] >> datetime and datatime-local states of the input element [Issue 462] >> >> Please share implementation details for any of these features on Github. >> To >> mark other features "at risk", please identify them by 10th June (ideally >> by >> filing an issue and providing a test case). >> >> At the same time we move HTML5.1 into CR, we plan to continue updating the >> Editor's Draft, and in the next few weeks we expect to post a Call for >> Consensus to publish it as the First Public Working Draft of HTML5.2, so >> improving HTML will continue without a pause. It also means that changes >> that didn't make it into >> HTML5.1 will not have long to wait before being incorporated into the >> specification. >> >> Léonie on behalf of the WP chairs and team, and HTML editors. >> [1] https://www.w3.org/TR/html51/ >> [2] https://www.w3.org/TR/html51/changes.html#changes >> [3] https://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Exclusion >> >> [issue 43] https://github.com/w3c/html/issues/43 >> [issue 109] https://github.com/w3c/html/issues/109 >> [issues 159/375/422] https://github.com/w3c/html/issues/159 and links >> [issue >> 233] https://github.com/w3c/html/issues/233 >> [issue 269] https://github.com/w3c/html/issues/269 >> [issue 372] https://github.com/w3c/html/issues/372 >> [issue 373] https://github.com/w3c/html/issues/373 >> [issue 427] https://github.com/w3c/html/issues/427 >> [Issue 461] https://github.com/w3c/html/issues/461 >> [Issue 462] https://github.com/w3c/html/issues/462 >> >> >> -- >> @LeonieWatson tink.uk Carpe diem >> >> >> >> >
Re: File API - where are the missing parts?
> > * Should permissions persist? If you're working in an editor and reload the > > tab, being hit with a flurry of permission prompts is less than ideal. But > > if you visit it again in a day or a year? And, similar to the "template" > > case above, what if you use a web-based editor to modify a file, then > > revisit the site a year later. > I don't think long persistence on file-location is a feasible idea. But the > option to choose persistence within a session seems a viable compromise. > You'll still need to click the dialog away once, but then you can work > uninterrupted. There is already a case similar to this with built in popup blockers in most browsers where you can allow once or always allow a similar approach could be taken with this. On Tue, Feb 23, 2016 at 4:50 PM, Florian Bösch wrote: > On Tue, Feb 23, 2016 at 7:06 PM, Joshua Bell wrote: >> >> On Tue, Feb 23, 2016 at 7:12 AM, Florian Bösch wrote: >>> >>> On Tue, Feb 23, 2016 at 2:48 AM, Jonas Sicking wrote: Is the last bullet here really accurate? How can you use existing APIs to listen to file modifications? >>> >>> I have not tested this on all UAs, but in Google Chrome what you can do >>> is to set an interval to check a files.lastModified date, and if a >>> modification is detected, read it in again with a FileReader and that works >>> fine. >> >> >> Huh... we should probably specify and/or fix that. > > Specify rather than fix, please. > There are also APIs implemented in several browsers for opening a whole directory of files from a webpage. This has been possible for some time in Chrome, and support was also recently added to Firefox and Edge. I'm not sure how interoperable these APIs are across browsers though :( >> >> >> IIRC, Edge's API[1] mimics Chrome's, and you can polyfill Firefox's API >> [2] on top of Chrome/Edge's[3]. So in theory if Firefox's pleases developers >> they can adopt the polyfill, and other browsers can transition to native >> support. >> >> [1] https://lists.w3.org/Archives/Public/public-wicg/2015Sep/.html >> [2] https://wicg.github.io/directory-upload/proposal.html >> [3] https://github.com/WICG/directory-upload/blob/gh-pages/polyfill.js >> >> ... or just read Ali's excellent summary: >> >> https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0245.html >> >> (But that's all a tangent to Florian's main use cases...) > > It's good to know this on a standards track. > >> True, but if we determine that permissions must be granted then the API >> needs to be designed to handle it, e.g. entry points to the API surface are >> through a requestPermission() API, everything is async, etc. > > > Ack > >> >> One concern is: what capabilities are granted by this action? Can the >> web-app re-save the file? Can it re-read the file? Does that permission >> persist across sessions? For example, if I save a document template from a >> site I would not expect the site to be able to read the file after I've >> edited with an unrelated file editor. >>> >>> Save many files to a user pickable folder: same as above >>> Working directory: this is more something that would go on in the >>> background of a UA, it would have to establish a "working directory" per tab >>> rather than UA-wide. No UX issues with that. >> >> Agreed. Likely doesn't even need to be specified - it'd just be a "least >> surprise" behavior by the UA. > > The save to directory case is less easy to handle because it impinges on > overwrite. After some thought, I'd move that to the more difficult UX cases. > >> >> * Since "File > Open" is supported today (via ) we must >> be careful about exposing functionality that has similar UX (i.e. a native >> file open dialog) but that implicitly grants extra permissions (e.g. being >> able to modify the file). This points to either additional UX during the >> action, UX when the app wants to write, or a more general permission granted >> to the origin for some scope (file? directory?). > > I'd think this to be a non formative note on implementation for UAs. The > mechanism of denying an action by the API should be fairly straightforward. > >> >> * Should permissions persist? If you're working in an editor and reload >> the tab, being hit with a flurry of permission prompts is less than ideal. >> But if you visit it again in a day or a year? And, similar to the "template" >> case above, what if you use a web-based editor to modify a file, then >> revisit the site a year later. > > I don't think long persistence on file-location is a feasible idea. But the > option to choose persistence within a session seems a viable compromise. > You'll still need to click the dialog away once, but then you can work > uninterrupted.
