Chatwing is an embeddable chat box, so it can provide unlimited communication benefits to your blog or website. Installation is easy. You just need to input your email address and desired password in the registration page. After that, you can now go directly to the dashboard and start customizing the appearance and settings of the chatbox.

In the dashboard, you can edit the color themes and fonts of your desired chat box. Chatwing even allows you to create as many chat boxes as you can – all with varying designs. If you don’t want to edit every detail of the chatroom, you can select from Chatwing’s preset of background images. There are hundreds to choose from, so you can really optimize it according to the appearance of your website.

Chatting in any Chatwing chat app is also an easy thing to do. Your visitors can log in with their social media accounts, such as Facebook, Twitter, Google, and Yahoo. Registered Chatwing users can also communicate with you in the chatroom. Recently, Chatwing has added the live control panel in the chatroom. With this feature, visitors can edit their font styles, upload images, and even upload links of their favorite videos. This high rate of functionality can attract many visitors to your websites, raising the entertainment factor. Every now and then, you can start conversations in your chatrooms to engage your visitors.

In this competitive world, it pays to use all available tools within your disposal. Chatwing is one of these tools that can help you achieve your long-term goals.
Chatwing can be visited here Chatwing.com

I recently decided to put some effort into updating my understanding of the current standards in semantic and structured HTML markup

Consider the following markup:

<!-- Page Header -->
<div id="header">
  <h1 class="branding">Header</h1>
  <div id="navigation">
    <a class="nav-item" href="#">Nav Item</a>
    <a class="nav-item" href="#">Nav Item</a>
    <a class="nav-item" href="#">Nav Item</a>
    <a class="nav-item" href="#">Nav Item</a>
    <a class="nav-item" href="#">Nav Item</a>
  </div>
  <form id="search" action="#">
    <input name="s" type="search" placeholder="search"/>
  </form>
</div>

<!-- Main Content -->
<div id="main">

  <!-- article -->
  <div id="article">
    <h1>Article</h1>
    <p>Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod
    tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim,
    quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo
    consequat.</p>
    <div class="meta">
      <span id="author">Fred Smith</span>
      <span id="datePublished">May 1st 2012</span>
    </div>
  </div>

  <!-- Sidebar -->
  <div id="sidebar">Aside</div>

</div>

<!-- Page Footer -->
<div id="footer">
  <div class="copyright">&copy;2013</div>
</div>

There’s absolutely nothing wrong with this markup, it’s syntactically valid and highly readable to a human. Unfortunately, to software such as search engines and screen-readers, the sensibly named element ids (“header”, “main”, “footer” etc.) are as meaningful as if I’d named them, “bargle”, “fumpsquib” and “poinkotron”.

Semantic Tagging

Fortunately One of the primary aims of the HTML5 specification is to provide new HTML tags which infer some semantic meaning to the content. In this case I can use the header, footer and the recently added main tags to clearly set out the three main areas of the page.
Within the header I can use the nav tag to signpost the navigation menu.
Inside the main area of the page I use the article and aside tags to enclose the main article and the page sidebar. Finally I use the footer tag again for the article meta-data and convert the published date to a time element.

<!-- Page Header -->
<header>
  <h1 class="branding">Header</h1>
  <nav>
    <a class="nav-item" href="#">Nav Item</a>
    <a class="nav-item" href="#">Nav Item</a>
    <a class="nav-item" href="#">Nav Item</a>
    <a class="nav-item" href="#">Nav Item</a>
    <a class="nav-item" href="#">Nav Item</a>
  </nav>
  <form id="search" action="#">
    <input name="s" type="search" placeholder="search"/>
  </form>
</header>

<!-- Main Content -->
<main>

  <!-- article -->
  <article>
    <h1>Article</h1>
    <div>Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod
    tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim,
    quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo
    consequat.</div>
    <footer class="meta">
      <span class="author">Fred Smith</span>
      <time class="datePublished" datetime="2012-05-01">May 1st 2012</time>
    </footer>
  </article>

  <!-- Sidebar -->
  <aside>Aside</aside>

</main>

<!-- Page Footer -->
<footer>
  <div class="copyright">&copy;2013</div>
</footer>

So having implemented the latest HTML5 semantic elements, I should be done right? I can get straight into adding some CSS so that it looks pretty?

No, not yet, there is still more that I can do to make this content work across the myriad web-enabled platforms we live with, many of which don’t care what the content looks like.

WAI-ARIA

In order to make the content as accessible as possible, I’ll be adding some attributes from the Web Accessibility Initiative’s Accessible Rich Internet Applications specification (WAI-ARIA).

The ARIA spec is very detailed in order to provide for highly interactive web interfaces, for most static pages we only need to worry about adding what are known as “Landmark” roles to certain elements. These allow screen-readers and other accessibility tools to easily find and skip to standard page regions and elements.

The first three roles I add correspond to the header, main and footer regions of the page.

banner – A region that contains the prime heading or internal title of a page.

<header role="banner">

main – Main content in a document.

<main role="main">

It is intended that the main element will imply an ARIA role of main so the role attribute could be omitted, however the main element is a very recent addition to the HTML5 spec and so it will take time before software is updated to make the assumption.

contentinfo – Meta information which applies to the first immediate ancestor whose role is not presentation.

<footer role="contentinfo">

This assumes that the footer will contain all of the usual stuff; links to about and contact pages etc. – in my simple example I’m just putting a copyright notice.

Next there are some other elements which are suited to landmark roles, the navigation element, the search form and the sidebar.

navigation – A collection of links suitable for use when navigating the document or related documents.

<nav role="navigation">

search – The search tool of a Web document.

<form role="search" id="search" action="#">

complementary – Any section of the document that supports but is separable from the main content, but is meaningful on its own even when separated from it.

<aside role="complementary">

Now that I have nice semantic, accessible markup, surely NOW I can start prettying up the page with some CSS, after all there are a bunch of great hooks for my CSS selectors now:

header[role='banner']{
  background-color:magenta !important 
  /* because magenta makes things look classy! */
} 

But wait! .. there is another level of information that I can embed in my markup which will help the content to be understood by whichever platforms and systems that it happens to come into contact with, particularly search engines.

Structured Data

There are 3 main competing conventions for adding structured data to HTML markup; Microformats, RDFa and HTML5 Microdata. In the past I have always tried to implement Microformats as they use existing HTML attributes to mark up the data, however I’ve sometimes found them to be a little over-prescriptive, often requiring me to alter my markup in order to include required elements that I hadn’t intended to include in the content.

Scott Gilbertson has this to say on the subject of Microformats and RDFa:

Microformats are a really good idea, but essentially a hack. Because Microformats rely only on the class and rel attributes, writing parsers to read them is complicated.

At the same time, RDFa was designed to work with the now-defunct XHTML 2.0 spec. Although RDFa is being ported to work with HTML5, it can be overly complex for many use cases. RDFa is a bit like asking what time it is and having someone tell you how to build a watch.

http://www.webmonkey.com/2010/09/microdata-html5s-best-kept-secret/

I decided to go for HTML5 Microdata for the structured data markup, it is well supported by the major search providers, Bing, Google, Yahoo! and Yandex all use Microdata to improve search relevance and the way in which results are displayed (Google support all three formats so you could use any of them if you have a preference) and the open nature of the spec appealed to my internal interrogator who had the spec tied to chair shouting “can you handle whatever comes along next?” at it.

Google even provide a testing tool to check that the structured data in the page is valid and makes sense. Testing the current markup, for all of it’s accessibility and semantic correctness, there’s still no structured data available for the search engine to work with.

Schema.org keeps a growing list of schemas for marking up different types of content items. For this demonstration, I’m only going to markup the article in the page as structured data. First I add an itemscope attribute to the article element. This tells whichever system is parsing the content that this article element and all of it’s contents represent a structured data item. Next I need to specify what sort of item this is. A quick scan through the item type hierarchy on schema.org finds the Article item type, so I use the url of the page as the value of an itemtype attribute on the article element.

<article itemscope itemtype="http://schema.org/Article">

The next step is to look at the list of available properties in the Article schema and find the ones which match the content in my markup. These properties are assigned to the HTML elements by adding an itemprop attribute with the property name as it’s value e.g. itemprop=”name”.
For my very simple markup I’m assigning the name, articleBody, author and datePublished properties

<article itemscope itemtype="http://schema.org/Article">
  <h1 itemprop="name">Article</h1>
  <div itemprop="articleBody">
  ...
  </div>
  <footer class="meta">
    <span itemProp="author">Fred Smith</span>
    <time itemprop="datePublished" datetime="2012-05-01">May 1st 2012</time>
  </footer>
</article>

Testing the markup with the Structured Data Testing Tool now shows the article as a data item.

Complete at last

Here’s my final markup, including HTML5 Shiv so that IE6-8 can render the HTML5 elements successfully. Now I can start thinking about styling it up.

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8" />
    <title>Semantic Structured Article</title>
    <!--[if lt IE 9]><script type="text/javascript" src="http://html5shiv.googlecode.com/svn/trunk/html5.js"></script><![endif]-->
  </head>
  <body>
    <!-- Page Header -->
    <header role="banner">
      <h1 class="branding">Header</h1>
      <nav role="navigation">
        <a class="nav-item" href="#">Nav Item</a>
        <a class="nav-item" href="#">Nav Item</a>
        <a class="nav-item" href="#">Nav Item</a>
        <a class="nav-item" href="#">Nav Item</a>
        <a class="nav-item" href="#">Nav Item</a>
      </nav>
      <form role="search">
        <input type="search" placeholder="search"/>
      </form>
    </header>

    <!-- Main Content -->
    <main role="main">

      <!-- article -->
      <article itemscope itemtype="http://schema.org/Article">
        <h1 itemprop="name">Article</h1>
        <div itemprop="articleBody">
        Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod
        tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam,
        quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo
        consequat.
        </div>
        <footer class="meta">
          <span itemProp="author">Fred Smith</span>
          <time itemprop="datePublished" datetime="2012-05-01">May 1st 2012</time>
        </footer>
      </article>

      <aside role="complementary">Aside</aside>

    </main>

    <!-- Page Footer -->
    <footer role="contentinfo">
      <div class="copyright">&copy;2013</div>
    </footer>
  </body>
</html>

So there we go, a whole article about the differences that you can make by paying attention purely to the markup of your web page. Personally I tend to obsess over getting the markup right before I think about how to style the content. I don’t like adding new markup elements just for style purposes but if it becomes necessary, I’ve learned that the WAI-ARIA spec include a “presentation” role which signifies that an element exists purely for presentational purposes and should be ignored by accessibility tools when parsing the page. e.g.

<div class="decoration" role="presentation"></div>

Hopefully this article has highlighted the importance of marking up content to convey it’s meaning and structure. We live in a world where barely a week goes by without some new web-enabled device hitting the market with some previously unknown way of presenting data i.e. screen resolutions and aspect ratios, text-to-speech etc. By leveraging these evolving standards we can extend the usefulness and portability of the content that we create.

This article was originally published in Web Designers Magazine for iPad.

The slider can use thumbnail navigation or arrows, a very nice feature is that the thumbnails are responsive too.

The plugin is easy to set up and provides enough configuration options to make most web developers happy. The fact that you can configure functions to run when the slider initialises and at the start and end of each slide transition makes tweaking the functionality or implementing more complex functions fairly painless.

The generated CSS includes default break points for typical mobile and tablet screens (480px and 768px respectively). You can also create custom break points at different widths as you need; this allows you to quickly build a framework to suit a design, rather than designing to a pre-set grid.

LESS and SASS included

In addition to the CSS file, the downloadable template includes LESS and SCSS files so that you can plug straight into your favourite CSS pre-processor (what do you mean you don’t use either of these? – it’s 2012, nobody has time to actually write all of their CSS anymore).

Here’s what’s missing (at the moment)

Two things that I would love to see added to this tool are:

1. The ability to change the template markup to test basic layout ideas.
2. The ability to specify different column/gutter configurations at each break point.

That second one is a big ask, but I think it would take Responsify from being a useful tool, to being held in high regard as part of the web designer’s arsenal of time-savers.

via Code Visually

AjaxML is a javascript library which allows you to define all sorts of AJAX interactions in your markup.

At first I wasn’t sure that this was such a great idea, the thought of mixing up what I would normally do in javascript with the HTML markup of the site seemed like a bad idea. However after some thought I realised that the Markup defines the interface and the interactions are part and parcel of that interface.

Simple Example

for instance, this simple example from the AjaxML site:

  <a href="say_hello.html" into="target">
    Say Hello
  </a>
  <div id="target"></div>

loads the contents of say_hello.html into the target div.

Advanced Functionality

There’s no need to write functions to handle the click on the link, just specify the interaction in the markup.

The library also includes a good range of advanced features such as:

• The ability to attach event handlers e.g. error handling
• Validation – you can specify conditions which must be met before the Ajax call is enabled
• Specifying the request method – handy for REST API calls
• Sending request parameters including getting values from form inputs
• Browser history manipulation – let the user use their back and forward buttons without breaking your page.
• Ajax upload of files
• Composite requests – triggering more than one Ajax request from a single user interaction

Why it’s a good idea

This style of coding has the potential to make huge time savings when building interactive web pages. Single page sites which pull in data based on user interactions can be prototyped or (if the functionality was satisfactory) built, very quickly and can be altered much more easily due to the lack of any JavaScript changes if the markup is changed.

I also realised that in certain circumstances, the library can open up new possibilities. Take for instance a CMS-driven site, if the AjaxML library is included by default, content authors can create clever, responsive, compelling content without the need to write and maintain scripts for each page that included Ajax functionality.

Commenters: What’s your opinion? Does specifying the interactions in the markup make sense or do you see it as a maintenance headache? Does it create too much reliance on a third-party script library?

turn.js is a plugin for jQuery that creates a very realistic page turn effect using HTML5, it’s a lovely effect and the plugin has been written in such a way that implementing and configuring it is simple and undemanding.

It’s time to start creating that alternative interior design magazine that you’ve always dreamed of running.

Features

• Uses Hardware acceleration
• Works on tablets and smartphones
• Easy to manipulate
• Lightweight, only 15K

via turn.js – The page flip effect for HTML5.

The application also claims to be able to learn about your interests in order to present you with the most relevant content.

Personally, I’m still enjoying Sprout Social but if you are looking for an application to help you to monitor and manage your Social Media networks then Bottlenose may be worth a look.

via PanoJS3 – pure JavaScript viewer for huge images.

http://storify.com/techn0tic/storify-releases-wordpress-plugin

It’s not perfect yet, there’s still a disconnection between the Storify “Story” and the WordPress “Post” with the former being embedded in the latter as above. The advantage is that it is a great way to compile a post from multiple sources with the ability to search social networks and other sources and then drag snippets straight into the story.