Online Resource

Online Resource

Online Resource

Online Resource

Online Resource

Online Resource

Online Resource

Online Resource

Hayden Library - TP248.2.B46 2019

Online Resource

Online Resource

Online Resource

Online Resource

Online Resource

Dewey Library - TP559.M53 M34 2019

Hayden Library - TP447.M4 W87 2019

Online Resource

Barker Library - TP248.2.E83 2019

Yarbrough, Mark M., author

Boer, Roland, 1961-

Root, Andrew, 1974-

Archer, Kenneth J., author

Cobb, Christy, author

Gurses Tarbuck, Derya, author

How to create a custom Tweet Button for WordPress using the bit.ly and Twitter APIs. The HTML and CSS is completely customisable and there is no need for JavaScript. PHP is used to automatically shorten and cache the URL of a post, fetch and cache the number of retweets, and populate the query string parameters in the link to Twitter.

The custom Tweet Button at the bottom of this post was created using this method. All the files are available on Github and released under MIT license. The PHP code was heavily influenced by the BackType Tweetcount plugin.

How to use

You’ll need your own bit.ly account and to be comfortable editing your theme’s functions.php, style.css, and template files. Be sure to make backups before you start making changes.

Step 1: Download the Custom Tweet Button for WordPress files from Github.

Step 2: Include the custom-tweet-button.php file in your theme’s functions.php file.

Step 3: Replace the bit.ly username, bit.ly API key, and Twitter username placeholders in the tweet_button function with your own. Your bit.ly credentials can be found on the “settings” page of your account.

Step 4: Add the custom Tweet Button CSS to your theme’s style.css file. Add the tweet.png image in your theme’s image folder. Make sure the image is correctly referenced in the CSS file.

Step 5: Call the function tweet_button in your template files (e.g. single.php) at the position(s) in the HTML you’d like the Tweet Button to appear:

if (function_exists('tweet_button')) {
   tweet_button(get_permalink());
}

Why make your own Tweet Button?

Making your own custom Tweet Button for WordPress has several additional advantages over using Twitter’s own offerings.

• Full control over the HTML and CSS.
  Having full control over the HTML and CSS means that you can choose how to present your Tweet Button. I decided to reproduce the horizontal and vertical styles of Twitter’s own button. But any appearance is possible.

• All click, traffic, and referrer data is stored in your bit.ly account.
  The URL for any published post is automatically shortened using the bit.ly service. The short URL is then passed to Twitter to ensure you can monitor the click and traffic data in your bit.ly account. The permalink is passed to Twitter in the counturl query string parameter to ensure that it counts the URL that your short URL resolves to.

• No need for JavaScript or embedded iframes.
  The Tweet Button works without JavaScript. You have full control over any custom JavaScript enhancements you may wish to include. If you’d prefer Twitter’s share page to open in a pop-up window you can write your own JavaScript handler.

• Faster page load.
  No external JavaScript or image files are loaded; both the short URL and retweet counts are cached.

• Use the short URL and retweet count for other purposes.
  The short URLs and retweet counts are stored as post meta-data. This makes it easy to display this data anywhere else in a post. The retweet count data could be used for conditional template logic. For example, you could order posts based on the number of retweets, apply custom styles to your most retweeted posts, or display your most tweeted posts in a widget.

• Easy to add Google Analytics campaign and event tracking.
  The Tweet Button is simple HTML and you have control over all the information that is sent to Twitter. Therefore, it is possible to use Google Analytics to help answer questions like: are people sharing your posts from the homepage or the post itself? If the Tweet Button is displayed above and below your posts, which gets the most clicks? How long do people take to click the Tweet Button? How many people are visiting my site thanks to links posted on Twitter using the Tweet Button?

• Approximate the number of retweets for old posts.
  Before the release of the official Tweet Button, Twitter did not collect data on the number of times a URL was tweeted. This means your older posts may display far fewer retweets than actually occurred. However, there is a workaround. Use a service like Topsy, Backtype, or Tweetmeme to get the number of times your old post was retweeted. The difference between this and the number from Twitter’s APIs is the approximate number of retweets Twitter missed. To correct the retweet count for old posts add the number of missed retweets to a Custom Field called retweet_count_start.

How the custom Tweet Button works

Once a post is published its permalink URL is shortened using the bit.ly API.

The returned URL is permanently cached in the bitly_short_url Custom Field. The short URL is now part of the post’s general meta-data and can be used in contexts other than the Tweet Button.

The Twitter API is used to get the number of retweets for the post’s permalink URL. This number, along with the time at which it was requested, is cached in the retweet_cache Custom Field. When the cache interval has passed, an API call is made and the returned number of retweets is checked against the value stored in retweet_cache. If the returned number is greater, the value of retweet_cache is updated.

The content of the tweet is automatically created by setting several properties for the http://twitter.com/share URL. The post title makes up the message; the short URL is passed to Twitter as the URL to be displayed in the tweet; the permalink URL is passed to Twitter as the URL to be counted; and your username is declared.

$twitter_params =
'?text=' . urlencode($title) .
'&url=' . urlencode($short_url) .
'&counturl=' .urlencode($url).
'&via=' . $twitter_via;

The default HTML output is very simple and can be fully customised. To display the count number vertically, add the class vcount.

<div class="twitter-share vcount>
   <a class="twitter-button"
      rel="external nofollow"
      title="Share this on Twitter"
      href="http://twitter.com/share?query-string-params"
      target="_blank">Tweet</a>
   <a class="twitter-count" href="http://twitter.com/search?q=url>259</a>
</div>

Further enhancements

Please apply any improvements or enhancements for the script against the source repository.

Drop-shadows are easy enough to create using pseudo-elements. It’s a nice and robust way to progressively enhance a design. This post is a summary of the technique and some of the possible appearances.

Demo: CSS drop-shadows without images

Known support: Firefox 3.5+, Chrome 5+, Safari 5+, Opera 10.6+, IE 9+

I’ll be looking mainly at a few details involved in making this effect more robust. Divya Manian covered the basic principle in her article Drop Shadows with CSS3 and Matt Hamm recently shared his Pure CSS3 box-shadow page curl effect.

After a bit of back-and-forth on Twitter with Simurai, and proposing a couple of additions to Divya’s and Matt’s demos using jsbin, I felt like documenting and explaining the parts that make up this technique.

The basic technique

There is no need for extra markup, the effect can be applied to a single element. A couple of pseudo-elements are generated from an element and then pushed behind it.

.drop-shadow {
  position: relative;
  width: 90%;
}

.drop-shadow:before,
.drop-shadow:after {
  content: "";
  position: absolute;
  z-index: -1;
}

The pseudo-elements need to be positioned and given explicit or implicit dimensions.

.drop-shadow:before,
.drop-shadow:after {
  content: "";
  position: absolute;
  z-index: -1;
  bottom: 15px;
  left: 10px;
  width: 50%;
  height: 20%;
}

The next step is to add a CSS3 box-shadow and apply CSS3 transforms. Different types of drop-shadow can be produced by varying these values and the types of transforms applied.

.drop-shadow:before,
.drop-shadow:after {
  content: "";
  position: absolute;
  z-index: -1;
  bottom: 15px;
  left: 10px;
  width: 50%;
  height: 20%;
  box-shadow: 0 15px 10px rgba(0, 0, 0, 0.7);
  transform: rotate(-3deg);
}

One of the pseudo-elements then needs to be positioned on the other side of the element and rotated in the opposite direction. This is easily done by overriding only the properties that need to differ.

.drop-shadow:after{
  right: 10px;
  left: auto;
  transform: rotate(3deg);
 }

The final core code is as shown below. There is just one more addition – max-width – to prevent the drop-shadow from extending too far below very wide elements.

.drop-shadow {
  position: relative;
  width: 90%;
}

.drop-shadow:before,
.drop-shadow:after {
  content: "";
  position: absolute;
  z-index: -1;
  bottom: 15px;
  left: 10px;
  width: 50%;
  height: 20%;
  max-width: 300px;
  box-shadow :0 15px 10px rgba(0, 0, 0, 0.7);
  transform: rotate(-3deg);
}

.drop-shadow:after{
  right: 10px;
  left: auto;
  transform: rotate(3deg);
}

No Firefox 3.0 problems this time

Some pseudo-element hacks require a work-around to avoid looking broken in Firefox 3.0 because that browser does not support the positioning of pseudo-elements. This usually involves implicitly setting their dimensions using offsets.

However, as Divya Manian pointed out to me, in this case we’re only using box-shadow – which Firefox 3.0 doesn’t support – and Firefox 3.0 will ignore the position:absolute declaration for the pseudo-elements. This leaves them with the default display:inline style. As a result, there is no problem explicitly setting the pseudo-element width and height because it won’t be applied to the pseudo-elements in Firefox 3.0.

Further enhancements

From this base there are plenty of ways to tweak the effect by applying skew to the pseudo-elements and modifying the styles of the element itself. A great example of this was shared by Simurai. By adding a border-radius to the element you can give the appearance of page curl.

.drop-shadow {
  border-radius: 0 0 120px 120px / 0 0 6px 6px;
}

I’ve put together a little demo page with a few of drop-shadow effects, including those that build on the work of Divya Manian and Matt Hamm.

If you’ve got your own improvements, please send them to me on Twitter.

The git-checkout command can be used to update specific files or directories in your working tree with those from another branch, without merging in the whole branch. This can be useful when working with several feature branches or using GitHub Pages to generate a static project site.

The git-checkout manual page describes how the git checkout command is not just useful for switching between branches.

When <paths> or --patch are given, git checkout does not switch branches. It updates the named paths in the working tree from the index file or from a named <tree-ish> (most often a commit)…The <tree-ish> argument can be used to specify a specific tree-ish (i.e. commit, tag or tree) to update the index for the given paths before updating the working tree.

In git, a tree-ish is a way of referring to a particular commit or tree. This can be a partial sha or the branch, remote, and tag name pointers.

The syntax for using git checkout to update the working tree with files from a tree-ish is as follows:

git checkout [-p|--patch] [<tree-ish>] [--] <pathspec>…

Therefore, to update the working tree with files or directories from another branch, you can use the branch name pointer in the git checkout command.

git checkout <branch_name> -- <paths>

As an example, this is how you could update your gh-pages branch on GitHub (used to generate a static site for your project) to include the latest changes made to a file that is on the master branch.

# On branch master
git checkout gh-pages
git checkout master -- myplugin.js
git commit -m "Update myplugin.js from master"

The need to update my gh-pages branch with specific files from my master branch was how I first found out about the other uses of the checkout command. It’s worth having a read of the rest of the git-checkout manual page and experimenting with the options.

Normalize.css is a small CSS file that provides better cross-browser consistency in the default styling of HTML elements. It’s a modern, HTML5-ready, alternative to the traditional CSS reset.

• Normalize.css project site
• Normalize.css source on GitHub

Normalize.css is currently used in some form by Twitter Bootstrap, HTML5 Boilerplate, GOV.UK, Rdio, CSS Tricks, and many other frameworks, toolkits, and sites.

Overview

Normalize.css is an alternative to CSS resets. The project is the product of 100’s of hours of extensive research by @necolas and @jon_neal on the differences between default browser styles.

The aims of normalize.css are as follows:

• Preserve useful browser defaults rather than erasing them.
• Normalize styles for a wide range of HTML elements.
• Correct bugs and common browser inconsistencies.
• Improve usability with subtle improvements.
• Explain the code using comments and detailed documentation.

It supports a wide range of browsers (including mobile browsers) and includes CSS that normalizes HTML5 elements, typography, lists, embedded content, forms, and tables.

Despite the project being based on the principle of normalization, it uses pragmatic defaults where they are preferable.

Normalize vs Reset

It’s worth understanding in greater detail how normalize.css differs from traditional CSS resets.

Normalize.css preserves useful defaults

Resets impose a homogenous visual style by flattening the default styles for almost all elements. In contrast, normalize.css retains many useful default browser styles. This means that you don’t have to redeclare styles for all the common typographic elements.

When an element has different default styles in different browsers, normalize.css aims to make those styles consistent and in line with modern standards when possible.

Normalize.css corrects common bugs

It fixes common desktop and mobile browser bugs that are out of scope for resets. This includes display settings for HTML5 elements, correcting font-size for preformatted text, SVG overflow in IE9, and many form-related bugs across browsers and operating systems.

For example, this is how normalize.css makes the new HTML5 search input type cross-browser consistent and stylable:

/**
 * 1. Addresses appearance set to searchfield in S5, Chrome
 * 2. Addresses box-sizing set to border-box in S5, Chrome (include -moz to future-proof)
 */

input[type="search"] {
  -webkit-appearance: textfield; /* 1 */
  -moz-box-sizing: content-box;
  -webkit-box-sizing: content-box; /* 2 */
  box-sizing: content-box;
}

/**
 * Removes inner padding and search cancel button in S5, Chrome on OS X
 */

input[type="search"]::-webkit-search-decoration,
input[type="search"]::-webkit-search-cancel-button {
  -webkit-appearance: none;
}

Resets often fail to bring browsers to a level starting point with regards to how an element is rendered. This is particularly true of forms – an area where normalize.css can provide some significant assistance.

Normalize.css doesn’t clutter your debugging tools

A common irritation when using resets is the large inheritance chain that is displayed in browser CSS debugging tools.

This is not such an issue with normalize.css because of the targeted styles and the conservative use of multiple selectors in rulesets.

Normalize.css is modular

The project is broken down into relatively independent sections, making it easy for you to see exactly which elements need specific styles. Furthermore, it gives you the potential to remove sections (e.g., the form normalizations) if you know they will never be needed by your website.

Normalize.css has extensive documentation

The normalize.css code is based on detailed cross-browser research and methodical testing. The file is heavily documented inline and further expanded upon in the GitHub Wiki. This means that you can find out what each line of code is doing, why it was included, what the differences are between browsers, and more easily run your own tests.

The project aims to help educate people on how browsers render elements by default, and make it easier for them to be involved in submitting improvements.

How to use normalize.css

First, install or download normalize.css from GitHub. There are then 2 main ways to make use of it.

Approach 1: use normalize.css as a starting point for your own project’s base CSS, customising the values to match the design’s requirements.

Approach 2: include normalize.css untouched and build upon it, overriding the defaults later in your CSS if necessary.

Closing comments

Normalize.css is significantly different in scope and execution to CSS resets. It’s worth trying it out to see if it fits with your development approach and preferences.

The project is developed in the open on GitHub. Anyone can report issues and submit patches. The full history of the project is available for anyone to see, and the context and reasoning for all changes can be found in the commit messages and the issue threads.

Related reading

Detailed information on default UA styles: WHATWG suggestions for rendering HTML documents, Internet Explorer User Agent Style Sheets,and CSS2.1 User Agent Style Sheet Defaults.

Translations

• Про normalize.css
• About normalize.css (Italiano)
• 关于Normalize.css

A collection of thoughts, experiences, ideas that I like, and ideas that I have been experimenting with over the last year. It covers HTML semantics, components and approaches to front-end architecture, class naming patterns, and HTTP compression.

About semantics

Semantics is the study of the relationships between signs and symbols and what they represent. In linguistics, this is primarily the study of the meaning of signs (such as words, phrases, or sounds) in language. In the context of front-end web development, semantics are largely concerned with the agreed meaning of HTML elements, attributes, and attribute values (including extensions like Microdata). These agreed semantics, which are usually formalised in specifications, can be used to help programmes (and subsequently humans) better understand aspects of the information on a website. However, even after formalisation, the semantics of elements, attributes, and attribute values are subject to adaptation and co-option by developers. This can lead to subsequent modifications of the formally agreed semantics (and is an HTML design principle).

Distinguishing between different types of HTML semantics

The principle of writing “semantic HTML” is one of the foundations of modern, professional front-end development. Most semantics are related to aspects of the nature of the existing or expected content (e.g. h1 element, lang attribute, email value of the type attribute, Microdata).

However, not all semantics need to be content-derived. Class names cannot be “unsemantic”. Whatever names are being used: they have meaning, they have purpose. Class name semantics can be different to those of HTML elements. We can leverage the agreed “global” semantics of HTML elements, certain HTML attributes, Microdata, etc., without confusing their purpose with those of the “local” website/application-specific semantics that are usually contained in the values of attributes like the class attribute.

Despite the HTML5 specification section on classes repeating the assumed “best practice” that…

…authors are encouraged to use [class attribute] values that describe the nature of the content, rather than values that describe the desired presentation of the content.

…there is no inherent reason to do this. In fact, it’s often a hindrance when working on large websites or applications.

• Content-layer semantics are already served by HTML elements and other attributes.
• Class names impart little or no useful semantic information to machines or human visitors unless it is part of a small set of agreed upon (and machine readable) names – Microformats.
• The primary purpose of a class name is to be a hook for CSS and JavaScript. If you don’t need to add presentation and behaviour to your web documents, then you probably don’t need classes in your HTML.
• Class names should communicate useful information to developers. It’s helpful to understand what a specific class name is going to do when you read a DOM snippet, especially in multi-developer teams where front-enders won’t be the only people working with HTML components.

Take this very simple example:

<div class="news">
    <h2>News</h2>
    [news content]
</div>

The class name news doesn’t tell you anything that is not already obvious from the content. It gives you no information about the architectural structure of the component, and it cannot be used with content that isn’t “news”. Tying your class name semantics tightly to the nature of the content has already reduced the ability of your architecture to scale or be easily put to use by other developers.

Content-independent class names

An alternative is to derive class name semantics from repeating structural and functional patterns in a design. The most reusable components are those with class names that are independent of the content.

We shouldn’t be afraid of making the connections between layers clear and explicit rather than having class names rigidly reflect specific content. Doing this doesn’t make classes “unsemantic”, it just means that their semantics are not derived from the content. We shouldn’t be afraid to include additional HTML elements if they help create more robust, flexible, and reusable components. Doing so does not make the HTML “unsemantic”, it just means that you use elements beyond the bare minimum needed to markup the content.

Front-end architecture

The aim of a component/template/object-oriented architecture is to be able to develop a limited number of reusable components that can contain a range of different content types. The important thing for class name semantics in non-trivial applications is that they be driven by pragmatism and best serve their primary purpose – providing meaningful, flexible, and reusable presentational/behavioural hooks for developers to use.

Reusable and combinable components

Scalable HTML/CSS must, by and large, rely on classes within the HTML to allow for the creation of reusable components. A flexible and reusable component is one which neither relies on existing within a certain part of the DOM tree, nor requires the use of specific element types. It should be able to adapt to different containers and be easily themed. If necessary, extra HTML elements (beyond those needed just to markup the content) and can be used to make the component more robust. A good example is what Nicole Sullivan calls the media object.

Components that can be easily combined benefit from the avoidance of type selectors in favour of classes. The following example prevents the easy combination of the btn component with the uilist component. The problems are that the specificity of .btn is less than that of .uilist a (which will override any shared properties), and the uilist component requires anchors as child nodes.

.btn { /* styles */ }
.uilist { /* styles */ }
.uilist a { /* styles */ }

<nav class="uilist">
    <a href="#">Home</a>
    <a href="#">About</a>
    <a class="btn" href="#">Login</a>
</nav>

An approach that improves the ease with which you can combine other components with uilist is to use classes to style the child DOM elements. Although this helps to reduce the specificity of the rule, the main benefit is that it gives you the option to apply the structural styles to any type of child node.

.btn { /* styles */ }
.uilist { /* styles */ }
.uilist-item { /* styles */ }

<nav class="uilist">
    <a class="uilist-item" href="#">Home</a>
    <a class="uilist-item" href="#">About</a>
    <span class="uilist-item">
        <a class="btn" href="#">Login</a>
    </span>
</nav>

JavaScript-specific classes

Using some form of JavaScript-specific classes can help to reduce the risk that thematic or structural changes to components will break any JavaScript that is also applied. An approach that I’ve found helpful is to use certain classes only for JavaScript hooks – js-* – and not to hang any presentation off them.

<a href="/login" class="btn btn-primary js-login"></a>

This way, you can reduce the chance that changing the structure or theme of components will inadvertently affect any required JavaScript behaviour and complex functionality.

Component modifiers

Components often have variants with slightly different presentations from the base component, e.g., a different coloured background or border. There are two mains patterns used to create these component variants. I’m going to call them the “single-class” and “multi-class” patterns.

The “single-class” pattern

.btn, .btn-primary { /* button template styles */ }
.btn-primary { /* styles specific to save button */ }

<button class="btn">Default</button>
<button class="btn-primary">Login</button>

The “multi-class” pattern

.btn { /* button template styles */ }
.btn-primary { /* styles specific to primary button */ }

<button class="btn">Default</button>
<button class="btn btn-primary">Login</button>

If you use a pre-processor, you might use Sass’s @extend functionality to reduce some of the maintenance work involved in using the “single-class” pattern. However, even with the help of a pre-processor, my preference is to use the “multi-class” pattern and add modifier classes in the HTML.

I’ve found it to be a more scalable pattern. For example, take the base btn component and add a further 5 types of button and 3 additional sizes. Using a “multi-class” pattern you end up with 9 classes that can be mixed-and-matched. Using a “single-class” pattern you end up with 24 classes.

It is also easier to make contextual tweaks to a component, if absolutely necessary. You might want to make small adjustments to any btn that appears within another component.

/* "multi-class" adjustment */
.thing .btn { /* adjustments */ }

/* "single-class" adjustment */
.thing .btn,
.thing .btn-primary,
.thing .btn-danger,
.thing .btn-etc { /* adjustments */ }

A “multi-class” pattern means you only need a single intra-component selector to target any type of btn-styled element within the component. A “single-class” pattern would mean that you may have to account for any possible button type, and adjust the selector whenever a new button variant is created.

Structured class names

When creating components – and “themes” that build upon them – some classes are used as component boundaries, some are used as component modifiers, and others are used to associate a collection of DOM nodes into a larger abstract presentational component.

It’s hard to deduce the relationship between btn (component), btn-primary (modifier), btn-group (component), and btn-group-item (component sub-object) because the names don’t clearly surface the purpose of the class. There is no consistent pattern.

In early 2011, I started experimenting with naming patterns that help me to more quickly understand the presentational relationship between nodes in a DOM snippet, rather than trying to piece together the site’s architecture by switching back-and-forth between HTML, CSS, and JS files. The notation in the gist is primarily influenced by the BEM system‘s approach to naming, but adapted into a form that I found easier to scan.

Since I first wrote this post, several other teams and frameworks have adopted this approach. MontageJS modified the notation into a different style, which I prefer and currently use in the SUIT framework:

/* Utility */
.u-utilityName {}

/* Component */
.ComponentName {}

/* Component modifier */
.ComponentName--modifierName {}

/* Component descendant */
.ComponentName-descendant {}

/* Component descendant modifier */
.ComponentName-descendant--modifierName {}

/* Component state (scoped to component) */
.ComponentName.is-stateOfComponent {}

This is merely a naming pattern that I’m finding helpful at the moment. It could take any form. But the benefit lies in removing the ambiguity of class names that rely only on (single) hyphens, or underscores, or camel case.

A note on raw file size and HTTP compression

Related to any discussion about modular/scalable CSS is a concern about file size and “bloat”. Nicole Sullivan’s talks often mention the file size savings (as well as maintenance improvements) that companies like Facebook experienced when adopting this kind of approach. Further to that, I thought I’d share my anecdotes about the effects of HTTP compression on pre-processor output and the extensive use of HTML classes.

When Twitter Bootstrap first came out, I rewrote the compiled CSS to better reflect how I would author it by hand and to compare the file sizes. After minifying both files, the hand-crafted CSS was about 10% smaller than the pre-processor output. But when both files were also gzipped, the pre-processor output was about 5% smaller than the hand-crafted CSS.

This highlights how important it is to compare the size of files after HTTP compression, because minified file sizes do not tell the whole story. It suggests that experienced CSS developers using pre-processors don’t need to be overly concerned about a certain degree of repetition in the compiled CSS because it can lend itself well to smaller file sizes after HTTP compression. The benefits of more maintainable “CSS” code via pre-processors should trump concerns about the aesthetics or size of the raw and minified output CSS.

In another experiment, I removed every class attribute from a 60KB HTML file pulled from a live site (already made up of many reusable components). Doing this reduced the file size to 25KB. When the original and stripped files were gzipped, their sizes were 7.6KB and 6KB respectively – a difference of 1.6KB. The actual file size consequences of liberal class use are rarely going to be worth stressing over.

How I learned to stop worrying…

The experience of many skilled developers, over many years, has led to a shift in how large-scale website and applications are developed. Despite this, for individuals weaned on an ideology where “semantic HTML” means using content-derived class names (and even then, only as a last resort), it usually requires you to work on a large application before you can become acutely aware of the impractical nature of that approach. You have to be prepared to disgard old ideas, look at alternatives, and even revisit ways that you may have previously dismissed.

Once you start writing non-trivial websites and applications that you and others must not only maintain but actively iterate upon, you quickly realise that despite your best efforts, your code starts to get harder and harder to maintain. It’s well worth taking the time to explore the work of some people who have proposed their own approaches to tackling these problems: Nicole’s blog and Object Oriented CSS project, Jonathan Snook’s Scalable Modular Architecture CSS, and the Block Element Modifier method that Yandex have developed.

When you choose to author HTML and CSS in a way that seeks to reduce the amount of time you spend writing and editing CSS, it involves accepting that you must instead spend more time changing HTML classes on elements if you want to change their styles. This turns out to be fairly practical, both for front-end and back-end developers – anyone can rearrange pre-built “lego blocks”; it turns out that no one can perform CSS-alchemy.

"We don’t want anything from the government. We just want to be dropped home," says a migrant worker from Chhattisgarh.

The Agriculture Produces Market Committee (APMC) in Navi Mumbai on Friday decided to shut all five markets — vegetables, fruits, masala, grain and oni

They say it violates Centre’s directive

All returnees are taken to centres from buses and trains