Tagged with javascript

Four Things You Need to Make a Site (Work) in HTML5

Posted in Tutorial tagged with css, hmtl5, javascript, web standards Sat 26 Feb 2011 10:13 am

This site is made with HTML5, but without a few little extras, the styling and layout would break in all except the most up-to-date browsers. For example, in all versions of IE (except IE 9, which is still currently in beta) the CSS applied to new HTML5 tags would not work, and in Firefox 3.6, the layout would not look the same as in Chrome.

Here is a quick list of things you’ll need to get around these problems. None of them are hard to apply, and all the really hard work has been done by other people. Bonus!

1. The New Doctype

From the W3C’s working draft of HTML5, finally a doctype you can remember! Without the doctype, certain browsers will enter quirks mode (in order to maintain backwards compatibility for pages designed with standards that are not the W3C’s) and you have basically no chance of getting you web page to look right.

<p class="code-para">
    <code>&lt;!DOCTYPE html&gt;</code>
</p>

2. A Tag Reference

Knowledge is power, and so W3Schools HTML5 tag reference is a good place to start. How you interpret which tag is right for which part of your site is more or less up to you, but remember, the tags are to be used to give semantic meaning or context to the information in your page. Some are more obvious to apply than others.

At this point, you site will probably work with Safari, Opera and Chrome. So yeah, none of the big boys. The next two points include code that you can apply to your page, and are included (with loads of other stuff) in the fantastic HTML5 boilerplate, but if you want a simpler solution you can just include them yourself.

3. A CSS Reset

As mentioned before, even Firefox has trouble with HTML5; the new tags are inline elements by default, so applying display: block to them will fix most of the problems. A good CSS reset will do this and more, and is a great base from which to start coding.

4. The HTML5 Shiv

Now you’ve got your site working in modern browsers, you need to give IE 6-8 a kick up the backside. These versions of IE do not recognise the new tags at all, and will do all sorts of strange things with them (as they would for any other tag they do not recognise). For this site, IE will decide to push all the content out of the header and into the white content section below. Very annoying.

However, if I include Remy Sharp’s (and Jon Neal’s, with a little help from Sjoerd Visscher) brilliant HTML5 Shiv (or is it shim?), all my troubles are over. What this does is inform your browser that the world has moved on, and that other versions of HTML have come into being. You’re basically having to tell a browser how to do its job, and creating the element in the browser’s DOM.

&lt;!--[if lt IE 9]&gt;
&lt;script src=&quot;http://html5shim.googlecode.com/svn/trunk/html5.js&quot;&gt;&lt;/script&gt;
&lt;![endif]--&gt;

All done. Now go! Make a site in HTML5! Or HTML. Or whatever the cool kids are calling it these days.

Sloppily typed by Nick Pyett

Click to suit your screen

Posted in Tutorial tagged with css, javascript Thu 25 Jun 2009 2:05 pm

Fixed and variable width CSS layouts both have their strengths and weaknesses, and have each been adopted widely, but there is a third way.

Paul Sowdens’s “style-switcher” article on A List Apart describes (with a little help from PPK) how to use alternate style sheets and Javascript to let a user switch between the style sheets applied to a web page. The most widely known use of this technique is probably Wired.com’s text size widget, where by clicking on a smaller or larger text icon changes the size of the article text.

As the style-switcher technique allows us to switch between whole style sheets, it is not just the text size a user can be allowed to adjust. By the same token, whatever styles we put into our alternate style sheet will override the styles set out in the persistent or preferred style sheets, when enabled by the Javascript (as long as they are put in order to cascade properly).

We can now set up multiple alternate style sheets, each with different styles applied, and the user change between them. My homepage is styled with a fixed width of 800px, but a user can click on the links at the top of the right column to change this width to suit their screen, be it a portable device, wide screen or standard.

This approach overcomes the two main issues associated with fixed width layouts, namely, that either they are too wide for your screen and necessitate horizontal scrolling, or, that they look lost in a sea of emptiness on your snazzy high-res screen. It also does not suffer the problem often criticized of variable width solutions; that they can produce paragraph widths too wide as to be comfortable to read. The widths can be chosen and tested before anyone applies them.

And I know what some of you will say before you say it: “If you’re using Javascript anyway, why not just use the screen.width property and match the page width with that?” Good point, but this is just another way of producing a variable width layout. Admittedly, you could then use Javascript to choose between alternate style sheets, but we don’t want Javascript to choose the width of our page - we can do that for ourselves.

There is no reason, however, that one of these methods should not be available to the user, or even set as default. We could have a standard width for the page, for example, and a “match my screen size” button for those who felt the standard width was not appropriate for their screens. What I am proposing is that users should have the choice over how best to view content in their own browsers.

Sloppily typed by Nick Pyett