You are on page 1of 33

Content

 Introduction
 Objectives/Goals
 Getting Started
 General Standards
 Deliverables

 HTML
 Goals for Markup
 Getting Started on Markup
 HTML Markup Best Practices
 Markup Deliverables
 Next Steps & HTML5 Resources

 CSS
 Goals for Effective CSS
 Getting Started with CSS
 CSS Best Practices
 CSS Deliverables
 Next Steps & CSS Resources

 JavaScript
 Objectives/Goals
 Getting Started on JavaScript
 JavaScript Best Practices
 JavaScript Deliverables
 Next Steps & JavaScript Resources

 Responsive Web Design


 Objectives of Responsive Web Design
 Getting Started with Mobile Development
 Responsive Design Best Practices
 Next Steps & RWD Resources

 Appendix
 Advanced Topics
 Links for More Resources

Created By : Kiran Shinde, Catseye


Front-end Code Standards

Introduction
This document useful for the guidelines and best practices for the front-end web development team,
and how front-end technologies work; a basic familiarity is assumed.

A Front End Developer is the link between the graphic designer, responsible for creating the visual
design of a Web Application and the Backend Developer responsible for creating the computational logic
behind the application.

Objectives/Goals
Our objective in creating this document is:
1. Consistency and faster code across our Application/project.
2. Make easy/ease of maintenance.
3. Create Enterprises Web Application.
4. Guide to staff or help to new developers.

Getting Started
Need to understand how the development environment will work, what tools will be available, and what
the differences between development, test, and production environment. Teams should get a proper
understanding of the client's browser and device requirements are.

Foundation of Front-end Development


Whenever possible, the front-end technology solutions produced shall adhere to industry best practices
honoring as strict a separation of concerns as possible between:
 Hypertext Markup Language (HTML) for structure
 Cascading Style Sheets (CSS) for presentation UI
 Responsive Web Development
 JavaScript (JS) for behavior and interaction

General Standards
A key hallmark of professional code includes a notion that while we are writing code that must reach a
desired goal, we are also creating code that must be read and understood by others.

Created By : Kiran Shinde, Catseye


1. Using Framework

A framework is an entity between a ‘model’ and a ‘method’. A framework is, or contains, a


structure or system for the realization of a defined result/goal.

Frameworks give the users much more freedom regarding the (partial or entire) use of the
framework and the use of the models or techniques therein.

Now days so many framework in the market, and There is a lot of confusion regarding the
use framework. That will be depend on client requirement or Situation

Choose one framework (like jQuery frameworks Bootstrap, UI kit, Semantic-UI Foundation Etc.)
but most popular front-end framework is Bootstrap. If a client using own framework we need to
understand the Framework.

2. Code Consistency

Everyone has their own style because of the way they learned to code. If you learned using a
plain text editor, your style likely evolved from what you thought was more readable. The
quality of your code is not just in its execution but also in its appearance. It should be formatted
and properly aligned with comments. Code that must be read and understood by others.

3. Indentation

Please consistently indent, include braces, quotes, and new lines so that code is clear and can be
read easily. New code that is added should never deviate from existing formatting conventions
or change the indent levels. Always follow code pattern.

4. Readability and Typography


Web typography best practices keep things readable and are an important aspect of the success
of the web.
1. Letter spacing
Need to understand just how crucial white spaces can be are just as important with typography
fonts.

2. Line Height
Need to understand about line height it is concerns the spacing between lines of text stacked
above another.

3. Font selection
Font selection is a very important, if stakeholder have own branding. Use same font or fallback
font family.

Created By : Kiran Shinde, Catseye


4. Font size
Need to remember when using font sizes, Heading, Subheading, Paragraph, and Links etc. that
will be consistence. Use bigger to small.

Third-Party Libraries API

Un-minified libraries and third-party scripts should be in local development environments for easier
debugging if available

 Third-party code and libraries should never be modified and their original source and the license must
be documented and be appropriate for a project.

Inclusion of any third-party code should be carefully considered and verified with the project team as
the appropriate solution to a given problem.

 Code Review /Deliverables

Quality deliverables are essential for professionals.

Please remove legacy files and unwanted code, be certain the work is delivered in a clean file, and in an
orderly, logical structure that serves a clear purpose.

Created By : Kiran Shinde, Catseye


HTML
HTML markup defines the content of a document and gives it a fundamental structure such as section
dividers, headers, paragraphs, lists, menus, and forms.

Goals for Markup


Please follow protocol established for a given project so all team members can have the same
expectations around document structure and markup.
A clear, clean, and concise HTML structure is also necessary for semantics, flexibility, and a reliable
deployment environment. Do not deviate from established templates or patterns without architect
approval.

Design Goals for HTML

1. Simplicity
2. Scalability
3. Platform
4. Content
5. Support CSS
6. Support UX (visual)

Getting Started on Markup

When creating the HTML for a website, environment or technical constraints may impact the type of
markup that can be used. Please discuss the final delivery environment in depth with technical leads and
clients.
Discuss types of:
 Templates and types of pages.
 Frameworks, CSS grid systems (custom or otherwise).
 Server-Side platforms.

Note that it is important to take care into account how the site will finally be maintained and who will be
doing that work.

Created By : Kiran Shinde, Catseye


HTML Markup Best Practices
When creating html need determines a particular path, consistency is matters most.
Guidelines are below:-
1. Semantics Markup
HTML document will make appropriate use of these semantic elements and leave all
responsibility for controlling the presentation of the document to the CSS style sheet.

2. Browser Support and Standard


All markups will be written using the latest HTML5 markup specifications from the W3C, as
implemented by browsers and devices that meet project requirements. When creating markup
make sure environments are support or not.
 
3. Using doctype
Always include a proper doctype.

Example :- <!doctype html>

4. Character encoding
Specify the character encoding for the HTML document

<meta charset="UTF-8">

5. Title declaration
Define title for your document

 <title>CyberTech Reference</title>

6. Meta declaration (viewport, keyword )


Metadata is data (information) about data.
Described Meta data in your document

 <head>
  <meta charset="UTF-8">
  <meta name="description" content="cybertech Systems and Software Limited
">
  <meta name="keywords" content="HTML,CSS,XML,JavaScript">
  <meta name="author" content="cybertech">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">

Created By : Kiran Shinde, Catseye


7. Tag closing opening and self closing
Some tags are self closing tag. Whenever using open and closing elements nested in the correct
ways to ensure maximum compatibility and clarity of document structure.

 Self closing example


 <meta charset="UTF-8">
 <link rel="stylesheet" type="text/css" href="1bc.css">
<input type="submit" value="Submit">
<img src=" " alt=" " height="" width="">

Open Closing Example

<div></div>
<p></p>
<ul>
<li></li>
<li></li>
</ul>

8. Indentation Html
Indent nested elements and tags with single indentation settings, whatever they may be, for
each level in the hierarchy of the document.

<div class="container">
<p class="paragraph"></p>
<ul class="listStyle">
<li>Loren</li>
<li> Loren </li>
</ul>
</div>

Created By : Kiran Shinde, Catseye


9. Html5 tag (header, footer, nav, section, article and aside etc. )
HTML5 introduces new elements and explains some of the advantages of the new markup
language.

This is a very basic and solid startup for all and any HTML5 projects you might do in the future.
With this, we can start assigning tags to the different sections of our layout.

<header role="banner">
<h1>HTML5 Document Structure Example</h1>
<p>This page should be tried in safari, chrome or Mozila.</p>
</header>
<section>
<div> main content here </div>
</section>
<footer>
<p>@cybertech.com </p>
</footer>

10. Attribute value


Use quotes to surround all attribute values in HTML, this maintains consistency between
attribute values that contain whitespace and those that don't.

<img src="logo.jpg" alt="cybertech.com" width="104" height="142">

11. Id and classes


HTML elements can be identified by using the id and class attributes.
An ID is a unique identifier for that particular element; no other element on the page should use
the same ID.
Classes are not unique. The same class can be used on multiple elements within a page, and a
single element can have more than one class, in a space delimited list.

<ul id="nav-tabs">
<li class="tabs">Home </li>
<li class=" tabs selected">About Us</li>
<li class=" tabs ">Contact</li>
</ul

Created By : Kiran Shinde, Catseye


12. Anchor and links
All links should point to absolute or relative URLs with user-readable content. Take care links are
not broken. Also allows the user to open the links in a new tab or window (like pdfs, micro
website, or any other references URLs )

13. Form / Table


Tables: - Tables should not be used for page layout; only use them when you need to display
tabular data.
Use the <thead> and <tbody> elements to inform which row contains column headers so when a
user prints the website and the table runs onto another page, browsers can display
the <thead> on each page for easier readability.

Form: - Using both semantic and functional reasons, we make full use of the <form> tag for all
sections requiring user input. This will require that the back-end be able to return a full HTML
<table>
page for form submission (e.g. registering a new user, editing the quantity in a shopping cart).
<caption>First
Do not nest the HTML formtwo U.S. presidents</caption>
element tag.
<thead>
<tr>
<th scope="col">Name</th>
<th scope="col">Took office</th>
<th scope="col">Party</th>
</tr>
</thead>
<tbody>
<tr>
<td>George Washington</td>
<td>April 30, 1789</td>
<td>n/a</td>
</tr>
<tr>
<td>John Adams</td>
<td>March 4, 1797</td>
<td>Federalist</td>
</tr>
</tbody>
</table>

Created By : Kiran Shinde, Catseye


Markup Deliverables
Typically HTML deliverables are incorporated into Content Management Systems or application delivery
platforms as templates. A plan for incorporation of templates that leverage patterns created during the
markup creation phase should be followed and matching types of pages to templates that were created,
so that an association between the source markup and the destination markup can be maintained over
time.

Next Steps & HTML5 Resources

Considerations:
1. Site maintenance procedures
2. Browser testing strategies
3. How new features will be added
4. Where new features will be added
5. What the file system looks like for static site assets
6. If a CDN is involved
7. Naming conventions and organization of graphics and photography assets
8. If the "back-end implementation" of static HTML templates will require review by front-end
team members

Created By : Kiran Shinde, Catseye


CSS (Cascading Style Sheet)
Introduction

Cascading Style Sheets (CSS) is help to visual presentation and design rules for a web application. 

Cascading Style Sheets (CSS) is used to define styles for your web pages, including the design, layout and
variations in display for different devices and screen sizes.

Objectives/Goals

CSS is an unusual language which can easily lead to code bloat, inconsistencies in design or clashing code
techniques. It is easy to end up with CSS code that is so fragile it can cause site-wide regressions with
small changes.

 CSS should be easy to maintain and modify.


 Should be follow clear enough patterns and consistency to understand.
 Offer a clear place for new styles going forwards.
 Not be a drag on page loading performance.
 Do not include unused style rules.
 Address different devices, browser versions, and do as much as it can with as synchronized
code as possible.

When setting up the CSS for a site, always consider:

 What the default styles for HTML elements are going to be. <def iaultii>
 Which styles are global or general CSS styles? <detailsiii>
 Difference between code for layout and for content.
(Layouts is structure of elements // content to wrap around a given element )

 How the code will evolve and grow.


(Approach mobile or browser, module based, versions etc.)
 Use of images as CSS background images vs. in-line HTML (content).

Getting Started with CSS

Created By : Kiran Shinde, Catseye


Planning for a CSS build isn't that different than any other software requirements for Web development.
Before coding you should follow below points.

 Review the design.


 Plan around technical constraints.
 Identify how content will be managed.
 Be certain who will be able to modify the design directly via code.

CSS Best Practices


What follows are some basic concepts for standardization of CSS code. You are feel free to edit and
update.

1. Inclusion
How to include style sheet in your document
a. Use the <link> tag to include all your style sheets in the <head> of the document.
Example

<link rel =”stylesheet” type= “test/css” href=”css/style.css”/>


b. The @import rule is another way of loading a CSS file. You can use it in two ways.
First Example within the head of your document

<style>@import url(“css/style.css”)</style>
Second Example within the css file

@import url(“css/layout.css”);

2. Formatting CSS
a. Use new line for every selector and every declaration.
b. Use single space using before opening brace set.

Created By : Kiran Shinde, Catseye


c. Use lowercase for properties & value.
d. Use camel case and Hyphenate class selector names;
e. If needed Shorthand Hex value like #fff;
f. Using opacity use rgba (0, 0, 0, 0.5) color set.
g. Add a single space between the property and value (width: 20px;)
h. Always include a semi-colon at the end of the last declaration.
i. Use shorthand if you can like (padding: 10px 0;)
j. Close brace set same column.
k. Close brace set start new selector give one line space.
Example

.box {
width: 130px;
height: 40px;
float: right;
padding: 10px 0;
color: #000;
}

3. Specificity
The concept Specificity is the means by which browsers decide which CSS property values are the most
relevant to an element and, therefore, will be applied.

<div id="test">
<span>Text</span>
</div>
div#test span { color: green }
div span { color: blue }
span { color: red }

https://jsfiddle.net/liteshbopche/0a2t85v7/

https://css-tricks.com/specifics-on-css-specificity/

4. Do Not Use! Important


Avoid using the!important keyword. Treat it like the nuclear option, only to be used in the most
extreme of cases. This fundamentally destroys the specificity feature and can even break
accessibility for some users.

If you can use! Important you will use parent or component based.

5. Selectorsiv
“Class selectors” let you apply CSS styles to a specific HTML element. Class selectors require two
things:
A class attribute on the HTML element in question.

Created By : Kiran Shinde, Catseye


A matching CSS class selector in your stylesheet.

6. Inline Styling
Do not hard codes style information into your HTML markup directly.

7. Vendor Prefixes

CSS vendor prefixes, also sometime known as or CSS browser prefixes, are a way for browser makers to
add support for new CSS features before those features are fully supported in all browsers. 

Example

-webkit-transition: all 4s ease;


-moz-transition: all 4s ease;
-ms-transition: all 4s ease;
-o-transition: all 4s ease;
transition: all 4s ease;

8. Performance Caveats)
Is the latest Flexbox implementation slower than CSS table layout? Yes, it is. But not enough to concern
yourself about. If you need to use Flexbox, use it. For all but the most extreme situations, any speed
difference against other layout methods is largely inconsequential.

9. Box Model
When you set with height properties of an element through CSS , just set width and height of the
content area . To consider full size of an element, you must add padding, margin, and borders.

Example

.box{ Here is calculation:


    width: 320px; Width 320px
    padding: 10px; Padding (left + right) 20px
    border: 5px solid gray; Border(left + right) 10px 360px
    margin: 5px;  Margin(left + right) 10px
}

Created By : Kiran Shinde, Catseye


10. Components
Components are a high level concept for organizing CSS files and rules. A component simply means a
grouped set of rules pertaining to an object or set of related objects on a page.

Additionally, encapsulating these components into distinct files is a great option. Within this file, using a
naming convention is a tremendous help here for code maintainability and readability.

Group styles under a simple name-space using type pattern such as:

* core component */
.container { ... }

/* component elements */
.header { ... }
11..content
The Mobile
{ ... Web,
} Media Queries, Responsive Design
.footer { ... }
With the mobile Web taking off Media Queries are mandatory in CSS going forwards.

We discuss media queries in the Mobile / Responsive section of this document.

CSS Deliverables
Please be aware of potential conflicts between the original development environment for CSS and an
ultimate deployment to production systems, if continuous integration will allow the continued use of
CSS preprocessors, or if there should a cross-platform development strategy.

Delivered CSS should be concatenated, minified, tested against browser bugs (e.g. MSIE selector count
bugs) and extra files should be removed.

File naming conventions should be consistent and language or use-case specific files should be clear and
not be easily confused with the global style CSS.

Next Steps & CSS Resources


This is just the tip of the iceberg where CSS is concerned.

 Browser Compatibility
 Media Queries
 Accessibility and CSS

Created By : Kiran Shinde, Catseye


 CSS pre-processors usage
 Internet Explorer, or browser-specific bugs
 Usage of CSS3 transitions, transforms, and more
 Vendor prefixes
 Color Management

JavaScript

JavaScript is the programming language of HTML and the Web. 

JavaScript is where extra behaviors, features, and functionality not offered natively by Web browsers
through CSS and HTML is created.

JavaScript has gained a huge amount of attention in recent years due to more feature rich, faster
browsers and server run-times such as Node.js. For the purposes, general discussion here focuses on
client-side JavaScript development, with references to where it crosses over.

It is of note that many techniques identified these days as "HTML5" are actually enabled by the related
JavaScript API

Objectives/Goals
Understand how JavaScript to makes is possible interact with web pages, minimize client/server
traffic, order of code execution, debugging testing and reason of include JavaScript.

Included JavaScript should:

 Be included after careful consideration.


 Have the performance overhead and file size evaluated.
 Have a feature set that is understood and appropriate.
 Perform only the necessary tasks without needless overhead.
 Have maintainability carefully assessed.

What we have to do

 Fast, efficient, and perform well.


 Re-usable if possible.
 Not conflict with other code on a given page or sets of pages.
 Executed only when necessary on a given page or sets of pages.

Created By : Kiran Shinde, Catseye


Likewise, the absence or failure of the code should be carefully considered:

 What happens if for some reason this code is missing or does not run?
 What happens if the code triggers an error?

Getting Started on JavaScript

We'll be doing all our work inside of an index.html file. All our JS will insert in index.html.

Often developer will solve a problem step by step and do not consider whole picture. "Add another
plug-in” is not always a good solution.

Take care all of the code being added can be useful elsewhere. Code should be cartelized because it can
be easily updated & reusable anywhere in the application.

For JavaScript, a Front-end developer should be thinking about:

 If there is code already return reuse.


 Code formatting rules, naming conventions, file locations, etc.
 Testing the code on various browsers and devices.
 When use API check licensed version or MIT.
 About framework
 Possible things to centralize as below point

a) Code that modifies the DOM


b) Ajax, validation, or other libraries
c) Query string parsing utilities, router-type code
d) Tests for global conditions (e.g. window size, feature support, etc.)
e) Page, window, or document level events (e.g. Ajax, resize, etc.)
f) UI controls (e.g. spinners, modals, tabs, etc.)
g) Date handling utilities
h) Files with strings of text in a given language

Created By : Kiran Shinde, Catseye


Finally, settings and configuration options (e.g. paths to services, debug flags, duration settings,
minimum or maximum values, etc.) are common things to set in a centralized, distinct place

JavaScript Best Practices

1. Inclusion

 Use external JavaScript files. Do NOT include JavaScript in-line in the page unless there is a
good reason.
 Use the <script> tag to include your JavaScript files at the bottom of your HTML document just
before the closing </body> tag. For optimal page performance, concatenate your JavaScript into
as few files as possible.

<script src=”script.js”></script>

 This should link to concatenated and minified, finalized JavaScript files.


 Enable source compare to assist with debugging and testing.
 Loading files on demand (On some sites it may be appropriate to load a single JavaScript
file with all dependencies bundled together, or it may be more appropriate (such as in a very
large SPA) to load files on demand, as they are needed, asynchronously.)

2. Writing and Formatting

Formatting the language statements and patterns should follow these basics:

 Open braces are preceded by a single space.


 Open braces should appear on the same line as their preceding argument.
 Close braces should appear at the same indentation as the statement preceding the
opening brace
 There should be no space characters between parentheses and their contents.
 Use semicolons and do not rely on automatic semicolon insertion.
 Each comma and colon (and semi-colons that don't end a line) should be followed by a
single space.

Created By : Kiran Shinde, Catseye


 Binary and ternary operators should have a single space on each side.
 Quoted values should be in 'single quotes' so that double quotes may easily exist inside
them.
 Comment JavaScript code thoroughly and consider using a pattern such as those
described by JSDocs so that documentation may be generated automatically.
 Conditional statements go on a new line followed by the opening brace.
 Else/else go on the same line as the brace.
 Use type strict checks with === as opposed to == whenever possible.

for (var i = 0, len = arr.length; i < len; i++) {


var example = 1;
if (example === i) {
// we are looping
} else {
// this will never happen
}
}

3. Variable Declaration

 Minimize the use of global or window level variables and name-spaces. Pollution of the


global name-space is error prone and a bad practice.
 If referencing a window or global level variable that isn't obvious, please comment as such
or explicitly state it.

Variable Names and Types


Always use meaningful variable names that can be read as words, not as silly abbreviations only
you understand.

 Variable names should be camelCase.


 Objects, classes, and name-spaces should be TitleCase.
 Boolean values should be prefixed with is if at all possible.
 Cached jQuery objects can be prefixed with $.
 Use shorthand versions of empty Arrays and Objects.

5. Basic JavaScript Architecture

Created By : Kiran Shinde, Catseye


Today it is common for the JavaScript code on a site to be a vast collection of "Modules"
brought together by build scripts, dependency tools, or even manually by the developer
(not really recommended).

Smaller sites can get away with more simple structures, but for longer term, JavaScript-
heavy code bases the following rule is critical:

 For a complex site, never use a single JavaScript file for development, unless it is tiny and
serves a very targeted purpose.

This is so that the code is maintainable and scalable. Smaller files are easier to debug,
swap in and out, and blocks of code should serve as small a purpose as possible (single
responsibility principle).

In most simple terms, most sites benefit from a basic structure similar to:

 Global site-wide JavaScript


 Specific modules for specific sections of the site
 Specific modules used for specific purposes / features
 Available vendor libraries

JavaScript Deliverables

The most obvious fact is you will need to provide working files that are error-free and will work
in a variety of scenarios. We can't assume that clients will always leave scripts and pages as we
leave them, though we can provide direction as to how scripts should be used.

Understanding the Code's Place in the Project


 Understand where your code will live vs. any code introduced in a destination environment
 Understand if the code will need to coexist with other code.

Clean, Clear, Organized, Readable Code


 As bug free as possible.
 Always remember we write code for other developers, not for a runtime or a browser.
 Remove code that is no longer used. Remove excess "noise" or distractions from source code
such as large commented out blocks of unused code. Source control can solve problems like this.

Created By : Kiran Shinde, Catseye


 Have console and debugging statements be removed or a plan in place for suppression during
the build or deployment.

Next Steps & JavaScript Resources

There is an enormous volume of JavaScript reference material out in the wild today. We hope to add
more at some point but here are various topics worth following up on:

 Debugging JavaScript
 Learning more about ES6
 JavaScript Design Patterns
 Unit Testing JavaScript code
 Node.js
 Compare JS Frameworks, Frameworks, and more Frameworks
 Baseline For Front End Developers
 JavaScript Style Guides and Beautifiers
 Douglas Crockford's JS Code Conventions
 Maintainable JavaScript Book
 Maintainable JavaScript Presentation
 Large Scale JavaScript Applications

Responsive Web Design

Responsive Web Design (RWD) is the term used for the practice of creating page layouts and
user experiences that work on a variety of devices and screen sizes.
With the ever expanding mobile landscape and the evolution of the Internet of Things (IoT), the
idea of a "standard" screen size has fallen by the wayside in favor of the rise of a device-
agnostic approach. It is less and less common to launch two versions of a site, one for desktop
and one for mobile.
To this end a series of techniques have been put together for pages to adjust based off
browsers' current specs (e.g. width, height, pixel density, orientation, etc).
The techniques are referred to as Responsive Web Design (RWD) and it is another technique in
the toolbox of progressive enhancement and adaptive web design.

Goals of Responsive Web Design


The goals of RWD are:
 Offer an optimized user experience (UX),

Created By : Kiran Shinde, Catseye


 Regardless of the user's screen size or features supported on their device.

Despite this lofty ideal, on Web projects the term "responsive web design" has generally been
used in reference to an optimized experience for a set of target devices, usually:
 A particular set of cell (smart) phones,
 various tablets,
 or desktop computer monitors (depending upon the target audience).

Getting Started with Mobile Development


As the name of RWD implies, it all starts with a flexible design that features components having
mutable characteristics based on the available screen canvas and varied types of user
interactions. Careful consideration needs to be taken when innovating to derive a design that
can respond to various screens.
For a given project, always consider:
 The extent of the use cases for each feature on the site.
 The target audience and likelihood they may be using an alternative device to conduct certain
activities on the site.
 If all target devices will support all the technologies required.
 That the UX will not be 100% the same across all devices, browsers and screens — nor should it
be!
 What happens to the design when the screen gets smaller and larger than the static canvas size
it is being designed on.
 For placement of content and decorative elements, are there patterns or rules that can describe
where it falls and adjust with screen sizes?
 Will some components be better suited as vector graphics (SVG or fonts) instead of raster files
to allow for distortion free scaling?
 Will assets need to be produced in different formats for different devices (e.g. Flash video vs.
HTML5 video, lower resolution artwork vs. high resolution artwork, smaller file sizes vs. larger
sizes).
 If a device offers a superior UX for some types of interaction (e.g. native date-pickers vs.
traditional browser controls, or swiping instead of clicking on dots).
 What happens when a feature is not supported by a device, or if a feature were to fail in a given
device?
 What if a device went off-line during usage of a feature?
 The best ways to detect support for various features (e.g. Modernizr, etc.).

Created By : Kiran Shinde, Catseye


Responsive Design Best Practices
RWD is frequently said to be achieved through the use of:
1. Percentage-based grids,
2. flexible images that scale,
3.  CSS media queries.

Some core guidelines:


 Always design and develop the mobile UX first (thus start with small defaults and scale
upwards; please see Mobile First)
 Set the baseline Media Queries as a team for various types of devices, and try to stick
to them as much as possible.
 Add additional Media Queries — as necessary — for less than ideal experiences at the
sizes in between, as appropriate for different types of content and components.
 Be careful of images. Do not render a 5GB image at 100px by 100px. This does not
change the bandwidth needed to download the file! Similarly if you are hiding an image
with display: none, visibility: hidden or similar, the image may still be downloaded.
 Test on real hardware. Actual testing on actual devices cannot be substituted with
resizing a browser window, or even an "emulation" mode offered by a desktop browser.
 A mobile browser is not a small desktop browser. Mobile versions of desktop browsers
are frequently woefully different (or a totally different product) than their desktop
counterparts, so do not assume that just because it works on Chrome desktop that it will
work on an Android device.

Next Steps & RWD Resources◊


Big collections:
 Responsive Design Resources
 (more) Responsive Design Resources
 Responsive Design Guidelines and Tutorials
Articles:
 Responsive Web Design
 Responsive Design Patterns
 What We Mean When We Say Responsive
 Essential Considerations for Crafting Quality Media Queries
Blogs:

Created By : Kiran Shinde, Catseye


 This Is Responsive
 Responsive Web Design

JS LINT
CSS Beautifier
HTML Format

(There are design/development techniques that allow you to reposition content based on screen size. So
if you do want elements visible on a screen regardless of its size, you can. This is “fold independent”
layout.
Today’s device ecosystem renders any concrete “fold line” moot. There’s just too much variety in screen
sizes. Therefore designing in an adaptive/responsive manner (using the techniques mentioned before) is
required.
)

Created By : Kiran Shinde, Catseye


https://www.youtube.com/watch?v=qlEJV_xUu6k

Smartphone Screen size Screen resolution

iPhone 7 4.7-in 750 x 1334

Samsung Galaxy S7 5.1-in 1440 x 2560

Sony Xperia X 5.0-in 1080 x 1920

HTC 10 5.2-in 1440 x 2560

Asus Zenfone 3 Deluxe 5.7-in 1080 x 1920

Huawei Nexus 6P 5.7-in 1440 x 2560

Huawei P9 5.2-in 1080 x 1920

Motorola Moto Z 5.5-in 1440 x 2560

LG G5 5.3-in 1440 x 2560

LG V20 5.7-in 1440 x 2560

Created By : Kiran Shinde, Catseye


Smartphone Screen size Screen resolution

Xiaomi Mi 5 5.15-in 1080 x 1920

OnePlus 3 5.5-in 1080 x 1920

http://screensiz.es/monitor

iPhone
Model DP PPI Ratio Viewport
iPhone 2g, 3g 320 x 480 163 PPI (@1x) 3:2 320 x 480
iPhone 4 320 x 480 326 PPI (@2x) 3:2 640 x 960
iPhone 5 320 x 568 326 PPI (@2x) 16:9 640 x 1136
iPhone 6 375 x 667 326 PPI (@2x) 16:9 750 x 1334
iPhone 6+ 414 x 736 401 PPI (@3x) 16:9 1080 x 1920

iPad
Model DP PPI Ratio Viewport
iPad + Mini 768 x 1024 132 PPI (@1x) 4:3 768 x 1024
iPad (Retina) 768 x 1024 264 PPI (@2x) 4:3 1536 x 2048

Android
Android screen density distribution is of course a bit more varied. The following table
details the various Android models which hold relatively large market share along
with their screen resolutions.

Top selling Android phones


Model DP Density PPI Ratio Viewport
Galaxy SIII 360 x 640 200% (XHDPI) 306 PPI 16:9 720 x 1280
Galaxy SII 320 x 533 150% (HDPI) 217 PPI 5:3 480 x 800
Google Nexus 4 384 x 640 200% (XHDPI) 318 PPI 5:3 768 x 1280

Created By : Kiran Shinde, Catseye


Galaxy Nexus 360 x 640 200% (XHDPI) 316 PPI 16:9 720 x 1280
Galaxy SIV 360 x 640 300% (XXHDPI) 441 PPI 16:9 1080 x 1920
Galaxy Note II 360 x 640 200% (XHDPI) 267 PPI 16:9 720 x 1280
Galaxy S Plus 320 x 533 150% (HDPI) 233 PPI 5:3 480 x 800
Galaxy S 320 x 533 150% (HDPI) 233 PPI 5:3 480 x 800
Galaxy Note 400 x 640 200% (XHDPI) 285 PPI 8:5 800 x 1280
HTC One 360 x 640 300% (XXHDPI) 469 PPI 16:9 1080 x 1920
Droid Razr 480 x 853 150% (HDPI) 312 PPI 16:9 720 x 1280
Droid 3 & 4 640 x 360 150% (HDPI) 274 PPI 16:9 960 x 540
Droid Raz Maxx 640 x 360 150% (HDPI) 256 ppi 16:9 540 x 960
HTC Desire 240 x 400 200% (HDPI) 252 ppi 5:3 480 x 800

Tools & resources


Helpful tools for writing and debugging your JavaScript code.
Firefox Developer Tools

Scratchpad, Web Console, JavaScript Profiler, Debugger, and more.

JavaScript Shells

A JavaScript shell allows you to quickly test snippets of JavaScript code.

TogetherJS
Collaboration made easy. By adding TogetherJS to your site, your users can help each other out on a
website in real time!

Stack Overflow
Stack Overflow questions tagged with "JavaScript".

JavaScript versions and release notes


Browse JavaScript's feature history and implementation status.

JSFiddle
Edit JavaScript, CSS, HTML and get live results. Use external resources and collaborate with your
team online.

Default css

Created By : Kiran Shinde, Catseye


i
{ html, address,
blockquote,
body, dd, div,
dl, dt, fieldset, form,
frame, frameset,
h1, h2, h3, h4,
h5, h6, noframes,
ol, p, ul, center,
dir, hr, menu, pre { display: block; unicode-bidi: embed }
li { display: list-item }
head { display: none }
table { display: table }
tr { display: table-row }
thead { display: table-header-group }
tbody { display: table-row-group }
tfoot { display: table-footer-group }
col { display: table-column }
colgroup { display: table-column-group }
td, th { display: table-cell }
caption { display: table-caption }
th { font-weight: bolder; text-align: center }
caption { text-align: center }
body { margin: 8px }
h1 { font-size: 2em; margin: .67em 0 }
h2 { font-size: 1.5em; margin: .75em 0 }
h3 { font-size: 1.17em; margin: .83em 0 }
h4, p,
blockquote, ul,
fieldset, form,
ol, dl, dir,
menu { margin: 1.12em 0 }
h5 { font-size: .83em; margin: 1.5em 0 }
h6 { font-size: .75em; margin: 1.67em 0 }
h1, h2, h3, h4,
h5, h6, b,
strong { font-weight: bolder }
blockquote { margin-left: 40px; margin-right: 40px }
i, cite, em,
var, address { font-style: italic }
pre, tt, code,
kbd, samp { font-family: monospace }
pre { white-space: pre }
button, textarea,
input, select { display: inline-block }
big { font-size: 1.17em }
small, sub, sup { font-size: .83em }
sub { vertical-align: sub }
sup { vertical-align: super }
table { border-spacing: 2px; }
thead, tbody,
tfoot { vertical-align: middle }
td, th, tr { vertical-align: inherit }
s, strike, del { text-decoration: line-through }
hr { border: 1px inset }
ol, ul, dir,
menu, dd { margin-left: 40px }
ol { list-style-type: decimal }
ol ul, ul ol,
ul ul, ol ol { margin-top: 0; margin-bottom: 0 }
u, ins { text-decoration: underline }
br:before { content: "\A"; white-space: pre-line }
center { text-align: center }
:link, :visited { text-decoration: underline }
:focus { outline: thin dotted invert }

/* Begin bidirectionality settings (do not change) */


BDO[DIR="ltr"] { direction: ltr; unicode-bidi: bidi-override }
BDO[DIR="rtl"] { direction: rtl; unicode-bidi: bidi-override }

*[DIR="ltr"] { direction: ltr; unicode-bidi: embed }


*[DIR="rtl"] { direction: rtl; unicode-bidi: embed }

@media print {
h1 { page-break-before: always }
h1, h2, h3,
h4, h5, h6 { page-break-after: avoid }
ul, ol, dl { page-break-before: avoid }
}
}
ii
Global CSS
_________________________
iii
We can use general document styling to apply CSS styles to our entire web page, and it will filter
down to all elements within the page unless it is overridden within an individual element. A great
example of this is when we want to apply the same font to every element in our web page.

Rather than having to set the font for each individual element - our headings, paragraphs, tables
and so on - we can just set the font once for the entire document, and all of these elements will
adopt it unless we tell them to do otherwise.

To set a general CSS style we need to apply that style to the page's <body> tag. Since our body tag
contains all visible elements of our web page, any styles we apply to it will apply to everything
within the visible page.
Taking the font example discussed above, we could set the font for the entire web page to be
Arial and sized 1em by using the following style declaration:

body {
font-family: arial;
font-size: 1em;
}

This setting would then filter down into all of our page elements. This is a very useful feature of
CSS because it allows us to keep the amount of repetition in our stylesheets down to a minimum,
which helps readability when we come to edit the styles, and also keeps the stylesheet's file size
down.

We can easily over-ride this default setting for individual elements. For example we might decide
to make our <h1> heading tag appear larger, so we could use the above CSS in combination with
the following code:

h1 {
font-size: 1.3em;
}

Our <h1> tags would still inherit the Arial font we defined within the tag, but the default size of
1em would be over-ridden, and our headings would appear in 1.3em instead .
Extra example {font-color, Bgcolor , header , footer etc.}

Selectors
iv
Basic Selectors
 Type selectors elementname
 Class selectors .classname
 ID selectors #idname
 Universal selectors * ns|* *|*
 Attribute selectors [attr=value]

 Combinators (more info)
 Adjacent sibling selectors A + B
 General sibling selectors A ~ B
 Child selectors A > B
 Descendant selectors A B

 Pseudo-elements (more info)
 ::after
 ::before
 ::first-letter
 ::first-line
 ::selection
 ::backdrop
 ::placeholder 
 ::marker 
 ::spelling-error 
 ::grammar-error 

 Standard pseudo-classes (more info)
 :active
 :any
 :checked
 :default
 :dir()
 :disabled
 :empty
 :enabled
 :first
 :first-child
 :first-of-type
 :fullscreen
 :focus
 :hover
 :indeterminate
 :in-range
 :invalid
 :lang()
 :last-child
 :last-of-type
 :left
 :link
 :not()
 :nth-child()
 :nth-last-child()
 :nth-last-of-type()
 :nth-of-type()
 :only-child
 :only-of-type
 :optional
 :out-of-range
 :read-only
 :read-write
 :required
 :right
 :root
 :scope
 :target
 :valid
 :visited

CSS Caveats (new edition)


Reasons for not relying on style sheets to convey information or essential emphasis:

1. Not all user agents support CSS.


Special-purpose browsers like speech-based or text-only browsers typically ignore CSS. Indexing
robots do that, too, so search engines “see” your page without style sheets. In particular, they process
the textual content as in the HTML document, ignoring all of CSS.

2. CSS support varies.


There is great variation in the coverage of CSS support in browsers, and no all-encompassing
documentation of the support. Although support has generally become better in new versions,
especially IE 8, there are still problems lurking around. Moreover, older versions of IE, with many CSS
bugs and limitations, are still in widespread use.

3. CSS support can be disabled.


Users may switch CSS support off because they have special needs (e.g., need very large font size) or
because too many sites use CSS to create confusing appearance, or for other reasons. (On IE, there is
no simple way way to turn off CSS as a whole, but the accessibility settings let the user tell the browser
to ignore colors, font size, and font family settings on web pages.)

4. CSS rules can be ignored or overridden.


Browsers may ignore some (or all) of your CSS rules because specifications allow them to be ignored
or because the browser has a user-settable option that overrides the effect of a rule. For example, a
browser that normally displays background images may omit them when instructed to do so. Some
browsers have a user-settable minimum font size.

5. Browsers have bugs.


There is a wide range of different bugs in CSS support, most of which manifest themselves in
particular situations only—e.g., for some values (especially exceptional values) for a property, or for
specific combinations of values. No exhaustive documentation exists even for a single browser, though
you can find many useful lists of known bugs.

6. Quirks Mode means quirks.


Widely used browsers have “Quirks Mode,” which means that they deliberately simulate many errors
and oddities in older browsers. In particular, this means interpreting CSS code against the
specification, e.g. wrong box model (widths and heights often calculated by wrong rules).

7. The cascade surprises you.


The C in CSS stands for cascade, the most misunderstood of all CSS concepts, next to the inheritance
concept. It means, in particular, that a browser style sheet or a user style sheet may override your
style sheet, with strange effects if any of the style sheets is poorly designed.

8. CSS specs are a moving target.


Although CSS 2.1 is stable and official (W3C Recommendation), authors want to use CSS3 features, too.
CSS3 is just a collection of documents of very varying maturity, mostly just drafts. This means that
they may change at any moment. Browser support varies greatly, too.

9. Form fields form into problems


Browsers, especially older browsers, often use built-in routines for rendering form fields like input
boxes and buttons. This means that they are largely immune to CSS. You might also destroy some of
the nice default rendering features (such as rounded corners) in new browsers, if you style form fields
too eagerly. More info: Affecting the presentation of form fields on Web pages.

10. A style sheet may get lost.


An external style sheet associated with a document may get lost, e.g. due to server overload (so that an
HTML file gets loaded but a CSS file does not) or due to storage issues (e.g., a server that stores old
copies of pages might store an HTML file but not an associated CSS file).

11. Styling may get lost in transfer.


If the user e.g. copies part or all of a web page and pastes it to Word or Excel, mostly just the content is
transferred. Some markup may affect the result (e.g., an HTML table becomes a Word table), but style
sheets are ignored.

Front-end tech:
1. HTML / HTML5: Semantic web
2. CSS / CSS3: LESS, SASS, Media Queries
3. JavaScript: jQuery, AngularJS, Knockout, etc.
4. Compatibility quirks across browsers
5. Responsive design
6. AJAX, JSON, XML, WebSocket
Traning Docs
https://mindmajix.com/ui-developer-training

camtasia video creator

Scroll bar bootsrap creater

<Div class="scrollbar-rail">
https://gromo.github.io/jquery.scrollbar/demo/basic.html

You might also like