Category: Design

What Does it Mean to Be “Full Stack”?

I was asked this recently by a fellow developer who was at the same web tech conference I was at. This developer had met a lot of new people who literally introduced themselves as full-stack developers sort of the way Bob Vance, Vance Refrigeration would on The Office, but it was Tony Frank, Full-Stack Developer instead.

I suspect the developer asking the question taken from the title of this post already knew the basic idea of what people mean by “full-stack developer,” but was wondering what the heck it’s all about. There was a tone in the question. A tone that suggested this person isn’t exactly in love with the term.

These days, probably a bit of DevOps (e.g. Git, testing, and getting sites to production). The “stack” is all these things combined, so a full-stack developer is shorthand for: when it comes to building websites, I can do it all.

There are some stacks that have achieved notoriety over the years. Maybe you’ve heard of the LAMP stack?

Linux Apache MySQL PHP

A full-stack developer on that stack means you know Linux, Apache, MySQL, and PHP. (Abstractly: server software, web server, database, back-end language.) This site runs on that stack, and I’m solely responsible for its development, so I guess I’m a full-stack developer in some loose sense.

But “loose” is a generous interpretation. I don’t know the first thing about Linux, except that’s what runs my web servers. I don’t know much about Apache, except that I sometimes use HTAccess directives to do things. I could count the number of MySQL queries I’ve written on my two hands, and I only really know PHP in the context of WordPress.

Looked at that way, I’m barely a developer at all. Full stack, on the other hand, generally refers to tossing front-end tasks into the mix and I’m competent enough in that space that my front-end skill set alone, has allowed me to build dozens (or hundreds!) of sites throughout my career. Full-stack-enough, anyway.

There are loads of other stacks.

LAMP isn’t particularly prescriptive about how you build the front-end. It came from an era where it was assumed you’d build a back end to spit out HTML and that’s your front end.

Another stack that’s achieved notoriety since the Grand Arrival of JavaScript is the MEAN stack.

MongoDB Express Angular Node

It is perfectly plausible to replace parts of a stack. Perhaps you’d use Nginx instead of Apache, or PostgreSQL instead of MySQL in what’s otherwise LAMP stack. MEAN is notable in that every layer of the stack was replaced with new technology. Node brought JavaScript to the back end, which could power web servers, handle routing, connect data sources, run build processes, compile code, and more.

A full-stack developer in this world is writing nearly everything in JavaScript. No wonder there is somewhat of an explosion of people considering themselves “full” stack. A single language, like JavaScript, that runs in browsers itself and is a paramount front-end technology is a widely transferrable skill.

The MEAN stack can have layers swapped out just as easily as LAMP. Perhaps you use a data store like Fauna or Firebase instead. Perhaps you use Vue or React instead of Angular. Perhaps you don’t need Express because you leave your routing to a framework or do it client-side.

Shawn Wang calls another a popular stack STAR:

Design Systems TypeScript Apollo React

That’s JavaScript all the way down.

It’s notable that, while we’re still thinking of this as a stack, we’re thinking less about our servers and server software to the point they aren’t really a key part of the stack. Not that developers and companies don’t take it seriously, but it’s more abstracted now than it has traditionally been. I’d point to the world of serverless as a case in point. The questions aren’t about what operating system our servers should use; it’s what platform is the most cost-effective to run our JavaScript functions.

So, stacks evolve over time. But it’s not just what technologies they use, but what technology we even consider a part of a stack. What full-stack means morphs over time.. We’re in a place right now where knowing JavaScript grants you a full-stack merit badge. You can work with client site frameworks, architect components and piece them together to build an entire front end. You can write web servers. You can write back-end code that talks to APIs. You can do all the state management you need. You can construct build processes and deployment pipelines. You can even bring CSS into JavaScript if you’re so inclined.

Even if you’re largely focused on JavaScript, people’s skillsets are generally wider than that. Throw in some HTML and CSS competency, Git foo, and a little DevOps hobby and you’re a real web powerhouse. You can do it all! A renaissance man! Lord of the seven kingdoms!

I think that’s kinda awesome, actually. It truly empowers developers. While it’s worth considering where the barriers of entrance for front-end development or high, it’s also interesting to consider all the places where that bar has been lowered. It’s particularly cool for me to see front-end development grow and grow to the point of nearly swallowing up the entire stack. The All-Powerful Front-End Developer, as it were.

It reminds me an awful lot of how powerful being a WordPress site-slinger feels. You can do a lot, even if you don’t deeply understand every little bit of it.

My conference acquaintance went on:

Why are some developers so proud of being a full stack? Many of them say it with a prideful smile. They, for some reason, feel the need to emphasize full stack when introducing themselves.

I suspect it’s just that: Pride.

Pride is a tricky thing. It meant the world to me when my parents ceaselessly told me they were proud of me or something I did. A positive thing on both sides. But, strangely enough, pride is also one of the seven deadly sins and one, as they say, that might be the root of all the rest. I don’t want to over-blow things, but I think there is some connection here. It’s one thing to be empowered and to feel strong and capable, but it’s another to be boastful and not sense the edges of your ability.

We’ve all got plenty of edges, particularly when it comes to doing an exemplary job versus merely getting the job done. Standing out these days requires being exemplary. How is your visual design skill? Are you building design systems or implementing existing ones? How many years have you maintained systems? Do you have a good eye for the most painful kinds of technical debt? How are you at helping co-workers succeed? Can you facilitate a user testing session? How good are you at diagnosing performance bottlenecks? What if there are serious server problems? Does your full stack moniker help you comprehend server logs? Are you versed in accessibility audits? Have you ever dealt with tricky relational data and slow queries?

I’m not trying to convince anyone they aren’t a full-stack developer or don’t deserve that particular merit badge — just that the web is a big place with divergent needs and ever-morphing stacks that all require different sets of skills. If you’re interviewing for a job asking for a full-stack developer, by all means, tell them how full-stack-y you are.

The post What Does it Mean to Be “Full Stack”? appeared first on CSS-Tricks.


, ,

INTI’s Gigantic Mural Art Adds Some Poetry to the Streets


The “Inside” Problem

So, you’re working on a design. You need a full-width container element because the design has a background-color that goes from edge-to-edge horizontally. But the content inside doesn’t necessarily need to be edge-to-edge. You want to:

  1. Limit the width (for large screens)
  2. Pad the edges
  3. Center the content

It’s “the inside problem” in web layout. It’s not hard, it’s just that there are lots of considerations.

The classic solution is an outer and inner container.

The parent element is naturally as wide as it’s own parent, and let’s assume that’s the <body> element, or the entire width of the browser window. That takes the background-color and pads the left and right sides. The inside element is what limits the width inside and centers.

<footer>   <div class="inside">     Content   </div> </footer>
footer {   --contentWidth: 400px;   background: lightcoral;   padding: 2rem 1rem; }  .inside {   max-width: var(--contentWidth);   margin: 0 auto; }

This is what my brain reaches for first. Doesn’t use anything fancy and feels perfectly understandable. That “inside” element isn’t wonderfully desirable, only because it feels like busywork to remember to add it to the markup each time this pattern is used, but it does the trick with few other downsides.

See the Pen
Classic "inside" element
by Chris Coyier (@chriscoyier)
on CodePen.

What if you only can use a single element?

These type of limitations aren’t my favorite, because I feel like a healthy project allows designers and developers to have whatever kind of control over the final HTML, CSS, and JavaScript output they need to do the best possible job. But, alas, sometimes you’re in a weird position as a contractor or have legacy CMS issues or whatever.

If you only have a single element to work with, padding sorrrrrta kinnnnda works. The trick is to use calc() and subtract half of the content’s maximum width from 100%.

<footer>   Content </footer>
footer {   --contentWidth: 600px;      background: lightcoral;   padding: 2rem calc((100% - var(--contentWidth)) / 2); }

See the Pen
by Chris Coyier (@chriscoyier)
on CodePen.

The problem here is that it doesn’t prevent edge-touching, which might make this entirely unacceptable. Maybe you could select elements inside (paragraphs and whatnot…) and add padding to those (with a universal selector, like footer > *). It’s tempting to put padding way up on the <body> or something to prevent edge-touching, but that doesn’t work because we want that edge-to-edge background color.

What if you’re already inside a container you can’t control and need to break out of it?

Well, you can always do the ol’ full-width utility thing. This will work in a centered container of any width:

.full-width {   width: 100vw;   margin-left: 50%;   transform: translateX(-50%); }

But that leaves the content inside at full width as well. So, you’d need to turn to an inside element again.

See the Pen
Full width element with inside element
by Chris Coyier (@chriscoyier)
on CodePen.

Also, as soon as you have a vertical scrollbar, that 100vw value will trigger an obnoxious horizontal scrollbar. Some sites can pull off something like this to get rid of that scroll:

body { overflow-x: hidden; }

That’s pretty nice. If you can’t do that, though, you might need to set an explicit width on the scrollbar, then subtract that from 100vw.

body {   scrollbar-width: 20px; /* future standards way */ }  body::-webkit-scrollbar { /* long-standing webkit way */   width: 20px; }  .full-width {   width: calc(100vw - 20px); }

Even that kinda sucks as it means the full-width container isn’t quite full width when there is no vertical scrolling. I’d love to see CSS step it up here and help, probably with improved viewport units handling.

There are a variety of other ways of handling this full-width container thing, like Yanking to the edges with margins and such. However, they all ultimately need viewport units and suffer from the same scrollbar-related fate as a result.

If you can definitely hide the overflow-x on the parent, then extreme negative-margin and positive-padding can do the trick.

This is kinda cool in that it uses nothing modern at all. All very old school CSS properties.

See the Pen
Full Width Bars Using Negative Margins
by Chris Coyier (@chriscoyier)
on CodePen.

Can CSS Grid or Flexbox help here?

Meh. Not really.

I mean, sure, you could set up a three-column grid and place the content in the center column, while using the outside columns as padding. I don’t think that’s a particularly compelling use of grid and it adds complication for no benefit — that is, unless you’re already using and taking advantage of grid at this scope.

Fake the edges instead.

There is no law that the background-color needs to come from one single continuous element. You could always “fake” the left and right sides by kicking out a huge box-shadow or placing a pseudo element wherever needed.

We cover various techniques around that here.

The post The “Inside” Problem appeared first on CSS-Tricks.



Creating a Diversity Scholarship Program for Your Conference

My partner and I ran a design and development conference company for eight years. During that time, we produced hundreds of hours of conferences, both on-site and online. Diversity scholarships were only becoming a typical conference offering around the time we decided to sunset our business. So, when we committed to collaborate on an updated ARTIFACT conference, I knew right away I wanted to make Diversity Scholarships available.

We always worked on making our events inclusive, so adding a program that would enhance that inclusion even more seemed like a no-brainer. When I started to research how to create a diversity scholarship program, though, the only examples I could find were finished programs, and not much documentation about the thinking or planning that created them. It’s not unusual to improvise a solution to a problem and make changes on the fly, in fact it’s pretty routine when you run a small business. A diversity scholarship program was something I wanted to get right, though — or at least as “right” as possible — the first time around. I decided to look a little deeper than what was available online.

Twitter helped me find conference organizers who had created and run diversity scholarship programs. I ended up talking to several organizers about their experiences, in addition to comparing a couple dozen programs and applications online.

Between sessions at the Open Source Summit (photo courtesy of the Linux Foundation)

Before we dive in

There are two types of readers I’d like to address:

  1. If you don’t think the lack of diversity in tech is a problem, or don’t see why a scholarship program is necessary, this article is not for you. It is written with the assumption that the reader is already convinced of the merits of diversity, and is looking for ways to build a more diverse audience at the conferences or tech events they host; or
  2. If you are overwhelmed by the lack-of-diversity-in-tech issue, so much that you feel uncomfortable even addressing it, you are not alone. The problem is systemic, with deep, historical roots. It’s important to remember that you alone cannot solve the problems of an entire industry with one program or one event. Focus instead on what you can create, even with limited resources. Ask for help when you need it — most conference organizers I’ve met are glad to help.

From the beginning

So much of the planning for an inclusive conference takes place before you even begin talking about things like diversity scholarships. If your destination city is a relatively inexpensive and easy place to visit; if your venue is accessible and you’ve made plans for accommodations like live captioning; if your ticket prices are reasonable; and if your speaker lineup is genuinely diverse, you’ve got a strong foundation to build on.

Most of this can be accomplished with research. Cities popular with tourists tend to have reasonable transportation and accommodation prices. Cities with big tech hubs often have large, sometimes state-of-the art meeting spaces to hold conferences. Finding cities that have both can be a challenge, but the combination ultimately makes your conference more accessible to different types of attendees.

Creating a diverse lineup of speakers may attract a more diverse set of attendees (left to right: Sample speaker lineups from Hopper Celebration, Alterconf, and Clarity Conference)

A little more work may have to go into your speaker lineup. Although there has been some progress on this issue, the majority of tech conferences still mostly feature white men. There have been plenty of articles written on how to create a diverse speaker lineup, but one of my favorite tips is to focus on your conference content first and foremost. Thinking in terms of content makes it easier to look past a potential speaker’s popularity. It also works against your natural bias toward picking “friends” or people you have worked with before. By focusing instead on the content a speaker provides, you can evaluate how that content might add to your overall theme and how it might affect your audience. Curating content is more work than just lining up a group of well-known speakers, but it pays off in the form of a more focused conference and — usually — a more diverse lineup.

You’ll also need to encourage open discussion among your co-organizers about diversity issues. My first job in conference planning was for South by SouthWest Interactive (SXSWi), and I feel lucky to have gotten my start working in an environment where these discussions were regular, open, and just “part of the process.” As with any skill, the more you practice talking about diversity, the easier it becomes.

Craft Conference has put together a video about their diversity program. These testimonials may help further the conversation with your colleagues.

Ask yourself why

Diversity and equity scholarship programs have become popular offerings at tech conferences for many reasons. We need more diversity in the industry, and the current thinking is that more diverse conferences can create more leadership and presentation opportunities for underrepresented populations. Diversity can lead to more robust discussions, too. This goal stated plainly on the Web site for #Perfmatters, run by Estelle Weyl:

“We want to ensure the conversation is stimulating and help everyone see their own Web app issues from new and different perspectives. For that, we need attendees with different perspectives. While we love everyone, conferences where all attendees come from corporations with generous continuing education budgets aren’t as interesting for participants as when attendees represent different work and life experiences.”

It can be useful to do a little soul-searching to think about why you and your co-organizers want to do this. “More than anything,” says Tenessa Gemelke, organizer of Confab, “we wanted to remove obstacles, not just check boxes.” It’s easy to tell ourselves that because we’ve recruited a few women or people of color, we’ve “taken care of” conference diversity and we can move on to the next task. The needs of your diversity scholarship recipients are not checklist items — they are the building blocks of a more inclusive community.

Brainstorming a bit about the reasons you want to build a diversity scholarship program can help you set goals, identify problems specific to your target audience, and define limits. You might even discover that you have secondary objectives, which is not unusual.

Justin Reese is the Founder of Code & Supply and co-creator of several conferences based in Pittsburgh, PA. In addition to the traditional uses for diversity scholarships, he and his staff occasionally use scholarship funds to send up-and-coming hometown speakers to other cities. “We want people to see the talent and resources we have here in Pittsburgh,” says Reese. He and his team think of Code & Supply scholarships as a way to showcase local talent and build a robust, diverse tech community in their home town.

At ARTIFACT, we think of diversity and inclusion as the future of technology. So, in addition to building a robust, inclusive community, we see our diversity scholarship program as a vital part of a forward-thinking conference. Techniques and workflow change not only because of new gadgets and platforms, but because of new audiences and different types of teams.

Taking stock

Once you’ve settled on your “why,” it’s best to determine your “what” — as in, what you have to offer. Do you have any resources or perks on hand that will require no help from sponsors? For example, some conferences have more space than they need. Can you give some tickets away for free, or at a discount? Or if you have limited space, can you make a few free or discounted tickets possible by bumping up the cost of your other tickets? Make a list of what you can offer for free or from simple changes to your conference plan.

Other services that you might consider offering through your diversity scholarship program:

  • Assisting with travel
  • Assisting with accommodations
  • Meal stipends
  • On-site childcare
  • On-site nursing / feeding spaces

Some organizers even make travel and hotel reservations for their diversity scholarship attendees. It makes sense — most conferences already make these arrangements for their presenters, so it’s easy to do it for a few more people. This service may help scholarship dollars stretch a little further too, if the extra travel or booked rooms are available at a bulk discount.

If you want to offer more than just the basics, you will probably have to work with sponsors. The good news here is that sponsors often enjoy investing in diversity initiatives. Before approaching a potential sponsor, though, it’s wise to be clear on how you plan to spend the money. Consider creating a one-sheet that states your goals, the underrepresented groups you are trying to recruit, and what perks the sponsor can expect for participating. This way, you have something to leave behind for sponsors who want to think it over or who need to present the idea to others before it gets approval. Be sure to include your contact information.

Set your goals

It’s useful to think about how many diversity scholarships you’d like to offer in an ideal situation. In practice, that perfect number will probably drop based on your budget or lack of space, but having a lofty goal may encourage you to try a little harder.

Among the conference organizers I spoke with, the number of diversity scholarship recipients ranged from two to fifteen percent of total ticket sales. Those with higher numbers started with higher goals.

Attendees at JSCamp Barcelona

Making it happen

Figuring out the logistics of a diversity scholarship plan may be the most complicated part of the process. Trying to figure out how to juggle all the tasks involved is what spurred me to do all this research in the first place!

Implementation will include some combination of the following steps, not necessarily in this order:

Put someone in charge

Your entire staff may be involved with processing diversity scholarships, but it’s a good idea to have one person oversee the whole program for the sake of continuity. There is a great deal of communication involved with this process, so it helps to choose a point person with strong organization and communication skills. The most significant qualification, though, is a real passion for creating a diverse conference community.

Create a reasonable timeline

With input from your team, set application deadlines, reviewing deadlines, and scholarship offer deadlines. Every organizer I spoke with suggested making these deadlines early in the process and sticking to them.

You’ll need enough time to review applications and make scholarship offers early enough to give your attendees time to plan. Remember that they might have to request time off work, make family care arrangements, and deal with other obligations. People from out of town need at least two months notice, and international attendees may need three months or more. Early deadlines help everyone. No one in your organization wants to review applications at the last minute anyway, since conference planning gets more intense in the weeks leading up to the event.

Any unclaimed scholarship resources can be used by qualified local attendees in the weeks leading up to your event. Since they don’t have to factor in travel or accommodations, it is easier for local attendees to make plans at the last minute.

Make your scholarship program easy to find

Devote a page to your diversity scholarship program on your site, then link to that page as reasonably often as possible. If you can‘t list it in your main menu, consider linking it from the site footer and from the ticket sales page, in addition to posting about it regularly on social media.

Clearly state who qualifies for aid

The list may vary a bit based on your typical audience, but we chose the following criteria:

  • People of color
  • Indigenous persons
  • People with disabilities
  • People who identify as LGBTQIA+
  • Women
  • Veterans and new graduates just beginning their tech careers
  • Full-time students
  • People who work for nonprofit/educational/government institution with limited funds
  • People who are 55 years old or older
  • People who are currently unemployed / underemployed
  • People experiencing temporary financial hardship

Be sure to list the types of aid available (determined earlier, when you were “taking stock“). It’s also good to let your applicants know that not every application will be accommodated, and that all applications will be verified.

Collect the information you need 

Most conferences use some kind of online application form to collect and organize data. If you are not able to code one yourself, Google Forms or Wufoo make it pretty easy to build a form. Keep the application as simple as you can — you’ll need:

  • name,
  • contact information,
  • the reason(s) they qualify for aid (instead of a blank field, consider listing qualifications on the form as a way of reiterating the types of attendees you are trying to recruit),
  • the type of aid they are requesting (again, listing they types of aid available will help applicants understand what’s possible), and
  • maybe a statement about why they want to attend or why they need aid at this time.

You’ll want the form to compile data in a way that will be easy to sort through later, like a spreadsheet.

Preserve the anonymity of your applicants

Asking for help in a society that values self-sufficiency over shared responsibility can be tough. Don’t make it harder by asking applicants to divulge too much personal information, participate in open interviews with committee members, or meet with sponsors as part of your program. If a committee will be reviewing applications, consider anonymizing the entries before review.

Verify applications

This should be an ongoing process for several reasons. Some applicants will qualify for your program for reasons that are not always verifiable, so the person doing the vetting may need to contact them and clarify the request.

Other applicants may either misunderstand or overlook your qualifying criteria. The most common mistake many applicants make is assuming they qualify for aid only because their employer won’t cover the cost of the conference. This is where additional information will help: why isn’t this covered? Does the company have very limited funds, or is their travel budget just maxed out already? Does the applicant qualify for a diversity scholarship on other grounds? Applicants should know early in the process if their application is refused or if more information is needed.

Evaluate applications

Once the application deadline is met, evaluation begins. If your applications have been properly vetted, then the hardest work is already done. If a committee is evaluating applications, it’s good to not only figure out a way to anonymize applications, but also to streamline the evaluation process. Maybe give each committee member two or three questions to rate for each applicant. Possible evaluation questions:

  • How clearly is the need for aid stated?
  • How much aid is needed?
  • How much would this attendee impact the conference?
  • How much would the conference impact this attendee?

These can be rated on a scale, maybe one to ten, with ten being highest. This makes calculating scores easy. Other data you might choose to consider: when was the application received? Do you want to consider more local applicants than those from out-of-town?

Make and process scholarship offers and refusals

Evaluations have been made, so you are probably left with a set of applicants you want to offer scholarships to, some applicants you are not sure about yet, and a few that you plan to refuse. Start by making offers to those applicants you want to help attend the conference. Clearly state how much help you are offering and a deadline for accepting or refusing the offer.

If you are working with a particularly long waiting list, or the process is going slowly (more than two weeks since you began awarding scholarships), it’s courteous to let people know they are on a waiting list.

At ARTIFACT, we are assuming that some applicants may have a change in plans and therefore may have to refuse the scholarship. In that case, we will be passing along their offer to the next person on our waiting list.

Once all the offers have been made and accepted, it’s time to email the rest of the applicants, thank them for their participation, and let them know they won’t be receiving a scholarship offer. If you can, it’s nice to offer something to those who didn’t receive a scholarship: maybe a discounted ticket if they still choose to attend, or an invitation to any after-hour events, where you have room for a few extra people.

Create feedback mechanisms

In addition to all the input you sought from your colleagues in the beginning, you’ll need feedback on every aspect of the program. Make that easy to do by including an email address or link to a feedback form on your scholarship description page, your application form, and anywhere else on your site that seems appropriate. Once you start awarding scholarships, make communication a high priority. Consider creating a way to collect anonymous feedback from scholarship awardees and sponsors—easier to do if you have a larger conference—to foster honest, less inhibited comments.

Wait and see (and listen)

Now that everything needed for your diversity scholarship program is in place, it’s time to follow your plan and take note of what works and what doesn’t. Stay flexible, as you may have to change some parts of your program on the fly. Keep thinking in terms of equity for all of your applicants, and communicate openly about any changes you make. Applicants are more likely to trust a transparent process.

Listen more than you talk. Always.

Scholarship recipients for the Tapia Conference, a conference that celebrates and nurtures diversity in computing

Follow up

Once ARTIFACT 2019 has concluded, I’ll be compiling all of our results and feedback in one place and writing a follow-up to this article. Until then, I’d like to thank all the conference organizers who took the time to answer my questions about diversity scholarship programs: Tenessa Gemelke, Estelle Weyl, Justin Reese, Val Head, Dave Poole, Jenn Strater, Ádám Boros, and PJ Hagerty.

In the meantime, here are some other resources you might find helpful:

The post Creating a Diversity Scholarship Program for Your Conference appeared first on CSS-Tricks.


, , , ,

Design Deals for the Week


Discover Form, a Free Front-end Kit With Data Management Included


Footnotes That Work in RSS Readers

Feedbin is the RSS reader I’m using at the moment. I was reading one of Harry’s blog posts on it the other day, and I noticed a nice little interactive touch right inside Feedbin. There was a button-looking element with the number one which, as it turned out, was a footnote. I hovered over it, and it revealed the note.

The HTML for the footnote on the blog post itself looks like this:

<p>...they’d managed to place 27.9MB of images onto the Critical Path.  Almost 30MB of previously non-render blocking assets had just been  turned into blocking ones on purpose with no escape hatch. Start  render time was as high as 27.1s over a cable connection<sup id="fnref:1"> <a href="#fn:1" class="footnote">1</a></sup>.</p>

Just an anchor link that points to #fn:1, and the <sup> makes it look like a footnote link. This is how the styling would look by default:

The HTML for the list of footnotes at the bottom of the blog post looks like this:

<div class="footnotes">   <ol>     <li id="fn:1">      <p>5Mb up, 1Mb down, 28ms RTT.&nbsp;<a href="#fnref:1" class="reversefootnote">&#x21a9;</a></p>     </li>   </ol> </div>

As a little side note, I notice Harry is using scroll-behavior to smooth the scroll. He’s also got some nice :target styling in there.

All in all, we have:

  1. a link to go down and read the note
  2. a link to pop back up

Nothing special there. No fancy libraries or anything. Just semantic HTML. That should work in any RSS reader, assuming they don’t futz with the hash links and maintain the IDs on the elements as written.

It’s Feedbin that sees this markup pattern and decides to do the extra UI styling and fancy interaction. By inspecting what’s going on, it looks like they hide the originals and replace them with their own special stuff:

Ah ha! A Bigfoot spotting! It’s right in their source.

That means they fire off Bigfoot when articles are loaded and it does the trick. Like this:

See the Pen
Bigfoot Footnotes
by Chris Coyier (@chriscoyier)
on CodePen.

That said, it’s based on an already functional foundation. Lemme end this with that same markup pattern, and I’ll try to look at it in different RSS readers to see what they do. Feel free to report what it does in your RSS reader of choice in the comments, if it does anything at all.

Azul is an abstract board game designed by Michael Kiesling and released by Plan B Games1 in 2017. From two to four players collect tiles to fill up a 5×5 player board. Players collect tiles by taking all the tiles of one color from a repository, and placing them in a row, taking turns until all the tiles for that round are taken. At that point, one tile from every filled row moves over to each player’s 5×5 board, while the rest of the tiles in the filled row are discarded. Each tile scores based on where it is placed in relation to other tiles on the board. Rounds continue until at least one player has made a row of tiles all the way across their 5×5 board.

  1. Plan B makes other cool games like Century and Reef. 

The post Footnotes That Work in RSS Readers appeared first on CSS-Tricks.


, ,

Weekly news: PWA Issue on iOS, Performance Culture, Anti-Tracking in Browsers

Šime posts regular content for web developers on Each week, he covers timely news at the intersection of development standards and the tools that make them available on the web.

Installed PWAs cannot easily be restarted on iOS

Maximiliano Firtman: On iOS, it is not possible to restart an installed PWA by closing it from the recently used apps screen and then immediately reopening it. Instead of restarting the app, iOS restores its state. This can be a problem for users if the PWA gets stuck in a broken state.

After some undefined time, the saved context seems to disappear. So if you get out of the PWA, do nothing with your phone and wait some hours to go back to the PWA, it restarts from scratch.

Instilling a performance culture at The Telegraph

Gareth Clubb: At The Telegraph (a major UK newspaper), we set up a web performance working group to tackle our “organizational” performance challenges and instill a performance culture. The group meets regularly to review third-party tags and work on improving our site’s performance.

We’ve started deferring all JavaScript (including our own) using the <script defer> attribute. This change alone nearly doubled our (un-throttled) Lighthouse performance score.

Deferring our JavaScript hasn’t skewed any existing analytics and it certainly hasn’t delayed any advertising. […] The First Ad Loaded metric improved by an average of four seconds.

We also removed 1 MB of third-party payload from our new front end. When one of our teams requests the addition of any new script, we now test the script in isolation and reject it if it degrades our metrics (first contentful paint, etc.).

When we started this process, we had a collection of very old scripts and couldn’t track the original requester. We removed those on the premise that, if they were important, people would get back in touch — no one did.

Microsoft plans to add tracking prevention to the Edge browser

Kyle Pflug: Microsoft has announced plans to add options for blocking trackers to the Edge browser. Malicious trackers would be blocked automatically, and the user would have the option to additionally block all potential trackers.

This would make Edge the fourth major browser with some form of built-in anti-tracking feature (two other major browsers, Opera and UC Browser, include ad blockers instead).

  1. In 2015, Firefox added Tracking Protection — recently renamed to Content Blocking — becoming the first major browser to protect users from third-party trackers (when browsing the web in private mode).
  2. Since 2017, Safari prevents cross-site tracking by default, through a feature called Intelligent Tracking Prevention (ITP). Users are prompted to allow tracking when they try to interact with third-party widgets on websites.

  3. Earlier this year, Samsung Internet added an experimental feature called Smart Anti-Tracking that denies third-party trackers access to cookies.

The post Weekly news: PWA Issue on iOS, Performance Culture, Anti-Tracking in Browsers appeared first on CSS-Tricks.


, , , , , ,

Everything You Ever Wanted to Know About inputmode

The inputmode global attribute provides a hint to browsers for devices with onscreen keyboards to help them decide which keyboard to display when a user has selected any input or textarea element.

<input type="text" inputmode="" /> <textarea inputmode="" />

Unlike changing the type of the form, inputmode doesn’t change the way the browser interprets the input — it instructs the browser which keyboard to display.

The inputmode attribute has a long history but has only very recently been adopted by the two major mobile browsers: Safari for iOS and Chrome for Android. Before that, it was implemented in Firefox for Android way back in 2012, and then subsequently removed several months later (though it is still available via a flag).

Almost six years later, Chrome for Android implemented the feature — and with the recent release of iOS 12.2, Safari now supports it too.

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


Chrome Opera Firefox IE Edge Safari
66 53 20 No 75 No

Mobile / Tablet

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

But before we go deep into the ins and outs of the attribute, consider that the WHATWG living standard provides inputmode documentation while the W3C 5.2 spec no longer lists it in its contents, which suggests they consider it obsolete. Given that WHATWG has documented it and browsers have worked toward supporting it, we’re going to go assume WHATWG specifications are the standard.

inputmode accepts a number of values. Let’s go through them, one by one.


<input type="text" inputmode="none" />

We’re starting here because it’s very possible we don’t want any type of keyboard on an input. Using inputmode=none will not show a keyboard at all on Chrome for Android. iOS 12.2 will still show its default alphanumeric keyboard, so specifying none could be sort of a reset for iOS in that regard. Regardless, none is intended for content that renders its own keyboard control.


<input type="text" inputmode="numeric" />

This one is probably the one of the more common inputmode values out in the wild because it’s ideal for inputs that require numbers but no letters — things like PIN entry, zip codes, credit card numbers, etc. Using the numeric value with an input of type="text" may actually make more sense than setting the input to type="number" alone because, unlike a numeric input, inputmode="numeric" can be used with maxlength, minlength and pattern attributes, making it more versatile for different use cases.

The numeric value on Chrome Android (left) and iOS 12.2 (right)

I’ve often seen sites using type=tel on an input to display a numeric keyboard, and that checks out as a workaround, but isn’t semantically correct. If that bums you out, remember that inputmode supports patterns, we can add pattern="d*" to the input for the same effect. That said, only use this if you are certain the input should only allow numeric input because Android (unlike iOS) doesn’t allow the user to change to the keyboard to use letters, which might inadvertently prevent users from submitting valid data.


<input type="text" inputmode="tel" />

Entering a telephone number using a standard alphanumeric keyboard can be a pain. For one, each number on a telephone keyboard (except 1 and 0) represents three letters (e.g. 2 represents A, B and C) which are displayed with the number. The alphanumeric keyboard does not reference those letters, so decoding a telephone number containing letters (e.g. 1-800-COLLECT) takes more mental power.

The tel value on Chrome Android (left) and iOS 12.2 (right)

Using inputmode set to tel will produce a standard-looking telephone keyboard, including keys for digits 0 to 9, the pound (#) character, and the asterisk (*) character. Plus, we get those alphabetic mnemonic labels (e.g. ABC).


<input type="text" inputmode="decimal" />
The decimal value on Chrome Android (left) and iOS 12.2 (right)

An inputmode set to the decimal value results in a subtle change in iOS where the keyboard appears to be exactly the same as the tel value, but replaces the +*# key with a simple decimal (.). On the flip side, this has no effect on Android, which will simply use the numeric keyboard.


<input type="text" inputmode="email" />

I’m sure you (and at least someone you know) has filled out a form that asks for an email address, only to make you swap keyboards to access the @ character. It’s not life-threatening or anything, but certainly not a great user experience either.

That’s where the email value comes in. It brings the @ character into the fray, as well as the decimal (.) character.

The email value on Chrome Android (left) and iOS 12.2 (right)

This could also be a useful keyboard to show users who need to enter a Twitter username, given that@ is a core Twitter character for identifying users. However, the email address suggestions that iOS display above the keyboard may cause confusion.

Another use case could be if you have your own email validation script and don’t want to use the browsers built-in email validation.


<input type="text" inputmode="url" />
The url value on Chrome Android (left) and iOS 12.2 (right)

The url value provides a handy shortcut for users to append TLDs (e.g. .com or with a single key, as well keys typically used in web addresses, like the dot (.) and forward slash (/) characters. The exact TLD displayed on the keyboard is tied to the user’s locale.

This could also be a useful keyboard to show users if your input accepts domain names (e.g. as well as full URIs (e.g. Use type="url" instead if your input requires validating the input.


<input type="text" inputmode="search" />
The search value on Chrome Android (left) and iOS 12.2 (right)

This displays a blue Go key on iOS and a green Enter key on Android, both in place of where Return. As you may have guessed by the value’s name, search is useful for search forms, providing that submission key to make a query.

If you’d like to showSearch instead of Enter on iOS and a magnifying glass icon on Android in place of the green arrow, use type=search instead.

Other things you oughta know

  • Chromium-based browsers on Android — such as Microsoft Edge, Brave and Opera — share the same inputmode behavior as Chrome.
  • I haven’t included details of keyboards on iPad for the sake of brevity. It’s mostly the same as iPhone but includes more keys. Same is true for Android tablets, save for third-party keyboards, which might be another topic worth covering.
  • The original proposed spec had the values kana and katakana for Japanese input but they were never implemented by any browser and have since been removed from the spec.
  • latin-name was also one of the values of the original spec and has since been removed. Interestingly, if it’s used now on Safari for iOS, it will display the user’s name as a suggestion above the keyboard.

    The latin-name value displays my name as an auto-fill suggestion


Oh, you want to see how all of these input modes work for yourself? Here’s a demo you can use on a device with a touchscreen keyboard to see the differences.


, , , , ,

What Web Designers Need to Know About Cyber Security