URLs in HTML fragments

Tue Mar 14 12:57:36 UTC 2017

Thanks Colin,

It seems like the most logical approach at this time. I’ve updated
FLUID-6142 <https://issues.fluidproject.org/browse/FLUID-6142> with a note
about why we can’t use SVG icons at this moment, but have left it open for
work in the future. I’ve also added some more information to the Research
SVG Icons <https://wiki.fluidproject.org/display/fluid/Research+SVG+Icons> wiki
page and replied to the SVG icons mailing list thread
<http://lists.idrc.ocad.ca/pipermail/fluid-work/2017-March/010326.html> about
the change in direction.

Thanks
Justin

On March 13, 2017 at 4:55:44 PM, Clark, Colin (cclark at ocadu.ca) wrote:

Hi Justin,

We had an interesting discussion on this in the fluid-tech IRC channel
today about issues of SVG URLs, rendering, and icon fonts:

https://botbot.me/freenode/fluid-tech/2017-03-13/?msg=82374792

I think the summary of the discussion is roughly this:

* As counter-intuitive as it may seem, dealing with URL rewriting in this
case, where we are server-agnostic, is complex. This is in part because SVG
uses its own scheme for linking that doesn't seem to harmonize with things
like the CSS url() directive very well
* Even using some kind of rendering technology—either by repurposing Tony
Atkins' Handlebars components, using plain old fluid.stringTemplate(), or
using some of the fragments of work that has been done in the P4A Nexus
Visualizer—would require us to have to write some custom logic for rebasing
URLs
* SVG icons still seem like they will be ideal someday, but given our
current time frame, we are probably better off continuing to use font icons
with some additional build tooling (e.g. Grunt plugins)
* We should follow the advice in this article and make sure our icons use
character codes above e600 in the Unicode PUA:
https://benfrain.com/seriously-use-icon-fonts/

So it sounds like our next step should be to research icon font build tools
and see if there's one that will make the task of maintaining the contents
of our font easier.

Did I capture the discussion fully? What do you think of this approach?

Colin

---
Colin Clark
Lead Software Architect,
Inclusive Design Research Centre, OCAD University
http://inclusivedesign.ca

On Mar 9, 2017, at 12:22 PM, Justin Obara <obara.justin at gmail.com> wrote:

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 ).

_______________________________________________________
fluid-work mailing list - fluid-work at lists.idrc.ocad.ca
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20170314/a08e2036/attachment.html>