Re: [whatwg] Accessing local files with JavaScript portably and securely
On 2017-04-11 Patrick Dark wrote: > Jan Tosovsky 2017-04-10 wrote: > > > On 2017-04-09 David Kendal wrote: > > > > > > ... there are many possible uses for local static files > > > accessing other local static files: the one I have in mind > > > is shipping static files on CD-ROM or USB stick... > > > > So basically you need > > (1) JSON /* the folder structure stored in JavaScript objects */ > > (2) link to that JSON in your HTML file > > (3) JavaScript in your HTML file, which renders JSON data to the page > > > > In my case both WebHelp pages and JSON is generated via XSLT from XML > > source. > > There's no reason to use JavaScript for displaying a table of contents. > If the file structure is fixed, you can simply hard-code static XML > entries in an XSLT stylesheet. While slighty off-topic, my goal was to reduce the final HTML file size. The more pages, the larger ToC so the size of the complete set grows exponentially. If ToC is extracted and then just linked in every HTML page, it reduces the total size significantly. If documentation is shipped together with desktop app in the form of installer, it is better to keep it as small as possible. > Granted, Google Chrome won't do XSLT transformations for local files, > but that seems to be more of a browser deficiency than a specification > issue. Sorry not being precise, that mentioned XSLT transformation (for my DocBook XML) is performed once off-the-browser, producing linked static HTML pages (and also JSON with the file hierarchy). I wanted to emphasize that generating JSON can be, in specific cases, nicely integrated into current generating workflow (the file structure is already available in DocBook XSL stylesheets for other purposes so it was quite easy to reuse it for generating JSON for ToC). Jan
Re: [whatwg] Accessing local files with JavaScript portably and securely
On 2017-04-10 David Kendal wrote: > On 2017-04-09 Jan Tosovsky wrote: > > On 2017-04-09 David Kendal wrote: > > > > > ... there are many possible uses for local static files accessing > > > other local static files: the one I have in mind is shipping static > > > files on CD-ROM or USB stick... > > > > In this case the file structure is fixed so it can be exported as > > JSON file and then linked via the HTML header in every HTML file where > > it is needed. This structure is then directly available for the further > > processing. > > > > However, I am not sure this covers your use case. > > I'm not sure either, because I don't understand what you're proposing. > What feature of the HTML header enables this functionality? (For an > arbitrary number of files which may be wanted by an arbitrary number > of other files, and which could be very large.) Imagine e.g. WebHelp composed of collection of static files with Table of Contents (ToC) in the left pane. It is not very efficient to generate large ToC into every single HTML file. If you extract ToC into a dedicated HTML page, it cannot be imported by standard means directly into another HTML page (analogically to XML Inclusions [1]). You have to use either IFrame, or, better, provide ToC as JSON file. JSON is kind of javascript which can be linked via the
Re: [whatwg] Accessing local files with JavaScript portably and securely
On 2017-04-09 David Kendal wrote: > > ... there are many possible uses for local static files accessing > other local static files: the one I have in mind is shipping static > files on CD-ROM or USB stick... In this case the file structure is fixed so it can be exported as JSON file and then linked via the HTML header in every HTML file where it is needed. This structure is then directly available for the further processing. However, I am not sure this covers your use case. Jan
[whatwg] Upload enhancements
Dear All,
I've seen many similar threads with input type=file proposals, but also
lot of people taking the current spec as sufficient for the majority of use
cases.
I'd like to describe several scenarios revealing current gaps and propose
the corresponding changes.
The missing access to the file system is a blocker now for replacing many
client apps to their web counterparts. The basic question is whether web
technologies should implement this functionality or not. I think it is a
must, though limited to a trusted zone and OSes with file systems.
By that trusted zone I mean a local network (local servers can access the
client file system via user action) or Internet location authorized by a
specific means (e.g. certificate like Java Applets).
In this trusted zone several new features (options) can be used for input
type=file:
A. Initial directory (URI) - by default set to {user.home}. If the initial
directory is not found, the default value is used. It improves user
experience signifficantly when browsing the same location multiple times
(and it is set by the web app accordingly).
B. Path info - when set to true, files are uploaded together with the paths
relativized to the initial directory.
C. Local compression - when set to true, selected files are compressed into
a single ZIP file before uploading.
D. Max size - the total size together with the unit (10M, 2G, 100k) which is
verified before either compressing (when enabled) or uploading.
Selection modes:
1. Single file
2. Multiple files
3. Directory with all descendants - selected by a special dialog allowing to
select directories only; used for 1:1 copying of e.g. user document library
into the specific location of the enterprise document storage. Quick and
efficient from the user perspective.
4. Single file with parent directory and all its descendants - selected by
the standard file dialog; the selected file is always passed as the first
in the array; used for various server/cloud solutions e.g. conversion of
your XML data together with resources (stored in directories besides the
main XML file) into various formats. Very powerful method how to transfer
both the data and the key file name at once. When compression is enabled,
that single ZIP file is transfered in the name of that key file.
How can I help with implementing this into the spec?
Thanks, Jan
