After reading up on dl and the rubyelements 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 rubyelement 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:
<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>
Regardless of how you feel about the b and ielements, 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 != strongsemantically, 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.
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).
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 boldfont-weight:700 and strong above bold to font-weight:900.
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.
Image Search is one aspect of Web Development typically overlooked by the vast majority of developers. While it may seem a distant second to the primary goal of Search, it’s actually not that far off. Image naming conventions, when properly applied, can aid in a sites Search, Searchability and Findability.
Typical image naming conventions in Web Development include image-01.png or even worse blargherghdadurpdedoo.png; while they do serve as a unique identifier and therefore conform to their primary purpose, they can be utilized for much more by providing machine-readable text that can be understood by bots when crawling your site(s). Bots have no clue what the below image is:
Bots crawling your site will now index this image with reference to “Jordan Dunking vs. Lakers”, which provides an extremely more relevant and detailed description than “23432asaere”.
Apply the kiss Principle here: don’t overthink your file names, thereby (even if not intentional) spamming keywords via your file names. I like to rely on two or three word names for images.
Image Naming Rules
Separate words with hyphens (-)
Using at most two or three keywords
Use only alphanumeric characters and hyphens in file names, not underscores (_), spaces (, or special characters
Use descriptive Directory Naming Conventions in tandem with Image Naming Conventions
Added Benefits of Precise Image Naming Conventions
Image Naming Conventions also will aid in a sites Information Architecture, organizing files and directories to benefit your development team, as well as users and bots. Your team can also use them to track document versions, like so:
<img src="screenshot-issue-11-04-2009-001" />
Adding Precise Image Naming Conventions to Workflows
Adding image naming conventions to your workflow(s) is extremely easy and should not be overthought. Simply think about what an image is before you name it. If the image is part of a set, think about suffixing a number to the end of all the images in the set, or putting them all into a directory, that aptly names the set. It’s really that simple, and you’ll greatly benefit by making this part of your development process instead of a post development afterthought.
Add Humans.TXT to your site and flaunt your practices for the humanoid searcher. Humans.TXT is a simple text file that you add to the your root file, which is filled with information about the people behind the site.
Humans.TXT is an initative to inform users about the people behind a website; typically it contains information about all the different people who have contributed to the development process of a site. So mine is sparce and only contains information about me; lame, but it’s a start. More importantly, I did it to help spread the word and also add it into Front-Endworkflows.
Humans.TXT uses a text file because its simple and easy and not intrusive with your code. Using Humans.TXT you can prove your authorship (not your property) very fast and in an accessible way.
Make sure that your file is utf-8 capable and lowercase; You can also add in thank you’s as well as information behind your site.
The metaelement allows authors to attach additional information (representing metadata) to their documents. This information can be used by the user agent for rendering content, it can provide meta information for indexing, it can be used to simulate http Response Headers, and it also can be used to reload the document. The additional information also represents various kinds of metadata that cannot be expressed using the title, base, link, style and scriptelements.
The metaelement belongs in a document’s head and has no content; its attributes define name/value pairs associated with the document. The metaelement information is machine-parsable (read: machine tags and all browsers expose meta information via the dom. These name/value pairs can be used by the server to further define the document type to the user agent.
The metaelement is a void element: an element whose content modelnever allows it to have contents under any circumstances; It requires exactly one of the attributes of name, http-equiv and charset must be specified. If the name or http-equivattributes are specified then the contentattribute must also be specified, otherwise omit content.
html5, whatwg and the dcmi are all working to create a standard lists of meta properties, however currently none exists.
name="" Attribute
The name=""attribute is the name in the name/value pair and represents document-level metadata. This representation specifies what aspect of metadata is being set. If the content=""attribute is omitted then the value of the name/value pair is an empty string. If not provided, the name of the name/value pair is taken from the http-equiv=""attribute.
The name=""attributemust be a defined metadata name or a registered metadata name. name IDL attributesmust reflect the respective content=""attributes of the same name.
w3c Defined Metadata Names
application-name: the value of the content=""attribute must be a string representing the name of the Web App the page represents. If document is not a Web App, don’t use it. Cannot have more than one per document. User Agents can use application name in ui instead of the titleelement because title could have status messages, etc. relevant to the status of the page at a particular time.
author: value of the content=""attribute must be a string giving the name of the author(s) of the document.
description: value of content=""attribute must be a string describing the page. Must be appropriate for use in a search engine. Document cannot have more than one.
generator: value of the content=""attribute must be a string identifying software used to generate the document. Do not use this value on hand-authored pages (notepad denied!).
keywords: value of content=""attribute must be a set of comma-separated strings, where each string is a relevant keyword to the document.
w3c Other Defined Metadata Names
keyword: actual name being defined; should not be similar to any other defined name (like differing only in case).
brief description: short, non-normative description of what the metadata name’s meaning is, including the format the value is required to be in.
specification: link to a more detailed description of metadata name’s semantics and requirements.
synonyms: list of names that have exactly the same processing requirements. do not use the named defined to be synonyms, they’re only intended to allow user agents to support legacy content. Synonms not in practice can be removed, only names that need to be processed as synonyms for compatibility with legacy content are to be registered this way.
status: has three possible values: proposed, ratified, and discontinued
name="status" content="proposed": name has not received wide peer review and approval; name has been proposed and is or soon will be in use.
name="status" content="ratified": name has received wide peer review and approval. its specification unambiguously defines how to handle pages using the name including when used incorrectly.
name="status" content="discontined": metadata name has received wide peer review and has been found wanting. May be in use on existing pages, but new pages should not used it. If anything, “brief description” and “specification” entries give details of what the author should use.
whatwg Registered Metadata Names (technically none so far)
baiduspider – synonym for robots targeting Baidu only.
googlebot – synonym for robots targeting Googlebot only.
ia_archive – synonym for robots targeting Archive and Alexa only.
msnbot – synonym for robots targeting Bing only.
robots – comma-separated list of operators telling search engine bots how to treat content.
slurp – synonym for robots targeting Yahoo! only.
teoma – synonym for robots targeting Teoma and Ask.com only.
viewport – allows documents to specify size, zoom factor and orientation of the viewport used as the base for document’s initial containing block. The following properties can be used in the value of the content=""attribute: width, height, initial-scale, minimum-scale, maximum-scale, user-scalable.
audience – aids search engine classification and aids directory compiliations by providing the audience most appropriate for the page. Values are case-insensitive and comma-separated (singular and plural values are equal).
bot- – represents all bots prefixed with bot-.
created – document creation datetime (ISO8601 date); must follow w3c ISO-8601 datetime profile with a granularity of “complete date” or finer.
creator – off-Web/pre-Web creator of a work for which an author authored a document, so the creator and author can be different people. One element represents one creator; multiple creators need to be represented by multiple creator elemetns.
datetime-coverage – value is a non-vague date or non-vague time (not a range) expressing which time frame is most relevant to the content.
datetime-coverage-end – identical to datetime-coverage except only representing the end. When used without datetime-coverage-start, it is interpreted as ending a range without a start.
datetime-coverage-start – identical to datetime-coverage except representing only the start; if used without datetie-coverage-end, is interpreted as starting a range with no end.
datetime-coverage-vague – identical to datetime-coverage except its value is not clear; use when datetime-coverage, datetime-coverage-end, datetime-coverage-start are all inappaproiate (example: Tuesdays).
DC – stands for Dublin Core, maintained by the dcmi, reserves all strings that begin with DC..
dir-content-pointer – helps search engines organize results by identifying similar sections of pages in a directory with a standard vocabulary. Useful when using different conventions for displaying or printing content. Recognized values are pointer types to which numbers may be suffixed: start, toc (table of contents), intro, abstract, main, bibliography, index, afterword, update, credit and author bio. Number suffixes tell the search engine/directory to arrange like itmes in numerical order within the results. Each directory and subdirectory has its own sequence.
expires – defines expiration date of the document which can be used in preparation for an upcoming event (when you have a pre-set date when the document will no longer be valid, like a sign-up form for an event). Search engines should remove this page from their main search results after the expiration date or by telling the user the result is out of date.
format-print – informs operating system/printer driver of the preferred print medium (like paper size). Recognized values are letter, A4, legal, A5, B5, monarch, envelope 10, envelope 6-3-4 as well as values with integers and decimals, like 8.5 x 11, paper (default color), weight (usually 20lb. stock). You can specify a medium of the given color or mixed by using white, yellow, pink, blue, green, violet or multicolor. Letterhead, p2 letterhead (letterhead for all pages minus first page), watermark and plain (not preprinted/not letterhead).
geographic-coverage – specify geographic relevance of content.
keywords-not – negative keywords that distinguish closely-related themes from a document’s theme. Supports Boolean not searches.
page-datetime – tells search engines recency or relevance to an event date.
page-version – Versions regardless of date may show consecutiveness and can replace vague dates; a version number can be more useful in this case. Versions 0 and 0.n signify beta versions, where .n is number of places and 1 or higher implies final-release versions.
publisher – provides the document’s publisher, which often differs from creator/author when the publisher is an institution.
referrer – controls the sharing of referrer information with linked resources and followed links at the meta level. The content attribute accepts three values, always, default (include referrer information in non-secure conext or for https resources with same origin) and never; The never value is redundant with link rel="nofollow" and supplants said link element, which provides more control.
resolutions – specifies high-resolution versions of images that the browsers should use in place of lower-resolution default images if a high-resolution screen is detected to be in use.
rights – used to assert intellectual property rights in source code.
rights-standard – enable search engines to compile the types of rights allocated to the document; the example belows implies that the Page code is cc By Attribution, Share alike
subj-... – To classify by subject a page’s content, a standard subject taxonomy that will be recognized by a search engine or directory will help. Because many such high-quality taxonomies exist, only a prefix is proposed. Over time, particular taxonomies, in print or online, may be recognized here and keywords assigned for each.
MSSmartTagsPreventParsing – ie6 beta feature allowed browser to add information that wasn’t supplied by the document; this prevents that.
meta Pragma Directives
The http-equivattribute is an enumerated attribute (taking one of a finite set of keywords), and if a meta http-equivelement is present within the document, the user agentmust run the algorithim appropriate for that State. keywords and appropriate algorithims below:
State Content Language maps to keyword content-language; Content language state (http-equiv="content-language"): this pragma sets the pragma-set default language; until successfully processed, there is no pragma-set default language.
note: this will trigger a warning in validators, use langattribute instead.
State Encoding Declaration maps to keyword content-type; Encoding declaration state (http-equiv="content-type") alternative form of setting charset=""attribute; is a character encoding declaration. Encoding declaration state’suser agent requirements are entirely handled by the parsing section of the specification.
State Default Style maps to keyword default-style; Default style state (http-equiv="default-style"): this pragma sets the name of the default alternative style sheet.
State Refresh maps to keyword refresh; Refresh state (http-equiv="refresh"): pragma acts as a timed redirect.
State Cookie Setter maps to keyword set-cookie although Cookie Setter is non-conforming; Cookie setter (http-equiv="set-cookie"): pragma sets http cookie. Is non-conforming, you should use real http Headers instead.
Pragma Directive http-equiv="" Attribute
The http-equiv=""attribute is the name in the name/value pair; tells the server to include said pair in the mime document header that is passed to the browser before actually sending the document. When the http-equiv=""attributee is used, the server adds these name/value pairs to the content header it sends to the browser.
The http-equiv=""attribute is restricted to these values: refresh, default-style and content-type in html5.
http-equiv="refresh" Pragma Directive
The http-equiv=""attribute whose value is refresh represents a pragma directive specifying either a number of seconds after which to reload the current page, or a number of seconds after which to reload a different page and the url for the replacement page.
meta http-equivelement attribute whose value is default-style represents a pragma directive that specifies the document’s preferred stylesheet. content=default-style-name where default-style-name is the name of the preferred stylesheet and must either match the value of the link title="name" that also has href=""attribute referencing the location of said stylesheet or, the names must match the value of the style title="name" whose contents are a css stylesheet.
meta http-equivelement attribute whose value is content-language represents a pragma directive specifying a document-wide default language; this is obselete, specify the language on the root element instead.
meta http-equivelement attribute whose value is content-type and has an accompanying content attribute and value represents a character encoding declaration.
meta http-equiv="content-type" indicates the meta element is in the encoding declaration state and represents a character encoding declaration.
meta http-equiv="content-type" content="meta-charset string" is a specially formatted string providing a character encoding name whose value is content-type and which has an accompanying content attribute and value is said to be in the encoding declaration state.
Non-standard meta http-equiv Values
Allow
Content-Encoding
Content-Language
Content-Length
Content-Type
Date
Expires
Last Modified
Location
Set-Cookie
WWW-Authenticate
content Attribute
The contentattribute is the value in the name/value pair. The value can be any valid string and should always be used in conjunction with a name or http-equivattribute. It gives value of the document metadata or pragma directive when the metaelement is used for these purposes. The content contains the actual metadata defined by the The nameattribute.
The charsetattribute specifies the character encoding used by the document (aka character encoding declaration). It has no effect on xml documents, and is only used to facilitate migration to/from xhtml. The charsetattribute represents a document’s character encoding declaration when an html document is serialized to string form. There must be no more than one meta element with charsetattribute per document.
The charsetattribute represents a character encoding declaration, where charset="name" specifies a character encoding name specified by the iana registry that has a Name or Alias field labeled as “preferred mime name“, or if none of the Alias fields are so labeled, a Name field in the registry.
scheme Attribute
The schemeattribute defines the scheme that should be used to interpret the property’s value, which should be defined within the profile specified by the profileattribute of the headelement. It provides additional information about the meta information; used in conjunction with the profileattribute of the headelement (which provides a pointer to instructions about the contents of the profile which are directly related to meta name attribute values). The value of scheme is a uri specifying the location of the profile information on the server.
The schemeattribute is obselete; use only one scheme per field or make the scheme declaration part of the value.
GeoNames is a geographical database that integrates various related geodata. GeoNames is shared under a creative commons attribution license, is available for download free of charge, and users can manually edit, or add new data as need be.
I read about GeoNames while researching Linked Data, after a quick run through of the user manual, I did a search for Virginia Beach in the United States. It returned GeoNameId : 4791259, the GeoNames representation of Virginia Beach, va. While there is a plethora of named places in Virginia Beach, it still seems quite sparse to me; randomly, there is an overwhelming mobile home representation amongst the named places (some realtor knew what they were doing). The data is available in csv and png formats for download. The png representation of Virginia Beach’s Geoname is shown below.
It seems like GeoNames could use some serious updates; any idea(s) how this can be achieved without manually entering/editing it all? How would you use this data?
The Semantic Web is all about Linked Data, primarily made up of machine-readable links, aka machine tags. Search optimized urls are machine-readable in this sense, though primarily for search engines. Microformats, Microdata, and rdfa are all examples of machine tags that search engines have adopted. The html aelement, when used in conjunction with href=""attribute provide the connectivity that has enabled the web of hypertext. As amazing as the hypertext web is, it has its limitations, including only having local scope(s), and primarily only linking to data embedded in html documents. While data embedded in html documents are accessible on the web, it is not in the web.
The Semantic Web marks a shift from this method of thinking, from human readable to machine readable. You can make your data machine readable by adhering to Linked Data Expectations of Behavior to make the data interconnected. The more connected the data is, the more opportunities it has for unexpected reuse.
It is the unexpected re-use of information which is the value added by the web.
Tim Berners-Lee
To promote Linked Data, the lidrc Laboratory has published Linked Open Data Star Examples and Linked Open Data Star Badges. Use the former to define your data and the latter to promote your data. I have put them all together into a sprite to help promote Linked Open Data.
