thepassle / generic-components

A collection of generic web components with a focus on accessibility, and ease of use
https://genericcomponents.netlify.app/
MIT License
557 stars 29 forks source link

generic-switch stylability without parts and progressive enhancement #14

Open thepassle opened 4 years ago

thepassle commented 4 years ago

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.

jordanaustin commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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:

jordanaustin commented 4 years ago

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 commented 4 years ago

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