Rachel Andrew has a new project to record some of the early histories of underrepresented folks from the web development world. She calls the project Web Histories. I was delighted that she called on me to tell my story.
Rachel explains that she, “intends this site to become a place to gather the stories of the efforts to create an open web. I’m starting with some of the early stories.” She provides a way for you to participate by taking a survey about the early history of the industry.
I seldom get recognized or remembered in the web design world, so I’m grateful to Rachel for thinking of me and including me in the project.
The first 50 people to sign up for the Web Design from the Ground Up course at Udemy using the special code webteacher.ws will receive access to the class absolutely free. This is a class for beginners. Here’s what you’ll learn:
Over 38 lectures and 9.5 hours of content
Introduction to HTML and XHTML including the most commonly used elements like linking
Introduction to CSS (Cascading Style Sheets) for working with fonts, colors, and complete layout control
Web Graphics and Image manipulation with an introduction to Photoshop
Introduction to JavaScript with practical applications including script tags, alert boxes, form validation, and much more
Domain name registration – how it works, pointing your domain to your site, best practices and much more
How to put your site on the Internet, including choosing a web host, working with FTP, and much more
Accessibility – make your site visible to all users
Ecommerce with PayPal – setting up a shopping cart, integrating PayPal, making money with your site!
That’s a lot for 10 hours, so I’m guessing it will be basic info, but that’s what a beginner needs, isn’t it?
Many thanks to Udemy for making this special offer available to Web Teacher readers.
Guideline 1.1 Text Alternatives: Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language.
Among those text alternatives is where alt text (or alternative text) for an image is used.
The HTML5 specification states that all images must have an alt attribute. Here’s the fine print. All images must have an alt attribute, but there are times when the alt attribute can be empty or null. That is, the attribute has to be there, but there might be nothing in it. Like this:
<img src="image.png" alt="">
When is null alt text acceptable?
There are times when the text surrounding an image gives the alt text of the image. It’s part of the content. Therefore, to put the same information in an alt attribute becomes redundant and unnecessary.
Here’s an example from the blog Old Ain’t Dead in the section where the most popular posts are displayed. Alt text is shown using the tools in the Web Developer Toolbar.
You can see that the alt text for the image is exactly the same as the link text that goes with it. On a screen reader, a user would have to listen to the same text read twice. It would be better if these images had null alt text because the function of the link is explained by the text accompanying it.
Look at how Twitter deals with null alt text.
If the alt text for Twitter avatars was not null, but in fact contained the name of the Twitter account, then the name would be spoken twice in a screen reader. In the example above, with null alt text, you would hear “Jeffrey Zeldman” spoken once only because of the null alt text.
Even if you couldn’t see the little profile image, you’d still know it was Jeffrey Zeldman’s twitter account.
What about when images are not loaded or otherwise not displayed by the browser?
If you consider the two examples already mentioned – the list of top posts and the Twitter avatars – in neither situation would null alt text on the image result in the user becoming confused. The information is there in text form and it’s all that is needed.
What if the text surrounding the image does not explain what the image is?
In that case, put a description in the alt attribute that explains the function of the image or provides the content of the image.
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.
@jsutt The post only needs to be this long: “Use it only when you really, purposefully want to strip away the HTML semantics.” /cc @vdebolt — Denis Boudreau (@dboudreau) September 17, 2014
@jsutt on 2nd thought, a caveat: If you’re unsure what purposefully stripping away semantics means, then you can never use it. /cc @vdebolt
As you see, this ARIA role has specific and limited use. I wasn’t sure where a front end developer who was only working with semantic HTML would even consider using it.
@dboudreau@jsutt Okay. So it’s used in apps more than in POSH docs. Now it’s starting to make some sense.
Oh, at last the light dawns. This is what developers building apps sometimes need to do. Even at that, go back to point one about only using it when you really know what you’re doing and are absolutely sure you want to strip an element of its semantics.
Denis draws us to a sensible conclusion.
@vdebolt Don’t like the output? Just change the markup instead of hiding the semantics under a presentation role. /cc @jsutt
Everything I said about pedagogy and color coding in the review of the JavaScript book applies to this book as well. In fact, this book is where the author first honed the techniques used in presenting information so simply and clearly.
Simple illustrations with color coding and annotations for every point are used to teach the coding rules.
The reference pages are also color coded, with HTML shown in blue and CSS in pink as well as results examples.
As with the JavaScript book, all the code is downloadable. And, as with the JavaScript book, the language used to explain each concept is exceptionally clear and simple. Here’s a quote from the page introducing CSS.
CSS Associates Style Rules with HTML Elements
CSS works by associating rules with HTML elements. These rules govern how the content of specified elements should be displayed. A CSS rule contains two parts: a selector and a declaration.
The book went completely through all the HTML it included (page structure, text, lists, links, images, tables, forms, audio and video and a few other bits of HTML) before getting to any CSS. Normally that would bother me, but it worked in this book. The CSS part of the book included color, text, boxes, lists, tables, forms, layout, images and some info on layout using HTML5.
Where the book is a little out of date is the information about HTML5. It’s no fault of the author, it’s just that the book came out in 2011. A few things are included (like hgroup or codec issues with video elements) that have gone away, and a few things that are more recent (like the main element) didn’t get mentioned. I reduced the star rating on the book because of that, but if I’d seen the book and reviewed it 4 years ago, I would have given it 5 stars. I simply want anyone who buys and uses it now to be aware that small parts of the book in the HTML 5 descriptions are different now. The book is still a perfectly good way to learn HTML and CSS – in fact, the book is an excellent way to learn HTML and CSS.
A review by Virginia DeBolt of HTML & CSS: Design and Build Websites (rating: 4 stars). The rating is based not on the quality of the book but on the fact that some of it is a little out of date.
Summary: Detailed, careful, guide to HTML, CSS and more.
Disclosure: I received a free copy of this book from the publisher for this review. Opinions are my own. Here is my review policy. Links to Amazon are affiliate links. You can buy the book from Wiley, as well as Amazon. The link to Wiley is not an affiliate link.
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.