Front-End Checklist

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

by tomcam • 9 years ago

193 81 9 years ago

github.com

miguelrochefort3• 9 years ago

It's already missing iPhone X support.

zeronight• 9 years ago

It will be interesting to find what the visitor percentages are for iPhone x.

Even though its Apple, at some point its not worth spending the time and money.

miguelrochefort3• 9 years ago

The iPhone X will be sold out everywhere until 2018.

jkaljundi2• 9 years ago

Are sitemaps still a thing that really matters?

miguelrochefort3• 9 years ago

Don't you wanna get crawled?

irrational2• 9 years ago

Actually I do work on a website that we do not want crawled. It would be handy to know which things to leave out to make it less likely your site will be crawled or show up high in a google result.

jkaljundi2• 9 years ago

Have not found the crawl rates changed for sites where everything is well linked together. Then again, these have been just small sites with a few million pages.

hayksaakian• 9 years ago

If you're coding it from scratch, don't bother.

If you're using wordpress or another pre-baked system, then it's worth having a sitemap plugin (example: Yoast SEO) or the built-in sitemap (like for Shopify).

Submit it to Google Search Console, Bing, and you're done (essentially).

franze4• 9 years ago

<body lang="en"> - High?

why?

stephenr• 9 years ago

I'd have thought things like that were better handled as a response header (same for the charset).

robin_reala5• 9 years ago

No, because pages can be saved, and then the page loses the information. Or rather, by all means do it (it does get the information to the browser quicker) but make sure you also add the information to the page.

Teichopsia3• 9 years ago

I also found that odd. I've always placed mine in the HTML tag.

  <html lang="en">

tough, I don't know what the difference is.

robin_reala5• 9 years ago

Putting it on <html> is better as that defines the language for <title> as well. The lang attribute defines the language of the tree that the element is the root node of.

sjmulder• 9 years ago

I use VoiceOver sometimes which will switch to an appropriate voice for the language.

Raphmedia2• 9 years ago

Alternative text: High All <img> have an alternative text which describe the image visually.

Please don't do that. Don't put an alt on ALL images. Screen readers will read all of them. Skin and flavour images don't deserve to be read outloud. Nobody wants to hear "bottom left corner of logo" or "rounded corner".

robin_reala5• 9 years ago

Typically you’d use background images for something like that. Regardless, if you do have an image that doesn’t add anything to the information on the page give it an empty alt attribute to indicate to the screen reader that it shouldn’t try to read out the file name or something.

Teichopsia3• 9 years ago

  <img src=".." alt="">

Do you mean like that? Empty quotes and it would not be read?

epmatsw• 9 years ago

Hmm. Why not aria-hidden=true?

rimliu3• 9 years ago

This recommendation would be fine 20 years ago. You should not have any decorative images in your markup, they belong to CSS.

seanwilson5• 9 years ago

Why? It shouldn't make any difference if you add alt="" to the img tag.

corymayfield• 9 years ago

Some people like myself work in places where there are still some clients that ask for IE6 compatibility and have to comply with WCAG 2.0 accessibility standards.

Raphmedia2• 9 years ago

Agreed but it does happen. Sometimes, the line between content and decorative it pretty thin.

Should you add an alt to a stock photo?

Should you disturb a user with a reading of "stock photo of a business man smiling" next to a sales paragraph? What about "sunset over a mountain" on a page for a SaaS website?

FilterSweep• 9 years ago

Nobody wants to hear "bottom left corner of logo" or "rounded corner".

I would assume front-end guys care more about passing a Web Accessibility[0] audit than inconveniencing some users, thus good taste and wise discretion is spared for avoidance of litigation.

[0] https://www.w3.org/TR/WCAG20-TECHS/H37.html

mrlase• 9 years ago

While that link is part of WCAG 2.0, there are other items within the standard to follow such as: https://www.w3.org/TR/WCAG20-TECHS/H67.html. Decorative images are not supposed to be read by the screen reader.

https://www.w3.org/WAI/tutorials/images/decorative/

leepowers• 9 years ago

Seconding this. It very much depends on the purpose of the image. If an image or any other tag is extraneous in a screen reader context use the `aria-hidden`[1] attribute to exclude it.

A good example is an image used as an icon next to a text label. Imagine a link/button that contains the words "Save" and a floppy disk icon. There's no need to have an alt of "Save" on the icon as the text "Save" is already present. So it would look something like this:

    <a href="#"><img src="save-icon.png" aria-hidden="true">Save</a>

Though in this case you'd probably be using an icon font like FontAwesome.

[1] https://stackoverflow.com/questions/31107040/whats-the-diffe...

extra882• 9 years ago

The first rule of ARIA is don't use it if you don't have to. An img element with an empty alt attribute will tell the screen reader not to read it and is more widely supported than the aria-hidden attribute.

'aria-hidden' is for HTML elements that don't have their own way of hiding themselves from assistive technologies and for cases where you'll use JavaScript to change the element's hidden state. I can't think of a situation where you'd want to conditionally show and hide only an image only from screen readers but if you had that situation, toggling aria-hidden would be better than adding and removing the alt attribute's value.

stefantheard• 9 years ago

Awesome list, I always forget about several things on here it's going to be nice to have a reference to prevent that from happening.

iKenshu• 9 years ago

What about back-end? Should be nice have one

techtalsky• 9 years ago

OWASP guidelines are a good start.

MatthewPhillips• 9 years ago

Note that you don't actually need the head or body tags in your page. The browser already knows what is allowed in the head. It looks weird at first, but you can write your html like so:

  <!doctype html>
  <html lang="en">
  <title>My Title</title>
  <div id="main"></div>

Also note that the html tag can also be omitted, unless you need to set the language. Don't worry about closing it either.

Deimorz• 9 years ago

Edit: my original comment (retained below) is wrong about this being malformed, and it's completely valid. Some more info here: https://html.spec.whatwg.org/multipage/syntax.html#optional-...

---

Original comment:

The fact that browsers are able to handle malformed HTML doesn't mean that you should do it that way. There's no meaningful benefit that I can think of, and the potential to break a ton of things that aren't as lenient.

Pxtl• 9 years ago

The new craziness is basically that HTML is no longer structured as a tree, no more closing tags that don't semantically hold data, etc.

irrational2• 9 years ago

My understanding is that it is not malformed, but actually a part of the spec. Maybe someone else has a link to the appropriate part of the spec, but following someone else's link to the spec and reading it for myself is how I learned that it is not malformed.

Yaggo• 9 years ago

It's not malformed in the traditional meaning, the HTML5 spec actually says that HTML, HEAD, BODY, etc. unambiguous tags can be omitted.

rimliu3• 9 years ago

This is not malformed HTML. In fact, optional tags were in older HTML specs and are perfectly legal. Even in HTML 4.01 Strict. See: http://rimantas.com/bits/minimal_html.html

c_shu• 9 years ago

Removing optional tags is recommended here: https://google.github.io/styleguide/htmlcssguide.html

davedx• 9 years ago

These are very subjective, I've never done half of the 'high' priority items, and I've never had any issues with my site having a 'disfunction'. Take this list with a gigantic grain of salt.

For example, your site certainly won't break from missing the 'lang' attribute.

DerfNet• 9 years ago

submit a pull request

groby_b2• 9 years ago

No. But e.g. automated translation now needs to guess your language, and that's... not always successful. Screenreaders will need to guess the language to pronounce properly. Search engines will have to infer the language. And so on.

Your site isn't "broken", per se, but it's not as high quality as it could be.

chrismorgan• 9 years ago

I wonder how much lang=en can actually be trusted—enough things put it in by default that I can easily imagine its presence on non-English pages.

Update: from elsewhere on this thread, Google ignores <html lang>:

But the language attribute within the HTML markup is something we don't use at all. We've found that this language markup is something that is almost always wrong. So we tend to ignore that.

https://www.seroundtable.com/google-ignores-the-html-lang-at...

amk_• 9 years ago

This would be a good checklist for anyone considering building a UI framework. This kind of thing is the reason Bootstrap & friends are so large - they do a lot for you.

threatofrain• 9 years ago

An oft overstated thing -- but the organization of CSS is currently being massaged by the front end community, and in-line CSS is no longer considered an awful thing with Radium and others.

ozaark5• 9 years ago

Seems like this could be presented without as much clutter. Not really useful at a glance for a checklist. Also, some of the info isn't well researched and lacks citations for claims as others have mentioned.

One would be better off just using the Google Web Starter kit[1], other boilerplate options, or just chrome dev tools running Audits to get started with a solid front-end.

[1] https://developers.google.com/web/tools/starter-kit/

rco8786• 9 years ago

Following this list is a great way to never launch something into production.

speedplane2• 9 years ago

Seriously... surprised there isn't a tabs or spaces diatribe in there.

sergeyfilippov• 9 years ago

Just keep a boilerplate handy

I've helped a friend to publish a one-page website over the weekend, and I believe it follows most of this checklist

chente• 9 years ago

Pixel perfection, are we still striving for that?

ravenstine• 9 years ago

All <img> have height and width set (Don't specify px or %)

So what unit should be used?

CM30• 9 years ago

None, image height and width attributes don't have the unit included.

(They generally assume these values are in pixels by default[1])

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/im...

frio• 9 years ago

I can't help but notice there's no "Security" section. Perhaps by the time you've got the HTML rendering it's too late, but SRI tags, CSP headers and whatnot all deserve some mention.

https://github.com/thedaviddias/Front-End-Checklist/issues/2...

mycentstoo• 9 years ago

What would be a great idea is an app that scans for the presence of these conditions.

laktek• 9 years ago

If anyone wants to have a crack at it, you can use Page.REST to build it. If not I might be able to get to it towards next week :)

speedplane2• 9 years ago

Here's a better checklist: Run a W3 validator on your HTML, fix the red stuff that isn't too annoying to fix. Launch. Deal with all that other stuff later.

adad95• 9 years ago

I love the http://webdevchecklist.com/ site.

swoongoonz• 9 years ago

Pixel perfect: High Pages are close to pixel perfect. Depending on the quality of the creatives, you may not be 100% accurate, but your page needs to be close to your template.

What is this 2004?

Front-End Checklist

Related Stories