thedaviddias / front-end-checklist Goto Github PK

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.

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

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

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

Addition to the README.md

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

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

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!

It seems list tag is missing here ;)

The "Portuguese" port is showing the Brazilian flag, I think it would make more sense to show the Portuguese flag.

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!

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...

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".

• 📖 Using ARIA landmarks to identify regions of a page
• 📖 ARIA roles categorization

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.

High/Medium/Low buttons have excessive margin/padding on Chrome (Win7)

On GitHub:

Homepage:

CSS rules:

Box-model view:

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.

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

The homepage isn't showing GitHub-style checkboxes at the start of each item.

Perhaps this can be fixed in the build process?

On GitHub:

Homepage:

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.

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.

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

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

subj :)

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.

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.

http://yahoo.github.io/debugCSS returns 404.

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.

In the optimization section you state:

Minification: High All CSS files are minified. (Not for HTTP2)

Actually you should minify the CSS even with http2 because this protocol will compress Headers, not the body of communications.

Ref:

• https://http2.github.io/http2-spec/compression.html

Hi @thedaviddias,

I saw the checklist is missing link tags for paginated lists. The following <link> tags would be added in the <head> on page 2 of a paginated list.

<link rel="prev" href="https://example.com/?page=1">
<link rel="next" href="https://example.com/?page=3">

See: https://support.google.com/webmasters/answer/1663744?hl=en

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.

• https://en.wikipedia.org/wiki/Same-origin_policy
• https://developers.google.com/web/fundamentals/security/csp/
• https://letsencrypt.org/getting-started/

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 🎏

Hi,

It is just a ping. 😊

I translated it to Japanese.
https://github.com/miya0001/Front-End-Checklist

It is really nice work and helps us very much, Thanks.

Feel free to close this issue. 😊

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.

https://github.com/ynizon/Front-End-Checklist/blob/master/README.md

thanks

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

LICENSE says MIT, but README.md says CC0.

I'm assuming you intended CC0 but just wanted to clarify.

Thanks for the excellent work!

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.

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?

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.

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.

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.

Function checkingItem has 40 lines of code (exceeds 25 allowed). Consider refactoring.

https://codeclimate.com/github/thedaviddias/Front-End-Checklist/src/scripts/components/Storage.js#issue_5a0d51836d0bab0001000084

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?

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.

Thank you for extremely useful checklist!

I have just finished Russian translation. Could you please add a link to the Translation section?

https://github.com/ungear/Front-End-Checklist

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.

There is discrepancy between the character limit specified between the title tags (65) and the one in the description (55).

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.

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.

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.

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 😊

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