Accessible Semantic HTML5 Glossary

Quick follow up to my last post regarding semantic glossaries: dictionary.com uses audio examples to express correct pronunciation. While I don’t think this practice is necessary for most glossaries, I can’t see how it would hurt any of them. If anything, you’d simply be adding accessibility coverage, which should always be a goal for a site, even if it’s in the long-run. Plus, in a very miniscule way, you’re adding more content, so it seemingly should help with seo. So, simple enough, right? Just add audio into the ruby element and we’re good, right? Not so fast, I quickly found out that cross-browser styling of audio isn’t very well documented, even though I’m positive it’s doable.

For starters, I grabbed the speaker icon via the Noun Project to show users that there is audio content to hear. It is an svg and I had planned on adding cross-browser compatibility for it, however considering the audio roadblock I hit, I decided to just publish this now and I’ll work on that once I get it to play in all browsers. Then I grabbed an audio file, I don’t have a microphone, so I couldn’t create the actual word pronunciation which is lame, but I figured this is just for demonstration purposes only. I used media.io to generate .ogg and .wav files for (what I thought was) cross-browser compatibility. And I thought I was good to go, but clearly this was not the case.

Fallback via button

Once I ran into the audio styling roadblock, I lamely wrapped it up into a button element. I thought for sure this would be the silver bullet. Negative, Ghost Rider. I hooked the button into the audio element‘s onclick event handler and provided 3 separate audio formats (.mp3 for Webkit, .ogg for Gecko and .wav for Presto) via source element. Here’s the markup and JavaScript:

Markup


<button type="button" id="play">
<audio id="audiosrc">
<source src="http://dev.bowdenweb.com/a/m/a/clipping_link-finds-a-secret-13908.ogg" />
<source src="http://dev.bowdenweb.com/a/m/a/clipping_link-finds-a-secret-13908.mp3" />
<source src="http://dev.bowdenweb.com/a/m/a/clipping_link-finds-a-secret-13908.wav" />
</audio>
</button>

JavaScript


window.onload = function() {
  var audio = document.getElementById("audiosrc");
  var play = document.getElementById("play");
  play.addEventListener('click', function(){
    audio.play();
   }, false);
}

Note: this doesn’t work in Opera 11.5, which is baffling to me. From what I can understand, Opera supports .ogg, but once I saw it not working, I actually created the .wav file specifically for Opera, and still no bueno. After struggling with this for a few hours, I’ve given up at the moment, so I’m quite positive that this won’t work in ie without testing. I’ll be sure to follow up on this as soon as I find more out and/or find a more elegant cross-browser solution. You can check out the Accessible Semantic Glossary demo here.

Semantic Glossary in HTML5

Using ruby with dl for English Words

After reading up on dl and the ruby elements on the super awesome html5Doctor, I was inspired to add this markup to my own dev glossary. Being the anal-retentive loser that I am, I frequently visit dictionary.com for correct spellings, and knew they had a viable use for the ruby element already in their markup. So I simply just put them together, nothing new or out of the box here. Below is a screenshot of the dictionary.com reference mentioned:

Screenshot of Definition of Assay on Dictionary.com

Definition of Assay on Dictionary.com

So I whipped up a simple semantic glossary demo for your viewing pleasure. Below is a screenshot and the corresponding markup.

Screenshot of Semantic HTML5 Dictionary

Screenshot of semantic html5 Dictionary


<dl> 
  <dt><ruby><dfn>Franscrollow</dfn> <rp>(</rp><rt>fran-scrahl-oh</rt><rp>)</rp></ruby></dt> 
  <dd>Verb that eliminates headaches and complexity by combining all relevant stalker-related buzzwords into one easy-to-remember term.  Friend + Fan + Subscribe + Follow = Franscrollow. So please, franscrollow me. You'll never be be made obsolete by smelly geeks again. It's the future, and you're welcome.
    <cite><a href="http://www.baratunde.com/franscrollow" title="Fanscrollow - baratunde.com"><b>Franscrollow</b> found here</a>.</cite></dd> 
  <dt><dfn><abbr title="XML Binding Language">xbl</abbr> (<abbr title="Extensible Markup Language">xml</abbr> Binding Language)</dfn></dt> 
  <dd>is a language for describing bindings that can be attached to <b>elements</b> in other documents. The <b>element</b> that the <b>binding</b> is attached to is called the <strong><em>bound element</em></strong>, acquires the new behavior specified by the <b>binding</b>. <b>Bindings</b> can contain <b>event handlers</b> that are registered on the <strong><em>bound element</em></strong>, an implementation of new <b>methods</b> and <b>properties</b> that become accessible from the <strong><em>bound element</em></strong>, and anonymous content that is inserted underneath the <strong><em>bound element</em></strong>. Most <abbr title="XML User Interface Language">xul</abbr> widgets are at least partially implemented using <strong><abbr>xbl</abbr></strong>. Developers can build their own widgets from existing <abbr>xul</abbr>, <abbr>html</abbr>, <abbr title="Scaleable Vector Graphics">svg</abbr>, and other primitives using <strong><abbr>xbl</abbr></strong>.
    <cite><a href="https://developer.mozilla.org/en/XBL" title="XBL - MDN Docs"><abbr>xbl</abbr> found here</a></cite></dd> 
</dl> 

Cross-Browser Small Caps Font Linking

Picking up from Font Linking Separate Styles for b and i, I wanted to add examples of using Small Caps fonts with @font-face correctly. I did get it working cross-browser in Firefox 5, Opera 11.5, Chrome 14.0.8, Safari 5.0.5, and ie9, but not without jumping through some hoops first.

To start, I needed to acquire some fonts that have a Small Caps type; I found three at exljbris Font Foundry, which I used for this demo, Delicious, Fontin, and Fontin Sans. Then I simply put each into a demonstration page, declaring the Small Caps font in the @font-face rule and adding the font-variant style, like so:


@font-face{font-family:"Delicious";
  src: url('http://bowdenweb.com/assets/fonts/delicious/webfontkit/delicious-smallcaps-delicious.eot');
  src: url('http://bowdenweb.com/assets/fonts/delicious/webfontkit/delicious-smallcaps-delicious.eot?#iefix') format('embedded-opentype'),
       url('http://bowdenweb.com/assets/fonts/delicious/webfontkit/delicious-smallcaps-delicious.woff') format('woff'), 
       url('http://bowdenweb.com/assets/fonts/delicious/webfontkit/delicious-smallcaps-delicious.ttf') format('truetype'), 
       url('http://bowdenweb.com/assets/fonts/delicious/webfontkit/delicious-smallcaps-delicious.svg#DeliciousSmallCapsRegular') format('svg');
font-weight:400; font-style:normal; font-variant:small-caps}

Initially, I had the fonts declared starting with the Regular version, continuing through any other versions (Bold, Italic, etc.) and ending with the Small Caps font. This failed in Firefox 5 however, all of the fonts would render as Small Caps. After doing a little research, I came across this @font-face Implementation Test, which proved quite useful. The tests recommend placing the font-variant:small-caps rule first because Firefox 3.6 and Opera 10.5 both will overwrite regular text if not. The implementation test is a bit out dated here, Opera 11.5 handles declaring font-variant declarations correctly, and also doesn’t cover ie, but that’s not to take away from it, I did find my solution here.

So for the second test run, I declared font-variant:small-caps first, then declared all the rest of the fonts per family, and lastly declared the Regular font. This proved fruitful cross-browser until I got to ie9, which rendered all the text in Small Caps, just as Firefox had until I flipped the font ordering. So I quickly reversed the changes I had just made and sure enough, they rendered correctly in ie.

Knowing that we can use one method to work in every browser except for ie, and being used similar situations (as all web developers are), my first inclination was conditional comments. I did use them for the final solution, however I did a tad bit more. If you take a gander at the declarations below:


@font-face{font-family:"FontinSansRegular";
  src: url('http://bowdenweb.com/assets/fonts/fontin-sans/webfontkit/fontin-sans-regular-45b-fontin-sans.eot');
  src: url('http://bowdenweb.com/assets/fonts/fontin-sans/webfontkit/fontin-sans-regular-45b-fontin-sans.eot?#iefix') format('embedded-opentype'),
  url('http://bowdenweb.com/assets/fonts/fontin-sans/webfontkit/fontin-sans-regular-45b-fontin-sans.woff') format('woff'), 
  url('http://bowdenweb.com/assets/fonts/fontin-sans/webfontkit/fontin-sans-regular-45b-fontin-sans.ttf') format('truetype'), 
  url('http://bowdenweb.com/assets/fonts/fontin-sans/webfontkit/fontin-sans-regular-45b-fontin-sans.svg#FontinSansRegular') format('svg');
font-weight:400; font-style:normal}

The first two lines target ie, while the last 3 cover the rest of the browsers; I didn’t want to serve up ie styles to non-ie browsers nor did I want to serve up any more extra (than already needed) for ie. So here’s what I did: I took out the ie specific declarations and put them into their own stylesheet, with the font-variant:small-caps declared last, then placed that stylesheet in conditional comments. Here’s the new version of the declarations for real browsers:


@font-face{font-family:"FontinSansRegular";
  src: url('http://bowdenweb.com/assets/fonts/fontin-sans/webfontkit/fontin-sans-smallcaps-45b-fontin-sans.woff') format('woff'), 
  url('http://bowdenweb.com/assets/fonts/fontin-sans/webfontkit/fontin-sans-smallcaps-45b-fontin-sans.ttf') format('truetype'), 
  url('http://bowdenweb.com/assets/fonts/fontin-sans/webfontkit/fontin-sans-smallcaps-45b-fontin-sans.svg#FontinSansSmallCaps') format('svg');

And the declarations for ie:


@font-face{font-family:"FontinSansRegular";
  src: url('http://bowdenweb.com/assets/fonts/fontin-sans/webfontkit/fontin-sans-regular-45b-fontin-sans.eot');
  src: url('http://bowdenweb.com/assets/fonts/fontin-sans/webfontkit/fontin-sans-regular-45b-fontin-sans.eot?#iefix') format('embedded-opentype');

Note: While this does work, I cannot say 100% if this is the best way to go about serving up Small Caps correctly via @font-face. Actually I’m positive that it isn’t, but it is a solution. Until I find more information to shed some light on this situation and browsers provide better support, I am stuck at this point. You can view the demonstrations here: Delicious Font Demo, Fontin Font Demo, and Fontin Sans Font Demo.

StronglyTyped JavaScript Library Logo

StronglyTyped logo | Flickr

StronglyTyped logo

posted by leaverou

Logo for a JavaScript library I wrote for strongly typed properties & global variables in JavaScript The description, as entered by the person who uploaded it.

37070783@N07 The ID of the content owner – you can use this to link to their buddy icon. like so leaverou

jalbertbowdenii Your Flickr screen name.

Cross-Domain XHR Flowchart

cross-domain xhr | Flickr

cross-domain xhr

posted by iluvrhinestones

The description, as entered by the person who uploaded it.

60216816@N00 The ID of the content owner – you can use this to link to their buddy icon. like so iluvrhinestones

jalbertbowdenii Your Flickr screen name.

Font Linking Separate Styles for b and i

Regardless of how you feel about the b and i elements, not only are they included in the html5 specification, they have been giving new semantic meaning. These new definitions assure that i != em and b != strong semantically, but when it comes to browser rendering the pairs are still equals. Considering they have separate meanings, it seems intuitive that their display should also convey the differences, or at the very least that they are different.

Opting for subtlety in design, I have chosen to portray the differences in content semantics by capitalizing on font linking optimization, a smart and elegant technique posted on 456 Berea Street.

For demonstration purposes, I grabbed Panefresco from the super fabulous Font Squirrel, namely because it has 16 styles from which to choose from. For brevity, I’m not going to post Panefresco’s @font-face Kit or my alterations entirely, but you can view the original here and my alterations here. The following font linking css displays the technique, notice how they all have the same font-name but each has its own resources as well as its own unique font declaration(s).


/** Panefresco Regular font weight 100 */
@font-face{font-family:"Panefresco400wtRegular";
src: url("http://dev.bowdenweb.com/assets/fonts/sans-serif/panefresco/Panefresco1wtRegular-webfont.eot");
src: url("http://dev.bowdenweb.com/assets/fonts/sans-serif/panefresco/Panefresco1wtRegular-webfont.eot?#iefix") format("eot"),
  url("http://dev.bowdenweb.com/assets/fonts/sans-serif/panefresco/Panefresco1wtRegular-webfont.woff") format("woff"),
  url("http://dev.bowdenweb.com/assets/fonts/sans-serif/panefresco/Panefresco1wtRegular-webfont.ttf") format("truetype"),
  url("http://dev.bowdenweb.com/assets/fonts/sans-serif/panefresco/Panefresco1wtRegular-webfont.svg#webfontgFFh5vxH") format("svg");
font-weight:100; font-style:normal}
/** Panefresco Italic font weight 100 */
@font-face{font-family:"Panefresco400wtRegular";
src: url("http://dev.bowdenweb.com/assets/fonts/sans-serif/panefresco/Panefresco1wtItalic-webfont.eot");
src: url("http://dev.bowdenweb.com/assets/fonts/sans-serif/panefresco/Panefresco1wtItalic-webfont.eot?#iefix") format("eot"),
  url("http://dev.bowdenweb.com/assets/fonts/sans-serif/panefresco/Panefresco1wtItalic-webfont.woff") format("woff"),
  url("http://dev.bowdenweb.com/assets/fonts/sans-serif/panefresco/Panefresco1wtItalic-webfont.ttf") format("truetype"),
  url("http://dev.bowdenweb.com/assets/fonts/sans-serif/panefresco/Panefresco1wtItalic-webfont.svg#webfontCeET7Ncb") format("svg");
font-weight:100; font-style:italic}
/** Panefresco Regular font weight 250 */
@font-face{font-family:"Panefresco400wtRegular";
src: url("http://dev.bowdenweb.com/assets/fonts/sans-serif/panefresco/Panefresco250wtRegular-webfont.eot");
src: url("http://dev.bowdenweb.com/assets/fonts/sans-serif/panefresco/Panefresco250wtRegular-webfont.eot?#iefix") format("eot"),
  url("http://dev.bowdenweb.com/assets/fonts/sans-serif/panefresco/Panefresco250wtRegular-webfont.woff") format("woff"),
  url("http://dev.bowdenweb.com/assets/fonts/sans-serif/panefresco/Panefresco250wtRegular-webfont.ttf") format("truetype"),
  url("http://dev.bowdenweb.com/assets/fonts/sans-serif/panefresco/Panefresco250wtRegular-webfont.svg#webfontAsSDuy7L") format("svg");
font-weight:200; font-style:normal}
/** Panefresco Italic font weight 250 */
@font-face{font-family:"Panefresco400wtRegular";
src: url("http://dev.bowdenweb.com/assets/fonts/sans-serif/panefresco/Panefresco250wtItalic-webfont.eot");
src: url("http://dev.bowdenweb.com/assets/fonts/sans-serif/panefresco/Panefresco250wtItalic-webfont.eot?#iefix") format("eot"),
  url("http://dev.bowdenweb.com/assets/fonts/sans-serif/panefresco/Panefresco250wtItalic-webfont.woff") format("woff"),
  url("http://dev.bowdenweb.com/assets/fonts/sans-serif/panefresco/Panefresco250wtItalic-webfont.ttf") format("truetype"),
  url("http://dev.bowdenweb.com/assets/fonts/sans-serif/panefresco/Panefresco250wtItalic-webfont.svg#webfontFnMZKWyV") format("svg");
font-weight:200; font-style:italic}
/** Panefresco Regular font weight 400 */
@font-face{font-family:"Panefresco400wtRegular";
src: url("http://dev.bowdenweb.com/assets/fonts/sans-serif/panefresco/Panefresco400wtRegular-webfont.eot");
src: url("http://dev.bowdenweb.com/assets/fonts/sans-serif/panefresco/Panefresco400wtRegular-webfont.eot?#iefix") format("eot"),
  url("http://dev.bowdenweb.com/assets/fonts/sans-serif/panefresco/Panefresco400wtRegular-webfont.woff") format("woff"),
  url("http://dev.bowdenweb.com/assets/fonts/sans-serif/panefresco/Panefresco400wtRegular-webfont.ttf") format("truetype"),
  url("http://dev.bowdenweb.com/assets/fonts/sans-serif/panefresco/Panefresco400wtRegular-webfont.svg#webfontGS74qLRB") format("svg");
font-weight:400l; font-style:normal}

Note: Panefresco applies font-weight values on 250, 750 and 999, which differ from css specifications that use font-weight values divisible by 100. I’ve spoken about the differences between type design conventions and css conventions before, and this is a perfect example. I’m not taking a side here, just pointing out the obvious. For this example I’ve simply set Panefresco 250 to font-weight:200, Panefresco 750 to font-weight:700 and Panefresco 999 to font-weight:900, but that’s not to say they are correct.

I now have more than enough options to convey semantic meaning to users, while staying within the same font-family, it’s just a matter of styling them. Applying a lighter font-weight value to b than to strong is an obvious solution that I’m actually going to carry over to i and em as well. Personally, I view em implying text with stress emphasis as being both italic and bolded, however I’m usually wrong and moreover, this post is about styling i and b.

After putting the demonstration together, I noticed that even though b and strong have different font-weights, they are not very distinguishable and to compensate I actually set b to bold font-weight:700 and strong above bold to font-weight:900.

You can see view the demo here, or just check out the screenshot below:

Font Linking Separate Styles for <b> and <i> Screenshot - Excerpt from The Last of the Mohicans
Font Linking Separate Styles for <b> and <i> Screenshot - Excerpt from The Last of the Mohicans

So there’s my easy solution to expressing varying degrees of semantics to readers via font linking. Hopefully this will inspire you to embrace a more vivid font design library into your workflows. During the creation of this post, quite a few new ideas popped into mind, hopefully it does the same for you.

Tons of love and gratitude extended to html5doctor, 456 Berea Street and Richard Ishida’s Language Subtag Lookup App, for providing the inspiration and blueprint for this post.

Quoting font-family Name Values in CSS

Always Quote Font Family Names in css

The css3 specification says that font-family names must be quoted if they contain the keyword values of inherit, default, serif, sans-serif, monospace, fantasy and/or cursive. By simply applying quotes to every font family name besides the defaults, you’re being proactive and ensuring that the proper font-family is applied.

Sounds simple enough, but why should you care? If you’re in a large organization, setting this simple standard can go along way, especially when there are lots of hands touching code. Moreover, the disconnect between type designers and the css specification is quite evident when using font linking. I noticed this trend while searching for font families with multiple weights; many fonts that should be in the same font-family under css rules are actually in their own family as defined by the artist. Below are screenshots of a few popular fonts that have the keyword value serif in their name and could cause problems if not quoted.

DejaVu Serif, Droid Serif and Afta Serif, Popular fonts that have CSS Keyword Values in their Names.
DejaVu Serif, Droid Serif and Afta Serif, Popular fonts that have css Keyword Values in their Names.

Note: I’m not attacking type designers here, I’m merely pointing out the obvious. Regardless of who is to blame, if you just start quoting your font-family values, you’ll never have to worry about it.

text-rendering Property

text-rendering is actually an svg property that provides text optimization information to the rendering engine while rendering text. Gecko and WebKit browsers have adopted text-rendering and allow it to be applied to html/xml content on Windows and Linux. Firefox in Windows automatically applies text-rendering:optimizeLegibility for text greater than 20px, Firefox for Mac has it always applied by default and Safari has it off by default for performance reasons. When set to text-rendering:optimizeLegibility enables ligatures in text that is 20px or smaller and also turns on kerning.

Style Declaration Style Definition
text-rendering:auto Browsers will make educated guesses about when to optimize for speed, legibility and geometric precision when drawing the text.
text-rendering:optimizeSpeed Browser emphasizes rendering speed over legibility and geometric precision when drawing text; disables kerning and ligatures. Has no effect on Gecko 2.0 (Firefox 4)
text-rendering:optimizeLegibility Browser emphasizes legibility over rendering speed and geometric precision, enabling kerning and optional ligatures
text-rendering:geometricPrecision Browser emphasizes geometric precision over rendering speed and legibility; makes text that use non-linear scaling font aspects look good. Kerning is one font aspect that doesn’t scale linearly. Scaling text in svg can result in stair-step scaling, however when fully supported, text-rendering:geometricPrecision lets text scale fluidly. WebKit supports text-rendering:geometricPrecision but Gecko treats it the same as text-rendering:optimizeLegibility

Note: using text-rendering:optimizeLegibility is not a silver bullet and it does come with certain cross-browser drawbacks:

  • text-rendering:optimizeLegibility, when used in unison with font-variant:small-caps causes small-caps not to render in Chromium
  • text-rendering:optimizeLegibility causes text to disappear completely in webOS
  • text-rendering:optimizeLegibility negatively impacts page load; Use Caution, especially on mobile devices.
  • text-rendering:optimizeLegibility, when used in conjunction with margin, padding, border-width, or outline-width properties which are set using ex measurement type in Safari 5 causes the browser to crash.

links for 2011-06-23

links for 2011-06-22