Blog home

Archive

RSS

The Livetyping Blog

• Bootstrap: not the solution to every problem

  Tweet

  or

  How to deal with the fiddly shit

  Responsive frameworks are awesome. Whether it's Foundation (my favourite) or Bootstrap (most other people's favourite), they really do save you a lot of time, effort, and pullling-out-of-hair. Using one is real standing-on-the-shoulders-of-giants stuff.

  But they're not perfect.

  You will always run up against something that they just can't help you with. And then you're on your own. Just you, whatever HTML and CSS knowledge you have, and Google to fill in the gaps.

  This post covers one such problem that I had to deal with recently, and shows you how to overcome it. (This isn't one of those "These three easy steps will solve all your Bootstrap woes" posts. There are lots of problems like this, each with its own solution. Or several possible solutions. If you're wrestling with a different problem, send me an email or a tweet and I'll try to help.)

  The problem I was having (with Bootstrap, so I'll use that here too) was that there was content that was displayed in a modal dialog, but sometimes the content was too wide—a very long string with no spaces or other natural breaks, and by default, it just ran out of the edge of the modal. And it was generated content that I had no control over, so I couldn't just insert some spaces. Oh, and there was also a Bootstrap label at the beginning of the line of text that had to be handled correctly too.

  It looked something like this:

  

  (View on JS Bin.)

  So I had to figure out how to make it wrap. This should be easy. There are a couple of different CSS properties that you can use to force text to wrap. word-break seemed to work best:

  .modal-header
  {
    word-break: break-all;
  }
  

  And it seemed to do the trick:

  

  (View on JS Bin.)

  But I don't really like the way the text on the second line starts under the label, instead of lining up nicely with the text on the first line. Surely it should be easy enough to fix that, right?

  I mean, we should just be able to use Bootstrap's responsive grid. We can just nest another grid in there. And…

  

  (View on JS Bin.)

  Aughhh! No! That's not what I meant! Why is it like that?

  Ah, I see, it's that close button. It's not even part of the row that we added, but because of the way it's being positioned (using a float), it's messing things up. Maybe if we try putting it in its own column?

  

  (View on JS Bin.)

  That's a lot better. But something still isn't right here. Look at the label. The text wasn't that small before, was it? (I'll save you the trouble of going back and checking—it wasn't.)

  If we take a look at the label in Chrome dev tools, we can see its font size is 75%:

  

  But 75% of what?

  Well, before, it was 75% of whatever our heading 4's font size was. Now I suppose it must be 75% of the base font size, which is presumably less. So. What to do?

  We could go and figure out the font size for h4 and apply that to this label. Or we could just wrap it in <h4> tags. (And we have to add the same class as our existing h4, otherwise it gets some margins added to it which makes it look crap.) How's that?

  

  (View on JS Bin.)

  One other annoying thing. There's a big gap between the label and the text. Maybe the two columns we gave it were too much. Would just one work?

  

  Well, kind of. But it's touching the text. And on smaller screens it really doesn't work:

  

  Also, if the label text is a bit longer, it will make the label wider, which will also screw things up. Which highlights the point that you need to know the actual content you're going to be displaying and set up your layout with that in mind.

  In fact, on small screens it would probably make more sense to make the label stack above the text—it's a better use of space. So maybe we should use the small (col-sm-) or medium (col-md-) column classes instead of the extra-small (col-xs-) ones I used to make sure that happens:

  

  (View on JS Bin.)

  And now we have yet another problem. The "x" close button is now in the wrong place. (Like I said, fiddly shit.) So let's think, what can we do here? There are a couple of things that come to mind. One thing that Bootstrap lets you do is to change the order of the columns depending on the screen size. But I've always found this to be very unintuitive and hard to get my head round.

  A more pragmatic approach might be to say, OK, on a small screen, that tiny "x" is next to useless, and anyway we've got a close button, so let's just hide the "x". Bootstrap's responsive utilities let you do this (by adding the hidden-xs class to the div containing the button):

  

  (View on JS Bin.)

  I'm pretty happy with the way this looks now. In the next post, I'll go through an even more fiddly and annoying problem. And if you're wrestling with something fiddly too, get in touch—maybe I'll be able to help.

  ---

  If you found this useful, and you don't want to miss out on other posts like this, sign up for my newsletter.

  Tweet

• The Easiest Way to Set Up a Static Prototype/Site

  Tweet

  Often, when you're building a prototype or a simple (maybe static) website, you'll find yourself making a bunch of static HTML pages that you link together. And most of the time, there are things that are the same on every single page. The header. The footer. An email signup form. Etc.

  There are many different ways of avoiding the bother of having to copy and paste this common content between pages (not to mention what a pain it is to edit every single page whenever you need to change something).

  When I was looking for a solution to this problem, I found that most of these ways are quite complicated. There are static site generators like Jekyll, Pelican, and Octopress. (And many, many others.) There are the templating languages, such as Handlebars, Mustache, and Jinja2. And there are powerful but complex frameworks like AngularJS that come with this of functionality built in.

  I've looked at all of these at various times and for various reasons, and I was left gibbering – they were all complete overkill for what I was trying to do. Their learning curves just weren't worth it.

  And then I found Brace Tags. All it does is pull pieces of content into HTML pages. That's it. Nothing more.

  Let me show you.

  Let's say you've got a web page that looks like this:

  <html>
  <head>
      <title>My homepage</title>
  </head>
  <body>
      <h1>Welcome to my homepage</h1>
      <p>Look at all this content!</p>
  </body>
  </html>
  

  And you want to add a footer to this page (and to all your other pages). You create a folder called _partials in the same folder as your HTML files and create a file containing your footer markup in it. Call it, say, footer.html. Something like this:

  <footer>
      <p>Copyright &copy; Martin Polley 2016</p>
  </footer>
  

  Then add one line to the first file to pull in the footer, so it looks like this:

  <html>
  <head>
      <title>My homepage</title>
  </head>
  <body>
      <h1>Welcome to my homepage</h1>
      <p>Look at all this content!</p>
      {% include _partials/footer.html %}
  </body>
  </html>
  

  Then you run Brace Tags on it by typing tags build at the command line in the folder containing your files. It assembles the pages and puts them in a folder called _site. That's it. Dead simple, with a minimum of faffing about.

  The thing is, it only runs on OS X or Linux. But I'm on Windows at the moment, so I've set up a virtual machine running Linux just so I can run Brace Tags. It's worth the hassle of setting up a VM to have access to such a simple, useful tool.

  ---

  If you found this useful, and don't want to miss out on more like it, sign up for my (rather irregular) newsletter.

  Tweet

Page 1 / 18 »