bendc / frontend-guidelines Goto Github PK
View Code? Open in Web Editor NEWSome HTML, CSS and JS best practices.
Some HTML, CSS and JS best practices.
You mention avoiding curry (which I highly disagree with) but you're essentially currying/partially applying in your example of:
const product = (a, b) => a * b;
const triple = product.bind(null, 3);
If you were to follow your earlier guidelines, wouldn't this recommendation instead be:
const product = (a, b) => a * b;
const triple = (a) => a * 3;
I agree that the first example is more elegant, but true currying is even more so. It might be more useful to say "don't abuse curry" than "strictly avoid it." I do agree with you that the following could be construed as unintuitive for the uninitiated:
const sum = a => b => a + b;
sum(5)(3); // => 8
but that function definition does not implement true currying, as you are unable to fully supply the arguments in the initial call; it's essentially a poor-man's curry. If this were to be a proper curried function, you could do the following:
const sum = curry((a, b) => a + b);
sum(1)(2); // 3
sum(1, 2); // 3
const add5 = sum(5);
add5(5); // 10
Is this not what you're striving for with elegance, composability, and reusability? I think this is a wonderful guide, but this suggestion in particular struck me as extremely out of place.
Although the format of good
and bad
is great these are opinions are proffered without justification. It would be good to say "x is bad because..."
=> , Map(), const, ... (spread operator), etc are all currently unsupported ES6 features.
I think it might be unclear to many who stumble across this guide that these require transpiling and do not have wide support. Perhaps note this, or change examples to reflect current standards?
hello,I am a beginner. I think html5 has too many new charter. though it's useless. but I think it will take some time to replace it .what do you think ?
The README.md is long, so it would be better if each guide were broken down into separate files.
Maybe put a caveat under this section regarding this... http://stackoverflow.com/questions/5641997/is-it-necessary-to-write-head-body-and-html-tags
Hi,
I think that would be necessary add examples of form accessibility, like the importance of fieldset
grouping, legend
and the correlation between labels and input fields. Also as WAI-ARIA basics covering simple roles and "described by" attribute (maybe live regions?). IMO it's a way of instigate readers to dive into this subject.
Thanks.
This example:
<article>
<header>
<h1>Blog post</h1>
<p>Published: <time datetime="2015-02-21">21st Feb, 2015</time></p>
</header>
<p>…</p>
</article>
...is probably better written with class names. Personally I would rather sway against the practice of styling plain tags (article
, header
) as it can lead to problems once you start scaling your site.
<article class='blog-post'>
<header class='post-header'>
<h1>Blog post</h1>
<p>Published: <time datetime="2015-02-21">21st Feb, 2015</time></p>
</header>
<p>…</p>
</article>
Never worry about writing performant JS just doesn't make any sense... for example, throttle on things like scrolling event is essential to have smooth 60 fps scrolling. Since JS will never be a perf bottleneck, why would people still bother to pre-compile handlebar templates?
Hello, thank you for sharing this guideline!
I have a doubt:
Keep your code terse. Forget about your old XHTML habits.
The element <head>
isn't required?
// doesn't work
const unique = arr => [...Set(arr)];
// works
const unique = arr => [...new Set(arr)];
Maybe the new
keyword is somehow implicit in some cases, but it doesn't works on any modern browser. Is that a real issue or I'm missing something?
Hi,
you're writing the company name in the alt-Tag. In case for accessibility to work you should use "The Logo of My Company Inc.", so people who can't see know, what the screenreader is doing there.
This is especially important for all images. Try to describe what's the image shows.
Just a tip. :)
isInvalid: function() {
//if question is prepopulated and there are answers available,
//make sure button is enabled
if (this.get('buttonIsActive')) {
return true;
}
if ( this.get('selected') || this.get('answer') ){
if (Ember.isArray(this.get('selected'))) {
return !this.get('selected').mapBy(function (choice) {
if (typeof choice === 'object') {
console.log(choice);
return choice.selected;
}
return true;
}).length;
}
return false;
}
not quite sute about this one, but sublime syntax check complains when i doctype
instead of DOCTYPE
.
In your examples, you stress brevity (and presumably clarity). One thing I do that makes HTML documents easier for me to read is to eliminate the closing </html>
tag and move the indentation up 1 level, which is still valid HTML5:
<!doctype html>
<html lang=en>
<meta charset=utf-8>
<title>Contact</title>
<link rel=stylesheet href=style.css>
<h1>Contact me</h1>
<input type=email placeholder=[email protected] required>
<script src=main.js></script>
</html>
becomes
<!doctype html>
<html lang=en>
<meta charset=utf-8>
<title>Contact</title>
<link rel=stylesheet href=style.css>
<h1>Contact me</h1>
<input type=email placeholder=[email protected] required>
<script src=main.js></script>
Hello Benjamin,
why do you see hsl inferior to hex?
Hsl gives me the possibility to work with colors: if I want to tone down the color for the active state I adjust the lightness. When I want to create a slightly blue toned gray I use a hue of ~200, a saturation of ~8% and ~97% lightness.
// bad
for (var prop in obj) {
if (obj.hasOwnProperty(prop))
console.log(prop);
}
// bad
Object.keys(obj).forEach(prop => console.log(prop));
//good -- fastest
keys = Object.keys(obj);
for (var i = 0, l = keys.length; i < l; i++) {
result = result + obj[keys[i]];
}
Nice guide, most of the guidelines I find very good.
One thing I found peculiar was the box model guideline. This seems to go against industry standard, and is difficult to understand. For instance:
Do you know something I don't here?
Thanks for sharing your guidelines.
Why would you suggest dropping the header & body tags?
Many tips (almost for javascript) rely on experimental feature, with no support on some major navigator.
Like: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions
What it 's Intended to do in this guidelines ?
Thank your for your résumé, could you perhaps improve it with on advice that could need it, explain why your approach is better.
For JS tips, it could be very useful I think, as it is better to understand why we do such a way than just copying advices without understanding the underlaying logic.
Thanks again
In the article under performance you mention including scripts at the bottom of the page. However, I think this is misleading. It is possible to include scripts in the header and not have them block the page through the use of async or defer.
I think it is also important to add that there are times when you don't need to include an external file. If you are including code that is a few lines, you can inline it into the page and it'll always be faster because you're avoiding a HTTP request.
I recommend using "defer" by default. This article from 2010 actually explains what each of the attributes do and how they affect the page.
I really like many of the points you've made through the guide. 👍
One area of semantics that many devs, I've met, have trouble knowing is when to use <section>
over <article>
, vice-versa or even over <div>
.
You managed to side-step it by using class names on the original markup.
Other (html5) elements like <header>
, <footer>
, <hgroup>
, <aside>
etc are self evident, but I think the guide would benefit from a brief example of where <section>
and <article>
should be used.
Would you consider using https://github.com/thlorenz/doctoc to insert a table of contents? I think it would help navigation, especially as the file gets bigger....
Hey @bendc
This is AWESOME list! Thanks for putting it together. There is one issue though and may be I misunderstood this one:
const isEven = n => n % 2 == 0;
This throws error: SyntaxError: Unexpected token '>'
also: ArrowFunctionExpression is not supported
This seems a coffee-script syntax, is it supported in JS?
While they are not required in HTML5 anymore, many would argue that it's better to be explicit about these for clarity.
I think many devs would understand the Lamda syntax you're using for your JavaScript examples; such as :
// bad
const toArray = obj => [].slice.call(obj);
// good
const toArray = (() =>
Array.from ? Array.from : obj => [].slice.call(obj)
)();
But ...
"This is an experimental technology, part of the ECMAScript 6"
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions#Browser_compatibility
And I believe only the Gecko (Firefox) engine support them; I know the current Chrome I use (40.0.2214.115) doesn't support this Lamda syntax - I do wish they all would tho!
Regardless, it might be a source of confusion for readers - especially ones that might try to understand the example by running it.
Many discussions have took place about the use of global box-sizing
.
A better practice for using border-box
on every element is the following:
html {
box-sizing: border-box;
}
*, *:before, *:after {
box-sizing: inherit;
}
This is better because it will allow external plugins, constructed on the "standard" behaviour to use easily the standard box-sizing
Hello @bendc
This guide looks great
Do you want a pull request for a website like this one ?
https://github.com/flexbox/foundation-boilerplate
If not you can close this issue :)
Also the use of calc()
. I know you keep cited "Standards" but this isn't fully supported and currently CR.
https://developer.mozilla.org/en-US/docs/Web/CSS/calc#Browser_compatibility
Duplicate from : #22 (comment)
Hi Benjamin!
Could you please explain advantage of using returns instead of regular switches?
I never seen this approach before and tried it with jsperf. It looks very interesting.
There should be a disclaimer clarification telling that this is it a personal recopilation of ideas through years of experience and not something you should do exactly in all your projects.
Hope you don't mind me saying that the example stated for this section seems bizarre given it's relative obscurity and at best, nascent support.
Such an odd choice of property would fine (and even informative) were it not at risk of completely over shadowing the broader context.
Perhaps another example would be better; I would of made a suggestion but due to the sections brevity it's hard to judge exactly what the broader point being made here is.
As Javascript doesn't have TCO (yet), recursion will make the browser crash when traversing big Arrays. If you cannot be completely sure the Arrays won't be too big, you should avoid it whenever possible.
I think there should be a project as well telling the use of all the tags so that anyone learning can execute them and learn from it .i would love to contribute in this process of making it a better place for learning and growing
Ben, first, AWESOME repo.
Second, I noticed that some of the syntax under the HTML section doesn't contain quotes for all property values. Ex:
<input type=email placeholder=[email protected] required>
In some cases you do include it:
<input type="email" placeholder="[email protected]" required>
For consistency I think you want to keep with one pattern.
I get the other suggestions inside the Units section, but I can't understand why you'd be suggesting px over other units, in particular px over rem (like in your example).
Hey Ben, this was an amazing read, and thank you for sharing.
A few others have already raised this point, and I wanted to open a separate issue and share my concern too: The phrasing and format of this document comes across as "The Right" way to do things (// bad
vs // good
).
A new, fresh front-end developer that might come across this will learn some great stuff and also debatable opinions. A lot of these examples are not necessarily the "best practices for maximum browser support" and most of it is fluctuating technology.
You've expressed in #4 that you won't have time to explain in each and every block why you personally chose this style, so I would suggest just a simple introduction/note right at the top under your heading, simply stating these are opinions and suggestions.
In reference to "Favor pixels over relative units".
I'd like to hear your reasoning, as most people I speak to prefer em over px, including my own preference.
Also, good reading:
http://nerd.vasilis.nl/using-pixels-polite/
I don't agree with this guideline.
See : http://codeguide.co/#css-shorthand
https://developer.mozilla.org/en-US/docs/Web/CSS/Shorthand_properties
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.