Scalable UI

[nothingismagick]

1. Claim

   • Current changes to root html font-size does not scale all components consistently.
     • Hard coded px values make it impossible to correctly scale Quasar without end users either:
     • forking it and changing those hard coded values or
     • overriding all Quasar CSS classes.

2. Background

   • There is a need to scale Quasar UI to accomodate end user requirements for UI density (e.g. highly technical applications requiring increased UI density and accessibility concerns with decreased UI density).
   • Overridding all of the exposed Quasar stylus variables to use rem (rather than px) in an attempt to scale the Quasar UI using the HTML font-size is ineffective.
   • There are a large quantity of components that have hard coded px font-sizes, padding, margin, etc. (e.g. the table component does not scale it's td font size--it's always 13px) so these components do not respond correctly to root font-size changes.
   • There are also components that were coded with rem values so the scale is inconsistent when changing the root html font-size.

3. Research Here is a list of components where anx is placed if the stylus file for the component uses a specific type of css units:

component name	rem	em	%	px
ajax-bar			x
avatar		x	x	x
badge				x
banner				x
bar				x
breadcrumbs			x	x
btn-default		x	x	x
btn-dropdown				x
btn-group			x	x
card			x	x
carousel			x	x
chat			x	x
checkbox			x	x
chip				x
circular-progress		x	x
color		x	x	x
date		x	x	x
time		x	x	x
dialog	x	x	x	x
bottom-sheet			x	x
dialog-plugin				x
editor				x
fab			x
field		x	x	x
form
img
inner-loading
input				x
knob			x	x
layout			x	x
linear-progress			x	x
expansion-item				x
list	x	x	x	x
slide-item		x		x
menu
option-group
pagination
parallax			x
popup-edit				x
pull-to-refresh			x	x
radio			x	x
rating				x
scroll-area				x
select				x
separator			x	x
slider			x	x
space
spinner			x
splitter			x	x
stepper			x	x
tab-panels				x
table		x	x	x
tabs			x	x
timeline			x	x
toggle			x	x
toolbar			x	x
tooltip
tree			x	x
uploader			x	x
video			x	x

4. Proposal a. Apply rem sizing units to component stylus files currently using hard coded px values. b. Convert all hard coded px values to Quasar stylus variables that are exposed to the user with default values set to current px values. This would allow users to override to rem units as they see fit.

5. Impacts Moving this into core is likely to have a negative impact on developers currently working with any type of CSS overrides, as scaling will be an issue that they haven't considered. Also, other app-extensions MIGHT have similar problems / so moving this into core at the current time is inadvisable.

Broad browser acceptance makes this a viable approach - except for IE11 because according to caniuse:

IE 9, 10 and 11 do not support rem
units when used in the "line-height"
property when used on :before and
:after pseudo elements
(https://connect.microsoft.com/IE/feedback/details/776744).

6. Approach Providing stylus files is well within the realm of possibilities of an app-extension, although it will likely be necessary to create a new type of AE-API interface for totally overriding stylus imports in order to reduce artifact size. (Note: Maybe I am wrong about this - will need feedback. Denjell)

7. POC In order to test the viability, the following approach is recommended:

   • Create an app extension
   • Choose a relatively simple component (like QAvatar or QBadge) to convert
   • Create the new stylus rule overrides
   • Build all potential artifacts
     • web, all browsers
     • electron, all OS's
     • cordova iOS and Android

8. Future Once we've validated the approach, all style resources should be converted appropriately in the context of an app-extension.

If, however, we are able to discover a non-breaking method where this could be integrated into core, such an approach would be more favourable.

9. Participants The Ruths.ai development team is willing to help contribute to whatever solution is deemed best for the framework.

---

Prepared by Denjell, Josh Davidson with the statistical analysis help of LucasFernog Ref: quasarframework/quasar#4246

[digiproductmarketer]

Fantastic to see this being looked into.

I needed more reponsiveness for a Quasar project I was doing, and with the help of some other Quasar users managed to get my fonts being reponsive where I needed them to be ... however that was a patch ... not a proper solution ...

Here's the forum thread ... https://forum.quasar-framework.org/topic/3483/fluid-typography-solved

BUT ... a comprehensive approach to the whole framework like this is exactly what is needed.

Looking forward to starting to see this get rolled out into the framework.

[codenamezjames]

We should look in to adding purgecss in to the build when we tackle theming. It strips out unused css and can be integrated with webpack. I think it would be a pretty big win for a small amount of effort.

[smakinson]

I have been wrestling with mixing in tachyons in the past and using a somewhat complete generator, but it never felt quite right. Now that https://tailwindcss.com is 1.0+ I am contemplating seeing how it mixed in, but it would for sure need to purge unused css as part of the quasar build. I think it uses PostCSS so I have yet to see how it plays with stylus in Quasar, but I am contemplating using it for all class names over the quasar class names because its error prone trying to be consistent to try and use only quasar grid class names sine they have the responsive breakpoints and them matching an external css lib to the breakpoints and using it for everything else. Often I find I need to do something like make the font size a bit larger or add a border, a shadow etc at some breakpoint and tachyons was very useful for that, but does not have the xs-xl breakpoints that Quasar has. Recently, as I start a 1.0 upgrade,I have started manually adding some of the tachyons names in my own .styl file by looping the $sizes info, but that also doesn't feel quite right, so this is why I am contemplating tailwindcss. So I guess I should bullet point what I think I would like to see.

• The scalable sizing as mentioned above
• The responsive breakpoints available on all class names with purging of unused class names for file size on build
• Customizable breakpoints
• Responsive class names that are clear at a glance. Currently when I see q-pa-md-md or q-pa-lg-md, etc. I have to stop and think about which md is the breakpoint and which is the amount of padding. I have yet to try tailwindcss, but it seems like their naming convention with prefixes might be more clear.

And then I suppose there is the question of does it make more sense to bring in something that already exists or to write it from scratch. Curious if this would be useful for integrating: https://tailwindcss.com/docs/functions-and-directives/#app

[hawkeye64]

https://engageinteractive.co.uk/blog/em-vs-rem-vs-px

[hawkeye64]

https://hackernoon.com/rems-and-ems-and-why-you-probably-dont-need-them-664b9ce1e09f

[digiproductmarketer]

One thing to remember in all this is that the User Experience is not just about scaling the objects displayed on screen.

You don't expect to show EXACTLY the same screen layout, just scaled according to size, .... to users of ... a 24inch desktop computer, a 10inch tablet in Landscape mode, a 10 inch tablet in Portrait mode, a 4.7inch mobile phone in portrait mode. You'd show them content appropriate to their device.

So, scalable, responsive UI also has to do with content layout as well as scalling the sizes of components displayed on screen.

[joshuadavidson]

@hawkeye64 Thanks for posting articles. If anything, they show that there are some strongly held opinions and that neither way (rem vs px) is correct. I think the current frustration with Quasar as it stands is two fold:

1. Internally it's inconsistent in the use of rem/em
2. There is no way for devs to override the defaults

Perhaps the best first step is to expose these values to the user so they can choose? Just assign stylus variables to them and allow for user overrides (this is already done for some values). In this way if a user wants to use rem over px (or vice versa) they can. This also opens the door to those who are looking to do some basic theming as stated above. Thoughts?

Eventually though I think Quasar should choose a consistent unit of measure so that the framework has good defaults out of the box.

As a case study see the following CSS Library implementations of global variables:

• Bootstrap 4
• Semantic UI
• Foundation - Uses a function to output rems throughout framework

All expose the kitchen sink as variables and also use rem/em as their base units.

[mesqueeb]

I just want to chip in that I'm making a sales app (on iPad) for elderly. I've set the base font-size to 20px, and thus since we build the entire UI with rather "big" elements, text etc. Quasar's "toggle" is the component we had the most trouble with. (It's just not possible to make this component larger in any way without re-writing it almost entirely...)

We ended up using CSS scale for now, but this makes the toggle look very blurry on iPad.

I'm not per-se an advocate of a specific method to make our Quasar components larger, but if it could be streamlined throughout the entire Quasar component library, I think it could greatly benefit the Quasar framework!

---

Edit: As for the proposal of the original post:

Proposal a. Apply rem sizing units to component stylus files currently using hard coded px values. b. Convert all hard coded px values to Quasar stylus variables that are exposed to the user with default values set to current px values. This would allow users to override to rem units as they see fit.

A.

In the case of a., isn't the only way to make the components larger to set the root font-size larger? In this case, is it possible to make an individual component larger?

B.

I would say b. but in a way that the developer can easily set all sizes of all components or just individual ones. Eg.

$component-size-md = 17px

$q-toggle-size-md = $component-size-md

then eg. the QToggle can use these generic sizes in its css like $q-toggle-size-md and the dev can either overwrite the md size of júst the QToggle or by changing $component-size-md he can make áll components larger.

However, the more I think about this, there are so many different ways to implement this, so it would really need to be thought through well.

---

Edit 2:

An idea for how these stylus variables could be documented:

Suggestion

[mesqueeb]

Just want to add, when I read this article (posted by @hawkeye64 before), I'm kind of convinced not to use em and rem in my websites anymore. XD

[gbouteiller]

as @smakinson mentioned https://tailwindcss.com and as it is becoming more and more popular, maybe it should be worth it to consider to use it and refactor the actual styles with it? Tailwindcss is a good piece of code, easy to customize and lightweight when you consider the use of purgecss with it. Other ideas that could be interesting to investigate more generally are renderless components (https://vuejsdevelopers.com/2019/02/11/renderless-component-libraries, https://adamwathan.me/renderless-components-in-vuejs ) and/or the new RFC about composition API (https://vue-composition-api-rfc.netlify.com/#api-introduction)

[kosirm]

I came from tailwind to quasar a month ago because I was looking for framework with components etc. and I wanted framework to be vue based. Bingo! Regarding units - I use them all, absolute, relative, depends what I want to do, with css grid I also use fractions extensively (nice article about fractions here). Speaking of css grid in quasar, I think that css grid deserves as much love as flex layout (maybe I missed something in documentation?) because it is (or can be) even better for responsive layouts than flex (both can be used together also). +1 for tailwind

[mesqueeb]

@kosirm I'd advice against CSS Grid in Quasar for at least another few months/years. Since CSS Grid is not supported on all browsers, and clients often request support for IE11 as well etc. But I digress.

Anyone else any opinion on @nothingismagick proposal?

Proposal a. Apply rem sizing units to component stylus files currently using hard coded px values. b. Convert all hard coded px values to Quasar stylus variables that are exposed to the user with default values set to current px values. This would allow users to override to rem units as they see fit.

A or B? Thoughts? C?

[disfated]

@rstoenescu Any news on this? It's a huge pain to override all px to rem. Can't see how using rems could hurt anyone who don't need them (yet?). How can I streamline this?

[Inventsable]

Would also love any updates on this. I'd love to use Quasar for projects in Adobe applications, which unfortunately are far smaller than a full browser window due to being a panel within another application. Since I can't wholesale scale the UI down, I have to manually go through and tweak every component so it isn't gigantic within an Adobe app.

[amexcompliance]

I see this post is closed, anyone knows what the closure is if any?