bendc / frontend-guidelines Goto Github PK

View Code? Open in Web Editor NEW

8.3K 8.3K 661.0 22 KB

Some HTML, CSS and JS best practices.

frontend-guidelines's People

Contributors

Stargazers

Watchers

Forkers

flexbox wakkos rverbitsky robergd pbamotra mubassirhayat pamsan mrkeng mattwebdev aliciimo toke phamtrisi larz0 brownmestizo alexanderkwright nullnotfound erinwilbur khalilbenihoud alevizio luigidon aldass kevinrodbe wcwung igalanga justinslack beetaa aphoenix tinhspace idrakimuhamad tbmluijten soundarapandian mauriciosoares i5ting bradparks wagnermatos grafick connormckelvey prabhjotsl eab70 chrisnusbaum kevinmcalear kyasui nicmarson andykov timuric onnayokheng nadoneves utkarsh141194 denis-sharypin cmariee asmithdigital dbuckley212 tagawa mesutcan jsnuts raihanhbh techierishi moscoding a3linux carloscabo dbertella klipitkas sludovic tapester chrisvdd gigo101 wildflame idrus82 tlinqu dvimster freewayspb dontpanicgr garygong kamdjouduplex luis-palacios mkaksingh dmitrysimonov simaq natewave ozf paddingme xiaohutai ematav corbmx justname4me pjstol pswaminathan achalj09 martincx antouank oliviachou plugins-resource wpsteak minasokoni ezhangle gerachev ashrough monkuver zengwx lifelive

frontend-guidelines's Issues

Unusable at this time

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 ?

shows a blank page when i use this code

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;
}

a website ?

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 :)

Why?

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

making it more interesting to learn

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

html5 why should out developer abandon <body>title and so on

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 ?

Global box-sizing

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

You can eliminate </html>

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>

Justification

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

The point 'Accessibility'

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

IE9 needs the body tag...

Maybe put a caveat under this section regarding this... http://stackoverflow.com/questions/5641997/is-it-necessary-to-write-head-body-and-html-tags

"Use shorthand properties"

I don't agree with this guideline.

See : http://codeguide.co/#css-shorthand
https://developer.mozilla.org/en-US/docs/Web/CSS/Shorthand_properties

Suggestion: introduction block

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.

Covering WAI-ARIA and form accessibility

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.

frontend-guidelines-zh-CN(前端指南汉化)

地址：https://github.com/ShanaMaid/frontend-guidelines-zh-CN/

ES6 Features Unsupported In Most Browsers

=> , 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?

IIFE's and return statements over if, else if, else and switch statements

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.

Table of contents?

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

Both object iterations mentioned are slow. Use native for loop

// 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]];
}

Lamda syntax might cause confusion

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.

Front end practical

px for font-size?

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

Suggestion: add classes to the HTML semantics example

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>

Missing "new" keyword?

// 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?

Why px over em?

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/

DOCTYPE instead of doctype?

not quite sute about this one, but sublime syntax check complains when i doctype instead of DOCTYPE.

favour px over relative units

really sure about this?

http://css-tricks.com/why-ems/
http://css-tricks.com/forums/topic/whats-the-benefit-of-using-ems-instead-of-pxs/

Extend Semantics

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.

ArrowFunctionExpression is not supported

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?

Question: why omit <body> and <head>?

While they are not required in HTML5 anymore, many would argue that it's better to be explicit about these for clarity.

JS never your performance bottleneck?

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?

Recursion in JS is actually bad

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.

[FEATURE]: Refactor README.md

The README.md is long, so it would be better if each guide were broken down into separate files.

Clarify or reconsider box model guideline

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?

What about script async and defer?

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.

calc() Not fully supported

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)

Colors

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.

Double quote missing on some HTML property values

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.

Disclaimer

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.

Avoid Curry vs. product.bind()...

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.

Hacks

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.

Keep your code terse. Forget about your old XHTML habits.

The element <head> isn't required?