Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support arbitrary HTML Attributes #139

Open
jherdman opened this issue Apr 29, 2022 · 1 comment
Open

Support arbitrary HTML Attributes #139

jherdman opened this issue Apr 29, 2022 · 1 comment

Comments

@jherdman
Copy link

To aid with tooling like AlpineJS the following would be nice:

<%= inline_svg_pack_tag "my/svg.svg", 'x-show': 'foo' %>

Ideally any HTML attribute ought to be supported.

Let's look at the options table:

key description
id set a ID attribute on the SVG
class set a CSS class attribute on the SVG
style set a CSS style attribute on the SVG
data add data attributes to the SVG (supply as a hash)
size set width and height attributes on the SVG
Can also be set using height and/or width attributes, which take precedence over size
Supplied as "{Width} * {Height}" or "{Number}", so "30px*45px" becomes width="30px" and height="45px", and "50%" becomes width="50%" and height="50%"
title add a <title> node inside the top level of the SVG document
desc add a <desc> node inside the top level of the SVG document
nocomment remove comment tags from the SVG document
preserve_aspect_ratio adds a preserveAspectRatio attribute to the SVG
aria adds common accessibility attributes to the SVG (see PR #34 for details)
aria_hidden adds the aria-hidden=true attribute to the SVG
fallback set fallback SVG document

I think a great many of these would benefit from a change in API that allowed for arbitrary HTML attrs.

Hypothetical future API:

<%= inline_svg "foo.svg",
  attrs: { aria: { hidden: true }, class: "fill-current", id: "123" },
  svg: { title: "My foo" },
  fallback: "whatever"
%>
@jamesmartin
Copy link
Owner

Thanks for the suggestion. Definitely not against this idea in principle but would only be possible if somebody from the community were prepared to work on this.

Obviously this kind of API change would require a major version bump. Version 2.0 is around the corner, so if anybody wants this to happen soon, and can spare the time to work on it, please let me know.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants