Giter Site home page Giter Site logo

thedaviddias / front-end-checklist Goto Github PK

View Code? Open in Web Editor NEW
67.2K 1.5K 6.3K 2.82 MB

๐Ÿ—‚ The perfect Front-End Checklist for modern websites and meticulous developers

Home Page: https://frontendchecklist.io

License: Creative Commons Zero v1.0 Universal

frontend front-end-development front-end-developer-tool guidelines checklist reference web-development html css javascript

front-end-checklist's Introduction


Front-End Checklist

ย  Front-End Checklist ย 


๐Ÿšจ Currently working on new version of frontendchecklist.io,
feel free to discuss any feature you would like to see. Thanks for your support!


The Front-End Checklist is an exhaustive list of all elements you need to have / to test before launching your website / HTML page to production.

ย  ย ย ย  PRs Welcome ย  ย  ย  ย ย ย  Contributors ย  ย  ย ย ย  Frontโ€‘End_Checklist followed ย  ย  ย ย ย  CC0 ย 

ย  How To Use โ€ข Contributing โ€ข Website โ€ข Product Hunt

Other Checklists:
ย  ๐ŸŽฎ Front-End Performance Checklist โ€ข ๐Ÿ’Ž Front-End Design Checklist

It is based on Front-End developers' years of experience, with the additions coming from some other open-source checklists.


How to use?

All items in the Front-End Checklist are required for the majority of the projects, but some elements can be omitted or are not essential (in the case of an administration web app, you may not need RSS feed for example). We choose to use 3 levels of flexibility:

All items in the Front-End Checklist are necessary for the majority of projects, but some elements can be omitted or are not essential. For example, in an administration web app, you may not need an RSS feed. We have categorized the flexibility into three levels:

Low indicates that the item is recommended but can be omitted in certain situations. Medium indicates that the item is highly recommended but can potentially be omitted in very specific cases. However, omitting these elements can negatively impact performance or SEO. High indicates that the item cannot be omitted under any circumstances. Removing these elements may result in page malfunctions or cause accessibility and SEO issues. Testing should prioritize these elements first.

Some resources possess an emoticon to help you understand which type of content / help you may find on the checklist:

  • ๐Ÿ“–: documentation or article
  • ๐Ÿ› : online tool / testing tool
  • ๐Ÿ“น: media or video content

You can contribute to the Front-End Checklist App reading the CONTRIBUTING.md file which explains everything about the project.


Head

Notes: You can find a list of everything that could be found in the <head> of an HTML document.

Meta tag

  • Doctype: High The Doctype is HTML5 and is at the top of all your HTML pages.
<!doctype html> <!-- HTML5 -->

The next 2 meta tags (Charset and Viewport) need to come first in the head.

  • Charset: High The charset (UTF-8) is declared correctly.
<!-- Set character encoding for the document -->
<meta charset="utf-8">
  • Viewport: High The viewport is declared correctly.
<!-- Viewport for responsive web design -->
<meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover">
  • Title: High A title is used on all pages (SEO: Google calculates the pixel width of the characters used in the title, and it cuts off between 472 and 482 pixels. The average character limit would be around 55-characters).
<!-- Document Title -->
<title>Page Title less than 55 characters</title>
  • Description: High A meta description is provided, it is unique and doesn't possess more than 150 characters.
<!-- Meta Description -->
<meta name="description" content="Description of the page less than 150 characters">
  • Favicons: Medium Each favicon has been created and displays correctly. If you have only a favicon.ico, put it at the root of your site. Normally you won't need to use any markup. However, it's still good practice to link to it using the example below. Today, PNG format is recommended over .ico format (dimensions: 32x32px).
<!-- Standard favicon -->
<link rel="icon" type="image/x-icon" href="https://example.com/favicon.ico">
<!-- Recommended favicon format -->
<link rel="icon" type="image/png" href="https://example.com/favicon.png">
  • Apple Web App Meta: Low Apple meta-tags are present.
<!-- Apple Touch Icon (at least 200x200px) -->
<link rel="apple-touch-icon" href="/custom-icon.png">

<!-- To run the web application in full-screen -->
<meta name="apple-mobile-web-app-capable" content="yes">

<!-- Status Bar Style (see Supported Meta Tags below for available values) -->
<!-- Has no effect unless you have the previous meta tag -->
<meta name="apple-mobile-web-app-status-bar-style" content="black">
  • Windows Tiles: Low Windows tiles are present and linked.
<!-- Microsoft Tiles -->
<meta name="msapplication-config" content="browserconfig.xml" />

Minimum required xml markup for the browserconfig.xml file is as follows:

<?xml version="1.0" encoding="utf-8"?>
<browserconfig>
   <msapplication>
     <tile>
        <square70x70logo src="small.png"/>
        <square150x150logo src="medium.png"/>
        <wide310x150logo src="wide.png"/>
        <square310x310logo src="large.png"/>
     </tile>
   </msapplication>
</browserconfig>
  • Canonical: Medium Use rel="canonical" to avoid duplicate content.
<!-- Helps prevent duplicate content issues -->
<link rel="canonical" href="http://example.com/2017/09/a-new-article-to-read.html">

HTML tags

  • Language attribute: High The lang attribute of your website is specified and related to the language of the current page.
<html lang="en">
  • Direction attribute: Medium The direction of lecture is specified on the html tag (It can be used on another HTML tag).
<html dir="rtl">
  • Alternate language: Low The language tag of your website is specified and related to the language of the current page.
<link rel="alternate" href="https://es.example.com/" hreflang="es">
  • x-default: Low The language tag of your website for international landing pages.
<link rel="alternate" href="https://example.com/" hreflang="x-default" />
  • Conditional comments: Low Conditional comments are present for IE if needed.
  • RSS feed: Low If your project is a blog or has articles, an RSS link was provided.

  • CSS Critical: Medium The CSS critical (or "above the fold") collects all the CSS used to render the visible portion of the page. It is embedded before your principal CSS call and between <style></style> in a single line (minified).

  • CSS order: High All CSS files are loaded before any JavaScript files in the <head>. (Except the case where sometimes JS files are loaded asynchronously on top of your page).

Social meta

Visualize and generate automatically our social meta tags with Meta Tags

Facebook OG and Twitter Cards are, for any website, highly recommended. The other social media tags can be considered if you target a particular presence on those and want to ensure the display.

  • Facebook Open Graph: Low All Facebook Open Graph (OG) are tested and no one is missing or with false information. Images need to be at least 600 x 315 pixels, although 1200 x 630 pixels is recommended.

Notes: Using og:image:width and og:image:height will specify the image dimensions to the crawler so that it can render the image immediately without having to asynchronously download and process it.

<meta property="og:type" content="website">
<meta property="og:url" content="https://example.com/page.html">
<meta property="og:title" content="Content Title">
<meta property="og:image" content="https://example.com/image.jpg">
<meta property="og:description" content="Description Here">
<meta property="og:site_name" content="Site Name">
<meta property="og:locale" content="en_US">
<!-- Next tags are optional but recommended -->
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
  • Twitter Card: Low
<meta name="twitter:card" content="summary">
<meta name="twitter:site" content="@site_account">
<meta name="twitter:creator" content="@individual_account">
<meta name="twitter:url" content="https://example.com/page.html">
<meta name="twitter:title" content="Content Title">
<meta name="twitter:description" content="Content description less than 200 characters">
<meta name="twitter:image" content="https://example.com/image.jpg">

โฌ† back to top


HTML

Best practices

  • HTML5 Semantic Elements: High HTML5 Semantic Elements are used appropriately (header, section, footer, main...).
  • Error pages: High Error 404 page and 5xx exist. Remember that the 5xx error pages need to have their CSS integrated (no external call on the current server).

  • Noopener: Medium In case you are using external links with target="_blank", your link should have a rel="noopener" attribute to prevent tab nabbing. If you need to support older versions of Firefox, use rel="noopener noreferrer".

  • Clean up comments: Low Unnecessary code needs to be removed before sending the page to production.

HTML testing

  • W3C compliant: High All pages need to be tested with the W3C validator to identify possible issues in the HTML code.
  • HTML Lint: High I use tools to help me analyze any issues I could have on my HTML code.
  • Link checker: High There are no broken links in my page, verify that you don't have any 404 error.
  • Adblockers test: Medium Your website shows your content correctly with adblockers enabled (You can provide a message encouraging people to disable their adblocker).

โฌ† back to top


Webfonts

Notes: Using web fonts may cause Flash Of Unstyled Text/Flash Of Invisible Text - consider having fallback fonts and/or utilizing web font loaders to control behavior.

  • Webfont format: High WOFF, WOFF2 and TTF are supported by all modern browsers.
  • Webfont size: High Webfont sizes don't exceed 2 MB (all variants included).

  • Webfont loader: Low Control loading behavior with a webfont loader

โฌ† back to top


CSS

Notes: Take a look at CSS guidelines and Sass Guidelines followed by most Front-End developers. If you have a doubt about CSS properties, you can visit CSS Reference. There is also a short Code Guide for consistency.

  • Responsive Web Design: High The website is using responsive web design.
  • CSS Print: Medium A print stylesheet is provided and is correct on each page.
  • Preprocessors: Low Your project is using a CSS preprocessor (e.g Sass, Less, Stylus).
  • Unique ID: High If IDs are used, they are unique to a page.
  • Reset CSS: High A CSS reset (reset, normalize or reboot) is used and up to date. (If you are using a CSS Framework like Bootstrap or Foundation, a Normalize is already included into it.)
  • JS prefix: Low All classes (or id- used in JavaScript files) begin with js- and are not styled into the CSS files.
<div id="js-slider" class="my-slider">
<!-- Or -->
<div id="id-used-by-cms" class="js-slider my-slider">
  • embedded or inline CSS: High Avoid at all cost embedding CSS in <style> tags or using inline CSS: only use for valid reasons (e.g. background-image for slider, critical CSS).
  • Vendor prefixes: High CSS vendor prefixes are used and are generated accordingly with your browser support compatibility.

Performance

  • Concatenation: High CSS files are concatenated in a single file (Not for HTTP/2).
  • Minification: High All CSS files are minified.
  • Non-blocking: Medium CSS files need to be non-blocking to prevent the DOM from taking time to load.
  • Unused CSS: Low Remove unused CSS.

CSS testing

  • Stylelint: High All CSS or SCSS files are without any errors.
  • Responsive web design: High All pages were tested at the following breakpoints: 320px, 768px, 1024px (can be more / different according to your analytics). Responsive Checker -
  • CSS Validator: Medium The CSS was tested and pertinent errors were corrected.
  • Desktop Browsers: High All pages were tested on all current desktop browsers (Safari, Firefox, Chrome, Internet Explorer, EDGE...).

  • Mobile Browsers: High All pages were tested on all current mobile browsers (Native browser, Chrome, Safari...).

  • OS: High All pages were tested on all current OS (Windows, Android, iOS, Mac...).

  • Design fidelity: Low Depending on the project and the quality of the creatives, you may be asked to be close to the design. You can use some tools to compare creatives with your code implementation and ensure consistency.

Pixel Perfect - Chrome Extension

  • Reading direction: High All pages need to be tested for LTR and RTL languages if they need to be supported.

โฌ† back to top


Images

Notes: For a complete understanding of image optimization, check the free ebook Essential Image Optimization from Addy Osmani.

Best practices

  • Optimization: High All images are optimized to be rendered in the browser. WebP format could be used for critical pages (like Homepage).
  • ๐Ÿ›  Imagemin
  • ๐Ÿ›  Use ImageOptim to optimise your images for free.
  • ๐Ÿ›  Use KeyCDN Image Processing for image optimization in real time.
  • ๐Ÿ›  Use Kraken.io awesome alternative for both png and jpg optimization. Up to 1mb per files on free plan.
  • ๐Ÿ›  TinyPNG optimises png, apng (animated png) and jpg images with very small loss in quality. Free and paid version available.
  • ๐Ÿ›  ZorroSVG jpg-like compression for transparent images using svg masking.
  • ๐Ÿ›  SVGO a Nodejs-based tool for optimizing SVG vector graphics files.
  • ๐Ÿ›  SVGOMG a web-based GUI version of SVGO for optimising your svgs online.
  • Picture/Srcset: Medium You use picture/srcset to provide the most appropriate image for the current viewport of the user.
  • Retina: Low You provide layout images 2x or 3x, support retina display.
  • Sprite: Medium Small images are in a sprite file (in the case of icons, they can be in an SVG sprite image).
  • Width and Height: High Set width and height attributes on <img> if the final rendered image size is known (can be omitted for CSS sizing).
  • Alternative text: High All <img> have an alternative text which describes the image visually.
  • Lazy loading: Medium Images are lazyloaded (A noscript fallback is always provided).

โฌ† back to top


JavaScript

Best practices

  • JavaScript Inline: High You don't have any JavaScript code inline (mixed with your HTML code).
  • Concatenation: High JavaScript files are concatenated.
  • Minification: High JavaScript files are minified (you can add the .min suffix).
  • JavaScript security: High
  • noscript tag: Medium Use <noscript> tag in the HTML body if a script type on the page is unsupported or if scripting is currently turned off in the browser. This will be helpful in client-side rendering heavy apps such as React.js, see examples.
<noscript>
  You need to enable JavaScript to run this app.
</noscript>
  • Non-blocking: Medium JavaScript files are loaded asynchronously using async or deferred using defer attribute.
  • Optimized and updated JS libraries: Medium All JavaScript libraries used in your project are necessary (prefer Vanilla Javascript for simple functionalities), updated to their latest version and don't overwhelm your JavaScript with unnecessary methods.
  • Modernizr: Low If you need to target some specific features you can use a custom Modernizr to add classes in your <html> tag.

JavaScript testing

  • ESLint: High No errors are flagged by ESLint (based on your configuration or standards rules).

โฌ† back to top


Security

Scan and check your web site

Best practices

  • HTTPS: High HTTPS is used on every page and for all external content (plugins, images...).
  • HTTP Strict Transport Security (HSTS): Medium The HTTP header is set to 'Strict-Transport-Security'.
  • Cross Site Request Forgery (CSRF): High You ensure that requests made to your server-side are legitimate and originate from your website / app to prevent CSRF attacks.
  • Cross Site Scripting (XSS): High Your page or website is free from XSS possible issues.
  • Content Type Options: Medium Prevents Google Chrome and Internet Explorer from trying to mime-sniff the content-type of a response away from the one being declared by the server.
  • X-Frame-Options (XFO): Medium Protects your visitors against clickjacking attacks.
  • Content Security Policy: Medium Defines how content is loaded on your site and from where it is permitted to be loaded. Can also be used to protect against clickjacking attacks.

โฌ† back to top


Performance

Best practices

  • Goals to achieve: Medium Your pages should reach these goals:
    • First Meaningful Paint under 1 second
    • Time To Interactive under 5 seconds for the "average" configuration (a $200 Android on a slow 3G network with 400ms RTT and 400kbps transfer speed) and under 2 seconds for repeat visits
    • Critical file size under 170Kb gzipped
  • Minified HTML: Medium Your HTML is minified.

  • Lazy loading: Medium Images, scripts and CSS need to be lazy loaded to improve the response time of the current page (See details in their respective sections).

  • Cookie size: Medium If you are using cookies be sure each cookie doesn't exceed 4096 bytes and your domain name doesn't have more than 20 cookies.

  • Third party components: Medium Third party iframes or components relying on external JS (like sharing buttons) are replaced by static components when possible, thus limiting calls to external APIs and keeping your user's activity private.

Preparing upcoming requests

  • DNS resolution: Low DNS of third-party services that may be needed are resolved in advance during idle time using dns-prefetch.
<link rel="dns-prefetch" href="https://example.com">
  • Preconnection: Low DNS lookup, TCP handshake and TLS negotiation with services that will be needed soon is done in advance during idle time using preconnect.
<link rel="preconnect" href="https://example.com">
  • Prefetching: Low Resources that will be needed soon (e.g. lazy loaded images) are requested in advance during idle time using prefetch.
<link rel="prefetch" href="image.png">
  • Preloading: Low Resources needed in the current page (e.g. scripts placed at the end of <body>) in advance using preload.
<link rel="preload" href="app.js">

Performance testing

  • Google PageSpeed: High All your pages were tested (not only the homepage) and have a score of at least 90/100.

โฌ† back to top


Accessibility

Notes: You can watch the playlist A11ycasts with Rob Dodson ๐Ÿ“น

Best practices

  • Progressive enhancement: Medium Major functionality like main navigation and search should work without JavaScript enabled.
  • Color contrast: Medium Color contrast should at least pass WCAG AA (AAA for mobile).

Headings

  • H1: High All pages have an H1 which is not the title of the website.
  • Headings: High Headings should be used properly and in the right order (H1 to H6).

Semantics

  • Specific HTML5 input types are used: Medium This is especially important for mobile devices that show customized keypads and widgets for different types.

Form

  • Label: High A label is associated with each input form element. In case a label can't be displayed, use aria-label instead.

Accessibility testing

  • Accessibility standards testing: High Use the WAVE tool to test if your page respects the accessibility standards.
  • Keyboard navigation: High Test your website using only your keyboard in a previsible order. All interactive elements are reachable and usable.
  • Screen-reader: Medium All pages were tested in a screen-reader (VoiceOver, ChromeVox, NVDA or Lynx).
  • Focus style: High If the focus is disabled, it is replaced by visible state in CSS.

โฌ† back to top


SEO

  • Google Analytics: Low Google Analytics is installed and correctly configured.
  • Search Console: Low Search Console is installed and correctly configured. It is a free service offered by Google that helps you monitor, maintain, and troubleshoot your site's presence in Google Search results.
  • Headings logic: Medium Heading text helps to understand the content in the current page.
  • sitemap.xml: High A sitemap.xml exists and was submitted to Google Search Console (previously Google Webmaster Tools).
  • robots.txt: High The robots.txt is not blocking webpages.
  • Structured Data: High Pages using structured data are tested and are without errors. Structured data helps crawlers understand the content in the current page.
  • Sitemap HTML: Medium An HTML sitemap is provided and is accessible via a link in the footer of your website.

โฌ† back to top


Translations

The Front-End Checklist is also available in other languages. Thanks for all translators and their awesome work!


Front-End Checklist Badge

If you want to show you are following the rules of the Front-End Checklist, put this badge on your README file!

โž” Frontโ€‘End_Checklist followed

[![Frontโ€‘End_Checklist followed](https://img.shields.io/badge/Frontโ€‘End_Checklist-followed-brightgreen.svg)](https://github.com/thedaviddias/Front-End-Checklist/)

โฌ† back to top


Contributing

Open an issue or a pull request to suggest changes or additions.

Guide

The Front-End Checklist repository consists of two branches:

1. master

This branch consists of the README.md file that is automatically reflected on the Front-End Checklist website.

2. develop

This branch will be used to make some significant changes to the structure, content if needed. It is preferable to use the master branch to fix small errors or add a new item.

Support

If you have any question or suggestion, don't hesitate to use Gitter or Twitter:

Author

David Dias

Contributors

This project exists thanks to all the people who contribute. [Contribute].

Backers

Thank you to all our backers! ๐Ÿ™ [Become a backer]

Sponsors

Support this project by becoming a sponsor. Your logo will show up here with a link to your website. [Become a sponsor]

License

CC0

โฌ† back to top

front-end-checklist's People

Contributors

abnersajr avatar aldo-roman avatar antarestupin avatar asood123 avatar daniel-hug avatar dylantackoor avatar e200 avatar enginelin avatar euclid1990 avatar greenkeeper[bot] avatar jboyer2012 avatar jochenkirstaetter avatar johnsenzhou avatar kristofmorva avatar ledubenjamin avatar matthias-vogt avatar mikestreety avatar miya0001 avatar mrsunshyne avatar nisarhassan12 avatar paulgv avatar paulofreitas avatar petetnt avatar petrkle avatar philraj avatar roger-kang-mo avatar satboy78 avatar squaredindex avatar thedaviddias avatar xhmikosr avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

front-end-checklist's Issues

No digests for javascript files names?

After concat and mini/uglify you generate a digest in the javascript file name.

eg. application-xxxx.js

It ensures that when js files change the cached version doesn't persist because it has a different name.

Preprocessor

In the CSS part, perhaps the use of a preprocessor can be upgraded to LOW or even removed?
A preprocessor is just an option, but not a guarantee of quality.
If used, ok for the SASS recommendation, especially for beginners.

5xx errors and external resources

Remember that the 5xx error page needs to have his CSS integrated (no external call on the current server).

I cannot not find any source for this. Does RFC 2616 mention this in some way?

No HTTPS

Under the security section, the site mentions the use of HTTPS yet the site itself doesn't use it

Trust and Scoping Web Content to Domains

Needs to address having SSL certificates for authenticating the site and trusting content is from originating site. Seems like any front end development will be dependent upon a secure environment such that whatever is created is not hijacked with DNS poisoning of advert, man-in-the-middle attacks, trust, and generally keeping your wire-frames and transfer to partner sites planned properly.

Accessibility Expansion + Animation

Accessibility section should include

Title Tags and Image Tags

  • provide text to screen readers. This is important for developers to understand.
  • Titale tags also tell screen readers where the link goes

Color Contrast

  • this section should include links to multiple palette tools, including
  • Paletton
  • Palette.io

Colors should not be hard-coded
color: #white ;
this is hard-coded, and difficult for users to override
color: #fff;
this is correct

Keyboard Section

  • use an incorporate the keyboard instructions from whatever backend framework is used
  • Skip Menu should also be included

I also agree that an Animation section should be included.
Animation

  • flashing elements should not be used for users with epilepsy. It may cause seizures.

Typo in first line of README

I think the README file should say:

The Front-End Checklist is an exhaustive list of all elements you need to have / to test before launching your site / HTML page to production.

And not:

The Front-End Checklist is an exhaustive list of all elements you need to have / to test before launching your site / page HTML to production.

Make website checkbox clickable

Can we make website checkbox clickable and (why not) count them with a sticky counter on the bottom on the screen ?

Would be happy to work on this, I just dont know how to contribute if I'm doing javascript.

I disagree with certain points of the favicon advice

If you have only a favicon.ico, put it at the root of your site. Normally you wonโ€™t need to use any markup. However, itโ€™s still good practice to link to it using the example below.

Why? Itโ€™s completely unnecessary, getting you absolutely nothing.

Today, PNG format is recommended over .ico format (dimensions: 32x32px)

I strongly disagree with this; 16ร—16 and 32ร—32 are distinct design targets, and there is value in tweaking the design for the different sizes, mostly for optimal clarity at 16ร—16. You can use multiple <link rel=icon> elements with varying sizes attributes, but there are compatibility issues with doing that; itโ€™s safest to have the .ico version include both 16ร—16 and 32ร—32, and then if you have more sizes, add them all to the document head.

Integrate with Lighthouse

While the checklist is awesome, it would be more usable if it were integrated into an automated testing tool. Perhaps it would be worth adding them to Lighthouse

Key words for use in RFCs to Indicate Requirement Levels

There is a specification about the requirement levels in RFC.
http://www.ietf.org/rfc/rfc2119.txt

1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
   definition is an absolute requirement of the specification.

2. MUST NOT   This phrase, or the phrase "SHALL NOT", mean that the
   definition is an absolute prohibition of the specification.

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label.

5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
   truly optional.  One vendor may choose to include the item because a
   particular marketplace requires it or because the vendor feels that
   it enhances the product while another vendor may omit the same item.
   An implementation which does not include a particular option MUST be
   prepared to interoperate with another implementation which does
   include the option, though perhaps with reduced functionality. In the
   same vein an implementation which does include a particular option
   MUST be prepared to interoperate with another implementation which
   does not include the option (except, of course, for the feature the
   option provides.)

If you already know, it is no problem.
I don't think it has to be respected at this project. It is just an information. โ˜บ๏ธ

Thanks ๐Ÿ˜Š

Add an animation section?

Hey David, nice checklist! Here's a suggestion: I'm no professional, but from a user point of view, using animation can absolutely change the way users interact with websites if done right. Maybe add some stuff about this? Thanks again!

-Masky

Suggestion: avoid "click here" links

Maybe you should add this to your frontend checklist: avoid "click here" links.

I see this often on website and you have no idea what the link leads to.

Hope it helps.

Add open collective shield

Add the open collective badge when it'll be working:

[![OpenCollective](https://opencollective.com/frontendchecklist/backers/badge.svg)](#backers)

Image dimensions best practices confusion

I'm busy working through this excellent checklist but I am confused by this one point under Images. Does anyone know what is meant by this?

All <img> have height and width set (Don't specify px or %).
Note: Lots of developers assume that width and height are not compatible with responsive web design. It's absolutely not the case.

I think the wording is confusing, so I might be missing the point but my understanding about image dimensions is for 90% of cases you'll want the image dimensions to be responsive (width: 100%; height: unknown) because you usually want images to fill their their parent container which is usually a dynamic width.

The exception being when you have very small images on the page or if you're making a non-responsive webpage - then you can pre-define the width and height for a smoother page load, but it's not practical to do this in most cases.

Making this part of a build process

I'm a big checklist fan, so thanks for making this. Have you heard of any effort to make the checklist part of an automated build/test process? For example, having a step in a travis build process that will fail if the home page of your site (or other URLs) don't adhere to the checklist?

Just a thought. I don't think I have the technical chops to implement this, but would love to see it.

Collate these into an ESLint Ruleset

Hey all,

Not sure if this is the right forum for this, but wouldn't it be great if we could just run an ESLint Ruleset for all these rules, rather than having to manually check them everytime you do a Production release?

Else maybe a Webpack addon?

Or am I being silly?

How to use it

Hello thanks for your support can you tell me how to use it do i need to upload it to my server and run some file or how please do let me know

Namespacing JS and RAIL for Performance

It might be worth mentioning namespacing with JavaScript to keep things out of the global scope. I have found it's always important to namespace JS to limit conflict possibilities with other code that you may not be aware of. https://www.safaribooksonline.com/library/view/learning-javascript-design/9781449334840/ch13s15.html

Also, the RAIL performance concepts from Google are must have for UI performance. https://developers.google.com/web/fundamentals/performance/rail

Add lang-Attribute note

It would make a lot of sense to tell developers that a lang-Attribute is always needed in the HTML element (first section with doctype).
The point is that screenreaders will automatically switch their language-mode when a lang attribute is present. That way the reader will not announce in a different language than present on the page.

Spanish translation *work-in-progress*

Hi, i forked this repo and started a Spanish translation. You can find it here: Front-End Checklist-ES

The README.md is almost done. If someone can help with fixes or examples on Spanish that would be cool. CODE_OD_CONDUCT.md file pending.

Any help with translation would be great.

Thanks to everyone making this project.

Addition in Performance: Chrome Audit Report

Chrome's Audit provides more insights to the performance, accessibility, pwa and best practices. Those can help to build a better performant site. Let me know if you want me to add that to the repo. Cheers!

"Sass is preferred"

That's a big assumption to make... Sass is preferred by whom? By you, by me, by the Overlords of Planet CSS?

It might be more correct to say Sass is (probably) the most popular CSS preprocessor, but many people choose to use (or are forced to use due to framework restrictions) LESS or Stylus for example.

Personally I don't care which preprocessor is used, as long as you use one. The end result is the same - they make my life easier :)

And what about people who prefer CSS post-processors...

Labels, Search or Sorting

Since the list itself is not sorted, I was trying to find the items marked HIGH.

The way it's constructed right now, it doesn't allow the search to work.

As a Enhancement to the list, I was thinking maybe they could be split into sections or possibly split into sections - High, Medium, Low - which would allow to easier go through the list.

If not, another option might be to add something besides the image that we could use that works with the built in browser search.

Minor typo

Hi there! This checklist is super awesome and helpful, thanks! Thereโ€™s a very minor typo/error that I caught: โ€œCross Site Request Forgery (CSRF): You are ensure that requests made to your server-side are...โ€
Instead of โ€œyou are ensureโ€, I suggest just โ€œyou ensure (remove โ€œareโ€).

Nitpicking for sure! Thanks again for this. Cheers!

Ensure there is an explanation with each point

Firstly thank you for publishing this list it's very useful.

I've noticed that some of the points have no explanation as to why they are needed.

As an example:
A meta description is provided, it is unique and doesn't possess more than 150 characters.

Why does it need to be provided?
Why does it need to be unique?
Why should it not possess more than 150 characters?
What happens if I don't include it?

Some points do have links to other resources or documentation, however a short inline explanation would be very useful.

role attributes on <nav> and <main> are superfluous

This is the Landmarks section under Accessibility > Best Practices:

Landmarks

  • Role banner: High <header> has role="banner".
  • Role navigation: High <nav> has role="navigation".
  • Role main: High <main> has role="main".

Comments:

  • The second link is a 404.

  • The HTML5 elements mentioned here already come with an implied role. In 2012 the Web Content Accessibility Guidlines recommended you still use a role attribute until support for these elements came to screen readers:

    When support for HTML5 improves there may be no need to continue to add the ARIA role="navigation".

    • Because of the wide support for these elements today (at least in browsers โ€” I don't use a screen reader), I think it's unnecessary to specify the same role in an attribute as well.
    • Bootstrap puts this better than me: Ensure accessibility by using a <nav> element or, if using a more generic element such as a <div>, add a role="navigation" to every navbar to explicitly identify it as a landmark region for users of assistive technologies.

dir and lang should be on html, not body

The dir and lang attributes should be placed on the document root, not the body, because they apply to the head (title, descriptions, &c.) as well as the body.

Add structured data (schema.org) to SEO list

I am missing a checkbox for structured data like schema.org.

Addition to the README.md

  • Schema schema.org: High Structured data helps crawlers understand the content in the current page.

Brazillian Portuguese translation - Work in Progress

I am vastly grateful for this checklist, so I think this is the smallest thing I could do for it.

This is the fork, some remarks:

  • Just finished the README translation;
  • I translated most of the documentation articles' titles for readability, do ping me back if you think it's better to revert them;
  • Should have the Code of Conduct done by two days from now - or at the very most, end of the week.

Hope we'll make this an i18n checklist ๐ŸŽ

Page size limited to 500KB?

I don't see the arguments of limiting the page size to 500KB in the links under the recommandation in the performance section. I agree that pages should be light, but 500KB seems arbitrary.

As the ideal size of a page depends on too many things, I would recommend to replace this limit by the use of a performance budget, which is more flexible than a fixed limit and a good way to make the team responsible about the pages size. Tools like the performance budget calculator are very helpful to compute the budget.

Alternatively, if you want an interesting fixed limit, you can recommend to limit the size of the critical content to 14KB, so that the browser will be able to start rendering it during first TCP roundtrip. But that's an advanced practice, I'm not sure it would fit in this list.

Generator

I think that it need develop a generator for whole guideline to generate a index.html page

No mention of Security

I can't help but notice the lack of a section on Security. As a suggestion, it may be worth adding some mention of SRI attributes where applicable, and ensuring CSP directives (alongside other useful stuff like CSRF protections) are included.

Korean Translation is work in progress

Hello! I forked this repository and started to work to translate into Korean. Here is repo; here

I just forked it, so have some things to do bit, but will do within 2 days. :)

Thank you for making this project.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.