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

UX: Discussion of usage of set font-sizes in CSS #1018

Open
kosmiq opened this issue Jul 11, 2019 · 5 comments
Open

UX: Discussion of usage of set font-sizes in CSS #1018

kosmiq opened this issue Jul 11, 2019 · 5 comments

Comments

@kosmiq
Copy link

kosmiq commented Jul 11, 2019

An issue with the current multiselect setup is that the font-sizes are defined within the CSS for the component itself.

This could affect usage in a few ways:

  • Accessibility is affected if the user is attempting to scale the font-size (browser zoom, changed browser defaults) for increased readability (but the font-size is set to 16px so it might not scale).
  • If the project designer decides that the base font-size for a page/project should be anything else than the default 16px the multiselect dropdown will not scale with that (or like older bootstrap: 14px as base).
  • If the user of the component places it in a tag, any other tag or CSS-class that scales the font-size the multiselect will not scale its text according to the container.

This should be the desired behaviour, enforcing 16px at all times (like current versions) have negative effects on the expected behaviour of the component (IMO). The component should scale with whatever font size its container is set to (be it HTML root font-size, a h1 tag or a specific class set to a container around the multiselect element).

A few CSS fixes would handle this fine. No explicit font-size should be set for the following classes:

  • .multiselect
  • .multiselect__placeholder
  • .multiselect__single
  • .multiselect__input

For the following classes it should be changed to a percentage based value:

  • .multiselect__tags
    • Set to font-size: 87.5%; (will be 14px on a 16px base)
  • .multiselect__tag-icon:after
    • Set to font-size: 87.5%; (will be 14px on a 16px base)
  • .multiselect--option:after
    • Set to font-size: 81.25%; (will be 13px on a 16px base)

An alternate solution would be to make this an SCSS choice
Like exposing a setting in the SCSS variables that allows for a 16px base set in the component or supplying your own OR disabling the font-sizes in the component CSS to make it scale with your Framework of choice.

Reproduction Link

https://jsfiddle.net/bvt7hpru/

Steps to reproduce

Look at the multiselect element added inside the tag. It does not scale with the font-size set inside

Expected behaviour

https://jsfiddle.net/0faynh25/

The multiselect element scales with the set font-size

Actual behaviour

The text size does not scale with the font-size set inside

@shentao
Copy link
Owner

shentao commented Jul 31, 2019

I think one of the issues was that with a smaller font, the screen on mobile devices used to zoom, which was reported as an issue previously (if I remember correctly). I would actually rather use rem units instead of a percentage.
Would you like to provide a PR for that?

@kosmiq
Copy link
Author

kosmiq commented Jul 31, 2019

Well I can expand some on that behavior. IOS (probably android as welö, don't have a handset available atm) do zoom on form components if they are deemed to small. However I think it should be up to the developer of the page to set how this should behave. You can set meta tags that decides if the page should zoom on forms or not (or rather zoom if some expression somewhere in the used browser deems the input too small). Setting that on a component could create irregular/inconsistent behavior between different parts of a form.

Example:
A form with name, mail, phone and a select box from this component. The user clicks name/mail/phone and the client zooms. The user clicks the select and it does not. Same form, different behaviors = bad experience IMO.

Regarding percentage vs rem:
Rem is a bad idea since it will be root relative and thus not scale in the following case:
Html root is 16px
A div is set to 14px
The user adds the select inside the div with 14px
The select will use 16px as base instead of expected 14px based on the wrapper it's placed in.

Example:
Re-using the form from above. It's placed in a container with 14px base. All normal/standard html inputs will scale to 14px. Using rems the select from this component will not.

We could however use em instead of percentage/rem. Em are relative to its closest declaration. Thus it will scale in the above example.

I am all for leaving sensible defaults that behaves the same way as any standard component would do.

I can provide a PR with ems instead of %. I could probably update my previous PR (or would you like a new one?).

@shentao
Copy link
Owner

shentao commented Jul 31, 2019

A separate PR would be more preferable. I’m still kind of worried about using em though. I imagine using rem for everything would actually be a bit better since it would then nicely adjust to the user having a bit different settings in the browser (say, increased font-size for improved readability). I’m also afraid that if we change it to em it will be a breaking change for many people that placed the component inside a div with a completely different font-size.
What about we introduce a fixed rem size at the top level of the multiselect and then have the child elements use em? This should make it quite easy to override the default size and have the internal elements inherit them.
What do you think?

@soichih
Copy link

soichih commented Nov 27, 2019

I just came across vue-multiselect, and it looks great! However, I am not able to use this because the font-size is way too big for our web app, and it doesn't scale accordingly to the parent font-size. I think switching to rem would solve it, and I strongly hope that vue-multiselect can adopt it.

@shentao
Copy link
Owner

shentao commented Nov 27, 2019

That is a great idea actually. I hope to work on a next major release in December.

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

3 participants