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

Allow style overrides for SVG elements #8

Open
drwpow opened this issue Sep 3, 2023 · 3 comments
Open

Allow style overrides for SVG elements #8

drwpow opened this issue Sep 3, 2023 · 3 comments

Comments

@drwpow
Copy link
Contributor

drwpow commented Sep 3, 2023

Problem

Wanted to open up an issue to discuss rather than a PR. When this component is rendered, it has hardcoded fill stylings on the SVG elements, and doesn’t expose predictable CSS classnames to select anything:

<svg width="337" height="276" class="svelte-g8w4qc">
  <g transform="translate(10,10)">
    <g transform="translate(238.80464917978173,30.615056478261636)">
      <circle cx="0" cy="0" r="5" fill="none" stroke-width="1.75" stroke="#fff"></circle>
      <circle cx="0" cy="0" r="6" fill="none" stroke-width="1.25" stroke="#000"></circle>
    </g>
  </g>
  <g transform="translate(286,10)">
    <g transform="translate(0,179.2)">
      <polygon points="-7,-4 -1,0 -7,4" fill="#fff" stroke-width="0.8" stroke="#000"></polygon>
      <polygon points="38,-4 32,0 38,4" fill="#fff" stroke-width="0.8" stroke="#000"></polygon>
    </g>
  </g>
</svg>

I’d like some selector to override default styles from the parent component if possible. Some examples would include, but not limited to:

  • Coloring the triangles based on light or dark mode (or adjusting to not be pure #000 / #fff to match other elements on page)
  • Changing border widths / colors of SVG elements
  • Adjusting sizing of picker circle / hue triangle
  • Adjusting the spacing between the picker square & hue wheel

Of course, all of these are opinionated and there’s no default styling that would make everyone happy. So just allowing for style overrides would be helpful.

Solution

One solution would possibly be to use global styling which would make selection easier. Elements could have some classname prefix such as scs-* (for svelte-color-select, but I don’t care what the prefix is). For example:

<div class="scs-colorpicker">
  <svg class="scs-colorpicker-picker">
    <g class="scs-colorpicker-lcsquare">…</g>
    <g class="scs-colorpicker-huewheel">
      <polygon class="scs-colorpicker-triangle scs-colorpicker-triangle--left"></polygon>
      <polygon class="scs-colorpicker-triangle scs-colorpicker-triangle--right"></polygon>
    </g>
  </svg>
</div>

No opinion on the actual prefix name, names of elements, or syntax (BEM/OOCSS/SMACCS/etc). Just as long as elements are exposed by some predictable class name (even if there are no default styles) that’d be ideal.

Also classnames would be preferred over IDs for the main reason there may be more than one of these colorpickers per page (would be rare, but possible nonetheless)


Open to thoughts / feedback! As well as other alternatives.

@CaptainCodeman
Copy link
Owner

Yeah, the options are usually to expose the classes as you have above, use css properties / variables to allow certain things to be overridden (which may be enough - there's probably a limited number of things that likely need to be overridden as you listed) or, for ultimate flexibility, switch to a "headless" approach (but with a default implementation provided). I guess it could also provide some slots to allow overriding some things (like providing your own SVG element)

@drwpow
Copy link
Contributor Author

drwpow commented Sep 4, 2023

Yeah a headless approach would be neat! Personally I really only need tiny styling tweaks that CSS could pull off—I like having all the elements there and hooked up—but a headless approach could allow for customizations like aligning the hue wheel horizontally under the square, etc.

@CaptainCodeman
Copy link
Owner

Yes, you should be able to make it look like any other color select component with a headless approach, which would be neat. It could still provide a default implementation (or two) for people who just want the ready-baked approach.

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

No branches or pull requests

2 participants