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

在 2017年04月11日 20:04, Patrick Dark 写道:
> 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.

JavaScript and XHR/fetch would be unavoidable if large amount of data 
have to be processed, even for local web pages with fixed structure. E.g.:

* Large 3D model files to be used in WebGL.
* Media files not supported by browsers natively, with decoders in js. 
E.g. MIDI, WebP, AV1...
* A programming tutorial with many sample codes, and web page 
load+parse+format those codes and show them inline.
   Sample codes should also be readily edited/compiled directly.

>
> 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 Wednesday, 12 April 2017 08:40:16 UTC