Group Toolbar Menu

Style Tips

  • Helpful tips

    Here are some tips and tricks of mine that I hope will make creating styles easier and more accessible to you!
    1. Use a code editor to write your code in.
      Think of Notepad++, Atom, and similar free programs. One reason is that when you save the file as .css, the program applies color to your code, which can help you recognize invalid code much more easily than if you were using plain old school Notepad. These programs also helpfully offer autocompletion on code and can show you a list of possible values for your styling.
      Another reason is that having a separate style.css file helps avoid accidentally overwriting your code on the RPR (something that happens to me frequently when I fumble and autopilot hit the save button, or I accidentally edit the wrong style when referencing the code!).
      .
    2. Make extensive use of available free resources.
      Paid stock image sites tend to have a much larger library and specific collections when you search for them, but I've also learned that you don't need an expensive monthly plan or pay for expensive credit packs to obtain beautiful images to use in your designs. Be sure to check out our free stock resources topic for this! I also recommend keeping an eye on paid stock image sites, they often have free downloads available when you register an account with them. :)
      .
    3. Use official RPR styles often.
      Official RPR styles go back almost 13 years now, and they have reliably survived numerous improvements to the code and even a complete redesign with RPR 2.0. They're also available to be edited whenever you want and saved as a new custom style.
      I highly recommend both using existing official styles to familiarize yourself with coding CSS, and to inspect and pull code from existing styles to troubleshoot or add elements to your styles that you struggle with.
      .
    4. Make extensive use of the browser inspector.
      Inspecting elements is something we can do to help us figure out the HTML and CSS a bit more easily. Typically, you can inspect an element by right-clicking on it and clicking "Inspect (Element)", but some browsers may have other variations, so I recommend consulting a guide if you're stuck.
      When an HTML element is selected, the inspector can help identify which code is being applied to the element. If you're not seeing your own code applied to an element, it means you're not using the right selectors (IDs, classes, etc.). You can also directly edit some code in the inspector to see what any changes to values might look like in real-time! Just remember to also add this to your actual style code.

  • Common mistakes

    While a style that works arguably works, there are some things people do that make styles less reliable across browsers and devices while having relatively easy fixes. When creating styles, try keeping these things in mind.

    Using only one font-family »

    When you finally find your perfect font, it's very tempting to slap that sucker into the code and be done with it! After all you designed your style to work with said font, so what else do you need?

    But what if the person is unable to load Google fonts? Or they don't have that font on their device they browse the style with? It's a lot more common than we think, and the devices still simply grab whatever font is available and your style may look disastrous! We add extra font-families to our code to prevent this from happening. The first font you put in there will be the preferred one. If the device can't find it, it will search for the second one. And if none are found? You can tell it to grab any from a particular family! If you use commonly present fonts as backups, you can curate a cascading list of fonts that match your style better than the wild random guesses the device will make.

    So instead of using this:
    Code:
    body { font-family: 'Dosis'; }

    Try using this:
    Code:
    body { font-family: 'Dosis', 'Georgia', sans-serif; }

    While there's no guarantee as to which font may be available on any given device, there are some fonts considered 'Web Safe Fonts' - fonts that occur so commonly that odds are high the vast majority of visitors can see them. There are no 100% Web Safe Fonts, so you also want to include at least one 'Fallback Font' in your font-family list to catch any stragglers here.

    Using uncompressed image files »

    There are SO many gorgeous images out there, many times totally for free and at beautiful large sizes, that we can't resist putting them into our templates. Many of us enjoy a good internet connection and high internet speeds, and so it doesn't matter to us if the image is large in filesize or not. It loads in just a second and after that it's cached in our browsers anyway, making loading the assets instant.

    The problem arises when someone is trying to view our profiles on a poor internet connection, whether they live in an isolated area or they don't have the financial means to afford stable internet for whatever reason. As part of the Accessibility guidelines, ensuring people without the socio-economic means for a high speed internet connection still get to make use of our profiles is important.

    On the other hand... you don't want images to be compressed to poor quality, either. So what can we do about this?

    Fortunately, in 2022 we have really good image compression tools that reduce file size without visually disrupting image quality! This tool is used for many assets found on the RPR as well, and it's completely free. Simply upload your images here, wait a few moments, and then download the optimized version to use in your styles:

    Ideally, your assets clock in at well under 500kb in file size total (yes, you read that right, total!). However, even just reducing a 2MB file to 600kb will be a dramatic improvement to your style's accessibility, so if you can't quite manage such a tight range, that's alright. :) In this case compressing every asset is always better than not doing so at all.

    Overusing flashy images or effects »

    One of my favorite things about creating styles is how we get to be creative and use code that does really cool tricks, like animated glowing, emulating flickering lights, and so much more. We don't need to stop using these effects, but I do believe it's important we use them sparingly and prioritize user comfort.

    Ideally, flashy animations are minimized -- use them as accent features and try to avoid any that fit this criteria:
    Quote:
    Generally, flashing lights most likely to trigger seizures are between the frequency of 5 to 30 flashes per second (Hertz)

    If you release styles for public use, also consider releasing a version that is flash/animation free. Opt for static glows or images where possible.