Fluid typography is the idea that font-size (and perhaps other attributes of type, like line-height) change depending on the screen size (or perhaps container queries if we had them).
The core trickery comes from viewport units. You can literally set type in viewport units (e.g. font-size: 4vw), but the fluctuations in size are so extreme that it's usually undesirable. That's tampered by doing something like font-size: calc(16px + 1vw). But while we're getting fancy with calculations anyway, the most common implementation ended up being an equation to calculate plain English:
I want the type to go between being 16px on a 320px screen to 22px on a 1000px screen.
html {
font-size: 16px;
}
@media screen and (min-width: 320px) {
html {
font-size: calc(16px + 6 * ((100vw - 320px) / 680));
}
}
@media screen and (min-width: 1000px) {
html {
font-size: 22px;
}
}
That's essentially setting a minimum and maximum font size so the type won't shrink or grow to anything too extreme. "CSS locks" was a term coined by Tim Brown.
Minimum and maximum you say?! Well it so happens that functions for these have made their way into the CSS spec in the form of min() and max().
So we can simplify our fancy setup above with a one-liner and maintain the locks:
html {
font-size: min(max(16px, 4vw), 22px);
}
We actually might want to stop there because even though both Safari (11.1+) and Chrome (79+) support this at the current moment, that's as wide as support will get today. Speaking of which, you'd probably want to slip a font-size declaration before this to set an acceptable fallback value with no fancy functions.
But as long as we're pushing the limits, there is another function to simplify things even more: clamp()! Clamp takes three values, a min, max, and a flexible unit (or calculation or whatever) in the middle that it will use in case the value is between the min and max. So, our one-liner gets even smaller:
body {
font-size: clamp(16px, 4vw, 22px);
}
That'll be Chrome 79+ (which doesn't hasn't even dropped to stable but will very soon).
Uncle Dave is very happy that FitText is now a few bytes instead of all-of-jQuery plus 40 more lines. Here is us chucking CSS custom properties at it:
I say "was" because it's deprecated. It may still "work" (like everybody's favorite <marquee> in some browsers), but it could stop working anytime, they say. The whole purpose of it was to display text in a monospace font, like the way Teletype machines used to.
Dave used it jokingly the other day.
Per recent events: As you can see by this official transcript, Dave Rupert LLC has done nothing wrong...
<tt> Client: This is the greatest call I've ever been on. Dave Rupert LLC: Definitely and we didn't even do anything illegal or quid pro quo'y. </tt>
Right here on CSS-Tricks. See, in my early days, I learned about that element and how its job is to set text as monospace. I thought, oh! like code! and then for years that's how I marked up code on this site. I had never heard of the <code> element! When I did, I switched over to that. But I still haven't updated every single article from <tt> to <code>. It lingers in articles like this:
I bring this up just because it's a funny little example of not knowing what you don't know. It's worth having a little sympathy for people early in their journey and just doing things that get the job done because that's all they know. We've all been there... and are always still there to some degree.
Recently, I had a chat with Chris Coyier and Dave Rupert over on the Shoptalk Podcast about writing for publications such as Smashing Magazine and CSS-Tricks. One of the things we talked about was submitting ideas to publications — something that can feel quite daunting even as an experienced writer.
In this article, I’m going to go through the process for pitching, heavily based on my own experience as a writer and as Editor in Chief of Smashing. However, I’ve also taken a look at the guidelines for other publications in order to help you find the right places to pitch your article ideas.
Do Your Research
Read existing articles on the site that you would like to write for. Who do they seem to be aimed at? What tone of voice do the writers take? Does the publication tend to publish news pieces, opinion, or how-to tutorials? Check to see if there are already other pieces which are on the same subject as your idea, i.e. will your piece add to the conversation already started by those articles? If you can show that you are aware of existing content on a particular subject, and explain how you will reference it or add to that information, the editor will know you have done some research.
Research more widely; are there already good pieces on the subject that an editor will consider your piece to be a repeat of? There is always space for a new take on an issue, but in general, publications want fresh material. You should be ready to explain how your piece will reference this earlier work and build upon it, or introduce the subject to a new audience.
A good example from our own archives is the piece, “Replacing jQuery With Vue.js”. There are a lot of introductions to Vue.js, however, this piece was squarely aimed at the web developer who knows jQuery. It introduced the subject in a familiar way specifically for the target audience.
Find The Submission Guide
The next thing to do is to find the submission information on the site you want to write for. Most publications will have information about who to contact and what information to include. From my point of view, simply following that information and demonstrating you have done some research puts you pretty high up the queue to be taken seriously. At Smashing Magazine, we have a link to the guide to writing for us right there on the contact form. I’d estimate that only 20% of people read and follow those instructions.
The link to our submission guide on our Contact Us page.
When you submit your idea, it is up to you to sell it to the publication. Why should I run with your idea over the many others that will show up today? Spending time over your submissions will make a huge difference in how many pieces you have accepted.
Different publications have different requirements. At Smashing Magazine, we ask you to send an outline first, along with some information about you so that we can understand your expertise in the subject matter. We’re very keen to feature new voices, and so we’ll accept pieces from writers who haven’t got a huge string of writing credentials.
The information we request helps us to decide if you are likely to be able to deliver a coherent piece. As our articles are technical in nature (often tutorials), I find that an outline is the best way to quickly see the shape of the proposal and the scope it will cover. A good outline will include the main headings or sections of the article, along with an explanation of what will be taught in that section.
For many other publications, a common request is for you to send a pitch for the article. This would typically be a couple of paragraphs explaining the direction your piece will take. Once again, check the submission guide for any specific details that publication is interested to see.
The Verge has an excellent submission guide which explains exactly what they want to see in a pitch:
“A good pitch contains a story, a narrative backbone. Pitches should clearly and concisely convey the story you plan to write and why it matters. The best pitches display promising pre-reporting and deep knowledge of the topic as well as a sense of the angle or insight you plan to pursue. If your story depends on access to a person or company, you should say whether you have obtained it already (and if not, what your prospects are). Pitches should also be written in the style you expect to write the story.”
A List Apart explains what they will accept in their contribution page:
“... a rough draft, a partial draft, or a short pitch (a paragraph or two summarizing your argument and why it matters to our readers) paired with an outline. The more complete your submission is, the better feedback we can give you.”
The Slate has a list of Do’s and Don’ts for pitching:
“Do distill your idea into a pitch, even if you have a full draft already written. If you happen to have a draft ready, feel free to attach it, but please make sure you still include a full pitch describing the piece in the body of the email.”
Including your pitch or outline in the body of the email is a common theme of pitch guidelines. Remember that your aim is to make it as easy as possible for the editor to think, “that looks interesting”.
Include A Short Biography
The editor doesn’t need your life story, however, a couple of sentences about you is helpful. This is especially useful if you are a newer writer who has subject matter expertise but fewer writing credentials. If you are proposing an article to me about moving a site from WordPress to Gatsby, and tell me that the article is based on your experience of doing this on a large site, that is more interesting to me than a more experienced writer who has just thought it would be a good topic to write about.
If you do have writing credits, a few relevant links are more helpful than a link to your entire portfolio.
When You Can’t Find A Submission Guide
Some publications will publish an email address or contact form for submissions, but have no obvious guide. In that case, assume that a short pitch as described above is appropriate. Include the pitch in the body of the email rather than an attachment, and make sure you include contact details in addition to your email address.
If you can’t find any information about submitting, then check to see if the publication is actually accepting external posts. Are all the articles written by staff? If unsure, then get in touch via a published contact method and ask if they accept pitches.
I’ve Already Written My Article, Why Should I Send An Outline Or Pitch?
We ask for an outline for a few reasons. Firstly, we’re a very small team. Each proposal is assessed by me, and I don’t have time in the day to read numerous 3000-word first draft proposals. In addition, we often have around 100 articles in the writing process at any one time. It’s quite likely that two authors will want to write on the same subject.
On receiving an outline, if it is going in a similar direction to something we already have in the pipeline, I can often spot something that would add to — rather than repeat — the other piece. We can then guide you towards that direction, and be able to accept the proposal where a completed piece may have been rejected as too similar.
If you are a new writer, the ability to structure an outline tells me a lot about your ability to deliver us something useful. We are going to spend time and energy working with you on your article, and I want to know it will be worthwhile for all of us.
If you are an experienced writer, the fact that you have read and worked with our guidelines tells me a lot about you as a professional. Are you going to be difficult for our editorial team to work with and refuse to make requested changes? Or are you keen to work with us to shape a piece that will be most useful and practical for the audience?
In The Verge submission guide included above, they ask you to “clearly and concisely” convey the story you plan to write. Your pitch shouldn’t be an article with bits removed or about the first two paragraphs. It’s literally a sales pitch for your proposed article; your job is to make the editor excited to read your full proposal! Some publications — in particular those that publish timely pieces on news topics — will ask you to attach your draft along with the pitch, however, you still need to get the editor to think it is worth opening that document.
Promoting Yourself Or Your Business
In many guides to self-promotion or bootstrapping the promotion of a startup, writing guest posts is something that will often be suggested. Be aware that the majority of publications are not going to publish an advert and pay you for the privilege.
Writing an article that refers to your product may be appropriate, as most of our expertise comes from doing the job that we do. It is worth being upfront when proposing a piece that would need to mention your product or the product of the company you work for. Explain how your idea will not be an advert for the company and that the product will only be mentioned in the context of the experience gained in your work.
Some publications will accept a trade of an article for some promotion. CSS-Tricks is one such publication, and describes what they are looking for as follows:
“The article is intended to promote something. In that case, no money changes hands. In this scenario, your pitch must be different from a sponsored post in that you aren’t just straight up pitching your product or service and that you’re writing a useful article about the web; it just so happens to be something that the promotion you’ll get from this article is valuable to you.”
Writing for a popular publication will give you a byline, i.e. your credit as an author. That will generally give you at least one link to your own site. Writing well-received articles can be a way to build up your reputation and even introduce people to your products and services, but if you try and slide an advert in as an article, you can be sure that editors are very well used to spotting that!
Pitching The Same Idea To Multiple Publications
For time-sensitive pieces, you might be keen to spread the net. In that case, you should make publications aware of submitting that you have submitted it elsewhere. Otherwise, it is generally good practice to wait for a response before offering the piece to another publication. The Slate writes,
“Do be mindful if you pitch your idea to multiple publications. We try to reply to everyone in a timely manner, typically within one to two days. As a general rule, and if the story isn’t too timely, it’s best to wait that amount of time before sharing the pitch with another publication. If you do decide to cast a wide net, it’s always helpful to let us know ahead of time so we can respond accordingly.”
You will have ideas rejected. Sometimes, the editor will let you know why, but most often you’ll get a quick no, thanks. Try not to take these to heart; there are many reasons why the piece might be rejected that have nothing to do with the article idea or the quality of your proposal.
The main reasons I reject pitches are as follows:
Obvious Spam
This is the easy one. People wanting to publish a “guest post” on vague subjects, and people wanting “do-follow links”. We don’t tend to reply to these as they are essentially spam.
No Attempt At A Serious Outline
I can’t tell anything about an idea from two sentences or three bullet points, and if the author can’t spend the time to write an outline, I don’t think I want to have a team member working with them.
Not A Good Topic For Us
There are some outlines that I can’t ever see being a great fit for our readers.
An Attempt To Hide An Advert
In this case, I’ll suggest that you talk to our advertising team!
Difficult To Work With
Last but not least, authors who have behaved so badly during the pitch process that I can’t bring myself to inflict them on anyone else. Don’t be that person!
If I have a decent outline on a relevant subject in front of me, then one of two things are going to happen: I’ll accept the outline and get the author into the writing process or I’ll reply to the author because there is some reason why we can’t accept the outline as it is. That will usually be because the target audience or tone is wrong, or we already have a very similar piece in development.
Quite often in these scenarios, I will suggest changes or a different approach. Many of those initial soft rejections become an accepted idea, or the author comes back with a different idea that does indeed work.
Ultimately, those of us who need to fill a publication with content really want you to bring us good ideas. To open my inbox and find interesting pitches for Smashing is a genuine highlight of my day. So please do write for us.
Things To Do
Research the publication, and the type of articles they publish;
Read their submissions guide, and follow it;
Be upfront if you have sent the pitch to other publications;
Include a couple of sentences about you, and why you are the person to write the article. Link to some other relevant writing if you have it;
Be polite and friendly, but concise.
Things To Avoid
Sending a complete draft along with the words, “How do I publish this on your site?”;
Sending things in a format other than suggested in the submissions guide;
Pitching a piece that is already published somewhere else;
Pitching a hidden advert for your product or services;
Following up aggressively, or sending the pitch to multiple editors, Facebook messenger, and Twitter, in an attempt to get noticed. We publish a pitch contact, because we want pitches. It might take a day or two to follow up though!
This isn’t our first rodeo! I started ARTIFACT back in 2013 with Christopher Schmitt and Ari Stiles (the team behind the legendary In Control and CSS Dev conferences). At that time, the sudden avalanche of web-enabled mobile devices was throwing the web design community for a loop. How do we best leverage the recently-introduced Responsive Design techniques to adapt our designs to a spectrum of screen sizes?! What does that do to our workflows?! What happens to our beloved Photoshop comps?! How do we educate our clients and structure our billing cycles?! It was an exciting time when we needed to adjust our processes quickly to take on a radically new web viewing environment.
After four events in 2013 and 2014, ARTIFACT took a little hiatus, but we are back for a five-year reunion in 2019. We are returning to a landscape where a lot of the challenges we faced in 2013 have been figured out or, at the very least, have settled down (although there is always room for innovation and improvement).
Is our work making the web better done? Not by a long shot! Now that we’ve got a handle on the low-bar requirement of getting something readable on all those screens, we can focus our energy on higher-order challenges. How do we make our sites work easier for people of all abilities? How do we make our content, products, and services welcoming to everyone? Does our code need to be so bloated and complicated? How can we make our sites simpler and faster? How can I put new tools like CSS Grid, Progressive Web Apps, static sites, and animation to good use?
To that end, this time around ARTIFACT is expanding its focus from “designing for all the devices” to “designing for all the people.” Simply put, we want a web that doesn’t leave anyone out, and we’ve curated our program to address inclusivity, performance, and the ways that new possibilities on the web affect our workflow.
A web for everyone
Inclusive design—including accessibility, diversity, and internationalization—has been bubbling to the top of the collective consciousness of the web-crafting community. I’m incredibly encouraged to see articles, conference talks, and podcasts devoted to improving the reach of the web. At ARTIFACT, inclusivity is a major theme that winds its way throughout our program.
Photo by Jopwell from Pexels
Benjamin Evans will talk about his efforts as the Inclusive Design Lead at AirBnB to create a user experience that does not alienate minority communities.
Accessibility expert Elle Waters will share best practices for integrating accessibility measures into our workflows..
We’ll also hear from David Dylan Thomas on how to recognize and address cognitive bias that can affect content and the overall user experience.
Even better performance
Visitors may also be turned away from our sites if pages take too long to load or use too much data. We know performance matters, yet sites on the whole grow more bloated with every passing year. Tim Kadlec (who knows more about performance than just about anybody) will examine the intersection of performance and inclusion in his talk “Outside Looking In” with lots of practical code examples for how to do better.
We’ll also look at performance through the lens of Progressive Web Apps (presented by Jason Grigsby of Cloud Four). In fact, improving performance is a subtext to many of our developer-oriented talks.
Leveraging the modern browser
In the Good News Department, another big change since the first ARTIFACT is that browsers offer a lot more features out of the box, allowing us to leverage native browser behavior and simplify our code (Viva Performance!). Chris Ferdinandi will be demonstrating exactly that in his talk “Lean Web Development,” where he’ll point out ways that taking advantage of built-in browser functionality and writing JavaScript for just the interactivity you need may make a big framework unnecessary.
Better native browser features also means un-learning some of our old coping mechanisms. We’ll get to delight at all the polyfills and workarounds that have been kicked to the curb since 2012 in Dave Rupert’s tale of “The Greatest Redesign Ever Told,” and we’ll see what best practices make sense going forward.
Workflow and process
One thing that hasn’t changed—and likely never will—is that never-ending hamster wheel of trying to keep up with an ever-changing web development landscape. I’m guessing that if you are reading CSS-Tricks right now, you know that feeling. The methods we use to build the web are always evolving with new tools, approaches, and possibilities, which is why best practices for adapting our workflows and processes have always been a central focus at ARTIFACT. This year is no different. Jen Simmons will share her thinking process for designing a CSS grid-based layout by live-coding a site before our very eyes.
Design systems, which have become a cornerstone of large-scale site production, get the treatment in talks by Kim Williams, Dan Mall, and Brad Frost. (Dan and Brad are also running their acclaimed “Designer + Developer Collaboration Workflow” workshop on October 3.)
Divya Sasidharan will show off the possibilities and performance advantages of static sites in her “JAMstackin” presentation
We’ll get a glimpse of the future of web animation from Sarah Drasner. (She’s bringing her popular “Design for Developers” workshop on October 3 as well).
The web can always do better to serve the people who use it. We’re proud to provide an occasion for designers and developers who care about putting their users front and center to mingle and share ideas. And yes, there will be milkshakes! The very best milkshakes.
