fluid typography - SOLVED



  • This is similar as @qyloxe code, just extended to other properties, so it can be used for padding, margin, etc.

    fluid-type($properties, $min-vw, $max-vw, $min-value, $max-value)
      for $property in $properties
        {$property} $min-value
      
      @media screen and (min-width: $min-vw)
        for $property in $properties
          {$property} "calc(%s + %s * ((100vw - %s) / %s)) !important" % ($min-value (remove-unit($max-value - $min-value)) $min-vw (remove-unit($max-vw - $min-vw)))
    
      @media screen and (min-width: $max-vw)
        for $property in $properties
          {$property} $max-value
    
    // Single property example
    :root
      fluid-type(font-size, 320px, 1920px, 16px, 24px)
    
    // Multiple property example
    h1
      fluid-type(padding-left padding-right, 320px, 1920px, 10px, 30px)
    

    Works for me… Props to Fredrik Beckius! There are also more sophisticated versions, for example to make different scales for different breakpoints



  • Since finding this post I’ve been fiddling round with dynamic fonts specifically on form fields.
    So sharing a bit what I have set up so far.

    First though for some reason if rfs-base-font-size is not explicitly set (even if to default) then the fonts don’t resize. Note I use a “factor” so I know it’s bigger which according to docs should enable the resizing.

    Secondly like @kosirm noted although useful it doesn’t adjust the related class properties (height, padding etc). That’s ok I suppose but the smaller font on smaller devices could have a smaller field box height saving precious vertical space and not look so wonky. Too classes like q-field__label need more bottom padding at smaller font size in order to keep the field content from running into the label.

    Too looks like instead of using padding the field box height is controlled by the height parameter of .q-field__control. So would have to be able to grab the computed font size in order to scale that number I suppose.

    Bottom line is that quasar at this point is agnostic to the dynamic font size. So if the framework wants to support dynamic font size then just need easy ways to scale all the related classes/properties when the font size changes. One idea would be that the framework has variables for font-size of various components/elements (e.g. q-field). Then you set that dynamically or manually (with defaults) instead of messing with classes directly. Guess those variables can be part of the component rather than in the core. Then all related can be changed accordingly. Nothing in the core variables like that except $input-font-size which gets ignored when wrapped in a field.

    @import "../../node_modules/rfs/stylus"
    
    // rfs settable variables - commented are defaults
    $rfs-base-font-size = 1.25rem
    // $rfs-font-size-unit = rem
    $rfs-breakpoint = 1400px
    // $rfs-breakpoint-unit = px
    // $rfs-factor = 10
    // $rfs-rem-value = 16
    $rfs-two-dimensional = true
    // $rfs-class = false
    
    $field-font-factor = 1.3
    $field-label-font-factor = 1
    
    .q-field__native
    .q-item__label
      rfs($rfs-base-font-size * $field-font-factor)
    
    .q-field__label
       &.no-pointer-events
         rfs($rfs-base-font-size * $field-font-factor)
    
    .q-field__label
       rfs($rfs-base-font-size * $field-label-font-factor)
       padding-bottom .3em // needs to be dynamic based on font size
    
    .q-field__control
       // height ??px // needs to be computed based on font size.  
    


  • Thanks for your elaborative interrogation @dgk. It’s true what you said, I noticed that I need quite a lot of tweaking to get visual style that I want with Quasar. Hopefully Quasar theming will get some love from dev team … for now “theme builder” (https://quasar.dev/style/theme-builder) is pretty basic… But overall quality and flexibility of whole framework is a few light years ahead of the competition, so I’m not complaining 🙂



  • The Typography in Quasar is an issue. It is a problem that it is hardcoded so it can’t be changed. What compounds the issue is it was hardcoded with no modern standards. No fluid formula, no REM, no Percentage. The typography limiting harms internationalization, Viewport issues with small devices etc. To load a presentable mobile page you are forced to use h4 which severely harms SEO.

    I was going to dance around to be politically correct but this single issue has forced me reassess Quasars ability to Serve my front end. I am so disenchanted I feel like I am forced to look at other front ends… Specifically Vuetify. I don’t know why there is reluctance but this issue has and will continue to drive prospective development companies away from the product. The ramifications of this single development decision will continue to grow exponentially.

    Other than this single issue developing in Quasar has been top notch.



  • @Chinook-Digital - What do you mean by hardcoded? There are a number of css variables for the typography.

    Scott



  • @s-molinari I am going to eat some crow here but that is fine. I was trying to make some css modifications to the typography and they didn’t take. I read the accompanying documents on typography and read a post inferring the Typography was coming in via a cdn … and Now I can see that I am wrong. So I will eat some crow … well a bat 🦇



  • Quasar is getting more and more traction, which is awesome. The main reason is that one has a lot of things pre-build to quickly release web, ios, and android apps. Fonts is not part of the pre-build features. One has to spend hours with testing, failing and testing again. So one ends removing a lot of custom rules and just switch to h4 instead of h1s, h5 instead of h2, which is a patch, not a real solution.

    One is used to just drop bootstrap in a project and forget about fonts, typography, spaces, margins and paddings.

    I understand “one can always replace the variabes/overwrite font-sizes”, but for an MVP or a prototype, one is more focused in the functionality and business logic, and want to push the optimizations/personalizations at end. On the other hand, the stake holders don’t pay any attention to the MVP or prototype, because the blog post title H1 uses more than half the screen.

    This is not a small issue, nor is it “SOLVED”



  • @str - I’m not certain what your problem is. You can set up the heading sizes and font weights as you please. Set them up once and use the same scss or sass or styl file for any other project with Quasar.

    Scott



  • @qyloxe , I am new to Quasar but love B4/B5. I’m trying to follow your instructions to make font size responsive but I’m not having any luck. Is the following still the right way to enable this behavior? I’ve done this but the behavior isn’t changing. I’ve tried adding https://github.com/twbs/bootstrap/blob/main/scss/vendor/_rfs.scss to my app.scss file as well but…nothing.

    npm install rfs --install

    and in their app.styl code:

    @import "../../node_modules/rfs/scss";



  • @Synaptrix didn’t check that lately, maybe someone with current experience will answer.

    Definitely those are two questions:

    1. are those css classes loaded/bundled properly?
    2. are they taking any effect on Quasar elements?

    no 1 could be verified by checking the generated code
    no 2 could be checked by using developer tools.

    There’s always option with !important, but let’s not go this way as of now.



  • @qyloxe It doesn’t look like the styles are being applied, but I could be misreading this: https://www.screencast.com/t/DEI1zvTdl It does look like the css is being loaded, but again, I could be misreading this: https://www.screencast.com/t/lA9Ye8ZiEL


Log in to reply