Tag: css

WordPress PSA: disable “Glue for Yoast SEO & AMP” plugin

If you have a site using the AMP plugin in “Reader” (formerly “Classic”) mode – which is to say it uses some simple templates for rendering AMP pages – you should remove Glue for Yoast SEO & AMP:

– it is no longer necessary
– the code in glue-for-yoast-seo-amp/classes/frontend.php adds a duplicate inline CSS selector for

header.amp-wp-header

and

.amp-site-title a

. This means the default colour scheme will override colours you set in Appearance > AMP.

Disabling the plugin fixes this.

(Tested with AMP 1.5.5, WordPress 5.4.2)

Utility first CSS – observations / lessons learnt

I’ve been trying Tailwind CSS recently.  I’ll likely to continue using it.

People talk about Component First vs Utility First CSS frameworks – in my opinion the important word here is “first” – you should use your own best  judgement to combine the two techniques.

  • Start prototyping the design using atomic styles.
  • Observe where you’re reusing the same styles a lot and/or it’ll be a pain (e.g. paragraphs of body text)
  • Build components for these using @apply in your CSS file (between @tailwind components; and @tailwind utilities;)
  • Don’t bother build components for things you are unlikely to reuse.

Does the HTML source code look a horrible with all those styles? 

A bit when you very first see it.  But:

  • most code you didn’t write yourself looks confusing initially
  • maybe your CSS file looks confusing close up too

There are several ways Utility First can save time:

  • You’ll be switching back and forth between HTML and CSS rather less
  • There won’t be as much friction in the early stages of building the site (you’ll be plugging in atomic classes and seeing the results straight away, you won’t be worrying about how to name things or constructing BEM selectors) – however you should keep an eye out for when you need to build a component.
  • Obviously for a while you’ll be referring to the framework’s documentation a lot to learn the class names, but in the case of Tailwind CSS there’s an autocomplete search field on the site.  The abbreviations for margin, padding, flexbox etc., once learnt, are logical and easy to remember.
  • I find specifying code for screen breakpoints a lot simpler (typically I end up with lots of nesting in conventional CSS/SASS).
  • No maths needed when building grids etc.

Can you still customise everything?

Yes. Your tailwind.js config defines everything – colours, breakpoints, font  sizes, font families, leading, the grid etc. etc.

Who’s it good for:

  • Developers who aren’t working in CSS every single day and can’t remember the intricacies of flexbox or grids.
  • Anyone who doesn’t want their site to look like every other Bootstrap site (or any other framework that comes with pre-built components)

Can you still use it with SASS?

Yes (my typical build process for static sites uses Gulp and PostCSS)

Performance issues

There are two aspects to this, the CSS file size/download speed, and the speed the browser can process the quantity of selectors in it.

By default Tailwind will generate a very large CSS file with several thousand selectors.  But with a little optimisation (turning off unused colours and screen sizes) you can dramatically reduce this.   Also, the size is modest if served minified and gzipped.

Further reading:

Tip: Firefox address bar, avoiding phishing scams

Paul Moore tweeted this demonstration of a rather devious phishing scam earlier, where someone has taken advantage of the fact a capital I can look virtually identical to a lower-case L in sans-serif fonts* (and therefore a hacker can register a domain with the incorrect spelling and provide a link that tricks people.). Letters can also be paired: an adjacent r and n make a convincing m if you’re not looking closely.

There is some protection in browsers against this nowadays: as soon as you press return (though not as you type or paste the URL in) the entire address is converted to lower case. In Firefox, the domain is highlighted in black while the rest – including, crucially, any subdomains that precede it – is greyed out, providing a further hint to the site’s real identity.

It’s common for phishing scams to use multiple subdomains to make you think you’re on the genuine site – e.g https://www.mytrustworthybank.com.somewhere.suspicio.us/login

You can go a step further.  The Firefox address bar can be customised via the userChrome.css CSS file –on a Mac you need to go to ~/Library/Application Support/Firefox/Profiles/[your profile]/chrome and create a copy based on userChrome-example.css

Add the following and restart:

#urlbar {
    font-size: 21px !important;
    font-family: serif !important;
}

This will make the font bigger and use the default serif font rather than a sans-serif one.  I and L are easy to distinguish and, for web developers, having a larger typeface probably helps, regardless of how good your eyesight is – we look at URLs more often than most people, after all. It ought to reduce the number of typos you make.

Firefox address bar

There are Add-ons that do similar things if you don’t want to write your own CSS.

GDS, the Government Digital Service, use a specially designed sans-serif font called New Transport based on Kinneir and Calvert’s work on British road signs.  Note the legibility clues, especially the curve at the bottom of the lower-case L.

Over time we’ve recognised text inputs are better when they’re bigger and made it easier for users to change the zoom level, but the address bar has remained resolutely small and in a font that’s not as legible as it might be. Perhaps we should fix that.

* It can happen the other way round too (in this case it was Sky’s fault for forcing a screenshot into the wrong aspect ratio, making a lower-case L slightly fatter and easily mistaken for a lower-case I, particular after it’s been bounced sent through the vision mixer and the presenter has to read it off a screen several metres away.)