Join GitHub today
[v1][RFC] Scalable UI #4274
RFC Scalable UI
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.
Prepared by Denjell, Josh Davidson with the statistical analysis help of LucasFernog
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 ...
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.
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
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
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.
@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:
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:
All expose the kitchen sink as variables and also use rem/em as their base units.
I just want to chip in that I'm making a sales app (on iPad) for elderly.
We ended up using CSS
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!
In the case of
I would say
$component-size-md = 17px $q-toggle-size-md = $component-size-md
then eg. the QToggle can use these generic sizes in its css like
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.
An idea for how these stylus variables could be documented:
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)
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
@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.
Anyone else any opinion on @nothingismagick proposal?
A or B? Thoughts? C?