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

generic-switch stylability without parts and progressive enhancement #14

Open
thepassle opened this issue May 9, 2020 · 5 comments
Open

Comments

@thepassle
Copy link
Owner

Styling

The generic-switch is somewhat of a headache. If a browser supports ::part, the component is fully stylable, if they dont however, it'll just look like the default 'ugly' switch.

In other components this is less of a problem, because they depend on user provided lightdom, e.g. the listbox:

<generic-listbox>
  <ul>
    <li>item 1</li>
    <li>item 2</li>
  </ul>
</generic-listbox>

Progressive enhancement

Progressive enhancement is somewhat of another problem here. The only 'sensible' thing I can currently think of is having the user provide a native checkbox as lightdom. If theres a case where there is no JS available, it would just fallback to a checkbox. But this feels a bit weird/unnatural to do, because while somewhat similar, a checkbox is not a switch button, and the checkbox wouldnt be used by the generic-switch internally at all. It'd only be there for fallback reasons.

It takes away from the simplicity and ease of use of just using a <generic-switch> and dropping it in your page as well.

@thepassle thepassle added this to the V1 milestone May 9, 2020
@jordanaustin
Copy link

As far as custom styling, what about just sprinkling in some css custom properties which has a little wider browser support to give the user the ability to style the switch at a basic level?

Definitely a little sad to lose the simplicity of just <generic-switch> but if you're going for progressive enhancement it seems like the only real option is to force the user to add a checkbox input into the lifghtdom (still 😢).

@thepassle
Copy link
Owner Author

The problem with css custom properties is that they only allow you to style a specific property that I have exposed with a css custom property, so while it does make styling more customizable, it wont be completely styleable. E.g. if I dont specifiy a custom property for the width, a user still wont be able to customize the width 😕

Another option actually might be to make the component just render its internals to the lightdom instead. Ive not really considered that before. That way a user could just directly style the button/thumb/track divs.

Im also thinking it may not be as big a problem as im making it out to be, parts did land in all modern browsers, and a polyfill is planned or already in development, so I guess in some way its just a problem of the times

@thepassle
Copy link
Owner Author

Re progressive enhancement, an escape hatch might be to just hide the component if its not defined with generic-switch(:defined) {}. If javascript is not available, the switch won't be able to offer any interactivity anyway (much like a native button, unless used in a form), so why show it?

That way a user basically has two options:

  • Just dont show the button if js is not available
  • Use a checkbox as lightdom if you do want to show something as a fallback

@jordanaustin
Copy link

RE styling, I totally agree with you that the custom properties wouldn't give total control over styling, but it might be a decent alternative for basic styling which could be used if parts isn't available.

@jordanaustin
Copy link

RE progressive enhancement, that seems pretty good. To me it would awesome to conditionally add the checkbox to lightdom if you wanted a fallback 🤷

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