DEV Community: Kushagra Gour

Top paid courses to learn CSS

Kushagra Gour — Thu, 12 Dec 2024 12:21:07 +0000

If you're looking to learn CSS (or get better at it), there are several excellent paid courses available that cater to different learning styles and levels. Here’s a roundup (in no particular order) of the best options currently on the Internet.

1. CSS for JavaScript Developers

Author: Josh W. Comeau
Options available: Basic, Pro and Ultimate packages.
Key Features:
- Includes videos, interactive exercises and a Discord community.
- Lifetime access to course materials and updates.
Website: css-for-js.dev

2. CSSBattle's Learn

Author: CSSBattle (Kushagra Gour)
Options available: Basic & Intermediate courses.
Key Features:
- Includes interactive levels, hands-on coding, quizzes and interactive playgrounds.
- Play like a game & practice as your learn.
- Lifetime access to course materials and updates.
Website: cssbattle.dev/learn

3. Complete CSS

Author: Piccalilli (Andy Bell)
Options available: Single course.
Key Features:
- Includes course videos and hands-on website-building project.
- Lifetime access to course materials and updates.
Website: piccalil.li/complete-css

4. CSS Demystified

Author: Kevin Powell
Options available: Single course.
Key Features:
- Includes course videos, excercises, code challenges, website-building projects and Discord community.
- Lifetime access to course materials and updates.
Website: cssdemystified.com

Conclusion

Check them all out and pick the one that suits you best. Have a great learning journey! 👋🏼

How to learn & master CSS

Kushagra Gour — Tue, 01 Aug 2023 16:24:02 +0000

Cascading Style Sheets (CSS) is an essential technology used in web development to style and layout web pages. CSS is not like other programming languages because of its unique core concepts and hence learning CSS can be challenging, especially for beginners. In this blog post, I attempt to outline how one can learn and master CSS.

Learning CSS can be broken down into 2 things: Learning and Practice

Learning

You need to learn 2 things in CSS: The core concepts & property-values.

Learning Core Concepts

This involves understanding the CSS specific concepts, theoretically. Things like cascade, z-index, box model, selectors etc

The resources I recommend for this are:

web.dev guide - Super nice articles explaining each of the concepts in CSS. Must read!
CSSBattles’s Learn CSS course - This is a unique interactive game-like experience to understand the concepts of CSS, while not feeling daunting with just reading long articles or videos.
Josh Comeau's CSS for JavaScript developers course. This man is a wizard in CSS and teaching - an extra-ordinary combination that makes his course excellent for learning CSS.

Learning about Properties and Values

The only resource I recommend here is the MDN docs. To learn properties and values, you should read the MDN docs on various properties. MDN docs provide an in-depth explanation of each property, including its syntax, possible values, interactive examples and browser support. As a routine you can visit the MDN pages of the first 2-3 properties you use daily…its fun!

Practice

Once you get a basic knowledge about the core concepts and properties, practice is of utmost important to turn your acquired knowledge into skills. Here are the 2 directions I recommend practicing CSS in:

Page layouts by building pages - this is an excellent way to practice what you have learned. It will give you real-world experience in applying CSS concepts and properties to create practical layouts and structures. You can start with building static webpages - grab a design from Dribbble/Behance and turn into HTML & CSS. Then move onto building simple apps like a landing page or a portfolio website.
Properties-values in CSSBattle - CSSBattle is a game where you play each level by replicating a given image as close as possible in just CSS in minimum number of characters (also called as code-golfing). Now writing minimum CSS may sound very impractical and it is! But you don't need to do code-golfing and can just focus on the matching the image part. Now even that might sound impractical, and yes that is! But surprisingly that gives you a very good practice in CSS properties and also helps develop your creative thinking when you come up with different approaches to replicate each level's image. There are so many levels on CSSBattle that doing them regularly will force you to experiment with each property and explore it in the process! I have personally learnt a lot of properties here like clip-path, radial-gradient and much more.

Disclaimer: I recommend CSSBattle in this post wich I have created. As biased as it may sound, I don't recommend it because I am the creator. It has been my first-hand experience learning a lot on that platform, accompanied by testimonials from a lot of other players.

Final tool

In the end, the thing that will give the final sharpness to your CSS sword is - "The Specifications"! Specifications are the written documentation on each feature of CSS, by the people who build CSS! It covers every topic in-depth - upto details which then are also used by all the browsers to implement those CSS features. Reading these specifications give you the extra bit of understanding into why every features works the way it does.

Remember that learning and practicing are not sequential phases, they go hand-in-hand. Never stop learning as CSS language keeps evolving and so should your skills. And with time and practice, you can become a CSS master. Happy CSS-ing! 👋

Learn CSS intuitively - Box Model

Kushagra Gour — Tue, 21 Mar 2023 12:19:25 +0000

Hey there! Welcome to our new series of posts where we try to decipher CSS concepts in an intuitive manner - by relating those concepts to something you already know in the real world so that we can learn CSS like never before! Are you ready for the first concept?? Let's go! 🚀

First up is - The "CSS Box Model". Everything on a webpage is a box for CSS and every box is like a sandwich 🥪! Just like a sandwich has several layers, each with its own purpose, a box in CSS has several layers that make up its overall appearance and behavior.

Let's break down the CSS box model into its layers, starting from the inside out:

Content: The content layer is like the yummy filling in a sandwich. It's the actual content that goes inside the box, such as text, images, or other HTML elements (boxes).
Padding: The padding layer is like the crust of a sandwich. It surrounds the filling and separates it from the wrapping paper of the sandwich. Similarly, padding provides a buffer between the content and the edges of the box. You can add padding to create some breathing space around the content.
Border: The border layer is like the wrapping paper around a sandwich. It adds a visible border around the content and padding layers. You can customize the border's thickness, color, and style.
Margin: Lastly, the margin layer is like the empty space around a sandwich on a plate. It's the space between the box and any surrounding elements. You can add margin to create some distance between the box and other elements on the page...so that your sandwiches don't just touch each other. 😁

So, you can see that just like how a sandwich has multiple layers that make up its structure and appearance, the CSS box model has multiple layers that does the same for the box. Understanding the box model is very important in controlling the layout of your web pages, so make sure you practice it well enough. You can hop over to CSSBattle and solve some targets to practice your box model learnings.

How did you like this post? Do you have questions about the CSS box model? What next concept would you want us to give a shot at?

Let us know on our forum or on the Twitter post.

Mocking Web Push notification in Cypress

Kushagra Gour — Tue, 28 Jun 2022 09:03:24 +0000

PushOwl has a JavaScript library that runs on merchant (our customers) websites and handles things like showing UI widgets to request visitor permissions, passing data to the backend, and subscribing the user to the Web Push Service.

It’s one of the most critical pieces of our system because a slight issue in our script can cause unexpected behavior on our customer websites causing a loss for them. So we take utmost care to test the library rigorously before deploying anything to production.

The Roadblock

We use Cypress to test our JavaScript library for end-to-end cases - just like how a website visitor would interact with the website and hence our script. As mentioned, one of the most important parts of our library is requesting permission from the user to send them notifications and then subscribe them to the Web Push Service. Permissions on the website are requested by triggering a prompt like so:

A native prompt asking for permission to show notifications

Current testing frameworks do not have very great support to test these native permission prompts. You could trigger them in headed mode, but then you can trigger a click on the “Allow” or “Block” buttons programmatically.

But tests don’t run in the headed mode in the CI environment, they run in headless browsers. In a headless environment, it becomes more difficult because the prompt doesn’t show up at all and just fails!

There are a few open issues in these libraries, but they still have to see the light of day!

How do we even test these prompts then? Let’s see how!

Going around these permission prompts

Since we can’t interact with these permission prompts, the next best thing we could do was to mock them!

By mocking, we simply mean converting the following test scenario:

user lands on the website
clicks on a button
sees a permission prompt
clicks “Allow” inside the prompt
User gets subscribed and an API request is made to the backend

to…

User lands on the website
clicks on a button
mock browser APIs to behave as if the user clicked “Allow”
User gets subscribed and an API request is made to the backend

Let’s see how we do this in the specific context of Notification permission.

Mocking browser APIs

Several properties and methods form the complete Web Push Notification subscription flow in the browser. We’ll look into each one individually.

Notification.permission

This property on the global Notification object gives the current status of the website visitor w.r.t. the “Show Notification” permission.

Notification.permission would have the value as default in the default case. And it would be granted or denied in case you allow or deny it respectively.

Mocking this property is simple, we use the Cypress’ stub method like so:

Cypress.Commands.add('setPermission', (permission = 'default') => {
  cy.window().then(win => {
    cy.stub(win.Notification, 'permission', permission);
  })
});

And of course, we have this inside a utility function or a Cypress Command so that we can pass in any permission value and have it set to that.

Notification.requestPermission()

This is the method that triggers the permission prompt i.e. we request permission. This is an async function that resolves to a string value - granted when “Allow” is clicked and denied otherwise.

Cypress gives a method to mock async functions. For a successful permission scenario, it would look like so:

cy.stub(win.Notification, 'requestPermission').resolves('granted')

navigator.serviceWorker.register()

According to the Web Push Subscription flow, once we get the granted permission from the visitor, we need to install a service worker which later handles receiving the push notification and displaying it.

To install a service worker script, our library would at some point calls navigator.serviceWorker.register() method and would await for a serviceWorkerRegistration object on successful resolution of this async method.

Mocking this method would mean providing a serviceWorkerRegistration object with the correct keys on it, which looks something like this:

{
  active: { state: 'activated' },
  pushManager: { subscribe: () => {} },
};

Note that

installing a service worker works fine in headless browsers. We’ll even get a serviceWorkerRegistration object on success. But the reason why we still mock it is the pushManager.subscribe method in that serviceWorkerRegistration object above — once the service worker is registered, we call the pushManager.subscriber method to subscribe the visitor to the remote Web Push notification service and that fails in headless browser environments. Hence, we don’t want our JavaScript library to be calling the actual pushManager.subscribe method on an actual serviceWorkerRegistration method 😄

So let’s mock it too!

const swRegistration = {
  active: { state: 'activated' },
  pushManager: { subscribe: () => {} },
};
cy.stub(win.navigator.serviceWorker, 'register').resolves(swRegistration)

pushManager.subscribe() - The final step!

In the end, we now also want to stub our own pushManager.subscribe method in the serviceWorkerRegistration object we created above. pushManager.subscribe is also an async function which resolves to a subscription object. So let’s make it do that:

// from above
const swRegistration = {
  active: { state: 'activated' },
  pushManager: { subscribe: () => {} },
};
// our mocked subscription object
const subscription = {
  endpoint:
    'https://fcm.googleapis.com/fcm/send/f.....u0LL',
  expirationTime: null,
  keys: {
    p256dh:
      'BGBn2Lco....ZUY',
    auth: 'y8....JWQ',
  },
};

cy.stub(swRegistration.pushManager, 'subscribe').resolves(subscription)

And done!

Now, all we have to do is set these mocks (which we have as commands) at the right time and trick our JavaScript library into believing that the user is subscribing, or not!

In the end, I’ll leave you with a nice quote:

“Testing is an infinite process of comparing the invisible to the ambiguous in order to avoid the unthinkable happening to the anonymous.”— James Bach

Keep testing! Until next time!

Learn Frontend, the right way

Kushagra Gour — Wed, 06 Nov 2019 09:42:01 +0000

Hello devs!

Do you want to learn Frontend development, the right way?

I present to you, the first-ever tweet-sized course -> https://twitter.com/i/moments/1187229313579438080

This course is an attempt to share my 8+ years of learnings in the field of Frontend. You'll learn to create performant and accessible web pages with a solid understanding of which web technology to use for which purpose. The course is completely available on Twitter, in the form of tweets!

2 chapters are already out. So head out to https://twitter.com/i/moments/1187229313579438080 and follow along with the chapters.

Happy learning! 😃

Terminal commands for daily use

Kushagra Gour — Fri, 11 Oct 2019 00:00:00 +0000

This post is a compilation of the most used commands I use in my terminal daily. A reason to share this compilation is to give a quick introduction to how a few very common regular tasks can be done through commands in a terminal. I find running commands in the terminal a lot faster than otherwise doing through the GUI and hence makes me more productive. If you feel you are better without them, that is completely fine too. But I suggest everyone should try them to see what works best for you.

There are 2 bonus tips at the end of this post to give you that extra productivity boost. Do read till the end.

List all files with human-readable filesizes

ls -lah some/folder/path

l - lists the files l ong format.
a - lists a ll the files.
h - lists filesize in more h uman-readable way.

Tip: you can list files of the current folder with ls .

Switch directory

cd some/folder/path

Create a new file

touch fileName.js

Creates an empty file with the name fileName.js.

Create a new folder

mkdir new-folder-name

Copy a file

cp copyFrom.js copyTo.js

Rename a file

mv oldFile.js newFile.js

Open a file in Visual Studio Code (VSCode)

code fileName.css

This is really useful. If you are not aware, VSCode can be added as a shell command too. Here is [how to add VSCode as shell command][vscode-command].

Git commands

I am going to club these into one section.

git status - Check the status of the repository in the current directory
git checkout master - Switch to master branch
git pull --rebase origin <branch_name> - Pull remote changes from a branch called branch_name and apply my unpushed changes over those pulled changes
`git commit -m "my message here" - Commit changes
git push origin <branch_name> - Push changes of branch branch_name to remote

Open any file (Max OSX only)

open /some/path/filename.ext

This basically works like double-clicking a file in the GUI file explorer. It opens the file in the default program set for that type of file. Super useful!

open is a Mac OSX command, but I am sure every OS has something similar.

Bonus Tips

Quickly accessing your terminal

When you start using your terminal for little quick things like mentioned above, it becomes all the more necessary that you are able to do them fast enough without any overhead. And so it makes sense to do some tweaks to make your terminal accessible as quickly as possible.

For that, you can do 2 things.

First, set your terminal to show as an overlay on the screen i.e. on top of whatever window you have open in front of you. In case you have spaces (also referred as workspaces) enabled on your machine, showing as overlay prevents unnecessary context switch in changing spaces (because you'll switch to whatever space the terminal window is in) and also removes the time delay it would take to switch spaces. Overlay terminal shows instantly.
Next, set a hotkey on your terminal. That enables you to show up your terminal with a quick keyboard shortcut.

Most terminals (I have tested on Hyper and iTerm) let you do the above things natively or through some plugin.

Aliases

With time, you'll realise that you use a few commands more frequently than others. For these commands, you can set aliases. Aliases are short names given to commands so that you don't have to type the complete command again and again. Whatever shell you are using, they allow setting aliases. You can find how to set aliases in your shell by searching "How to set aliases in <your_shell_name>". By default, most operating systems give your bash shell.

Also, here is a good article on setting aliases in few different shells.

Hope this post proves useful to you and give you some extra productivity boost! Ciao!

I am starting a first-ever "Tweet-Course" on Frontend development. Yes! Learn frontend with tweet-size chapters spanning from HTML to CSS to JavaScript. Follow the @learn__frontend account to take this free course.

Strong vs Em

Kushagra Gour — Sun, 25 Aug 2019 00:00:00 +0000

 and  are two of the most basic tags that we learn when we start learning HTML. I am sure you must have used both these tags multiple times. I have too. But somewhere at the back of my mind I always had that slight confusion about which cases each should be used. In fact about which places one tag shouldn't be used. So I finally decided to look up the specifications to clear that doubt once and for all. And I must admit, the specification does a great job at explaining the purpose of each.

If you also face that slight confusion about using  and  tags, you are at the right place. This article tries to re-express the learnings I got by reading the W3C specification.

TL;DR

If it's just visual importance, you want strong. If it alters the sentence meaning, use em.

The `` tag

Firstly, to quote the HTML specification

The strong element represents strong importance, seriousness, or urgency for its contents.

Let's try to understand those 3 use cases.

Importance

Importance can be thought of like "hierarchy". For example, say you are describing certain items in different paragraphs. You will probably start the paragraph by putting the item name in strong tags, like so:

<p>
  <strong>Item X</strong>: This paragraph is all about describing Item X, it's
  properties and behaviour.
</p>

<p>
  <strong>Item Y</strong>: This paragraph is all about describing Item Y, it's
  properties and behaviour.
</p>

They are acting similar to headings, visually. I compare importance with hierarchy because if someone needs to quickly scan all such items described in the paragraphs, they can just glance at the strong texts which also appear bold (and hence seemingly higher up the hierarchy).

Seriousness

A classic example of this is when you need to show a warning or error. You could simply show a sentence describing the whole warning but there could be a chance that the user ignores reading the whole text, and thus the warning. To make it more evident that the particular text is conveying a warning, we can wrap it in strong tags. Again, the bold appearance of the strong tag helps us convey that this is not just another text. It's something serious and needs to be seen.

A simple example:

<strong>Warning: You data will lost in 35 seconds</strong>

which renders as:

Warning: You data will be lost in 35 seconds

Urgency

This use case is something I have encountered quite a lot, especially while writing emails. Say you are writing a long paragraph and there are certain things that you want the reader to read first and foremost. Those things can be wrapped in strong tags.

Again, the whole premise is that the person reading your long text doesn't have the time to read all the text and even if they do, there might be certain important pieces of text that are intended to be read first and act urgently. The strong tag helps us achieve that.

I know all the 3 use cases seem similar and overlapping each other. That is true. But overall they do help to construct a good set of intentions where you would use the strong tag.

The `` tag

em tag reads as emphasis but it certainly isn't just that. In fact, it's that word emphasis that has confused a lot of us in thinking that it is similar to the strong tag, which is also used to emphasize the importance of something. And it is not!

Again, to quote the HTML specification:

The em element represents stress emphasis of its contents.

Stress emphasis is the important thing to note here. It actually has to do with how you speak a particular piece of text.

Let me explain the gist of em tag with a gif:

via GIPHY

I am sure you have seen people doing this quote gesture while speaking a particular word or phrase in a long sentence. Imagine they hadn't done that gesture while speaking that word/phrase. Would you have got the same meaning out of that speaker? No. Because the specific stress that the speaker put on that particular part of the sentence, changed their intended meaning.

This is exactly what the em tag helps you do while writing. You can wrap certain parts of sentences to simulate the same stress as you would while speaking.

To make it more clear, I would like to show you the exact example from the HTML specification because I think it does the job perfectly in explaining what em tag does.

These examples show how changing the stress emphasis changes the meaning. First, a general statement of fact, with no stress:

Cats are cute animals.

By emphasizing the first word, the statement implies that the kind of animal under discussion is in question (maybe someone is asserting that dogs are cute):

Cats are cute animals.

Moving the stress to the verb, one highlights that the truth of the entire sentence is in question (maybe someone is saying cats are not cute):

Cats are cute animals.

By moving it to the adjective, the exact nature of the cats is reasserted (maybe someone suggested cats were mean animals):

Cats are cute animals.

Similarly, if someone asserted that cats were vegetables, someone correcting this might emphasize the last word:

Cats are cute animals.

By emphasizing the entire sentence, it becomes clear that the speaker is fighting hard to get the point across. This kind of stress emphasis also typically affects the punctuation, hence the exclamation mark here.

Cats are cute animals!

Anger mixed with emphasizing the cuteness could lead to markup such as:

Cats are cute animals!

Hope these examples make it all clear.

Screen reader accessibility

 and  are not just meant to convey semantics visually, but they are also supposed to convey the same meaning to screen reader users too, ideally through a change of voice.

From what I could test, VoiceOver doesn't seem to differentiate normal text from the emphasized text. Also, there seems to be no recent studies on the Web for other screen readers like JAWS and NVDA. Hence, I am not covering this topic in much details. I would appreciate if someone can share studies on this matter, which I can update here.

Nevertheless, screen readers are continuously improving and our correct use of the tags will only help users eventually.

Also, it's worth noting that accessibility isn't always about screen readers. The visual difference that comes with strong/em tag is great for increasing reading comprehension and helping with cognitive disabilities like dyslexia.

Summary

Next time you get confused which tag to use out of strong and em, think about this: What's your intention to change the visual appearance of a certain word or phrase? Is it just visual importance of does your stress actually help in communicating better by changing the meaning of the sentence (like you would have stressed while speaking)?

If it's just visual importance, you want strong. If it alters the sentence meaning, use em.

What about `b` and `i` tags?

There is also a common confusion while choosing between strong/b and em/i. Visually they look exactly the same as their counterparts. Then what's the difference?

The difference lies in semantics. strong and em bring in some additional context or meaning wherever used. On the other hand, b and i are just for styling and visually differentiating some part of the sentence from the rest. You can consider b tag the same as a span with a CSS of font-weight: bold applied on it. Similarly, i can be thought of as a span with CSS of font-style: italics applied on it.

So if you want to communicate importance, urgency or seriousness, use strong. If you just need to draw attention without any importance, use b or rather just use CSS font-weight. Similarly, if you want put stress on something, use em. If it's just about highlighting a different type of text, such as a word in another language, then use  or just CSS font-style.

That is all for this post. Hope this helps understand these common tags better.

Special thanks to Jitendra Vyas, @stommepoes, and the lovely members of Slack Web Accessibility group for reviewing this post.

Case Study: Accessibility Report for Managers - Part 1

Kushagra Gour — Thu, 08 Aug 2019 00:00:00 +0000

This is a case-study of why and how I created my recent side-project - Accessibility Report for Managers. Part 1 talks about the idea behind it and how the Frontend was created.

Accessibility is a very important aspect of any product. If your product isn’t accessible to every possible user, then you are simply losing out on potential users. Over the past few years, I have grown to care more and more about accessibility in every work I do, not just web development, but everything. With that also comes the disappointment to see all these websites out that that break even the basic accessibility rules.

Lack of knowledge is certainly the reason for poor accessibility in websites. But it isn’t always just the lack of knowledge of developers. I feel there are times when developers do want to take time out to improve the accessibility in their work as they slowly learn new and new things, but they are not always given the freedom to do so. Again, it’s the lack of knowledge and empathy, but in a different set of people who manage these developers. That is why Accessibility, and for that matter, any part of a website, is not just a developer’s job. It needs to be a company value that starts from the early stage of idea conceptualisation, to design, development, product management, marketing, and beyond.

The Idea behind “Accessibility Report for Managers”

The most common argument we get to hear from people who are tried to convinced about focusing on Accessibility is:

Hey, do we really have those kinds of users? Has anyone ever complained about our website not being accessible?
-- A Manager

This gave me an idea - why not make an app that gives these people what they want - real feedback from actual users. But then I thought, the primary aim here is “real feedback”, not “actual users” 😉 This led to the whole concept for “Accessibility Report For Managers” - website where you can enter any website URL and generate a report full of dummy feedbacks about actual Accessibility issues on that website, by dummy users 🙂 You take this report to your manager who was asking for real customer feedback all this time, and voila!

Disclaimer : The idea here is not at all to diminish the importance of actual accessibility testing and feedback submitted by real users. That is at most important. This app is just a fun attempt to bring a different perspective to look at real accessibility issues.

The Real value

Okay, fun part aside. Accessibility Report for Managers isn’t just a funny impractical website to generate these fake feedback. I realised it serves a more practical purpose. This app basically gives you a very different, a customer oriented, view of the Accessibility issues present on your website. Compare this to reading a story and actually seeing/hearing the same story in a movie. Similarly, a textual list of issues generated from a linter would not create the same amount of empathy inside the reader that probably a tweet from a disappointed user showing a screenshot of something broken on the website would do.

For example, compare these two:

Linter : Color contrast not sufficient. It should be at least 4.5:1.

User Feedback : Hey web admin, I was browsing through your website to get some work done but at some places, it’s really hard for me to read the text, probably due to poor colour contrast.

I hope you can see the huge difference between the two. I feel the latter gives a very understandable view of the same issue.

TL;DR: Creating the App

This app, though seemingly small, has quite a few components behind the scenes. And the best part, as a frontend developer I could write it all in JavaScript and run without actually setting up or managing a server. These things really excite me and this article series is an attempt to share the whole process of creating such an app with all the latest tech out there. Let’s begin with the tech stack used in the app.

Note: The app is open-source on Github.

Component 1 - The Frontend

I chose Preact to write this app’s frontend. Preact is an extremely lightweight (just 3KB gzipped) alternative to React with almost the same API. It’s perfect for a scenario where you have such a small app and you don’t wanna overload it with some framework’s footprint.

I used Preact’s preact-cli which does a basic scaffolding for a Preact Progressive Web App. There is no other dependency on Frontend apart from Preact.

The CSS is written the old-fashioned way - a single CSS file.

Component 2 - The Backend

The backend is basically a set of serverless functions which creates 2 endpoints for the frontend. Again, they are all written in JavaScript (NodeJS).

There is one API endpoint to get the actual issues on a given page which uses the pa11y package to extract out all the issues.
The second API endpoint is to get the screenshot of affected areas. This is done using Puppeteer to get screenshot of specific elements on the page.

Component 3 - Deployment

Both, the frontend and the backend, are hosted on Zeit Now. It simply involves writing the deployment configuration for your components and everything gets deployed with a single command without managing any server!

The Frontend

Note : Till we get to the Backend, assume that we have a backend API. We can send any URL to the API and it returns us a list of Accessibility issues.

The framework

I love React. But if the project I am working on is not too demanding in terms of features and I am the only one working on it, I prefer to use Preact - which is a 3KB alternative to React. It almost feels like I am shipping a vanilla JS app while getting the same ease as with React.

Preact also has a CLI that scaffolds a basic progressive app.

Creating fake tweets - Content

As I mentioned, our API gives us a list of Accessibility issues (found through pa11y). First of all, we need to turn these into tweets. Each issue in the list is of the following structure:

    {
      code: "WCAG2AA.Principle2.Guideline2_4.2_4_1.H64.1",
      message: "Iframe element requires a non-empty title attribute that identifies the frame.",
      type: "error",
      selector: "#77c8c1c1-74e9-4d61-be2e-c1e39ffe02a0"
    }

The code is a unique identifier for a particular Accessibility guideline that wasn’t followed, explained in brief in the message value. The main gist of this app is to turn the technical guideline into seemingly real feedback from a real user. That is why I need to convert that into a tweet. And the same tweet always for a particular issue type would look unreal and boring. So I maintain 3-4 different tweets for each issue type and pick one out randomly. Like so:

const supportedRules = {
  INSUFFICIENT_CONTRAST: "WCAG2AA.Principle1.Guideline1_4.1_4_3.G18.Fail",
  MISSING_LABEL_ON_FORM_CONTROL: "WCAG2AA.Principle1.Guideline1_3.1_3_1.F68"
};

function generateFeedback(issue, url) {
  switch (issue.code) {
    case supportedRules.MISSING_LABEL_ON_FORM_CONTROL: {
      return {
        message: [
          `Dear Web Developer, I cannot see and browse the web using a screen reader. And websites like ${url} on which you don't label your form elements are completely unusable to people like me. #fixtheweb #a11y`,
          `Oh God! It's a disaster browsing websites where the developer simply didn't care to put a label on form controls!! Encountered one such site -> ${url} #accessibility.`
        ][random(0, 2)]
      };
    }
    case supportedRules.INSUFFICIENT_CONTRAST: {
      return {
        message: [
          `Hello! I was browsing through your website ${url} and facing issues with reading few texts. I guess it could get a lil' better for people like me if the text color had some more contrast with the background.`,
          `It's such a difficult task to read websites these days. Eg. Missing text contrast here -> ${url} Someone please fix the web. #accessibility`
        ][random(0, 2)]
      };
    }
  }
}

What's happening here is, I have made enums for the supported Accessibility guideline codes to make it more clear while referencing them. Then there is the generateFeedback function which does a switch on the accessibility issue code and returns a random feedback from a list of feedbacks corresponding to that issue.

One more thing to note here is that I pass the URL of the website, whose report is being generated, to the generateFeedback function. This passed argument gets used in the ${url} placeholder within the feedback strings, which are actually template literals.

Creating fake tweets - Fake users

This one is interesting! Next, we need some fake users to show within our feedback tweets. I searched a lot for services which would give me random user data and finally settled on https://randomuser.me. It’s free, fast and gave me the data I wanted (eg. name, photo etc). It has an API with all sorts of options, but the one that is of our interest here is the results option. You can pass a count in results parameter and the API will return that number of fake users to you. Sweet right!

So the whole report generation process till now is as follows:

I get a list of issues from the API
The issue list is converted into fake feedback tweets (only the issues which are supported)
As per the number of feedbacks we generate, we fetch those number of fake user from https://randomuser.me

Creating fake tweets - Twitter handles

To complete our fake feedback tweet, we need to show the twitter handles (username) of our fake users. Now we could just create random strings out of numbers and alphabets, but that would again look unreal. And what's the fun in making unreal stuff! So here is what I do instead:

For each user, we have the user’s full name.
I extract some part of the user’s first name ( F ) and some part of their last name ( L ).
Then with a 50% probability, I concat F and L with an underscore. The other 50% times, I concat them straightaway. Because people generally contact their first and last names to create their handles.
Next, with a 30% probability, I append some digits (maximum 3) after the result of Step 3. Why? Because not everyone in the Twitter-verse gets their handle of choice. They append random numbers to make it unique :)
The result is appended to a “@” character.

And we have the handle ready! If you are wondering how do we do something with X% probability, it can be done easily by checking the result of Math.random().

For example: To run a code with 70% probability, we could use Math.random() > 0.3. This condition means we want the number returned by Math.random() to be greater than 0.3. And Math.random() return from 0 to 1. So basically we are checking that the returned number should be between 0.3 and 0.1. This translates to having a 70% chance:

0 - 0.3 → 30% probably outcomes

0.3 - 1 → 70% probably outcomes

Here is how the complete function looks like:

function getHandleFromName(fname, lname) {
  // Concatenating extracts from first and last name, with _ maybe?
  let handle = [
    `${fname.substr(0, random(1, fname.length - 1))}`,
    Math.random() > 0.5 ? "_" : "",
    `${lname.substr(0, random(1, lname.length - 1))}`
  ].join("");

  // Add some digits?
  if (Math.random() > 0.7) {
    handle = `${handle}${random(0, 999)}`;
  }

  // Append to @
  return `@${handle}`;
}

Creating fake tweets - Final items

To all the above data, we add random “like” count and tweet date. One more thing that the tweet shows is the image of the element on the website that failed the Accessibility guideline. Remember the issue structure that we get from the API? It had a key called selector is the CSS selector of the corresponding element. I created another API to which I pass the CSS selector and website URL and it returns me the screenshot of that element. More on that later.

And combining all the fake data, we generate this beautiful fake feedback tweet:

Tweet screenshot of a fake user complaining about color contrast user

That is it for this article. In the next article, I’ll go through the app’s backend and how it is deployed.

Introducing CSSBattle PRO

Kushagra Gour — Fri, 12 Jul 2019 04:51:06 +0000

We're proud to introduce CSSBattle PRO, where you can upgrade your CSSBattle experience 🥳. For those who have not heard about CSSBattle before, CSSBattle is the first ever code-golfing game for CSS lovers.

CSSBattle PRO gives you access to the following features:

Add plugins to the code editor 🔌

With plugins, you can add custom scripts to enhance the editor and make it faster to reach the optimized solutions. For example, you can use it to automatically minify your code or convert the units to smaller character units. Here's a simple minification script to get you started:

function run(code) {
    processedCode = code
      .replace(/\<\!--\s*?[^\s?\[][\s\S]*?--\>/g,'')
      .replace(/\>\s*\</g,'><')
      .replace(/\/\*.*\*\/|\/\*[\s\S]*?\*\/|\n|\t|\v|\s{2,}/g,'')
      .replace(/\s*\{\s*/g,'{')
      .replace(/\s*\}\s*/g,'}')
      .replace(/\s*\:\s*/g,':')
      .replace(/\s*\;\s*/g,';')
      .replace(/\s*\,\s*/g,',')
      .replace(/\s*\~\s*/g,'~')
      .replace(/\s*\>\s*/g,'>')
      .replace(/\s*\+\s*/g,'+')
      .replace(/\s*\!\s*/g,'!')

  return processedCode;
}

Advanced target stats 📊

Get a bird's-eye view on your performance in battles with these advanced stats. See where you're performing well and where you're lagging behind. Here's what it looks like:

Light theme ☀️🌙

This is one of our favourite features! You'll be able to switch between light and dark themes and customize the experience as you like. Here's what the light theme looks like:

PRO badge 🎖

Apart from all the above features, you'll also get a shiny PRO badge next to your name wherever it appears across CSSBattle.

Upcoming features

We're also planning to add these features very soon which will make your PRO experience even better.

Create public community targets: Create your own targets for the community with your own rules. All the targets will be rated by the community and we'll feature new targets every week.
Organize your own battles: Create your own custom battles with your own targets or choose from the community targets. You can also make it invite only which is great for conferences or workplaces.

You can upgrade to CSSBattle PRO for $3/month (a special launch price). This price may change in the future depending upon features but will remain the same for you if you decide to upgrade now.

We hope you enjoy CSSBattle PRO!

Giveaway 🎁

To celebrate the launch, we are giving away 1 month free access to 5 lucky players who Retweet the following tweet!

// Detect dark theme var iframe = document.getElementById('tweet-1149249241530929152-839'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1149249241530929152&theme=dark" }

How I saved 100KB with React.lazy

Kushagra Gour — Fri, 05 Jul 2019 00:00:00 +0000

This post is about how I was able to reduce my homepage JavaScript by more around 100KB.

TL;DR : Use React.lazy and React.Suspense to lazy load your non-critical dependencies

I have a React app bootstrapped from create-react-app. One of the page (just a React Component) in that app uses CodeMirror (a code editor). The app uses react-router for routing. And so this page component, just like all other pages, is imported in the main App component to provide to the router.

App.js

import Home from "./Home";
import Page2 from "./Page2";

function App() {
  <Router>
    <Route path="/" component={Home} />
    <Route path="/page2" component={Page2} />
  </Router>;
}

Page2.js

import CodeMirror from "react-codemirror";

function App() {
  return (
    <div>
      <CodeMirror />
    </div>
  );
}

Note: react-codemirror actually does a named export. But for simplicity, I am assuming a default export.

This situation leads to Page2.js being a synchronous dependency to render App.js. And Page2.js in turn depends on react-codemirror. So indirectly, react-codemirror becomes a synchronous dependency to render App.js. This basically means whatever page we visit, react-codemirror will be fetched and parsed before the page renders. Even if Codemirror is not even being used on that page! Let's fix this.

Solution

The solution is pretty neat and easy. React recently introduced a new API: React.lazy. And an accompanying component called Suspense. Here is how we use them to fix our problem.

Step 1: Make the import lazy

Page2.js imports react-codemirror. Ideally we want that Page2.js should load react-codemirror asynchronously when Page2 is actually visited.

This is our current Page2.js:

import CodeMirror from "react-codemirror";

function App() {
  return (
    <div>
      <CodeMirror />
    </div>
  );
}

Using the React.lazy API, we can make the import lazy. Like so:

import React from "react";
const CodeMirror = React.lazy(() => import("react-codemirror"));

function App() {
  return (
    <div>
      <CodeMirror />
    </div>
  );
}

And this just starts working out of the box! No more change required in the way CodeMirror component is used. What you'll notice now is initially when you are on homepage, CodeMirror doesn't load. When you visit /page2/, you see blank area where CodeMirror was to be rendered, for a short duration while CodeMirror loads asynchronously. And then when it has finished loading, CodeMirror component renders.

While CodeMirror is being fetched, there is just blank space where CodeMirror editor should have been present. That is not such a good experience as user is left without any information about that blank space. That is where React.Suspense component comes into action.

Step 2: Improve the blank space context

Here is all we need to do to make the experience better:

import React, { Suspense } from "react";
const CodeMirror = React.lazy(() => import("react-codemirror"));

function App() {
  return (
    <div>
      <Suspense fallback="Loading editor...">
        <CodeMirror />
      </Suspense>
    </div>
  );
}

We wrap the asynchronous/lazy components with a Suspense tag and give it a fallback which should show instead of blank space. That is it!

Bonus tip

There is one special requirement for using React.lazy which you need to be aware of. It only works with component that have default export. So components with named exports can't be lazily imported with it. But you might have components with named exports, what to do then? There is a small trick. Let's assume our Page2.js file exported Page2 component so that it was initially imported as import {CodeMirror} from 'react-codemirror'. In that case, we can use React.lazy on it as follows:

import React, { Suspense } from "react";
const CodeMirror = lazy(() =>
  import("react-codemirror").then(module => ({ default: module.CodeMirror }))
);

function App() {
  return (
    <div>
      <Suspense fallback="Loading editor...">
        <CodeMirror />
      </Suspense>
    </div>
  );
}

What we did here is once we import the named module, inside the then callback we turn it into a seemingly default exported module - an object with the module available on default key.

Side note, this app is CSSBattle.

That's all folks! Go shave off some unnecessary bytes of your pages. If you have any questions or comments, ask me here or on Twitter @chinchang457 (DMs are open).

Let's build a Perfect CSS Framework

Kushagra Gour — Wed, 03 Jul 2019 08:24:50 +0000

This is an experiment I am doing to build a theoretically perfect CSS framework for teams. Here is how it goes:

You comment on this discussion with a problem/issue we currently face with writing CSS (with vanilla CSS or any library).
I'll reply (or anyone of you can too) with what can be the probable solutions to that issue.
In the end, we collect all those suggested solutions to build or search that "Perfect CSS Framework".

Sounds good? I'll start.

An interactive and practical introduction to Web Accessibility for everyone

Kushagra Gour — Tue, 02 Jul 2019 00:00:00 +0000

Ever since I understood the importance of Accessibility, I have always tried putting a conscious effort to share whatever I keep learning. So that everyone can start caring about at least the basics of Accessibility while making websites.

Nothing brings you closer to reality than actually facing it. This is the premise of my latest attempt to spread awareness about Web Accessibility.

Presenting 👉🏼 introtoaccessibility.com

This project is a series of chapters, in the form of a quiz. Each chapter shows you something or ask you to do something and then asks you a question. The chapters are basically extreme cases of unusable user experience designed such that they are inaccessible even to abled users.

Each chapter makes you experience a particular Accessibility issue. It then tells you how that issue affects various users on the Internet, why it affects them and what you can do to prevent it.

My intention with this project is that it can be the first step to introduce Web Accessibility to anyone and everyone who work with websites. No matter if they are developers, designers or marketers! I hope I can arouse empathy that each one of us requires to make the Web a better place for everyone.

Please do share with anyone and everyone you know who works with websites -> introtoaccessibility.com

You can see my other projects here -> https://kushagra.dev/lab/
And follow me on Twitter -> @chinchang457 where I share more such stuff.
Also, I recently launched a "Ask me Anything" on Github.