URLs in HTML fragments

Justin Obara obara.justin at gmail.com
Thu Mar 9 17:22:45 UTC 2017


It’s not uncommon to load in an HTML template for use with an Infusion
component. The preferences framework in particular will load in templates
for the editor and each of the individual adjuster panels. Typically these
fragments are simple markup, but while working on FLUID–6142
<https://issues.fluidproject.org/browse/FLUID-6142>, which is about
switching to SVG icons, I’ve run into a case where we will require URLs in
the template.

For the SVG icons we’ve settled on an approach which includes a minimal
<svg> element which just contains a <use> element to pull in an SVG
fragment from a sprite sheet.

<div>
    <svg>
        <use xlink:href="../icons.svg#fl-icon-contrast" />
    </svg>
</div>

This works well because we get the benefit of browser caching the SVGs, not
having to include all of the SVG markup inline, and still having some
ability to style the SVG icon for the contrast themes.

However, the issue is that the URL used to reference the external SVG
fragment is relative to the HTML document that the HTML fragment is
inserted into. In UI Options, it will be the iframe containing the
preference editor. In a full page version of the preferences framework, it
will be the page itself. All that is to say that we don’t know for sure,
ahead of time, what that relative path actually is.

Below are a couple of solutions to the issue that I’ve thought of. Please
let me know what you think and if there are other options as well. Also,
note that this isn’t only an issue for SVG icons, but for any case where we
might want to have a URL in the template.

Thanks Justin
Possible solutions Modify Resource Fetching

The templates used by the Prefs Framework are pulled in using the
fluid.resourceLoader
<https://github.com/fluid-project/infusion/blob/master/src/framework/core/js/ResourceLoader.js>
which internally makes use of fluid.fetchResources
<https://github.com/fluid-project/infusion/blob/master/src/framework/core/js/FluidRequests.js#L48-L83>.
We could modify one or both of these to be able to perform some form of
manipulation on the fetched content before it is injected into DOM. We’d
likely need to be able to have tokens in the HTML fragment to identify the
parts to be replaced.
Rebase URLs using DOM manipulation

Another option would be to have a component or grade responsible for
rebasing the URLs after the content has been inserted into the DOM. This
will potentially introduce some lag between the time the page loads and the
icons are rendered. It will also be a performance hit.
Require the integrator to update URLs in the HTML Fragments

We could require that the integrator ensure all of the paths in the HTML
fragments are correct for their particular use case. This seems
unsatisfactory and may require ourselves to have multiple templates just
for our manual tests and demos to all work.
Require that URLs are not in HTLM fragments

We could require that an HTML fragment not contain any URLs.

Options for SVG icons in this case would be:

   - don’t use SVG icons, continue with font icons
   - use inline SVG for each icon
   - continue to make use of the referenced SVG but embed the sprite sheet
   into the page ( something / someone would still be responsible for doing
   this and browser caching will be lost/diminished ).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20170309/069594b6/attachment.html>


More information about the fluid-work mailing list