# Sharing, the Old-fashioned Way

When it comes to sharing, there are myriad ways to do it. If you’re at all familiar with my work, it should come as no surprise that I always start with a universally-useable and accessible baseline and then progressively enhance things from there. Thankfully, every social media site I commonly use (with the exception of the Fediverse) makes this pretty easy by providing a form that accepts inbound content via the query string.¹ You can try LinkedIn’s to see it in action.

Each service is a little different, but all function similarly. I support the following ones in this site:

Using this information, I created a partial template for use on any page in this site (though I mainly use it on blog posts right now). Each link includes useful text content (e.g., “Share on __”) and a local SVG of the service’s icon. Here’s a simplified overview of the markup I use:

<ulclass=“social-links social-links–share”><liclass=“social-links__item”><ahref=“{{ SHARE URL }}”class=“social-link”rel=“nofollow”><svg>{{ SERVICE ICON }}</svg><bclass=“social-link__text”>Share on {{ SERVICE NAME }}</b></a></li></ul>

You can check out the baseline experience on this very page by disabling JavaScript.

It’s worth noting that I have chosen not to enforce opening these links in a new tab. You can do that if you like, but on mobile devices I’d prefer the user just navigate to the share page directly. You may have a different preference, but if you decide to spawn a new tab, be sure your link text lets folks know that’s what will happen. I do include a rel="nofollow" on the link, however, to prevent search spiders from indexing the share forms.

If you test out these links, you’ll notice many of the target forms will pick up a ton of information from your page automatically. By and large, this info is grabbed from your page’s Open Graph data (stored in meta tags) or Linked Data (as JSON-LD). You can write that info to your page by hand or use a plugin to generate it for you automatically. There are a ton of options out there if you choose to go the later route (which I’d recommend).

# Enhancement Level 1: Popup Share

If you played around with any of the various share forms, you probably noticed that they are, by and large, designed as discrete interactions best-suited to a narrow window (e.g., mobile) or popup. To provide that experience, I’ve long-relied on a little bit of JavaScript to launch them in a new, appropriately-sized window:

functionpopup(e){var $link = e.target;while($link.nodeName.toLowerCase()!=“a”){$link = $link.parentNode;}e.preventDefault();var popup = window.open($link.href,“share”,“height=500,width=600,status=no,toolbar=no,popup”,);try{popup.focus();e.preventDefault();}catch(e){}}var screen_width =“visualViewport”in window? window.visualViewport.width: window.innerWidth,$links = document.querySelectorAll(“.social-links–share a”),count = $links.length;if(screen_width >600){while(count–){$links[count].addEventListener(“click”, popup,false);$links[count].querySelector(“.social-link__text”).innerHTML +=" (in a popup)“;}}

The first chunk defines a new function called popup() that will act as the event listener. It takes the event (e) as an argument and then finds the associated link (bubbling up through the DOM as necessary in that while loop). Once it finds the link, the function opens a new popup window (using window.open()). Then, to check if the popup was blocked, it attempts (within the try…catch) to focus it. If the focus succeeds, which means the popup wasn’t blocked, the script prevents the link from navigating the user to the href (which is the default behavior, hence e.preventDefault()).

The second block defines a couple of variables we’ll need. First, it captures the current screen_width using either the window’s visualViewport (if available) or its innerWidth (which is more old school). Next it grabs the social links ($links) and counts them for looping purposes (count).

The final block is a conditional that checks to see if the screen_width is wider than 600px (an arbitrary width that just feels right… your mileage may vary). If the screen is wider than that threshold, it loops through the links,² adds the click handler, and adds some text to the link label to let folks know it will open a popup.

And with that, the first layer of enhancement is complete: Users with JavaScript support who also happen to be using a wider browser window will get the popup share form if the popup is allowed. If the popup isn’t allowed, they’ll default to the baseline experience.

# Enhancement Level 2: OS Share

A few years back, browsers began participating in OS-level share activities. On one side, this allowed websites to share some data—URLs, text, files—to other apps on the device via navigator.share(). On the other side of the equation, Progressive Web Apps could advertise themselves—via the Manifest’s share_target member—as being able to receive content shared in this way.

Sharing a URL and text is really well supported. That said, it’s only been around a few years at this point and some browsers require an additional permission to use the API.³ For these reasons, it’s best to use the API as a progressive enhancement. Thankfully, it’s easy to test for support:

if(“share”in navigator){// all good!}

For my particular implementation, I’ve decided to swap out the individual links for a single button that, when clicked, will proffer the page’s details over to the OS’s share widget. Here’s the code I use to do that:

var $links = document.querySelector(”.social-links–share"),$parent = $links.parentNode,$button = document.createElement(“button”),title = document.querySelector(“h1.p-name,title”).innerText,$description = document.querySelector(‘meta[name=“og:description”],meta[name=“description”]’,),text = $description ? $description.getAttribute(“content”):“”,url = window.location.href;$button.innerHTML =“Share <svg>…</svg>”;$button.addEventListener(“click”,function(e){navigator.share({ title, text, url });});$parent.insertBefore($button, $links);$links.remove();

The first block sets up my variables:

• $links - A reference to the list (ul) of sharing links;
• $parent - the parent container of that list;
• $button - the button I’m going to swap in for the links;
• title - The page title (either from the page’s h1 or title element);
• $description - A reference to a meta description element;
• text - The text content of that description, if one is found; and
• url - The URL to be shared.

The second block sets up the button by inserting the text “Share” and an SVG share icon and setting an event listener on it that will pass the collected info to navigator.share().

The third and final block swaps out the link list for the button.

# Putting It All Together

The final step to putting this all together involves setting up the conditional that determines which enhancement is offered. To keep everything a bit cleaner, I’m also moving each of the enhancements into its own function:

!(function(window, document, navigator){functionprepForPopup(){// popup code}functionpopup(){// popup event handler}functionswapForShareAPI(){// share button code}if(“share”in navigator){swapForShareAPI();}else{prepForPopup();}})(this,this.document,this.navigator);

With this setup in place, I can provide the optimal experience in browsers that support the web share API and a pretty decent fallback experience to browsers that don’t. And if none of these enhancements can be applied, users can still share my content to the places I’ve identified… no cookies or third-party widgets required.

You can see (and play with) an isolated demo of this interface over on Codepen.

# Background

In their research, the Otto JS team found that Chrome and Edge each use their own web services to drive their spellchecking services. In Chrome’s case it seems to only be with their “advanced spellcheck” feature turned on. I was able to validate this behavior using Charles on macOS Monterey using the latest Chrome Stable and the latest Edge Canary. I did not see the same exfiltration happen with Safari or Firefox. I created a CodePen form with several fields to test different permutations of form field attributes and behaviors. What I am sharing, below, is a result of that testing.

# What gets sent?

In both Chrome and Edge, the information sent to their services is the text value itself, disconnected from any specific field name. Chrome also sends the user’s language, and country. Edge, which uses the Microsoft Editor service under the hood, also sends a bunch of licensing details and the user’s language.

# Password fields are safe

<inputtype=“password”id=“password”name=“password”/>

Browsers do a lot to protect the contents of password fields already, so I wasn’t surprised to see that the contents of password fields are not passed to a spellcheck service.

If you are not using a true password field, however, the contents of that field are not protected in the same way. If you build a custom password control, you’re on the hook to replicate the entirety of the browser’s feature set when it comes to protecting user data. Unless you’re a glutton for punishment, you should probably just use the built-in password field instead.

# Fields marked readonly and disabled are not exposed

As you’d hope, neither read-only fields nor disabled fields are exposed ot the service. This even holds true when you change the values of these fields programmatically or via DevTools.

I should note, however, that readonly fields are send to the server when the form is submitted and their contents are editable via JavaScript and DevTools, so you should always assume readonly fields are informational for the user only and never trust their contents on the server side. Fields that are marked disabled, in contrast, are never sent to the server.

# You can protect interactive fields with the spellcheck attribute

<inputid=“no-spellcheck”name=“no-spellcheck”spellcheck=“false”/>

The spellcheck attribute can be applied to any element and setting it to “false” instructs browsers to turn off spellchecking services for its contents. The post from Otto JS showed this being used globally on the body element, but that is overkill. It would be better to use the attribute on specific fields you want to protect, as shown above.

# Don‘t forget about password controls that support show/hide

Edge has a neat feature in its password field implementation where it enables a user to toggle the visibility of the password within the control itself. When users show their password using that built-in functionality, no content is shared with the spellchecker. Not all browsers have this feature, however, which has led to JavaScript-based implementations that simply swap the “password” type value for “text” to show the contents and then swap it back again to hide the contents. Here’s a quick & dirty example of what the toggle button’s event handler might look like:

functiontogglePassword(e){var $btn = e.target,$field = $btn.parentNode.querySelector(“input”),state = $field.type;if($btn && $field){if(state ==“password”){$field.type =“text”;$btn.innerText =“Hide”;}else{$field.type =“password”;$btn.innerText =“Show”;}e.preventDefault();e.stopPropagation();}}

The problem with this approach, when it comes to the spellchecker, is that the text field is considered fair game for checking. Its contents aren’t sent right away, but if the field receives focus or its value is changed in any way while in the “text” state, its contents are sent to the spellcheck service.

Protecting the field’s contents are fairly easy, however: turn off the spellchecker for that field, even in its “password” state.

<inputtype=“password”id=“password-show-nospellcheck”name=“password-show-nospellcheck”spellcheck=“false”/>

With spellcheck="false" in place, you can turn the field into a text field safely, without the contents being exposed to the spellcheck service.

HTML is a pretty powerful language and, when wielded properly, can be an excellent tool for protecting user data, provided we use it properly. And know that you know how to protect your users’ sensitive data, minimize this tab and start filing those pull requests…

[M]y personal preference is generally to continue as normal, and then to use whatever’s being requested as an enhancement, as a natural part of whatever task I am hoping to do, at a time that makes sense to me rather than having it pushed on me out of context or at a time that doesn’t make sense.

This is true for me as well. I hate going to a new site only to be immediately bombarded with requests to see my location or send me notifications. It makes your site appear desperate, socially-awkward, and a bit sociopathic.

I definitely believe there’s room for improvement in terms of how browsers relay requests for permission. Personally, I’d love to see permission requests require an accompanying link to the section of that site’s privacy policy covering how the information being requested will be used. Sure, most users probably won’t click on it, but having to provide something might make some developers think twice about it (and more directly tie these requests to the site’s governing entity from a legal standpoint).

What I want is a way that both sides can get what they want: companies and projects can be data-driven, and users don’t get their privacy compromised.

Amen.

You see, any time you add third party widget code—a “tweet this” button, for example—a request is made to that third party’s server in order to retrieve the required snippet of JavaScript. When that request is sent, information is sent to the server in the form of headers and (as is often the case) cookies. The headers usually contains general information about the browser being used, referring page, etc. and don’t generally pose much of a threat, but cookies are another matter altogether.

When a user visits a site—say, Facebook—she is typically cookied by that site. Browsers give a user some modicum of control over what sites can set a cookie, so she could have opted out of receiving Facebook’s cookie, but most users don’t know enough to or don’t know how to opt-out of cookies. Once that cookie is in place, it is directly associated with a specific domain (e.g. facebook.com or one of its hostnames). As long as that cookie is active, it remains on the users’ computer and accompanies any requests sent to the specifed domain. That means when this user visits a web page that includes a Facebook-supplied “Like” button, for example, Facebook can identify who she is (via the cookie) and what she’s looking at (via the request headers) without her even clicking the “Like” button. As she moves from page to page across the web, Facebook—or Google, or Twitter, or Pinterest, or AddThis, or any other service with decent distribution of its widgets—can effectively track her movement and build up a profile of her interests or browsing habits without her even knowing.

Now I’m pretty certain none of these companies started out wanting to track their users in such a manner, nor am I convinced many of them actively are (though I would not put it past Google or Facebook), but I think you can agree there is certainly potential for abuse here.

So what are we to do? Including buttons that easily allow our users to share content on their favorite social networks is extremely helpful for attracting more eyeballs to our content; it would be a shame to lose that opportunity. I agree, but just because a company offers a widget to make it simple for you to set up the button doesn’t mean you need to use it. Thankfully it isn’t really that difficult to host “share” buttons yourself, you just have to know how to do it.

Below is simplification of the current markup we use to achieve this in our blog. At present, we’ve chosen to support only four social networks: Twitter, Facebook, LinkedIn, and Google Plus.

To trigger a share via Twitter, we use Twitter’s “tweet intent” URL: https://twitter.com/intent/tweet. We then supply several key-value pairs as part of the query string:

1. The referer (our page) as original-referer;
2. Any text we want included in the tweet—e.g. the title of the page—as text (n.b. be sure to replace spaces with “+”);
3. the page to share as url; and
4. (optionally) a Twitter account handle you’d like the tweet to appear “via”.

Facebook seems less complicated, but it’s really not. Sure, the URL is simple—http://www.facebook.com/sharer.php with the URL supplied as u in the query string—but to control what Facebook displays when your page is shared, you need to add some meta tags that describe the page as an OpenGraph object. Here’s a sample from this blog post:

This set of meta tags establishes this post as an “article” with a title, description, and a canonical URL, which ensures it is displayed in Facebook properly. Facebook maintains pretty decent documentation on OpenGraph and the pieces they support and they also have a handy testing tool you can use to see if everything is making it to them properly. (It’s also worth noting that, using the debugger, you can also force Facebook to update any previously cached content from a given URL.)

Rounding out the pack are LinkedIn and Google Plus. Both use OpenGraph like Facebook does, but LinkedIn only supports a subset of OpenGraph tags—og:title, og:url, and og:image (though only if the image is wider than 150px and taller than 80px)—and Google Plus would prefer you use the ridiculously convoluted attributes defined by schema.org, but will fall back to OpenGraph or basic meta title and description tags if necessary.

Now that the HTML links are working properly (you did test them, right?), you need some buttons. There are tons of options out there, but if you like the ones we are using, you can download a layered PSD from us and tweak to your heart’s content. If, however, you want to go image-less, you could use one of the many great icon fonts out there (like IcoMoon). Whatever you do, just don’t link to images on a 3rd party site because then you are falling back into the same trap again because image requests also pass along headers and cookies.

And there you have it: a fully-funcitonal set of sharing tools that requires no JavaScript and doesn’t sacrifice your users’ privacy.

If you want to take it a step further, it’s pretty easy to add a tiny bit of JavaScript to make the links trigger a popup when there’s enough real estate (after all, you probably don’t want to do that on mobile). Here’s the jQuery code we currently use on this site for that purpose:

$(‘#bookmark’).delegate(‘a’,‘click’,function(e){if($(window).width()>700){e.preventDefault();window.open(this.href,‘share-this’,‘height=300,width=500,status=no,toolbar=no’);}});

As you can see, with just a little bit of effort (and maybe a bit of research), it’s easy to protect your users. Please consider doing it on your own sites.

It started as a bookmarklet, but the endpoint URL for the mobile share form is easily extracted from there (note: this works, ok but is not ideal… see Update #2 below):

https://m.google.com/app/plus/x/?content=CONTENT+AND+URL+GOES+HERE&v=compose&hideloc=1

We’ve gone ahead and implemented Google+ now, so if you are a fan… happy linking!

Update #1: In playing around with it a bit more, there’s a strange behavior whereby Google says there’s a problem with the post, but it actually does get into your Stream. I’ll dig around a bit and see if I can sort that out.

Update #2: Google is finally supporting this properly. Here’s the URL scheme:

https://plus.google.com/share?url=URL+GOES+HERE