This is a quick experiment that reproduces an image from I Love Typography using semantic HTML, CSS 2.1, a little CSS3. Along the way, I learnt about a few modern browser bugs and inconsistencies.

• See the demo: CSS typography experiment.
• See the bugs: Some new CSS 2.1 and CSS3 bugs in modern browsers.

I came across an image on I Love Typography that I thought could be reproduced using only semantic HTML and CSS.

The idea was to reproduce the image from simple markup, and to rely as much as possible on what can be achieved with CSS.

This is the HTML I ended up using.

<p>I love <strong>typography</strong> <em>a lot</em></p>

This is the CSS that controls the presentation of that content.

body {
  padding: 0;
  margin: 0;
  font-family: Times New Roman, serif;
  background: #000;
}

p {
  position: relative;
  width: 1100px;
  padding: 100px 0 0;
  margin: 0 auto;
  font-size: 175px;
  font-weight: bold;
  line-height: 1.2;
  letter-spacing: -13px;
  color: #0caac7;
  transform: rotate(-20deg);
}

/* "i" */
p:first-letter {
  float: left;
  margin: -137px -20px 0 0;
  font-size: 880px;
  line-height: 595px;
  text-transform: lowercase;
}

/* "love" */
p:first-line {
  font-size: 200px;
}

/* "typography" */
p strong {
  display: block;
  margin: -80px 0 0;
  font-weight: normal;
  letter-spacing: -2px;
  text-transform: capitalize;
}

p strong:first-letter {
  margin-right: -30px;
  color: #fff;
}

/* "a lot" */
p em {
  position: absolute;
  z-index: 10;
  top: 100px;
  left: 147px;
  width: 136px;
  overflow: hidden;
  padding-left: 64px;
  font-size: 200px;
  font-style: normal;
  text-transform: lowercase;
  color: #fff;
}

p em:first-letter {
  float: left;
  margin: 130px 0 0 -55px;
  font-size: 80px;
  font-style: italic;
  line-height: 20px;
  color: #fff;
}

/* create the heart shape */
p:before,
p:after {
  content: "";
  position: absolute;
  z-index: 1;
  top: 225px;
  left: 120px;
  width: 75px;
  height: 50px;
  background: #000;
  transform: rotate(45deg);
  border-radius: 25px 0 0 30px;
}

p:after {
  left: 138px;
  transform: rotate(-45deg);
  border-radius: 0 25px 30px 0;
}

/* hide the tip of the "t" from "a lot" */
p strong:before {
  content: "";
  position: absolute;
  z-index: 11;
  top: 205px;
  left: 341px;
  width: 7px;
  height: 7px;
  background: #000;
  border-radius: 7px;
}

The final CSS typography experiment approximates the original image in all modern browsers that support the CSS3 properties of border-radius and transform.

Some browsers render type (especially after rotational transformations) better than others. Note that all the screenshots are taken from browsers running on Windows Vista OS.

Browser bugs and inconsistencies

I’ve put together a small test page to highlight some new CSS 2.1 and CSS3 bugs in modern browsers. It includes two new CSS 2.1 bugs in Internet Explorer 8.

Here are two ways to include HTML5 elements in your WordPress post content without WordPress’ wpautop function wrapping them in p tags or littering your code with line breaks.

HTML5 has several new elements that you may want to use in your post content to markup document sections, headers, footers, pullquotes, figures, or groups of headings. One way to safely include these elements in your posts is simple; the other way is a bit more complicated. Both ways rely on hand-coding the HTML5 markup in the WordPress editor’s HTML view.

If you are adding HTML5 elements to your post content then you should use an HTML5 doctype.

Disable wpautop for your theme

This is the simple way. Disable the wpautop function so that WordPress makes no attempt to correct your markup and leaves you to hand-code every line of your posts. If you want total control over every line of your HTML then this is the option for you.

To disable wpautop entirely add these lines to your theme’s functions.php:

remove_filter('the_excerpt', 'wpautop');
remove_filter('the_content', 'wpautop');

However, wpautop is generally quite useful if most of your posts are simple text content and you only occasionally want to include HTML5 elements. Therefore, modifying wpautop to recognise HTML5 elements might be more practical.

Modify wpautop to recognise HTML5 elements

WordPress’ wpautop is part of the core functions and can be found in this file within your WordPress installation: wp-includes/formatting.php. It controls how and where paragraphs and line breaks are inserted in excerpts and post content.

In order to create a modified version of WordPress’ core wpautop function I started off by duplicating it in my theme’s functions.php file.

What I’ve experimented with is disabling wpautop and adding a modified copy of it – which includes HTML5 elements in its arrayss – to my theme’s functions.php file.

Add the following to your theme’s functions.php file and you’ll be able to use section, article, aside, header, footer, hgroup, figure, details, figcaption, and summary in your post content. (Probably best to try this in a testing environment first!)

/* -----------------------------
MODIFIED WPAUTOP - Allow HTML5 block elements in wordpress posts
----------------------------- */

function html5autop($pee, $br = 1) {
   if ( trim($pee) === '' )
      return '';
   $pee = $pee . "
"; // just to make things a little easier, pad the end
   $pee = preg_replace('|<br />s*<br />|', "

", $pee);
   // Space things out a little
    // *insertion* of section|article|aside|header|footer|hgroup|figure|details|figcaption|summary
   $allblocks = '(?:table|thead|tfoot|caption|col|colgroup|tbody|tr|td|th|div|dl|dd|dt|ul|ol|li|pre|select|form|map|area|blockquote|address|math|style|input|p|h[1-6]|hr|fieldset|legend|section|article|aside|header|footer|hgroup|figure|details|figcaption|summary)';
   $pee = preg_replace('!(<' . $allblocks . '[^>]*>)!', "
$1", $pee);
   $pee = preg_replace('!(</' . $allblocks . '>)!', "$1

", $pee);
   $pee = str_replace(array("
", "
"), "
", $pee); // cross-platform newlines
   if ( strpos($pee, '<object') !== false ) {
      $pee = preg_replace('|s*<param([^>]*)>s*|', "<param$1>", $pee); // no pee inside object/embed
      $pee = preg_replace('|s*</embed>s*|', '</embed>', $pee);
   }
   $pee = preg_replace("/

+/", "

", $pee); // take care of duplicates
// make paragraphs, including one at the end
   $pees = preg_split('/
s*
/', $pee, -1, PREG_SPLIT_NO_EMPTY);
   $pee = '';
   foreach ( $pees as $tinkle )
      $pee .= '<p>' . trim($tinkle, "
") . "</p>
";
   $pee = preg_replace('|<p>s*</p>|', '', $pee); // under certain strange conditions it could create a P of entirely whitespace
// *insertion* of section|article|aside
   $pee = preg_replace('!<p>([^<]+)</(div|address|form|section|article|aside)>!', "<p>$1</p></$2>", $pee);
   $pee = preg_replace('!<p>s*(</?' . $allblocks . '[^>]*>)s*</p>!', "$1", $pee); // don't pee all over a tag
   $pee = preg_replace("|<p>(<li.+?)</p>|", "$1", $pee); // problem with nested lists
   $pee = preg_replace('|<p><blockquote([^>]*)>|i', "<blockquote$1><p>", $pee);
   $pee = str_replace('</blockquote></p>', '</p></blockquote>', $pee);
   $pee = preg_replace('!<p>s*(</?' . $allblocks . '[^>]*>)!', "$1", $pee);
   $pee = preg_replace('!(</?' . $allblocks . '[^>]*>)s*</p>!', "$1", $pee);
   if ($br) {
      $pee = preg_replace_callback('/<(script|style).*?</\1>/s', create_function('$matches', 'return str_replace("
", "<WPPreserveNewline />", $matches[0]);'), $pee);
      $pee = preg_replace('|(?<!<br />)s*
|', "<br />
", $pee); // optionally make line breaks
      $pee = str_replace('<WPPreserveNewline />', "
", $pee);
   }
   $pee = preg_replace('!(</?' . $allblocks . '[^>]*>)s*<br />!', "$1", $pee);
// *insertion* of img|figcaption|summary
   $pee = preg_replace('!<br />(s*</?(?:p|li|div|dl|dd|dt|th|pre|td|ul|ol|img|figcaption|summary)[^>]*>)!', '$1', $pee);
   if (strpos($pee, '<pre') !== false)
      $pee = preg_replace_callback('!(<pre[^>]*>)(.*?)</pre>!is', 'clean_pre', $pee );
   $pee = preg_replace( "|
</p>$|", '</p>', $pee );

   return $pee;
}

// remove the original wpautop function
remove_filter('the_excerpt', 'wpautop');
remove_filter('the_content', 'wpautop');

// add our new html5autop function
add_filter('the_excerpt', 'html5autop');
add_filter('the_content', 'html5autop');

The results are not absolutely perfect but then neither is the original wpautop function. Certain ways of formatting the code will result in unwanted trailing </p> tags or a missing opening <p> tags.

For example, to insert a figure with caption into a post you should avoid adding the figcaption on a new line because an image or link appearing before the figcaption will end up with a trailing </p>.

<!-- this turns out ok -->
<figure>
  <a href="#"><img src="image.jpg" alt="" /></a><figcaption>A figure caption for your reading pleasure</figcaption>
</figure>

<!-- this turns out not so ok -->
<figure>
  <a href="#"><img src="image.jpg" alt="" /></a>
  <figcaption>A figure caption for your reading pleasure</figcaption>
</figure>

Another example would be when beginning the contents of an aside with a paragraph. You’ll have to leave a blank line between the opening aside tag and the first paragraph.

<aside>

This content could be a pullquote or information that is tangentially related to the surrounding content. But to get it wrapped in a paragraph you have to leave those blank lines either side of it before the tags.

</aside>

Room for improvement

Obviously there are still a few issues with this because if you format your post content in certain ways then you can end up with invalid HTML, even if it doesn’t actually affect the rendering of the page. But it seems to be pretty close!

Leave a comment or email me if you are using this function and find there that are instances where it breaks down. I ran numerous tests and formatting variations to try and iron out as many problems as possible but it’s unlikely that I tried or spotted everything.

Hopefully someone with more PHP and WordPress experience will be able to improve upon what I’ve been experimenting with, or find a simpler and more elegant solution that retains the useful wpautop functionality while allowing for the use of HTML5 elements in posts. Please share anything you find!

Using within-page links presses the jumped-to content right at the very top of the viewport. This can be a problem when using a fixed header. With a bit of hackery, there are some CSS methods to insert space between the top of the viewport and the target element within a page.

Demo: Jump links and viewport positioning

Known support: varies depending on method used.

This experiment is the result of a post Chris Coyier made on Forrst. Chris’ method was to add an empty span element to the target element, shift the id attribute onto the span, and then absolutely position the span somewhere above it’s parent element.

That method works but it requires changes to the HTML. The comments on Chris’ post suggested the use of psuedo-elements or padding. This experiment expands on, and combines, some of those suggestions to show the limitations of each method and document their browser support.

Simplest method

If you need to jump to an element with simple styling then using the :before pseudo-element is a quick and simple approach.

#target:before {
   content: "";
   display: block;
   height: 50px;
   margin: -30px 0 0;
}

The drawbacks are that it requires browser support for pseudo-elements and it will fail if the target element has a background colour, a repeated background image, padding-top, or border-top as part of its rule set.

More robust method

The more robust method uses a transparent border, negative margin, and the background-clip property. If a top border is required then it can be mimicked using a pseudo-element, as described in Multiple Backgrounds and Borders with CSS 2.1.

#target {
   position: relative;
   border-top: 52px solid transparent;
   margin: -30px 0 0;
   -webkit-background-clip: padding-box;
   -moz-background-clip: padding;
   background-clip: padding-box;
}

#target:before {
   content: "";
   position: absolute;
   top: -2px;
   left: 0;
   right: 0;
   border-top: 2px solid #ccc;
}

There are still drawbacks: it requires browser support for background-clip if there is a background color, gradient, or repeating image set on the target element; it requires browser support for pseudo-elements and their positioning if a top border is desired; and it interferes with the standard use of margins.

To see these methods in action – as well as more details on the code, browser support, and drawbacks – have a look at the demo page. Please let me know if you know of better techniques.

Future CSS implementations should allow for some form of responsive images via CSS alone. This is an early idea for how that might be done. However, a significant drawback is that it would not prevent both “mobile optimised” and larger size images from being requested at larger screen resolutions.

Note that the CSS presented here is not supported in any browsers at the time of writing.

This method relies on the use of @media queries, CSS3 generated content, and the CSS3 extension to the attr() function.

The principles are basically the same as those underpinning Filament Group’s work on Responsive Images. The source image is “mobile optimised” and the urls of larger size images are included using HTML data-* attributes.

<img src="image.jpg"
     data-src-600px="image-600px.jpg"
     data-src-800px="image-800px.jpg"
     alt="">

Using CSS @media queries you can target devices above certain widths. Within each media query block, images with larger alternatives can be targeted using an attribute selector.

CSS3 generated content allows you to replace the content of any element using the content property. At the moment, only Opera 10+ supports it. In CSS 2.1, the content property is limited to use with the :before and :after pseudo-elements.

By combining the content property with the CSS3 extension to attr(), you will be able to specify that an attribute’s value is interpreted as the URL part of a url() expression. In this case, it means you will be able to replace an image’s content with the image found at the destination URL stored in a custom HTML data-* attribute.

@media (min-device-width:600px) {
  img[data-src-600px] {
    content: attr(data-src-600px, url);
  }
}

@media (min-device-width:800px) {
  img[data-src-800px] {
    content: attr(data-src-800px, url);
  }
}

Fork the Gist

Issues

Unfortunately, there are a number of issues with this technique.

1. It doesn’t prevent multiple assets being downloaded at larger screen widths because network activity kicks in before CSS is applied. That means, for example, that desktop environments would make 2 HTTP requests for an image and have to load more assets than if they had been served only the larger image in the source.
2. It makes the assumption that wider screens are tied to better internet connections.
3. It forces authors to create and maintain multiple image sizes for each image.
4. At present, using the context menu (or drag and drop) to copy the image will result in the source file being copied and not the replacement image.
5. It doesn’t account for devices with different pixel densities.

I’m working on a project at Twitter that uses React and webpack. After a few conversations with @sokra last year, this is the setup I put in place for testing React components (authored using JSX and ES6) using Karma.

Dependencies

You’ll need to install various packages. It looks like a lot of dependencies, but all the non-Karma packages will be necessary for general module bundling during development.

Full set of required packages:

• babel-core: to transform JSX and transpile ES6.
• babel-loader: webpack loader for Babel.
• karma: the test runner.
• karma-chai-plugins: assertion library (or your library of choice).
• karma-chrome-launcher: Chrome browser launcher.
• karma-cli: CLI tool for Karma.
• karma-mocha: adapter for the Mocha testing framework.
• karma-sourcemap-loader: sourcemap loader.
• karma-webpack: to use webpack with Karma.
• react
• webpack: module bundler

webpack entry file

If you use webpack-specific features in your modules (e.g., loaders, plugins) you will need to use webpack to build a test bundle. The fastest and simplest approach is to create a single, test-specific entry file.

Create a file named tests.bundle.js. Within this file, you create a webpack context to match all the files that conform to a naming pattern – in this case *.spec.js(x).

var context = require.context('.', true, /.+.spec.jsx?$/);
context.keys().forEach(context);
module.exports = context;

Next, you point Karma to this file.

Karma config

Karma is configured using a karma.conf.js file. The browsers, plugins, and frameworks are specified in the standard way.

Point Karma at the tests.bundle.js file, and run it through the relevant preprocessor plugins (see example below).

The karma-webpack plugin relies on 2 custom properties of the Karma config: webpack and webpackMiddleware. The value of the former must be a webpack config object.

module.exports = function (config) {
  config.set({
    browsers: [ 'Chrome' ],
    // karma only needs to know about the test bundle
    files: [
      'tests.bundle.js'
    ],
    frameworks: [ 'chai', 'mocha' ],
    plugins: [
      'karma-chrome-launcher',
      'karma-chai',
      'karma-mocha',
      'karma-sourcemap-loader',
      'karma-webpack',
    ],
    // run the bundle through the webpack and sourcemap plugins
    preprocessors: {
      'tests.bundle.js': [ 'webpack', 'sourcemap' ]
    },
    reporters: [ 'dots' ],
    singleRun: true,
    // webpack config object
    webpack: {
      devtool: 'inline-source-map',
      module: {
        loaders: [
          {
            exclude: /node_modules/,
            loader: 'babel-loader,
            test: /.jsx?$/
          }
        ],
      }
    },
    webpackMiddleware: {
      noInfo: true,
    }
  });
};

Rather than duplicating your webpack config, you can require it in the Karma config file and override the devtool value to get sourcemaps working.

var webpackConfig = require('./webpack.config');
webpackConfig.devtool = 'inline-source-map';

module.exports = function (config) {
  config.set({
    ...
    webpack: webpackConfig
  });
};

That’s all you need to do to configure Karma to use webpack to load your JSX, ES6 React components.

Court says Hemant Bhatt needs to be treated at a govt. hospital

Bandipora tops the list with 134 cases, followed by Srinagar at 129

This has been the highest spike in the number of cases in the State in a single day, taking the number of cases to 1,678

Rupa Rani Bhuyan, assistant professor of Mangaldoi College, was held for “misbehaving” with the police and “obstructing” them from investigating cases against her

He is wanted for murder, attempt to murder and smuggling of weapons and drugs

State mulling changes in excise policy, labour laws amid lockdown