侘寂

Language Support In HTML

Defining the language you are using on a HTML page makes it easier for browsers, speech synthesizers, search engines and online services to understand, present, and translate your content. Generally speaking, you should declare the language of a document by specifying the lang attribute on the <html> element:

<html lang="en">

(You’ll note that I use this approach in my HTML5 boilerplate example.)

The language code is a two-letter acronym that follows ISO 639-1, an international standard for defining every known human language. (You can find a complete list of 639-1 language codes at Wikipedia or IANA). If you are using a specific dialect or derivation of a language, you can also add a sub-code. Often, this sub-code follows the ISO-3166-1 specification (which, interestingly, matches the country’s assigned TLD):

<html lang="en-US"> (“US English”)

<html lang="fr-CA"> (“Canadian French”)

But the sub-code can be specified in other ways:

<html lang="en-cockney">

<html lang="X-klingon">

The w3C suggests that older methods, such as declaring the language in a pragma directive or specifying it in the site’s .htaccess file, which you will find many references to online, should no longer be used.

Language declaration becomes interesting when you are mixing languages on a web page. You can define the fact that you are using multiple languages on the same page by separating the values for each language with commas:

<html lang=en,fr>

Alternatively, you could define a single default language, then switch to another language for a particular element:

<figure>
<blockquote lang="la">Idcirco, quod non animadvertit ea, quae in alius animo
aguntur, non facile quisquam repertus est infelix; illos autem, qui sui
animi motus non percipiunt, necesse est infelices esse.</blockquote>
<p>Through not observing what is in the mind of another a man has
seldom been seen to be unhappy; but those who do not observe the movements
of their own minds must of necessity be unhappy.</p>
<figcaption>Marcus Aurelius, The Meditations</figcaption>
</figure>

(Note that in this scenario lang is only effective for the element it is applied to. Once that tag closes, the page goes back to assuming we are writing in the language specified in the html tag. Also note that the directionality of language in HTML is a separate issue.)

In the past it’s been common for small sites with multiple region support to make a separate page for each language, significantly raising the amount of work required to create and maintain the site. Thankfully CSS3 introduces the lang selector, which allows web developers to easily switch the appearance and visibility of different languages written on the same page.

</time> after <time>: semantic dates in HTML5

The <time> element has had an off-again, on-again relationship with HTML5. Removed from the specification several months ago by WHATWG, it was quickly reinserted after an uprising from the web development community. <time> is not just back, it’s improved and better than ever, with many of the element’s new attributes officially supported by the W3C.

<time> surrounds time and date content on your page, in almost any context: the only requirement is that the date must be anytime between 0 CE and the future, as the element cannot take negative values. <time> allows the browser, search engines and other applications to understand the specific time and date that is referenced on a web page, rather than guessing.

The simplest example is a year date:

<p>The <time datetime="1816">year without a summer</time>.</p>

Or a month, for any year:

<p>Remember, remember <time datetime="11-05">the fifth of November</time>,
Guy Fawkes Day.</p>

Month and year or full date:

<p>Construction of the Berlin Wall began in <time datetime=1961-08>August 1961
</time>. It fell on <time datetime="1989-11-09">9 November, 1989.</time></p>

Obviously we can also talk about dates in the future. Full dates should include a time, in 24-hour (military) format, separated from the date by a T character or a space:

<p>The working group’s presentations have been rescheduled for
<time datetime="2012-03-07T15:00">3pm next Wednesday</time></p>

(Note that the W3C validator currently allows the full date without time information; it may not yet recognize the year-only and month-year combinations shown above).

For exact moments in time, we can also supply seconds:

<p>I’ll see everyone at <time datetime="2012-02-21 20:00:00">the party next
Tuesday</time></p>

That’s a good start, but remember that all web pages are international: a browser looking at the datetime value above has no idea which side of the international date line the page is talking about. While not having this information is allowed by the W3C validator, you should always add time zone details by specifying the offset between the location of the event and UTC (Coordinated Universal Time) traditionally known as Greenwich Mean Time. For example, Calgary is in the Mountain Time Zone, seven hours behind London. With that information, the HTML code would become:

<p>I’ll see everyone <time datetime="2012-02-21T20:00:00-07:00">next Tuesday
</time></p>

Alternatively, using just the time:

<p>You have a meeting at <time datetime="09:00-07">9am</time></p>

(A nice way of calculating time offsets from UTC for different cities around the world is at timeanddate.com)

pubdate

pubdate is now supported by the W3C. Adding the pubdate attribute to <time> indicates the publication date of the first appropriate ancestor element . For example:

<article>
<time datetime="2012-02-18">Posted 18 February</time>
</article>

…would indicate that the article was published on 18 February, 2012. A time with pubdate attribute directly in the <body> would indicate that the page was made on that date and time.

Ranges

Time now has the ability to describe time ranges and durations with the P prefix:

<p>Bake the soufflé for <time datetime="P25M">25 minutes</time></p>

You can specify durations of weeks (W), days (D), minutes (M) and seconds (S). These units may be separated by spaces:

<p>Wait <time datetime="P27D 7H 43M 11.5S">one lunar month</time>
before testing for lycanthropy

Introduction to Site Speed Optimization

Stopwatch The speed at which a web page loads is a delivery of service. A slow website not only frustrates users (an increasing number of whom will abandon your site as the seconds tick by) but also lowers your ranking in search results (Google includes page load speed as part of its algorithm) and potentially increases your costs, if you are paying for site traffic.

As a broad and general rule, assume that every visitor to your site has ADD. Every page must have a load time under eight seconds. That time should be less than five seconds, and ideally under two seconds.

Optimizing a site for speed is a seven-step process, the first five of which are applicable to every web page:

Set a performance baseline by testing the load time of existing pages.
Redesign and recode your pages for speed.
Minimize file sizes by shaving off every excess byte.
Reduce the number of HTTP requests.
Use intelligent compression and caching.
Cojoin, defer, optimize and make asynchronous any JavaScript.
Optimize MySQL queries.

Each of these steps will be explained in a separate upcoming article.

BALUCHITHERIUM

3D Extruded Text with CSS3

A few points to note before I begin:

the technique I am demonstrating here isn’t one I made from scratch; as far as I am aware, credit for origination should go to Mark Otto, a designer at Twitter; the version that I’m showing derives from patterns created by Trent Walton.
This is not “true 3D” but a fake-out; real 3D text will have to wait for lessons in WebGL and CSS 3D transforms.

Very simply, we create extruded text appearance by creating a stacked series of CSS text-shadows. As we’ll see later, transferring the same technique to box-shadow can also create the effect of a raised or sunken button in CSS.

The CSS code is somewhat repetitive; the main aspect to focus on is the changing vertical offset of the main shadows. Thankfully, text-shadow does not require CSS3 vendor prefixes.

The code for the example at the top of this article is:

h1 { background: #ccc; font-size: 4rem; padding: 1.2rem;
color: #fff; font-family: "Blue Highway"; "Arial Black", sans-serif;
text-align: center; letter-spacing: 1rem;
text-shadow:0 .01em 0px #dededa,
0 .015em 0 #dededa,
0 .02em 0 #dededa,
0 .028em 0 #dededa,
0 .035em 0 #dededa,
0 .04em 0 #dededa,
0 .045em 0 #dbdbd6,
0 .055em 0 #dbdbd6,
0 .06em 0 #dbdbd6,
0 .065em 0 #d9d9d4,
0 .07em 0 #d9d9d4,
0 .08em 0 #d8d8d3,
0 .085em 0 #d8d8d3,
0 .09em 0 #d8d8d3,
0 .095em 0 #d6d6d1,
0 .105em 0 #d6d6d1,
0 .06em .06rem rgba(104, 104, 92, 0.15),
.07em .105em .04em rgba(0, 0, 0, .015),
-.02em .09em .05em rgba(104, 104, 92, 0.25),
-.03em .07em .065em rgba(104, 104, 92, 0.1),
-.075em .08em .09em rgba(104, 104, 92, 0.06),
-.09em .06em .195em rgba(104, 104, 92, 0.095);
}

Just as with multiple background images in CSS, we separate multiple text shadows with commas, starting with those originating nearest the text element and working outwards. (For this example I’m using em units rather than px for enhanced scalability, but almost any CSS unit of measurement would work).

The first 16 shadows are solid, slowly and subtly growing darker as they descend, creating the appearance of extruded text. The final six shadows in the declaration actually serve the purpose of ambient shadows, being offset to the left, right, and top of each letter, with added blur and transparency (in the form of rgba color values).

Naturally, this effect will only work in modern browsers – IE9 does not support text-shadow, although IE10 will. It’s therefore wise to make sure that make that the base color of the text is distinct from the background, as is the example at the top of this article; try to avoid “white on white”, ensuring that your content is still readable in IE.

HTML5 Testing Tools

While validation will remain your front-line defense against pages that render poorly in the browser, there is a suite of other testing tools that can help you determine that you’ve created your page the right way, most especially for search engines. As a broad rule, these tools should be used after you’ve validated the page.

HTML5 Outliners

One of the advances that HTML5 has provided us is the ability to create pages that are far richer in semantics: generic <div> elements with class and id replaced with <article>, <section>, <aside> and more.

Validation will tell you if you’ve used these tags in the right order, but to actually understand the structure of your page, you should view your page in an HTML5 Outliner. Like the validator, the outliner accepts input either directly or from a URL.

Very simply, an outliner looks at the structure and headings of your page, and maps it as a series of nested ordered lists.As an example, this is a map of this article in the context of this blog:

demosthenes.info
1. featured articles
2. popular favourites
3. HTML5 Testing Tools
  1. HTML5 Outliners
  2. Rich Snippets Testing Tool
  3. Facebook Linter
4. web developer guide
5. featured comment
6. what i'm reading
7. what i'm watching
8. what i'm playing
9. what i'm hearing
10. blogs
11. podcasts
12. no ads ever
13. creative commons licensed

As an open algorithm, outliner tools are also available as extensions for Chrome, Opera, and as a bookmarklet that works in every modern browser.

Some common errors reported in the outliner:

If you find entries in the outliner are untitled, you are probably not using headings correctly.
If you find numbers skipped, you are likely not resetting your headings. (Remember that using <article>, <section> or <aside> resets your elements in HTML5: you use <h1> again from the start).

Rich Snippets Testing Tool

The advent of HTML5 has meant that search engines are now moving on from looking at metatags within the <head> of web pages to far more discrete, particular information, most especially in the form of microdata. The tools available to test this are less advanced, the schema proposal only being a year old. The only reliable service that I am aware of that tests “rich snippets”, as Google calls microdata-enhanced pages, is the Rich Snippets Testing Tool. There is no offline version yet available for the tool: the page to test must be on a public server.

Facebook Linter

While not directly related to HTML5, it is worthwhile mentioning the Facebook Linter (aka the Facebook debugger), which can show how your page appears to Facebook, together with any errors the Facebook crawler encounters. Like the Rich Snippets Testing Tool, the page to test must be on a publicly accessible server.

Calgary's Worst Website 2011: Calgary Transit

Five weeks into the semester and I realized that I have neglected to announce the winner of this website's annual competition for Calgary's Worst Website. This year’s winner is Calgary Transit, the portal for the city’s LRT and bus transit system.

The previous winner was chosen on the basis of the terrible design of the pages; while there is a great deal that could be improved about the visual qualities of http://calgarytransit.com/, the site’s worst aspect is, to me, its user interface, which I’ve critiqued in the past. Modern web technologies mean that the second decade will be focused on user-centric design: intelligent, responsive sites that quickly provide relevant, timely information to the user regardless of the device used… all aspects of which the Calgary Transit site leaves a great deal to be desired.

In discussions leading up to this award I’ve faced objections that the city’s transit system has a limited budget (an annual operating cost of $277.5 million) while trying to service an exploding population (now 1.2 million people) and suburbs that are creeping ever outwards. How can I justify pushing for a total site redesign under those conditions?

Let’s put it in perspective. A new Nova model LFS bus, as currently employed in Calgary Transit’s fleet, costs approximately $300,000. Ongoing operating costs for the vehicle – fuel, cleaning, maintenance, etc. – will easily double that.

For 1/10^th of that bus, you could have a complete, usable Calgary Transit website. And in terms of return… well, a Nova carries 40 people in an hour’s commute. A well-made website could serve that many Calgary Transit customers per second… and lead to far more efficient use of resources, with an intelligent routing system that would lead commuters to make better use of transit services.

When people are Calgary Transit Alternate making their own sites to work out Calgary transit services – in the case illustrated to the left, a Google Maps mashup made with a budget of $25,000, made as a project by a professor at Mount Royal University – you know that something is seriously wrong with the original site.

Of course at the same time there are competing interests: a petition to push Calgary Transit to 24/7 service, and to upgrade the bus stops. Both are worthy causes; either, if followed through with action, would increase costs for the transit service significantly. And CT does deserve kudos for its responsive Twitter presence and (in my experience) courteous staff.

Another entirely appropriate objection is the possibility that Calgary Transit’s customer base does not use browsers that are capable of supporting the kinds of features that I feel are reasonable. And that’s possible – although I would counter that we simply don’t know. Calgary Transit does – they have Google Analytics on their site, bless them – but anyone else is simply guessing. I would counter with the fact that Calgary is among the most wired (and wireless) cities in the world, and that I would hope that the bulk of the population has graduated from IE6… but even if they haven’t, there are tools like ChromeFrame and html5shiv to bring them into the second decade of this century.

And it may well be that an external, outsourced solution is the answer: if CalgaryTransit follows the lead of the site above, and provides its routing and schedule information under the auspices of OpenData, we could well have a half-dozen different portals for transit information, all using the same, rapidly updated information.

Site Icons For Mobile Devices

Modern mobile devices like iPhones, iPads and Androids boast high-speed web access and fully-featured browsers. They also have the ability to add a frequently visited site to their home screen as an icon. If you want your site to be represented with anything more than a generic picture or a zoomed version of your site’s 16 x 16 pixel favicon, you need to create an image with a very particular size and filename.

That image must be in PNG format, exactly 114 × 114 pixels in size, and have the filename apple-touch-icon.png or apple-touch-icon-precomposed.png. I recommend using the latter, as images with that filename are picked up by both Apple and Android devices, and escape a “shine” effect when they are rendered on the device’s screen. You can see the icon for this site in the top left corner of the image to the left.

You should treat the home screen icon image exactly like a favicon, and upload it to the root of your web server, directly beside the index page. No changes to your HTML code are needed: devices will pick up the icon automatically.

(And yes, the screenshot is from one of my own Apple devices: to take a screenshot under iOS 5, simply hold down the sleep button and tap the home button twice. The resulting screen grab is saved to your device’s camera roll.)

Showing 1 – 7 of hundreds
>
Oldest

featured articles

popular favourites

pubdate

Ranges

HTML5 Outliners

Rich Snippets Testing Tool

Facebook Linter

web developer guide

featured comment

what i'm reading

what i'm watching

what i'm playing

what i'm hearing

blogs

podcasts

no ads ever

creative commons licensed