Tag Archives: html

Improving the already excellent ‘Twitter Blackbird Pie’ WordPress plugin

4 Replies

I’ve just started using the “” plugin to embed tweets into WordPress posts (I use the self-hosted wordpress.org package). You can see an example below:

[blackbirdpie id=”66835851316957185″]

It’s fantastic — no more taking screen captures, cropping and uploading; or faffing about manually constructing links. All I have to do is include the magic code [blackbirdpie id="66835851316957185"] with the ID of the tweet (in the above example, taken from http://twitter.com/pigsonthewing/status/66835851316957185) as the id parameter value.

However, there are a few ways in which the plugin could be improved.

hCard microformat

Firstly, add an to emit details of the cited tweeter as metadata, by changing, for example (inline styles omitted for clarity):

<div><a href="http://twitter.com/intent/user?screen_name=pigsonthewing">@pigsonthewing</a><div>Andy Mabbett</div></div>

to:

<div class="vcard"><a class="nickname url" href="http://twitter.com/intent/user?screen_name=pigsonthewing">@pigsonthewing</a><div class="fn">Andy Mabbett</div></div>

with the addition of three class attributes: “vcard”; “nickname URL” and “fn”.

Citation

Next, instead of wrapping the contents of the tweet in a span, wrap it in a semantically-appropriate blockquote element, by changing:

<span>Blogging about a Blackbird.</span>

to:

<blockquote cite="http://twitter.com/pigsonthewing/status/66835851316957185">Blogging about a Blackbird.</blockquote>

and styling to maintain the current visual presentation.

Separating links

When viewed with CSS disabled, the tweet’s actions (“Reply”, “Retweet”, “Favorite”) run into each other.

Screenshot showing links with no spacing, when CSS is disabled

To improve accessibility and usability, either add white space between them, or, better, mark them up as a list, styled to display in-line, unbulletted, again looking like they do at present.

White space

There is more white space above then below the embedded tweet, above. A little more padding below it would improve readability.

COinS

Finally, consider adding COinS mark-up, so that details of the cited tweet are emitted as metadata.

Invitation

I hope the authors of the plug-in, Themergency.com, will appreciate and act on these suggestions. I’ll be inviting them to read and comment on this post. And I’ll be happy to help with developing any of the ideas suggested above.

I can teach HTML. Well.

Leave a reply

I enjoy talking about, and teaching people to use, valid, semantically-meaningful and accessible HTML. I don’t get to do the teaching very often, so, after running a session on the correct use of HTML tables, it was heartening today to receive a complimentary e-mail from an attendee. Having little modesty, I’m going to share part of it with you:

Just wanted to say thank you for the training this week… The subject of making our pages accessible for customers is a very important one, we will now make changes to the way in which we load our pages ensuring that we meet these standards… We found it very informative, interesting and unlike other training we’ve been on we didn’t walk out of there completely baffled, which is an accomplishment on your part, as the majority of us are not familiar with HTML.

Hello world!

4 Replies

I’m migrating to a WordPress.org installation. Please bear with me — and the crappy header graphic — while I fiddle under the bonnet.

The links that used to be on my home page are now on the new about page. I’ve migrated posts and comments from my old blog, Mabblog, and closed comments there. I’ll be using this site to blog from now on.

Recommendations for a better theme, useful plug-ins and the like all welcome. I’d particularly like to be able to write my own HTML header and footer (without using PHP), and to add & improve metadata headers.

The Highway Code should be available as a set of linkable HTML documents, not just PDFs

3 Replies

The Highway Code is:

the official road user guide for Great Britain ()

Drivers must study it in order to pass a driving test, and all road users should remain familiar with it — including any revisions — throughout their lives.

It’s available online, but large parts only as a series of large PDF files. That means that when, for example, my friend Pete Ashton asks:

It’s still illegal to park on double yellow lines, right? on Twitter

I can’t easily answer him by linking directly to the section of the Road Markings PDF which says:

Double yellow lines mean no waiting at any time, unless there are signs that specifically indicate seasonal restrictions.

I would like the Highway Code to be fully available as a series of plain old semantic HTML web pages, with each section within each page having a unique ID (which even the parts already in HTML currently lack), so that I can link to the relevant, specific, section when I want to refer to it. For example, the section quoted above might be at http://www.direct.gov.uk/en/TravelAndTransport/Highwaycode/markings#double-yellow

Dear Government, Can you do that, please?

Update: I’ve asked my MP, Khalid Mahmood, to do what he can to assist with this request. I’ll let you know what happens.

Dates and coordinates in HTML5

7 Replies

I’m grateful to Bruce Lawson of Opera for alerting me to discussion of the <time> element on the HTML5 mailing list (where I’ve posted a copy of this blog post) and encouraging me participate; and indebted to him for the engaging discussions which have led me to the ideas expressed below. So please blame him if you don’t like what I have to say 😉

I’ve read up on what prior discussion I can find on that mailing list; but may have missed some. I’ll be happy to have anything I’ve overlooked pointed out to me.

I have considerable experience of marking up dates in microformats, both for forthcoming events on the West Midland Bird Club’s diary pages; and for historic events, on Wikipedia and Wikimedia Commons.

I’ve been a staunch and early critic of the accessibility problems caused by abusing the <abbr> element for things like machine-readable dates (as has Bruce). The HTML5 time element has the potential to resolve that problem, but only if it caters for all the cases in which microformats are — or could potentially be — used.

It seems to me that there are several outstanding, and overlapping, issues for <time> in HTML5, which include use-cases, imprecise dates, Gregorian vs. non-Gregorian dates and BCE (aka “BC“) dates. First, though, I should like to make the observation that, while are most commonly used to allow event details to be added to calendar apps, and that that use case drove their development, they should not be seen simply as a tool to that end. I see them, and hope that others do, as a way of adding semantic meaning to mark-up; and that’s how I view the “time” element, too. Once we indicate that the semantic meaning of a string of text is date, it’s up to other people to decide what they use that for — ”let a thousand flowers bloom”, as the adage goes.

Use-cases for machine-readable date mark-up are many: as well as the aforesaid calendar interactions, they can be used for sorting; for searching (“find me all the pages about events in 1923″ — recent developments in Yahoo’s YQL searching API (which now supports searching for microformats) have opened up a whole new set of possibilities, which is only just beginning to be explored). They can be mapped visually on a “SIMILE” or similar time-line. They can be translated into other languages more effectively than raw prose; they can be disambiguated (does “5/6/09” mean “5th June 2009” or “6th May 2009”?); and they can be presented in the user’s preferred format (I might want to see “5th June 2009”; you might see “June 5, 2009″ — such presentational preferences have generated arguments of little-endian proportions on Wikipedia).

hCalendar microformats are already used to mark up imprecise dates (“June 1977”; “2009”). ISO8601 already supports them. Why not HTML5? Though care needs to be taken, it’s even possible to mark up words like “today” with a precise date, if that’s generated real-time, server-side.

The issue of non-Gregorian (chiefly Julian) dates is a vexing one; and has already caused problems on Wikipedia. So far as I am aware, there is no ISO-, RFC- or similar standard for such dates, other than converting them to Gregorian dates. It is not the job of the HTML5 working group to solve this problem; but I think the group should recognise that at some point a solution must be forthcoming. One way to do so would be allow something like:

<time schema="[schema-name]" datetime="[value]">[date in plain text]</time>

where the schema defaults to ISO 8601 if not stated, and the whole element is treated as simply:

[date in plain text]

if the schema is unrecognised; thereby ensuring backwards compatibility. That way, if a hypothetical ISO- or other standard for Julian dates emerges in the future, authors may simply start to use it without any revision to HTML 5 being required.

As for BCE dates, they’re already allowed in ISO 8601 (since there was no year 0, the year 3 BCE is given as -0002 in ISO 8601). I see no reason why they should be disallowed in <time> elements in HTML5. We wouldn’t, to take an extreme example, say that “<P>” can be used for paragraphs in English but not French; or paragraphs about literature but not music, so why make an effectively arbitrary limit on the dates which can be marked up semantically? Surely the use case for marking-up a sortable table of Roman emperors, should allow all such emperors, and not just those who ruled from 0001AD, to be included?

Coordinates

Another abuse of ABBR in microformats for coordinates:

<abbr class="geo" title="52.548;-1.932">Great Barr</abbr>

Bruce and I agree that this could be resolved, and HTML5 usefully extended, by a “location” element:

<location latitude="52.548" longitude="-1.932">Great Barr</location>

Using the “schema” attribute shown above, for non-Gregorian dates, we can extend that for Martian, Lunar (and eventually other bodies):

<location schema="moon" latitude="52.548" longitude="23.47297">Sea of Tranquility</location>

and for nonWGS84 coordinates, in a manner similar to that I described in my proposals to extend the related Geo microformat.

Now all we need to do is to work-around the abuse of ABBR for durations, in the draft hAudio microformat:

<abbr title="PT3M23S">3 minutes 23 seconds</abbr>

Marking up the scientific names of living things

Leave a reply

As any web manager worth their salt knows, it’s <span lang=”fr”>trés important</span> that changes in language be marked up with HTML’s “lang” attribute, using an IETF language tag (such as “fr” for French, as shown above). This allows software like text readers for blind people to pronounce them correctly (instead of sounding like an outtake from ‘Allo ‘Allo!) and means that translation software can handle them appropriately.

But what happens when a page like this one includes the scientific (or taxonomic) name of a living thing, such as Circus cyaneus (the Hen Harrier)? It’s not English, and should not be translated, into, say, German, as Zirkus cyaneus.

It’s not really Latin, either, though some people mistakenly refer to scientific names as “Latin names”. Many of them are neologisms — new words, with no real Latin content, but based on Latinised Greek (for example Brachypelma albopilosum), people’s names (Ardeola grayii, in honour of John Edward Gray, a biologist), place names (Nepenthes sumatrana, from Sumatra), culture (Ba humbugi, a quote from Charles Dickens‘ ‘A Christmas Carol‘) or even humour (Phthiria relativitae, a play on “The Theory of Relativity”).

Back in 2003, on the IETF mailing list whcih discusses such langauge codes, I proposed that there should be a specific language code, or sub-code, so that scientific names such as these could be marked up and recognised by software. There wasn’t much interest (possibly because I made the proposal as an amateur, rather than a professional or academic taxonomist), and distractions in my work and domestic life meant that I didn’t, unfortunately, have time to pursue the matter.

However, the need for such a code has now been recognised by Gregor Hagedorn, of the Julius Kuehn Institute, Germany‘s Federal Research Centre for Cultivated Plants, in Berlin, who has rekindled my proposal.

With the support of Gregor and other taxonomists, via the Taxacom mailing list, I’m hopeful we can at last make a case that such a code is needed.

hAccessibility – Unhappy First Birthday

8 Replies

It’s one year today since Bruce Lawson and James Craig published “hAccessibility“, about the misuse of the ‘abbr’ element in microformats (an issue I first raised on 20 September 2006 in Accessify Forums).

As recent events show, the microformats cabal still has its collective head up its own^W^W^W in the sand.

Despite suggestions for a workaround, a solution seems no nearer, thanks to their apparent indifference. Shame on them.

More Nokia N95 (and Opera Mini) wishes

1 Reply

Dear Nokia, and Opera,

When using your browsers on my N95, please can I:

  • Copy text from a web page
  • Disable CSS
  • View the HTML source
  • Parse microformats (not least hCard, to add contact details to the address book and dial phone numbers; hCalendar, to add events to the calendar; and Geo, to find places on maps).

Surely that’s not a lot to ask for? Thank you.