Re: SVG templating language standards?

Brennan – yes, if one were to assume that the SVG would be consumed in a browser, then HTML in a foreign-object element might indeed be an option…However, I am not sure that is indeed the case as I could set use cases where the VC is displayed in a native app or other environment w/o a full browser engine behind it (for security, size or other reasons).    But it is definitely something worth discussing around use cases and requirements.


From: Brennan Young <>
Date: Tuesday, July 12, 2022 at 10:52 AM
To: Manu Sporny <>
Cc: <>
Subject: Re: SVG templating language standards?

EXTERNAL: Use caution when clicking on links or opening attachments.

Regarding text-flow in SVG.

Manu's question appears to be about *display* (i.e. presentation), rather than just delivery of verifiable string data (e.g. a hash or a public key) to a client. Do I understand this correctly? Clarification on this point would be useful.

I know far too little about the use case here, but a possible avenue for exploration might be foreign-object elements (in practice these are HTML-in-SVG) which seem to handle text flow rather more predictably than the text element in SVG 1.0. AFAICT user agents hand these off to the HTML rendering engine, with all the text-layout advantages afforded there. CSS may be applied to HTML child elements of foreign-object if special presentation is important.

Not all SVG renderers support foreign-object in exactly the same way, but in general, browser support is very good today, and as it’s “just markup”, then templating engines should be able to handle it. I observe that all non-deprecated major browsers render CSS-styled HTML elements correctly in foreign-object even if the root document is SVG.

If the intention is to make the verifiable credential *text* available to a broad range of user agents and presentation technologies, then ARIA may be a viable choice. ARIA is well-supported in SVG, as long as appropriate semantic roles are used. We should however be wary of the impulse to insert public keys and other ’noisy' machine-readable data strings into text alternative attributes intended for labelling and description, as this would degrade the experience for assistive tech users.

Please make the VGWG aware that assistive tech users’ access to verifiable credential text should be considered as part of any solution for the presentation of these credentials - if they are not already aware, that is.

Furthermore, considering several specific WCAG success criteria will offer valuable insights, in particular:<><><>

And above all<>

With the experience of accessibility on the web thus far, it would be wisest not to rely on content authors to provide special handling for these credentials to achieve accessibility conformance in their presentation, but I recognise that this is a greater challenge.

On 10 Jul 2022, at 19.25, Manu Sporny <<>> wrote:

Hi SVG-ers, :)

The Verifiable Credentials WG has been rechartered to work on VC 2.0:<>

... and "display of VCs" is almost certainly going to be a topic of concern
over the next 18 months.

It has been suggested that utilizing SVG to provide graphical rendering of VCs
will meet the needs of 80% of our use cases. With that in mind, here's what we
have to work with:

* We have a JSON data structure containing variables
 that need to be rendered in an SVG file.

* We can reference an SVG file TEMPLATE or include one
 directly in the Verifiable Credential.

The questions to this group are:

1. Does there exist an SVG templating language?
2. If so, does it take JSON objects as input?
3. Any hints/pointers on previous attempts/failures?

We have been mixing SVG + a subset of Handlebars + JSON Pointer:

<svg version="1.1" width="300" height="200"

 <text x="150" y="125" font-size="60"
       text-anchor="middle" fill="white">

Note the use of "{{}}" in the SVG markup.

Any guidance from those who know better before we go down this path?

-- manu

Manu Sporny -
Founder/CEO - Digital Bazaar, Inc.
News: Digital Bazaar Announces New Case Studies (2021)

Received on Tuesday, 12 July 2022 14:59:05 UTC