#css

I’ve been putting off upgrading from Jekyll 3.10. Partly late-adopter habit, partly because my setup worked fine, and a version bump seemed simple enough. I should know better by now. It mostly was.

I came across a catalogue of antiquated HTML snippets and artefacts, the kind of markup we just accepted as necessary in the <head> of every site. It got me thinking about the CSS side of that same period, the stylesheets rather than the markup. My first job in 2009 was building marketing campaign pages for an electronics distributor’s B2B storefront, where dropping IE6 was not a conversation anyone was going to have. Developers eventually landed on one clean way to target different IE versions, but getting there took a lot of less elegant detours.

In the old days of the web, animating between pages meant faking it with jQuery. Then came pjax, which used pushState to swap in fetched content and fake a full navigation without one, still relying on popState to stop the back button breaking. Every single-page app since has done some version of the same trick, intercept the link click, fetch the new content, swap it in, animate the swap yourself. It works, but it means every navigation runs through a JS router, even on a static blog that didn’t need one otherwise. Cross-document view transitions do the same job without any of that, and there’s no JavaScript API involved at all. It’s a single @view-transition rule in the CSS. No router, no fetch, no client-side history hijacking, the browser still does a real navigation to a real URL, it just captures the outgoing page as it leaves and lets CSS animate that against the incoming one.

I’ve spent more time over the last 20 years working on front-end asset pipelines than I’d care to admit. One thing that kept coming up when inheriting older codebases was CSS full of vendor prefixes that hadn’t been necessary for years - -webkit-border-radius sitting above border-radius, -moz-box-shadow doubling up on box-shadow.

I use Sass every day, both professionally and in my side projects. One thing that never seems to stick in my mind though is the correct way to use @for, @each or @while. I’m writing this up here for some cathartic release, and hopefully to be of use to somebody else.

Recently I was contacted to provide a short quote about why CSS preprocessors are awesome. This wasn’t a hard task as I spend a lot of time evangelising the use of preprocessors, specifically Sass.

There has been some talk lately about how iOS 8 has started to handle typography descenders when text is underlined. They’ve done away with the usual overlapping line intersect in favour of a more aesthetically pleasing line crop.

I read an article recently that explained why a web design agency had stopped using CSS pre-processing as part of their development process, as a means to “optimise [their] internal workflow”. CSS pre-processors aren’t for everyone, but what I found particularly grating about this article was the mis-information, and the bad reasoning for ceasing to use a CSS pre-processor such as Sass.

In their simplest form, web pages are made of stacked rectangles. Every block-level element takes up as much vertical space as the content requires, and fills as much horizontal space as is available. Additionally, block-level elements can have their width/height specified. When you have absolutely positioned, or floated elements this changes a bit but the rule pretty much sticks.

Sass is a CSS-compatible preprocessor for CSS. It allows you to reduce the amount of duplication and complexity in your CSS by using variables, mixins (functions), nesting, and other cool things that should have existed in the CSS spec from the beginning.

I read an article on the subject of implementing a PSD design of a website perfectly in HTML/CSS, and without wanting to spend my time writing a lengthy response in the comment form of a blog for it to disappear in to the depths of a blog that I don’t visit very regularly, I figured I’d write my thoughts up as a blog post.

If you’re a returning visitor to blomg you might notice some changes to the design.

Recently I came across an interesting problem, fluidly scaling iframe/embed code on a responsive design. The problem surfaced because I was using a fluid width and a fixed height for my video embed, and so at some screen sizes the video would look fine, and at others it would have some black banding at the edges.

This is just a short post about an unobtrusive CSS3 effect that I”ve used on some projects lately. Using the ::before and ::after CSS pseudo elements and some CSS3 styles you can make a simple HTML element look like a stack of paper sheets.

Making assumptions during web development is never a good idea – especially if your assumptions are about the way a new feature will behave across modern browsers. This is an issue because of two things:

In the process of rapid prototyping and trying out new CSS styles I often find myself making changes to styles within the inspector in Google Chrome. This works quite well, but I’ve always had a process like the following:

I decided it was time that I gave some attention to the design of my Jekyll-powered blog. I’ve been using a slightly modified version of the default Twitter Bootstrap theme since I moved to Jekyll, and that’s just not good enough. I’ve created the new theme from scratch, and I’ve thrown in some PJAX wizardry to make page-loading fancier. Gone are the old post-banners, and thumbnails (which to be honest I was adding just to make things look a bit less-boring), say hello to the new, larger hero banner for the latest post! You might notice some fancy effects on the homepage when you scroll, this is accomplished with a bit of jQuery and css3 to scale the title while parallaxing the hero banner. I’ve also made a forray in to a responsive layout, so if you’re viewing this on a screen smaller than 960px wide you will see some slight differences. But it’s not that different. Obviously the fancy stuff is dependant on your browser, but it should atleast look nice for anybody using Internet Explorer.

Styling form elements with CSS is never a fun task. Cross browser differences in how form elements are rendered, coupled with changes in font size and browser capabilities, makes predicting how a form will look, after you’ve applied a style to it, a hard job. When working on the design for moanlog (and the Wordpress theme for moanblog) the search bar was one of the areas that took the most deliberation. Unable to recover the image :( The search form as it looks in its finished style maintains the unified style of the soft salmon colours in the moanlog design.

So i was playing with some css ideas the other day, during a random spur of boredom (ok, well it wasn’t that random, infact i could have probably avoided it on account of i knew i would be bored.. but regardless..) i came up with some nice css tabs, using dave shea’s css sprite slicing technique, and douglas bowman’s sliding doors technique.