BlogmyQuery – BMQ

You can’t escape it. Everyone’s talking about HTML5. it’s perhaps the most hyped technology since people started putting rounded corners on everything and using unnecessary gradients. In fact, a lot of what people call HTML5 is actually just old-fashioned DHTML or AJAX. Mixed in with all the information is a lot of misinformation, so here, JavaScript expert Remy Sharp and Opera’s Bruce Lawson look at some of the myths and sort the truth from the common misconceptions.

[Offtopic: by the way, did you already get your copy of the Smashing Book?]

First, Some Facts

Once upon a time, there was a lovely language called HTML, which was so simple that writing websites with it was very easy. So, everyone did, and the Web transformed from a linked collection of physics papers to what we know and love today.

Most pages didn’t conform to the simple rules of the language (because their authors were rightly concerned more with the message than the medium), so every browser had to be forgiving with bad code and do its best to work out what its author wanted to display.

In 1999, the W3C decided to discontinue work on HTML and move the world toward XHTML. This was all good, until a few people noticed that the work to upgrade the language to XHTML2 had very little to do with the real Web. Being XML, the spec required a browser to stop rendering if it encountered an error. And because the W3C was writing a new language that was better than simple old HTML, it deprecated elements such as <img> and <a>.

A group of developers at Opera and Mozilla disagreed with this approach and presented a paper to the W3C in 2004 arguing that, “We consider Web Applications to be an important area that has not been adequately served by existing technologies… There is a rising threat of single-vendor solutions addressing this problem before jointly-developed specifications.”

The paper suggested seven design principles:

1. Backwards compatibility, and a clear migration path.
2. Well-defined error handling, like CSS (i.e. ignore unknown stuff and move on), compared to XML’s “draconian” error handling.
3. Users should not be exposed to authoring errors.
4. Practical use: every feature that goes into the Web-applications specifications must be justified by a practical use case. The reverse is not necessarily true: every use case does not necessarily warrant a new feature.
5. Scripting is here to stay (but should be avoided where more convenient declarative mark-up can be used).
6. Avoid device-specific profiling.
7. Make the process open. (The Web has benefited from being developed in the open. Mailing lists, archives and draft specifications should continuously be visible to the public.)

The paper was rejected by the W3C, and so Opera and Mozilla, later joined by Apple, continued a mailing list called Web Hypertext Application Technology Working Group (WHATWG), working on their proof-of-concept specification. The spec extended HTML4 forms, until it grew into a spec called Web Applications 1.0, under the continued editorship of Ian Hickson, who left Opera for Google.

In 2006, the W3C realized its mistake and decided to resurrect HTML, asking WHATWG for its spec to use as the basis of what is now called HTML5.

Those are the historical facts. Now, let’s look at some hysterical myths.

The Myths

“I Can’t Use HTML5 Until 2012 (or 2022)â€�

This is a misconception based on the projected date that HTML5 will reach the stage in the W3C process known as Candidate Recommendation (REC). The WHATWG wiki says this:

For a spec to become a REC today, it requires two 100% complete and fully interoperable implementations, which is proven by each successfully passing literally thousands of test cases (20,000 tests for the whole spec would probably be a conservative estimate). When you consider how long it takes to write that many test cases and how long it takes to implement each feature, you’ll begin to understand why the time frame seems so long.

So, by definition, the spec won’t be finished until you can use all of it, and in two browsers.

Of course, what really matters is the bits of HTML5 that are already supported in the browsers. Any list will be out of date within about a week because the browser makers are innovating so quickly. Also, much of the new functionality can be replicated with JavaScript in browsers that don’t yet have support. The <canvas> property is in all modern browsers and will be in Internet Explorer 9, but it can be faked in old versions of IE with the excanvas library. The <video> and <audio> properties can be faked with Flash in old browsers.

HTML5 is designed to degrade gracefully, so with clever JavaScript and some thought, all content should be available on older browsers.

“My Browser Supports HTML5, but Yours Doesn’tâ€�

There’s a myth that HTML5 is some monolithic, indivisible thing. It’s not. It’s a collection of features, as we’ve seen above. So, in the short term, you cannot say that a browser supports everything in the spec. And when some browser or other does, it won’t matter because we’ll all be much too excited about the next iteration of HTML by then.

What a terrible mess, you’re thinking? But consider that CSS 2.1 is not yet a finished spec, and yet we all use it each and every day. We use CSS3, happily adding border-radius, which will soon be supported everywhere, while other aspects of CSS3 aren’t supported anywhere at all.

Be wary of browser “scoring” websites. They often test for things that have nothing to do with HTML5, such as CSS, SVG and even Web fonts. What matters is what you need to do, what’s supported by the browsers your client’s audience will be using and how much you can fake with JavaScript.

HTML5 Legalizes Tag Soup

HTML5 is a lot more forgiving in its syntax than XHTML: you can write tags in uppercase, lowercase or a mixture of the two. You don’t need to self-close tags such as img, so the following are both legal:

<img src="nice.jpg" />
<img src="nice.jpg">

You don’t need to wrap attributes in quotation marks, so the following are both legal:

<img src="nice.jpg">
<img src=nice.jpg>

You can use uppercase or lowercase (or mix them), so all of these are legal:

<IMG SRC=nice.jpg>
<img src=nice.jpg>
<iMg SrC=nice.jpg>

This isn’t any different from HTML4, but it probably comes as quite a shock if you’re used to XHTML. In reality, if you were serving your pages as a combination of text and HTML, rather than XML (and you probably were, because Internet Explorer 8 and below couldn’t render true XHTML), then it never mattered anyway: the browser never cared about trailing slashes, quoted attributes or case—only the validator did.

So, while the syntax appears to be looser, the actual parsing rules are much tighter. The difference is that there is no more tag soup; the specification describes exactly what to do with invalid mark-up so that all conforming browsers produce the same DOM. If you’ve ever written JavaScript that has to walk the DOM, then you’re aware of the horrors that inconsistent DOMs can bring.

This error correction is no reason to churn out invalid code, though. The DOM that HTML5 creates for you might not be the DOM you want, so ensuring that your HTML5 validates is still essential. With all this new stuff, overlooking a small syntax error that stops your script from working or that makes your CSS unstylish is easy, which is why we have HTML5 validators.

Far from legitimizing tag soup, HTML5 consigns it to history. Souper.

“I Need to Convert My XHTML Website to HTML5�

Is HTML5′s tolerance of looser syntax the death knell for XHTML? After all, the working group to develop XHTML 2 was disbanded, right?

True, the XHTML 2 group was disbanded at the end of 2009; it was working on an unimplemented spec that competed with HTML5, so having two groups was a waste of W3C resources. But XHTML 1 was a finished spec that is widely supported in all browsers and that will continue to work in browsers for as long as needed. Your XHTML websites are therefore safe.

HTML5 Kills XML

Not at all. If you need to use XML rather than HTML, you can use XHTML5, which includes all the wonders of HTML5 but which must be in well-formed XHTML syntax (i.e. quoted attributes, trailing slashes to close some elements, lowercase elements and the like.)

Actually, you can’t use all the wonders of HTML5 in XHTML5: <noscript> won’t work. But you’re not still using that, are you?

HTML5 Will Kill Flash and Plug-Ins

The <canvas> tag allows scripted images and animations that react to the keyboard and that therefore can compete with some simpler uses of Adobe Flash. HTML5 has native capability for playing video and audio.

Just as when CSS Web fonts weren’t widely supported and Flash was used in sIFR to fill the gaps, Flash also saves the day by making HTML5 video backwards-compatible. Because HTML5 is designed to be “fake-able” in older browsers, the mark-up between the video tags is ignored by browsers that understand HTML5 and is rendered by older browsers. Therefore, embedding fall-back video with Flash is possible using the old-school <object> or <embed> tags, as pioneered by Kroc Camen is his article “Video for Everybody!â€� (see the screenshot below).

But not all of Flash’s use cases are usurped by HTML5. There is no way to do digital rights management in HTML5; browsers such as Opera, Firefox and Chrome allow visitors to save video to their machines with a click of the context menu. If you need to prevent video from being saved, you’ll need to use plug-ins. Capturing input from a user’s microphone or camera is currently only possible with Flash (although a <device> element is being specified for “post-5″ HTML), so if you’re keen to write a Chatroulette killer, HTML5 isn’t for you.

HTML5 Is Bad for Accessibility

A lot of discussion is going on about the accessibility of HTML5. This is good and to be welcomed: with so many changes to the basic language of the Web, ensuring that the Web is accessible to people who cannot see or use a mouse is vital. Also vital is building in the solution, rather than bolting it on as an afterthought: after all, many (most?) authors don’t even add alternate text to images, so out-of-the-box accessibility is much more likely to succeed than relying on people to add it.

This is why it’s great that HTML5 adds native controls for things like sliders (<input type=range>, currently supported in Opera and Webkit browsers) and date pickers (<input type=date>, Opera only)—see Bruce’s HTML5 forms demo)—because previously we had to fake these with JavaScript and images and then add keyboard support and WAI-ARIA roles and attributes.

The <canvas> tag is a different story. It is an Apple invention that was reverse-engineered by other browser makers and then retrospectively specified as part of HTML5, so there is no built-in accessibility. If you’re just using it for eye-candy, that’s fine; think of it as an image, but without any possibility of alternate text (some additions to the spec have been suggested, but nothing is implemented yet). So, ensure that any information you deliver via <canvas> supplements more accessible information elsewhere.

Text in a <canvas> becomes simply pixels, just like text in images, and so is invisible to assistive technology and screen readers. Consider using the W3C graphics technology Scalable Vector Graphics (SVG) instead, especially for things such as dynamic graphs and animating text. SVG is supported in all the major browsers, including IE9 (but not IE8 or below, although the SVGweb library can fake SVG with Flash in older browsers).

The situation with <video> and <audio> is promising. Although not fully specified (and so not yet implemented in any browsers), a new <track> element has been included in the HTML5 spec that allows timed transcripts (or karaoke lyrics or captions for the deaf or subtitles for foreign-language media) to be associated with multimedia. It can be faked in JavaScript. Alternatively (and better for search engines), you could include transcripts directly on the page below the video and use JavaScript to overlay captions, synchronized with the video.

“An HTML5 Guru Will Hold My Hand as I Do It the First Time�

If only this were true. However, the charming Paul Irish and lovely Divya Manian will be as good as there for you, with their HTML5 Boilerplate, which is a set of files you can use as templates for your projects. Boilerplate brings in the JavaScript you need to style the new elements in IE; pulls in jQuery from the Google Content Distribution Network (CDN), but with fall-back links to your server in case the CDN server is down.

It adds mark-up that is adaptable to iOS, Android and Opera Mobile; and adds a CSS skeleton with a comprehensive reset style sheet. There’s even an .htaccess file that serves your HTML5 video with the right MIME types. You won’t need all of it, and you’re encouraged to delete the stuff that’s unnecessary to your project to avoid bloat.

Further Resources

HTML5 is a massive topic. Here are a few hand-picked links. Disclosure: the authors have their fingers in some of these pies.

• W3C Specification: HTML5 (Edition for Web Authors)
  Just the stuff for those who write websites (as opposed to those who write browsers).
• HTML5 Demos and Examples
  Demos of the HTML5 APIs that are implemented in browsers.
• HTML5 Doctor
  Short, focused articles, “helping you implement HTML5 today.”
• html5-shims
  Scripts that fake HTML5 functionality in older browsers.

About the Authors

Remy and Bruce are two developers who have been playing with HTML5 since Christmas 2008: experimenting, participating in the mailing list and generally trying to help shape the language as well as learn it.

Bruce evangelizes Open Web Standards for Opera. Remy is a developer, speaker, blogger and contributing author for jQuery Cookbook (O’Reilly). He runs his own Brighton-based development company called Left Logic, coding and writing about JavaScript, jQuery, HTML5, CSS, PHP, Perl and anything else he can get his hands on. Together, they are the authors of Introducing HTML5, the first full-length book on HTML5 (New Riders, July 2010).

(al)

© Bruce Lawson, Remy Sharp for Smashing Magazine, 2010. | Permalink | Post a comment | Add to del.icio.us | Digg this | Stumble on StumbleUpon! | Tweet it! | Submit to Reddit | Forum Smashing Magazine
Post tags: html5

By Melinda Rainsberger

We’re all guilty of using the Ken Burns effect at some point. Multi-photo slide shows are difficult and unwieldy. Some programs come with presets for image slideshows, some just make it very easy to apply a standard piece of animation to many images. Carousels, image sliders, fade/zoom transitions, falling images, flash photography, and 3D space slideshows are just some of the many ways you can present a photo. In this article, we’ll present 5 of the most common slideshows that you might use, as well as giving you an After Effects project file that creates some of these simple slide shows. This could then be modified to fit your design requirements/images.



All these slideshows use the ‘sequence layers’ feature to some extent. Some use simple keyframing techniques and others use presets or even a mixture to create their effect. You can replace the photos use with your own or use the presets on your own video projects.

Fade/ Zoom

The Fade/Zoom slideshow is made by animating 3 properties at the front end of every layer. Each of the animated properties start out as: Scale (115%), Opacity (0%) and the Fast Blur Effect (50). Each effect is animated to transition to their original settings. Scale goes down to 100%, Opacity goes up to 100% and Fast Blur goes down to 0. This animation takes 40 seconds.  The layers are then sequenced, with a 40 frame overlap. This overlap means the images cross-dissolve into each other.

Hand-held/POV

This is based user point of view style that is popular in many cellphone ads. For even more realism, you could film a real person’s hand, then motion stabilize it and ‘photoshop’ the photos into the hand. The hand is two layers, the thumb is on the top, the rest of the hand is under the photos. In between these layers are the photos. They are a series of layers, sequenced and each one is rotated plus or minus 1 degree to create a bit of movement. The gray shaded background is made with a solid to add a little bit of depth.

‘Flash’ Photograph

Like the Fade/Zoom slideshow, 3 properties are animated before the layers are sequenced. Each of the beginning animated properties are: Tint (100% white), Scale (100%) and Rotation (0x, +0.0). They each end up at Tint (0% white), Scale (73%), and Rotation randomized and end between negative or positive 6 degrees (ox, -6.0 or 0x, +6.0). The layers are then sequenced. While they are offset, each of the layers’ out points are pulled out so that they continue to the end of the composition. This creates the illusion of a stack of photographs that are building. The layer styles Drop Shadow and an inner white Stroke complete the illusion that these are photographs.

Carousels

Image carousels can be made with keyframes or hard coded with the After Effect’s coding language called expressions. For our example, we’ll keep it small and use keyframes. However, for dozens of images, it’s much easier to use expressions. The Position, Scale, and Opacity animation properties are utilized. Instead of having an “A” and “B” point, they have 3-4 keyframes. This is to create the pause in the middle. If there were simply 2 Opacity keyframes, the image would only fade in or out, but could not fade in and then fade out. To create the reflection, the images are Pre-Composed (nested) and then this new, singular layer is duplicated, mirrored and masked with a fuzzy edge. We’ve also added a light gray shading to the background to create a greater sense of space.

3D World

Zooming around a 3D world will create a very slick presentation for your photos. In this slideshow, the images are arranged in 3D space, but are not animated. The only animated element is the camera. The extra dimensions of 3D space can be a bit confusing though. Try practicing with fewer elements before embarking on a large slideshow presentation.

Custom Mix

The custom mix uses a keyframes and presets, which are then customized a little bit to create a viewmaster-like slideshow. One of the original presets uses expressions–the coding language of After Effects. This configuration is then saved as its own preset. A preset is a effect/keyframe, it is saved as an external file and you can load it again and again to ensure a standard result.

Each of these slideshows use a mixture of effects and keyframes, in escalating levels of complexity. A good way to start delving into animation is to pull apart the working files and examine them. In some ways, After Effects and animation are more similar to the realm of web coding. The technology uses less real-world analogies, or uses analogies only professionals from specialized fields would understand. Having a start file allows you to see how a project is put together—typically the hardest part of animation is imagining what something will be before you’ve made it.

Designers tend to be perfectionists, as everything they do has to fit in place precisely the way they intend it to be whether based on concepts or imagination. Most browsers tend to default to Times New Roman or the likes, which does not quite blend in with sleek, imaginative, and very creative designs.

With that said, creative designers always search for new fonts and techniques to improve and implement their favorite typography to their websites. Below we’re excited to cover 7 helpful tips on how to improve the typography of your websites.

Contrast and Color

Color and contrast are a very important piece to the typography puzzle. Many tend to keep typography color in the same color wheel as their main design is. For instance, having a dark blue background means they tend to set a light blue typography color. Sometimes this is an issue as the colors may blend too much making it viewable but rather difficult to read causing eyestrain.

For your readers or viewers, this makes them less inclined to read articles or to browse around your website for a longer period of time. Therefore, the color contrast between the background and the foreground text or typography should generally be quite significant to keep things apparent, like black on white, or white on blue.

Font Size

The font size is a very important key to keeping text readable, clear, and precise. A general tip is to keep font in a comfortable cushion where it is not too large that can cause unnecessary used space, but not smaller than a usual textbook font size.

A good way to emphasize your body content from your sidebar or side-focus content is to generally have the font size of the body content larger than the side content as your viewers will spend more time reading the body text than the side text.

Therefore, keeping the side content out of focus from the body content enables the viewer to easily browse and read about, this is also referred to as a hierarchy between content.

Emphasis

Let us look back at the hierarchy concept discussed earlier, by it, we can easily identify between many bodies of text. For example, if the largest text in size on your web page is up top, while other bodies of text are significantly smaller, your eyes will naturally land on the larger object, in this case the larger text size. What this means is, by emphasizing certain keywords or text blocks, you increase its visibility across that page.

With that said, throughout your body text, highlighting or emphasizing key aspects from your text helps keep your long text blocks clear and understandable. Additionally, it gives your design or website a nice touch to the typography, keeping it unique and organized at its best.

Proofreading

Proofreading in this case does not correlate to assuring your text contains correct spelling and is grammatically correct, but rather correlates to tying the misconnection between your design and the typography. Typography is not always about how it looks from a design perspective but also how it appears in clarity and readability when it comes down to actually reading the text.

Many usually tend to post a dump of the lorem ipsum dummy text and make it look good at a design perspective, but do not actually go in depth to the reading level to read the text to understand if their implementation of the typography is actually suitable and comfortable for reading. With that said, do not just style and layout the typography based on what looks good for the design, but also assure the typography is clear, well spaced, and organized for the general audience to easily read through.

Too Many Fonts

I have seen this as a commonality across many websites as if the designer was a kid in a candy store and decided to pick out one of each to put in their baggy. We all have bundles of favorite font faces and we tend to use many of them across many different projects. However, using multiple font faces causes confusion to your reader, as each font face has its own style for each character, making it difficult for them to read through. Instead, stick to one or two font faces across your website, and use your favorites for other projects.

Good Whitespace

Cramming everything together is a viewer’s nightmare, let alone a pet peeve to any designer. Leave a good whitespace gap between sets of text to keep other bodies of text the viewer may not be reading out of focus from what they are reading. This generally helps viewers from running on to different segments of text or from unintentionally skipping lines. Remember, spacing is key to good readability, so use whitespace wherever needed.

Use Font Stacks

You may have a favorite font face and decide to use it on your website, however, you need to understand that not everyone may have that font installed on their system or device, thus, it will not display properly. Instead, use CSS’ font stacks rather generously as a fallback to your viewers that do not have the font you originally intended the website to use.

A good fallback font would be something similar to what you implemented for utilization, and a fallback to that would be a font that is generally used across most platforms and devices. It is a great way to assure your website’s typography does not significantly change across different platforms and devices, leaving your typography exactly or close to the way you intended it to appear.

Overall typography for the web is an interesting topic with many tips and DO’s and DON’T’s arising across the web. The main thing to note is that the way the typography appears should be user friendly as well as compliment your website’s design. This includes color and contrast, size, font face, and the likes. Do not overdo it and complicate it with the typography, but also have it fit in with your design well enough for it to look great as well as be great for your viewers.

Slideshows and image galleries are all the rage at the moment, there are loads of new techniques, plugins and tutorials cropping up everywhere. In this design news round-up we have chosen our favorites from recent weeks.

SIDEWAYS – jQuery fullscreen image gallery

Sideways is a simple, yet elegant fullscreen image gallery created with the jQuery and some simple CSS.
SIDEWAYS – jQuery fullscreen image gallery

Full Page Image Gallery with jQuery

In this tutorial you can learn how to create a stunning full page gallery with scrollable thumbnails and a scrollable full screen preview. The idea is to have a thumbnails bar at the bottom of the page that scrolls automatically when the user moves the mouse. When a thumbnail is clicked, it moves to the center of the page and the full screen image is loaded in the background.
Full Page Image Gallery with jQuery

Orbit: A Slick jQuery Image Slider Plugin

Orbit is a killer jQuery plugin that lets you create a simple, effective and beautiful slider for images of any size, and even includes some parameters for making awesome captions and a sweet timer.
Orbit: A Slick jQuery Image Slider Plugin

By Paul Andrew (Speckyboyand speckyboy@twitter).