Tag: Programming

HTML 5: Omitting unnecessary speech marks

In my last post I described how it is possible to cut down on your HTML filesize and save some time in your coding by omitting optional closing tags.

As a follow up to that post I thought I’d also describe another process to save even more on your filesize and a little bit more time still.

Please note however, these examples i’m describing are really micro-optimizations. For every project you make to be the best that it can be, I would strongly recommend looking into combining your scripts into one single file and minifying it. Minifying your CSS can also go a long way to improving speed. Those techniques, as well as others, are a seperate issue but are definiately worth your time in learning.

Back to the speech marks

A lot of us developers, me included, have a habit of wrapping up our attributes in speech marks, whether single or double, as in the following example:

<head>
  <meta charset="utf-8">
  <title>Example Title</title>
  <link rel="stylesheet" href="css/style.css">
</head>

The truth is, however, that in most cases you can leave the speech marks out completely, as in the following example:

<head>
  <meta charset=utf-8>
  <title>Example Title</title>
  <link rel=stylesheet href=css/style.css>
</head>

The browser will still render that correctly, and if you view the page source with the Chrome dev tools ‘inspect element’, you’ll see that the speech marks have in fact been put in for you!

Most Cases you say?

There is one situation where you will still need to use speech marks. This is when attributes have more than one value, or includes any white space. For Example:

<section>
  <span class="main-class secondary-class"></span>
  <img class=section-image src="images/image name with spaces.jpg">
</section>

So as a rule, when declaring attributes on html elements, you can omit all speech marks where there’s no white space contained. This is because the attribute ends when it hits the white space. I hope this helps you all to add an extra little bit of optimization into both your workflow and the size of your code.

If you have any of your own tips for code optimization, please share it in the comments section below. Thanks!

HTML5: On removing optional closing tags

Firstly, an example of some html…

<article>


  <p>Once upon a time there was a web programmer.</p>
  <p>He found that he wanted to cut down on his html filesize.</p>
  <p>He came up with a list of ideas. They were as follows:</p>


  <ul>
    <li>Minifying his code</li>
    <li>Cutting out content, (unacceptable!!!).</li>
    <li>Remove optional tags, speech marks, etc...</li>
  </ul>


  <p>On writing the last item in the list, he exclaimed, <em>That's amazing</em>, now to tell others...</p>


</article>

Lovely and semantic. Now, there’s nothing at all wrong with what I’ve written above. This article is all about showing you how there are certain things in your HTML that can be left out, without breaking any part of it.

You can actually omit many closing tags and still have it render exactly how you planned.

The example above, after removing optional closing tags:

<article>


  <p>Once upon a time there was a web programmer.
  <p>He found that he wanted to cut down on his html filesize.
  <p>He came up with a list of ideas. They were as follows:


  <ul>
    <li>Minifying his code
    <li>Cutting out content, (unacceptable!!!).
    <li>Remove optional tags, speech marks, etc...
  </ul>


  <p>On writing the last item in the list, he exclaimed, <em>That's amazing</em>, now to tell others...


</article>

The elements removed:

Paragraph closing tags can be omitted, because when the next one begins it knows that the last one has finished. Same with the list items also. Each list is begun with its <li>. But you’ll notice other closing tags have been kept.

The elements remaining:

The article still needs to be closed, as the browser will otherwise think the article is ongoing. The </ul> has also been kept, as it wraps the list, and stops the last list item from continuing onwards. And lastly in the example above, the </em> has remained, simply because, if left out, will continue to emphasize the rest of the paragraph.

Common Errors to be aware of:

There may be times when you will omit a closing tag, but find it may mess up your code. For Example:

<article>
  <h1>The heading is as expected. Yay!
  <p>But the paragraph inherits styles from the <h1>, boo!
</article>

The above happens, quite simply, because the browser doesn’t know that the <h1> should close. So as a result the paragraph is treated as though it is ‘wrapped within’ the <h1></h1> tags. The <h1> in the example above is closed by the browser, when it reaches the end of its parent continer, the <article> And so ends up rendering as the following:

<article>
  <h1>The heading is as expected. Yay!
    <p>But the paragraph inherits styles from the <h1>, boo!</p>
  </h1>
</article>

Combating this, however, is easy. See the following:

<article>
  <header>
    <h1>The heading is now contained within both header tags that we close in the code...
  </header>
  <p>...and so now the heading styles wont bleed into this paragraph as they are contained in the <header>
</article>

By way of summary

At first it can feel odd omitting these optional closing tags, but it will, in the long run, save you both time and those precious bytes. You just need to make sure you pick your times carefully. Generally, the rule I try to stick to is: if its a container with more than one type of child element (ie. article, section, div, nav etc.) close them off in your code. But if they are single entities, such as paragraphs, headings(of same number), lists etc, that are immediately preceded by the same tags, and have no differing siblings, omit the closing tag.

It will take a bit of getting used to, but if you nest your code well you will quickly begin to notice where you can omit closing tags.

Developer inspect tools can help

I am a huge fan and regular user of the chrome developer tools. you can use its ‘inspect element’ feature to test out your code to see where the tags are being closed by the browser. Just write a paragraph without the closing tag and view it in the inspector. When you see it in the flesh and get used to how the browser renders your code, it will give you more confidence to omit those optional tags.

In Google Chrome, right click any part of the web page, and you should see the option to ‘inspect element’ towards the bottom.

CSS… how to use sass and compass: Part Two

Please note: for the sake of brevity, when using sass and compass, I refer to them both as compass.

Following on from our previous tutorial, I would like to introduce you to @import. @import is a css feature that will allow you to import stylesheets into one another. For example:

@import "normalize.css"; 
body{
    background:lightblue;
    width:1000px;
    margin:auto;
}

This will bring in ‘normalize.css’ from the same folder as the stylesheet itself, and then apply the body properties.

With this, however, it will grab each @import on page load and add unnecessary time to your page download speed. In this part of my compass tutorial, I will show you how to incorporate @import and use compass to compile them all into one stylesheet during production.

How styles get compiled

Remember from the last part of the tutorial when we changed the style.scss file, and it updated our style.css one? Well we could in fact have any number of files, with different names, and they would each update in the same way. So if you had a base.scss, it would compile to base.css, typography.scss would update typography.css, and so on. You need not create the .css version either, as compass will do this for you automatically if it can’t find one when it compiles.

The way in which it compiles is defined in the config.rb file. As mentioned in the previous post, I highly recommend you set it to ‘:compressed’ before uploading to your server, as this will improve your page loading speed. The reason for this is that it removes any and all comments and white space.

Example Stylesheet setup

Below I have listed the default structure of my stylesheets. Create them as .scss files in your sass folder and please note the underscores, as these are needed. You wont be needing any .css versions. The only css file you will need is style.css.

I recommend you save a copy of the whole project directory when you have these stylesheets setup. That way you will have a nice starting off point for each of your projects.

  • _normalize.scss
  • _helpers.scss
  • _print.scss

Remember that stylesheet I advised you to temporarily save to your desktop? Well we are now going to bring that back in. If you open it in your code editor, you will see it is split into three main areas (not including the media queries part). The main code up top is the normalize. Then you have useful helper classes, and finally a set of print styles.

Copy and paste each part of the stylesheet into their respective .scss files.

Now re-open your style.scss and delete any previous code out, and write the following:

@import "normalize";
@import "helpers";
@import "print";

Save it. Notice how I have not included the underscore or the ‘.scss’ extension, as these are not required when importing them.

If it isn’t already running, start compass off watching your project as shown in the previous part. Compass should detect the changes to style.scss straight away and compile to its css equivalent. So now on re-opening style.css, you should see how normalize, helpers and print have all been pulled in from their imports on style.scss

What this now means is that you could theoretically split your styles into as many separate sheets as your wanted. As long as you remember to @import them into style.scss, then compass will see any changes to any of them and compile them all together into the one style.css. See, I told you they were awesome.

I encourage you to go now and experiment with splitting up your own stylesheets into manageable chunks. You will soon find a balance that suits your own tastes.

Thank you for reading the tutorials this far. I hope these first two parts have given you a good start with using sass and compass, although I did say I’d only refer to them as compass… Darn it! Oh well.

I realize this isn’t the most exciting of the features available to them. After all, I haven’t even mentioned mixins or even nesting (coming up in next part), but for me at least this has been the most indespensible of the features I’ve learnt so far.

I hope this helps you get up and running with Sass and Compass with ease. Let me know how you get on. Thanks.

CSS… how to use sass and compass: Part One

After listening to Chris Coyier speak about using Sass in CSS, I read up on it and decided to give it a bash myself. And… oh my god… it… is… frickin’ awesome!

I love writing CSS anyway, so I wasn’t really thinking about anything to make it easier or quicker (which Sass does in spades). But what I didn’t expect was how much more creative it made me feel.

So what are Sass and Compass?

In short, Sass is a CSS pre-processor. It enables you to write much more condensed stylesheets and then have sass ‘turn them into’ real CSS. On top of this it gives you a lot of nifty little abilities to really help with your workflow and avoid repetition of code. Compass is a separate entity and sits on top of Sass to give even more goodies.

I realize that to the uninitiated these terms may seem daunting – they did to me – but I can honestly say that once you get working with them you really will wonder how you did without them.

Installing Sass and Compass (for windows)

What follows is how I installed Sass and Compass on my windows machine. I’ve included the installation here, but if you run on anything different, or find something not working for you, then please visit the documentation pages (links at end of this post). The docs are fantastic and will have you up and running in no time!

Firstly you’ll need to install Ruby. Don’t run away! This is all very easy, honest. Use one of the windows installers here, and that’ll be that.

Once installed, open it up, type the following in and hit enter:

gem install sass

After a few seconds or so, Sass will be installed on your machine. Told you it was easy! Now you can leave it there and enjoy all of the fantastic benefits that Sass has to offer, or you can continue and install Compass in an equally simple way.

Type each line separate, hitting enter after you do:

gem update --system
gem install compass

And there you have it, Sass and Compass installed on your machine.

Next if you go to the compass install docs here, it will guide you through setting up your first project with compass. The reason I urge you to do this at least once, is that it will create a file called ‘config.rb’, which you will use in each project. It is the file that dictates how your styles will be compiled.

Starting to use them in your projects

Again, I’d just like to point out that the following is how I use Sass and Compass in my own projects. There are ways of creating new projects in the command line, but I prefer to do it my own way. Mainly because, if I’m honest, the command line scares me.

For most of my projects I kick off with the HTML5 Boilerplate. This is such a great resource for learning from if nothing more, but it’s also an awesome platform from which to start new projects. Get it here.

Within the root directory of the Boilerplate folder, create a folder called ‘sass’ and paste the ‘config.rb’ file from the project created in the previous step. Within this config file you can edit certain properties to suit your needs. (I highly recommend setting the output style to ‘:compressed’, right before uploading to your live server)

The settings in my config file are as follows:

  • http_path = “/”
  • css_dir = “css”
  • sass_dir = “sass”
  • images_dir = “img”
  • javascripts_dir = “js”
  • output_style = :expanded

Lastly, to get us up and running, you need to create a file in the sass folder of your project. Let’s call it style.scss (please note the .scss extension). Then look inside your css folder of your project. If you have begun with the HTML5 Boilerplate, then there should already be a style.css file inside.

At this point, I would highly recommend making a copy of the style.css file and saving it elsewhere, perhaps to your desktop temporarily. This will become apparent as to why in part two of this tutorial.

Next, find and note down the location of your new project root (the one we are making with boilerplate, not the command line one). For Example, C:\xampp\htdocs\PROJECT_NAME (As I use xampp as my localhost). This may differ for you, but hopefully you should be able to work out your own. Then open up the ruby command prompt, type the following and hit enter:

cd\

This will set your path relative to your computer’s main hard drive. Then you simply tell compass to ‘watch’ your project for changes and to compile it into a css file:

compass watch xampp\htdocs\PROJECT_NAME

Obviously you would need to alter the path to match your own project location. If that has started correctly you should receive a message telling you that compass is ‘polling for changes’. What this means is that whatever changes are made to the sass file and saved, will be automatically converted into normal css.

Now, opening the style.scss file in your code editor, write any css style you like as a quick test. Write it exactly as you would in a normal css file, then save it. Now open up the style.css file and you should see that same code copied from the sass style file.

And that finishes off this introduction to sass and compass. I realize that the end result has given you nothing that is of use yet, but this was merely setting the stage for the awesomeness that is to come. In the next part I will show you how to further delve into the functionality of these great tools.

Helpful Links

Sass documentation | Compass Documentation