◊ Posted in Tutorial ◊
Posted in Tutorial
tagged with
jekyll
Fri 9 Feb 2024 8:31 am
Jekyll is a fantastic static site generator and I have recently implemented it to generate this site. While I was perfectly happy with my previous CMS, I enjoyed the idea of writing blog posts in markdown on my laptop locally and pushing content via an rsync command.
When creating Jekyll with the default command, the Minima theme will also be installed. Minima is a great theme and contains features to add author data, social icons and analytics snippets, but if you’ve already got a design like my site had, installing the Minima theme will add extra code that might get in the way of developing your own design.
To remove the theme, delete the theme entry from your _config.yml file and then remove the minima gem from your Gemfile, which should look something like this:
# This is the default theme for new Jekyll sites. You may change this to anything you like.
gem "minima", "~> 2.5"
Next, update the gems with bundle:
The default about.markdown file will contain some info about Minima but you can tidy that up in no time.
Another option is to read the docs in the first place and not install Minima at all, which we can do by using the blank option:
$ jekyll new site-dir/ --blank
Jekyll is an very well established static site generator at this point, but I hope to share more about it soon.
Sloppily typed by Nick Pyett
Posted in Tutorial
tagged with
git
Mon 22 Oct 2012 3:17 pm
Git’s speed and simplicity encourages regular, small commits. Commiting more often makes for smaller and easier to understand code changes, but does make it more likely that you will make a mistake in your commits. Fortunatly Git has the –amend commit option, which can be called like this:
This commit is like any other; only changes staged for commit will be commited. With the amend option, however, the changes made in the current working tree will be added to the changes in the previous commit, and will not create a new commit.
Lets run thought a simple example, starting with creating a directory and initialising a git repo (you will need to have git installed to follow this tutorial).
mkdir amend-test; cd amend-test # Make a new directory and change to it
git init # Initialise an empty git repo
echo 'This is a test file that we will amend.' > test.txt # Echo some text into a new file in our repo
git status # Get the status of our new repo
You should then see something like this from Git.
# On branch master
#
# Initial commit
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# test.txt
Add the file in the normal way and do our erroneous commit.
git add test.txt
git commit -m 'We added some text'
You will get a message from Git saying one file changed and one insertions. But oh, crap! We forgot to sign off! Quick Batman, add your name!
echo 'Yours, Nick' >> test.txt
We now need to add the files to be included in our next commit, just like a normal commit.
And now here is the magic…
Your default Git text editor will now pop up and give you a chance to amend the commit message as well, so practice editing that too. I changed mine to “We added some text, and our name”.
(If Vi/Vim pops up are you are not sure what to do, edit the message, press escape, type :x and hit enter).
And that’s it! No more commits about forgetting to update a timestamp or adding that all important new script - we have just one commit and our git history is clean. Don’t believe me? Run git log and find out for yourself.
A Word of Warning
If you are using remotes with your repositories, you may encounter an error when pushing a branch to a remote repository. If you have already pushed the repo before you apply the amend, and then try to push again, you may get this error:
error: failed to push some refs to 'git@remoterepo.com:dir/repo'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes (e.g. 'git pull') before pushing again. See the
'Note about fast-forwards' section of 'git push --help' for details.
This is because git can’t merge the changes between the two commits during a push. You have two options to resolve this problem. The first option is to do what the help message says, go a pull:
Now you may need to resolve any conflicts git has found. If there are conflicts, sort them out, commit the changes (without the –amend keyword this time), and push the result. If there are no commits, you are good to push straight away.
The second option is to force the commit. This is risky as you may loose changes to your repo, but is acceptable if you are sure noone else has access to the repo.
git push origin master --force
Sloppily typed by Nick Pyett
Posted in Tutorial
tagged with
jquery
Sun 30 Oct 2011 10:21 am
View the demo and fork on GitHub.
Fluid websites are a great method to create a responsive website. CSS can be used to create both fluid images and videos, but what about other web design elements? I was recently involved with a project that was using media queries to deliver the site over multiple platforms, and needed an image slider that was fluid. Google didn’t deliver, so I made one myself!
Create Your Own Image Gallery
The code is available on GitHub, as was created as a plugin for jQuery. Once you have jQuery in your page, create your HTML and CSS as described on the demo page, and then call Fluid Fader like so to create your image gallery.
$('#fluid-fader').fluidFader();
Browser Warfare
Fluid Fader work well across all browsers (yeah, including skanky old IE6), but because it needs quite a lot of CSS to make it work, I would suggest thorough testing.
Enjoy!
Sloppily typed by Nick Pyett
Posted in Tutorial
tagged with
css,
html,
media queries
Thu 25 Aug 2011 8:19 am
View the demo.
CSS3 media queries are a useful tool to change the layout of a web page depending on the screen size of the device viewing it. There are plenty of examples of how to create a site suitable for mobile or tablet devices using media queries (including this post on my blog), but what about screen sizes larger than the standard desktop layout width of 980 pixels?
Media queries are usually applied to a standard layout. For devices that do support media queries, the layout will be realigned to suit the device, but for those devices that don’t support media queries (such as a PC using IE6), the standard desktop layout will be used.
What’s the problem?
A website using the technique described so far may be viewed by a device which supports media queries (such as a PC using Firefox 6) but has a screen size much larger than 980 pixels (devices with screen sizes over 2,500 pixels in width are quite common), yet will still be viewing a site at 980 pixels wide.
Why optimize a layout for screen sizes of the average layout width and below, but not above the average?
The answer to this question is two fold. Firstly, we still want to deliver the average layout width to devices that don’t support media queries (which means we must build the original layout to 980 pixels in width), and secondly, we will still want to set an upper limit to the width of our design.
We would wish to do this for usability and design decisions, such as keeping the line length of text to the optimum of 60 - 80 characters, and keeping images from being stretched too much and being distorted.
The solution
You have probably seen many layouts using the max-width media feature, but you can also target CSS to devices above a certain width using min-width. Using these two features, we can write media queries that will fit screen sizes from a top limit (in this case it is 1150 pixels, but you can set the top limit to whatever you like), down to a mobile device width of around 320 pixels, but also, as the original design (the CSS before the media queries are applied) is created to 980 pixels, users without media queries will be served the average layout size.
I have created a demo to highlight this process in action. The demo includes a button to toggle media queries on and off (as long as your browser supports JavaScript).
Here is the CSS.
@media screen and (min-width: 1150px) {
.media-queries .row .center
{
width: 1116px;
}
}
@media screen and (max-width: 1149px) {
.media-queries .row .center
{
width: 96%;
padding-left: 0;
padding-right: 0;
}
}
@media screen and (max-width: 480px) {
.media-queries .row .center
{
padding: 0;
}
.media-queries .row .center div
{
float: none;
width: 100%;
margin: 17px 0;
}
}
As you can see, we are creating two queries with only 1 pixel in difference, the first to target screens with width of 1150 pixels and everything above (the width of 1116 pixels is due to the padding on the sides of the central div, and the .media-queries class is for toggling the effect in the demo), and the second to devices 1 pixel smaller, at 1149 pixels.
The third screen query is to align the layout to a mobile screen.
Media queries are a very powerful technique, so if just making a layout wider for larger screens is not enough to create a great design, you could use the positioning or display CSS properties to add, rearrange or reposition new or existing elements.
Using this technique makes targeting layouts to screen sizes of both above and below the average easy, so you can create the best user experience for the most users as possible.
Sloppily typed by Nick Pyett
Posted in Tutorial
tagged with
css,
html,
media queries
Thu 30 Jun 2011 3:14 pm
One of the development priorities when I redesigned my website was to use media queries to create a layout that was responsive to as many screen sizes as possible. With the rise of mobile, we can no longer rely on 980 pixel wide layouts delivering the best experience for the various devices being used to browse the web.
Media queries are part of the CSS3 W3C recommendation and can be used to completely restyle a web page depending on the media type (such as print or screen) and media feature of the device’s screen, such as orientation, resolution and colour support. For my site, I shall only be using the media type and width of the screen.
Responsive and Fluid
Many of the sites that use media queries also employ another technique to create a responsive website. Fluid layouts use relative widths (such as percentages) that only fill a portion of the screen width of the device being used, meaning content will fit to all screen sizes. A limitation of fluid layouts is that content cannot be hidden or the layout changed significantly, such as moving entire columns or changing background images.
Media queries used alongside fluid layouts provide the best of both worlds: a design that can fit to a screen size exactly, and a layout that can be realigned depending on that screen size.
Not mobile specific?
Another tactic for creating a device specific website is using device detection and redirecting to a separate dedicated site, usually on a sub-domain such as http://m.example.com. Device detection is a great method if the content of your current standard desktop site is incredibly complex, contains large file sizes or would generally be difficult to scale down for a mobile’s screen.
A lingering problem with device detection is that it is very difficult to predict and detect every single device before it arrives at your site. Granted, most devices can be predicted, and media queries themselves are not supported perfectly in all browsers, but media queries will at least fit all devices that support them perfectly. For both these cases, the worst case scenario is that the user will see the desktop version of the site.
If you do decide to use device detection, what do you do about tablets? You could create another site specifically for tablets, but tablets have a wide range of screen sizes, so it is imperative that you create a fluid design that will fit to all tablet screen sizes. You will now have created three separate websites! This may be the best tactic for your digital marketing strategy, and you could certainly take steps to reuse the content and media, but this may not be within your budget.
If the content on your site is mainly copy with a small amount of images, which could be downloaded easily on a mobile Internet connection, media queries allow you to serve a design specific to the device, without any redirection or creation of multiple websites. This is the case with my blog, and certainly many other blogs and other types of website.
The Beef
Ok let’s finally get down to some code. Firstly, the media queries themselves.
@media screen and (max-width: 940px) {
/* CSS here creates two-column fluid layout */
}
@media screen and (max-width: 480px) {
/* CSS here creates single-column fluid layout, realigns header */
}
As you can see, only the two. These are positioned right at the bottom of my CSS file.
The first query will apply the CSS for screen sizes (for media types of screen) no larger than 940 pixels. This is the width of the main content of my website; the central column of 900 pixels and padding of 20 pixels at each side.
Without media queries, the layout of my site would result in a horizontal scroll-bar for screens smaller than 940 pixels. With media queries, I have applied widths measured in percentages for the two column’s containing the main content and aside, and the central column, leaving a small percentage to create a margin at both vertical edges of the page.
I also have a line of CSS to make the images in the page fluid. The image tags themselves do not have any width or height attributes, and the image files are the same width as the column that they are in. With the following line of CSS, they will become fluid and fit to the column.
.col-a article img
{
width: 100%;
}
Devices with screen widths smaller than 940 pixels wide include the iPad tablet and HTC Desire mobile phone in portrait orientation, among many older desktop monitors and laptops.
The second query creates a single column layout. The aside at the right of the page is moved to below the main content and the header is realigned so that the logo and main navigation are on top of each other and both centrally aligned. The styles from the previous media query mentioned are also still applied, so no need to re-declare styles.
Devices with screen widths smaller than 480 pixels include the iPhone (lower than generation 4) in portrait orientation and the Blackberry Curve in the standard landscape mode.
I wish I could say that was all you had to do, but there are a few more things we must apply before our responsive site works as we want it to for as many devices as possible. Firstly, you must add a few lines of meta data to each page in the head of the document.
<meta name="viewport" content="width=device-width, minimum-scale=1.0, maximum-scale=1.0" />
<meta name="HandheldFriendly" content="true" />
<meta name="MobileOptimized" content="width here" />
The viewport meta data tells mobile browsers that the width of the document should be the same width as the device’s screen. Without this present, a device may use the width of a title or image as the maximum width, meaning a user would have to scroll horizontally.
The MobileOptimized is only used by some IE browsers, and stops the browser attempting to fit the layout of your site to the screen itself. You must specify a width for this. I chose 320 pixels, as it is a good baseline for most mobile sites. The HandheldFriendly meta data does a similar job a range of other mobile browsers.
Poly-fill for Internet Explorer
CSS3 is not implemented in IE older than version 9, but there is a great JavaScript poly-fill available on Google code that will parse your CSS and apply media queries to your site, even in IE. It works well, but has the disadvantage that your CSS is downloaded twice for anyone using IE to view your site, adding to your server load. You may to choose not to support older IE versions, as again the worst case scenario is that users will see the non-responsive desktop site.
<!--[if lt IE 9]>
<script src="http://css3-mediaqueries-js.googlecode.com/svn/trunk/css3-mediaqueries.js"></script>
<![endif]-->
Why You Shouldn’t Just Design for the iPhone
As a final point about design, I would suggest not to design for just one device. Apple’s iPhone is a great way to browse the web, but the strength of media queries is that they are “device agnostic” - they respond to the device’s screen size, rather than the device itself. You should test your design, and decide for which widths you should alter the layout, considering elements of your design such as line length, floats and accessibility of content.
Looking at the analytics for my site, I have had hits from devices based on the mobile operating systems of Android, iOS and SymbianOS in the last month. The mobile web is a real consideration for my site, and this trend is set to continue. Media queries are a great device for creating flexible and responsive web page layouts, and with the tips in the tutorial you should have mobile appropriate content in no time.
Sloppily typed by Nick Pyett
Posted in Tutorial
tagged with
html5,
web standards
Fri 25 Mar 2011 1:18 pm
Since the days we broke free from tables to structure our web designs, one HTML element has been the most useful and widely used. The div HTML element is almost guaranteed to appear in the markup of any website that has been built to separate content from design and to current web standards. But standards move on; and the future is not looking rosy for the div.
Take a look at the draft specification for HTML5 and there is our old friend the div. But wait, what does that say below?
Authors are strongly encouraged to view the div element as an element of last resort, for when no other element is suitable. Use of the div element instead of more appropriate elements leads to poor accessibility for readers and poor maintainability for authors.
That’s right; you’re being told (more or less) to stop using the div. There are far more semantic elements to choose from when you are marking-up your content. Are you creating a blog post? Use the article element. Are you adding content that is only partially related to your main content? Use the aside tag. The div tag has no meaning at all, which, when authoring a document, is not helpful at all to the reader.
But it’s not the end for the div, as it can still be used to group content. For example:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8" />
<title>Types of Markup Language</title>
<link rel="stylesheet" type="text/css" href="did-you-know.css" />
</head>
<body>
<section>
<hgroup>
<h1>HTML</h1>
<h2>Markup for Authoring Web Pages</h2>
</hgroup>
<p>You're reading a page made in HTML right now!</p>
<div class="did-you-know">
<p>HTML was invented by Tim Berners-Lee (among others), who also helped create HTTP and URL's.</p>
<p>Tim Berners-Lee now leads the W3C, an organisation that helps develop web standards.</p>
</div>
</section>
<section>
<hgroup>
<h1>XML</h1>
<h2>Markup for Creating Machine Readable Data</h2>
</hgroup>
<p>RSS feeds are an example of commonly used XML.</p>
</section>
</body>
</html>
The div in this example is used to style a part of the document that explains extra facts directly related to the content of the section. (The content is not appropriate for a blockquote, nor is it digressing enough from the section content to use an aside.)
The HTML5 specification goes quite deeply into “sectioning content”, or how to hierarchically structure your HTML document. I won’t go into it too deeply, but this essentially means a properly sectioned document will break up the document by thematically grouping the content into distinct sections. You can even have more than one h1 element (as many as you need) in one web page.
For properly sectioning content, we can use the section and article elements. If we again look at the HTML5 specification, we find more advice on the div in the section section of the document.
> The `section` element is not a generic container element. When an element is needed for styling purposes or as a convenience for scripting, authors are encouraged to use the `div` element instead.
Let’s look at another example of how we may use a div. Take the markup below.
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8" />
<title>Types of Markup Language</title>
<link rel="stylesheet" type="text/css" href="border.css" />
</head>
<body>
<div class="border">
<section>
<h1>HTML</h1>
<p>HTML was invented by Tim Berners-Lee (among others), who also helped create HTTP and URL's.</p>
</section>
<section>
<h1>XML</h1>
<p>RSS feeds are an example of commonly used XML.</p>
</section>
<section>
<h1>XHTML</h1>
<p>XHTML was created to be more interoperable with other data formats and is more strict in its syntax than HTML.</p>
</section>
</div>
<aside>
<h1>Learn more</h1>
<p>You can learn more about how to script HTML at <a href="http://htmldog.com/">htmldog.com</a>.</p>
</aside>
</body>
</html>
This is a similar example as before, except this time the sections are much shorter. Imagine we want to create a design of the three sections in a single row (probably by floating them to the left and giving them a width) within a border, with an aside in the same row but floated right. The easiest way to achieve this is by wrapping the sections in a div. I would suggest that it would make no sense to a reader if we used another section element, as we just want to style the section of content, rather than group it thematically.
As a general rule, I would suggest to consider using a div element if the section you are wrapping does not have a header (h1, h2 etc.). This is because headers should be used to title thematic groups and introduce a reader to the section of content. If your section of content does not have a sensible header, then it’s probably not a thematic group of content.
(As a quick note, the HTML5 specification is still in its draft stage, so some of this may change in the future.)
Authoring HTML is subjective. In most cases there is no single correct answer. Even the examples I have given here could be marked-up differently and still make sense to a reader, but I hope I have shown you that the div element is still a useful part of HTML that can be used in an effective way to achieve your designs.
Sloppily typed by Nick Pyett
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><!DOCTYPE html></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.
<!--[if lt IE 9]>
<script src="http://html5shim.googlecode.com/svn/trunk/html5.js"></script>
<![endif]-->
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
Posted in Tutorial
tagged with
firefox
Sat 26 Jun 2010 8:53 am
Searching using the default Google search from Firefox’s address bar will use Google US, but if you want to change this to Google UK, you can use the following method.
You can edit many of the Firefox’s preferences by opening Firefox and typing “about:config” (without the quotes) into the address bar. You will then be greeted by a screen that reads “Hear be dragons!”. Click the button that reads “I’ll be careful, I promise!” (and make sure you are), and the preferences list will appear. As you can see, there are loads. Type “keyword” into the “Filter:” search field at the top of the page and two preferences will be displayed, “keyword.URL” and “keyword.enabled”.
http://www.google.co.uk/search?ie=UTF-8&oe=UTF-8&q=
Firstly, copy the line of text above and then double click on the “keyword.URL” preference. A pop-up box titled “Enter string value” will appear. Paste the text into the input field and click “OK”. Next, if the text in the “Value” column of the second preference “keyword.enabled” reads “false”, double click on the preference to change it to “true”. This will allow the search keyword we just set to be used. With this setting set to “false”, any search in the address bar will take you to the closest URL to your search term. You may like this functionality, but the sites you will be taken to will only be in relation to the URL, not in relation to any search engine page-rank or site quality.
Close the “about:config” tab or Firefox itself to close the preferences menu. Other resources on Firefox include my blog post How to view your Firefox bookmarks in a tab and MozillaZine’s About:config entries article.
Sloppily typed by Nick Pyett
Posted in Tutorial
tagged with
css,
html,
seo
Thu 3 Jun 2010 11:50 am
Image replacement is a great technique for anyone wanting to maximise SEO and design on a web page. What with the “do they don’t they” question of whether Google penalise pagerank for those using it more or less answered, I thought I’d have a look at how Google do it themselves.
On any Google search results page, you will see their logo at the top left of the page, next to the search box. This image is an image sprite consisting of most of the images used on the page. If we disable images on the page, we are left with a text link back to Google’s homepage where Google’s logo was. Disabling both styles and images leaves a similar result. Google achieve this with the following HTML.
<h1>
<a href="http://www.google.com/">
Google
<img width="167" height="222" src="nav_logo13.png" alt="" />
</a>
</h1>
The HTML used is what you’d expect for a text based link, apart from the empty alt text attribute and with the addition of some text reading “Google” between the anchor tags. It is this text that we need to hide (or replace) in order to get the look we need. This is achieved with the following CSS.
h1
{
font-size: 1em;
font-weight: normal;
}
h1 a
{
height: 49px; width: 137px;
display: block;
position: relative;
overflow: hidden;
}
h1 a img
{
border: 0;
position: absolute;
left: 0;
top: -41px;
}
Let’s start with the CSS applied to the image itself. The border property is to remove the default anchor border style. So far, so boring. The position property is more interesting, as it allows us to hide the “Google” text between the anchor tags. Absolutely positioned elements can be positioned with the top, right, bottom and left properties. These properties set the margin (in pixels) between the element and the next parent element with a position property other then the default “static” value.
In our case, the parent element is the anchor. The left property is applied to our image with a value of zero, which means the image will have no left margin in relation to the anchor. As a result of this, the text between the anchor tags is covered by the image. Image replacement complete!
The rest of the styles are only necessary if you are going to use an image sprite. The height, width, display and overflow properties applied to the anchor trim the image so that only the Google logo appear, and the same goes for the top property applied to the image. The font styles applied to the h1 element are to make the text small enough to hide behind the image.
Alt text is used to give context to an image for a screen reader or if images have been disabled by the user. In this case, it is not necessary; the “Google” text between the anchor tags serves this purpose. One criticism you may make of this method is that it generates “double text” if the user has disabled styles but not images, as both the image and text are visible. Please bear that in mind if you would like to implement this method.
If you would like to learn more about the CSS discussed in this article, W3 Schools is a great resource. If you’re wondering how on earth I figured out the CSS applied to each element, you need to get Firebug for Firefox in your life!
Sloppily typed by Nick Pyett
Posted in Tutorial
tagged with
firefox
Fri 14 May 2010 4:02 pm
There are many great add-ons for Firefox (the open-source web browser from Mozilla), some of which allow you to open your bookmarks in a formatted tab. Both Bookmarks Tab and MyBookmarks do this, but if you want something even simpler, copy and paste the following line into Firefox’s address bar.
chrome://browser/content/bookmarks/bookmarksPanel.xul
Easy! If you want to be even craftier, you can bookmark the address, right click, choose “Properties”, check the box that says “Load this bookmark in the sidebar” and click “Save”. You now have a bookmark that will open all your bookmarks as normal when you left-click, or open in them in a new tab when you Ctrl+click or middle-click, just like opening a normal tab window.
Other great Firefox resources include the Basic Bookmarks add-on, a jimmyrcom YouTube tutorial showing you how to speed the browser up with about:config and LifeHacker’s guide to FF3.
Sloppily typed by Nick Pyett
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
Posted in Tutorial
tagged with
web,
standards
Wed 17 Jun 2009 12:27 pm
The World Wide Web Consortium (W3C) is an organisation dedicated to developing standard practices and guidelines to help the internet grow in a positive way.
The W3C produce recommendations about how to best apply a web programming language. Everything from current standards, such as XHTML, the mark-up language this website is coded in, to newer languages, such as Service Modeling Language, a language used to model complex services and systems, are explained in detail. These guidelines are only recommended after the endorsement of W3C members and its Director.
By complying with the W3C recommendations set out for web programming, a web designer can produce sites that are easily accessible to a user and compatible with the range of browsers that are available today. Why should the browser you’re using effect how the web looks? Well, in a perfect world, it shouldn’t, but different browsers support different programming languages to different degrees.
To aid web programmers in complying with the recommendations for HTML, the W3C provide a validator to check a designer’s code against its own guidelines. This service shows errors and warnings if your code does not match the specific guidelines set out for HTML (or XHTML). Validators for CSS, hyperlinks and mobile devices, among others, are also provided.
Membership to the W3C is open to companies and individuals, of which there are over 400. The advantages of membership for a company is to get an early insight into market trends and emerging technologies, not to mention the kudos received for being an innovator within the industry and the networking possibilities.
To give you an idea of the sort of early insight we are talking about, the W3C launched the Mobile Web Initiative, to facilitate mobile web access, in May 2005, over a year and a half before the release of the iPhone. In February 1998, XML, the language used for RSS news feeds and blogs, became a W3C recommendation, five years before Google bought Blogspot.com.
Currently, the W3C is focusing on the tools to bring about a Semantic world wide web. This is a vision of the internet where data is easily accessible to a wide range of applications, rather than the model we have now, where applications control data.
Since its creation in October 1994 by Tim Berners-Lee, the inventor of the internet, the W3C has been at the forefront of the development of the web, and now, with the creation of the Web Science Research Initiative, the goal for the future is to “build synergies between Web Science and Web Standards - to ensure that the Web benefits all people on the planet”. If you are anybody from a web enthusiast to an associate in a large corporation, news from the W3C and its associated bodies is always worth following.
Sloppily typed by Nick Pyett
