Do Hackers Care About Your Meta CharSet?

The other day, I got this question about the meta charset tag in the mail:

“Would you be so kind as to explain to me, in logical terms, how in 7 hecks does the presence of:
<meta charset="utf-8">
is supposed to affect a ‘hacker attack’ in accordance to your book?
I literally cannot imagine hackers caring much about which charset you display on the UI side when attacking.”

This is a great question. The book he’s referencing is Sams Teach Yourself Bootstrap in 24 Hours, and in it I emphasize the importance of using the meta charset tag and placing it as the first element of your <head> element. But while I explain that leaving it out can leave a page vulnerable to hacks, I don’t explain why. But I will now.

. . .

HTML5 Cheat Sheet

I built an HTML5 cheat sheet for myself, so that I could make sure that my tag libraries were up-to-date and so on. And then when I finished, I realized that this might be something you would like too.

It is a PDF file listing all the HTML5 elements, what they are and whether they are new, changed, the same as HTML 4 or gone from the specification (and what you should use instead). I hope you like it!

HTML5 Cheat Sheet PDF

The Lazy Way to Mobile-Friendly

Or How I Made a Simple Change on a Bootstrap Site to Please Google

Like most web designers I know, I am frantically trying to get many websites mobile-friendly in time for Google’s deadline of April 21st. Knowing that Bootstrap is a very mobile-friendly framework, I have been migrating a lot of the sites I manage into it. This has worked great, but as the deadline looms ever nearer, I have been cutting more corners in getting the sites ready.

And at this point, most of the sites that I’ve left hanging are my own.

So today, I decided to check my branding site http://htmljenn.com/. And as I suspected, even with Bootstrap, it came up as not friendly.

Not Mobile Friendly
I knew that header image was too big!

As you can see from the picture, my headline graphic is way too large for most mobile screens. I knew this, but I was probably hoping it would fix itself overnight or something. It didn’t.

Luckily, Bootstrap offers a feature that makes it easy to get rid of the offending graphic (for now) and replace it with text that is mobile-friendly: The Bootstrap responsive utility classes.

There are 16 classes you can use in Bootstrap to show and hide content from different sized devices. They are:

  • .visible-xs-*
  • .visible-sm-*
  • .visible-md-*
  • .visible-lg-*
  • .hidden-xs
  • .hidden-sm
  • .hidden-md
  • .hidden-lg

You may notice that I only listed eight classes above. That’s because the .visible classes each have three variations:

  • .visible-*-block
  • .visible-*-inline
  • .visible-*-inline-block

Since I realized that most likely the real problem with the mobile site was that the banner image was too big, I decided to hide it (for now) on smaller screens. Instead, I would show them the site title in an <h1> tag.

So I added the <h1> site title (<h1>HTMLJenn</h1>) and then added the class .hidden-md to it. This would hide the site title from any devices of medium size or larger.

Then I hid the banner image by adding the class .visible-md-block to it. This makes it visible only to devices of medium size or larger.

After I uploaded these simple changes, I tested on Google and got:

Mobile Friendly
It’s mobile-friendly!

Hooray! My site is mobile-friendly. Now to work on making it look less ugly! But that can wait until I’ve finished fixing all my other sites!

What To Do to Make Your Site Mobile Friendly

  1. Test your site to see if Google feels it is mobile friendly.
  2. If it isn’t, don’t panic. Google will not delist your site. This bears repeating. Just because a site is not mobile friendly does not mean that it will not show up in Google search. It just means that when someone on a mobile device searches Google, your site will not rank as well as a similar site that is mobile friendly.
  3. If it isn’t already, add your site to Google Webmaster Tools and follow the instructions in the Google Mobile SEO

There are many ways you can make your sites more mobile friendly. The Bootstrap framework is one way to get a responsive web design fairly quickly.

More Help with Bootstrap, Mobile-Friendly Design, RWD, and Google’s Change to Search Results

How to Speed Up Your Website with GZip Compression

If you follow the instructions on the Yahoo! YSlow best practices, one of them is to compress your pages using gzip compression (“Gzip components”). By doing this, you compress all your files before they are sent across the web, and then the browser decompresses them on the other side. This can significantly improve the time it takes your website to load.

How to Compress a Website with GZip and HTaccess

First check that your site is not already compressed. Some hosting providers do this automatically.

Go to GID Zip Test and enter your URL. If it returns that your site is compressed, you’re done.

GID Zip Test
This site is compressed

If your site is not compressed, you need to know what web server you’re using. If you’re not sure, ask your hosting provider, but the most common web server is Apache. Chances are, that is what your site uses too.

Compress Files on Apache

  1. Go to the root directory of your web server and edit the .htaccess file in a text editor. If you can’t see that file, first make sure that hidden files are visible and if it’s still not there, then you should create a file with that name—including the dot (.) at the beginning of the file.
  2. Add the following lines to the file:
  3. Upload the .htaccess file to the same location on your website (typically the root folder).
  4. Test your site again using the GID Zip Test site.

If Your Apache Site Still Isn’t Compressed

Many hosting providers use virtual hosts for web hosting, and sometimes these don’t always recognize all commands in the .htaccess file. Your best bet is to talk to your hosting support to see if they can get it running. They will probably have to add the above lines (in step 2) into the httpd.conf or vhosts.conf file.

Compress Files on IIS

I don’t have an IIS server, so I cannot tell you exactly how to do it, but Microsoft has a comprehensive Technet document: Configuring HTTP Compression in IIS 7 that covers: configuring compression, enabling compression of dynamic content, and enabling compression of static content.

What Semantics Means in HTML and Why You Should Care

Once you’ve been writing HTML for a while, you may come across the term “semantic HTML.” But what does that really mean?

What is Semantics?

You may have heard the phrase “that’s just semantics” used as a way to dismiss an argument or otherwise minimize the importance of something someone says, but semantics can be important to your website. Understanding semantics as it applies to HTML can save you time and money in the long run.

In web design, semantics is concerned with the meaning of the tags and attributes that you use to build your web pages. In other words, semantic HTML is HTML that contains meaning in and of itself, beyond any content that it might be marking up. Semantic HTML lets the browser understand what the tag contains, and so will you.

Here is a hypothetical example of HTML if it were written with all the tags differentiated by numbers:

This is pretty difficult to understand, right? Web browsers could have been programmed to read the above faux HTML just as easily as they read real HTML.

Here’s the same web page written in real HTML:

This is much easier to read and understand, even if you don’t know HTML. You can make guesses about what the content is because of the HTML tags surrounding it. Let’s look at it line by line:

Line 1: <!doctype html>
You may not know what the word “doctype” means, but if you were to guess, you might think it meant “document type” and this is followed by HTML. So this line probably means that the document is an HTML document.

Line 2: <html>
Even if you didn’t understand the first line, this line confirms that we’re working with an HTML document.

Line 3: <head>
This may not be clear immediately, but it obviously means something to do with the “head” of the document, perhaps the brains.

Line 4: <title>Now is the Time</title>
This is the first really semantic tag you see in the document, even though the above tags are reasonably understandable. It’s clear that the title of the document is “Now is the Time.” This line also gives you a clue as to how HTML is structured, as you can see the closing tag right there.

Line 5: </head>
We learned about closing tags in line 4, so it’s clear that this is the end of the head information for the page.

Line 6: <body>
This is probably the beginning of the main focus or body of the web page.

Line 7: <h1>Now is the Time</h1>
This is a repetition of the title, but the tags surrounding the text aren’t terribly clear. Once you understand HTML you’ll recognize this as a level 1 headline, but the semantics are poor on this tag.

Line 8: <p>For all good people…</p>
This is another tag that you will recognize as semantic once you know HTML better. And it might be more obvious what it is in a longer page with more of them. This is a paragraph tag. It might have been more semantic if it was written <paragraph>.

Line 9: </body>
Here we have the end of the body of the page.

Line 10: </html>
And finally the end of the document itself.

As you can see, a tag like <body> has a lot more meaning in and of itself than <tag5>.

This is semantic HTML. Semantic HTML is HTML that provides meaning to the content it contains.

Why is Semantics Important for HTML?

Semantic HTML makes your web pages easier to read and understand. While most of your customers won’t ever see the HTML tags, the browsers will and they can make adjustments based on the tags to make the content display more effectively.

For example, in HTML 4, you could only embed video and audio using non-semantic <object> tags. The browser knew that the element was an object of some type, but not what it was.

An object could be almost anything, and the browser wouldn’t know until it started to try and display it. But with the new semantic <video> and <audio> tags the browser will know immediately what it has to download. If the browser doesn’t support video, it knows before it starts to download the file, which saves the customer time.

But semantics can also save you money. Web pages need to change to stay current. When a page is marked up semantically the next web designer to edit it can tell almost at a glance what the page has on it, without needing to read any of the content. This saves time, and gets the designs built more quickly, which saves money.

Plus, just like browsers, web designers can use semantic HTML to design their pages better. If you have code samples in your documents, you can add line numbers to them automatically if you use the <code> tag around them. You can put gorgeous graphical quotation marks around <blockquote> elements.

And there will probably be additional features that come out in the future for semantic elements. For instance, a tag like <address type=”skype”> might allow for direct video calls embedded in web pages. Using semantic HTML tags future-proof your web designs and ensure that your meaning is understood.

Semantic HTML Tags in HTML5

The following table shows the semantic tags in HTML5.

<abbr>Abbreviation
<address>Address of the authors of the document
<article>Article
<aside>Tangential or content that is loosely related to the main content
<audio>Audio or sound file
<blockquote>Long quotation
<body>Body of the document
<button>Button or input tag
<canvas>Canvas for animation or scripted content
<cite>Citation
<code>Code reference
<col>Column in a table
<colgroup>Group of columns
<datalist>List of data for use in forms
<del>Deleted text
<dfn>Definition
<em>Emphasis
<figure>Figure
<footer>Footer
<h1>First level headline
<h2>Second level headline
<h3>Third level headline
<h4>Fourth level headline
<h5>Fifth level headline
<h6>Sixth level headline
<head>Head of the document
<header>Header
<hr>Thematic break
<html>HTML
<ins>Inserted text
<kbd>Text to be entered by the user
<label>Label
<legend>Legend
<mark>Content that has been marked in some way
<menu>Menu
<meter>A scalar measure
<output>Form output
<p>Paragraph
<pre>Pre-formatted text
<progress>Progress bar
<q>Short inline quotation
<ruby>Ruby annotation
<s>Strikethrough
<samp>Sample output
<section>Section
<small>Small text
<strong>Strongly emphasized text
<sub>Subscript
<summary>Summary
<sup>Superscript
<title>Title
<var>Variable or user defined text
<video>Video

Basics of HTML5

HTML5 is no more difficult to learn than any other version of HTML. But there are a few things you can do to make it easier and more cost-effective to using it.

Start with the Doctype

The easiest way to start using HTML5 is to change the doctype you use in your documents. You can do this by simply making the first line of your HTML documents read:

<doctype html>

But if you use a WYSIWYG editor, you can also change it there. For example, in Dreamweaver CC, in the “New Document” window, you can choose HTML5 as the DocType from one of several choices.

Dreamweaver Using HTML5 Doctype
How to add the HTML5 doctype to a new Dreamweaver document

In the CoffeeCup Web Editor, you use the template “HTML 5” when you’re opening a new document to create a new HTML5 document.
CofeeCup Web Editor Using HTML5 Doctype
How to add the HTML5 doctype to a CoffeeCup Web Editor page

And many web editors these days default to HTML5. If you’re using an editor like Tummult Hype, Macaw, or CoffeeCup Responsive Design Layout Maker Pro you don’t have to worry about the doctype, as these editors use HTML5 automatically.
Hype, Responsive Layout Maker, Macaw
Many modern web editors use HTML5 automatically.

Your First HTML5 Document

As I said above, all you need to have an HTML5 document is the correct doctype. But there are a few other tags that can help. Here’s a really basic HTML5 template that I start all my web pages with:

Change the highlighted lines to your own content

HTML5 is an Improvement to HTML 4.01

One question I get asked all the time is how difficult is it to learn HTML5 if you already know HTML 4.01 or any other version of HTML. The great news is that HTML5 isn’t really all that different from HTML 4.01. In fact, if all you do is add the doctype listed above and then writing your pages exactly as you did before, you will have joined the millions of designers using HTML5.

But one of the reasons to use HTML5 is because of all the improvements there are in it. There are dozens of new tags that add more functionality to your pages. None of the new tags are absolutely critical to any web page, but they add useful features that can enhance your pages and make them more useful to your customers.

Some of the tags I find most useful include:

  • The sectioning tags: <article>, <nav>, <footer>, etc.
  • Text semantics tags like <data> and <time>
  • Embedded content: <canvas>, <video>, and <audio>
  • The new forms tags and attributes

Learn about all the new HTML5 tags.

Scripting APIs Give You So Much More to Do On Your Sites

HTML5 offers a bunch of new APIs or application programming interfaces to help designers and developers offer more features on your websites.

  • Web Application APIs—these let your web pages act more like applications on a computer or tablet. There is support for error handling and events and can make your pages more interactive and useful.
  • Video and audio APIs—with more than just the <video> and <audio> tags, the new APIs help you to play back video and audio that are embedded directly in your web pages.
  • Offline web applications—this API helps you store information so that a customer using your web application on a mobile device doesn’t have to be connected to the internet to use the application.
  • Contenteditable—While Internet Explorer has supported this attribute for a few years, HTML5 has added an API to support it more widely.
  • Drag and Drop—This is a functionality that desktop applications have had for years, but until recently, web designers were stuck fiddling and futzing with different scripts to get drag and drop to work.
  • History API—Most people don’t understand the value of the History API because it’s not a visible functionality. But this API can make your web applications work more effectively by giving URIs to dynamic pages that don’t have URLs and changing the visible URL or any URIs in the history of the browser.

Where to Learn More About HTML5

There are lots of places online to learn HTML5, these are some of my favorite resources:

And of course, you can learn all about HTML5 from my book: Sams Teach Yourself HTML5 Mobile Application Development in 24 Hours.
Buy Now: Teach Yourself HTML5 Mobile Application Development in 24 Hours

Not all design testing tools are created equal

I’ve noticed lately a proliferation of websites like Responsive Design Testing Tool which claim to offer a way to test your responsive web designs in different browser or device widths. I happily began testing some of the pages I design and noticed that they didn’t look right—the designs weren’t responding to the width. After checking my CSS @media queries for errors I had an idea. Check the page on my iPhone.

A bad way to test responsive designs
Do you notice anything interesting about these four renderings?

If you go to the Responsive Design Testing Tool and put in a web page you know is responsive, you might notice something like what I saw in the screen shot above. What you’re seeing is the About.com home page rendered in four iframes at the four listed dimensions. If you look closely, you’ll notice that all four images in the frames are exactly the same size. This is because while the iframes loading the page are set to the width and height of the devices, the pages are rendering based on the browser window itself, not the iframe widths.

When I viewed the page on my iPhone the responsive features kicked in as they were supposed to and I saw the page as it was supposed to look.

Testing on the Device Gives Better Results
Here’s what the page looks like on a real iPhone

As you can see, on a real iPhone the About.com logo is smaller and on the black background. The navigation has been reduced down to the navigation icon example icon. The headline and image are both fully visible. And there is no horizontal scrolling required. In other words, About.com modified the layout responsively based on the viewport of the iPhone.

Be Wary of Online Emulators

There are a number of sites like the Responsive Design Testing Tool that claim to be RWD testing tools, but in reality they are just iframe page loaders. And because most pages take their cue from the device window rather than a width set on an HTML element like an iframe, they just show the page as it would look on the browser it’s in.

I decided for the hell of it to see how About.com’s page would render in the iframes of the Responsive Testing Tool on my iPhone. Below is the result:

How it renders on an iPhone
The Responsive Design Testing Tool on an iPhone

The immediate red flag for me when viewing this site on my iPhone was that the testing tool page itself made no effort to be responsive. You could argue that that’s because it really needs to be viewed on a desktop browser, but it was very difficult to scroll horizontally to see any of the iframes other than the 240×320 (small phone) frame. Other things I noticed were that the URL field did not use the URL input field, which made it slightly tougher to type in on my iPhone and it cut off the iframe completely on the right as you can see in the screen shot on the left.

All in all I wouldn’t trust this tool to do any testing on my websites. I’d be better off doing only testing on my browser and not worrying about mobile devices.

What Can You Use?

While online emulators might not be the best solution for testing responsive websites, you can use them to test non-responsive sites to see how your pages might render on a smaller screen device.

Another option you have for testing is to use an emulator. You can get an iPhone emulator from Apple and an Android emulator from Android.

Want to Learn more about Responsive Web Design?

Sams Teach Yourself Responsive Web Design with HTML5 and CSS3 in 24 Hours
Available Oct 2014

I am writing a book on responsive web design Responsive Web Design with HTML5 and CSS3 in 24 Hours, Sams Teach Yourself. It is available now for pre-order on Amazon and other places where books are sold.

I’m loving SVG

One of the great things about HTML5 is that there is a proposal in the W3C  to allow HTML5 and XHTML to include SVG inline in the documents. But what’s especially great is that if you’re using a modern browser (IE 9+, Firefox, Safari, Chrome, or Opera) you can embed SVG graphics in your HTML5 documents quickly and painlessly.

I am loving SVG because I don’t have to learn anything new. I can simply create vector graphics in Adobe Illustrator and then embed the SVG code into my HTML like I would any other image or embedded element. I don’t even have to use any special tags to call it out, I just paste everything from the starting <svg> tag to the closing </svg> tag.

Here’s an example. Note, I have added a <switch> tag to call a fallback image if your browser doesn’t support inline SVG. This might result in you seeing the image twice, but I hope not. 🙂 If, when you right-click on this graph, you see a PNG image, then you’re seeing the fallback image.

If you look at the HTML for that image, you’ll see a lot of <g> and <path fill="#FED7B8" d="M149.878,150.489l52.584,112.768c-62.28,29.041-136.311,2.097-165.353-60.184 c-14.521-31.14-15.905-62.854-4.154-95.141L149.878,150.489z"/> and other stuff that might look like gobbledygook, but it’s all SVG, and I didn’t have to come up with any of it. My program, Illustrator, did all the heavy lifting.

The ability to add smooth, crisp vector images to my HTML pages is a huge benefit to using HTML5. I hope that we see more of this type of graphics in the future.