Hi.

Sliders (or carousels) are a fairly common practical requirement in web projects. Here, Chris Coyier shows us how far we can get in 2019 with HTML and CSS alone.

Here’s a nice CSS-only hover technique from Trys Mudford incorporating scale transforms, opacity transitions and mouse pointer events.

I have, I’m afraid to say, for many years been setting buttons to cursor: pointer because it “felt right” and a better user experience.

I shouldn’t have.

I was going against the W3C’s spec that cursor: pointer is reserved for links and was adding to the antipattern that “everything is a link”.

I’ll leave buttons as they are from here on in.

I realised last night while watching a presentation by Lea Verou that I could streamline my CSS Grid layouts.

I’d been creating an overall page grid by setting body { display: grid; } and some grid areas, but noticed that this only got me so far when it came to aligning more deeply nested elements of the page to that grid.

For example in the case of the main header, if I wanted its child logo, nav and search box elements to snap to the grid I found myself having to set display: grid and grid-template-areas again on the header.

It didn’t feel very DRY but my understanding was that while we await subgrid, this was a necessary evil.

What I should have been using is display: contents.

If you set this on your header then the body’s grid layout will apply to the header’s contents (logo, nav, etc) rather than the header itself. No need to redefine the grid on the header.

Here’s a codepen to illustrate.

I was aware of the existence of display: contents but somehow it hadn’t sunk in because I’d only read about it in the abstract.

Lea Verou’s explanation made all the difference. Cheers, Lea!

Fair play, Jeff – once this interview gets going it’s pretty damn good.

• The technique of "Subtraction";
• the last quarter of records being the best;
• the bar for electronic music being set too low;
• the complexity of the art form; and
• thinking about other things while DJing in front of 2000 people…

Plenty of good bits to chew over!

As mentioned before, recently I’ve been working on my SVG skills.

A while back I read a great SVG icon tip from Andy Bell which I’d been meaning to try and finally did so today.

Andy recommended setting the width and height of icons to 1em then using font-size to further tweak them.

Here’s a pen I created this morning to test-drive the technique.

See the Pen Control SVG icon size with font-size and match colour to parent text by Laurence Hughes (@fuzzylogicx) on CodePen.

And here’s some key points I’ve noted:

• By applying width and height of 1em to our icon it is predictably sized by default.
• It can now have its size further tweaked in CSS using font-size, for example with ems (where 1em = the font-size of the parent anchor element).
• This technique requires the “viewbox” attribute being present on the svg.
• Apply the width and height =1em as inline attributes on the svg. We could apply them using CSS, however the inline approach avoids potentially massive icons showing in cases where CSS doesn’t load.
• To get the colour matching, apply fill="currentColor" as an inline attribute on the svg’s path.
• Now, when you apply a hover colour to the anchor in CSS, the icon will just pick that up. Nice!
• Applying inline-flex to the anchor makes the vertical-alignment of text and icon easier.
• Add aria-hidden on the icon because it’s mainly decorative so we don’t want it read out by screen readers.

I learned something new today when developing in the Firefox Dev Tools console (although this applies to Chrome too) – something which was really useful and which I thought I’d share.

Basically, type $$('selector') into the console (replacing selector as desired) and it’ll give you back all matching items on the page.

So for example, $$('script') or `$$('li').

Similarly you can select a single element by instead using just one dollar ($).

These basically seem to be console shortcuts for document.querySelector() (in the case of $) and document.querySelectorAll() (in the case of $$).

The other really cool thing is that the resultant nodeList is returned as an array, so you could do e.g. $$('li').forEach(…) or similar.

I owe this new discovery to the very talented Remy Sharp (@rem) who dropped this science routinely during a live-stream where he refactored his blog from jQuery to vanilla JavaScript.

Cheers, Remy!

Here’s Bridget Stewart, a developer from Ohio, with some thoroughly enjoyable “curmudgeonly” thoughts on why your website doesn’t necessarily need a Javascript framework.

With websites taking a median time of 5.8 seconds to show primary content (source: HTTPArchive) and Google warning us that 53% of mobile visits leave pages that take longer than three seconds to load, it’s hard to justify stuffing the front-end unnecessarily.

Bridget’s article also contains this quote which I love:

First, solve the problem. Then, write the code.

Essentially, don’t select the tooling first – a principle I fully endorse.

Great article by Jake Archibald (developer advocate at Google Chrome) comparing ten F1 team websites in terms of performance. While checking for common issues he provides great insights into the tools and techniques he uses to test web performance.

Some points of note:

• He uses WebPageTest to gather the data on Chrome Canary on a mobile phone (Moto G4, a mid-to-lower end Android device) with a 3g connection;
• He doesn’t score on the amount of bandwidth used but on time to become interactive, i.e. meaningful content displayed in a stable way and reactive to a tap/click;
• “Caching is important”, so he takes the first load and second load score and adds them;
• He checks if any savings can be made via good-enough-for-mobile images resized to max. 1000px wide, for display at no larger than 500px (so it looks good on high density mobile devices);

A great resource from Dave Rupert, whose work on accessible components I’ve been meaning to write about since I saw his talk “The Four Devine Beasts of Accessibility” at An Event Apart last August.

It came to mind as I prepare to code a navigation menu with dropdown submenus in the most accessible way I can for a client project.

Dave has also written about the ideas behind creating these cards, and provided a few working demos.