X SEO

The fact that this:

h1 {color: red;}
h1 {color: green;}

…results in green h1 text, but this:

h1 {background:
	url(red-wave.gif) repeat,
	url(green-wave.gif) repeat;}

…results in a red wavy h1 background does my head in every single time. And it’s the same with text and box shadows, too! In cases where backgrounds or shadows overlap, the first one you write “wins”, by virtue of being “in front of” the background images that are listed after it.

I know that font stacks are also done in order of most-to-least preferred, but I don’t see them as being equivalent. The reason is that a font stack is a list of fallbacks—use this face unless it can’t render the glyph or doesn’t exist, in which case try the next one in the list, etc., etc. Multiple background images and multiple shadows, on the other hand, are not a series of fallbacks. I expect to see them all, unless I made a mistake of some kind; and I do, constantly, because of this disconnect. Sure, one could use the multiple background image syntax to create a series of fallbacks—first an SVG file, second a PNG, third a GIF—but that’s not its primary purpose, and I certainly wouldn’t teach multiple background images that way. That’s not what they’re designed to do.

Maybe writing the problem down here will purge this daemon, but in all honesty, my hopes are not terribly high.

I’m working my way through a rewrite of Two Salmon (more on that anon), and I just recently came to the ch unit. Its definition in the latest CSS Values and Units module is as follows:

ch unit

Equal to the advance measure of the “0″ (ZERO, U+0030) glyph found in the font used to render it.

…and that’s it. I had never heard the term “advance measure” before, and a bit of Googling for font "advance measure" only led me to copies of the CSS Values and Units module and some configuration files for the Panda 3D game engine. So I asked the editor and it turns out that “advance measure” is a CSS-ism that corresponds to the term “advance width”, which I had also never heard before but which yielded way more Google results. Wikipedia’s entry for “Font” has this definition:

Glyph-level metrics include … the advance width (the proper distance between the glyph’s initial pen position and the next glyph’s initial pen position)…

My question for the font geeks in the room is this: is that the generally accepted definition for “advance width”? If not, is there a better definition out there; and if so, where? I’d like to be able to recommend the best known definition for inclusion in the specification; or, if there’s no agreement as to the best, then at least a good one. The Wikipedia definition certainly sounds good, assuming it’s accurate. Is it?

In CSS terms, if I’ve understood things correctly, 1ch is equal to the width of the character box for the glyph for “0”. In other words, if I were to create a floated element with just a “0” and no whitespace between it and the element’s open and close tags, then the float’s width would be precisely 1ch. But that’s if I’ve understood things correctly. If I haven’t, I hope I’ll be corrected soon!

It may be that from the ashes of vendor prefixes will arise a new way forward. As proposed by François Remy, vendor tokens would serve the same basic purpose as prefixes with a different syntactical approach, and with at east a couple of extra benefits. Instead of prefixing properties, you’d instead add vendor tokens to the end of a single declaration, much as you do !important (which of course we never ever use, amirite?).

For example, you might write:

border-radius: 1em !webkit-draft !moz-draft !o-draft;

That’s it. The prefixed alternative, of course, runs to multiple lines and has spawned a whole subindustry of framework plugins and mixins and what-all just to take the repetitive authoring burden off our shoulders.

I’ve been contemplating this proposal all morning, and perhaps not too surprisingly I’ve come down in favor of the idea. I’m on record as being a fan of vendor prefixes, but what I was truly a fan of was the capabilities they offer. The syntax was never a core interest for me, and the ugliness was pretty apparent. Vendor tokens are less tortuous, and even make it much simpler to build in versioning, like so:

border-radius: 1em !webkit-draft-2 !moz-draft !o-draft;

Not that I’m saying this proposal will or even should get to that point, but the ability is there and it feels cleaner than trying to do the same thing with prefixes. I feel they ought to drop the -draft part of the tokens; just saying !webkit !moz !o or possibly !x-webkit !x-moz !x-o should be sufficient. I’m also not a fan of the bang, but then I never have been, and I figure any token marker would suffice. As before, it’s not the syntax I care about so much as the capabilities.

There is a discussion ongoing at www-style, if you’re interested in adding your perspective or even just following along as various stakeholders thrash at the idea. I’m cautiously optimistic. It’s kind of a nice feeling!

Linear gradients in CSS can lead to all kinds of wacky, wacky results—some of them, it sometimes seems, in the syntax itself.

Let me note right up front that some of what I’m talking about here isn’t widely deployed yet, nor for that matter even truly set in stone. Close, maybe, but there could still be changes. Even if nothing actually does change, this isn’t a “news you can use RIGHT NOW” article. Like so much of what I produce, it’s more of a stroll through a small corner of CSS, just to see what we might see.

For all their apparent complexity, linear gradients are pretty simple. You define a direction along which the gradient progresses, and then list as many color stops as you like. In doing so, you describe an image with text, sort of like SVG does. That’s an important point to keep in mind: a linear (or radial) gradient is an image, just as much as any GIF or PNG. That means, among other things, that you can mix raster images and gradient images in the background of an element using the multiple background syntax.

But back to gradients. Here’s a very simple gradient image:

linear-gradient(45deg, red, blue)

The 45deg defines the gradient line, which is the line that defines how the gradient progresses. The gradient line always passes through the center of the background area, and its specific direction is declared by you, the author. In this case, it’s been declared to point toward the 45-degree angle. red and blue are the color stops. Since the colors don’t have stop distances defined, the distances are assumed to be 0% and 100%, respectively, which means you get a gradient blend from red to blue that progresses along the gradient line.

You can create hard stops, too:

linear-gradient(45deg, green 50%, lightblue 50%)

That gets you the result shown in Figure 1, to which I’ve added (in Photoshop) an arrow showing the direction of the gradient line, as well as the centerpoint of the background area. Each individual “stripe” in the gradient is perpendicular to the gradient line; that’s why the boundary between the two colors at the 50% point is perpendicular to the gradient line. This perpendicularness is always the case.

Now, degrees are cool and all (and they’ll be changing from math angles to compass angles in order to harmonize with animations, but that’s a subject for another time), but you can also use directional keywords. Two different kinds, as it happens.

The first way to use keywords is to just declare a direction, mixing and matching from the terms top, bottom, right, and left. The funky part is that in this case, you’re declaring the direction the gradient line comes from, not that toward which it’s going; that is, you specify its origin instead of its destination. So if you want your gradient to progress from the bottom left corner to the top right corner, you actually say bottom left:

linear-gradient(bottom left, green 50%, lightblue 50%)

But bottom left does not equal 45deg, unless the background area is exactly square. If the area is not square, then the gradient line goes from one corner to another, with the boundary lines perpendicular to that, as shown in Figure 2. Again, I added a gradient line and centerpoint in Photoshop for clarity.

Of course, this means that if the background area resizes in either direction, then the angle of the gradient line will also change. Make the element taller or more narrow, and the line will rotate counter-clockwise (UK: anti-clockwise); go shorter or wider and it will rotate clockwise (UK: clockwise). This might well be exactly what you want. It’s certainly different than an degree angle value, which will never rotate due to changes in the background’s size.

The second way to use keywords looks similar, but has quite different results. You use the same top/bottom/left/right terms, but in addition you prepend the to keyword, like so:

linear-gradient(to top right, green 50%, lightblue 50%)

In this case, it’s clear that you’re declaring the gradient line’s destination and not its origin; after all, you’re saying to top right. However, when you do it this way, you are not specifying the top right corner of the background area. You’re specifying a general topward-and-rightward direction. You can see the result of the previous sample in Figure 3; once more, Photoshop was used to add the gradient line.

Notice the hard-stop boundary line. It’s actually stretching from top left to bottom right (neither of which is top right). That’s because with the to keyword in front, you’re triggering what’s been referred to as “magic corners” behavior. When you do this, no matter how the background area is (re)sized, that boundary line will always stretch from top left to bottom right. Those are the magic corners. The gradient line thus doesn’t point into the top right corner, unless the background area is perfectly square—it points into the top right quadrant (quarter) of the background area. Apparently the term “magic quadrants” was not considered better than “magic corners”.

The effect of changing the background area’s size is the same as before; decreasing the height or increasing the width of the background area will deflect the gradient line clockwise, and the opposite change to either axis will produce the opposite deflection. The only difference is the starting condition.

Beyond all this, if you want to use keywords that always point toward a corner, as in Figure 2 except specifying the destination instead of the origin, that doesn’t appear to be an option. Similarly, neither can you declare an origin quadrant. Having the gradient line always traverse from corner to corner means declaring the origin of the gradient line (Figure 2). If you want the “magic corners” effect where the 50% color-stop line points from corner to corner, with the gradient line’s destination flexible, then you declare a destination quadrant (Figure 3).

As for actual support: as of this writing, only Firefox and Opera support “magic corners”. All current browsers—in Explorer’s case, that means IE10—support angles and non-magic keywords, which means Opera and Firefox support both keyword behaviors. Nobody has yet switched from math angles to compass angles. (I used 45deg very intentionally, as it’s the same direction in either system.)

That’s the state of things with linear gradients right now. I’m interested to know what you think of the various keyword patterns and behaviors—I know I had some initial trouble grasping them, and having rather different effects for the two patterns seems like it will be confusing. What say you?

I’ve been messing around with native calculated values in CSS, and there’s something a bit surprising buried in the value format. To quote the CSS3 Values and Units specification:

Note that the grammar requires spaces around binary ‘+’ and ‘-’ operators. The ‘*’ and ‘/’ operators do not require spaces.

In other words, two out of four calculation operators require whitespace around them, and for the other two it doesn’t matter. Nothing like consistency, eh?

This is why you see examples like this:

width: calc(100%/3 - 2*1em - 2*1px);

That’s actually the minimum number of characters you need to write that particular expression, so far as I can tell. Given the grammar requirements, you could legitimately rewrite that example like so:

width: calc(100% / 3 - 2 * 1em - 2 * 1px);

…but not like so:

width: calc(100%/3-2*1em-2*1px);

The removal of the spaces around the ‘-’ operators means the whole value is invalid, and will be discarded outright by browsers.

We can of course say that this last example is kind of unreadable and so it’s better to have the spaces in there, but the part that trips me up is the general inconsistency in whitespace requirements. There are apparently very good reasons, or at least very historical reasons, why the spaces around ‘+’ and ‘-’ are necessary. In which case, I personally would have required spaces around all the operators, just to keep things consistent. But maybe that’s just me.

Regardless, this is something to keep in mind as we move forward into an era of wider browser support for calc().

Oh, and by the way, the specification also says:

The ‘calc()’ expression represents the result of the mathematical calculation it contains, using standard operator precedence rules.

Unfortunately, the specification doesn’t seem to actually define these “standard operator precedence rules”. This makes for some interesting ambiguities because, as with most standards, there are so many to choose from. For example, 3em / 2 * 3 could be “three em divided by two, with the result multiplied by three” (thus 4.5em) or “three em divided by six” (thus 0.5em), depending on whether you privilege multipliers over dividers or vice versa.

I’ve looked around the Values and Units specification but haven’t found any text defining the actual rules of precedence, so I’m going to assume US rules (which would yield 4.5em) unless proven otherwise. Initial testing seems to bear this out, but not every browser line supports these sorts of expressions yet, so there’s still plenty of time for them to introduce inconsistencies. If you want to be clear about how you want your operators to be resolved, use parentheses: they trump all. If you want to be sure 3em / 2 * 3 resolves to 4.5em, then write it (3em / 2) * 3, or (3em/2)*3 if you care to use inconsistent whitespacing.

There’s a subtle aspect of CSS descendant selectors that most people won’t have noticed because it rarely comes up: selectors have no notion of element proximity. Here’s the classic demonstration of this principle:

body h1 {color: red;}
html h1 {color: green;}

Given those styles, all h1 elements will be green, not red. That’s because the selectors have equal specificity, so the last one wins. The fact that the body element is “closer to” the h1 than the html element in the document tree is irrelevant. CSS has no mechanism for measuring proximity within the tree, and if I had to place a bet on the topic I’d bet that it never will.

I bring this up because it can get you into trouble when you’re using the negation pseudo-class. Consider:

div:not(.one) p {font-weight: bold;}
div.one p {font-weight: normal;}

<div class="one">
  <div class="two">
    <p>Hi there!</p>
  </div>
</div>

Given these styles, the paragraph will not be boldfaced. That’s because both rules match, so the last one wins. The paragraph will be normal-weight.

“AHA!” you cry. “But the first rule has a higher specificity, so it wins regardless of the order they’re written in!” You’d think so, wouldn’t you? But it turns out that the negation pseudo-class isn’t counted as a pseudo-class. It, like the univseral selector, doesn’t contribute to specificity at all:

Selectors inside the negation pseudo-class are counted like any other, but the negation itself does not count as a pseudo-class.

—Selectors Level 3, section 9: Calculating a selector’s specificity

If you swapped the order of the rules, you’d get a boldfaced paragraph thanks to the “all-other-things-being-equal-the-last-rule-wins” step in the cascade. However, that wouldn’t keep you from getting a red-on-red paragraph in this case:

div:not(.one) p {color: red;}
div.one p {background: red;}

<div class="one">
  <div class="two">
    <p>Hi there!</p>
  </div>
</div>

The paragraph is a child of a div that doesn’t have a class of one, but it’s also descended from a div that has a class of one. Both rules apply.

(Thanks to Stephanie Hobson for first bringing this to my attention.)

Last Thursday, I had the rare honor and privilege of chatting with Jen Simmons as a guest on The Web Ahead . (I’ve also chatted with Jen in real life. That’s even awesomer!) As is my wont, I completely abused that privilege by chatting for two hours—making it the second-longest episode of The Web Ahead to date—about the history of the web and CSS, what’s coming up that jazzes me the most, and all kinds of stuff. I even revealed, toward the end of the conversation, the big-picture projects I dearly wish I had time to work on.

The finished product was published last Friday morning. I know it’s a bit of a lengthy beast, but if you’re at all interested about how we got to where we are with CSS, you might want to give this a listen: The Web Ahead, Episode #18. Available for all your finer digital audio players via embedded Flash player, iTunes, RSS, and MP3 download.

My deepest thanks to Jen for inviting me to be part of the show!

Published this morning in A List Apart #344: an interview I conducted with Tantek Çelik, web standards lead at Mozilla, on the subject of Mozilla’s plan to honor -webkit- prefixes on some properties in their mobile browser. Even better: Lea Verou’s Every Time You Call a Proprietary Feature ‘CSS3,’ a Kitten Dies. Please—think of the kittens!

My hope is that the interview brings clarity to a situation that has suffered from a number of misconceptions. I do not necessarily hope that you agree with Tantek, nor for that matter do I hope you disagree. While I did press him on certain points, my goal for the interview was to provide him a chance to supply information, and insight into his position. If that job was done, then the reader can fairly evaluate the claims and plans presented. What conclusion they reach is, as ever, up to them.

We’ve learned a lot over the past 15-20 years, but I’m not convinced the lessons have settled in deeply enough. At any rate, there are interesting times ahead. If you care at all about the course we chart through them, be involved now. Discuss. Deliberate. Make your own case, or support someone else’s case if they’ve captured your thoughts. Debate with someone who has a different case to make. Don’t just sit back and assume everything will work out—for while things usually do work out, they don’t always work out for the best. Push for the best.

And fix your browser-specific sites already!

Right in the middle of AEA Atlanta—which was awesome, I really must say—there were two announcements that stand to invalidate (or at least greatly alter) portions of the talk I delivered. One, which I believe came out as I was on stage, was the publication of the latest draft of the CSS3 Positioned Layout Module. We’ll see if it triggers change or not; I haven’t read it yet.

The other was the publication of the minutes of the CSS Working Group meeting in Paris, where it was revealed that several vendors are about to support the -webkit- vendor prefix in their own very non-WebKit browsers. Thus, to pick but a single random example, Firefox would throw a drop shadow on a heading whose entire author CSS is h1 {-webkit-box-shadow: 2px 5px 3px gray;}.

As an author, it sounds good as long as you haven’t really thought about it very hard, or if perhaps you have a very weak sense of the history of web standards and browser development. It fits right in with the recurring question, “Why are we screwing around with prefixes when vendors should just implement properties completely correctly, or not at all?” Those idealized end-states always sound great, but years of evidence (and reams upon reams of bug-charting material) indicate it’s an unrealistic approach.

As a vendor, it may be the least bad choice available in an ever-competitive marketplace. After all, if there were a few million sites that you could render as intended if only the authors used your prefix instead of just one, which would you rather: embark on a protracted, massive awareness campaign that would probably be contradicted to death by people with their own axes to grind; or just support the damn prefix and move on with life?

The practical upshot is that browsers “supporting alien CSS vendor prefixes”, as Craig Grannell put it, seriously cripples the whole concept of vendor prefixes. It may well reduce them to outright pointlessness. I am on record as being a fan of vendor prefixes, and furthermore as someone who advocated for the formalization of prefixing as a part of the specification-approval process. Of course I still think I had good ideas, but those ideas are currently being sliced to death on the shoals of reality. Fingers can point all they like, but in the end what matters is what happened, not what should have happened if only we’d been a little smarter, a little more angelic, whatever.

I’ve seen a proposal that vendors agree to only support other prefixes in cases where they are un-prefixing their own support. To continue the previous example, that would mean that when Firefox starts supporting the bare box-shadow, they will also support -webkit-box-shadow (and, one presumes, -ms-box-shadow and -o-box-shadow and so on). That would mitigate the worst of the damage, and it’s probably worth trying. It could well buy us a few years.

Developers are also trying to help repair the damage before it’s too late. Christian Heilmann has launched an effort to get GitHub-based projects updated to stop being WebKit-only, and Aarron Gustafson has published a UNIX command to find all your CSS files containing webkit along with a call to update anything that’s not cross-browser friendly. Others are making similar calls and recommendations. You could use PrefixFree as a quick stopgap while going through the effort of doing manual updates. You could make sure your CSS pre-processor, if that’s how you swing, is set up to do auto-prefixing.

Non-WebKit vendors are in a corner, and we helped put them there. If the proposed prefix change is going to be forestalled, we have to get them out. Doing that will take a lot of time and effort and awareness and, above all, widespread interest in doing the right thing.

Thus my fairly deep pessimism. I’d love to be proven wrong, but I have to assume the vendors will push ahead with this regardless. It’s what we did at Netscape ten years ago, and almost certainly would have done despite any outcry. I don’t mean to denigrate or undermine any of the efforts I mentioned before—they’re absolutely worth doing even if every non-WebKit browser starts supporting -webkit- properties next week. If nothing else, it will serve as evidence of your commitment to professional craftsmanship. The real question is: how many of your fellow developers come close to that level of commitment?

And I identify that as the real question because it’s the question vendors are asking—must ask—themselves, and the answer serves as the compass for their course.

This is a guest post by Gab Goldenberg, author of the advanced SEO book. Get a free chapter on link building here and check out his book affiliate program – the site boasts a 5.5% conversion rate to sale!

Affiliate web design is not only unique because it’s purpose is to generate conversions – in contrast to providing an outlet for frustrated artists – but it has to do so in a limited environment where the conversion has to happen on a third party site. Here are the 10 key web design rules for affiliates.

10. Problem: You need to send the traffic onwards, with minimal bounce rate on the merchant site.

Solution: Therefore, prepare your traffic by including visual elements of the merchant’s landing page on your own site.

Logos are a minimum, but try cropping the hero shot and using that or some stock photo face that’s on the lander… use things people will recognize after clicking through and reassure them this is what they clicked through to see. Only using text links is lazy and less likely to work.

Similarly, either repeat or paraphrase the merchant’s headline with your headline and call to action.

9. Problem: Merchant sites don’t show shipping costs [or other costs, ex.: book clubs, hidden fees] easily. This means people will abandon the cart in higher rates.

Solution: Gather the info yourself and inform your visitors exactly of all charges ahead of time.

8. Problem: Visitors care about the merchant/ the merchant’s product. Not you.

Solution: Provide a value add that encourages people to refer their friends to you. Are your reviews updated periodically? Do they get a bonus if they buy through your affiliate link? (E.g. similar to cashback affs, but you can offer bonuses like info products, tools, stickers, support etc) Do you have some unique value add like BBGeeks.com‘s reviews of network coverage organized by geography?
7. Problem: Your design is intended to yield a sale, once, and once-only.  

Solution: It’s OK to start with pushing your traffic to convert right away, you’re only ever going to get value from that customer once… so you should figure out how to get that traffic into an email (or phone, direct mail, personal contact) list you can monetize repeatedly. Generating leads for the aerospace field? Why not invite leads to your aerospace summer retreat?

6. Problem: Your claims aren’t credible.

Solution: Substantiate them with pics and video. Did you really buy that top fom the Gap? Show a picture of yourself in it with the matching bag. Weight-loss product really work? Show before/after or record yourself doing it, and prove the dates are real with newspapers in your vid.

5. Problem: You’re too enthusiastic about the affiliate product. Every reference to it on your site is linked, the “negatives” in your review are that the merchant is too helpful and generous etc… skeptical consumers don’t click.

Solution: Use one call to action above the fold, and one for every scroll of screen real estate downwards. How many pixels to a scroll? Check your analytics for visitors’ most common screen resolutions.

4. Problem: You overestimate how much persuasion people need and have too much copy.

Solution: Short copy vs long copy depends on several factors, chief amongst which is price and second degree of need. You can get names and emails with a title, picture and 2-3 bulleted benefits. (I once wrote a sales letter with 20 reasons to subscribe to my free RSS feed. Ooops.)

Note: Price includes total price, because people aren’t stupid and get that a $50 monthly subscription is a helluva lot more than a one-time $50 purchase.

3. Problem: You’re starting with visuals/templates as opposed to copy.

Solution: Form serves function. Figure out what you want to do, and create a page (or find a template) that matches that. Don’t start with visuals and then try to fit your copy/ purpose into it. For example, I’ve seen complicated SaaS software trying to sell me on a $50 subscription with hardly any copy on the landing page, because the lander featured a big spot for a hero image / video (which was meant for newbies very unfamiliar with the category of product, and thus didn’t help me) and then some horizontally aligned features with 3 lines of adwords-length copy each.

2. Problem: Your blog posts lack email subscription forms. I don’t mean in the sidebar or in a dhtml overlay-popup. I mean in the post.

Solution: Scott Brinker from IonInteractive.com (no association, though I did get a free review copy of their CRO book Honest Seduction) showed a brilliant type of landing page at Pubcon 2010. He featured a full length article featuring X ways to do Y… and then there was an opt-in form above the fold embedded in the copy, right-aligned, saying “Get 10 more ways to do Y”…

Obviously you can’t do that for every blog post, but your popular posts should have that sort of integration so you get max value out of each post. On the backend, you can need to figure out how to send a custom initial autoresponder if you want all these people on the same list, or you can create multiple duplicate lists.

Another more general way to do this is to have your forms tied to your blog post’s category or tag, in which case you have a general free report for the “seo” category” and another for the “affiliate” category.

1. Problem: Your landing page is leaky. Yes, affiliates have leaks too, not just merchants.

Solution: Get rid of all the extra junk on your landing page. Standard navigation on your product review blog post? Use a WP custom post type with a blank sidebar or comment it out for that page. Use Google Website Optimizer to test the two and watch CTR soar on the nav-free page.

p.p.s. Problem #11: WordPress is your default landing page creation/testing engine. Even using something like Thesis or Affiliate Theme, you’re strongly limiting your ability to test graphics, in terms of layout, hero shots, and more. Either use purpose built testing software that has a built-in landing page creation/editing, or get some graphics and html. I use Bharce for graphics and PSD to HTML/CSS for slicing.

photo credit: Shutterstock/SSGuy

Related posts:

1. Maximizing Profits With Website Design and Layout: Part III In Maximizing Profits With Website Design and Layout: Part I,…
2. How to Mask Affiliate Links How to mask affiliate links is one of the most…
3. Maximizing Profits With Website Design and Layout: Part I I was building new site this past weekend and I…
4. Cloaking Affiliate Links, How and Why Today’s topic is one that gets asked about pretty regularly,…
5. Maximizing Profits With Website Design and Layout: Part II In Maximizing Profits With Website Design and Layout: Part I,…

Advertisers:

1. Text Link Ads – New customers can get $100 in free text links.
2. BOTW.org – Get a premier listing in the internet’s oldest directory.
3. Ezilon.com Regional Directory – Check to see if your website is listed!
4. Need an SEO Audit for your website, look at my SEO Consulting Services
5. Directory Journal – Get permanent deep links in a search engine friendly directory
6. LinkWheel SEO – Get Web 2.0 Backlinks
7. TigerTech – Great Web Hosting service at a great price.
8. Article-Writing-services.org – Article Writing Services creates quality content for websites and blogs at no cost to site owners.
9. Link Building Services – Hire WeBuildLink.com for well-planned advanced link building campaigns. Very affordable. Contact us now for a FREE evaluation.
10. Join 500+ top agencies & publishers who rely on The HOTH every day. US based, enterprise-grade support. High quality, contextually relevant links. 100% money back guarantee. Try it now.
11. Professional website designs – Get a unique brand image with website designs that sets you apart and convert your visitors into customers. Make a brand, not just a website
12. Krystal Glass Whiteboards – Glass writing boards for offices, boardrooms, and classrooms.

This post originally came from Michael Gray who is an SEO Consultant. Be sure not to miss the Thesis WordPress Theme review.

10 Commandments of Affiliate Web Design