W3C home > Mailing lists > Public > whatwg@whatwg.org > April 2017

Re: [whatwg] Accessing local files with JavaScript portably and securely

From: Patrick Dark <whatwg.at.whatwg.org@patrick.dark.name>
Date: Tue, 11 Apr 2017 07:04:42 -0500
To: Jan Tosovsky <jan.tosovsky.cz@gmail.com>
Message-ID: <b5ed9023-a05b-93f0-a8aa-29619a479782@patrick.dark.name>
Cc: "whatwg@whatwg.org" <whatwg@whatwg.org>
Jan Tosovsky 於 4/10/2017 5:38 PM 寫道:
> 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 <script> tag in the HTML header. It is hence loaded together with the page and you can manipulate it further with javascript. In case of ToC to render data as itemized list with proper CSS classes and even detect if the current item matches the actual page (if so use a different class).
>
> So basically you need
> (1) JSON
> (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.
>
> If you have to list the file structure of CD-ROM, I suppose it is fixed so it doesn't need to be determined dynamically, but in advance. I can imagine simple Java 'walker'[2] which could traverse all the folder content and export all necessary data into JSON structure.

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.

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. To accommodate Chrome's deficiency while keeping maintenance down 
(i.e., avoiding putting a copy of the TOC in every HTML file), one could 
create a standalone index page. That's less convenient than an 
XSLT-based navigation panel, but it's doable today.
Received on Tuesday, 11 April 2017 12:05:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 11 April 2017 12:05:21 UTC