URLs in HTML fragments

[Clark, Colin]

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 <mailto:fluid-work at lists.idrc.ocad.ca>
> To unsubscribe, change settings or access archives,
> see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work <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/20170313/f99a646e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1347 bytes
Desc: not available
URL: <http://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20170313/f99a646e/attachment.p7s>