When new bloggers get started on WordPress, they need to understand the basics of what Categories and Tags are. Both can help people find the content they want on your blog, but they serve slightly different purposes.
Categories are big. Broad topics that will repeat again and again on your blog. For example, web education is a topic mentioned over and over again on this blog. It should be a Category.
Under the overarching Category of web education, however, there might be many specific ideas that would be used just once, or perhaps infrequently. For example, a post about web education could be something as specific as how to write good alt text or what ARIA roles are. These very specific topics should be added to the post as tags. Tags are also helpful to search engines in figuring out what a post is about.
Depending on your theme in WordPress, the categories may become part of the menu. For example, on my blog Old Ain’t Dead, I only have 5 categories. These categories are Movies, TV series, Web series, Streaming, and News. These categories are shown as a menu. On this blog, Web Teacher, I have dozens of categories and it would not be useful to list them as menu items. The categories are, however, shown in the sidebar in a pull-down menu.
Blogs can be searched by category. For example, if you select the category bloggingfrom the list of categories on this blog, every post in that category shows up as a search result.
Tags are also searchable, for example a search on the tag alt text. The tag alt text might be used in posts in several Categories, so the search results for a tag would include posts from all those Categories.
Choose meaningful category names. Don’t create category names that convey nothing about your content. For example, category names like “This & That” or “Misc” are not helpful to your readers or to search engines.
I’ve been attempting to sort out in my own mind exactly what I needed to be teaching students about responsive images. For a while, things have been a bit wobbly in this area and there were no definite best practice ideas. Thanks to the Responsive Images Community Group, I think a consensus on best practice has gelled for now.
Srcset and sizes
I’m sure you’ve heard about the new picture element. Before you think about using it, you need to know when you can use the familiar img element.
The majority of the time, the srcset and sizes attributes of the img element will be what front end developers use.
This example shows srcset with img and options for display density.
The src attribute is the fallback image. The “1.5x” means 1.5 device pixels per CSS pixel, and is a larger image. The 2x means 2 device pixels per CSS pixel, and again, refers to a larger image. It means you have prepared 3 versions of the same image and uploaded them.
Here’s an example of code using an img element with srcset and sizes attributes.
The srcset attribute lets you give a comma separated list of image file paths. The second example used w to specify width to the browser and vw to specify viewport width. Instead of display density, the second example uses media queries to designate images from the list. Again, you have prepared 3 images in different sizes and have them on the server.
Whether you’ve prepared your code to work with pixel density or using widths, the result is the browser makes a choice as to which image will work best. The browser decides which image of the listed images fits the situation by evaluating resolution, viewport size, even bandwidth, and chooses the best image for the situation.
You can also add add the sizes attribute. The sizes attribute tells the browser how many pixels it needs by describing the final rendered width of the image. To make the image occupy a third of the viewport, the code would be:
sizes="33.3vw"
With sizes, you provide a CSS length that describes the image’s rendered width. CSS lengths can be either absolute (150px or 20em) or relative to the viewport as in 33.3vw. As with fonts or other relative measures, the relative to the viewport value is what offers the responsive rendering. The 100vw measure is the default length and would be used if no other conditions matched.
Value can be in px, ems, or vw.
In the second example above the sizes attribute uses media query width descriptors with values in ems or vw (viewport width). The first value is a media condition (a media query without the media type) and the second value is a length. Note, the default length is not matched to a media query.
You can use only the srcset or both srcset and sizes attributes with the img element.
When you need to do more than resize an image
So, when do you use the picture element?
Sometimes an image won’t work if it is simply sized differently for different devices. It might need to be cropped or have some other type of what is called art direction work done on it. In this situation, you want to give a list of different images to the browser to use in different situations. Perhaps they’ve been cropped. If the image contain words, perhaps the text has been reworked for different size displays. They are not merely resized versions of a single image, but completely reworked images meant to fit different situations.
Use the picture element with multiple source elements for this situation.
Embedded in the picture element are source elements with images paths, media queries, display density designations – all the things we saw with the img element, but here the source elements link to images that have been altered in some way. The last thing nested in the picture element is a fallback img element.
OMG
That’s a lot of new information for someone who grew up on the old style image tags. New length measures, new elements, new attributes. I’m not sure I really have it clearly understood. Writing this was one way to help me work it all out in my mind. If any of you see where I’m foggy or misunderstand something, please offer suggestions.
There’s an 8th Edition released in 2013, but we haven’t switched to it yet. I’m sure we will soon, but for the moment, we are using the 7th edition.
Here are a few teaching tips if you are using the 7th edition, as I currently am.
At the time this book was written, there was no <main> element in the spec. I suggest you change the layout suggested in Chapter 3 to use the <main> element for the left column. Use the landmark role role="main" with it.
Chapter 3 contains a clear explanation of the purposes and uses of both the <section> and <article> element. If you want, you can include an example of these two elements inside the <main> element.
Remember that <hgroup> has disappeared from the spec.
The example files all show empty elements such as <img> with a closing forward slash included: <img />. This provides a perfect opportunity to talk about backwards compatibility, XHTML, and some of the personal choices that are acceptable when writing HTML5.
I always tell students to use the Web Developer Toolbar developed by Chris Pederick. It’s free, it works in Firefox, Opera, or Chrome and it’s very helpful.
This short video explains a bit about it. Although it’s talking about Joomla specifically and is an ad for Lynda.com, it’s still a good video. You hear Jen Kramer doing the description. It’s almost the same speech that I give students when I introduce them to this tool, so I thought it was worth sharing with you.
For a while now, I’ve been seeing mentions of implicit ARIA roles as something web designers and developers should be aware of and know how to use.
In the case of ARIA roles, the word implicit means that the browser interprets certain HTML elements semantically and treats them as if an ARIA role were assigned to them. In these situations, the web designer does not specifically need to add the role attribute to the element. The addition of the ARIA role is considered redundant in some situations.
If you do add the role information, it does no harm, but, in my opinion, it’s best practice to know when you do need to add it and when you don’t.
For elements that have been around for a while, say the a (anchor) element, the browser implicitly assigns a role="link" attribute.
For the newer HTML5 semantic structural elements, browsers already have some of the roles built in. This improves as browsers add support. A header element that is not a descendant of an article or section element is implicitly assigned role="banner". A footer element that is not a descendant of an article or section element is implicitly assigned role="contentinfo". There are a number of other cases like this as browsers add support for HTML5. They are detailed at the W3C in two tables. This table shows strong native HTML semantics with default ARIA semantics. Just under it, this table lists the default implicit ARIA semantics for many other elements, along with any restrictions that apply.
Students may have a problem grasping is the need for a wrapper div. I frequently find myself explaining it numerous times until the message finally sinks in.
The metaphor I’ll use today will be to compare a wrapper div to a fence.
A wrapper div, or a container div, has no semantic meaning. It’s a generic container. Therefore, <div> is the proper tag. A <section> element should not be used as a container. [See: Sections and Articles are Not Generic Containers]
What does a fence do?
It demarks the edges of your property.
It contains animals or children within a prescribed area. It keeps them from getting out.
It creates a border between one area and another.
It can be plain or decorative.
A wrapper div in an HTML document does the same things but to a layout instead of to actual property.
The wrapper holds a design within certain boundaries.
The various areas of a design cannot escape from the boundaries set by the wrapper.
A max-width or min-width or varying width based on an @media query can be set for the wrapper that makes it size a design responsively.
The id identifying a wrapper provides a CSS hook which enables more than size constraints. Borders and other decorations can be added.
With a wrapper div in place, a layout can be centered on the page. The width of the design can be controlled for easier reading and line-length.
It’s necessary to create the wrapper with a div and an id:
<div id="wrapper">everything on the page goes in here</div>
One of the principles of HTML5 is to pave the existing cow paths. Hence we have all sorts of new semantic elements like header, main, and footer that were once created using the same div with an id technique.
If wrappers are so great, why isn’t there a new HTML5 element called wrapper? I don’t know the answer for sure, but I’m guessing it’s because a wrapper is not a semantic element. It’s merely a container, a boundary into which you place all your semantic content.
By the same token, there is no ARIA landmark role for wrapper or container divs. The container carries no semantic meaning, it just puts a fence around the content. There’s no need to indicate it as a landmark on the page.
There are several choices open to you if you want to bring in your photos from Instagram into a WordPress blog: You can add a badge from Instagram, use embedding, or choose from a number of plugins.
Place an Instagram Badge on Your Site
Sign in to your account on Instagram. There’s a “badges” option in the menu. A badge will put an icon on your site that links to your Instagram URL. It doesn’t bring in any images.
Select a badge type and copy the code. I selected an icon, copied the code, and pasted it into Text view in a post. What showed up was a nifty little Instagram icon that linked to my feed on Instagram.com.
If I wanted this type of Instagram badge on my blog, I’d paste the code into a text widget in my sidebar, near my other social media badges and buttons. It doesn’t make much sense to put this icon in a post, because it will get buried over time.
Embed a Single Photo
You can put a single Instagram photo into a blog post using the Instagram “embed” option. Find the icon showing three dots next to the comment box and click it to see the embed option.
Instagram gives you the option to embed a single photo. Copy that code and paste it into the Text view of your post, and the photo will show up.
Instagram’s embed feature allows you to embed other people’s photos in your blog as well. The link to the original image on Instagram is included in the embed code, and shows up when you hover over the word “Instagram.”
Having this link included with the image skirts copyright problems by linking directly to the photo on the Instagram feed of the creator of the image.
WordPress Plugins
With a plugin, you get more than just an occasional image to insert into a post. There are plugins to create image sliders, to back up your Instagram photos to your WordPress database, or to place a small gallery of photos in your sidebar; others do even more. Most of the plugins below only require your Instagram username to work. The last one I mention gives you the option to set it up using the Instagram API.
DsgnWrks Instagram Importer, according to its description, “will allow you to import and backup your Instagram photos to your WordPress site. Includes robust options to allow you to control the imported posts formatting including built-in support for WordPress custom post-types, custom taxonomies, post-formats.” This plugin also imports Instagram video. When you first launch DsgnWrks Instagram Importer, you can set up the import to filter by hashtags or by date. There are a number of custom tags you can use to control the title and content of imported images.
Instagram Picture provides a way to add Instagram images to almost any position in your blog. You can use shortcodes, widgets, and PHP to insert images with this plugin. Here’s a screenshot from the developer of one of the widget styles you can choose with Instagram Picture. This plugin also has a feature for adding individual image to posts.
Instagram Slider Widget will display a grid of thumbnails like you saw in the image above, but it also has the option to shows up to 20 images in a slider. You can set the number of images to include in the slider and set a time for how often the plugin goes to Instagram to look for new photos. Instagram Slider Widget has an option to insert the images into your WordPress Media Library, which gives you a backup of your Instagram photos.
Alpine PhotoTile for Instagram offers more options than the plugins mentioned above. It retrieves (but does not back up on WordPress) as many as 100 photos. According to the developer, “The photos can be linked to your Instagram page, a specific URL, or to a Lightbox slideshow. Also, the Shortcode Generator makes it easy to insert the widget into posts without learning any of the code. This lightweight but powerful widget takes advantage of WordPress’s built in JQuery scripts.” The lightbox feature on this plugin sets it apart from the others. Alpine PhotoTile for Instagram will insert photos in a page, a sidebar, or a post. Of all the plugins I’ve mentioned, it has the most and best reviews.
The WordPress plugin directory has many, many Instagram plugins; I’ve only scratched the surface with these four. The ones I’ve highlighted all have good reviews. I suggest you look at the number and quality of reviews when you consider any plugin. If you use a plugin yourself, it’s very helpful to the WordPress community (you) if you return to the plugin page and leave a review.
Keep in mind that a widget that doesn’t store your photos in WordPress, but instead reaches out to Instagram to retrieve photos, may experience delays in loading if the Internet is clogged up that day.
Many Instagram plugins allow you to display not only your own photos, but the photos of people you follow or photos with a particular hashtag. If you choose a plugin with that capability, check carefully for the copyright issues involved, and make sure the original creator of the image is linked to the photo. I can definitely see the value of a post with a slideshow based on a particular hashtag, say #blogher14. Enjoy sharing your Instagram photos on your WordPress blog!
GoDaddy Managed WordPress is built from the ground up for maximum performance, security and ease of use. Click here to experience the difference.
