CSSnewbie

Become a Blogging Master

Everyone blogs for different reasons. Some simply do it for the joy of writing. Others blog to promote a product or service they’re hoping to sell. Some do it for the exposure to a mass audience, while others write for a close circle of family of friends. And still others are hoping that blogging will prove to be a means to an end, a chance at moving into a new career where they’re their own bosses.

Whichever one of those reasons you’d attribute to yourself, one thing is probably true: you’d love it if your blogging habit would pay for itself. And hey, if your blog made you some extra spending money on the side too… well, that’d be icing on a pretty darn cool cake, wouldn’t it?

But how do you start making money with your blog? The only people who can jump into income-producing blogging without a good deal of planning and understanding are those who are already famous in another genre (Drew Curtis of Fark.com wouldn’t need to work to create a popular blog; his blog would be popular by virtue of his being Drew Curtis). If you’re not already a pseudo-celeb, where do you go?

For the rest of us, there’s Yaro Starak’s Blog Mastermind online course. In this course, Yaro walks his students through the process of learning to blog the way he does. And trust me – you want to learn to blog like Yaro. He’s been making anywhere from $10,000 to $35,000 per month for the last couple of years by blogging.

And Mr. Starak didn’t come into the blogging scene as a celebrity superstar, either. He simply writes good content, promotes it well, varies his income sources (for security), and brings in visitors. And now, he’s willing to share how he does it with the rest of us.

If you’re a veteran blogger who has had trouble generating income in the past, there is probably no better place you could go to learn the secrets of the trade. There are a lot of so-called gurus out there, but Yaro has the knowledge – and the income – to back up his claim.

And if you’re new to blogging, the Blog Mastermind course is a fantastic way to enter the scene with all the knowledge necessary to start off on the right foot and build a successful blog as quickly as can be done.

Best of all, the Blog Mastermind course is surprisingly affordable: just $97 buys you a month’s worth of access to this 6-month course. If you like what you see after a month, you can stay on for the long haul and pay the same price ($97) for the remaining 5 months of the course. Or, if you’d like to save a little cash, you can pay for all 6 months up front and save $85.

If you’re new to blogging, $97 may sound like a large chunk of dough… but you have to think about this sort of thing as an investment. Even if the information you gain teaches you how to create a blog that generates just $100/month, you’ll have made back your money in under six months. And several of Yaro’s previous students are doing much better than a paltry Benjamin per month: check out this interview with one of his past students, who is now making well over six figures a year from his blog.

If you’d like to learn more about Yaro’s teaching style and techniques, check out this video he’s released on Conversion Blogging, one of the cornerstones of how he’s built such a successful blogging enterprise. It will give you a clue both into Yaro’s exceptional teaching ability, as well as give you a glimpse at the quality of content you’ll be getting in the course.

Or, if you’re already convinced, you can sign up for Blog Mastermind here. This course won’t stay open forever, so don’t miss your chance!

Hiding Content in Your RSS Feed

I’ve been doing a bit of research lately on creating RSS-only content for my website – that is, content that shows up in my RSS feed and nowhere else. My research has a specific purpose: I’m planning to start a contest on CSSnewbie in the very near future. The contest would by available only to people who subscribe to my RSS feed, meaning I’d need to provide some sort of clue or password in my RSS, but nowhere else.

My searching has lead me to two very nice Wordpress plugins that should do the job that I need to do. I’ve also come up with a way to accomplish the same feat using just HTML and CSS.

The first Wordpress plugin I came across is called RSS Footer (you can find RSS Footer here). It’s a simple plugin, originally written in order to include some sort of a copyright message at the top or bottom of your RSS entries. This in itself probably wouldn’t be a bad idea – there’s a lot of websites out there that simply grab random articles with certain keywords from other sites and display them as their own. I know that a lot of CSSnewbie articles, for example, end up on other sites.

However, it occurs to me that this plugin could also be used to insert some sort of a “secret” message to your RSS subscribers. Just install the plugin, write your message, and the plugin will automatically bypass your website’s content and insert your message into the RSS feed, before it gets shipped off to the end user (or to services like FeedBurner). Viola! Instant contest.

Or, if you’d prefer a little more flexibility in your options, the Feed Footer Wordpress plugin might be a better way to go (get a copy of Feed Footer here). Feed Footer is similar to RSS Footer, in that it allows you to insert arbitrary content into your RSS feed before your users or FeedBurner see it. However, Feed Footer’s solution is a little different. When using Feed Footer, you cannot insert your content into the top of your RSS entries – it has to appear at the bottom (hence “footer,” I suppose). However, instead of a single boilerplate message, you can include up to ten different messages in your feed, which will rotate through as you add new articles to your website.

There are many benefits to this option, not the least of which as it relates to advertising. Using Feed Footer, you could insert several different advertisements into your RSS feed and have them rotate through. But there are also benefits as it relates to our contest idea: you needn’t give the same clue/password/whatever on the same two days. In fact, maybe only one out of every three blog posts even has a clue, requiring your subscribers to stay subscribed (and active) for long enough to find the message.

But what if you aren’t using Wordpress, or feel like a plugin might be overkill in this situation? Well, there’s another option out there, an HTML- and CSS-only option.

This idea takes advantage of the fact that, unlike screen and print versions of your website, your RSS feed tends to be unstyled – all those fancy CSS rules you write for your website get stripped away when readers use the RSS feed instead. Normally, I see that as a bit of a downside, but in this instance, it’s perfect for what we want to do.

In this scenario, our “secret message” is included as part of the regular article. We just do our best to ensure that only those who are meant to see it (i.e., the RSS readers) ever do.

We’ll start by giving our secret message a CSS class, something like “rssonly” or the like:

<p class="rssonly">Be sure to drink
your Ovaltine!</p>

Now, all we need to do is create a CSS rule that ensures that the message we’ve written doesn’t see the light of day in normal circumstances:

.rssonly {
	display: none; }

That’s really the fundamentals of it right there. Be sure to add the class to both your screen and print stylesheets (assuming you have both). This will prevent the text from showing up on the screen or page, but it’ll be plain as day in your RSS feed.

Of course, what’s to stop some unscrupulous soul from looking at your website’s source code and divining the answer without having to subscribe to your feed? Not much at all, that’s what. Although, you could make the quest a little more difficult by encoding your message by converting your text to its ASCII equivalents. All you need to do is find a simple text-to-HTML-ASCII converter online, type in your message, and then copy the resulting HTML codes into your page. For example, when converting our secret message above, we get something like this:

<p class="rssonly">&#66;&#101;
&#32;&#115;&#117;&#114;
&#101;&#32;&#116;&#111;&#32;
&#100;&#114;&#105;&#110;
&#107;&#32;&#121;&#111;
&#117;&#114;&#32;&#79;
&#118;&#97;&#108;&#116;
&#105;&#110;&#101;
&#33;</p>

When displayed on the screen (in, say, an RSS feed), the content would be perfectly readable. But it looks like an awful lot of gibberish if you’re just viewing the source code. And sure, someone could still take the time to decode your ASCII entities and avoid subscribing to your RSS feed that way. But really, if they’re willing to do that much work up front, I think I’m okay with that. :)

I’m not yet sure which of these options I’ll be using in my own contest. Do you have any other Wordpress or homegrown solutions that you know about? If so, I’d love to hear about them in the comments. I’ll be announcing more about this upcoming contest in the next week or thereabouts, so you might want to subscribe to my RSS feed now so you don’t miss any of the details!

Great Resources Elsewhere: July 18 to July 24

4 Ways CSS Can Improve Your SEO

We all know the overt benefits of using CSS by now – being able to centrally locate all of our presentation, the ability to replicate design changes instantly over an entire website, and so on. But not everyone is sold on such details. These days, a lot of people are more interested in SEO (Search Engine Optimization, or making your pages look good in search engines) than anything else. So what happens if you have a client or an employer whose mantra is more along the lines of, “SEO at any cost, CSS be damned”?

Well, I have some good news for you! Using CSS (and its trusty sidekick, XHTML) is actually very beneficial to your SEO standings. Below, I’ve outlined four different ways that using CSS can help you improve your search engine optimization. Some of them happen automatically, while others require you make decisions.

Streamlined XHTML

In the world of SEO, size and location matter. If your page is significantly long, the content towards the bottom of your page won’t rank as “important” as the stuff at the top. And here’s the important part – the “length” of the page is determined not by the amount of content (text, etc), but by the quantity of code. If Google has to read through a few hundred lines of nested tables constituting your top navigation before it ever gets to your content, then you’re running the risk of the search engines considering the real guts of your website insignificant.

Organized Code

Sure, your table-based design might look just fine and dandy on the screen, but when it comes to search engine optimization, it’s what’s underneath that really counts. Search engines don’t scan your page visually… they piece together a “picture” of your site based on the code. And you may discover that your table-based design doesn’t “read” quite the way you expected.

Take the image above, for example. A search engine would read this page just like any other table: from top left to bottom right. It would read everything in the header, everything in the navigation, and everything in the sidebar before it gets to the content. And if your navigation and sidebar are the same on every page, you’re going to take a negative hit in search engines for having a lot of duplicate content up front.

Luckily, when you’re working with CSS, you can organize your code any which way you choose. You can make sure your valuable, keyword-rich content is right up near the top of your XHTML, and push your sidebar into a div down below your content area. Your CSS can put your sidebar anywhere you want or need visually… and it won’t change Google’s reading of your website one iota.

Headings Make a Difference

As mentioned previously, when you’re worried about SEO, you should be worried about your code. It’s what’s underneath that counts when it’s a search engine browsing your page – the visuals matter not a whit. To that end, make sure you’re using good, old-fashioned heading tags (<h1> - <h6>) for all of your documents headings instead of just styling paragraphs or some other element with *shudder* font tags, or even CSS.

You don’t like how the third-level heading looks just above your article? Well, Google thinks it looks delicious, so maybe you should reconsider. Just whip out your mad CSS skills and style that heading to look like… well, like whatever you want! Google doesn’t mind if your headings are 30-points tall and fuchsia (even if your other readers do).

Choose Your Emphasis

Headings aren’t the only things that affect your SEO. Search engines also pay attention to a few other tags when determining what the “important” words on a page are. For example, Google tends to treat words wrapped in <strong> and <em> tags as being more significant that their surrounding text. That’s why you’ll sometimes see pages with randomly bold-faced or italicized word strewn about – they’re trying to boost their SEO by helping Google find the keywords they want to focus on.

But who’s to say that those keywords need to be visible to everyone? We could always use CSS to ensure that search engines like Google and Yahoo understand which words are important, without having to annoy our readers with our strong-em soup. If we just take some XHTML like this:

<p>This sentence contains several
<strong>keywords</strong> of
<em>significant importance</em>.

Append it with a new “SEO” CSS class:

<p>This sentence contains several
<strong class="seo">keywords</strong> of
<em class="seo">significant importance</em>.

And then write a simple CSS rule like this:

em.seo, strong.seo {
	font-weight: normal;
	font-style: normal; }

This CSS will prevent your SEO-purposed strong and em tags from being bold-faced or italicized on the screen. However, search engines will still recognize the significance of those tags.

CSS and SEO, living together in perfect harmony. Who says you can’t have your cake and eat it too?

Great Resources Elsewhere: July 11 to July 17

Six Ways to Style Blockquotes

The blockquote XHTML tag is a fairly useful (if somewhat underused) element. Semantically speaking, a blockquote should be used any time you’re quoting a longer piece of text from another source – another speaker, another website, whatever. It’s a way of setting the text apart, and showing that it came from some other source. Stylistically, you could accomplish all this with a special class on your paragraph tags… but that wouldn’t be as semantically useful, now, would it?

Blockquotes do have some styling by default. Most browsers will indent the text in a blockquote tag, which helps the user recognize that the text is different somehow. But who’s to say that we need to stop there? Here are six different ways you could style your blockquotes using CSS.

Color and Borders

Applying a color change to the text and adding a border (along with some additional margins and padding) can really make the blockquote stand out, yet is subtle enough to retain a hint of sophistication.

blockquote {
	margin: 1em 3em;
	color: #999;
	border-left: 2px solid #999;
	padding-left: 1em; }

Background Colors

If you’d like something a little more obvious than just a text color change, you might considering altering your background color instead. This causes the blockquote to “pop,” making it immediately more noticeable. When applying background colors, be sure to account for any tags inside that might alter your margins (such as paragraph tags).

blockquote {
	margin: 1em 3em;
	padding: .5em;
	background-color: #f6ebc1; }
blockquote p {
	margin: 0; }

Background Colors and Borders

Of course, we’re not just limited to either-or, here. A background color in addition to a border in a complementary color is a nice effect, particularly on sites that are a little bit more “glossy.”

blockquote {
	margin: 1em 3em;
	padding: .5em 1em;
	border-left: 5px solid #fce27c;
	background-color: #f6ebc1; }
blockquote p {
	margin: 0; }

Background Images

We’re also not just limited to colors! Many websites make use of background images in their blockquotes to help distinguish them from the surrounding text. The background image might appear below the text, or perhaps off to the side (like we’ve done here) by way of a wider left padding.

blockquote {
	margin: 1em 20px;
	padding-left: 50px;
	background: transparent url(quote.gif) no-repeat; }

Drop-Caps and Styled Lines

Borrowing from my Book-Style Chapter Introductions article, we can also distinguish our blockquotes by using drop-caps, stylized text, or (in this example’s case) both at the same time. Here, we’re making use of the first-letter and first-line pseudo-classes, so browser support may not be 100% in older browsers.

blockquote {
	margin: 1em 2em;
	border-left: 1px dashed #999;
	padding-left: 1em; }
blockquote p:first-letter {
	float: left;
	margin: .2em .3em .1em 0;
	font-family: "Monotype Corsiva", "Apple Chancery", fantasy;
	font-size: 220%;
	font-weight: bold; }
blockquote p:first-line {
	font-variant: small-caps; }

Text and Color

Or, if you’d rather go the subtle-but-effective route, you might consider altering the color of the text in the blockquote, as well as the font style or variant. Also in this example, I’m making use of the :before and :after pseudo-classes to insert content into my document – namely, the quotation marks at the beginning and end of the text. Of course, :before and :after aren’t supported by all browsers, so… caveat emptor, and all that.

blockquote {
	color: #66a;
	font-weight: bold;
	font-style: italic;
	margin: 1em 3em; }
blockquote p:before {
	content: '"'; }
blockquote p:after {
	content: '"'; }

You can see all of these examples live here. And if you’ve seen any other great examples of well-styled blockquotes in the wild (or just have a wild idea yourself), I’d love to hear about them: leave me a comment!

Great Resources Elsewhere: June 27 to July 10

New to CSS? New to CSSnewbie? Start Here!

I get a great many reader comments that read something like this: “Your site is the best CSS resource on the web (okay, maybe I’m embellishing slightly here), but where do I start if I’m new?” And that’s a fantastic question. If you’re new to the site, it can be tough to find your way around at first. So here is a collection of articles to get you started. I’ve broken them down into two categories: articles for true CSS newbies, and articles for people new to CSSnewbie, but with an understanding of CSS.

New to CSS

If you don’t know much about CSS at all, but would like to, here is where you want to start. I’ve tried to put them in an order that makes sense, but feel free to click around as you see fit.

• What Is This CSS Thing, Anyway?
• How to Write a CSS Rule
• Understanding the CSS Box Model
• When to Use CSS IDs and Classes
• When to Use Inline, In-Document, and Linked CSS
• The 4 CSS Rules of Multiplicity
• Writing CSS Shorthand
• 5 Web Design Books That Have Inspired Me

New to CSSnewbie.com

So where should you start reading if you’re new to the site? Well, that’s largely subjective depending on your interests, but here are a few articles that a lot of people have found interesting in the past.

• A Semantic List-Based CSS Calendar
• The CSS-Only Accordion Effect
• Easy CSS Dropdown Menus
• Combating Classitis with Cascades and Sequential Selectors
• Intelligent Navigation Bars with JavaScript and CSS
• 7 Tips for Great Print Style Sheets
• Book-Style Chapter Introductions Using Pure CSS

And if those articles don’t whet your whistle, don’t forget to check out the article categories listed in the sidebar. That’s a great way to find a lot of information fast, if you know what it is you’re looking for.

If you have other articles you’ve read on this site that are favorites, or articles that you think are essential to the beginning CSS master, please don’t hesitate to mention them in the comments. I’d be more than willing to add things to either list.

Also, I’ll be adding a link to this article to the sidebar once it has cycled off the front page. That way, future generations can bask in our collective wisdom.

Print-Friendly Images and Logos with CSS

In certain instances, not everyone views every portion of your website online: eventually, someone is going to print parts of it. In many cases, this is perfectly fine: if you have a print style sheet that takes care of your worst sins, your website should look okay. But one area where it may still look lackluster is the images.

It’s a simple problem of resolution. Images are always displayed on the web at 72dpi (dots per inch). However, nearly all printers can handle resolutions far higher than this. What that means is the text of your printed web page will be printed at a high resolution – likely at least 300dpi. Your images, however, won’t have enough information to print out at 300dpi or higher. Instead, because the browser and printer know how much space (vertically and horizontally) the image is supposed to take up, they’ll up-sample the image, doubling and tripling the number of pixels in the image via crude pixel duplication algorithms until the image is the correct size. The result is a fuzzy image with jagged edges.

Back in 2005, an article by Ross Howard appeared on A List Apart describing a way around this problem. It solves a real problem with a viable solution, but the author doesn’t give a lot of practical information on how to implant the solution. So here’s my take on that technique.

The trick is this: send a low-resolution version of your image to the screen, and a high-resolution version to the printer. It’s a fairly simple trick, but it does have a few problems. For one, it requires a bit of extra XHTML to pull it off. For another, the end user has to download both version of the image when they view the page, and the high-res image is bound to use up significantly more bandwidth. As such, I would recommend only using this technique for smaller images, and when a crisp, clean image is vitally important. A company logo would be an excellent example of this.

So here’s how it’s done. First off, we’ll have to make our logo. I built an example up quick in Photoshop:

Before you actually start building the logo, it’d be a good idea to know what size you want your large and small versions to be. I decided that I wanted my screen-size logo to be 150 pixels wide by 75 tall. However, I built my high-res version to be 600×300 pixels: four times the size (and thus, the final resolution) of the screen version. This will give me a final resolution four times the original, or 288dpi, which I’ve decided is sufficient for my aims. Your wants and needs may necessitate a larger image.

Once I have my logo designed, I just save a large version, and then downsample a smaller version for the screen. I used the Save For Web feature of Photoshop to create a small version quickly, without having to mess with the original. I saved this version in color as well, but if you wanted, you could make the printer-friendly version grayscale so as to save on color ink. Again, it’s your call.

Once we have the image, we can start in on the XHTML:

<div id="logo">
	<img src="images/logo-print.gif" width="150" height="75" />
</div>

Simple, right? It bears explanation, though. The image inside our span is the printer-friendly, high resolution version of our image. However, the width and the height we’ve set are based on the low-resolution 72dpi version. This is so our span takes up the correct amount of space on the screen.

Now, we just have to hide the printer-friendly version and show the screen version:

#logo {
	background: #fff url(images/logo-screen.gif) no-repeat;
	width: 150px;
	height: 75px; }
#logo img {
	display: none; }

The CSS above would go in your screen CSS file. It hides the image inside your span and displays a background image instead. The background image takes up the same number of pixels as the original, but it is scaled for 72dpi and displays perfectly on the screen.

Now, all you have to do is either ensure the rules above do not exist in your print CSS file, or negate them in your print CSS with something like this:

#logo {
	background: none; }
#logo img {
	display: block; }

And you should be set! When shown on the screen, the printer-friendly logo will be hidden with the “display: none” rule, and the background image will be shown instead. But when printed, the background image won’t show, and the larger image will be displayed. Because we’ve forced it to display at a size of 150px by 75px, our image has an effective resolution of 72 x 4 = 288dpi, which will result in a much cleaner printed logo. And if the user has CSS disabled for any reason, the worst that will happen is they’ll see the compressed high-res version on the screen instead of its low-res counterpart. The result will be a slightly jagged logo on the screen as the browser down-samples the original, but that is probably a small crime in the grand scheme of things.

If you’d like to see this in action, view the example page. The first version has no fancy CSS image replacement going on. If you print the page, the logo should look fairly blurry. However, if you click through to the second version and print that page, you should see a noticeable difference in the printed result, but no real difference on the screen.

View Example

As I mentioned before, this technique has the possibility of eating up quite a bit of bandwidth, so it’s probably best suited for smaller, important images. I wouldn’t suggest rendering every image on your website this way. We don’t want to create printer-friendliness at the expense of user-friendliness.

On Calendars, Lists, Tables and Semantics

A couple of weeks ago, I wrote an article on creating a calendar using lists instead of tables. I was expecting a few people to find the concept interesting, and I was hoping for a little feedback from the web community. What I wasn’t expecting was the outpouring of comments and a very serious, fascinating debate on the semantic nature of calendars, the place of lists in web design, and more. And because I don’t think it’d be productive to just go through the list and respond to each comment individually, I thought I’d take some time and respond in a follow-up article. If you haven’t read the comments yet, I’d encourage you to do so first.

The first thing that I realized as the comments started to roll in was that my tutorial was fundamentally incomplete in a couple of vital ways. While I feel I did a decent job describing how to implement the technique, I fell short when it came to explaining how I envisioned the technique being used, or my reasoning behind what made using a list in lieu of a table such a useful idea. In other words, I’d covered the “how,” but not the “what” or the “why.” So I’ll cover more of that here.

I first came up with the idea for a list-based calendar at my 8-5 job as I was leafing through my appointments in Outlook. I thought about how useful it was to be able to switch between the month view, to the 7-day, to the 5-day, and so on as necessity dictated. I wasn’t restricted to just one view of my time: I had flexibility. And then I realized that even my day planner, an old fashioned, low tech paper product broke my time into months at the top of the page, but showed the days of my week in a more linear fashion.

And that got me thinking: was there any way to support that sort of flexibility in web-based calendars? I’d dealt with web calendars before: they were exclusively table-based and, as a result, fundamentally rigid. But what if, instead of turning to a table, I used a list? Then the data could be displayed linearly, like the 7-day calendar view of my planner, or in a grid like a traditional month-based calendar, as need dictated.

I was also thinking of my multiple-calendar setup in Outlook. I have two calendars: one for my meetings and appointments, which is generally useful in a month or week view, and one for my bills (I’m bad about remembering them!), which was really more useful as a list of dates. That convinced me even further that maybe a calendar didn’t need to be based on a grid.

I created my first test calendar with that flexibility in mind. I envisioned it being used in a scenario where it was sometimes useful to see things in relation to their days of the week or place in the month, and other scenarios where it was simply more useful to have things broken down by date. I figured it’d be an easy thing to set up bit of PHP or JavaScript to swap between two CSS files, changing the view on the fly. Of course, when it came to the tutorial, I focused exclusively on how to implement the idea, and neglected to mention why such an idea might be useful.

And that explains my thinking on the “what” and “why” portions of the tutorial. I was looking for a flexible calendar solution, one that wasn’t locked to the month-based grid.

Because — to get more into the semantics side of things — I would disagree with those that commented that a calendar was, fundamentally and semantically, a grid-based (and therefore table-based) entity. If calendars are married to the grid, why does my Outlook calendar have so many alternative views? Why does my day planner make so much sense to me at a glance, even though the days are arranged in a single column? Thinking of a calendar as exclusively month-based and grid-based is a narrow way at looking at the concept, considering all the alternative options we as a culture use on a daily basis.

And all that plays into the semantics of the calendar. Is a calendar, semantically, a grid? Sure, if you’re talking specifically of a month-based calendar. But I’d argue that my day planner is much more closely semantically related to an ordered list, and my Outlook calendar is like both, depending on what view I’m using at any given moment.

I can understand now why my calendar tutorial stirred up such a big semantics debate: my tutorial showed a calendar locked in a month-based, grid-like format. I didn’t mention any of my ideas on flexibility, multiple views, or the rest. And that resulted in well-reasoned retorts in the comments and even elsewhere: for example, Unintentionally Blank argued that I had presented a grid, but used a linear tool to do so, and thus wasn’t using the right tool for the job. Similarly, commenter Mark Aplet directed me to a recent post on his blog visual28, where he argued that designers were using lists for everything; that, essentially, lists were becoming what tables had once been in the web design world.

And the ironic part of it all is, I agree with both of those stances. Yes, I worry that designers overuse lists: I am opposed to the idea, for example, of using an unordered list as a basic structure for an entire website. And I would also agree that, if you’re presenting tabular data, there’s no better tool than a table to accomplish that aim. Which meant that my earlier attempts to respond to the debate raging in the comments all started with, “Yes, but…” Which is how this, longer and hopefully more clearly argued article came about.

So, what say you, semantically impassioned readers? If the goal is to create multiple calendar views with a single XHTML file, is a list an acceptable tool or am I still trying too hard to live off the grid? Does a calendar by any other orientation smell just as sweet? Let’s keep the debate alive: we’ll all end up coming away a little bit wiser.