Some HTML, CSS and ES2015 Best Practices
github.com
Some HTML, CSS and ES2015 Best Practices
1–10 of 11 posts
Re: Some HTML, CSS and ES2015 Best Practices
#2Lots of "whats", not many "whys"
Is there any explanation for the reason for a lot of these things?
Re: Some HTML, CSS and ES2015 Best Practices
#3Lots of "whats", not many "whys" Is there any explanation for the reason for a lot of these things?
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.
Re: Some HTML, CSS and ES2015 Best Practices
#4Some 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..
Re: Some HTML, CSS and ES2015 Best Practices
#5I 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.
Re: Some HTML, CSS and ES2015 Best Practices
#6Some 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 su…
You're wrong, the HTML is valid.
Re: Some HTML, CSS and ES2015 Best Practices
#7I 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…
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).
Re: Some HTML, CSS and ES2015 Best Practices
#8I 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…
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).
Oh, in that case I vehemently agree
Re: Some HTML, CSS and ES2015 Best Practices
#9Several of the examples have an extra lambda like this. What does it do?
const toArray = (() => Array.from ? Array.from : obj => [].slice.call(obj) )();
Re: Some HTML, CSS and ES2015 Best Practices
#10Several of the examples have an extra lambda like this. What does it do? const toArray = (() => Array.from ? Array.from : obj => [].slice.call(obj) )();
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.