Category: Web dev

jQuery – check if an element contains element

Forgive the jQuery! I’m just putting it here so I can find it again later 🙂

I’ve recently just had to create a menu in Foundation, in a CMS where I can’t change the menu markup (it just outputs lis and uls). So have had to use JavaScript to add the classes that Foundation needs to turn this into the slidey mobile menu. It feels like a horrible hack I know, but there’s no better way – and the Foundation menu needs JavaScript to display anyway.

So I needed to add the .has-dropdown class to any li containing a ul, which I did with jQuery’s .has() function:

//-- Add Foundation dropdown classes to subnav (so mobile nav works)
$("#main-nav li").has("ul").addClass("has-dropdown");
$("#main-nav li ul").addClass("dropdown");

The internet, a living graveyard

I stumbled across the blog today of Alex King, who wrote an article titled “We’ve made web development complicated” (see it here), which is something I’ve been thinking about recently (I also wrote a blog article about it called “Editing websites has never been more time-consuming” (see that here).

The most interesting thing about Alex’s blog though is that, well, he’s dead. Continue reading The internet, a living graveyard

6 reasons why I still prefer Bootstrap to Foundation

bootstrap vs Foundation

The versions I’m comparing are Bootstrap 3, and Foundation 5. Although I’m aware Foundation 6 has recently been released, which makes up for some of the shortcomings in this article – which is better late than never! But I’m still locked into Foundation 5 for many projects.

Bootstrap 3 has sliding animations out of the box

Both Foundation and Bootstrap have accordion components that expand and collapse. But only Bootstrap’s animate nicely out of the box. You can probably change this in Foundation but it’d involve rewriting the component – which is annoying when I’d rather have it working the best way possible right out of the box (that’s why we use frameworks right?!).

Same problem with the navbar. Bootstrap’s mobile nav slides down nicely, allowing you to see where it appears from. Foundation’s just appears and overlays the content, which is sometimes surprising.

I’m glad to see the new Foundation 6 does have an animated slidey accordion and navbar.

Foundation’s config variables

Foundation is very customisable, which is great! And in some ways it’s better than Bootstrap because you can change the look and feel of a component without having to override it’s basic styles.

The way it does this is by using config variables, and plenty of them! Each component has at least 10 variables, about sizing, fonts, colours, background colours etc, which when you compile all your SASS will style the component as you need. Without having to override any styles (and overriding some of Foundation’s styles is a horrible battle of specificity!).

Problem is – you’ve got to figure out what variables there are, what each do, and type them our (or copy & paste), which is more time consuming than writing CSS, because I’ve got CSS styles committed to memory, not Foundation’s arbitrary variable names.

It’s a good idea, but sometimes it’s faster to write normal css.

Bootstrap has glyphicons

I use Bootstrap’s glyphicons all the time. In my Foundation projects I’ve been using FontAwesome, which is great, but it’s nice to have decent icons built-in.

Foundation’s installation process

The tutorial for installing Foundation uses commandline functions to get it installed. Maybe if you’re used to using commandline all the time, you’ll see the advantage in this. But for a light user like me, I feel much more comfortable copying and pasting files into the correct directories.

The ability to @extend more stuff

I use @extend all the time, and find it useful to extend the styles of a class into another. But many places I’ve found in Foundation this errors, for example I was trying to @extend the .show-for-sr class into a new class that did the same thing and more, so that I didn’t have to type out all the styles (SASS will also smush these together in the css for optimisation), but this didn’t work in Foundation because of how these styles are written. Whereas extending .sr-only in Bootstrap is easy.

By default Foundation looks like ass

So out of the box, Foundation looks quite basic, and Bootstrap looks… well… like Bootstrap. This isn’t really a problem which is why I left it til last. There’s a very valid argument that a framework shouldn’t make your site look like anything – and you don’t have to look very far to see the impact Bootstrap has had on the web – many websites that all look the same!

Foundation is deliberately basic so you can apply your own styles, although I quite enjoy working on a site that looks nice right from the start.

All this being said…

…Foundation is decent, and I still think it’s much better to work with a framework than no framework. It does also have some cool things that Bootstrap doesn’t, like Joyride built in (although I’ve not used it yet), and Equalizer, a bit of JavaScript that makes all columns the same height – something that’s been an annoyance in CSS for so many years! (although has been finally fixed with Flexbox).

Overriding a pesky parent selector with ninja specificity

ninjaI try and keep my CSS/SCSS in a fairly flat structure, and recently on a project I’ve been bugged by a parent selector which has been adding quite specific styles that have been getting in the way of my own.

The class is called .copy and has colour styles for <p>, <h2> and for <a>. So if I try to do something specific like give a result title a different colour, it gets overridden by the .copy h2 style.

I could of course make all my styles more specific, but this means adding in another class wrap all my SASS in body or an arbitary class further up the structure, but that’d annoy me because it’d be inserted into the css loads of times unnecessarily.

So I’ve taken to adding in extra selectors to provide more specificity, like this:

.result {
      &__title a,
      .copy & &__title a {

 }

Using the ampersand at the end of the line which in SASS will insert the parent (my new favourite thing) means that I’m covered for if the .copy class overrides my style, but without putting this style somewhere weird that I can’t find later.

It means I’ve added a bit of extra specificity which leaps in like a ninja when I need it, and I don’t have to do it to the entire section.

I’ve discovered the ampersand selector in SASS & now I’m using it everywhere!

Once I discovered you could use an ampersand selector in SASS to reference the parent, I haven’t gone back. I’m using it everywhere because it’s so useful. Here’s an example copied from an article – the article explains it better than I ever could.

h3
  font-size: 20px
  margin-bottom: 10px
  .some-parent-selector &
    font-size: 24px
    margin-bottom: 20px

And here’s how the output CSS looks.

h3 {
  font-size: 20px;
  margin-bottom: 10px;
}
.some-parent-selector h3 {
  font-size: 24px;
  margin-bottom: 20px;
}

This is very useful! Especially when you want to keep css together by usage (I wrote about that here) so that you aren’t looking in multiple SASS files for information about every modification of a style.

Here’s how I used it today – I’ve got a class called “.copy” which is used for the content section of a page. There’s useful things in there like how the links and list items should look, because they’re a bit different to in the chrome (header & footer). But I wanted to create an aside section with different coloured text. Problem was, .aside p is the same specificity as .copy p, and I don’t want to start adding !important which could cause problems later on.

So I wanted to increase the specificity, but I didn’t want to add these styles for the aside inside the copy.scss – because that’s detached from the rest of the styles (which are in aside.scss). So I did this in my aside.scss:

.aside {
   .copy & p {
      color: #484848;
   }
}

Notice it’s between the .copy and the p. It outputs like this:

.copy .vacancy-aside p {
   color: #484848;
}

Neat ways to write BEM without being verbose

BEM + SASS

I love naming classes using BEM, which is a good way to indicate what classes represent (and where to find them in your project), without forcing it into a hierarchy that will cause problems later if you have to change the markup.

Problem is, it can get a bit verbose though.  Especially if you’re being super specific with your names. Writing CSS selectors for long class names is repetitive and annoying. So here’s 2 tips for making it easier using SCSS: Continue reading Neat ways to write BEM without being verbose

The difference between <a> and <button> elements

I’ve seen some markup recently where the <a> tag is being hijacked to do things it shouldn’t be used for, and where a <button> should be used instead. I was going to write a long article about the difference between a HTML <button> element (used normally to DO something), and the HTML <a> element (used normally to take you somewhere else) but I saw this great answer to a question on Quora by Jakob Persson who sums it up perfectly:

This has to do with the semantics of HTML.

An A tag is an anchor element and in the context of hypertext, helps link documents together. HTTP stands for “Hypertext Transfer Protocol” why hypertext is one of the foundational ideas of the web. The word “web” is a metaphor for this network of pages which all tie together, like a spider’s web.

A BUTTON is exactly that, a button. It doesn’t denote there being a relationship between the current document and other. It just says that it is a UI element which you can click.

CSS allows us to style things to look identical. But it doesn’t change the semantics, i.e. the meaning of different HTML elements.

In summary:

  • If your element links the user to another page, then it should be an A.
  • If it’s a UI element that triggers JavaScript, make it a BUTTON.
  • If you want your site to “fail gracefully” when JS is absent, use an A tag that links to a page that relies on a server-side script and attach an event handler to it for the JS functionality.

– Jakob Persson

Keeping CSS classes together by usage

I’ve written before about keeping your CSS grouped by component, so that styles for a specific part are not distributed wildly around the project and difficult to find.

This is normally done because of media queries. A common thing people might do is to split the stylesheet into 3 chunks. Styles for mobile, styles for tablet, and styles for desktop (or more, depending on how many breakpoints you decide to have). But I prefer to put all styles for a specific component in one place, to save you chasing these around. Even if it does mean having loads of media query declarations. But that doesn’t matter! (I use variables for these anyway). Continue reading Keeping CSS classes together by usage