taitems / front-end-development-guidelines Goto Github PK

Please add more guidelines on CSS USage and semantic HTML

I use ExtJS library and they use single quotes everywhere. To me it's mostly a question of style except one good argument I've found so far: generating HTML. It's more convenient to use single quotes when you output html because html attributes are typically enclosed in double quotes:

    '<div class="calendar-popup" style="display: none;">',
        '<div class="calendar-popup-inner">',
        ...
        '</div>'
    '</div>'
];

I suggest a less strict guideline: just be consistent. Use whatever quotes you like but use them everywhere.

"The better way is to set a specific width on the parent element (it doesn't work if it is "auto") and an overflow value of either auto or hidden."

I'm to lazy to look up and test this out to figure out exact situations. But I often use width:auto to help clear floats so I know it does work.

This section was never finalised before release.

Discuss comment headings on blocks of CSS code.

yo, nice write up! by no means am i being critical here, just wanted to point somethings out....

1. css shorthand is optimal...for making your css smaller. it is not optimal how it is presented in these guidelines. using shorthand simply because it is shorter can/will cause build-ups/bottlenecks in performance. mostly because of Reflows, Repaints,and Redraws. i agree with you actually, i prefer shorthand, but i've switched up for single property declarations for better performance/optimization.
2. i only use camelCasing in markup for Ajax classes. and JSON classes. the camelCase denotes to developers that the class is only there for JavaScript usage, i've found this to make things quite readable, especially when fixing bugs on the fly.
   POSH and XHTML demand lower case...i realize its a new ballgame with HTML5/CSS3 but i still have yet to hear a good argument against all lowercase all the time...mostly the arguments are all about personal preference, which i understand completely. right here i am arguing my preference(s).
   furthermore data attributes must be in lowercase, so i see no reason to deviate from the plan; mixing them up will just confuse alot of peoples. especially if someone is researching microformats and realizes that they are (mostly) all speed in pseudo camelCase (hCard, hAudio, etc.)...i can totally see peeps thinking that a) that is how the microformats are spelled and b) bleeding those practices into other areas where lower case is a must case

i have some more thoughts that i'll gather and get back @ ya. but this is great. nicely done sir!

I am guessing that the following code example is not actually supposed to be using PHP style variable naming:

// before
var $quoteLinks = $(".quote a");  // the only DOM query
$quoteLinks.bind("click", doStuff);

// now
$quoteLinks.addClass("quoteLink");

// later
$quoteLinks.fadeIn("slow");

Should the first line (and subsequent references) be: var quoteLinks = $(".quote a"); ?

I was using a font that was allowed for font embedding as long as I removed the OTF and TTF files.

Unfortunately I swapped this out at the last minute and forgot to check the EULA (I thought they were from the same foundry).

I now have to swap out "Gotham". Yes, this is embarrassing as I ignored my own section on reading the EULA.

"Tangentially, I find it odd that what I can only assume is an American authored library uses such a profoundly British word as queue."

I'm sure you'll agree that an individual with even a basic, introductory, understanding of data-types will immediately recognize one so fundamental as a queue. Your statement, which suggests otherwise, could cause some readers to question the credibility of what you've put together. Just a thought.

In section Always Specify the Second ‘radix’ Parameter When Using .parseInt(), it is said that

When parsing a string to an integer, it is considered good practice to specify the second 'radix' parameter - which determines to what base the string should be converted to. It is, by default, octal/binary - so you will run into some problems.

This is actually not true. ECMA-262 specifies that

The parseInt function produces an integer value dictated by interpretation of the contents of the string argument according to the specified radix. Leading white space in string is ignored. If radix is undefined or 0, it is assumed to be 10 except when the number begins with the character pairs 0x or 0X, in which case a radix of 16 is assumed. If radix is 16, number may also optionally begin with the character pairs 0x or 0X.

I do not, nevertheless, challenge the importance of always specifying the radix.

Edit: Rant trimmed.

A page about front end development guidelines should probably pass W3C markup validation:
http://validator.w3.org/check?verbose=1&uri=http%3A%2F%2Ftaitems.github.com%2FFront-End-Development-Guidelines%2F

As of May 6: 48 Errors, 4 warning(s)

In your commenting section you should always use single line comments for the reason listed in Douglas Crockford's JavaScript: The Good Parts

The example you give for this section:
var MOUSE_TIMEOUT = 30;

is, i believe, a good practice: variables that are supposed to be 'constant' (stuff like intervals, timeouts) can be differentiated by using ALL_CAPS. I'm sure you meant 'variables' in the general sense, so maybe it makes sense to change the example to something like:

var ARRAY_LENGTH = myArray.length; // bad
var arrayLength = myArray.length; // good

Self is a reserved keyword, use _self instead.

As per: http://news.ycombinator.com/item?id=2519614

Hi,

thanks first of all for your interesting article. What do you think about:

• Pagespeed in general (Chrome inspector e.g. FPS, Network, etc.?)
• Loadtimes in network view?

Best

As per:

http://news.ycombinator.com/item?id=2519548

Hi and congratulations on your article.

However, I have a few comments:

1. Whitespacing & Formatting both in the JavaScript and CSS sections are mostly subjective.

2. This has no params although the comment says so:
   /*
   Initiated When: zeroAsAString === 0
   Parameters: param1, param2
   */
   function doHeapsOfStuff() {

}

3. Camel Case Variables: I used upper-case only names for things that I use as constants.

4. Readable Milliseconds: false, you should not make the compiler do the math each time. Just put the final result in and using inline comments show the calculations that got to the end result e.g. var secondsInOneHour=3600;//60 min_60 sec OR just 60_60

5. var bigArray = ["1000 items"]; It only has one item, which is a string. I know you meant it as bigArray[0] would imply, but I'd try to find another way like not declaring it at all as the var name is sufficient.

Change comments relating to this.

It's an HTML5-approved way of adding data to a particular element.

More here:

http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#embedding-custom-non-visible-data-with-the-data-*-attributes

The problem with using overflow: hidden to clear floats is that in addition to clearing floats, it also hides overflow. So if you've got a heading that's supposed to hang just outside of your box, you've got a tough choice to make.

The New Clearfix method is a great way to clear floats in modern browsers, and falls back in IE the same way that the overflow trick does.

Hi,

Awesome guideline on frontend development!

I have a suggestion for the alt text attribute section, specifically for the 'bullet' example. Why would I not just add '-' as the alt text for bullet.gif, since that would be a fairly accurate semantic (and textual) representation of the bullet image? Otherwise it might be a good idea to just use the CSS property list-style-item.

Source: W3C

Best, Michael

In this example len is in the (default) global scope.

for (var i = 0, len = toLoop.length; i < len; i++) {
    // GOOD - the length is only looked up once and then cached
}

This is a safer example.

for (var i = 0, var len = toLoop.length; i < len; i++) {
    // GOOD - the length is only looked up once and then cached
}

"Strings should always use double quotes. Some people are very fond of their C style strings (single quotes), but this leads to conflicting styles within a script."

Maybe I've read this statement incorrectly, but:

C strings are double quoted not single quoted.

     char *s = "hello world";

C characters are single quoted.

     char c = 'c';

This is also the case with C++ (naturally), Java and C#. In fact Javascript is the only vaguely C'ish language which comes to mind that doesn't follow this convention.

Awesome checklist, thanks for this.