Some HTML, CSS and ES2015 Best Practices(github.com)

18 pointsby benjamindcvor 11 Jahren10 comments

Some HTML, CSS and ES2015 Best Practices

https://github.com/bendc/frontend-guidelines

5 comments

I vehemently disagree with the recommendation on box models. I'm of the opinion that `border-box` leads to cleaner, terser css. Working around the default box model results in all kinds of CSS gymnastics that some poor person is going to have to figure out in a few months time when they pick up the project.

I also can't agree with the recommendation on using pixel values over relative values. I guess most people are using some sort of CSS preprocessor these days, so a pixel to rem mixin would be my recommendation.

Not to poo-poo the whole thing though. A lot of that stuff I agree with. A small amount I don't, and a couple of things I think are up for debate.

benjamindcvor 11 Jahren

I guess I should clarify this example. I’m mostly fine with a global * { box-sizing: border-box; }, I’m only opposed to changing the box model randomly. The example illustrates a bad usage where changing the box model to get a full-width element is fundamentally wrong (since it’s the default behavior of block elements anyway).

tomeldersvor 11 Jahren

Oh, in that case I vehemently agree

mattchambvor 11 Jahren

Lots of "whats", not many "whys"

Is there any explanation for the reason for a lot of these things?

benjamindcvor 11 Jahren

Yup, I guess I should just be a bit less lazy and give a bit more context for each section :)

Some things are just personal preferences and some things are just completely subjective. Overall, though, these advices tend to make front-end code better. The JS part, for example, is largely based on functional programming best practices. Things like immutability, statelessness and the point about JS performance aren't subjective: they'll basically always improve your code's quality.

bjornsteffansonvor 11 Jahren

Some of these examples are valid and should be common knowledge for all web developers (e.g.: treating CSS semicolons as terminators rather than separators; transitions; unitless values; all [+1]), and some of these examples are a bit questionable. The code style seems a bit esoteric, especially some of the ES. Also, not many of these examples would pass an HTML validator without warnings due to the lack of quotes surrounding attributes. Just a caveat..

benjamindcvor 11 Jahren

You're wrong, the HTML is valid.

beernutzvor 11 Jahren

I like a LOT of these comments, but some just leave me scratching my head:

// bad void function() { /* IIFE / }();

// good (function() { / IIFE */ }());

To me, the "bad" one was more readable until I noticed you were invoking the function. Personally, I don't like either notation, but the point is that this example (along with quite a few others) seems to need more explanation to get the point across.

I would maybe think about defining "IIFE" as well as maybe sectioning off the more "functional programming" sections.

Thank you for taking the time to put this together.

malftvor 11 Jahren

Several of the examples have an extra lambda like this. What does it do?

const toArray = (() => Array.from ? Array.from : obj => [].slice.call(obj) )();

benjamindcvor 11 Jahren

It's an IFFE (Immediately-Invoked Function Expression). The goal is to perform the feature test (the availability of Array.from in this case) just once instead of for every function call.