Looking for long shadow style icons? Good, then you came to the right place!

Flat design has been continuing virtually unchallenged for some time now, and it’s started to develop sub-styles. One of the most popular new trends is long shadow design, and you’d have to have been living under a rock not to have seen it.

Long shadow design is often abused by trend-chasing designers who want to seem hip, but used correctly and it’s a great tool. This great icon set designed by WebIconSet.com. They provide professional and quality royalty-free stock icons for designers. You can access to over 1,000+ premium icons with an affordable subscription fee. All of the icons are perfect for websites, web applications and wireframes creation. There are 3 types of premium icons including pictograms, stock icons and mini icons, all professionally designed. You can check out their free icons too.

Look at the home icon: the long shadow works perfectly to create a path to the door, a welcoming and enticing effect. Another great use of the long shadow is on the document icon, in which the file seems to push forward into the circle; it’s positive, dynamic and reinforces the message being communicated.

Particularly successful — in addition to the home and document icons — are the cloud, which mimics the shade cast by clouds; the camera, which manages a charming vintage feel; and the settings on which the long shadow creates a strong sculptural form.

As a set of icons they provide a consistent, positive message. The use of the popular circular icon format together with the flat design color scheme mean they’ll fit well with almost any flat design project.

All of the icons are designed using vector shapes in Photoshop, so you can scale them to any size without losing quality.

The whole set is free for personal and commercial use, download the files below the preview:

Have you used this set in a project? Which of the icons is your favorite? Let us know in the comments.

Pay with a Tweet

Download now

Please enter your email address below and click the download button. The download link will be sent to you by email, or if you have already subscribed, the download will begin immediately.

I agree to receive exclusive deals from MightyDeals.com and monthly/weekly newsletters from WebdesignerDepot.com. Unsubscribe at any time. Your email will not be sold/rented.

Bundle Storm: The Bundle of Bundles – only $47!

A question came up in a semi-recent ShopTalk episode about the use of jQuery in tutorials.

Lately I've begun to realize how muddled the line between jQuery and JavaScript has become when learning about the language. It's hard to find a solid tutorial that doesn't include jQuery instead of JavaScript. What's your opinion on the overuse of the library?

The question was from Nick Hehr who wrote about it as well. You can listen to our answer there with this time-jump link.

If you've been reading this site for very long, you know we're a bit guilty of that. I'm not sure there has ever been a tutorial posted here that just used "vanilla" JavaScript (i.e. JavaScript by itself, no framework) rather than jQuery. Or if we have, they are few and far between. Is that a bad thing? I'm not so sure it is. But it is certainly worth discussing.

A little bit later I published an article that covered how to swap out text after an event. I covered five ways to do it. jQuery was used in two of them, vanilla JavaScript another, and CSS for the other two. Including jQuery, even amongst other options, ignited some "that's just overkill" style discussion:

Ah helpful, but there is really no need for jQuery here: Swapping Out Text, Five Different Ways - http://t.co/5gyFGmoCVp

— Smashing Magazine (@smashingmag) July 3, 2013

So here's how I feel about it.

I Write What I Do

This blog is a reflection of things that I learn. I use jQuery a bunch. So when I translate things into a tutorial, I do it how I would do it.

I have only worked on a handful of sites that didn't use jQuery in the last many years, and those that didn't used some other library or just didn't need JavaScript at all.

jQuery is JavaScript

Literally. Using jQuery is still literally writing and working with JavaScript directly. jQuery just makes it easier and lowers the bar to entry. I know loads of good JavaScript developers who started with jQuery. Just like there are loads of good guitar players who started as a Dave Matthews Band Cover Band Cover Band.

Tutorials are Concepts

The goal of a tutorial is to teach an idea and do it fairly succinctly.

Let's say you wanted to select a button with a certain class name and change some text when it is clicked. To avoid any dependancies, maybe you do document.querySelectorAll(".my-button"). But that will return an array so you need to use [0] at the end of it to target the element and attach the event. Or should we just use querySelector instead which selects the first? Or should we run a loop or map over the array to bind to all of them? Or should we have used getElementByClassName? What about browser support? Should we talk about polyfills for that? Or should we just add an ID and use getElementById since that's likely a best practice?

Or, we could just do $(".my-button") and get on with the tutorial. All of that stuff is interesting and worthy of discussion, but not in every single tutorial every single time. jQuery allows the concepts in tutorials to shine without getting bogged down in detail.

The Future

Right now I feel like jQuery is still a pretty important part of the front end stack, well worth learning, and still appropriate to use in tutorials.

But things will change on the web. How JavaScript is presented in tutorials will change as well. Probably. We'll change with it. Probably. I've seen comments floating around the last few months like "I feel like if I'm using jQuery I did it wrong." which I've never heard before and may be harbingers of change. The newschool approaches of Ember/Angular also loom.

The Use of jQuery in Tutorials is a post from CSS-Tricks

“Form ever follows function. This is the law.” So said the architect and “father of skyscrapers” Louis Sullivan. For architects not wishing to crush hundreds of innocent people under the weight of a colossal building, this rule of thumb is pretty good. In design, you should always lead with function, and allow form to emerge as a result. If you were to lead with form, making your skyscraper look pretty would be easier, but at the cost of producing something pretty dangerous.

So much for architects. What about front-end architects — or “not real architects,” as we are sometimes known? Do we abide by this law or do we flout it?

With the advent of object-oriented CSS (OOCSS), it has become increasingly fashionable to “decouple presentation semantics from document semantics.” By leveraging the undesignated meanings of classes, it is possible to manage one’s document and the appearance of one’s document as curiously separate concerns.

In this article, we will explore an alternative approach to styling Web documents, one that marries document semantics to visual design wherever possible. With the use of “intelligent” selectors, we’ll cover how to query the extant, functional nature of semantic HTML in such a way as to reward well-formed markup. If you code it right, you’ll get the design you were hoping for.

If you are like me and have trouble doing or thinking about more than one thing at a time, I hope that employing some of these ideas will make your workflow simpler and more transferable between projects. In addition, the final section will cover a more reactive strategy: We’ll make a CSS bookmarklet that contains intelligent attribute selectors to test for bad HTML and report errors using pseudo-content.

Intelligent Selectors

With the invention of style sheets came the possibility of physically separating document code from the code used to make the document presentable. This didn’t help us to write better, more standards-aware HTML any more than the advent of the remote control resulted in better television programming. It just made things more convenient. By being able to style multiple elements with a single selector (p for paragraphs, for instance), consistency and maintenance became significantly less daunting prospects.

The p selector is an example of an intelligent selector in its simplest form. The p selector is intelligent because it has innate knowledge of semantic classification. Without intervention by the author, it already knows how to identify paragraphs and when to style them as such — simple yet effective, especially when you think of all of the automatically generated paragraphs produced by WYSIWYG editors.

So, if that’s an intelligent selector, what’s an unintelligent one? Any selector that requires the author to intervene and alter the document simply to elicit a stylistic nuance is an unintelligent selector. The class is a classic unintelligent selector because it is not naturally occurring as part of semantic convention. You can name and organize classes sensibly, but only with deliberation; they aren’t smart enough to take care of themselves, and browsers aren’t smart enough to take care of them for you.

Unintelligent selectors are time-intensive because they require styling hooks to be duplicated case by case. If we didn’t have p tags, we’d have to use unintelligent selectors to manufacture paragraphs, perhaps using .paragraph in each case. One of the downsides of this is that the CSS isn’t portable — that is, you can’t apply it to an HTML document without first going through the document and adding the classes everywhere they are required.

Unintelligent selectors at times seem necessary, or at least easier, and few of us are willing to rely entirely on intelligent selectors. However, some unintelligent selectors can become “plain stupid” selectors by creating a mismatch between document structure and presentation. I’ll be talking about the alarming frequency with which the unintelligent .button selector quickly becomes plain stupid.

Vive la Différence

Intelligent selectors are not confined just to the basic elements offered to us in HTML’s specification. To build complex intelligent selectors, you can defer to combinations of context and functional attribution to differentiate basic elements. Some elements, such as <a>, have a multitude of functional differences to consider and exploit. Other elements, such as <p>, rarely differ in explicit function but assume slightly different roles according to context.

    header p {
       /* styles for prologic paragraphs */
    }
    
    footer p {
       /* styles for epilogic paragraphs */
    }
    

Simple descendent selectors like these are extremely powerful because they enable us to visually disclose different types of the same element without having to physically alter the underlying document. This is the whole reason why style sheets were invented: to facilitate physical separation without breaking the conceptual reciprocity that should exist between document and design.

Inevitably, some adherents of OOCSS treat the descendent selector with some suspicion, with the more zealous insisting on markup such as the example below, found in BEM’s “Definitions” documentation.

    <ul class="menu">
      <li class="menu__item">…</li>
      <li class="menu__item">…</li>
    </ul>
    

I won’t cover contextual selectors any further because, unless you have a predilection for the kind of overprescription outlined above, I’m sure you already use them every day. Instead, we’ll concentrate on differentiation by function, as described in attributes and by attribute selectors.

Hyperlink Attributes

Even those who advocate for conceptual separation between CSS and HTML are happy to concede that some attributes — most attributes besides classes and custom data attributes, in fact — have an important bearing on the internal functioning of the document. Without href, your link won’t link to anything. Without type, the browser won’t know what sort of input to render. Without title, your abbr could be referring to either the British National Party or Banco Nacional de Panama.

Some of these attributes may improve the semantic detail of your document, while others are needed to ensure the correct rendering and functioning of their subject elements. If they’re not there, they should be, and if they are there, why not make use of them? You can’t write CSS without writing HTML.

The rel Attribute

The rel attribute emerged as a standard for link relations, a method of describing some specific purpose of a link. Not all links, you see, are functionally alike. Thanks to WordPress’ championing, rel="prev" and rel="next" are two of the most widely adopted values, helping to describe the relationship between individual pages of paginated blog content. Semantically, an a tag with a rel attribute is still an a tag, but we are able to be more specific. Unlike with classes, this specificity is semantically consequential.

The rel attribute should be used where appropriate because it is vindicated by HTML’s functional specification and can therefore be adopted by various user agents to enhance the experience of users and the accuracy of search engines. How, then, do you go about styling such links? With simple attribute selectors, of course:

    [rel="prev"] {
      /* styling for "previous links" */
    }
    
    [rel="next"] {
      /* styling for "next" links */
    }
    

Attribute selectors like these are supported by all but the most archaic, clockwork browsers, so that’s no reason not to use them anywhere the attributes exist. In terms of specificity, they have the same weight as classes. No woe there either, then. However, I recall it being suggested that we should decouple document and presentation semantics. I don’t want to lose the rel attributes (Google has implemented them, for one thing), so I’d better put an attribute that means nothing on there as well and style the element via that.

      <a href="/previous-article-snippet/" rel="prev" class="prev">previous page</a>
    

The first thing to note here is that the only part of the element above that does not contribute to the document’s semantics is the class. The class, in other words, is the only thing in the document that has nothing functionally to do with it. In practice, this means that the class is the only thing that breaks with the very law of separation that it was employed to honor: It has a physical presence in the document without contributing to the document’s structure.

OK, so much for abstraction, but what about maintenance? Accepting that we’ve used the class as our styling hook, let’s now examine what happens when some editing or refactoring has led us to remove some attributes. Suppose we’ve used some pseudo-content to place a left-pointing arrow before the [rel="prev"] link’s text:

    .prev:before {
      content: '\2190'; /* encoding for a left-pointing arrow ("←") */
    }
    

Removing the class will remove the pseudo-content, which in turn will remove the arrow (obviously). But without the arrow, nothing remains to elucidate the link’s extant prev relationship. By the same token, removing the rel attribute will leave the arrow intact: The class will continue to manage presentation, all the time disguising the nonexistence of a stated relationship in the document. Only by applying the style directly, via the semantic attribute that elicits it, can you keep your code and yourself honest and accurate. Only if it’s really there, as a function of the document, should you see it.

Attribute Substrings

I can imagine what you’re thinking: “That’s cute, but how many instances are there really for semantic styling hooks like these on hyperlinks? I’m going to have to rely on classes at some point.” I dispute that. Consider this incomplete list of functionally disimilar hyperlinks, all using the a element as their base:

• links to external resources,
• links to secure pages,
• links to author pages,
• links to help pages,
• links to previous pages (see example above),
• links to next pages (see example above again),
• links to PDF resources,
• links to documents,
• links to ZIP folders,
• links to executables,
• links to internal page fragments,
• links that are really buttons (more on these later),
• links that are really buttons and are toggle-able,
• links that open mail clients,
• links that cue up telephone numbers on smartphones,
• links to the source view of pages,
• links that open new tabs and windows,
• links to JavaScript and JSON files,
• links to RSS feeds and XML files.

That’s a lot of functional diversity, all of which is understood by user agents of all sorts. Now consider that in order for all of these specific link types to function differently, they must have mutually differential attribution. That is, in order to function differently, they must be written differently; and if they’re written differently, they can be styled differently.

In preparing this article, I created a proof of concept, named Auticons. Auticons is an icon font and CSS set that styles links automatically. All of the selectors in the CSS file are attribute selectors that invoke styles on well-formed hyperlinks, without the intervention of classes.

In many cases, Auticons queries a subset of the href value in order to determine the function of the hyperlink. Styling elements according to the way their attribute values begin or end or according to what substring they contain throughout the value is possible. Below are some common examples.

The Secure Protocol

Every well-formed (i.e. absolute) URL begins with a URI scheme followed by a colon. The most common on the Web is http:, but mailto: (for SMTP) and tel: (which refers to telephone numbers) are also prevalent. If we know how the href value of the hyperlink is expected to begin, we can exploit this semantic convention as a styling hook. In the following example for secure pages, we use the ^= comparator, which means “begins with.”

    a[href^="https:"] {
       /* style properties exclusive to secure pages */
    }
    

In Auticons, links to secure pages become adorned with a padlock icon according to a specific semantic pattern, identifiable within the href attribute. The advantages of this are as follows:

• Links to secure pages — and only secure pages — are able to resemble links to secure pages by way of the padlock icon.
• Links to secure pages that cease to be true links to secure pages will lose the https protocol and, with it, the resemblance.
• New secure pages will adopt the padlock icon and resemble links to secure pages automatically.

This selector becomes truly intelligent when applied to dynamic content. Because secure links exist as secure links even in the abstract, the attribute selector can anticipate their invocation: As soon as an editor publishes some content that contains a secure link, the link resembles a secure one to the user. No knowledge of class names or complex HTML editing is required, so even simple Markdown will create the style:

    [Link to secure page](https://payment.example.com/)
    

Note that using the [href^="https:"] prefix is not infallible because not all HTTPS pages are truly secure. Nonetheless, it is only as fallible as the browser itself. Major browsers all render a padlock icon natively in the address bar when displaying HTTPS pages.

File Types

As promised, you can also style hyperlinks according to how their href value ends. In practice, this means you can use CSS to indicate what type of file the link refers to. Auticons supports .txt, .pdf, .doc, .exe and many others. Here is the .zip example, which determines what the href ends with, using $=:

    [href$=".zip"]:before, 
    [href$=".gz"]:before {
       content: '\E004'; /* unicode for the zip folder icon */
    }
    

Combinations

You know how you can get all object-oriented and use a selection of multiple classes on elements to build up styles? Well, you can do that automatically with attribute selectors, too. Let’s compare:

    /* The CSS for the class approach */
    
    .new-window-icon:after {
       content: '[new window icon]';
    }
    
    .twitter-icon:before {
      content: '[twitter icon]';
    }
    
    /* The CSS for the attribute selector approach */
    
    [target="_blank"]:after {
       content: '[new window icon]';
    }
    
    [href*="twitter.com/"]:before {
      content: '[twitter icon]';
    }
    

(Note the *= comparator, which means “contains.” If the value string contains the substring twitter.com/, then the style will be honored.)

    <!-- The HTML for the class approach -->
    
    <a href="http://twitter.com/heydonworks" target="_blank" class="new-window-icon twitter-icon">@heydonworks</a>
    
    <!-- The HTML for the attribute selector approach -->
    
    <a href="http://twitter.com/heydonworks" target="_blank">@heydonworks</a>
    

Any content editor charged with adding a link to a Twitter page now needs to know only two things: the URL (they probably know the Twitter account already) and how to open links in new tabs (obtainable from a quick Google search).

Inheritance

Some unfinished business: What if we have a link that does not match any of our special attribute selectors? What if a hyperlink is just a plain old hyperlink? The selector is an easy one to remember, and performance fanatics will be pleased to hear that it couldn’t be any terser without existing at all.

Flippancy aside, let me assure you that inheritance within the cascade works with attribute selectors just as it does with classes. First, style your basic a — perhaps with a text-decoration: underline rule to keep things accessible; then, progressively enhance further down the style sheet, using the attribute selectors at your disposal. Browsers such as Internet Explorer (IE) 7 do not support pseudo-content at all. Thanks to inheritance, at least the links will still look like links.

    a {
      color: blue;
      text-decoration: underline;
    }
    
    a[rel="external"]:after {
       content: '[icon for external links]';
    }
    

Actual Buttons Are Actual

In the following section, we’ll detail the construction of our CSS bookmarklet for reporting code errors. Before doing this, let’s look at how plain stupid selectors can creep into our workflow in the first place.

Adherents of OOCSS are keen on classes because they can be reused, as components. Hence, .button is preferable to #button. I can think of one better component selector for button styles, though. Its name is easy to remember, too.

The <button> element represents a button.

– W3C Wiki

Topcoat is an OOCSS BEM-based UI framework from Adobe. The CSS for Topcoat’s various button styles is more than 450 lines if you include the comment blocks. Each of these comment blocks suggests applying your button style in a manner similar to this introductory example:

       <a class="topcoat-button">Button</a>
    

This example is not a button. No, sir. If it were a button, it would be marked up using <button>. In fact, in every single browser known to man, if it were marked up as a button and no author CSS was supplied, you could count on it looking like a button by default. It’s not, though; it’s marked up using <a>, which makes it a hyperlink — a hyperlink, in fact, that lacks an href, meaning it isn’t even a hyperlink. Technically, it’s just a placeholder for a hyperlink that you haven’t finished writing yet.

A dog in a shark costume does not a shark make. (Image: reader of the pack)

The examples in Topcoat’s CSS are only examples, but the premise that the class defines the element and not the HTML is deceptive. No amount of class name modification via “meaningful hyphenation” can make up for this invitation to turn your unintelligent selector into a plain stupid one and to just code stuff wrong.

See No Evil, Hear No Evil

“If it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck.”

A link that resembles a button and triggers button-like JavaScript events is, to many, a button. However, this only means that it has passed the first two stages of the “duck test.” For all users to be able to apply inductive reasoning and discern the button as such, it must also quack like one. Because it remains a link, it will be announced by screen readers as “link,” meaning that your allegorical skyscraper is not wheelchair-accessible. Avoiding this kind of unnecessary confusion for assistive technology users is not a pursuit of semantic perfection but a responsibility we should undertake for real benefit.

Nonetheless, some will insist on using a as the basis of their buttons. Hyperlinks are (slightly) easier to restyle consistently, after all. If a is the element of choice, then there is only one way to make it a close-to-true button in the accessibility layer. You guessed it: You must apply another meaningful attribute in the form of a WAI ARIA role. To ensure that a hyperlink element looks like a button for good reason, apply only the following attribute selector.

    [role="button"] {
       /* semantic CSS for modified elements that are announced as “button” in assistive technologies */
    }
    

Quality Assurance With Attribute Selectors

“CSS gives so much power to the class attribute, that authors could conceivably design their own “document language” based on elements with almost no associated presentation (such as DIV and SPAN in HTML) and assigning style information through the “class” attribute. Authors should avoid this practice since the structural elements of a document language often have recognized and accepted meanings.”

– “Selectors,” CSS Level 2, W3C

The reason we have two elements — a and button — is to semantically demarcate two entirely different types of functional interaction. While the hyperlink denotes a means to go somewhere, the button is intended as the instigator of an event or action. One is about traversal, the other about transformation. One facilitates disengagement, the other engagement.

To make sure we don’t do anything too daft and get our links and buttons muddled up, we will now build a CSS bookmarklet that uses intelligent attribute selectors to test the validity and quality of the two respective elements.

Inspired partly by Eric Meyer’s post and taking a few cues from DiagnostiCSS, this style sheet will combine attribute selectors and the :not selector (or negation pseudo-class) to highlight problems in the HTML. Unlike these other two implementations, it will write an error to the screen using pseudo-content. Each error will be written in Comic Sans against a pink background.

By connecting function directly to form, we see that ugly markup results in ugly CSS. Consider this the revenge of an abused document, exacted on its designer. To try it out, drag revenge.css to your bookmarks, and click the bookmark to trigger it on any page that you fancy (Facebook is good):

Rule 1

“If it’s a hyperlink, it should have an href attribute.”

    a:not([href]):after {
       content: 'Do you mean for this to be a link or a button, because it does not link to anything!';
       display: block !important;
       background: pink !important;
       padding: 0.5em !important;
       font-family: 'comic sans ms', cursive !important;
       color: #000 !important;
       font-size: 16px !important;
    }
    

Notes: In this example, we are testing not the attribute’s value, but whether the attribute exists in the first place — that is, whether [href] matches any element with an href attribute. This test is only appropriate on hyperlinks, hence the a prefix. The rule reads like, “For every a element that is not also an [href] element, append some pseudo-content with an error notice.”

Rule 2

“If it’s a hyperlink and has an href attribute, it should have a valid value.”

    a[href=""]:after, a[href$="#"]:after, a[href^="javascript"]:after {
       content: 'Do you mean for this link to be a button, because it does not go anywhere!';
       /*... ugly styles ...*/
    }
    

Notes: If the href is empty, ends in a # or is using JavaScript, it’s probably being used as a button without the correct button element. Note that I am using “starts with javascript.” Standard practice for voiding hrefs is to use javascript:void(0), but we can’t depend on that always being written in the same way (with or without a space after the colon, for example).

Rule 3

“If it uses a button class, it should be a button — at least in the accessibility layer.”

    .button:not(button):not([role="button"]):not([type="button"]):not([type="submit"]):not([type="reset"]):after,
    .btn:not(button):not([role="button"]):not([type="button"]):not([type="submit"]):not([type="reset"]):after, 
    a[class*="button"]:not([role="button"]):after {
       content: 'If you are going to make it look like a button, make it a button, damn it!';
       /*... ugly styles ...*/
    }
    

Notes: In this example, we’re demonstrating how you can chain negation when testing for attributes. Each selector reads like this: “If the element has a class that says it’s a button but it’s not a button element and it doesn’t have the correct role to make it a button in the accessibility layer and it’s not an input being used as a button, then… well, you’re lying.” I’ve had to use [class*="button"] to catch the many Topcoat class variations (62 in total!) that fail to enforce actual buttons on hyperlinks. I’ve noticed that some authors use button-container and the like on parent elements, which is why the a qualifier is included to avoid false positives. You may recognize the .btn class from Twitter Bootstrap, which (if you’ve read the component’s documentation carefully) you’ll know is also unsure about whether links or buttons are buttons.

Rule 4

“If it is an a element with role="button", then it should link to somewhere when JavaScript is off.”

    a[role="button"]:not([href*="/"]):not([href*="."]):not([href*="?"]):after {
       content: 'Either use a link fallback, or just use a button element.';
       /*... ugly styles ...*/
    }
    

Notes: We can be fairly sure that hrefs that do not include one of /, . (usually to precede a file extension) or ? (to start a query string) are probably bogus. Getting links to act as buttons and return: false when JavaScript is on is fine — fine, that is, if they have a page to go to when JavaScript is off. In fact, it’s the only legitimate reason I can think of not to use <button> instead.

Rule 5

“You can’t disable a hyperlink.”

    a.button[class*="disabled"]:after, 
    a.btn.disabled:after,
    a[class*="button"][class*="disabled"]:after {
       content: 'You cannot disable a hyperlink. Use a button element with type="disabled".';
       /*... ugly styles ...*/
    }
    

Notes: Even ancient user agents understand the disabled attribute, so use it with an appropriate element in a compliant way. You can concatenate attribute selectors just as you can concatenate classes: In the last of the three selectors, we’re saying, “If it’s a link that contains the substring button and the substring disabled, then print an error message.” Twitter Bootstrap uses the second form, .btn.disabled, in its style sheet, but not with the a prefix. We’ll only consider it an error if used on hyperlinks.

Rule 6

“Buttons in forms should have explicit types.”

    form button:not([type]):after {
    	content: 'Is this a submit button, a reset button or what? Use type="submit", type="reset" or type="button"';
    }
    

Notes: We need to determine whether buttons within forms have explicit types, because some browsers will treat any button in this context without a specified type as type="submit". We want to be absolutely sure that the form won’t submit if our button has a different purpose.

Rule 7

“Both hyperlinks and buttons should have some sort of content or an ARIA label.”

    a:empty:not([aria-label]):not([aria-labelledby]):after, 
    button:empty:not([aria-label]):not([aria-labelledby]):after, 
    button:not([aria-label]):not([aria-labelledby]) img:only-child:not([alt]):after, 
    a:not([aria-label]):not([aria-labelledby]) img:only-child:not([alt]):after {
       content: 'All buttons and links should have text content, an image with alt text or an ARIA label';
       /*... ugly styles ...*/
    }
    

Notes: Buttons and links that don’t include any kind of direction for their usage — in either textual or graphical form — are pretty bogus. These final two selectors are perhaps the most complex I’ve ever written. For the hyperlink version, the selector reads something like this: “If it is a hyperlink that does not have either an aria-label attribute or an aria-labelledby attribute and it contains only an image as content but this image does not have an alt attribute, then write the ugly error message.” Also, note the use of the :empty selector. Arguably, no element that is not self-closing should ever be left empty.

Ten points to the first person using revenge.css who can tell me where I’ve broken my own rule in this very article. Trust me, the error is definitely there.

Conclusion

The reason I use the kinds of selectors and patterns described above is not to try something different or to have something new to write about. Attribute selectors aren’t, by themselves, anything new anyway. IE 6 is the only browser that doesn’t support them. The reason I use them is because I simply do not have the time or mental capacity to “do” HTML and CSS in parallel. My brain just isn’t good enough for that. The reason I style my page headers with [role="banner"] and not .page-header is because that’s the only way I’ll know — upon seeing the intended visual effect — that I’ve put the navigable landmark in place. How else does one keep track? You can’t just leave it to testing, because then it’s usually too late.

There’s no such thing as semantic CSS. There’s only semantic HTML and its visible form. In this article I have tried to demonstrate that, by coupling the function and form of Web pages directly, you can create mechanisms for reward and punishment. On the one hand, you can set up selectors that invoke visual motifs only when the suitable markup is used. On the other hand, you can query the markup for bad patterns and erode the visual design as a commitment to the underlying ugly truth.

It’s true that not all the styling hooks in your arsenal will likely ever be uniformly semantic or intelligent. Classes are often desirable as polyfills for much needed elements or attributes that have yet to be standardized. That’s how .footer became <footer> and type="text" (with a bunch of JavaScript) became type="url". Other times, they are helpful for doing non-semantic layout scaffolding with grid frameworks and the like.

However, if you are committed to giving CSS its own completely separate logic, then you are bound to create unnecessary arguments between form and function. In this eventuality, only constant vigilance can protect against inaccessibility and invalidity. To make matters worse, trying to manufacture pseudo-semantics purely with classes makes it easy to fall into one of those interminable discussions over what makes a semantic class name. You’ll start spending less time using the remote to control the TV and more time just sitting there, contemplating the remote control held in your hand.

Life is too short.

(al) (ea)

© Heydon Pickering for Smashing Magazine, 2013.

The power of a good visual isn’t just a scientifically well-documented phenomenon; it’s the whole reason our industry exists. Indeed, our existence as a species is largely defined by our sense of sight. What we see, and how we interpret the things that we see, is a major factor in determining our actions and thus, the course of our lives.

You can hear, read, and think about anything at all, any concept, any object, or any person; but you’ll have a harder time understanding it until you’ve seen it.

Have you ever met someone who has never seen snow for themselves? Maybe you are one of those people. The few I’ve met simply can’t comprehend what it is. Oh, they know it’s moisture in the air that got nice and cold, but they don’t get it. I’ve met a few who told me about their first encounters with snow; and I witnessed the sheer wonder, the amazement on their faces at this white stuff that just fell out of the sky. I’ve heard of one or two people in far off countries who had snow described to them, and didn’t believe it. They thought these foreigners were just making it up.

Visual media, such as photography and video, are the closest that we can come to experiencing life elsewhere without going there ourselves. When you add a photo to a website, you’re not just adding pretty pixels. You’re offering your users a miniature experience to go along with whatever you’re selling.

Need I emphasize just how important it is that you pick the right experience?

Photography as design

When I design a content-driven website that needs imagery, I turn to photography over illustration every time. Now, this is mostly because I can’t draw more than a stick figure to save my life —if you’re an illustrator, or have one on your team, then more power to you! I’m jealous.

The right photo can take a good design, and make it great. The right photo can be the solution to the itching in the back of your brain that says, Something’s just missing. But it absolutely has to be the right photo.

Contrast

Because usability comes first, make sure that the photo you integrate into your design has the right kind of contrast. Chances are, you’ll be putting things like text on top of it, and there is nothing more irritating than text you can barely read. I’m looking at you, thin-white-fonts-on-light-backgrounds.

To find the right kind of contrast, start with the obvious: if the photo is light, use dark text or elements, and vice versa. If you want to use light text with a light background, put something dark in between the text and the photo. A subtle drop shadow is usually acceptable.

Quality

Let’s say that you’re making a website for a small restaurant. What kind of photos do you want in the design? Do want a photo taken by somebody who stood across the busy street, and snapped photos with a point-and-shoot camera in their shaky hands? Do you like answering rhetorical questions?

If your client hasn’t had photos of their business and/or products taken by a professional, try to convince them to get that done. Failing that, tell them all about how awesome minimalist design is. Not having photos as a part of your design is better than trying to work with bad photos.

Relevance

A picture might be worth a thousand words, but some words are more relevant than others. This should go without saying, but you need to use photos that have something to do with whatever you’re selling. In the case of the aforementioned restaurant, you’ll want to use photos of the actual business, or their actual food. With this kind of business, stock photos will not do you any good.

When you’re selling something a little bit less tangible, like insurance for example, you can get away with using photos that are more symbolically linked to the product or service in question. Make sure, though, that the symbolism is strong, and easily recognized by your website’s users. Symbols vary from country to country, and culture to culture.

Big images sell

This seems almost a little obvious if you think about it. Bigger images will have a bigger visual impact. I mean, why not?

Well, the lovely people at Econsultancy decided that just thinking about it wasn’t enough. They needed data. They published their findings in three case studies, which you can read here.

Photography as content

Photos aren’t just great for completing a design, of course, they also make great content, especially when they are paired with non-visual content such as text or audio. This can serve one of several purposes:

Drawing attention

An eye-catching image can be used to represent an article or page, drawing the user’s attention to the content in question. When confronted with large blocks of text, especially online, the human brain tends to start skimming over it, instead of reading it in detail.

Photos can break up the visual monotony, and help users to identify an article, link, story, or what-have-you that they might be interested in. If you remember anything from this article, remember this: imagery makes people stop and pay attention.

Context

Photos can provide the user with visual context for a text-heavy page, article, or audio file. Visual context may consist of things like a picture of the author, a picture of a place mentioned in the text, and so on.

Be careful when choosing a photo to provide context. The photo you choose will likely set the reader’s entire mood, so make sure that the mood of the photo fits the mood of the article.

Other considerations

Permission

If a photo’s not yours, or doesn’t belong to the client, then make sure that you have permission to use it. Get that permission in writing if you can, and always, always credit (and link back to) the photographer unless they have specified otherwise.

It doesn’t take that much work to plan ahead, and ask for their permission in advance. Still, there are ways to avoid that. This brings us to stock photo sites.

Stock Photos: free or paid?

The advantage of stock photo sites is that you never have to wonder where you stand when it comes to permission. Better still, there are a bunch of sites where you can get great stock for free. But, you may also want to look into paying for your stock photos, especially when you’re picking photos to be used as part of a site’s design.

Free Stock Photos – Advantages:

• Free. Seriously, it’s hard to beat that.
• There’s a large selection of good ones out there.

Free Stock Photos – Disadvantages:

• There are also a lot of bad ones. You may have to sort through a lot of trash to get the photos you need.
• You may never find what you need. Sometimes you need something very specific that isn’t there.
• Permissions vary. Some photos will require an attribution link, which may be less than ideal in a design.

Despite the disadvantages, free stock photos are often the way to go. I’ve found the best ones at stock.xchng, StockVault, and with some considerable searching, DeviantArt. (Happy hunting!)

Paid Stock Photos – Advantages:

• If you buy a photo, then you have all the permission you need, usually.
• More varied, more (and sometimes weirdly) specific photos.

Paid Stock Photos – Disadvantages:

• Well… the money. I mean, stock photos are getting pretty cheap these days, but that just makes them like songs on iTunes. When they only cost a dollar, it’s so easy to just buy “one more”.

There are myriad paid stock sites, so it really depends on which one has the photo you want. You could always start with some of the more popular sites: Shutterstock, iStockphoto and Dreamstime.

Photos of people

Lastly, we must consider photos of people. Never, ever use stock photos of people in your design (at least, not if they look like stock photos). They may as well be mannequins for all the feelings of authenticity that they invoke.

Use photos of real people, the people behind a product or service. Show them at work, preferably. If the products being sold are meant to to be worn, pictures of models wearing said items are also acceptable.

But photos of random people blinding the user with their unnaturally white teeth are pointless unless you’re advertising a dentist. Even then, you could probably be more original.

In conclusion

Be careful when choosing the photos you use in your design and content. Make sure to budget in enough time to find the right photos, because the process can take a while. Don’t settle for anything less than a great photo.

What tips would you add for using photos in design? Do you use stock photos or take your own? Let us know in the comments.

Featured image/thumbnail, photography image via Shutterstock.

The Ultimate All-In-One Video Converter for PC or Mac – only $14

Those who make peaceful revolution impossible will make violent revolution inevitable.  

~JFK

Like most, We initially expressed great disappointment after the ouster of Egypt’s first democratically elected president Mohamed Morsi on July 3, 2012.  We feared that Egypt, in the nascence of its democratic experience, had set a disastrous precedent for its political culture; however, We do believe that there was no way to avoid what transpired on that significant day.

As the Economist puts it, “Majoritarianism – the credo of an expanding group of elected but autocratic rulers around the world, which holds that electoral might always makes you right—is not true democracy, even if, on the face of it, the two things look alike.”

Yes – Morsi was democratically elected. To be specific, by 13 million votes. Democratic, right?

Well, it’s more complicated than that.  22 million people signed a petition started by the grassroots opposition movement Tamarod (“Rebellion” in Arabic) urging President Morsi to step down from the presidency – almost double the amount that voted him into office.

Which is truly the voice of the people? Being elected to office by a “majority” does not simultaneously create a just, democratic rule.

Perhaps no single event illustrates this best than in November of 2012, five months after Morsi was elected into office, when he gave himself sweeping new powers which placed him and his executive decrees/orders above judicial review and the constitutional court. As one Al Jazeera contributor put it, this was the only coup that happened in Egypt, and it was executed by Morsi.

There has never been a concrete definition for democracy.  Throughout history, the characteristics of practiced democracy have been as varied as the regions of the world they were practiced in.  However, the system of checks and balances has always gone hand in hand with democracy, from Ancient Greece to modern times.  Morsi’s decree made void any check or balance of power that may have previously existed. 

Democracy is also categorized by civil freedoms, namely, freedom of religion and freedom of the press.  More journalists were jailed under Morsi’s one year tenure than under the ousted autocrat Hosni Mubarak’s 30 year rule. Bassam Youssef, an Egyptian satirist who runs a show called al-Bernameg, which is often likened to Jon Stewart’s “Daily Show,” was arrested for allegedly insulting the president and Islam. 

Can you imagine if Jon Stewart were jailed for criticizing President Obama?

(Unfortunately, restrictions on press seems to be a broader trend in the political culture of Egypt.  Even the military, viewed widely as a secular institution,  closed down various media and news outlets within Egypt promptly after Morsi’s ouster). 

Our founding fathers were scared of what minorities would be subject to at the whim of the majority. Protection of minorities is so embedded in the democratic process that it is often overlooked, but it cannot be in the case of Egypt.

Morsi’s hastily approved constitution (which many judges and elected officials boycotted to express their disapproval) only protects those belonging to “heavenly religions” to practice their religion publicly.  There is no constitutional protection for Egypt’s Bahai minority.  Even with the constitutional guarantee for Muslims and Christians, Egypt’s Coptic Christian community (approximately 10% of the population) and Shia minority face constant physical and mental intimidation and discrimination. 

In recent weeks, the more extreme supporters of Morsi, self-dubbed as “supporters of legitimacy,” have called for the destruction and defacement of Coptic owned stores, homes, and churches.  Many pro-Morsi supporters have heeded the call, with acts ranging from spray painting “Islamic” on Coptic properties, to dragging nuns through the streets, to burning churches.   Copts, seen by many pro-Morsi supporters as one of the main coup-encouraging groups, have faced unprecedented violence since Morsi’s removal.   

Upon entering office, Morsi banned the National Democratic Party – Hosni Mubarak’s party – from political practice. In a democracy, you cannot exclude your opponents from the political process.  Even now as military leaders and the interim government arrest senior Muslim Brotherhood members and debate the dissolution of the Muslim Brotherhood and their political arm, The Freedom and Justice Party, the current violence is indicative of the following chaos that would undoubtedly overcome Egypt.  Egypt’s path forward must be all inclusive – religious minorities, secularists, military leaders, ultra-conservative parties (such as Al-Nour), and the Muslim Brotherhood.  A difficult feat indeed, but a necessary feat nonetheless.  As history shows, when groups are excluded from the political process, there are violent and chaotic ramifications. 

Living conditions – call it “the icing on the cake.”  On top of political polarization, religious tension, and a yearning for civil freedoms, power outages are chronic, shortages of fuel are commonplace, and higher food prices have driven up Egypt’s inflation rate to a two year high. Robberies, kidnappings, and murders all dramatically increased during Morsi’s one year tenure, yet nothing was done to build on the capacity of the police force as an institution. As it stands now, they are inadequate at best. 

These concerns are shared amongst all Egyptians, regardless of political affiliation, and regardless of religion.  The current war-like state on the streets of Egypt’s capitol will only worsen the pitiful living conditions in the land of the pyramids. 

As the international community goes through the cliché process of holding press conferences “strongly condemning the violence in Egypt” and calling on “all parties in Egypt to come to the negotiating table for a peaceful dialogue,” it would do them well to bear in mind how lack of international involvement and support has played out in Syria. 

There is an important distinction to note between politics stateside and politics abroad, a distinction that many of us take for granted. 

Regardless of who is president of the US, though some may be loath to admit, our lives do not change that much, and that is the simple truth.  Sure, you may pay a little more taxes or save more money, but your general welfare isn’t threatened.

This is not the case for Egypt and much of the rest of the world.  When elected officials change, their lives may change, for better or worse.