Tag: share

How to Safely Share Your Email Address on a Website

Spammers are a huge deal nowadays. If you want to share your contact information without getting overwhelmed by spam email you need a solution. I run into this problem a few months ago. While I was researching how to solve it, I found different interesting solutions. Only one of them was perfect for my needs.

In this article, I am going to show you how to easily protect your email address from spam bots with multiple solutions. It’s up to you to decide what technique fits your needs.

The traditional case

Let’s say that you have a website. You want to share your contact details, and you don’t want to share only your social links. The email address must be there. Easy, right? You type something like this:

<a href="mailto:email@address.com">Send me an Email</a>

And then you style it according to your tastes.

Well, even if this solution works, it has a problem. It makes your email address available to literally everyone, including website crawlers and all sorts of spam bots. This means that your inbox can be flooded with tons of unwanted rubbish like promotional offers or even some phishing campaign.

We are looking for a compromise. We want to make it hard for bots to get our email addresses, but as simple as possible for normal users.

The solution is obfuscation.

Obfuscation is the practice of making something difficult to understand. This strategy is used with source code for multiple reasons. One of them is hiding the purpose of the source code to make tampering or reverse-engineering more difficult. We will first look at different solutions that are all based on the idea of obfuscation.

The HTML approach

We can think of bots as software that browse the web and crawl through web pages. Once a bot obtains an HTML document, it interprets the content in it and extracts information. This extraction process is called web scraping. If a bot is looking for a pattern that matches the email format, we can try to disguise it by using a different format. For example, we could use HTML comments:

<p>If you want to get in touch, please drop me an email at<!-- fhetydagzzzgjds --> email@<!-- sdfjsdhfkjypcs -->addr<!-- asjoxp -->ess.com</p>

It looks messy, but the user will see the email address like this:

If you want to get in touch, please drop me an email at email@address.com

Pros:

  • Easy to set up.
  • It works with JavaScript disabled.
  • It can be read by assistive technology.

Cons:

  • Spam bots can skip known sequences like comments.
  • It doesn’t work with a mailto: link.

The HTML & CSS approach

What if we use the styling power of CSS to remove some content placed only to fool spam bots? Let’s say that we have the same content as before, but this time we place a span element inside:

<p>If you want to get in touch, please drop me an email at <span class="blockspam" aria-hidden="true">PLEASE GO AWAY!</span> email@<!-- sdfjsdhfkjypcs -->address.com</p>.

Then, we use the following CSS style rule:

span.blockspam {   display: none; }

The final user will only see this:

If you want to get in touch, please drop me an email at email@address.com.

…which is the content we truly care about.

Pros:

  • It works with JavaScript disabled.
  • It’s more difficult for bots to get the email address.
  • It can be read by assistive technology.

Con:

  • It doesn’t work with a mailto: link.

The JavaScript approach

In this example, we use JavaScript to make our email address unreadable. Then, when the page is loaded, JavaScript makes the email address readable again. This way, our users can get the email address.

The easiest solution uses the Base64 encoding algorithm to decode the email address. First, we need to encode the email address in Base64. We can use some websites like Base64Encode.org to do this. Type in your email address like this:

A large textarea to paste an email address with a series of options beneath it for how to encode the text.

Then, click the button to encode. With these few lines of JavaScript we decode the email address and set the href attribute in the HTML link:

var encEmail = "ZW1haWxAYWRkcmVzcy5jb20="; const form = document.getElementById("contact"); form.setAttribute("href", "mailto:".concat(atob(encEmail)));

Then we have to make sure the email link includes id="contact" in the markup, like this:

<a id="contact" href="">Send me an Email</a>

We are using the atob method to decode a string of Base64-encoded data. An alternative is to use some basic encryption algorithm like the Caesar cipher, which is fairly straightforward to implement in JavaScript.

Pros:

  • It’s more complicated for bots to get the email address, especially if you use an encryption algorithm.
  • It works with a mailto: link.
  • It can be read by assistive technology.

Con:

  • JavaScript must be enabled on the browser, otherwise, the link will be empty.

The embedded form approach

Contact forms are everywhere. You certainly have used one of them at least once. If you want a way for people to directly contact you, one of the possible solutions is implementing a contact form service on your website.

Formspree is one example of service which provides you all the benefits of a contact form without worrying about server-side code. Wufoo is too. In fact, here is a bunch you can consider for handling contact form submissions for you.

The first step to using any form service is to sign up and create an account. Pricing varies, of course, as do the features offered between services. But one thing most of them do is provide you with an HTML snippet to embed a form you create into any website or app. Here’s an example I pulled straight from a form I created in my Formspring account

<form action="https://formspree.io/f/[my-key]" method="POST">   <label> Your email:     <input type="email" name="email" />   </label>   <label> Your message:     <textarea name="message"></textarea>   </label>   <!-- honeypot spam filtering -->   <input type="text" name="_gotcha" style="display:none" />   <button type="submit">Send</button> </form>

In the first line, you should customize action based on your endpoint. This form quite basic, but you can add as many fields as you wish.

Notice the hidden input tag on line 9. This input tag helps you filter the submissions made by regular users and bots. In fact, if Formspree’s back-end sees a submission with that input filled, it will discard it. A regular user wouldn’t do that, so it must be a bot.

Pros:

  • Your email address is safe since it is not public.
  • It works with Javascript disabled.

Con:

  • Relies on a third-party service (which may be a pro, depending on your needs)

There is one other disadvantage to this solution but I left it out of the list since it’s quite subjective and it depends on your use case. With this solution, you are not sharing your email address. You are giving people a way to contact you. What if people want to email you? What if people are looking for your email address, and they don’t want a contact form? A contact form may be a heavy-handed solution in that sort of situation.

Conclusion

We reached the end! In this tutorial, we talked about different solutions to the problem of online email sharing. We walked through different ideas, involving HTML code, JavaScript and even some online services like Formspree to build contact forms. At the end of this tutorial, you should be aware of all the pros and cons of the strategies shown. Now, it’s up to you to pick up the most suitable one for the your specific use case.


How to Safely Share Your Email Address on a Website originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

CSS-Tricks

, , , ,

If I work really hard on my Open Graph images, people will share my blog posts.

Zach did that thing where each of his blog posts has a special URL with the design of social image card that is screenshat by a headless browser (like Puppeteer) and used as a true meta Open Graph image, meaning it’s displayed on Twitter, Facebook, iMessage, Slack, Discord, and whatever else supports that card look.

I like it. Even though I’ve got a pretty good solution cooking now (for WordPress), the templates aren’t controlled with HTML/CSS like I wish they were.

As bit of yang to the ying here, Jim has some thoughts on the not-so-great aspects of Open Graph images:

I feel like they’ve been hijacked by auto-generated computer imagery serving as attention-grabbing filler more than supportive expression.

Jim Nielsen, “Quibbles With Social Share Imagery”

It’s kinda like… we can add Open Graph images, and we essentially get a totally free massive clickable target for hungry fingers, so we do add Open Graph images — even when that image is, well, boring. Just auto-generated computer barf of title text with branding. Jim’s post has examples.

I get where Jim is coming from, and I suppose I’m guilty to some degree. I feel like we’re a cut-above on CSS-Tricks though, if you’ll pardon a taste of defensiveness, because:

  1. We have a variety of templates to choose from to switch it up, like a quote design.
  2. We incorporate custom imagery into the final card, meaning most cards are somewhat visually unique.
  3. We don’t just brand the cards, we usually incorporate the author for a little extra high five for the person, rather than just our brand.

Direct Link to ArticlePermalink


The post If I work really hard on my Open Graph images, people will share my blog posts. appeared first on CSS-Tricks. You can support CSS-Tricks by being an MVP Supporter.

CSS-Tricks

, , , , , , , , ,
[Top]

Automatic Social Share Images

It’s a pretty low-effort thing to get a big fancy link preview on social media. Toss a handful of specific <meta> tags on a URL and you get a big image-title-description thing. Here’s Twitter’s version of an article on this site:

It’s particularly low-effort on this site, as our Yoast SEO plugin puts the correct tags in place automatically. The image it uses by default is the “featured image” feature of WordPress, which we use anyway.

I’m a fan of that kind of improvement for that so little work. Jetpack helps the process, too, by automating things.

But let’s say you don’t use these particular tools. Maybe creating an image per blog post isn’t even something you’re interested in doing, but you still want something nice to show for the social media preview.

We’ve covered this before. You can design the “image” with HTML and CSS, using content and metadata you already have from the blog post. You can turn it into an image with Puppeteer (or the like) and then use that for the image in the meta tags.

Ryan Filler has detailed out that process the best I’ve seen so far.

  1. Create a route on your site that takes dynamic data from the URL to create the layout
  2. Make a cloud function that hits that route, turns it into an image, and uploads it to Cloudinary (for optimizing and serving)
  3. Any time the image is requested, check to see if you’ve already created it. If so, serve it from Cloudinary; if not, make it, then serve it.

This stuff gets my brain cooking. What if we didn’t need to create a raster image at all?

Maybe rather than needing to create a raster image we could use SVG? SVG would be easy to template, and we know <img src="file.svg" alt="" /> is extremely capable. But… Twitter says:

Images must be less than 5MB in size. JPG, PNG, WEBP and GIF formats are supported. Only the first frame of an animated GIF will be used. SVG is not supported.

Fifty sad faces, Twitter. But let’s continue this thought experiment.

We need raster. The <canvas> element can spit out a PNG. What if the cloud function that you talked to was an actual browser? Richard Young called that a “browser function” last year. Maybe the browser-in-the-cloud could do that SVG templating we’re dreaming of, but then draw it to a canvas and spit out that PNG.

Meh, I’m not sure that solves anything since you’d still have the Puppeteer dependency and, if anything, this just complicates how you make the image. Still, something appeals to me about being able to use native browser abilities at the server level.

Direct Link to ArticlePermalink


The post Automatic Social Share Images appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

CSS-Tricks

, , ,
[Top]

On the Web Share API

I think the Web Share API is very cool (here’s our coverage). In a nutshell, it taps into the native sharing features on whatever platform you’re on, if that platform supports it. So essentially…


I like this:

Web Share API activated on iOS

A heck of a lot more than these things:

This is just an image, don’t try to click them. You clicked them didn’t you?

Why?

  • The Web Share API is just a couple of lines of code. Easy! No images, no weighty JavaScript or iframes, no chance of going out of date (cough, Google+).
  • The UI that users see is customized to their platform and perhaps even customized by them to have the things they want in it.

Good job, web standards.

But it’s not supported everywhere. For example, I’m writing this blog post in Chrome, and it doesn’t work in desktop Chrome. But it does work in desktop Safari!

So if I’m going to use it, I’d rather test for support before plunking the button on a page. It’s very easy:

if (navigator.share) {  }

Here’s an example where I plop a <button> onto an article, should that API be supported:

That JavaScript does a little fancy dancing to grab the title and first paragraph of the post to use in the API. I like how Jeremy Keith does it at the page level:

if (navigator.share) {   navigator.share(     {       title: document.querySelector('title').textContent,       text: document.querySelector('meta[name="description"]').getAttribute('content'),       url: document.querySelector('link[rel="canonical"]').getAttribute('href')     }   ); }

You could just pass in strings to those values too. This is just showing off how you might do things dynamically that work on any page.

Jeremy has also been on a kick advocating for a JavaScript-optional version of the Web Share API, which he thinks could work like this:

<button type="share">

And then, for specifying title and text:

<button type="share" value="title,text">

That feels a little funky to me, with the comma. What if the title has a comma in it? And what about specifying the URL? Could we split them all up into attributes? I think I know what Jeremy would say: this is a simple declarative version. If you’d like to change the default behavior, that’s what JavaScript is for.

But also, should it be there at all if the browser doesn’t support it? Well sure, if you polyfill it:

This polyfill turns the button into a mailto: experience if not supported. That’s pretty clever. I think if I was production-bound, I’d probably only slip the button in when the feature is truly supported.


The post On the Web Share API appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

CSS-Tricks

[Top]

How to Use the Web Share API

The Web Share API is one that has seemingly gone under the radar since it was first introduced in Chrome 61 for Android. In essence, it provides a way to trigger the native share dialog of a device (or desktop, if using Safari) when sharing content — say a link or a contact card — directly from a website or web application.

While it’s already possible for a user to share content from a webpage via native means, they have to locate the option in the browser menu, and even then, there’s no control over what gets shared. The introduction of this API allows developers to add sharing functionality into apps or websites by taking advantage of the native content sharing capabilities on a user’s device.

iOS offers a number of native sharing options.

This approach provides a number of advantages over conventional methods:

  • The user is presented with a wide range of options for sharing content compared to the limited number you might have in your DIY implementation.
  • You can improve your page load times by doing away with third-party scripts from individual social platforms.
  • You don’t need to add a series of buttons for different social media sites and email. A single button is sufficient to trigger the device’s native sharing options.
  • Users can customize their preferred share targets on their own device instead of being limited to just the predefined options.

A note on browser support

Before we get into the details of how the API works, let’s get the issue of browser support out of the way. To be honest, browser support isn’t great at this time. It’s only available for Chrome for Android, and Safari (desktop and iOS).

This browser support data is from Caniuse, which has more detail. A number indicates that browser supports the feature at that version and up.

Desktop

Chrome Opera Firefox IE Edge Safari
No No No No No 12.1

Mobile / Tablet

iOS Safari Opera Mobile Opera Mini Android Android Chrome Android Firefox
12.2 No No No 74 No

But don’t let that discourage you from adopting this API on your website. It’s pretty easy to implement a fallback for supporting browsers that don’t offer support for it, as you’ll see.

A few requirements for using it

Before you can adopt this API on your own web project, there are two major things to note:

  • Your website has to be served over HTTPS. To facilitate local development, the API also works when your site is running over localhost.
  • To prevent abuse, the API can only be triggered in response to some user action (such as a click event).

Here’s an example

To demonstrate how to use this API, I’ve prepared a demo that works essentially the same as it does on my site. Here’s how it looks like:

See the Pen
WebShare API Demo – Start
by Ayooluwa (@ayoisaiah)
on CodePen.

At this moment, once you click the share button, a dialog pops out and shows a few options for sharing the content. Here’s the part of the code that helps us achieve that:

shareButton.addEventListener('click', event => {   shareDialog.classList.add('is-open'); });

Let’s go ahead and convert this example to use the Web Share API instead. The first thing to do is check if the API is indeed supported on the user’s browser as shown below:

if (navigator.share) {   // Web Share API is supported } else {   // Fallback }

Using the Web Share API is as simple as calling the navigator.share() method and passing an object that contains at least one of the following fields:

  • url: A string representing the URL to be shared. This will usually be the document URL, but it doesn’t have to be. You share any URL via the Web Share API.
  • title: A string representing the title to be shared, usually document.title.
  • text: Any text you want to include.

Here’s how that looks in practice:

shareButton.addEventListener('click', event => {   if (navigator.share) {     navigator.share({       title: 'WebShare API Demo',       url: 'https://codepen.io/ayoisaiah/pen/YbNazJ'     }).then(() => {       console.log('Thanks for sharing!');     })     .catch(console.error);   } else {     // fallback   } });

At this point, once the share button is clicked in a supported browser, the native picker will pop out with all the possible targets that the user can share the data with. Targets can be social media apps, email, instant messaging, SMS or other registered share targets.

The API is promised-based, so you can attach a .then() method to perhaps display a success message if the share was successful, and handle errors with .catch(). In a real-world scenario, you might want to grab the page’s title and URL using this snippet:

const title = document.title; const url = document.querySelector('link[rel=canonical]') ? document.querySelector('link[rel=canonical]').href : document.location.href;

For the URL, we first check if the page has a canonical URL and, if so, use that. Otherwise, we grab the href off document.location.

Providing a fallback is a good idea

In browsers where the Web Share API isn’t supported, we need to provide a fallback mechanism so that users on those browsers still get some sharing options.

In our case, we have a dialog that pops out with a few options for sharing the content and the buttons in our demo do not actually link to anywhere since, well, it’s a demo. But if you want to learn about how you can create your own links to share web pages without third-party scripts, Adam Coti’s article is a good place to start.

What we want to do is display the fallback dialog for users on browsers without support for the Web Share API. This is as simple as moving the code that opens the share dialog into the else block:

shareButton.addEventListener('click', event => {   if (navigator.share) {     navigator.share({       title: 'WebShare API Demo',       url: 'https://codepen.io/ayoisaiah/pen/YbNazJ'     }).then(() => {       console.log('Thanks for sharing!');     })     .catch(console.error);   } else {     shareDialog.classList.add('is-open');   } });

Now, all users are covered regardless of what browser they’re on. Here’s a comparison of how the share button behaves on two mobile browsers, one with Web Share API support, and the other without:

Testing the share button on an Android device that supports the functionality. Android's native sharing options are triggered when the share button is pressed. The second test shows the hare button being clicked on an Android device that does not support the functionality. That produces the fallback sharing options that have been added manually.

Try it out! Use a browser that supports Web Share, and one that doesn’t. It should work similarly to the above demonstration.

See the Pen
WebShare API Demo – End
by Ayooluwa (@ayoisaiah)
on CodePen.

Wrapping up

This covers pretty much the baseline for what you need to know about the Web Share API. By implementing it on your website, visitors can share your content more easily across a wider variety of social networks, with contacts and other native apps.

It’s also worth noting that you’re able to add your web application as a share target if it meets the Progressive Web App installation criteria and is added to a user’s home screen. This a feature of the Web Share Target API which you can read about at Google Developers.

Although browser support is spotty, a fallback is easily implemented, so I see no reason why more websites shouldn’t adopt this. If you want to learn more about this API, you can read the specification here.

Have you used the Web Share API? Please share it in the comments.

The post How to Use the Web Share API appeared first on CSS-Tricks.

CSS-Tricks

[Top]

Use monday.com to manage and share projects all in one place

(This is a sponsored post.)

We’ve talked quite a bit about project management and workflows around here at CSS-Tricks, not because it’s the core of what we do as designers and developers, but because we all play a role in it as part of a team and because it impacts the quality of our work at the end of the day.

That’s why having a good system in place is such a benefit both to us and to teams as a whole. Where can you find a system like that? You might want to start by looking at monday.com. Yes, it’s a project management tool but it actually goes way beyond that. Where some other platforms out there stop at task lists, calendars, and milestones, monday.com does those plus team collaboration.

If you’ve ever felt out of the loop on a project, had a surprise change in scope, or even been curious what other folks on your team have been up to, that’s where monday.com really shines. It’s people-centric, giving you and others insight into activity across an entire project through news feeds, messaging, shared assets, clearly defined user roles, among any other things. It’s what a healthy, transparent, and collaborative team environment looks like.

We’ve only scratched the surface here, but lucky for you, there’s a free 14-day trial to check out everything that monday.com has to offer. Go for it!

Try it Now

Direct Link to ArticlePermalink

The post Use monday.com to manage and share projects all in one place appeared first on CSS-Tricks.

CSS-Tricks

, , , ,
[Top]