There are several ways to add custom styling to the classic editor, including:

• loading a custom stylesheet, using add_editor_style('custom-editor-style.css'),
• loading a custom stylesheet, using add_filter('mce_css'), and
• loading dynamic styles, using add_filter('tiny_mce_before_init') and appending style properties to $settings['content_style'].

In this post, we’ll focus on the latter, which we can use to get the Customizer’s CSS.

Loading Customizer CSS into the Classic Editor

The Customizer’s theme CSS is stored in the post table, with post type custom_css. To get this we’ll use get_posts(), then we’ll append the post_content to $mce_settings['content_style'] (after sanitising it). Here’s the WordPress filter, note that I’ve used an anonymous function, but you don’t have to:

add_filter('tiny_mce_before_init', function ($mce_init) {
    $customizer_posts = get_posts('post_type=custom_css&numberposts=1');
    $styles = $customizer_posts[0]->post_content ?? '';
    
    // return early if no stlying was found
    if (!$styles) return $mce_init;
    
    // sanitise ready for use
    $styles = sanitize_text_field($styles);
    
    // add styling
    if (isset($mce_init['content_style'])) {
        $mce_init['content_style'] .= " $styles ";
    } else {
        $mce_init['content_style'] = " $styles ";
    }
    
    // return updated settings
    return $mce_init;
});

And that’s how to add customizer CSS into the classic editor.

If you’re struggling with this or any other WordPress challenge, don’t hesitate to get in touch for further support.

Once upon a time, a challenge like this, where you want to reveal a footer when the end of the content is reached, would have needed position: fixed|absolute and a bit of JavaScript to calculate the dynamic height of the footer, for responsiveness.

Thankfully, we now have a much simpler solution, using sticky positioning. With position: sticky we don’t need to worry too much about the height of the footer, we can simply set a sensible minimum viewport size that we’re confident the footer will fit in and voila, a footer that reveals from underneath the content above it.

Code example to reveal a footer

@media (min-width: 1200px) and (min-height: 600px) {
    .any-preceding-siblings {
        z-index: 2;
    }
    
    footer {
        position: sticky;
        bottom: 0;
        z-index: 1;
    }
}

Sticky positioning, like many styling customisations, is easy when you know what can be achieved with CSS3 and CSS4. If you’re looking for help with custom styling or would like help designing your web pages, please reach out and we’ll gladly help.

Check out our other CSS tips: CSS

This post describes how to create a horizontal grid with 2 rows and infinite columns using CSS grid. This technique uses display: grid, which finally has decent browser coverage.

Like CSS flex(box), CSS grid is incredibly flexible for creating relatively complex layouts and making seemingly simple ones, well simple (which wasn’t always the case, like centring content both vertically and horizontally).

Making a grid that scrolls horizontally using CSS grid & grid-auto-flow

Scrolling up and down is the default way to consume web page content. In order to scroll vertically to consume the content, we can need to tell the browser it’s okay to overflow on the x-axis and we need to tell the content it doesn’t need to wrap to the viewport.

There are a few ways to do this, but this post will demonstrate the grid way:

.grid.scroll-x {
    display: grid;
    grid-auto-flow: column;
    /* should, in theory, work without overflow-x */
    overflow-x: scroll;
}

As can be seen in the code above, the grid-auto-flow property is the key here. Used in conjunction with display: flexand set to column will tell the browser to render the element’s children as columns, which is what we want!

In order to reach the solution, this post set out to achieve all that’s needed now is to spread this grid element’s children over 2 rows. Fortunately, using grid this is really easy.

Making a horizontal grid with 2 rows

The code above will render the horizontal elements, as required. If we introduce another property to this code snippet, grid-template-rows, as per the following code, the element’s children will now be not only horizontally scrollable but they will also be rendered over 2 rows:

.grid.scroll-x--rows-2 {
    display: grid;
    /* auto auto is telling the browser to render two rows, if needed */
    grid-template-rows: auto auto;
    grid-auto-flow: column;
    overflow-x: scroll;
}

This is perfect, just what was needed, and it was achieved with just 3 lines of CSS grid properties (plus overflow-x: scroll you feel the need to include it). However, there’s one small caveat;  the layout’s rendered in a reversed ‘N’ order, with each column output, then the rows for that column. This outputs the first 2 elements in rows, then adds subsequent elements as columns to the right (as modelled below). This means that if the layout was designed for 2 columns there would need to be at least 3 items to render a second column, but this can be handled with the logic to make sure there are at least 3 items before applying the grid-template-rows property.

Conclusion

The display: grid CSS property is incredibly flexible and I think this scenario demonstrates a great use-case. Yes, this could have been done in other ways, for example, I used negative margins to create this horizontal masonry layout of cards, but the CSS grid approach feels cleaner and more robust.

If you’d like to implement something like this in your project, please get in touch as we’re passionate about making the web look great.

Have you needed to apply styling to only touch devices, or only non-touch devices? Well, great news CSS4’s @media (hover: [value]) can come to the rescue in a multitude of ways.

What is CSS4?

For some time we’ve been working with CSS3, which I think is pretty epic, especially when compared to what came before. And CSS4 goes much further, offering super useful functionality to enhance how we interact with webpages. But, for now, we’re only focusing on the media query above, that, for me, is a breath of fresh air, as it vastly simplifies scenarios where I only want to target devices that have specific ways of interacting with the. e.g a touch-only device.

Use-cases for the hover media query

Here are two use-cases to whet the appetite, hopefully, they’ll show the power and flexibility of this awesome new media query?!

Use Case 1: increase spacing between tap targets on touch devices

I’ve had this one a few times, where the links are considered too close, thus reporting accessibility issues. The solution is to give each link (tap target) more spacing on touch devices. In this use case, I’m also using the media query pointer to detect the type of pointer (none|coarse|fine) – a perfect use-case for the hover media query:

@media (hover: none) and (pointer: coarse) {
  .nav-link {
    margin: $nav-link-margin--touch-only;
  }
}

Use Case 2: hover effects for devices with hover capability

I was recently building a website where the creative direction required a simple animation that zoomed in on images when hovered over. This featured is intended only for devices that support hover (i.e. mouseover, etc). Here’s a code snippet that increases the scale of the image element when its parent is in a hovered state :

@media (hover: hover) {
  .image-wrap {
    overflow: hidden;

    > img {
      transform: scale(1);
      transition: 0.25s ease-in transform;
    }

    &:hover > img {
      transform: scale(1.15);
      transition: 2.5s ease-out transform;
    }
  }
}

As I’ve shown in the two use cases, this is a pretty useful media query and one I will be making a lot of use of. I’m also sure it can be used in conjunction with nest media queries? There is, however, one caveat; there is no support for Internet Explorer and Opera Mobile. But I no longer support IE, unless the client explicitly needs it and frankly cannot support the insanely restrictive Opera Mobile browser (unless the client needs it).

So, there it is, the awesome hover media query in CSS4. Enjoy using it!

Do you have uses for hover media query?

If you’ve got another use-case for this query, or you’d like help implementing it on your sites’ then please get in touch as we’d love to help make use of this great CSS feature.

I’m a sucker for performance gains to the point that I’m convinced I’m actually losing time overthinking it –

A good example is CSS delivery and it’s always interesting to get others’ opinions on how important they consider styling performance to be and how they measure it.

Inlining – good/bad/ugly?

Good

I see genuine reasons to inline certain styling rules, for use cases such as;

• a one-off element style
• a style that requires browser/JS intervention
• overriding nasty !important rules

Good use case: inline background-image

<div class="card" style="background-image: url({{ $just_in_time_image_url }})">[...]</div>

Aside: This isn’t the best example, as background images should really be responsive;

<style>
  .card {
    background-image: url({{ $just_in_time_image_url }});
  }
  @media (min-width: {{ $breakpoint_width }}) {
    .card {
      background-image: url({{ $just_in_time_image_url }});
    }
  }
</style>

Beyond these, I’m all for steering away from it.

Bad

IMO, whenever the above doesn’t apply the rule should be contained in a stylesheet. I see the following used inline, which I would absolutely put in a stylesheet;

• repeated inline styling spitting out the same rules – “Always try to be DRY“
• brand-specific rules – argh!

Bad use case: inline brand colours

<div class="card" style="color: #2457ba; background-color: #a0d8c6">[...]</div>

Better still, use a preprocessor, such as SASS, to reduce maintenance overheads.

Ugly

WP plugins. I am amazed at the number of plugins that make excessive use of inlining. My best guesses as to why they do this are;

• inline rules, well…rule – their cascading rank is high (and used in conjunction with !important they are simply brute force bullies)
• the plugin’s styling will not be in the cascading rules of non-plugin elements
• to annoy me

Ugly use case: inline rule with !important

<div class="card" style="opacity: 0.5 !important">[...]</div>

Closing words

I love building websites and get a lot of satisfaction out of my clients’ sites working hard for them – both in terms of optimising for search engines and for great user experiences.

A note on SEO: I’m not a fan of “SEO Experts”, as they are more-often-than-not focusing on one very specific area of SEO; content. Don’t get me wrong, “Content is king!”, but it’s only part of the puzzle. A good website should;

• load fast, with optimised assets
• look great on mobiles, tablets and desktops, alike
• be easy to use and navigate*

*in hipster terms; provide a good UX design – aka User Experience

When a site is fast, easy to use and has great content (the things actual users are interested in) SEO rankings will naturally improve, as these are the core metric that search engines are concerned with.

Note on low-budget websites: I’m not a fan of the crap out there that’s lowering the standards and the vast number of budget websites that smaller client’s get lumbered with. This is a false economy, as a good website will work hard and, assuming it’s built to perform, it will more than pay for itself.

If you’re looking for a better website, feel free to call for a free consultation with one of the team.

Free Consultation

Recently, I had an odd scenario where wrapping long text needed either word-wrap, overflow-wrap or word-break to achieve the same overflow pattern across different browsers. To arrive at a suitable solution I opted to use @supports to maintain control of the declarations.

What is @supports?

@supports is a feature query, whose associated block of statments only get triggered when the client (i.e. browser) supports the feature(s), as described on MDN. Here’s a simple example:

/*
 * Test if client supports display: grid 
 */
@supports (display: grid) {
  display: grid;
  float: none;
}

The example above is pretty self explanatory:
Process the enclosed block of declarations if the control declaration is know by the client.

The Problem – text that is too long for the width of its containing box

This is a common webpage layout hurdle, and one that completely breaks the page if not handled with due consideration. Take for example a scenario I’ve seen time and again: horizontal scroll on a mobile device, where the content overflowing to the right of the viewport is completly unstyled, as depicted below (NB: the site in the demo isn’t broken – we’re just demostrating the issue):

Toggle Demo

Using @supports to handle long words

This is an ugly problem. And one that’s often addressed with a combination of hyphens(inc. prefixes) and word-break. Unfortunately, there are times when they don’t cut it. For example, when a hypen isn’t a desirable aethestic, or not all words want breaking.

What I was looking for was a way to break long words, but not hypenate them, and defintely don’t break words that can just fit on the next line. So, through trial and error, I found the following to work perfectly for our use-case, which only passes the relevant declarations to browsers that support them:

/*
 * Break long words
 * Only break words that are too long to fit on one line
 * Uses @supports
 */
h1, h2, h3, h4, article {
  /* doesn't recognise underscored_words on all browsers */
  word-wrap: break-word; 
}
@supports (overflow-wrap: break-word) and (not (word-break: break-word)) {
  /* doesn't recognise underscored_words on all browsers, use if word-break: break-word isn't supported */
  h1, h2, h3, h4, article {
      overflow-wrap: break-word;
  }
}
@supports (word-break: break-word) {
  /* use if supported */
  h1, h2, h3, h4, article {
      word-break: break-word;
  }
}

Conclusion

Using @supports is an elegant way to make us of the tools that fit each of the browsers we need to code for. Sometimes, more-often-than-not, we don’t need to use it. In the case above I could have just let the browser’s decide if they could or couldn’t understand the declarations, but the way I’ve structured it gives me confidence that I’ll get the desired outcomes from the declarations I’ve tested. Plus it gave me a reason to talk about @supports.

What’s a @media query?

Here’s a simple example of a media query to make the text 10% bigger on devices with a screen (viewport) wider than 768px (the viewport width of the original iPad):

@media (min-width: 768px) {
  p, div {
    font-size: 1.1em;
  }
}

This is a pretty self-explanatory snippet of code:

When the width is greater than 768 pixels relatively resize the font size of paragraph and div tags to 110% of their current size.

Cool, right? But what about if we also wanted to increase the font-size of div tags by a different amount when the height is greater than 1024px? One solution is to use nested media queries.

What are nested @media queries?

Taking the problem described above, here’s an example of nested media queries to make the text within the paragraph and div tags 10% bigger on devices wider than 768px, but with a nested condition to apply an additional rule to div tags when the viewport height is also at least 1024px:

@media (min-width: 768px) {
  p, div {
    font-size: 1.1em;
  }

  @media (min-height: 1024px) {
    div {
      font-size: 1.15em;
    }
  }
}

How about that?! The query is still pretty self-explanatory:

When the width is greater than 768 pixels relatively resize the font size of paragraph and div tags to 110% of the current size. However, if the height is greater than 1024 pixels relatively resize the font size of div tags to 115% of the current size.

Note: there are other ways to achieve this, without nesting the media queries, most obviously is by having separate query groups for paragraph and div tags.